From pthubert@cisco.com Mon Mar 1 01:59: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 3B5623A8B47; Mon, 1 Mar 2010 01:59:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GjBN5QfuxOc3; Mon, 1 Mar 2010 01:59:39 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id B7D133A8B2F; Mon, 1 Mar 2010 01:59:38 -0800 (PST) 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: AtQAALIei0uQ/uCWe2dsb2JhbACbDRUBARYkBhyhfZdDhHsE X-IronPort-AV: E=Sophos;i="4.49,559,1262563200"; d="scan'208";a="57597344" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 01 Mar 2010 09:59:37 +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 o219xblb013699; Mon, 1 Mar 2010 09:59:37 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, 1 Mar 2010 10:59:38 +0100 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, 1 Mar 2010 10:59:33 +0100 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D01594653@XMB-AMS-107.cisco.com> In-Reply-To: <201002282158.35975.hrogge@googlemail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] [manet] Fwd: New Version Notification fordraft-gnawali-roll-etxof-00 Thread-Index: Acq4uNkkx80bxBl7RqS5VbjCOTU2ugAWripg References: <20100223045634.C3F6328C44F@core3.amsl.com><201002281212.54577.hrogge@googlemail.com> <201002282158.35975.hrogge@googlemail.com> From: "Pascal Thubert (pthubert)" To: "Henning Rogge" , "Marcello Caleffi" X-OriginalArrivalTime: 01 Mar 2010 09:59:38.0078 (UTC) FILETIME=[E76847E0:01CAB925] Cc: ROLL WG , manet@ietf.org, Thomas Heide Clausen Subject: Re: [Roll] [manet] Fwd: New Version Notification fordraft-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: Mon, 01 Mar 2010 09:59:40 -0000 Hi Henning: I share your belief that we can and need to derive more stable information out of the very dynamic raw data we get from the radio links. The rank is supposed to be one such information, and because tuning an adaptive filter is more properly achieved with an heuristical understanding of the use case, RPL introduces the Objective Functions that instantiate the generic RPL mechanisms for the specificities of a use case. The good point here is that there's room for additional OFs after the RPL spec is released. So (hopefully) you won't hear that RPL does not work because of such things as hop count, but rather that this OF applies better than that one for this use case. On the side, I'm sure that we could learn quite a few things on how to operate our filters from guys who track curves all day on the stock market ; ) This does not mean that the router should not react upon rapid variations of the link metrics. The roll fundamentals draft add some words about that see http://tools.ietf.org/html/draft-thubert-roll-fundamentals-01#section-6. 2.3. The idea here would be to consider that the filtered metrics are topological - that is they impact the routing operation - whereas the transient variations of the link properties are topical - that is the impact the per packet forwarding decision only. cheers, Pascal -----Original Message----- From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Henning Rogge Sent: Sunday, February 28, 2010 9:58 PM To: Marcello Caleffi Cc: ROLL WG; manet@ietf.org; Thomas Heide Clausen Subject: Re: [Roll] [manet] Fwd: New Version Notification fordraft-gnawali-roll-etxof-00 Am Sonntag 28 Februar 2010 12:33:49 schrieb Marcello Caleffi: > We should discuss about it. Honestly, I don't know if the=20 > post-processing can be independent from the metric dimension, but it will be a nice idea. I'm convinced it can be done, especially if the range of raw metric would be known (0 to 2^24-1 for example). Sliding-Window averaging, exponential aging, even hysteresis could be considered postprocessing of the raw link value, not depending what data is represented by the link. It's similar to ripples objective function I think, just with a little bit more options. =20 > It was not my intention to discuss against your draft. Until we move=20 > towards realistic hypothesis, I am in. Okay. > But since there are multiple > bi-directional connections among the topics: << I want a routing=20 > protocol that works also in non-trivial networks <---> routing=20 > protocols forward the packets according to routing metrics <---> I=20 > need a good routing metric <---> routing metric usually estimates=20 > random processes like delivery ratio or round trip time Packet loss/error rate, delay and bandwith... that are the most common three generic metric values I think. Signal strength might be a forth one. > <---> I need a good estimator >> here I am just exploiting the=20 > opportunity provided by your draft to discuss some issues outside from > my research group. If you have a good idea how to "smooth/stabilize" the output of a packet loss measurement without sacrificing lot's of reaction time of the metric I would be very interested. The problem with many routing metrics is that they either fluctuate too much or need to much time to detect change. Henning Rogge From pthubert@cisco.com Mon Mar 1 02:17: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 493B03A8B49 for ; Mon, 1 Mar 2010 02:17:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n9d+RoRQLmLa for ; Mon, 1 Mar 2010 02:17:45 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id C4B0F28C2A4 for ; Mon, 1 Mar 2010 02:17:44 -0800 (PST) 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: AtQAAGMji0uQ/uCWe2dsb2JhbACbDRUBARYkBhyhYYppCIxUgmMIghAE X-IronPort-AV: E=Sophos;i="4.49,559,1262563200"; d="scan'208";a="57598200" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 01 Mar 2010 10:17: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 o21AHiaj018521; Mon, 1 Mar 2010 10:17:44 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, 1 Mar 2010 11:17:43 +0100 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, 1 Mar 2010 11:17:38 +0100 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D01594683@XMB-AMS-107.cisco.com> In-Reply-To: <4B8B0A9B.3020005@acm.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] Roll Digest, Vol 25, Issue 46 (follow up on point to point routing into a DAG where the destination is at lower rank) Thread-Index: Acq41mAotpgGVizHS+ifknq9uN5jDwAUBc5g References: <6A2A459175DABE4BB11DE2026AA50A5D0151C08B@XMB-AMS-107.cisco.com><054001cab646$432d5210$c987f630$@sturek@att.net> <4B8B0A9B.3020005@acm.org> From: "Pascal Thubert (pthubert)" To: "Tim Winter" , X-OriginalArrivalTime: 01 Mar 2010 10:17:43.0327 (UTC) FILETIME=[6E4422F0:01CAB928] Cc: ROLL WG Subject: Re: [Roll] Roll Digest, Vol 25, Issue 46 (follow up on point to point routing into a DAG where the destination is at lower rank) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 01 Mar 2010 10:17:46 -0000 Hi Tim and Don: I'm so sorry I failed to answer earlier. =20 Don: Tim is correct throughout. If your use case permits to store DAO states and the associated routes, you should never see a routing header with RPL as it stands. We need to improve our language on source route. In short, support would be mandatory but usage a case by case deployment decision, with probably some heuristics in the implementations to decide when to use it, for which destinations, etc.=20 Tim: About you first point on RH in the infrastructure. You're correct with the current model where the RPL routes are redistributed (hopefully in an aggregated fashion) by the roots; but when we couple RPL with mobility that might not be so anymore, in particular if mobile addresses are injected in RPL, or if the RPL mesh is built off ULAs. That day, I expect a routing header in the infra to get from afar to the root using infrastructure routing and then from the root to device, using RPL routing. You'll find information on how that could work in http://tools.ietf.org/html/draft-thubert-nemo-reverse-routing-header.=20 Cheers, Pascal -----Original Message----- From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Tim Winter Sent: Monday, March 01, 2010 1:30 AM To: d.sturek@att.net Cc: ROLL WG Subject: Re: [Roll] Roll Digest, Vol 25, Issue 46 (follow up on point to point routing into a DAG where the destination is at lower rank) Hi Don, Don Sturek wrote: > Hi Pascal, >=20 > One additional question: If I am routing from outside the DAG to a device > in the DAG at a rank that is not the DAG root, is source routing required? > I had thought with the right selection of RA/RS and storage within the > devices in the DAG it was possible to support this scenario without source > routing. Could you or someone in the DT answer this? >=20 > The issue is if source routing is required, we need to carefully review the > header sizes to see if this will actually work for our application. >=20 > Thanks, >=20 > Don Generally the idea is that traffic originating from outside the RPL domain and headed for a LLN destination inside the RPL domain would never need source routing on the outside of the RPL domain. When the traffic crosses into the RPL domain it may or may not need source routing as per the capabilities of the implementation. In the case where the nodes in the LLN store DAO state, as per the HW selection made by the implementation, then it may be possible that the traffic can traverse down the DODAG to the destination using only hop-by-hop routing state and without any additional modification to the traffic. In the case where not all of the nodes in the LLN are able to store DAO state, intermediate nodes will usually need to add source routing information to the traffic at the borders of the non-storing regions that the traffic must traverse. In the case where only the DAG root is capable of storing any DAO state, then the source routing information would be added at the DAG root as the traffic enters the RPL domain. The design decisions made in RPL thus far try to take into account the capabilities of both storing and non-storing nodes. The exact mechanism to bind source routing information on to the data traffic is still to be determined. Related mechanisms such as address compression and/or the use of tags/labels to mitigate the impact on header sizes have also been suggested by various members of the WG. Regards, -Tim _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From marcello.caleffi@unina.it Mon Mar 1 07:18: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 AC30228C324; Mon, 1 Mar 2010 07:18:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.719 X-Spam-Level: X-Spam-Status: No, score=-0.719 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5pfayqsZ0w1Y; Mon, 1 Mar 2010 07:18:22 -0800 (PST) Received: from smtp2.unina.it (smtp2.unina.it [192.132.34.62]) by core3.amsl.com (Postfix) with ESMTP id 5903A3A8B6E; Mon, 1 Mar 2010 07:18:22 -0800 (PST) Received: from [143.225.97.243] ([143.225.97.243]) (authenticated bits=0) by smtp2.unina.it (8.14.0/8.14.0) with ESMTP id o21FICWM023403 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 1 Mar 2010 16:18:13 +0100 Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Marcello Caleffi In-Reply-To: <201002282158.35975.hrogge@googlemail.com> Date: Mon, 1 Mar 2010 16:18:12 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <06604817-FD05-4213-8F5B-9895553C316F@unina.it> References: <20100223045634.C3F6328C44F@core3.amsl.com> <201002281212.54577.hrogge@googlemail.com> <201002282158.35975.hrogge@googlemail.com> To: Henning Rogge X-Mailer: Apple Mail (2.1077) X-Virus-Scanned: ClamAV 0.94.1/10471/Mon Mar 1 04:59:27 2010 on smtp2.unina.it X-Virus-Status: Clean X-Mailman-Approved-At: Mon, 01 Mar 2010 07:44:27 -0800 Cc: ROLL WG , manet@ietf.org, 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: Mon, 01 Mar 2010 15:18:23 -0000 Il giorno 28/feb/2010, alle ore 21.58, Henning Rogge ha scritto: > Am Sonntag 28 Februar 2010 12:33:49 schrieb Marcello Caleffi: >> We should discuss about it. Honestly, I don't know if the = post-processing >> can be independent from the metric dimension, but it will be a nice = idea. > I'm convinced it can be done, especially if the range of raw metric = would be > known (0 to 2^24-1 for example). Sliding-Window averaging, exponential = aging,=20 > even hysteresis could be considered postprocessing of the raw link = value, not=20 > depending what data is represented by the link. >=20 > It's similar to ripples objective function I think, just with a little = bit=20 > more options. Of coures you can adopt a blind filtering, however my studies shows that = not only the type of raw metric (i.e. rss versus delivery ratios) but = also the environment conditions affects the wellness of the filtering. = Just as example, if we assume that the shadow-fading effects are the = main hostile component in packet delivery, the moving average = (Sliding-Window averaging) is the best estimator (trust me, you cannot = do better). Otherwise, in presence of correlated hostile effects (i.e. = interference or collision in burst networks or node mobility), then = exponential aging can (can, since it depends on the parameter setting) = outperforms the sliding windows one. >=20 >> It was not my intention to discuss against your draft. Until we move >> towards realistic hypothesis, I am in. > Okay. >=20 >> But since there are multiple >> bi-directional connections among the topics: << I want a routing = protocol >> that works also in non-trivial networks <---> routing protocols = forward >> the packets according to routing metrics <---> I need a good routing >> metric <---> routing metric usually estimates random processes like >> delivery ratio or round trip time > Packet loss/error rate, delay and bandwith... that are the most common = three=20 > generic metric values I think. Signal strength might be a forth one. Both these metrics are random processes. Therefore if one wants deal = with routing metric, it is better for him to make a little knowledge = about random processes and stochastic theory. Or at least, I need to. >=20 >> <---> I need a good estimator >> here I >> am just exploiting the opportunity provided by your draft to discuss = some >> issues outside from my research group. > If you have a good idea how to "smooth/stabilize" the output of a = packet loss=20 > measurement without sacrificing lot's of reaction time of the metric I = would=20 > be very interested. > The problem with many routing metrics is that they either fluctuate = too much=20 > or need to much time to detect change. Just a self citation, but there are a lot of other (and better) works = about such a topic: = http://ieeexplore.ieee.org/xpls/abs_all.jsp?isnumber=3D5282393&arnumber=3D= 5282423&count=3D99&index=3D84&tag=3D1 Marcello= From alexandru.petrescu@gmail.com Mon Mar 1 08:25: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 0713C3A8AB5 for ; Mon, 1 Mar 2010 08:25:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7gpkUQTw12wf for ; Mon, 1 Mar 2010 08:25:42 -0800 (PST) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.1]) by core3.amsl.com (Postfix) with ESMTP id 00C593A87DB for ; Mon, 1 Mar 2010 08:25:41 -0800 (PST) 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 o21GPXAS023552 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 1 Mar 2010 17:25:33 +0100 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.2/8.14.2) with ESMTP id o21GPXox018749; Mon, 1 Mar 2010 17:25:33 +0100 (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 o21GPWbw022357; Mon, 1 Mar 2010 17:25:33 +0100 Message-ID: <4B8BEA7C.9040401@gmail.com> Date: Mon, 01 Mar 2010 17:25:32 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.9.1.7) Gecko/20100111 Thunderbird/3.0.1 MIME-Version: 1.0 To: MiJeom Kim References: <01f301cab4b7$1cecdb60$56c69220$@com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: Yoav Ben-Yehezkel , roll@ietf.org Subject: Re: [Roll] [roll] #18: Numeric Ranges in Routing Metric X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 01 Mar 2010 16:25:43 -0000 Le 26/02/2010 09:32, MiJeom Kim a écrit : > Hi, > > To summarize up to now, for latency metric, > > 1. Better to express both in millisecond and microsecond Well I'd say better to express in micro-second and not in millisecond. I'd avoid an encoding like "3milli-seconds and 2micro-seconds" and prefer an encoding saying "3002 milli-seconds", for the same value. > 2. 2 bytes may be enough Probably. Do we have an idea of bounds? What's the fastest link out there? (6Gbps? OC optical)? What's the slowest link? (150baud?) (yes people mentioned about devices with links with latency in the order of seconds, which I have yet to see. But is that the link latency? Or does it include the computer latency? What's 'link latency anyways and at which layer is it measured (PHY, MAC, IP, app?) These questions are commonly raised when measuring links.) > 3. Floating point needs to be avoided Somehow yes, I guess floating point is not necessary for encoding bandwidth if we go with micro-second precision. > So how about using 2 bytes with the first bit to express the unit > (millisecond or microsecond) and the rest 15 bits for the value > (unsigned integer)? I don't understand why 15bits - what's one bit left for (the one up to 16)? If we say "unsigned" then no need for sign bit. I am not sure what you mean by 15bits and not 16. ' > And for throughput, for simplicity, how about using bytes per second > presented by unsigned integer using 32 bits? That is my first > suggestion. I think that's ok for bandwidth. > Regarding baud, I meant that given the same bandwidth, changing > modulation methods (e.g. BPSK or QPSK) changes baud rate, but not > bytes per second. So we may need to encode a 1bit value saying BPSK or QPSK? The baud suggestion (in addition to bandwidth of faster links) is that because baud is typically used on slow links. Alex From alexandru.petrescu@gmail.com Mon Mar 1 09:43: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 EFEFD28C45F for ; Mon, 1 Mar 2010 09:43:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C1caFSi3SISC for ; Mon, 1 Mar 2010 09:43:31 -0800 (PST) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.166.172.106]) by core3.amsl.com (Postfix) with ESMTP id EEEE128C459 for ; Mon, 1 Mar 2010 09:43:30 -0800 (PST) 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 o21HhNYM030063 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 1 Mar 2010 18:43:23 +0100 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (8.14.2/8.14.2) with ESMTP id o21HhNQO031749; Mon, 1 Mar 2010 18:43:23 +0100 (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 o21HhMS6022111; Mon, 1 Mar 2010 18:43:22 +0100 Message-ID: <4B8BFCBA.2060500@gmail.com> Date: Mon, 01 Mar 2010 18:43:22 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.9.1.7) Gecko/20100111 Thunderbird/3.0.1 MIME-Version: 1.0 To: Alexandru Petrescu References: <01f301cab4b7$1cecdb60$56c69220$@com> <4B8BEA7C.9040401@gmail.com> In-Reply-To: <4B8BEA7C.9040401@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: Yoav Ben-Yehezkel , roll@ietf.org Subject: Re: [Roll] [roll] #18: Numeric Ranges in Routing Metric X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 01 Mar 2010 17:43:32 -0000 Le 01/03/2010 17:25, Alexandru Petrescu a écrit : > Le 26/02/2010 09:32, MiJeom Kim a écrit : >> Hi, >> >> To summarize up to now, for latency metric, >> >> 1. Better to express both in millisecond and microsecond > > Well I'd say better to express in micro-second and not in millisecond. > I'd avoid an encoding like "3milli-seconds and 2micro-seconds" and > prefer an encoding saying "3002 milli-seconds", for the same value. ^^^^^ Sorry, I obviously meant 3002 micro-seconds. Alex > >> 2. 2 bytes may be enough > > Probably. > > Do we have an idea of bounds? What's the fastest link out there? > (6Gbps? OC optical)? What's the slowest link? (150baud?) > > (yes people mentioned about devices with links with latency in the > order of seconds, which I have yet to see. But is that the link > latency? Or does it include the computer latency? What's 'link > latency anyways and at which layer is it measured (PHY, MAC, IP, > app?) These questions are commonly raised when measuring links.) > >> 3. Floating point needs to be avoided > > Somehow yes, I guess floating point is not necessary for encoding > bandwidth if we go with micro-second precision. > >> So how about using 2 bytes with the first bit to express the unit >> (millisecond or microsecond) and the rest 15 bits for the value >> (unsigned integer)? > > I don't understand why 15bits - what's one bit left for (the one up to > 16)? If we say "unsigned" then no need for sign bit. I am not sure > what you mean by 15bits and not 16. > ' >> And for throughput, for simplicity, how about using bytes per second >> presented by unsigned integer using 32 bits? That is my first >> suggestion. > > I think that's ok for bandwidth. > >> Regarding baud, I meant that given the same bandwidth, changing >> modulation methods (e.g. BPSK or QPSK) changes baud rate, but not >> bytes per second. > > So we may need to encode a 1bit value saying BPSK or QPSK? > > The baud suggestion (in addition to bandwidth of faster links) is that > because baud is typically used on slow links. > > Alex > > From gnawali@cs.stanford.edu Mon Mar 1 11:57: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 D3E7E28C184; Mon, 1 Mar 2010 11:57:18 -0800 (PST) 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 jeLZMZoFsgJv; Mon, 1 Mar 2010 11:57:17 -0800 (PST) Received: from cs-smtp-2.Stanford.EDU (cs-smtp-2.Stanford.EDU [171.64.64.26]) by core3.amsl.com (Postfix) with ESMTP id 843D83A8AED; Mon, 1 Mar 2010 11:57:17 -0800 (PST) Received: from mail-qy0-f195.google.com ([209.85.221.195]) by cs-smtp-2.Stanford.EDU with esmtpsa (TLSv1:RC4-MD5:128) (Exim 4.60) (envelope-from ) id 1NmBjx-0007UR-T2; Mon, 01 Mar 2010 11:57:18 -0800 Received: by qyk33 with SMTP id 33so1726397qyk.17 for ; Mon, 01 Mar 2010 11:57:16 -0800 (PST) MIME-Version: 1.0 Received: by 10.224.73.35 with SMTP id o35mr2108879qaj.386.1267473436772; Mon, 01 Mar 2010 11:57:16 -0800 (PST) In-Reply-To: <06604817-FD05-4213-8F5B-9895553C316F@unina.it> References: <20100223045634.C3F6328C44F@core3.amsl.com> <201002281212.54577.hrogge@googlemail.com> <201002282158.35975.hrogge@googlemail.com> <06604817-FD05-4213-8F5B-9895553C316F@unina.it> From: Omprakash Gnawali Date: Mon, 1 Mar 2010 11:56:56 -0800 Message-ID: To: Marcello Caleffi Content-Type: text/plain; charset=ISO-8859-1 X-Scan-Signature: a11a15d02c0ec4233875b3872b0caebb Cc: ROLL WG , manet@ietf.org, 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: Mon, 01 Mar 2010 19:57:18 -0000 On Mon, Mar 1, 2010 at 7:18 AM, Marcello Caleffi wrote: ... >>> <---> I need a good estimator >> here I >>> am just exploiting the opportunity provided by your draft to discuss some >>> issues outside from my research group. >> If you have a good idea how to "smooth/stabilize" the output of a packet loss >> measurement without sacrificing lot's of reaction time of the metric I would >> be very interested. >> The problem with many routing metrics is that they either fluctuate too much >> or need to much time to detect change. > > Just a self citation, but there are a lot of other (and better) works about such a topic: > http://ieeexplore.ieee.org/xpls/abs_all.jsp?isnumber=5282393&arnumber=5282423&count=99&index=84&tag=1 Interesting approach. I would be curious to know if these ideas have been used in practice (in experimental testbeds or deployments). Have people found issues with the traditional ETX metric estimation and maintenance in their deployments and experiments? Those would be the things to avoid in our recommendation on how to compute these metrics. - om_p From dominique.barthel@orange-ftgroup.com Mon Mar 1 13:10: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 3826D28C52F for ; Mon, 1 Mar 2010 13:10:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.248 X-Spam-Level: X-Spam-Status: No, score=-3.248 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-1, 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 2zTe8npFHKNR for ; Mon, 1 Mar 2010 13:10:51 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by core3.amsl.com (Postfix) with ESMTP id 7498B28C1D4 for ; Mon, 1 Mar 2010 13:10:40 -0800 (PST) Received: from omfedm06.si.francetelecom.fr (unknown [xx.xx.xx.2]) by omfedm14.si.francetelecom.fr (ESMTP service) with ESMTP id A5C80105744; Mon, 1 Mar 2010 22:10:39 +0100 (CET) Received: from ftrdsmtp1.rd.francetelecom.fr (unknown [10.192.128.46]) by omfedm06.si.francetelecom.fr (ESMTP service) with ESMTP id 8993A27C074; Mon, 1 Mar 2010 22:10:39 +0100 (CET) Received: from ftrdmel0.rd.francetelecom.fr ([10.192.128.56]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Mon, 1 Mar 2010 22:10:18 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 1 Mar 2010 22:09:23 +0100 Message-ID: <24939_1267477839_4B8C2D4F_24939_241_1_8E09C72DBC577D489F13A71228C0B7BFFD45F1@ftrdmel0.rd.francetelecom.fr> In-Reply-To: <4B8BEA7C.9040401@gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] [roll] #18: Numeric Ranges in Routing Metric Thread-Index: Acq5W9keWfLh7r8CTQOTYg7Yx/qYHgAG7PaQ References: <01f301cab4b7$1cecdb60$56c69220$@com> <4B8BEA7C.9040401@gmail.com> From: To: , X-OriginalArrivalTime: 01 Mar 2010 21:10:18.0571 (UTC) FILETIME=[989C39B0:01CAB983] X-PMX-Version: 5.5.7.378829, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2010.2.3.124223 Cc: yoav@yitran.com, roll@ietf.org Subject: Re: [Roll] [roll] #18: Numeric Ranges in Routing Metric X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 01 Mar 2010 21:10:57 -0000 Hi all, Since you are calling for other's opinions, let me chime in here with my 2 = cents. I believe Floating Point, or any variation thereof (exponential representat= ion, etc), is a pain for addition and for non-strict monotonicity reasons, = as was already mentioned by Phil ( A + B =3D A when B > 0 ). I believe we shouldn't worry about latencies less than about 10 us, because - whatever the radio throughput (even megabits per second), the Rx-Tx turna= round time is still a few microseconds, the Carrier Sensing is many microse= conds, and you usually need these to randomly send packets to your neighbors - even at megabits/s speed, transmitting one useful data bit still requires= several hundreds of framing/synch/control/correction bits, which translate= s to a latency of many microseconds - many other, unpredictable, events cause latencies of that magnitude : med= ium access contention, microcontroller interrupt processing time Sleeping MACs I've been exposed to commonly have wake-up periods of up to a= few seconds. Ten seconds seems to be an extreme case. This means random pa= thes across the network would take n times a few seconds for n hops, given = a reasonable ETX. If 10 hops is a reasonably long path, then about one minu= te of latency would cover all interesting cases. >From one full minute downto a quantum of 10 microseconds, this means we nee= d 22 bits with an uniform integer representation. How about a 3-byte unsigned integer, expressing latency in units of 10us? 3 bytes seems like an odd size, but we already have a 3 byte routing object= header (Object Type | Flags | Length), so it actually improves alignement = ;-) Regarding baud rates, I suggest to leave this to the Electrical Engineers. = IETF shouldn't even know about modulation, electrical symbols and baud rate= s. For large packets, bit rate and/or MAC wake-up period will determine latenc= y. Modulation and spectral bandwith will only impact some delays (turn-arou= nd time, carrier sensing) that are marginal and better described with a con= stant than explicited in an IETF RFC. Dominique The reason why old link technologies (100, 150, 300) are = still refered to by their baud rates is because they placed one bit per sym= bol, ie bit rates were equal to baud rates, hence users would say "baud" as= a fancy term for "bits per second". As PSTN modem technology evolved, bit = rates grew (4800, 9600) while maintaining baud rates low (1200, 2400), beca= use baud rate translates to spectral (audio) bandwith which was contrained = by the telephone line technology. -----Message d'origine----- De : roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] De la part de Ale= xandru Petrescu Envoy=E9 : lundi 1 mars 2010 17:26 =C0 : MiJeom Kim Cc : Yoav Ben-Yehezkel; roll@ietf.org Objet : Re: [Roll] [roll] #18: Numeric Ranges in Routing Metric Le 26/02/2010 09:32, MiJeom Kim a =E9crit : > Hi, > > To summarize up to now, for latency metric, > > 1. Better to express both in millisecond and microsecond Well I'd say better to express in micro-second and not in millisecond. I'd avoid an encoding like "3milli-seconds and 2micro-seconds" and prefer a= n encoding saying "3002 milli-seconds", for the same value. > 2. 2 bytes may be enough Probably. Do we have an idea of bounds? What's the fastest link out there? (6Gbps? OC optical)? What's the slowest link? (150baud?) (yes people mentioned about devices with links with latency in the order of seconds, which I have yet to see. But is that the link latency? Or does it include the computer latency? What's 'link latency anyways and at which layer is it measured (PHY, MAC, IP, app?) These questions are commonly raised when measuring links.) > 3. Floating point needs to be avoided Somehow yes, I guess floating point is not necessary for encoding bandwidth= if we go with micro-second precision. > So how about using 2 bytes with the first bit to express the unit=20 > (millisecond or microsecond) and the rest 15 bits for the value=20 > (unsigned integer)? I don't understand why 15bits - what's one bit left for (the one up to 16)?= If we say "unsigned" then no need for sign bit. I am not sure what you m= ean by 15bits and not 16. ' > And for throughput, for simplicity, how about using bytes per second=20 > presented by unsigned integer using 32 bits? That is my first=20 > suggestion. I think that's ok for bandwidth. > Regarding baud, I meant that given the same bandwidth, changing=20 > modulation methods (e.g. BPSK or QPSK) changes baud rate, but not=20 > bytes per second. So we may need to encode a 1bit value saying BPSK or QPSK? The baud suggestion (in addition to bandwidth of faster links) is that beca= use baud is typically used on slow links. Alex _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll ********************************* This message and any attachments (the "message") are confidential and inten= ded solely for the addressees.=20 Any unauthorised use or dissemination is prohibited. Messages are susceptible to alteration.=20 France Telecom Group shall not be liable for the message if altered, change= d or falsified. If you are not the intended addressee of this message, please cancel it imm= ediately and inform the sender. ******************************** From jvasseur@cisco.com Mon Mar 1 13:22: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 6C40A28C1C8 for ; Mon, 1 Mar 2010 13:22:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q+DGmKJY+Hem for ; Mon, 1 Mar 2010 13:22:58 -0800 (PST) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 15DCF28C1C5 for ; Mon, 1 Mar 2010 13:22:58 -0800 (PST) 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: AgUFAD+/i0utJV2b/2dsb2JhbACBQplFc6VXl2qCT4IsBA X-IronPort-AV: E=Sophos;i="4.49,562,1262563200"; d="scan'208,217";a="89813668" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rtp-iport-2.cisco.com with ESMTP; 01 Mar 2010 21:22:57 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by rcdn-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id o21LMtKJ013968 for ; Mon, 1 Mar 2010 21:22:57 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); Mon, 1 Mar 2010 22:22:55 +0100 Received: from ams-jvasseur-8713.cisco.com ([10.55.201.132]) by xfe-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 1 Mar 2010 22:22:55 +0100 Message-Id: <93806249-BA5A-481E-9D61-2F5878F2D386@cisco.com> From: JP Vasseur To: ROLL WG Content-Type: multipart/alternative; boundary=Apple-Mail-70--747247372 Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 1 Mar 2010 20:04:04 +0100 X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 01 Mar 2010 21:22:55.0227 (UTC) FILETIME=[5B9CC4B0:01CAB985] Subject: [Roll] ROLL WG Meeting X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Mar 2010 21:22:59 -0000 --Apple-Mail-70--747247372 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit The agenda is now confirmed: MONDAY, March 22, 2010 1740-1940 Afternoon Session III California A APP alto Application-Layer Traffic Optimization WG Huntington APP eai Email Address Internationalization WG California D INT csi Cga & Send maIntenance WG Palos Verdes IRTF hiprg Host Identity Protocol Redondo OPS radext RADIUS EXTensions WG California C RAI codec Internet Wideband Audio Codec WG Manhattan RTG forces Forwarding and Control Element Separation WG California B RTG roll Routing Over Low power and Lossy networks W --Apple-Mail-70--747247372 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable The agenda is now = confirmed:

<= td style=3D"padding-top: 0.1em; padding-right: 0.5em; padding-bottom: = 0.1em; padding-left: 0.5em; margin-top: 0em; margin-right: 0em; = margin-bottom: 0em; margin-left: 0em; vertical-align: top; = border-top-style: none; border-right-style: none; border-bottom-style: = none; border-left-style: none; border-top-width: 0em; = border-right-width: 0em; border-bottom-width: 0em; border-left-width: = 0em; border-collapse: collapse; text-align: left; font-size: 0.9em; = ">Email Address Internationalization WG<= td style=3D"padding-top: 0.1em; padding-right: 0.5em; padding-bottom: = 0.1em; padding-left: 0.5em; margin-top: 0em; margin-right: 0em; = margin-bottom: 0em; margin-left: 0em; vertical-align: top; = border-top-style: none; border-right-style: none; border-bottom-style: = none; border-left-style: none; border-top-width: 0em; = border-right-width: 0em; border-bottom-width: 0em; border-left-width: = 0em; border-collapse: collapse; text-align: left; font-size: 0.9em; = ">Cga & Send maIntenance WG

MONDAY, March 22, = 2010


Califo= rnia AAPPaltoHuntingt= onAPPeai
Califo= rnia DINTcsi
Palos = VerdesIRTFhiprgHost Identity Protocol
Redondo= OPSradext= RADIUS EXTensions WG
Califo= rnia CRAIcodecInternet Wideband Audio Codec WG
Manhattan= RTGforces= Forwarding and Control Element Separation = WG
Califo= rnia BRTGroll wrote: > Le 26/02/2010 09:32, MiJeom Kim a =E9crit : >> >> Hi, >> >> To summarize up to now, for latency metric, >> >> 1. Better to express both in millisecond and microsecond > > Well I'd say better to express in micro-second and not in millisecond. > I'd avoid an encoding like "3milli-seconds and 2micro-seconds" and > prefer an encoding saying "3002 milli-seconds", for the same value. > >> 2. 2 bytes may be enough > > Probably. > > Do we have an idea of bounds? =A0What's the fastest link out there? > (6Gbps? OC optical)? =A0What's the slowest link? =A0(150baud?) > > (yes people mentioned about devices with links with latency in the > =A0order of seconds, which I have yet to see. =A0But is that the link > =A0latency? =A0Or does it include the computer latency? =A0What's 'link > =A0latency anyways and at which layer is it measured (PHY, MAC, IP, > =A0app?) =A0These questions are commonly raised when measuring links.) > >> 3. Floating point needs to be avoided > > Somehow yes, I guess floating point is not necessary for encoding > bandwidth if we go with micro-second precision. > >> So how about using 2 bytes with the first bit to express the unit >> (millisecond or microsecond) and the rest 15 bits for the value >> (unsigned integer)? > > I don't understand why 15bits - what's one bit left for (the one up to > 16)? =A0If we say "unsigned" then no need for sign bit. =A0I am not sure > what you mean by 15bits and not 16. > ' >> >> And for throughput, for simplicity, how about using bytes per second >> presented by unsigned integer using 32 bits? That is my first >> suggestion. > > I think that's ok for bandwidth. > >> Regarding baud, I meant that given the same bandwidth, changing >> modulation methods (e.g. BPSK or QPSK) changes baud rate, but not >> bytes per second. > > So we may need to encode a 1bit value saying BPSK or QPSK? > > The baud suggestion (in addition to bandwidth of faster links) is that > because baud is typically used on slow links. > > Alex > > From alexandru.petrescu@gmail.com Tue Mar 2 09:04: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 0B93E28C1DA for ; Tue, 2 Mar 2010 09:04:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b2PiMAaqPpaU for ; Tue, 2 Mar 2010 09:04:17 -0800 (PST) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.1]) by core3.amsl.com (Postfix) with ESMTP id A432A28C1D7 for ; Tue, 2 Mar 2010 09:04:16 -0800 (PST) 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 o22H4Fmq009160 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 2 Mar 2010 18:04:15 +0100 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.2/8.14.2) with ESMTP id o22H4EWU006317; Tue, 2 Mar 2010 18:04:14 +0100 (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 o22H4Ell014532; Tue, 2 Mar 2010 18:04:14 +0100 Message-ID: <4B8D450E.80706@gmail.com> Date: Tue, 02 Mar 2010 18:04:14 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.9.1.7) Gecko/20100111 Thunderbird/3.0.1 MIME-Version: 1.0 To: dominique.barthel@orange-ftgroup.com References: <01f301cab4b7$1cecdb60$56c69220$@com> <4B8BEA7C.9040401@gmail.com> <24939_1267477839_4B8C2D4F_24939_241_1_8E09C72DBC577D489F13A71228C0B7BFFD45F1@ftrdmel0.rd.francetelecom.fr> In-Reply-To: <24939_1267477839_4B8C2D4F_24939_241_1_8E09C72DBC577D489F13A71228C0B7BFFD45F1@ftrdmel0.rd.francetelecom.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: yoav@yitran.com, roll@ietf.org Subject: Re: [Roll] about the historical note and the fashionability of baud rate (Was: [roll] #18: Numeric Ranges in Routing Metric) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 02 Mar 2010 17:04:18 -0000 :-) Le 01/03/2010 22:09, dominique.barthel@orange-ftgroup.com a écrit : [...] > Regarding baud rates, I suggest to leave this to the Electrical > Engineers. IETF shouldn't even know about modulation, electrical > symbols and baud rates. For large packets, bit rate and/or MAC > wake-up period will determine latency. Modulation and spectral > bandwith will only impact some delays (turn-around time, carrier > sensing) that are marginal and better described with a constant than > explicited in an IETF RFC. WEll, yes, it's good to leave these specs to specialized Electrical Engineers; and a constant would be good too. Baud rates I've seen are expressed as doubling the pervious value: 150baud, 300baud, 600baud, etc. There's no intermediary value like 351baud. I guess we could encode them all as: 1 (for 75), 2 (for 150), 3 (for 300), and so on. As a side note - I think baudrates are very fashionable :-) I just stumbled on a recent small device guaranteed to run up to 10years autonomously on one AA-sized battery (thyonil is that?); it can be queried by a laptop-USB and to which I must set the baudrate. Also I have seen a device for which I had 4800baud over bluetooth and another real recent - 38400baud. That's what these thre user manuals asked me to do: set the baud rate. The COM port specifications on Vista(!) are baud rate, stop bits,... Alex > > > Dominique > > The reason why old link technologies (100, 150, > 300) are still refered to by their baud rates is because they placed > one bit per symbol, ie bit rates were equal to baud rates, hence > users would say "baud" as a fancy term for "bits per second". As > PSTN modem technology evolved, bit rates grew (4800, 9600) while > maintaining baud rates low (1200, 2400), because baud rate > translates to spectral (audio) bandwith which was contrained by the > telephone line technology. > > -----Message d'origine----- De : roll-bounces@ietf.org > [mailto:roll-bounces@ietf.org] De la part de Alexandru Petrescu > Envoyé : lundi 1 mars 2010 17:26 À : MiJeom Kim Cc : Yoav > Ben-Yehezkel; roll@ietf.org Objet : Re: [Roll] [roll] #18: Numeric > Ranges in Routing Metric > > Le 26/02/2010 09:32, MiJeom Kim a écrit : >> Hi, >> >> To summarize up to now, for latency metric, >> >> 1. Better to express both in millisecond and microsecond > > Well I'd say better to express in micro-second and not in > millisecond. I'd avoid an encoding like "3milli-seconds and > 2micro-seconds" and prefer an encoding saying "3002 milli-seconds", > for the same value. > >> 2. 2 bytes may be enough > > Probably. > > Do we have an idea of bounds? What's the fastest link out there? > (6Gbps? OC optical)? What's the slowest link? (150baud?) > > (yes people mentioned about devices with links with latency in the > order of seconds, which I have yet to see. But is that the link > latency? Or does it include the computer latency? What's 'link > latency anyways and at which layer is it measured (PHY, MAC, IP, > app?) These questions are commonly raised when measuring links.) > >> 3. Floating point needs to be avoided > > Somehow yes, I guess floating point is not necessary for encoding > bandwidth if we go with micro-second precision. > >> So how about using 2 bytes with the first bit to express the unit >> (millisecond or microsecond) and the rest 15 bits for the value >> (unsigned integer)? > > I don't understand why 15bits - what's one bit left for (the one up > to 16)? If we say "unsigned" then no need for sign bit. I am not > sure what you mean by 15bits and not 16. ' >> And for throughput, for simplicity, how about using bytes per >> second presented by unsigned integer using 32 bits? That is my >> first suggestion. > > I think that's ok for bandwidth. > >> Regarding baud, I meant that given the same bandwidth, changing >> modulation methods (e.g. BPSK or QPSK) changes baud rate, but not >> bytes per second. > > So we may need to encode a 1bit value saying BPSK or QPSK? > > The baud suggestion (in addition to bandwidth of faster links) is > that because baud is typically used on slow links. > > Alex > > _______________________________________________ Roll mailing list > Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll > > ********************************* This message and any attachments > (the "message") are confidential and intended solely for the > addressees. Any unauthorised use or dissemination is prohibited. > Messages are susceptible to alteration. France Telecom Group shall > not be liable for the message if altered, changed or falsified. If > you are not the intended addressee of this message, please cancel it > immediately and inform the sender. ******************************** > > From alexandru.petrescu@gmail.com Tue Mar 2 09:05: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 AF5AC3A87DF for ; Tue, 2 Mar 2010 09:05:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5z3-SyaPzLsZ for ; Tue, 2 Mar 2010 09:05:54 -0800 (PST) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.166.172.106]) by core3.amsl.com (Postfix) with ESMTP id 9FB783A87C7 for ; Tue, 2 Mar 2010 09:05:54 -0800 (PST) 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 o22H5r0G031595 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 2 Mar 2010 18:05:53 +0100 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.2/8.14.2) with ESMTP id o22H5rHx006608; Tue, 2 Mar 2010 18:05:53 +0100 (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 o22H5qFq015002; Tue, 2 Mar 2010 18:05:53 +0100 Message-ID: <4B8D4570.8080402@gmail.com> Date: Tue, 02 Mar 2010 18:05:52 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.9.1.7) Gecko/20100111 Thunderbird/3.0.1 MIME-Version: 1.0 To: MiJeom Kim References: <01f301cab4b7$1cecdb60$56c69220$@com> <4B8BEA7C.9040401@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: roll@ietf.org Subject: Re: [Roll] [roll] #18: Numeric Ranges in Routing Metric X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 02 Mar 2010 17:05:55 -0000 Le 02/03/2010 08:49, MiJeom Kim a écrit : > Hi, Alex, > > I didn't mean to encode like "3milli-seconds and 2micro-seconds". I > suggested using 16 bits with 1 bit to indicate millisecond or > microsecond. Thus, using 15 bits for actual value. For example, if > the indication bit is 1, the rest 15 bits is used for the value of > millisecond. Otherwise, if the indication bit is 0, the 15 bits is > for the value of microsecond. This is pretty reasonable when the > spectrum of the metric value is way to wide as already mentioned > several times. Ah, in this sense I understand that 1/0 bit. The only thing left is to ensure this encoding does cover appropriately the range of values we know we need. Alex > > Mijeom. > > On Tue, Mar 2, 2010 at 1:25 AM, Alexandru Petrescu > wrote: >> Le 26/02/2010 09:32, MiJeom Kim a écrit : >>> >>> Hi, >>> >>> To summarize up to now, for latency metric, >>> >>> 1. Better to express both in millisecond and microsecond >> >> Well I'd say better to express in micro-second and not in >> millisecond. I'd avoid an encoding like "3milli-seconds and >> 2micro-seconds" and prefer an encoding saying "3002 milli-seconds", >> for the same value. >> >>> 2. 2 bytes may be enough >> >> Probably. >> >> Do we have an idea of bounds? What's the fastest link out there? >> (6Gbps? OC optical)? What's the slowest link? (150baud?) >> >> (yes people mentioned about devices with links with latency in the >> order of seconds, which I have yet to see. But is that the link >> latency? Or does it include the computer latency? What's 'link >> latency anyways and at which layer is it measured (PHY, MAC, IP, >> app?) These questions are commonly raised when measuring links.) >> >>> 3. Floating point needs to be avoided >> >> Somehow yes, I guess floating point is not necessary for encoding >> bandwidth if we go with micro-second precision. >> >>> So how about using 2 bytes with the first bit to express the >>> unit (millisecond or microsecond) and the rest 15 bits for the >>> value (unsigned integer)? >> >> I don't understand why 15bits - what's one bit left for (the one up >> to 16)? If we say "unsigned" then no need for sign bit. I am not >> sure what you mean by 15bits and not 16. ' >>> >>> And for throughput, for simplicity, how about using bytes per >>> second presented by unsigned integer using 32 bits? That is my >>> first suggestion. >> >> I think that's ok for bandwidth. >> >>> Regarding baud, I meant that given the same bandwidth, changing >>> modulation methods (e.g. BPSK or QPSK) changes baud rate, but >>> not bytes per second. >> >> So we may need to encode a 1bit value saying BPSK or QPSK? >> >> The baud suggestion (in addition to bandwidth of faster links) is >> that because baud is typically used on slow links. >> >> Alex >> >> > From mijeom@gmail.com Tue Mar 2 21:28: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 5594E28C21C for ; Tue, 2 Mar 2010 21:28:28 -0800 (PST) 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 sZoLI9gm5d3t for ; Tue, 2 Mar 2010 21:28:27 -0800 (PST) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by core3.amsl.com (Postfix) with ESMTP id 71EC03A8C33 for ; Tue, 2 Mar 2010 21:28:27 -0800 (PST) Received: by pwi3 with SMTP id 3so709918pwi.31 for ; Tue, 02 Mar 2010 21:28:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=SwQpKCYtvQPhOe7q9jAdbBYjOXmSRDJ/ssTLR8YWpWk=; b=r6ZUpkFHNR939ioNXpUgc6w4iQjA5y0bbXwv57qsczgDchohLkclTEAfzErNj2fz7M +3qtLq5yCYP4lGLC5Ql3R/sM3TcQ/srMCcKjddfnVu8FnP9T5HikZuZcy0F4DyQEX34U 4ThevariGqdGJyg/ovraBMPIObJf3R5eXqwTU= 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=EoZ1fdsceqPOgwu47yVjd/5WPQlZBhDTiC6J8YkaFpGaIY/gdWswF1TcsoTaJICdNE 484i4T5tNQPXltdZN8fiHTG7OlhxYsNQih8zauBSfP78LrU0oUH9NzjrnsrewGeghRRR D53iDI0U3+2B4Y1gdiYq96AEpKQBVE9S5LL9Y= MIME-Version: 1.0 Received: by 10.142.118.26 with SMTP id q26mr4097658wfc.127.1267594106241; Tue, 02 Mar 2010 21:28:26 -0800 (PST) In-Reply-To: References: <055.a3c60804880e85f93fc1826167be4fb6@tools.ietf.org> <201002230913.47381.henning.rogge@fkie.fraunhofer.de> <201002231122.41069.henning.rogge@fkie.fraunhofer.de> Date: Wed, 3 Mar 2010 14:28:26 +0900 Message-ID: From: MiJeom Kim To: Omprakash Gnawali Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: roll@ietf.org Subject: Re: [Roll] [roll] #20: Question on Metric 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: Wed, 03 Mar 2010 05:28:28 -0000 Hi, It=E2=80=99s time to summarize. - ETX >=3D 1, and 100 is enough for Max ETX since more than 10 ETX is close to infinity. - 8 bits are enough but need to avoid floating point format. =EF=83=A8 good= to multiply with a constant factor (C) like 256 I think Henning=E2=80=99s suggestion is good. But we don=E2=80=99t need a b= ig range for ETX, but precision needs to be increased. So we can adjust it with 5 bit mantissa and 3 bit exponent. So, we can represent (ETX * C) as (32 + a) * 2^b where 0 <=3D a <=3D 31 and 0 <=3D b <=3D 7. If C is 128, the max possible ETX is 63 and if C is 64, the max ETX is 126. So let=E2=80=99s try C =3D 64 and if ETX is bigger = than 126, we can just make it the possible max which is 126. All the numbers can be adjustable again, so please settle down the issue with your ideas. I can=E2=80=99t understand the Overloading ETX thing. Nobody suggests overloading ETX, I think. What do you mean by that in this thread, Omprakash? Mijeom. On Wed, Feb 24, 2010 at 2:00 AM, Omprakash Gnawali wrote: > On Tue, Feb 23, 2010 at 2:22 AM, Henning Rogge > wrote: > .... >>> Does your bad experience related to metric representation from running >>> OLSR network have to do with metric precision? >> No, we discovered that we could not represent ethernet links (connecting >> multiple devices) better than a "perfect" wireless link in our metric >> encoding, so our routing agent prefers a single wireless link with some = packet >> loss over an ethernet-hop plus a perfect wireless link, which is BAD. >> >> It's a good idea to keep a little bit room for "better links". >> >> We use 1 byte for LQ with a factor of 255 to shift the floating point va= lue >> (0.0 - 1.0) into a pure integer one. It's very difficult to change the e= ncoding >> of the routing metric later without reinstalling the whole network at on= ce. > > Thanks for sharing this insight. We need to be aware of similar > scenarios also on LLNs. > > I think RPL's approach is to have different objective functions that > maximize/minimize or constrain different metrics, and even apply a > series of objective functions for path selection if desired. That > seems like a better approach than overloading many meanings to ETX. > Does OLSRv2 support different metrics such as data rates and energy? > If it does, are there still advantages to overloading ETX? > > - om_p > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > From henning.rogge@fkie.fraunhofer.de Tue Mar 2 23:05: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 7ADF128C14B for ; Tue, 2 Mar 2010 23:05:46 -0800 (PST) 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 QXj7hDPB0qgr for ; Tue, 2 Mar 2010 23:05:45 -0800 (PST) Received: from mailguard.fgan.de (mailguard.fkie.fraunhofer.de [128.7.3.5]) by core3.amsl.com (Postfix) with ESMTP id 4420E3A7DD9 for ; Tue, 2 Mar 2010 23:05:44 -0800 (PST) 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 1NmieE-0008OU-W8; Wed, 03 Mar 2010 08:05:35 +0100 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 1NmieD-00007G-T8; Wed, 03 Mar 2010 08:05:34 +0100 From: Henning Rogge To: MiJeom Kim Date: Wed, 3 Mar 2010 08:05:20 +0100 User-Agent: KMail/1.13.0 (Linux/2.6.31-17-generic; KDE/4.4.0; i686; ; ) References: <055.a3c60804880e85f93fc1826167be4fb6@tools.ietf.org> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart4434028.OsbrnA9iTm"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <201003030805.30679.henning.rogge@fkie.fraunhofer.de> X-Virus-Scanned: yes (ClamAV 0.95.3/10494/Wed Mar 3 05:52:46 2010) by mailguard.fgan.de X-Scan-Signature: 054ccd22e44c7b570fe3109fd6105c99 Cc: roll@ietf.org Subject: Re: [Roll] [roll] #20: Question on Metric 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: Wed, 03 Mar 2010 07:05:46 -0000 --nextPart4434028.OsbrnA9iTm Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On Wed March 3 2010 06:28:26 MiJeom Kim wrote: > Hi, >=20 > It=E2=80=99s time to summarize. >=20 > - ETX >=3D 1, and 100 is enough for Max ETX since more than 10 ETX is > close to infinity. > - 8 bits are enough but need to avoid floating point format. =EF=83=A8 go= od to > multiply with a constant factor (C) like 256 As soon as you move to ETT or MIC you need a higher range. Either you use a= =20 32-bit integer or floating point, otherwise Ripple will be unable to run wi= th=20 better metrics. > I think Henning=E2=80=99s suggestion is good. But we don=E2=80=99t need a= big range > for ETX, but precision needs to be increased. So we can adjust it with > 5 bit mantissa and 3 bit exponent. >=20 > So, we can represent (ETX * C) as (32 + a) * 2^b where 0 <=3D a <=3D 31 > and 0 <=3D b <=3D 7. If C is 128, the max possible ETX is 63 and if C is > 64, the max ETX is 126. So let=E2=80=99s try C =3D 64 and if ETX is bigge= r than > 126, we can just make it the possible max which is 126. >=20 > All the numbers can be adjustable again, so please settle down the > issue with your ideas. >=20 > I can=E2=80=99t understand the Overloading ETX thing. Nobody suggests > overloading ETX, I think. What do you mean by that in this thread, I suggest not to design your protocol for a single routing metric. That wou= ld=20 make Ripple inflexible and force you to change the message format later whe= n=20 you want to move to something better. Henning Rogge =2D-=20 Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=C3=BCr Kommunikation, Informationsverarbeitung und Ergonomie FKIE Kommunikationssysteme (KOM) Neuenahrer Stra=C3=9Fe 20, 53343 Wachtberg, Germany Telefon +49 228 9435-263, 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 --nextPart4434028.OsbrnA9iTm 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) iEYEABECAAYFAkuOCjAACgkQRIfGfFXsz+DQNACeOJOPeGbuSDffW9MvBagWSmg7 4PMAoI5wX84ROHKhHKpg1nZy8htImJhd =Bcks -----END PGP SIGNATURE----- --nextPart4434028.OsbrnA9iTm-- From pthubert@cisco.com Wed Mar 3 01:33: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 91BA028C2F9 for ; Wed, 3 Mar 2010 01:33:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=-4.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 s-y-Q-HhYgHx for ; Wed, 3 Mar 2010 01:33:30 -0800 (PST) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by core3.amsl.com (Postfix) with ESMTP id 0D3F928C2F8 for ; Wed, 3 Mar 2010 01:33:29 -0800 (PST) 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: AuQAANa7jUuQ/uCWe2dsb2JhbACDBZcnYBUBARYkBhyla4ghkCGBNIJdagQ X-IronPort-AV: E=Sophos;i="4.49,573,1262563200"; d="scan'208";a="3947749" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-2.cisco.com with ESMTP; 03 Mar 2010 09:00:51 +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 o239XU7o008978; Wed, 3 Mar 2010 09:33:30 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); Wed, 3 Mar 2010 10:33:30 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Date: Wed, 3 Mar 2010 10:33:26 +0100 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D01594FD5@XMB-AMS-107.cisco.com> In-Reply-To: <201003030805.30679.henning.rogge@fkie.fraunhofer.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] [roll] #20: Question on Metric ID Thread-Index: Acq6n/rPRW3BRrQgSoqL7S4iwfbXBgAE9F3w References: <055.a3c60804880e85f93fc1826167be4fb6@tools.ietf.org> <201003030805.30679.henning.rogge@fkie.fraunhofer.de> From: "Pascal Thubert (pthubert)" To: "Henning Rogge" , "MiJeom Kim" X-OriginalArrivalTime: 03 Mar 2010 09:33:30.0205 (UTC) FILETIME=[95B558D0:01CABAB4] Cc: roll@ietf.org Subject: Re: [Roll] [roll] #20: Question on Metric 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: Wed, 03 Mar 2010 09:33:31 -0000 SGk6DQoNClRoZSBsYXRlc3QgdmVyc2lvbiBvZiB0aGUgZHJhZnQgYWNjb21tb2RhdGVkIHRoZSBS YW5rIGluIDIgYnl0ZXMsIGluIHBhcnRpY3VsYXIgdG8gZW5hYmxlIHRoZSBncmFudWxhcml0eSB0 aGF0IGxhdGVuY3kgd291bGQgcmVxdWlyZS4NCg0KV2UgaGF2ZSBhIG1pbiBpbmNyZW1lbnQgdGhh dCBhY3RzIGFzIHRoZSBsb2NhdGlvbiBvZiB0aGUgZmxvYXRpbmcgcG9pbnQuIFRoaXMgaXMgdmVy eSBnZW5lcmljLCBidXQgaXQgYWxzbyBtYWtlcyB0aGUgdGV4dCwgYW5kIHByb2JhYmx5IHRoZSBj b2RlIHRoYXQgZ29lcyB3aXRoIGl0LCBhIGxvdCBtb3JlIGNvbXBsZXggdGhhbiBuZWVkIGJlLCBp biBwYXJ0aWN1bGFyIHdpdGggdGhlIHVzZSBvZiBkaXZpc2lvbnMgYW5kIGZsb29yKCkuDQoNCldl IGNvdWxkIHByb2JhYmx5IGxpdmUgd2l0aCBSaWNoYXJkJ3Mgb3JpZ2luYWwgcHJvcG9zYWwsIHRo YXQgaXMgdG8gZ2VuZXJhbGl6ZSB0aGUgbWluaW11bSBpbmNyZW1lbnQgdG8gd2hhdCdzIHByb3Bv c2VkIGhlcmUsIDI1Ni4gSU9XIHVzZSB0aGUgZmlyc3QgYnl0ZSBhcyB0aGUgZmxvb3IgdG8gZGV0 ZXJtaW5lIHNpYmxpbmdzIGV0Yy4uLiBhbmQgdXNlIHRoZSBzZWNuZCBieXRlIHRvIGNhcnJ5IGZp bmVyIGdyYWluZWQgaW5mb3JtYXRpb24gdGhhdCBiZWNvbWVzIHNlZnVsIHdoZW4gdGhpbmdzIGFk ZCB1cC4NCg0KSSBzdWdnZXN0IHdlIG1ha2UgYW4gaXNzdWUgb24gdGhlIGRyYWZ0IHRvIGZpZ3Vy ZSB0aGF0IG91dC4gSWRlYXM/DQoNClBhc2NhbA0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0t LS0tDQo+IEZyb206IHJvbGwtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOnJvbGwtYm91bmNlc0Bp ZXRmLm9yZ10gT24gQmVoYWxmIE9mDQo+IEhlbm5pbmcgUm9nZ2UNCj4gU2VudDogV2VkbmVzZGF5 LCBNYXJjaCAwMywgMjAxMCA4OjA1IEFNDQo+IFRvOiBNaUplb20gS2ltDQo+IENjOiByb2xsQGll dGYub3JnDQo+IFN1YmplY3Q6IFJlOiBbUm9sbF0gW3JvbGxdICMyMDogUXVlc3Rpb24gb24gTWV0 cmljIElEDQo+IA0KPiBPbiBXZWQgTWFyY2ggMyAyMDEwIDA2OjI4OjI2IE1pSmVvbSBLaW0gd3Jv dGU6DQo+ID4gSGksDQo+ID4NCj4gPiBJdOKAmXMgdGltZSB0byBzdW1tYXJpemUuDQo+ID4NCj4g PiAtIEVUWCA+PSAxLCBhbmQgMTAwIGlzIGVub3VnaCBmb3IgTWF4IEVUWCBzaW5jZSBtb3JlIHRo YW4gMTAgRVRYIGlzDQo+ID4gY2xvc2UgdG8gaW5maW5pdHkuDQo+ID4gLSA4IGJpdHMgYXJlIGVu b3VnaCBidXQgbmVlZCB0byBhdm9pZCBmbG9hdGluZyBwb2ludCBmb3JtYXQuIMOoIGdvb2QgdG8N Cj4gPiBtdWx0aXBseSB3aXRoIGEgY29uc3RhbnQgZmFjdG9yIChDKSBsaWtlIDI1Ng0KPiBBcyBz b29uIGFzIHlvdSBtb3ZlIHRvIEVUVCBvciBNSUMgeW91IG5lZWQgYSBoaWdoZXIgcmFuZ2UuIEVp dGhlciB5b3UgdXNlIGENCj4gMzItYml0IGludGVnZXIgb3IgZmxvYXRpbmcgcG9pbnQsIG90aGVy d2lzZSBSaXBwbGUgd2lsbCBiZSB1bmFibGUgdG8gcnVuIHdpdGgNCj4gYmV0dGVyIG1ldHJpY3Mu DQo+IA0KPiA+IEkgdGhpbmsgSGVubmluZ+KAmXMgc3VnZ2VzdGlvbiBpcyBnb29kLiBCdXQgd2Ug ZG9u4oCZdCBuZWVkIGEgYmlnIHJhbmdlDQo+ID4gZm9yIEVUWCwgYnV0IHByZWNpc2lvbiBuZWVk cyB0byBiZSBpbmNyZWFzZWQuIFNvIHdlIGNhbiBhZGp1c3QgaXQgd2l0aA0KPiA+IDUgYml0IG1h bnRpc3NhIGFuZCAzIGJpdCBleHBvbmVudC4NCj4gPg0KPiA+IFNvLCB3ZSBjYW4gcmVwcmVzZW50 IChFVFggKiBDKSBhcyAoMzIgKyBhKSAqIDJeYiB3aGVyZSAwIDw9IGEgPD0gMzENCj4gPiBhbmQg MCA8PSBiIDw9IDcuIElmIEMgaXMgMTI4LCB0aGUgbWF4IHBvc3NpYmxlIEVUWCBpcyA2MyBhbmQg aWYgQyBpcw0KPiA+IDY0LCB0aGUgbWF4IEVUWCBpcyAxMjYuIFNvIGxldOKAmXMgdHJ5IEMgPSA2 NCBhbmQgaWYgRVRYIGlzIGJpZ2dlciB0aGFuDQo+ID4gMTI2LCB3ZSBjYW4ganVzdCBtYWtlIGl0 IHRoZSBwb3NzaWJsZSBtYXggd2hpY2ggaXMgMTI2Lg0KPiA+DQo+ID4gQWxsIHRoZSBudW1iZXJz IGNhbiBiZSBhZGp1c3RhYmxlIGFnYWluLCBzbyBwbGVhc2Ugc2V0dGxlIGRvd24gdGhlDQo+ID4g aXNzdWUgd2l0aCB5b3VyIGlkZWFzLg0KPiA+DQo+ID4gSSBjYW7igJl0IHVuZGVyc3RhbmQgdGhl IE92ZXJsb2FkaW5nIEVUWCB0aGluZy4gTm9ib2R5IHN1Z2dlc3RzDQo+ID4gb3ZlcmxvYWRpbmcg RVRYLCBJIHRoaW5rLiBXaGF0IGRvIHlvdSBtZWFuIGJ5IHRoYXQgaW4gdGhpcyB0aHJlYWQsDQo+ IEkgc3VnZ2VzdCBub3QgdG8gZGVzaWduIHlvdXIgcHJvdG9jb2wgZm9yIGEgc2luZ2xlIHJvdXRp bmcgbWV0cmljLiBUaGF0IHdvdWxkDQo+IG1ha2UgUmlwcGxlIGluZmxleGlibGUgYW5kIGZvcmNl IHlvdSB0byBjaGFuZ2UgdGhlIG1lc3NhZ2UgZm9ybWF0IGxhdGVyDQo+IHdoZW4geW91IHdhbnQg dG8gbW92ZSB0byBzb21ldGhpbmcgYmV0dGVyLg0KPiANCj4gSGVubmluZyBSb2dnZQ0KPiANCj4g LS0NCj4gRGlwbG9tLUluZm9ybWF0aWtlciBIZW5uaW5nIFJvZ2dlICwgRnJhdW5ob2Zlci1JbnN0 aXR1dCBmw7xyDQo+IEtvbW11bmlrYXRpb24sIEluZm9ybWF0aW9uc3ZlcmFyYmVpdHVuZyB1bmQg RXJnb25vbWllIEZLSUUNCj4gS29tbXVuaWthdGlvbnNzeXN0ZW1lIChLT00pIE5ldWVuYWhyZXIg U3RyYcOfZSAyMCwgNTMzNDMgV2FjaHRiZXJnLA0KPiBHZXJtYW55DQo+IFRlbGVmb24gKzQ5IDIy OCA5NDM1LTI2MywgICBGYXggKzQ5IDIyOCA5NDM1IDY4NQ0KPiBtYWlsdG86aGVubmluZy5yb2dn ZUBma2llLmZyYXVuaG9mZXIuZGUgaHR0cDovL3d3dy5ma2llLmZyYXVuaG9mZXIuZGUNCj4gR1BH OiBFMUM2IDA5MTQgNDkwQiAzOTA5IEQ5NDQgRjgwRCA0NDg3IEM2N0MgNTVFQyBDRkUwDQo= From phoebus@ieee.org Wed Mar 3 06:24: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 DD4F93A8DE4 for ; Wed, 3 Mar 2010 06:24:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.249 X-Spam-Level: X-Spam-Status: No, score=-106.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F8BvEi8B5uAM for ; Wed, 3 Mar 2010 06:24:03 -0800 (PST) Received: from smtp-2.sys.kth.se (smtp-2.sys.kth.se [130.237.32.160]) by core3.amsl.com (Postfix) with ESMTP id 6B35F3A8DE0 for ; Wed, 3 Mar 2010 06:24:03 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by smtp-2.sys.kth.se (Postfix) with ESMTP id C594114DCEC for ; Wed, 3 Mar 2010 15:23:33 +0100 (CET) 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 kC8V2T2FJ9AV for ; Wed, 3 Mar 2010 15:23:32 +0100 (CET) X-KTH-Auth: phoebus [2002:82ed:3209:b:223:dfff:fe92:5e5c] X-KTH-mail-from: phoebus@ieee.org X-KTH-rcpt-to: roll@ietf.org Received: from dhcp-50-62.s3.kth.se (unknown [IPv6:2002:82ed:3209:b:223:dfff:fe92:5e5c]) by smtp-2.sys.kth.se (Postfix) with ESMTP id B2E9F14DC82 for ; Wed, 3 Mar 2010 15:23:32 +0100 (CET) Message-ID: <4B8E70E3.8000100@ieee.org> Date: Wed, 03 Mar 2010 15:23:31 +0100 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.8) Gecko/20100216 Thunderbird/3.0.2 MIME-Version: 1.0 To: "roll@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [Roll] RPL spec v6: Preferred Parent for Rank Calculation and Packet Forwarding 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: Wed, 03 Mar 2010 14:24:05 -0000 Hello, In version 6 of the RPL specification, the preferred parent is used for two purposes: 1) Rank calculations (pg. 36, Sec. 5.3.4.1) (bottom of pg. 59, Sec. 10) 2) Preferred next hop for forwarding packets upwards (pg. 30, Sec. 5.3.2) (pg. 56,57, Sec. 8) I recall that this had caused some confusion on the mailing list earlier on. Is it really a good idea to have the preferred parent serve both purposes? We had a discussion within our research group, and there does seem to be situations where it might be better to NOT force every node in the DODAG to specify a preferred parent for forwarding packets. For instance, if a node has several parents with reliable paths to the root (and their reliability doesn't differ too much), there might be better load balancing in the network if you allow a node to cycle through its parents when forwarding packets. This could affect packet queuing delay, energy consumption, etc. Another example arises when using a fixed, repeating TDMA schedule for the network, like with WirelessHART. The first link scheduled for transmission after a packet arrives at a node (or is generated at a node) might not be to the node's preferred parent. If RPL requires that a node tries to forward to the preferred parent first, then the packet will have to wait at the node. This could severely prolong the end-to-end latency of the packet if this situation happens at each hop along the path and the nodes in the network are duty-cycled (sleep) to save energy. Section 10, "Guidelines for Objective Functions," goes so far as to suggest creating an ordered list of parents, presumably for preference forwarding packets. If this is just a suggestion, I feel that this section needs to be clearer what is required (MUST) and what is optional (SHOULD). On the other hand, I feel that the current RPL specification makes sense designating a node in the parent set with the highest rank (whether you want to call it the "preferred parent" or something else) to calculate the rank of the node. What do others think of this suggestion to not force all RPL implementations to designate a preferred parent for forwarding packets? -- Phoebus Chen Postdoctoral Researcher Automatic Control Lab, KTH (Royal Institute of Technology) http://www.ee.kth.se/~phoebus From anders.jagd@gmail.com Wed Mar 3 07:16: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 1413928C121 for ; Wed, 3 Mar 2010 07:16:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4EJ7dBzDAkuU for ; Wed, 3 Mar 2010 07:16:37 -0800 (PST) Received: from mail-pv0-f172.google.com (mail-pv0-f172.google.com [74.125.83.172]) by core3.amsl.com (Postfix) with ESMTP id 73F0628C100 for ; Wed, 3 Mar 2010 07:16:37 -0800 (PST) Received: by pvg2 with SMTP id 2so523309pvg.31 for ; Wed, 03 Mar 2010 07:16:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=A5rMBUgtIDv+238a7Pe3xUTdfVIZ1JMyXQDT/ZX8Mg8=; b=k0jj+a6cVrYWNuTyDKPv6V6bHdWzP4IDek536k3KQfuUVgv0F3VXkr3533uWYUzAf8 Khv5tL8LEZqcfXo90CzLhQAXoPO85Z/aPgfZrJhIqsLEif/aMkez4feReHIMhUmzpyP1 zgsguGo3oN5QPtd8Zp+nOn9xA0mehCnUR53Z4= 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=g2GtMzjlo8CTvpXuaToz89ndI0ahJIqofkz3RsEtn/mrHsGcjPwxeTM4GU3l3LzoGf ZXIJ8mxlzBzk/+7pJmK2CdwTayk0CHbBZiK5jiOxJNpQPKW7mOyIOqZCCjRmSq0XKgBV KorYrhz55PsrjF9M3h2L+bHUw5g+KfSaBX0mc= MIME-Version: 1.0 Received: by 10.143.21.25 with SMTP id y25mr4434684wfi.206.1267629393605; Wed, 03 Mar 2010 07:16:33 -0800 (PST) In-Reply-To: <4B8E70E3.8000100@ieee.org> References: <4B8E70E3.8000100@ieee.org> Date: Wed, 3 Mar 2010 10:16:33 -0500 Message-ID: <77b524e41003030716u6d008622n6ddb41d9ba56a2ab@mail.gmail.com> From: Anders Jagd To: phoebus@ieee.org Content-Type: multipart/alternative; boundary=00504502cf2bb6759f0480e6f7d0 Cc: "roll@ietf.org" Subject: Re: [Roll] RPL spec v6: Preferred Parent for Rank Calculation and Packet Forwarding X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 03 Mar 2010 15:16:39 -0000 --00504502cf2bb6759f0480e6f7d0 Content-Type: text/plain; charset=ISO-8859-1 Phoebus, I believe Section 7.1 is quite clear about the forwarding options for each node: Quote: 5. If there is a DODAG iteration offering a route to a prefix matching the destination, then select *one of those DODAG parents* as a successor. End Quote Nothing written about giving preference to the "preferred parent". Not only is load balancing allowed, I believe it is encouraged (on a case by case basis as usual). I do agree that, in order to avoid confusion, we may want to get rid of the "preferred parent" terminology, unless there is some other "special attention" given to the preferred parent. /Anders On Wed, Mar 3, 2010 at 9:23 AM, Phoebus Chen wrote: > Hello, > > In version 6 of the RPL specification, the preferred parent is used for two > purposes: > 1) Rank calculations (pg. 36, Sec. 5.3.4.1) (bottom of pg. 59, Sec. 10) > 2) Preferred next hop for forwarding packets upwards (pg. 30, Sec. 5.3.2) > (pg. 56,57, Sec. 8) > > I recall that this had caused some confusion on the mailing list earlier > on. Is it really a good idea to have the preferred parent serve both > purposes? > > We had a discussion within our research group, and there does seem to be > situations where it might be better to NOT force every node in the DODAG to > specify a preferred parent for forwarding packets. For instance, if a node > has several parents with reliable paths to the root (and their reliability > doesn't differ too much), there might be better load balancing in the > network if you allow a node to cycle through its parents when forwarding > packets. This could affect packet queuing delay, energy consumption, etc. > > Another example arises when using a fixed, repeating TDMA schedule for the > network, like with WirelessHART. The first link scheduled for transmission > after a packet arrives at a node (or is generated at a node) might not be to > the node's preferred parent. If RPL requires that a node tries to forward > to the preferred parent first, then the packet will have to wait at the > node. This could severely prolong the end-to-end latency of the packet if > this situation happens at each hop along the path and the nodes in the > network are duty-cycled (sleep) to save energy. > > Section 10, "Guidelines for Objective Functions," goes so far as to suggest > creating an ordered list of parents, presumably for preference forwarding > packets. If this is just a suggestion, I feel that this section needs to be > clearer what is required (MUST) and what is optional (SHOULD). > > On the other hand, I feel that the current RPL specification makes sense > designating a node in the parent set with the highest rank (whether you want > to call it the "preferred parent" or something else) to calculate the rank > of the node. > > What do others think of this suggestion to not force all RPL > implementations to designate a preferred parent for forwarding packets? > > > -- > Phoebus Chen > Postdoctoral Researcher > Automatic Control Lab, KTH (Royal Institute of Technology) > http://www.ee.kth.se/~phoebus > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > --00504502cf2bb6759f0480e6f7d0 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Phoebus,

I believe Section 7.1 is quite clear about the = forwarding options for each node:

Quote:
5. If there is a DODAG iteration offering a route to a prefix matching the= destination, then select *one of those DODAG parents* as a successor.
End Quote

Nothing written about giving prefer= ence to the "preferred parent". Not only is load balancing allowe= d, I believe it is encouraged (on a case by case basis as usual).

I do agree that, in order to avoid confusion, we may wa= nt to get rid of the "preferred parent" terminology, unless there= is some other "special attention" given to the preferred parent.=

/Anders

On Wed, Mar 3= , 2010 at 9:23 AM, Phoebus Chen <phoebus@ieee.org> wrote:
Hello,

In version 6 of the RPL specification, the preferred parent is used for two= purposes:
1) Rank calculations (pg. 36, Sec. 5.3.4.1) (bottom of pg. 59, Sec. 10)
2) Preferred next hop for forwarding packets upwards (pg. 30, Sec. 5.3.2) (= pg. 56,57, Sec. 8)

I recall that this had caused some confusion on the mailing list earlier on= . =A0Is it really a good idea to have the preferred parent serve both purpo= ses?

We had a discussion within our research group, and there does seem to be si= tuations where it might be better to NOT force every node in the DODAG to s= pecify a preferred parent for forwarding packets. =A0For instance, if a nod= e has several parents with reliable paths to the root (and their reliabilit= y doesn't differ too much), there might be better load balancing in the= network if you allow a node to cycle through its parents when forwarding p= ackets. =A0This could affect packet queuing delay, energy consumption, etc.=

Another example arises when using a fixed, repeating TDMA schedule for the = network, like with WirelessHART. =A0The first link scheduled for transmissi= on after a packet arrives at a node (or is generated at a node) might not b= e to the node's preferred parent. =A0If RPL requires that a node tries = to forward to the preferred parent first, then the packet will have to wait= at the node. =A0This could severely prolong the end-to-end latency of the = packet if this situation happens at each hop along the path and the nodes i= n the network are duty-cycled (sleep) to save energy.

Section 10, "Guidelines for Objective Functions," goes so far as = to suggest creating an ordered list of parents, presumably for preference f= orwarding packets. =A0If this is just a suggestion, I feel that this sectio= n needs to be clearer what is required (MUST) and what is optional (SHOULD)= .

On the other hand, I feel that the current RPL specification makes sense de= signating a node in the parent set with the highest rank (whether you want = to call it the "preferred parent" or something else) to calculate= the rank of the node.

What do others think of this suggestion to not force all RPL implementation= s to designate a preferred parent for forwarding packets?


--
Phoebus Chen
Postdoctoral Researcher
Automatic Control Lab, KTH (Royal Institute of Technology)
http://www.ee.k= th.se/~phoebus
_______________________________________________
Roll mailing list
Roll@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/roll

--00504502cf2bb6759f0480e6f7d0-- From anders.jagd@gmail.com Wed Mar 3 07:40: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 4AC3B3A8ABB for ; Wed, 3 Mar 2010 07:40:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zo3cdVScORWI for ; Wed, 3 Mar 2010 07:40:49 -0800 (PST) Received: from mail-pz0-f195.google.com (mail-pz0-f195.google.com [209.85.222.195]) by core3.amsl.com (Postfix) with ESMTP id BB8193A8A86 for ; Wed, 3 Mar 2010 07:40:49 -0800 (PST) Received: by pzk33 with SMTP id 33so1051566pzk.5 for ; Wed, 03 Mar 2010 07:40:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=sjL28qdeecKzQk6p0MxnktBGrgn3a9+SQXA9eKjFfQY=; b=u9aLBlUklscVZuBCK0byuTOKR0Gu/+VYpt14JNOrWnGcHocQAcF8N/CO6GDp5waF5m RnlPiNKI5dc1mSemNc8sPSIn9beDjREgnTyfNe3ipfcOksW7/PYM4rbRFx7+W351yQZp 3TKu0qPVtlsnlruq5Cy9DdPBxCLv09Tmu1bO0= 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=NQZZ6GcSNqd+8b15QRPePVJlNoamm8m5TNUnvJqb79ZBZNUo7/lV5qGYQTBb79sZ1g DoDYOEWJ6HB3wFD6oeE0Tg3atjJf2BC2M0uT9Y71kguLSBLuL03RM9yVyGF4TZw4LF+l QipTgY+t9XM9N+4ZGadi9rxDTEoFhCkBNEbHk= MIME-Version: 1.0 Received: by 10.142.3.27 with SMTP id 27mr1268497wfc.349.1267630848778; Wed, 03 Mar 2010 07:40:48 -0800 (PST) In-Reply-To: <77b524e41003030716u6d008622n6ddb41d9ba56a2ab@mail.gmail.com> References: <4B8E70E3.8000100@ieee.org> <77b524e41003030716u6d008622n6ddb41d9ba56a2ab@mail.gmail.com> Date: Wed, 3 Mar 2010 10:40:48 -0500 Message-ID: <77b524e41003030740v47d54dc7ta824abf49b510619@mail.gmail.com> From: Anders Jagd To: phoebus@ieee.org Content-Type: multipart/alternative; boundary=00504502ad0d72a3a10480e74e78 Cc: "roll@ietf.org" Subject: Re: [Roll] RPL spec v6: Preferred Parent for Rank Calculation and Packet Forwarding X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 03 Mar 2010 15:40:51 -0000 --00504502ad0d72a3a10480e74e78 Content-Type: text/plain; charset=ISO-8859-1 Allow me to clarify myself (see below) /Anders On Wed, Mar 3, 2010 at 10:16 AM, Anders Jagd wrote: > Phoebus, > > I believe Section 7.1 is quite clear about the forwarding options for each > node: > > Quote: > 5. If there is a DODAG iteration offering a route to a prefix matching the > destination, then select *one of those DODAG parents* as a successor. > End Quote > > Nothing written about giving preference to the "preferred parent". Not only > is load balancing allowed, I believe it is encouraged (on a case by case > basis as usual). > > I do agree that, in order to avoid confusion, we may want to get rid of the > "preferred parent" terminology, unless there is some other "special > attention" given to the preferred parent. > > I meant to say "unless there is some other special attention - besides rank calculation - given to the preferred parent". > /Anders > > > On Wed, Mar 3, 2010 at 9:23 AM, Phoebus Chen wrote: > >> Hello, >> >> In version 6 of the RPL specification, the preferred parent is used for >> two purposes: >> 1) Rank calculations (pg. 36, Sec. 5.3.4.1) (bottom of pg. 59, Sec. 10) >> 2) Preferred next hop for forwarding packets upwards (pg. 30, Sec. 5.3.2) >> (pg. 56,57, Sec. 8) >> >> I recall that this had caused some confusion on the mailing list earlier >> on. Is it really a good idea to have the preferred parent serve both >> purposes? >> >> We had a discussion within our research group, and there does seem to be >> situations where it might be better to NOT force every node in the DODAG to >> specify a preferred parent for forwarding packets. For instance, if a node >> has several parents with reliable paths to the root (and their reliability >> doesn't differ too much), there might be better load balancing in the >> network if you allow a node to cycle through its parents when forwarding >> packets. This could affect packet queuing delay, energy consumption, etc. >> >> Another example arises when using a fixed, repeating TDMA schedule for the >> network, like with WirelessHART. The first link scheduled for transmission >> after a packet arrives at a node (or is generated at a node) might not be to >> the node's preferred parent. If RPL requires that a node tries to forward >> to the preferred parent first, then the packet will have to wait at the >> node. This could severely prolong the end-to-end latency of the packet if >> this situation happens at each hop along the path and the nodes in the >> network are duty-cycled (sleep) to save energy. >> >> Section 10, "Guidelines for Objective Functions," goes so far as to >> suggest creating an ordered list of parents, presumably for preference >> forwarding packets. If this is just a suggestion, I feel that this section >> needs to be clearer what is required (MUST) and what is optional (SHOULD). >> >> On the other hand, I feel that the current RPL specification makes sense >> designating a node in the parent set with the highest rank (whether you want >> to call it the "preferred parent" or something else) to calculate the rank >> of the node. >> >> What do others think of this suggestion to not force all RPL >> implementations to designate a preferred parent for forwarding packets? >> >> >> -- >> Phoebus Chen >> Postdoctoral Researcher >> Automatic Control Lab, KTH (Royal Institute of Technology) >> http://www.ee.kth.se/~phoebus >> _______________________________________________ >> Roll mailing list >> Roll@ietf.org >> https://www.ietf.org/mailman/listinfo/roll >> > > --00504502ad0d72a3a10480e74e78 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Allow me to clarify myself (see below)
/Anders

On Wed, Mar 3, 2010 at 10:16 AM, Anders Jagd &l= t;anders.jagd@gmail.com> wrote:
Phoebus,

I believe Secti= on 7.1 is quite clear about the forwarding options for each node:

Quote:
5. If there is a DODAG iteration offering a= route to a prefix matching the destination, then select *one of those DODA= G parents* as a successor.
End Quote

Nothing written about giving prefer= ence to the "preferred parent". Not only is load balancing allowe= d, I believe it is encouraged (on a case by case basis as usual).

I do agree that, in order to avoid confusion, we may wa= nt to get rid of the "preferred parent" terminology, unless there= is some other "special attention" given to the preferred parent.=


I meant to say "unless= there is some other special attention - besides rank calculation - given t= o the preferred parent".
=A0
/Anders


On Wed, Mar 3, 2010 at 9:23= AM, Phoebus Chen <phoebus@ieee.org> wrote:
Hello,

In version 6 of the RPL specification, the preferred parent is used for two= purposes:
1) Rank calculations (pg. 36, Sec. 5.3.4.1) (bottom of pg. 59, Sec. 10)
2) Preferred next hop for forwarding packets upwards (pg. 30, Sec. 5.3.2) (= pg. 56,57, Sec. 8)

I recall that this had caused some confusion on the mailing list earlier on= . =A0Is it really a good idea to have the preferred parent serve both purpo= ses?

We had a discussion within our research group, and there does seem to be si= tuations where it might be better to NOT force every node in the DODAG to s= pecify a preferred parent for forwarding packets. =A0For instance, if a nod= e has several parents with reliable paths to the root (and their reliabilit= y doesn't differ too much), there might be better load balancing in the= network if you allow a node to cycle through its parents when forwarding p= ackets. =A0This could affect packet queuing delay, energy consumption, etc.=

Another example arises when using a fixed, repeating TDMA schedule for the = network, like with WirelessHART. =A0The first link scheduled for transmissi= on after a packet arrives at a node (or is generated at a node) might not b= e to the node's preferred parent. =A0If RPL requires that a node tries = to forward to the preferred parent first, then the packet will have to wait= at the node. =A0This could severely prolong the end-to-end latency of the = packet if this situation happens at each hop along the path and the nodes i= n the network are duty-cycled (sleep) to save energy.

Section 10, "Guidelines for Objective Functions," goes so far as = to suggest creating an ordered list of parents, presumably for preference f= orwarding packets. =A0If this is just a suggestion, I feel that this sectio= n needs to be clearer what is required (MUST) and what is optional (SHOULD)= .

On the other hand, I feel that the current RPL specification makes sense de= signating a node in the parent set with the highest rank (whether you want = to call it the "preferred parent" or something else) to calculate= the rank of the node.

What do others think of this suggestion to not force all RPL implementation= s to designate a preferred parent for forwarding packets?


--
Phoebus Chen
Postdoctoral Researcher
Automatic Control Lab, KTH (Royal Institute of Technology)
http://www.ee.k= th.se/~phoebus
_______________________________________________
Roll mailing list
Roll@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/roll


--00504502ad0d72a3a10480e74e78-- From pthubert@cisco.com Wed Mar 3 07:44: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 D5F6128C422 for ; Wed, 3 Mar 2010 07:44:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.265 X-Spam-Level: X-Spam-Status: No, score=-5.265 tagged_above=-999 required=5 tests=[AWL=-2.667, 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 M9SjZgHcK5pO for ; Wed, 3 Mar 2010 07:44:37 -0800 (PST) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by core3.amsl.com (Postfix) with ESMTP id 76CCC28C41C for ; Wed, 3 Mar 2010 07:44:36 -0800 (PST) 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: AsYAAI8SjkuQ/uCWe2dsb2JhbACBQ5lKFQEBFiQGHKc+mEqEfAQ X-IronPort-AV: E=Sophos;i="4.49,574,1262563200"; d="scan'208,217";a="3961435" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-2.cisco.com with ESMTP; 03 Mar 2010 15:11:56 +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 o23FiaEp028027; Wed, 3 Mar 2010 15:44:36 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); Wed, 3 Mar 2010 16:44:36 +0100 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_01CABAE8.6D1FCD3C" Date: Wed, 3 Mar 2010 16:44:24 +0100 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D01619695@XMB-AMS-107.cisco.com> In-Reply-To: <77b524e41003030716u6d008622n6ddb41d9ba56a2ab@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] RPL spec v6: Preferred Parent for Rank Calculation andPacket Forwarding Thread-Index: Acq65IpVsATUE2OyQ42euqfty1HJ4gAAzZ4Q References: <4B8E70E3.8000100@ieee.org> <77b524e41003030716u6d008622n6ddb41d9ba56a2ab@mail.gmail.com> From: "Pascal Thubert (pthubert)" To: "Anders Jagd" , X-OriginalArrivalTime: 03 Mar 2010 15:44:36.0830 (UTC) FILETIME=[6DA6AFE0:01CABAE8] Cc: roll@ietf.org Subject: Re: [Roll] RPL spec v6: Preferred Parent for Rank Calculation andPacket Forwarding X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 03 Mar 2010 15:44:37 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CABAE8.6D1FCD3C Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Anders and Phoebus =20 Quote: 5. If there is a DODAG iteration offering a route to a prefix matching the destination, then select *one of those DODAG parents* as a successor. End Quote =20 Nothing written about giving preference to the "preferred parent". Not only is load balancing allowed, I believe it is encouraged (on a case by case basis as usual). =20 [Pascal] Most certainly. This also enables a quick reactivity to transient events that will not be reflected in the routing plane.=20 =20 I do agree that, in order to avoid confusion, we may want to get rid of the "preferred parent" terminology, unless there is some other "special attention" given to the preferred parent. =20 [Pascal] The preferred parent is still needed as the reference for the metrics computation. If a node derives its own metrics from that of a preferred parent, then it can be expected that this preferred parent also gets the bulk of the traffic, otherwise the node is not honest about the service that it is providing. =20 Pascal =20 ------_=_NextPart_001_01CABAE8.6D1FCD3C Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Anders and Phoebus

 

Quote:

5. If there is a DODAG iteration offering a route to a = prefix matching the destination, then select *one of those DODAG = parents* as a successor.

End Quote

 

Nothing written about giving preference to the = "preferred parent". Not only is load balancing allowed, I = believe it is encouraged (on a case by case basis as = usual).

 

[Pascal] Most certainly. This also enables a quick reactivity to = transient events that will not be reflected in the routing plane. =

 

I do = agree that, in order to avoid confusion, we may want to get rid of the = "preferred parent" terminology, unless there is some other = "special attention" given to the preferred = parent.

 

[Pascal] The preferred parent is still needed as the reference for = the metrics computation. If a node derives its own metrics from that of = a preferred parent, then it can be expected that this preferred parent = also gets the bulk of the traffic, otherwise the node is not honest = about the service that it is providing.

 

Pascal

 

------_=_NextPart_001_01CABAE8.6D1FCD3C-- From phoebus@ieee.org Wed Mar 3 08: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 3D30E28C108 for ; Wed, 3 Mar 2010 08:30:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.249 X-Spam-Level: X-Spam-Status: No, score=-106.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GeSeGRqMTlLG for ; Wed, 3 Mar 2010 08:30:33 -0800 (PST) Received: from smtp-1.sys.kth.se (smtp-1.sys.kth.se [130.237.32.175]) by core3.amsl.com (Postfix) with ESMTP id 3B7F528C0F0 for ; Wed, 3 Mar 2010 08:30:33 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by smtp-1.sys.kth.se (Postfix) with ESMTP id AB8B2155876 for ; Wed, 3 Mar 2010 17:30:03 +0100 (CET) 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 hxHE6DSEAwte for ; Wed, 3 Mar 2010 17:30:02 +0100 (CET) X-KTH-Auth: phoebus [2002:82ed:3209:b:223:dfff:fe92:5e5c] X-KTH-mail-from: phoebus@ieee.org X-KTH-rcpt-to: roll@ietf.org Received: from dhcp-50-62.s3.kth.se (unknown [IPv6:2002:82ed:3209:b:223:dfff:fe92:5e5c]) by smtp-1.sys.kth.se (Postfix) with ESMTP id 1BDB7155964 for ; Wed, 3 Mar 2010 17:30:01 +0100 (CET) Message-ID: <4B8E8E89.5080101@ieee.org> Date: Wed, 03 Mar 2010 17:30:01 +0100 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.8) Gecko/20100216 Thunderbird/3.0.2 MIME-Version: 1.0 To: roll@ietf.org References: <4B8E70E3.8000100@ieee.org> <77b524e41003030716u6d008622n6ddb41d9ba56a2ab@mail.gmail.com> <6A2A459175DABE4BB11DE2026AA50A5D01619695@XMB-AMS-107.cisco.com> In-Reply-To: <6A2A459175DABE4BB11DE2026AA50A5D01619695@XMB-AMS-107.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Roll] RPL spec v6: Preferred Parent for Rank Calculation and Packet Forwarding 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: Wed, 03 Mar 2010 16:30:35 -0000 Anders and Pascal, Thanks for your responses. Comments Inline below. On 3/3/10 4:44 PM, Pascal Thubert (pthubert) wrote: > Hi Anders and Phoebus > > Quote: > > 5. If there is a DODAG iteration offering a route to a prefix matching > the destination, then select *one of those DODAG parents* as a successor. > > End Quote > > Nothing written about giving preference to the "preferred parent". Not > only is load balancing allowed, I believe it is encouraged (on a case by > case basis as usual). > > */[Pascal] Most certainly. This also enables a quick reactivity to > transient events that will not be reflected in the routing plane. /* Hmm, then I suppose that the text I quoted: (pg. 30, Sec. 5.3.2) "Finally, the preferred parent, a set of size one, is an element of the parent set that is the preferred next hop in upward routes." (pg. 56,57, Sec. 8) "For a source inside the DODAG, the packet is passed to the preferred parents, and if that fails then to the alternates in the DODAG." is outdated and will be removed in the next revision of the specification? > I do agree that, in order to avoid confusion, we may want to get rid of > the "preferred parent" terminology, unless there is some other "special > attention" given to the preferred parent. > > */[Pascal] The preferred parent is still needed as the reference for the > metrics computation. If a node derives its own metrics from that of a > preferred parent, then it can be expected that this preferred parent > also gets the bulk of the traffic, otherwise the node is not honest > about the service that it is providing./* > > */Pascal/* > I see your point of why you might want to make a node get the bulk of the traffic if it is the basis for the (single-path) metric computation. But if a node really is doing load balancing, he is "not being honest" by sending the bulk of the traffic to one parent anyways, regardless of whether you call it a "preferred parent." ;) As an aside, I'd like to point out that although this mailing list and the drafts have been discussing mostly single-path metrics, there may be multi-path / mesh metrics developed for RPL in the future. What I mean by a multi-path/mesh metric is a metric assigned to a node that takes into account all the paths through its parents. These aren't so common in the literature, so I'll take an example of what I've worked with. Suppose you want to define a metric that measures reliability, i.e. end-to-end packet delivery probability, when you have a mesh of paths from a source to a sink. Such a metric should reflect the fact that routing to a parent with many equally good paths to the sink is better than routing to a parent that has one good path to the sink. If you're skeptical that such multi-path metrics can be defined, you can look at one example: http://www.eecs.berkeley.edu/Pubs/TechRpts/2009/EECS-2009-75.html pg. 73, Definition 2.3.2. In a nutshell, it measures the end-to-end delivery probability assuming that a node will try to forward packets on its outgoing links with equal probability, and calculates the probability that a packet reaches the sink assuming all links are independent and stay up or down (does not switch between the two) during the entire duration of the packet transmission. I'll probably comment more on this later... after I've read the latest version of the routing metrics document and can provide some feedback. -- Phoebus Chen Postdoctoral Researcher Automatic Control Lab, KTH (Royal Institute of Technology) http://www.ee.kth.se/~phoebus From richard.kelsey@ember.com Wed Mar 3 10:36: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 5D3583A8B99 for ; Wed, 3 Mar 2010 10:36:01 -0800 (PST) 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 P9AgDme3wy+f for ; Wed, 3 Mar 2010 10:36:00 -0800 (PST) Received: from EMPIRE.hq.ember.com (mail.ember.com [74.10.175.227]) by core3.amsl.com (Postfix) with ESMTP id DE5BA28C46C for ; Wed, 3 Mar 2010 10:35:48 -0800 (PST) Received: from kelsey-ws.hq.ember.com ([192.168.81.37]) by EMPIRE.hq.ember.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 3 Mar 2010 13:38:21 -0500 Date: Wed, 03 Mar 2010 13:20:20 -0500 Message-Id: <87vddd5kt7.fsf@kelsey-ws.hq.ember.com> To: "Pascal Thubert (pthubert)" In-reply-to: <6A2A459175DABE4BB11DE2026AA50A5D01594FD5@XMB-AMS-107.cisco.com> (pthubert@cisco.com) From: Richard Kelsey References: <055.a3c60804880e85f93fc1826167be4fb6@tools.ietf.org> <201003030805.30679.henning.rogge@fkie.fraunhofer.de> <6A2A459175DABE4BB11DE2026AA50A5D01594FD5@XMB-AMS-107.cisco.com> X-OriginalArrivalTime: 03 Mar 2010 18:38:22.0184 (UTC) FILETIME=[B3A57680:01CABB00] Cc: roll@ietf.org Subject: Re: [Roll] [roll] #20: Question on Metric 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: Wed, 03 Mar 2010 18:36:01 -0000 > Date: Wed, 3 Mar 2010 10:33:26 +0100 > From: "Pascal Thubert (pthubert)" > > We have a min increment that acts as the location of the floating > point. This is very generic, but it also makes the text, and probably > the code that goes with it, a lot more complex than need be, in > particular with the use of divisions and floor(). I don't think it adds significant implementation complexity. For any given metric the rank is a fixed-point number. -Richard Kelsey From phoebus@ieee.org Wed Mar 3 10:37: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 42C9A3A8BEE for ; Wed, 3 Mar 2010 10:37:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.249 X-Spam-Level: X-Spam-Status: No, score=-106.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t5cm5WMyD9dl for ; Wed, 3 Mar 2010 10:37:56 -0800 (PST) Received: from smtp-1.sys.kth.se (smtp-1.sys.kth.se [130.237.32.175]) by core3.amsl.com (Postfix) with ESMTP id 9FBF93A8B99 for ; Wed, 3 Mar 2010 10:37:56 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by smtp-1.sys.kth.se (Postfix) with ESMTP id 70625155876 for ; Wed, 3 Mar 2010 19:37:27 +0100 (CET) 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 gAjAPjA7mB5L for ; Wed, 3 Mar 2010 19:37:16 +0100 (CET) X-KTH-Auth: phoebus [130.237.50.62] X-KTH-mail-from: phoebus@ieee.org X-KTH-rcpt-to: roll@ietf.org Received: from dhcp-50-62.s3.kth.se (dhcp-50-62.s3.kth.se [130.237.50.62]) by smtp-1.sys.kth.se (Postfix) with ESMTP id 41C22154129 for ; Wed, 3 Mar 2010 19:37:15 +0100 (CET) Message-ID: <4B8EAC5B.4040105@ieee.org> Date: Wed, 03 Mar 2010 19:37:15 +0100 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.8) Gecko/20100216 Thunderbird/3.0.2 MIME-Version: 1.0 To: "roll@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [Roll] RPL spec v6: request for multiple clarifications 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: Wed, 03 Mar 2010 18:37:58 -0000 Hello RPL authors, I just wanted to provide a list of suggestions on how to clarify the readability of the document. I was confuse by some points. I will send a separate email with more "minor" suggestions (nits), so as to not mix things up if there turns out to be a discussion thread following this email. Unicast DIS vs. Multicast DIS? ------------------------------ (pg. 37, Section 5.3.5) This was discussed earlier on the mailing list (also, Ticket item #12 on the Trac Issue Tracker), but I don't think the specification makes it clear when a node should transmit a unicast DIS and when it should transmit a multicast DIS. It's not even clear to a reader that there are two types of DIS when DIS is introduced in Section 5.2 (maybe the differentiation between unicast and multicast DIS doesn't belong here either, but it's really easy to miss in the document). I think the motivation was given here: http://www.ietf.org/mail-archive/web/roll/current/msg02552.html and the rest of the thread on DIS processing, but that should be hinted at in the document instead of asking an RPL implementer to search through the mailing list archives, right? My understanding: * A node should send a multicast DIS when it joins the network, to discover its parents. * A node sends a unicast DIS message to obtain DIO Configuration Options But can / should nodes send a DIS message upon detection of inconsistencies? When does it reset its own trickle timer (and push out DIOs more frequently), and when does it send a DIS? I think the former is mentioned in the specification but not the latter. Also, since the responses to a unicast DIS and a multicast DIS are different, maybe there should be a message body in the DIS to indicate how it a node should respond, instead of the receiver trying to infer it from whether the DIS is unicast or multicast? Which DIO Suboptions must be present in DIOs triggered by Trickle? ------------------------------------------------------------------ (pg. 38, Section 5.3.5.1.2) "A metric communicated in the DIO message is determined to be inconsistent, as according to a implementation specific path metric selection engine." From this, I would expect that the metric suboption should be in all DIOs that are periodically broadcast by Trickle. If only the DIO Base option is required, then nodes will have to chose their parents based only on rank, which may result in a suboptimal choice of parents (rank is primarily for loop-prevention, although there are references throughout the document of how it should be "synced" with the cost metric). Perhaps it is only omitted in response to a unicast DIS message? Invocation of Forwarding Error Correction during Sibling Loop Avoidance ----------------------------------------------------------------------- (pg. 55, Sec. 7.2.2.4, last paragraph) "When a router forwards to a sibling: if the Sibling bit was not set then the Sibling bit is set. If the Sibling bit was set then then the router SHOULD return the packet to the sibling that that passed it with the Forwarding-Error 'F' bit set." This paragraph is rather confusing. The last sentence implies that the current router is unable to forward to a parent, and thus must forward to another sibling. This could happen because the links to the parent happen to be down at the moment. But it should not forward to a sibling, because the sibling bit had already been set. So it should discard the packet. Instead, as written here the packet is suppose to be sent back to the sender with the Forwarding-Error bit set, presumably to evict current router from the sender's candidate neighbor set (or sibling set... whatever "routing states that caused forwarding to that neighbor" as stated in Section 7.2.2.6). Is this the right action? What if those parent links come up again? This is not loop-prevention so much as pruning the mesh of nodes that have (temporary) bad connectivity. Reminders of mechanisms that still have not been specified ---------------------------------------------------------- (pg. 32, Section 5.3.3.1) "Another possibility is that nodes within the LLN have some means by which they can signal detected routing inconsistencies or suboptimalities to the DODAG root, in order to request an on- demand DODAGSequenceNumber increment (i.e. request a global repair of the DODAG)." No message formats have been defined for this... I suppose this is still under consideration by the Working Group. Should this be a ticket item? (pg. 56, Section 7.2.2.5) "If DAO inconsistency loop recovery is applied, then the router SHOULD send the packet to the parent that passed it with the Forwarding-Error 'F' bit set." This sentence seems to imply that one can turn off local loop recovery. I don't see any flags or fields in the DIO Base or the DODAG Configuration Option that allow you to do this. -- Phoebus Chen Postdoctoral Researcher Automatic Control Lab, KTH (Royal Institute of Technology) http://www.ee.kth.se/~phoebus From phoebus@ieee.org Wed Mar 3 10:38: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 635673A8BCC for ; Wed, 3 Mar 2010 10:38:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.249 X-Spam-Level: X-Spam-Status: No, score=-106.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XlLKzxqA8vyX for ; Wed, 3 Mar 2010 10:38:20 -0800 (PST) Received: from smtp-1.sys.kth.se (smtp-1.sys.kth.se [130.237.32.175]) by core3.amsl.com (Postfix) with ESMTP id 0DBB53A8BEE for ; Wed, 3 Mar 2010 10:38:20 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by smtp-1.sys.kth.se (Postfix) with ESMTP id 68F471558BF for ; Wed, 3 Mar 2010 19:37:51 +0100 (CET) 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 ula-D23Ha8v5 for ; Wed, 3 Mar 2010 19:37:50 +0100 (CET) X-KTH-Auth: phoebus [130.237.50.62] X-KTH-mail-from: phoebus@ieee.org X-KTH-rcpt-to: roll@ietf.org Received: from dhcp-50-62.s3.kth.se (dhcp-50-62.s3.kth.se [130.237.50.62]) by smtp-1.sys.kth.se (Postfix) with ESMTP id 25030154129 for ; Wed, 3 Mar 2010 19:37:50 +0100 (CET) Message-ID: <4B8EAC7D.4000809@ieee.org> Date: Wed, 03 Mar 2010 19:37:49 +0100 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.8) Gecko/20100216 Thunderbird/3.0.2 MIME-Version: 1.0 To: "roll@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [Roll] RPL spec v6: request for minor clarifications (nits) 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: Wed, 03 Mar 2010 18:38:21 -0000 Hello RPL authors, Here are my list of nits and other minor suggestions for clarification on RPL draft 6. These are points that I think I understand more clearly in the document ;). (pg. 10, Sec. 3.1.1) Rank should not be listed as a 'Topology Identifier' (pg. 16, Sec. 3.4.6) "Nodes provision routing table entries, for the destinations specified by the DIO, via their DODAG parents in the DODAG iteration." What is meant by 'via their DODAG parents'? Change wording. (pg. 18, Sec. 3.6.1) 'strong global convergence' has not been defined. (pg. 20, Sec. 3.6.2.1) 'minHopRankIncrease' was first used here in the document. But it is more clearly "defined" in (pg. 59, Sec. 10) "The increase in rank must be at least MinHopRankIncrease." That text should be moved further up in the document. (pg. 21, Sec. 3.6.2.2) "... entails the probability of creating a loop" Replace 'probability' with 'chance'. Probability should be associated with a number. "... appropriate to the objective code point being used within the DODAG." Replace 'objective code point' with 'objective function' (pg. 25, Sec. 5.1.2) point #3, shouldn't Destination Advertisements Stored (S) also be in the list of fields that a node may update at each hop? (pg. 28, Sec. 5.1.3.5) "The Destination Prefix suboption is used when the DODAG root, or another node located upwards along the DODAG on the path to the DODAG root, needs to indicate that it offers connectivity to destination prefixes other than the default." Is the default destination prefix the DODAGID? Maybe you can put that in parentheses here. Otherwise, how is the default prefix specified (i.e. what messages are used, is the Destination Prefix suboption also used to specify the default prefix?)? (pg. 30, Sec. 5.3.2) "Second, the parent set is a restricted subset of the candidate neighbor set." remove 'restricted'. (pg. 31, Sec. 5.3.3.1) Point #1. Maybe also say that the sibling set may belong to different DODAG iterations? Or must they belong to the same DODAG iteration? (pg. 32, Sec. 5.3.3.1) Point #6 "(i.e. with the same DODAGID and a lower DODAGSequenceNumber)" Insert 'same RPLInstanceID and the' before "same DODAGID." (pg. 32, Sec. 5.3.3.1) This is the first mention of the parent set 'being depleted' on a node. The reader needs to make the connection that this is from parents jumping to the next iteration, that the node must remove those parents from its parent set. Perhaps it can be reworded more clearly. (pg. 32, Sec. 5.3.3.1) "...DODAG information should not be suppressed..." Clarify what is meant by suppressing the DODAG information. (pg. 37, Sec. 5.3.5) "If a node is not a member of a DODAG, it MUST suppress transmission of DIO messages." Replace 'suppress transmission' with 'not transmit'. (pg. 38, Sec. 5.3.5.1.2) "The node receives a modified DIO message from a DODAG parent" Clarify that 'modified' above means not matching a previously cached version of the DIO message from that DODAG parent. (pg. 40, Sec. 5.6) 'Race Condition' might be better than "Collision," since there are no collision of packets. (pg. 54, Sec. 7.2.2.2) "... packet that is flagged with a given RPLInstanceID" Replace 'flagged' with 'marked.' (pg. 56, Sec. 8) MLD is undefined and does not have a reference. (pg. 58, Sec. 10) "compute the DODAG" should be 'construct the DODAG' or 'optimize the DODAG' (pg. 59, Sec. 10) Remove sentence: "(This prevents the creation of a path of sibling links connecting a child with its parent.)" since it is no longer applicable with 1-hop sibling routing (pg. 59, Sec. 10) "Candidate neighbors that would cause self's rank to increase are ignored" Ignored for what? Parent Selection? Not for computing your own rank... remove this? (pg. 59, Sec. 10) What are "policy functions"? (pg. 60, Sec. 10) Remove sentence "Candidate neighbors of an equal rank to self (siblings) are ignored" since neighbors of equal rank are considered for siblings. (pg. 60, Sec. 11) ZERO_LIFETIME is not used anywhere else in the document. (pg. 61, Sec. 11) The timers do not belong in the "RPL Constants and Variables" section. (pg. 62, Sec. 12.1.2) "logical equivalent of the DODAG table that contains all the records about a DODAG is suppressed" Replace "suppressed" with 'marked as invalid.' (pg. 63, Sec. 12.1.6) Is "administrative preference" here the same as route preference in Figure 9 on pg. 27? I think the term 'administrative preference' has been used loosely throughout the document. -- Phoebus Chen Postdoctoral Researcher Automatic Control Lab, KTH (Royal Institute of Technology) http://www.ee.kth.se/~phoebus From pthubert@cisco.com Wed Mar 3 23:21: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 12AA428C4F7 for ; Wed, 3 Mar 2010 23:21:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.199 X-Spam-Level: X-Spam-Status: No, score=-8.199 tagged_above=-999 required=5 tests=[AWL=2.400, 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 QBjrsmCvDQh3 for ; Wed, 3 Mar 2010 23:21:23 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id AFD6E28C2C6 for ; Wed, 3 Mar 2010 23:21:21 -0800 (PST) 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: AvQAAO/tjkuQ/uCWe2dsb2JhbACbFRUBARYkBhyeAphUhHwE X-IronPort-AV: E=Sophos;i="4.49,580,1262563200"; d="scan'208";a="57702606" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 04 Mar 2010 07:21:22 +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 o247LMgr012670; Thu, 4 Mar 2010 07:21:22 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, 4 Mar 2010 08:21:22 +0100 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, 4 Mar 2010 08:21:19 +0100 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D01619849@XMB-AMS-107.cisco.com> In-Reply-To: <87vddd5kt7.fsf@kelsey-ws.hq.ember.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] [roll] #20: Question on Metric ID Thread-Index: Acq7AFoSw+RoiuN6Sme8SujKjMVMkQAach1Q References: <055.a3c60804880e85f93fc1826167be4fb6@tools.ietf.org><201003030805.30679.henning.rogge@fkie.fraunhofer.de> <6A2A459175DABE4BB11DE2026AA50A5D01594FD5@XMB-AMS-107.cisco.com> <87vddd5kt7.fsf@kelsey-ws.hq.ember.com> From: "Pascal Thubert (pthubert)" To: "Richard Kelsey" X-OriginalArrivalTime: 04 Mar 2010 07:21:22.0241 (UTC) FILETIME=[4AAFCB10:01CABB6B] Cc: roll@ietf.org Subject: Re: [Roll] [roll] #20: Question on Metric 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, 04 Mar 2010 07:21:25 -0000 Richard: With the current text, one could make a min increment that is say, 103. The division should be something that can be achieved at worst by a simple shift. Making the position of the dot a variable destroys the generic aspect of the Rank, and for example the capability to extend the network with OF0. I think that is very wrong. So while I agree to use a second byte to reflect fined grained metrics increments, I do not see the value of the added complexity of making the min increment anything.=20 Do you have a use case that justifies that? My take is that this deserves a ticket. Pascal > -----Original Message----- > From: Richard Kelsey [mailto:richard.kelsey@ember.com] > Sent: Wednesday, March 03, 2010 7:20 PM > To: Pascal Thubert (pthubert) > Cc: henning.rogge@fkie.fraunhofer.de; mijeom@gmail.com; roll@ietf.org > Subject: Re: [Roll] [roll] #20: Question on Metric ID >=20 > > Date: Wed, 3 Mar 2010 10:33:26 +0100 > > From: "Pascal Thubert (pthubert)" > > > > We have a min increment that acts as the location of the floating > > point. This is very generic, but it also makes the text, and probably > > the code that goes with it, a lot more complex than need be, in > > particular with the use of divisions and floor(). >=20 > I don't think it adds significant implementation complexity. > For any given metric the rank is a fixed-point number. >=20 > -Richard Kelsey From richard.kelsey@ember.com Thu Mar 4 05:10: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 262843A8647 for ; Thu, 4 Mar 2010 05:10:37 -0800 (PST) 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 NSVynxATWvsw for ; Thu, 4 Mar 2010 05:10:35 -0800 (PST) Received: from EMPIRE.hq.ember.com (mail.ember.com [74.10.175.227]) by core3.amsl.com (Postfix) with ESMTP id 39BAC3A7D1E for ; Thu, 4 Mar 2010 05:10:35 -0800 (PST) Received: from kelsey-ws.hq.ember.com ([192.168.81.37]) by EMPIRE.hq.ember.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 4 Mar 2010 08:13:14 -0500 Date: Thu, 04 Mar 2010 07:55:02 -0500 Message-Id: <87vddcw8k9.fsf@kelsey-ws.hq.ember.com> To: "Pascal Thubert (pthubert)" In-reply-to: <6A2A459175DABE4BB11DE2026AA50A5D01619849@XMB-AMS-107.cisco.com> (pthubert@cisco.com) From: Richard Kelsey References: <055.a3c60804880e85f93fc1826167be4fb6@tools.ietf.org><201003030805.30679.henning.rogge@fkie.fraunhofer.de> <6A2A459175DABE4BB11DE2026AA50A5D01594FD5@XMB-AMS-107.cisco.com> <87vddd5kt7.fsf@kelsey-ws.hq.ember.com> <6A2A459175DABE4BB11DE2026AA50A5D01619849@XMB-AMS-107.cisco.com> X-OriginalArrivalTime: 04 Mar 2010 13:13:14.0075 (UTC) FILETIME=[725202B0:01CABB9C] Cc: roll@ietf.org Subject: Re: [Roll] [roll] #20: Question on Metric 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, 04 Mar 2010 13:10:37 -0000 > Date: Thu, 4 Mar 2010 08:21:19 +0100 > From: "Pascal Thubert (pthubert)" Pascal, > With the current text, one could make a min increment that is say, 103. > The division should be something that can be achieved at worst by a > simple shift. We have to trust the writers of objective functions to do something sensible. > Making the position of the dot a variable destroys the generic aspect of > the Rank, and for example the capability to extend the network with OF0. The current draft requires that non-leaves understand the objective function: In the case where a node is unable to encounter a suitable RPL Instance using a known Objective Function, it may be configured to join a RPL Instance using an unknown Objective Function - but in that case only acting as a leaf node. Ranks from different objective functions are not comparable. > So while I agree to use a second byte to reflect fined grained metrics > increments, I do not see the value of the added complexity of making the > min increment anything. Do you have a use case that justifies that? This needs to be determined by the objective function, not by RPL. There is added complexity only if the objective function mandates it. I don't see why we should limit the authors of objective functions in this way. -Richard From anders.jagd@gmail.com Thu Mar 4 07:59: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 625423A8B21 for ; Thu, 4 Mar 2010 07:59:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TmsX6q0fBWa6 for ; Thu, 4 Mar 2010 07:59:44 -0800 (PST) Received: from mail-pv0-f172.google.com (mail-pv0-f172.google.com [74.125.83.172]) by core3.amsl.com (Postfix) with ESMTP id 498713A8B1F for ; Thu, 4 Mar 2010 07:59:44 -0800 (PST) Received: by pvg2 with SMTP id 2so966003pvg.31 for ; Thu, 04 Mar 2010 07:59:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=uGeHvoeWJiCP1iaSs0fhEM4rWMgBVLKPAmjeXjqMB0A=; b=AMcABbhAahm7Gi7Ztr+eTbzXFV1z1TGhMA69+vWkP7ypnRA9vV0HDd0S/Ij6ddMX+V uQuEdCU5bgzYb7Q61HQQsCdJ4Bo1L07DswjGFzJjfWp1zRYnwuypr7nMHzgG4/4skG4W AXtUM8hbLNzYQUOuzgzo2/lM1S7iEFhBiOPig= 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=Jx5Jk1ioYtP5alvHgoNusxq6DfQzWQ5g60u8SwTWNekXpfYqdf/PLF3SIYrGKPQt8G R3LOdQlzEp0pMFzAwjUz6yUQ4tn3b9r5qbPyFgv1tY9pe0Cgu2Q4qTDW8vcXsMY1aAic H5WB2yGCWJiW8cueUxVy+KmXXL+TukKCnoZi4= MIME-Version: 1.0 Received: by 10.142.247.21 with SMTP id u21mr558894wfh.85.1267718383272; Thu, 04 Mar 2010 07:59:43 -0800 (PST) In-Reply-To: <4B8E8E89.5080101@ieee.org> References: <4B8E70E3.8000100@ieee.org> <77b524e41003030716u6d008622n6ddb41d9ba56a2ab@mail.gmail.com> <6A2A459175DABE4BB11DE2026AA50A5D01619695@XMB-AMS-107.cisco.com> <4B8E8E89.5080101@ieee.org> Date: Thu, 4 Mar 2010 10:59:43 -0500 Message-ID: <77b524e41003040759n25144da5od1786c936dd82ffb@mail.gmail.com> From: Anders Jagd To: phoebus@ieee.org Content-Type: multipart/alternative; boundary=00504502c5f5e905a60480fbafa1 Cc: roll@ietf.org Subject: Re: [Roll] RPL spec v6: Preferred Parent for Rank Calculation and Packet Forwarding X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 04 Mar 2010 15:59:46 -0000 --00504502c5f5e905a60480fbafa1 Content-Type: text/plain; charset=ISO-8859-1 Phoebus, One thing to keep in mind is that RPL-06 - at least the way I look at it - is a "base" draft (others, feel free to correct me). It is extremely ambitious to generate a single RFC suitable for networks ranging from small home area "light switch control" networks to large scale urban smart grid networks with tens of thousands or even hundred of thousands of nodes. This is what I meant when I, in a previous mail, congratulated the WG on having achieved a good balance of content for such a base document. In a base document, general rules are defined, while specific algorithms are only hinted at. More work is clearly needed moving forwards in the form of "applicability" documents for various environments. That said, let me comment a bit further on the "preferred parent": Rank and aggregated metrics are not the same, but they will typically be somewhat (even strongly) correlated. As we all know, a nodes rank is given by preferred parent rank + some "delta". All other parents must have ranks less than the nodes rank, which, since "delta" is bounded, typically limits the number of parents with a rank higher than the preferred parent. In other words, often, if a node wants to maintain a lot of parents (for redundancy, load balancing, etc.), many (most) of them will have a lower rank (thus to some extent better aggregated metric) than the preferred parent. So, if a node chooses to forward a message through an alternative (not preferred) parent, chances are that quality/metrics are actually "better" than what the node "promised" downstream. This is all (intentionally) kept somewhat vague; applicability documents will need to make all of this more precise, in particular if we are to enable multi-vendor "heterogeneous" systems. As far as I understand, this could be left up to the objective function, which would specify how much (if at all) a node may deviate from it's "promised" aggregated metric, even to the (extreme) extent of limiting nodes to never route through non-preferred parents with worse metrics. A clear (and well known) dilemma can probably be seen here. If a node wants to maintain a lot of parents (redundancy, robustness, load balancing, ...), it will typically be difficult to, at the same time, achieve best possible aggregated metric. This since, in order to collect a lot of parents, the node will likely have to base it's rank (metric) on a "preferred" parent that is not the lowest ranked one. So, being "greedy" regarding parent set won't be "free" (no free lunch). I hope this helps. The above are obviously my interpretations, not necessarily the WGs, so I look forward to become educated in case I have (unintentionally) misinterpreted something. /Anders On Wed, Mar 3, 2010 at 11:30 AM, Phoebus Chen wrote: > Anders and Pascal, > > Thanks for your responses. Comments Inline below. > > > On 3/3/10 4:44 PM, Pascal Thubert (pthubert) wrote: > >> Hi Anders and Phoebus >> >> Quote: >> >> 5. If there is a DODAG iteration offering a route to a prefix matching >> the destination, then select *one of those DODAG parents* as a successor. >> >> End Quote >> >> Nothing written about giving preference to the "preferred parent". Not >> only is load balancing allowed, I believe it is encouraged (on a case by >> case basis as usual). >> >> */[Pascal] Most certainly. This also enables a quick reactivity to >> transient events that will not be reflected in the routing plane. /* >> > > Hmm, then I suppose that the text I quoted: > > > (pg. 30, Sec. 5.3.2) > "Finally, the preferred parent, a set of size one, is an element of the > parent set that is the preferred next hop in upward routes." > > > (pg. 56,57, Sec. 8) > "For a source inside the DODAG, the packet is passed to the preferred > parents, and if that fails then to the alternates in the DODAG." > > is outdated and will be removed in the next revision of the specification? > > I do agree that, in order to avoid confusion, we may want to get rid of >> the "preferred parent" terminology, unless there is some other "special >> attention" given to the preferred parent. >> >> */[Pascal] The preferred parent is still needed as the reference for the >> metrics computation. If a node derives its own metrics from that of a >> preferred parent, then it can be expected that this preferred parent >> also gets the bulk of the traffic, otherwise the node is not honest >> about the service that it is providing./* >> >> */Pascal/* >> >> > I see your point of why you might want to make a node get the bulk of the > traffic if it is the basis for the (single-path) metric computation. > But if a node really is doing load balancing, he is "not being honest" by > sending the bulk of the traffic to one parent anyways, regardless of whether > you call it a "preferred parent." ;) > > > As an aside, I'd like to point out that although this mailing list and the > drafts have been discussing mostly single-path metrics, there may be > multi-path / mesh metrics developed for RPL in the future. What I mean by a > multi-path/mesh metric is a metric assigned to a node that takes into > account all the paths through its parents. These aren't so common in the > literature, so I'll take an example of what I've worked with. Suppose you > want to define a metric that measures reliability, i.e. end-to-end packet > delivery probability, when you have a mesh of paths from a source to a sink. > Such a metric should reflect the fact that routing to a parent with many > equally good paths to the sink is better than routing to a parent that has > one good path to the sink. > > If you're skeptical that such multi-path metrics can be defined, you can > look at one example: > http://www.eecs.berkeley.edu/Pubs/TechRpts/2009/EECS-2009-75.html > pg. 73, Definition 2.3.2. In a nutshell, it measures the end-to-end > delivery probability assuming that a node will try to forward packets on its > outgoing links with equal probability, and calculates the probability that a > packet reaches the sink assuming all links are independent and stay up or > down (does not switch between the two) during the entire duration of the > packet transmission. > > I'll probably comment more on this later... after I've read the latest > version of the routing metrics document and can provide some feedback. > > > > -- > Phoebus Chen > Postdoctoral Researcher > Automatic Control Lab, KTH (Royal Institute of Technology) > http://www.ee.kth.se/~phoebus > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > --00504502c5f5e905a60480fbafa1 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Phoebus,

One thing to keep in mind is that RPL-06 - at l= east the way I look at it - is a "base" draft (others, feel free = to correct me). It is extremely ambitious to generate a single RFC suitable= for networks ranging from small home area "light switch control"= networks to large scale urban smart grid networks with tens of thousands o= r even hundred of thousands of nodes. This is what I meant when I, in a pre= vious mail, congratulated the WG on having achieved a good balance of conte= nt for such a base document.

In a base document, general rules are defined, while sp= ecific algorithms are only hinted at. More work is clearly needed moving fo= rwards in the form of "applicability" documents for various envir= onments.

That said, let me comment a bit further on the "pr= eferred parent":

Rank and aggregated metrics = are not the same, but they will typically be somewhat (even strongly) corre= lated. As we all know, a nodes rank is given by preferred parent rank + som= e "delta". All other parents must have ranks less than the nodes = rank, which, since "delta" is bounded, typically limits the numbe= r of parents with a rank higher than the preferred parent. In other words, = often, if a node wants to maintain a lot of parents (for redundancy, load b= alancing, etc.), many (most) of them will have a lower rank (thus to some e= xtent better aggregated metric) than the preferred parent. So, if a node ch= ooses to forward a message through an alternative (not preferred) parent, c= hances are that quality/metrics are actually "better" than what t= he node "promised" downstream.

This is all (intentionally) kept somewhat vague; applic= ability documents will need to make all of this more precise, in particular= if we are to enable multi-vendor "heterogeneous" systems. As far= as I understand, this could be left up to the objective function, which wo= uld specify how much (if at all) a node may deviate from it's "pro= mised" aggregated metric, even to the (extreme) extent of limiting nod= es to never route through non-preferred parents with worse metrics.

A clear (and well known) dilemma can probably be seen h= ere. If a node wants to maintain a lot of parents (redundancy, robustness, = load balancing, ...), it will typically be difficult to, at the same time, = achieve best possible aggregated metric. This since, in order to collect a = lot of parents, the node will likely have to base it's rank (metric) on= a "preferred" parent that is not the lowest ranked one. So, bein= g "greedy" regarding parent set won't be "free" (no= free lunch).

I hope this helps. The above are obviously my interpret= ations, not necessarily the WGs, so I look forward to become educated in ca= se I have (unintentionally) misinterpreted something.

/Anders

On Wed, Mar 3, 2010 at 11:30= AM, Phoebus Chen <phoebus@ieee.org> wrote:
Anders and Pascal,

Thanks for your responses. =A0Comments Inline below.


On 3/3/10 4:44 PM, Pascal Thubert (pthubert) wrote:
Hi Anders and Phoebus

Quote:

5. If there is a DODAG iteration offering a route to a prefix matching
the destination, then select *one of those DODAG parents* as a successor.
End Quote

Nothing written about giving preference to the "preferred parent"= . Not
only is load balancing allowed, I believe it is encouraged (on a case by case basis as usual).

*/[Pascal] Most certainly. This also enables a quick reactivity to
transient events that will not be reflected in the routing plane. /*

Hmm, then I suppose that the text I quoted:


(pg. 30, Sec. 5.3.2)
"Finally, the preferred parent, a set of size one, is an element of th= e parent set that is the preferred next hop in upward routes."


(pg. 56,57, Sec. 8)
"For a source inside the DODAG, the packet is passed to the preferred<= br> =A0parents, and if that fails then to the alternates in the DODAG."
is outdated and will be removed in the next revision of the specification?<= br>
I do agree that, in order to avoid confusion, we may want to get rid of
the "preferred parent" terminology, unless there is some other &q= uot;special
attention" given to the preferred parent.

*/[Pascal] The preferred parent is still needed as the reference for the metrics computation. If a node derives its own metrics from that of a
preferred parent, then it can be expected that this preferred parent
also gets the bulk of the traffic, otherwise the node is not honest
about the service that it is providing./*

*/Pascal/*


I see your point of why you might want to make a node get the bulk of the t= raffic if it is the basis for the (single-path) metric computation.
But if a node really is doing load balancing, he is "not being honest&= quot; by sending the bulk of the traffic to one parent anyways, regardless = of whether you call it a "preferred parent." ;)


As an aside, I'd like to point out that although this mailing list and = the drafts have been discussing mostly single-path metrics, there may be mu= lti-path / mesh metrics developed for RPL in the future. =A0What I mean by = a multi-path/mesh metric is a metric assigned to a node that takes into acc= ount all the paths through its parents. =A0These aren't so common in th= e literature, so I'll take an example of what I've worked with. Sup= pose you want to define a metric that measures reliability, i.e. end-to-end= packet delivery probability, when you have a mesh of paths from a source t= o a sink. =A0Such a metric should reflect the fact that routing to a parent= with many equally good paths to the sink is better than routing to a paren= t that has one good path to the sink.

If you're skeptical that such multi-path metrics can be defined, you ca= n look at one example:
http://www.eecs.berkeley.edu/Pubs/TechRpts/2009/EECS-2= 009-75.html
pg. 73, Definition 2.3.2. =A0In a nutshell, it measures the end-to-end deli= very probability assuming that a node will try to forward packets on its ou= tgoing links with equal probability, and calculates the probability that a = packet reaches the sink assuming all links are independent and stay up or d= own (does not switch between the two) during the entire duration of the pac= ket transmission.

I'll probably comment more on this later... after I've read the lat= est version of the routing metrics document and can provide some feedback.<= div>



--
Phoebus Chen
Postdoctoral Researcher
Automatic Control Lab, KTH (Royal Institute of Technology)
http://www.ee.k= th.se/~phoebus
_______________________________________________
Roll mailing list
Roll@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/roll

--00504502c5f5e905a60480fbafa1-- From trac@tools.ietf.org Fri Mar 5 02:36: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 29C333A8795 for ; Fri, 5 Mar 2010 02:36:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 RJctFKJPm3Ax for ; Fri, 5 Mar 2010 02:36:26 -0800 (PST) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 7296D3A8559 for ; Fri, 5 Mar 2010 02:36:26 -0800 (PST) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1NnUtN-0002kt-LR; Fri, 05 Mar 2010 02:36:25 -0800 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: mjkim@kt.com, jpv@cisco.com X-Trac-Project: roll Date: Fri, 05 Mar 2010 10:36:25 -0000 X-URL: http://tools.ietf.org/wg/roll/ X-Trac-Ticket-URL: https://svn.tools.ietf.org/wg/roll/trac/ticket/18#comment:2 Message-ID: <064.2a20a25a31ddeb41de55f5c2ba559806@tools.ietf.org> References: <055.28872d5d0fcf65e6839f1cd72771083c@tools.ietf.org> X-Trac-Ticket-ID: 18 In-Reply-To: <055.28872d5d0fcf65e6839f1cd72771083c@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: mjkim@kt.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] #18: Numeric Ranges in Routing Metric 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: Fri, 05 Mar 2010 10:36:27 -0000 #18: Numeric Ranges in Routing Metric --------------------------------+------------------------------------------- Reporter: jpv@… | Owner: mjkim@… Type: defect | Status: closed Priority: minor | Milestone: Component: routing-metrics | Version: Severity: Active WG Document | Resolution: fixed Keywords: | --------------------------------+------------------------------------------- Changes (by jpv@…): * status: new => closed * resolution: => fixed Comment: Here is the resolution after discussion on the mailing list: It's time to close on the #18. I think that throughput and latency can be better presented by unsigned integers as the below justification wrote. Latency can be expressed in units of milliseconds and throughput can be expressed in bytes per second. Mijeom. -- Ticket URL: roll From alexandru.petrescu@gmail.com Fri Mar 5 02:39: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 3147E3A87A3 for ; Fri, 5 Mar 2010 02:39:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lyHUjj8XwgGL for ; Fri, 5 Mar 2010 02:39:42 -0800 (PST) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.166.172.106]) by core3.amsl.com (Postfix) with ESMTP id 303223A7930 for ; Fri, 5 Mar 2010 02:39:42 -0800 (PST) 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 o25AdgUm019072 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 5 Mar 2010 11:39:42 +0100 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.2/8.14.2) with ESMTP id o25Adg6j019293; Fri, 5 Mar 2010 11:39:42 +0100 (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 o25Adgf6032311; Fri, 5 Mar 2010 11:39:42 +0100 Message-ID: <4B90DF6D.9070806@gmail.com> Date: Fri, 05 Mar 2010 11:39:41 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.9.1.8) Gecko/20100227 Thunderbird/3.0.3 MIME-Version: 1.0 To: roll@ietf.org References: <055.28872d5d0fcf65e6839f1cd72771083c@tools.ietf.org> <064.2a20a25a31ddeb41de55f5c2ba559806@tools.ietf.org> In-Reply-To: <064.2a20a25a31ddeb41de55f5c2ba559806@tools.ietf.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [Roll] [roll] #18: Numeric Ranges in Routing Metric X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 05 Mar 2010 10:39:43 -0000 Le 05/03/2010 11:36, roll issue tracker a écrit : > #18: Numeric Ranges in Routing Metric > --------------------------------+------------------------------------------- > Reporter: jpv@… | Owner: mjkim@… > Type: defect | Status: closed > Priority: minor | Milestone: > Component: routing-metrics | Version: > Severity: Active WG Document | Resolution: fixed > Keywords: | > --------------------------------+------------------------------------------- > Changes (by jpv@…): > > * status: new => closed > * resolution: => fixed > > > Comment: > > Here is the resolution after discussion on the mailing list: > > It's time to close on the #18. I think that throughput and latency can > be better presented by unsigned integers as the below justification > wrote. > Latency can be expressed in units of milliseconds But we just seemed to agree on micro-seconds instead, haven't we? Alex and throughput can > be expressed in bytes per second. > > Mijeom. > From pthubert@cisco.com Fri Mar 5 07:56: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 0DDFF28C169 for ; Fri, 5 Mar 2010 07:56:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.969 X-Spam-Level: X-Spam-Status: No, score=-4.969 tagged_above=-999 required=5 tests=[AWL=-2.370, 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 IJE7Py7dZys5 for ; Fri, 5 Mar 2010 07:56:50 -0800 (PST) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by core3.amsl.com (Postfix) with ESMTP id CBFF828C160 for ; Fri, 5 Mar 2010 07:56:49 -0800 (PST) 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: Ag8BABO5kEuQ/uCWe2dsb2JhbACbRRUBARYkBhyeXphahH0E X-IronPort-AV: E=Sophos;i="4.49,588,1262563200"; d="scan'208";a="4035276" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-2.cisco.com with ESMTP; 05 Mar 2010 15:23:58 +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 o25FumYj001297; Fri, 5 Mar 2010 15:56:48 GMT Received: from xmb-ams-107.cisco.com ([144.254.74.82]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 5 Mar 2010 16:56:48 +0100 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, 5 Mar 2010 16:56:44 +0100 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D0161A00A@XMB-AMS-107.cisco.com> In-Reply-To: <4B8EAC7D.4000809@ieee.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] RPL spec v6: request for minor clarifications (nits) Thread-Index: Acq7ALfnBEjNJLoRT5+Aw1GWUi7sOQBev5GA References: <4B8EAC7D.4000809@ieee.org> From: "Pascal Thubert (pthubert)" To: , X-OriginalArrivalTime: 05 Mar 2010 15:56:48.0290 (UTC) FILETIME=[76762020:01CABC7C] Subject: Re: [Roll] RPL spec v6: request for minor clarifications (nits) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 05 Mar 2010 15:56:52 -0000 Hi Phoebus=20 Thanks a huge bunch for your comments. You'll find some answers/discussion below.=20 We'll be pushing an 07 shortly and are trying to incorporate as much as we can for this. For clarity, I'd appreciate a bit more info on the following: (pg. 16, Sec. 3.4.6) "Nodes provision routing table entries, for the destinations specified by the DIO, via their DODAG parents in the DODAG iteration." What is meant by 'via their DODAG parents'? Change wording. [Pascal] A RIB route has the general form of 'this aggregate of destinations' via 'that router' with fancy metadata when we care. A FIB route has the general form of 'this aggregate of destinations' via 'that next_hop',the latter being usually expressed as a link local. As it goes, the DODAG parent is both the via_router and the next_hop for the default route, but we do not expect that the routers necessarily support a FIB so we use the via terminology. Since I fail to see what your issue is, I'd appreciate that you suggest an alternate text that could be more appropriate and address your concern? (pg. 28, Sec. 5.1.3.5) "The Destination Prefix suboption is used when the DODAG root, or another node located upwards along the DODAG on the path to the DODAG root, needs to indicate that it offers connectivity to destination prefixes other than the default." Is the default destination prefix the DODAGID? Maybe you can put that in parentheses here. Otherwise, how is the default prefix specified (i.e. what messages are used, is the Destination Prefix suboption also used to specify the default prefix?)? [Pascal] Actually, the 'G' bit used to tell you whether to install a default or not. Implicitly it could still, if the Goal of the DAG is to build a default. But considering how the meaning of the 'G' bit has been amended, that has become only remotely related and it makes sense to remove the 'other than default'. Still, we have the potential issue of a DAO conflicting with the DIO suboption by announcing the same reachability. Any suggestion here? (pg. 31, Sec. 5.3.3.1) Point #1. Maybe also say that the sibling set may belong to different DODAG iterations? Or must they belong to the same DODAG iteration? [Pascal] You can only compare Ranks within an iteration, that's the scope of the Rank. A node is a leaf in an iteration that it has not joined yet. If you mean sibling in a different DODAG of the same instance, there are use cases where you could do that and other where you could not, for instance depending on whether the root consumes the data or not. Today we do not allow that, but we could leave that up to the OF.=20 Pascal > -----Original Message----- > From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of > Phoebus Chen > Sent: Wednesday, March 03, 2010 7:38 PM > To: roll@ietf.org > Subject: [Roll] RPL spec v6: request for minor clarifications (nits) >=20 > Hello RPL authors, >=20 > Here are my list of nits and other minor suggestions for clarification on RPL > draft 6. These are points that I think I understand more clearly in the > document ;). >=20 >=20 > (pg. 10, Sec. 3.1.1) Rank should not be listed as a 'Topology Identifier' >=20 > (pg. 16, Sec. 3.4.6) > "Nodes provision routing table entries, for the destinations specified by the > DIO, via their DODAG parents in the DODAG iteration." > What is meant by 'via their DODAG parents'? Change wording. >=20 > (pg. 18, Sec. 3.6.1) 'strong global convergence' has not been defined. >=20 > (pg. 20, Sec. 3.6.2.1) 'minHopRankIncrease' was first used here in the > document. But it is more clearly "defined" in (pg. 59, Sec. 10) "The increase in > rank must be at least MinHopRankIncrease." > That text should be moved further up in the document. >=20 > (pg. 21, Sec. 3.6.2.2) > "... entails the probability of creating a loop" > Replace 'probability' with 'chance'. Probability should be associated with a > number. > "... appropriate to the objective code point being used within the DODAG." > Replace 'objective code point' with 'objective function' >=20 > (pg. 25, Sec. 5.1.2) point #3, shouldn't Destination Advertisements Stored (S) > also be in the list of fields that a node may update at each hop? >=20 > (pg. 28, Sec. 5.1.3.5) > "The Destination Prefix suboption is used when the DODAG root, or another > node located upwards along the DODAG on the path to the DODAG root, > needs to indicate that it offers connectivity to destination prefixes other than > the default." > Is the default destination prefix the DODAGID? Maybe you can put that in > parentheses here. Otherwise, how is the default prefix specified (i.e. what > messages are used, is the Destination Prefix suboption also used to specify > the default prefix?)? >=20 > (pg. 30, Sec. 5.3.2) > "Second, the parent set is a restricted subset of the candidate neighbor set." > remove 'restricted'. >=20 > (pg. 31, Sec. 5.3.3.1) Point #1. Maybe also say that the sibling set may belong > to different DODAG iterations? Or must they belong to the same DODAG > iteration? >=20 > (pg. 32, Sec. 5.3.3.1) Point #6 > "(i.e. with the same DODAGID and a lower DODAGSequenceNumber)" > Insert 'same RPLInstanceID and the' before "same DODAGID." >=20 > (pg. 32, Sec. 5.3.3.1) This is the first mention of the parent set 'being > depleted' on a node. The reader needs to make the connection that this is > from parents jumping to the next iteration, that the node must remove > those parents from its parent set. Perhaps it can be reworded more clearly. >=20 > (pg. 32, Sec. 5.3.3.1) > "...DODAG information should not be suppressed..." > Clarify what is meant by suppressing the DODAG information. >=20 > (pg. 37, Sec. 5.3.5) > "If a node is not a member of a DODAG, it MUST suppress transmission of > DIO messages." > Replace 'suppress transmission' with 'not transmit'. >=20 > (pg. 38, Sec. 5.3.5.1.2) > "The node receives a modified DIO message from a DODAG parent" > Clarify that 'modified' above means not matching a previously cached version > of the DIO message from that DODAG parent. >=20 > (pg. 40, Sec. 5.6) 'Race Condition' might be better than "Collision," > since there are no collision of packets. >=20 > (pg. 54, Sec. 7.2.2.2) > "... packet that is flagged with a given RPLInstanceID" > Replace 'flagged' with 'marked.' >=20 > (pg. 56, Sec. 8) MLD is undefined and does not have a reference. >=20 > (pg. 58, Sec. 10) "compute the DODAG" should be 'construct the DODAG' or > 'optimize the DODAG' >=20 > (pg. 59, Sec. 10) Remove sentence: > "(This prevents the creation of a path of sibling links connecting a child with > its parent.)" > since it is no longer applicable with 1-hop sibling routing >=20 > (pg. 59, Sec. 10) > "Candidate neighbors that would cause self's rank to increase are ignored" > Ignored for what? Parent Selection? Not for computing your own rank... > remove this? >=20 > (pg. 59, Sec. 10) What are "policy functions"? >=20 > (pg. 60, Sec. 10) Remove sentence > "Candidate neighbors of an equal rank to self (siblings) are ignored" > since neighbors of equal rank are considered for siblings. >=20 > (pg. 60, Sec. 11) ZERO_LIFETIME is not used anywhere else in the document. >=20 > (pg. 61, Sec. 11) The timers do not belong in the "RPL Constants and > Variables" section. >=20 > (pg. 62, Sec. 12.1.2) > "logical equivalent of the DODAG table that contains all the records about a > DODAG is suppressed" > Replace "suppressed" with 'marked as invalid.' >=20 > (pg. 63, Sec. 12.1.6) > Is "administrative preference" here the same as route preference in Figure 9 > on pg. 27? I think the term 'administrative preference' has been used loosely > throughout the document. >=20 >=20 >=20 > -- > Phoebus Chen > Postdoctoral Researcher > Automatic Control Lab, KTH (Royal Institute of Technology) > http://www.ee.kth.se/~phoebus > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From gnawali@cs.stanford.edu Fri Mar 5 12:58: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 4D1B23A8BD2; Fri, 5 Mar 2010 12:58:52 -0800 (PST) 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 AGGXAlkNn5la; Fri, 5 Mar 2010 12:58:51 -0800 (PST) Received: from cs-smtp-3.Stanford.EDU (cs-smtp-3.Stanford.EDU [171.64.64.27]) by core3.amsl.com (Postfix) with ESMTP id 929713A8AE6; Fri, 5 Mar 2010 12:58:51 -0800 (PST) Received: from mail-qy0-f202.google.com ([209.85.221.202]) by cs-smtp-3.Stanford.EDU with esmtpsa (TLSv1:RC4-MD5:128) (Exim 4.60) (envelope-from ) id 1Nnebm-00048B-5x; Fri, 05 Mar 2010 12:58:54 -0800 Received: by qyk40 with SMTP id 40so1436274qyk.23 for ; Fri, 05 Mar 2010 12:58:53 -0800 (PST) MIME-Version: 1.0 Received: by 10.224.114.17 with SMTP id c17mr757107qaq.7.1267822733157; Fri, 05 Mar 2010 12:58:53 -0800 (PST) In-Reply-To: References: <055.a3c60804880e85f93fc1826167be4fb6@tools.ietf.org> <201002230913.47381.henning.rogge@fkie.fraunhofer.de> <201002231122.41069.henning.rogge@fkie.fraunhofer.de> From: Omprakash Gnawali Date: Fri, 5 Mar 2010 12:58:33 -0800 Message-ID: To: MiJeom Kim Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Scan-Signature: 2d1a4fa5d0150c38835749a59b44c419 Cc: manet , roll@ietf.org Subject: Re: [Roll] [roll] #20: Question on Metric 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: Fri, 05 Mar 2010 20:58:52 -0000 On Tue, Mar 2, 2010 at 9:28 PM, MiJeom Kim wrote: > Hi, > > It=E2=80=99s time to summarize. > > - ETX >=3D 1, and 100 is enough for Max ETX since more than 10 ETX is > close to infinity. > - 8 bits are enough but need to avoid floating point format. =EF=83=A8 go= od to > multiply with a constant factor (C) like 256 > > I think Henning=E2=80=99s suggestion is good. But we don=E2=80=99t need a= big range > for ETX, but precision needs to be increased. So we can adjust it with > 5 bit mantissa and 3 bit exponent. > > So, we can represent (ETX * C) as (32 + a) * 2^b where 0 <=3D a <=3D 31 > and 0 <=3D b <=3D 7. If C is 128, the max possible ETX is 63 and if C is > 64, the max ETX is 126. So let=E2=80=99s try C =3D 64 and if ETX is bigge= r than > 126, we can just make it the possible max which is 126. > > All the numbers can be adjustable again, so please settle down the > issue with your ideas. > > I can=E2=80=99t understand the Overloading ETX thing. Nobody suggests > overloading ETX, I think. What do you mean by that in this thread, > Omprakash? It was the suggestion that not all ETX=3D1 links are the same so we should leave room in the metric to differentiate preferred ETX=3D1 link from the other ETX=3D1 links. The example that was used was, wired ETX=3D1 link vs wireless ETX=3D1 link. If we make minimum ETX value to be 1, then there is no room for such differentiation based on just the ETX metric. - om_p From phoebus@ieee.org Sat Mar 6 11:42: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 3574F3A8FCE for ; Sat, 6 Mar 2010 11:42:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.249 X-Spam-Level: X-Spam-Status: No, score=-106.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3f-L6Zy8hQwO for ; Sat, 6 Mar 2010 11:42:26 -0800 (PST) Received: from smtp-2.sys.kth.se (smtp-2.sys.kth.se [130.237.32.160]) by core3.amsl.com (Postfix) with ESMTP id 1AD833A8D97 for ; Sat, 6 Mar 2010 11:42:26 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by smtp-2.sys.kth.se (Postfix) with ESMTP id 1884514DCBF; Sat, 6 Mar 2010 20:41:58 +0100 (CET) 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 e0ENLl8TWNkJ; Sat, 6 Mar 2010 20:41:45 +0100 (CET) X-KTH-Auth: phoebus [130.237.50.62] X-KTH-mail-from: phoebus@ieee.org Received: from dhcp-50-62.s3.kth.se (dhcp-50-62.s3.kth.se [130.237.50.62]) by smtp-2.sys.kth.se (Postfix) with ESMTP id 8184614D846; Sat, 6 Mar 2010 20:41:44 +0100 (CET) Message-ID: <4B92AFF7.8000405@ieee.org> Date: Sat, 06 Mar 2010 20:41:43 +0100 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.8) Gecko/20100227 Thunderbird/3.0.3 MIME-Version: 1.0 To: "Pascal Thubert (pthubert)" References: <4B8EAC7D.4000809@ieee.org> <6A2A459175DABE4BB11DE2026AA50A5D0161A00A@XMB-AMS-107.cisco.com> In-Reply-To: <6A2A459175DABE4BB11DE2026AA50A5D0161A00A@XMB-AMS-107.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "roll@ietf.org" Subject: Re: [Roll] RPL spec v6: request for minor clarifications (nits) 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, 06 Mar 2010 19:42:29 -0000 Pascal, I'm glad to help. Thanks for taking my comments into consideration. You guys are doing a great job making progress on RPL... not an easy task to come up with one protocol to meet all the requirements. As for your questions, see my comments inline below. -- Phoebus Chen Postdoctoral Researcher Automatic Control Lab, KTH (Royal Institute of Technology) http://www.ee.kth.se/~phoebus On 3/5/10 4:56 PM, Pascal Thubert (pthubert) wrote: > Hi Phoebus > > Thanks a huge bunch for your comments. You'll find some > answers/discussion below. > We'll be pushing an 07 shortly and are trying to incorporate as much as > we can for this. > > For clarity, I'd appreciate a bit more info on the following: > > (pg. 16, Sec. 3.4.6) > "Nodes provision routing table entries, for the destinations specified > by the DIO, via their DODAG parents in the DODAG iteration." > What is meant by 'via their DODAG parents'? Change wording. > > [Pascal] A RIB route has the general form of 'this aggregate of > destinations' via 'that router' with fancy metadata when we care. A FIB > route has the general form of 'this aggregate of destinations' via > 'that next_hop',the latter being usually expressed as a link local. As > it goes, the DODAG parent is both the via_router and the next_hop for > the default route, but we do not expect that the routers necessarily > support a FIB so we use the via terminology. Since I fail to see what > your issue is, I'd appreciate that you suggest an alternate text that > could be more appropriate and address your concern? > When I wrote this, I thought the phrase just needed some grammar correction. Is "via_router" or "via router" standard terminology? If so, then maybe the phrase "via their DODAG parents" is fine as it is... I've just never heard of it before. As for alternate text, I think it would be clearer to add a reference to the actual data structures described in Section 12. My comments on the document have mostly ignored DAOs and downwards routing since, as I understand, that part of the protocol is still under heavy revisioning. But since you ask me to try to clarify the wording, I'll have to give my interpretation of how some of the DAO mechanisms work before proposing how I'd revise the sentence. (pg. 16, Section 3.5.1), and the rest of the document says that unicast DAOs propagate upwards along the DODAG, and never downwards. In order for any nodes besides your DODAG ancestors to hear your destination prefix advertisement, at some point your destination prefix must be crammed into a DIO Destination Prefix suboption so it can traverse downwards. Which means that not all destination prefixes advertised in a DIO are offered by ("located at") the root. There doesn't seem to be a field in the DAG Destination Prefix Suboption to distinguish between prefixes offered by the root and prefixes offered by other nodes. I haven't thought this through to see if it matters for correct protocol operation, but it might matter for what type of routing table entry you store. My understanding is that there are two types of routing tables described in Section 12.3: (pg. 64, Sec. 12.3.2) DAG Table (more than just a routing table) for destination prefixes advertised by the DODAG root (pg. 65, Sec. 12.3.3) Routing Table for destination prefixes advertised by other nodes in the DODAG I suppose one could also put destination prefixes offered by the DODAG root into the routing table, but I think it would be redundant (unless you wanted to associate a lifetime timer with each destination prefix offered by the root... I think adding a lifetime to the DAG Destination Prefix Suboption was discussed earlier but not yet decided?). If I were to reword the sentence, I would break it up into two bullet points: "Nodes provision DODAG table entries for the destinations offered by the DODAG root specified by the DIO (Section 12.3.2). A node creates a separate DODAG parent entry for each of its DODAG parents." "Nodes provision routing table entries for the destinations offered by non-root nodes specified by the DIO (Section 12.3.3). A node creates a separate routing table entry for each destination and DODAG parent that can serve as the next hop to that destination." I've written this based on the routing table described on (pg. 65, Sec. 12.3.3). I didn't mention the word "route" because the routing table entry doesn't refer to a single path through the network (after the first hop, there may be multiple paths available). Actually, Section 12.3.3 uses the word "route" even though the entries don't correspond to single-path routes, which confused me a little. And as I understand, each destination prefix can be associated with multiple routing table entries, since there is only one "Next Hop" field per routing table entry. If you think this is too much detail for Section 3.4.6 and you do intend to create a routing table (Section 12.3.3) entry for each destination regardless of whether it is offered by the root, then you can just replace the text with: "Nodes provision routing table entries for the destinations specified by the DIO. A node creates a separate routing table entry for each destination and DODAG parent that can serve as the next hop to that destination." > (pg. 28, Sec. 5.1.3.5) > "The Destination Prefix suboption is used when the DODAG root, or > another node located upwards along the DODAG on the path to the DODAG > root, needs to indicate that it offers connectivity to destination > prefixes other than the default." > Is the default destination prefix the DODAGID? Maybe you can put that > in parentheses here. Otherwise, how is the default prefix specified > (i.e. what messages are used, is the Destination Prefix suboption also > used to specify the default prefix?)? > > [Pascal] Actually, the 'G' bit used to tell you whether to install a > default or not. Implicitly it could still, if the Goal of the DAG is to > build a default. But considering how the meaning of the 'G' bit has been > amended, that has become only remotely related and it makes sense to > remove the 'other than default'. Still, we have the potential issue of a > DAO conflicting with the DIO suboption by announcing the same > reachability. Any suggestion here? > I'm okay with removing the "other than default." I'm not sure I follow what you mean by a DAO conflicting with a DIO suboption by announcing the same reachability. Do you mean when they both advertise the same destination prefix? Like when a destination prefix in a multicast DAO is propagated by a unicast DAO upwards (pg. 51, Section 6.2.9 point #4) and then back downwards in a DIO to a node that received the original multicast DAO? Is this a problem of not being able to compare DIO ranks and metrics to DAO ranks and metrics to choose a preferred route when you are given two options? > (pg. 31, Sec. 5.3.3.1) Point #1. Maybe also say that the sibling set > may belong to different DODAG iterations? Or must they belong to the > same DODAG iteration? > > [Pascal] You can only compare Ranks within an iteration, that's the > scope of the Rank. > A node is a leaf in an iteration that it has not joined yet. If you mean > sibling in a different DODAG of the same instance, there are use cases > where you could do that and other where you could not, for instance > depending on whether the root consumes the data or not. Today we do not > allow that, but we could leave that up to the OF. > You're right, it's a lot less confusing if we restrict siblings to the same DODAG iteration. Maybe that's better. When I was suggesting that the sibling set may belong to different DODAG iterations, I was thinking of what would be least restrictive but still have the protocol work. When your parents join the next DODAG iteration (same DODAG, new sequence number), you can still route packets to them if they are your 'future parents.' If your siblings join the next DODAG iteration before you, you will lose your siblings during the transition period. Do they automatically become 'future parents' until you join the next DODAG iteration? Or should there be some notion of 'future siblings'? When I wrote my comment, I wasn't thinking of routing to siblings in a different DODAG of the same instance. I agree that if we allow a node to only join one DODAG and it's parents to only be from one DODAG, it's less confusing if you only allow siblings to be in one DODAG. > > Pascal > > >> -----Original Message----- >> From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf > Of >> Phoebus Chen >> Sent: Wednesday, March 03, 2010 7:38 PM >> To: roll@ietf.org >> Subject: [Roll] RPL spec v6: request for minor clarifications (nits) >> >> Hello RPL authors, >> >> Here are my list of nits and other minor suggestions for clarification > on RPL >> draft 6. These are points that I think I understand more clearly in > the >> document ;). >> >> >> (pg. 10, Sec. 3.1.1) Rank should not be listed as a 'Topology > Identifier' >> >> (pg. 16, Sec. 3.4.6) >> "Nodes provision routing table entries, for the destinations specified > by the >> DIO, via their DODAG parents in the DODAG iteration." >> What is meant by 'via their DODAG parents'? Change wording. >> >> (pg. 18, Sec. 3.6.1) 'strong global convergence' has not been defined. >> >> (pg. 20, Sec. 3.6.2.1) 'minHopRankIncrease' was first used here in the >> document. But it is more clearly "defined" in (pg. 59, Sec. 10) "The > increase in >> rank must be at least MinHopRankIncrease." >> That text should be moved further up in the document. >> >> (pg. 21, Sec. 3.6.2.2) >> "... entails the probability of creating a loop" >> Replace 'probability' with 'chance'. Probability should be associated > with a >> number. >> "... appropriate to the objective code point being used within the > DODAG." >> Replace 'objective code point' with 'objective function' >> >> (pg. 25, Sec. 5.1.2) point #3, shouldn't Destination Advertisements > Stored (S) >> also be in the list of fields that a node may update at each hop? >> >> (pg. 28, Sec. 5.1.3.5) >> "The Destination Prefix suboption is used when the DODAG root, or > another >> node located upwards along the DODAG on the path to the DODAG root, >> needs to indicate that it offers connectivity to destination prefixes > other than >> the default." >> Is the default destination prefix the DODAGID? Maybe you can put that > in >> parentheses here. Otherwise, how is the default prefix specified > (i.e. what >> messages are used, is the Destination Prefix suboption also used to > specify >> the default prefix?)? >> >> (pg. 30, Sec. 5.3.2) >> "Second, the parent set is a restricted subset of the candidate > neighbor set." >> remove 'restricted'. >> >> (pg. 31, Sec. 5.3.3.1) Point #1. Maybe also say that the sibling set > may belong >> to different DODAG iterations? Or must they belong to the same DODAG >> iteration? >> >> (pg. 32, Sec. 5.3.3.1) Point #6 >> "(i.e. with the same DODAGID and a lower DODAGSequenceNumber)" >> Insert 'same RPLInstanceID and the' before "same DODAGID." >> >> (pg. 32, Sec. 5.3.3.1) This is the first mention of the parent set > 'being >> depleted' on a node. The reader needs to make the connection that > this is >> from parents jumping to the next iteration, that the node must remove >> those parents from its parent set. Perhaps it can be reworded more > clearly. >> >> (pg. 32, Sec. 5.3.3.1) >> "...DODAG information should not be suppressed..." >> Clarify what is meant by suppressing the DODAG information. >> >> (pg. 37, Sec. 5.3.5) >> "If a node is not a member of a DODAG, it MUST suppress transmission > of >> DIO messages." >> Replace 'suppress transmission' with 'not transmit'. >> >> (pg. 38, Sec. 5.3.5.1.2) >> "The node receives a modified DIO message from a DODAG parent" >> Clarify that 'modified' above means not matching a previously cached > version >> of the DIO message from that DODAG parent. >> >> (pg. 40, Sec. 5.6) 'Race Condition' might be better than "Collision," >> since there are no collision of packets. >> >> (pg. 54, Sec. 7.2.2.2) >> "... packet that is flagged with a given RPLInstanceID" >> Replace 'flagged' with 'marked.' >> >> (pg. 56, Sec. 8) MLD is undefined and does not have a reference. >> >> (pg. 58, Sec. 10) "compute the DODAG" should be 'construct the DODAG' > or >> 'optimize the DODAG' >> >> (pg. 59, Sec. 10) Remove sentence: >> "(This prevents the creation of a path of sibling links connecting a > child with >> its parent.)" >> since it is no longer applicable with 1-hop sibling routing >> >> (pg. 59, Sec. 10) >> "Candidate neighbors that would cause self's rank to increase are > ignored" >> Ignored for what? Parent Selection? Not for computing your own > rank... >> remove this? >> >> (pg. 59, Sec. 10) What are "policy functions"? >> >> (pg. 60, Sec. 10) Remove sentence >> "Candidate neighbors of an equal rank to self (siblings) are ignored" >> since neighbors of equal rank are considered for siblings. >> >> (pg. 60, Sec. 11) ZERO_LIFETIME is not used anywhere else in the > document. >> >> (pg. 61, Sec. 11) The timers do not belong in the "RPL Constants and >> Variables" section. >> >> (pg. 62, Sec. 12.1.2) >> "logical equivalent of the DODAG table that contains all the records > about a >> DODAG is suppressed" >> Replace "suppressed" with 'marked as invalid.' >> >> (pg. 63, Sec. 12.1.6) >> Is "administrative preference" here the same as route preference in > Figure 9 >> on pg. 27? I think the term 'administrative preference' has been used > loosely >> throughout the document. >> >> >> >> -- >> Phoebus Chen >> Postdoctoral Researcher >> Automatic Control Lab, KTH (Royal Institute of Technology) >> http://www.ee.kth.se/~phoebus >> _______________________________________________ >> Roll mailing list >> Roll@ietf.org >> https://www.ietf.org/mailman/listinfo/roll From mijeom@gmail.com Sun Mar 7 17:24: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 5F3393A67C2 for ; Sun, 7 Mar 2010 17:24:07 -0800 (PST) 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 7zKosjVqoDOg for ; Sun, 7 Mar 2010 17:24:06 -0800 (PST) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by core3.amsl.com (Postfix) with ESMTP id 12E2E3A67B5 for ; Sun, 7 Mar 2010 17:24:06 -0800 (PST) Received: by pwi3 with SMTP id 3so3836058pwi.31 for ; Sun, 07 Mar 2010 17:24:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=OBOO3U9RD2gzTNyTA3w+XpMPFOw1xRYd898YlVZ1eEs=; b=A8EanTYdgwLcQgw3VeUperx9OMc38SQY759G1Z3rXZG8r9PsLI/hnQJQa9VvN30GcS DlzPLl5q38K5Va2QprTHcjKrnpW1UQP6mvIdEPa1Pp9khp0XmOpmXjF1O6h1MnUgydVx nF+6Q2PSCaKS2ti70ILx6PP08oMo5uRyyDEck= 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=GLg/62GqmaFKtk47l6ueG99pN2/zn225sNvLZsGd+AFEaXlZzjuKfQl+MuINlKcGmo aynTPjVjzDR+Kov3o23VFANM09SFRWgfhwSvbBZOTW68I/3o3xsJ0tOwn1sMNmuF2VQ6 c7fo0FgR+36IS7dzd6T9k0urMM0Y3eg069Z0I= MIME-Version: 1.0 Received: by 10.142.62.15 with SMTP id k15mr2759844wfa.139.1268011446873; Sun, 07 Mar 2010 17:24:06 -0800 (PST) In-Reply-To: <4B90DF6D.9070806@gmail.com> References: <055.28872d5d0fcf65e6839f1cd72771083c@tools.ietf.org> <064.2a20a25a31ddeb41de55f5c2ba559806@tools.ietf.org> <4B90DF6D.9070806@gmail.com> Date: Mon, 8 Mar 2010 10:24:06 +0900 Message-ID: From: MiJeom Kim To: Alexandru Petrescu Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: roll@ietf.org Subject: Re: [Roll] [roll] #18: Numeric Ranges in Routing Metric X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 08 Mar 2010 01:24:08 -0000 Hi, Actually, we were in the middle of discussion. Let me resummerize the final options we have until now. 1. 16 bit unsigned integer --> it's not enough to express all cases since 65535 micro seconds (65 milliseconds) 2. 24 bit unsigned integer 3. 1 bit indication bit (to indicate millisecond or mirocsecond) + 15 bit insigned integer --> the range can be from 0 microseconds to 32767 milliseconds. Thanks, Mijeom. On Fri, Mar 5, 2010 at 7:39 PM, Alexandru Petrescu wrote: > Le 05/03/2010 11:36, roll issue tracker a =E9crit : >> >> #18: Numeric Ranges in Routing Metric >> >> --------------------------------+---------------------------------------= ---- >> =A0Reporter: =A0jpv@=85 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0 =A0 =A0Own= er: =A0mjkim@=85 >> =A0 =A0 =A0Type: =A0defect =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 =A0 =A0 Stat= us: =A0closed >> =A0Priority: =A0minor =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0Milestone: >> Component: =A0routing-metrics =A0 =A0 | =A0 =A0 =A0Version: >> =A0Severity: =A0Active WG Document =A0| =A0 Resolution: =A0fixed >> =A0Keywords: =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| >> >> --------------------------------+---------------------------------------= ---- >> Changes (by jpv@=85): >> >> =A0 * status: =A0new =3D> =A0closed >> =A0 * resolution: =A0=3D> =A0fixed >> >> >> Comment: >> >> =A0Here is the resolution after discussion on the mailing list: >> >> =A0It's time to close on the #18. I think that throughput and latency ca= n >> =A0be better presented by unsigned integers as the below justification >> =A0wrote. >> =A0Latency can be expressed in units of milliseconds > > But we just seemed to agree on micro-seconds instead, haven't we? > > Alex > > > =A0and throughput can >> >> =A0be expressed in bytes per second. >> >> =A0Mijeom. >> > > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > From mijeom@gmail.com Sun Mar 7 17:38: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 91CF63A67E1; Sun, 7 Mar 2010 17:38:19 -0800 (PST) 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 Rui+7N2J-IuR; Sun, 7 Mar 2010 17:38:18 -0800 (PST) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by core3.amsl.com (Postfix) with ESMTP id A9C513A67C2; Sun, 7 Mar 2010 17:38:18 -0800 (PST) Received: by pwi3 with SMTP id 3so3841530pwi.31 for ; Sun, 07 Mar 2010 17:38:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=ucnG7rFj0DIVOkkDU2PVIRTfr8/3l1jZ+vbGDvKfelo=; b=pVUnYNXmZKEleEaV0u6Be0ccaiuVEe/hv57QvMNrzPd+Yt0r6/MA27fQpi4P5YXTOQ 8rLmWvCBU7DS0itGiN7UmZ8Fl53j34ulsIqaYlPIRYv2pFTmvLIGAagGzrouiaX/82f2 qNGF91sPEcffy2Z9vLCAemxRumgmw6znHWBmo= 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=SZjlOnZm9xTmhf+h9eMBY2WpzgwU4GJWe6t60VXiO5kCvIR7CRqSMLJ8ryhd5/mOj7 Y2A3XWSnbOINxYDZ8Gyqw2O8oT1Ej43Ub7VXi1X5w/wgL2nxk8SljaXGBYcG64vp3tZK d5UBzN8drlG0toK4c6Dc3FKEgs8HSEyJ6THwc= MIME-Version: 1.0 Received: by 10.142.2.26 with SMTP id 26mr100755wfb.231.1268012299698; Sun, 07 Mar 2010 17:38:19 -0800 (PST) In-Reply-To: <108AEE8B-E296-44E3-BE37-1A43144B0281@unina.it> References: <055.a3c60804880e85f93fc1826167be4fb6@tools.ietf.org> <201002230913.47381.henning.rogge@fkie.fraunhofer.de> <201002231122.41069.henning.rogge@fkie.fraunhofer.de> <108AEE8B-E296-44E3-BE37-1A43144B0281@unina.it> Date: Mon, 8 Mar 2010 10:38:19 +0900 Message-ID: From: MiJeom Kim To: Marcello Caleffi Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: manet , roll@ietf.org Subject: Re: [Roll] [manet] [roll] #20: Question on Metric 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: Mon, 08 Mar 2010 01:38:20 -0000 Thank you for clearing the issue. So, we don't need the overloading ETX, then. How do you think about my suggestion: we can represent (ETX * C) as (32 + a) * 2^b where 0 <=3D a <=3D 31 and 0 <=3D b <=3D 7. If C is 128, the max possible ETX is 63 and if C is 64, the max ETX is 126. So let=E2=80=99s try C =3D 64 and if ETX is bigger than 126= , we can just make it the possible max which is 126. Other better ideas? let's close the ticket soon. Mijeom. On Sat, Mar 6, 2010 at 6:04 AM, Marcello Caleffi wrote: > If the delivery ratios are correctly estimated, there is no difference am= ong 1ETX links, wired wireless or anything else. > The issue is in correctly estimating the delivery ratios, but this does n= ot need additional bits in the header. > > Marcello > > > Il giorno 05/mar/2010, alle ore 21.58, Omprakash Gnawali ha scritto: > >> On Tue, Mar 2, 2010 at 9:28 PM, MiJeom Kim wrote: >>> Hi, >>> >>> It=E2=80=99s time to summarize. >>> >>> - ETX >=3D 1, and 100 is enough for Max ETX since more than 10 ETX is >>> close to infinity. >>> - 8 bits are enough but need to avoid floating point format. =EF=83=A8 = good to >>> multiply with a constant factor (C) like 256 >>> >>> I think Henning=E2=80=99s suggestion is good. But we don=E2=80=99t need= a big range >>> for ETX, but precision needs to be increased. So we can adjust it with >>> 5 bit mantissa and 3 bit exponent. >>> >>> So, we can represent (ETX * C) as (32 + a) * 2^b where 0 <=3D a <=3D 31 >>> and 0 <=3D b <=3D 7. If C is 128, the max possible ETX is 63 and if C i= s >>> 64, the max ETX is 126. So let=E2=80=99s try C =3D 64 and if ETX is big= ger than >>> 126, we can just make it the possible max which is 126. >>> >>> All the numbers can be adjustable again, so please settle down the >>> issue with your ideas. >>> >>> I can=E2=80=99t understand the Overloading ETX thing. Nobody suggests >>> overloading ETX, I think. What do you mean by that in this thread, >>> Omprakash? >> >> It was the suggestion that not all ETX=3D1 links are the same so we >> should leave room in the metric to differentiate preferred ETX=3D1 link >> from the other ETX=3D1 links. The example that was used was, wired ETX= =3D1 >> link vs wireless ETX=3D1 link. If we make minimum ETX value to be 1, >> then there is no room for such differentiation based on just the ETX >> metric. >> >> - om_p >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet > > From abr@sdesigns.dk Mon Mar 8 00:19: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 8C7A93A67D3 for ; Mon, 8 Mar 2010 00:19:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.238 X-Spam-Level: X-Spam-Status: No, score=-1.238 tagged_above=-999 required=5 tests=[AWL=-1.240, 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 2jNbt5k4kCI2 for ; Mon, 8 Mar 2010 00:19:31 -0800 (PST) Received: from mail.zen-sys.com (mail.zen-sys.com [195.215.56.170]) by core3.amsl.com (Postfix) with ESMTP id 369B23A6784 for ; Mon, 8 Mar 2010 00:19:29 -0800 (PST) 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_01CABE98.14AA9C2A" Date: Mon, 8 Mar 2010 09:19:32 +0100 Message-ID: <6D9687E95918C04A8B30A7D6DA805A3E01429F5F@zensys17.zensys.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: P2P performance with current RPL proposal Thread-Index: Acq+mBRA8djVC8wZSJSeUmM3XWRlWw== From: "Anders Brandt" To: "ROLL WG" Subject: [Roll] P2P performance with current RPL proposal X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Mar 2010 08:19:44 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CABE98.14AA9C2A Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello =20 I would like to probe the temperature of the WG on using DAOs to support P2P. =20 The building and home application spaces (and maybe others) have a few clearly defined requirements. It is not obvious to me how the current RPL proposal (cRPLp) can satisfy those requirements: =20 =20 In both cases it is the worst case scenario that hurts: =20 =20 P2P routing inside the PAN =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 cRPLp has no way of routing inside the PAN if you need more than one repeater. cRPLp has to go all the way to the top (maybe 4 hops up) and down again (maybe 4 hops down) to get just 2 hops to the side. =20 The consequence is high latency and high levels of background noise for nodes just outside the direct radio range. At the same time the risk of meeting a failing link is 4 times higher = =3D> latency may be much more than 4 times larger. =20 Latency may sound like a minor issue but it actually translates directly into lower battery lifetime. In the above (very realistic) example, the battery lifetime is reduced to 25% of what it should be. =20 We have lots of battery devices sending into the network: * PIR sensors turning on lights * Door locks sending alarms * Door/window sensors starting chimes * Smoke sensors triggering an alarm system =20 =20 =20 =20 Response time =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D The latency issue is important. When a user (real human being) presses a light button the user expects the light to turn on. cRPLp proposes that nodes in the tree periodically advertises their presence using DAOs. The periodicity is a real beast: Thanks to Trickle, the rate of updates in a (apparently) stable network is low. This is good since it leaves bandwidth for data. But it is not good if existing routes to my lamp fail and I do not get new routes to my lamp until it decides to send out a new DAO. My user will (with a good reason) not tolerate waiting for minutes for the light to turn on. =20 I have met two arguments to counter this concern: =20 A1: Well, your lamp can always send a DAO when it detects a problem. My answer: True, except that my lamp does not intend to send anything so it will never experience any problems from its side of the network. =20 A2: Well, you can increase the DAO rate to sub-second updates. My answer: Oh no. I get a very high degree of management traffic which limits my available bandwidth, increases the risk of collisions and even run the risk of violating EU legislation requiring me to only transmit in less than 1% of the time: http://focus.ti.com/lit/an/swra048/swra048.pdf =20 868 - 868.6 MHz: <1% =20 Reactiveness is hard to achieve via polling. =20 =20 =20 If you agree that this seems to be critical issues please raise your voice on the list. =20 Going forward =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =20 We need some reactive mechanism to reach lamps before the user decides to sue our companies. So is this possible? I think so. Existing commercial (non-IP) solutions are capable of re-routing quickly if they really have to. =20 Let me try scoping the requirements to a potential solution: (no different from the req. docs for home and building) =20 * P2P routing in any direction independent of the tree. =20 * On-demand P2P route discovery if requested by a real-time critical app. Data collection apps may be able to just wait for the next DAO update. =20 * Limited range of discovery mechanism: max 4 repeaters. A TTL field may limit the scope of the repeaters. =20 * Suboptimal routing and traffic bursts are accepted in exchange for quick route repair. But only as an exception. =20 =20 Just as an example, one existing home control technology uses a (source routing) variant of AODV for quick route repair. Nothing comes for free. The price is flooding - but not just flooding: Managed flooding using a distributed algorithm running in all participating nodes. The algorithm dampens the flooding in a time, volume and range perspective.=20 Some similar mechanism could be built into RPL for quick route repair. =20 =20 If anyone have alternative proposals, please bring it to the list. Now is the time. =20 =20 =20 Thanks, Anders ------_=_NextPart_001_01CABE98.14AA9C2A Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hello
 
I = would like to=20 probe the temperature of the WG on using DAOs to
support=20 P2P.
 
The = building and=20 home application spaces (and maybe others) have
a = few clearly=20 defined requirements.
It = is not obvious=20 to me how the current RPL proposal (cRPLp) can
satisfy those=20 requirements:
 
 
In = both cases it=20 is the worst case scenario that hurts:
 
 
P2P = routing inside=20 the PAN
=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
cRPLp has no way=20 of routing inside the PAN if you need more than
one = repeater.=20 cRPLp has to go all the way to the top (maybe 4 hops = up)
and = down again=20 (maybe 4 hops down) to get just 2 hops to the side.
 
The = consequence is=20 high latency and high levels of background noise
for nodes just = outside the=20 direct radio range.
At = the same time the risk of meeting a = failing link is=20 4 times higher =3D>
latency may be=20 much more than 4 times larger.
 
Latency may sound like a minor issue but it = actually=20 translates directly
into lower battery lifetime. In the above (very=20 realistic) example,
the battery lifetime is reduced to 25% of what = it should=20 be.
 
We have lots of battery devices sending into the = network:
* PIR sensors turning on = lights
* Door locks sending = alarms
* Door/window sensors starting=20 chimes
* Smoke sensors triggering an alarm=20 system
 
 
 
 
Response=20 time
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
The = latency issue=20 is important.
When = a user (real=20 human being) presses a light button the user expects
the = light to turn=20 on.
cRPLp proposes=20 that nodes in the tree periodically advertises their
presence using=20 DAOs.
The = periodicity is=20 a real beast:
Thanks to Trickle,=20 the rate of updates in a (apparently) stable network
is low. This is = good=20 since it leaves bandwidth for data.
But = it is not good=20 if existing routes to my lamp fail and I do not get
new routes=20 to my lamp until it=20 decides to send out a new DAO.
My = user will (with=20 a good reason) not tolerate waiting for minutes for
the = light to turn=20 on.
 
I = have met two=20 arguments to counter this concern:
 
A1: = Well, your=20 lamp can always send a DAO when it detects a = problem.
  My=20 answer:
  True,=20 except that my lamp does not intend to send anything
  so it will=20 never experience any problems from its side of the = network.
 
A2: = Well, you can=20 increase the DAO rate to sub-second updates.
  My=20 answer:
 =20 Oh no. I get a = very high=20 degree of management traffic which
  limits my=20 available bandwidth, increases the risk of collisions = and
  even run=20 the risk of violating EU legislation requiring me to = only
  transmit in=20 less than 1% of the time:
 =20 http://focus.ti.com/lit/an/swra048/swra048.pdf=
  868 - 868.6 MHz: <1%
 
 =20 Reactiveness is hard to achieve via polling.
 
 
 
If = you agree that=20 this seems to be critical issues please raise your
voice=20 on the=20 list.
 
Going forward
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
 
We need some reactive mechanism to reach lamps before the user=20 decides
to sue our companies.
So is this possible? I think=20 so.

Existing commercial (non-IP) solutions are = capable=20 of re-routing=20 quickly
if they really have = to.
 
Let me try scoping the requirements to a = potential=20 solution:
(no different from the req. docs for home and = building)
 
* P2P routing in any direction independent of = the=20 tree.
 
* On-demand P2P route discovery if = requested by a=20 real-time critical app.
  Data collection apps may be able to = just wait=20 for the next DAO=20 update.
 
* Limited range of discovery mechanism: max 4 = repeaters.
  A TTL field may limit the scope of the = repeaters.
 
* Suboptimal routing and traffic bursts are = accepted in=20 exchange
  for quick route repair. But only as an = exception.
 
 
Just as an example, one existing home = control=20 technology uses a
(source routing) variant of AODV for quick = route=20 repair.
Nothing comes for free. The price is flooding = - but not=20 just flooding:
Managed flooding using a distributed algorithm running = in=20 all
participating nodes.
The algorithm dampens the flooding in a=20 time, volume and range perspective.
Some similar mechanism could be built into = RPL for=20 quick route repair.
 
 
If anyone have alternative=20 proposals,=20 please bring it to the list.
Now = is the=20 time.
 
 
 
Thanks,
  = Anders
------_=_NextPart_001_01CABE98.14AA9C2A-- From yoav@yitran.com Mon Mar 8 00:39: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 2DDEA3A67A3 for ; Mon, 8 Mar 2010 00:39:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.288 X-Spam-Level: X-Spam-Status: No, score=-6.288 tagged_above=-999 required=5 tests=[AWL=0.311, 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 NeXJ1BX7LOyJ for ; Mon, 8 Mar 2010 00:39:17 -0800 (PST) Received: from na3sys009aog106.obsmtp.com (na3sys009aog106.obsmtp.com [74.125.149.77]) by core3.amsl.com (Postfix) with SMTP id 1DB4E3A63C9 for ; Mon, 8 Mar 2010 00:39:17 -0800 (PST) Received: from source ([74.125.82.173]) by na3sys009aob106.postini.com ([74.125.148.12]) with SMTP ID DSNKS5S3uBfIUrN0Um9/f+uuy9vt4CAKQFUL@postini.com; Mon, 08 Mar 2010 00:39:21 PST Received: by wyb36 with SMTP id 36so2919440wyb.4 for ; Mon, 08 Mar 2010 00:39:20 -0800 (PST) From: Yoav Ben-Yehezkel References: In-Reply-To: MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acq+mDLLV/CivcAdTKCEfW97MSP4vgAAKi5w Date: Mon, 8 Mar 2010 10:39:17 +0200 Received: by 10.216.87.18 with SMTP id x18mr1959591wee.201.1268037558685; Mon, 08 Mar 2010 00:39:18 -0800 (PST) Message-ID: <003e01cabe9a$d77524a0$865f6de0$@com> To: roll@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [Roll] Roll Digest, Vol 26, Issue 10 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 08 Mar 2010 08:39:20 -0000 Hi, I agree in general that P2P needs to be handled better for time critical applications and that time critical applications require either on-demand routing or on-demand routing repair mechanisms (if proactive routing fails there's no time to wait for it to be fixed eventually). It would also be helpful if ROLL defines a heuristic for joining a DODAG based on an applicative criteria (whether the root is interesting to the application)? For example, a bulb will be a root and switches operating the bulb will be a leaf nodes in that DODAG. That has a good chance of working in most cases and significantly reduces the amounts of floods required. Thanks, Yoav Hello I would like to probe the temperature of the WG on using DAOs to support P2P. The building and home application spaces (and maybe others) have a few clearly defined requirements. It is not obvious to me how the current RPL proposal (cRPLp) can satisfy those requirements: In both cases it is the worst case scenario that hurts: P2P routing inside the PAN ========================== cRPLp has no way of routing inside the PAN if you need more than one repeater. cRPLp has to go all the way to the top (maybe 4 hops up) and down again (maybe 4 hops down) to get just 2 hops to the side. The consequence is high latency and high levels of background noise for nodes just outside the direct radio range. At the same time the risk of meeting a failing link is 4 times higher => latency may be much more than 4 times larger. Latency may sound like a minor issue but it actually translates directly into lower battery lifetime. In the above (very realistic) example, the battery lifetime is reduced to 25% of what it should be. We have lots of battery devices sending into the network: * PIR sensors turning on lights * Door locks sending alarms * Door/window sensors starting chimes * Smoke sensors triggering an alarm system Response time ============= The latency issue is important. When a user (real human being) presses a light button the user expects the light to turn on. cRPLp proposes that nodes in the tree periodically advertises their presence using DAOs. The periodicity is a real beast: Thanks to Trickle, the rate of updates in a (apparently) stable network is low. This is good since it leaves bandwidth for data. But it is not good if existing routes to my lamp fail and I do not get new routes to my lamp until it decides to send out a new DAO. My user will (with a good reason) not tolerate waiting for minutes for the light to turn on. I have met two arguments to counter this concern: A1: Well, your lamp can always send a DAO when it detects a problem. My answer: True, except that my lamp does not intend to send anything so it will never experience any problems from its side of the network. A2: Well, you can increase the DAO rate to sub-second updates. My answer: Oh no. I get a very high degree of management traffic which limits my available bandwidth, increases the risk of collisions and even run the risk of violating EU legislation requiring me to only transmit in less than 1% of the time: http://focus.ti.com/lit/an/swra048/swra048.pdf 868 - 868.6 MHz: <1% Reactiveness is hard to achieve via polling. If you agree that this seems to be critical issues please raise your voice on the list. Going forward ============= We need some reactive mechanism to reach lamps before the user decides to sue our companies. So is this possible? I think so. Existing commercial (non-IP) solutions are capable of re-routing quickly if they really have to. Let me try scoping the requirements to a potential solution: (no different from the req. docs for home and building) * P2P routing in any direction independent of the tree. * On-demand P2P route discovery if requested by a real-time critical app. Data collection apps may be able to just wait for the next DAO update. * Limited range of discovery mechanism: max 4 repeaters. A TTL field may limit the scope of the repeaters. * Suboptimal routing and traffic bursts are accepted in exchange for quick route repair. But only as an exception. Just as an example, one existing home control technology uses a (source routing) variant of AODV for quick route repair. Nothing comes for free. The price is flooding - but not just flooding: Managed flooding using a distributed algorithm running in all participating nodes. The algorithm dampens the flooding in a time, volume and range perspective. Some similar mechanism could be built into RPL for quick route repair. If anyone have alternative proposals, please bring it to the list. Now is the time. Thanks, Anders -------------- next part -------------- An HTML attachment was scrubbed... URL: ------------------------------ _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll End of Roll Digest, Vol 26, Issue 10 ************************************ From yoav@yitran.com Mon Mar 8 00:48: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 A26F13A67F3 for ; Mon, 8 Mar 2010 00:48:15 -0800 (PST) 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 dEq3vdGYlxTh for ; Mon, 8 Mar 2010 00:48:14 -0800 (PST) Received: from na3sys009aog102.obsmtp.com (na3sys009aog102.obsmtp.com [74.125.149.69]) by core3.amsl.com (Postfix) with SMTP id AA8313A67ED for ; Mon, 8 Mar 2010 00:48:13 -0800 (PST) Received: from source ([74.125.82.182]) by na3sys009aob102.postini.com ([74.125.148.12]) with SMTP ID DSNKS5S50fOcsx/c3Vh7n+U/L83FHfzoCxFL@postini.com; Mon, 08 Mar 2010 00:48:18 PST Received: by mail-wy0-f182.google.com with SMTP id 32so3284717wyb.13 for ; Mon, 08 Mar 2010 00:48:17 -0800 (PST) From: Yoav Ben-Yehezkel References: MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acq+mDLLV/CivcAdTKCEfW97MSP4vgAAKi5wAADEkTA= Date: Mon, 8 Mar 2010 10:48:16 +0200 Received: by 10.216.165.146 with SMTP id e18mr2475239wel.54.1268038097096; Mon, 08 Mar 2010 00:48:17 -0800 (PST) Message-ID: <004401cabe9c$186db8e0$49492aa0$@com> To: Yoav Ben-Yehezkel , roll@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [Roll] P2P performance with current RPL proposal X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Mar 2010 08:48:15 -0000 Sorry about bad subject in previous email. This is in response to: Date: Mon, 8 Mar 2010 09:19:32 +0100 From: "Anders Brandt" Subject: [Roll] P2P performance with current RPL proposal To: "ROLL WG" Thanks, Yoav -----Original Message----- From: Yoav Ben-Yehezkel [mailto:yoav@yitran.com] Sent: Monday, March 08, 2010 10:39 AM To: 'roll@ietf.org' Cc: 'abr@sdesigns.dk' Subject: RE: Roll Digest, Vol 26, Issue 10 Hi, I agree in general that P2P needs to be handled better for time critical applications and that time critical applications require either on-demand routing or on-demand routing repair mechanisms (if proactive routing fails there's no time to wait for it to be fixed eventually). It would also be helpful if ROLL defines a heuristic for joining a DODAG based on an applicative criteria (whether the root is interesting to the application)? For example, a bulb will be a root and switches operating the bulb will be a leaf nodes in that DODAG. That has a good chance of working in most cases and significantly reduces the amounts of floods required. Thanks, Yoav Hello I would like to probe the temperature of the WG on using DAOs to support P2P. The building and home application spaces (and maybe others) have a few clearly defined requirements. It is not obvious to me how the current RPL proposal (cRPLp) can satisfy those requirements: In both cases it is the worst case scenario that hurts: P2P routing inside the PAN ========================== cRPLp has no way of routing inside the PAN if you need more than one repeater. cRPLp has to go all the way to the top (maybe 4 hops up) and down again (maybe 4 hops down) to get just 2 hops to the side. The consequence is high latency and high levels of background noise for nodes just outside the direct radio range. At the same time the risk of meeting a failing link is 4 times higher => latency may be much more than 4 times larger. Latency may sound like a minor issue but it actually translates directly into lower battery lifetime. In the above (very realistic) example, the battery lifetime is reduced to 25% of what it should be. We have lots of battery devices sending into the network: * PIR sensors turning on lights * Door locks sending alarms * Door/window sensors starting chimes * Smoke sensors triggering an alarm system Response time ============= The latency issue is important. When a user (real human being) presses a light button the user expects the light to turn on. cRPLp proposes that nodes in the tree periodically advertises their presence using DAOs. The periodicity is a real beast: Thanks to Trickle, the rate of updates in a (apparently) stable network is low. This is good since it leaves bandwidth for data. But it is not good if existing routes to my lamp fail and I do not get new routes to my lamp until it decides to send out a new DAO. My user will (with a good reason) not tolerate waiting for minutes for the light to turn on. I have met two arguments to counter this concern: A1: Well, your lamp can always send a DAO when it detects a problem. My answer: True, except that my lamp does not intend to send anything so it will never experience any problems from its side of the network. A2: Well, you can increase the DAO rate to sub-second updates. My answer: Oh no. I get a very high degree of management traffic which limits my available bandwidth, increases the risk of collisions and even run the risk of violating EU legislation requiring me to only transmit in less than 1% of the time: http://focus.ti.com/lit/an/swra048/swra048.pdf 868 - 868.6 MHz: <1% Reactiveness is hard to achieve via polling. If you agree that this seems to be critical issues please raise your voice on the list. Going forward ============= We need some reactive mechanism to reach lamps before the user decides to sue our companies. So is this possible? I think so. Existing commercial (non-IP) solutions are capable of re-routing quickly if they really have to. Let me try scoping the requirements to a potential solution: (no different from the req. docs for home and building) * P2P routing in any direction independent of the tree. * On-demand P2P route discovery if requested by a real-time critical app. Data collection apps may be able to just wait for the next DAO update. * Limited range of discovery mechanism: max 4 repeaters. A TTL field may limit the scope of the repeaters. * Suboptimal routing and traffic bursts are accepted in exchange for quick route repair. But only as an exception. Just as an example, one existing home control technology uses a (source routing) variant of AODV for quick route repair. Nothing comes for free. The price is flooding - but not just flooding: Managed flooding using a distributed algorithm running in all participating nodes. The algorithm dampens the flooding in a time, volume and range perspective. Some similar mechanism could be built into RPL for quick route repair. If anyone have alternative proposals, please bring it to the list. Now is the time. Thanks, Anders -------------- next part -------------- An HTML attachment was scrubbed... URL: ------------------------------ _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll End of Roll Digest, Vol 26, Issue 10 ************************************ From trac@tools.ietf.org Mon Mar 8 02:11: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 6B1633A6825 for ; Mon, 8 Mar 2010 02:11:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.46 X-Spam-Level: X-Spam-Status: No, score=-102.46 tagged_above=-999 required=5 tests=[AWL=0.140, BAYES_00=-2.599, 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 mVm5biRl+7+O for ; Mon, 8 Mar 2010 02:11:27 -0800 (PST) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 6C5A13A67D3 for ; Mon, 8 Mar 2010 02:11:26 -0800 (PST) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1NoZvs-0004cc-3B; Mon, 08 Mar 2010 02:11:28 -0800 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: abr@sdesigns.dk, jpv@cisco.com X-Trac-Project: roll Date: Mon, 08 Mar 2010 10:11:27 -0000 X-URL: http://tools.ietf.org/wg/roll/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/roll/trac/ticket/24 Message-ID: <055.3e06cbe3d0929bb0b64fd4bd0b090661@tools.ietf.org> X-Trac-Ticket-ID: 24 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: abr@sdesigns.dk, 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] #24: Discussion P2P 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, 08 Mar 2010 10:11:30 -0000 #24: Discussion P2P -----------------------------------+---------------------------------------- Reporter: jpv@… | Owner: abr@… Type: task | Status: new Priority: major | Milestone: Component: building-routing-reqs | Version: Severity: Candidate WG Document | Keywords: -----------------------------------+---------------------------------------- Hello I would like to probe the temperature of the WG on using DAOs to support P2P. The building and home application spaces (and maybe others) have a few clearly defined requirements. It is not obvious to me how the current RPL proposal (cRPLp) can satisfy those requirements: In both cases it is the worst case scenario that hurts: P2P routing inside the PAN ========================== cRPLp has no way of routing inside the PAN if you need more than one repeater. cRPLp has to go all the way to the top (maybe 4 hops up) and down again (maybe 4 hops down) to get just 2 hops to the side. The consequence is high latency and high levels of background noise for nodes just outside the direct radio range. At the same time the risk of meeting a failing link is 4 times higher => latency may be much more than 4 times larger. Latency may sound like a minor issue but it actually translates directly into lower battery lifetime. In the above (very realistic) example, the battery lifetime is reduced to 25% of what it should be. We have lots of battery devices sending into the network: * PIR sensors turning on lights * Door locks sending alarms * Door/window sensors starting chimes * Smoke sensors triggering an alarm system Response time ============= The latency issue is important. When a user (real human being) presses a light button the user expects the light to turn on. cRPLp proposes that nodes in the tree periodically advertises their presence using DAOs. The periodicity is a real beast: Thanks to Trickle, the rate of updates in a (apparently) stable network is low. This is good since it leaves bandwidth for data. But it is not good if existing routes to my lamp fail and I do not get new routes to my lamp until it decides to send out a new DAO. My user will (with a good reason) not tolerate waiting for minutes for the light to turn on. I have met two arguments to counter this concern: A1: Well, your lamp can always send a DAO when it detects a problem. My answer: True, except that my lamp does not intend to send anything so it will never experience any problems from its side of the network. A2: Well, you can increase the DAO rate to sub-second updates. My answer: Oh no. I get a very high degree of management traffic which limits my available bandwidth, increases the risk of collisions and even run the risk of violating EU legislation requiring me to only transmit in less than 1% of the time: http://focus.ti.com/lit/an/swra048/swra048.pdf 868 - 868.6 MHz: <1% Reactiveness is hard to achieve via polling. If you agree that this seems to be critical issues please raise your voice on the list. Going forward ============= We need some reactive mechanism to reach lamps before the user decides to sue our companies. So is this possible? I think so. Existing commercial (non-IP) solutions are capable of re-routing quickly if they really have to. Let me try scoping the requirements to a potential solution: (no different from the req. docs for home and building) * P2P routing in any direction independent of the tree. * On-demand P2P route discovery if requested by a real-time critical app. Data collection apps may be able to just wait for the next DAO update. * Limited range of discovery mechanism: max 4 repeaters. A TTL field may limit the scope of the repeaters. * Suboptimal routing and traffic bursts are accepted in exchange for quick route repair. But only as an exception. Just as an example, one existing home control technology uses a (source routing) variant of AODV for quick route repair. Nothing comes for free. The price is flooding - but not just flooding: Managed flooding using a distributed algorithm running in all participating nodes. The algorithm dampens the flooding in a time, volume and range perspective. Some similar mechanism could be built into RPL for quick route repair. If anyone have alternative proposals, please bring it to the list. Now is the time. Thanks, Anders _____________________________________ -- Ticket URL: roll From jpv@cisco.com Mon Mar 8 02:12: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 D35E43A689F for ; Mon, 8 Mar 2010 02:12:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P1YfWbIL3KJ6 for ; Mon, 8 Mar 2010 02:12:47 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id AAE303A6901 for ; Mon, 8 Mar 2010 02:12:46 -0800 (PST) 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: AhgBAANclEuQ/uCWe2dsb2JhbACbJRUBAQsLJAYcoAuXZoR4BA X-IronPort-AV: E=Sophos;i="4.49,601,1262563200"; d="scan'208,217";a="57804867" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 08 Mar 2010 10:12:49 +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 o28ACnAP024363; Mon, 8 Mar 2010 10:12:49 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, 8 Mar 2010 11:12:49 +0100 Received: from ams-jvasseur-8713.cisco.com ([10.55.201.132]) by xfe-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 8 Mar 2010 11:12:48 +0100 Message-Id: <3694878B-D4C9-4D11-9DDC-5597EC168B58@cisco.com> From: JP Vasseur To: Anders Brandt In-Reply-To: <6D9687E95918C04A8B30A7D6DA805A3E01429F5F@zensys17.zensys.local> Content-Type: multipart/alternative; boundary=Apple-Mail-466--174324770 Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 8 Mar 2010 11:12:47 +0100 References: <6D9687E95918C04A8B30A7D6DA805A3E01429F5F@zensys17.zensys.local> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 08 Mar 2010 10:12:48.0106 (UTC) FILETIME=[E7313CA0:01CABEA7] Cc: ROLL WG Subject: Re: [Roll] P2P performance with current RPL proposal X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Mar 2010 10:12:50 -0000 --Apple-Mail-466--174324770 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Ticket #24 was created. On Mar 8, 2010, at 9:19 AM, Anders Brandt wrote: > Hello > > I would like to probe the temperature of the WG on using DAOs to > support P2P. > > The building and home application spaces (and maybe others) have > a few clearly defined requirements. > It is not obvious to me how the current RPL proposal (cRPLp) can > satisfy those requirements: > > > In both cases it is the worst case scenario that hurts: > > > P2P routing inside the PAN > ========================== > cRPLp has no way of routing inside the PAN if you need more than > one repeater. cRPLp has to go all the way to the top (maybe 4 hops up) > and down again (maybe 4 hops down) to get just 2 hops to the side. > > The consequence is high latency and high levels of background noise > for nodes just outside the direct radio range. > At the same time the risk of meeting a failing link is 4 times > higher => > latency may be much more than 4 times larger. > > Latency may sound like a minor issue but it actually translates > directly > into lower battery lifetime. In the above (very realistic) example, > the battery lifetime is reduced to 25% of what it should be. > > We have lots of battery devices sending into the network: > * PIR sensors turning on lights > * Door locks sending alarms > * Door/window sensors starting chimes > * Smoke sensors triggering an alarm system > > > > > Response time > ============= > The latency issue is important. > When a user (real human being) presses a light button the user expects > the light to turn on. > cRPLp proposes that nodes in the tree periodically advertises their > presence using DAOs. > The periodicity is a real beast: > Thanks to Trickle, the rate of updates in a (apparently) stable > network > is low. This is good since it leaves bandwidth for data. > But it is not good if existing routes to my lamp fail and I do not get > new routes to my lamp until it decides to send out a new DAO. > My user will (with a good reason) not tolerate waiting for minutes for > the light to turn on. > > I have met two arguments to counter this concern: > > A1: Well, your lamp can always send a DAO when it detects a problem. > My answer: > True, except that my lamp does not intend to send anything > so it will never experience any problems from its side of the > network. > > A2: Well, you can increase the DAO rate to sub-second updates. > My answer: > Oh no. I get a very high degree of management traffic which > limits my available bandwidth, increases the risk of collisions and > even run the risk of violating EU legislation requiring me to only > transmit in less than 1% of the time: > http://focus.ti.com/lit/an/swra048/swra048.pdf > 868 - 868.6 MHz: <1% > > Reactiveness is hard to achieve via polling. > > > > If you agree that this seems to be critical issues please raise your > voice on the list. > > Going forward > ============= > > We need some reactive mechanism to reach lamps before the user decides > to sue our companies. > So is this possible? I think so. > > Existing commercial (non-IP) solutions are capable of re-routing > quickly > if they really have to. > > Let me try scoping the requirements to a potential solution: > (no different from the req. docs for home and building) > > * P2P routing in any direction independent of the tree. > > * On-demand P2P route discovery if requested by a real-time critical > app. > Data collection apps may be able to just wait for the next DAO > update. > > * Limited range of discovery mechanism: max 4 repeaters. > A TTL field may limit the scope of the repeaters. > > * Suboptimal routing and traffic bursts are accepted in exchange > for quick route repair. But only as an exception. > > > Just as an example, one existing home control technology uses a > (source routing) variant of AODV for quick route repair. > Nothing comes for free. The price is flooding - but not just flooding: > Managed flooding using a distributed algorithm running in all > participating nodes. > The algorithm dampens the flooding in a time, volume and range > perspective. > Some similar mechanism could be built into RPL for quick route repair. > > > If anyone have alternative proposals, please bring it to the list. > Now is the time. > > > > Thanks, > Anders > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll --Apple-Mail-466--174324770 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Ticket #24 was = created.

On Mar 8, 2010, at 9:19 AM, Anders Brandt = wrote:

Hello
 
I would = like to probe the temperature of the WG on using DAOs = to
support P2P.
 
The = building and home application spaces (and maybe others) = have
a few clearly defined = requirements.
It is not = obvious to me how the current RPL proposal (cRPLp) = can
satisfy those = requirements:
 
 
In both = cases it is the worst case scenario that hurts:
=
 
 
P2P = routing inside the PAN
=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
cRPLp has = no way of routing inside the PAN if you need more = than
one repeater. cRPLp has to go all the way to = the top (maybe 4 hops up)
and down = again (maybe 4 hops down) to get just 2 hops to the = side.
 
The = consequence is high latency and high levels of background noise
for = nodes just outside the direct radio range.
=
At the same = time the risk of meeting a failing link is 4 times higher = =3D>
latency may be much more than 4 times = larger.
 
Latency may sound like a minor issue but it = actually translates directly
into lower battery lifetime. In the = above (very realistic) example,
the battery lifetime is reduced to 25% of = what it should be.
 
We have lots of battery devices sending into = the network:
* PIR sensors turning on = lights
* Door locks sending = alarms
* Door/window sensors starting = chimes
=
* Smoke = sensors triggering an alarm system
=
 
 
=
 
 
Response = time
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
The latency issue is = important.
When a = user (real human being) presses a light button the user = expects
the light to turn on.
=
cRPLp proposes that nodes in the tree periodically advertises = their
presence using DAOs.
=
The periodicity is a real beast:
=
Thanks to Trickle, the rate of updates in a (apparently) = stable network
is low. This is good since it leaves bandwidth for = data.
But it is not good if existing routes to my = lamp fail and I do not get
new = routes to my lamp until it decides to send out a new = DAO.
My user = will (with a good reason) not tolerate waiting for minutes = for
the light to turn on.
=
 
I have = met two arguments to counter this concern:
=
 
A1: Well, = your lamp can always send a DAO when it detects a = problem.
  My answer:
=
  True, except that my lamp does not intend to send = anything
  so it will never experience any = problems from its side of the network.
 
A2: Well, = you can increase the DAO rate to sub-second updates.
=
  My answer:
  Oh no. I get a very high = degree of management traffic which
=
  limits my available bandwidth, increases the risk of = collisions and
  = even run the risk of violating EU legislation requiring me to = only
  transmit in less than 1% of the = time:
 
  = Reactiveness is hard to achieve via polling.
=
 
 
 
If you = agree that this seems to be critical issues please raise = your
voice on the = list.
 
Going forward
=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
 
We need some reactive = mechanism to reach lamps = before the user decides
to sue our companies.
=
So is = this possible? I think so.

Existing commercial (non-IP) = solutions are capable of re-routing = quickly
if they really have = to.
 
=
Let me = try scoping the requirements to a potential = solution:
(no different from the req. docs for home = and building)
 
=
* P2P = routing in any direction independent of the = tree.
 
=
* = On-demand P2P route discovery if requested by a real-time critical = app.
  Data collection apps may be able to just wait for the = next DAO = update.
 
=
* = Limited range of discovery mechanism: max 4 = repeaters.
  A TTL field may limit the scope of = the repeaters.
 
=
* = Suboptimal routing and traffic bursts are accepted in = exchange
  for quick route repair. But only as = an exception.
 
=
 
Just as an example, one existing home = control technology uses a
(source routing) variant of AODV for = quick route repair.
Nothing comes for free. The price is = flooding - but not just flooding:
Managed flooding using a = distributed algorithm running in all
participating = nodes.
The algorithm dampens the flooding in a = time, volume and range perspective.
=
Some = similar mechanism could be built into RPL for quick route = repair.
 
=
 
=
If anyone have = alternative proposals, please bring it to the = list.
Now is = the time.
 
 
 
Thanks,
=
  = Anders
= _______________________________________________
Roll mailing = list
Roll@ietf.org
https://www.ietf.org/ma= ilman/listinfo/roll

= --Apple-Mail-466--174324770-- From trac@tools.ietf.org Mon Mar 8 02:14: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 1AA073A67E7 for ; Mon, 8 Mar 2010 02:13:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.469 X-Spam-Level: X-Spam-Status: No, score=-102.469 tagged_above=-999 required=5 tests=[AWL=0.131, BAYES_00=-2.599, 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 0k4dVBpipPM3 for ; Mon, 8 Mar 2010 02:13:54 -0800 (PST) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id E93763A67A4 for ; Mon, 8 Mar 2010 02:13:53 -0800 (PST) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1NoZyG-0006vM-NJ; Mon, 08 Mar 2010 02:13:56 -0800 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: abr@sdesigns.dk, jpv@cisco.com X-Trac-Project: roll Date: Mon, 08 Mar 2010 10:13:56 -0000 X-URL: http://tools.ietf.org/wg/roll/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/roll/trac/ticket/24#comment:1 Message-ID: <064.4794b241e11b5cb24d32b7747a789572@tools.ietf.org> References: <055.3e06cbe3d0929bb0b64fd4bd0b090661@tools.ietf.org> X-Trac-Ticket-ID: 24 In-Reply-To: <055.3e06cbe3d0929bb0b64fd4bd0b090661@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: abr@sdesigns.dk, 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] #24: Discussion P2P 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, 08 Mar 2010 10:14:00 -0000 #24: Discussion P2P -----------------------------------+---------------------------------------- Reporter: jpv@… | Owner: abr@… Type: task | Status: new Priority: major | Milestone: Component: rpl | Version: Severity: Candidate WG Document | Keywords: -----------------------------------+---------------------------------------- Changes (by jpv@…): * component: building-routing-reqs => rpl -- Ticket URL: roll From alexandru.petrescu@gmail.com Mon Mar 8 02:45: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 BFFED3A6892 for ; Mon, 8 Mar 2010 02:45:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.194 X-Spam-Level: X-Spam-Status: No, score=-2.194 tagged_above=-999 required=5 tests=[AWL=0.055, 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 u5aJk7eCwxOK for ; Mon, 8 Mar 2010 02:45:51 -0800 (PST) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.1]) by core3.amsl.com (Postfix) with ESMTP id 988833A67ED for ; Mon, 8 Mar 2010 02:45:50 -0800 (PST) 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 o28Ajo0G026687 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 8 Mar 2010 11:45:51 +0100 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.2/8.14.2) with ESMTP id o28AjoGC006911; Mon, 8 Mar 2010 11:45:50 +0100 (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 o28AjoWP010107; Mon, 8 Mar 2010 11:45:50 +0100 Message-ID: <4B94D55E.7080302@gmail.com> Date: Mon, 08 Mar 2010 11:45:50 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.9.1.8) Gecko/20100227 Thunderbird/3.0.3 MIME-Version: 1.0 To: MiJeom Kim References: <055.28872d5d0fcf65e6839f1cd72771083c@tools.ietf.org> <064.2a20a25a31ddeb41de55f5c2ba559806@tools.ietf.org> <4B90DF6D.9070806@gmail.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: roll@ietf.org Subject: Re: [Roll] [roll] #18: Numeric Ranges in Routing Metric X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 08 Mar 2010 10:45:51 -0000 Le 08/03/2010 02:24, MiJeom Kim a écrit : > Hi, > > Actually, we were in the middle of discussion. Let me resummerize the > final options we have until now. > > 1. 16 bit unsigned integer --> it's not enough to express all cases > since 65535 micro seconds (65 milliseconds) Ok I guess we need to discard this. > 2. 24 bit unsigned integer This could represent 0..16777216 microseconds i.e. 0..16777,216 milliseconds i.e. 0.. 16,777216 seconds delay. > 3. 1 bit indication bit (to indicate millisecond or mirocsecond) + > 15 bit insigned integer --> the range can be from 0 microseconds to > 32767 milliseconds. Right, the range of representation could be wider than with the 24bit integer(?) But there a same value could be represented by two different encodings. This makes comparisons for equality longer to write in C, requires normalization before each comparison. I.e. 1 millisecond could be represented by somebody as 1000micro-seconds, and when comparing the two values it's not sufficient to simply compare the 16bit values received in messages, one has to normalize first (similar to when one has to apply ntohs before every comparison of shorts received from the wire). Tradeoffs tradeoffs... Alex > > Thanks, Mijeom. > > > On Fri, Mar 5, 2010 at 7:39 PM, Alexandru Petrescu > wrote: >> Le 05/03/2010 11:36, roll issue tracker a écrit : >>> >>> #18: Numeric Ranges in Routing Metric >>> >>> --------------------------------+------------------------------------------- >>> >>> >>> >>> Reporter: jpv@… | Owner: mjkim@… >>> Type: defect | Status: closed Priority: >>> minor | Milestone: Component: routing-metrics >>> | Version: Severity: Active WG Document | Resolution: fixed >>> Keywords: | >>> >>> --------------------------------+------------------------------------------- >>> >>> >>> >>> Changes (by jpv@…): >>> >>> * status: new => closed * resolution: => fixed >>> >>> >>> Comment: >>> >>> Here is the resolution after discussion on the mailing list: >>> >>> It's time to close on the #18. I think that throughput and >>> latency can be better presented by unsigned integers as the below >>> justification wrote. Latency can be expressed in units of >>> milliseconds >> >> But we just seemed to agree on micro-seconds instead, haven't we? >> >> Alex >> >> >> and throughput can >>> >>> be expressed in bytes per second. >>> >>> Mijeom. >>> >> >> >> _______________________________________________ Roll mailing list >> Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll >> > From yoav@yitran.com Mon Mar 8 03:27: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 71F143A696B for ; Mon, 8 Mar 2010 03:27:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.184 X-Spam-Level: X-Spam-Status: No, score=-6.184 tagged_above=-999 required=5 tests=[AWL=-0.208, 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 zgcFOh30msV1 for ; Mon, 8 Mar 2010 03:27:22 -0800 (PST) Received: from na3sys009aog109.obsmtp.com (na3sys009aog109.obsmtp.com [74.125.149.201]) by core3.amsl.com (Postfix) with SMTP id B4DBD3A6917 for ; Mon, 8 Mar 2010 03:27:21 -0800 (PST) Received: from source ([74.125.82.48]) by na3sys009aob109.postini.com ([74.125.148.12]) with SMTP ID DSNKS5TfHKkjPEIYzbzT/4j85ufHO2FE4W0T@postini.com; Mon, 08 Mar 2010 03:27:26 PST Received: by mail-ww0-f48.google.com with SMTP id 29so2829766wwb.21 for ; Mon, 08 Mar 2010 03:27:24 -0800 (PST) From: Yoav Ben-Yehezkel MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acq+slM6v4++4iyHQt2ANqZAQQoNng== Date: Mon, 8 Mar 2010 13:27:24 +0200 Received: by 10.216.87.18 with SMTP id x18mr2071180wee.201.1268047644687; Mon, 08 Mar 2010 03:27:24 -0800 (PST) Message-ID: <78f3c80e2561e4ba653a4bff472a5b80@mail.gmail.com> To: roll@ietf.org Content-Type: multipart/alternative; boundary=0016e6db29996b7d05048148591e Subject: [Roll] a few questions on ROLL X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 08 Mar 2010 11:27:23 -0000 --0016e6db29996b7d05048148591e Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi, My experience is of PLC networks, and I have a few questions to the group regarding ROLL that are interesting in particular to the networks we=92re working on. The draft really looks like a pertinent massive and impressive amount of work in progress. 1) Regarding 5.2. DODAG Information Solicitation (DIS) - How would DIS reception affect the network if there are potentially LOTS of nodes that ca= n respond? This invites congestion to the channel. Maybe some filters are due (e.g. based on max-rank response, or allowing responses from lower ranks to be sent faster, etc.)? 2) Regarding 5.3.5. DIO Transmission (the trickle reset to a minimum value due to detected inconsistency) =96 In some of the cases, the inconsistencie= s may be transient (pass by themselves if waiting long enough) but also detectable by many nodes simultaneously. So reducing the timer to a minimum by many nodes could be a little aggressive (may cause instantaneous bursts of congestion). This is particularly problematic in case of =93blinking links/nodes=94 in PLC networks, which can be a timely repetitive phenomenon (for example, due to repetitive power grid usage profile). It looks like remaining with the same timer that would eventually solve the problem after a longer while, so this reduction seems that critical only if a node is really expected to transmit packets via that routing inconsistency very often, otherwise it seems that the requirement can be more relaxed. 3) Regarding 5.3.5.1.2. Determination of Inconsistency - What about allowin= g for some indications from L2 (failure to receive link layer ACKs for example). Another question is whether an inconsistency can be learned from = a DAO message that needs to return to a node already appearing on the RR Stack? 4) Regarding 7.1. Suggestions for Packet Forwarding =96 does ROLL allow to = use a similar or lower preferences via another node if it detects a failure to transmit to a node that satisfied the best preference (for example no L2 AC= K for pref.#3 in case of a bad, asymmetric or occasional link with a neighbor node). 5) Regarding 7.2.2.6. Forward Path Recovery =96 can the TTL be reset after setting the Forwarding-Error bit to allow higher probability to reach the originating node (in case the forwarding problem occurred more than half wa= y through the TTL)? 6) Regarding 12.1.1 Initialization mode - In PLC networks, there=92re occasional problems of high noise near the receiver (causing it to have bad reception but being well-heard by others) or tx load at the transmitter (causing other nodes to have bad reception of its transmissions, but allowing the transmitter to have good reception of other nodes packets). In such scenarios, it is particularly difficult to detect the only good candidates that have a bi-directional link with the node. I=92m not sure th= at simply going over the candidate options one by one is a very good approach (again filters to the DIS message could ease the problem). In addition, I have some questions about coverage of the draft as well: 1) Should the draft address the behavior of nodes after warm starts up (wha= t should MUST be saved, what is recommended to be saved, trickle timer considerations, etc.)? This is an interesting tradeoff in particular for large PLC networks after power fails (where channel congestions should be avoided) vs. sporadic power fail in a single or few nodes (where fast recovery of routes is required). 2) Should the draft address the ability to gracefully replace a DODAG root without regenerating the whole DODAG to a new DODAG root? Maybe if the root that originated the DODAG is maintained, instead of the active one in the DODAGID field? Any assistance and clarifications would be very much appreciated. Thanks in advance, Yoav Ben-Yehezkel Senior communications engineer Yitran Communications LTD. --0016e6db29996b7d05048148591e Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable

Hi,

=A0

My experience is of PLC networks, and I have a few q= uestions to the group regarding ROLL that are interesting in particular to the netwo= rks we=92re working on. The draft really looks like a pertinent massive and impressive amount of work in progress.

=A0

1) Regarding 5.2. DODAG Information Solicitatio= n (DIS) - How would DIS reception affect the network if there are potentially LOTS = of nodes that can respond? This invites congestion to the channel. Maybe some filters are due (e.g. based on max-rank response, or allowing responses fro= m lower ranks to be sent faster, etc.)?

2) Regarding 5.3.5. DIO Transmission (the trickle re= set to a minimum value due to detected inconsistency) =96 In some of the cases, the inconsistencies may be transient (pass by themselves if waiting long enough= ) but also detectable by many nodes simultaneously. So reducing the timer to a minimum by many nodes could be a little aggressive (may cause instantaneous bursts of congestion). This is particularly problematic in case of =93blinking links/nodes=94 in PLC networks, which can be a timely repetitiv= e phenomenon (for example, due to repetitive power grid usage profile). It lo= oks like remaining with the same timer that would eventually solve the problem = after a longer while, so this reduction seems that critical only if a node is rea= lly expected to transmit packets via that routing inconsistency very often, otherwise it seems that the requirement can be more relaxed.

=A0

3) Regarding 5.3.5.1.2. Determination of Inconsisten= cy - What about allowing for some indications from L2 (failure to receive link layer = ACKs for example). Another question is whether an inconsistency can be learned f= rom a DAO message that needs to return to a node already appearing on the RR St= ack?

=A0

4) Regarding 7.1. Suggestions for Packet Forwarding = =96 does ROLL allow to use a similar or lower preferences via another node if it det= ects a failure to transmit to a node that satisfied the best preference (for exa= mple no L2 ACK for pref.#3 in case of a bad, asymmetric or occasional link with = a neighbor node).

=A0

5) Regarding 7.2.2.6. Forward Path Recovery =96 can = the TTL be reset after setting the Forwarding-Error bit to allow higher probabi= lity to reach the originating node (in case the forwarding problem occurred more than half way through the TTL)?

=A0

6) Regarding 12.1.1 Initialization mode - In PLC net= works, there=92re occasional problems of high noise near the receiver (causing it to have bad reception but being well-heard by others) or tx load at the transmitter (causing other nodes to have bad reception of its transmissions= , but allowing the transmitter to have good reception of other nodes packets)= . In such scenarios, it is particularly difficult to detect the only good candid= ates that have a bi-directional link with the node. I=92m not sure that simply going over the candidate options one by one is a very good approach (again filters to the DIS message could ease the problem).

=A0

In addition, I have some questions about coverage of= the draft as well:

1) Should the draft address the behavior of nodes af= ter warm starts up (what should MUST be saved, what is recommended to be saved, tric= kle timer considerations, etc.)? This is an interesting tradeoff in particular = for large PLC networks after power fails (where channel congestions should be avoided= ) vs. sporadic power fail in a single or few nodes (where fast recovery of routes= is required).

=A0

2) Should the draft address the ability to gracefull= y replace a DODAG root without regenerating the whole DODAG to a new DODAG root? Mayb= e if the root that originated the DODAG is maintained, instead of the active one= in the DODAGID field?

=A0

Any assistance and clarifications would be very much appreciated.

=A0

Thanks in advance,

Yoav Ben-Yehezkel

Senior communications engineer

Yitran Communications LTD.

--0016e6db29996b7d05048148591e-- From yoav@yitran.com Mon Mar 8 05:43: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 ADA7F3A68D9 for ; Mon, 8 Mar 2010 05:43:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.132 X-Spam-Level: X-Spam-Status: No, score=-6.132 tagged_above=-999 required=5 tests=[AWL=-0.156, 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 qeNhYljEj8x5 for ; Mon, 8 Mar 2010 05:43:06 -0800 (PST) Received: from na3sys009aog102.obsmtp.com (na3sys009aog102.obsmtp.com [74.125.149.69]) by core3.amsl.com (Postfix) with SMTP id F373D3A6904 for ; Mon, 8 Mar 2010 05:43:05 -0800 (PST) Received: from source ([74.125.82.171]) by na3sys009aob102.postini.com ([74.125.148.12]) with SMTP ID DSNKS5T+7UcjvWEiJRRyZ7Gv1WakIqdwdQZF@postini.com; Mon, 08 Mar 2010 05:43:10 PST Received: by mail-wy0-f171.google.com with SMTP id 42so3316602wyb.2 for ; Mon, 08 Mar 2010 05:43:09 -0800 (PST) From: Yoav Ben-Yehezkel MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acq+xUmbJVk5epPiSSiTGz9Cgk0hrQ== Date: Mon, 8 Mar 2010 15:43:08 +0200 Received: by 10.216.89.5 with SMTP id b5mr2680836wef.143.1268055788611; Mon, 08 Mar 2010 05:43:08 -0800 (PST) Message-ID: <9802e8a1f10bffd581181c0e7893304e@mail.gmail.com> To: roll@ietf.org Content-Type: multipart/alternative; boundary=0016e6d7eea0d5e91f04814a3e22 Cc: T.Clausen@computer.org Subject: Re: [Roll] Fwd: New Version Notification for draft-levis-roll-trickle-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, 08 Mar 2010 13:43:08 -0000 --0016e6d7eea0d5e91f04814a3e22 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi, I have a few minor comments and clarifications WRT this draft. 1) In your abstract and also introduction you state that Trickle is designe= d for wireless networks. It is in fact for any low resource networks (can als= o be PLC or any other type of low speed/cost/energy network). Can you clarify about the following two issues (that also appear in my questions about the RPL): 1) How does Tickle take into consideration that in PLC network the scenario in which a node can only hear a small subset of nodes that can hear it is common (due to Tx Load allowing to hear well, but be heard badly or Rx nois= e allowing to be heard well but hear badly). Stopping to transmit due to othe= r nodes transmissions could cause an unresolved inconsistency. I suggest that it would be possible to disable redundancy counter, or enable to reset/reduce it if inconsistency is still overheard (persists) even after i= t reaches k. 2) How does Tickle take into consideration that an inconsistency can be immediately detected by many nodes. Aggressive reduction of I to Imin could cause bursty congestion, especially in PLC where the =93blinking node/link= =94 phenomenon can be timely repetitive (due to power grid usage profile). Best regards, Yoav Ben-Yehezkel Senior Communication Engineer Yitran Communications LTD. [Roll] Fwd: New Version Notification for draft-levis-roll-trickle-00 ------------------------------ - *To*: ROLL WG > - *Subject*: [Roll] Fwd: New Version Notification for draft-levis-roll-trickle-00 - *From*: Philip Levis > - *Date*: Thu, 25 Feb 2010 17:20:39 -0800 - *Delivered-to*: roll at core3.amsl.com - *List-archive*: - *List-help*: > - *List-id*: Routing Over Low power and Lossy networks - *List-post*: > - *List-subscribe*: , < mailto:roll-request@ietf.org?subject=3Dsubscribe > - *List-unsubscribe*: , < mailto:roll-request@ietf.org?subject=3Dunsubscribe > - *References*: <20100226011704.C9E4D28C140 at core3.amsl.com<20100226011704.C9E4D28C140@DOMAIN.HIDDEN> > ------------------------------ Thomas and I thought it might make sense to separate Trickle out from the RPL specification. Here's a first version of the draft: http://www.ietf.org/internet-drafts/draft-levis-roll-trickle-00.txt Phil Begin forwarded message: *From: *IETF I-D Submission Tool > *Date: *February 25, 2010 5:17:01 PM PST *To: *pal at cs.stanford.edu *Cc: *T.Clausen at computer.org *Subject: **New Version Notification for draft-levis-roll-trickle-00 * A new version of I-D, draft-levis-roll-trickle-00.txt has been successfuly submitted by P Levis and posted to the IETF repository. Filename: draft-levis-roll-trickle Revision: 00 Title: The Trickle Algorithm Creation_date: 2010-02-25 WG ID: Independent Submission Number_of_pages: 8 Abstract: 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. The IETF Secretariat. --0016e6d7eea0d5e91f04814a3e22 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable

Hi,

=A0

I have a few minor comments and clarifications WRT t= his draft.

=A0

1) In your abstract and also introduction you state = that Trickle is designed for wireless networks. It is in fact for any low resource netwo= rks (can also be PLC or any other type of low speed/cost/energy network).

=A0

Can you clarify about the following two issues (that= also appear in my questions about the RPL):

=A0

1) How does Tickle take into consideration that in P= LC network the scenario in which a node can only hear a small subset of nodes = that can hear it is common (due to Tx Load allowing to hear well, but be heard b= adly or Rx noise allowing to be heard well but hear badly). Stopping to transmit= due to other nodes transmissions could cause an unresolved inconsistency. I sug= gest that it would be possible to disable redundancy counter, or enable to reset= /reduce it if inconsistency is still overheard (persists) even after it reaches k. =

=A0

2) How does Tickle take into consideration that an inconsistency can be immediately detected by many nodes. Aggressive reducti= on of I to Imin could cause bursty congestion, especially in PLC wh= ere the =93blinking node/link=94 phenomenon can be timely repetitive (due to power grid usage profile).

=A0

Best regards,

Yoav Ben-Yehezkel

Senior Communication Engineer

Yitran Communications LTD.

=A0

=A0

=A0

=A0[Roll] Fwd: New Version Notification for draft-levis-roll-trickle-00

Thomas and I thought it might make sense to separa= te Trickle out from the RPL specification. Here's a first version of the= draft:

=A0

http://www.ietf.org/internet-drafts/draft-lev= is-roll-trickle-00.txt

=A0

Phil

=A0

Begin forwarded message:



From: IETF I-D Submission Tool <i= dsubmission at ietf.org>

Date: February 25, 2010 5:17:01 PM PST

To: pal at cs.stanford.edu

Cc: T.Clausen at computer.org

Subject: New Version Notification fo= r draft-levis-roll-trickle-00

=A0


A new version of I-D, draft-levis-roll-trickle-00.txt has been successful= y submitted by P Levis and posted to the IETF repository.

Filename:=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= draft-levis-roll-trickle
Revision:=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0 00
Title:=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0 The Trickle Algorithm
Creation_date: 2010-02-25
WG ID:=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0 Independent Submission
Number_of_pages: 8

Abstract:
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. =A0A simple suppression nechanism and transmission point
selection allows Trickle's communication rate to scale
logarithmically with density. =A0This document describes Trickle and
considerations in its use.



The IETF Secretariat.

=A0

--0016e6d7eea0d5e91f04814a3e22-- From d.sturek@att.net Mon Mar 8 06:19: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 885953A6962 for ; Mon, 8 Mar 2010 06:19:57 -0800 (PST) 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 nsKB2CXh9KNh for ; Mon, 8 Mar 2010 06:19:49 -0800 (PST) Received: from smtp107.sbc.mail.mud.yahoo.com (smtp107.sbc.mail.mud.yahoo.com [68.142.198.105]) by core3.amsl.com (Postfix) with SMTP id 0EECD3A69A5 for ; Mon, 8 Mar 2010 06:19:49 -0800 (PST) Received: (qmail 94728 invoked from network); 8 Mar 2010 14:19:50 -0000 Received: from Studio (d.sturek@67.124.203.61 with login) by smtp107.sbc.mail.mud.yahoo.com with SMTP; 08 Mar 2010 06:19:49 -0800 PST X-Yahoo-SMTP: fvjol_aswBAraSJvMLe2r1XTzhBhbFxY8q8c3jo- X-YMail-OSG: uHyd46kVM1nvODZ_sQv_j.AUAOl_WbJWcyVcsGHn4P3wUJnQgDSGxiqOG1_q6fLCy.nXP_FDB5sZ2hfKxHP446K61rYDWnJht5P6Ssx8YesOeJiKP4Q0cEaB9w9k7m0pVpYqTcGnXxDkYNegTHsP_wTjNRK0Fyb2i1p0b.CzaLnbruKNg09z0wriD_qU87FI80SGcRZMylCYyeCtdN2xaIHn_d3SemyDsZNKUPsGM.6LTdPZSIJfSVm4h1golwhKsX.WNnmNwd32BN.gwyTRubSJ9YkWxkheu6FkK8Tvjijko2DRtxM- X-Yahoo-Newman-Property: ymail-3 From: "Don Sturek" To: "'Anders Brandt'" , "'ROLL WG'" References: <6D9687E95918C04A8B30A7D6DA805A3E01429F5F@zensys17.zensys.local> In-Reply-To: <6D9687E95918C04A8B30A7D6DA805A3E01429F5F@zensys17.zensys.local> Date: Mon, 8 Mar 2010 06:19:48 -0800 Message-ID: <006e01cabeca$691fbf80$3b5f3e80$@sturek@att.net> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_006F_01CABE87.5AFC7F80" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acq+mBRA8djVC8wZSJSeUmM3XWRlWwAMgRfw Content-Language: en-us Subject: Re: [Roll] P2P performance with current RPL proposal 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, 08 Mar 2010 14:19:57 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_006F_01CABE87.5AFC7F80 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Anders, First let me say +1 on your note. Agree these are the issues to solve. I was happy to see JP add a ticket. I would encourage establishment of a subgroup within the DT to address these. These points have been open for some time. The trouble with "managed flooding" is that it would be the application that would somehow have to know how many hops it needed to flood to fine the device of interest. That has been problematic in the past... Don From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Anders Brandt Sent: Monday, March 08, 2010 12:20 AM To: ROLL WG Subject: [Roll] P2P performance with current RPL proposal Hello I would like to probe the temperature of the WG on using DAOs to support P2P. The building and home application spaces (and maybe others) have a few clearly defined requirements. It is not obvious to me how the current RPL proposal (cRPLp) can satisfy those requirements: In both cases it is the worst case scenario that hurts: P2P routing inside the PAN ========================== cRPLp has no way of routing inside the PAN if you need more than one repeater. cRPLp has to go all the way to the top (maybe 4 hops up) and down again (maybe 4 hops down) to get just 2 hops to the side. The consequence is high latency and high levels of background noise for nodes just outside the direct radio range. At the same time the risk of meeting a failing link is 4 times higher => latency may be much more than 4 times larger. Latency may sound like a minor issue but it actually translates directly into lower battery lifetime. In the above (very realistic) example, the battery lifetime is reduced to 25% of what it should be. We have lots of battery devices sending into the network: * PIR sensors turning on lights * Door locks sending alarms * Door/window sensors starting chimes * Smoke sensors triggering an alarm system Response time ============= The latency issue is important. When a user (real human being) presses a light button the user expects the light to turn on. cRPLp proposes that nodes in the tree periodically advertises their presence using DAOs. The periodicity is a real beast: Thanks to Trickle, the rate of updates in a (apparently) stable network is low. This is good since it leaves bandwidth for data. But it is not good if existing routes to my lamp fail and I do not get new routes to my lamp until it decides to send out a new DAO. My user will (with a good reason) not tolerate waiting for minutes for the light to turn on. I have met two arguments to counter this concern: A1: Well, your lamp can always send a DAO when it detects a problem. My answer: True, except that my lamp does not intend to send anything so it will never experience any problems from its side of the network. A2: Well, you can increase the DAO rate to sub-second updates. My answer: Oh no. I get a very high degree of management traffic which limits my available bandwidth, increases the risk of collisions and even run the risk of violating EU legislation requiring me to only transmit in less than 1% of the time: http://focus.ti.com/lit/an/swra048/swra048.pdf 868 - 868.6 MHz: <1% Reactiveness is hard to achieve via polling. If you agree that this seems to be critical issues please raise your voice on the list. Going forward ============= We need some reactive mechanism to reach lamps before the user decides to sue our companies. So is this possible? I think so. Existing commercial (non-IP) solutions are capable of re-routing quickly if they really have to. Let me try scoping the requirements to a potential solution: (no different from the req. docs for home and building) * P2P routing in any direction independent of the tree. * On-demand P2P route discovery if requested by a real-time critical app. Data collection apps may be able to just wait for the next DAO update. * Limited range of discovery mechanism: max 4 repeaters. A TTL field may limit the scope of the repeaters. * Suboptimal routing and traffic bursts are accepted in exchange for quick route repair. But only as an exception. Just as an example, one existing home control technology uses a (source routing) variant of AODV for quick route repair. Nothing comes for free. The price is flooding - but not just flooding: Managed flooding using a distributed algorithm running in all participating nodes. The algorithm dampens the flooding in a time, volume and range perspective. Some similar mechanism could be built into RPL for quick route repair. If anyone have alternative proposals, please bring it to the list. Now is the time. Thanks, Anders ------=_NextPart_000_006F_01CABE87.5AFC7F80 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Anders,

 

First let me say +1 on your note.  Agree these are = the issues to solve.  I was happy to see JP add a ticket.  I would encourage = establishment of a subgroup within the DT to address these.  These points have been = open for some time.

 

The trouble with “managed flooding” is that = it would be the application that would somehow have to know how many hops it needed to = flood to fine the device of interest.  That has been problematic in the = past………

 

Don

 

 

From:= roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of = Anders Brandt
Sent: Monday, March 08, 2010 12:20 AM
To: ROLL WG
Subject: [Roll] P2P performance with current RPL = proposal

 

Hello

=

 

I would like to probe the temperature of the WG on using DAOs = to

support P2P.

 

The building and home application spaces (and maybe others) = have

a few clearly defined requirements.

It is not obvious to me how the current RPL proposal (cRPLp) = can

satisfy those requirements:

 

 

In both cases it is the worst case scenario that hurts:

 

 

P2P routing inside the PAN

=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

=

cRPLp has no way of routing inside the PAN if you need more = than

one repeater. cRPLp has to go all the way to the top (maybe 4 hops = up)

and down again (maybe 4 hops down) to get just 2 hops to the = side.

 

The consequence is high latency and high levels of background noise
for nodes just outside the direct radio range.

At the same time the risk of meeting a failing link is 4 times higher = =3D>

latency may be much more than 4 times larger.

 

Latency may sound like a minor issue but it actually translates directly
into lower battery lifetime. In the above (very realistic) = example,

the battery lifetime is reduced to 25% of what it should = be.

 

We have lots of battery devices sending into the network:

* PIR sensors turning on lights

* Door locks sending alarms

* Door/window sensors starting chimes

* Smoke sensors triggering an alarm system

 

 

 

 

Response time

=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D

The latency issue is important.

When a user (real human being) presses a light button the user = expects

the light to turn on.

cRPLp proposes that nodes in the tree periodically advertises = their

presence using DAOs.

The periodicity is a real beast:

Thanks to Trickle, the rate of updates in a (apparently) stable network
is low. This is good since it leaves bandwidth for = data.

But it is not good if existing routes to my lamp fail and I do not = get

new routes to my lamp until it decides to send out a new DAO.

My user will (with a good reason) not tolerate waiting for minutes = for

the light to turn on.

 

I have met two arguments to counter this concern:

 

A1: Well, your lamp can always send a DAO when it detects a = problem.

  My answer:

  True, except that my lamp does not intend to send = anything

  so it will never experience any problems from its side of the = network.

 

A2: Well, you can increase the DAO rate to sub-second = updates.

  My answer:

  Oh no. I get a very high degree of = management traffic which

  limits my available bandwidth, increases the risk of collisions = and

  even run the risk of violating EU legislation requiring me to = only

  transmit in less than 1% of the time:

  http://focus.ti.com/lit/an/swra048/swra048.pdf
  868 - = 868.6 MHz: <1%

 

  Reactiveness is hard to achieve via polling.

 

 

 

If you agree that this seems to be critical issues please raise = your

voice on the list.

 

Going forward

=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D

 

We need some reactive mechanism to reach lamps before the user = decides

to sue our companies.

So is this possible? I think so.


Existing = commercial (non-IP) solutions are capable of re-routing = quickly

if they really have to.

 

Let me try scoping the requirements to a potential solution:

(no different from the req. docs for home and = building)

 

* P2P routing in any direction independent of the tree.

 

* On-demand P2P route discovery if requested by a real-time critical = app.
  Data collection apps may be able to just wait for the next DAO = update.

 

* Limited range of discovery mechanism: max 4 repeaters.

  A TTL field may limit the scope of the repeaters.

 

* Suboptimal routing and traffic bursts are accepted in = exchange

  for quick route repair. But only as an exception.

  =

 

Just as an example, one existing home control technology uses a
(source routing) variant of AODV for quick route = repair.

Nothing comes for free. The price is flooding - but not just flooding:
Managed flooding using a distributed algorithm running in all
participating nodes.

The algorithm dampens the flooding in a time, volume and range = perspective.

Some similar mechanism could be built into RPL for quick route = repair.

 

 

If anyone have alternative proposals, please bring it to the = list.

Now is the time.

 

 

 

Thanks,

  Anders

------=_NextPart_000_006F_01CABE87.5AFC7F80-- From Matteo.Paris@ember.com Mon Mar 8 06:40: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 841F93A6904; Mon, 8 Mar 2010 06:40:33 -0800 (PST) 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 GU5NOUg-hJ2N; Mon, 8 Mar 2010 06:40:32 -0800 (PST) Received: from EMPIRE.hq.ember.com (mail.ember.com [74.10.175.227]) by core3.amsl.com (Postfix) with ESMTP id 665B33A68FF; Mon, 8 Mar 2010 06:40:32 -0800 (PST) Received: from [192.168.81.62] ([192.168.81.19]) by EMPIRE.hq.ember.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 8 Mar 2010 09:43:16 -0500 Mime-Version: 1.0 Message-Id: In-Reply-To: References: <055.a3c60804880e85f93fc1826167be4fb6@tools.ietf.org> <201002230913.47381.henning.rogge@fkie.fraunhofer.de> <201002231122.41069.henning.rogge@fkie.fraunhofer.de> <108AEE8B-E296-44E3-BE37-1A43144B0281@unina.it> Date: Mon, 8 Mar 2010 09:40:34 -0500 To: roll@ietf.org From: Matteo Paris Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-OriginalArrivalTime: 08 Mar 2010 14:43:16.0091 (UTC) FILETIME=[AFD33CB0:01CABECD] Cc: manet Subject: Re: [Roll] [manet] [roll] #20: Question on Metric 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: Mon, 08 Mar 2010 14:40:33 -0000 I'd prefer using a 16-bit fixed point value for ETX, with 4 bits of fractional part. It's very simple, and easily covers the desirable ranges. I don't think the ETX value field is the right place to try to save one byte. If we need to shave bytes, there are other good candidates. For example we could reduce the length fields of DIO suboptions and routing metric common headers from 2 bytes to 1 byte. We could also eliminate the byte of flags from the routing metric common header since that information is redundant if you know the Objective Function, and unused if you don't. Matteo At 10:38 AM +0900 3/8/10, MiJeom Kim wrote: >Thank you for clearing the issue. > >So, we don't need the overloading ETX, then. >How do you think about my suggestion: > >we can represent (ETX * C) as (32 + a) * 2^b where 0 <= a <= 31 and 0 ><= b <= 7. If C is 128, the max possible ETX is 63 and if C is 64, the >max ETX is 126. So let's try C = 64 and if ETX is bigger than 126, we >can just make it the possible max which is 126. > >Other better ideas? >let's close the ticket soon. > >Mijeom. > > >On Sat, Mar 6, 2010 at 6:04 AM, Marcello Caleffi > wrote: >> If the delivery ratios are correctly estimated, there is no >>difference among 1ETX links, wired wireless or anything else. >> The issue is in correctly estimating the delivery ratios, but this >>does not need additional bits in the header. >> >> Marcello >> >> >> Il giorno 05/mar/2010, alle ore 21.58, Omprakash Gnawali ha scritto: >> >>> On Tue, Mar 2, 2010 at 9:28 PM, MiJeom Kim wrote: >>>> Hi, >>>> >>>> It's time to summarize. >>>> >>>> - ETX >= 1, and 100 is enough for Max ETX since more than 10 ETX is >>>> close to infinity. >>>> - 8 bits are enough but need to avoid floating point format. ? good to >>>> multiply with a constant factor (C) like 256 >>>> >>>> I think Henning's suggestion is good. But we don't need a big range >>>> for ETX, but precision needs to be increased. So we can adjust it with >>>> 5 bit mantissa and 3 bit exponent. >>>> >>>> So, we can represent (ETX * C) as (32 + a) * 2^b where 0 <= a <= 31 >>>> and 0 <= b <= 7. If C is 128, the max possible ETX is 63 and if C is >>>> 64, the max ETX is 126. So let's try C = 64 and if ETX is bigger than >>>> 126, we can just make it the possible max which is 126. >>>> >>>> All the numbers can be adjustable again, so please settle down the >>>> issue with your ideas. >>>> >>>> I can't understand the Overloading ETX thing. Nobody suggests >>>> overloading ETX, I think. What do you mean by that in this thread, >>>> Omprakash? >>> >>> It was the suggestion that not all ETX=1 links are the same so we >>> should leave room in the metric to differentiate preferred ETX=1 link >>> from the other ETX=1 links. The example that was used was, wired ETX=1 >>> link vs wireless ETX=1 link. If we make minimum ETX value to be 1, >>> then there is no room for such differentiation based on just the ETX >>> metric. >>> >>> - om_p >>> _______________________________________________ >>> manet mailing list >>> manet@ietf.org >>> https://www.ietf.org/mailman/listinfo/manet >> >> >_______________________________________________ >Roll mailing list >Roll@ietf.org >https://www.ietf.org/mailman/listinfo/roll From Emmanuel.Monnerie@landisgyr.com Mon Mar 8 06:54: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 629513A6968 for ; Mon, 8 Mar 2010 06:54:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_63=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g0i+AcQ42E8Z for ; Mon, 8 Mar 2010 06:54:37 -0800 (PST) Received: from mta1.cellnet.com (mta1.cellnet.com [66.173.18.47]) by core3.amsl.com (Postfix) with ESMTP id 6BBCB3A6904 for ; Mon, 8 Mar 2010 06:54:37 -0800 (PST) X-ASG-Debug-ID: 1268060080-657100fa0000-BCmCR7 X-Barracuda-URL: http://10.3.2.11:8000/cgi-bin/mark.cgi Received: from livemail.cellnethunt.com (localhost [127.0.0.1]) by mta1.cellnet.com (Spam Firewall) with ESMTP id BC125F8157 for ; Mon, 8 Mar 2010 08:54:40 -0600 (CST) Received: from livemail.cellnethunt.com (usatlsv15.am.bm.net [10.1.130.15]) by mta1.cellnet.com with ESMTP id 7zrH24eZ7sxw4rn3 for ; Mon, 08 Mar 2010 08:54:40 -0600 (CST) X-ASG-Whitelist: Sender X-ASG-Whitelist: Client Received: from livemail.cellnethunt.com ([10.1.130.105]) by livemail.cellnethunt.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 8 Mar 2010 09:54:39 -0500 Received: from mail pickup service by livemail.cellnethunt.com with Microsoft SMTPSVC; Mon, 8 Mar 2010 09:54:39 -0500 Content-Transfer-Encoding: 7bit Importance: normal Priority: normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.4325 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CABECF.46EC8477" X-ASG-Orig-Subj: RE: [Roll] P2P performance with current RPL proposal Date: Mon, 8 Mar 2010 09:56:13 -0500 Message-ID: <76DBCE2AA6605F42A49F1BD7454C841B96AA31@usatlsv105.am.bm.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] P2P performance with current RPL proposal thread-index: Acq+mBRA8djVC8wZSJSeUmM3XWRlWwANVCAwAACD7QA= References: <6D9687E95918C04A8B30A7D6DA805A3E01429F5F@zensys17.zensys.local> From: "Monnerie, Emmanuel" To: X-OriginalArrivalTime: 08 Mar 2010 14:54:39.0870 (UTC) FILETIME=[4763A1E0:01CABECF] X-Barracuda-Connect: usatlsv15.am.bm.net[10.1.130.15] X-Barracuda-Start-Time: 1268060080 X-Barracuda-Virus-Scanned: by Barracuda Spam Firewall at cellnet.com Subject: Re: [Roll] P2P performance with current RPL proposal X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Mar 2010 14:54:39 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CABECF.46EC8477 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Anders, Thanks for bringing this topic on the table. Clearly there are many other applications that would need P2P, such as Smart Grid/Urban networks. P2P does not represent a high volume of traffic, but is usually required in time critical applications, such as local management of power grid switches. The chapter 5 (Traffic Pattern) of RFC5548 would be good place to describe in detail these use cases. Best Regards From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Anders Brandt Sent: Monday, March 08, 2010 3:20 AM To: ROLL WG Subject: [Roll] P2P performance with current RPL proposal Hello I would like to probe the temperature of the WG on using DAOs to support P2P. The building and home application spaces (and maybe others) have a few clearly defined requirements. It is not obvious to me how the current RPL proposal (cRPLp) can satisfy those requirements: In both cases it is the worst case scenario that hurts: P2P routing inside the PAN ========================== cRPLp has no way of routing inside the PAN if you need more than one repeater. cRPLp has to go all the way to the top (maybe 4 hops up) and down again (maybe 4 hops down) to get just 2 hops to the side. The consequence is high latency and high levels of background noise for nodes just outside the direct radio range. At the same time the risk of meeting a failing link is 4 times higher => latency may be much more than 4 times larger. Latency may sound like a minor issue but it actually translates directly into lower battery lifetime. In the above (very realistic) example, the battery lifetime is reduced to 25% of what it should be. We have lots of battery devices sending into the network: * PIR sensors turning on lights * Door locks sending alarms * Door/window sensors starting chimes * Smoke sensors triggering an alarm system Response time ============= The latency issue is important. When a user (real human being) presses a light button the user expects the light to turn on. cRPLp proposes that nodes in the tree periodically advertises their presence using DAOs. The periodicity is a real beast: Thanks to Trickle, the rate of updates in a (apparently) stable network is low. This is good since it leaves bandwidth for data. But it is not good if existing routes to my lamp fail and I do not get new routes to my lamp until it decides to send out a new DAO. My user will (with a good reason) not tolerate waiting for minutes for the light to turn on. I have met two arguments to counter this concern: A1: Well, your lamp can always send a DAO when it detects a problem. My answer: True, except that my lamp does not intend to send anything so it will never experience any problems from its side of the network. A2: Well, you can increase the DAO rate to sub-second updates. My answer: Oh no. I get a very high degree of management traffic which limits my available bandwidth, increases the risk of collisions and even run the risk of violating EU legislation requiring me to only transmit in less than 1% of the time: http://focus.ti.com/lit/an/swra048/swra048.pdf 868 - 868.6 MHz: <1% Reactiveness is hard to achieve via polling. If you agree that this seems to be critical issues please raise your voice on the list. Going forward ============= We need some reactive mechanism to reach lamps before the user decides to sue our companies. So is this possible? I think so. Existing commercial (non-IP) solutions are capable of re-routing quickly if they really have to. Let me try scoping the requirements to a potential solution: (no different from the req. docs for home and building) * P2P routing in any direction independent of the tree. * On-demand P2P route discovery if requested by a real-time critical app. Data collection apps may be able to just wait for the next DAO update. * Limited range of discovery mechanism: max 4 repeaters. A TTL field may limit the scope of the repeaters. * Suboptimal routing and traffic bursts are accepted in exchange for quick route repair. But only as an exception. Just as an example, one existing home control technology uses a (source routing) variant of AODV for quick route repair. Nothing comes for free. The price is flooding - but not just flooding: Managed flooding using a distributed algorithm running in all participating nodes. The algorithm dampens the flooding in a time, volume and range perspective. Some similar mechanism could be built into RPL for quick route repair. If anyone have alternative proposals, please bring it to the list. Now is the time. Thanks, Anders Emmanuel Monnerie Senior Research Engineer Landis+Gyr Energy Management Solutions Office: +1 678 258 1695 Fax: +1 678 258 1316 Emmanuel.Monnerie@landisgyr.com www.landisgyr.com manage energy better ------_=_NextPart_001_01CABECF.46EC8477 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Anders,

 

Thanks for bringing this topic on the = table.

 

Clearly there are many other applications that would need = P2P, such as Smart Grid/Urban networks. P2P does not represent a high volume = of traffic, but is usually required in time critical applications, such as local = management of power grid switches.

 

The chapter 5 (Traffic Pattern) of RFC5548 would be good = place to describe in detail these use cases.

 

Best Regards

 

 



Emmanuel Monnerie
Senior Research Engineer
Landis+Gyr
Energy Management = Solutions
Office: +1 678 258 1695
Fax: +1 678 258 = 1316        
Emmanuel.Monnerie@landisg= yr.com
www.landisgyr.com =
manage energy = better

From:= = roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Anders Brandt
Sent: Monday, March 08, 2010 3:20 AM
To: ROLL WG
Subject: [Roll] P2P performance with current RPL = proposal

 

Hello

=

 

I would like to probe the temperature of the WG on using DAOs = to

support P2P.

 

The building and home application spaces (and maybe others) = have

a few clearly defined requirements.

It is not obvious to me how the current RPL proposal (cRPLp) = can

satisfy those requirements:

 

 

In both cases it is the worst case scenario that hurts:

 

 

P2P routing inside the PAN

=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

=

cRPLp has no way of routing inside the PAN if you need more = than

one repeater. cRPLp has to go all the way to the top (maybe 4 hops = up)

and down again (maybe 4 hops down) to get just 2 hops to the = side.

 

The consequence is high latency and high levels of background noise
for nodes just outside the direct radio range.

At the same time the risk of meeting a failing link is 4 times higher = =3D>

latency may be much more than 4 times larger.

 

Latency may sound like a minor issue but it actually translates directly
into lower battery lifetime. In the above (very realistic) = example,

the battery lifetime is reduced to 25% of what it should = be.

 

We have lots of battery devices sending into the network:

* PIR sensors turning on lights

* Door locks sending alarms

* Door/window sensors starting chimes

* Smoke sensors triggering an alarm system

 

 

 

 

Response time

=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D

The latency issue is important.

When a user (real human being) presses a light button the user = expects

the light to turn on.

cRPLp proposes that nodes in the tree periodically advertises = their

presence using DAOs.

The periodicity is a real beast:

Thanks to Trickle, the rate of updates in a (apparently) stable network
is low. This is good since it leaves bandwidth for = data.

But it is not good if existing routes to my lamp fail and I do not = get

new routes to my lamp until it decides to send out a new DAO.

My user will (with a good reason) not tolerate waiting for minutes = for

the light to turn on.

 

I have met two arguments to counter this concern:

 

A1: Well, your lamp can always send a DAO when it detects a = problem.

  My answer:

  True, except that my lamp does not intend to send = anything

  so it will never experience any problems from its side of the = network.

 

A2: Well, you can increase the DAO rate to sub-second = updates.

  My answer:

  Oh no. I get a very high degree of = management traffic which

  limits my available bandwidth, increases the risk of collisions = and

  even run the risk of violating EU legislation requiring me to = only

  transmit in less than 1% of the time:

  http://focus.ti.com/lit/an/swra048/swra048.pdf
  868 - = 868.6 MHz: <1%

 

  Reactiveness is hard to achieve via polling.

 

 

 

If you agree that this seems to be critical issues please raise = your

voice on the list.

 

Going forward

=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D

 

We need some reactive mechanism to reach lamps before the user = decides

to sue our companies.

So is this possible? I think so.


Existing = commercial (non-IP) solutions are capable of re-routing = quickly

if they really have to.

 

Let me try scoping the requirements to a potential solution:

(no different from the req. docs for home and = building)

 

* P2P routing in any direction independent of the tree.

 

* On-demand P2P route discovery if requested by a real-time critical = app.
  Data collection apps may be able to just wait for the next DAO = update.

 

* Limited range of discovery mechanism: max 4 repeaters.

  A TTL field may limit the scope of the repeaters.

 

* Suboptimal routing and traffic bursts are accepted in = exchange

  for quick route repair. But only as an exception.

  =

 

Just as an example, one existing home control technology uses a
(source routing) variant of AODV for quick route = repair.

Nothing comes for free. The price is flooding - but not just flooding:
Managed flooding using a distributed algorithm running in all
participating nodes.

The algorithm dampens the flooding in a time, volume and range = perspective.

Some similar mechanism could be built into RPL for quick route = repair.

 

 

If anyone have alternative proposals, please bring it to the = list.

Now is the time.

 

 

 

Thanks,

  Anders

------_=_NextPart_001_01CABECF.46EC8477-- From emmanuel.baccelli@gmail.com Mon Mar 8 06:56: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 884653A69B7 for ; Mon, 8 Mar 2010 06:56:57 -0800 (PST) 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 UoclEacludAP for ; Mon, 8 Mar 2010 06:56:56 -0800 (PST) Received: from mail-ew0-f216.google.com (mail-ew0-f216.google.com [209.85.219.216]) by core3.amsl.com (Postfix) with ESMTP id 5E4783A6904 for ; Mon, 8 Mar 2010 06:56:55 -0800 (PST) Received: by ewy8 with SMTP id 8so113789ewy.28 for ; Mon, 08 Mar 2010 06:56:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:from:date:x-google-sender-auth:message-id:subject:to :content-type; bh=Knoa7F4hhIRighrXwpiyCUSdReNu2fNWGr/wydXEzPE=; b=iEzk0VHvF4BM765ZowTl4s5QyRjzC2+qKeodRPPdxes4PQ2w/5c/mMeN3oMK511uS0 s5Alm0NSIjeWFOuLfMoxs3mXLUp4YPYzSr+Ec9dzW4Xg7eZrxJAsNZgmE4AA9m+OLCOz XAVXslDoDvuAwlhn6gl0zWP6l55utEh4EFmFI= 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=tZu9+E1I5fxj7C3qddOgJGQVE4FrQ0gJnKvlqQJMeKz7l4rP7QPdHjrERyh9RacHFK r4pgrDlbGui8tT/bNDZcKnfF1HZsUS5OHnR7ewNamPEzfAWWmKPXt65pMkTLnjQYM17+ a92vbZN+tW1XgR1otAX3AR+RLDODsONzqr82M= MIME-Version: 1.0 Sender: emmanuel.baccelli@gmail.com Received: by 10.213.54.66 with SMTP id p2mr3149746ebg.68.1268060215159; Mon, 08 Mar 2010 06:56:55 -0800 (PST) In-Reply-To: <-8432212445548738069@unknownmsgid> References: <6D9687E95918C04A8B30A7D6DA805A3E01429F5F@zensys17.zensys.local> <-8432212445548738069@unknownmsgid> From: Emmanuel Baccelli Date: Mon, 8 Mar 2010 15:56:35 +0100 X-Google-Sender-Auth: 5d72f79b0fa94233 Message-ID: To: ROLL WG Content-Type: multipart/alternative; boundary=00163600cd01adb71604814b467c Subject: Re: [Roll] P2P performance with current RPL proposal X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Mar 2010 14:56:57 -0000 --00163600cd01adb71604814b467c Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Anders, I am also concerned about this subject, and I support the creation of a DT to address this particular topic. In particular, I think we need to be clearer about what we mean by "real-time critical apps". Do we mean: 1 - once the app uses a path, this path better be as short as possible to reduce latency, or 2 - once a path needs to reach a destination, a path must be available as soon as possible to reduce buffering, or 3 - both of the above. If we aim at anything else than property 1 in this list, the time needed fo= r the discovery phase of a reactive protocol may be an issue at some point. I= t is hard to imagine a way to be "real-time" in the sense of property 3, without being more proactive (and to thus introducing other types of issues/tradeoffs). In a way, the current RPL proposal may be seen as an attempt at providing property 2, with the additional assumption that destinations "know" who the= y are in advance. It remains to be seen if this approach actually works the way it is intended to. If on the other hand we are just aiming for property 1, then reactive approaches, such as the one you point out, are an interesting potential alternative indeed. Regards, Emmanuel On Mon, Mar 8, 2010 at 3:19 PM, Don Sturek wrote: > Hi Anders, > > > > First let me say +1 on your note. Agree these are the issues to solve. = I > was happy to see JP add a ticket. I would encourage establishment of a > subgroup within the DT to address these. These points have been open for > some time. > > > > The trouble with =93managed flooding=94 is that it would be the applicati= on > that would somehow have to know how many hops it needed to flood to fine = the > device of interest. That has been problematic in the past=85=85=85 > > > > Don > > > > > > *From:* roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] *On Behalf O= f > *Anders Brandt > *Sent:* Monday, March 08, 2010 12:20 AM > *To:* ROLL WG > > *Subject:* [Roll] P2P performance with current RPL proposal > > > > Hello > > > > I would like to probe the temperature of the WG on using DAOs to > > support P2P. > > > > The building and home application spaces (and maybe others) have > > a few clearly defined requirements. > > It is not obvious to me how the current RPL proposal (cRPLp) can > > satisfy those requirements: > > > > > > In both cases it is the worst case scenario that hurts: > > > > > > P2P routing inside the PAN > > =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 > > cRPLp has no way of routing inside the PAN if you need more than > > one repeater. cRPLp has to go all the way to the top (maybe 4 hops up) > > and down again (maybe 4 hops down) to get just 2 hops to the side. > > > > The consequence is high latency and high levels of background noise > for nodes just outside the direct radio range. > > At the same time the risk of meeting a failing link is 4 times higher =3D= > > > latency may be much more than 4 times larger. > > > > Latency may sound like a minor issue but it actually translates directly > into lower battery lifetime. In the above (very realistic) example, > > the battery lifetime is reduced to 25% of what it should be. > > > > We have lots of battery devices sending into the network: > > * PIR sensors turning on lights > > * Door locks sending alarms > > * Door/window sensors starting chimes > > * Smoke sensors triggering an alarm system > > > > > > > > > > Response time > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > The latency issue is important. > > When a user (real human being) presses a light button the user expects > > the light to turn on. > > cRPLp proposes that nodes in the tree periodically advertises their > > presence using DAOs. > > The periodicity is a real beast: > > Thanks to Trickle, the rate of updates in a (apparently) stable network > is low. This is good since it leaves bandwidth for data. > > But it is not good if existing routes to my lamp fail and I do not get > > new routes to my lamp until it decides to send out a new DAO. > > My user will (with a good reason) not tolerate waiting for minutes for > > the light to turn on. > > > > I have met two arguments to counter this concern: > > > > A1: Well, your lamp can always send a DAO when it detects a problem. > > My answer: > > True, except that my lamp does not intend to send anything > > so it will never experience any problems from its side of the network. > > > > A2: Well, you can increase the DAO rate to sub-second updates. > > My answer: > > Oh no. I get a very high degree of management traffic which > > limits my available bandwidth, increases the risk of collisions and > > even run the risk of violating EU legislation requiring me to only > > transmit in less than 1% of the time: > > http://focus.ti.com/lit/an/swra048/swra048.pdf > 868 - 868.6 MHz: <1% > > > > Reactiveness is hard to achieve via polling. > > > > > > > > If you agree that this seems to be critical issues please raise your > > voice on the list. > > > > Going forward > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > > We need some reactive mechanism to reach lamps before the user decides > > to sue our companies. > > So is this possible? I think so. > > > Existing commercial (non-IP) solutions are capable of re-routing quickly > > if they really have to. > > > > Let me try scoping the requirements to a potential solution: > > (no different from the req. docs for home and building) > > > > * P2P routing in any direction independent of the tree. > > > > * On-demand P2P route discovery if requested by a real-time critical app. > Data collection apps may be able to just wait for the next DAO update. > > > > * Limited range of discovery mechanism: max 4 repeaters. > > A TTL field may limit the scope of the repeaters. > > > > * Suboptimal routing and traffic bursts are accepted in exchange > > for quick route repair. But only as an exception. > > > > > > Just as an example, one existing home control technology uses a > (source routing) variant of AODV for quick route repair. > > Nothing comes for free. The price is flooding - but not just flooding: > Managed flooding using a distributed algorithm running in all > participating nodes. > > The algorithm dampens the flooding in a time, volume and range perspectiv= e. > > > Some similar mechanism could be built into RPL for quick route repair. > > > > > > If anyone have alternative proposals, please bring it to the list. > > Now is the time. > > > > > > > > Thanks, > > Anders > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > > --00163600cd01adb71604814b467c Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Anders,

I am also concerned about this subject, and I suppo= rt the creation of a DT to address this particular topic.

In particular, I think we need to be clearer about what we mean by = "real-time critical apps". Do we mean:=A0

1 - once the app uses a path, this path better be as sh= ort as possible to reduce latency, or
2 - once a path needs to re= ach a destination, a path must be available as soon as possible to reduce b= uffering, or
3 - both of the above.

If we aim at anything = else than property 1 in this list, the time needed for the discovery phase = of a reactive protocol may be an issue at some point. It is hard to imagine= a way to be "real-time" in the sense of property 3, without bein= g more proactive (and to thus introducing other types of issues/tradeoffs).= =A0

In a way, the current RPL proposal may be seen as an at= tempt at providing property 2, with the additional assumption that destinat= ions "know" who they are in advance. It remains to be seen if thi= s approach actually works the way it is intended to.

If on the other hand we are just aiming for property 1,= then reactive approaches, such as the one you point out, are an interestin= g potential alternative indeed.

Regards,

Emmanuel


On Mon, Mar 8, 2010 at 3:19 PM, Don Sturek <= d.sturek@att.net> wrote:<= br>

Hi An= ders,

=A0

First= let me say +1 on your note.=A0 Agree these are the issues to solve.=A0 I was happy to see JP add a ticket.=A0 I would encourage establis= hment of a subgroup within the DT to address these.=A0 These points have been open f= or some time.

=A0

The t= rouble with =93managed flooding=94 is that it would be the application that would somehow have to know how many hops it needed to floo= d to fine the device of interest.=A0 That has been problematic in the past=85=85= =85

=A0

Don

=A0

=A0

From:= roll-bounces@iet= f.org [mailto:roll-bounces@ietf.org] On Behalf Of Anders Brandt
Sent: Monday, March 08, 2010 12:20 AM
To: ROLL WG


Subject: [Roll] P2P performance with current RPL proposal

=A0

= Hello

=A0

= I would like to probe the temperature of the WG on using DAOs to

= support P2P.

=A0

= The building and home application spaces (and maybe others) have

= a few clearly defined requirements.

= It is not obvious to me how the current RPL proposal=A0(cRPLp) can

= satisfy those requirements:

=A0

=A0

= In both cases it is the worst case scenario that hurts:

=A0

=A0

= P2P routing inside the PAN

= =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

= cRPLp has no way of routing inside the PAN if you need more than

= one repeater. cRPLp has to go all the way to the top (maybe 4 hops up)

= and down again (maybe 4 hops down) to get just 2 hops to the side.

=A0

= The consequence is high latency and high levels of background noise
for nodes just outside the direct radio range.

= At the same time=A0the risk of meeting a failing link is 4 times higher =3D>

= latency may be much more than 4 times larger.

=A0

= Latency may sound like a minor issue but it actually translates directly
into lower battery lifetime. In the above (very realistic) example,<= /p>

= the battery lifetime is reduced to 25% of what it should be.

=A0

= We have lots of battery devices sending into the network:

= * PIR sensors turning on lights

= * Door locks sending alarms

= * Door/window sensors starting chimes

= * Smoke sensors triggering=A0an alarm system

= =A0

= =A0

=A0

=A0

= Response time

= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

= The latency issue is important.

= When a user (real human being) presses a light button the user expects

= the light to turn on.

= cRPLp proposes that nodes in the tree periodically advertises their

= presence using DAOs.

= The periodicity is a real beast:

= Thanks to Trickle, the rate of updates in a (apparently) stable network
is low. This is good since it leaves bandwidth for data.

= But it is not good if existing routes to my lamp fail and I do not get

= new routes to my lamp until it decides to send out a new DAO.

= My user will (with a good reason) not tolerate waiting for minutes for

= the light to turn on.

=A0

= I have met two arguments to counter this concern:

=A0

= A1: Well, your lamp can always send a DAO when it detects a problem.

= =A0=A0My answer:

= =A0 True, except that my lamp does not intend to send anything

= =A0 so it will never experience any problems from its side of the network.<= /p>

=A0

= A2: Well, you can increase the DAO rate to sub-second updates.

= =A0 My answer:

= =A0 Oh no. I get a very high deg= ree of management traffic which

= =A0 limits my available bandwidth, increases the risk of collisions and<= /p>

= =A0 even run the risk of violating EU legislation requiring me to only

= =A0 transmit in less than 1% of the time:

= =A0 = http://focus.ti.com/lit/an/swra048/swra048.pdf
=A0 868 - 868.6 MHz: <1%

=A0

= =A0 Reactiveness is hard to achieve via polling.

=A0

=A0

=A0

= If you agree that this seems to be critical issues please raise your

= voice on the list.

=A0

= Going forward

= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

=A0

= We need some reactive mechanism to reach lamps before the user decides

= to sue our companies.

= So is this possible? I=A0think so.


Existing commerc= ial (non-IP) solutions are capable of re-routing quickly

= if they really have to.

=A0

= Let me try scoping the requirements to a potential solution:

= (no different from the req. docs for home and building)

=A0

= * P2P routing in any direction independent of the tree.

=A0

= * On-demand P2P route discovery if requested by a real-time critical app.
=A0 Data collection apps may be able to just wait for the next DAO update.<= /span>

=A0

= * Limited range of discovery mechanism: max 4 repeaters.

= =A0 A TTL field may limit the scope of the repeaters.

=A0

= * Suboptimal routing and traffic bursts are accepted in exchange

= =A0 for quick route repair. But only as an exception.

= =A0

=A0

= Just as an example,=A0one existing home control technology=A0uses a
(source routing) variant of AODV for quick route repair.

= Nothing comes for free. The price is flooding - but not just flooding:
Managed flooding using a distributed algorithm running in all
participating nodes.

= The algorithm dampens the flooding in a time,=A0volume and range perspective. <= /span>

= Some similar mechanism could be built into RPL for quick route repair.

=A0

=A0

= If=A0anyone have alternative proposals, please bring it to the list.

= Now is the time.

=A0

=A0

=A0

= Thanks,

= =A0 Anders


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


--00163600cd01adb71604814b467c-- From jpv@cisco.com Mon Mar 8 08:39: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 123AA3A69E1 for ; Mon, 8 Mar 2010 08:39:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=-4.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 L4ilBKZPnoBd for ; Mon, 8 Mar 2010 08:39:24 -0800 (PST) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by core3.amsl.com (Postfix) with ESMTP id 587773A69A6 for ; Mon, 8 Mar 2010 08:39:23 -0800 (PST) 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: AvYAAPK2lEuQ/uCWe2dsb2JhbACBRJlkFQEBCwskBhyhdZgYhHgE X-IronPort-AV: E=Sophos;i="4.49,603,1262563200"; d="scan'208,217";a="4095035" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-2.cisco.com with ESMTP; 08 Mar 2010 16:06:22 +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 o28GdP3r018308; Mon, 8 Mar 2010 16:39:25 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); Mon, 8 Mar 2010 17:39:25 +0100 Received: from ams-jvasseur-8713.cisco.com ([10.55.201.132]) by xfe-ams-202.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 8 Mar 2010 17:39:24 +0100 Message-Id: From: JP Vasseur To: d.sturek@att.net In-Reply-To: <006e01cabeca$691fbf80$3b5f3e80$@sturek@att.net> Content-Type: multipart/alternative; boundary=Apple-Mail-474--151129608 Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 8 Mar 2010 17:39:22 +0100 References: <6D9687E95918C04A8B30A7D6DA805A3E01429F5F@zensys17.zensys.local> <006e01cabeca$691fbf80$3b5f3e80$@sturek@att.net> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 08 Mar 2010 16:39:24.0479 (UTC) FILETIME=[E94EDCF0:01CABEDD] Cc: 'ROLL WG' Subject: Re: [Roll] P2P performance with current RPL proposal X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Mar 2010 16:39:27 -0000 --Apple-Mail-474--151129608 Content-Type: text/plain; charset=WINDOWS-1252; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Hi Don, On Mar 8, 2010, at 3:19 PM, Don Sturek wrote: > Hi Anders, > > First let me say +1 on your note. Agree these are the issues to =20 > solve. Absolutely. P2P supports is a clear MUST spelled out in many =20 requirements documents and as a WG we will provide a solution. The question is to judge how RPL in its current form is in support of =20= P2P for specific applications. Indeed, RPL does support P2P (although we have few issues to sort out =20= with regards to DAO) but is it good enough for all applications ? *with a co-chair hat off* Here is what I would recommend. * look at specific scenario for which we think there is a potential =20 issue (like the one listed by Anders) * see how we can deploy RPL: remember that one can deploy RPL with =20 more than one DODAG. If there is a critical destination, it could be the root of a new DODAG. * tune RPL accordingly See how far we are from what we need. * end* > I was happy to see JP add a ticket. I would encourage establishment =20= > of a subgroup within the DT to address these. These points have =20 > been open for some time. > Yes, we also need to close on a few items: * Security (The Security DT is working on it) * DAO mode of operation: new tickets will be opened soon, = packing, ... I do not think that we need another DT there. I'd rather have it a WG =20= discussion for the time being. > The trouble with =93managed flooding=94 is that it would be the =20 > application that would somehow have to know how many hops it needed =20= > to flood to fine the device of interest. That has been problematic =20= > in the past=85=85=85 Very much true. Thanks. JP. > > Don > > > From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf =20= > Of Anders Brandt > Sent: Monday, March 08, 2010 12:20 AM > To: ROLL WG > Subject: [Roll] P2P performance with current RPL proposal > > Hello > > I would like to probe the temperature of the WG on using DAOs to > support P2P. > > The building and home application spaces (and maybe others) have > a few clearly defined requirements. > It is not obvious to me how the current RPL proposal (cRPLp) can > satisfy those requirements: > > > In both cases it is the worst case scenario that hurts: > > > P2P routing inside the PAN > =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 > cRPLp has no way of routing inside the PAN if you need more than > one repeater. cRPLp has to go all the way to the top (maybe 4 hops up) > and down again (maybe 4 hops down) to get just 2 hops to the side. > > The consequence is high latency and high levels of background noise > for nodes just outside the direct radio range. > At the same time the risk of meeting a failing link is 4 times =20 > higher =3D> > latency may be much more than 4 times larger. > > Latency may sound like a minor issue but it actually translates =20 > directly > into lower battery lifetime. In the above (very realistic) example, > the battery lifetime is reduced to 25% of what it should be. > > We have lots of battery devices sending into the network: > * PIR sensors turning on lights > * Door locks sending alarms > * Door/window sensors starting chimes > * Smoke sensors triggering an alarm system > > > > > Response time > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > The latency issue is important. > When a user (real human being) presses a light button the user expects > the light to turn on. > cRPLp proposes that nodes in the tree periodically advertises their > presence using DAOs. > The periodicity is a real beast: > Thanks to Trickle, the rate of updates in a (apparently) stable =20 > network > is low. This is good since it leaves bandwidth for data. > But it is not good if existing routes to my lamp fail and I do not get > new routes to my lamp until it decides to send out a new DAO. > My user will (with a good reason) not tolerate waiting for minutes for > the light to turn on. > > I have met two arguments to counter this concern: > > A1: Well, your lamp can always send a DAO when it detects a problem. > My answer: > True, except that my lamp does not intend to send anything > so it will never experience any problems from its side of the =20 > network. > > A2: Well, you can increase the DAO rate to sub-second updates. > My answer: > Oh no. I get a very high degree of management traffic which > limits my available bandwidth, increases the risk of collisions and > even run the risk of violating EU legislation requiring me to only > transmit in less than 1% of the time: > http://focus.ti.com/lit/an/swra048/swra048.pdf > 868 - 868.6 MHz: <1% > > Reactiveness is hard to achieve via polling. > > > > If you agree that this seems to be critical issues please raise your > voice on the list. > > Going forward > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > We need some reactive mechanism to reach lamps before the user decides > to sue our companies. > So is this possible? I think so. > > Existing commercial (non-IP) solutions are capable of re-routing =20 > quickly > if they really have to. > > Let me try scoping the requirements to a potential solution: > (no different from the req. docs for home and building) > > * P2P routing in any direction independent of the tree. > > * On-demand P2P route discovery if requested by a real-time critical =20= > app. > Data collection apps may be able to just wait for the next DAO =20 > update. > > * Limited range of discovery mechanism: max 4 repeaters. > A TTL field may limit the scope of the repeaters. > > * Suboptimal routing and traffic bursts are accepted in exchange > for quick route repair. But only as an exception. > > > Just as an example, one existing home control technology uses a > (source routing) variant of AODV for quick route repair. > Nothing comes for free. The price is flooding - but not just flooding: > Managed flooding using a distributed algorithm running in all > participating nodes. > The algorithm dampens the flooding in a time, volume and range =20 > perspective. > Some similar mechanism could be built into RPL for quick route repair. > > > If anyone have alternative proposals, please bring it to the list. > Now is the time. > > > > Thanks, > Anders > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll --Apple-Mail-474--151129608 Content-Type: text/html; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable Hi Don,

On = Mar 8, 2010, at 3:19 PM, Don Sturek wrote:

Hi = Anders,
First = let me say +1 on your note.  Agree these are the issues to = solve.  =

Absolutel= y. P2P supports is a clear MUST spelled out in many requirements = documents and as a WG we will provide a solution.
The question = is to judge how RPL in its current form is in support of P2P for = specific applications.
Indeed, RPL does support P2P (although = we have few issues to sort out with regards to DAO) but is it good = enough for all
applications = ? 

*with a co-chair hat = off*

Here is what I would = recommend.
* look at specific scenario for which we think = there is a potential issue (like the one listed by Anders)
* = see how we can deploy RPL: remember that one can deploy RPL with more = than one DODAG.
If there is a critical destination, it could = be the root of a new DODAG.
* tune RPL = accordingly
See how far we are from what we = need.

* end* 

I was = happy to see JP add a ticket.  I would encourage establishment of a = subgroup within the DT to address these.  These points have been = open for some time.
* = Security (The Security DT is working on it)
* DAO = mode of operation: new tickets will be opened soon, packing, = ...

I do not think that we need another DT = there. I'd rather have it a WG discussion for the time = being.

The = trouble with =93managed flooding=94 is that it would be the application = that would somehow have to know how many hops it needed to flood to fine = the device of interest.  That has been problematic in the = past=85=85=85

<= div>Very much = true.

Thanks.

JP.
<= br>
From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Anders = Brandt
Sent: Monday, March 08, 2010 = 12:20 AM
To: ROLL = WG
Subject: [Roll] P2P performance with = current RPL proposal
 
I would like to probe the temperature of = the WG on using DAOs to
The building and home application spaces = (and maybe others) have
a few = clearly defined requirements.
It is = not obvious to me how the current RPL proposal (cRPLp) = can
satisfy those = requirements:
In both cases it is the worst case = scenario that hurts:
 
P2P routing inside the = PAN
cRPLp has no way of routing inside the = PAN if you need more than
one = repeater. cRPLp has to go all the way to the top (maybe 4 hops = up)
and down again (maybe 4 hops down) to get = just 2 hops to the side.
 
The consequence is = high latency and high levels of background noise
for nodes just = outside the direct radio range.
At the = same time the risk of meeting a failing link is 4 times higher = =3D>
latency may be much more than 4 times = larger.
Latency may sound like a minor issue but = it actually translates directly
into lower battery lifetime. In the = above (very realistic) example,
the = battery lifetime is reduced to 25% of what it should = be.
We have lots of battery devices sending = into the network:
* PIR = sensors turning on lights
* Door = locks sending alarms
* = Door/window sensors starting = chimes
* Smoke sensors = triggering an alarm system
Response = time
When a = user (real human being) presses a light button the user = expects
the light to turn = on.
cRPLp proposes that nodes in the tree = periodically advertises their
The = periodicity is a real beast:
Thanks = to Trickle, the rate of updates in a (apparently) stable network
is = low. This is good since it leaves bandwidth for = data.
But it is not good if existing routes to = my lamp fail and I do not get
new = routes to my lamp until it decides to send out a new = DAO.
My user will (with a good reason) not = tolerate waiting for minutes for
the = light to turn on.
 
I have met two = arguments to counter this = concern:
A1: Well, your lamp can always send a DAO = when it detects a problem.
  = True, except that my lamp does not intend to send = anything
  so it will = never experience any problems from its side of the = network.
A2: Well, you can increase the DAO rate = to sub-second updates.
  = My answer:
  Oh no. I get a very high degree of = management traffic which
  = limits my available bandwidth, increases the risk of collisions = and
  even run the risk of violating EU = legislation requiring me to only
  = transmit in less than 1% of the = time:
________________________________= _______________
Roll mailing list
 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [Roll] RPL spec v6 and OF0 draft v1: Identifying what needs to be specified in an Objective Function 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: Mon, 08 Mar 2010 16:53:18 -0000 Hello RPL and OF0 authors, I've been looking over draft-ietf-roll-of0-01 and draft-gnawali-roll-etxof-00 to help get a sense of which items left to be "specified by the implementation / implementation-dependent" in draft-ietf-roll-rpl-06 are to be specified by the objective function. My understanding is that of0 will eventually serve as a template for how future objective function specifications should be written (together with Section 10 of draft-ietf-roll-rpl-06, which will indicate what MUST be specified by an OF). OF0 currently is tasked to specify: 1) selection of parents and siblings 2) how to compute the rank I suggest that some sections be added, maybe as placeholders for now, to specify: 1) The format/fields of the Objective Code Point, following the OCP object format from the ROLL routing metrics document (draft-ietf-roll-routing-metrics-04, pg. 24, Sec. 6, Fig. 19). This is especially important because it indicates what parameters of the Objective Function are left for tuning. For instance, it is hard to spot the optional preference in (draft-ietf-roll-of0-01, pg. 5, Sec. 3.2, point #8). 2) The rules for how a node decides to "defer" joining or migrating to a new DODAG iteration. I believe this has a large impact on how well a DODAG iteration optimizes a metric. If this is arbitrary and left up to each vendor to implement separately, there is no reason to expect that the nodes in the network will cooperate to reach an optimum DODAG. I'm referring to (draft-ietf-roll-rpl-06, pg. 34, Sec. 5.3.3.4): "An implementation could defer to migrate for some reasonable amount of time, to see if some other neighbors with potentially better metrics but higher rank announce themselves." 3) What constitutes a redundant DIO message. This determines which nodes that have joined the DODAG iteration can talk, and thus the set of candidate neighbors that a node can choose as a parent. I'll send a follow up email elaborating my thoughts on this. I'm referring to (draft-ietf-roll-rpl-06, pg. 38, Section 5.3.5.1.1): "The exact determination of what constitutes a redundant DIO message is left to an implementation; it could for example include DIOs that advertise the same rank." 4) How the metric used by this OF may be considered inconsistent, for the sake of the Trickle timer. I'm referring to (draft-ietf-roll-rpl-06, pg. 38, Sec. 5.3.5.1.2): "A metric communicated in the DIO message is determined to be inconsistent, as according to a implementation specific path metric selection engine." 5) The rules for a node to choose which DODAG to join, when it has multiple choices within an RPLInstance. I'm guessing that in most cases it is only specified by the DODAGPreference field in the DIO Base Option, but the rules should be made explicit for each OF. I'm referring to (draft-ietf-roll-rpl-06, pg. 33, Sec. 5.3.3.3.) "If a node has the option to join a more preferred DODAG while still meeting other optimization objectives, then the node will generally seek to join the more preferred DODAG as determined by the OF." and also (draft-ietf-roll-rpl-06, pg. 39, Sec. 5.3.6): "The DODAG selection is implementation and algorithm dependent. Nodes SHOULD prefer to join DODAGs for RPLInstanceIDs advertising OCPs and destinations compatible with their implementation specific objectives." 6) The rules for how a node decides to jump to another DODAG. This should be related to the value of the node's metric and rank. I'm referring to (draft-ietf-roll-rpl-06, pg. 34, Sec. 5.3.3.4): "A node MAY, at any time, choose to join a different DODAG within a RPL Instance." 7) What triggers the parent selection process. As I understand, a node is allowed to change parents within a DODAG iteration, so long as it does not violate any rank constraints. If the trigger for the parent selection process is the same across all OFs, then it should be made clear in the RPL core specification (the current wording is ambiguous). I'm referring to (draft-ietf-roll-rpl-06, pg. 58, Sec. 10): "The parent selection is triggered each time an event indicates that a potential next hop information is updated. This might happen upon the reception of a DIO message, a timer elapse, or a trigger indicating that the state of a candidate neighbor has changed." I also suggest that (draft-ietf-roll-of0-01, pg. 4, Sec. 3.1) be broken up into separate sections: * the general description of the goal * a placeholder for how to compute the metric (even if it is irrelevant here since there is no metric) * the rules for computing the rank * how to use administrative preference The rules for computing the rank should also include a sentence or a subsection on how and when administrative rank is to be used to adjust the rank computed from the objective function. Or it should say that it is not used. The guidelines for writing OFs in (draft-ietf-roll-rpl-06, pg. 58, Sec. 10) should say that administrative rank must be addressed in an OF specification. I'm referring to (draft-ietf-roll-rpl-06, pg. 39, Sec. 5.5) "In some cases it might be beneficial to adjust the rank advertised by a node beyond that computed by the OF based on some implementation specific policy and properties of the node." I'm not sure if it's necessary to have a separate "Advertise the metric" section, like in (draft-gnawali-roll-etxof-00, pg. 6, Sec. 3.3), or if it can be merged into a section on how to compute the metric. The way I think of OFs, a node decides on a single metric and rank, and that is what it is always advertised. Also, is the propagation of metrics different from OF to OF? Otherwise, change the text in the RPL core spec: (draft-ietf-roll-rpl-06, pg. 27, Sec. 5.1.3.4) "The processing and propagation of the Metric Container is governed by implementation specific policy functions." Another point for consideration is whether the rules for how a node decides to lower its rank should be made explicit in a separate section from the "Preferred Parent Selection" section. I'm not sure myself. I'm referring to (draft-ietf-roll-rpl-06, pg. 34, Sec. 5.3.3.4): "When a node moves to improve its position,... Such a movement may occur at any time to decrease the rank, as per the calculation indicated by the OF." I didn't understand if there are separate OFs for upwards or downwards routing... whether there should be placeholder sections for DAO rank, DAO metrics, etc. I suppose this has yet to be decided. -- Phoebus Chen Postdoctoral Researcher Automatic Control Lab, KTH (Royal Institute of Technology) http://www.ee.kth.se/~phoebus P.S. There are some mechanisms in the RPL specification marked as "implementation-dependent" that may not belong in an objective function. Some of these are mentioned in (draft-ietf-roll-rpl-06, Sec. 11 and 12). I see these sections as also serving the purpose of helping an implementer keep track of what he needs to tune (and what he may have implemented differently from other implementers, if their implementations turn out to be incompatible or interact in unpredictable ways). I've tried to list some of the "implementation-dependent" mechanisms mentioned in the document that were missed in Sections 11 and 12. It might also help the reader to separate out what can be tuned over the network via messages (besides the ones defined thus far) and what is only tuned on the devices before deployment. Poisoning Interval (draft-ietf-roll-rpl-06, pg. 14, Sec. 3.4.2) "Such a move may be undertaken after waiting an appropriate poisoning interval, and should allow the node to restore connectivity to the DODAG Iteration, if at all possible." Selection of the candidate neighbors (indirectly mentioned in Sec. 12.3.1) (draft-ietf-roll-rpl-06, pg. 30, Sec. 5.3.2) "The exact policies for selecting neighbors and parents is implementation-dependent." Whether to forward packets to future parents (draft-ietf-roll-rpl-06, pg. 32, Sec. 5.3.3.1) "During transition to a new DODAG Iteration, a node may decide to forward packets via 'future parents' that belong to the same DODAG (same RPLInstanceID and DODAGID), but are observed to advertise a more recent (incremented) DODAGSequenceNumber." Whether to poison a sub-DAG before increasing rank and moving, or form a floating DODAG (draft-ietf-roll-rpl-06, pg. 34, Sec. 5.3.3.4) "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." (draft-ietf-roll-rpl-06, pg. 35, Sec. 5.3.3.5) "An implementation may choose to employ this poisoning mechanism when a node loses all of its current parents, i.e. the set of DODAG parents becomes depleted, and it can not jump to an alternate DODAG. An alternate mechanism is to form a floating DODAG." Risk Window (draft-ietf-roll-rpl-06, pg. 40, Sec. 5.6) "It left to the implementation to define the duration of the risk window." From pister@eecs.berkeley.edu Mon Mar 8 11:44: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 20D233A6B94 for ; Mon, 8 Mar 2010 11:44:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gzLNcGzjWLs9 for ; Mon, 8 Mar 2010 11:44:56 -0800 (PST) Received: from gateway0.EECS.Berkeley.EDU (gateway0.EECS.Berkeley.EDU [169.229.60.87]) by core3.amsl.com (Postfix) with ESMTP id 93E2A3A6B11 for ; Mon, 8 Mar 2010 11:44:56 -0800 (PST) Received: from [128.32.32.46] (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 o28Jiujo004562 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 8 Mar 2010 11:44:58 -0800 (PST) Message-ID: <4B9553B8.6010001@eecs.berkeley.edu> Date: Mon, 08 Mar 2010 11:44:56 -0800 From: Kris Pister User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Anders Brandt References: <6D9687E95918C04A8B30A7D6DA805A3E01429F5F@zensys17.zensys.local> In-Reply-To: <6D9687E95918C04A8B30A7D6DA805A3E01429F5F@zensys17.zensys.local> Content-Type: multipart/alternative; boundary="------------070207010506020108070100" Cc: ROLL WG Subject: Re: [Roll] P2P performance with current RPL proposal X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Mar 2010 19:44:58 -0000 This is a multi-part message in MIME format. --------------070207010506020108070100 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Anders - if we take JP's suggestion to make The Lamp a DODAG root, and take Phoebus' recommendation that we use path diversity to improve end-to-end reliability, do you see a chance of success? In my experience, with diverse paths and order-minutes updates you get extremely high reliability. I have no aversion to TTL-limited floods as a part of a solution either. I'm open to ideas on how to bring those in as (presumably infrequently used) options. ksjp Anders Brandt wrote: > Hello > > I would like to probe the temperature of the WG on using DAOs to > support P2P. > > The building and home application spaces (and maybe others) have > a few clearly defined requirements. > It is not obvious to me how the current RPL proposal (cRPLp) can > satisfy those requirements: > > > In both cases it is the worst case scenario that hurts: > > > P2P routing inside the PAN > ========================== > cRPLp has no way of routing inside the PAN if you need more than > one repeater. cRPLp has to go all the way to the top (maybe 4 hops up) > and down again (maybe 4 hops down) to get just 2 hops to the side. > > The consequence is high latency and high levels of background noise > for nodes just outside the direct radio range. > At the same time the risk of meeting a failing link is 4 times higher => > latency may be much more than 4 times larger. > > Latency may sound like a minor issue but it actually translates directly > into lower battery lifetime. In the above (very realistic) example, > the battery lifetime is reduced to 25% of what it should be. > > We have lots of battery devices sending into the network: > * PIR sensors turning on lights > * Door locks sending alarms > * Door/window sensors starting chimes > * Smoke sensors triggering an alarm system > > > > > Response time > ============= > The latency issue is important. > When a user (real human being) presses a light button the user expects > the light to turn on. > cRPLp proposes that nodes in the tree periodically advertises their > presence using DAOs. > The periodicity is a real beast: > Thanks to Trickle, the rate of updates in a (apparently) stable network > is low. This is good since it leaves bandwidth for data. > But it is not good if existing routes to my lamp fail and I do not get > new routes to my lamp until it decides to send out a new DAO. > My user will (with a good reason) not tolerate waiting for minutes for > the light to turn on. > > I have met two arguments to counter this concern: > > A1: Well, your lamp can always send a DAO when it detects a problem. > My answer: > True, except that my lamp does not intend to send anything > so it will never experience any problems from its side of the network. > > A2: Well, you can increase the DAO rate to sub-second updates. > My answer: > Oh no. I get a very high degree of management traffic which > limits my available bandwidth, increases the risk of collisions and > even run the risk of violating EU legislation requiring me to only > transmit in less than 1% of the time: > http://focus.ti.com/lit/an/swra048/swra048.pdf > 868 - 868.6 MHz: <1% > > Reactiveness is hard to achieve via polling. > > > > If you agree that this seems to be critical issues please raise your > voice on the list. > > Going forward > ============= > > We need some reactive mechanism to reach lamps before the user decides > to sue our companies. > So is this possible? I think so. > > Existing commercial (non-IP) solutions are capable of re-routing quickly > if they really have to. > > Let me try scoping the requirements to a potential solution: > (no different from the req. docs for home and building) > > * P2P routing in any direction independent of the tree. > > * On-demand P2P route discovery if requested by a real-time critical app. > Data collection apps may be able to just wait for the next DAO update. > > * Limited range of discovery mechanism: max 4 repeaters. > A TTL field may limit the scope of the repeaters. > > * Suboptimal routing and traffic bursts are accepted in exchange > for quick route repair. But only as an exception. > > > Just as an example, one existing home control technology uses a > (source routing) variant of AODV for quick route repair. > Nothing comes for free. The price is flooding - but not just flooding: > Managed flooding using a distributed algorithm running in all > participating nodes. > The algorithm dampens the flooding in a time, volume and range > perspective. > Some similar mechanism could be built into RPL for quick route repair. > > > If anyone have alternative proposals, please bring it to the list. > Now is the time. > > > > Thanks, > Anders > ------------------------------------------------------------------------ > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > --------------070207010506020108070100 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Anders - if we take JP's suggestion to make The Lamp a DODAG root, and take Phoebus' recommendation that we use path diversity to improve end-to-end reliability, do you see a chance of success?
In my experience, with diverse paths and order-minutes updates you get extremely high reliability.

I have no aversion to TTL-limited floods as a part of a solution either.  I'm open to ideas on how to bring those in as (presumably infrequently used) options.

ksjp

Anders Brandt wrote:
Hello
 
I would like to probe the temperature of the WG on using DAOs to
support P2P.
 
The building and home application spaces (and maybe others) have
a few clearly defined requirements.
It is not obvious to me how the current RPL proposal (cRPLp) can
satisfy those requirements:
 
 
In both cases it is the worst case scenario that hurts:
 
 
P2P routing inside the PAN
==========================
cRPLp has no way of routing inside the PAN if you need more than
one repeater. cRPLp has to go all the way to the top (maybe 4 hops up)
and down again (maybe 4 hops down) to get just 2 hops to the side.
 
The consequence is high latency and high levels of background noise
for nodes just outside the direct radio range.
At the same time the risk of meeting a failing link is 4 times higher =>
latency may be much more than 4 times larger.
 
Latency may sound like a minor issue but it actually translates directly
into lower battery lifetime. In the above (very realistic) example,
the battery lifetime is reduced to 25% of what it should be.
 
We have lots of battery devices sending into the network:
* PIR sensors turning on lights
* Door locks sending alarms
* Door/window sensors starting chimes
* Smoke sensors triggering an alarm system
 
 
 
 
Response time
=============
The latency issue is important.
When a user (real human being) presses a light button the user expects
the light to turn on.
cRPLp proposes that nodes in the tree periodically advertises their
presence using DAOs.
The periodicity is a real beast:
Thanks to Trickle, the rate of updates in a (apparently) stable network
is low. This is good since it leaves bandwidth for data.
But it is not good if existing routes to my lamp fail and I do not get
new routes to my lamp until it decides to send out a new DAO.
My user will (with a good reason) not tolerate waiting for minutes for
the light to turn on.
 
I have met two arguments to counter this concern:
 
A1: Well, your lamp can always send a DAO when it detects a problem.
  My answer:
  True, except that my lamp does not intend to send anything
  so it will never experience any problems from its side of the network.
 
A2: Well, you can increase the DAO rate to sub-second updates.
  My answer:
  Oh no. I get a very high degree of management traffic which
  limits my available bandwidth, increases the risk of collisions and
  even run the risk of violating EU legislation requiring me to only
  transmit in less than 1% of the time:
 
  Reactiveness is hard to achieve via polling.
 
 
 
If you agree that this seems to be critical issues please raise your
voice on the list.
 
Going forward
=============
 
We need some reactive mechanism to reach lamps before the user decides
to sue our companies.
So is this possible? I think so.

Existing commercial (non-IP) solutions are capable of re-routing quickly
if they really have to.
 
Let me try scoping the requirements to a potential solution:
(no different from the req. docs for home and building)
 
* P2P routing in any direction independent of the tree.
 
* On-demand P2P route discovery if requested by a real-time critical app.
  Data collection apps may be able to just wait for the next DAO update.
 
* Limited range of discovery mechanism: max 4 repeaters.
  A TTL field may limit the scope of the repeaters.
 
* Suboptimal routing and traffic bursts are accepted in exchange
  for quick route repair. But only as an exception.
 
 
Just as an example, one existing home control technology uses a
(source routing) variant of AODV for quick route repair.
Nothing comes for free. The price is flooding - but not just flooding:
Managed flooding using a distributed algorithm running in all
participating nodes.
The algorithm dampens the flooding in a time, volume and range perspective.
Some similar mechanism could be built into RPL for quick route repair.
 
 
If anyone have alternative proposals, please bring it to the list.
Now is the time.
 
 
 
Thanks,
  Anders

_______________________________________________
Roll mailing list
Roll@ietf.org
https://www.ietf.org/mailman/listinfo/roll
--------------070207010506020108070100-- From Ted.Humpal@jci.com Mon Mar 8 12:08: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 7845B3A69AC; Mon, 8 Mar 2010 12:08:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.044 X-Spam-Level: X-Spam-Status: No, score=-5.044 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, HTML_MIME_NO_HTML_TAG=0.097, MIME_HTML_ONLY=1.457, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id swV7XONsyxXr; Mon, 8 Mar 2010 12:08:31 -0800 (PST) Received: from exprod8og113.obsmtp.com (exprod8og113.obsmtp.com [64.18.3.26]) by core3.amsl.com (Postfix) with ESMTP id 5FE6F3A6991; Mon, 8 Mar 2010 12:08:30 -0800 (PST) Received: from source ([192.132.24.137]) (using SSLv3) by exprod8ob113.postini.com ([64.18.7.12]) with SMTP ID DSNKS5VZPUx7zZVboYDAG+jpT8EH7QxlTdWx@postini.com; Mon, 08 Mar 2010 12:08:35 PST Received: from jwimkrs1.na.jci.com ([10.10.6.31]) by smtpmke01.jci.com (Lotus Domino Release 8.0.1) with ESMTP id 2010030814083265-353274 ; Mon, 8 Mar 2010 14:08:32 -0600 In-Reply-To: <4B9553B8.6010001@eecs.berkeley.edu> References: <6D9687E95918C04A8B30A7D6DA805A3E01429F5F@zensys17.zensys.local> <4B9553B8.6010001@eecs.berkeley.edu> To: Kris Pister MIME-Version: 1.0 X-KeepSent: 8C20C224:DA806964-862576E0:006D113D; 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, 8 Mar 2010 14:08:13 -0600 X-MIMETrack: Serialize by Router on jwimkrs1.na.jci.com/NA/Johnson_Controls at 03/08/2010 02:08:20 PM, Serialize complete at 03/08/2010 02:08:20 PM, Itemize by SMTP Server on smtpmke01.jci.com/JCI_SMTP(Release 8.0.1|February 07, 2008) at 03/08/2010 02:08:32 PM, Serialize by Router on smtpmke01.jci.com/JCI_SMTP(Release 8.0.1|February 07, 2008) at 03/08/2010 02:08:46 PM, Serialize complete at 03/08/2010 02:08:46 PM Content-Type: text/html; charset="US-ASCII" Cc: ROLL WG , roll-bounces@ietf.org Subject: Re: [Roll] P2P performance with current RPL proposal X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Mar 2010 20:08:32 -0000
A concern also will be how much overhead (memory space) will be required for a DODAG Root?

and based on the first question how many DODAG roots a lamp may need to be a member of?

For example in lighting  a single lamp may be a root for a single switch (1 DODAG root),  this lamp / luminaire may also
be a member of another group - -  which could be all lights on the floor (2nd DODAG root), and a third group
of all the lights in the building.  There can be many more speciality groups associated based on the building configuration.
Consider also during the installation time - how these DODAG roots will be configured?  Must I commission each device
to tell it which DODAG it must use for its Object Function?  How easy will this be to change and add in a new DODAG root
for the end user if the lighting group changes??

With respect to Jerry Martocci's - commercial building requirements - every device may need to communicate to any or
all of the end devices.  If each device must establish a DODAG for the other 499 devices in a 500 node network - How much memory
space will this require for each end device to maintain?  

Keep in mind that the end devices are very limited processor and memory wise.

Not to mention all of the network maintenance messages that would need to be transmitted to maintain all of these DODAGs.

Consider the reconvergence time when one device is turned off and it was in the middle of the majority of the 100+ DODAGS?

In many lighting and building application an application acknowledgement - must be returned {Back down the DODAG} so . . . the
requirement is not just getting to the Root - a return path must also be maintained and have a  low latency path.

Ted Humpal




From: Kris Pister <pister@eecs.berkeley.edu>
To: Anders Brandt <abr@sdesigns.dk>
Cc: ROLL WG <roll@ietf.org>
Date: 03/08/2010 01:45 PM
Subject: Re: [Roll] P2P performance with current RPL proposal




Anders - if we take JP's suggestion to make The Lamp a DODAG root, and take Phoebus' recommendation that we use path diversity to improve end-to-end reliability, do you see a chance of success?
In my experience, with diverse paths and order-minutes updates you get extremely high reliability.

I have no aversion to TTL-limited floods as a part of a solution either.  I'm open to ideas on how to bring those in as (presumably infrequently used) options.

ksjp

Anders Brandt wrote:
Hello
 
I would like to probe the temperature of the WG on using DAOs to
support P2P.
 
The building and home application spaces (and maybe others) have
a few clearly defined requirements.
It is not obvious to me how the current RPL proposal (cRPLp) can
satisfy those requirements:
 
 
In both cases it is the worst case scenario that hurts:
 
 
P2P routing inside the PAN
==========================
cRPLp has no way of routing inside the PAN if you need more than
one repeater. cRPLp has to go all the way to the top (maybe 4 hops up)
and down again (maybe 4 hops down) to get just 2 hops to the side.
 
The consequence is high latency and high levels of background noise
for nodes just outside the direct radio range.
At the same time the risk of meeting a failing link is 4 times higher =>
latency may be much more than 4 times larger.
 
Latency may sound like a minor issue but it actually translates directly
into lower battery lifetime. In the above (very realistic) example,
the battery lifetime is reduced to 25% of what it should be.
 
We have lots of battery devices sending into the network:
* PIR sensors turning on lights
* Door locks sending alarms
* Door/window sensors starting chimes
* Smoke sensors triggering an alarm system
 
 
 
 
Response time
=============
The latency issue is important.
When a user (real human being) presses a light button the user expects
the light to turn on.
cRPLp proposes that nodes in the tree periodically advertises their
presence using DAOs.
The periodicity is a real beast:
Thanks to Trickle, the rate of updates in a (apparently) stable network
is low. This is good since it leaves bandwidth for data.
But it is not good if existing routes to my lamp fail and I do not get
new routes to my lamp until it decides to send out a new DAO.
My user will (with a good reason) not tolerate waiting for minutes for
the light to turn on.
 
I have met two arguments to counter this concern:
 
A1: Well, your lamp can always send a DAO when it detects a problem.
  My answer:
  True, except that my lamp does not intend to send anything
  so it will never experience any problems from its side of the network.
 
A2: Well, you can increase the DAO rate to sub-second updates.
  My answer:
  Oh no. I get a very high degree of management traffic which
  limits my available bandwidth, increases the risk of collisions and
  even run the risk of violating EU legislation requiring me to only
  transmit in less than 1% of the time:
  http://focus.ti.com/lit/an/swra048/swra048.pdf
 868 - 868.6 MHz: <1%
 
  Reactiveness is hard to achieve via polling.
 
 
 
If you agree that this seems to be critical issues please raise your
voice on the list.
 
Going forward
=============
 
We need some reactive mechanism to reach lamps before the user decides
to sue our companies.
So is this possible? I think so.

Existing commercial (non-IP) solutions are capable of re-routing quickly
if they really have to.
 
Let me try scoping the requirements to a potential solution:
(no different from the req. docs for home and building)
 
* P2P routing in any direction independent of the tree.
 
* On-demand P2P route discovery if requested by a real-time critical app.
 Data collection apps may be able to just wait for the next DAO update.
 
* Limited range of discovery mechanism: max 4 repeaters.
  A TTL field may limit the scope of the repeaters.
 
* Suboptimal routing and traffic bursts are accepted in exchange
  for quick route repair. But only as an exception.
 
 
Just as an example, one existing home control technology uses a
(source routing) variant of AODV for quick route repair.
Nothing comes for free. The price is flooding - but not just flooding:
Managed flooding using a distributed algorithm running in all
participating nodes.
The algorithm dampens the flooding in a time, volume and range perspective.
Some similar mechanism could be built into RPL for quick route repair.
 
 
If anyone have alternative proposals, please bring it to the list.
Now is the time.
 
 
 
Thanks,
  Anders


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

From d.sturek@att.net Mon Mar 8 13:58: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 0B85B3A6A1C for ; Mon, 8 Mar 2010 13:58:37 -0800 (PST) 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 32VtpCQ7skPo for ; Mon, 8 Mar 2010 13:58:22 -0800 (PST) Received: from smtp104.sbc.mail.gq1.yahoo.com (smtp104.sbc.mail.gq1.yahoo.com [67.195.15.63]) by core3.amsl.com (Postfix) with SMTP id 30B013A69C6 for ; Mon, 8 Mar 2010 13:58:22 -0800 (PST) Received: (qmail 51466 invoked from network); 8 Mar 2010 21:58:23 -0000 Received: from adsl-67-124-203-61.dsl.sndg02.pacbell.net (d.sturek@67.124.203.61 with login) by smtp104.sbc.mail.gq1.yahoo.com with SMTP; 08 Mar 2010 13:58:23 -0800 PST X-Yahoo-SMTP: fvjol_aswBAraSJvMLe2r1XTzhBhbFxY8q8c3jo- X-YMail-OSG: _kSrMDwVM1nQk16izOtGmSjAd8b6pul2N7h8SKEw_J6weWZtiam0gRskjxwUIFsRxRbmRMRqO4DKJfWHs7mHhf7u0mnnqnnODGIWsdvFlFiskKBYL93zzM801Q4uCss425SSStdj1XaEFg7ctfrAn57HJfTFUiWTJm0U.f6LYlTA.TaZQHa6p4SxQdq5FO65qcsE2nes8rSiWQex2xL.rmYOAvrBr9PUCSTzWF33RJaVbRfL1jRXwvh.vyrToc7W1wsCXFVTdhdpDdz0cLRJqBUqJle0hkhxv197_hvnXGYzswEv2U4- X-Yahoo-Newman-Property: ymail-3 From: "Don Sturek" To: "'Kris Pister'" , "'Anders Brandt'" References: <6D9687E95918C04A8B30A7D6DA805A3E01429F5F@zensys17.zensys.local> <4B9553B8.6010001@eecs.berkeley.edu> In-Reply-To: <4B9553B8.6010001@eecs.berkeley.edu> Date: Mon, 8 Mar 2010 13:58:21 -0800 Message-ID: <009801cabf0a$784a16a0$68de43e0$@sturek@att.net> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0099_01CABEC7.6A26D6A0" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acq+99mTLBY/NcFLQh2DxMXHWRicGQAEfrIA Content-Language: en-us Cc: 'ROLL WG' Subject: Re: [Roll] P2P performance with current RPL proposal 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, 08 Mar 2010 21:58:37 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0099_01CABEC7.6A26D6A0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Kris, In general it is a bad idea to map application function (like a lamp) to network function (like DODAG root) to help address latency concerns. This won't scale if you look at the use cases for building or home automation. Don From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Kris Pister Sent: Monday, March 08, 2010 11:45 AM To: Anders Brandt Cc: ROLL WG Subject: Re: [Roll] P2P performance with current RPL proposal Anders - if we take JP's suggestion to make The Lamp a DODAG root, and take Phoebus' recommendation that we use path diversity to improve end-to-end reliability, do you see a chance of success? In my experience, with diverse paths and order-minutes updates you get extremely high reliability. I have no aversion to TTL-limited floods as a part of a solution either. I'm open to ideas on how to bring those in as (presumably infrequently used) options. ksjp Anders Brandt wrote: Hello I would like to probe the temperature of the WG on using DAOs to support P2P. The building and home application spaces (and maybe others) have a few clearly defined requirements. It is not obvious to me how the current RPL proposal (cRPLp) can satisfy those requirements: In both cases it is the worst case scenario that hurts: P2P routing inside the PAN ========================== cRPLp has no way of routing inside the PAN if you need more than one repeater. cRPLp has to go all the way to the top (maybe 4 hops up) and down again (maybe 4 hops down) to get just 2 hops to the side. The consequence is high latency and high levels of background noise for nodes just outside the direct radio range. At the same time the risk of meeting a failing link is 4 times higher => latency may be much more than 4 times larger. Latency may sound like a minor issue but it actually translates directly into lower battery lifetime. In the above (very realistic) example, the battery lifetime is reduced to 25% of what it should be. We have lots of battery devices sending into the network: * PIR sensors turning on lights * Door locks sending alarms * Door/window sensors starting chimes * Smoke sensors triggering an alarm system Response time ============= The latency issue is important. When a user (real human being) presses a light button the user expects the light to turn on. cRPLp proposes that nodes in the tree periodically advertises their presence using DAOs. The periodicity is a real beast: Thanks to Trickle, the rate of updates in a (apparently) stable network is low. This is good since it leaves bandwidth for data. But it is not good if existing routes to my lamp fail and I do not get new routes to my lamp until it decides to send out a new DAO. My user will (with a good reason) not tolerate waiting for minutes for the light to turn on. I have met two arguments to counter this concern: A1: Well, your lamp can always send a DAO when it detects a problem. My answer: True, except that my lamp does not intend to send anything so it will never experience any problems from its side of the network. A2: Well, you can increase the DAO rate to sub-second updates. My answer: Oh no. I get a very high degree of management traffic which limits my available bandwidth, increases the risk of collisions and even run the risk of violating EU legislation requiring me to only transmit in less than 1% of the time: http://focus.ti.com/lit/an/swra048/swra048.pdf 868 - 868.6 MHz: <1% Reactiveness is hard to achieve via polling. If you agree that this seems to be critical issues please raise your voice on the list. Going forward ============= We need some reactive mechanism to reach lamps before the user decides to sue our companies. So is this possible? I think so. Existing commercial (non-IP) solutions are capable of re-routing quickly if they really have to. Let me try scoping the requirements to a potential solution: (no different from the req. docs for home and building) * P2P routing in any direction independent of the tree. * On-demand P2P route discovery if requested by a real-time critical app. Data collection apps may be able to just wait for the next DAO update. * Limited range of discovery mechanism: max 4 repeaters. A TTL field may limit the scope of the repeaters. * Suboptimal routing and traffic bursts are accepted in exchange for quick route repair. But only as an exception. Just as an example, one existing home control technology uses a (source routing) variant of AODV for quick route repair. Nothing comes for free. The price is flooding - but not just flooding: Managed flooding using a distributed algorithm running in all participating nodes. The algorithm dampens the flooding in a time, volume and range perspective. Some similar mechanism could be built into RPL for quick route repair. If anyone have alternative proposals, please bring it to the list. Now is the time. Thanks, Anders _____ _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll ------=_NextPart_000_0099_01CABEC7.6A26D6A0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Kris,

 

In general it is a bad idea to map application function = (like a lamp) to network function (like DODAG root) to help address latency concerns.   This won’t scale if you look at the use = cases for building or home automation.

 

Don

 

 

From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Kris Pister
Sent: Monday, March 08, 2010 11:45 AM
To: Anders Brandt
Cc: ROLL WG
Subject: Re: [Roll] P2P performance with current RPL = proposal

 

Anders - if we take JP's suggestion to make The = Lamp a DODAG root, and take Phoebus' recommendation that we use path diversity to = improve end-to-end reliability, do you see a chance of success?
In my experience, with diverse paths and order-minutes updates you get extremely high reliability.

I have no aversion to TTL-limited floods as a part of a solution = either.  I'm open to ideas on how to bring those in as (presumably infrequently = used) options.

ksjp

Anders Brandt wrote:

Hello

=

 

I would like to probe the temperature of the WG on using DAOs = to

support P2P.

 

The building and home application spaces (and maybe others) = have

a few clearly defined requirements.

It is not obvious to me how the current RPL proposal (cRPLp) = can

satisfy those requirements:

 

 

In both cases it is the worst case scenario that hurts:

 

 

P2P routing inside the PAN

=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

=

cRPLp has no way of routing inside the PAN if you need more = than

one repeater. cRPLp has to go all the way to the top (maybe 4 hops = up)

and down again (maybe 4 hops down) to get just 2 hops to the = side.

 

The consequence is high latency and high levels of background noise
for nodes just outside the direct radio range.

At the same time the risk of meeting a failing link is 4 times higher = =3D>

latency may be much more than 4 times larger.

 

Latency may sound like a minor issue but it actually translates directly
into lower battery lifetime. In the above (very realistic) = example,

the battery lifetime is reduced to 25% of what it should = be.

 

We have lots of battery devices sending into the network:

* PIR sensors turning on lights

* Door locks sending alarms

* Door/window sensors starting chimes

* Smoke sensors triggering an alarm system

 

 

 

 

Response time

=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D

The latency issue is important.

When a user (real human being) presses a light button the user = expects

the light to turn on.

cRPLp proposes that nodes in the tree periodically advertises = their

presence using DAOs.

The periodicity is a real beast:

Thanks to Trickle, the rate of updates in a (apparently) stable network
is low. This is good since it leaves bandwidth for = data.

But it is not good if existing routes to my lamp fail and I do not = get

new routes to my lamp until it decides to send out a new DAO.

My user will (with a good reason) not tolerate waiting for minutes = for

the light to turn on.

 

I have met two arguments to counter this concern:

 

A1: Well, your lamp can always send a DAO when it detects a = problem.

  My answer:

  True, except that my lamp does not intend to send = anything

  so it will never experience any problems from its side of the = network.

 

A2: Well, you can increase the DAO rate to sub-second = updates.

  My answer:

  Oh no. I get a very high degree of = management traffic which

  limits my available bandwidth, increases the risk of collisions = and

  even run the risk of violating EU legislation requiring me to = only

  transmit in less than 1% of the time:

  http://focus.ti.com/lit/an/swra048/swra048.pdf
  868 - = 868.6 MHz: <1%

 

  Reactiveness is hard to achieve via polling.

 

 

 

If you agree that this seems to be critical issues please raise = your

voice on the list.

 

Going forward

=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D

 

We need some reactive mechanism to reach lamps before the user = decides

to sue our companies.

So is this possible? I think so.


Existing = commercial (non-IP) solutions are capable of re-routing quickly

if they really have to.

 

Let me try scoping the requirements to a potential solution:

(no different from the req. docs for home and building)

 

* P2P routing in any direction independent of the tree.

 

* On-demand P2P route discovery if requested by a real-time critical app.
  Data collection apps may be able to just wait for the next DAO = update.

 

* Limited range of discovery mechanism: max 4 repeaters.

  A TTL field may limit the scope of the repeaters.

 

* Suboptimal routing and traffic bursts are accepted in = exchange

  for quick route repair. But only as an exception.

 

 

Just as an example, one existing home control technology uses a
(source routing) variant of AODV for quick route repair.

Nothing comes for free. The price is flooding - but not just flooding:
Managed flooding using a distributed algorithm running in all
participating nodes.

The algorithm dampens the flooding in a time, volume and range = perspective.

Some similar mechanism could be built into RPL for quick route = repair.

 

 

If anyone have alternative proposals, please bring it to the list.

Now is the time.

 

 

 

Thanks,

  Anders

 





 
__________________________________=
_____________
Roll mailing =
list
Roll@ietf.org
https://www.ietf.org/=
mailman/listinfo/roll
  =
------=_NextPart_000_0099_01CABEC7.6A26D6A0-- From phoebus@ieee.org Mon Mar 8 14:28: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 CA2473A69E1 for ; Mon, 8 Mar 2010 14:28:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.249 X-Spam-Level: X-Spam-Status: No, score=-106.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jbpwDQwtXzni for ; Mon, 8 Mar 2010 14:28:27 -0800 (PST) Received: from smtp-1.sys.kth.se (smtp-1.sys.kth.se [130.237.32.175]) by core3.amsl.com (Postfix) with ESMTP id 774143A69CA for ; Mon, 8 Mar 2010 14:28:27 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by smtp-1.sys.kth.se (Postfix) with ESMTP id B5876157084; Mon, 8 Mar 2010 23:28:00 +0100 (CET) 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 r0WwA8rqcEtY; Mon, 8 Mar 2010 23:27:57 +0100 (CET) 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-1.sys.kth.se (Postfix) with ESMTP id 30757157057; Mon, 8 Mar 2010 23:27:56 +0100 (CET) Message-ID: <4B9579EB.6040604@ieee.org> Date: Mon, 08 Mar 2010 23:27:55 +0100 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.8) Gecko/20100227 Thunderbird/3.0.3 MIME-Version: 1.0 To: Philip Levis , gnawali@cs.stanford.edu, joakime@sics.se References: <20100226011704.C9E4D28C140@core3.amsl.com> <6CE3E5D3-DAEE-45E7-9C16-1260BD345A46@cs.stanford.edu> In-Reply-To: <6CE3E5D3-DAEE-45E7-9C16-1260BD345A46@cs.stanford.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: ROLL WG Subject: Re: [Roll] Fwd: New Version Notification for draft-levis-roll-trickle-00 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: Mon, 08 Mar 2010 22:28:28 -0000 Phil, Omprakash, and Joakim, Did you find any resolution to Trickle's load balancing problem that was discussed in this previous thread? http://www.ietf.org/mail-archive/web/roll/current/msg02707.html This is related to the concern I raised in a previous email http://www.ietf.org/mail-archive/web/roll/current/msg02723.html regarding how Trickle affects the selection of parents (or how the rules on how to defer joining a DODAG may affect Trickle's operation, point #2 I made in the email thread). I am concerned that the redundancy suppression mechanisms in Trickle will suppress the DIO advertisements of some of the potential parents of a node, and the node will end up choosing a bad parent (or bad parents). Let me illustrate with an example: ---------------------------------- Assume that "DIOs that advertise the same rank" are considered redundant, as suggested by (draft-ietf-roll-rpl-06, pg. 38, Section 5.3.5.1.1). Nodes A, B, and C are waiting to connect to the DODAG. Node A connects to the DODAG first, starts it's Trickle timer, and advertises its DIO, but C misses the message (maybe a fluke, because an 802.11 access point happened to go off nearby). After roughly I_min, Node B connects to the DAG (but node A is not a parent), starts it's Trickle timer, and advertises the same rank as A. Node B may have deferred joining the DODAG for I_min because it wanted to find a better parent. Now, node B always has a shorter interval I than node A, so it should always advertise its DIO before node A (since T is always within [I/2,I]). If the redundancy constant is set to 1, then B will always suppress A (until a packet is lost, but let's say this is uncommon). Let's say C needs to connect through the DODAG through B or A. C will choose B since C never hears A's DIO advertisements, and C will compute it's rank based on B's rank (B is C's preferred parent). But it may be that A would be a better choice for C, and should be the preferred parent for C. ---------------------------------- This may sound like a contrived example, but my point is that a low-chance event such as C missing A's first advertisement could result in C not knowing that A is present for a long time... past the time that C has to make a decision on how it connects to the DODAG (compute and advertise a rank). I think variants of this example with multiple parents could occur and cause the building of very suboptimal DODAGs. The root of the problem is that Trickle was designed for ensuring consistency, but is being applied to a situation where nodes are actually advertising different values (their rank, their metrics). It's tricky to say what should be suppressed. I'm having a hard time imagining using something besides rank or the Objective Function metric for measuring consistency. Could you guys give your thoughts on this? -- Phoebus Chen Postdoctoral Researcher Automatic Control Lab, KTH (Royal Institute of Technology) http://www.ee.kth.se/~phoebus On 2/26/10 2:20 AM, Philip Levis wrote: > Thomas and I thought it might make sense to separate Trickle out from > the RPL specification. Here's a first version of the draft: > > http://www.ietf.org/internet-drafts/draft-levis-roll-trickle-00.txt > > Phil > > Begin forwarded message: > >> *From: *IETF I-D Submission Tool > > >> *Date: *February 25, 2010 5:17:01 PM PST >> *To: *pal@cs.stanford.edu >> *Cc: *T.Clausen@computer.org >> *Subject: **New Version Notification for draft-levis-roll-trickle-00 * >> >> >> A new version of I-D, draft-levis-roll-trickle-00.txt has been >> successfuly submitted by P Levis and posted to the IETF repository. >> >> Filename: draft-levis-roll-trickle >> Revision: 00 >> Title: The Trickle Algorithm >> Creation_date: 2010-02-25 >> WG ID: Independent Submission >> Number_of_pages: 8 >> >> Abstract: >> 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. >> >> >> >> The IETF Secretariat. >> >> > From prvs=67691683a=mukul@uwm.edu Mon Mar 8 14:35: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 18FB03A68E7 for ; Mon, 8 Mar 2010 14:35:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.126 X-Spam-Level: X-Spam-Status: No, score=-2.126 tagged_above=-999 required=5 tests=[AWL=0.474, 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 52Okt3MMbdtB for ; Mon, 8 Mar 2010 14:34:54 -0800 (PST) Received: from ip2mta.uwm.edu (ip2mta.uwm.edu [129.89.7.20]) by core3.amsl.com (Postfix) with ESMTP id EEA373A69CA for ; Mon, 8 Mar 2010 14:34:53 -0800 (PST) Received: from mta02.pantherlink.uwm.edu ([129.89.7.82]) by ip2mta.uwm.edu with ESMTP; 08 Mar 2010 16:34:57 -0600 Received: from localhost (localhost.localdomain [127.0.0.1]) by mta02.pantherlink.uwm.edu (Postfix) with ESMTP id 90B702C3800D; Mon, 8 Mar 2010 16:34:57 -0600 (CST) 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 702C6w4b1EU4; Mon, 8 Mar 2010 16:34:57 -0600 (CST) Received: from mail02.pantherlink.uwm.edu (mail02.pantherlink.uwm.edu [129.89.7.86]) by mta02.pantherlink.uwm.edu (Postfix) with ESMTP id 1017E2C38012; Mon, 8 Mar 2010 16:34:57 -0600 (CST) Date: Mon, 8 Mar 2010 16:34:57 -0600 (CST) From: Mukul Goyal To: Kris Pister Message-ID: <1448174924.3318921268087696978.JavaMail.root@mail02.pantherlink.uwm.edu> In-Reply-To: <1514207108.3318341268087662937.JavaMail.root@mail02.pantherlink.uwm.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Originating-IP: [129.89.7.92] X-Mailer: Zimbra 5.0.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] P2P performance with current RPL proposal X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Mar 2010 22:35:20 -0000 We have done a performance comparison between P2P routing along a DAG versu= s shortest path routing: http://www.cs.uwm.edu/~mukul/draft-goyal-roll-p2p-performance-00.pdf These results clearly indicate that the average and the worst-case performa= nce of DAG-based P2P routing is particularly bad for source-destination pai= rs that are closeby in terms of shortest path routing. So, TTL-limited flooding to discover shortest paths to nearby destinations = definitely makes sense. =20 Thanks Mukul ----- Original Message ----- From: "Kris Pister" To: "Anders Brandt" Cc: "ROLL WG" Sent: Monday, March 8, 2010 1:44:56 PM GMT -06:00 US/Canada Central Subject: Re: [Roll] P2P performance with current RPL proposal Anders - if we take JP's suggestion to make The Lamp a DODAG root, and take= Phoebus' recommendation that we use path diversity to improve end-to-end r= eliability, do you see a chance of success?=20 In my experience, with diverse paths and order-minutes updates you get extr= emely high reliability.=20 I have no aversion to TTL-limited floods as a part of a solution either.=C2= =A0 I'm open to ideas on how to bring those in as (presumably infrequently = used) options.=20 ksjp=20 Anders Brandt wrote:=20 Hello=20 =C2=A0=20 I would like to probe the temperature of the WG on using DAOs to=20 support P2P.=20 =C2=A0=20 The building and home application spaces (and maybe others) have=20 a few clearly defined requirements.=20 It is not obvious to me how the current RPL proposal=C2=A0(cRPLp) can=20 satisfy those requirements:=20 =C2=A0=20 =C2=A0=20 In both cases it is the worst case scenario that hurts:=20 =C2=A0=20 =C2=A0=20 P2P routing inside the PAN=20 =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=20 cRPLp has no way of routing inside the PAN if you need more than=20 one repeater. cRPLp has to go all the way to the top (maybe 4 hops up)=20 and down again (maybe 4 hops down) to get just 2 hops to the side.=20 =C2=A0=20 The consequence is high latency and high levels of background noise=20 for nodes just outside the direct radio range.=20 At the same time =C2=A0the risk of meeting a failing link is 4 times higher= =3D>=20 latency may be much more than 4 times larger.=20 =C2=A0=20 Latency may sound like a minor issue but it actually translates directly=20 into lower battery lifetime. In the above (very realistic) example,=20 the battery lifetime is reduced to 25% of what it should be.=20 =C2=A0=20 We have lots of battery devices sending into the network:=20 * PIR sensors turning on lights=20 * Door locks sending alarms=20 * Door/window sensors starting chimes=20 * Smoke sensors triggering=C2=A0an alarm system=20 =C2=A0=20 =C2=A0=20 =C2=A0=20 =C2=A0=20 Response time=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=20 The latency issue is important.=20 When a user (real human being) presses a light button the user expects=20 the light to turn on.=20 cRPLp proposes that nodes in the tree periodically advertises their=20 presence using DAOs.=20 The periodicity is a real beast:=20 Thanks to Trickle, the rate of updates in a (apparently) stable network=20 is low. This is good since it leaves bandwidth for data.=20 But it is not good if existing routes to my lamp fail and I do not get=20 new routes to my lamp until it decides to send out a new DAO.=20 My user will (with a good reason) not tolerate waiting for minutes for=20 the light to turn on.=20 =C2=A0=20 I have met two arguments to counter this concern:=20 =C2=A0=20 A1: Well, your lamp can always send a DAO when it detects a problem.=20 =C2=A0=C2=A0My answer:=20 =C2=A0 True, except that my lamp does not intend to send anything=20 =C2=A0 so it will never experience any problems from its side of the networ= k.=20 =C2=A0=20 A2: Well, you can increase the DAO rate to sub-second updates.=20 =C2=A0 My answer:=20 =C2=A0 Oh no. I get a very high degree of management traffic which=20 =C2=A0 limits my available bandwidth, increases the risk of collisions and= =20 =C2=A0 even run the risk of violating EU legislation requiring me to only= =20 =C2=A0 transmit in less than 1% of the time:=20 =C2=A0 http://focus.ti.com/lit/an/swra048/swra048.pdf=20 =C2=A0 868 - 868.6 MHz: <1%=20 =C2=A0=20 =C2=A0 Reactiveness is hard to achieve via polling.=20 =C2=A0=20 =C2=A0=20 =C2=A0=20 If you agree that this seems to be critical issues please raise your=20 voice on the list.=20 =C2=A0=20 Going forward=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=20 =C2=A0=20 W e need some reactive mechanism to reach lamps before the user decides=20 to sue our compan ies.=20 So is this possible? I=C2=A0think so.=20 Existing commercial (non-IP) solutions are capable of re-routing quickly=20 if they really have to.=20 =C2=A0=20 Let me try scoping the requirements to a potential solution:=20 (no different from the req. docs for home and building)=20 =C2=A0=20 * P2P routing in any direction independent of the tree.=20 =C2=A0=20 * On-demand P2P route discovery if requested by a real-time critical app.= =20 =C2=A0 Data collection apps may be able to just wait for the next DAO updat= e.=20 =C2=A0=20 * Limited range of discovery mechanism: max 4 repeaters.=20 =C2=A0 A TTL field may limit the scope of the repeaters.=20 =C2=A0=20 * Suboptimal routing and traffic bursts are accepted in exchange=20 =C2=A0 for quick route repair. But only as an exception.=20 =C2=A0=20 =C2=A0=20 Just as an example,=C2=A0one existing home control technology=C2=A0uses a= =20 (source routing) variant of AODV for quick route repair.=20 Nothing comes for free. The price is flooding - but not just flooding:=20 Managed flooding using a distributed algorithm running in all=20 participating nodes.=20 The algorithm dampens the flooding in a time,=C2=A0volume and range perspec= tive.=20 Some similar mechanism could be built into RPL for quick route repair.=20 =C2=A0=20 =C2=A0=20 If=C2=A0 anyone have alternative proposals , please bring it to the list.= =20 Now is the time.=20 =C2=A0=20 =C2=A0=20 =C2=A0=20 Thanks,=20 =C2=A0 Anders=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 From phoebus@ieee.org Mon Mar 8 14:48: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 94ACD3A6A07 for ; Mon, 8 Mar 2010 14:48:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.249 X-Spam-Level: X-Spam-Status: No, score=-106.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OQRgSubYHodw for ; Mon, 8 Mar 2010 14:48:05 -0800 (PST) Received: from smtp-1.sys.kth.se (smtp-1.sys.kth.se [130.237.32.175]) by core3.amsl.com (Postfix) with ESMTP id 585AD3A6AA1 for ; Mon, 8 Mar 2010 14:48:01 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by smtp-1.sys.kth.se (Postfix) with ESMTP id 4CA4C156384; Mon, 8 Mar 2010 23:47:35 +0100 (CET) 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 I7zEILI5hMJD; Mon, 8 Mar 2010 23:47:32 +0100 (CET) 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-1.sys.kth.se (Postfix) with ESMTP id DC7E6155876; Mon, 8 Mar 2010 23:47:31 +0100 (CET) Message-ID: <4B957E83.8050409@ieee.org> Date: Mon, 08 Mar 2010 23:47:31 +0100 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.8) Gecko/20100227 Thunderbird/3.0.3 MIME-Version: 1.0 To: Philip Levis , "gnawali@cs.stanford.edu" , "joakime@sics.se" , ROLL WG References: <20100226011704.C9E4D28C140@core3.amsl.com> <6CE3E5D3-DAEE-45E7-9C16-1260BD345A46@cs.stanford.edu> <4B9579EB.6040604@ieee.org> In-Reply-To: <4B9579EB.6040604@ieee.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Roll] Fwd: New Version Notification for draft-levis-roll-trickle-00 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: Mon, 08 Mar 2010 22:48:06 -0000 Sorry, I just realized the last part of my example is bad... see the correction below. -- Phoebus Chen Postdoctoral Researcher Automatic Control Lab, KTH (Royal Institute of Technology) http://www.ee.kth.se/~phoebus On 3/8/10 11:27 PM, Phoebus Chen wrote: > Phil, Omprakash, and Joakim, > > Did you find any resolution to Trickle's load balancing problem that was > discussed in this previous thread? > http://www.ietf.org/mail-archive/web/roll/current/msg02707.html > > This is related to the concern I raised in a previous email > http://www.ietf.org/mail-archive/web/roll/current/msg02723.html > regarding how Trickle affects the selection of parents (or how the rules > on how to defer joining a DODAG may affect Trickle's operation, point #2 > I made in the email thread). > > I am concerned that the redundancy suppression mechanisms in Trickle > will suppress the DIO advertisements of some of the potential parents of > a node, and the node will end up choosing a bad parent (or bad parents). > > Let me illustrate with an example: > ---------------------------------- > Assume that "DIOs that advertise the same rank" are considered > redundant, as suggested by (draft-ietf-roll-rpl-06, pg. 38, Section > 5.3.5.1.1). > > Nodes A, B, and C are waiting to connect to the DODAG. Node A connects > to the DODAG first, starts it's Trickle timer, and advertises its DIO, > but C misses the message (maybe a fluke, because an 802.11 access point > happened to go off nearby). After roughly I_min, Node B connects to the > DAG (but node A is not a parent), starts it's Trickle timer, and > advertises the same rank as A. Node B may have deferred joining the > DODAG for I_min because it wanted to find a better parent. Now, node B > always has a shorter interval I than node A, so it should always > advertise its DIO before node A (since T is always within [I/2,I]). If > the redundancy constant is set to 1, then B will always suppress A > (until a packet is lost, but let's say this is uncommon). > > Let's say C needs to connect through the DODAG through B or A. C will > choose B since C never hears A's DIO advertisements, and C will compute > it's rank based on B's rank (B is C's preferred parent). But it may be > that A would be a better choice for C, and should be the preferred > parent for C. Disregard the last two sentences. Since A and B has the same rank, C wouldn't have a problem with it's rank computation, just with it's choice of parents. That's what I was concerned with. If we are using metrics for consistency checks, and the metric is computed from multiple parents (rather than the single best parent), this would also be a problem. > ---------------------------------- > > This may sound like a contrived example, but my point is that a > low-chance event such as C missing A's first advertisement could result > in C not knowing that A is present for a long time... past the time that > C has to make a decision on how it connects to the DODAG (compute and > advertise a rank). I think variants of this example with multiple > parents could occur and cause the building of very suboptimal DODAGs. > > The root of the problem is that Trickle was designed for ensuring > consistency, but is being applied to a situation where nodes are > actually advertising different values (their rank, their metrics). It's > tricky to say what should be suppressed. I'm having a hard time > imagining using something besides rank or the Objective Function metric > for measuring consistency. > > Could you guys give your thoughts on this? > From prvs=67691683a=mukul@uwm.edu Mon Mar 8 14:49: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 F3F9C3A6A07 for ; Mon, 8 Mar 2010 14:49:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.245 X-Spam-Level: X-Spam-Status: No, score=-2.245 tagged_above=-999 required=5 tests=[AWL=0.354, 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 fFMBwEwQxonS for ; Mon, 8 Mar 2010 14:49:34 -0800 (PST) Received: from ip2mta.uwm.edu (ip2mta.uwm.edu [129.89.7.20]) by core3.amsl.com (Postfix) with ESMTP id F326B3A6A01 for ; Mon, 8 Mar 2010 14:49:33 -0800 (PST) Received: from mta02.pantherlink.uwm.edu ([129.89.7.82]) by ip2mta.uwm.edu with ESMTP; 08 Mar 2010 16:49:37 -0600 Received: from localhost (localhost.localdomain [127.0.0.1]) by mta02.pantherlink.uwm.edu (Postfix) with ESMTP id E86A32C3800E; Mon, 8 Mar 2010 16:49:37 -0600 (CST) 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 fZf+1uwVZQbi; Mon, 8 Mar 2010 16:49:37 -0600 (CST) Received: from mail02.pantherlink.uwm.edu (mail02.pantherlink.uwm.edu [129.89.7.86]) by mta02.pantherlink.uwm.edu (Postfix) with ESMTP id 7E2C32C3800D; Mon, 8 Mar 2010 16:49:37 -0600 (CST) Date: Mon, 8 Mar 2010 16:49:37 -0600 (CST) From: Mukul Goyal To: Kris Pister Message-ID: <1628514371.3326981268088577465.JavaMail.root@mail02.pantherlink.uwm.edu> In-Reply-To: <1448174924.3318921268087696978.JavaMail.root@mail02.pantherlink.uwm.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Originating-IP: [129.89.7.92] X-Mailer: Zimbra 5.0.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] P2P performance with current RPL proposal X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Mar 2010 22:49:36 -0000 Working group may also want to seriously consider the possibility of modify= ing its charter to allow a distance-vector protocol with controlled floodin= g in addition to RPL. May I re-present one such protocol: http://www.cs.uwm.edu/~mukul/draft-goyal-roll-dv-01.txt Distance vector protocols are as old as the internet. So, it is not some th= ing that people dont have operational experience with. Thanks Mukul=20 ----- Original Message ----- From: "Mukul Goyal" To: "Kris Pister" Cc: "ROLL WG" Sent: Monday, March 8, 2010 4:34:57 PM GMT -06:00 US/Canada Central Subject: Re: [Roll] P2P performance with current RPL proposal We have done a performance comparison between P2P routing along a DAG versu= s shortest path routing: http://www.cs.uwm.edu/~mukul/draft-goyal-roll-p2p-performance-00.pdf These results clearly indicate that the average and the worst-case performa= nce of DAG-based P2P routing is particularly bad for source-destination pai= rs that are closeby in terms of shortest path routing. So, TTL-limited flooding to discover shortest paths to nearby destinations = definitely makes sense. =20 Thanks Mukul ----- Original Message ----- From: "Kris Pister" To: "Anders Brandt" Cc: "ROLL WG" Sent: Monday, March 8, 2010 1:44:56 PM GMT -06:00 US/Canada Central Subject: Re: [Roll] P2P performance with current RPL proposal Anders - if we take JP's suggestion to make The Lamp a DODAG root, and take= Phoebus' recommendation that we use path diversity to improve end-to-end r= eliability, do you see a chance of success?=20 In my experience, with diverse paths and order-minutes updates you get extr= emely high reliability.=20 I have no aversion to TTL-limited floods as a part of a solution either.=C2= =A0 I'm open to ideas on how to bring those in as (presumably infrequently = used) options.=20 ksjp=20 Anders Brandt wrote:=20 Hello=20 =C2=A0=20 I would like to probe the temperature of the WG on using DAOs to=20 support P2P.=20 =C2=A0=20 The building and home application spaces (and maybe others) have=20 a few clearly defined requirements.=20 It is not obvious to me how the current RPL proposal=C2=A0(cRPLp) can=20 satisfy those requirements:=20 =C2=A0=20 =C2=A0=20 In both cases it is the worst case scenario that hurts:=20 =C2=A0=20 =C2=A0=20 P2P routing inside the PAN=20 =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=20 cRPLp has no way of routing inside the PAN if you need more than=20 one repeater. cRPLp has to go all the way to the top (maybe 4 hops up)=20 and down again (maybe 4 hops down) to get just 2 hops to the side.=20 =C2=A0=20 The consequence is high latency and high levels of background noise=20 for nodes just outside the direct radio range.=20 At the same time =C2=A0the risk of meeting a failing link is 4 times higher= =3D>=20 latency may be much more than 4 times larger.=20 =C2=A0=20 Latency may sound like a minor issue but it actually translates directly=20 into lower battery lifetime. In the above (very realistic) example,=20 the battery lifetime is reduced to 25% of what it should be.=20 =C2=A0=20 We have lots of battery devices sending into the network:=20 * PIR sensors turning on lights=20 * Door locks sending alarms=20 * Door/window sensors starting chimes=20 * Smoke sensors triggering=C2=A0an alarm system=20 =C2=A0=20 =C2=A0=20 =C2=A0=20 =C2=A0=20 Response time=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=20 The latency issue is important.=20 When a user (real human being) presses a light button the user expects=20 the light to turn on.=20 cRPLp proposes that nodes in the tree periodically advertises their=20 presence using DAOs.=20 The periodicity is a real beast:=20 Thanks to Trickle, the rate of updates in a (apparently) stable network=20 is low. This is good since it leaves bandwidth for data.=20 But it is not good if existing routes to my lamp fail and I do not get=20 new routes to my lamp until it decides to send out a new DAO.=20 My user will (with a good reason) not tolerate waiting for minutes for=20 the light to turn on.=20 =C2=A0=20 I have met two arguments to counter this concern:=20 =C2=A0=20 A1: Well, your lamp can always send a DAO when it detects a problem.=20 =C2=A0=C2=A0My answer:=20 =C2=A0 True, except that my lamp does not intend to send anything=20 =C2=A0 so it will never experience any problems from its side of the networ= k.=20 =C2=A0=20 A2: Well, you can increase the DAO rate to sub-second updates.=20 =C2=A0 My answer:=20 =C2=A0 Oh no. I get a very high degree of management traffic which=20 =C2=A0 limits my available bandwidth, increases the risk of collisions and= =20 =C2=A0 even run the risk of violating EU legislation requiring me to only= =20 =C2=A0 transmit in less than 1% of the time:=20 =C2=A0 http://focus.ti.com/lit/an/swra048/swra048.pdf=20 =C2=A0 868 - 868.6 MHz: <1%=20 =C2=A0=20 =C2=A0 Reactiveness is hard to achieve via polling.=20 =C2=A0=20 =C2=A0=20 =C2=A0=20 If you agree that this seems to be critical issues please raise your=20 voice on the list.=20 =C2=A0=20 Going forward=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=20 =C2=A0=20 W e need some reactive mechanism to reach lamps before the user decides=20 to sue our compan ies.=20 So is this possible? I=C2=A0think so.=20 Existing commercial (non-IP) solutions are capable of re-routing quickly=20 if they really have to.=20 =C2=A0=20 Let me try scoping the requirements to a potential solution:=20 (no different from the req. docs for home and building)=20 =C2=A0=20 * P2P routing in any direction independent of the tree.=20 =C2=A0=20 * On-demand P2P route discovery if requested by a real-time critical app.= =20 =C2=A0 Data collection apps may be able to just wait for the next DAO updat= e.=20 =C2=A0=20 * Limited range of discovery mechanism: max 4 repeaters.=20 =C2=A0 A TTL field may limit the scope of the repeaters.=20 =C2=A0=20 * Suboptimal routing and traffic bursts are accepted in exchange=20 =C2=A0 for quick route repair. But only as an exception.=20 =C2=A0=20 =C2=A0=20 Just as an example,=C2=A0one existing home control technology=C2=A0uses a= =20 (source routing) variant of AODV for quick route repair.=20 Nothing comes for free. The price is flooding - but not just flooding:=20 Managed flooding using a distributed algorithm running in all=20 participating nodes.=20 The algorithm dampens the flooding in a time,=C2=A0volume and range perspec= tive.=20 Some similar mechanism could be built into RPL for quick route repair.=20 =C2=A0=20 =C2=A0=20 If=C2=A0 anyone have alternative proposals , please bring it to the list.= =20 Now is the time.=20 =C2=A0=20 =C2=A0=20 =C2=A0=20 Thanks,=20 =C2=A0 Anders=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 _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From tzeta.tsao@ekasystems.com Mon Mar 8 15:15: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 268693A6B82 for ; Mon, 8 Mar 2010 15:15:40 -0800 (PST) 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 Np8jnPfiOElH for ; Mon, 8 Mar 2010 15:15:35 -0800 (PST) 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 9D1793A6A9B for ; Mon, 8 Mar 2010 15:15:31 -0800 (PST) Received: (qmail 75049 invoked from network); 8 Mar 2010 23:15:33 -0000 Received: from [192.168.0.182] (tzeta.tsao@209.48.242.70 with plain) by smtp115.biz.mail.re2.yahoo.com with SMTP; 08 Mar 2010 15:15:33 -0800 PST X-Yahoo-SMTP: oSTnanOswBB7CsQprEGEdQm86hOa9bg- X-YMail-OSG: 30dJfl4VM1m3dIkjKw0a0jZS2VvpmFwA8ZTurBJK9wRe3b61Nc9QYKDpVPjzuucE1voxz50I6hewRchDCmoOxfCqPZ2S_.nN8FhkN_qJGGfYyBbckSX7DhvoRLr040TRe9qX5lQXXZAgAr__ObOn_I1yWShKdY5kmYSc1WV86lT7trKyzGkP7IHD.U7e_NJei0veqmuO_A.RCa2.SgWiz0dwxMOwsXrmNTENZv66T7i63lNaOzj4RrDUsWkxcTEXpRDGMNHNIkl_JoxwEaFtB63yNLRQ09yIl_kI5Ya1Dy0FPn3kLAyXEIbdy97DrIZw8U9tYyKWUPFKDUUC3MQKxCmOqjbfF9U7 X-Yahoo-Newman-Property: ymail-3 Message-ID: <4B958514.7030509@ekasystems.com> Date: Mon, 08 Mar 2010 18:15:32 -0500 From: Tzeta Tsao User-Agent: Mozilla-Thunderbird 2.0.0.22 (X11/20090706) MIME-Version: 1.0 To: ROLL WG Content-Type: multipart/mixed; boundary="------------000406080300010505020700" Subject: [Roll] [Fwd: New Version Notification for draft-tsao-roll-security-framework-02] X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 08 Mar 2010 23:15:40 -0000 This is a multi-part message in MIME format. --------------000406080300010505020700 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit WG, We have posted draft-tsao-roll-security-framework-02, which should be available from the repository shortly. The one major change is the addition of Section 7 that gives an analysis on RPL and so provides a basis for its security design. We appreciate your input and please comment to the list. Thanks, Tzeta --------------000406080300010505020700 Content-Type: message/rfc822; name="New Version Notification for draft-tsao-roll-security-framework-02.eml" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename*0="New Version Notification for draft-tsao-roll-securi"; filename*1="ty-framework-02.eml" X-Account-Key: account3 X-Mozilla-Keys: X-Apparently-To: tzeta.tsao@ekasystems.com via 68.142.199.179; Mon, 08 Mar 2010 15:05:08 -0800 X-YMailISG: 3OOrkUkWLDvwSTMeWQryXqqxSMThWGY7yGD10ixagMjITiNRZcABfFoR3MbvUadORpw1Z3ttQZWSMP9HuQMDtMvZbJaw0pG26hmoDpN_elqoNeZci44AHT4j673u1U_O28yT6_yMisD1dBj_wOxiIw48OrrguhsupXjT2okhJq5fkhwurGQpvqw4LgxzgzIM_G9SauEKOjrnBQo_6sOSMqXvc6H2cVji6DvuDtNd0fu3i4pd2DiSOAGELO1yso8WTzfUURGpbQ1T_sqJ6pBFP_Y34x.ZRlFK0Sf3p.zkj1EogrkDokf_cnjqddpYnqMknHZiumsuQJa.05stvLlv03HF6cl2qX7fl69Uw0OgXkbU25S1pVPv2x4xRtUb_f6OJrTG82WK0BcjLzk- X-Originating-IP: [64.170.98.32] Authentication-Results: mta113.biz.mail.re2.yahoo.com from=ietf.org; domainkeys=neutral (no sig); from=ietf.org; dkim=neutral (no sig) Received: from 64.170.98.32 (EHLO mail.ietf.org) (64.170.98.32) by mta113.biz.mail.re2.yahoo.com with SMTP; Mon, 08 Mar 2010 15:05:07 -0800 Received: by core3.amsl.com (Postfix, from userid 30) id 59EB73A69E2; Mon, 8 Mar 2010 15:05:01 -0800 (PST) From: IETF I-D Submission Tool To: tzeta.tsao@ekasystems.com Cc: roger.alexander@ekasystems.com,vanesa.daza@upf.edu,angel.lozano@upf.edu Subject: New Version Notification for draft-tsao-roll-security-framework-02 Content-Type: text/plain; charset="utf-8" Mime-Version: 1.0 Message-Id: <20100308230502.59EB73A69E2@core3.amsl.com> Date: Mon, 8 Mar 2010 15:05:02 -0800 (PST) A new version of I-D, draft-tsao-roll-security-framework-02.txt has been successfuly submitted by Tzeta Tsao and posted to the IETF repository. Filename: draft-tsao-roll-security-framework Revision: 02 Title: A Security Framework for Routing over Low Power and Lossy Networks Creation_date: 2010-03-08 WG ID: Independent Submission Number_of_pages: 41 Abstract: This document presents a security framework for routing over low power and lossy networks. The development builds upon previous work on routing security and adapts the assessments to the issues and constraints specific to low power and lossy networks. A systematic approach is used in defining and evaluating the security threats and identifying applicable countermeasures. These assessments provide the basis of the security recommendations for incorporation into low power, lossy network routing protocols. As an illustration, this framework is applied to RPL. The IETF Secretariat. --------------000406080300010505020700-- From root@core3.amsl.com Mon Mar 8 15:30: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 C6F863A69F9; Mon, 8 Mar 2010 15:30:01 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20100308233001.C6F863A69F9@core3.amsl.com> Date: Mon, 8 Mar 2010 15:30:01 -0800 (PST) Cc: roll@ietf.org Subject: [Roll] I-D Action:draft-ietf-roll-rpl-07.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Mar 2010 23:30: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 : RPL: IPv6 Routing Protocol for Low power and Lossy Networks Author(s) : T. Winter, et al. Filename : draft-ietf-roll-rpl-07.txt Pages : 82 Date : 2010-03-08 Low power and Lossy Networks (LLNs) are a class of network in which both the routers and their interconnect are constrained: LLN routers typically operate with constraints on (any subset of) processing power, memory and energy (battery), and their interconnects are characterized by (any subset of) high loss rates, low data rates and instability. LLNs are comprised of anything from a few dozen and up to thousands of LLN routers, and support point-to-point traffic (between devices inside the LLN), point-to-multipoint traffic (from a central control point to a subset of devices inside the LLN) and multipoint-to-point traffic (from devices inside the LLN towards a central control point). This document specifies the IPv6 Routing Protocol for LLNs (RPL), which provides a mechanism whereby multipoint-to-point traffic from devices inside the LLN towards a central control point, as well as point-to-multipoint traffic from the central control point to the devices inside the LLN, is supported. Support for point-to-point traffic is also available. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-roll-rpl-07.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-roll-rpl-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-03-08151945.I-D@ietf.org> --NextPart-- From geoff@proto6.com Mon Mar 8 15:40: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 5C7D03A6B86 for ; Mon, 8 Mar 2010 15:40:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.755 X-Spam-Level: X-Spam-Status: No, score=-2.755 tagged_above=-999 required=5 tests=[AWL=-0.156, 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 WLDTa4pHNmVd for ; Mon, 8 Mar 2010 15:40:51 -0800 (PST) Received: from server2.coslabs.com (server2.coslabs.com [64.111.18.234]) by core3.amsl.com (Postfix) with ESMTP id 6D98D3A63EC for ; Mon, 8 Mar 2010 15:40:51 -0800 (PST) Received: from server1.coslabs.com (unknown [199.233.92.34]) by server2.coslabs.com (Postfix) with ESMTP id 632A41812C for ; Mon, 8 Mar 2010 16:40:59 -0700 (MST) Received: from [199.233.92.20] (dev20.coslabs.com [199.233.92.20]) by server1.coslabs.com (8.13.6/8.13.6) with ESMTP id o28NetQ4011524 for ; Mon, 8 Mar 2010 16:40:55 -0700 (MST) From: Geoff Mulligan To: roll@ietf.org Content-Type: text/plain; charset="UTF-8" Date: Mon, 08 Mar 2010 16:40:51 -0700 Message-ID: <1268091651.1955.155.camel@dellx1> Mime-Version: 1.0 X-Mailer: Evolution 2.28.1 Content-Transfer-Encoding: 7bit Subject: [Roll] [Fwd: New Version Notification for draft-mulligan-roll-ripless-01] X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Mar 2010 23:40:58 -0000 I don't think my previous message about -00 made it to the list. geoff PS- I didn't spell successfully incorrectly below :-) Other spelling errors are all mine. From: IETF I-D Submission Tool To: geoff@proto6.com Subject: New Version Notification for draft-mulligan-roll-ripless-01 Date: Mon, 8 Mar 2010 15:29:52 -0800 (PST) A new version of I-D, draft-mulligan-roll-ripless-01.txt has been successfuly submitted by Geoffrey Mulligan and posted to the IETF repository. Filename: draft-mulligan-roll-ripless Revision: 01 Title: Optimized RIP for embedded RF networks Creation_date: 2010-03-08 WG ID: Independent Submission Number_of_pages: 12 Abstract: This document specifies an optimization to the Routing Information Protocol (RIP) routing protocol for use in embedded RF IPv6 internets such as those used in 6lowpan [7] networks. RIPless specifies the minimal changes to RIP, as specified in RIPng [2], RIP [3] and RIPv2 [4] to allow the protocol to be used in a "lossy" RF networks where the routing fabric of the network is built upon powered nodes and that only the edge devices may be battery powered. The IETF Secretariat. From yoav@yitran.com Mon Mar 8 18: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 E7BE43A67FD for ; Mon, 8 Mar 2010 18:52:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.412 X-Spam-Level: X-Spam-Status: No, score=-6.412 tagged_above=-999 required=5 tests=[AWL=0.186, 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 wgLH7IJYAzcd for ; Mon, 8 Mar 2010 18:52:37 -0800 (PST) Received: from na3sys009aog112.obsmtp.com (na3sys009aog112.obsmtp.com [74.125.149.207]) by core3.amsl.com (Postfix) with SMTP id 5CE953A63D3 for ; Mon, 8 Mar 2010 18:52:36 -0800 (PST) Received: from source ([74.125.82.47]) by na3sys009aob112.postini.com ([74.125.148.12]) with SMTP ID DSNKS5W3+KM9I9EF+2g1HfPPcJzoRsd9m9Bm@postini.com; Mon, 08 Mar 2010 18:52:41 PST Received: by wwb31 with SMTP id 31so2847274wwb.6 for ; Mon, 08 Mar 2010 18:52:39 -0800 (PST) From: Yoav Ben-Yehezkel References: <6D9687E95918C04A8B30A7D6DA805A3E01429F5F@zensys17.zensys.local> <006e01cabeca$691fbf80$3b5f3e80$@sturek@att.net> In-Reply-To: <006e01cabeca$691fbf80$3b5f3e80$@sturek@att.net> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acq+mBRA8djVC8wZSJSeUmM3XWRlWwAMgRfwABohR/A= Date: Tue, 9 Mar 2010 04:52:39 +0200 Received: by 10.216.179.18 with SMTP id g18mr2825064wem.52.1268103159530; Mon, 08 Mar 2010 18:52:39 -0800 (PST) Message-ID: <007601cabf33$954bf1a0$bfe3d4e0$@com> To: d.sturek@att.net, roll@ietf.org Content-Type: multipart/alternative; boundary=0016367b689e5cc48f04815546b9 Subject: Re: [Roll] P2P performance with current RPL proposal X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Mar 2010 02:52:39 -0000 --0016367b689e5cc48f04815546b9 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi, Did you consider managed flooding using bloom filters? http://www.cs.ucsb.edu/~rgilbert/pubs/GJW+06.pdf This relatively simple method basically allows a compact way of knowing whether a node is NOT N hops away from a transmitting node and also whether it is with some probability. If table entries can be integrated into DIO messages (not all of them at once, can be by layer), it will allow for better hops manageability and als= o discarding (or significantly reduced probability) to congest irrelevant zones in the network. Thanks, Yoav *From:* roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] *On Behalf Of = *Don Sturek *Sent:* Monday, March 08, 2010 4:20 PM *To:* 'Anders Brandt'; 'ROLL WG' *Subject:* Re: [Roll] P2P performance with current RPL proposal Hi Anders, First let me say +1 on your note. Agree these are the issues to solve. I was happy to see JP add a ticket. I would encourage establishment of a subgroup within the DT to address these. These points have been open for some time. The trouble with =93managed flooding=94 is that it would be the application= that would somehow have to know how many hops it needed to flood to fine the device of interest. That has been problematic in the past=85=85=85 Don *From:* roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] *On Behalf Of *Anders Brandt *Sent:* Monday, March 08, 2010 12:20 AM *To:* ROLL WG *Subject:* [Roll] P2P performance with current RPL proposal Hello I would like to probe the temperature of the WG on using DAOs to support P2P. The building and home application spaces (and maybe others) have a few clearly defined requirements. It is not obvious to me how the current RPL proposal (cRPLp) can satisfy those requirements: In both cases it is the worst case scenario that hurts: P2P routing inside the PAN =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 cRPLp has no way of routing inside the PAN if you need more than one repeater. cRPLp has to go all the way to the top (maybe 4 hops up) and down again (maybe 4 hops down) to get just 2 hops to the side. The consequence is high latency and high levels of background noise for nodes just outside the direct radio range. At the same time the risk of meeting a failing link is 4 times higher =3D> latency may be much more than 4 times larger. Latency may sound like a minor issue but it actually translates directly into lower battery lifetime. In the above (very realistic) example, the battery lifetime is reduced to 25% of what it should be. We have lots of battery devices sending into the network: * PIR sensors turning on lights * Door locks sending alarms * Door/window sensors starting chimes * Smoke sensors triggering an alarm system Response time =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D The latency issue is important. When a user (real human being) presses a light button the user expects the light to turn on. cRPLp proposes that nodes in the tree periodically advertises their presence using DAOs. The periodicity is a real beast: Thanks to Trickle, the rate of updates in a (apparently) stable network is low. This is good since it leaves bandwidth for data. But it is not good if existing routes to my lamp fail and I do not get new routes to my lamp until it decides to send out a new DAO. My user will (with a good reason) not tolerate waiting for minutes for the light to turn on. I have met two arguments to counter this concern: A1: Well, your lamp can always send a DAO when it detects a problem. My answer: True, except that my lamp does not intend to send anything so it will never experience any problems from its side of the network. A2: Well, you can increase the DAO rate to sub-second updates. My answer: Oh no. I get a very high degree of management traffic which limits my available bandwidth, increases the risk of collisions and even run the risk of violating EU legislation requiring me to only transmit in less than 1% of the time: http://focus.ti.com/lit/an/swra048/swra048.pdf 868 - 868.6 MHz: <1% Reactiveness is hard to achieve via polling. If you agree that this seems to be critical issues please raise your voice on the list. Going forward =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D We need some reactive mechanism to reach lamps before the user decides to sue our companies. So is this possible? I think so. Existing commercial (non-IP) solutions are capable of re-routing quickly if they really have to. Let me try scoping the requirements to a potential solution: (no different from the req. docs for home and building) * P2P routing in any direction independent of the tree. * On-demand P2P route discovery if requested by a real-time critical app. Data collection apps may be able to just wait for the next DAO update. * Limited range of discovery mechanism: max 4 repeaters. A TTL field may limit the scope of the repeaters. * Suboptimal routing and traffic bursts are accepted in exchange for quick route repair. But only as an exception. Just as an example, one existing home control technology uses a (source routing) variant of AODV for quick route repair. Nothing comes for free. The price is flooding - but not just flooding: Managed flooding using a distributed algorithm running in all participating nodes. The algorithm dampens the flooding in a time, volume and range perspective. Some similar mechanism could be built into RPL for quick route repair. If anyone have alternative proposals, please bring it to the list. Now is the time. Thanks, Anders --0016367b689e5cc48f04815546b9 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable

Hi,

=A0

Did you consider managed flooding using bloom filters?

http://www.cs.ucsb.edu/~rgilbert/pubs/GJW+06.pdf

=A0

This relatively simple method basically allows a compact way= of knowing whether a node is NOT N hops away from a transmitting node and also whether= it is with some probability.

If table entries can be integrated into DIO messages (not al= l of them at once, can be by layer), it will allow for better hops manageability= and also discarding (or significantly reduced probability) to congest irrelevan= t zones in the network.

=A0

Thanks,

Yoav

=A0

=A0

From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org]= On Behalf Of Don Sturek
Sent: Monday, March 08, 2010 4:20 PM
To: 'Anders Brandt'; 'ROLL WG'
Subject: Re: [Roll] P2P performance with current RPL proposal=

=A0

Hi Anders,

=A0

First let me say +1 on your note.=A0 Agree these are the issues to solve.=A0 I was happy to see JP add a ticket.=A0 I would encourage establishment of a subgroup within the DT to address these.=A0 Th= ese points have been open for some time.

=A0

The trouble with =93managed flooding=94 is that it would be = the application that would somehow have to know how many hops it needed to floo= d to fine the device of interest.=A0 That has been problematic in the past=85=85= =85

=A0

Don

=A0

=A0

From: roll-bounces@ietf.org [mailto:= roll-bounces@ietf.org] On B= ehalf Of Anders Brandt
Sent: Monday, March 08, 2010 12:20 AM
To: ROLL WG
Subject: [Roll] P2P performance with current RPL proposal

=A0

= Hello

=A0

= I would like to probe the temperature of the WG on using DAOs to

= support P2P.

=A0

= The building and home application spaces (and maybe others) have

= a few clearly defined requirements.

= It is not obvious to me how the current RPL proposal=A0(cRPLp) can

= satisfy those requirements:

=A0

=A0

= In both cases it is the worst case scenario that hurts:

=A0

=A0

= P2P routing inside the PAN

= =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

= cRPLp has no way of routing inside the PAN if you need more than

= one repeater. cRPLp has to go all the way to the top (maybe 4 hops up)

= and down again (maybe 4 hops down) to get just 2 hops to the side.

=A0

= The consequence is high latency and high levels of background noise
for nodes just outside the direct radio range.

= At the same time=A0the risk of meeting a failing link is 4 times higher =3D>

= latency may be much more than 4 times larger.

=A0

= Latency may sound like a minor issue but it actually translates directly
into lower battery lifetime. In the above (very realistic) example,<= /p>

= the battery lifetime is reduced to 25% of what it should be.

=A0

= We have lots of battery devices sending into the network:

= * PIR sensors turning on lights

= * Door locks sending alarms

= * Door/window sensors starting chimes

= * Smoke sensors triggering=A0an alarm system

= =A0

= =A0

=A0

=A0

= Response time

= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

= The latency issue is important.

= When a user (real human being) presses a light button the user expects

= the light to turn on.

= cRPLp proposes that nodes in the tree periodically advertises their

= presence using DAOs.

= The periodicity is a real beast:

= Thanks to Trickle, the rate of updates in a (apparently) stable network
is low. This is good since it leaves bandwidth for data.

= But it is not good if existing routes to my lamp fail and I do not get

= new routes to my lamp until it decides to send out a new DAO.

= My user will (with a good reason) not tolerate waiting for minutes for

= the light to turn on.

=A0

= I have met two arguments to counter this concern:

=A0

= A1: Well, your lamp can always send a DAO when it detects a problem.

= =A0=A0My answer:

= =A0 True, except that my lamp does not intend to send anything

= =A0 so it will never experience any problems from its side of the network.<= /p>

=A0

= A2: Well, you can increase the DAO rate to sub-second updates.

= =A0 My answer:

= =A0 Oh no. I get a very high deg= ree of management traffic which

= =A0 limits my available bandwidth, increases the risk of collisions and<= /p>

= =A0 even run the risk of violating EU legislation requiring me to only

= =A0 transmit in less than 1% of the time:

=A0

= =A0 Reactiveness is hard to achieve via polling.

=A0

=A0

=A0

= If you agree that this seems to be critical issues please raise your

= voice on the list.

=A0

= Going forward

= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

=A0

= We need some reactive mechanism to reach lamps before the user decides

= to sue our companies.

= So is this possible? I=A0think so.


Existing commerc= ial (non-IP) solutions are capable of re-routing quickly

= if they really have to.

=A0

= Let me try scoping the requirements to a potential solution:

= (no different from the req. docs for home and building)

=A0

= * P2P routing in any direction independent of the tree.

=A0

= * On-demand P2P route discovery if requested by a real-time critical app.
=A0 Data collection apps may be able to just wait for the next DAO update.<= /span>

=A0

= * Limited range of discovery mechanism: max 4 repeaters.

= =A0 A TTL field may limit the scope of the repeaters.

=A0

= * Suboptimal routing and traffic bursts are accepted in exchange

= =A0 for quick route repair. But only as an exception.

= =A0

=A0

= Just as an example,=A0one existing home control technology=A0uses a
(source routing) variant of AODV for quick route repair.

= Nothing comes for free. The price is flooding - but not just flooding:
Managed flooding using a distributed algorithm running in all
participating nodes.

= The algorithm dampens the flooding in a time,=A0volume and range perspective. <= /span>

= Some similar mechanism could be built into RPL for quick route repair.

=A0

=A0

= If=A0anyone have alternative proposals, please bring it to the list.

= Now is the time.

=A0

=A0

=A0

= Thanks,

= =A0 Anders

--0016367b689e5cc48f04815546b9-- From trac@tools.ietf.org Mon Mar 8 20:51: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 84E443A6846 for ; Mon, 8 Mar 2010 20:51:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.477 X-Spam-Level: X-Spam-Status: No, score=-102.477 tagged_above=-999 required=5 tests=[AWL=0.123, BAYES_00=-2.599, 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 ZYcyi9t84NhU for ; Mon, 8 Mar 2010 20:51:46 -0800 (PST) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 5F52F3A6839 for ; Mon, 8 Mar 2010 20:51:46 -0800 (PST) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1NorQ7-000551-0p; Mon, 08 Mar 2010 20:51:51 -0800 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: jpv@cisco.com X-Trac-Project: roll Date: Tue, 09 Mar 2010 04:51:50 -0000 X-URL: http://tools.ietf.org/wg/roll/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/roll/trac/ticket/25 Message-ID: <055.972e1cd4173e658bd712402411ccf5dd@tools.ietf.org> X-Trac-Ticket-ID: 25 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: 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] #25: RPL satisfying the MUST requirements 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: Tue, 09 Mar 2010 04:51:50 -0000 #25: RPL satisfying the MUST requirements --------------------------------+------------------------------------------- Reporter: jpv@… | Owner: jpv@… Type: task | Status: new Priority: major | Milestone: Component: rpl | Version: Severity: Active WG Document | Keywords: --------------------------------+------------------------------------------- The Working has produced four "application-specific" requirements documents listing a series of "MUST", SHOULD and MAY using RFC 2119 language. The object of this ticket is to track the list of MUST and make sure that RPL as specified in draft-ietf-roll-rpl meets (at least) the MUST requirements. This is currently being taken care of in the Appendix A: Appendix A. Requirements A.1. Protocol Properties Overview RPL demonstrates the following properties, consistent with the requirements specified by the application-specific requirements documents. A.1.1. IPv6 Architecture RPL is strictly compliant with layered IPv6 architecture. Winter, et al. Expires August 7, 2010 [Page 72] Internet-Draft draft-ietf-roll-rpl-06 February 2010 Further, RPL is designed with consideration to the practical support and implementation of IPv6 architecture on devices which may operate under severe resource constraints, including but not limited to memory, processing power, energy, and communication. The RPL design does not presume high quality reliable links, and operates over lossy links (usually low bandwidth with low packet delivery success rate). A.1.2. Typical LLN Traffic Patterns Multipoint-to-Point (MP2P) and Point-to-multipoint (P2MP) traffic flows from nodes within the LLN from and to egress points are very common in LLNs. Low power and lossy network Border Router (LBR) nodes may typically be at the root of such flows, although such flows are not exclusively rooted at LBRs as determined on an application- specific basis. In particular, several applications such as building or home automation do require P2P (Point-to-Point) communication. As required by the aforementioned routing requirements documents, RPL supports the installation of multiple paths. The use of multiple paths include sending duplicated traffic along diverse paths, as well as to support advanced features such as Class of Service (CoS) based routing, or simple load balancing among a set of paths (which could be useful for the LLN to spread traffic load and avoid fast energy depletion on some, e.g. battery powered, nodes). Conceptually, multiple instances of RPL can be used to send traffic along different topology instances, the construction of which is governed by different Objective Functions (OF). Details of RPL operation in support of multiple instances are beyond the scope of the present specification. A.1.3. Constraint Based Routing The RPL design supports constraint based routing, based on a set of routing metrics and constraints. The routing metrics and constraints for links and nodes with capabilities supported by RPL are specified in a companion document to this specification, [I-D.ietf-roll-routing-metrics]. RPL signals the metrics, constraints, and related Objective Functions (OFs) in use in a particular implementation by means of an Objective Code Point (OCP). Both the routing metrics, constraints, and the OF help determine the construction of the Directed Acyclic Graphs (DAG) using a distributed path computation algorithm. A.2. Deferred Requirements NOTE: RPL is still a work in progress. At this time there remain several unsatisfied application requirements, but these are to be addressed as RPL is further specified. -- Ticket URL: roll From phoebus@ieee.org Tue Mar 9 00:54: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 9E1CF3A6918 for ; Tue, 9 Mar 2010 00:54:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.249 X-Spam-Level: X-Spam-Status: No, score=-106.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZGhTrUF0lCWM for ; Tue, 9 Mar 2010 00:54:58 -0800 (PST) Received: from smtp-2.sys.kth.se (smtp-2.sys.kth.se [130.237.32.160]) by core3.amsl.com (Postfix) with ESMTP id 1AA873A6902 for ; Tue, 9 Mar 2010 00:54:58 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by smtp-2.sys.kth.se (Postfix) with ESMTP id 8A52014EFC7 for ; Tue, 9 Mar 2010 09:54:31 +0100 (CET) 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 Gf2Qwq3fHYfZ for ; Tue, 9 Mar 2010 09:54:28 +0100 (CET) X-KTH-Auth: phoebus [130.237.50.62] X-KTH-mail-from: phoebus@ieee.org X-KTH-rcpt-to: roll@ietf.org Received: from dhcp-50-62.s3.kth.se (dhcp-50-62.s3.kth.se [130.237.50.62]) by smtp-2.sys.kth.se (Postfix) with ESMTP id 2612114EE9F for ; Tue, 9 Mar 2010 09:54:27 +0100 (CET) Message-ID: <4B960CC2.7010309@ieee.org> Date: Tue, 09 Mar 2010 09:54:26 +0100 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.8) Gecko/20100227 Thunderbird/3.0.3 MIME-Version: 1.0 To: "roll@ietf.org" Content-Type: text/plain; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [Roll] Fwd: Re: Fwd: New Version Notification for draft-levis-roll-trickle-00 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, 09 Mar 2010 08:54:59 -0000 Hi everyone, I said something in my clarification below that may be misleading for the readers of this thread. In my example, C's rank would be the same whether C chose A or B as a preferred parent only if the rank increment is fixed. If, for example, the rank increment depends on the quality of the link between C and its preferred parent, then C's rank would depend on whether it chose A or B as a preferred parent. Sorry for the confusion. I'm looking forward to hearing comments on the concerns raised in this thread. -- Phoebus Chen Postdoctoral Researcher Automatic Control Lab, KTH (Royal Institute of Technology) http://www.ee.kth.se/~phoebus -------- Original Message -------- Subject: Re: [Roll] Fwd: New Version Notification for draft-levis-roll-trickle-00 Date: Mon, 8 Mar 2010 23:47:31 +0100 From: Phoebus Chen Reply-To: phoebus@ieee.org To: Philip Levis , "gnawali@cs.stanford.edu" , "joakime@sics.se" , ROLL WG Sorry, I just realized the last part of my example is bad... see the correction below. -- Phoebus Chen Postdoctoral Researcher Automatic Control Lab, KTH (Royal Institute of Technology) http://www.ee.kth.se/~phoebus On 3/8/10 11:27 PM, Phoebus Chen wrote: > Phil, Omprakash, and Joakim, > > Did you find any resolution to Trickle's load balancing problem that > was discussed in this previous thread? > http://www.ietf.org/mail-archive/web/roll/current/msg02707.html > > This is related to the concern I raised in a previous email > http://www.ietf.org/mail-archive/web/roll/current/msg02723.html > regarding how Trickle affects the selection of parents (or how the > rules on how to defer joining a DODAG may affect Trickle's > operation, point #2 I made in the email thread). > > I am concerned that the redundancy suppression mechanisms in Trickle > will suppress the DIO advertisements of some of the potential > parents of a node, and the node will end up choosing a bad parent (or > bad parents). > > Let me illustrate with an example: > ---------------------------------- Assume that "DIOs that advertise > the same rank" are considered redundant, as suggested by > (draft-ietf-roll-rpl-06, pg. 38, Section 5.3.5.1.1). > > Nodes A, B, and C are waiting to connect to the DODAG. Node A > connects to the DODAG first, starts it's Trickle timer, and > advertises its DIO, but C misses the message (maybe a fluke, because > an 802.11 access point happened to go off nearby). After roughly > I_min, Node B connects to the DAG (but node A is not a parent), > starts it's Trickle timer, and advertises the same rank as A. Node B > may have deferred joining the DODAG for I_min because it wanted to > find a better parent. Now, node B always has a shorter interval I > than node A, so it should always advertise its DIO before node A > (since T is always within [I/2,I]). If the redundancy constant is > set to 1, then B will always suppress A (until a packet is lost, but > let's say this is uncommon). > > Let's say C needs to connect through the DODAG through B or A. C > will choose B since C never hears A's DIO advertisements, and C will > compute it's rank based on B's rank (B is C's preferred parent). But > it may be that A would be a better choice for C, and should be the > preferred parent for C. Disregard the last two sentences. Since A and B has the same rank, C wouldn't have a problem with it's rank computation, just with it's choice of parents. That's what I was concerned with. If we are using metrics for consistency checks, and the metric is computed from multiple parents (rather than the single best parent), this would also be a problem. > ---------------------------------- > > This may sound like a contrived example, but my point is that a > low-chance event such as C missing A's first advertisement could > result in C not knowing that A is present for a long time... past the > time that C has to make a decision on how it connects to the DODAG > (compute and advertise a rank). I think variants of this example > with multiple parents could occur and cause the building of very > suboptimal DODAGs. > > The root of the problem is that Trickle was designed for ensuring > consistency, but is being applied to a situation where nodes are > actually advertising different values (their rank, their metrics). > It's tricky to say what should be suppressed. I'm having a hard > time imagining using something besides rank or the Objective Function > metric for measuring consistency. > > Could you guys give your thoughts on this? From richard.kelsey@ember.com Tue Mar 9 05:47: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 2A5363A6837 for ; Tue, 9 Mar 2010 05:47:53 -0800 (PST) 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 zajdkVIZIoaL for ; Tue, 9 Mar 2010 05:47:52 -0800 (PST) Received: from EMPIRE.hq.ember.com (mail.ember.com [74.10.175.227]) by core3.amsl.com (Postfix) with ESMTP id 42BB83A682F for ; Tue, 9 Mar 2010 05:47:52 -0800 (PST) Received: from kelsey-ws.hq.ember.com ([192.168.81.37]) by EMPIRE.hq.ember.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 9 Mar 2010 08:50:37 -0500 Date: Tue, 09 Mar 2010 08:31:21 -0500 Message-Id: <878wa162qe.fsf@kelsey-ws.hq.ember.com> To: phoebus@ieee.org In-reply-to: <4B9579EB.6040604@ieee.org> (message from Phoebus Chen on Mon, 08 Mar 2010 23:27:55 +0100) From: Richard Kelsey References: <20100226011704.C9E4D28C140@core3.amsl.com> <6CE3E5D3-DAEE-45E7-9C16-1260BD345A46@cs.stanford.edu> <4B9579EB.6040604@ieee.org> X-OriginalArrivalTime: 09 Mar 2010 13:50:37.0138 (UTC) FILETIME=[7F5B0320:01CABF8F] Cc: roll@ietf.org Subject: Re: [Roll] Fwd: New Version Notification for draft-levis-roll-trickle-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: Tue, 09 Mar 2010 13:47:53 -0000 > Date: Mon, 08 Mar 2010 23:27:55 +0100 > From: Phoebus Chen > > I am concerned that the redundancy suppression mechanisms in Trickle > will suppress the DIO advertisements of some of the potential parents of > a node, and the node will end up choosing a bad parent (or bad parents). > > [example elided] > > The root of the problem is that Trickle was designed for ensuring > consistency, but is being applied to a situation where nodes are > actually advertising different values (their rank, their metrics). It's > tricky to say what should be suppressed. I'm having a hard time > imagining using something besides rank or the Objective Function metric > for measuring consistency. Phoebus, There was an earlier dicussion of this on the roll list. See, for example, http://www.ietf.org/mail-archive/web/roll/current/msg01381.html The thread was a discussion mostly between Jonathan and myself about the redundancy counter and whether DIOs should be suppressed. In the end the agreement was that "it depends". The value of DIO suppression varies in different use cases, making it a requirement in some and unimportant in others. In the current draft the DIORedundancyConstant is settable on a per-DODAG basis. For those cases where the benefit of more reliable DIO information outweighs the cost of sending more of them, setting DIORedundancyConstant to 0xFF disables the DIO suppression mechanism entirely. -Richard Kelsey From phoebus@ieee.org Tue Mar 9 06:46: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 A223C3A68C1 for ; Tue, 9 Mar 2010 06:46:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.249 X-Spam-Level: X-Spam-Status: No, score=-106.249 tagged_above=-999 required=5 tests=[AWL=-0.000, 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 0Tct0NGT40uA for ; Tue, 9 Mar 2010 06:46:35 -0800 (PST) Received: from smtp-2.sys.kth.se (smtp-2.sys.kth.se [130.237.32.160]) by core3.amsl.com (Postfix) with ESMTP id D2FFB3A68B5 for ; Tue, 9 Mar 2010 06:46:34 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by smtp-2.sys.kth.se (Postfix) with ESMTP id 3FDE614D747; Tue, 9 Mar 2010 15:46:08 +0100 (CET) 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 g4lDq1zzaORI; Tue, 9 Mar 2010 15:46:05 +0100 (CET) X-KTH-Auth: phoebus [130.237.50.62] X-KTH-mail-from: phoebus@ieee.org Received: from dhcp-50-62.s3.kth.se (dhcp-50-62.s3.kth.se [130.237.50.62]) by smtp-2.sys.kth.se (Postfix) with ESMTP id D80B614C223; Tue, 9 Mar 2010 15:46:03 +0100 (CET) Message-ID: <4B965F2B.1090206@ieee.org> Date: Tue, 09 Mar 2010 15:46:03 +0100 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.8) Gecko/20100227 Thunderbird/3.0.3 MIME-Version: 1.0 To: Richard Kelsey References: <20100226011704.C9E4D28C140@core3.amsl.com> <6CE3E5D3-DAEE-45E7-9C16-1260BD345A46@cs.stanford.edu> <4B9579EB.6040604@ieee.org> <878wa162qe.fsf@kelsey-ws.hq.ember.com> In-Reply-To: <878wa162qe.fsf@kelsey-ws.hq.ember.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "roll@ietf.org" Subject: Re: [Roll] Fwd: New Version Notification for draft-levis-roll-trickle-00 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, 09 Mar 2010 14:46:36 -0000 Richard, Thanks for bringing up that very relevant discussion thread... I had forgotten about it. I guess this issue is partially resolved by falling back to disabling the suppression mechanism. I was hoping that something more clever could be done by modifying Trickle's mechanisms, as Joakim, Phil, and Omprakash seemed to have been doing. And maybe by redefining the consistency check. I don't have any good suggestions regarding this right now, so I was probing the list for the current status on this issue. Thanks for your response. Phoebus On 3/9/10 2:31 PM, Richard Kelsey wrote: >> Date: Mon, 08 Mar 2010 23:27:55 +0100 >> From: Phoebus Chen >> >> I am concerned that the redundancy suppression mechanisms in Trickle >> will suppress the DIO advertisements of some of the potential parents of >> a node, and the node will end up choosing a bad parent (or bad parents). >> >> [example elided] >> >> The root of the problem is that Trickle was designed for ensuring >> consistency, but is being applied to a situation where nodes are >> actually advertising different values (their rank, their metrics). It's >> tricky to say what should be suppressed. I'm having a hard time >> imagining using something besides rank or the Objective Function metric >> for measuring consistency. > > Phoebus, > > There was an earlier dicussion of this on the roll list. > See, for example, > > http://www.ietf.org/mail-archive/web/roll/current/msg01381.html > > The thread was a discussion mostly between Jonathan and > myself about the redundancy counter and whether DIOs should > be suppressed. In the end the agreement was that "it > depends". The value of DIO suppression varies in different > use cases, making it a requirement in some and unimportant > in others. > > In the current draft the DIORedundancyConstant is settable > on a per-DODAG basis. For those cases where the benefit of > more reliable DIO information outweighs the cost of sending > more of them, setting DIORedundancyConstant to 0xFF disables > the DIO suppression mechanism entirely. > > -Richard Kelsey -- Phoebus Chen Postdoctoral Researcher Automatic Control Lab, KTH (Royal Institute of Technology) http://www.ee.kth.se/~phoebus From wintert@acm.org Tue Mar 9 06:52: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 AE4433A68B5 for ; Tue, 9 Mar 2010 06:52:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.668 X-Spam-Level: X-Spam-Status: No, score=-101.668 tagged_above=-999 required=5 tests=[AWL=0.929, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3ZXGOOUnemfl for ; Tue, 9 Mar 2010 06:52:12 -0800 (PST) Received: from smtp108.prem.mail.ac4.yahoo.com (smtp108.prem.mail.ac4.yahoo.com [76.13.13.47]) by core3.amsl.com (Postfix) with SMTP id A52F93A6830 for ; Tue, 9 Mar 2010 06:52:11 -0800 (PST) Received: (qmail 80677 invoked from network); 9 Mar 2010 14:52:11 -0000 Received: from 206-83-249-194.edurostream.com (wintert@206.83.249.194 with plain) by smtp108.prem.mail.ac4.yahoo.com with SMTP; 09 Mar 2010 06:52:11 -0800 PST X-Yahoo-SMTP: 30iEHGKswBCbca_Y5pX7d6RVQMoT5Mk- X-YMail-OSG: y7yqzjwVM1l53K2f6N3nf9dkwQVAtTdey_yGLCvQciTs4V4819xmeHYSEkOzxyz9xkpTi2DpqL7FQ8CYqh5S61dIievtJO6u8ocNFGOKNcF7fhCHjRdNKwiF9888.5m1sH8vVtQmTCCKZd_CFTdIebqY4itbZVvri1tW6m2gVSpkXvRE4RH77EKee.D_ZT4Jv6qV5ldKi6IN_3HNiLTS26SiDo_VfOvB9aG0lMixwpPjemHrBdTAvVVJMYYDSkE647fMtw7e6d.5KV.PtglDfwVSbAgUr.8nXWGiKAbzbCHKQXeOskLAOKYV X-Yahoo-Newman-Property: ymail-3 Message-ID: <4B966090.9050208@acm.org> Date: Tue, 09 Mar 2010 09:52:00 -0500 From: Tim Winter User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: ROLL WG References: <20100308233001.C6F863A69F9@core3.amsl.com> In-Reply-To: <20100308233001.C6F863A69F9@core3.amsl.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Roll] I-D Action:draft-ietf-roll-rpl-07.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Mar 2010 14:52:13 -0000 WG, In this version there is a significant update to the Examples in Appendix B to illustrate the operation of the proposed DAO mechanism. Some additional description of the control fields for DAO operation ('T', 'S', and DTSN) is added to Section 6. Many other small editorial changes are incorporated in response to feedback from -06 as well. Please especially review and provide your feedback on the proposal for provisioning downward routes described in Section 6. Thanks, - RPL Author Team Internet-Drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Routing Over Low power and Lossy networks Working Group of the IETF. > > > Title : RPL: IPv6 Routing Protocol for Low power and Lossy Networks > Author(s) : T. Winter, et al. > Filename : draft-ietf-roll-rpl-07.txt > Pages : 82 > Date : 2010-03-08 > > Low power and Lossy Networks (LLNs) are a class of network in which > both the routers and their interconnect are constrained: LLN routers > typically operate with constraints on (any subset of) processing > power, memory and energy (battery), and their interconnects are > characterized by (any subset of) high loss rates, low data rates and > instability. LLNs are comprised of anything from a few dozen and up > to thousands of LLN routers, and support point-to-point traffic > (between devices inside the LLN), point-to-multipoint traffic (from a > central control point to a subset of devices inside the LLN) and > multipoint-to-point traffic (from devices inside the LLN towards a > central control point). This document specifies the IPv6 Routing > Protocol for LLNs (RPL), which provides a mechanism whereby > multipoint-to-point traffic from devices inside the LLN towards a > central control point, as well as point-to-multipoint traffic from > the central control point to the devices inside the LLN, is > supported. Support for point-to-point traffic is also available. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-roll-rpl-07.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > > > ------------------------------------------------------------------------ > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From wintert@acm.org Tue Mar 9 07:23: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 DB5263A690D for ; Tue, 9 Mar 2010 07:23:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.133 X-Spam-Level: X-Spam-Status: No, score=-102.133 tagged_above=-999 required=5 tests=[AWL=0.465, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kOgNKdPwAusY for ; Tue, 9 Mar 2010 07:23:47 -0800 (PST) Received: from smtp110.prem.mail.ac4.yahoo.com (smtp110.prem.mail.ac4.yahoo.com [76.13.13.93]) by core3.amsl.com (Postfix) with SMTP id 8EBEB3A6983 for ; Tue, 9 Mar 2010 07:23:45 -0800 (PST) Received: (qmail 41760 invoked from network); 9 Mar 2010 15:23:48 -0000 Received: from 206-83-249-194.edurostream.com (wintert@206.83.249.194 with plain) by smtp110.prem.mail.ac4.yahoo.com with SMTP; 09 Mar 2010 07:23:47 -0800 PST X-Yahoo-SMTP: 30iEHGKswBCbca_Y5pX7d6RVQMoT5Mk- X-YMail-OSG: yCOC7kAVM1nn3b05z9C_z57_gjM4UGaDydjyWWLnZyJVVfA01e_6.nkdUPJITpCB_8ysrffVvdkGD04lD03rqfr6o6LKFOWVpUuRbmdWkZPs6uo94.N.0TWhTUQ03GsKfv7IjJmialIFK8zI.IQS7_3yMkgjbto8oPal3mbFpRVFgexN3pBxpzrl.I7Po3ICHlNEBAJkfDmOn6swVg_IpFVK.ZmBUDl6e2iDAGPqPLS8Vi8Q5zmHA0wuGQXewjN34WcgrrinF9ag0yAxi7IL724UVxmjuJ1dMuSG13dfQMGbkGu8f9gm3g-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4B966803.5090703@acm.org> Date: Tue, 09 Mar 2010 10:23:47 -0500 From: Tim Winter User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: ROLL WG Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [Roll] 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, 09 Mar 2010 15:23:49 -0000 WG, 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 From mcr@sandelman.ca Tue Mar 9 07:46: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 591E33A687A for ; Tue, 9 Mar 2010 07:46:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.295 X-Spam-Level: X-Spam-Status: No, score=-0.295 tagged_above=-999 required=5 tests=[AWL=1.659, BAYES_00=-2.599, 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 R1uyX6ehWjbp for ; Tue, 9 Mar 2010 07:46:12 -0800 (PST) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by core3.amsl.com (Postfix) with ESMTP id 40EF73A692D for ; Tue, 9 Mar 2010 07:46:12 -0800 (PST) Received: from sandelman.ottawa.on.ca (unknown [132.213.238.4]) by relay.sandelman.ca (Postfix) with ESMTPS id C6CD034779 for ; Tue, 9 Mar 2010 10:42:12 -0500 (EST) Received: from marajade.sandelman.ca (unknown [127.0.0.1]) by sandelman.ottawa.on.ca (Postfix) with ESMTP id 958ED4E78C for ; Tue, 9 Mar 2010 10:46:15 -0500 (EST) From: Michael Richardson To: ROLL WG In-Reply-To: <4B966803.5090703@acm.org> References: <4B966803.5090703@acm.org> X-Mailer: MH-E 8.1; nmh 1.1; XEmacs 21.4 (patch 21) Date: Tue, 09 Mar 2010 10:46:15 -0500 Message-ID: <10001.1268149575@marajade.sandelman.ca> Sender: mcr@sandelman.ca Subject: Re: [Roll] 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, 09 Mar 2010 15:46:13 -0000 >>>>> "Tim" == Tim Winter writes: Tim> It has been noted that operation in the case where all nodes Tim> (except possibly the root) are non-storing nodes allows for Tim> certain optimizations, and that the case where all nodes Tim> (except possibly leaves) are storing leads to other Tim> optimizations. It has also been noted that in the mixed cases Tim> the ability to provide an optimal solution may break down. In Tim> particular there are concerns about the complexity and Tim> correctness of mixed-mode operation as proposed by RPL-07. To summarize my understanding: root nodes always have to store leaf nodes never have to store it is intermediate nodes that in question Tim> With this in mind, should RPL allow for operation in a mixture Tim> of storing/non-storing nodes? Or should each RPL Instance be Tim> exclusively operating in either storing or non-storing mode Tim> (with the provision that operation as a leaf is always an Tim> option)? (The non-mixed case may imply some control flag or Tim> equivalent given in the DIO to signal the mode of operation). I note that intermediate nodes that can store should clearly be able to operate in non-storing mode. I am favour of the RPL Instance being exclusively storing or non-storing. This significantly reduces the testing complexity. I also suggest that non-storing operation be a MUST and storing operating be a MAY. If one comes to assemble a bunch of equipement from different vendors, it would be acceptable to discovery that they can interoperate in a given physical configuration only in non-storing mode. (A different physical configuration might well permit all of the non-storing only nodes to be leaves) -- ] 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 phoebus@ieee.org Tue Mar 9 07:48: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 3F68F3A6830 for ; Tue, 9 Mar 2010 07:48:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.249 X-Spam-Level: X-Spam-Status: No, score=-106.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VFv6qgkzZh1P for ; Tue, 9 Mar 2010 07:48:46 -0800 (PST) Received: from smtp-2.sys.kth.se (smtp-2.sys.kth.se [130.237.32.160]) by core3.amsl.com (Postfix) with ESMTP id 3D3553A687A for ; Tue, 9 Mar 2010 07:48:46 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by smtp-2.sys.kth.se (Postfix) with ESMTP id 8841A14EF10 for ; Tue, 9 Mar 2010 16:48:20 +0100 (CET) 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 Y4u3RE7LAiDf for ; Tue, 9 Mar 2010 16:48:19 +0100 (CET) X-KTH-Auth: phoebus [130.237.50.62] X-KTH-mail-from: phoebus@ieee.org X-KTH-rcpt-to: roll@ietf.org Received: from dhcp-50-62.s3.kth.se (dhcp-50-62.s3.kth.se [130.237.50.62]) by smtp-2.sys.kth.se (Postfix) with ESMTP id F325C14EF7A for ; Tue, 9 Mar 2010 16:48:18 +0100 (CET) Message-ID: <4B966DC2.7030407@ieee.org> Date: Tue, 09 Mar 2010 16:48:18 +0100 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.8) Gecko/20100227 Thunderbird/3.0.3 MIME-Version: 1.0 To: "roll@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [Roll] Routing Metrics spec v4: Clarifying how metrics are computed or aggregated in RPL 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, 09 Mar 2010 15:48:52 -0000 Dear Authors of RPL Routing Metrics Document, I finished reading draft-ietf-roll-routing-metrics-04 and found it very informative. I liked the classification of metrics by characteristics on pg. 5. (By the way, should "local versus global" be placed in the list?) One characteristic shared by all the metrics used by RPL is that they all must be computable and optimizable using one pass outward from the destination (root) to the source (nodes in the network). This should be mentioned in the document to put the reader into the right frame of reference. What types of metrics would not fit this description? Well, a metric that measures the amount of leftover upwards bandwidth available at a node after it has been allocated to forwarding the packets of the node's children. This type of metric might be useful for load balancing a network... for a node to signal to other nodes through its metric whether too many other children have already joined. But this type of metric should not be allowed if you wish for the metric to track the rank, since the rank should not change (too much) within a DODAG iteration. I'm referring to (draft-ietf-roll-rpl-07, pg. 60, Sec. 10): "To keep loop avoidance and metric optimization in alignment, the increase in rank should reflect any increase in the metric value." I recall an earlier discussion in the mailing list that OFs may combine several different types of metrics (throughput, latency, delay) to compute a node's own metric. This might be done by taking a weighted linear combination of the various metrics, or by other means. Is this the purpose of the TLVs in (draft-ietf-roll-routing-metrics-04, pg. 24, Fig. 19)? As I understand, such metrics specific to an Objective Function do not deserve their own object format. The metrics in Sections 3 and 4, such as Node Energy and ETX, are expected to be used by several objective functions, and hence are given their own object formats. Is that correct? In (draft-ietf-roll-routing-metrics-04, pg. 7, Fig. 2), there is an A field indicating how a node or link metric is aggregated. I thought the objective function decides how to aggregate the metric. Is the A field placed here instead of in the TLVs for the OCP to save space? Does it make sense to make A=0x03 represent "other," telling the node to look at the TLVs for the OCP to specify how to aggregate the metric? For instance the metric computed from an OCP might be a polynomial function of the metrics a node has heard from the neighbors. -- Phoebus Chen Postdoctoral Researcher Automatic Control Lab, KTH (Royal Institute of Technology) http://www.ee.kth.se/~phoebus From trac@tools.ietf.org Tue Mar 9 07:49: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 654463A691A for ; Tue, 9 Mar 2010 07:49:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.482 X-Spam-Level: X-Spam-Status: No, score=-102.482 tagged_above=-999 required=5 tests=[AWL=0.118, BAYES_00=-2.599, 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 WvsiW8F1JuG0 for ; Tue, 9 Mar 2010 07:49:02 -0800 (PST) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 55B943A6830 for ; Tue, 9 Mar 2010 07:49:01 -0800 (PST) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1Np1g8-0002jY-3n; Tue, 09 Mar 2010 07:49:04 -0800 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: wintert@acm.org, jpv@cisco.com X-Trac-Project: roll Date: Tue, 09 Mar 2010 15:49:04 -0000 X-URL: http://tools.ietf.org/wg/roll/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/roll/trac/ticket/26 Message-ID: <055.de2b44186f7f768ae4dcb71da1e0a0b0@tools.ietf.org> X-Trac-Ticket-ID: 26 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: wintert@acm.org, 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] #26: Establishing downward routes in RPL : storing / non-storing / mixed modes of operation 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: Tue, 09 Mar 2010 15:49:03 -0000 #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. -- Ticket URL: roll From d.sturek@att.net Tue Mar 9 08: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 AA8F43A6967 for ; Tue, 9 Mar 2010 08:00:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.815 X-Spam-Level: X-Spam-Status: No, score=-0.815 tagged_above=-999 required=5 tests=[AWL=0.001, 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 ubpvksmBRT43 for ; Tue, 9 Mar 2010 08:00:03 -0800 (PST) Received: from smtp102.sbc.mail.gq1.yahoo.com (smtp102.sbc.mail.gq1.yahoo.com [67.195.15.61]) by core3.amsl.com (Postfix) with SMTP id CD9553A68BC for ; Tue, 9 Mar 2010 08:00:03 -0800 (PST) Received: (qmail 18162 invoked from network); 9 Mar 2010 16:00:05 -0000 Received: from adsl-69-108-51-105.dsl.sndg02.pacbell.net (d.sturek@69.108.51.105 with login) by smtp102.sbc.mail.gq1.yahoo.com with SMTP; 09 Mar 2010 08:00:05 -0800 PST X-Yahoo-SMTP: fvjol_aswBAraSJvMLe2r1XTzhBhbFxY8q8c3jo- X-YMail-OSG: yQz5C2IVM1mWNHFVHPRYvUizOovF6U5q.StPSNqCjidCmP79JnHkg.APUzAQgLtf5aE7CYp9rYDE38Cc.6YUq7Wseq4szqeYVuFCJ6Ta3L9NxrOQ1AprNyxka6_.UgCgsbuCUjLb2X_QiptsbpvnDNZijpZ7QYmu5BnGTJBaZBSf7P8MrzCI_6md9BmO8rVW6Pd.ENCEauMHKM0Y6XGnr2hQVNqNIamfALq1NOLFTUqsDkODelrxYVEBCoNlYW09iV42M54Nw4yltQxdA10zmuwpAFtJ43n8Enx0Hz4GfQDnY0p2AcI- X-Yahoo-Newman-Property: ymail-3 From: "Don Sturek" To: "'Tim Winter'" , "'ROLL WG'" References: <4B966803.5090703@acm.org> In-Reply-To: <4B966803.5090703@acm.org> Date: Tue, 9 Mar 2010 08:00:03 -0800 Message-ID: <015401cabfa1$95106540$bf312fc0$@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: Acq/nIiJgUlYvs2HRwWt7xB1/27B/wABBwPw Content-Language: en-us Subject: Re: [Roll] 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: Tue, 09 Mar 2010 16:00:05 -0000 Hi Tim, I would be in favor of operating ROLL RPL as either all storing or all non-storing. However, I have the following concerns around this: 1) Obviously, the choice would be a deployment concern if either storing MAY be supported or non-storing MAY be supported, however, this would only work in a closed system. Introducing a non-storing device in a network of all storing devices would not allow downward routing. Introducing a storing device in a network of all non-storing devices would only work if you MUST use source routing (an odd feature selection for a storing device that expects others in its network to be storing devices) 2) The suggestion to make non-storing MUST and storing MAY drags in source routing as a MUST. There are instances where source routing won't work (DAGs with sufficient depth where the source routing header frame exceeds a 6LowPAN single fragment according to the 6LowPAN reflector, for example.....). It would be a shame to have source routing as a MUST in deployments where source routing does not even work for the application profile. Don -----Original Message----- From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Tim Winter Sent: Tuesday, March 09, 2010 7:24 AM To: ROLL WG Subject: [Roll] Establishing downward routes in RPL : storing / non-storing / mixed modes of operation WG, 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 _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From anders.jagd@gmail.com Tue Mar 9 08: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 E09693A6919 for ; Tue, 9 Mar 2010 08:18:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nEfyHcUolt0k for ; Tue, 9 Mar 2010 08:18:32 -0800 (PST) Received: from mail-qy0-f197.google.com (mail-qy0-f197.google.com [209.85.221.197]) by core3.amsl.com (Postfix) with ESMTP id 49DD23A6917 for ; Tue, 9 Mar 2010 08:18:31 -0800 (PST) Received: by qyk35 with SMTP id 35so5440582qyk.18 for ; Tue, 09 Mar 2010 08:18:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=N2Fxdj8Wox9k32JLMG6Em1MvwRiDVxtX/cSOpePDQXE=; b=ZxIl9dEfUXVpmDNEN7JHdL4Ju8nZkQgnV9AT/9BdGJt/gpHs3llZAfN5XMjri4iuxS K50KA36AyatpZstwvy6mqEdt/YbSmrwm9uOt+TyJG8xS+QoBBdnpYrQ/hDbEETVC0+wB T5kDUquy7Rn1KBFx5cjihhaOC5bO0AXbIcNU0= 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=Cxa/2nzkO8dOeL/pb9rtIn3AwuF2c83OYPEITl9GmawZGGbJE55tY7iHUAlsxQK4F/ ICBtYhDhDf/7+nJLwTc0dYl88ry3W6RI0cWD/zX8UMSU7dlk/KOz4YU4qTSNrS8lQgIL KwOkg/9BZNCeTcyn6BaT6yOiMWGxO26Y5vR7M= MIME-Version: 1.0 Received: by 10.224.43.133 with SMTP id w5mr849256qae.326.1268151513353; Tue, 09 Mar 2010 08:18:33 -0800 (PST) In-Reply-To: <4B966803.5090703@acm.org> References: <4B966803.5090703@acm.org> Date: Tue, 9 Mar 2010 11:18:33 -0500 Message-ID: <77b524e41003090818t658cb324x226acd8a31b57758@mail.gmail.com> From: Anders Jagd To: Tim Winter Content-Type: multipart/alternative; boundary=00c09f97286179906c04816088f4 Cc: ROLL WG Subject: Re: [Roll] 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, 09 Mar 2010 16:18:34 -0000 --00c09f97286179906c04816088f4 Content-Type: text/plain; charset=ISO-8859-1 Tim, I don't see that we would benefit from going as far as generally dis-allowing a mix of storing/non-storing. Granted, most networks would likely in practice be either storing on non-storing. However, I am not convinced there would not be use cases justifying a mix. Rather than tying our hands on this, would it not be better to have each OF set rules/requirements for nodes to be "all storing", "all non-storing", or "mix" ? I actually don't think we are able to properly answer questions like this properly before applicability work has been done - which is the main reason I don't think we should go so far as to dis-allow a mix quite yet. /Anders On Tue, Mar 9, 2010 at 10:23 AM, Tim Winter wrote: > WG, > > 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 > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > --00c09f97286179906c04816088f4 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Tim,

I don't see that we would benefit from going as= far as generally dis-allowing a mix of storing/non-storing.=A0Granted, mos= t networks would likely in practice be either storing on non-storing. Howev= er, I am not convinced there would not be use cases justifying a mix.

Rather than tying our hands on this, would it not be be= tter to have each OF set rules/requirements for nodes to be "all stori= ng", "all non-storing", or "mix" ?

I actually don't think we are able to properly answer questi= ons like this properly before applicability work has been done - which is t= he main reason I don't think we should go so far as to dis-allow a mix = quite yet.

/Anders

On Tue, Mar 9= , 2010 at 10:23 AM, Tim Winter <wintert@acm.org> wrote:
WG,

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. =A0The present proposal describes operation in= a mixed
mode operation, with both storing and non-storing nodes, where each node ma= y
provision downward routing state as according to its capabilities and large= ly
independent of its position in the LLN topology.

It has been noted that operation in the case where all nodes (except possib= ly 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= . =A0It has
also been noted that in the mixed cases the ability to provide an optimal s= olution
may break down. =A0In particular there are concerns about the complexity an= d
correctness of mixed-mode operation as proposed by RPL-07.

With this in mind, should RPL allow for operation in a mixture of storing/n= on-storing
nodes? =A0Or should each RPL Instance be exclusively operating in either st= oring 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
_______________________________________________
Roll mailing list
Roll@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/roll

--00c09f97286179906c04816088f4-- From jhui@archrock.com Tue Mar 9 08:23: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 C23AC3A6917 for ; Tue, 9 Mar 2010 08:23:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.219 X-Spam-Level: X-Spam-Status: No, score=-1.219 tagged_above=-999 required=5 tests=[AWL=-0.920, BAYES_00=-2.599, MANGLED_TOOL=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 FgKdAOz1DCBu for ; Tue, 9 Mar 2010 08:23:33 -0800 (PST) Received: from mail.sf.archrock.com (mail.sf.archrock.com [216.121.16.71]) by core3.amsl.com (Postfix) with ESMTP id 2B7083A68E9 for ; Tue, 9 Mar 2010 08:23:33 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.sf.archrock.com (Postfix) with ESMTP id A4E3AAF914; Tue, 9 Mar 2010 08:23:37 -0800 (PST) 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 z-HHGRB5usUf; Tue, 9 Mar 2010 08:23:33 -0800 (PST) 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 97D62AF918; Tue, 9 Mar 2010 08:23:33 -0800 (PST) Message-Id: From: Jonathan Hui To: Tim Winter In-Reply-To: <4B966803.5090703@acm.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: Tue, 9 Mar 2010 08:23:32 -0800 References: <4B966803.5090703@acm.org> X-Mailer: Apple Mail (2.936) Cc: ROLL WG Subject: Re: [Roll] 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, 09 Mar 2010 16:23:35 -0000 To reiterate some of my messages in the past, I have been against mixing of storing and non-storing nodes. To indicate why, let me highlight some of the issues. Supporting mixed mode operation effectively is a problem of managing distributed state. What makes this problem difficult in mixed-mode networks is the difficulty in tracking where state is being stored and keeping that state up-to-date, since only select nodes are storing such state. Specifically in RPL, it requires knowing which ancestor particular DAO state is being maintained and sending DAO messages at appropriate times when the ancestor changes. In the fully storing case, the ancestor is simply the parent and easy to detect. In the fully non-storing case, the ancestor is always the root, so again a node only needs to send updates if its immediate parent changes. In a mixed mode case, ideally the node would know which node is storing its DAO information (it may not be the immediate parent or even the first storing node) when that node changes. The existing RPL draft punts on this problem because we haven't come up with a good simple solution. Early drafts specified that if a non- storing node is triggered to send DAOs (e.g. due to a single link failure), it must trigger DAOs from its descendants as well. This can lead to O(N) messages due to a single link failure. The 'S' bit helped to optimized for the fully non-storing case by indicating if there is a storing node that is not the root, reducing to O(1) for a single link failure. But doesn't help much in mixed-mode environments where the true worst-case is still O(N). To maintain some kind of interoperability, I would say that every node MUST at least be able to operate in leaf mode, regardless of whether it supports only storing or only non-storing. -- Jonathan Hui On Mar 9, 2010, at 7:23 AM, Tim Winter wrote: > WG, > > 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 > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From mcr@sandelman.ca Tue Mar 9 08:50: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 E7E6D3A68F5 for ; Tue, 9 Mar 2010 08:50:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.491 X-Spam-Level: X-Spam-Status: No, score=-1.491 tagged_above=-999 required=5 tests=[AWL=0.463, BAYES_00=-2.599, 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 UWFoIfadCzfX for ; Tue, 9 Mar 2010 08:50:10 -0800 (PST) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by core3.amsl.com (Postfix) with ESMTP id 67E773A68B9 for ; Tue, 9 Mar 2010 08:50:10 -0800 (PST) Received: from sandelman.ottawa.on.ca (unknown [132.213.238.4]) by relay.sandelman.ca (Postfix) with ESMTPS id C39243479C; Tue, 9 Mar 2010 11:46:11 -0500 (EST) Received: from marajade.sandelman.ca (unknown [127.0.0.1]) by sandelman.ottawa.on.ca (Postfix) with ESMTP id 4F9084E78D; Tue, 9 Mar 2010 11:50:14 -0500 (EST) From: Michael Richardson To: Anders Jagd In-Reply-To: <77b524e41003090818t658cb324x226acd8a31b57758@mail.gmail.com> References: <4B966803.5090703@acm.org> <77b524e41003090818t658cb324x226acd8a31b57758@mail.gmail.com> X-Mailer: MH-E 8.1; nmh 1.1; XEmacs 21.4 (patch 21) Date: Tue, 09 Mar 2010 11:50:14 -0500 Message-ID: <14058.1268153414@marajade.sandelman.ca> Sender: mcr@sandelman.ca Cc: ROLL WG Subject: Re: [Roll] 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, 09 Mar 2010 16:50:14 -0000 >>>>> "Anders" == Anders Jagd writes: Anders> I don't see that we would benefit from going as far as Anders> generally dis-allowing a mix of Anders> storing/non-storing. Granted, most networks would likely in Anders> practice be either storing on non-storing. However, I am not Anders> convinced there would not be use cases justifying a mix. The amount of testing you need to do goes up considerably when you have some nodes that can store and some that do not. If we later find a use for a mixed network, it is much easier to relax a rule when we iterate from Proposed Standard (step1 RFC) to Draft Standard (step2 RFC) than it is to tighten up a rule and make some implementations non-compliant. -- ] 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 jhui@archrock.com Tue Mar 9 08:50: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 81A9F3A67E4 for ; Tue, 9 Mar 2010 08:50:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.216 X-Spam-Level: X-Spam-Status: No, score=-2.216 tagged_above=-999 required=5 tests=[AWL=0.383, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YvJuRgaHrML1 for ; Tue, 9 Mar 2010 08:50:16 -0800 (PST) Received: from mail.sf.archrock.com (mail.sf.archrock.com [216.121.16.71]) by core3.amsl.com (Postfix) with ESMTP id 11E613A68B9 for ; Tue, 9 Mar 2010 08:50:14 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.sf.archrock.com (Postfix) with ESMTP id 8D34CAF916; Tue, 9 Mar 2010 08:50:18 -0800 (PST) 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 HEdKQonA2XZ3; Tue, 9 Mar 2010 08:50:14 -0800 (PST) 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 B321DAF845; Tue, 9 Mar 2010 08:50:13 -0800 (PST) Message-Id: <0426FE54-2A2B-46FE-B6C6-329EE62CB74B@archrock.com> From: Jonathan Hui To: Anders Jagd In-Reply-To: <77b524e41003090818t658cb324x226acd8a31b57758@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: Tue, 9 Mar 2010 08:50:10 -0800 References: <4B966803.5090703@acm.org> <77b524e41003090818t658cb324x226acd8a31b57758@mail.gmail.com> X-Mailer: Apple Mail (2.936) Cc: ROLL WG Subject: Re: [Roll] 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, 09 Mar 2010 16:50:20 -0000 Hi Anders, On Mar 9, 2010, at 8:18 AM, Anders Jagd wrote: > I don't see that we would benefit from going as far as generally dis- > allowing a mix of storing/non-storing. Granted, most networks would > likely in practice be either storing on non-storing. However, I am > not convinced there would not be use cases justifying a mix. > > Rather than tying our hands on this, would it not be better to have > each OF set rules/requirements for nodes to be "all storing", "all > non-storing", or "mix" ? The decision of whether or not we allow a mix may have a significant impact on how we design the DAO mechanism(s). Going either way would be effectively "tying our hand" in what the solution will look like. > I actually don't think we are able to properly answer questions like > this properly before applicability work has been done - which is the > main reason I don't think we should go so far as to dis-allow a mix > quite yet. We do have routing requirements docs that are guiding us. Did any of those point out the need for mixed-mode operation? In any case, I don't think we are in a position to properly specify a DAO mechanism that supports mixed-mode operation effectively. AFAIK, all existing production deployments within this space do not allow a mix storing and non-storing routing nodes. It's fair to say that this WG has tremendous experience and understanding of solutions that can effectively address a particular mode. But so far we have not seen a good proven solution for supporting mixed-mode environments. Going in without a proven and well-understood solution worries me and I wouldn't want to start a research project here. -- Jonathan Hui From pthubert@cisco.com Tue Mar 9 08:55: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 C303A3A68CB for ; Tue, 9 Mar 2010 08:55:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.757 X-Spam-Level: X-Spam-Status: No, score=-7.757 tagged_above=-999 required=5 tests=[AWL=0.542, BAYES_00=-2.599, MANGLED_TOOL=2.3, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oN8FevZp-shw for ; Tue, 9 Mar 2010 08:55:02 -0800 (PST) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 46BA83A6885 for ; Tue, 9 Mar 2010 08:55:02 -0800 (PST) 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: AvsEADMMlktAZnwN/2dsb2JhbACbNXOlRpkUhHkE X-IronPort-AV: E=Sophos;i="4.49,608,1262563200"; d="scan'208";a="91529411" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 09 Mar 2010 16:55:06 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o29Gt0oP028671; Tue, 9 Mar 2010 16:55:06 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); Tue, 9 Mar 2010 17:55:04 +0100 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, 9 Mar 2010 17:55:01 +0100 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D0169800A@XMB-AMS-107.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] Establishing downward routes in RPL : storing /non-storing / mixed modes of operation Thread-Index: Acq/pPhm9ggdnT20Rweep38tHYcHIgAAJcxw References: <4B966803.5090703@acm.org> From: "Pascal Thubert (pthubert)" To: "Jonathan Hui" , "Tim Winter" X-OriginalArrivalTime: 09 Mar 2010 16:55:04.0784 (UTC) FILETIME=[442FC500:01CABFA9] Cc: ROLL WG Subject: Re: [Roll] 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, 09 Mar 2010 16:55:03 -0000 Hi Jonathan and all, One thing is I'm not happy with the S bit. I do not think we understand fully what makes it work or when. Also, it implies an inner behavior in the root, and probably also implies a tree structure. And like Jonathan explains below, the worst case has not changed. I think that the problem that Jonathan discusses, the O(N) stuff and the need for DTSN that came with it, is a consequence of the behavior of the cache in the current RPL (07); specifically, the caching nodes are expected to absorb a piece of source route, and reinsert that piece on the fly for forward packets. This is in fact a complex behavior. An alternate behavior could be to optionally cache the source route piece, but in any case let the full source route info through.=20 With that alt behavior, then the source route steps would go up to the root and the need for the S bit mechanism would go away. The root would then insert all the source route step in a loose Routing Header. The intermediate caches would be useful only for the P2P traffic within the DODAG to avoid systematically going through the root. Cost compared to the current behavior is bigger (control and data) packets in normal conditions.=20 So: - I agree that the current behavior introduces too many problems and I prefer that all the steps in the source route reach the top, without being absorbed by intermediate caches. I understand that this is what people really want here, and that can be done without a mutual exclusion of source route and stateful routing. But: - I do not think that the means for source route and stateful routing should necessary be the same. I can go into the gory details if people follow me along that track. This has to do with when and why the methods are being used (proactively or reactively). This also has to do with the addresses involved (routing uses 1 hop link local, source route uses global addresses. Which address would you use to source a DAO?). And this has to do with the routing states being in place proactively so they can be used to compress the record route when it comes. We've seen some strong concerns on the source route DAOs, in particular recurring objections that we design as we go when we should be using well-known techniques. The well-known technique for source route is LSRR (in the data packets) and we have ample experience on it. Using it would actually decouple the stateful DAO from the record route. More importantly, that would allow the DAO states to compress a strict source route into a loose one whenever possible, as already prescribed in RPL, but probably not working so well since the routing states might be populated too late. I hope this helps... Pascal > -----Original Message----- > From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of > Jonathan Hui > Sent: Tuesday, March 09, 2010 5:24 PM > To: Tim Winter > Cc: ROLL WG > Subject: Re: [Roll] Establishing downward routes in RPL : storing /non-storing > / mixed modes of operation >=20 >=20 > To reiterate some of my messages in the past, I have been against mixing of > storing and non-storing nodes. To indicate why, let me highlight some of the > issues. >=20 > Supporting mixed mode operation effectively is a problem of managing > distributed state. What makes this problem difficult in mixed-mode > networks is the difficulty in tracking where state is being stored and keeping > that state up-to-date, since only select nodes are storing such state. > Specifically in RPL, it requires knowing which ancestor particular DAO state is > being maintained and sending DAO messages at appropriate times when the > ancestor changes. In the fully storing case, the ancestor is simply the parent > and easy to detect. In the fully non-storing case, the ancestor is always the > root, so again a node only needs to send updates if its immediate parent > changes. In a mixed mode case, ideally the node would know which node is > storing its DAO information (it may not be the immediate parent or even the > first storing node) when that node changes. >=20 > The existing RPL draft punts on this problem because we haven't come up > with a good simple solution. Early drafts specified that if a non- storing node > is triggered to send DAOs (e.g. due to a single link failure), it must trigger > DAOs from its descendants as well. This can lead to O(N) messages due to a > single link failure. The 'S' bit helped to optimized for the fully non-storing > case by indicating if there is a storing node that is not the root, reducing to > O(1) for a single link failure. But doesn't help much in mixed-mode > environments where the true worst-case is still O(N). >=20 > To maintain some kind of interoperability, I would say that every node MUST > at least be able to operate in leaf mode, regardless of whether it supports > only storing or only non-storing. >=20 > -- > Jonathan Hui >=20 > On Mar 9, 2010, at 7:23 AM, Tim Winter wrote: >=20 > > WG, > > > > 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 > > _______________________________________________ > > 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 From rstruik@certicom.com Tue Mar 9 08:56: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 411783A6919 for ; Tue, 9 Mar 2010 08:56:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2xaBcXsYHdkQ for ; Tue, 9 Mar 2010 08:56:13 -0800 (PST) Received: from mhs03ykf.rim.net (mhs03ykf.rim.net [216.9.243.80]) by core3.amsl.com (Postfix) with ESMTP id 3ECAF3A6904 for ; Tue, 9 Mar 2010 08:56:13 -0800 (PST) X-AuditID: 0a401fcb-b7b5cae0000009f8-a7-4b967db04e30 Received: from XCH38YKF.rim.net ( [10.64.31.208]) by mhs03ykf.rim.net (RIM Mail) with SMTP id FC.EA.02552.0BD769B4; Tue, 9 Mar 2010 11:56:16 -0500 (EST) Received: from XCH57YKF.rim.net ([10.64.31.54]) by XCH38YKF.rim.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 9 Mar 2010 11:56:15 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 Date: Tue, 9 Mar 2010 11:56:00 -0500 Message-ID: <7E1DF37F1F42AB4E877E492C308E6AC4045E0ED8@XCH57YKF.rim.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-struik-roll-rpl-security-design Thread-Index: Acq5orJCFnJIKM3VQo++LDYjJRaZXgGBKPSg From: "Rene Struik" To: "IETF ROLL" X-OriginalArrivalTime: 09 Mar 2010 16:56:15.0806 (UTC) FILETIME=[6E84DDE0:01CABFA9] X-Brightmail-Tracker: AAAAAQDsyNY= Subject: [Roll] draft-struik-roll-rpl-security-design X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 09 Mar 2010 16:56:14 -0000 RGVhciBjb2xsZWFndWVzOg0KDQpGWUkgLSBNb25kYXkgbGFzdCB3ZWVrLCBNYXJjaCAxLCAyMDEw LCBJIHBvc3RlZCBhIGxpdHRsZSBzZWN1cml0eSBkZXNpZ24gZG9jdW1lbnQgKGNmLiBiZWxvdyku IFRoZSBkb2N1bWVudCBpcyBzdGlsbCBhIHdvcmsgaW4gcHJvZ3Jlc3MsIGJ1dCBzaG91bGQgbmV2 ZXJ0aGVsZXNzIHByb3ZpZGUgc3VmZmljaWVudCBpbmZvcm1hdGlvbiBmb3IgYSBmcnVpdGZ1bCBz ZWN1cml0eSBkaXNjdXNzaW9uIGF0IHRoZSBJRVRGLTc3IG1lZXRpbmcsIEFuYWhlaW0sIENBLCBN YXJjaCAyMS0yNiwgMjAxMC4NCg0KVGhlIG5leHQgdmVyc2lvbiBpcyBpbnRlbmRlZCB0byBtZXJn ZSB0aGlzIHdpdGggVHpldGEgVHNhbydzIGRyYWZ0IGFuZCB0byBpbmNsdWRlIG1vcmUgZGV0YWls ZWQgbWF0ZXJpYWwgb24sIGUuZy4sIG1haW50YWluZWQgc3RhdGUgYW5kIHBhcmFtZXRlciBzZXR0 aW5ncy4gDQoNCkJlc3QgcmVnYXJkcywgUmVuZQ0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0t LQ0KRnJvbTogSUVURiBJLUQgU3VibWlzc2lvbiBUb29sIFttYWlsdG86aWRzdWJtaXNzaW9uQGll dGYub3JnXSANClNlbnQ6IE1vbmRheSwgTWFyY2ggMDEsIDIwMTAgNzo1MyBQTQ0KVG86IGludGVy bmV0LWRyYWZ0c0BpZXRmLm9yZw0KQ2M6IFJlbmUgU3RydWlrDQpTdWJqZWN0OiBNYW51YWwgUG9z dCBSZXF1ZXN0ZWQgZm9yIGRyYWZ0LXN0cnVpay1yb2xsLXJwbC1zZWN1cml0eS1kZXNpZ24gDQoN Ck1hbnVhbCBQb3N0aW5nIFJlcXVlc3RlZCBmb3IgZm9sbG93aW5nIEludGVybmV0LURyYWZ0Og0K DQpJLUQgU3VibWlzc2lvbiBUb29sIFVSTDogaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9p ZHN0L3N0YXR1cy5jZ2k/c3VibWlzc2lvbl9pZD0yMjExMQ0KDQoNCkZpbGVuYW1lOgkgICBkcmFm dC1zdHJ1aWstcm9sbC1ycGwtc2VjdXJpdHktZGVzaWduDQpWZXJzaW9uOgkgICAwMA0KU3RhZ2lu ZyBVUkw6CSAgIGh0dHA6Ly93d3cuaWV0Zi5vcmcvc3RhZ2luZy9kcmFmdC1zdHJ1aWstcm9sbC1y cGwtc2VjdXJpdHktZGVzaWduLTAwLnR4dA0KVGl0bGU6CQkgICBTZWN1cml0eSBEZXNpZ24gZm9y IHRoZSBJUHY2IFJvdXRpbmcgUHJvdG9jb2wgZm9yIExvdyBQb3dlciBhbmQgTG9zc3kgTmV0d29y a3MgKFJQTCkNCkNyZWF0aW9uX2RhdGU6CSAgIDIwMTAtMDMtMDENCldHIElEOgkJICAgSW5kaXZp ZHVhbCBTdWJtaXNzaW9uDQpOdW1iZXJfb2ZfcGFnZXM6IDE0DQpBYnN0cmFjdDoNCldlIGRpc2N1 c3MgYSBzZWN1cml0eSBkZXNpZ24gZm9yIHRoZSBJUHY2IFJvdXRpbmcgUHJvdG9jb2wgZm9yIExv dw0KUG93ZXIgYW5kIExvc3N5IE5ldHdvcmtzIChSUEwpLiBXaGlsZSB0aGUgZGVzaWduIGZvY3Vz ZXMgb24NCmNvbW11bmljYXRpb24gc2VjdXJpdHksIHdlIGFsc28gZGlzY3VzcyBjcm9zcy1sYXll cmluZyBhc3BlY3RzIGFuZA0Kc2VjdXJpdHkgcG9saWN5IGNvbnNpZGVyYXRpb25zLg0KDQpTdWJt aXR0ZXI6IE1hcmludXMgU3RydWlrIChyc3RydWlrQGNlcnRpY29tLmNvbSkNCg== From richard.kelsey@ember.com Tue Mar 9 09:39: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 3D57E3A6917 for ; Tue, 9 Mar 2010 09:39:49 -0800 (PST) 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 cOaGRVKT7ktH for ; Tue, 9 Mar 2010 09:39:48 -0800 (PST) Received: from EMPIRE.hq.ember.com (mail.ember.com [74.10.175.227]) by core3.amsl.com (Postfix) with ESMTP id 4F52D3A6956 for ; Tue, 9 Mar 2010 09:39:48 -0800 (PST) Received: from kelsey-ws.hq.ember.com ([192.168.81.37]) by EMPIRE.hq.ember.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 9 Mar 2010 12:42:33 -0500 Date: Tue, 09 Mar 2010 12:23:14 -0500 Message-Id: <873a095rzx.fsf@kelsey-ws.hq.ember.com> To: "Pascal Thubert (pthubert)" In-reply-to: <6A2A459175DABE4BB11DE2026AA50A5D0169800A@XMB-AMS-107.cisco.com> (pthubert@cisco.com) From: Richard Kelsey References: <4B966803.5090703@acm.org> <6A2A459175DABE4BB11DE2026AA50A5D0169800A@XMB-AMS-107.cisco.com> X-OriginalArrivalTime: 09 Mar 2010 17:42:33.0294 (UTC) FILETIME=[E607E6E0:01CABFAF] Cc: roll@ietf.org Subject: Re: [Roll] 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, 09 Mar 2010 17:39:49 -0000 > Date: Tue, 9 Mar 2010 17:55:01 +0100 > From: "Pascal Thubert (pthubert)" > > One thing is I'm not happy with the S bit. I do not think we understand > fully what makes it work or when. Pascal, The S bit reduces the DAO overhead in mostly non-caching DODAGs. This benefit, and thus the S bit, disappears if we do not support mixed caching and non-caching DODAGs. For that reason, along with all the others that have been mentioned, I am in favor of removing support for mixed mode operation. We have spent a good amount of effort trying to come up with a workable solution and have not been successful. For now we should move on to other areas in need of attention, such as P2P and multicast. -Richard From pthubert@cisco.com Tue Mar 9 10:19: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 6D9583A69EF for ; Tue, 9 Mar 2010 10:19:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.949 X-Spam-Level: X-Spam-Status: No, score=-8.949 tagged_above=-999 required=5 tests=[AWL=1.650, 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 fExCuGXrLSBg for ; Tue, 9 Mar 2010 10:19:42 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 149A33A695D for ; Tue, 9 Mar 2010 10:19:37 -0800 (PST) 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: AvkAAFsglkuQ/uCWe2dsb2JhbACbNhUBAQsLJAYcpRiZF4R5BA X-IronPort-AV: E=Sophos;i="4.49,609,1262563200"; d="scan'208";a="57858092" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 09 Mar 2010 18:19: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 o29IJcQg028938; Tue, 9 Mar 2010 18:19:38 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); Tue, 9 Mar 2010 19:19:38 +0100 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, 9 Mar 2010 19:15:40 +0100 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D0169808D@XMB-AMS-107.cisco.com> In-Reply-To: <4B952B5D.1010907@ieee.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] RPL spec v6 and OF0 draft v1: Identifying what needs to be specified in an Objective Function Thread-Index: Acq+3+lbz5X9OfSOTPizO3cDdfOErwAfWeGQ References: <4B952B5D.1010907@ieee.org> From: "Pascal Thubert (pthubert)" To: , X-OriginalArrivalTime: 09 Mar 2010 18:19:38.0818 (UTC) FILETIME=[148BEA20:01CABFB5] Subject: Re: [Roll] RPL spec v6 and OF0 draft v1: Identifying what needs to be specified in an Objective Function X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 09 Mar 2010 18:19:50 -0000 Hi Phoebus, These are all good points. Too many fore a single thread, and probably some to be taken as tickets to attract a better WG attention. In short, what is the separation between OF and RPL, should we specify an abstract interface, and what's left to implementation. Please see below =20 > I've been looking over draft-ietf-roll-of0-01 and > draft-gnawali-roll-etxof-00 to help get a sense of which items left to be > "specified by the implementation / implementation-dependent" in > draft-ietf-roll-rpl-06 are to be specified by the objective function. > My understanding is that of0 will eventually serve as a template for how > future objective function specifications should be written (together with > Section 10 of draft-ietf-roll-rpl-06, which will indicate what MUST be specified > by an OF). >=20 > OF0 currently is tasked to specify: > 1) selection of parents and siblings > 2) how to compute the rank Correct, at least as far as I understand it. > I suggest that some sections be added, maybe as placeholders for now, to > specify: > 1) The format/fields of the Objective Code Point, following the OCP object > format from the ROLL routing metrics document (draft-ietf-roll-routing- > metrics-04, pg. 24, Sec. 6, Fig. 19). This is especially important because it > indicates what parameters of the Objective Function are left for tuning. For > instance, it is hard to spot the optional preference in (draft-ietf-roll-of0-01, > pg. 5, Sec. > 3.2, point #8). The preference is in the DIO base format. My expectation is that the OF gets the DIOs to play with. I see that I need to align the OF text with the RPL text. Will do in next revision. " DODAGPreference (Prf): A 3-bit unsigned integer that defines how preferable the root of this DODAG is compared to other DODAG roots within the instance. DAGPreference ranges from 0x00 (least preferred) to 0x07 (most preferred). The default is 0 (least preferred). Section 5.3 describes how DAGPreference affects DIO processing. " > 2) The rules for how a node decides to "defer" joining or migrating to a new > DODAG iteration. I believe this has a large impact on how well a DODAG > iteration optimizes a metric. If this is arbitrary and left up to each vendor to > implement separately, there is no reason to expect that the nodes in the > network will cooperate to reach an optimum DODAG. > I'm referring to (draft-ietf-roll-rpl-06, pg. 34, Sec. 5.3.3.4): > "An implementation could defer to migrate for some reasonable amount of > time, to see if some other neighbors with potentially better metrics but > higher rank announce themselves." Yes, I think we need a ticket for this one, to discuss when to actually jump. Thomas Clausen and I just discussed that same question a few days ago. > 3) What constitutes a redundant DIO message. This determines which nodes > that have joined the DODAG iteration can talk, and thus the set of candidate > neighbors that a node can choose as a parent. I'll send a follow up email > elaborating my thoughts on this. > I'm referring to (draft-ietf-roll-rpl-06, pg. 38, Section 5.3.5.1.1): > "The exact determination of what constitutes a redundant DIO message is > left to an implementation; it could for example include DIOs that advertise > the same rank." If you ask me, you'll get one answer. You've seen from Richard's answer that there is no easy one. For reference, my answer is what's really redundant is the role of router, so we could use trickle to elect routers upon new sequences. See from http://www.ietf.org/mail-archive/web/roll/current/msg02573.html Then again, I am not sure that the RPL spec has the full and correct answer and that deserves a ticket to see what the group thinks. > 4) How the metric used by this OF may be considered inconsistent, for the > sake of the Trickle timer. > I'm referring to (draft-ietf-roll-rpl-06, pg. 38, Sec. 5.3.5.1.2): > "A metric communicated in the DIO message is determined to be > inconsistent, as according to a implementation specific path metric selection > engine." Probably the same ticket as above... > 5) The rules for a node to choose which DODAG to join, when it has multiple > choices within an RPLInstance. I'm guessing that in most cases it is only > specified by the DODAGPreference field in the DIO Base Option, but the > rules should be made explicit for each OF. > I'm referring to (draft-ietf-roll-rpl-06, pg. 33, Sec. 5.3.3.3.) "If a node has the > option to join a more preferred DODAG while still meeting other optimization > objectives, then the node will generally seek to join the more preferred > DODAG as determined by the OF." I'm not sure what more you need here? Once a node joins an instance that runs a give OF, the OF is responsible to decide the movements within the DAG for that instance. I hope that OF0 does that clearly, if not, we need to work out improvements. I do not see what's missing in the base spec here? > and also (draft-ietf-roll-rpl-06, pg. 39, Sec. 5.3.6): > "The DODAG selection is implementation and algorithm dependent. Nodes > SHOULD prefer to join DODAGs for RPLInstanceIDs advertising OCPs and > destinations compatible with their implementation specific objectives." Maybe we should just remove this text? What I think is that there is a need to join a default instance (0) in order to get more info on the environment (like discuss to some management entity) and from there, join more instances as appropriate. All this is out of scope, but the mandate to support an instance 0 with OF 0 could be added. What do you think? > 6) The rules for how a node decides to jump to another DODAG. This should > be related to the value of the node's metric and rank. > I'm referring to (draft-ietf-roll-rpl-06, pg. 34, Sec. 5.3.3.4): > "A node MAY, at any time, choose to join a different DODAG within a RPL > Instance." Some OF might be 'sticky' for instance if the root is a collection point. Others might just optimize the metrics and the preference. There must be logic that ties the whole thing in, and that logic is the core of the OF. > 7) What triggers the parent selection process. As I understand, a node is > allowed to change parents within a DODAG iteration, so long as it does not > violate any rank constraints. If the trigger for the parent selection process is > the same across all OFs, then it should be made clear in the RPL core > specification (the current wording is ambiguous). > I'm referring to (draft-ietf-roll-rpl-06, pg. 58, Sec. 10): > "The parent selection is triggered each time an event indicates that a > potential next hop information is updated. This might happen upon the > reception of a DIO message, a timer elapse, or a trigger indicating that the > state of a candidate neighbor has changed." > I also suggest that (draft-ietf-roll-of0-01, pg. 4, Sec. 3.1) be broken up into > separate sections: > * the general description of the goal > * a placeholder for how to compute the metric (even if it is irrelevant here > since there is no metric) > * the rules for computing the rank > * how to use administrative preference OF0 is an example for sure, but the spec is not THE schema that all OFs should follow, though. > The rules for computing the rank should also include a sentence or a > subsection on how and when administrative rank is to be used to adjust the > rank computed from the objective function. Or it should say that it is not > used. The guidelines for writing OFs in (draft-ietf-roll-rpl-06, pg. 58, Sec. 10) > should say that administrative rank must be addressed in an OF specification. > I'm referring to (draft-ietf-roll-rpl-06, pg. 39, Sec. 5.5) "In some cases it might > be beneficial to adjust the rank advertised by a node beyond that computed > by the OF based on some implementation specific policy and properties of > the node." Good point. I'm not sure whether OF0 has anything special there though. Maybe a ticket against OF0 wold be appropriate. > I'm not sure if it's necessary to have a separate "Advertise the metric" > section, like in (draft-gnawali-roll-etxof-00, pg. 6, Sec. 3.3), or if it can be > merged into a section on how to compute the metric. The way I think of OFs, > a node decides on a single metric and rank, and that is what it is always > advertised. Also, is the propagation of metrics different from OF to OF? > Otherwise, change the text in the RPL core > spec: (draft-ietf-roll-rpl-06, pg. 27, Sec. 5.1.3.4) "The processing and > propagation of the Metric Container is governed by implementation specific > policy functions." Hum, could you reword that? Do you really mean single? The logic in the OF enables to tie policies with multiple metrics and other administrative and non-administrative information. The metrics propagation belongs to the metrics draft, not the OF. > Another point for consideration is whether the rules for how a node decides > to lower its rank should be made explicit in a separate section from the > "Preferred Parent Selection" section. I'm not sure myself. > I'm referring to (draft-ietf-roll-rpl-06, pg. 34, Sec. 5.3.3.4): > "When a node moves to improve its position,... Such a movement may occur > at any time to decrease the rank, as per the calculation indicated by the OF." >=20 > I didn't understand if there are separate OFs for upwards or downwards > routing... whether there should be placeholder sections for DAO rank, DAO > metrics, etc. I suppose this has yet to be decided. Routing downwards happen along a DAG that is decided by the OF. The OF might be selecting a parent as DAO parent for metrics that indicate a good down path rather than a good up path. So ultimately, you could think of an OF as being split in 2, one up, one down, as you figured. You could even have a different set of parents for up and down routes.=20 Still at the moment, we form a single DAG, not a DAG for UP routes and a DAG for down routes, which seemed overly complex. So there's a single Rank as opposed to an up Rank and a down Rank. And all the DAOs will circulate along the reverse DAG. So we do not need DAO metrics to avoid loops, the loops are already avoided by the DAG construction. DAO metrics can still be useful to select a shorter path within the loopless DAG, allow a better load balancing, etc... and they are are described in Section 5.1.3.4. I see that as an optimization that might or might not be very useful, depending on the DAG. It is certainly useless if DAOs only follow a tree of preferred DAO parents. Thanks for all your very pertinent comments, Pascal >=20 > -- > Phoebus Chen > Postdoctoral Researcher > Automatic Control Lab, KTH (Royal Institute of Technology) > http://www.ee.kth.se/~phoebus >=20 >=20 >=20 > P.S. >=20 > There are some mechanisms in the RPL specification marked as > "implementation-dependent" that may not belong in an objective function. > Some of these are mentioned in (draft-ietf-roll-rpl-06, Sec. 11 and > 12). I see these sections as also serving the purpose of helping an > implementer keep track of what he needs to tune (and what he may have > implemented differently from other implementers, if their > implementations turn out to be incompatible or interact in unpredictable > ways). I've tried to list some of the "implementation-dependent" > mechanisms mentioned in the document that were missed in Sections 11 > and > 12. It might also help the reader to separate out what can be tuned > over the network via messages (besides the ones defined thus far) and > what is only tuned on the devices before deployment. >=20 > Poisoning Interval > (draft-ietf-roll-rpl-06, pg. 14, Sec. 3.4.2) > "Such a move may be undertaken after waiting an appropriate poisoning > interval, and should allow the node to restore connectivity to the DODAG > Iteration, if at all possible." >=20 > Selection of the candidate neighbors (indirectly mentioned in Sec. 12.3.1) > (draft-ietf-roll-rpl-06, pg. 30, Sec. 5.3.2) > "The exact policies for selecting neighbors and parents is > implementation-dependent." >=20 > Whether to forward packets to future parents > (draft-ietf-roll-rpl-06, pg. 32, Sec. 5.3.3.1) > "During transition to a new DODAG Iteration, a node may decide to > forward packets via 'future parents' that belong to the same DODAG > (same RPLInstanceID and DODAGID), but are observed to advertise a > more recent (incremented) DODAGSequenceNumber." >=20 > Whether to poison a sub-DAG before increasing rank and moving, or form a > floating DODAG > (draft-ietf-roll-rpl-06, pg. 34, Sec. 5.3.3.4) > "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." > (draft-ietf-roll-rpl-06, pg. 35, Sec. 5.3.3.5) > "An implementation may choose to employ this poisoning mechanism when > a node loses all of its current parents, i.e. the set of DODAG > parents becomes depleted, and it can not jump to an alternate DODAG. > An alternate mechanism is to form a floating DODAG." >=20 > Risk Window > (draft-ietf-roll-rpl-06, pg. 40, Sec. 5.6) > "It left to the implementation to define the duration of the risk window." > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From jpv@cisco.com Tue Mar 9 12:25: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 78C933A69B0 for ; Tue, 9 Mar 2010 12:25:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.598 X-Spam-Level: X-Spam-Status: No, score=-8.598 tagged_above=-999 required=5 tests=[AWL=2.001, 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 tbS0VZzQB40F for ; Tue, 9 Mar 2010 12:25:43 -0800 (PST) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 7F2813A6996 for ; Tue, 9 Mar 2010 12:25:43 -0800 (PST) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEADg9lkutJV2c/2dsb2JhbACbNnOmCpkchHkE X-IronPort-AV: E=Sophos;i="4.49,610,1262563200"; d="scan'208";a="91450069" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rtp-iport-1.cisco.com with ESMTP; 09 Mar 2010 20:25:47 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by rcdn-core-5.cisco.com (8.14.3/8.14.3) with ESMTP id o29KPkKq017851 for ; Tue, 9 Mar 2010 20:25:47 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); Tue, 9 Mar 2010 21:25:45 +0100 Received: from ams-jvasseur-8713.cisco.com ([10.55.201.132]) by xfe-ams-202.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 9 Mar 2010 21:25:45 +0100 Message-Id: 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: Tue, 9 Mar 2010 21:25:45 +0100 X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 09 Mar 2010 20:25:45.0927 (UTC) FILETIME=[B2E51D70:01CABFC6] Subject: [Roll] IETF-77 ROLL WG Meeting Agenda posted X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Mar 2010 20:25:44 -0000 Dear WG, Please find the IETF-77 ROLL WG agenda: http://www.ietf.org/proceedings/10mar/agenda/roll.txt If you have a "slot" please send us your slide no later than March 24. Many Thanks. JP. From prvs=677664696=mukul@uwm.edu Tue Mar 9 12:33: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 8E6FA3A6A37 for ; Tue, 9 Mar 2010 12:33:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.289 X-Spam-Level: X-Spam-Status: No, score=-2.289 tagged_above=-999 required=5 tests=[AWL=0.310, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ssFdG6AeXlPP for ; Tue, 9 Mar 2010 12:33:49 -0800 (PST) Received: from ip1mta.uwm.edu (ip1mta.uwm.edu [129.89.7.18]) by core3.amsl.com (Postfix) with ESMTP id 009633A6852 for ; Tue, 9 Mar 2010 12:33:48 -0800 (PST) Received: from mta02.pantherlink.uwm.edu ([129.89.7.82]) by ip1mta.uwm.edu with ESMTP; 09 Mar 2010 14:33:53 -0600 Received: from localhost (localhost.localdomain [127.0.0.1]) by mta02.pantherlink.uwm.edu (Postfix) with ESMTP id 45A732C3800E; Tue, 9 Mar 2010 14:33:53 -0600 (CST) 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 N+ByKRhiYsmB; Tue, 9 Mar 2010 14:33:52 -0600 (CST) Received: from mail02.pantherlink.uwm.edu (mail02.pantherlink.uwm.edu [129.89.7.86]) by mta02.pantherlink.uwm.edu (Postfix) with ESMTP id DA4952C38010; Tue, 9 Mar 2010 14:33:52 -0600 (CST) Date: Tue, 9 Mar 2010 14:33:52 -0600 (CST) From: Mukul Goyal To: JP Vasseur Message-ID: <1448862664.3775571268166832775.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] IETF-77 ROLL WG Meeting Agenda posted X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Mar 2010 20:34:08 -0000 JP I would like a brief slot too to present a comparison of P2P performance of DAG-based routing versus shortest path routing. Regards Mukul ----- Original Message ----- From: "JP Vasseur" To: "ROLL WG" Sent: Tuesday, March 9, 2010 2:25:45 PM GMT -06:00 US/Canada Central Subject: [Roll] IETF-77 ROLL WG Meeting Agenda posted Dear WG, Please find the IETF-77 ROLL WG agenda: http://www.ietf.org/proceedings/10mar/agenda/roll.txt If you have a "slot" please send us your slide no later than March 24. Many Thanks. JP. _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From gnawali@cs.stanford.edu Tue Mar 9 13:29: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 C91093A69AD for ; Tue, 9 Mar 2010 13:29:04 -0800 (PST) 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 blIsFsud907d for ; Tue, 9 Mar 2010 13:29:02 -0800 (PST) Received: from cs-smtp-2.Stanford.EDU (cs-smtp-2.Stanford.EDU [171.64.64.26]) by core3.amsl.com (Postfix) with ESMTP id 390103A698D for ; Tue, 9 Mar 2010 13:29:02 -0800 (PST) Received: from qw-out-2122.google.com ([74.125.92.24]) by cs-smtp-2.Stanford.EDU with esmtpsa (TLSv1:RC4-MD5:128) (Exim 4.60) (envelope-from ) id 1Np6zB-00026d-PM for roll@ietf.org; Tue, 09 Mar 2010 13:29:07 -0800 Received: by qw-out-2122.google.com with SMTP id 8so73581qwh.31 for ; Tue, 09 Mar 2010 13:28:59 -0800 (PST) MIME-Version: 1.0 Received: by 10.224.124.1 with SMTP id s1mr425715qar.78.1268170109125; Tue, 09 Mar 2010 13:28:29 -0800 (PST) In-Reply-To: <4B965F2B.1090206@ieee.org> References: <20100226011704.C9E4D28C140@core3.amsl.com> <6CE3E5D3-DAEE-45E7-9C16-1260BD345A46@cs.stanford.edu> <4B9579EB.6040604@ieee.org> <878wa162qe.fsf@kelsey-ws.hq.ember.com> <4B965F2B.1090206@ieee.org> From: Omprakash Gnawali Date: Tue, 9 Mar 2010 13:28:09 -0800 Message-ID: To: phoebus@ieee.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Scan-Signature: f219e97bb238ccbb8ed40879dafdba3c Cc: "roll@ietf.org" Subject: Re: [Roll] Fwd: New Version Notification for draft-levis-roll-trickle-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: Tue, 09 Mar 2010 21:29:05 -0000 On Tue, Mar 9, 2010 at 6:46 AM, Phoebus Chen wrote: > Richard, > > Thanks for bringing up that very relevant discussion thread... I had > forgotten about it. =A0I guess this issue is partially resolved by fallin= g > back to disabling the suppression mechanism. > > I was hoping that something more clever could be done by modifying Trickl= e's > mechanisms, as Joakim, Phil, and Omprakash seemed to have been doing. =A0= And > maybe by redefining the consistency check. =A0I don't have any good > suggestions regarding this right now, so I was probing the list for the > current status on this issue. =A0Thanks for your response. Joakim, Phil, and I did some experiments to explore variations in Trickle and what if any impact it would have on propagation speeds. We found some corner cases where dissemination latency can be long. And it turns out if we tweak the Trickle algorithm to improve Trickle timer schedule synchronization among the nodes, not only does the latency go down but also the pkt tx overhead per node becomes more uniform across the network. These explorations were done in the context of dissemination of key-values to the network rather than using Trickle to time the beacons for a routing protocol. We haven't explored these variations in the context of RPL or RPL-like protocols (eg. CTP). The impact might not be pronounced, however we don't have evidence either way at the moment. - om_p From gnawali@cs.stanford.edu Tue Mar 9 13:39: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 799783A698D for ; Tue, 9 Mar 2010 13:39:26 -0800 (PST) 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 oXyLnHMHfsxy for ; Tue, 9 Mar 2010 13:39:25 -0800 (PST) Received: from cs-smtp-3.Stanford.EDU (cs-smtp-3.Stanford.EDU [171.64.64.27]) by core3.amsl.com (Postfix) with ESMTP id A3B3B3A6814 for ; Tue, 9 Mar 2010 13:39:25 -0800 (PST) Received: from mail-qy0-f201.google.com ([209.85.221.201]) by cs-smtp-3.Stanford.EDU with esmtpsa (TLSv1:RC4-MD5:128) (Exim 4.60) (envelope-from ) id 1Np79F-0005PW-VV for roll@ietf.org; Tue, 09 Mar 2010 13:39:30 -0800 Received: by qyk39 with SMTP id 39so5889182qyk.22 for ; Tue, 09 Mar 2010 13:39:29 -0800 (PST) MIME-Version: 1.0 Received: by 10.224.45.1 with SMTP id c1mr435394qaf.87.1268170769074; Tue, 09 Mar 2010 13:39:29 -0800 (PST) In-Reply-To: <878wa162qe.fsf@kelsey-ws.hq.ember.com> References: <20100226011704.C9E4D28C140@core3.amsl.com> <6CE3E5D3-DAEE-45E7-9C16-1260BD345A46@cs.stanford.edu> <4B9579EB.6040604@ieee.org> <878wa162qe.fsf@kelsey-ws.hq.ember.com> From: Omprakash Gnawali Date: Tue, 9 Mar 2010 13:39:09 -0800 Message-ID: To: Richard Kelsey Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Scan-Signature: d1b7ebe10773c68371983edd1a66f504 Cc: roll@ietf.org, phoebus@ieee.org Subject: Re: [Roll] Fwd: New Version Notification for draft-levis-roll-trickle-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: Tue, 09 Mar 2010 21:39:26 -0000 On Tue, Mar 9, 2010 at 5:31 AM, Richard Kelsey w= rote: >> Date: Mon, 08 Mar 2010 23:27:55 +0100 >> From: Phoebus Chen >> >> I am concerned that the redundancy suppression mechanisms in Trickle >> will suppress the DIO advertisements of some of the potential parents of >> a node, and the node will end up choosing a bad parent (or bad parents). >> >> [example elided] >> >> The root of the problem is that Trickle was designed for ensuring >> consistency, but is being applied to a situation where nodes are >> actually advertising different values (their rank, their metrics). =A0It= 's >> tricky to say what should be suppressed. =A0I'm having a hard time >> imagining using something besides rank or the Objective Function metric >> for measuring consistency. > > Phoebus, > > There was an earlier dicussion of this on the roll list. > See, for example, > > http://www.ietf.org/mail-archive/web/roll/current/msg01381.html > > The thread was a discussion mostly between Jonathan and > myself about the redundancy counter and whether DIOs should > be suppressed. =A0In the end the agreement was that "it > depends". =A0The value of DIO suppression varies in different > use cases, making it a requirement in some and unimportant > in others. > > In the current draft the DIORedundancyConstant is settable > on a per-DODAG basis. =A0For those cases where the benefit of > more reliable DIO information outweighs the cost of sending > more of them, setting DIORedundancyConstant to 0xFF disables > the DIO suppression mechanism entirely. There is evidence that a threshold that is too low can be detrimental. In CTP, I can see the path cost go up with low thresholds. I can guess that the right threshold is network/density dependent. As Phoebus points out, the definition of inconsistency gets more complicated when we start using different metrics. If a path has become inconsistent according to one metric but is still consistent according to another metric, is that an inconsistency? Perhaps. But the answer might sometimes depend on the combination of the metrics being used for routing as well as the relative importance of each metric in a particular metric. It might be more important to ensure that a network is "consistent" according to a particular metric but not so important to maintain strict consistency according to other metrics in the same network. - om_p From yoav@yitran.com Tue Mar 9 13:50: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 BA7AD3A6A6D for ; Tue, 9 Mar 2010 13:50:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.132 X-Spam-Level: X-Spam-Status: No, score=-6.132 tagged_above=-999 required=5 tests=[AWL=-0.155, 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 q7LIoCDBgTQh for ; Tue, 9 Mar 2010 13:50:21 -0800 (PST) Received: from na3sys009aog106.obsmtp.com (na3sys009aog106.obsmtp.com [74.125.149.77]) by core3.amsl.com (Postfix) with SMTP id 565453A6A3D for ; Tue, 9 Mar 2010 13:50:20 -0800 (PST) Received: from source ([74.125.82.178]) by na3sys009aob106.postini.com ([74.125.148.12]) with SMTP ID DSNKS5bCoLVHfAbh7DElZrpVMnBQIZdDPHQb@postini.com; Tue, 09 Mar 2010 13:50:25 PST Received: by mail-wy0-f178.google.com with SMTP id 34so57891wyb.23 for ; Tue, 09 Mar 2010 13:50:24 -0800 (PST) From: Yoav Ben-Yehezkel References: <20100226011704.C9E4D28C140@core3.amsl.com> <6CE3E5D3-DAEE-45E7-9C16-1260BD345A46@cs.stanford.edu> <4B9579EB.6040604@ieee.org> <878wa162qe.fsf@kelsey-ws.hq.ember.com> <4B965F2B.1090206@ieee.org> In-Reply-To: MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acq/z5Op3cOu0YC1Rl+Mh9TBo70SeQAAFlrQ Date: Tue, 9 Mar 2010 23:50:27 +0200 Received: by 10.216.87.75 with SMTP id x53mr292926wee.144.1268171424505; Tue, 09 Mar 2010 13:50:24 -0800 (PST) Message-ID: <3241a448a1e9fcce6935b4322a5efdc4@mail.gmail.com> To: Omprakash Gnawali , phoebus@ieee.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: roll@ietf.org Subject: Re: [Roll] Fwd: New Version Notification for draft-levis-roll-trickle-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: Tue, 09 Mar 2010 21:50:22 -0000 Hi, See concern regarding pkt tx overhead per node becomes more uniform across the network (marked ). Thanks, Yoav -----Original Message----- From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Omprakash Gnawali Sent: Tuesday, March 09, 2010 11:28 PM To: phoebus@ieee.org Cc: roll@ietf.org Subject: Re: [Roll] Fwd: New Version Notification for draft-levis-roll-trickle-00 On Tue, Mar 9, 2010 at 6:46 AM, Phoebus Chen wrote: > Richard, > > Thanks for bringing up that very relevant discussion thread... I had > forgotten about it. =A0I guess this issue is partially resolved by fallin= g > back to disabling the suppression mechanism. > > I was hoping that something more clever could be done by modifying Trickle's > mechanisms, as Joakim, Phil, and Omprakash seemed to have been doing. =A0And > maybe by redefining the consistency check. =A0I don't have any good > suggestions regarding this right now, so I was probing the list for the > current status on this issue. =A0Thanks for your response. Joakim, Phil, and I did some experiments to explore variations in Trickle and what if any impact it would have on propagation speeds. We found some corner cases where dissemination latency can be long. And it turns out if we tweak the Trickle algorithm to improve Trickle timer schedule synchronization among the nodes, not only does the latency go down but also the pkt tx overhead per node becomes more uniform across the network. Consider the case where there is a large "cloud" of nodes that borders with a smaller cloud where all nodes are transmitting at the same uniform rate (see figure below). If the tx rates are uniform across the network, the overall number of transmissions in the large cloud may be significantly larger than the smaller cloud. In addition, the border nodes that are in both clouds will suffer most (experience approximately twice as many transmissions). Alternatively, if the rate per station is small, it will take a longer time for reaching consistency in the smaller cloud relative to the time in the larger cloud. Small cloud of nodes | OOO | O O O O O O O O|O OOO +----- border nodes (experiencing transmissions from both clouds) | Large cloud of nodes It would be nice if the trickle overall number of transmissions within a cloud can be somehow limited by some sort of congestion control algorithm thereby balancing the traffic rates experienced and smoothing the consistency update durations within each cloud. These explorations were done in the context of dissemination of key-values to the network rather than using Trickle to time the beacons for a routing protocol. We haven't explored these variations in the context of RPL or RPL-like protocols (eg. CTP). The impact might not be pronounced, however we don't have evidence either way at the moment. - om_p _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From anders.jagd@gmail.com Tue Mar 9 14:12: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 7024C3A69BE for ; Tue, 9 Mar 2010 14:12:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W8Coy-1qAcM6 for ; Tue, 9 Mar 2010 14:12:38 -0800 (PST) Received: from mail-qy0-f201.google.com (mail-qy0-f201.google.com [209.85.221.201]) by core3.amsl.com (Postfix) with ESMTP id 26E893A6802 for ; Tue, 9 Mar 2010 14:12:34 -0800 (PST) Received: by qyk39 with SMTP id 39so5922379qyk.22 for ; Tue, 09 Mar 2010 14:12:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=OzJ/EJBsmSiV1dEE4NGXKr+Ti0ifaoPKAajC6R7Ixuo=; b=wCoLHnvGp7B8RdgzhMdkx9Xhcu2VWpTUpEGPqKseEyzRZJhVp345Fq0HnHkfjAoMY9 t/Fxyr6bpVo+QTiqSLE5RqOjHf2IPaOJBRhZeEB9smpsw9LsYf/AKP7a54t5zHpckVeS jmbqmgoJ0wTvN238FoIeba+hI+iYgRqUMGJI8= 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=kO95TsRsrnTvnd4EJ/K7Jibv1GGmXdkWsJxMbOIR/caoSmyc4EOf+Kg3Q4+NuY0oDB yj3scK3f2bvlcYNNIsx9i6XxYRRL/Jxkgf71YguSoSBhxphU+V473JOx3ynXwv/n4Sza uTPBypYij19+//t7EUtYOJXZ+RhBn8BG9J+sc= MIME-Version: 1.0 Received: by 10.224.13.145 with SMTP id c17mr350898qaa.244.1268172753760; Tue, 09 Mar 2010 14:12:33 -0800 (PST) In-Reply-To: <873a095rzx.fsf@kelsey-ws.hq.ember.com> References: <4B966803.5090703@acm.org> <6A2A459175DABE4BB11DE2026AA50A5D0169800A@XMB-AMS-107.cisco.com> <873a095rzx.fsf@kelsey-ws.hq.ember.com> Date: Tue, 9 Mar 2010 17:12:33 -0500 Message-ID: <77b524e41003091412v568b2590mede379ee789de9a@mail.gmail.com> From: Anders Jagd To: Richard Kelsey Content-Type: multipart/alternative; boundary=000feaea1c6f80da1b0481657aa9 Cc: roll@ietf.org Subject: Re: [Roll] 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, 09 Mar 2010 22:12:39 -0000 --000feaea1c6f80da1b0481657aa9 Content-Type: text/plain; charset=ISO-8859-1 Could someone please help me understand why there is such reluctance to keeping a door open for mixed-mode operation ? As I see it (but I may be missing something), the first few Object Functions could certainly constrain the RPL Instance to either "all storing" or "no storing"; other OFs potentially later to follow allowing for a mix. What is it in the base document that becomes difficult to wrap-up while at the same time allowing for this flexibility ? Would that "something" be important enough to outweigh the potential cost of, after imposing such a "no mix" restriction, later having to develop protocol translation gateways between non-storing islands and storing backbone networks ? /Anders On Tue, Mar 9, 2010 at 12:23 PM, Richard Kelsey wrote: > > Date: Tue, 9 Mar 2010 17:55:01 +0100 > > From: "Pascal Thubert (pthubert)" > > > > One thing is I'm not happy with the S bit. I do not think we understand > > fully what makes it work or when. > > Pascal, > > The S bit reduces the DAO overhead in mostly non-caching > DODAGs. This benefit, and thus the S bit, disappears if we > do not support mixed caching and non-caching DODAGs. For > that reason, along with all the others that have been > mentioned, I am in favor of removing support for mixed > mode operation. > > We have spent a good amount of effort trying to come up with > a workable solution and have not been successful. For now > we should move on to other areas in need of attention, such > as P2P and multicast. > -Richard > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > --000feaea1c6f80da1b0481657aa9 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Could someone please help me understand why there is such reluctance to kee= ping a door open for mixed-mode operation ?=A0

As I see = it (but I may be missing something), the first few Object Functions could c= ertainly constrain the RPL Instance to either "all storing" or &q= uot;no storing"; other OFs potentially later to follow allowing for a = mix.=A0

What is it in the base document that becomes difficult = to wrap-up while at the same time allowing for this flexibility ? Would tha= t "something" be important enough to outweigh the potential cost = of, after imposing such a "no mix" restriction, later having to d= evelop protocol translation gateways between non-storing islands and storin= g backbone networks ?

/Anders

On Tue, Mar= 9, 2010 at 12:23 PM, Richard Kelsey <richard.kelsey@ember.com> wrote:<= br>
> Date: Tue, 9 Mar 2010 17:55:01 +0100 > From: "Pascal Thubert (pthubert)" <pthubert@cisco.com>
>
> One thing is I'm not happy with the S bit. I do not think we under= stand
> fully what makes it work or when.

Pascal,

The S bit reduces the DAO overhead in mostly non-caching
DODAGs. =A0This benefit, and thus the S bit, disappears if we
do not support mixed caching and non-caching DODAGs. =A0For
that reason, along with all the others that have been
mentioned, I am in favor of removing support for mixed
mode operation.

We have spent a good amount of effort trying to come up with
a workable solution and have not been successful. =A0For now
we should move on to other areas in need of attention, such
as P2P and multicast.
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0-Richard

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

--000feaea1c6f80da1b0481657aa9-- From jeonggil.ko@gmail.com Tue Mar 9 14:37: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 257393A6AB1 for ; Tue, 9 Mar 2010 14:37:16 -0800 (PST) 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 yODLRHw6mTOO for ; Tue, 9 Mar 2010 14:37:15 -0800 (PST) Received: from mail-fx0-f227.google.com (mail-fx0-f227.google.com [209.85.220.227]) by core3.amsl.com (Postfix) with ESMTP id 211653A6AB0 for ; Tue, 9 Mar 2010 14:37:14 -0800 (PST) Received: by fxm27 with SMTP id 27so3377318fxm.28 for ; Tue, 09 Mar 2010 14:37:16 -0800 (PST) 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=svsyHPa12DNR62SgOsvxCxxLSYGT9hguqIhxskDwVtQ=; b=C2kVLcoSqUyTRhz+UldcBOLkg9dXaPaOiIBkRUpnQvAbnDnIyrp7tj5es0LMxui8JQ pFlhlKPOIh3ufnFTNo9DjevVroYia18nRkFp87f/8krv2LVcG8kTOTbLBe8fsAgyvZeO 04HpSo95egcVpVHQ8m/GsEeDzja9yVjJ8Cx4E= 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=SYKZGoNnu9WJ7gV7KRaCpVuQnaWuQk8HTEaA8solyoVki2ywQJaW3wVxy2PZdfIguB yj29adYWlGwkjmI8fxGTAsDJMs3i955MN/Woc9Ao+cI8OFTQOnD2k5p+O75k5YAT6ImV O700sc6wR1/OOYWmLcQ+xZA5KyXrOzvHLWE94= Received: by 10.103.67.18 with SMTP id u18mr394903muk.66.1268174236186; Tue, 09 Mar 2010 14:37:16 -0800 (PST) Received: from dnab404649.stanford.edu (DNab404649.Stanford.EDU [171.64.70.73]) by mx.google.com with ESMTPS id j6sm13443218mue.44.2010.03.09.14.37.14 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 09 Mar 2010 14:37:15 -0800 (PST) Sender: "JeongGil (John) Ko" From: "JeongGil Ko (John)" Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Tue, 9 Mar 2010 14:37:11 -0800 Message-Id: To: ROLL WG Mime-Version: 1.0 (Apple Message framework v1077) X-Mailer: Apple Mail (2.1077) Subject: [Roll] Downwards packet forwarding X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 09 Mar 2010 22:37:16 -0000 Hi! Maybe I am missing this, but, is there a specific format of how the = routing stack (for source routing) should be specified in the data = packets? For example, if the root is the only storing node then the root = needs to add a routing path that the data packet should take on the = payload. Is there a specific format for this? Also should there be a = flag indicating that a specific packet contains the route that it should = take or is this checking done implicitly?=20 Thanks! -John. From jhui@archrock.com Tue Mar 9 14:39: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 5CA193A6ABC for ; Tue, 9 Mar 2010 14:39:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.27 X-Spam-Level: X-Spam-Status: No, score=-2.27 tagged_above=-999 required=5 tests=[AWL=0.329, 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 1vK5Wv-gi2IQ for ; Tue, 9 Mar 2010 14:39:35 -0800 (PST) Received: from mail.sf.archrock.com (mail.sf.archrock.com [216.121.16.71]) by core3.amsl.com (Postfix) with ESMTP id A72EF3A6A3D for ; Tue, 9 Mar 2010 14:39:35 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.sf.archrock.com (Postfix) with ESMTP id 78439AF9CE; Tue, 9 Mar 2010 14:39:40 -0800 (PST) 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 YNq6EBqPRD6G; Tue, 9 Mar 2010 14:39:36 -0800 (PST) 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 8AB92AF990; Tue, 9 Mar 2010 14:39:36 -0800 (PST) Message-Id: <3CB604AE-5E53-45FC-9C09-3381DA50863D@archrock.com> From: Jonathan Hui To: "JeongGil Ko (John)" 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: Tue, 9 Mar 2010 14:39:34 -0800 References: X-Mailer: Apple Mail (2.936) Cc: ROLL WG Subject: Re: [Roll] Downwards packet forwarding X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 09 Mar 2010 22:39:43 -0000 Message formats required for forwarding based on source routes are not specified yet. -- Jonathan Hui On Mar 9, 2010, at 2:37 PM, JeongGil Ko (John) wrote: > Hi! > > Maybe I am missing this, but, is there a specific format of how the > routing stack (for source routing) should be specified in the data > packets? For example, if the root is the only storing node then the > root needs to add a routing path that the data packet should take on > the payload. Is there a specific format for this? Also should there > be a flag indicating that a specific packet contains the route that > it should take or is this checking done implicitly? > > Thanks! > > -John. > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From Matteo.Paris@ember.com Tue Mar 9 14:58: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 AB2DF3A69A6 for ; Tue, 9 Mar 2010 14:58:57 -0800 (PST) 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 lOwYhjBFWkxB for ; Tue, 9 Mar 2010 14:58:53 -0800 (PST) Received: from EMPIRE.hq.ember.com (mail.ember.com [74.10.175.227]) by core3.amsl.com (Postfix) with ESMTP id 5482F3A687E for ; Tue, 9 Mar 2010 14:58:51 -0800 (PST) Received: from [192.168.81.62] ([192.168.90.78]) by EMPIRE.hq.ember.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 9 Mar 2010 18:01:35 -0500 Mime-Version: 1.0 Message-Id: In-Reply-To: <77b524e41003091412v568b2590mede379ee789de9a@mail.gmail.com> References: <4B966803.5090703@acm.org> <6A2A459175DABE4BB11DE2026AA50A5D0169800A@XMB-AMS-107.cisco.com> <873a095rzx.fsf@kelsey-ws.hq.ember.com> <77b524e41003091412v568b2590mede379ee789de9a@mail.gmail.com> Date: Tue, 9 Mar 2010 17:58:51 -0500 To: roll@ietf.org From: Matteo Paris Content-Type: multipart/alternative; boundary="============_-943946962==_ma============" X-OriginalArrivalTime: 09 Mar 2010 23:01:36.0075 (UTC) FILETIME=[780479B0:01CABFDC] Subject: Re: [Roll] 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, 09 Mar 2010 22:58:57 -0000 --============_-943946962==_ma============ Content-Type: text/plain; charset="us-ascii" ; format="flowed" Mixed mode is a much harder problem, for which we don't have a workable solution. It also appears that it is not as common a use case. Like others, I would like a cache-mode field in the DAG config suboption that specifies all-cache or only-root-cache. These cases are relatively simple, so we can come to consensus on solutions for each quickly and move on to other pressing issues. The cache-mode field could include a reserved value which could be used at some future date for specifying mixed-mode operation. Matteo At 5:12 PM -0500 3/9/10, Anders Jagd wrote: >Could someone please help me understand why there is such reluctance >to keeping a door open for mixed-mode operation ? > >As I see it (but I may be missing something), the first few Object >Functions could certainly constrain the RPL Instance to either "all >storing" or "no storing"; other OFs potentially later to follow >allowing for a mix. > >What is it in the base document that becomes difficult to wrap-up >while at the same time allowing for this flexibility ? Would that >"something" be important enough to outweigh the potential cost of, >after imposing such a "no mix" restriction, later having to develop >protocol translation gateways between non-storing islands and >storing backbone networks ? > >/Anders > >On Tue, Mar 9, 2010 at 12:23 PM, Richard Kelsey ><richard.kelsey@ember.com> wrote: > > > Date: Tue, 9 Mar 2010 17:55:01 +0100 >> From: "Pascal Thubert (pthubert)" >><pthubert@cisco.com> > > > >> One thing is I'm not happy with the S bit. I do not think we understand >> fully what makes it work or when. > >Pascal, > >The S bit reduces the DAO overhead in mostly non-caching >DODAGs. This benefit, and thus the S bit, disappears if we >do not support mixed caching and non-caching DODAGs. For >that reason, along with all the others that have been >mentioned, I am in favor of removing support for mixed >mode operation. > >We have spent a good amount of effort trying to come up with >a workable solution and have not been successful. For now >we should move on to other areas in need of attention, such >as P2P and multicast. > -Richard > > >_______________________________________________ >Roll mailing list >Roll@ietf.org >https://www.ietf.org/mailman/listinfo/roll > > > >_______________________________________________ >Roll mailing list >Roll@ietf.org >https://www.ietf.org/mailman/listinfo/roll --============_-943946962==_ma============ Content-Type: text/html; charset="us-ascii" Re: [Roll] Establishing downward routes in RPL : storing

Mixed mode is a much harder problem, for which we don't have a workable solution.  It also appears that it is not as common a use case.

Like others, I would like a cache-mode field in the DAG config suboption that specifies all-cache or only-root-cache.  These cases are relatively simple, so we can come to consensus on solutions for each quickly and move on to other pressing issues.  The cache-mode field could include a reserved value which could be used at some future date for specifying mixed-mode operation.

Matteo


At 5:12 PM -0500 3/9/10, Anders Jagd wrote:
Could someone please help me understand why there is such reluctance to keeping a door open for mixed-mode operation ?

As I see it (but I may be missing something), the first few Object Functions could certainly constrain the RPL Instance to either "all storing" or "no storing"; other OFs potentially later to follow allowing for a mix.

What is it in the base document that becomes difficult to wrap-up while at the same time allowing for this flexibility ? Would that "something" be important enough to outweigh the potential cost of, after imposing such a "no mix" restriction, later having to develop protocol translation gateways between non-storing islands and storing backbone networks ?

/Anders

On Tue, Mar 9, 2010 at 12:23 PM, Richard Kelsey <richard.kelsey@ember.com> wrote:
> Date: Tue, 9 Mar 2010 17:55:01 +0100
> From: "Pascal Thubert (pthubert)" <pthubert@cisco.com>
>
> One thing is I'm not happy with the S bit. I do not think we understand
> fully what makes it work or when.
Pascal,

The S bit reduces the DAO overhead in mostly non-caching
DODAGs.  This benefit, and thus the S bit, disappears if we
do not support mixed caching and non-caching DODAGs.  For
that reason, along with all the others that have been
mentioned, I am in favor of removing support for mixed
mode operation.

We have spent a good amount of effort trying to come up with
a workable solution and have not been successful.  For now
we should move on to other areas in need of attention, such
as P2P and multicast.
                                   -Richard

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


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

--============_-943946962==_ma============-- From mijeom@gmail.com Tue Mar 9 17:57: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 B65933A6AE1 for ; Tue, 9 Mar 2010 17:57:13 -0800 (PST) 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 MYJ87f0g88IU for ; Tue, 9 Mar 2010 17:57:12 -0800 (PST) Received: from qw-out-2122.google.com (qw-out-2122.google.com [74.125.92.26]) by core3.amsl.com (Postfix) with ESMTP id BCA2D3A67F2 for ; Tue, 9 Mar 2010 17:57:12 -0800 (PST) Received: by qw-out-2122.google.com with SMTP id 8so163641qwh.31 for ; Tue, 09 Mar 2010 17:57:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=gtLdFHXlO9F8YJcnF4MpEUmGCYc6yH1PIH42rrphCf8=; b=WfKwm7TzcqvtHTsVtXC08C0F1BTH1mnEYEWa+b/ncAZKeEqLRDXfRjgMpICEuPm+cG k5UF5vgaMMWomMYwooBEtX9LU6eBAXsIvmXBKSYFJfzGnBNapkVkKawNwz08y3KQ4FhF mpY4WYpRJhy5C3t/1rnBIKkVyL3dsx9dhvcow= 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=CLAkHNpvFT13rzMo2P93rVd+r+HJW8BGMUe1JdUF0u9OfwyliXDzWgsGTK6cm5CnWt o+67mobu+zIbqFyVE+LBt1eSFcKdialdjphKKEveDYPjUTS9rA4Zy0imYUax0db+mZLU Aohb0dp66o3c6/sqWcb8j4G+dBk7I7VPMe+PI= MIME-Version: 1.0 Received: by 10.224.43.136 with SMTP id w8mr561191qae.209.1268186234808; Tue, 09 Mar 2010 17:57:14 -0800 (PST) In-Reply-To: <4B94D55E.7080302@gmail.com> References: <055.28872d5d0fcf65e6839f1cd72771083c@tools.ietf.org> <064.2a20a25a31ddeb41de55f5c2ba559806@tools.ietf.org> <4B90DF6D.9070806@gmail.com> <4B94D55E.7080302@gmail.com> Date: Wed, 10 Mar 2010 10:57:14 +0900 Message-ID: From: MiJeom Kim To: Alexandru Petrescu Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: roll@ietf.org Subject: Re: [Roll] [roll] #18: Numeric Ranges in Routing Metric X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 10 Mar 2010 01:57:13 -0000 Hi, Alex, The problem you mentioned regarding option 3 can be easily solved. We can just set the rule that whenever possible, using microsecond instead of millisecond to give more information (precision). So upto 32767 miroseconds, uses microsecond and if latency becomes greater than that, uses millisecond. I had considered that removing the overlapping part, but that makes the format more complicated. Mijeom. On Mon, Mar 8, 2010 at 7:45 PM, Alexandru Petrescu wrote: > Le 08/03/2010 02:24, MiJeom Kim a =E9crit : >> >> Hi, >> >> Actually, we were in the middle of discussion. Let me resummerize the >> final options we have until now. >> >> 1. 16 bit unsigned integer --> =A0it's not enough to express all cases >> since 65535 micro seconds (65 milliseconds) > > Ok I guess we need to discard this. > >> 2. 24 bit unsigned integer > > This could represent > > 0..16777216 =A0 microseconds i.e. > 0..16777,216 =A0milliseconds i.e. > 0.. 16,777216 seconds delay. > >> 3. 1 bit indication bit (to indicate millisecond or mirocsecond) + >> 15 bit insigned integer --> =A0the range can be from 0 microseconds to >> =A032767 milliseconds. > > Right, the range of representation could be wider than with the 24bit > integer(?) > > But there a same value could be represented by two different encodings. > =A0This makes comparisons for equality longer to write in C, requires > normalization before each comparison. > > I.e. 1 millisecond could be represented by somebody as > 1000micro-seconds, and when comparing the two values it's not sufficient > to simply compare the 16bit values received in messages, one has to > normalize first (similar to when one has to apply ntohs before every > comparison of shorts received from the wire). > > Tradeoffs tradeoffs... > > Alex > >> >> Thanks, Mijeom. >> >> >> On Fri, Mar 5, 2010 at 7:39 PM, Alexandru Petrescu >> =A0wrote: >>> >>> Le 05/03/2010 11:36, roll issue tracker a =E9crit : >>>> >>>> #18: Numeric Ranges in Routing Metric >>>> >>>> >>>> --------------------------------+-------------------------------------= ------ >>>> >>>> >>>> >>>> > Reporter: =A0jpv@=85 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0 =A0 =A0Owner: = =A0mjkim@=85 >>>> >>>> Type: =A0defect =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 =A0 =A0 Status: =A0cl= osed Priority: >>>> minor =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0Milestone: Component: =A0ro= uting-metrics >>>> | Version: Severity: =A0Active WG Document =A0| =A0 Resolution: fixed >>>> Keywords: =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| >>>> >>>> >>>> --------------------------------+-------------------------------------= ------ >>>> >>>> >>>> >>>> > Changes (by jpv@=85): >>>> >>>> * status: =A0new =3D> =A0 =A0closed * resolution: =A0=3D> =A0 =A0fixed >>>> >>>> >>>> Comment: >>>> >>>> Here is the resolution after discussion on the mailing list: >>>> >>>> It's time to close on the #18. I think that throughput and >>>> latency can be better presented by unsigned integers as the below >>>> justification wrote. Latency can be expressed in units of >>>> milliseconds >>> >>> But we just seemed to agree on micro-seconds instead, haven't we? >>> >>> Alex >>> >>> >>> and throughput can >>>> >>>> be expressed in bytes per second. >>>> >>>> Mijeom. >>>> >>> >>> >>> _______________________________________________ Roll mailing list >>> Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll >>> >> > > > From mijeom@gmail.com Tue Mar 9 18:21: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 730853A6B18; Tue, 9 Mar 2010 18:21:13 -0800 (PST) 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 HKrth6WAbwdr; Tue, 9 Mar 2010 18:21:10 -0800 (PST) Received: from mail-qy0-f201.google.com (mail-qy0-f201.google.com [209.85.221.201]) by core3.amsl.com (Postfix) with ESMTP id 39AFD3A6B13; Tue, 9 Mar 2010 18:21:10 -0800 (PST) Received: by qyk39 with SMTP id 39so6145892qyk.22 for ; Tue, 09 Mar 2010 18:21:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=FpD2zsbUDy+JB8fl9hx9tsktlKpy/COeh5AV6regFFE=; b=IrwaMm4ObARozeHf6YXjpgkOd8INbHu9KGzdHWxYZEn/yByDpnSKd2iIRFUzWgkTTC FOCxBebAI1CxcdgdGTjQxoznAFjtijjZVKhq1+/alEgIFg/loGyFRcJYskO5Bc1furjl BV9n7pq6EKS7XYZ8EDkYtJAwbx6wU6Hx2Dc/w= 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=IjU7xS9k2JNk8papvjfYHAinQ7dRDRvVf6NFciews77Qa2gBv9P5hTUS60MfFFpLkD xPqmQNqcfGz2+b/VmlJ24YaWA8oj06VdqjM3o+X/PIwzLSW/gbcylwGHEwN11Z19q7Tq GfroR+zZZ2F3HqTHahAntVt3WKz0mtOl1NLwo= MIME-Version: 1.0 Received: by 10.224.114.9 with SMTP id c9mr579466qaq.148.1268187671584; Tue, 09 Mar 2010 18:21:11 -0800 (PST) In-Reply-To: References: <055.a3c60804880e85f93fc1826167be4fb6@tools.ietf.org> <201002230913.47381.henning.rogge@fkie.fraunhofer.de> <201002231122.41069.henning.rogge@fkie.fraunhofer.de> <108AEE8B-E296-44E3-BE37-1A43144B0281@unina.it> Date: Wed, 10 Mar 2010 11:21:11 +0900 Message-ID: From: MiJeom Kim To: Matteo Paris Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: roll@ietf.org, manet Subject: Re: [Roll] [manet] [roll] #20: Question on Metric 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: Wed, 10 Mar 2010 02:21:14 -0000 Hi, Matteo, I think we don't need two bytes since 1 byte can manage it as I suggested. 1 byte can be enough for ETX according to what we have discussed until now. Even using 2 bytes, we need more bits for fractional part. Anyway, what's your proposal to express fractional part using 4 bits? Mijeom. On Mon, Mar 8, 2010 at 11:40 PM, Matteo Paris wrote: > > I'd prefer using a 16-bit fixed point value for ETX, with 4 bits of > fractional part. =A0It's very simple, and easily covers the desirable ran= ges. > > I don't think the ETX value field is the right place to try to save one > byte. =A0If we need to shave bytes, there are other good candidates. =A0F= or > example we could reduce the length fields of DIO suboptions and routing > metric common headers from 2 bytes to 1 byte. We could also eliminate the > byte of flags from the routing metric common header since that informatio= n > is redundant if you know the Objective Function, and unused if you don't. > > Matteo > > > At 10:38 AM +0900 3/8/10, MiJeom Kim wrote: >> >> Thank you for clearing the issue. >> >> So, we don't need the overloading ETX, then. >> How do you think about my suggestion: >> >> we can represent (ETX * C) as (32 + a) * 2^b where 0 <=3D a <=3D 31 and = 0 >> <=3D b <=3D 7. If C is 128, the max possible ETX is 63 and if C is 64, t= he >> max ETX is 126. So let's try C =3D 64 and if ETX is bigger than 126, we >> can just make it the possible max which is 126. >> >> Other better ideas? >> let's close the ticket soon. >> >> Mijeom. >> >> >> On Sat, Mar 6, 2010 at 6:04 AM, Marcello Caleffi >> wrote: >>> >>> =A0If the delivery ratios are correctly estimated, there is no differen= ce >>> among 1ETX links, wired wireless or anything else. >>> =A0The issue is in correctly estimating the delivery ratios, but this d= oes >>> not need additional bits in the header. >>> >>> =A0Marcello >>> >>> >>> =A0Il giorno 05/mar/2010, alle ore 21.58, Omprakash Gnawali ha scritto: >>> >>>> =A0On Tue, Mar 2, 2010 at 9:28 PM, MiJeom Kim wrote= : >>>>> >>>>> =A0Hi, >>>>> >>>>> =A0It's time to summarize. >>>>> >>>>> =A0- ETX >=3D 1, and 100 is enough for Max ETX since more than 10 ETX= is >>>>> =A0close to infinity. >>>>> =A0- 8 bits are enough but need to avoid floating point format. ? goo= d to >>>>> =A0multiply with a constant factor (C) like 256 >>>>> >>>>> =A0I think Henning's suggestion is good. But we don't need a big rang= e >>>>> =A0for ETX, but precision needs to be increased. So we can adjust it = with >>>>> =A05 bit mantissa and 3 bit exponent. >>>>> >>>>> =A0So, we can represent (ETX * C) as (32 + a) * 2^b where 0 <=3D a <= =3D 31 >>>>> =A0and 0 <=3D b <=3D 7. If C is 128, the max possible ETX is 63 and i= f C is >>>>> =A064, the max ETX is 126. So let's try C =3D 64 and if ETX is bigger= than >>>>> =A0126, we can just make it the possible max which is 126. >>>>> >>>>> =A0All the numbers can be adjustable again, so please settle down the >>>>> =A0issue with your ideas. >>>>> >>>>> =A0I can't understand the Overloading ETX thing. Nobody suggests >>>>> =A0overloading ETX, I think. What do you mean by that in this thread, >>>>> =A0Omprakash? >>>> >>>> =A0It was the suggestion that not all ETX=3D1 links are the same so we >>>> =A0should leave room in the metric to differentiate preferred ETX=3D1 = link >>>> =A0from the other ETX=3D1 links. The example that was used was, wired = ETX=3D1 >>>> =A0link vs wireless ETX=3D1 link. If we make minimum ETX value to be 1= , >>>> =A0then there is no room for such differentiation based on just the ET= X >>>> =A0metric. >>>> >>>> =A0- om_p >>>> =A0_______________________________________________ >>>> =A0manet mailing list >>>> =A0manet@ietf.org >>>> =A0https://www.ietf.org/mailman/listinfo/manet >>> >>> >> _______________________________________________ >> Roll mailing list >> Roll@ietf.org >> https://www.ietf.org/mailman/listinfo/roll > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > From dominique.barthel@orange-ftgroup.com Wed Mar 10 00:08: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 D264E3A67B3 for ; Wed, 10 Mar 2010 00:08:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, 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 gE5u+0kD0i5r for ; Wed, 10 Mar 2010 00:08:14 -0800 (PST) Received: from p-mail2.rd.francetelecom.com (p-mail2.rd.francetelecom.com [195.101.245.16]) by core3.amsl.com (Postfix) with ESMTP id 926213A65A6 for ; Wed, 10 Mar 2010 00:08:14 -0800 (PST) Received: from p-mail2.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id E34C56FCC24; Wed, 10 Mar 2010 09:12:13 +0000 (UTC) Received: from ftrdsmtp1.rd.francetelecom.fr (unknown [10.192.128.46]) by p-mail2.rd.francetelecom.com (Postfix) with ESMTP id DA9EC6FCC22; Wed, 10 Mar 2010 09:12:13 +0000 (UTC) Received: from ftrdmel0.rd.francetelecom.fr ([10.192.128.56]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Wed, 10 Mar 2010 09:08:19 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 10 Mar 2010 09:07:14 +0100 Message-ID: <8E09C72DBC577D489F13A71228C0B7BF0105150F@ftrdmel0.rd.francetelecom.fr> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] [roll] #18: Numeric Ranges in Routing Metric Thread-Index: Acq/9SobzZTeGQ2+SPit8qOvJT6lYgAMnSPQ References: <055.28872d5d0fcf65e6839f1cd72771083c@tools.ietf.org><064.2a20a25a31ddeb41de55f5c2ba559806@tools.ietf.org><4B90DF6D.9070806@gmail.com><4B94D55E.7080302@gmail.com> From: To: , X-OriginalArrivalTime: 10 Mar 2010 08:08:19.0590 (UTC) FILETIME=[D86FA260:01CAC028] Cc: roll@ietf.org Subject: Re: [Roll] [roll] #18: Numeric Ranges in Routing Metric X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 10 Mar 2010 08:08:15 -0000 Hi all, I disagree with option 3. This is just another "floating point" format, = with a one-bit exponent and a 15-bit mantissa. If IEEE 16-bit FP was = rejected, this one should be rejected for the same reasons. Again, I favor option 2, but instead of microsecond increments, which is = a resolution we don't need, I suggest using 10 us increments, which = pushes the full range to about 168 seconds. Again, you can't measure the = link latency with a resolution smaller than 10us, if only because of = random back-off delays or mere electrical symbol duration. Dominique -----Message d'origine----- De : roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] De la part de = MiJeom Kim Envoy=E9 : mercredi 10 mars 2010 02:57 =C0 : Alexandru Petrescu Cc : roll@ietf.org Objet : Re: [Roll] [roll] #18: Numeric Ranges in Routing Metric Hi, Alex, The problem you mentioned regarding option 3 can be easily solved. We = can just set the rule that whenever possible, using microsecond instead = of millisecond to give more information (precision). So upto 32767 miroseconds, uses microsecond and if latency becomes greater than = that, uses millisecond. I had considered that removing the overlapping part, but that makes the = format more complicated. Mijeom. On Mon, Mar 8, 2010 at 7:45 PM, Alexandru Petrescu = wrote: > Le 08/03/2010 02:24, MiJeom Kim a =E9crit : >> >> Hi, >> >> Actually, we were in the middle of discussion. Let me resummerize the = >> final options we have until now. >> >> 1. 16 bit unsigned integer --> =A0it's not enough to express all = cases=20 >> since 65535 micro seconds (65 milliseconds) > > Ok I guess we need to discard this. > >> 2. 24 bit unsigned integer > > This could represent > > 0..16777216 =A0 microseconds i.e. > 0..16777,216 =A0milliseconds i.e. > 0.. 16,777216 seconds delay. > >> 3. 1 bit indication bit (to indicate millisecond or mirocsecond) + >> 15 bit insigned integer --> =A0the range can be from 0 microseconds = to >> =A032767 milliseconds. > > Right, the range of representation could be wider than with the 24bit > integer(?) > > But there a same value could be represented by two different = encodings. > =A0This makes comparisons for equality longer to write in C, requires=20 > normalization before each comparison. > > I.e. 1 millisecond could be represented by somebody as=20 > 1000micro-seconds, and when comparing the two values it's not=20 > sufficient to simply compare the 16bit values received in messages,=20 > one has to normalize first (similar to when one has to apply ntohs=20 > before every comparison of shorts received from the wire). > > Tradeoffs tradeoffs... > > Alex > >> >> Thanks, Mijeom. >> >> >> On Fri, Mar 5, 2010 at 7:39 PM, Alexandru Petrescu=20 >> =A0wrote: >>> >>> Le 05/03/2010 11:36, roll issue tracker a =E9crit : >>>> >>>> #18: Numeric Ranges in Routing Metric >>>> >>>> >>>> --------------------------------+---------------------------------- >>>> --------------------------------+--------- >>>> >>>> >>>> >>>> > Reporter: =A0jpv@... =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0 =A0 = =A0Owner: =A0mjkim@... >>>> >>>> Type: =A0defect =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 =A0 =A0 Status: = =A0closed Priority: >>>> minor =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0Milestone: Component: = =A0routing-metrics >>>> | Version: Severity: =A0Active WG Document =A0| =A0 Resolution: = fixed >>>> Keywords: =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| >>>> >>>> >>>> --------------------------------+---------------------------------- >>>> --------------------------------+--------- >>>> >>>> >>>> >>>> > Changes (by jpv@...): >>>> >>>> * status: =A0new =3D> =A0 =A0closed * resolution: =A0=3D> =A0 = =A0fixed >>>> >>>> >>>> Comment: >>>> >>>> Here is the resolution after discussion on the mailing list: >>>> >>>> It's time to close on the #18. I think that throughput and latency=20 >>>> can be better presented by unsigned integers as the below=20 >>>> justification wrote. Latency can be expressed in units of=20 >>>> milliseconds >>> >>> But we just seemed to agree on micro-seconds instead, haven't we? >>> >>> Alex >>> >>> >>> and throughput can >>>> >>>> be expressed in bytes per second. >>>> >>>> Mijeom. >>>> >>> >>> >>> _______________________________________________ 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 From pthubert@cisco.com Wed Mar 10 01:17: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 EA8EA3A67A7 for ; Wed, 10 Mar 2010 01:17:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.066 X-Spam-Level: X-Spam-Status: No, score=-9.066 tagged_above=-999 required=5 tests=[AWL=1.532, 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 PIraKoih3TjN for ; Wed, 10 Mar 2010 01:17:20 -0800 (PST) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id 4E27F3A65A6 for ; Wed, 10 Mar 2010 01:17:20 -0800 (PST) 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: Av0EAB7ylkutJV2Z/2dsb2JhbACBRJlDc6NhmFSEeQQ X-IronPort-AV: E=Sophos;i="4.49,613,1262563200"; d="scan'208,217";a="216427039" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by sj-iport-3.cisco.com with ESMTP; 10 Mar 2010 09:17:24 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by rcdn-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id o2A9HINn003042; Wed, 10 Mar 2010 09:17: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); Wed, 10 Mar 2010 10:17:04 +0100 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_01CAC032.72F869E9" Date: Wed, 10 Mar 2010 10:13:11 +0100 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D0169821A@XMB-AMS-107.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] Establishing downward routes in RPL : storing /non-storing / mixed modes of operation Thread-Index: Acq/3CA4WBViHxBITTSn3gXcY6pHFAAUmbRA References: <4B966803.5090703@acm.org><6A2A459175DABE4BB11DE2026AA50A5D0169800A@XMB-AMS-107.cisco.com><873a095rzx.fsf@kelsey-ws.hq.ember.com><77b524e41003091412v568b2590mede379ee789de9a@mail.gmail.com> From: "Pascal Thubert (pthubert)" To: "Matteo Paris" , X-OriginalArrivalTime: 10 Mar 2010 09:17:04.0766 (UTC) FILETIME=[733B89E0:01CAC032] Subject: Re: [Roll] 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, 10 Mar 2010 09:17:22 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CAC032.72F869E9 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Matteo and Anders : =20 There are known solutions to the mixed mode problem. Very, very well known. That is called Loose Source and Record Route. But we did not use that. We tried to merge the well know problem of the source route into the DAO advertisement, and for such a merge I do not know of an existing, working solution. And then we started proposing mechanisms that opened more questions than they actually solved, and ultimately, we lost confidence in what we were doing. =20 Obviously, this proposal to split seems to simplify, but since it does not address the real problem, it does not provide the right solution, and we end up throwing the baby with the bath water. =20 For me, the real answer to this call is to split the procedures used for stateful and source route, as opposed to the deployment cases where source route and stateful routing are used.=20 =20 That is, to leave the proactive DAO mechanism to stateful routing, and use the classical data path LSRR for the source route. And those 2 work great together, mostly independently. That way, stateful DAO happens first and does not depend on source route, and then source route can benefit from existing routing states to make the LSRR as small (loose) as possible. It is up to a destination to advertise itself proactively in the DAO system, or just on demand using source route. =20 Cheers, =20 Pascal =20 From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Matteo Paris Sent: Tuesday, March 09, 2010 11:59 PM To: roll@ietf.org Subject: Re: [Roll] Establishing downward routes in RPL : storing /non-storing / mixed modes of operation =20 =20 Mixed mode is a much harder problem, for which we don't have a workable solution. It also appears that it is not as common a use case.=20 =20 Like others, I would like a cache-mode field in the DAG config suboption that specifies all-cache or only-root-cache. These cases are relatively simple, so we can come to consensus on solutions for each quickly and move on to other pressing issues. The cache-mode field could include a reserved value which could be used at some future date for specifying mixed-mode operation. =20 Matteo =20 =20 At 5:12 PM -0500 3/9/10, Anders Jagd wrote: Could someone please help me understand why there is such reluctance to keeping a door open for mixed-mode operation ? =20 As I see it (but I may be missing something), the first few Object Functions could certainly constrain the RPL Instance to either "all storing" or "no storing"; other OFs potentially later to follow allowing for a mix. =20 What is it in the base document that becomes difficult to wrap-up while at the same time allowing for this flexibility ? Would that "something" be important enough to outweigh the potential cost of, after imposing such a "no mix" restriction, later having to develop protocol translation gateways between non-storing islands and storing backbone networks ? =20 /Anders =20 On Tue, Mar 9, 2010 at 12:23 PM, Richard Kelsey wrote: > Date: Tue, 9 Mar 2010 17:55:01 +0100 > From: "Pascal Thubert (pthubert)" > > One thing is I'm not happy with the S bit. I do not think we understand > fully what makes it work or when. Pascal, =09 The S bit reduces the DAO overhead in mostly non-caching DODAGs. This benefit, and thus the S bit, disappears if we do not support mixed caching and non-caching DODAGs. For that reason, along with all the others that have been mentioned, I am in favor of removing support for mixed mode operation. =09 We have spent a good amount of effort trying to come up with a workable solution and have not been successful. For now we should move on to other areas in need of attention, such as P2P and multicast. -Richard =09 _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll =20 =09 _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll =20 ------_=_NextPart_001_01CAC032.72F869E9 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Re: [Roll] Establishing downward routes in RPL = : storing

Hi Matteo and Anders :

 

There are known solutions to the mixed mode problem. Very, very well = known. That is called Loose Source and Record Route. But we did not use = that. We tried to merge the well know problem of the source route into = the DAO advertisement, and for such a merge I do not know of an = existing, working solution. And then we started proposing mechanisms = that opened more questions than they actually solved, and ultimately, we = lost confidence in what we were doing.

 

Obviously, this proposal to split seems to simplify, but since it = does not address the real problem, it does not provide the right = solution, and we end up throwing the baby with the bath = water.

 

For me, the real answer to this call is to split the procedures used = for stateful and source route, as opposed to the deployment cases where = source route and stateful routing are used.

 

That is, to leave the proactive DAO mechanism to stateful routing, = and use the classical data path LSRR for the source route. And those 2 = work great together, mostly independently. That way, stateful DAO = happens first and does not depend on source route, and then source route = can benefit from existing routing states to make the LSRR as small = (loose) as possible. It is up to a destination to advertise itself = proactively in the DAO system, or just on demand using source = route.

 

Cheers,

 

Pascal

 

From:= = roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of = Matteo Paris
Sent: Tuesday, March 09, 2010 11:59 = PM
To: roll@ietf.org
Subject: Re: [Roll] = Establishing downward routes in RPL : storing /non-storing / mixed modes = of operation

 

 

Mixed mode is a much harder problem, for which we = don't have a workable solution.  It also appears that it is not as = common a use case.

 

Like others, I would like a cache-mode field in the = DAG config suboption that specifies all-cache or only-root-cache.  = These cases are relatively simple, so we can come to consensus on = solutions for each quickly and move on to other pressing issues.  = The cache-mode field could include a reserved value which could be used = at some future date for specifying mixed-mode = operation.

 

Matteo

 

 

At 5:12 PM -0500 3/9/10, Anders Jagd = wrote:

Could someone please help me understand why there is = such reluctance to keeping a door open for mixed-mode operation = ?

 

As I = see it (but I may be missing something), the first few Object Functions = could certainly constrain the RPL Instance to either "all = storing" or "no storing"; other OFs potentially later to = follow allowing for a mix.

 

What = is it in the base document that becomes difficult to wrap-up while at = the same time allowing for this flexibility ? Would that = "something" be important enough to outweigh the potential cost = of, after imposing such a "no mix" restriction, later having = to develop protocol translation gateways between non-storing islands and = storing backbone networks ?

 

/Anders

 

On = Tue, Mar 9, 2010 at 12:23 PM, Richard Kelsey <richard.kelsey@ember.com>= wrote:

> Date: Tue, 9 Mar 2010 = 17:55:01 +0100
> From: "Pascal Thubert (pthubert)" = <pthubert@cisco.com><= /p>

>
> One thing is I'm not happy with the S = bit. I do not think we understand
> fully what makes it work or = when.

Pascal,

The S bit reduces the DAO overhead in = mostly non-caching
DODAGs.  This benefit, and thus the S bit, = disappears if we
do not support mixed caching and non-caching DODAGs. =  For
that reason, along with all the others that have = been
mentioned, I am in favor of removing support for mixed
mode = operation.

We have spent a good amount of effort trying to come = up with
a workable solution and have not been successful.  For = now
we should move on to other areas in need of attention, such
as = P2P and multicast.
        &= nbsp;           &n= bsp;           &nb= sp;  -Richard


_______________________________________________
= Roll mailing 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_01CAC032.72F869E9-- From pthubert@cisco.com Wed Mar 10 02:39: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 A34973A6767 for ; Wed, 10 Mar 2010 02:39:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.658 X-Spam-Level: X-Spam-Status: No, score=-6.658 tagged_above=-999 required=5 tests=[AWL=-1.080, BAYES_50=0.001, EXTRA_MPART_TYPE=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, SARE_GIF_ATTACH=1.42] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O2PE8ncvvU+p for ; Wed, 10 Mar 2010 02:39:32 -0800 (PST) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id C62393A69F6 for ; Wed, 10 Mar 2010 02:39:24 -0800 (PST) Authentication-Results: sj-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-Files: image003.gif, image004.png : 87, 6279 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: At0KABsFl0utJV2c/2dsb2JhbAB1T4FHlxljc6QIiCmQJwKEDWoE X-IronPort-AV: E=Sophos;i="4.49,613,1262563200"; d="gif'147?png'147,150?scan'147,150,208,217,147,150";a="307221512" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by sj-iport-1.cisco.com with ESMTP; 10 Mar 2010 10:39:29 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by rcdn-core-5.cisco.com (8.14.3/8.14.3) with ESMTP id o2AAdP43008439 for ; Wed, 10 Mar 2010 10:39:29 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); Wed, 10 Mar 2010 11:39:27 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----_=_NextPart_001_01CAC03D.F52E7EAC" Date: Wed, 10 Mar 2010 11:39:24 +0100 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D016982C5@XMB-AMS-107.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Ack the DAO? Thread-Index: AcrAPfPIyxeYBGuWTw+gDRQ3zVwt/Q== From: "Pascal Thubert (pthubert)" To: X-OriginalArrivalTime: 10 Mar 2010 10:39:27.0579 (UTC) FILETIME=[F560F2B0:01CAC03D] Subject: [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: Wed, 10 Mar 2010 10:39:33 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CAC03D.F52E7EAC Content-Type: multipart/alternative; boundary="----_=_NextPart_002_01CAC03D.F52E7EAC" ------_=_NextPart_002_01CAC03D.F52E7EAC Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 V0c6DQoNCiANCg0KUlBMIDA3IHByb3ZpZGVzIG1lYW5zIGZvciBhIG5vZGUgdG8gYWR2ZXJ0aXNl IHNvbWUgcmVhY2hhYmlsaXR5IHVzaW5nIGEgREFPIG1lY2hhbmlzbS4gVGhlIERBTyBjYW4gYmUg dHJpZ2dlcmVkIGJ5IHRoZSBub2RlIHRvIG1hdGNoIGl0cyBvd24gbmVlZHMuIEl0IGNhbiBhbHNv IGJlIHN0aW11bGF0ZWQgYnkgYSBwYXJlbnQsIGJ5IGluY3JlbWVudGluZyB0aGUgRFRTTiwgb3Ig YnkgdGhlIHJvb3QsIGJ5IHNldHRpbmcgdGhlIFQgYml0IHRoYXQgY2F1c2VzIHRoZSBEVFNOIGlu Y3JlbWVudCB0byBzcGFuIHRoZSB3aG9sZSBET0RBRy4NCg0KIA0KDQpUaGUgRFRTTiB3YXMgYWRk ZWQgYXMgYSByZXBsYWNlbWVudCB0byBhIHNpbmdsZSBiaXQgYmVjYXVzZSwgZHVlIHRvIHRoZSBu YXR1cmUgb2YgYW4gTExOLCB3ZSB0aG91Z2h0IHRoYXQgdGhlIGJpdCBtaWdodCBiZSBsb3N0IHdo ZXJlYXMgYSBEVFNOIGluY3JlbWVudCBtdXN0IGJlIHNlZW4gYXQgc29tZSBwb2ludC4gQnV0IHRo ZSBvdGhlciB3YXkgYXJvdW5kLCB0aGUgREFPIG1lc3NhZ2UgaXMgbm90IGFja25vd2xlZGdlZCBz byBhIG5vZGUgbWlnaHQgbm90IG9idGFpbiB0aGUgc2VydmljZSB0aGF0IGl0IGV4cGVjdHMsIGFu ZCBhIHJvdXRlIHByb3BhZ2F0aW9uIG1pZ2h0IGJlIGluYXBwcm9wcmlhdGVseSBkZWxheWVkLg0K DQogDQoNClNvIHRoZSBzaW1wbGUgcXVlc3Rpb24gaXMsIHNob3VsZCB3ZSBtYWtlIHRoZSBEQU8g YSBiaXQgbW9yZSByZWxpYWJsZSBieSBhZGRpbmcgYW4gYWNrPyANCg0KIA0KDQogDQoNCgkNClBh c2NhbCBUaHViZXJ0DQpFbmdpbmVlci5zb2Z0d2FyZSBFbmdpbmVlcmluZw0KUHJvZHVjdCBEZXZl bG9wbWVudA0KcHRodWJlcnRAY2lzY28uY29tIDxtYWlsdG86cHRodWJlcnRAY2lzY28uY29tPiAN ClBob25lOiArMzMgNCA5NzIzIDI2MzQNCk1vYmlsZTogKzMzIDYgMTk5OCAyOTg1DQoNCg0KDQpD aXNjbyBTeXN0ZW1zIEZyYW5jZQ0KVmlsbGFnZSBkJ0VudHJlcHJpc2VzIEdyZWVuIFNpZGUNCjQw MCBBdmVudWUgZGUgUm91bWFuaWxsZSANCkJhdGltZW50IFQgMyANCjA2NDEwIA0KQklPVCAtIFNP UEhJQSBBTlRJUE9MSVMNCkZyYW5jZQ0KQ2lzY28uY29tIDxodHRwOi8vd3d3LmNpc2NvLmNvbS9n bG9iYWwvRlIvPiANCg0KICANCg0KIA0KDQogVGhpbmsgYmVmb3JlIHlvdSBwcmludC4NCg0KQ2lz Y28gU3lzdGVtcyBGcmFuY2UsIFNvY2nDqXTDqSDDoCByZXNwb25zYWJpaXTDqSBsaW1pdMOpZSwg UnVlIENhbWlsbGUgRGVzbW91bGlucyDigJMgSW1tIEF0bGFudGlzIFphYyBGb3J1bSBTZWluZSBJ bG90IDcgOTIxMzAgSXNzeSBsZXMgTW91bGluZWF1eCwgQXUgY2FwaXRhbCBkZSA5MS40NzAg4oKs LCAzNDkgMTY2IDU2MSBSQ1MgTmFudGVycmUsIERpcmVjdGV1ciBkZSBsYSBwdWJsaWNhdGlvbjog SmVhbi1MdWMgTWljaGVsIEdpdm9uZSwgRm9yIGNvcnBvcmF0ZSBsZWdhbCBpbmZvcm1hdGlvbiBn byB0bzoNCmh0dHA6Ly93d3cuY2lzY28uY29tL3dlYi9hYm91dC9kb2luZ19idXNpbmVzcy9sZWdh bC9jcmkvaW5kZXguaHRtbCA8aHR0cDovL3d3dy5jaXNjby5jb20vd2ViL2Fib3V0L2RvaW5nX2J1 c2luZXNzL2xlZ2FsL2NyaS9pbmRleC5odG1sPiANCg0KIA0KDQogDQoNCg== ------_=_NextPart_002_01CAC03D.F52E7EAC Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij48bWV0YSBuYW1lPUdlbmVyYXRvciBjb250ZW50 PSJNaWNyb3NvZnQgV29yZCAxNCAoZmlsdGVyZWQgbWVkaXVtKSI+PCEtLVtpZiAhbXNvXT48c3R5 bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7YmVoYXZpb3I6dXJs KCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0KLnNo YXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwhW2VuZGlmXS0tPjxz dHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFt aWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7 fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRp di5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9u dC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCW1z by1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7 bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVu ZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0 eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJs aW5lO30NCnAuTXNvQWNldGF0ZSwgbGkuTXNvQWNldGF0ZSwgZGl2Lk1zb0FjZXRhdGUNCgl7bXNv LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJUZXh0ZSBkZSBidWxsZXMgQ2Fy IjsNCgltYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6OC4w cHQ7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiOw0KCW1zby1mYXJlYXN0LWxh bmd1YWdlOkVOLVVTO30NCnNwYW4uRW1haWxTdHlsZTE3DQoJe21zby1zdHlsZS10eXBlOnBlcnNv bmFsLWNvbXBvc2U7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xv cjp3aW5kb3d0ZXh0O30NCnNwYW4uVGV4dGVkZWJ1bGxlc0Nhcg0KCXttc28tc3R5bGUtbmFtZToi VGV4dGUgZGUgYnVsbGVzIENhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHls ZS1saW5rOiJUZXh0ZSBkZSBidWxsZXMiOw0KCWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNl cmlmIjt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglm b250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCW1zby1mYXJlYXN0LWxhbmd1YWdl OkVOLVVTO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCglt YXJnaW46NzAuODVwdCA3MC44NXB0IDcwLjg1cHQgNzAuODVwdDt9DQpkaXYuV29yZFNlY3Rpb24x DQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4 bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94 bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2 OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFw ZWxheW91dD48L3htbD48IVtlbmRpZl0tLT48L2hlYWQ+PGJvZHkgbGFuZz1GUiBsaW5rPWJsdWUg dmxpbms9cHVycGxlPjxkaXYgY2xhc3M9V29yZFNlY3Rpb24xPjxwIGNsYXNzPU1zb05vcm1hbD48 c3BhbiBsYW5nPUVOLVVTPldHOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3Jt YWw+PHNwYW4gbGFuZz1FTi1VUz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9 TXNvTm9ybWFsPjxzcGFuIGxhbmc9RU4tVVM+UlBMIDA3IHByb3ZpZGVzIG1lYW5zIGZvciBhIG5v ZGUgdG8gYWR2ZXJ0aXNlIHNvbWUgcmVhY2hhYmlsaXR5IHVzaW5nIGEgREFPIG1lY2hhbmlzbS4g VGhlIERBTyBjYW4gYmUgdHJpZ2dlcmVkIGJ5IHRoZSBub2RlIHRvIG1hdGNoIGl0cyBvd24gbmVl ZHMuIEl0IGNhbiBhbHNvIGJlIHN0aW11bGF0ZWQgYnkgYSBwYXJlbnQsIGJ5IGluY3JlbWVudGlu ZyB0aGUgRFRTTiwgb3IgYnkgdGhlIHJvb3QsIGJ5IHNldHRpbmcgdGhlIFQgYml0IHRoYXQgY2F1 c2VzIHRoZSBEVFNOIGluY3JlbWVudCB0byBzcGFuIHRoZSB3aG9sZSBET0RBRy48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIGxhbmc9RU4tVVM+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBsYW5nPUVOLVVTPlRo ZSBEVFNOIHdhcyBhZGRlZCBhcyBhIHJlcGxhY2VtZW50IHRvIGEgc2luZ2xlIGJpdCBiZWNhdXNl LCBkdWUgdG8gdGhlIG5hdHVyZSBvZiBhbiBMTE4sIHdlIHRob3VnaHQgdGhhdCB0aGUgYml0IG1p Z2h0IGJlIGxvc3Qgd2hlcmVhcyBhIERUU04gaW5jcmVtZW50IG11c3QgYmUgc2VlbiBhdCBzb21l IHBvaW50LiBCdXQgdGhlIG90aGVyIHdheSBhcm91bmQsIHRoZSBEQU8gbWVzc2FnZSBpcyBub3Qg YWNrbm93bGVkZ2VkIHNvIGEgbm9kZSBtaWdodCBub3Qgb2J0YWluIHRoZSBzZXJ2aWNlIHRoYXQg aXQgZXhwZWN0cywgYW5kIGEgcm91dGUgcHJvcGFnYXRpb24gbWlnaHQgYmUgaW5hcHByb3ByaWF0 ZWx5IGRlbGF5ZWQuPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3Bh biBsYW5nPUVOLVVTPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3Jt YWw+PHNwYW4gbGFuZz1FTi1VUz5TbyB0aGUgc2ltcGxlIHF1ZXN0aW9uIGlzLCBzaG91bGQgd2Ug bWFrZSB0aGUgREFPIGEgYml0IG1vcmUgcmVsaWFibGUgYnkgYWRkaW5nIGFuIGFjaz8gPG86cD48 L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBsYW5nPUVOLVVTPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gbGFuZz1FTi1V Uz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PHRhYmxlIGNsYXNzPU1zb05vcm1hbFRhYmxl IGJvcmRlcj0wIGNlbGxzcGFjaW5nPTAgY2VsbHBhZGRpbmc9MCB3aWR0aD01NDMgc3R5bGU9J3dp ZHRoOjQwNy4yNXB0Jz48dHI+PHRkIHN0eWxlPSdwYWRkaW5nOjBjbSAwY20gMGNtIDBjbSc+PHRh YmxlIGNsYXNzPU1zb05vcm1hbFRhYmxlIGJvcmRlcj0wIGNlbGxzcGFjaW5nPTAgY2VsbHBhZGRp bmc9MCB3aWR0aD02MDAgc3R5bGU9J3dpZHRoOjQ1MC4wNXB0Jz48dHI+PHRkIGNvbHNwYW49MyBz dHlsZT0ncGFkZGluZzowY20gMGNtIDBjbSAwY20nPjwvdGQ+PC90cj48dHIgc3R5bGU9J2hlaWdo dDo5NC4wNXB0Jz48dGQgbm93cmFwIHZhbGlnbj10b3Agc3R5bGU9J3BhZGRpbmc6MGNtIDBjbSAx MS4yNXB0IDE4LjBwdDtoZWlnaHQ6OTQuMDVwdCc+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJnaW4tYm90dG9tOjEyLjBwdCc+PGI+PHNwYW4gbGFu Zz1FTi1VUyBzdHlsZT0nZm9udC1zaXplOjguNXB0O2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMt c2VyaWYiO2NvbG9yOiM2NjY2NjY7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RlInPlBhc2NhbCBUaHVi ZXJ0PC9zcGFuPjwvYj48c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdmb250LXNpemU6OC41cHQ7Zm9u dC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiI7Y29sb3I6IzY2NjY2Njttc28tZmFyZWFzdC1s YW5ndWFnZTpGUic+PGJyPjxiPkVuZ2luZWVyLnNvZnR3YXJlIEVuZ2luZWVyaW5nPC9iPjxicj48 Yj5Qcm9kdWN0IERldmVsb3BtZW50PC9iPjxicj48L3NwYW4+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6 ZTo4LjVwdDtmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIjtjb2xvcjojNjY2NjY2O21z by1mYXJlYXN0LWxhbmd1YWdlOkZSJz48YSBocmVmPSJtYWlsdG86cHRodWJlcnRAY2lzY28uY29t Ij48c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdjb2xvcjojNjY2NjY2Jz5wdGh1YmVydEBjaXNjby5j b208L3NwYW4+PC9hPjwvc3Bhbj48c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdmb250LXNpemU6OC41 cHQ7Zm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiI7Y29sb3I6IzY2NjY2Njttc28tZmFy ZWFzdC1sYW5ndWFnZTpGUic+PGJyPlBob25lOiA8Yj4rMzMgNCA5NzIzIDI2MzQ8L2I+PGJyPk1v YmlsZTogPGI+KzMzIDYgMTk5OCAyOTg1PC9iPjxicj48YnI+PG86cD48L286cD48L3NwYW4+PC9w PjwvdGQ+PHRkIG5vd3JhcCB2YWxpZ249dG9wIHN0eWxlPSdwYWRkaW5nOjBjbSAwY20gNy41cHQg MTUuMHB0O2hlaWdodDo5NC4wNXB0Jz48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21zby1tYXJn aW4tdG9wLWFsdDphdXRvO21hcmdpbi1ib3R0b206MTIuMHB0Jz48Yj48c3BhbiBzdHlsZT0nZm9u dC1zaXplOjguNXB0O2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiO2NvbG9yOiM2NjY2 NjY7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RlInPkNpc2NvIFN5c3RlbXMgRnJhbmNlPC9zcGFuPjwv Yj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjguNXB0O2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMt c2VyaWYiO2NvbG9yOiM2NjY2NjY7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RlInPjxicj5WaWxsYWdl IGQnRW50cmVwcmlzZXMgR3JlZW4gU2lkZTxicj40MDAgQXZlbnVlIGRlIFJvdW1hbmlsbGUgPGJy PkJhdGltZW50IFQgMyA8YnI+MDY0MTAgPGJyPkJJT1QgLSBTT1BISUEgQU5USVBPTElTPGJyPkZy YW5jZTxicj48YSBocmVmPSJodHRwOi8vd3d3LmNpc2NvLmNvbS9nbG9iYWwvRlIvIj48c3BhbiBz dHlsZT0nY29sb3I6IzY2NjY2Nic+Q2lzY28uY29tPC9zcGFuPjwvYT48bzpwPjwvbzpwPjwvc3Bh bj48L3A+PC90ZD48dGQgd2lkdGg9MTg2IHN0eWxlPSd3aWR0aDoxMzkuNzVwdDtwYWRkaW5nOjBj bSAwY20gMGNtIDBjbTtoZWlnaHQ6OTQuMDVwdCc+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0 eWxlPSdmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJp ZiI7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RlInPiZuYnNwOzxpbWcgYm9yZGVyPTAgd2lkdGg9MTY0 IGhlaWdodD0xMDggaWQ9IkltYWdlX3gwMDIwXzEiIHNyYz0iY2lkOmltYWdlMDA0LnBuZ0AwMUNB QzA0Ni41NThCMzJCMCI+PG86cD48L286cD48L3NwYW4+PC9wPjwvdGQ+PC90cj48L3RhYmxlPjxw IGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWls eToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO2Rpc3BsYXk6bm9uZTttc28tZmFyZWFzdC1sYW5n dWFnZTpGUic+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjx0YWJsZSBjbGFzcz1Nc29Ob3Jt YWxUYWJsZSBib3JkZXI9MCBjZWxsc3BhY2luZz0wIGNlbGxwYWRkaW5nPTAgd2lkdGg9NzE5IHN0 eWxlPSd3aWR0aDo1MzkuMTVwdCc+PHRyIHN0eWxlPSdoZWlnaHQ6OTAuOHB0Jz48dGQgd2lkdGg9 NzE5IHN0eWxlPSd3aWR0aDo1MzkuMTVwdDtwYWRkaW5nOjBjbSAxOC4wcHQgMGNtIDE4LjBwdDto ZWlnaHQ6OTAuOHB0Jz48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTo3 LjVwdDtmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIjtjb2xvcjojMDA5OTAwO21zby1m YXJlYXN0LWxhbmd1YWdlOkZSJz48aW1nIGJvcmRlcj0wIHdpZHRoPTE4IGhlaWdodD0xOSBpZD0i SW1hZ2VfeDAwMjBfMiIgc3JjPSJjaWQ6aW1hZ2UwMDMuZ2lmQDAxQ0FDMDNFLjYzQjU5M0IwIiBh bHQ9IlRoaW5rIGJlZm9yZSB5b3UgcHJpbnQuIj5UaGluayBiZWZvcmUgeW91IHByaW50Ljxicj48 YnI+PC9zcGFuPjxzcGFuIHN0eWxlPSdmb250LXNpemU6Ny41cHQ7Zm9udC1mYW1pbHk6IkFyaWFs Iiwic2Fucy1zZXJpZiI7Y29sb3I6Izk5OTk5OTttc28tZmFyZWFzdC1sYW5ndWFnZTpGUic+Q2lz Y28gU3lzdGVtcyBGcmFuY2UsIFNvY2nDqXTDqSDDoCByZXNwb25zYWJpaXTDqSBsaW1pdMOpZSwg UnVlIENhbWlsbGUgRGVzbW91bGlucyDigJMgSW1tIEF0bGFudGlzIFphYyBGb3J1bSBTZWluZSBJ bG90IDcgOTIxMzAgSXNzeSBsZXMgTW91bGluZWF1eCwgQXUgY2FwaXRhbCBkZSA5MS40NzAg4oKs LCAzNDkgMTY2IDU2MSBSQ1MgTmFudGVycmUsIERpcmVjdGV1ciBkZSBsYSBwdWJsaWNhdGlvbjog SmVhbi1MdWMgTWljaGVsIEdpdm9uZSwgRm9yIGNvcnBvcmF0ZSBsZWdhbCBpbmZvcm1hdGlvbiBn byB0bzo8YnI+PGEgaHJlZj0iaHR0cDovL3d3dy5jaXNjby5jb20vd2ViL2Fib3V0L2RvaW5nX2J1 c2luZXNzL2xlZ2FsL2NyaS9pbmRleC5odG1sIj48c3BhbiBzdHlsZT0nY29sb3I6Ymx1ZSc+aHR0 cDovL3d3dy5jaXNjby5jb20vd2ViL2Fib3V0L2RvaW5nX2J1c2luZXNzL2xlZ2FsL2NyaS9pbmRl eC5odG1sPC9zcGFuPjwvYT48L3NwYW4+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTo3LjVwdDtmb250 LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIjtjb2xvcjojMDA5OTAwO21zby1mYXJlYXN0LWxh bmd1YWdlOkZSJz48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC90ZD48L3RyPjwvdGFibGU+PHAgY2xh c3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdtc28tZmFyZWFzdC1sYW5ndWFnZTpGUic+PG86cD48 L286cD48L3NwYW4+PC9wPjwvdGQ+PC90cj48L3RhYmxlPjxwIGNsYXNzPU1zb05vcm1hbD48c3Bh biBzdHlsZT0nbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RlInPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PG86cD4mbmJzcDs8L286cD48L3A+PC9kaXY+PC9ib2R5 PjwvaHRtbD4= ------_=_NextPart_002_01CAC03D.F52E7EAC-- ------_=_NextPart_001_01CAC03D.F52E7EAC Content-Type: image/gif; name="image003.gif" Content-Transfer-Encoding: base64 Content-ID: Content-Description: image003.gif Content-Location: image003.gif R0lGODlhEgATAJEAAAAAAP///wCZAP///yH5BAEAAAMALAAAAAASABMAAAIojI+pGyK8nINqUiTf bVnfvHEg1UmhdZRqaawu6XZVjKb0/CYxo8JOAQA7 ------_=_NextPart_001_01CAC03D.F52E7EAC Content-Type: image/png; name="image004.png" Content-Transfer-Encoding: base64 Content-ID: Content-Description: image004.png Content-Location: image004.png 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_001_01CAC03D.F52E7EAC-- From trac@tools.ietf.org Wed Mar 10 04:33: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 556373A67EF for ; Wed, 10 Mar 2010 04:33:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.486 X-Spam-Level: X-Spam-Status: No, score=-102.486 tagged_above=-999 required=5 tests=[AWL=0.114, BAYES_00=-2.599, 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 pjOY6OFZMMQM for ; Wed, 10 Mar 2010 04:33:33 -0800 (PST) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 3E80E3A68E3 for ; Wed, 10 Mar 2010 04:33:33 -0800 (PST) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1NpL6Y-0007to-Bj; Wed, 10 Mar 2010 04:33:38 -0800 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: Wed, 10 Mar 2010 12:33:38 -0000 X-URL: http://tools.ietf.org/wg/roll/ X-Trac-Ticket-URL: http://svn.tools.ietf.org/wg/roll/trac/ticket/27 Message-ID: <055.c6bd3c511a71be1395c9120dcf8adad6@tools.ietf.org> X-Trac-Ticket-ID: 27 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: [Roll] [roll] #27: DAO ACK ? 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: Wed, 10 Mar 2010 12:33:34 -0000 #27: DAO ACK ? --------------------------------+------------------------------------------- Reporter: jpv@… | Owner: pthubert@… Type: task | Status: new Priority: major | Milestone: Component: rpl | Version: Severity: Active WG Document | Keywords: --------------------------------+------------------------------------------- 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. -- Ticket URL: roll From roger.alexander@ekasystems.com Wed Mar 10 05:45: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 0C7F73A6809 for ; Wed, 10 Mar 2010 05:45:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.149 X-Spam-Level: X-Spam-Status: No, score=-1.149 tagged_above=-999 required=5 tests=[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 Jbr2uN++Uo5n for ; Wed, 10 Mar 2010 05:45:24 -0800 (PST) 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 9533F3A6807 for ; Wed, 10 Mar 2010 05:45:18 -0800 (PST) Received: (qmail 69784 invoked from network); 10 Mar 2010 13:45:20 -0000 Received: from dallas (roger.alexander@209.48.242.70 with login) by smtp114.biz.mail.re2.yahoo.com with SMTP; 10 Mar 2010 05:45:20 -0800 PST X-Yahoo-SMTP: 1dQRPo6swBBzwSsRzMLy_tvdRrLDyF0J X-YMail-OSG: 8QeD414VM1ljspMqmyb9gfU7F0_pE7M0j53KHxqL9RFV9tgxaGsnX.8Fk3agubxe6COD4y7Ke9kL8nbvWH77Nt38gWoZjDkHr9j6BGQaYrQ1z2B3A_7TCeve2IJgTnfn.MTSpjceQU9zf5bXoTkPXDfmTtt90i5lU3uPcy8cPL9Ggn9Xf..c5uDkkOwYl5DPeyJcNaAW39GhnYk8NM8Yz_ovNip9si2Z4c5top6XdazFn2l09Lsdx0Jr9WprRLtoSP9ov_baDveEG9Gv1YkG7Co6bT1QzCGV.NJBjqJy_srZoN8Uw9XxUiMBtz9yctfH6geqUr30SKawb8kZmzb3NfOiQ82sL4Uc8Y6mcHp3UxfizBkS0kLlkmxoT.AQQgrn X-Yahoo-Newman-Property: ymail-3 From: "Roger Alexander" To: "'Tim Winter'" , "'ROLL WG'" References: <4B966803.5090703@acm.org> In-Reply-To: <4B966803.5090703@acm.org> Date: Wed, 10 Mar 2010 08:44:37 -0500 Message-ID: <005c01cac057$d3685bc0$7a391340$@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: Acq/nIiJt/Vd5AS8Qwe8GEVMI7zxuAAulm/Q Content-Language: en-us Subject: Re: [Roll] 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, 10 Mar 2010 13:45:25 -0000 Hi Tim, WG, I would be in favor of currently restricting RPL operation to storing and non-storing modes only. Without entirely precluding the support for a mixed mode in the future, the emphasis on storing and non-storing will allow for greater clarity and focus of the specification effort. An early system indication in the form of a control flag would be a good mechanism as it would allow a mixed mode to be introduced in the future. Roger -----Original Message----- From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Tim Winter Sent: Tuesday, March 09, 2010 10:24 AM To: ROLL WG Subject: [Roll] Establishing downward routes in RPL : storing / non-storing / mixed modes of operation WG, 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 _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From roger.alexander@ekasystems.com Wed Mar 10 05: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 B44203A67F7 for ; Wed, 10 Mar 2010 05:58:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.439 X-Spam-Level: X-Spam-Status: No, score=-0.439 tagged_above=-999 required=5 tests=[AWL=-0.711, BAYES_00=-2.599, 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 3-60n9Ibp-Ck for ; Wed, 10 Mar 2010 05:58:43 -0800 (PST) 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 467B93A67CC for ; Wed, 10 Mar 2010 05:58:43 -0800 (PST) Received: (qmail 1631 invoked from network); 10 Mar 2010 13:58:45 -0000 Received: from dallas (roger.alexander@209.48.242.70 with login) by smtp111.biz.mail.re2.yahoo.com with SMTP; 10 Mar 2010 05:58:45 -0800 PST X-Yahoo-SMTP: 1dQRPo6swBBzwSsRzMLy_tvdRrLDyF0J X-YMail-OSG: aa2vAdAVM1kQdTce5U3TadJmI_lRB6LowdQXfN.8fNL1nGN9f1CgGUg414zZJDOOu8OaL9LJy8FcRnaDUV6XJqj75r.XH4c1KWoO.JQmfZc0m4QmMFJwSVBYjdtMuIGJs1ATR5rs7i9OQwbY6mmKkCwJ8sXStmJJUss1PiFqQep2Fdt8IKbVjYRzID9WWhPXuizj927JYPlJ9hBwxGwA1BUJv.9AM4WQbkMuh2z7BzAOzVtJ4lK9U24rZHFjhX.bR67nDhgbDheQUYNoWB4953BtC76Rdn9OPgI.4RTw9WKSpb_aVZIRXnz8g95eADic6tKh.ji3IoerQdZUkOXT2TVELd259XmAaOf_KDmlKaKux.PCTXYor..Xki5G9gfZ X-Yahoo-Newman-Property: ymail-3 From: "Roger Alexander" To: "'Pascal Thubert \(pthubert\)'" , References: <6A2A459175DABE4BB11DE2026AA50A5D016982C5@XMB-AMS-107.cisco.com> In-Reply-To: <6A2A459175DABE4BB11DE2026AA50A5D016982C5@XMB-AMS-107.cisco.com> Date: Wed, 10 Mar 2010 08:58:01 -0500 Message-ID: <006301cac059$b2da3e30$188eba90$@alexander@ekasystems.com> MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_NextPart_000_0064_01CAC02F.CA043630" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcrAPfPIyxeYBGuWTw+gDRQ3zVwt/QAGegBQ 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: Wed, 10 Mar 2010 13:58:44 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0064_01CAC02F.CA043630 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0065_01CAC02F.CA043630" ------=_NextPart_001_0065_01CAC02F.CA043630 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable 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_0065_01CAC02F.CA043630 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

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_0065_01CAC02F.CA043630-- ------=_NextPart_000_0064_01CAC02F.CA043630 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_0064_01CAC02F.CA043630 Content-Type: image/gif; name="image002.gif" Content-Transfer-Encoding: base64 Content-ID: R0lGODlhEgATAJEAAAAAAP///wCZAP///yH5BAEAAAMALAAAAAASABMAAAIojI+pGyK8nINqUiTf bVnfvHEg1UmhdZRqaawu6XZVjKb0/CYxo8JOAQA7 ------=_NextPart_000_0064_01CAC02F.CA043630-- From phoebus@ieee.org Wed Mar 10 06:30: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 917233A6BD6 for ; Wed, 10 Mar 2010 06:30:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.249 X-Spam-Level: X-Spam-Status: No, score=-106.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YTpuuk-aU1eQ for ; Wed, 10 Mar 2010 06:30:15 -0800 (PST) Received: from smtp-1.sys.kth.se (smtp-1.sys.kth.se [130.237.32.175]) by core3.amsl.com (Postfix) with ESMTP id AAD983A6809 for ; Wed, 10 Mar 2010 06:30:14 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by smtp-1.sys.kth.se (Postfix) with ESMTP id 56329156E84; Wed, 10 Mar 2010 15:29:48 +0100 (CET) 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 lA-KJwhHl3Dg; Wed, 10 Mar 2010 15:29:45 +0100 (CET) X-KTH-Auth: phoebus [2002:82ed:2bf4:b:223:dfff:fe92:5e5c] X-KTH-mail-from: phoebus@ieee.org Received: from dhcp-50-62.s3.kth.se (unknown [IPv6:2002:82ed:2bf4:b:223:dfff:fe92:5e5c]) by smtp-1.sys.kth.se (Postfix) with ESMTP id 8FD001558B1; Wed, 10 Mar 2010 15:29:45 +0100 (CET) Message-ID: <4B97ACD8.90505@ieee.org> Date: Wed, 10 Mar 2010 15:29:44 +0100 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.8) Gecko/20100227 Thunderbird/3.0.3 MIME-Version: 1.0 To: "Pascal Thubert (pthubert)" , "roll@ietf.org" References: <4B952B5D.1010907@ieee.org> <6A2A459175DABE4BB11DE2026AA50A5D0169808D@XMB-AMS-107.cisco.com> In-Reply-To: <6A2A459175DABE4BB11DE2026AA50A5D0169808D@XMB-AMS-107.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Roll] RPL spec v6 and OF0 draft v1: Identifying what needs to be specified in an Objective Function 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: Wed, 10 Mar 2010 14:30:20 -0000 Hi Pascal, Yes, I'd love to see the WG address some of these issues in detail. Please see my comments below. -- Phoebus Chen Postdoctoral Researcher Automatic Control Lab, KTH (Royal Institute of Technology) http://www.ee.kth.se/~phoebus On 3/9/10 7:15 PM, Pascal Thubert (pthubert) wrote: > Hi Phoebus, > > These are all good points. Too many fore a single thread, and probably > some to be taken as tickets to attract a better WG attention. > In short, what is the separation between OF and RPL, should we specify > an abstract interface, and what's left to implementation. > > Please see below > > >> I've been looking over draft-ietf-roll-of0-01 and >> draft-gnawali-roll-etxof-00 to help get a sense of which items left to > be >> "specified by the implementation / implementation-dependent" in >> draft-ietf-roll-rpl-06 are to be specified by the objective function. >> My understanding is that of0 will eventually serve as a template for > how >> future objective function specifications should be written (together > with >> Section 10 of draft-ietf-roll-rpl-06, which will indicate what MUST be > specified >> by an OF). >> >> OF0 currently is tasked to specify: >> 1) selection of parents and siblings >> 2) how to compute the rank > > Correct, at least as far as I understand it. > >> I suggest that some sections be added, maybe as placeholders for now, > to >> specify: >> 1) The format/fields of the Objective Code Point, following the OCP > object >> format from the ROLL routing metrics document > (draft-ietf-roll-routing- >> metrics-04, pg. 24, Sec. 6, Fig. 19). This is especially important > because it >> indicates what parameters of the Objective Function are left for > tuning. For >> instance, it is hard to spot the optional preference in > (draft-ietf-roll-of0-01, >> pg. 5, Sec. >> 3.2, point #8). > > The preference is in the DIO base format. My expectation is that the OF > gets the DIOs to play with. > I see that I need to align the OF text with the RPL text. Will do in > next revision. > > " DODAGPreference (Prf): A 3-bit unsigned integer that defines > how preferable the root of this DODAG is compared to > other DODAG roots within the instance. DAGPreference > ranges from 0x00 (least preferred) to 0x07 (most > preferred). The default is 0 (least preferred). > Section 5.3 describes how DAGPreference affects DIO > processing. > " Oh, I see. Yes, a reference to the DODAGPreference field in the RPL document would help here. > > >> 2) The rules for how a node decides to "defer" joining or migrating to > a new >> DODAG iteration. I believe this has a large impact on how well a > DODAG >> iteration optimizes a metric. If this is arbitrary and left up to > each vendor to >> implement separately, there is no reason to expect that the nodes in > the >> network will cooperate to reach an optimum DODAG. >> I'm referring to (draft-ietf-roll-rpl-06, pg. 34, Sec. 5.3.3.4): >> "An implementation could defer to migrate for some reasonable amount > of >> time, to see if some other neighbors with potentially better metrics > but >> higher rank announce themselves." > > Yes, I think we need a ticket for this one, to discuss when to actually > jump. Thomas Clausen and I just discussed that same question a few days > ago. > >> 3) What constitutes a redundant DIO message. This determines which > nodes >> that have joined the DODAG iteration can talk, and thus the set of > candidate >> neighbors that a node can choose as a parent. I'll send a follow up > email >> elaborating my thoughts on this. >> I'm referring to (draft-ietf-roll-rpl-06, pg. 38, Section 5.3.5.1.1): >> "The exact determination of what constitutes a redundant DIO message > is >> left to an implementation; it could for example include DIOs that > advertise >> the same rank." > > If you ask me, you'll get one answer. You've seen from Richard's answer > that there is no easy one. > For reference, my answer is what's really redundant is the role of > router, so we could use trickle to elect routers upon new sequences. > See from http://www.ietf.org/mail-archive/web/roll/current/msg02573.html > > Then again, I am not sure that the RPL spec has the full and correct > answer and that deserves a ticket to see what the group thinks. > >> 4) How the metric used by this OF may be considered inconsistent, for > the >> sake of the Trickle timer. >> I'm referring to (draft-ietf-roll-rpl-06, pg. 38, Sec. 5.3.5.1.2): >> "A metric communicated in the DIO message is determined to be >> inconsistent, as according to a implementation specific path metric > selection >> engine." > > Probably the same ticket as above... > >> 5) The rules for a node to choose which DODAG to join, when it has > multiple >> choices within an RPLInstance. I'm guessing that in most cases it is > only >> specified by the DODAGPreference field in the DIO Base Option, but the >> rules should be made explicit for each OF. >> I'm referring to (draft-ietf-roll-rpl-06, pg. 33, Sec. 5.3.3.3.) "If a > node has the >> option to join a more preferred DODAG while still meeting other > optimization >> objectives, then the node will generally seek to join the more > preferred >> DODAG as determined by the OF." > > I'm not sure what more you need here? Once a node joins an instance that > runs a give OF, the OF is responsible to decide the movements within the > DAG for that instance. I hope that OF0 does that clearly, if not, we > need to work out improvements. I do not see what's missing in the base > spec here? > I did not mean that the base spec (draft-ietf-roll-rpl-06) needed to be revised. I was suggesting that you create a new section within OF0 to address how it uses the DODAGPreference field to choose between different DODAGs. Now that I understand (draft-ietf-roll-of0-01, pg. 5, Sec. 3.2, point #8) was for DODAGPreference, I see that you can just break out point #8 into its own section. I think this makes it easy for the reader, to separate choosing a preferred parent within a DODAG from choosing which DODAG to join, although the two are interrelated. >> and also (draft-ietf-roll-rpl-06, pg. 39, Sec. 5.3.6): >> "The DODAG selection is implementation and algorithm dependent. Nodes >> SHOULD prefer to join DODAGs for RPLInstanceIDs advertising OCPs and >> destinations compatible with their implementation specific > objectives." > > Maybe we should just remove this text? What I think is that there is a > need to join a default instance (0) in order to get more info on the > environment (like discuss to some management entity) and from there, > join more instances as appropriate. All this is out of scope, but the > mandate to support an instance 0 with OF 0 could be added. What do you > think? > I thought that the leaf node functionality described in (draft-ietf-roll-rpl-07, pg. 39-40, Sec. 5.4) was for management purposes. Maybe it's not sufficient. Let me outline what I see as possible concerns. 1) The RPLInstances that have been installed might not be good for management. For instance, if the installed RPLInstances had OFs that did not account for reliability, many of the management packets might be lost. Or maybe the latencies for the installed RPLInstances are too large for a management user interface (humans managing the nodes would get impatient waiting for a response). 2) If there are multiple RPLInstances, nodes may join different RPLInstances as leaf nodes, expecting to be managed. This can create a slight headache for the network operator (or network management software), who now has to use more than one RPLInstance to manage all the nodes in his network. A counterargument to this is that there might be deployments where you need to use different RPLInstances to manage different sets of nodes anyways. The (weak) example I have is with path diversity in a DODAG without siblings... with a single DODAG, there might be some nodes that help other nodes forward packets but do not have many nodes that would help them forward packets (there is at least one node besides the sink in every DODAG that has no one else forwarding packets for him). A second RPLInstance can be built to provide path diversity for these nodes. Here is what I see as possible solutions besides a mandate to support instance 0 with OF 0: 1) Maybe designating instance 0 as the "management instance" that all nodes must join, even if it is not associated with OF0, is good enough. Since nodes can always join as leaves, they don't have to understand the OF. A network operator might have a better OF than OF0 for managing his deployment and for his network traffic. If this is the case, he can save memory on the nodes by not having them maintain another RPLInstance. 2) Overload the use of the DODAGPreference (or create another RPLPreference field), to let the network operator specify which RPLInstance the nodes should try to join if the nodes cannot join all the available RPLInstances in the network because of memory constraints. The management RPLInstance would advertise the highest preference. Hopefully there is only one network operator managing the network... I'm not sure how you would resolve conflicts if multiple network operators tried to manage the network. > >> 6) The rules for how a node decides to jump to another DODAG. This > should >> be related to the value of the node's metric and rank. >> I'm referring to (draft-ietf-roll-rpl-06, pg. 34, Sec. 5.3.3.4): >> "A node MAY, at any time, choose to join a different DODAG within a > RPL >> Instance." > > Some OF might be 'sticky' for instance if the root is a collection > point. Others might just optimize the metrics and the preference. > There must be logic that ties the whole thing in, and that logic is the > core of the OF. > >> 7) What triggers the parent selection process. As I understand, a > node is >> allowed to change parents within a DODAG iteration, so long as it does > not >> violate any rank constraints. If the trigger for the parent selection > process is >> the same across all OFs, then it should be made clear in the RPL core >> specification (the current wording is ambiguous). >> I'm referring to (draft-ietf-roll-rpl-06, pg. 58, Sec. 10): >> "The parent selection is triggered each time an event indicates that a >> potential next hop information is updated. This might happen upon the >> reception of a DIO message, a timer elapse, or a trigger indicating > that the >> state of a candidate neighbor has changed." >> I also suggest that (draft-ietf-roll-of0-01, pg. 4, Sec. 3.1) be > broken up into >> separate sections: >> * the general description of the goal >> * a placeholder for how to compute the metric (even if it is > irrelevant here >> since there is no metric) >> * the rules for computing the rank >> * how to use administrative preference > > OF0 is an example for sure, but the spec is not THE schema that all OFs > should follow, though. > OK. I thought it would be nice to use OF0 as THE schema, putting "Not Applicable" in sections as appropriate. It allows the readers to compare OF's really quickly, to see what is there and what is missing. >> The rules for computing the rank should also include a sentence or a >> subsection on how and when administrative rank is to be used to adjust > the >> rank computed from the objective function. Or it should say that it > is not >> used. The guidelines for writing OFs in (draft-ietf-roll-rpl-06, pg. > 58, Sec. 10) >> should say that administrative rank must be addressed in an OF > specification. >> I'm referring to (draft-ietf-roll-rpl-06, pg. 39, Sec. 5.5) "In some > cases it might >> be beneficial to adjust the rank advertised by a node beyond that > computed >> by the OF based on some implementation specific policy and properties > of >> the node." > > Good point. I'm not sure whether OF0 has anything special there though. > Maybe a ticket against OF0 wold be appropriate. > >> I'm not sure if it's necessary to have a separate "Advertise the > metric" >> section, like in (draft-gnawali-roll-etxof-00, pg. 6, Sec. 3.3), or if > it can be >> merged into a section on how to compute the metric. The way I think > of OFs, >> a node decides on a single metric and rank, and that is what it is > always >> advertised. Also, is the propagation of metrics different from OF to > OF? >> Otherwise, change the text in the RPL core >> spec: (draft-ietf-roll-rpl-06, pg. 27, Sec. 5.1.3.4) "The processing > and >> propagation of the Metric Container is governed by implementation > specific >> policy functions." > > Hum, could you reword that? Do you really mean single? The logic in the > OF enables to tie policies with multiple metrics and other > administrative and non-administrative information. The metrics > propagation belongs to the metrics draft, not the OF. > I was wrong. I was thinking single metric because oftentimes, to choose between parents, one compares a scalar value (maybe a weighted combination of several metrics) computed for one node with the scalar value computed for another node. But you're right, there is no limitation that a node only sends a single metric and a single rank in its DIO advertisements. I see, "propagation of the metric container" refers to whether it is global or local (only one hop). I got mixed up by the words "implementation specific policy functions," thinking this was something addressed in the OF documents. In this case, I guess an "advertise the metric" section is necessary to explain what metrics to mark as local and what metrics to mark as global (and if it is recorded, aggregated, etc.). >> Another point for consideration is whether the rules for how a node > decides >> to lower its rank should be made explicit in a separate section from > the >> "Preferred Parent Selection" section. I'm not sure myself. >> I'm referring to (draft-ietf-roll-rpl-06, pg. 34, Sec. 5.3.3.4): >> "When a node moves to improve its position,... Such a movement may > occur >> at any time to decrease the rank, as per the calculation indicated by > the OF." >> >> I didn't understand if there are separate OFs for upwards or downwards >> routing... whether there should be placeholder sections for DAO rank, > DAO >> metrics, etc. I suppose this has yet to be decided. > > Routing downwards happen along a DAG that is decided by the OF. The OF > might be selecting a parent as DAO parent for metrics that indicate a > good down path rather than a good up path. So ultimately, you could > think of an OF as being split in 2, one up, one down, as you figured. > You could even have a different set of parents for up and down routes. > > Still at the moment, we form a single DAG, not a DAG for UP routes and a > DAG for down routes, which seemed overly complex. So there's a single > Rank as opposed to an up Rank and a down Rank. And all the DAOs will > circulate along the reverse DAG. So we do not need DAO metrics to avoid > loops, the loops are already avoided by the DAG construction. DAO > metrics can still be useful to select a shorter path within the loopless > DAG, allow a better load balancing, etc... and they are are described in > Section 5.1.3.4. I see that as an optimization that might or might not > be very useful, depending on the DAG. It is certainly useless if DAOs > only follow a tree of preferred DAO parents. > Thanks for the clarification. I'll have to read over RPL v7 and digest what is going on with Downwards routing. > Thanks for all your very pertinent comments, > > Pascal > >> >> -- >> Phoebus Chen >> Postdoctoral Researcher >> Automatic Control Lab, KTH (Royal Institute of Technology) >> http://www.ee.kth.se/~phoebus >> >> >> >> P.S. >> >> There are some mechanisms in the RPL specification marked as >> "implementation-dependent" that may not belong in an objective > function. >> Some of these are mentioned in (draft-ietf-roll-rpl-06, Sec. 11 and >> 12). I see these sections as also serving the purpose of helping an >> implementer keep track of what he needs to tune (and what he may have >> implemented differently from other implementers, if their >> implementations turn out to be incompatible or interact in > unpredictable >> ways). I've tried to list some of the "implementation-dependent" >> mechanisms mentioned in the document that were missed in Sections 11 >> and >> 12. It might also help the reader to separate out what can be tuned >> over the network via messages (besides the ones defined thus far) and >> what is only tuned on the devices before deployment. >> >> Poisoning Interval >> (draft-ietf-roll-rpl-06, pg. 14, Sec. 3.4.2) >> "Such a move may be undertaken after waiting an appropriate poisoning >> interval, and should allow the node to restore connectivity to the > DODAG >> Iteration, if at all possible." >> >> Selection of the candidate neighbors (indirectly mentioned in Sec. > 12.3.1) >> (draft-ietf-roll-rpl-06, pg. 30, Sec. 5.3.2) >> "The exact policies for selecting neighbors and parents is >> implementation-dependent." >> >> Whether to forward packets to future parents >> (draft-ietf-roll-rpl-06, pg. 32, Sec. 5.3.3.1) >> "During transition to a new DODAG Iteration, a node may decide to >> forward packets via 'future parents' that belong to the same DODAG >> (same RPLInstanceID and DODAGID), but are observed to advertise a >> more recent (incremented) DODAGSequenceNumber." >> >> Whether to poison a sub-DAG before increasing rank and moving, or form > a >> floating DODAG >> (draft-ietf-roll-rpl-06, pg. 34, Sec. 5.3.3.4) >> "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." >> (draft-ietf-roll-rpl-06, pg. 35, Sec. 5.3.3.5) >> "An implementation may choose to employ this poisoning mechanism when >> a node loses all of its current parents, i.e. the set of DODAG >> parents becomes depleted, and it can not jump to an alternate DODAG. >> An alternate mechanism is to form a floating DODAG." >> >> Risk Window >> (draft-ietf-roll-rpl-06, pg. 40, Sec. 5.6) >> "It left to the implementation to define the duration of the risk > window." >> _______________________________________________ >> Roll mailing list >> Roll@ietf.org >> https://www.ietf.org/mailman/listinfo/roll From alexandru.petrescu@gmail.com Wed Mar 10 09:24: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 686733A6BDB for ; Wed, 10 Mar 2010 09:24:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.199 X-Spam-Level: X-Spam-Status: No, score=-2.199 tagged_above=-999 required=5 tests=[AWL=0.050, 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 foSXwP2U8PHw for ; Wed, 10 Mar 2010 09:24:38 -0800 (PST) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.166.172.106]) by core3.amsl.com (Postfix) with ESMTP id CED0C3A6A93 for ; Wed, 10 Mar 2010 09:24:37 -0800 (PST) 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 o2AHOdRS031212 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 10 Mar 2010 18:24:39 +0100 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.2/8.14.2) with ESMTP id o2AHOdPA015414; Wed, 10 Mar 2010 18:24:39 +0100 (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 o2AHOd9a001253; Wed, 10 Mar 2010 18:24:39 +0100 Message-ID: <4B97D5D7.5050909@gmail.com> Date: Wed, 10 Mar 2010 18:24:39 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.9.1.8) Gecko/20100227 Thunderbird/3.0.3 MIME-Version: 1.0 To: dominique.barthel@orange-ftgroup.com References: <055.28872d5d0fcf65e6839f1cd72771083c@tools.ietf.org><064.2a20a25a31ddeb41de55f5c2ba559806@tools.ietf.org><4B90DF6D.9070806@gmail.com><4B94D55E.7080302@gmail.com> <8E09C72DBC577D489F13A71228C0B7BF0105150F@ftrdmel0.rd.francetelecom.fr> In-Reply-To: <8E09C72DBC577D489F13A71228C0B7BF0105150F@ftrdmel0.rd.francetelecom.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: roll@ietf.org Subject: Re: [Roll] [roll] #18: Numeric Ranges in Routing Metric X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 10 Mar 2010 17:24:39 -0000 Le 10/03/2010 09:07, dominique.barthel@orange-ftgroup.com a écrit : > Hi all, > > I disagree with option 3. This is just another "floating point" > format, with a one-bit exponent and a 15-bit mantissa. If IEEE 16-bit > FP was rejected, this one should be rejected for the same reasons. > > Again, I favor option 2, but instead of microsecond increments, which > is a resolution we don't need, I suggest using 10 us increments, > which pushes the full range to about 168 seconds. That is a smart way of increasing the overall range, I think. > Again, you can't measure the link latency with a resolution smaller > than 10us, if only because of random back-off delays or mere > electrical symbol duration. Not sure about the impossibility of measuring a less-than-10us precision of less-than 10us. The linux kernel time struct (and tv in userspace) is expressed in 1us precision range. An off-the-shelf "ping" on linux on wired Ethernet 100Mbps reports RTTs like "0.384 ms" which makes it for precision of units of micro-second. The situation with a wireless 802.11g is similar. YEs precise measuring should account for backoff delays and electrical symbol representations too, with average and statistical tools. Alex > > > Dominique > > > -----Message d'origine----- De : roll-bounces@ietf.org > [mailto:roll-bounces@ietf.org] De la part de MiJeom Kim Envoyé : > mercredi 10 mars 2010 02:57 À : Alexandru Petrescu Cc : > roll@ietf.org Objet : Re: [Roll] [roll] #18: Numeric Ranges in > Routing Metric > > Hi, Alex, > > The problem you mentioned regarding option 3 can be easily solved. We > can just set the rule that whenever possible, using microsecond > instead of millisecond to give more information (precision). So upto > 32767 miroseconds, uses microsecond and if latency becomes greater > than that, uses millisecond. I had considered that removing the > overlapping part, but that makes the format more complicated. > > Mijeom. > > > On Mon, Mar 8, 2010 at 7:45 PM, Alexandru > Petrescu wrote: >> Le 08/03/2010 02:24, MiJeom Kim a écrit : >>> >>> Hi, >>> >>> Actually, we were in the middle of discussion. Let me resummerize >>> the final options we have until now. >>> >>> 1. 16 bit unsigned integer --> it's not enough to express all >>> cases since 65535 micro seconds (65 milliseconds) >> >> Ok I guess we need to discard this. >> >>> 2. 24 bit unsigned integer >> >> This could represent >> >> 0..16777216 microseconds i.e. 0..16777,216 milliseconds i.e. 0.. >> 16,777216 seconds delay. >> >>> 3. 1 bit indication bit (to indicate millisecond or mirocsecond) >>> + 15 bit insigned integer --> the range can be from 0 >>> microseconds to 32767 milliseconds. >> >> Right, the range of representation could be wider than with the >> 24bit integer(?) >> >> But there a same value could be represented by two different >> encodings. This makes comparisons for equality longer to write in >> C, requires normalization before each comparison. >> >> I.e. 1 millisecond could be represented by somebody as >> 1000micro-seconds, and when comparing the two values it's not >> sufficient to simply compare the 16bit values received in >> messages, one has to normalize first (similar to when one has to >> apply ntohs before every comparison of shorts received from the >> wire). >> >> Tradeoffs tradeoffs... >> >> Alex >> >>> >>> Thanks, Mijeom. >>> >>> >>> On Fri, Mar 5, 2010 at 7:39 PM, Alexandru Petrescu >>> wrote: >>>> >>>> Le 05/03/2010 11:36, roll issue tracker a écrit : >>>>> >>>>> #18: Numeric Ranges in Routing Metric >>>>> >>>>> >>>>> --------------------------------+---------------------------------- >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> --------------------------------+--------- >>>>> >>>>> >>>>> >>>>> >> Reporter: jpv@... | Owner: mjkim@... >>>>> >>>>> Type: defect | Status: closed Priority: >>>>> minor | Milestone: Component: >>>>> routing-metrics | Version: Severity: Active WG Document | >>>>> Resolution: fixed Keywords: | >>>>> >>>>> >>>>> --------------------------------+---------------------------------- >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> --------------------------------+--------- >>>>> >>>>> >>>>> >>>>> >> Changes (by jpv@...): >>>>> >>>>> * status: new => closed * resolution: => fixed >>>>> >>>>> >>>>> Comment: >>>>> >>>>> Here is the resolution after discussion on the mailing list: >>>>> >>>>> It's time to close on the #18. I think that throughput and >>>>> latency can be better presented by unsigned integers as the >>>>> below justification wrote. Latency can be expressed in units >>>>> of milliseconds >>>> >>>> But we just seemed to agree on micro-seconds instead, haven't >>>> we? >>>> >>>> Alex >>>> >>>> >>>> and throughput can >>>>> >>>>> be expressed in bytes per second. >>>>> >>>>> Mijeom. >>>>> >>>> >>>> >>>> _______________________________________________ Roll mailing >>>> 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 Wed Mar 10 09:48: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 BE5D73A6BFB for ; Wed, 10 Mar 2010 09:48:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.203 X-Spam-Level: X-Spam-Status: No, score=-2.203 tagged_above=-999 required=5 tests=[AWL=0.046, 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 5UMV6upAQn1p for ; Wed, 10 Mar 2010 09:48:51 -0800 (PST) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.1]) by core3.amsl.com (Postfix) with ESMTP id E9C483A68E5 for ; Wed, 10 Mar 2010 09:48:50 -0800 (PST) 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 o2AHmrsR006580 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 10 Mar 2010 18:48:54 +0100 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (8.14.2/8.14.2) with ESMTP id o2AHmrIf019818; Wed, 10 Mar 2010 18:48:53 +0100 (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 o2AHmrdD011139; Wed, 10 Mar 2010 18:48:53 +0100 Message-ID: <4B97DB85.2090800@gmail.com> Date: Wed, 10 Mar 2010 18:48:53 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.9.1.8) Gecko/20100227 Thunderbird/3.0.3 MIME-Version: 1.0 To: roll@ietf.org References: <1268091651.1955.155.camel@dellx1> In-Reply-To: <1268091651.1955.155.camel@dellx1> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [Roll] RIPless metrics (was: [Fwd: New Version Notification for draft-mulligan-roll-ripless-01]) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Mar 2010 17:48:52 -0000 Hello, I am happy this draft draft-mulligan-roll-ripless-01 exists, because it relies on widely available software and deployments. Are you requesting comments? I have one comment with respect to the metrics section "6.1. Routing Metric": " The routing metric described in the RIP RFCs is a simple hop-count. It is thought in the RF sensor networking community (???need reference???) that just a simple hop count is insufficient to properly determine the "best path" between two nodes. It is suggest here that a weighted hop-count might provide a better metric. The hop-count would be weighted by the RSSI/LQI value for the link between each node." I am not sure a unique metric, be that hopcount weighted by RSSI, is enough to express various other needs like energy expenditure to send packets on a particular link. > The specific weighting could be implementation specific, but for an > IEEE 802.15.4 [9] type network using 8 discrete LQI values links with > an LQI of 0x00 and 0x01 might have the metric set to "infinite", LQIs > of 0x02 through 0x05 would set metric to 2 and an LQI of 0x06 or 0x07 > would use the standard metric value of 1. If the implementor would > rather use RSSI values or more values in LQI (256) are available some > different step funtion might be use. Hmmm... I would avoid filling up so many values of that RIP 8bit metric value. Out of 255 values about 238 are left free. I would only take 1 value "0xfe", call it "energy metric encoded in RIPng RTE", as described in the paragraphs below. Alex > 5. Energy Metric Encoded in RIPng RTE > > A RIPng packet can be depicted as follows: > > > +-----------+ +-----------------+ +---+ +----+ > |Base Header| ...|Extension Headers| |UDP| ...|RTEs| > +-----------+ +-----------------+ +---+ +----+ > > > A RIPng packet contains a list of RTEs (Route Table Entries) as > explained in [RFC2080] "RIPng for IPv6". An 'address' RTE contains a > 128 bit address, an 8 bit route tag, an 8 bit prefix length and an 8 > bit metric (all for 20bytes). A 'next hop' RTE is an RTE with a > metric value of 0xFF. Many 'address' RTEs (actually, prefixes) > correspond to a single 'next hop' RTE. > > The existing 8-bit metric value is used to express metrics between 1 > and 15, thus determining the potential size of a RIPng routing > domain. We propose to reserve the value 0xFE for an 'energy' metric > within an address RTE. > > The energy RTE relates to the immediately preceding address RTE. A > typical sequence of RTEs would be as depicted in the figure below: > > > +-----------+ +------------++-----------+ +------------++-----------+ > |NextHop1RTE| |Address1 RTE||Energy1 RTE| |Address2 RTE||Energy2 RTE| > +-----------+ +------------++-----------+ +------------++-----------+ > > > This sequence should be interpreted as follows: for any destination > address longest-prefix matching the prefix in Address1 RTE, the > energy metric is in Energy1 RTE and the next hop address is in Next > Hop1 RTE. The same for Address2 RTE and Energy2 RTE. > > The bit layout of the Energy RTE 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 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Max Energy Send | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Min Energy Send | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Max Energy Receive | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Min Energy Receive | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | route tag (2) | prefix len (1)| Energy Metric | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > Max Energy Send > > Single-precision 32bit floating point number in binary > interchange format (see [IEEE754-2008] and [IEC60559-2.0]), a > C 'float' type (see [ISOIEC-C99]), in network byte order. > The value represents the maximum energy, expressed in Joules, > necessary to send an IP packet of size 1280 bytes to any > address valid on the IPv6 prefix of the immediately preceding > address RTE. This is the sum of the max energy values needed > to transmit this packet on each intermediary IPv6 Link. > > Min Energy Send > > Single-precision 32bit floating point number in binary > interchange format (see [IEEE754-2008] and [IEC60559-2.0]), a > C 'float' type (see [ISOIEC-C99]), in network byte order. > The value represents the minimum energy, expressed in Joules, > necessary to send 1280 bytes to any address valid on the IPv6 > prefix of the immediately preceding address RTE. This is the > sum of the min energy values needed to transmit this packet > on each intermediary IPv6 link. > > Max Energy Receive > > Single-precision 32bit floating point number in binary > interchange format (see [IEEE754-2008] and [IEC60559-2.0]), a > C 'float' type (see [ISOIEC-C99]), in network byte order. > The value represents the maximum energy, expressed in Joules, > necessary to receive 1280 bytes from any address valid on the > IPv6 prefix of the immediately preceding address RTE. This > is the sum of the max energy values needed to receive this > packet on each intermediary IPv6 link. > > > Min Energy Receive > > Single-precision 32bit floating point number in binary > interchange format (see [IEEE754-2008] and [IEC60559-2.0]), a > C 'float' type (see [ISOIEC-C99]), in network byte order. > The value represents the minimum energy, expressed in Joules, > necessary to receive 1280 bytes from any address valid on the > IPv6 prefix of the immediately preceding address RTE. This > is the sum of the min energy values needed to receive this > packet on each intermediary IPv6 link. > > route tag > > Set to 0 by sender, ignored by receiver. > > > prefix len > > Set to zero by sender and ignored by receiver. > > > Energy Metric > > Energy Metric for IPv6 Links. > > TBA > > We are not aware of IANA assignments for this metric field, > althtough IANA does maintain RIP Message Types at > http://www.iana.org/assignments/rip-types > > We propose this field to contain 0xFE. Existing values of > which we are aware are: 0, 1, ... 15, 0XFF. > > Le 09/03/2010 00:40, Geoff Mulligan a écrit : > I don't think my previous message about -00 made it to the list. > > geoff > > PS- I didn't spell successfully incorrectly below :-) Other spelling > errors are all mine. > > From: IETF I-D Submission Tool > To: geoff@proto6.com > Subject: New Version Notification for draft-mulligan-roll-ripless-01 > Date: Mon, 8 Mar 2010 15:29:52 -0800 (PST) > > A new version of I-D, draft-mulligan-roll-ripless-01.txt has been successfuly submitted by Geoffrey Mulligan and posted to the IETF repository. > > Filename: draft-mulligan-roll-ripless > Revision: 01 > Title: Optimized RIP for embedded RF networks > Creation_date: 2010-03-08 > WG ID: Independent Submission > Number_of_pages: 12 > > Abstract: > This document specifies an optimization to the Routing Information > Protocol (RIP) routing protocol for use in embedded RF IPv6 internets > such as those used in 6lowpan [7] networks. RIPless specifies the > minimal changes to RIP, as specified in RIPng [2], RIP [3] and RIPv2 > [4] to allow the protocol to be used in a "lossy" RF networks where > the routing fabric of the network is built upon powered nodes and > that only the edge devices may be battery powered. > > > > The IETF Secretariat. > > > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > From anders.jagd@gmail.com Wed Mar 10 09:59: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 4EED13A6C0A for ; Wed, 10 Mar 2010 09:59:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.888 X-Spam-Level: X-Spam-Status: No, score=-1.888 tagged_above=-999 required=5 tests=[AWL=-0.710, BAYES_00=-2.599, HTML_MESSAGE=0.001, SARE_GIF_ATTACH=1.42] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qc04a18jZiuf for ; Wed, 10 Mar 2010 09:59:14 -0800 (PST) Received: from mail-pv0-f172.google.com (mail-pv0-f172.google.com [74.125.83.172]) by core3.amsl.com (Postfix) with ESMTP id 04ABD3A69DA for ; Wed, 10 Mar 2010 09:59:13 -0800 (PST) Received: by pvg2 with SMTP id 2so2980168pvg.31 for ; Wed, 10 Mar 2010 09:59:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=yqxCaDCJK1WlznRbwj9giYgs9goXvx0YoSwgiE7Ivdo=; b=qfEHhrhmgwiqvABqVJGPYwllDh/ewvXp0wbX12uhJFPPwDDBpV2MJx3/+/OjJuCSP4 aIuVxdX+bZtg6T2C+n12tSzrQGAW/f2uxOm6VDgNUr7n8wlBgnyKjjOlta+Mc5ARVqOS 5Q/xalazXhQImjnjmfW5Ar+aTJNff+kCGXD1s= 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=wbnra2Cy6XJ2VOd8hfpUdbqVFtjjwzDjQTDvdKtyeqb1fuAiSdb6Cz2aWsfkngDcIc l0MUk4v6yBWtDnVmfLosn1mssb5XW1DzUVgzeoYIuEae8e3nKp7cSe1NaG0FcDuk0sED JXOxnQJjCHpEJHMzoVGfbFktZjps2KBrGRCDY= MIME-Version: 1.0 Received: by 10.143.24.18 with SMTP id b18mr642295wfj.16.1268243955758; Wed, 10 Mar 2010 09:59:15 -0800 (PST) In-Reply-To: <6A2A459175DABE4BB11DE2026AA50A5D016982C5@XMB-AMS-107.cisco.com> References: <6A2A459175DABE4BB11DE2026AA50A5D016982C5@XMB-AMS-107.cisco.com> Date: Wed, 10 Mar 2010 12:59:15 -0500 Message-ID: <77b524e41003100959j74612e4of292193772b75c0c@mail.gmail.com> From: Anders Jagd To: "Pascal Thubert (pthubert)" Content-Type: multipart/related; boundary=001636e0acda78b53e0481760ea8 Cc: roll@ietf.org 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: Wed, 10 Mar 2010 17:59:15 -0000 --001636e0acda78b53e0481760ea8 Content-Type: multipart/alternative; boundary=001636e0acda78b53c0481760ea7 --001636e0acda78b53c0481760ea7 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Pascal, WG, Not sure I agree with a requirement for a RPL level ACK to the DAO. As you discuss, if a parent (or the root) is requesting the information, there are mechanisms in place already to trigger retries/refresh (not all timers necessarily worked out yet, but state machine and DTSN mechanism is there). So, this deals with the situation where a child node is volunteering the information rather responding to a request from the parent. I hope I understand this right, otherwise please let me know. Typically, upon learning of a new child node, the above DTSN based DAO trigger mechanism should start. However, if a node wants to issue an unsolicited DAO, I don't see anything wrong with doing so, and then, if no trigger arrives (DTSN based or otherwise) within a reasonable time (again, timers are not defined by RPL, but could/would be by the Object Function), it could assume the unsolicited DAO was not received and retry. However, since child to parent DAO transmission has link scope, wouldn't this all often become a mood point, since many link layers would provide such link layer ack mechanism anyways. Some maybe not, but I think making an RPL layer ACK a requirement may be too costly in many cases. Some case b= y case here, so if we do define an ACK, at least make it optional. /Anders On Wed, Mar 10, 2010 at 5:39 AM, Pascal Thubert (pthubert) < pthubert@cisco.com> wrote: > WG: > > > > RPL 07 provides means for a node to advertise some reachability using a D= AO > mechanism. The DAO can be triggered by the node to match its own needs. I= t > 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 who= le > 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 i= t > 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 > > > > > > [image: Think before you print.]Think before you print. > > Cisco Systems France, Soci=E9t=E9 =E0 responsabiit=E9 limit=E9e, Rue Cami= lle > Desmoulins =96 Imm Atlantis Zac Forum Seine Ilot 7 92130 Issy les Mouline= aux, > Au capital de 91.470 =80, 349 166 561 RCS Nanterre, Directeur de la > publication: Jean-Luc Michel Givone, For corporate legal information go t= o: > http://www.cisco.com/web/about/doing_business/legal/cri/index.html > > > > > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > > --001636e0acda78b53c0481760ea7 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Pascal, WG,

Not sure I agree with a requirement for a RP= L level ACK to the DAO.=A0

As you discuss, if a pa= rent (or the root) is requesting the information, there are mechanisms in p= lace already to trigger retries/refresh (not all timers necessarily worked = out yet, but state machine and DTSN mechanism is there).=A0

So, this deals with the situation where a child node is= volunteering the information rather responding to a request from the paren= t. I hope I understand this right, otherwise please let me know.

Typically, upon learning of a new child node, the above DTSN= based DAO trigger mechanism should start. However, if a node wants to issu= e an unsolicited DAO, I don't see anything wrong with doing so, and the= n, if no trigger arrives (DTSN based or otherwise) within a reasonable time= (again, timers are not defined by RPL, but could/would be by the Object Fu= nction), it could assume the unsolicited DAO was not received and retry.

However, since child to parent DAO transmission has lin= k scope, wouldn't this all often become a mood point, since many link l= ayers would provide such =A0link layer ack mechanism anyways. Some maybe no= t, but I think making an RPL layer ACK a requirement may be too costly in m= any cases. Some case by case here, so if we do define an ACK, at least make= it optional.

/Anders

On Wed= , Mar 10, 2010 at 5:39 AM, Pascal Thubert (pthubert) <= pthubert@cisco.com> wro= te:

WG:

=A0

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 th= e root, by setting the T bit that causes the DTSN increment to span the who= le DODAG.

=A0

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.

=A0

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

<= span lang=3D"EN-US">=A0

=A0

Pascal Thub= ert=
Engineer.software Engineering
Product Development
<= /span>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
Batime= nt T 3
06410
BIOT - SOPHIA ANTIPOLIS
France
= Cisco.com

=A0

=A0=

3D"ThinkThink before you print.

Cisco Systems Fran= ce, Soci=E9t=E9 =E0 responsabiit=E9 limit=E9e, Rue Camille Desmoulins =96 I= mm Atlantis Zac Forum Seine Ilot 7 92130 Issy les Moulineaux, Au capital de= 91.470 =80, 349 166 561 RCS Nanterre, Directeur de la publication: Jean-Lu= c Michel Givone, For corporate legal information go to:
http://www.cisco.com/web/a= bout/doing_business/legal/cri/index.html

=A0

=A0


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


--001636e0acda78b53c0481760ea7-- --001636e0acda78b53e0481760ea8 Content-Type: image/png; name="image004.png" Content-Transfer-Encoding: base64 Content-ID: X-Attachment-Id: 0.0.2 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 --001636e0acda78b53e0481760ea8 Content-Type: image/gif; name="image003.gif" Content-Transfer-Encoding: base64 Content-ID: X-Attachment-Id: 0.0.1 R0lGODlhEgATAJEAAAAAAP///wCZAP///yH5BAEAAAMALAAAAAASABMAAAIojI+pGyK8nINqUiTf bVnfvHEg1UmhdZRqaawu6XZVjKb0/CYxo8JOAQA7 --001636e0acda78b53e0481760ea8-- From anders.jagd@gmail.com Wed Mar 10 10:23: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 0842A3A6984 for ; Wed, 10 Mar 2010 10:23:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3d8Kn+gNQaDx for ; Wed, 10 Mar 2010 10:23:12 -0800 (PST) Received: from mail-pz0-f204.google.com (mail-pz0-f204.google.com [209.85.222.204]) by core3.amsl.com (Postfix) with ESMTP id 1FE113A68EF for ; Wed, 10 Mar 2010 10:22:23 -0800 (PST) Received: by pzk42 with SMTP id 42so1093070pzk.32 for ; Wed, 10 Mar 2010 10:22:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=5Q8PeijIOvKBz+grgEcVWO0GJlCMu1E+5FAc0bU7KqQ=; b=EckY41TIOfi7BquMttmT+pnpLwyiEWbW9GjEkHRPHJkPlj80k+AeB+2ixJK/kbA1cV xaMp5rTnWesP6l0x/LOVu1Lc+L+3IWWcRTbDg9UqPsaJcnnimkuF4eL6K6CDnxe+Gtyy wQ9SxNDHvokMWC+JSfHNHWU2T8foUsQook/jo= 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=d2WYO+AOEr29RZS8acXcuxSOexeA+kbOjRRVI7UtxM3JTIvwjtVF3OtpsZbQ+1ZdpJ NTSCZYIXqY0kB2LngiWBmIdiENa36URtCWC35ah9h5tWaFY/siuWoYiwxWp9t5AiNy4Y xZl+/D6Ck6vWmdSP5RxT1NUJ27PPezJzWmVXk= MIME-Version: 1.0 Received: by 10.142.61.33 with SMTP id j33mr649565wfa.61.1268245345517; Wed, 10 Mar 2010 10:22:25 -0800 (PST) In-Reply-To: <6A2A459175DABE4BB11DE2026AA50A5D0169821A@XMB-AMS-107.cisco.com> References: <4B966803.5090703@acm.org> <6A2A459175DABE4BB11DE2026AA50A5D0169800A@XMB-AMS-107.cisco.com> <873a095rzx.fsf@kelsey-ws.hq.ember.com> <77b524e41003091412v568b2590mede379ee789de9a@mail.gmail.com> <6A2A459175DABE4BB11DE2026AA50A5D0169821A@XMB-AMS-107.cisco.com> Date: Wed, 10 Mar 2010 13:22:25 -0500 Message-ID: <77b524e41003101022n47a4c664o8517b212e9798ed2@mail.gmail.com> From: Anders Jagd To: "Pascal Thubert (pthubert)" Content-Type: multipart/alternative; boundary=001636e1f93d4ec3eb048176615f Cc: Matteo Paris , roll@ietf.org Subject: Re: [Roll] 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, 10 Mar 2010 18:23:14 -0000 --001636e1f93d4ec3eb048176615f Content-Type: text/plain; charset=ISO-8859-1 Pascal, WG, I think you are making a good case for data path LSRR *optionally* supplemented by a stateful DAO mechanism, which would provide useful, however not required, assistance in making the LSRR as loose as possible. That said, I still haven't heard anyone explain the core problem with mixed environments. Mixed working solutions not being known, or maybe being difficult to test, doesn't seem to be quite enough reason for not considering them. How could mixed working solutions really exist when the problem we have been facing for so long, and which the WG has made great progress towards resolving, is that we don't have the standards yet to allow for heterogeneous multi-vendor systems. If there is a fundamental problem with mixed environments (and I am not saying there is not, I am just not aware of it - please educate me), then fine, we can discuss if the problem is so severe that it will be too costly/time-consuming to solve, but until then, I agree with Pascal that we may be "throwing the baby out with the bath water". If the problem has been analyzed previously, just point me towards the thread; I am not trying to reopen an old discussion. /Anders On Wed, Mar 10, 2010 at 4:13 AM, Pascal Thubert (pthubert) < pthubert@cisco.com> wrote: > Hi Matteo and Anders : > > > > There are known solutions to the mixed mode problem. Very, very well known. > That is called Loose Source and Record Route. But we did not use that. We > tried to merge the well know problem of the source route into the DAO > advertisement, and for such a merge I do not know of an existing, working > solution. And then we started proposing mechanisms that opened more > questions than they actually solved, and ultimately, we lost confidence in > what we were doing. > > > > Obviously, this proposal to split seems to simplify, but since it does not > address the real problem, it does not provide the right solution, and we end > up throwing the baby with the bath water. > > > > For me, the real answer to this call is to split the procedures used for > stateful and source route, as opposed to the deployment cases where source > route and stateful routing are used. > > > > That is, to leave the proactive DAO mechanism to stateful routing, and use > the classical data path LSRR for the source route. And those 2 work great > together, mostly independently. That way, stateful DAO happens first and > does not depend on source route, and then source route can benefit from > existing routing states to make the LSRR as small (loose) as possible. It is > up to a destination to advertise itself proactively in the DAO system, or > just on demand using source route. > > > > Cheers, > > > > Pascal > > > > *From:* roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] *On Behalf Of > *Matteo Paris > *Sent:* Tuesday, March 09, 2010 11:59 PM > *To:* roll@ietf.org > > *Subject:* Re: [Roll] Establishing downward routes in RPL : storing > /non-storing / mixed modes of operation > > > > > > Mixed mode is a much harder problem, for which we don't have a workable > solution. It also appears that it is not as common a use case. > > > > Like others, I would like a cache-mode field in the DAG config suboption > that specifies all-cache or only-root-cache. These cases are relatively > simple, so we can come to consensus on solutions for each quickly and move > on to other pressing issues. The cache-mode field could include a reserved > value which could be used at some future date for specifying mixed-mode > operation. > > > > Matteo > > > > > > At 5:12 PM -0500 3/9/10, Anders Jagd wrote: > > Could someone please help me understand why there is such reluctance to > keeping a door open for mixed-mode operation ? > > > > As I see it (but I may be missing something), the first few Object > Functions could certainly constrain the RPL Instance to either "all storing" > or "no storing"; other OFs potentially later to follow allowing for a mix. > > > > What is it in the base document that becomes difficult to wrap-up while at > the same time allowing for this flexibility ? Would that "something" be > important enough to outweigh the potential cost of, after imposing such a > "no mix" restriction, later having to develop protocol translation gateways > between non-storing islands and storing backbone networks ? > > > > /Anders > > > > On Tue, Mar 9, 2010 at 12:23 PM, Richard Kelsey > wrote: > > > Date: Tue, 9 Mar 2010 17:55:01 +0100 > > From: "Pascal Thubert (pthubert)" > > > > > One thing is I'm not happy with the S bit. I do not think we understand > > fully what makes it work or when. > > Pascal, > > The S bit reduces the DAO overhead in mostly non-caching > DODAGs. This benefit, and thus the S bit, disappears if we > do not support mixed caching and non-caching DODAGs. For > that reason, along with all the others that have been > mentioned, I am in favor of removing support for mixed > mode operation. > > We have spent a good amount of effort trying to come up with > a workable solution and have not been successful. For now > we should move on to other areas in need of attention, such > as P2P and multicast. > -Richard > > > _______________________________________________ > Roll mailing 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 > > --001636e1f93d4ec3eb048176615f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Pascal, WG,

I think you are making a good case for data = path LSRR *optionally* supplemented by a stateful DAO mechanism, which woul= d provide useful, however not required, assistance in making the LSRR as lo= ose as possible.

That said, I still haven't heard anyone explain the= core problem with mixed environments. Mixed working solutions not being kn= own, or maybe being difficult to test, doesn't seem to be quite enough = reason for not considering them. How could mixed working solutions really e= xist when the problem we have been facing for so long, and which the WG has= made great progress towards resolving, is that we don't have the stand= ards yet to allow for heterogeneous multi-vendor systems.=A0

If there is a fundamental problem with mixed environmen= ts (and I am not saying there is not, I am just not aware of it - please ed= ucate me), then fine, we can discuss if the problem is so severe that it wi= ll be too costly/time-consuming to solve, but until then, I agree with Pasc= al that we may be "throwing the baby out with the bath water". If= the problem has been analyzed previously, just point me towards the thread= ; I am not trying to reopen an old discussion.

/Anders

On Wed= , Mar 10, 2010 at 4:13 AM, Pascal Thubert (pthubert) <= pthubert@cisco.com> wro= te:

Hi Matteo and Anders=A0:

=A0

There are known solutions to the mixed = mode problem. Very, very well known. That is called Loose Source and Record= Route. But we did not use that. We tried to merge the well know problem of= the source route into the DAO advertisement, and for such a merge I do not= know of an existing, working solution. And then we started proposing mecha= nisms that opened more questions than they actually solved, and ultimately,= we lost confidence in what we were doing.

=A0

Obviously, this proposal to split seems= to simplify, but since it does not address the real problem, it does not p= rovide the right solution, and we end up throwing the baby with the bath wa= ter.

=A0

For me, the real answer to this call is= to split the procedures used for stateful and source route, as opposed to = the deployment cases where source route and stateful routing are used.

=A0

That is, to leave the proactive DAO mec= hanism to stateful routing, and use the classical data path LSRR for the so= urce route. And those 2 work great together, mostly independently. That way= , stateful DAO happens first and does not depend on source route, and then = source route can benefit from existing routing states to make the LSRR as s= mall (loose) as possible. It is up to a destination to advertise itself pro= actively in the DAO system, or just on demand using source route.

=A0

Cheers,

=A0<= /p>

Pascal

=A0

Fr= om: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Matteo Paris
Sent: Tuesday, March 09, 2010 11:59 PM
To: roll@ietf.org


Subject: Re: [Roll] Establishing downward routes in RPL = : storing /non-storing / mixed modes of operation

=A0

=A0

Mixed mode is a much harder prob= lem, for which we don't have a workable solution.=A0 It also appears th= at it is not as common a use case.

=A0

=

Like others, I would like a cache-mode fi= eld in the DAG config suboption that specifies all-cache or only-root-cache= .=A0 These cases are relatively simple, so we can come to consensus on solu= tions for each quickly and move on to other pressing issues.=A0 The cache-m= ode field could include a reserved value which could be used at some future= date for specifying mixed-mode operation.

=A0

= Matteo

=A0

=A0

At 5:12 PM -0500 3/9/10,= Anders Jagd wrote:

Could someone please help me understand why there is such re= luctance to keeping a door open for mixed-mode operation ?

=

=A0

As I see it (but I may be= missing something), the first few Object Functions could certainly constra= in the RPL Instance to either "all storing" or "no storing&q= uot;; other OFs potentially later to follow allowing for a mix.

=A0

What is it in the base docum= ent that becomes difficult to wrap-up while at the same time allowing for t= his flexibility ? Would that "something" be important enough to o= utweigh the potential cost of, after imposing such a "no mix" res= triction, later having to develop protocol translation gateways between non= -storing islands and storing backbone networks ?

=A0

/Anders

=A0

On Tue, Mar 9, 2010 at 12= :23 PM, Richard Kelsey <richard.kelsey@ember.com> wrote:

> Date: Tue, 9 Mar 2010 17:55:01 +0100
> Fr= om: "Pascal Thubert (pthubert)" <pthubert@cisco.com>

>
> One thing is I'm not happy with the= S bit. I do not think we understand
> fully what makes it work or wh= en.

Pascal,

The S bit reduces the DAO overhead in= mostly non-caching
DODAGs. =A0This benefit, and thus the S bit, disappe= ars if we
do not support mixed caching and non-caching DODAGs. =A0Forthat reason, along with all the others that have been
mentioned, I am in favor of removing support for mixed
mode operation.
We have spent a good amount of effort trying to come up with
a wor= kable solution and have not been successful. =A0For now
we should move o= n to other areas in need of attention, such
as P2P and multicast.
=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0 =A0-Richard


______________________= _________________________
Roll mailing list
Rol= l@ietf.org
https://www.ietf.org/mailman/listinfo/roll

=A0


________________________= _______________________
Roll mailing list
Rol= l@ietf.org
https://www.ietf.org/mailman/listinfo/roll

=A0


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


--001636e1f93d4ec3eb048176615f-- From joakime@sics.se Wed Mar 10 10:53: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 9A3CF3A6968 for ; Wed, 10 Mar 2010 10:53:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_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 4qGBP+W6Pbwm for ; Wed, 10 Mar 2010 10:53:17 -0800 (PST) Received: from smtprelay-h22.telenor.se (smtprelay-h22.telenor.se [195.54.99.197]) by core3.amsl.com (Postfix) with ESMTP id 57ED83A6C49 for ; Wed, 10 Mar 2010 10:50:25 -0800 (PST) Received: from ipb2.telenor.se (ipb2.telenor.se [195.54.127.165]) by smtprelay-h22.telenor.se (Postfix) with ESMTP id 8058BEA542 for ; Wed, 10 Mar 2010 19:50:28 +0100 (CET) X-SMTPAUTH-B2: X-SENDER-IP: 85.228.27.73 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlsUAO14l0tV5BtJPGdsb2JhbAAHmlgBAQEBN70ChHkE X-IronPort-AV: E=Sophos;i="4.49,615,1262559600"; d="scan'208";a="48571765" Received: from c-491be455.013-276-73746f7.cust.bredbandsbolaget.se (HELO [192.168.1.144]) ([85.228.27.73]) by ipb2.telenor.se with ESMTP; 10 Mar 2010 19:50:28 +0100 Message-ID: <4B97E9F9.8020605@sics.se> Date: Wed, 10 Mar 2010 19:50:33 +0100 From: Joakim Eriksson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; sv-SE; rv:1.9.1.8) Gecko/20100227 Thunderbird/3.0.3 MIME-Version: 1.0 To: roll@ietf.org References: <20100308233001.C6F863A69F9@core3.amsl.com> <4B966090.9050208@acm.org> In-Reply-To: <4B966090.9050208@acm.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Roll] I-D Action:draft-ietf-roll-rpl-07.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, 10 Mar 2010 18:53:18 -0000 Hello, Why are we not moving up 9.5 (OCP sub-option) from draft-ietf-roll-routing-metrics-04 to the DIO sub-option descriptions (5.1.3) in the roll-rpl draft? I prefer to have all (important) DIO sub-options in the main rpl-draft (missed that one when implementing due to its current position ;-) Best regards, -- Joakim Eriksson, SICS Tim Winter skrev 2010-03-09 15:52: > WG, > > In this version there is a significant update to the Examples in Appendix B to > illustrate the operation of the proposed DAO mechanism. Some additional description > of the control fields for DAO operation ('T', 'S', and DTSN) is added to Section 6. > Many other small editorial changes are incorporated in response to feedback from -06 > as well. > > Please especially review and provide your feedback on the proposal for provisioning > downward routes described in Section 6. > > Thanks, > > - RPL Author Team > > > > Internet-Drafts@ietf.org wrote: >> A New Internet-Draft is available from the on-line Internet-Drafts directories. >> This draft is a work item of the Routing Over Low power and Lossy networks Working Group of the IETF. >> >> >> Title : RPL: IPv6 Routing Protocol for Low power and Lossy Networks >> Author(s) : T. Winter, et al. >> Filename : draft-ietf-roll-rpl-07.txt >> Pages : 82 >> Date : 2010-03-08 >> >> Low power and Lossy Networks (LLNs) are a class of network in which >> both the routers and their interconnect are constrained: LLN routers >> typically operate with constraints on (any subset of) processing >> power, memory and energy (battery), and their interconnects are >> characterized by (any subset of) high loss rates, low data rates and >> instability. LLNs are comprised of anything from a few dozen and up >> to thousands of LLN routers, and support point-to-point traffic >> (between devices inside the LLN), point-to-multipoint traffic (from a >> central control point to a subset of devices inside the LLN) and >> multipoint-to-point traffic (from devices inside the LLN towards a >> central control point). This document specifies the IPv6 Routing >> Protocol for LLNs (RPL), which provides a mechanism whereby >> multipoint-to-point traffic from devices inside the LLN towards a >> central control point, as well as point-to-multipoint traffic from >> the central control point to the devices inside the LLN, is >> supported. Support for point-to-point traffic is also available. >> >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-ietf-roll-rpl-07.txt >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> Below is the data which will enable a MIME compliant mail reader >> implementation to automatically retrieve the ASCII version of the >> Internet-Draft. >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> Roll mailing list >> Roll@ietf.org >> https://www.ietf.org/mailman/listinfo/roll > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From alexandru.petrescu@gmail.com Wed Mar 10 10:54: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 31FB03A6C51 for ; Wed, 10 Mar 2010 10:54:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.206 X-Spam-Level: X-Spam-Status: No, score=-2.206 tagged_above=-999 required=5 tests=[AWL=0.043, 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 lAUUiRZ62ZHq for ; Wed, 10 Mar 2010 10:54:17 -0800 (PST) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.1]) by core3.amsl.com (Postfix) with ESMTP id E381F3A69EF for ; Wed, 10 Mar 2010 10:52:32 -0800 (PST) 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 o2AIqa5G013089 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Wed, 10 Mar 2010 19:52:36 +0100 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.2/8.14.2) with ESMTP id o2AIqaOS026318 for ; Wed, 10 Mar 2010 19:52:36 +0100 (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 o2AIqZdK019489 for ; Wed, 10 Mar 2010 19:52:36 +0100 Message-ID: <4B97EA73.5040405@gmail.com> Date: Wed, 10 Mar 2010 19:52:35 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.9.1.8) Gecko/20100227 Thunderbird/3.0.3 MIME-Version: 1.0 To: roll@ietf.org References: <1268091651.1955.155.camel@dellx1> <4B97DB85.2090800@gmail.com> In-Reply-To: <4B97DB85.2090800@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [Roll] RIPless 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: Wed, 10 Mar 2010 18:54:18 -0000 I meant to say one could reserve only one value e.g. 0xfd to mean e.g. "RSSI-weighted hopcount" in the 8bit metric and further detail in a new RTE. Alex Le 10/03/2010 18:48, Alexandru Petrescu a écrit : > Hello, > > I am happy this draft draft-mulligan-roll-ripless-01 exists, because it > relies on widely available software and deployments. > > Are you requesting comments? > > I have one comment with respect to the metrics section "6.1. Routing > Metric": > > " The routing metric described in the RIP RFCs is a simple hop-count. > It is thought in the RF sensor networking community (???need > reference???) that just a simple hop count is insufficient to > properly determine the "best path" between two nodes. It is suggest > here that a weighted hop-count might provide a better metric. The > hop-count would be weighted by the RSSI/LQI value for the link > between each node." > > I am not sure a unique metric, be that hopcount weighted by RSSI, is > enough to express various other needs like energy expenditure to send > packets on a particular link. > >> The specific weighting could be implementation specific, but for an >> IEEE 802.15.4 [9] type network using 8 discrete LQI values links with >> an LQI of 0x00 and 0x01 might have the metric set to "infinite", LQIs >> of 0x02 through 0x05 would set metric to 2 and an LQI of 0x06 or 0x07 >> would use the standard metric value of 1. If the implementor would >> rather use RSSI values or more values in LQI (256) are available some >> different step funtion might be use. > > Hmmm... I would avoid filling up so many values of that RIP 8bit metric > value. Out of 255 values about 238 are left free. I would only take 1 > value "0xfe", call it "energy metric encoded in RIPng RTE", as described > in the paragraphs below. > > Alex > >> 5. Energy Metric Encoded in RIPng RTE >> >> A RIPng packet can be depicted as follows: >> >> >> +-----------+ +-----------------+ +---+ +----+ >> |Base Header| ...|Extension Headers| |UDP| ...|RTEs| >> +-----------+ +-----------------+ +---+ +----+ >> >> >> A RIPng packet contains a list of RTEs (Route Table Entries) as >> explained in [RFC2080] "RIPng for IPv6". An 'address' RTE contains a >> 128 bit address, an 8 bit route tag, an 8 bit prefix length and an 8 >> bit metric (all for 20bytes). A 'next hop' RTE is an RTE with a >> metric value of 0xFF. Many 'address' RTEs (actually, prefixes) >> correspond to a single 'next hop' RTE. >> >> The existing 8-bit metric value is used to express metrics between 1 >> and 15, thus determining the potential size of a RIPng routing >> domain. We propose to reserve the value 0xFE for an 'energy' metric >> within an address RTE. >> >> The energy RTE relates to the immediately preceding address RTE. A >> typical sequence of RTEs would be as depicted in the figure below: >> >> >> +-----------+ +------------++-----------+ +------------++-----------+ >> |NextHop1RTE| |Address1 RTE||Energy1 RTE| |Address2 RTE||Energy2 RTE| >> +-----------+ +------------++-----------+ +------------++-----------+ >> >> >> This sequence should be interpreted as follows: for any destination >> address longest-prefix matching the prefix in Address1 RTE, the >> energy metric is in Energy1 RTE and the next hop address is in Next >> Hop1 RTE. The same for Address2 RTE and Energy2 RTE. >> >> The bit layout of the Energy RTE 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 >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Max Energy Send | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Min Energy Send | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Max Energy Receive | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Min Energy Receive | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | route tag (2) | prefix len (1)| Energy Metric | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> >> >> Max Energy Send >> >> Single-precision 32bit floating point number in binary >> interchange format (see [IEEE754-2008] and [IEC60559-2.0]), a >> C 'float' type (see [ISOIEC-C99]), in network byte order. >> The value represents the maximum energy, expressed in Joules, >> necessary to send an IP packet of size 1280 bytes to any >> address valid on the IPv6 prefix of the immediately preceding >> address RTE. This is the sum of the max energy values needed >> to transmit this packet on each intermediary IPv6 Link. >> >> Min Energy Send >> >> Single-precision 32bit floating point number in binary >> interchange format (see [IEEE754-2008] and [IEC60559-2.0]), a >> C 'float' type (see [ISOIEC-C99]), in network byte order. >> The value represents the minimum energy, expressed in Joules, >> necessary to send 1280 bytes to any address valid on the IPv6 >> prefix of the immediately preceding address RTE. This is the >> sum of the min energy values needed to transmit this packet >> on each intermediary IPv6 link. >> >> Max Energy Receive >> >> Single-precision 32bit floating point number in binary >> interchange format (see [IEEE754-2008] and [IEC60559-2.0]), a >> C 'float' type (see [ISOIEC-C99]), in network byte order. >> The value represents the maximum energy, expressed in Joules, >> necessary to receive 1280 bytes from any address valid on the >> IPv6 prefix of the immediately preceding address RTE. This >> is the sum of the max energy values needed to receive this >> packet on each intermediary IPv6 link. >> >> >> Min Energy Receive >> >> Single-precision 32bit floating point number in binary >> interchange format (see [IEEE754-2008] and [IEC60559-2.0]), a >> C 'float' type (see [ISOIEC-C99]), in network byte order. >> The value represents the minimum energy, expressed in Joules, >> necessary to receive 1280 bytes from any address valid on the >> IPv6 prefix of the immediately preceding address RTE. This >> is the sum of the min energy values needed to receive this >> packet on each intermediary IPv6 link. >> >> route tag >> >> Set to 0 by sender, ignored by receiver. >> >> >> prefix len >> >> Set to zero by sender and ignored by receiver. >> >> >> Energy Metric >> >> Energy Metric for IPv6 Links. >> >> TBA >> >> We are not aware of IANA assignments for this metric field, >> althtough IANA does maintain RIP Message Types at >> http://www.iana.org/assignments/rip-types >> >> We propose this field to contain 0xFE. Existing values of >> which we are aware are: 0, 1, ... 15, 0XFF. >> >> > > Le 09/03/2010 00:40, Geoff Mulligan a écrit : >> I don't think my previous message about -00 made it to the list. >> >> geoff >> >> PS- I didn't spell successfully incorrectly below :-) Other spelling >> errors are all mine. >> >> From: IETF I-D Submission Tool >> To: geoff@proto6.com >> Subject: New Version Notification for draft-mulligan-roll-ripless-01 >> Date: Mon, 8 Mar 2010 15:29:52 -0800 (PST) >> >> A new version of I-D, draft-mulligan-roll-ripless-01.txt has been >> successfuly submitted by Geoffrey Mulligan and posted to the IETF >> repository. >> >> Filename: draft-mulligan-roll-ripless >> Revision: 01 >> Title: Optimized RIP for embedded RF networks >> Creation_date: 2010-03-08 >> WG ID: Independent Submission >> Number_of_pages: 12 >> >> Abstract: >> This document specifies an optimization to the Routing Information >> Protocol (RIP) routing protocol for use in embedded RF IPv6 internets >> such as those used in 6lowpan [7] networks. RIPless specifies the >> minimal changes to RIP, as specified in RIPng [2], RIP [3] and RIPv2 >> [4] to allow the protocol to be used in a "lossy" RF networks where >> the routing fabric of the network is built upon powered nodes and >> that only the edge devices may be battery powered. >> >> >> >> The IETF Secretariat. >> >> >> >> _______________________________________________ >> Roll mailing 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 Wed Mar 10 10:57: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 493033A6926 for ; Wed, 10 Mar 2010 10:57:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.312 X-Spam-Level: X-Spam-Status: No, score=-2.312 tagged_above=-999 required=5 tests=[AWL=0.288, 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 zb-rkUvtXYqB for ; Wed, 10 Mar 2010 10:57:50 -0800 (PST) Received: from mail.sf.archrock.com (mail.sf.archrock.com [216.121.16.71]) by core3.amsl.com (Postfix) with ESMTP id 8927D3A6980 for ; Wed, 10 Mar 2010 10:57:50 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.sf.archrock.com (Postfix) with ESMTP id D1962AF9D6; Wed, 10 Mar 2010 10:57:55 -0800 (PST) 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 9aQC+c2242nP; Wed, 10 Mar 2010 10:57:51 -0800 (PST) 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 23F6DAF9B8; Wed, 10 Mar 2010 10:57:51 -0800 (PST) Message-Id: From: Jonathan Hui To: Anders Jagd In-Reply-To: <77b524e41003101022n47a4c664o8517b212e9798ed2@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, 10 Mar 2010 10:57:49 -0800 References: <4B966803.5090703@acm.org> <6A2A459175DABE4BB11DE2026AA50A5D0169800A@XMB-AMS-107.cisco.com> <873a095rzx.fsf@kelsey-ws.hq.ember.com> <77b524e41003091412v568b2590mede379ee789de9a@mail.gmail.com> <6A2A459175DABE4BB11DE2026AA50A5D0169821A@XMB-AMS-107.cisco.com> <77b524e41003101022n47a4c664o8517b212e9798ed2@mail.gmail.com> X-Mailer: Apple Mail (2.936) Cc: roll@ietf.org, Matteo Paris Subject: Re: [Roll] 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, 10 Mar 2010 18:57:51 -0000 Hi Anders, On Mar 10, 2010, at 10:22 AM, Anders Jagd wrote: > That said, I still haven't heard anyone explain the core problem > with mixed environments. Mixed working solutions not being known, or > maybe being difficult to test, doesn't seem to be quite enough > reason for not considering them. How could mixed working solutions > really exist when the problem we have been facing for so long, and > which the WG has made great progress towards resolving, is that we > don't have the standards yet to allow for heterogeneous multi-vendor > systems. New standards are typically based on well-understood solutions. Anything else would be a research project and that has no place within the IETF. The question that so many of us have raised is whether there are well-understood solutions for mixed-mode operation in the class of networks we are targeting. At this point, it seems that there are not. > If there is a fundamental problem with mixed environments (and I am > not saying there is not, I am just not aware of it - please educate > me), then fine, we can discuss if the problem is so severe that it > will be too costly/time-consuming to solve, but until then, I agree > with Pascal that we may be "throwing the baby out with the bath > water". If the problem has been analyzed previously, just point me > towards the thread; I am not trying to reopen an old discussion. It's not that there is a fundamental problem with supporting mixed- mode operation. It's that we have not yet found a satisfactory solution that supports mixed-mode environments effectively while at the same time not compromising the solutions that we care about today (fully stateless and fully stateful environments). We have tried with one solution, but that has its issues that make many feel uncomfortable. See previous mails in this thread for more details. -- Jonathan Hui From Jerald.P.Martocci@jci.com Wed Mar 10 13: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 2305F3A6964; Wed, 10 Mar 2010 13:00:36 -0800 (PST) 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 I79dyYdU-unj; Wed, 10 Mar 2010 13:00:34 -0800 (PST) Received: from exprod8og117.obsmtp.com (exprod8og117.obsmtp.com [64.18.3.34]) by core3.amsl.com (Postfix) with ESMTP id E8E583A69CE; Wed, 10 Mar 2010 13:00:33 -0800 (PST) Received: from source ([192.132.24.137]) (using SSLv3) by exprod8ob117.postini.com ([64.18.7.12]) with SMTP ID DSNKS5gIdXL+1mCP39xfIxX1384JotMIRQpW@postini.com; Wed, 10 Mar 2010 13:00:39 PST Received: from jwimkrs1.na.jci.com ([10.10.6.31]) by smtpmke01.jci.com (Lotus Domino Release 8.0.1) with ESMTP id 2010031015004960-598604 ; Wed, 10 Mar 2010 15:00:49 -0600 In-Reply-To: <6D9687E95918C04A8B30A7D6DA805A3E01429F5F@zensys17.zensys.local> References: <6D9687E95918C04A8B30A7D6DA805A3E01429F5F@zensys17.zensys.local> To: "Anders Brandt" MIME-Version: 1.0 X-KeepSent: 858923A6:2A8A454B-862576E2:0071C0B8; 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, 10 Mar 2010 15:00:28 -0600 X-MIMETrack: Serialize by Router on jwimkrs1.na.jci.com/NA/Johnson_Controls at 03/10/2010 03:00:34 PM, Serialize complete at 03/10/2010 03:00:34 PM, Itemize by SMTP Server on smtpmke01.jci.com/JCI_SMTP(Release 8.0.1|February 07, 2008) at 03/10/2010 03:00:49 PM, Serialize by Router on smtpmke01.jci.com/JCI_SMTP(Release 8.0.1|February 07, 2008) at 03/10/2010 03:00:54 PM, Serialize complete at 03/10/2010 03:00:54 PM Content-Type: text/html; charset="US-ASCII" Cc: ROLL WG , roll-bounces@ietf.org Subject: Re: [Roll] P2P performance with current RPL proposal X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Mar 2010 21:00:36 -0000
Anders,

+1

Sorry for the delayed response.  I was on vacation this past week and only saw your email today.

As you probably expect, I certainly agree with your assessment and concern about RPL latency in P2P mission critical applications.  Lighting applications will visually be unacceptable to our customers.  We cannot have lights turning on seconds (much less minutes) after the light switch is depressed.  

However, Fire and Physical Security applications are even more time critical.  Fire alarms must start sounding, strobes must start flashing and evacuation instructions must be presented almost instantaneously to its detection.  HVAC smoke control operations must be in place within a few seconds after the detector has smelled smoke.  These applications affect various subsystems randomly based on the fire and smoke's path.  Hence there is no preordained control path that can be established.

I think I have pretty much bored the entire WG on this issue the past 6 months.  I also agree that RPL needs some reactive means to quickly discovering a new path.  I am glad that JP has added this an 'issue tracker'.  

Regards,

Jerry


From: "Anders Brandt" <abr@sdesigns.dk>
To: "ROLL WG" <roll@ietf.org>
Date: 03/08/2010 02:20 AM
Subject: [Roll] P2P performance with current RPL proposal




Hello
 
I would like to probe the temperature of the WG on using DAOs to
support P2P.
 
The building and home application spaces (and maybe others) have
a few clearly defined requirements.
It is not obvious to me how the current RPL proposal (cRPLp) can
satisfy those requirements:
 
 
In both cases it is the worst case scenario that hurts:
 
 
P2P routing inside the PAN
==========================
cRPLp has no way of routing inside the PAN if you need more than
one repeater. cRPLp has to go all the way to the top (maybe 4 hops up)
and down again (maybe 4 hops down) to get just 2 hops to the side.
 
The consequence is high latency and high levels of background noise
for nodes just outside the direct radio range.
At the same time the risk of meeting a failing link is 4 times higher =>
latency may be much more than 4 times larger.
 
Latency may sound like a minor issue but it actually translates directly
into lower battery lifetime. In the above (very realistic) example,
the battery lifetime is reduced to 25% of what it should be.
 
We have lots of battery devices sending into the network:
* PIR sensors turning on lights
* Door locks sending alarms
* Door/window sensors starting chimes
* Smoke sensors triggering an alarm system
 
 
 
 
Response time
=============
The latency issue is important.
When a user (real human being) presses a light button the user expects
the light to turn on.
cRPLp proposes that nodes in the tree periodically advertises their
presence using DAOs.
The periodicity is a real beast:
Thanks to Trickle, the rate of updates in a (apparently) stable network
is low. This is good since it leaves bandwidth for data.
But it is not good if existing routes to my lamp fail and I do not get
new routes to my lamp until it decides to send out a new DAO.
My user will (with a good reason) not tolerate waiting for minutes for
the light to turn on.
 
I have met two arguments to counter this concern:
 
A1: Well, your lamp can always send a DAO when it detects a problem.
  My answer:
  True, except that my lamp does not intend to send anything
  so it will never experience any problems from its side of the network.
 
A2: Well, you can increase the DAO rate to sub-second updates.
  My answer:
  Oh no. I get a very high degree of management traffic which
  limits my available bandwidth, increases the risk of collisions and
  even run the risk of violating EU legislation requiring me to only
  transmit in less than 1% of the time:
  http://focus.ti.com/lit/an/swra048/swra048.pdf
 868 - 868.6 MHz: <1%
 
  Reactiveness is hard to achieve via polling.
 
 
 
If you agree that this seems to be critical issues please raise your
voice on the list.
 
Going forward
=============
 
We need some reactive mechanism to reach lamps before the user decides
to sue our companies.
So is this possible? I think so.

Existing commercial (non-IP) solutions are capable of re-routing quickly
if they really have to.
 
Let me try scoping the requirements to a potential solution:
(no different from the req. docs for home and building)
 
* P2P routing in any direction independent of the tree.
 
* On-demand P2P route discovery if requested by a real-time critical app.
 Data collection apps may be able to just wait for the next DAO update.
 
* Limited range of discovery mechanism: max 4 repeaters.
  A TTL field may limit the scope of the repeaters.
 
* Suboptimal routing and traffic bursts are accepted in exchange
  for quick route repair. But only as an exception.
 
 
Just as an example, one existing home control technology uses a
(source routing) variant of AODV for quick route repair.
Nothing comes for free. The price is flooding - but not just flooding:
Managed flooding using a distributed algorithm running in all
participating nodes.
The algorithm dampens the flooding in a time, volume and range perspective.
Some similar mechanism could be built into RPL for quick route repair.
 
 
If anyone have alternative proposals, please bring it to the list.
Now is the time.
 
 
 
Thanks,
  Anders_______________________________________________
Roll mailing list
Roll@ietf.org
https://www.ietf.org/mailman/listinfo/roll

From robert.cragie@gridmerge.com Thu Mar 11 05:43: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 7097F3A6B85 for ; Thu, 11 Mar 2010 05:43:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.668 X-Spam-Level: X-Spam-Status: No, score=-2.668 tagged_above=-999 required=5 tests=[AWL=-0.929, 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 xEmla7pMO0qK for ; Thu, 11 Mar 2010 05:43:55 -0800 (PST) Received: from mail78.extendcp.co.uk (mail78.extendcp.co.uk [79.170.40.78]) by core3.amsl.com (Postfix) with ESMTP id EE6D53A690F for ; Thu, 11 Mar 2010 05:43:24 -0800 (PST) Received: from client-82-25-239-211.glfd.adsl.virginmedia.com ([82.25.239.211] helo=[192.168.1.68]) by mail78.extendcp.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.70) id 1NpifW-0007um-RV; Thu, 11 Mar 2010 13:43:23 +0000 Message-ID: <4B98F374.4030301@gridmerge.com> Date: Thu, 11 Mar 2010 13:43:16 +0000 From: Robert Cragie Organization: Gridmerge Ltd. User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Ted.Humpal@jci.com References: <6D9687E95918C04A8B30A7D6DA805A3E01429F5F@zensys17.zensys.local> <4B9553B8.6010001@eecs.berkeley.edu> In-Reply-To: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms000602040106030904050208" Cc: ROLL WG Subject: Re: [Roll] P2P performance with current RPL proposal 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, 11 Mar 2010 13:43:57 -0000 This is a cryptographically signed message in MIME format. --------------ms000602040106030904050208 Content-Type: multipart/alternative; boundary="------------010506050002080202030800" This is a multi-part message in MIME format. --------------010506050002080202030800 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit I agree with Ted's comments below. Creating a DODAG for every reachable node as a root seems a very inefficient approach compared to alternative routing algorithms. I am concerned that RPL does not actually meet the original requirements in I-D.ietf-roll-building-routing-reqs, I-D.ietf-roll-home-routing-reqs, RFC5673 and RFC5548. The traffic pattern requirement for a sink node features prominently in only two of those documents. Even in this case, as Ted points out, communication is likely to be bidirectional (e.g. end-to-end acks.) therefore the DODAG approach is fundamentally asymmetric, especially if no intermediate storage is allowed for destination routes and source routing has to be used. Also, RPL seems highly complex for what are constrained nodes in terms of memory as well as power and bandwidth. The RPL draft as it stands is 82 pages long and that doesn't include text about the objective function. Robert Robert Cragie (Pacific Gas & Electric) Gridmerge Ltd. 89 Greenfield Crescent, Wakefield, WF4 4WA, UK +44 (0) 1924 910888 http://www.gridmerge.com Ted.Humpal@jci.com wrote: > > A concern also will be how much overhead (memory space) will be > required for a DODAG Root? > > and based on the first question how many DODAG roots a lamp may need > to be a member of? > > For example in lighting a single lamp may be a root for a single > switch (1 DODAG root), this lamp / luminaire may also > be a member of another group - - which could be all lights on the > floor (2nd DODAG root), and a third group > of all the lights in the building. There can be many more speciality > groups associated based on the building configuration. > Consider also during the installation time - how these DODAG roots > will be configured? Must I commission each device > to tell it which DODAG it must use for its Object Function? How easy > will this be to change and add in a new DODAG root > for the end user if the lighting group changes?? > > With respect to Jerry Martocci's - commercial building requirements - > every device may need to communicate to any or > all of the end devices. If each device must establish a DODAG for the > other 499 devices in a 500 node network - How much memory > space will this require for each end device to maintain? > > Keep in mind that the end devices are very limited processor and > memory wise. > > Not to mention all of the network maintenance messages that would need > to be transmitted to maintain all of these DODAGs. > > Consider the reconvergence time when one device is turned off and it > was in the middle of the majority of the 100+ DODAGS? > > In many lighting and building application an application > acknowledgement - must be returned {Back down the DODAG} so . . . the > requirement is not just getting to the Root - a return path must also > be maintained and have a low latency path. > > Ted Humpal > > > > > From: Kris Pister > To: Anders Brandt > Cc: ROLL WG > Date: 03/08/2010 01:45 PM > Subject: Re: [Roll] P2P performance with current RPL proposal > > > ------------------------------------------------------------------------ > > > > Anders - if we take JP's suggestion to make The Lamp a DODAG root, and > take Phoebus' recommendation that we use path diversity to improve > end-to-end reliability, do you see a chance of success? > In my experience, with diverse paths and order-minutes updates you get > extremely high reliability. > > I have no aversion to TTL-limited floods as a part of a solution > either. I'm open to ideas on how to bring those in as (presumably > infrequently used) options. > > ksjp > > Anders Brandt wrote: > Hello > > I would like to probe the temperature of the WG on using DAOs to > support P2P. > > The building and home application spaces (and maybe others) have > a few clearly defined requirements. > It is not obvious to me how the current RPL proposal (cRPLp) can > satisfy those requirements: > > > In both cases it is the worst case scenario that hurts: > > > P2P routing inside the PAN > ========================== > cRPLp has no way of routing inside the PAN if you need more than > one repeater. cRPLp has to go all the way to the top (maybe 4 hops up) > and down again (maybe 4 hops down) to get just 2 hops to the side. > > The consequence is high latency and high levels of background noise > for nodes just outside the direct radio range. > At the same time the risk of meeting a failing link is 4 times higher => > latency may be much more than 4 times larger. > > Latency may sound like a minor issue but it actually translates directly > into lower battery lifetime. In the above (very realistic) example, > the battery lifetime is reduced to 25% of what it should be. > > We have lots of battery devices sending into the network: > * PIR sensors turning on lights > * Door locks sending alarms > * Door/window sensors starting chimes > * Smoke sensors triggering an alarm system > > > > > Response time > ============= > The latency issue is important. > When a user (real human being) presses a light button the user expects > the light to turn on. > cRPLp proposes that nodes in the tree periodically advertises their > presence using DAOs. > The periodicity is a real beast: > Thanks to Trickle, the rate of updates in a (apparently) stable network > is low. This is good since it leaves bandwidth for data. > But it is not good if existing routes to my lamp fail and I do not get > new routes to my lamp until it decides to send out a new DAO. > My user will (with a good reason) not tolerate waiting for minutes for > the light to turn on. > > I have met two arguments to counter this concern: > > A1: Well, your lamp can always send a DAO when it detects a problem. > My answer: > True, except that my lamp does not intend to send anything > so it will never experience any problems from its side of the network. > > A2: Well, you can increase the DAO rate to sub-second updates. > My answer: > Oh no. I get a very high degree of management traffic which > limits my available bandwidth, increases the risk of collisions and > even run the risk of violating EU legislation requiring me to only > transmit in less than 1% of the time: > _http://focus.ti.com/lit/an/swra048/swra048.pdf_ > 868 - 868.6 MHz: <1% > > Reactiveness is hard to achieve via polling. > > > > If you agree that this seems to be critical issues please raise your > voice on the list. > > Going forward > ============= > > We need some reactive mechanism to reach lamps before the user decides > to sue our companies. > So is this possible? I think so. > > Existing commercial (non-IP) solutions are capable of re-routing quickly > if they really have to. > > Let me try scoping the requirements to a potential solution: > (no different from the req. docs for home and building) > > * P2P routing in any direction independent of the tree. > > * On-demand P2P route discovery if requested by a real-time critical app. > Data collection apps may be able to just wait for the next DAO update. > > * Limited range of discovery mechanism: max 4 repeaters. > A TTL field may limit the scope of the repeaters. > > * Suboptimal routing and traffic bursts are accepted in exchange > for quick route repair. But only as an exception. > > > Just as an example, one existing home control technology uses a > (source routing) variant of AODV for quick route repair. > Nothing comes for free. The price is flooding - but not just flooding: > Managed flooding using a distributed algorithm running in all > participating nodes. > The algorithm dampens the flooding in a time, volume and range > perspective. > Some similar mechanism could be built into RPL for quick route repair. > > > If anyone have alternative proposals, please bring it to the list. > Now is the time. > > > > Thanks, > Anders > > ------------------------------------------------------------------------ > > _______________________________________________ > Roll mailing 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 > --------------010506050002080202030800 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit I agree with Ted's comments below. Creating a DODAG for every reachable node as a root seems a very inefficient approach compared to alternative routing algorithms. I am concerned that RPL does not actually meet the original requirements in I-D.ietf-roll-building-routing-reqs, I-D.ietf-roll-home-routing-reqs, RFC5673 and RFC5548. The traffic pattern requirement for a sink node features prominently in only two of those documents. Even in this case, as Ted points out, communication is likely to be bidirectional (e.g. end-to-end acks.) therefore the DODAG approach is fundamentally asymmetric, especially if no intermediate storage is allowed for destination routes and source routing has to be used.

Also, RPL seems highly complex for what are constrained nodes in terms of memory as well as power and bandwidth. The RPL draft as it stands is 82 pages long and that doesn't include text about the objective function.

Robert

Robert Cragie (Pacific Gas & Electric)

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



Ted.Humpal@jci.com wrote:

A concern also will be how much overhead (memory space) will be required for a DODAG Root?

and based on the first question how many DODAG roots a lamp may need to be a member of?

For example in lighting  a single lamp may be a root for a single switch (1 DODAG root),  this lamp / luminaire may also
be a member of another group - -  which could be all lights on the floor (2nd DODAG root), and a third group
of all the lights in the building.  There can be many more speciality groups associated based on the building configuration.
Consider also during the installation time - how these DODAG roots will be configured?  Must I commission each device
to tell it which DODAG it must use for its Object Function?  How easy will this be to change and add in a new DODAG root
for the end user if the lighting group changes??

With respect to Jerry Martocci's - commercial building requirements - every device may need to communicate to any or
all of the end devices.  If each device must establish a DODAG for the other 499 devices in a 500 node network - How much memory
space will this require for each end device to maintain?  

Keep in mind that the end devices are very limited processor and memory wise.

Not to mention all of the network maintenance messages that would need to be transmitted to maintain all of these DODAGs.

Consider the reconvergence time when one device is turned off and it was in the middle of the majority of the 100+ DODAGS?

In many lighting and building application an application acknowledgement - must be returned {Back down the DODAG} so . . . the
requirement is not just getting to the Root - a return path must also be maintained and have a  low latency path.

Ted Humpal




From: Kris Pister <pister@eecs.berkeley.edu>
To: Anders Brandt <abr@sdesigns.dk>
Cc: ROLL WG <roll@ietf.org>
Date: 03/08/2010 01:45 PM
Subject: Re: [Roll] P2P performance with current RPL proposal




Anders - if we take JP's suggestion to make The Lamp a DODAG root, and take Phoebus' recommendation that we use path diversity to improve end-to-end reliability, do you see a chance of success?
In my experience, with diverse paths and order-minutes updates you get extremely high reliability.

I have no aversion to TTL-limited floods as a part of a solution either.  I'm open to ideas on how to bring those in as (presumably infrequently used) options.

ksjp

Anders Brandt wrote:
Hello
 
I would like to probe the temperature of the WG on using DAOs to
support P2P.
 
The building and home application spaces (and maybe others) have
a few clearly defined requirements.
It is not obvious to me how the current RPL proposal (cRPLp) can
satisfy those requirements:
 
 
In both cases it is the worst case scenario that hurts:
 
 
P2P routing inside the PAN
==========================
cRPLp has no way of routing inside the PAN if you need more than
one repeater. cRPLp has to go all the way to the top (maybe 4 hops up)
and down again (maybe 4 hops down) to get just 2 hops to the side.
 
The consequence is high latency and high levels of background noise
for nodes just outside the direct radio range.
At the same time the risk of meeting a failing link is 4 times higher =>
latency may be much more than 4 times larger.
 
Latency may sound like a minor issue but it actually translates directly
into lower battery lifetime. In the above (very realistic) example,
the battery lifetime is reduced to 25% of what it should be.
 
We have lots of battery devices sending into the network:
* PIR sensors turning on lights
* Door locks sending alarms
* Door/window sensors starting chimes
* Smoke sensors triggering an alarm system
 
 
 
 
Response time
=============
The latency issue is important.
When a user (real human being) presses a light button the user expects
the light to turn on.
cRPLp proposes that nodes in the tree periodically advertises their
presence using DAOs.
The periodicity is a real beast:
Thanks to Trickle, the rate of updates in a (apparently) stable network
is low. This is good since it leaves bandwidth for data.
But it is not good if existing routes to my lamp fail and I do not get
new routes to my lamp until it decides to send out a new DAO.
My user will (with a good reason) not tolerate waiting for minutes for
the light to turn on.
 
I have met two arguments to counter this concern:
 
A1: Well, your lamp can always send a DAO when it detects a problem.
  My answer:
  True, except that my lamp does not intend to send anything
  so it will never experience any problems from its side of the network.
 
A2: Well, you can increase the DAO rate to sub-second updates.
  My answer:
  Oh no. I get a very high degree of management traffic which
  limits my available bandwidth, increases the risk of collisions and
  even run the risk of violating EU legislation requiring me to only
  transmit in less than 1% of the time:
  http://focus.ti.com/lit/an/swra048/swra048.pdf
 868 - 868.6 MHz: <1%
 
  Reactiveness is hard to achieve via polling.
 
 
 
If you agree that this seems to be critical issues please raise your
voice on the list.
 
Going forward
=============
 
We need some reactive mechanism to reach lamps before the user decides
to sue our companies.
So is this possible? I think so.

Existing commercial (non-IP) solutions are capable of re-routing quickly
if they really have to.
 
Let me try scoping the requirements to a potential solution:
(no different from the req. docs for home and building)
 
* P2P routing in any direction independent of the tree.
 
* On-demand P2P route discovery if requested by a real-time critical app.
 Data collection apps may be able to just wait for the next DAO update.
 
* Limited range of discovery mechanism: max 4 repeaters.
  A TTL field may limit the scope of the repeaters.
 
* Suboptimal routing and traffic bursts are accepted in exchange
  for quick route repair. But only as an exception.
 
 
Just as an example, one existing home control technology uses a
(source routing) variant of AODV for quick route repair.
Nothing comes for free. The price is flooding - but not just flooding:
Managed flooding using a distributed algorithm running in all
participating nodes.
The algorithm dampens the flooding in a time, volume and range perspective.
Some similar mechanism could be built into RPL for quick route repair.
 
 
If anyone have alternative proposals, please bring it to the list.
Now is the time.
 
 
 
Thanks,
  Anders


_______________________________________________
Roll mailing 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
--------------010506050002080202030800-- --------------ms000602040106030904050208 Content-Type: application/x-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 GgUAoIIB0DAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMDAz MTExMzQzMTZaMCMGCSqGSIb3DQEJBDEWBBQHAuoPTEwtMs8wY0b/q9hbJWDZIzBfBgkqhkiG 9w0BCQ8xUjBQMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYI KoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgYUGCSsGAQQBgjcQBDF4MHYw YjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4x LDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhB0FYYcRpgg E7/iD53vjpAfMIGHBgsqhkiG9w0BCRACCzF4oHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoT HFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25h bCBGcmVlbWFpbCBJc3N1aW5nIENBAhB0FYYcRpggE7/iD53vjpAfMA0GCSqGSIb3DQEBAQUA BIIBAEadr5hT/ItyDJbQDAJTN8XOiosu0mV9DxKzylbU3DZC5VvjiiUXT0Xa29yMdvnj45f+ yU/dpatrAQa/Wq29G+FeCbYgDvREVxhK4A1OLFRxaIWV5mlnPligdzJEZinduLnSTeWlZe4C XddksB8AueSz1J5Un20lZtH22VC5trj1a1JZe+Zi0Nqc09BpiRMuFRdLdZOxUsV5/YSTFpEq qODJ8+BVqEqN5TWY7wI0rTuGP06FwSXvV/MtApyTPo0INIYRtwRwS8gvb2GY1AGSOHZKB7Hv OpONuu80+HJX1RCc0cVmhUqSjznuAxrVq2Pqxu4pp28Bl+9TAwupHTVwrDQAAAAAAAA= --------------ms000602040106030904050208-- From Jerald.P.Martocci@jci.com Thu Mar 11 06:28: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 739613A67E5; Thu, 11 Mar 2010 06:28:33 -0800 (PST) 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 4rRkuYUmw18l; Thu, 11 Mar 2010 06:28:32 -0800 (PST) Received: from exprod8og107.obsmtp.com (exprod8og107.obsmtp.com [64.18.3.94]) by core3.amsl.com (Postfix) with ESMTP id F10A03A67D7; Thu, 11 Mar 2010 06:27:48 -0800 (PST) Received: from source ([192.132.24.137]) (using SSLv3) by exprod8ob107.postini.com ([64.18.7.12]) with SMTP ID DSNKS5j96qVP0DeqBAS22nXkYI4ArSzx/lkQ@postini.com; Thu, 11 Mar 2010 06:27:55 PST Received: from jwimkrs1.na.jci.com ([10.10.6.31]) by smtpmke01.jci.com (Lotus Domino Release 8.0.1) with ESMTP id 2010031108275564-15822 ; Thu, 11 Mar 2010 08:27:55 -0600 In-Reply-To: <77b524e41003090818t658cb324x226acd8a31b57758@mail.gmail.com> References: <4B966803.5090703@acm.org> <77b524e41003090818t658cb324x226acd8a31b57758@mail.gmail.com> To: Tim Winter MIME-Version: 1.0 X-KeepSent: BA2210D8:D5EB5A86-862576E3:004E50C9; 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: Thu, 11 Mar 2010 08:27:45 -0600 X-MIMETrack: Serialize by Router on jwimkrs1.na.jci.com/NA/Johnson_Controls at 03/11/2010 08:27:48 AM, Serialize complete at 03/11/2010 08:27:48 AM, Itemize by SMTP Server on smtpmke01.jci.com/JCI_SMTP(Release 8.0.1|February 07, 2008) at 03/11/2010 08:27:55 AM, Serialize by Router on smtpmke01.jci.com/JCI_SMTP(Release 8.0.1|February 07, 2008) at 03/11/2010 08:28:02 AM, Serialize complete at 03/11/2010 08:28:02 AM Content-Type: text/html; charset="US-ASCII" Cc: ROLL WG , roll-bounces@ietf.org Subject: Re: [Roll] 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: Thu, 11 Mar 2010 14:28:33 -0000
Hi Tim,

With regard to your query regarding all-or-nothing storing nodes in RPL; I agree it's too soon to make this call.  Until the time we lock down exactly how P2P messaging will be handled to meet the performance requirements, I think we must proceed assuming a mixed network of storing and non-storing nodes.  

Having packets traverse to/through the LBR (non-storing mode) will not meet our latency requirement .  Yet expecting every sensor to store routing info (storing mode) is not acceptable from a constrained processor and memory perspective.  Once we know how P2P works for intra-LLN packet communication, hopefully the non-storing mode can be used for inter-LLN packet communication.  That would give us the performance we need in the LLN yet have the connectivity needed for communication to the outside world.

Jerry


From: Anders Jagd <anders.jagd@gmail.com>
To: Tim Winter <wintert@acm.org>
Cc: ROLL WG <roll@ietf.org>
Date: 03/09/2010 10:18 AM
Subject: Re: [Roll] Establishing downward routes in RPL : storing /        non-storing / mixed modes of operation




Tim,

I don't see that we would benefit from going as far as generally dis-allowing a mix of storing/non-storing. Granted, most networks would likely in practice be either storing on non-storing. However, I am not convinced there would not be use cases justifying a mix.

Rather than tying our hands on this, would it not be better to have each OF set rules/requirements for nodes to be "all storing", "all non-storing", or "mix" ?

I actually don't think we are able to properly answer questions like this properly before applicability work has been done - which is the main reason I don't think we should go so far as to dis-allow a mix quite yet.

/Anders
On Tue, Mar 9, 2010 at 10:23 AM, Tim Winter <wintert@acm.org> wrote:
WG,

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
_______________________________________________
Roll mailing 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 Mar 11 06:49: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 8BCF23A690F for ; Thu, 11 Mar 2010 06:49:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.576 X-Spam-Level: X-Spam-Status: No, score=-10.576 tagged_above=-999 required=5 tests=[AWL=0.022, 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 TbKTgjEklFSo for ; Thu, 11 Mar 2010 06:49:14 -0800 (PST) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id 49FFA3A6BBC for ; Thu, 11 Mar 2010 06:48:56 -0800 (PST) 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: AmQFADORmEutJV2c/2dsb2JhbACBRJkdc6Q0mHOEewQ X-IronPort-AV: E=Sophos;i="4.49,620,1262563200"; d="scan'208,217";a="216868834" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by sj-iport-3.cisco.com with ESMTP; 11 Mar 2010 14:49:01 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by rcdn-core-5.cisco.com (8.14.3/8.14.3) with ESMTP id o2BEmj3n009924; Thu, 11 Mar 2010 14:49:00 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, 11 Mar 2010 15:48:52 +0100 Received: from [64.103.29.99] ([64.103.29.99]) by xfe-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 11 Mar 2010 15:48:52 +0100 Message-Id: From: JP Vasseur To: robert.cragie@gridmerge.com, ROLL WG In-Reply-To: <4B98F374.4030301@gridmerge.com> Content-Type: multipart/alternative; boundary=Apple-Mail-42-101429916 Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 11 Mar 2010 15:48:42 +0100 References: <6D9687E95918C04A8B30A7D6DA805A3E01429F5F@zensys17.zensys.local> <4B9553B8.6010001@eecs.berkeley.edu> <4B98F374.4030301@gridmerge.com> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 11 Mar 2010 14:48:52.0641 (UTC) FILETIME=[F7A9F110:01CAC129] Cc: Ted.Humpal@jci.com Subject: Re: [Roll] P2P performance with current RPL proposal X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Mar 2010 14:49:16 -0000 --Apple-Mail-42-101429916 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Hi Robert, On Mar 11, 2010, at 2:43 PM, Robert Cragie wrote: > I agree with Ted's comments below. Creating a DODAG for every > reachable node as a root seems a very inefficient approach compared > to alternative routing algorithms. I am concerned that RPL does not > actually meet the original requirements in I-D.ietf-roll-building- > routing-reqs, I-D.ietf-roll-home-routing-reqs, RFC5673 and RFC5548. Just to re-assure you, I opened a ticket on this since we will as a WG deliver a solution for P2P that satisfy the requirements. I think that before jumping to the conclusions that RPL (as it stands) does not meet some of the requirements we need to make a careful analysis and we will. > The traffic pattern requirement for a sink node features prominently > in only two of those documents. Even in this case, as Ted points > out, communication is likely to be bidirectional (e.g. end-to-end > acks.) therefore the DODAG approach is fundamentally asymmetric, > especially if no intermediate storage is allowed for destination > routes and source routing has to be used. > > Also, RPL seems highly complex for what are constrained nodes in > terms of memory as well as power and bandwidth. Let's wait until we get numbers from implementers ... there are about 10 implementations and numbers should be provided fairly soon but early numbers show that we are talking about a few K of RAM and a dozen of K of Flash. Implementers, please chime in here to provide feed-back to the WG. > The RPL draft as it stands is 82 pages long and that doesn't include > text about the objective function. > You are right ! But we need to be careful not to judge complexity by the length of the document. I'd rather look at the FSM, which is not that complex. Just so you know, the document will be reworked, there are still redundant sections, appendix, sections that will be removed. Thanks for your comments. JP. > Robert > Robert Cragie (Pacific Gas & Electric) > > Gridmerge Ltd. > 89 Greenfield Crescent, > Wakefield, WF4 4WA, UK > +44 (0) 1924 910888 > http://www.gridmerge.com > > > > Ted.Humpal@jci.com wrote: >> >> >> A concern also will be how much overhead (memory space) will be >> required for a DODAG Root? >> >> and based on the first question how many DODAG roots a lamp may >> need to be a member of? >> >> For example in lighting a single lamp may be a root for a single >> switch (1 DODAG root), this lamp / luminaire may also >> be a member of another group - - which could be all lights on the >> floor (2nd DODAG root), and a third group >> of all the lights in the building. There can be many more >> speciality groups associated based on the building configuration. >> Consider also during the installation time - how these DODAG roots >> will be configured? Must I commission each device >> to tell it which DODAG it must use for its Object Function? How >> easy will this be to change and add in a new DODAG root >> for the end user if the lighting group changes?? >> >> With respect to Jerry Martocci's - commercial building requirements >> - every device may need to communicate to any or >> all of the end devices. If each device must establish a DODAG for >> the other 499 devices in a 500 node network - How much memory >> space will this require for each end device to maintain? >> >> Keep in mind that the end devices are very limited processor and >> memory wise. >> >> Not to mention all of the network maintenance messages that would >> need to be transmitted to maintain all of these DODAGs. >> >> Consider the reconvergence time when one device is turned off and >> it was in the middle of the majority of the 100+ DODAGS? >> >> In many lighting and building application an application >> acknowledgement - must be returned {Back down the DODAG} so . . . the >> requirement is not just getting to the Root - a return path must >> also be maintained and have a low latency path. >> >> Ted Humpal >> >> >> >> >> From: Kris Pister >> To: Anders Brandt >> Cc: ROLL WG >> Date: 03/08/2010 01:45 PM >> Subject: Re: [Roll] P2P performance with current RPL proposal >> >> >> >> >> Anders - if we take JP's suggestion to make The Lamp a DODAG root, >> and take Phoebus' recommendation that we use path diversity to >> improve end-to-end reliability, do you see a chance of success? >> In my experience, with diverse paths and order-minutes updates you >> get extremely high reliability. >> >> I have no aversion to TTL-limited floods as a part of a solution >> either. I'm open to ideas on how to bring those in as (presumably >> infrequently used) options. >> >> ksjp >> >> Anders Brandt wrote: >> Hello >> >> I would like to probe the temperature of the WG on using DAOs to >> support P2P. >> >> The building and home application spaces (and maybe others) have >> a few clearly defined requirements. >> It is not obvious to me how the current RPL proposal (cRPLp) can >> satisfy those requirements: >> >> >> In both cases it is the worst case scenario that hurts: >> >> >> P2P routing inside the PAN >> ========================== >> cRPLp has no way of routing inside the PAN if you need more than >> one repeater. cRPLp has to go all the way to the top (maybe 4 hops >> up) >> and down again (maybe 4 hops down) to get just 2 hops to the side. >> >> The consequence is high latency and high levels of background noise >> for nodes just outside the direct radio range. >> At the same time the risk of meeting a failing link is 4 times >> higher => >> latency may be much more than 4 times larger. >> >> Latency may sound like a minor issue but it actually translates >> directly >> into lower battery lifetime. In the above (very realistic) example, >> the battery lifetime is reduced to 25% of what it should be. >> >> We have lots of battery devices sending into the network: >> * PIR sensors turning on lights >> * Door locks sending alarms >> * Door/window sensors starting chimes >> * Smoke sensors triggering an alarm system >> >> >> >> >> Response time >> ============= >> The latency issue is important. >> When a user (real human being) presses a light button the user >> expects >> the light to turn on. >> cRPLp proposes that nodes in the tree periodically advertises their >> presence using DAOs. >> The periodicity is a real beast: >> Thanks to Trickle, the rate of updates in a (apparently) stable >> network >> is low. This is good since it leaves bandwidth for data. >> But it is not good if existing routes to my lamp fail and I do not >> get >> new routes to my lamp until it decides to send out a new DAO. >> My user will (with a good reason) not tolerate waiting for minutes >> for >> the light to turn on. >> >> I have met two arguments to counter this concern: >> >> A1: Well, your lamp can always send a DAO when it detects a problem. >> My answer: >> True, except that my lamp does not intend to send anything >> so it will never experience any problems from its side of the >> network. >> >> A2: Well, you can increase the DAO rate to sub-second updates. >> My answer: >> Oh no. I get a very high degree of management traffic which >> limits my available bandwidth, increases the risk of collisions and >> even run the risk of violating EU legislation requiring me to only >> transmit in less than 1% of the time: >> http://focus.ti.com/lit/an/swra048/swra048.pdf >> 868 - 868.6 MHz: <1% >> >> Reactiveness is hard to achieve via polling. >> >> >> >> If you agree that this seems to be critical issues please raise your >> voice on the list. >> >> Going forward >> ============= >> >> We need some reactive mechanism to reach lamps before the user >> decides >> to sue our companies. >> So is this possible? I think so. >> >> Existing commercial (non-IP) solutions are capable of re-routing >> quickly >> if they really have to. >> >> Let me try scoping the requirements to a potential solution: >> (no different from the req. docs for home and building) >> >> * P2P routing in any direction independent of the tree. >> >> * On-demand P2P route discovery if requested by a real-time >> critical app. >> Data collection apps may be able to just wait for the next DAO >> update. >> >> * Limited range of discovery mechanism: max 4 repeaters. >> A TTL field may limit the scope of the repeaters. >> >> * Suboptimal routing and traffic bursts are accepted in exchange >> for quick route repair. But only as an exception. >> >> >> Just as an example, one existing home control technology uses a >> (source routing) variant of AODV for quick route repair. >> Nothing comes for free. The price is flooding - but not just >> flooding: >> Managed flooding using a distributed algorithm running in all >> participating nodes. >> The algorithm dampens the flooding in a time, volume and range >> perspective. >> Some similar mechanism could be built into RPL for quick route >> repair. >> >> >> If anyone have alternative proposals, please bring it to the list. >> Now is the time. >> >> >> >> Thanks, >> Anders >> >> >> _______________________________________________ >> Roll mailing 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-42-101429916 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Hi Robert,

On = Mar 11, 2010, at 2:43 PM, Robert Cragie wrote:

I agree with Ted's comments below. = Creating a DODAG for every reachable node as a root seems a very = inefficient approach compared to alternative routing algorithms. I am = concerned that RPL does not actually meet the original requirements in = I-D.ietf-roll-building-routing-reqs, I-D.ietf-roll-home-routing-reqs, = RFC5673 and RFC5548. =

Just to re-assure = you, I opened a ticket on this since we will as a WG deliver a solution = for P2P that satisfy the requirements.
I think that before = jumping to the conclusions that RPL (as it stands) does not meet some of = the requirements we need to make a careful analysis and we = will.

The traffic pattern requirement = for a sink node features prominently in only two of those documents. = Even in this case, as Ted points out, communication is likely to be = bidirectional (e.g. end-to-end acks.) therefore the DODAG approach is = fundamentally asymmetric, especially if no intermediate storage is = allowed for destination routes and source routing has to be = used.

Also, RPL seems highly complex for what are constrained = nodes in terms of memory as well as power and bandwidth. =

Let's wait until we = get numbers from implementers ... there are about 10 implementations and = numbers should be provided
fairly soon but early numbers show = that we are talking about a few K of RAM and a dozen of K of = Flash.

Implementers, please chime in here to = provide feed-back to the WG.

The RPL draft as it stands is 82 = pages long and that doesn't include text about the objective = function.


You = are right !

But we need to be careful not to = judge complexity by the length of the document. I'd rather look at the = FSM, which is not that complex.
Just so you know, the document = will be reworked, there are still redundant sections, appendix, sections = that will be removed.

Thanks for your = comments.

JP.

Robert

Robert Cragie (Pacific Gas & = Electric)

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

<= br>
Ted.Humpal@jci.com wrote:

A concern = also will be how much overhead (memory space) will be required for a = DODAG Root? 

and based on the first question how many = DODAG roots a lamp may need to be a member of? 

For example in lighting  a single = lamp may be a root for a single switch (1 DODAG root),  this lamp / = luminaire may also 
be a member of another group - -  which could be all = lights on the floor (2nd DODAG root), and a third group 
of all the lights in the building.  There can be many = more speciality groups associated based on the building = configuration. 
Consider also during the installation time - how these DODAG = roots will be configured?  Must I commission each = device 
to tell it which DODAG it must use for = its Object Function?  How easy will this be to change and add in a = new DODAG root 
for the end user if the lighting group changes?? 

With respect to Jerry Martocci's - = commercial building requirements - every device may need to communicate = to any or 
all of the end devices.  If each device must establish = a DODAG for the other 499 devices in a 500 node network - How much = memory 
space will this require for each end = device to maintain?   

Keep in mind that the end devices are = very limited processor and memory wise. 

Not to mention all of the network = maintenance messages that would need to be transmitted to maintain all = of these DODAGs. 

Consider the reconvergence time when one = device is turned off and it was in the middle of the majority of the = 100+ DODAGS? 

In many lighting and building application = an application acknowledgement - must be returned {Back down the DODAG} = so . . . the 
requirement is not just getting to the = Root - a return path must also be maintained and have a  low = latency path. 

Ted Humpal 




From:Kris Pister <pister@eecs.berkeley.edu><= /a>
To:Anders Brandt <abr@sdesigns.dk>
Cc:ROLL = WG <roll@ietf.org>
Date:03/08/2010 01:45 PM
Subject:Re: [Roll] P2P performance with current RPL = proposal




Anders - if we take = JP's suggestion to make The Lamp a DODAG root, and take Phoebus' = recommendation that we use path diversity to improve end-to-end = reliability, do you see a chance of success?
In my experience, with = diverse paths and order-minutes updates you get extremely high = reliability.

I have no aversion to TTL-limited floods as a part = of a solution either.  I'm open to ideas on how to bring those in = as (presumably infrequently used) options.

ksjp

Anders = Brandt wrote: 
Hello 
  
I would like to probe the temperature of the WG on using DAOs = to 
support P2P. 
  
The building and home application spaces (and maybe others) = have 
a few clearly defined = requirements. 
It is not obvious to me how the current RPL proposal (cRPLp) = can 
satisfy those requirements: 
  
  
In both cases it is the worst case scenario that = hurts: 
  
  
P2P routing inside the PAN 
=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 
cRPLp has no way of routing inside the PAN if you need more = than 
one repeater. cRPLp has to go all the way to = the top (maybe 4 hops up) 
and down again (maybe 4 hops down) to get just 2 hops to the = side. 
  
The consequence is high latency and high levels of background = noise
for nodes just outside the direct radio range. 
At the same time the risk of meeting a failing link is 4 = times higher =3D> 
latency may be much more than 4 times larger. 
  
Latency may sound like a minor issue but it actually = translates directly
into lower battery lifetime. In the above (very = realistic) example, 
the battery lifetime is reduced to 25% of what it should = be. 
  
We have lots of battery devices sending into the = network: 
* PIR sensors turning on lights 
* Door locks sending alarms 
* Door/window sensors starting chimes 
* Smoke sensors triggering an alarm system 
  
  
  
  
Response time 
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D 
The latency issue is important. 
When a user (real human being) presses a light button the = user expects 
the light to turn on. 
cRPLp proposes that nodes in the tree periodically advertises = their 
presence using DAOs. 
The periodicity is a real beast: 
Thanks to Trickle, the rate of updates in a (apparently) = stable network
is low. This is good since it leaves bandwidth for = data. 
But it is not good if existing routes to my = lamp fail and I do not get 
new routes to my lamp until it decides to send out a new = DAO. 
My user will (with a good reason) not = tolerate waiting for minutes for 
the light to turn on. 
  
I have met two arguments to counter this concern: 
  
A1: Well, your lamp can always send a DAO when it detects a = problem. 
  My answer: 
  True, except that my lamp does not intend to send = anything 
  so it will never experience any problems from its side = of the network. 
  
A2: Well, you can increase the DAO rate to sub-second = updates. 
  My answer: 
  Oh no. I get a very high degree of management traffic = which 
  limits my available bandwidth, = increases the risk of collisions and 
  even run the risk of violating EU legislation = requiring me to only 
  transmit in less than 1% of the time: 
  http://focus.ti.com/lit/an/swra048/swra048.pdf
 868 - 868.6 MHz: = <1% 
  
  Reactiveness is hard to achieve via = polling. 
  
  
  
If you agree that this seems to be critical issues please = raise your 
voice on the list. 
  
Going forward 
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D 
  
We need some reactive mechanism to reach lamps before the = user decides 
to sue our companies. 
So is this possible? I think so. 

Existing commercial (non-IP) solutions are capable of = re-routing quickly 
if they really have to. 
  
Let me try scoping the requirements to a potential = solution: 
(no different from the req. docs for home and = building) 
  
* P2P routing in any direction independent of the = tree. 
  
* On-demand P2P route discovery if requested by a real-time = critical app.
 Data collection apps may be able to just wait for = the next DAO update. 
  
* Limited range of discovery mechanism: max 4 = repeaters. 
  A TTL field may limit the scope of the = repeaters. 
  
* Suboptimal routing and traffic bursts are accepted in = exchange 
  for quick route repair. But only as an = exception. 
  
  
Just as an example, one existing home control technology uses = a
(source routing) variant of AODV for quick route = repair. 
Nothing comes for free. The price is = flooding - but not just flooding:
Managed flooding using a = distributed algorithm running in all
participating nodes. 
The algorithm dampens the flooding in a time, volume and = range perspective. 
Some similar mechanism could be built into = RPL for quick route repair. 
  
  
If anyone have alternative proposals, please bring it to the = list. 
Now is the time. 
  
  
  
Thanks, 
  Anders 


_______________________________________________
Roll = mailing list
Roll@ietf.org
https://www.ietf.org/mailman/listinfo/roll
 _______________________________________________
Roll = mailing list
Roll@ietf.org
https://www.ietf.org/mailman/listinfo/roll<= font size=3D"2">



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

= --Apple-Mail-42-101429916-- From pete.st.pierre@oracle.com Thu Mar 11 11:17: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 B72953A6D2A; Thu, 11 Mar 2010 11:17:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, 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 Caeq97UzjWRR; Thu, 11 Mar 2010 11:17:44 -0800 (PST) Received: from acsinet12.oracle.com (acsinet12.oracle.com [141.146.126.234]) by core3.amsl.com (Postfix) with ESMTP id AB49F3A69A1; Thu, 11 Mar 2010 10:48:52 -0800 (PST) Received: from rcsinet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by acsinet12.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id o2BImqKj024177 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 11 Mar 2010 18:48:54 GMT Received: from acsmt353.oracle.com (acsmt353.oracle.com [141.146.40.153]) by rcsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o2BImpAI022375; Thu, 11 Mar 2010 18:48:51 GMT Received: from abhmt017.oracle.com by acsmt354.oracle.com with ESMTP id 78732841268333257; Thu, 11 Mar 2010 10:47:37 -0800 Received: from dhcp-umpk16-78-79.sfbay.sun.com (/129.146.78.79) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 11 Mar 2010 10:47:37 -0800 Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: multipart/alternative; boundary=Apple-Mail-142-115763351 From: "Pete St. Pierre" In-Reply-To: Date: Thu, 11 Mar 2010 10:47:35 -0800 Message-Id: <798CD581-16D2-4272-B6C3-426826B01871@oracle.com> References: <4B966803.5090703@acm.org> <77b524e41003090818t658cb324x226acd8a31b57758@mail.gmail.com> To: Jerald.P.Martocci@jci.com X-Mailer: Apple Mail (2.1077) X-Source-IP: acsmt353.oracle.com [141.146.40.153] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090207.4B993B14.0071:SCFMA4539814,ss=1,fgs=0 Cc: ROLL WG , roll-bounces@ietf.org Subject: Re: [Roll] 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: Thu, 11 Mar 2010 19:17:46 -0000 --Apple-Mail-142-115763351 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii I strongly agree with Jerald's comments below. On Mar 11, 2010, at 6:27 AM, Jerald.P.Martocci@jci.com wrote: >=20 > Hi Tim,=20 >=20 > With regard to your query regarding all-or-nothing storing nodes in = RPL; I agree it's too soon to make this call. Until the time we lock = down exactly how P2P messaging will be handled to meet the performance = requirements, I think we must proceed assuming a mixed network of = storing and non-storing nodes. =20 [forgive me if I'm missing something obvious, I've just tried to play = catchup on this & other roll threads.] I think we have to explicitly allow mixed-mode at this point, unless we = determine that it is either not feasible or cannot meet the full set of = requirements. =20 If we begin to enforce two separate modes non-interoperable modes, it = begins to feel to me like we have effectively created two = non-interoperable protocols that just happen to look alike because of a = shared header structure. Since we're not chartered for two separate = protocols, I think we need to reconcile the differences so they work = together in an efficient manner. ...Pete >=20 > Having packets traverse to/through the LBR (non-storing mode) will not = meet our latency requirement . Yet expecting every sensor to store = routing info (storing mode) is not acceptable from a constrained = processor and memory perspective. Once we know how P2P works for = intra-LLN packet communication, hopefully the non-storing mode can be = used for inter-LLN packet communication. That would give us the = performance we need in the LLN yet have the connectivity needed for = communication to the outside world.=20 >=20 > Jerry >=20 >=20 >=20 > From: Anders Jagd > To: Tim Winter > Cc: ROLL WG > Date: 03/09/2010 10:18 AM > Subject: Re: [Roll] Establishing downward routes in RPL : storing = / non-storing / mixed modes of operation >=20 >=20 >=20 >=20 > Tim,=20 >=20 > I don't see that we would benefit from going as far as generally = dis-allowing a mix of storing/non-storing. Granted, most networks would = likely in practice be either storing on non-storing. However, I am not = convinced there would not be use cases justifying a mix.=20 >=20 > Rather than tying our hands on this, would it not be better to have = each OF set rules/requirements for nodes to be "all storing", "all = non-storing", or "mix" ?=20 >=20 > I actually don't think we are able to properly answer questions like = this properly before applicability work has been done - which is the = main reason I don't think we should go so far as to dis-allow a mix = quite yet.=20 >=20 > /Anders >=20 > On Tue, Mar 9, 2010 at 10:23 AM, Tim Winter wrote:=20= > WG, >=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 >=20 > -Tim > _______________________________________________ > 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 > _______________________________________________ > 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 --Apple-Mail-142-115763351 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii I = strongly agree with Jerald's comments below.

On Mar = 11, 2010, at 6:27 AM, Jerald.P.Martocci@jci.com = wrote:


Hi Tim,

With regard to your query = regarding all-or-nothing storing nodes in RPL; I agree it's too soon to make this call.  Until the time we lock down exactly how P2P messaging will be handled to meet the performance requirements, I think we must proceed assuming a mixed network of storing and non-storing nodes.  

[forgive me if I'm missing = something obvious, I've just tried to play catchup on this & other = roll threads.]

I think we have to explicitly allow = mixed-mode at this point, unless we determine that it is either not = feasible or cannot meet the full set of requirements. =  

If we begin to enforce two separate = modes non-interoperable modes, it begins to feel to me like we have = effectively created two non-interoperable protocols that just happen to = look alike because of a shared header structure.  Since we're not = chartered for two separate protocols, I think we need to reconcile the = differences so they work together in an efficient = manner.

...Pete


Having packets traverse = to/through the LBR (non-storing mode) will not meet our latency requirement .  Yet expecting every sensor to store routing info (storing mode) is not = acceptable from a constrained processor and memory perspective.  Once we know how P2P works for intra-LLN packet communication, hopefully the = non-storing mode can be used for inter-LLN packet communication.  That would = give us the performance we need in the LLN yet have the connectivity needed for communication to the outside = world. 

Jerry


From: Anders Jagd <anders.jagd@gmail.com>=
To: Tim Winter <wintert@acm.org>
Cc: ROLL WG <roll@ietf.org>
Date: 03/09/2010 10:18 AM
Subject:= Re: [Roll] Establishing = downward routes in RPL : storing /        non-storing / mixed modes of operation




Tim,

I don't see that we would benefit from going as far = as generally dis-allowing a mix of storing/non-storing. Granted, most networks would likely in practice be either storing on non-storing. = However, I am not convinced there would not be use cases justifying a mix.

Rather than tying our hands on this, would it not = be better to have each OF set rules/requirements for nodes to be "all storing", "all non-storing", or "mix" ?

I actually don't think we are able to properly = answer questions like this properly before applicability work has been done - which is the main reason I don't think we should go so far as to = dis-allow a mix quite yet.

/Anders
On Tue, Mar 9, 2010 at 10:23 AM, Tim Winter = <wintert@acm.org> wrote:
WG,

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
_______________________________________________
Roll mailing list
Roll@ietf.org
https://www.ietf.org/mailman/listinfo/roll
_______________________________________________
Roll mailing list
Roll@ietf.org
https://www.ietf.org/mailman/listinfo/roll<= font size=3D"2">

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

--
Pete St. Pierre
Pete.St.Pierre@oracle.comSun Labs
Oracle 
16 Network Circle
Menlo Park, CA = 94025

= --Apple-Mail-142-115763351-- From pal@cs.stanford.edu Sun Mar 14 22:28: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 CF9D13A6A59; Sun, 14 Mar 2010 22:28:32 -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 0do2a5EPF2nY; Sun, 14 Mar 2010 22:28: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 36B833A6A5D; Sun, 14 Mar 2010 22:18:01 -0700 (PDT) Received: from [76.14.71.8] (helo=[192.168.1.104]) by cs-smtp-1.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1Nr2go-0007KR-OS; Sun, 14 Mar 2010 22:18:07 -0700 Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=iso-8859-1 From: Philip Levis In-Reply-To: <06A2C7FF-44F7-4D59-A1E0-1B21F5E99495@unina.it> Date: Sun, 14 Mar 2010 22:18:05 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20100223045634.C3F6328C44F@core3.amsl.com> <810690E8-63C2-4ADC-AF6D-2CBAD93EE5DF@thomasclausen.org> <06A2C7FF-44F7-4D59-A1E0-1B21F5E99495@unina.it> To: Marcello Caleffi X-Mailer: Apple Mail (2.1077) X-Scan-Signature: 47150f6aa31409442f7db1cf5c00e98a Cc: MANET IETF , ROLL WG , 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: Mon, 15 Mar 2010 05:28:33 -0000 On Feb 28, 2010, at 2:19 AM, Marcello Caleffi wrote: > My two cents. > I think that ETX is a better metric than hop count (maybe every not = stupid metric works better then it), however I think that sometimes we = miss the point. > The ETX estimates the expected transmission count basing on the = delivery ratios. A lot of works deal with improving the use of the = delivery ratios, but very few deal with improving the delivery ratio = estimation, which is the real key point (as it seems to me by my = simulations/experiments). So, with stupid delivery ratio estimators you = need to differentiate between links with the same ETX metric (in well = connected networks you have a lot of '1' links, while in high = dynamic/delay tolerant networks you have a lot of 'big value' links) = just because these estimators do not do their job. > Just as example, generally people use the moving average one (counting = the hello packets received and normalize to the number of hello sent), = which assigns to the sequences '0000011111' and '1111100000' the same = directional delivery ratio (0.5). > However, maybe I am boring the list with uninteresting or out-of-topic = considerations , so I stop here. Marcello, Sorry for the late reply -- I was traveling for two weeks on my = honeymoon. :) Actually, there has been a good deal of work on this topic.=20 Part of the issue is distinguishing ETX the metric (trying to estimate = the number of transmissions) from ETX the algorithm (as per DeCouto et = al.). There are algorithms for the metric that use a different names, = such as RNP, etc. The basic difference between modern approaches and the = original ETX is that they use link-layer acknowledgments from the data = path, and EWMA rather than a fixed window size. Some starting points: Kyu-Han Kim and Kang G. Shin. "On accurate measurement of link quality = in multi-hop wireless mesh networks." http://portal.acm.org/citation.cfm?id=3D1161095 Rodrigo Fonseca, Omprakash Gnawali, Kyle Jamieson, and Philip Levis. = "Four Bit Wireless Link Estimation." http://enl.usc.edu/papers/cache/Fonseca07.pdf Alberto Cerpa, Jennifer L. Wong, Miodrag Potkonjak, and Deborah Estrin. = "Temporal properties of low power wireless links: modeling and = implications on multi-hop routing." http://portal.acm.org/citation.cfm?id=3D1062689.1062741 Muhammad Hamad Alizai, Olaf Landsiedel, J=F3 =C1gila Bitsch Link, Stefan = G=F6tz, and Klaus Wehrle. "Bursty traffic over bursty links." http://portal.acm.org/citation.cfm?id=3D1644038.1644046 Phil= From pal@cs.stanford.edu Sun Mar 14 22:44: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 B574C3A6A64 for ; Sun, 14 Mar 2010 22:44:07 -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=[AWL=-0.000, 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 NP+8BFiQOAWs for ; Sun, 14 Mar 2010 22:44:05 -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 615423A6A40 for ; Sun, 14 Mar 2010 22:38:45 -0700 (PDT) Received: from [76.14.71.8] (helo=[192.168.1.104]) by cs-smtp-1.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1Nr30t-0008Kr-R7; Sun, 14 Mar 2010 22:38:52 -0700 Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: multipart/alternative; boundary=Apple-Mail-11-414039038 From: Philip Levis In-Reply-To: <4B9579EB.6040604@ieee.org> Date: Sun, 14 Mar 2010 22:38:51 -0700 Message-Id: References: <20100226011704.C9E4D28C140@core3.amsl.com> <6CE3E5D3-DAEE-45E7-9C16-1260BD345A46@cs.stanford.edu> <4B9579EB.6040604@ieee.org> To: phoebus@ieee.org X-Mailer: Apple Mail (2.1077) X-Scan-Signature: 768232f66e6ec7ed279584ab5539d282 Cc: ROLL WG Subject: Re: [Roll] Fwd: New Version Notification for draft-levis-roll-trickle-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, 15 Mar 2010 05:44:07 -0000 --Apple-Mail-11-414039038 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Mar 8, 2010, at 2:27 PM, Phoebus Chen wrote: > Phil, Omprakash, and Joakim, >=20 > Did you find any resolution to Trickle's load balancing problem that = was discussed in this previous thread? > http://www.ietf.org/mail-archive/web/roll/current/msg02707.html We've been discussing it with Joakim. The short answer is that these are contrived edge cases. They can happen = in practice, but are *very* unlikely and the next Trickle reset will = clear them. So while we do want to solve them for the sake of = completeness, (Joakim has been evaluating some ideas and showing me and = Om the results), I don't think they're a significant issue in real = situations. > This is related to the concern I raised in a previous email > http://www.ietf.org/mail-archive/web/roll/current/msg02723.html > regarding how Trickle affects the selection of parents (or how the = rules on how to defer joining a DODAG may affect Trickle's operation, = point #2 I made in the email thread). This is a good point -- the Trickle draft tries to address this, by = noting a protocol should specify what constitutes a redundant = transmission.=20 > I am concerned that the redundancy suppression mechanisms in Trickle = will suppress the DIO advertisements of some of the potential parents of = a node, and the node will end up choosing a bad parent (or bad parents). Well, do you mean bad in terms of Rank, or ba >=20 > Let me illustrate with an example: > ---------------------------------- > Assume that "DIOs that advertise the same rank" are considered = redundant, as suggested by (draft-ietf-roll-rpl-06, pg. 38, Section = 5.3.5.1.1). >=20 > Nodes A, B, and C are waiting to connect to the DODAG. Node A = connects to the DODAG first, starts it's Trickle timer, and advertises = its DIO, but C misses the message (maybe a fluke, because an 802.11 = access point happened to go off nearby). After roughly I_min, Node B = connects to the DAG (but node A is not a parent), starts it's Trickle = timer, and advertises the same rank as A. Node B may have deferred = joining the DODAG for I_min because it wanted to find a better parent. = Now, node B always has a shorter interval I than node A, so it should = always advertise its DIO before node A (since T is always within = [I/2,I]). If the redundancy constant is set to 1, then B will always = suppress A (until a packet is lost, but let's say this is uncommon). True, unless some other node suppresses B. This also assumes that B's = messages are never lost by A. RPL allows a DODAG Root to increment the = sequence number, such that Trickle timers reset in a more coherent = fashion if such problems occur. >=20 > Could you guys give your thoughts on this? Generally, it's possible to come up with constructed edge cases under = which Trickle acts poorly; in practice, the general messiness of = wireless networks (packet losses, etc.) means they rarely last long. Phil= --Apple-Mail-11-414039038 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
Phil, = Omprakash, and Joakim,

Did you find any resolution to Trickle's = load balancing problem that was discussed in this previous thread?
h= ttp://www.ietf.org/mail-archive/web/roll/current/msg02707.html

We've been discussing it with = Joakim.

The short answer is that these are = contrived edge cases. They can happen in practice, but are *very* = unlikely and the next Trickle reset will clear them. So while we do want = to solve them for the sake of completeness, (Joakim has been evaluating = some ideas and showing me and Om the results), I don't think they're a = significant issue in real situations.

This is related to the concern I raised in a previous = email
h= ttp://www.ietf.org/mail-archive/web/roll/current/msg02723.html
rega= rding how Trickle affects the selection of parents (or how the rules on = how to defer joining a DODAG may affect Trickle's operation, point #2 I = made in the email = thread).

This is a good point = -- the Trickle draft tries to address this, by noting a protocol should = specify what constitutes a redundant = transmission. 

I am = concerned that the redundancy suppression mechanisms in Trickle will = suppress the DIO advertisements of some of the potential parents of a = node, and the node will end up choosing a bad parent (or bad = parents).

Well, do you mean = bad in terms of Rank, or ba


Let me illustrate with an = example:
----------------------------------
Assume that "DIOs that = advertise the same rank" are considered redundant, as suggested by = (draft-ietf-roll-rpl-06, pg. 38, Section 5.3.5.1.1).

Nodes A, B, = and C are waiting to connect to the DODAG.  Node A connects to the = DODAG first, starts it's Trickle timer, and advertises its DIO, but C = misses the message (maybe a fluke, because an 802.11 access point = happened to go off nearby).  After roughly I_min, Node B connects = to the DAG (but node A is not a parent), starts it's Trickle timer, and = advertises the same rank as A.  Node B may have deferred joining = the DODAG for I_min because it wanted to find a better parent. =  Now, node B always has a shorter interval I than node A, so it = should always advertise its DIO before node A (since T is always within = [I/2,I]).  If the redundancy constant is set to 1, then B will = always suppress A (until a packet is lost, but let's say this is = uncommon).

True, unless some = other node suppresses B. This also assumes that B's messages are never = lost by A. RPL allows a DODAG Root to increment the sequence number, = such that Trickle timers reset in a more coherent fashion if such = problems occur.


Could you guys = give your thoughts on this?

Generally, = it's possible to come up with constructed edge cases under which Trickle = acts poorly; in practice, the general messiness of wireless networks = (packet losses, etc.) means they rarely last = long.

Phil
= --Apple-Mail-11-414039038-- From pal@cs.stanford.edu Sun Mar 14 22: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 2A85C3A67FE for ; Sun, 14 Mar 2010 22:58:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.554 X-Spam-Level: X-Spam-Status: No, score=-4.554 tagged_above=-999 required=5 tests=[AWL=0.556, BAYES_05=-1.11, 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 8YWk-0b4ZThe for ; Sun, 14 Mar 2010 22:58:03 -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 64CA93A67E2 for ; Sun, 14 Mar 2010 22:58:03 -0700 (PDT) Received: from [76.14.71.8] (helo=[192.168.1.104]) by cs-smtp-1.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1Nr3Ja-0000jP-Ep; Sun, 14 Mar 2010 22:58:10 -0700 Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Philip Levis In-Reply-To: Date: Sun, 14 Mar 2010 22:58:09 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <4FD68C85-841A-4B81-9881-0FADF31AC15C@cs.stanford.edu> References: <4B966803.5090703@acm.org> <6A2A459175DABE4BB11DE2026AA50A5D0169800A@XMB-AMS-107.cisco.com> <873a095rzx.fsf@kelsey-ws.hq.ember.com> <77b524e41003091412v568b2590mede379ee789de9a@mail.gmail.com> <6A2A459175DABE4BB11DE2026AA50A5D0169821A@XMB-AMS-107.cisco.com> <77b524e41003101022n47a4c664o8517b212e9798ed2@mail.gmail.com> To: Jonathan Hui X-Mailer: Apple Mail (2.1077) X-Scan-Signature: ae35470b07fbe4e2dbb6b33d1de23969 Cc: roll@ietf.org, Matteo Paris Subject: Re: [Roll] 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, 15 Mar 2010 05:58:04 -0000 On Mar 10, 2010, at 10:57 AM, Jonathan Hui wrote: >=20 > Hi Anders, >=20 > On Mar 10, 2010, at 10:22 AM, Anders Jagd wrote: >=20 >> That said, I still haven't heard anyone explain the core problem with = mixed environments. Mixed working solutions not being known, or maybe = being difficult to test, doesn't seem to be quite enough reason for not = considering them. How could mixed working solutions really exist when = the problem we have been facing for so long, and which the WG has made = great progress towards resolving, is that we don't have the standards = yet to allow for heterogeneous multi-vendor systems. >=20 > New standards are typically based on well-understood solutions. = Anything else would be a research project and that has no place within = the IETF. The question that so many of us have raised is whether there = are well-understood solutions for mixed-mode operation in the class of = networks we are targeting. At this point, it seems that there are not. >=20 >> If there is a fundamental problem with mixed environments (and I am = not saying there is not, I am just not aware of it - please educate me), = then fine, we can discuss if the problem is so severe that it will be = too costly/time-consuming to solve, but until then, I agree with Pascal = that we may be "throwing the baby out with the bath water". If the = problem has been analyzed previously, just point me towards the thread; = I am not trying to reopen an old discussion. >=20 >=20 > It's not that there is a fundamental problem with supporting = mixed-mode operation. It's that we have not yet found a satisfactory = solution that supports mixed-mode environments effectively while at the = same time not compromising the solutions that we care about today (fully = stateless and fully stateful environments). We have tried with one = solution, but that has its issues that make many feel uncomfortable. = See previous mails in this thread for more details. >=20 > -- > Jonathan Hui +1 Phil= From gnawali@cs.stanford.edu Mon Mar 15 01:16: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 522173A68EB for ; Mon, 15 Mar 2010 01:16:06 -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 0dVoBVUvV3nP for ; Mon, 15 Mar 2010 01:16:05 -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 B57213A6A4A for ; Mon, 15 Mar 2010 01:13:38 -0700 (PDT) Received: from qw-out-2122.google.com ([74.125.92.25]) by cs-smtp-3.Stanford.EDU with esmtpsa (TLSv1:RC4-MD5:128) (Exim 4.60) (envelope-from ) id 1Nr5Qo-0002hQ-1T for roll@ietf.org; Mon, 15 Mar 2010 01:13:46 -0700 Received: by qw-out-2122.google.com with SMTP id 9so799486qwb.31 for ; Mon, 15 Mar 2010 01:13:45 -0700 (PDT) MIME-Version: 1.0 Received: by 10.224.72.228 with SMTP id n36mr822376qaj.138.1268640825098; Mon, 15 Mar 2010 01:13:45 -0700 (PDT) In-Reply-To: References: <20100226011704.C9E4D28C140@core3.amsl.com> <6CE3E5D3-DAEE-45E7-9C16-1260BD345A46@cs.stanford.edu> <4B9579EB.6040604@ieee.org> <878wa162qe.fsf@kelsey-ws.hq.ember.com> <4B965F2B.1090206@ieee.org> From: Omprakash Gnawali Date: Mon, 15 Mar 2010 01:13:25 -0700 Message-ID: To: phoebus@ieee.org Content-Type: text/plain; charset=ISO-8859-1 X-Scan-Signature: b65b8f26ca423de213f14dca1c6ea011 Cc: "roll@ietf.org" Subject: Re: [Roll] Fwd: New Version Notification for draft-levis-roll-trickle-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, 15 Mar 2010 08:16:06 -0000 Section 5 of the draft states that Imin should not be used to specify the minimum interval. I wonder if this makes the intervals too abstract for RPL implementations. Are the implementations allowed to hard code the minimum interval? Will there be a dynamic lookup mechanism into the link layer or compile time flags to learn about the worst case latency? It is not clear if Imax should be specified as a function of the worst case link layer latency. "Worst case latency is the time until the first link-layer transmission of the frame assuming an idle channel (does not include backoff, virtual carrier sense, etc.). " Does it include preamble, etc.? Are we talking about only the function of data rate (transmisstion) ? - om_p From henning.rogge@fkie.fraunhofer.de Mon Mar 15 02:12: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 E75913A6995; Mon, 15 Mar 2010 02:12:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.753 X-Spam-Level: X-Spam-Status: No, score=-4.753 tagged_above=-999 required=5 tests=[AWL=-1.104, 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 UsFyjCfkxNUd; Mon, 15 Mar 2010 02:12:47 -0700 (PDT) Received: from mailguard.fgan.de (mailguard.fkie.fraunhofer.de [128.7.3.5]) by core3.amsl.com (Postfix) with ESMTP id 8B10C3A683A; Mon, 15 Mar 2010 02:07:11 -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 1Nr6GS-0002Hr-Eb; Mon, 15 Mar 2010 10:07:08 +0100 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 1Nr6GS-0002mf-3l; Mon, 15 Mar 2010 10:07:08 +0100 From: Henning Rogge To: roll@ietf.org Date: Mon, 15 Mar 2010 10:06:59 +0100 User-Agent: KMail/1.13.1 (Linux/2.6.31-17-generic; KDE/4.4.1; i686; ; ) References: <20100223045634.C3F6328C44F@core3.amsl.com> <06A2C7FF-44F7-4D59-A1E0-1B21F5E99495@unina.it> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1788653.EqzU8cItlF"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <201003151007.05075.henning.rogge@fkie.fraunhofer.de> X-Virus-Scanned: yes (ClamAV 0.95.3/10576/Mon Mar 15 07:02:52 2010) by mailguard.fgan.de X-Scan-Signature: 33310ad9788a957f7423ac134a469312 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: Mon, 15 Mar 2010 09:12:49 -0000 --nextPart1788653.EqzU8cItlF Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable On Mon March 15 2010 06:18:05 Philip Levis wrote: > Actually, there has been a good deal of work on this topic. >=20 > Part of the issue is distinguishing ETX the metric (trying to estimate the > number of transmissions) from ETX the algorithm (as per DeCouto et al.). > There are algorithms for the metric that use a different names, such as > RNP, etc. The basic difference between modern approaches and the original > ETX is that they use link-layer acknowledgments from the data path, If you can access layer 1/2 data this is a good idea. But the code will bec= ome=20 OS or even hardware specific. > and EWMA rather than a fixed window size. EWMA is not always better than a fixed window. > Some starting points: >=20 > Kyu-Han Kim and Kang G. Shin. "On accurate measurement of link quality in > multi-hop wireless mesh networks." > http://portal.acm.org/citation.cfm?id=3D1161095 >=20 > Rodrigo Fonseca, Omprakash Gnawali, Kyle Jamieson, and Philip Levis. "Four > Bit Wireless Link Estimation." > http://enl.usc.edu/papers/cache/Fonseca07.pdf >=20 > Alberto Cerpa, Jennifer L. Wong, Miodrag Potkonjak, and Deborah Estrin. > "Temporal properties of low power wireless links: modeling and > implications on multi-hop routing." > http://portal.acm.org/citation.cfm?id=3D1062689.1062741 >=20 > Muhammad Hamad Alizai, Olaf Landsiedel, J=F3 =C1gila Bitsch Link, Stefan = G=F6tz, > and Klaus Wehrle. "Bursty traffic over bursty links." > http://portal.acm.org/citation.cfm?id=3D1644038.1644046 Thank you for the links. 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 --nextPart1788653.EqzU8cItlF 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) iEYEABECAAYFAkud+LQACgkQRIfGfFXsz+AfNwCfYaCSA8/jYR4UkpOdadP+/2fJ mwAAmwadGWCGkXN2gnDtsOq1u9eWpZ38 =1JaC -----END PGP SIGNATURE----- --nextPart1788653.EqzU8cItlF-- From henning.rogge@fkie.fraunhofer.de Mon Mar 15 02:40: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 3CC2E3A690E; Mon, 15 Mar 2010 02:40:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.968 X-Spam-Level: X-Spam-Status: No, score=-5.968 tagged_above=-999 required=5 tests=[AWL=0.281, 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 Amee3sEDVoxN; Mon, 15 Mar 2010 02:40:41 -0700 (PDT) Received: from mailguard.fgan.de (mailguard.fkie.fraunhofer.de [128.7.3.5]) by core3.amsl.com (Postfix) with ESMTP id CDAD83A68AC; Mon, 15 Mar 2010 02:40:23 -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 1Nr6md-0002Jz-I4; Mon, 15 Mar 2010 10:40:23 +0100 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 1Nr6md-00030Y-4h; Mon, 15 Mar 2010 10:40:23 +0100 From: Henning Rogge To: roll@ietf.org Date: Mon, 15 Mar 2010 10:40:06 +0100 User-Agent: KMail/1.13.1 (Linux/2.6.31-17-generic; KDE/4.4.1; i686; ; ) References: <20100223045634.C3F6328C44F@core3.amsl.com> <06A2C7FF-44F7-4D59-A1E0-1B21F5E99495@unina.it> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart2321110.msWHyNUSNu"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <201003151040.20072.henning.rogge@fkie.fraunhofer.de> X-Virus-Scanned: yes (ClamAV 0.95.3/10576/Mon Mar 15 07:02:52 2010) by mailguard.fgan.de X-Scan-Signature: fe63cde163a9813fbfae5d53d3252e1e 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: Mon, 15 Mar 2010 09:40:45 -0000 --nextPart2321110.msWHyNUSNu Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I tracked down free available alternatives to the ACM links. On Mon March 15 2010 06:18:05 Philip Levis wrote: > Kyu-Han Kim and Kang G. Shin. "On accurate measurement of link quality in > multi-hop wireless mesh networks." > http://portal.acm.org/citation.cfm?id=3D1161095 http://www.eecs.umich.edu/~kyuhkim/papers/mobicom06Kim.pdf > Alberto Cerpa, Jennifer L. Wong, Miodrag Potkonjak, and Deborah Estrin. > "Temporal properties of low power wireless links: modeling and > implications on multi-hop routing." > http://portal.acm.org/citation.cfm?id=3D1062689.1062741 http://lecs.cs.ucla.edu/~cerpa/papers/time-estimation-tech-report.pdf =20 > Muhammad Hamad Alizai, Olaf Landsiedel, J=F3 =C1gila Bitsch Link, Stefan = G=F6tz, > and Klaus Wehrle. "Bursty traffic over bursty links." > http://portal.acm.org/citation.cfm?id=3D1644038.1644046 http://ds.informatik.rwth-aachen.de/members/alizai/publications- mha/pdfs/2009-11-alizai-bursty-traffic-over-bursty-links.pdf 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 --nextPart2321110.msWHyNUSNu 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) iEYEABECAAYFAkueAHcACgkQRIfGfFXsz+AVJACfbbhd7kxBSdYQGptS8qHmm+ay V+cAoIGLm8hbNmfgak0ONZ7H8nwMw7P2 =6wIv -----END PGP SIGNATURE----- --nextPart2321110.msWHyNUSNu-- From pthubert@cisco.com Mon Mar 15 06:28: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 625E53A695F for ; Mon, 15 Mar 2010 06:28:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.684 X-Spam-Level: X-Spam-Status: No, score=-6.684 tagged_above=-999 required=5 tests=[AWL=-0.920, BAYES_40=-0.185, EXTRA_MPART_TYPE=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, SARE_GIF_ATTACH=1.42] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O2nO7CZdWwjY for ; Mon, 15 Mar 2010 06:28:41 -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 3FC6C3A68DD for ; Mon, 15 Mar 2010 06:28:39 -0700 (PDT) Authentication-Results: ams-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-Files: image003.gif, image004.png : 87, 6279 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: An8CAIPSnUuQ/uCWe2dsb2JhbAB1T4FIln9mFQEBCwskBhyfTogvjywChA9qBA X-IronPort-AV: E=Sophos;i="4.49,643,1262563200"; d="gif'147?png'147,150?scan'147,150,208,217,147,150";a="58073537" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 15 Mar 2010 13:28: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 o2FDSjmK025427 for ; Mon, 15 Mar 2010 13:28:45 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, 15 Mar 2010 14:28:45 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----_=_NextPart_001_01CAC443.6FEBC701" Date: Mon, 15 Mar 2010 14:28:33 +0100 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D0170DE12@XMB-AMS-107.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Issue #17 Thread-Index: AcrEQ2krwJPwmGohSLqaSKhOxuTpGA== From: "Pascal Thubert (pthubert)" To: X-OriginalArrivalTime: 15 Mar 2010 13:28:45.0568 (UTC) FILETIME=[7013D000:01CAC443] Subject: [Roll] Issue #17 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 15 Mar 2010 13:28:42 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CAC443.6FEBC701 Content-Type: multipart/alternative; boundary="----_=_NextPart_002_01CAC443.6FEBC701" ------_=_NextPart_002_01CAC443.6FEBC701 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 V0c6DQoNCiANCg0KVGlja2V0IDE3IHNheXM6DQoNCuKAnA0KDQpSUEwgYWxsb3dzIHNvdXJjZSBy b3V0aW5nIGRvd24gdGhlIERBRy4gVHlwaWNhbGx5LCB0aGUgc291cmNlIHdpbGwgYmUgdGhlIHJv b3QsIGFuZCB0aGUgZGVzdGluYXRpb24gYSBub2RlIHNvbWV3aGVyZSBkb3duLiBUaGUgc291cmNl IHJvdXRlIHBhdGggbWlnaHQgYmUgc3RyaWN0IG9yIGxvb3NlLCBkZXBlbmRpbmcgb24gd2hldGhl ciBpbnRlcm1lZGlhdGUgbm9kZXMgY2FuIGFjdHVhbGx5IHN0b3JlIHN0YXRlcy4gDQoNCmEpIFdl IGNhbiBjaG9vc2UgYmV0d2VlbiAyIG1vZGVsczoga2VlcCBpbnRlcm1lZGlhdGUgU1JQIGluIHRo ZSBub2RlcyBkb3duIHRoZSBEQUcgb3Igb25seSBkbyBMU1JSIGZyb20gdGhlIHJvb3QgDQoNCmIp IEEgc291cmNlIHJvdXRlIHBhdGggbXVzdCBiZSByZWNvbXB1dGVkIGZyb20gdGhlIGRlc3RpbmF0 aW9uIHVwIHdoZW4gdGhlIHBhdGggYmV0d2VlbiB0aGUgc291cmNlIGFuZCB0aGUgZGVzdGluYXRp b24gY2hhbmdlcy4gQnV0IHRoZXJlIGlzIG5vIHdheSBmb3IgdGhlIGRlc3RpbmF0aW9uIHRvIGtu b3cgdGhhdC4gVGhhdCBpcyB3aGF0IHRoZSBkaWdlc3Qgd2FzIGZvciANCg0K4oCcDQoNCiANCg0K Rm9yIGIpIFdlIGhhdmUgaW50cm9kdWNlZCB0aGUgRFRTTiB0byByZXBsYWNlIHRoZSBkaWdlc3Qu IA0KDQogDQoNCkZvciBhKSB0aGUgY3VycmVudCBzcGVjIHBpY2tlZCB0aGUgZmlyc3QgbW9kZWwu IFdlIGFyZSBvYnNlcnZpbmcgYSBsaWdodCBjb25zZW5zdXMgdGhhdCB0aGlzIHBhdGggbGVhZCB0 b28gZmFyLiBUaHVzIGlzc3VlICMyNiBhYm91dCBzdG9yaW5nIC8gbm9uLXN0b3JpbmcgLyBtaXhl ZCBjYWNoaW5nIG5vZGVzLiBTbyBteSB0YWtlIGlzIHRoYXQgdGhpcyBwYXJ0IG9mIHRpY2tldCAj MTcgaXMgbm93IGlycmVsZXZhbnQsIHRvIGJlIGZvbGxvd2VkIG9uIHdpdGggIzI2LiBUbyBtZXJn ZSB0aGUgMiwgd2UgbmVlZCB0byBjb25zaWRlciBMU1JSIGFzIGFuIGFsdGVybmF0ZSBpbiAjMjYu DQoNCiANCg0KRm9yIGFsbCBJIGtub3csIEkgdGhpbmsgdGhhdCB3ZSBjYW4gY2xvc2UgIzE3LCBh dCBsZWFzdCBpZiB3ZSBpbmNsdWRlIHRoZSBMU1JSIG9wdGlvbiBpbiAjMjYuIA0KDQogDQoNCldo YXQgZG8geW91IHRoaW5rPw0KDQogDQoNCiANCg0KCQ0KUGFzY2FsIFRodWJlcnQNCkVuZ2luZWVy LnNvZnR3YXJlIEVuZ2luZWVyaW5nDQpQcm9kdWN0IERldmVsb3BtZW50DQpwdGh1YmVydEBjaXNj by5jb20gPG1haWx0bzpwdGh1YmVydEBjaXNjby5jb20+IA0KUGhvbmU6ICszMyA0IDk3MjMgMjYz NA0KTW9iaWxlOiArMzMgNiAxOTk4IDI5ODUNCg0KDQoNCkNpc2NvIFN5c3RlbXMgRnJhbmNlDQpW aWxsYWdlIGQnRW50cmVwcmlzZXMgR3JlZW4gU2lkZQ0KNDAwIEF2ZW51ZSBkZSBSb3VtYW5pbGxl IA0KQmF0aW1lbnQgVCAzIA0KMDY0MTAgDQpCSU9UIC0gU09QSElBIEFOVElQT0xJUw0KRnJhbmNl DQpDaXNjby5jb20gPGh0dHA6Ly93d3cuY2lzY28uY29tL2dsb2JhbC9GUi8+IA0KDQogIA0KDQog DQoNCiBUaGluayBiZWZvcmUgeW91IHByaW50Lg0KDQpDaXNjbyBTeXN0ZW1zIEZyYW5jZSwgU29j acOpdMOpIMOgIHJlc3BvbnNhYmlpdMOpIGxpbWl0w6llLCBSdWUgQ2FtaWxsZSBEZXNtb3VsaW5z IOKAkyBJbW0gQXRsYW50aXMgWmFjIEZvcnVtIFNlaW5lIElsb3QgNyA5MjEzMCBJc3N5IGxlcyBN b3VsaW5lYXV4LCBBdSBjYXBpdGFsIGRlIDkxLjQ3MCDigqwsIDM0OSAxNjYgNTYxIFJDUyBOYW50 ZXJyZSwgRGlyZWN0ZXVyIGRlIGxhIHB1YmxpY2F0aW9uOiBKZWFuLUx1YyBNaWNoZWwgR2l2b25l LCBGb3IgY29ycG9yYXRlIGxlZ2FsIGluZm9ybWF0aW9uIGdvIHRvOg0KaHR0cDovL3d3dy5jaXNj by5jb20vd2ViL2Fib3V0L2RvaW5nX2J1c2luZXNzL2xlZ2FsL2NyaS9pbmRleC5odG1sIDxodHRw Oi8vd3d3LmNpc2NvLmNvbS93ZWIvYWJvdXQvZG9pbmdfYnVzaW5lc3MvbGVnYWwvY3JpL2luZGV4 Lmh0bWw+IA0KDQogDQoNCiANCg0K ------_=_NextPart_002_01CAC443.6FEBC701 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij48bWV0YSBuYW1lPUdlbmVyYXRvciBjb250ZW50 PSJNaWNyb3NvZnQgV29yZCAxNCAoZmlsdGVyZWQgbWVkaXVtKSI+PCEtLVtpZiAhbXNvXT48c3R5 bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7YmVoYXZpb3I6dXJs KCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0KLnNo YXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwhW2VuZGlmXS0tPjxz dHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFt aWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7 fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRp di5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9u dC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCW1z by1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7 bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVu ZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0 eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJs aW5lO30NCnAuTXNvQWNldGF0ZSwgbGkuTXNvQWNldGF0ZSwgZGl2Lk1zb0FjZXRhdGUNCgl7bXNv LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJUZXh0ZSBkZSBidWxsZXMgQ2Fy IjsNCgltYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6OC4w cHQ7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiOw0KCW1zby1mYXJlYXN0LWxh bmd1YWdlOkVOLVVTO30NCnNwYW4uRW1haWxTdHlsZTE3DQoJe21zby1zdHlsZS10eXBlOnBlcnNv bmFsLWNvbXBvc2U7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xv cjp3aW5kb3d0ZXh0O30NCnNwYW4uVGV4dGVkZWJ1bGxlc0Nhcg0KCXttc28tc3R5bGUtbmFtZToi VGV4dGUgZGUgYnVsbGVzIENhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHls ZS1saW5rOiJUZXh0ZSBkZSBidWxsZXMiOw0KCWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNl cmlmIjt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglm b250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCW1zby1mYXJlYXN0LWxhbmd1YWdl OkVOLVVTO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCglt YXJnaW46NzAuODVwdCA3MC44NXB0IDcwLjg1cHQgNzAuODVwdDt9DQpkaXYuV29yZFNlY3Rpb24x DQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4 bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94 bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2 OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFw ZWxheW91dD48L3htbD48IVtlbmRpZl0tLT48L2hlYWQ+PGJvZHkgbGFuZz1GUiBsaW5rPWJsdWUg dmxpbms9cHVycGxlPjxkaXYgY2xhc3M9V29yZFNlY3Rpb24xPjxwIGNsYXNzPU1zb05vcm1hbD48 c3BhbiBsYW5nPUVOLVVTPldHOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3Jt YWw+PHNwYW4gbGFuZz1FTi1VUz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9 TXNvTm9ybWFsPjxzcGFuIGxhbmc9RU4tVVM+VGlja2V0IDE3IHNheXM6PG86cD48L286cD48L3Nw YW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBsYW5nPUVOLVVTPuKAnDxvOnA+PC9vOnA+ PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gbGFuZz1FTi1VUz5SUEwgYWxsb3dz IHNvdXJjZSByb3V0aW5nIGRvd24gdGhlIERBRy4gVHlwaWNhbGx5LCB0aGUgc291cmNlIHdpbGwg YmUgdGhlIHJvb3QsIGFuZCB0aGUgZGVzdGluYXRpb24gYSBub2RlIHNvbWV3aGVyZSBkb3duLiBU aGUgc291cmNlIHJvdXRlIHBhdGggbWlnaHQgYmUgc3RyaWN0IG9yIGxvb3NlLCBkZXBlbmRpbmcg b24gd2hldGhlciBpbnRlcm1lZGlhdGUgbm9kZXMgY2FuIGFjdHVhbGx5IHN0b3JlIHN0YXRlcy4g PG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBsYW5nPUVOLVVT PmEpIFdlIGNhbiBjaG9vc2UgYmV0d2VlbiAyIG1vZGVsczoga2VlcCBpbnRlcm1lZGlhdGUgU1JQ IGluIHRoZSBub2RlcyBkb3duIHRoZSBEQUcgb3Igb25seSBkbyBMU1JSIGZyb20gdGhlIHJvb3Qg PG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBsYW5nPUVOLVVT PmIpIEEgc291cmNlIHJvdXRlIHBhdGggbXVzdCBiZSByZWNvbXB1dGVkIGZyb20gdGhlIGRlc3Rp bmF0aW9uIHVwIHdoZW4gdGhlIHBhdGggYmV0d2VlbiB0aGUgc291cmNlIGFuZCB0aGUgZGVzdGlu YXRpb24gY2hhbmdlcy4gQnV0IHRoZXJlIGlzIG5vIHdheSBmb3IgdGhlIGRlc3RpbmF0aW9uIHRv IGtub3cgdGhhdC4gVGhhdCBpcyB3aGF0IHRoZSBkaWdlc3Qgd2FzIGZvciA8bzpwPjwvbzpwPjwv c3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIGxhbmc9RU4tVVM+4oCcPG86cD48L286 cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBsYW5nPUVOLVVTPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gbGFuZz1FTi1VUz5G b3IgYikgV2UgaGF2ZSBpbnRyb2R1Y2VkIHRoZSBEVFNOIHRvIHJlcGxhY2UgdGhlIGRpZ2VzdC4g PG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBsYW5nPUVOLVVT PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gbGFu Zz1FTi1VUz5Gb3IgYSkgdGhlIGN1cnJlbnQgc3BlYyBwaWNrZWQgdGhlIGZpcnN0IG1vZGVsLiBX ZSBhcmUgb2JzZXJ2aW5nIGEgbGlnaHQgY29uc2Vuc3VzIHRoYXQgdGhpcyBwYXRoIGxlYWQgdG9v IGZhci4gVGh1cyBpc3N1ZSAjMjYgYWJvdXQgc3RvcmluZyAvIG5vbi1zdG9yaW5nIC8gbWl4ZWQg Y2FjaGluZyBub2Rlcy4gU28gbXkgdGFrZSBpcyB0aGF0IHRoaXMgcGFydCBvZiB0aWNrZXQgIzE3 IGlzIG5vdyBpcnJlbGV2YW50LCB0byBiZSBmb2xsb3dlZCBvbiB3aXRoICMyNi4gVG8gbWVyZ2Ug dGhlIDIsIHdlIG5lZWQgdG8gY29uc2lkZXIgTFNSUiBhcyBhbiBhbHRlcm5hdGUgaW4gIzI2Ljxv OnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gbGFuZz1FTi1VUz48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIGxhbmc9 RU4tVVM+Rm9yIGFsbCBJIGtub3csIEkgdGhpbmsgdGhhdCB3ZSBjYW4gY2xvc2UgIzE3LCBhdCBs ZWFzdCBpZiB3ZSBpbmNsdWRlIHRoZSBMU1JSIG9wdGlvbiBpbiAjMjYuIDxvOnA+PC9vOnA+PC9z cGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gbGFuZz1FTi1VUz48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIGxhbmc9RU4tVVM+V2hhdCBk byB5b3UgdGhpbms/PG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3Bh biBsYW5nPUVOLVVTPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3Jt YWw+PHNwYW4gbGFuZz1FTi1VUz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PHRhYmxlIGNs YXNzPU1zb05vcm1hbFRhYmxlIGJvcmRlcj0wIGNlbGxzcGFjaW5nPTAgY2VsbHBhZGRpbmc9MCB3 aWR0aD01NDMgc3R5bGU9J3dpZHRoOjQwNy4yNXB0Jz48dHI+PHRkIHN0eWxlPSdwYWRkaW5nOjBj bSAwY20gMGNtIDBjbSc+PHRhYmxlIGNsYXNzPU1zb05vcm1hbFRhYmxlIGJvcmRlcj0wIGNlbGxz cGFjaW5nPTAgY2VsbHBhZGRpbmc9MCB3aWR0aD02MDAgc3R5bGU9J3dpZHRoOjQ1MC4wNXB0Jz48 dHI+PHRkIGNvbHNwYW49MyBzdHlsZT0ncGFkZGluZzowY20gMGNtIDBjbSAwY20nPjwvdGQ+PC90 cj48dHIgc3R5bGU9J2hlaWdodDo5NC4wNXB0Jz48dGQgbm93cmFwIHZhbGlnbj10b3Agc3R5bGU9 J3BhZGRpbmc6MGNtIDBjbSAxMS4yNXB0IDE4LjBwdDtoZWlnaHQ6OTQuMDVwdCc+PHAgY2xhc3M9 TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJnaW4tYm90dG9tOjEy LjBwdCc+PGI+PHNwYW4gbGFuZz1FTi1VUyBzdHlsZT0nZm9udC1zaXplOjguNXB0O2ZvbnQtZmFt aWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiO2NvbG9yOiM2NjY2NjY7bXNvLWZhcmVhc3QtbGFuZ3Vh Z2U6RlInPlBhc2NhbCBUaHViZXJ0PC9zcGFuPjwvYj48c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdm b250LXNpemU6OC41cHQ7Zm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiI7Y29sb3I6IzY2 NjY2Njttc28tZmFyZWFzdC1sYW5ndWFnZTpGUic+PGJyPjxiPkVuZ2luZWVyLnNvZnR3YXJlIEVu Z2luZWVyaW5nPC9iPjxicj48Yj5Qcm9kdWN0IERldmVsb3BtZW50PC9iPjxicj48L3NwYW4+PHNw YW4gc3R5bGU9J2ZvbnQtc2l6ZTo4LjVwdDtmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlm Ijtjb2xvcjojNjY2NjY2O21zby1mYXJlYXN0LWxhbmd1YWdlOkZSJz48YSBocmVmPSJtYWlsdG86 cHRodWJlcnRAY2lzY28uY29tIj48c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdjb2xvcjojNjY2NjY2 Jz5wdGh1YmVydEBjaXNjby5jb208L3NwYW4+PC9hPjwvc3Bhbj48c3BhbiBsYW5nPUVOLVVTIHN0 eWxlPSdmb250LXNpemU6OC41cHQ7Zm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiI7Y29s b3I6IzY2NjY2Njttc28tZmFyZWFzdC1sYW5ndWFnZTpGUic+PGJyPlBob25lOiA8Yj4rMzMgNCA5 NzIzIDI2MzQ8L2I+PGJyPk1vYmlsZTogPGI+KzMzIDYgMTk5OCAyOTg1PC9iPjxicj48YnI+PG86 cD48L286cD48L3NwYW4+PC9wPjwvdGQ+PHRkIG5vd3JhcCB2YWxpZ249dG9wIHN0eWxlPSdwYWRk aW5nOjBjbSAwY20gNy41cHQgMTUuMHB0O2hlaWdodDo5NC4wNXB0Jz48cCBjbGFzcz1Nc29Ob3Jt YWwgc3R5bGU9J21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21hcmdpbi1ib3R0b206MTIuMHB0Jz48 Yj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjguNXB0O2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMt c2VyaWYiO2NvbG9yOiM2NjY2NjY7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RlInPkNpc2NvIFN5c3Rl bXMgRnJhbmNlPC9zcGFuPjwvYj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjguNXB0O2ZvbnQtZmFt aWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiO2NvbG9yOiM2NjY2NjY7bXNvLWZhcmVhc3QtbGFuZ3Vh Z2U6RlInPjxicj5WaWxsYWdlIGQnRW50cmVwcmlzZXMgR3JlZW4gU2lkZTxicj40MDAgQXZlbnVl IGRlIFJvdW1hbmlsbGUgPGJyPkJhdGltZW50IFQgMyA8YnI+MDY0MTAgPGJyPkJJT1QgLSBTT1BI SUEgQU5USVBPTElTPGJyPkZyYW5jZTxicj48YSBocmVmPSJodHRwOi8vd3d3LmNpc2NvLmNvbS9n bG9iYWwvRlIvIj48c3BhbiBzdHlsZT0nY29sb3I6IzY2NjY2Nic+Q2lzY28uY29tPC9zcGFuPjwv YT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC90ZD48dGQgd2lkdGg9MTg2IHN0eWxlPSd3aWR0aDox MzkuNzVwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDBjbTtoZWlnaHQ6OTQuMDVwdCc+PHAgY2xhc3M9 TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiJUaW1l cyBOZXcgUm9tYW4iLCJzZXJpZiI7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RlInPiZuYnNwOzxpbWcg Ym9yZGVyPTAgd2lkdGg9MTY0IGhlaWdodD0xMDggaWQ9IkltYWdlX3gwMDIwXzEiIHNyYz0iY2lk OmltYWdlMDA0LnBuZ0AwMUNBQzQ0Qi5DQUVFRjY1MCI+PG86cD48L286cD48L3NwYW4+PC9wPjwv dGQ+PC90cj48L3RhYmxlPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXpl OjEyLjBwdDtmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO2Rpc3BsYXk6bm9u ZTttc28tZmFyZWFzdC1sYW5ndWFnZTpGUic+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjx0 YWJsZSBjbGFzcz1Nc29Ob3JtYWxUYWJsZSBib3JkZXI9MCBjZWxsc3BhY2luZz0wIGNlbGxwYWRk aW5nPTAgd2lkdGg9NzE5IHN0eWxlPSd3aWR0aDo1MzkuMTVwdCc+PHRyIHN0eWxlPSdoZWlnaHQ6 OTAuOHB0Jz48dGQgd2lkdGg9NzE5IHN0eWxlPSd3aWR0aDo1MzkuMTVwdDtwYWRkaW5nOjBjbSAx OC4wcHQgMGNtIDE4LjBwdDtoZWlnaHQ6OTAuOHB0Jz48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4g c3R5bGU9J2ZvbnQtc2l6ZTo3LjVwdDtmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIjtj b2xvcjojMDA5OTAwO21zby1mYXJlYXN0LWxhbmd1YWdlOkZSJz48aW1nIGJvcmRlcj0wIHdpZHRo PTE4IGhlaWdodD0xOSBpZD0iSW1hZ2VfeDAwMjBfMiIgc3JjPSJjaWQ6aW1hZ2UwMDMuZ2lmQDAx Q0FDNDQ5LjhDMjZDQzEwIiBhbHQ9IlRoaW5rIGJlZm9yZSB5b3UgcHJpbnQuIj5UaGluayBiZWZv cmUgeW91IHByaW50Ljxicj48YnI+PC9zcGFuPjxzcGFuIHN0eWxlPSdmb250LXNpemU6Ny41cHQ7 Zm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiI7Y29sb3I6Izk5OTk5OTttc28tZmFyZWFz dC1sYW5ndWFnZTpGUic+Q2lzY28gU3lzdGVtcyBGcmFuY2UsIFNvY2nDqXTDqSDDoCByZXNwb25z YWJpaXTDqSBsaW1pdMOpZSwgUnVlIENhbWlsbGUgRGVzbW91bGlucyDigJMgSW1tIEF0bGFudGlz IFphYyBGb3J1bSBTZWluZSBJbG90IDcgOTIxMzAgSXNzeSBsZXMgTW91bGluZWF1eCwgQXUgY2Fw aXRhbCBkZSA5MS40NzAg4oKsLCAzNDkgMTY2IDU2MSBSQ1MgTmFudGVycmUsIERpcmVjdGV1ciBk ZSBsYSBwdWJsaWNhdGlvbjogSmVhbi1MdWMgTWljaGVsIEdpdm9uZSwgRm9yIGNvcnBvcmF0ZSBs ZWdhbCBpbmZvcm1hdGlvbiBnbyB0bzo8YnI+PGEgaHJlZj0iaHR0cDovL3d3dy5jaXNjby5jb20v d2ViL2Fib3V0L2RvaW5nX2J1c2luZXNzL2xlZ2FsL2NyaS9pbmRleC5odG1sIj48c3BhbiBzdHls ZT0nY29sb3I6Ymx1ZSc+aHR0cDovL3d3dy5jaXNjby5jb20vd2ViL2Fib3V0L2RvaW5nX2J1c2lu ZXNzL2xlZ2FsL2NyaS9pbmRleC5odG1sPC9zcGFuPjwvYT48L3NwYW4+PHNwYW4gc3R5bGU9J2Zv bnQtc2l6ZTo3LjVwdDtmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIjtjb2xvcjojMDA5 OTAwO21zby1mYXJlYXN0LWxhbmd1YWdlOkZSJz48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC90ZD48 L3RyPjwvdGFibGU+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdtc28tZmFyZWFzdC1s YW5ndWFnZTpGUic+PG86cD48L286cD48L3NwYW4+PC9wPjwvdGQ+PC90cj48L3RhYmxlPjxwIGNs YXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RlInPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PG86cD4mbmJzcDs8L286 cD48L3A+PC9kaXY+PC9ib2R5PjwvaHRtbD4= ------_=_NextPart_002_01CAC443.6FEBC701-- ------_=_NextPart_001_01CAC443.6FEBC701 Content-Type: image/gif; name="image003.gif" Content-Transfer-Encoding: base64 Content-ID: Content-Description: image003.gif Content-Location: image003.gif R0lGODlhEgATAJEAAAAAAP///wCZAP///yH5BAEAAAMALAAAAAASABMAAAIojI+pGyK8nINqUiTf bVnfvHEg1UmhdZRqaawu6XZVjKb0/CYxo8JOAQA7 ------_=_NextPart_001_01CAC443.6FEBC701 Content-Type: image/png; name="image004.png" Content-Transfer-Encoding: base64 Content-ID: Content-Description: image004.png Content-Location: image004.png 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_001_01CAC443.6FEBC701-- From pthubert@cisco.com Mon Mar 15 09:24: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 5C9FF3A6BC6 for ; Mon, 15 Mar 2010 09:24:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=x tagged_above=-999 required=5 tests=[] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TDg5k0jCbH-r for ; Mon, 15 Mar 2010 09:24: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 DB3393A6BF2 for ; Mon, 15 Mar 2010 09:24:05 -0700 (PDT) Authentication-Results: ams-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-Files: DAGPtP.pdf : 310397 X-IronPort-AV: E=Sophos;i="4.49,644,1262563200"; d="pdf'?scan'208,217";a="4358066" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-2.cisco.com with ESMTP; 15 Mar 2010 15:50:37 +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 o2FGOCcv017058; Mon, 15 Mar 2010 16:24:12 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, 15 Mar 2010 17:24:12 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01CAC45B.F213E524" Date: Mon, 15 Mar 2010 17:24:01 +0100 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D0170DFA9@XMB-AMS-107.cisco.com> In-Reply-To: <4B98F374.4030301@gridmerge.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] P2P performance with current RPL proposal Thread-Index: AcrBIO0mcBW5di9DSESfrbyVRyBbFwDOfAKw References: <6D9687E95918C04A8B30A7D6DA805A3E01429F5F@zensys17.zensys.local> <4B9553B8.6010001@eecs.berkeley.edu> <4B98F374.4030301@gridmerge.com> From: "Pascal Thubert (pthubert)" To: , X-OriginalArrivalTime: 15 Mar 2010 16:24:12.0060 (UTC) FILETIME=[F25B05C0:01CAC45B] X-Mailman-Approved-At: Mon, 15 Mar 2010 09:28:49 -0700 Cc: ROLL WG Subject: Re: [Roll] P2P performance with current RPL proposal X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Mar 2010 16:24:12 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CAC45B.F213E524 Content-Type: multipart/alternative; boundary="----_=_NextPart_002_01CAC45B.F213E524" ------_=_NextPart_002_01CAC45B.F213E524 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable HI Robert : =20 I respectfully have to disagree. =20 My understanding is that we are considering a limited set of P2P pairs, for which the specific path that we need to create might have to obey specific constraints.=20 So it makes sense to use an on-demand technique, probably inspired by the MANET Reactive protocols. =20 As it goes, those protocols usually use flooding for a node to locate another. Forking a DAG is just another flooding. It does not take a lot of addition to the existing DIO for a root to use RPL to build a DAG that contains one or multiple Targets as leaves, under a set of constraints expressed as an objective function. Please find attached a slideware that illustrates that. =20 Pascal =20 From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Robert Cragie Sent: Thursday, March 11, 2010 2:43 PM To: Ted.Humpal@jci.com Cc: ROLL WG Subject: Re: [Roll] P2P performance with current RPL proposal =20 I agree with Ted's comments below. Creating a DODAG for every reachable node as a root seems a very inefficient approach compared to alternative routing algorithms. I am concerned that RPL does not actually meet the original requirements in I-D.ietf-roll-building-routing-reqs, I-D.ietf-roll-home-routing-reqs, RFC5673 and RFC5548. The traffic pattern requirement for a sink node features prominently in only two of those documents. Even in this case, as Ted points out, communication is likely to be bidirectional (e.g. end-to-end acks.) therefore the DODAG approach is fundamentally asymmetric, especially if no intermediate storage is allowed for destination routes and source routing has to be used. Also, RPL seems highly complex for what are constrained nodes in terms of memory as well as power and bandwidth. The RPL draft as it stands is 82 pages long and that doesn't include text about the objective function. Robert Robert Cragie (Pacific Gas & Electric) Gridmerge Ltd. 89 Greenfield Crescent, Wakefield, WF4 4WA, UK +44 (0) 1924 910888 http://www.gridmerge.com =20 Ted.Humpal@jci.com wrote:=20 A concern also will be how much overhead (memory space) will be required for a DODAG Root?=20 and based on the first question how many DODAG roots a lamp may need to be a member of?=20 For example in lighting a single lamp may be a root for a single switch (1 DODAG root), this lamp / luminaire may also=20 be a member of another group - - which could be all lights on the floor (2nd DODAG root), and a third group=20 of all the lights in the building. There can be many more speciality groups associated based on the building configuration.=20 Consider also during the installation time - how these DODAG roots will be configured? Must I commission each device=20 to tell it which DODAG it must use for its Object Function? How easy will this be to change and add in a new DODAG root=20 for the end user if the lighting group changes??=20 With respect to Jerry Martocci's - commercial building requirements - every device may need to communicate to any or=20 all of the end devices. If each device must establish a DODAG for the other 499 devices in a 500 node network - How much memory=20 space will this require for each end device to maintain? =20 Keep in mind that the end devices are very limited processor and memory wise.=20 Not to mention all of the network maintenance messages that would need to be transmitted to maintain all of these DODAGs.=20 Consider the reconvergence time when one device is turned off and it was in the middle of the majority of the 100+ DODAGS?=20 In many lighting and building application an application acknowledgement - must be returned {Back down the DODAG} so . . . the=20 requirement is not just getting to the Root - a return path must also be maintained and have a low latency path.=20 Ted Humpal=20 From:=20 Kris Pister To:=20 Anders Brandt =20 Cc:=20 ROLL WG =20 Date:=20 03/08/2010 01:45 PM=20 Subject:=20 Re: [Roll] P2P performance with current RPL proposal =20 ________________________________ Anders - if we take JP's suggestion to make The Lamp a DODAG root, and take Phoebus' recommendation that we use path diversity to improve end-to-end reliability, do you see a chance of success? In my experience, with diverse paths and order-minutes updates you get extremely high reliability. I have no aversion to TTL-limited floods as a part of a solution either. I'm open to ideas on how to bring those in as (presumably infrequently used) options. ksjp Anders Brandt wrote:=20 Hello=20 =20 I would like to probe the temperature of the WG on using DAOs to=20 support P2P.=20 =20 The building and home application spaces (and maybe others) have=20 a few clearly defined requirements.=20 It is not obvious to me how the current RPL proposal (cRPLp) can=20 satisfy those requirements:=20 =20 =20 In both cases it is the worst case scenario that hurts:=20 =20 =20 P2P routing inside the PAN=20 =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=20 cRPLp has no way of routing inside the PAN if you need more than=20 one repeater. cRPLp has to go all the way to the top (maybe 4 hops up)=20 and down again (maybe 4 hops down) to get just 2 hops to the side.=20 =20 The consequence is high latency and high levels of background noise for nodes just outside the direct radio range.=20 At the same time the risk of meeting a failing link is 4 times higher = =3D> latency may be much more than 4 times larger.=20 =20 Latency may sound like a minor issue but it actually translates directly into lower battery lifetime. In the above (very realistic) example,=20 the battery lifetime is reduced to 25% of what it should be.=20 =20 We have lots of battery devices sending into the network:=20 * PIR sensors turning on lights=20 * Door locks sending alarms=20 * Door/window sensors starting chimes=20 * Smoke sensors triggering an alarm system=20 =20 =20 =20 =20 Response time=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=20 The latency issue is important.=20 When a user (real human being) presses a light button the user expects=20 the light to turn on.=20 cRPLp proposes that nodes in the tree periodically advertises their=20 presence using DAOs.=20 The periodicity is a real beast:=20 Thanks to Trickle, the rate of updates in a (apparently) stable network is low. This is good since it leaves bandwidth for data.=20 But it is not good if existing routes to my lamp fail and I do not get=20 new routes to my lamp until it decides to send out a new DAO.=20 My user will (with a good reason) not tolerate waiting for minutes for=20 the light to turn on.=20 =20 I have met two arguments to counter this concern:=20 =20 A1: Well, your lamp can always send a DAO when it detects a problem.=20 My answer:=20 True, except that my lamp does not intend to send anything=20 so it will never experience any problems from its side of the network. =20 A2: Well, you can increase the DAO rate to sub-second updates.=20 My answer:=20 Oh no. I get a very high degree of management traffic which=20 limits my available bandwidth, increases the risk of collisions and=20 even run the risk of violating EU legislation requiring me to only=20 transmit in less than 1% of the time:=20 http://focus.ti.com/lit/an/swra048/swra048.pdf =20 868 - 868.6 MHz: <1%=20 =20 Reactiveness is hard to achieve via polling.=20 =20 =20 =20 If you agree that this seems to be critical issues please raise your=20 voice on the list.=20 =20 Going forward=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=20 =20 We need some reactive mechanism to reach lamps before the user decides=20 to sue our companies.=20 So is this possible? I think so.=20 Existing commercial (non-IP) solutions are capable of re-routing quickly if they really have to.=20 =20 Let me try scoping the requirements to a potential solution:=20 (no different from the req. docs for home and building)=20 =20 * P2P routing in any direction independent of the tree.=20 =20 * On-demand P2P route discovery if requested by a real-time critical app. Data collection apps may be able to just wait for the next DAO update.=20 =20 * Limited range of discovery mechanism: max 4 repeaters.=20 A TTL field may limit the scope of the repeaters.=20 =20 * Suboptimal routing and traffic bursts are accepted in exchange=20 for quick route repair. But only as an exception.=20 =20 =20 Just as an example, one existing home control technology uses a (source routing) variant of AODV for quick route repair.=20 Nothing comes for free. The price is flooding - but not just flooding: Managed flooding using a distributed algorithm running in all participating nodes.=20 The algorithm dampens the flooding in a time, volume and range perspective.=20 Some similar mechanism could be built into RPL for quick route repair.=20 =20 =20 If anyone have alternative proposals, please bring it to the list.=20 Now is the time.=20 =20 =20 =20 Thanks,=20 Anders=20 ________________________________ _______________________________________________ Roll mailing list Roll@ietf.org =20 https://www.ietf.org/mailman/listinfo/roll =20 _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll =20 =20 ________________________________ =20 _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll =20 ------_=_NextPart_002_01CAC45B.F213E524 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

HI Robert :

 

I respectfully have to disagree.

 

My understanding is that we are considering a limited set of P2P = pairs, for which the specific path that we need to create might have to = obey specific constraints.

So it makes sense to use an on-demand technique, probably inspired by = the MANET Reactive protocols.

 

As it goes, those protocols usually use flooding for a node to locate = another. Forking a DAG is just another flooding. It does not take a lot = of addition to the existing DIO for a root to use RPL to build a DAG = that contains one or multiple Targets as leaves, under a set of = constraints expressed as an objective function. Please find attached a = slideware that illustrates that.

 

Pascal

 

From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf = Of Robert Cragie
Sent: Thursday, March 11, 2010 2:43 = PM
To: Ted.Humpal@jci.com
Cc: ROLL = WG
Subject: Re: [Roll] P2P performance with current RPL = proposal

 

I agree with Ted's comments = below. Creating a DODAG for every reachable node as a root seems a very = inefficient approach compared to alternative routing algorithms. I am = concerned that RPL does not actually meet the original requirements in = I-D.ietf-roll-building-routing-reqs, I-D.ietf-roll-home-routing-reqs, = RFC5673 and RFC5548. The traffic pattern requirement for a sink node = features prominently in only two of those documents. Even in this case, = as Ted points out, communication is likely to be bidirectional (e.g. = end-to-end acks.) therefore the DODAG approach is fundamentally = asymmetric, especially if no intermediate storage is allowed for = destination routes and source routing has to be used.

Also, RPL = seems highly complex for what are constrained nodes in terms of memory = as well as power and bandwidth. The RPL draft as it stands is 82 pages = long and that doesn't include text about the objective = function.

Robert

Robert = Cragie (Pacific Gas & Electric)

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



Ted.Humpal@jci.com wrote: =


A concern = also will be how much overhead (memory space) will be required for a = DODAG Root?

and based on = the first question how many DODAG roots a lamp may need to be a member = of?

For example = in lighting  a single lamp may be a root for a single switch (1 = DODAG root),  this lamp / luminaire may also
be a member = of another group - -  which could be all lights on the floor (2nd = DODAG root), and a third group
of all the = lights in the building.  There can be many more speciality groups = associated based on the building configuration.
Consider = also during the installation time - how these DODAG roots will be = configured?  Must I commission each device
to tell it = which DODAG it must use for its Object Function?  How easy will = this be to change and add in a new DODAG root
for the end = user if the lighting group changes??

With respect = to Jerry Martocci's - commercial building requirements - every device = may need to communicate to any or
all of the = end devices.  If each device must establish a DODAG for the other = 499 devices in a 500 node network - How much memory
space will = this require for each end device to maintain?   =

Keep in mind = that the end devices are very limited processor and memory wise. =

Not to = mention all of the network maintenance messages that would need to be = transmitted to maintain all of these DODAGs.

Consider the = reconvergence time when one device is turned off and it was in the = middle of the majority of the 100+ DODAGS?

In many = lighting and building application an application acknowledgement - must = be returned {Back down the DODAG} so . . . the
requirement = is not just getting to the Root - a return path must also be maintained = and have a  low latency path.

Ted = Humpal



= From:

Kris Pister = <pister@eecs.berkeley.edu>=

= To:

Anders Brandt = <abr@sdesigns.dk> =

= Cc:

ROLL WG <roll@ietf.org> =

= Date:

03/08/2010 = 01:45 PM

= Subject:

Re: [Roll] = P2P performance with current RPL = proposal

 




Anders - if = we take JP's suggestion to make The Lamp a DODAG root, and take Phoebus' = recommendation that we use path diversity to improve end-to-end = reliability, do you see a chance of success?
In my experience, with = diverse paths and order-minutes updates you get extremely high = reliability.

I have no aversion to TTL-limited floods as a part = of a solution either.  I'm open to ideas on how to bring those in = as (presumably infrequently used) options.

ksjp

Anders = Brandt wrote:
Hello
  =
I would like to = probe the temperature of the WG on using DAOs to
support P2P. =
 
The = building and home application spaces (and maybe others) have =
a few clearly = defined requirements.
It is not obvious to me = how the current RPL proposal (cRPLp) can
satisfy those = requirements:
 
 
In both cases it is the = worst case scenario that hurts:
 
 
P2P routing inside the = PAN
=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
cRPLp has no way of = routing inside the PAN if you need more than
one repeater. cRPLp has to = go all the way to the top (maybe 4 hops up)
and down again (maybe 4 = hops down) to get just 2 hops to the side.
 
The consequence is high = latency and high levels of background noise
for nodes just outside = the direct radio range.
At the same time the risk = of meeting a failing link is 4 times higher =3D>
latency may be much more = than 4 times larger.
 
Latency may sound like a = minor issue but it actually translates directly
into lower battery = lifetime. In the above (very realistic) example,
the battery lifetime is = reduced to 25% of what it should be.
 
We have lots of battery = devices sending into the network:
* PIR sensors turning on = lights
* = Door locks sending alarms
* Door/window sensors = starting chimes
* Smoke sensors triggering = an alarm system
 
 
  =
 
Response time =
=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D
The latency issue is = important.
When a user (real human = being) presses a light button the user expects
the light to turn = on.
cRPLp = proposes that nodes in the tree periodically advertises their =
presence using = DAOs.
The = periodicity is a real beast:
Thanks to Trickle, the = rate of updates in a (apparently) stable network
is low. This is good = since it leaves bandwidth for data.
But it is not good if = existing routes to my lamp fail and I do not get
new routes to my lamp = until it decides to send out a new DAO.
My user will (with a good = reason) not tolerate waiting for minutes for
the light to turn = on.
 
I have met two arguments = to counter this concern:
 
A1: Well, your lamp can = always send a DAO when it detects a problem.
  My answer: =
  True, = except that my lamp does not intend to send anything
  so it will never = experience any problems from its side of the network.
  =
A2: Well, you = can increase the DAO rate to sub-second updates.
  My answer: =
  = Oh no. I get a very high = degree of management traffic which
  limits my available = bandwidth, increases the risk of collisions and
  even run the risk = of violating EU legislation requiring me to only
  transmit in less = than 1% of the time:
  http://focus.ti.com/lit/an/= swra048/swra048.pdf
 868 - 868.6 MHz: = <1%
 
  Reactiveness is = hard to achieve via polling.
 
 
  =
If you agree = that this seems to be critical issues please raise your
voice on the list. =
 
Going = forward
=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D
 
We need some reactive = mechanism to reach lamps before the user decides
to sue our = companies.
So is this possible? I = think so.

Existing commercial = (non-IP) solutions are capable of re-routing quickly
if they really have = to.
 
Let me try scoping the = requirements to a potential solution:
(no different from the = req. docs for home and building)
 
* P2P routing in any = direction independent of the tree.
 
* On-demand P2P route = discovery if requested by a real-time critical app.
 Data = collection apps may be able to just wait for the next DAO update. =
 
* Limited range of = discovery mechanism: max 4 repeaters.
  A TTL field may = limit the scope of the repeaters.
 
* Suboptimal routing and = traffic bursts are accepted in exchange
  for quick route = repair. But only as an exception.
 
 
Just as an example, one = existing home control technology uses a
(source routing) variant of = AODV for quick route repair.
Nothing comes for free. = The price is flooding - but not just flooding:
Managed flooding using = a distributed algorithm running in all
participating nodes. =
The algorithm = dampens the flooding in a time, volume and range perspective. =
Some = similar mechanism could be built into RPL for quick route repair. =
 
 
If anyone have alternative = proposals, please bring it to the list.
Now is the time. =
 
 
 
Thanks,
  Anders =


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



 
<= pre style=3D'text-align:center'>
 
___________________=
____________________________
Roll mailing =
list
Roll@ietf.org
https://www.ietf.org/=
mailman/listinfo/roll
  =
------_=_NextPart_002_01CAC45B.F213E524-- ------_=_NextPart_001_01CAC45B.F213E524 Content-Type: application/octet-stream; name="DAGPtP.pdf" Content-Transfer-Encoding: base64 Content-Description: DAGPtP.pdf Content-Disposition: attachment; filename="DAGPtP.pdf" JVBERi0xLjUNCiW1tbW1DQoxIDAgb2JqDQo8PC9UeXBlL0NhdGFsb2cvUGFnZXMgMiAwIFIvTGFu Zyhmci1GUikgL1N0cnVjdFRyZWVSb290IDY4IDAgUi9NYXJrSW5mbzw8L01hcmtlZCB0cnVlPj4+ Pg0KZW5kb2JqDQoyIDAgb2JqDQo8PC9UeXBlL1BhZ2VzL0NvdW50IDcvS2lkc1sgMyAwIFIgOCAw IFIgNTIgMCBSIDU4IDAgUiA2MCAwIFIgNjIgMCBSIDY0IDAgUl0gPj4NCmVuZG9iag0KMyAwIG9i ag0KPDwvVHlwZS9QYWdlL1BhcmVudCAyIDAgUi9SZXNvdXJjZXM8PC9Gb250PDwvRjEgNSAwIFI+ Pi9FeHRHU3RhdGU8PC9HUzcgNyAwIFI+Pi9Qcm9jU2V0Wy9QREYvVGV4dC9JbWFnZUIvSW1hZ2VD L0ltYWdlSV0gPj4vTWVkaWFCb3hbIDAgMCA3MjAgNTQwXSAvQ29udGVudHMgNCAwIFIvR3JvdXA8 PC9UeXBlL0dyb3VwL1MvVHJhbnNwYXJlbmN5L0NTL0RldmljZVJHQj4+L1RhYnMvUy9TdHJ1Y3RQ YXJlbnRzIDA+Pg0KZW5kb2JqDQo0IDAgb2JqDQo8PC9GaWx0ZXIvRmxhdGVEZWNvZGUvTGVuZ3Ro IDIwNz4+DQpzdHJlYW0NCnichc9NC4JAEMbx+8J+h+eoQevsuKsJ0iF7oSiwWugQHdNTRS/fnxQq MsSOAzO/P4MgR5oGq2w+Bg2HGI0zXKUgkCIizUwxYiZYQ7gdpdj1cJZCo/zsEEWaTGOp6EmxlgKT VQZ8BfQrMHJSBFMNY1R16YoarDRocKSVHYCTRNkY7lRXqlQw28Yo7/U0k2Lv5X7feo/cP8AtpJi4 lhZ/td56yKx0Q9976ELCNiSsENNECp/Zu9w6LdNmJaHiH2uTL7sY28IYO1Dmz1tPUs5g/g0KZW5k c3RyZWFtDQplbmRvYmoNCjUgMCBvYmoNCjw8L1R5cGUvRm9udC9TdWJ0eXBlL1RydWVUeXBlL05h bWUvRjEvQmFzZUZvbnQvQUJDREVFK0NhbGlicmkvRW5jb2RpbmcvV2luQW5zaUVuY29kaW5nL0Zv bnREZXNjcmlwdG9yIDYgMCBSL0ZpcnN0Q2hhciAzMi9MYXN0Q2hhciAxMjIvV2lkdGhzIDE1ODYg MCBSPj4NCmVuZG9iag0KNiAwIG9iag0KPDwvVHlwZS9Gb250RGVzY3JpcHRvci9Gb250TmFtZS9B QkNERUUrQ2FsaWJyaS9GbGFncyAzMi9JdGFsaWNBbmdsZSAwL0FzY2VudCA3NTAvRGVzY2VudCAt MjUwL0NhcEhlaWdodCA3NTAvQXZnV2lkdGggNTIxL01heFdpZHRoIDE3NDMvRm9udFdlaWdodCA0 MDAvWEhlaWdodCAyNTAvU3RlbVYgNTIvRm9udEJCb3hbIC01MDMgLTI1MCAxMjQwIDc1MF0gL0Zv bnRGaWxlMiAxNTg3IDAgUj4+DQplbmRvYmoNCjcgMCBvYmoNCjw8L1R5cGUvRXh0R1N0YXRlL0JN L05vcm1hbC9DQSAxPj4NCmVuZG9iag0KOCAwIG9iag0KPDwvVHlwZS9QYWdlL1BhcmVudCAyIDAg Ui9SZXNvdXJjZXM8PC9Gb250PDwvRjEgNSAwIFIvRjIgMzggMCBSPj4vRXh0R1N0YXRlPDwvR1M3 IDcgMCBSPj4vWE9iamVjdDw8L0ltYWdlMTAgMTAgMCBSL0ltYWdlMTIgMTIgMCBSL0ltYWdlMTQg MTQgMCBSL0ltYWdlMTYgMTYgMCBSL0ltYWdlMTggMTggMCBSL0ltYWdlMjAgMjAgMCBSL0ltYWdl MjIgMjIgMCBSL0ltYWdlMjQgMjQgMCBSL0ltYWdlMjYgMjYgMCBSL0ltYWdlMjggMjggMCBSL0lt YWdlMzAgMzAgMCBSL0ltYWdlMzIgMzIgMCBSL0ltYWdlMzQgMzQgMCBSL0ltYWdlMzYgMzYgMCBS L0ltYWdlNDAgNDAgMCBSL0ltYWdlNDIgNDIgMCBSL0ltYWdlNDQgNDQgMCBSL0ltYWdlNDYgNDYg MCBSL0ltYWdlNDggNDggMCBSL0ltYWdlNTAgNTAgMCBSPj4vUHJvY1NldFsvUERGL1RleHQvSW1h Z2VCL0ltYWdlQy9JbWFnZUldID4+L01lZGlhQm94WyAwIDAgNzIwIDU0MF0gL0NvbnRlbnRzIDkg MCBSL0dyb3VwPDwvVHlwZS9Hcm91cC9TL1RyYW5zcGFyZW5jeS9DUy9EZXZpY2VSR0I+Pi9UYWJz L1MvU3RydWN0UGFyZW50cyAxPj4NCmVuZG9iag0KOSAwIG9iag0KPDwvRmlsdGVyL0ZsYXRlRGVj b2RlL0xlbmd0aCA4OTM4Pj4NCnN0cmVhbQ0KeJztfduOJEly3XsD/Q/5WEVocvx+AQgC2gsJEqJI zbaghyUfZnt7hiNV94g7I6z49/RzjrlHZHVkTk+pQYnafKnKY25hbm5ubu7htzh9+fenP//zL//2 l3/9q5P7i784/eJXvzz98+tX7uTOzjkfgqunGtwpJ3f6w7vXr/7bn50+vH7lT98uHueKd+mC6Zs/ e/3qv7x+dfr13/7ydNpl4L/8T19/+Pb08O7DF//1N4+W2y/evH715V/6U0pnV9LpzTcQP2Sf/Mm3 do75lHI753568x55joy//Kvf1NO3PwD91etXv3346vTh3bvfP34RH344PaaHHx+9f/j+9PiF/fz6 6X+cjPbm8R9Pb/7m9atfvznQLlzTbqqToz+XsFfntw+nWxKjCXHnkmmy2M+xxlMs+VziqY+/oZyK P7eal+HCuYWWTn8cxTuHMJ4d3ONvTv701Sju0OO/n35S0G8OtElH5fvnW/Woyg79XAtNkEYG7VTT ObRTbBHg7bDCl3/9/utv33l3+tX3p6Nqzy/MOOZz2uVbRpnLKHJA9rt8w7V8y1G+rIeWz6GmUYZ+ bv30fkcowwlPT4NQznXU2Y5Qzz71SRgo9UjkAWoTCKe3g7WdXRWOJ7iwzwSJKLtGVLzxVhdIqA3J LUmNTtQjHq1wBDD3swsipHwCqp5o/Nuh8agxk9As426IgmsNLL6fWmRq3M8pIDnETjQaJMRXgvHv LQ1Rgtku0BC5CZF32bUYs2sSNWpwFKulOs0+UE5tosH8T4M/nSNK2P2wNitm2GWoZATVgwt9EpBh aUJxKQPkp67JmJHaJGnUAMxUDVUzQfIguHPvrAj+bhWW9bESVW+WTShlR6tEcs2FKEag3jKRYzWM H8HLtMNHwITkgcajA6Uu66iCB6GQucEkQFZnOe7RKLgxz/ovTPZdvhGAsq9EfkpOXp7VPJJDKUQ5 Ay1/nX7Wqvl6O9ENUE+ZdYjI04mWNbwTAdYYmrtKRJAoOLPJ0sileBHIGgU8/ZNtKI16mWLp/ImO NSxEL0zn0oESs0znPBVGfAQhkrmwdIku0q11xnOfCnfC4TgoOu0U0UgG8jERmYmH32QQHMLsEwkB QWgQYOWB6N3DnBUowoMG8t2ejsbsmUrfHzmmhWqHtxnvJGQmxyZEEDxBq5PXRREilRg9BBGBk5ja ZgmSJMFJhrfDMkB0v14keNSSnKRliar0oQqXAaLLZAQFITEPB9klh9E3bo9602lJdqXNjFED3U+l gKI92pf7KePGwNaCHm0MerUXs4x4axFvV13L4vzJpuS2Bl4KKiCM9spIMppVUm0joqP9F6JIz0Un DJS7Pe1zUK+XGT26PGwIR2Bh2xodY55hByUahKSo5M1bGXh8VVpRmxixPkhWZYgsagajatGhtDzR 2103RcLTRpAfPSMMPQeyGu4EMe38CATXph+hGZa6rD6Q9/tKyWeXy6qzhF6GIAO0Fne1zaKU6Qwo 6XQGD5R92/kR2mwNu+SQd0/6/Eywy3XlO1p07UulgcKFxqOqzCVRoIFmK4pAtde9LQZh2o2p9mTP F2gKJgFNItDoG0FqtWA9CfPt6sBmAVC/aIid5du6souuT93hNxgOOgwA/4hh6Bj+3Ycu96HLfehy H7rchy73oct96HIfuvw/O3Q5moGqn2sGqiO4fzwTlK7NBLWjjEdgHFJGuUffNwLC6Gz/8O0YZaEr aacQ0DJOpZ7zz5yg+wkJR3bpL7SLzxUtcTPMCKCYIwup7M1SrpnFuxdmPMqTy0W+Hl1dCCNq7HNu V3M+nArm3Fzwo1CjDDkgQL3fCCnC3E8gjC7VPyOMEGqEEByGBkCjjw5h+KtQYhMAwZJHzADqEj7a SwhhjHtDSjaaAC4iVCairGnEF6AoudkaOAjIPWHoDBD5u9cFKjoQ4wRurKv5GEbMkjqeSGOYUKYG PZAwWjD1GSpkh1E0tS1ELU3m0buG7GUHTlcDZSEvNLVwMxkGgAnbtDotPIHac/AFQS7kCNu8t1po k/AkgWMsYQTmR6DfVcL7UjSpjktXoSMRH2RNQa+2zIW6GQTaK8F4o8y1E4xBDpBGzSBUs19k8hjk wLalbGi0y8lLXDC4Xk9mmgOCPVEIkzkUekKSxnyUc+DUWP64Soe6TAFRlLUkBLdDpQhFP6vBmGH4 gRwEexZ5mBh1JvR2qwQRnkTIdeMv9IsRtPHTcnV9PspGE86jWQL5LDXSHuU6mUEYNTKye7ogdPEH Va5fOQGsnKAFql455c0rLrzo6kvuPQbcY8A9BvwJxYCjUZE/XJB9wXAxxIoh+Uejk6vDRR8/fbwY yyhGPWEoll80XLwp4NAuL13I/Wi4yNe+dPI184XuU0aML13Lze151pxM8DlxsmllHa6uIvvry7mx jzc8bBeI+DdkJYfpkEl4MkKdBKBAfv3M42ewyRsSmgiZycNJifRcFLPmCEkQc1NyIhjRlcATlTx5 UyQhlqmTEYJySsrJ5/3TbqkF2R5dwMrWo19YWnl7IVxKewS1VSCPaLnK69FGZnm9CNKadvLo0ZYZ vfVvMPSIjEZ42gi1wiIk4C30GU6TQNSEVEgXhOLUZfSnJMicTrJGUKYuYq6L2Yt5eNZUHEhl9son p8UsWaPPYZkJ4h6ExSrsTZCec3ETWywWr1wLTL80KlN9Klx2lmZ5GP5WWQuGIMsUBfPWb81uyoqv 52bFgU7TxPi9qxPifZXQHZ4RICpDeaDahKJQXtKEPVObnizibQIr45pESEwtVUi5ZEN+Mic9nTuT owRnCQ4TGK/bpSaV3Z7kpOpecFpaBCZPLZKQv1A5oQNeBWIHvwqbpobTFAnOsiyV0KMtK26oLmaF hthl9UUwvbLas8kqavnb09WiUFEZ2wxWl8Ht6pD5HgPvMfAeA+8x8E8mBh4OjT/XDHPy8XB4euOd 4WfMMY+3zzyCls8dmbzkpeG2hEPTfLZJ5tIwlzCDxSe8NISXTjOP0vl9rRTWhs+ZAWJ7Z7i6AzRc n2aujetgvrE1vNdiDsKACE8kpDQxQAtCXPDIBoKtjeTcSEhcG8mtC3G9qXjJTcZbojKOlFvQGhs3 1Ta1XIC55lKadMAeAawgK1u3Q2txeCM0rkbp0WhrU0Vdf5mrUco2YiJ/qRRN/WIDhzQ1Vnki2vUq azT9s/KMU7DsxIm3aULMdS37AgxOLnsWw08b1orZXJq6xFifNwJQ6kJaIkO4GKjMhS4sTZKgBbZs yXy0M352C7YwqPciUFEXCVIlSEqKfa3jKVmsWUoEv0drxYy4cV/GfLCd+ya2IZIarxK1Kil9+NK8 1G3WL67ScB/6KmljVU5DNOv1l53YapcNG0LxtDDBrkpE2NcJ69HaRE6XhIzILAJbhyVHtYMgNJ1O MMrVTVJM8tZIFKaZqxdzYDIiKJDno5UdT1p2xjYWYMeV18psYJc9mlU9MStXD0Z0kUtshBcYL3ON 3LM0NYpT/aa0uLWoRII1ZPFKe9khzs1Q00ycLlsmjFa4ZHI8NZ6BSoQnEpoJHwR4TLR8I1DxQppb G4TURRj+BmTMY2SyQzMnYq77Wk4iJIzwpig05C0n6DtzqsacmROVVPS8DLZX32HuMfkek+8x+R6T 7zH5/1JMPnpxCJ9rGaZXNIaPRu/XX6nCz1iG8T3iFbjiVb68bNvOTQmHlvlsCzHBc0vdeOcNn/ZG 9dJlGJToYt9OQ4Os4bzfMBSu18j1NZgQGufQHCcl3oswKtoIYXgDpnoGwkpg4Nos0FyQ5043EgZz 1CSS81xVHChJkK3DDkIVASujkduegRwe9Zyscs52ZoMQRcDS7kAI+M5x4T9SN6C8mEc9kBCYzHw4 R0lUiRRdSJDkoOQmWVi8Feq21XODtVkiQOlSeEgBcmWJZXIOllyAsJwqhTr6vbx4AwlRcgtFhW4o E9UluJA5ZOmbmU1IyianiYx5dLW75ChZvU4bQydtFAfBUXL2nRWi4iXVDnaAYwt+nZUXKKqj8ka9 Y3wEq0WiLIP7PN2CjuC48D48yirAE/iFyFvnw0zmOQQ+SZCokua3Q8hIhFJQcaAsE4dMFFgWF9Z2 gjYsgdhauYg8XGYgbxsRsJm62qCFOwQSsAvaejC07+WcwgJ5VGefvCI426YAs2BA1iR3oNEJxDKZ CwmhinkM23oYntOkcQdKPszigTnwyAUK77jFu0aZIhNl8+JhNle0bTtx02Lhju9ANNr0BG/VpHPe p3KLN7a3o6aCxBQ/q65wi3fCLg/UM5PzcGD6gFTSaHYSMvfIPkkrHWzeEfIiAA2pA3lnyAMFV2eZ IpOjK0we6mLyFXtdFip1GUCE2tIuuXFvSaXfZw7udpKHSaMyHuOOgbwLS43C7dbGPMo3CAGRCagS 2e5QukYoe+/t2jZNRMFsb2YMIWtvIU/CkwU5v/iB2pKFlpz2WaGtLz0it3JSRwUFhAgUYYsZVSVU SKnMxu2iEWbWt4DIWmzNIleTXesOleb3YQ6HB9osgwgem28s7nleCkDETf955VR4+qPtghd6BZUh krnkFZ10rKSqM+k8PJGaOhqdAIhtdS2JokJT8PI8n+K7XLzxUR/qdPHMsy7YXg7EcxjOJXV3PADQ S5tNR0edOrq0gXBaCUFQcU2nPYDMGULZkgsdB9koWlVqEUOard1Ri9wVn2iYTjfiGwzaoHWGIVoD 7rbRbIxWR5zI3O7EHUsIMd2Ygw1KHGMz9y5hkp7bnYQyX1mNOdOrctY2OfREo3lU7VFD429sraYG wmTTpuFo3VIq2kLs1XHWFSatj+amKy6TqHdnGNcwwGxcUB8cRFizL9v4Yz88uToDcR/F3Ecx91HM fRRzH8XcRzH3Ucx9FPPvYBRzODP1ufZBYPM7GS8miG5M2f2MXRCxOFz61Ycjv2zf9NXHD03y2fY/ YOsyNiPET93/EF+6/yFyAn+Xcy0gJP9s/8P1nK/vf+CtCOVUh0Ud75GIw89HkDTCkwhjWGYEIvIn HJ/tOEABUG2rVkUrAAFXTwBRVMI55oE6QCyTtVNsxHFvID6IOE6UgXyOi7ni6q+Wl1Ii1GT8BahY tuPpgbIGJyZ8EFKzrAJRMGbeKVb9KgEFR0ttfJKnmFlagLJ4K7OdSlfKDTgMLTMaemuboBbhaRFy p0dfErxtsipAvDag0weANKVPgifBKTnyUV+1MSwyzc9dZByPgRAleWSQeaAEwAk42+qFNS0QHA64 Y9RGLRzOR2NuPExkzLntk6XyfDSWZ5JDWfnGqQRViiDuNeaR9lWgiCH5Kmy8MAS3qy47MTovGy5U 8mIu+0qQ+z8j+FWLuIihrhpuHAXuHACE5R24wqEsz9H9GDvHAmFzO6DlkbgNou0dlvdzLH9uPAE2 fX2hljdmErqJYpPjZQUSvGtHzHa2Mmk0W6AU3tqnijMbL0s627XssGv2MtMMCjLhDBgXAebqG/c9 Dt3j0D0O3ePQv2kcOhogxpeucyfePbQfH2J0/9Eg7epdCPFwmfslm5ZdRrB4nvP10Xo8XMC+ssBe uA0mxpeec7wp4LBCXrrI/dGI3TfeyRLzJ59zjIcL3Z+ywM5z2PusGTdjfLaRPF495xgP3920xu4C omzE9RucnNYJGZRLd+oEl3hH7o6we+JJh7gHCbe6FAa49yLgph0RgGrZI7h04UF3vJ06bcgv3B8P 5A1FITJPzqD7ejG957j7hSgLWdrkTYStMDFFIQFx2pF1h4vaRhEDJk6fRIBkHFTPugFliMKJ9rRH OqxEQiah2nUpUSgQ4bam7O16IxKUXCTL61G8iQ/kDIm3IEPgERWB0G1sCAYWMuYU98mWryHfLgUj Os5sM5YJiILQUpDMmPEToTC5WXIXkhY2Zeg4B0OCmFHvmXP8RPHCcEnJya4TC5rs3gi+Y4sdn+gT O4nHTrnep72w2gAUZ9ZvyTyrwfcGFzGtiWaByMjpFhIiU01pzK50nvFfpgPOZRoWCH6/oVB2dQKC 61tynUoYmpl6MfMeB6sGoJlvFvJTf2POdRqeaGeIhXQKxmuXFP1XsnD8R75NyVGubw7KSVE2Dl0F 4LjewabjeStP3loV14zY5Px8ONetRdKgq7VipnI1ZB3+mY2cqq4A4Hmb1i4+hPNFLMF9ixvaAs/1 Jbh7kLsHuXuQuwe5/2+C3OHg9nCi/CUz9B4vRh+NL28M+g8nwq9M0SMWuI51uBdN0V9//Mgm6aXz 5B9P0Ude+Bqx5PhJ4/10OFH+aeN9f/Hyh5W5UR9un2+8ekAxHb50aoIedxINSVhy4x1Yi8AghamC 1OFkl4Q0MUAlaPzdxdk0vZFZYyDgpT1zvTBqDQ6oCOlO0KjLpUBgR8ydKkAWATxBM16PFaqI5XoF GvRjA8W6RzbNMAl1Bko+al0db0KOYe5KiFmIMcoUaix/5hW3QCFOfdEGsTwpfb3siPtwE+9iBVLD ByFLFl4RE7dqmNEjLo2qE6kxz1qIEeFwXy2c/2AtNMazCwKsLAKywC3QkafdmX0k8ksfZB25H4cV JxRVT17MOkjCapTTVZU0yQMN4Elvu1BAQBTWsjpRI8LR7A2pJ1yEgDVdokQU+yY5zOPngwD6ILAn 5i4IGMhJMqoxzqMTLFEmIap86IIjj3PQf/VoXsYIehq+ltrO9EApTjQrJ2NqFdFQl6OzLvwkWBPB xaUiMHu9nTfTtRFN/3TMdxCy/Ix1kWRAz741pllx2cu+vA+MXZ8VRYh6zdMm7OyKTGbjPNkXw8AN OT+ZSfDqj4MsivVw9ZpKC2mq0S0OqQFaVKp1DkXoP2UyFzmUDRiTnM2rd5ZvTU406NBXA5RH1639 9fPyHYwStQ2KYpQ6R4ME2nwwzRQ0J5vVartGugKlTRugMaNNywZZDdPLYKXN4GDMwqj7HNQ+6+Ql Ktakd4SkbNsufAUGBW1WMGYWNU/bZ8VJZRPTjKiz1pqisQrehbKCG+bCAg9aTedRPJ6mV7KzgAsN 4y54MyxFjQs5YwpUVBmIpSHOxmndQJzRD7EVyNpTn+jt1nxEeBKh9o0/s+EFHlAEYuCMdrkLCElP w01Tnmr1DazGYoTRekKdORkhn6YkNMQto5jmpRSmR+Q1GFPH2aL3EeD6qtO9c713rvfO9d653jvX e+d671z/DzrXwxf5z7Wiie9bpmcv09dnNtLPWM5MmV/ODNW97P6l648fGuTFS5ktXHwDM9XCMx34 yMd+jTdeN8pLVzIjv3yzz1oTyKVcLi/H65Mq11cyU9ft1dx6y9sKse+5TULiV48IAkESUmAFAZqA MFIZyQFSIML909g0rxvysC84kjACJVBVshdzJxIne9Ggi8eAcNCAO4WJksBkTWKlflFZsCMjykJh MmcxJ0kqAlHAE8UluEhUlOCibHE5YmcsAPIbs2T50w64HYpaethh3H84JUV0xSuXeC4XOkQUYKnI MQTL0oVW2Srx8EAiSVLZsh4Mm9HEa6VJyiWIOfaJjPki1Vuq9HXKRYd8UI2tbwqHs3Ipcg7LU30M /UMPd3lWN6PJ6Yqq3C8/C132R81pu3bnVQt04DgRmBvPAM1k7Ynho0JOFemMuU0b4/5NtGZpmYH4 GTQgfUwFBFz43jkBDkTJdHQgqujNM/GNnkg8HgbCchE/1rWQ9sMYsxGcmPEoviYkuSPPVu3Vg9km EqQi3Alf5DKFhVKZpcORncZ+nmUdjtC4MkNTRKISpt0QCfDVLVmqK3kauU70VlECRp7Jnm0UqKv6 CpG1ZyUVr6jQiXC/J0KC0uyu0M7VQOorZiuOl097TxRWmAhKjmU5LsquZkd9y3LNqKxWcs4XqEnQ 1kiV1YgGsxkCpdVkocbGrKyCJUuWt0ellGuTWWbsaj8CFuYEar7kLHmXmOserPz7qraZf16qqybi CoFFdRzKVjIeUVulzruwliXLxxVT8A0ni8NKcytOoBk2DgwtarQVwVlzabp715X8uAdGXsACpBk1 cLytpV1Q8YmEIN9qSvZCaIJAYQYK5YR2hJ4MgL/YiNJ0dJYksUm0OgWwuZBt9gLW4Hnpk9ql0AgL qRX5al6NjQ7Cyk1MdvIhhhKO3tBo7V7Xxj4UBDJnNb2mwGKIW+mMOSl6oJeTGwSVHQgGQcOaWjhF JdNCQRYdIj+dqOC3ihfUIWZFJQGWjsuX7K3zNJpT941a0sa+NUjYjyGuTvXchxr3ocZ9qHEfatyH Gvehxn2ocR9qfK6hxuE8z+fa1ZOa4s3zyZYbk19XtvWM4mIKrGL6qo48MPlV6nZ4Cv90vjl98uzX reePzJIPN/b84s0o1V/iPsLTm28wWkPxeeVjxxcJ+LXaN++R8K2N5X778N3jP57e/M3rV79+c5TN 4SYeZLNkYwlvJ/q3D6ebAsOFqv65qqm5+f04pLxHPX+LP9T1P55+8+7Hx/Rw+v6b0+MX7eHto3cP 3394zA8//uExpIevv/vwWB9+/OG2CvGgGMVzbXKX7+kLHLg5vXk7TPTDTXnpSF5082NxU56jrNuq 5QNRZhLsfczNbPzu0fuH//0///Do08O7Hx6/iA8/vMPf39+UXg6k58zloQvpt3Wsh1Ia4tiFlK+H XuEnZLUjWbXxoxV7WX/3y7+/KacfVYFrvKXnk0tW3KFjMCj+DCn+Rh1Wjg6Xe40eBT7x1W2B4Uig 4u9eoPzr66enx/LwPVvG1+PXj48+D3e5Jf+oPWTborrJ/6liH7WCnNnRXEj5+kR//f5/0XnfPsaf 0O6oSRRfzz5dyv3ippQj1y+4jKJcSvlu6PPhh8cuu3394e2726WuH4Wz4bvpKKT5zDHnzCY9/P7d h5HZj9+NSvrmu3c3W245bCeZL90Xcm8re9RK0P77Mym/Gyr9ywiw5eEfHoaKXw1l/wOi7uMXPlL1 f3gc5Jt51eO2pFizz+uP//RuOEK57QT1qE2V4rjv+5PLX48aUinYcLITorg/RvqM/LcFHvYkNeqT GvvqvtmB1MMOpOlDgjvFPqEDqfmTulcfOay2BvnhhEB95PlfjF//+Xe3czzsVPSadZnNYWC66fb1 qKspmQO7C9m3NTxqPMU+fLKX8rsxjviX01c3ZR12NJi9+hkKNbeGkofrqF0fZxoD1Xa8SfzKAurN 544Gke2lW7Sfr6Fmr9MHes/7lDXU9tKjwbFcngbNXltVCt8tt6zT1dOg7XApnUPijJ1dnmfMEyc2 s+3CEAEo6Ag6Du7rkq+ol8+3Yk5G8EzG/prOTUhZ96cR1clcdLg9SnK15CCUiDRfQILUCMasR4Pf I018TUJjjk+DEHlU42OCHrkkQGK070Upt8ijHTtlYpxGgq6RRzhmOaIOdm3FBKEsK0Te8DMtZHuq NgNGneAy+8Y4DZgkuU5gvC3tU01lPpm4W2knOK1q9EwOcdOJkwR7lfnJilWixM1is7ScYtgbQ4eR p614Pd+y40JWM0Zo3C7zdEk4TVEDDPaZE1BcanUSnLSOetKVVQagNJlRxMb7F2fxm1+madxuZXbs RqinadUN1QmMFzWypaK2NhTjM8EhWabR8pc28pGdsnKhWRa51yynvG9nBjnntJK5tgy4gbx4QeC8 29OuaXxEWDWyI5xms7O8rFVuqlijNU2tQVsprL1vhbRwYDawUNH8CiOb4SzKmF0tAm2IxllVEviN wJVcuE9rQyVfSC6mA9OkgNTRbrKdthx2rMLwPoZV0DKdbdqhcAflNFPhRkOz4Aby4i370LMRgtQK dQt0ZTbNsAoARWaYlJIzhKoMuwhbZjiO0npGE79Ms4vdstwM7bLqFva3XuHqqti987h3HvfO4955 3DuPe+dxu/M4fBd76Zdvnq9z5MD5h49eiK6vc7TDrbTHL6cZy1e1wP4v2eR74/FDo7x0p60P8fIQ ce58K+YC/37rc7p6jri99MJXzPxfvKFio8koNZepdzlfr4/DJS++oBbX6WmOdwK8F6FPPBTiGRbH HTZA3hBXRUHAzn/HGwaI9CiuQ/M6UuG8LceBkIxZkpMlC1SCXCevErNYsx5M/QItudxZwuvfny4I uDCNogjSzIholcAWNaN0TnoyplkCorCK20U4WdkBQp+mIVolcEYYBaRRCfLJTG7orUxe/D459f2T se8Fuz6VQL6uTy0iAW5x3hQGYRXHaUHKiupsJXVZwnVtnJKhXF8GtJ86kARktn/aIWni/Kozx00k uxpV7lbf0GtzBaC69xQUKi5HggU2J4N1/N4HXTdXgYfCkmF574VvXx1m35vAvQn8KTWBw37xpTdv fzRY6KqA553T9cFCP9x4cDxYwKcb+SIxxgIv+yj7bQlHpumfa07bLlHFXphPmdDuL57Q9pc3kmPb 4gnHwfZjhasHgvr1yWzveJ6wRH5n4b0Iw7xGABovK0SeqAnpPiGny3gHxjdYXcNLVon67E07S6w3 Vp5qLNhSptRAUAxEIo3BSaCgPHmZScZnLDekE8BGyNhpxkN3k5C47caEY/8CVqodv5WQcdPtUotv hCNSBZav4y1vxKCoshO5qVfFFiWcn8SKsONnFnBckpJ5RRcPdBoz7+XCic+amRyE8GlbXYBliMzc tLVLpqjgC0EQSosXPjcIuMLK8WMuOKfpEhGT8FUM8vKwIQj8Tg4/2Awdo55MQq1P5khCtuRAWZk1 r4uEcTq6TGYVqGRJ9p2ITsP9yzxnGiaz59M1WzJVrl35eApqaakhbKl8IRxv5NICRcddUWnyioBv QxBVInxgdaHolhYipLiXlbHabPnAB+NOi+G/ri0d4fdZiE7UQl68dKI2kymqm93oQ32J5SzOuWdL FauVLqaJZoVcJCc9atWTKbj1pUQmczPJhaVrdChucYf+i7cRlw6zUWrBl5GHb6loxeXpbIE2y1SB W0FpMzEXP5ExN79P7jIwG3nhRc+RX8q19hHU8iw5moaFKFUVzk/mzDbtgpLHMxkeqJY3GkKGN6+W V9nkSxPziAPYwNDzQtjEWhZzmfHk6YJgmij+KRTx5r19pCoocdkK0fIW4wo8YB8Cy4yWidHDgiVD J6//uwis6Mq2sBvLPiRvEfvqCPge2O+B/R7Y74H9Htj/PQf2w5eXzzUJ3AvXOS7fIm681P2cGWDf rDm4F34W/raEQ7u8eB64Pbs8fng52n3lXTG7F6yrnxLoL54G5me+9jnbEcLLC/Pz1X1K/fo0cE6c f6ntzCudAPE9BkD8HrmN3xl9DG4vEtIROmwaHQEVhBK5hXT4MBA+8pE5QQRk6y26GgkExJvMD2gO lGoVikS2CKJ7XUBwlsxHYyl7pJ52ErBNUEtnmXHTOIyQKB8f2yCigIROKTOQAukiGBKUN75sknmy E2qjz8q8HglIHRAIVYXOkoXP28BCthuWueZmpeJhJZozcT+z7FX4O1odGGMqW1Le6kDfSNjXQUbM WHWQpwJJOUjZ4CdvV8mwKJd5CAwIPUXmcSEgHbAjQTbrlpxUBXswa2AS8NGV7Ulfyi4b15cSLLbz UhEeNsZd6H6tMBhzmnnDRb3yaNFo5K20SdDqT/VSa4SIUjmWI9I0Ty5TSYwcKxbanvY4orfI7I6A 8Gmc9XDoyxqSHVjPvB8bCEOzzK4NyPllDkr2ddkZCJ/CQYGFUlwVKEKQBUoR0pb3PIHxhr5PHT5Z eFgT7kehbbplkwZFblmFWJWJX7BBD7N8uFhh5bWZeUS6UDpLcnLxsrG5Zm1LM6riuCBgxG0tGSiE 2dCRVUtLnCljQYOPBl9nCKHaZTJ7FbOK2awMuyo47eyq2DXtqqg2LaeQtzOsLl/bJce8fzTkZ5JN Dct4VrYiprvQGffflVUkoK24uoNqZ43UrNpoLF35Ng250KwJEXZRbiMUE15XCFVWuwgrTWYAlpYz OKsQu9itMs7QrvLPkCPz7CKSrLfrNBRsy2nf01x9Ib13R/fu6N4d3buje3d0747+rbujw9fFz7Y8 mrij8fk72+WL9L8CplsF0g0KZW5kc3RyZWFtDQplbmRvYmoNCjEwIDAgb2JqDQo8PC9UeXBlL1hP YmplY3QvU3VidHlwZS9JbWFnZS9XaWR0aCA4My9IZWlnaHQgMTE2L0NvbG9yU3BhY2UvRGV2aWNl UkdCL0JpdHNQZXJDb21wb25lbnQgOC9JbnRlcnBvbGF0ZSBmYWxzZS9TTWFzayAxMSAwIFIvRmls dGVyL0ZsYXRlRGVjb2RlL0xlbmd0aCA1MD4+DQpzdHJlYW0NCnic7cEBAQAAAIIg/69uSEABAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAjwZw1AABDQplbmRzdHJlYW0NCmVuZG9iag0KMTEgMCBv YmoNCjw8L1R5cGUvWE9iamVjdC9TdWJ0eXBlL0ltYWdlL1dpZHRoIDgzL0hlaWdodCAxMTYvQ29s b3JTcGFjZS9EZXZpY2VHcmF5L01hdHRlWyAwIDAgMF0gL0JpdHNQZXJDb21wb25lbnQgOC9JbnRl cnBvbGF0ZSBmYWxzZS9GaWx0ZXIvRmxhdGVEZWNvZGUvTGVuZ3RoIDMyPj4NCnN0cmVhbQ0KeJzt wTEBAAAAwqD1T20JT6AAAAAAAAAAAAB4GyWcAAENCmVuZHN0cmVhbQ0KZW5kb2JqDQoxMiAwIG9i ag0KPDwvVHlwZS9YT2JqZWN0L1N1YnR5cGUvSW1hZ2UvV2lkdGggOTgvSGVpZ2h0IDExNi9Db2xv clNwYWNlL0RldmljZVJHQi9CaXRzUGVyQ29tcG9uZW50IDgvSW50ZXJwb2xhdGUgZmFsc2UvU01h c2sgMTMgMCBSL0ZpbHRlci9GbGF0ZURlY29kZS9MZW5ndGggNTY+Pg0Kc3RyZWFtDQp4nO3BMQEA AADCoPVPbQZ/oAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD4DhTgAAQ0KZW5kc3Ry ZWFtDQplbmRvYmoNCjEzIDAgb2JqDQo8PC9UeXBlL1hPYmplY3QvU3VidHlwZS9JbWFnZS9XaWR0 aCA5OC9IZWlnaHQgMTE2L0NvbG9yU3BhY2UvRGV2aWNlR3JheS9NYXR0ZVsgMCAwIDBdIC9CaXRz UGVyQ29tcG9uZW50IDgvSW50ZXJwb2xhdGUgZmFsc2UvRmlsdGVyL0ZsYXRlRGVjb2RlL0xlbmd0 aCAxMDk4Pj4NCnN0cmVhbQ0KeJztmOlTWlcUwPMe20MWA6jIougEjeJSt2gEY9JqGuIypqk1amOk wTZYI1pjbW1KDC5VSVTQRBHcUHZ5G/kHewEzar96O9Pp3N83+PKbc849597zrl1DIBAIBAKBQCAQ /x0wDL8AhmHQBTiXTwizUgiFhIDP5eBwHRiXkCiUao1Wq9Vo1Pm5cmmWgAvTgXGzFDpD/W2TqcVk Mt6+VWPQa3MkBDwHxiFySoxdAxbryMiI9bnlaV/P/eaqohwxH5YC40mLTf0TjqWVVcDKX/OOmfHh njsGtRSWAhfkVj/6xeU9DBwfHwcCRwe+7fWFaYu5tkDKw2EIMFyoabYs+CMJMkUicRqPBvc9b23d tWoRF0YQGEdUeHf0/QnJsCxDUyRJ0TQVD3oXbebyHAGMIDCOuOircXeYTiYZMhYOhqKnFMOQ4Z25 Z6ZCMYwggKG43b4ZYZJMIujf2vBsH0RIoDjZmOwsl/NhGSaAgaXCO0sz9snZFW+IZJmY701/nZKA kKbPBppNHK6M9z3s6Btb8sVoljxafm7UCGEamLjP8f2dyormx1PuIMVSJ+9trYVZnKun6dwQ2/nt m5oCTVmbbTVAsnRo/ed7OtG/YShvt7mAgQqu2e4WwjWks1RVZeyd9gQphgysWE2aLPiV7ugasC/v xYDPPzdYD/UsnZ3WianXLl8YhBB0T3UZ4PZDpuPcm96jKMlQ0V3ncIsOXk+nDempEQrHEjTLnB66 XnZUQJtLZ4ZPSZamKJphk0k6/HH2SaMWSgiXDQzNAMGnJHWyNm4uk0MJ4VKWqNNYHOQomSSP3422 3cjmQbnjzg1sInTg8x9FSBa0m3uyo0zOhxsDOK27q2+d78BkZeiY98/+BhWMqXS541xTP1jG53dA OyQCrtF2PZw0XZwab559/WXP6NJenKYj27Pf1SoJDlQDmHyPGwy3HqWGNwNGyI/3iiUwO45moh+n uyoK9C3D83txhgpv/dpTCaXlLhpedZbl5Vd2v9oElTjdXxg2auFOb2DoKFXIilqty4cJhgpu2M03 ZRBq/Q+DTKys6f1jJwrKsuvor88XXr3Wlw0l14XX9ffH1sADjQysvoBS68x7yZMyfJh6WJItEGma njpBrenw1nQ3jBsi/eZ7uREiwemZNOulPIHCAGoNfoM0PanNu/otl3q3tv60ehiNBdbG2kBWeBJd q3XRH4mHd+cGG/IhGHChqnHwtce/tzWXPp4cIq+6Z9Ll3fetz/TCiAHsD4ryB9bfnfOzLzqrcgkc 50l1xj67Y9E5Y2m7KYMwXzGuWPNFe+/QUN+DugIJDyy+hELf3DUwPPRtWzWcFQLnS9WltY1NdWWa bAFYrDCOUKGraGhqrClVSaBcERjOF8nyVCqlXMxPD4nM9qtS5clEkFa5zMIuJPifF9yzPwR8eJt7 5qvD+ceGs68Q8L8+IBAIBAKBQCAQCAQCgfjf8De6HcCDDQplbmRzdHJlYW0NCmVuZG9iag0KMTQg MCBvYmoNCjw8L1R5cGUvWE9iamVjdC9TdWJ0eXBlL0ltYWdlL1dpZHRoIDgzL0hlaWdodCAxMTYv Q29sb3JTcGFjZS9EZXZpY2VSR0IvQml0c1BlckNvbXBvbmVudCA4L0ludGVycG9sYXRlIGZhbHNl L1NNYXNrIDE1IDAgUi9GaWx0ZXIvRmxhdGVEZWNvZGUvTGVuZ3RoIDUwPj4NCnN0cmVhbQ0KeJzt wQEBAAAAgiD/r25IQAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACPBnDUAAENCmVuZHN0cmVh bQ0KZW5kb2JqDQoxNSAwIG9iag0KPDwvVHlwZS9YT2JqZWN0L1N1YnR5cGUvSW1hZ2UvV2lkdGgg ODMvSGVpZ2h0IDExNi9Db2xvclNwYWNlL0RldmljZUdyYXkvTWF0dGVbIDAgMCAwXSAvQml0c1Bl ckNvbXBvbmVudCA4L0ludGVycG9sYXRlIGZhbHNlL0ZpbHRlci9GbGF0ZURlY29kZS9MZW5ndGgg MzI+Pg0Kc3RyZWFtDQp4nO3BMQEAAADCoPVPbQlPoAAAAAAAAAAAAHgbJZwAAQ0KZW5kc3RyZWFt DQplbmRvYmoNCjE2IDAgb2JqDQo8PC9UeXBlL1hPYmplY3QvU3VidHlwZS9JbWFnZS9XaWR0aCA0 MzgvSGVpZ2h0IDExNi9Db2xvclNwYWNlL0RldmljZVJHQi9CaXRzUGVyQ29tcG9uZW50IDgvSW50 ZXJwb2xhdGUgZmFsc2UvU01hc2sgMTcgMCBSL0ZpbHRlci9GbGF0ZURlY29kZS9MZW5ndGggMTcw Pj4NCnN0cmVhbQ0KeJztwQENAAAAwqD3T20PBxQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAD8GFOGAAENCmVuZHN0cmVhbQ0KZW5kb2JqDQoxNyAwIG9iag0KPDwvVHlwZS9YT2JqZWN0 L1N1YnR5cGUvSW1hZ2UvV2lkdGggNDM4L0hlaWdodCAxMTYvQ29sb3JTcGFjZS9EZXZpY2VHcmF5 L01hdHRlWyAwIDAgMF0gL0JpdHNQZXJDb21wb25lbnQgOC9JbnRlcnBvbGF0ZSBmYWxzZS9GaWx0 ZXIvRmxhdGVEZWNvZGUvTGVuZ3RoIDcxPj4NCnN0cmVhbQ0KeJztwQEBAAAAgiD/r25IQAEAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAB8GcZ4AAENCmVuZHN0 cmVhbQ0KZW5kb2JqDQoxOCAwIG9iag0KPDwvVHlwZS9YT2JqZWN0L1N1YnR5cGUvSW1hZ2UvV2lk dGggMTcxL0hlaWdodCAxMTYvQ29sb3JTcGFjZS9EZXZpY2VSR0IvQml0c1BlckNvbXBvbmVudCA4 L0ludGVycG9sYXRlIGZhbHNlL1NNYXNrIDE5IDAgUi9GaWx0ZXIvRmxhdGVEZWNvZGUvTGVuZ3Ro IDgxPj4NCnN0cmVhbQ0KeJztwQENAAAAwqD3T20ON6AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADgwwDodAABDQplbmRzdHJlYW0NCmVuZG9i ag0KMTkgMCBvYmoNCjw8L1R5cGUvWE9iamVjdC9TdWJ0eXBlL0ltYWdlL1dpZHRoIDE3MS9IZWln aHQgMTE2L0NvbG9yU3BhY2UvRGV2aWNlR3JheS9NYXR0ZVsgMCAwIDBdIC9CaXRzUGVyQ29tcG9u ZW50IDgvSW50ZXJwb2xhdGUgZmFsc2UvRmlsdGVyL0ZsYXRlRGVjb2RlL0xlbmd0aCAxMTk0Pj4N CnN0cmVhbQ0KeJzt2f03G1kYB/DMZCYvk4SkiCCEImrVIlmt3XiPeim2pUXV1rE2OJagylJyymlL mlovUSGNl0jEyMvMZMZfuJNorbPrnP1pj9tz7ufH+el7ntz75Ln3CgQQBEEQBEEQBEEQBEEQBP3/ kJibDvGfEARFhV+gKApuZAQR4hJCJufJZAQhlYhwIQpkWgTFCaU6Iys7Jydbl5WZkZ6alCiXxNLe dLJ/QXF5al7ZT7XmhgZzfW2VqcJYrNelqmQiIWiVRYSEpqju6a+j1okJ6/josGXgeWdLtbEgQ0Xg gBUWFan05oG5lfUt57Zzc33NsbK8MDXU03RPn6oQgZVVSKSVP3u9dRggz87I08CJz3vgdjps473m 77WJYiFAWRFMkVM34vCGmWg0yjA0TVGREOlz/7k41GbMShQDVFcES8xvmdommfNzjmUoiqJpJspQ QZ/r/djj8qwEHL3phJcQXHmnfdYVZM+5aPjUd3zsPw1G+ApTpMdufVSWLsOAKSuCqwp//mMvxJ6z 4eOdtVX7mtPtJakoy5ztr442FSaJgSkrH/W7R3N8VI72O21jvw2OTC7YXb5wLKt7qd+UpQCmrJdR 2fD+W0trtammuWt4YdPLZ6VPtqbbi8Ap699RQ7vznT/kZur0BnPf7IaP4sMfvO3/USsDpWFdRo0G P023FCTL5UqNvur5wg7JcMzJhrUxLxEHLurZ9tSD3AQcw4lkff3Q6lGEZYN7853FyaCsgKtRJxty 5PxAhRGppU/md4MsFzl8+0u5RgJqVIT/lJjXaN0MMBzt+2AxaQnhTYe8cE1UgVCWWWX54KM5JrA+ WqsDZV9dFxWVpt3vf3dEcVFyy2q++AaAa6NK1Mbe5QN+X/HfHtxWgBxVnFLa82Y/HnWqEfio3V+i gl5VidrwbIlfAPG1mg3yWhXy2+oFv61YJrDxO9AdAMHkupphB9+saP/HoUqA+yqCim8Vtr50klGW Onrffz9NCua/lQJDUZEis6JvyRPmh63Pi10lKQDOAJ+m+DFKLJIkpJe0Taz7aS566nz5sEAJ3mQV 3JlpK9IoVers0uahd54Q//t77ZZqnRyUY8CV0dpt6628qy8srXo8srx7yvCtyjX/tFQNymB15WxF eR2Tve0P27sGX63sBSg2Gj60D9fnAjNZX4nKkJ8dizPTs7ZV5yFJs2zEv/mqo1QjBaSrfj1c7/KH a44mvW7Xzq7Hexq7aon4txf6TNkJwBQ1fmXRNuMKRs/POSYSCgaDYYoPSoeOnbaBOn2SBJybIARL yG+a3ArQLMexsVurGCp04lmb6zcXqglQtr8gdr0q11VbVvbJcORCOHQWOHZvLFu7a+6oAboGEsRG fo3hybTD5Tm44HHvbNptEy9a7uWmgFRTHiJS5lb2jM2/WY5bsr2eGR/sbq4o1KqkYCXlV4A0Ob+i qaOnN66nq6O1wVSm1ybFHgNuOtw/8Of+pEx9cZnBaDQaDGUldwtua9VKmRgDZ+9fQjCxXJmcoo5L Sb6lVBBgvgUJYi9XGC4SiyUSiZgnwjFAX9jiYi+XX30TT60QBEEQBEEQBEEQBEEQBEEQBEEQBH1D /gKfBNo3DQplbmRzdHJlYW0NCmVuZG9iag0KMjAgMCBvYmoNCjw8L1R5cGUvWE9iamVjdC9TdWJ0 eXBlL0ltYWdlL1dpZHRoIDE2My9IZWlnaHQgMTE2L0NvbG9yU3BhY2UvRGV2aWNlUkdCL0JpdHNQ ZXJDb21wb25lbnQgOC9JbnRlcnBvbGF0ZSBmYWxzZS9TTWFzayAyMSAwIFIvRmlsdGVyL0ZsYXRl RGVjb2RlL0xlbmd0aCA3Nz4+DQpzdHJlYW0NCnic7cEBDQAAAMKg909tDwcUAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA8GzdlAABDQplbmRzdHJl YW0NCmVuZG9iag0KMjEgMCBvYmoNCjw8L1R5cGUvWE9iamVjdC9TdWJ0eXBlL0ltYWdlL1dpZHRo IDE2My9IZWlnaHQgMTE2L0NvbG9yU3BhY2UvRGV2aWNlR3JheS9NYXR0ZVsgMCAwIDBdIC9CaXRz UGVyQ29tcG9uZW50IDgvSW50ZXJwb2xhdGUgZmFsc2UvRmlsdGVyL0ZsYXRlRGVjb2RlL0xlbmd0 aCA4MzA+Pg0Kc3RyZWFtDQp4nO3Ze09ScRjAcQ8HOJxzEFRuIqCmSeYlUkpLUbRs1pqWF2Y4L6lY qYtsNjWtiWZe8rLU0qk4FRI17vQG05x4NP9s42l7Pq/gu3N5fg+HuDiEEEIIIYQQQgghhGKJ4Ih1 y98Igscjz+EByyRIAcWw4jMsIxIeVca66wzBp6VKTVr6lag0rSqREcBpJPiMPMNQUnG/KqrSVJil EgugJBKkSK431XX0vLa/OWG393ZZKnOUNAmkkRBI0kutA5MLS8unlhanBlvLMyRQLiOPkufV9s87 3Z79Ux63c/5tTa5MCCWRVhe1ODYO/MFQMBg44d1bHbHcVFC8WMedIBmtyTaz6w9HwqGA3+c9duBa GWowwElkdeaXc+5AJBL0elzbW1tOp3NjZbL3UXYSlBtNsqkVPQs/AuGQ17U2/3li3OFwfBzqqS9O jedDSwzsfR+3d7Y0W63WpvrqoswkCsrsjib6tmf66sxFRqOxsCBfr00CMxajiaGfm2MtpXpNskql UsoTxRSYQk7i+oilMEXKMgxDiyg+nEJu4qjFqEmIF7MsQwv5UB7EOE6id9PRbs5J12m1GrUiAdKi c/a67Mz1N1WbTabSu0WGq8nxQiCDO5oYDAf216cH+17YbLaO1vp7+WoWylg8Swz79pwrC19mZ2en JgY7HhwdLlAu42liJBLyH3rcLpdrd2fz6/tnt9Q0lKcxmvgrEg4G/H6fz+fdd051mbQMlLlzWeLB 1pTNpIOXyLnRzqXR5tvwbjTndZn+NNxVfV0GZV28bOh0tjVWGTRiaEOHO7pLigv0agmYmcPddBxt pwegMpEVQnkSz286jQUpkqNNh6ZFMNeIw7Xhp3kyiuQdA/XViZM49CQnEcrPey5M/Bf+j0Tzq3n3 UeLqYC3QREZX1j276wvsf3tXk50AMpFOudM+seE52F20P8ySgjn1OHiUwlA3MLe2sTz2vCxNDGUB 4yIE0szy5v4PY0Pdj2+oaDAHMwdB0oprppoma0NVgQ7Mh9nzCD4rT88tNBr0KVIwX5ou4PFFEplS pUhghRCfxD8Iki8UiSgBqH+DLjj+gw3YdoMQQgghhBBCCCGEEEIIIYRQLPwG+IA+yQ0KZW5kc3Ry ZWFtDQplbmRvYmoNCjIyIDAgb2JqDQo8PC9UeXBlL1hPYmplY3QvU3VidHlwZS9JbWFnZS9XaWR0 aCAxNjQvSGVpZ2h0IDExNi9Db2xvclNwYWNlL0RldmljZVJHQi9CaXRzUGVyQ29tcG9uZW50IDgv SW50ZXJwb2xhdGUgZmFsc2UvU01hc2sgMjMgMCBSL0ZpbHRlci9GbGF0ZURlY29kZS9MZW5ndGgg Nzg+Pg0Kc3RyZWFtDQp4nO3BMQEAAADCoPVPbQdvoAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAB4DN7wAAENCmVuZHN0cmVhbQ0KZW5kb2JqDQoy MyAwIG9iag0KPDwvVHlwZS9YT2JqZWN0L1N1YnR5cGUvSW1hZ2UvV2lkdGggMTY0L0hlaWdodCAx MTYvQ29sb3JTcGFjZS9EZXZpY2VHcmF5L01hdHRlWyAwIDAgMF0gL0JpdHNQZXJDb21wb25lbnQg OC9JbnRlcnBvbGF0ZSBmYWxzZS9GaWx0ZXIvRmxhdGVEZWNvZGUvTGVuZ3RoIDk3MD4+DQpzdHJl YW0NCnic7dnfUxNXFAdwdje7m2zIL34lBkghQRRTgQYzhcKAQFBAKOMgDKnOgBWr0BIj2NYRFLRS gaoNDWBQAiY0CUlIson/YDcJuMuUd8/D+Tzl8Tvn3j333JuCAoQQQgghhBBCCCGEwCIkvnSWUxAE SVInkCSsoARB0XJOWShSKhWsjAQUkiBpTltWbqqq/qzKZCxRsRSckARdqK/55rvL3Y7Putq/tVZq WTCVJChOb+28cXtqxvUgz+X65d6ta3aTmgaTkdGd7Rr/bfnN+j/H1j1ri9OD9Xo5+aXDHSEVhqbR xx7/v+HIsXAosLU00WZSAtmRBKU0td9d2Y0mU4JkXiL68a+pbrNKBiWjytwz4wklM5k0nzyM58TC /pV7ndVgMsrUNb0PvRE+k07FQoFdv39nZ+eD7+2Tm80VYNZapjnbN7d5wGf42Efv2svnS4LF+dnx nroSFsg3k83Yn82YTgTX56fHb/7gdDrHRgY7vjYWAllqMSMf+/Bi8lqrvUlga7hg1qsYIGWUZIxu PR62W8rPGAwGfVmxRkHDOWaOM6YONn8dvGgs0mo0alWhggE0U5xWR32JVglqovj/frQ1Wi1n1HAm itO+67GR7zsbKuFMFGJGsT8uLszd6W8wKMCstpjx6JwRjhmf59mPl81qKO1RzPgpf17HBJG9N+7+ 8zowiy1m/JThU4lDQTwa8MwO1OkYeBkz/OFBaD8YDAR2t17ed9Ro4NUxw8f3t9dfr62uriw/nRm2 l0OZeqS9JxnafDE7dXdy8s6Ec6DZooMy9Uh7eNz/59R1R3tba2vLJetXRXBaj/QsfPdkpLnWVFlR bjQUq+VgOs+JmWJjrr+uTKXkOE7B0nCqKM0Y8T7srdUpWIahaRkF6b1HWsdHA1aDRpV78OEgVVKy H30LY21Wizn/3lMKaEeKvedwb9XlHLjS43A4ujta6qvgfNmS/hjeXp2fc+fee+6PD7WYdVAuNELG mr7Zjezckwjv+Ta82Qcfz+vnD4YvGTkghSRkastVtzeSymTSyXj0IP/gE/Qt/9RlgTKdEZSquvvn t/sJPp3mjx98ErHg3+6+c1ogUwVBcRWtE3+8D8XiouwE6eqthZKxgJSX1g+5X22835HY9jy73QHm TaqAoNVVLTemf3+6JFpceATqRkOQ8iKL/cr1UadobHSoqxHWzVChq6i92GizNR2x5W7YGkA3bOGz YZXa4tIyidJiDcdAWekcgpTRDMuy8iPCT4amAFUxJ/tn3Akw/zNECCGEEEIIIYQQQgghhBBCCI7/ AIwZghUNCmVuZHN0cmVhbQ0KZW5kb2JqDQoyNCAwIG9iag0KPDwvVHlwZS9YT2JqZWN0L1N1YnR5 cGUvSW1hZ2UvV2lkdGggMTcyL0hlaWdodCAxMTYvQ29sb3JTcGFjZS9EZXZpY2VSR0IvQml0c1Bl ckNvbXBvbmVudCA4L0ludGVycG9sYXRlIGZhbHNlL1NNYXNrIDI1IDAgUi9GaWx0ZXIvRmxhdGVE ZWNvZGUvTGVuZ3RoIDgwPj4NCnN0cmVhbQ0KeJztwQEBAAAAgiD/r25IQAEAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADvBunQAAENCmVuZHN0 cmVhbQ0KZW5kb2JqDQoyNSAwIG9iag0KPDwvVHlwZS9YT2JqZWN0L1N1YnR5cGUvSW1hZ2UvV2lk dGggMTcyL0hlaWdodCAxMTYvQ29sb3JTcGFjZS9EZXZpY2VHcmF5L01hdHRlWyAwIDAgMF0gL0Jp dHNQZXJDb21wb25lbnQgOC9JbnRlcnBvbGF0ZSBmYWxzZS9GaWx0ZXIvRmxhdGVEZWNvZGUvTGVu Z3RoIDE0MjU+Pg0Kc3RyZWFtDQp4nO3ZaVcTVxgHcGcmC9khCZCdBAIVEJFFtgCyC1pZLFKwEsoi CBwi4MaiQjEGSThAQlSQQDaYLGQmEz9h70DbF31j33F7zv19gv+555lnnvvca9cQBEEQBEEQBEEQ BEEQBIEExrrqED+GYThOXMJxqBNjOMHlpQlFYrFYJBKk8TgEDmlaDOfwhTKFSpdjNJmMek2WXCrg cWBMyyaVKHTmktuWpta2tpbG2vKiXI1cxCOgC4vhPJHCUFzb8fDJxPSczTY7NTrU01p1XZch4EAW FiP4Mk2h5YF1bnlja2fP7d7ddqy9nn7cVZWnFMB1shiRlpFT3mld2Nj5ehw8JUnyLBzwfd5+PzfQ YJbzYapZEFWeW9M3vbbnC0fPKYoGqEQ8Ejp0vhysMYhhqgKcn5Fb+2h+8yAcp5JJEBNgAyeiJy7b vUI5D7/qhP/AuBJDdf+iyxcBSak4GQqc+ANhMpagKfLr6kBZVho0WTFCkF3abXMex2iGjoePPC6H 3b657fkWJGPkt/XfbqvgyYrz0s0tT+1HUZqhIse764tTo1br2PTiuy2vz+dZGSjPhiYrRgjVFQPL n0lwqpHDzcXhn5tqq6rrmu8PTr3ecLyf7ipSQFOvGFdmbnu2FUgwyeiRY7avrsioVat1xusVzX3W iZHuKoMEmj6Ap2Xd6l/+EkkyCb/L1lNpVEpFYHyRKjTm0ro79WWmDGj6K0aIDA3jDn+CoUnv0kBV ToZIIBAIhSJJeqbOZM7VQvSTBSWQ3/l874xmEoFPky35CokkXZGZlZ2tUmv1Br1aLuLCcqygCyhu 9C19jTJM7GB1oEKTIdeab9wqL69glZXka9L50MwDoFzLh9Z850ySdC/cK8zONJW39gwMDrEGHz1o KtXLoGkDuEBdbbWDcqXCrmfNedmGyu7JV2/X1llrq4tj98s0IlgOlhBo68Y2gxRDBTbH6k2a6+2T f3gOfReODvbWJ9sL0rmwZBXqGp46QxToWPaRWqOutPelOxg9vxQL7S/138riQ1IEhFDfOOkKgzZw YrfWGPWlfa+9p+c0nWSYVCoZP/4wXK0WwJO1YdIJslIBx6jFpC2+N+c8CpNRMB2mvqfYwqjTComr TnmJEGrrJ7bYeg05p5ry1LmWoZcfdzxfjkLx5PfvdGhrvF4HS1bQB2pGPvopJnnmnu8qVKkLG/vH ZuffbLgDcSYFsk5AlPXv/nr5L9Ap1eYyS0vnw4nV/TM6RUGVFeMpinvffIkyKfCPnWotyEyXq3Sm nyrvzzjB6AVZVo7U3D63c0qnkpHPy79W58jFYoksM6/hd/sJbFnZBls38uEYFEEi4LJ1VxiVMrFE YaqHMSvOV5b0vvKA4gSz9seZnlowa2uNN+9ejN+QZcU4EtOdcbuP/erJQ8f8E3CHqa7vHF7ynML2 bV10gps9CzvBBAPuhr6dNfZuODqzsn0C0lPBT+MWiLKCgzXUPV7ZD4OwdCz0jb1zO1xef5ROpdif Wa1GAE1WULHygpbR997weZK53GX4/SHyHERNxo7WH8O0H2Bv3VnFHePv3P4olfxrR0SxwwsdD+69 6ClRwjJnsTCOSHWjbeSN8yAYOWcXWcmL5Vvs9Hhv1dqYK4Vlfr2Ac8WqwsZHM2+dXl/wlIxEI5Gz 0MnBrv2Fta0oC64FLIZzRZl5lR2Dz16tf9px73u9nl3nhxXbaG9DoQqqlSYL46Slawoqm7uHxqdt Cy8Wn88+Hf7lrqXEqAR37qsO928YwRNmqE1FFZam9s6uro6Whqqb+fpMaRqMLzEYTvAEEnm2NifX nJ+fZ9SrlTIRH8akLAwjOOxTnEQqlUrEQgGfS+AQPx1evnFygMtHzqvO8yMY9j95PEYQBEEQBEEQ BEEQBEEQBEEQBEEQ5D/6E4VF56cNCmVuZHN0cmVhbQ0KZW5kb2JqDQoyNiAwIG9iag0KPDwvVHlw ZS9YT2JqZWN0L1N1YnR5cGUvSW1hZ2UvV2lkdGggOTYvSGVpZ2h0IDExNi9Db2xvclNwYWNlL0Rl dmljZVJHQi9CaXRzUGVyQ29tcG9uZW50IDgvSW50ZXJwb2xhdGUgZmFsc2UvU01hc2sgMjcgMCBS L0ZpbHRlci9GbGF0ZURlY29kZS9MZW5ndGggNTU+Pg0Kc3RyZWFtDQp4nO3BMQEAAADCoPVPbQwf oAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAeBqCgAABDQplbmRzdHJlYW0NCmVuZG9i ag0KMjcgMCBvYmoNCjw8L1R5cGUvWE9iamVjdC9TdWJ0eXBlL0ltYWdlL1dpZHRoIDk2L0hlaWdo dCAxMTYvQ29sb3JTcGFjZS9EZXZpY2VHcmF5L01hdHRlWyAwIDAgMF0gL0JpdHNQZXJDb21wb25l bnQgOC9JbnRlcnBvbGF0ZSBmYWxzZS9GaWx0ZXIvRmxhdGVEZWNvZGUvTGVuZ3RoIDYyMj4+DQpz dHJlYW0NCnic7djbUxJRHAdwd1kuy8ULkCgEZGZM3kYrISLDoos1ORMG06Rj44RS6thDUWODZaMW aUqlNXlBJxclhGXZ3f7BdndqmsieztL08Ps88fQ9e37nnN/8hooKAAAAAAAAgHwwDP8LDJMjXkGo NaT2DySpURE48goYoak01Vlth0vZ6mtrdCrUBTAFaXK2nPb6fOd+5zvr6TxurVThaPG42njMe2Ng ODJS6t7d8KUOm55A2gBG6O2e0MMXr94slErMTUV6m81qpA1gqhpX7/jrz9s7VImdL6kP8UGPTatA 2QCuNrcFn66mczRdEDEC6QdN57NbiajfqZcvn2E5jud5ji0Ka8iTL9VnIiHWJ72XpYsc/41nmVxm l6KE+kwj10c83zNh8XwXl96vUbmi8PmFzNbH5FvxfEeuIp+vdD/7hPs5Ovbo5QpFc3wxu7kwNXl/ VLifl5Hvp7AB0nSkVXhf3YGb0dmNfZYrUMnYwLWebuF9uZDf16/+4Ghy98dWM0U2vz0fCbQdtcvT H8QOoRT7m8HsujL5bo9h85szd7rs1XqZ+tvP/qw0NFwcT+4ybG7jebijliTk6s8/KHTOnrFlKX86 1I54bSAf8iEf8iEf8v9dvv/BUlrIX4/fKke+1nE+ukjRTHbtWX+rqQz5Nu/wXOrrfnrlcd8JI/Lc UwrXWDpDT5bXU5/mo4HGKqWMo4NEmHSbLgzFZmbjE8FTVh3SVHtgvkJrafEHB4duX3c3VMteHqFA Sr2lsb3LfbLZYdTI/vniKK3UVh2qq7eYDOoyxIsLSJOoTFPngStg8v0tAAAAAAAAAAAAgP/Hd/z+ KrgNCmVuZHN0cmVhbQ0KZW5kb2JqDQoyOCAwIG9iag0KPDwvVHlwZS9YT2JqZWN0L1N1YnR5cGUv SW1hZ2UvV2lkdGggMTI5L0hlaWdodCAxMTYvQ29sb3JTcGFjZS9EZXZpY2VSR0IvQml0c1BlckNv bXBvbmVudCA4L0ludGVycG9sYXRlIGZhbHNlL1NNYXNrIDI5IDAgUi9GaWx0ZXIvRmxhdGVEZWNv ZGUvTGVuZ3RoIDY1Pj4NCnN0cmVhbQ0KeJztwQEBAAAAgiD/r25IQAEAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADwbq9cAAENCmVuZHN0cmVhbQ0KZW5kb2JqDQoyOSAw IG9iag0KPDwvVHlwZS9YT2JqZWN0L1N1YnR5cGUvSW1hZ2UvV2lkdGggMTI5L0hlaWdodCAxMTYv Q29sb3JTcGFjZS9EZXZpY2VHcmF5L01hdHRlWyAwIDAgMF0gL0JpdHNQZXJDb21wb25lbnQgOC9J bnRlcnBvbGF0ZSBmYWxzZS9GaWx0ZXIvRmxhdGVEZWNvZGUvTGVuZ3RoIDM2Pj4NCnN0cmVhbQ0K eJztwQEBAAAAgiD/r25IQAEAAAAAAAAAAAAAAAAA8G46dAABDQplbmRzdHJlYW0NCmVuZG9iag0K MzAgMCBvYmoNCjw8L1R5cGUvWE9iamVjdC9TdWJ0eXBlL0ltYWdlL1dpZHRoIDE2OS9IZWlnaHQg MTE2L0NvbG9yU3BhY2UvRGV2aWNlUkdCL0JpdHNQZXJDb21wb25lbnQgOC9JbnRlcnBvbGF0ZSBm YWxzZS9TTWFzayAzMSAwIFIvRmlsdGVyL0ZsYXRlRGVjb2RlL0xlbmd0aCA3OT4+DQpzdHJlYW0N Cnic7cEBAQAAAIIg/69uSEABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAACPBuW8AAENCmVuZHN0cmVhbQ0KZW5kb2JqDQozMSAwIG9iag0KPDwv VHlwZS9YT2JqZWN0L1N1YnR5cGUvSW1hZ2UvV2lkdGggMTY5L0hlaWdodCAxMTYvQ29sb3JTcGFj ZS9EZXZpY2VHcmF5L01hdHRlWyAwIDAgMF0gL0JpdHNQZXJDb21wb25lbnQgOC9JbnRlcnBvbGF0 ZSBmYWxzZS9GaWx0ZXIvRmxhdGVEZWNvZGUvTGVuZ3RoIDEyNTI+Pg0Kc3RyZWFtDQp4nO2Z6VfT WBjGTdKmaSlLC6UgYAFZBBwUhBGVgYPK6kJBlgEPoAgii+JR2TdBoLLL1pYCBbrQLclNwj84N46z OXPmK/d47u9b76fnvE9vnudNLlzAYDAYDAaDwWAwGAwGg8FgMD8gBEFSEJIkzlvJ/wJV0owmLEyj phUoSyVIpUZnTDSZkuL1WhphpaRSa0zPLy4r+6UwKyESXaUEpTHm3G160dfX3VqVnxSuRFUoqdJn 3Hs2allfX5p69TDXqKbQVEpQYQk/t4xvOj3eE+tcV1lqBKIjJZRRGRUDq8dBHrCe7ZH6XANDnrem /4RkjHlNEzY/kCQh5FzoLL6kRdJ7QqE1lXRZjlnx7EzivZtvqzN1SHpP0PqsB++2vEA6OzsTAo6p X2/EIek9qY4vaJl2BOFA4Ui5k6WXpclaBXojJRThKWU9yyec9FUoON1+/yhbTyMolI7OqR3a9sGr JCME9z8+LYxXU+et619Qmos322YPQoIoACBIIuda6b2bGoGc94Qi4vL9vlUXJ4BQIMACEfh2h81X Y1SoXSdSFfNT3YjVB0DQfej0hIAQOpxrL0rQIOY9jM/EWx3zhyHAuq2razYPJ3DutYHytEjEHqWE MjK94vW6h+P9e4sjo58dAQD8trEn1wyIeU8ysdcbxu1+wLnWP3S+GPni5gTWufD8TlIYUjFKUNpL xZ2LRywIHnzqNte9WnCGBN7zZbAqMwop7wmlLrP67aaXh35PPK2obJ/eCwhCwD7ZlG9EKkZJJu5G 85QjKACfdaKt5sGzKZtfELljS1eJCaUYhcUpubR76YQTBb9j/nVHx+DifkCQgHfr3YMslGIUFqfs R++3T4Eksq6dxakpy66bFSUx6JhuKYhXo+M9pY4vbJ3ZD4qSBIKeQ/veoSckSHKFWu4pSwlHxnsY n6l3X624YHGSRMAFA4EgJ4jwB/DtDNXmRCPjPaGKvmoe3vlanGAl4SEACpU3koPZtpsXkYlRSpNQ 1D53CN0WeBbOUybI8rBC8a7VvvuXUalQhCIyrXxgzc2LAnt6vG+322x2+/7xqdz4/NbRulxUKhSp Mlx7Mmb1w8Lk2v08Mz46MjI6PvN51xUS4DY633E7EY0YhcUp6c7zr5np3Znuba0319aa61t7p3e8 vMh7Nl5XpqMRo/J7h6o3Gx4e5vz8y5qi3Jzs7JzcmzXd8wcwqQL28cbrsUjEqFycGifsAcCfbn0w 55sMep1Ob7iUZ36/dQoE9mixsxiNCgUrM3QeFicWRntpahRDK5U0E5VS0mU5YmGF2nhTmY5CfZbX 5HtwWWI5n228MU9+hQeh1Ma8hjGrj+fhM/8xEmuzvNWV968c+XzO5f6KP+6N3PjLe5ecvoB7G+54 KIQTnGhyaefHbYd9dbipEKbQ70Lh9lzQOLRq37da+quv6FAQSmni8x73jM5MDraWpunob/ebpHVp JS2Dk7OTb5pumZDoJSQdlVxQ2dDa/PB2puHPl8zwX2rIuP2w+Sk8To9hULj1BMVEJV65fiMv2xSj +WtyhEITbcrOL8jP+cfxeUJQKq3OYIzVhzN/F0QomHB9bFxsNDxG5PsIQSpoFaP6/huYfMwwDK1A wfdvEARJkvDx+f2pfEx+f4zBYDAYDAaDwWAwGAwGg8FgMBgMBoPBYH5ofgPLw6CSDQplbmRzdHJl YW0NCmVuZG9iag0KMzIgMCBvYmoNCjw8L1R5cGUvWE9iamVjdC9TdWJ0eXBlL0ltYWdlL1dpZHRo IDE2Ny9IZWlnaHQgMTE2L0NvbG9yU3BhY2UvRGV2aWNlUkdCL0JpdHNQZXJDb21wb25lbnQgOC9J bnRlcnBvbGF0ZSBmYWxzZS9TTWFzayAzMyAwIFIvRmlsdGVyL0ZsYXRlRGVjb2RlL0xlbmd0aCA3 OT4+DQpzdHJlYW0NCnic7cExAQAAAMKg9U9tCF+gAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAB4DeMEAAENCmVuZHN0cmVhbQ0KZW5kb2JqDQoz MyAwIG9iag0KPDwvVHlwZS9YT2JqZWN0L1N1YnR5cGUvSW1hZ2UvV2lkdGggMTY3L0hlaWdodCAx MTYvQ29sb3JTcGFjZS9EZXZpY2VHcmF5L01hdHRlWyAwIDAgMF0gL0JpdHNQZXJDb21wb25lbnQg OC9JbnRlcnBvbGF0ZSBmYWxzZS9GaWx0ZXIvRmxhdGVEZWNvZGUvTGVuZ3RoIDExNDE+Pg0Kc3Ry ZWFtDQp4nO3Z2VMTSRwHcCYDuTCQgOEKx2rWXTmWIwEFklURKHUBYbE4VivKtRAUFBXU5b7CISEe BAhJzDUhyWTu7D+4PaIBq/adfujPyyRv3/p1T/dvulNSEARBEARBEARBEARBEASBDYZJzsIw7LwT /R9MkiqVK5QnFHKZNBWHMCiGy1TZuQW6QpGuID8nS6WQQhcUwxVZxWXGepPJbDabTA3Xasou5amV aRKocmISWZa+vq1/YHhENDz4uK+jyXglL0OGw5QTS1WV1PdMLti2tr/aXF+cHuttripSQ5VTIs0u b3++degPhoBgMOBzO7dnR+/XFWdKJecd7pREnlf3cNEVoRiAFsUjgX3bZKehID0VnnLiSp1peDNA 84LAsSAkw4JHxL3x9G7ZRRk85cTTi26M7RCskOCoKBEMHZMMx7NR15KlsQiicuLpxbfGd8OswFOh Q8f7nU/uMMUJDOF4ce9XdRp8Mdnj/dWX1vFXq06CFnjSNddTrYVn1JMxaf/WxIPWlq7RZVeM42nf muVavgK6mHzcs2T5vby0rnPKQbA8E9wcatQpIYx5NNdbd6morNX6PsiAmFvDJp0SP+94353GdC88 bPhFX902uUswPO23DdQXQDjolM821mY23XkyfxDlwBRY7DfkyKGLKbDEpzmrxWKd+xCkeC7qnLlf liWFbUHiBD7u/7yxsrrtDMQ5kNn+rEWfAd26ySUSXDzs834JRMDqLtCBzZEbJSrodiEQU+AZKk7R LA9+0oGtsdv6TAir+S/IybEsxwuJRIINf3zdVZWrgKblPFNNjo7HYiTFgEHnSc/6SNPPamhazmRM gY0F3YcHLm8oxvBgh3e+6zHmK2EpZ/JN52Le3eV3b2ZX7C6C5nnKv21thuddT66bTMgxM9Dd2W2Z WNkPM2Dl3H/T9Vs2LKN+ugt5V4daasorG9pH1zwkKKd3+VFtHiz70A+tR22xNqfE+OfrzxFQ3cDG YAM0u3oyJun6p7sqV6XSXr0zsUuIk2B7xFwIS490ppqzPQadRpNf8cfzD2H2eysHWzXjnuXHN8sv 6ytuPJoVeyTav/7kOjT9++lHRmBnqv/u7eZ2y7TdT/E8eTTfW5MDy9dQct1ko0ebbyfGn71acnyJ gb/hjy/brmpgaeVAzJtWe1jsio69ew67Y88dIlmeIz2rg+aSC7D0SOJxwujX4wSeISMEEY6QNMex pG/nRUeFFpZlUzycaRzaAJNR7I8YmmYYlmWpiNc+3Xu9CJ6GUyLPNfbPH4RJShQHyGjY57RN9Zn0 GlheIPHgMKv03tO1vSPvN56jfYft7d+d9fpsOSz9kXgMe6GwtmtsZmFp+cTi3MzEYHdTVYkGopSg nDL1T8aWrt7+v070Pehobay8nKuC6rQ4BcPl6oIrFdUGgxEwGGoqS/WF2gwFZHcEIKc0PTNbm/ON 9qImI12WBt2NSwomwdOkMplMDoCHNC0Vl0AXUoT9cB0I6WUggiAIgiAIgiAIgiAIgiAIgiAIgiBn /Aekn97QDQplbmRzdHJlYW0NCmVuZG9iag0KMzQgMCBvYmoNCjw8L1R5cGUvWE9iamVjdC9TdWJ0 eXBlL0ltYWdlL1dpZHRoIDUwNy9IZWlnaHQgMTE2L0NvbG9yU3BhY2UvRGV2aWNlUkdCL0JpdHNQ ZXJDb21wb25lbnQgOC9JbnRlcnBvbGF0ZSBmYWxzZS9TTWFzayAzNSAwIFIvRmlsdGVyL0ZsYXRl RGVjb2RlL0xlbmd0aCAxOTM+Pg0Kc3RyZWFtDQp4nO3BAQ0AAADCoPdPbQ8HFAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA8GyxUgABDQplbmRz dHJlYW0NCmVuZG9iag0KMzUgMCBvYmoNCjw8L1R5cGUvWE9iamVjdC9TdWJ0eXBlL0ltYWdlL1dp ZHRoIDUwNy9IZWlnaHQgMTE2L0NvbG9yU3BhY2UvRGV2aWNlR3JheS9NYXR0ZVsgMCAwIDBdIC9C aXRzUGVyQ29tcG9uZW50IDgvSW50ZXJwb2xhdGUgZmFsc2UvRmlsdGVyL0ZsYXRlRGVjb2RlL0xl bmd0aCA3OT4+DQpzdHJlYW0NCnic7cEBAQAAAIIg/69uSEABAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACPBuW8AAENCmVuZHN0cmVhbQ0KZW5k b2JqDQozNiAwIG9iag0KPDwvVHlwZS9YT2JqZWN0L1N1YnR5cGUvSW1hZ2UvV2lkdGggOTgvSGVp Z2h0IDExNi9Db2xvclNwYWNlL0RldmljZVJHQi9CaXRzUGVyQ29tcG9uZW50IDgvSW50ZXJwb2xh dGUgZmFsc2UvU01hc2sgMzcgMCBSL0ZpbHRlci9GbGF0ZURlY29kZS9MZW5ndGggNTY+Pg0Kc3Ry ZWFtDQp4nO3BMQEAAADCoPVPbQZ/oAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD4D hTgAAQ0KZW5kc3RyZWFtDQplbmRvYmoNCjM3IDAgb2JqDQo8PC9UeXBlL1hPYmplY3QvU3VidHlw ZS9JbWFnZS9XaWR0aCA5OC9IZWlnaHQgMTE2L0NvbG9yU3BhY2UvRGV2aWNlR3JheS9NYXR0ZVsg MCAwIDBdIC9CaXRzUGVyQ29tcG9uZW50IDgvSW50ZXJwb2xhdGUgZmFsc2UvRmlsdGVyL0ZsYXRl RGVjb2RlL0xlbmd0aCAxMjA1Pj4NCnN0cmVhbQ0KeJztmOlTGkkYhzMX1wwCKwJR5IgSb11do9EY FPBIynVTq2a1shrvO5AyqxuMFd0YFU9U1HgTkEOugfE/3MZYu7VV+2lt9lM/H+fDPNP9dr/967l3 D4FAIBAIBAKBQPwXMEAKX47jxA04ngoNhhMUXyCiGYahhXyKhC3BcJJPS+QqtVav12kyFTJGQOEw FRjBZ9LVhtKqOpOl0VJfU56vVaQJSHgOnBTK1IU1LR29I5NW25vxga7Wp2X6DBrWMDCcohWG6tZe 69znDefe3u7W6sd3Qz8bC+8zFBwDTjGqQlO37Q/nkfsyEAwGfZ5T18psX3OxUkTAUGAkrSpuHpjb OvWFomwcwMYigYu9j4Nmg5QHwYARwozCpqGFfW+YTSTiLBsDlgQbuXTZX5YrBfjdDThPltvQv3Do iya4ePTK5/VcBsBY2Ih7ZbA2C8I0YSSjruqyu3wxjmOv3Ifba46N3SN3IBz2rI8+zYZgwPnpBc+t m54ox8X8R473U8ODo7a5Vdf51+PPA7XquxswglY/7lk8CSU41n+wON7RWFdrbOkYmllaX3nXCaMO GCV92GJ1+lgufnW0ONRSkZudpTGUGV+8HhvtMuZCWEu4QFH+y/xxOMFF3Y7xZ8WZElpESxS64hqT qTpPAaEMBJ1dN+TwxLhE8OD39opMhgeaNyUQy9X6B2o5ffc9jZFpOU3WnUCcYz1row0PJMlOhN00 WnEaDaP1YZSsoG32MMRxkdOF7gqVkLh9jhMkScDoezhPXtoxfxLhuNDhbFuB7O/CwjpNcb6ionvx PArKsGdryhGT0A9PXKCs/PXTRZSL+7cnTVqGgC0ABtWj3iV3DBi2xus1dAoMQlVV7+eUGsAYesAY ruMB55RZl5JZUla+AnW4BpV+25yTloJK8zPKuxbOotdgtc78mC+l/rFaYehwXnpJ+9xxGOy4k/nO sgz+bStN7jiKJCA4QGvNa/3t4CpxHXMv9z/RMMmo961rpEnEQghpBiPFesvktj9+HffvvG0tVogo Any9QJyhzsnVKsS8ux/ThCirpm8ZLFcufPqp35SvktA0I1XqSmotTXVFmczdSw9KXdpu/3JzxLns Pebvc7XZuofl9S/6JiZ6GgvkfAhnnCTXMrHhBYOIenY+DLc31xtNz18OzyxtrL1/VQ0ha4C0dL+y 68NhMM4lIt6DFbt1bHRyet6xf+45dYw1gE5192mipAbL6MpZCCiiAfeXnc3Nbdfx12Ak7N2aNOvE EPISIVSW/WTbuAAKkMhCAd+lPxiOxdmw2zFiBJ0KxpYQa6o6p9fPgrFE4iZWJrMrG/a67F0/qIQQ UiVYTlL9407b8gGYmlj8JhlHQ74z53y/2SCDsCGS8ySQ6avahu1r+2ceXyAY8HsvjpxL0z2WIkjp PnnFkmaXmjpHZhZWt3Z2d7bXluasr9tq85QMBWMINwqeWJlT3tDWPTA29WZqfKinvbmmSJMugndZ BPcsoUSpK6yoMZrM5vonj0oMajnDJ2FeeLFk0PtOkZmt1Wk1WSq5hOZDvIl+U4CWzRMIRTRAJOBR UOLYv0jw258OKfnr8Jcmde9GIBAIBAKBQCAQCAQC8X/xJ9tSY7ENCmVuZHN0cmVhbQ0KZW5kb2Jq DQozOCAwIG9iag0KPDwvVHlwZS9Gb250L1N1YnR5cGUvVHJ1ZVR5cGUvTmFtZS9GMi9CYXNlRm9u dC9BQkNERUUrQ2FsaWJyaSxCb2xkL0VuY29kaW5nL1dpbkFuc2lFbmNvZGluZy9Gb250RGVzY3Jp cHRvciAzOSAwIFIvRmlyc3RDaGFyIDMyL0xhc3RDaGFyIDEwNS9XaWR0aHMgMTU4OCAwIFI+Pg0K ZW5kb2JqDQozOSAwIG9iag0KPDwvVHlwZS9Gb250RGVzY3JpcHRvci9Gb250TmFtZS9BQkNERUUr Q2FsaWJyaSxCb2xkL0ZsYWdzIDMyL0l0YWxpY0FuZ2xlIDAvQXNjZW50IDc1MC9EZXNjZW50IC0y NTAvQ2FwSGVpZ2h0IDc1MC9BdmdXaWR0aCA1MzYvTWF4V2lkdGggMTc1OS9Gb250V2VpZ2h0IDcw MC9YSGVpZ2h0IDI1MC9TdGVtViA1My9Gb250QkJveFsgLTUxOSAtMjUwIDEyNDAgNzUwXSAvRm9u dEZpbGUyIDE1ODkgMCBSPj4NCmVuZG9iag0KNDAgMCBvYmoNCjw8L1R5cGUvWE9iamVjdC9TdWJ0 eXBlL0ltYWdlL1dpZHRoIDEwMi9IZWlnaHQgMTE2L0NvbG9yU3BhY2UvRGV2aWNlUkdCL0JpdHNQ ZXJDb21wb25lbnQgOC9JbnRlcnBvbGF0ZSBmYWxzZS9TTWFzayA0MSAwIFIvRmlsdGVyL0ZsYXRl RGVjb2RlL0xlbmd0aCA1Nz4+DQpzdHJlYW0NCnic7cExAQAAAMKg9U9tDQ+gAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAHg0iqgAAQ0KZW5kc3RyZWFtDQplbmRvYmoNCjQxIDAgb2Jq DQo8PC9UeXBlL1hPYmplY3QvU3VidHlwZS9JbWFnZS9XaWR0aCAxMDIvSGVpZ2h0IDExNi9Db2xv clNwYWNlL0RldmljZUdyYXkvTWF0dGVbIDAgMCAwXSAvQml0c1BlckNvbXBvbmVudCA4L0ludGVy cG9sYXRlIGZhbHNlL0ZpbHRlci9GbGF0ZURlY29kZS9MZW5ndGggOTU1Pj4NCnN0cmVhbQ0KeJzt mOtTE1cUwL37ymazmwB5ECQhDQEqRgd5GKkNoPKwibbqUF5VfLTEgRYIBcdaQWAoigHFkgQwiAYJ 5MGSfYR/sJtEOuN0OqMzux/U+/t4Z/b87rl359x77pEjEAgEAoFAIBAI5IsHAARBUQQB7w3lRsD/ f/WxEgRXqSlKrcIOPZKCICmKInFULg1AVVrDUau1RE8T+aCSlio0W6ylpgI1hsgkIQttJxub3K7j Fp0qFxPgtLmq/tvms6ccRg0mSzYA19lc3/f7Bq576i1MNiZA1Sbnhe6f797pbP7aQCJyaBDSVHNl eDbw9NGg12nIJgNwbXnLzT8eL85P9J21MXIkA1CN1X1nbn0rujrdf+aoWpo5IPQnrow/39x6tTji OVZIyGJhytuHl7fZvbdLgy1lGmn/pezqeqcjCTa+9mdnjUElw/4DTFvx3e+hBM/t/j1y4Ss6a1Gb Xf1/vWb5vY3pnjojKYtFV+mdWE0KfCI42mbPW0rO3Hoc3RfYzdm+epPcFj+0fKRlrMOhxVEE05R+ c/uJQpZkeMJbbWQ0FF1kbx5Y2FLEIqTWH3Y1VpVZLVZHrXf42XZaEQv7+snQtbZmt7vp/OXbk+E4 p4RF5HZX58aHfAMDvkH/1HJ0TxAVsGQENhZZebYYCCwuvViLJjlRCctBRthP7sa2JWI7CZYXM4pY DjIiz6VzcLwgZg6Usgj8O7ISZSwZkWNTyYREMsWmBWVyyYjpePRlOBQMBsPrmzssr8i+iFw8Epic GPP7/eMP5kNvWUX+ZHE/Ghjtu9zR3tbh/fHuzHqCV6bCvJzqdTsd5XbHsdM/jD6PKVJhpGp575Kz WMfQWoOjxfdUmWrJJ0JjHRU6AkNx2qJc5c+dYox0V0apz+CshJYPtXjGw5IlvjLaemhx3Zx/I1le zfTWyWTROi6OBeNceufFb+dt+Xuy+fSNuc09LhV51F1rlOWejDL21qGlrWTizYKvyUrlLMZTXZNr O6lY6P7VE3pCFot0+7oxtbIRWX7Q02DOLg8giqo9wwtrG6vzg+2VBbg8XZLBefGX+zPT9261VuWa FYAxZY1dI1OzD3+91lCqkaWBBRhdWtPa+VPf1XNOM5Xv+MiiisZLPde7PS57ASFLxwcQQltSWdNQ f9JRTOP57hVT623H6xpqq62FpEy9uKShCozmYoNOjb+bN8BIRl9sNhXRKvkafgTFVSSpwtF/nyoA ghEkSRKYLMt1GBQgyPvPIf8dgUAgEAgEAoFAIBAIBAL5VPkH8L7C4Q0KZW5kc3RyZWFtDQplbmRv YmoNCjQyIDAgb2JqDQo8PC9UeXBlL1hPYmplY3QvU3VidHlwZS9JbWFnZS9XaWR0aCAzNDIvSGVp Z2h0IDExNi9Db2xvclNwYWNlL0RldmljZVJHQi9CaXRzUGVyQ29tcG9uZW50IDgvSW50ZXJwb2xh dGUgZmFsc2UvU01hc2sgNDMgMCBSL0ZpbHRlci9GbGF0ZURlY29kZS9MZW5ndGggMTM4Pj4NCnN0 cmVhbQ0KeJztwTEBAAAAwqD1T20JT6AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAeBrQ9wABDQplbmRzdHJlYW0NCmVuZG9iag0KNDMgMCBv YmoNCjw8L1R5cGUvWE9iamVjdC9TdWJ0eXBlL0ltYWdlL1dpZHRoIDM0Mi9IZWlnaHQgMTE2L0Nv bG9yU3BhY2UvRGV2aWNlR3JheS9NYXR0ZVsgMCAwIDBdIC9CaXRzUGVyQ29tcG9uZW50IDgvSW50 ZXJwb2xhdGUgZmFsc2UvRmlsdGVyL0ZsYXRlRGVjb2RlL0xlbmd0aCA2MT4+DQpzdHJlYW0NCnic 7cEBDQAAAMKg909tDwcUAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAPBpr4 AAENCmVuZHN0cmVhbQ0KZW5kb2JqDQo0NCAwIG9iag0KPDwvVHlwZS9YT2JqZWN0L1N1YnR5cGUv SW1hZ2UvV2lkdGggODQvSGVpZ2h0IDExNi9Db2xvclNwYWNlL0RldmljZVJHQi9CaXRzUGVyQ29t cG9uZW50IDgvSW50ZXJwb2xhdGUgZmFsc2UvU01hc2sgNDUgMCBSL0ZpbHRlci9GbGF0ZURlY29k ZS9MZW5ndGggNTE+Pg0Kc3RyZWFtDQp4nO3BMQEAAADCoPVPbQlPoAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAB4GnIwAAENCmVuZHN0cmVhbQ0KZW5kb2JqDQo0NSAwIG9iag0KPDwvVHlwZS9Y T2JqZWN0L1N1YnR5cGUvSW1hZ2UvV2lkdGggODQvSGVpZ2h0IDExNi9Db2xvclNwYWNlL0Rldmlj ZUdyYXkvTWF0dGVbIDAgMCAwXSAvQml0c1BlckNvbXBvbmVudCA4L0ludGVycG9sYXRlIGZhbHNl L0ZpbHRlci9GbGF0ZURlY29kZS9MZW5ndGggMzc3Pj4NCnN0cmVhbQ0KeJzt10tLAlEUwHHnjnN1 Ho1TIoMv1EBpIrIsoUAle2AUKhRBSQQhuiksonRjSIsKFxnaS4LCwLIHaR+xgb7CWUSd3wf4c+5d nWMwIIQQQgih/4MhhGUJYRjAopHygsCbOBYqyhAqDdhdbodNNhuBooTKTi0ciU6Neq08zKSMUXKO JTayua309KBCCUSTUKuWyJXPqyeFlQmHADIo4e3hTPnqsdU8zcd9fRA/yrCiO5avtt4/2vX9pYAF qOmd3b187vZeb46SmsKBNCXfXKHe6X293ZXSw/1Qzfm9BjaxiU1sYhOb2PxbTa++M7zozdtiCqop euI7tfZnt3N9mBwC2m0EVyR79tB5faoVFv0gO5iBmNXQWvGied+obMc8Esj+yVDFP7N5cFwp5ZaD Kg+yJ+uPV7Voaj2zujDuliG+U0c40eYbCU0GAw6LicA0GcLxslVVbYpIwQ4k/fkcNZv1kwtoyp+o fhyCnoYIIYQQQgghhH6Rb+2Tx9ENCmVuZHN0cmVhbQ0KZW5kb2JqDQo0NiAwIG9iag0KPDwvVHlw ZS9YT2JqZWN0L1N1YnR5cGUvSW1hZ2UvV2lkdGggODcvSGVpZ2h0IDExNi9Db2xvclNwYWNlL0Rl dmljZVJHQi9CaXRzUGVyQ29tcG9uZW50IDgvSW50ZXJwb2xhdGUgZmFsc2UvU01hc2sgNDcgMCBS L0ZpbHRlci9GbGF0ZURlY29kZS9MZW5ndGggNTI+Pg0Kc3RyZWFtDQp4nO3BMQEAAADCoPVPbQo/ oAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAeBl2RAABDQplbmRzdHJlYW0NCmVuZG9iag0K NDcgMCBvYmoNCjw8L1R5cGUvWE9iamVjdC9TdWJ0eXBlL0ltYWdlL1dpZHRoIDg3L0hlaWdodCAx MTYvQ29sb3JTcGFjZS9EZXZpY2VHcmF5L01hdHRlWyAwIDAgMF0gL0JpdHNQZXJDb21wb25lbnQg OC9JbnRlcnBvbGF0ZSBmYWxzZS9GaWx0ZXIvRmxhdGVEZWNvZGUvTGVuZ3RoIDU2Nj4+DQpzdHJl YW0NCnic7df/TxJxHMdxP5/jjrsDORAM8UAT5pdsNdJoDYG+sCKd2SgZm7XVMJKGrdj80tS2Wg7J /DLmEFwDkol8E+78D0PrP7jPL23vxx/w3O3Gjde7owMAAAAAAAAiEMYURWGEyEZVao7X8CxNEewi zGiNFlufeEXgVOS6mNGJo3e899xOu4kj9rxIpel1BuaiC2+CEw4DgwllMdM18ji6kfr5/dPs7V6e 1ONi1jweXjsoHh8l3z20d5J6uxQvTkSShVrjJJ2YGhaIZTU238JOqSlVM8tPr+lpYtm++7Hdk5Zc y64+GzWQzL7fgyxkIQtZyP6HWYQQprX9D8hm2yuJUfN6uz++XyaXRZS6s6vbbL0++TF9Ksm1w5UZ An+RiGINtpGbznFf+PNhVZKrmaXpYeVZzAhXXU+eh0KvPiTzdVmuHCQmB3WKdwLF9ThnYivra1+2 suXWuVTeX/QPKF41iNL2+yJf09lcLl8+k+Wz36l5j03xBkMqnePR4k6xUqvVm/K5VM1thMfMrNLF +De7W2q0JEmWpXpxOx4YUv77unwJ85u/ThvNZrNRKewth1yiRvkOxZz5VjCRyhZKpeN8JrU053Xo CaxmRAsD7tn4+uaP7a1vq7EXnkETS2A0tz8Ho90VCL1+G428DPrH7EYyF8nFZyYOOe96vG7XDYdF YAlNZkQxGn23xWoVe0wCz5C7cjBFty89nmPVdPuIJFS9CF/epRgTPkwBAAAAAAAAAIB//gA/heRp DQplbmRzdHJlYW0NCmVuZG9iag0KNDggMCBvYmoNCjw8L1R5cGUvWE9iamVjdC9TdWJ0eXBlL0lt YWdlL1dpZHRoIDUwMi9IZWlnaHQgMTE2L0NvbG9yU3BhY2UvRGV2aWNlUkdCL0JpdHNQZXJDb21w b25lbnQgOC9JbnRlcnBvbGF0ZSBmYWxzZS9TTWFzayA0OSAwIFIvRmlsdGVyL0ZsYXRlRGVjb2Rl L0xlbmd0aCAxOTI+Pg0Kc3RyZWFtDQp4nO3BgQAAAADDoPlT3+AEVQEAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADwDKqGAAENCmVuZHN0cmVhbQ0K ZW5kb2JqDQo0OSAwIG9iag0KPDwvVHlwZS9YT2JqZWN0L1N1YnR5cGUvSW1hZ2UvV2lkdGggNTAy L0hlaWdodCAxMTYvQ29sb3JTcGFjZS9EZXZpY2VHcmF5L01hdHRlWyAwIDAgMF0gL0JpdHNQZXJD b21wb25lbnQgOC9JbnRlcnBvbGF0ZSBmYWxzZS9GaWx0ZXIvRmxhdGVEZWNvZGUvTGVuZ3RoIDc5 Pj4NCnN0cmVhbQ0KeJztwQENAAAAwqD3T20ON6AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHg043gAAQ0KZW5kc3RyZWFtDQplbmRvYmoNCjUw IDAgb2JqDQo8PC9UeXBlL1hPYmplY3QvU3VidHlwZS9JbWFnZS9XaWR0aCA5Ny9IZWlnaHQgMTE2 L0NvbG9yU3BhY2UvRGV2aWNlUkdCL0JpdHNQZXJDb21wb25lbnQgOC9JbnRlcnBvbGF0ZSBmYWxz ZS9TTWFzayA1MSAwIFIvRmlsdGVyL0ZsYXRlRGVjb2RlL0xlbmd0aCA1NT4+DQpzdHJlYW0NCnic 7cEBDQAAAMKg909tDwcUAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAB8GoPcAAENCmVu ZHN0cmVhbQ0KZW5kb2JqDQo1MSAwIG9iag0KPDwvVHlwZS9YT2JqZWN0L1N1YnR5cGUvSW1hZ2Uv V2lkdGggOTcvSGVpZ2h0IDExNi9Db2xvclNwYWNlL0RldmljZUdyYXkvTWF0dGVbIDAgMCAwXSAv Qml0c1BlckNvbXBvbmVudCA4L0ludGVycG9sYXRlIGZhbHNlL0ZpbHRlci9GbGF0ZURlY29kZS9M ZW5ndGggMTAzND4+DQpzdHJlYW0NCnic7ZjvUxpHGMe9O7g75JcKigIxQRM0qEXtBBKp0dYYxUmq dNSmEbQTo2loGhm1howhAWM0FscGghoDBIUgHD/uAP/BHs5EwPYd2850Zj/v9s1+Zu95dve7V1EB gUAgEAgEAoFA/ksQBGVBkJJhYVz29CgHJ3k8EuegyOn0GJcgeSTBxVAgCgTF+dV1DQ11NQIcQ9gh lyeW1jfU11ZVcoEYUFwsb+nS6bpbFGIcZXUCWXPHNf017WWZgAtAgHCFys7BCYtl8naXUsjFcKG8 o980NTNl6tPIKrHyDSgpbTfO2dfWns8Z26QkLpBrjQ9+d66/WjLfbBKXvwQE4ytvWBzegN/rMOsV QoGsfXje6fUHP2wt3NFIcAACoWrAun1IxQ//+KVfJalrHZh17kUo6sizPNoGQsARNQ/ZvMd0Ovru t8EWpbrX8sL3OUUnQu5fh9RVAD4RR3zFuOiLZ5iY12bUanomV96FU0w66lv9Sa/kl1/kvGBkaTcv eL80Zuj9weYOJRg6drD2cEBdQ6Dlzl8kiO/a798Zf7IZoGg6HtiwjrQD6dIzQYY6cFlnn64fxGg6 8cm9MNotF3BA7LMzQTK07Vjd2I+m6eTRzvKErlHELf8DFQmydPSjx3PANlAq4n1+36CqwoGcRGeC XCYZPQrH8g2093Km/0oNCaAAJYJcJp1M0acNNDd4tZYHZv6C4OQkl2VhqOCmdaSjvhJEgc8JTnK5 XDYV3lk0dSuAHNR/E7AKtlmd09+o2IsB0PznBcyxb8WklYEqwD8IYv+yIEN9dFp6LoqAleC8IJsO 79i+14JropI2zXcRQwXezA+2SgFts2JBLpthGPbEON5zTPc2VYHqo8JOztKJOJViMqmIZ2VCd0EI qAwFAUMdBYKRJMMkQ+6nd4GVoXCapsO7bvdumDVQ/nVwZSjcB4nAW/uyyxdJM0DLUHSj7b+ct1hd +8c00DIU38nP7hlN1jcBqlAGkHcymyoWR28YTAvbh1/K0CIBmiryueirqz0/PvN+TmfyZTAbQBwZ rODyl+C1cJtNdn0/v/oQo5lU+M/F0Y5asuwllETHgWapTDP0eOM0GvnXZnoulB/t2PB76bvHbjb8 hrYe9V0UieRdYzZ3MJaIBTcffasSlr3bEKxScd3s8Pr9nhdTOjmfEDVen1za2g8G3jsf3LxUvqAC JaRtww/tLpd9dkgjIThEdbNh4snq69er1rHuBgCNinAECu2tcbN5/JZWIeCgGClp0g1PWqbvjehV QDYziovk6k6drlMtF7FhDsHIamVrl07/taaxBsjVefaMreafhkUEIwT5sUwiJACFO/YhThQe4ucf 5kAUpb8SgP9LgEAgEAgEAoFAIBAIBPI/4S8B953GDQplbmRzdHJlYW0NCmVuZG9iag0KNTIgMCBv YmoNCjw8L1R5cGUvUGFnZS9QYXJlbnQgMiAwIFIvUmVzb3VyY2VzPDwvRm9udDw8L0YxIDUgMCBS L0YyIDM4IDAgUj4+L0V4dEdTdGF0ZTw8L0dTNyA3IDAgUj4+L1hPYmplY3Q8PC9JbWFnZTE0IDE0 IDAgUi9JbWFnZTEyIDEyIDAgUi9JbWFnZTE2IDE2IDAgUi9JbWFnZTE4IDE4IDAgUi9JbWFnZTIw IDIwIDAgUi9JbWFnZTIyIDIyIDAgUi9JbWFnZTI0IDI0IDAgUi9JbWFnZTU0IDU0IDAgUi9JbWFn ZTMwIDMwIDAgUi9JbWFnZTMyIDMyIDAgUi9JbWFnZTM0IDM0IDAgUi9JbWFnZTM2IDM2IDAgUi9J bWFnZTU2IDU2IDAgUi9JbWFnZTQyIDQyIDAgUi9JbWFnZTQ0IDQ0IDAgUi9JbWFnZTQ2IDQ2IDAg Ui9JbWFnZTQ4IDQ4IDAgUi9JbWFnZTUwIDUwIDAgUj4+L1Byb2NTZXRbL1BERi9UZXh0L0ltYWdl Qi9JbWFnZUMvSW1hZ2VJXSA+Pi9NZWRpYUJveFsgMCAwIDcyMCA1NDBdIC9Db250ZW50cyA1MyAw IFIvR3JvdXA8PC9UeXBlL0dyb3VwL1MvVHJhbnNwYXJlbmN5L0NTL0RldmljZVJHQj4+L1RhYnMv Uy9TdHJ1Y3RQYXJlbnRzIDI+Pg0KZW5kb2JqDQo1MyAwIG9iag0KPDwvRmlsdGVyL0ZsYXRlRGVj b2RlL0xlbmd0aCA5MzYwPj4NCnN0cmVhbQ0KeJztfV2TZDdy3Tsj+B/qcVoWi/j+cCgUIS3ljXVo Q/IuFXpg+IEekVzKPUObuxEK+dcb55wE7q3uWzU97bHW8tZLd50EbiKRSCRwgQTu6cu/P/3FX3z5 61/86quT+/Jvv33/w+nNd++/+IffPvzlX57++qtfnP7n55+5kzs753wIrp5qcKec3Onn7z7/7B// 7PT+88/86YeVx7niXbrI9P2fff7Zf/n8s9Pf/PoXp9OuNH9U2l9//flnX/4nf0rp7Eo6ff092A/e J38KKZ9rOqXczrmfvn6HMkfBX/7yt/X0w++Bfvn5Z9+8+avTVw/ev/mrh/7ml6fvH4J789PP737/ 8F9PX//nzz/7m68PBAnXBJklp5rO4aLkb96cbnGMxsSdS6Z2Yj/HGk+x5HOJpz7+hnIq/txqXjoK 5xZaOv3LqMk5hPHsyD3+5uRPvxk1G3L88+mDjH57IE263awHTaZ2Df1cC1WQRgHtBC20U2wR4O3Q wpe/evftD9/5dPrqp9NRC+dXFhzzOe3KLaPOZVQ5oPhdueFaueWoXLZDy+cwbCi2fm799G5HKMPe To+DUM51tNmOUM8+9UkYKPVI5AFqEwintyNrO7sqHE8DRJ8JElF2jah4y1tdIKE2JLckMTpRj3i0 whCQuZ9dECHlE1D1ROPfDo1HLTMJzQruhsi41sDq+ylFpsT9nAKSQ+xEo++BfSUY/95SESWY7gIV kZsQ8y69FsvsmliNFhzVaqlOtQ+UU5toZP7dyJ/OETXsfmibDTP0MkQygtrBhT4JKLA0obiEAfJT 1mSZkdrEabQA1FQNVVNB8iC4c+9sCP5uFZr1sRJVb5pNqGVHr0RyzYUoRqDeMpFjM4wfwUu1w0aQ CckDjUcHSl3aUQMPQmHmBpUAWZvluEej4pZ5tn9hsu+yjQCUfSXyk3PysqzmkRxKIcoZaNnrtLNW zdbbiWaAdspsQ3ieTrS04Z0I0MaQ3FUigkTGmV2WSi7Fi8CsUcDTPtmH0miXyZbGn2hYQ0O0wnQu HSixyHTOU2D4RxAiMxfWLtFEuvXOeO5T4E44DAdVp54iOslAPiYiU/GwmwyCg5t9JCHACQ0CtDwQ rXuoswJFWNBAvtvT0TJ7ptL2R4lpodphbZZ3EjKTYxMiCJ6g1ZnXRREihRgjBBGBE5vaZg2SOMFI hrVDM0A0v17EeLSSjKRlsaq0oQqTAaLJZDgFIWUeBrJLDiXsHvUm0+LsSpsFowW6n0IBRXu0L/NT wY2OrQU92uj0ai+mGeWtRXm72loa5092Jbd18FLQAGH0V3qS0a2SWhseHf2/EEVaLgZhoNztaZ+D Rr1M79FlYYM5HAv71hgY83Q7qNEgJHklb9ZKx+Or0or6xPD1QbwqXWRRNxhNiwGl5Yne7oYpEh43 guzoCWHIOZC1cCeIaWdHILg27QjdsNSl9YG83zdKPrtcVpsljDIEGaC1uGttVqVMY0BNpzF4oOzb zo7QZ2vYJYe8e9LnJ4xdrqvc0aNrXyINFC4kHk1lJokKDTR7UQSqve51MQhTb0y1J3u+QJMxCegS gUrfCBKrBRtJWG7XADYrgPZFR+ys3zaUXQx9Gg6/x3TQYQL4L5iGjunffepyn7rcpy73qct96nKf utynLvepy/+zU5ejFaj6qVagOpz785WgqytQ7ajg4RgHl1HvMfYNhzAG259/GLMsDCXtFAJ6xqnU c/7IBboPcDjSS3+lXnyu6ImbYoYDxRpZSGWvlnJNLf4DK71XCx71yeWiXI+hLoThNfYlt6slH676 cm0u+FGpUYcc4KDebYQUoe5HEMaQ6p8Qhgs1QggOUwOgMUaHMOxVKLELgGDJw2cAdTEf/SWEMOa9 ISWbTQAXESoTUdc0/AtQFN9sHRwElJ4wdQaI/N3rAhUDiOUEbmyr+RhmzOI6nkhjmlCmBD2QMHow 5RkiZIdZNKUtRC3NzGN0DdlLD35Md4mykBeaUriZDAVAhW1qnRqeQP05+AInF3KEbt5ZK7RJeBTD MZcwAssj0O8q5n0JmtTGpavSkYgPsqUgV1vqQtsMAvWVoLxR59oJxiQHSLNmEKrpLzJ5THKg21I2 NPrlzEtcMLleT2aqA4y11xDCzBwKLSFJYj7KNXBKLHtctUNbpgAvylYSgtmhUYSin81gmaH4gRwY e1Z5qBhtJvR2awQRHkXIdctfaBfDaeOnler6fJSdJpxHtwTyWWKkPcp1ZgZhtMgo7vGC0JU/qHH9 KglglQQp0PQqKW9WcWFFV19y7z7g7gPuPuBPyAcczYr84YbsK6aLIVZMyZ/NTq5OF308ni+GUW+s XGC6V0cRnC/2ysbUlIj7stDiy2eLN54/1MrhNq72y8NpNOvFXvmYD6KLcBKKDWvOsLx2yH/zEN/8 +Y+39q/94c7tfks8hEKftAr4wI64Lzcn37EMm6gnzGvz4dz7WIc3HztU4mvfRJ7NuPnmnAbDzHfi l0y6D19GXlB2bk+L5nqMz4nrdavo8eC1og9fNCwyYbwk+yFcxL/BKzmsKE3CoxHqJAAF5tfPPH4G W/8ioYmQmRyDkJ6LyqxlVhKUuSk5ESDEA8ATlTzzpkhCLFMmIwSVlFSSz/un3RILvD0sdhXrMbQu qby9Uy+hPcaFVSGP3rTq6+FmZn29CJKaevKYFCw1epsiQNFjcDHC40aoFRohAS/yT3CaBKImpEq6 IBSnLGNKQoLU6cRrjGuURZnryuyVeVjWFBxIdfYqJ6eVWbzGsM06E8Q9CCursDdGes7FjW2x4WyV WqD6JVGZ4lPgstM068MRZNW1YBa3VFGw9P/W9KaiuMJhWhzoNFWM37s2Id43Cc3hCQGsMoQHqk0o CuXFTdgztenJorxNYBVckwiJqaUKqZRsyM/MSU/nzuQoxlmMwwSW1+1Sk+puT3Jdes84LSkCk6cU SchfiJwwh1kV4hxpVTZNCacqEoxlaSphUrC0uKG6Mss1xC6tL4LJldWfjVdRz9+eruaFiurYprO6 dG5X3zruPvDuA+8+8O4D/2R84NHUOLx2TfjpW1fy8XB6ev21KxwuCh+/KYwX+Dycls8dhbxmmf42 h0PVvPaF9NlbQ2lYjpnO4gUvDeHwjfQlLw397PetUtgaPmc6iO2d4WoQbTh83+Q7Q23cSvSNveGd 9sPgBkR4JCGliQFaEOKeUTYQbHsp50ZC4vZSbl2IW3bFi2+yvCWq4Ei+Bb2xMS65qecCzG2r0iQD wiywCa9i3Q6t/fWN0Lihp0ejbe8VDf1lbuip2IgX9yVSNPGLTRzSlFj1iejXq67R5M8qM07G0hPX LqcKsVy49AswcnLnuBh+3LA2Hefu3iVGiIMRgFIX0i4j3MVAZe4VYneXBO1RZkvmo53+s5uzhUK9 F4GCukiQKkFSUuxrK1TJypolRPB7tDYdiRtDW+aD7dw3tg2e1PIqURu7kocvzUvcZuPiqg1D+VdN G5tyKqLZqL/0xF67dNjgiqeGCXZNIsK+TdiO1idyuiRkeGYR2DssOaofBKFpdIJRpm6cYpK1RqIw 1Vy9Mgcmw4MCeT5aOfCkpWdEAgE7bl5XFgO97NFs6onZuHowYohcbCOswPKy1MiwrylRnOI3pcWt RyUSrCMrr6SXHuKMJ5tq4orjUmG0yiXj4ynxdFQiPJLQjPkgwGKilRuBihfS8uQgpC7CsDcgyzxm Jjs0SyLm1rmVJELCDG+yQkfeSoK8s6RqmTNLopDynpfO9uo7zN0n333y3SffffLdJ/+RfPLhi8Nr T8A9fafqFZ3h2ez9xivV4Rm4452sjAjuUbcesMLz8TtZt54/1MrhJsx+d6kg8nvUtzfs3338/lU4 3GrZl4DYyMsSPrCBFfrt6LEesYxQsRxSPmIH6/ZzR9qLr31Pfx405hnP2ROOALzgXTQevqa/LGrs MlitwZXVcN5Hq4WrthwPX78VMxYaVx8dl3PeiTC6iBHC6EdYJBsI29CBgQFAMxqEYZYkjMxRy2/O c0t7oCRGFgQwCFUEbMtHxtwDOTzqucznnB0LACGKgLiCgTBUOseok0jZgPLKPNqBhMBklsPVXaJK JL9MgjgHJTfxQuSAULc44w3WZokApUvgwQXIlcWWyTlYcgHCXr4E6pgx5JU3kBDFt5BV6IYyUV2M CzOHLHkziwlJxeQ0kWUek5RdchSvXqeOIZNOKYDgyDn7zgZR9ZJaB8cPcP6jzsYLZNXReKPdMbOE 1iJRlsJ9nmZBQ3CM+hgWZQ3gCfxCzFvnw9F2xdWSgSBRJO0MhJCRCKEg4kBZKg6ZKLAuLqxYljY0 gVGpMoJhmMxA3qJgEMlfbbrH8JQE7ILiXob0vZxTWCCP5uwzrwjOYmSgFkxlm/gONIbPWGbmQkKo yjwmvPTyTRJ3oOTDrB4yB573QeUdzxfUKFVkomxWPNTmis4MJEbMFh43CESjT0/wVl06530qzxfg bAVaKohN8bPpCs8XJIQYoZ2ZnIcB0wYkkt4DJiEzQPtRUulU/Y6QFwFocB3IO0MeKLg66xSZHF1h 8hAXy9YItFqo1KUAEWpLu+TGwKZKu8+cFu84D5VGFTxmbAN5F5YYhbH+lnnUbxACPBNQJbLQZJpG KHvr7YrZJyJj9jdThpD1t5An4dGcnF/5gdrihZ6c9kWhry85IoNeKKOcAlwEqrD5jKoayqVUFuN2 3gh7EptDZCu2Zp6rSa91h0rzezeHkytt1kEEj8gv83uel08Q8cRJXiUVHj1qO+eFUUF1iMxc8vJO OtNUNZh0ntxJTQONjp/EtoaWRFahyXl5Ho7yXSbe+KgPdZp45kErnG0A4iEg55KGO54+6aXNrqNz dh1D2kA4KgcnKL+mo0ZAZgyhbMmFhoNi5K0qpYghzd7uKEXu8k9UTKcZ8d0PfdAGwxCtA3eLchzz /OEnMmPtGC4HF9Mtc7BJiaNvZuActjcYayeU+bJvmTOtKmfFaGIkqpqABm6GwGfO/sm3l94UsR5t WEpF8eteA2ddbtLGaEb8cYNJozvduKYBpuOC9uAkwrp92eYf++nJ1bWb+yzmPou5z2Lus5j7LOY+ i7nPYu6zmH8Hs5jDlanXxio8i9tPcOxPF4iuL3bGw1CFa5HmDpfL9WHIrwkeufH4oUpeuwB8EG/u GMYRXxo5Eg9XgF8SOZIRKbIruRb06+Qv157z9eY4XN9VtDnPvp/q0KjjJSYRpyDqJDyKMKZlRiBi /oSz2x2ndwCqBblV9AIQcO8JEFklHKIfqAPEMrN2so24awCID8KPE2Ugn+PKXHHvXMtLKBFqsvwF qFix4+mBsiYnxnwQUrOiAlGwzLzQrvpVAzKOltr4JI/Qs7YAZeWtLHYKXck34CS+1GjorYWPLcLj IuROi74keAtPK0C8s6Jz+wtImyEkeBKckiMf9VUhdZFpfsbfcT4GQhTnUUDmaSYAJ+AsSA67gSA4 3K6AWRulcDicj7XxMJFlzm2fLJHno7E84RzKKjdOIShSBHEvMe9TWBWKmJKvysYLRTDQd+mJ3nnp cKGSV+aybwSZ/xOCX62IW0DqauHGWeDOAEBY1oH7Q8qyHF3OsjMsEDazA1oWiatI2t5geTnMsufG 44fT1hdqectMQjdW7HK8KUOMd/2Ixc5eJolmD5TAW/9UdWbnZU1nv5Yedt1eappOQSqcDuPCwVx9 4777obsfuvuhux/6N/VDhxPE1x4KfBZ17TL67NNZ2o1J8+GZwCu724VxPDFeO575wcOutxgc6SV9 sl1u33gvT8wvPqiZXr3PzbP4+6LpvmJ8Egkfrx7UTDe2ul2As4s4L8w1Yh3xQb10r1Jwifck7wi7 Jx51kH+QcLNPoZ95JwJuWxIBqJY9wvy/8LIDvCQ6nSgoDPAH8oaiEDPPnEF3NmOVzTF8hygLWdrM mwhbYWKKQgLKadcWOFzWN6oYsH75KAI447KCrFtwBivcapD2SKetSMgkVLsyJwoFItzYlb1dcUWC kot4eT1adLraGVLeggKBh3MCgvfeEBQsZJlT3CdbuYZ8u2QMJzWLzVitJwpCS0BmxsKbCIXJzZK7 kKSwlTvHpRASlBntnrnUThQvFJeUnOxKuaA1543gO2IE+USf2Ik9Qv16n/rCoj9QnEW/ZebZDIjH 6XlKTTQrxIxc9SAhKnanTOUAlbKpDjiXqVgg2P2GQtm1CQiub8l1CmFoFuqVmXd5WDPwGL+Vm4X8 lN8y5zoVT7RTxEI6xuMV5kX7FS+cX5Jt23UBNH0zUK5NsnPoOgjHbQd2Hc+bmfLWq7h1wy7n58O5 bj2SCl29FQuGqyPr9NLs5BR1OQDPG9V2/iGcL3wJ7tzc0OZ4ru+E3Z3c3cndndzdyf1/4+QOJ7ef bKHc4/3k2fzy+qQ/XVkpP7zgprnTeIvj3ZYff7vNtYcP9XH1uhldbTPegi8/BeM7d7kjzlH6g/jg 9IH44HS4Nn5xv43rdKNbCR+ID0719rYDxAXP422HK5sN1x86VONr3yWfbzZE3pscsXn6slem195k WXjIfV+y4xFmty83Xj2kmg9fE7XVgKu9BidsHvIquUWgn8eiR+rop5eENDFAJWj83ZWzaaEms8VA wPJD5s5n1G4iUBHS1bpRd7SBwLkMY26AzIl6gmZ5PQwuIvBAvhpTgYFi3SNbMJmEOscaPmqzBV4o HsOMr4hZiG7eBGqsf+ZN0UAhTnnhxrDRKnm99IhrpROvNAaS7wQhixfeshODTkzpEXev1YnkD2cr xIgRZd8sXMlhKzQOCRcEaFkEFIHL1CNvPGDxkcgveVB0ZGQRG04oqp28MuswEZtRRldV0yQLNIAn vcXTgICBTAECRI0Ix/M3pMnEIgTsThMlotg3zmFeQTAIoA8CJzOM54CCnDijGeM8PsMaZRKi6odZ TOSRHtqvHs1LGUFPw9ZS26keKMWJZuNkLBJjQNE3BtgWfhKsi+D+XxFYvBY4msnaiKZ9OpY7CFl2 xrZIUqDn9CSm2XDZS7+8Vo+zB6uKEOWaJ444XyhSmU2VpV/MpDfk/MxMgteUJkij2NnXxENpIU0x uvkhdUDzSrXO2Rztp8zMRQZlc+4kY/Oa4Mi2Zk506NBXB5RF163/9fOyHUy0FdBFNkqdE2oChVFM NQWtLmf12q6XBYHSpg7QmdGnpYOsjumlsNKmc7DMwmj7HNQ/68xLVKxL7whJxbad+wp0Cgq7sMys ap66z/KTKiam6VFnqzV5Y1W8C2U5NywnBh62m8YjfzxVr2RnDhcSxp3zpluKmlpz7ReoqDHgS0Oc ndOGgTi9H3wrkPWnPtHbrfuI8ChC7Vv+zI4XeEgViI4z2gU/ICQ9DTNNeYrVN7A6ixFG7wl1lmSE fJqc0BG3gmKaF5OYHJFXoUwZZ4/ee4Dr+2f3wfU+uN4H1/vgeh9c74PrfXD9Pxhcj17k82s3IJ+u D+EzsenJy/SNz7Uebj5euYYr8wO0obrX3cF1/fFDhbx2wQw3ou13ZFMtPJ2Cb+Xst8njdaW89uu5 kR+Q2hetNfhSLnfo49VFlXy4LMbFjdR1CTyDiHljJSK42yQkfjyMIBAkITlWECAJCCOVnhwgBSJc 447wf92SiAjnSMJwlEBVyV6ZO5FychQNunwOCEcmGPNMlARm1qSslC+qCA5kRFkozMxZmZM4FYEo 4IniYlzEKopxUbG4ILPTFwD5LbN4+dMOuB2K2r3ZYdyBOTlFDMWrlHguFzJEVGCJyDkE69KFVt0q 8bBAInFS3bIeDJvSlNdqk1RKUObYJ7LMF6neUiWvUyk6roRmbH0TOJxVSpFxWJkaY2gferjLsrop TUZX1OR+2Vno0j9aToHnnddt0IDjRMjceJppJiu6h48KOTWks8xt6hh3sKI3S8oMxK8JAumbRCDg uwmdewhA5ExDB6KI3iwTn7qKxONhIOy48Zt3CymyxzIbwSkzHsVHucR3lNmqvXqw2ESCRIQ54cN2 JrBQKrN2OHzUOM6zrsMQGje3qIpIVMLUGzwBPl4nTXUlTyXXid7KS0DJM9mzjwJ1NV8hsv6spOLl FToR7niFS1Ca3RfbuaFKeZXZquNl094TheUmgpJjWYaLuqvbUd6yTDOqqJWc8wVqYrR1UhU1vMHs hkBpdVmIsWVWUcGSxcvboxLKtZlZauzqPwLm5gRqvsxZ8i4x1z1Y5ffVbLP8vERXS8TlAovaOJSt Zjxst2qdd24ti5ePy6c0BvVPxwu0/AS6YePE0LxGWx6cLZemuXd92QJ3AckKWIE0vQYO6rW0cyo+ kRBkW03JXghdEChMR6GS0I8wkgHwFztRmobOmiR2iVYnA3YXZpujgHV4Xvylfik03EJqRbaaV2ej gbBxE5OdbIiuhLM3dFq727dxDAWBmbO6XpNjMcSgQMuc5D0wyskMguoOBIWgY00pnLySSSEniwGR XyCV81vVCxoQs7ySAGvHHWCO1nkqzWn4RispRHFNEvZziKtLPfepxn2qcZ9q3Kca96nGfapxn2rc pxqfaqpxuM7z2jOrz05DNPmbp4stNxa/Dg+tHkdGlbodA2uvCI669fyhWq5eZ3jw6S8YH75KwY8+ Pw2NuhkVlQ+DeC5uTcQW3o71B2KiirsQ1T8VNdVAGw8F/gMMHWR1kvXr33338EX4QAn+tjKys4/0 rRK+efMVuP7q726yDbcFzzHoI4s7trfljAfazFFfi9wxefvg3Zuf3j/kN3948PnNtz++//1NtumI bec3TC74/sebXPLRFZyKZfyIKpYDLrOFXYKTA5fTF+jJ5fT122/e+PNNhvWIYe9PGTry+rtf/P1N Zu2wARwaYOP1oSr2QybYFbhg8v6/0XD/w01m1R0xq7ye6YLb//j253c3raD6o/bDpxfbR1Suhuvt xw+LPG+/cLP96pHNW/vtGar9fvPnD2UI+EUZPirqxx8e2pufbst8aP/agdkV8Q15vv8ntMp378fP P/w4etj3D1/UN/96k/1hx/DcQbxgf1vIo45RfOYHe54J+fuHbn3//dvvbrI96h5jnDrzavMXC3fU L2arF94h9rTV4+1WP+ojs9V3DNXqf4s6f/8Q8pvv4PPQLO9u1rod9hp8ITHs2X+g1u2ox+TCGdEF l5++P/0Bw1D8AL+jvgNDqZfsvn/86ad/+vEhvXn/w012Rz2nDNcwht2PqORR55hNGxna8LRp082m bUfdYTbtjqF16G/f//fT7376+cfRr//XQwhjWLst7lE3yTgckfbcP1Tpuk0av7A5o/ecLY6H58Tx UT+Z7gNOVz/us3POtk/SJHM0Z+YeqMeUMI7uyzD5ZNdeU7GYbw1rxJZ448F4nBPJnJ3GzsgfEIo2 vPFFAstRSMB9/kkEneJp/HwwCIk39YCpDgX9TlPNMZX9v1DTD0xgR9P886mdfv1HrPtvWfXnzd92 7wyqpEvjDeYlWpn58ekIpbTo/YeaH69MzYLY9N0NfWM5VlxGgC8KjBckLMfEur/v3u4F1FcJcCKl M0dhHFAt/LQCCLrBrbkZTBGetf2nr+atFv8jVfdac/fnvd3h4P4tRczqrgdiih/T3304KzhrWOc7 nY23VTFdaOHhqCPf3K0PVOo06OMY7APURcAnOVan4AqHHWL0rjHSD1+bb1d7+6er6Yv7+x+p7lea v8/JwJUYla6PH5bCm7NefOzm9nNHL+j9tQE7T+NTstfhOK2hvSQ+pb/223SxXF5WkL3CAAvX7Xb3 fF2NT+mHUTlcbsiImvUcGBLdRLYINxGAgi4qwfUuugoyamHvrTInI3gmI3axM8Az65ZNojozF12B EsW5WnIQSkRaiyVBYgTLrEeD3yNtKkxCY4nDEvHaj/DQZwQ9ckkIWiboW2mRJw93wsQ4lQRZI08Y znpEnTveqglCWVqIvAduasjiVTcFRh0wNv3GOBWYxLlOYHlb2qeayHwyMRJ0xzitZtSrb4ibTFyA 3YvMT0KtGiUG4s7acvl2rwzdlTF1xUtclx4XspYxQmMo4uMl4TRZDTCyz5KA4hKrk+AkddSTrqw6 AKWZGVVsvKV3Vr/5pZrGUFbTYzdCPU2tbqhOYHnRIlsqWmtDMT5hHJIVGq18SSMb2QkrE5p1kXnN esr6dmqQcU4tmWlLgRvIKy8I3NN43HWNZ4TVIjvCaXY7K8t65SaKdVqT1Dq01cL6+1ZJcwemA3MV zS83sinOvIzp1TzQhqic1SSB3+BdyYUxsBsq+YJzMRmYJgEkjiJ1d9Jy82lVpjDEdVa0TGObeiiM Tp9qKgziNg1uIK+8Ze96NkKQWKFujq7MrhlWBSDIdJMScrpQ1WHnYct0x1FST2/il2p2vluam65d Wt3c/jYqXI04uA8e98HjPnjcB4/74HEfPG4PHofvYq8N2H+6h5xD5PUuT1+Iru8h98OA/eOX04zQ gFqg/9ccoLjx+KFSXrux7kO8vKAhd74VM3hqf6wkXb2joR/urL/kDdXBde2LTgjIqwwB2pV8vT0O 9835glpcp6U5XlnzToQ+MZbucT7QMXoRyBtixAkIOFXleAEOkR7FpZlex9Wct1AHEJJlFudkyQKV INeZV4lZWbMeTP0CLb6M2uNHQh4vCLhWk6wI0iyIaNXAAkaiZE56MqZZA6KwqttFOFndAUKfqiFa NXBGGBWkUgnyyVRu6K1UXvw+OfX9k7HvGbs+hUC5rk8pIgHu+t8EBmFVx3XFu6iqzqJUliZcV1Cq FOX6UqD91GFPINP94w5JEudXmzkG6O1aVKVbe0OuzRSA6t5SUKm4DAka2IwM2vF7G3TdTAUWCk2G Zb0Xtn11mn3vAvcu8KfUBQ7HxdfeW/RsstDVAE8Hp+uTBe8O7y46ni3g28h8kxiTgfSqCcNtDke6 8e5TrWrbZduINHzJkrZ3r17T5m1xu4Ix+8Vp2/104ep6tnfXF7S943ntEvlFnnciDA0bAWi8sBB5 oiakK++crm0fGN85dw0vWiXqA2ntLLbesvLUOPdElBoIioFIpHk4CWSUZ14WkrEfvyHdsGCEjEje OvdZQEgMazTmGbO6IKnwBj/e+pZYfCsc3iqwfh1vesMPRdWdyE25KkJAcT4dcTiOH+TBcXRy5i2S PDBvmXl1JE7U18zkIITPx+uORkPMzKDYXTJZBV8IglBaeWF1g4BbFh0/+4Vz8C4RMQnfT2JeHuYG gV9Uw/fMKWPUk0mo9Zk5kpAtOZBXZsvrynncPlFmZlWoZHH2nYhGw/MhPMcfZmbPp2u2ZIpcu8rx ZNTSEkPYUvlSON7KJQWqjusM08wrAr4iRFSJ8BHzhbDDOTOTkOKeV45tlQMbjDsphv26tmSE3Wch GlELeeWlEbWZTFbd9EYb6ostV3LOPVuqslrtYppoNshFctKj1jyZjFtfQmRmbsa5sHaNBsUjRJB/ 5W3EpUNt5FpSp7GpasXlaWyBOssUgaH21JkyFz+RZW5+n9ylYHbywk8CRH6N3vpHUM+z5GgSFqJU VTk/M2f2aReUPJ7JsED1vNERMqx59bzKLl+aMg8/kPFto7wQDgmUlblMf/J4QTBJ5P/king57N5T FdS4bJVoefNxBRawd4FlestE72HOkq6TN9ReOFaMZpvbjWXvkjePfXUWfHfsd8d+d+x3x3537P+e Hfvx+8unWgnuhZsdl+8Rt97sPmYd2DfrEC6+cin4Jodjzbx6Obg9+cTJMHR0/crruHYvWe26cl69 HMyPQu6LtmPal991yVc/rjLGuusBS4kLMbWdGccKiM/3AOL3KG78zhhoEPkopHPKGZdaVRLKSM68 mRoI34TKXCkCso0X3T8HApxO5veWB0q1CkUi2w3R5VkgOEvmo7GUPdJwOwk48qo9tEznaTmMkMgf 32YiIoOEkSnTmwLpti0SVDY+hJV5fB5iY+DKvIMOSKMQCFWVzuKFr6FBQyqns9TcrFY8EUp1Dh82 kPRV+DtaG1jGVLakvLWBvuWzb4MMx7HaIE8BkkqQsMHPvF01w+5c5klbIAwXmWcygXSKmQTprFty UhPswWyBScA3urYnfSm7YlxfQrDazktEWNiYfGEMtspg4mnqDRftyvObo5+30iZB20DVS6zhJUrl hI5Iyz25TCExfawWfbnhiCEjc0wCwpfU1sOhL22Id2A78zsOQJifZY5vQM4vdZCzr0vPQPhyWuYx FaAUVwOKEKSBUoS82n4Cyxv6PnXYZOGJeJgfmbZplk0SFJllFWJTJn7wrDJa2TIXq6ysNrOMSBNK Z3FOLl52Ntesb2lpVTkuCJh2W08GCmF2dBTV0mJnwpjT4KPB1+lCKHaZmb2qWZXZtAy9yjnt9Crf NfUqrzY1J5e3U6xuuNwlx7x/NOQnnE0MK3g2tjymu5A58VjArBLQVl1d9LfTRmrWbFSW7tWcilxo toQIOy+3EYoxr8uFqqidh5Uk0wFLyumcVYmd71Ydp2tX/afLkXp2Hkna2w0acrbltB9prr6V3oej +3B0H47uw9F9OLoPR//Ww9HxG+Mn2yhNjG18+tZ2+Tb9vwF1LaZyDQplbmRzdHJlYW0NCmVuZG9i ag0KNTQgMCBvYmoNCjw8L1R5cGUvWE9iamVjdC9TdWJ0eXBlL0ltYWdlL1dpZHRoIDE1My9IZWln aHQgMTE2L0NvbG9yU3BhY2UvRGV2aWNlUkdCL0JpdHNQZXJDb21wb25lbnQgOC9JbnRlcnBvbGF0 ZSBmYWxzZS9TTWFzayA1NSAwIFIvRmlsdGVyL0ZsYXRlRGVjb2RlL0xlbmd0aCA3ND4+DQpzdHJl YW0NCnic7cExAQAAAMKg9U9tCj+gAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAA4GvP/AABDQplbmRzdHJlYW0NCmVuZG9iag0KNTUgMCBvYmoNCjw8L1R5 cGUvWE9iamVjdC9TdWJ0eXBlL0ltYWdlL1dpZHRoIDE1My9IZWlnaHQgMTE2L0NvbG9yU3BhY2Uv RGV2aWNlR3JheS9NYXR0ZVsgMCAwIDBdIC9CaXRzUGVyQ29tcG9uZW50IDgvSW50ZXJwb2xhdGUg ZmFsc2UvRmlsdGVyL0ZsYXRlRGVjb2RlL0xlbmd0aCA2NTA+Pg0Kc3RyZWFtDQp4nO3Z/U9SURzH ce8Tj4LoACEwZT5mY2mbVoDN0ljp1jJ1PYmbZmzONKdU060abZk6XUmaITM1xUAueKF/sMvV3ML6 4f507urz+okf3zvfs3PuvRQVAQAAAAAAAADA/4Si6L+gKKJdDKfWaHWnaLVqjqHJpdGs1mi2nXE4 CzgcdkuJjiNWRrE6s8vdcsXr9f3O62m9UF1ezNGEuhiNuc57+9HQ45FCwwM97Y3lOobMklGsodJz b/LN3PxCoffhUOBarUlFKExV1tg9vvBla+dbgZ3tjeXnvU1WDZlZ0mpLU9/M2t4Bz6fzMiLpB8+n 9qPhwCW7VgFhGSGbzeWyWeFQjCMcJo1yQhrlbjzBC7ncj5yQTsZ3xVHGxFE2kxolxRqrPPfFzb+w uLQS3U2JZQK/txFZXsxv/kGCmz9/XPjE42LkyejU27V4JpvLxNffhcaCI8OBu+3nbaSOi5MD1tfW 2TM6t5kSsvzX+fE+/1WfeMDWkDtgT64k59m6y/2z60lBOIi+euhtqHSKV5KJ4JX06xLXGyznuqZX E4dC8vOLO26bUU/6Ej9+7GE4Y7V/MvL9UEishrrrS1UM8cee4zqm2NX57Chsuqu2hFVAkwRhciFM LoTJhTC5ECYXwuRCmFwIk0vRYR0TK1LY1C1Fhemrrj/9EE9n9iOTN2uMCgrTVbQF57cSye2lsQ6X gdR77ikUrbW3PJj9GIt9ej3oceoVE1ZEq8oabgy9DIdngl1uC6FPKX9CsXq7u6N3INDvv1hh4BSz YOKScQZbbVNra3O9o0RN9A28AEVzOpPVZreW6lXK2WF5FC19xdCoWCWtl+TozxslfLEAAAAAAAAA AAAAAAD4p/wExSwnvA0KZW5kc3RyZWFtDQplbmRvYmoNCjU2IDAgb2JqDQo8PC9UeXBlL1hPYmpl Y3QvU3VidHlwZS9JbWFnZS9XaWR0aCAxMDIvSGVpZ2h0IDExNi9Db2xvclNwYWNlL0RldmljZVJH Qi9CaXRzUGVyQ29tcG9uZW50IDgvSW50ZXJwb2xhdGUgZmFsc2UvU01hc2sgNTcgMCBSL0ZpbHRl ci9GbGF0ZURlY29kZS9MZW5ndGggNTc+Pg0Kc3RyZWFtDQp4nO3BMQEAAADCoPVPbQ0PoAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAB4NIqoAAENCmVuZHN0cmVhbQ0KZW5kb2JqDQo1 NyAwIG9iag0KPDwvVHlwZS9YT2JqZWN0L1N1YnR5cGUvSW1hZ2UvV2lkdGggMTAyL0hlaWdodCAx MTYvQ29sb3JTcGFjZS9EZXZpY2VHcmF5L01hdHRlWyAwIDAgMF0gL0JpdHNQZXJDb21wb25lbnQg OC9JbnRlcnBvbGF0ZSBmYWxzZS9GaWx0ZXIvRmxhdGVEZWNvZGUvTGVuZ3RoIDk1NT4+DQpzdHJl YW0NCnic7ZjrUxNXFMC9+8pms5sAeRAkIQ0BKkYHeRipDaDysIm26lBeVXy0xIEWCAXHWkFgKIoB xZIEMIgGCeTBkn2Ef7CbRDrjdDqjM7sf1Pv7eGf2/O65d+fce+6RIxAIBAKBQCAQCOSLBwAEQVEE Ae8N5UbA/3/1sRIEV6kpSq3CDj2SgiApiiJxVC4NQFVaw1GrtURPE/mgkpYqNFuspaYCNYbIJCEL bScbm9yu4xadKhcT4LS5qv7b5rOnHEYNJks2ANfZXN/3+waue+otTDYmQNUm54Xun+/e6Wz+2kAi cmgQ0lRzZXg28PTRoNdpyCYDcG15y80/Hi/OT/SdtTFyJANQjdV9Z259K7o63X/mqFqaOSD0J66M P9/cerU44jlWSMhiYcrbh5e32b23S4MtZRpp/6Xs6nqnIwk2vvZnZ41BJcP+A0xb8d3voQTP7f49 cuErOmtRm139f71m+b2N6Z46IymLRVfpnVhNCnwiONpmz1tKztx6HN0X2M3ZvnqT3BY/tHykZazD ocVRBNOUfnP7iUKWZHjCW21kNBRdZG8eWNhSxCKk1h92NVaVWS1WR613+Nl2WhEL+/rJ0LW2Zre7 6fzl25PhOKeEReR2V+fGh3wDA75B/9RydE8QFbBkBDYWWXm2GAgsLr1YiyY5UQnLQUbYT+7GtiVi OwmWFzOKWA4yIs+lc3C8IGYOlLII/DuyEmUsGZFjU8mERDLFpgVlcsmI6Xj0ZTgUDAbD65s7LK/I vohcPBKYnBjz+/3jD+ZDb1lF/mRxPxoY7bvc0d7W4f3x7sx6glemwryc6nU7HeV2x7HTP4w+jylS YaRqee+Ss1jH0FqDo8X3VJlqySdCYx0VOgJDcdqiXOXPnWKMdFdGqc/grISWD7V4xsOSJb4y2npo cd2cfyNZXs301slk0ToujgXjXHrnxW/nbfl7svn0jbnNPS4VedRda5Tlnowy9tahpa1k4s2Cr8lK 5SzGU12TazupWOj+1RN6QhaLdPu6MbWyEVl+0NNgzi4PIIqqPcMLaxur84PtlQW4PF2SwXnxl/sz 0/dutVblmhWAMWWNXSNTsw9/vdZQqpGlgQUYXVrT2vlT39VzTjOV7/jIoorGSz3Xuz0uewEhS8cH EEJbUlnTUH/SUUzj+e4VU+ttx+saaquthaRMvbikoQqM5mKDTo2/mzfASEZfbDYV0Sr5Gn4ExVUk qcLRf58qAIIRJEkSmCzLdRgUIMj7zyH/HYFAIBAIBAKBQCAQCAQC+VT5B/C+wuENCmVuZHN0cmVh bQ0KZW5kb2JqDQo1OCAwIG9iag0KPDwvVHlwZS9QYWdlL1BhcmVudCAyIDAgUi9SZXNvdXJjZXM8 PC9Gb250PDwvRjEgNSAwIFIvRjIgMzggMCBSPj4vRXh0R1N0YXRlPDwvR1M3IDcgMCBSPj4vWE9i amVjdDw8L0ltYWdlMTQgMTQgMCBSL0ltYWdlMTIgMTIgMCBSL0ltYWdlMTYgMTYgMCBSL0ltYWdl MTggMTggMCBSL0ltYWdlMjAgMjAgMCBSL0ltYWdlMjIgMjIgMCBSL0ltYWdlMjQgMjQgMCBSL0lt YWdlNTQgNTQgMCBSL0ltYWdlMzAgMzAgMCBSL0ltYWdlMzIgMzIgMCBSL0ltYWdlMzQgMzQgMCBS L0ltYWdlMzYgMzYgMCBSL0ltYWdlNTYgNTYgMCBSL0ltYWdlNDIgNDIgMCBSL0ltYWdlNDQgNDQg MCBSL0ltYWdlNDYgNDYgMCBSL0ltYWdlNDggNDggMCBSL0ltYWdlNTAgNTAgMCBSPj4vUHJvY1Nl dFsvUERGL1RleHQvSW1hZ2VCL0ltYWdlQy9JbWFnZUldID4+L01lZGlhQm94WyAwIDAgNzIwIDU0 MF0gL0NvbnRlbnRzIDU5IDAgUi9Hcm91cDw8L1R5cGUvR3JvdXAvUy9UcmFuc3BhcmVuY3kvQ1Mv RGV2aWNlUkdCPj4vVGFicy9TL1N0cnVjdFBhcmVudHMgMz4+DQplbmRvYmoNCjU5IDAgb2JqDQo8 PC9GaWx0ZXIvRmxhdGVEZWNvZGUvTGVuZ3RoIDEwMTk5Pj4NCnN0cmVhbQ0KeJztfV2PbDd23bsA /Yd67OtYJX5/BIYBe8YZTOCBnRkFeZDzMLkjyTJaV87MwE7+fbjW2uQ51X2qum/nwooz9dJda5Nn c3Nzc/ObPH3596e/+Isvf/WzX/785L78299++O708M2HL/7rb9795V+e/vrnPzv9z88/cyd3ds75 EFw91eBOObnT77/5/LP/9menD59/5k/frTjOFe/SRaRv/+zzz/7L55+d/uZXPzuddqn5o9T++qvP P/vyP/lTSmdX0umrb8F+8D75U87nkNop5XbO/fTVD0hzJPzlL35TT9/9AegXn3/29cNfnX7+zvuH v3rXH35x+uadTw//659/++HdF/Hhd384vYsP//Dw+3c+P3zz2/d//P5f3nn38M0Jgd8+/vjj7/Dj +w/f/cO7d//99NV//vyzv/nqQO5wTe4paCnp3PJe0K8fTrc4RmPiziVTmbGfY42nWPK5xFMff0M5 FX9uNS+VhnMLLZ3+dWT8HML4dsQef3Pyp18PRQw5/un0IqPfHEiTblvBQQnLDEI/10IVpJFAO9V0 Du0UWwR4P7Tw5S9/+O133/h0+vmPpyODyG9MOOZz2qVbRp7LyHJA8rt0w7V0y1G6LIc2TK6mkYd+ bv30w45QhnmeHgehnOsosx2hnn3qkzBQ6pHIA9QmEE7vR9R2dlU4ngaIPhMkouwaUfEWt7pAQm0I bklidKIe8WmFISByP7sgQsonoOqJxr8dGp9aZBKaJdwNkXGtgdn3U4pMifs5BQSH2IlGVQX7SjD+ vaciSjDdBSoiNyHGXXotFtk1sRolOLLVUp1qHyinNtGI/I8jfjpH5LD7oW0WzNDLEMkIKgcX+iQg wdKE4hIGyE9Zk0VGaBOnUQJQUzVUTQXJg+DOvbMg+LtVaNbHSlS9aTYhlx21EsE1F6IYgXrLRI7F MH4EL9UOG0EkBA80Ph0odWlHBTwIhZEbVAJkZZbjHo2MW+RZ/oXBvss2AlD2lchPzsnLsppHcCiF KGegZa/Tzlo1W28nmgHKKbMM4Xk60dKGdyJAG0NyV4kIEhlnVlkquRQvAqNGAU/7ZB1Ko1wmWxp/ omENDdEK07l0oMQk0zlPgeEfQYiMXJi7RBPpVjvjuU+BO+EwHGSdeoqoJAP5mIhMxcNuMggObvaR hAAnNAjQ8kC07qHOChRhQQP5bl9Hi+wZStsfKaaFaoe1WdxJyAyOTYggeIJWZ1wXRYgUYrQQRARO bGqbOUjiBCMZ1g7NANH8ehHjUUoykpbFqtKGKkwGiCaT4RSEFHkYyC44lLD71JtMi7MrbSaMEuh+ CgUU7dO+zE8JNzq2FvRpo9OrvZhmFLcWxe0qa2mcP1mV3FbBS0EBhFFf6UlGtUoqbXh01P9CFGm5 aISBcrevfQ5q9TK9R5eFDeZwLKxbo2HM0+0gR4OQ5JW8WSsdj68KK6oTw9cH8ap0kUXVYBQtGpSW J3q/a6ZIeNwIsqMnhCHnQFbCnSCmnR2B4Nq0I1TDUpfWB/J+Xyj57HJZZZbQyhBkgNbirrSZlTKN ATmdxuCBsm87O0KdrWEXHPLuS5+fMHa5rnRHja59iTRQuJB4FJWZJDI00KxFEaj2utfFIEy9MdS+ 7PkCTcYkoEoEKn0jSKwWrCVhul0N2MwAyhcVsTN/W1N20fSpOfwW3UGHDuC/ohs6un/3rsu963Lv uty7Lveuy73rcu+63Lsu/892XY5moOqnmoHqcO7PZ4KuzkC1o4SHYxxcRr5H2zccwmhsf//d6GWh KWmnEFAzTqWe80dO0L3A4Ugv/Y168bmiJm6KGQ4Uc2Qhlb1ayjW1+Bcmhq8mPPKTy0W6Hk1dCMNr 7FNuV1M+nCTm3FzwI1MjDznAQf2wEVKEuh9BGE2qf0IYLtQIITh0DYBGGx3CsFehxCoAggUPnwHU xXzUlxDC6PeGlKw3AVxEqAxEXtPwL0BRfLNVcBCQekLXGSDyd68LVDQgFhO4sazmZ+gxi+v4Io1u QpkS9EDCqMGUZ4iQHXrRlLYQtTQjj9Y1ZC89+NHdJcpCXmhK4WYwFAAVtql1angC1efgC5xcyBG6 +cFKoU3CoxiOvoQRmB6Bflcx70vQpDIuXZmORPyQJQW52lIXymYQqK8E5Y08104wOjlA6jWDUE1/ kcGjkwPdlrKhUS9nXOKCzvX6MlMdYOyJQpiRQ6ElJEnMTzkHTolljyt3KMsU4EVZSkIwOxSKUPSz GCwyFD+QA2PPLA8Vo8yE3m+FIMKjCLlu8QvtYjht/LRUXZ+fstKE86iWQD5LjLRHuc7IIIwSGck9 XhC64gcVrl8pAayUIAWKXinlzSourOjqIPfuA+4+4O4D/oR8wFGvyB8uyL6huxhiRZf8We/kanfR x+P+Yhj5xswFunt1JMH+Yq8sTHWJuC4LLb6+t3jj+0OtHC7jank9nEax7pfW0R9EFWEnFAvW7GF5 Laj/+l18+PPvb61f+8OV2/2SeAiFPmkl8MKKuC83O9+xDJuoJ/Rr82Hf+1iHNz87VOJbRyLPetwc OafBMHNM/JpO9+Fg5BVp5/Y0ac7H+Jw4X7eSHh9eS/pwoGE7E8Yg2Q/hIv4NXslhRmkSHo1QJwEo ML5+5vEz2PwXCU2EzOAYhPRdVGRNs5KgyE3BiWA0UASeqOQZN0USYpkyGSEopaSUfN5/7ZZY4O1h sStZj6Z1SeVtTL2E9mgXVoY8atPKr4ebmfn1Ikhq6smjU7DU6K2LAEWPxsUIjxuhVmiEBAzkn+A0 CURNSJl0QShOWUaXhASp04nXaNcoiyLXFdkr8rCsKTiQ8uyVTk4rsniNZpt5Joh7EFZUYW+M9J2L G9tizdlKtUD1S6IyxafAZadp5octyMprQS9uqaJg6v+96U1JcYbDtDjQaaoYv3dlQrwvEprDEwJY ZQgPVJtQFMqLm7BnaNOXRXGbwEq4JhESQ0sVUirZkJ+Rk77OncFRjLMYhwksrtuFJuXdvuS89J5x WlIEBk8pkpC/EDmhD7MyxD7SymyaEk5VJBjL0lRCp2BpcUN1RZZriF1aXwSTK6s+G6+imr99Xc0L FeWxTWd16dyujjruPvDuA+8+8O4D/2R84FHXOLx1TvjpqCv5eNg9vT7sCoeTwsfDrlgTFOKxapjf MOy69f2hWl7cHcxVsGHzYzyHUdjTwdbtkVY4HHHu2SeXWLU39i8MtUK6OdRKw6cNr+9zRym9fqx1 +7tD1b11/++zwVZpmMWaPvYVY61wuAX4NWOtfvZ7Yy40Yp8z/eo21Lq69zgcjjBpEbVxBdY3OpEf tIwI7ynCIwkpTQzQghCX2rKBYKtyOTcSElflcutCXOksXnyTxS1RCUfyLXBijdu5mxwewFztK00y YHcK9i4oWbdDa1vCRmhcB9Wn0VZFi3pMZa6DKtmI+Y4lUjTxi/W30pRY+Ylwhyuv0eTPSjNOxtIT p3ynCjHLuvQLMGJywb0Yftyw1mrnouglxs4QIwClLqTFWXjZgcpcYsWiOAla2s0WzE87m51ubRQU 6r0IFNRFglQJkoJiXyvIClbULCGC36O1VkvcuCNoftjOfWPb0ABZXAVqPVzycK5hidusO7FywxMQ K6eNRTkV0ayztPTEWrt02NCCTQ0T7IpEhH2ZsBytTuR0Scho0ERg7bDgqHoQhKbRCUaZunGKSdYa icJUc/WKHBgMvwnk+Wlle52WnrGBCthxzb8yGehlj2ZRT8zC1YcRPYvFNsIKLC5TjdwtNyWKU/ym sLjVqESCVWTFlfTSQ5zb8KaaOFG7VBgtc8n4eEo8HZUIjyQ0Yz4IsJho6Uag4oU0qzsIqYsw7A3I Io8O3Q7NlIi548BSEiGhYzxZoSJvKUHemVK1yJkpUUh5z0tne3Xod/fJd59898l3n3z3yT+RTz4c OLx1peTpUHSMmVCwT3vvN0aihwslxyPRjI3vGJgFDP8+fiR66/sjrcTDAfrFOVVsmB/57Q3Lnh+/ 7BevnuCdKWBL6WUKL52EDbc33fWI2ZeKWaTyEYPR298dau9woP2mvXae22B7wsmJV4xF41vP3yJH F3vtGlxZDef9Jr9w1Zbj4fBbW+1C46St4yzYDyKMKmKEMOoR5hYHwup94H4KoLmJhrtTSRiRo2Yt nedOgIGSGNneiUGoImA3Q+RRBSCHTz1nR52z0xQgRBGwHWMgNJXOcbNOpGxAeUUe5UBCYDDT4aQ4 USWSXyZBnIOCm3hhw4VQt+3ZG6zNAgFKl8CDC5Ariy2Dc7DgAoQtEBKoo8eQV9xAQhTfQlahG8pE dTEujByy5M1MJiQlk9NEFnl0UnbBUbx6nTqGTDrcAYIj5+w7C0TZSyodnNrAsZk6Cy+QVUfhjXJH zxJai0RZCvd5mgUNwXGzzLAoKwBP4Bdi3Do/jraZQCUZCBJF0oJKCBmBEAoiDpSl4pCJAvPiwtoC 1IYm0CpVbvwYJjOQt81DOABRrbvHXT0J2AVtFxrS93JOYYE8irPPuCI421oEtaAr28R3oNF8xjIj FxJCVeTR4aWXb5K4AyUfZvYQOfCYFDLveCyjRqkiE2Wz4qE2V3TUInGjceEpjUA06vQE71Wlc96H 8lgGjqSgpILYFD+LrvBYRsLOLJQzg/MwYNqARNI4YBIy97U/SipdRrAj5EUAGlwH8s6QBwquzjxF BkdXGDzExWw/9qctVOpSgAi1pV1w436wSrvP7BbvOA+VRiU8emwDeReWGIVHJCzyyN8gBHgmoEpk O7ppGqHsrbfrqAMRGbO+mTKErL6FPAmP5uT8ig/UFi/U5LRPCnV9yRG5V4gyyinARSALm8+oyqFc SmUybueNsJSzOUSWYmvmuZr0WneoNL93czjw02YeRPDYMGd+z/OKDyIe1MkrpcITW23nvNAqKA+R kUte3klHwaoak84DT6mpodGpndhW05LIKjQ5L88zZb7LxBs/9aFOE888n4YjIUA8O+VcUnPHQzu9 tFl1dDyxo0kbCCcM4QTl13RCC8iMIZQtuNBwkIy8VaUUMaRZ2x2lyF3+iYrpNCOO/VAHrTEM0Spw t82ho58//ETmFkXuMoSL6RY5WKfE0TdzvyFWhbhFUShzsG+RM60qZ21tRUtU1QENXEOCz5z1k6OX 3rTRP1qzlIq2/Xs1nHW5SWujuVGS63Jq3enG1Q0wHReUBzsRVu3L1v/Yd0+uzt3cezH3Xsy9F3Pv xdx7MfdezL0Xc+/F/DvoxRzOTL11r8Kz4w4Jjv3pBNH1yc54uFXheLIzuKQuD1dWPn6y89b3h0o5 nAK+OIHgcfj75Me/od43THYeTvVepBATi3NL4YXJzuReOOTgcA1iH87gY444XP3oSG/pcAr3bQcc HDfAxNfuuUlvPbaTM/bY7FKuBR4x+ctZ+3zVkNPh3K6ON/CyhVMdGnW8NSfi2E2dhEcRRofWCESM n3BZQMdxMYBquyor/AcIuGgHiKwSbm0YqAPEMqN2so243AKIH6IFJMpAPscVueKiw5aXUCLUZPEL ULFkx9cDZXXrjPkgpGZJBaJgkXmDYvUrB2QcLbTxS97ZwNwClBW3MtkpdCXfgKsfpEZD722/4iI8 LkLutOhLgrf9kAWIl6R0LhwCaRmJBE+CU3Dkp75qD2dkmJ8bPtmTBSGK80gg8/gcgBNwtisT66gg OFzngf4upXC4DQKrCmEii5zbPlgiz09jecI5lJVunEJQpAjiXmJe4LEyFDGYWZmNF4rgzvKlJ7Zr S4cLlbwil30hyPyfEPwqRVw7U1cJN/afdwYAwrIOXFhTluXoNqCdYYGwmR3QskjcfdP2BsvbiJY9 N553nba+UMtbZBK6sWKV49UsYryrR0x21jJJNGugBN7qp7IzKy9zOuu19LCr9lLTdApS4XQYFw7m 6lzF3Q/d/dDdD9390L+pHzrsIH6q26CTy6izT3tp14cb6XA9+sq+gMIdUDFeOw/84unqWwwO9fLW UdizjrNvvAgq5lefDE5vPZVcePnDPmm6rxifHL2IV08Gp8NxljYJuABnF3FAnbPrOlOGfOkiL4zp cHPZjrD74lE3RwwSrpIq9DM/iIDrvUQAqmWP0P8vvF0Dw2unIyyFJ0qAvKEoxMgzZtAl4ZifdNz4 RJSFLGzGTYStMDBFIQHFtHsyHG6HHFkMmPl9FAGccTtG1rVLgxWu0Uh7pON9JGQSqt3RFIUCEa6I y97uVCNBwUW8vD4tOs7vDCluQYLAwzkBwXtvCAoWssgp7oMtXUO+XTKGk5rJZgzaiYLQEpCRMWUp QmFws+AuJClsztNxEokERUa5Zy5SEMULxSUFJ7vDMGi2fiP4jt2V/KJP7MQemyR7n/riyZyuj+eZ RW+ZqoE7mXqeUhPNDDEi54tIiNr1VKZygErZVAecy1QsEOx+Q6HsygQE17fgOoUwNBP1iszLY6wY eG+EpZuF/JTfIuc6FU+0U8RCOjfmtUGO9iteODAn27b7KWj6ZqCc1WXl0P0jjgs2rDqeV4HlrVZx 0YtVzs+Pc91qJBW6aiumWldF1nG5Wckp6nIAnlf47fxDOF/4ElzyuqHN8VxfQ7w7ubuTuzu5u5P7 /8bJHXZu33rR5LMlBo/xybP+5Y0nYA43LV+5Uam50xjFve1c79WPj/SRbzxVhN3qYxR8+VSR79wf EHEC9WixIb2w2JBfPEUcXKcb3VJ4YbEhx9uLDRAXPD9qseH6R4dqfOtY8vliQ+RF3RHLzq8aMuW3 ni0uvFVhn7LjmXm3TzdePd6br78tFHGX3OCEZVfeXbgI9POY9Egd9fSSkCYGqASNv7tiNk3UZJYY CJh+yFwzjlqHBSpCuss56lJAENiX4W4lIHOinqBZXA+Di9iyIV+NrsBAse6RTZhMQp1tDT+13gJv sI9h7kyJWYhu3gRqzH/m1eRAIU554cawRC15vfSIe8wT79AGku8EIYsXRtmJ23VM6RGX/dWJ5A9n KcSIFmVfLJzJYSk0NgkXBGhZBCSB2/sjr9hg8pHIL3mQdOSeLBacUFQ5eUXWMSwWo4yuKqdJFmgA X3rbiQQCGjJtrSBqRLgPYkPqTCxCwLo+USKKfeMc5p0XgwD6ILAzw50wUJATZxRjnAePmKNMQlT+ 0IuJPAxF+9WneSkj6GvYWmo71QOlONEsnIxJYjQoetSCZeEnwaoILpwWgclrgqOZrI1o2qdjuoOQ ZWcsiyQFenZPYpoFl730y3sc2XuwrAhRrnlWi/2FIpVZV1n6RU96Q87PyCR4dWmCNIo9Eep4KCyk KUY3P6QKaF6p1tmbo/2UGbnIoKzPnWRsXh0c2daMiQod+qqAsui61b9+XraDjra2wpGNQmeHmkAb UKaagmaXs2pt12BBoLSpA1Rm1GnpIKtieimstOkcLLIwyj4H1c864xIVq9I7QlKybee+Ap2CNqxY ZGY1T91n+UklE9P0qLPUmryxMt6FspwbphMDjylO45E/nqpXsDOHCwnjznnTLUV1rTn3C1RUGPCl Ic7Kac1AnN4PvhXI6lOf6P1WfUR4FKH2LX5mxQs83gtExxntRikQkr6GmaY8xeobWJXFCKP2hDpT MkI+TU6oiFtCMc2bcEyOyLt3poyzRu89wPX1s3vjem9c743rvXG9N673xvXeuP5fNK6HA/lP9UAL 3iVOTwbTNyaHrjzPcnjv2zBCWEGKdPoff+/bje8PVXJ1e+jBddsxavY5cX724/eilheP9nM1+SKF F6aHir99C5z4heo+5gq46x8dqbC8dUMo7jHcL2unWng4Ci9c7fcaxKuWVd562j/y2bd90lrIKOVy m0O8OjNVDifFaA+p6+kG7mHnPbM4QNAmIfHJP4JAkITUOoEASUAYoWwOAVIgwuMLOH2iu02xwT6S MFoboKpgr8idSDHZFQm6MhIIJ3a45Z4oCcyoSVEpX1QS7A0QZaEwI2dFTuJUBKKAJ4qLcRGrKMZF yeJa206HCuS3yOLlTzvgdihqCWyHcXPt5BTRn1mpxHO5kCEiA0tEdsSYly608laJhwUSiZPylvVh 2JSmuJabpFSCIsc+kUW+CPUWKnmdUtFpORRj65vA4axUiozD0lRDTfvQx12W1U1pMrqiIvfLzkKX /lFyOvfQedsLDThOhMiNh+lmsLZI8VMhp4J0FrlNHePmZNRmSZmB+AYokF4SAwGvnXQuxACRMw0d iCJ6s0w8UBeJx8dAWLbkS5ULaXuURTaCU2R8iqf0xHek2aqN35hsIkEiwpzwHKUJLJTKzB3OvjV2 lpjXYQiNK4RURSQqYeoNngBPTkpTXcFTyXWi9/ISUPIM9qyjQF3FV4isPiuoeHmFToSbmeESFGa3 PHeuSlNeRbbseNm090RhuYmg4FiW4SLvqnaUtyzTjEpqBed8gZoYbZVUSQ1vMKshUFpVFmJskZVU sGDx8vaphHJtRpYau+qPgLk5gZovY5a8C8x1D1b6fRXbTD8v0VUScbnAojIOZcsZz3quXOedW8vi 5ePyKY0nI6bjBVp+AtWwsXdtXqMtD86SS9Pcu96jwVVUsgJmIE2vgXOiLe2cik8kBNlWU7AXQhUE CtNRKCXUI7RkAPzFSpSmoTMniVWi1cmA1YXRZitgFZ73zqleCg23kFqRreZV2WggLNzEYCcboith FxiV1m7kbmxDQWDkrKrX5FgMcWelRU7yHmjlZAZBeQeCQlCxphROXsmkkJNFg8h3g+X8VvaCGsQs ryTA3HEZna11nkpzar5RStrnuToJ+z7E1fmye1fj3tW4dzXuXY17V+Pe1bh3Ne5djU/V1Tic53nr XpxnR0qa/M3TyZbrM4jlcDvO8QxiGmwxRekiZ5s/egbx1veHajmcVL142gHPwlTuuKpvmTV88Yx8 wiUb+wRemjTsNzVY6nYasR1o8Fhvt7460lt9cTIUNRUP7/Bd+6d6u6my+vINp1g03rF+QWM17Mxd xu4TjuMNQx9fT5t/1E/+sGiYid1Xj8dZK/AgO6dqPUogumCbIzP6tXhHFox95DKTbV7G3uAIT4G9 3Z0PsnosvYCQFoFrAcEjHnHl9Raeq6iPNuta5tur2tmOUh317tNl7oVKNpj806mdfvUTZfc3zO3z Qo7PCjnipqkrekAM36L3O4X4jP2ODAk4XPlCaUf16rnAyNFb4jNPEfnn2198jWXgaqvqKXU5J78I ep4Wl2I1ERIX85y3nc0RLY3W80q+Vt6fMJ+3ivunyu+1Ak9bgX9hOXN1tPSv0cT6oI8uyOuL3ONd 3XDyhavvsHk9O+U9rlqjxVa29z7wbAIJXHz3nnd0gFBYP7xnZ4sEOl3vEwb0ICAojVT4atvTQv/0 eX11ff/Jcn/NBPJzE/C4v/2WWmbe1we9548wAT60rHeSk84RBa7ze1zsY89sZ+Y58f41EDz3MvnI FwRIGGoaEZIphcwqCfZoNJ+cw+05/bmX//Q5fa0B/FR5v1b85bnLTyG+SicWP7TZCL6u8AunAkLj JAl8IDYYDY9W+UDdowgY7NZ2Vu1LkU9KhMrdKCRovqXME0T4ZPTn5RH5WHMlQ73sd+jwP1UuX13w P0m+rxV7fV7rIy6mu9HlmfE67iOY4DVdupC5t4+dHO1pxLaiYeE9m3viDpXEJwKU84hLH3A8Ktlp xJgLRuSOg2xiTpLy1JLqBM6I88313q5W90+QxVcX90+U6WsF3i52dvinOzuSpqHgMrIePHAYaziN Nb76x2/efRFeGCH0g1FG9pqB2Nh+/fDzX/7dLT7NHfFJvATtgs9NaZo/5NKfZPLrh/fvvHv48cO7 /PDHdz4//Pb7D3+4yTcc8B0Wcq6XbP/jTSbxkAlmxD4ih+loIKxi9JqWBheZcTl99f7rB3++yTAf FmB8ytCR19/97O9vMiuH+tcrgxuzl/JYD7lwmuuCy4f/Qfv8D7e5tSNu9qTTnts///b3P9y2giNb L1GvDb86d/3I0mcJ1tE4PCvAcLMA+6HNWwFu/FR+v/7zd2WI90V5+P5d1I8/vmsPP96W+Mj683Bb fN5npvA1WX74HYrkmw/j5x+/H9Xr23df1If/fZP7YbUI9m7txv22iEfVogR2nZ6J+Id33ar9h/ff 3OR6VDdK42tbrxftqE7M8s7Opq725R1vl/dh7bDy3vipvP8WGf72XcgP38DXoUR+uJ3lw9pSsWNt Y/5Sjg/bBDzsHC6Y/Pjt6Y9oYuJtdt4d1ZjCe1n37L59/PHH333/Lj18+O42u6MKU+wxq9fm0bvD JqHJ4l7P5fncC67n/bixSfQf0xFPvNsX87xOPRSnTdF+PkEHAk9jhLkz2OECrRGjYfBCAhdXxij5 nIS59jASmlcspKiVw2osjvrinzCjN7tkP1WGr/TJRr/yeS88xH57SuKZMkL+uLG39u1HXETN8acP WrbnSg9HjxnnAkAoZQ4nA5dv7Epsl7QiX6zjytsuAgnBLhPQ7viYj0Zgnz6rrx98/0SZv2oBB7Mv Dln7KLVk/1EWkBpNuHLHPpTQdaAj2YRTdNLSGMHIplFjmo4k2ITDyCy33fOCexIqTwElXtvNalB0 hUvD4ujV+bdPmNXbNf8nyvLVcp9dgSu71mF+uO+CK3EfsXH95ndHi1DevfVIxNPN6xjq4YCIFthf s3ndu7e+fxjL5X1w2eukVeGq/u4q5au71707PPfABbaMk4metz0meolsp4hEAAq6DBJXaOqhgqh1 //eKnIzgGYzzYZ2H6LLegCCqM3LRNZNRnKsFB6FEpK0aJEiMYJH1afB7pD1Hk9CY4rDGHHlby3OC PrkkgGPk9pWZWuTtLjthYpxKgqyRrd7MR9TdTls2QShLC5Ez2VNDdiZwU2DUJU6m3xinApM41wks bkv7UBOZXyaettsxTqsYPYND3GTi/oy9yHyweOUo8bDjzC13d+yVofsIp674xMjS40JWMkZo3hqM PeE0WQ0wos+UgOISq5PgJHXUl66sPAClGRlZbHxDZma/+aWaxuOCpsduhHqaWt1QncDiokS2UJTW hmJ8wjgkSzRa+pJGNrITViY08yLzmvmU9e3UIOOcWjLTlgI3kFdcEIrNp6+q8YywSmRHOM1qZ2lZ rdxEsUprklqFtlxYfd8yae7AdGCuovnlRjbFmZcxvZoH2hCVs4okFJ7MnMGFOzc2VPIF52IyMEwC SBydhtxJy7HpykzhMcKZ0TKNbepBezCmmtQYmgY3kFfcsnc9GyFIrFA3R1dm1QwrAxBkukkJOV2o 8rDzsGW64yippzfxSzU73y3NTdcurW5uf2sVrm5Ivjce98bj3njcG49743FvPG43HofDMX+4KfAN e0xziLxD8+mQ6PoeU+8PNw0ej1Az9g7XghJ4y7XlNz4/Vsubj1iHeHkPXu5F+6d43e2ml3T1Kjzv 33zImpMH+7QTNvtVnhLYJX2jSK4fsi7Y7Jq17yuiowFCnxhLkriIxfGEE5A3xF3pIARtGiudwUGf 4nUCr3tBnLft0CAkiyzOyYIFKkGuM64Cs6JmfZj6BVp8OZXmbPJtR8D7BWRFkGZCRCsHtqk8Suak L2OaOSAKK7tdhJPlHSD0qRqilQNnhJFBKpUgn0zlht5L5cXvg1Pffxn7nrHrUwik6/qUIhJgeXsT GISVHde1J15ZdbaTfWnCdR1ck6JcXwq0n7pVB8h0/7hDksT5VWaOh3h2JarUrbwh12YKNju+WQoy FZchQQObkUE7fm+DrpupwEKhybCs98K2r/a171XgXgX+lKrAcdP4qU6l5K4SeNo83eoxXDmWctRj qGiI0bsfHYL0pk7DbQ7HyvlUs9v2rBGOI71qatu/eWqb93LvEkYfGPca7TsM16e1/fVpbe+4JFki X439QYShYSMAjWELkSdqQrpcXDvSgTPefm4YbpWoR7zbWWy9ReX9XAXn+hQaCIqBSKTeOAlklGdc JpKxA3pDusvOCBnH/bhIMwmJJ3eMeUbHLkgqjOPPvS2xODYc7iowfx3jveGIovJO5KZcFbuCcBMY dng4PhqLi7/Imff182oyi8xL+nF3Wc0MDkIOnHkbviFG5sm5XTBZBTzxiYVDobTiwuoGAffZOz5N jRvHXCJiEN74ZVxemwUCX/1OWOqGjFFfJqHWZ+RIQrbgQF6ZJa/HvXDPX5mRlaGSxdl3IhoN1715 Y1qYkT2/rtmCKXLtSseTUUtLDGEL5dBwjM0lBbKOi+PTjCsCXrolqkTYGb0Q1jhnZBJS3PPK2J9l 6cAG406KYb+uLRlh91mIRtRCXnFpRG0Gk1U3vdGG+mLL+ZxzzxaqqJa7mCaaBXIRnPSpFU8m49aX EJmRm3EuzF2jQfGegRztHC7NhLh0qI1cS+o0NmWtuDyNLVBnmSLwPC51psjFT2SRm98HdymYlZw7 3FnR0qwfQTXPgqNJWIhSVeb8jJxZp11QMDeHDAtUzSvYMjCsedW8yipfmiJX7O89Y5P+RDhJXFbk Mv3J4wXBJJH/kyviMxx7T1WQ47JlouXNxxVYwN4FluktE72HOUu6Tr4FcuFY0ZptbjeWvUvePPbV bvDdsd8d+92x3x373bH/e3bsh+OX8Kmmg3vhksflOOLGyC5cmQs+Oi7P+ybiqeKIanrDhQO3vj/W ytVXZg7uLMXtEMPEKo9IfvzlA2PE+dJRepzMxAOlK4WX9vqGdHtu3TdzMC4eT69fmVS/+d2xJt86 eeDbkyc5h7uAA628Pno3VG3XTeytL5HGjOmZfdJ2I9blO6T56mOgPhxOC2jzV+J8Vm1nns4ExHOz gFlnscfvjOYaV5oL6UqojEuYKwllBGe+pASEN4wzJ9yAbBFL96WDANeN25wZnGoVikS2sqTLnkFw FsxPYyl7pE7LJOB2Ia1HZjZBFsMIifzxljARGSS075ltEpBuh846cwYCHm7O3BwPsdH8Z96ZDqS2 HISqTGfxwuvd0JDS6UwVZ24ZmZfvUJ2jJRhI+ir8Ha0MLGIqW1DeykBvz+7LIMP9rjLIU4CkFCRs 8DNuV86w0pl5qBoIjW7m9TdAujCKBOmsW3BSEezBLIFJwJvS25e+lF0yri8hmG3nJSIsbHRh0ZOx zKD7buoNF+XKq3JwrFTnP0HQglr1Emt4iVLZLSbSpFkuU0h0wqsdJdwwfDERWUW8/L0+Dn1pQ7wD y5nvDgKhl5vZSwByfqmDnH1degbCS9/IsFCKqwBFCNJAKUJeZT+BxQ19HzpssvDyMZgfmbZplk0S FJllFWJRJj7QjcZ62XCxzMpqM9OINKF0Fufk4mVlc83qlmaoFeOCgMGL1WSgEGZFR1ItLXYmjDkN fhp8nS6EYpcZ2SubVZFNy9CrnNNOr/JdU6/yalNzcnk7xepFhl1wzPtPQ37C2cSwhGdhy2O6C5nx KEZZWQLasquL6XfaSM2KjcrSOxBTkQvNkhBh5+U2QjHmdblQJbXzsJJkOmBJOZ2zMrHz3crjdO3K /3Q5Us/OI0l7u0ZDzrac9i3N1bH9vTm6N0f35ujeHN2bo3tz9G/dHB2PGN+6sPlsuTlxn+jTUdut OYlrr/uu42TtI0+TwSW8/uAcrnvFTBzO9PKdKU4tJGycs1NjXT4HhMht0rhTuto0G/0aTnvjTWvc GMHNi7iXsotAO8FVuk2J6NKP44Nznyqnrz05+ZPl/TfbCbr/A+/JVnQNCmVuZHN0cmVhbQ0KZW5k b2JqDQo2MCAwIG9iag0KPDwvVHlwZS9QYWdlL1BhcmVudCAyIDAgUi9SZXNvdXJjZXM8PC9Gb250 PDwvRjEgNSAwIFIvRjIgMzggMCBSPj4vRXh0R1N0YXRlPDwvR1M3IDcgMCBSPj4vWE9iamVjdDw8 L0ltYWdlMTQgMTQgMCBSL0ltYWdlMTIgMTIgMCBSL0ltYWdlMTYgMTYgMCBSL0ltYWdlMTggMTgg MCBSL0ltYWdlMjAgMjAgMCBSL0ltYWdlMjIgMjIgMCBSL0ltYWdlMjQgMjQgMCBSL0ltYWdlNTQg NTQgMCBSL0ltYWdlMzAgMzAgMCBSL0ltYWdlMzIgMzIgMCBSL0ltYWdlMzQgMzQgMCBSL0ltYWdl NTYgNTYgMCBSL0ltYWdlMzYgMzYgMCBSL0ltYWdlNDIgNDIgMCBSL0ltYWdlNDQgNDQgMCBSL0lt YWdlNDYgNDYgMCBSL0ltYWdlNDggNDggMCBSL0ltYWdlNTAgNTAgMCBSPj4vUHJvY1NldFsvUERG L1RleHQvSW1hZ2VCL0ltYWdlQy9JbWFnZUldID4+L01lZGlhQm94WyAwIDAgNzIwIDU0MF0gL0Nv bnRlbnRzIDYxIDAgUi9Hcm91cDw8L1R5cGUvR3JvdXAvUy9UcmFuc3BhcmVuY3kvQ1MvRGV2aWNl UkdCPj4vVGFicy9TL1N0cnVjdFBhcmVudHMgND4+DQplbmRvYmoNCjYxIDAgb2JqDQo8PC9GaWx0 ZXIvRmxhdGVEZWNvZGUvTGVuZ3RoIDk3MTg+Pg0Kc3RyZWFtDQp4nO19y45kyXHlvoH+h1hmCtPR /n4AgoARqSE0EAFJXYNZkFo0CsWmhKwm1CQgYL5+/Jxj7vdG1o3IylRBLYmxyYxj/jI3Nzd/2z19 +/env/zLb3/9i7/95cn91V+d/vqXvzj969dfuZM7O+d8CK6eanCnnNzppw9ff/V//+L049df+dMP K45zxbt0Eel3f/H1V//w9Venv/n1L06nXQH+27/7/scfTg8ffvzm/3z3aKX99buvv/r2f/lTSmdX 0und75D9yPvkT777c8+nlNs599O7jyhzFPztr76rpx/+CPSrr7/6zcO73394/CY8nH756PPD/3zs D786PX4TH3569Onhw/fvFfrH07vHfzq9+99ff/U37w5YC9dYm7zk0M4+7Xn5zcPpVo7RMnHnkimv 2M+xxlMs+VziqY+/oZyKP7eal9TCuYWWTv826nYOYaQdscffnPzpH0ddBx//cnoxo+8OuElH9fvX W42olg79XAtFkEYB7VTTObRTbBHg/ZDCt3/78fsfPgzJ/PIPp6M2z28sOOZz2pVbRp3LqHJA8bty w7Vyy1G5bIeWz6GmUYd+bv30cUcoQwNPT4NQznW02Y5QR9v3SRgo9UjkAWoTCKf3I2o7uyocTwNE nwkSUXaNqHiLW10goTYEtyQ2OlGPSFqhCIjczy6IkPIJqHqi8W+HRlKLTEKzgrshZlxrYPX95CKT 435OAcEhdqLRG5F9JRj/3lMQJZjsAgWRmxDjLrkWi+yashotOKrVUp1iHyinNtGI/PsRP50jajh6 /dCnj2qHwZIR1A4u9ElAgaUJxcUMkJ+8JouM0KacRgtATNVQNREkD4I7986G4O9WIVkfK1H1JtmE Wnb0SgTXXIhiBOotEzk2w/gRvEQ7dASREDzQSDpQ6pKOGngQCiM3iATI2izHPRoVt8iz/QuDfZdu BKDsK5GfOScvzWoewaEUopyBlr5OPWvVdL2dqAZop8w2hOXpREsa3okAaQzOXSUiSMw4s8tSyKV4 ERg1CnjqJ/tQGu0ys6XyJyrWkBC1MJ1LB0osMp3zZBj2EYTIyIW1S1SRbr0znvtkuBMOxUHVKaeI TjKQj4nIRDz0JoPgYGafSAgwQoMAKQ9E7R7irEARGjSQ75Y6WmTPUOr+KDEtVDu0zeJOQmZwbEIE wRO0OuO6KEIkE2OEICJwyqa2WYOknKAkQ9shGSCqXy/KeLSSlKRlZVWpQxUqA0SVyTAKQoo8FGQX HErYJfXG08rZlTYLRgt0P5kCipa0L/VTwY2GrQUlbTR6tReTjOLWorhdbS2J8ye7kts6eClogDD6 Ky3J6FZJrQ2Ljv5fiCI1F4MwUO6W2uegUS/TenRp2MgchoV9awyMeZod1GgQkqySN22l4fFVYUV9 Ytj6oLwqTWRRNxhNiwGl5Yne74YpEp42gvToGWHwOZC1cCeIaadHILg29QjdsNQl9YG83zdKPrtc VpsljDIEGaC1uGttVqVMZUBNpzJ4oOzbTo/QZ2vYBYe8S+nzs4xdrqvc0aNrXywNFC44Hk1lKokK DTR7UQSqve5lMQhTbgy1lD1foJkxCegSgULfCGKrBRtJWG7XADYrgPZFR+ys3zaUXQx9Gg5/h+mg wwTw3zANHdO/+9TlPnW5T13uU5f71OU+dblPXe5Tl/+0U5ejHaj6pXagOoz7pztBV3eg2lHBwzCO XEa9x9g3DMIYbH/6YcyyMJS0UwjoGadSz/mVG3Qv5HAkl/5Gufhc0RM3wQwDij2ykMpeLOWaWLx7 Y8GjPrlclOsx1IUwrMa+5Ha15MN9YO7NBT8qNeqQAwzUx42QIsT9BMIYUv0zwjChRgjBYWoANMbo EIa+CiV2ARAseNgMoK7MR38JIYx5b0jJZhPARYTKQNQ1DfsCFJVvtg4OAkpPmDoDRP7udYGKAcRi Aje21UyGGbNyHSnSmCaUyUEPJIweTH4GC9lhFk1uC1FLM/IYXUP2koMf012iLOSFJhduBkMAEGGb UqeEJ1B/Dr7AyIUcIZuP1gptEp6U4ZhLGIHlEeh3VeZ9MZrUxqWr0pGICdlS4KstcaFtBoHyShDe qHPtBGOSA6RZMwjV5BcZPCY5kG0pGxr9csYlLphcr5SZ4kDGniiEGTkUakISx0zKPXByLH1ctUNb pgArylYSgtqhUYSin81gkSH4gRwy5qkHRIw2E3q/NYIITyLkusUv1IthtPHTSnV9JmWnCefRLYF8 Fhtpj3KdkUEYLTKKe7ogdMUPaly/SgJYJYELNL1KyptWXGjR1UXu3QbcbcDdBvwZ2YCjWZE/PJB9 w3QxxIop+Sezk6vTRR+P54th1Bs7F5ju1VEE54u9sjE1JeK5LKT4+bPFG+kPpXJ4jKsT9HAazbo/ Pcd8EF2Ek1AcWHOG5XVm/o+P8eF//POt82t/eHK7PxIPodAmrQJeOBH35ebkO5ahE/WEeW0+nHsf y/BmskMhvnUl8smMmyvnNDLMXBN/zqT7cDHyGWXn9rxo7sf4nLhft4oeCa8VfbjQsJsJY5HsB3MR /0ZeyWFHaRKejFAnASgwvn7m8TPY/hcJTYTM4BiElC4qsrZZSVDkpuBEMAYoAk9U8oybIgmxTJ6M EFRSUkk+71O7xRby9tDYVazH0Lq48ramXkx7jAurQh69adXXw8zM+noRxDXl5DEpWGL0NkWAoMfg YoSnjVArJEICFvLPcJoEoiakSrogFCcvY0pCgsTplNcY18iLItcV2Svy0KzJOJDq7FVOTiuy8hrD NutMEPcgrKjC3jJSOhe3bIsNZ6vUAtEvjspknwyXnaRZH44gq64Fs7glioKt//cmNxXFHQ6T4kCn KWL83rUJ8b5JqA7PCMgqg3mg2oSiUF65CXuGNqUsitsEVsE1iZAYWqqQSsmG/IyclDp3BkdlnJVx mMDiul1oUt0tJfel9xmnxUVg8OQiCfkLlhPmMKtCnCOtyqbJ4RRFgrIsSSVMCpYUN1RXZJmG2CX1 RTC+svqz5VXU87fU1axQUR3bNFaXxu3qquNuA+828G4D7zbwz8YGHk2Nw1v3hJ+vupKPh9PT68uu cLgpfLzsijVBILgezJOH1y67bqU/FMuLt4N5CjZ0fqznsAp7vti6vdIKhyvOffbJJXbtLfsXlloh 3VxqpWHThtX3uaOVPn+tdTvdoejeev/3k8VWadjFmjb2M9Za4fAK8OestfrZ75W5UIl9zrSr21Lr 6t3jcLjCpEbUxhNY32hEPuoYEdZThCcSUpoYoAUhHrVlA8FO5XJuJCSeyuXWhXjSWbzyTRa3RBUc mW+BEWu8zt1k8ADmaV9p4gG3U3B3QcW6HVrXEjZC4zmokkY7FS2aMZV5DqpiI/Y7FkvR2C8230qT Y9UnwhyuukbjP6vMODOWnLjlO0WIXdYlX4ARkwfuxfDThnVWOw9FLzFuhhgBKHUhHc7Cyg5U5hEr DsVJ0NFutmAm7Rx2uo1REKj3IpBRFwlSJUgKin2dICtYUbOYCH6P1lktceONoJmwnfuWbcMAZHEV qPNw8cO9hsVus+nEqg1fQKyaNjblFESzydKSE3vtkmHDCDYlTLBrEhH2bcJ2tD6R0yUhY0ATgb3D gqP6QRCaSicYpeqWU0zS1kgUppirV+TAYNhNIM+kleN1WnLGBSpgxzP/ymIglz2aTT0xG1cJI2YW K9sILbC4LDXyttzkKE72m8Li1qMSCdaRFVfcSw5xXsObYuJG7RJhtMoly8eT42moRHgioVnmgwCN iVZuBCpeSLu6g5C6CEPfgCzymNDt0CyJmDcOrCQREibGMyt05K0k8DtLqhY5syQyKet5aWyvLv3u Nvluk+82+W6T7zb5Z7LJhwuHt56UPF+KjjUTGvb57P3GSvTwoOR4JZpx8R0Ls4Dl3+tXorfSH0kl Hi7Q90vFggvzo7694djz9cd+8eoj3VkCrpRelvDSS9hw+9Jdj9h9qdhFKq9YjN5Odyi9w4X2m+7a eV6D7QkvJz5jLRrf+v4WNbq4a9dgymo47y/5hau6HA+X37pqFxo3bR13wT6KMLqIEcLoR9hbHAin 94H3KYDmJRreTiVhRI7atXSeNwEGSsrI7k4MQhUBtxkinyoAOST13B11zl5TgBBFwHWMgTBUOsfL OpG8AeUVebQDCYHBLIeb4kSVSHaZBOUcFNyUFy5cCHW7nr3B2iwQoHQxPHIBcmVly+AcLLgA4QqE GOqYMeQVN5AQlW9hVqEbykR1ZVwYOWTxm1lMSComp4ks8pik7IKj8up1yhg86XEHCI45Z9/ZIKpe Uuvg1QaezdTZeIFZdTTeaHfMLCG1SJQlcJ+nWlARHC/LDI2yBvAEfiHGrTNxtMsEaslAkMiSDlRC yAgEU2BxoCwRh0wUWBcX1hWgNiSBUany4sdQmYG8XR7CA4hq0z3e6knALui60OC+l3MKC+TRnH3G FcHZ1SKIBVPZpnwHGsNnLDNyISFURR4TXlr5Jo47UPJhVg+RA59JofKOzzJqlCgyUTYtHmJzRU8t Ei8aF77SCESjT0/wXl06530on2XgSQpaKiib4mfTFT7LSLiZhXZmcB4KTB0QS1oHTELmvfYncSVn BDtCXgSgketA3hnyQMHVWafI4OgKgwe72O3H/bSFSl0CEKG2tAtuvA9WqfeZ0+JdzkOkUQWPGdtA 3oXFRuETCYs86jcIAZYJqBLZjW6qRih77e166kDEjNnfTBhC1t9CnoQnM3J+xQdqKy/05LQvCn19 8RF5V4g8yijARKAKm82oqqFMSmUxbmeNcJSzGUS2YmtmuZrkWneoNL83c3jw02YdRPC4MGd2z9OL BxEf6uRVUuGLrbYzXhgVVIfIyCUv66SnYFWDSeeDp9Q00OjVTmxraEnMKjQZL883Zb5LxRuT+lCn ime+T8OTECC+nXIuabjjo51e2uw6ep7YMaQNhBeGMIKya3qhBWTKEMoWXKg4KEbWqpKLGNLs7Y5c 5C77RMF0qhHXfuiDNhiGaB242+XQMc8fdiLziiJvGcLEdIscbFLiaJt53xCnQryiKJS52LfImVqV s662YiSqmoAGniHBZs7+ydVLb7roH21YSkXX/r0GzrrMpI3RvCjJczmN7jTjmgaYjAvag5MI6/Zl m3/spydX927us5j7LOY+i7nPYu6zmPss5j6Luc9i/gvMYg53pt56V+GT5w4Jhv35BtH1zc54eFXh eLMzuKQpD09WXr/ZeSv9oVAOt4AvXiB4PP4++fFviPcNm52HW70XJcTE5txKeGGzM7kXHjk4eDrs wxi85onD1URHckuHW7hve+DgeAEmfu6dm/TWZzs5447NruRaYBGTv9y1z1cVOR3u7ep5A50tnOqQ qKPXnIhnN3USnkQYE1ojEDF+grOAjudiANVuVVbYDxDgaAeIWSV4bRioA8Qyo3ZmG+HcAogJMQIS ZSCf44pc4eiw5cWUCDVZ/AJUrNiReqCsaZ1lPgipWVGBKFhkelCsftWAGUcLbUxJnw2sLUBZcSuL nUxX5hvg+kFiNPTe7isuwtMi5E6NviR4uw9ZgOgkpfPgEEjHSCR4EpyCI5P6qjuckWF+XvjkTBaE qJxHAZnP5wCcgLNbmThHBcHBnQfmu+TCwRsEThXCRBY5t32wWJ5JY3mWcyir3DiZIEsRxD3HdOCx KhSxmFmVjReC4M3yJSeOa0uGC5W8Ipd9I0j9nxH8akW4namrhRvnzzsFAGFpBxzWlKU58ga0UywQ NrUDWhoJ3zdtr7D0RrT0ufG969T1hVreIpPQLSt2ObpmUca7fsRiZy8TR7MHiuGtf6o6s/OyprNf Sw67bi8xTaMgEU6DcWFgru5V3O3Q3Q7d7dDdDv2H2qHDCeKX8gadXEaffT5Lu77cSIfn0ddu+XO7 AZdJ0luWG7fSH0rlcA12ecvf22UmOJZ7/XIjHS62Li/602PbroSXlhvt9t2KwltkMb7uTfXNZIey +2JejHyjC62YP/tNdX6zIyO6zdgXTcMf47NHK/Hqm+p8w5ORCxgmIp7281xCr/FQL7lAw2oYPt92 hF2KJ/ncGCQ44Sq00B9FgGM0EYBq2SOsnAr9kmBjwunxT+FbHCBvKAox8owZ5F4dO7uOV8aIspCF zbiJsBUGpigkoJjmYcTBr+aoYsCe+ZMIyBl+RbIcVo2s4IAk7ZEeRpKQSajm3SoKBSI418vevNGR oOCivLySFjlCcIYUt6BA4GHWgTDubQgCFrLIKe6DrVxDvl1mDPM+i83Y7iAKQotBRsZmrwiFwc2C u5C4sN1ix+03EhQZ7Z55vEMULwSXFJzM+2PQOcdG8B33UpmiT+yUPa6X9j7lxTdNXYnna09vlaqB d8B6nlwTzQoxInfaSIi6L1amcIBK2UQHnMsULBD0fkOh7NoEBNe34DqZMDQL9YpMtzvWDPS4YeVm IT/5t8i5TsET7QSxkF7ceV0tpP4qLzw1lG6bZw+qviko98PZOeS5xfGoi13H04la3noVjwvZ5fxM nOvWIynQ1VuxSb06sh4azk5OVpcB8HR+uLMP4XxhS+Aed0Ob4bl++no3cncjdzdydyP338bIHU1u 8xfzReWxsvtkfnnj4zmv8UXV3MmWPG9wRHUt8aE8XvBCdXbh+XeceLMi4u3u0TFNemHdlF92ReU6 zehWwgvrpvyCLyqwizxfdUxzPdGhGL+cH6pIF+cRB/aft2R66+OKQn8U+5IdvQ24fbnx6sPofMMH FbzwjZxwYE2vj4tAO4/totTRTy8JaWKAStD4uytm0xZXZouBgI2bzNP2qBNsoCIkL9hR7hRB4FyG 97yAzIh6gmZxPRQu4rKLbDWmAgPFuke21TQJdY41TGqzBfr+j2He6YlZiGbeGGqsf+YWAVCIk1+Y MRzui18vOcIDfKL3cSDZThCy8sIqO/Gikwk9wk1inUj2cLZCjBhR9s3CPTC2QuOQcEGAlEVAEfju QaRzEhYfifziB0VH3mZjwwlFtZNXZD1gYzNK6apqmqSBBpDS2x0uEDCQ6VIKUSOCJ40NaTKxCAE3 IogSUexbzmF6CxkE0AeBkxneIYKAnHJGM8b5ZIs1yiRE1Q+zmMhnZNRfJc1LGEGpoWup7UQPlOJE s3EyttcxoOhzIGwLPwnWReCqWwQWrw2OZrw2oqmfjuUOQpaesS2SBOg5PYlpNlz2ki89YHL2YFUR Il/zlRvnC0Uis6my5IuZ9Iacn5FJ8JrSBEkUt0k08VBYSJONbnZIHdCsUq1zNkf9KTNykULZnDtJ 2bwmONKtGRMdOvTVAaXRdet//bx0BxNtXSJkNgqdE2oCXd2ZYgral8/qtV2LBYHSpgzQmdGnJYOs juklsNKmcbDIwmj7HNQ/64xLVKxL7whJxbad+Qo0CrrqY5FZ1Txln2UnVUxM06LOVmuyxqp4F8oy bthODHzgOZVH9niKXsHODC44jDvjTbMUNbXmrjlQUWPAloY4O6cNA3FaP9hWIOtPfaL3W/cR4UmE 2rf4mR0v8GE0EA1nNF9cICSlhpqmPNnqG1idxQij94Q6SzJCPs2c0BG3gmKaPoSMj0ivRZPH2aP3 FuD6yeN9cL0PrvfB9T643gfX++B6H1z/HYPr0UK+fCmvefiic3q2mL6+OVRe4zFvKCG0IEUa/def pd9IfyiSqx7zDhyVx6jd58T92dcfq5cX/efxNPmihBe2h8oL/vO6XGqWwuuxn+8/72a6Q0G+2X9e Cxcf0M5e+7gtPzvcvq5fb72THsvluXr2GrFKhKXbXea9uj9VrjvQy5jgeV43SjxzymaMRQAKuo2E O1x6KUPEsRKEZATPYAyznXORrEdIRHVGLrrnFJVzteAglIjkpYYEsREsspIGv0d6aTEJjSUOk5Uj N70/JSjJJQE5RvPyqdIiN8l3zMQ4hQReIzfDZz2ijsi2aoJQlhQiL3tPCdnUahNg1FmYyTfGKcCk nOsEFrelfaixzJSJk5Zdxmk1o2dwiBtP9AW0Z5kes1aNEueMs7a8rbcXhq51TFnxjduS40LWMkZo HDWfLgmnmdUAI/osqXkbiSYjjfObySRQWXUASjMyqtj4iHFWv/klmubsu21Tco1zxinVDdUJLC5a ZAtNcY9ifJYxP4mqhlb54kY6smNWKjTrIvWa9ZT27cQg5ZxSMtWWADeQV1x9ZjZwUr26xieE1SI7 wml2OyvLeuXGinVa49Q6tNXC+vtWSTMHJgMzFc0vM7IJzqyMydUs0IYonNUkgZ6dV3DhdG1DJV/k XIwHhokBsaNJ5Y7bwlnOrAw/groqWqayTTkULqSmmArXGybBDeQVt+xNz0YIYivUzdCV2TXDqgAY mWZSTE4TqjrsLGyZ5jiK62lN/BLNznZLctO0S6qb2d9Ghav7IPfB4z543AeP++BxHzzug8ftweNw LfalXBJmfO+ufbogurHWf41PQlfnlyTKW9b6t9IfiaW+6JMwe26uJ107e6V3/PqiQ8IcK/Rnl/0L q/sabgpwrMvXg6t2IMBjsd1KdSi2F3ctWoIlTI6f7n4utdsyu3pDZ+WN051d1i9JLO+0XboeOizH 0POReqr8k34yhg94QPS04qcQnwWoc+Db09xb8WiJOKwVd1hwfZHfjxgmmV/j4ZUyvMOWZcfTk0TC /EQMXNt6Z5cw+XkMvNsu2O62V2z2kLtlZYDtY/gFjd5uoqJxR+/78nV8ocuNFvmXUzv9+uep9Xes 9KdNXrYm/2bKA85pbsmjRc9sZwLfUntFq4fKoyIPRwE8chk9u/QTfTXryCXiNc8Je1v6dlAK9HUr f72MQK/cuMqmW6C4G5U7Yjj58g6lmYuhKBldNPyXr+nntv3PVfdrzV8vNm39803b1Dg4e3rmoAlx sE4O1ulEoZTTu/e/eXh32660o0dQcPi0z3lQkdVPj748fHj/2B7+8MOPj9/EYQPjw/97DOHhwx9v FtKPBo16wfwL9q+5oyyau+TzNw9/+v33j+XhTzez8kdeez2V4xUMhcNc8GncveDQEGqHf77NVDzK LvB08tOGuM1ZOsyK59hXWLvZei0f5Rd52Ppa1sqRtpkiy4e2RP/bhz8M1frxA5Ts9PiNjw9/+N34 lx5++3gC7U+//3C7oHqocfTLdFHQnx59fvj+J/z94TE9fHjMLyjPUX8p+NJyel6DP/728WZOR50C YnXhMqebFe23vZ0knbsM0/aaQ5LriY7mUf3N3k6enZCkWuh+r7VLbyfXT0j6Wy+GD7sc2kXRevBR yuVD2nj1hKRfd3eSuj4OTi9JnEXARVWbhNT5XW6AQJCEdIoPAjgBYYTy2gBACkT4vDf8m+nreXDh FEkY4xBQVbBX5E6kmFSooI+SAcEnnDovUBKYUZOikr+oInhrgigLhRk5K3JSTkUgCniiuDIuyioq 46Ji8eHEzoNnIL9FVl7+tANuh6KeCu0wvo04c4oYvFcp8VwueIiowGKRF1ZYly606laJhwYSKSfV LSth2ISmuFabpFKCIsc+kUW+CPUWKn6dSpE/RjRj6xvDo4lVGymHlakLDdQPJe7SrG5Ck9IVNblf eha65I+Wk2etzu8JUIHjRIjc6K5xBusRPpMKOTWks8htyhjf5kRvFpcZqPI1CSotITdepQ+d82wg 5kxFByKL3jRzYB+JR2IgPO/qdBA2kR7gW2QjOEVG0sGMAL6L3qrdc2OxiQSxCHUao1IzhoVSmbWD d8XGSyWs61CExpdUFEUkKmHKDZZgEJIk1RU8hVwnei8rASHPYM8+CtTVfIXI+rOCipdV6ET49idM gsLsO6Kdr/fIryJbdbx02nuisMxEUHAsS3FRd3U78luWakYVtYJzvkBNGW2dVEUNazC7IVBaXVab hjOyigoWrLy8JRVTrs3IEmNX/xEwMydQ82XMkneBue7BKr+vZpvl58W6WiIuE1jUxqFsNaM30VXr vDNrWXn5uGyKrgRMwwu07AS6YeMtJLMabVlwtlya6t6DdAuOC9jMrECaVgOeSFvaGRWfSAjSraZg L4QuCBSmoVBJ6EcYyQD4i50oTUVnTRK7RKszA3YXRpujgHV4ftlI/VJomAXMBKtkOzsbFYSNmxjs pEM0JbwqhE5r33xtHENBYOSsrtdkWAzRd4dFTrIeGOWkBkF1B4JA0LEmF05WybiQkcWA2HjVgsZv VS9oQMyySgKsHZ8bcrTOU2hOwzdaSZ5E1iRhP4e4ep52n2rcpxr3qcZ9qnGfatynGvepxn2q8aWm Gof7PF/MaVmTvXm+2XL99LW/wmtZ0t3e6KLOm197+nor/aFYrnotO7hpnWql7w6He/yvv2jdX/Zf 1nW+vwp4af/wtvsybNKHWjCQf/7+4Y1EhwJ8s+uyEC8fw+fOpuPcYX+FP119D+/dW58O4EnXxR1r TGJHtTkE7oq+qtPeXfddVtB88GVAByEfRegT46wCr7Ecp+9A3hBNLo8yPAnDMBMpKZw7ej0Oct76 OgjJIivnZMEClSDXGVeBWVGzEqZ+gVa+nLbyMyBPFwS4f2RWBGkWRLRqYBYziueklDHNGhCFVd0u wsnqDhD6FA3RqoEzwqgghUqQTyZyQ+8l8uL3wanvU8a+z9j1yQTKdX1yEQngzX9jGIRVHddl8FVV Z2Z6ScJ1rcokKNeXAO2nntYBmeyfdkicOL/azHGGumtRlW7tDb42VQCqe01BpeJSJEhgUzJIx+91 0HVTFWgoJBmW9l7o9tWV7b0L3LvAn1MXOBoZvftSjo9yVws8H56uT7m8e4Xro4ypqHzv0Bny67/C ez39sWBevF+Vuy6A4uJNecNUy7sXfR4VX/hUdSvihcmWd7edHuHUl5eKh5DSKyZct9MdC/DNvo+e HdqaS20sVD7nxNa7t97h1OeMdgXj+itehu5nW1ePa7277vloCAN2uUR+seijCEPCRgCqVcgTNSG5 Z3Nyzo7VAi4PNWwFlagPyLWzsvUWlS+cC1b8Cg0ExUAk0r4ECcwoz7gsJONT2huSNwAjZGwE8OLT JCT2UMs8Y1YcxBWu8I+F4mKL18KHrQ+sX8dV79HRo+pO5CZfFStIvKXGPTfHDxbh6TRzpsdDPu62 yLwQitffuEQHr4ZCDjnTn6AhRuaaehfMrAI+LzNAEEorLrRuEOAR0PGzaHiz7RIRg/B9KcbllTwQ +MU5XtECj1Epk1DrM3IkIVtwYF6ZLS/H8vCUUGZkVahk5ew7EZWG28t8cx5mZM/UNVswWa5d5Xhm 1NJiQ9hCeSv83Iu4QNXhei/NuCLgK0tElQgfeV8IF/xmZBJS3OeVY1vlQAfjjouhv64tHqH3WYhK 1EJecalEbQYzq25yow71lS2fcpx7tlBFtdrFNNFskIvgpKTWPJkZt76YyIzcLOfC2jUqFE8gcrQd OqoJcekQG3MtuMw5dEtVKy5PZQuUWSYL3KmjzBS5+IkscvP74C4Bs5MXOv5HR0uzfwT1PAuOxmEh SlWV8zNyZp92QcEjTYYGqueNjpChzavnVXb50hS54h7tufe8EPYYy4pcpj15uiAYJ7J/MkV0ZLq3 VAU1LlslWt5sXIEG7E1gmdYy0XqYsaTppDfVC8OK0Wwzu7HsTfJmsa+uIe6G/W7Y74b9btjvhv2/ smE/XL/4L+XypRe+drxcR9xYFvtXOH3hSVTEe4DO18avXRbfSn8slateX+aaFYdFQ68q30i9YVXs X3w0NaLwizirhJcWxf62qxe8XZNVcfFVpxA30x2L7+2+Xp59yWTYCFjNSq9bu/Vpu65Xb3b2wu+N 7ou2CzKXn2/JV7+h4v0NZy+JO4C1nekeDxDfNwLE71Hc+J0xRsMTnJBuiGT4rqoklBGc6YAaCB/N ytyiBLJHq3IzBwLsdeanvCueylShSGQvSeUjCwRnwUwaS9kjzVQmAZcN9P44c9yxGEZIzB8fryJi BgmDeuZABCSnWiSobHwpLPPiEtjGmJ/pag5IAzgIVZXOygufi4OEVE5nqblZrXgWT3EO8z+Q5FX4 O1obWMRUtqC8tYE+2bNvgwybu9ogTwaSShCzwc+4XTXDy+bMOw5AGGkzT8OBdH+EBMmsW3BSE+zB bIFJwEfMtpS+lF0xri8mWG3nxSI0bMxbMX2xymDObuINF+3Kk/PRz1tpk6ATyOrF1rASpXIuTKSd slwmk5h5VxybP+0xDDARs4r41NxKHPqShvIObGd+rgEIU9vMqQGQ80sczNnXJWcgfFoOFRZKcTWg CEESKEXIq+0nsLih70OHThbeRYL6MdM21bKJgyK1rEJsysQvwmGEXjpcrLLS2swyIlUonZVzcvGy s7lmfUt7+opxQcCKxXoyUAizo6OollZ2xowZDSYNvk4TQrbLjOxVzarIJmXIVcZpJ1fZrilXWbUp OZm8nWDlyHIXHPM+acjPcjY2rODZ2LKY7oJn+BItq0pAW3Xlz28njdSs2Sgsuc+cglxotoQIOyu3 EYplXpcJVVE7CytOpgEWl9M4qxI72606TtOu+k+TI/HsLJKktxs0ZGzLaT/SXF3Q34ej+3B0H47u w9F9OLoPR//Rw9HxivGLeaRJ9Av1fNV2ayPiNR5p4L75hCuvdLrz6uP568kPpRJedkgTeQMVd4ff tg8RXnZKk6k1uyJe2ogIYdd+5lQCG96f439kua2I2Af4bH8bcETUdVFXJxQZDiJwE4JO2p9E8LqO 6mWzauSVnabv92V+oVmvGupM0Lue7pgDqKSXDg7zgSuOVr5kRW852fi5KvzdsZMNH+LW5rNqvXGH 9UgW3+x79U4apQ2T9DzwpnudzoEYDkKK5OCTvtzXsZuNWviqz/7hc14iFHq7L5yygIADn06n1Sow e336ocTprUZPcSJ2o9pVVytftr6f7WrnZ5PAVV1In/R/V+NNLzRb5Q3mGPJrvCxhwlVPofAjF3i/ F3n0FEI1f3kp8rgghGzfBUmB49+YzZ2DcMUjgch7ZsR8eBD0zQkQMj+aHeDs7Fr3/3L1/Ozm/3lq vmv7/w9/McpWDQplbmRzdHJlYW0NCmVuZG9iag0KNjIgMCBvYmoNCjw8L1R5cGUvUGFnZS9QYXJl bnQgMiAwIFIvUmVzb3VyY2VzPDwvRm9udDw8L0YxIDUgMCBSL0YyIDM4IDAgUj4+L0V4dEdTdGF0 ZTw8L0dTNyA3IDAgUj4+L1hPYmplY3Q8PC9JbWFnZTE0IDE0IDAgUi9JbWFnZTEyIDEyIDAgUi9J bWFnZTE2IDE2IDAgUi9JbWFnZTE4IDE4IDAgUi9JbWFnZTIwIDIwIDAgUi9JbWFnZTIyIDIyIDAg Ui9JbWFnZTI0IDI0IDAgUi9JbWFnZTI2IDI2IDAgUi9JbWFnZTMwIDMwIDAgUi9JbWFnZTMyIDMy IDAgUi9JbWFnZTM0IDM0IDAgUi9JbWFnZTM2IDM2IDAgUi9JbWFnZTU2IDU2IDAgUi9JbWFnZTQy IDQyIDAgUi9JbWFnZTQ0IDQ0IDAgUi9JbWFnZTQ2IDQ2IDAgUi9JbWFnZTQ4IDQ4IDAgUi9JbWFn ZTUwIDUwIDAgUj4+L1Byb2NTZXRbL1BERi9UZXh0L0ltYWdlQi9JbWFnZUMvSW1hZ2VJXSA+Pi9N ZWRpYUJveFsgMCAwIDcyMCA1NDBdIC9Db250ZW50cyA2MyAwIFIvR3JvdXA8PC9UeXBlL0dyb3Vw L1MvVHJhbnNwYXJlbmN5L0NTL0RldmljZVJHQj4+L1RhYnMvUy9TdHJ1Y3RQYXJlbnRzIDU+Pg0K ZW5kb2JqDQo2MyAwIG9iag0KPDwvRmlsdGVyL0ZsYXRlRGVjb2RlL0xlbmd0aCA5ODYzPj4NCnN0 cmVhbQ0KeJztfduObEdy3TsB/kM99hHMYt4vgCBAmpEFGR7I1tDwg+AH4pjDkdyHgjgjzO8711qR uXf12VXdXUOJlqdeumtF3iIjIyPvsU9f/7fTn//517/6xd/+8uT+4i9Of/XLX5z+5csv3MmdnXM+ BFdPNbhTTu7043dffvE//+z0w5df+NP3K45zxbt0Eek3f/blF//9yy9Of/2rX5xOuwL81//12x++ Pz1998NX/+PXH6y0v/rmyy++/s/+lNLZlXT65jfIfuR98icfyzmPkNzOuZ+++YQyR8Ff/82v6+n7 3wH9zZdf/MPTNx9qf/r2xw8+PX3/oT199yE//f707Q+/+xCf/vDBu6fvRlB5+t3pD4Pwj7//7emX H7x/+ssPPj793Yf/dfrmv3z5xV9/c8BtuMbtZC+3eM5tz94/PJ1u5RgtE3cumSKM/RxrPMWSzyWe +vgbyqn4c6t5CTKcW2jp9IdR3XMII+2IPf7m5E9/P6o/+Pin06sZ/fqAm3RUv3+51a5q/NDPtVAE aRTQTjWdQzvFIYwBPg4pfP23n779/jufTr/859ORGuQ7C475nHblllHnMqocUPyu3HCt3HJULtuh 5XOoadShn1s/fdoRylDK0/MglHMdbbYj1LNPfRIGSj0SeYDaBMLp44jazq4Kx9MA0WeCRJRdIyre 4lYXSKgNwS2JjU7UI5JWKAIi97MLIqR8AqqeaPzboZHUIpPQrOBuiBnXGlh9P7nI5LifU0BwiJ1o dFBkXwnGv48URAkmu0BB5CbEuEuuxSK7pqxGC45qtVSn2AfKqU00Iv92xE/niBp2P6TNhhlyGSwZ Qe3gQp8EFFiaUFzMAPnJa7LICG3KabQAxFQNVRNB8iC4c+9sCP5uFZL1sRJVb5JNqGVHr0RwzYUo RqDeMpFjM4wfwUu0Q0cQCcEDjaQDpS7pqIEHoTByg0iArM1y3KNRcYs8278w2HfpRgDKvhL5mXPy 0qzmERxKIcoZaOnr1LNWTdfbiWqAdspsQ1ieTrSk4Z0IkMbg3FUigsSMM7sshVyKF4FRo4CnfrIP pdEuM1sqf6JiDQlRC9O5dKDEItM5T4ZhH0GIjFxYu0QV6dY747lPhjvhUBxUnXKK6CQD+ZiITMRD bzIIDmb2mYQAIzQIkPJA1O4hzgoUoUED+W6po0X2DKXujxLTQrVD2yzuJGQGxyZEEDxBqzOuiyJE MjFGCCICp2xqmzVIyglKMrQdkgGi+vWijEcrSUlaVlaVOlShMkBUmQyjIKTIQ0F2waGEXVJvPK2c XWmzYLRA95MpoGhJ+1I/Fdxo2FpQ0kajV3sxyShuLYrb1daSOH+yK7mtg5eCBgijv9KSjG6V1Nqw 6Oj/hShSczEIA+VuqX0OGvUyrUeXho3MYVjYt8bAmKfZQY0GIckqedNWGh5fFVbUJ4atD8qr0kQW dYPRtBhQWp7o426YIuF5I0iPXhAGnwNZC3eCmHZ6BIJrU4/QDUtdUh/I+32j5LPLZbVZwihDkAFa i7vWZlXKVAbUdCqDB8q+7fQIfbaGXXDIu5Q+v8jY5brKHT269sXSQOGC49FUppKo0ECzF0Wg2ute FoMw5cZQS9nzBZoZk4AuESj0jSC2WrCRhOV2DWCzAmhfdMTO+m1D2cXQp+HwN5gOOkwA/4Bp6Jj+ PaYuj6nLY+rymLo8pi6Pqctj6vKYuvw/O3U52oGqP9UOVIdx/3wn6OoOVDsqeBjGkcuo9xj7hkEY g+2P349ZFoaSdgoBPeNU6jm/c4PulRyO5NLvlIvPFT1xE8wwoNgjC6nsxVKuicW7Owse9cnlolyP oS6EYTX2JberJR9uDXNvLvhRqVGHHGCgPm2EFCHuZxDGkOpfEIYJNUIIDlMDoDFGhzD0VSixC4Bg wcNmAHVlPvpLCGHMe0NKNpsALiJUBqKuadgXoKh8s3VwEFB6wtQZIPJ3rwtUDCAWE7ixrWYyzJiV 60iRxjShTA56IGH0YPIzWMgOs2hyW4hampHH6Bqylxz8mO4SZSEvNLlwMxgCgAjblDolPIH6c/AF Ri7kCNl8slZok/CsDMdcwggsj0C/qzLvi9GkNi5dlY5ETMiWAl9tiQttMwiUV4LwRp1rJxiTHCDN mkGoJr/I4DHJgWxL2dDolzMuccHkeqXMFAcy9kQhzMihUBOSOGZS7oGTY+njqh3aMgVYUbaSENQO jSIU/WwGiwzBD+SQsWeVh4jRZkIft0YQ4VmEXLf4hXoxjDZ+Wqmuz6TsNOE8uiWQz2Ij7VGuMzII o0VGcc8XhK74QY3rV0kAqyRwgaZXSXnTigsturrIfdiAhw142IA/IRtwNCvyhweyd0wXQ6yYkn82 O7k6XfTxeL4YRr2xc4HpXh1FcL7YKxtTUyKey0KKb58t3kh/KJXDY1wdqofTaNb9gTrmg+ginITi wJozLK9j9L//EJ/+0z/eOr/2hye3+yPxEApt0irglRNxX25OvmMZOlFPmNfmw7n3sQxvJjsU4r0r kc9m3Fw5p5Fh5pr4LZPuw8XIG8rO7WXR3I/xOXG/bhU9El4r+nChYTcTxiLZD+Yi/o28ksOO0iQ8 G6FOAlBgfP3M42ew/S8SmgiZwTEIKV1UZG2zkqDITcGJYAxQBJ6o5Bk3RRJimTwZIaikpJJ83qd2 iy3k7aGxq1iPoXVx5W1NvZj2GBdWhTx606qvh5mZ9fUiiGvKyWNSsMTobYoAQY/BxQjPG6FWSIQE LORf4DQJRE1IlXRBKE5expSEBInTKa8xrpEXRa4rslfkoVmTcSDV2aucnFZk5TWGbdaZIO5BWFGF vWWkdC5u2RYbzlapBaJfHJXJPhkuO0mzPhxBVl0LZnFLFAVb/x9NbiqKOxwmxYFOU8T4vWsT4n2T UB1eEJBVBvNAtQlFobxyE/YMbUpZFLcJrIJrEiExtFQhlZIN+Rk5KXXuDI7KOCvjMIHFdbvQpLpb Su5L7zNOi4vA4MlFEvIXLCfMYVaFOEdalU2TwymKBGVZkkqYFCwpbqiuyDINsUvqi2B8ZfVny6uo 52+pq1mhojq2aawujdvVVcfDBj5s4MMGPmzgn4wNPJoah3v3hF+uupKPh9PT68uucLgpfLzsijVB IB6nhvmOZdet9IdiefV2ME/Bhs6P9RxWYS8XW7dXWuFwxbnPPrnErr1l/8pSK6SbS600bNqw+j53 tNLb11q30x2K7t77v58ttkrDLta0sW9Ya4XDK8BvWWv1s98rc6ES+5xpV7el1tW7x+FwhUmNqI0n sL7RiHzSMSKspwjPJKQ0MUALQjxqywaCncrl3EhIPJXLrQvxpLN45ZssbokqODLfAiPWeJ27yeAB zNO+0sQDbqfg7oKKdTu0riVshMZzUCWNdipaNGMq8xxUxUbsdyyWorFfbL6VJseqT4Q5XHWNxn9W mXFmLDlxy3eKELusS74AIyYP3Ivh5w3rrHYeil5i3AwxAlDqQjqchZUdqMwjVhyKk6Cj3WzBTNo5 7HQboyBQ70Ugoy4SpEqQFBT7OkFWsKJmMRH8Hq2zWuLGG0EzYTv3LduGAcjiKlDn4eKHew2L3WbT iVUbvoBYNW1syimIZpOlJSf22iXDhhFsSphg1yQi7NuE7Wh9IqdLQsaAJgJ7hwVH9YMgNJVOMErV LaeYpK2RKEwxV6/IgcGwm0CeSSvH67TkjAtUwI5n/pXFQC57NJt6YjauEkbMLFa2EVpgcVlq5G25 yVGc7DeFxa1HJRKsIyuuuJcc4ryGN8XEjdolwmiVS5aPJ8fTUInwTEKzzAcBGhOt3AhUvJB2dQch dRGGvgFZ5DGh26FZEjFvHFhJIiRMjGdW6MhbSeB3llQtcmZJZFLW89LYXl36PWzywyY/bPLDJj9s 8s9kkw8XDveelLxcio41Exr25ez9xkr08KDkeCWacfEdC7OA5d/7V6K30h9JJR4u0PdLxYIL86O+ veHY8/3HfvHqu91ZAq6UXpbw2kvYcPvSXY/YfanYRSrvWIzeTncovcOF9l137TyvwfaElxNvWIvG e9/fokYXd+0aTFkN5/0lv3BVl+Ph8ltX7ULjpq3jLtgnEUYXMUIY/Qh7iwPh9D7wPgXQvETD26kk jMhRu5bO8ybAQEkZ2d2JQagi4DZD5FMFIIeknrujztlrChCiCLiOMRCGSud4WSeSN6C8Io92ICEw mOVwU5yoEskuk6Ccg4Kb8sKFC6Fu17M3WJsFApQuhkcuQK6sbBmcgwUXIFyBEEMdM4a84gYSovIt zCp0Q5morowLI4csfjOLCUnF5DSRRR6TlF1wVF69ThmDJz3uAMEx5+w7G0TVS2odvNrAs5k6Gy8w q47GG+2OmSWkFomyBO7zVAsqguNlmaFR1gCewC/EuHUmjnaZQC0ZCBJZ0oFKCBmBYAosDpQl4pCJ AuviwroC1IYkMCpVXvwYKjOQt8tDeABRbbrHWz0J2AVdFxrc93JOYYE8mrPPuCI4u1oEsWAq25Tv QGP4jGVGLiSEqshjwksr38RxB0o+zOohcuAzKVTe8VlGjRJFJsqmxUNsruipReJF48JXGoFo9OkJ PqpL57wP5bMMPElBSwVlU/xsusJnGQk3s9DODM5DgakDYknrgEnIvNf+LK7kjGBHyIsANHIdyDtD Hii4OusUGRxdYfBgF7v9uJ+2UKlLACLUlnbBjffBKvU+c1q8y3mINKrgMWMbyLuw2Ch8ImGRR/0G IcAyAVUiu9FN1Qhlr71dTx2ImDH7mwlDyPpbyJPwbEbOr/hAbeWFnpz2RaGvLz4i7wqRRxkFmAhU YbMZVTWUSaksxu2sEY5yNoPIVmzNLFeTXOsOleb3Zg4PftqsgwgeF+bM7nk69iDiQ528Sip8sdV2 xgujguoQGbnkZZ30FKxqMOl88JSaBhq92oltDS2JWYUm4+X5psx3qXhjUh/qVPHM92l4EgLEt1PO JQ13fLTTS5tdR88TO4a0gfDCEEZQdk0vtIBMGULZggsVB8XIWlVyEUOavd2Ri9xlnyiYTjXi2g99 0AbDEK0Dd7scOub5w05kXlHkLUOYmG6Rg01KHG0z7xviVIhXFIUyF/sWOVOrctbVVoxEVRPQwDMk 2MzZP7l66U0X/aMNS6no2r/XwFmXmbQxmhcleS6n0Z1mXNMAk3FBe3ASYd2+bPOP/fTk6t7NYxbz mMU8ZjGPWcxjFvOYxTxmMY9ZzH+AWczhztS9dxU+e+6QYNhfbhBd3+yMh1cVjjc7g0ua8vBk5f2b nbfSHwrlcAv44gWCx+Pvkx//hnjv2Ow83Oq9KCEmNudWwiubncm98sjBwflhH8bgPU8criY6kls6 3MK974GD4wWY+NY7N+neZzuRh0a7kmsBIfkXd26ul3y4t6vnDXS2cKpDoo5ecyKe3dRJeBZhTGiN QMT4Cc4COp6LAVS7VVlhP0CAox0gZpXgtWGgDhDLjNqZbYRzCyAmxAhIlIF8jityhaPDlhdTItRk 8QtQsWJH6oGypnWW+SCkZkUFomCR6UGx+lUDZhwttDElfTawtgBlxa0sdjJdmW+A6weJ0dBHu6+4 CM+LkDs1+pLg7T5kAaKTlE4dANIxEgmeBKfgyKS+6g5nZJifFz45kwUhKudRQObzOQAn4OxWJs5R QXBw54H5Lrlw8AaBU4UwkUXObR8slmfSWF7kHMoqN04myFIEcc8xHXisCkUsZlZl44UgeLN8yYnj 2pLhQiWvyGXfCFL/FwS/WhFuZ+pq4cb5804BQFjaAYc1ZWmOvAHtFAuETe2AlkbC903bKyy9ES19 bnzvOnV9oZa3yCR0y4pdjq5ZlPGuH7HY2cvE0eyBYnjrn6rO7Lys6ezXksOu20tM0yhIhNNgXBiY q3sVDzv0sEMPO/SwQ/+uduhwgvhTeYOWQ7SXk7Trq410eBx97ZI/dxtwlyTds9q4lf5QKIdLsMtL /t7uMsGv3PtXG+lwrXV5z58O23YlvLbaaLevVhReIovxfU+qbyY7lN1P5sTIN3rQivnNT6rz3X6M 6DVjXzTtfowv3qzEq0+q8w1HRi5glIh42c9jCT3GQ73kAQ2LYbh82xF2KZ7lcmOQ4IOr0EB/EgF+ 0UQAqmWP0CUL3ZJgX8Lp7U/hUxwgbygKMfKMGeRdHRu7jjfGiLKQhc24ibAVBqYoJKCY5mDEwa3m qGLAlvmzCMgZbkWy/FWNrOB/JO2R3kWSkEmo5twqCgUi+NbL3pzRkaDgory8khb5QXCGFLegQOBh 1YEw7G0IAhayyCnug61cQ75dZgzrPovN2O0gCkKLQUbGXq8IhcHNgruQuLDNYsfdNxIUGe2eebpD FC8ElxSczPlj0DHHRvAd11KZok/slD1ul/Y+5cUnTV2J52NPb5WqgVfAep5cE80KMSI32kiIui5W pnCAStlEB5zLFCwQ9H5DoezaBATXt+A6mTA0C/WKTK871gx0uGHlZiE/+bfIuU7BE+0EsZAe3Hnd LKT+Ki+8NJRum2MPqr4pKLfD2TnkuMXxpItdx9OHWt56FU8L2eX8TJzr1iMp0NVbsUe9OrLeGc5O TlaXAfD0fbizD+F8YUvgHXdDm+G5fvj6MHIPI/cwcg8j9/+NkTua3OafzBWVx8Lus/nljW/nvMcV VXMnW/Lc4YfqWuJDebzihOrswosvO3VerIh4unt0SpNeWTfl1z1RuU4zupXwyropv+KKCuwiz3ed 0lxPdCjGn84NVaSH84jz+rctme59W1HojmJfsqOzAbcvN159F51vuKCCE76RE86r6fRxEWjnsVuU OvrpJSFNDFAJGn93xWza4cpsMRCwb5N52B51gA1UhOQEO8qbIgicy/CaF5AZUU/QLK6HwkXcdZGt xlRgoFj3yHaaJqHOsYZJbbZA1/8xzCs9MQvRzBtDjfXP3CIACnHyCzOGs33x6yVHOIBPdD4OJNsJ QlZeWGUn3nMyoUd4SawTyR7OVogRI8q+WbgFxlZoHBIuCJCyCCgCnz2I9E3C4iORX/yg6MjLbGw4 oah28oqs92tsRildVU2TNNAAUnq7wgUCBjLdSSFqRHCksSFNJhYh4EIEUSKKfcs5TGchgwD6IHAy wytEEJBTzmjGOF9ssUaZhKj6YRYT+YqM+qukeQkjKDV0LbWd6IFSnGg2TsbuOgYUfQ2EbeEnwboI PHWLwOK1wdGM10Y09dOx3EHI0jO2RZIAPacnMc2Gy17ypQNMzh6sKkLkaz5y43yhSGQ2VZZ8MZPe kPMzMgleU5ogieIyiSYeCgtpstHNDqkDmlWqdc7mqD9lRi5SKJtzJymb1wRHujVjokOHvjqgNLpu /a+fl+5goq07hMxGoXNCTaCbO1NMQdvyWb22a7EgUNqUAToz+rRkkNUxvQRW2jQOFlkYbZ+D+med cYmKdekdIanYtjNfgUZBN30sMquap+yz7KSKiWla1NlqTdZYFe9CWcYN24mB7zun8sgeT9Er2JnB BYdxZ7xplqKm1tw0BypqDNjSEGfntGEgTusH2wpk/alP9HHrPiI8i1D7Fj+z4wW+iwai4YzmiguE pNRQ05QnW30Dq7MYYfSeUGdJRsinmRM64lZQTNOFkPER6bRo8jh79N4CXD94fAyuj8H1Mbg+BtfH 4PoYXB+D6x8xuB4t5MtP5TQPH3ROLxbT1zeHynsc5g0lhBakSKP//rP0G+kPRXLVYd6Bn/IYtfuc uD/7/mP18qr7PJ4mX5TwyvZQecV9nvIL1b3Hd971RIcivNtxXgsXX85OtfBVGT4Ntr+lEa9r1r2X 0SO/l7cvWgcZpVxeEIlXd6bKdc95qeubF7z8Twe9eHnRJiHxW4kEgSAJaXQCAZyAMEI5HAKkQISv VuDZjpzC4mVCJGGMNkBVwV6RO5FicioS5GsTCE+d+FaBKAnMqElRyV9UEZwNEGWhMCNnRU7KqQhE AU8UV8ZFWUVlXFQs/AF3GlQgv0VWXv60A26Hoo7Adhguf2dOEfOZVUo8lwseIiqwWOREjHXpQqtu lXhoIJFyUt2yEoZNaIprtUkqJShy7BNZ5ItQb6Hi16kUPTNEM7a+MRzOKqVIOaxMDdTUDyXu0qxu QpPSFTW5X3oWuuSPltODkU43OVTgOBEiN75CnMG6W8akQk4N6SxymzKGy2n0ZnGZgfjxVCB9gg0E fCam8yAGiDlT0YHIojfNxJf9IvFIDIRjS37icyHdK7PIRnCKjKT4BqHyHWW2aus3FptIEItQJ3zH 0xgWSmXWDo8GGydLrOtQhMYTQooiEpUw5QZLgG91SlJdwVPIdaKPshIQ8gz27KNAXc1XiKw/K6h4 WYVOBJfWMAkKM/fYnafS5FeRrTpeOu09UVhmIig4lqW4qLu6HfktSzWjilrBOV+gpoy2TqqihjWY 3RAorS4LNrbIKipYsPLyllRMuTYjS4xd/UfAzJxAzZcxS94F5roHq/y+mm2Wnxfraom4TGBRG4ey 1YyPZFet886sZeXl47Ip+PKj2WGFuWUn0A0bZ9dmNdqy4Gy5NNW960M+vJDHZmYF0rQaeGDb0s6o +ERCkG41BXshdEGgMA2FSkI/wkgGwF/sRGkqOmuS2CVanRmwuzDaHAWsw9Nhn/ql0DALqRXpal6d jQrCxk0MdtIhmhJOgdFpzZV54xgKAiNndb0mw2KIV1ItcpL1wCgnNQiqOxAEgo41uXCySsaFjCwG RH5wWcZvVS9oQMyySgKsHY/ROVrnKTSn4RutpAuya5Kwn0Nc3S97TDUeU43HVOMx1XhMNR5TjcdU 4zHV+KmmGof7PD+Vn9PUZG9ebrbc2EF8h6PTNLLFFqWL3G1+9w7irfRHYqmvOjpN+J5O5Y2reseu YX3Vz2mCd5J9Aa9sGtZwU4Klbs8424EEj+V2K9Wh3F7dDMXXjfCRpoix8w65Xb39Nwvo7FG7Al6T W96U/ivTeZeH1YC+j+RT9Z/1kzF8wOvE5y3BkLV/EaRuQrdMeBBX0BZDrLwsGTjz4a1ieg3jR508 Pxtb6BYG33SEJdPlaxCaPsyb6cjlWfus8GSjzwiT4DjxT3kS5FxHl1d12R0NPbriv0lNX+mCo23+ 6dROv/r5Kv9r1v3z9i8H7Z/G1O2KVPbC8GmUtreTt9sd9hqjVYRXInr6F4HH6jzUxUCF07NFwAIO p/yZAz4I8OhS9zFGiB2BXRCslKsN/0dX8a0N/vPV+lqL189bPMLx1RvEUVtsotxoZ3sf7r2zGs8v 1OHKRpmP2vPJ64iTH9LjxBluwu1jfw0TFySIWQQe34CQw0wBr+eOK6trrXxvtd7atj9XTa+1bNtN YEx/G564X5fAEtRYfLzarpjqxBM82I+JGN4KVb6Sp9801jZUelLnKlzvQkqT0yHeQmEMnod5x7sX JOTpvyknHSBjMYFPN7j2WcP+cbV6c7P+XBW91q798x6b8KmCN6h2wHcjXmtZfodg8Oa5sMGghK+K U0t1qu+9vn6X+QCMBF778YXXVTjiyItm4WKJMTr2RHyZqs8PMo4YI+t+tcfeW603D78/U02vtGxz n7es7yPbYxF89WIkmin8WPi+DLvZ3J37b43vlj6pSlE3DV2eVcL0PhX7BCUIkSOShKI7esC5iJD1 4i3a1xP5cZzOVd9BP/43qevbdeDnqf41HfCfWe0xO3lLJ3Dp1Z4dfOOjtNimh1491sG/GvRKjJtM pMuUeb4NC0N7nWKMPIY8g3fWJeD4DftcnnuHz/LXBw+7sZuxOzLad1XqrW3689XzWquGg7G4XZ2N HOp6iaG/fVmFZ718uslnQhBBydyVTm2KgFdfwnqUGTL3ehhBw1rx3KoZ9bMEgTuJie+GMWZlXr7l xz8+X1X95PV884D9M1X9WtvHiztX/uWdq+y5m+91gIRFusMugNMuwC8/+PT0lx+8f/q7351+88GX p29/+PBVfDr9879++Co9/f704atspP99a2Xf0sH2QEn05ror+pX9gZYPcpkV0JePlMunbz98FZ5+ /D8f0tPp97/9Dqyefvzg89N3H+LT7//1xx8G321WLj39zc1CyxHrpehrvrtCb7Neb98j6/oys/bG 3nGV7Ga6o22hdu8u48vbZNnrPbB2vN9ym6zd6xsmlkv/LNnr5nPhLvtWdL56m6wfbiJyvyvjoYCn 16rEI95sl3pFAApyagVXYHK4HLUN/1GRkxE8g3Fdu/NOe5Yva6I6Ixe5y4rKuVpwEEpEOjkhQWwE i6ykwe+RjgAnobHEYRBy5OPpzwlKcklAjtE+Fq3SIh9b75iJcQoJvEY+qp71iHK1sFUThLKkEOkz dErIruhvAozyqWDyjXEKMCnnOoHFbWkfaiwzZeLl913GaTWjZ3CIG088LtmzzA8vrholvj2YteVh y14Ycg80ZUVX6UuOC1nLGKHx9vXzJeE0sxpgRJ8lAcXFVifBieuolK6sOgClGRlVbPSFP6vf/BJN 4+19k2M3Qj1NqW6oTmBx0SJbKFprQzG+yDgkKzRa+eJGOrJjVio06yL1mvWU9u3EIOWcUjLVlgA3 kFdcEHgC+bzrGp8RVovsCKfZ7aws65UbK9ZpjVPr0FYL6+9bJc0cmAzMVDS/zMgmOLMyJlezQBui cFaTBC4FVnDhQcqGSr7IuRgPDBMDYkePE3bc8qh4VabwVv+saJnKNuWgI5EpJm71TQluIK+4ZW96 NkIQW6Fuhq7MrhlWBcDINJNicppQ1WFnYcs0x1FcT2vil2h2tluSm6ZdUt3M/jYqXL0f9Bg8HoPH Y/B4DB6PweMxeNwePI7WYv1e9/wvb3zkEOnR6uWC6PqNj374LuvKp20dvTObS9I7Pm17I/2hWK7e XDh4M5Y932sneTL77BbD7SsM/dUrDDny4uIu+1cW+j3fXOhnbA3VAl1++yr/RqJD+d37asuHeOnV J3fuK/Cy6P4tYrrq2Kff68sIT9Mv1vi4tHzi2dZFydc1+nBjg8pQsPEKl0z0c/ZJhD7xYIiPyh1v awN5Q7xhBwKe4jp6TSNSUrio9nrj7Lxd7QIhWWTlnCxYoBLkOuMqMCtqVsLUL9DKl7eU+TGz5wsC nFgzK4I0CyJaNbALclE8J6WMadaAKKzqdhFOVneA0KdoiFYNnBFGBSlUgnwykRv6KJEXvw9OfZ8y 9n3Grk8mUK7rk4tIgG8SbQyDsKrjuu73qarObuUtSbiuS/gSlOtLgPZTHgKATPbPOyROnF9t5ngh edeiKt3aG3xtqgBU95qCSsWlSJDApmSQjt/roOumKtBQSDIs7b3Q7asLlUcXeHSBP6UucDgu3rv/ /Nl0q6sBXg5O16db3h1uQF+Zb+HisTwI8osO755v3Uh/JBfvXr0Bm7uWHz7jLtH774p6d9UPwDpS 8YUON7YiXplpeRdvTrVwNsMl7RBSesds63a6YwHe+xmFl4cq9l0QXEt/y4mKd/f6BtA3GXcFY/EF /xb7udbV4xTvDqeY0glHDykl8rOLn0QYEjYC0FgvE3miJiQns05fmMHdcHw8tWGdX6K+gtvOytZb VPppKXjfodBAUAxEIi0DSWBGecZlITmXPZJPIyPgFo5dwzFCYg+1zDOmxEFcYQPp3Ntii5sSw9QH 1q9jo2F09Ki6E7nJV8XFLHiEKYXB+FRLOGfmTL/NdFFjkbkGgQ+bmhkchBxypldkQ4zM6yC7YGYV 8I28AYJQWnGhdYMAv8aO33aF5xmXiBiEj2QyLt2ngNB1oyyLx6iUSaj1GTmSkC04MK/MltfXceDv qczIqlCxu2q+E1Fp+JiQnnPCjOyZumYLJsu1qxzPjFpabAhbKPckzr2IC1QdDoTTjCsCPhVJVIl6 2aHoFhcipLjPK8e2yoEOxh0XQ39dWzxC77MQlaiFvOJSidoMZlbd5EYd6itbbiSee7ZQRbXaxTTR bJCL4KSk1jyZGbe+mMiM3Cznwto1KhTP7HO091hUE+LSITbmWlKnsqlqxeWpbIEyy2SB77IoM0Uu fiKL3Pw+uEvA7OSFXy9CR0uzfwT1PAuOxmEhSlWV8zNyZp92QcEFl++HBqrnFdwaGdq8el5lly9N kYcdyPgMY14IL8rKilymPXm+IBgnsn8yRXTHvrdUBTUuWyVa3mxcgQbsTWCZ1jLRepixpOmkT/gL w4rRbDO7sexN8maxry4hHob9Ydgfhv1h2B+G/T+yYT9ev9y7a/tyZdwLz9ou1xG3lsWHm7bHy2K+ O46n6odo0h3L4lvpj6Xy6jeh8TR46FXlk8w7VsX+1betuPFf/a6E1xbF3t8+f/DNrIqL7zqCuJnu UHz+3q9l4AXh5X2/yP2WSt+hu/Vpu6pX/vAI6W2O69xl0eYO5fIjdPnql+C8P9wL0FXDxA3A2s58 oAWIjzQC4vcobvzOGKPhz1ZI/kAyHm1VEsoIzvyMBhC+/Jm5QwlkR6ZylgsC7HXmDe2BUq1CkcjO MeXpEwRnwUwaS9kjzVQmAe/GdPqdOe5YDCMk5o8vcBIxg4RBPXMgApJrUBJUNj53mummBmxjzM90 mAukARyEqkpn5YVv3kJCKqez1NysVvS8QHEO848XbtkEDYNubWARU9mC8tYG+vDgvg0ybO5qgzwZ SCpBzAY/43bVDOfqmR4tgDDSZvo+AJK3EBIks27BSU2wB7MFJgFfYt1S+lJ2xbi+mGC1nReL0LAx b8X0xSqDObuJN1y0K/0kjH7e9O4XBB0/Vi+2hpUolXNhIu2U5TKZxMy72qOkDcMAEzGriO/lrsSh L2ko78B25kengDC1zZwaADm/xMGcfV1yBsL3cTPv3QOluBpQhCAJlCLk1fYTWNzQ96FDJws9z0D9 mGmbatnEQZFaViE2ZeJnbTFCLx0uVllpbWYZkSqUzso5uXjZ2VyzvqUtfcW4IGDFYj0ZKITZ0VFU Sys7Y8aMBpPiMa+ZELJdZmSvalZFNilDrjJOO7nKdk25yqpNycnk7QQrd9y74Jj3SUN+kbOxYQXP xpbFdBc84wFyWVUC2qorr8Q7aaRmzUZhyQn4FORCsyVE2Fm5jVAs87pMqIraWVhxMg2wuJzGWZXY 2W7VcZp21X+aHIlnZ5Ekvd2gIWNbTvuR5uqC/jEcPYajx3D0GI4ew9FjOPr3Ho6OV4z3nmZ+dkCf eCv55artxkaEPzzQvHI+j49QnODgjFc+3308fz35sVRe/Vg81sejY8NT3J37EIfbMBdFZGrNroiD jYj/CziuRkoNCmVuZHN0cmVhbQ0KZW5kb2JqDQo2NCAwIG9iag0KPDwvVHlwZS9QYWdlL1BhcmVu dCAyIDAgUi9SZXNvdXJjZXM8PC9FeHRHU3RhdGU8PC9HUzY2IDY2IDAgUi9HUzcgNyAwIFI+Pi9G b250PDwvRjEgNSAwIFIvRjIgMzggMCBSPj4vWE9iamVjdDw8L0ltYWdlMTQgMTQgMCBSL0ltYWdl MTIgMTIgMCBSL0ltYWdlMTYgMTYgMCBSL0ltYWdlMTggMTggMCBSL0ltYWdlMjAgMjAgMCBSL0lt YWdlMjIgMjIgMCBSL0ltYWdlMjQgMjQgMCBSL0ltYWdlMjYgMjYgMCBSL0ltYWdlMzAgMzAgMCBS L0ltYWdlMzIgMzIgMCBSL0ltYWdlMzQgMzQgMCBSL0ltYWdlMzYgMzYgMCBSL0ltYWdlNTYgNTYg MCBSL0ltYWdlNDIgNDIgMCBSL0ltYWdlNDQgNDQgMCBSL0ltYWdlNDYgNDYgMCBSL0ltYWdlNDgg NDggMCBSL0ltYWdlNTAgNTAgMCBSPj4vUHJvY1NldFsvUERGL1RleHQvSW1hZ2VCL0ltYWdlQy9J bWFnZUldID4+L01lZGlhQm94WyAwIDAgNzIwIDU0MF0gL0NvbnRlbnRzIDY1IDAgUi9Hcm91cDw8 L1R5cGUvR3JvdXAvUy9UcmFuc3BhcmVuY3kvQ1MvRGV2aWNlUkdCPj4vVGFicy9TL1N0cnVjdFBh cmVudHMgNj4+DQplbmRvYmoNCjY1IDAgb2JqDQo8PC9GaWx0ZXIvRmxhdGVEZWNvZGUvTGVuZ3Ro IDk0Njg+Pg0Kc3RyZWFtDQp4nO19W4+kx3HlOwH+h3qcMZbFvF8Aw8BasgUvVvCuxYUfDD8IY4qy t4eCKQr++85zTmR+WT1VNT2tsble1Ut3nchbZGRk5D2+09f/6/Tnf/71L3/2Nz8/ub/4i9Nf/vxn p3/98gt3cmfnnA/B1VMN7pSTO/3w7Zdf/P2fnb7/8ouvf/GrUk7f/f7LL/zpuxXbueJduoj+mz/7 8ov//eUXp7/65c9Op60o//X//PX3353efPv9V//nV2+t3L/8ZuT81/6U0tmVdPrmN8h+5H3yJ1/K ufdTyu2c++mb9yjzO/JRyYY7/eLLL/7hzd/++Ntvfzh9/7t/+vb3px//+f3b+Obb0+/+8OPbfzx9 8z++/OKvvrnCSbjFySw653DubS/6H96c7uUYLRN3Lpniif0cazzFks8lnvr4G8qp+HOreQkpnFto 6fRvoyrnEEbaEXv8zcmf/m5UbfDxL6ePZvSrK9yka/X713ttpiYO/VwLRZBGAe1U0zm0U2wR4N2Q wtd/8/7X333r0+nnvztda+L8yoJjPqet3DLqXEaVA4rfyg23yi3XymU7tHwONY069HPrp/cboQyF Oz0NQjnX0WYboZ596pMwUOqRyAPUJhBO70bUdnZVOJ4GiD4TJKLsGlHxFre6QEJtCG5JbHSiHpG0 QhEQuZ9dECHlE1D1ROPfhkZSi0xCs4K7IWZca2D1/eQik+N+TgHBIXai0fmQfSUY/95RECWY7AIF kZsQ4y65FovsmrIaLTiq1VKdYh8opzbRiPzbET+dI2rY/ZA2G2bIZbBkBLWDC30SUGBpQnExA+Qn r8kiI7Qpp9ECEFM1VE0EyYPgYF4oJvxuFZL1sRJVb5JNqGVHr0RwzYUoRqDeMpFjM4wfwUu0Q0cQ CcEDjaQDpS7pqIEHoTByg0iArM1y3NGouEWe7V8Y7Lt0IwBlX4n8zDl5aVbzCA7DbAPlDLT0depZ q6br7UQ1QDtltiEsTyda0vBOBEhjcO4qEUFixpldlkIuxYvAqFHAUz/Zh9Jol5ktlT9RsYaEqIXp XDpQYpHpnCfDsI8gREYurF2iinTrnfHcJ8OdcCgOqk45RXSSgXxMRCbioTcZBAcz+0RCgBEaBEh5 IGr3EGcFitCggXy31NEie4ZS90eJaaHaoW0WdxIyg2MTIgieoNUZ10URIpkYIwQRgVM2tc0aJOUE JRnaDskAUf16UcajlaQkLSurSh2qUBkgqkyGURBS5KEgW3AoYUvqjaeVsyttFowW6H4yBRQtaV/q p4IbDVsLStpo9GovJhnFrUVxu9paEudPdiV3dPBS0ABh9FdaktGtklobFh39vxBFai4GYaDcLbXP QaNepvXo0rCROQwL+9YYGPM0O6jRICRZJW/aSsPjq8KK+sSw9UF5VZrIom4wmhYDSssTvduGKRKe DoL06Blh8DmQtXAniGnTIxBcm3qEbljqkvpA3u+Nks8ul9VmCaMMQQZoLW6tzaqUqQyo6VQGD5R9 2/QIfbaGLTjkLaXPzzJ2ua5yR4+ufbE0ULjgeDSVqSQqNNDsRRGo9rrLYhCm3BhqKXu+QDNjEtAl AoV+EMRWCzaSsNyuAWxWAO2LjthZv2Mouxj6NBz+BtNBhwngv2EaOqZ/j6nLY+rymLo8pi6Pqctj 6vKYujymLv/PTl2u7UDVz7UD1WHcP9wJurkD1a4VPAzjyGXUe4x9wyCMwfaH78YsC0NJO4WAnnEq 9Zw/cYPuIzlck0t/pVx8ruiJh2CGAcUeWUhlF0u5JRbvXlnwqE8uF+V6DHUhDKuxl9xulnx125d7 c8GPSo065AAD9f4gpAhxP4EwhlT/jDBMqBFCcJgaAI0xOoShr0KJXQAECx42A6gr89FfQghj3htS stkEcBGhMhB1TcO+AEXlm62Dg4DSE6bOAJG/e12gYgCxmMCNbTWTYcasXEeKNKYJZXLQAwmjB5Of wUJ2mEWT20LU0ow8RteQveTgx3SXKAt5ocmFm8EQAETYptQp4QnUn4MvMHIhR8jmvbVCm4QnZTjm EkZgeQT6XZV5X4wmtXHpqnQkYkK2FPhqS1xom0GgvBKEN+pcO8GY5ABp1gxCNflFBo9JDmRbyoFG v5xxiQsm1ytlpjiQsScKYUYOhZqQxDGTcg+cHEsfV+3QlinAirKVhKB2aBSh6GczWGQIfiCHjD2r PESMNhN6dzSCCE8i5HrEL9SLYbTx00p1fSZlpwnn0S2BfBYbaUe5zsggjBYZxT1dELriBzWuXyUB rJLABZpeJeVDKy606OYi92EDHjbgYQP+hGzAtVmRv3og+4rpYogVU/IPZic3p4s+Xp8vhlFv7Fxg uldHEZwv9srG1JSI57KQ4stni3fSX5XK1WNcHZiH02jW/bAc80F0EU5CcWDNGZbXEfnfvY1v/ts/ 3zu/9ldPbvcj8RB4Gn8U8JETcV/uTr5jGTpRT5jX5qtz7+syvJvsqhBfuxL5YMbNlXMaGWauiV8y 6b66GHlB2bk9L5r7MT4n7tetokfCW0VfXWjYzYSxSPaDuYh/I6/ksKM0CU9GqJMAFBhfP/P4GWz/ i4QmQmZwDEJKFxVZ26wkKHJTcCIYAxSBJyp5xk2RhFgmT0YIKimpJJ/31G6xhbw974/MYj2G1sWV tzX1YtpjXFgV8uhNq74eZmbW14sgriknj0nBEqO3KQIEPQYXIzwdhFohERKwkH+G0yQQNSFV0gWh OHkZUxISJE6nvMa4Rl4Uua7IXpGHZk3GgVRnr3JyWpGV1xi2WWeCuIOwogp7y0jpXDyyLTacrVIL RL84KpN9Mlw2SbM+HEFWXQtmcUsUBVv/70xuKoo7HCbFgU5TxPi9tQnx3iRUh2cEZJXBPFBtQlEo r9yEPUObUhbFbQKr4JpESAwtVUilZEN+Rk5KnTuDozLOyjhMYHHdFppUd0vJfek947S4CAyeXCQh f8FywhxmVYhzpFXZNDmcokhQliWphEnBkuKB6oos0xC7pL4IxldWf7a8inr+kbqaFSqqY5vG6tK4 3Vx1PGzgwwY+bODDBv7J2MBrU+Pw2j3h56uu5OPV6entZVe4uil8fdkVa4JAPE4N8yuWXffSXxXL R28H8xRs6PxYz2EV9nyxdX+lFa6uOPfsk0vs2kf2H1lqhXR3qZWGTRtW3+eOVnr5Wut+uquie+39 3w8WW6VhF2va2BestcLVK8AvWWv1s9+VuVCJfc60q8dS6+bd43B1hUmNqI0nsL7RiLzXMSKspwhP JKQ0MUALQjxqywaCncrl3EhIPJXLrQvxpLN45ZssbokqODLfAiPWeJ27yeABzNO+0sQDbqfg7oKK dRta1xIOQuM5qJJGOxUtmjGVeQ6qYiP2OxZL0dgvNt9Kk2PVJ8IcrrpG4z+rzDgzlpy45TtFiF3W JV+AEZMH7sXw04F1VjsPRS8xboYYASh1IR3OwsoOVOYRKw7FSdDRbrZgJu0cdrqNURCo9yKQURcJ UiVICop9nSArWFGzmAh+R+uslrjxRtBM2M79yLZhALK4CtR5uPjhXsNit9l0YtWGLyBWTRubcgqi 2WRpyYm9dsmwYQSbEibYmkSEvU3YjtYncrokZAxoIrB3WHBUPwhCU+kEo1TdcopJ2hqJwhRz9Yoc GAy7CeSZtHK8TkvOuEAF7HjmX1kM5LKj2dQTs3GVMGJmsbKN0AKLy1Ijb8tNjuJkvyksHj0qkWAd WXHFveQQ5zW8KSZu1C4RRqtcsnw8OZ6GSoQnEpplPgjQmGjlRqDihbSrOwipizD0DcgijwndhmZJ xLxxYCWJkDAxnlmhIx8lgd9ZUrXImSWRSVnPS2N7c+n3sMkPm/ywyQ+b/LDJP5FNvrpweO1JyfOl 6FgzoWGfz97vrESvHpRcX4lmXHzHwixg+ffpK9F76a9JJV5doO9LxYIL86O+veHY89OP/eLNN7mz BFwpvSzhYy9hw/1Ldz1i96ViF6l8wmL0frqr0ru60H7VXTvPa7A94eXEC9ai8bXvb1Gji7t2Daas hvN+yS/c1OV4dfmtq3ahcdPWcRfsvQijixghjH6EvcWBcHofeJ8CaF6i4e1UEkbkqF1L53kTYKCk jOzuxCBUEXCbIfKpApBDUs/dUefsNQUIUQRcxxgIQ6VzvKwTyRtQXpFHO5AQGMxyuClOVIlkl0lQ zkHBTXnhwoVQt+vZB6zNAgFKF8MjFyBXVrYMzsGCCxCuQIihjhlDXnEDCVH5FmYVuqFMVFfGhZFD Fr+ZxYSkYnKayCKPScoWHJVXr1PG4EmPO0BwzDn7zgZR9ZJaB6828GymzsYLzKqj8Ua7Y2YJqUWi LIH7PNWCiuB4WWZolDWAJ/ALMW6diaNdJlBLBoJElnSgEkJGIJgCiwNliThkosC6uLCuALUhCYxK lRc/hsoM5O3yEB5AVJvu8VZPAnZB14UG972cU1ggj+bsM64Izq4WQSyYyjblO9AYPmOZkQsJoSry mPDSyjdx3IGSD7N6iBz4TAqVd3yWUaNEkYmyafEQmyt6apF40bjwlUYgGn16gnfq0jnvoXyWgScp aKmgbIqfTVf4LCPhZhbamcF5KDB1QCxpHTAJmffan8SVnBFshLwIQCPXgbwz5IGCq7NOkcHRFQYP drHbj/tpC5W6BCBCbWkLbrwPVqn3mdPiLech0qiCx4xtIO/CYqPwiYRFHvUbhADLBFSJ7EY3VSOU XXu7njoQMWP2NxOGkPW3kCfhyYycX/GB2soLPTntRaGvLz4i7wqRRxkFmAhU4bAZVTWUSaksxm3W CEc5h0FkK7ZmlqtJrnVDpfndzOHBT5t1EMHjwpzZPU+nHUR8qJNXSYUvttpmvDAqqA6RkUte1klP waoGk84HT6lpoNGrndjW0JKYVWgyXp5vynyXijcm9aFOFc98n4YnIUB8O+Vc0nDHRzu9tNl19Dyx Y0gbCC8MYQRl1/RCC8iUIZQjuFBxUIysVSUXMaTZ2x25yF32iYLpVCOu/dAHbTAM0Tpwt8uhY54/ 7ETmFUXeMoSJ6RY52KTE0TbzviFOhXhFUShzsW+RM7UqZ11txUhUNQENPEOCzZz9k6uX3nTRP9qw lIqu/XsNnHWZSRujeVGS53Ia3WnGNQ0wGRe0BycR1u3LMf/Ypyc3924es5jHLOYxi3nMYh6zmMcs 5jGLecxi/gvMYq7uTL32rsIHzx0SDPvzDaLbm53x6lWF65udwSVNeXiy8umbnffSXxXK1S3gixcI Ho+/T378G+J9xWbn1a3eixJiYnMeJXxkszO5jzxycHBs2Icx+JQnDjcTXZNburqF+7oHDo4XYOJL 79yk1z7biTw02kquBYTkn925uV3y1b1dPW+gs4VTHRJ19JoT8eymTsKTCGNCawQixk9wFtDxXAyg 2q3KCvsBAhztADGrBK8NA3WAWGbUzmwjnFsAMSFGQKIM5HNckSscHba8mBKhJotfgIoVO1IPlDWt s8wHITUrKhAFi0wPitWvGjDjaKGNKemzgbUFKCtuZbGT6cp8A1w/SIyG3tl9xUV4WoTcqdGXBG/3 IQsQnaR06gCQjpFI8CQ4BUcm9VV3OCPD/LzwyZksCFE5jwIyn88BOAFntzJxjgqCgzsPzHfJhYM3 CJwqhIkscm57sFieSWN5lnMoq9w4mSBLEcSdYzrwWBWKWMysysYLQfBm+ZITx7Ulw4VKXpHL3ghS /2cEv1oRbmfqauHG+fOmACAs7YDDmrI0R96ANsUC4VA7oKWR8H3TdoWlN6Klz43vXaeuL9TyEZmE blmxy9E1izLe+hGLnb1MHM0eKIaP/qnqzM7Lms5+LTls3V5imkZBIpwG48LA3NyreNihhx162KGH HfpPtUNXJ4ifyxu0HKI9n6TdXm2kq8fRty75c7cBd0nSa1Yb99JfFcrVJdjlJX9vd5ngV+7TVxvp 6lrr8p4/HbZtJXxstdHuX60ovEQW46c9qb6b7KrsPpsTI9/oQSvmFz+pzq/2Y0SvGXvRtPsxPnuz Em8+qc53HBm5gFEi4mU/jyX0GA/1kgc0LIbh8m0jbCme5HJjkOCDq9BAvxcBftFEAKplR+iShW5J sC/h9Pan8CkOkDcUhRh5xgzyro6NXccbY0RZyMJm3ETYCgNTFBJQTHMw4uBWc1QxYMv8SQTkDLci Wf6qRlbwP5J2pHeRJGQSqjm3ikKBCL71sjdndCQouCgvr6RFfhCcIcUtKBB4WHUgDHsHgoCFLHKK e7CVa8i3y4xh3WexGbsdREFoMcjI2OsVoTC4WXAXEhe2Wey4+0aCIqPdM093iOKF4JKCkzl/DDrm OAi+41oqU/SJnbLH7dLep7z4pKkr8Xzs6a1SNfAKWM+Ta6JZIUbkRhsJUdfFyhQOUCmH6IBzmYIF gt4fKJStTUBw/QiukwlDs1CvyPS6Y81AhxtWbhbyk3+LnOsUPNEmiIX04M7rZiH1V3nhpaF02xx7 UPVNQbkdzs4hxy2OJ13sOp4+1PLRq3hayC7nZ+Jcjx5Jga7eij3q1ZH1znB2crK6DICn78PNPoTz hS2Bd9wDHYbn9uHrw8g9jNzDyD2M3P83Ru7a5DZ/NldUHgu7D+aXd76dc8MV1dWDBdgC13EC+xq/ pXeSX5XJa1eQHx4xRLrnjjhsftl8/7Uvigt9KewlO76Ud3u58eaj3nz7i0IRHuRGTjhspcfCRaCR wlZH6lCyS0KaGKASNP7uitm0PZPZYiBg0yHzpDjq9BWoCMmDc5QrQBA4EPOOEpBZAE/QLK7H2WTE RQ0ZGoxjA8W6I9smmYQ6DSWT2lBHv/UxzPsoMQvRRhlDjfXPXN8ChTj5RR/EwbT49ZIjvJcnes4G UscHISsvLBETL+mY0CNc/NWJ1JlnK8QIc7g3C/dv2AqN9uyCACmLgCLgsz/SsQaLj0R+8YOiI29i seGEotrJK7IeX7EZpXRVNU3SQANI6e3+EQiwwrpQQdSI4AXiQBoJFyHgNJ8oEcV+5Bymp4tBAH0Q OBLz/gsE5JQzmjHO50asUSYhqn4YgiOfQFF/lTQvYQSlhq6ltokeKMWJZuNkbA3DGupTFmwLPwnW ReBmWgQWr9V5M14b0dRPx3IHIUvP2BZJAvQcW2OaDZe95EvvjRz6rCpC5Gu+0OJgVyQym+dJvpgG Hsj5GZkEr/E4SKK4CaFRU2EhTTa62SF1QLNKtc6pCPWnzMhFCmUTxiRl8xqdpVszJjp06KsDSqPr 0f/6eekOZom6AMdsFDpngwS6djLFFLSnnNVru2a6AqVNGaAzo09LBlkd00tgpU3jYJGF0fY5qH/W GZeoWJfeCEnFts18BRoFXVOxyKxqnrLPspMqJqZpUWerNVljVbwLZRk37IUFPk6cyiN7PEWvYGcG FxzGzXjTLEXNC7njC1TUGLClIc7OacNAnNYPthXI+lOf6N3RfUR4EqH2I35mxwt81AtEwxnNjxQI SamhpilPtvoBVmcxwug9oc6SjJBPMyd0xKOgmKb/G+Mj0uPO5HH26N0C3D41ewyuj8H1Mbg+BtfH 4PoYXB+D6x8xuF5dyH+uz7Lga8Tp2WL6zs7GJ3yUJWV+5zhU96qdjTvJrwrk1UeZLVx8sTjVwtc8 +CTTfjoebwqlvPYkM/I7ZXvR2kAu5fJgPt7cVCm3TzJT17cGeOmajlFx471NQuI36ggCQRKSYQUB nIAwQmnJAVIgwtcC8FxCzjhxIzySMAwlUFWwV+ROpJgcRYN8HALhiQnviBMlgRk1KSr5iyqCAxlR FgozclbkpJyKQBTwRHFlXJRVVMZFxcIPa6ctAPJHZOXlTxtwG4o6etgwXK3OnCKG4lVKPJcLHiIq sFjkHIJ16UKrbpV4aCCRclLdshKGQ2iKa7VJKiUocuwTWeSLUG+h4tepFD3vQjO2fjAcziqlSDms TI0x1A8l7tKsbkKT0hU1uV96Frrkj5bTRf1O9yRU4DgRIje+/prButPDpEJODekscpsyhqtf9GZx mYH40UogffoKBHyeo3MDHIg5U9GByKI3zcQX1SLxSAyE4yJ+WnEh3eexyEZwioyk+Pab8h1ltmpL DxabSBCLUCd8P9EYFkpl1g6PtRrHedZ1KELjyQxFEYlKmHKDJcA3EiWpruAp5DrRO1kJCHkGe/ZR oK7mK0TWnxVUvKxCJ4IrYZgEhZlb4s7TQPKryFYdL532nigsMxEUHMtSXNRd3Y78lqWaUUWt4Jwv UFNGRydVUcMazG4IlFaXBRtHZBUVLFh5eUsqplybkSXGrv4jYGZOoObLmCVvgbnuYJXfV7PN8vNi XS0RlwksauNQjprxceKqdd7MWlZePi6bgi/umR1WmFt2At2wcWJoVqMtC86WS1Pduz6gwotQbGZW IE2rgYeNLW1GxScSgnSrKdgLoQsChWkoVBL6EUYyAP5iJ0pT0VmTxC7R6syA3YXR5ihgHZ6O0tQv hYZZSK1IV/PqbFQQNm5isJMO0ZRw9oZOay6kG8dQEBg5q+s1GRZDvApokZOsB0Y5qUFQ3YEgEHSs yYWTVTIuZGQxIPJDtzJ+q3pBA2KWVRJg7Xh8ydE6T6E5Dd9oJV1MXJOEfQ5xc6vnMdV4TDUeU43H VOMx1XhMNR5TjcdU43NNNa7t85TPdasnNdmb55sttze/yid8Ya7U4/FXe8UriHvpr4rl5hfm5hsF fB0FH3nhB8U//RFE+ehn5To1YyvgI28gSjka7ytrO5eH9qPdRvLZhE/6yRg+4HXT05FgSN0/C1Jz 060LHtQUtMoQK99VBI7gvJVIr0P8KIznZycL3Urgm3Dokbq8CULThz0zHUE8ab8QnjD0GVISHCew KU+CnHPo8psuy6LJh0r9h9T0I6o02uZfTu30y5+u8r9i3T9s/3ql/dOYgtyQyi4Mn0Zpe3+/3+6w O7C6EV5N6ClcBJ5szu/YdxxgLAIWIjhozRy4QIBHiLrHGCF2CnFBsFJuNvwfXcWXNvhPV+tbLd4+ bPEIxzkvEEdtsYlyp53tfan3zmo8v3CFU/MyH8Xmk9cpEz/ExQkg3Azbx8IaBmAkiFkEHkOAkMNM Aa/JjiuEW6382mq9tG1/qpreatm+DcSmvw1PZG9LYAlqTKI/2q4YsuMJHrDHhAJvDSpf2dLvEmsb Kj0xczWpe+WlyWkJLwIwBs91vOPxNwl5+n/JSWd4mBTD9btrHzTsH1erFzfrT1XRG+1a3Yc9NsHV +QtUO8Dv/Mdaln7MB2+eE3QMSvgqMbVUB6ve6+tZmQ9ISODNC194Y4AjjrzwFU76GaNjbe/LVH1+ 0G3EGFn3mz32tdV68fD7E9X0Vsv6D1vW95HtdRF89Wwkmin8WMA9D7vb3J37SI3vHt6rSlGXvVye VcI7lVTsE3YgRI5IEoquSQHnIkLWi5loX1/jxzU6Vy9X+vF/SF1frgM/TfVv6UD4wGqP2clLOoFL H+3ZwTc+aoltevh0HGnwr+q7846bJaTLlHm+LcG3xp1ijDwCPj7urEvAcRT2azz3wJ7k7wseOmM3 Y3fNaL+qUi9t05+unrdaNV4Zi9vN2chVXS8x9Jcvq/AskE+/+FIDIiiZu6upTRHwCkdYj7pC5p4F I2hYK55bDqN+liBwRyzx3SHGrMz7j/x4wIerqs9ezxcP2D9R1W+1fdoW5l//NT4defFt+ey5K+11 EIJFusMugNMuwM/f+vTmv7/1/s3f/v70m7e+vPn192+/im9Ov/vD26/Smx9Pb7/KRvqneyv7mq99 4CLRG+RW9Ef2B2q5ksusgL6colze//rtV+HND//3bXpz+vG334LV0w9vfX7z7dv45sc//PD94LvN yqU3v7hbaL3Gein6GuhW6H3W77t3SF1fdh3Ztk/xJ3c/3bVtofq5bkVlr/eE2rl9ya2o9upbUeXS v0P2unxauFt8FJ1v3opqt29FZdzV9vR6k3hUme1epQhAQU5x4EpIDlujtpPfKXIygmcwbsx2XivO 8oVLVGfkInc7UTlXCw5CiUgnACSIjWCRlTT4HekoaxIaSxwGIUc+vvyQoCSXBOQY7WOzKi3ysebG TIxTSOA18lHmrEfUU+2jmiCUJYVIn4NTQnZL+hBg1Jtsk2+MU4BJOdcJLG5Le6ixzJSJ94+3jNNq Rs/gEA+euO2/s8wPt60aJV7/nrXlocEuDLkXmbKiq+Ulx4WsZYzQeAH26ZJwmlkNMKLPkoDiYquT 4MR1VEpXVh2A0oyMKjb60p7Vb36JpvECtcmxG6GeplQPVCewuGiRIxStdaAYn2UckhUarXxxIx3Z mJUKzbpIvWY9pX2bGKScU0qm2hLgAfKKCwJP0p62rvEBYbXIRjjNbmdlWa88WLFOa5xah7ZaWH8/ KmnmwGRgpqL5ZUYOwZmVMbmaBToQhbOaJHApsIILb14fqOSLnIvxwDAxIHZ0P3zjlkeeqzKFF6tn RctUtimHwjcRU0zc6psSPEBecctueg5CEFuhHoauzK4ZVgXAyDSTYnKaUNVhs7BlmuMorqc18Us0 m+2W5KZpl1QPs3+MCjfvuTwGj8fg8Rg8HoPHY/B4DB73B49ra7H2uW4u5BDpEef5guj2zYX2CQ5J MrYzaoH8X/Ns507yq0J5tUOSEC/dguTOVTGv7O2PmdJNzyDttR5J8Lb1YoWKq6MnnsxclHy7PW77 JCnYNoRPF3r5eS9Cn3gwxFepjndmgbwh3nMCAW/5HH0GESkpHLR6PZJ03i7YgJAssnJOFixQCXKd cRWYFTUrYeoXaOXLu6L8lM/TBQEuXJkVQZoFEa0a2DWlKJ6TUsY0a0AUVnW7CCerO0DoUzREqwbO CKOCFCpBPpnIDb2TyIvfg1PfU8a+Z+z6ZALluj65iAT4IsfBMAirOq7rlpWq6uxu1JKE67oKLUG5 vgRoP/XEGMhk/7QhceL8ajPHa6Fbi6p0a2/wdagCUN01BZWKS5EggUPJIB2/66DrpirQUEgyLO29 0O2b0+xHF3h0gT+lLnB1XPxc73tzVwM8H5zuTBY+4Y0vdsS5kBhzgfSq+cL9HK6K5nPtaZtbd9xu fcmGdn/1hra//EYKHiKc8MB7nyvc3MzutzezvaOHgBL5zaz3IgzxGgFoLFaIPFETkodAp88DDJzx 5buGRVaJ+oRhOytbb1Hpp6DgkrhCA0ExEIk0ByeBGeUZl4VkfMz9QPLpYQRcgbA7EEZIvEhrmWfM 6IK4wup9rPgWW1wRDksVWL+OVd6wQVF1J3KTr4pbMfCIUAqD4Wc/nDNzptNNumiwyPS0CR8ONTM4 CDnkTJeWhhiZZ/FbMLMK+MDRAEEorbjQuUGAU0rHD/PB84JLRAzCF84Yl+4DQOi6zpPFY1TKJNT6 jBxJyBYcmFdmy+vTBvB3UmZkVajYRSHfiag0fJFEzxFhRvZMXbMFk+XaVY5nRi0tNoQtlAvCsSIX F6g6vD+mGVcEfOeLqBL1sqHoFhcipLjnlWNb5UAH48bF0F/XFo/Q+yxEJWohr7hUojaDmVU3uVGH +sqWuzjnni1UUa12MU00G+QiOCmpNU9mxq0vJjIjN8u5sHaNCsUDU/C/4jbi0iE25lpSp7KpasXl qWyBMstkgY87KDNFLn4ii9z8HtwlYHbywk9PoKOl2T+Cep4FR+OwEKWqyvkZObNPu6DggpvPQwPV 8wqO7Ic2r55X2eVLU+RhBzK+oZUXwrOUsiKXaU+eLgjGieyfTBF96e6WqqDG5ahEy4eNK9CA3QSW aS0TrYcZS5pOOvS9MKwYyg6zG8tukg+LfXMG/DDsD8P+MOwPw/4w7P+VDfu1xUv/XJvAvfCc43IV cXtR1z9lB9g36w4uvnIT+G4OV+Xy6n3g9uxzMEPL0e8rvb9tC6x2UzSv3gbmJ1v3ks0pwOUncPLN 79D029vAOXH/pbYzX3cA4gtRgPg9Shu/M8YY+CMU0qP4jBcflYQygjM/jg6Ez45lbhAB2XmLnB2C AHuTeb1zoFSrUCSyQxB5agPBWTCTxlJ2pJF2EvDoREdnmXbTYhghMX98/ouIGSQMSpmGFEiu3UhQ 2fjWWqavBrCNMSvT4SGQBiAQqiqdlRc+uAcJqZzOUnOzWvH5McU5zBeex2QTNAyStYFFTOUIykcb 6KtHextk2IzVBnkykFSCmA1+xu2qGQ7lMp91A2GkyHwADKQn8yRIZt2Ck5pgB7MFJgGfgTtS+lK2 YlxfTLDazotFaNiYd2H4tcpgzmniDRftysfCo5M3PRoEQac/1YutYSJK5VyOSNs8uUwmMXOs9qLh wBGjReZwBISP9a3EoS9pKO/AduYXL4AwNcsc2oCcX+Jgzr4uOQPh43yZl3aBUlwNKEKQBEoR8mr7 CSxu6Hvo0MlC9wtQP2baplo2cVCkllWITZn4TT2MMEuHi1VWWptZRqQKpbNyTi5edjbXrG9pR1Ux LgiYcVtPBgphdnQU1dLKzpgxo8GkeAloJoRslxnZq5pVkU3KkKuM0yZX2a4pV1m1KTmZvE2wcqe6 Bce8Jw35Wc7GhhU8G1sW013wjNeLZVUJ6KiuvEpu0kjNmo3CkhPXKciFZkuIsFm5g1As87pMqIra LKw4mQZYXE7jrEpstlt1nKZd9Z8mR+LZLJKktw0aMrbltI80Nxekj+HoMRw9hqPHcPQYjh7D0X/2 cHR1ufjZjkcTbzQ+X7NdLqT/HVkNdrkNCmVuZHN0cmVhbQ0KZW5kb2JqDQo2NiAwIG9iag0KPDwv VHlwZS9FeHRHU3RhdGUvQk0vTm9ybWFsL2NhIDE+Pg0KZW5kb2JqDQo2NyAwIG9iag0KPDwvVGl0 bGUo/v8AUAByAOkAcwBlAG4AdABhAHQAaQBvAG4AIABQAG8AdwBlAHIAUABvAGkAbgB0KSAvQXV0 aG9yKFBhc2NhbCBUaHViZXJ0KSAvQ3JlYXRpb25EYXRlKEQ6MjAxMDAzMTMxMzUzMjArMDEnMDAn KSAvTW9kRGF0ZShEOjIwMTAwMzEzMTM1MzIwKzAxJzAwJykgL1Byb2R1Y2VyKP7/AE0AaQBjAHIA bwBzAG8AZgB0AK4AIABQAG8AdwBlAHIAUABvAGkAbgB0AK4AIAAyADAAMQAwKSAvQ3JlYXRvcij+ /wBNAGkAYwByAG8AcwBvAGYAdACuACAAUABvAHcAZQByAFAAbwBpAG4AdACuACAAMgAwADEAMCkg Pj4NCmVuZG9iag0KNzMgMCBvYmoNCjw8L1R5cGUvT2JqU3RtL04gNTAwL0ZpcnN0IDQ3NTAvRmls dGVyL0ZsYXRlRGVjb2RlL0xlbmd0aCA1NTUyPj4NCnN0cmVhbQ0KeJzNXU2PLbdx3QfIf+ils1KT VcUPwDAgJ3EsSwtD1i7IwokFw4AQB4EMOP8+57Crn+bOkLfJufM0YyRqvm5Wscg69cGvuTls+5Z1 E9uysZDTFoJsOW/B4pbLFir+VbcoupV9i6hVwiYhbXkHVd6KbMqHbVrjVtJmEraSN8P3Ura0163U Ldm+1X1LNWz4vxzThso52QbuZdetgq3KVhMq4xteaN4qhNh3EFY8hf/Z8f8grBArqOEfEYXj8xai 4T972ILs/KQoJBLgH1L5Bl1TdCPs4KuZlUFpgTxQz1pz4JzQz8C3GaPCwQi5clTAuaCnIeBtbVR4 WxPf6Bb3AGYho4BRDKFssXHF2xgUn2JAAQMSYtxiZJ2I4eQIhghyJcNoKFCwKBt6wzpgaIXkYJiU bxIKlCdWaqN1FwWMeMDAx4LvQdBESew3ONc2EuBcoYAgssnOJiRDi+AapKDAJiRtEqGnoNBsG0OF ptsYYvClSagRBXYZyhLjqCvBo/xkKAAbGNpNUiQfcM5t1ME5swlwl8JeQG6prQlwrgl1oDzdMUjB FAXCEPjTJqEBWwE4C5Y2jRxnjJpiXFAoKFBxkFIhKwphU8UYQ58AJptIRCh7kcA5UXsJnFPmGzDM kW/AMBcIhlHTovwE8kLYoJ5WDksqm+1EXA4oUHE5olAJENmMox6gV+P3gA5YJABgSRapL1iOCSwJ aNqs4RA4M21NgLOhc6GAYWpAA8PEYcGAWgaaAoSzTMXB0qwQubS1ovyEJgoBgCG2SgDQ1Hbq67BA AjZuicNPc06RTcAOU0QPAj4nAdCAZRQK3+iWmoQY2aRUHCwuGQeq0pYT8Y4mEgAQMSIpAQAR/0hZ milsqRDCGP1U0LkIEKQqfAPOtfBNgQNRvqkoVL7JW6aEHLVMUkqZYRgowFdEeh96JjlMCgWjkdFr 7fwEj6QUAzaYtTRrg0+jkYEgW6LZgXOCCBE4ywmojJFeiPJE+jxaEowx58zK4Fxo2RjQXIyVwblQ VIAyV2VlcK4YsQjKstOO6fx2KC4CDYXuJKLbpfWLHpR6gNFvhf+KwGuJmZXpR+kzYIyFFhdhcYAh KqMZWEzzEChA5xGdLEZ/gOErdLMRn0sKrAzOyVgZnOkl4E7gjOkPAJSSgcwIiyuQDH4FDAv+FWFo pXKcm5PmIIBF3QG0CNOr9Af0rZVIicB9ZUWaX6WXiBiaSj8WYXGVXiKiA1WVHgvuXoHMiNGv1lwX fT2MLNL3J1LBPGumLmCDtQA7EYZW24BjHGsFCmJmEOCo0rR2ugn4QJZgEA3De3OQzafTzJt/3YlI BiyUCAzGtD0SGQxruzTaxEhBbJQWKujA6cNg3qRgG4k+mN5nT9R0aQFE+I7t0q3Fwjbo1+B1WSJU aY97JVbp9GGDha6YJRhVhPEhPDRahg16gEhHEgiXWBlBSBcrw4zQTloIEqKvtohjfMf4RB9HUQJ9 XGQwxNjC4TISYpTo7xlaaJnSwmTGkAiDAnrKesYSdCd7iyqoLYyQkIfvGLGgFpQYIjj0ElrQwaAJ XYww6gldndBXCgOm0FaErlaoTaYLiDywMQkMRggGjDmMT7AFGjRKlbSMYsbYwvgBQ8A7xgRJDFf0 6pJIG1sAA53QJwmMGiW2URhqItsANlFiG7WQtjKuMdrQ0ymjuQiDFd26SAttoEPcYwlQEWFwE44a PaEKACFMCFTRwxZqVI1fyU8ruRRGQYZIJitqHDWGEuArMH6yxFFTcs7QhTAUambPWwQtzMSUnKuQ gpwrNchcB3rGWGlLWTDuQmduTXrGAKNPE6YDRniLMQJy3IVZkdE+MbAsUVLGGgxzbRkc4mtkPbaR ArM6tpESwzjbyJH12EYGbBHaGXYZ2xM5M72QxHYr20iMoXvgO4bVHXII41hinBRmDolZiSQmWoyJ QkNO9NHSIjL9gdDMExHMUUeJY0rjRnjiV3JWaovmm4y6zC12wyCILcR1tkvzTZmy0PRTRm2hcafC LIg2A9ePdksL92yDZp5q5Ttl5CfqSssBOKY07syMTmjSmTmH0HwzvazQ4DMxJTTuzDpSW0rQchym AsbRpXEjHIGihf5Eq2g5RKJ8LVPIlI9mnumxqTE4COqc1o1YxFSJbcBrM2liSoF+MQwip2AGQ+su zDSV1l2YPChtvzAwKK270BcorbtQ30rbL3Te2lILZfpDmy6G2nrkvtB5SwILM1JaAVIQ2IvSpkuC BpQWX5iuKC2+ZCZstOmSK7mQcxGmbOSMMMK8jtkK2mw5W2XoVFp3pUPX2PIUjJ223IPjrC2/adLT zqu0pJDZCyVSWnxV2IHS4ivnJEqbroYxVWnpDiWldVdiXOkFamZGSeuuDPlK64bbYE7JNphTKa27 Vk53YDdIf/BfZRjYOSNRxsid2awykO7MyVo2sjNZ0JboMGS1SL7TW8J5sMRsl8Fvp5ZVyY/8W/Tc tbAeWzP0VRl1d4PlsH/IqagtYxv09y0g7BkY4HSMsxBSkHNuUzS2hmRjo89CiX1jSGohSo1tVCbK qSVg1HliCrVzJBkeGcFQEmZllA8jhxI5MywHJlLKsB4YtJUhODBiaGKORu9BRCFtA1qVKUtgr5X5 SKDnV4bbwCkP5z8owd40s41EzsyRYNSQJbONDFRrZhuZmGTwDA1hnKgSxpu2bLFwVtpSwRqZzrON Cv4KuZEMApktOeFQbi21YtdRMpY4fqXlitRlyxGZsDEdRomaqcwAGW0UFs+Ppc2BEUdoAZVtaHtH LtbekTMzfWVuFjnlVKYDcHr8Ss6J0wMmtJFZqB7pZuJEg5ypLU67UOJ8gtkSTKHNR1gqnKIwn6T0 trd8FPxpwxDU+I5JJtMKTFyYmwpnLsw3pU1dmJ3SijGbYZ6K2vSuKFWW2EYyfm05K74YE2S4YbRx pK+RXMiZSVBLp4SJf8vDhTNQY/IGGKAfsaW3me+E+S35tSkwp34tW1T6K2vzY0Zcz3or+VWmvUba zLwXPeTCA0rAnrWEl1HXmM0qfRPtn5NrviO/zHY5LQZA+I6tFbYrbKOwDdq5Mnsw2jmaQKmlyYxg jPMoQfPW8mMm2EbrNmZURus2xkpmMxh5jh11aUS60c5TNlJUloALo3UjMqGX1nJgtkbrTjVweiht 2o/WaL8wc+WUkSXlO6bGO2ePtP3M9QOjTWcmwy0vzIywRovPTJiN1p2ZFRltOjP22pE4QwNtspRp Q9aSbvafEQslIod2jukT65Ff3vmOrWWMWJuQ5Eza3FJtaqGl2g3FtFrMndCj3JJu4bvEEuzql7/8 4vdcV9q3b7/4wxd/+J8//vcXv//zJu3fX2/7r371j/9wW+W77//+43/+9e9ffP3v/7F9qvrzVdvC bMU4W1FmK+psRetVhOJ8kH/4y5++Z7XMlcBvuQTYHnY80vHIx6Mcj9oeZT8eja7XBuB4q8jyQpGf qjwf+tLn9LmqnYq8rhjvVnzeU3nfnlZ9KteX//Xj3/74Ayl+sf3T9gRDS0SzA1UPBNX0Ezxe14cy EOfbow/2GqI03YsD60wLBt3givPdQc6voZrG7R5dQLkc5+fgLO8LTi6ODYbg4n/HuNbPwHR+2B0X YYyLMNLwvzztRdgfIZ52W1wxOAQe4oS7GHeBHLq+74psXkJzCa89xnMkh8/lZ7lH8whGQ9fDPsh1 ekTjEdK5DjDSeZSBJL+56UbXyc4STztbboQdAttY4HQB0r67vSCblzC7hGUdpO/tb2Wkrkks9x3u Y1ynB14cGjKGhox0/K9PuxH7DneSeN7hiiNFhkjhOspdLMe+w70gm5ZQjwSeu7yrWI7vnNhyR/kR LMe+X36M6/zAOzR0DA0d6fjfbrrR98uTxPN+2RwpNkQKV2zuY7nvly/I5iUUl1DXsfzeftmG9jyH 5b5ffozr9MAnh0YaQyONdPzd0QHpe+RLsnlfnBwdaYgOnvu4M1zeYt8fT5DOS5pc0jyWdDjDcSnl NWTzEvrMJw9nPuPVEH1nS8t3NXVpadJ3t49xnR54X4sLeQyNPNLxlzfd6Dr+WeKuH+8L7Egp4zly uVg7kfIasmkJi0+Ky/riidR3xnJ5bPVE+073Ma7zA+/QqGNo1JGOf33TjW4QmCW+v5j7VODqSKnj 5ZPLxda+X36j5dbg661hYsH1OZb1nf1yHC+GTv3Px7frnd+E9/TmgK/GxvFqLE9A9uX5Z+9G1ztf k037ZR6tPIQcIoVnMe9jueuXr8jmJSwuYV3H8jv75V5/rOtruzVnc9q3lnDaE1rXi3VrdufY3Zpd y+3WnJ6z2rQ9WBfL3ZrdmVavZprWeJqexaRpHaVpHaVpHaVpHaVpHaVpHaVpHaVpHeVpHeVpHeVp HeVpHeVpHeVpHeVpHeVpHeVpHeX7OnqxT/nO5wWivXa75ml6UrogehPe03H1WL9rB/5Hkd9Gy/m/ 9W50EX5NNg33eCzhtasHQyEvNoFK12SuyOYlzC7hcP12jGV7Zyyn127X3GC5n6O+Be9pJSSHSRrD JI30/ZV3o+vbrsmmHV1MjpQ0REpMF5tApessr8imJTyW8drFmlUs1/f2y/m12zVPsVz7fvkteM8r wWGSxzDJI33/zrvR98uXZPN+2c/7xTJESryFykss175fviCbl1BcwvVNoPrefrm8drvmBst9v/wW vKeVUB0mdQyTOtL3196Nvl++JJv3y9WRUodIiXW4qu+t9f3yBdm8hMklHK72vzzC6/gvx/pOOTiU w7ccC7ubL7y6kg4dbb646YNyjMl2NOwnKc/ziu1a/fH05cbddyV239P2pRs/wHaeDms344/n+d1X gKPvH0bfoovOL/p38e/i/MQXYsXri9cXr6/+Xf27evvq8qrXV69vXt/8u/l3z/GCubzm9ZPXT14/ +Xc/Ps0r4cfT2/fz1L5JdO6ynFsY7Vr38fTvrrXgavMF+XNF+1wubjezj+f5/ZCP17KPp6f6ri9f mmuXq4+nf/dzgTG4Rbi+op/Gi8FxGE56X5pz/UXXX/SzZjE6P9dn9CNdMTo/12/0g1QxOj/Xd3R9 R9d3dH1H13f0c0BRnJ/rP/pxmyjOz/EQ/ZBLVOfn+IiOj+j4iI6P6PiIfkYjqvNzvPh87ZzwnHOK dve5PX0/PCZvz/HiufGZXJ75W7u8fDz9u+MlOl48DzkD+Rkr25Xj4+nfHS/R8eI+/3Sap1/qu6xP jsSDoh/KeHpQ/6dKz+PYUflnrnie15+pGi+qvui1fIReSxguDNyc3V8kmx82cQ8h4cliwet7M9q+ uD3Fv0qWVvpj3p807I+Ei32P/CqyFSGLC1knBv0FcsuHQG4c7mjOJbGfg+uCCjxSSbyDkzhSePds /yupF3yceBiVOMaNyIVHCX1PeUW3IKUHdZEZl/IC3eHndsyfju9P1e27sHv9SR/CXHU4+54y1zDw iY+xXQCVZ3KiOgSV6GhWdntToTxE3XdcA6GTC53vCF1GI3h7kn2RbkXKI4kU24dS3sF3DB8C3/bY ob848IqPsV1Qgs8wxO5AxUYqv729IA9RLzhD8emQpDFyJF0c/ouDpPCCbkFKn5xJklfh+0P47/6c p++U+3X7Xu9ex+tH6Ljkx/JMGbjPx9guoM+n+JLvJJp5lCreXOWQfqo4S301Q74R2hPNfCfRLBeJ pgz80AXdgpS+uiblVYnmk3Pq74nvMpxVzuF74D4fY7uiBIdKuQOVOlL5d0970p/mTxIvuELxVVap Y9xIHe5y355ZX6RbkVJdSnsVuj+E9+YfK3sE3dr33g+ynVeC+gK77mOo6D5S+c2VCu1771nqBe+t vhug+xg5ul8crtG+976iW5Eyu5RlKOUdfOuH8N79nl2tETyte7W2+bLj+XPaaxjOKufste8VH2S7 MJy+YaVxPCPROHdtpD/Rn6S2vuPqC+27aRrHExQdL4x6gwP3ckG3IqW5lONE9g5sLX4Ee1V5izso NvCNb8F8QSG+aapyBzZycaHE+tP9a7oVH+e7uCpj5Khc7MlY31Fe0a1IWVzKV23K2Od0y4/FI7ua +j+tO7+8+RkkTQteMy1snKSF7Cn1jbtfd2GxLPUtRj8dV/7m13/90/8NHdenhchvvjpyjPE6odpp vN8cVWcc9k3+MjPjeNq1hQ3atDBRSwvATQvr8nkBZnkQV9Oc2tIztaU7aku3akurakuLassLVpEX rCIvWEVeiCN5AWa5DzPNc2rLz9SW76gt36rtzjpfX215VW0LVpEXrKIsWEVZcL5lAWZlkFmVObWV Z2ord9RWbtVWVtVWFtVWFqyiLFhFubKK3/zlz3/73++/+PKHH39xeyFigeIKci8proD3IoGqH+IY mt4K+OBtg8/BfAGiflqUf2d8BFUbXpz/7e2Ng2W6hYBhfqHe9vFMxoZX45/dOlikW5HSXMpXTYCf 3D14R3zb8E+OLuG773PehPmCQvxUs4U7sBmeLfzq9hbCMt3KpMoPJdqdQ4l2dSix9j3qFd2KlMWl fNUEOOwfwoHbq08QPgV42Pse/E24L6jE19zszpqbDc8Z/u7sy8CFXxOu+HA/m2h3ziba5dnEfeDE 3+xwovnhRHvl4cT9Y3jx8arXEsgHbvwtuK+oxJFzZ+HNdASAr8++DPz4NeGKI/f7JaZj9Jhe7ByH feDJLwhXxFQXczxHeXmvLHq6KL7nKZ6Vye5HL31bUTwPEr8UJr6RJ34pTPyvpvslhfZTccfT6f2S kfilIvFLReLbIOKXivws+HmQ+jyh3H6y7Xj6d19eFr8kJHLWd3n8kpD4JSFxJfrZ1fPg53misv28 2vH0734JSPxPFviZwPNA3XlSrf0o2vH0734JSPx6uKSzvsvjl7LFL5WJXxISvyTkR5TO8z3nwZn2 82XH07/7JSHxS0J+9OM8OHEeSWg/OnY8z+8uj+vdN9XPHelzq7f9VFh7uj7Vr4yop1/q+lXXr3q2 o36pTF3fvgl47qCdW1PtZ72O5/nd23N9+7bKuSdxLvm3H+M6nv7d9al+VFjdCtT1q34aV/Wk9/b8 /Kv6pS91/avrX13/vqzaflDreDqdXwZTx4H6eUP1y2C+rtd+JOt4Op3rX13/6vpX178vLLUfvjqe Tuc4UD/+pH5ZTB0XvrLRfszqeDqd40H9+Iv6pTF1fKgfOFH/G3PqeFHHi89ez6nfObNqPzt1PM/v Pu10vPis4Eypz4x1M7d/czyY27+5/XuudeYpZxLQfuLpePp3t39z+/fwdbr+068OfO7NcQZWOPzi 01txP1V6EZbLgNvnrPjpVtxE1XhR9UWv5UP0enhU+dmtuDWy+WEzN227Odj82t4M/8Txs1txi2Rp oT/uiuzpn0Z+0d7FVfj8KrIVId1+b/ZIppFbPgRy80hpcyl5/RxcF1TgocfyHZwM/xBy/1bcJ+r/ Bw2h/koNCmVuZHN0cmVhbQ0KZW5kb2JqDQo1NzggMCBvYmoNCjw8L1R5cGUvT2JqU3RtL04gNTAw L0ZpcnN0IDQ4NTcvRmlsdGVyL0ZsYXRlRGVjb2RlL0xlbmd0aCA1MTYzPj4NCnN0cmVhbQ0KeJzN XUurJMl13hv8H3IprTqe5wFCMLIkW55ZiJF2xgs9BiEYLGFGIP97f1/kqcu9czMqK6r6NtXQXacz 4zwi4juPiIys6qpb2rr2TcrWLW05Oz7zlnGpq2+lGP5ftmL4v9WtlorPtlVp+OxbS7wuW2vk0605 74OnZnzimkKup00yrnvZpIMPbbThvufNCvi9b2ZsJ5s33m9bTklAGAghp8MymuYKAjIlwdZSHASM LaIgypZrMhAVROMtyKlUDiNzqw2EgFC2gZyeBQRU9E52qKBCyRAoFewZArWgTYYuy+wEBBp1ZQh0 ake3sqMfknUrqZHdtpKhWSC9ZErOHEawSkkgOowvGQRGQQpGttIwDGupYxraVho4BANTmrAN5HT0 UgpU9EZ2qOBkSIVAcghGu2hmG+hSjKfUyjlDY0gvTu0VulzRnSpbTZXsCgKTJLVvNVNyNRDOK86p hvEtgeCIYcJqpWFoV6tgNBrg0NhTzFlt7HuDnAY0SIOKXsgOFV14CwI5xtIhUJxtoEsBOYGV1air Q6BxCjp0eWdjIozT1AGxpDt+WsbYCEa2ZeMV21oplOMgBIOAv60CDgJQt8oOwtzWFF0GbFvHsIlA 8gAkhrhRqmBe2xhDmNuUsyxQapQskGxwFVHIcUy+KFQ4jBLY1Nx5CzBNGD9RIDjRMLpQJn4w6MAa VEBEL4ns8BDM7ibofy/wG4HP9apsA5Q39Ekwwb1TF9wNCGUb+MhAJoa4jzEEJ5wXuoZ7UjJ9z4RX 6C3wEoEDwKPQL6fL0TB2OwFxQggm9tSJV/ad0Mn0HUrP9B32rVTeIijRXaXQivETH1PecYXTkHmr cqoMBMcRyFTaxM5p4kBgljWNTiYQ7FLjFfbWKIeKMWJKZ3MYxvmAPggc0tFThcehHds0/of/gJPx SgEULfwHzqilkx2cFbYogKsV8FRMpwJbbIggNK5AaBtXILmPKxDaxxX8lXEFQjnqCkzr+Ac+qAoU KDxOjSYAVWqdenDVMRIKj1NnB+FxyiihcDRLbAi7LWG6FX5omfZiaCwDcQoMGSIIzWR4RBv4oBUM NoOm1UZ7CwjaAwxZo0BYaQ04RZ826xwkuKf1zjaQzBCo8DijI6K7IBiF4Yw2JgUeZ8ppwhAbg7KC 04wCMcHmnAKYYs4pgJ+ac3wwxJ4aR8tAGNv45pn9hsd5Vg5b3pzuqQAl5pYjWjev7CBcwivxg6ve EhszA3DiMPfeqRRg8s4xhCnOzMJBd8Y5zMPmY9LglW7sMgbUDf9ToMF9zBV0ORwIc8WcggFUZVJJ HE6YlxPSACgE/1SojzkwFSpkFkyFGuEzOdUx0cxMVcdMg2rogcJPc+qcJ6MO5g+1kbjoCEYdA0hO yZSlTslWKY96zXmNOpyT45Tn1Ms8CBN4rZOi3pEA6arK5JgZTRTeAIpZlFkxV84h02JuibzMnQ0j a0yMuWPEjJkxM98bs2ZmtmD0AOW8JiPJOiFKSnmN2oBUUJTH1MKUCMoJXGpzopJJM2M2Nk4IzCu8 1kgJkQ7JIzsaIA8KfaDvIJMbKUgu9FIG3VxaIq+R6nQFSC7M2VYouWNq4SdM/oXXqGPEzEYdw8EK s30xUsYCoLDecFJC/4GO1jAmBocFRccBckFhHg0jkkemgMOREl5jGcGKwSol05XghaQ4apWShx/C oUCxb406jB7UKNl8uCsop8MBjbmz0DFwgeII0fqOUQXVSCnbsVhhJWaN1QqdyBrLlUreTimVTo45 yb1xLuHXqGoyr7VR3zAoUAeTv8F/QdG+TsnDwzslj/nttABxYmMwQ0nEURPKY0Y2YXWUgDMmGVAM SbAbFDyCXBl1E9t1Uhw1IC8LfYuVE6g9+JDiqAFbgJ+yHSxA4cBARMmdY6CUPHCq1Mvaw5SSmY2M /ivDeqVeYpRZGhRHiH4ujMNG7xZWlkbvRsdZb7LGTUQOvVvpW0ZPRsZhu0ZqxMJOCj5p9GSEG941 UkopkKwDTfR9xF7I81E9Uy99GnF0xE9QLOCMPq1M6Uaf1hHb6fFKvyc+snL26FWg6BX0c2WxafRk BABEO/o5XByRkH4O10W8oyfDOREm6edwvxGcSSmjM7TBXXhXSTE+06eNyHF6PIAJeaPWbdDr9GmA hu2cZS882+nTxnLIRynMuOb0eGNUZWGUjV7i9HPj7Dn93Nja6cnoNO9SnrPap5/DSOigJ8OgxmQB ChEBFIvrzHRRRr2deFdG5c2kAgucNbPTux3uvXGUQDk5oNcZlZ3e7YzKTu921nlO33fWAk4/d2YH p587o5HTz51+4PRz51w4fdpZRjk93okhh8eXxEIKyYsU8xlalIR8AKqSavuaBoGwsh1q8FQxJo7r oJiw2lg51JH5SGG+mQcQ2TlWnZKH9fB9UNTRqYMFDLMxKCbdTm2M/8iWpGhppzzim5VqSRw779Q2 MNTHQiUxv/pYskAKUAEKaEWGBZWJCIx/QahGO/hmySysHZgGRb3CVU6jLbAMFHzIhZI7Z1Uoeazr MOoozahDqYPloCvlsWDBVJDimCq1MXK7Uh5jhiu1EY9cvpQ8MKSU55xpIA/1RaUULrQSEWFcYCGb bax3Cy5Cr3H1VegfQFkplfMLjQXLLfQIdoNitQFP5iqNUiiZq2GH75fCpRTAQIr4c8pjlmRlB4pj 6tTGKErLyliAATSkOAZObcQKsQ+KPgNsFVSolGKk6JewERV3GqvgRLKNkiWTHEvixGVj2a9y4VhG HQEGgIzQTsAfSI11NIJWHm2pqzFuc9oxAnR7lEIkmTGAW5Jj+Z2pjetBkNQmowjKY5laRt1Ebew0 SyiQI8tzrQayDzZqG1EpcU1c2fHMnoLcaytoaywQMv8ByTxCd8KMMDElLpPb3s2xGq5pXBWSzDRp LJYJPhZqJPfqDSqQukdbJTnqLa6Vm4xucrXcZNRoXBQ3TmLmihjk6BDXzG0UNalS8cidqVLxCMJw XJAjJnDJB3IUlYwHnT3MTIsgmTYTfR7rONrLMIF13ygdoQL5e1ztJMe0MGZgiT/Yxmp/FKb0/L53 iGGj7x1ijOh7hxgkugwQMDZ0HSBgcOgsl0FS7qjNEsNDH4mfWaP0fYYYIMYqESQV+5huhoixUszs Csgx6gwDkvvQ5tyAGDYwTEhlqmArkDKqYdiArN1HOUxyVNAMBsKtDJCdJPNeYtgQGUPNuCEygMhw IVw4gaTivWpnwJBRRCZGDBnVCBdU8M2BEsYMYZQFScU+inPGCiVWfvazT78d+15p+/bT7z797u9/ +J9PX/3ph3/84fvff/fPH37yy238+en26ev/Qj3739un3/4F62q2/vnP//Vfdm4I37nJ8se//ZNt u46LWx8ba98eM2JSj9VeFJa7+BashJ8MK+GHUytfGIe2lwafvt5yvSr+ZjtuNzi3hbZ9uT/yhftz 3NDzbHpP/gRq9CPELoAKyW+ACqlvCiq49LExv37TFXuI21eM7mG0XDFar/trSXfxrVhpYaXf468l PwW+j3pWJqHusG1d7nh7ho7z+cEjjl2OA9qDYm8fd64+iD6uAGfo44OQY2N+9aYr8hD3JMIdG93C 6H7FaJmNYCg8jkNnfCtWalhpdzm2PwO+D3tWJzHxsO1ZgfWu47U8Q8e5C/2IY9fjgPag2AX01b0M 5OPDqY/UMjHm39905bhAu5X7rGR7Y3QNo9sVo2eF/UXhJA6d8K1YKWHllXXAFXzrM+D72Fkntdlh 27NK7F3HW3qGjvPZ9COO3Y4D2oNiF9DXfEdfT3Mf6bN1we9f9+S4PruR+axge21yL2HyfPXAx/RX 3bpNotAJ34qVPay8sly4gu7+kaCVx8rMNomJj4ldGFuJMlOulJkyKxS/etOV40LxVu6FCMf9+N3o K2WmnJSZ7ThMnvGtWBllptxVZvanCMrHK+OVvbmzteb7jn/pja5jHMz3/W5y7D6Jio+JXUBf7DbK ld1GPl44NuYXb7oyWQrfyH0c4SZGR5lpV8pMOykz+yQOnfCtWBllpt1VZnZ7BnxPtrwWRuFsrfmu 4/IUO2Li99aDr1EtkxLtcwhfmIN9a3KcDpwhkacCj036t+jKccF4zrfweICHFXdD54UmzyhedWw5 jkNnfCtW9rDyrkJTnuOJxiFQVjbxziqx9x1/3h0xXdgR07Oy5td//cs//ve7T199/8NPdkTqWXHz nuNsdfae48zN3nOcbey85zjL0e85bgfUR8zqwmJBF3KaLaDFFopgW3jgYpNw/LJL9s0v/vbn/5sN l9ZLMPzmNzve5qFM62Vl9s3edL6aOh7ZK5uBx11byBi2sDtpCyWmLURCW4CZHcOMR1Nvmbb2o2lr V6atvZ22tjptbXHafMErfMErfMErfGFXyxdg5pOaot82bf1H03Zlh0r722nrq9PWV6dtwSt8wSt8 wSt8IfjmtICznBaAltNyns5pOVHntJypc1o/NpM+ssrkSbxXiu9cHOV0DKfPIn3BY3Tf2+Q7K1Ov 1Nnu5H9c+nIM9xsYF7DPl2h2U+dRQfVkRzPnYwc6Y1wxU8PMu7Y0c36KHQC12dQtgXxyYPCzSF8p hQM5dgU5NgPAby59mRSd54wrmwAW6LE5evhy1gnIJxn7hHFlwbDvnKrfd07zOQ42qk+dfgnkk0j+ OaSvTEkgx68gx2cA+M9LXyaR/JxxaQm5o8fSHD2WZjvnL2eRjyP5GeOKmTXMvKWqfA/yJz7dmFeO N+b18435OQ44Wp4+z1hx8Mk5x88ifWUzZX+kYnn+SMXybG/960tfjlc8NzCubArkfc+dr8tOTS3T 498Xjcex6IxxZcuphJlXDoZfWZmUyePxl6H8/q9//m48M2p7bO5x/KX3eM1hP62Czzihvq9/t76v Y7cepzr6vmbmty3Ep+2fcTKhS/BLtJfL/dCnoS+q/a7RXqO9RjuL6/GMsUfh1C3axVO9HlVKt9Bj wR9lQRztv5yLvxw4H1+Osn/GiYp45CERaSXFoYV4yCApniKmC7/FZxwjyiEvB3+4iAT+pMT9Evpi wqVE+xL6SugrwV9CXwl9JeTV4K/Rvsb9Gvdb6Guhr0X7Fvpa6GvB30Jf4CPOYV1OMV3OB43vFNk/ L/dDn4Q+CfkS8mLeJeZdYt4l5l002seSSgIHEi8JSaxhRENf4CMeZ1+eE48v9dg/437Mv8T8S7x5 IR76Ag8SLzeIh74LPuJ1gniudnlsNb6RY/+83I9nejH/GgfBNccjtMCDxllrzfHQKvChcbpZc8gL vGjgRQMvGnjRwIsGXjTwooEXDbxo4EUDLxrnWLWGvMBP7CqP79bYP4MvcKSBIw0caeAotjXHN2fs n8EXcUUjrmjgRyOuxL7a+F6M/TP4AkcaONKIJxrxRANXGoeJNOKLBs40ju9oxBsN3MUmxmUD4LK6 Hl9nMT7j4IVa6Atcxbrwsqa6LFjGl1Dsn3E/cKSBoyi1L2XqpQYcXx2xf0bqDBxZ4MgCRxY4ssCR BY4scGSBo8j4l2x5SUXjSx7SNM+9qRLQIM6tfb2lg0Y/rmj2xl+44ZZvb1pOmr7rdX2KXteTV6fa XWy3D5uFy1t99ebU3b1ps5Lo2zjvcx+bLPQnQpS1Ou9POzm9oHexrRgZ/vv60dHtyLWPBGR/7JCs f4TUhZGNjGO9zEe2z3b93r7VnB7iXghdFuWVvX7O9E7t2Y7yJACe8K1YGUmr2z2gzV863r68E31T 20lkutIfeYr8IbP18m3umieh7jGxC6CKSs00zUGls/Rw+E70ndyTwHVodCxfTK/kGD3JMWUSXk74 VqyMJKN3JZlXu4bPVhWWs1rvddu63PH2FB23aYV3k2OXSUB7TOwC+mJJbnalrvRZVXD4TvSd3JMI d2h07BeYX6kefPrM8O070Yt8K1ZGueBXyoUr+PanwPdRz+okJh62PSuw3i/4yjN03NO9j+PevhP9 ecXePu4eexee5mWgp9ljusN3ou/kPivZXhsdGyue89zofPKkrx7HoTO+FStrWNmmVl7Dtz4Dvo+d dRITD9ueVWLvOt4+cgPLy7Qgu8lf23GcelDsAqhij9jLvAz0MqsKjl51vo/5rA57Y7KFyfPawet0 R+Htq86LfAtWxma61yvFwhXQ9i/thG1hG62dVU3v+/Ohu1I3e2ubBuPbvPU4+DwodgFU8WTF2zwF eOsTY968pd2Pi6lbuRf2rzweH3rTK0ZPdxRC4SS6nPCtWLlvNfjr73y4Hd/9OZ4XHPWsL2x09eWN rv4UG10uj335Xz8OaA+KXUBfPMp0me8ZucxqgrdvaR8XU7dyL2x0eTxndblSO8jJEyyZxKETvhUr o1yQWx5hvcO3PO9GlyxsdMnyRpc8xUaX27Qgu+nP2/eNP0L4AhLjHIHbvCT06ZnzeBlBJsvMU76F jS6PA1X++iT6O4UnT5xkEodO+FasjK0Gu+uJkzzvRpcubHTp8kaXfumNrpdXpW9qe1atTF+SXuC4 fanzEaOx4Im6sDOiK8+oFhBmK8+qF1KSLaDCFmpYW9j5s5WzIyuPChbmzZZ3tPwpjmSNHxh4PDf7 Mbw+j/TbZ2H8iALTyfgJhVk+Gb+ZcGxVfJeKH3vADYwL7jB+0CGMndfe4/cbruZoP3arU8YlS+1i 6V31t3/pjbCVlcVC2+UdM3+KHbPxoxufwcmPY9znkb6CxjiqPH5WZO43bVZMX16WTMf58xbOhWw6 fuYkzJ1X4uNXTa66+ctb86ucS6bqxdT7DoCl591Be/k+gNsarx8WS0+xiTZ+j+ZxX3/5zoAPEb8y EXur/Sd35t4js837y0uj6biYu4VzoSQfPwEU5s5398cv/lx39snJ1FPOJVPlYup8T/8a4PPz7qrl 2VHZ48bL+2o5f+TGGpzv3iNcb3z4/YnX/wedmE9WDQplbmRzdHJlYW0NCmVuZG9iag0KMTA4MCAw IG9iag0KPDwvVHlwZS9PYmpTdG0vTiA1MDAvRmlyc3QgNTMyMC9GaWx0ZXIvRmxhdGVEZWNvZGUv TGVuZ3RoIDU3NDQ+Pg0Kc3RyZWFtDQp4nM1cy44suXHdG/A/1FJe3WQEgw9AEDB+yLZmI0jaGV7I 9kAQMLANYwTo8x3nJKOn+1Yxs1jdjVt30RU3i/EgGXEYjCQrbbVftkvaar305J9NLsnwoOlFtgYi XaQUEHZRMRDlov61E/mStYKol9zZpl1M2aZfrOJJ3y4loY2LL0VAyKVufKKXalDR86Vt/dJceitQ 7rIkN1LtIpbYqDuFb9O2uUWbgIJtOYMSp1y7U254VX6bnarksIu0xGcuuRk5XHKD0S76It34bb3o tuFZ2pwqpOSiaOyUOlXAm5IPhUBywqA0Uj4qquTITnU+c3nZSDWnaF/qFzXFMxegVqFXXEdJkCyu o3q3nHIdtUGeD4u2TMp1dDfXKdfRd952yRv7K92pxm99PlL2KUquKMtGKjmV0c4bZ2nQpuoTKJCs mMoC+3z6ck7kKE4Zn7m83Cso12YKHf7Hv4Sl2SUXAYeLzzXxmeutHF2fntyMlEvuCbxuWu5wtZTr xTZald11MMlOlYslozz3IqEtPogmnCNLTnVY7/+1fcS9sflggcoXy7TFzCn2yJWbweOSuTbL0GEu 2eDxyV3KSuWzBp+FZPdTa0LKJbcG3uJ6O+ey2KVsiVRxqvDb7G4ulFed4ri48rJ7SelOwfmTu2PR DZKrx4PSFp/GouxR1UvJCuury8vVQLk2QwQlj9HiRoNyyf41KLdg93Z3Qu8GKZfcjLyutyN6ksdr 6Rwhn/i6IUZTQyDSXzy0a6It7nA10U+901Xop/7fKvQ1b1yVfuruXZW2+CDWzB4hsDO9DpHtkw7K tZnAUneGaoUcLrkYn7neytn3ia8NMS0e3bXtkl1v97DyZy65V1LqUIEREg+SBuBxyuEDjuSUAwi6 4FRxOPHQcKo6BRQAnDVN1OFgo7BAfBpbpl532+aOD0qcAsDB9ZoB88Tj3J2YHC65GJ+5Xu86KJfc NlIuuRXyut6O2BJ3i9Zplcd53zBCcAsPZMhzZ+2JtrjDdQyTU3bporDeBXTii/ggdgcdUM0p2uIR 3zN75BPVs8F6j/OeO3T4MHWisXh0d0aouKv0CjQTDxwfUlIu2QcGlOtt8ETx6O4dOCno4LYlfg0c 3gokYqC2xKHB/G3ERUHXNoy9kxlkhvyMBUFoElDMp49PsQRoRTfQastABoETbrlAG3qzGbCLgb8Z h4uLE5FeYN5WqcK45mwwx7gyIdjEuMpwzPZ1BmEuxKLdh+hmGy3jygJodDIRutEhxqzQBzGpuxwh Rigtw2A4ePIpcZQeSUjIAm1EIAdFkAQZwBn90REKbHUHIT4VogsUV4IAO1SJDLBaCAgNUCaIBo9b SmAoYVkQRnhHX4R93eeN/rNhYATA5O4PuY1ej/VbdmfnA6wLAmdz0uiAkEPvZeQLO8jQF86Cdvxt nDwGA1Y+n1II6xx6AOk+/QVYJIBdHwFw0JBKFXT8xoChBzYaReGdIYO1wVdnqqggMVCK/yuWXCcT SHRTEdEKeNmnSeHjibirHBjFyKoK2QrIwqdolREeyj9cuxVQ70hNkVBhGA2F/R6F4MCUaqUKGlLR ASKNNqNRYOhkBpJrh1e4qRdfJ4VyG8i2W+1k4lOsHZmRpVhaMiOLGJAZEoqQzhwjdiUzspikZcWk c23PeRcGFXkXBhVcSRQTnQu7CQRwRyUJFQQHxQqQOS2qUNHYeaBK7ohxRSDlThuwFttmJCvI/an/ MSQETnaQ7Cb+b8IJAJYYQ0KBJbYPF+bc0YtkBtn3GXGSfqYAEMu7MKgwzgUQxgpNR688vyIJFcym uORao+lwFev0CviSdYS7YmR9fUdbwErZKkn/U9L+tIJkN/GnCH0Qw1kIhor4K4wORlrhyCmEtw32 KWahIX120hu0xPEFgLRE0wEgTTgX+H8j1tFH2z7dGK3GAVcASGP2owCQluE2CtTwpBHmADUak2gF rDTmnIpe+UpFEipK3V3XyaqUABv2MQNqNKagivFunfEFD2udM4RY7fuYoVd9j00ASEcyv8NiT3RP jEvHEuekf9X3+AJqdHZLgQ+daZACVjq3FgoA6UZtCK9eGHWIyl4KgwraquzxBbKwLRQ3RjMGrjf6 OrDEVzoGIBR3eFQGgHQuEkgJfFoZddhQ+KoHN8c+YsNuwskCsvOp7zM2Qi+gQ/b1LWNXsVFkdlhx EpOeHQMciRmsCSqYQWcfAY9tBlWCtkLLEuRWRl2C4oopczzAxoyAkSCXO6acoLjTsgTFzFThCU5i ELN3xf2JMe5w4GQldrgKbmKAKE5yq4D8WXZ0zz6csseXbxmcRAecLCArIcdVeHCShAom1Vj6fNXM BCJo40qGKXUysy0U07myQnEjPCnkNjgB9pWeTKUdykCymwq5HbMHDPAsCtiBrM1J+CDST8+3iICu xxeyxKcCsu8I6CTjNjuAOABxjt1SJ+G6vs9x0mikQUXhFPoIOAk8QJbl6yMtM8itxrZQzB1PNihu dAKD3IZAyQbFnZYZFHd20w3x3G0jIHeQQCrkP07SuTyCfeGll/gIeP4Gr4YveXpHdHcAcZKddx/1 VI+u7BHhvdxIQoUZgd5t8I0mhUFbqcR8yCXwI09x0gj/UMyVLFfIbQBvzLmTHKgKxZ1LUIXcDijL jhqeMmIh9f0fSOAt9vKeMiqfujlZuIg5ljjZSLqKTHTPKDhkLsLYQjhZSKIkwFwc0+Qkw7RBW6Fl DXILo7BBceXq2aG4AgaxgKOoANM7tLXOp9DWgXXZg87TSxqJAoQlDp+PgJMMfxYjRPYFDyQn1hHG k05EAMbbyU7S5RpBzIAlxs0cslnPVRMXR2jjImzAEitcjYAlxhAxYInRXgOWeNaBRQxYYtzTGbDE uKkzYEnhrs4SqyONK61rK9zXGbCkcGNnwJLCnZ0BSwrTTtjkKS7SF6wUTtIyYEnh7s6AJQUO7STK LrAaKzhIOJcBNUrBvAHfnKQEwEqhcxlQo9Syr/Yo1yBDMsBKYUnGgBqFNRkUSDzzZOoAWCm9MR1w bXUTPkWZZ0MMAXw8HhGQ2O04Wfi0gARUGLCkcstiwJLKfNcAIJXJkgFAKjcgqG14RNNeYEk1qgCW uBcx44ANBRFgwJK6TxawxDewUAEsqdx/G1CjEsRQdXCS3QSs1M5uAkB8P8v0RVGjwnpsQJhGPzMA SNvtBYC0PW8CwjQubdhDeM7OCQCANOMUAmF8vwq5QA3fDpGEXC6WBlhpzMENWNIqMyRgiQc37AWW tM6MDljSdnuBJZ07CQOW9MSBAoD0xIECgHRuH7DXd7Ix83Jtfc/zgCWdqYMBSzqTUwOWdK6QyOJ8 W0DnAlQ47rMttBWsLQYs6bu9gAou7r/85Zff7lXM7fK7L7//8vv//eN/f/nuP3/6yx9//MMPf/3p F5e7/v3d5cv3//bvly+//dPFR80l/epXf/s3FI3S5C4Z4v7jf/7qDaGv4SkIVFF/d5OVFdTbVn1P hdjzPcxZV8x1pN3NdX86MDfPBjGUtsc4l0y1MLVMTf2ZlfpeGnz5HpvgQw13m7Jgs2wrjdNJ41// +U9/+b8fvnz340+/GMMuss6i6yz5JktpMdQ//vm/fkBL7AkxRcjc9s++f+o2PtP4lPGp4zOPTxuf Q47W/TMP/jz482if4/uhLw99NtrbkG9Dno3vy/i+DHll2FNG+zLkl2FPGfxl6CtDXx38dbSv4/sa 3w99behro/2IutaGvjb4h4u3NvS1Ia8P/j7a9/F9j++Hvr7r69s2PtP4lPGp4zOPTxufZXwO/jTa p/F9Gt+nOj7b+BztZeiToU8Gvwx9MvTJ4B/+0Mf89zH/fcx/H/PfNdoPfTr0DX/owx98xRifg3/4 Q7fxvY3vhz9gzd0/R/vhH92GPgv+oW/4Sx/+0od/9OEPyNv3z/F9Hfrq0Df8w5eo8Tn01eAf+oa/ 9OEvffhHH/6AbRs/hz/0PvT1oW/4h+9dx+fQN/ylD3/pw1/68Je0DYdBVTeIWBiGzziRgwggHm6T kNsPIla/LSSnkJxCcgrJKSSnkJxCcgrJKSSnkJxCsoRkCckSciS4NNpotNHQrqFdg0tDu4Z2fZET 2jW055CcQ04OrhxtLNpYaLfQbsFlod1Cu4UcC+0W2i0kl5BTgqtEmxJtamivob0GVw3tNbTXkFND ew3tLdhbNG4vX4XSFkp7KO3B1UNpD6W7d04Shn61gJPfF/DtVqurZVlm8j635SUttJWztld912fp e9qm+fSeLeTH+FZGOgXKpO11jv14n9Isp/7d3id7kK8s9SpwMSWd9yqlk1S8Psa3ZqmFpeWe8b/y 5vY03iyzGbxrX3jpnyJ2aS4kvEaOvEZms/+Pr7uTtvexr2Agz7AMyw+8KMkJ3qQJmJ4xrpkagCN3 Ac6Vw6enwe/bHZyA9u3GEzQ86n55lu6nPW17OODTDF7fJ3fJGcemh0er5nGzp6U3DPr1m/6097FP AHBmeQ7L7cjychzxMkOpE8Y1U2uY2h6KeEnP4vK3M9DTFPR1Y13vfv7kOLY2m+u74lhmKd375C65 WGzm0r4HmhhUZqnEP73pzyTVvJd9AmsTy2P3mcpRzlFOMlWZYc8J45qpkWSUx1JV6d8gOnWCcLcb n2Zd17tJeRZwSnWK2XfFsU6g6Z1yl1wsCiWpHiwVaS/t3TDon9/0Z7Z9vpP9NDd7Y/koM/J48Nzy vVg9j2OdYc8J45qpGqbmualHLl+fxeVvB/EEC283Ps26rrqfn6Z4lt4auRzxeQJ375S75IyjnM5j 6/O46bNU4g+jJ7Od6ynjaT721tqRZ+BM4tRa2aYli6F0gkxnjCumSrx0kO0gsThyc3sWN7/ZwbxS EMynOdl195+msCbzcuN9UT6BuHfKXXLGqHLKUZVT0qzM9N3r/tgko7uXfamyJvGuTNJBuUpkWrIY Sif4dMa4ZGq8uxM5KGYcuLw9d2XNViprtl5Zs0+urIlOc7i74tgmIPZOuUsuFi96RQ9SR9FZ+vD3 b/ozydPuZV+ql0m8hxY9yDNEpyWL8RZqhj0njGumRpKRD5KMA0cu36Be5o1WGq9XwconV8EW4tge rU+/dt8yAagPkb7kbnGgQuxg2RCbFbH/YfRnko+dMy7VyyTOeIgd1L3FTureZYY9J4xrptYw9bG6 d/kG9bKFDtaVylpdr6zVp6ms3e7Rys6xnuYuV0dF62kGc81yuie6ZjmNvmuW0/rKNcvpWn3F0k69 65rl1MeuWRZWrW/sb23F39pCrrwidqUm2k698fowy9NUFqU/euzk9SLfZsvMR0hfWovi5KD0g2qQ 9FlF4F9Gf2alhDPGvrJW8N76sPaoXNBPjrP0CR6cMa6ZGvWB/thxlv7cq1xfQZ1+ijrX3f/kKqNu s5c9K3HcJ1D2IdJX3E3jCLimg9dMmmYVgX8d/Zms+ueMK+9W+MsNw9qDcoGm6duGoXSCOmeMa6aW MPWgPnDgyGn7Bq+F/OlSNXNbPy2dtqepCur8GOJCLKdtglIfIn7J5+IopB4dhVSdFQR+Ex2aZGV3 cC6dqta4+KF6UClQnW34XyZghj4nnGu25rD1oE5w6PdP8wJoEstr5wVPE7DrEUhPc+5O58cRVyJ/ dr75Q8QveWccidSjI5GaZ9nFy/3kSXZ2B+fSMWWN21dqR2mHTV9EhNYZUp1wrtkaSYc9drwlPc8R 60ksr50wvJ2yXd84TlucxdhiU7PFeQf8Vscg4sR0nC9IcakxxaXGFJcaU1xqTHGpMUX+muIKY4oL iym9tIkbAnE9McX1xBSvOFNcT0xxPTHF9cQUq1SK64kp3lqlWBRSXE9M8Voo6Yuc0B6vYVJcT0xx PTHF9cQU1xNTBEiKanqK64kp/DFF6TrF9cQU1xNTlIpTXE8ch01fTnBe+MuXg3hpE9rjemKK64kp riemuJ6Y4npiiuuJKa4njgNxL6fMLvzFykFEm7inmOKeYop7iinuKaa4p5ii2pDinmLqoT229ull 4xweJeE/Ev4j4T8S/iPbC1e8JAuPkvAoictfEtsPCR+T8DEJjxKJNuFREndpREK7vHCFdgnt4XUS XifhdRI+JuFRErcNJEeb8CiJ4/ySgyt8TGKtkPwiJ7SH10n4mIRHSZyIlhJtwqOkhPYSXOFjEkd8 pYSc8DoJr5PwOgmvk/A6Ca+T8DoJr5PwOgmvkzjrKfEzHxJ+KHGYUuK+rIRnShxelLhBK+GrEr4q 4asSvirhqxK+KuGrEp45qkIX/ubhICLfDazTwDoNX9XwVQ1f1e1FTqT34asanqlxHkYD6zSwTsMz NbBO41qahq9q+KqGr2r4qoavanimBvppYJ3qS5vQHlingXUavqrhqxq+quGrGr6q4asanqmBfhpY p+GZGlingXUavqpHp/f17fF7tNiLjm9uM//c6mptzTN5n9vy5TbzPW3lrO1V3/Vp+l5P9n35Mb6V kdaAG62vd33v6NOsJPDVbeZVvrLWqwiUN7+D9DVvOzmDVh/jW7I08Fqb3DP+V97cPtlH2/uuSPRP Ebs2woGerR35wmz/d/uO8oPsK8jGnyDdLe/pwPJ+toecQeQJ45qpsdS9+XmN+904fQNU/vnm8V2N Z8h10KnyLEtN3t53IjpNoPCdcpfmKvLGvJW5i+XpL33cvnn8IPsM1iaWt7D8YDXK6WQ1kgn2nDEu mRpbwpweW45e3zx+wsxSTtPF1411vfv5WbqfZZok3hXxMoG7d8pdcsbYtGU5yE2zzFKJ23eUH2Sf 5YITy2tYfpBzZJm+C//qjvIi45KpsevNepRkHLh8fxaXv9lBnWVsNxuf5mfXu0l5lu7nPM3n7op4 ncDdO+UuOWNUTHI+SCNznp1iuH2b+UH203zvreUlLK9Hlp/cltAZSp0wrpk6ikfZtrmpRy5fn8Xl bwfxBDVvNz7N5K66nz+5eJbL+34lKE9A7J1yl1wsKue5HKSRucxSia/vKC8znmZub62NPKMc5Rnl 5IZEnuHNCeOaqZFYlKNixoHz2jeIyLxSvMunmdZ1pz67CHZ/7Nb3/TJQnsDRO+UuuVi8U8rtYHnI 01+Cv33z+EH2pXpZjlde+c3PyV+pnpYsvrp5vMi4ZmoUM9pBMePA5e1p3mLkh0/mj+Geweb75C7N Rrx9z/3IcaZH9t/esp1tnO9kX3rRkeNwQO5HRbGzc/82K+/dd+7/TlOjCtaP3skcuPzToLw9XPV8 M9MTrP8Q6UuF7ais2lFl1aal0biWOsH6c8YllLeoptpRNdXOqqllgvJnjEumRjXVHqymlqdB+Zsd LCvvT8rpfvrqrmE5xcJrltPs8ZrldL94zXK6a7y+0Hlah7pmOY2La5bT+vY1y8Je6Rv7W13xt7pQ v1kRu7I+1/W9TH2eVU4/4iJYna1yHyF9CYzjoJblg0K3TYudcaFztsqdMq6tclEJtaNKqE1LmXGd drbKnTCumVrC1IPS59ERlk9e5cwe3Um8duQ2AZ8Pkb403nFS0Oxgt2I2yyLHxcQ2wcdzxqUdisVx RrOj5NJOdihtgqRnjGumRmZpj+1Q2idjt03rnkuOPEPkj5C+NN5Rd7WjuqtNy6e/+eqm/DLjGiJH 6dWOSq9WTt7p9hkinzAumRrnzK0+9k63P82+wx7+KeXXLt9n2P0R0tdmJpyoHjnR9PeWx2W0PsPu U8Yr7P5/rfOwSA0KZW5kc3RyZWFtDQplbmRvYmoNCjE1ODIgMCBvYmoNCjw8L1R5cGUvT2JqU3Rt L04gMTQvRmlyc3QgMTIxL0ZpbHRlci9GbGF0ZURlY29kZS9MZW5ndGggMjE2OD4+DQpzdHJlYW0N CnictZlNq13HEUXngfyHM0xGr7u6qz/AGDI2GCFpZjJQnEcIOJZRJLD/fc59d62jS7A0CGR0+93b H+ft2rW7dp2acx/lqLn6MV4+86h13gbtqLMetY16RKvHWOeXI4+xjzp2OWacv89+nAvrinq0Uo4Y UY7s62hZ8lgxj5557lr2PHKcX527tWOMVY9vvnl6dd+8HK+f3jy9ff7149/e//r03Q+3s8vt29vg 5ee/Hk+v/nGMfht/++0f/3Bfe3vC+9o3v7z7+ekvP3789O6n2zZ/Ov583PbZ839b+PurvvSo3UfN Lz7qCR3n/fTPvz+/rGsj7uva6A7SwXAwHSwHm8EsDqoDN5zNgftM9xHXtpzj47fl6ctVy7O2O2/n bOdsd94+4WZVL8VBdRAOmoPugH16dVV1TnVOTQfDwbVqOfD0cJ/w9PD0cOdwn3BVc05zTvP05unN Vc3Tm6c39+me3j29u3N3n+6qdE46Jz09PT1dlZ6enp7XPp4+PH24j4zq8qfLny5/uvzp8qdPT5+e LqO6jOrT05f7yKi+nLOuOZ6+PX27artKRqX8SfmT8iflT8qflD8pf1L+pPxJ+ZPyJ+u1ajngCVP+ pPxJ+ZPyJ8Odw51lVIY7hzvLsWzu3NxZ1qWsS1mXsi5lXcq6lHUp61KOpRxLOZbdOenpsi7lWMqo lD85nKNYpYxKGZUyKuVPyp+UPyl/Uv7cL53XlxT/jmq+/e2X56c3Hz98+vHj2w/Pz6/fv//49Ord h+efX/487sfepBQmr/vxgRBlH3zN2eUSr3HdKdd235+K/t3zb8fk8O8//evfPxwvd9zLmgNSx8st dxu1Q3D7yz33cub9orsNx/2meznntuf5mHcsSRzSBhiQZS+723QEmtQhcUgb/hOV1kQxPUyKwu+V 780I80D2y3DpLGJyWOZKynbdJqTsJbVqgklpUklUiXb/lGZyyotQasksFUryyB0vMyJfFR5Vxmtr s78EIEQBXlGSz8Hn/f8KpCQQkAC3qP5+PyeQigDHQCgCnQhwDXANRCLAN5CIAOdAIAJ9COQhUIcg DoE2BNIQxCWIS6ALQXyCuyiIU3T26+yHagSZE8QtEIggboFOBPdNELegWgmKlSAxgyQKqB/ELbgx AqoHFUjA8iBuwdUQ96Ljnh4B+RtkbwSxEcRWK598X/3+/nCNoDWC0sLv2RfwG6A3QG6A3AC5AWID tAb5G4LbALFxbzdAa5DfMtAq0ErPQs86ryGhDeFoJEEDRAu6hmA0LlZrtwaIVm4WZVZgHfwsxDri YRlmFWYRZqFlVWVR1cGzQ24rKssnqydrJiulDgktj6yOOjh2xMRiyVrJUskqyCLIGqhzhXVwtiTq 4GxBZD1kOWQ1ZDFkndPBvUNiy56OCHXiYM1jyWPFY8HTiUuH5NY/HV5b61jqJPGx0ElE3aLGmsZK xvrF0sQ6xDLE4sOSw2oiEQlribzH5Z50CbkT8BPwLSES8K0SElJbLCSgWyFYDiTKoO1LwMRSnZ/M o6JMwEsUPSF1cvePUvjsfCaf93kDcRiQegDi4EYckHtA6oGCD8AcKPQAvIEiD8g9AHMA4kAkBiQf kHqA4wDHgcIOFHZA3gGOA4c4hr+zD3gOCq6BWAzwHJBycEMO8ByQdIDngIwDMg7IOCHjhIwTPCdk nOA5IeVENGb1d6odcJ2Qc3JjTkRkgvcE74mITMg7Ie8E/wmJZ2M94jzBf3IDTkRmQu5JXCZ8nojN JC4TsZmIzSROk7hMxGbC94nYTOI1EZtJHkziN4nfJB8mcZxXbcg84jctFhGdSfzmsoi0iuR84jip cBZ5sBD7RfwW8VuI/KrWn8xDTBbxWmGJHXw+iMKinFkEYxGMRXIsgrEAfZEMC6VfBGEB9kJMFsmw 0t95GMBdgLsAd5EMC+VeJMUCzAWYC8VeiMy6Km1LbX4HzEUyLERmA+oG1E1ybJJhA+YGzE0ybERm A+oG1E0SbMRlQ/YN2Te4bvDciMyG7Bt8N7huKpENrhtSb/Dd4LqpSDb4bnDdkHRD0o1ob27IDUk3 uG5EfIPrhqQb8d6QdethEJkNrvtyM5zz2dboa2wAlMvZFE0din4OpoPlwH1sCZTqPjqioiUqNgmK 5qjYJCjapGIDoFyWUrtfdPlFc180S0UHX3TwxZ5Q6c7RrxetU9GvF01T0aYX7VPRPxUNVNFBFS1U sXFYdLJFd15058UWTtFIFbuDxaZgsZdT7NwUOzdFm1X0WWU/yMP5F89SDeNlVKt9nGrQPnvVy6xe btU4VONwGdVqHKpxqMbhMq3VOFTjUI1DNQ7VOFwWthqHy7xW43DZ2GrfrdoluRxttaVb7eRW+26X q61GptpTu4xttadWDUg1IJfJrQakGpB6AW4mhZmk5T0Hen2RD9NF21v1u1XDW3W8Na6Wgb2wuJoF hkA7W/WtVaNadapVi1r1plUzWnWjVTta9aNVQ1p1pFVLWvWkJyM81JwIYxH2FTSo58CdjUWYJWGW hD2ssA2hnz0H/ssmkJa26mnPgavMpDBvwr5EGLi4mukGTptb9blVo1ub8WqmTFPMNL1V11ubgWsm UTOCOuCq9T0Hzrk6P0aw2fNpBq7Z/dEBnwnnHAPXTKJm4LTDFT+MZjy8HPnKG5CrHeVPNoY0xY+v Oa73FD6U6dKUrYe3G195l2En3LzRKJ9qYiv785uLr7yesN1t3nTh70rXw8uIL79x6J5llnTh1zk/ vl/48ksEO73ddOmmSx/XnOvdwVfeFDjHVNAQnwM3vN4LmAFd5LsZ0A3Bw1sAe8jl+skessg/9Pz/ b4393+nef7lpb5akYUrlzfb0Q4vetz9pmNIwpa94Hjrz7mN09NY1VbWHhrxz/uu16vX28pZ2/wFM g7g3DQplbmRzdHJlYW0NCmVuZG9iag0KMTU4NiAwIG9iag0KWyAyMjYgMCAwIDAgMCAwIDAgMCAz MDMgMzAzIDAgNDk4IDI1MCAzMDYgMjUyIDAgMCA1MDcgNTA3IDUwNyA1MDcgMCAwIDAgMCAwIDI2 OCAwIDAgMCAwIDAgMCA1NzkgMCA1MzMgNjE1IDAgMCA2MzEgMCAyNTIgMCAwIDQyMCAwIDY0NiA2 NjIgNTE3IDAgNTQzIDQ1OSA0ODcgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgNDc5IDUyNSA0MjMg NTI1IDQ5OCAzMDUgNDcxIDUyNSAyMzAgMCA0NTUgMjMwIDc5OSA1MjUgNTI3IDUyNSAwIDM0OSAz OTEgMzM1IDUyNSA0NTIgNzE1IDQzMyA0NTMgMzk1XSANCmVuZG9iag0KMTU4NyAwIG9iag0KPDwv RmlsdGVyL0ZsYXRlRGVjb2RlL0xlbmd0aCA4OTI3NS9MZW5ndGgxIDE4OTIyOD4+DQpzdHJlYW0N Cnic7HsHWJRX2vY5884MwxRmBmZgYIAZGIoIggIKVkaaBRvCKKgoCLYkNuzd9ARjqimmml5M4jBq xJhiEtN7Nm2T3cRsskl2NyZmU3Zjgf8+7zNH0WRzJbvf/vvt9XHgnvs+zynvOc8p78PlyDhjzIkP LZtQXjNqxNEV36YxzbN3MOa+qKK0vPb7s2PWMPaqizF7n4rSMWVTBox8m7Hngozp544or6j87Klv jjHNU7sYU74cMWF8zbyWwecwdnAk4zeaR9QESp/+4OMupllby9iI6eNr8vJ/+OTdzxnj7+Kpjc3z mxbdOfPONMZ6HcMAzM3Ll3qDNxx4g7EphYzpEmcvmjP/++/HmhnrY2AsMmFO05JFLJH58PxtaG+b c9aq2a/czuoYmzGBsf53zJ3V1PJpeudQ9D8N5QPmwmB5IGIj8luQT5s7f+nKx++MjWFMU8xYxpNn zmpdsG3sLZGM7RzCWETOWQubm5Lc9ocY2/ItY8mV85tWLkrpk3Yr2negvXdB0/xZGcurUfbwXMai YhctXLK0y80uwHg2ivJFrbMWnblD04lHY05pNiZ8q7u5Y1+jYeIM65DvWDymgbTvL2tfEvx06nWr jx45vinyiwg8k0UyDaOEdnrWyfgB47ajR45si/xC7alb0pYIizWVNTKdatAwG8tjs7BKl+O5Iina bH45Sg26rboCdJlMrLzGLtAwA9NYdRqNRqtotB8xTZef3d+ljgBpbI3Xy/yYjo3GEHGzJsPL+C1q p3t0UWKm6D3q5Gj4qxjRrWJdfn3SlrOmn7R/we7/Z/oTSWdmU3+uXKP95/tWGn66rf4ddr+u90+X 6caw5l/zDG3qyX60daf2qTzARvzkuD5l1l/zjJ7Uk/4nkvIWm/Zr22gL2VZlJpvyC+s2nvK8o6zh l7TTLGbpv3Zc/z+TcoD1/yX1hK+k5m+z8//p591+Sj9bf6qOvoVt7f68H42l+Jet2Yn63frSvHBq v0oKq/4lfWgeZCm/5pn/SsJ4t/zSuspNLFXX8eM1VFawLOUWlvojexar/1fH15N6Uk/qST3pvydp buDGX1qXd7Heaps0tk+jY9f++0Z1MmmWsIpfVX8+Ox9Y/e8aj0hKf7bp39n//9WEv9kfBFqBOUDf //R4/tuScoxV/qfH0JN6Uk/qST2pJ/WkntSTelJP6kk9qSf1pJ7Uk3pST+pJPekXJSWMRPqGHU9G DkoxMi0X38brxbxMy8TX9iwslWWxXFbIBrHhrJyNYKPYBFbL5rFFbDXbxh7w2rq61D4taNOLZbN+ as0yteYYNpE1sTNZ64mavOs7PGcS8IiS1PUUY10Huz49ObCuZs3TH88Mf+8vDcgIF2SELTmsL/Oz 0SdnooxWrtUOVQJKq1LHopmLDcMoK1gVm8ymsOmshWu4ldt4Ak/mvfgEPoU38LP4Qr6ML+fr+MX8 En45v57v5vv5E/wZ/ix/ien5F2rPX5/+7UPkNeHvKmrYzyd+cmzdnL5e2cDYibEKyyHlS+Ur5XC3 OpNP6UcLiDmJlAnkqerkDBnN8R8O40dzh63b7JH78fz/dyflf7S3//O73T+iZcb0hmlTp9TXBWpr JlZPGD9u7Jiq0aNGjqisKC8rHe4vGTZ0yOBBA4uLBvTPy+2T0ysjPc2X6nE57DarxWSMNETodVpF w1lOha+y0RvMaAxqM3wjR/YReV8TDE3dDI1BL0yVp9YJehvVat5Ta/pRc/ZpNf1U03+iJrd5h7Ah fXK8FT5v8OVyn7eDT6mug95c7qv3Bg+peqyqtRlqxoJMSgpaeCtcc8u9Qd7orQhWLp/bVtFYjv7a TcYyX9ksY58c1m40QZqggr18i9p5r2FcFZpeFYPaNcxgEY8NKukVTS3BCdV1FeXulJR61cbK1L6C +rJghNqXd54YM9vkbc/Z33ZJh43NbMw2t/hamqbVBZUmNGpTKtraLgzas4NZvvJg1upPXJjyrGCO r7wimO1DZ1UTTzyAB3XpNp+37TuGwfsOfXGqpSls0afbvmNCiimecBPKpWYYG0aI+aWkiLFs6vCz mcgEN1bXUd7LZrpDzJ+XXR/UNIqS/bLEGRAlG2XJieaNvhSxVBWN4d/lc13BjTO9fXLgffU3Hb8o 9waVjMaZzXMFN81q85WXk99q64L+cgh/U3iuFe1981C/qRGTmCfcUF0XzPMtCjp8pVQBBq9Yg3k1 dWqTcLOgoyzIGpvDrYJ5FeViXN6KtsZyGqDoy1ddt5cVdB1sL/S6dxbgzNeLcQRjy7AoGRVtdS2z g55Gdwv252xvnTsl6K+H++p9dbPqxSr5bMGsg3hcivpEtRXmdlptWVnMPCLd4K3TuJV6sVoweCvx 4SsdggIblkvNihUtHeKt424mq+Ep4RpCndIPMkp62UhRpIimZSPdKfUplH5mSO7wmHTpQUO3vmww nBgTPecfDo1qiwFleStmlXcb4Cmd6sIDDPf20+PUCF+EH4wWBrGcI2WRko6TC5sG3agmsYoub5BN 8Nb5ZvnqfdhD/gl1Ym7C1+r6VtX4qqqn1KmrHd4ltafkqLyYckGWgmKZ0ZRhD1Zmu+WyqvkRav5E duRpxaNksbfN4KuqaROd+8IdMi9OECatzxjVtKk4uhBHsxK3m6+yyee1eSvbmjq6Ns5sa/f72xZV NM4dJPrwjWpp89XUDXGrY51Yt869WjwqmlXxqtrSPjm4e0rbffyi6nY/v6hmSt1eG2Pei2rrQhqu KWssrW9PQ1ndXi9jftWqEVZhFBmvyIieJiJjUOu79/oZ26iWalWDmm/u4Ey1GaSNs+YODdls0qaB TUs2v2oTCYvkmgsX47qt8LaI5VlbP7etsV4cLhaLpcQvD3LfMBbU+Ia1c43eHDT6ZpUGTb5SYS8R 9hKy64U9AhuDx3I4R9xJbY0+3FPYUHXMzWkrKqJLb0dXV21dysvuQ/Up2GrTgCl1wchs3P269NGo N0KgEeYRwY3NTWIcLFAn2kakj2qux7aVHaLKqGAkeogM94AalWobsR3RqBlrgwVU229EJrixPlif LR5aN69e3c62IBvpG4Rlpz51GeJBefVt0b589WziKBjTLxQUibGxmjqyuJHFw+rJSRFmjLzZh6Lm Ri+8rWXNNdjqdJca3WSZhStRmzFLhdEdLmRiWkq6yWIMRuaiQ/wKbcoVR1KXHlFfT4NXcxeGK+DZ tqAJI8ro5spwA3gHRaPEWPB7IYYqqj4huqnuYBN9K3GziEGrPUWgOGhJH9WEy5/am2DxFcvGBnFH mMJ9HCBrhJi5GX5X0ms7uu72rUrplvrk+MTLQWxM5t6Ljc3q2043BKdm98kxnG61qOa2NoPlpxuQ vwyWEyyM3gq8NRgLRSreDs15uyJdfDTEuVKcI8XZUmyUYoMU66VYJ8VaKdZIsVqKVVKslGKFFMul WCbFUimWSLFYikVSLJRigRTzpThLijOlOEOKeVLMlWKOFLOlmCVFixTNUsyUokmKRilmSDFdigYp pkkxVYopUtRLUSfFZCkmSRGQolaKGikmSlEtxQQpxksxToqxUoyRokqK0VKMkmKkFCOkqJSiQopy KcqkKJViuBR+KUqkGCbFUCmGSDFYikFSDJSiWIoiKQZI0V+KQikKpMiXop8UfaXIkyJXij5S5EiR LUVvKbKk6CVFphQZUqRLkSaFT4pUKVKk8ErhkSJZiiQpEqVwS5EgRbwULinipIiVwimFQ4oYKaKl sEthk8IqRZQUFinMUpikMEoRKYVBiggp9FLopNBKoUihkYJLwcKCd0nRKcVxKY5JcVSKI1L8IMXf pfibFN9L8Z0U30rxjRR/leJrKQ5L8ZUUX0pxSIovpPiLFH+W4k9SfC7FZ1J8KsUfpfhEio+l+IMU H0lxUIoPpfhAit9L8Tsp3pfiPSl+K8W7UrwjxdtSvCXFm1L8Roo3pHhditekeFWKV6R4WYqXpHhR ihekeF6K56R4VopnpHhaigNSPCXFk1I8IcV+KR6X4jEpHpXiESn2SfGwFHul6JBijxQPSbFbil1S 7JQiJEW7FEEpdkjxoBQPSHG/FNuluE+Ke6W4R4q7pbhLijuluEOK26W4TYpbpdgmxS1S3CzFTVLc KMUNUlwvxVYprpPiWimukeJqKbZIcZUUV0pxhRSXS3GZFJdKsVmKS6TYJEWbFBdLcZEUF0pxgRTn SyHDHi7DHi7DHi7DHi7DHi7DHi7DHi7DHi7DHi7DHi7DHi7DHi7DHi7DHi7DHi7DHi7DHi7DHt4q hYx/uIx/uIx/uIx/uIx/uIx/uIx/uIx/uIx/uIx/uIx/uIx/uIx/uIx/uIx/uIx/uIx/uIx/uIx/ uIx/uIx/uIx/uIx/uIx/uIx/uIx/uIx/uIx/uIx/uIx/uIx/uIx/uAx7uAx7uAx7uIx2uIx2uIx2 uIx2uIx2uIx2uIx2uIx2uIx2eNlOIRA1h5KHeRAzh5KdoHMod3YoeRBoI+U2EK0PJZtB6yi3lmgN 0WqiVaGk4aCVoaQy0Aqi5UTLqGwp5ZYQtZJxcSipFLSIaCHRAqoyn+gsojNDiRWgM4jmEc0lmkM0 O5RYDppFuRaiZqKZRE1EjUQziKZTuwbKTSOaSjSFqJ6ojmgy0SSiAFEtUQ3RRKJqoglE44nGEY0l GkNURTQ65B4FGkU0MuQeDRpBVBlyV4EqQu4xoHKiMqJSKhtO7fxEJdRuGNFQoiFUczDRIGo+kKiY qIhoAFF/6qyQqIB6ySfqR9SXOssjyqV2fYhyiLKJehNlEfUiyqSuM4jSqc80Ih9RKnWdQuSldh6i ZKIkokQiN1FCKGEcKJ7IFUoYD4ojiiWjk8hBxhiiaCI7ldmIrGSMIrIQmanMRGQkiqQyA1EEkT4U PwGkC8VXg7REChk1lONETCXeRdSpVuHHKXeM6CjRESr7gXJ/J/ob0fdE34VctaBvQ64a0DeU+yvR 10SHqewryn1JdIjoCyr7C9Gfyfgnos+JPiP6lKr8kXKfUO5jyv2B6COig1T2IdEHZPw90e+I3id6 j6r8lnLvEr0TipsMejsUNwn0FtGbZPwN0RtErxO9RlVeJXqFjC8TvUT0ItELVOV5oufI+CzRM0RP Ex0geopqPkm5J4j2Ez1OZY8RPUrGR4j2ET1MtJeog2ruodxDRLuJdhHtDMWWgEKh2KmgdqIg0Q6i B4keILqfaDvRfaFY3Nf8XurlHqK7qewuojuJ7iC6neg2oluJthHdQp3dTL3cRHQjld1AdD3RVqLr qMG1lLuG6GqiLVR2FfVyJdEVVHY50WVElxJtJrqEam6iXBvRxUQXEV1IdEHI2QQ6P+ScCTqP6NyQ czboHKKzQ84AaGPIicuYbwg5B4DWE62j5mup3Rqi1SFnC2gVNV9JtIJoOdEyoqVES6jrVmq+mGhR yNkMWkidLaCa84nOIjqT6AyiedRuLtEcGtlsaj6LqIVqNhPNJGoiaiSaQTSdJt1AI5tGNJUmPYW6 rqcH1RFNpuFOogcFqJdaohqiiUTVIYcfNCHkEE8YH3KI7T0u5DgXNDbk6AMaQ1WqiEaHHIgL+CjK jSQaQcbKkGM9qCLkuBBUHnJsAJWFHBtBpaHoStBwIj9RCdGwUDTe73wo5YaE7PWgwUSDQnaxNQYS FYfsI0BFIXsdaEDIPgXUn8oKiQpC9hxQPtXsF7KLifUN2cXZzCPKpeZ96Ak5RNnUWW+iLOqsF1Em UQZResguvJRG5KM+U6nPFOrMS714iJKpXRJRIpGbKIEoPmRrALlCtumguJBtBiiWyEnkIIohiqYG dmpgI6OVKIrIQmSmmiaqaSRjJJGBKIJITzV1VFNLRoVIQ8SJmL/LOtMj0Glt9hy3tniOQR8FjgA/ wPZ32P4GfA98B3wL+zfAX1H2NfKHga+AL4FDsH8B/AVlf0b+T8DnwGfAp1FzPH+Mmuv5BPgY+APw EWwHwR8CHwC/R/534PeB94DfAu9azvS8Y+nneRv8luUsz5uWDM9vgDegX7dke14DXgVeQfnLsL1k me95EfoF6Oehn7Oc4XnWMs/zjGWu52nLHM8BtH0K/T0JPAH4u/bj83HgMeBR82LPI+ZWzz7zEs/D 5qWevUAHsAf2h4DdKNuFsp2whYB2IAjsMK3yPGha7XnAtNZzv2mdZ7tpvec+4F7gHuBu4C7gTlMf zx3g24Hb0OZW8DbTmZ5boG+Gvgm4EfoG9HU9+tqKvq6D7VrgGuBqYAtwFXAl2l2B/i43jvNcZhzv udQ4x7PZeKfnEuPdnvOVdM95SrHnXF7sOSewMXD29o2BDYF1gfXb1wVM67hpnXtd1bo167ave3+d P1pvXBtYHVizfXVgVWBFYOX2FYGHNRew2Zrz/UMCy7cvC2iXOZYtXaZ8u4xvX8bLl/G+y7iGLbMt 8y5TzEsDrYEl21sDrHVC68bWYKt2cLD1YKuGtXJjR9f+na3u5Eqwf22rxVa5OLAwsGj7wsCC2fMD Z2CA84rnBOZunxOYXdwSmLW9JdBcPDPQVNwYmFHcEJi+vSEwrXhKYOr2KYH64rrAZNSfVFwbCGyv DdQUVwcmbq8OjC8eFxgH+9jiqsCY7VWB0cUjA6O2jwyMKK4MVGDyLNGW6E1UbGIA4xIxEubmpX3d fvdB92G3lrmD7v1uJdqa4EnQZFnjedn4eL4wfkP8ZfGK1fWqS+N3ZeVUWuNejfsw7qs4bYw/Liu3 ksXaYr2xilPMLXZsbaXKJeXE/fqrcx0b68uotDq51elxaio8Ts7sB+2H7YrzcdurNo3Vyq3WLqvG b0V1a5QnSiM+uqIUf1S/okqrxWPRiI8uixLrt8Aiesw0T6ittJo8Jk2gxDTepPGbSsoq/aY+fSuZ wr2cM24DKQYxCu70VOJc74zlOo73eXttTXZ2VYeBTawKGiZMDfKLguk14tNfPSWovyjIAlOm1rVz fml9O9eU1QYd4l9s1fz5mzez0qSqYFJNXXBbUn1VcCOEX4guCJbUHstK67OnL1m2JDt76XR8TF+y NFv9RY4vE7lsYRS/S5YiL36WqXmW/bOJqoFmLEFaKo1Lf77V//bE/9MD+O9P7Ux8yWB4l+Y81qI5 FzgHOBvYCGwA1gPrgLXAGmA1sApYCawAlgPLgKXAEmAxsAhYCCwA5gNnAWcCZwDzgLnAHGA2MAto AZqBmUAT0AjMAKYDDcA0YCowBagH6oDJwCQgANQCNcBEoBqYAIwHxgFjgTFAFTAaGAWMBEYAlUAF UA6UAaXAcMAPlADDgKHAEGAwMAgYCBQDRcAAoD9QCBQA+UA/oC+QB+QCfYAcIBvoDWQBvYBMIANI B9IAH5AKpABewAMkA0lAIuAGEoB4wAXEAbGAE3AAMUA0YAdsgBWIAiyAGTABRiASMAARgB7QAdrh XfhUAA3AAcZaOGy8EzgOHAOOAkeAH4C/A38Dvge+A74FvgH+CnwNHAa+Ar4EDgFfAH8B/gz8Cfgc +Az4FPgj8AnwMfAH4CPgIPAh8AHwe+B3wPvAe8BvgXeBd4C3gbeAN4HfAG8ArwOvAa8CrwAvAy8B LwIvAM8DzwHPAs8ATwMHgKeAJ4EngP3A48BjwKPAI8A+4GFgL9AB7AEeAnYDu4CdQAhoB4LADuBB 4AHgfmA7cB9wL3APcDdwF3AncAdwO3AbcCuwDbgFuBm4CbgRuAG4HtgKXAdcC1wDXA1sAa4CrgSu AC4HLgMuBTYDlwCbgDbgYuAi4ELgAuB81jJ8I8f55zj/HOef4/xznH+O889x/jnOP8f55zj/HOef 4/xznH+O889x/jnOP8f55zj/vBXAHcBxB3DcARx3AMcdwHEHcNwBHHcAxx3AcQdw3AEcdwDHHcBx B3DcARx3AMcdwHEHcNwBXHzrFHcAxx3AcQdw3AEcdwDHHcBxB3DcARx3AMcdwHEHcNwBHOef4/xz nH+Os89x9jnOPsfZ5zj7HGef4+xznH2Os89x9v/T9/B/ear/Tw/gvzy5ZkxnLOJmxjqvOuUb5BPY GWwJ24ifC9hmdhV7nL3PZrJzobaybewudi8LsifY8+ydf/Wr6t1T5yrdfGZW9jA9i2Gs60jXoc67 gA5dVDfLVcjFaL0nLV22ri9Ps33ZeVWXrbNDH82MaluL5g1Yv+HHu47g/Yp81wCR11wIbVVbfB1x c+eOzrtP80E1m8KmsmmsgTWyJsy/hc1l8+CZM9lZbD5boOYWoGwOPmcjNwO1cJeo+mSthWwR0MqW smVsOX4WQS8J50TZYjW/jK3Az0q2iq1ma9hati78uUK1rEXJajW/EljPNmBlzmbnqEoyWc5l57Hz sWoXsovYxT+bu/iEamOb2CVY50vZZf9Qbz4ldzl+rmBXYj9sYVeza9h12Bc3sBtPs16r2q9nN7Nb sGdE2dWw3KIqUfoIe4btZg+yHewh1ZfN8Bp5RPplturDRfDBWszw3G4jJv+tOOGt9Zi7mFtbeKYr YT+nW4vlYT+KmueiJvVC6yB6WXeaJy7HHEifnBHlrlbnf9La3Ss/Z5X+uLGbZ25Qc0Kdbv1H+hp2 E07grfgUXhXqNmhSt6i6u/3mE3W3qfnb2R3sTqzF3aqSTJa7oO9m9+Bs38e2s/vxc1J3V8QPsgfU lQuydhZiO9kurORDbA/rUO0/V/ZT9p1he+iEZS97mO3DDnmM7cdN8yR+pOVR2B4PWw+oNso/yZ5C XtSi3DPsWdxQL7AX2UvsVfY0cq+on88h9xp7g/2GvcMtUK+zP+HzOHtN9wmLYsMZ0z0MP9/IpuNH h1tpifIGbhGFRbCBbCwbx6Y+wix43ceyQXz3bmd5uaFPxGN4lWuYF8GAgXFe5rdqNZY9CQklvj39 9ZsV+6gO3mdXScRmhLklxz84/kre8Q8ORQ/MO8Tzfv/RBx/Zvn7FPjCv4KM3P+rXl9tT7CocUZqI CIfel5qr6Z+ZMaCgIH+Ypn9hhi81SqPaCgcUDVMK8pM1ikNahmlEnitvHJuijD+u16z3lUwq0CUn WB0WvU6T6IruMyTdVjM1fUhuUoQSoVd0hoheRaWpVWdVpL4XYU9yxiZFGwzRSbHOJHvE8fd1UUf+ qos6WqY96+gWRT94Wkmacp3RoNHq9R3Jrvjeg1NGTbLG2LSmGJs91hARbTf3Kp92/AJnougj0emk vo6PhVt8XUe063UOlsoy2E17WVrX57vMNj7G1xEWGR1dh3eZIExSGCH8CUKl28SnRf00q5/+Xjxd FOeY+Ng0X0b6t2aT2ZWa5DNaeKzWzMw2s2aH73Hfqz7FZ/aZo5MmRgd0AVZSUhI9cGBeXkODPW6g HdJeYDuUby+Ax7Mb6FXIsrPTY2P1qsszlRQlSvGlZmQMKOLk57gIn5KiXWbgtnSPJz0mUrvw+Kdn KMYYX2JSupUbeEhric9M9vZOiNKu4R/yJ4fGuqO0SoQ5kg/ufD7SEqnVRbljtSFTlEFRDFbT5uNr xP+na+o6rDXrkrGzZu5MZIOz4ZOdNj4WfHinVeUvdlpU/nKnWeXPd2Li2Y/h774o5uJ5LIVl8JxQ TI12H+/N+rO+PLc9chK22ZuHBHjeR+rkbG8f6Nc33RGl77ZV9M7w1hGbyulI1og9JqaqNWt0Bod/ xppR61+8bGzNNa9vKD5jSqXboFO0BpMhKn/84vGTNrcU9W++fOrYJdWF1gijXtljc0VHObIy3bV3 fH3Trcd2THN6e7ujYhKiHYkxkZl5mRUXPLF2zaMbhmfkZejtydgV9zOmvQznKpp52Ap/UkkKj3Fh 5jE2TDvGgTnHRGPCMS7MNmYf/sJlLIF8kxD2jcoWlb8XvkkI+yZhH/4WjYRvzKGoancHz2jX1bKS QyUnfPEmUb++DeKU+VJSM/rbCwcUpGDmEYXwhs8uHKG9bNKdh+/q/DIuKyuOp9/z+U3VuwsX3nfB jva197UO1Fx/z9E7J3oytedkeibf/vnWebvPG33MPmzjE2JNp3Z9qV2p87ISdps/KTHR6hLzcol5 uWwYr8toFgojdXVo7H4LezyTezP9mY2ZSqY1vP7W8Byt4fW3htffGp6jVXzPNa+QF7o6uHFXaurA vGH7uBG3lZFnhQbWODp4TnveJDFr7AE7XTUN4dk3NBwgBTO2/4/2wIAiu3CJ2CPCJU67I0rbbddo tSu1BnOEuXj6uVPOvG95ScXqe2cNWdO/8027XRuJ3X6DKTbaGD1o2syWftd8cfukhnsPXT76nFkV CUbt9JikGENGbsa4tscWrt1/XnlSEl+VmhbjthsMtsTozpiEjKRUl7nh/sNbrj8SbErwZSWkwpv3 dx3hdbg9nGzCnpK48XE74hQW9hILe4mFdwIL7wQW9hJ7GDvB2LV/j5OPNdomqtcAz8s+sfzp8uq0 h+9OJ68zOFLiXakOQ6QzJS4+xWFIwFx1ugizQfueVGKNsXuVKowqgY3cy5w0HGd4OM7wcJzh4TjD w3GK79yySOtEZwfPbterm5LnvSyHk35yM4ZHYxf+V6q0uD2OH4jLMjhSXWJI/DVxnVQ53DGR2IEP ymEdvTXSnsjIY/psnKwh7H6/rXHYomEaS9++cXl5xlyXK6HjFx4isTWT0/qZzUaxe41i9xrF7jWK 3WsUp9IovMu69vvjhavTBlSbXHGWPFe/XL2nV7UnIK/dkmhcuAWY6Jthx+PWtZ1Q9oFD8woKxD3c bTV8XNy9uIW5z35yicQ7ENcwLxAXsuoffbbB4YmPS4kxaDoLFJMzyeFMdpg0nSO4weGNd3ljInLc c71901yRfIWOX2BK8GTEz7e6Y8wnF3XO0S0RxghFiysML7qtJ+x39U4zJ/RyH5us3JXcO94UGZPk JM/iTWZnQ9n5OzOtVkfYmSpbw2xR+bBwpiPsTIfqzGRjbm6+cGa+yyo+UDHfZhYKVfJFFRtLLp5o zLVmauNTq+MDYoeo7hPO+5Hv8grCW4Y8lZGR6YuNdf6Ev5KVuIKMbrtKu97iTLAUJWT6fM7Oud7h iRqNxhDjcbk80YachIlJmZ4kOx+UNCC/n4trOEriY73RhhEOvNlNSfmZmoMD1w0eec3oY99EWISz LBHa+3qlGuOyPMefK2xubMgbv3285jG897S4DiLE/ylv7jqk/VyXgr/NMtlaf4JD+MAhNpRDXPMO cc07XOSmAn+kl/XFXzIKSw47Nzm8U5PDV2Fy+CpMDjs3eR9ehUYWj4vPWuMTJ0s36dTrvkGeMH5a qKTe9t3efdrPR1/1wZYr39pUPnrLB1sue3Nzxe7MqdctWnTdjKyMKde2Lr5+ei/NNTcda58x+a7v t209smPGpDu/uXfBo5vG1V6yb07r/k1jay97RLzZuo4oz+L8JbIstrI9TR+eiD48EX34yOnDR04f nohebIE4e5JwT5JwT5LNbOFjkrwoSxJfHmP2dNz2O/V6M6Zp2umsNosDFg4kaYPIzRGe66nHB7eJ ttsLTnnWv+KBlVdFxqTEi1uldwJ39h47b/6YrN2DJzfk3HLDuDmVacpVTTcuGNKZe+JcYKkj4kqm rZo8/ozCqOM/9BrRzGjGWhNmPICVsyv8ybZce5EBoy4SsyhSZ1EkZlUkVrkIq7wny49sVolduALK HnaNPewae9g19rBr7OJLZYm5tg5ueGiRn/v9cUPhgd0p1XHhS0Y4oeHQQLnk+fKuQaAXPiVqUJer /MglsXHJioiDInBMYmJjeWFGZkaGDAFMekdackKKw6Rd4ewzrHbwEukshAQx/YYnVC0Zl+krnTbQ W9inl2NplKHzePmE+JKCK+4pby714JIx4AzgiPcrnFziO/7bE058MNOjUyzFkxaWDZ8zfpAjKnvI uH6dH6clKeePmRcXoe8ckzJ4Am6bEV2HlGacm1Hss71sOIJlK8Lf4WEXDQ+7bnj4rhkedtXwDk2O PzvfH+PgY/L9dsTI+Wn5ZrdLtHWLC9xts4kPNHGL5XA/rOknbvGdbvW9uX9nfJgdxA9Z7XwMM+fu 45msCOFFht9k9xbxIr/JzMfYxb9oGoUqshfZY4d0cPPu4W5dVk1sB88Kn0MswSG7CL2zsxtsh2xi q4qVObE+ouC0A6qVB5T+6MnV/4OAVa80l624tWH4wsmD40wISgxRBRMWjy5uKEvLnzhvwdyJBYPn XVGbPXnskBi9VqPoTRGmvPKGQQMmFCbk15yx4IyaAn7m1Eub82O9qa50D/76iUjt5UsumlBQNG5w v4JhtYvHV2+Y1Mca74kx2V0x0YhjE31JSX1L0weMG5JfMLRmMdbIirP+DnZ+Kpu1x+UX0Z1deG2X iEZ+8cEXL1J71/7dYufrozt4r51J4bOdj3Dla9U5T2fbDkgPpZzcwynyOlNDhXcQKhg6t8gYBspi 0OnwoZxnQMigPRCTaDccvfnERpxpsCfGxNCfauIcT8OOK1FeYAXMz4J+r7XUU5pXqpgi4wrNGG+h 2D6FYtMU2sR2Kuzgf/NHscxMK+NmJs46GxTejYPCb8JB4SkKVrfvoA6Nwe+wxz3NCm2FmsH7CzlD FFuYO7x3B3f7ra+l8tRUbdKfc0cP/X/sfXl4XMWV7617e+9W9+1u9aaWWre1dUstqbXbkm2pjeVF lmzLNrZlg4zb6pYRaHOrZWPAEMySeAKD4UEyOMzL8iUhvJeQAWwwyyTShGdBxmYcAmYJMJBMwhLM lgy7dd+v6t7WYhtC8s0f874nFT5dt27dqvqdOnXqnHOL7hctqzRclCpytrapEdu9c2t3Rq0/Ftna 3RhV9F0NFvlW2A/Ud8NOV6+b9nJq61Udr5Zo2BaoVwTITY1doUXM9efkWxfcsnb5yNqK5vSP+q50 V69uXBRvq7YYsI3p/edt7K2Lf+38ku/f1Jo4L39z5+KhRV6LBXrYsqVlWfGy3sUdwyuLl9V11vvz CvMMos/my8spzHOWb7jq/Mc8FS2ly9af1wru3gHuPqPdyZVR++EwTFFTsEEVhQZVNBpUftFrxq+G I+SjmN8VoZtkRKKeIOV/hGrTiMgcRN4UM3IuU0N9UKOtOkK0D5Ss9C8TOxqRvVe7iq5Aqh49jVM2 xDTPujMbYsh1liVsV7zezBapt7vdbNN4prbnQHekbdmykMHhd8Eo0OmdktcHCyHcvmJFePvXN4Xv cdVtjEnNsaWh1iuXNHfN85HXRh+5bpm9pKl0EKKn0UD0tPOZdgQ5/fvS+YXi6mv/aXTpvsQiR9l5 NZN3rN+0sOcKrK4t4JgkPAG3dv+9uUwrKVb/K6q1//ohanqG1HUWUtdZSLUQQioz8fkmfSB0hDfH sqJWYvW9lh8zZa3ILzpC+EPOlcIfq+maNWatqC4/QnT3GldR/zlyipEpx+kxZWM924nWKSpJN9OF FiReq/ctbO+Kxr+RrF+8847NkbWt9V6jjndk2UILNzTtvjoY617YuLElYqEG6PfsPnuWrzjPEbvi /tHrf375AjGnwGt1eh2h/GA4+OA9m67tihRFCg1Otk63gS93age4Eq6R+3osv2UBMfsb6epspNZ5 I9XwjVQ6GqmwND5CPob3HFW4FlWZFVWZFVVXbFRlVpQKlMkZXGZuDPk11jJ69My7Ektdc791lbaD KiUmTi1neNNMnqZM+JlLEFvslFQJJSUzDa55wp16e242DRotv+OCnhs3hWu233LRmmtj+ux8KlPG Hy7Z29oCCYJELQ4uii0L+TICtHvVxlXX3rs9/ch1y5cu4c0ZW/T0UsjO9itjrfuSkKUl1ZRb3eDW HdBqEa6OuydWFm1oaRhqEJx0NTklGm1wBsvpflhOuVVO2VjO9Btk4ePDrZHvR3gajjlMV1udRhU+ jSpj7NrMPhUFp6H8CwbLJ76iOaDhxzTkhIZoNLnRF0tWet/cZh228lbjm7lMwLpV3bYzlVFqNS9F FGFDsRqg0BUGZ4iVa7bw8a5QA2OoXrgj5Dt9X2DZ8NpYoi1q0Zt1Ai/ozQ0bd8aG7ko1Ldz5nZ5L bt9W8UNhz+5FFzYXwOQPBdsv21jpynHprT5HltNmMfu8zubLj1yefuiapa0j3+py7rutsiM5j3qU xfIn/A3ay+BRJu5zi3QBsoXnV7WWP6Ot/Ko686vC5KeH7KvKio/IJ2IOEYZEselUw/KcklNVK6QO cQWz3GqopR55rPY9ZY3VPnZGTMKl4NbNtNwK1fhEbSYmwd+g0Rp0eleg1F9cJ1mfMJiNWoftCQNU E9xAw9WiSFXN1YUrBlYWnldkMQham9Nj1RrNRm/t2qbtenuOs0j67I8GM9VJZoPgkoqcOXZ999av bizNslmcfvoNTfWT/0PYLzzONXOruYu4EzGXo2I5XWXLDYC8XBKdpGN5bcsR+SPKghZ1feHzlQfo rRb9GmRjWTYH6Vjj19iqhFq9nkqPyPg1FstCpqJW7/frays0lMexOsrkLtpFlyTisa6y4pgZn8W2 Kr0wf+ULlvWvu1zb5gtvLFxRJp33/PyVFzwvreGULbNFCfucVFR/pPY4Za4H1ha1t+woFI9H8F8k QyjXwWO4kIzLJSEd9Jnbo1rHGZmbh+21roFRZWXDgCZ1JVPbaTPvhAEdsgrqlbDfabumMLem+yur 5/X4HZ7FDX9cMryusu7SH+4cuGN7uRislqqjNcX5RXUXXtNRujyfiHb75GSyu2p51JO8oHpF1LP+ orVvSKVe43W72pPNfiFdmF+0Kbr6svXleW5HZaCwkjfxwUWbFzQPb6gujm2uCzbPr/X5OsoXbSsp 7j5v1eXnVxgNwcn3LtwhzW8Lb+7Nn7fi9NamFt7gqygNuxYvyatqpvJ9B6y472BnruH2HGqpI2VO VX6dGcF2qoLtVCXeSbdlT8BM1a2Zagwz1R1mpjbM9J6Ji9FAVKDMB6dF92DFyqJlvg6mPpmzQqJq GErZjBtnB6PYbqK3n70nNzQoWvQ7Boey53or26qar2zFJQt3ZLbi5QfatlzREfRl5Jm3rdraWtS1 4fTXMyUz99/2tkW9++NUU14vf0LWaqOciwtyNz7YUrimcKhQcKu2nFvlAbt2sk8mvG5V0t0q09yP 8Dvh+7o+LwimstQFNj1gyo/hSXrc/JBPbGP8OXkqompDdWc5d6TOSbddKoyQQtJ8JgOc5QuaIvTf FAuE6/QKYD2paiorbcS/zMxfiZmv426PWVoaSGk1qY45yCoYBCfYMKtVhV9NjQgL+2QKv/oRPgSr 36KisaiCYVHhWlS4FioMOe6KCo4CVYTCXWDWhttyl9kzAgEviERhXsCeZVqw5pUM7ingIXIOcVDf TEA56glxu4UrDc6CHH+h16abvO5MjpDzDQ5fgddX4DJm2SYfJoNZZuagCvosI3l/MutswfjsKbLL lGUUsI0YLV5x8uHJYrtL5RlpBs9cXIxFZIdYRPbcEdjMbHP0f8c3icsYYnV+zx2BPWsufWcPTR2F 9gR29U7uzZjfQcPp7F1BiUjd0ZCX0uF1ZNmMlTu1pKnUOlWpdarGIVvRgYCbRpgCNUqUk8U7WaiT LWwTdrMHO6lP3dkcUpudYWO+e4YNyhgSeoR8BLUiEt197SthbupiWYtXNi+rmN9W0eGbMf8zA1aN avTC3piJVVP9wA7afpGS+Dyt4VK0hkcVFu0JRXk4DdnlrZWNI0vpJukJOvXu8iWVjekpXaJz5Hrc eaK+4+a2+Ztbq8SKte3Lizbtasuf1iqFjWdolbNL4HiaIUJGs2H3hjU50cXh6tYyJ9RNR0brYgZr uNtiNmUGKVEV8JmzpOrdM2eTukcBM7V4FT1Md0tFLTONjPsPqqqYKuKYqWJlma+oLcN6uk9O6eJM 9Ezl9pdQyK6/pJCnmPjNVX9BIc9iFBi0jepj6v+8DA7RyOmPYrktpSTsIKV2UpJFSiykxEBK9KRM IKU8OUe09JVzRkupeRqImohpRhhWmh2GfZg30YjQgzZu1TCmyUf/DxPbykL4SqpDSX0ilWXRqeBq d+bvL0VZhZebRn6SGvrBYEPjyI9H8DnvHn/zJWva+lqD/pZL1qy4pFUivx986Ib28646lMLnSnxe 2bZve2PdRftWrdwXb6zbuo9605O3Cc+AN9Sb/gr1poMNJlVKTKqUmDLax6SiN7Ft26U40sylZnEx xac+pyfdJq75XE/6XI70OWTk8x3pW7eGWxfHimYIS7bL79CXdqxaW7H976gjXcsc6WWh1suXNG+e l0Pe2PXotcvFgrrCyeaMLtS8AZkRBEjPnrLmUlfHdT8dXXpNYqGzdEn15MH1XQsTV6rakr+LRXZ6 Dg3XkxKbyqLpF4oqq2wqD22UVQ4u5qS7FlQeR3nG5YCDxTFjZGWJzSW1uegaYsqLbV+RKVtmpgF/ rmXDWKLj7+J1RoPBk1fk8lXVNxWeuWiKFzc15mUFi/IsGoEI290Bu9FoNGRXdsw7/U9nL5trG1pD NsFgMhmtfop4rXyKfxKI27gnY5Zoe0v7mvar23/arp0RQP1ADZyyFbOYhhecZwRWWUCVvBjLV6Ko LH5KlYsaRKUuDl1B/ofJB+xVmIlu8pYY2/hxWYL2Wiw/tfCWypfmmf5o77Rvsw/bBSVY+hsaKV3p fl0RrakwqRok7Yb9MzNIOm0L/bVBUv7J2q37VldtWlrlNmloEDTSsnF+WWuNPxTr3LA2Fipdd8W6 ohVNpS69gL3epDMWNLRFy2KlrnBs3Yb1sRCxLu3HfHt82UX5zhxR75f8jsKG4pK6cH5BpHnjwvp4 W7nF4RItNrdo94l6t8/tLKzKDdWHpYKyhefTuQjK7/ADmp9wTdyFh0o5e2GFyvMKdS4q1LmoULVY hSqVFVQILZ6silOFK/KyTnlWVB8hmnv1ihI6TsWuVo0+HH9MCc1ozu0gznYj3Rl3mh8wiFJppWdZ IpZ3lc1BI6V7M2bHazT257C9Nm+5pyg326A1ajUX5BWIVqOuuH1kNW9VPMSTmRddJxUfctLUfZHR ZNRavRT3bTROIzyKHe7WWD72NXOISlCISlCIviAJMbsiJDIDgnz8gLLS8lWu5KtcwedHbG3SDGVL fmax5qsyCgP645jRWdEWMmt9bTAztNPBGro+M5bFlEidM1gzbVhmzgFMhW3u1DvyXJ48u27VN9hG ps9WHGtPdEVV8xVL9dn5WLkO49T+tnvD6oU79m/nCzKr8/Sf11y0pLhrAz+aKaH8KYAFcAX4U879 7iGuUIZupmZbvoHS4nwSUDIB4lZxutTP7Gljjn06pt4Tye/G5tGXTNgj7SQkkrCWFIRRsKiAFBWQ IM22BElRkEisVCJFEgnZyK4gCdIghdHuWhGUsGpx9XrMCFEM0ggRvaIzEaTtW/BgMNwWNOe0mRUF SA8V0D8u0s32wYjyH6G7ocL3bnrIiJ3pmnq1Pb1BepyeeU71MNcVhBf4yeOarJxwIBD2WTWTT2q0 9CWsJ6/QadRMaoRPeZMz6PcE7Hrh2xqjyaL/7G56pkhjsJqETRaHUYCLw4MYT+dYLPwfjBaDwBvM lNv1sJivA7eXci8/xC2HeloEaPNp8KJ0PplHP4srSUmQlEikJJ+UBEhJHgnlkrCGlAqkaQFZ0EQW VJCF9NuJXWSVqLp/9DNmgriKEloQbWox/YxZ6EZCi22L21g9yswWcY04JF4tasSYw71CrG0rbms6 UE7K6b1yqjVFp3vFjvLd5fxSlHo6jJTJz1BOdj/W0nIcnFT4HVX0IcdsjinrQ2G0borPQkgvZFie CVvMYvmMrPY6jXbyQyHLEw7kl/kswj/z/E+FrJzSQH4IV5MfazWwlT25BQ6D8DzPT/BGB8Q+32Hg n+XJSd7oDOZ48+i06LNt05PC32Q0nh6ZniJbtt5oxgzB7zqdYzRihrKgeOGcnvZmrniDic5XKVZH O+Yryt3wEFcNxthpfJbqjUqqMRZUEi/k8QH6PsZLPKpucGeK3MRIpbWMemH0mYUcmV9IGszELFFj mc6K2VxdVdpWaLbntdmnDOLGFruDKOFHjjKWCq8iv5Fid3bmeNz06ThwVXUwnIyNbjeYLywxOEP5 gUKXWfPcsxqzqyA3r9hOjMQ7+aGBOENSXmG2SXP8hMZkz/fnFTt44+TH5VanRQtfU0+Sk9/Ch6C1 OK3kQXKX1ZmlEXQm/eS9ZI2OntUwZ9smt1LtAQvwSvCniFv3EOcH1nq68v2k1E+8zBX0khJrg5UP GUkO3ZKbcohvPmWcj+S3+UzONlO7Zg3XrrpgLVi6EWXR0sUbFBSo85wlJZCcOhUjqXWywJc7W8/X XqarrsmR7LzuSqMoTP7cIBYFAgXZRi0hwkc6e4GUW2TXTR4W7VpLtpU0ahwm4UKX16oVDLas05X8 SadZi33CASSbYew/KzzIRbgFD3EikLjpO/MS9uY8ivt1xlYjbyy2wwS/37fCFmKmOAZOg6c1sBWO Q++oDgs9QMQidWTWIS72ipvQLP+szmA1nD7p8lN5JDdNXi066QkjXmO2W/S0bHKU/NCQZdQtc/rt +txggdXt9on8JcFiB651Vrddsno9OeLpb+hFWFo8MckfkBe1WzkXV8pZD2uL/avEZWDqS0/OOHEh lEzFbc44rvrPenpcNNehtxODqzDXX+gyWI2+cH5+KdaDtzQ/P+wzktGMtSs8bHFYtDqL3fJpYzDi N5v9kWCwwmc2+yrAp7LJl8kI9wrn50z3mT25nPj0ceX1v16v6IB5zql+R3RWj32/Nsvpc9o9JqK5 3uwtyvEVecw359dVVvie1JsMbFkS51f8kqjTiRL1yB6RPyQ3Cbczj8x/L5d9hL/iQVOgEP6kbQXX crzlODVJas4+amI/E/ZNFKMUphjDEsV45rUgSeUUX7lUUEE/K06Hg0oBAEO151RQHfFNjGcQiM2c 5176wnnsAfpi2ShgMWMokXEKf0agbDDavLCS/htYHq1cin+0jaXkEF/JL+JsnPUQpzef0nD0QIka EQ4qzzLJqXTYJ7c68Ee+B/nQko9DgfySkoDOnoNWrp+8i/xJ+3WukCuIuQSqoARqGgtMiAVXvvl6 riUK7igv+nWwxRyeqeO2lQKTWUUNk3cu6r7oAi2x5vkcOU6L0LBufm5+47paYhRz3Z5ckdduf2Jy 88lnJ7f8q8Vu1vI6g7b3V8+9tHPni88/tUOj00FZiBTX5RjRaxhRkKt9iHMoloNDtTzp52E6Mgc7 5GBmvo0ywkjN1FkEfUbLNTjq6/iQKsMet4O8ljt/bYNgceY4cvKyiPbCrVu3angx1+PKtRv4HaO8 b+dLz/2qV2vQ8Vosq1+Su549Se56wiiaMDqd5vjkGsjS14Ve/qB2NLNu/CXLxeVYN8dnio+QcaLP KHG7+Gt1osfh8Np0HlN20OMNZhvJ5FdnlVWVCDdkFg75t0xusnp2mSiCV/dwnPBtrYer5H4fKyoK kKI8UpRLCv2kKIcU+QhVpR5SyoIPDrp/VLE3FjZ+1bYqwtETSlyparuXqhwuVa3YUtWKLVU3qFJ6 zMka8NKHvGZKzXZqMyjHf56+H23a1Te9M8rH1ONA78aMeOI7dmJ3Oo6QlvsL15WKR4heOU1Z03L6 OPOc6N9x+jIpc3aC6nYuMm0ldKu6MnN4AnpNp1gH84rVOJmd2WPf1pmy9Kcv1FvMOp0xy0Csn9D3 RoLObCRlGovD64DZq3sTGkvbSn0jvZjjdOTYjcJzt5s0WQGP3StadD8XNBqi0Zt1n95sxFIBt1Pg 9p3aINfM3RbLKm0gkQApzaMWV4yy1UPZGiNuGqBxs+XjltjOzlc8UFuMxDWqvG58mL+aMyvMMVP7 ykyjX/b5jZLU6D9CKh+odesq14uNR0g4wyHFz4yykDP12I9T55JFMhiPmCU1iznUODrjEIVOfRUJ tcqOndypNdqMp+utLpteMNksn27qa3Tk1nfWsSMU2Mo1vNbgXbD50gVbb+qudC+/Yeg4X2uwmbUr 6ZkavRhwZwc8nixiuvDWy7ZHIquaCgrCBQZHwAWH0uoqKvTWX3j50uYrbv5p6qTRwXz7HfCrbgX/ uoj2IW4LWJZLWbaFVBvAlGqqdqoZ36op36qP8PUx0+r1JatXe2HZx6hlX4IqJdTgjKG0JCZY/QYx 48uzJ/0Se32piKwfnD/MjCh25gB9cVZVNK2qtFvpxDkxDdYFNNC/IMa27gWEia4qwjETLVxgX2B3 Nxwh5pipbX35nyRJ20aPS5mnjktFTzWKUyemYMxGmd+WiQWwV3g0OOxoFDNR9IiqHHRMy09FBJSj oYofnCk51yS6AoJwa3P6f126eGdXk82gE6xZxvr1Q63nJVoLIuv3rLoCc6XXma3Gnef1tYVy6tbW N8U7akzURoPudTZtGIpt+doFFVLzlgVLhjorSGrzzb3zXHn5Vmt2nqsoVyqWCpo31MzrihVgebic Ppu+ILZ5XritIb8wXKi1+d02j93qxDxXnj+6fFHf2kYzr6/vvBQasgoW8K+12VwZ9NKnsSbqnlSQ UDkpCpGiElKcS0r8pJApqGIvKfaQEjcpcZGSbFIiEkxxkZYUaUjET5i2cijaqsLtRcYtieobLOXN 1SsP0jdbuZWVcFM+i+WhhkiXn0glQqROu0iddpFuayL9/wtCnEbRVRq4jZmDADETPQmgqYqG/JVs gjWRoCiagutMG5ifiFVXe6qmRrWvI2rsgh7qPR5RDpdkVuAZf2T26++ppUmmdZWbFJKg8Otsx62Z s8+n37SIWdgdTXrylNYZKA8EqwPirXbX5Hf5yQvIXWQ4WDL5bsZhJ6JODHidAZ8nS3BQO0uLHf6z o4X8G6eb6IpbxvULD2jc8EWy7ysrCtBvMLLoHFy09vjp47VfdCztjMPsD+hMVsPkEYM915WdZ0fO mGXSQccaSJvBnpdNt0/ksrCrx5x+Bz3BZqYn2DDAfoPD73SgDDkYH1rlpBvVBxz3XSWR6BekH08n 3veFaWx2EsxfmDZPJ41O893ppPV9TrqVJt0iJeltM9KuufS3JkPx56afGVeeI72qJNO+s5NZ+1+c 3j87WXax9M4Xpaz9LB2bTtaf2JpnpWPnTmIPSy8qyf69s5Mj8Dele86VnMnsRVPpuKtmKt0yl+bS /6fp5LmSW4+0xr3zb0i3fU56yVPxV6aR/3eSt8z7S9/Pcq79b5uemktzaS7Npbk0l+bSXJpLc2ku zaW5NJfm0lyaS3NpLs2lufTfO7Fv/CUcpw9zhER1HGcgOZyGc8jvgYYYbZffAE3I2zgNOSgfAx2T XwCdkJ/lNMIGzgbaxVlAU6jvwFNvg7YzmuBMnEPYIH/IeTmN/FvQBFrzouQJ0C75BBdCyQdcCG3+ DnRcfhP0qPw+6ATqN2Mkb4KG5F+Btsu/Bk3Il3DNJIx2mjGeF0DH5PtAx+UjoBPyvVwzRmXn2tHj G6AJ9NWONv8Megx9taP3E6BdaH8T6vSBJjDCTYSXnwYV5WdAc+SXQQPAuImEgW4T2cvyB+RXQA+y kglK0RoP2jX5KWhK/gW3BWN+GzQknwJtl98C3Sr/HjRB82jzRdC98knQMfkPoOPyv4NOUApOmrit GNV7oAnwYSvqvAE6Lr8DOiG/xm1FLx+CsxrMSAJ9nQQNyf8HtF0+CroVGBNIuVwCiOj3uosy/Xb2 HJl+L3xApt/M3inT74Qflek3z+9idC8r38/yNzJ6QKbfF3+Y5cdk+o354zL9Pv2jMv0W/QmZfn/+ MTnFJcCBStBN8uWgXXI9aEreRnjM0Z9BD8qnQMfkl0HH5fdBj7KSCfkFYkOdd0APyB+AHpQ/BB1j +XFGj8rPgk6w/DH5P4gIRO+A7gUN4Nm3QQ/K/wlKnwqwpwJ46lXQCflPoMfkt0gYTz0HKsq/Bs2R /xU0IB8HDbO7nfJjoHvlZ0APyL8HHeOyQMc5HegEZwJl7QDpPtAu+TLQlPwE6NVcgHSi/RdAReDt RPunQAMYYSfp5Jyge4G6E+N8lXRCMj1kC+PMFsaZLYwzWxhntjDObGGc6UebL4GK8gnQHPlx0ID8 M9C98iOgB1CzHy18AHpY/gPpx3juJ6Os5VHW8ihreZS1PMpaHmUt72J1drE6u1idXazOLlZnF6uz F+Ufgo7LH4EeBff2ovw/QY+BP3vBh9+Q/Wzu9rO528/mbj+bhf1sFvazudvP5m4/m7sbgegkqCj/ FjSHlQTQ2o3gP83vlf8d9ABQ3wj+O0HHOTMo5f+N6LETtEuuAU1hvg6g91OgB+U3QMfA2wOs3wPo 903QCYzwAPp9mxxEv6+BiozmoP5B9Psm6F7M6UG08DtyEG2OkzHU/C0orTmGmm+BBhgNYyRjbJxj eOoU6AHgHYMeMIGOcRbQcUYnGD2GGRnDmOOgXXIXaEr+FRlH+2+AimhzHO2/DRpgNAxJG0f7NE/b H0f7NH8QenactT+O9g2gEyx/DJwfZzwZR/uYJ7T/DDmK9n8DKspPgebIT4MG5F+C7oWsHkWbfwY9 iL6OQmbeIkfx1L+QCTz1KqiIMU/gqddBA+DABEZlAu1k5XtZOZW6CYZ6go1qgo1qgs3RBBvVBEY1 CNol7wFNYcUdQ/svg4osn4OxHUP7lIYxX8fQ/juge9ndA5iXYxgbLR8DB47RHQF0Qn4bK0fD2UET 8hXCBszaM9CVGs4C6pBfAA0x2i6/CZqQdwhdaP850E7ODXpQfhp0TL4fdFx+FHSC5Y9xJqEL47xZ SFF9AjrG6FG0lkKdt4Sr0IJJs0hDT4pzXAVfwNFvRaF/CUYFtoNa2RXN85xV0Kh5gasSHGpeM6OO FrvfeWpeN6Ncz30ibFHzBq5MOKHmjZykOV/Nm/jvTNU3cxs1aTVv4co0v1TzWfw/aP6s5q1cv/5G usezvxr9R2qecHpDmZrnOb3xcjUvcF7jNWpeM6OOlrMY71Dzuhnlem6v8Qdq3sC5jK+oeSMnmgrU vIl0TtU3cxFTjZq3cC5Tt5rPIh2mlJq3cg3mn2EkRGNU+azkFT4reYXPSl7hs5LXzKij8FnJ62aU K3xW8gqflbzCZyWv8FnJK3xW8gqflbzCZyWv8PluTuJquCqk+citYt/un+KGuBH86+XSKFvCfhVB +W2EOEr6kBvkKnFnMdePJHHrULaDuxj3RthVEp9J1N4FmkDNJXiuH3W2o6wPNfpYvTj+DaCtBKs7 iKsRlA2ye8rzfRiBhH9x1OtDC3twtRu5NPqS2G8xbEe+H3UlNuZRPJ1gv/Wwg7UypLaaRo0BtU9a QwLGIdZnkv2mA8XSxrD2oiTOfmsgxVBI7DPOUNJ+FRw9uFPOWh5gJf2sxTh4pJRnehlAO/2MY8Pq KAdRMsB6VdqkONMzRkB7HGZYMr9FoXBbGTvtaQgckNivMOxgXOhjv7tAf88iza4o4vTUfCg8U3qR 2NgHVVxDjLfbWc3pEc9ERLl2GXtOQX0priuZPMyczRBrbYC1sIfxYVSd+Zn8pjOm4E+y8VP8yryk mDTQT6VHOtcS2hieQqOMcYdaZwRXl6utp4FCmaFdU7MUZzISR+nALFwZae7BSOKs/x61/0omsTvY XNE7Z6+BprNQN02tmnpuoypFfaq81aPFBtw9t9QnVflV0MTV8e9gd5XxJFWO0TEmmOTSUV3K5izz zLnv9v5VK3haWpS52YCrPjYG2v96Ju3pWfMYVUcwNANBj7ru0gxlkslyB0p6uDCb41LUSbD2l7NR Kc+mkYbBxSjSbpYq2RqfPfJK1voA6qQhW3T8OxiCYbSwB6V0BnsZFrpyZreaKe9lvwiTYvKbaW8z G7MitXuYtI2wEabZuhphekB5WmIY6JpMMonqY30oHNrOns1wbyn41wGNqDybmnFHWc8JxpPpNbpb /SWViz+nX+Wa1u2BFI0yHiamZD7B7g8zid0zQ86HGdJBVdKVtpKM0pV7Jm56X9EQYTxVyqRzALiS U2v27FENntXyl+fRdOsZLS2pelaRnp5Z+u5s7NPyOntcC2ZwgCJRsChaPyP1qakdJMF06CDTpfHP RarwOT6Lp0lV+s9cA5SrVPJG2ZMJpo8omuRUO7RmP9NpXzRD/1XrYnpNRNlo6BpQdqJKNlfD3GV3 SzVVVfOlVX09qaGRod60tGQoNTyUiqf7hgYrpcX9/dK6vh0Xp0ekdcmRZGpXMlG5JN7ftz3VJ/WN SHFpYCiRTA1KI/HBEQn3+3ql3vhAX/8eaXdf+mJpZHR7uj8ppYZGBxN9gztGpCFUTScH8ORgQuoZ Sg0mUyOVUlta6k3G06Op5IiUSsb7pb40+ugZKZdGBuIYQU98GHn6yMBof7pvGE0Ojg4kU6g5kkyz Bkak4dQQxk2Hjdb7+4d2Sxdj4FLfwHC8Jy31DUppigMjwyNSf98g+hrqlbb37WANKx2lk5el8XDf pclKSYUZGpEG4oN7pJ5RgFfGnb4Y/Sd3S6k4sKT6ABsPxgek0WHaDVrcgZKRvstRPT0EQLsopLi0 O54aUPqibO65OJ7CwJKpynXJHaP98dTUDDRlum6iU1O/ESwCKKm+sqFmBuuT4C+6iaP9HX10HEkM LBVPJAfiqUulIXpnxmXvuSeYsQVoNgz2pfH8+nQ8rWCMooEh1kEP5i6d6kuOVHaM9oTjI6VSIikt Tw3hbjo93BSN7t69u3Ig03hlz9BANL1neGhHKj588Z5oT7p3aDA9olal+d44AFxK620eGgVr90ij I0kMApDobSmOmUymBvrSdEDb97DhLd3QsRh3U+wC85wYVWZ098V9PRfPeBaffYM9/aMJyoshKdE3 MtyPDijPh1N9qNCDWsnBdKWU6XtoEAIR7iuVkgPb6UPTTQ1mKp9zRKw6FWmwfwTs6VHkbqp3xle1 rQVsAOE+9ALRp6xP0QWSGNo92D8Un9kpxhxXRgrGT83A0Gh6eDQNtu/q60nSOhcn+4fPAPRl5oLN RDSR7I1jEVXGR4Yvm/IHOdnL3XCOH3ijvpYA38LEOTm9LMOP5FUvioOPzXGvKDHYL/jTaBZZLAR1 eMOXrZ+Vxeq//mXr22y0vvD4l60virS+5kdftr7dTutrv/Zl6zudqI9PjnqVGlafetU1jDq4LM7L 5cBaDkEn13HNsBRaudWwGi7g2qG1N0E/b+H2cVu5m6Gx7yQ8dzexcYeIyI2THO4YCXDPg/P/Ac/+ PbKFmyTdxEz6iZcMkWIySmrILrKI7CUryH6yntxItpED5FJyEKWHyT4yRm4i4+QfyFFyN5kgh2iM QlhJjgkbyPPCJvKq0EXeElLkfeEq8pFwNa8Xvsm7hVN8QHibjwjv8POFd/mlmkX8OszNhbPx8du+ BL4e4BsGvr3A93fA903g+z7w3Qt8jwLfL4HvGeD7HfC9DXyfkS3ECHwe4CsCvhrgiwFJO/BtBL44 8A0C3x7guw74bgG+O4HvLuA7Any/AL4TwPcb4HsD+N4Dvs+EFM8LV/EG4PMCXxj4qoBvEfCtBL5N wAefnR+ejU9zYgY+D/AVA10t8C0GvjXA1w18aeDbB3wHgO9/At+Pge9h4Hsc+J4Gvt8B3zvAN0nC xEQ6iY9GU4FvHvAtBb7zga8H+HYB3z7g+3vg+0fguxv4DiP9Avj+DfhonOxt4PuEHOONwkreJWzg i4RNfIXQxTcCXwz4lgFfF/BdAnwjwHcN8N0MfP8IfP8b+B6cjU//1Rn4fMAX5uiPB0S5ZcC3AfgS wLcX+G4Evh8A3yHg+wVKnwK+V4HvFPCdJjmYrwBwhSGLnaQe+FqB73zg2w58KeDbB3S3A993ge8n wPco8D0OfE8DH41f0sjhJ+Qon0UmeB/whYGvDvhagW8V8G0Gvm3A1wt8e4DvRuC7Hfi+D3z3A9+/ AN+vgO+l2fhMiRn4/MAXAb4FwLcR+HqBbxfw3QJ8Pwa+CeB7FvheA74PCU/0xEayiQhMOZDBAFlC 4+5IceDbCXz7gO8W4Pse8N0PfI8D3zPAR2PF7wOfTA7yFnKY95MxPkzG+XrgWwl8m4BvB/Clge96 4Pt74PsW8H0P+H4EfI8C3wngex743gC+j4V3BaNmkeCDriuejS9r/wx8ecDXBHybmFXYzF0PfN8A vvuB7wRK6budSW4r8XMJUg58/5e4M4GPqrob9rmz3LmzJITIEhYlAUQ2EYEKBYSAEdkMEcVSbHUE BAeRhtWwD0nEoBSjIsWlitQiVYuUtFZbOx0gjSCLiElMCcUQCCodIFJmmNKU+z7nzGRD+tX2972/ d47PnXvvWea/nf85M2aGW9FvHPr9EP0eQb/l6PcU+v0U/bZxN4h+h9HvJPpFtEX4Zjm6rLH00NZa BmuFltHody/6zUC/Bej3FPptRr/t6HcA/Zh/ljPod9E62Wq3zrN6rCusydaV1husP7EOtZ6xjrKe tX7Pes76MPotRr8N6Pe6XGcMB/8lJXXvnrEsN9ewa4aeXeDnUZBt6Jph1Bbk8yioVReDMvz+l/Mz BhmaZtj88Ydh0wx7/LzWMDTDtXv3z3m88ILqU1z8+uvr169dqy5y8tUjR71ObUFBQa0cgAuHuigs KJCj6d5Cf3pqUqHXsAtDj6bGHrpd0x21Rk5Bgeru4NUKZCfdpun2bPnq2eq+IZvQSLXPLoj6/TmG TRi2vum16fJBI13PKSz0+rNRKzbS9j2yS0wt0aiW7vcXbgpu2lTYTGHd0HTXu3vX8FCvEescfzke UgzdEROO1lZNt1XFOiKpnu0P9k2qctiEwxYTqK/qKVtvfFi3C91eUJCVhbpOoTsL/AX+SeSGzpRY HTVZBUZjs/R0+QL2Kk78VU3EFH6rRWhW7uqaplv9ctX0azysfs1KXFe5LLSlWj3S09WlPJEPv99q xambNm1SHvBuUg6IqovsAsNISk1vuMg2DKkxF337ZmUVRpOS7Ein0zw1tXlsEQAOGUF+PxH038SW UzPcO/07/Zsp6ynSOs1jzKEZzkEZuTwYqCGs/qsYc9o1p8PfNMj0WJCpCqMhymSFt7BWVtiEkyi7 WpjVD3aVOHPaNCdxFg80p6Y5G7T/TyNNToTtwSsiTcV++tVDTf9/hJreGGr6VUKtqaD/NtbcFhrX xxoxpq7rgy0Wbc5YtOGlxmjjojHaYhfxaOOiPtocduHQU1W4pTqdwuk0RCvRSqkxQv7rv9LEDs1p DB2pXnzkUHnljObLIMnNj6orWbcuN5e6ZuaXXtPrL6JOl+b0BHm8lv5a+rOqrKU4Dc3p2vnaa8+s WfP443nqaujIVfLBcDovHCXGo2q4hqsCAl+FhEy1SiWnQzgdl5PiD4ddc0htc/CTS9dcBr3fK6Zn 8XuyKpahC7JVlc1mW7CWqrULHLrmkBm2zu9f5rIJl70hFtNp6XAskxHjp0FOszERRWkdj0e/y665 ZKwWyIgsLHBpmqvRJH6HU3N4isR+NfliRb1ufKh6GfJjrxK/X/ye7GnTHPHwVOdyOnmTkqrktLHX S9pXDaD6o5A0g4w9gs/hEg53RnpGek+/LC1FSxGrpjIrq8DVpCnxqcavTZKRWuvSLK76HIKONouw 2GTUOTTNgWIyVv0WTbNwrlk1m70qwaq57KlNwjVV3ZEnsQdVNpvm0gt5KDfGQzY1GncqMSuDtuEq 5mLc70jp3n306II6w3DEUmOS9LmLt36EbWPgriR0lSsMzeUcNiImx4hh8tJVl6uCa1VunbpUtU+v WkVtc0dJHzsarupcbs2VEPQGvUyzTc+kPpP6JCWfokaR8RsLYJdTc7mHxV+//iE34CpmZPTGgtnl QLTYJcGcq4JGhqU3SerqcgiX0RDOSfGosC3DqW5dc8vYaxrQjnhAqzrb1SPabRNuGdENIe2gboWM Mz+Ly7Lmw14Z02675lbGiAe1W9PcTWz1/yuqpSo5akbX/m9HtVuzuOuj+tuFdaJVczcJaxnO6lZj XMcD260C22W3uIzUhshW7seFNpWP6xouc/BWPKGkNAtuIx7cbpdwuzzsmGVJo6T7V/oRIt2f7jY0 t/O6B2MSpT94nbx2RVfHAjx3ddTt1NzuTsLrTxeoKJ6OtfN7/Z3ElQ6U7m+Mdn+dO0FztwimBFM2 dd/UvXB04Wi56D1uPG7kGmrUoH8TpZBS4M+n5FJW+VVVR95DNw3/EVx3FG4HsqpVIxb/Ddex+M9V 8ZeTj3x9DWkRt0O4m8yApPj2lylACHgcmscZC1a5ChW/12xvpGotPAaPkrWjBsf3R3IaUGsXHvug xnmQjiRG40TIXXbF4Lm5scTQoJFH1zxGk7mQ79E0T1Nb+g23ZiS+HyxR+aG+qL1V/ZDNNlruxho1 JdT2Kj4l/PGFW+YF0gJZQk9Pj8YEH6RGiQ2IkjJmGC6je3es5RaGR77q2PSx6fUzQw2ldiJMDXfT 5klsNWVllNhMTfdHPZrF07BwN5sdhmaRG0pxxfSw26taWDWPnB7184OzVHVPndXPDzVBPA45QVQE 9M0qjDv4srrOycdvNjlFGq+ZIxYLESGj3dOqVdeMjHyTWdN0knjcwuNOFIm8bZblZv/Nfm9wJela ZmyPU/O4Oolsv1cEmxQvdzoJj0vzeC6L3WyLg00eO/27/ZdjlZ382emxnh/GK73B7GAnv8eCkZr2 kYFjNLm+7EnUPElVHas61g491LtidsXsPeP37y9e++Ha3Z7dHjV2VbA2eChYQdlPKaHsCu4O7gx6 3JonoZOYG9egvniDc4OIbKBPXcnu3btL6mIvLBWsEyVityolQp7Hrnb6VTgPnREMVuV0TNT1/Tke Q3icZkrjQ23hlpXo+oqSkoOLEgwtwSVHPXpqt3ycOhrb/s1QLzVjqKq38hgyU9XPHCL3bLxCScnl YHDq0ARdS9CHer3eqDf+8Mj6lSU8lgVX0GPFlS+xe3eCRUuwBYNCNBgvwaElOOVJyf6K2tqK/ftL 4m2aPJwezdniaNUXfUuaFbWHbBg6tqOcoc5nDPU0qTt1VI4h9xgVVfUjyi1mTrG0lWdtjlz19EZF Bqmh4sOittwsy7dT04Qst1A6UpyJ/CcdPC1l5sbpGwdsH1qb4k3xsj9xGrtnzBiaMnTGjN2eq/dN ofQVSog6T0pKXxxel2CxJDQJMyxkt2oWO/IE/WQ5p12aTUjLyZTHlWbT7KxyNtzQV7aqD1qvt6+6 qc7iD1lvx2HGfvlQgTUop6I+MEx1Y1kJztZ1D+I03tCH6twtWaZCL1FcJ9qgQjcxQ4wi8Ey/LmRx yj1OUnyKJon4p9IusdkyWVinLZ43W7SaOe+hR8Tg2Q8umCPGU6PdPXFkKkYQpqk+J9JFAlu62JUm HEzw1up+7I6FLV8LXrmNsI7Jyhotuk6ccGeq6HvPxHGpbLhibeT/F0gSbdWVlVdo2TA6+yH1OWLs ilVBXCPaiw7Tsudni9fV8U113K6O76rjB+q465GH5s0Re9TxoDqWquMRdaxSx1PqGJL/X0ucl0dN V8f26thHHUeq473qOOvRRx59RFuhjqvVcZ06blDHV9Rxizpua/h0/98dtW95NLAk7zPlX51xLv8a 6//ungU/JPzHzzIC5d/FyL+cyBXPis1ih9glDotqcV6zCKfS1IhrGxLyb9Ks9GvFlNPkZ3ja4Nhz werY80+jTfoQb2c3N7vWPHXNrxO7Nb9umdz8+poXm19ff7n5dfcr6nu2b349gKRgaXp9oUm9LrQ7 hja/Hv8kzy5iurvIkn/HR59cTNXXkiVWWl63fCY2WX9q/akotS2wvSbK7J/qBZrVdbfrQe191xPs DPd4kjy3W27z3Od5xbI4YXrCLMsfElYmrLUUJ1oSDcvhxIuJFy1/Fpo/Im2jlye8e9VyiHIk4WST cjpeDl2lXEjs3FC6UwZTMiizVNl4ZUk4lLg58ddJG+JlU5Pypixyv3OV4mqZ1VCebLm+oURiJbnj VUofyoBWLzYpr8eKqrmitNrRak9DOdi6inJKlja2q5XkPm2S23Rv+2STsl6VXVcth9peqi8prVLa N5SMeBl71ZKlyr3x5+bFHz/KdiWqlDaUWO9jKbXterab3u6VdltluXL0dtuuVmKjt3uvXXW8XGgs 8lXaXVKv5ZdcO77L4IYyvsvEhjI9XmZR/F1myX8qpWv69X2uz+gyi2Of63d123NDuSoXuk+hZPfo Rundo7pHFKp7XO65p9crsvSo7vVBr9O9Tve29U7s3ar37yilfYZRsvpMuenleAnc7O/frf+XA569 ZQBl2MCUgVMG5gzaES8fDCoZVDq4J2XQ4NVDjsZ/ZLHw1l2q1A27Zdjb8fLurXVcvz2sVl3VDrcM twx7e3jv9HXpH4zoc/tkyrE7Hr61MNaa59pYqzHDZLsx48d2Htt37LCxW8d1UyVr3CxVcsatHvcy x5xxH1Gqxi8Z7x9/7M5syoZML62yMg9mHhz3Ecej8oxSnRnKvDTBr8qWCftVOTYhBMcmRLJsEyLU h7KmZB3Nqr5rAeXZiam02zIhEquZuGRCZOLJiWcnZd1bMnnyD5N/2PGH3WbaZk6ZWTHzUv3zw70p O+YkzemcnZOdmx3Mrs4OZUfm2ub2m5sxd8bc7LlL5hbM3TD37bnvzi2ee3he9rxn522dd36+mJ88 f/T8qfM/mF++YMCCqQteXnjvwoKFgYUXFumLei8atejtRacey3jsUk7HnFE53px5OS/nbMupWNx5 8Q8Wv7u4YvGlJZ4lbZYMWjJyyfQlW5ZULO25NGPp/Us3Ln1z6dGlkWXpy5Ys+2C5vjx9+bzl25eX LK9b0X7Fwyu2rAitHLwyZ+U2f9a/yFXvXpmPmmcb/6LGIvOIevMbL7EM8i/m3tgrZ1zzeRKL9Ktm nfrM06Q0zx3+ksYis4O/tLHE8oLMoUlvppS0XU8ePjKslqypcrB6Jt+2zCK/bkzcnLQh4VBDzqRt y0iX6bJvwruJGxtzZ8xKZOcMlX9jrTonbq63nrwrc7Fqe0TWq/ZxCzLuuwknyeSb6XFEjXYI6Tbw fESVxtXh9BWrQkaTdaBxJdgs5f5G9n/zG9nfFc/5T6p8r7K8GofeiRmcb6zPhPhja9xf5KZY/onl t7gfyYlkQOm16Q3Zsd6j5LiUsf5q2aPRx10m+qv91YwmW12gLqtddZeJ34wJ8mBpk4x6lTzbNK9+ M6fGM3eJiqZYFh1fnz9lXucOr+oPtdvKnYkpWbcMyDzYxhZbx9Qza1bbS62riKrk+tWnflVJ7tjG 1rgCxaJSrm2qtU22oO+uNsmyRt6RreT95I4Jh+ojNaV9ckdWwGTZX57H7jauo01XUimLWjXj62aT lTOZEa5cJ9c3Wx0PxVfGVvXSU38p9ury9cdlta5KyUCeZtaXVpM2xlNNZmy9jWMzUVozFildpmPv sdKb0hIpWa1eVP7eKn3TZFYPbrcNXetX2NLYqP5Qit8fihX5CvK5y0TpFXkWizT57A9d36drvxix Fa5rP7UqNSlyhYutbmp9/C+LWlOblG+2UCttkxJfcRvKN3vIlfY/K2ot/talYcX+F+VKS8nSsI7/ i6JW9m9d1G7jW5YrraP2KE3KN+2n9i5Nioz7mKf/s/LNkf+9dN+uxOws9y6Jm2/Vx3a+tS7hiNz1 qFKo7uhyp6OuCsd2lnugeB2FHdQguWuK3ZW5X57JonZHk9XOSu6haofVqv0RuyPOdt1aqHYn/oZd jCxbJvgzj07wyx2MutoS3+fEzrewC6qWd+SORvbLjBe141mg9ka0VbVb5LHdNlpvkbspskW3zKNq 35UTL1nqTje561JXWZlHZV6K11HYufVlryZ3aLLfanVGUfu0bLWfo63aqTXs18ZlDbcoi9RJW9y1 IGaJW3WlDxLHJB33kRpbvtJqNZYat/lM/KZHm8bBDeWxK6HLb5db7zQ/kN8sl98rl98qtwbEQCG/ Q3yIqxp1FrJOMk8KTX233CK/T66+Te4Wb5l1otis07ziGu1BMVGbKtpp00SaNl201B6R3x80B9By uHW2+UehqW+d22jroW1L2npo61Lj1dDqrHBq94uO1HehfhL111LfhbGuZ6w0er+EPMfkd0PNHfI7 59ZlyLHc/C3yDraeMH9iPSn6WmtEP+sXopf1K/MT62ne7crRD6lvn9vkd8flN8eRZr367niOaCHG iiQYLHqIITDd/EQ8BDNgvvmFWGBeEAthETwGObBYeMQS87BYCstgOayAPPrnw+OwGp6AAlgDT8JT sBbeFyPF7yDK+WUwRQ9NgAZZYoh2F0yEu+Ee8IkJWonohMY+671iqPU+YVgfgNmiQH4f2rpKpFrz xHW2V83Dtk3wGhwWPWyfQimUQTl8BhXwZzgClXAU/iJ62JPMT+xV5mH7X4XHHuL8DNSah3W7GKv3 4Lm/6KHfwvNs8xP9UZgDP4KF5hf6IsA2OrbRsY2+BLCN/o4Yom+H38JFMcTRU3Ry9IIHRA+HF6bC XJgHi8EPqwAbOQrhGXgVXhMjHW/xfAbOQi18DefhImBDYxpMh4dgoejkFGKIs5XopGL3lPqWvzz7 Sn2XvzVRW0TUFhFt3Yi2EURbLtF2N9E2lWgbQ7Sly+/gy2/aW+8118nv2stv2hM3z8vv2lsD5hbr CeKsRlitp4jBr8R9Ks5O0uoo28z6WXG/uKnJ+KMZfxHj3874A2k9hbHXM/Zv6dWfsTcw9kuM9wHj 3SsSGeUco5xjlCRGuYFR5jDKTYxyE6P0YhT5Ow7HGKk7I8nfAujHCFuVpns5e0ekMMYfGeOPjNFd e8D8HePcxDgPMM4AxrmbcYZrPvNjxrpJ22i+R8/fM56N8RYh2QzGvAbJ8hjtKWu1eQHpPrJ+yWz9 StxoPR2fsS0ZtSej+hh1IKPezqhdGbE7o30qv5PMzLsTLScJdzzD/JNMIjPLCyLPDIl8eBxWwxNQ AGvgSXgK1sJHZlTsg/1wAA7Cx3AIPoHD8CmUQhlUwF9MUxyDz6EKjkM1nDD3iZNQA+fNSvE35vkF CEMELkKU7PZ36i/BP6AO/gmXkcU0Q5oATWXFE9YpRNgPzHPW+3n2mudsh82Q7VMohTIoh8+gAv4M R6ASjsJf4EszavsKTsNfIQRn4Cycg1r4Gs7D3+ACIIvtMpjmPnuyuc+RbkYdt8NYGAeZ5heOe3ie BFOovw/uhwfMkMMLU+ER6ubyPA8WcP4Y5MBirpfx7Od5Fazm/AnAD46neS7k+Rl4jvP18DxsgJ8w /qvc38z565y/xfk7nP8e8JEDHznwkQMfOSpN03EU8JEDHznwkaOKPsehGvCR4yuz0nEa/oouIThj HnKchXPU1TL213AeLnCN7xwRni9yjY+MaTAdHsJfFrFOtFIrl1WsI3YnEcNy9bJz9UuuxnI1higv tn4segmNuxGRQWRWEpmVRGYlkVlJZFYSmZVEZiWRWUlkVhKZlbT+gkiLEmlRIi1KpEWJtCiRFiWK QkRMhIiJEDERIibC68nfKKi0/lDYrQ/CVCJomnmCqKkkaiqJmkqippKoqSRqKomaSqKmkqipJGoq iZpKoqYST0bwZARPRvBiJV6sxHMRvFaJ1yrxVgRPRfBUJV6pxBuVWD2K1aNYPYrVo1g9ilVDWDWE RSNYNIJFI1ixEitGsGIlVqzEipVqxh4RDmw5gplssPb+gbX3N9ZDrLWfsAqx2ij7nkbDT9DwuLLv Mq7kL890xL65jPCZmMw6mcY6mcY6mcY6mcY6mcY6mcY6mcY6mSbkv6W2FtaJW1gru7JWdmXOljJn S5mzpczZ48zZMHM2zJwNM2fDzNkw62kyc7aGOVvDnK1hztYwZ/G3GMe6OYB5epx5+jnz9Djz9HPr VNHNOg1mi3zW0U6so51YRzuwdqaxdqaxdqaxdqaxdqaxdqaxdqaxdqaxdqaxdqaxdqaxdqYxF2uY izXMxRrmYilzL8ycK2XOlTLnaljj0ljj0ljf0ljf0ljX0pgrNaxtaaxtXZkrNaxvacR/KfFfSvyX Ev+lxP9x4v848R8m/sOsf8msf8nEfw0xX0rMh4n5GtbANNa/NNa/NNa/NBnv5nlsfZ792TrzcTww mnx+nHy+EE+MxhM/p3Yt0X679TA7qVLzsrVMTFXeq6T1EVpVsGKuM1dwNZW+h+n7KXfT6buOvh/S dyx9S+n3faHH59H3aFlGy1JajlX7Kxkzb6iRHqJ+OPUHqS+nfggjraF2OyONZKSPGKmvav9ntU88 po4R4dJaiE7aFJgNj8KPIBvmwjxYAE+y0reUvyIjfzFG/l6M/LUYtTfaJNpafy++Y92J/6tFF1bt u9klJrNyt2eX2MX6JZnhKyQ4zb2/iu+wns8zd9KjDXvKznJNp/9sMYYVbAoxf58YY71f7b7GiEQk 64BkHZCsA5J1QLIOSNYByTogWQck64BkHejZip5z6NmKnnNUzwR6JtAzgZ4J9EygZwI9E+iZQM8E eibQsxs9b6ZnN3rerHp66Omhp4eeHnp66Omhp4eeHnp66OmJ9xwQ7zkATe4TPTnrqWxcpPYIF+Xv ysjfioC7YCLcDfcIF3s3F3s3F3s3F3s3l1P+f1qb/J0Y+Sso8Z1GsfLRcVGqdTertR7QE3pBb7gR +sBN0Bduhn7QHwbAd+AWGAiD4LswGIbAULgVhsFwSIcRMBJugwy4HUbBHTAaxsBYGAfj4U7IhAnw IrwEL8Mr8CpsgtdgM/wMXoefwxZ4A7bCL+BNeAvehl/CNngHtsOvYAcUwa/hN+zWgjzvNI9ou2A3 FMOfoIT7H5pl2h7YCx/BPpC/XXMADsLH7CCm8G7lfvOQ7U/sJErgQ9gDe+Ej2Af74YBZZjsIH5tl 9pZmtb0VtIY20BZSoJ1ZrT8NLwA20F8xT+lbzHP6G7AVfgFvwq+5v5tndpv6nzg/ZJbpn9K+gvOI We24Fq6DTpAKaeY5R2foAl3heuhmljlugO7mEUcPIBYcxIIDvzv6cd2fuiHmKcdQniea5wyLWW1Y wQZ20MEBBjjBBW7wQAIkQgtIAvQ1kuEaQG8DvQ30NtDbQG8DvY320AE6AvIbyG8gv4H8Rhp0hi7Q Fa6HbsjUzzxl9IfvmmXGYBjCvXQYBXfAA7SbyvMM6mbS7mHwwSxYSN1yWAErwQ9Pc/9ntH+D9lvN I8YvuH4TznMvbFY7NUBX5zVmmRM9nK3NU85UYmip+mUkrKNhHQ3raFhHwzoa1tHooWEdDetoWEb9 flJLSIZroBW0hjbQFlKgHchfWJK/r9QJUiENOkMX6ArXQze4Qf72Fu+ye0BP6AW94UboAzdBX7gZ +kF/GADfgVtgIAyC78JgGAJD4VYYBsMhHUbASLgNMuB2GAV3wGgYA2NhHIwX8t9FdGuZMAHkb0Pd BRPhbrgHJiH3vfA9mAzfB/nrTitgJfhhFeRCHuTD47AanoAC4P2G+q2pZ+BZeA7Ww/OwAeS/hCt/ j+kleBlegVdhE7wGm+Fn8Dr8HLYAK6C2FX4Bb8Jb8Db8ErYBuVYj12q/gh1QBL+Wv3Qlf3sKdsFu KIY/yV+Bgj2wFz6CfXBlFplkPih/CYt1oAWZfyjrQAuy/1D5u1g2Mp6NjGcj49nIeDYyno2MZyPj 2ch4NjKejYxnI+PZyHi2bbxHeQe2w69gBxTBr+E38J55xvY+/A5+Dx/AHyAAf4Qg7IRdsBuK4YDw 2A7Cx8Jjbylc9lbCbW8NbaAtpEA74dbXmmf0H5sh/WnON3C+0fxCf4E1CR+obLaJOnTRf04dMuvI rCOzTpbW3zFP6tthB3VFILPcu7T/Lffep/538HuuPwDk1JFTZb8Puf6Iun087+feATgIH8Mh4dE/ 5bV5b6fz3k4v595n5kWVKY8gG+/n9C/oy3sWPcQ5u2ud3bV+DnjPovOeRec9i/43uABhiKDbRfOk I9E842gBSdASUsyLjnbQHjpAR7hWuBzXQSdIhW7C47gBukMPuJl7/XjuD6yyDlbXWNYVHsMi3IYV bGAHHeSf1RrgBBe4wQMJkAgtIAlaQjJcA62Ey2gNbaAtpEA7aA8doCMgp4GcBnIayGmkQWfoAl3h erjBPGP04j1ab7gR+nDNTsG4mfP6TDyA81tgIAyC76LHYBjP+Z3A+1xjAv2yzGLjLpgI3zcvGg8g 5wzaXZmleb9r8H7XeAyWI8MKWAl+2q/htZn/Kmtv4Hkj474AL8JL8AbjbYX6LP4W9/ChEabvP8yL TmGedGryqwdmyIk9nS6eW3L/GuFRmZ0VytmWeynQDsjHzo7yc0k50+P7quXyl+XUHm1Xw/058tfd 1Ococr91Vtgto80fWO80d7M7dcnPtqg7I3pb+pqnLQNgIAyH0eYnljHmPss4uJNd+STzGLuLo+wu jromm/tcU+AJ87SrANbAk/AUrIUfA+/lXE9DITwDz8JzsB6ehw3wE9gIL8CL8BK8DD+FV+BV2ASv wWb4Gbxunvb0Mk8LK5JGLJN5TzyP99BDkD+M/GHLYLMG+cOW23heYx63PMl7l/vEjeSvG2m5z3W3 WeO6B+6FH8A087hrFsyGOZANC+AJM4xuYXQLo1sY3cLoFka3MLqF0S2MbmF0C6NbGN3C6BZGtzC6 hdEtjG5hdAujWxjdwugWRrcwuoXRLYxuYXQLo1sY3cLoFnaPNY+7x8F4uBMyYQJkwV3mcXQP48OB 5md4aL9F+dHcoz457ITuW9F7q+U+c5tlOjwKa8wgNpC/aXgE3bei+1Z034ruW9E9iO5BdA+iexDd g+gedOWY21yLYSmsgsfNbcgVRK4gcgWRK4hcQeQKIlcQuYJiBB7w4QEfsp3AAz7ku0gEXSCCLiDn 50hSgSQV1kmXL1gnXw6zuiTgmZtYXRLwzk3x9/jFRNcFousC0lUgXQXSVSBdBdJVIF0FnvHhGR+e 8eEZH57x4RkfnvHhGR+e8eEZH57x4RkfnvHhGR+e8eEZH57x4RkfnvHhGR+e8eEZH57x4RkfnvHh GR+e8eEZH57x4RkfFqjAAhVYoAILVGCBCixQgQUqsEAFnvGJ27CCFyt48cVerODFH3sto8W1aJ+J 9pnxz1ufir+f7okV2mCF/lihDVboH/+U+Pv4ai++2ouv9uKrvVgjE2tkYo1MrJGJNTKxRibW8GIN L9bwYg0v1vBiDS/W8GINL9bwYg0v1vBiDS/W8GINL9bwYg0v1vBiDS/W8GINL9bwYg0v1vBiDS/W 8GINL9bwYg0v1vBiDS/WyMQamVgjE2tkYo1MrJGJNTKxRibW8AoHsXABjT1o/AwaL0LjZDRcgYaP iXbYqBj7FGObcmxTjh2SsUEytc+hfzH6F6N/MfoXo385+pejfzn6l6N/OfqXI0c5cpQjRzlylCNH OXKUI0c5cpQzV3zmG1fkuwviRstd5LjJ4CPPzSLHPQKzgbGRuKoh1y0nZ6w097mXmqfdy2A5rICV 4IdVkAt5kA+Pw2ogN7rJjW5yo5vc6CY3usmNbnKjm9zoJje6yY1u8qKbvOgmL7rJi27yopu86CYv usmLiU5wgZucJzP7aSV7mDlewxyvYY7XYDf5Pr0btYeZuzXM3Rrmbg1zt4a5W4PsYWQPI3sY2cPI Hkb2MLKHkT2M7GFkDyN7GNnDyB5G9jCyh5E9jOxhZA8jexjZw8geRvYwsoeRPYzsYWQPI3sY2cPI Hkb2MLKHkT2M7DJnTTb/jLX3Y+GdDTlLavS56IdGRdRXU38Rb9ThjTq8UUfbz2lr0NbNTHGhaR9m igtt+8Q/AyrBQ3V4qA4ti9CyCC2L0LIILYvQsggti9CyCC2L0LIILYvQsggti9CyCC2L0LIILYvQ sggti9CyCC2L0LIILYvQsggti9CyCC2L0LIILYvQsggti9CyCC2LxHfQJA/f7ME3eyw+0RH/7EGD acyAvzMDImiSjyZt45/MtJWfzKDJT+SnWfhuD77bg+/24Ls9+G4PWuWhVR5a5aFVHlrloVUeWuWh VR5a5aFVHlrloVUeWuWhVR5a5aFVHlrloVUeWuWhVR5a5aFVHlrloVUeWuWhVR5a5aFVHlrloVUe WuWhVR5a5TGPJ6t5PAgtPo7/P6dRSP0cUu8QbvQ9gL4H0PUAerVGp9bUPI8+B9DnAPocQJ8D6HNA 6JaF+HWR+XfLY+YpSz5x8WPzrOV5+Uk7dy9Z8s2I0Dj+XfSgRcSSQ0QshnyzzLJaGJYn6L3W/NKy Qf6ep/kPywvmP9zsb93sb93XwnXQCVIhDTrDdNo8BDNgJjwMPpgFj8BseBTmwI8gG+bCPJgPC2Ah LILHIAcWwxLzH0qfS0h6wrLc/AJdTlrWm+csvNMTUyzziPb5sJC7OWi5GFaahyx+WAW5kC9aW1ab 71iepl2hWWV5Bp6F52Cj+T76ve+2mPvdVrCBHXRwgAFOcIEbPJAAidACkqAlJMM10ApaQxtoCynQ DtpDB/MsNjyLDc9iw7PY8Cw2PIsNz2LDs+7B5iH3EBgKt8IwGA7pMAJGwm2QAbfDKLgDRsMYmI4e D8EMmAkPgw9mwSMwGx6FOfAjyIa5MA/mwwJYCIvgMciBxbDEfF/YiJxjWPFTrHjcssH8mljKN88T JxdFFl6I4oUoHriEB2SEHWfFibDiRGgRwcpRrBxlhYmwwkRYYSKsMBFWmAgrTATrR7F+FOtHsX4U 60exfhTrR7F+FOtHsX4U60exfhTrR7F+FOtHsX4U60exfhTrR7F+FOtHsX4U60exfhTrR7H+Jax/ CetfwvqXsP4lrH8J61/C+pdY5SKschFWuQirXIRVLsIqF2GVi7DKRbBuFOtGsW4U60axbhTrRrFu FOtGsW4U60axbhTrRrFuFOtGsW4U60axbhTrRrFuFOtGsW4U60axbpQ5t4jolnNxOTZdQXTni0Ss fQJrV2PtcyIbGwewcYBI/5KWe7D1CWx9wrKE6+XmV/Q6T+SHiPwQkR8i8kP44Z/4IYAfAvjha8s6 80NmwGfMgM+YAZ8xAz5jLu0nN5TgozJ8VIaPAvgogI8C+CiAjwL4KICPAvgogI8C+CiAjwL4KICP AvgogI8C+CiAjwL4KICPAvgogI8C+CiAjwL4KICPAvgogI8C+CiAjwL4KICPAvjoBD46gY9O4KMT +OgEPjqBj07goxPMkBAzJMQMCTFDQsyQEDMkxAwJMUNCzJAQMyTEDAkxQ0LMkBAzJMQMCTFDQvg4 gI8D+DiAjwP4OICPA/g4gI8D+LgMH5fh4zJ8XIaPy/BxGT4uw8dl+LgMH5fh4zJ8XIaPy/BxGT4u w8dl+LgMH5fh4zJ8XIaPy/BxGT4uEz48WIMHa/Dg3/D3Lrx4Ds8dwXN/xXNn8dxZPHcWz53F/x78 vwPvhfBeyPIU936Mp582f4kHv8SDX+LBL/Hgl3jwDB78mjj5A178HC9+jhdDeDGEF0N4MYQXQ3gx hBdr8GINXqzBizV4sQYv1uDFGrxYgxdr8GINXqzBizV4sQYv/g9x9x4fdX3ne/yXmWQmTCbexWtr rdZW3dbaWrvVXrZd1rXbrb1b227t7qq1UGmlShUpCq2XesW7KOClIgWtQE1RUfCKRWODCRlgmAQS gZhkmPxIQm6A8j3PSWmP3XPO45x/zjl/vB6/uf6+3+/7c48hdrBiByt2sGIHK3awYgcrdrBiByt2 sGIHK3awYgcrxawUs1LMSjErxawUs1LMSjErxawUs1LMSjErxawUs1LMSjErlVipxEolViqxUomV SqxUYqUSK7WxUhsrtbFSGyu1sVIbK7WxUhsrtbFSGyu1sVIbK7WxUhsrtbFSGyu1sVIbK7WxUhsr tbFSGyu1RR9lpSFWGhqNxj9bYYAV+lihjwWGWKA8N/VRt4+6fdTto24fdfuoO0TdIeoOUXeIukPU HaLuEHWHqDtE3SHqDlF3iLpD1B2i7hB1h6g7RN0h6g5Rd4i6Q9Qdou4QdYeoO0SdPur0UaePOn3U 6aNOH3X6qNMXnSAzvC0zvC36S+p5JnGjU9zkFKO79/huzFLv71W3j9DVHYn34L04Cu/D0Xg/zveZ C/BDXIgfQQdJ62FaD9N6mNbDtB6m9TCth2k9TOthWg/TepjWw7QepvUwrYdpPUzr4ehHtO6idZcd l+y4JAqKoqAoCoqioDiq/18igO7/g+fr4BPln2z8r729iz262KOLPbrYo4s9utijiz262KOLPbrY o4s9utijiz262KOLPbrYo4s9utijiz262KOLPbrYo4s9utiji4IlCpYoWKJgiYIlCpYoWKJgSTQU RUNRNBRFQ1E0FEVDUTQURUNRNBRFQ1E0FEVDUTQURUNRNBRFQ/H/IBqKLFRkoSILFVmoyEJFFiqy UJGFiixUZKEiCxVZqMhCRRYqslCRhYosVGShIgsVWajIQkUWKo7W+N7R/wp5KluV2Kok25Rkmw7a l2hf1rhE4xKNSzQu0bhE4xKNSzQu0bhE4xKNSzQu0bhE4xKNSzQu0bhE4xKNSzQu0bhE4xKNSzQu 0bh8xpIzlpyx5IwlZyw5Y8kZS85YcsaSM5acseSMJWcsOWPJGUvOWKop+8Jk/ByXgb85Y8kZS9F+ cvHg38YMT7txNNKH5NSh/12M6N1/rkc1mYq2rGhLibY3RdrBIi0TnfXXjDJZNZ6GK83lV1vr+tDL s3t9ekRs9qrOA771EQoPUXjgXV1TL+/u5d29vLuXd/fy7t7/R9mml/f18r5e3tfL+3p5Xy/v6+V9 vf9Xu6LytDJCqVV/nVsGouTe10ZYaXf0LdrW07ae/XrYr4e25cmmwBJV9O2kb+do/pvp+Z1mhLt0 SrO8dm/opGsnXTvp2knXTrp20rWTrvV0radrPV3r6VpP13q61tO1nq71dK2naz1d6+laT9d6utbT tZ6u9XStp2s9XevpWk/XerrW07WervV8qodP9fCpHj7Vw6d6+FQPn+rhUz1076R7J9076d5J9066 d9K9k+6ddO+keyfdO+neSfdOunfSvZPunXTvpHsn3Tvp3kn3Trp30r2T7p015XNOxs9xGS7HFFwR Okc13rk3EkaiAxNLo7GJF3WcL/HLl8P0xKqwILFDnzEYZiZ2hsakzJn8sOn1pLA4eUro+OtvK58d 7Zf89uj/kaT8O4Vd2ZawmsXmue8ivCQCXg65xEqe/gpWWfNV19dDS2K1STdntbWu69AVjUl0i9RB Pe6QTmgYu0JfMgrtyTSqcZjp/6SwJXly2JH8GD6OT4Sh5Olhc/bfQyl7QWjI/hhyRPanrheHluwk yAnZqa7TXK+EHjr7K6iY2ZshKrMzvX+H1+S+7D2ez8Ic95gXdmYXuv9iLAk7sr/HE16r83yZqzNl G73WhDVY73keLR63ot3nekJ7dgeGQ3vtQSGuPRhjYTqsNR3WHuv1CaGhVk9fa1+114WB2pvDjtq7 cC8eDnH0L3tVLbDTCFXXU7WHqj1UfZuqW6map+p6qu6g6nqqrqfmEDX7qdlPyX5K9lOyn4o7qThI xUEqDlKwh4IFCq6n4HoKFii4noJ5CuYpWKBg/r8oWKBgDwV7KNhDwTwFCxQsULCHgj0UXE+9Hur1 UG+QeoOU66HYIMUGKTZIqUFKDVKqh1L9lOqnVD+l+inVT6l+SvVTqp9S/ZRav1epAqV6KDVIqUFK DVKqP3p/4tEwNbE0LKHUc3xwN4XmU2VbYlO4kJ9NTnSHB3j32YkBnfbO8Fl+9sdkMqxMpsItyWz4 CW9fmzwoHJ08Kvph8gPhUp7//uRHwheo9jDvP4PPzU5+NlyZ/Hz43t7fzmpLfjs8mDwnTEiODyvK v7/kVM/ISS+qEi9jVdhoxbfYY5MVO6zQ7a697rjZHbeLpdPF0mdMhI+y2IuhybfK8fKn0Rjpit7r 22t88zXf3GpvHfZW4w650Xg4JeR888Xwmm+95VtP+saBvvGm9dpG49dUPRrDR4nTD3t+UtjkW+12 uTJ6D8/aMfrNlTzrFbzKY1737dW8KqeLXOu6LmzlHVt5x1aesZVnvMkz3uQVb/KKHbxiB6/YwSNG eMQIjxjhEW/yhBGeMMITtrLcVpbbwWrlzN8V7WM/KTufZ71Hrfu0sy7Dq2EXXVvp2ZG9PAy5f7/7 97t/f/Zez+8PQ+7TH1X61oCd/8w3Npf9Xif8qFyy1FleDo1ebUk0ySNlDTeFIt2a3He9+66PzrHq TJ+eLqa2jHrL02Ga1af5Zh8ldlFilztsoUSgxMDeuBqgxEAiHxa5Yx1PakyUeE8GB4ULkmNZ4xAc imPCJclj8YGwLfkhdj4eH2Y9uic/5/3Pj/7u8sl2c7LY20LdAeoOiL0tFB6gcKBwEHtbqDCN0oES MykxkxIzxd8Wau+i9i5q76J2EH9bxN8Wqu+i+i5qTaP8AMWmZR+XiRbh2XBJdqXrn9CA1diAAjZ6 r831TffYHC6pjcIfa6vCotoU0jja8+MwQYaaEWaKwS2suav27rC59h7Mwn2YGxZFNTyynzduZumP yz7vyD7vyD7vsPonRfo7Iv0dkf6OqH4nOpI9yrYcon0v7Xt9KyVH9clRfXJUn7MPOPuAsw84d69z 9zp3r7P2Omuv/NInv/TJLX1yS5/c0se/++SWPnsdsM9euaJPruiTK/oqMlacwQPuZv0XWP921r89 sYJFn8OLYVVipar4ClaFh3nB7sQar+f4Vj5MTmwIyxMFtKAVG7EpXJdoc92MLe651bUDneiKZvCW ukTR420o8bwe1xjbwyWJXvR53I8dYbzc1Chz52XuvAg+W45andjtvbfxTliR2OMaVOEKJFDOX5W8 rcrjlDyVCdOTNR5nw8TRfLav637YHwfgoHA6bz2Tt57JW89UW69NHh4uSx7hvSNxVPSd5NGu78cx ct6x+ED4t+Rxnn8QH/L8eJzg8d/hw+Ef5cj/kFkeZ7UZrDaD1Wbw9i/LlzcnT/WZT+Lvwy+Tn3I9 DaeHq5Kfdv0MPhu+LyrOTP6Dx58PPxMZZ+/9jdnHRchlye9GhybPxfjwhvz6u+z40JidgIvDblGy W4TcLkJ285IZvGQGL5mRneH9X+LXuB434KZobPZm3IKZPn+X1+7GPZ7Pwr3uM9vz+10fCBOzD+Fh zAvXZh8Jl6lmV2Uf9fwx/A6PhzNE1Rkq3FU8cAYPnKE/uFaVuyr7h/DL7FI86XPLvPaszy33eAWe 8/pKz1d5/VX3rffa6/iT1xqwGo3u1YQ1aPb59T6bxwbvFSB78+4ZovaM7KawXOSeoYpeJXrPFL1n ZLd4jQ9m+WD2LfDDbBe6wwtZfpjlh9kS+GB2O3rRJwP0Y8jjkbAiuxO7PH4HfC7L52SF6bX8rpbf 1SbDitpK16owWZaYLEtMrq32fIzskQEfrM2GF2prsY/H+2I/r++PA3Cg1w8KeZU+r9Lnaw9xv0N9 5jAcjiNwJN7js0d5/3042vrv95oMKxtNr70qNIrwGbXXRWNr2bqWrWvZuvZG3ISbvXdHuEzkz5Cp zpCpzpCpzpAFZshWZ9TOdp+59v2Aez7s/vM8fwTz8dtwSXS0LPEzWeL3o5X5pdF6/opM0CniZ4rs 74vspaJ2sah9Tc0dFLHPi9gtorJJNNaLwhWisFnU/ZPIOlckLRYxN4uYV0RMpyi5S5Q0i4LneP8j vP8rvP8F3l/+lwqn8vg3ov+Urxbaye9UrDWJxarUUjnhaa8tw0vq3MveWxnWyZ7rVK4X5KwelWup Gthjt92q11LVa6n8Nc/OX5Gnuu18tVy00q7z8s1m+WaznXfK1zk73y5n5+TsnHyy0u4flwselwse t8vddvn1cs+jeq3J/odMe0FYqoItVcHWqGBLxWaP2OxRwdaIz4Xis0d8LhSfC8XnQhVsTfZq37sG N+KmsE5WXyerrxObParZGtVsjQy/ToZfJzYXqmZLxeZCsfQ4v3+cnz/Op7vVk5x6kuO33WpKjq92 89OV/HIev5zHL+fxxW6+tpmvbeZrm/lWN9/q5leb+dVmfrVSLcrxqZUq3FI+tVCFW6NyrOMf8/hH N//YrINcwQ+ew4s6tFXhaUpvVR2a+MIXZPNW2byVP7xO1XaqNlK1kU88JXNvouyrMnUrZV+l7Kt8 YxvfeEs2bpaNm2XjZj7yd3xkWJYtyLIFvrKBn3TIrA0ya4PM2sBn1sqmG2TRvMzZLCM2yYhNVN9K 9a3U3ioDNsmATTJgkwzYJAM2UXarrNck6zXJdE0yWl4WK8hiBVksL4s1yGINMlheBtsgg22QrTbI VgXZqSA7FWSnguzUIDs1yE4NstMGWakgKxX2ZqUG2aggG+Vlo2bWeVVmaZVZWlnpVRZ6VXbZJLts kkE2yRatskWrzNAqM7TKDK0s1chSjSzVKCtskgFaWaqRpRpFfitLvSrym0R8k4hvEvFNIr5JxDeJ +AbR3iDaC6K9INoLor1BtBdEeysrNoryVlHeKspbRXmrmbhLd1zuq08Jb0efEGXlOevHImqWiJol ol5i5+miZie7zmfXOnatEy1Fdt3CrovYdBGbLhIRI6JghC2ms8V0ETDCHtN5/Agvn8XLZ/HyWWwx nZeP8PIRXj6Ll8/izTvptYhOi3jzTlototUWWm3h1TvptYUn76RPHX3q6FNHny28eSdv3kmjOhrV 0WcR7x3hvbN47k5nrnPGl8PNPHbYCVZ4tsPeB8OjfHNTdLiT7fCsw8m6nazbyXqdqkEeKDpZg5M1 2N0Ou2uwuwa722F3DXa1w4522FG3HXXbUbfd7LCbHXbTbTfddtNgF+VZtjs6ykqDVtpgpQ4rdVip i4blGbXRagNWa7Rao9UGrdZotUarDVqtkRb9tOi36iAt+q08aOUOK3dYuYMW/VYftPqg1Tus3mH1 RquX58MOM8Im+XJHeMOp37DygBVb5bJlMu56Gbc8Hzw1mnFTPjWwd4Yq7v03TCclz4k+Nqpcu3da vdM++qw82+0e1bFq77f6PSu5/zr379MN5/W0JQrvcs4MJSJU6UlTSONoz4/D3NDrHptGLdPk0y2q SHmPA9Fx7vGKd56mX797PeMTb/1lvh+tN5H8kkY1MuEZp/qa05xHx346bqLjJjqW5+tN9Ou3h2fs 4RV7eMUeXqHl387dR+DId83fR/v8sWLxONe5Pv+A18ozd4Uzx9Eh9tdnT332tM2etu39Cc52u++2 r+32td0+ttvHdnvYbu0+a/dZu8+626y7zbrbrLfNetustd06fdbYFh3r7s86/R+d/NV3ZdkcnR+3 0tBoVs2M/qbINXttucHpx5d/o+cv2ceJX7Xqs1Z91qrP/k8zTznTHO1z5SxznGs5Y8z12f+aMcaM VtEd+oCdZusUu34rXLz3tzvesPJ3Rn9j9GP2vcknn2K1BnPBOvt/nkqL35VBypUhT6m5bF2uu29R ay615jrP8+56o7stYsUGvds6Cs6l4FyWbKDiXBGRFxF5Fm1wvudFRd4ZNznjJmfcxKoNerB1erB1 +q11/yVz5Fm5gZUb/po5jnaPY8NcZ3/euTexcsNo9jiC6i1Ubxn9acSgLLIzvGzXPZRvseMeOy7/ DKeH2i3UbrHLHjvsoXILlVuo3ELlFiq3ULmFwi1W6qFwC3VbqNtC3RbqtoiqQVl3l+rHe3jYYHg+ SqiCu3RKO6OkbmSVZ32edUZHexabYUb0J7H+JFYph1XKYZVyeO/PCIt6ll59/IiKV1TpiirdsEo3 rF8fUe2KevQRfUWsJx9R3YZVt2HVbVjfPaLvHlHZhlW2YX1HrLIV9R6xSjOs0gyrLsPRGLV8p53M UbtjNbvc171l1ZgFH2bBh0ezyhjVfiB5kEzy4VBygm6fKiU/Ee0rw5h5opOtk48q3Wer+5R/5jpS PoETZ0d/glAsf54SB4mnT4QRr5d/KusTvrc5Otiz8ukHnH7A6QdGT/5dvcK5Ye27Tj7g5AOjp250 bcIatKAVTudkA0424GQD0fustpq+g/RdT9/1757MrV2ySgdtB63QYYWOv07jT4z+xK+DtoO0XU/b wb+Z0Nd7nh/9KeDopE7b9VbvoO36d0/rUYWTD0bHJms9Oig8oFuKdUuxbim2pyft6UlqDeqYunVM 5Z+u9dBpm84oZoG3WeAxFnjMHHmAObL825Hlrqdb19NtX0/qbrp1N926m27dTbdupls3020/T+pk unUxsT09qaPo1lF06yi6dRPdUdpufm/lHVYcseIOq+202utWez06xrtv0q3THjfY4wafHNr7M+z/ bqFP6OxO59efp8O80EnDXTTc9VcrPeG1Os+XuT6r01rl+m6rrfc8j79Yb6PPtPv85rDhb6w4lmrt VGunWjul2inVbt9te38m1U6Rdoq0U6OdGu3UaKdGOzXaqdFOiXZKtFOhnQrtVGinQnt0uHNudMaN zrjRGbc7Y84Zm52x2Rmbdaplr2t2nmZdZVFXWXSWjTrLsgc2O0uzszTrJIvO0ewczc6x0Rk2OkOz MzQ7Q/Pov6I8JvmD6JhoVnR+uDe6AD/EJeHB6IpwWzQVv8A0XIktYVa0FR3o95md4dZoF3bjbbwT bq34UGisOB4n4ET8HT6Mj+AkfBQn42P4OE7BJ3AqPom/x6dwGk7Hp/EZfBafwz/g8/gC/hHj8E84 A/+MM/FF/Au+hH/Fl3EWvoLx0SEVL4TnK14MT1W8hJexEq9gVVhR8SpeQz1eDysqHwi3VT6Ih9Dg +Wq8AWet3IMQbq3aL9xbdUCYVaXLrtJlV+myqw7BoTgM7eG2qpLP9KA33JY6HqfionBvaiJ+gp9i cngw9XPQPTUzNKYaw4qUiSd9XFiR/iA+FJ5KH4+P4eOefxrfDbPS38O54db0PZiHds/fxGawWbo7 PJguYrv3BjwfCrdWJ0JjdRKVqEIKOsVqnWL1GGRQgyxqsQ/2xX7YHwfgQHwqrKg+DT/w+Ieu011/ 67ogPFU9GBrHuNeYA/XH348OCKujAyH7RQdjLA7BB/EhHI8TcCK+hH/Fl3EWvoKv4mv4Or6Bs/Ed nB/m8Nw5PHcOz70yujTMjSbj57gMl+OKsIA3L+DNC3jzAt68oPKGsLryRtyEm3ELZuJW3IbbcQfu xF24Gw/43oN4KCxg9TlV68PqqlZsRBvavf6WaydK3u9Br9feCatTKaQxBhkcisPwARwHOqTowDsW pE5xPdX1dNd/xvdxLn6Af8dFYQ7PmcNz5vCcOTznSp5zZcp5U87LgxZU/7SsTXRbaIxuxx24E3fh bszHb7EAC/Eo6vE6/oQGrMYbaEQT1qAZOaxFHlvCE3LCE3LCE3LCa9EODGAQQxjGzrBYnlgsTyyW JxbLE4sru0JjZTeK2IYSTCeVMbajF33oh4mlcgDl7+1BCIvF2xNpuSAt9tNiPS3W0+I8fVZ4Lf1N 12/huz7zPZwbFqd/7PmlmIzLcDl+gWtxHcRbmkZpGqVplKaReFqc/o3rPNfFrs+CDmk6pOmQpoNY e0KsPSHWnhBrT4i118Taa+ltKGG77w54nR7ibnHFR6LKaP+oCqny/86j/D8uwBiU/3p3DbLlPzGJ fXBaNDY6HeeHqXx8Kh+fyscn8/EJfHwCH5/Axyfw8QnRFHe4Ikzk5xP5+UR+PpGfT4x+Fe0bXY1r cC2uw69xPW7AjbgJy6L3Rs9gS7iCRa9g0StY9E4WXcCiC1h0AYsuYNEFUfkvSO8M01h1GqtOY9Vp rDqt4r6wtmI25uB+PIAH8RB+g4cxD49gPn6LBViIR/EYfofHsQiLsQS/xxOowx/C2sRHo30TJ0dj E6e4fg5nhqmJL4ZLEl/C1zwfH2YkJoSLEj/GReEiPduXkt8Ll+rbvpT8geuloT45OTQlG6OqZFN0 ULJZ17vWVL4uyiS3hAXJrXqRjuhDybdcO8t/G8h1W3RA5aXR/pWT8XNchssxBVdgKn6BabgSV+GB MFG+mChfTKxcE+1b2Ywc1mId1iOPDSigBa3YCHry9mm8fZpcM7Vq/7CW118hx0ys2hZl5Jep8stU +WVi1e5o/1QSfCt1AA7EMTg+TEyd4HoyPh6NlVMmpj7p8UVhqvwxVf6YKn9MlT8myx+T5Y8J8seE FF9KXQG+lLo3rE3dN/ov6Nem34P34ii8DyfjrLBApF0h0q4QadPSk6J90z/DdMzAbbjH6w+4PhS9 VzRNSz/mcbvPv4nN4HMi506Rc6fIWSByFqR7ojHpGNt9fsD7/E8ETUsPR/tWHxTWVh+MsTgEh+Iw HI4jcCTstdpeq+212l6rj8b7cQyOxQdwnnudjwswzfMrcVVYO6YirM2cEy7JfBfTwkWZqyBuMuIm I24y4iYjbjLiJnMzbsFM3ArnzdyOO3An7sLduAezcC/uw2zMwVzcD/pkHsRD+A0exrxo35qp+AWm 4UpcBdrW0LbmlxDfNeK7RnzXiO8a+6yxzxr7rLHPGvussc8a+6yxzxr7rLHPGnussccae6yxxxp7 rLHHGnusscfsidG++4xBBjXl/+tw8g2RskU2Kj8q/+2RQxKXyWbZ0f+7QAppVGMMMqhBdvQv2Gdl s6wOoKADKOgACjqAgg6goAMo6AAKOoCCDqCgAyjoAAoy34Ey34E6gaJOoKgTKOoEijqBok6gqBMo 6gSKOoGiTqCoEyjKkhfKkhfKkhdGPwpxNB4T8GNchIn4CX6KizEJP8MlYbyMerGMerGMerGMerGM erFsOk42HSebjpNNx8mm42TTjGyakU0zsmlGNs3IphnZNCObZmTTjGyaUXdb1d1WdbdV3W1Vd1vV 3VZ1tzUq/7xjARbiUSyLDpN5D1N/Y/U3Vn9j9TdWf2P1N1Z/Y/U3Vn9j9TdWf2P1N1Z/Y9l6kmw9 SbaeFHWaZbvQjSK2oYQexNiOXvShP9wjs8+X2efL7PNl9vky+3xZfYqsPkVWnyKrT5HVp+jp83r6 vJ4+r6fP6+nzevq8nj6vp8/r6fN6+ryePq+nz+vp83r6vJ4+r6fP6+nzevq8nj6vp8/r6fN6+rye Pq+nz+vp83r6vJ4+r6fP6+nzevq8nj6vp8/r6fN6+ryePq+nz+vp83r6vJ4+r6fPV3w1GlvxNXwd 38A3cV/IqUQ5lSinEuVUopxKlFOJcipRTiXKqUQ5lSinEuVUopxKlFOJcipRTiXKqUQ5lSinEuVU opxKlFOJcipRTiXKqUQ5s0SdWWK5WWK5WWK5WWK5WWK5WaLOLFFnlqgzS9SZJeoq/hRlKhqwGm9E GVUsq4plVbFs4rTyv1F1/UfXM8NVqtlZqtlZo9Xse6GUOB/jVbd3VbXExFBS2T6jsk1Q2T6jsk0w i89MXhIeTz4bXko+F+2TfFH1e8M832ROb44OUeWKqlwyud58/+dKV6XSHTv6NyaLXt+m8lwaZVW5 rCqXVeWyqlxWlcuqcllVLqvKZVW5rCqXVeWyOumiTrqoky7qpIs66aJOuqiTLuqkizrpok66qJMu 6qSLOuli5T0hrpyFe3EfZmMO5uJ+PBDGqZzjVM5x5q46c1eduatOFc2oohlVNKOKZlTRjCqaUUUz qmhGFc2oohlVNKOKZvSZsT4z1mfG+sxYnxnrM2N9ZqzPjPWZsT4z1mfG+sxYnxlXDoZS5RCGMYKd 2IXdeBtiQmWeojJPUZkvVJlzKvMk81/e/Jc3/+XNf3nzX978lzclFEwJBVNC0ZRQUMHHVW0NsUmh YFIoqOQXquQXVtlTlT2p6ONU9KypoVC1x/MQ4lSECiSQjLIqfdZEUTBRFEwUBRNFQeXPqvxZk0XB ZFFIHemz78ExXvuA58dBrjVlFHQG43QG2dRHvc8HdQcHmjoKOoRxOoSsyaNg8iiYPAomj4LJo2Dy KOgcLtQ5XKhzuFDncGFKHk3Joyl5NHUJLsXkMF43MV43cbFu4mJdxDjzbF4nkdNJ5FL3j/5FprGp JfjD6F9lGpt6xbUx1Okycim2NPfmU8PRWB1HTseR03HkdBw5s3CdWbjOLLzcLLxcB5IzDy83D9el T48yZuI6c0FsLojNBbG5IDYXtOpS5psLYnNBrFuZpFuZlP63UEp/H+eGKeaDOH2Rx2Iq/RP8FBdj knv+DM5ldmg1O8Rmh9jsEOtwMjqcjBkiNkPE6Rt8/sbRvyoY63oy5onYPBGbJ2LzRKwLmqILyuiC DjNXxDqhKTqhjNkiNlvEZovYbBGbLWKzRaxDmqRDmqRDmqRDmpTe6t4deAtyfVqu1zXdo2u6R9c0 X9c0X7c0Rbc0Sbc0X7c0RbeUMevnzfp5s37erJ836+fN+nmzft6snzfr5836ebN+3qyfN+vnzfp5 s37erJ836+fN+nldV07XldN15XRdOV1XTteV03XldF05XVdO15XTdeV0XTldV07XldN15XRdOV1X TteVq/6YPX0cnwp11afhB+59nufn4wL80GsXuv4I4zEBPw1FHVpOh5bToeWqp/vOTK//1mcXhOXV Cz1+FIMhPyaKxurgcmOcbcyBoW7MwVEm842wJfNNnI1zwlk6u7My/+bx5aGUmYKp+EunN8Pja3Bd lNXxZXV8WR1fVseX1fFldXxZHV9Wx5fV8WV1fFkdX1bHl9XxZXV8WR1fVseX1fFldXxZHV9Wx5fV 8WV1fFkdX1bHl9XxZXV8WR1fVseX1fFl/z92fNm/6fgOjm4Jn644N/pyxb9H36j4j+jyiv+M/qni vOjTFedH306cGZ2TGB+dnfxW+ELynPD55DNhfvK58OXk5vCa3vCgpAyXfCvcluwKq5Ld0RHJonlr WxiKjopu2fNy9FhYE60Ma9z9s3v/Guyp7n6iu5/o7v9QMT4Mqa0dVjHNmcq+FU6zymesMjm5PDyb XIHn9pSSL4Slatz65EvhleTL4RarX23lkWRH6LT6aVafafWk1e+3+stRdXJ1mJdstCeTfHJNOC/Z HJYlc761LrSoihv1qY+FP9rbH33yO2rnap++x6enJtfs2ePTD/n0F9XRpb5xmW/cN/q3HU+y22mq +XtU7y8mvqySjw/jEz+JkolH9ckvh/9MrAqzEpuiTyQGVeSDon2TJ4VHksujrCp9khP83kqrzKPJ 5Bqz5trwB1W6yt33OFFOpZ66t1In986kSSfrTHY7VdHr20JPxbejyrAsqkIKaVRjDDKoQRa12Af7 hmej/XBaaIlOx6/CkuhqXINrcR1+jetxA27ETbiFhstCU/RMaKpIhJaKJCpRhRTSqMYYZFCDWuyH /XEADsRBOBhjcQgOxWF4L47C+3A03o9jcCw+gOPwQXw1bKz4Gr6Ob+CbmIYrcRWmYwZ+iV/halyD a3Edfo1bw4aK23A77sCduAt3456wIfHRsCRxCj6Hr4WnE9eHQuKGUODl32KVEj97m48tYYkSH/sK H3s7ObSnKzksIkZCOrlzz3By156W5O6QSr69pzP5Tvhcco/XQzissmpPV2UqfKEyHdKV1XuGK8fs aanMhFRlzZ7Oymz4XGWt1/fxuUvDssrJ+Dkuw+WYgiswFb/ANFyJq/Cb0FL5MObhEczHb7EAC/Eo HsPv8DgWYTGW4Pd4AnX4A5bi6bCxchmewbNYjhV4Ds/jBbyIl/AyVmJNWFLZjBzWYh3WI48NKKAF rdgYllTtDstSSfDfVFV4NnWA64E4BifgZHw8tKQ+6XpT2Ji6G7M8d87UIx47T8p5Us6Tcp7UYq8t wROow1NY5vVn8CyWw95T9p6q9/h1/MnjBqzGG1iH9WFDquC9TmxDH/qxAwMYxHDYmN4H+2I/7I9D w4b0YTgcR+BInBJa0p/EpLAk/TNMxwzchgfwUGhKP+Y6HJZUfzBsrD4xtFR/xPWjrmfhKx5/J2yo Ps/75+MCXO/1WV6/F/dhNh7D7rBhTBQ2jtnfVXyNEVdjDseRoSVzXihkJuAi/AQX41KI94x4z4j3 jHjPiPeMeM/cjFswE7fCfjO34w7cibtwN+7BLNyL+zAbczAX98MZMw/iIfwGD2NeWFLzL6FQ8yX8 K76Ms/AVfBVfw9TwdM0vMA1X4ipMxwz8Er/C1bgG1+I6/BrX4wbciJtwM27BTNyK23EH7sRduBv3 YBbuDU9nTwxL9hkTnt4ng5rwdFSpViyR+YvJtdFH5OW3o7uiK8LsaCp+gWm4EjtDwfxcMD8XzM8F 83PB/Bybn2Pzc2x+js3Psfk5Nj/H5ufY/Bybn2Pzc2x+js3Psfk5Nj/H5ufY/Bybn2Pzc2x+js3P sfk5Nj/H5ufY/Bybn2Pzc2x+js3Psfk5Nj/H5ufY/Bybn2Pzc2x+js3Psfk5Nj/H5ue4/Fe4Kv5o n6tCycxaMrOWzKwlM2vJHDrLHDrL3Nls7mw2dzYn5oWu0d+P/PNvHb2ZGA5vqmZ5VWx28o3oKPWy XQW7yQw32ww32ww32wxXMsOVzHDl+algfiqYnwpmptjMFJuZYjNTbGaKzUyxGWm2OWi2OWW2mWS2 GWK2GSI2I5TMBrE5oGQOKKVPCIX0iaN/j7Ok9y/38gV9dkFvXdALF/TABf1vrP+N9b+x/jfW/8b6 31j/G+t/Y/1vrP/9b9R9CXwURfb/q6qerp6Z7iSEEJIAIdx4A4uoeICKugqIruLBraJ4gLpcInJ4 rIqIgqiAKwoK6iouuh6ggOCFyqoccgpyJUAChIQjnAlT/2/VdGJCAjlg9ffv/lRPdZ2vq159672q 7jc5kH9zIP/mQP7NgfybA/k3B/JvDuTfHMi/OZBXsyGvZkNezYGMmu0MQtmPwv+OtpqmciBv5kDe zA4mYDzdoiZBxpwEmXI5ZMrl7nCV5Y6AG6myvAS12asBlwhXFy4N7jGET1ObiWNWeR/zOuQ4MYcu EHOpu1hALcWXlIT2nS2+hiT1DTURi+latPW10OsDkBgugW4fL1ZQC7T7RkgOqZBz0hGaQadDXrgW 8kJjkUVXotyv/bXsM1DTV2oG0r9o6vwQcfdCqphLMQhbhLsl2i5laVu67B5qU7Y9XdDTHKPjItTa AfPh1aAhGtIcs+VBhF6G2XIuZssdxkbxTv1vlAitjbtLzJpiTaRtBBr0fxFso7OQ4mzcLaE2eMIE xKXiWbXVt1vUz2IgtQb9X1sXQ17jCPkBdz8iNeYmyIS5uFuPu77k4e4I7n6gJmRRGwrA2XASzoEL woXgwnAunAcXgxo7Uw3RBTJeD7i+eKa5kAO/hJz5lVpmDaQ21iC4wXAPwQ2BexhuKNwjcMPghsON gBtJbaDLt4HO3gY6exvo6G2go7eBTt4G+ncb6N5toG+3Mf9/4UG6zUNN6/EU28QC9KT+N5Ov1CxI tzvx7APRJnNA1xdIhafFs3sUz5ZSA7aMmqFleqAdLhddkKordRU9jI25rqKv+kpbJRKDVbqYQK3E RDoP9eSgpxtBkplpXUAtrNbUDK3VlVKRIxX1tERvDqQ01LRL129q8vz/NfledEPu7kjfC7+34Xcg OGyp+hUycjbk48OGf1aRg1yCbP1PKEidiJSJSBlEyhykyKVEygCKQoairZCb+qMm3aeD1XLI3dno 9Vgg7jJT3gr04ErkQplaIg7EqwLo8AXQ4QugIxdARy6AjlwAHbkAum8B6uyssvQXTyjxdIwUaUpb qfKoZok6uwGzesH1w7MNhCS+RO0Bdbl4jhxwXA3UvR+5FqLeMOo9VG69YdSbrv+bBaXFo94AStyP ErNRYh5KDKK0Pf5TFGCcdUaothfYDZJ8L7j+iBlIycgZBMU2ch5AzgLk9EBLRLcacuZjVGTQVbQF bivcYXD2Ebh8uAK4o0CHztBcblHNRDegRXfqKXrh9zb89oPu0x/0DFbTxDDwxQQ6H/xwEVp8KWps bfrmF/WaqW2FWoUxlwAt54jPIy0slG1F4BQ1CcTTVbILXFe4HtREToSbDrcJ95vh0uFAp8xFWB5+ D4A2bf8xF5QdxjMfBmWn47kPg7LT8dwpeG6NGA6eN4RnzRSrKc5w3Tzk+Bo5tiBHCnJsQY4U5Dgf qeNA8zbDeb+ofNB9CDm3mFwrzP8SdEF9XcHJPfDbE7+DgIrpVB+IlwuMCQEZk4GM1YB388w/6uj+ W4tUAiG56IfO8N1ixoa2hpcoBoCrHsJ8tw10Z6HG7SrH8Nsm5NuCfCGU7qBkjpi1lEy91R66E+4u uAHo/c7ozy6gqwfcIHCmTp0BLtmGls4ETduhX+5AKTsxT15MNQNxak8gG26X2mP3hesHdz/cA3CD 4Aaj3Bj/P4HWoOS1KHmtGICnGgTMT0c/ZoCLtmAEmacFDmehjbarn4wuXhP05YO+fNCX7z+9XlPe gFI2oBSOUk4HjXEo5SBKiaAUbWneQQmb9f8Rgb580JcP+vJBXz7oywd9+aAvn86i3tSB7oS7C24o taNH4IbBDYcbQe1QYyxqPBOYFUALXw/MCqCVrwdmvYOW/ggt/QX49Hvw6dXg0w7iPfUCnulHzBCN o9Rg3tLUZEGauIBag0dbWxerNdYUamdNhXuD2gXiqENgE36z8bsLbje1s0+DawXXlzrY/eDuh3sA TtPngKoDPt9wn2+46SvdgttVplmNmAm63/ZTJfqpEkF3DlK2MCsQ29VycEbfyDfQBXdB99sEXW8X dLtNVtPIVvBa30gOQnMRkms1VZeg1L6RDeIA2jkfuQuADUfVYiugDkIvPGSFVR5SLkbKK03erxC7 DCHLEBIyeXPEEdSXj1Y5qlZCx4xYQbKRN4JUK6FLRpCyDXCpb2QbaolAS80DZdniMH7zUWsBODOa swC1RqCd5oHibMvBbwhUhBEeLakAT7AfXNcXeu1BYiglF6VEUIpCCVmmbpsYcucidwS5FXJm+TSc ptspMg40pCN3A+Reh9wHxBGMWE19Afj4KDguAjlBqaOgJR2lNUBp61DaASuoVpinCqOfXYqDprwD JR8FTf/Ws6jiKPEQ6FgvIsSR6xDqXm958DdV9XSKyBKkyER9uqXWIkUmytSttBZl7EbrHtNf6H2/ n5C7nP4xaU2/IG05/YFnPMl+AJ5Wsv2BMqe43fGMx2lvE1NmO1OMlUBBqwboS6KQlYLSaiFPbcgM deBPRVxdxNVHXEPcN0JcY8Q1wXxgWYmooRZi0/DbCH3iWgm4gw5h1UT9KaihFmrSZaUivC7C6yG8 IcIbIRzloBd0al1zLT+FrkmXFQ+6OGK3WokIqQmXRKmgLx4pt6LMVNDHQR9Hrq1WGuLrwdVHeEOk aYSwxvA30f9KjlLWg1b9hNxKBq0pFPBL0bnXg379hNxqgLiGiIvm5njeBLga4L1E0JyEclPwLLXQ +7VRVx39XIivi/g0xNdHfEOENUJ8Y8Q3wfPhKdA3NVBuIkJrwiWpVaAhgtZJt2qjL+vgmVORpi7S pCG+Hlx9pGmANA2RpjHSNMHMpvvJNe2aRAmgQ7fYIdCRADrCoMM1bVsf9w1NCx4CDQmgIax7hYR5 9hS/naPU69YT5rmjOXJ9qjnFVpUnMGpz0H7H8AVG+znkVZY3kKsZyePxB2IbUfVTxSMo7Uw8dRX5 BLmbUrWT5RWUcoF+olPDL+iJ/5p+rBLPmLnBqyzfGFRvKg5EtgNJewFxagPVOoojkVyg2hWiILID 6NMbqJYGVGttBSLbgai9gEa1gWodrWAkF6h2hRWO7AAy9QaqpQHVWlsJkQNokbPQIqehRU6zknCf rM5Ei8SAquZolcZolUZWKsLrIl0a0tSDq4/7BkjXEOkaIV1jpGsCrglCc3Ohc7UR+n99vqHqkHYT IOk2hFRxPmSFhZD2Ys1/C81hPehC1ouuZLfRs+x2/N4Bzb2zmixugi5ys5oDyWOy+ae6006QaqFJ pf8DabUJLbz7sOiOQ5Ofz75UHxqf/ne7dPhioSWfRUStoZOeTpfibEbt6QZqTjfRzQi9FbLcRXQ3 jaFr6Hl6jx6gOTQfd1/ifIH+S6toPK3BOYXWQzuZSpko8V1Wi9WiX1gqO4uWsw6sI2WwTuxG2sq6 sG60k/VkPSmH3cZ6Uy7ry+6nfWwQm0QH2D9xprDJOGux13HWZu+y91gd9iVbwuryZrwFO4e35Oex Frw1b81a8Ut4G3Yev5y3YxfwK/mV7EL+V96eXcQ78o6sLb+e38Au5TfxW1g73pV3ZVfxnrwn+yvv ze9kV/M+vA9rz+/h97MOvD8fzP7Gh/Cn2c38Gf4c68PH8gmsL5/EX2ED+XT+HzaYf8wXsn/w7/kq NpGv4RnsHb6d72Qf81y+m83ie/lB9hk/zPPZfK4Esa8EF4J9I6Tw2EIRK+LZTyJBJLClIlGksGWi nqjPVomGohFbI5qI09hacaY4i60X54hz2EbRXLRgm0RL0Yqli9biQrZVXCwuYZmirWjLtovLxGVs h2gn2rGdoqPoxLLFjeIWliu6iDtYnugr+rGI6C8e4iSGiWHcFiPECC7FBDGRO2KmmMlD4hPxCQ+L 2WI2d8Xn4hvuicViNU8S6WInry8OCMXPtAJWDG9lJVhNeVvrYuti3tkaaD3Nb7JGW5/ye63PrPl8 gvWztYS/Zv1ibeVTrSxL8U8CoUCI/xRwAy7/ORAXiOeLA8sDv/Jlgd8Cm/iaQEYgg68PbAts4xsC WYHtfGNgZ2A33xzYG9jLMwP7Awd5VuBw4DDfGcgP5PPswFE7wHfZ0o7hB+w4O45H7Hi7Bld2kp0q hF3P/osI2efa54o69nn2VSLV7mR3FufY3e3HRSv7H/ZTopv9jP2s6GmPtceK2+0X7PHiDvtl+2Vx pz3RnizusqfaU0Vfe5o9TfSz37LfEvfbM+yPxQP2LHueGGIvsL8WI+3v7O/FE/Yie6V40l5trxHj 7bX2WvGSvcHeKF62M+0dYqK9xy4Qr0qSXLwjpUwT78nGsqX4Vl4gLxbLZVvZVqyRl8urxK/yGnmt 2CCvl9eLDHmjvFFskTfJm8RW2UX2FNvkHbK3yJb3yHtEjrxPDhG5cqgcIY7KR+VjFpdPyactS46W z1q2HCsnWY78p/ynFS8ny8lWdfm6nGIlyOlyupUoZ8i5Vk35jVxkNZXL5CrrHLlO7rXOlXnyiNVR Fkhl3eg0dhpbtzhNndOtW52znXOsbk5Lp6XVw7nAaW31dC5yLrZuc9o6ba07nL8611i9nQ5OB6uP c63TybrbucHpbN3r3OrcavVz7nD6WPc7Dzh/twY4Q52h1mBnuDPcesh51HncGuI87TxjPeI864yx RjhjnbHWo854Z7z1mDPBedV63HnH+Zc1ypnhzLBGOzOdmdazzl5nnzXG2e/st553DjmHrLFBAJ81 LmgFLWt8UAZD1otBN1jTmhhMDiZb04K1gqnW9GBaMM36V+iGUBfr3VCvUC/rP6Heod7WR6G7Q/dY H4fuC91nfRrqF7rfmhV6MPSg9VlocGiw9XloaGioNSc0LDTSmht6OvS+tSD0ZegHa2toZeg3Kye0 IbTVOhA6HE6xIuEG4XGBtPD48BuB58OzwvMDr4eXhPcG3nGlmxT40T3DvSKw3r3FvTtwyL3PfdAO uv3dgXasO9gdYse7Q92hdg13mPukneiOcp+309xx7ji7iTvefclu6k5wp9pnuG+6b9qt3Onu+/Z5 7gfuJ3Zbd7Y7177S/cL9wm7vLnAX2B3cr9wf7I7uT+4vdmd3hbvC7uauctfY3d217ka7l7vZ3W3f 5e5zD9mD3SNugT3MjXhkj/S4x+3HPcuz7Sc8x/Psp7w4L9Ee4yV5SfaLXopX237JS/Ua2hO9xl5j +3VvpDfSnuI95j1pT/VGec/Zb3kveC/aM7yXvQn2TO8V7xX7Q+9V71X7P95r3hv2R9407x17dgyP ibHnxcTH1LQXxdSKqWMviTkYc8T+hXgI8juRe1m166gppdEpOtQclaG2UTOVBf+6MlNE1KvqA5y5 ajTurlNdkWchfFl+fJbagetm/+5Aqfw6dofKw/l7nCyjnn1wL5VL7yNwX5QI2YAaEnUtxz2geSHd ryoffhczeTfycJ9RksbCpymjzp/UJpWjfkYJ6XjazPJorMDhoNQJfulbVLZaqLb6d3tL1b4Tbr3a qJarQ+oaCqLtTqd6xeIj5VWm9qPv8lDC75Sj/SGxRGPfUm+RC1fUh8fk3gW3Va1FGRtwG4Cc1Zgu ga+uif1WLVarwD/gHejtZdf/nnpTvY7fUXBt1NlqkBoIX7F2LHx6+LJL5Y6o71QmOOg79SPoQD/o 1iuZqyjtT+U0BUFPJYoxvuf9kByU/XMhbxbnCj8kD0++F22/Tu2DvB+LoJbohaLa1U7TQzsLU5fK n622Y4zlFLa4Xhk1v78VT1Me3X66tSXu/l7i7oeKlYGjuUnvc5pajf5z1Opyaj5YbGw3p/PLSf2+ +pce0eq7CtNUMv82zR2aZ0vFrKxAbjyZesr4Zh07ntXtFcgPHlGfGNzaoPutsod616Dpu2jX0odT oRJy1RyDmhXkizJK2Ftxriojt4+w6pcq5f7QXFdr5Djlx18qUP+26Fym8sFH+ypdg3vC2CZwfzO1 FM54m6OnH1+3jDyn4ayL87QSVL7t/y6JnifI37zM/H7rgkv2A532H49g4OcutQcItsmMKc3Vh0z4 iyY6VX2p5qsVekY/Tv6CYv5nKRn4fzN10iPED1uPuWFuaSwuypNfzD8OM08sXU294J/ph2Wg9ZYd f1YtrN9w9CvIHwT69PeRXId/pD4goWYfN/+xXBiA9NQH4c/58T+o79H+//XvSuP3kWL+0cidTB1J S0Jt/LAv1Oco4d/HrX9L2eER9JjGR3W9ulb1Vp381FNK5X8cKPaW+rdaqlYUC+bUnZ6gMfA9T2P1 NzP0Pjh3Js2GdDiX5lMLs6rQir6hVXQe/UpbqT1lMka3sF6sFw2ARv83Gqh1eRqstXh6iN/L+9HD 0MfX0HC+jmfQCJ7Fs+hpvoPvpFFaN6fR/AA/SGN4Ps+n57VuTmO1bk4vQDcP04uirqhLk0Q30Z1e Eb3EbfSqNcuaRVqrVfR6ID4QTz/Zn9qf0s/2F/Z8Wmyvs3+jpbayFf2idTparnU6WiOvk9fTeq3T 0UbodDfTJq3TUbrW6ShL63S0Q+t0tFPrdHRY63QUgU73LCNocy8wW74oJ7Gg1ulYrNbpWJzW6Vg1 OU1OZ9W1TsdqaJ2ONYZOt5edBW1OsU6OcAKsq+M4IdbDcZ0YdptTzanOejs1nJqsj5Pi1Gb3OqlO GuvnNHAasQedS5w2bAC0tjvZIGhno9gQaGfPsqFa/2KPaJ2IDdM6ERsefiQ8jj2mNR020Y1zk9hc 9333ffatm+HuZgu1rsGWa12D/ap1Dfab1jXYRq1rsE1a12AZWtdg27WuwXZrXYPt0boGy9O6BsvX egQr0HoEO6r1CM5jgjFhLmNqxNTkoZhDMUe43lNYbTiGGY7h4JgJ0Cgm0j/B06/SdIS8hVPS2/Qe ZqkZ4Cfb8JMNfpqHUfcFuCpkuCoErlqE8P/SCgrTSpwcXLYKUvWv9Bukq/WUjjGWAZ6rR5m0ByN+ L876tI8OUgM6hLMhHaaj1Igi4MhqhiPrGI4UhiNdw5EuOLIvxfF+4EvX8GU8+HI9JfINfANV5xv5 ZqrJ03k6JfEM8Gttw6+1DL8mGX6tYfg1xfBrda64ouoC4j8lgGs5rjioBnhXwo/Op2QRBB8nGD6u BT7uRo1Fd3BzE3BzL/hvA083MTxdBzy9npi1wdpK3NpmZZJtZVk5FLZyrTxKtfZbByjWOmgVUF3r KLi/keH+eob76xjur2O4v47h/jrg/sspQbaT7Sgsr5BXkCWvxHgIYDxcg5D2sj1COsgOJGVH2ZEc eS3GSQOMk+uQ93qMlqAZLWG9AkKevBljJgZjpivVk91kd4qVPWQPaiR7YhRVM6OomhlFDKPoPuTq Kx9Emr/L/ggZIAcQlwPlINQyWA5GyQ9hpIUx0h5BrmFyGMKHy+FIPwJjzzNjj+n1FKQZJZ9BvaPl s4gdK8ciZJwch1wvyBeQ5kU5ASET5URQMklOQgjGJ4X0+EQ5r8vXkWuKnILwaXIaypkupyPlDDkD Ie/Lmcj7gfwA7fCh/AQt86n8HHTOkXPQJnPlXFD1jVwIar+Ti1DmMgnOlCsleFKulmtR2jq5kdLk JpmBNtkis1DXdrmD6sudMhstuUvmUEOZK3NR4265FzTnyTyk3C/3I/aAPIDwg/IgKDkkD6P8I/II Ss6X+Si5QBZQdXlUHkXtERlBXiWV/n9VJ0B1NJrgCjTBFWiCK9AEV6AJrkATXIEmuAJNcAWaEAOa PI3rKGcUcY0pZGlMIaYxhVxgyjBch4dGUpxGFhJAllXkhleH15AX/jW8l+I0ypDQKEPJQJkMqu5u cbdQgrvV3Uqeu83dRoluppuJ2Cw3i5Lc7e52qu3ucHfBn+PmIH2um4s0u93dSLPP3Qd/nrufUtwD 7gGkOegeQpoj7hHE5rsFFHYjrqIkT6vW1TV+4Wp5Fq4Bz6Z4oJhDNb2gF6IaXtgLI6XreVQbuFYd IQleIqVodKNEoFsKrrW82kiT6tWlBC/NS0M59bz68DfwGiB9Q68h/MA+hAP7EPKa9zpqmeJNRa43 vDdQ8jRvOsp8y3uHamg0JKHRkOI0GlIcEOs/PhqOwykMGgaAhpPgfxU4KAwO2kDB9+GfSZ/h+jmB 24CGX8L/NTBQ0ELgoAAOrgRirgK+CrN+7xgcFAYHaxgcTDQ4GDI4WNPgYJLBwWSDgykGB10Wy2LJ Y11YF1z7sn64PsD64zqQDcR1NBtNHlDyeuIGJYNAyd64apQMG5QMGpSMMZiYwLN5NlUzOBhvcLA6 P8qPUqxBwDhhCYvigX0O/CERomqii+hCtUVX8yabxr46Bvvqih6iB8J7mrfbNA7WMThYV9wu7qBa RTiYSQIImEcOsK+AQgb1UgzqJepVW4zPS+WlGL2XyctIGIxz5FXAOAsY1x5+jW7CoJtt0C1JdpKd EKLRTcgb5A243ig7I6XGOMugW6JBt5BBtxSgWy9y5e3ydlzvkHcg/Z3yTlz7yD64aqRzDNKFfKQb KAciZBCQzjYY58iH5cPIO1QORfpCpBsJfxTjHpdPwK+RzjFIJwzSheQYOQa5npPPI0SjnmNQz/VR b7wcj3CNfY7BvhSDesKgniVfA+oJH/WmyqnwvyHfAKK9Kd9Eeo2DwuBgSjEcFAYHHeDgHPij2DdP fgX/N3Iprhr7HGDfWvg16tUwqJdoUC9kUK+mQb0kg3rJBvVSDOq5cp/ch1wa+xIN9iUZ7Evxsa8A GCcMxrkOcxiJKFqFhoQepmDokdAjuA4PDadwaCSwKRx6LPQYQp4MPUlBg1M8PD78CnGDOAnuLmBN nLvH3UvxBl/iDLIkAFkOwn/IPUyxwJQIxrnGlGqe8ATFAk0kxRgciTc4kgAEiYdfI0h1r6ZXE2k0 diR4dbw6CK/rY0c9lKCxI95gR5zBjmoGO+KBHa+hzCneFOSa5k1D+ulAjXiDGpx4i9165fW8bZe3 omvoluPJ+f9/HCpLbdfOv9tUlt6l13nMWl9ly96iV7iM5v2luV9XWKe5LvW1z2ytfxpddK1KV5kl V3TKr7dwhU49WHkKT+2h2kPz1L/H1b1L5ciCpv191ddlisrJPvZO7TFXPxy6Yh5aNl3lwBWt7BXT RBOK5V6LVGtIr3vUhM9fYSzUrv+gI1RETfF6XbrVhO0sa3VB7Si9Nqf2qs3qV8SU2oWo6lG4Sl7y To8fn6uLrReAdlHkzz5eL6uNpVc1T9VR9g5OubmmqzfMb4FZDf9BO70+pN6Fb5GfppCz9Ajer5YU hleqni2GR9N/v9erYGp9sRTPmfUgvVa+0fi2gJriCOW3b0X716xap5efrvIHOK1YueqAKoA7ote6 1NES6U60L/V/7PiDx3wFDjX5JDJfV0Z56dQUPJh6EqWe+GhKBls1nhpMLfMANlR4D/Hk54pjyitB VfGxV8H8H6n56kN/fyBBTVHzTWiGnt2Lz95Vkh/WABs3Gfkh08gmBs30nKQ24XeGnyrH7Lf9F24h zsySK9cGyZKpcG32W8wFi9QyuMkIvUYtVz+a8BVRKcLsaN9aeUpLUb69xJ2ZQ9V/ioXcq6apfuoZ vcqv+heFXoiwz/S4K73rSHrPtfRe6A71JZ5l7akbqYX8oOcxIFihXLiI/P3Z4jQAl4v2RvQeSzkl /3yqaKzqgVbyzO8Ler+5VOxA9W2JtNHf9ZjdMjSHVKG+lZrrjbxl2kn7ML9t8lsNV3WPWmz6+yCJ MuYwj5qVKjMH42CXv7skgByFu04Ho7EnP7/9vg9dcr+yUErRspeZt7fgzCkle240smcZox2j+RRj V1nHMXi2vFR8wbEhfvjfyw6nyuyjV/pQd1UyQ/Qdi1HqSfObaxDgY+3g+5eaFfWZuEL5zOx3oqc+ rwJ1H6nPgJif+nffqvdIvx80W/vhgJxAsW+BEoVScC7Q90cfJ6L7ZzGlyvxefaoW+GUm6Ds/vAQ6 KFV5ak0+jFL1a9Fdoe6yWfsK9cqoJG4QbZHmj+g7Iv742WsQubu6ztwtIL2b9yDcQ/CNU5Mw1z3k l1Ls3Ra0wFw1tArU3qaGqzdVP/i+xqh+U/Ux+PAcZqM30c4L1GR1N+bWXL0HaJ5sjpqppkZr9meN FPX1MWVmqlXQKqMj99winy93qsNRV3GJuUTZeWa8F70VVHKWMvN0keZrJN9N5r2H4m9cnF3yjZU/ 6ii5i2veYNpVPiXmiUq9f/VHHCU1Wd2q4OF95eGn6Z1TpulW5iguf2A0aC1rNX6Ps9NdlHLHydOr XlPD1D/URONfAn5/Q78p489DUXlxv/oEbv7J1WNKahZ9k+WkyshQ2zATmvkRfboNfFgkc0d7Xe2G zLG7LAmw0nVVQeYulvvHaK+CFo2DP/t3G/3x41P954znsg51l7pTzVOziJu74Wow0LpXVCJQs9Uh 3I1Rf1cXqAbA0ZbqIXXPSdQVlR/TTopeH5OiOm3R+4ZvlIw9lYeafgrK0Ny7KorqkG9L9b6JT1e/ /D4L/7kHqFmHMWfWPMHDWlMs0lSiki5iv4c7zruqf/QBep8vPnIhX835M+k5/oHRNlDLTtE3XdUA SEcrMPqicQvMdZ36XHVVz8A3Vv0WDatiXd+fPL2VrDGv+Hte/3ePIhl378m/XVnWu+6n8ohKh5C/ t2LWOwUrFuW9o3zCvBXkKPWBWdvfWfWaih3Jp6SUCh2QhU5aclUvnApKyqnDRzpItye9Ln+Keqm8 WjIg2f6PR8qpOyD15J2ylok/CTpOxXj/A/cjqsKNkHvSozn9LzsK10UWm32GxSfMfL+f9sPK1/tH H1X5BqJUGcfdDTlBHrNar1eKoppwdEWnaC84dCL92KztJlM/sitfr8lfha+8VKaZO37/lqxwTa6i ul2Yrqp8rX/qkVjVjJXfeSL9VoPely7S7NVcc90FfC53N+L/2gG5f//xv5kolu7Q/56Wih0VQ8iq zuplfitVbl3mDYLfvx00OxZFnBUqM1NhWr1WVZu6Ysz9CUdJ2T2KGtCeysFZsxPzJ6z3qT2nsKzN 5K8ol/nF0WnmKye9g76kjNjyytbfUW0uzFnoMyv8m/2QwjovNHUdQ1exu6d/L7OQFv29Vimq9FdZ zfUuTVW0djVZva3mFH0H5vu0ROCvaS4poqN5KXrfrnx9JfJX4U0h9YvZlfhv0b15Bwjypl3hnb4K fL13nLrL/Da5nDzbzKqVnskNFpi7bzH2osgQOpF8aWaUWLqkYt9rlpG/Ku8/LNffWxp3IHpvrv6q +YnRwX+W2iXfNwJ/7VHLjJtMNSGTbvd3kzZFx7ThtXsrT2k5zxHdYSumrate6iH1jnrd2A0oeqdH tVcfVbLkb/8YiVnTePx6VKSsXeXojuIxYXvK38Wp6mHekfGRWe2FPLEX8tEatfZ3JFLZCNN7xuer m8z9x+CAVaq7Wqjv1QL1kvpOr5ibuBdLlL2+MLxSFHVS/dRj6hr/zvjAgX2M/201TfUHH0yGtDYH M69OMUt9qj7xZ229Op9Izcye8xDV14RF30d8HXL1a7o/tJWEoreASqwFqcOFX/NXit5X1LvQ1f7p 3y02dU82OL/YtIHeff1Q5amvTILoV/v+GwY+F59b+Vr/rON/8jV26Vo2FyJWdN/5zzqqsk+Fnt5F xVYdiiwkVGTuqU76/Z0bjL82tYTumWbyboXUsdXMJrXoL2olRqg+16sN6gKMlz7kqui87uupGJ1R naqmf/+Rv1PBqeiLaRP+/gmew7xboYZinvNXINWlqidce3UXVVfRObjQhsZwuCvUhaqz8r9sUD+o 38zbEnrE7sCctNnXX8+gpmbmPMOkOvHqRtl0vaGm4fpu0f0crcuVeLPiRt/Tlf5G51MLYyemkYkp /uyhyC8qHDloZsp56j71sZ7D1Aj1hPah1NElqo2+A3ZfFejtqx7A8z9gbhz4+hrcfMLM1MvQl5mR 6Jf0s41VkMLDtKwa4JdRAR2vzLq3l5+mVJ5s80aAlhMMNxlu/hb3lol2Tyjv6FyxdBGo57S8HDt2 XXw7do/T1YyzGtTbWKcbYqzTjTLW6UazLqw7jWP3sHvoJWOX7mU2iI2mSWwMm0gztXU6mqOt09Fc bZ2O5mnrdPQF+4otoQW8GW9Oi3lL3oqWaut0tJy34W1ohbZORyv51bw9reb9+QBay4fwh+k3Po6/ SBv4dD6d0vk7fCZl8Fl8Nu3kn/PPaRefx+dTDv+WL6Q9fBFfRPv4z3wx5fGlfBkd4Mv5cjrEV/FV dFi4wqMjIk7EU4G2MEfKWJgjY2EuIBqKhkwaC3OOsSoXFq1EK+YZq3IxxqpcnLEqF2/syVUXXURX liB6iJ4sUX8rx5K01TeWoq2+sbOt2dZ81kVbfWO3a0tv7E5t6Y3dFYgLVGN9AgmBZHaPtvfGHgj8 FtjMBmt7b2yYtvfGhmt7b2yEtvfGHtX23thTgf2BfPa0tvHGntc23thEbeONTdE23thUbeONTdc2 3tgMbeONzdc23tgCbeONLbW720+x1dq6G2fauhu3tHU3HtDW3bjU1t24Y0+1p/EYbdeNx2u7bry6 tuvGa2u7bryBtuvGm9iL7DX8NG3RjV+gLbrx1namvZNfpC268Uu1RTfeUVt049dpi278Xm3RjT+s v4/jIxzucD7SsR3JH3XCTpg/7sQ6cfwJJ8FJ4E86SU4yf8qp49Tho5x6Tn3+jLa4xp/VFtf4GG1x jY91mjvN+Qva7hofr+2u8Re13TX+stPWuZRP1HbX+Cva7hqfrO2u8de03TU+Rdtd4286dzl9+DRt d42/5Qx0BvJ/aetr/F1tfY2/p62v8RnOM84zfKYzxhnDP3DGOuP4h9r6Gv9IW1/jH2vra/xzbX2N z3U+dubzec6XznL+g7PKWc1/c3511vENznonk292tjv7eLa2ysYPaqts/JCjgowf1lbZeIG2ysaP aqtsggWTg6nC0/bYRPVg/WBTkRA8I3i2qBVsEWwh6gbPDZ4r0oLnBS8U9YIXBy8TjYPtgu3EmcEr g38VZwWvCbYXzYIdg51Ei+DNwVvEucH7g/3FeaG0UENxkbbuJi7V1t3E1dpam7hGW2sTD2prbeJh ba1NPKattYlnwjeG7xAz9Fd7Yq621ia+caUbK37SdtrESrere7fYre20iYi202ZZ2k6bJbWdNiuk 7bRZYW2nzaqh7bRZtbWdNquOttNmpWk7bdYZ7nR3hnWmttNmtdR22qzW2k6b1UbbabPaajtt1qXa Tpt1tbbTZl2n7bRZ12s7bdaN7mY33eqiraxZ3bSVNau7trJm3a6trFl3aytr1n3ayprVL4bHONb9 MW5MjDUoJj4mwRqiLatZj8QcjDlojYilWGaNJM7SgXox0PhiKY4YVcMpKB7zsEVJmLsDmNUbIbwx TklNMAs6dCZQMgg8vJBc4KH+n4dLzD9gaMSMMYgZC8S8CbluxlkNuNkdJfagO6gt9QaGXgoM7Q/J YQDOy2ggDaEa9DDORBpKI1DzSCBsEhDWpWTmsRhKMV8I12JxwNyzgLlNENKUNaVm7DR2OsLPYGfA fyawONlgcXNgcSdcrwMiX2HshSaz7sDlFgaXWxhc/gtweRjCh7OnqSUbxUahzGeA1LWA1GOpFRvH Xqbz2ASgdnOD2s0Najc3qN0MqP0u/O8Bu5sBuxdiPviOfUcXsu/Zj3QR+wlofrFBcw40b4nrucB0 22B6nMF0bjA9zmB6gsH0yw2mn2Mw/XyD6bWB6e9SXf4ef4/q8Bn831SPzwTK1zcoX9+gfBpQfh6u XwDrUw3WNzRYXwdY/zOui4H4aUD8pbguA+6nGtxPNbjfALjvUiPhAf0bG/RvatC/CdA/iU4XySKZ zhApIoXa/T/Kzgcqquts93uGOXsOcABFooiEGEKQICEECaEEDRJCiLGEEmP8rHUGGGYGGIZhmBmG YTjzl9Eaa421hlhrrLXWWmOstdZal7V+1nqNy3KNNdbPGGr9jLV+1lpjrbHmPvsdYm3Xumvdq2s/ s9d79tnnz8yc/XtY8ihWAvSxErDHsBJMgxYkPIa9sB6wIrEeYK/KhEroMwnPYOvMhJnQWQmzMAZr AxRrAyrid61foN+1rqffr36Bfr+6nn6nug7rRIDN0gV1S5gGq8VKlqZ7Q7eGfUH3pm6YTdC9pVvP KnVv677DJuk26t5hk3XbdT9hWVhRfspKRZooKxPrCqsS6wpTxLoCHSeNY7Ol8dJ49qRYXVgpVpeT LEH6rfRbNlU6JZ1iadIH0gdMJ52WfsckrDpnUflQ+hCVc9I5ppc+kj5isjQqjbIHpN9Lv2fJYk1i KWJNwshL0iU2Xvqj9EeWjpXpT0wjXZH+B0e8Kv2ZTZCuSdfYJLFW4YifSJ+wTOmmdJPNlP4m/Q3n dku6hfP5u/R39G9Lt9H/VPqUzZL+If0DM9/lWjaBJ3Adm8UlLjENVjg9w2LBZZbCE3kSS+PJPJkl cIUrLJOn8BQ2k6fyVIzBKij+V3c+Aftm8AewbyafjPFZfApL59n8Qcycw3OYSEB9GJrLczHDI/wR jM/jeRj/KC/A+Mf4Y2wSL+SFqE/n05mOF/Eilsof58WY/wn+BPYt4SWY7Un+JMaU8lLsO4PPYIpY cXGsp/nTqFfwSox8hj+DGap4NZP4bP48RtbxOqbnL/AXcM4v8y/hupr4q5j/K9yIozfzFhyllZsx j4V3smpu491sNndwF47o5h5Ww/s4nh68n/vYRD7AB3C2fq7iWgI8iHlCPIQZwjyMGSI8wpJ5lEdx lCE+hDExHsNRQABsiiAAVgICeIOV8VV8FZshOIBNBge8ia3DfJhl8bc4ngP8W/xbrIqv4+twtzfw DdDv8I2sVGTAYjxYATP8kP8Quo3jU8q38+3Y912+gz3Pf8R/hJl38h9j626+G/v+lP8U9T18L0b+ nO/DyF/wA9j6S36QlYMwDqP+a/5rVgzO+F8Yf5QfReU9/h5GHuO/wcgRPoLz+d/8BMa8z9/HGZ7k v8U5n+Kn2OP8A/4Be5qf5qexLxgFe53j5zDzR/wj7PUx/xizXeKXMf5P/E8Y/xf+Ccbc5DdxN/7G /4Zzu8XvsMmCY9gMcEwK+qn68axMn66fwKboM/STWLk+U5/NntY/qJ/KngTlTGNV+gL9Y+xFfaF+ OntGX6QvQuVx/RNspr5EX4IZntQ/iZGl+lKMmaGfga1lenhHsNEX2FP6Sn0ljvWM/hmMr9JXYetM /UwcS2QKaAQzsVLBTFAwExTMBAUzQcFMUDATFMwEBTOxLMFMbIpgJiiYiT0umAl9MBOrEszEJous WlYsz5ZnYy+QEyogJ4wBOUFBTqxckBN7GuQEJyBbZAubCX7qZmmyQ+7BGFAU9gVFoQ6KwsigHMQ8 ITmEflgOow6iwvmAqDD+6/LXWZm8Ul6JvcBVbAa4ag0qb8r41MnD8rfQ/778fRxri7yFvShICxWQ FksSpAUFaUFBWlCQFvSP8l/Ys/J1+TqO8lf5r5gH1MVKBHWh/5n8mfi/txIZez5Rk6hhkwWBsSkg MD1UTpTZU4n4w0oSkxKT0FcSU6FpiVh/E8cljmPlieMT01GZkDiBVSVmJGawGYkPJD7AZiZOTJyE +uTEyawsMSsxiz2eOCVxCvrZidk4yoOJD2JrTmIOKmA79MF2OBOwHRRsBwXbQcF2ULAdFGwHBdtB wXZQsB0UbAcF27EkwXbsWbDdK2xc0rykeYwnvZr0Kvrzk+aj/1rSa+gvSFrIMgT5obIkaRPTJn0v aRv64D/0wX8YA/7DmL8na5g2WZucxZ4TFMgq4tkNggKZVlAgFBQI/bLyZfagskhZxKYqX1G+wsYr i5XF7CHFoBjYI4pRMbJcpVlpZglKi9KGvlkxY7xFsWCMVbFiTKfSib5N6WJ5il2xY0y34sAYp+LE 1l7FxXJAln2oexUv6uBLqF/xQwcVlWUrASXIHlZCShgjI0oEI6PKEI64VHkdleXKCswMBsVRVimr oN9QVmPMGuVNnPOwMox53lLWov8t5VsYv05Zh/63lW9jzvXKemx9W3mbTVM2KBvYY4JcWQHIdROb rnxP+R6rVTYrP0B/q7IVY36o/BBb31Xehe5QfsSKlJ3KTmz9sbILW3+q7GGFys+Uvaj8XPk5KuBd KHgX+kvlIHtU+U/lEMb8SjnM8pVfK7/GyCPKERzlmPIbVEaUE5gTNIz5TymnoB8opzHmjPJf2HpW OYt5PlTOof+R8hErAyX/HrOdV86zaYKVWQ5YOcyyUyIpUZabMpSCuwRuXsqKUr6agnuVsjxlOXso 5WspX0PljZRVbHrKN1K+wWoFT6MCnmZFgqdZhuBpphU8DQVPQ8HTLEPwNCsF2VUTT9cRT2uJpOPc /DkxCz5OJT5OZf+Bv6lExvVExnOIjNOJjOcSGU8kMp5EZJxJZDz5vvweifJ7ZMrvkSi/R6L8niTK 75Eov0ei/J4Uyu+RKL9HovweifJ70ii/R6L8njTK75Eov+dFyu95ifJ7JlB+zxcpv6eB8ntepvye RsrvyQKpJ4ObUzQpxOiT2VOaLE0WGFqQegVI/WVWSSz+iuZVzX+gLlj8GY1ZYwZhuzVuqEfjAzf7 QeRPg8iXsplg8a+i/7rmdYwXRP40iPxNVg0WX8dmg8J3QX+i+Qmr0ezW/AJbBYW/RhT+HFF4LVH4 86DwEpZAFJ5wH38ngL+fI/5+Efz9ElG4SBjSUcLQeEoYGk8JQw9QwtB4YvQvEaN/QftV7TI2SyT7 s3ljpC64fLr2Xe277DHtHnD5I0TkjxKRT9O+p30P/C1Y/GHtCe0J1H8L/n6YUose1P5O+yGI/CPt R1CRYFREqW6F2gva/0blY+3HUJHtlkPJRnna/9FeRV/kG+Vr/6K9jr5IOSrQfqq9g77IOnpIe1f7 GcuhxKPcBE2CFn2Re5SfICVI6Iv0o1xKP8pLSE5IRiUN9F9M3F9K3F9G3N+UMCUhG3VB/8UJj4D+ n0jIB/0XE/2XJBQmFKJflFAEfTJhBpsBJ/A0+hUJFezxhC/ADxSTH3gyoQp+oDjh2YRnMb/wA8Xk BF4lJzCfnMCr5ATmkweoA/2vYang/vUsnYg/k4h/ChF/hW43iP8ZEP8hNlP3K90xVkPcX3tfJpNE mUxplMk0gTKZGskJzCEnMJvymV4iP1AJP/A+4+QB9NLv4AE4eQA9eYBUon890X+mdEG6AMq/KH2M iuB+TsQ/iYh/DhF/OhF/JhH/ZOmGdAMqmL6OmF5PTJ9OTF9HTK/lHEyvJ5rXE81PJmqvI17XE6mn E6lPJjqvIy7XE5dnEpfXgcXhe3kxiJwTi6cTi9eNUXgZL8P4cl6O8YLF64jC48ytJ87WE1vXE1vP IbZOJ7aeS2w9kdh6ErF1JrH1ZKLnyXw5Xw6m/Br/GmhS0HMlEXMVX8PXoC6I+Ski5tl8PV8PjhSs XM43gpWriJWnECvP5Jv5VnD8D0HJU4iSXyE+nsl38V3YS1ByOVHyK6DkPdj3Z2DlKcTKFcTKM/l/ 8kOY4Vf8VxgvWLmcKHkKUXIFUfJMouRafgKUXEWUPJsouZwoeSZRcjVR8vNEyU/xD/mH2Cr4OE7G T/Er/Boqgo8riI8riY9f4Xf5XRCqIOMqIuOZIONJ6AsmriYmnq1/WP8oqyEyriUyfo3I+Dni4NnE wa8RB9cSB0/RP61/GioI+Hki4Fr9s/pnMadIFEujLDGJssTSKEUsjVLEJEoRS6IUsQZKEZMoRUzS N+mbcHSRJSZRllgapYi9RCliEyhFrJFSxLIoRSyLUsQkShGTKEVMohSxNEoRm3BfilgapYglUYpY GqWIZVGKmEQpYmmUIibdlyImUYpYGqWISZQiNoFSxLIoRUyiFLE0ShHLui9FTKIUsTRKEWukFDGJ 8sOk+/LDJMoPS6H8sDTKD5MoP6zxvvwwifLD0ig/TKL8sDTKD5MoP0yi/LA0yg+TKD/sRcoPe4ny wyZQftgXKT+sgfLDXqb8sEbKD8ui/DCJ8sNeovywBsoPa7wvP0yi/LAsyg+T4GEmsEo4lkfZbPIn NfI0eRq8QYFcANafLk9nFXKR/Dj8RrFcjHqJXDLmW8rlUnkGe57cS7lcLldAhYeplZ+Rn8E8wsPU yHXyC9B6+SXMNlf+IsY0yA3sKfllOJmZcqPcBIfwmvwatgo/Uy0bZAPOp0VuwV7xJEbhcGrhcDpw LOFwUuUe2Yl5euVe7OWW3ew5uU/uQ2VQDuAqhM+pJG8zhZIby8nhVMkr5BVQ4XOeJ59TJX9TxlOC fE45OZyZ8tvy26h8V/4uji7cTi25ndfkH8hbsZfwPDPld+R3MOZdeQf0x3A+yfI5+Q/Q/4bnSSbP 8wJ5nhr5hnwDMwvPUyl/Kn+KqxOeJ5k8zyvkeWaT56kit1NObqeS3E55YgocThUcznhWTQ6nlhzO c+RwnofDmQgXNCkxEyMnw+FUkLeZQn6mBn5mGo5SCD+TDD9TBi1PrITOhIdJJg+TDA/zMlS4l2Ry L8nkXl6Ae5k35liEV1kAH7KQHMuipEWotCa1sllJHUkdUFuSDWpPskMdSQ6oK8kFFVl04ymLbjxl 0T1AWXQPUBbdeMqiG0/OJ4G8zZeSpyTnsi8kz0n+EpuVbEr2sXmUVKcjt6ODw5kOFyE8zHTyMI8p bfAwDyvtSgdIXfiWh8mxTIdj6UbfofTAOXgUDyrCqzyiDCgDqAwqAbgU4U8eJX8ynfzJY/Any1B5 HS7lMXIp05SvK1/HeOFPpivfVNZg65vwJ9PgT97CbMKfPEr+JO5MHiFnUqx8R/kO9LvKd6HCmZSR M2lSfgBn8iScyTbU31G2sxJyJk+SM5lBzqQMzuTHqOxSfsIeV3YruzHyZ8rPUBf+5AllH/xJsbJf 2Y+th+BMSsiTlJEnaVKOKu9h6zHlOOrCmcxQ3lfex0jhScqU3ylnUP8veJIZ8CQfYrZzcCY55ExK lFFlFMcV/qSU/MkTyh8UMB6lAxZRHmmhclm5gopICsxVrirX0Bd5gfmUF5hLeYFFlBeYS3mBD1Ee aY7yD+UfUJEdWKR8poAAKUEwD2AOAqQcwYcomzSH0gQfpGzSHMoUzKdMwSLKJi1MSU1JQ13kC+an TEiZgIpIGSyglMGHUjJTsrBVZA0WUdZgPmUNFlDWYF5KbkoutorEwXxKHMylxMG8lI6UDvYwObFH 4cRC5MTweUhZkrIEDm0p3Nej5L5mkO9qgu/6JvprUoZZCbmvGSlrU9aiL5IL8ym58EFKLiyi5MIC Si7Mp+RCHdNMuZ4dBPwqCcvYR4wZF6IZ0cxoNjQnmvfeq8axFa8qWhRtGdpKtDVo69A2om1B2462 C20v2gG0w2jH0E6gnUY7x7TBo9SY8QI1bXAE7RT6l9Guod1Eu8NYsxZNRktFy0DLQpsaP4fm/P/L a1F8rubSsSb2qUCbRdtYcy3anPj50j4b49fY3Ig2H21RvD72qg2epaZx7EDbjf75e7V4u4R2dax/ Cu3GWP92vIXYWONoClo6WiZaTnxsKI/Gs+YWNGv8PjXb793z+NhCGseaXWg+tCBabOwalsePFyoZ u9ZVaMNo68e2bxrbXj7WqlDD+9gsrmcf2sF71xK/5t1o+9AOoh1BO452Eu0M2ijaxbHXK/e9fj7+ OtqtsdczY/vdum/7XcZadGhJaOPQJqJl//NVvH8tuWgF/8+v2lDNP98rcW0txWPv9f9vy/rXRp/v ZfHj0OcqKz6Ojnt/K0Or/OfrvTni82pD9ahXo9WNff6wrWXuP19bmtAW6MYvHu2aMzhijHYzUk6q QJd1p0NXdmdC13TnQNd150E3dhcOjoi9AouMW7pLAi2LL3Y1Dp5afKVr/uBZ4/buctKqe/1d3TWD Z8XWgHXx9a5Fg+eNe7vrB8/H+2N6q6tl8JLxQHcD6TzoYeofpv6x7oXQE91G6OluM/Rct23wktgr YIda0b/bZR+8arzQ7YRe7vZCr3Wrg1dFPeAy6LpcgzeMN7uj0DvdywI+Q1KXb/B2s7Z7Jeka0nVQ ubkWmtq9EZrRvQWa1b0dOrV71+BtsVcg2JzfvVddZxjXFVRxZ7sPqMwwsSumcqGBmCG7a7mqNJd2 H4ZWdB9TFVEJLI/XxzS3a5WabijoGlYzm2d1n7intd2n1UxRD6wa0+Ku9WpO85zuc6QXoI3Un999 Gbqo+xq0pfsm1Np9557aHdrAcLPLIQfWG8q6Nql5zT5HqppHsxWOVYKOjM9VVAKbDJVdW9WS5pgj i3Tq531RD2w1VHftUMublzvy1XLRD+wwVDuK0K/r2q1WNa9ylJJW3OsPO2ZB1ztqoZscc6BbHY3Q HY751F+kVol9A7sNc7v2qTWGpq6Dan3zbkfLPd3naAnsaz7osKr1hgVdR9QGw+Ku43QOdlLXvf4R hw9nYuo6qc5rPu4I3tOTjpg6z9DRdUZd2H6gP0gaI10OPdy/Cnqsfxh6on899HT/Jui5/q3qQrHX kK/9Qv+OoaDB0TWqGg2erouquf1y/27otf59pKJ/s/+gahZbh2IGf9cVlbff6T+i8g5t15Wh5XE1 hLuuq7YOuf846UloKvVTqZ/Rfwaa1T8Kndp/EZrff0W1ib2GVkFvob+0667q7Cjqvw4t7b8FrehH RdSHhg0r7DrV2zHLJ7TWlzS03rDanqSqHXN844R2xKg/Edroy4bO9+VCF/kKoC2+YqjVV6aqYq+h TR12X+XQVsNaw3k12uHyVatRwwb7OHWZ0FCeYbN9orqyw+ergwZ9c9WVojK0I14f0232bHWNYac9 V13XEfM13dPlvgX47qA+tHtM99gL1I0dq3yLSU33+sO+Duh6nwO6yeeBbvX5oTt8Yehu39KhfR37 fCsCLYb99mJ1S8dB3+qhgzTb9rHKEd9a6HGhojJ0xHDIXqbu6jjp20C6+fO+qA8dNxy1V6p7O874 tql7RX/oZMeob+fQGcOIvVo90HERdx7q23Ovf8W3H3rddwh6y3cUetc3oh7o1PlOQZN8Z9UDYt+h UcMpe5162HDWPlc91jnOd/7fdKLvknrMcN7epJ4wXLIvUE93Zvuukt6418/13VZPG67aF6vnOgsG 2D0tHuDqOcMNu0m90HzGsZx0FXSU+hcdw9ArjvXQ645N0FuOrdC7jh3qBbFX4GCLzrE7cMRw296h XjYyu0O91pLk2AcdRzqRNNtxUL0mtgaOG7ndo940cscRoaLfkus4Hkg1Kna/eqelwHGS9My/9Ysd o9Ayx0VopeMKtNpxXb0j9gqcNKbbwwGtMdO+NCC31DluQec67kKbenTQBT1JAdmYY18RSG1ZTGrq GRc4Y8yzrw5ktHT0TCTNJs0NZBjzegrQd/QUQz09ZVB/T6WoY/xoS7inGpWlPXWBi8ZC+9pAVsuK nrnQ1T1NgSxjiX2DekJo4ErL2p4FgevGcvtmjN/QsxgzlPeYhKIyGq+PaZV9W2Cqsca+E+e2uacD uo10Z48Dd0bUb7Xs6fFg9aS+sd6+J5Dfsr/HTxq+p4d6lkKP9qyAjvSshp7qWQs927MBer5nc+Bu y6WebUEd5tkfKDLm9OyE1tgPQRvsR3GeV3v2QG8IpcqocZ59JFDacrtn/7+qqAdhW3sOBfJbec/R 4DjjQvupQEWr0jMSqBD94ETjwh5UjEb7WbquuJ7/vN+a3nMJmtlzFZrTcwOa13MbWuhk0BInx7WL fW8ZzfbzgVlGm/1SoLa13Kn8m1Y50wO1Rqf9amCO0Wu/EWhsrXGsEurMvKf1zpxAo1G13w7Mb21w 5kHnkS50FkKNzpJgtmCSYG6r2VkOPgEbBAtabc6qwUutTmcN1Ousj6/gwWKxDgbLWlVng5rTGnXO U3PEShSsbF3mXChWJacRirUmWN260mlWy1vXOG1YX/B9Cda1rnM61Qvicxuc27rR6VXvtG5xqtDt zmj8MxZsEu9vcEHrLueyQL6x3rkSivsQXNy617lG3BPnOmj8Sg84N0IPO7cEGmnFudhZNqBg9RFP /iudlQPpqq2zeiATWjeQM/Z8vi6eckO3OucO5KkbDXsGCqHiOXO3s2mgRDxzBsqheJLEdJ0LBqrw 9Fg8UKOepk/+aOsx5/agqfWEc1ewo/W0c2/Q0XrOeSDoab3gPDx4tvWy89jg+dZrzhNBP8acxpib znPBcOsd54XgUpPWeTm4wiQ7rwVXm1KdNwevGuY676g1poxebXCtKatXDm4wLOhNVRtMU3szgpsN Bb1ZwW2G4t6pao4pvzc/cMRU1FsU3Gkq7S0N7onzhqmityK43zSrd9bgiCCK4CFTbW9t8KhpTu8c 8S70Nn6+spsae+eTLoLOx7mNmBb1tgRPmVp6rcGzJmuvPXjeZO91BS+ZXL2+4FWTrzcYvBFn2mZt bwwUF+coohRTsHc52JW40RTrXQVd3jsMihOfjdvNLb1Q06reTSFmGu7dGuKm9b07Qoppkxhp0PXu Hrxh2tq7L5QeJzfjut6DgyOmHb1H8B0nRjXt7j0+eKk5q/fk4G3Tvt4zOLq1dxT34WDvReiR3itq nul473Uw2NbeWzifk713oWdcuuAK401XEuYfdY0LZZouuiYGR8QdCOWYrriy45/tUJ7puisX89xy Fajlpruu4lBhm85VFiqJE2ZbkqsyVN42zlUdqhLfi1BN20RXHSgdrB6qj2tbtmtunMBDDffpPNKF dBQjqbkt19U0eKmtwLVg8GpbsWvx4A1B1CFbW5nLNNZ3knrF9yukjt1J8HAoSrpMnFVoZVulqyO0 Mt4nXdNW7XKo6W11Lg94GFQcWtc21+WPM3Bo4326BaTqUvPamlxh6AKhglpD2+Patti1NE6qoV1t JtcKtaStw7UaijoqDtfaOLUGq/+pob3iWx86QHo4rm0e1wawKIg0dKzN79oM8gSXhk60hV3b1Ia2 pa6dUIdrD5jzuGs/2FK8L6fj2rbCdSh0riXXdRTfbvFkTm1b7RrB6pnrOoX+WtfZ0AVjjuu8WBFc l0KX2za4rgaut2123Qhda9vmuh262bbTzUJ32va4eVg79mynp7dxoVsJy2373el4GnvdmeHU+JOw 7ZA7J5zRdtSdF85qG+mpC09tO+UuDOfHGaClw12CtYBWmbaz4rkdX6PbzrvLw0Vtl9xV4dK2q2K1 bbvhrsGqh6dWuKJlxF0frmi77TgZntWy2t0QyDIz97xw1ti6vNm9MJBq5m6jYAm3Wb1gVtw2saa7 neodc7rbG8gwZ7pVHPesOyrWLzeegeYc90rU89xrAhmtJe51n68U5kL3xnCtucS9BecGlgilm8vd 24Mj4urCc8xV7l3xJ23gpLnGvRfz1LsPYBXAmhtuNDfYd4bni3UqvMg8z3043GJe6D4WtpqN7hNh u7hvYRfN4zOb3afDQbPNfQ4eB8/wcCxOO0KDi+P6OdXYPeHlQuOV8CrSYXEO4fWkm8xO94WA1ux1 Xw7IZlXQiCCT4GJz1H0t3sd6B8VeWAvCW8VTN7zVvMx9M84V4R1jiqsINplXuu9gvaA+XddW8xqP NjDVvM4jgyjAFeHd5o2e1DhF4KzuaXi4ZbMnI1Bk3uLJgm73TI2v+JgHGt5n3uXJj6/y4YPmvZ6i QKn5gKcUijoqhz0V8VU+fOQ+PS7WqfBJ0mHSM+ZjnllYu7GCh0fNJzy1WKmxjocvmk975gTmmM95 GqEXPPOxijV4FgXm0z2/Qnp97M5c9rQEKszXPNZArfmmxx5oNN/xuNQLFq3HF77VaRqojyV1dgw0 RBs6HQPzoJ6BherKTv+AUTV3hgfMKu9cOmCLjcMYJ7auGPDGJnauHlCxde1ANJbduWFgWSy3c/PA SrihDQNr1GWd2wbWxQoMqwc2qmrnzoEtseLOPQPbY2Wd+wd2xSqxYu5VN3YeGjgQWdp5dOBwrLpz ZOBYrC7uDgxHB06oeztPDZyOze0869sZa+o8P3AutqDz0sAF+LhLA5fvcfjVgWuxxZ03Bm6if3vg TmSnjfm1MZON++VYh03xp8YctnR/Rsxjy/Rnxfy2HP/UWDjuQDvm+PPhueJOhzyFLc9fFFsad3m2 QlScthJ/KTwX1vrYio5N/orYis4C/6zYalu5vza21lblnxPr6CgSIw0r/I2q11bjnx/bEPdZ7Qf8 iz73s3GPaasnXzmn46JwfP6We0ff6rdCySvZGvx2OKa4x7kLj3nANm/gWqiqY5bfhfkX+n2xzTaj PwifhTsQ22Yz+2NjrLLKZvMvVzfanP5V6mmb1z8c22lT/etje+J+0Bb1b4rtty3zb40dEpwTO2pb 6d8BTw1nHRshPWVb49+NVQMOGusFNHZWaIA8dey8OErsUlxt6/z7cEUb4bmcti3+g6pX+N/YVdt2 /5Gx/g3S24KXlrCxOwn3uoSPKc5qiWLb5T++RIn3SdNte/0n1TW2A/4zcK/wsEsybYf9o3HHuiTn Ps3rOOK/iDt2zH8FekKo8JjBBXG1nfZfj/vKJYW2c/5b6i7bBf9dKOqoXB7UxT3mkpL7tFxQ3JIq 0pq42q4NJsE5wj8uqbfdHBwHnwgXuaTBdmdwonqiSzuYDZUHc9XTXamDBbHF4n1ZMo90oWHFYHHs alfGYJm6tytrsFI91jV1sBoj8wfr1IUW2RMM3yXvQOsRPbvgWSypnlhEZ8nwLI8kGblnVSjdkuUZ FmuHZ31knGWqUPQ3RSZa8j1bI9nQHfe0yLM7kmsp9eyLFFgqsJcc93SWWZ6DkWJLredIpMwyx3M8 Umlp9JyMVFuyxPOT9JZlvudM6Jp4WkbqSOe2hD2jgQzLIs/FSJOlxXMlssBY7rkeGLVYPbciiy12 z92IibRDPCcjjjFvBY14LK4+XcQf91kWX19SJGwJ9o2LLLXE+iZGVliW92VHVltW9eVCh/sKImvF MzOygXSzZX1fcWQbtCygtWzqq4zstGztq47sjK8plh19dZE9lt19cyP7Lfv6miKHLAf7FkSOWo70 LQ5V0VNUthzvM6lmy8m+jsiI5UyfI3LKMtrniZw12vr8gVrLxb5wYJblSt9SdVd8hRIaOW9UsRqi 37ci7IuTW9u4vtWRS5brfWsjV42sb0PkhuVW3+bIbcvdvm3hu5aivp2RXKuub0+k2JrUtz/KrOP6 DkW5dWLf0ahize4bUVdacz3D0fT7Z7MW9J2KZlqL+85Gc6xlfeejedbKvkvRQmt139VoibWu70a0 3Dq373a0ytrkZdEa6wIvj9ZbF3uVaIPV5E2Hdngzo+lj6vDmqBesHm9edJ7V7y2MhK1hb0l0oXWp tzxqtK7wVkXN1tXemqjNutZbH3VaN3gbol7x/kZV62ajNxq1bvPOiy6zZnvxzLfu9BqjK+PvnXWP 1xxdY93vtQVXWA95ndF11qNeL3TEq0Y3Wk9h1y3Ws95l4QxjvRcOy3reuwZ6ybsuut161bsxust6 w7sFeruvMrq3nXm3h861c+8ulbcr3r3RA+3p3gPRw+2Z3sOqrT3Heyx6rD3PeyJ6or3Qezp6ur3E PhKqai/3notUtld5L0TPYeRljKzxXoteiB+lvd57M3q5vcF7JzjSPq9fG71m5NYC9Wb7wn45etNY 1Z8amNpu7M+I3mk392cNadtt/VOH5Han1T8kG+f1Y3Vu9/YXDYHl+ksD89vV/oqhjPZo/6yhrPZl /bVDU9tX9s8ZyreU9jeGrgkdKoq7/vY1/fOHStvX9S8aqhD0MjRLUMpQrfgpytCc+DeOfoKxfOwn Ff/67dg/9rMC+snAUGP7xv6WSIFY34fmCw8+tEh8Goda4j8doufDrfYtnmHMTyTWvr3fGjhpye+3 B06O/fSGfq7SvsvuGLJarve7huxx19++t9835BLvdbCJadkkzTXNXxjTfKK5ybSa25pPmU7zmVbD uFbScpaoTdYqLFk7TjuepWgf0E5kados7RQ2XpurfYRN0BZoH2MPaL+t/TablFCf8CLLlOqkF1iW 5JR6Wbb0S+mXLCcVf9lDqVNTv8impjamLmINqYbUIfbl1DdSf8HCqUdSr7AfpV5NvclO4Wy+xHT0 vx+ksjSWyMazeSyZzWct7GVmYq+zRexrbAWLspXsfRZjv2W/Z0fZHzRJ7AONoklhn2nSNA9oNBrx O06y+HeTmkmahRqLJlvTrolpCjVLNas19Zphzbc1r2p+ovmN5ssJ7yS8o/HoXDq3pk8X1IU1/bql utc1ft0bujc0Qd2burc0Id3buu9qorrtuh2ar+p2636mWa77he4XmpW6X+l+rXmDfh9zte6E7n3N m7pzulHNW7qLuj9q1un+rPuzZoPuE93fNN8R/4pOs0maIE3QfF96X7qr2cIlnqc5yafxaZob/DFe rPmEP80rNZ+K3/DQfMaf47VaHa/jX9Ry/jJfpE3lzdykzeZm7tRO5W6uah/nX+UrtE/zlXyddiZ/ m2/WzhG/OaFt4tv5e9pX+HF+XNvDR/hprZOf5We1A3yUj2r9/GN+WTso/j2WNsT/ym9oY/wmv6td qmf6/8Pe1wBHcV3p3p4faYzFWMYKxjJWZBnLsixjLAhRFCITIoSYPxSCCSEKTDQ9fz09o/mH8AjG LGEVwiMywYQQjCkey2plQjAhBCuAMYtlwuoRTDDGPMISzGKCtQqFWZmwmLxzvu4Rg5BjUruv6lUl der7+ur27dP355xzTzczw2DDc7lDcj9leDH33tyHDP8rtzT3M4atuV/MVQ17cxO5Kwzduc/nPm/M y/1h7lrj4NyXcrcY7+H/V9V4b+4vcncah+d25L5mLOLPAxlLc9/KPW4ck3si95yxKvf3uR8aJ1pK LduM0ywf3PGg8XfW/7T+p4m/L6eKFuI8UcTfNp6wVYeFUCFK1ab6K2qgtn7ysdpRakRNqvPqT6sL 1SW1akOrukPdpe6r7VAPqIfUo+oJ9bR6zjHIUaIuc6TVFRNtEwPqanWdulFtV7c6SibWklWZyMYv wsb/Q0jSn6Q/CQNZdL4w0rkH8ElUYXjJ8JKQDD8x/ITObTW8LIyG3YbdwoxPouYYfm34tbDgm2B3 GH5jOCoG4TOoefj06WDD7wy/E1Z87vQuwx8MfyDv4E+WDjFKRqnvfw02G3PEUHxzbJhxqHGouM84 zDhMFOKTovcby4xl4gF8K6zIOM44ThTjO2APGscbvyhK8K2YEfjMxsPU/zxpCGaOWYT2i/mh/aGD ocOhY6GToTOh86Ge0OXQVVWELqs5ap46RB0GFKkj1PJQjzpKHauOUyeo9apLnabOVN2qT1XVuDpX XaAuVpeqreoqda26AWhTt6jb1Q51r9qpdqlH1OPZEp6unlLPqhfUi33Sq14LG8KWLLGGC8KF4WKq Lb1JGsOl1LYiXBmuUq9lJFwTrg3biFkawk3qxXCA2kbCTeFkeF54YXhJeBnpLA2vCK8OrwtvpPFL d6h61ODvrN+NORlGYhTDSUyiVDwizKKCJFc8QWIR1SR3iHEkg0QNyZ2iVkzEp8vtFHX4e5d3ia+J mSJfzCIZQnFHFveIAEmBSIgkvnE5D9+1fAafKP87UUjx6Dlxv/ghyQPixyRF4h/EJvFp8RLJg2IL SYl4heQh8UuSEWI3ycPin8V+6t9BkjL8b9iPiuPiHVEufktSId4leVy8RzJSXBIfUN+viD+KJ8V1 ktGSQcoVY6RBFPuq8fnxz1Psyxfj8PnxGqlIelA8JT0kPSS+hO971lI0bMA3OmeKOukbkltMkpqk JmHHZ8kd+HanU1IlVbikZqlZTJFSUlo0SN+WFompFDuXiBkUPb8rviZ9T1omvi61Sq3iG/h25yyK pDvFbKlD6hAeaa/0mpClTukN4ZN+Jf1KBKR/kbpEEPYboihQJlRLuaVcNOPTeVHLk5ZKEcMn8hKW aku1SFpqLDUihW8SpfH5uzkWt+Wb4lsWj8Uj/get7TnRC9sfy78soWwndBD2EjoJXTqO6DhOOCW+ qnQoe5VOpUs5ohxXTilnlQvKRaWX+FrIELKQWEMFocJQcag0VBGqDFWFakK1IVuoITQ91BhqCgVC kVAyNC+0MLQktCy0IrQ6tC60kaQ9tDW0I7QrtC90IHQodDR0InQ6dC7UHboUuhK6rraoJnWQmq8O VYerJWqZOlIdo1ar40nqVIc6VZ1BMkuVVUWNqml1vrqIZLm6Ul3D/4OouckcpE3wG9ZZ+H2Fif9t 9u0kuQtWng8rvxtWfg+svABW/ilY+VBY+TBYeSGs/H5Y+XBYeRGs/NOw8mJYeQms/CFY+QhY+cOw 8lJY+SOw8kdFF0k5bP0x2HoFbH0kbP0J2Poo2PqTsPXRsPXPkK0bxFjY92dh35+THpCKyO7ZssfB sr8Ay67B9yOegjWPhzV/EdY8Adb8JbLmb5MPPCM9Qz7A35KYBGuuhzXbpB9IPyB/YJt24PsRTliz C9bcIHWRHU+VDkmHxFcsT1ueFtMsMy0zxdOWoCXI39fOX5i/lNYpj+b+TiHFZpHdVRKqCDWEWr3O RmggTCc0cp3pbmVMbGzoyJ8H2hyPH1WqY+OU8bEJoVM3g+uUulh96CzhQvwEQ3HEXKGLfx7cRpka m6bMiM0M9d4A/63MirlD12Ju1RA/rcgxn2r580Aba/ycosRUtSCmKtFYHEjH5qqFhOJ4BOXSeLda Eb+kzI8tUBbFFquVN4C/q+JXlJbYUrXmE1Abv67aEiZleawVWBlbpayJrVUbNHCZx6ZOvwGMdX1s g9oY28BHYFOsTW36ZHA7ZXNsi7Ittl0N3AxlZ6wjozcbyp7YXjVyA8r+WOftIDorvUY5GOtSDseO DIhjseOMqJxez1BOxk7dFs7EzirnYxduQU/sIiOqJJYrl2O9t4NoNL1JuRq7xgiJuAHIiVsY0XR6 Mx+bI6n2kDveFMqLW0ND4gX9EZ2f3hYaFi/8JEQXpXdCR1G8GBgRLw2Vxytuwqh45S0YG6+6CePi NbeNCfHaUH3cdgtc8YbQtPj0WzAz3ngTeNy3ATWZGBTyxQMhNR4ZEHROnZfIVxcmhqJdPJ68LcyN zwstiC+8BaxvCWFZYnhocXzJ7UBdkSgJLY0v60NrfEUf+PxqwrpEGcobEyPV9sSY0Kr4avS3H9St iWqU18bXfRLUHYnx6q5E3U06NsQ33oS2ePst4Gv3JRyhLfGt6oHEVBwPJWYM1J+Pxfb4jlBHfNct 2BvfF+qMH7gFXfFD2VCPJmZlYnt2LM7Eyr4YdyIh98Wg0wklO4702Un2umbWJTNH5xLRvrntTqSz +4RY0kIxhXw/ulyLAdGVmv/Cr9bEC7FvkL1H1xM2pfdk7Dm6mY50Hz6vXkrMV68kFqnXEy1hU2I5 7y/hQYmVXM9jC+cn1oSHJtZzfA0PT2ziOBkuSWwOlyW28R4QHpnYybEdYyZ7D49J7MnE53B1Yn94 fOIgjztclzjMcxF2JI5x7GSdwNTEyfCMxJnwrMT5sJzoCSuJy+Fo4mo4nRQ8v9iDeC5pDsPzaZ/U 97PwItp/9HkOt5Ce5ckc1oFzK5N54TXJIbzv9O21WWvUp5Oh7ymZvYD7xHtjeH1yGPq2KVmUWWe0 59hPa499mfY8jG1zcgTXhbfRHl6tgfdrnt+b4ND2Zd6vsB/TfTJ7MR8Bsh+Mrd8ei3sRwjtjCxi8 x2b21QzCe2KtjL49kvdMfW/M3itv2iP1fTKD8H7aB2mNsffRfhg+GOtgwG55n9ujoS9mEcKHk+U4 HkuOCp9MjkU9xY/wmeS48PnkhHBPsj58OelCPfsw7yXst+RH7E/hq8lpEZGcybEokpN0wy8yfqDH RdgW6eE4F8mj2KT7CNaL4hZfn4mBt/hWP7/qiy+Z/pMOjpuRIUkfr3lkWFLtu57bk79FipLxyIjk XO53pDy5IDIquRgxnMdDY4iMTS6NjEu24rpPij96vyIT9Die8fElWW30PmOs/eJx33g4Dmfwcff6 mHgaqdePrvhWHlMf+sfJ7FjJ8TETI7NjIrWFHm7D52gOItMSjui29P7ozvRBBuc2vN7Ia/akD6OO YlbkSMoa3Z8+lslfogfTJyOLk3sRxyjviB5On0FOQTEtsiV5IbIg2ZHJCaLH0ucR03j/57yBY93J dA/v0dEz6cvR8+mrkb3Ja9GeOSJ6eU5O9OqcvJiYMySWM2dYLG9OEXIyPV7iWs7N9LwJOU8mR2Fd ug4+FxsyZwTHS+5XX26XycMu34jBQCaH0XMP1sX5WGzYnHLOd2JFc0Zlrkd7Gg/+pvmCn9DYYiPm jEUd540Z6HniTeifC+q5303Q57V/XtcHzsUy6J/XZXK0AXKzWLmGT8zNOPfKzr8458rkXVk5FvcV 13IbfU5u8S3yv8jM5Kpb/MqdXJvJsSK+5IaImmzjWJRpF4knt7BdR+Ymt8OeMnGA27DPkf3huDTZ GWlNdqG8KnkksjZ5nJHtb5ENyVMcIyJtybOwz+3Ji7fkMYRIR7IXIHtkwA85bnWmDDh2pSwZH2Sf iBxPFUROpQr7/I9j0NlUMWLNhVRp5GKqItKbquS9JwMeLz9jwf9ozJFrqapmQ6oGuil+NFtStRin 3r7ZmrI1F6QamgtT05uLU40ci5pLU03NFalAc2Uq0lyVSvL+hz2Q4xPlBM01qXnNtamFHI+bbakl eGahvbC5IbWseXpqRXNjajXPV3NTal1zILWRnxOak6mtPE/N81I7uH3zwtSu5iWpfc3LUgc4B+T4 n4nNzStSh5pXp44CpI/3Gbbt5nWpEzzvzRtTp5vbU+fYzpq3proRw2gdm3ekLuHcrtQV6NiXus6x vPlA2tR8KD2o+Wg6v/lEemjz6fTw5nPpkubudFnzpfRInt/mK+kxiGM8/uvpaj5GTenxbA/RQem6 aH7aER2anhodnp7RZz+Ug3P+ES1Jz4qWpeXoyLSCej3mRseko9HqdBrrR34SHZ+eH61LL4o60i19 tpp5DsjsUVSOTk0v5zbRGemVXCcMQrIusbYK8bd/Qfkr+heUbnHpxr8DyL1C9RZ6i72l3gpvpbfK WzPN5K312rwNxNO9jXKvJt5ihrfJG5CvaeKNeJPeed6F3iXeZd4V3tXedd6N3nbv1mnLvTu8u6bt 8e7zHvAe8lp1WQEc9Z7wFuhy2nvO2+295L3ive4z+Qb58n1DfcN9Jb4y30jfGF+1b7yvzmvICLVw +Kb6ZvhmeS2a+GSf4otSuzR6yD3ilnyO70d34Pf8g9vJtif/t7wHdZJvTCG5G+9Bh+A96D14D/op vAcdKgJCEfcKlaQQb0Pvx9vQB/A29NN4G1qMt6EP4m3oQ3gbOgJvQx/G29BH8Da0DG9DH8Xb0HK8 DX0Mb0MryOe6xEhxiORJvA2txNvQ0Xgb+hm8DR0r3hO/F58V75NU453o5/FO9At4J/oU3omOxzvR L+Kd6JekIqlI1OKd6ES8E63DO9FJeCdaj3eik/FO1IZ3ona8E3VI35aeES7pWelZ8WW8E52Kd6Jf wTvRp/E2dDp5+i/EV6VXpFfETLwT/TreiX4D70Rnm5aavifc+KXBJtNO0ytCJr/uFD7TedPvRYD8 t5fmUhJzxYIbtuqhEXuOeU56znjOe3pILnuu0sTnyHnyEHmYXATxyaocl+fKC0gWy0vlVnmVvFbe ILfJWyAj5HJ5lDxWHgeZAK6XXcTT5Jmym4XtxvAY2c3jut0Mwf3ZYgy0Ro+Q9bCtmGj+K8l62FZy YCu5ZCkTyYb4nfkdZB0zyYbYPu6EfeThPflgGleILImtIZ9s4TmyJ7aDIWQFm8ie2AIKxMskn4IF DIUF3Evrv5/slt+H30dr/g5ZGK/6/Vj14XgH/gCt/AVRhDUulvJpjR/E6pZgXR/Cio6QZktu8TBW 9BFa0agok9K0ouV4y/2YtIxWsQKr+DhWcSTeaT8h/ULaKUYJyTLWMi5rPcpNd3vK+4s8T17oGeUZ mxG51DNOlwn9RV7iqfe4NJGXeaZ5pskrqKafyKvldZ6ZJG4SH4u8EUfVE8+I3O6Ze6vIW6FhrmeB Los1kXd4lnqWyruIW28VeZ9nlWdtn2zgtrq06bKlvwS3BLd7tns6MuK76NmrS2d/CXZ4ujL3Cu71 HCHZQDX9xDvG0+s5TsL3O8USKJOtdDyLKyDenlu1ezoDddDQmZlZzwVNgp2ei56LwTbi3lsl2EXj u9YnLtnQJxZNBpipA/Ih2SoX9MlRuRBy4sZMZEQ+LRfLpRnBip+TK/pJN+GSXAmpIrmi11/3mohr +kbk8izwDpJrbxVvvmzzDpUb5Oks3uFyoybeEjlCNU1yk7dMbsrS0yfekZ4LcqBPInIyI9rse07R ipB9e6thu/Xe8d46tjGvg2fCO5XtwzuDSrMw2gqv7FXQIwVj1TSxpRzBKnUFjwdPwRrOYvYvYKa7 vVHynVE0f2M947xpT5t3Ps2y1buI+tfiXU627PauJHuf610jG7zryZZbm1q8m+Qquu9yspPF1Haz d5t3p+ead493v/cg9Zjtv9V7GKN004od8Cz2HqMWLu9J7xnSxV6LEaGl5iu8uos907znqf89NObL VL+U2o0lr1vqvUqlUd5ZPuEZ58vx5fmG+Ib5inwj4MvTNPGV+0axv/rG+saRTPDVk7eqmsf6XL5p uBvdyTfTs9jnZp/0kWZqqfrivrm+Bb7FnlW+pbr/sQe2+Vp9KtmaFfZWSGdXyTa5yrdWLvRt8LX5 tsiNvu20vrRa3uW+Dt9eXyfNXIVcS31aJR/ydfmOUOvjJKfkSl8HLJBHibXidiRkMTxLvrOEC3It +XCrr5fqk75rfoPvlN/ip3v7C/yF/mJ/qb+C5lrxV7K9+6v8Nf5av83fwDZOM4s190/3lpG1Vfkb faq/iSTgj8g1LHQu6a/0z6MR2OTpdGah3OhfwnZK3ORf5l/hX+1f5xvh3+i54G+XA/6tZI8RHpt/ h38X3bOJLDTJ4wte9GwP9gZkigx7g9dofU7ReGrJXloVg2KhKNCmWClSdPpW+buVAs8wT0fTQX+D UqgUs1+TzdBsKaVKhVLpa1OqlBqyUI4cvRTNeHbagh3BDq2FpzVwWKklXRzvYMFoqUUZsmDSdUSx eVYpDZ4tynRPp2ygdh3Un4tKI5W2+xuVJs9eb7W/MlCtBJSIkkQU1COZMi+IyOqvCh4JHlEWKkso zp3VYp2yTFmBu9GdlNWeC8o6jmbEF5V1ykalXdkaGKpQRPc3apELscsSvKDsUpbJjco+7ol/H60T 206j/4D/ENuPJt7l1O9O/1GOSf4TtMan5QZanXNkVxUUDyr83TTXG/2X5Br/Ff91jytgClDc8ZwN 5AeGNh1sOhgYTiu4kezmomduoCRQFhgZGBOoDoyXm3yneN492+WqQF3A4bkYmBqY4TsbmEXes5QC jCJH6P6naH88FxhPHmylmNVEZ6KBdGC+XBhYFGgJLA+s9CyQLYE1gfWBTZ4jgc2BbYGdsjWwh7Ra A/sDBz3HSfOpwGHqk5X6cixwMnAmcD7QE7hMfewi3RbPRWp5NSiCOZ6lwTyKNkPIl1xkN8Pomgqy lapgEdlvd3CEZ0ugzN/t7/Yu95/2nPIdCZYHRwVH0DwYgmOD44ITfF3B+qArOC04M+gO+oL1so2O qq83GA/OpdYLAsv9h4KLg0vlZLA1uCq4NrghsDzY5pWRTT3+tyfMv6InzICI4lMNQ/l/k3G3Cemb BlHg3kjSTrKVZAfJLveumSTufe59s4/PPu4+QHLIfQh1R0lOkHDdaZJzJHTdjJ4ZPe5ukktufoY1 WF3WKXSPfDzRCDzRGPAsY0TOa8KzjBlPMTnIeXPxFGPBU8wdeHK5E08uech5rch570LOm49nlrvx tHKPkPLl/AjGhM8duscIye2gYzUdp5rurt/krrsd2Gx03EzY9jHYqcHWqKF+z21iP+HgADiswZak 47Hbg20hHU/qOKPjvIbJp7SjbTVhHZV7CJdvha2djlc/GbYdhF2kV+jIIeTdDIytHyYP6YdhfwGK CCMGQPkAehmj+mHs7cFF8z55HGHCx6Beg+uYhsmu28Q0wswB4NbgonWb7Ls9uGhtJ6s64jrmanCd 147O03Q8QlhAWHwrXGQDk5d+MlyXdR2tOlYR1vbDhgHQ1g9b/gJsJ3QMgL2EzgHQ1Q9Hbg+2c3Q8 7oZ/DAg6Z+smXNLbnb1NXCBcHADHdZ3X6dh7e7Cb6HjtBmyGG+hrk68fhxKG0znLjXtlw16i39/6 ybCXEUbefL2toB8KBwBfO4aOxXSs1o/jB+7Px8FWSqgYAJWEqgFQczPsdVnxOzveZuKlHsfsDndf fLFPdd8cPzJ2kr2u+nz3zdGMrLmddXOf+mJKdgzI+LDuW7xnZGx+yrB+Nt2rnbfLBIUQ1WIE7y/2 +Vo9j8m+iNCixVc3rxfFSftKwhptD7Cv1+P7Vc3e7TQnmfhspz3Nvk0br32nPg+kk+Ml6wRYL62n neKinebOTn2ws97z+vzq88nXYp/M7GFnsuaZ9DiEpoPPOWi/cOTp/eq/Tv3WqG9PyaxTi7Y3OoZo fXMMy7r+qjYW/L1N3/vob0eRXrc5CzsHQP99+fAAOJa1v2btsX3oyUK//bVvv/yv7JNF7pv3wnL3 jT0wa7/ri1kExwT9SPuWw6X7GMUPB+1JDtqDHLT/OHx6Pfkw7x/w2zrNnxy0zzjiWixyzNX9QveD TFxk22I9HOcQnzI+0qLFLb6+Lwb2961+fpWJL32+1aL3f7G+5ktvXI/25G8O2pscq7R+O2hPcvAe dEqPSTwG2oMcW/TrPikG9Y/jA7XJ9HmAeNx3znIDHxvrPimeFt+MW+JkdqyszIqRWfEQbYv1NlXa HHCMnkL2M6VcA+c2vN6c00wZpdeRrThrqcxxTM9fplBu5OjV4xit6RS2rcVaPHPy3PN86TnBlHo9 lvH+v0qPc2x/tEdPIX1TSJ+T+juF7GYK6ZtCdjaFdZKNTVmgx89MvNyi52aZvCl+I45Cl64DfVys xUv0q38c7heD+3KYTBzmcbIuPkc2NaU16/ql+njGavOFnIvGNmWVXjcuC/UDoH8u6B4A+rz2z+v6 sCAL/fO6TI72X8nNtrtvzr/2um/kXdk5llu/tiNrTvr7Fvmfo8t9i185jrj7ciwH+/UpLRb1xauz ml07Luj2lKnnNr26/fGR4opT9zsn+ZjTqiHb35wFWoxwFmr26SwdII8hOCt0VGpAHGT9Vfqx5oYP sk84aa9zNmT5H7VzTtf8zUl7tLOJEND2ngwQj9q1eeIxOyOEpK6bxuGcp49Tb++kZzrnEsIywgo3 YpFzNYGe4ZwbCe3a/sdAnKScwLmVsEOLx85dmp3yXujcRzhAOKTP11HCCe05wXlOmydnt9beSXuH 8wrhupYDcvzPxGYX7QGuQRpYH/YZsm1XvjbvLspBXcM1O3OVaPPI6+gq08+N1HWM0WK5i3JEF+WH Lo49lI+5KA9zUV7lonzKJWvz61L0OEbjd0X1Y1qzBxflQi7KgVy0R7iW37Afjt2cD7goF3JRLuRa r9frMddF+YBrs6af/cRFc+SiHMC1J8tWM88BmT2Kyq79WhvXQa2OP40xeN/g1//2aYy/pndlpnLT fv4XVcNB8VMhcosJpYQKQiWhilCTdawl2AgNhOmERkITIUCIEJKEeYSFhCWEZYQVhNWEdYSNhHYd Wwk7CLsI+wgHCIcIRwknCKcJ5/R7dn/M8RLhig5uf10Ii0mrtwwi5Ot969aPNAbLUMJwQolW33cs I4zU+moZc2PMlmrCeEIdwaHpsUzV7meZQZhFkPV6hRAlpDW9lvmERYQWwnLCSsIawnrCJsJm/bgt 65hpv5OwRz+u16/bk3V+P+Eg4TDhGOEk4cyNI8+P5Tyh5y84ZubisjaPfymwBtlo0MD6sV6n9bbn ++Gq9t/OZ46Z6zN678gh5OnrTfV3DLlxvGMYoUj81F5vd9mn2Wfa3XYfoNrj9rn2BfbF9qX2Vvsq +1r7BnubfYt9u73Dvtfeae+yHyE5bj9lP2u/YL9o77VfcxgcFofVUeAoBIodpfi7gqTSUUWocdQ6 bI4Gx3R7q6PR3uZocgQcESDpmOdY6FjiWOZY4VjtWOfY6Gh3bKW/dzh2OfY5DjgOOY46TjhOO845 uh2XHFcc150m5yBnvnOoc7izxFnmHOkc46x2jnfWOR18nuqnOmc4Zzllp+KMOtPO+c5FQItzuXPl gFjjXO/cZFedm3XZRjJQeSfJHud+50EqH9blmPMkcIbkPEmP87Lzqku4coA81xDaE+4b8BcXhP6L Cxb84sIg/OJCHn5xwYpfXMjHLy4MwS8uFOAXF4biFxfuxW8t3Gcttj4p7reOttaKx60ea0A8ZVWt MTHRmrR+S9itC6zPiC9bF1u/I75ifc76S/G0dbd1j1hoPWB9XyzCry9s+v+4Z5I0RIri8yod/L/J l1TqoMhSUqOjVoctq8wgrymZrpe5XaNebtIR0EFRt4SibglF3RKKuiVL9LbL9PZctyLr79X6cZ2O jVn3bNf/3ioesx0kOWw7ZjtpO0NyHnzG1kNy2XbVLuw59jxNbAftQ+zD7EX2EVRbTvVF9lH2sbYz 9nH2CeST8ErbZfJLl91Na3UXfmlD4Dc2DPiNDaO10lopTNaJ1jphtk62OkUufm8jzzrb2kTrELSG xAPWuDUhiq3zrN8WJdZF1r8TpdZd1l2izPqq9VXxqLXb2i3K/x9rl65/3fQl4plkHdL1O1EehPKT KD+J8mhTPfEYcxL1Taj/IcrLiCvNL6Ncj7J27ZMoN+DaJ4hHon6MKQI9fG0l9DeaRjObv86ffTLP o3KBaQKzOUW8DW1e5Pt+hPJHu9GHRagPoTwa5dEoj9F6q/M8cAxtSOdHvzM9RnxaH9FjOPt19Aoj NX0O4wqi5wEuG4+jbMFZgav+CTVhXGtHzV0oP4Vr50DbXejJU2Az2oxFGx/xKJRHoVxpqka9gvJY aEA9eDTOVuLsZ02fZzaH0JNqtOTyaOMltNHmYRm07YI2XosnTG2o17gKPBVtZOjcAZ00G4Yv8x0N j5vdxN8xk3cb0ig/BT5ujhMv4DaSAfw82qOfBsFs9KHl82YP8SbovJtrpLe5LH2As8+h/US0/z7K BdD2Afg02l81/QvVG0yvE081HeW7cFn6A2p8preJx3Eb0css2cB/BO9mNhrRcjL0PM3tpXehoQ3l n+DsJLT/E9qXo3wOvA/8c7R/39RMLR3mf6byFbZbQ475VSpf53qpyXyQ+IyJLMFQyG3E++Znif+D WTqn1xAbK6GnEDwc13rBz4HvNf0JZ79J5V8zG06ivAt8GPy8qZHXKOd98A5wO7gF3MOcO4zuNUZb QbT8Tg7/hkoTyk+BB+vcDm4B87X3ouV+nN2KmuOoWYCa9dq6c5l4B7gd3ALuAXP7yWg5H1cJjc0/ YqtA+Xn0fBPKHeBNek07uAXcA66lsew1t8CKAsy4+9vgD3DtczrvALeDW8Cs4TnMxve5jXE1+Pvo 8wfg09BzmvssvW/uIr4Mft/8AjgKng2GJZi7ScO9WK8raHkafEHnZ2ED+9g2UHMdGq5Dw3VouA6r OIOzZ1BzRq/pIDZiLA+a98NmusBR8Gzwm8ywhNOajXGZLI21vYny+5TTcx+oxlCtM43F8AZbqWE4 aoajZji8ezhrJn4d3AHL3ExjnKfZJzS3gp/Tr2W/SMDm7+X/iZvu9QI4Cp4Nfh3cDWadJ3HtSczG YWg7jPLzKL+oM8/eQfTzy7msbbDGmqWhvElj8y+xslGsI5/9AOX3c77AM6wx90qghp5pmQtRfxgr exg12+AjpeBiRKEnEd++k1NG/Azq30MsuozyCt5BpH9DTBusxUNuKQ0y+4nvQTRbDL4Xs7EFbSrg C2+h/GVwmx4DaX+RoN+Qy5zzJq9+zvd4NsyIpSY3z0nOTi7nVHDZeB623QY7qYT1duGqneZtfK1p C3rFZxUtnudw5HyMmXzzKHzqKPyIveNhlJ/D2X/Tx5hAf3y49iW0fwnzjAhjPs/zw0yxmllbr8dz aH80pNF+MMr70X6BHj3aEQdaeHeAD/pQ/zz4bvDDuMvb4D/l1vNq5m7GffnsRF5l8lwuF+jMOj+j x+R1VB4Gm3wTNcXgEzn38/oi3r4Ie/4q4vZ2jqLmI7DJw9zSXAbbs3ANrR3bcAHHc6lL82J6VqYd AetyhGeY4kAHbKwDXqnx6/CXDvDr2EE4VhfytTSfr+KqZ+FBz8IO+S4p7pVxMp81TtaiiolyFekB +PgEXLUz50PEB25fxb0lS+aac+zpZOFv8c6Cnlfq8edZtOS7bAQ/B96X8wiXc/4nPHcK7zLw3JM4 u0tnzUO5PC3nMZztRk03+s8zPDbnTY516O0LvBtK/xt7YiF6+xHqX8acP4ByMcZyhjMlQ4OJ9R8y WYnPc/ZouI+Z1utZRBVetTUY4zr2NeOT2AcfZTYWm6jG8Cto/jFafgDN/4ryv6I8Cfq7eOaJWbMN fY4wi60oXwB/1TxIcF7B+j+PlSqHhkPa/st5FOUJ30T0YwtfiuzlgknBKNjeHsLZNej5m7jXbmgr 5JGafsOzYcacmD7E+qZ5fzcOZW3Gt7hs+jzKdRhvD0bxIWLFh/DEQvQT0d6wi3toHIOx36H3lntS gnKFiXJX6Q2M+hcmygal8ejbAVwLazdUm1T2cVw1jXNgwzTjvxOvNE0kzTVYx+0mme3T8GMqH4W2 93RmbS9Cz2egs9JkIn6XmazuAcFZGc2AMRfz8I+4Kg5uhQ2cN/HsbYGGMvAPoceFcgpjfwHzPAFj VHDVe+CT4CDPGGVZPIpFnLVS+Q62CuxBYWhrQj+nQU+OeRVHAN0aeXS/RH+u5oxgNn8Afgu8G/Ul YBvHBC3n5JaGUeBq89vYR7hcp2Wh0PMm+A3oeQN63oCe/4P2PrT3cY0hippxqHFpWSuXRS/3hPgt 8G7Ul6DM7QdrmS3usltj5FGToWcyX2t4GuWntTLrId6N+hLwA6gZDvtBvgGd70LbZXAb+CfgzSbe ASdB5yTonASdk6BzEnROwixNYs3Gcm5pLMcM7IOGfSj/HOWf8yhoVteh/8w/08bLZerbOuhZh6s+ gAauqUI/P9T5IDyL+zDV/AS8lVfnWRNnm3v1pwO+y+umY/BZPB1wS6Fl8meR29+Hp4B68K+g7T7o 7wUfA2/GtTPAdbh2J+rfA3eZyEpzSnhcOe3MJoXbmA6ZXyFPx71y4mbepxoxV1HMwB/R3sqzmtMO v34SvX0TdvIuuFV/Tnkbq9MJm3wbq/Y2Zgb2yV5GM1DKK2W+l3gtnokMaFmElm+ivBh3H6fZG9bi n7jGaMRKGVE/Ge3fBX8IbgN3IpNvyzmHu3DNn3hdaH25fE5nrDXKOzXL4RqyBBtW0IYVp+dosdj4 G3qudJnvZM6h59aPfs2e+NGvzbTKxh8jUzrIc2L6HO87Ji+XjS+Df4D6Ns7HTC8iKqI95cacF30a 19qRF4XQ8jV+3jS9wVHaiOdH49P8vGzKx9mf4ap/YM69H/VDoeEaeDPau2EnC3gtjD/nuTWeQnkS eDSzqZjXyFQC22hB+1dhUe8wmzeizWhYRSG3NH4XK/vvKCs4+yjODoO11EKD9qy6GVyPez2FrOBF 7IB1PGPGd7GDtCA27seu0cn5iXE9MtLl2IM2ID+cj5rvIKvpgZ494KPgt8DvQM9Z8CHwHOxN72Cf 3clsfg3lBeBXEF17sQf9PedvpseQxb2jl3eA28Et4B4+y09e5guY/8lomQf+XM7XiLUnMjwhGl/R uR3cAmYNL6PlXFz1c64h5poGrjHPglU0ItedA7aDo8gM48g/6/BMigzWVAr7+SXuhZbGFo6lJtQQ 8yjOQ/PDOu8At4NbwKTN/Cg/k+a8Cpt5wzyUrroT2taDPWA8n5oKMPZvobxD5x3gdnALzvK4vsVz ZdrN5dwHcn4EnsH6cZVJZ54fPCMYN/M8GJ9C1jdf5xfAUfBsMGyJM7ecQVj3b6BlHcdG88PmN6j8 B/NrxD9C/TGdo+DZ4NfBT7C94WwnajpR813OdY0/ZQ+Vvo1cugj8BfAc5JbFeA76HHLXCmTFy2FR c2CxyzkPNNRB889Q/haeXrejb79F/W9Zj8mO/p/iGtP9Or8AjoJng9m/HuFemT7Nz7A5/6jZPHuE 4Sy03QlejwxhIfyoAPlDDPa/Fmff0fkFcBQ8G/w62tB8mh7ku5hf4/eKxNzmFVz1CsoFmIFezNIJ czt8oYjPaown1nP8xGo6zzXm3dwT0w6U/4CyCXZiQvv55v/L3rmH61StDX/MMeZ81sEyiEUsshc5 H5djSE6RY0KUpNqOSYvEskg2knJIRVFySlLJqZIOjklOSUhCKtuWVJTjIls86x33b879vfF2fbv9 7f3f916u6zfveY973HOMe9xjzDnm86zHMUYhpOxed8ju1UVDsmK7P5q2ScYq5BW0fAWl4SraEOYJ Uh2VjFdQNNbByfNEH5Qkk7+BD0Vrqaw8q1lLp2AzEfvXmXE/M4/ysKLWZQWegbxKVmCXV65WsI5x 2YRPdq/mGTz3x1sl5Hdl/+t2uFI6EMvVwsQ1kuGJit3W83jmnUlCuNp/wu5mPDP0KDPoHWZHbcju 2CzBw2t4U/5jrtZq/LwnbfN5T+WzI3ZjIffQ3uyFB4vsPByHu5nXx+FuZutxuJvWvu3kJ7ni+0Tp ojwDmJmsTpuhT9tWyR7ZfxlmCQ1vTszW2ONyv2MWT0F+B/sXqfskM328aGJ9ZTWI3Y/+Q+wPws5w buycMKGr3OmweUUyJ6EYcmFYE28XsZ9Km5Pl7uAXkPdUfrUgjfwRWUvbgp9k9P0CzJ0R4X6TfFgc bJE8Eb3/bbSnljeWC9nj1GNet5B7REJLxu4LRup6kWPJQV5Xep571grZEbvslTWhmZQmtOTOMldm k1uvVsKNrEsrodxDW/MeqRL6A+gPoD+B/jD6L9F3w9s3XCXceY3gzrgbrpDrBgelRzHex5pl7Ljn cY+bLvb6I9lfu1XuHiL8C22Wdame7LVjeZn1x5nda4UukttYZ6rREuF2SvPwXJRHnnzceniJuTCb FUNKR8Lx0eohtfaybnwg+25nMwP9DNrPehUb5eR3aXNzv5jjS0I/nfi/SU+/YnSysbk9shRNCfZB H0sf/atkj2x4q2zCXds+dm1bWJMfJg7FGfcq7MteIFuKBG4tiiVS6xeeEN6Q/XjQz3c7C/8p1tgB 1B1A3UnIC+Ra+jqu2INxeZFdfy96NI4d7m5mhI/mSdmV+5Vo553Yn+SKtCoYizxC9ubmAeTQpj8e 6sC75HnJPTfKrFzhXy33BVr4PXke7qabkAkt6Hs1s9r1q6v4iWXB4UJ/rr+ElVNmxI0iB8OCYbRK 4tkJm/DzjjWsZoGUmsFyFws8/OQn/ito4Suy7zb7kU/Ibt1UR24hu3WziL7kk5YEzCD/dr+o08yh /aPNCcdRxmWCf1Q+5Ym9zDNhd9mtu95Je4rJnt1MxOfgiBLDvPB22acHK+Adso8wv0rfY4WJQGv2 4Ieo9WfZp5tCyGspzaE9P9LCZehP8VlGukQmVp6rN4T30N9MWCd6tpS7alFqbZOdu/5cdu5mHPEp yvvDg7SwO2zN6ExgHNvIqLnsddRL0BSnnTPYxUyBjUKZHcoU5toUdjpTZFflSt1OJCjHE/U6LB+F 7wSPsR6KbGGbkHhog4c2eGiB5XH2epVE41dCsxfNDN+NuEddXRo+zn75VvbLt7ILq8f+7gXZK7lM cPa6L5ZfcsXCPH9WwVsVqes3Q34kJJpHxJvjGvSl4DXc2V1kgs/oXT/f7QrNLHzWw3/Yu4bwYdl7 uvbTC3xWwmclenqcnh6XWPm3i+dYs2AXfFSyCA9vhiQ+PZBbEodGsbbESngL+/f9sn93vWgr7778 z7huW2bQV3g4g7e2creSVrmVRzjTL+N4tz/G6YexorJfdvtrKZ0Ai6Np6I918kBf2lYFDeutfw1j 8TM8JTRbhcF2oV8FPiJ1g6pcpRA+W8H6cD7exoexwsMJWJ4IPwT7y4qXsFkikNiOeJ5n33c/b+n7 i5wQ467XXUqDckR4K5bNkHuLnLBZvCW2kyeTIM5+sB79CnOjLqPcjHGZhZyKhwbYLJL3A+bPEn8/ jVF4k9woKXcxc0R6Z5Yg50ceic0BWIVapWAqo1lY6gbzZMSD+ehrYvkaozxBZP0zmnqxOnCq5BuW RWU0XZ48xhoo3InPxchlaHMqMXxY9M7yPK09zwzlk/rc15WnTO7HyEvks2xYI/c15ApwvHxKHpW+ DudhPxw5ZBE4BX1YdynyUrwtht+g+QZ5HzZOrzvkyhvRKvAxmA0bwX1wpNDTQpWDpgZUQtMHeRp8 FV4VyfKpwV7qnkEzBTan1tPIqZQehBfQcBXdEc0J5NB/A65+Dn5J6d/hGrwZbFrBzui/jWRpwwI0 S9C0QM6lVkXkI3A9fAcew7It8nnkGHIcFoGH4hXlyZD2YK/OisaEkSkO00Tj0WvvdrgD/dfIq+FO bMLodYg3cR5qhWMhsm4E58C54Sgg14AKToOvxuXpdF0Yf9F4b8AzlH6K5+lh75CvDiOPTRybkmFf 0BykVUeQP4v60oR+Jbq6w6k7QjSK+HijsKwRb0cvZtDyGbR2Bm0TTkFzBh5DU1KoQrk4TIOHuWJZ mA6rw++5VpiBzyB/B9PiTR07IRdkZMeGOSl6vRS5clx2318g10dPVugEYYxMiw0V+ivwcEkiEOsv crCVsX41jEzuTPm0EfsnwtzA2zO04Rds/k6sOsisdHOqCPkvnByO8qXTMuPoaXZEDdMdr4aN4EhK R+JtpGhcPEV/E/oaUEVMl/sC8rSIYtmOaO+NIp/OKMyBIjcXvXma0hxq1aaFYYbn0CPi7+0PR4Se vhjmM3IvbJYTpV3h6iGx8ncTsXD+piIXJzLrsV8fbyxvpZCz8TMEebbQMItNKzLwPHGbQimj6V2D /pjE0LtIm2NEL40eJRKluNDlVShLH4mV9wQM87B7xHTqzsGP2O/A5y5KX4fEU52k10fhbPhpbkHH S/QxGc1byNcgpzNq7ZG30/IfKC0qslsxFjhNY0oHwxmUziECZLupjhzO9DSJmK6APpwRH8OZeO6N h9543hNFSeRwZdvGvN7AbP2eUWBV8Xwifz1+wpVwO/wxt6ZEEnlruAZiORHLa8M1kKt8hp7Z549m 7mxG/iW3hWtneB+Zx2rzhcTKvx75JvTH8fMLMiuhToKVYKlwzmKzGb4XrU61HblTeFuwWR7OaMgK oKcSpYbY7IbhukHeau4LLqpuT2GY+95rcBAM14ry8Hk4BH0WclPYjwx8CP3r0b1A8nlMJEsEwntH N+xZQ3SP8J7CaMaIfxE4Be6AqyHrufcW45WLvApeoO7OcLyQiaR3ArkPbEeUziHnpXQNcivYOX5O Woj+W3xOhkvg4mj+hteSzN9M5p9jRnSGLdCvR66L/SN4477jbeTqcXKDO6PHSm6KYrmGbEH2zrEa 70FejL4LcriuMvqxhWRUfvgoKwzPJ7ESeAtXpM609p3cWfIZEx5y40/QX0dvE7zAOtyRlWQJvBvL C6zDKfQlvE+lRutqOrktK0MDNA2IXgNWlXPo8xKHNRFl7TVYtoooHhZQuiRiOvedTGKYTjtlXUqn dBt8h7rteceYwzv84rxpLB5721mmRN+ukW+n1OU7OZd4t1xBvuXo7RDqhXz+u5G9J2+ovO98+WbO OnZkfNqim8XyyEznE5ztIusPkU/7+9ir8pmXPJ+rrrqsjIu8kTAV/fvk6v7L8owhsj7un5JsFJrT /qtK3i85S/W10OtLrZbCYCHvNGKwqj9C5iYeFvjuudd0w8NFKY11olZHWIvvJ5yHiX6ajLh5WCJm NoiNyHq0/IWLzhSageYA3pyl2iL0SoW10OwS+j8JXS+E88yT0gv8NJO3CnpT6IfSLsJgDB7OwwNw Ilxm5H1ORaFebWR3ny77en0eTYGgK+2Ub5GliEbtEll9LXT2Im8R+6ABftKplWHk+3tlzXQZfTOP ti2Wd9rUWgbroykv9sFaah2OWiKlXdDMMcNltUHfMKJ8j8iPvM2TKNG2d0X2DtIeoz1hkCO/eoOs tRaNt5ZS+QZyTe8Q35iVb7W11xMdq8hbF71aPy2rrh4nLdevyLwWWT+uH3ccqeXTbS323hTYUWju x2aa5ruOerJjNTPB8S3kyuY1/DjZO4MldXVz6j6NXBBvZyRLvb9y9Qu6oMxlLVnRRRehnfkl/zWf 8uuY0zTR+WQu63Iyl8Xeawc7CNVZoTF4aIm3zrqorJl6Bz5FPqe/lbsG8mIs2+IhTt0/IR+BH3oS 4eW04ah3rbOs6skbTrcuOs1FTz5lvuTlyL1AZ8i6qkfzqb38suwx76C0R+g10YVFo9+XO5f3ndxz YXFYVei8OapvkSfDAt4BLA/ITEf+2hsudxN87vDmO071vpL7kbREfY+Hs9ISfVEp+Ra6f1IYS0X+ G3Jevp2eB/k69G+gcX78l2LOp98VNoM/Cc0PcIkwSEF/Uah9+CSa8tjcJYztxbIibEtpKeQeyF2w PIIGvT9RmFACuRylH8AcNFzFfILcG3k0bI9mDBwm9Gitbkjpx8gHaU8MmylwIaUbkd9C/hneAu9A T4/MJeqG3rbBR+F98AssayHTL/MrV3wQeQPt2QOPonkZb72oVRfLrehLIi9Fnk1M3kceCl+EFaj1 UoK7+8SKhaMjsv8TzA3HSOQgBc1F5MbhGKF5Jhwpkc1dsAcciLe7w/GiVkI4asjEJHYiHDXsl8Aj lJYSJpRA8wFtq4blJNgvjA9Xv5EWrgtjIhp3TxQ5jBhx9ufBBlyRaHunKCWSejUeyLpgKtyE/Vy4 C94M6bUfZtps2jkS+zJ4IOaBpQ3kjy5L7iVhfxibRciNsAxzrCm0wsRFUjexEO002LTAw3swFX0x el2eyGzFfhqlzBF/N7VKcy1ia6aG844Y7qUusfUnwnL4eRubDPwTT92EusvRM8uCMFf7cq1wJpYI cw8/nyJjqSdQ6xg2z8IwQ4ieGRRmMtctSayWCr1TaGZyrTAPa8PrYQfq7kSuiYca8Hv4d/SPc62e yLfih34FXD2og+VT+JmOTOQ164M/H2bDztiEV/wchhmyitL7IeNiinLFByCRT0Djn+GKw9GHaxpz 0A9nNzM3yIemAGRlMGSFwZsOVypWFX0Se+r6WfB1uAB9uDYimx1oNiMf4OrklWHu6NPUIuuCcDaF PVqDTTL2s9CE474WfUeYBmmzYc2Mjcdn2Cqywv8KMqd8csOj5bFR1HoY+wvIzER/BNyHnjE1xD/o hp41ymfV8skHzaru94Ersc8hZ0aTP+F6tRCyFgXMI/MomnDlPE7dcEwZd8NIxcglcydkrpnJkOxN 2C5MJCsC7l8B2R4j2gn0PUapj71hjTL14C1ydaVkD+K/FJdPi7rCZvAnofkBLhEGKegvCrUPn0RT Hpu7hLG9WFaEbSkthdwDuQuWR9Cg9ycKE0ogl6P0A5iDhquYT5B7I4+G7dGMgcOEHq3VDSn9GPkg 7YlhMwUupHQj8lvIP8Nb4B3o6ZG5RN3Q2zb4KLwPfoFlLWT6ZX7lig8ib6A9e+BRNC/jrRe16mK5 FX1J5KXIs4nJ+8hD4YuwAnWLUTcXm8bIz1A6EPlu9AmQvsROwGqUToL94I3UWsd1i9PCsOX0158H G1CXXnunKKVHejV1Gf1gKtyE/Vy4C94MwxaGIx72ayQsgwf6Hlh8Mo66LDmQhP1hbBYhN8IyHOum kFqJlCYWop0GmxZ4eA+mUjoNmcz0d2NTGs9ExtB+8zalGfghMroJ+uXoyd4gzIG+eAszPMzVT9Fj oyegOUbps5DR0cTBDIIz8RaOY214PexA6U7kmtSqAb+Hf0f/OD57It+KH1oecJWgDpZP4Wc6MrHS zCx/PsyGnbEJr/g5DMd0FaX3QyJpinLFByDRS0Djn+GKw9GHqwHZ64fzgpwP8qEpAJlThnE0eNPh HGc+6pPYU9fPgq/DBejDVQXZ7ECzGfkAVycTDBmuT1OLPAnCnA97tAabZOxnoQlHdi36jjAN0mbD ahMbj8+wVYy7/xVkFviMvkfLY6Oo9TD2F5CZO/4IuA89Y2qIf9ANPbPbJxM0K6HfB67Ehqz2w5Xk OHI4UoymIf4xMsTcCcl5MxmSewnbyX/GOmA9D8jVGDFMoEcxSn3sDeuDqSdUX+kvlbwV2e5KS4fv McxTTtOSfXcfedtg5vEmoRWlc+RvY026fD/NTOddihaN/hH9U6KXL1go+WsL0XQTBruEflX0OdQd SOkPwtgg5D6wJd6Oh5Zct0v0NqO0kncUsjecg+ax6I1HVf62Tt6itOb9yQXeh6TybmQx+vlSV+9E 04fS55A1Ho7DbLiAvqcI9Wgi0EnekOhNvLWohVzLvCd1xUbl8r6iYPT+xFH9TWyCGvjpSK1mvCGp LxqvoD/L6QtH70YW8w5kMe9DHOPP5Mp7qva522XtRe4ie1u9U2SvOXJXSpshr0Heh+UI5ETk+pR+ RK2jaAqE3tAcistOvzI2BaiVAXtQuickpWnIFyh9AQ+l0b+Cvg5yRUpjyPcijwvbILL3ZdgGSoeJ HO+Ye85lQlk0y1RRx/3Ic0Q2+djL5wpNQ3gazQXk6Vj+VRjsEvoeeg0XU5oo9HKQj8MM7BU2T8GK cCyl2bRhKnIP5AVc8Rg2w5G3UJqJn2T8r4fzo5ZLS/qheR/NajgR0lPTklKLZnR8Ff8Lu3heG5c3 gel4HhC1QfRfyxiZhkL1NXWXwsl4442HPoymk9j4ZePyXbVGlDaJv+YYV22dPj821UWjT4ZtxvM8 aUPsGjRrRPYmo+8Yf0vyU+z9DZTukVLXdxmdFDx3RF8En0/T/mK5F1w7x9Das7Rtv9QKBtKXI+jn knUjpZZXh2sNRy6Fn4z4RT5BuCjxhBOF7mlKeBBNcWyOIBcQmhtpVS1GbRPXGobnPrTwoDDmE9vy YYbkdpasExtdQDTy+ztuhWSW+fmlL7Ei2B8RObgJmxQ0XcM8JNrFuUoKkSkgEfMep9dd4vJuNpMW LkBOjt8uORaXt50FYTuuvoloNEfuIZZeDrUykM9huQkPk5Enod9DNLahL4vmDKVT0OzH2xQ0jbA8 IXQrDuMV5iHtb0tf/kYbDpIJYSZPlV67XcABosS4w9GMVA72cTxU5Vr1Kc0gfw6iryt067uMS6vI RniYHNiF551h/KNoSMub0ZeDxKow+rywC5aZ0XUvMi8uknunyYTQUuJWQmSX26fJZLG5G05GczuW aVwrDcvt1NqEzQz4PqXtovlbw/UlRpuX08dP0ReHH9CevqEl/R0Q9losXRbx1pqMikVRnUdWEw2J jNcXz8+xDqwleuuja4mfGoxU4XClotZxaq3HMk62Z2C5nMxMFTlWSuUj01Yx4tL+WeGMjuaIeOvG GJWGf6aFP0UrXlHuNXKVbdGcne5K3wznsnhzq+VztKoGtcJ1VTyP5S3xcdWLvOol9/TcDk6+jaw7 ig3rgAnn0STqttOfkPmrGE3p47pwbcRyFPpORH6q0K1Lq1grZFUJR2QBTKQ0nV43pb8H4FPwIp6b MV6NYSnYOrKRVW5kNI6ysj0ra6bLh1XMptfIiot8knuRXL1IPl9kLEQ+T9xGR3exomik1zPoaYPw Lsaac5zRWS1MIIsSuMuYH7DsBbnHqZOSh+4Z+BvWwNOsgbLCdKKd9cnSDHJ4J1nNWuQs52Ep9m+g z8SyJXIb9PNp+R7kxehviu+GA5l9p+WZXK4Sn557iPHqKLOVMb2ZfpUK72vxj/i8vpC0lpaPoS/p WHaM88xD3eKqhPOZFo2sky8tEc9K8Ttvype/04neNApVMvpk0Sslmvid8i3reFf5JnycvweJJyNX R66OXFO+px2vJd+ld/qB6Bci3yPfH5Nv5jt5I/Jx5J9Elr/icXVXyq/coK8l3wZ0fhbx2yxn+X2b 1UL5OwKl5O/c46ny1xzxVPl7kPiyWKb8yk3CI/IrNyJfWiNyfEzsafmVm4ST4j92WJhwAvkr8Z/w A/KvyKFNB1gTy+6wl/zujbTt0sGwzbHnsZ+HHNY6Sptz0JdGn1+Y0JjeVYUn6O9YSpfDBPTXYdmU a/2Efis+a6CpT2RCzQVK78R+IlfcSpQuwFFcvQmWlagrlhnIGcg1YlvQn0euhJ9QX5aW3IZcAfkO /OwVJiYg80s+iYmU3olmAt5WyG/g4OE6PFRHro5cU/5e3tl/hlwYFqJWc9pcgzb3YJRn09OzlNK2 2Kto7oEbYQ6lVztWS3gD+U18rkWehM3b8Fn0y5F3IZ+RFsqvcLjWSh7W5HN5cykXmbjJJ+nx6pd+ lPZcYizkk3enOS2ll9ZIJENNfBRMh9TCQ/VLG7Ck7iV6fWk28mF8foS8B/k4pWTUpS/RfI8f+QaO Usne+MSjyvR8aFCmSr13UO/71cjM7lkD1DLldn63dmyartzOIjdXFVIpKqaKq2tVAVVV1Vb1VGPV Wt2u7nI+OqiH1SOqp7pPPaCGqHGRfV6VoK5RpVVBVU3VcV6aqDaqi7rbXbWjGqHGuJWjnxqostV4 /o/BsI5ViW7NKKNSVYa6Tl2vmrrV+Q51j9LqVvUX9ajqre5XD6qhaoIqrEyr9u1bqtYdb7k5XfXo 1LFNupqOl6v5zdA/ubW5rPNYXTVQN6oW6mbVVf1ZGVVRdVIj1VjVR2WqQWqYmkidJJWuyim5092g mql2qpJ6An0Rld/FoaRKU+Wd35qqrmqomquW6hZ1p+ru2l1ZdVaj1GPqXtVfDVYPqUlRC65SeVQp VUxVcB5qqUbqJtVKtVfdVA8VqCrqNjVaPa76qgEqSw2X3zLtWWNwT3MbvBv2gQNgNhzZs3tmlnkc ToYz4Hy4FL7fs/vg3mY93AK3w91wPzzYs2f/geYIzBH6GuaHJWBlWL9X5n33+jfBtrBjrwEP9Pe7 wLthL9gPDoTZcESfQd17+mPgJPgcnAsXwuVwrXPc3d8Ct8PdcH/mgCH9/YPwCPwJnobnYVwY+JkP 9MwMkmF+WASWcIWDgtKwIsyAdWAD2BS2fED8tIOdYFf4Z9gHZsJBDwzqNSAYBkfCsQNFPxFOhs/B WXAeXACXDnZjFCyHK+F6uAVuh3sG3zegT/A1PAR/gMdhDrwwuH/PgTEFk2EqLAHLwxqDB2dUjzWA zWBb2Al2g70ca8QyYRYcAcfCSXCqY83YLDgfLobL4Wq4wbFWbBvcBffBA/AwPDp4SI/BsZPwHLwo TNAwEdrBQwYOTkiFaTAdloWVYY0sF8mEurAhbAZbw/bwNihP49qtPan/wtG4eV5MFf9/kjx+OPT/ zsCtGIFbRRNU4n/szOcslD236l3JvH+Qxq1zefjN5X9H8tzq/fss8IepGRHtvMoZb3vk/iBPiX+Y V/1hXvM/mP8PM52WGo7ebyg9+K3O/lMad6cqrIr8i9LVSNrdn0r9S8drVel/6VhGlf0Xjp67k/5z /vOYeO4O/s+Z7w+xunvayHJ3/alqvlquNqjd6rDK8Xwv1Svt1fKaeZ28Xl6WN9ab6s33lnsbvN3e YS9H+7qEbquH64l6hl6oV+qter8+qi+YZJNmKpr6prXpavqZ4WaimWEWujko10oMc9a0u+K8xxXn k644f+o35/4V5TE3zfepBO8358m1Lj9PmXd5fXvucv+pXS8/L6Qu918o9YrzslfYt7zivNsV51f0 p9D+y88Ll7/ivP0V58Mub3/xuZeXX7P68vMyla84r/qbczf/ymRcUT6Gc+3WhwJhD8u1D4/lw577 LucKu7WqbKTdGR33R8fD0fHk71lXXBYdV0fHTdFx1+WtqGQv72WllZefVxtzuX21ry8/r77t8vMa 715x/v7l5zU7XXF+2xXnA684H3TF+XO/yTIn1Jl+xfnKy+3rXDFK/6N8+xXnO68433X5KNbb7mhd ZHp601QfbxarbQ/3T7mZOlV5Qf7gKu4VBVQspZXdlNLSbrDr7HqniXk/ez87u5PeSeV5p73TSntn vbPK2Ca2ifLtjfZGd9+UfNCmuWkp19MFdCGnkb8gstIek9fVrOrOC7vdyCA1S21SB9UFL9W1IdG1 KjWlg9IpLVM6OrZKudWxtWt9frcmp7vdQobb8zSwPyij87s2/chxk3U7LV3InR/juMnuUdqd7XPc ZPc7bnF9lQxNU6XsQdfWda70bxw32UPuuN6df8tx028sD0eW30WWRyLL7yPLf7S3De1tS3tvpr3/ KGlHyS2UtP9tid1KC7fRwu208B8lOynZRcluSrRK0O6fm2Z5tHxzO7/O76JayEXVpNyU0sJFfZ1d p2KuTetdpIyzkE8jw7u+m1qufnfGSzFSnnfBu+BGLdfLddEKtHvuwW+A3xh+E3SaTlOJupQupZJ0 eV1eJZuWbjTzBD2CHiol6BX0UnmDPkEfZYO+QV+VLxgUDFL5g6wgS10VZAfZqoBNt+mqoC1lS7k+ lbalVSFb1pZVhW156/Z8tqKtqIrYyrayKmqr2qoqzWbYDH6Xu6Yqbmvb2uoae529TpWw9Ww99Sd7 vb1epdsb7A2qpG1kG7nRkXy7lnwrbVvYFqqMvcvepcranranKmd7296qvL3X3qsq2EybqSraAXaA WygG2oGqss2yWaqKzbbZqqodZoepanakHaky7Gg7WlW3Y+1YVcOOs+NUTTvBTlC17CQ7SdW2T9mn VB07xU5R19ln7bOqrp1mp6l69nn7vKpvX7AvqOvtTDvT5edsO1vdYF+0L6qG9iX7kmpkX7Yvq8b2 FfuKamJfs6+ppvZ1+7q60S6yi1Qzu8QuUc3tm/ZNdZNdZpepFna5Xa5a2nftu6qVfd++r1rblXal amPX2DWqLeN9M+PdzuXKBnWLy5VNqr3d4rKlg93qsquj3eay61a73WVXJ7vTZVVnu8tl1W12t8uq 2+0eN0e62H1ujtxh97s50tUesAfUnfwmdjd7wp5Qd9lT9pS6256xZ9Q99qw9q+R3vse4+THGZVI+ L58a5aV516jR/M+oY72uXjf1mJfp9Vfj+d9QJ3oPelnqCW+iN1E97U33XlCTvVPeKfWMd847p571 fvV+VVNlkVHTdEzH1HM6Raeo5/VV+io1XRfWhdULupgupmboa/W1aqauoCuoWTpDt1ezdZYeotbq oXqoWueeI4arD/Vf9Ei1Xo/VY9UGPU6PUxv1VD1VbdLP6+fVZj1f71VbTF63/lw0tUwtFTdNTTOV a1qZVp42s81sz/hZ/kueH/QMeno1gt5Bb69mcG9wr1cruC+4z6sdDA4Ge3WCIcEQ77pgaDDUqxt8 Hhvv1Uu+Nbm7dyJ5XB7Pi6fkT2muH0q5M2WOfiNvr7z99Jm8o/JO0hestokm0Za0JU0+e6291uS3 ZWwZc5UtZ8uZAraCrWAK2kq2kkm1VWwVU8hWs9VMYVvdVjdX21q2lili69g6pqita+uaNFvf1jfF bAPbwBS3DW1Dc41tbBubErapbWr+ZJvZZibdtrQtTUl7t73blJL/nNpca/vYPqa07Wv7mjK2v+1v ytoH7AOmnH3QPmjK2yF2iKlgh9qhpqJ9yD5kKtlRdpSpbB+xj5gq9jH7mKlqx9vxppqdaCeaDPuk fdJUt0/bp00N+4x9xtS0U+1UU8s+Z58zte10O93UsTPsDHOdnWVnmbp2jp1j6tm5dq6pb+fZeeZ6 O9/ONw3sq/ZVc4NdYBeYhnahXWga2cV2sWlsl9qlpol9y75lmtq37dvmRvuOfcc0s+/Z90xzu8Ku MDfZVXaVaWHX2rWmpf3Qfmha2Y/sR6a13Wg3mjZ2s91s2tqP7cfmZvuJ/cS0s5/aT80tdofdYdrb z+xnpoP93H5uOtov7BfmVrvX7jWd7Jf2S9PZfmW/MrfZv9q/mtvtz/Zn08WetCfNHfa0PW262hyb Y+605+wvplu0l5Inn1qstRVcOgfeXd5dTt3b6608/z3/PaVjl2KXlElsmNjQzZ7/zGrsMvd/V+P/ z1fj/86+NLKvojxteffFvvrfHPvfHPsP5ZgX9HPP8/m9UrqWucnvooqr+qqpaq06qq5uv9DPPb8P d88DE9UzaoaapxaqZWqlWq+2ql1qvzqkjqrT7sleeTEvJWmYMkmDk7KSHuI4JGk4x+ykhzkOTfqL O2Y5aSTHrKRRHIckjeaYnfQIx6FJj7rjEGc3lmNW0mMchyQ9zjE7aRzHoUkT3DHb2U3kmJX0BMch SZM4Zic9yXFo0tPuONTZTeaYlTSF45CkZzhmJz3LcWjSCKVd6RjHIUnjHbOTnnIc+m9EZBo9H5z0 XBSZ56PITI8i80IUmRlRZGZGEZkVRWR2FJEXo4jMjSLyUhSReVFEXo4i8koUkVejiLwWRWRBFJHX o4gsiiKyOIrIkigiS6OIvBFFZKrr/+CkOURkPhFZ+G9G5K0oIsuiiLwdRWR5FJF3ooi8F0Xk/ShX VkSRWRlFZlUUmdVRZNZEkVkbReSDKCIfRhFZH0XkoygiG6KIbIwisjmKyJYoIh9HEdkaReSTKCJv EpF3yZR1RGTTvxmRT6OIbI8isiOKyM4oIp9FEfk8isjuKCJfRBHZE0VkbxSRL6OI7I8i8lWUK19H kfkmisyBKDJ/jSJzMIrM36KIfBtF5HAUke+iiByJIvJ9FJFtRGQXEdlHphz6NyPyYxSRo1FEjkUR +SmKyM9RRE5EETkZReRUFJHTUUTORBE5G0XkXBSRX6KInI8i8vcoIr9GEbkYReRSFJF4lCu5YWSS VRiZZC+MTLIOI5Nsosj8QESOE5EcInJBMkX+n0ZpN2/TuqgK3i79omlrbjF9zL2mn7nfDDZDzFDz kPmLGW8mmInmCTPJPOn2LofMt+aw+c4cMd+bH8yP5qg5Zn4yP5vj5oQ5aU6Z0+aMyTFn89aR/0fJ 2+ntdBeYI3+da9qYNkqbdqadMqaX6a1809fcp2JmkBmkEk2WyVJJJttkuyeBYWaYymNGmBEqxYw0 j6q8ZqaZqQqaleZTlZq3dt7avGVIU8l+Cf9Pfrpf0i/lX+uX9sv4Zf1y0jPXorO8XfdUkd+8m6jE +6BMsXA1y0UWxX9jUfk3ZS6SJtNZKz/Vl98CK++XV3mi66b6hfzC/tV+Eb+onya/fecs/vu6WpVW +fwCfkE/8GN+gp/oJ/nJfh4/xc/rWz+fn9+X912+69so1wSpo/0b/IYqxW/iN1HWldVRRcyrZoFZ bN4wG8xGs8lsNlvMx2ar+cRsM5/+XsTlbZl5xbziPL4mf9dsFplFLt5LjVtHXeQ+ctc7ZI79H++v OKtFrnSlWWVWmzVmrfnArDMfmvXmo98bY7y/al513heYBfKNTLPYeX/DuNXZtfBT5136Id6rqtTf 9fo7/SBmh6KYSb0/mF3Uk2xw9YIBerl6VI1Vj6nH1Tg1Xk1w8/oJNYn/XfRpNVlNcbP8WTVVTVPP qefVdPWCm/Mz1Sw1W81R/8Xed4BVjbRtz0ySM4ckJ1QBAREUFQTlgIggihV7F3sHUcECKtZFERTL WtcuFhB772JDwIq9F0TE3huiKCLwPRnL4q777/7v9+27//dfr3M5M0kOOXnmmbnv+5nJSeJQPFoO CLACrUSr0Gq0Bq1F6wAPNqCNaBPajLagrWgboMMOtBPtQrtRItqD9gJW7EcHUBI6iJJRCkoF5DiM jqCj6Bg6jtLQCcCRU+g0OoPOonPoPLoAqHIJXUZX0FV0DV1H6YAxGegmykS3UBa6je4A4txD99ED 9BA9Qo/RE8CfZ+g5eoFeolfoNcoGNMpBb9E7lIveow8oD31E+egTKkCFqAg6NCatSRvSlviTdqQ9 6UA6kk6kM+lCupJupDvpQXqSXiSABJLeJIj0IX1JPxJMQkh/MoAMJINIKAkjg0k8uU7SyQ2SQW6S THKLZJHb5A65S+6R++QBeUgekcfkCXlKnpHnnEhekJecRF6R1ySbvCE55C15R3LJe/KB5JGPJJ98 IgWkkBQBBKl323MczwmchqOcljPgWnNtuLacP9eV68b15HpxA7nB3AQuhpvITeLmcIu4JdxWbhu3 g9vJ7eH2cme5c9x57gJ3kbvEXeaucFe5a9x1Lp27wWVwN7lM7haXxd3m7vA+fA31va38Zf4Kf5W/ xl/n0/kbfAZ/k8/kb/FZ/G3+Dn+Xv8ff5x/wD/lH/GP+Cf+Uf8Y/51/wL/lX/Gs+m3/D5/Bv+Xd8 Lv+e/8Dn8R/5fP4TX8AX8kWCTjChdWhdWo/Wp360AW1IG9HGtAltSpvR5rQFbUlb0da0DW1L/Wk7 2p52oB1pJ9qZdqFdaTfanfagPWkvGkADIQVB6gspmIbQ/nQAHUgH0VAaRgfTIXQoDafD6HA6go6k o+hoSBF0DB1LI+k4GkWj6Xg6gcbQiXQSnUyn0J/pVDqNTqcz6Ew6i/5CZ9M5dC6dR+fTBXQhXURj 6WK6hC6ly2gcjafLaQJdQVfSDXQj3UQ30y10K91Gt9MddCfdRXer736le+k+up8eoEn0IE2mKTSV HqKH6RF6lB6jx2kaPUFP0lP0ND1Dz9Jz9Dy9QC/SS/QyvUKv0mv0Ok2nN2gGvUkz6S2aRW/TO/Qu vUfv0wf0IX1EH9Mn9Cl9Rp/TF/QlfUVf02z6hn6gefQjzaefaAEtpEVapMV0FV1N19C1dB1dT3Po W/qO5tL34khxlDha/EmMEMeIY8VIcZwYJUaL48UJYow4UfpJipDGSGOlSGmcFCVFS+OlCdJEaZI0 WZoi/SxNlaZJ06UZ0kxplhQrLZaWSEulZVKcFC8tlxKkFdJKaZW0WlojrZXWSeulDdImabO0Rdoq bZO2SzukndIuKVlKkVKlQ9Jh6Yh0VDomnZROSWeks9I56bx0QbooXZIuS1ekq9J16Y50T3ogPZKe SM+kV1K2lCO9ld5JudJ76YOUJ32U8qVPUqFUJCMZy0TmZF4WZI18T74vP5Afyo/kx/IT+an8TH4u v5Bfyq/k13K2/EbOkd/K7+Rc+b38Qc6TP8r58ie5QC6Ui3RIh3VEx+l4naDT6KhOqzPQiTpJJ+t0 OkVnqDPSGetMdKY6M10JnbnOQmepK6mz0lnrbHSldLa60jo7nb2ujK6szkFXTldet1i3RLdUt0wX p4vXLdcl6FboVupW6Vbr1ujWstVnNiPLZkYjSRwBBGXzncu5JsDvV7jmwO/XuM5cF5TOded6oAzG oZlcGBeGbgHjRaEsbjY3G93jFnIL0X3G7A8Ybz1kvPWI8dZjxltPuN1cInrKGOI5781Xx4jNmxJB FESsF4wEI+zGZkbdNXc0D/Fjqqce+CWbJc0RJ4mLCRFXicnEQjwhfiDubK40gM2Srga2f4MMQB2U Ac5vAQooFhjgIKAzfIUUg4hygtU2spq6RmOEzJGNdBy2r0lpkKdLJyDPkE5/++w1qKUiLWgJS2QL CqDi59UjKV3dL2VAfkrKhPyMlAX5OemF+pdKCfWMirl6RsVCPSM7VwE769c1GgPYOqqIkB9XpO+O GLIjRuyI8XdHLNmRkuyIFTtCkAF4TQ++8yLq25J8iA8ipAFpgDjSmDRGPGlJWiJBnCPOQRoxUUxE VHwtvobzEWEtufA3cez3DPv/N7/+exhW5dC/ypt/J2ea0N60D+1HfwIGUpnTDzizGWOz1sBMMxhP dgSOVNnxMzcG/UVWjPgTPvw9Gy4CHvyVAYuzy/9rbPiN7YAXFwJ/F2fFOqA+VO3xWXmouqMVKI+8 L7ojH1RHJ1Acy5jmiAPF8RF6bXvoqT3UfvmVO8nA73lTNpKNZRPZVDaTS8jmsoVsKZeUrWRr2UYu JdvKpWU72V4uI5eVHeRycnm5guwoO8kVf8i2MT/mW8VAERXpL7Huxt/zrmKoGCnGv2Pf41KadIJx 8OkfsvA14OF0KUPKlLK+8rFirlgwTn7xh6xc8HteViyVkorVv8TO33GzXPBvYOcWmOASEMpaYUdk hlthf1SWrZQ64u44CDnjvrgvqoKDcTDywP3xQFQVh+LRyAtH4HmoPo7FS1F3vAufQwFkCAlHY8hw MgaNI5EkCk0m48kkNJVMIdPRLDKTzEbz2JrnIjKfANqzGH8ZJ3MmKI4z48zQas6cq4jWcC6cKzrA uXH1UQpj/MuM8a+w6O0qn8CfQ08FY8EYWwq5Qi4uKXwQPmAr4aPwEVtroLmwjWaKZjoupZmpmYPL aOZpFuIKmljNUuysidOsx66ajZqd2EezW3MM19ekac7jdpqrmqu4uyZdk4F7aDI1WTgAtEEBDtIU gTaIpp7UB++hNWktfFDrpK2IU7UuWld8WOumdcPHtZ5aT5ym9dZ64xPq+hk+qa2trY1Paetq6+LT 2gbaBviMtrG2MT6rbaZths9p/bX++Ly2g7YDvqDtrO2ML2p7aAPxJW2wNhhfN4CwH6eLAWIgviEG if3wTTFEDMe3xeHicPwMeHYxfg48m4zfAc9+wIUSkboQKnWTRpNecpx8l0TqputiyeHP97dANLqZ rbh0w32+7NldbA9G1ZHmi/YoD5rGA46vgqTmm0EVrGKlupX0ZSsJtjIhqXfZOGNn6DWVcWWgOy/s BedsiBsCuTTFTRGPF+KF7C6bNNRLsBKsBRuhlGArlBbsBHuhjFBWcBDKCeWFCoKj4CRUFJwFF6GS UFlwFfSCm+AuVMGX8GV8BV/F1/B1nI5v4Ax8E2fiWzgL38Z38F18D9/HD/BD/Ag/xk/wU/wMP+c5 nudyuffcBy6P+8jlc5+4Aq6QK/rv7OPBFJ6wmQae/VrBmK1mWULikA0kHlquAljqgtT70lwhaaFV q4NOrAFJRL6QJFQf+SEZNYWkoA6QDFEn1Bn0YXdIJqg3JFPUD5IZGorCUQk0Co1GFigSUkkYnQRZ YUNshKxhjFqhUtgW2yJbdk9DaRivrZAdjNfOyJ6t6pZhI7UsHoAHIAd2l0M5PAwPR+XxGDwGxvQU PAU54al4GqqIZ+FZyAVGcCyqBCN4F6qMU3AqcsXH8HHkhk/j06gKm2/yYCPPk2nqJmzWqTubderJ 5sKsis2FVWJ3U/mQrtBipYgbcQPl6Ek81d+IkfpwpAlpAsqxDWkDyrED6YAE0D9BSAPKpz8ox8ni z0grThNnIUlcLa5BRuI6cSMyEa+K15C5mC7eRJZilngPNHWENBbZA4tMQA4qQyAnYIjlyFnFc+QK eH4VuQGKZ6KqgORZyBOw/B6qBnj+AHlBjPUIeQOmP0HVAdefIR/A9hfgq9/aUpnZ0piEgC2239ni TbzhiGoRR1pBTMMziwRmkQZ0XmdEmV1aUHGDkQGzS2R26ZhdJswuM3GzuBUs2i7uRtbMRjtmYxnx kfgElRefia/ALtXSysxSN2apJ7PUC3hwFcQJayDaqMWs9mNWNwR+ykVNgZ0KIEL5vPqq/sqxN7PI VbVRfdIeqv7FRtcvn3GE0TsLz/+2j+D1eCtsmX37HIyAH7RBDQLtxlqCZ74VWHtoWHtQ1h5a1h4G oHu7IZG1isS8LbO20YmdxE5Igch8LDKE6Gs2+HyuuBjZQAy2GzmIe8Rk5AmR2CvkK2aLH1AQaIhJ aCCohVloNKiDjSgauH8Xmgdcn46WMp/vYT7fCwx+B+1jnt/PPH+AeT6Jef4g83wy83wKMPsrlArs no0OAcMXoMPA5xp0FjSOJboKusYe3QItUxE9BFUioZegLoxRNnC8FUQAgIQQIQ1GSI0gUV11lgG1 Vu+2QW2ln2Q/dBb+phRe9Jc/x552+Td9+lt/QAHMq3rW51sV6w/6X/sD8ke+3/YR1ICt3Zt9+xxB nLhEXAnfmSKmQR/Pk9SRA3tZlP/5SuzZNei/XOXXa60OaPYvoDv8ZQmGhYhhIWZYyDEs5BkWCgwL NQwLKcNCLcNCA4aFIsNCiWGhzLBQYVhoyLDQiGGhCcNCU4aFZgwLSzAstGBYqP62+RBYIJNG3D5U +0/XgggWsQlcZRlcEbvj6rguboLbwNUF4BAchoeDforGk/EMPBe+NR6vxhvxdrwHH8RH8El8Htrm JrTDY/wSv8UfgYA0RCYmxJLYEgdSEdrYE1cE6x2hLSqxsjMwsFp2w96s7I6rs7IH9mFlT1yDlb1w TVYGYF9WBuJarOyNa7MyCNdhZR9cn5XBuAErBwCrq2UobsnKWMFCLfndgiUrE4WSaqnkayW1FEy1 slpqVmp1rEzSKqw8qDVkZYHWiJWFWmNWFmlN1BIUlCkraxli9j0h2AnQyBC0BoEtF8g7g+JQ9Qtg ElgJPRFsdIO8J3aHvBeuAnkABi0DtlWFvDf2hDwIV4O8D66r3n+C60HeH/tBPgA0CwGrGkEehhtD Phg3gXwIbgZ5LG4O+RLcAvLFghkiYG8JyBMFdfYlXwuOAUuhV4OdPORJWtA8YKNGvaNKSyEv1Goh L9IaIAK2gQLT1kJOMLa6AucPAK6PQBPQNDQXLUEr0Ua0Ex1AR9BpdBndRPfRc8CXL2uK0JMsoa87 QF/SY09cA3pTI9wC+0Nr9ASrBuD10Fqx0EIbWNkNb2Rld7yJlT3wZlb2xFtYGQDorpaBeBsre+Ht rOyNd7AyCO9kZR9tKbUEG23VEqwszcokrR0rD2rtWVmgLcPKQm1ZVhZpHdQSLC7Hylp4GfNfHPNc PPPccua5BOa5FcxnK5nPVjEvrmaeW8M8t5Z5bp3qD60Za/ESrMXNWYtbsBa3ZC1ekrW4FWtxa9bi NqzFMeINEbuznGNYgdhIx4bqz0TUpwm3YPf1OyJ3pgPYbBg2Z33NgvURS/W71bPgkt9q/dSepGIv 4Ml81ldYrq7SYSNAKIRLQFyFGRIRhi8qr1qiKbgd7oA74Y64Pe4ndgQG7Px5bpoMI2PJZDKPi+XW cduVT0qBUqgUAcouFZeJcWK8uFxMEFeIKwFxU8VD4mHxiHhUPCYeF9OU9wpROIVXBEWjUEUr5okf xXzxk1ggFopFEsCe9Is0W5ojzZXmSfOlBdJCaZG0W0qU9kh7pX3SfumAlCQdlG5IN6Vb0m3prnRf eig9lp5Kz6WX0mvpjUxlrWwgi7Iky7JOVmRD2Vl2kSvJlWVXWS+7ye5yFdlDrip7ytVkL9lbri77 yDXkmrKvXEuuLdeR68r15PqynyIrOkVRTBRTxUz5oOQpHxVrxUZR10HLs8gTsWhTANXVFDgthAwA 5RAOUaVMxkBUqWP3zSoshjRkkaERm/815rZx25CJZotmKzLVJGoSUQnNe8170IwQLyELNV4CbXVL fICc1KgJlNRk0A/VpU2gHOpBxJ+OmkHUn4GaM/3QgumHlkw/tGL6oTXTD22YfmjL9IM/0w/tmH5o z/RDB6YfOkqFoBw6yUagFgKYWhjD1MI4pQSohfFg5z7U+a949F/z4N/ip68eEllrItaaBqwdTVg7 WrN2dGCWV2KWezLLWzPL/ZlO6vA5+hTY2wah3gSpc8t1kW3x/v/bXvzH/fFz34EzGLOeglhP4ZiH NcyfCvOnIfOnEfOnMfOnCfOnKfOnGfNnCeZPc+ZPC+ZPS+bPksyfVuA3C2T95eolQSl29Qpo3i8j Vh3zrJ8i1k8x66eE9VPuy9/KgmGxv7UEVfINBb6OdIYcbBSwniywnkxZT9Z+jqRxNs7F+V/UgDEx J9akLHHiGguBQpDQVwgWhgrDhBGKvVJWKadUUJwUZ6WS4qq4KR6Kp+KlVFdqKL5KbaWuUl9ppHRX eit9lH7KQCVUGawMU0Yoo5RIJUqJUSYrPyvTlZnKbGWuMl9ZqMQqS5RlSrySoKxUVitrlfXKRmWz sk3ZoexSEpW9yn7loJKqHFaOKseVE8op5YxyTrmgXFKuKNeUdCVDyVJeKK+VN8pbJfc/v/T4z32f /2O/9DACzd9HMFXygfNr/aX72mEk4hDNzWJ3IWvVu3S+3ePzf7hP59sdPnAOUpN0LzbToe5pCgj0 bb4Av0XvQaNXJV7wiXqwryVpTdqTTqQr6Q1YFQaoN0ZdV/tRUtfSiic4y/fJ6/dJXXkrntR1uh+m er9JDdRVvO9Sy98ndUWveAJb/iABH3yXwObvU6cfJeCP7xK00vepO0u/bvf+TeoLKeQPUtiPklT4 fQLW+j6V/E0q8336Yt/n62Vn+M/8yB/Mj2B0C/izBnB9I1DZ/uxZLF+fwKI+jeVnNAvNh+gnAa1F myH+2YdS0DGIgC6i69B+erbe/H+be/1Lect/Jf/hLMjnORIZivlq3IPqqLEAcJ05ix7UdRaMnSCO JsD286A+Hy+A+kKsvkF8GUReBO/Cr9Sn0OJsiFfesPdwvMO5UH+P8xhn5kP9Ey6EehFR34JCCA99 TiAaqFOiPrlVIhB/Ex17p4gRgRibmBAzqJcg5lC3UN8RArxqDXUbYg/1MgQiN+Kgvn0EONYJ6hVJ Rag7E2eouxAXpL5VpRLUKxP1bUCLyWKoLyFLoL6ULIX6Mq4he5JsY8RxTQRT9Vl1AtgrWAl+6tMV hYaIExoJvdRnhQvBUA9R30wMXD0C6iPVp1YJMUIM1CcKKUh9y3Iq1A9pAZm1BKJIoi1v0B9hgwEG oPQMBurWIaxbr4OoV7dBlwr1Q7qjUD8GShUrtqAzOFCTRSzCA1Q2JIb2n39nzTxDUMCXXwf/qkEw 0yCYaRBc7FesmGkQzDQIZhoEMw2C2W9PMNMgmGkQzDQIZhoEMw2CmQbBTIN8vkLClAhmSgQzJYKZ EsFMiWCmRDBTIpgpEcyUCGZKBDMlgpkSwUyJYKZEMFMimCkRzJQIZkoEMyWCmRLBTIlgpkQwUyKY KRHMlAhmSgQzJYKZEsFMiWCmRDBTIpgpEcyUCGZKBDMlgpkSwUyJYKZEMFMimCkRzJQIZkoEMyWC mRLBTIlgpkQwUyKYKRHMlAhmSgQzJYKZEsFMiWCmRDBTIpgpEcyUCGZKBDMlgpkSwUyJYKZEMFMi mCkRzJQIZkoEMyWCmRLBTIlgpkQwUyKYKRHMlAhmSgQzJYKZEsFMiWCmRL4+o+TbE0ush0JpxvYi 6/76aOu+GoOKExtNfK/DlMRHW3eEXf4EYzdJb6ARnBWOWAlI30sjOmswj6OrEczHt9W31rsU22OT YDvOhi0p1UAtUQAaikIBRINQOPxXl5h89fbFTsabVaArWnrlVJrypC62HPzs5xtP6u0/Hx9tXlEf zZvoo8nHeI5gAuCQiqbWqDHZ+IJvbuDzrNp63bcrxTxcU5ibs95Jw7XjJdMy9ULDRg0J7tsv3M4x 0MnOzdu7ml3z4MAhoUND+4Tb1QsdElbZzVZv8/nDJb4/EjqkV3hw6CA3e31p9Thnavnr8TahoeF2 dYaF9wsdEhw+Sm9rofOupndz0+ur6eFfZwudu97NvYrbl81/4IqicZnizaK+qSoaYAX2iyQaY7SO JKWGPfR508LaMW7ByO76pwnrppfr8aFwXrMViYVLE+x8I1onLE6Y2dO9/4W6vUe93Dj8hP+NN8+W TLSZGTehz46j/UcHlL1aqsYtQzz78fwjyZX6xMb2K7/ofHWXZHlXx/KpDR6Jvl7zXdY5eq993nh8 3XsTDPfHDmjXa2N0xPKelUY0e7JoZ2+f2FY2bloHs7h1j35xtnxYc2GgWc+OQlBcqWptJr1f82ou OWZ9Kbmd344p45KrP/ef22JzwZrRA8NbbLE8Pd/A0R51mNUzuNr+pia0RvuiLvkr+4ja1Rej2nd4 tdunu3nUCP5G7sHN4+YVbj0TeXWN1ZCuNU4eeK1dUUa/QxNzYofdCNOYLMJBx18RtVYftUoflQCt WQrzUbH6qAXjjLqcD3sVPGRZ2dZjzbY3n1F0avmQf7//ov+kj3OqD+c9llKm5yywrPpiD3a4PsI4 p2tP97hl0ilf4ZfJM09Uf2j/5nWHOS674humBbz6dO20j0/ndZ7+wYUOA2udOL3+lhCR6Ta9ZpxR WMj+QpOWlsEpn87Xu2fc2a7l04CftqwvmeZcrVylg0HLTX4uZxi44r2/TZ79iaslctpsHFTPnRZE W3x40HeArnVuUnab40mPjug/2bkZTC41z8mq+ZVSZFX2uNvczi5vt2WmdXgZ1Ph4G//dOzlHk6JZ V19rZ47ds+Dohmou90ffXzvi3vB4dD6kVupFz59v1zFZWzXEOiSj6p3LNvz9tX58WucqXoOa2+gC EsWEaZeu+NdqcMam3eqwDJPqk+YMi1tzMR5Qoac+mmv2GRXEyhuMb7Yq6rr0VMpXTCn1T4EBjHsv d/gHCOAOYODmDptVv4LBKIagcBKNKWnX1s1Ub6xuaE3FDr2G9gse1DccvsZIr6g7qSltE9R7YOig 3l8vTPyjCyurt/98YVbFj/cOsmsb3HcQnNWuVb06f4oKiaPGXO22w897rcdGtxt55ao2HpGSX3rZ cb/Bry40eHx52uH+zdoEvF1EDje/3niAq4NvUPLZsolSo8TIYZl+SetnKq2OlnN+E/9IV7b0hToO HwMWnSvpt2pOk9KLzuxwLXO4SaWI0PQStj7TvI28M5Oc3vbxqYTdiworNFq9awCetCR/3/bAyOi8 rvFRE2JmbH2zZ+6Kc16rW8VYVJjUIlOfi2q+PZZXM+rgxBcDvNdU9sjdWXmLOCbgl5F9liwcqpu4 5c2RHLu9LU2mB55ySXf3K/lyf5P5Pq3aWp7t03rU+k2T0tr7xkW3mjxI2FY19SeHpDZ9ai5qcdp5 bJVBExpqLiw732QiGTQRrUyZlNX2Cyp81Ee915uqoFCOl/WiRguEJgiU4/53QIWheo2m6msnBT0H hb6UukPhzXmz06XODkdhXbZk3zjSIrZ1/cor6ge+1kvqYUOeh2E0sdjQYRjz04bNY5uUf3P2QIvw hI4VwisO2zGxYEOzuSNR8ycnn1neDD6qJETkkHrHTk46/aHt6UNxSe1DXwfWX1cfvZyfFnvFZo8U V1I399oN201OY169WD1048xb3jNqLgw54DXw4uQtZQuynlwNNvhlclLhHbTfI+d9RJ6RSWXhmdP8 OXX7Ow5O9Jp5m+pOdOt3Jmlcnf591u5P3D/D4+Qbzihi9LuLt+tm/VR4587GwtysK7odYVdn32u5 2yshotLlmhkeUkA1EhcVUnZKbtfAmVs77/e+1nNauwlWVd75LIyPlhN6TN3hkrh81akNN+x2J+tL xtiZ6SoeaPO2zu3u+nuzHYMnpYbdzVmz4ey4ukOGK4AxIYAxbb5gTC/Dkc2ZQuKKjyMBcOYfHNVf AaeKXg+IUwUAR++td1c3q6ib+vC/5dK+HOf+4PifYk1Chjj93KHUxovPrK/usalsp/4ZAw7al0mc m/Z0c/KxK+UPuRtPPXCjm0u+Z3vbEs6bZ+oyzVYMcmwWaV6rzsbptbc1mKxLj5q7aYHmfIf6w7s+ zf6k3I0MX1HlVPiDV/d6LR/LJfoVXfE1ubL1ZHfd+Z/eJJrqPvUMcYwZNi1x04GYxxY7Zx18Z747 oNsL46zqL+27TN0ybuhhv3vzpozoufjRphGp1aZXMXM1zQg4sdlqXcuFfTddtvPWD749vW+Du8ds 3upahddxfSw4hNj3b7x19pHt3sfrrhrY1bLJhpnXZoz3HSk2vL5y+4Syh++++anPtibhSeXrNF3S y6xnC31adM55KSziZbvmIy5q2w2P+oI1H/RR71jblzJURywMQk1KsQGbY197RkTrD/5NFz6wuBYy 3kOoXP7xj6FJxYlSZXlLvfm4Hw/z+uoHSvM19T567/hq8VUnVukXHh5W3dU1cMiAygO/+rByYOhA 17D+wepe17Ahob2HBYYPda3XFjpaZdilb/T1K0GH1NBX13t93daTiS5fTjhixIgfnTBoSLEzhf9m ADG0qd0htG3fZXbjPbDy0KJpjU3PrkdFvtSNCh/RckFDyxxUInhsRsCshIK+y5fcd3T62O7aosJW yd0Nduxd/SI6Z6FtaKeP77LvyJeman3NLewupOzya6gt37ODQdO5r7Wn9zUf9PpuIxPHqlPth2T1 2L0l2MRh7ssnHgYZYweFzhbbnKzYrPF6d5eJj5ef7lb+wIEat7tsHy/tq2rTcoJfw6L9c5d3ouvm Z45M6hC5ak2L0282LYmtc/dUVwffm5EeDVvknkv7aemz3SeWBJq13bIp9tW15HPxyzfMOznaeZJL yvH0TwO4G8lem7IvdC1pYZjy/uS41UZaq8xZZR9tXd7M9+lW4/IjlVSXvSv7H59ZA9BmKaBNzFe0 aRzxgqGN8M+hjX/wwKCh4b0GhhVHG0+9t5un3q1qVXcmb9zYprte3dRHrf5brq2CvtxnorQdVC84 rF/QELv6bf3s/Nq2qO6mr+9VqaqXR7VK9eo28Pr6Qc7U9g+MaBs0ZHhwYNCfAtTTfUJgWvqozRPq +67aceRFs2UOWd7DbQ2uujfpOPKic/oqOuvVo5r5SeUjVuQ/GDPW/Vx6zane1d58uO7jYX55dnS+ x/N+MUOsZt7e0+z2npicKiJJTRg+tGqzbtmJd5qMKbVn7siMItuYEnUbDD4bWaGDyYXxLX3OfbyV O/VFLXTvyq1eeRbTm66MqvEuuPbTO1OSact94T89kR80fLphQPaVvlHaD+Ynx5juH3rXoNnHgPwX 8d6x1QufGaf1sg3oeF30H3/Fp2nTu+2SXHtazZgt1LvR7Vm0WHaBQbzgFjR1TgvbOvYJs2cV+NX3 C626za/apuB1QXke9bZZHPLxvmM07Y3VpHv+rUr7LHXbVBygfgWksUNeV67V3ul2uff99uBPTe+M PXfP9zvsCX3cotaCvR4bmk6ceWDJ040+deodO//fwp7woWGBvf5HsOfrmcJ/hKDa36HwDwAqeHS0 gWx+4da5BlMqJ1/wGB0VWcGxTsWcS/azlQWberTt7pT3ItW/ydox703PS2Z5zd9MLIEG3RtfytFv jYu3e2ZobLXOL8u2menPTa+1Zklvr1zPNLN6u6v7LjyhOzw4yjGnzxq3u127zcxr0+ZO12dzZi0N Nmg25cKF4c08dCF3Iuqvce4y3j/Sz6FkuSM/Nzha7l7JccFOZrkWx16XcYlq0N35bd7qYyN8y4bm re4dMyMhQLeuku3aB7N8I4u2zvi04Hl2Ab/lTOOzncM3fswxLW3tfXbFzqsH3u58mbbpTXvb/BrZ aVcr1j+QvKTWmD6WZ7bbBYona9cMci8ZsX1PzdTyjVqUKblo0DR9avYv3wOUUYi0qGUKKrfBOMOv dMfRfRN+C1P/TPD1BZ30Hh7VVHTyhs1/IPj6HXD+Gd7crDYof0ta3SaDLdPONvJtm/Jxg9k+F/f9 Ji3bpI1/4VslvbHbbMfdv/S+XbrVhH2Hml6IFD68GnZw6vG1VzYHh/UZWaHP492Jr2L2nnm5vsBk pdSpjJPrudrp7Xnr4bsG9h7YxD8jM/tWctz44+OyIpuRanPfpSzTtrft1/BMesrwrq5jdpfjd7bv EmITWDQuosbLK3y55t4jwmm3Q12vT6zmMuyE8tTW2yBieOHSAYNG337uO3PBssFKj4otLQN6ui+7 OL6Fc5mu/fym3nKdYNRqe94uq+kDXpZbbPrhlNG1GOVt9PChnsfmjU443VPzXNg6sUrih7ldJtSZ 0DFm7qCtpV0anQ5dUu92yOPI8jP6f8abaOwILeLw4xH6vyL8MtIYfJkALYHVmAoVQ88fgmPJb39g RnjZVkRt0TAUgOqhOt+HZr+L634AUHObG7sdimi133jG8l4UK9PC/Ka/GuqfVMtAqFS0p3XbGJsX 3r8krmgv3Zq228f6Qv7GNScSt7W2tw7VBo/tzyWUafBiwM6BEWX2NLg0IWe64UH6s2fqs7FPwrr5 xc2+ePps5oyUO8kVz0Q8P7HZ/cqkvacCj3hesLRPHn7LJ3aH9dBl9pOv7/yvbREK6fky51Cq1ywN tTkJXfzWx4VTKzx2n1/bbOW/ISninsHLl5ayjzs/3bJs/Cms2JPSkMzGMu3TLCZn/Wq3jl3/mW6m /vS6d4u5ZPJm1jyeM3PvaCTWeHwUnyOoaMEk076G7eg0ox1PHY4F2+5d2XnvRZp57xelaXPObCgP CbS6VuSySfmbYRPLemAhtZqJkdGgsX0Ae2UofUXEGPeCxlsGIvD41mA0ZGdmBa9eBqUCaGRyMhvy IA+rA12D4HEb8hkgy4oaKCM0shgC09j3fi/2Ru+J97ZyzArY0Ln/r4b/xK0GKUhaeAzDDEIWaDVo MPgyZDIkMxQx5INH5tMYShgUGEIYKhkKgLx0oHgikJXBULlQrUEFZ/VaUlmQn16UWJBRqYBWvLE0 MTIo7H+2I1KSwUpkllSH77nPUzfMmeyw6BWfcTjLO4titz9/Nq6b+f6BweO6rq+vvzBXf70a8/Nr ydwG7rzNt9bpM+exFLxivvZNvFP3QMtU86Xn7Vpiw/kqT96QvLH/r3H3vDubFRZtd3u9s27+2/UH 7I692u9y/6Ljnh8vRSS7vD9OZnQ9H2/M012/rmexc++JP37/k9dOOnzWUD20eEvC9oks30/ylq3z qFjHNKvh1LqJJmZqx56l8CzoYzqZK1+7ri7M9Mhl4ZpNTkpTZ56v8isoW7xO+6jS86ri67EL+he+ D/c3ZNIWKHP5NcVNJmmKcHV/zZMW5QeLZ/uZsxzzSVv1YumtpRHKtZ0GF+VFFjYxyRs0MUkj4ojN sImJByjEQfckil4joXQw2KFJdEGsgQRySuRGzAIxAu2Ey7Aa8gOrWgtDAyNgRWtkaWwahZEQmf6r 8N3fltgbqxdv0OEq9XX9gzc/0MosUBK5P/2wF4fu/R0npZfdVGQ9zvMmrU3lvxPTeecPe08sVCib 9mjPw8l9Qg6P1LQWLZvYndgj8fOM1sYAqfYf1RNfBR91eLFbN7b/nMuklLywBFUn7uNtTA2O75Rm Vh81qgp4l9Px5JeZ+Ndj3ZOSZENmXXkqLLTw2tx13/+HWzG7v7z6LuJzmp1junfc9n17b7bqPgnf cWLi6qTCLPvlwhyHzmufKb03s6uyoqB5rdusQ5ubO/3crbSbgxWNVvx7ddy+pIzpwLpVRcGxOzKO 1702tM2Ypd7weQvbhueXdwjqNF3K2b/+fuGmF81JK7Yxlhnc4nMI3hTN+vn7FrMU1mBF0e50tzyB rNxI4aC8LbwMAOsBJCgNCmVuZHN0cmVhbQ0KZW5kb2JqDQoxNTg4IDAgb2JqDQpbIDIyNiAwIDAg MCAwIDAgMCAwIDAgMCAwIDAgMjU4IDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAw IDAgMCAwIDAgMCA2MzAgMCAwIDAgMCAyNjcgMCAwIDAgMCAwIDY3NiAwIDAgNTYzIDAgMCAwIDAg MCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMjQ2XSANCmVuZG9iag0KMTU4OSAw IG9iag0KPDwvRmlsdGVyL0ZsYXRlRGVjb2RlL0xlbmd0aCA3NzU4NC9MZW5ndGgxIDE2Nzg1Mj4+ DQpzdHJlYW0NCnic7JwLXJRV+vif875zH4YZkPv1hREEwQFBES/piIAgmhcYAytlHAaZBIaGQdQ0 qd1upN3vF7V7rZXDaIXZlpXZbmm1u3a/rG1tdzfbamu9MP/nvM8Mgtpuu5922//nN+f4zPec5zzn Oc95znlfIA1gABCLHwqYV15bPbNunCcCBO9IgORLK8rK684bf9E9AJcdQgNFRdnsGY9H2PcBXFII IOyaWV5R+fGzXx8FoWMcgPiXmfPm1n7YwG4A2PANsFvem1lrK3vuwIcMhJz9ADMXz60tKDoavXM7 AHsDV210tNk7pNzU1wFG+XB+jGOFVyqoHl8NUO0FUGmaO5a13fFZ2YMAo3cDaEcss3d2QAKYcX0J 55uWta5qPno471yAuWsAdK+1OO1NH6kGKtH/WThe0oIKwwbVLuxfh/2RLW3elQUTlRaMvRQga8Vy p6ddc7/yBYCVt+F4YavbYZ8/a+4mgEV1AGmVbfaVHclH4lJwfj+OS+32NueVu9ffivZ7ASLHdbg7 vYF58DjGA3y8w+PseP6QF/0X4/5ibwOeW+XGfk3xo/uXGKd8C4kabgc7P1+zl/O5zJs8R946tkH7 hfo5tNWCAFRwngoGgO3WbT7y1uGLtV/InoYU8WauMWbCXFDKCgFMUACNABGO2NvIRDFLeAJHNcqb lcXoMo0ovgKPC6ABwagWRIVCFBTvgxCwwoMBnKPlE+fUShLw/G6mGNQbhWwJ2CbZ6S5lJN8peo88 Hg17GX7yotTDhp/eKxUh86f3rRr4YZ9KF8z7d/0qLvjP5SFcwuV/vShqoObnjuF/pbDvYPnPHcO/ W4Q34PyfO4ZwCZdwCZdwCZf/VhFuhY9+tK0J4v+Tsfz/UsQLYdXPHUO4hEu4hEu4hEu4hEu4hEu4 hEu4hEu4hEu4hEu4hEu4hMt/uYhBSQn+q7A7sYct4QpQwMWy3oSaCGwZIBPyoRyqYQ7MhQXQBC7w wOZAQJ5nAOkHRlngW1wiN7A/8FHgu8BR0MCj8A1LCjiCKyb8UGTiLPFGULEv5N5XJ/6rNewLwX/j JsA/LmyIv5OXsf2T2SeW4/EWBFmOQv+uZNE/n86SBltnnzS2/l+M5ecu4k/q7X/ixlkrlyw++6wz FzXU2+pqF8yfN/f0ObNrZlVXzaysKJ9RNt06beppUyZPmlg6oWR8gWVMfk521khzZnpCTJTJaNDr tBq1SqkQBQb5FebKRsmX3ehTZJurqsbwvtmOCvsQRaNPQlXlcBuf1CibScMtrWjZfIKllSytg5bM JE2BKWPypQqz5NtXbpb62aL59djeUG5ukHwH5fYcua3IljsG7GRk4AypIqGlXPKxRqnCV7mipbei sRz99el1M8wznLox+dCn02NTjy1fjrmjj+VMZXJDyKmY1CeAxsCX9YlZFfYm37z59RXlyRkZDbIO Zsi+fKoZPrXsS3LxmOFyqS9/V+/6fhMsbcyLaDI32c+q94l2nNQrVvT2XuKLyvPlmst9uas/TMAt O3355vIKX54ZndUsGFyA+ZRZJrPU+y1g8OaDXwzX2IMaVZbpW+BNvsXBNOF4qA0YG0aI+8vI4LFc 3m+Fpdjx9cyvp74ES5P9YC3Ia/AJjXxkV2gk1sZHekIjg9MbzRn8qCoag39WtCT4epZKY/Ix+/Kf LPyD45JPzG5c6mjhtDt7zeXllLe6ep+1HBtWe3CvFX2FBWhvb8RNuHga5tf7CswdvhhzGRmgQuJn 4Kqtl6cEp/liZvig0RGc5SuoKOdxSRW9jeUUIPdlnl+/A4oDB/rGScnbimEcNPA4fHEz8FCyK3rr m5p96Y3JTXg/m6X65AyftQHT12CudzbwUzKbfLkHcLkMeUV5Fu7tBOuQMd+5Oksj1QvJYgM/LVRI lfhhLpuCAyY8LrnLT7RsilTPkiFkhqsELXhrmB/siFkzqviQyKfOqErOaMig8g9CSg7GpMzyaYb4 MqFiMCZa5wdDI2seUK5U4SwfEuAwp8pggEFvp45T4LkILowzNPw4q0JDYhY+uagT0I2s4qeYIPlg nlRvdpobzHiHrPPq+d54ruXzrak118xfVC+fdvCW1A3r0Xgp9XyQgcOhjjAD72BlXnLoWOX+TLk/ 2K06Ybg6NCz1asw1tb3cuTnoECR8gnDTquxq++Wl0ePw0azEt5u50m6WTFJlr70/0LO0t89q7e2o aGyZxH2Yq5t6zbX1U5LlWBfUr01ezZeKhhpWU1c2Jh/fPWV9Znbp/D4ru7R2Uf0OE4B0aV29X2DC jMayhr6ROFa/QwKwylqBa7mSdyTe4Z4WYEcj2yfvsAL0yKMKWSH3Hf0MZJ0mpGPg6BdIZwrpBNQp SGeVdbzgISW0YIrxdVshNfHjWdPQ0tvYwB8uiMOjxD/Mx8xTwSeYp/YxQRXh05mdZT69uYzrp3H9 NNKruF6NF4PFMUwOfyf1NprxPYUXqh6SGV1FkbuU+gOBuvqMfckHGzLwqp2Fsqjep83Dd78yaxba zeTSiOqZvh6HnccBtno+V51V7WjAaxtyiCbVPi160AY9oEWlPIdfR5zkwLPBA5Tn92DH19Pga8jj i9a7GuTrbPJBlXkSHjv5VGbzhQoaeqPNRfKziY+CLusSDi3GBrX1pEnGLi7WQElSR2DkDjMOORol zLYCHLV41eldqksmjRNfiYpspyy65OAg8G2JWXqDzqe1oEP8w9t6C38klVnqhgYKXu5dEjTAtU0+ PUaUPSSVwQmYHRyq5rHgn0swVG76NHczvx8WmFfim4UHLXtS47DPkFVtx5c/zdejxlwamqzh7wh9 0Mdu0qr5ziMw72JWXX/gPvOqjCFlTL6Zf3HgFxOSd+DFhobeExW+M/PG5GtO1BpkdW+vxnDqCZQv jWGQqIQ+rdgv/N2flpreL3zvT8tDfOdPy0f8jfAt4Rsa+5p6fyV8RThE+JLwF7I8SPiClJ8TPiN8 SviE8DHhI8KfCR/607SID6j3J8L7/tRoxAF/aiLij/7UAsR7hHcJ7xDeJpO3qPcm4Q3C64TXCK8S 9hP+QPg94XeEVwgvE16iIPYR9hJeJLxAy/6WLH9DeJ6wh/AcYTfhWcIzhKcJuwhPkc8nCb8m5ROE nYTHCTsI/YTHCI8SHiFsJ2wj+Al9/pQihI+w1Z9SjHiY8BDhQcIWwq/8KWMRDxDup3n3Ee4l3EO4 m3AX4U6afgdhM2ETYSPhdsJt5PpWwi00/WbCTYQbCTcQrqd51xGuJVxDuJpwFeFKwhXkegNNX0+4 nNBLuIxwKU24hHAx4SLCLwm/IFzoTx6HuIDQQ1hHOJ+wlrCGcB5hNWEVYSWhm7CC0EXwEjoJHsK5 hA6C2580HtFOaCO0EpYTziG4CC2EZYRmgpPQRHAQlhLshEbCEsJiwtmEswhnEhYRGvyJExD1hDMI Cwk2Qh2hlrCAMJ8wjzCXcDphDmE2oYYwi1BNqCLMJFQSKgjlhBmEMsJ0gpUwjTCVcBphCmEyYRJh oj9hIqKUMIFQQhhPGEcoJhQRxhIKZYjMn2DBXgEpLYQxhHxCHmE0IZeQQxhFyCZk+eMnI0YSzP54 fqEz/fGTEBmklAjphDRCKiGFkExIIiQSEgjxhDhCLK0QQyuMIGU0IYpgIhgJkQQDIYKgJ+gIWvKp IahJqSIoCQqCSBAIjAAyWIAwQDhGOEo4QjhM+Dvhe8J38rLsb/KO2Lek/IbwNeGvhK8IhwhfEv5C OEj4gvA54TPCp4RPCB/Teh/548yIPxM+9MfhBWMfEP7kjytFvE844I+bgfijP64c8R7hXcI7/rgK xNv+uErEW4Q3CW+Q69cJr5GzV8nZfsIfCL8nZ7+jea8QXia8RNhH2Et4kea9QK5/S/gNBf88YQ+t 95w/rgyxmyY8Sws9Q1E/Tc52EZ4iPEn4NeEJwk7C4+R6B7nuJ9ePketHCY8QttNC2wh+Qh8t6yNs JTxMrh8iPEjYQvgV4QF/LL532f3+2OmI+wj3+mPnIO7xx56OuNsfOxdxlz92AeJOf6wVcQeZbCaT TWSykUxup7HbyPJW6t1CljcTbqIJNxJu8MfOQ1xP068jXEu4hkK6miyvIssrCVf4Y+cjNpDlesLl hF5/TD3iMn9MA+JSf8xZiEv8MWcjLvbHzEJc5I85E/FLGvsFWV5IJhdYtyIPGSvSv4ysSj8QcXr6 MyhPo+xCeUq/MN2P0ofiQ9mK8jDKQygPomxB+RXKAyj3o9yHci/KPSh3o9yFcifKHSibUTahbNS1 pN+CcjPKTSg3otyAcj3KdSjXolyDcjXKVdqW9CtRrkDZgLIeZbpWOCochoWQLhxBtkA6W+cfwR/H 8/3R/Gp5CZ3+KH61PIRzCR0EN6Gd0EZoJSwnnEOYQpjsN3FMIkwklBImEEoI4wnjCMWEIr+R39Ox hEJCNCGKYCIYCZEEgx8PpZ9FEPQEHUFL0BDUfgM/apX1TORfUA6ifIHyOcpnKJ/icf4R5T2Ud1He QXkb5S2UN/FY3kB5HeVJlF+jPIGyE+VxlNvxKG5D6Wc9lOnV/ih+5VdRclYSugkrCF2EGYQyysN0 gpUwjTCVcBptOZYQQxjBsUMURcFvTb/7SVGA7Si7UUQRKJbzCLV06gsosvmEeYS5hNMJcwizCTWE WYRqQhVhJqGSUEEoJ2QSMih4iZBOSCOkElIIyYQkQiIhgbYZT4iz3oo8hnIU5QjKYZS/4wF/j/Id yt9QvkX5BuVrPNW/onyF8jHKRyh/RvkQ5QOUP6G8j6e7D2UvyosoL6D8FuU3KM+j7EF5DmU3yrMo /SiP4Yk/ivIIynaUbSi38tMXjlGO1xLWEFz+KPxWiLUQllFamglOQhPBQVhKsBMaCUsIiwlnE84i nElYRGgg1BPOICwk2Ah1hAKChVI9hpBPyCOMJuQScgijCNmELDqbkQQzQUlQEESCQGD0RIL1TmQA ZQDlE0zsayivouxH+QPK71F+h/IKyssoL2Gid6BcJGal/1K0pP+CWdIvrOqxXbClx7auaq3t/C1r bfq1k9fWrBX1a5MR563dsvbttao1Vatt521ZbVOsjlkt6FZVddtWbum26btZxIqqLltd14dd33SJ MV11XU1d3q7ruvajQn131/au3V1if2CXNbqrdHJlT9dVXUIMjgvQxYxcndGlj6z0VnlsnVs8NoVn nEeY/I2HHfAwodDD5nkaPQJabfOMzKnk1uM9cUmVJk+hx+oRz61y2zq2uG1z3W73Ovcm91Nu5Tr3 lW5hK7YEq1trqGyvarP9sY3BE0IATCi7hIBf1Ll3CgPA4EthwBpgyzEB52AiXJZltpYty2zNliab c0uTzWFZarNbGm1LLGfbFm8523aWZZHtzC2LbA2WetsZaL/QUmezbamz1Vrm2xZsmW+baznddjrq 51hqbLO31NhmWaps1VuqbPOq2ExLpa1CLEnHryCQhn860nrSDqUp9I2pHalCR+qB1EOpYkfKoRRh XTIzJq1LujJJNOKHQB+J6YlXJm5K3JqoNMoNMaIjuida6IjqiRIKo6xRr0QdiFJA1OYowXilcZNx q1Gca1xi/NIYMCq2GtnWyKciX44U50YuiXRHisZI3hdN1kjL2EqjId1gnVlgEKcUGKYZ5hrEKw3M arAUVVoNI0dVTouYG7EkQtwUwawR2bmVX+oCOsGqw4EvtQGtENAyEJnEGDATQtTwM2Kx6ZV4H7fF MSXDby366mrz8mr61YEFNT7NvDN97FJfVi3/tM5f5FNd6gPbojPr+xi7oqGPCTPqfDH8PxzL/Ys2 bICy1Bpfam29b3NqQ42vBxtW3ghgA1L74qCsIW9xZ1dnpzevMw8/UBZ3osbbhX9kMPxEdnn5iLcT 0CTvBwq36OToko06u5Z0oQ8cQHWnrOa9xbLJD/n4r5Yf3Ml/o7Cfc/H/2yVhyWIA9UaAgWuH/D32 BVhvgy3wCDwOT8ML8Af4mumgES6Cp+AD+Az+CkfwMVWzWJbCcn+av7rnZeAXyjYwiLtAxf/P08Dh wKcDDwQ+BVBGDtFci714RfZxTSA6cPBE3cC1A/0DL6n0YJLnmoQXUXuIHQwcFqbxfqCE94VLeFue cUi9cWDrwKZh4XSAB7pgJayC1XAerIXzYR38Ai6GS+BSuAxzsQ7bl8N62ABXwJVwFVwN18C1cB1c DzfAjXAT3Ay3wK2Yx9thI2wKjvH+Rqw3yKN85E64Fx6AB5F3wd1wD9wH92P/V5j9B+Fh1JGG+g+h ZjPcgdp7UcutuG4rVh/0gR+2wXY8M+qHev2wCx6Fx5A78DR3whPwa3gSz3EXnuwzso5rQv0ftqTP Z2E3PAd74Hn4DfwWb8aLsBf2wUvw8r818tyghvdegd/B7/Gu7YdX4TV4Hd6Et+E9+CMcgD/hrfvi pPE30OIttHk3aPU+Wv0ZPkXLg2hJdmTzjjz6iexhP849AB8yDXzLBDgCAWzx07tBPqGb5XPkp8dP 5245z/w8tmKfn9B9g2fzEOb4ITxP3uPtW4Kn8TDa9mEGQ/k7ddZeCp4O5fsJtOG54CP7grl4PngS 3M+Tg3NflMf88rxnBr0ezyjt8NUh2XlnSA7/DB/JmaHs0ejx7HGLD9GGZ5n7GJ7bP+Fcyj6fy/VD 5/Cxt7D/Kb4dvsBMc34un8Tn8PFg++Pg+EH4C3wJ38qfh+ArfJ98Dd9g/2+oOYS9k7Unar7D+j38 HQ7jCR6FY0N6x04YOQYDeMbAGBOYCAPHW8e1sijwWwwVvtM0TMt0LIIZWCQz4rci6hNG9IMjUSeN RJxiTCtrotkIFoPvy3iWwJJYMr43U1kaS2cZLHPIWOLgiIQjZjaSZQXH4uSZiYNz09EifohtLitk 3fiZxyysANtj2Tg2nk1gE1EzBvtF2J+EY4Uyy2AeLIVWOKz8RNiL/mPwrdLHf3fbQKf4Nr4xRVDD RJgDp0PdE2Bgt+NrdRJ7cXt5uWaM+knsCiCxF0GD6bvdOkIhGJKTp5nHq9aL86Oqp6nXC3Uw7dh7 7+7Bj33REwv2sYJ3D7520HRsT9TEgoP7D44tZFEZUbLERApqtUplzrQI40dllxQXF00Vxo/LNmdG CrJuXMmEqWJxUZogxoQ0UwXeZ+LbR+eKFcdGCqsyJteOVbK8rPj0ERqNmJ5myCqWjDVzzCU5SUqF RiUqNepRJWVmW/eszJd0CaNSUkcl6JCpKchjzygjD/9VGXnkDEX5kSeETybWTx2pWmXQC0qt5vac tNiRY1NOqzEYDcrI5PikFLUmKlI3usp+7OakrHidLj4rKSWL+8o6NhkzsgFAwX8fXTSkw7n8209b /VMwQrgVv5AkCdeAFhICn2zXG9nsBPy5zqqNnJ+cwHvJ/Gc+q7IOEqYlzTmYN+1gHqMkJe/40TPG FjbwVJozMrPHR40rKc7ADCnHWQSzOYpnVLHr7If//uDAixljxmSw2Q99dc/CgUN5S65fddFlrdc5 xgq3+I9trhmVr2jJHzV/02d3nbXRO/3oVaXn3o8/z2wIHGbXK2MgFkbTjnYACNc9YtWZFihtuP40 VoAhYKzbQgoMJSt0VlHBw4pl1xvSikZlF6cZDOlF2aOK0gwjdSadSoUfij2hFtB6qnMxh1PgTVrP qjcUFsYXFOgsCQlJ/ULT9pFjIyJ02HgMRpbMT4zQJ+xkY8AKlsCh7SazMHtsf+CQVeKteBP/NNBn fEHhWIsqPWd+ui3aRoFOmxYdP5F/B4QbKCoqwp3sP1gUVWziH1ETTysoLo4qxo098tOuMiw9ZhYp 8tYoZo46njP+FKQJ8ayY4dWX06c6V59amDWyMCVCGLhMEZ1emJlZmB4tDtwg6NMKUJ+qLxnzoKWs UIpgCQqWaUjPLc3qSx6VOCTLqUc+NETpRKXepFekHPlgUH9BcYnRPHH00WMiGz1ppDESZ/F/DTsv 8KkyUZkFI2DU8bscIzyDdzkNP3WQGLyZif3sLKvWWGuWb6aZ/+cPq3Lhqe7yj50RustDHnb5KuMr ITYmTeD3WZk4b+OnN9/4/g01yFuuff/GOQNfSHN6Gu0XzsuQZvfYOYUb7hjoO3vunYe33H7Et/j0 O797tPm+7unVq+8685wHVk6rWnMPf2IDhxVz8LaVQDncTrvcbrJE5ep2CntwpxOEW/2506Lkv+21 mPqD8Zv6WdY2qzX+tJDitH6W+6g1Y3586Mj5RvC1dzBvIu6+aD8mICp64kRMQt+/52XInRklWkTz 8MuSURQXnybG8jdpmhgfHxfHxmWPys4OPfpzNGmTikYXpUYovLE5Y62jFwSfxAh8FcwtLks+fe0Z lgzr4impxWNyRrQZdQMPTSqLKR6z4uLSutKUTL1Rp1DooyJYxtjZxUkDIwbvzY35oxSivuSM7jnT l9dNHRGZM7HaEsg2i03W+milauDq5LHl/B7VBD4V9+L39Nn41eR6yrBfnzxxp4A/dECB4LHqRmRU 6ieOSlZEjg5lYnQ/q7ZqE2aNky/IOOxtt0bOUc7mWQneEXympsk3q4in1ar9d30MfRrHB78MyXcu Ln7w3SVmZw+9exPEvbqE3DQpJ1FfceNZzRsacoqXXrOkZvUU/ohm4SN6uMRRMnZmXmx0bvm4pLHF JRIlUWfUO2YtmHvxNkf3kxdXnTaZ4TOoV6n0Jt2xceVVYxc4x5eeU1tkzJyQw/O2HN+7G5Sn43s3 AypCz1+c8BSkQKzQiM9fOjvvEWuiqZq29Bru6fiTdvLYKV/KI2Jww9n4JRa3y1ZHyOGnRoQ4Ymqd bfJptropmTqjTqnED3E17gEjNupY4exJpdWzJ0/EN/b5+BPVTvF1KIYOirMv29gvNFojIMmoS9cV 6ESDqMNj2aZnc3T9rNaqs+bNyjbGStWxcnj4ZMgnsmTx2axg98GJ8g50/9x+yGuCH4866qT9xcrf OaiEnQqNQaeJSUyLjh09ZmxKaIO6pNx0aXS8zjy1tDTFkCYl6JUKQawZaUnSqTXqqJFT8o/tH9z6 mlDLXTQ92yiqtbqI2NF4Th8FvhJA2YLnlAvpT+AJ9YOEJ3TFo3plVvIcUyVMm/buS8GTCb3sxeMH cML3NO8zXWIeBpWoY0kR6eNzcsalG5SGjJLc3AmSwSBNyM0tyTCw+0MXR1xviDGo1IYRhiNzc0sz jcbM0tzRE81GfKHzr6XxA++we1kGJENsnwn6hSu2RevjU8C0H78fO7hnbGGW/M0XBTVhxGAQ92qi U2IvVkclZCaljjQx5WpT5rgsc1GGsT9n+qQJqbt0kRrMhEnPYjZmjo5Tq+N4HlaJTcJbyu5QHmIF FeghQ1A9mqtMzp5pmol52FeEy77G8xDa9mAi2ODbLVt++GKFZ7WxmUnJ5hhtQkRyviTlJ+sGWrUx 5qTkzFgNftvLldPHileEXkfsKQxIiV/cdAPTh+tiY+Wf5Df+axW/n/9XqvXHVkExrHb/oyrmhOvP Wnf/L1RF4n+03hSu4RquP0v96FRVmfI/UJeHa7iGa7iGa7iGa7iGa7iGa7iGa7iGa7iGa7iGa7iG a7j+X6ny3yPz3/6Wj59KSAABVJAg2gJ/gBr5cxHUBL5g61lS4GO2HjXnoO0YIRNCv+OuSf4UZS+R co+3BdCIoyH0WxQniYpgW4G+k4JtXE2cGmzzNRcG22o4LLYH2xoYLX4YbGtBUrQE2zph8+Baelio uDTYjoDRiveCbYNwk1ITbEdCq3rz4G9KLNJEBNsM1JqpwbYACu0dod+JCKnaK4JtBURobw62ldje EmyrsP1YsK2Gtdpng20NxGoHgm0tmHTWYFvH5g2upYc83bxgOwJidecF2wY2W3dVsB0JJfp3+G+d VGiDeaY25ZnalGdqU56pTXmmNuWZ2pRnalOeqU15pjblmdqUZ2pTnqlNeaY25ZnalOcHQIIiKMRa iq054AIHeMANnSjN4EXdDGx5oEP+tKPGha12sODIdGjFKsEC1C2DFhzrlHtOpBOtV+BnE1rOwHmt aLMUdS60cMl2dpQ29NUk27ZjrxN17fIYzXdhBBKKHe1c6GEV9rqx5cW1uE0XevSi3ok9HnMXzua/ QbEdo+Fe3EGvXrRoC67JLSTco1tek6/SKe+lWt5rM2r4HrtQ75RneGRNqxy1N7gPB47ky57bZE2r 7NGOOSJ9aJU29NMqZ6wjGGU7atrkVckn36d3SAR8xQ55L5TvULYpdr6SGzMg4f4p4zyqNrS14/pe ucd37B08D8oZrSLJsbcH9+WWc7tUtjwe8dAd8aytlOfRrpdj3yLfh6GnOUr21iZ7WCXnoSt48kPz zU+M9u+U4+f7p3PxyLeBk1bkZy2hj47B3VCMy4I2ndhbHfTuxV3QCa0YPCW7fEfsqG0btq/QbXZg JHZ5fUdwfcspbv2kk/YpQRmOtaK3SYNPzHhYGLxBruBdG4/eSnB0+Nwxg3NP/SQ4g3eadmgP7mmZ PEoxOoNZ5HE3ybeZ72G5fI6hOacebf6XnurjN4jOy4Y9lxwDX79WfgK8w862IBiBe8gOHMFn0Svv 0inf79mocUCOfO65aNMk+58pR0VzvVg7MLsFWLvlapGf++GRW2TvbWjjxfvG418m76ADPaxCLT/V Znkv/Gka7jWk528UOoHlg/4a5JjpJq+Sb2CnHKFXftY65XcDzZbkPfDn1CnfMpe8BmVoqTw3lL0K zN9sfEvSXM+QEXrGm+ScHH9uu+W1HPJzfap1qc9tHXiLuuQcNg0+B03yOH/T0A5Cd79D3ml78PaT L6f8yZ/mE/fNx+mtkYOzcuXb2Yb7cg4+xydH1X6S5x+fo+PeQ29uKfjupdvjGPYOPHnvx+/r8Lgm D8kA3wnthb4ShG69Z/CrSpP8Xm2X36/2H9wp5dk+LKfO4O0/8RngWeU3r0ue2SS/o/hunIN+uGWr /J77Ryf0Uz0Xx5+JAjka/gzQVyeLfFYdsPIBqaiwsFSa43J43J3uZq80w+3pcHvsXpe73SJNb22V FriWtXg7pQXOTqdnhbPJMsPe6lrqcUmuTskutbmbnJ52qdPe3inhuKtZara3uVpXSd0ub4vU2bXU 2+qUPO6u9iZX+7JOyY2mXmcbzmxvkhxuT7vT02mRqr1Ss9Pu7fI4OyWP094quby4hqMzX+pss2ME DnsHtvmUtq5Wr6sDXbZ3tTk9aNnp9MoOOqUOjxvj5mGj99ZWd7fUgoFLrrYOu8MrudolL98HRoZT pFZXO67lbpaWupbJjmkhr3OlFye7ljstUnCbozqlNnv7KsnRhZunuL0tuL6zW/LYcS8eF24bJ9rb pK4Ovgx6XIaaTtdqNPe6cUMr+JbsUrfd00Zr8TQ7WuweDMzpsQymflJoTanM3do0iR/M+IWYINyS NN5SUhQcHcNHhxyCEzONC9pxpWUuHpETQ/TYm5xtds9yyc1HhnSbT33UcoJwX7Z2lxfn13rtXtpt ATpwyws48BS9Hpez0zK7y5Fj78yVmpzSTI8bR73ejkkFBd3d3Za2kHOLw91W4F3V4V7msXe0rCpw eJvd7d7OoClvN9txA8u5XYO7C5O8SurqdGIQuCU+LNnxTJ2eNpeXB7R0lRxehW32dBz1yB088aYu OtvuFpejZchcpKvd0drVxHPhlppcnR2tuADPfofHhQYOtHK2ey1SaG13O16NHFeu5Gxbyicdd9Ue Mj5lRLI5v9yY/k5Mj4Nu4ODqcl6DvibLAeS4cBV8CHjqPfxRaXJ3t7e67UMXxZjtFCkmfvAE3F3e ji4vpn2Fy+HkNi3O1o4TNvRjzkI+iYImZ7MdHyeLvbNjZej3oQfmwOOn+B+k+c9hIv7coQMjqAMB /BSCP2EBywH6PfLslPNCJUG8MSKCoQ1r/bH2BoNs7/ux9kajbP/Nj7U3mbi9UPpj7aOiZPs1P9Z+ xAi0T5B/c78Gf97j9vynbL38W9wLwIBekqAGW4tgCkuCanY2LGTroUmcBW7RBmtw5kVoueEEH1f/ Ex9noA8n+uhAH+fjzEvQ8srhPpg0xEck+khBH8XoYzr6mIs+FqOPNvSxCn1cijP5mrec4OPxIT6M 6CMNfUxAH/PQxxL04UYf56OPXvRxC868Cy0fHO5DaB7iIxl95KGPSvRhRx/noo8L0cc16GMT+vDh zB1o+cxwH2LOEB+p6MOCPmrQRwv6uAh93Ig+7kcfj6KP3+DM36PlO/z+atSg0Xy/dw+Wvd9r+A/q u4JFgz9v657u+QDrdz2v9rzb81ussvmaPXJZo1Hh9O/37v3+jb1792qUoFElJKx8A8tKrQBadATk SSWCSnGAnApMo5BbOKYQA4LY2Ni4SxSZRrl582aNivFg5HJiMEyjPzkYptEeD4YdD0arAq06IiJi Dfe05oRoFKBSHpKbWoFpKZrh4ShBq8JtaNVMq6XcYHKGGPOpeqY1HMDy1YHfNb6N9YXGl7BqNUyr m9L8LC/NU7QqppX3IwelUzGdJhTU3jU6gekUg1HtUiuYOhjWLj6k3DUkMBAUPDCFkunUPME6DdPp jg48z5d5fuBo0FWo6CKYLvJAxyEsb/p4fbnw5cI9WHVaptNPhXXwQc/TwfpBzzqYCjo102mPDuzZ cxSj3bNHr2Z6rQrLClTtGVhxYqhKpla98b3c1gtMHwr1xFj1cqx6LdPrByAAzw4u+nTPsz0BGIBh k7kzA9MbD5QeKD208pB8kfbdtO+ml296PuH5BL2O6SOmwbqe94fYv///iDv3+KaqdH+v7LRJ2qQt YLi0IiAgFgRUQGGgIqKici0IDOAZySAqN1FusUGuiuIFEREVFfGWUYQ5iI7OjDIXCoKUCnSgDa1D MS2ai26Spt0EDXNYv2fvhFIQP+P8/jjnrPMkO/uyst7v913vWunozI6ly24UdpvJnqkPfs+//rVn z65dDqvJcW70DF//mibD32FLN9kYfzIjHYrisDT2eEEEDiMCR6bJ4SACxt3ky3cUL5PLzgiHYnI0 jWGHI9vkaO5v629bV1BXUDmrcpbu9hervli1y7HL4bCbHFntxdIdrh38f2Nz7Vi6o71wZJgcSaWM dkb8S+wxjnTFsmymrEwz/zdgaRDXg0sHpL65MawdGemmDOvZuHZkKUrWucD029LNJiVdj2xHerop y6aHVmlU00zxtjJBmO/xzJ0lnPfPvXem6D/rt/Nn8wsuU5juHDO4g15ZWPH0ym2h3jpTn0zCSuVs aZxPnmHOUgdb0cx3FBbeLjqPGTWig7hm7JhhHUiz5D36Gmr8r9vzycw3NG/sPY0a1kLkpj6lC4e4 hMp+6T0PzXtIeI3XzcbrNuP1j8brX4zXnTPZgIu9xusB47XceP3KePUbrwHjVdV3gKJefzVZjNc8 47Wn8TrYeB1vvM54YOYDM01LjNcnjNfVxutLxutG4/Vd43Vr40r4715Nv/DVhpJmNLCgsE3of9X8 vzun4EPWf/yezVrYU4wx/trwqFgr3hYfsWodErWi3kQ9NiK1paJVhf63Xf1/NcZp/C8ZsS6Z+iff nyxPvr/+apNnyLdg3nmfTenzz/9s2Xj+54ynz//saHH+53bu8z9ffsH1jmvP/9x9k8hQmnzuMavJ dYsw3fjx+Z9vVXjPJKfzRSHxZPPMo0h1jVIolipe5Yh40/y6+XVRnjY/7S1RkX7Y8qTJnHln5m9N n2autJtMex3NHLcqNzvucmxUPFlTs2Yof81amrVK+TxbybYph7JPZZ9SqoRpeaGujeVw1raLtn20 8qxjTdo3qbbvIi2S3baxdaT1oQ2kTTXa2gtb1r7sDdlbm61JtVebNK/REhdrzdOaD21sK5qvbmx1 ydai1UVaPq2nc12TtjHZjCsXNOfvnTsb296WX9H8RjtzsdYiv5WjVcfWK1Lt6SZtndF2XrSVtU6c bW2cbfIa2y2pNvSirdBo41Pv57dlqVf9vj1GK29syaePtanL7ZY7NXdj7ia9Xdh77taLtWTvuX/O rU017VzTvyU3YXzXMp3Lhnfq2dgGdRrS2Cak2t20+Z3u7tyF1ueKjlf063Q3rx2v+GOXv1y5z2ih /JG0qV3zaB26+rqq4Ota3+0vV63VW1ffVduuOkb7obvS3dZ9K21vz160W3qOvHpNqn107fzeeb2P 9nni+nxar76OviP7zur3bqpt6/dZv73929G693cP+LIgrrcbFt2w1Wihge0Grku1jTeE+LxuYKXx qXLgd7R1NzoHuQd5b2p16yDantsKb1iUvJv3yuRdd3TR77ujz9BMRO0ydM2wbKP1GzbGaNpwZXib 4R2HaRwV0u4bIUZYRkwdER8RH9l2ZID7+o0aO2rs8EJep+hHtGmj5o5aVmgxWvfCkUZzFc4GV2FR 4aOFRVyfW1g5etJo1+j60fVjmo3ZyH3duWZcGfNDYdGdU+6cNe7Ar2+Z4PvNmt+8+hvv/Y/eXzlt /LSis+/TNk/bPP2a2atnv/lQfI6YM3COa86MOfPnPDpn25ydc76ZE5nzw1zLXOfcbnP7zB08t3Bu ZF6zeV3mPTRvybw18/bM88/vP3/s/I/m+xfkLShfkHBf477PXeR+1f3xw3kPj334o6JpRU8XfVx0 oMjvyfS09QzxrPHsW9h54ZCF0xYuXLhi4bsLty089IjzkSGPrH/ko0e+XGRZ1GbR0EVTF21dFFrc bfH8xVsX+5e0W9JnyYwlTy7xLXUunbR009LAsrbL/vYzVWvbhZXp/Lqz7JtzTa8oy7PPtWQt+ZnZ N/TCOXf+TEnm+kXrz9ka1KSdX0WW9znX9PqwfPC5lqwMejVt5m2zp/U6KnL5wErqp1GNjXcqb/Oh VNq12Ruarcnad7Z6Nl+dVd68rtME/dmsbdlrz1XRpErU6YFGJU7e1TZ7w1n19LNGVdbvLdevG/en FKTfbVnHqOkbeKLc6G0fo1vDe7nRzq0T31ywPgxssiKcWxM26OP+yTrgvXAdoPanper+irMV3+iH p7MHcrz2bC3Ej00pv6hOyQqUrHApH6mK1EDdtQmN9fGso1S5NkP1+8853GkI/ejXNc4X5tby+SfZ QA0sb1JNL1Jjm9bUn9bTVNXeY+RRsoIOOls79ZrOmSF6v3we0qbw+vxRY1ueSa5kxjurVusEa9WZ Vg7WodTKc3ZFadGq5Zlzq08yH/X1Tb+/5Rn9Dp7e2cqhX9HPGGsZZ/RrLVpl7Tubp23yuO7nG+ij 9Qrjk3H+3IradE3Vx2Ssn2dX0MY1lDXTcZE1c91P1syy5ErJGuk8GwvXE8lxGCNZMaxfy6/a3MLY znNDV/HCmXtW8eSM1LVNZkynCag/VPdW16VNoXOd4fwm3akms7tn7tYWrRrX2vJUr8uS+aD7ksyv 3K1XdOzcJUlyVevcxViJmjR9VUuuaMaa+P/ZjHW0SfvpHcbq2qSlVtnG9tMnjNX1P2rG+vuLW+Mq /TPtQqX01rh2/0wzVvNf3Iwdxi9sF6pj7EuatJ/qZ+xXmjQ905NO/2ftpz3/+9H9spbUWd+vZG8o iA/NvCGUVa7vdIy2SD9TENd3N/qnGxYNzdT3PclremPX1F3fKSXPGmvRd8lm7IgGGbspfd9UObDS 2BPp+6ZKnlhk7EcsjfsWvXUvtIyaUmjR9yzGp+6pnU3yuDv7nmn6GWN3w3P6u970+3nCYvTmMq52 119zt3J3d33/1MoxLHvUFH2vpe+zjNbPOJOt77OMT/1GTdErUeoaTS8T+o7M2KEpxt6Mpt/PE/oO jjv13di5/dmwfgO/M/QI6UqMrk/qUBA3omG8yXEOL9R7NvZ7it5Xst/z5+FP/WyaBVfuS34SFtMO ecA8Qv7ePE7kmieIHPNcGTT/TXQVCldK+VRpHKnmcTIoTLz+KBT9n3czT5CH+W2+RcbF5zJucolO pt+KcaYpvN8j8k1TRTvTTNGOO0dz52TzLFkiTPTzrUjj3hzubce9OdybafSncldMZJjuFnlc78H1 yVy/mus96KsXfeXz9HvGeOwcfcR425kXyWLzYvkG4+1tPi7fMn8jepi/Fb3MQa6FZaX5O37tnh1t rUjjqD1H7RjNFno6LIpEjrhONIP+4nIxAKbS/71wH8yT1WI+o1oAbngYisDDL9yFcrd4BBbBYlgC j4lcsQIehydgJTwJT8HT8Aysgk/5Bf4Z/MDxGZAi1yTABIWin2k0jIE7YSxMF6NMe0RrIp5sHi8K zHcJh3kyzBKzzUuJdLnoZH5MtEt7Q+5OexPegkMiN+0wlEMF+OAIVEIVfAX/hKNQLXLTm8nKdL/c nf69SEtXOT4BdXK3JV1cZ+nKe29xueV63mfJSssDMBsehAWy2uIGtLGgjQVtLAsBbSwfiH6WbfAn OCX6WbuJ1tarYLLItbpgCsyBueCBZbAc0Mi6Bp6HN+AtkW/dwvsJiEAdxKAeTgEa2u6BqXAvLBCt M4Tol+EUrY3cjZDXmcZRGNd/EC3J2n1k7T6yrRPZNoxse5Rsm0S2TSbbCsm227l7B/ky2DyeXPm1 3EzejCNvnqSH+ea/yVfNx8mzb0WmOSD/bg6LYUaeBbkrIJo3zoq7RUGT/ifT/zz6H0f/N3H3lFTf n/PUDfT9Jn1vSfVXKLKb9JJJL33pZTa9FNBLQWpO9GWUQXq6k56ep5dCevi7EemfjKM29PFX+vgr feSbJsvP6KeAfqbTzzD6mUQ/Q0zT5SH6KjCtl5/w5Hb6a0F/HkY2jz7zGJmH3taaa2WM0X1uDjGz wuTcd6kZm9Vkxvag116p2a/P2AqerGbmjZCvk7/2ZIXR/6bL+SrxinhMqmIFPA5PwEp4Ep6Cp+EZ WAX75GlRCl/CfjgAB6EM/gGH4DCUQwVUQrU8I47B1+CHGqiF47JMfAPfQr08IhpkjdDgJMThFPwg K8SPzOkEnIZ/wf/AGcYipWoSYDKqYsA8SdaZ/0vGzXfz7pLxtENSTTsM5VABPjgClVAFX8E/4ShU Q0ieTgvDd/A9qHACIhCFOohBPTSABowl7QxI5mwLWWYdJE9bb4WhMAxGyhrrWN7HwSSu3wV3y93W yVK1umAKzOTaHN7nwnyOH4Yi8PB5Ee/LeF8OT3C8EvDB+hzva3h/Hl7geB28CC/By/T/Buff5tjL 8RaOP+B4O+CRFY+seGTFI+s/5RnrUcAjKx5Z8cjqZ4w1UAt4ZA3LI9bv4HtiUeGErLBGIErfdfQd g3rQuBfvrHHOn+IzHtnugalwL34pYrVw4lRCmMVqWdW4eqXz6VM+reLTYrK80nxQdBQmzsbFLWSm j8z0kZk+MtNHZvrITB+Z6SMzfWSmj8z0cfcxMu00mXaaTDtNpp0m006TaafJIpWMiZMxcTImTsbE +b79fJ/f/Btmwm9hivzWfI/8lqzxkTU+ssZH1vjIGh9Z4yNrfGSNj6zxkTU+ssZH1vhwMo6TcZyM 46IPF304F8c1H675cCuOU3Gc8uGKDzd8qH4a1U+j+mlUP43qp1FVRVUVReMoGkfROCr6UDGOij5U 9KGiz5ix+4UVLfsxky2sva+z9q43l4nLzf8QLcysNoa+wZS+NYa+T/HpV3y6GX2L9L2FmMA66WSd dLJOOlknnayTTtZJJ+ukk3XSyTrpZJ108k09WCvzWCvzmLPHmLPHmLPHmLPVzNmTzNmTzNmTzNmT zNmTrKc5zNkq5mwVc7aKOVvFnMVvqu14kc88PcE8VZmnJ5inqnmK6G6+B2aJqal1tD3rqJO108na 6WTtdLJ2Olk7naydTtZOJ2unk7XTydrpZO10snY6mYtVzMUq5mIVc/EYc+8kc+4Yc+4Yc66KNc7J GudkfXOyvjlZ15zMlSrWNidrWx5zpYr1zUn+HyP/j5H/x8j/Y+R/NflfTf6fJP9Psv7lsP7lkP9V 5Pwxcv4kOV/FGuhk/XOy/jlZ/5w4NUGe0LOeGJnb7NJWU73HsXaNl8eo6q9x/Un8+ISr75LzvcyH OGZWmitYx3QPj3B3NXdVUqlXyyV88vBsFc/qZ6em1sH9PNuDZw/w3BBh4c53uXMxd9Zy59fcOcPY ZemZs9no6S6uj+D6Aa7rOTKYnlZx9S16yqenz+mpu3G/auwWjxuvcda/HPaCk2AWPAAPwkMwB+bC fHhaXC2am3YYc30Dva/Vv91w9k3YLvqYi6GWfe5xMYS9Yg7rt5O9Yq45xHuYndV3nPuenZmZJw/w RCt2lrn6ys7zs0QB69gk9l13iULz3cYejFWakeUzsnxGls/I8hlZPiPLZ2T5jCyfkeUzMrKP77iL HdvdvE8Ws40nnTzp5EknTzp50smTTp508qSTJ5086eTJXjx5E0/24smbjCdzeDKHJ3N4Mocnc3gy hydzeDKHJ3N4Mif15LDUk/oe5S4cm8y80jX+zNgpJFCrVv93LljLR8MYuBPGigx2cBns4DLYwWWw g8vI0P89jTQUbqH/+y0oPNzYj+sefSPKTfnyuKkrdIOroDv0gJ5wNVwD10Iv6A194Dq4HvpCP/gV 9IcBUAA3wEC4EQbBTTAYboZb4FYYArfB7XAHDIVhMBxGwEgYBa/KWtNrsAE2whvwJrwFb8M74IXf wbvwHmyC92EzbIHfw3/DVvgAtsGH8BH8AT6GT2QDitSaimW1aSfsgs9hN+zh/BfSZ9oLJbAPSuFL 9hP74QAcZN5OInPvlofTdsuGtD3wBeyFEtgHpfAl7Gc1OAAHpS+9uaxNd8rj6S2hFbSGNpArj1ue g1dkrQUNLBulanlXNljeg03wPmyGjzm/i/fPYTfHZdJnOcz97FsscXncepmstbaD9tABLpcN1o7Q CTrDFdCFleNKyKdudYVu3HcVXAu9+NybawNYbQp4HyMbbIo8bjNDGqSDBaxggwzIBDs4IAuyIQea QXNoAZeAU9baWkIraA1tIBfy4FJoC4zfxvhtjN/G+G2XQ0foBJ3hCujCmHqxb+gNv2Ll6w8DODcI hsBtMJnvm8L7fVy7n/umwXSYAQvoYzEsgaWwjHuf4/w73P8e92+S1bb3+bwZ6jl3Uh7PMMnaDGLN uET6Mogjo6VUMzqQQ0UmhWwxQxqkgwWsYIMMyAQ7ZEEzGTQ1hxZwCTihJbSC1tAGciGPDGsnT5ja Qwe4HDpCJ+gMV0AXuBLyqTVdoRtcBd2hB/SEq+EauBZ6QW/oA9fB9dAX+sGvoD8MgAK4AQbCjTAI 9Ho2GG6GW+BWGAK3we1wBwyFYTAcRsBIGAWFMmwaDWPgThgL44hvPPwaJsBEWEwsS2ApLIPl8Cg8 BivgcXgCVsKTwK8O0xqZMD0Pa+EFWKf/d+HDS/AyvErNfA02wEZ4A96Et+BteAe88Dt4F96DTfA+ sBqatsDv4b9hK3wA2+BD+Aj+AB/DDmp5MeyEXfA57IYvYC+UwD4ohS9lhCoSoYpEqCIRqvRKqvSD rAO5VP4C1oFcqn8BVftIGhUvjYqXRsVLo+KlUfHSqHhpVLw0Kl4aFS+NipdGxUuj4qVtlSfSPoBt 8CF8BH+Aj+ET+DN8Cp/BdvgL/BX+Bn+HHVAMO2EXfA77RU7aATgoctKbi8x0p8hObwmtoDW0gVyR bVklT1iepQo9x/FLHK+XQcsrItOCB1SziOVNrhGL5XdcY8wWxmxhzBaqtOUDGbZsA8ZrYbxUuYjl j9z/J859yvXPgPFaGK+FcVoYJ9UvYvmCe/ZxrZTPX8J+OAAHoUzkWA7z3fzCs/ALz+Lj3BGZoFJG LF8xNn7VWYI8+z3HKsfssS3ssS1R4JeLJcb99dAAGpyEOLGdkmFrtjxhzYFm0BzayIQ1F/LgUmgL l4lMaztoDx2gC7vCKyEfusK1nOvFe2/oQ+XtCwNkxFogcmyKyLaZIQ3SwQJWsEEGZIIdHJAF2ZAD zaA5tIBLwCkybS2hFbSGNpALeXAptAXGaWOcNsZpY5y2y6EjdILOcAVQZ2xXQXcqYg/oyfE1VM5r Oe4lI1TiiK0Px9dDX+inV2bi6A/DOR4BI2XQNornJsqEbTJju49r9/PcNJgOM4Bfujb2lbaHYTHf uwSWwjLuf4rvY85TqSO2l3hfT1+vwKvwGrxHf5vgfa5vhi2c07jvJM+elokMIcMZJpGZYaNyo2FG Ju/NOX+JyKGaRzJYlTJac64N5MoTGXnQVv+LpD67U3upp5iVtca+7O+N51dw/jHjLyj6Hism0pXb 5XjzCP0vUyJT/6uWca27co0MKH2grwwqN/J+uyxX7pC7lWEwQpbRUyU7igA7ikDmBLk7cxKs5PhJ eAqehmdgFTwLq+E5WAPPw1p4AdbBi/ASvAzr4RV4FV6DDfA6bIQ34E14C96Gd8ArA46rZECYGWlc mcCvYX38Axi/xvg1pb+sZPyacjPvT8ka5WlZQ93qQM3qwJ27M++UlZljYTz8F9wjazJnwCyYDQ/B fFgpNWLTiE0jNo3YNGLTiE0jNo3YNGLTiE0jNo3YNGLTiE0jNo3YNGLTiE0jNo3YNGLTiE0jNo3Y NGLTiE0jNo3YNGLT7ENljX0YDIcRMBJGQSGMljXEruFhX3kEhyoVw0e53fhbRHti30LcW5S75HZl KjwAT8kSNCjRf40Q+xZi30LsW4h9C7GXEHsJsZcQewmxlxB7SWaR3J7pgUdgOTwutzOuEsZVwrhK GFcJ4yphXCWMq4RxlYibcMCNA27GFsABN+NLkEExMijGOL9iJLWMpNY87swpxpuT+jXTI/Vrpkfq b4SVZFeM7IoxulpGV8voahldLaOrZXS1OOPGGTfOuHHGjTNunHHjjBtn3Djjxhk3zrhxxo0zbpxx 44wbZ9w448YZN864ccaNM26cceOMG2fcOOPGGTfOuHHGjTNunHGjQC0K1KJALQrUokAtCtSiQC0K 1OKMW9yMCi5UcOHFQVRw4cdB5XaRR/QTiX4ibvXk1+tbqd/QvVPr6tWpdfXq1O9iF14dxKuDeHUQ rw6ixkTUmIgaE1FjImpMRI2JqOFCDRdquFDDhRou1HChhgs1XKjhQg0XarhQw4UaLtRwoYYLNVyo 4UINF2q4UMOFGi7UcKGGCzVcqOFCDRdquFDDhRou1HChxkTUmIgaE1FjImpMRI2JqDERNSaihktY yYUYEXcl4iVEvJiIWxLhg0R4l8hFow/R50O0KUObMnTIQQP9Pz/aTPwfEv+HxP8h8X9I/GXEX0b8 ZcRfRvxlxF/GOMoYRxnjKGMcZYyjjHGUMY4yxlHGXJmO0ufXu3rRQxlNlk6g1k2nzs2gxs2EWTBb Vhh/uThb6xZTM5bK3fZHZMC+CBbDElgKy2A5PAqPwQp4HJ4AaqOd2minNtqpjXZqo53aaKc22qmN dmqjndpopy7aqYt26qKduminLtqpi3bqop26mJ0BmWCn5pmMv37pY9eY41XM8SrmeBW62dHNbsye IlnF3K1i7lYxd6uYu1WMXWPsGmPXGLvG2DXGrjF2jbFrjF1j7Bpj1xi7xtg1xq4xdo2xa4xdY+wa Y9cYu8bYNcauMXaNsWuMXWPsGmPXGLvG2DXGrjF2jbFrjF2vWRPkUdSuROHtjTVLj+io6EVEXq5/ y/UEbsRxI44bce79inuv4d4CZkomkeYzUzKJNp88elav/TgUx6E4UXqJ0kuUXqL0EqWXKL1E6SVK L1F6idJLlF6i9BKllyi9ROklSi9ReonSS5ReovQSpZcovUTpJUovUXqJ0kuUXqL0EqWXKL1E6SVK L1F6xXVE4sGb/XizX5kuWuHPfiK4lxmgMgOOE8mzRNKWSLoRSVsi6UYkq4lkG97tx7v9eLcf7/bj 3X6i8hCVh6g8ROUhKg9ReYjKQ1QeovIQlYeoPETlISoPUXmIykNUHqLyEJWHqDxE5SEqD1F5iMpD VB6i8hCVh6g8ROUhKg9ReYjKQ1QeovIwjycY87gfURwiio9T/3msvq94V9iJt4R4S4i1hLhaElNL rnxAPCXEU0I8JcRTQjwlwqIswGM3GfywDCsrePpZ1ocX9b+xc/ZHZYWMCxOvp0RX7jilFHHOY5w/ qDwhMpSVPM1eXnlJNFPWc/4V+aP9UmgLl0E7aA8d4HLoCFPhXrgP7odpMB1mwEyYBQ/AbHgQHoI5 MBfmwXxYAIzP/jAwJjtjsi+UPxrx/MhIA8piGSWWoLJORpSXGf8kZS51bR4s4GwRUXpgqTykLIPl 8CisEJcpT8i/Kc9x3xpZrTwPa+EFWC/3Et9eu0ItM0MapIMFrGCDDMgEOzggC7IhB5pBc2gBl4AT WkIraA1tIBfy4FIZQ8MYGsbQMIaGMTSMoWEMDWP2/vKQfQAUwA0wEG6EQXATDIab4Ra4FYbAbXA7 3AFTieNeuA/uh2kwHWbATJgFD8BseBAegjkwF+bBfFgAbngYisADC+VekUbm1KCiHxXDykvyNLm0 Qn5HnpwShbig4YLWJJMqWHEirDgR7oigsqbou7R7ZIQVJsIKE2GFibDCRFhhIqivob6G+hrqa6iv ob6G+hrqa6ivob6G+hrqa6ivob6G+hrqa6ivob6G+hrqa6ivob6G+hrqa6iv/dsMHso4hsFwGAEj YRQUwmiYSh/3wn1wP0yD6TADZsIseABmw4PwEMwBtEFdDXU11NVQV0NdDXU11NVQVxM21P2aDI+T 4aqyhBxeIZyoXYvatagdEw+hcTEaF5PpAe48gNYBtA4oC5mpi3FiCU8ulXVkfh2ZX0fm19GLBR9K 8aEUH6LKairmGnmcGXCcGXCcGXCcuVRObSjBowo8qsCjUjwqxaNSPCrFo1I8KsWjYjwqxqNiPCrG o2I8KsajYjwqxqNiPCrGo2I8KsajYjwqxqNiPCrGo2I8KsajYjwqxqNiPCrGo2I8KsajYjwK4FEA jwJ4FMCjAB4F8CiARwFmSB0zpI4ZUscMqWOG1DFD6pghdcyQOmZIHTOkjhlSxwypY4bUMUPqmCF1 zJA6PC7F41I8LsXjUjwuxeNSPC7F41I8rsDjCjyuwOMKPK7A4wo8rsDjCjyuwOMKPK7A4wo8rsDj CjyuwOMKPK7A4wo8rsDjCjyuwOMKPK4Q03FQxUEVBzX83o6LGs4dxbkozsVwLoZzMZzT/W+N/5/i nop7qvIM557F6efkVhw8gYMncPAEDp7AwTocbCBPDuNiCBdDuKjiooqLKi6quKjiooqLKi6quKji ooqLKi6quKjiooqLKi6quKjiooqLKi6quKjiooqLKi6quKjiooqLKi6quKjiooqLKi7FcCmGSzFc iuFSDJdiuBTDpRguxXAphksxXIrhUgyXYrgUw6UYLqm4pOKSiksqLqm4pOKSiksqLoVwKYRLIVwK 4VIIl0K4FMKlEC6FcCmESyFcCuFSCJdCuBTCpRAuhXAphEshXArhUgiXQrgUEtfgUhyX4sZsXCFy cCGGCw240IADcRzQfzc1oG4D6jagbgPqNqBuA+rGUTeOunHUjaNuHHXjqBtH3TjqxlE3jrpx1I2j bhx146gbR9046sZRN466cdSNo24cdeOoG0fdOOrGUacBdRpQpwF1GlCnAXUaUKcBdRpENypDgsqQ oAp/w3qeqTxDFKuM/GH0HL8E67n+ikww4xLMuAQzLsGMSzDjEsy4BDMuwYxLoHUCrRNonUDrBFon 0DqB1gm0TqB1Aq0TaJ1A6wRaJ9A6gdYJtE6gdQKtE2idQOsEWifQOoHWCTENrf1o7WfEKiPW61eQ WRBkFgSZBUFD/7Mz4DmyfA3V8HlYCy8AO3hF/8vGz2e7Hz/8+OHHDz9++PHDjx9+/PDjhx8//Pjh xw8/fvjxw48ffvzw44cfP/z44ccPP3748cOPH3788OOHHwVVFFRRUEVBFQVVFFRRUEVBfTYEmQ1B ZkOQ2RBkNgSZDUFmQ5DZEGQ2BJkNQWZDkNkQZDYEmQ1BZkOQ2RD8BbMhgEMBHArgUACHAjgUwKEA DgVwKIBDARwK4FAAhwI4FMChAA4FcCiAQwEcCuBQAIcCOBTAoYCxxkfZldaI6xur1zoqDntJtFfR /n+nokyFe+E+uB+mwXTAc2JUiVElRpUYVWJUiVElRpUYVWJU7XouLAA3PAzkGzGqxKiyx3UT0bk5 ozLjNeqtPtPj1NT4v5sj7N3d7LFXkMdPkK/PcLyKvdJz/Pp+SbQQI1EugnIRY1e+GJZw1wren6Lu Pw387mNu6qtzjKe6GrvbFzleL+tRuJ7sjpLdUbI7SnZHye4o2R1F+QjKR1A+gvIRlI+gfATlIygf QfkIykdQPoLyEZSPoHwE5SMoH0H5CMpHUD6C8hGUj6B8BOUjKB9B+QjZFyX7omRflOyLkn1Rsi9K 9kXJvijO1ONMPc7U40w9ztTjTD3O1ONMPc7U40w9ztTjTD3O1ONMPc7U40w9ztTjTD3O1ONMPc7U 40w9ztQbv1ZOoVRp4++WmDAbv2v4JY1Lp8U4tPWhrQ//ovgXZS09ydWjOGFH3xD6hoz69xwuraOi vMhOaT072FdkGF1D6BpC1xC6htA1lKmvDYr0oasPXX3o6kNXH7r60NWHrj509aGrD1196OpDVx+6 +tDVh64+dPWhqw9dfejqQ1cfuvrQ1YeuPnT1kVNRcipKTkXJqSg5FSWnouRUlJyKonsI3UPoHkL3 ELqH0D2E7iF0D6F7GN3D6B5G9zC6h9E9jO5hdA+jexjdw+geRvcwuofRPYzuYXQPo3sY3cPoHkb3 MLqH0T2M7mFDY13379H4B9FC+YRMLpa7lZ3k5S45X/lCvqM0yK+Uk/Jp5Uf5D3OWrDX3kN+br5ab zH2kv/GfUx4v8sy/Fjmpf165Fre8uLGVGbaT7N/FHvZznNgNXzDT9uJMKccH2IuW42QF7z4IiZZK mFXsJM/Fef4UJPg2Ib82W8EGrI18e9B8Led7QW+4TtaZB8jjDpdUHffKEsdMoD44HuQdNRyo4aAe OB7hfbEMOZbAUniMc6s49yysBn7vOF7g3Dp4mWOyx7GBPrwy7nif/j+AbfJ7x4fwEef+wOdPeScm Rxnn/gGH4AifK+GfHB8FP/edkF87GuCU/DrLKUNZLaEVtIcO0JnzM2RJ1nKOGVfWShnOelZ+n/Ui vALvsGMZmlK1Bo9Oo+oRVK1G1WpU/R9UPYqqQVQ9gqr1qHoEVY+gZgQ1VdRUUVJFSRUlVVQ8hYox VIyhYgwFoyhYg4JHUPAICtag4BEUDKJgEAVrUDB4gYI1KFiNgtUoWI2CQRSsQcEaFKxGwWoUPIJ6 UdSLol4M9WIoF0WxGIrFUCyGUjGUiqFUFKVUlFJRSkUpFaVUlFJRSkUpFaVUlDqSUqoGpapRKoZS MZSKoZQqLlc2y+nKJ/L3KLWHHPwXCm1FlZByTM4lz5YpYfkumT1d0eRnZPYk8qzabJaVZot8zeyQ TxqZ7pRXm9uLGeYr5EqyfrC5p7wH1XaS+cPJue3mgfId801yauovUtWpfyp5hnm6/DuzYLtw8O0+ fPLx7V/ybd/gxQG+rZbeVXpsoDcfvcWYQwOYQzeJbMYd56lDPPUjT+nzI854e/F0ZWoGhhjXCcbV lh589BCghwqRZUS6i53TF3IbT/TmiRq+7yhPHSai0zxZw1PtU09V8tTX4jIyKspTETKpgUxqIIu+ J4s0sijMd58ki8JkUZisCJMVYTIiTEZoZIRGNmhkQ5RsiJINUTKhgUxoIBMayASNDGggAxrIgDCO hXEsilsN1PiQ6MxYsojXy75uM9/7Z8bwKeyVPxj/DO8EMqBIRug/QP8B+g84XuHzRhmhn4BI46kf Gfl9PFGhO0vd2Cz34fnXnK3g7AGF7Pp/xJ0LeBRVtu93d1V3J5XuNEJ4BBTE8NRhlPgaX8fDecg4 juNrdBhURkf0DA7qjAZEnmrwwcMA8tSgwAhBCIMcJc6howkIxgBahDSPiqYJhNBNTCdxJyQBAr3v ryqRD70z91znzHfv5/f7qrt6V+291157rf9q6Ypjv0PEizRsd6/az333i1H0mkPr59lLUa7YRO/T 6H0aV7ZhiRYs0cIdDrp3U5ub9LMPi+zneAAslc8dC/CgcnccbzAgTU3SyKkaOVUjp2oZKlsbAANZ 4yG8HwrD0FdXse4383qEOsFobmU0t7Lnolj3FNY9xZ6LYuFT/j+INP8fAaWGFab5p/B6msrBEjlY Iod9F8XaLVi7BWu3+Ofx+ULOLYKlvF8Gb3Ddcu71Nsc/Y7mNUKiy/Ts4fg5fgAkV8CVE+KyK4xGo VtkBoT4JeFR+wAs+6M/7QfC4OsUK5LD3oqxmS2AJK7IUlsGb8JbKJyNvczyxmpW+haiTIOokiDoJ Vv1f2eEJdniCHZ5gNyfEhayHxPZxbB/F9lGuCpwfm5i7ZO6SuUvmHWXeUeZtzzXKXKPn4spfiSmM VTLO6PkxwmXQ4wQ84CVWP8TqZ7P62e6PWdEi2MZu3SF6uD+Fz4ghu/HTcs7b8cMiK1ZQfX8JX0El ROCQesVdxbEajuJ/NRyPQQyOixfwlvfdX/O6DuLco55jAzTS7zcged0EzWoSMSlMxI4RsWPs3nF2 bHK3c+4MnFX73AmOil3tAjfYcUvH2zy89qr38MgsLcXZ9TPY9Ye1oFqkdYELoCukqRF462i8dTTe OpqcukHrrVZqffjsQugnHtT6c7wEMtTtePLtePJ0bRDvB8MQNQqPHqVdyusfwTB1N7Exi6jyBau2 nlVbz6qtx9vvJE6GtGtocy38RH2gXcfxerhBrdZu5HgT/JPKYVeM1v6Z1yPU8+yMx4inR4in9r/M nqyNFn21MTBO7bG/I/ePU+X+x+EPIpVdksoOyWaHpOIlE/CSCXjJBP8LfP4ivAqzYDbMFT38r0EO zKP9Ys4tgaW8XwZvcJ9c3r/NcYVa5F8F78BqtcG/Rq0ki632r+d9PmyAP6tR7KpRZLbVeOB6PHA9 umAD2W21f7P6wF8AH9JuC+cK1e3+j3j9MRRxfgfX4Vv+Uu67i3O74XPOfQEmlHGvvVAOYdofpK0F FXz2JXzF+UqIcN9DKszOHUX2XM3uHc3uvd1/lHP4oB8f9EcBP/Qfh1q1348f+vFDfxzwQX8jfAOS eTdBK69Pqn3+U3Ca12cBn/Pjc0SFrAB+F8DvApraF9A5ejjnBR8k8T6Z6GEAPhjwq/2BAKTyOghd OH8BdIVunE9TMTJ8jAwfC/Tkfr1okw69oQ9cCBfRth+fXwz96eMSzhFhiUZZgRmqnB0+IfCK6BFg rQOsdYC1DsyBufCaWh9YqFay89cTqUYRqUYRqUYRBdYTrUYFcrnPW9xnBfd8h/uv5v0ayIO1KttR Er8jSnxAVNiJkqgiInxMJPiKHT+Lnf0MOzufXbuBXbuNfHuCHfsXdmwNu/Igu3EHu3ATu7CcXXcr O+tRdtI77Jg57JgP2DFH2CVz2CW72QVFeH9u52+cPsT7P3T+n/bTao/4LfEqj5HkkbFK3e+RowvU buLWO8StdxiVHT3/i+i5nei5ncy1rjOHbyMHHme0NWSvbWSvbcSvdYz8U+JUlJGbdgZj1DHiTQ3x poaRHyJeRxh5KzE7QsyOdGa4tcSCdcSCdYyyhVE+Zf9Kg+xV6n8Yjfuo2kYG20YGKyWDbTunESby fpJ6p1Mr5LE/89ifeWSwUj91h/8lmANz1Xai+nai+nZHOyzk80WwlPfL4A3usZz7vs2xUK3D79fh 5+vw6Sj5JEI+ieC3UXJKBF+NdmavdfjlOvxyHb4Yxddq8LUafK0G34riW1H8qga/qnGy2wCUZEeG 24ZP5ZHhSskc2/GPdfhHFP+oERPIEiVkiRL8oRhfWIOlG8kOJfjCHUTzMNHcjuKfYtUIVi3HquX4 xPtE7iosW0akDmPZMixbhm9IJ0L3UPuIxvuIxvvwkUx85BRRtoIoW9Gp18qIrIVE1kIiayE+s4do upcoWkrk3EdELCEilmD1RqzeiLUbiYAlRMASImAJEbCECFiCZRuJeiVEvRIiXQkRrZQoVkEUqyCK lRLFColihUSwUiLYXiLYXqLVXqJVBdGpguhUQXSqIDoVEp0KiU6FRKe9RKUKolIFUamQqFRINKog GpUSjfaxOmVEljCRJcwqlbFCZUSXKqJLFRGkimgRJlrYkSFMZAgTGcKsVDkrVc5KlRMVqogAYVaq nJUqZ+eHWakydn4JO76EHV/Cji9hx5ew40vY8YXs9kJ2ewW7vYLdXsFuL2S3V7Db7V1ezi4Ps8vD 7PIwuzxMHXwcZWxr6qvUaXE1u+wEO+ohdtRidtRidtRnrPNqdk0b65rHuuaxrnnslhjr2sC65rOm +axpPjviBLvgBGuxmrVYzQ6wlfJqPP4EXr4YL1+Mly9mLVbj5SfwclspL8bLF+PNbdgrHzvl481t 2CofWzVgqwa8ug17NeDJbdgnD/vkYZ887NOAN7fhzW3YKA8b5WGffLz3BN67GM9tY855zHG7ehmP bWEG7/GumbG3qLfxTUv0ZmaNvKtgZlXMrIqZRZnVLuJAjJntYma7GJ1dne1idLsYXSOj28WoGhlR IyOqYkRVjKiK0TQymkZGU8VoqhjNLkbRyCiqRD96anbqklZ6a4PTqMSz6GThqBdJb2F6s7NVM73Z PhOmt2Z6s7NSM7ZoptdmbNFMz830XEHPFfRcgS2a6b2Z3pvpvYLeK+g9TO/N9F5BjXBILWfme5j1 HnqW9Bgllv2JiHuQiHuQmPYWEXe38NKqtbN+kp2/WBqmjRIZYgi7PMYuj9GiihY131bXtKxiJq3M xGSX23YzmYnJLEx2QIwdEGM2JjMxmUkrM2llFq3sgBg7IMYOiLEDYuyA2Hcq3560uYhz31bAGbwe oEy8OWZXu3hzDG+O4c0xvDnmrO1XjOyks7Ye3jU536mcgtNEEq/9ayRU1TWoqmvQ6hZziKt6PosT 6+uJnfXEzhpiZw2x046N9cTFeuJgDXc75PjNPudOmmNBKQZxjwI+2cLq1nGvEC2+OWcXNAQ2qcMe ddijjj5Cnf/G8jlWuQ771GGXOla5DtvUsbp1jCHEGAoYQwFjKGCl675jkz68vxC+tUl/2g/g/SCO b9F+hfOdSVy4mL0UPRlfXWeeq2RMlfbOZUzVjP4Y46pmXNWMo5pxVDOGavquo+86+rb7raTfSvqt pL9K+qukr2r6sfuoFAO4+1pmH2LmheflALvWD9FTgxPzDedf6izs9LRKR9k+TXzsjI3MuJBe19Lr Wnpd+1fjoh0H+9POjoGDONrx7C3afj+eJTOavzCCQ863DV7nd7GP0/Meet7T+TuhEpHJuC1abmfV TKqWKOMvxUrFWCmEleyx/ycebVtqM2ttq4IGrLUZa21mPqXcdRV3C7GKJsrSzsSbseBmVtL28s14 eQwvj7GiJvMrxdtjzNFijhZztFhVE4UYRSFGUYN2hg5h6RCWDuH1MVbZZJVNrB7C6iHmXorlNzP3 UuZtscomKxASfbB6GVYvY847mUEj897KqG3LlzHiBkbcwOgasHYZ1i5jlA2MsAErl2HlMqxchpXL sHIZVi7DwmX01ICFy7BuGdYtw7plWLeM/dWiXsc25dijFg8jI7CfLidnX61OCg2t9IXz7drV6pDo z7sW51vLDGLcABiumsjjTeTxJlq0ksPrUFSNnd8y1pGH68jDTeThps5vGeucbxkLiXsd3zQ2kXub yL1N533T2ETebUIVNZN361BGzeTBJvJgE7mvSSSjNNoYyXKUhXS+wb1KHadX+xcJ77KC7zrf2iah RaSWxpiHOd8PHnW+r7iaq+8V/0786yt07nHUucflqt3+3pXZsn60r6btEayQxoyuVm2OPYp41SC6 80p+75vGBm00yneMOsKMG5hxw3nfDDb8jW8GG86v4MXF9GR/G1yPXWuwa833vhE+Ti/12LSeHurp of68b27r6aUem9Zj0xpsWv+9b2/rsWn9uW9vI7Q5zPtqIuF538gKF7M+IQZoAWfF16DhmtFwzWi4 Zsb0IWP6EEu1oeMa0XGNtG5yvuu7mc9HOL/yK8DyBcThi4nD9r+njqHFGtFijYzrQzRXI5qrEc3V iOZqRGM1orEaGc+H6KtGtFUzY/oQndOIzmlE5zSicRqFj9G8T88nnG8Y7RUcQc/3qm30tk1k8OkR 7HaIMVYyxkpa2t+of439arFfLfarxX6HsV+b/T0VNjyEDduwYRs2rMWGtdjwEDZsw4aHGGslNjyE DWuxYS02rMWGh7DhIWxYiw1rGXMlNmxjvJXYsBYb1mLDWtEDq1VhtSqsVoWlIlgqwrgrGbeFpaqw SASLRLBGBGtEsEYEa0SwRgRrRLBEBEtUYYUIVohghQhWiIjezPM4czzOHI871ricOw8nI2fClfAT 9ssm4tR/wmZeF0ChOo7ebWIuJnMxmYuJvm1iHibzMJnHceZwnDmYzMFkDqbzG077Xxuni2ViLJHg UXgMnlHvislqvpgCU2EaTIejao2ogWPQRJtTap44De1wBs6qea4hKuwaCpfCZfAjGAY/hsvhChgO mXAlXAVXwzVwLfwEroPr4Qa4EW6Cf4Kb4Z9hBPwL/Cv8G/w73AIj4adwK/wMboOfw+3wC7gDxom+ rq1qp2ub2uH6BLbDDvgUPoNS2Am7YLfaoa9Q8/WVsAq+4L0Je4C56glQap6ni8rzdFVrPGkq7OkO PaAn9IJ0OKzme+K0qYdv1HzvULgGxqs87xPwJDwFE9S73omA3b3zVNhbpnZ4W1XYN0jt8A2GITAU MuFKuBFGqzW++2GMmudbCqvhMO+PQDWwZr5a9a7va2jksxO8b1XzktwqnKQB+T3JA15AvyahX5PI 30nk76QU8EMAUiEI5PQkcnoSOT2pG1yndiRdD7/h9WMcn+e4luO70KLCydwruZvaIR4UXfG4bpAG 3aEH9ITBMASGwqVwGdwGP4fb4RdwB9wJd8HdcA/cB7+GsWoDnrsBz92A584WWdQIE2AiPAuTYLLa iDdvxJs34s0b8eaN+mxl6nNgLrAr9ByYB/NhAbwOC2ERsGP0JbCC61bCKrWRVd/gOahMD7vLE4Eq OMz5KMcYxPm8Hr7h3Fller2ArvYmgwG9IB0GwiDADl7sgHds9F7F8RqON3AcCQ/CGPgNPATj1QY8 ZwOeswHP2YDnzMZzZnuZr5f54kEbk56ybSMWoKleh4WwCBbDEkBvCVtvvQvrYD3sgt3wOXwBJuyB MtgL5RCGfbAfLDiqCogJBcSEAmJCWFDziBPA2gt8V1D7ECeKiRPFxIli4kQxcaJYP67Cei18DXUQ B2omvQHQoTo6VEdf6txT554699Tt6xKgVDH7rcBHLPCx933sdR973cc+97HPfb+Ee2E0be6HMarY 93veZ8EEeBYmwVR4GV4B9psPG/mwkQ8b+bAR+6nY9yeOqzm+x7EQsIMPO/iwgw87sNcK2GsF7LUC 9loBey3MXgv7mJOPObHnitlzBT7swb4rdv1Y6KgRD3jBB0mQDAakgB8CYD9z+noxTNwAY1UuPp6L j+fi47n4+Ep8fCU+vhIfX4mPrxTPia74+Uz8fCZ+PhM/n4mfz/wBz5LKFCE4qpawoktY0SWsaD4r WsSKFrGiRaxoEStaJE6KC1jVHFY1h1XNYVVzWNWc/1e/i3dfIdLdw8Uw91Ucb4afqlz3rWqJ+za4 S/Ryj1Pr3Y+rF92/h/HqRTTbk9r96lV025PabzhmUclMIE+XiaC2V6RpYdhPlj0g+mpHVbFWw/tj YogWdZ7qkKF9zbFOBPUs0VefABPhWZgEz8FkmAJTYRpMhxnOc7RmEi9mEi9m/tDnaOHtOXh7Dt6e Q6zJdX6T31UtIcbM9NSJrsSXXOJLLvFlpqdd9PVqgG95u0I3yIChaqb3Uo7D4UoxjJgy03str8er XOJHLvEjl/iRS/zIJX7kEj9WEj9WevEl72TAl8791j+sqv+33+3bv8X/hSpipy1hpy1hp+Wcew7X t8/gsp+9tZTzHc/fymQ35TjP4DpM+yNQDfgcOyefnZPPzili5xT56sUFvgZopP0JPsf/2EE59nO6 /mG/0T//WV/n/dbe/h29MUotMZiXMU29aMwA9o3BvjHYNwb7xmDfGOwb4zXIgXkwH5iv8ToshEWw GJbAUlgGb8CbkAvL4S14G7CPsRJWwZ/gHVgt0lOmiF4pU2EaTIcZ8Dy8AC9CNsyEl+BleAVehVkw G+bAXHgNcmAezIfXYSEsgsWwBJbCMnhD9PJfJtJTk0WvVAPsv8bi1vawC446TzHZ4zz5pK/7WaJZ kGgWJJoFiWZB5y8mJIP9d4VSwA8BSIWuqNtukAbdoQf0hMGAgkYBRFAAERRAhMiXQeTLQAnEUAIx lEAMJRBDCcRQAjGUQAwlEEMJxFACMZRAjCiZRZTMIkpmid9RaY2Dx+H3MB6egCfhKfvfqsMf4Wl4 Rj33VyPqZDWSaDqSaDqSaDqSaDqSaGoQTQ2iqUE0NYimBtHUIJoaRFODaGoQTQ3ybpS8GyXvRsm7 UfJulLwbJe9GybtR8m6UvBsl70aJvBlE3gzyryT/SvKvJP9K8q8k/0ryryT/SvKvJP9K8q8k/0ry ryRaLyBaLyBaLxAxFRfHoRa+hjqIQz00QCN8AxKa1PtE9i1E9i1E9i1E9i1E9i1E9WyiejZRPZuo nk1Uz0bTW2h6C01voektNL2FprfQ9Baa3kLTW2h6C01voektNL2FprfQ9Baa3kLTW2h6C01voekt NL2FprfQ9Baa3kLTW2h6C01voektNL2FprfQ9Baa3kLTW2h6C01voektNL2FprfQ9Baa3nLdKdJd d8HdcA/8Et5UJpnIJBOZZCKTTGSSiUwykUkmMslEJpnIJBOZZCKTTGSSiUwykUkmMslEJpnIJBOZ ZCKTTGSSiUwykUkmMslEJpnIpJYIUUsUU0sUU0sUU0sUU0sUU0uEqCVC1BIhaokQtUTI9bkwXF+A CXuEQRYLksVSyWJBN/UOmSzopqYhm20hm40lm411stn9Ku4eC+PU0vOzmvsJ5+kuI8lsj5PZRpLZ 7Kckvac9o9ZqhWSxIhHQtqlXtD1qE1kuSJYzyHIxspyhHVTVZLr8zmcX9XWec/k15+uEhywXJMsF yXJBslyQLBckywXJckGyXJAsFyTLBclyQbJcECUdQ0nHUNIxlHQMJR1DScdQ0jGUdAwlHUNJx1DS MZR0DCUd05cqqS+DN+BNyIXl8Ba8DSvUSDLnSDLnSOquEHVXiLorRBY1yKIGWdQgixpkUYMsapBF DbKoQRY1yKIGWdQgixroTInOlOhMic6U6EyJzpToTInOlOhMic6U6EyJzpToTKm3qLjeCm1wEk7B aWiHM8CeIDNnk5mzycxZZGaTzLyA+s+i/rOo/yzqP4v6z6L+s6gSIlQJEaqEGFVChAw+0lOjJJVC hEohQibPIpNneRiThzGR0UeS0YNUDRFPgvdKSa8AF7hBE0EyfZCKIkJFEaGiiFBRRMj8QTJ/kMoi QmUR8V5I24sgg3MDeT8IiLVUGRGUwUiUQdB7BZ8P53ilyKDqiKAQRqIQglQeESqPCJVHhMojQuUR ofKIoByyUA5ZKIcslEOWlzjqJY56iaPeZyALJqjnUBPPnVMTxFDqWQslYaIkTO/bwvC+J9K9m2Az r//C8VOOZSqEyjC9rCV1r+W1n8h5kTJRHCaKw0RxmNTCIWrhELVwMbVwMQrEpB4uph4O+W4QBjVx iLpAUhdI6gJJXSCpC6KolC3UBZK6QKJWFqBWFvgeUHHfgzBGZVMfSN94XrOnfE/CU/AH+CP3fBqY F7VDlNpBUjtIageJwjFQOAY1hKSGkL7ZtJ/jPNlQonoM6glJPSGpJyT1hEQFZaOCDFRQBnWFRAll o4QMagtJbSGpLSS1haS2kNQWEoW0AIW0AIW0AIW0wFfDvY9BFIj1PmI9qul9VNP7qKYtqKYtqKVs 1NIC1NIW1FI2asmg1reo9S1qfYta36LWt6j1LWp9i1rfota3qPUtan2LWt+i1reo9S1qfYta36LW t6j1LVSXieoyUV0mqstEdZmoLhPVZaK6TFSXieoyUV0mqstEdZmoLhPVZaK6TFSXieoykzIZ05Vw nQolXQ+/4d6P8H4sPAqPce4/OP4OxsHj8JSKodBMFJqJQjOTnueaeZxfS9t3VXHSOl6vhxZlJQuR joIzk5lbcjcVSu4uDOMeFTaoC437YJQai7IbazzA60kqbjwHU+BbpfcCr1+CV0QQxRdE8QVRfEEU XxDFF0TxBVF8QRRfEMUXRPEFUXxBFF8QxRdE8QVRfEEUXxDFF0TxBVF8QRRfEMUXRPEFUXxBFF8Q xRdE8QVRfEEUXxDFF/z/qPiC31F83UWOusU1Rox2PQQPi0mu34qHXY+IO11jxVj3T8W/uMeJG7V7 1X3aKHWXFlIhrUiN1apVGG2YptU4z3hdpR1XplZLLfU19VadahX9RE7iuMhXNWKHquHuN3U+kfZO 7j6Cu4/ofJJsq/2saHpJpxeDXm6il5H0Ml/7SO3SPoYiZWhbOW5TR7VPuPt2tYLeV9Fzu3bM6f0O el9O7wa9F9B7WCRpJi3KGBOVvFbO2MNqp7aPcwfIiAdp4Wdsuxnbblo+RO40ab2K1q/Sujut82l9 H3m0mCumc0W26G8/X5LRriSb/4jsPc59O5l8nJrrftL+t52iv3u7muD+TK1yHxI3uFuoR9PQz5er D7WPyL5F4gpmUEpPIepRQyt3alGTLB3k7u3M6DCZ+tXOTG101qQGM5NaLbNynjSoGl2/ErrKEx7w gg+SIBkM+9fZ4IcApEKQyr4LXK9McQNkq1liJrwEL8Mr8CrMgtkwB+ZCjtoqtqjNIqQ2u9zoHw10 8IAXfJAEyWBACgSgC5AnXV2hGxBLXMQSF7HERSxxEUtcxBIXscNF7HARO1zEDhexw0XscBE7XMQO 1yAYDHeqsOsuuBvY2y72tmsaTIcZ8Dy8AC9CNsyEl+BleAVehflqp2sBvA4LYREshiWwVO10X6Fm ua+Cm+EuVm+WMt2zWZkidTerEsfPWvGxTaxEvOOZj7xvTXyitak07WQiop1KhLXTifVae8LSziS2 aGdVipbgvErEdU/iE92r0nRfIqInJcJ6cmK9biQsPSWxRferFD3A+VTaZak8fQJMhGdhEjwHk2EK TIVpMB1mANpWR9vqaFsdbaujbXW0rY621dG2OtpWR9vqaFsdbaujbXW0rY621dG2OtpWR9vqaFu9 AP5LhfUtEIJC+Ag+hiIohq2wDT6B7bADytUsPQz7YD8cgINgQQV8CV9BJUTULE+7yvNqgP96PSrf 25VjN8iAS2E4XIkuuJbjXBX2LoFlvGee3jW8Zj5e5uNlPl7m432Pc5vgffgA/gJbOB+CQvgIGLuX sXt38Xo3fM7rL8CEPXAADqqd3i/5LAZ1IKEJmuEEtECbCvtSIQhd4ALopXb60qE39IEL4Sp0yrXw RzXL9zQ8Dy/AAlgBq9RmXz7HNjUrabAKJ11Gjvsxxys4/gLu4PWv1c6kR/h8LDwK+GPSMs6/AW9C LuRDu9qZLFQ4+QKO7K9k9lUyOTqZ/Gw8Ao/DeHgS/gBZwH432O8G+91gvxvsd4P9brwGOTAP5gPj NV6HhbAIFsMSWArL4A14E3JhObwFbwNzNFbCKvgTvAOr1ayUnykz5Tb4OdwOzDXlDrgT7oIpalXK VJgG02EGPA8vwIuQDTPhJXgZXoFXYRbMhjkwF16DHJgH8+F1WAiLYDEsgaWwDN5Qq/yXqVmpyWpV qgEpapXQif6biPwxbT+57CB5bLGYTPycAlNhGkyHU8TS09AOZ+AssWqIktTPkvpZUj9L6mdJ/Syp nyX1s6R+ltTPkvpZUj9L6mdJ/SypnyX1s6R+ltTPkvpZUj9L6mdJ/SypnyX1s6R+ltTPkvpZUj9L 6mdJ/SypnyX1s6R+ltTPkvpZUj9L6mdJ/SypnyX1s7SfB+YqURFq1jg1a5yaNU7NGqdmjVOHrqEO XUPdGaHujFB3RtyrVTUZLY9Mdtzdqurdbare+WXTNurOPWSjMhUhg+VRw+VTw+VTw+VTw8Wp4eLU cHb9ZFI/mdRPJjWTpGaS1EySmklSM0lqJkmNlE8dlE+dkk9Nkk8NkU8NIakR7CeISuqAOHVA3Hep ivguc54Gaj8J1NbyJjrbRFubaGETDWyifyX6V6J/JfpXon8l+leifyX6V6J/JfpXon8l+leifyX6 V6J/JfpXon8l+leiV+Po1Th6VaJR7Sd0RtChEg0aR3dK9KZEb8aT01QEjbkGjbkGTRlBU0b801S1 fzrMUNWBNFUf6A49oB9cDC9w/h3nXzfVqDzyOhpTC4krtULxiFYsBmhbRW/s+7n2ieiubReDNVPc hq1vc+r6cjGC2j6o7ROZ2D1uf4uNzqnm7FExDL1wm/Mdtv17hlpUS8d32Zn0tE1tof0Wp89NfDZd aPQ3hHNhu6VIcd0pDNddcDfcA7+EcSKT6s2gerMrN4MqzUi2/+qqznj6sjtudJ6JTD5kDB1n+pIt Y5wdQrbMJ1uGHT1INU7PR1FCtWKE852i3TaTMdh/DyHKiDuen+w8VdrWRPb/N3GePzdK7dWysM02 fOgm+y+Xc6acd5W0/hgtuFW18K6ad+O5bqs6xbtyMVjo3N0DXvBBEiSDASnghwCk0uO94gJttPpM GwPjsWKhOsCdqrhTmZ4lMvUJMBGehUnwHEyGKTAVpsF0mCEyqeUzqdkzqdkzqdEzqdEzqckzqb8z qb0zqbcZizPWEJquEFt9rI5oxeyiraqCHgtRtw3MPUtchk9cwKfS9gXmnia6usrERa69YmDnv0t7 VBtNq44nNV9mP6lZG+/8pmu3NhF9u0QM1ZZCSNWy0pegZN7XrxOX6teLgVjrfpHKFan0czmrmcUK fKwa6Gm301OAHurowdQeoP8HUaAPcXyYYxa9lKlKNHIcfXzG8Z8DwsNVhvDaf42F1um0TKdlOi0l LVpED3GUKIqGEsc6nt7n9DiRI3GCVfcQcS3ud4Ko28IV0r6nrYg9XVUrNXwrNXwrNXIrNXIrNXIr NXIrtW8rfd7LXEdxlyxWzuQq+272N6Y9v9PnA9z/IXhCuJy+92D5Ms7vpb9y7BzGc/ajzA+IlP+r flM6+63mbkFm0c4dq7ljnDtK7ujt/PbN4+SPVFpLbZQzjgjjiGhPO2ucwYh9mv3k5o6xtHJlCmNp 52q7QpHix+KouFbUwDE4JQaJ09AOZ+CsGMSdH3KqpQfYZw+Ke7WHOD7M8Qkqmae580S1XZvKSi7B 05eyY1E92GiAszbl6n2nt33qIHsujSrnDD6SiY9k6txbT4ASgzxdxbW+0XA/jBGDfEthNRzm/RGo Bsbpa+TcCY6tjC2ZkbUyomGMZhhzTetcHbIrO8Be44P4jO1pxYy/GMvEaJ2GdWJckcYVmbROZpz1 WKaZsUrGetK2q3OV6fgna4QvZ7B3W/HnDG0CkbBa9OzQ6/hrjNWxf6dVq7Y7f8nHXrMIrQzOtDCO b58Q1/mvY7Rn8JFn2f/H8Yda7O/tfKZ9jGuIbcwgCrUqItLFWEbyKDwGzzh/waCV8ZiMxaR1mtP6 KD06VRyf1RIRne9dyYs3ib6eLirmiUO9innHwxPwJDwFE2Ai903t/LsI9pM4I9w5oj3DjCYw02rW 7aj6mpme6pipamPU7fSy06m9ezI+yfgk45Pndslo7jQGnmFsE1iXaq48ytjtOrqj2rRnd9j+G0iM TzI+yfgk45OMTzI+6bX/n8owQeUuHoXHYDLvp8BUmAbTuXPHX00aSoxK7XwOvR1xRhCjlmLlAqy8 A78M4Zc34pe3aOvx12pGdpS5OaMhT8VYs+Mqgk9ei09eq9+kLH2FGKavhFVimKeLuMVzmGOcYz18 I4Z5h9r/7xPGi1u8T8CT8BTY40vqXCPbZzydPuNx1irqeIR0vn3IZ9x5na3SO1ulM25Jy0xnbPb6 e7XxibXaSdVIrRfRfaqRWi6iD0mUMubxicOcbeVMqz5E/Yi7jk8c1FpZqXauPsOdzqpq3aNO6YZq 19EjtKym5XDn2o18anHG4m4tzrWmdpo4YV97Fm9QXJMsfM61fmqwVI5DVF/RlZal9NJOVSoZWVyz /1V4O72eUae5ci9XttJrO9WoZMRxHVXEXU4xgtPcaS93YryJI6zUeOrYjru0cJd27pKwx+z03XF1 C1e3c3XCGXvHGDyiB1eOZwzVWhs2O8nxFPZDJXfO3NLOsqcT6hh3OsVYqnWvSOdu1dytVU8my3dY hPmLZD2gjnHnU4zpNTtrJqq5o22DmJYg5/ic+cf0AK+HKOG0eM9ZkdNOq45VSXZa2StTjnW/t17o ic514ur/Zn2cts660Pa/WQ/R5X+6DsL/Q+2PF/+D7Y6P/w17O5/8VTuLVD1NJOnduWsvYei9oQ/X XMj1F/Eatar347NLeD0ABvLZID4bbKtKvQf36MOnF3McaNtAT+MdNYPekza9nU+lc6++nO/H6/68 HuC0lvZ9hNdp3cvptcVpcYnTS4voyrg8fBrXe3CmJ/QSfRlfkJZx7tmX8XFf6Mf7i/m8P1zC+QG0 Gci5QbweTB+p3CXGWO0ZevR0eu8ttM672FfHGL89Q4+ewWcD+Kzjao/owhgMrq53ZtqL+/amVR+s dyHnO/o3uEO9Y4FL+HwA5wby+SDO230zC+7fnU97qG/0nvZc8ThnDKzlhfR7Eef60qYf5y6mTX/b BrRxxkKbQbQZTKSz1yno2LWXSOtcp3bGkcY4UhlH0LHtJbzvWKd2xpDGGFLtVXGs5+m86sR3Rm/P u+OKE+dGHfx7fYJdu49X3/MLdns/EfihvsFVGezSv+EffOoW3f5RPsLdunPm7/QTrvaLC/6nvsJd etgz+sf4Cyux2lnHv8tnnBkFfqjf0OdJ1GxrYi+xcBgRRyeqDddOJ4qIan20M4ntRJ/rtESinajW Rfck9hIbhxGNdKLacD05UURU66OnJLYTma7TA4l2ohp7MFGBRXpjkQAWCei9EqVYpLveOxFlVAOw io5V3Hpf2vWj3cW06Q+X0C6DdgNoN5B2g2g3GK9JplILUmPdotl/RWi7o+rTULl9URWZ9vf2qL10 5y8ZhVxjxA2uh8QtrofFHNdvOT7CVfbfHbpPfar9CjU0Si13/jre0P9Dq0+dVt/+xaXl595tOvfO 7QpQAQ8TQlwvbhaXUnOPEFeI28Q9Yri4T/yKs79Gt90ofifmip+JHLFePCVCooh3W/lvgdglDojX hUXNsULEXEHxZ1cfVx9xwNXX9b+o+w4wqWo17C/JOcmZmZzdBXbZXViQLqBIFRCkCKhXUZFruQoq WFHRa0NFBBEUAQUpKqAgoqBegQs2uliugGIDQYpIUTpI703yv8kMyyAsZVH+/z/zTDaT86XMmS9v 3iTnvFuJFrAr2JVIbcaupXWsBbuJNrNWrBVtY7eyO2g7u4/9m3azR9kg2sdew6s4G4LXWWwoXiXY e2wkK8k+Z7NYaV6FV2PVeQ1ei9XkdXgdVofX5w1YXd6YN2H1+CX8EtaA/4M3ZQ35lfxK1oQ359ew i/n1/Ab2D96St2RNeSveil3B7+B3sit5G96GNeP38H+zq/nD/DF2PW/Pu7OWvCfvzdryPnwAe5AP 4q+y9nwE/4B14B/x6awH/4rPZ4P5Qr6CjeJr+e9sAt/Mt7ApfBvfzabyvXw/+5IbQWyG4EKwr4US IftGpIqC7EeRLtLZPFFYFGHzRUlRiv0iyoiybIk4W1Rgy8S5ohJbLiqLymylqCqqsVWihqjJ1og6 oi5bL+qJ+myDaCgask2ikWjENosmognbIq4UzdhWca24ge0QLcTtbK+4T9yPqh8Wj3NfdBQdeUw8 JZ7iWgwQA3koxogxPFV8LD7maWKCmMALiEniS15Q/CAW8GJiufidny12CcOrer6Xwut66V55frFX z6vHW3jtvO68pfe8N44/4E30PuWDve+9Wfwtb463ir/trfUMn+RH/Sj/0de+5nP8NL8gn+vP9X/m 8/3F/q98ib/CX8GX+6v91XyFv9Zfx1f6v/tb+Gp/m7+Nb/B3+rv5Rn+vv5dv8ff7+/lW/w/p821S yRS+X6bJNCFkQZkhPJkli4tAlpTVRao8X54vSsla8lJRWjaT14ka8mbZVdSVz8rnxK2yp3xB3CH7 yD6ijewn+4u75SvyFXGvHCiHiLZymBwmHpLD5XDxsHxbvi0ekaPkR6KdHC8/EZ3kZ/J/4lk5Q84Q PeRMOVv0lHPlPNFPLpALxctykVwkBsilcpkYKNfI9eJVuVUeEK8rUly8p5QqIUarcqqGmKHqqHpi nmqoGoqfVWN1qVikLldXiWWquWouVqpr1bVilbpe/UusVi1UK7FW3a7uEJvUPeoesUW1Ve3FVtVB PSWMelp18Tz1nHrBk6qPGuRp9Zp6zSushqghXqYaqt7wstRwNcIrokapKV6O+lLN9CqpH9U2r4ba AZC7PigXlPNuC8oHFb3bg/OCyt5dQY2ghnd3cEFQx7snuDCo57UN/hFc7t0fXBFc4T0YXBU08x4K rgmu8x4Jbgxu9B4Lbg/aeI8HDwQPeR2DDkEHr3PQKejkPR08HXT1ugTdg57es8ELQS+ve9An6OP1 DPoH/b3ngwHBYO+F4N3gP16/YFQwynspGBOM8V4OtgXbvVeCncFOb2CwJ9jjDYoAzLxXI17E8wZH VER5QyI4vNcjqZE0b2ikUCTDGxbJjmR7wyNFIzneiEjxSHHvneg10Rbeu9HW0dbe2Ogd0Tu896N3 R+/xPoi2jbb1PoreH/2393H0weiD3vjoY9HHvAnRDtEO3sRox2hnb1K0e3S0NzX6efRrb0V0XnSx tyG6NLrK2xHdGyviHYiVjvX1i8f6x970e8XGxz71h8Rmxbb5b2uls/yZ+hx9sf+LvkHf7e/SbfWD UumHdTsZ6sd0e5mmO+gOspDuqLvJdN1DvyiL6766ryyr++uXZTk9QA+TFfRb+i1ZQ4/Qo+X5eqz+ WNbXE/QU2URP1VPlZfoz/Zm8XH+hv5ZN9Xd6jrxG/6R/ki30fL1QttSL9DJ5i/5Nb5F36O16j2yn 9+kDsoM+GJLsFPKQy6dDL5SySxgJQ/lsmBYWlj3DrDBL9g2LhDmyX1g8LCNfDsuF5eTgsHPYWQ4J u4Td5Othj7C3fCvsF74k/xO+Eg6Qo8JXw1flf8PB4WA5Jnw9fFOODYeH78qPU3hKipyUUjAlU85I KZpSTH6Xsjtln5xFPNIVIwrFJqd9QmfTWfSXHGapWUaVMLMi8+Mxz+83L5oxeO0y7fGplbnTjDbj EFvuzi43axD+lrDddVRue3aN2YrX4XPpR1ltxvvZE7a0B94fJH1eiNIzbA15HlGzz7bObEfc3iN7 KZXD5yW5JazNjS0/Rn0/msVmnfkWr+VmC9j66R6ZKHOYK3mF2WBmHqrdbDiq5g3uqm0wS3D1b6Wi uGIVbMsTZ/efqCKz02wy28xasyo3qRBSN7lzH+PXSzXjEVt5zLywMhtR+y6zjuxVK06lqWG89Tgz 38yHtyyzsTzqHmqG2G9pHsX7KtPIdDHdEVuWe/735G/5p7z7ca2Xou4vzHR8+634pfzEmZ//ZDnj hNdgByU8zfR14VazGaUnvDDpyhyy34krts3sMfNgd7n7tnVx5ROtNOvNeoTrErZ7jsq9GddstfWR RL/YRUXc37l5f9s82r3kiE9tk+KfnFwJOM47XCN+sbnkm3knqNX2wPWJDxWpxnFt3zGvWT+xPnTq h1llvyG8a/FRZ347Yd4teD/jYqP//AtadDpB7hV4T3aItOhwzz/ZA16904Vzj3Ey9aRK2Ib3r6da byLv54m/4/KR93UXzrDf/y8+6pyw7rXx39XsBZZuOsXSj39Va+F9navjt3gYfyXOHmt0rIDXWXhV OKKF77hwVvx1nNxVj5l7tQs3mh3Arh15NRXnLKqtN7/YfmjzxDE8PuYB7aaZb8xXeeZOGlVNTyoJ RL6SmiH+nkuZi3HqE7Mwz9xJ45bpj3Egmy7GzBM9yKX8gr4w7TA651W3HUHhRzZ3DcxaE+lmkpmA MTZPXDqM9YkjFdevBdKfcGenmonmc/NpwnbjUbmTRnZcqVQ3DtlR5QqXMg21TzaT86w7D15w0DKC b82Nprlpa65L2B6FZKYnruvX5nuz7Aic4XQLPYMZOmG+3sc+dUKjSdMYmkDlaQrm7tXc3L0mfYm5 ey36GXP3ppilM7qBtWat6RHMnv9J7ey8mR6zM2Z6nN/L76cnMPddSJ34L3wpPcWX8xXUFfPgtfQs X89/p252Nkzd+S6+m3ry/Xw/vWBnw9TLzobpRcyGY9RXWE2iV8RN4mYaIFqLW2mQN94bT69hHmlo sF/QL0gz5Tg5jr6RU+Wn9K38RS6m76WRhmbZ+RPNtvMnmqeuVs1pkZ0/0WI7f6Ildv5Ey+z8iVbZ +ROtsfMnWmvnT7TLzp9ov50/0R+YP/VjQr2kBjFpZ1FM21kUC+0siqXYWRRLs7MoVtDOolhpO4ti Fe0sil0RiMBnNwRBEGUtAx2ksFuCAkEhdmuQEWSyO4IiQQ5rExQPSrB7g9JBWXZ/UD9owB7EzOlO 9jBmSD3Yo5ghvcAet3Mg1t7ORdgTdi7COsSejPVlT9kZBntZp+ksNlGP1qPZF3qF3sL+Zzk+m205 PptvOT772XJ8tthyfLbEcnz2q+X4bJXl+GyD5fhso+X4bIvl+Gy35e9sj+XvbK/l7+xgSiQlxkVK Rkomlyl7UvbxCPxmnvMb5vyGw28GgMkPpNfAbwbTCKS8jZeid2gkBTQKXiWdV0l41ScUoanwrajz rSh8aybSv6GfKIZS5yHvfLxCeNtiSqEltBx9bAU8rwStoa3oNdvwKknbaTeVoj14laa99AeVoYPw ywLOL3OcXwrnl9r5pYZf3kdp/H54p3beWRDeuYQK86Xw0ULw0eWUyVfAU4s6Ty3iPDXTeWqG89Rs 56mFuOGGCgmCv6bDXzlCHJQBr1WI42enLBGBB6c7Dy4CD76Jyoqb4cfl4MetEb8V3lzOeXMOvHkJ MW+pt4q4t9pbQ9Jb622imLfZ20HFvJ3eLkr1dnsHqLj3B/y+jPP7Es7vc5zf5zi/z3F+nwO/b0zp qolqQjF1sbqYPHUJeoKPnnA5Upqqpki5Ql1BSl2prqRAXYUeUgo95GrkbY5+EnH9JIZ+cj2F6l/o LSnoLS2phLpJ3Uyp6hZ1C5VRrdB/Crj+U8D1H4b+0xa57lMPwuYh9TBSHlGPEFft1KOo5TH1GEp+ HH0shj72JHJ1VB2R3kl1gv1T6HWh63UMva47bHqonqj3efTAVPTAPkjpq/oiVz/VDzYvqQFIGagG oiWD1CCkoGdS1PZMsj1zKHK9od5A+nA1HOWMUCNgOUqNQspoNQZ5x6qxuA7vq49xZcapSWjnZDUZ 12SKmoJWfammo7Uz1EyU+aOCT6p5Ct6oFqhFKO0XtYzOUr+qFbgmK9Va1LVOraeS6ne1AVdyo9pE pdVmtRk1blHb0OYdagcsd6qdOLtL7UL6brUbLdmj9qL8fWofSt6v9qPkA+oAFVJ/qD9Q+0F1EHmN MhSzOEI5FkcQAkcQAkcQAkcQAkcQAkcQAkcQAkcQAkeIAUe6I+wR9CBu0YQ8iybELJqQBpp0RNgp 2pnSLKaQAKbMJx1bEFtIYezn2DZKs/hCwuILZQFfVlAhvVKvpHS9Sq+iUK/Wq6mwXqPX4OxavZYy 9Tq9jorq9Xoj4pv0Jthv1pths0Vvgc12vR3xHXonZetdehdsdus9sNmn9+Hsfn2AYvqgNpQZovtT IYtcCL3QQ+iHkgoCv6KUEcbCGGx0GFJRYFkhpKSHhSnbIhoVBqIVQVg0zIFN8fAsSg9LhCVQQsmw FOKlw9KwLxOWQRx4h3TgHVJeD4ei/DfCYcj1ZvgmSh4ejkCZb4fvUoZFQHIISGkWASkNKPXfBAL2 xUvkIuAgxAcD+4TDPh/INxrxMTQR4SSa7BDwc8T/B9wTNB3YJ4B984CV82kB4gvxUg77hMO+dId9 GQ77Ig77Cjvsy3TYl+WwL9thX4ylslTSrAVrgfA+BqRjD7CHEbZj7RA+z54H9jXnzYk7ZAyAjHcg tMgYdcgYOGQMHRoW4hu4/b8RFgELOAQsyP/gf1CKw75U4QmPCgD1AsSjIkppooVoQUVFS9GSijnU y3GoV1zcIm5BeivRCukWAXMcAhYXt4nbqUguAq4hAezbQQqod4AiDu+yHd5l2FVR9M9GqhEJh2sK iNYUocUy4bDMd1iWqZqpZkixWCbUNeoahNeq62BpUSzDoVjEoVg2UKw1+vZt6jaEt6vbYXmnuhNh G9UGoUU05RAtkkC0dqodUh4FovkOy5R6Qj3hEK0D7C2iKSBaZ8TjWNZVPYO4RTTlEE04RIuoXqoX cvVWLyLFopty6BZLoFt/1Z+EwzjlMC7boZtQrwPXRALXhqlhiL+p3iSp3lJvwdIinXBIl52EdMIh nQLSTUbcoptSn6gvEP9SzUZo0U0B3RYhbnEt3eFahsO1iMO1wg7XMh2uZTlcy3a4FlPb1XbksuiW 4dAt06FbdgLdDgDFhEOxWMACRiKOR9H20ScoiD4ZfRJhp2gnikY7A32i0S7RLkjpFu1GgUMiHusf e5W4w5RCeiPQJFVv1cBThyCpDjsKATt2I75H76UUoMZB9GSLGmmhCAWlAC8UhQ4vCji8KASkKIi4 RYqCYWaYCRuLEYXCYmExpJ8FjCgIjCiJEixGFHAYkeowIs1hRAFgxOso843wDeQaHg6H/QigQwGH Dpx4pRvsambVfRc+ixnJtXnx+P+XD7PNLLdvF9965MpNrs0us+q4a5R5lW1XZJfiPdN9Wnoozc5e 3OrgfrtCFl8vQiu2HrmCmfd8MHF+TuLvXafesr/qMC3NEPd320lZLzc/2Nneya6j5VnOhiPjdp01 d61sG2Z9y80SezXNglyrw79eYuXaXXOrBlCcUq21Sztq7ftvPaKJliTXmkr1Xdqvf/71zaaj17vg Pd+bmWZ3fnzzxIeZnfi7IuHJW5LObT/UeteKY/yeZvGx+9Jf0rJTLtkMMwPd311mNjxjFt5jzMtm TuJ3z22/W1mcDR/6Ol/9fQMl7ULE902SzvYyW4AjGxJXdK1tSVLmQ96w8yTq2UPH3O043QO/5OHW 78C12oS3XTXafYTV+qNz/r925K55rTs5XzldRDpu2cdabc7beoYZZ6aZ9y1OIR5f2ZybWKNcl2u1 +jC2nULZv9j1ywT2rXc7QFuBIHZXZEy8fHz+En+/sm/Ej1jPNKPI4lO1Q98KqDsXKNWASpoF8Z0A s8L84P6+eGiF7/SO5N2t+O6R+W/u59fNvaanaW0+Q/ym3NRG5j4zyY00f7rqx0IpfIPJ5jP4eJ5r p/ls9zaHNInW25a4K548am1NXhk3i45b2td/betO5QAaJfbfTLs/nZlmuuXGc0cweITFi5UYWY/7 nfKozSKm/S3ctXH+uT5xnRCaR109yu0H/3mkTnd3aSWXZRnAUoxZUVtSghvsTZzbeqJrfhJtPYyU Sbtgh7AxzkeA8WtcXUd4nutva44a3zfkd18pv0eclSZ9zpP9JO9gJqVO+Wvbk1Tydadg7PZ5TI/E nuIu9OjVdofQvG9GxXcKjxjftya8bLz5MB/t+gS8YEIi/jUw2u3n2v5pfQAcY3liT2WXQ9aFCXYR R9HwT2V95rBnnMP5z+J7IOabIyz+OPUWJnLOoaTd9gRyznEY9JmLAwsdbn4R94L4jmS8dyTOXGya uE9TzV24kvfi3dX0xt+PXOq0I2r7CFe9nflnPtr5gBlisRvf/zfEWiLWBTOEIWYkxsC+prnpb2cM SLVzhrFmeLzPmDYuc/qh/dREWXPR28H8qbyLx2dZCfZld/Xc/SPWP/JxD4jzmtyd7fhYnIgvocTc 5/A8jo7kZiX+fN/D338kc0i7J2c22lH/uDn+xO/PzHHEvqbbWTcbj8/E3FU+s7M0Sr6e8J89jkft PP78wGFMPtqZ9/7zKZRxRq+PGWqeNS+ax1x8OWaj75hXE2c2mJ/c341A4o2HmVu+amlkhp5mO3/B 3OuHxErMSjPffJd0D5nj1ZjxzDLbc+8fyF8tJ1izOW7eFZZ74+9BvL8DP0+MBu5+A3tvj2P8ed2z deYOoHZrYzWNs9ynx/H5EcxU3MzZXgGz30ww/UwdjCE/AMOH5e+XM4Pcn9Kn1dL47/pl4lNiFhtf CaCk2dTpH6dwX1deJWxxV9Di8Drw1aN+ZZxfZGd9f/Vc5VQPMKt1aEV8Proefrol6ZwbZeDH36GH fXPM7GfsQDtHJd+7Alz68v9ea451mDvNTRYh7XwG4Yv4/L753sUTMz74wQRztelFdv71a/587Ez/ DvCOvWe2xlM7DqG++f3o+0dPoZS/dQ0swSg3YMzafHrrfPldO7D7EydpOdbdbfznu8RO9Sh5mvlP +sAYfxprfabfX9eSPGpI4LvZdDq//F85tuVZxxKz70yvWZz6YSa6OcPpXo+z/5LG/G3H6T7ZgJEm H7s1bi05d/XL3SN8qG9F8+5ljiOXphak8lHjhvygtv31D8/XEmuBJ3f3uHb3KP//cGTnJ5Ndw89H rjnJI4t9jgPj1K6/Zxfy7zjAX3eceMQyB/JR8tz83KHvmP+6Iz4dupaR4+SyHpxNTeGjZ/iws9Hc +Do3D/jt+Ajk1sPP8LpNcitPq5zfEu/pR52qkHiWID3puYNTKXkWrtusQ7XYmHsfehbiUH11XU1H tCfpU/fDpSXe78T/Jh32mYeq9q+ZHL9f4xTb+Q7yvZOIu5hb+56c+A6HWlD1T+1859Rrys3767Gf ZDxBrp+Tv7kt4ejdlzyPfK004FdafWKro3KtS/R3t+fv9oMO3U8RPc4TKPZ7ZNNF+envZvWJVoCP mWtR4h3f1bCr25sosbtxnFzx1dLsI/ufWWjWuqc9K1AO/rq9UYw+jnU4b7rx1Nt33LZ/4cLcOb/p YFqbN81Atzt8uM+0NG+5v/uPvu/iGE8IbjUb/57VfHdHSHyvaiE4zlzMTheCX+c+GeN2bOxKfkNz vfv8jXkYVvear/GNJpgHE+uaR+xpuXHkTnNVPlpzH0ptloi7mHtueKAZZz43r5hWZprziGy3sz3n 0IzK3G/TqKzdHTKPmAdc2i5c82VmGL7LOPO+eS+xg3PEGpYbG/qYl/LRzhFmRu5q3gzzJsKRCT6y wnxoXkLaloRpJGnmH0fAMqde35k+zsSOjPOq+P0KR/n7Gah9Sb7249ZR0gpMwvtOXE4BvAvSJS5e Bry+NJWy3x89y/6Hn9pUHni0HO816H1r0HOuAE6kmurOPpZbWydzSSIa33melvs8p4rf/ZKwm5hH 2+OINxB470Yc09k0Nw/h3Y1KmbrOJIHv7gnseqaRaWNuRmyqfaN9w8xIM9PdexOvrQSVoxT8dc+W w+NHnfA6HN2m9+PvxKfJ+E5J+xiJu2uqgWmeRfZ/8R16jvzTJJvCB7cZbRqblcClz8wDKGOQeRHf a7LpnXxV6NDz3F3j+HCK7XwC/hJ/RthH7AFzj+ntfGihu+MzjGN+0kzIPXkevzPgpHnAkTWuP/qZ xpPItTXRd90M1+3dbCfpTqUeZ3y3ObLpQvz+nKafQHeoRUJ3qCtdxjjLoDucplB7pynUw2kKPc9a sJupL7uH3UMvOzWhV9ij7HkaxHqxgTTGagrRZKspRFOsphB9YjWFaCr7gs2iz3gVXpV+4DV4TZpt NYVoLm/AG9BPVlOI5vHLeFNawB/mj9Ai3p4/QYt5X/4SLeUj+Ahazt/lY2gFH88n0O98Ep9EG/kn /FPaxKfx6bSVz+QzaTv/nv9AO/hs/iPt4nP5XNrD5/P5tFdoEdI+kSYK0gGrC0TG6QKR0wXyRRlR himnCxQ4LaCYqClqstBpAaU4LaA0pwVU0KkAFRItREuWLm4RrVhh++wFy7JaPayI1eph53kTvE9Z C6vVw26z+jzsTqvPw+7y0/wCrI2f7meze6xKD3vAqvSwx6xKD3vSqvSwjlalh3WyKj2ss1XpYd38 nf5+9pxV5mG9rTIPG2CVedhQq8zD3rDKPGy4VeZhI60yD5tqlXnYp1aZh82yyjxsvlXmYQesMg8z VpmHc6vMw4VV5uG+VebhUg6Tw7m2mjw8zWry8AJWk4cXsZo8vKTV5OFlrSYPLyfnyoX8PKvGw2tY NR5+vlwjf+e1rBoPv9Cq8fB/WDUe3tSq8fA7rRoPb2efxuDtAx5w/kQgA8U7BLEgxjsGqUEa7xSk B+m8c5AVZPOng2JBMd41KBmU4s9Y/Rzezern8Oesfg7vGVQNqvIXrIoO72VVdHhvq6LD+wQXBRfx flZLh/e3Wjr8FaulwwdYLR0+yGrp8MHBXUEbPsRq6fChQbugHX/TKurwt6yiDh9uFXX4iKBn0JO/ G/QKevH/BH2Cvvw9q6jDR1lFHT7aKurwD62iDv/YaunwcVZLh0+wWjp8otXS4ZOslg6fYrV0+CdW S4dPtVo6/FOrpcM/j2RHcviXVkWHf2VVdPjXVkWHz7aqOPxHq4rDd1tVHEFWFUcEVhVHpMWujd0u qtknOUQjq4ojLtdKp4prrB6OuEm31HeLx60ejuhm9XDEC1YPR7xo9XBEP6uHI/pbPRwxxOrhiOFW D0eMsHo44l2rhyM+1CP0KPGR1cMRU6wejvjC6uGIGVYPR3xl9XDE11YPR8y2ejhigdXDEQutHo74 Rf+ml4vfrJqNWGHVbMRKq2Yj1lk1G7HZqtmIbVbNRuxI4SmB2JmiU1LEgZSCKenCWAUbj6fsTtnt +amUyjxJnH0BhEoBEqVSGjGMrQVIYHTNRGoWFQXy5lBZpJfDS9HZdA4FdC4QLYIcdTH2XUj1MKbW B7pph27aoVsIdLseuf6FVyow7maUfQvdjhx3JPDuYdTzCF71qB21p0L0BF7p1IGeogzqDDQsDDTU lMlClkJZ7umwbJYGfCwCfDwbKeVZearEKrCKSD+HnYP4ucDNTIeb5wE3myG8GujZ0CmyZbKbgaGV HYZWdhhaBRjaEemdWHeqynqwHiizJ1A1G6jah6qxvuwVqs4GAGHPcwh7nkPY8xzCVgLCvof4SOBs JeDsdGrCZrAZVIt9xb6l2uw7IO8FDnk5kLcGwvOBv9Lhb4rDX+7wN8Xhb0GHv/Ud/p7r8LeGw9+i wN/3qDgfyUdSDh/F/0sl+BggckmHyCUdIp8FRP4E4VTgcjGHy6UdLucAl79H+APQ+Syg82yEPwKj izmMLuYwuhQwWlMZEQKpyzqkPtshdTkgdRZVENkimyqKIqIINbCojThQm8oDtc9GWF5UQC5gN51j sRu56og6COuKujhbT9RDWF/Uhw1wHCFwHCn2ObtG7jm7xu7Zukbu2brG7nm6i4DpnamO97TXnRiQ vS+FXj9vAJ3vDfQGUQHvVW8o1fTe8N6kDO8t77+U6Y3xxlEW0H8CVbZ6bVTVjgFU244BFLVjAMI0 P40u9Av4Beg8OxJQZYwEP5Hw5/nz6Cx/vj+fQn+Bv4A8f6H/M/kYIRYjZYm/BClL/aWk/GX+Mgr8 X/1fqZAdOShmRw7YrPXXUqq/zl9HaRg/fifmb/A3oq5N/mYq4G/xt1CGHVFQ105/JxX2d/m76AJ/ t78brdrj70FL9vp7Ed/n70N8v7+f6vh/+H+g5IOSUwEppEd1pC99YhiHFAHGZUAxGZFRCmVMxkhI LTUVlqEM6QKZIlNgg7GKUjFWFULedJmBvFkyG/ZFZFFKkzmyGEouLosjb0lZEmEpWQollJalYV9G loF9WVke9hVkBcqQFWVFpJ8jzyFPnivPJS0ryfNQfmVZGXmryCooraqsCptqshryVpfVKWrHRdRV S9ZCem1ZB5Z1ZV2UcKFsSL68SF4My0vkJaTkpfJStLmZbI7v9U95Hcq/WbZG7bfK21DL7fIulNNG tqW68j75AF0oH5TtUOOj8jGqJx+XwA35hOxA6fJJ+SRa21E+he/SWT6NcrrILiihq+yKEp6Vz6L8 brIbzj4nn0P5GJsp247NVAljcz+qKvvL/lTFjtCUiRF6IM4OkoMoS74q0fflYDmYasshcgiu8zA5 DOGb8i2qbJX1YI9RHCWMkqMQjpbwTDlGjkHesfJ9aig/kB+g5A/lRzg7Xo5H3glyAtInysmwnCI/ geVn8nOc/UL+j6rZsR/pM+VMWH4jv0H8W/ktbL6Ts2AzW85GS+bKuWjVT3Ie2jlfzqcicoFcQNXl QrkQucAVYL9ULkVpy+Qy2K+Ra1DOWrke9r/L32G/Ve6EzS65C1dgt9yN9uyRByjT8gmqAj4RIp6i ClBVVVAVomyVrjKpmspSOVRdFVMl6DywjbOptiqvKlATVVGdQ7XUuepcpFRSlekCVUVVQQlVVVVY VlPVYFNdVcfZGqoG0uuoOqilrqoLywvVhUivp+qhFvsMKbOshSpb1oIQrAUhWAtCsBaEYC0IwVoQ grUgBGuhLMtaKNuyFoRgLVTEshbEwVqotmUtlGlZC+zBWhAHa8FZsBaEYC1UzbIWqg7Wchfs2wRt 6AJwlwcoDB4MHoINGAzygsEgHQwGlk8HT6OcLkEXxLsGXZEONoOWgM3Avk/Qh6oGfYO+yAVOQ1XA aQYgZWAA7woGBYMRfzd4F3X9J/gPNbEsBynbgm0oYXuwHTbgOlTJch3KjtiFj4YRFmGUaRkPUsB4 EOKgSmA8GB8jaZE0qgbeU4hqR9Ij6VQlkhHJoAusniBVjRSJFKEikaKRoojnRHJQDlgRVQUruoZS otdGryUZvS56HeLXR69H/F/RfyF+Q7QFFbScCSndoyOIR9+OjkYczAlxMCfYgDnBZm+MEY/xWBGq b/kT1Yg/CWv5E3HLnxCCPyFsqVtSjr5J30Rn6Zv1zZSqb9G3UHHdSreiUrq1bk0l9a36VhL6Nn0n 4nfpu2DfRreBzd36bti01W0Rv0/fT6X1v/W/YfOAfhA2D+uHcfYR3Y6KgZM9jvT2uj3SwcwQdtQd EXbST1FR3Vk/TSV0F90Vls/oZ2D5rO6GGnvoF5DSS7+IksHeUEt/3R/hS/pl2AzQA9HmQXoQynlV v4b4YD0Y9kP0EMRf16+jzKF6KM6+od+gcnqYHkblLeejs8H5RlBF/bZ+mxrod/R7iI/UI2EzSo/C 2bF6LML39Qd0jv5Qf4izH+mPcXaCnkgV9CQ9GSlT9BSkgCkiBFNE+IX+H5XRX+ppsJmuZ1BZ/ZX+ CpZf669Ry3d6FlJm6zkoEzwS5c/X8xEu0Aths0j/grOL9WKUs0QvRXyZXkZVwS9/Q2nL9XIqZ1km FQPL7EpFw2fCZ6lk2C3EVQLj7EHnhD1DXKuwV9iLioe9w95I6Rf2p4rhS+FL1MAyUaSAidI5lolS QctEiVsmihBMlBwTpYKWiVJlcKJzHRNt7Jgodxw0zjjjXDOWxCxDuhGv0HHKix2nvDSJU17mOGW6 45QZjlMWdpwyK0n1wHeqB9KpHvhO9cBPKL5Y1QPfqR74TvUg6lQPfKd64DvVA9+pHmineuA71QPt VA98p3rQxKkeXOJUD9Kc6sE/nOrB5U71oKlTPbjCqR5kguPGwDhDFjp2mw12ixfVcBy3JjhuM7BJ y2KbsevYjUi3LPYCdhe7i84Hf30U4WOsA9VhHcFlzweX7UF1wWJ7Iv4CewH2lsueDy47kOqBxQ6h +uCvHyMcx8ZRAzaefYazlr9e4/hrQ8dfL3L8tRH4axXyHH/1HHNNdczVA3PFLwTmehkV4k3BXws5 XYa4Yk2K02VIcboMBZ0uQ4pjt1c6dluL9+TP04VWdZiudhw3xzHac/hYPpYq8IlgtKUdly3ruOzZ /Fv+LZirZbEl+Rw+B+nzwFxLOq2HovxnvgRcdhlfhtDqPlR0Kjjl+Uq+Cilr+BqEVgunmNODKMU3 8k2IW1WIMnwr34a41YYox/fzA4hbhYji/CA3VMzpRJQQTHDErVpEGeELH3GrGVHCaUaUEjERQ0oq eHMlx5irOsZc3THmq0RRkYN0y5sridLgzeeJcuDNlRxvriwqioqInyswkwKHrk7VwKFrIV5b1KZz xQVg0pUck64iLgSTriQaiAYo3zLpSo5DN3cc+p+OQzd3HPqfjj03Bm8eAN48EFy5gOPKhR1XznZc uaY3Hlz5AnDlaVTXm+59Rw0cY74oScnCd0oW2ilZpDkliysch77Ucej6TtXiEsekazverBxjVo4x h44rK8eVC/sr/ZXgwav9NUix/DjD8eNLk/hxYcePs/wd/g6ElgE3dgxYJTHgxo4BcynBgJXjvspx 3yzHcRs7dquSeG2W47KNHYtVjsUWdiy2MZhrJZw9zFkbO7YakzVkDVjWlDVhaTlrY8dW49xUOT6q HAe92HHQS5M46GWOg6Y7DprhOGhhx0GzHNfMkr1kLzDX3rI31XBcs7bjl3XkADkA6ZZfFnH8sr4c KodSI8csa8i3wCzrOGaZ7ZhlXfmOHEkNwC/HIMVyymaOTdaVH8uPkctyyhqOUzYDp5yIvJPALLMd s6zpmGVd+aWchhKmy+mw/0p+BXvLLLMds6zpmGVdxywvknPkHJRg+WV9xy9rOH5Z1/HLeo5fNnL8 sohcIpfgrGWWhzjlBrkFKZZZ1nTMsrZjls3kQXmQ6jhOWcdxyrrglJmIWzZZz7HJ+qqkKksNHKe8 yHHKaxynbOgYZH3HIK9xDPIixyCzVS1VC6FlkI0cg7xINVAN/g9r3wPV1nXmeZ8Q4pnIhBAHU0Io IYQQQgklDGUJJcR1KaWEutR1GeoaAUIIWe8P0tOTkIT0JIQkU5YhDKWUpa5LWJZxCcuwDEtZl7pe 1sNQDuUQj5dhGZa6PoyHw3FZlzJehyH73StBcNI/mXP23PP7vct9T1fvz/e+7/vpvPcBc+J6K0pS byWU1FtRknorSlJvJfRI7ahiUm8llNRbCQ0rCyuDb8dVV0JJ1RUlqbpSSKquRJKqKyWk6spJUnXl JKm6EkqqroSSqiuhpOqKklRdiTxSdUVJqq7QpOqKklRdOUmqroSSqitKUnUl9EjVlVBSdUVJqq6E kqorkaTqyklSdSWUVF1RkqorJ49UXQklVVeUpOpKCam6EkqqroQeqboSSqquhJOqK0pSdSWUVF0p OVJ1JZRUXVGSqiuhpOqKklRdCSVVV0JJ1RUlqboSSqqunCZVVwpJ1ZVIUnWliFRdKSZVV75Cqq6U kKorJ0nVlVBSdaWQVF0pJlVXSo5UXQklVVdOkqoroaABIIuFjP9FlE/y+zfol+iX0OuQ5aegXPoV +hWUTafRn0FZkPGnw3gGnRHM+7PoTPo1dIpk/1l0Np0DjDXAm/Tr9OswTwFdAFxIfwm4iP4KzFZC vwXblNKloBm+Cnrgdfqb9DdhHOuBz9OVdCXsSTVdDdsHalNhhfAmKAQdfEtAITTQBpjBSBvhUyba hApoM22GkSbaCfuPdUIO0QafIrWssohCyKXb6XZgrBNOEZ2QS3+XBv9AdEIWUQiv0z+kfwgj79Dv wLdjtfAmUQtfp/+Kvgqfwprhdfpd+l3Y5j/To8BYP7xB79A7MAPWDzn0+/T76PNEP3yV6Id8oh9y j9HHaJRF9EPOsfBj4dA/Dvoh99hTx56C7bGKeJOoiAKiIk4diz4WDRrj5LEY2PJToCWyiYr41LGE YwnoDVARZ9GTRDk8CZqhHD0dXgHK4enw8+HnYaQmvAblhevCdcD6cD0wG84C8+E8sBAuAOMKOxGk wk4EqbATRSrsRJEKOxGkwk4EUSByojHeeuLZJxLR554ofuJrKO8J9RNWdCZYCQyrjhBQGq8gOdES rxAt8bKylmiJeqUOMl2sH54nyuEVUA4c9HllA2TwolKEEawZXlDalDYYaVI6IZvHOuFFohNeITrh ZdAJrTDyHVALLxO18JLyL5R/AdtjnfCK8rvKblj7PdAJL4FO+D7MhnXCi0QnPE8UwgtEIXxG+SPl j4DfUb4DjBXCa0QhlCr/ChRCBiiEYRh/VzmCXiUKIYMohEyiEF4DhfBfYGRc+TcoTTmhnIAtf6L8 CYxjnZCuvAY64TPKaeU0rJ0BhfAq0QavEW1QqpxT/gLWzisXYBwrhEzle8r3YEusDV5T/oNyBcb/ F2iDTNAG/wizrYFCeI4ohFeV68p1+F6sEz5LdEK68tdKyLVIzaNUUkctRbmp3IIRXP8oQXlfuQ19 XAUpiVRBSiBVkFJJFaQEUgUpntRRe075r8p/BcYVkVKVHyghEyN1kRIhQYZMjFRHiic11Z4jNZKe PU4fp6GPKyUlkUpJqaSyWsrxiONPwjiumpR0/OnjT8MIrp2UTGonxR+POR4La3EFpVRSQSmJVFBK JhWUEo9Dg7W4jlISqaOUQOooJR7XHdeB/sGK6EVQRC4UB4oI7OG477gPvQSKqA3GsQrKJPqnFPTP d6HffbwHvUpUUObx3uO90Mf1mJJIPaZnST2mVFKPKZnUY0oKVGtD1LMP4iRYKkNa0f9GSFUBUAE0 AD3AALAcLqmGQVg6gmMeQCugA9AN6AP0A4YAI4BxwBTgOuAmYB6wBFhGMjdLgFRrBDK3ALBC/y5g E7AN2AXsIVQlA9CAiMB3V50AxAISjiyTj/ydFpirKhOQA8gHnD6yLAacAZwLfgYvzwOqAVoA7FeV cLiUuSUCqmEYMAZ97+FYAG2AzmDfCugJ9i8HMRDEVcAoYAJwDXAjuO0s2R5V4X3GSy+gDdBJ9iuw 7QLZDlX1AC4DBgBXAaOAieD33YL+NcANAN52AYDHVoLrV4JYhzGMDTieScD04bGgqi3AA8BDwD5C 1XJAOCAycN6rowFxwWXih8vD7VMCNoCXZPvIwN+H69MBWYBcQAGgEFDy4RJfv+oyQPmR5QWA+shS B+APlzL3RmC/q8XAsVXbg/O4/20gdn0UngDwfjw2X9lH4Ae0B5f+j80jc+N96wL0Bq5N9RXA4JHl MGBM/lRlLlvoFFRr3B5mXkaYBr7LRwBv8ieAt/lY4F0+AXiPT3YK+FPSTpWMT5MeVRawJU5rZSFb 5pSqaD6TcM5hP4LPd0p4rQtVlrDlTm/VCf600xvoB7mMveBsq4rliwmf+Ug/gT8HnMyfB07jq4Ez ea2zDX/KpagsZ9XOzsoLrM7ZU5XDs8D5vAB8mrc6e/C4S1mpZnnn5apiXgI+w3tdUZU6VnQOVJ3j 2wh3Eu4BPs9fBq7mB4C1/FVglh8FFvgJYCsrumKqJP6aK76SZ+3Oq1Ve/obzaqXIup2jVW2s25VU aWf9zomqTn4WuIdfAL7M+l2pVQNk/DLmSjfb7rxW6We7nDeqrvK3DnmUX3HewOOujCC3s73O2aoJ WIt5/bB/jd8AvsFvAc/yD4AX+IeHfIvfd2VXrTTIXXmVXewV50LVekO4c4HMdis4stEQCbyFGY+4 TlX2soPOlaoHcM4xFx/08birqPIKO+xcr3rYEO1cx31XadV+Qxz0B9kx50a1vCGRcMphP7whHTiy IQs4uiEXOK6hADixoZD0S4BT2DHX2cphdtK5VTnGTjsfVKc3lLkqHuOshnJXReUkO+N8WDnNzjn3 q3MbLhBWH/YLGnTO/coZdlGSVxc28Idc0iBK8so59rYUrhu13ie8Q/gR8IQNAV+zKYBv2JTAs7Yo 4AVbjBSOP+Up1d2yxfuGKhfZVSmy8jZ7R4rWrdiSgNdtqYRxf8OWIUXjtb6RylX2nnNUt2XLdo4G +kG+w96X4nQPbHmET32k/9BWBLxvK5XiLsptZ4HDbRVSHP6Ub7zyHrsjJVbeZx9JKRcjbSrgaJsG OM6ml1LwuG+qcodDUvrFRJsBOMVm8V2vfMQppKyL6TYHYQ/hVuAsWwdwrq0buMDWB1xo6wcusQ1J WfhTvpsXy2wj3jsqpCqSci+W28alXJWCU0oFmH3zKiUXJRVevGCbAlbbrkuFeMS3FBgPchQXI5Wo Yrh4qeyiznbzkHnbvFSGx33LQY7nkqTyi6JtifDyYd9uWwN22+4C+22bwO22beAu2y5wr23Pt3bx il3mu6tK4lKlCxcH7bR0gcymDo4M2yMOGI/4NlWpXIakuzgG1w7YfuKgj8d926oMLhsflz0W9h/6 vqWLk/YE6GdzeRJ/cdqeTDjtsD9jzwSes+cAL9rzgW/bTwOv2ouB79jPSDz+rG9XlcedkkTVKa5I sl+8Zz93yPcJ79jPS3Y4t6Vwhou4s5L74iN7NWHtQV+P7KzkrrzHVUiJeoVdOGSl3Solqko5leSv LmuwE3Yf9ssb/MAXGtqB1Q1dwLqGXmC+4Yrkx59yqarFhkGXRnWW00jtqgpOL3VV2xuGgd2E/YTb G8akLrzWpVepOIPUq1I1TGLG/equhmlpWKXhLM7O6t6GGcJzH+lfaVgEHmy4DTzcsAo81nDH2Yk/ 5TKo9JxDuqIycB5psHqy4R7wdMN94JmGHeC5hkfSoMrCtUrD1YuEbxuQy6JycB3SWPWqQUFYSThK GlM5DDHQv2OIB75nSAK+b0jF41yHy1G9Y8iAkUeGbJdH5eG6pckaZMgDVhhOSZOqVq5Pmq5Rcn2u 1pooQ5E0rerg+qWxmhhDKXC84SzMAyMuB+GOwFpVNzckzaj6uBFpuCbJUHHIqQYVnBkYd3XXZBg0 rr5AX9XPjUtzNdkGPWHDIecZLMCnDA7gIoMHuNTQCnzW0AFcYeh29deoDH2uIZhnSlqs0Rj6pUXo Xwce4m7CHuoNQ4RHYK9gBPZzhJuXbtcYDOOPMx53jdRYDFOu8RqH4bqUpRrnlqTVGo/hprSK+64p 1bhhHvpT3DI5oiXCH/ZTDWvArYa7wB2GTeBuwzZwn2EXrlGXYQ+OHT4Lx3udW3OuqG5yd6U7Nf1G 2SEPER4x0tId1Ty3Kd1TLXHb2AaMEYRPHHDNuDEWbGCZ25Xu10wZEw75ujEZ+KYxzXW9Zp4tdN2s WTJmQn6Cc4P5mmVjjrOtZs2YD3zXeDoYwZdwHHQt12wai52zNdvGM85ZEonWanaN53BUMp53btTs sXOuu2qZsdq5r6aNWuc+uV821RFGFu4dbLfb6hNGwdmpjjVagROMUtDGdvH1de2pk41eaU7Vb2wD hvPglqnTjJ34nBh7gMmRqjONl4FzjAPSII44vj19lF2C6AOe3y/Tx9i9Upw+3t4GnGTvDPhnP429 nD9Cn2rvkcr1GfbLUjn2M/4T+mz7APY59qvA4En8sfo8+yh4j1P2CcmNLd/lUOcbr0ol6tPGUTet LjZOuCPUZ4zXnOvqc8YbTkl93jjr9KqrjQvuE7DNLdhGa1xxx6pZ47orSi0YN6QutdW45U5QS8YH zh611/jQuaVuM+67k9Wdgtydpu4Rwp2j6stCpDtTPSBEu3PUV4U456x6VEh056snhBT3afU1Id1d HMg31DeELPcZ9ayQ6z6HMwpXqXpBKHCfV98SCvFVEErc1YHIrl4RyoDXhXLgDeGCW6veEtRuVv1A 0LkF9UOBd1vV+4Lolmrlgt3trQ0X3O62QE5bdU7ww9UnuVMgS6mNFNrdh3mj0OXsqY0WeiFSg224 e6pmhSvunto4YdB9uTZRGHYP1KYIY26hNp1smSVMOm/U5grT7qu1BcIM9AuFOadQWyIsApcJt51t teXCKvAF4Y5zoFYt3APWCfeds7W8sAMsCo+cC7V2EwJ2mxSwP36TErjdFOUerSo2xTgv13aZ4t0T tb2mJMg94Ay4r9VeMaUGbVtVO2jKgHmGTdnO/doxU577Ru2k6ZR7tnYaZ5i1M6Yi90LtnKnUfQvf F+6V2kXTWcjSIVd3rxPeqL1tqghk4O4twg8IPyS8j7+lWR7g2lWTytlZe8ekgWO/Z9LDvt1n+ebw 2h2TIdiPJByN76/muNpH+EzifLg5kXAKznub0zXIZGlOJ/0swrkahcnhvKZRmjyQD0NW3FygiTK1 BnLg5kLCJYTLqjZMHc4FTYypGzgeM85am8sJX9AkmfoCmWqzWpNq6neuaDJMQ8AwDiPZppFA1tqs I8wTFvFd32wn7A6wJs807tzSnGInm/2aItOU84GmlJ1ubtecNV13PtRUmG4Cq0zzzn2NxrQEuSVc l+Yuwr0avWnZHVGjMYFX1BhMd5uvaCymzeZBGAGvqHGYdmHPPaa95mFNqyhrHtN0iLQ0rekWI5on NX3iieZpGI9tntH0iwnNc5ohMRm8OvHemhExrXlRMy5mgjdeEnOabwc8oWZKzG9e1VwXTzff0dwU i5vvaebFM833NUskB1gVz0EsCEQZ4rcDMVqzLJ6HiA/RtnlHs4ajreauWA2RDrxW86OaIlHb/Eiz KbIepNkWBWlSsytam+8E4nJNkijBseyJXpxLiG2Sv04mduKYLvY4O+to8fJBtK2LEAdw/BKvSnN1 J8RRGIkVJ4ATxGsHkaIuWbzhUdSlibPQzxQXPMq6HPGWJwofnSemLl9cCXpaQ91pcR3mKRY3pMG6 M+KWJ77unPjAkwRn5qEnte68uO/JqKs2yz3ZdVpzuCcPnzfPKTJPUQ0yR0qTdaw52lOKfbjnbDDb AfZUEFYdZDWcwaMhTPIcj4GwBe+Dx0HYUyeY46QrdcXmRNgTK85G6iSu1S2r85pTAn1PK+EOHAs8 3djrerrr2sgZhuzC00e4n+QPu3Wd5nSIF9D3DBHurusxZ0kzdZfNuZBRQF7hGakbMBcEsgi3DLNn nHBHTZK5UFqEtSXAV81lwYi/i9kzVTdqLg9Eec/1ugnzBel23TWzGhjGYeSGWReI8p6bhOcJL+E4 5Vkm3EF4rW7WzEPshgjerK5bMIsQqSGOe+7W3TLbpXt1K2a3dK96xuwH25gyt0v3yTnfJLxNzsN4 3bq5S1qt2zD3SnfqtsxXIKaTLLTugXlQytIX2a/5E/Sl9huePf1Z+6w/WV9hX2iZ1avst/xpeo19 xTmq19vXyTYbsI3BvgV5r8X+wJ+pd9gf+nP0Hvu+P1/f2iT3n9Z3NIXDDN1Nkf5ifV9TtP+Mvr8p TirQDzUl+s/pR5pS/Of1403pEDenmrL81frrTbnOLf3NpgK/NqAO9PNNhVKhfqmpxM/q5+0JviX9 clOZX9CvNZXjqNp0wW8N5uF3m9SEdcCbTbxf0m83iX6vfrfJ7m/T7zW5/Z2MrMnv72Hopnb/ZSai qcs/EFCgF9ObekFzBZQO0RTMiaYr/qsBlcfENg0CJzQNgyLAsX70or9pzD+qVzRN+ieY5KZpv5dJ a5rxt12MJFtmNs15x5icpkX/tYDO0o02geZl8ptWQc8+aLojxTGnm+6Brkxvui9lMcVNOwffzpxp egT7QFQSc86BQDEF9ue8QwFc7VD6b1xMdERJ6YzWEeOfZVhHvLMTnwH/AiM4kgK5im+csTpSYTbJ kSG5Ga8j23+LaXPk+VcCepDpdJzyrzM9jiL/Bs5z/FvMZUcpxDVQ1v4HhB8yA46zAb3s38fcnILZ lYT5khx/yyXyXZci9UoHnH/mqgO0MDPq0EjpWP9eimYmHPpgP45wIs6XLh2cSVCvl9IJZ+G9upTL XHMYLuWSfgHhQuaGwyKVMLMOB6hX0LCXSpgFhyegWC8FuJww6EpHK5yxW46OA8Ya07WH+ZKaWXF0 B3TlJR2z7uiTdMyGox8YxmFkyzEU0Jjw7ZgLCBOleYloxksiYTvzwDECyhH04yU389AxDjoRVOQl P7PvmJIKWLnjOnC44ybkeArHvJSIr8uldsJdlTuOpUu9bKRjWSpkox1rkp2Nc9yV3GyiY1MKr3to Hpb8mlbzGHitffMk5KgW8IrDWrl5unlVG26e8exqI81zrm5ttHnRZdHGmUG7HfKqZ0+baL7TIgO+ R/g+cIp5p4XWppsftURos8yLkLETTadptSCYOdeiaDmhLbAoW2K1hZaolgTNEPafmOFbSiwxLcna MkNGS5q2HDizescCCk57wZLUkqNVW1Jb8rU6S0bLaS1vyW4p1oqWPGkGc8sZ7CdbzgW1FWGt3XLK +VDr5sZbzmv9lqKWam27pbRFq+2ynG1htb2WihZBe8WiAu61aFqs2kGLvkUi7NUOWwwtbcAW4DGL wz0K7HGPYl/a0qmdtLS29GinLR0tl7Uzlu6WAe2cpa/lqnbR0t8yir1oy4T2tmWo5Zp21TIi8do7 lvGWG9p7linniva+5Tr4wGLLzZZZ7Y5lvmUhEKEwt9xSLYs3WlZUy5allvVA5lY7Z1lu2dA+sqy1 bNUjy92WB5Xtlk3nbL3Cst3ysF5p2W2h66Msey379TGNMve5+vhG2iuvT2qM8IbXpzae8EbWZzTG eqOPzlaf3ZjgjQNO9ibW5zWmeVPqTzVmetPrixpzvFn1pY353tz6s42nvQX1FY3F3sJ6VeMZb0m9 pvGct6xe33jeW15vaKz2XgDWetX1lkbWq6t3NApevt7TaHVp6lsbJa9Y39Ho9drruxvbvO4g9zV2 ev0Ba6neaezxttf3N172dtUPNQ54e+tHGq96r9SPN456B+unGie8w/XXG695x2CeGzDPzcZZ72T9 fOOCd7p+qfGWd6Z+uXHFNVS/1rjunavbb9yQ5urvNm4BbzY+8C7Wbzc+dK4D7wPvWuXe2/V71nDv qk5mjfTe0dHWaO89XYQ1zntfd8Ka6N3RxVpTvI90CdZ0SadLtmb5kC7Nmivd1mVaC1oe6nKshT6F Lt9a4h7VnbaWwb6Rb9EVW8t9St0Z6wVflOqsVe2LUamsOqlXd87K++JV3VbRl6Tqs9p9qcBuaVF3 3ur3ZQC3+zJUI9YuX7au2torJaqWrVd8eTqtddB3Ssdah31FOsE65ivVWa2TvrP1/dZpOEvAvoqA 6tdJ1hmfSue1zvnI7zY+kqv4DLo2zuGzBO44nGO4UoO/VDx+d0wFfisI/DLQ0qnrtC76HDi++zxY g/tagzZJfh3Cvy24unU91tu+jkAmprtsXQUesN5xGYK/3pDfVbRyTu/rxneHry+g+nVXrfd8/UR1 7iIZOkltU/8HIep3FPxFPaLeR3LqAxmFFLJQmQIdkz0hU6InZJGyp9Bx2TOyaPSkLFb2LHpKlih7 AT0tS5G9jJ6R/UD2A3QypCjkyygmtDD0Syg21BBqRHGhPw/9OYqPgIY+HZEQ8RZKiDgTcR6VRlRG tKBvRbwd8TPkjpiN2EJ/HXE/Yhfdhr35GpKT91cj0JPoGHoKnUVPoHOoGn0VqdF30Hn071E78qAO 9B7yor9Hv0Jz6NdUOPqflJI6jj6gnqSeoSgqlkqhaPz8InWSqqDqqDiqnvJSqZSf6qKKqB7qB9Q3 qL+hfkl9K+TdkHcpUS7ITZRZLsndVKPcL/8OZZe/LX+bkuTfk3+fcsl/KH+H8shH5KPUJfmE/CdU m/xn8p9RHfL/If9b6m3y9l+XfEn+HvU9+Zp8nfq+fEP+z1Sf/Dfy31BX5L+T/wv1I/w0GzUQ+nTo 09R/Cn0vdJ8aUoQqkqhbipcUL1E7ipcV6dTvFJ9T5FLv4zcVqA8UX1CclskVhYq3ZArFVxXnZRGK KoVaFqfQKAyyBIVJ4ZB9RnFJ0S77nKJD0Sf7vOKHikFZMX4PQFamGFH8QvZ1xYJiQdagWFQsywyK VcWqzKZYV6zL7Ip/UmzKmvDzUjKX4reKHZlXsavYl/nDUNhx2dthUWHPyH4YdjLsBdk7YclhfyYb DXszTC+7HmYM65RthX037Lsh+FmfvpDjYT8OGwl5Gv8/uJCTYf81bDIkLmwq7Och8fh5nZDksL8P Ww7JClsJ2wjJCfvnsH8J+SKdTI+FnKV/e+z5kF9FvB/xvhy/8aVHfmAlisdvBL+5DdhD6FQmIBkl s/1f1rFD7Ag7/uVhdoq9zt5k59kldpmjvyZwEdwJLvZrE1wCl8ylcZlcDpdf8uit+C/1l15j195C 7F12k91md9k9TvZW/FfawKrkYOPbxMZ/hyjqA+oDJAOLjkQhsO458kQokv1Y9mNEyd6VvQvrRmV/ jUJkP5X9FIWSJ0IVsl/Kfolo8i7TMdl7slsonDwLqiRPgR6X/Ur2KxRBnv98UvYb2W8O/vtXCBVC Hf63w9AQBYom7z7FhESHRKNPhcSExKBY8sTmsyEpISnoOfJeU3xIXkgeSiBvMT0fUhDyJkok73gk kWc2XoT9V1JR5MxhRmwcgvyBTWRT2HQ2i81lC9hCtoQtY8uBL7BqVsfyAJG1s27WD+va2S62l73C DrLD7Bg7yU6zM+wcu8jeZlfZO8D32PvsDqzbYR9xiIOsjIN8i4Nsl4Os6bF2nYNciIO857CVcme5 Ck51pGk4PWfgLJwDtv2w3eTmgT1cK9fBdXN9h62fG+JGuHHSpmC+JRjL5paht8bdhd4mtw1zZnO7 3B4v41rh+Klj+qDXwO+VP0XOSQy0EBQHTY6S0UsoFKVBC0OvQqNRLrRjKA9aOMqH9gQ6jb5I3h/8 CnidwJuDf44qyJuDF2A+NbSnkRbaCWREAnoGNSIrOomc0D6FmqHFgj96Gz2LvgftOfQfoMWj/4gG 0afRj6E9j0agJaKfQHsB/TdoSein0F5E/x3NwP7NQUsh/7/zZbSM/gGlon+EloZ+De0z6J+gpaMH 6Lew7w/R/0WfRfvQXqNkVBjKosLB9+WS57hfB98XifLIc9z5VDz1PHqDeoF6AX2BvLF4GrzhGfRF 8n/uCqlvUyr0JaqaqkZfIc90l5D3E9+i9JQelVIcxaGvUiZKRGeoJsqNysB3elE5eM9L6M+p71Bt 6FtUB9WBvk3eT7wAnnQSVVJT1BSqoa5TP0dq6ib1t0hD/R31d0hL/YKaR/XEfi+CF0hBejqVTkUc eXqOpz9LZ6IG8sSckc6lc5FA59P5yETelxHJ83FmWkVXoUa6hq5BNri2G2iX2H42rnfDRAFiAPGA JEBqEBlBZAPy0DeZGCaeSWJSmQwmm8ljTjFFTClzlqlgVIyG0UMzACyMg/EwrUwH0830Mf3MEDPC jDNTzHXmJjPPLDHLzBpzl9lktpldZo+VQaPZCPYEG8smsMlsGpvJ5rD5zE32NFvMnmHPsevsebaa 1bIsK7BWVmK9bBvbyfZAu8wOsFfZUWgT7DX2BjvLLrC32BVoG+wW+wD/X7TQ6tB6CILfjrgAFisD +/z/Zd9vQXuSWHkksfKniJU/Taz8BLHyZ4iVRxMrjyFWHkus/Fli5XHEyuOJlX+aWHkCsfJEYuUv ECtPIlb+IrHyZGLlLxErfxnNQ0sltv4KsfU0YuvpxNZfJbaeQWz9s8TWXyO2/mdg6zKUTez7c8S+ /x31HBUPdo8tO49Y9ueJZeeT9xTeINZcQKz5TWLNp4g1fwGsuQnuASflhHsAv63wJWLNRcSai6m/ pP4S7gds0yXkPYW3iDWXEms+Q82DHZdRC9QC+jr9Dfob6CxdQVegb9D1dD1+4zhSimyF66SEc/8E ooQxhPStgA5AN6APxiZh2Q8YAowAxmFsWv6Uvk3oZpP+OMg2qWK6vlPo0/cI/WzG48Bj+svCEJsN yBOzMPQDwgh76o8Db6O/KozrR4UptuhD4L/1E8J1thRwVszVXxNushV/HGQblVigvyHMsxphXj8r LBEsCMusHmAQC0nfIpawDrFMf0tY068Id1nPhyB/t4rl+nVhk+34E+gWL5A5NoRtgi1hV/9A2GP7 AsB9/UOTjO3/EPhv/b6JZodMNF5iMHJTBDvyp4G3Y8JNJ5hIUyw7/jiYaFMCE2dKZqceB5NoSmOv fwgmxZT5SWDsss4z6aYcJsuU/3uRazqNYey1LmEwBabiT4RC0xmmxHTuD8F4xbrMlJnOfxIYBhpX mXJTNcEFk5ZAbWIxjIPWNbw03LIqjcPWu4zOJDC8yfpRGEYb7zGiSfpTMI5ZN42T1m3GbvISuE1t jN/U+RjaTT0fQ5fp8mPoNQ18YlwxXWUGTaMfw7BpghkzXfsYPnquJ003PgnYm6KamTbNMjOmhd8L WMfOizp2SeTJdnOmW58Ii6aV32s7eL5lwJooMrdN658E7F3RzqyaNg5xx7R1CLx+E7Atukl/V/Sz e2I7c8/0gOzvR8DJxC7Sv296+KfA0WIvFyFeeWyOHdP+Y3gkyj8K7oQ4yMWKwywSw7kEcYwsk8XJ 37c/fwisQoxklWL0xxAlxrExYuLHEC+mHAWXJk4f+PbHfHHQVx74OC5TnDnwQVyOOHfUjxzaydHr enBdDs5Rvrh4eG5Pi7eP7hPxJdPgU8AejTMBuzTOBe9hfF8tAm5bd7G9G1cBd6x7B/ZsvAdL+B6u WFzlzoh3uHPiPe68eJ+rFndwfOG04iM8To4NYgTHmhGOJZxgVnBWs5KTzFGc1xzDtZnjuU5zEvbt +Ji5HnMqd9mcgf0zN2DO5q6a87hR8ynil8Gn43PBTZiLsO/krplL8bzcDfNZbtZcwS2YVdwts4Zb Meu5dbOB2zBbSIzEMQjHBHwOt8R07oHZgeMY9xDiz8F53jeX8nKzB8+B1/Hh5lY+0txBYs9BrD1y jQ7nxAjGlINYgPcLx0Y+2tzNx5n7+ERz/+F1xtvDtcPXnk8xD/Hp5hE+yzzO55qnyFgBxPDOAHC8 xnH7MQwE4jJfKIyTeAzfcxCL8ZIA7Icc20diLF5i8CXCGgaOjwdx9QB8mbCNcRgjccwMxsajsfJo jDyIkwfgyyEOQiwksQ/iIX/BlIBB7BbHucQAeLX5OrZLXme+yfPmedIXzUu83bxMbBb8B+82r/F+ 812yrt28SZZd5m2+17yL71v+inkP30/kuAYtMn7YQvNjlghyXxzcB0G/iH0pP2k5gf0cPw2+KXiP 8DOWWOy38OcPfODH7q2P3FeH/iV4b+E5sN/k58QdftGSgPfx8POwPb7f+NuWZH7VksbfsWTy9yw5 /H1LPt5v7JPwMfA7ltP8I0sgNvwpHxTcrwYU9OMHfmn5yDbBfSbH+hF/fHg82A8f4A991x/wpw2K 4FIphuNrcYCP+cmjvhL7xwMfecQf4m3JPHgb7JvgHDREicPG+zYZvsbGHRuNj9P4yBYhINsJQWGL xePEZ/0/9r4GOqrqavvOzL2TEHEMMfJnRH5CihECBggYEREDIoTJ/KQRaUBMcObOnZkwmaRhZoIB KUakNAVKIaUU8+ZFysuLgBQREREpIqUUEVOKFBVpzAuIiIgYIYzf3s+5+SHikq73+9b61mrXWfuZ zb777HvOPvvs85NZQyCytrRjeU/sXyjuWLc0oTwF+w3ad5R2Le+PPQXltNIe5enYp+l7gtLk8uGl qeUjef0vHVSexbmuNKMcubB0RLmNiedo6ejyvNJx5fml1vICzsOlueVq6eTyIuzJKF+WTisvRV1X eaRlz8R7Hn2PAlu6DX5W6iufU+KILEC7mvd2zXsDR2sOBjXvYfS9B9uCjWB5ZbB72IE6zfVZn3M0 /5vjgn3AfQuVL4SM943NpO8Tr6Eb2Qty25r3dG32dS3E+7lmar+va96jXWdvVloh6Af3Zrz3arv/ 4j1X876r7R6L28p1WafZJ/rcKu4asuGzRyivODmUj1jlPU/zvEoNFRQPCqmgjFBR8YhQafHoUKR4 XGhOsTVUCcoNLSyeHFrSNt6Lp4WqQa7QKp5fxb7Q6uJgaF1xKLSpuCK09brzjc4HxfNCO4oXhHYX LwrtK14WOtg834pXhupa+NrQMdDa0AkmzL0NoYbiLaGz+NweutA8B4t3hRqL94aixQfCcsv8o3lV fDgch/YcDcdzzir+MNyZ155m4j1lcX04qfhMuDf6fD7cr/hSOI1zF+eP4qbwEF5TmvWDxnBmMDY8 KmgJjw0mhrM5HoM9w5OCKeGpwf7h6cH0sMb7guDwcIDtsP+CI8NlwazwLOxtafyD48Nzg7bwfFBe uIp9zr4L5oeXBgvCK4JquCZYFF7DuTtYGl4P/Uh4c3BOeFuwMryT94DBheE9zbk5uCS8v3ldClaH DwVXhY/weSS4LnySzxTBreFzwR3hi8Hd4cvBfRGJ/Rg8GDHzeYTX7uCxSALbCJ6IdOVxDjZEevC8 Cp6NJAcvRFKDjZFBwWgko0SOjCiJi4zm9Z2flcRHxvGcgx61u6RzxFqSFMkt6R2ZzG0v6ReZVpIW cfGYlwyJ+EoyI0HuV8moSKhkbKSiJDsyDzlBz7mcJ0smRRbxWlkyNbKsZHpkZYkWqeV8V1IW2VAy K7KFY5f9xXzJ3Mh2xDPFQsn8yK6Sqshe9qNklAyWSssiSfr3X1D+hf6Ccla60Pp3AE+25PMEPGWe WZ65nvmeKs9SzwpPjWeNZz3hZs82T7ZeykA7PXs8Dr3s9xzyHPEc95z0nMrb4Tnnuei5rEmaOa9B 66glPNpZ65p3QuvhmS4KaRBpyVqqRxMlb9+j8dogLSNvqzZCG62N06xarjZZm6a5NJ8W1EJahTbP M6m5kMYCbZG2TFvpmSqKVqut1TaQ3ha0j1vEmvyM30hv4Hv+m9dRbD/yf+UedCLNjRwqnXAPmoB7 0FtxD3ob7kE7S6qkSV0kH5XuuA29Hbehd+A29E7chvbEbWgv3Ib2wW1oMm5D++I29Ee4De2H29C7 cBuaitvQu3Eb2p/m3AEpTTpI5R7chqbjNnQwbkOH4jY0Q/of6bQ0TPqUSibuRO/Dnej9uBN9AHei o3An+iDuRB8y9DD0kLJwJzoGd6JjcSf6MO5Ex+FO9BHciY7HnegE3IlmG54yzJashqcNT0t23Ik6 cCfqxJ3oj3Ebmkcz/RXpUcOrhlelybgT/QnuRKfgTvRxeYH8c2kafiuvQN4mvypNp3m9V3LJp+TT kkrz95LE4xeSKlpjVU2U0tVEtbvaU01R+1NJV4erI9UsdbxqU/PUfJQlarW6Sl2trqOySd2q7lB3 q/vUg2qdegylQFXVIrUU9furEeActZKwgMpCLhw3xrspbgbocZOA93PEGGmMfkTRw7Eik//TKXo4 VsyIlRiKlDEUQ3xn3oGiYzLFEMfHTYiPjrgnv5n65aVI4miIp1hYTPHEcZBAUbCG4okjIFF6icpt iIDOiIAuNP57KG75Prwbjfn7FGE86rdj1JNwB34HjfwZqQfGuKchnsa4F0a3N8a1D0Y02fC4YZrU FyP6IxrRgNTPUEYjmopb7rsNC2kU+2MUB+i/I8l32gMNrxi2SYMkQ2xG7IjW8XDnyZ3cee2LOled 7853F7gXiqJWufPVpVzcavuirnAXuUtFUWvcEXdEXUOSdkVd717lnkOlkoqwuRmfS9zVzUXdRjrf KepO92qysM69SS9bRVH3APcT7vhuUQ+5d7v3tZRK197m0mK5sn2Zsctb5T7ormsuM/a6j+nlRPsy 4wC1qkGUGYfdZ91n1TiStCszjs740H1hRr27kUqUy4wzRYfcUVVW45rLjPNqfPtC3pnvXu0Z4a5T O4viOizKjEtqkpo044ya1NrONi1uci1SezcXd6Par7mQRWE7TT3SrhxXT9J7hrSUU2omF9ei7/Za Pefuro5qKazXWR3brlwkuqxmozhUh0cSco/Z05E+JwnrXDwJnq7q1O8WTw91uidZ1RAvczyp3GMu nkGeDM8IV5NntGecx9pqp43FXNfhNvEUUMs8k0VRZ4nimcbx7XEhdos8Pk+QY8ET4pjxVHB8eOap RzwL0NuxnkWeZWjRMlhfqZapZRwpASP8sToQG7CwVwOJ7P1Ad/a0p9az1rPBs8Wz3bPLne/ZS/UO kO3DnqPuUs+HnnrPGXel5zy1b5XnkqdJM2qxmkVL1LprPbUUrb97lWuXlq4N10ZqWdp4zablafnU 4iJq5Q6tALOsUlO1Iq1Ui2hZ7lJtjlZJtnjWokfQXIV5Qj3SFroj2hKtWlvlztNWk+29pFdAc2mr to64fG2TtpVwh7Zb26cd1Oq0Y5jLEVG0E1oD91Y7q13QGrWoV6bZyqXaG+eN93ZGjNObvEnurd7e PBu9/YjSvEO8md5R3rHebPdur8O9zzuJrfDM8071TheRqg7xat6At8w7S3V457pLvfO9Vep0Ncm7 1LuCvDzLW+Nd413v3UzxOpZGINO7zbvTu4dizuHdT+WQmu09gghMU9PEWEFvKkcMj5X3ONFJ7ynv OTXNe5GelHkv06Ju9nX0JahDfF21Vb4evmRfqrvON8iXwTV8I3yjfeOoWBHjmZ4FkOb6JvumqQ6f y+fzBamEfBUUw1wyffN8C3yLqNXT3XN8y3wr1SRfLcepb61vg2+Lb7tvl2+v74CPZq3vqLva9yHF Y4D75qv3nfGd94ymCC1T03yXPLvIN1s9o2nGHQv0pNw1tehQICXQ390QSKd4jrobA8MpU8QHRnrq A1k0l+tcewPjiw4VHeJ57c4K2NR+gbxAfqBAG+/pMaMjeXs1RyVlM85Pjfxa0iIN+te+QBFlKs53 iGChyRkG45LlPhsodS0KRCjG55C8H+nVUb5KCnCNg4GFgSXUxurAqsDqwLrApsBWZMGzgR2cAQO7 A/vobQcDSwJ1KMcoz8ki12lbA3gbR3Cg2nU40MDZLNBAllnzbOBCoDEQde8OLBSZC7krPmCkUk0+ 7c0t8Z7yNfn5J95i/RZ/ImWotf7u/u6utRQrNf6e/hTOSe4Cf3+t1J+uZvqH+0d65/qz1LH+8X6b P8+fr07yF/hVelLkL/We8kf8c/yVPGP9C/1L/NXuOd4V/lX+1f51/k3+rf5q/w7/bv8+/0F/nf+Y R/KfIGrwn/Vf8Df6o0Wy1r8orijevc5/zHvKvaOoM2nnu0945+MJvpPjLuVv5Xg3e9byN3Pcq1q+ mzO1aLr7RJGGb+fo381xR/m7Of46T73+/Zwq9+7rfkfnVNE5f13RRZprjZ6O/C0dT8cZZopTB8Wr lUZ+k1o2I4FyYz/X3tZv7nhotZiRocbP6OqN17+1o39bR50+I7coTf+mTg98V6f1mznN38jZ7gti NzXg3yfMf6ETpioF8K2GzoSSq14yuNOlRNcJKg2uhin5U/JdZ6lUu6rBX3BdmHJiyglXI5WoK8oy t0wlzh3HsvyK/Ap3PJXO7s5Th0wd4k6i0tvdm95jtFgtOfSOeJxoJJxojDjLmLDnlXGWUXCKMWPP G4NTTCxOMR1wcrkJJ5eO2PNasOe9BXveeJxZOuG0cqtkiJ8eX4Q+4XuHrumSwTWfPumM4qqSO42P uubeCGWvdM2dIBPFfQ/FC8reIGhC5xukJKLe16F+grL30mfajVH2YfocolOmTqMEuaaKz+wzROeJ H0uU/V3KbqJPxw/TxFjdxiSd2P70dqRdhwLtqOyfoFlEc69D84mqrkNL29GKGyOHmT5riNZ8D60X 5OgoaMLmG6RtRDu/nxwJ9LnnxsjOsbNfp0M6HRHk6Co+7TQ+jh7EHyc6+V2yc5yd+mFyJBOlEn9O p4tEl6+lbOk6ZG5HHf8JIl9kd70OUX+yk79L7X2dnXpjNHE4fQ4iyvgeomcTRxJl6XojbpBGXz92 YINt2uhz3I3RxDz6tILm4zO3DTXrFOifKlER8ZNb39WWJpbq/LQfpokRojntbLjake+7NLGSaCHx Qco708XnxOrrt+d7KURUcR2aR7TgOrToWpq4qjV3X5Nvm/Nlcx5b3ZpfJq67Nn+0xEnbcW0el2Yf bWrj263Xtqklp7SNzeY53Dy32JYe847cdnHN47mDaDfRPqKDrrk53AZaXyYeE3LuE68RE0+4sJa4 KMdOPEt0gaiRiPpv5XUrW/TXSmuVldcqGhcr1bVSHSvngYCe08kP1n4iX1rThF0rrScuem6l9cNK OcVKtqxsa5Lu32Z/Ul1eJ62c+9lmZquf2Za1TNjgZ1bK5da5ol3fGad2Y9SynujjxLZ4bbRS3rfS OFmXtqnvEGPH/7aS762Ux60076zrdR25DcVfh9qvy/2uQ2mu1vW1zRrbQmPbUPs1tnm9/N+sk7Nc 166F812ta2Cb9c56RMSllfK/9aTOU8xZz+kxS/FmpVxuvSz+nSPpn5SrczqKeZuTIOYT9yuH8m8O 5d+cZH1eNM8DPS9yLs1J1fNcbuscyckQ+Yvrt+TA9nOr3bxqyS/63MrRczHHf85o0caW+tPEfMuh +jn8Hnp3DuW/nGmi3chL1Iccspfj0+v9UP5pl8evq9Pc5uvk4xaa3Ia+710/kE95HK6h9nmyba6c 1yZHts2Jg/S6FfqzVJGjHdPEGDtcop8Oep+D9BwhIeecZafYcVA97F9mCV0HvQP7Ddp3ODjXndTz 2SI9NvU9gWMZEeUEXv8dtXqeWyvsOjYI4jnq2EK0nWiXyMMOymmOA3r+pHzpOKzXPepq3TMdapNH N7TawF7qQ2r3Hr1d7fNwuxzcsodpzsMbdBv1rrm2hXqd5vqnRG7Gv9cIH6BvZ3RZTRtafx26kb3g Hlfrnu6Qq2Vf10LH21D7fV3zHu1/szdLcF27/+rhatl3XbOW7dTrdm31SfPcylmgf/K8W+Zq3fPo 8yqHYiKnVieKhxzyeQ6NXw6NX84unSgGcg5cG+85h3U6KuZXDo1zDo1TDvk/5/z15xvnxpxLRHS2 sRmJYlvnm83Shk/Uqbsgnnu2nkQp+mf/1jloSyeifGcb2Wb+UZ9tWaI9tvEiZ9lsYu1pJt5T2mg/ Z8sXfbbRvs2mitzF+cNWJNaUZn0b7ddstA+z0T7MVini0baEiPZTNtrj2FaLfYFtnW6H/GejPYlt q8jHPP422kPYduu0T/icfWfjenVEtJewnRC529ag69MewkZ7CFuj2APaoq6W3GyXW9clO+0n7PHi PGJPEmcKO62Rdloj7bRvsGcKP9pHifMIr932bGHD7hDjbJ8k5pWdzpB2Wg/ttP7Z2TatdfZZYn3H s7lizjHP7bbTuNppzbMvFW23U/zZa8SY21lvveiXnXMYzTf7TpETWnIu5TD7frFW2mme2fnMdFzk Ozu355yIXfYX8/aLIp45FuzkV4ck/Mjfxrh5981v/fvbGP9Kd2VyqryH/6Jq3C9tlKSYnkQpRP2J 0omGE41s85mlf44nshHlEeUTFRCpREVEpUQRojlElUQLiZYQVROtIlqt0zqiTURbiXYQ7SbaR3SQ qE5/1zGiE0QNbT7Ptvn3BaJGoqgkxcpEcW0+44k6EyUJff6M7U3UjyiNaAhRZpvPUURjibKJHEST dP2pRNOJNKIAURnRLKK5RPOJqoiWEq0gqiFaQ7SeaDPRNqKdRHuI9hMdIjoi+hV7nOik/nmqzWez /jnhU3we0+upbZ5fJLqM/+Jb6mAmovnaIaH1k/3ToStRjzafyUSpbT4HEWW0fnKbO4wgGq3XH/fP EcasLY0XxO+/xl7XdmQlytU/rd+102Ey0TTh7w4uIl+bzyBRSNpoX2BfZF9mX2mvta9lMofsG+xb 7Nvtu+x77Qfsh+1H7R+affZ6+xn7efsle5PD6IilYnEkOro7ejpSHP0d6Y7hjpGOLMd4hw2U58jH vwscqqPIUQqKOOY4Kh0L7QccS8w+R7VjlWM1aJ1jk2OrY4djt2Of46CjznGM6p1wNDjOOi44Gh1R p+yMc8Y7OzuTnL2d/RylzjTnEGemc5RzrDPb6XBOck51TndqzgBRGddxznLOdc53VjmXOlc4a5xr nOudm0HbnDude0D7nYdAR5zHQSedp5znzCHnRb1cbuGYv5wr6cVMpaOjMTeB5MdFye2a24Ooa24y lVQqg3Izckc4L+aOZsodl2ulNaHbdX9xQdJ/cSEWv7gQh19c6IhfXLDgFxfijfyLCwn4xYVE/OJC Z/ziQhf81kI3S0/LPdLtlsGWLGmApdCiSg9YfJZiaYyl1BKWJlgqLLMlu2We5RnJaVlseU36seV1 y05pjmWf5VNpLn59Yc3/xy0zGBIMAXxfZbt0tyT1OaITzfQ+J3U6pdO5NjwTze4+l3X+JP/H7YJP NuvUUSea6ck0g5JpdieTUnKq0E0epOuzLKPNv0fon6N1Gtf6zmSr+HdyrnS33Uyloz3B3tXeg0qy PRVlkD3DPsI+2j7ObrXnoky2T7O77D570B4iaYV9HnELqEaqPhvFfOSZWGvfTmN1C35pQ8JvbBjx GxsmS7olXZItYyxjJcXyiGWiFIPf2+hoedxSQOPgsXilOyxBS4nU0xKxPCX1tsy1/ExKseyw7JD6 Wd6wvCHdZTlrOSul/j+2boj+RL6PcLKiEd4EPg78EPBDwA8Gf49sZVTmgC8lTFeWg78PvAb+bvAT UKs/YZpuzQlrFfwU+vlyP0bFwd96UiLEJ8rJjMpPCTdD53muexX81ddhZy7kXtEqvW0jYbkE/DjI wStPMJqXQ34/JIVk52Nu4dUTyiS0diR6JOreDZ2foLVDYbMQ/L3gPWj5Q+idirrM32P6FpIB4D+G hZvwdBzkflh+CPJi8LeAfwA6aXh7Pt5yC97yAPiHwAv9DOi7CAeBHwQ+Xc4EZsACJMDBkA+Dl4Yp XrwlEzrMDzZVo9ZeaJbCci34GvAHwS8Ev4PbEB0F/ZGQDwXOIxwIHIzxGiyPAd6LWtPxXg/wVclg 9ClVhCOV+YTPKPR2Yxn4LkAT8KiygrCSNQ2dgCtQKx0oMZpmQ7NW+TnhFuW3hL1YYqhn3nAFT1dC fwr0a8APASbC5mno9JH/TJgkv0XokOv4Lcwb3gW+DblL/huhlTUNscCpqGUE/zqjKRmahZD7Wd8Q hYVXwL+Op3l42h36Y1C3AfiNPIPk2QprNspFxJuV99gbLDcUKPsJP5Epcox9WUe6orxOEgvwU11C aHoQdvoCU1DXB6wG9lJ+hKdPsJcYjVfAHwF+Alwu5/MYxdwBNDKam4B1kPQFTqF3VYgRhOYz5qs8 juC7CEStLqjVBbW6QGcTnm6C5CgklZD8B0eCoRPzhEZGtkBYB0lf8FcRDxSfxunQn4W66ZBI4CXl JJAl/YC1kNeiL1vAbxE8WrgFLdyC9mwxU/YwvYN+9UIE9oL+ULSqHnhFoLKEowtPV8LaSlhbCWsr YW0le4kikNpgwntN4o2JqJWI3p2GtdPo1ze03BEq9cB9wI3AJjyluWbqhnFshOYx4Dlgo3IYsXGJ Y4YlNI/2ATcCm4CHeZSh/wlsfiIkXMtwM1o1iHnpCutQRO0DbgQ2McqUDYwGEXvMGyyw9qnyR0aW SFdiJkP/Y24PWtKXe2RsQhtSIEmBJAUtTEELU8RTtD9FPkc9fVxEsnKRYxhvqUbd4Wi5BuxlLoPO PuBGYBPeO5Rjm/VNikD48xPgclhbDo/t55lFGakWUb0TsSoQEQh+i0BYXgk+EfqJGPdEltDo+OF5 IPeOfOhHfzFnGent9fA/S9Yjfu4FPoIc2E35PeFpczZhFeRfMhqANDt+j1H+L56tkByF5hTMgkTg ENhJZzRVga9VlqHlVMs0FPZ/ibqjoP8x+DTgqyKekTlfQRb9CLMghuXmyxwb5rXsN+UOrit72Xvm j5g3W5k3bUPkj0U8/5UxRub+mpfKJ7i1iK558FsJt4fmoxU+HwjsBp8PBHaD5wcCu8H/A4HdMB8H ArthLAYCWf8rtH8xLCeh7z7kli3ARJG7zHcjUw0h7MEtMVxh3vAmRnZkzF2cwaBvAn8UtSpFjkLL KzF/00We4aem2ZjXs6FTC+wFfAAzul5gzMuMdFbnN/LTKYicKcgMNSyhtYntj8PTISJLoO7pmEcR ITQLjAOBmfL7yE6scz8kfeWPMAe/JhyF+XLBTCuv8Y8spxnxNTI/zQhDIfiXOMMrDZgXEusrucgD n0PSDTnnbcy1DjGUDw1vYL7IGP3LPJqUkT5HnH+Omf45Zu7nPE91xBwEXydjbrIdo1/5gvAWRrJw GLVE/uEMcw59qeA2m6zKG4Q5ItdhffSjXwUxtIMyzha95pxDlh/hvrN9yjx9eQVELx7U8+FhtIex WqD5V8CLyB412C1wLrqCp0d05CzhNP8MOWQo5izjQzG9sVJ/hBz1ETxJK7Vhj/wh3vUF8ufX7Bk8 fRmat4NPReYcqDxL/Bl5POF52Yux4yw6FO8dCj4G+Cv09yDQqHxFPYpVAljf2c4Q7FKS4assvOU9 4AHo/xkW/iwyJ95uA37FY2Hoh8w5Bfn8LfBLgIUK7TCNk2A/D6PWE3bqIUHmNxwDlkN/PffacFku QR/LCVPlI5xPoPMCevQpt9OwChZquO/KUPaSksJoWs4xSXmJrJk+Z16eCX4mt9xkxyh3Q6b6Ws9U HFe3sjXTndxCWg251wno1wfyceLvkf9E/CZIMtCSL4BPoQ3H0K9M8LmoO0beTJgl80q9lHlad9hX x6GZYrqN+M9g7QpwHeQPwcIwuZLwC+AEhea4UUbb7sAbX4H+BvltjjfYvAyshPwrWMiEtcPgn4B8 r/Ih2syR/wzv1mhXNpNwGWdykmeR/UfNg0m/WOY5pTHS/pBrjYF/1ih/wrwrRwQyvsW7d2Mf86PA +4CpwDjgY8DFhGKv64DmEKDD3J8zHvOGd3VMBcYBHwOyjgv6VbBWBYkVkmkK59hY1I3ltxOmAuOA jwFZfxg0p0LzdYHYyxXCTiFa7gfv1/lUYBzwMWAe8sxU8tID2HtHYTMKa68Im/I6jnDYyYOdPNjJ g5082MmDN/LYmmkMa5pygI+h5Q2w0wD+bfBvo/19zO/BGwJFT99Dq4BKR9h8D3XvA7K8XKETn9EC vI3O9JwPH0KWoyxhzIH8N4yGt8F7lCzMbsb1kByB5m3oaZK8ibCCeaOR0TQOfCHQz7VMnRhp9eG6 Caj1OuyfhSTAM9GYpwxHDLMPF7HHzKO4p+Y9jPLvuJb8Ne+QlU+ZN8/DrmMYfBiBb43QH4W6RzF/ M3D2sfF5lnxVCC8VwkuF8FIhRqoQXmL+LbTnCeibwPeBn/2M5D1Er5LDUcond+oFrwW/kXeRJEmP WxGZcYhGEZOpiK44Pq9hTJMhL4TNKPAVHXmleyWmDPqs051HjeKhP3onUMRDf+ik4uliSBajtT+l HDvPRPMxajV9yaj0kgxX3+F7j6vvKE+T/m/5hG7ar0wjf97LGV5+knnTS8BfQb5WCRI+z5oG6NPq TyjfiboTGM1eaL7JtxPy23x3YToBCz/m+xA5Hk//gFovMMbcDnlnWGgCrof+NJxMK3jcTS9z9jZ9 CP5h4GBGuSefZ+XeWJfnQ/8NjOz7jMpq6AxmXu7OmqbnkFU+A6/h6V142pXRnAUL4gS9HjgO73qA c6Dpeb7xMI3lddb0D+wK5uNcsIf37aa9fCKmvRPpGKrYn4ZaeHUWJM/wDkE5Bzs7gXXAvwLfh516 4EHgTPlbyJ/g3Syj8ib4CuCrOC9fwun4D7zrkx/A3u81nTcy8s6NsA6SvnhKK4t5GPzvh2ZH4L3m MOEuWFgI/EwgWyCsg4QtvATN36JWE0vkJkiw81R+jfXx19iR7gGWA49hh/kudpJ7sI99HifoKO8q KZZ4h9yAN+YCX+ZMq3SDzW5cV4mAjwie7RDWQUJ2lJ/xSTnGiH6ZlM6EE2HnDNo5gee7/CIsWHRk OxbYscA/L6IvL7J/lHuZj/mp+TfAEMcG7IQFwqsdYH89991Uhj3e3wTy/o1wH3AjsAk6lMfMD2Gs 50JzrEInDmW5+U6ydj+fNE1bWS53EcgWCDcCm4BW7h2e4gRt2ssSUy3qnuJZaTiOffJTwGXA3dhP zsGZ9FmcSZ/GfqkKewOc0w3neAdorIHlruAP8anZNFKJ8tyBfDDbkU9y+2XsveUnBUL+JFr7JFr7 JFpbxa2SS/jsbP4LaknYMSah7zh3m5zAbdgn/AE9WoYT9GLsxA7A/gCBeMsAvGUA3jIA+gfYq/Kz /C7zEGUWcB9uNrjWbQIhyYE3LsFjjcpHmAuZiGqBHJ9pfHameCOJOaAgNsB70KMw5lQY+n9TTmNE BLKHe/A5WpZZohTIO9BC5ueAvw3tvw2SBERjNXCSkkjW6vksrDxoriLJeyxXVuLpGEbTa+C/ZB25 E87Oe6BTx/pKHObOncDHcBZ+Eafg84xKN96nKRGuZR6Jt4yCzT9hffwAll+CtblAC5+45a14+gJm UyLwVn7aATdFsZNx8vqWs7RSyPkt5k3k8LHMG/+Os/kwzKkmzJfnxSyGxAwLV9hm7GR5FdXqhFXg G24heZ5H5yqfoylfdcO4DATy+XoVztf/zTxpDgR2w0wfCOyG8RoI5LovmDkPnEAbcFMh55qTeI1D vnobGEYOSeaTuPwxn77lzYy0DnJ07Te/gDjnOb4HfBN68TzqnkBufJkl5sOcK8xeyN8ETkd+OIG6 PwZ+FnMPsJJXQJYoMRxRMbdDvzPwBdhERjWt5bO2/DCfO+QngIlYkR9Vnkd0XQRP+uZJkD+B89dr OPEVYq79w9wNax/JFZxkaQ7y+egt7Kk+Z035aeSBebzbj1mB+djI42jOxmj+miXmhxT2TxKfainC Oafhrs/4PGPMCl6DTId59pnK+JRNyL3YCn4rZvd85qmuQH46AE/vxMwSfJjbIA/mt9DaSicyeQTO ZX/DfU4dI82gjVhJL2IN5RPTTO6LcpBXWHMususX2AnU4hSj4tT2DZ/TZdw9mmr4hG58ljO8WeM2 K+eQE3Yiuz4BD/yVeWM98CCeOs23AAP8Ro4iGot6XpHxtAJ4DnnmVdTCLaipC5/ZKSO9hJa/xFnO TDEv34yxGAAswKjNkjnfvgX8Fn3/BKPTAzo43ZsWA58D2iHPwwmujnsqPwJJH/BD5Xdgn8998Jvh 7/BGR3jjDpzE5/EpXi6Xz1ILn0StCby/Uk4hWvbIP0Eu4v6+hrqvoe4EREsSPP8pcD7asx1jdzvO j7/AiL+KVWYtxnokJBv5HCHjNCrvhP5YWPsDo/Ie+C3I7WbwFThTCwuZwLl8xpc/wFy+lXetso3b qSjKSs4YaOcKRMt27BVnm/aSvJ49af4rRymtRIyVjPI/ZB6XF5Dny5lXTiu81r+M1eoj6KjIhJeR JwvwNIHR9BteJZUF3ELzRHjgA7T2KJ/65Zv41G8qwQn6M7TKil7fiX6N4VYpf4YHHoV8M/fCtFum U4P8O/6Lm7zS9D7aQLz5b7B/BPpPYpSf5HsAinN+47uQ9wH/W12HbS7kewCzxCjX8G2A7GC5eSba sBj6SXwbYDwP+1OBDsg/hgUb88qvwPcVb8Ht3ADMSqyP5r/DV9uB2Amb1gFnAcV8vA372NfhT5P8 d+JTeVUy7YH3luP+MwFvyQaOgsf2IzNcRTZrhH+eAz6MGEvDWWk7MEPn7wOmAuOAj+EpnX2UX2AP fxaaPwe+rKwl+5ngBwCrdEwFxgHZwsPQ7IGT5myWyLMh6QzJOZxwF+CMWQN8DHgIZ3m0x/h7nPiW 4G7hIp/OaK5RLeMaaF7Ee5/iHa9cC5u1XFd+BnyDjvcBU4FxQG7JF3wnQCffqeTJAejjK/wXbdP/ wGYqcBrwTT75yv1g7Tkd7wOmAuPw9DEgeUx+hy2bd/Ff/QjXkIU/olayjuylzbA8jr1Bfs6Bxxh/ ib734PsE6gVJlA/4toHewvxx8Ml4ezJL5A1o2whG05cyna9NxfIbPC+Uhchs/LQRT78CapA8xSdr 0waglyVKFvRD8O2dwIuMlBk28eoMvhbYwLWUq4zyEdgsZLnpWVjuCTyL/PCcvIVwMp4OhYdrgItZ JzaFPRALPyi/xHnzS6yeR5iPmYE1dAOe/gIeng3v3Q98BjG2DBZS2GbsZt4RmZfgNPqa/Bo9Demx Tedo00Y9PgtxhuLIeZZ5slOIES+Eh5kfyrcT8ky8ZRXboX1jGkcC4rY7MBnteR7vmq50IkxnNFnh zwqM6YdAL/RnQ783+JkY/R+zxJzMEaKshnwwsCva+Rzzxs9g4efmfOAFHjvoPMWjb87C09chGQGb 6yGxo+Uz4fM3WW7eZb4Zbb4Z3uBvXwz+llYByfTtn8C/yN8fAKZ/+3vwdwHn87cR9Kf/BcR3Cb6N gBfYFbgYclF3A/gNsLYe+AEkH4A/Ch2SG33f8p3nSOAzwDJgF6AJeBRYyWjoxChFIUkHSoym2eBr gVuAvQQf5fvqetS9AslK4BTUqgE/BJgIndPg+wCTgA7I3wW+DYkLaIUkFu35DBIjJK/DcjIkhUA/ 5KLNfrTnFfB5wO7QHwOdBuA3kGeDbwRvBt8f+EmU82FfvBc9MlhYYvgUdh6EfgqwL+TV0BEtEfpH gMsh8UWHcawK/zNv7AI8CvwP4XPw04XPwUvAWuCWKM/ld4TPWWJYCryCpythf4voF/hu4DfjqQk4 SPQFvEH0BRZu0XvB8o9Fv6J/IQuPw4IL8uGid9BPj/YkSUE0D73IQ8vz0MI8tIQxEfJvwPdipPfm wXIe3sV4L971CPx5O+x/CeyOt4g4QcyYqoB3oV9DUeuXwFFR2p8YRJvTgK8C44ExjDFdGc1LGeW/ AO/lvpv/E/JY5k3b9Bgehsh8kv8CKyIzyn+3+gr84mgy8ZeiGRjNBoxjA/zPWC5G+eoxnmXo3cho Mc8y8GWCv7of/E3wG2MlnlZGncCb4EmW2yBPRy0JvKTzN/EchKRWx2Ig13JC4mSJoR7+v6JjMfAm jM5YIPNT+KmpBjqndWRrA+H5i+jR/WLuRPkGbBTkF/RoIc8Y/yii4uoV4mciol5iiXIZOttZonTF PHrkKr63AA8vj8bzbj86nOfpVd6rIwINv2PfGrZCUsFIlvn0hAxgyoH9Rni7GprLEZl9YPObq/wX gbQorzXZ6IUZ3jALHp7vjl7fDDQB+0YfAd6E+GRJB/jhU64lwW+mB/WIZR8+DqyGztPAQkhm6tbY t7eDF55friPr7InSmmK0oKcvwz8i5lPR/jPwyXndt/cSjzgn5Ft0RLLhV8CDQCP6vpt9SC28F8gS 5ENTFuy8BzwAa8j/hvdZRzqHSO4T7UNog7wa8rdYIp2C/BZgR4zCr/W5z+M1CTZ7igwJPAY8E21C T4cD+e81WEEMbwLXQy6iQuRJByx/ipasgnwQx5iM+JHrWV9J+ZZ8YhL5811uj+lz9qE8E/xM9NSO pyLXfS3yAPeXkFt7K3TuhDwBOh+Avwf8Jj0fUmsNGZB8ARQ5BP0yZgJzgVg7jMK3yCeG40CsSoZ1 kD8EHAaENeOEKO2UjMgnpjuguQGIddZ4GPgEcD7ki6Ap2vAaJIuBTcA/6WsTj84y0Wbm5RfBz/o/ 7H13lBXF9u7uqupTM9PnFMEBERHJAiIShqiiIiAgAiIikhQGhuAAAwxBREAki4iKgGQRAQFREBFJ IsqAZGFIg5JBcs7hzKv9dd/3E67rXe+7vz/vmrW+3r1r166qr3bt6tPd5wxqdQF28Hc3REUIMVYC GELdw5B3oLQc5PlBDLAMFP4unA+aX6GpAnwNbcVAnwFcDj12B7vzbrH9R1Z3oih9E/pGwWptBG+N 4KER8kYjlLLmKGR/184B9K832sPbeqC/J3aFjCsHZwkYqwnL37FHZPNnnHcHkRdyCiz3Afcj87cD 4ppHvQ7E3uqC+RCulKQ/jx0xijWZSVjd1Zkff9Z8fTAu3hEaIDstBz4Jm4K3j2EfaQTsgqzOcg1k +yPAX5Ex6kJfN/ok0AM/HvhnfXHkkOVgaXkg817wKEoTA+yC3npYTWzzXcBtDSDrXwPmRuavB29r AuS6zwCT8WTkIp6ATMDd2gmad/xSkEuFTtq6pSE/hGvgmXh3qA6eVFZ2M3lcuJ9zhGWxG/IP+Mzu v90RxTsYBfH8dA0+dTbGM9bGoZc4J0B/kmXhyxfd6pzT8Oz1Pv50QGVEZSsPd/nOVYJqz5/x1WcW 17Estih+n2QBo7yg+PNgOlvSUUanHWrVZHRXMKoQsKTiu4I14a0B/MzCvZEq8HOLbUINUbeB3y6j yABWU7ktXpNvAu1Vt0yC3AP6xowyRe5lPcu0ldEpgdIMRjceNgOBc+V7FgU8VFMOxsL63kB4c8f4 LQL3AvsDF0i+m1qcUYyGnM9tYuXDLDuX+I1i20P7iUCGWUNrpf3kSL8ximWsp7Vs79ZA3Zy+B9aL GLmU15RcxNleToOea53hUjcONrOAZ6Avwmj17CGB0Z2KXl0DVgb2Zz+icdBna+8oRrWLUTYAzkUP pXAY+a4OCchCCNY4K1CKz1nOQbw1fYpjWAznfCWG8LgEP1OezLJzUfB7ejsE31seIfpaHCxsfnay sb0zBjgeKBllP3iYJoZZXCg4wvNLfvvoKTmMsyhrnJuwmYgWm6PWVMgJwHgRY22Ow6ag4GjPI+7h mRX8tLEmy84a4Fz+H46irogD5uQMAOwKHAU0jLIQPCSyLDqKvLymhI1V0ZllkV38zmsf+uWwbATL 3Khb3eErMQFvR505fO3kFLGaws4JK6c7dnWLbA6/eShZdkqIUuihHQvdUPG8Y3Kp4wKHi/KsEYut 5+dQtzCwSCBnWNSMdBnexgFLwX9h5xA4tPyIm04fnhdojsDzWNhoRjrDtegq90TsJsJ3HEozhpoz 8vvzVvM15F8gX4bcHvLHNqJ2h6Zb7AN8nNH1GOUfwLnQ3AcMM4oCwBmwfw02rRhDUdhUB7ZHaVXI b0F+G5ZrgVegrwT9Ukb9FOR2wKKw2Qb5WWBFaNZD/gDy+8DG0ExEf7IC/XZdyLfQq5rQrAFmoNZt yHuBhaHpDHwTGoxXlUPd4ZAVSjcCL0LzHORXIGu0NZTRuQrZZ28nPAyAzfPQ74K+NOQ0yL+AB7Ah vwSuA5ZErd06mZ87+PPCsusBH/BnB/J9wDDwGX92WFa/+HPEsmwF7ALsAW99/ZlCrfz+fEHu6s8U LNcCr0BfiVE/Bc9Fod+GvpWFPcai3vOZgU1LyNLnhDWiG/qTBz33S28Am4ClFZBTYJMNeAy1dsDe n8e8wHvRW8y1C5ZcPwb8nn8E9Hu1Bz33Y/g8LLuhb0vgPwnox1trRCD6FuoAS7QlNwNXwaYZsA00 JyEbxpi97DMGkRwqhrod4Q02uj70CehJMX+9gL2TqLUaNvHQH0XdgpDhTZ6CXAPyIMhxkP2I6gM/ czELUYyrKnApsB3wQ1i+ilqLICNCQp0wdn89Hka7QyBXhv40LMGGfgOyQK1GkFP92EbrX/g8Ax9E 3emQMV8C7IUmAadA4+eKD/z1Ag+lMctpwGzocx3YJAKxptxCkDEvqh6wAjy8BLkFsDZs0oH7Ufo6 0Nc/BEQOEVjLag6wFvz/CJwJHAcb5EMxFbVOIIbPQIO5EBiLmg/EmlVPw3IhcDtwHrw9AvkybBoC m0ODHBuCfQi5SDeFPfKqCkFGKyHkVXUJiDUiz0LGiNye0CB/KlhKMCwQgfIgZKwy91vYzAL6OW0Y 9H6m/R6IeZQ+q4OByIruIchjgbHo1WOwRBRJrAuJHkrsDqo7avmRsA968KCRAdwG0C+DHmtQPgHE 2g99hT4nAxE5CqNQmFkFVoU/Cn9+sTuEkGmVP1+oq5AZpN/WYuBWoB9FfobxM6G/H72LvmFPUf6+ hqiQEcg5gFgpIT8zP4vofR9xmxVxm4E1Dj8Kq9IFz3IjSpHh1cNAPw9gfl3EsxyD/vSC/1FARILs DfR35wOQrwPhOQbZNQZ9dr9BLaw47ee02dBjdkIoVT+hLnKj7My9IsqsDMwF/JJ3nCg/3esDfJzR 9RjlH8C50NwHDDOKAsAZsH8NNq0YQ1HYVAe2R2lVyG9BfhuWa4FXoK8E/VJG/RTkdsCisNkG+Vlg RWjWQ/4A8vvAxtBMRH+yAv12Xci30Kua0KwBZqDWbch7gYWh6Qx8ExqMV5VD3eGQFUo3Ai9C8xzk VyBrtDWU0bkK2WdvJzwMgM3z0O+CvjTkNMi/gAewIb8ErgOWRN0ElD4AfAZ+YC+7AHtA0xel+YFd Uass9PCv3gO2BEq02w2YBx58/Q1gE9RdATkFNtmAx4A7YO/zmRd4L1oE5y566/pzgT6oj4B+T/ag 1I+l85DRB7UEnpOA/ry3RiSgb6EOsERbcjNwFWyaAdtAcxKyYYzBbMYgokLFULcjvMFG14cG+pjV 0MSj7lHoC0JGXXkKcg3IgyDHQfbn8UPgq9Asgox5CXXCKPwIPwyfQyBXhv40LDEu/QZkgVqNIKfC 8gvID8J+OmSwLTD20CTgFGj8FYdVoOpATgQiAt1CkMGeqgesgFovQW4BrA2bdOB+lL4O9PUPAbHi BCJfzQHWgv8fgTOB42CD7CGmotYJRucMNOBQoM9qPhARrp6G5ULgduA8eHsE8mXYNAQ2hwYZKQT7 EFaubgp7ZCEVgoxWQshC6hIQkSzPQsaI3J7QINsoWEowKRAn8iBkrAX3W9jMAvoZYBj0fl76Hoio lj6rg4HIIe4hyGOBsejVY7BEhEhEr0QPJXKp6o5a/ozvgx48aKwRtwH0y6DHSpFPALFCQ1+hz8lA RIjCKBRmVoFV4Y/Cn1/k0hDykvLnC3UV1q/021oM3Ar0o8jPA3628bP3u+gbMrDydwFEhYxAzgHE Kgj5mcG395lErlMPA7EeFebORazKMWirF+qOAmKWZW+gv08dgHwdCJ8xyGwx6I/7DWph1Wg/q8yG HsyHUKp+Ql1kJ9osJfE9MX53pZAbh7sx/P3umrgjlCT5qfc03EeqhdLJrkt8Byne4jjcSROsEceh H8l6FWJLuwm5fOcE+maM7lZGVRL6S/CQgtJjjKGukJOANeHzjG+J1ofzd+FlmO+YicnQDArud/Hd v8u4e1Ybd9Ju+HfMoJnOtcQWaATszwBnYYxhRtEfI22Ie2JpuFuVADlBfse12IYyWe/cE9wls0gH cE+sDPw0QK1quHNVmTXOPWoi8b2yubxqUDoZ2JgxmpLJ38ytn8lvCi3L5DuTjfkOhtjCslMCchOU VoO8HPIuWPZh2YnCQxGU/oRaOyBn971BczA6DRquWwrYCvooWzo3oPkE9oVQ93OUlodcHKUhyG0h D4FlZbS+G5YnUNqL5WgD7o+q44+C+H3XayzLLGirAOQUwp1VaBQ062CfwRhSxLGBnsjisMkFWQD3 wjIGchhyXUYbQyzPQosLII+GPAuWOYHTcHfoKOQk2PRA3SbcolwU9JlLe6PdDejnLsiXghY5GktB bgb7VtGlfOeN9bQ1yndxa8LnGJT2R91Y5t9mPNwXhWYUZiQZ/utEZ6IPbN+SZZHGPZclWLYxXYF3 Q9Sqzhpbd5ItnRRdZLlChDiLo3x3dB6X2tw1E+PlERWHh4MUh3v4i5AD+XuaBfxW+C0I21vu+Wzo c4H5HBjjFvbp9oJ/E/3Y2iyEzagoR/798GlQugpYmnvljPfZ49E5g4Fl2F4Uia5Eu+t4dlgWyyAX AcYASzHatpZBXom2pnAcosWBFM9rh9sVyygL35kEY2fQYgPoDwPTMMtTUWsu+rYf+BSiC7HktoYm yvZybyY/TciTecriRfhM9lvx5wvr61qwypiZ4ZA1I//2l82uiCI1FFiVYyBUnkvdndwHt37mDczF fOBcrESue7/fE5YtM8zV5czjuDoajRWKdsFVHp47ZzD6Vg2aHjx3Yjh4mwW5crQK8xNNgk0SSgdi FAPZ/+2z0BzDczf2EAZWY40oxk92VEUwfAaatGhvjl4ei3MCc7Ef9jHAwlH+FQIXz4Mmct9kfPQz tJWCFZHOzwjQW0IPH4jyU6GkTH4TIAZj/BqjjuW4cmojVpOYAfW1P1/curPYjy62DCHG7OhWYmdn Dgshzxz08wavQTs65vASl4bmcStOOnzWQa8ag8/sqFsKayE76+2nNjxxYHTjuIeyHtZmY54vusEM WE7mYhaehyWPqG50J/AAWiyOSGY/b0bfR13mvCtzYvFL1N2LuscQ4RznuZkTJ1cUz3FQ2jR6GTI/ i1HgfBVs5sF+uo/gZDzeXxqL0o/hoRJGNAxtVQre8ViJKyv2s8B/3wn+E9HnGHD+MmZkFqMzCvxs oAaWk6zID6Wg6c9Ia5kNy9hI5LGPea0h5zzFfuwc3UTfXOw+jBtgf4aZdKcCy2DuciM7vcb2lm2O hBBayQDno5HfFMe/zWnIZpjfxsg2g1lDeJeMfgMuBFfzsCqLIA5Hwn6ZXwuttEZ/TmC8VYIM/Di4 5VaWI2ZG+aOAnxjW2x3KxZsqvIprcLuhD/kXnGyE8/fsVlMV/gyIVg5jdacg0grB/1xu10b4TcRn FmSteOw18diVsLMg/g3iRCELtYD9FWSzkehJBpVB3huBPrM8zu5INs7BRi7EqmD/shn4X+xnpyAr 1sAuXAEZrCL2a/Y/EZaXwMbr8DAwGIWVQ34+H+WvtWB34+8Y9hfrIfOOsBZclcdI06ObkaXXYfUt BQ/8zdaGjO45vJO2CB5GI8KToakCDoeyN7uW54M3nutjwJGIqz7QZ8W664+o6M0yXcWOtgmaPrBP D1b0XOxZfs4vw1kF8RBmzuk3jKuFP/vYr6f7pcirO7A6ciGL9gcmQxPF/pgTVxGVsaesgAY5352N CCkDJnvjaX4PxHAe7Ai4WtO4nrE7OK4r0FYu5kqmB9GejuyxCDmQMAo/k6cjDzC2gM3K6HjiZ/Qp 6BXnmRfhoS5sZiGG20FTBPYbAkzBvKQg2tMx0hSMbhF24Wnos9VEr2ceRCQ0wHg7Wcsv/B0TtboG V2X+lRvH4WrU7U95rbwSY1yC/u9jjJZmb5lX+LewLLayNl1wf+8Y7sjhLmgMnj1RHNtYbIWndawh eGjq8rupTUKX+XfSIMdBLg25NOSEUAY0U6FJhzyE32sNzYWcDvk2SiMs63L8C2nQJNjZYw/bYaPw 22g7GUPXuA+a/cSHqjPqMfwLafxtvugUPYt/IY3l28tZjg4IjedfSNNn+cmyvhd4Db+EdoT9+zL/ uoWVr0OPXz/TX0CuCrkd/06au4Z/J80fY+gw28dkZ1nHwfIWelsWflrCJjdKa2JcFYHXMeqRKF0G +Rr0RaDZBOTvSpeJyQ+fj6P1Dngmng5ZwOYdeJ4PltLRokDrwyB/h7qV+W1kH7n/lsP9rI8xkCvD g68vgz68BrkS5LbwcAD2WdAfIPpTxu9PaDT6s4p/2QyjrhCMuiw8t4RNU9gPg1wRqFHrScj4DTr9 OmSMV9fDKLiVBEJP8KtrZUMuShtDVmjlNDgZAk1ZlNrZiT4KLKslcARsjgC3wTIT+tLo8xL0GXOH twfl7TOQKwAbcSu307gPtzdD3scYbQVsAs0xtry9kBkO9N2BHjAH/OSA/CawAmotQa1DkNdAD35u T0Fb30O/nuWogAfMeNCHC7DZi1r5/afoFOcMjTlBMvGNrskU37Zrm9epb3LL1E60gHegFxtUzUc2 L2ZmUg4KU4jyUEHKTiWpnOX3KapNL1Nz6+MFepPepkRqT52pOw0J7COk6QEqRPfQo1TeenmanqPG 1MK22oD60ABqTR0ohXrQUPz/Wr+OoRibcQrbjF7K7muPUVWqQ6/QqyToRXqL3qE29Dp1oZ40jHKS rFW/fk2q3aDe8/moVcMGz+WjcfByL36P+kGb04tYj6XtlcAz9Cw9T03oNZJ2h29IfWkgJVEydaVe NBx1YikfPWR9lqEnqBrVpYfpXehzUVbLQ37KTUWt37JU0V4VVKeaVI+aUkvb7xL0EvWjQdSWOlI3 esPu434PspFHBeh+KmY9JNCTdqeuRfWpGbWye8kj1Ij602BqZ7NwKvXm38lOLNMtUTYCtgAmATsB ewD7JrZMTpWDgaOA44HTgfOAixNbdmsjVwHXAjcB04EZwP2JiR1T5FHgJUYlgFmBeYElgJVbJ7dv q2oA6wAbtO7UuaNqDGwBbA3sAEwB9gD2SeraMlENAI4AjgFOBc4GLgSusI5bqrXATcB0YEZyp+4d 1X7gUeAp4AXgNWCU0VXJnROT3ThgVmAuYF5b2NUtBCwOLAUsD3wcWBVYszP7qQtsCGwCfA2YBEwG du3ctXUntxewL3BgCuuHA0cBxwAnAqcBZwHndbNz5C4ELgGuAq4FbgLu6Na+U5L7G/Ag8BjwDPAS 8Ea3jokpIQLGAeOBeYFFgWW6dStVOvQ4sBqwDrAhsBmwtcUyoWRgKrAPcCBwBHC0xbKhicDpwLnA hcBlwJ8tJoQ2ALcCdwH3Ag8DT3Tr3qpb6BzwCvAWoxbAGKDp1j2lm44H5gbmAxYBlgCWSbVM6orA KsBqwNrA+sBGQL5zI2zuif83jtKu8/spz/+X5OBHtv/f6BLf9wrZvBjzv3amcObLDj34Txj5myht nvPwe/7/ieTY7P3XmP1vo8CMCOuVz5xgn2KM+9uY7W/jA/+EWf825kNPJY7On5BH8Ged+Zco7U6V k3L9m9K9kITdnwr8W8eC+Pnnv38sTEX+jaNjd9J/jf+aE8fu4P8as/wtLG2vNlLtrj+aptNC+pnS 6TBdcpQT7xRyEpxqTkOntZPqDHRGO9Odhc7PTrpz2LkklMgr6ojeYrgYL2aLJWKdyBAnxA0ZJ3PL 4rKyrC2byA6ytxwux8vZdg1yWzF+zMq6d523uut8xF3nI/90ru4qD9llvou086fzuIQ7z8PT7qxv rtzpP77Jnec56E7/OeLvOi9yl33Nu86b3XV+13hyZNx5nrPoXef17zrvdWf/80y9s/yBZXeeFy5x 13nJP53b9Ve41F3lA3AubH7I7o/wofr+sag/cmVjLqfNVUUC7ZbgmBEcDwfHc39lXXxBcFwWHNOC 49Y7e/GwuXOUDy+58/zRAXfaP/rbneelN9x5XmbRXeeL7zwv2/Cu80Z3nafcdd71rvMxf4oyK5Qf d9f5kjvty981S/9Uvumu8y13nW+9cxYrbbJoLDOJzseU5ExEtm1l/8iu1NH8RoabDXtFdgqFa5m0 cE3zs1lpVllNyDntnLZ255xz5DgXnAsknMvOZZLmafM0KfOMecbumxwPQlaXNbk9kV3ksBrbtjTc HxmxNUva85z200hXmkhptJ9uOPG2DzG2V/HhF0iEa4YbWKwVftFibdv7rDYn57OfFkrZzzyPm2Mk RVbbp+M4phn7SUvksOcncUwzO0jYs10W00yGxbWkEKG5qYDZb/u60pYewDHNHLTHVfb8EI5pf7I8 HFgeCSyPBpZ/BJb/6O9z6G8d9Pd59PcfJXVRUg8l9f9cYtahhxvQw03o4T9KtqBkK0rSUSJIC/tn l5kn+FsmWUVWy2oOy6oM1wg/a1lfaVZSyPZplWXKfsoW/Eza3/Xt0rL1W2K+CDPlODecG3bWMp1M y5Yr7HUP/LrwG4JfLXKL3BQjCogCFCuKiqIUJ2vJWuS5rdxWFHZbu60p4ia5SWTcdm47yuJ2dbtS VjfVTaVsbg+3B2U3+Uw+uscUMAXsmAqZQpTDFDFFKKcpauxnPlPcFKdcpoQpQfeZkqYk5TalTCn8 z4eylMeUM+XoAVPBVKC8ppKpRA+ax8xjlM88YZ6g/OZJ86SdHY63goi3QuZZ8ywVNs1NcypiEk0i PWTamDZU1LQ1bamYSTbJVNx0Mp1sokgxKVTCpJpUesT0MD2opOlletGjpq/pS6VMf9OfSpuBZiCV MUPMECprhplhlGBGmBFUzow0I6m8+cB8QBXMR+Yjqmg+Nh9TJTPWjKXK5hPzCT1mJpgJNj4nmUn0 hJliplAV86n5lJ40n5nP6CnzufmcnjYzzUyqar4wX9AzZo6ZQ9XMl+ZLqm6+Nl9TDbPALKBnzUKz kGqaRWYR1TKLzWKqbZaYJfScWW6WUx3M9/OY77o2Vn6mejZW0qi+WWuj5QWzzkZXA7PBRteLZpON roZmi42ql8xWG1WNTLqNqpfNDrtGGptddo28YjLsGmli9pq91BT/b6GZOWvOUnNz3pynFuaiuUiv msvmsv2cL2iAXR8DbCRlcbJQPye38wD1x3/dHug0cZrRICfZ6UhD8Z+2hztdnFR61xnuDKf3nXHO JzTKOe+cpw+dK84V+si56dyk0Zxk6GMREiEaI8IiTGNFNpGNxomcIid9Iu4X99N4UVAUpAmimChG E0UpUZ8miVTRnVaInqInrbTXEb3pR/GW6EurxEAxkH4WQ8QQWi1Gi9GUJsaKsbRGTBc7aa2M2Pxz SybIBIrKqrIaZXJMO0JOkpMcqVLVp45yE91Ep4zbxm3jlHXbum2dBLe9294p53Zzuznl3e5ud6eC 29Pt6VR0t4WGOpXiXoxr6ZyNG+I5TjScNVxdvBFuGp4svoq0jnQQFyP9IiPEDSNMjIwx+U1+mcUU NAVlVlPYFJbZzEPmIZndFDPF5D3mYfOwjDePmEdkDvOoeVTmNKVNaXmvSTAJMpcpb8rL+0xFU1Hm NpVNZXm/edw8LvOYKqaKfMA8ZZ6SeU1VU1U+aKqZajKfqWlqyvymhWkhC5jWprUsaJJMkixk2pl2 srDpaDrKIqaz6SwfMl1MF1nUdDfdZTHT0/SUxc0b5g35sOln+skS5m3ztnzEDDKDZEkz1AyVj5rh ZrgsZd4z78nS5n3zvixjPjQfyrJmtBktE8wYM0aWM+PMOFnejDfjZQUz0UyUFc1kM1lWMlPNVFnZ TDPT5GNmupkuHzczzAz5hJllZskqZraZLZ80c81c+ZSZZ+bJp818M19WNd+Yb+Qz5lvzraxmvjPf yerme/O9rGGWmqXyWbPCrJA1zY/mR1nL/GR+krXNarNaPmfWmDWyjvnF/CKfN+vNelnXbDQbZT2z 2WyW9c2v5lf5gtlmtskGZrvZLl80O81O2dDsNrvlS2aP2SMbmX1mn3zZnDanZWNzzpyTr5gL5oJs Yi6ZS7KpuWKuymbBZym+8klAri1mw9l1mjvNrbqN04Yc9Z36jkTodug2yZgqMVXs6vlvNv5vNv7f ycb/E325EX3F+WrLaR/a898Y+2+M/S/FmON2sNfzWZ0CIkHWUI0pD1WmqlSbGlAT+3mhg71+722v B4bThzSeptFsWkBLaBWto62UQQfpBF2wV/bkhJxwbC+Ssd1iU2PfwLF7bG8ce8S+iWPP2LfsMdVK fXFMje2HY/fY/jj2iH0bx56x79hjd2s3EMfU2EE4do8djGOP2CE49owdZo89rN1wHFNj38Wxe+wI HHvEvodjz9j37bGntRuFY2rsBzh2j/0Qxx6xH+HYM7YPCVs6wGL32KEWe8SOtNjzP2DkY4y8W+yY gJmxATPjAmY+CZgZHzAzIWBkYsDIpICRKQEjUwNGPg0YmRYw8lnAyOcBIzMCRmYGjMwKGPkiYGRO wMjcgJEvA0bmBYx8FTAy2o6/W+xkMDIdjMz+DxmZHzCyIGDkm4CRhQEj3waMfBcwsjiIle8DZpYE zCwNmFkWMLM8YGZFwMgPASM/BoysChj5KWDk54CR1QEjawJG1gaM/BIwsi5gZH3AyNdgZBEiZSUY SfsPGdkYMLIpYGRzwMiWgJFfA0a2BYykB4xsDxjZETCyM2Bkd8BIRsDIniBWfguY+T1gZm/AzL6A mf0BMwcCRg4FjBwOGDkSMHI0YOSPgJENYGQrGNmFSDn4HzJyPGDkRMDIyYCRUwEjpwNGzgaMnAsY OR8wciFg5GLAyOWAkSsBI1cDRq4FjFwPGLkZMHIrYOR2wEg0iJVMn5k48pmJc3xm4oTPTJwMmDkG Rs6AkUtg5AZHCv8PYO437qY1pmLOVjFF1pH1ZJJsKzvI12U32V32lG/It+RQOUwOl+/KEfI9+9nl oDwkD8sj8qj8Qx6Tx+UJeVKekqflGXlWnpPn5QV5UV6SlyPl+X/0OVucLbaByfzdfPmcfI6ErCvr kpStZRtSsp1sTyHZVXalGJkqUylW9pA97JVAL9mLPNlH9qGw7CvfoYicICfQPXKJ3EjxkXKRcrjL kJviVF71oMqn8qsCqqAqpAqrIuohHpnt0WXcXXco15/uTTyM+0HJbGFrPhRY5PmTRYk/lVkmZbK1 JhWv+Bd9i6qi5AXtxqscKqe6V+VS96nc6n6Vx1r8T7uCClEWlV3do1wVUlrFqFgVpzwVVhFlVBaV VfH9LmXH1s92gesI9YSqQmH1tHqajC0rT7nkDDlLzpVfyZ/lapkm18i18he5Tq6XG+TGv2Kc75bJ z+Xn1uNMye9bzZFzLN/zpM2jlrmfbHsH5cn/6/1zazXHli6RS+UyuVyukD/IlfJHuUr+9FdzDO8z 5AzrfZbkXwuZK+da719Jm51tDzda7zwO9l6S4v/S61+MA5wdDDjjen8zulCPo8HWczuJhfQODaRB NJiG0FAaZtf1uzQC/7n6fRpFH9hV/hGNpo9pDI2lcfSJXfMTaCJNosk0habSpzYDfEbT6XOaQTNp Fn1h88Ecmktf0jz6ir6m+TY7fEML6VtaRN/RYvre5oqltIyW0wr6gVbSjzZz/EQ/02pKozW0ln6x eWQ9baCNtIk20xb61WaVbZRO22kH7aRdtNvmmD30G/1Oe2kf7acDNuMcosN0hI7SH3SMjtv8c5JO 0Wk6Q2fpHJ232egiXaLLdIWu0jW6TjfoJt2i2xSlTBvQjnhBNBAviobiJdFIvCwai1dEE9FUNBPN RQvxqnhNtBStRKJoLdqIJNFWtBPtRQfxukgWHUUn0VmkiC5iqtgldosMsUf8Jn4Xe8U+sV8cEAfF IXFYHBFHxR/imDguToiT4pSME6fFGemJs+KcOC8uiIvikrgsroir4pq4Lm6Im+KWuC2iItOmIP4u hpRKujIktYyRsfIF2UC+KBvKZrK5fE22lB1lFzlQDpKD5RD5kfxETpRfy/nyG7lQLpbfy01ys9wi f5Vb5TaZLrfLHXKn3CV3ywy5R/4mf5d75T65Xx5Qj6nH+X+Cq3S1Xe1QO9UutVtlqD3qN/W72qv2 qf3qgDqoDqnD6og6qv5Qx9RxdUKdVKfUaXVGnVXn1Hl1QV1Ul9RldUVdVdfUdXVD3VS31G0VVZlu xM2un9ZV9TO6mq6ua+hndU1dS9fWz+k6+nldV9fT9fULuoF+UTfUL+lG+mXdWL+im+imuplurlvo V/VruqVupRPtXxv719b+tdcd9Os6WXfUnXRnnaK76K66m07V3XUP3VP30m/o3vavj35L99X9dH/9 th6g39ED9SA9WA/RQ/UwPVy/q0fo9/RI/b4epT/QH+qP9Gj9sR6jx+px+hM9Xk/QE/UkPVlP0VP1 p3qa/kxP13P0XP2lnqe/0l/r+XqB/kYv1N/qRfx/xfX3eoleqpfp5XqF/kGv1D/qVfon/bNerdP0 Gr1W/6LX6fV6g96oN+nNeov+VW/V23S63q536J16l96tM/Qe/Zv+Xe/V+/R+fUAf1If0YX1EH9V/ 6GP6uD6hT+pT+rQ+o8/qc/q8vqCv6ev6hr6pb+nbOqozYyjG0Z/rGXqmnqW/0LP1RX1JX9ZX9NW4 XnFvxPWOezOuT9xbcX3j+sX1j3s7bkDcO3ED4wbFDfbe9Pp4b3l9vX5ef+9tb4D3jjfQG+wN8YZ6 w7zh3rveCO89b6T3vjfKG+9N8CZ6k7zJ3hRvqvepN837zJvufe7N8GZ6s7wvvNneHO9Lb573lfe1 N99b4H3jLfS+9X7wVno/equ8n7yfvdVemrfOW+9t9DZ5m70t3q/eVm+bl+5t93Z4u7wD3iHviPeH d9w76Z31znsXvUveZe+Kd9W75l33bng3vVte1MsMU9gJi7AMq7AbDoUPhQ+Hj4SPhv8IHwsfD58I nwyfCp8OnwmfDZ8Lnw9fCF8MXwpfDl8JXw1fC18P3wjfDN8K3w5Hw5kRijgREZERFXEjoYiOxERi I3ERLxKORCImkiWSNZItkj1yTyQ+kiOSM3JvJFfkvkjuyP2RPJEHInkjD0byRfJHCkQKRgpFCkeK RCZEJkYmRSZHpkSmRj6NTIt8Fpke+TwyIzIzMgtPn3FHFndG+4kpwmZQ3O/8VNa2+/t2+bzd33fK JrIp7ZYt5Ku0B3vo7zJFptBeu+O9Tfvkh/+nve8AiyLp1q7TMz0MPU2TMyJZEJAZRLIoElREMGCO RAUREDGjCIphjauYEAUx5wyuioC6ioppd81Z1zUndFUMcE+XqLjr/rv/d+9++9//+aiHqurumZ4+ dare9z1VPT2SOeSWZKFkIfmZMvttylu/UN66Q3nrLuWte5IiSTG5TxniodRL6g2EzpsyLMdyoGS1 WC1Q0ZlRV9kN2S9wV02p5gaP6Szpc24yt5hhuJVcKWPIHeFeM650rjSKzpKuQravIuqoDqyQ88NQ AeUiA+xDdMaPUGQTRjhCaxtoTVyj0SIGxExxGLfPKSowv6A4gvklReWn157DWjmRo5YwIuaoABp/ WD1SXBD3Ky5hfkxxBfPjimuYn1Q8Et8p6ItnFAzEMwqG4hnpud7Ts35co1HHre8FDvPDguKLI5r0 iBY9ov3FESN6xJgeMaFHGKKOXlOi7zwZ8T5zH8aHMEwwE0wkTFumLZEy4Uw4Ybm53Fwi44q5YqLG PeWe4vkYdg1z+m/i2C8Z9v9vfv33MKzIoX+VN/9OztRRi1GLUxuoNgYZSGTOIOTMUMpmHZGZZlKe 7I4cKbLjB26M/YusmP4nfPh7NlyEPPiZAeuzy/9rbPiJ7ZAXFyJ/12dFf1Qfovb4oDxE3dEBlUd1 ne54i6qjByqOpVRz5KPieIO9tiv21H5iv/zInczgL3mT1+K1eR1el9fj9XkD3pA34o15E96UN+Mb 8OZ8Q96Ct+SteGvehrfl7fhGvD3vwDf+Kttmf51vBXWBExR/iXU3/J53BU1BS9D+HfseVlQojlAO rvwqC59DHr6guKS4orj2kY8FA8GQcvKjP2Tl97/nZcFIMBZM/iV2/oKb+ff/BnYOAwb0MZQ1AXui Bx0ggljTlVJ76AuxxBEGwADSFOIhnrjBIBhMmkEyjCaekA7zSCDkwhLSF3bCSRLFpDJpZCwznBlL xjMZTCaZwkxgJpNpzFRmBpnNzGLmkHl0zXMRM59BtKcx/lIJL9Eh+RI9iR5ZJTGQNCarJU4SF7JX opIEkjLK+D9Rxj9Do7ez0kLpSXKf1Wa1wYh9yb4EY/Y1+xpM2DfsGzCVYXOBmWyqbAY0kM2SzQUr 2TzZQmgky5UtAUdZvmwduMg2yHaAj6xIdggCZRWyU9BFdlZ2FvrKLsguQT/ZFdk1iEJt8B5iZbWo DbLU3NV8YJdac7UWsE/uIG8M5XInuQsckKvkKjgsd5e7Q4XcS+4FR8T1MzgqbylvCcfkreStoFIe LA+G4/K28rZwQh4qD4WT8gh5BJySd5N3g9PynvKe8IO8nzwafpTHy+PhvDqG/XCBi+Ki4SIXyw2E y1wClwbXueHccHiAPLsYHiLPlsKvyLOvoUbBKHoxaoo+itFMJJ/P32QyNGZo5DIHPtzfgtHoJrri 0gfi6vYU1dsDxJvI6rSHHWoaNzy+EpOYb0JVsJKW4lZJ3VYJbl3BJN5l4wiO2GuagPgriJ7gieds Da2RXNpBOyKFhbCQ3mVTQSJZE9aUNWMbsOZsQ9aCtWStWGvWhrVl7dhGrD3rwDZmHVkn1pltwrqw SlbFurJN4Uf4Cc7AWTgH5+ECXIRLcBmuwFW4BtfhBtyEW/Az3IZf4A7chXtwHx7AQ6lEKpW8lLyS vJZUS95I3kreSd5LaiS1/519UjRFytCZBin9toI2Xc0ywiQhZpik2HKN0FInIt6X5oJJjq3qjTrR FxNH/DApSCAJIjxph0kg3TBpkh6kJ+rDvph0SAwmXTIQkx4ZStKIPhlFRhNDkoHJGEcnQ0xAE7SI KY5RE9IAzMGcmNN7GhrieO1ALHC89iSWdFXXio5Ua0iERGJD73KwhWEwnNjBWBiLY3oqTCUOMA2m k8YwG2YTJxzBucQZR/BO0gTKoJy4wCE4TFRQCZWkKZ1vcqMjz51q6hA669SXzjr1p3NhJvXmwpzp 3VQ+TG9ssQaMilGhcnQXnxPJBDKBeCSECUHl2InphMqxG9ONsKh/YokMlc8gVI5TuG+InJvOzSYK bhW3mmhxa7kNRIc7y50jBtwF7jIx4q5xt1BTpyvGEUtkkYnERmQI4oAMsYw4inhOXBDPzxIVovgV 0gyR/BpxRyy/RTwQz28TT4yx7hAvxPR7xBtx/QHxQWx/hL76rS1NqC1tmQS0xfwLW7wYLzwiWiRh OmBMI6UWsdQiGeq8nkSN2iVHFTeEqFO7OGqXBrVLh9qlx23itqBF27giYkpttKA2WnF3uHvEjnvA PUG7REubUEtV1FJ3aqkn8uBKjBNWY7TRglodRK1ujfz0krRDdnqPEcqH1ddQHJ8x1CIX0UbEbnHc k097xJo9jt7ZMP/TPgbWwRbc0vv0OhwBX2kDXwbbjbaElPqWpe0ho+2hRttDTttDHXVvH8LRVlFQ b/O0bTS4HlwPImBkPo5oYvQ1B32ewy0mZhiDFREbbhdXStwxEntC/Lhn3GsSixpiMhmMamE2GY3q YAPJQu7fSeYh118gS6jPd1Gff4cMfoPspp7fQz2/l3q+hHp+H/V8KfV8GTL7E1KO7P6M7EeGf08O IJ/LyAnUOEbkLOoaS3IVtUxj8guqEgV5jOpCmzxDjjfBCACRECOkIYSIESRpJc4ykI7i3Taks2IM H0RO4HsawKK//Dr6rNu/6dWf+gOh38nEWFPs8x3q9Qfl5/5AIsTvQdftY0gwXbvX+/Q6hki4PG4F fmYZV4F9vFohjhzcS6P8D1diSa9BWXeVH6/VG9HsX0B3fKc+xUJCsRAoFkooFkopFrIUC2UUC9Uo FsopFqpTLOQoFiooFvIUCwWKhZoUC7UoFupQLNSlWKhHsVCfYqEhxULxqR370QKeaSPZTVr+6VoQ Axzo4FVaQWNwBW9oBSHQCa8uChIgBYajfsqCKTATcvBTC2AVbIBtsAv2wUE4CqewbS5jO9yFx/AC 3iAByRie0WGMGHPGhmmMbewOjdF6e2wLZ1r2RAYWyz7gRcu+4E3LfuBDy/7gS8tIaE7LKPCjZTS0 oGUMtKRlLPjTMg4CaRkPwbRMRFYXy2QIp2UuayiW0iLWiJbFrLFYCm/lCrFkdeW8WMpWyDVoWSIX aLlPrknL93ItWtbItWlZK9cRS1RQurRsoQn0cxLAAdFIE7UGg1tOmPdExSHqF8QktBJ7Itqowrw/ uGIeCU0xjwLUMmhbM8xjwB3zWPDAPA5aifefQADmgyAI80TULAxa1QbzFGiL+RAIwTwVQjHPhfaY 50EY5otZPcKgvfqYF7Pi7MtbOToGLcVejXZKMS+Ro+ZBG2XiHVVyNcxr5HLMa+XqhEHbUIHJWxAH HFu9kfMTkevTifgMgBySR1aQDWQH2UsOkkryE7lMfiYPEV/q1hSxJxlhX7fBvqQEd/DF3tQGwiAC W6M/WpUI67C1crGF1tOyD2ygZV/YSMt+sImW/WEzLaMQ3cUyGrbSMhK20TIGttMyFnbQMk7eQCzR RnOxRCsb0rJEbkHLfXJLWr6XW9GyRm5Ny1q5jViixba0bAFLqf/yqecKqOeWUc8VUs8tpz5bQX22 knpxFfXcauq5NdRza0V/yPVoi+vTFjegLW5IW9yItrgxbXET2uKmtMXNaIsDkWoSeme5hGIFoSMd NMWviYjPEg+j9/XbE1eqA+hsGBjQvmZI+4iR+NniWcD4U22g2JNE7EU8mU/7Cs3FVTrQQoQioI9x FVAkYii+iLxqRKZCF+gGPaA7dIWBXHdkwJ4f5qaZYcw4ZgozT5IrWSvZJrwT3gs1Qi2i7BJuKZfP FXDLuEJuObcCEbec288d4A5y33OHuMNchfBKYASJIBVYQSaoCXKumnvDveXece+5Gq5WgbCn+FYx RzFXkaOYp5ivWKBYqFikKFIUK3YpvlPsVuxR7FWUKPYpLiouK64qrituKn5W/KK4q7iveKh4rHiq qOLVeDmvznO8gud5DV7gNXlH3ol35pvwLrySV/GufFPejW/Gu/MevCfvxXvzPrwv35z341vwLXl/ vhUfwAfyQQIvaAiCoCPoCnrCa6FaeCOYCmaCuA5qRyNPQqNNFlVXO+S0BCYRlUMaRpU8MxajSg16 36xAY0hNGhlq0flfbclWyVaiI9ss20J0ZcWyYqIveyV7hZoR4yViKMZLqK2ucreJgxg1oZKagvrB W7ERlUMARvwXSChG/ZdIe6ofwqh+CKf6oQPVDx2pfuhE9UNnqh8iqH7oQvVDV6ofulH90F1Rg8qh B6+FaiGKqoWxVC2MF/RRLUxAO3eTnn/Fo/+aB/8WP330EEdbk9DWVKftqEPb0ZS2ow213Jla7k4t 70gtj6A6qduH6JPlWA06CkOIOLfcipjX7/+/7cV/3B8/9B08gzbtKYT2FAn1sIz6U6D+1KT+1KL+ 1Kb+1KH+1KX+1KP+1Kf+NKD+NKT+NKL+NKb+NEG/GRLTuqtXsEK9qxdQ89aNWHHM035KaD8F2k8Z 2k8lde/lWc167zVCVfIJBT6OdIocdBTQnszSnqxGe7L8QyQNz+AlvK1TA9qMAWPKWDMOkrZsNBvL DmDj2aHsMHaEYClYC7ZCI8FBcBScBRdBJbgJ7oKn4C34Cn5CS6GVECi0EfoKMUKcMFAYLCQLQ4Rh wghhlJAhZArZwhThG2GGMEuYI+QI84WFQq6QJywVCoRCYYWwSlgjrBM2CJuErcJ2YadQLHwn7BH2 CeXCAeF74bBwRDgmHBdOCqeFH4UzwjnhgnBJuCY8Ep4KVcIL4eV/7vv8z32f/2Pf9NBCzR/H6gpv kfNb/KX72nEkQoLscr27kOXiXTqf7vH5P9yn8+kOHzwH05zpW2+mQ9zTDhHo03wBvBB/sYJpxnji KwJwXzjTkenK9GB6MzGIVSmIemPFdbWvJXEtrX7Cs3yZPH+fxJW3+klcp/tqCvhNChZX8b5I4b9P 4ope/YS2/EFCPvgioc1fph5fS8gfXyRspS9TX5o+b8f8Jg3AlPAHKeVrSVHzZULW+jIZ/yZZfZnq 7PtwvfQM/5kf+YP5ESBXkT99kevboMqOoM9i+fgEFvFpLN+Q2WQ+Rj+FZA3ZhPHPblJGDmEE9AM5 j+2npOvN/7e557+Uh/8r+VdnQT7MkfBYzBfjHuIvxgLIdQY0ehDXWQAcMI5mkO3FZyTOhwVYXwji MzaXYuTFwE54gvWn8AzjlSpEE0C2fIn1V1BNOfMt1t9BDdZrGfE3kBhGKj6zkZFhXY3+ipCCwfib 0WA06bcxMcZmdBjxCXX6jAHWDRnxuWcmjCnWzRhLrFsxGLkxNkwjrNszDlhvTH+xyJFxxLoT44R1 Z8YZ600Y8Xlli5nFWM9j8rC+hFmC9aWS1vR5wm2JRBLC6opPbWXRXtZE/A0vNphtTSRsGzYS61Fs PNYT2CHis9zZEVgfyU7EejabjfVJbJn4/G22HOv75YjMcgajSEZupz6IgHqiOio99cEaawlorNPA qFdjvUY51vdrfI/1Q6hUQTBHnSFBNVlLIzxEZU1G0/LD96ypZxgSVfft4M8aBKgGAapBoN63WIFq EKAaBKgGAapBgGoQoBoEqAYBqkGAahCgGgSoBgGqQT5cIUOVCFAlAlSJAFUiQJUIUCUCVIkAVSJA lQhQJQJUiQBVIkCVCFAlAlSJAFUiQJUIUCUCVIkAVSJAlQhQJQJUiQBVIkCVCFAlAlSJAFUiQJUI UCUCVIkAVSJAlQhQJQJUiQBVIkCVCFAlAlSJAFUiQJUIUCUCVIkAVSJAlQhQJQJUiQBVIkCVCFAl AlSJAFUiQJUIUCUCVIkAVSJAlQhQJQJUiQBVIkCVCFAlAlSJAFUiQJUIUCUCVIkAVSJAlQhQJQJU iQBVIkCVCFAlAlSJAFUiQJUIUCXy8Rkln55YYjoUSz26l5gOUmaZDpCpN57UZtIrDVBjCrJMu+Ou CAZApVCqy1hHQcKYsEQZKeMcZSCFLA8GpAWdlR2VTvX2mBWajzejS0q+JJxEkaEkGUE0lqThv7jE 5Ke0rHcyqV7/iX7bwltMedssqXVf2euZbfvml3YvyDJorMyS6iizmDcFEgYYBIdyMs3Xd4r2ab+X 0Q+vtVRqfLpSkOI1pagclQ4ySRepQtcqIDllVGr8gIFpFvbRDhYqLy8Pi/bx0anJQ5Pj0iwCklNT mqjMlWYfXqz/5ZHk1Mi0+OQklaWyoXhcomv0+Xin5OQ0C/9haQOTU+PTRinNDTW8PJQqlVLpocS/ noYarkqVa1NV3eY/cEVZYFW/WYAlkiyEFdzPMVkAZC1TUp7yi09VmKl9/oKRfZX3C9fOsO33umZe 6PLimiWFFn7pHQsXF87q7zrodKuYUY83DD8ScbHqQd4ks1n5E+O2fz9odJT12Qa+VzVhzt35B0ud 43JzB9otOuXtVMrv7G5XHnyH8/Oc77TW3mvNw7YTWt2aqLknN7FL5Ias9GX9nUeE3lu0I8Ynt4OZ Sm6jl7/2zreORr80Xxit1787G5vfwKPT5Fern+Qwh0x/LO0StH3q+FLvhxE5YZverx49OC1ss1Hl fHV7S9Jtdv94jz3tdNR8u9b2ersijpOv+iGza7cnRT59DTJHSC++3Ldp/LyaLcczzq42Se3te3Tv U/lyK+V2WfaR7RYjdLOvMRLs+Msz1ygzVyozC7E1G4A0M1eZuWC8Vq9TKU/iU5dadxynt639zNpj y1L//f7L+pM+LhF9OO+uomzG8wVGzR7tApvzI7Sf9+7vmr9UccyP/XbKrCPev1hWPe0212lnQeuK qCfvzlX6+PRc6x4RX2MzuMWRynVX2fQrqhnN87VSEvbU6IQbxZe9OxVwS7unRfj9qDGb1xlXOHrY Ou+LXabzja1m9PJXEWbVlkfO6j/vtCEpwFXtfZbh69sDEjU6vix51ulwyZ2DyncWKvUpDeY5mLQ/ 04BZ+Wz8dcmOXi+2Xqno9ji27eFOEUU7JPY6tbPPPpXPGrdrwffrPZx+Hv3zmhG3hheQUwktyn9w /+a6v86aZgmmCZea3fjJTPrzmiBpRc+mnkntzTSiirnC6T+eiWgRfNysy6qUSzrek+cOy1/9QwGi Qn9lliT0AypwTdZrX+5Q23vJsbKPmNLgnwIDHPeerviHCOCKYKByxc1mH8FgFEVQPIlMl+nSWaWr 1BY35Lpct8ihA+OTBqThx2gpBXGnmq5ap9iYwclJMR8vjPujC7NWWn64MJP6x2NiLTrHD0jCs1p0 CPD/U1QoHjX2bJ/tQV5r3DaoLlbbNms7ouxtw6WHg4Y8OR1896fpBwaFdop6sYg50P5820QXG7/Y 0hPWxYo2xRnDrgSVrJsldPje1rGq4I6GdcPT/jZvohadNA5aOTek4aLj212sDoQ4pydf0Df3me6l 5XWlxOFFnI8zuNbWNGqzamciTM57u3tbdEZWde+CzInZM7dU7cpZftJzVYdsw0aTw64oX5LmLw5V N8/cN+lRotfqJm4vdzTZzI2N+nZkXN7CoRqTNlcdfG7xXbjOjOhjThdcg4wf7wmZ79Ohs9GJuI6j 1m2cXNHVLz+rw5Qkdmuz8jE2JZ3imi8Kq3Qc1zRpYmvZ6aWnQiYxSZPIirLJ1zrXocIbZeYrpa4I CrZSXsnJ5EhoLKsmkfzvgApN8Rp1URpKWaUEC2UDcYcgNZDqVTY4MZyk9Nr87OLBsNyOgU2WB0Y/ VSrEw5pSKQ6jSfWGDsWYMes3jQuxqzqxNyytsHujtMbDtk96vz40ZyRpf+/oA6PL8d8LhenPmYBD RydXvu5cuT+/pGvy0+jAtYHk8fyK3DNmuxT5xho55y6ab3QY++TRqqEbZl31mtl8YcJez8E/TNls /f7avbPx6t9OKam5Qfa4PX+VXq2l04R94DB/bqtB9kOKPWddV9M40mfg8ZLx/oPi1uwp3jPT7WiV RCt99K8/XG91bUzNjRsbal5eO6OxPeXsnFvhRZ6F6c4/Nb/kpojyYPIzE6ynvuwdPWtLzz1e5/pP 7zLRpOmvPgsLsvjCftO2OxUvW3ls/UWLolKlcbaFnkbjvZ1e+F/vq7w1xz5+cnnKzeer158Y3yp1 uIAYk4AY06kOYyI1R7anCklSfxyxiDP/4Kj+CDhNlUpEnKYIOEovpau42VTcVKb9LZdWd1zyB8f/ FGsKL3EzTu4vb7v4+Dpvt43WPQZdStxnaVWcU3F/U+mhM3b7XbWn7b3Yx+mte1dzfcdNszSu6C1P sg/NMGjhv2FGy63BUzQuZOZsXCA71S1weO/7z94JNzPSljc9lnb7ya3IZeMkxUG1Z/x0zmw52lfj 1JiqYl2Nd/0T7LOHTS/euDf7ruGO2ft+NSiK6vNI+5r3Y8te0zaPH3og6Na8qSP6L76zcUS5x4ym ei66l6KObDJZG75wwMafLLyUQ67PGBB885DZC40Oaf4ud1mbBMtBbbfMObjN63CrlYN7G4Wsn3Vu 5gS/kVzr8yu2TbQ+cLNqTNzWkLQSO/92eZF6/cOUFVnPTylS0h93aT/iB3mX4Zl1WPNamfkrbfsG muKIxUEoK6s3YJ9btpyZ3vF1RLuFtw3PJUxwY5vY3f06NIk40cBaaqQ0GP/1YR4ovqChtLnSR+lV 4FHQbFLTgWlpKd4uLtGpiU0Gf/Rhk+jkwS4pg+LFvS4pqckxw6LThroEdMaO1gR3Kdt8/EjUIb5K b6Xnx20lM8mp7oQjRoz42gljU+udKe03A4iiTctuyZ0HLLWY4AbCL4btfDc+OJ+Z8VhjVNqI8AWt jZ4T/fhxl6JmF74fsCzvZ3uHN13OLarpUNpXfft3qx5lPV9ontzjza/PbvA/TpP7GRhanC7bGdRa bte/m3q7nKfyyt3tk57ebKNj32yaZeq1fkWb43Vsch7fc1O/NC4peQ7X6Wjj0LbrXJ0m3V1W2cdu 717f6722TVDsbmYWPjGode2enGU91NbOvzKypFvGytVhlVUb83L9bx7rbeN3OcOtddjLkxVjljwo OpIXrdd588bcJ+dKTxYsWz/v6GjHyU5lhy+8S5RcLPXc+Ox0b2NDzbJXR8ev0pKbXJltfWfLslC/ +1u07UYK5U7frRh0eJYvos0SRJvsj2jTNv0RRRv2n0ObiPjBsUPTIgen1Ecbd6WXyl2patbMlcob Fd10VYqbysxVf8u1NVLafiBK86SA+JSBsakWgZ2DLII6h3mrlIGezs083TycA1oFe358oUTX/A+M 6BybOjw+OvZPAer+bja64sKoTRMD/VZuP/godKnNNa/h5upnXUO6j/zB8cJKtdlP7jR/W2KXvvzt 7bHjXE9eaD7Ny6Pq9XkfN4Of5mS9dXs4MDvVZNb1XaHXd2U/b8ox5YXDhzYL7fOs+EbI2Aa7ckZe qjXP1m8VPORERqNuOqcnhPucfHP15bRHLcitM1cjqw1ntFuR6ftrfMv7N6aWqoXvThtzj7/d+v76 xGdnBmTKXxscHau7Z+hN9dA3UW8fFXjletc80K6INI/qfp6LmHDGp127m11KXPqbzJzDBlzs8yCL s16gXsCqYqfNDTP3tyycM/t9UGBQcrOtQR4b49fGVrsFbDXc7+N1Q2t6lcnkWxEdGvosUW2sD1Cf AWlc6tMmLbo6XLd9NXAXvGt3Y9zJW35fYE/y3bAWC75zW99u0qy9efc3+PgHHDr138KetKEp0ZH/ I9jz8UxpX0NQ+e9Q+CsAFT86S503OH31ZPDUJqWn3UZnZjSy92/8/EfLOcKCjf0693WoflQeEbJm 7CvdUwq96vZVk/RJ0q0JDeyDVjt5uV5JzvXo+di606wIyYwWq/NiPF+6V+gFFHn7LTyicWBIpv3z uNWqm737zKru1OlG7wdzZy+JVw+devr08FA3jYQb6YGrHXtNiMgIsjG2PfhN8Pe2t4zHxzvovTQ8 9NTKKTO4r+OL6lWHRvhZJ1evismeWRilsdbZfM3t2X4ZtVtmvlvw8Nl76ebjbU/0TNvw5rluQ1Ov E8t3nN37Ysfjio1VXc3f+j6rONs4cG9pXouxcUbHt1lEc0dbNo91NU7ftqt5uV2bMCvjRUnTleXP vv0SoLQSFIvCy4jteu1LQQ27jx5Q+FuY+meCrzp0Urq5eYjo5IWb/0Dw9Tvg/DO8ueyR9HZzRauQ IUYVJ9r4dS57s15vt5PrHp3wThUTHvk1vdBWNce+6NuY6w07TNy9v93pDPb1k2H7ph1ec2ZTfErc yEZxd4uKn2R/d/zxuvc6KxQ9rBxcTra80FVqOnzn4JjBIRGXrjy7Wpo/4fD4axmhjEfOr2VL5V3N B7Y+fqFseG+XsUW20h1deyWYRdeOT/d9fEZq295rRJpan/29z0/ycBp2RLhv7qWePrxmSWLS6OsP /WYtWDpE6Nc43Ciqv+vSHyaEOVr1Hhg07arLRK0O26p3msxIfGy7WPf1Ma1z2cKLrOFD3Q/NG11Y 2V/2kN0yqWnx65xeE/0nds/OSdrS0KlNZXJewPWEuxl2Mwd9wJsssMcWsfn6CP1fEX5pydTrJkD1 QYypSD30/Co4Gn96gx4j5c050pkMI1EkgPh/GZr9Lq77CkDltNdW7U/vsEd75rJINRCmpwTNeDI0 oqSFOutcu6tj52yzR17fFi/vqrg6vcjH9PTbDauPFG/taGmaLI8fN0hSaBX8KHHH4HSrXcE/Tnw+ Q3Of2jfu5Q/G3UvpE5Q/54fKE1dmlt0obXw8/eGRTa5nJn93LPqg+2kjy9LhV31yt5sOXWo55fyO HToR01/k7Y8NybW3y+v/jabPYd3YkW32nNw4wTt8S1T3q8p797wa3JpaddErs1rXcnrM+GiZdH5V LhPgMiZ4yu5a5kJsdcjVi5K0udvZJL5yyWX7yPQ2zwzztC09GbPJG2Tfz3fddbvloc7NS9ZOvXo3 zmPGC6v5eZVbRkR09D6bGrjN+qUqS7oZQWo9A6DMnPwPRmVfxIqf57gLMi8q9T752x5UahKW3r0s 9oI6Z6pLVHz9aXW8ms9bCpWgrH9UX2n9+Y1SFfaxR4mp4T2mDUgaZOAr497n68UczVqrjKn3Fl7V VRlR0Hi8PWlP4kk0SSXJdGY+jqQRCxJBRpEU3BqA+yOxNpCMWmY33uYP6TVtVErygNTIlIGjLH4D b9IsIIqou5kjZ/yYN9PkZUhI3v1zS85ULm0d5dDq4MWWD6QRL8OOzCt/8a42etmD62TUAevljRbE HfzGP9u896IHYy7aSh6cTLlTsr9nSFlw95v9q5rlBL+5P66Z++qjsWXrR5v0LEvwXsot0os06nP7 xa8tD52wONYy4FRNldm+gX3H+QvrWodD9G33RrfPJU8KL832W8CM9Wo384p93xLDknahcyssGi6p ulW6Y13lo4iclbMPGmZMfmQ6fsirU0JZkf9dz/BblbuiFl9tNTw9t6HagbXFu9a5DA4+f1VNY3rR qFs9ew0+9uDZvRPuD3a3iXsysuKdb37RIV2nDdqeN755s8YoTi3yxrSJ0K9H2z1hy7KYhsosxvSz j2SqLIbHXfJ/exf9LSN9EWCo1XXRgj5Ko/o9UfF5FQjwMz8dYVWaSLWeKqUrEq2rV1P3nr/riNu9 cxeEZd/rqCufFvKi0HumXZRp8m8wS+wi/q1+FOYfHHvJeWUk+BoLqSebjIzolWw9KfQR920nZ5OM wNjqJTeWn1hgGrznaVc3a9OtY7ckzJZ+2zn7VWjCQdej7RVDpz/yGSedtGWksckvshat8q9NKJl4 vsHKxqxRN7vE/R5zR1/du3udya3UfUfnTQpPzb1Z8FLb4cVZVfm4BQuYe0uHjZhDitO3B7c4+mrl tvMyu3aVBwaFdpi799Uy25VnktqmBM5Ym3Hu/m2tSnOjwp4/DYvhh44YGmDr8J3RtetTqottQ1Tq taesVl/aab50yxsnz70K4+w1S7ft6BEeEZad8/zysRsvPN979j62N3T/pT6R2QPXT9p7b8Dy4rWj 97NrvfSri53To8h/ASfLy/YNCmVuZHN0cmVhbQ0KZW5kb2JqDQoxNTkwIDAgb2JqDQo8PC9UeXBl L1hSZWYvU2l6ZSAxNTkwL1dbIDEgNCAyXSAvUm9vdCAxIDAgUi9JbmZvIDY3IDAgUi9JRFs8MzA2 QzM2NkQ5Mzk3QzE0N0I5QjI1MjJBNDk0OEFENzQ+PDMwNkMzNjZEOTM5N0MxNDdCOUIyNTIyQTQ5 NDhBRDc0Pl0gL0ZpbHRlci9GbGF0ZURlY29kZS9MZW5ndGggMzAxOT4+DQpzdHJlYW0NCnicNdd3 /HZz/cDx7+u+cSORmchMNsmeySg07D0aZoWUkT0qm7JKpSIZkV2olJaEjGhYiRQayPYrs+s+z+t3 /XE9H59zznWuc84f5/V4T0yMPq+/3uh71omJqRyOBwd6YGDSCwOTzxmY5lTcODBl2oElVx9YaumB pWcZWGbKwPJzDawwPR4fWGmbgZV3Hlhl/4E1HxlY69mBdfztetMMbHDGwIbnD2z88sAmjtxikYEt Fx3YauaBrecf2OHmgR3vHdh59oFdzhzY9eKB3c4d2HNe3Daw1w0De18/sO9aA/udMLD/iQMHeFgH Xjdw0OUDh140cPiSA0f43ZErDhw9eeDYxQYusbrU5V6x08CVnsvV9wxc6zYfWmDg4fWm0pRjBmYY Lr7lDhtY/tKBbZ4f2Hb075MmJqZbdmJaTDdiYqOJGTDeN2V05Ha7DKvRxjAJkzENpsX4LFMwPf6C GZ1zvPENmAlvxMyYBW/CrJgNs2MuzIE58WbMg7nxFsyHefFWzI8FsCAWwiJYGG/DYng7FsWSWBxL YCksjWWwHJbFO7AC3onlsTJWxEpYBatiNayOtbAG1sS78S6sjfWwDtbF+ngP3osN8D5siI3wQbwf H8Cm2BibYDNsji2wJbbBVtga22NbbIedsAN2xEfwIXwYH8XO2AW7Yg/sht3xCXwMH8fe2BN74ZPY B5/Cp7E/9sV+OBAH4DM4BAfhYByKw3A4jsBncSSOwtH4HD6P43AMjsXxOAEn4iScjC/gizgFp+I0 nI4z8CV8GWfiK/gqvoaz8HV8A9/E2TgH38K5+DbOw/m4ABfiO7gIF+O7uASX4jJcjivwPVyJq3AN vo+r8UNcix/gR7gOP8ZP8DNcj5/il/g5foEbcQN+hV/jJtyMW3AbfoNb8VvcjjvwO9yJu/B7/AF/ xN24D/fgXjyA+/EnPIQ/48GBxr97eNLwnh+X5K/4Gx7Bo3gMf8c/8E/8C0/icTyBf+MZPIWn8Tye xXN4AS/i//AfvIz/4iW8hlfwqvsb9+91K1FMDVPD1DA1TA1Tw4Qvz6UZIXypYWqY8KWGqWHClxqm hulf+pcoJoPJYDKYDCaDyWAymPClhqlhMpj+pX+JYvqX/iWK6V/6lygmfKlhapgMJoPJYDKYDCaD 6V/6lygmgwlfapgaJoPJYDKYDCaDyWD6l/4lislgwpcapobJYDKYDCaDyWAymP6lf4liMpgMJoPJ YPqX/qV4aWMymOKljclgipc2JoOJYjKYDCaDKV5qmAymeGljMpjipY3JYKKYDCaDyWAymP6lf4li +pf+JYrpX/qXKKZ46V9qmDamf+lfopj+pX+JYoqXGiaDiWIymAwmg8lgMpgMpnjpX2qYNiaDyWAy mAwmg8lgipf+pYZpYzKYDCaDyWAymAwmg8lgMpgMJnypYWqY8KWGqWHClxqmhulf+pcopn8pXjKY NiZ8yWDamPClhqlh+pf+JYrpX4qXDKaNCV8ymDYmfKlhapj+pX+JYvqX4iWDaWPClwymjQlfatjU Gk5adxyGpvZv1LHxi1obk8FkMG1MBhtnUBsz9fQwhC81TA2TwYQvNUwNU7zUMDVM/xLFZDD9S/GS wZ5xK5LVc1ZTB799DhvGudFqGkzCZEyL6TAF02MGzIg3YCa8EW/CzJgFs2NWzIa5MAfmxJsxN96C eTAv3or5MD8WwIJ4GxbCwlgUi+DtWAKLYXEsiaWwNJbBsngHlsM7sTxWwMpYESthNayCVbEmVsca WAvvwtp4N9bBulgP6+M9eC82wgbYEB/A+/B+bIIPYmNsis2wObbCFtgS22JrbIMdsB22x47YCR/C h/ERfBQ7Yxfsit3wMeyOPbAnPo5P4JPYC3tjH3wKn8a+2A/74wB8BgfiIByKg3EIjsBhOByfxZE4 Cp/D53E0jsGxOA7H4wSciJNwMr6AL+IUnIrTcDrOwJfwZZyJr+Cr+BrOwtdxDs7GN/ENfAvn4ts4 D+fjAlyMi/AdXIjv4hJcistwOa7A9/E9XIUrcTWuwbX4AX6IH+E6/Bg/wfX4KX6Gn+MG/AK/xK/x K9yIW3ATbsZvcCtuw+24E3fgt/g97sLvcDf+gHG57sG9uA/348/4Ex7AX/AgHsLf8DD+ikfwKB7D 3/EP/BP/wuN4Ak/iafwbT2Fcp3GynsWLeB4vYOrkNs2q/1+ZqSPbKNDjEL2El/EKXsVreH1gmNxG BP1L+JLBtDEZTPhSw9Qw4UsNcxHJYPqX/qV4uepkMMVLG5PBhC9tTA2TwWQwGUwGk8FkMBlsQehf ipcMpo0pXjKYNiZ8yWDamAwmg8lgMpgMDuPcCBlMBpPB9C/FSwbTxhQvGUwbE75kMG1MBpPBYZwb IYPJYDKYDCaDyWD6l+Ilg2ljipcMpo3DyDZCBtPGZDAZTP/Sv0Qx/Uv/EsX0L+FLBtPGhC81TA0T vmGOG6GGyWAymAymf+lfopj+pX+JYjKYDCaDCV9qOMxxI4QvNUwNk8FkMBlMBtO/9C9RTP/Sv0Qx GUwGhzluhPClhqlhwpcapobJYDKYDCaDyWAymAwmg8lgMpjwpYapYcKXGqaGCV9qmBomgyle+pca po3JYDKYDCaDyWAymOKlf6lh2pgMJoPJYDKYDCaDKV76lxqmjclgMpgMJoPJYDKYDCZ8qWFqmPCl hqlhMpgMJoPpX/qXKKZ/6V+imAwmg8lgMpgMJoPJYDKYDCaDyWAyOB7gksFkMBlMBtO/9C9RTP/S v0QxGUwGk8GELzVMDRO+1DA1TAaTwWQwGUz/0r9EcTyyDXPcqHHjOj1nNXVyO3rWiQmraTAJkzEF 02I6TI8ZMCPegJnwRsyMWQaG5oxWU1s1Kuz4yNkwO+bAnJgLb8bcGJ9lHsyHefFWzI+FsAAWxCJY GG/D27EoFsPiWApLYEksi6WxDN6Jd2A5LI8VsCJWwspYBatiNayONfAurIm1sA7WxruxPtbFengP 3osNsCE2wvvwfnwAH8Sm2BibYAtshs2xNbbEVtgG22I7bI8dsCN2wofwYeyMj+Cj2A27YFd8DLtj D3wcn8Ce2At745PYB5/Cp7EvDsB+2B8H4TM4EIfiYByCw3A4jsCROAqfxefweRyNY3A8jsVxOAkn 4ER8ESfjCzgFp+I0nI4z8CV8GWfiKzgLX8XX8E18Hd/At3A2zsG5+DbOw/m4ABfiO7gIF+NSfBeX 4ApchsvxPVyJq/B9XI1rcC1+gB/iR7gOP8ZPcD1+ip/h5/gFfokb8CvciF/jJtyMW/Ab3IrbcDvu wG9xJ+7C7/BH/B5/wL24G/fgT7gP9+MB/BkP4iH8BQ/jr/gbHsHf8Sgew7/wD/wTT+JxPIF/4yk8 jWcwLtc4Wc/jBbyI/2I8x/0Hr+AlvIzX8SpeG0j/hslthP6lf4li+pf+JYrJYDKYnKWGqWHj8Klh apjiDZPbiFmhf+lf+pf+pX/DHDfq5viS5rEan1r/0r9EMRlM/9K/RDH9S/8SvrQxNUwGU7zUMBlM 8dLGZDBRTP/Sv4QvbUwNE77UMDVM+FLD1DAZTAbTv/QvUUz/0r9EMf1L+JLBtDHhSw1Tw4QvNUwN k8FkMP1L/xLF9C/9SxTTv/Qv4UsbU8OELzVMDRO+1DA1TAbTv/QvUUz/0r9EMf1L/xLFhC81TA0T vtQwNUz4UsPUMBlM/9K/RDH9S/8SxfQv/Uv40sbUMOFLDVPDhC81TA2TwWQw/Uv/EsX0L/1LFNO/ hC8ZTBsTvtQwNUz4UsPUMBlMBtO/9C/FSxuTwRQvbUwGE760MTVMBpPBZDAZTPhSw9QwGUwGk8Fk MBlMBtO/9C9RTAaTwWQwGUwGk8FkMBlMBpPBZDAZTAaTwWQwGUwGk8FkMBlMBpPBZDDhSw1Tw4Qv NUwNE77UMDVM/9K/RDEZTAaTwWQwGUwGE77UMDVMBpPBZDDhSw1Tw2QwGUwGk8FkMBlM/9K/RDEZ TPhSw2GOG73nx5FSw54bTW5nPTFsHO2bjDBptO+824fh7vxXpjJ50py4c2Lif+GltDcNCmVuZHN0 cmVhbQ0KZW5kb2JqDQp4cmVmDQowIDE1OTENCjAwMDAwMDAwNjggNjU1MzUgZg0KMDAwMDAwMDAx NyAwMDAwMCBuDQowMDAwMDAwMTI1IDAwMDAwIG4NCjAwMDAwMDAyMjIgMDAwMDAgbg0KMDAwMDAw MDQ3NiAwMDAwMCBuDQowMDAwMDAwNzU3IDAwMDAwIG4NCjAwMDAwMDA5MjcgMDAwMDAgbg0KMDAw MDAwMTE2OCAwMDAwMCBuDQowMDAwMDAxMjIxIDAwMDAwIG4NCjAwMDAwMDE3OTcgMDAwMDAgbg0K MDAwMDAxMDgxMCAwMDAwMCBuDQowMDAwMDExMDUyIDAwMDAwIG4NCjAwMDAwMTEyNzkgMDAwMDAg bg0KMDAwMDAxMTUyNyAwMDAwMCBuDQowMDAwMDEyODIyIDAwMDAwIG4NCjAwMDAwMTMwNjQgMDAw MDAgbg0KMDAwMDAxMzI5MSAwMDAwMCBuDQowMDAwMDEzNjU1IDAwMDAwIG4NCjAwMDAwMTM5MjIg MDAwMDAgbg0KMDAwMDAxNDE5NiAwMDAwMCBuDQowMDAwMDE1NTg4IDAwMDAwIG4NCjAwMDAwMTU4 NTggMDAwMDAgbg0KMDAwMDAxNjg4NSAwMDAwMCBuDQowMDAwMDE3MTU2IDAwMDAwIG4NCjAwMDAw MTgzMjMgMDAwMDAgbg0KMDAwMDAxODU5NiAwMDAwMCBuDQowMDAwMDIwMjE5IDAwMDAwIG4NCjAw MDAwMjA0NjYgMDAwMDAgbg0KMDAwMDAyMTI4NCAwMDAwMCBuDQowMDAwMDIxNTQyIDAwMDAwIG4N CjAwMDAwMjE3NzQgMDAwMDAgbg0KMDAwMDAyMjA0NiAwMDAwMCBuDQowMDAwMDIzNDk2IDAwMDAw IG4NCjAwMDAwMjM3NjggMDAwMDAgbg0KMDAwMDAyNTEwNyAwMDAwMCBuDQowMDAwMDI1NDk0IDAw MDAwIG4NCjAwMDAwMjU3NjkgMDAwMDAgbg0KMDAwMDAyNjAxNyAwMDAwMCBuDQowMDAwMDI3NDE5 IDAwMDAwIG4NCjAwMDAwMjc1OTYgMDAwMDAgbg0KMDAwMDAyNzg0MyAwMDAwMCBuDQowMDAwMDI4 MDkzIDAwMDAwIG4NCjAwMDAwMjkyNDUgMDAwMDAgbg0KMDAwMDAyOTU3NyAwMDAwMCBuDQowMDAw MDI5ODM0IDAwMDAwIG4NCjAwMDAwMzAwNzcgMDAwMDAgbg0KMDAwMDAzMDY1MCAwMDAwMCBuDQow MDAwMDMwODk0IDAwMDAwIG4NCjAwMDAwMzE2NTYgMDAwMDAgbg0KMDAwMDAzMjA0MiAwMDAwMCBu DQowMDAwMDMyMzE3IDAwMDAwIG4NCjAwMDAwMzI1NjQgMDAwMDAgbg0KMDAwMDAzMzc5NSAwMDAw MCBuDQowMDAwMDM0MzQzIDAwMDAwIG4NCjAwMDAwNDM3NzkgMDAwMDAgbg0KMDAwMDA0NDA0NiAw MDAwMCBuDQowMDAwMDQ0ODkzIDAwMDAwIG4NCjAwMDAwNDUxNDMgMDAwMDAgbg0KMDAwMDA0NjI5 NSAwMDAwMCBuDQowMDAwMDQ2ODQzIDAwMDAwIG4NCjAwMDAwNTcxMTkgMDAwMDAgbg0KMDAwMDA1 NzY2NyAwMDAwMCBuDQowMDAwMDY3NDYxIDAwMDAwIG4NCjAwMDAwNjgwMDkgMDAwMDAgbg0KMDAw MDA3Nzk0OCAwMDAwMCBuDQowMDAwMDc4NTA4IDAwMDAwIG4NCjAwMDAwODgwNTIgMDAwMDAgbg0K MDAwMDA4ODEwNiAwMDAwMCBuDQowMDAwMDAwMDY5IDY1NTM1IGYNCjAwMDAwMDAwNzAgNjU1MzUg Zg0KMDAwMDAwMDA3MSA2NTUzNSBmDQowMDAwMDAwMDcyIDY1NTM1IGYNCjAwMDAwMDAwNzMgNjU1 MzUgZg0KMDAwMDAwMDA3NCA2NTUzNSBmDQowMDAwMDAwMDc1IDY1NTM1IGYNCjAwMDAwMDAwNzYg NjU1MzUgZg0KMDAwMDAwMDA3NyA2NTUzNSBmDQowMDAwMDAwMDc4IDY1NTM1IGYNCjAwMDAwMDAw NzkgNjU1MzUgZg0KMDAwMDAwMDA4MCA2NTUzNSBmDQowMDAwMDAwMDgxIDY1NTM1IGYNCjAwMDAw MDAwODIgNjU1MzUgZg0KMDAwMDAwMDA4MyA2NTUzNSBmDQowMDAwMDAwMDg0IDY1NTM1IGYNCjAw MDAwMDAwODUgNjU1MzUgZg0KMDAwMDAwMDA4NiA2NTUzNSBmDQowMDAwMDAwMDg3IDY1NTM1IGYN CjAwMDAwMDAwODggNjU1MzUgZg0KMDAwMDAwMDA4OSA2NTUzNSBmDQowMDAwMDAwMDkwIDY1NTM1 IGYNCjAwMDAwMDAwOTEgNjU1MzUgZg0KMDAwMDAwMDA5MiA2NTUzNSBmDQowMDAwMDAwMDkzIDY1 NTM1IGYNCjAwMDAwMDAwOTQgNjU1MzUgZg0KMDAwMDAwMDA5NSA2NTUzNSBmDQowMDAwMDAwMDk2 IDY1NTM1IGYNCjAwMDAwMDAwOTcgNjU1MzUgZg0KMDAwMDAwMDA5OCA2NTUzNSBmDQowMDAwMDAw MDk5IDY1NTM1IGYNCjAwMDAwMDAxMDAgNjU1MzUgZg0KMDAwMDAwMDEwMSA2NTUzNSBmDQowMDAw MDAwMTAyIDY1NTM1IGYNCjAwMDAwMDAxMDMgNjU1MzUgZg0KMDAwMDAwMDEwNCA2NTUzNSBmDQow MDAwMDAwMTA1IDY1NTM1IGYNCjAwMDAwMDAxMDYgNjU1MzUgZg0KMDAwMDAwMDEwNyA2NTUzNSBm DQowMDAwMDAwMTA4IDY1NTM1IGYNCjAwMDAwMDAxMDkgNjU1MzUgZg0KMDAwMDAwMDExMCA2NTUz NSBmDQowMDAwMDAwMTExIDY1NTM1IGYNCjAwMDAwMDAxMTIgNjU1MzUgZg0KMDAwMDAwMDExMyA2 NTUzNSBmDQowMDAwMDAwMTE0IDY1NTM1IGYNCjAwMDAwMDAxMTUgNjU1MzUgZg0KMDAwMDAwMDEx NiA2NTUzNSBmDQowMDAwMDAwMTE3IDY1NTM1IGYNCjAwMDAwMDAxMTggNjU1MzUgZg0KMDAwMDAw MDExOSA2NTUzNSBmDQowMDAwMDAwMTIwIDY1NTM1IGYNCjAwMDAwMDAxMjEgNjU1MzUgZg0KMDAw MDAwMDEyMiA2NTUzNSBmDQowMDAwMDAwMTIzIDY1NTM1IGYNCjAwMDAwMDAxMjQgNjU1MzUgZg0K MDAwMDAwMDEyNSA2NTUzNSBmDQowMDAwMDAwMTI2IDY1NTM1IGYNCjAwMDAwMDAxMjcgNjU1MzUg Zg0KMDAwMDAwMDEyOCA2NTUzNSBmDQowMDAwMDAwMTI5IDY1NTM1IGYNCjAwMDAwMDAxMzAgNjU1 MzUgZg0KMDAwMDAwMDEzMSA2NTUzNSBmDQowMDAwMDAwMTMyIDY1NTM1IGYNCjAwMDAwMDAxMzMg NjU1MzUgZg0KMDAwMDAwMDEzNCA2NTUzNSBmDQowMDAwMDAwMTM1IDY1NTM1IGYNCjAwMDAwMDAx MzYgNjU1MzUgZg0KMDAwMDAwMDEzNyA2NTUzNSBmDQowMDAwMDAwMTM4IDY1NTM1IGYNCjAwMDAw MDAxMzkgNjU1MzUgZg0KMDAwMDAwMDE0MCA2NTUzNSBmDQowMDAwMDAwMTQxIDY1NTM1IGYNCjAw MDAwMDAxNDIgNjU1MzUgZg0KMDAwMDAwMDE0MyA2NTUzNSBmDQowMDAwMDAwMTQ0IDY1NTM1IGYN CjAwMDAwMDAxNDUgNjU1MzUgZg0KMDAwMDAwMDE0NiA2NTUzNSBmDQowMDAwMDAwMTQ3IDY1NTM1 IGYNCjAwMDAwMDAxNDggNjU1MzUgZg0KMDAwMDAwMDE0OSA2NTUzNSBmDQowMDAwMDAwMTUwIDY1 NTM1IGYNCjAwMDAwMDAxNTEgNjU1MzUgZg0KMDAwMDAwMDE1MiA2NTUzNSBmDQowMDAwMDAwMTUz IDY1NTM1IGYNCjAwMDAwMDAxNTQgNjU1MzUgZg0KMDAwMDAwMDE1NSA2NTUzNSBmDQowMDAwMDAw MTU2IDY1NTM1IGYNCjAwMDAwMDAxNTcgNjU1MzUgZg0KMDAwMDAwMDE1OCA2NTUzNSBmDQowMDAw MDAwMTU5IDY1NTM1IGYNCjAwMDAwMDAxNjAgNjU1MzUgZg0KMDAwMDAwMDE2MSA2NTUzNSBmDQow MDAwMDAwMTYyIDY1NTM1IGYNCjAwMDAwMDAxNjMgNjU1MzUgZg0KMDAwMDAwMDE2NCA2NTUzNSBm DQowMDAwMDAwMTY1IDY1NTM1IGYNCjAwMDAwMDAxNjYgNjU1MzUgZg0KMDAwMDAwMDE2NyA2NTUz NSBmDQowMDAwMDAwMTY4IDY1NTM1IGYNCjAwMDAwMDAxNjkgNjU1MzUgZg0KMDAwMDAwMDE3MCA2 NTUzNSBmDQowMDAwMDAwMTcxIDY1NTM1IGYNCjAwMDAwMDAxNzIgNjU1MzUgZg0KMDAwMDAwMDE3 MyA2NTUzNSBmDQowMDAwMDAwMTc0IDY1NTM1IGYNCjAwMDAwMDAxNzUgNjU1MzUgZg0KMDAwMDAw MDE3NiA2NTUzNSBmDQowMDAwMDAwMTc3IDY1NTM1IGYNCjAwMDAwMDAxNzggNjU1MzUgZg0KMDAw MDAwMDE3OSA2NTUzNSBmDQowMDAwMDAwMTgwIDY1NTM1IGYNCjAwMDAwMDAxODEgNjU1MzUgZg0K MDAwMDAwMDE4MiA2NTUzNSBmDQowMDAwMDAwMTgzIDY1NTM1IGYNCjAwMDAwMDAxODQgNjU1MzUg Zg0KMDAwMDAwMDE4NSA2NTUzNSBmDQowMDAwMDAwMTg2IDY1NTM1IGYNCjAwMDAwMDAxODcgNjU1 MzUgZg0KMDAwMDAwMDE4OCA2NTUzNSBmDQowMDAwMDAwMTg5IDY1NTM1IGYNCjAwMDAwMDAxOTAg NjU1MzUgZg0KMDAwMDAwMDE5MSA2NTUzNSBmDQowMDAwMDAwMTkyIDY1NTM1IGYNCjAwMDAwMDAx OTMgNjU1MzUgZg0KMDAwMDAwMDE5NCA2NTUzNSBmDQowMDAwMDAwMTk1IDY1NTM1IGYNCjAwMDAw MDAxOTYgNjU1MzUgZg0KMDAwMDAwMDE5NyA2NTUzNSBmDQowMDAwMDAwMTk4IDY1NTM1IGYNCjAw MDAwMDAxOTkgNjU1MzUgZg0KMDAwMDAwMDIwMCA2NTUzNSBmDQowMDAwMDAwMjAxIDY1NTM1IGYN CjAwMDAwMDAyMDIgNjU1MzUgZg0KMDAwMDAwMDIwMyA2NTUzNSBmDQowMDAwMDAwMjA0IDY1NTM1 IGYNCjAwMDAwMDAyMDUgNjU1MzUgZg0KMDAwMDAwMDIwNiA2NTUzNSBmDQowMDAwMDAwMjA3IDY1 NTM1IGYNCjAwMDAwMDAyMDggNjU1MzUgZg0KMDAwMDAwMDIwOSA2NTUzNSBmDQowMDAwMDAwMjEw IDY1NTM1IGYNCjAwMDAwMDAyMTEgNjU1MzUgZg0KMDAwMDAwMDIxMiA2NTUzNSBmDQowMDAwMDAw MjEzIDY1NTM1IGYNCjAwMDAwMDAyMTQgNjU1MzUgZg0KMDAwMDAwMDIxNSA2NTUzNSBmDQowMDAw MDAwMjE2IDY1NTM1IGYNCjAwMDAwMDAyMTcgNjU1MzUgZg0KMDAwMDAwMDIxOCA2NTUzNSBmDQow MDAwMDAwMjE5IDY1NTM1IGYNCjAwMDAwMDAyMjAgNjU1MzUgZg0KMDAwMDAwMDIyMSA2NTUzNSBm DQowMDAwMDAwMjIyIDY1NTM1IGYNCjAwMDAwMDAyMjMgNjU1MzUgZg0KMDAwMDAwMDIyNCA2NTUz NSBmDQowMDAwMDAwMjI1IDY1NTM1IGYNCjAwMDAwMDAyMjYgNjU1MzUgZg0KMDAwMDAwMDIyNyA2 NTUzNSBmDQowMDAwMDAwMjI4IDY1NTM1IGYNCjAwMDAwMDAyMjkgNjU1MzUgZg0KMDAwMDAwMDIz MCA2NTUzNSBmDQowMDAwMDAwMjMxIDY1NTM1IGYNCjAwMDAwMDAyMzIgNjU1MzUgZg0KMDAwMDAw MDIzMyA2NTUzNSBmDQowMDAwMDAwMjM0IDY1NTM1IGYNCjAwMDAwMDAyMzUgNjU1MzUgZg0KMDAw MDAwMDIzNiA2NTUzNSBmDQowMDAwMDAwMjM3IDY1NTM1IGYNCjAwMDAwMDAyMzggNjU1MzUgZg0K MDAwMDAwMDIzOSA2NTUzNSBmDQowMDAwMDAwMjQwIDY1NTM1IGYNCjAwMDAwMDAyNDEgNjU1MzUg Zg0KMDAwMDAwMDI0MiA2NTUzNSBmDQowMDAwMDAwMjQzIDY1NTM1IGYNCjAwMDAwMDAyNDQgNjU1 MzUgZg0KMDAwMDAwMDI0NSA2NTUzNSBmDQowMDAwMDAwMjQ2IDY1NTM1IGYNCjAwMDAwMDAyNDcg NjU1MzUgZg0KMDAwMDAwMDI0OCA2NTUzNSBmDQowMDAwMDAwMjQ5IDY1NTM1IGYNCjAwMDAwMDAy NTAgNjU1MzUgZg0KMDAwMDAwMDI1MSA2NTUzNSBmDQowMDAwMDAwMjUyIDY1NTM1IGYNCjAwMDAw MDAyNTMgNjU1MzUgZg0KMDAwMDAwMDI1NCA2NTUzNSBmDQowMDAwMDAwMjU1IDY1NTM1IGYNCjAw MDAwMDAyNTYgNjU1MzUgZg0KMDAwMDAwMDI1NyA2NTUzNSBmDQowMDAwMDAwMjU4IDY1NTM1IGYN CjAwMDAwMDAyNTkgNjU1MzUgZg0KMDAwMDAwMDI2MCA2NTUzNSBmDQowMDAwMDAwMjYxIDY1NTM1 IGYNCjAwMDAwMDAyNjIgNjU1MzUgZg0KMDAwMDAwMDI2MyA2NTUzNSBmDQowMDAwMDAwMjY0IDY1 NTM1IGYNCjAwMDAwMDAyNjUgNjU1MzUgZg0KMDAwMDAwMDI2NiA2NTUzNSBmDQowMDAwMDAwMjY3 IDY1NTM1IGYNCjAwMDAwMDAyNjggNjU1MzUgZg0KMDAwMDAwMDI2OSA2NTUzNSBmDQowMDAwMDAw MjcwIDY1NTM1IGYNCjAwMDAwMDAyNzEgNjU1MzUgZg0KMDAwMDAwMDI3MiA2NTUzNSBmDQowMDAw MDAwMjczIDY1NTM1IGYNCjAwMDAwMDAyNzQgNjU1MzUgZg0KMDAwMDAwMDI3NSA2NTUzNSBmDQow MDAwMDAwMjc2IDY1NTM1IGYNCjAwMDAwMDAyNzcgNjU1MzUgZg0KMDAwMDAwMDI3OCA2NTUzNSBm DQowMDAwMDAwMjc5IDY1NTM1IGYNCjAwMDAwMDAyODAgNjU1MzUgZg0KMDAwMDAwMDI4MSA2NTUz NSBmDQowMDAwMDAwMjgyIDY1NTM1IGYNCjAwMDAwMDAyODMgNjU1MzUgZg0KMDAwMDAwMDI4NCA2 NTUzNSBmDQowMDAwMDAwMjg1IDY1NTM1IGYNCjAwMDAwMDAyODYgNjU1MzUgZg0KMDAwMDAwMDI4 NyA2NTUzNSBmDQowMDAwMDAwMjg4IDY1NTM1IGYNCjAwMDAwMDAyODkgNjU1MzUgZg0KMDAwMDAw MDI5MCA2NTUzNSBmDQowMDAwMDAwMjkxIDY1NTM1IGYNCjAwMDAwMDAyOTIgNjU1MzUgZg0KMDAw MDAwMDI5MyA2NTUzNSBmDQowMDAwMDAwMjk0IDY1NTM1IGYNCjAwMDAwMDAyOTUgNjU1MzUgZg0K MDAwMDAwMDI5NiA2NTUzNSBmDQowMDAwMDAwMjk3IDY1NTM1IGYNCjAwMDAwMDAyOTggNjU1MzUg Zg0KMDAwMDAwMDI5OSA2NTUzNSBmDQowMDAwMDAwMzAwIDY1NTM1IGYNCjAwMDAwMDAzMDEgNjU1 MzUgZg0KMDAwMDAwMDMwMiA2NTUzNSBmDQowMDAwMDAwMzAzIDY1NTM1IGYNCjAwMDAwMDAzMDQg NjU1MzUgZg0KMDAwMDAwMDMwNSA2NTUzNSBmDQowMDAwMDAwMzA2IDY1NTM1IGYNCjAwMDAwMDAz MDcgNjU1MzUgZg0KMDAwMDAwMDMwOCA2NTUzNSBmDQowMDAwMDAwMzA5IDY1NTM1IGYNCjAwMDAw MDAzMTAgNjU1MzUgZg0KMDAwMDAwMDMxMSA2NTUzNSBmDQowMDAwMDAwMzEyIDY1NTM1IGYNCjAw MDAwMDAzMTMgNjU1MzUgZg0KMDAwMDAwMDMxNCA2NTUzNSBmDQowMDAwMDAwMzE1IDY1NTM1IGYN CjAwMDAwMDAzMTYgNjU1MzUgZg0KMDAwMDAwMDMxNyA2NTUzNSBmDQowMDAwMDAwMzE4IDY1NTM1 IGYNCjAwMDAwMDAzMTkgNjU1MzUgZg0KMDAwMDAwMDMyMCA2NTUzNSBmDQowMDAwMDAwMzIxIDY1 NTM1IGYNCjAwMDAwMDAzMjIgNjU1MzUgZg0KMDAwMDAwMDMyMyA2NTUzNSBmDQowMDAwMDAwMzI0 IDY1NTM1IGYNCjAwMDAwMDAzMjUgNjU1MzUgZg0KMDAwMDAwMDMyNiA2NTUzNSBmDQowMDAwMDAw MzI3IDY1NTM1IGYNCjAwMDAwMDAzMjggNjU1MzUgZg0KMDAwMDAwMDMyOSA2NTUzNSBmDQowMDAw MDAwMzMwIDY1NTM1IGYNCjAwMDAwMDAzMzEgNjU1MzUgZg0KMDAwMDAwMDMzMiA2NTUzNSBmDQow MDAwMDAwMzMzIDY1NTM1IGYNCjAwMDAwMDAzMzQgNjU1MzUgZg0KMDAwMDAwMDMzNSA2NTUzNSBm DQowMDAwMDAwMzM2IDY1NTM1IGYNCjAwMDAwMDAzMzcgNjU1MzUgZg0KMDAwMDAwMDMzOCA2NTUz NSBmDQowMDAwMDAwMzM5IDY1NTM1IGYNCjAwMDAwMDAzNDAgNjU1MzUgZg0KMDAwMDAwMDM0MSA2 NTUzNSBmDQowMDAwMDAwMzQyIDY1NTM1IGYNCjAwMDAwMDAzNDMgNjU1MzUgZg0KMDAwMDAwMDM0 NCA2NTUzNSBmDQowMDAwMDAwMzQ1IDY1NTM1IGYNCjAwMDAwMDAzNDYgNjU1MzUgZg0KMDAwMDAw MDM0NyA2NTUzNSBmDQowMDAwMDAwMzQ4IDY1NTM1IGYNCjAwMDAwMDAzNDkgNjU1MzUgZg0KMDAw MDAwMDM1MCA2NTUzNSBmDQowMDAwMDAwMzUxIDY1NTM1IGYNCjAwMDAwMDAzNTIgNjU1MzUgZg0K MDAwMDAwMDM1MyA2NTUzNSBmDQowMDAwMDAwMzU0IDY1NTM1IGYNCjAwMDAwMDAzNTUgNjU1MzUg Zg0KMDAwMDAwMDM1NiA2NTUzNSBmDQowMDAwMDAwMzU3IDY1NTM1IGYNCjAwMDAwMDAzNTggNjU1 MzUgZg0KMDAwMDAwMDM1OSA2NTUzNSBmDQowMDAwMDAwMzYwIDY1NTM1IGYNCjAwMDAwMDAzNjEg NjU1MzUgZg0KMDAwMDAwMDM2MiA2NTUzNSBmDQowMDAwMDAwMzYzIDY1NTM1IGYNCjAwMDAwMDAz NjQgNjU1MzUgZg0KMDAwMDAwMDM2NSA2NTUzNSBmDQowMDAwMDAwMzY2IDY1NTM1IGYNCjAwMDAw MDAzNjcgNjU1MzUgZg0KMDAwMDAwMDM2OCA2NTUzNSBmDQowMDAwMDAwMzY5IDY1NTM1IGYNCjAw MDAwMDAzNzAgNjU1MzUgZg0KMDAwMDAwMDM3MSA2NTUzNSBmDQowMDAwMDAwMzcyIDY1NTM1IGYN CjAwMDAwMDAzNzMgNjU1MzUgZg0KMDAwMDAwMDM3NCA2NTUzNSBmDQowMDAwMDAwMzc1IDY1NTM1 IGYNCjAwMDAwMDAzNzYgNjU1MzUgZg0KMDAwMDAwMDM3NyA2NTUzNSBmDQowMDAwMDAwMzc4IDY1 NTM1IGYNCjAwMDAwMDAzNzkgNjU1MzUgZg0KMDAwMDAwMDM4MCA2NTUzNSBmDQowMDAwMDAwMzgx IDY1NTM1IGYNCjAwMDAwMDAzODIgNjU1MzUgZg0KMDAwMDAwMDM4MyA2NTUzNSBmDQowMDAwMDAw Mzg0IDY1NTM1IGYNCjAwMDAwMDAzODUgNjU1MzUgZg0KMDAwMDAwMDM4NiA2NTUzNSBmDQowMDAw MDAwMzg3IDY1NTM1IGYNCjAwMDAwMDAzODggNjU1MzUgZg0KMDAwMDAwMDM4OSA2NTUzNSBmDQow MDAwMDAwMzkwIDY1NTM1IGYNCjAwMDAwMDAzOTEgNjU1MzUgZg0KMDAwMDAwMDM5MiA2NTUzNSBm DQowMDAwMDAwMzkzIDY1NTM1IGYNCjAwMDAwMDAzOTQgNjU1MzUgZg0KMDAwMDAwMDM5NSA2NTUz NSBmDQowMDAwMDAwMzk2IDY1NTM1IGYNCjAwMDAwMDAzOTcgNjU1MzUgZg0KMDAwMDAwMDM5OCA2 NTUzNSBmDQowMDAwMDAwMzk5IDY1NTM1IGYNCjAwMDAwMDA0MDAgNjU1MzUgZg0KMDAwMDAwMDQw MSA2NTUzNSBmDQowMDAwMDAwNDAyIDY1NTM1IGYNCjAwMDAwMDA0MDMgNjU1MzUgZg0KMDAwMDAw MDQwNCA2NTUzNSBmDQowMDAwMDAwNDA1IDY1NTM1IGYNCjAwMDAwMDA0MDYgNjU1MzUgZg0KMDAw MDAwMDQwNyA2NTUzNSBmDQowMDAwMDAwNDA4IDY1NTM1IGYNCjAwMDAwMDA0MDkgNjU1MzUgZg0K MDAwMDAwMDQxMCA2NTUzNSBmDQowMDAwMDAwNDExIDY1NTM1IGYNCjAwMDAwMDA0MTIgNjU1MzUg Zg0KMDAwMDAwMDQxMyA2NTUzNSBmDQowMDAwMDAwNDE0IDY1NTM1IGYNCjAwMDAwMDA0MTUgNjU1 MzUgZg0KMDAwMDAwMDQxNiA2NTUzNSBmDQowMDAwMDAwNDE3IDY1NTM1IGYNCjAwMDAwMDA0MTgg NjU1MzUgZg0KMDAwMDAwMDQxOSA2NTUzNSBmDQowMDAwMDAwNDIwIDY1NTM1IGYNCjAwMDAwMDA0 MjEgNjU1MzUgZg0KMDAwMDAwMDQyMiA2NTUzNSBmDQowMDAwMDAwNDIzIDY1NTM1IGYNCjAwMDAw MDA0MjQgNjU1MzUgZg0KMDAwMDAwMDQyNSA2NTUzNSBmDQowMDAwMDAwNDI2IDY1NTM1IGYNCjAw MDAwMDA0MjcgNjU1MzUgZg0KMDAwMDAwMDQyOCA2NTUzNSBmDQowMDAwMDAwNDI5IDY1NTM1IGYN CjAwMDAwMDA0MzAgNjU1MzUgZg0KMDAwMDAwMDQzMSA2NTUzNSBmDQowMDAwMDAwNDMyIDY1NTM1 IGYNCjAwMDAwMDA0MzMgNjU1MzUgZg0KMDAwMDAwMDQzNCA2NTUzNSBmDQowMDAwMDAwNDM1IDY1 NTM1IGYNCjAwMDAwMDA0MzYgNjU1MzUgZg0KMDAwMDAwMDQzNyA2NTUzNSBmDQowMDAwMDAwNDM4 IDY1NTM1IGYNCjAwMDAwMDA0MzkgNjU1MzUgZg0KMDAwMDAwMDQ0MCA2NTUzNSBmDQowMDAwMDAw NDQxIDY1NTM1IGYNCjAwMDAwMDA0NDIgNjU1MzUgZg0KMDAwMDAwMDQ0MyA2NTUzNSBmDQowMDAw MDAwNDQ0IDY1NTM1IGYNCjAwMDAwMDA0NDUgNjU1MzUgZg0KMDAwMDAwMDQ0NiA2NTUzNSBmDQow MDAwMDAwNDQ3IDY1NTM1IGYNCjAwMDAwMDA0NDggNjU1MzUgZg0KMDAwMDAwMDQ0OSA2NTUzNSBm DQowMDAwMDAwNDUwIDY1NTM1IGYNCjAwMDAwMDA0NTEgNjU1MzUgZg0KMDAwMDAwMDQ1MiA2NTUz NSBmDQowMDAwMDAwNDUzIDY1NTM1IGYNCjAwMDAwMDA0NTQgNjU1MzUgZg0KMDAwMDAwMDQ1NSA2 NTUzNSBmDQowMDAwMDAwNDU2IDY1NTM1IGYNCjAwMDAwMDA0NTcgNjU1MzUgZg0KMDAwMDAwMDQ1 OCA2NTUzNSBmDQowMDAwMDAwNDU5IDY1NTM1IGYNCjAwMDAwMDA0NjAgNjU1MzUgZg0KMDAwMDAw MDQ2MSA2NTUzNSBmDQowMDAwMDAwNDYyIDY1NTM1IGYNCjAwMDAwMDA0NjMgNjU1MzUgZg0KMDAw MDAwMDQ2NCA2NTUzNSBmDQowMDAwMDAwNDY1IDY1NTM1IGYNCjAwMDAwMDA0NjYgNjU1MzUgZg0K MDAwMDAwMDQ2NyA2NTUzNSBmDQowMDAwMDAwNDY4IDY1NTM1IGYNCjAwMDAwMDA0NjkgNjU1MzUg Zg0KMDAwMDAwMDQ3MCA2NTUzNSBmDQowMDAwMDAwNDcxIDY1NTM1IGYNCjAwMDAwMDA0NzIgNjU1 MzUgZg0KMDAwMDAwMDQ3MyA2NTUzNSBmDQowMDAwMDAwNDc0IDY1NTM1IGYNCjAwMDAwMDA0NzUg NjU1MzUgZg0KMDAwMDAwMDQ3NiA2NTUzNSBmDQowMDAwMDAwNDc3IDY1NTM1IGYNCjAwMDAwMDA0 NzggNjU1MzUgZg0KMDAwMDAwMDQ3OSA2NTUzNSBmDQowMDAwMDAwNDgwIDY1NTM1IGYNCjAwMDAw MDA0ODEgNjU1MzUgZg0KMDAwMDAwMDQ4MiA2NTUzNSBmDQowMDAwMDAwNDgzIDY1NTM1IGYNCjAw MDAwMDA0ODQgNjU1MzUgZg0KMDAwMDAwMDQ4NSA2NTUzNSBmDQowMDAwMDAwNDg2IDY1NTM1IGYN CjAwMDAwMDA0ODcgNjU1MzUgZg0KMDAwMDAwMDQ4OCA2NTUzNSBmDQowMDAwMDAwNDg5IDY1NTM1 IGYNCjAwMDAwMDA0OTAgNjU1MzUgZg0KMDAwMDAwMDQ5MSA2NTUzNSBmDQowMDAwMDAwNDkyIDY1 NTM1IGYNCjAwMDAwMDA0OTMgNjU1MzUgZg0KMDAwMDAwMDQ5NCA2NTUzNSBmDQowMDAwMDAwNDk1 IDY1NTM1IGYNCjAwMDAwMDA0OTYgNjU1MzUgZg0KMDAwMDAwMDQ5NyA2NTUzNSBmDQowMDAwMDAw NDk4IDY1NTM1IGYNCjAwMDAwMDA0OTkgNjU1MzUgZg0KMDAwMDAwMDUwMCA2NTUzNSBmDQowMDAw MDAwNTAxIDY1NTM1IGYNCjAwMDAwMDA1MDIgNjU1MzUgZg0KMDAwMDAwMDUwMyA2NTUzNSBmDQow MDAwMDAwNTA0IDY1NTM1IGYNCjAwMDAwMDA1MDUgNjU1MzUgZg0KMDAwMDAwMDUwNiA2NTUzNSBm DQowMDAwMDAwNTA3IDY1NTM1IGYNCjAwMDAwMDA1MDggNjU1MzUgZg0KMDAwMDAwMDUwOSA2NTUz NSBmDQowMDAwMDAwNTEwIDY1NTM1IGYNCjAwMDAwMDA1MTEgNjU1MzUgZg0KMDAwMDAwMDUxMiA2 NTUzNSBmDQowMDAwMDAwNTEzIDY1NTM1IGYNCjAwMDAwMDA1MTQgNjU1MzUgZg0KMDAwMDAwMDUx NSA2NTUzNSBmDQowMDAwMDAwNTE2IDY1NTM1IGYNCjAwMDAwMDA1MTcgNjU1MzUgZg0KMDAwMDAw MDUxOCA2NTUzNSBmDQowMDAwMDAwNTE5IDY1NTM1IGYNCjAwMDAwMDA1MjAgNjU1MzUgZg0KMDAw MDAwMDUyMSA2NTUzNSBmDQowMDAwMDAwNTIyIDY1NTM1IGYNCjAwMDAwMDA1MjMgNjU1MzUgZg0K MDAwMDAwMDUyNCA2NTUzNSBmDQowMDAwMDAwNTI1IDY1NTM1IGYNCjAwMDAwMDA1MjYgNjU1MzUg Zg0KMDAwMDAwMDUyNyA2NTUzNSBmDQowMDAwMDAwNTI4IDY1NTM1IGYNCjAwMDAwMDA1MjkgNjU1 MzUgZg0KMDAwMDAwMDUzMCA2NTUzNSBmDQowMDAwMDAwNTMxIDY1NTM1IGYNCjAwMDAwMDA1MzIg NjU1MzUgZg0KMDAwMDAwMDUzMyA2NTUzNSBmDQowMDAwMDAwNTM0IDY1NTM1IGYNCjAwMDAwMDA1 MzUgNjU1MzUgZg0KMDAwMDAwMDUzNiA2NTUzNSBmDQowMDAwMDAwNTM3IDY1NTM1IGYNCjAwMDAw MDA1MzggNjU1MzUgZg0KMDAwMDAwMDUzOSA2NTUzNSBmDQowMDAwMDAwNTQwIDY1NTM1IGYNCjAw MDAwMDA1NDEgNjU1MzUgZg0KMDAwMDAwMDU0MiA2NTUzNSBmDQowMDAwMDAwNTQzIDY1NTM1IGYN CjAwMDAwMDA1NDQgNjU1MzUgZg0KMDAwMDAwMDU0NSA2NTUzNSBmDQowMDAwMDAwNTQ2IDY1NTM1 IGYNCjAwMDAwMDA1NDcgNjU1MzUgZg0KMDAwMDAwMDU0OCA2NTUzNSBmDQowMDAwMDAwNTQ5IDY1 NTM1IGYNCjAwMDAwMDA1NTAgNjU1MzUgZg0KMDAwMDAwMDU1MSA2NTUzNSBmDQowMDAwMDAwNTUy IDY1NTM1IGYNCjAwMDAwMDA1NTMgNjU1MzUgZg0KMDAwMDAwMDU1NCA2NTUzNSBmDQowMDAwMDAw NTU1IDY1NTM1IGYNCjAwMDAwMDA1NTYgNjU1MzUgZg0KMDAwMDAwMDU1NyA2NTUzNSBmDQowMDAw MDAwNTU4IDY1NTM1IGYNCjAwMDAwMDA1NTkgNjU1MzUgZg0KMDAwMDAwMDU2MCA2NTUzNSBmDQow MDAwMDAwNTYxIDY1NTM1IGYNCjAwMDAwMDA1NjIgNjU1MzUgZg0KMDAwMDAwMDU2MyA2NTUzNSBm DQowMDAwMDAwNTY0IDY1NTM1IGYNCjAwMDAwMDA1NjUgNjU1MzUgZg0KMDAwMDAwMDU2NiA2NTUz NSBmDQowMDAwMDAwNTY3IDY1NTM1IGYNCjAwMDAwMDA1NjggNjU1MzUgZg0KMDAwMDAwMDU2OSA2 NTUzNSBmDQowMDAwMDAwNTcwIDY1NTM1IGYNCjAwMDAwMDA1NzEgNjU1MzUgZg0KMDAwMDAwMDU3 MiA2NTUzNSBmDQowMDAwMDAwNTczIDY1NTM1IGYNCjAwMDAwMDA1NzQgNjU1MzUgZg0KMDAwMDAw MDU3NSA2NTUzNSBmDQowMDAwMDAwNTc2IDY1NTM1IGYNCjAwMDAwMDA1NzcgNjU1MzUgZg0KMDAw MDAwMDU3OCA2NTUzNSBmDQowMDAwMDAwNTc5IDY1NTM1IGYNCjAwMDAwMDA1ODAgNjU1MzUgZg0K MDAwMDAwMDU4MSA2NTUzNSBmDQowMDAwMDAwNTgyIDY1NTM1IGYNCjAwMDAwMDA1ODMgNjU1MzUg Zg0KMDAwMDAwMDU4NCA2NTUzNSBmDQowMDAwMDAwNTg1IDY1NTM1IGYNCjAwMDAwMDA1ODYgNjU1 MzUgZg0KMDAwMDAwMDU4NyA2NTUzNSBmDQowMDAwMDAwNTg4IDY1NTM1IGYNCjAwMDAwMDA1ODkg NjU1MzUgZg0KMDAwMDAwMDU5MCA2NTUzNSBmDQowMDAwMDAwNTkxIDY1NTM1IGYNCjAwMDAwMDA1 OTIgNjU1MzUgZg0KMDAwMDAwMDU5MyA2NTUzNSBmDQowMDAwMDAwNTk0IDY1NTM1IGYNCjAwMDAw MDA1OTUgNjU1MzUgZg0KMDAwMDAwMDU5NiA2NTUzNSBmDQowMDAwMDAwNTk3IDY1NTM1IGYNCjAw MDAwMDA1OTggNjU1MzUgZg0KMDAwMDAwMDU5OSA2NTUzNSBmDQowMDAwMDAwNjAwIDY1NTM1IGYN CjAwMDAwMDA2MDEgNjU1MzUgZg0KMDAwMDAwMDYwMiA2NTUzNSBmDQowMDAwMDAwNjAzIDY1NTM1 IGYNCjAwMDAwMDA2MDQgNjU1MzUgZg0KMDAwMDAwMDYwNSA2NTUzNSBmDQowMDAwMDAwNjA2IDY1 NTM1IGYNCjAwMDAwMDA2MDcgNjU1MzUgZg0KMDAwMDAwMDYwOCA2NTUzNSBmDQowMDAwMDAwNjA5 IDY1NTM1IGYNCjAwMDAwMDA2MTAgNjU1MzUgZg0KMDAwMDAwMDYxMSA2NTUzNSBmDQowMDAwMDAw NjEyIDY1NTM1IGYNCjAwMDAwMDA2MTMgNjU1MzUgZg0KMDAwMDAwMDYxNCA2NTUzNSBmDQowMDAw MDAwNjE1IDY1NTM1IGYNCjAwMDAwMDA2MTYgNjU1MzUgZg0KMDAwMDAwMDYxNyA2NTUzNSBmDQow MDAwMDAwNjE4IDY1NTM1IGYNCjAwMDAwMDA2MTkgNjU1MzUgZg0KMDAwMDAwMDYyMCA2NTUzNSBm DQowMDAwMDAwNjIxIDY1NTM1IGYNCjAwMDAwMDA2MjIgNjU1MzUgZg0KMDAwMDAwMDYyMyA2NTUz NSBmDQowMDAwMDAwNjI0IDY1NTM1IGYNCjAwMDAwMDA2MjUgNjU1MzUgZg0KMDAwMDAwMDYyNiA2 NTUzNSBmDQowMDAwMDAwNjI3IDY1NTM1IGYNCjAwMDAwMDA2MjggNjU1MzUgZg0KMDAwMDAwMDYy OSA2NTUzNSBmDQowMDAwMDAwNjMwIDY1NTM1IGYNCjAwMDAwMDA2MzEgNjU1MzUgZg0KMDAwMDAw MDYzMiA2NTUzNSBmDQowMDAwMDAwNjMzIDY1NTM1IGYNCjAwMDAwMDA2MzQgNjU1MzUgZg0KMDAw MDAwMDYzNSA2NTUzNSBmDQowMDAwMDAwNjM2IDY1NTM1IGYNCjAwMDAwMDA2MzcgNjU1MzUgZg0K MDAwMDAwMDYzOCA2NTUzNSBmDQowMDAwMDAwNjM5IDY1NTM1IGYNCjAwMDAwMDA2NDAgNjU1MzUg Zg0KMDAwMDAwMDY0MSA2NTUzNSBmDQowMDAwMDAwNjQyIDY1NTM1IGYNCjAwMDAwMDA2NDMgNjU1 MzUgZg0KMDAwMDAwMDY0NCA2NTUzNSBmDQowMDAwMDAwNjQ1IDY1NTM1IGYNCjAwMDAwMDA2NDYg NjU1MzUgZg0KMDAwMDAwMDY0NyA2NTUzNSBmDQowMDAwMDAwNjQ4IDY1NTM1IGYNCjAwMDAwMDA2 NDkgNjU1MzUgZg0KMDAwMDAwMDY1MCA2NTUzNSBmDQowMDAwMDAwNjUxIDY1NTM1IGYNCjAwMDAw MDA2NTIgNjU1MzUgZg0KMDAwMDAwMDY1MyA2NTUzNSBmDQowMDAwMDAwNjU0IDY1NTM1IGYNCjAw MDAwMDA2NTUgNjU1MzUgZg0KMDAwMDAwMDY1NiA2NTUzNSBmDQowMDAwMDAwNjU3IDY1NTM1IGYN CjAwMDAwMDA2NTggNjU1MzUgZg0KMDAwMDAwMDY1OSA2NTUzNSBmDQowMDAwMDAwNjYwIDY1NTM1 IGYNCjAwMDAwMDA2NjEgNjU1MzUgZg0KMDAwMDAwMDY2MiA2NTUzNSBmDQowMDAwMDAwNjYzIDY1 NTM1IGYNCjAwMDAwMDA2NjQgNjU1MzUgZg0KMDAwMDAwMDY2NSA2NTUzNSBmDQowMDAwMDAwNjY2 IDY1NTM1IGYNCjAwMDAwMDA2NjcgNjU1MzUgZg0KMDAwMDAwMDY2OCA2NTUzNSBmDQowMDAwMDAw NjY5IDY1NTM1IGYNCjAwMDAwMDA2NzAgNjU1MzUgZg0KMDAwMDAwMDY3MSA2NTUzNSBmDQowMDAw MDAwNjcyIDY1NTM1IGYNCjAwMDAwMDA2NzMgNjU1MzUgZg0KMDAwMDAwMDY3NCA2NTUzNSBmDQow MDAwMDAwNjc1IDY1NTM1IGYNCjAwMDAwMDA2NzYgNjU1MzUgZg0KMDAwMDAwMDY3NyA2NTUzNSBm DQowMDAwMDAwNjc4IDY1NTM1IGYNCjAwMDAwMDA2NzkgNjU1MzUgZg0KMDAwMDAwMDY4MCA2NTUz NSBmDQowMDAwMDAwNjgxIDY1NTM1IGYNCjAwMDAwMDA2ODIgNjU1MzUgZg0KMDAwMDAwMDY4MyA2 NTUzNSBmDQowMDAwMDAwNjg0IDY1NTM1IGYNCjAwMDAwMDA2ODUgNjU1MzUgZg0KMDAwMDAwMDY4 NiA2NTUzNSBmDQowMDAwMDAwNjg3IDY1NTM1IGYNCjAwMDAwMDA2ODggNjU1MzUgZg0KMDAwMDAw MDY4OSA2NTUzNSBmDQowMDAwMDAwNjkwIDY1NTM1IGYNCjAwMDAwMDA2OTEgNjU1MzUgZg0KMDAw MDAwMDY5MiA2NTUzNSBmDQowMDAwMDAwNjkzIDY1NTM1IGYNCjAwMDAwMDA2OTQgNjU1MzUgZg0K MDAwMDAwMDY5NSA2NTUzNSBmDQowMDAwMDAwNjk2IDY1NTM1IGYNCjAwMDAwMDA2OTcgNjU1MzUg Zg0KMDAwMDAwMDY5OCA2NTUzNSBmDQowMDAwMDAwNjk5IDY1NTM1IGYNCjAwMDAwMDA3MDAgNjU1 MzUgZg0KMDAwMDAwMDcwMSA2NTUzNSBmDQowMDAwMDAwNzAyIDY1NTM1IGYNCjAwMDAwMDA3MDMg NjU1MzUgZg0KMDAwMDAwMDcwNCA2NTUzNSBmDQowMDAwMDAwNzA1IDY1NTM1IGYNCjAwMDAwMDA3 MDYgNjU1MzUgZg0KMDAwMDAwMDcwNyA2NTUzNSBmDQowMDAwMDAwNzA4IDY1NTM1IGYNCjAwMDAw MDA3MDkgNjU1MzUgZg0KMDAwMDAwMDcxMCA2NTUzNSBmDQowMDAwMDAwNzExIDY1NTM1IGYNCjAw MDAwMDA3MTIgNjU1MzUgZg0KMDAwMDAwMDcxMyA2NTUzNSBmDQowMDAwMDAwNzE0IDY1NTM1IGYN CjAwMDAwMDA3MTUgNjU1MzUgZg0KMDAwMDAwMDcxNiA2NTUzNSBmDQowMDAwMDAwNzE3IDY1NTM1 IGYNCjAwMDAwMDA3MTggNjU1MzUgZg0KMDAwMDAwMDcxOSA2NTUzNSBmDQowMDAwMDAwNzIwIDY1 NTM1IGYNCjAwMDAwMDA3MjEgNjU1MzUgZg0KMDAwMDAwMDcyMiA2NTUzNSBmDQowMDAwMDAwNzIz IDY1NTM1IGYNCjAwMDAwMDA3MjQgNjU1MzUgZg0KMDAwMDAwMDcyNSA2NTUzNSBmDQowMDAwMDAw NzI2IDY1NTM1IGYNCjAwMDAwMDA3MjcgNjU1MzUgZg0KMDAwMDAwMDcyOCA2NTUzNSBmDQowMDAw MDAwNzI5IDY1NTM1IGYNCjAwMDAwMDA3MzAgNjU1MzUgZg0KMDAwMDAwMDczMSA2NTUzNSBmDQow MDAwMDAwNzMyIDY1NTM1IGYNCjAwMDAwMDA3MzMgNjU1MzUgZg0KMDAwMDAwMDczNCA2NTUzNSBm DQowMDAwMDAwNzM1IDY1NTM1IGYNCjAwMDAwMDA3MzYgNjU1MzUgZg0KMDAwMDAwMDczNyA2NTUz NSBmDQowMDAwMDAwNzM4IDY1NTM1IGYNCjAwMDAwMDA3MzkgNjU1MzUgZg0KMDAwMDAwMDc0MCA2 NTUzNSBmDQowMDAwMDAwNzQxIDY1NTM1IGYNCjAwMDAwMDA3NDIgNjU1MzUgZg0KMDAwMDAwMDc0 MyA2NTUzNSBmDQowMDAwMDAwNzQ0IDY1NTM1IGYNCjAwMDAwMDA3NDUgNjU1MzUgZg0KMDAwMDAw MDc0NiA2NTUzNSBmDQowMDAwMDAwNzQ3IDY1NTM1IGYNCjAwMDAwMDA3NDggNjU1MzUgZg0KMDAw MDAwMDc0OSA2NTUzNSBmDQowMDAwMDAwNzUwIDY1NTM1IGYNCjAwMDAwMDA3NTEgNjU1MzUgZg0K MDAwMDAwMDc1MiA2NTUzNSBmDQowMDAwMDAwNzUzIDY1NTM1IGYNCjAwMDAwMDA3NTQgNjU1MzUg Zg0KMDAwMDAwMDc1NSA2NTUzNSBmDQowMDAwMDAwNzU2IDY1NTM1IGYNCjAwMDAwMDA3NTcgNjU1 MzUgZg0KMDAwMDAwMDc1OCA2NTUzNSBmDQowMDAwMDAwNzU5IDY1NTM1IGYNCjAwMDAwMDA3NjAg NjU1MzUgZg0KMDAwMDAwMDc2MSA2NTUzNSBmDQowMDAwMDAwNzYyIDY1NTM1IGYNCjAwMDAwMDA3 NjMgNjU1MzUgZg0KMDAwMDAwMDc2NCA2NTUzNSBmDQowMDAwMDAwNzY1IDY1NTM1IGYNCjAwMDAw MDA3NjYgNjU1MzUgZg0KMDAwMDAwMDc2NyA2NTUzNSBmDQowMDAwMDAwNzY4IDY1NTM1IGYNCjAw MDAwMDA3NjkgNjU1MzUgZg0KMDAwMDAwMDc3MCA2NTUzNSBmDQowMDAwMDAwNzcxIDY1NTM1IGYN CjAwMDAwMDA3NzIgNjU1MzUgZg0KMDAwMDAwMDc3MyA2NTUzNSBmDQowMDAwMDAwNzc0IDY1NTM1 IGYNCjAwMDAwMDA3NzUgNjU1MzUgZg0KMDAwMDAwMDc3NiA2NTUzNSBmDQowMDAwMDAwNzc3IDY1 NTM1IGYNCjAwMDAwMDA3NzggNjU1MzUgZg0KMDAwMDAwMDc3OSA2NTUzNSBmDQowMDAwMDAwNzgw IDY1NTM1IGYNCjAwMDAwMDA3ODEgNjU1MzUgZg0KMDAwMDAwMDc4MiA2NTUzNSBmDQowMDAwMDAw NzgzIDY1NTM1IGYNCjAwMDAwMDA3ODQgNjU1MzUgZg0KMDAwMDAwMDc4NSA2NTUzNSBmDQowMDAw MDAwNzg2IDY1NTM1IGYNCjAwMDAwMDA3ODcgNjU1MzUgZg0KMDAwMDAwMDc4OCA2NTUzNSBmDQow MDAwMDAwNzg5IDY1NTM1IGYNCjAwMDAwMDA3OTAgNjU1MzUgZg0KMDAwMDAwMDc5MSA2NTUzNSBm DQowMDAwMDAwNzkyIDY1NTM1IGYNCjAwMDAwMDA3OTMgNjU1MzUgZg0KMDAwMDAwMDc5NCA2NTUz NSBmDQowMDAwMDAwNzk1IDY1NTM1IGYNCjAwMDAwMDA3OTYgNjU1MzUgZg0KMDAwMDAwMDc5NyA2 NTUzNSBmDQowMDAwMDAwNzk4IDY1NTM1IGYNCjAwMDAwMDA3OTkgNjU1MzUgZg0KMDAwMDAwMDgw MCA2NTUzNSBmDQowMDAwMDAwODAxIDY1NTM1IGYNCjAwMDAwMDA4MDIgNjU1MzUgZg0KMDAwMDAw MDgwMyA2NTUzNSBmDQowMDAwMDAwODA0IDY1NTM1IGYNCjAwMDAwMDA4MDUgNjU1MzUgZg0KMDAw MDAwMDgwNiA2NTUzNSBmDQowMDAwMDAwODA3IDY1NTM1IGYNCjAwMDAwMDA4MDggNjU1MzUgZg0K MDAwMDAwMDgwOSA2NTUzNSBmDQowMDAwMDAwODEwIDY1NTM1IGYNCjAwMDAwMDA4MTEgNjU1MzUg Zg0KMDAwMDAwMDgxMiA2NTUzNSBmDQowMDAwMDAwODEzIDY1NTM1IGYNCjAwMDAwMDA4MTQgNjU1 MzUgZg0KMDAwMDAwMDgxNSA2NTUzNSBmDQowMDAwMDAwODE2IDY1NTM1IGYNCjAwMDAwMDA4MTcg NjU1MzUgZg0KMDAwMDAwMDgxOCA2NTUzNSBmDQowMDAwMDAwODE5IDY1NTM1IGYNCjAwMDAwMDA4 MjAgNjU1MzUgZg0KMDAwMDAwMDgyMSA2NTUzNSBmDQowMDAwMDAwODIyIDY1NTM1IGYNCjAwMDAw MDA4MjMgNjU1MzUgZg0KMDAwMDAwMDgyNCA2NTUzNSBmDQowMDAwMDAwODI1IDY1NTM1IGYNCjAw MDAwMDA4MjYgNjU1MzUgZg0KMDAwMDAwMDgyNyA2NTUzNSBmDQowMDAwMDAwODI4IDY1NTM1IGYN CjAwMDAwMDA4MjkgNjU1MzUgZg0KMDAwMDAwMDgzMCA2NTUzNSBmDQowMDAwMDAwODMxIDY1NTM1 IGYNCjAwMDAwMDA4MzIgNjU1MzUgZg0KMDAwMDAwMDgzMyA2NTUzNSBmDQowMDAwMDAwODM0IDY1 NTM1IGYNCjAwMDAwMDA4MzUgNjU1MzUgZg0KMDAwMDAwMDgzNiA2NTUzNSBmDQowMDAwMDAwODM3 IDY1NTM1IGYNCjAwMDAwMDA4MzggNjU1MzUgZg0KMDAwMDAwMDgzOSA2NTUzNSBmDQowMDAwMDAw ODQwIDY1NTM1IGYNCjAwMDAwMDA4NDEgNjU1MzUgZg0KMDAwMDAwMDg0MiA2NTUzNSBmDQowMDAw MDAwODQzIDY1NTM1IGYNCjAwMDAwMDA4NDQgNjU1MzUgZg0KMDAwMDAwMDg0NSA2NTUzNSBmDQow MDAwMDAwODQ2IDY1NTM1IGYNCjAwMDAwMDA4NDcgNjU1MzUgZg0KMDAwMDAwMDg0OCA2NTUzNSBm DQowMDAwMDAwODQ5IDY1NTM1IGYNCjAwMDAwMDA4NTAgNjU1MzUgZg0KMDAwMDAwMDg1MSA2NTUz NSBmDQowMDAwMDAwODUyIDY1NTM1IGYNCjAwMDAwMDA4NTMgNjU1MzUgZg0KMDAwMDAwMDg1NCA2 NTUzNSBmDQowMDAwMDAwODU1IDY1NTM1IGYNCjAwMDAwMDA4NTYgNjU1MzUgZg0KMDAwMDAwMDg1 NyA2NTUzNSBmDQowMDAwMDAwODU4IDY1NTM1IGYNCjAwMDAwMDA4NTkgNjU1MzUgZg0KMDAwMDAw MDg2MCA2NTUzNSBmDQowMDAwMDAwODYxIDY1NTM1IGYNCjAwMDAwMDA4NjIgNjU1MzUgZg0KMDAw MDAwMDg2MyA2NTUzNSBmDQowMDAwMDAwODY0IDY1NTM1IGYNCjAwMDAwMDA4NjUgNjU1MzUgZg0K MDAwMDAwMDg2NiA2NTUzNSBmDQowMDAwMDAwODY3IDY1NTM1IGYNCjAwMDAwMDA4NjggNjU1MzUg Zg0KMDAwMDAwMDg2OSA2NTUzNSBmDQowMDAwMDAwODcwIDY1NTM1IGYNCjAwMDAwMDA4NzEgNjU1 MzUgZg0KMDAwMDAwMDg3MiA2NTUzNSBmDQowMDAwMDAwODczIDY1NTM1IGYNCjAwMDAwMDA4NzQg NjU1MzUgZg0KMDAwMDAwMDg3NSA2NTUzNSBmDQowMDAwMDAwODc2IDY1NTM1IGYNCjAwMDAwMDA4 NzcgNjU1MzUgZg0KMDAwMDAwMDg3OCA2NTUzNSBmDQowMDAwMDAwODc5IDY1NTM1IGYNCjAwMDAw MDA4ODAgNjU1MzUgZg0KMDAwMDAwMDg4MSA2NTUzNSBmDQowMDAwMDAwODgyIDY1NTM1IGYNCjAw MDAwMDA4ODMgNjU1MzUgZg0KMDAwMDAwMDg4NCA2NTUzNSBmDQowMDAwMDAwODg1IDY1NTM1IGYN CjAwMDAwMDA4ODYgNjU1MzUgZg0KMDAwMDAwMDg4NyA2NTUzNSBmDQowMDAwMDAwODg4IDY1NTM1 IGYNCjAwMDAwMDA4ODkgNjU1MzUgZg0KMDAwMDAwMDg5MCA2NTUzNSBmDQowMDAwMDAwODkxIDY1 NTM1IGYNCjAwMDAwMDA4OTIgNjU1MzUgZg0KMDAwMDAwMDg5MyA2NTUzNSBmDQowMDAwMDAwODk0 IDY1NTM1IGYNCjAwMDAwMDA4OTUgNjU1MzUgZg0KMDAwMDAwMDg5NiA2NTUzNSBmDQowMDAwMDAw ODk3IDY1NTM1IGYNCjAwMDAwMDA4OTggNjU1MzUgZg0KMDAwMDAwMDg5OSA2NTUzNSBmDQowMDAw MDAwOTAwIDY1NTM1IGYNCjAwMDAwMDA5MDEgNjU1MzUgZg0KMDAwMDAwMDkwMiA2NTUzNSBmDQow MDAwMDAwOTAzIDY1NTM1IGYNCjAwMDAwMDA5MDQgNjU1MzUgZg0KMDAwMDAwMDkwNSA2NTUzNSBm DQowMDAwMDAwOTA2IDY1NTM1IGYNCjAwMDAwMDA5MDcgNjU1MzUgZg0KMDAwMDAwMDkwOCA2NTUz NSBmDQowMDAwMDAwOTA5IDY1NTM1IGYNCjAwMDAwMDA5MTAgNjU1MzUgZg0KMDAwMDAwMDkxMSA2 NTUzNSBmDQowMDAwMDAwOTEyIDY1NTM1IGYNCjAwMDAwMDA5MTMgNjU1MzUgZg0KMDAwMDAwMDkx NCA2NTUzNSBmDQowMDAwMDAwOTE1IDY1NTM1IGYNCjAwMDAwMDA5MTYgNjU1MzUgZg0KMDAwMDAw MDkxNyA2NTUzNSBmDQowMDAwMDAwOTE4IDY1NTM1IGYNCjAwMDAwMDA5MTkgNjU1MzUgZg0KMDAw MDAwMDkyMCA2NTUzNSBmDQowMDAwMDAwOTIxIDY1NTM1IGYNCjAwMDAwMDA5MjIgNjU1MzUgZg0K MDAwMDAwMDkyMyA2NTUzNSBmDQowMDAwMDAwOTI0IDY1NTM1IGYNCjAwMDAwMDA5MjUgNjU1MzUg Zg0KMDAwMDAwMDkyNiA2NTUzNSBmDQowMDAwMDAwOTI3IDY1NTM1IGYNCjAwMDAwMDA5MjggNjU1 MzUgZg0KMDAwMDAwMDkyOSA2NTUzNSBmDQowMDAwMDAwOTMwIDY1NTM1IGYNCjAwMDAwMDA5MzEg NjU1MzUgZg0KMDAwMDAwMDkzMiA2NTUzNSBmDQowMDAwMDAwOTMzIDY1NTM1IGYNCjAwMDAwMDA5 MzQgNjU1MzUgZg0KMDAwMDAwMDkzNSA2NTUzNSBmDQowMDAwMDAwOTM2IDY1NTM1IGYNCjAwMDAw MDA5MzcgNjU1MzUgZg0KMDAwMDAwMDkzOCA2NTUzNSBmDQowMDAwMDAwOTM5IDY1NTM1IGYNCjAw MDAwMDA5NDAgNjU1MzUgZg0KMDAwMDAwMDk0MSA2NTUzNSBmDQowMDAwMDAwOTQyIDY1NTM1IGYN CjAwMDAwMDA5NDMgNjU1MzUgZg0KMDAwMDAwMDk0NCA2NTUzNSBmDQowMDAwMDAwOTQ1IDY1NTM1 IGYNCjAwMDAwMDA5NDYgNjU1MzUgZg0KMDAwMDAwMDk0NyA2NTUzNSBmDQowMDAwMDAwOTQ4IDY1 NTM1IGYNCjAwMDAwMDA5NDkgNjU1MzUgZg0KMDAwMDAwMDk1MCA2NTUzNSBmDQowMDAwMDAwOTUx IDY1NTM1IGYNCjAwMDAwMDA5NTIgNjU1MzUgZg0KMDAwMDAwMDk1MyA2NTUzNSBmDQowMDAwMDAw OTU0IDY1NTM1IGYNCjAwMDAwMDA5NTUgNjU1MzUgZg0KMDAwMDAwMDk1NiA2NTUzNSBmDQowMDAw MDAwOTU3IDY1NTM1IGYNCjAwMDAwMDA5NTggNjU1MzUgZg0KMDAwMDAwMDk1OSA2NTUzNSBmDQow MDAwMDAwOTYwIDY1NTM1IGYNCjAwMDAwMDA5NjEgNjU1MzUgZg0KMDAwMDAwMDk2MiA2NTUzNSBm DQowMDAwMDAwOTYzIDY1NTM1IGYNCjAwMDAwMDA5NjQgNjU1MzUgZg0KMDAwMDAwMDk2NSA2NTUz NSBmDQowMDAwMDAwOTY2IDY1NTM1IGYNCjAwMDAwMDA5NjcgNjU1MzUgZg0KMDAwMDAwMDk2OCA2 NTUzNSBmDQowMDAwMDAwOTY5IDY1NTM1IGYNCjAwMDAwMDA5NzAgNjU1MzUgZg0KMDAwMDAwMDk3 MSA2NTUzNSBmDQowMDAwMDAwOTcyIDY1NTM1IGYNCjAwMDAwMDA5NzMgNjU1MzUgZg0KMDAwMDAw MDk3NCA2NTUzNSBmDQowMDAwMDAwOTc1IDY1NTM1IGYNCjAwMDAwMDA5NzYgNjU1MzUgZg0KMDAw MDAwMDk3NyA2NTUzNSBmDQowMDAwMDAwOTc4IDY1NTM1IGYNCjAwMDAwMDA5NzkgNjU1MzUgZg0K MDAwMDAwMDk4MCA2NTUzNSBmDQowMDAwMDAwOTgxIDY1NTM1IGYNCjAwMDAwMDA5ODIgNjU1MzUg Zg0KMDAwMDAwMDk4MyA2NTUzNSBmDQowMDAwMDAwOTg0IDY1NTM1IGYNCjAwMDAwMDA5ODUgNjU1 MzUgZg0KMDAwMDAwMDk4NiA2NTUzNSBmDQowMDAwMDAwOTg3IDY1NTM1IGYNCjAwMDAwMDA5ODgg NjU1MzUgZg0KMDAwMDAwMDk4OSA2NTUzNSBmDQowMDAwMDAwOTkwIDY1NTM1IGYNCjAwMDAwMDA5 OTEgNjU1MzUgZg0KMDAwMDAwMDk5MiA2NTUzNSBmDQowMDAwMDAwOTkzIDY1NTM1IGYNCjAwMDAw MDA5OTQgNjU1MzUgZg0KMDAwMDAwMDk5NSA2NTUzNSBmDQowMDAwMDAwOTk2IDY1NTM1IGYNCjAw MDAwMDA5OTcgNjU1MzUgZg0KMDAwMDAwMDk5OCA2NTUzNSBmDQowMDAwMDAwOTk5IDY1NTM1IGYN CjAwMDAwMDEwMDAgNjU1MzUgZg0KMDAwMDAwMTAwMSA2NTUzNSBmDQowMDAwMDAxMDAyIDY1NTM1 IGYNCjAwMDAwMDEwMDMgNjU1MzUgZg0KMDAwMDAwMTAwNCA2NTUzNSBmDQowMDAwMDAxMDA1IDY1 NTM1IGYNCjAwMDAwMDEwMDYgNjU1MzUgZg0KMDAwMDAwMTAwNyA2NTUzNSBmDQowMDAwMDAxMDA4 IDY1NTM1IGYNCjAwMDAwMDEwMDkgNjU1MzUgZg0KMDAwMDAwMTAxMCA2NTUzNSBmDQowMDAwMDAx MDExIDY1NTM1IGYNCjAwMDAwMDEwMTIgNjU1MzUgZg0KMDAwMDAwMTAxMyA2NTUzNSBmDQowMDAw MDAxMDE0IDY1NTM1IGYNCjAwMDAwMDEwMTUgNjU1MzUgZg0KMDAwMDAwMTAxNiA2NTUzNSBmDQow MDAwMDAxMDE3IDY1NTM1IGYNCjAwMDAwMDEwMTggNjU1MzUgZg0KMDAwMDAwMTAxOSA2NTUzNSBm DQowMDAwMDAxMDIwIDY1NTM1IGYNCjAwMDAwMDEwMjEgNjU1MzUgZg0KMDAwMDAwMTAyMiA2NTUz NSBmDQowMDAwMDAxMDIzIDY1NTM1IGYNCjAwMDAwMDEwMjQgNjU1MzUgZg0KMDAwMDAwMTAyNSA2 NTUzNSBmDQowMDAwMDAxMDI2IDY1NTM1IGYNCjAwMDAwMDEwMjcgNjU1MzUgZg0KMDAwMDAwMTAy OCA2NTUzNSBmDQowMDAwMDAxMDI5IDY1NTM1IGYNCjAwMDAwMDEwMzAgNjU1MzUgZg0KMDAwMDAw MTAzMSA2NTUzNSBmDQowMDAwMDAxMDMyIDY1NTM1IGYNCjAwMDAwMDEwMzMgNjU1MzUgZg0KMDAw MDAwMTAzNCA2NTUzNSBmDQowMDAwMDAxMDM1IDY1NTM1IGYNCjAwMDAwMDEwMzYgNjU1MzUgZg0K MDAwMDAwMTAzNyA2NTUzNSBmDQowMDAwMDAxMDM4IDY1NTM1IGYNCjAwMDAwMDEwMzkgNjU1MzUg Zg0KMDAwMDAwMTA0MCA2NTUzNSBmDQowMDAwMDAxMDQxIDY1NTM1IGYNCjAwMDAwMDEwNDIgNjU1 MzUgZg0KMDAwMDAwMTA0MyA2NTUzNSBmDQowMDAwMDAxMDQ0IDY1NTM1IGYNCjAwMDAwMDEwNDUg NjU1MzUgZg0KMDAwMDAwMTA0NiA2NTUzNSBmDQowMDAwMDAxMDQ3IDY1NTM1IGYNCjAwMDAwMDEw NDggNjU1MzUgZg0KMDAwMDAwMTA0OSA2NTUzNSBmDQowMDAwMDAxMDUwIDY1NTM1IGYNCjAwMDAw MDEwNTEgNjU1MzUgZg0KMDAwMDAwMTA1MiA2NTUzNSBmDQowMDAwMDAxMDUzIDY1NTM1IGYNCjAw MDAwMDEwNTQgNjU1MzUgZg0KMDAwMDAwMTA1NSA2NTUzNSBmDQowMDAwMDAxMDU2IDY1NTM1IGYN CjAwMDAwMDEwNTcgNjU1MzUgZg0KMDAwMDAwMTA1OCA2NTUzNSBmDQowMDAwMDAxMDU5IDY1NTM1 IGYNCjAwMDAwMDEwNjAgNjU1MzUgZg0KMDAwMDAwMTA2MSA2NTUzNSBmDQowMDAwMDAxMDYyIDY1 NTM1IGYNCjAwMDAwMDEwNjMgNjU1MzUgZg0KMDAwMDAwMTA2NCA2NTUzNSBmDQowMDAwMDAxMDY1 IDY1NTM1IGYNCjAwMDAwMDEwNjYgNjU1MzUgZg0KMDAwMDAwMTA2NyA2NTUzNSBmDQowMDAwMDAx MDY4IDY1NTM1IGYNCjAwMDAwMDEwNjkgNjU1MzUgZg0KMDAwMDAwMTA3MCA2NTUzNSBmDQowMDAw MDAxMDcxIDY1NTM1IGYNCjAwMDAwMDEwNzIgNjU1MzUgZg0KMDAwMDAwMTA3MyA2NTUzNSBmDQow MDAwMDAxMDc0IDY1NTM1IGYNCjAwMDAwMDEwNzUgNjU1MzUgZg0KMDAwMDAwMTA3NiA2NTUzNSBm DQowMDAwMDAxMDc3IDY1NTM1IGYNCjAwMDAwMDEwNzggNjU1MzUgZg0KMDAwMDAwMTA3OSA2NTUz NSBmDQowMDAwMDAxMDgwIDY1NTM1IGYNCjAwMDAwMDEwODEgNjU1MzUgZg0KMDAwMDAwMTA4MiA2 NTUzNSBmDQowMDAwMDAxMDgzIDY1NTM1IGYNCjAwMDAwMDEwODQgNjU1MzUgZg0KMDAwMDAwMTA4 NSA2NTUzNSBmDQowMDAwMDAxMDg2IDY1NTM1IGYNCjAwMDAwMDEwODcgNjU1MzUgZg0KMDAwMDAw MTA4OCA2NTUzNSBmDQowMDAwMDAxMDg5IDY1NTM1IGYNCjAwMDAwMDEwOTAgNjU1MzUgZg0KMDAw MDAwMTA5MSA2NTUzNSBmDQowMDAwMDAxMDkyIDY1NTM1IGYNCjAwMDAwMDEwOTMgNjU1MzUgZg0K MDAwMDAwMTA5NCA2NTUzNSBmDQowMDAwMDAxMDk1IDY1NTM1IGYNCjAwMDAwMDEwOTYgNjU1MzUg Zg0KMDAwMDAwMTA5NyA2NTUzNSBmDQowMDAwMDAxMDk4IDY1NTM1IGYNCjAwMDAwMDEwOTkgNjU1 MzUgZg0KMDAwMDAwMTEwMCA2NTUzNSBmDQowMDAwMDAxMTAxIDY1NTM1IGYNCjAwMDAwMDExMDIg NjU1MzUgZg0KMDAwMDAwMTEwMyA2NTUzNSBmDQowMDAwMDAxMTA0IDY1NTM1IGYNCjAwMDAwMDEx MDUgNjU1MzUgZg0KMDAwMDAwMTEwNiA2NTUzNSBmDQowMDAwMDAxMTA3IDY1NTM1IGYNCjAwMDAw MDExMDggNjU1MzUgZg0KMDAwMDAwMTEwOSA2NTUzNSBmDQowMDAwMDAxMTEwIDY1NTM1IGYNCjAw MDAwMDExMTEgNjU1MzUgZg0KMDAwMDAwMTExMiA2NTUzNSBmDQowMDAwMDAxMTEzIDY1NTM1IGYN CjAwMDAwMDExMTQgNjU1MzUgZg0KMDAwMDAwMTExNSA2NTUzNSBmDQowMDAwMDAxMTE2IDY1NTM1 IGYNCjAwMDAwMDExMTcgNjU1MzUgZg0KMDAwMDAwMTExOCA2NTUzNSBmDQowMDAwMDAxMTE5IDY1 NTM1IGYNCjAwMDAwMDExMjAgNjU1MzUgZg0KMDAwMDAwMTEyMSA2NTUzNSBmDQowMDAwMDAxMTIy IDY1NTM1IGYNCjAwMDAwMDExMjMgNjU1MzUgZg0KMDAwMDAwMTEyNCA2NTUzNSBmDQowMDAwMDAx MTI1IDY1NTM1IGYNCjAwMDAwMDExMjYgNjU1MzUgZg0KMDAwMDAwMTEyNyA2NTUzNSBmDQowMDAw MDAxMTI4IDY1NTM1IGYNCjAwMDAwMDExMjkgNjU1MzUgZg0KMDAwMDAwMTEzMCA2NTUzNSBmDQow MDAwMDAxMTMxIDY1NTM1IGYNCjAwMDAwMDExMzIgNjU1MzUgZg0KMDAwMDAwMTEzMyA2NTUzNSBm DQowMDAwMDAxMTM0IDY1NTM1IGYNCjAwMDAwMDExMzUgNjU1MzUgZg0KMDAwMDAwMTEzNiA2NTUz NSBmDQowMDAwMDAxMTM3IDY1NTM1IGYNCjAwMDAwMDExMzggNjU1MzUgZg0KMDAwMDAwMTEzOSA2 NTUzNSBmDQowMDAwMDAxMTQwIDY1NTM1IGYNCjAwMDAwMDExNDEgNjU1MzUgZg0KMDAwMDAwMTE0 MiA2NTUzNSBmDQowMDAwMDAxMTQzIDY1NTM1IGYNCjAwMDAwMDExNDQgNjU1MzUgZg0KMDAwMDAw MTE0NSA2NTUzNSBmDQowMDAwMDAxMTQ2IDY1NTM1IGYNCjAwMDAwMDExNDcgNjU1MzUgZg0KMDAw MDAwMTE0OCA2NTUzNSBmDQowMDAwMDAxMTQ5IDY1NTM1IGYNCjAwMDAwMDExNTAgNjU1MzUgZg0K MDAwMDAwMTE1MSA2NTUzNSBmDQowMDAwMDAxMTUyIDY1NTM1IGYNCjAwMDAwMDExNTMgNjU1MzUg Zg0KMDAwMDAwMTE1NCA2NTUzNSBmDQowMDAwMDAxMTU1IDY1NTM1IGYNCjAwMDAwMDExNTYgNjU1 MzUgZg0KMDAwMDAwMTE1NyA2NTUzNSBmDQowMDAwMDAxMTU4IDY1NTM1IGYNCjAwMDAwMDExNTkg NjU1MzUgZg0KMDAwMDAwMTE2MCA2NTUzNSBmDQowMDAwMDAxMTYxIDY1NTM1IGYNCjAwMDAwMDEx NjIgNjU1MzUgZg0KMDAwMDAwMTE2MyA2NTUzNSBmDQowMDAwMDAxMTY0IDY1NTM1IGYNCjAwMDAw MDExNjUgNjU1MzUgZg0KMDAwMDAwMTE2NiA2NTUzNSBmDQowMDAwMDAxMTY3IDY1NTM1IGYNCjAw MDAwMDExNjggNjU1MzUgZg0KMDAwMDAwMTE2OSA2NTUzNSBmDQowMDAwMDAxMTcwIDY1NTM1IGYN CjAwMDAwMDExNzEgNjU1MzUgZg0KMDAwMDAwMTE3MiA2NTUzNSBmDQowMDAwMDAxMTczIDY1NTM1 IGYNCjAwMDAwMDExNzQgNjU1MzUgZg0KMDAwMDAwMTE3NSA2NTUzNSBmDQowMDAwMDAxMTc2IDY1 NTM1IGYNCjAwMDAwMDExNzcgNjU1MzUgZg0KMDAwMDAwMTE3OCA2NTUzNSBmDQowMDAwMDAxMTc5 IDY1NTM1IGYNCjAwMDAwMDExODAgNjU1MzUgZg0KMDAwMDAwMTE4MSA2NTUzNSBmDQowMDAwMDAx MTgyIDY1NTM1IGYNCjAwMDAwMDExODMgNjU1MzUgZg0KMDAwMDAwMTE4NCA2NTUzNSBmDQowMDAw MDAxMTg1IDY1NTM1IGYNCjAwMDAwMDExODYgNjU1MzUgZg0KMDAwMDAwMTE4NyA2NTUzNSBmDQow MDAwMDAxMTg4IDY1NTM1IGYNCjAwMDAwMDExODkgNjU1MzUgZg0KMDAwMDAwMTE5MCA2NTUzNSBm DQowMDAwMDAxMTkxIDY1NTM1IGYNCjAwMDAwMDExOTIgNjU1MzUgZg0KMDAwMDAwMTE5MyA2NTUz NSBmDQowMDAwMDAxMTk0IDY1NTM1IGYNCjAwMDAwMDExOTUgNjU1MzUgZg0KMDAwMDAwMTE5NiA2 NTUzNSBmDQowMDAwMDAxMTk3IDY1NTM1IGYNCjAwMDAwMDExOTggNjU1MzUgZg0KMDAwMDAwMTE5 OSA2NTUzNSBmDQowMDAwMDAxMjAwIDY1NTM1IGYNCjAwMDAwMDEyMDEgNjU1MzUgZg0KMDAwMDAw MTIwMiA2NTUzNSBmDQowMDAwMDAxMjAzIDY1NTM1IGYNCjAwMDAwMDEyMDQgNjU1MzUgZg0KMDAw MDAwMTIwNSA2NTUzNSBmDQowMDAwMDAxMjA2IDY1NTM1IGYNCjAwMDAwMDEyMDcgNjU1MzUgZg0K MDAwMDAwMTIwOCA2NTUzNSBmDQowMDAwMDAxMjA5IDY1NTM1IGYNCjAwMDAwMDEyMTAgNjU1MzUg Zg0KMDAwMDAwMTIxMSA2NTUzNSBmDQowMDAwMDAxMjEyIDY1NTM1IGYNCjAwMDAwMDEyMTMgNjU1 MzUgZg0KMDAwMDAwMTIxNCA2NTUzNSBmDQowMDAwMDAxMjE1IDY1NTM1IGYNCjAwMDAwMDEyMTYg NjU1MzUgZg0KMDAwMDAwMTIxNyA2NTUzNSBmDQowMDAwMDAxMjE4IDY1NTM1IGYNCjAwMDAwMDEy MTkgNjU1MzUgZg0KMDAwMDAwMTIyMCA2NTUzNSBmDQowMDAwMDAxMjIxIDY1NTM1IGYNCjAwMDAw MDEyMjIgNjU1MzUgZg0KMDAwMDAwMTIyMyA2NTUzNSBmDQowMDAwMDAxMjI0IDY1NTM1IGYNCjAw MDAwMDEyMjUgNjU1MzUgZg0KMDAwMDAwMTIyNiA2NTUzNSBmDQowMDAwMDAxMjI3IDY1NTM1IGYN CjAwMDAwMDEyMjggNjU1MzUgZg0KMDAwMDAwMTIyOSA2NTUzNSBmDQowMDAwMDAxMjMwIDY1NTM1 IGYNCjAwMDAwMDEyMzEgNjU1MzUgZg0KMDAwMDAwMTIzMiA2NTUzNSBmDQowMDAwMDAxMjMzIDY1 NTM1IGYNCjAwMDAwMDEyMzQgNjU1MzUgZg0KMDAwMDAwMTIzNSA2NTUzNSBmDQowMDAwMDAxMjM2 IDY1NTM1IGYNCjAwMDAwMDEyMzcgNjU1MzUgZg0KMDAwMDAwMTIzOCA2NTUzNSBmDQowMDAwMDAx MjM5IDY1NTM1IGYNCjAwMDAwMDEyNDAgNjU1MzUgZg0KMDAwMDAwMTI0MSA2NTUzNSBmDQowMDAw MDAxMjQyIDY1NTM1IGYNCjAwMDAwMDEyNDMgNjU1MzUgZg0KMDAwMDAwMTI0NCA2NTUzNSBmDQow MDAwMDAxMjQ1IDY1NTM1IGYNCjAwMDAwMDEyNDYgNjU1MzUgZg0KMDAwMDAwMTI0NyA2NTUzNSBm DQowMDAwMDAxMjQ4IDY1NTM1IGYNCjAwMDAwMDEyNDkgNjU1MzUgZg0KMDAwMDAwMTI1MCA2NTUz NSBmDQowMDAwMDAxMjUxIDY1NTM1IGYNCjAwMDAwMDEyNTIgNjU1MzUgZg0KMDAwMDAwMTI1MyA2 NTUzNSBmDQowMDAwMDAxMjU0IDY1NTM1IGYNCjAwMDAwMDEyNTUgNjU1MzUgZg0KMDAwMDAwMTI1 NiA2NTUzNSBmDQowMDAwMDAxMjU3IDY1NTM1IGYNCjAwMDAwMDEyNTggNjU1MzUgZg0KMDAwMDAw MTI1OSA2NTUzNSBmDQowMDAwMDAxMjYwIDY1NTM1IGYNCjAwMDAwMDEyNjEgNjU1MzUgZg0KMDAw MDAwMTI2MiA2NTUzNSBmDQowMDAwMDAxMjYzIDY1NTM1IGYNCjAwMDAwMDEyNjQgNjU1MzUgZg0K MDAwMDAwMTI2NSA2NTUzNSBmDQowMDAwMDAxMjY2IDY1NTM1IGYNCjAwMDAwMDEyNjcgNjU1MzUg Zg0KMDAwMDAwMTI2OCA2NTUzNSBmDQowMDAwMDAxMjY5IDY1NTM1IGYNCjAwMDAwMDEyNzAgNjU1 MzUgZg0KMDAwMDAwMTI3MSA2NTUzNSBmDQowMDAwMDAxMjcyIDY1NTM1IGYNCjAwMDAwMDEyNzMg NjU1MzUgZg0KMDAwMDAwMTI3NCA2NTUzNSBmDQowMDAwMDAxMjc1IDY1NTM1IGYNCjAwMDAwMDEy NzYgNjU1MzUgZg0KMDAwMDAwMTI3NyA2NTUzNSBmDQowMDAwMDAxMjc4IDY1NTM1IGYNCjAwMDAw MDEyNzkgNjU1MzUgZg0KMDAwMDAwMTI4MCA2NTUzNSBmDQowMDAwMDAxMjgxIDY1NTM1IGYNCjAw MDAwMDEyODIgNjU1MzUgZg0KMDAwMDAwMTI4MyA2NTUzNSBmDQowMDAwMDAxMjg0IDY1NTM1IGYN CjAwMDAwMDEyODUgNjU1MzUgZg0KMDAwMDAwMTI4NiA2NTUzNSBmDQowMDAwMDAxMjg3IDY1NTM1 IGYNCjAwMDAwMDEyODggNjU1MzUgZg0KMDAwMDAwMTI4OSA2NTUzNSBmDQowMDAwMDAxMjkwIDY1 NTM1IGYNCjAwMDAwMDEyOTEgNjU1MzUgZg0KMDAwMDAwMTI5MiA2NTUzNSBmDQowMDAwMDAxMjkz IDY1NTM1IGYNCjAwMDAwMDEyOTQgNjU1MzUgZg0KMDAwMDAwMTI5NSA2NTUzNSBmDQowMDAwMDAx Mjk2IDY1NTM1IGYNCjAwMDAwMDEyOTcgNjU1MzUgZg0KMDAwMDAwMTI5OCA2NTUzNSBmDQowMDAw MDAxMjk5IDY1NTM1IGYNCjAwMDAwMDEzMDAgNjU1MzUgZg0KMDAwMDAwMTMwMSA2NTUzNSBmDQow MDAwMDAxMzAyIDY1NTM1IGYNCjAwMDAwMDEzMDMgNjU1MzUgZg0KMDAwMDAwMTMwNCA2NTUzNSBm DQowMDAwMDAxMzA1IDY1NTM1IGYNCjAwMDAwMDEzMDYgNjU1MzUgZg0KMDAwMDAwMTMwNyA2NTUz NSBmDQowMDAwMDAxMzA4IDY1NTM1IGYNCjAwMDAwMDEzMDkgNjU1MzUgZg0KMDAwMDAwMTMxMCA2 NTUzNSBmDQowMDAwMDAxMzExIDY1NTM1IGYNCjAwMDAwMDEzMTIgNjU1MzUgZg0KMDAwMDAwMTMx MyA2NTUzNSBmDQowMDAwMDAxMzE0IDY1NTM1IGYNCjAwMDAwMDEzMTUgNjU1MzUgZg0KMDAwMDAw MTMxNiA2NTUzNSBmDQowMDAwMDAxMzE3IDY1NTM1IGYNCjAwMDAwMDEzMTggNjU1MzUgZg0KMDAw MDAwMTMxOSA2NTUzNSBmDQowMDAwMDAxMzIwIDY1NTM1IGYNCjAwMDAwMDEzMjEgNjU1MzUgZg0K MDAwMDAwMTMyMiA2NTUzNSBmDQowMDAwMDAxMzIzIDY1NTM1IGYNCjAwMDAwMDEzMjQgNjU1MzUg Zg0KMDAwMDAwMTMyNSA2NTUzNSBmDQowMDAwMDAxMzI2IDY1NTM1IGYNCjAwMDAwMDEzMjcgNjU1 MzUgZg0KMDAwMDAwMTMyOCA2NTUzNSBmDQowMDAwMDAxMzI5IDY1NTM1IGYNCjAwMDAwMDEzMzAg NjU1MzUgZg0KMDAwMDAwMTMzMSA2NTUzNSBmDQowMDAwMDAxMzMyIDY1NTM1IGYNCjAwMDAwMDEz MzMgNjU1MzUgZg0KMDAwMDAwMTMzNCA2NTUzNSBmDQowMDAwMDAxMzM1IDY1NTM1IGYNCjAwMDAw MDEzMzYgNjU1MzUgZg0KMDAwMDAwMTMzNyA2NTUzNSBmDQowMDAwMDAxMzM4IDY1NTM1IGYNCjAw MDAwMDEzMzkgNjU1MzUgZg0KMDAwMDAwMTM0MCA2NTUzNSBmDQowMDAwMDAxMzQxIDY1NTM1IGYN CjAwMDAwMDEzNDIgNjU1MzUgZg0KMDAwMDAwMTM0MyA2NTUzNSBmDQowMDAwMDAxMzQ0IDY1NTM1 IGYNCjAwMDAwMDEzNDUgNjU1MzUgZg0KMDAwMDAwMTM0NiA2NTUzNSBmDQowMDAwMDAxMzQ3IDY1 NTM1IGYNCjAwMDAwMDEzNDggNjU1MzUgZg0KMDAwMDAwMTM0OSA2NTUzNSBmDQowMDAwMDAxMzUw IDY1NTM1IGYNCjAwMDAwMDEzNTEgNjU1MzUgZg0KMDAwMDAwMTM1MiA2NTUzNSBmDQowMDAwMDAx MzUzIDY1NTM1IGYNCjAwMDAwMDEzNTQgNjU1MzUgZg0KMDAwMDAwMTM1NSA2NTUzNSBmDQowMDAw MDAxMzU2IDY1NTM1IGYNCjAwMDAwMDEzNTcgNjU1MzUgZg0KMDAwMDAwMTM1OCA2NTUzNSBmDQow MDAwMDAxMzU5IDY1NTM1IGYNCjAwMDAwMDEzNjAgNjU1MzUgZg0KMDAwMDAwMTM2MSA2NTUzNSBm DQowMDAwMDAxMzYyIDY1NTM1IGYNCjAwMDAwMDEzNjMgNjU1MzUgZg0KMDAwMDAwMTM2NCA2NTUz NSBmDQowMDAwMDAxMzY1IDY1NTM1IGYNCjAwMDAwMDEzNjYgNjU1MzUgZg0KMDAwMDAwMTM2NyA2 NTUzNSBmDQowMDAwMDAxMzY4IDY1NTM1IGYNCjAwMDAwMDEzNjkgNjU1MzUgZg0KMDAwMDAwMTM3 MCA2NTUzNSBmDQowMDAwMDAxMzcxIDY1NTM1IGYNCjAwMDAwMDEzNzIgNjU1MzUgZg0KMDAwMDAw MTM3MyA2NTUzNSBmDQowMDAwMDAxMzc0IDY1NTM1IGYNCjAwMDAwMDEzNzUgNjU1MzUgZg0KMDAw MDAwMTM3NiA2NTUzNSBmDQowMDAwMDAxMzc3IDY1NTM1IGYNCjAwMDAwMDEzNzggNjU1MzUgZg0K MDAwMDAwMTM3OSA2NTUzNSBmDQowMDAwMDAxMzgwIDY1NTM1IGYNCjAwMDAwMDEzODEgNjU1MzUg Zg0KMDAwMDAwMTM4MiA2NTUzNSBmDQowMDAwMDAxMzgzIDY1NTM1IGYNCjAwMDAwMDEzODQgNjU1 MzUgZg0KMDAwMDAwMTM4NSA2NTUzNSBmDQowMDAwMDAxMzg2IDY1NTM1IGYNCjAwMDAwMDEzODcg NjU1MzUgZg0KMDAwMDAwMTM4OCA2NTUzNSBmDQowMDAwMDAxMzg5IDY1NTM1IGYNCjAwMDAwMDEz OTAgNjU1MzUgZg0KMDAwMDAwMTM5MSA2NTUzNSBmDQowMDAwMDAxMzkyIDY1NTM1IGYNCjAwMDAw MDEzOTMgNjU1MzUgZg0KMDAwMDAwMTM5NCA2NTUzNSBmDQowMDAwMDAxMzk1IDY1NTM1IGYNCjAw MDAwMDEzOTYgNjU1MzUgZg0KMDAwMDAwMTM5NyA2NTUzNSBmDQowMDAwMDAxMzk4IDY1NTM1IGYN CjAwMDAwMDEzOTkgNjU1MzUgZg0KMDAwMDAwMTQwMCA2NTUzNSBmDQowMDAwMDAxNDAxIDY1NTM1 IGYNCjAwMDAwMDE0MDIgNjU1MzUgZg0KMDAwMDAwMTQwMyA2NTUzNSBmDQowMDAwMDAxNDA0IDY1 NTM1IGYNCjAwMDAwMDE0MDUgNjU1MzUgZg0KMDAwMDAwMTQwNiA2NTUzNSBmDQowMDAwMDAxNDA3 IDY1NTM1IGYNCjAwMDAwMDE0MDggNjU1MzUgZg0KMDAwMDAwMTQwOSA2NTUzNSBmDQowMDAwMDAx NDEwIDY1NTM1IGYNCjAwMDAwMDE0MTEgNjU1MzUgZg0KMDAwMDAwMTQxMiA2NTUzNSBmDQowMDAw MDAxNDEzIDY1NTM1IGYNCjAwMDAwMDE0MTQgNjU1MzUgZg0KMDAwMDAwMTQxNSA2NTUzNSBmDQow MDAwMDAxNDE2IDY1NTM1IGYNCjAwMDAwMDE0MTcgNjU1MzUgZg0KMDAwMDAwMTQxOCA2NTUzNSBm DQowMDAwMDAxNDE5IDY1NTM1IGYNCjAwMDAwMDE0MjAgNjU1MzUgZg0KMDAwMDAwMTQyMSA2NTUz NSBmDQowMDAwMDAxNDIyIDY1NTM1IGYNCjAwMDAwMDE0MjMgNjU1MzUgZg0KMDAwMDAwMTQyNCA2 NTUzNSBmDQowMDAwMDAxNDI1IDY1NTM1IGYNCjAwMDAwMDE0MjYgNjU1MzUgZg0KMDAwMDAwMTQy NyA2NTUzNSBmDQowMDAwMDAxNDI4IDY1NTM1IGYNCjAwMDAwMDE0MjkgNjU1MzUgZg0KMDAwMDAw MTQzMCA2NTUzNSBmDQowMDAwMDAxNDMxIDY1NTM1IGYNCjAwMDAwMDE0MzIgNjU1MzUgZg0KMDAw MDAwMTQzMyA2NTUzNSBmDQowMDAwMDAxNDM0IDY1NTM1IGYNCjAwMDAwMDE0MzUgNjU1MzUgZg0K MDAwMDAwMTQzNiA2NTUzNSBmDQowMDAwMDAxNDM3IDY1NTM1IGYNCjAwMDAwMDE0MzggNjU1MzUg Zg0KMDAwMDAwMTQzOSA2NTUzNSBmDQowMDAwMDAxNDQwIDY1NTM1IGYNCjAwMDAwMDE0NDEgNjU1 MzUgZg0KMDAwMDAwMTQ0MiA2NTUzNSBmDQowMDAwMDAxNDQzIDY1NTM1IGYNCjAwMDAwMDE0NDQg NjU1MzUgZg0KMDAwMDAwMTQ0NSA2NTUzNSBmDQowMDAwMDAxNDQ2IDY1NTM1IGYNCjAwMDAwMDE0 NDcgNjU1MzUgZg0KMDAwMDAwMTQ0OCA2NTUzNSBmDQowMDAwMDAxNDQ5IDY1NTM1IGYNCjAwMDAw MDE0NTAgNjU1MzUgZg0KMDAwMDAwMTQ1MSA2NTUzNSBmDQowMDAwMDAxNDUyIDY1NTM1IGYNCjAw MDAwMDE0NTMgNjU1MzUgZg0KMDAwMDAwMTQ1NCA2NTUzNSBmDQowMDAwMDAxNDU1IDY1NTM1IGYN CjAwMDAwMDE0NTYgNjU1MzUgZg0KMDAwMDAwMTQ1NyA2NTUzNSBmDQowMDAwMDAxNDU4IDY1NTM1 IGYNCjAwMDAwMDE0NTkgNjU1MzUgZg0KMDAwMDAwMTQ2MCA2NTUzNSBmDQowMDAwMDAxNDYxIDY1 NTM1IGYNCjAwMDAwMDE0NjIgNjU1MzUgZg0KMDAwMDAwMTQ2MyA2NTUzNSBmDQowMDAwMDAxNDY0 IDY1NTM1IGYNCjAwMDAwMDE0NjUgNjU1MzUgZg0KMDAwMDAwMTQ2NiA2NTUzNSBmDQowMDAwMDAx NDY3IDY1NTM1IGYNCjAwMDAwMDE0NjggNjU1MzUgZg0KMDAwMDAwMTQ2OSA2NTUzNSBmDQowMDAw MDAxNDcwIDY1NTM1IGYNCjAwMDAwMDE0NzEgNjU1MzUgZg0KMDAwMDAwMTQ3MiA2NTUzNSBmDQow MDAwMDAxNDczIDY1NTM1IGYNCjAwMDAwMDE0NzQgNjU1MzUgZg0KMDAwMDAwMTQ3NSA2NTUzNSBm DQowMDAwMDAxNDc2IDY1NTM1IGYNCjAwMDAwMDE0NzcgNjU1MzUgZg0KMDAwMDAwMTQ3OCA2NTUz NSBmDQowMDAwMDAxNDc5IDY1NTM1IGYNCjAwMDAwMDE0ODAgNjU1MzUgZg0KMDAwMDAwMTQ4MSA2 NTUzNSBmDQowMDAwMDAxNDgyIDY1NTM1IGYNCjAwMDAwMDE0ODMgNjU1MzUgZg0KMDAwMDAwMTQ4 NCA2NTUzNSBmDQowMDAwMDAxNDg1IDY1NTM1IGYNCjAwMDAwMDE0ODYgNjU1MzUgZg0KMDAwMDAw MTQ4NyA2NTUzNSBmDQowMDAwMDAxNDg4IDY1NTM1IGYNCjAwMDAwMDE0ODkgNjU1MzUgZg0KMDAw MDAwMTQ5MCA2NTUzNSBmDQowMDAwMDAxNDkxIDY1NTM1IGYNCjAwMDAwMDE0OTIgNjU1MzUgZg0K MDAwMDAwMTQ5MyA2NTUzNSBmDQowMDAwMDAxNDk0IDY1NTM1IGYNCjAwMDAwMDE0OTUgNjU1MzUg Zg0KMDAwMDAwMTQ5NiA2NTUzNSBmDQowMDAwMDAxNDk3IDY1NTM1IGYNCjAwMDAwMDE0OTggNjU1 MzUgZg0KMDAwMDAwMTQ5OSA2NTUzNSBmDQowMDAwMDAxNTAwIDY1NTM1IGYNCjAwMDAwMDE1MDEg NjU1MzUgZg0KMDAwMDAwMTUwMiA2NTUzNSBmDQowMDAwMDAxNTAzIDY1NTM1IGYNCjAwMDAwMDE1 MDQgNjU1MzUgZg0KMDAwMDAwMTUwNSA2NTUzNSBmDQowMDAwMDAxNTA2IDY1NTM1IGYNCjAwMDAw MDE1MDcgNjU1MzUgZg0KMDAwMDAwMTUwOCA2NTUzNSBmDQowMDAwMDAxNTA5IDY1NTM1IGYNCjAw MDAwMDE1MTAgNjU1MzUgZg0KMDAwMDAwMTUxMSA2NTUzNSBmDQowMDAwMDAxNTEyIDY1NTM1IGYN CjAwMDAwMDE1MTMgNjU1MzUgZg0KMDAwMDAwMTUxNCA2NTUzNSBmDQowMDAwMDAxNTE1IDY1NTM1 IGYNCjAwMDAwMDE1MTYgNjU1MzUgZg0KMDAwMDAwMTUxNyA2NTUzNSBmDQowMDAwMDAxNTE4IDY1 NTM1IGYNCjAwMDAwMDE1MTkgNjU1MzUgZg0KMDAwMDAwMTUyMCA2NTUzNSBmDQowMDAwMDAxNTIx IDY1NTM1IGYNCjAwMDAwMDE1MjIgNjU1MzUgZg0KMDAwMDAwMTUyMyA2NTUzNSBmDQowMDAwMDAx NTI0IDY1NTM1IGYNCjAwMDAwMDE1MjUgNjU1MzUgZg0KMDAwMDAwMTUyNiA2NTUzNSBmDQowMDAw MDAxNTI3IDY1NTM1IGYNCjAwMDAwMDE1MjggNjU1MzUgZg0KMDAwMDAwMTUyOSA2NTUzNSBmDQow MDAwMDAxNTMwIDY1NTM1IGYNCjAwMDAwMDE1MzEgNjU1MzUgZg0KMDAwMDAwMTUzMiA2NTUzNSBm DQowMDAwMDAxNTMzIDY1NTM1IGYNCjAwMDAwMDE1MzQgNjU1MzUgZg0KMDAwMDAwMTUzNSA2NTUz NSBmDQowMDAwMDAxNTM2IDY1NTM1IGYNCjAwMDAwMDE1MzcgNjU1MzUgZg0KMDAwMDAwMTUzOCA2 NTUzNSBmDQowMDAwMDAxNTM5IDY1NTM1IGYNCjAwMDAwMDE1NDAgNjU1MzUgZg0KMDAwMDAwMTU0 MSA2NTUzNSBmDQowMDAwMDAxNTQyIDY1NTM1IGYNCjAwMDAwMDE1NDMgNjU1MzUgZg0KMDAwMDAw MTU0NCA2NTUzNSBmDQowMDAwMDAxNTQ1IDY1NTM1IGYNCjAwMDAwMDE1NDYgNjU1MzUgZg0KMDAw MDAwMTU0NyA2NTUzNSBmDQowMDAwMDAxNTQ4IDY1NTM1IGYNCjAwMDAwMDE1NDkgNjU1MzUgZg0K MDAwMDAwMTU1MCA2NTUzNSBmDQowMDAwMDAxNTUxIDY1NTM1IGYNCjAwMDAwMDE1NTIgNjU1MzUg Zg0KMDAwMDAwMTU1MyA2NTUzNSBmDQowMDAwMDAxNTU0IDY1NTM1IGYNCjAwMDAwMDE1NTUgNjU1 MzUgZg0KMDAwMDAwMTU1NiA2NTUzNSBmDQowMDAwMDAxNTU3IDY1NTM1IGYNCjAwMDAwMDE1NTgg NjU1MzUgZg0KMDAwMDAwMTU1OSA2NTUzNSBmDQowMDAwMDAxNTYwIDY1NTM1IGYNCjAwMDAwMDE1 NjEgNjU1MzUgZg0KMDAwMDAwMTU2MiA2NTUzNSBmDQowMDAwMDAxNTYzIDY1NTM1IGYNCjAwMDAw MDE1NjQgNjU1MzUgZg0KMDAwMDAwMTU2NSA2NTUzNSBmDQowMDAwMDAxNTY2IDY1NTM1IGYNCjAw MDAwMDE1NjcgNjU1MzUgZg0KMDAwMDAwMTU2OCA2NTUzNSBmDQowMDAwMDAxNTY5IDY1NTM1IGYN CjAwMDAwMDE1NzAgNjU1MzUgZg0KMDAwMDAwMTU3MSA2NTUzNSBmDQowMDAwMDAxNTcyIDY1NTM1 IGYNCjAwMDAwMDE1NzMgNjU1MzUgZg0KMDAwMDAwMTU3NCA2NTUzNSBmDQowMDAwMDAxNTc1IDY1 NTM1IGYNCjAwMDAwMDE1NzYgNjU1MzUgZg0KMDAwMDAwMTU3NyA2NTUzNSBmDQowMDAwMDAxNTc4 IDY1NTM1IGYNCjAwMDAwMDE1NzkgNjU1MzUgZg0KMDAwMDAwMTU4MCA2NTUzNSBmDQowMDAwMDAx NTgxIDY1NTM1IGYNCjAwMDAwMDE1ODIgNjU1MzUgZg0KMDAwMDAwMTU4MyA2NTUzNSBmDQowMDAw MDAxNTg0IDY1NTM1IGYNCjAwMDAwMDE1ODUgNjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBmDQow MDAwMTA3NDY5IDAwMDAwIG4NCjAwMDAxMDc3NzIgMDAwMDAgbg0KMDAwMDE5NzE0MSAwMDAwMCBu DQowMDAwMTk3MzI4IDAwMDAwIG4NCjAwMDAyNzUwMDYgMDAwMDAgbg0KdHJhaWxlcg0KPDwvU2l6 ZSAxNTkxL1Jvb3QgMSAwIFIvSW5mbyA2NyAwIFIvSURbPDMwNkMzNjZEOTM5N0MxNDdCOUIyNTIy QTQ5NDhBRDc0PjwzMDZDMzY2RDkzOTdDMTQ3QjlCMjUyMkE0OTQ4QUQ3ND5dID4+DQpzdGFydHhy ZWYNCjI3ODIzMQ0KJSVFT0YNCnhyZWYNCjAgMA0KdHJhaWxlcg0KPDwvU2l6ZSAxNTkxL1Jvb3Qg MSAwIFIvSW5mbyA2NyAwIFIvSURbPDMwNkMzNjZEOTM5N0MxNDdCOUIyNTIyQTQ5NDhBRDc0Pjwz MDZDMzY2RDkzOTdDMTQ3QjlCMjUyMkE0OTQ4QUQ3ND5dIC9QcmV2IDI3ODIzMS9YUmVmU3RtIDI3 NTAwNj4+DQpzdGFydHhyZWYNCjMxMDIxMw0KJSVFT0Y= ------_=_NextPart_001_01CAC45B.F213E524-- From pal@cs.stanford.edu Mon Mar 15 10:01: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 465863A6A50 for ; Mon, 15 Mar 2010 10:01:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OrPpzzh6TSLB for ; Mon, 15 Mar 2010 10:01:22 -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 9DD043A6BCB for ; Mon, 15 Mar 2010 10:01:00 -0700 (PDT) Received: from dn0a210316.sunet ([10.33.3.22]) by cs-smtp-3.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1NrDf9-00046n-3j; Mon, 15 Mar 2010 10:01:08 -0700 Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Philip Levis In-Reply-To: Date: Mon, 15 Mar 2010 09:08:40 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <8516D84F-92D7-4FC6-BC7B-B434722DEBED@cs.stanford.edu> References: <20100226011704.C9E4D28C140@core3.amsl.com> <6CE3E5D3-DAEE-45E7-9C16-1260BD345A46@cs.stanford.edu> <4B9579EB.6040604@ieee.org> <878wa162qe.fsf@kelsey-ws.hq.ember.com> <4B965F2B.1090206@ieee.org> To: Omprakash Gnawali X-Mailer: Apple Mail (2.1077) X-Scan-Signature: 323acaff36744e8473855e70acc36bcb Cc: "roll@ietf.org" , phoebus@ieee.org Subject: Re: [Roll] Fwd: New Version Notification for draft-levis-roll-trickle-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, 15 Mar 2010 17:01:23 -0000 On Mar 15, 2010, at 1:13 AM, Omprakash Gnawali wrote: > Section 5 of the draft states that Imin should not be used to specify > the minimum interval. I wonder if this makes the intervals too > abstract for RPL implementations. Are the implementations allowed to > hard code the minimum interval? No -- because it is specified in the DIO suboption. Note that these = specifications are only for the *default* values. The draft does *not* = say a protocol has to specify Imin in terms of this parameter. > Will there be a dynamic lookup > mechanism into the link layer or compile time flags to learn about the > worst case latency? If you want a code implementation that is 100% link layer independent, = then there must be some way to specify or compute this value. It could = be an interface the OS provides, a compile-time constant, etc. The basic reason is pretty simple: given the really huge variation in = link layer latencies once you consider low-power link layers, it is a = bad idea for a network protocol to specify time values. Let's take RPL = as an example. If it specifies the default value as 1 second, this could = be too small (for ultra-low power link layers) or too big (for = 802.11abgn). However, if it specifies the default value as a factor of = the link-layer latency (e.g., 4), then the *default* value works across = different link layers. Having time constants in network protocols just doesn't work when you = have the 3+ orders of magnitude range that low-power link layers can = bring. Note that while Imin in a protocol specification is in terms of this = value, this does not mean that protocols must specify it in terms of it. = E.g., it would perfectly fine for a RPL network configuration suboption = to specify a value for Imin in milliseconds. >=20 > It is not clear if Imax should be specified as a function of the worst > case link layer latency. You mean Imin? What should it be specified in terms of? >=20 > "Worst case latency is the time until the first > link-layer transmission of the frame assuming an idle channel > (does not include backoff, virtual carrier sense, etc.). > " >=20 > Does it include preamble, etc.? >=20 > Are we talking about only the function of data rate (transmisstion) ? Jonathan Hui also brought this up. I agree that the current wording is = suboptimal.=20 The basic goal is to have some notion of how long a packet can take. My = original intention was to include preamble and backoff times, but not = congestion or retransmissions. E.g., if the channel is clear and the = packet is delivered successfully, how long could it take? This seemed = like the most useful measure to me, but I could be wrong. Do you think = there's a better one? Phil= From pal@cs.stanford.edu Mon Mar 15 10:01: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 0CBC53A6916; Mon, 15 Mar 2010 10:01:31 -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 BKsRD6sptjnH; Mon, 15 Mar 2010 10:01:30 -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 92C123A69D0; Mon, 15 Mar 2010 10:01:18 -0700 (PDT) Received: from dn0a210316.sunet ([10.33.3.22]) by cs-smtp-3.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1NrDfR-00046n-S7; Mon, 15 Mar 2010 10:01:26 -0700 Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Philip Levis In-Reply-To: <201003151007.05075.henning.rogge@fkie.fraunhofer.de> Date: Mon, 15 Mar 2010 09:18:53 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <9DD3490C-638B-4B03-ACFF-B8B9997FE873@cs.stanford.edu> References: <20100223045634.C3F6328C44F@core3.amsl.com> <06A2C7FF-44F7-4D59-A1E0-1B21F5E99495@unina.it> <201003151007.05075.henning.rogge@fkie.fraunhofer.de> To: Henning Rogge X-Mailer: Apple Mail (2.1077) X-Scan-Signature: 10362da83454c0a30f3f1339bddfed40 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: Mon, 15 Mar 2010 17:01:31 -0000 On Mar 15, 2010, at 2:06 AM, Henning Rogge wrote: > On Mon March 15 2010 06:18:05 Philip Levis wrote: >> Actually, there has been a good deal of work on this topic. >>=20 >> Part of the issue is distinguishing ETX the metric (trying to = estimate the >> number of transmissions) from ETX the algorithm (as per DeCouto et = al.). >> There are algorithms for the metric that use a different names, such = as >> RNP, etc. The basic difference between modern approaches and the = original >> ETX is that they use link-layer acknowledgments from the data path, > If you can access layer 1/2 data this is a good idea. But the code = will become=20 > OS or even hardware specific. Absolutely. But honestly, I'm less worried about the software = engineering of network protocols than their actual efficiency. OSes can = evolve to support new interfaces.=20 This also gets back to my original point: separating the metric and its = computation is valuable. Implementations can use this kind of = information when it's available, but when it's not they can use other = techniques. >=20 >> and EWMA rather than a fixed window size. > EWMA is not always better than a fixed window. In theory, no. In practice, I think it is. By practice, I mean "on = unlicensed ISM bands."=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. Phil= From hrogge@googlemail.com Mon Mar 15 10:15: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 51B2B3A6BC6; Mon, 15 Mar 2010 10:15:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.374 X-Spam-Level: X-Spam-Status: No, score=-2.374 tagged_above=-999 required=5 tests=[AWL=0.225, 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 PeNTipEYHH2w; Mon, 15 Mar 2010 10:15:46 -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 BA3193A6B6A; Mon, 15 Mar 2010 10:14:07 -0700 (PDT) Received: by pwj6 with SMTP id 6so2077172pwj.31 for ; Mon, 15 Mar 2010 10:14:12 -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=3EXrs8mg9+Jh/nUv2hg4d+2lDmvTOeg7ZhAlcFxSekY=; b=KjfemXPuD2AEBN3U0fzdF/hvMElucP6sfq70oz8KY/y+GcPJPnQZnE4U3Tt7H/FXRC P6K/XvK6XxE1Q+MeuMN/l7F1ouERm3kmlOeaqasDf2AAWqz0uRwCD2Vkhmo69Cfm10P5 iagB97Bt0L6qxHzC5Hb1gSJU7TfX23NuAjGzI= 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=YDqu2r6N3mApU80Xtg0kHGsFTomwo6zFF2g40apCmXNzgY7Uon/cruEscQMg/sMkBQ UUyseLiM+mTqZtURdT7o+b+IOqRf0VvvV/G/UtuccU9HzZ1mYQSAc6evJsUUaoVGq/8E TZdmjPksfB2C3bHzjGMjicoghEKBvocdx/n7s= Received: by 10.141.53.14 with SMTP id f14mr6073483rvk.266.1268673252351; Mon, 15 Mar 2010 10:14:12 -0700 (PDT) Received: from core2.localnet (static-87-79-93-195.netcologne.de [87.79.93.195]) by mx.google.com with ESMTPS id 31sm566089pxi.3.2010.03.15.10.14.10 (version=SSLv3 cipher=RC4-MD5); Mon, 15 Mar 2010 10:14:11 -0700 (PDT) From: Henning Rogge To: roll@ietf.org Date: Mon, 15 Mar 2010 18:14:03 +0100 User-Agent: KMail/1.13.1 (Linux/2.6.33-gentoo; KDE/4.4.1; x86_64; ; ) References: <20100223045634.C3F6328C44F@core3.amsl.com> <201003151007.05075.henning.rogge@fkie.fraunhofer.de> <9DD3490C-638B-4B03-ACFF-B8B9997FE873@cs.stanford.edu> In-Reply-To: <9DD3490C-638B-4B03-ACFF-B8B9997FE873@cs.stanford.edu> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1390973.ZWQzcPnDJ5"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <201003151814.08275.hrogge@googlemail.com> 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: Mon, 15 Mar 2010 17:15:47 -0000 --nextPart1390973.ZWQzcPnDJ5 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Am Montag 15 M=E4rz 2010 17:18:53 schrieb Philip Levis: > > If you can access layer 1/2 data this is a good idea. But the code will > > become OS or even hardware specific. >=20 > Absolutely. But honestly, I'm less worried about the software engineering > of network protocols than their actual efficiency. OSes can evolve to > support new interfaces. We should worry about both. If we ignore the software side of the problem w= e=20 might design stuff that does not run on most platforms.=20 > This also gets back to my original point: separating the metric and its > computation is valuable. Implementations can use this kind of information > when it's available, but when it's not they can use other techniques. > > >> and EWMA rather than a fixed window size. > >=20 > > EWMA is not always better than a fixed window. >=20 > In theory, no. In practice, I think it is. By practice, I mean "on > unlicensed ISM bands." We have experimented with EWMA based in the Freifunk networks (IEEE 802.11= =20 based meshs), and we had better experience with the fixed window than the=20 EWMA. EWMA is more difficult to adapt to events that don't occur on a regul= ar=20 interval. =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. You don't want your LQ value change quicker than you can transport it to th= e=20 network. That can be a desaster (depending on protocol and network topology= ). Henning Rogge --nextPart1390973.ZWQzcPnDJ5 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) iEYEABECAAYFAkueauAACgkQcenvcwAcHWeeZQCfQOPOzPD9QF2zj6wWly0zQDFz mNAAn1fA4asMFdtyt6i9UqoVVCa6wQVA =QorM -----END PGP SIGNATURE----- --nextPart1390973.ZWQzcPnDJ5-- From d.sturek@att.net Mon Mar 15 10:34: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 7ED523A6972 for ; Mon, 15 Mar 2010 10:34:55 -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_50=0.001, 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 JmfcNjjLUSjo for ; Mon, 15 Mar 2010 10:34:39 -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 89CF03A69CC for ; Mon, 15 Mar 2010 10:33:20 -0700 (PDT) Received: (qmail 13261 invoked from network); 15 Mar 2010 17:33:26 -0000 Received: from adsl-69-224-191-23.dsl.sndg02.pacbell.net (d.sturek@69.224.191.23 with login) by smtp126.sbc.mail.sp1.yahoo.com with SMTP; 15 Mar 2010 10:33:25 -0700 PDT X-Yahoo-SMTP: fvjol_aswBAraSJvMLe2r1XTzhBhbFxY8q8c3jo- X-YMail-OSG: G83RQoMVM1neigu2_lSCDm0epLhlKB_HSZsdFpt9PHO1I83np1ro8ppjKhg2ktvFwkmVAcAmFwjnUewfgpnuyUIzcfccP5dwOT._LCvKsyPA4YuEfnxkcdVCr_eJnpWEQZwQIRRslt178C1Qlh6IfLGAWCWaJyx3UnO7xS4rDeA8IqY9AdZct1G3vE64WLKVDPrV4NxwRPegt1dLOhqQUM0sPNss7FFMi4T_e_e2_q3UbfLUlpTSCCR66y5paHWNdkVPL81kkjBRO5VHHKTcCzyb8BIX7xdjHZ7MY7hxMlNw7uj1fm4- X-Yahoo-Newman-Property: ymail-3 From: "Don Sturek" To: "'Pascal Thubert \(pthubert\)'" , , References: <6D9687E95918C04A8B30A7D6DA805A3E01429F5F@zensys17.zensys.local> <4B9553B8.6010001@eecs.berkeley.edu> <4B98F374.4030301@gridmerge.com> <6A2A459175DABE4BB11DE2026AA50A5D0170DFA9@XMB-AMS-107.cisco.com> In-Reply-To: <6A2A459175DABE4BB11DE2026AA50A5D0170DFA9@XMB-AMS-107.cisco.com> Date: Mon, 15 Mar 2010 10:33:20 -0700 Message-ID: <01ad01cac465$9bb9da70$d32d8f50$@sturek@att.net> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_01AE_01CAC42A.EF5B0270" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcrBIO0mcBW5di9DSESfrbyVRyBbFwDOfAKwAAIhgwA= Content-Language: en-us Cc: 'ROLL WG' Subject: Re: [Roll] P2P performance with current RPL proposal 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, 15 Mar 2010 17:34:55 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_01AE_01CAC42A.EF5B0270 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Pascal, I think we have fundamental disagreement on P2P support in RPL. Here are the issues that I see: 1) "We are considering a limited set of P2P pairs" - I think most of the use cases for Building Automation and Home Automation use P2P pairs. Even Smart Energy is mostly a P2P solution (as a percentage of messages sent/received). I think to handle P2P we need to view the deployment as NOT being a limited set of P2P pairs. 2) "for which the specific path that we need to create might have to obey specific constraints." - I think there was discussion on having application server type devices (like lamps for example) become DAG roots to help solve the mapping of RPL to P2P solutions. This really won't work. Aligning the network topology by moving application devices to the role of DAG roots won't scale. Don From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Pascal Thubert (pthubert) Sent: Monday, March 15, 2010 9:24 AM To: robert.cragie@gridmerge.com; Ted.Humpal@jci.com Cc: ROLL WG Subject: Re: [Roll] P2P performance with current RPL proposal HI Robert : I respectfully have to disagree. My understanding is that we are considering a limited set of P2P pairs, for which the specific path that we need to create might have to obey specific constraints. So it makes sense to use an on-demand technique, probably inspired by the MANET Reactive protocols. As it goes, those protocols usually use flooding for a node to locate another. Forking a DAG is just another flooding. It does not take a lot of addition to the existing DIO for a root to use RPL to build a DAG that contains one or multiple Targets as leaves, under a set of constraints expressed as an objective function. Please find attached a slideware that illustrates that. Pascal From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Robert Cragie Sent: Thursday, March 11, 2010 2:43 PM To: Ted.Humpal@jci.com Cc: ROLL WG Subject: Re: [Roll] P2P performance with current RPL proposal I agree with Ted's comments below. Creating a DODAG for every reachable node as a root seems a very inefficient approach compared to alternative routing algorithms. I am concerned that RPL does not actually meet the original requirements in I-D.ietf-roll-building-routing-reqs, I-D.ietf-roll-home-routing-reqs, RFC5673 and RFC5548. The traffic pattern requirement for a sink node features prominently in only two of those documents. Even in this case, as Ted points out, communication is likely to be bidirectional (e.g. end-to-end acks.) therefore the DODAG approach is fundamentally asymmetric, especially if no intermediate storage is allowed for destination routes and source routing has to be used. Also, RPL seems highly complex for what are constrained nodes in terms of memory as well as power and bandwidth. The RPL draft as it stands is 82 pages long and that doesn't include text about the objective function. Robert Robert Cragie (Pacific Gas & Electric) Gridmerge Ltd. 89 Greenfield Crescent, Wakefield, WF4 4WA, UK +44 (0) 1924 910888 http://www.gridmerge.com Ted.Humpal@jci.com wrote: A concern also will be how much overhead (memory space) will be required for a DODAG Root? and based on the first question how many DODAG roots a lamp may need to be a member of? For example in lighting a single lamp may be a root for a single switch (1 DODAG root), this lamp / luminaire may also be a member of another group - - which could be all lights on the floor (2nd DODAG root), and a third group of all the lights in the building. There can be many more speciality groups associated based on the building configuration. Consider also during the installation time - how these DODAG roots will be configured? Must I commission each device to tell it which DODAG it must use for its Object Function? How easy will this be to change and add in a new DODAG root for the end user if the lighting group changes?? With respect to Jerry Martocci's - commercial building requirements - every device may need to communicate to any or all of the end devices. If each device must establish a DODAG for the other 499 devices in a 500 node network - How much memory space will this require for each end device to maintain? Keep in mind that the end devices are very limited processor and memory wise. Not to mention all of the network maintenance messages that would need to be transmitted to maintain all of these DODAGs. Consider the reconvergence time when one device is turned off and it was in the middle of the majority of the 100+ DODAGS? In many lighting and building application an application acknowledgement - must be returned {Back down the DODAG} so . . . the requirement is not just getting to the Root - a return path must also be maintained and have a low latency path. Ted Humpal From: Kris Pister To: Anders Brandt Cc: ROLL WG Date: 03/08/2010 01:45 PM Subject: Re: [Roll] P2P performance with current RPL proposal _____ Anders - if we take JP's suggestion to make The Lamp a DODAG root, and take Phoebus' recommendation that we use path diversity to improve end-to-end reliability, do you see a chance of success? In my experience, with diverse paths and order-minutes updates you get extremely high reliability. I have no aversion to TTL-limited floods as a part of a solution either. I'm open to ideas on how to bring those in as (presumably infrequently used) options. ksjp Anders Brandt wrote: Hello I would like to probe the temperature of the WG on using DAOs to support P2P. The building and home application spaces (and maybe others) have a few clearly defined requirements. It is not obvious to me how the current RPL proposal (cRPLp) can satisfy those requirements: In both cases it is the worst case scenario that hurts: P2P routing inside the PAN ========================== cRPLp has no way of routing inside the PAN if you need more than one repeater. cRPLp has to go all the way to the top (maybe 4 hops up) and down again (maybe 4 hops down) to get just 2 hops to the side. The consequence is high latency and high levels of background noise for nodes just outside the direct radio range. At the same time the risk of meeting a failing link is 4 times higher => latency may be much more than 4 times larger. Latency may sound like a minor issue but it actually translates directly into lower battery lifetime. In the above (very realistic) example, the battery lifetime is reduced to 25% of what it should be. We have lots of battery devices sending into the network: * PIR sensors turning on lights * Door locks sending alarms * Door/window sensors starting chimes * Smoke sensors triggering an alarm system Response time ============= The latency issue is important. When a user (real human being) presses a light button the user expects the light to turn on. cRPLp proposes that nodes in the tree periodically advertises their presence using DAOs. The periodicity is a real beast: Thanks to Trickle, the rate of updates in a (apparently) stable network is low. This is good since it leaves bandwidth for data. But it is not good if existing routes to my lamp fail and I do not get new routes to my lamp until it decides to send out a new DAO. My user will (with a good reason) not tolerate waiting for minutes for the light to turn on. I have met two arguments to counter this concern: A1: Well, your lamp can always send a DAO when it detects a problem. My answer: True, except that my lamp does not intend to send anything so it will never experience any problems from its side of the network. A2: Well, you can increase the DAO rate to sub-second updates. My answer: Oh no. I get a very high degree of management traffic which limits my available bandwidth, increases the risk of collisions and even run the risk of violating EU legislation requiring me to only transmit in less than 1% of the time: http://focus.ti.com/lit/an/swra048/swra048.pdf 868 - 868.6 MHz: <1% Reactiveness is hard to achieve via polling. If you agree that this seems to be critical issues please raise your voice on the list. Going forward ============= We need some reactive mechanism to reach lamps before the user decides to sue our companies. So is this possible? I think so. Existing commercial (non-IP) solutions are capable of re-routing quickly if they really have to. Let me try scoping the requirements to a potential solution: (no different from the req. docs for home and building) * P2P routing in any direction independent of the tree. * On-demand P2P route discovery if requested by a real-time critical app. Data collection apps may be able to just wait for the next DAO update. * Limited range of discovery mechanism: max 4 repeaters. A TTL field may limit the scope of the repeaters. * Suboptimal routing and traffic bursts are accepted in exchange for quick route repair. But only as an exception. Just as an example, one existing home control technology uses a (source routing) variant of AODV for quick route repair. Nothing comes for free. The price is flooding - but not just flooding: Managed flooding using a distributed algorithm running in all participating nodes. The algorithm dampens the flooding in a time, volume and range perspective. Some similar mechanism could be built into RPL for quick route repair. If anyone have alternative proposals, please bring it to the list. Now is the time. Thanks, Anders _____ _______________________________________________ Roll mailing 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_01AE_01CAC42A.EF5B0270 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Pascal,

 

I think we have fundamental disagreement on P2P support = in RPL.  Here are the issues that I see:

1)       “We are considering a limited set of = P2P pairs” – I think most of the use cases for Building = Automation and Home Automation use P2P pairs.  Even Smart Energy is mostly a P2P = solution (as a percentage of messages sent/received).  I think to handle P2P = we need to view the deployment as NOT being a limited set of P2P = pairs.

2)       “for which the specific path that we need to = create might have to obey specific constraints.” – I think there = was discussion on having application server type devices (like lamps for = example) become DAG roots to help solve the mapping of RPL to P2P = solutions.  This really won’t work.  Aligning the network topology by moving = application devices to the role of DAG roots won’t scale.

Don

 

From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Pascal Thubert = (pthubert)
Sent: Monday, March 15, 2010 9:24 AM
To: robert.cragie@gridmerge.com; Ted.Humpal@jci.com
Cc: ROLL WG
Subject: Re: [Roll] P2P performance with current RPL = proposal

 

HI Robert :

 

I respectfully have to disagree.

 

My understanding is that we are considering a limited set = of P2P pairs, for which the specific path that we need to create might have to = obey specific constraints.

So it makes sense to use an on-demand technique, probably inspired by the MANET Reactive protocols.

 

As it goes, those protocols usually use flooding for a = node to locate another. Forking a DAG is just another flooding. It does not take = a lot of addition to the existing DIO for a root to use RPL to build a DAG = that contains one or multiple Targets as leaves, under a set of constraints expressed as an objective function. Please find attached a slideware = that illustrates that.

 

Pascal

 

From: = roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Robert Cragie
Sent: Thursday, March 11, 2010 2:43 PM
To: Ted.Humpal@jci.com
Cc: ROLL WG
Subject: Re: [Roll] P2P performance with current RPL = proposal

 

I agree with Ted's comments below. Creating a DODAG for every reachable = node as a root seems a very inefficient approach compared to alternative routing algorithms. I am concerned that RPL does not actually meet the original requirements in I-D.ietf-roll-building-routing-reqs, I-D.ietf-roll-home-routing-reqs, RFC5673 and RFC5548. The traffic = pattern requirement for a sink node features prominently in only two of those documents. Even in this case, as Ted points out, communication is likely = to be bidirectional (e.g. end-to-end acks.) therefore the DODAG approach is fundamentally asymmetric, especially if no intermediate storage is = allowed for destination routes and source routing has to be used.

Also, RPL seems highly complex for what are constrained nodes in terms = of memory as well as power and bandwidth. The RPL draft as it stands is 82 = pages long and that doesn't include text about the objective function.

Robert

Robert Cragie (Pacific Gas & = Electric)

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



Ted.Humpal@jci.com wrote: =


A concern also will be how much overhead (memory space) will be required = for a DODAG Root?

and based on the first question how many DODAG roots a lamp may need to be a = member of?

For example in lighting  a single lamp may be a root for a single = switch (1 DODAG root),  this lamp / luminaire may also =
be a member of another group - -  which could be all lights on the = floor (2nd DODAG root), and a third group
of all the lights in the building.  There can be many more speciality = groups associated based on the building configuration. =
Consider also during the installation time - how these DODAG roots will be = configured?  Must I commission each device
to tell it which DODAG it must use for its Object Function?  How easy = will this be to change and add in a new DODAG root =
for the end user if the lighting group changes??

With respect to Jerry Martocci's - commercial building requirements - every = device may need to communicate to any or
all of the end devices.  If each device must establish a DODAG for the = other 499 devices in a 500 node network - How much memory
space will this require for each end device to maintain?  

Keep in mind that the end devices are very limited processor and memory = wise.

Not to mention all of the network maintenance messages that would need to be transmitted to maintain all of these DODAGs.

Consider the reconvergence time when one device is turned off and it was in the = middle of the majority of the 100+ DODAGS?

In many lighting and building application an application acknowledgement - = must be returned {Back down the DODAG} so . . . the
requirement is not just getting to the Root - a return path must also be maintained = and have a  low latency path.

Ted Humpal


From:

Kris Pister <pister@eecs.berkeley.edu>=

To:

Anders Brandt <abr@sdesigns.dk> =

Cc:

ROLL WG <roll@ietf.org> =

Date:

03/08/2010 01:45 PM

Subject:

Re: [Roll] P2P performance with current RPL proposal

 




Anders - if we take JP's suggestion to make The Lamp a DODAG root, and = take Phoebus' recommendation that we use path diversity to improve end-to-end reliability, do you see a chance of success?
In my experience, with diverse paths and order-minutes updates you get extremely high reliability.

I have no aversion to TTL-limited floods as a part of a solution either.  I'm open to ideas on how to bring those in as (presumably = infrequently used) options.

ksjp

Anders Brandt wrote:
Hello
 
I = would like to probe the temperature of the WG on using DAOs to
support P2P.
 
The = building and home application spaces (and maybe others) have
a = few clearly defined requirements.
It = is not obvious to me how the current RPL proposal (cRPLp) can
satisfy those requirements:
 
 
In = both cases it is the worst case scenario that hurts:
 
 
P2P = routing inside the PAN
=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
cRPLp has no way of routing inside the PAN if you need more than
one = repeater. cRPLp has to go all the way to the top (maybe 4 hops up)
and = down again (maybe 4 hops down) to get just 2 hops to the side.
 
The consequence is high latency and high levels of background noise
for nodes just outside the direct radio range. =
At = the same time the risk of meeting a failing link is 4 times higher = =3D>
latency may be much more than 4 times larger.
 
Latency may sound like a minor issue but it actually translates directly
into lower battery lifetime. In the above (very realistic) = example,
the = battery lifetime is reduced to 25% of what it should be. =
 
We = have lots of battery devices sending into the network:
* = PIR sensors turning on lights
* = Door locks sending alarms
* = Door/window sensors starting chimes
* = Smoke sensors triggering an alarm system
 
 
 
 
Response time
=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D
The = latency issue is important.
When a user (real human being) presses a light button the user expects
the = light to turn on.
cRPLp proposes that nodes in the tree periodically advertises their
presence using DAOs.
The periodicity is a real beast:
Thanks to Trickle, the rate of updates in a (apparently) stable network
is low. This is good since it leaves bandwidth for data.
But = it is not good if existing routes to my lamp fail and I do not get
new = routes to my lamp until it decides to send out a new DAO. =
My = user will (with a good reason) not tolerate waiting for minutes for
the = light to turn on.
 
I = have met two arguments to counter this concern:
 
A1: = Well, your lamp can always send a DAO when it detects a problem.
  My answer:
  True, except that my lamp does not intend to send anything
  so it will never experience any problems from its side of the = network.
 
A2: = Well, you can increase the DAO rate to sub-second updates. =
  My answer:
  Oh no. I get a very high degree = of management traffic which
  limits my available bandwidth, increases the risk of collisions and
  even run the risk of violating EU legislation requiring me to = only
  transmit in less than 1% of the time:
  http://focus.ti.com/lit/an/= swra048/swra048.pdf
 868 - 868.6 MHz: <1%
 
  Reactiveness is hard to achieve via polling.
 
 
 
If = you agree that this seems to be critical issues please raise your
voice on the list.
 
Going forward
=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D
 
We = need some reactive mechanism to reach lamps before the user decides
to = sue our companies.
So = is this possible? I think so.

Existing commercial (non-IP) solutions are capable of re-routing = quickly
if = they really have to.
 
Let = me try scoping the requirements to a potential solution: =
(no = different from the req. docs for home and building)
 
* = P2P routing in any direction independent of the tree.
 
* = On-demand P2P route discovery if requested by a real-time critical app.
 Data collection apps may be able to just wait for the next DAO = update.
 
* = Limited range of discovery mechanism: max 4 repeaters. =
  A TTL field may limit the scope of the repeaters.
 
* = Suboptimal routing and traffic bursts are accepted in exchange
  for quick route repair. But only as an exception. =
 
 
Just as an example, one existing home control technology uses a
(source routing) variant of AODV for quick route repair.
Nothing comes for free. The price is flooding - but not just flooding:
Managed flooding using a distributed algorithm running in all
participating nodes.
The = algorithm dampens the flooding in a time, volume and range perspective. =
Some similar mechanism could be built into RPL for quick route repair.
 
 
If = anyone have alternative proposals, please bring it to the list.
Now = is the time.
 
 
 
Thanks,
  Anders


______________________________________________= _
Roll mailing = 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_01AE_01CAC42A.EF5B0270-- From pthubert@cisco.com Mon Mar 15 10:55: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 17E893A69E9 for ; Mon, 15 Mar 2010 10:55:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.747 X-Spam-Level: X-Spam-Status: No, score=-3.747 tagged_above=-999 required=5 tests=[AWL=-3.749, 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 sRmxHvNwHT7i for ; Mon, 15 Mar 2010 10:55:18 -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 355843A6A0A for ; Mon, 15 Mar 2010 10:55:13 -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: AiABAI8RnkuQ/uCWe2dsb2JhbACBRJkuFQEBCwskBhyhfZd8hHsE X-IronPort-AV: E=Sophos;i="4.49,644,1262563200"; d="scan'208,217";a="4362205" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-2.cisco.com with ESMTP; 15 Mar 2010 17:21: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 o2FHtIlX007360; Mon, 15 Mar 2010 17:55: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, 15 Mar 2010 18:55:18 +0100 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_01CAC468.AC93C314" Date: Mon, 15 Mar 2010 18:55:13 +0100 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D0170E03D@XMB-AMS-107.cisco.com> In-Reply-To: <01ad01cac465$9bb9da70$d32d8f50$@sturek@att.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] P2P performance with current RPL proposal Thread-Index: AcrBIO0mcBW5di9DSESfrbyVRyBbFwDOfAKwAAIhgwAAAJmCYA== References: <6D9687E95918C04A8B30A7D6DA805A3E01429F5F@zensys17.zensys.local> <4B9553B8.6010001@eecs.berkeley.edu> <4B98F374.4030301@gridmerge.com> <6A2A459175DABE4BB11DE2026AA50A5D0170DFA9@XMB-AMS-107.cisco.com> <01ad01cac465$9bb9da70$d32d8f50$@sturek@att.net> From: "Pascal Thubert (pthubert)" To: , , X-OriginalArrivalTime: 15 Mar 2010 17:55:18.0892 (UTC) FILETIME=[ACD762C0:01CAC468] Cc: ROLL WG Subject: Re: [Roll] P2P performance with current RPL proposal X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Mar 2010 17:55:34 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CAC468.AC93C314 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Don : =20 Well, in both cases my words did not convey the message I wished to convey. =20 1) I mean that the nodes that need to do P2P need to do so with a limited set of other nodes, as opposed to all other nodes in the network. So what you want to do is not any to any but a number of groups of 2 or more nodes that need to talk to one another 2) I mean that the path that we create might have to obey constraints, like low latency, that the generic P2MP DAG does not need. For instance, I think about a closed loop in process control. =20 I'm not sure we disagree so far. =20 I read your earlier mail about application role vs. network role. In that, we might have to discuss some more. Because RPL is designed to optimize P2MP and MP2P, it is not symmetrical wrt the P and the MP. The P has to be selected to match the Goal that the DAG is built to serve. =20 Taking your example, one way of handling multiple lamps in a room can be to set them all as roots , and then coordinate them, for instance through the powerline, as discussed in section 3.2. =20 Our we could use the on-demand approach that I just suggested. For instance, we could have each switch lookup the set of lamps by forking a DAG. With the proposal, the DAG only spans so far, and acts as a reactive route setup. The DIO contains the list of lamps, and each lamp answers with a DAO that can be fanned out. The nodes that do not see the DAO back forget about that DAG just like they would other reactive floodings. =20 How far do we really disagree? =20 Pascal =20 From: Don Sturek [mailto:d.sturek@att.net]=20 Sent: Monday, March 15, 2010 6:33 PM To: Pascal Thubert (pthubert); robert.cragie@gridmerge.com; Ted.Humpal@jci.com Cc: 'ROLL WG' Subject: RE: [Roll] P2P performance with current RPL proposal =20 Hi Pascal, =20 I think we have fundamental disagreement on P2P support in RPL. Here are the issues that I see: 1) "We are considering a limited set of P2P pairs" - I think most of the use cases for Building Automation and Home Automation use P2P pairs. Even Smart Energy is mostly a P2P solution (as a percentage of messages sent/received). I think to handle P2P we need to view the deployment as NOT being a limited set of P2P pairs. 2) "for which the specific path that we need to create might have to obey specific constraints." - I think there was discussion on having application server type devices (like lamps for example) become DAG roots to help solve the mapping of RPL to P2P solutions. This really won't work. Aligning the network topology by moving application devices to the role of DAG roots won't scale. Don =20 From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Pascal Thubert (pthubert) Sent: Monday, March 15, 2010 9:24 AM To: robert.cragie@gridmerge.com; Ted.Humpal@jci.com Cc: ROLL WG Subject: Re: [Roll] P2P performance with current RPL proposal =20 HI Robert : =20 I respectfully have to disagree. =20 My understanding is that we are considering a limited set of P2P pairs, for which the specific path that we need to create might have to obey specific constraints.=20 So it makes sense to use an on-demand technique, probably inspired by the MANET Reactive protocols. =20 As it goes, those protocols usually use flooding for a node to locate another. Forking a DAG is just another flooding. It does not take a lot of addition to the existing DIO for a root to use RPL to build a DAG that contains one or multiple Targets as leaves, under a set of constraints expressed as an objective function. Please find attached a slideware that illustrates that. =20 Pascal =20 From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Robert Cragie Sent: Thursday, March 11, 2010 2:43 PM To: Ted.Humpal@jci.com Cc: ROLL WG Subject: Re: [Roll] P2P performance with current RPL proposal =20 I agree with Ted's comments below. Creating a DODAG for every reachable node as a root seems a very inefficient approach compared to alternative routing algorithms. I am concerned that RPL does not actually meet the original requirements in I-D.ietf-roll-building-routing-reqs, I-D.ietf-roll-home-routing-reqs, RFC5673 and RFC5548. The traffic pattern requirement for a sink node features prominently in only two of those documents. Even in this case, as Ted points out, communication is likely to be bidirectional (e.g. end-to-end acks.) therefore the DODAG approach is fundamentally asymmetric, especially if no intermediate storage is allowed for destination routes and source routing has to be used. Also, RPL seems highly complex for what are constrained nodes in terms of memory as well as power and bandwidth. The RPL draft as it stands is 82 pages long and that doesn't include text about the objective function. Robert Robert Cragie (Pacific Gas & Electric) Gridmerge Ltd. 89 Greenfield Crescent, Wakefield, WF4 4WA, UK +44 (0) 1924 910888 http://www.gridmerge.com =20 Ted.Humpal@jci.com wrote:=20 A concern also will be how much overhead (memory space) will be required for a DODAG Root?=20 and based on the first question how many DODAG roots a lamp may need to be a member of?=20 For example in lighting a single lamp may be a root for a single switch (1 DODAG root), this lamp / luminaire may also=20 be a member of another group - - which could be all lights on the floor (2nd DODAG root), and a third group=20 of all the lights in the building. There can be many more speciality groups associated based on the building configuration.=20 Consider also during the installation time - how these DODAG roots will be configured? Must I commission each device=20 to tell it which DODAG it must use for its Object Function? How easy will this be to change and add in a new DODAG root=20 for the end user if the lighting group changes??=20 With respect to Jerry Martocci's - commercial building requirements - every device may need to communicate to any or=20 all of the end devices. If each device must establish a DODAG for the other 499 devices in a 500 node network - How much memory=20 space will this require for each end device to maintain? =20 Keep in mind that the end devices are very limited processor and memory wise.=20 Not to mention all of the network maintenance messages that would need to be transmitted to maintain all of these DODAGs.=20 Consider the reconvergence time when one device is turned off and it was in the middle of the majority of the 100+ DODAGS?=20 In many lighting and building application an application acknowledgement - must be returned {Back down the DODAG} so . . . the=20 requirement is not just getting to the Root - a return path must also be maintained and have a low latency path.=20 Ted Humpal=20 From:=20 Kris Pister To:=20 Anders Brandt =20 Cc:=20 ROLL WG =20 Date:=20 03/08/2010 01:45 PM=20 Subject:=20 Re: [Roll] P2P performance with current RPL proposal =20 ________________________________ Anders - if we take JP's suggestion to make The Lamp a DODAG root, and take Phoebus' recommendation that we use path diversity to improve end-to-end reliability, do you see a chance of success? In my experience, with diverse paths and order-minutes updates you get extremely high reliability. I have no aversion to TTL-limited floods as a part of a solution either. I'm open to ideas on how to bring those in as (presumably infrequently used) options. ksjp Anders Brandt wrote:=20 Hello=20 =20 I would like to probe the temperature of the WG on using DAOs to=20 support P2P.=20 =20 The building and home application spaces (and maybe others) have=20 a few clearly defined requirements.=20 It is not obvious to me how the current RPL proposal (cRPLp) can=20 satisfy those requirements:=20 =20 =20 In both cases it is the worst case scenario that hurts:=20 =20 =20 P2P routing inside the PAN=20 =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=20 cRPLp has no way of routing inside the PAN if you need more than=20 one repeater. cRPLp has to go all the way to the top (maybe 4 hops up)=20 and down again (maybe 4 hops down) to get just 2 hops to the side.=20 =20 The consequence is high latency and high levels of background noise for nodes just outside the direct radio range.=20 At the same time the risk of meeting a failing link is 4 times higher = =3D> latency may be much more than 4 times larger.=20 =20 Latency may sound like a minor issue but it actually translates directly into lower battery lifetime. In the above (very realistic) example,=20 the battery lifetime is reduced to 25% of what it should be.=20 =20 We have lots of battery devices sending into the network:=20 * PIR sensors turning on lights=20 * Door locks sending alarms=20 * Door/window sensors starting chimes=20 * Smoke sensors triggering an alarm system=20 =20 =20 =20 =20 Response time=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=20 The latency issue is important.=20 When a user (real human being) presses a light button the user expects=20 the light to turn on.=20 cRPLp proposes that nodes in the tree periodically advertises their=20 presence using DAOs.=20 The periodicity is a real beast:=20 Thanks to Trickle, the rate of updates in a (apparently) stable network is low. This is good since it leaves bandwidth for data.=20 But it is not good if existing routes to my lamp fail and I do not get=20 new routes to my lamp until it decides to send out a new DAO.=20 My user will (with a good reason) not tolerate waiting for minutes for=20 the light to turn on.=20 =20 I have met two arguments to counter this concern:=20 =20 A1: Well, your lamp can always send a DAO when it detects a problem.=20 My answer:=20 True, except that my lamp does not intend to send anything=20 so it will never experience any problems from its side of the network. =20 A2: Well, you can increase the DAO rate to sub-second updates.=20 My answer:=20 Oh no. I get a very high degree of management traffic which=20 limits my available bandwidth, increases the risk of collisions and=20 even run the risk of violating EU legislation requiring me to only=20 transmit in less than 1% of the time:=20 http://focus.ti.com/lit/an/swra048/swra048.pdf =20 868 - 868.6 MHz: <1%=20 =20 Reactiveness is hard to achieve via polling.=20 =20 =20 =20 If you agree that this seems to be critical issues please raise your=20 voice on the list.=20 =20 Going forward=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=20 =20 We need some reactive mechanism to reach lamps before the user decides=20 to sue our companies.=20 So is this possible? I think so.=20 Existing commercial (non-IP) solutions are capable of re-routing quickly if they really have to.=20 =20 Let me try scoping the requirements to a potential solution:=20 (no different from the req. docs for home and building)=20 =20 * P2P routing in any direction independent of the tree.=20 =20 * On-demand P2P route discovery if requested by a real-time critical app. Data collection apps may be able to just wait for the next DAO update.=20 =20 * Limited range of discovery mechanism: max 4 repeaters.=20 A TTL field may limit the scope of the repeaters.=20 =20 * Suboptimal routing and traffic bursts are accepted in exchange=20 for quick route repair. But only as an exception.=20 =20 =20 Just as an example, one existing home control technology uses a (source routing) variant of AODV for quick route repair.=20 Nothing comes for free. The price is flooding - but not just flooding: Managed flooding using a distributed algorithm running in all participating nodes.=20 The algorithm dampens the flooding in a time, volume and range perspective.=20 Some similar mechanism could be built into RPL for quick route repair.=20 =20 =20 If anyone have alternative proposals, please bring it to the list.=20 Now is the time.=20 =20 =20 =20 Thanks,=20 Anders=20 ________________________________ _______________________________________________ Roll mailing list Roll@ietf.org =20 https://www.ietf.org/mailman/listinfo/roll =20 _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll =20 =20 =20 =20 ________________________________ =20 =20 =20 _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll =20 ------_=_NextPart_001_01CAC468.AC93C314 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Don :

 

Well, in both cases my words did not convey the message I wished to = convey.

 

1)      = I mean that the nodes that need to do P2P need to do so with a = limited set of other nodes, as opposed to all other nodes in the = network. So what you want to do is not any to any but  a number of = groups of 2 or more nodes that need to talk to one = another

2)      = I  mean that the path that we create might have to obey = constraints, like low latency, that the generic P2MP DAG does not need. = For instance, I think about a closed loop in process = control.

 

I’m not sure we disagree so far.

 

I read your earlier mail about application role vs. network role. In = that, we might have to discuss some more. Because RPL is designed to = optimize P2MP and MP2P, it is not symmetrical wrt the P and the MP. The = P has to be selected to match the Goal that the DAG is built to = serve.

 

Taking your example, one way of handling multiple lamps in a room can = be to set them all as roots , and then coordinate them, for instance = through the powerline, as discussed in section = 3.2.

 

Our we could use the on-demand approach that I just suggested. For = instance, we could have each switch lookup the set of lamps by forking a = DAG. With the proposal, the DAG only spans so far, and acts as a = reactive route setup. The DIO contains the list of lamps, and each lamp = answers with a DAO that can be fanned out. The nodes that do not see the = DAO back forget about that DAG just like they would other reactive = floodings.

 

How far do we really disagree?

 

Pascal

 

From: Don Sturek [mailto:d.sturek@att.net]
Sent: Monday, = March 15, 2010 6:33 PM
To: Pascal Thubert (pthubert); = robert.cragie@gridmerge.com; Ted.Humpal@jci.com
Cc: 'ROLL = WG'
Subject: RE: [Roll] P2P performance with current RPL = proposal

 

Hi Pascal,

 

I think we have fundamental disagreement on P2P support in RPL.  = Here are the issues that I see:

1)      =  “We are considering a limited set of P2P pairs” = – I think most of the use cases for Building Automation and Home = Automation use P2P pairs.  Even Smart Energy is mostly a P2P = solution (as a percentage of messages sent/received).  I think to = handle P2P we need to view the deployment as NOT being a limited set of = P2P pairs.

2)      =  “for which the specific path that we need to create might = have to obey specific constraints.” – I think there was = discussion on having application server type devices (like lamps for = example) become DAG roots to help solve the mapping of RPL to P2P = solutions.  This really won’t work.  Aligning the = network topology by moving application devices to the role of DAG roots = won’t scale.

Don

 

From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf = Of Pascal Thubert (pthubert)
Sent: Monday, March 15, 2010 = 9:24 AM
To: robert.cragie@gridmerge.com; = Ted.Humpal@jci.com
Cc: ROLL WG
Subject: Re: [Roll] = P2P performance with current RPL = proposal

 

HI Robert :

 

I respectfully have to disagree.

 

My understanding is that we are considering a limited set of P2P = pairs, for which the specific path that we need to create might have to = obey specific constraints.

So it makes sense to use an on-demand technique, probably inspired by = the MANET Reactive protocols.

 

As it goes, those protocols usually use flooding for a node to locate = another. Forking a DAG is just another flooding. It does not take a lot = of addition to the existing DIO for a root to use RPL to build a DAG = that contains one or multiple Targets as leaves, under a set of = constraints expressed as an objective function. Please find attached a = slideware that illustrates that.

 

Pascal

 

From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf = Of Robert Cragie
Sent: Thursday, March 11, 2010 2:43 = PM
To: Ted.Humpal@jci.com
Cc: ROLL = WG
Subject: Re: [Roll] P2P performance with current RPL = proposal

 

I agree with Ted's comments = below. Creating a DODAG for every reachable node as a root seems a very = inefficient approach compared to alternative routing algorithms. I am = concerned that RPL does not actually meet the original requirements in = I-D.ietf-roll-building-routing-reqs, I-D.ietf-roll-home-routing-reqs, = RFC5673 and RFC5548. The traffic pattern requirement for a sink node = features prominently in only two of those documents. Even in this case, = as Ted points out, communication is likely to be bidirectional (e.g. = end-to-end acks.) therefore the DODAG approach is fundamentally = asymmetric, especially if no intermediate storage is allowed for = destination routes and source routing has to be used.

Also, RPL = seems highly complex for what are constrained nodes in terms of memory = as well as power and bandwidth. The RPL draft as it stands is 82 pages = long and that doesn't include text about the objective = function.

Robert

Robert = Cragie (Pacific Gas & Electric)

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



Ted.Humpal@jci.com wrote: =


A concern = also will be how much overhead (memory space) will be required for a = DODAG Root?

and based on = the first question how many DODAG roots a lamp may need to be a member = of?

For example = in lighting  a single lamp may be a root for a single switch (1 = DODAG root),  this lamp / luminaire may also
be a member = of another group - -  which could be all lights on the floor (2nd = DODAG root), and a third group
of all the = lights in the building.  There can be many more speciality groups = associated based on the building configuration.
Consider = also during the installation time - how these DODAG roots will be = configured?  Must I commission each device
to tell it = which DODAG it must use for its Object Function?  How easy will = this be to change and add in a new DODAG root
for the end = user if the lighting group changes??

With respect = to Jerry Martocci's - commercial building requirements - every device = may need to communicate to any or
all of the = end devices.  If each device must establish a DODAG for the other = 499 devices in a 500 node network - How much memory
space will = this require for each end device to maintain?   =

Keep in mind = that the end devices are very limited processor and memory wise. =

Not to = mention all of the network maintenance messages that would need to be = transmitted to maintain all of these DODAGs.

Consider the = reconvergence time when one device is turned off and it was in the = middle of the majority of the 100+ DODAGS?

In many = lighting and building application an application acknowledgement - must = be returned {Back down the DODAG} so . . . the
requirement = is not just getting to the Root - a return path must also be maintained = and have a  low latency path.

Ted = Humpal

= From:

Kris Pister = <pister@eecs.berkeley.edu>=

= To:

Anders Brandt = <abr@sdesigns.dk> =

= Cc:

ROLL WG <roll@ietf.org> =

= Date:

03/08/2010 = 01:45 PM

= Subject:

Re: [Roll] = P2P performance with current RPL = proposal

 




Anders - if = we take JP's suggestion to make The Lamp a DODAG root, and take Phoebus' = recommendation that we use path diversity to improve end-to-end = reliability, do you see a chance of success?
In my experience, with = diverse paths and order-minutes updates you get extremely high = reliability.

I have no aversion to TTL-limited floods as a part = of a solution either.  I'm open to ideas on how to bring those in = as (presumably infrequently used) options.

ksjp

Anders = Brandt wrote:
Hello
  =
I would like to = probe the temperature of the WG on using DAOs to
support P2P. =
 
The = building and home application spaces (and maybe others) have =
a few clearly = defined requirements.
It is not obvious to me = how the current RPL proposal (cRPLp) can
satisfy those = requirements:
 
 
In both cases it is the = worst case scenario that hurts:
 
 
P2P routing inside the = PAN
=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
cRPLp has no way of = routing inside the PAN if you need more than
one repeater. cRPLp has to = go all the way to the top (maybe 4 hops up)
and down again (maybe 4 = hops down) to get just 2 hops to the side.
 
The consequence is high = latency and high levels of background noise
for nodes just outside = the direct radio range.
At the same time the risk = of meeting a failing link is 4 times higher =3D>
latency may be much more = than 4 times larger.
 
Latency may sound like a = minor issue but it actually translates directly
into lower battery = lifetime. In the above (very realistic) example,
the battery lifetime is = reduced to 25% of what it should be.
 
We have lots of battery = devices sending into the network:
* PIR sensors turning on = lights
* = Door locks sending alarms
* Door/window sensors = starting chimes
* Smoke sensors triggering = an alarm system
 
 
  =
 
Response time =
=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D
The latency issue is = important.
When a user (real human = being) presses a light button the user expects
the light to turn = on.
cRPLp = proposes that nodes in the tree periodically advertises their =
presence using = DAOs.
The = periodicity is a real beast:
Thanks to Trickle, the = rate of updates in a (apparently) stable network
is low. This is good = since it leaves bandwidth for data.
But it is not good if = existing routes to my lamp fail and I do not get
new routes to my lamp = until it decides to send out a new DAO.
My user will (with a good = reason) not tolerate waiting for minutes for
the light to turn = on.
 
I have met two arguments = to counter this concern:
 
A1: Well, your lamp can = always send a DAO when it detects a problem.
  My answer: =
  True, = except that my lamp does not intend to send anything
  so it will never = experience any problems from its side of the network.
  =
A2: Well, you = can increase the DAO rate to sub-second updates.
  My answer: =
  = Oh no. I get a very high = degree of management traffic which
  limits my available = bandwidth, increases the risk of collisions and
  even run the risk = of violating EU legislation requiring me to only
  transmit in less = than 1% of the time:
  http://focus.ti.com/lit/an/= swra048/swra048.pdf
 868 - 868.6 MHz: = <1%
 
  Reactiveness is = hard to achieve via polling.
 
 
  =
If you agree = that this seems to be critical issues please raise your
voice on the list. =
 
Going = forward
=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D
 
We need some reactive = mechanism to reach lamps before the user decides
to sue our = companies.
So is this possible? I = think so.

Existing commercial = (non-IP) solutions are capable of re-routing quickly
if they really have = to.
 
Let me try scoping the = requirements to a potential solution:
(no different from the = req. docs for home and building)
 
* P2P routing in any = direction independent of the tree.
 
* On-demand P2P route = discovery if requested by a real-time critical app.
 Data = collection apps may be able to just wait for the next DAO update. =
 
* Limited range of = discovery mechanism: max 4 repeaters.
  A TTL field may = limit the scope of the repeaters.
 
* Suboptimal routing and = traffic bursts are accepted in exchange
  for quick route = repair. But only as an exception.
 
 
Just as an example, one = existing home control technology uses a
(source routing) variant of = AODV for quick route repair.
Nothing comes for free. = The price is flooding - but not just flooding:
Managed flooding using = a distributed algorithm running in all
participating nodes. =
The algorithm = dampens the flooding in a time, volume and range perspective. =
Some = similar mechanism could be built into RPL for quick route repair. =
 
 
If anyone have alternative = proposals, please bring it to the list.
Now is the time. =
 
 
 
Thanks,
  Anders =


______________________________________________= _
Roll mailing = 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_01CAC468.AC93C314-- From pthubert@cisco.com Mon Mar 15 11:05: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 B94D03A6BDE for ; Mon, 15 Mar 2010 11:05:52 -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 5mhH0-imD8ON for ; Mon, 15 Mar 2010 11:05: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 09C683A68C2 for ; Mon, 15 Mar 2010 11:04:50 -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: Av0EAPITnkurRN+J/2dsb2JhbACDDJcAZnOhfogvj0+BMoJfagSORA X-IronPort-AV: E=Sophos;i="4.49,644,1262563200"; d="scan'208";a="166403461" Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-5.cisco.com with ESMTP; 15 Mar 2010 18:04:57 +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 o2FI4tNF028266; Mon, 15 Mar 2010 18:04: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); Mon, 15 Mar 2010 19:04:55 +0100 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, 15 Mar 2010 19:04:51 +0100 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D0170E042@XMB-AMS-107.cisco.com> In-Reply-To: <1242976330.5868041268675804357.JavaMail.root@mail02.pantherlink.uwm.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] P2P performance with current RPL proposal Thread-Index: AcrEaOXtw23afc2gSRKITIrmrWD4VAAAC4xQ References: <6A2A459175DABE4BB11DE2026AA50A5D0170DFA9@XMB-AMS-107.cisco.com> <1242976330.5868041268675804357.JavaMail.root@mail02.pantherlink.uwm.edu> From: "Pascal Thubert (pthubert)" To: "Mukul Goyal" X-OriginalArrivalTime: 15 Mar 2010 18:04:55.0728 (UTC) FILETIME=[04A99300:01CAC46A] Cc: ROLL WG , Ted Humpal Subject: Re: [Roll] P2P performance with current RPL proposal X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Mar 2010 18:05:52 -0000 SGkgTXVrdWwNCg0KPiAxLiBBIG5vZGUvcm91dGVyIGluIHRoZSBtaWRkbGUgbWF5IG5lZWQgdG8g bWFpbnRhaW4gc3RhdGUgZm9yIG11bHRpcGxlIERBR3MNCj4gdGhhdCBsZWFkIHRvIHRoZSBzYW1l IGRlc3RpbmF0aW9uLiBDb25zaWRlciB0aGUgc2l0dWF0aW9uIHdoZXJlIDUgbmVhcmJ5DQo+IG5v ZGVzIG5lZWQgdG8gZmluZCByb3V0ZSB0byB0aGUgc2FtZSBkZXN0aW5hdGlvbiBELiBBcyBwZXIg eW91ciBzY2hlbWUsDQo+IGVhY2ggbm9kZSB3b3VsZCBmb3JtIGl0cyBvd24gREFHIHRvd2FyZHMg dGhlIGRlc3RpbmF0aW9uIEQgYW5kIHRoZSBub2Rlcw0KPiBpbiB0aGUgbWlkZGxlIHdvdWxkIG5l ZWQgdG8gbWFpbnRhaW4gc3RhdGUgYWJvdXQgYWxsIDUgREFHcy4gVGhpcyBzZWVtcw0KPiB3YXN0 ZWZ1bC4gWW91IG1heSBhcmd1ZSB0aGF0IHRoaXMgaXMgYSBmaXQgY2FzZSBmb3IgdGhlc2UgNSBu b2RlcyB0byBiZWxvbmcgdG8gYQ0KPiBzaW5nbGUgREFHIHJvb3RlZCBhdCBELiBCdXQgdGhlIHBy b2JsZW0gaXMgdGhhdCBEIGRvZXMgbm90IGtub3cgdGhhdCBpdCBpcyBhDQo+IGRlc3RpbmF0aW9u IGZvciB0aGVzZSA1IG5vZGVzLiBTbywgaW4gZ2VuZXJhbCwgSSBzZWUgYSBzY2FsYWJpbGl0eSBw cm9ibGVtDQo+IGFzc29jaWF0ZWQgd2l0aCB0aGUgdXNlIG9mIERBR3MgZm9yIFAyUCByb3V0aW5n LiBBIHNpbXBsZSBEViBhcHByb2FjaCwNCj4gd2hlcmUgdGhlIG5vZGVzIG1haW50YWluIGluZm9y bWF0aW9uIGFib3V0IGRlc3RpbmF0aW9ucyAocmF0aGVyIHRoYW4NCj4gREFHcyksIHNlZW1zIHRv IGF2b2lkIHRoaXMgc2NhbGFiaWxpdHkgcHJvYmxlbS4NCg0KW1Bhc2NhbF0gSSBkbyBub3Qga25v dyB3aGF0IHlvdSBjYWxsIHJlZ3VsYXIgOikgDQpSSVAgdXN1YWxseSBtYWludGFpbnMgdHJlZXMg YnV0IGVpZ3JwIGFsbG93cyBmb3Igbm9uLWVxdWFsIGNvc3QgZmVhc2libGUgc3VjY2Vzc29ycyBh bmQgdGh1cyBidWlsZHMgREFHcy4NCg0KQU9EViAoVGhvbWFzLCBvciBDaGFybGllIGlmIHlvdSdy ZSBsaXN0ZW5pbmcsIGNvcnJlY3QgbWUgaWYgSSdtIHdyb25nKSBidWlsZHMgYW5kIG1haW50YWlu cyByb3V0ZXMgdGhhdCBhcmUgZG90dGVkIGxpbmVzIGJldHdlZW4gMiBwb2ludHMuDQoNCldpdGgg UlBMIHVzZWQgcmVhY3RpdmVseSBhcyBwcm9wb3NlZCBoZXJlLCB3ZSBjYW4gZG8gZWl0aGVyIHdh eS4gDQoNClRoZSBPRiBjYW4gYmUgZGVzaWduZWQgdG8gYnVpbGQgYSB0cmVlIGFuZCBpZiBzbywg d2UgZW5kIHVwIHdpdGggc29tZXRoaW5nIHF1aXRlIHNpbWlsYXIgdG8gQU9EVi9EWU1PLg0KT3Ig dGhlIE9GIHdhbnRzIGEgREFEIGZvciByZWR1bmRhbmN5IGFuZCB3ZSBidWlsZCBhIERBRy4NCg0K T25lIGNvb2wgdGhpbmcgaXMgdGhhdCB3ZSBjYW4gcmVxdWVzdCBtb3JlIHRoYW4gb25lIHRhcmdl dCwgZWZmZWN0aXZlbHkgYnVpbGRpbmcgYSBEQUcgdGhhdCBsb29rcyBsaWtlIGEgZmxvd2VyLg0K DQpJdCdzIG5vdCBhIG1hdHRlciBvZiBzY2FsYWJpbGl0eSwgaXQncyBhIG1hdHRlciBvZiB3aGF0 IHlvdSBjYW50IHRvIGFjaGlldmUgYW5kIHRoZSBhc3NvY2lhdGVkIGNvc3QuIERBRyBpcyBtb3Jl IGV4cGVuc2l2ZSB0aGFuIHRyZWUuDQoNCg0KPiANCj4gMi4gU28sIGluIHlvdXIgc2NoZW1lLCB0 aGUgbm9kZXMgdGltZW91dCB0aGUgc3RhdGUgdGhleSBoYXZlIGZvciBhIERBRy4gVGhpcw0KPiBt ZWFucyB0aGF0IGEgbm9kZSB0aGF0IGRvZXMgbm90IGJlbG9uZyB0byB0aGUgYWN0dWFsIHJvdXRl IHRha2VuIGJ5IHRoZQ0KPiBwYWNrZXRzIHdvdWxkIGVuZCB1cCB0aW1pbmcgb3V0IGl0cyBzdGF0 ZSBmb3IgdGhpcyBEQUcuIFRoaXMgaXMgb2sgdW5sZXNzIHRoaXMNCj4gbm9kZSBpcyBwYXJ0IG9m IGFuIG9idmlvdXMgYmFja3VwIHJvdXRlIGFuZCBzaG91bGQgaGF2ZSBtYWludGFpbmVkDQo+IGlu Zm9ybWF0aW9uIGFib3V0IHRoaXMgREFHLiBJdCB3b3VsZCBiZSBnb29kIHRvIHVzZSB0aGUgInJv dXRpbmcgaW50ZXJlc3QiDQo+IGNvbmNlcHQgaW4gdGhpcyBzaXR1YXRpb24uIEFzIHBlciB0aGlz IGNvbmNlcHQsIGVhY2ggbm9kZSBtYWludGFpbnMgYSAicm91dGluZw0KPiBpbnRlcmVzdCIgaW4g YSBwYXJ0aWN1bGFyIERBRyAob3IgZGVzdGluYXRpb24pLiBUaGUgcm91dGluZyBpbnRlcmVzdCBp cyBhIG1ldHJpYw0KPiBiZXR3ZWVuIDAgYW5kIDEuIElmIGEgbm9kZSBpcyBhY3RpdmVseSBzZW5k aW5nIHBhY2tldHMgYWxvbmcgdGhlIERBRywgaXRzDQo+IHJvdXRpbmcgaW50ZXJlc3Qgd291bGQg YmUgMS4gT3RoZXJ3aXNlLCB0aGUgcm91dGluZyBpbnRlcmVzdCB3b3VsZCBiZQ0KPiB4Km1heChy b3V0aW5nIGludGVyZXN0IG9mIGl0cyBuYnJzKSwgd2hlcmUgeCBpcyBhIGZyYWN0aW9uLiBBIG5v ZGUgbWF5IGRlbGV0ZQ0KPiBzdGF0ZSBhYm91dCBhIERBRy9kZXN0aW5hdGlvbiBpZiBpdHMgcm91 dGluZyBpbnRlcmVzdCBpbiB0aGF0IGRhZy9kZXN0aW5hdGlvbg0KPiBkcm9wcyBiZWxvdyBhIHRo cmVzaG9sZC4gVGhlIHJvdXRpbmcgaW50ZXJlc3QgY29uY2VwdCB3b3VsZCBhbGxvdyBub2Rlcw0K PiAiYXJvdW5kJyB0aGUgYWN0dWFsIHBhdGggdG8gbWFpbnRhaW4gc3RhdGUgYWJvdXQgdGhpcyBk YWcgd2hpbGUgb3RoZXIgbm9kZXMNCj4gY2FuIGRlbGV0ZSB0aGlzIHN0YXRlIGFmdGVyIGluaXRp YWwgcm91dGUgZGlzY292ZXJ5Lg0KW1Bhc2NhbF0gDQoNCkNvb2wgOiApIE5vdyB3ZSdyZSBidWls ZGluZyBhIHNvbHV0aW9uLg0KDQpQYXNjYWwgDQoNCj4gDQo+IFRoYW5rcw0KPiBNdWt1bA0KPiAt LS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tDQo+IEZyb206ICJQYXNjYWwgVGh1YmVydCAocHRo dWJlcnQpIiA8cHRodWJlcnRAY2lzY28uY29tPg0KPiBUbzogInJvYmVydCBjcmFnaWUiIDxyb2Jl cnQuY3JhZ2llQGdyaWRtZXJnZS5jb20+LCAiVGVkIEh1bXBhbCINCj4gPFRlZC5IdW1wYWxAamNp LmNvbT4NCj4gQ2M6ICJST0xMIFdHIiA8cm9sbEBpZXRmLm9yZz4NCj4gU2VudDogTW9uZGF5LCBN YXJjaCAxNSwgMjAxMCAxMToyNDowMSBBTSBHTVQgLTA2OjAwIFVTL0NhbmFkYSBDZW50cmFsDQo+ IFN1YmplY3Q6IFJlOiBbUm9sbF0gUDJQIHBlcmZvcm1hbmNlIHdpdGggY3VycmVudCBSUEwgcHJv cG9zYWwNCj4gDQo+IA0KPiANCj4gDQo+IA0KPiBISSBSb2JlcnQgOg0KPiANCj4gDQo+IA0KPiBJ IHJlc3BlY3RmdWxseSBoYXZlIHRvIGRpc2FncmVlLg0KPiANCj4gDQo+IA0KPiBNeSB1bmRlcnN0 YW5kaW5nIGlzIHRoYXQgd2UgYXJlIGNvbnNpZGVyaW5nIGEgbGltaXRlZCBzZXQgb2YgUDJQIHBh aXJzLCBmb3INCj4gd2hpY2ggdGhlIHNwZWNpZmljIHBhdGggdGhhdCB3ZSBuZWVkIHRvIGNyZWF0 ZSBtaWdodCBoYXZlIHRvIG9iZXkgc3BlY2lmaWMNCj4gY29uc3RyYWludHMuDQo+IA0KPiBTbyBp dCBtYWtlcyBzZW5zZSB0byB1c2UgYW4gb24tZGVtYW5kIHRlY2huaXF1ZSwgcHJvYmFibHkgaW5z cGlyZWQgYnkgdGhlDQo+IE1BTkVUIFJlYWN0aXZlIHByb3RvY29scy4NCj4gDQo+IA0KPiANCj4g QXMgaXQgZ29lcywgdGhvc2UgcHJvdG9jb2xzIHVzdWFsbHkgdXNlIGZsb29kaW5nIGZvciBhIG5v ZGUgdG8gbG9jYXRlIGFub3RoZXIuDQo+IEZvcmtpbmcgYSBEQUcgaXMganVzdCBhbm90aGVyIGZs b29kaW5nLiBJdCBkb2VzIG5vdCB0YWtlIGEgbG90IG9mIGFkZGl0aW9uIHRvIHRoZQ0KPiBleGlz dGluZyBESU8gZm9yIGEgcm9vdCB0byB1c2UgUlBMIHRvIGJ1aWxkIGEgREFHIHRoYXQgY29udGFp bnMgb25lIG9yIG11bHRpcGxlDQo+IFRhcmdldHMgYXMgbGVhdmVzLCB1bmRlciBhIHNldCBvZiBj b25zdHJhaW50cyBleHByZXNzZWQgYXMgYW4gb2JqZWN0aXZlDQo+IGZ1bmN0aW9uLiBQbGVhc2Ug ZmluZCBhdHRhY2hlZCBhIHNsaWRld2FyZSB0aGF0IGlsbHVzdHJhdGVzIHRoYXQuDQo+IA0KPiAN Cj4gDQo+IA0KPiBQYXNjYWwNCj4gDQo+IA0KPiANCj4gDQo+IA0KPiANCj4gRnJvbTogcm9sbC1i b3VuY2VzQGlldGYub3JnIFttYWlsdG86cm9sbC1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYg T2YNCj4gUm9iZXJ0IENyYWdpZQ0KPiBTZW50OiBUaHVyc2RheSwgTWFyY2ggMTEsIDIwMTAgMjo0 MyBQTQ0KPiBUbzogVGVkLkh1bXBhbEBqY2kuY29tDQo+IENjOiBST0xMIFdHDQo+IFN1YmplY3Q6 IFJlOiBbUm9sbF0gUDJQIHBlcmZvcm1hbmNlIHdpdGggY3VycmVudCBSUEwgcHJvcG9zYWwNCj4g DQo+IA0KPiANCj4gSSBhZ3JlZSB3aXRoIFRlZCdzIGNvbW1lbnRzIGJlbG93LiBDcmVhdGluZyBh IERPREFHIGZvciBldmVyeSByZWFjaGFibGUNCj4gbm9kZSBhcyBhIHJvb3Qgc2VlbXMgYSB2ZXJ5 IGluZWZmaWNpZW50IGFwcHJvYWNoIGNvbXBhcmVkIHRvIGFsdGVybmF0aXZlDQo+IHJvdXRpbmcg YWxnb3JpdGhtcy4gSSBhbSBjb25jZXJuZWQgdGhhdCBSUEwgZG9lcyBub3QgYWN0dWFsbHkgbWVl dCB0aGUNCj4gb3JpZ2luYWwgcmVxdWlyZW1lbnRzIGluIEktRC5pZXRmLXJvbGwtYnVpbGRpbmct cm91dGluZy1yZXFzLCBJLUQuaWV0Zi1yb2xsLWhvbWUtDQo+IHJvdXRpbmctcmVxcywgUkZDNTY3 MyBhbmQgUkZDNTU0OC4gVGhlIHRyYWZmaWMgcGF0dGVybiByZXF1aXJlbWVudCBmb3IgYQ0KPiBz aW5rIG5vZGUgZmVhdHVyZXMgcHJvbWluZW50bHkgaW4gb25seSB0d28gb2YgdGhvc2UgZG9jdW1l bnRzLiBFdmVuIGluIHRoaXMNCj4gY2FzZSwgYXMgVGVkIHBvaW50cyBvdXQsIGNvbW11bmljYXRp b24gaXMgbGlrZWx5IHRvIGJlIGJpZGlyZWN0aW9uYWwgKGUuZy4gZW5kLQ0KPiB0by1lbmQgYWNr cy4pIHRoZXJlZm9yZSB0aGUgRE9EQUcgYXBwcm9hY2ggaXMgZnVuZGFtZW50YWxseSBhc3ltbWV0 cmljLA0KPiBlc3BlY2lhbGx5IGlmIG5vIGludGVybWVkaWF0ZSBzdG9yYWdlIGlzIGFsbG93ZWQg Zm9yIGRlc3RpbmF0aW9uIHJvdXRlcyBhbmQNCj4gc291cmNlIHJvdXRpbmcgaGFzIHRvIGJlIHVz ZWQuDQo+IA0KPiBBbHNvLCBSUEwgc2VlbXMgaGlnaGx5IGNvbXBsZXggZm9yIHdoYXQgYXJlIGNv bnN0cmFpbmVkIG5vZGVzIGluIHRlcm1zIG9mDQo+IG1lbW9yeSBhcyB3ZWxsIGFzIHBvd2VyIGFu ZCBiYW5kd2lkdGguIFRoZSBSUEwgZHJhZnQgYXMgaXQgc3RhbmRzIGlzIDgyDQo+IHBhZ2VzIGxv bmcgYW5kIHRoYXQgZG9lc24ndCBpbmNsdWRlIHRleHQgYWJvdXQgdGhlIG9iamVjdGl2ZSBmdW5j dGlvbi4NCj4gDQo+IFJvYmVydA0KPiANCj4gDQo+IFJvYmVydCBDcmFnaWUgKFBhY2lmaWMgR2Fz ICYgRWxlY3RyaWMpDQo+IA0KPiBHcmlkbWVyZ2UgTHRkLg0KPiA4OSBHcmVlbmZpZWxkIENyZXNj ZW50LA0KPiBXYWtlZmllbGQsIFdGNCA0V0EsIFVLDQo+ICs0NCAoMCkgMTkyNCA5MTA4ODgNCj4g aHR0cDovL3d3dy5ncmlkbWVyZ2UuY29tDQo+IA0KPiANCj4gDQo+IFRlZC5IdW1wYWxAamNpLmNv bSB3cm90ZToNCj4gDQo+IA0KPiBBIGNvbmNlcm4gYWxzbyB3aWxsIGJlIGhvdyBtdWNoIG92ZXJo ZWFkIChtZW1vcnkgc3BhY2UpIHdpbGwgYmUgcmVxdWlyZWQNCj4gZm9yIGEgRE9EQUcgUm9vdD8N Cj4gDQo+IGFuZCBiYXNlZCBvbiB0aGUgZmlyc3QgcXVlc3Rpb24gaG93IG1hbnkgRE9EQUcgcm9v dHMgYSBsYW1wIG1heSBuZWVkIHRvDQo+IGJlIGEgbWVtYmVyIG9mPw0KPiANCj4gRm9yIGV4YW1w bGUgaW4gbGlnaHRpbmcgIGEgc2luZ2xlIGxhbXAgbWF5IGJlIGEgcm9vdCBmb3IgYSBzaW5nbGUg c3dpdGNoICgxDQo+IERPREFHIHJvb3QpLCAgdGhpcyBsYW1wIC8gbHVtaW5haXJlIG1heSBhbHNv DQo+IGJlIGEgbWVtYmVyIG9mIGFub3RoZXIgZ3JvdXAgLSAtICB3aGljaCBjb3VsZCBiZSBhbGwg bGlnaHRzIG9uIHRoZSBmbG9vciAoMm5kDQo+IERPREFHIHJvb3QpLCBhbmQgYSB0aGlyZCBncm91 cA0KPiBvZiBhbGwgdGhlIGxpZ2h0cyBpbiB0aGUgYnVpbGRpbmcuICBUaGVyZSBjYW4gYmUgbWFu eSBtb3JlIHNwZWNpYWxpdHkgZ3JvdXBzDQo+IGFzc29jaWF0ZWQgYmFzZWQgb24gdGhlIGJ1aWxk aW5nIGNvbmZpZ3VyYXRpb24uDQo+IENvbnNpZGVyIGFsc28gZHVyaW5nIHRoZSBpbnN0YWxsYXRp b24gdGltZSAtIGhvdyB0aGVzZSBET0RBRyByb290cyB3aWxsIGJlDQo+IGNvbmZpZ3VyZWQ/ICBN dXN0IEkgY29tbWlzc2lvbiBlYWNoIGRldmljZQ0KPiB0byB0ZWxsIGl0IHdoaWNoIERPREFHIGl0 IG11c3QgdXNlIGZvciBpdHMgT2JqZWN0IEZ1bmN0aW9uPyAgSG93IGVhc3kgd2lsbCB0aGlzDQo+ IGJlIHRvIGNoYW5nZSBhbmQgYWRkIGluIGEgbmV3IERPREFHIHJvb3QNCj4gZm9yIHRoZSBlbmQg dXNlciBpZiB0aGUgbGlnaHRpbmcgZ3JvdXAgY2hhbmdlcz8/DQo+IA0KPiBXaXRoIHJlc3BlY3Qg dG8gSmVycnkgTWFydG9jY2kncyAtIGNvbW1lcmNpYWwgYnVpbGRpbmcgcmVxdWlyZW1lbnRzIC0g ZXZlcnkNCj4gZGV2aWNlIG1heSBuZWVkIHRvIGNvbW11bmljYXRlIHRvIGFueSBvcg0KPiBhbGwg b2YgdGhlIGVuZCBkZXZpY2VzLiAgSWYgZWFjaCBkZXZpY2UgbXVzdCBlc3RhYmxpc2ggYSBET0RB RyBmb3IgdGhlIG90aGVyDQo+IDQ5OSBkZXZpY2VzIGluIGEgNTAwIG5vZGUgbmV0d29yayAtIEhv dyBtdWNoIG1lbW9yeQ0KPiBzcGFjZSB3aWxsIHRoaXMgcmVxdWlyZSBmb3IgZWFjaCBlbmQgZGV2 aWNlIHRvIG1haW50YWluPw0KPiANCj4gS2VlcCBpbiBtaW5kIHRoYXQgdGhlIGVuZCBkZXZpY2Vz IGFyZSB2ZXJ5IGxpbWl0ZWQgcHJvY2Vzc29yIGFuZCBtZW1vcnkNCj4gd2lzZS4NCj4gDQo+IE5v dCB0byBtZW50aW9uIGFsbCBvZiB0aGUgbmV0d29yayBtYWludGVuYW5jZSBtZXNzYWdlcyB0aGF0 IHdvdWxkIG5lZWQNCj4gdG8gYmUgdHJhbnNtaXR0ZWQgdG8gbWFpbnRhaW4gYWxsIG9mIHRoZXNl IERPREFHcy4NCj4gDQo+IENvbnNpZGVyIHRoZSByZWNvbnZlcmdlbmNlIHRpbWUgd2hlbiBvbmUg ZGV2aWNlIGlzIHR1cm5lZCBvZmYgYW5kIGl0IHdhcyBpbg0KPiB0aGUgbWlkZGxlIG9mIHRoZSBt YWpvcml0eSBvZiB0aGUgMTAwKyBET0RBR1M/DQo+IA0KPiBJbiBtYW55IGxpZ2h0aW5nIGFuZCBi dWlsZGluZyBhcHBsaWNhdGlvbiBhbiBhcHBsaWNhdGlvbiBhY2tub3dsZWRnZW1lbnQgLQ0KPiBt dXN0IGJlIHJldHVybmVkIHtCYWNrIGRvd24gdGhlIERPREFHfSBzbyAuIC4gLiB0aGUNCj4gcmVx dWlyZW1lbnQgaXMgbm90IGp1c3QgZ2V0dGluZyB0byB0aGUgUm9vdCAtIGEgcmV0dXJuIHBhdGgg bXVzdCBhbHNvIGJlDQo+IG1haW50YWluZWQgYW5kIGhhdmUgYSAgbG93IGxhdGVuY3kgcGF0aC4N Cj4gDQo+IFRlZCBIdW1wYWwNCj4gDQo+IA0KPiANCj4gDQo+IA0KPiBGcm9tOg0KPiANCj4gS3Jp cyBQaXN0ZXIgPHBpc3RlckBlZWNzLmJlcmtlbGV5LmVkdT4NCj4gDQo+IA0KPiBUbzoNCj4gDQo+ IEFuZGVycyBCcmFuZHQgPGFickBzZGVzaWducy5kaz4NCj4gDQo+IA0KPiBDYzoNCj4gDQo+IFJP TEwgV0cgPHJvbGxAaWV0Zi5vcmc+DQo+IA0KPiANCj4gRGF0ZToNCj4gDQo+IDAzLzA4LzIwMTAg MDE6NDUgUE0NCj4gDQo+IA0KPiBTdWJqZWN0Og0KPiANCj4gUmU6IFtSb2xsXSBQMlAgcGVyZm9y bWFuY2Ugd2l0aCBjdXJyZW50IFJQTCBwcm9wb3NhbA0KPiANCj4gDQo+IA0KPiANCj4gDQo+IA0K PiANCj4gDQo+IEFuZGVycyAtIGlmIHdlIHRha2UgSlAncyBzdWdnZXN0aW9uIHRvIG1ha2UgVGhl IExhbXAgYSBET0RBRyByb290LCBhbmQNCj4gdGFrZSBQaG9lYnVzJyByZWNvbW1lbmRhdGlvbiB0 aGF0IHdlIHVzZSBwYXRoIGRpdmVyc2l0eSB0byBpbXByb3ZlIGVuZC0NCj4gdG8tZW5kIHJlbGlh YmlsaXR5LCBkbyB5b3Ugc2VlIGEgY2hhbmNlIG9mIHN1Y2Nlc3M/DQo+IEluIG15IGV4cGVyaWVu Y2UsIHdpdGggZGl2ZXJzZSBwYXRocyBhbmQgb3JkZXItbWludXRlcyB1cGRhdGVzIHlvdSBnZXQN Cj4gZXh0cmVtZWx5IGhpZ2ggcmVsaWFiaWxpdHkuDQo+IA0KPiBJIGhhdmUgbm8gYXZlcnNpb24g dG8gVFRMLWxpbWl0ZWQgZmxvb2RzIGFzIGEgcGFydCBvZiBhIHNvbHV0aW9uIGVpdGhlci4gIEkn bQ0KPiBvcGVuIHRvIGlkZWFzIG9uIGhvdyB0byBicmluZyB0aG9zZSBpbiBhcyAocHJlc3VtYWJs eSBpbmZyZXF1ZW50bHkgdXNlZCkNCj4gb3B0aW9ucy4NCj4gDQo+IGtzanANCj4gDQo+IEFuZGVy cyBCcmFuZHQgd3JvdGU6DQo+IEhlbGxvDQo+IA0KPiBJIHdvdWxkIGxpa2UgdG8gcHJvYmUgdGhl IHRlbXBlcmF0dXJlIG9mIHRoZSBXRyBvbiB1c2luZyBEQU9zIHRvDQo+IHN1cHBvcnQgUDJQLg0K PiANCj4gVGhlIGJ1aWxkaW5nIGFuZCBob21lIGFwcGxpY2F0aW9uIHNwYWNlcyAoYW5kIG1heWJl IG90aGVycykgaGF2ZQ0KPiBhIGZldyBjbGVhcmx5IGRlZmluZWQgcmVxdWlyZW1lbnRzLg0KPiBJ dCBpcyBub3Qgb2J2aW91cyB0byBtZSBob3cgdGhlIGN1cnJlbnQgUlBMIHByb3Bvc2FsIChjUlBM cCkgY2FuDQo+IHNhdGlzZnkgdGhvc2UgcmVxdWlyZW1lbnRzOg0KPiANCj4gDQo+IEluIGJvdGgg Y2FzZXMgaXQgaXMgdGhlIHdvcnN0IGNhc2Ugc2NlbmFyaW8gdGhhdCBodXJ0czoNCj4gDQo+IA0K PiBQMlAgcm91dGluZyBpbnNpZGUgdGhlIFBBTg0KPiA9PT09PT09PT09PT09PT09PT09PT09PT09 PQ0KPiBjUlBMcCBoYXMgbm8gd2F5IG9mIHJvdXRpbmcgaW5zaWRlIHRoZSBQQU4gaWYgeW91IG5l ZWQgbW9yZSB0aGFuDQo+IG9uZSByZXBlYXRlci4gY1JQTHAgaGFzIHRvIGdvIGFsbCB0aGUgd2F5 IHRvIHRoZSB0b3AgKG1heWJlIDQgaG9wcyB1cCkNCj4gYW5kIGRvd24gYWdhaW4gKG1heWJlIDQg aG9wcyBkb3duKSB0byBnZXQganVzdCAyIGhvcHMgdG8gdGhlIHNpZGUuDQo+IA0KPiBUaGUgY29u c2VxdWVuY2UgaXMgaGlnaCBsYXRlbmN5IGFuZCBoaWdoIGxldmVscyBvZiBiYWNrZ3JvdW5kIG5v aXNlDQo+IGZvciBub2RlcyBqdXN0IG91dHNpZGUgdGhlIGRpcmVjdCByYWRpbyByYW5nZS4NCj4g QXQgdGhlIHNhbWUgdGltZSB0aGUgcmlzayBvZiBtZWV0aW5nIGEgZmFpbGluZyBsaW5rIGlzIDQg dGltZXMgaGlnaGVyID0+DQo+IGxhdGVuY3kgbWF5IGJlIG11Y2ggbW9yZSB0aGFuIDQgdGltZXMg bGFyZ2VyLg0KPiANCj4gTGF0ZW5jeSBtYXkgc291bmQgbGlrZSBhIG1pbm9yIGlzc3VlIGJ1dCBp dCBhY3R1YWxseSB0cmFuc2xhdGVzIGRpcmVjdGx5DQo+IGludG8gbG93ZXIgYmF0dGVyeSBsaWZl dGltZS4gSW4gdGhlIGFib3ZlICh2ZXJ5IHJlYWxpc3RpYykgZXhhbXBsZSwNCj4gdGhlIGJhdHRl cnkgbGlmZXRpbWUgaXMgcmVkdWNlZCB0byAyNSUgb2Ygd2hhdCBpdCBzaG91bGQgYmUuDQo+IA0K PiBXZSBoYXZlIGxvdHMgb2YgYmF0dGVyeSBkZXZpY2VzIHNlbmRpbmcgaW50byB0aGUgbmV0d29y azoNCj4gKiBQSVIgc2Vuc29ycyB0dXJuaW5nIG9uIGxpZ2h0cw0KPiAqIERvb3IgbG9ja3Mgc2Vu ZGluZyBhbGFybXMNCj4gKiBEb29yL3dpbmRvdyBzZW5zb3JzIHN0YXJ0aW5nIGNoaW1lcw0KPiAq IFNtb2tlIHNlbnNvcnMgdHJpZ2dlcmluZyBhbiBhbGFybSBzeXN0ZW0NCj4gDQo+IA0KPiANCj4g DQo+IFJlc3BvbnNlIHRpbWUNCj4gPT09PT09PT09PT09PQ0KPiBUaGUgbGF0ZW5jeSBpc3N1ZSBp cyBpbXBvcnRhbnQuDQo+IFdoZW4gYSB1c2VyIChyZWFsIGh1bWFuIGJlaW5nKSBwcmVzc2VzIGEg bGlnaHQgYnV0dG9uIHRoZSB1c2VyIGV4cGVjdHMNCj4gdGhlIGxpZ2h0IHRvIHR1cm4gb24uDQo+ IGNSUExwIHByb3Bvc2VzIHRoYXQgbm9kZXMgaW4gdGhlIHRyZWUgcGVyaW9kaWNhbGx5IGFkdmVy dGlzZXMgdGhlaXINCj4gcHJlc2VuY2UgdXNpbmcgREFPcy4NCj4gVGhlIHBlcmlvZGljaXR5IGlz IGEgcmVhbCBiZWFzdDoNCj4gVGhhbmtzIHRvIFRyaWNrbGUsIHRoZSByYXRlIG9mIHVwZGF0ZXMg aW4gYSAoYXBwYXJlbnRseSkgc3RhYmxlIG5ldHdvcmsNCj4gaXMgbG93LiBUaGlzIGlzIGdvb2Qg c2luY2UgaXQgbGVhdmVzIGJhbmR3aWR0aCBmb3IgZGF0YS4NCj4gQnV0IGl0IGlzIG5vdCBnb29k IGlmIGV4aXN0aW5nIHJvdXRlcyB0byBteSBsYW1wIGZhaWwgYW5kIEkgZG8gbm90IGdldA0KPiBu ZXcgcm91dGVzIHRvIG15IGxhbXAgdW50aWwgaXQgZGVjaWRlcyB0byBzZW5kIG91dCBhIG5ldyBE QU8uDQo+IE15IHVzZXIgd2lsbCAod2l0aCBhIGdvb2QgcmVhc29uKSBub3QgdG9sZXJhdGUgd2Fp dGluZyBmb3IgbWludXRlcyBmb3INCj4gdGhlIGxpZ2h0IHRvIHR1cm4gb24uDQo+IA0KPiBJIGhh dmUgbWV0IHR3byBhcmd1bWVudHMgdG8gY291bnRlciB0aGlzIGNvbmNlcm46DQo+IA0KPiBBMTog V2VsbCwgeW91ciBsYW1wIGNhbiBhbHdheXMgc2VuZCBhIERBTyB3aGVuIGl0IGRldGVjdHMgYSBw cm9ibGVtLg0KPiAgIE15IGFuc3dlcjoNCj4gICBUcnVlLCBleGNlcHQgdGhhdCBteSBsYW1wIGRv ZXMgbm90IGludGVuZCB0byBzZW5kIGFueXRoaW5nDQo+ICAgc28gaXQgd2lsbCBuZXZlciBleHBl cmllbmNlIGFueSBwcm9ibGVtcyBmcm9tIGl0cyBzaWRlIG9mIHRoZSBuZXR3b3JrLg0KPiANCj4g QTI6IFdlbGwsIHlvdSBjYW4gaW5jcmVhc2UgdGhlIERBTyByYXRlIHRvIHN1Yi1zZWNvbmQgdXBk YXRlcy4NCj4gICBNeSBhbnN3ZXI6DQo+ICAgT2ggbm8uIEkgZ2V0IGEgdmVyeSBoaWdoIGRlZ3Jl ZSBvZiBtYW5hZ2VtZW50IHRyYWZmaWMgd2hpY2gNCj4gICBsaW1pdHMgbXkgYXZhaWxhYmxlIGJh bmR3aWR0aCwgaW5jcmVhc2VzIHRoZSByaXNrIG9mIGNvbGxpc2lvbnMgYW5kDQo+ICAgZXZlbiBy dW4gdGhlIHJpc2sgb2YgdmlvbGF0aW5nIEVVIGxlZ2lzbGF0aW9uIHJlcXVpcmluZyBtZSB0byBv bmx5DQo+ICAgdHJhbnNtaXQgaW4gbGVzcyB0aGFuIDElIG9mIHRoZSB0aW1lOg0KPiAgIGh0dHA6 Ly9mb2N1cy50aS5jb20vbGl0L2FuL3N3cmEwNDgvc3dyYTA0OC5wZGYNCj4gIDg2OCAtIDg2OC42 IE1IejogPDElDQo+IA0KPiAgIFJlYWN0aXZlbmVzcyBpcyBoYXJkIHRvIGFjaGlldmUgdmlhIHBv bGxpbmcuDQo+IA0KPiANCj4gDQo+IElmIHlvdSBhZ3JlZSB0aGF0IHRoaXMgc2VlbXMgdG8gYmUg Y3JpdGljYWwgaXNzdWVzIHBsZWFzZSByYWlzZSB5b3VyDQo+IHZvaWNlIG9uIHRoZSBsaXN0Lg0K PiANCj4gR29pbmcgZm9yd2FyZA0KPiA9PT09PT09PT09PT09DQo+IA0KPiBXZSBuZWVkIHNvbWUg cmVhY3RpdmUgbWVjaGFuaXNtIHRvIHJlYWNoIGxhbXBzIGJlZm9yZSB0aGUgdXNlciBkZWNpZGVz DQo+IHRvIHN1ZSBvdXIgY29tcGFuaWVzLg0KPiBTbyBpcyB0aGlzIHBvc3NpYmxlPyBJIHRoaW5r IHNvLg0KPiANCj4gRXhpc3RpbmcgY29tbWVyY2lhbCAobm9uLUlQKSBzb2x1dGlvbnMgYXJlIGNh cGFibGUgb2YgcmUtcm91dGluZyBxdWlja2x5DQo+IGlmIHRoZXkgcmVhbGx5IGhhdmUgdG8uDQo+ IA0KPiBMZXQgbWUgdHJ5IHNjb3BpbmcgdGhlIHJlcXVpcmVtZW50cyB0byBhIHBvdGVudGlhbCBz b2x1dGlvbjoNCj4gKG5vIGRpZmZlcmVudCBmcm9tIHRoZSByZXEuIGRvY3MgZm9yIGhvbWUgYW5k IGJ1aWxkaW5nKQ0KPiANCj4gKiBQMlAgcm91dGluZyBpbiBhbnkgZGlyZWN0aW9uIGluZGVwZW5k ZW50IG9mIHRoZSB0cmVlLg0KPiANCj4gKiBPbi1kZW1hbmQgUDJQIHJvdXRlIGRpc2NvdmVyeSBp ZiByZXF1ZXN0ZWQgYnkgYSByZWFsLXRpbWUgY3JpdGljYWwgYXBwLg0KPiAgRGF0YSBjb2xsZWN0 aW9uIGFwcHMgbWF5IGJlIGFibGUgdG8ganVzdCB3YWl0IGZvciB0aGUgbmV4dCBEQU8gdXBkYXRl Lg0KPiANCj4gKiBMaW1pdGVkIHJhbmdlIG9mIGRpc2NvdmVyeSBtZWNoYW5pc206IG1heCA0IHJl cGVhdGVycy4NCj4gICBBIFRUTCBmaWVsZCBtYXkgbGltaXQgdGhlIHNjb3BlIG9mIHRoZSByZXBl YXRlcnMuDQo+IA0KPiAqIFN1Ym9wdGltYWwgcm91dGluZyBhbmQgdHJhZmZpYyBidXJzdHMgYXJl IGFjY2VwdGVkIGluIGV4Y2hhbmdlDQo+ICAgZm9yIHF1aWNrIHJvdXRlIHJlcGFpci4gQnV0IG9u bHkgYXMgYW4gZXhjZXB0aW9uLg0KPiANCj4gDQo+IEp1c3QgYXMgYW4gZXhhbXBsZSwgb25lIGV4 aXN0aW5nIGhvbWUgY29udHJvbCB0ZWNobm9sb2d5IHVzZXMgYQ0KPiAoc291cmNlIHJvdXRpbmcp IHZhcmlhbnQgb2YgQU9EViBmb3IgcXVpY2sgcm91dGUgcmVwYWlyLg0KPiBOb3RoaW5nIGNvbWVz IGZvciBmcmVlLiBUaGUgcHJpY2UgaXMgZmxvb2RpbmcgLSBidXQgbm90IGp1c3QgZmxvb2Rpbmc6 DQo+IE1hbmFnZWQgZmxvb2RpbmcgdXNpbmcgYSBkaXN0cmlidXRlZCBhbGdvcml0aG0gcnVubmlu ZyBpbiBhbGwNCj4gcGFydGljaXBhdGluZyBub2Rlcy4NCj4gVGhlIGFsZ29yaXRobSBkYW1wZW5z IHRoZSBmbG9vZGluZyBpbiBhIHRpbWUsIHZvbHVtZSBhbmQgcmFuZ2UNCj4gcGVyc3BlY3RpdmUu DQo+IFNvbWUgc2ltaWxhciBtZWNoYW5pc20gY291bGQgYmUgYnVpbHQgaW50byBSUEwgZm9yIHF1 aWNrIHJvdXRlIHJlcGFpci4NCj4gDQo+IA0KPiBJZiBhbnlvbmUgaGF2ZSBhbHRlcm5hdGl2ZSBw cm9wb3NhbHMsIHBsZWFzZSBicmluZyBpdCB0byB0aGUgbGlzdC4NCj4gTm93IGlzIHRoZSB0aW1l Lg0KPiANCj4gDQo+IA0KPiBUaGFua3MsDQo+ICAgQW5kZXJzDQo+IA0KPiANCj4gDQo+IA0KPiBf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBSb2xsIG1h aWxpbmcgbGlzdA0KPiBSb2xsQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vcm9sbA0KPiAgIF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fDQo+IFJvbGwgbWFpbGluZyBsaXN0DQo+IFJvbGxAaWV0Zi5vcmcNCj4gaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9yb2xsDQo+IA0KPiANCj4gDQo+IA0K PiAgIF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fIFJvbGwg bWFpbGluZw0KPiBsaXN0IFJvbGxAaWV0Zi5vcmcgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9yb2xsDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fDQo+IFJvbGwgbWFpbGluZyBsaXN0DQo+IFJvbGxAaWV0Zi5vcmcNCj4gaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9yb2xsDQo= From robert.cragie@gridmerge.com Mon Mar 15 11:27: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 1A4683A6B63 for ; Mon, 15 Mar 2010 11:27:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.133 X-Spam-Level: X-Spam-Status: No, score=-3.133 tagged_above=-999 required=5 tests=[AWL=0.465, 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 thOnxv-aqQ+E for ; Mon, 15 Mar 2010 11:27: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 C264F3A6AA1 for ; Mon, 15 Mar 2010 11:26:50 -0700 (PDT) Received: from client-82-25-239-211.glfd.adsl.virginmedia.com ([82.25.239.211] helo=[192.168.1.68]) by mail78.extendcp.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.70) id 1NrF07-0001lq-FO; Mon, 15 Mar 2010 18:26:52 +0000 Message-ID: <4B9E7BE8.9060109@gridmerge.com> Date: Mon, 15 Mar 2010 18:26:48 +0000 From: Robert Cragie Organization: Gridmerge Ltd. User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "Pascal Thubert (pthubert)" References: <6D9687E95918C04A8B30A7D6DA805A3E01429F5F@zensys17.zensys.local> <4B9553B8.6010001@eecs.berkeley.edu> <4B98F374.4030301@gridmerge.com> <6A2A459175DABE4BB11DE2026AA50A5D0170DFA9@XMB-AMS-107.cisco.com> In-Reply-To: <6A2A459175DABE4BB11DE2026AA50A5D0170DFA9@XMB-AMS-107.cisco.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms080002000605010300040503" Cc: ROLL WG , Ted.Humpal@jci.com Subject: Re: [Roll] P2P performance with current RPL proposal 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, 15 Mar 2010 18:27:21 -0000 This is a cryptographically signed message in MIME format. --------------ms080002000605010300040503 Content-Type: multipart/alternative; boundary="------------020204000203090109020504" This is a multi-part message in MIME format. --------------020204000203090109020504 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi Pascal, So in your slideware T can end up talking to R (DODAG root) through the DODAG. So are you proposing that all potential targets can act as a DODAG root? And therefore all intermediates have to retain DIO propagation support for that DODAG as well? This may work for limited P2P but seems less efficient than simple distance vector flooding RREQ/RREP like AODV or DYMO for generic P2P. What about R to T (or anyone else for that matter)? Do we source route, maintain state, some undefined hybrid of the two? I apologise if some of these questions have been answered in detail in earlier reflector posts but I have only recently started to concentrate my efforts on RPL and have 82 pages to wade through :-). I look forward to a productive session in Anaheim. Robert Robert Cragie (Pacific Gas & Electric) Gridmerge Ltd. 89 Greenfield Crescent, Wakefield, WF4 4WA, UK +44 (0) 1924 910888 http://www.gridmerge.com Pascal Thubert (pthubert) wrote: > > HI Robert : > > > > I respectfully have to disagree. > > > > My understanding is that we are considering a limited set of P2P > pairs, for which the specific path that we need to create might have > to obey specific constraints. > > So it makes sense to use an on-demand technique, probably inspired by > the MANET Reactive protocols. > > > > As it goes, those protocols usually use flooding for a node to locate > another. Forking a DAG is just another flooding. It does not take a > lot of addition to the existing DIO for a root to use RPL to build a > DAG that contains one or multiple Targets as leaves, under a set of > constraints expressed as an objective function. Please find attached a > slideware that illustrates that. > > > > Pascal > > > > *From:* roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] *On > Behalf Of *Robert Cragie > *Sent:* Thursday, March 11, 2010 2:43 PM > *To:* Ted.Humpal@jci.com > *Cc:* ROLL WG > *Subject:* Re: [Roll] P2P performance with current RPL proposal > > > > I agree with Ted's comments below. Creating a DODAG for every > reachable node as a root seems a very inefficient approach compared to > alternative routing algorithms. I am concerned that RPL does not > actually meet the original requirements in > I-D.ietf-roll-building-routing-reqs, I-D.ietf-roll-home-routing-reqs, > RFC5673 and RFC5548. The traffic pattern requirement for a sink node > features prominently in only two of those documents. Even in this > case, as Ted points out, communication is likely to be bidirectional > (e.g. end-to-end acks.) therefore the DODAG approach is fundamentally > asymmetric, especially if no intermediate storage is allowed for > destination routes and source routing has to be used. > > Also, RPL seems highly complex for what are constrained nodes in terms > of memory as well as power and bandwidth. The RPL draft as it stands > is 82 pages long and that doesn't include text about the objective > function. > > Robert > > Robert Cragie (Pacific Gas & Electric) > > Gridmerge Ltd. > 89 Greenfield Crescent, > Wakefield, WF4 4WA, UK > +44 (0) 1924 910888 > http://www.gridmerge.com > > > > Ted.Humpal@jci.com wrote: > > > A concern also will be how much overhead (memory space) will be > required for a DODAG Root? > > and based on the first question how many DODAG roots a lamp may need > to be a member of? > > For example in lighting a single lamp may be a root for a single > switch (1 DODAG root), this lamp / luminaire may also > be a member of another group - - which could be all lights on the > floor (2nd DODAG root), and a third group > of all the lights in the building. There can be many more speciality > groups associated based on the building configuration. > Consider also during the installation time - how these DODAG roots > will be configured? Must I commission each device > to tell it which DODAG it must use for its Object Function? How easy > will this be to change and add in a new DODAG root > for the end user if the lighting group changes?? > > With respect to Jerry Martocci's - commercial building requirements - > every device may need to communicate to any or > all of the end devices. If each device must establish a DODAG for the > other 499 devices in a 500 node network - How much memory > space will this require for each end device to maintain? > > Keep in mind that the end devices are very limited processor and > memory wise. > > Not to mention all of the network maintenance messages that would need > to be transmitted to maintain all of these DODAGs. > > Consider the reconvergence time when one device is turned off and it > was in the middle of the majority of the 100+ DODAGS? > > In many lighting and building application an application > acknowledgement - must be returned {Back down the DODAG} so . . . the > requirement is not just getting to the Root - a return path must also > be maintained and have a low latency path. > > Ted Humpal > > > > From: > > > > Kris Pister > > To: > > > > Anders Brandt > > Cc: > > > > ROLL WG > > Date: > > > > 03/08/2010 01:45 PM > > Subject: > > > > Re: [Roll] P2P performance with current RPL proposal > > > > ------------------------------------------------------------------------ > > > > > Anders - if we take JP's suggestion to make The Lamp a DODAG root, and > take Phoebus' recommendation that we use path diversity to improve > end-to-end reliability, do you see a chance of success? > In my experience, with diverse paths and order-minutes updates you get > extremely high reliability. > > I have no aversion to TTL-limited floods as a part of a solution > either. I'm open to ideas on how to bring those in as (presumably > infrequently used) options. > > ksjp > > Anders Brandt wrote: > Hello > > I would like to probe the temperature of the WG on using DAOs to > support P2P. > > The building and home application spaces (and maybe others) have > a few clearly defined requirements. > It is not obvious to me how the current RPL proposal (cRPLp) can > satisfy those requirements: > > > In both cases it is the worst case scenario that hurts: > > > P2P routing inside the PAN > ========================== > cRPLp has no way of routing inside the PAN if you need more than > one repeater. cRPLp has to go all the way to the top (maybe 4 hops up) > and down again (maybe 4 hops down) to get just 2 hops to the side. > > The consequence is high latency and high levels of background noise > for nodes just outside the direct radio range. > At the same time the risk of meeting a failing link is 4 times higher => > latency may be much more than 4 times larger. > > Latency may sound like a minor issue but it actually translates directly > into lower battery lifetime. In the above (very realistic) example, > the battery lifetime is reduced to 25% of what it should be. > > We have lots of battery devices sending into the network: > * PIR sensors turning on lights > * Door locks sending alarms > * Door/window sensors starting chimes > * Smoke sensors triggering an alarm system > > > > > Response time > ============= > The latency issue is important. > When a user (real human being) presses a light button the user expects > the light to turn on. > cRPLp proposes that nodes in the tree periodically advertises their > presence using DAOs. > The periodicity is a real beast: > Thanks to Trickle, the rate of updates in a (apparently) stable network > is low. This is good since it leaves bandwidth for data. > But it is not good if existing routes to my lamp fail and I do not get > new routes to my lamp until it decides to send out a new DAO. > My user will (with a good reason) not tolerate waiting for minutes for > the light to turn on. > > I have met two arguments to counter this concern: > > A1: Well, your lamp can always send a DAO when it detects a problem. > My answer: > True, except that my lamp does not intend to send anything > so it will never experience any problems from its side of the network. > > A2: Well, you can increase the DAO rate to sub-second updates. > My answer: > Oh no. I get a very high degree of management traffic which > limits my available bandwidth, increases the risk of collisions and > even run the risk of violating EU legislation requiring me to only > transmit in less than 1% of the time: > http://focus.ti.com/lit/an/swra048/swra048.pdf > 868 - 868.6 MHz: <1% > > Reactiveness is hard to achieve via polling. > > > > If you agree that this seems to be critical issues please raise your > voice on the list. > > Going forward > ============= > > We need some reactive mechanism to reach lamps before the user decides > to sue our companies. > So is this possible? I think so. > > Existing commercial (non-IP) solutions are capable of re-routing quickly > if they really have to. > > Let me try scoping the requirements to a potential solution: > (no different from the req. docs for home and building) > > * P2P routing in any direction independent of the tree. > > * On-demand P2P route discovery if requested by a real-time critical app. > Data collection apps may be able to just wait for the next DAO update. > > * Limited range of discovery mechanism: max 4 repeaters. > A TTL field may limit the scope of the repeaters. > > * Suboptimal routing and traffic bursts are accepted in exchange > for quick route repair. But only as an exception. > > > Just as an example, one existing home control technology uses a > (source routing) variant of AODV for quick route repair. > Nothing comes for free. The price is flooding - but not just flooding: > Managed flooding using a distributed algorithm running in all > participating nodes. > The algorithm dampens the flooding in a time, volume and range > perspective. > Some similar mechanism could be built into RPL for quick route repair. > > > If anyone have alternative proposals, please bring it to the list. > Now is the time. > > > > Thanks, > Anders > > ------------------------------------------------------------------------ > > > _______________________________________________ > Roll mailing 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 > --------------020204000203090109020504 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi Pascal,

So in your slideware T can end up talking to R (DODAG root) through the DODAG. So are you proposing that all potential targets can act as a DODAG root? And therefore all intermediates have to retain DIO propagation support for that DODAG as well? This may work for limited P2P but seems less efficient than simple distance vector flooding RREQ/RREP like AODV or DYMO for generic P2P. What about R to T (or anyone else for that matter)? Do we source route, maintain state, some undefined hybrid of the two?

I apologise if some of these questions have been answered in detail in earlier reflector posts but I have only recently started to concentrate my efforts on RPL and have 82 pages to wade through :-). I look forward to a productive session in Anaheim.

Robert

Robert Cragie (Pacific Gas & Electric)

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



Pascal Thubert (pthubert) wrote:

HI Robert :

 

I respectfully have to disagree.

 

My understanding is that we are considering a limited set of P2P pairs, for which the specific path that we need to create might have to obey specific constraints.

So it makes sense to use an on-demand technique, probably inspired by the MANET Reactive protocols.

 

As it goes, those protocols usually use flooding for a node to locate another. Forking a DAG is just another flooding. It does not take a lot of addition to the existing DIO for a root to use RPL to build a DAG that contains one or multiple Targets as leaves, under a set of constraints expressed as an objective function. Please find attached a slideware that illustrates that.

 

Pascal

 

From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Robert Cragie
Sent: Thursday, March 11, 2010 2:43 PM
To: Ted.Humpal@jci.com
Cc: ROLL WG
Subject: Re: [Roll] P2P performance with current RPL proposal

 

I agree with Ted's comments below. Creating a DODAG for every reachable node as a root seems a very inefficient approach compared to alternative routing algorithms. I am concerned that RPL does not actually meet the original requirements in I-D.ietf-roll-building-routing-reqs, I-D.ietf-roll-home-routing-reqs, RFC5673 and RFC5548. The traffic pattern requirement for a sink node features prominently in only two of those documents. Even in this case, as Ted points out, communication is likely to be bidirectional (e.g. end-to-end acks.) therefore the DODAG approach is fundamentally asymmetric, especially if no intermediate storage is allowed for destination routes and source routing has to be used.

Also, RPL seems highly complex for what are constrained nodes in terms of memory as well as power and bandwidth. The RPL draft as it stands is 82 pages long and that doesn't include text about the objective function.

Robert

Robert Cragie (Pacific Gas & Electric)

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



Ted.Humpal@jci.com wrote:


A concern also will be how much overhead (memory space) will be required for a DODAG Root?

and based on the first question how many DODAG roots a lamp may need to be a member of?

For example in lighting  a single lamp may be a root for a single switch (1 DODAG root),  this lamp / luminaire may also
be a member of another group - -  which could be all lights on the floor (2nd DODAG root), and a third group
of all the lights in the building.  There can be many more speciality groups associated based on the building configuration.
Consider also during the installation time - how these DODAG roots will be configured?  Must I commission each device
to tell it which DODAG it must use for its Object Function?  How easy will this be to change and add in a new DODAG root
for the end user if the lighting group changes??

With respect to Jerry Martocci's - commercial building requirements - every device may need to communicate to any or
all of the end devices.  If each device must establish a DODAG for the other 499 devices in a 500 node network - How much memory
space will this require for each end device to maintain?  

Keep in mind that the end devices are very limited processor and memory wise.

Not to mention all of the network maintenance messages that would need to be transmitted to maintain all of these DODAGs.

Consider the reconvergence time when one device is turned off and it was in the middle of the majority of the 100+ DODAGS?

In many lighting and building application an application acknowledgement - must be returned {Back down the DODAG} so . . . the
requirement is not just getting to the Root - a return path must also be maintained and have a  low latency path.

Ted Humpal



From:

Kris Pister <pister@eecs.berkeley.edu>

To:

Anders Brandt <abr@sdesigns.dk>

Cc:

ROLL WG <roll@ietf.org>

Date:

03/08/2010 01:45 PM

Subject:

Re: [Roll] P2P performance with current RPL proposal

 




Anders - if we take JP's suggestion to make The Lamp a DODAG root, and take Phoebus' recommendation that we use path diversity to improve end-to-end reliability, do you see a chance of success?
In my experience, with diverse paths and order-minutes updates you get extremely high reliability.

I have no aversion to TTL-limited floods as a part of a solution either.  I'm open to ideas on how to bring those in as (presumably infrequently used) options.

ksjp

Anders Brandt wrote:
Hello
 
I would like to probe the temperature of the WG on using DAOs to
support P2P.
 
The building and home application spaces (and maybe others) have
a few clearly defined requirements.
It is not obvious to me how the current RPL proposal (cRPLp) can
satisfy those requirements:
 
 
In both cases it is the worst case scenario that hurts:
 
 
P2P routing inside the PAN
==========================
cRPLp has no way of routing inside the PAN if you need more than
one repeater. cRPLp has to go all the way to the top (maybe 4 hops up)
and down again (maybe 4 hops down) to get just 2 hops to the side.
 
The consequence is high latency and high levels of background noise
for nodes just outside the direct radio range.
At the same time the risk of meeting a failing link is 4 times higher =>
latency may be much more than 4 times larger.
 
Latency may sound like a minor issue but it actually translates directly
into lower battery lifetime. In the above (very realistic) example,
the battery lifetime is reduced to 25% of what it should be.
 
We have lots of battery devices sending into the network:
* PIR sensors turning on lights
* Door locks sending alarms
* Door/window sensors starting chimes
* Smoke sensors triggering an alarm system
 
 
 
 
Response time
=============
The latency issue is important.
When a user (real human being) presses a light button the user expects
the light to turn on.
cRPLp proposes that nodes in the tree periodically advertises their
presence using DAOs.
The periodicity is a real beast:
Thanks to Trickle, the rate of updates in a (apparently) stable network
is low. This is good since it leaves bandwidth for data.
But it is not good if existing routes to my lamp fail and I do not get
new routes to my lamp until it decides to send out a new DAO.
My user will (with a good reason) not tolerate waiting for minutes for
the light to turn on.
 
I have met two arguments to counter this concern:
 
A1: Well, your lamp can always send a DAO when it detects a problem.
  My answer:
  True, except that my lamp does not intend to send anything
  so it will never experience any problems from its side of the network.
 
A2: Well, you can increase the DAO rate to sub-second updates.
  My answer:
  Oh no. I get a very high degree of management traffic which
  limits my available bandwidth, increases the risk of collisions and
  even run the risk of violating EU legislation requiring me to only
  transmit in less than 1% of the time:
  http://focus.ti.com/lit/an/swra048/swra048.pdf
 868 - 868.6 MHz: <1%
 
  Reactiveness is hard to achieve via polling.
 
 
 
If you agree that this seems to be critical issues please raise your
voice on the list.
 
Going forward
=============
 
We need some reactive mechanism to reach lamps before the user decides
to sue our companies.
So is this possible? I think so.

Existing commercial (non-IP) solutions are capable of re-routing quickly
if they really have to.
 
Let me try scoping the requirements to a potential solution:
(no different from the req. docs for home and building)
 
* P2P routing in any direction independent of the tree.
 
* On-demand P2P route discovery if requested by a real-time critical app.
 Data collection apps may be able to just wait for the next DAO update.
 
* Limited range of discovery mechanism: max 4 repeaters.
  A TTL field may limit the scope of the repeaters.
 
* Suboptimal routing and traffic bursts are accepted in exchange
  for quick route repair. But only as an exception.
 
 
Just as an example, one existing home control technology uses a
(source routing) variant of AODV for quick route repair.
Nothing comes for free. The price is flooding - but not just flooding:
Managed flooding using a distributed algorithm running in all
participating nodes.
The algorithm dampens the flooding in a time, volume and range perspective.
Some similar mechanism could be built into RPL for quick route repair.
 
 
If anyone have alternative proposals, please bring it to the list.
Now is the time.
 
 
 
Thanks,
  Anders


_______________________________________________
Roll mailing 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
 
--------------020204000203090109020504-- --------------ms080002000605010300040503 Content-Type: application/x-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 GgUAoIIB0DAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMDAz MTUxODI2NDhaMCMGCSqGSIb3DQEJBDEWBBSMOqqmZFH4/ugTCVTqDz3Hp06gJTBfBgkqhkiG 9w0BCQ8xUjBQMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYI KoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgYUGCSsGAQQBgjcQBDF4MHYw YjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4x LDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhB0FYYcRpgg E7/iD53vjpAfMIGHBgsqhkiG9w0BCRACCzF4oHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoT HFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25h bCBGcmVlbWFpbCBJc3N1aW5nIENBAhB0FYYcRpggE7/iD53vjpAfMA0GCSqGSIb3DQEBAQUA BIIBAEGIlvFpzyjw8qKCTvJpIOlQscPlq2Y6sM9sAwF++rX/SkjIMMqqEJMpjGKwMnAB9H/O iz+crdoNCzwhs6eadwE0OuO0XoETLVShbupmeQ69p36aE9R79I0Py5h0GafYnLeuUQl+JVsE bu/Yo1r/S7QOy0aPjcplJHYcLogmGtQGVIyCXgVMn9hRcFZ8t7PDw44tuQTsDl3tYAtvIm4B IW99ltjpRshf2WwxYDGmJLoXON18tIGQ8uQFzWQo3Y8zTqcfoDEO39bFuZ3NYmTbL+vJ+wRc oDQK0uDngJzziEZqDjdHl+U0FMJ9CqHgpBHQW2UdMRBWjMFT/o+V4SGb5C0AAAAAAAA= --------------ms080002000605010300040503-- From gnawali@cs.stanford.edu Mon Mar 15 12:47: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 524C83A6900 for ; Mon, 15 Mar 2010 12:47:15 -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 r1WacBH0N6Rd for ; Mon, 15 Mar 2010 12:47:14 -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 84F973A677E for ; Mon, 15 Mar 2010 12:47:14 -0700 (PDT) Received: from mail-qy0-f197.google.com ([209.85.221.197]) by cs-smtp-3.Stanford.EDU with esmtpsa (TLSv1:RC4-MD5:128) (Exim 4.60) (envelope-from ) id 1NrGG2-0004tE-18 for roll@ietf.org; Mon, 15 Mar 2010 12:47:22 -0700 Received: by qyk35 with SMTP id 35so2765202qyk.18 for ; Mon, 15 Mar 2010 12:47:21 -0700 (PDT) MIME-Version: 1.0 Received: by 10.224.42.8 with SMTP id q8mr656771qae.290.1268682441093; Mon, 15 Mar 2010 12:47:21 -0700 (PDT) In-Reply-To: <8516D84F-92D7-4FC6-BC7B-B434722DEBED@cs.stanford.edu> References: <20100226011704.C9E4D28C140@core3.amsl.com> <6CE3E5D3-DAEE-45E7-9C16-1260BD345A46@cs.stanford.edu> <4B9579EB.6040604@ieee.org> <878wa162qe.fsf@kelsey-ws.hq.ember.com> <4B965F2B.1090206@ieee.org> <8516D84F-92D7-4FC6-BC7B-B434722DEBED@cs.stanford.edu> From: Omprakash Gnawali Date: Mon, 15 Mar 2010 12:47:01 -0700 Message-ID: To: Philip Levis Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Scan-Signature: 10362da83454c0a30f3f1339bddfed40 Cc: "roll@ietf.org" , phoebus@ieee.org Subject: Re: [Roll] Fwd: New Version Notification for draft-levis-roll-trickle-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, 15 Mar 2010 19:47:15 -0000 On Mon, Mar 15, 2010 at 9:08 AM, Philip Levis wrote: ... >> It is not clear if Imax should be specified as a function of the worst >> case link layer latency. > > You mean Imin? What should it be specified in terms of? The text does not say Imax should also be specified in terms of link layer latency. It only talks about Imin in relation to worst case latency. I was wondering if that was intentional or something to be fixed in the next version. >> "Worst case latency is the time until the first >> =A0 =A0 =A0link-layer transmission of the frame assuming an idle channel >> =A0 =A0 =A0(does not include backoff, virtual carrier sense, etc.). >> " >> >> Does it include preamble, etc.? >> >> Are we talking about only the function of data rate (transmisstion) ? > > Jonathan Hui also brought this up. I agree that the current wording is su= boptimal. > > The basic goal is to have some notion of how long a packet can take. My o= riginal intention was to include preamble and backoff times, but not conges= tion or retransmissions. E.g., if the channel is clear and the packet is de= livered successfully, how long could it take? This seemed like the most use= ful measure to me, but I could be wrong. Do you think there's a better one? One approach would be to abstract everything that the link layer does and just look at the maximum delay between packet hand off to the link layer and final success/failure notification/status determination for that packet. This would include retx, channel access times, node wake up times, and everything else. One advantage of this approach is two DIOs with interval larger than this time at the transmitter will maintain that time difference at the receiver. Otherwise, the timing is less useful in this type of reasoning. If the DIOs are all broadcast, we don't need to worry about retx. - om_p From gnawali@cs.stanford.edu Mon Mar 15 12:52: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 775593A6804 for ; Mon, 15 Mar 2010 12:52:50 -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 bz93lSo35+-P for ; Mon, 15 Mar 2010 12:52:49 -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 97DD93A6900 for ; Mon, 15 Mar 2010 12:52:49 -0700 (PDT) Received: from mail-qy0-f197.google.com ([209.85.221.197]) by cs-smtp-2.Stanford.EDU with esmtpsa (TLSv1:RC4-MD5:128) (Exim 4.60) (envelope-from ) id 1NrGLR-0006Sb-66 for roll@ietf.org; Mon, 15 Mar 2010 12:52:57 -0700 Received: by qyk35 with SMTP id 35so2768877qyk.18 for ; Mon, 15 Mar 2010 12:52:56 -0700 (PDT) MIME-Version: 1.0 Received: by 10.224.26.224 with SMTP id f32mr1225330qac.292.1268682776083; Mon, 15 Mar 2010 12:52:56 -0700 (PDT) In-Reply-To: References: <20100226011704.C9E4D28C140@core3.amsl.com> <6CE3E5D3-DAEE-45E7-9C16-1260BD345A46@cs.stanford.edu> <4B9579EB.6040604@ieee.org> <878wa162qe.fsf@kelsey-ws.hq.ember.com> <4B965F2B.1090206@ieee.org> <8516D84F-92D7-4FC6-BC7B-B434722DEBED@cs.stanford.edu> From: Omprakash Gnawali Date: Mon, 15 Mar 2010 12:52:36 -0700 Message-ID: To: Philip Levis Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Scan-Signature: f69c4e6b4bf914f22ae37cd490358bf0 Cc: "roll@ietf.org" , phoebus@ieee.org Subject: Re: [Roll] Fwd: New Version Notification for draft-levis-roll-trickle-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, 15 Mar 2010 19:52:50 -0000 On Mon, Mar 15, 2010 at 12:47 PM, Omprakash Gnawali wrote: > On Mon, Mar 15, 2010 at 9:08 AM, Philip Levis wrote= : > ... >>> It is not clear if Imax should be specified as a function of the worst >>> case link layer latency. >> >> You mean Imin? What should it be specified in terms of? > > The text does not say Imax should also be specified in terms of link > layer latency. It only talks about Imin in relation to worst case > latency. I was wondering if that was intentional or something to be > fixed in the next version. > >>> "Worst case latency is the time until the first >>> =A0 =A0 =A0link-layer transmission of the frame assuming an idle channe= l >>> =A0 =A0 =A0(does not include backoff, virtual carrier sense, etc.). >>> " >>> >>> Does it include preamble, etc.? >>> >>> Are we talking about only the function of data rate (transmisstion) ? >> >> Jonathan Hui also brought this up. I agree that the current wording is s= uboptimal. >> >> The basic goal is to have some notion of how long a packet can take. My = original intention was to include preamble and backoff times, but not conge= stion or retransmissions. E.g., if the channel is clear and the packet is d= elivered successfully, how long could it take? This seemed like the most us= eful measure to me, but I could be wrong. Do you think there's a better one= ? > > One approach would be to abstract everything that the link layer does > and just look at the maximum delay between packet hand off to the link > layer and final success/failure notification/status determination for > that packet. This would include retx, channel access times, node wake > up times, and everything else. One advantage of this approach is two > DIOs with interval larger than this time at the transmitter will > maintain that time difference at the receiver. Otherwise, the timing One correction - the DIOs will be separated in time, that is all that can be guaranteed with this approach. - om_p From A.Ramrekha@kingston.ac.uk Mon Mar 15 11:32: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 C365B3A6A30; Mon, 15 Mar 2010 11:32:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.523 X-Spam-Level: X-Spam-Status: No, score=-6.523 tagged_above=-999 required=5 tests=[AWL=0.076, 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 SW2EvjX5aV1y; Mon, 15 Mar 2010 11:32:22 -0700 (PDT) Received: from mail56.messagelabs.com (mail56.messagelabs.com [193.109.254.67]) by core3.amsl.com (Postfix) with ESMTP id 5E9C13A6B63; Mon, 15 Mar 2010 11:32:08 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: A.Ramrekha@kingston.ac.uk X-Msg-Ref: server-3.tower-56.messagelabs.com!1268677933!40909775!1 X-StarScan-Version: 6.2.4; banners=kingston.ac.uk,-,- X-Originating-IP: [141.241.2.32] Received: (qmail 17076 invoked from network); 15 Mar 2010 18:32:14 -0000 Received: from kuexim5.king.ac.uk (HELO kuexim5.king.ac.uk) (141.241.2.32) by server-3.tower-56.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 15 Mar 2010 18:32:14 -0000 Received: from kucahtkh02.king.ac.uk ([141.241.72.36] helo=KUCAHTKH02.kuds.kingston.ac.uk) by kuexim5.king.ac.uk with esmtp (Exim 4.69) (envelope-from ) id 1NrF5O-0003I5-O2; Mon, 15 Mar 2010 18:32:18 +0000 Received: from KUMBX.kuds.kingston.ac.uk ([141.241.71.40]) by KUCAHTKH02 ([141.241.72.36]) with mapi; Mon, 15 Mar 2010 18:31:43 +0000 From: "Ramrekha, Arvind" To: Henning Rogge , "roll@ietf.org" Date: Mon, 15 Mar 2010 18:31:43 +0000 Thread-Topic: [manet] [Roll] Fwd: New Version Notification for draft-gnawali-roll-etxof-00 Thread-Index: AcrEY00Kn3zaP8DCTaOKSqi0ZVNH4gACHkjV Message-ID: <31FA0235108C2F43A69AEC26D34E28010172D396CFBF@KUMBX.kuds.kingston.ac.uk> References: <20100223045634.C3F6328C44F@core3.amsl.com> <201003151007.05075.henning.rogge@fkie.fraunhofer.de> <9DD3490C-638B-4B03-ACFF-B8B9997FE873@cs.stanford.edu>, <201003151814.08275.hrogge@googlemail.com> In-Reply-To: <201003151814.08275.hrogge@googlemail.com> Accept-Language: en-US, en-GB Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Mon, 15 Mar 2010 13:14:31 -0700 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: Mon, 15 Mar 2010 18:32:23 -0000 > Absolutely. But honestly, I'm less worried about the software engineerin= g > of network protocols than their actual efficiency. OSes can evolve to > support new interfaces. -We should worry about both. If we ignore the software side of the problem= we -might design stuff that does not run on most platforms. I assume that by network protocol efficiency we are talking about efficien= t routes which are summation of values for link qualities. But what is "go= od quality". I understand that we want something that is better than hop c= ount but am I wrong when I say that "link quality" or rather "route qualit= y" is relative and depends on the traffic we use? If route quality is actu= ally relative then implementing a fix LTX metric is not a good idea. I und= erstand that using packet loss is an easy way to implement the LTX metric = estimation but shouldn't we also look at other metrics that could be more = important in cases of multimedia streaming etc? =20 Arvind. ________________________________________ From: manet-bounces@ietf.org [manet-bounces@ietf.org] On Behalf Of Henning= Rogge [hrogge@googlemail.com] Sent: 15 March 2010 17:14 To: roll@ietf.org Cc: MANET IETF; Thomas Heide Clausen Subject: Re: [manet] [Roll] Fwd: New Version Notification for draft-gnaw= ali-roll-etxof-00 Am Montag 15 M=E4rz 2010 17:18:53 schrieb Philip Levis: > > If you can access layer 1/2 data this is a good idea. But the code wil= l > > become OS or even hardware specific. > > Absolutely. But honestly, I'm less worried about the software engineerin= g > of network protocols than their actual efficiency. OSes can evolve to > support new interfaces. We should worry about both. If we ignore the software side of the problem = we might design stuff that does not run on most platforms. > This also gets back to my original point: separating the metric and its > computation is valuable. Implementations can use this kind of informatio= n > when it's available, but when it's not they can use other techniques. > > >> and EWMA rather than a fixed window size. > > > > EWMA is not always better than a fixed window. > > In theory, no. In practice, I think it is. By practice, I mean "on > unlicensed ISM bands." 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 regu= lar interval. > 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 wi= th > 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 t= he network. That can be a desaster (depending on protocol and network topolog= y). Henning Rogge This email has been scanned for all viruses by the MessageLabs Email Security System. This email has been scanned for all viruses by the MessageLabs Email Security System. From phoebus@ieee.org Mon Mar 15 13:37: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 824313A6B89 for ; Mon, 15 Mar 2010 13:37:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.32 X-Spam-Level: X-Spam-Status: No, score=-105.32 tagged_above=-999 required=5 tests=[AWL=-0.929, BAYES_20=-0.74, 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 rH6Fauzfracc for ; Mon, 15 Mar 2010 13:37:28 -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 00DD53A6C16 for ; Mon, 15 Mar 2010 13:37:28 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp-2.sys.kth.se (Postfix) with ESMTP id ACFDD14C146; Mon, 15 Mar 2010 21:37:04 +0100 (CET) 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 PfYv2swVvh5I; Mon, 15 Mar 2010 21:37:02 +0100 (CET) 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 62F0514C12E; Mon, 15 Mar 2010 21:37:01 +0100 (CET) Message-ID: <4B9E9A6C.70601@ieee.org> Date: Mon, 15 Mar 2010 21:37:00 +0100 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.8) Gecko/20100227 Thunderbird/3.0.3 MIME-Version: 1.0 To: Philip Levis References: <20100226011704.C9E4D28C140@core3.amsl.com> <6CE3E5D3-DAEE-45E7-9C16-1260BD345A46@cs.stanford.edu> <4B9579EB.6040604@ieee.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: ROLL WG Subject: Re: [Roll] Fwd: New Version Notification for draft-levis-roll-trickle-00 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: Mon, 15 Mar 2010 20:37:31 -0000 Hey Phil, Glad to see you're back. See comments below. -- Phoebus Chen Postdoctoral Researcher Automatic Control Lab, KTH (Royal Institute of Technology) http://www.ee.kth.se/~phoebus On 3/15/10 6:38 AM, Philip Levis wrote: > > On Mar 8, 2010, at 2:27 PM, Phoebus Chen wrote: > >> Phil, Omprakash, and Joakim, >> >> Did you find any resolution to Trickle's load balancing problem that >> was discussed in this previous thread? >> http://www.ietf.org/mail-archive/web/roll/current/msg02707.html > > We've been discussing it with Joakim. > > The short answer is that these are contrived edge cases. They can happen > in practice, but are *very* unlikely and the next Trickle reset will > clear them. So while we do want to solve them for the sake of > completeness, (Joakim has been evaluating some ideas and showing me and > Om the results), I don't think they're a significant issue in real > situations. > >> This is related to the concern I raised in a previous email >> http://www.ietf.org/mail-archive/web/roll/current/msg02723.html >> regarding how Trickle affects the selection of parents (or how the >> rules on how to defer joining a DODAG may affect Trickle's operation, >> point #2 I made in the email thread). > > This is a good point -- the Trickle draft tries to address this, by > noting a protocol should specify what constitutes a redundant transmission. > >> I am concerned that the redundancy suppression mechanisms in Trickle >> will suppress the DIO advertisements of some of the potential parents >> of a node, and the node will end up choosing a bad parent (or bad >> parents). > > Well, do you mean bad in terms of Rank, or ba > >> >> Let me illustrate with an example: >> ---------------------------------- >> Assume that "DIOs that advertise the same rank" are considered >> redundant, as suggested by (draft-ietf-roll-rpl-06, pg. 38, Section >> 5.3.5.1.1). >> >> Nodes A, B, and C are waiting to connect to the DODAG. Node A connects >> to the DODAG first, starts it's Trickle timer, and advertises its DIO, >> but C misses the message (maybe a fluke, because an 802.11 access >> point happened to go off nearby). After roughly I_min, Node B connects >> to the DAG (but node A is not a parent), starts it's Trickle timer, >> and advertises the same rank as A. Node B may have deferred joining >> the DODAG for I_min because it wanted to find a better parent. Now, >> node B always has a shorter interval I than node A, so it should >> always advertise its DIO before node A (since T is always within >> [I/2,I]). If the redundancy constant is set to 1, then B will always >> suppress A (until a packet is lost, but let's say this is uncommon). > > True, unless some other node suppresses B. This also assumes that B's > messages are never lost by A. RPL allows a DODAG Root to increment the > sequence number, such that Trickle timers reset in a more coherent > fashion if such problems occur. > Hmm, I'm still not fully convinced that scenarios similar to the one I described are edge cases. My point is that a rare event, such as a missed DIO advertisement, along with Trickle suppressions could throw the network into an unbalanced state with nodes not equally sharing the responsibility of sending DIO advertisements. In this respect, the load balancing in Trickle is not robust to rare events. I agree with you that packet losses may be able to reset this imbalance eventually, but I'm concerned that by the time this happens, nodes that were listening to these DIO advertisements to choose their parents will have already joined the network and committed to a rank. I don't have a firm grasp of how "suboptimal" this would be, or even if once can "bound" in a probabilistic sense how suboptimal the topology is (as measured by a metric in the OF) relative to an RPL topology where all transmissions were perfect. Also, incrementing the DODAG sequence number from the root is a heavy-handed, global approach to "reset in a more coherent fashion" the Trickle timers. You may "fix" the Trickle timers one part of the network (no lost DIOs), but "break" the Trickle timers in other parts of the network (lose DIOs where originally you did not lose them). >> >> Could you guys give your thoughts on this? > > Generally, it's possible to come up with constructed edge cases under > which Trickle acts poorly; in practice, the general messiness of > wireless networks (packet losses, etc.) means they rarely last long. > Another place where the Trickle intervals of neighboring nodes can be partially unsynchronized is in the (currently unspecified) time that nodes can defer before joining the RPL topology. You mentioned in http://www.ietf.org/mail-archive/web/roll/current/msg02710.html that load balancing is imperfect when a network is mostly synchronized but a few nodes are out of phase. I'm trying to think of how one can design a rule for nodes to defer joining the network that can guarantee with high probability that we can avoid that situation in most network deployments, and right now I don't have an answer. I hope we'll get a better understanding of how Trickle operates in RPL over time. It will help us isolate problems in RPL deployments in the future, i.e. understand which parameters were tuned wrong when the metric being optimized on the topology is far worse than expected. > Phil From Ted.Humpal@jci.com Mon Mar 15 14:00: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 7A15F3A6BED; Mon, 15 Mar 2010 14:00:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.744 X-Spam-Level: X-Spam-Status: No, score=-1.744 tagged_above=-999 required=5 tests=[AWL=-3.300, BAYES_50=0.001, HTML_MESSAGE=0.001, HTML_MIME_NO_HTML_TAG=0.097, MIME_HTML_ONLY=1.457] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rc6trBNxxD8n; Mon, 15 Mar 2010 14:00:50 -0700 (PDT) Received: from exprod8og116.obsmtp.com (exprod8og116.obsmtp.com [64.18.3.32]) by core3.amsl.com (Postfix) with ESMTP id 843053A6887; Mon, 15 Mar 2010 14:00:49 -0700 (PDT) Received: from source ([192.132.24.139]) (using SSLv3) by exprod8ob116.postini.com ([64.18.7.12]) with SMTP ID DSNKS56gBSwFa/Uv5dyQxMpdmvSwrAebhKEE@postini.com; Mon, 15 Mar 2010 14:00:57 PDT Received: from jwimkrs1.na.jci.com ([10.10.6.31]) by smtpmke02.jci.com (Lotus Domino Release 8.0.1) with ESMTP id 2010031516004040-330440 ; Mon, 15 Mar 2010 16:00:40 -0500 In-Reply-To: <6A2A459175DABE4BB11DE2026AA50A5D0170DFA9@XMB-AMS-107.cisco.com> References: <6D9687E95918C04A8B30A7D6DA805A3E01429F5F@zensys17.zensys.local> <4B9553B8.6010001@eecs.berkeley.edu> <4B98F374.4030301@gridmerge.com> <6A2A459175DABE4BB11DE2026AA50A5D0170DFA9@XMB-AMS-107.cisco.com> To: "Pascal Thubert (pthubert)" MIME-Version: 1.0 X-KeepSent: 49E7F19C:87D2D9D9-862576E7:00700505; 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, 15 Mar 2010 16:00:42 -0500 X-MIMETrack: Serialize by Router on jwimkrs1.na.jci.com/NA/Johnson_Controls at 03/15/2010 04:00:45 PM, Serialize complete at 03/15/2010 04:00:45 PM, Itemize by SMTP Server on smtpmke02.jci.com/JCI_SMTP(Release 8.0.1|February 07, 2008) at 03/15/2010 04:00:40 PM, Serialize by Router on smtpmke02.jci.com/JCI_SMTP(Release 8.0.1|February 07, 2008) at 03/15/2010 04:00:51 PM, Serialize complete at 03/15/2010 04:00:51 PM Content-Type: text/html; charset="US-ASCII" Cc: ROLL WG , roll-bounces@ietf.org Subject: Re: [Roll] P2P performance with current RPL proposal X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Mar 2010 21:00:55 -0000
Pascal

Going over your P2P proposal - I have a  fundamental question that I would like to clarify -

On  page 3 you show how a 'new P2P' DAG could be formed, with the initial transmission of a DIO message.
Included in the DIO message is the base option parameters and maybe  DIO suboption(s)
Of the defined suboptions in the version 8 of the standard - I do not see a way to include in the DIO which node
I wish to send a message to (destination)  -  - -   so as the DIO is transmitted along the network  - - -  How does a node know which DAG  it should join ?
Should a node join any DAG for some initial period - since it may be in the path, to the ultimate destination?

For instance in your example R wishes to send a message to T but T is not aware, that it will be receiving a message. When
the DIO comes along Should I join this new DAG or not?  How do I decide?

When a DIO is received by this nod (T) or any node (along the path A,D,E,F,G) - How do they determine if they should join this new DAG?
Eventually  D and E join this new DAG,  and A drops opts of the DAG.  

How does a node know how to associate a DAG to a destination address -  Is there an OCP / OF for each destination address?

Does is matter if all of the nodes have the same prefix on the LLN network?  If they all have the same prefix, which has been discussed,
then the prefix suboption for the DIO is less valuable.

How many DAGs can a LLN support?  For P2P the number of DAGs could be the number of nodes minus 1, and every node may be a member
of every DAG??

Typically every node does not need to communicate with every other node, but the design should not limit the number of P2P paths that
may be required.

Thanks

Ted







From: "Pascal Thubert (pthubert)" <pthubert@cisco.com>
To: <robert.cragie@gridmerge.com>, <Ted.Humpal@jci.com>
Cc: ROLL WG <roll@ietf.org>
Date: 03/15/2010 11:29 AM
Subject: Re: [Roll] P2P performance with current RPL proposal




HI Robert :
 
I respectfully have to disagree.
 
My understanding is that we are considering a limited set of P2P pairs, for which the specific path that we need to create might have to obey specific constraints.
So it makes sense to use an on-demand technique, probably inspired by the MANET Reactive protocols.
 
As it goes, those protocols usually use flooding for a node to locate another. Forking a DAG is just another flooding. It does not take a lot of addition to the existing DIO for a root to use RPL to build a DAG that contains one or multiple Targets as leaves, under a set of constraints expressed as an objective function. Please find attached a slideware that illustrates that.
 
Pascal
 
From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Robert Cragie
Sent: Thursday, March 11, 2010 2:43 PM
To: Ted.Humpal@jci.com
Cc: ROLL WG
Subject: Re: [Roll] P2P performance with current RPL proposal
 
I agree with Ted's comments below. Creating a DODAG for every reachable node as a root seems a very inefficient approach compared to alternative routing algorithms. I am concerned that RPL does not actually meet the original requirements in I-D.ietf-roll-building-routing-reqs, I-D.ietf-roll-home-routing-reqs, RFC5673 and RFC5548. The traffic pattern requirement for a sink node features prominently in only two of those documents. Even in this case, as Ted points out, communication is likely to be bidirectional (e.g. end-to-end acks.) therefore the DODAG approach is fundamentally asymmetric, especially if no intermediate storage is allowed for destination routes and source routing has to be used.

Also, RPL seems highly complex for what are constrained nodes in terms of memory as well as power and bandwidth. The RPL draft as it stands is 82 pages long and that doesn't include text about the objective function.

Robert

Robert Cragie (Pacific Gas & Electric)

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


Ted.Humpal@jci.com wrote:

A concern also will be how much overhead (memory space) will be required for a DODAG Root?

and based on the first question how many DODAG roots a lamp may need to be a member of?

For example in lighting  a single lamp may be a root for a single switch (1 DODAG root),  this lamp / luminaire may also
be a member of another group - -  which could be all lights on the floor (2nd DODAG root), and a third group
of all the lights in the building.  There can be many more speciality groups associated based on the building configuration.
Consider also during the installation time - how these DODAG roots will be configured?  Must I commission each device
to tell it which DODAG it must use for its Object Function?  How easy will this be to change and add in a new DODAG root
for the end user if the lighting group changes??

With respect to Jerry Martocci's - commercial building requirements - every device may need to communicate to any or
all of the end devices.  If each device must establish a DODAG for the other 499 devices in a 500 node network - How much memory
space will this require for each end device to maintain?  

Keep in mind that the end devices are very limited processor and memory wise.

Not to mention all of the network maintenance messages that would need to be transmitted to maintain all of these DODAGs.

Consider the reconvergence time when one device is turned off and it was in the middle of the majority of the 100+ DODAGS?

In many lighting and building application an application acknowledgement - must be returned {Back down the DODAG} so . . . the
requirement is not just getting to the Root - a return path must also be maintained and have a  low latency path.

Ted Humpal


From: Kris Pister <pister@eecs.berkeley.edu>
To: Anders Brandt <abr@sdesigns.dk>
Cc: ROLL WG <roll@ietf.org>
Date: 03/08/2010 01:45 PM
Subject: Re: [Roll] P2P performance with current RPL proposal

 






Anders - if we take JP's suggestion to make The Lamp a DODAG root, and take Phoebus' recommendation that we use path diversity to improve end-to-end reliability, do you see a chance of success?
In my experience, with diverse paths and order-minutes updates you get extremely high reliability.

I have no aversion to TTL-limited floods as a part of a solution either.  I'm open to ideas on how to bring those in as (presumably infrequently used) options.

ksjp

Anders Brandt wrote:
Hello
 
I would like to probe the temperature of the WG on using DAOs to
support P2P.
 
The building and home application spaces (and maybe others) have
a few clearly defined requirements.
It is not obvious to me how the current RPL proposal (cRPLp) can
satisfy those requirements:
 
 
In both cases it is the worst case scenario that hurts:
 
 
P2P routing inside the PAN
==========================
cRPLp has no way of routing inside the PAN if you need more than
one repeater. cRPLp has to go all the way to the top (maybe 4 hops up)
and down again (maybe 4 hops down) to get just 2 hops to the side.
 
The consequence is high latency and high levels of background noise
for nodes just outside the direct radio range.
At the same time the risk of meeting a failing link is 4 times higher =>
latency may be much more than 4 times larger.
 
Latency may sound like a minor issue but it actually translates directly
into lower battery lifetime. In the above (very realistic) example,
the battery lifetime is reduced to 25% of what it should be.
 
We have lots of battery devices sending into the network:
* PIR sensors turning on lights
* Door locks sending alarms
* Door/window sensors starting chimes
* Smoke sensors triggering an alarm system
 
 
 
 
Response time
=============
The latency issue is important.
When a user (real human being) presses a light button the user expects
the light to turn on.
cRPLp proposes that nodes in the tree periodically advertises their
presence using DAOs.
The periodicity is a real beast:
Thanks to Trickle, the rate of updates in a (apparently) stable network
is low. This is good since it leaves bandwidth for data.
But it is not good if existing routes to my lamp fail and I do not get
new routes to my lamp until it decides to send out a new DAO.
My user will (with a good reason) not tolerate waiting for minutes for
the light to turn on.
 
I have met two arguments to counter this concern:
 
A1: Well, your lamp can always send a DAO when it detects a problem.
 My answer:
 True, except that my lamp does not intend to send anything
 so it will never experience any problems from its side of the network.
 
A2: Well, you can increase the DAO rate to sub-second updates.
 My answer:
 Oh no. I get a very high degree of management traffic which
 limits my available bandwidth, increases the risk of collisions and
 even run the risk of violating EU legislation requiring me to only
 transmit in less than 1% of the time:
 http://focus.ti.com/lit/an/swra048/swra048.pdf
868 - 868.6 MHz: <1%
 
 Reactiveness is hard to achieve via polling.
 
 
 
If you agree that this seems to be critical issues please raise your
voice on the list.
 
Going forward
=============
 
We need some reactive mechanism to reach lamps before the user decides
to sue our companies.
So is this possible? I think so.

Existing commercial (non-IP) solutions are capable of re-routing quickly
if they really have to.
 
Let me try scoping the requirements to a potential solution:
(no different from the req. docs for home and building)
 
* P2P routing in any direction independent of the tree.
 
* On-demand P2P route discovery if requested by a real-time critical app.
Data collection apps may be able to just wait for the next DAO update.
 
* Limited range of discovery mechanism: max 4 repeaters.
 A TTL field may limit the scope of the repeaters.
 
* Suboptimal routing and traffic bursts are accepted in exchange
 for quick route repair. But only as an exception.
 
 
Just as an example, one existing home control technology uses a
(source routing) variant of AODV for quick route repair.
Nothing comes for free. The price is flooding - but not just flooding:
Managed flooding using a distributed algorithm running in all
participating nodes.
The algorithm dampens the flooding in a time, volume and range perspective.
Some similar mechanism could be built into RPL for quick route repair.
 
 
If anyone have alternative proposals, please bring it to the list.
Now is the time.
 
 
 
Thanks,
 Anders



_______________________________________________
Roll mailing 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
  [attachment "DAGPtP.pdf" deleted by Ted Humpal/CORP/Johnson_Controls] _______________________________________________
Roll mailing list
Roll@ietf.org
https://www.ietf.org/mailman/listinfo/roll

From d.sturek@att.net Mon Mar 15 14:54: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 2D5003A6BA8 for ; Mon, 15 Mar 2010 14:54:04 -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.000, 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 sJtQg-8H01Kd for ; Mon, 15 Mar 2010 14:53:47 -0700 (PDT) Received: from smtp102.sbc.mail.gq1.yahoo.com (smtp102.sbc.mail.gq1.yahoo.com [67.195.15.61]) by core3.amsl.com (Postfix) with SMTP id 275673A689A for ; Mon, 15 Mar 2010 14:53:46 -0700 (PDT) Received: (qmail 59262 invoked from network); 15 Mar 2010 21:53:51 -0000 Received: from adsl-69-224-191-23.dsl.sndg02.pacbell.net (d.sturek@69.224.191.23 with login) by smtp102.sbc.mail.gq1.yahoo.com with SMTP; 15 Mar 2010 14:53:49 -0700 PDT X-Yahoo-SMTP: fvjol_aswBAraSJvMLe2r1XTzhBhbFxY8q8c3jo- X-YMail-OSG: PDsfDiMVM1nDU__Otj4JQnArohV0ij2K1fquJ1LNT43j2qnF_1QzOLLKe9S4U2fofkSHK4iJ3s1dXUb27p375Y6q1eIkjPdIf.cfZ9DyThvISV1SyErRqxPpJxAjDXFJO.2DJXYwXSb9uU9CaB7Y7lTwmiZfLf2vCInv2HFYleFOq0Q0ACFSoqXGossPasKTibT09bnIcQsE04b7DKRg6wwIixwB7Nzw1FfhzIPeZY0QfC9kESONVWeMGjIGmk9ME5zZ2iQfDNwX44Ia.IIyRxjCiftq6h5j2sGKSozGgCNlBw7Y2w-- X-Yahoo-Newman-Property: ymail-3 From: "Don Sturek" To: "'Pascal Thubert \(pthubert\)'" , , References: <6D9687E95918C04A8B30A7D6DA805A3E01429F5F@zensys17.zensys.local> <4B9553B8.6010001@eecs.berkeley.edu> <4B98F374.4030301@gridmerge.com> <6A2A459175DABE4BB11DE2026AA50A5D0170DFA9@XMB-AMS-107.cisco.com> <01ad01cac465$9bb9da70$d32d8f50$@sturek@att.net> <6A2A459175DABE4BB11DE2026AA50A5D0170E03D@XMB-AMS-107.cisco.com> In-Reply-To: <6A2A459175DABE4BB11DE2026AA50A5D0170E03D@XMB-AMS-107.cisco.com> Date: Mon, 15 Mar 2010 14:53:43 -0700 Message-ID: <033601cac489$fbdf27b0$f39d7710$@sturek@att.net> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0337_01CAC44F.4F804FB0" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcrBIO0mcBW5di9DSESfrbyVRyBbFwDOfAKwAAIhgwAAAJmCYAAI9RJQ Content-Language: en-us Cc: 'ROLL WG' Subject: Re: [Roll] P2P performance with current RPL proposal 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, 15 Mar 2010 21:54:04 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0337_01CAC44F.4F804FB0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Pascal, I think for Smart Energy what you outlined may work. We have a lot of traffic from devices in the DAG to a single point (MP to P) but then most of that traffic has some sort of response. This means even if we use the Energy Services Interface as the DAG root, we must still route down the DAG on the responses. We don't, however, have the low latency requirements you will see in Building or Home Automation. I do think those use cases will be more difficult. Don From: Pascal Thubert (pthubert) [mailto:pthubert@cisco.com] Sent: Monday, March 15, 2010 10:55 AM To: d.sturek@att.net; robert.cragie@gridmerge.com; Ted.Humpal@jci.com Cc: ROLL WG Subject: RE: [Roll] P2P performance with current RPL proposal Hi Don : Well, in both cases my words did not convey the message I wished to convey. 1) I mean that the nodes that need to do P2P need to do so with a limited set of other nodes, as opposed to all other nodes in the network. So what you want to do is not any to any but a number of groups of 2 or more nodes that need to talk to one another 2) I mean that the path that we create might have to obey constraints, like low latency, that the generic P2MP DAG does not need. For instance, I think about a closed loop in process control. I'm not sure we disagree so far. I read your earlier mail about application role vs. network role. In that, we might have to discuss some more. Because RPL is designed to optimize P2MP and MP2P, it is not symmetrical wrt the P and the MP. The P has to be selected to match the Goal that the DAG is built to serve. Taking your example, one way of handling multiple lamps in a room can be to set them all as roots , and then coordinate them, for instance through the powerline, as discussed in section 3.2. Our we could use the on-demand approach that I just suggested. For instance, we could have each switch lookup the set of lamps by forking a DAG. With the proposal, the DAG only spans so far, and acts as a reactive route setup. The DIO contains the list of lamps, and each lamp answers with a DAO that can be fanned out. The nodes that do not see the DAO back forget about that DAG just like they would other reactive floodings. How far do we really disagree? Pascal From: Don Sturek [mailto:d.sturek@att.net] Sent: Monday, March 15, 2010 6:33 PM To: Pascal Thubert (pthubert); robert.cragie@gridmerge.com; Ted.Humpal@jci.com Cc: 'ROLL WG' Subject: RE: [Roll] P2P performance with current RPL proposal Hi Pascal, I think we have fundamental disagreement on P2P support in RPL. Here are the issues that I see: 1) "We are considering a limited set of P2P pairs" - I think most of the use cases for Building Automation and Home Automation use P2P pairs. Even Smart Energy is mostly a P2P solution (as a percentage of messages sent/received). I think to handle P2P we need to view the deployment as NOT being a limited set of P2P pairs. 2) "for which the specific path that we need to create might have to obey specific constraints." - I think there was discussion on having application server type devices (like lamps for example) become DAG roots to help solve the mapping of RPL to P2P solutions. This really won't work. Aligning the network topology by moving application devices to the role of DAG roots won't scale. Don From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Pascal Thubert (pthubert) Sent: Monday, March 15, 2010 9:24 AM To: robert.cragie@gridmerge.com; Ted.Humpal@jci.com Cc: ROLL WG Subject: Re: [Roll] P2P performance with current RPL proposal HI Robert : I respectfully have to disagree. My understanding is that we are considering a limited set of P2P pairs, for which the specific path that we need to create might have to obey specific constraints. So it makes sense to use an on-demand technique, probably inspired by the MANET Reactive protocols. As it goes, those protocols usually use flooding for a node to locate another. Forking a DAG is just another flooding. It does not take a lot of addition to the existing DIO for a root to use RPL to build a DAG that contains one or multiple Targets as leaves, under a set of constraints expressed as an objective function. Please find attached a slideware that illustrates that. Pascal From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Robert Cragie Sent: Thursday, March 11, 2010 2:43 PM To: Ted.Humpal@jci.com Cc: ROLL WG Subject: Re: [Roll] P2P performance with current RPL proposal I agree with Ted's comments below. Creating a DODAG for every reachable node as a root seems a very inefficient approach compared to alternative routing algorithms. I am concerned that RPL does not actually meet the original requirements in I-D.ietf-roll-building-routing-reqs, I-D.ietf-roll-home-routing-reqs, RFC5673 and RFC5548. The traffic pattern requirement for a sink node features prominently in only two of those documents. Even in this case, as Ted points out, communication is likely to be bidirectional (e.g. end-to-end acks.) therefore the DODAG approach is fundamentally asymmetric, especially if no intermediate storage is allowed for destination routes and source routing has to be used. Also, RPL seems highly complex for what are constrained nodes in terms of memory as well as power and bandwidth. The RPL draft as it stands is 82 pages long and that doesn't include text about the objective function. Robert Robert Cragie (Pacific Gas & Electric) Gridmerge Ltd. 89 Greenfield Crescent, Wakefield, WF4 4WA, UK +44 (0) 1924 910888 http://www.gridmerge.com Ted.Humpal@jci.com wrote: A concern also will be how much overhead (memory space) will be required for a DODAG Root? and based on the first question how many DODAG roots a lamp may need to be a member of? For example in lighting a single lamp may be a root for a single switch (1 DODAG root), this lamp / luminaire may also be a member of another group - - which could be all lights on the floor (2nd DODAG root), and a third group of all the lights in the building. There can be many more speciality groups associated based on the building configuration. Consider also during the installation time - how these DODAG roots will be configured? Must I commission each device to tell it which DODAG it must use for its Object Function? How easy will this be to change and add in a new DODAG root for the end user if the lighting group changes?? With respect to Jerry Martocci's - commercial building requirements - every device may need to communicate to any or all of the end devices. If each device must establish a DODAG for the other 499 devices in a 500 node network - How much memory space will this require for each end device to maintain? Keep in mind that the end devices are very limited processor and memory wise. Not to mention all of the network maintenance messages that would need to be transmitted to maintain all of these DODAGs. Consider the reconvergence time when one device is turned off and it was in the middle of the majority of the 100+ DODAGS? In many lighting and building application an application acknowledgement - must be returned {Back down the DODAG} so . . . the requirement is not just getting to the Root - a return path must also be maintained and have a low latency path. Ted Humpal From: Kris Pister To: Anders Brandt Cc: ROLL WG Date: 03/08/2010 01:45 PM Subject: Re: [Roll] P2P performance with current RPL proposal _____ Anders - if we take JP's suggestion to make The Lamp a DODAG root, and take Phoebus' recommendation that we use path diversity to improve end-to-end reliability, do you see a chance of success? In my experience, with diverse paths and order-minutes updates you get extremely high reliability. I have no aversion to TTL-limited floods as a part of a solution either. I'm open to ideas on how to bring those in as (presumably infrequently used) options. ksjp Anders Brandt wrote: Hello I would like to probe the temperature of the WG on using DAOs to support P2P. The building and home application spaces (and maybe others) have a few clearly defined requirements. It is not obvious to me how the current RPL proposal (cRPLp) can satisfy those requirements: In both cases it is the worst case scenario that hurts: P2P routing inside the PAN ========================== cRPLp has no way of routing inside the PAN if you need more than one repeater. cRPLp has to go all the way to the top (maybe 4 hops up) and down again (maybe 4 hops down) to get just 2 hops to the side. The consequence is high latency and high levels of background noise for nodes just outside the direct radio range. At the same time the risk of meeting a failing link is 4 times higher => latency may be much more than 4 times larger. Latency may sound like a minor issue but it actually translates directly into lower battery lifetime. In the above (very realistic) example, the battery lifetime is reduced to 25% of what it should be. We have lots of battery devices sending into the network: * PIR sensors turning on lights * Door locks sending alarms * Door/window sensors starting chimes * Smoke sensors triggering an alarm system Response time ============= The latency issue is important. When a user (real human being) presses a light button the user expects the light to turn on. cRPLp proposes that nodes in the tree periodically advertises their presence using DAOs. The periodicity is a real beast: Thanks to Trickle, the rate of updates in a (apparently) stable network is low. This is good since it leaves bandwidth for data. But it is not good if existing routes to my lamp fail and I do not get new routes to my lamp until it decides to send out a new DAO. My user will (with a good reason) not tolerate waiting for minutes for the light to turn on. I have met two arguments to counter this concern: A1: Well, your lamp can always send a DAO when it detects a problem. My answer: True, except that my lamp does not intend to send anything so it will never experience any problems from its side of the network. A2: Well, you can increase the DAO rate to sub-second updates. My answer: Oh no. I get a very high degree of management traffic which limits my available bandwidth, increases the risk of collisions and even run the risk of violating EU legislation requiring me to only transmit in less than 1% of the time: http://focus.ti.com/lit/an/swra048/swra048.pdf 868 - 868.6 MHz: <1% Reactiveness is hard to achieve via polling. If you agree that this seems to be critical issues please raise your voice on the list. Going forward ============= We need some reactive mechanism to reach lamps before the user decides to sue our companies. So is this possible? I think so. Existing commercial (non-IP) solutions are capable of re-routing quickly if they really have to. Let me try scoping the requirements to a potential solution: (no different from the req. docs for home and building) * P2P routing in any direction independent of the tree. * On-demand P2P route discovery if requested by a real-time critical app. Data collection apps may be able to just wait for the next DAO update. * Limited range of discovery mechanism: max 4 repeaters. A TTL field may limit the scope of the repeaters. * Suboptimal routing and traffic bursts are accepted in exchange for quick route repair. But only as an exception. Just as an example, one existing home control technology uses a (source routing) variant of AODV for quick route repair. Nothing comes for free. The price is flooding - but not just flooding: Managed flooding using a distributed algorithm running in all participating nodes. The algorithm dampens the flooding in a time, volume and range perspective. Some similar mechanism could be built into RPL for quick route repair. If anyone have alternative proposals, please bring it to the list. Now is the time. Thanks, Anders _____ _______________________________________________ Roll mailing 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_0337_01CAC44F.4F804FB0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Pascal,

 

I think for Smart Energy what you outlined may = work.  We have a lot of traffic from devices in the DAG to a single point (MP to P) but = then most of that traffic has some sort of response.  This means even if = we use the Energy Services Interface as the DAG root, we must still route down the = DAG on the responses.  We don’t, however, have the low latency = requirements you will see in Building or Home Automation.  I do think those use cases = will be more difficult.


Don

 

 

From: Pascal Thubert (pthubert) [mailto:pthubert@cisco.com]
Sent: Monday, March 15, 2010 10:55 AM
To: d.sturek@att.net; robert.cragie@gridmerge.com; = Ted.Humpal@jci.com
Cc: ROLL WG
Subject: RE: [Roll] P2P performance with current RPL = proposal

 

Hi Don :

 

Well, in both cases my words did not convey the message I = wished to convey.

 

1)      I mean that the nodes that need to do P2P need to do so = with a limited set of other nodes, as opposed to all other nodes in the = network. So what you want to do is not any to any but  a number of groups of 2 = or more nodes that need to talk to one another

2)      I  mean that the path that we create might have to = obey constraints, like low latency, that the generic P2MP DAG does not need. = For instance, I think about a closed loop in process = control.

 

I’m not sure we disagree so = far.

 

I read your earlier mail about application role vs. = network role. In that, we might have to discuss some more. Because RPL is = designed to optimize P2MP and MP2P, it is not symmetrical wrt the P and the MP. The = P has to be selected to match the Goal that the DAG is built to = serve.

 

Taking your example, one way of handling multiple lamps = in a room can be to set them all as roots , and then coordinate them, for = instance through the powerline, as discussed in section = 3.2.

 

Our we could use the on-demand approach that I just = suggested. For instance, we could have each switch lookup the set of lamps by = forking a DAG. With the proposal, the DAG only spans so far, and acts as a = reactive route setup. The DIO contains the list of lamps, and each lamp answers with a = DAO that can be fanned out. The nodes that do not see the DAO back forget = about that DAG just like they would other reactive = floodings.

 

How far do we really disagree?

 

Pascal

 

From: Don Sturek [mailto:d.sturek@att.net]
Sent: Monday, March 15, 2010 6:33 PM
To: Pascal Thubert (pthubert); robert.cragie@gridmerge.com; Ted.Humpal@jci.com
Cc: 'ROLL WG'
Subject: RE: [Roll] P2P performance with current RPL = proposal

 

Hi Pascal,

 

I think we have fundamental disagreement on P2P support = in RPL.  Here are the issues that I see:

1)       “We are considering a limited set of P2P = pairs” – I think most of the use cases for Building Automation and Home Automation use = P2P pairs.  Even Smart Energy is mostly a P2P solution (as a percentage = of messages sent/received).  I think to handle P2P we need to view the deployment as NOT being a limited set of P2P = pairs.

2)       “for which the specific path that we need to = create might have to obey specific constraints.” – I think there was = discussion on having application server type devices (like lamps for example) become DAG = roots to help solve the mapping of RPL to P2P solutions.  This really = won’t work.  Aligning the network topology by moving application devices = to the role of DAG roots won’t scale.

Don

 

From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Pascal Thubert = (pthubert)
Sent: Monday, March 15, 2010 9:24 AM
To: robert.cragie@gridmerge.com; Ted.Humpal@jci.com
Cc: ROLL WG
Subject: Re: [Roll] P2P performance with current RPL = proposal

 

HI Robert :

 

I respectfully have to disagree.

 

My understanding is that we are considering a limited set = of P2P pairs, for which the specific path that we need to create might have to = obey specific constraints.

So it makes sense to use an on-demand technique, probably inspired by the MANET Reactive protocols.

 

As it goes, those protocols usually use flooding for a = node to locate another. Forking a DAG is just another flooding. It does not take = a lot of addition to the existing DIO for a root to use RPL to build a DAG = that contains one or multiple Targets as leaves, under a set of constraints = expressed as an objective function. Please find attached a slideware that = illustrates that.

 

Pascal

 

From: = roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Robert Cragie
Sent: Thursday, March 11, 2010 2:43 PM
To: Ted.Humpal@jci.com
Cc: ROLL WG
Subject: Re: [Roll] P2P performance with current RPL = proposal

 

I agree with Ted's comments below. Creating a DODAG for every reachable = node as a root seems a very inefficient approach compared to alternative routing algorithms. I am concerned that RPL does not actually meet the original requirements in I-D.ietf-roll-building-routing-reqs, I-D.ietf-roll-home-routing-reqs, RFC5673 and RFC5548. The traffic = pattern requirement for a sink node features prominently in only two of those documents. Even in this case, as Ted points out, communication is likely = to be bidirectional (e.g. end-to-end acks.) therefore the DODAG approach is fundamentally asymmetric, especially if no intermediate storage is = allowed for destination routes and source routing has to be used.

Also, RPL seems highly complex for what are constrained nodes in terms = of memory as well as power and bandwidth. The RPL draft as it stands is 82 = pages long and that doesn't include text about the objective function.

Robert

Robert Cragie (Pacific Gas & = Electric)

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



Ted.Humpal@jci.com wrote: =


A concern also will be how much overhead (memory space) will be required = for a DODAG Root?

and based on the first question how many DODAG roots a lamp may need to be a = member of?

For example in lighting  a single lamp may be a root for a single = switch (1 DODAG root),  this lamp / luminaire may also =
be a member of another group - -  which could be all lights on the = floor (2nd DODAG root), and a third group
of all the lights in the building.  There can be many more speciality = groups associated based on the building configuration. =
Consider also during the installation time - how these DODAG roots will be = configured?  Must I commission each device
to tell it which DODAG it must use for its Object Function?  How easy = will this be to change and add in a new DODAG root =
for the end user if the lighting group changes??

With respect to Jerry Martocci's - commercial building requirements - every = device may need to communicate to any or
all of the end devices.  If each device must establish a DODAG for the = other 499 devices in a 500 node network - How much memory
space will this require for each end device to maintain?  

Keep in mind that the end devices are very limited processor and memory = wise.

Not to mention all of the network maintenance messages that would need to be transmitted to maintain all of these DODAGs.

Consider the reconvergence time when one device is turned off and it was in the = middle of the majority of the 100+ DODAGS?

In many lighting and building application an application acknowledgement - = must be returned {Back down the DODAG} so . . . the
requirement is not just getting to the Root - a return path must also be maintained = and have a  low latency path.

Ted Humpal

From:

Kris Pister <pister@eecs.berkeley.edu>=

To:

Anders Brandt <abr@sdesigns.dk> =

Cc:

ROLL WG <roll@ietf.org> =

Date:

03/08/2010 01:45 PM

Subject:

Re: [Roll] P2P performance with current RPL proposal

 




Anders - if we take JP's suggestion to make The Lamp a DODAG root, and = take Phoebus' recommendation that we use path diversity to improve end-to-end = reliability, do you see a chance of success?
In my experience, with diverse paths and order-minutes updates you get extremely high reliability.

I have no aversion to TTL-limited floods as a part of a solution either.  I'm open to ideas on how to bring those in as (presumably = infrequently used) options.

ksjp

Anders Brandt wrote:
Hello
 
I = would like to probe the temperature of the WG on using DAOs to
support P2P.
 
The = building and home application spaces (and maybe others) have
a = few clearly defined requirements.
It = is not obvious to me how the current RPL proposal (cRPLp) can
satisfy those requirements:
 
 
In = both cases it is the worst case scenario that hurts:
 
 
P2P = routing inside the PAN
=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
cRPLp has no way of routing inside the PAN if you need more than
one = repeater. cRPLp has to go all the way to the top (maybe 4 hops up)
and = down again (maybe 4 hops down) to get just 2 hops to the side.
 
The consequence is high latency and high levels of background noise
for nodes just outside the direct radio range. =
At = the same time the risk of meeting a failing link is 4 times higher = =3D>
latency may be much more than 4 times larger.
 
Latency may sound like a minor issue but it actually translates directly
into lower battery lifetime. In the above (very realistic) = example,
the = battery lifetime is reduced to 25% of what it should be. =
 
We = have lots of battery devices sending into the network:
* = PIR sensors turning on lights
* = Door locks sending alarms
* = Door/window sensors starting chimes
* = Smoke sensors triggering an alarm system
 
 
 
 
Response time
=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D
The = latency issue is important.
When a user (real human being) presses a light button the user expects
the = light to turn on.
cRPLp proposes that nodes in the tree periodically advertises their
presence using DAOs.
The periodicity is a real beast:
Thanks to Trickle, the rate of updates in a (apparently) stable network
is low. This is good since it leaves bandwidth for data.
But = it is not good if existing routes to my lamp fail and I do not get
new = routes to my lamp until it decides to send out a new DAO. =
My = user will (with a good reason) not tolerate waiting for minutes for
the = light to turn on.
 
I = have met two arguments to counter this concern:
 
A1: = Well, your lamp can always send a DAO when it detects a problem.
  My answer:
  True, except that my lamp does not intend to send anything
  so it will never experience any problems from its side of the = network.
 
A2: = Well, you can increase the DAO rate to sub-second updates. =
  My answer:
  Oh no. I get a very high degree = of management traffic which
  limits my available bandwidth, increases the risk of collisions and
  even run the risk of violating EU legislation requiring me to = only
  transmit in less than 1% of the time:
  http://focus.ti.com/lit/an/= swra048/swra048.pdf
 868 - 868.6 MHz: <1%
 
  Reactiveness is hard to achieve via polling.
 
 
 
If = you agree that this seems to be critical issues please raise your
voice on the list.
 
Going forward
=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D
 
We = need some reactive mechanism to reach lamps before the user decides
to = sue our companies.
So = is this possible? I think so.

Existing commercial (non-IP) solutions are capable of re-routing = quickly
if = they really have to.
 
Let = me try scoping the requirements to a potential solution: =
(no = different from the req. docs for home and building)
 
* = P2P routing in any direction independent of the tree.
 
* = On-demand P2P route discovery if requested by a real-time critical app.
 Data collection apps may be able to just wait for the next DAO = update.
 
* = Limited range of discovery mechanism: max 4 repeaters. =
  A TTL field may limit the scope of the repeaters.
 
* = Suboptimal routing and traffic bursts are accepted in exchange
  for quick route repair. But only as an exception. =
 
 
Just as an example, one existing home control technology uses a
(source routing) variant of AODV for quick route repair.
Nothing comes for free. The price is flooding - but not just flooding:
Managed flooding using a distributed algorithm running in all
participating nodes.
The = algorithm dampens the flooding in a time, volume and range perspective. =
Some similar mechanism could be built into RPL for quick route repair.
 
 
If = anyone have alternative proposals, please bring it to the list.
Now = is the time.
 
 
 
Thanks,
  Anders


______________________________________________= _
Roll mailing = 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_0337_01CAC44F.4F804FB0-- From mischa.dohler@cttc.es Mon Mar 15 15:18: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 94B713A67E6 for ; Mon, 15 Mar 2010 15:18:43 -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 Lz6gRy62RBWF for ; Mon, 15 Mar 2010 15:18:42 -0700 (PDT) Received: from aquila.cttc.es (aquila.cttc.es [84.88.62.230]) by core3.amsl.com (Postfix) with ESMTP id 93B673A69F8 for ; Mon, 15 Mar 2010 15:18:31 -0700 (PDT) Received: from leo (postfix@leo.cttc.es [84.88.62.208]) by aquila.cttc.es (8.14.3/8.14.3/Debian-9ubuntu1) with ESMTP id o2FME0Cq010917 for ; Mon, 15 Mar 2010 23:14:01 +0100 Received: from [127.0.0.1] (166.Red-88-3-146.dynamicIP.rima-tde.net [88.3.146.166]) by leo (Postfix) with ESMTP id 89FE010C31E for ; Mon, 15 Mar 2010 23:18:06 +0100 (CET) Message-ID: <4B9EB1E7.1060700@cttc.es> Date: Mon, 15 Mar 2010 23:17:11 +0100 From: Mischa Dohler User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) 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 100315-0, 15/03/2010), Outbound message X-Antivirus-Status: Clean X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (leo); Mon, 15 Mar 2010 23:18:09 +0100 (CET) X-Scanned-By: MIMEDefang 2.67 on 84.88.62.230 Subject: [Roll] video over embedded 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: Mon, 15 Mar 2010 22:18:43 -0000 A slightly off-track but still related topic: Has anybody on the list ever researched or experimented with video over wireless sensor networks? If so, would you please be so kind and contact me directly? Thanks, Mischa. From prvs=684a899bb=mukul@uwm.edu Mon Mar 15 18:55: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 6C4283A6A43 for ; Mon, 15 Mar 2010 18:55:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.4 X-Spam-Level: X-Spam-Status: No, score=-2.4 tagged_above=-999 required=5 tests=[AWL=0.199, 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 B3XWjCS9qSFH for ; Mon, 15 Mar 2010 18:55:15 -0700 (PDT) Received: from ip1mta.uwm.edu (ip1mta.uwm.edu [129.89.7.18]) by core3.amsl.com (Postfix) with ESMTP id 215823A6A29 for ; Mon, 15 Mar 2010 18:55:15 -0700 (PDT) Received: from mta02.pantherlink.uwm.edu ([129.89.7.82]) by ip1mta.uwm.edu with ESMTP; 15 Mar 2010 20:55:22 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by mta02.pantherlink.uwm.edu (Postfix) with ESMTP id 68E142C3800E for ; Mon, 15 Mar 2010 20:55:22 -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 YdOWNXaqLA0d for ; Mon, 15 Mar 2010 20:55:21 -0500 (CDT) Received: from mail02.pantherlink.uwm.edu (mail02.pantherlink.uwm.edu [129.89.7.86]) by mta02.pantherlink.uwm.edu (Postfix) with ESMTP id CAF3F2C3800D for ; Mon, 15 Mar 2010 20:55:21 -0500 (CDT) Date: Mon, 15 Mar 2010 20:55:21 -0500 (CDT) From: Mukul Goyal To: roll Message-ID: <1143612538.6122571268704521770.JavaMail.root@mail02.pantherlink.uwm.edu> In-Reply-To: <1809118198.6000821268686115313.JavaMail.root@mail02.pantherlink.uwm.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Originating-IP: [129.89.7.92] X-Mailer: Zimbra 5.0.22_GA_3210.RHEL4_64 (ZimbraWebClient - [unknown] (Win)/5.0.22_GA_3210.RHEL4_64) X-Authenticated-User: mukul@uwm.edu Subject: [Roll] Fwd: P2P performance with current RPL proposal X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Mar 2010 01:56:25 -0000 Forwarding the message again as the original could not get posted on the li= st. Thanks Mukul ----- Forwarded Message ----- From: "Mukul Goyal" To: "Pascal Thubert (pthubert)" Cc: "ROLL WG" , "robert cragie" , "Ted Humpal" Sent: Monday, March 15, 2010 12:56:44 PM GMT -06:00 US/Canada Central Subject: Re: [Roll] P2P performance with current RPL proposal Hi Pascal I am glad that we are moving in right direction FINALLY. However, I have so= me concerns with the scheme you proposed (unless I did not understand the s= cheme correctly): 1. A node/router in the middle may need to maintain state for multiple DAGs= that lead to the same destination. Consider the situation where 5 nearby n= odes need to find route to the same destination D. As per your scheme, each= node would form its own DAG towards the destination D and the nodes in the= middle would need to maintain state about all 5 DAGs. This seems wasteful.= You may argue that this is a fit case for these 5 nodes to belong to a sin= gle DAG rooted at D. But the problem is that D does not know that it is a d= estination for these 5 nodes. So, in general, I see a scalability problem a= ssociated with the use of DAGs for P2P routing. A simple DV approach, where= the nodes maintain information about destinations (rather than DAGs), seem= s to avoid this scalability problem. 2. So, in your scheme, the nodes timeout the state they have for a DAG. Thi= s means that a node that does not belong to the actual route taken by the p= ackets would end up timing out its state for this DAG. This is ok unless th= is node is part of an obvious backup route and should have maintained infor= mation about this DAG. It would be good to use the "routing interest" conce= pt in this situation. As per this concept, each node maintains a "routing i= nterest" in a particular DAG (or destination). The routing interest is a me= tric between 0 and 1. If a node is actively sending packets along the DAG, = its routing interest would be 1. Otherwise, the routing interest would be x= *max(routing interest of its nbrs), where x is a fraction. A node may delet= e state about a DAG/destination if its routing interest in that dag/destina= tion drops below a threshold. The routing interest concept would allow node= s "around' the actual path to maintain state about this dag while other nod= es can delete this state after initial route discovery. Thanks Mukul =20 ----- Original Message ----- From: "Pascal Thubert (pthubert)" To: "robert cragie" , "Ted Humpal" Cc: "ROLL WG" Sent: Monday, March 15, 2010 11:24:01 AM GMT -06:00 US/Canada Central Subject: Re: [Roll] P2P performance with current RPL proposal HI Robert :=20 =20 I respectfully have to disagree.=20 =20 My understanding is that we are considering a limited set of P2P pairs, for= which the specific path that we need to create might have to obey specific= constraints.=20 So it makes sense to use an on-demand technique, probably inspired by the M= ANET Reactive protocols.=20 =20 As it goes, those protocols usually use flooding for a node to locate anoth= er. Forking a DAG is just another flooding. It does not take a lot of addit= ion to the existing DIO for a root to use RPL to build a DAG that contains = one or multiple Targets as leaves, under a set of constraints expressed as = an objective function. Please find attached a slideware that illustrates th= at.=20 =20 Pascal=20 =20 From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Rob= ert Cragie=20 Sent: Thursday, March 11, 2010 2:43 PM=20 To: Ted.Humpal@jci.com=20 Cc: ROLL WG=20 Subject: Re: [Roll] P2P performance with current RPL proposal=20 =20 I agree with Ted's comments below. Creating a DODAG for every reachable nod= e as a root seems a very inefficient approach compared to alternative routi= ng algorithms. I am concerned that RPL does not actually meet the original = requirements in I-D.ietf-roll-building-routing-reqs, I-D.ietf-roll-home-rou= ting-reqs, RFC5673 and RFC5548. The traffic pattern requirement for a sink = node features prominently in only two of those documents. Even in this case= , as Ted points out, communication is likely to be bidirectional (e.g. end-= to-end acks.) therefore the DODAG approach is fundamentally asymmetric, esp= ecially if no intermediate storage is allowed for destination routes and so= urce routing has to be used.=20 Also, RPL seems highly complex for what are constrained nodes in terms of m= emory as well as power and bandwidth. The RPL draft as it stands is 82 page= s long and that doesn't include text about the objective function.=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 Ted.Humpal@jci.com wrote:=20 A concern also will be how much overhead (memory space) will be required fo= r a DODAG Root?=20 and based on the first question how many DODAG roots a lamp may need to be = a member of?=20 For example in lighting a single lamp may be a root for a single switch (1= DODAG root), this lamp / luminaire may also=20 be a member of another group - - which could be all lights on the floor (2= nd DODAG root), and a third group=20 of all the lights in the building. There can be many more speciality group= s associated based on the building configuration.=20 Consider also during the installation time - how these DODAG roots will be = configured? Must I commission each device=20 to tell it which DODAG it must use for its Object Function? How easy will = this be to change and add in a new DODAG root=20 for the end user if the lighting group changes??=20 With respect to Jerry Martocci's - commercial building requirements - every= device may need to communicate to any or=20 all of the end devices. If each device must establish a DODAG for the othe= r 499 devices in a 500 node network - How much memory=20 space will this require for each end device to maintain? =20 Keep in mind that the end devices are very limited processor and memory wis= e.=20 Not to mention all of the network maintenance messages that would need to b= e transmitted to maintain all of these DODAGs.=20 Consider the reconvergence time when one device is turned off and it was in= the middle of the majority of the 100+ DODAGS?=20 In many lighting and building application an application acknowledgement - = must be returned {Back down the DODAG} so . . . the=20 requirement is not just getting to the Root - a return path must also be ma= intained and have a low latency path.=20 Ted Humpal=20 From: =20 Kris Pister =20 To: =20 Anders Brandt =20 Cc: =20 ROLL WG =20 Date: =20 03/08/2010 01:45 PM=20 Subject: =20 Re: [Roll] P2P performance with current RPL proposal=20 =20 Anders - if we take JP's suggestion to make The Lamp a DODAG root, and take= Phoebus' recommendation that we use path diversity to improve end-to-end r= eliability, do you see a chance of success?=20 In my experience, with diverse paths and order-minutes updates you get extr= emely high reliability.=20 I have no aversion to TTL-limited floods as a part of a solution either. I= 'm open to ideas on how to bring those in as (presumably infrequently used)= options.=20 ksjp=20 Anders Brandt wrote:=20 Hello=20 =20 I would like to probe the temperature of the WG on using DAOs to=20 support P2P.=20 =20 The building and home application spaces (and maybe others) have=20 a few clearly defined requirements.=20 It is not obvious to me how the current RPL proposal (cRPLp) can=20 satisfy those requirements:=20 =20 =20 In both cases it is the worst case scenario that hurts:=20 =20 =20 P2P routing inside the PAN=20 =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=20 cRPLp has no way of routing inside the PAN if you need more than=20 one repeater. cRPLp has to go all the way to the top (maybe 4 hops up)=20 and down again (maybe 4 hops down) to get just 2 hops to the side.=20 =20 The consequence is high latency and high levels of background noise=20 for nodes just outside the direct radio range.=20 At the same time the risk of meeting a failing link is 4 times higher =3D>= =20 latency may be much more than 4 times larger.=20 =20 Latency may sound like a minor issue but it actually translates directly=20 into lower battery lifetime. In the above (very realistic) example,=20 the battery lifetime is reduced to 25% of what it should be.=20 =20 We have lots of battery devices sending into the network:=20 * PIR sensors turning on lights=20 * Door locks sending alarms=20 * Door/window sensors starting chimes=20 * Smoke sensors triggering an alarm system=20 =20 =20 =20 =20 Response time=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=20 The latency issue is important.=20 When a user (real human being) presses a light button the user expects=20 the light to turn on.=20 cRPLp proposes that nodes in the tree periodically advertises their=20 presence using DAOs.=20 The periodicity is a real beast:=20 Thanks to Trickle, the rate of updates in a (apparently) stable network=20 is low. This is good since it leaves bandwidth for data.=20 But it is not good if existing routes to my lamp fail and I do not get=20 new routes to my lamp until it decides to send out a new DAO.=20 My user will (with a good reason) not tolerate waiting for minutes for=20 the light to turn on.=20 =20 I have met two arguments to counter this concern:=20 =20 A1: Well, your lamp can always send a DAO when it detects a problem.=20 My answer:=20 True, except that my lamp does not intend to send anything=20 so it will never experience any problems from its side of the network.=20 =20 A2: Well, you can increase the DAO rate to sub-second updates.=20 My answer:=20 Oh no. I get a very high degree of management traffic which=20 limits my available bandwidth, increases the risk of collisions and=20 even run the risk of violating EU legislation requiring me to only=20 transmit in less than 1% of the time:=20 http://focus.ti.com/lit/an/swra048/swra048.pdf=20 868 - 868.6 MHz: <1%=20 =20 Reactiveness is hard to achieve via polling.=20 =20 =20 =20 If you agree that this seems to be critical issues please raise your=20 voice on the list.=20 =20 Going forward=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=20 =20 We need some reactive mechanism to reach lamps before the user decides=20 to sue our companies.=20 So is this possible? I think so.=20 Existing commercial (non-IP) solutions are capable of re-routing quickly=20 if they really have to.=20 =20 Let me try scoping the requirements to a potential solution:=20 (no different from the req. docs for home and building)=20 =20 * P2P routing in any direction independent of the tree.=20 =20 * On-demand P2P route discovery if requested by a real-time critical app.= =20 Data collection apps may be able to just wait for the next DAO update.=20 =20 * Limited range of discovery mechanism: max 4 repeaters.=20 A TTL field may limit the scope of the repeaters.=20 =20 * Suboptimal routing and traffic bursts are accepted in exchange=20 for quick route repair. But only as an exception.=20 =20 =20 Just as an example, one existing home control technology uses a=20 (source routing) variant of AODV for quick route repair.=20 Nothing comes for free. The price is flooding - but not just flooding:=20 Managed flooding using a distributed algorithm running in all=20 participating nodes.=20 The algorithm dampens the flooding in a time, volume and range perspective.= =20 Some similar mechanism could be built into RPL for quick route repair.=20 =20 =20 If anyone have alternative proposals, please bring it to the list.=20 Now is the time.=20 =20 =20 =20 Thanks,=20 Anders=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 Roll@ie= tf.org https://www.ietf.org/mailman/listinfo/roll =20 _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From prvs=684a899bb=mukul@uwm.edu Mon Mar 15 18:56: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 40A5B3A69EF for ; Mon, 15 Mar 2010 18:56:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.41 X-Spam-Level: X-Spam-Status: No, score=-2.41 tagged_above=-999 required=5 tests=[AWL=0.189, 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 vkId84vfT80H for ; Mon, 15 Mar 2010 18:56:13 -0700 (PDT) Received: from ip2mta.uwm.edu (ip2mta.uwm.edu [129.89.7.20]) by core3.amsl.com (Postfix) with ESMTP id 64A8C3A6864 for ; Mon, 15 Mar 2010 18:56:13 -0700 (PDT) Received: from mta02.pantherlink.uwm.edu ([129.89.7.82]) by ip2mta.uwm.edu with ESMTP; 15 Mar 2010 20:56:21 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by mta02.pantherlink.uwm.edu (Postfix) with ESMTP id 02B5C2C38010 for ; Mon, 15 Mar 2010 20:56:21 -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 BJAkIHnGzwi1 for ; Mon, 15 Mar 2010 20:56:20 -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 6D3AE2C3800D for ; Mon, 15 Mar 2010 20:56:20 -0500 (CDT) Date: Mon, 15 Mar 2010 20:56:20 -0500 (CDT) From: Mukul Goyal To: roll Message-ID: <553397372.6123061268704580401.JavaMail.root@mail02.pantherlink.uwm.edu> In-Reply-To: <2086157294.6001121268686150003.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 Subject: [Roll] Fwd: P2P performance with current RPL proposal X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Mar 2010 01:56:36 -0000 Hi Pascal I may not have been clear enough in expressing the scalability concern I have. I was saying that we can not have "source-destination pair" specific route states in the intermediate nodes. It would simply be unscalable. The approach you described in your slides seemed to suggest that nodes maintain "source-destination pair" specific route states (nodes maintain state for DAG "R,i" with target "T"). Please let me know if this is not the case. The simple/regular distance vector approach I was referring to means storing "destination(s)" specific routing states (i.e. the cost to reach a particular destination(or destinations)) in the nodes so that all the sources going to the same "destination" can benefit from this state in both routing as well as route discovery (so, no need to flood the RREQ/DIO further if I already know the cost to reach this destination). So, the scheme you proposed would work if we can have a source (or multiple sources) build a DAG towards the destination (or destinations) so that the DAG ranks/cost maintained by the nodes are with respect to the destination(s) rather than the root(s)/source(s). So, when another node needs to reach this destination, it can simply join this DAG. I hope I am clear enough this time. Thanks Mukul ----- Original Message ----- From: "Pascal Thubert (pthubert)" To: "Mukul Goyal" Cc: "ROLL WG" , "robert cragie" , "Ted Humpal" Sent: Monday, March 15, 2010 1:04:51 PM GMT -06:00 US/Canada Central Subject: RE: [Roll] P2P performance with current RPL proposal Hi Mukul > 1. A node/router in the middle may need to maintain state for multiple DAGs > that lead to the same destination. Consider the situation where 5 nearby > nodes need to find route to the same destination D. As per your scheme, > each node would form its own DAG towards the destination D and the nodes > in the middle would need to maintain state about all 5 DAGs. This seems > wasteful. You may argue that this is a fit case for these 5 nodes to belong to a > single DAG rooted at D. But the problem is that D does not know that it is a > destination for these 5 nodes. So, in general, I see a scalability problem > associated with the use of DAGs for P2P routing. A simple DV approach, > where the nodes maintain information about destinations (rather than > DAGs), seems to avoid this scalability problem. [Pascal] I do not know what you call regular :) RIP usually maintains trees but eigrp allows for non-equal cost feasible successors and thus builds DAGs. AODV (Thomas, or Charlie if you're listening, correct me if I'm wrong) builds and maintains routes that are dotted lines between 2 points. With RPL used reactively as proposed here, we can do either way. The OF can be designed to build a tree and if so, we end up with something quite similar to AODV/DYMO. Or the OF wants a DAD for redundancy and we build a DAG. One cool thing is that we can request more than one target, effectively building a DAG that looks like a flower. It's not a matter of scalability, it's a matter of what you cant to achieve and the associated cost. DAG is more expensive than tree. > > 2. So, in your scheme, the nodes timeout the state they have for a DAG. This > means that a node that does not belong to the actual route taken by the > packets would end up timing out its state for this DAG. This is ok unless this > node is part of an obvious backup route and should have maintained > information about this DAG. It would be good to use the "routing interest" > concept in this situation. As per this concept, each node maintains a "routing > interest" in a particular DAG (or destination). The routing interest is a metric > between 0 and 1. If a node is actively sending packets along the DAG, its > routing interest would be 1. Otherwise, the routing interest would be > x*max(routing interest of its nbrs), where x is a fraction. A node may delete > state about a DAG/destination if its routing interest in that dag/destination > drops below a threshold. The routing interest concept would allow nodes > "around' the actual path to maintain state about this dag while other nodes > can delete this state after initial route discovery. [Pascal] Cool : ) Now we're building a solution. Pascal > > Thanks > Mukul > ----- Original Message ----- > From: "Pascal Thubert (pthubert)" > To: "robert cragie" , "Ted Humpal" > > Cc: "ROLL WG" > Sent: Monday, March 15, 2010 11:24:01 AM GMT -06:00 US/Canada Central > Subject: Re: [Roll] P2P performance with current RPL proposal > > > > > > HI Robert : > > > > I respectfully have to disagree. > > > > My understanding is that we are considering a limited set of P2P pairs, for > which the specific path that we need to create might have to obey specific > constraints. > > So it makes sense to use an on-demand technique, probably inspired by the > MANET Reactive protocols. > > > > As it goes, those protocols usually use flooding for a node to locate another. > Forking a DAG is just another flooding. It does not take a lot of addition to the > existing DIO for a root to use RPL to build a DAG that contains one or multiple > Targets as leaves, under a set of constraints expressed as an objective > function. Please find attached a slideware that illustrates that. > > > > > Pascal > > > > > > > From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of > Robert Cragie > Sent: Thursday, March 11, 2010 2:43 PM > To: Ted.Humpal@jci.com > Cc: ROLL WG > Subject: Re: [Roll] P2P performance with current RPL proposal > > > > I agree with Ted's comments below. Creating a DODAG for every reachable > node as a root seems a very inefficient approach compared to alternative > routing algorithms. I am concerned that RPL does not actually meet the > original requirements in I-D.ietf-roll-building-routing-reqs, I-D.ietf-roll-home- > routing-reqs, RFC5673 and RFC5548. The traffic pattern requirement for a > sink node features prominently in only two of those documents. Even in this > case, as Ted points out, communication is likely to be bidirectional (e.g. end- > to-end acks.) therefore the DODAG approach is fundamentally asymmetric, > especially if no intermediate storage is allowed for destination routes and > source routing has to be used. > > Also, RPL seems highly complex for what are constrained nodes in terms of > memory as well as power and bandwidth. The RPL draft as it stands is 82 > pages long and that doesn't include text about the objective function. > > Robert > > > Robert Cragie (Pacific Gas & Electric) > > Gridmerge Ltd. > 89 Greenfield Crescent, > Wakefield, WF4 4WA, UK > +44 (0) 1924 910888 > http://www.gridmerge.com > > > > Ted.Humpal@jci.com wrote: > > > A concern also will be how much overhead (memory space) will be required > for a DODAG Root? > > and based on the first question how many DODAG roots a lamp may need to > be a member of? > > For example in lighting a single lamp may be a root for a single switch (1 > DODAG root), this lamp / luminaire may also > be a member of another group - - which could be all lights on the floor (2nd > DODAG root), and a third group > of all the lights in the building. There can be many more speciality groups > associated based on the building configuration. > Consider also during the installation time - how these DODAG roots will be > configured? Must I commission each device > to tell it which DODAG it must use for its Object Function? How easy will this > be to change and add in a new DODAG root > for the end user if the lighting group changes?? > > With respect to Jerry Martocci's - commercial building requirements - every > device may need to communicate to any or > all of the end devices. If each device must establish a DODAG for the other > 499 devices in a 500 node network - How much memory > space will this require for each end device to maintain? > > Keep in mind that the end devices are very limited processor and memory > wise. > > Not to mention all of the network maintenance messages that would need > to be transmitted to maintain all of these DODAGs. > > Consider the reconvergence time when one device is turned off and it was in > the middle of the majority of the 100+ DODAGS? > > In many lighting and building application an application acknowledgement - > must be returned {Back down the DODAG} so . . . the > requirement is not just getting to the Root - a return path must also be > maintained and have a low latency path. > > Ted Humpal > > > > > > From: > > Kris Pister > > > To: > > Anders Brandt > > > Cc: > > ROLL WG > > > Date: > > 03/08/2010 01:45 PM > > > Subject: > > Re: [Roll] P2P performance with current RPL proposal > > > > > > > > > Anders - if we take JP's suggestion to make The Lamp a DODAG root, and > take Phoebus' recommendation that we use path diversity to improve end- > to-end reliability, do you see a chance of success? > In my experience, with diverse paths and order-minutes updates you get > extremely high reliability. > > I have no aversion to TTL-limited floods as a part of a solution either. I'm > open to ideas on how to bring those in as (presumably infrequently used) > options. > > ksjp > > Anders Brandt wrote: > Hello > > I would like to probe the temperature of the WG on using DAOs to > support P2P. > > The building and home application spaces (and maybe others) have > a few clearly defined requirements. > It is not obvious to me how the current RPL proposal (cRPLp) can > satisfy those requirements: > > > In both cases it is the worst case scenario that hurts: > > > P2P routing inside the PAN > ========================== > cRPLp has no way of routing inside the PAN if you need more than > one repeater. cRPLp has to go all the way to the top (maybe 4 hops up) > and down again (maybe 4 hops down) to get just 2 hops to the side. > > The consequence is high latency and high levels of background noise > for nodes just outside the direct radio range. > At the same time the risk of meeting a failing link is 4 times higher => > latency may be much more than 4 times larger. > > Latency may sound like a minor issue but it actually translates directly > into lower battery lifetime. In the above (very realistic) example, > the battery lifetime is reduced to 25% of what it should be. > > We have lots of battery devices sending into the network: > * PIR sensors turning on lights > * Door locks sending alarms > * Door/window sensors starting chimes > * Smoke sensors triggering an alarm system > > > > > Response time > ============= > The latency issue is important. > When a user (real human being) presses a light button the user expects > the light to turn on. > cRPLp proposes that nodes in the tree periodically advertises their > presence using DAOs. > The periodicity is a real beast: > Thanks to Trickle, the rate of updates in a (apparently) stable network > is low. This is good since it leaves bandwidth for data. > But it is not good if existing routes to my lamp fail and I do not get > new routes to my lamp until it decides to send out a new DAO. > My user will (with a good reason) not tolerate waiting for minutes for > the light to turn on. > > I have met two arguments to counter this concern: > > A1: Well, your lamp can always send a DAO when it detects a problem. > My answer: > True, except that my lamp does not intend to send anything > so it will never experience any problems from its side of the network. > > A2: Well, you can increase the DAO rate to sub-second updates. > My answer: > Oh no. I get a very high degree of management traffic which > limits my available bandwidth, increases the risk of collisions and > even run the risk of violating EU legislation requiring me to only > transmit in less than 1% of the time: > http://focus.ti.com/lit/an/swra048/swra048.pdf > 868 - 868.6 MHz: <1% > > Reactiveness is hard to achieve via polling. > > > > If you agree that this seems to be critical issues please raise your > voice on the list. > > Going forward > ============= > > We need some reactive mechanism to reach lamps before the user decides > to sue our companies. > So is this possible? I think so. > > Existing commercial (non-IP) solutions are capable of re-routing quickly > if they really have to. > > Let me try scoping the requirements to a potential solution: > (no different from the req. docs for home and building) > > * P2P routing in any direction independent of the tree. > > * On-demand P2P route discovery if requested by a real-time critical app. > Data collection apps may be able to just wait for the next DAO update. > > * Limited range of discovery mechanism: max 4 repeaters. > A TTL field may limit the scope of the repeaters. > > * Suboptimal routing and traffic bursts are accepted in exchange > for quick route repair. But only as an exception. > > > Just as an example, one existing home control technology uses a > (source routing) variant of AODV for quick route repair. > Nothing comes for free. The price is flooding - but not just flooding: > Managed flooding using a distributed algorithm running in all > participating nodes. > The algorithm dampens the flooding in a time, volume and range > perspective. > Some similar mechanism could be built into RPL for quick route repair. > > > If anyone have alternative proposals, please bring it to the list. > Now is the time. > > > > Thanks, > Anders > > > > > _______________________________________________ > Roll mailing 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 wwwrun@core3.amsl.com Tue Mar 16 08:09:49 2010 Return-Path: X-Original-To: roll@ietf.org Delivered-To: roll@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id D49173A6B56; Tue, 16 Mar 2010 08:09:49 -0700 (PDT) X-idtracker: yes From: The IESG To: IETF-Announce Message-Id: <20100316150949.D49173A6B56@core3.amsl.com> Date: Tue, 16 Mar 2010 08:09:49 -0700 (PDT) Cc: roll mailing list , Internet Architecture Board , roll chair , RFC Editor Subject: [Roll] Document Action: 'Building Automation Routing Requirements in Low Power and Lossy Networks' to Informational RFC X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Mar 2010 15:09:50 -0000 The IESG has approved the following document: - 'Building Automation Routing Requirements in Low Power and Lossy Networks ' as an Informational RFC This document is the product of the Routing Over Low power and Lossy networks Working Group. The IESG contact persons are Adrian Farrel and Ross Callon. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-roll-building-routing-reqs-09.txt Technical Summary The Routing Over Low power and Lossy network (ROLL) Working Group has been chartered to work on routing solutions for Low Power and Lossy networks (LLN) in various markets: Industrial, Commercial (Building), Home and Urban networks. Pursuant to this effort, this document defines the IPv6 routing requirements for building automation. Commercial buildings have been fitted with pneumatic and subsequently electronic communication pathways connecting sensors to their controllers for over one hundred years. Recent economic and technical advances in wireless communication allow facilities to increasingly utilize a wireless solution in lieu of a wired solution; thereby reducing installation costs while maintaining highly reliant communication. The cost benefits and ease of installation of wireless sensors allow customers to further instrument their facilities with additional sensors; providing tighter control while yielding increased energy savings. IPv6 is beoming the accepted technology for use in such environments, but that means that the IP packets must be routed in LLNs. This document examines the specific routing requirements imposed by building automation applications. Working Group Summary No controversy. Document Quality The I-D is informational and specifies IPv6 routing requirements. The I-D has been revised to take advantage of the comments made on previous ROLL routing requirement drafts. Personnel JP Vasseur is the Document Shepherd. Adrian Farrel is the Responsible Area Director. RFC Editor Note Section 5.8 - New first paragraph This section sets out specific requirements that are placed on any protocols that are developed or used in the ROLL building environment in order to ensure adequate security and retain suitable flexibility of use and function of the protocol. --- Section 5.8 OLD FMS systems are typically highly configurable in the field and hence the security policy is most often dictated by the type of building to which the FMS is being installed. Single tenant owner occupied office buildings installing lighting or HVAC control are candidates for implementing low or even no security on the LLN. Antithetically, military or pharmaceutical facilities require strong security policies. As noted in the installation procedures, security policies must be facile to allow for no security policy during the installation phase (prior to building occupancy), yet easily raise the security level network wide during the commissioning phase of the system. NEW FMS systems are typically highly configurable in the field and hence the security policy is most often dictated by the type of building to which the FMS is being installed. Single tenant owner occupied office buildings installing lighting or HVAC control are candidates for implementing a low level of security on the LLN especially when the LLN is not connected to an external network. Antithetically, military or pharmaceutical facilities require strong security policies. As noted in the installation procedures described in Sections 3.3 and 5.2, security policies MUST support dynamic configuration to allow for a low level of security during the installation phase (prior to building occupancy when it may be appropriate to use only diagnostic levels of security), yet to make it possible easily raise the security level network wide during the commissioning phase of the system. From pal@cs.stanford.edu Tue Mar 16 17:15: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 4F53C3A6ADB for ; Tue, 16 Mar 2010 17:15:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.484 X-Spam-Level: X-Spam-Status: No, score=-5.484 tagged_above=-999 required=5 tests=[AWL=1.115, 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 97rFcY1zoLVX for ; Tue, 16 Mar 2010 17:15:23 -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 1DEA43A6A70 for ; Tue, 16 Mar 2010 17:15:16 -0700 (PDT) Received: from [76.14.71.8] (helo=[192.168.1.104]) by cs-smtp-1.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1Nrguz-0006X7-7q; Tue, 16 Mar 2010 17:15:25 -0700 Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Philip Levis In-Reply-To: Date: Tue, 16 Mar 2010 17:15:24 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <2BFF9008-9C96-43C0-81C3-B73F7B9FA090@cs.stanford.edu> References: <20100226011704.C9E4D28C140@core3.amsl.com> <6CE3E5D3-DAEE-45E7-9C16-1260BD345A46@cs.stanford.edu> <4B9579EB.6040604@ieee.org> <878wa162qe.fsf@kelsey-ws.hq.ember.com> <4B965F2B.1090206@ieee.org> <8516D84F-92D7-4FC6-BC7B-B434722DEBED@cs.stanford.edu> To: Omprakash Gnawali X-Mailer: Apple Mail (2.1077) X-Scan-Signature: 078eb853d78558c6c655f7b6c94b391a Cc: "roll@ietf.org" , phoebus@ieee.org Subject: Re: [Roll] Fwd: New Version Notification for draft-levis-roll-trickle-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, 17 Mar 2010 00:15:24 -0000 On Mar 15, 2010, at 12:47 PM, Omprakash Gnawali wrote: > On Mon, Mar 15, 2010 at 9:08 AM, Philip Levis = wrote: > ... >>> It is not clear if Imax should be specified as a function of the = worst >>> case link layer latency. >>=20 >> You mean Imin? What should it be specified in terms of? >=20 > The text does not say Imax should also be specified in terms of link > layer latency. It only talks about Imin in relation to worst case > latency. I was wondering if that was intentional or something to be > fixed in the next version. IMax is defined as a number of doublings of the minimum interval. It's = therefore implicitly defined in terms of link layer latency. Or am I = missing something? > One approach would be to abstract everything that the link layer does > and just look at the maximum delay between packet hand off to the link > layer and final success/failure notification/status determination for > that packet. This would include retx, channel access times, node wake > up times, and everything else. One advantage of this approach is two > DIOs with interval larger than this time at the transmitter will > maintain that time difference at the receiver. Otherwise, the timing > is less useful in this type of reasoning. This gets tricky when one considers an always busy channel: in theory, a = packet can back off indefinitely. I agree that a better wording is needed: I'm just not sure yet what it = should be. Phil From gnawali@cs.stanford.edu Tue Mar 16 18:06: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 DE9C43A6B98 for ; Tue, 16 Mar 2010 18:06:36 -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 idzqK-J9HuBb for ; Tue, 16 Mar 2010 18:06:35 -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 D96813A6B97 for ; Tue, 16 Mar 2010 18:06:35 -0700 (PDT) Received: from mail-qy0-f198.google.com ([209.85.221.198]) by cs-smtp-1.Stanford.EDU with esmtpsa (TLSv1:RC4-MD5:128) (Exim 4.60) (envelope-from ) id 1Nrhif-0000p5-0y for roll@ietf.org; Tue, 16 Mar 2010 18:06:45 -0700 Received: by qyk36 with SMTP id 36so281117qyk.30 for ; Tue, 16 Mar 2010 18:06:44 -0700 (PDT) MIME-Version: 1.0 Received: by 10.224.65.226 with SMTP id k34mr54053qai.283.1268788004140; Tue, 16 Mar 2010 18:06:44 -0700 (PDT) In-Reply-To: <2BFF9008-9C96-43C0-81C3-B73F7B9FA090@cs.stanford.edu> References: <20100226011704.C9E4D28C140@core3.amsl.com> <6CE3E5D3-DAEE-45E7-9C16-1260BD345A46@cs.stanford.edu> <4B9579EB.6040604@ieee.org> <878wa162qe.fsf@kelsey-ws.hq.ember.com> <4B965F2B.1090206@ieee.org> <8516D84F-92D7-4FC6-BC7B-B434722DEBED@cs.stanford.edu> <2BFF9008-9C96-43C0-81C3-B73F7B9FA090@cs.stanford.edu> From: Omprakash Gnawali Date: Tue, 16 Mar 2010 18:06:24 -0700 Message-ID: To: Philip Levis Content-Type: text/plain; charset=ISO-8859-1 X-Scan-Signature: 993826b9125cbf1b907f71dc54053338 Cc: "roll@ietf.org" , phoebus@ieee.org Subject: Re: [Roll] Fwd: New Version Notification for draft-levis-roll-trickle-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, 17 Mar 2010 01:06:37 -0000 On Tue, Mar 16, 2010 at 5:15 PM, Philip Levis wrote: > > On Mar 15, 2010, at 12:47 PM, Omprakash Gnawali wrote: > >> On Mon, Mar 15, 2010 at 9:08 AM, Philip Levis wrote: >> ... >>>> It is not clear if Imax should be specified as a function of the worst >>>> case link layer latency. >>> >>> You mean Imin? What should it be specified in terms of? >> >> The text does not say Imax should also be specified in terms of link >> layer latency. It only talks about Imin in relation to worst case >> latency. I was wondering if that was intentional or something to be >> fixed in the next version. > > IMax is defined as a number of doublings of the minimum interval. It's therefore implicitly defined in terms of link layer latency. Or am I missing something? > >> One approach would be to abstract everything that the link layer does >> and just look at the maximum delay between packet hand off to the link >> layer and final success/failure notification/status determination for >> that packet. This would include retx, channel access times, node wake >> up times, and everything else. One advantage of this approach is two >> DIOs with interval larger than this time at the transmitter will >> maintain that time difference at the receiver. Otherwise, the timing >> is less useful in this type of reasoning. > > This gets tricky when one considers an always busy channel: in theory, a packet can back off indefinitely. > > I agree that a better wording is needed: I'm just not sure yet what it should be. If we are using retx, there might be max retx. For backoffs, there might be maximum number of them. Does 15.4 spec has bounds on these times? We can also specify in terms of minimum time, which is what you were thinking originally I think. - om_p From mijeom@gmail.com Tue Mar 16 18:30: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 3E9A83A6905 for ; Tue, 16 Mar 2010 18:30:30 -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 Efs18K7rB3YZ for ; Tue, 16 Mar 2010 18:30:29 -0700 (PDT) Received: from mail-px0-f187.google.com (mail-px0-f187.google.com [209.85.216.187]) by core3.amsl.com (Postfix) with ESMTP id DDAE23A6781 for ; Tue, 16 Mar 2010 18:30:28 -0700 (PDT) Received: by pxi17 with SMTP id 17so418985pxi.5 for ; Tue, 16 Mar 2010 18:30:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=Mgyylcxjep/JkbZFQVfgXLvJkEF5GtuZQMeSDFxB9Pc=; b=elO+QBO9hYOCR3H+8GggDfH/waImMR59Q9XEJBMWc6bTAJreY2Wf+Bsl00yN9pJhGO A+0F62oPwq9neM3Rb/WbOSOcSn+q0Yezgk7Bo3BFGKZxUeRCC2YZpIe1K8tnCcRCxOLA 4nPyt15t2j1URNlSlv9BUHiSH00PJN/aySChg= 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=YtGgwwAeox9sxUm/A9rTpnX3ANbPNV5tTAKZkqWiAp5PXJtw15tlIgROT1eoLr0fIG kJHG4Eto6qm0Q8mnQggZFSH00v09M65vEmaMEdSWj/U1kDW544tdxR0OVEoHRDpNRZay wlzq46NvRAZtbHfHaomMJmPV6GcC7jC93Gguk= MIME-Version: 1.0 Received: by 10.143.85.8 with SMTP id n8mr65180wfl.276.1268789435182; Tue, 16 Mar 2010 18:30:35 -0700 (PDT) In-Reply-To: <4B97D5D7.5050909@gmail.com> References: <055.28872d5d0fcf65e6839f1cd72771083c@tools.ietf.org> <064.2a20a25a31ddeb41de55f5c2ba559806@tools.ietf.org> <4B90DF6D.9070806@gmail.com> <4B94D55E.7080302@gmail.com> <8E09C72DBC577D489F13A71228C0B7BF0105150F@ftrdmel0.rd.francetelecom.fr> <4B97D5D7.5050909@gmail.com> Date: Wed, 17 Mar 2010 10:30:35 +0900 Message-ID: From: MiJeom Kim To: Alexandru Petrescu Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: roll@ietf.org Subject: Re: [Roll] [roll] #18: Numeric Ranges in Routing Metric X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 17 Mar 2010 01:30:30 -0000 Hi, Let's try to close on this ticket. So, let's express latency metric with 24 unsigned integer in unit of microsecond. We don't need to restrict the increasing unit to 10 microsecond. And throughput metric uses 32 unsigned integer to present bytes per second. Thank you. Mijeom. On Thu, Mar 11, 2010 at 2:24 AM, Alexandru Petrescu wrote: > Le 10/03/2010 09:07, dominique.barthel@orange-ftgroup.com a =E9crit : >> >> Hi all, >> >> I disagree with option 3. This is just another "floating point" >> format, with a one-bit exponent and a 15-bit mantissa. If IEEE 16-bit >> FP was rejected, this one should be rejected for the same reasons. >> >> Again, I favor option 2, but instead of microsecond increments, which >> is a resolution we don't need, I suggest using 10 us increments, >> which pushes the full range to about 168 seconds. > > That is a smart way of increasing the overall range, I think. > >> Again, you can't measure the link latency with a resolution smaller >> than 10us, if only because of random back-off delays or mere >> electrical symbol duration. > > Not sure about the impossibility of measuring a less-than-10us precision > of less-than 10us. =A0The linux kernel time struct (and tv in userspace) > is expressed in 1us precision range. > > An off-the-shelf "ping" on linux on wired Ethernet 100Mbps reports RTTs > like "0.384 ms" which makes it for precision of units of micro-second. > The situation with a wireless 802.11g is similar. > > YEs precise measuring should account for backoff delays and > electrical symbol representations too, with average and statistical > tools. > > Alex > >> >> >> Dominique >> >> >> -----Message d'origine----- De : roll-bounces@ietf.org >> [mailto:roll-bounces@ietf.org] De la part de MiJeom Kim Envoy=E9 : >> mercredi 10 mars 2010 02:57 =C0 : Alexandru Petrescu Cc : >> roll@ietf.org Objet : Re: [Roll] [roll] #18: Numeric Ranges in >> Routing Metric >> >> Hi, Alex, >> >> The problem you mentioned regarding option 3 can be easily solved. We >> can just set the rule that whenever possible, using microsecond >> instead of millisecond to give more information (precision). So upto >> 32767 miroseconds, uses microsecond and if latency becomes greater >> than that, uses millisecond. I had considered that removing the >> overlapping part, but that makes the format more complicated. >> >> Mijeom. >> >> >> On Mon, Mar 8, 2010 at 7:45 PM, Alexandru >> Petrescu =A0wrote: >>> >>> Le 08/03/2010 02:24, MiJeom Kim a =E9crit : >>>> >>>> Hi, >>>> >>>> Actually, we were in the middle of discussion. Let me resummerize >>>> the final options we have until now. >>>> >>>> 1. 16 bit unsigned integer --> =A0 =A0it's not enough to express all >>>> =A0cases since 65535 micro seconds (65 milliseconds) >>> >>> Ok I guess we need to discard this. >>> >>>> 2. 24 bit unsigned integer >>> >>> This could represent >>> >>> 0..16777216 =A0 microseconds i.e. 0..16777,216 =A0milliseconds i.e. 0.. >>> 16,777216 seconds delay. >>> >>>> 3. 1 bit indication bit (to indicate millisecond or mirocsecond) >>>> =A0+ 15 bit insigned integer --> =A0 =A0the range can be from 0 >>>> microseconds to 32767 milliseconds. >>> >>> Right, the range of representation could be wider than with the >>> 24bit integer(?) >>> >>> But there a same value could be represented by two different >>> encodings. This makes comparisons for equality longer to write in >>> C, requires normalization before each comparison. >>> >>> I.e. 1 millisecond could be represented by somebody as >>> 1000micro-seconds, and when comparing the two values it's not >>> sufficient to simply compare the 16bit values received in >>> messages, one has to normalize first (similar to when one has to >>> apply ntohs before every comparison of shorts received from the >>> wire). >>> >>> Tradeoffs tradeoffs... >>> >>> Alex >>> >>>> >>>> Thanks, Mijeom. >>>> >>>> >>>> On Fri, Mar 5, 2010 at 7:39 PM, Alexandru Petrescu >>>> =A0 =A0wrote: >>>>> >>>>> Le 05/03/2010 11:36, roll issue tracker a =E9crit : >>>>>> >>>>>> #18: Numeric Ranges in Routing Metric >>>>>> >>>>>> >>>>>> --------------------------------+---------------------------------- >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> > --------------------------------+--------- >>>>>> >>>>>> >>>>>> >>>>>> >>> Reporter: =A0jpv@... =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0 =A0 =A0Owner= : =A0mjkim@... >>>>>> >>>>>> Type: =A0defect =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 =A0 =A0 Status: =A0= closed Priority: >>>>>> minor =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0Milestone: Component: >>>>>> routing-metrics | Version: Severity: =A0Active WG Document =A0| >>>>>> Resolution: fixed Keywords: =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0| >>>>>> >>>>>> >>>>>> --------------------------------+---------------------------------- >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> > --------------------------------+--------- >>>>>> >>>>>> >>>>>> >>>>>> >>> Changes (by jpv@...): >>>>>> >>>>>> * status: =A0new =3D> =A0 =A0 =A0closed * resolution: =A0=3D> =A0 = =A0 =A0fixed >>>>>> >>>>>> >>>>>> Comment: >>>>>> >>>>>> Here is the resolution after discussion on the mailing list: >>>>>> >>>>>> It's time to close on the #18. I think that throughput and >>>>>> latency can be better presented by unsigned integers as the >>>>>> below justification wrote. Latency can be expressed in units >>>>>> =A0of milliseconds >>>>> >>>>> But we just seemed to agree on micro-seconds instead, haven't >>>>> we? >>>>> >>>>> Alex >>>>> >>>>> >>>>> and throughput can >>>>>> >>>>>> be expressed in bytes per second. >>>>>> >>>>>> Mijeom. >>>>>> >>>>> >>>>> >>>>> _______________________________________________ Roll mailing >>>>> 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 trac@tools.ietf.org Tue Mar 16 18:57: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 363FF3A6BAC for ; Tue, 16 Mar 2010 18:57:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.205 X-Spam-Level: X-Spam-Status: No, score=-101.205 tagged_above=-999 required=5 tests=[AWL=-1.224, BAYES_05=-1.11, 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 t34mOcoTQa7m for ; Tue, 16 Mar 2010 18:57:58 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 91B953A6B9A for ; Tue, 16 Mar 2010 18:57:56 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1NriWK-00067n-Fm; Tue, 16 Mar 2010 18:58:04 -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: mjkim@kt.com X-Trac-Project: roll Date: Wed, 17 Mar 2010 01:58:04 -0000 X-URL: http://tools.ietf.org/wg/roll/ X-Trac-Ticket-URL: https://svn.tools.ietf.org/wg/roll/trac/ticket/20#comment:1 Message-ID: <064.2fcbbc9928617712d033305fbb1562c6@tools.ietf.org> References: <055.a3c60804880e85f93fc1826167be4fb6@tools.ietf.org> X-Trac-Ticket-ID: 20 In-Reply-To: <055.a3c60804880e85f93fc1826167be4fb6@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: mjkim@kt.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] #20: Question on Metric ID 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: Wed, 17 Mar 2010 01:57:59 -0000 #20: Question on Metric ID --------------------------------+------------------------------------------- Reporter: jpv@… | Owner: mjkim@… Type: defect | Status: closed Priority: major | Milestone: Component: routing-metrics | Version: Severity: Active WG Document | Resolution: fixed Keywords: | --------------------------------+------------------------------------------- Changes (by mjkim@…): * status: new => closed * resolution: => fixed Comment: After long discussion, we concluded as follows: - Throughput: 32 unsigned integer in unit of microsecond - Latency: 24 unsigned integer in unit of bytes per second - ETX: 1 byte to present (ETX * C) as (32 + a) * 2^b where C = 64, 0 <= a <= 31 and 0 <= b <= 7. If ETX >= 126, we can assume ETX is infinity. (First 5 bits for a and the rest 3 bits for b.) Thanks, Mijeom. -- Ticket URL: roll From pal@cs.stanford.edu Tue Mar 16 22:46: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 EAEAD3A67AD for ; Tue, 16 Mar 2010 22:46:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.198 X-Spam-Level: X-Spam-Status: No, score=-5.198 tagged_above=-999 required=5 tests=[AWL=0.271, 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 5-4S5xDEdYhr for ; Tue, 16 Mar 2010 22:46: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 F3F5E3A6359 for ; Tue, 16 Mar 2010 22:46:23 -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 1Nrm5R-0006g7-Ga; Tue, 16 Mar 2010 22:46:33 -0700 In-Reply-To: References: <055.28872d5d0fcf65e6839f1cd72771083c@tools.ietf.org> <064.2a20a25a31ddeb41de55f5c2ba559806@tools.ietf.org> <4B90DF6D.9070806@gmail.com> <4B94D55E.7080302@gmail.com> <8E09C72DBC577D489F13A71228C0B7BF0105150F@ftrdmel0.rd.francetelecom.fr> <4B97D5D7.5050909@gmail.com> Mime-Version: 1.0 (Apple Message framework v753.1) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <513D9DE7-0798-4423-8450-161697F6248C@cs.stanford.edu> Content-Transfer-Encoding: 7bit From: Philip Levis Date: Tue, 16 Mar 2010 22:44:37 -0700 To: MiJeom Kim X-Mailer: Apple Mail (2.753.1) X-Scan-Signature: ff384b2b9a2989b26e23b1d864f6aba2 Cc: roll@ietf.org Subject: Re: [Roll] [roll] #18: Numeric Ranges in Routing Metric X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 17 Mar 2010 05:46:25 -0000 On Mar 16, 2010, at 6:30 PM, MiJeom Kim wrote: > Hi, > > Let's try to close on this ticket. > So, let's express latency metric with 24 unsigned integer in unit of > microsecond. > We don't need to restrict the increasing unit to 10 microsecond. > And throughput metric uses 32 unsigned integer to present bytes per > second. Shouldn't latency be 32 bits as well? 24 bits means up to 2^4 seconds. With low power link layers, that seems like close enough to be comfortable for now, but doesn't have a lot of space to grow. Phil From richard.kelsey@ember.com Wed Mar 17 05:36: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 614EA3A6A22 for ; Wed, 17 Mar 2010 05:36:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.29 X-Spam-Level: X-Spam-Status: No, score=-1.29 tagged_above=-999 required=5 tests=[AWL=-1.310, BAYES_05=-1.11, 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 Q10sEWjwfkHY for ; Wed, 17 Mar 2010 05:36:48 -0700 (PDT) Received: from EMPIRE.hq.ember.com (mail.ember.com [74.10.175.227]) by core3.amsl.com (Postfix) with ESMTP id EC5AF3A6A39 for ; Wed, 17 Mar 2010 05:36:46 -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, 17 Mar 2010 08:39:41 -0400 Date: Wed, 17 Mar 2010 08:36:31 -0400 Message-Id: <87pr333z1s.fsf@kelsey-ws.hq.ember.com> To: roll@ietf.org In-reply-to: <064.2fcbbc9928617712d033305fbb1562c6@tools.ietf.org> (trac@tools.ietf.org) From: Richard Kelsey References: <055.a3c60804880e85f93fc1826167be4fb6@tools.ietf.org> <064.2fcbbc9928617712d033305fbb1562c6@tools.ietf.org> X-OriginalArrivalTime: 17 Mar 2010 12:39:42.0124 (UTC) FILETIME=[EA7966C0:01CAC5CE] Subject: Re: [Roll] [roll] #20: Question on Metric 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: Wed, 17 Mar 2010 12:36:49 -0000 > From: "roll issue tracker" > Date: Wed, 17 Mar 2010 01:58:04 -0000 > > #20: Question on Metric ID > > Comment: > > After long discussion, we concluded as follows: > > - Throughput: 32 unsigned integer in unit of microsecond > > - Latency: 24 unsigned integer in unit of bytes per second > > - ETX: 1 byte to present (ETX * C) as (32 + a) * 2^b > where C = 64, 0 <= a <= 31 and 0 <= b <= 7. > If ETX >= 126, we can assume ETX is infinity. > (First 5 bits for a and the rest 3 bits for b.) I applaud the decision not to use floating point for throughput and latency. Can we please do the same for ETX? Many of the same arguments apply to it as well (e.g. http://www.ietf.org/mail-archive/web/roll/current/msg03104.html). Make it ETX * 64 as a 16-bit unsigned integer. -Richard Kelsey From pal@cs.stanford.edu Wed Mar 17 08:24: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 8B45F3A6C80 for ; Wed, 17 Mar 2010 08:24:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.252 X-Spam-Level: X-Spam-Status: No, score=-5.252 tagged_above=-999 required=5 tests=[AWL=0.217, 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 4-LDO8CSw+Yr for ; Wed, 17 Mar 2010 08:24:37 -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 0A3273A6C6A for ; Wed, 17 Mar 2010 08:20:35 -0700 (PDT) Received: from [76.14.71.8] (helo=[192.168.1.106]) by cs-smtp-3.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1Nrv36-0007Sd-Rt; Wed, 17 Mar 2010 08:20:45 -0700 In-Reply-To: <87pr333z1s.fsf@kelsey-ws.hq.ember.com> References: <055.a3c60804880e85f93fc1826167be4fb6@tools.ietf.org> <064.2fcbbc9928617712d033305fbb1562c6@tools.ietf.org> <87pr333z1s.fsf@kelsey-ws.hq.ember.com> Mime-Version: 1.0 (Apple Message framework v753.1) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Philip Levis Date: Wed, 17 Mar 2010 08:18:49 -0700 To: Richard Kelsey X-Mailer: Apple Mail (2.753.1) X-Scan-Signature: f219e97bb238ccbb8ed40879dafdba3c Cc: roll@ietf.org Subject: Re: [Roll] [roll] #20: Question on Metric 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: Wed, 17 Mar 2010 15:24:38 -0000 On Mar 17, 2010, at 5:36 AM, Richard Kelsey wrote: >> From: "roll issue tracker" >> Date: Wed, 17 Mar 2010 01:58:04 -0000 >> >> #20: Question on Metric ID >> >> Comment: >> >> After long discussion, we concluded as follows: >> >> - Throughput: 32 unsigned integer in unit of microsecond >> >> - Latency: 24 unsigned integer in unit of bytes per second >> >> - ETX: 1 byte to present (ETX * C) as (32 + a) * 2^b >> where C = 64, 0 <= a <= 31 and 0 <= b <= 7. >> If ETX >= 126, we can assume ETX is infinity. >> (First 5 bits for a and the rest 3 bits for b.) > > I applaud the decision not to use floating point for > throughput and latency. Can we please do the same for ETX? > Many of the same arguments apply to it as well (e.g. > http://www.ietf.org/mail-archive/web/roll/current/msg03104.html). > Make it ETX * 64 as a 16-bit unsigned integer. +1 Phil From pal@cs.stanford.edu Wed Mar 17 09:38: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 A1C133A6837; Wed, 17 Mar 2010 09:38:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.034 X-Spam-Level: X-Spam-Status: No, score=-6.034 tagged_above=-999 required=5 tests=[AWL=-0.565, 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 ErNQu8IU4Hf6; Wed, 17 Mar 2010 09:38:45 -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 8D3C63A691F; Wed, 17 Mar 2010 09:38:39 -0700 (PDT) Received: from dnab404680.stanford.edu ([171.64.70.128]) by cs-smtp-1.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1NrwGe-0005A6-Q4; Wed, 17 Mar 2010 09:38:49 -0700 Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=iso-8859-1 From: Philip Levis In-Reply-To: <201003151814.08275.hrogge@googlemail.com> Date: Wed, 17 Mar 2010 09:25:25 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <8F5D47B2-FF37-494F-B137-B3BAF07CD2E1@cs.stanford.edu> References: <20100223045634.C3F6328C44F@core3.amsl.com> <201003151007.05075.henning.rogge@fkie.fraunhofer.de> <9DD3490C-638B-4B03-ACFF-B8B9997FE873@cs.stanford.edu> <201003151814.08275.hrogge@googlemail.com> To: Henning Rogge X-Mailer: Apple Mail (2.1077) X-Scan-Signature: cb5916722246bf80bd9488153e8e2604 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: Wed, 17 Mar 2010 16:38:46 -0000 On Mar 15, 2010, at 10:14 AM, Henning Rogge wrote: > Am Montag 15 M=E4rz 2010 17:18:53 schrieb Philip Levis: >>> If you can access layer 1/2 data this is a good idea. But the code = will >>> become OS or even hardware specific. >>=20 >> Absolutely. But honestly, I'm less worried about the software = engineering >> of network protocols than their actual efficiency. OSes can evolve to >> support new interfaces. > We should worry about both. If we ignore the software side of the = problem we=20 > might design stuff that does not run on most platforms. Very true.=20 >=20 >> This also gets back to my original point: separating the metric and = its >> computation is valuable. Implementations can use this kind of = information >> when it's available, but when it's not they can use other techniques. >>=20 >>>> and EWMA rather than a fixed window size. >>>=20 >>> EWMA is not always better than a fixed window. >>=20 >> In theory, no. In practice, I think it is. By practice, I mean "on >> unlicensed ISM bands." > We have experimented with EWMA based in the Freifunk networks (IEEE = 802.11=20 > based meshs), and we had better experience with the fixed window than = the=20 > EWMA. EWMA is more difficult to adapt to events that don't occur on a = regular=20 > interval. Interesting. I'd love to see what the link behavior of these networks = look like. Do you have a writeup of what led you to this conclusion? >=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. > You don't want your LQ value change quicker than you can transport it = to the=20 > 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). 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. Phil From hrogge@googlemail.com Wed Mar 17 09:52: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 2FE5A3A6A48; Wed, 17 Mar 2010 09:52:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.834 X-Spam-Level: X-Spam-Status: No, score=-1.834 tagged_above=-999 required=5 tests=[AWL=-0.365, 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 jU8ih1l7TTHe; Wed, 17 Mar 2010 09:52:33 -0700 (PDT) Received: from mail-ew0-f218.google.com (mail-ew0-f218.google.com [209.85.219.218]) by core3.amsl.com (Postfix) with ESMTP id AB6033A6A08; Wed, 17 Mar 2010 09:52:32 -0700 (PDT) Received: by ewy10 with SMTP id 10so671358ewy.32 for ; Wed, 17 Mar 2010 09:52: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=eP9om/uuOx8Nij71CH6UBFmjE7SCyYKSlzL2RYvNsxc=; b=iUJtr+WVPdT8Gm9VYWP9rJ6mYDlZkiHFHnshCKmYs7xMBV5BKoStr8epGty5YWjB16 eWsT6cVIEK94w11ThAEZr9vRpNk8L3sWga4KvBNv2m01uChGJBWJHlng01TVTJnykr8D 6eKaiL59pWvqMTUhn7zCOxTKwWQBfalHmqRxc= 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=ecZNNLu1phIvusYlDIAi5cH6YPoLqf/rNzrqW66LVyXi5v65vdtk50EgduBWuLJ6H9 hqoTUWZXTc3u7CL2R8SVBNxShl70zKjIlNt1QJR5mtKBn3tWIfUt0kS6Rs4uK+9F/bJf a9Lr8eJ9ViqL+XUeyikfNwsGsCa8JhWI15His= Received: by 10.213.15.14 with SMTP id i14mr758977eba.71.1268844758987; Wed, 17 Mar 2010 09:52:38 -0700 (PDT) Received: from core2.localnet (static-87-79-93-195.netcologne.de [87.79.93.195]) by mx.google.com with ESMTPS id 15sm704344ewy.4.2010.03.17.09.52.37 (version=SSLv3 cipher=RC4-MD5); Wed, 17 Mar 2010 09:52:37 -0700 (PDT) From: Henning Rogge To: Philip Levis Date: Wed, 17 Mar 2010 17:52:31 +0100 User-Agent: KMail/1.13.1 (Linux/2.6.33-gentoo; KDE/4.4.1; x86_64; ; ) References: <20100223045634.C3F6328C44F@core3.amsl.com> <201003151814.08275.hrogge@googlemail.com> <8F5D47B2-FF37-494F-B137-B3BAF07CD2E1@cs.stanford.edu> In-Reply-To: <8F5D47B2-FF37-494F-B137-B3BAF07CD2E1@cs.stanford.edu> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1575251.0rFsvgiJQn"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <201003171752.36500.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: Wed, 17 Mar 2010 16:52:34 -0000 --nextPart1575251.0rFsvgiJQn Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable 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= =20 tuning parameter and more influence to recent data) is their disadvantage t= oo.=20 EWMA values. Because of the higher influence of recent data EWMA-based ETX= =20 tends to jump up/down more because of it's binary input (packet=20 received/lost). > 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. ;) > 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 g= ood=20 hysteresis can keep the "speed" of the metric change down to something the= =20 adhoc network can handle. Unless the "fast time" variations of the metric a= re=20 higher than the hysteresis threshold. Henning Rogge --nextPart1575251.0rFsvgiJQn 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) iEYEABECAAYFAkuhCNQACgkQcenvcwAcHWfpZACfWwqCmswQwaaP3/ib17guoG0T /8QAoIdLaEldxG4MZ2i1Y8US9QgaDxOa =VM4Z -----END PGP SIGNATURE----- --nextPart1575251.0rFsvgiJQn-- From abr@sdesigns.dk Wed Mar 17 09:56: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 EFE0F3A6A86 for ; Wed, 17 Mar 2010 09:56:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.231 X-Spam-Level: X-Spam-Status: No, score=0.231 tagged_above=-999 required=5 tests=[AWL=-2.297, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NZNZz+4Ryqmn for ; Wed, 17 Mar 2010 09:56: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 30CC23A679C for ; Wed, 17 Mar 2010 09:56:26 -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_01CAC5F2.CDCD470E" Date: Wed, 17 Mar 2010 17:56:35 +0100 Message-ID: <6D9687E95918C04A8B30A7D6DA805A3E01AD45C2@zensys17.zensys.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] Fwd: P2P performance with current RPL proposal Thread-Index: AcrEq/HNWiPhal6tTwqQ8YLTTeUPbQBRDsDU References: <553397372.6123061268704580401.JavaMail.root@mail02.pantherlink.uwm.edu> From: "Anders Brandt" To: "roll" Subject: Re: [Roll] Fwd: P2P performance with current RPL proposal X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Mar 2010 16:56:36 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CAC5F2.CDCD470E Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Pascal, =20 > Cool : ) Now we're building a solution. =20 Are we? OK - I guess I need some readers guidance here... =20 In some previous mail I saw you mention that the DAG mechanisms could be = made reactive. Could you explain in a few words how this can be achieved? =20 Even if so, I fail to see how this meets the other goals pinpointed = multiple times by Jerry, me and others: =20 Just re-iterating, my world (also) consists of=20 =20 * Battery powered =20 devices having to send =20 * P2P traffic to a subset of network nodes or all nodes =20 with =20 * close to optimal routing =20 to keep battery consumption low and a need for =20 * soft real-time route repair (less than 4 seconds with a limit of four = repeaters) =20 to provide a reasonable user experience when turning on light. =20 Are we getting closer to these objectives? =20 Thanks, Anders =20 ________________________________ Fra: roll-bounces@ietf.org p=E5 vegne af Mukul Goyal Sendt: ti 16-03-2010 02:56 Til: roll Emne: [Roll] Fwd: P2P performance with current RPL proposal Hi Pascal I may not have been clear enough in expressing the scalability concern I = have. I was saying that we can not have "source-destination pair" specific route states in the = intermediate nodes. It would simply be unscalable. The approach you = described in your slides seemed to suggest that nodes maintain = "source-destination pair" specific route states (nodes maintain state = for DAG "R,i" with target "T"). Please let me know if this is not the = case. The simple/regular distance vector approach I was referring to means = storing "destination(s)" specific routing states (i.e. the cost to reach = a particular destination(or destinations)) in the nodes so that all the = sources going to the same "destination" can benefit from this state in = both routing as well as route discovery (so, no need to flood the = RREQ/DIO further if I already know the cost to reach this destination). So, the scheme you proposed would work if we can have a source (or = multiple sources) build a DAG towards the destination (or destinations) = so that the DAG ranks/cost maintained by the nodes are with respect to = the destination(s) rather than the root(s)/source(s). So, when another = node needs to reach this destination, it can simply join this DAG. I hope I am clear enough this time. Thanks Mukul =20 ----- Original Message ----- From: "Pascal Thubert (pthubert)" To: "Mukul Goyal" Cc: "ROLL WG" , "robert cragie" = , "Ted Humpal" Sent: Monday, March 15, 2010 1:04:51 PM GMT -06:00 US/Canada Central Subject: RE: [Roll] P2P performance with current RPL proposal Hi Mukul > 1. A node/router in the middle may need to maintain state for multiple = DAGs > that lead to the same destination. Consider the situation where 5 = nearby > nodes need to find route to the same destination D. As per your = scheme, > each node would form its own DAG towards the destination D and the = nodes > in the middle would need to maintain state about all 5 DAGs. This = seems > wasteful. You may argue that this is a fit case for these 5 nodes to = belong to a > single DAG rooted at D. But the problem is that D does not know that = it is a > destination for these 5 nodes. So, in general, I see a scalability = problem > associated with the use of DAGs for P2P routing. A simple DV approach, > where the nodes maintain information about destinations (rather than > DAGs), seems to avoid this scalability problem. [Pascal] I do not know what you call regular :) RIP usually maintains trees but eigrp allows for non-equal cost feasible = successors and thus builds DAGs. AODV (Thomas, or Charlie if you're listening, correct me if I'm wrong) = builds and maintains routes that are dotted lines between 2 points. With RPL used reactively as proposed here, we can do either way. The OF can be designed to build a tree and if so, we end up with = something quite similar to AODV/DYMO. Or the OF wants a DAD for redundancy and we build a DAG. One cool thing is that we can request more than one target, effectively = building a DAG that looks like a flower. It's not a matter of scalability, it's a matter of what you cant to = achieve and the associated cost. DAG is more expensive than tree. > > 2. So, in your scheme, the nodes timeout the state they have for a = DAG. This > means that a node that does not belong to the actual route taken by = the > packets would end up timing out its state for this DAG. This is ok = unless this > node is part of an obvious backup route and should have maintained > information about this DAG. It would be good to use the "routing = interest" > concept in this situation. As per this concept, each node maintains a = "routing > interest" in a particular DAG (or destination). The routing interest = is a metric > between 0 and 1. If a node is actively sending packets along the DAG, = its > routing interest would be 1. Otherwise, the routing interest would be > x*max(routing interest of its nbrs), where x is a fraction. A node may = delete > state about a DAG/destination if its routing interest in that = dag/destination > drops below a threshold. The routing interest concept would allow = nodes > "around' the actual path to maintain state about this dag while other = nodes > can delete this state after initial route discovery. [Pascal] Cool : ) Now we're building a solution. Pascal > > Thanks > Mukul > ----- Original Message ----- > From: "Pascal Thubert (pthubert)" > To: "robert cragie" , "Ted Humpal" > > Cc: "ROLL WG" > Sent: Monday, March 15, 2010 11:24:01 AM GMT -06:00 US/Canada Central > Subject: Re: [Roll] P2P performance with current RPL proposal > > > > > > HI Robert : > > > > I respectfully have to disagree. > > > > My understanding is that we are considering a limited set of P2P = pairs, for > which the specific path that we need to create might have to obey = specific > constraints. > > So it makes sense to use an on-demand technique, probably inspired by = the > MANET Reactive protocols. > > > > As it goes, those protocols usually use flooding for a node to locate = another. > Forking a DAG is just another flooding. It does not take a lot of = addition to the > existing DIO for a root to use RPL to build a DAG that contains one or = multiple > Targets as leaves, under a set of constraints expressed as an = objective > function. Please find attached a slideware that illustrates that. > > > > > Pascal > > > > > > > From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf = Of > Robert Cragie > Sent: Thursday, March 11, 2010 2:43 PM > To: Ted.Humpal@jci.com > Cc: ROLL WG > Subject: Re: [Roll] P2P performance with current RPL proposal > > > > I agree with Ted's comments below. Creating a DODAG for every = reachable > node as a root seems a very inefficient approach compared to = alternative > routing algorithms. I am concerned that RPL does not actually meet the > original requirements in I-D.ietf-roll-building-routing-reqs, = I-D.ietf-roll-home- > routing-reqs, RFC5673 and RFC5548. The traffic pattern requirement for = a > sink node features prominently in only two of those documents. Even in = this > case, as Ted points out, communication is likely to be bidirectional = (e.g. end- > to-end acks.) therefore the DODAG approach is fundamentally = asymmetric, > especially if no intermediate storage is allowed for destination = routes and > source routing has to be used. > > Also, RPL seems highly complex for what are constrained nodes in terms = of > memory as well as power and bandwidth. The RPL draft as it stands is = 82 > pages long and that doesn't include text about the objective function. > > Robert > > > Robert Cragie (Pacific Gas & Electric) > > Gridmerge Ltd. > 89 Greenfield Crescent, > Wakefield, WF4 4WA, UK > +44 (0) 1924 910888 > http://www.gridmerge.com =20 > > > > Ted.Humpal@jci.com wrote: > > > A concern also will be how much overhead (memory space) will be = required > for a DODAG Root? > > and based on the first question how many DODAG roots a lamp may need = to > be a member of? > > For example in lighting a single lamp may be a root for a single = switch (1 > DODAG root), this lamp / luminaire may also > be a member of another group - - which could be all lights on the = floor (2nd > DODAG root), and a third group > of all the lights in the building. There can be many more speciality = groups > associated based on the building configuration. > Consider also during the installation time - how these DODAG roots = will be > configured? Must I commission each device > to tell it which DODAG it must use for its Object Function? How easy = will this > be to change and add in a new DODAG root > for the end user if the lighting group changes?? > > With respect to Jerry Martocci's - commercial building requirements - = every > device may need to communicate to any or > all of the end devices. If each device must establish a DODAG for the = other > 499 devices in a 500 node network - How much memory > space will this require for each end device to maintain? > > Keep in mind that the end devices are very limited processor and = memory > wise. > > Not to mention all of the network maintenance messages that would need > to be transmitted to maintain all of these DODAGs. > > Consider the reconvergence time when one device is turned off and it = was in > the middle of the majority of the 100+ DODAGS? > > In many lighting and building application an application = acknowledgement - > must be returned {Back down the DODAG} so . . . the > requirement is not just getting to the Root - a return path must also = be > maintained and have a low latency path. > > Ted Humpal > > > > > > From: > > Kris Pister > > > To: > > Anders Brandt > > > Cc: > > ROLL WG > > > Date: > > 03/08/2010 01:45 PM > > > Subject: > > Re: [Roll] P2P performance with current RPL proposal > > > > > > > > > Anders - if we take JP's suggestion to make The Lamp a DODAG root, and > take Phoebus' recommendation that we use path diversity to improve = end- > to-end reliability, do you see a chance of success? > In my experience, with diverse paths and order-minutes updates you get > extremely high reliability. > > I have no aversion to TTL-limited floods as a part of a solution = either. I'm > open to ideas on how to bring those in as (presumably infrequently = used) > options. > > ksjp > > Anders Brandt wrote: > Hello > > I would like to probe the temperature of the WG on using DAOs to > support P2P. > > The building and home application spaces (and maybe others) have > a few clearly defined requirements. > It is not obvious to me how the current RPL proposal (cRPLp) can > satisfy those requirements: > > > In both cases it is the worst case scenario that hurts: > > > P2P routing inside the PAN > = =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 > cRPLp has no way of routing inside the PAN if you need more than > one repeater. cRPLp has to go all the way to the top (maybe 4 hops up) > and down again (maybe 4 hops down) to get just 2 hops to the side. > > The consequence is high latency and high levels of background noise > for nodes just outside the direct radio range. > At the same time the risk of meeting a failing link is 4 times higher = =3D> > latency may be much more than 4 times larger. > > Latency may sound like a minor issue but it actually translates = directly > into lower battery lifetime. In the above (very realistic) example, > the battery lifetime is reduced to 25% of what it should be. > > We have lots of battery devices sending into the network: > * PIR sensors turning on lights > * Door locks sending alarms > * Door/window sensors starting chimes > * Smoke sensors triggering an alarm system > > > > > Response time > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > The latency issue is important. > When a user (real human being) presses a light button the user expects > the light to turn on. > cRPLp proposes that nodes in the tree periodically advertises their > presence using DAOs. > The periodicity is a real beast: > Thanks to Trickle, the rate of updates in a (apparently) stable = network > is low. This is good since it leaves bandwidth for data. > But it is not good if existing routes to my lamp fail and I do not get > new routes to my lamp until it decides to send out a new DAO. > My user will (with a good reason) not tolerate waiting for minutes for > the light to turn on. > > I have met two arguments to counter this concern: > > A1: Well, your lamp can always send a DAO when it detects a problem. > My answer: > True, except that my lamp does not intend to send anything > so it will never experience any problems from its side of the = network. > > A2: Well, you can increase the DAO rate to sub-second updates. > My answer: > Oh no. I get a very high degree of management traffic which > limits my available bandwidth, increases the risk of collisions and > even run the risk of violating EU legislation requiring me to only > transmit in less than 1% of the time: > http://focus.ti.com/lit/an/swra048/swra048.pdf > 868 - 868.6 MHz: <1% > > Reactiveness is hard to achieve via polling. > > > > If you agree that this seems to be critical issues please raise your > voice on the list. > > Going forward > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > We need some reactive mechanism to reach lamps before the user decides > to sue our companies. > So is this possible? I think so. > > Existing commercial (non-IP) solutions are capable of re-routing = quickly > if they really have to. > > Let me try scoping the requirements to a potential solution: > (no different from the req. docs for home and building) > > * P2P routing in any direction independent of the tree. > > * On-demand P2P route discovery if requested by a real-time critical = app. > Data collection apps may be able to just wait for the next DAO = update. > > * Limited range of discovery mechanism: max 4 repeaters. > A TTL field may limit the scope of the repeaters. > > * Suboptimal routing and traffic bursts are accepted in exchange > for quick route repair. But only as an exception. > > > Just as an example, one existing home control technology uses a > (source routing) variant of AODV for quick route repair. > Nothing comes for free. The price is flooding - but not just flooding: > Managed flooding using a distributed algorithm running in all > participating nodes. > The algorithm dampens the flooding in a time, volume and range > perspective. > Some similar mechanism could be built into RPL for quick route repair. > > > If anyone have alternative proposals, please bring it to the list. > Now is the time. > > > > Thanks, > Anders > > > > > _______________________________________________ > Roll mailing 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_01CAC5F2.CDCD470E Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable [Roll] Fwd: P2P performance with current = RPL proposal=0A= =0A= =0A= =0A=
=0A=
Pascal,
=0A=
 
=0A=
> Cool : ) = Now we're building a solution.
=0A=
 
=0A=
Are we?
=0A=
OK - I guess I need some = readers guidance here...
=0A=
 
=0A=
In some previous mail I saw = you mention that the DAG mechanisms could be made reactive.
=0A=
Could you explain in a few = words how this can be achieved?
=0A=
 
=0A=
Even if so, I fail to see how = this meets the other goals pinpointed multiple times by Jerry, me and = others:
=0A=
 
=0A=
Just re-iterating, my world = (also) consists of
=0A=
 
=0A=
* Battery powered
=0A=
 
=0A=
devices having to = send
=0A=
 
=0A=
* P2P traffic to a subset of = network nodes or all nodes
=0A=
 
=0A=
with
=0A=
 
=0A=
* close to optimal = routing
=0A=
 
=0A=
to keep battery consumption = low and a need for
=0A=
 
=0A=
* soft real-time route repair = (less than 4 seconds with a limit of four repeaters)
=0A=
 
=0A=
to provide a reasonable user = experience when turning on light.
=0A=
 
=0A=
Are we getting closer to = these objectives?
=0A=
 
=0A=
Thanks,
=0A=
  Anders
=0A=
 
=0A=

=0A=
=0A= Fra: roll-bounces@ietf.org p=E5 = vegne af Mukul Goyal
Sendt: ti 16-03-2010 02:56
Til: = roll
Emne: [Roll] Fwd: P2P performance with current RPL = proposal

=0A=
=0A=

Hi Pascal

I may not have been clear enough in = expressing the scalability concern I have. I was saying that
we can = not have "source-destination pair" specific route states in the = intermediate nodes. It would simply be unscalable. The approach you = described in your slides seemed to suggest that nodes maintain = "source-destination pair" specific route states (nodes maintain state = for DAG "R,i" with target "T"). Please let me know if this is not the = case.

The simple/regular distance vector approach I was referring = to means storing "destination(s)" specific routing states (i.e. the cost = to reach a particular destination(or destinations)) in the nodes so that = all the sources going to the same "destination" can benefit from this = state in both routing as well as route discovery (so, no need to flood = the RREQ/DIO further if I already know the cost to reach this = destination).

So, the scheme you proposed would work if we can = have a source (or multiple sources) build a DAG towards the destination = (or destinations) so that the DAG ranks/cost maintained by the nodes are = with respect to the destination(s) rather than the root(s)/source(s). = So, when another node needs to reach this destination, it can simply = join this DAG.

I hope I am clear enough this = time.

Thanks
Mukul
   
----- Original = Message -----
From: "Pascal Thubert (pthubert)" = <pthubert@cisco.com>
To: "Mukul Goyal" = <mukul@uwm.edu>
Cc: "ROLL WG" <roll@ietf.org>, "robert = cragie" <robert.cragie@gridmerge.com>, "Ted Humpal" = <Ted.Humpal@jci.com>
Sent: Monday, March 15, 2010 1:04:51 PM = GMT -06:00 US/Canada Central
Subject: RE: [Roll] P2P performance with = current RPL proposal

Hi Mukul

> 1. A node/router in the = middle may need to maintain state for multiple DAGs
> that lead to = the same destination. Consider the situation where 5 nearby
> = nodes need to find route to the same destination D. As per your = scheme,
> each node would form its own DAG towards the destination = D and the nodes
> in the middle would need to maintain state about = all 5 DAGs. This seems
> wasteful. You may argue that this is a = fit case for these 5 nodes to belong to a
> single DAG rooted at = D. But the problem is that D does not know that it is a
> = destination for these 5 nodes. So, in general, I see a scalability = problem
> associated with the use of DAGs for P2P routing. A = simple DV approach,
> where the nodes maintain information about = destinations (rather than
> DAGs), seems to avoid this scalability = problem.

[Pascal] I do not know what you call regular :)
RIP = usually maintains trees but eigrp allows for non-equal cost feasible = successors and thus builds DAGs.

AODV (Thomas, or Charlie if = you're listening, correct me if I'm wrong) builds and maintains routes = that are dotted lines between 2 points.

With RPL used reactively = as proposed here, we can do either way.

The OF can be designed to = build a tree and if so, we end up with something quite similar to = AODV/DYMO.
Or the OF wants a DAD for redundancy and we build a = DAG.

One cool thing is that we can request more than one target, = effectively building a DAG that looks like a flower.

It's not a = matter of scalability, it's a matter of what you cant to achieve and the = associated cost. DAG is more expensive than = tree.


>
> 2. So, in your scheme, the nodes timeout = the state they have for a DAG. This
> means that a node that does = not belong to the actual route taken by the
> packets would end up = timing out its state for this DAG. This is ok unless this
> node = is part of an obvious backup route and should have maintained
> = information about this DAG. It would be good to use the "routing = interest"
> concept in this situation. As per this concept, each = node maintains a "routing
> interest" in a particular DAG (or = destination). The routing interest is a metric
> between 0 and 1. = If a node is actively sending packets along the DAG, its
> routing = interest would be 1. Otherwise, the routing interest would be
> = x*max(routing interest of its nbrs), where x is a fraction. A node may = delete
> state about a DAG/destination if its routing interest in = that dag/destination
> drops below a threshold. The routing = interest concept would allow nodes
> "around' the actual path to = maintain state about this dag while other nodes
> can delete this = state after initial route discovery.
[Pascal]

Cool : ) Now = we're building a solution.

Pascal

>
> = Thanks
> Mukul
> ----- Original Message -----
> From: = "Pascal Thubert (pthubert)" <pthubert@cisco.com>
> To: = "robert cragie" <robert.cragie@gridmerge.com>, "Ted = Humpal"
> <Ted.Humpal@jci.com>
> Cc: "ROLL WG" = <roll@ietf.org>
> Sent: Monday, March 15, 2010 11:24:01 AM = GMT -06:00 US/Canada Central
> Subject: Re: [Roll] P2P performance = with current RPL = proposal
>
>
>
>
>
> HI Robert = :
>
>
>
> I respectfully have to = disagree.
>
>
>
> My understanding is that we = are considering a limited set of P2P pairs, for
> which the = specific path that we need to create might have to obey specific
> = constraints.
>
> So it makes sense to use an on-demand = technique, probably inspired by the
> MANET Reactive = protocols.
>
>
>
> As it goes, those protocols = usually use flooding for a node to locate another.
> Forking a DAG = is just another flooding. It does not take a lot of addition to = the
> existing DIO for a root to use RPL to build a DAG that = contains one or multiple
> Targets as leaves, under a set of = constraints expressed as an objective
> function. Please find = attached a slideware that illustrates = that.
>
>
>
>
> = Pascal
>
>
>
>
>
>
> From: = roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] = On Behalf Of
> Robert Cragie
> Sent: Thursday, March 11, = 2010 2:43 PM
> To: Ted.Humpal@jci.com
> Cc: ROLL WG
> = Subject: Re: [Roll] P2P performance with current RPL = proposal
>
>
>
> I agree with Ted's comments = below. Creating a DODAG for every reachable
> node as a root seems = a very inefficient approach compared to alternative
> routing = algorithms. I am concerned that RPL does not actually meet the
> = original requirements in I-D.ietf-roll-building-routing-reqs, = I-D.ietf-roll-home-
> routing-reqs, RFC5673 and RFC5548. The = traffic pattern requirement for a
> sink node features prominently = in only two of those documents. Even in this
> case, as Ted points = out, communication is likely to be bidirectional (e.g. end-
> = to-end acks.) therefore the DODAG approach is fundamentally = asymmetric,
> especially if no intermediate storage is allowed for = destination routes and
> source routing has to be = used.
>
> Also, RPL seems highly complex for what are = constrained nodes in terms of
> memory as well as power and = bandwidth. The RPL draft as it stands is 82
> pages long and that = doesn't include text about the objective function.
>
> = Robert
>
>
> Robert Cragie (Pacific Gas & = Electric)
>
> Gridmerge Ltd.
> 89 Greenfield = Crescent,
> Wakefield, WF4 4WA, UK
> +44 (0) 1924 = 910888
> http://www.gridmerge.com
>>
>
> Ted.Humpal@jci.com wrote:
>
>
> = A concern also will be how much overhead (memory space) will be = required
> for a DODAG Root?
>
> and based on the = first question how many DODAG roots a lamp may need to
> be a = member of?
>
> For example in lighting  a single lamp = may be a root for a single switch (1
> DODAG root),  this = lamp / luminaire may also
> be a member of another group - -  = which could be all lights on the floor (2nd
> DODAG root), and a = third group
> of all the lights in the building.  There can = be many more speciality groups
> associated based on the building = configuration.
> Consider also during the installation time - how = these DODAG roots will be
> configured?  Must I commission = each device
> to tell it which DODAG it must use for its Object = Function?  How easy will this
> be to change and add in a new = DODAG root
> for the end user if the lighting group = changes??
>
> With respect to Jerry Martocci's - commercial = building requirements - every
> device may need to communicate to = any or
> all of the end devices.  If each device must = establish a DODAG for the other
> 499 devices in a 500 node = network - How much memory
> space will this require for each end = device to maintain?
>
> Keep in mind that the end devices = are very limited processor and memory
> wise.
>
> Not = to mention all of the network maintenance messages that would = need
> to be transmitted to maintain all of these = DODAGs.
>
> Consider the reconvergence time when one device = is turned off and it was in
> the middle of the majority of the = 100+ DODAGS?
>
> In many lighting and building application = an application acknowledgement -
> must be returned {Back down the = DODAG} so . . . the
> requirement is not just getting to the Root = - a return path must also be
> maintained and have a  low = latency path.
>
> Ted = Humpal
>
>
>
>
>
> = From:
>
> Kris Pister = <pister@eecs.berkeley.edu>
>
>
> = To:
>
> Anders Brandt = <abr@sdesigns.dk>
>
>
> Cc:
>
> ROLL = WG <roll@ietf.org>
>
>
> Date:
>
> = 03/08/2010 01:45 PM
>
>
> Subject:
>
> Re: = [Roll] P2P performance with current RPL = proposal
>
>
>
>
>
>
>
><= BR>> Anders - if we take JP's suggestion to make The Lamp a DODAG = root, and
> take Phoebus' recommendation that we use path = diversity to improve end-
> to-end reliability, do you see a = chance of success?
> In my experience, with diverse paths and = order-minutes updates you get
> extremely high = reliability.
>
> I have no aversion to TTL-limited floods as = a part of a solution either.  I'm
> open to ideas on how to = bring those in as (presumably infrequently used)
> = options.
>
> ksjp
>
> Anders Brandt = wrote:
> Hello
>
> I would like to probe the = temperature of the WG on using DAOs to
> support = P2P.
>
> The building and home application spaces (and maybe = others) have
> a few clearly defined requirements.
> It is = not obvious to me how the current RPL proposal (cRPLp) can
> = satisfy those requirements:
>
>
> In both cases it is = the worst case scenario that hurts:
>
>
> P2P routing = inside the PAN
> = =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
> cRPLp has no way of routing inside the PAN if you need more = than
> one repeater. cRPLp has to go all the way to the top (maybe = 4 hops up)
> and down again (maybe 4 hops down) to get just 2 hops = to the side.
>
> The consequence is high latency and high = levels of background noise
> for nodes just outside the direct = radio range.
> At the same time the risk of meeting a failing link = is 4 times higher =3D>
> latency may be much more than 4 times = larger.
>
> Latency may sound like a minor issue but it = actually translates directly
> into lower battery lifetime. In the = above (very realistic) example,
> the battery lifetime is reduced = to 25% of what it should be.
>
> We have lots of battery = devices sending into the network:
> * PIR sensors turning on = lights
> * Door locks sending alarms
> * Door/window sensors = starting chimes
> * Smoke sensors triggering an alarm = system
>
>
>
>
> Response time
> = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> The latency issue is = important.
> When a user (real human being) presses a light button = the user expects
> the light to turn on.
> cRPLp proposes = that nodes in the tree periodically advertises their
> presence = using DAOs.
> The periodicity is a real beast:
> Thanks to = Trickle, the rate of updates in a (apparently) stable network
> is = low. This is good since it leaves bandwidth for data.
> But it is = not good if existing routes to my lamp fail and I do not get
> new = routes to my lamp until it decides to send out a new DAO.
> My = user will (with a good reason) not tolerate waiting for minutes = for
> the light to turn on.
>
> I have met two = arguments to counter this concern:
>
> A1: Well, your lamp = can always send a DAO when it detects a problem.
>   My = answer:
>   True, except that my lamp does not intend to = send anything
>   so it will never experience any = problems from its side of the network.
>
> A2: Well, you can = increase the DAO rate to sub-second updates.
>   My = answer:
>   Oh no. I get a very high degree of = management traffic which
>   limits my available = bandwidth, increases the risk of collisions and
>   even = run the risk of violating EU legislation requiring me to = only
>   transmit in less than 1% of the = time:
>   http://focus.ti.c= om/lit/an/swra048/swra048.pdf
>  868 - 868.6 MHz: = <1%
>
>   Reactiveness is hard to achieve via = polling.
>
>
>
> If you agree that this seems to = be critical issues please raise your
> voice on the = list.
>
> Going forward
> = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>
> We need some = reactive mechanism to reach lamps before the user decides
> to sue = our companies.
> So is this possible? I think so.
>
> = Existing commercial (non-IP) solutions are capable of re-routing = quickly
> if they really have to.
>
> Let me try = scoping the requirements to a potential solution:
> (no different = from the req. docs for home and building)
>
> * P2P routing = in any direction independent of the tree.
>
> * On-demand = P2P route discovery if requested by a real-time critical = app.
>  Data collection apps may be able to just wait for the = next DAO update.
>
> * Limited range of discovery mechanism: = max 4 repeaters.
>   A TTL field may limit the scope of = the repeaters.
>
> * Suboptimal routing and traffic bursts = are accepted in exchange
>   for quick route repair. But = only as an exception.
>
>
> Just as an example, one = existing home control technology uses a
> (source routing) variant = of AODV for quick route repair.
> Nothing comes for free. The = price is flooding - but not just flooding:
> Managed flooding = using a distributed algorithm running in all
> participating = nodes.
> The algorithm dampens the flooding in a time, volume and = range
> perspective.
> Some similar mechanism could be built = into RPL for quick route repair.
>
>
> If anyone have = alternative proposals, please bring it to the list.
> Now is the = time.
>
>
>
> Thanks,
>   = Anders
>
>
>
>
> = _______________________________________________
> Roll mailing = list
> Roll@ietf.org
> https://www.ietf.org/= mailman/listinfo/roll
>   = _______________________________________________
> 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
____________________________________________= ___
Roll mailing list
Roll@ietf.org
https://www.ietf.org/= mailman/listinfo/roll

------_=_NextPart_001_01CAC5F2.CDCD470E-- From alexandru.petrescu@gmail.com Wed Mar 17 10:07: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 C87303A67A3 for ; Wed, 17 Mar 2010 10:07:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.539 X-Spam-Level: X-Spam-Status: No, score=-1.539 tagged_above=-999 required=5 tests=[AWL=-0.420, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, 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 JjRaNIflPTqs for ; Wed, 17 Mar 2010 10:07:07 -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 2D91D3A6A48 for ; Wed, 17 Mar 2010 10:07: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 o2HH790M025173 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Wed, 17 Mar 2010 18:07:09 +0100 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.2/8.14.2) with ESMTP id o2HH79Va031183 for ; Wed, 17 Mar 2010 18:07:09 +0100 (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 o2HH78QY023168 for ; Wed, 17 Mar 2010 18:07:09 +0100 Message-ID: <4BA10C3C.7060003@gmail.com> Date: Wed, 17 Mar 2010 18:07:08 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.9.1.8) Gecko/20100227 Thunderbird/3.0.3 MIME-Version: 1.0 To: roll@ietf.org References: <055.a3c60804880e85f93fc1826167be4fb6@tools.ietf.org> <064.2fcbbc9928617712d033305fbb1562c6@tools.ietf.org> In-Reply-To: <064.2fcbbc9928617712d033305fbb1562c6@tools.ietf.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [Roll] [roll] #20: Question on Metric 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: Wed, 17 Mar 2010 17:07:07 -0000 How about using RTT too? RTT Round Trip Time is inherent in protocols such as TCP, and is typically measured by ping available on many platforms. RTT could be accurately measured and compared between different implementations. Alex Le 17/03/2010 02:58, roll issue tracker a écrit : > #20: Question on Metric ID > --------------------------------+------------------------------------------- > Reporter: jpv@… | Owner: mjkim@… > Type: defect | Status: closed > Priority: major | Milestone: > Component: routing-metrics | Version: > Severity: Active WG Document | Resolution: fixed > Keywords: | > --------------------------------+------------------------------------------- > Changes (by mjkim@…): > > * status: new => closed > * resolution: => fixed > > > Comment: > > After long discussion, we concluded as follows: > > - Throughput: 32 unsigned integer in unit of microsecond > > - Latency: 24 unsigned integer in unit of bytes per second > > - ETX: 1 byte to present (ETX * C) as (32 + a) * 2^b > where C = 64, 0<= a<= 31 and 0<= b<= 7. > If ETX>= 126, we can assume ETX is infinity. > (First 5 bits for a and the rest 3 bits for b.) > > Thanks, > Mijeom. > From Matteo.Paris@ember.com Wed Mar 17 10:40: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 62BB63A6952 for ; Wed, 17 Mar 2010 10:40:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.734 X-Spam-Level: X-Spam-Status: No, score=-0.734 tagged_above=-999 required=5 tests=[AWL=-1.865, 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 ttu+Nu+YNw35 for ; Wed, 17 Mar 2010 10:40:52 -0700 (PDT) Received: from EMPIRE.hq.ember.com (mail.ember.com [74.10.175.227]) by core3.amsl.com (Postfix) with ESMTP id 16AFE3A693D for ; Wed, 17 Mar 2010 10:40:51 -0700 (PDT) Received: from [192.168.1.102] ([192.168.81.18]) by EMPIRE.hq.ember.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 17 Mar 2010 13:43:47 -0400 Mime-Version: 1.0 Message-Id: Date: Wed, 17 Mar 2010 13:40:59 -0500 To: roll@ietf.org From: Matteo Paris Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-OriginalArrivalTime: 17 Mar 2010 17:43:47.0765 (UTC) FILETIME=[65B94650:01CAC5F9] Subject: [Roll] Two minor comments on 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, 17 Mar 2010 17:40:53 -0000 Two minor comments on draft-ietf-roll-rpl-07: 1. The link-local multicast address used for sending RPL control messages should be explicitly specified as the all-routers multicast address, FF02::2. It is currently ambiguous. 2. Because the rank increased from one to two bytes, the DAGMaxRankIncrease and MinHopRankIncrease configuration parameters have insufficient range. For example, OF0 specifies a MinHopRankIncrease of 256, which is out of range of the configuration parameter. Two possible solutions: a) Increase the size of the configuration parameters to two bytes each. b) Decrease the size of the configuration parameters to four bits each, and interpret their value as the base 2 logarithm of the increase amount. I prefer solution b) since it is natural to specify those values as a power of two, particularly MinHopRankIncrease. It also saves 3 bytes. Matteo From Matteo.Paris@ember.com Wed Mar 17 12:40: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 633AC3A6954 for ; Wed, 17 Mar 2010 12:40:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.205 X-Spam-Level: X-Spam-Status: No, score=-0.205 tagged_above=-999 required=5 tests=[AWL=-1.150, BAYES_40=-0.185, 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 pTOmljyYbQM6 for ; Wed, 17 Mar 2010 12:40:21 -0700 (PDT) Received: from EMPIRE.hq.ember.com (mail.ember.com [74.10.175.227]) by core3.amsl.com (Postfix) with ESMTP id 6861E3A67AB for ; Wed, 17 Mar 2010 12:40:21 -0700 (PDT) Received: from [192.168.1.102] ([192.168.81.18]) by EMPIRE.hq.ember.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 17 Mar 2010 15:43:17 -0400 Mime-Version: 1.0 Message-Id: Date: Wed, 17 Mar 2010 15:40:30 -0500 To: roll@ietf.org From: Matteo Paris Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-OriginalArrivalTime: 17 Mar 2010 19:43:17.0484 (UTC) FILETIME=[173592C0:01CAC60A] Subject: [Roll] DIS filtering X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 17 Mar 2010 19:40:22 -0000 Every recipient of a multicast DIS must reset its trickle timer for every DAG it belongs to. I'm concerned with how to minimize the burst of control message activity this will cause in a dense network with multiple DAGs. It is often the case that the node sending the DIS message has information that could reduce the number of responses necessary. For example, it may know the DAG id, instance id, or destination prefix(es) that it is interested in. By including this in the DIS, receiving nodes could avoid resetting trickle timers for DAGs that do not match the desired criteria. Another option to reduce control messages would be for nodes receiving a multicast DIS to respond with a single (jittered) DIO, but not reset their trickle timer. This is slightly more complicated to implement than just resetting the timer, but could save a lot of control overhead. Matteo From gnawali@cs.stanford.edu Wed Mar 17 18:42: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 410893A6964 for ; Wed, 17 Mar 2010 18:42:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.947 X-Spam-Level: X-Spam-Status: No, score=-4.947 tagged_above=-999 required=5 tests=[AWL=-0.100, 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 9oQRrnesEYDX for ; Wed, 17 Mar 2010 18:42:11 -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 403DD3A68DD for ; Wed, 17 Mar 2010 18:42:11 -0700 (PDT) Received: from qw-out-2122.google.com ([74.125.92.25]) by cs-smtp-3.Stanford.EDU with esmtpsa (TLSv1:RC4-MD5:128) (Exim 4.60) (envelope-from ) id 1Ns4kf-00030U-Tp for roll@ietf.org; Wed, 17 Mar 2010 18:42:22 -0700 Received: by qw-out-2122.google.com with SMTP id 5so194120qwd.31 for ; Wed, 17 Mar 2010 18:42:21 -0700 (PDT) MIME-Version: 1.0 Received: by 10.224.65.217 with SMTP id k25mr551052qai.170.1268876539143; Wed, 17 Mar 2010 18:42:19 -0700 (PDT) In-Reply-To: References: <055.a3c60804880e85f93fc1826167be4fb6@tools.ietf.org> <064.2fcbbc9928617712d033305fbb1562c6@tools.ietf.org> <87pr333z1s.fsf@kelsey-ws.hq.ember.com> From: Omprakash Gnawali Date: Wed, 17 Mar 2010 18:41:59 -0700 Message-ID: To: Philip Levis Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Scan-Signature: 67f4a389e065da33eb5969ecb4726704 Cc: roll@ietf.org Subject: Re: [Roll] [roll] #20: Question on Metric 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, 18 Mar 2010 01:42:12 -0000 On Wed, Mar 17, 2010 at 8:18 AM, Philip Levis wrote: > > On Mar 17, 2010, at 5:36 AM, Richard Kelsey wrote: > >>> From: "roll issue tracker" >>> Date: Wed, 17 Mar 2010 01:58:04 -0000 >>> >>> #20: Question on Metric ID >>> >>> Comment: >>> >>> =A0After long discussion, we concluded as follows: >>> >>> =A0- Throughput: 32 unsigned integer in unit of microsecond >>> >>> =A0- Latency: 24 unsigned integer in unit of bytes per second >>> >>> =A0- ETX: 1 byte to present (ETX * C) as (32 + a) * 2^b >>> =A0 where C =3D 64, 0 <=3D a <=3D 31 and 0 <=3D b <=3D 7. >>> =A0 If ETX >=3D 126, we can assume ETX is infinity. >>> =A0(First 5 bits for a and the rest 3 bits for b.) >> >> I applaud the decision not to use floating point for >> throughput and latency. =A0Can we please do the same for ETX? >> Many of the same arguments apply to it as well (e.g. >> http://www.ietf.org/mail-archive/web/roll/current/msg03104.html). >> Make it ETX * 64 as a 16-bit unsigned integer. > > +1 > > Phil +1 for not using floating point for ETX. - om_p From robert.assimiti@nivis.com Thu Mar 18 13: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 8C9043A697A for ; Thu, 18 Mar 2010 13:24:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.448 X-Spam-Level: * X-Spam-Status: No, score=1.448 tagged_above=-999 required=5 tests=[AWL=-0.682, BAYES_60=1, DNS_FROM_OPENWHOIS=1.13, 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 zQmlhssWGcFq for ; Thu, 18 Mar 2010 13:24:25 -0700 (PDT) Received: from smtp.nivis.com (smtp.nivis.com [65.205.163.2]) by core3.amsl.com (Postfix) with ESMTP id DA94C3A67D7 for ; Thu, 18 Mar 2010 13:24:24 -0700 (PDT) Received: from ATLEXCH02.nivis.com ([10.0.0.18]) by ATLEXCH02.nivis.com ([10.0.0.18]) with mapi; Thu, 18 Mar 2010 16:24:36 -0400 From: Robert Assimiti To: "roll@ietf.org" Date: Thu, 18 Mar 2010 16:24:28 -0400 Thread-Topic: Triggering a new DODAG iteration Thread-Index: AcrG2QJXRfv/f0MATFqqv3obzcLwwA== Message-ID: <67442429D9C35E4C975B89BE73BD33D015FB214273@ATLEXCH02.nivis.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-cr-hashedpuzzle: AOlf BfPt BxOX CknX DfGk FZdw FdHD FnsP Fu/t GTxU GiPF Gw91 H4ME IZ75 It3I JXir; 1; cgBvAGwAbABAAGkAZQB0AGYALgBvAHIAZwA=; Sosha1_v1; 7; {93FBF4AD-9233-4786-8ED6-00E604EE2389}; cgBvAGIAZQByAHQALgBhAHMAcwBpAG0AaQB0AGkAQABuAGkAdgBpAHMALgBjAG8AbQA=; Thu, 18 Mar 2010 20:24:28 GMT; VAByAGkAZwBnAGUAcgBpAG4AZwAgAGEAIABuAGUAdwAgAEQATwBEAEEARwAgAGkAdABlAHIAYQB0AGkAbwBuAA== x-cr-puzzleid: {93FBF4AD-9233-4786-8ED6-00E604EE2389} acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_67442429D9C35E4C975B89BE73BD33D015FB214273ATLEXCH02nivi_" MIME-Version: 1.0 Subject: [Roll] Triggering a new DODAG iteration X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 18 Mar 2010 20:24:30 -0000 --_000_67442429D9C35E4C975B89BE73BD33D015FB214273ATLEXCH02nivi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable As you can imagine, triggering a new DODAG iteration in a wireless subnet t= hat scales to thousands of wireless nodes can be quite disruptive to the op= eration of the subnet. The criteria that will trigger a new DODAG iteration should (in my opinion)= be left to the implementation. The decision of triggering a new DODAG iteration lies with the root. A well informed root can make better decisions than an un-informed root. Hence I propose that we discuss additional standardized error messages repo= rted by the routers. At this point nodes can flag rank and forwarding errors through the usage o= f the 'R' and 'F' bits present in the flow label. In my opinion, this is a very limited set of error messages. Since we are seeking interoperability, we should define a new ICMPv6 error= message that allows the nodes to report various DODAG inconsistencies and = discrepancies with more details and precision than the 'R' and 'F' bits. Some suggestions for potential reported errors: 1. Preferred parent not reachable 2. Parent not reachable 3. Parent set nears depletion Etc ....etc Armed with this information (sent in an interoperable manner) the root is n= ow capable of making a more informed decision when to trigger a new DODAG i= teration. Any thoughts? Suggestions? Robert Assimiti Office: [678]-202-6859 Mobile: [404]-578-0205 robert.assimiti@nivis.com ________________________________ This e-mail (including any attachments to it) is confidential, proprietary,= legally privileged, subject to copyright and is sent for the personal atte= ntion of the intended recipient only. If you have received this e-mail in e= rror, please reply to advise us immediately, delete it and destroy any prin= ted copies of it. You are notified that reading, disclosing, copying, distr= ibuting or taking any action in reliance on the contents of this informatio= n is strictly prohibited. No employee is authorized to conclude any binding= agreement on behalf of NIVIS LLC with another party by e-mail without expr= ess written confirmation by an officer of the company. Although we have tak= en reasonable precautions to ensure no viruses are present in this e-mail, = we cannot accept responsibility for any loss or damage arising from the vir= uses in this e-mail or attachments. --_000_67442429D9C35E4C975B89BE73BD33D015FB214273ATLEXCH02nivi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

As yo= u can imagine, triggering a new DODAG iteration in a wireless subnet that s= cales to thousands of wireless nodes can be quite disruptive to the operati= on of the subnet.

=  

The c= riteria that will trigger a new DODAG iteration should (in my opinion) be l= eft to the implementation.

The d= ecision of triggering a new DODAG iteration lies with the root.

A wel= l informed root can make better decisions than an un-informed root.

=  

Hence= I propose that we discuss additional standardized error messages reported = by the routers.

At th= is point nodes can flag rank and forwarding errors through the usage of the= ‘R’ and ‘F’ bits present in the flow label.

=  

In my= opinion, this is a very limited set of error messages.

Since= we are seeking interoperability,  we should define a new ICMPv6 error= message that allows the nodes to report various DODAG inconsistencies and = discrepancies with more details and precision than the ‘R’ and ‘F’ bits.

Some = suggestions for potential reported errors:

1.       Preferred parent not reachable

2.       Parent not reachable

3.       Parent set nears depletion

Etc ….etc

 

Armed with this information (sent in an interoperable manner= ) the root is now capable of making a more informed decision when to trigge= r a new DODAG iteration.

 

Any thoughts? Suggestions?

=  

=  

=  

=  

Robert= Assimiti

Office= : [678]-202-6859

Mobile= : [404]-578-0205

robert.as= simiti@nivis.com

 


This e-mail (including any a= ttachments to it) is confidential, proprietary, legally privileged, subject= to copyright and is sent for the personal attention of the intended recipi= ent only. If you have received this e-mail in error, please reply to advise us immediately, delete it and destroy any= printed copies of it. You are notified that reading, disclosing, copying, = distributing or taking any action in reliance on the contents of this infor= mation is strictly prohibited. No employee is authorized to conclude any binding agreement on behalf of NIVI= S LLC with another party by e-mail without express written confirmation by = an officer of the company. Although we have taken reasonable precautions to= ensure no viruses are present in this e-mail, we cannot accept responsibility for any loss or damage arisin= g from the viruses in this e-mail or attachments.
 --_000_67442429D9C35E4C975B89BE73BD33D015FB214273ATLEXCH02nivi_-- From pthubert@cisco.com Thu Mar 18 15:33: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 66F5B3A6827 for ; Thu, 18 Mar 2010 15:33:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.159 X-Spam-Level: X-Spam-Status: No, score=-7.159 tagged_above=-999 required=5 tests=[AWL=-0.105, BAYES_40=-0.185, DNS_FROM_OPENWHOIS=1.13, 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 7QFBN0Ym976v for ; Thu, 18 Mar 2010 15:33:00 -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 E57A83A6452 for ; Thu, 18 Mar 2010 15:32:59 -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: AkMBAL5GokuQ/uCWe2dsb2JhbACBRJlqFQEBCwskBhyjd4sTCY1hAoJlghIE X-IronPort-AV: E=Sophos;i="4.51,269,1267401600"; d="scan'208,217";a="58254798" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 18 Mar 2010 22:33: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 o2IMXAdx002211; Thu, 18 Mar 2010 22:33: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); Thu, 18 Mar 2010 23:33:10 +0100 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_01CAC6EA.FCEFEB57" Date: Thu, 18 Mar 2010 23:33:05 +0100 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D01792E3C@XMB-AMS-107.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] Triggering a new DODAG iteration Thread-Index: AcrG6vlRuB55h/aLSs+69ctadjLZeg== From: "Pascal Thubert (pthubert)" To: "Robert Assimiti" , X-OriginalArrivalTime: 18 Mar 2010 22:33:10.0692 (UTC) FILETIME=[FD3F6E40:01CAC6EA] Subject: Re: [Roll] Triggering a new DODAG iteration X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 18 Mar 2010 22:33:06 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CAC6EA.FCEFEB57 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable HI Robert : =20 This makes a lot of sense to me. Other root decisions like a source route path selection could also benefit from such error/info reporting. =20 Pascal =20 From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Robert Assimiti Sent: Thursday, March 18, 2010 1:24 PM To: roll@ietf.org Subject: [Roll] Triggering a new DODAG iteration =20 As you can imagine, triggering a new DODAG iteration in a wireless subnet that scales to thousands of wireless nodes can be quite disruptive to the operation of the subnet. =20 The criteria that will trigger a new DODAG iteration should (in my opinion) be left to the implementation. The decision of triggering a new DODAG iteration lies with the root.=20 A well informed root can make better decisions than an un-informed root. =20 Hence I propose that we discuss additional standardized error messages reported by the routers. At this point nodes can flag rank and forwarding errors through the usage of the 'R' and 'F' bits present in the flow label. =20 In my opinion, this is a very limited set of error messages.=20 Since we are seeking interoperability, we should define a new ICMPv6 error message that allows the nodes to report various DODAG inconsistencies and discrepancies with more details and precision than the 'R' and 'F' bits.=20 Some suggestions for potential reported errors: 1. Preferred parent not reachable 2. Parent not reachable 3. Parent set nears depletion Etc ....etc =20 Armed with this information (sent in an interoperable manner) the root is now capable of making a more informed decision when to trigger a new DODAG iteration. =20 Any thoughts? Suggestions? =20 =20 =20 =20 Robert Assimiti Office: [678]-202-6859 Mobile: [404]-578-0205 robert.assimiti@nivis.com =20 =20 ________________________________ This e-mail (including any attachments to it) is confidential, proprietary, legally privileged, subject to copyright and is sent for the personal attention of the intended recipient only. If you have received this e-mail in error, please reply to advise us immediately, delete it and destroy any printed copies of it. You are notified that reading, disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited. No employee is authorized to conclude any binding agreement on behalf of NIVIS LLC with another party by e-mail without express written confirmation by an officer of the company. Although we have taken reasonable precautions to ensure no viruses are present in this e-mail, we cannot accept responsibility for any loss or damage arising from the viruses in this e-mail or attachments. ------_=_NextPart_001_01CAC6EA.FCEFEB57 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

HI = Robert :

 

This makes = a lot of sense to me. Other root decisions like a source route path = selection could also benefit from such error/info = reporting.

 

Pascal

 

From:= = roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of = Robert Assimiti
Sent: Thursday, March 18, 2010 1:24 = PM
To: roll@ietf.org
Subject: [Roll] Triggering a = new DODAG iteration

 

As you can = imagine, triggering a new DODAG iteration in a wireless subnet that = scales to thousands of wireless nodes can be quite disruptive to the = operation of the subnet.

 

The criteria that will trigger = a new DODAG iteration should (in my opinion) be left to the = implementation.

The decision of = triggering a new DODAG iteration lies with the root. =

A well informed root can make = better decisions than an un-informed root.

 

Hence I propose that we discuss = additional standardized error messages reported by the = routers.

At this point nodes can flag = rank and forwarding errors through the usage of the ‘R’ and = ‘F’ bits present in the flow label.

 

In my opinion, this is a very = limited set of error messages.

Since we are seeking = interoperability,  we should define a new ICMPv6 error message that = allows the nodes to report various DODAG inconsistencies and = discrepancies with more details and precision than the ‘R’ = and ‘F’ bits.

Some suggestions for potential = reported errors:

1.       = Preferred parent not = reachable

2.       = Parent not = reachable

3.       = Parent set nears = depletion

Etc = ….etc

 

Armed with this information = (sent in an interoperable manner) the root is now capable of making a = more informed decision when to trigger a new DODAG = iteration.

 

Any thoughts? = Suggestions?

 

 

 

 

Robert Assimiti

Office: = [678]-202-6859

Mobile: = [404]-578-0205

robert.assimiti@nivis.com

 

 

Thi= s e-mail (including any attachments to it) is confidential, proprietary, = legally privileged, subject to copyright and is sent for the personal = attention of the intended recipient only. If you have received this = e-mail in error, please reply to advise us immediately, delete it and = destroy any printed copies of it. You are notified that reading, = disclosing, copying, distributing or taking any action in reliance on = the contents of this information is strictly prohibited. No employee is = authorized to conclude any binding agreement on behalf of NIVIS LLC with = another party by e-mail without express written confirmation by an = officer of the company. Although we have taken reasonable precautions to = ensure no viruses are present in this e-mail, we cannot accept = responsibility for any loss or damage arising from the viruses in this = e-mail or attachments.

------_=_NextPart_001_01CAC6EA.FCEFEB57-- From pthubert@cisco.com Thu Mar 18 19:23: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 E93263A6CE9 for ; Thu, 18 Mar 2010 19:23:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.061 X-Spam-Level: X-Spam-Status: No, score=-7.061 tagged_above=-999 required=5 tests=[AWL=-0.193, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, 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 GuN8mFayf-PQ for ; Thu, 18 Mar 2010 19:23: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 EE0C23A6CD4 for ; Thu, 18 Mar 2010 19:23:05 -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: AgEFAON8okurR7Hu/2dsb2JhbACBRJlrc6JumQOEeQQ X-IronPort-AV: E=Sophos;i="4.51,272,1267401600"; d="scan'208,217";a="499221285" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-6.cisco.com with ESMTP; 19 Mar 2010 02:23:17 +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 o2J2NGqh002499; Fri, 19 Mar 2010 02:23:16 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, 19 Mar 2010 03:23:15 +0100 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_01CAC70B.210F5DCA" Date: Fri, 19 Mar 2010 03:23:14 +0100 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D01792E48@XMB-AMS-107.cisco.com> In-Reply-To: <4B9E7BE8.9060109@gridmerge.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] P2P performance with current RPL proposal Thread-Index: AcrEbU1tfn0308v7QGeWK3YmnqapOAClmO0Q References: <6D9687E95918C04A8B30A7D6DA805A3E01429F5F@zensys17.zensys.local> <4B9553B8.6010001@eecs.berkeley.edu> <4B98F374.4030301@gridmerge.com> <6A2A459175DABE4BB11DE2026AA50A5D0170DFA9@XMB-AMS-107.cisco.com> <4B9E7BE8.9060109@gridmerge.com> From: "Pascal Thubert (pthubert)" To: X-OriginalArrivalTime: 19 Mar 2010 02:23:15.0211 (UTC) FILETIME=[2161DDB0:01CAC70B] Cc: ROLL WG , Ted.Humpal@jci.com Subject: Re: [Roll] P2P performance with current RPL proposal X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Mar 2010 02:23:41 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CAC70B.210F5DCA Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Robert : =20 At least from a distance, the proposed mechanism emulates AODV, with the DIO as RREQ and the DAO as RREP. So if we decide to dig along those lines, we'll certainly appreciate help from MANET experts. I'd say that if you already have RPL for P2MP and MP2P, the proposed extension are probably simpler to add than doing AODV from scratch. =20 For the setup, the major differences are that we build a DAG and that we can indicate multiple targets. If you look at it, the DAG capability is a MUST for RPL, and I have not seen that this MUST goes away for P2P flows. The multiple targets is something that appears in a number of use cases and it seems more economical to build a single DAG for multiple targets when possible. =20 For the maintenance, the major differences are that we have the DAG as first line of defense, and the RPL detection to stimulate the local repair. =20 About your questions: =20 The DODAG root is the one that spawns the DAG. The targets can reach the root because the root advertises itself in the DIO. The idea is that the root ID is the address that the targets need to talk to. If needed, the root can also advertise a prefix that it can reach and that the targets need to reach too. =20 All the intermediate nodes that are confirmed by the DAO need to retain at least info about the DAG. That enables the targets to reach the root. The flooding should cost about the same as that of AODV but the RPL way will require more states in the nodes on the way if the OF requires a DAG. =20 The way back (down) can be stateful of stateless, depending on which DAO we're using. With fully stateful DAO, we are really in AODV-land. With stateless, we could drift into DSR-land for that direction. Which limits we place to keep it simple will be determined by the resolution of issue #26 I guess... =20 And please, no apologize or on one will dare post anything anymore. Your questions are fully relevant and at the core of the discussion. =20 I hope we can talk in Anaheim for sure, Pascal =20 From: Robert Cragie [mailto:robert.cragie@gridmerge.com]=20 Sent: Monday, March 15, 2010 11:27 AM To: Pascal Thubert (pthubert) Cc: Ted.Humpal@jci.com; ROLL WG Subject: Re: [Roll] P2P performance with current RPL proposal =20 Hi Pascal, So in your slideware T can end up talking to R (DODAG root) through the DODAG. So are you proposing that all potential targets can act as a DODAG root? And therefore all intermediates have to retain DIO propagation support for that DODAG as well? This may work for limited P2P but seems less efficient than simple distance vector flooding RREQ/RREP like AODV or DYMO for generic P2P. What about R to T (or anyone else for that matter)? Do we source route, maintain state, some undefined hybrid of the two? I apologise if some of these questions have been answered in detail in earlier reflector posts but I have only recently started to concentrate my efforts on RPL and have 82 pages to wade through :-). I look forward to a productive session in Anaheim. Robert Robert Cragie (Pacific Gas & Electric) Gridmerge Ltd. 89 Greenfield Crescent, Wakefield, WF4 4WA, UK +44 (0) 1924 910888 http://www.gridmerge.com =20 Pascal Thubert (pthubert) wrote:=20 HI Robert : =20 I respectfully have to disagree. =20 My understanding is that we are considering a limited set of P2P pairs, for which the specific path that we need to create might have to obey specific constraints.=20 So it makes sense to use an on-demand technique, probably inspired by the MANET Reactive protocols. =20 As it goes, those protocols usually use flooding for a node to locate another. Forking a DAG is just another flooding. It does not take a lot of addition to the existing DIO for a root to use RPL to build a DAG that contains one or multiple Targets as leaves, under a set of constraints expressed as an objective function. Please find attached a slideware that illustrates that. =20 Pascal =20 From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Robert Cragie Sent: Thursday, March 11, 2010 2:43 PM To: Ted.Humpal@jci.com Cc: ROLL WG Subject: Re: [Roll] P2P performance with current RPL proposal =20 I agree with Ted's comments below. Creating a DODAG for every reachable node as a root seems a very inefficient approach compared to alternative routing algorithms. I am concerned that RPL does not actually meet the original requirements in I-D.ietf-roll-building-routing-reqs, I-D.ietf-roll-home-routing-reqs, RFC5673 and RFC5548. The traffic pattern requirement for a sink node features prominently in only two of those documents. Even in this case, as Ted points out, communication is likely to be bidirectional (e.g. end-to-end acks.) therefore the DODAG approach is fundamentally asymmetric, especially if no intermediate storage is allowed for destination routes and source routing has to be used. Also, RPL seems highly complex for what are constrained nodes in terms of memory as well as power and bandwidth. The RPL draft as it stands is 82 pages long and that doesn't include text about the objective function. Robert Robert Cragie (Pacific Gas & Electric) Gridmerge Ltd. 89 Greenfield Crescent, Wakefield, WF4 4WA, UK +44 (0) 1924 910888 http://www.gridmerge.com =20 Ted.Humpal@jci.com wrote:=20 A concern also will be how much overhead (memory space) will be required for a DODAG Root?=20 and based on the first question how many DODAG roots a lamp may need to be a member of?=20 For example in lighting a single lamp may be a root for a single switch (1 DODAG root), this lamp / luminaire may also=20 be a member of another group - - which could be all lights on the floor (2nd DODAG root), and a third group=20 of all the lights in the building. There can be many more speciality groups associated based on the building configuration.=20 Consider also during the installation time - how these DODAG roots will be configured? Must I commission each device=20 to tell it which DODAG it must use for its Object Function? How easy will this be to change and add in a new DODAG root=20 for the end user if the lighting group changes??=20 With respect to Jerry Martocci's - commercial building requirements - every device may need to communicate to any or=20 all of the end devices. If each device must establish a DODAG for the other 499 devices in a 500 node network - How much memory=20 space will this require for each end device to maintain? =20 Keep in mind that the end devices are very limited processor and memory wise.=20 Not to mention all of the network maintenance messages that would need to be transmitted to maintain all of these DODAGs.=20 Consider the reconvergence time when one device is turned off and it was in the middle of the majority of the 100+ DODAGS?=20 In many lighting and building application an application acknowledgement - must be returned {Back down the DODAG} so . . . the=20 requirement is not just getting to the Root - a return path must also be maintained and have a low latency path.=20 Ted Humpal=20 From:=20 Kris Pister To:=20 Anders Brandt =20 Cc:=20 ROLL WG =20 Date:=20 03/08/2010 01:45 PM=20 Subject:=20 Re: [Roll] P2P performance with current RPL proposal =20 ________________________________ Anders - if we take JP's suggestion to make The Lamp a DODAG root, and take Phoebus' recommendation that we use path diversity to improve end-to-end reliability, do you see a chance of success? In my experience, with diverse paths and order-minutes updates you get extremely high reliability. I have no aversion to TTL-limited floods as a part of a solution either. I'm open to ideas on how to bring those in as (presumably infrequently used) options. ksjp Anders Brandt wrote:=20 Hello=20 =20 I would like to probe the temperature of the WG on using DAOs to=20 support P2P.=20 =20 The building and home application spaces (and maybe others) have=20 a few clearly defined requirements.=20 It is not obvious to me how the current RPL proposal (cRPLp) can=20 satisfy those requirements:=20 =20 =20 In both cases it is the worst case scenario that hurts:=20 =20 =20 P2P routing inside the PAN=20 =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=20 cRPLp has no way of routing inside the PAN if you need more than=20 one repeater. cRPLp has to go all the way to the top (maybe 4 hops up)=20 and down again (maybe 4 hops down) to get just 2 hops to the side.=20 =20 The consequence is high latency and high levels of background noise for nodes just outside the direct radio range.=20 At the same time the risk of meeting a failing link is 4 times higher = =3D> latency may be much more than 4 times larger.=20 =20 Latency may sound like a minor issue but it actually translates directly into lower battery lifetime. In the above (very realistic) example,=20 the battery lifetime is reduced to 25% of what it should be.=20 =20 We have lots of battery devices sending into the network:=20 * PIR sensors turning on lights=20 * Door locks sending alarms=20 * Door/window sensors starting chimes=20 * Smoke sensors triggering an alarm system=20 =20 =20 =20 =20 Response time=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=20 The latency issue is important.=20 When a user (real human being) presses a light button the user expects=20 the light to turn on.=20 cRPLp proposes that nodes in the tree periodically advertises their=20 presence using DAOs.=20 The periodicity is a real beast:=20 Thanks to Trickle, the rate of updates in a (apparently) stable network is low. This is good since it leaves bandwidth for data.=20 But it is not good if existing routes to my lamp fail and I do not get=20 new routes to my lamp until it decides to send out a new DAO.=20 My user will (with a good reason) not tolerate waiting for minutes for=20 the light to turn on.=20 =20 I have met two arguments to counter this concern:=20 =20 A1: Well, your lamp can always send a DAO when it detects a problem.=20 My answer:=20 True, except that my lamp does not intend to send anything=20 so it will never experience any problems from its side of the network. =20 A2: Well, you can increase the DAO rate to sub-second updates.=20 My answer:=20 Oh no. I get a very high degree of management traffic which=20 limits my available bandwidth, increases the risk of collisions and=20 even run the risk of violating EU legislation requiring me to only=20 transmit in less than 1% of the time:=20 http://focus.ti.com/lit/an/swra048/swra048.pdf =20 868 - 868.6 MHz: <1%=20 =20 Reactiveness is hard to achieve via polling.=20 =20 =20 =20 If you agree that this seems to be critical issues please raise your=20 voice on the list.=20 =20 Going forward=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=20 =20 We need some reactive mechanism to reach lamps before the user decides=20 to sue our companies.=20 So is this possible? I think so.=20 Existing commercial (non-IP) solutions are capable of re-routing quickly if they really have to.=20 =20 Let me try scoping the requirements to a potential solution:=20 (no different from the req. docs for home and building)=20 =20 * P2P routing in any direction independent of the tree.=20 =20 * On-demand P2P route discovery if requested by a real-time critical app. Data collection apps may be able to just wait for the next DAO update.=20 =20 * Limited range of discovery mechanism: max 4 repeaters.=20 A TTL field may limit the scope of the repeaters.=20 =20 * Suboptimal routing and traffic bursts are accepted in exchange=20 for quick route repair. But only as an exception.=20 =20 =20 Just as an example, one existing home control technology uses a (source routing) variant of AODV for quick route repair.=20 Nothing comes for free. The price is flooding - but not just flooding: Managed flooding using a distributed algorithm running in all participating nodes.=20 The algorithm dampens the flooding in a time, volume and range perspective.=20 Some similar mechanism could be built into RPL for quick route repair.=20 =20 =20 If anyone have alternative proposals, please bring it to the list.=20 Now is the time.=20 =20 =20 =20 Thanks,=20 Anders=20 ________________________________ _______________________________________________ Roll mailing list Roll@ietf.org =20 https://www.ietf.org/mailman/listinfo/roll =20 _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll =20 =20 ________________________________ =20 _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll =20 ------_=_NextPart_001_01CAC70B.210F5DCA Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Robert :

 

At least from a distance, the proposed mechanism emulates AODV, with = the DIO as RREQ and the DAO as RREP. So if we decide to dig along those = lines, we’ll certainly appreciate help from MANET experts. = I’d say that if you already have RPL for P2MP and MP2P, the = proposed extension are probably simpler to add than doing AODV from = scratch.

 

For the setup, the major differences are that we build a DAG and that = we can indicate multiple targets. If you look at it, the DAG capability = is a MUST for RPL, and I have not seen that this MUST goes away for P2P = flows. The multiple targets is something that appears in a number of use = cases and it seems more economical to build a single DAG for multiple = targets when possible.

 

For the maintenance, the major differences are that we have the DAG = as first line of defense, and the RPL detection to stimulate the local = repair.

 

About your questions:

 

The DODAG root is the one that spawns the DAG. The targets can reach = the root because the root advertises itself in the DIO. The idea is that = the root ID is the address that the targets need to talk to. If needed, = the root can also advertise a prefix that it can reach and that the = targets need to reach too.

 

All the intermediate nodes that are confirmed by the DAO need to = retain at least info about the DAG. That enables the targets to reach = the root. The flooding should cost about the same as that of AODV but = the RPL way will require more states in the nodes on the way if the OF = requires a DAG.

 

The way back (down) can be stateful of stateless, depending on which = DAO we’re using. With fully stateful DAO, we are really in = AODV-land. With stateless, we could drift into DSR-land for that = direction. Which limits we place to keep it simple will be determined by = the resolution of issue #26 I guess…

 

And please, no apologize or on one will dare post anything anymore. = Your questions are fully relevant and at the core of the = discussion.

 

I hope we can talk in Anaheim for sure,

Pascal

 

From: Robert Cragie [mailto:robert.cragie@gridmerge.com] =
Sent: Monday, March 15, 2010 11:27 AM
To: Pascal = Thubert (pthubert)
Cc: Ted.Humpal@jci.com; ROLL WG
Subject: = Re: [Roll] P2P performance with current RPL = proposal

 

Hi Pascal,

So in your = slideware T can end up talking to R (DODAG root) through the DODAG. So = are you proposing that all potential targets can act as a DODAG root? = And therefore all intermediates have to retain DIO propagation support = for that DODAG as well? This may work for limited P2P but seems less = efficient than simple distance vector flooding RREQ/RREP like AODV or = DYMO for generic P2P. What about R to T (or anyone else for that = matter)? Do we source route, maintain state, some undefined hybrid of = the two?

I apologise if some of these questions have been = answered in detail in earlier reflector posts but I have only recently = started to concentrate my efforts on RPL and have 82 pages to wade = through :-). I look forward to a productive session in = Anaheim.

Robert

Robert = Cragie (Pacific Gas & Electric)

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



Pascal Thubert (pthubert) wrote: =

HI Robert :

 

I respectfully have to disagree.

 

My understanding is that we are considering a limited set of P2P = pairs, for which the specific path that we need to create might have to = obey specific constraints.

So it makes sense to use an on-demand technique, probably inspired by = the MANET Reactive protocols.

 

As it goes, those protocols usually use flooding for a node to locate = another. Forking a DAG is just another flooding. It does not take a lot = of addition to the existing DIO for a root to use RPL to build a DAG = that contains one or multiple Targets as leaves, under a set of = constraints expressed as an objective function. Please find attached a = slideware that illustrates that.

 

Pascal

 

From: roll-bounces@ietf.org = [mailto:roll-bounces@ietf.org] = On Behalf Of Robert Cragie
Sent: Thursday, March 11, = 2010 2:43 PM
To: Ted.Humpal@jci.com
Cc: = ROLL WG
Subject: Re: [Roll] P2P performance with current RPL = proposal

 

I agree with Ted's comments = below. Creating a DODAG for every reachable node as a root seems a very = inefficient approach compared to alternative routing algorithms. I am = concerned that RPL does not actually meet the original requirements in = I-D.ietf-roll-building-routing-reqs, I-D.ietf-roll-home-routing-reqs, = RFC5673 and RFC5548. The traffic pattern requirement for a sink node = features prominently in only two of those documents. Even in this case, = as Ted points out, communication is likely to be bidirectional (e.g. = end-to-end acks.) therefore the DODAG approach is fundamentally = asymmetric, especially if no intermediate storage is allowed for = destination routes and source routing has to be used.

Also, RPL = seems highly complex for what are constrained nodes in terms of memory = as well as power and bandwidth. The RPL draft as it stands is 82 pages = long and that doesn't include text about the objective = function.

Robert

Robert = Cragie (Pacific Gas & Electric)

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



Ted.Humpal@jci.com wrote: =


A concern = also will be how much overhead (memory space) will be required for a = DODAG Root?

and based on = the first question how many DODAG roots a lamp may need to be a member = of?

For example = in lighting  a single lamp may be a root for a single switch (1 = DODAG root),  this lamp / luminaire may also
be a member = of another group - -  which could be all lights on the floor (2nd = DODAG root), and a third group
of all the = lights in the building.  There can be many more speciality groups = associated based on the building configuration.
Consider = also during the installation time - how these DODAG roots will be = configured?  Must I commission each device
to tell it = which DODAG it must use for its Object Function?  How easy will = this be to change and add in a new DODAG root
for the end = user if the lighting group changes??

With respect = to Jerry Martocci's - commercial building requirements - every device = may need to communicate to any or
all of the = end devices.  If each device must establish a DODAG for the other = 499 devices in a 500 node network - How much memory
space will = this require for each end device to maintain?   =

Keep in mind = that the end devices are very limited processor and memory wise. =

Not to = mention all of the network maintenance messages that would need to be = transmitted to maintain all of these DODAGs.

Consider the = reconvergence time when one device is turned off and it was in the = middle of the majority of the 100+ DODAGS?

In many = lighting and building application an application acknowledgement - must = be returned {Back down the DODAG} so . . . the
requirement = is not just getting to the Root - a return path must also be maintained = and have a  low latency path.

Ted = Humpal




= From:

Kris Pister = <pister@eecs.berkeley.edu>=

= To:

Anders Brandt = <abr@sdesigns.dk> =

= Cc:

ROLL WG <roll@ietf.org> =

= Date:

03/08/2010 = 01:45 PM

= Subject:

Re: [Roll] = P2P performance with current RPL = proposal

 




Anders - if = we take JP's suggestion to make The Lamp a DODAG root, and take Phoebus' = recommendation that we use path diversity to improve end-to-end = reliability, do you see a chance of success?
In my experience, with = diverse paths and order-minutes updates you get extremely high = reliability.

I have no aversion to TTL-limited floods as a part = of a solution either.  I'm open to ideas on how to bring those in = as (presumably infrequently used) options.

ksjp

Anders = Brandt wrote:
Hello
  =
I would like to = probe the temperature of the WG on using DAOs to
support P2P. =
 
The = building and home application spaces (and maybe others) have =
a few clearly = defined requirements.
It is not obvious to me = how the current RPL proposal (cRPLp) can
satisfy those = requirements:
 
 
In both cases it is the = worst case scenario that hurts:
 
 
P2P routing inside the = PAN
=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
cRPLp has no way of = routing inside the PAN if you need more than
one repeater. cRPLp has to = go all the way to the top (maybe 4 hops up)
and down again (maybe 4 = hops down) to get just 2 hops to the side.
 
The consequence is high = latency and high levels of background noise
for nodes just outside = the direct radio range.
At the same time the risk = of meeting a failing link is 4 times higher =3D>
latency may be much more = than 4 times larger.
 
Latency may sound like a = minor issue but it actually translates directly
into lower battery = lifetime. In the above (very realistic) example,
the battery lifetime is = reduced to 25% of what it should be.
 
We have lots of battery = devices sending into the network:
* PIR sensors turning on = lights
* = Door locks sending alarms
* Door/window sensors = starting chimes
* Smoke sensors triggering = an alarm system
 
 
  =
 
Response time =
=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D
The latency issue is = important.
When a user (real human = being) presses a light button the user expects
the light to turn = on.
cRPLp = proposes that nodes in the tree periodically advertises their =
presence using = DAOs.
The = periodicity is a real beast:
Thanks to Trickle, the = rate of updates in a (apparently) stable network
is low. This is good = since it leaves bandwidth for data.
But it is not good if = existing routes to my lamp fail and I do not get
new routes to my lamp = until it decides to send out a new DAO.
My user will (with a good = reason) not tolerate waiting for minutes for
the light to turn = on.
 
I have met two arguments = to counter this concern:
 
A1: Well, your lamp can = always send a DAO when it detects a problem.
  My answer: =
  True, = except that my lamp does not intend to send anything
  so it will never = experience any problems from its side of the network.
  =
A2: Well, you = can increase the DAO rate to sub-second updates.
  My answer: =
  = Oh no. I get a very high = degree of management traffic which
  limits my available = bandwidth, increases the risk of collisions and
  even run the risk = of violating EU legislation requiring me to only
  transmit in less = than 1% of the time:
  http://focus.ti.com/lit/an/= swra048/swra048.pdf
 868 - 868.6 MHz: = <1%
 
  Reactiveness is = hard to achieve via polling.
 
 
  =
If you agree = that this seems to be critical issues please raise your
voice on the list. =
 
Going = forward
=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D
 
We need some reactive = mechanism to reach lamps before the user decides
to sue our = companies.
So is this possible? I = think so.

Existing commercial = (non-IP) solutions are capable of re-routing quickly
if they really have = to.
 
Let me try scoping the = requirements to a potential solution:
(no different from the = req. docs for home and building)
 
* P2P routing in any = direction independent of the tree.
 
* On-demand P2P route = discovery if requested by a real-time critical app.
 Data = collection apps may be able to just wait for the next DAO update. =
 
* Limited range of = discovery mechanism: max 4 repeaters.
  A TTL field may = limit the scope of the repeaters.
 
* Suboptimal routing and = traffic bursts are accepted in exchange
  for quick route = repair. But only as an exception.
 
 
Just as an example, one = existing home control technology uses a
(source routing) variant of = AODV for quick route repair.
Nothing comes for free. = The price is flooding - but not just flooding:
Managed flooding using = a distributed algorithm running in all
participating nodes. =
The algorithm = dampens the flooding in a time, volume and range perspective. =
Some = similar mechanism could be built into RPL for quick route repair. =
 
 
If anyone have alternative = proposals, please bring it to the list.
Now is the time. =
 
 
 
Thanks,
  Anders =


______________________________________________= _
Roll mailing = 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_01CAC70B.210F5DCA-- From pthubert@cisco.com Thu Mar 18 19:23: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 8A5EE3A6CC6; Thu, 18 Mar 2010 19:23:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.352 X-Spam-Level: X-Spam-Status: No, score=-8.352 tagged_above=-999 required=5 tests=[AWL=1.116, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, 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 ptsDUSv2vBQH; Thu, 18 Mar 2010 19:23: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 119F33A6CE8; Thu, 18 Mar 2010 19:23:08 -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: AgEFAKZ8okurR7H+/2dsb2JhbACBRJlrc6JvmQOEeQQ X-IronPort-AV: E=Sophos;i="4.51,272,1267401600"; d="scan'208,217";a="168761570" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-5.cisco.com with ESMTP; 19 Mar 2010 02:23:19 +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 o2J2NI6e018274; Fri, 19 Mar 2010 02:23: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); Fri, 19 Mar 2010 03:23:17 +0100 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_01CAC70B.22919CA4" Date: Fri, 19 Mar 2010 03:23:10 +0100 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D01792E49@XMB-AMS-107.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] P2P performance with current RPL proposal Thread-Index: AcrEgqQThVZ7nDJXT+qtgDR4ozgeJQChhFUg References: <6D9687E95918C04A8B30A7D6DA805A3E01429F5F@zensys17.zensys.local> <4B9553B8.6010001@eecs.berkeley.edu><4B98F374.4030301@gridmerge.com> <6A2A459175DABE4BB11DE2026AA50A5D0170DFA9@XMB-AMS-107.cisco.com> From: "Pascal Thubert (pthubert)" To: X-OriginalArrivalTime: 19 Mar 2010 02:23:17.0836 (UTC) FILETIME=[22F268C0:01CAC70B] Cc: ROLL WG , roll-bounces@ietf.org Subject: Re: [Roll] P2P performance with current RPL proposal X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Mar 2010 02:23:55 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CAC70B.22919CA4 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Ted : =20 As you point out, the proposal requires a new option for P2P to indicate the targets. It also requires to limit the distance at which we spawn the DIO, things like that, details to be worked out. And yes, the nodes on the way would keep a state when confirmed by DAO, and others would time out and forget. The decision to join would include the capability to run the OF, capacity, and probably some consistency logic like no need to join if many neighbors already did. =20 =20 Pascal =20 From: Ted.Humpal@jci.com [mailto:Ted.Humpal@jci.com]=20 Sent: Monday, March 15, 2010 2:01 PM To: Pascal Thubert (pthubert) Cc: robert.cragie@gridmerge.com; ROLL WG; roll-bounces@ietf.org Subject: Re: [Roll] P2P performance with current RPL proposal =20 Pascal=20 Going over your P2P proposal - I have a fundamental question that I would like to clarify -=20 On page 3 you show how a 'new P2P' DAG could be formed, with the initial transmission of a DIO message.=20 Included in the DIO message is the base option parameters and maybe DIO suboption(s)=20 Of the defined suboptions in the version 8 of the standard - I do not see a way to include in the DIO which node=20 I wish to send a message to (destination) - - - so as the DIO is transmitted along the network - - - How does a node know which DAG it should join ?=20 Should a node join any DAG for some initial period - since it may be in the path, to the ultimate destination?=20 [Pascal]=20 You are correct, the proposal requires a new option for P2P to indicate the targets. It also requires to limit the distance at which we spawn the DIO, things like that, details to be worked out. And yes, the nodes on the way would keep a state when confirmed by DAO, and others would time out and forget.=20 For instance in your example R wishes to send a message to T but T is not aware, that it will be receiving a message. When=20 the DIO comes along Should I join this new DAG or not? How do I decide? When a DIO is received by this nod (T) or any node (along the path A,D,E,F,G) - How do they determine if they should join this new DAG?=20 Eventually D and E join this new DAG, and A drops opts of the DAG. =20 [Pascal] The decision to join would include the capability to run the OF, capacity, and probably some consistency logic like no need to join if many neighbors already did. TBD. =20 How does a node know how to associate a DAG to a destination address - Is there an OCP / OF for each destination address?=20 Does is matter if all of the nodes have the same prefix on the LLN network? If they all have the same prefix, which has been discussed,=20 then the prefix suboption for the DIO is less valuable.=20 [Pascal] The prefix in the DIO is really something that you can reach via the root, not the prefix option in the RA. The spec allows nodes on the way to add their own, but that might lead to unwanted complexities, like should the OCP select parents that have this additional prefix, or else, will the route table flap? How many DAGs can a LLN support? For P2P the number of DAGs could be the number of nodes minus 1, and every node may be a member=20 of every DAG??=20 [Pascal] In that extreme case, we end up with something close to the traditional DV, like RIP, when you use the DV to maintain multiple feasible successors. In the use cases that I know of, the DAGs do not span far. So at least, we enable the optimization of controlling how far we flood, when RIP would floor the entire network about every node in the network. =20 Typically every node does not need to communicate with every other node, but the design should not limit the number of P2P paths that=20 may be required.=20 [Pascal] Sure. RPL enables to align the cost to what's really useful. But when what's useful is a lot, the cost grows accordingly, no magic. =20 Cheers, Thanks=20 Ted=20 From:=20 "Pascal Thubert (pthubert)" =20 To:=20 , =20 Cc:=20 ROLL WG =20 Date:=20 03/15/2010 11:29 AM=20 Subject:=20 Re: [Roll] P2P performance with current RPL proposal =20 ________________________________ HI Robert :=20 =20 I respectfully have to disagree.=20 =20 My understanding is that we are considering a limited set of P2P pairs, for which the specific path that we need to create might have to obey specific constraints.=20 So it makes sense to use an on-demand technique, probably inspired by the MANET Reactive protocols.=20 =20 As it goes, those protocols usually use flooding for a node to locate another. Forking a DAG is just another flooding. It does not take a lot of addition to the existing DIO for a root to use RPL to build a DAG that contains one or multiple Targets as leaves, under a set of constraints expressed as an objective function. Please find attached a slideware that illustrates that.=20 =20 Pascal=20 =20 From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org ] On Behalf Of Robert Cragie Sent: Thursday, March 11, 2010 2:43 PM To: Ted.Humpal@jci.com Cc: ROLL WG Subject: Re: [Roll] P2P performance with current RPL proposal=20 =20 I agree with Ted's comments below. Creating a DODAG for every reachable node as a root seems a very inefficient approach compared to alternative routing algorithms. I am concerned that RPL does not actually meet the original requirements in I-D.ietf-roll-building-routing-reqs, I-D.ietf-roll-home-routing-reqs, RFC5673 and RFC5548. The traffic pattern requirement for a sink node features prominently in only two of those documents. Even in this case, as Ted points out, communication is likely to be bidirectional (e.g. end-to-end acks.) therefore the DODAG approach is fundamentally asymmetric, especially if no intermediate storage is allowed for destination routes and source routing has to be used. Also, RPL seems highly complex for what are constrained nodes in terms of memory as well as power and bandwidth. The RPL draft as it stands is 82 pages long and that doesn't include text about the objective function. 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 Ted.Humpal@jci.com wrote:=20 A concern also will be how much overhead (memory space) will be required for a DODAG Root?=20 and based on the first question how many DODAG roots a lamp may need to be a member of?=20 For example in lighting a single lamp may be a root for a single switch (1 DODAG root), this lamp / luminaire may also=20 be a member of another group - - which could be all lights on the floor (2nd DODAG root), and a third group=20 of all the lights in the building. There can be many more speciality groups associated based on the building configuration.=20 Consider also during the installation time - how these DODAG roots will be configured? Must I commission each device=20 to tell it which DODAG it must use for its Object Function? How easy will this be to change and add in a new DODAG root=20 for the end user if the lighting group changes??=20 With respect to Jerry Martocci's - commercial building requirements - every device may need to communicate to any or=20 all of the end devices. If each device must establish a DODAG for the other 499 devices in a 500 node network - How much memory=20 space will this require for each end device to maintain? =20 Keep in mind that the end devices are very limited processor and memory wise.=20 Not to mention all of the network maintenance messages that would need to be transmitted to maintain all of these DODAGs.=20 Consider the reconvergence time when one device is turned off and it was in the middle of the majority of the 100+ DODAGS?=20 In many lighting and building application an application acknowledgement - must be returned {Back down the DODAG} so . . . the=20 requirement is not just getting to the Root - a return path must also be maintained and have a low latency path.=20 Ted Humpal=20 From:=20 Kris Pister To:=20 Anders Brandt =20 Cc:=20 ROLL WG =20 Date:=20 03/08/2010 01:45 PM=20 Subject:=20 Re: [Roll] P2P performance with current RPL proposal =20 =20 ________________________________ Anders - if we take JP's suggestion to make The Lamp a DODAG root, and take Phoebus' recommendation that we use path diversity to improve end-to-end reliability, do you see a chance of success? In my experience, with diverse paths and order-minutes updates you get extremely high reliability. I have no aversion to TTL-limited floods as a part of a solution either. I'm open to ideas on how to bring those in as (presumably infrequently used) options. ksjp Anders Brandt wrote:=20 Hello=20 =20 I would like to probe the temperature of the WG on using DAOs to=20 support P2P.=20 =20 The building and home application spaces (and maybe others) have=20 a few clearly defined requirements.=20 It is not obvious to me how the current RPL proposal (cRPLp) can=20 satisfy those requirements:=20 =20 =20 In both cases it is the worst case scenario that hurts:=20 =20 =20 P2P routing inside the PAN=20 =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=20 cRPLp has no way of routing inside the PAN if you need more than=20 one repeater. cRPLp has to go all the way to the top (maybe 4 hops up)=20 and down again (maybe 4 hops down) to get just 2 hops to the side.=20 =20 The consequence is high latency and high levels of background noise for nodes just outside the direct radio range.=20 At the same time the risk of meeting a failing link is 4 times higher = =3D> latency may be much more than 4 times larger.=20 =20 Latency may sound like a minor issue but it actually translates directly into lower battery lifetime. In the above (very realistic) example,=20 the battery lifetime is reduced to 25% of what it should be.=20 =20 We have lots of battery devices sending into the network:=20 * PIR sensors turning on lights=20 * Door locks sending alarms=20 * Door/window sensors starting chimes=20 * Smoke sensors triggering an alarm system=20 =20 =20 =20 =20 Response time=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=20 The latency issue is important.=20 When a user (real human being) presses a light button the user expects=20 the light to turn on.=20 cRPLp proposes that nodes in the tree periodically advertises their=20 presence using DAOs.=20 The periodicity is a real beast:=20 Thanks to Trickle, the rate of updates in a (apparently) stable network is low. This is good since it leaves bandwidth for data.=20 But it is not good if existing routes to my lamp fail and I do not get=20 new routes to my lamp until it decides to send out a new DAO.=20 My user will (with a good reason) not tolerate waiting for minutes for=20 the light to turn on.=20 =20 I have met two arguments to counter this concern:=20 =20 A1: Well, your lamp can always send a DAO when it detects a problem.=20 My answer:=20 True, except that my lamp does not intend to send anything=20 so it will never experience any problems from its side of the network.=20 =20 A2: Well, you can increase the DAO rate to sub-second updates.=20 My answer:=20 Oh no. I get a very high degree of management traffic which=20 limits my available bandwidth, increases the risk of collisions and=20 even run the risk of violating EU legislation requiring me to only=20 transmit in less than 1% of the time:=20 http://focus.ti.com/lit/an/swra048/swra048.pdf =20 868 - 868.6 MHz: <1%=20 =20 Reactiveness is hard to achieve via polling.=20 =20 =20 =20 If you agree that this seems to be critical issues please raise your=20 voice on the list.=20 =20 Going forward=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=20 =20 We need some reactive mechanism to reach lamps before the user decides=20 to sue our companies.=20 So is this possible? I think so.=20 Existing commercial (non-IP) solutions are capable of re-routing quickly if they really have to.=20 =20 Let me try scoping the requirements to a potential solution:=20 (no different from the req. docs for home and building)=20 =20 * P2P routing in any direction independent of the tree.=20 =20 * On-demand P2P route discovery if requested by a real-time critical app. Data collection apps may be able to just wait for the next DAO update.=20 =20 * Limited range of discovery mechanism: max 4 repeaters.=20 A TTL field may limit the scope of the repeaters.=20 =20 * Suboptimal routing and traffic bursts are accepted in exchange=20 for quick route repair. But only as an exception.=20 =20 =20 Just as an example, one existing home control technology uses a (source routing) variant of AODV for quick route repair.=20 Nothing comes for free. The price is flooding - but not just flooding: Managed flooding using a distributed algorithm running in all participating nodes.=20 The algorithm dampens the flooding in a time, volume and range perspective.=20 Some similar mechanism could be built into RPL for quick route repair.=20 =20 =20 If anyone have alternative proposals, please bring it to the list.=20 Now is the time.=20 =20 =20 =20 Thanks,=20 Anders=20 =20 ________________________________ _______________________________________________ Roll mailing list Roll@ietf.org =20 https://www.ietf.org/mailman/listinfo/roll =20 _______________________________________________ Roll mailing list Roll@ietf.org =20 https://www.ietf.org/mailman/listinfo/roll =20 =20 =20 ________________________________ =20 _______________________________________________=20 Roll mailing list=20 Roll@ietf.org =20 https://www.ietf.org/mailman/listinfo/roll =20 [attachment "DAGPtP.pdf" deleted by Ted Humpal/CORP/Johnson_Controls] _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll =20 ------_=_NextPart_001_01CAC70B.22919CA4 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Ted :

 

As you point out, the proposal requires a new option for P2P to = indicate the targets. It also requires to limit the distance at which we = spawn the DIO, things like that, details to be worked out. And yes, the = nodes on the way would keep a state when confirmed by DAO, and others = would time out and forget. The decision to join would include the = capability to run the OF, capacity, and probably some consistency logic = like no need to join if many neighbors already = did.

 

 

Pascal

 

From:= = Ted.Humpal@jci.com [mailto:Ted.Humpal@jci.com]
Sent: Monday, = March 15, 2010 2:01 PM
To: Pascal Thubert = (pthubert)
Cc: robert.cragie@gridmerge.com; ROLL WG; = roll-bounces@ietf.org
Subject: Re: [Roll] P2P performance with = current RPL proposal

 


Pascal=

Going over = your P2P proposal - I have a  fundamental question that I would = like to clarify -

On =  page 3 you show how a 'new P2P' DAG could be formed, with the = initial transmission of a DIO message.
Included in = the DIO message is the base option parameters and maybe  DIO = suboption(s)
Of the = defined suboptions in the version 8 of the standard - I do not see a way = to include in the DIO which node
I wish to = send a message to (destination)  -  - -   so as the DIO = is transmitted along the network  - - -  How does a node know = which DAG  it should join ?
Should a = node join any DAG for some initial period - since it may be in the path, = to the ultimate destination?

[Pascal]

You are correct, the proposal requires a new option for P2P to = indicate the targets. It also requires to limit the distance at which we = spawn the DIO, things like that, details to be worked out. And yes, the = nodes on the way would keep a state when confirmed by DAO, and others = would time out and forget.


For instance = in your example R wishes to send a message to T but T is not aware, that = it will be receiving a message. When =
the DIO = comes along Should I join this new DAG or not?  How do I = decide?

When a DIO = is received by this nod (T) or any node (along the path A,D,E,F,G) - How = do they determine if they should join this new DAG?
Eventually =  D and E join this new DAG,  and A drops opts of the DAG. =  

[Pascal] The decision to join would include the capability to run the OF, = capacity, and probably some consistency logic like no need to join if = many neighbors already did. TBD.

 


How does a = node know how to associate a DAG to a destination address -  Is = there an OCP / OF for each destination address?

Does is = matter if all of the nodes have the same prefix on the LLN network? =  If they all have the same prefix, which has been discussed, =
then the = prefix suboption for the DIO is less valuable.

[Pascal] The prefix in the DIO is really something that you can reach via the = root, not the prefix option in the RA. The spec allows nodes on the way = to add their own, but that might lead to unwanted complexities, like = should the OCP select parents that have this additional prefix, or else, = will the route table flap?


How many = DAGs can a LLN support?  For P2P the = number of DAGs could be the number of nodes minus 1, and every node may = be a member
of every = DAG??

[Pascal] In that extreme case, we end up with something close to the = traditional DV, like RIP, when you use the DV to maintain multiple = feasible successors. In the use cases that I know of, the DAGs do not = span far. So at least, we enable the optimization of controlling how far = we flood, when RIP would floor the entire network about every node in = the network.

 


Typically = every node does not need to communicate with every other node, but the = design should not limit the number of P2P paths that
may be = required.

[Pascal] Sure. RPL enables to align the cost to what’s really useful. = But when what’s useful is a lot, the cost grows accordingly, no = magic.

 

Cheers,


Thanks=

Ted =






= From:

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

= To:

<robert.cra= gie@gridmerge.com>, <Ted.Humpal@jci.com> =

= Cc:

ROLL WG = <roll@ietf.org>

= Date:

03/15/2010 = 11:29 AM

= Subject:

Re: [Roll] = P2P performance with current RPL = proposal

 




HI Robert :
 
I respectfully have to disagree.
 
My understanding is that we are considering a limited set of P2P = pairs, for which the specific path that we need to create might have to = obey specific constraints.
So it makes sense to use an on-demand technique, probably inspired by = the MANET Reactive protocols.
 
As it goes, those protocols usually use flooding for a node to locate = another. Forking a DAG is just another flooding. It does not take a lot = of addition to the existing DIO for a root to use RPL to build a DAG = that contains one or multiple Targets as leaves, under a set of = constraints expressed as an objective function. Please find attached a = slideware that illustrates that.
 
Pascal
 
From:= = roll-bounces@ietf.org = [mailto:roll-= bounces@ietf.org] On = Behalf Of Robert Cragie
Sent: Thursday, March 11, 2010 = 2:43 PM
To: Ted.Humpal@jci.com
Cc: = ROLL WG
Subject: Re: [Roll] P2P performance with current RPL = proposal
 
I agree with Ted's comments = below. Creating a DODAG for every reachable node as a root seems a very = inefficient approach compared to alternative routing algorithms. I am = concerned that RPL does not actually meet the original requirements in = I-D.ietf-roll-building-routing-reqs, I-D.ietf-roll-home-routing-reqs, = RFC5673 and RFC5548. The traffic pattern requirement for a sink node = features prominently in only two of those documents. Even in this case, = as Ted points out, communication is likely to be bidirectional (e.g. = end-to-end acks.) therefore the DODAG approach is fundamentally = asymmetric, especially if no intermediate storage is allowed for = destination routes and source routing has to be used.

Also, RPL = seems highly complex for what are constrained nodes in terms of memory = as well as power and bandwidth. The RPL draft as it stands is 82 pages = long and that doesn't include text about the objective = function.

Robert

Robert Cragie (Pacific Gas = & Electric)

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


Ted.Humpal@jci.com wrote: =

A = concern also will be how much overhead (memory space) will be required = for a DODAG Root?

and = based on the first question how many DODAG roots a lamp may need to be a = member of?

For = example in lighting  a single lamp may be a root for a single = switch (1 DODAG root),  this lamp / luminaire may also
be a = member of another group - -  which could be all lights on the floor = (2nd DODAG root), and a third group
of all = the lights in the building.  There can be many more speciality = groups associated based on the building configuration.
Consider = also during the installation time - how these DODAG roots will be = configured?  Must I commission each device
to tell = it which DODAG it must use for its Object Function?  How easy will = this be to change and add in a new DODAG root
for the = end user if the lighting group changes??

With = respect to Jerry Martocci's - commercial building requirements - every = device may need to communicate to any or
all of = the end devices.  If each device must establish a DODAG for the = other 499 devices in a 500 node network - How much memory
space = will this require for each end device to maintain?   =

Keep in = mind that the end devices are very limited processor and memory = wise.

Not to = mention all of the network maintenance messages that would need to be = transmitted to maintain all of these DODAGs.

Consider = the reconvergence time when one device is turned off and it was in the = middle of the majority of the 100+ DODAGS?

In many = lighting and building application an application acknowledgement - must = be returned {Back down the DODAG} so . . . the
requirement is not = just getting to the Root - a return path must also be maintained and = have a  low latency path.

Ted = Humpal

= From:

Kris Pister = <pister@eec= s.berkeley.edu>

= To:

Anders Brandt = <abr@sdesig= ns.dk>

= Cc:

ROLL WG = <roll@ietf.= org>

= Date:

03/08/2010 = 01:45 PM

= Subject:

Re: [Roll] = P2P performance with current RPL = proposal


  =

 





Anders - if we take JP's suggestion to = make The Lamp a DODAG root, and take Phoebus' recommendation that we use = path diversity to improve end-to-end reliability, do you see a chance of = success?
In my experience, with diverse paths and order-minutes = updates you get extremely high reliability.

I have no aversion to = TTL-limited floods as a part of a solution either.  I'm open to = ideas on how to bring those in as (presumably infrequently used) = options.

ksjp

Anders Brandt wrote:
Hello =
 
I = would like to probe the temperature of the WG on using DAOs to =
support = P2P.
 
The building and home = application spaces (and maybe others) have
a few clearly defined = requirements.
It is not obvious to = me how the current RPL proposal (cRPLp) can
satisfy those = requirements:
 
 
In both cases it is = the worst case scenario that hurts:
 
 
P2P routing inside the = PAN
=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
cRPLp has no way of = routing inside the PAN if you need more than
one repeater. cRPLp = has to go all the way to the top (maybe 4 hops up)
and down again (maybe = 4 hops down) to get just 2 hops to the side.
 
The consequence is = high latency and high levels of background noise
for nodes just = outside the direct radio range.
At the same time the = risk of meeting a failing link is 4 times higher =3D>
latency may be much = more than 4 times larger.
 
Latency may sound like = a minor issue but it actually translates directly
into lower battery = lifetime. In the above (very realistic) example,
the battery lifetime = is reduced to 25% of what it should be.
 
We have lots of = battery devices sending into the network:
* PIR sensors turning = on lights
* Door locks sending = alarms
* = Door/window sensors starting chimes
* Smoke sensors = triggering an alarm system
 
 
 =
 
Response time =
=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D
The latency issue is = important.
When a user (real = human being) presses a light button the user expects
the light to turn = on.
cRPLp = proposes that nodes in the tree periodically advertises their =
presence using = DAOs.
The = periodicity is a real beast:
Thanks to Trickle, the = rate of updates in a (apparently) stable network
is low. This is good = since it leaves bandwidth for data.
But it is not good if = existing routes to my lamp fail and I do not get
new routes to my lamp = until it decides to send out a new DAO.
My user will (with a = good reason) not tolerate waiting for minutes for
the light to turn = on.
 
I have met two = arguments to counter this concern:
 
A1: Well, your lamp = can always send a DAO when it detects a problem.
 My = answer:
 True, except = that my lamp does not intend to send anything
 so it will never = experience any problems from its side of the network. =
 
A2: = Well, you can increase the DAO rate to sub-second updates.
 My = answer:
 Oh no. I get a very high degree of = management traffic which
 limits my = available bandwidth, increases the risk of collisions and
 even run the = risk of violating EU legislation requiring me to only
 transmit in less = than 1% of the time:
 http://focus.ti.com/lit/an/= swra048/swra048.pdf
868 - 868.6 MHz: = <1%
 
 Reactiveness is = hard to achieve via polling.
 
 
 
If you agree that this = seems to be critical issues please raise your
voice on the = list.
 
Going forward =
=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D
 
We need some reactive = mechanism to reach lamps before the user decides
to sue our = companies.
So is this possible? I = think so.

Existing = commercial (non-IP) solutions are capable of re-routing quickly =
if they really = have to.
 
Let me try scoping the = requirements to a potential solution:
(no different from the = req. docs for home and building)
 
* P2P routing in any = direction independent of the tree.
 
* On-demand P2P route = discovery if requested by a real-time critical app.
Data collection = apps may be able to just wait for the next DAO update.
 
* Limited range of = discovery mechanism: max 4 repeaters.
 A TTL field may = limit the scope of the repeaters.
 
* Suboptimal routing = and traffic bursts are accepted in exchange
 for quick route = repair. But only as an exception.
 
 
Just as an example, = one existing home control technology uses a
(source routing) variant = of AODV for quick route repair.
Nothing comes for = free. The price is flooding - but not just flooding:
Managed flooding = using a distributed algorithm running in all
participating = nodes.
The algorithm dampens = the flooding in a time, volume and range perspective.
Some similar = mechanism could be built into RPL for quick route repair.
 
 
If anyone have = alternative proposals, please bring it to the list.
Now is the = time.
 
 
 
Thanks,
 Anders =

 



_______________________________________________
Roll = mailing 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
  [attachment = "DAGPtP.pdf" deleted by Ted Humpal/CORP/Johnson_Controls] = _______________________________________________
Roll = mailing list
Roll@ietf.org
https://www.ietf.org/mailman/listinfo/roll

------_=_NextPart_001_01CAC70B.22919CA4-- From d.sturek@att.net Thu Mar 18 19:41: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 B6E733A6A7A for ; Thu, 18 Mar 2010 19:41:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.583 X-Spam-Level: X-Spam-Status: No, score=-0.583 tagged_above=-999 required=5 tests=[AWL=-0.565, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, 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 F37OxxbIaG07 for ; Thu, 18 Mar 2010 19:41:26 -0700 (PDT) Received: from smtp101.sbc.mail.mud.yahoo.com (smtp101.sbc.mail.mud.yahoo.com [68.142.198.200]) by core3.amsl.com (Postfix) with SMTP id 6C09E3A6975 for ; Thu, 18 Mar 2010 19:41:25 -0700 (PDT) Received: (qmail 4564 invoked from network); 19 Mar 2010 02:41:35 -0000 Received: from Studio (d.sturek@69.225.127.54 with login) by smtp101.sbc.mail.mud.yahoo.com with SMTP; 18 Mar 2010 19:41:34 -0700 PDT X-Yahoo-SMTP: fvjol_aswBAraSJvMLe2r1XTzhBhbFxY8q8c3jo- X-YMail-OSG: Rcx1YCMVM1mA3RUC6SP3TenYHUAQNmYnF8gKz_bpqZeGXiFkpxelaFlhghgWZIkiSvXy1wv67xL0i3YAs1h4oYO0rBodHzBXrf8jYVj_9if.3_UXiZQS5oSuwG0FXgnp_od1zEOco.0QVIFnz62HZ9fJuT_1T_ToRW4IE_Kq40U4RsCJl9x3R6Xu3HJff2URaw_rGGyyJOBzZZ82hKSXLjMQo9XsW7_AuBm11cusde4_xDjbviUr96R29KymGbXg4lb82yvrXNwrr6RVIXapznAHZLJPwbc4VtCKv0A8MCFT38Ih79kePQI- X-Yahoo-Newman-Property: ymail-3 From: "Don Sturek" To: "'Pascal Thubert \(pthubert\)'" , References: <6D9687E95918C04A8B30A7D6DA805A3E01429F5F@zensys17.zensys.local> <4B9553B8.6010001@eecs.berkeley.edu> <4B98F374.4030301@gridmerge.com> <6A2A459175DABE4BB11DE2026AA50A5D0170DFA9@XMB-AMS-107.cisco.com> <4B9E7BE8.9060109@gridmerge.com> <6A2A459175DABE4BB11DE2026AA50A5D01792E48@XMB-AMS-107.cisco.com> In-Reply-To: <6A2A459175DABE4BB11DE2026AA50A5D01792E48@XMB-AMS-107.cisco.com> Date: Thu, 18 Mar 2010 19:41:25 -0700 Message-ID: <02c901cac70d$ac1c7990$04556cb0$@sturek@att.net> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_02CA_01CAC6D2.FFBDA190" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcrEbU1tfn0308v7QGeWK3YmnqapOAClmO0QAAIVugA= Content-Language: en-us Cc: 'ROLL WG' , Ted.Humpal@jci.com Subject: Re: [Roll] P2P performance with current RPL proposal 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, 19 Mar 2010 02:41:44 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_02CA_01CAC6D2.FFBDA190 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Pascal, I have to say I am skeptical of a solution where destination devices advertise themselves as DAG roots and sources join those DAGs. It is not clear to me at network formation how this is known and the number of destination devices and potential source devices would indicate that too much routing information would need to be retained to make such a solution make sense economically. >From my experience with Smart Energy, we seem resigned to creating relatively few DAGs (maybe only one) then using source routing to reach devices lower in the DAG. I would doubt we would invest the time in forming multiple DAGs or trying to optimize with multiple destination devices as DAG roots and devices lower in the DAG joining multiple DAG depending on the destination address of their packets. Keep in mind we don't have the requirement right now for low latency P2P communication in Smart Energy which I would maintain IS NOT supported in the current RPL proposal. I encourage you to look at some of the alternative I-Ds to create a workable solution for P2P communication. If you believe that low latency P2P communication is currently supported, I would encourage you to take some of the requirements from the Building Controls or Home Automation requirements and show how this works with RPL today (particularly showing the memory storage requirements on the individual devices in the DAG). I think you will quickly conclude there is a problem with respect to P2P routing. Don From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Pascal Thubert (pthubert) Sent: Thursday, March 18, 2010 7:23 PM To: robert.cragie@gridmerge.com Cc: ROLL WG; Ted.Humpal@jci.com Subject: Re: [Roll] P2P performance with current RPL proposal Hi Robert : At least from a distance, the proposed mechanism emulates AODV, with the DIO as RREQ and the DAO as RREP. So if we decide to dig along those lines, we'll certainly appreciate help from MANET experts. I'd say that if you already have RPL for P2MP and MP2P, the proposed extension are probably simpler to add than doing AODV from scratch. For the setup, the major differences are that we build a DAG and that we can indicate multiple targets. If you look at it, the DAG capability is a MUST for RPL, and I have not seen that this MUST goes away for P2P flows. The multiple targets is something that appears in a number of use cases and it seems more economical to build a single DAG for multiple targets when possible. For the maintenance, the major differences are that we have the DAG as first line of defense, and the RPL detection to stimulate the local repair. About your questions: The DODAG root is the one that spawns the DAG. The targets can reach the root because the root advertises itself in the DIO. The idea is that the root ID is the address that the targets need to talk to. If needed, the root can also advertise a prefix that it can reach and that the targets need to reach too. All the intermediate nodes that are confirmed by the DAO need to retain at least info about the DAG. That enables the targets to reach the root. The flooding should cost about the same as that of AODV but the RPL way will require more states in the nodes on the way if the OF requires a DAG. The way back (down) can be stateful of stateless, depending on which DAO we're using. With fully stateful DAO, we are really in AODV-land. With stateless, we could drift into DSR-land for that direction. Which limits we place to keep it simple will be determined by the resolution of issue #26 I guess. And please, no apologize or on one will dare post anything anymore. Your questions are fully relevant and at the core of the discussion. I hope we can talk in Anaheim for sure, Pascal From: Robert Cragie [mailto:robert.cragie@gridmerge.com] Sent: Monday, March 15, 2010 11:27 AM To: Pascal Thubert (pthubert) Cc: Ted.Humpal@jci.com; ROLL WG Subject: Re: [Roll] P2P performance with current RPL proposal Hi Pascal, So in your slideware T can end up talking to R (DODAG root) through the DODAG. So are you proposing that all potential targets can act as a DODAG root? And therefore all intermediates have to retain DIO propagation support for that DODAG as well? This may work for limited P2P but seems less efficient than simple distance vector flooding RREQ/RREP like AODV or DYMO for generic P2P. What about R to T (or anyone else for that matter)? Do we source route, maintain state, some undefined hybrid of the two? I apologise if some of these questions have been answered in detail in earlier reflector posts but I have only recently started to concentrate my efforts on RPL and have 82 pages to wade through :-). I look forward to a productive session in Anaheim. Robert Robert Cragie (Pacific Gas & Electric) Gridmerge Ltd. 89 Greenfield Crescent, Wakefield, WF4 4WA, UK +44 (0) 1924 910888 http://www.gridmerge.com Pascal Thubert (pthubert) wrote: HI Robert : I respectfully have to disagree. My understanding is that we are considering a limited set of P2P pairs, for which the specific path that we need to create might have to obey specific constraints. So it makes sense to use an on-demand technique, probably inspired by the MANET Reactive protocols. As it goes, those protocols usually use flooding for a node to locate another. Forking a DAG is just another flooding. It does not take a lot of addition to the existing DIO for a root to use RPL to build a DAG that contains one or multiple Targets as leaves, under a set of constraints expressed as an objective function. Please find attached a slideware that illustrates that. Pascal From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Robert Cragie Sent: Thursday, March 11, 2010 2:43 PM To: Ted.Humpal@jci.com Cc: ROLL WG Subject: Re: [Roll] P2P performance with current RPL proposal I agree with Ted's comments below. Creating a DODAG for every reachable node as a root seems a very inefficient approach compared to alternative routing algorithms. I am concerned that RPL does not actually meet the original requirements in I-D.ietf-roll-building-routing-reqs, I-D.ietf-roll-home-routing-reqs, RFC5673 and RFC5548. The traffic pattern requirement for a sink node features prominently in only two of those documents. Even in this case, as Ted points out, communication is likely to be bidirectional (e.g. end-to-end acks.) therefore the DODAG approach is fundamentally asymmetric, especially if no intermediate storage is allowed for destination routes and source routing has to be used. Also, RPL seems highly complex for what are constrained nodes in terms of memory as well as power and bandwidth. The RPL draft as it stands is 82 pages long and that doesn't include text about the objective function. Robert Robert Cragie (Pacific Gas & Electric) Gridmerge Ltd. 89 Greenfield Crescent, Wakefield, WF4 4WA, UK +44 (0) 1924 910888 http://www.gridmerge.com Ted.Humpal@jci.com wrote: A concern also will be how much overhead (memory space) will be required for a DODAG Root? and based on the first question how many DODAG roots a lamp may need to be a member of? For example in lighting a single lamp may be a root for a single switch (1 DODAG root), this lamp / luminaire may also be a member of another group - - which could be all lights on the floor (2nd DODAG root), and a third group of all the lights in the building. There can be many more speciality groups associated based on the building configuration. Consider also during the installation time - how these DODAG roots will be configured? Must I commission each device to tell it which DODAG it must use for its Object Function? How easy will this be to change and add in a new DODAG root for the end user if the lighting group changes?? With respect to Jerry Martocci's - commercial building requirements - every device may need to communicate to any or all of the end devices. If each device must establish a DODAG for the other 499 devices in a 500 node network - How much memory space will this require for each end device to maintain? Keep in mind that the end devices are very limited processor and memory wise. Not to mention all of the network maintenance messages that would need to be transmitted to maintain all of these DODAGs. Consider the reconvergence time when one device is turned off and it was in the middle of the majority of the 100+ DODAGS? In many lighting and building application an application acknowledgement - must be returned {Back down the DODAG} so . . . the requirement is not just getting to the Root - a return path must also be maintained and have a low latency path. Ted Humpal From: Kris Pister To: Anders Brandt Cc: ROLL WG Date: 03/08/2010 01:45 PM Subject: Re: [Roll] P2P performance with current RPL proposal _____ Anders - if we take JP's suggestion to make The Lamp a DODAG root, and take Phoebus' recommendation that we use path diversity to improve end-to-end reliability, do you see a chance of success? In my experience, with diverse paths and order-minutes updates you get extremely high reliability. I have no aversion to TTL-limited floods as a part of a solution either. I'm open to ideas on how to bring those in as (presumably infrequently used) options. ksjp Anders Brandt wrote: Hello I would like to probe the temperature of the WG on using DAOs to support P2P. The building and home application spaces (and maybe others) have a few clearly defined requirements. It is not obvious to me how the current RPL proposal (cRPLp) can satisfy those requirements: In both cases it is the worst case scenario that hurts: P2P routing inside the PAN ========================== cRPLp has no way of routing inside the PAN if you need more than one repeater. cRPLp has to go all the way to the top (maybe 4 hops up) and down again (maybe 4 hops down) to get just 2 hops to the side. The consequence is high latency and high levels of background noise for nodes just outside the direct radio range. At the same time the risk of meeting a failing link is 4 times higher => latency may be much more than 4 times larger. Latency may sound like a minor issue but it actually translates directly into lower battery lifetime. In the above (very realistic) example, the battery lifetime is reduced to 25% of what it should be. We have lots of battery devices sending into the network: * PIR sensors turning on lights * Door locks sending alarms * Door/window sensors starting chimes * Smoke sensors triggering an alarm system Response time ============= The latency issue is important. When a user (real human being) presses a light button the user expects the light to turn on. cRPLp proposes that nodes in the tree periodically advertises their presence using DAOs. The periodicity is a real beast: Thanks to Trickle, the rate of updates in a (apparently) stable network is low. This is good since it leaves bandwidth for data. But it is not good if existing routes to my lamp fail and I do not get new routes to my lamp until it decides to send out a new DAO. My user will (with a good reason) not tolerate waiting for minutes for the light to turn on. I have met two arguments to counter this concern: A1: Well, your lamp can always send a DAO when it detects a problem. My answer: True, except that my lamp does not intend to send anything so it will never experience any problems from its side of the network. A2: Well, you can increase the DAO rate to sub-second updates. My answer: Oh no. I get a very high degree of management traffic which limits my available bandwidth, increases the risk of collisions and even run the risk of violating EU legislation requiring me to only transmit in less than 1% of the time: http://focus.ti.com/lit/an/swra048/swra048.pdf 868 - 868.6 MHz: <1% Reactiveness is hard to achieve via polling. If you agree that this seems to be critical issues please raise your voice on the list. Going forward ============= We need some reactive mechanism to reach lamps before the user decides to sue our companies. So is this possible? I think so. Existing commercial (non-IP) solutions are capable of re-routing quickly if they really have to. Let me try scoping the requirements to a potential solution: (no different from the req. docs for home and building) * P2P routing in any direction independent of the tree. * On-demand P2P route discovery if requested by a real-time critical app. Data collection apps may be able to just wait for the next DAO update. * Limited range of discovery mechanism: max 4 repeaters. A TTL field may limit the scope of the repeaters. * Suboptimal routing and traffic bursts are accepted in exchange for quick route repair. But only as an exception. Just as an example, one existing home control technology uses a (source routing) variant of AODV for quick route repair. Nothing comes for free. The price is flooding - but not just flooding: Managed flooding using a distributed algorithm running in all participating nodes. The algorithm dampens the flooding in a time, volume and range perspective. Some similar mechanism could be built into RPL for quick route repair. If anyone have alternative proposals, please bring it to the list. Now is the time. Thanks, Anders _____ _______________________________________________ Roll mailing 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_02CA_01CAC6D2.FFBDA190 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Pascal,

 

I have to say I am skeptical of a solution where = destination devices advertise themselves as DAG roots and sources join those = DAGs.  It is not clear to me at network formation how this is known and the number of destination devices and potential source devices would indicate that too = much routing information would need to be retained to make such a solution = make sense economically.

 

From my experience with Smart Energy, we seem resigned to creating relatively few DAGs (maybe only one) then using source routing = to reach devices lower in the DAG.  I would doubt we would invest the = time in forming multiple DAGs or trying to optimize with multiple destination = devices as DAG roots and devices lower in the DAG joining multiple DAG depending = on the destination address of their packets.  Keep in mind we don’t = have the requirement right now for low latency P2P communication in Smart Energy = which I would maintain IS NOT supported in the current RPL = proposal.

 

I encourage you to look at some of the alternative I-Ds = to create a workable solution for P2P communication.  If you believe = that low latency P2P communication is currently supported, I would encourage you = to take some of the requirements from the Building Controls or Home Automation requirements and show how this works with RPL today (particularly = showing the memory storage requirements on the individual devices in the DAG).  = I think you will quickly conclude there is a problem with respect to P2P = routing.

 

Don

 

 

From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Pascal Thubert = (pthubert)
Sent: Thursday, March 18, 2010 7:23 PM
To: robert.cragie@gridmerge.com
Cc: ROLL WG; Ted.Humpal@jci.com
Subject: Re: [Roll] P2P performance with current RPL = proposal

 

Hi Robert :

 

At least from a distance, the proposed mechanism emulates = AODV, with the DIO as RREQ and the DAO as RREP. So if we decide to dig along = those lines, we’ll certainly appreciate help from MANET experts. = I’d say that if you already have RPL for P2MP and MP2P, the proposed extension are probably = simpler to add than doing AODV from scratch.

 

For the setup, the major differences are that we build a = DAG and that we can indicate multiple targets. If you look at it, the DAG = capability is a MUST for RPL, and I have not seen that this MUST goes away for P2P = flows. The multiple targets is something that appears in a number of use cases and = it seems more economical to build a single DAG for multiple targets when = possible.

 

For the maintenance, the major differences are that we = have the DAG as first line of defense, and the RPL detection to stimulate the = local repair.

 

About your questions:

 

The DODAG root is the one that spawns the DAG. The = targets can reach the root because the root advertises itself in the DIO. The idea = is that the root ID is the address that the targets need to talk to. If needed, = the root can also advertise a prefix that it can reach and that the targets = need to reach too.

 

All the intermediate nodes that are confirmed by the DAO = need to retain at least info about the DAG. That enables the targets to reach = the root. The flooding should cost about the same as that of AODV but the RPL way = will require more states in the nodes on the way if the OF requires a = DAG.

 

The way back (down) can be stateful of stateless, = depending on which DAO we’re using. With fully stateful DAO, we are really in = AODV-land. With stateless, we could drift into DSR-land for that direction. Which = limits we place to keep it simple will be determined by the resolution of issue = #26 I guess…

 

And please, no apologize or on one will dare post = anything anymore. Your questions are fully relevant and at the core of the = discussion.

 

I hope we can talk in Anaheim for = sure,

 

Pascal

 

From: Robert Cragie [mailto:robert.cragie@gridmerge.com]
Sent: Monday, March 15, 2010 11:27 AM
To: Pascal Thubert (pthubert)
Cc: Ted.Humpal@jci.com; ROLL WG
Subject: Re: [Roll] P2P performance with current RPL = proposal

 

Hi Pascal,

So in your slideware T can end up talking to R (DODAG root) through the = DODAG. So are you proposing that all potential targets can act as a DODAG root? = And therefore all intermediates have to retain DIO propagation support for = that DODAG as well? This may work for limited P2P but seems less efficient = than simple distance vector flooding RREQ/RREP like AODV or DYMO for generic = P2P. What about R to T (or anyone else for that matter)? Do we source route, maintain state, some undefined hybrid of the two?

I apologise if some of these questions have been answered in detail in = earlier reflector posts but I have only recently started to concentrate my = efforts on RPL and have 82 pages to wade through :-). I look forward to a = productive session in Anaheim.

Robert

Robert Cragie (Pacific Gas & = Electric)

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



Pascal Thubert (pthubert) wrote:

HI Robert :

 

I respectfully have to disagree.

 

My understanding is that we are considering a limited set = of P2P pairs, for which the specific path that we need to create might have to = obey specific constraints.

So it makes sense to use an on-demand technique, probably inspired by the MANET Reactive protocols.

 

As it goes, those protocols usually use flooding for a = node to locate another. Forking a DAG is just another flooding. It does not take = a lot of addition to the existing DIO for a root to use RPL to build a DAG = that contains one or multiple Targets as leaves, under a set of constraints expressed as an objective function. Please find attached a slideware = that illustrates that.

 

Pascal

 

From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] = On Behalf Of Robert Cragie
Sent: Thursday, March 11, 2010 2:43 PM
To: Ted.Humpal@jci.com
Cc: ROLL WG
Subject: Re: [Roll] P2P performance with current RPL = proposal

 

I agree with Ted's comments below. Creating a DODAG for every reachable = node as a root seems a very inefficient approach compared to alternative routing = algorithms. I am concerned that RPL does not actually meet the original requirements = in I-D.ietf-roll-building-routing-reqs, I-D.ietf-roll-home-routing-reqs, = RFC5673 and RFC5548. The traffic pattern requirement for a sink node features prominently in only two of those documents. Even in this case, as Ted = points out, communication is likely to be bidirectional (e.g. end-to-end acks.) therefore the DODAG approach is fundamentally asymmetric, especially if = no intermediate storage is allowed for destination routes and source = routing has to be used.

Also, RPL seems highly complex for what are constrained nodes in terms = of memory as well as power and bandwidth. The RPL draft as it stands is 82 = pages long and that doesn't include text about the objective function.

Robert

Robert Cragie (Pacific Gas & = Electric)

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



Ted.Humpal@jci.com wrote: =


A concern also will be how much overhead (memory space) will be required = for a DODAG Root?

and based on the first question how many DODAG roots a lamp may need to be a = member of?

For example in lighting  a single lamp may be a root for a single = switch (1 DODAG root),  this lamp / luminaire may also =
be a member of another group - -  which could be all lights on the = floor (2nd DODAG root), and a third group
of all the lights in the building.  There can be many more speciality = groups associated based on the building configuration. =
Consider also during the installation time - how these DODAG roots will be = configured?  Must I commission each device
to tell it which DODAG it must use for its Object Function?  How easy = will this be to change and add in a new DODAG root =
for the end user if the lighting group changes??

With respect to Jerry Martocci's - commercial building requirements - every = device may need to communicate to any or
all of the end devices.  If each device must establish a DODAG for the = other 499 devices in a 500 node network - How much memory
space will this require for each end device to maintain?  

Keep in mind that the end devices are very limited processor and memory = wise.

Not to mention all of the network maintenance messages that would need to be transmitted to maintain all of these DODAGs.

Consider the reconvergence time when one device is turned off and it was in the = middle of the majority of the 100+ DODAGS?

In many lighting and building application an application acknowledgement - = must be returned {Back down the DODAG} so . . . the
requirement is not just getting to the Root - a return path must also be maintained = and have a  low latency path.

Ted Humpal



From:

Kris Pister <pister@eecs.berkeley.edu>=

To:

Anders Brandt <abr@sdesigns.dk> =

Cc:

ROLL WG <roll@ietf.org> =

Date:

03/08/2010 01:45 PM

Subject:

Re: [Roll] P2P performance with current RPL proposal

 




Anders - if we take JP's suggestion to make The Lamp a DODAG root, and = take Phoebus' recommendation that we use path diversity to improve end-to-end reliability, do you see a chance of success?
In my experience, with diverse paths and order-minutes updates you get extremely high reliability.

I have no aversion to TTL-limited floods as a part of a solution either.  I'm open to ideas on how to bring those in as (presumably = infrequently used) options.

ksjp

Anders Brandt wrote:
Hello
 
I = would like to probe the temperature of the WG on using DAOs to
support P2P.
 
The = building and home application spaces (and maybe others) have
a = few clearly defined requirements.
It = is not obvious to me how the current RPL proposal (cRPLp) can
satisfy those requirements:
 
 
In = both cases it is the worst case scenario that hurts:
 
 
P2P = routing inside the PAN
=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
cRPLp has no way of routing inside the PAN if you need more than
one = repeater. cRPLp has to go all the way to the top (maybe 4 hops up)
and = down again (maybe 4 hops down) to get just 2 hops to the side.
 
The consequence is high latency and high levels of background noise
for nodes just outside the direct radio range. =
At = the same time the risk of meeting a failing link is 4 times higher = =3D>
latency may be much more than 4 times larger.
 
Latency may sound like a minor issue but it actually translates directly
into lower battery lifetime. In the above (very realistic) = example,
the = battery lifetime is reduced to 25% of what it should be. =
 
We = have lots of battery devices sending into the network:
* = PIR sensors turning on lights
* = Door locks sending alarms
* = Door/window sensors starting chimes
* = Smoke sensors triggering an alarm system
 
 
 
 
Response time
=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D
The = latency issue is important.
When a user (real human being) presses a light button the user expects
the = light to turn on.
cRPLp proposes that nodes in the tree periodically advertises their
presence using DAOs.
The periodicity is a real beast:
Thanks to Trickle, the rate of updates in a (apparently) stable network
is low. This is good since it leaves bandwidth for data.
But = it is not good if existing routes to my lamp fail and I do not get
new = routes to my lamp until it decides to send out a new DAO. =
My = user will (with a good reason) not tolerate waiting for minutes for
the = light to turn on.
 
I = have met two arguments to counter this concern:
 
A1: = Well, your lamp can always send a DAO when it detects a problem.
  My answer:
  True, except that my lamp does not intend to send anything
  so it will never experience any problems from its side of the = network.
 
A2: = Well, you can increase the DAO rate to sub-second updates. =
  My answer:
  Oh no. I get a very high degree = of management traffic which
  limits my available bandwidth, increases the risk of collisions and
  even run the risk of violating EU legislation requiring me to = only
  transmit in less than 1% of the time:
  http://focus.ti.com/lit/an/= swra048/swra048.pdf
 868 - 868.6 MHz: <1%
 
  Reactiveness is hard to achieve via polling.
 
 
 
If = you agree that this seems to be critical issues please raise your
voice on the list.
 
Going forward
=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D
 
We = need some reactive mechanism to reach lamps before the user decides
to = sue our companies.
So = is this possible? I think so.

Existing commercial (non-IP) solutions are capable of re-routing = quickly
if = they really have to.
 
Let = me try scoping the requirements to a potential solution: =
(no = different from the req. docs for home and building)
 
* = P2P routing in any direction independent of the tree.
 
* = On-demand P2P route discovery if requested by a real-time critical app.
 Data collection apps may be able to just wait for the next DAO = update.
 
* = Limited range of discovery mechanism: max 4 repeaters. =
  A TTL field may limit the scope of the repeaters.
 
* = Suboptimal routing and traffic bursts are accepted in exchange
  for quick route repair. But only as an exception. =
 
 
Just as an example, one existing home control technology uses a
(source routing) variant of AODV for quick route repair.
Nothing comes for free. The price is flooding - but not just flooding:
Managed flooding using a distributed algorithm running in all
participating nodes.
The = algorithm dampens the flooding in a time, volume and range perspective. =
Some similar mechanism could be built into RPL for quick route repair.
 
 
If = anyone have alternative proposals, please bring it to the list.
Now = is the time.
 
 
 
Thanks,
  Anders


______________________________________________= _
Roll mailing = 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_02CA_01CAC6D2.FFBDA190-- From mijeom@gmail.com Thu Mar 18 21:06: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 A96283A692E for ; Thu, 18 Mar 2010 21:06:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.817 X-Spam-Level: X-Spam-Status: No, score=-1.817 tagged_above=-999 required=5 tests=[AWL=-0.348, 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 0xWCYmRw668R for ; Thu, 18 Mar 2010 21:06:09 -0700 (PDT) Received: from mail-px0-f177.google.com (mail-px0-f177.google.com [209.85.216.177]) by core3.amsl.com (Postfix) with ESMTP id F40BC3A68FB for ; Thu, 18 Mar 2010 21:06:08 -0700 (PDT) Received: by pxi7 with SMTP id 7so684946pxi.5 for ; Thu, 18 Mar 2010 21:06:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=t4lpn/B7XIAXn4EOBun230YW+hFX4h9rv9Y1av8vI0Y=; b=JazLN5uN2J3I7Ts9UowFerDZ/Cc1OFIhPzc7KHFpW8707kZNGzQzzr2c3N4Bw4yXpL 6fXsVXUVjurD9uLDYW86ttvfJ2GfSzQNP2G85tpX/O/iuNLX9Tzg2T+nIfGYHfPjPAIQ QXysbdZsSkcCUolaXpgCLWA9qQB7v1N8FCp2U= 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=iNfZX96gdi26z1lVeHYdcgR5BMDr3r4fqljr/6agHATy8HUdcEmlvTryj5oN5wdtgg mmYMutpyVeYbxalov7lJkE3Us3mky8pKFUptGLN4Ou6Q7Buar9s/h8O2QhJ0cugbXrAu xotGK1VoYRsxwWxKfuutKlwbLXF4wyP49ZWAw= MIME-Version: 1.0 Received: by 10.143.24.23 with SMTP id b23mr1776483wfj.247.1268971577452; Thu, 18 Mar 2010 21:06:17 -0700 (PDT) In-Reply-To: <513D9DE7-0798-4423-8450-161697F6248C@cs.stanford.edu> References: <055.28872d5d0fcf65e6839f1cd72771083c@tools.ietf.org> <064.2a20a25a31ddeb41de55f5c2ba559806@tools.ietf.org> <4B90DF6D.9070806@gmail.com> <4B94D55E.7080302@gmail.com> <8E09C72DBC577D489F13A71228C0B7BF0105150F@ftrdmel0.rd.francetelecom.fr> <4B97D5D7.5050909@gmail.com> <513D9DE7-0798-4423-8450-161697F6248C@cs.stanford.edu> Date: Fri, 19 Mar 2010 13:06:17 +0900 Message-ID: From: MiJeom Kim To: Philip Levis Content-Type: text/plain; charset=ISO-8859-1 Cc: roll@ietf.org Subject: Re: [Roll] [roll] #18: Numeric Ranges in Routing Metric X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 19 Mar 2010 04:06:09 -0000 How about we just leave it with 24 unsigned integer at least for now since it's the result of the long discussion. And 1 byte is pretty valuable here. Mijeom. On Wed, Mar 17, 2010 at 2:44 PM, Philip Levis wrote: > > On Mar 16, 2010, at 6:30 PM, MiJeom Kim wrote: > >> Hi, >> >> Let's try to close on this ticket. >> So, let's express latency metric with 24 unsigned integer in unit of >> microsecond. >> We don't need to restrict the increasing unit to 10 microsecond. >> And throughput metric uses 32 unsigned integer to present bytes per >> second. > > Shouldn't latency be 32 bits as well? 24 bits means up to 2^4 seconds. With > low power link layers, that seems like close enough to be comfortable for > now, but doesn't have a lot of space to grow. > > Phil > From mijeom@gmail.com Thu Mar 18 21:59: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 417853A6A16 for ; Thu, 18 Mar 2010 21:59:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.768 X-Spam-Level: X-Spam-Status: No, score=-1.768 tagged_above=-999 required=5 tests=[AWL=-0.299, 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 hHhZ8CqlC7qz for ; Thu, 18 Mar 2010 21:59:27 -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 8D0873A69D4 for ; Thu, 18 Mar 2010 21:59:27 -0700 (PDT) Received: by pwi10 with SMTP id 10so864378pwi.31 for ; Thu, 18 Mar 2010 21:59:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=yt+V+n9wIDFklSZHI4qEdko0rm50nV8IXuABI2b8VmM=; b=sCVQWJGVAC5FoXTs8spSJsQdNZuj4btSSyGq82DX7qwRmWHYQLqerg4lQrcv2WHyLI nbOyLNk4FCOM6KpFsNVjqVcutXW2ctX4ds1JILcqo+rllHVCJVv/FQP8uVXyFvhI2FlP Op0HdD7ZunxKgbAUOnLB/y7Zyvl1nLahySXMg= 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=ovmhMDfYd2yyG2Gi7bIhCNjQlsDBK15SI803uiZzg9TyWF1l2cNwIoOK24iJSXqT7S izAkXTopYiqmmZkX6i8TNqwr8xIDXvO5bBMZKj9KIRqJYYBlbgC1OvVbznYWtnTHKjKd jYjnrs/LAenfm6Qp+ZWc3jJiJMTO1RusHA6HY= MIME-Version: 1.0 Received: by 10.142.210.17 with SMTP id i17mr1834337wfg.146.1268974776589; Thu, 18 Mar 2010 21:59:36 -0700 (PDT) In-Reply-To: References: <055.a3c60804880e85f93fc1826167be4fb6@tools.ietf.org> <064.2fcbbc9928617712d033305fbb1562c6@tools.ietf.org> <87pr333z1s.fsf@kelsey-ws.hq.ember.com> Date: Fri, 19 Mar 2010 13:59:36 +0900 Message-ID: From: MiJeom Kim To: Omprakash Gnawali Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: roll@ietf.org Subject: Re: [Roll] [roll] #20: Question on Metric 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: Fri, 19 Mar 2010 04:59:28 -0000 Okay, then. Let make ETX * 128 as a 16 bit unsigned integer. (With 16 bits, the range can be up to 65535 so we may use a bigger number (like 256) as the Constant C. But, let's just leave it for now.) And let's round off to the nearest whole number. For example, if ETX =3D 3.569, the metric value will be 457. If ETX > 511.9921875, let make the metric vale the maximum which is 65535. Mijeom. On Thu, Mar 18, 2010 at 10:41 AM, Omprakash Gnawali wrote: > On Wed, Mar 17, 2010 at 8:18 AM, Philip Levis wrote= : >> >> On Mar 17, 2010, at 5:36 AM, Richard Kelsey wrote: >> >>>> From: "roll issue tracker" >>>> Date: Wed, 17 Mar 2010 01:58:04 -0000 >>>> >>>> #20: Question on Metric ID >>>> >>>> Comment: >>>> >>>> =A0After long discussion, we concluded as follows: >>>> >>>> =A0- Throughput: 32 unsigned integer in unit of microsecond >>>> >>>> =A0- Latency: 24 unsigned integer in unit of bytes per second >>>> >>>> =A0- ETX: 1 byte to present (ETX * C) as (32 + a) * 2^b >>>> =A0 where C =3D 64, 0 <=3D a <=3D 31 and 0 <=3D b <=3D 7. >>>> =A0 If ETX >=3D 126, we can assume ETX is infinity. >>>> =A0(First 5 bits for a and the rest 3 bits for b.) >>> >>> I applaud the decision not to use floating point for >>> throughput and latency. =A0Can we please do the same for ETX? >>> Many of the same arguments apply to it as well (e.g. >>> http://www.ietf.org/mail-archive/web/roll/current/msg03104.html). >>> Make it ETX * 64 as a 16-bit unsigned integer. >> >> +1 >> >> Phil > > +1 for not using floating point for ETX. > > - om_p > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > From prvs=68763956a=mukul@uwm.edu Fri Mar 19 00:08: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 EBEC33A687D for ; Fri, 19 Mar 2010 00:08:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.862 X-Spam-Level: X-Spam-Status: No, score=-1.862 tagged_above=-999 required=5 tests=[AWL=-0.393, 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 YxSwUaeN3s9q for ; Fri, 19 Mar 2010 00:08:56 -0700 (PDT) Received: from ip1mta.uwm.edu (ip1mta.uwm.edu [129.89.7.18]) by core3.amsl.com (Postfix) with ESMTP id 17D7E3A67FC for ; Fri, 19 Mar 2010 00:08:56 -0700 (PDT) Received: from mta02.pantherlink.uwm.edu ([129.89.7.82]) by ip1mta.uwm.edu with ESMTP; 19 Mar 2010 02:09:08 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by mta02.pantherlink.uwm.edu (Postfix) with ESMTP id 45FCC2C38016; Fri, 19 Mar 2010 02:09:08 -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 Mzt+4kLXvs9f; Fri, 19 Mar 2010 02:09:07 -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 F30AC2C38015; Fri, 19 Mar 2010 02:09:06 -0500 (CDT) Date: Fri, 19 Mar 2010 02:09:06 -0500 (CDT) From: Mukul Goyal To: "Pascal Thubert (pthubert)" Message-ID: <836717245.7606741268982546867.JavaMail.root@mail02.pantherlink.uwm.edu> In-Reply-To: <6A2A459175DABE4BB11DE2026AA50A5D01792E48@XMB-AMS-107.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Originating-IP: [129.89.7.91] X-Mailer: Zimbra 5.0.22_GA_3210.RHEL4_64 (ZimbraWebClient - [unknown] (Win)/5.0.22_GA_3210.RHEL4_64) X-Authenticated-User: mukul@uwm.edu Cc: ROLL WG , Ted Humpal Subject: Re: [Roll] P2P performance with current RPL proposal X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Mar 2010 07:09:19 -0000 Pascal, WG: Here I have attempted to formulate a simple DV algorithm in RPL/DAG terms. = I will appreciate it if you could let me know about your objections to this= proposal: Node A needs to reach a destination D. Node A initiates a discovery DAG tow= ards D. As the DIOs reach D, it sends a DAO back to selected parents. As th= e DAO travels towards node A, in-route nodes store the cost to reach D. When node B needs to reach D, it similarly initiates a discovery dag. Durin= g this discovery, when a DIO reaches a node C that maintains a cost to reac= h D, node C responds back with a DAO that travels towards B and stores in i= n-route nodes the cost to reach D. Thus, as more and more nodes try to discover a route to D, a destination or= iented DAG (DODAG) emerges that leads these nodes to D. The difference from= the traditional DODAG, as explained in RPL draft, is that the DAG root doe= s not initiate DAG formation. The leaf nodes initiate the discovery of the = DAG root. Now, we can go one step further in order to save on memory =E2=80=93 combin= e DODAGs leading to D and another destination E into one. This can be done = by aggregating the cost to reach D and E into one cost (the higher of the t= wo) and letting parent nodes know about the aggregated cost. Repeated aggre= gations can help reduce memory requirements at the cost of suboptimality. Thanks Mukul ----- Original Message ----- From: "Pascal Thubert (pthubert)" To: "robert cragie" Cc: "ROLL WG" , "Ted Humpal" Sent: Thursday, March 18, 2010 9:23:14 PM GMT -06:00 US/Canada Central Subject: Re: [Roll] P2P performance with current RPL proposal Hi Robert=C2=A0:=20 =C2=A0=20 At least from a distance, the proposed mechanism emulates AODV, with the DI= O as RREQ and the DAO as RREP. So if we decide to dig along those lines, we= =E2=80=99ll certainly appreciate help from MANET experts. I=E2=80=99d say t= hat if you already have RPL for P2MP and MP2P, the proposed extension are p= robably simpler to add than doing AODV from scratch.=20 =C2=A0=20 For the setup, the major differences are that we build a DAG and that we ca= n indicate multiple targets. If you look at it, the DAG capability is a MUS= T for RPL, and I have not seen that this MUST goes away for P2P flows. The = multiple targets is something that appears in a number of use cases and it = seems more economical to build a single DAG for multiple targets when possi= ble.=20 =C2=A0=20 For the maintenance, the major differences are that we have the DAG as firs= t line of defense, and the RPL detection to stimulate the local repair.=20 =C2=A0=20 About your questions:=20 =C2=A0=20 The DODAG root is the one that spawns the DAG. The targets can reach the ro= ot because the root advertises itself in the DIO. The idea is that the root= ID is the address that the targets need to talk to. If needed, the root ca= n also advertise a prefix that it can reach and that the targets need to re= ach too.=20 =C2=A0=20 All the intermediate nodes that are confirmed by the DAO need to retain at = least info about the DAG. That enables the targets to reach the root. The f= looding should cost about the same as that of AODV but the RPL way will req= uire more states in the nodes on the way if the OF requires a DAG.=20 =C2=A0=20 The way back (down) can be stateful of stateless, depending on which DAO we= =E2=80=99re using. With fully stateful DAO, we are really in AODV-land. Wit= h stateless, we could drift into DSR-land for that direction. Which limits = we place to keep it simple will be determined by the resolution of issue #2= 6 I guess=E2=80=A6=20 =C2=A0=20 And please, no apologize or on one will dare post anything anymore. Your qu= estions are fully relevant and at the core of the discussion.=20 =C2=A0=20 I hope we can talk in Anaheim for sure,=20 Pascal=20 =C2=A0=20 From: Robert Cragie [mailto:robert.cragie@gridmerge.com]=20 Sent: Monday, March 15, 2010 11:27 AM=20 To: Pascal Thubert (pth ubert)=20 Cc: Ted.Humpal@jci.com; ROLL WG=20 Subject: Re: [Roll] P2P performance with current RPL proposal=20 =C2=A0=20 Hi Pascal,=20 So in your slideware T can end up talking to R (DODAG root) through the DOD= AG. So are you proposing that all potential targets can act as a DODAG root= ? And therefore all intermediates have to retain DIO propagation support fo= r that DODAG as well? This may work for limited P2P but seems less efficien= t than simple distance vector flooding RREQ/RREP like AODV or DYMO for gene= ric P2P. What about R to T (or anyone else for that matter)? Do we source r= oute, maintain state, some undefined hybrid of the two?=20 I apologise if some of these questions have been answered in detail in earl= ier reflector posts but I have only recently started to concentrate my effo= rts on RPL and have 82 pages to wade through :-). I look forward to a produ= ctive session in Anaheim.=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 Pascal Thubert (pthubert) wrote:=20 HI Robert=C2=A0:=20 =C2=A0=20 I respectfully have to disagree.=20 =C2=A0=20 My understanding is that we are considering a limited set of P2P pairs, for= which the specific path that we need to create might have to obey specific= constraints.=20 So it makes sense to use an on-demand technique, probably inspired by the M= ANET Reactive protocols.=20 =C2=A0=20 As it goes, those protocols usually use flooding for a node to locate anoth= er. Forking a DAG is just another flooding. It does not take a lot of addit= ion to the existing DIO for a root to use RPL to build a DAG that contains = one or multiple Targets as leaves, under a set of constraints expressed as = an objective function. Please find attached a slideware that illustrates th= at.=20 =C2=A0=20 Pascal=20 =C2=A0=20 From: roll-bounces@ietf.org [ mailto:roll-bounces@ietf.org ] On Behalf Of R= obert Cragie=20 Sent: Thursday, March 11, 2010 2:43 PM=20 To: Ted.Humpal@jci.com=20 Cc: ROLL WG=20 Subject: Re: [Roll] P2P performance with current RPL proposal=20 =C2=A0=20 I agree with Ted's comments below. Creating a DODAG for every reachable nod= e as a root seems a very inefficient approach compared to alternative routi= ng algorithms. I am concerned that RPL does not actually meet the original = requirements in I-D.ietf-roll-building-routing-reqs, I-D.ietf-roll-home-rou= ting-reqs, RFC5673 and RFC5548. The traffic pattern requirement for a sink = node features prominently in only two of those documents. Even in this case= , as Ted points out, communication is likely to be bidirectional (e.g. end-= to-end acks.) therefore the DODAG approach is fundamentally asymmetric, esp= ecially if no intermediate storage is allowed for destination routes and so= urce routing has to be used.=20 Also, RPL seems highly complex for what are constrained nodes in terms of m= emory as well as power and bandwidth. The RPL draft as it stands is 82 page= s long and that doesn't include text about the objective function.=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 Ted.Humpal@jci.com wrote:=20 A concern also will be how much overhead (memory space) will be required fo= r a DODAG Root?=20 and based on the first question how many DODAG roots a lamp may need to be = a member of?=20 For example in lighting =C2=A0a single lamp may be a root for a single swit= ch (1 DODAG root), =C2=A0this lamp / luminaire may also=20 be a member of another group - - =C2=A0which could be all lights on the flo= or (2nd DODAG root), and a third group=20 of all the lights in the building. =C2=A0There can be many more speciality = groups associated based on the building configuration.=20 Consider also during the installation time - how these DODAG roots will be = configured? =C2=A0Must I commission each device=20 to tell it which DODAG it must use for its Object Function? =C2=A0How easy = will this be to change and add in a new DODAG root=20 for the end user if the lighting group changes??=20 With respect to Jerry Martocci's - commercial building requirements - every= device may need to communicate to any or=20 all of the end devices. =C2=A0If each device must establish a DODAG for the= other 499 devices in a 500 node network - How much memory=20 space will this require for each end device to maintain? =C2=A0=20 Keep in mind that the end devices are very limited processor and memory wis= e.=20 Not to mention all of the network maintenance messages that would need to b= e transmitted to maintain all of these DODAGs.=20 Consider the reconvergence time when one device is turned off and it was in= the middle of the majority of the 100+ DODAGS?=20 In many lighting and building application an application acknowledgement - = must be returned {Back down the DODAG} so . . . the=20 requirement is not just getting to the Root - a return path must also be ma= intained and have a =C2=A0low latency path.=20 Ted Humpal=20 From: =09 Kris Pister =20 To: =09 Anders Brandt =20 Cc: =09 ROLL WG =20 Date: =09 03/08/2010 01:45 PM=20 Subject: =09 Re: [Roll] P2P performance with current RPL proposal=20 =C2=A0=20 Anders - if we take JP's suggestion to make The Lamp a DODAG root, and take= Phoebus' recommendation that we use path diversity to improve end-to-end r= eliability, do you see a chance of success?=20 In my experience, with diverse paths and order-minutes updates you get extr= emely high reliability.=20 I have no aversion to TTL-limited floods as a part of a solution either. = =C2=A0I'm open to ideas on how to bring those in as (presumably infrequentl= y used) options.=20 ksjp=20 Anders Brandt wrote:=20 Hello=20 =C2=A0=20 I would like to probe the temperature of the WG on using DAOs to=20 support P2P.=20 =C2=A0=20 The building and home application spaces (and maybe others) have=20 a few clearly defined requirements.=20 It is not obvious to me how the current RPL proposal (cRPLp) can=20 satisfy those requirements:=20 =C2=A0=20 =C2=A0=20 In both cases it is the worst case scenario that hurts:=20 =C2=A0=20 =C2=A0=20 P2P routing inside the PAN=20 =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=20 cRPLp has no way of routing inside the PAN if you need more than=20 one repeater. cRPLp has to go all the way to the top (maybe 4 hops up)=20 and down again (maybe 4 hops down) to get just 2 hops to the side.=20 =C2=A0=20 The consequence is high latency and high levels of background noise=20 for nodes just outside the direct radio range.=20 At the same time the risk of meeting a failing link is 4 times higher =3D>= =20 latency may be much more than 4 times larger.=20 =C2=A0=20 Latency may sound like a minor issue but it actually translates directly=20 into lower battery lifetime. In the above (very realistic) example,=20 the battery lifetime is reduced to 25% of what it should be.=20 =C2=A0=20 We have lots of battery devices sending into the network:=20 * PIR sensors turning on lights=20 * Door locks sending alarms=20 * Door/window sensors starting chimes=20 * Smoke sensors triggering an alarm system=20 =C2=A0=20 =C2=A0=20 =C2=A0=20 =C2=A0=20 Response time=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=20 The latency issue is important.=20 When a user (real human being) presses a light button the user expects=20 the light to turn on.=20 cRPLp proposes that nodes in the tree periodically advertises their=20 presence using DAOs.=20 The periodicity is a real beast:=20 Thanks to Trickle, the rate of updates in a (apparently) stable network=20 is low. This is good since it leaves bandwidth for data.=20 But it is not good if existing routes to my lamp fail and I do not get=20 new routes to my lamp until it decides to send out a new DAO.=20 My user will (with a good reason) not tolerate waiting for minutes for=20 the light to turn on.=20 =C2=A0=20 I have met two arguments to counter this concern:=20 =C2=A0=20 A1: Well, your lamp can always send a DAO when it detects a problem.=20 =C2=A0 My answer:=20 =C2=A0 True, except that my lamp does not intend to send anything=20 =C2=A0 so it will never experience any problems from its side of the networ= k.=20 =C2=A0=20 A2: Well, you can increase the DAO rate to sub-second updates.=20 =C2=A0 My answer:=20 =C2=A0 Oh no. I get a very high degree of management traffic which=20 =C2=A0 limits my available bandwidth, increases the risk of collisions and= =20 =C2=A0 even run the risk of violating EU legislation requiring me to only= =20 =C2=A0 transmit in less than 1% of the time:=20 =C2=A0 http://focus.ti.com/lit/an/swra048/swra048.pdf=20 =C2=A0868 - 868.6 MHz: <1%=20 =C2=A0=20 =C2=A0 Reactiveness is hard to achieve via polling.=20 =C2=A0=20 =C2=A0=20 =C2=A0=20 If you agree that this seems to be critical issues please raise your=20 voice on the list.=20 =C2=A0=20 Going forward=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=20 =C2=A0=20 We need some reactive mechanism to reach lamps before the user decides=20 to sue our companies.=20 So is this possible? I think so.=20 Existing commercial (non-IP) solutions are capable of re-routing quickly=20 if they really have to.=20 =C2=A0=20 Let me try scoping the requirements to a potential solution:=20 (no different from the req. docs for home and building)=20 =C2=A0=20 * P2P routing in any direction independent of the tree.=20 =C2=A0=20 * On-demand P2P route discovery if requested by a real-time critical app.= =20 =C2=A0Data collection apps may be able to just wait for the next DAO update= .=20 =C2=A0=20 * Limited range of discovery mechanism: max 4 repeaters.=20 =C2=A0 A TTL field may limit the scope of the repeaters.=20 =C2=A0=20 * Suboptimal routing and traffic bursts are accepted in exchange=20 =C2=A0 for quick route repair. But only as an exception.=20 =C2=A0=20 =C2=A0=20 Just as an example, one existing home control technology uses a=20 (source routing) variant of AODV for quick route repair.=20 Nothing comes for free. The price is flooding - but not just flooding:=20 Managed flooding using a distributed algorithm running in all=20 participating nodes.=20 The algorithm dampens the flooding in a time, volume and range perspective.= =20 Some similar mechanism could be built into RPL for quick route repair.=20 =C2=A0=20 =C2=A0=20 If anyone have alternative proposals, please bring it to the list.=20 Now is the time.=20 =C2=A0=20 =C2=A0=20 =C2=A0=20 Thanks,=20 =C2=A0 Anders=20 _______________________________________________=20 Roll mailing list=20 Roll@ietf.org=20 https://www.ietf.org/mailman/listinfo/roll=20 =C2=A0_______________________________________________=20 Roll mailing list=20 Roll@ietf.org=20 https://www.ietf.org/mailman/listinfo/roll=20 =C2=A0=20 =C2=A0 _______________________________________________ Roll mailing list Ro= ll@ietf.org https://www.ietf.org/mailman/listinfo/roll =C2=A0=20 _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From abr@sdesigns.dk Fri Mar 19 00:38: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 10DD33A697B for ; Fri, 19 Mar 2010 00:38:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.741 X-Spam-Level: X-Spam-Status: No, score=-0.741 tagged_above=-999 required=5 tests=[AWL=-0.669, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JnjpmCzo0qL2 for ; Fri, 19 Mar 2010 00:38:01 -0700 (PDT) Received: from mail.zen-sys.com (mail.zen-sys.com [195.215.56.170]) by core3.amsl.com (Postfix) with ESMTP id E0BDC3A68D7 for ; Fri, 19 Mar 2010 00:37: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_01CAC737.1D1642C2" Date: Fri, 19 Mar 2010 08:37:36 +0100 Message-ID: <6D9687E95918C04A8B30A7D6DA805A3E01AD45C5@zensys17.zensys.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] P2P performance with current RPL proposal Thread-Index: AcrEbU1tfn0308v7QGeWK3YmnqapOAClmO0QAAIVugAACsDrww== References: <6D9687E95918C04A8B30A7D6DA805A3E01429F5F@zensys17.zensys.local><4B9553B8.6010001@eecs.berkeley.edu> <4B98F374.4030301@gridmerge.com> <6A2A459175DABE4BB11DE2026AA50A5D0170DFA9@XMB-AMS-107.cisco.com> <4B9E7BE8.9060109@gridmerge.com><6A2A459175DABE4BB11DE2026AA50A5D01792E48@XMB-AMS-107.cisco.com> <02c901cac70d$ac1c7990$04556cb0$@sturek@att.net> From: "Anders Brandt" To: , "Pascal Thubert (pthubert)" , Cc: ROLL WG , Ted.Humpal@jci.com Subject: Re: [Roll] P2P performance with current RPL proposal X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Mar 2010 07:38:19 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CAC737.1D1642C2 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable +1 =20 Anders ________________________________ Fra: roll-bounces@ietf.org p=E5 vegne af Don Sturek Sendt: fr 19-03-2010 03:41 Til: 'Pascal Thubert (pthubert)'; robert.cragie@gridmerge.com Cc: 'ROLL WG'; Ted.Humpal@jci.com Emne: Re: [Roll] P2P performance with current RPL proposal Hi Pascal, =20 I have to say I am skeptical of a solution where destination devices = advertise themselves as DAG roots and sources join those DAGs. It is = not clear to me at network formation how this is known and the number of = destination devices and potential source devices would indicate that too = much routing information would need to be retained to make such a = solution make sense economically. =20 >From my experience with Smart Energy, we seem resigned to creating = relatively few DAGs (maybe only one) then using source routing to reach = devices lower in the DAG. I would doubt we would invest the time in = forming multiple DAGs or trying to optimize with multiple destination = devices as DAG roots and devices lower in the DAG joining multiple DAG = depending on the destination address of their packets. Keep in mind we = don't have the requirement right now for low latency P2P communication = in Smart Energy which I would maintain IS NOT supported in the current = RPL proposal. =20 I encourage you to look at some of the alternative I-Ds to create a = workable solution for P2P communication. If you believe that low = latency P2P communication is currently supported, I would encourage you = to take some of the requirements from the Building Controls or Home = Automation requirements and show how this works with RPL today = (particularly showing the memory storage requirements on the individual = devices in the DAG). I think you will quickly conclude there is a = problem with respect to P2P routing. =20 Don =20 =20 From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of = Pascal Thubert (pthubert) Sent: Thursday, March 18, 2010 7:23 PM To: robert.cragie@gridmerge.com Cc: ROLL WG; Ted.Humpal@jci.com Subject: Re: [Roll] P2P performance with current RPL proposal =20 Hi Robert : =20 At least from a distance, the proposed mechanism emulates AODV, with the = DIO as RREQ and the DAO as RREP. So if we decide to dig along those = lines, we'll certainly appreciate help from MANET experts. I'd say that = if you already have RPL for P2MP and MP2P, the proposed extension are = probably simpler to add than doing AODV from scratch. =20 For the setup, the major differences are that we build a DAG and that we = can indicate multiple targets. If you look at it, the DAG capability is = a MUST for RPL, and I have not seen that this MUST goes away for P2P = flows. The multiple targets is something that appears in a number of use = cases and it seems more economical to build a single DAG for multiple = targets when possible. =20 For the maintenance, the major differences are that we have the DAG as = first line of defense, and the RPL detection to stimulate the local = repair. =20 About your questions: =20 The DODAG root is the one that spawns the DAG. The targets can reach the = root because the root advertises itself in the DIO. The idea is that the = root ID is the address that the targets need to talk to. If needed, the = root can also advertise a prefix that it can reach and that the targets = need to reach too. =20 All the intermediate nodes that are confirmed by the DAO need to retain = at least info about the DAG. That enables the targets to reach the root. = The flooding should cost about the same as that of AODV but the RPL way = will require more states in the nodes on the way if the OF requires a = DAG. =20 The way back (down) can be stateful of stateless, depending on which DAO = we're using. With fully stateful DAO, we are really in AODV-land. With = stateless, we could drift into DSR-land for that direction. Which limits = we place to keep it simple will be determined by the resolution of issue = #26 I guess... =20 And please, no apologize or on one will dare post anything anymore. Your = questions are fully relevant and at the core of the discussion. =20 I hope we can talk in Anaheim for sure, =20 Pascal =20 From: Robert Cragie [mailto:robert.cragie@gridmerge.com]=20 Sent: Monday, March 15, 2010 11:27 AM To: Pascal Thubert (pthubert) Cc: Ted.Humpal@jci.com; ROLL WG Subject: Re: [Roll] P2P performance with current RPL proposal =20 Hi Pascal, So in your slideware T can end up talking to R (DODAG root) through the = DODAG. So are you proposing that all potential targets can act as a = DODAG root? And therefore all intermediates have to retain DIO = propagation support for that DODAG as well? This may work for limited = P2P but seems less efficient than simple distance vector flooding = RREQ/RREP like AODV or DYMO for generic P2P. What about R to T (or = anyone else for that matter)? Do we source route, maintain state, some = undefined hybrid of the two? I apologise if some of these questions have been answered in detail in = earlier reflector posts but I have only recently started to concentrate = my efforts on RPL and have 82 pages to wade through :-). I look forward = to a productive session in Anaheim. Robert Robert Cragie (Pacific Gas & Electric) Gridmerge Ltd. 89 Greenfield Crescent, Wakefield, WF4 4WA, UK +44 (0) 1924 910888 http://www.gridmerge.com =20 Pascal Thubert (pthubert) wrote:=20 HI Robert : =20 I respectfully have to disagree. =20 My understanding is that we are considering a limited set of P2P pairs, = for which the specific path that we need to create might have to obey = specific constraints.=20 So it makes sense to use an on-demand technique, probably inspired by = the MANET Reactive protocols. =20 As it goes, those protocols usually use flooding for a node to locate = another. Forking a DAG is just another flooding. It does not take a lot = of addition to the existing DIO for a root to use RPL to build a DAG = that contains one or multiple Targets as leaves, under a set of = constraints expressed as an objective function. Please find attached a = slideware that illustrates that. =20 Pascal =20 From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of = Robert Cragie Sent: Thursday, March 11, 2010 2:43 PM To: Ted.Humpal@jci.com Cc: ROLL WG Subject: Re: [Roll] P2P performance with current RPL proposal =20 I agree with Ted's comments below. Creating a DODAG for every reachable = node as a root seems a very inefficient approach compared to alternative = routing algorithms. I am concerned that RPL does not actually meet the = original requirements in I-D.ietf-roll-building-routing-reqs, = I-D.ietf-roll-home-routing-reqs, RFC5673 and RFC5548. The traffic = pattern requirement for a sink node features prominently in only two of = those documents. Even in this case, as Ted points out, communication is = likely to be bidirectional (e.g. end-to-end acks.) therefore the DODAG = approach is fundamentally asymmetric, especially if no intermediate = storage is allowed for destination routes and source routing has to be = used. Also, RPL seems highly complex for what are constrained nodes in terms = of memory as well as power and bandwidth. The RPL draft as it stands is = 82 pages long and that doesn't include text about the objective = function. Robert Robert Cragie (Pacific Gas & Electric) Gridmerge Ltd. 89 Greenfield Crescent, Wakefield, WF4 4WA, UK +44 (0) 1924 910888 http://www.gridmerge.com =20 Ted.Humpal@jci.com wrote:=20 A concern also will be how much overhead (memory space) will be required = for a DODAG Root?=20 and based on the first question how many DODAG roots a lamp may need to = be a member of?=20 For example in lighting a single lamp may be a root for a single switch = (1 DODAG root), this lamp / luminaire may also=20 be a member of another group - - which could be all lights on the floor = (2nd DODAG root), and a third group=20 of all the lights in the building. There can be many more speciality = groups associated based on the building configuration.=20 Consider also during the installation time - how these DODAG roots will = be configured? Must I commission each device=20 to tell it which DODAG it must use for its Object Function? How easy = will this be to change and add in a new DODAG root=20 for the end user if the lighting group changes??=20 With respect to Jerry Martocci's - commercial building requirements - = every device may need to communicate to any or=20 all of the end devices. If each device must establish a DODAG for the = other 499 devices in a 500 node network - How much memory=20 space will this require for each end device to maintain? =20 Keep in mind that the end devices are very limited processor and memory = wise.=20 Not to mention all of the network maintenance messages that would need = to be transmitted to maintain all of these DODAGs.=20 Consider the reconvergence time when one device is turned off and it was = in the middle of the majority of the 100+ DODAGS?=20 In many lighting and building application an application acknowledgement = - must be returned {Back down the DODAG} so . . . the=20 requirement is not just getting to the Root - a return path must also be = maintained and have a low latency path.=20 Ted Humpal=20 From:=20 Kris Pister = =20 To:=20 Anders Brandt =20 Cc:=20 ROLL WG =20 Date:=20 03/08/2010 01:45 PM=20 Subject:=20 Re: [Roll] P2P performance with current RPL proposal =20 ________________________________ Anders - if we take JP's suggestion to make The Lamp a DODAG root, and = take Phoebus' recommendation that we use path diversity to improve = end-to-end reliability, do you see a chance of success? In my experience, with diverse paths and order-minutes updates you get = extremely high reliability. I have no aversion to TTL-limited floods as a part of a solution either. = I'm open to ideas on how to bring those in as (presumably infrequently = used) options. ksjp Anders Brandt wrote:=20 Hello=20 =20 I would like to probe the temperature of the WG on using DAOs to=20 support P2P.=20 =20 The building and home application spaces (and maybe others) have=20 a few clearly defined requirements.=20 It is not obvious to me how the current RPL proposal (cRPLp) can=20 satisfy those requirements:=20 =20 =20 In both cases it is the worst case scenario that hurts:=20 =20 =20 P2P routing inside the PAN=20 =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=20 cRPLp has no way of routing inside the PAN if you need more than=20 one repeater. cRPLp has to go all the way to the top (maybe 4 hops up)=20 and down again (maybe 4 hops down) to get just 2 hops to the side.=20 =20 The consequence is high latency and high levels of background noise for nodes just outside the direct radio range.=20 At the same time the risk of meeting a failing link is 4 times higher = =3D>=20 latency may be much more than 4 times larger.=20 =20 Latency may sound like a minor issue but it actually translates directly into lower battery lifetime. In the above (very realistic) example,=20 the battery lifetime is reduced to 25% of what it should be.=20 =20 We have lots of battery devices sending into the network:=20 * PIR sensors turning on lights=20 * Door locks sending alarms=20 * Door/window sensors starting chimes=20 * Smoke sensors triggering an alarm system=20 =20 =20 =20 =20 Response time=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=20 The latency issue is important.=20 When a user (real human being) presses a light button the user expects=20 the light to turn on.=20 cRPLp proposes that nodes in the tree periodically advertises their=20 presence using DAOs.=20 The periodicity is a real beast:=20 Thanks to Trickle, the rate of updates in a (apparently) stable network is low. This is good since it leaves bandwidth for data.=20 But it is not good if existing routes to my lamp fail and I do not get=20 new routes to my lamp until it decides to send out a new DAO.=20 My user will (with a good reason) not tolerate waiting for minutes for=20 the light to turn on.=20 =20 I have met two arguments to counter this concern:=20 =20 A1: Well, your lamp can always send a DAO when it detects a problem.=20 My answer:=20 True, except that my lamp does not intend to send anything=20 so it will never experience any problems from its side of the network. = =20 A2: Well, you can increase the DAO rate to sub-second updates.=20 My answer:=20 Oh no. I get a very high degree of management traffic which=20 limits my available bandwidth, increases the risk of collisions and=20 even run the risk of violating EU legislation requiring me to only=20 transmit in less than 1% of the time:=20 http://focus.ti.com/lit/an/swra048/swra048.pdf = =20 868 - 868.6 MHz: <1%=20 =20 Reactiveness is hard to achieve via polling.=20 =20 =20 =20 If you agree that this seems to be critical issues please raise your=20 voice on the list.=20 =20 Going forward=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=20 =20 We need some reactive mechanism to reach lamps before the user decides=20 to sue our companies.=20 So is this possible? I think so.=20 Existing commercial (non-IP) solutions are capable of re-routing quickly = if they really have to.=20 =20 Let me try scoping the requirements to a potential solution:=20 (no different from the req. docs for home and building)=20 =20 * P2P routing in any direction independent of the tree.=20 =20 * On-demand P2P route discovery if requested by a real-time critical = app. Data collection apps may be able to just wait for the next DAO update.=20 =20 * Limited range of discovery mechanism: max 4 repeaters.=20 A TTL field may limit the scope of the repeaters.=20 =20 * Suboptimal routing and traffic bursts are accepted in exchange=20 for quick route repair. But only as an exception.=20 =20 =20 Just as an example, one existing home control technology uses a (source routing) variant of AODV for quick route repair.=20 Nothing comes for free. The price is flooding - but not just flooding: Managed flooding using a distributed algorithm running in all participating nodes.=20 The algorithm dampens the flooding in a time, volume and range = perspective.=20 Some similar mechanism could be built into RPL for quick route repair.=20 =20 =20 If anyone have alternative proposals, please bring it to the list.=20 Now is the time.=20 =20 =20 =20 Thanks,=20 Anders=20 ________________________________ _______________________________________________ Roll mailing list Roll@ietf.org =20 https://www.ietf.org/mailman/listinfo/roll = =20 _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll = =20 =20 ________________________________ =20 _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll =20 ------_=_NextPart_001_01CAC737.1D1642C2 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =0A= =0A= =0A= =0A= =0A= =0A=
=0A=
+1
=0A=
 
=0A=
Anders
=0A=

=0A=
=0A= Fra: roll-bounces@ietf.org p=E5 = vegne af Don Sturek
Sendt: fr 19-03-2010 03:41
Til: = 'Pascal Thubert (pthubert)'; robert.cragie@gridmerge.com
Cc: = 'ROLL WG'; Ted.Humpal@jci.com
Emne: Re: [Roll] P2P performance = with current RPL proposal

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

Hi Pascal,

=0A=

 

=0A=

I have to say I am skeptical of a = solution where destination devices advertise themselves as DAG roots and = sources join those DAGs.  It is not clear to me at network = formation how this is known and the number of destination devices and = potential source devices would indicate that too much routing = information would need to be retained to make such a solution make sense = economically.

=0A=

 

=0A=

From my experience with Smart Energy, = we seem resigned to creating relatively few DAGs (maybe only one) then = using source routing to reach devices lower in the DAG.  I would = doubt we would invest the time in forming multiple DAGs or trying to = optimize with multiple destination devices as DAG roots and devices = lower in the DAG joining multiple DAG depending on the destination = address of their packets.  Keep in mind we don’t have the = requirement right now for low latency P2P communication in Smart Energy = which I would maintain IS NOT supported in the current RPL = proposal.

=0A=

 

=0A=

I encourage you to look at some of the = alternative I-Ds to create a workable solution for P2P = communication.  If you believe that low latency P2P communication = is currently supported, I would encourage you to take some of the = requirements from the Building Controls or Home Automation requirements = and show how this works with RPL today (particularly showing the memory = storage requirements on the individual devices in the DAG).  I = think you will quickly conclude there is a problem with respect to P2P = routing.

=0A=

 

=0A=

Don

=0A=

 

=0A=

 

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

From: roll-bounces@ietf.org = [mailto:roll-bounces@ietf.org] On Behalf Of Pascal Thubert = (pthubert)
Sent: Thursday, March 18, 2010 7:23 = PM
To: robert.cragie@gridmerge.com
Cc: ROLL WG; = Ted.Humpal@jci.com
Subject: Re: [Roll] P2P performance with = current RPL proposal

=0A=

 

=0A=

Hi Robert :

=0A=

 

=0A=

At least from a distance, the proposed = mechanism emulates AODV, with the DIO as RREQ and the DAO as RREP. So if = we decide to dig along those lines, we’ll certainly appreciate = help from MANET experts. I’d say that if you already have RPL for = P2MP and MP2P, the proposed extension are probably simpler to add than = doing AODV from scratch.

=0A=

 

=0A=

For the setup, the major differences = are that we build a DAG and that we can indicate multiple targets. If = you look at it, the DAG capability is a MUST for RPL, and I have not = seen that this MUST goes away for P2P flows. The multiple targets is = something that appears in a number of use cases and it seems more = economical to build a single DAG for multiple targets when = possible.

=0A=

 

=0A=

For the maintenance, the major = differences are that we have the DAG as first line of defense, and the = RPL detection to stimulate the local repair.

=0A=

 

=0A=

About your questions:

=0A=

 

=0A=

The DODAG root is the one that spawns = the DAG. The targets can reach the root because the root advertises = itself in the DIO. The idea is that the root ID is the address that the = targets need to talk to. If needed, the root can also advertise a prefix = that it can reach and that the targets need to reach too.

=0A=

 

=0A=

All the intermediate nodes that are = confirmed by the DAO need to retain at least info about the DAG. That = enables the targets to reach the root. The flooding should cost about = the same as that of AODV but the RPL way will require more states in the = nodes on the way if the OF requires a DAG.

=0A=

 

=0A=

The way back (down) can be stateful of = stateless, depending on which DAO we’re using. With fully stateful = DAO, we are really in AODV-land. With stateless, we could drift into = DSR-land for that direction. Which limits we place to keep it simple = will be determined by the resolution of issue #26 I = guess…

=0A=

 

=0A=

And please, no apologize or on one will = dare post anything anymore. Your questions are fully relevant and at the = core of the discussion.

=0A=

 

=0A=

I hope we can talk in Anaheim for = sure,

=0A=

 

=0A=
=0A=

Pascal

=0A=

 

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

From: Robert Cragie = [mailto:robert.cragie@gridmerge.com]
Sent: Monday, March 15, = 2010 11:27 AM
To: Pascal Thubert (pthubert)
Cc: Ted.Humpal@jci.com; ROLL = WG
Subject: Re: [Roll] P2P performance with current RPL = proposal

=0A=

 

=0A=

Hi Pascal,

So in your slideware T can end up talking to = R (DODAG root) through the DODAG. So are you proposing that all = potential targets can act as a DODAG root? And therefore all = intermediates have to retain DIO propagation support for that DODAG as = well? This may work for limited P2P but seems less efficient than simple = distance vector flooding RREQ/RREP like AODV or DYMO for generic P2P. = What about R to T (or anyone else for that matter)? Do we source route, = maintain state, some undefined hybrid of the two?

I apologise if = some of these questions have been answered in detail in earlier = reflector posts but I have only recently started to concentrate my = efforts on RPL and have 82 pages to wade through :-). I look forward to = a productive session in Anaheim.

Robert

=0A=
=0A=

Robert Cragie (Pacific Gas & = Electric)

=0A=

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

=0A=



Pascal Thubert (pthubert) = wrote:

=0A=

HI Robert :

=0A=

 

=0A=

I respectfully have to = disagree.

=0A=

 

=0A=

My understanding is that we are = considering a limited set of P2P pairs, for which the specific path that = we need to create might have to obey specific constraints.

=0A=

So it makes sense to use an on-demand = technique, probably inspired by the MANET Reactive = protocols.

=0A=

 

=0A=

As it goes, those protocols usually use = flooding for a node to locate another. Forking a DAG is just another = flooding. It does not take a lot of addition to the existing DIO for a = root to use RPL to build a DAG that contains one or multiple Targets as = leaves, under a set of constraints expressed as an objective function. = Please find attached a slideware that illustrates that.

=0A=

 

=0A=
=0A=

Pascal

=0A=

 

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

From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] = On Behalf Of Robert Cragie
Sent: Thursday, March 11, = 2010 2:43 PM
To: Ted.Humpal@jci.com
Cc: = ROLL WG
Subject: Re: [Roll] P2P performance with current RPL = proposal

=0A=

 

=0A=

I agree with Ted's comments below. Creating a DODAG for every = reachable node as a root seems a very inefficient approach compared to = alternative routing algorithms. I am concerned that RPL does not = actually meet the original requirements in = I-D.ietf-roll-building-routing-reqs, I-D.ietf-roll-home-routing-reqs, = RFC5673 and RFC5548. The traffic pattern requirement for a sink node = features prominently in only two of those documents. Even in this case, = as Ted points out, communication is likely to be bidirectional (e.g. = end-to-end acks.) therefore the DODAG approach is fundamentally = asymmetric, especially if no intermediate storage is allowed for = destination routes and source routing has to be used.

Also, RPL = seems highly complex for what are constrained nodes in terms of memory = as well as power and bandwidth. The RPL draft as it stands is 82 pages = long and that doesn't include text about the objective = function.

Robert

=0A=
=0A=

Robert Cragie (Pacific Gas & = Electric)

=0A=

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

=0A=



Ted.Humpal@jci.com wrote: =

=0A=


A concern also will be how much overhead = (memory space) will be required for a DODAG Root? =

and based on the first question how many = DODAG roots a lamp may need to be a member of? =

For example in lighting  a single lamp = may be a root for a single switch (1 DODAG root),  this lamp / = luminaire may also
be a member of another group - -  which could be all = lights on the floor (2nd DODAG root), and a third group
of all the lights in the building. =  There can be many more speciality groups associated based on the = building configuration.
Consider also during the installation time - how these DODAG = roots will be configured?  Must I commission each = device
to tell it which DODAG = it must use for its Object Function?  How easy will this be to = change and add in a new DODAG root =
for the end user if the lighting group = changes??

With respect to Jerry Martocci's - commercial building = requirements - every device may need to communicate to any = or
all of the end devices. =  If each device must establish a DODAG for the other 499 devices in = a 500 node network - How much memory =
space will this require for each end device to maintain? =  

Keep in mind that the = end devices are very limited processor and memory wise.

Not to mention all of = the network maintenance messages that would need to be transmitted to = maintain all of these DODAGs. =

Consider the reconvergence time when one = device is turned off and it was in the middle of the majority of the = 100+ DODAGS?

In many lighting and building application an application = acknowledgement - must be returned {Back down the DODAG} so . . . the =
requirement is not just = getting to the Root - a return path must also be maintained and have a =  low latency path.

Ted Humpal



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

From:

=0A=

Kris Pister <pister@eecs.berkeley.edu>=

=0A=

To:

=0A=

Anders Brandt <abr@sdesigns.dk> =

=0A=

Cc:

=0A=

ROLL WG <roll@ietf.org> =

=0A=

Date:

=0A=

03/08/2010 01:45 PM

=0A=

Subject:

=0A=

Re: [Roll] P2P performance with current RPL = proposal

=0A=

 

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




Anders - if we take JP's suggestion to make The = Lamp a DODAG root, and take Phoebus' recommendation that we use path = diversity to improve end-to-end reliability, do you see a chance of = success?
In my experience, with diverse paths and order-minutes = updates you get extremely high reliability.

I have no aversion to = TTL-limited floods as a part of a solution either.  I'm open to = ideas on how to bring those in as (presumably infrequently used) = options.

ksjp

Anders Brandt wrote:
Hello
 
I would like = to probe the temperature of the WG on using DAOs to
support P2P.
  =
The building and home application spaces (and maybe others) = have
a few clearly defined = requirements.
It is not = obvious to me how the current RPL proposal (cRPLp) can
satisfy those requirements: =
 
 
In both cases it is the worst case scenario = that hurts:
 
  =
P2P routing inside the PAN =
=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
cRPLp has no = way of routing inside the PAN if you need more than
one repeater. cRPLp has to go all the way to the top = (maybe 4 hops up)
and down = again (maybe 4 hops down) to get just 2 hops to the side.
 
The consequence is high latency and high = levels of background noise
for nodes just outside the direct radio = range.
At the same time the risk of = meeting a failing link is 4 times higher =3D> =
latency may be much more than 4 times larger.
 
Latency may sound like a minor issue but it = actually translates directly
into lower battery lifetime. In the = above (very realistic) example,
the battery = lifetime is reduced to 25% of what it should be. =
 
We have lots of battery devices sending into the = network:
* PIR sensors turning on = lights
* Door locks sending = alarms
* Door/window sensors starting = chimes
* Smoke sensors triggering an alarm = system
  =
 
 
  =
Response time
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =
The latency issue is important. =
When a user (real human being) presses a light button the user = expects
the light to turn on.
cRPLp proposes that nodes in the tree periodically = advertises their
presence = using DAOs.
The = periodicity is a real beast:
Thanks to = Trickle, the rate of updates in a (apparently) stable network
is low. = This is good since it leaves bandwidth for data. =
But it is not good if existing routes to my lamp fail and I do = not get
new routes to my lamp until it = decides to send out a new DAO.
My user will = (with a good reason) not tolerate waiting for minutes for
the light to turn on.
  =
I have met two arguments to counter this concern:
 
A1: Well, your lamp can always send a DAO = when it detects a problem.
  My = answer:
  True, except that my lamp = does not intend to send anything
  so it = will never experience any problems from its side of the = network.
 
A2: Well, you = can increase the DAO rate to sub-second updates. =
  My answer:
  = Oh no. I get a = very high degree of management traffic which =
  limits my available bandwidth, increases the risk of = collisions and
  even = run the risk of violating EU legislation requiring me to = only
  transmit in less than 1% of = the time:
  http://focus.ti.com/lit/an/swra048/swra048.pdf
 868 - 868.6 MHz: <1% =
 
  Reactiveness is hard to achieve via = polling.
 
 
  =
If you agree that this seems to be critical issues please = raise your
voice on the list.
 
Going forward =
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =
 
We need some reactive mechanism to reach lamps before = the user decides
to sue our = companies.
So is this possible? I think = so.

Existing commercial (non-IP) = solutions are capable of re-routing quickly =
if they really have to. =
 
Let me try scoping the requirements to a potential = solution:
(no different from the req. docs = for home and building)
  =
* P2P routing in any direction independent of the = tree.
 
* On-demand = P2P route discovery if requested by a real-time critical = app.
 Data collection apps may be able to just wait for the next = DAO update.
 
* Limited = range of discovery mechanism: max 4 repeaters. =
  A TTL field may limit the scope of the = repeaters.
 
* Suboptimal = routing and traffic bursts are accepted in exchange
  for quick route repair. But only as an = exception.
 
 
Just as an = example, one existing home control technology uses a
(source routing) = variant of AODV for quick route repair. =
Nothing comes for free. The price is flooding - but not just = flooding:
Managed flooding using a distributed algorithm running in = all
participating nodes.
The algorithm = dampens the flooding in a time, volume and range perspective. =
Some similar mechanism could be built into = RPL for quick route repair.
  =
 
If anyone have alternative proposals, please bring it = to the list.
Now is the = time.
 
  =
 
Thanks,
  = Anders

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


_______________________________________________
Roll = mailing list
Roll@ietf.org
https://www.ietf.org/mailman/listinfo/roll<= SPAN style=3D"FONT-FAMILY: 'Courier New'; FONT-SIZE: 7.5pt" = lang=3DFR>
 _______________________________________________
Roll mailing list
Roll@ietf.org
https://www.ietf.org/mailman/listinfo/roll



 
=0A=
=0A=

=0A=
=0A=

 
_______________________________________________
Roll mailing list
Roll@ietf.org
https://www.ietf.org/=
mailman/listinfo/roll
  =
------_=_NextPart_001_01CAC737.1D1642C2-- From Ruben.Salazar@landisgyr.com Fri Mar 19 07:14: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 1D9753A6A89 for ; Fri, 19 Mar 2010 07:14:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.868 X-Spam-Level: X-Spam-Status: No, score=-0.868 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, HTML_MESSAGE=0.001, J_CHICKENPOX_63=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HryFDwYAI9K1 for ; Fri, 19 Mar 2010 07:13:42 -0700 (PDT) Received: from mta1.cellnet.com (mta1.cellnet.com [66.173.18.47]) by core3.amsl.com (Postfix) with ESMTP id 7351A3A6A3C for ; Fri, 19 Mar 2010 07:13:41 -0700 (PDT) X-ASG-Debug-ID: 1269008030-7b71002d0004-BCmCR7 X-Barracuda-URL: http://10.3.2.11:8000/cgi-bin/mark.cgi Received: from livemail.cellnethunt.com (localhost [127.0.0.1]) by mta1.cellnet.com (Spam Firewall) with ESMTP id 4A1F3FDC46 for ; Fri, 19 Mar 2010 09:13:52 -0500 (CDT) Received: from livemail.cellnethunt.com (usatlsv15.am.bm.net [10.1.130.15]) by mta1.cellnet.com with ESMTP id gBeItHuMAcAntAwA for ; Fri, 19 Mar 2010 09:13:52 -0500 (CDT) X-ASG-Whitelist: Sender X-ASG-Whitelist: Client Received: from livemail.cellnethunt.com ([10.1.130.105]) by livemail.cellnethunt.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 19 Mar 2010 10:13:49 -0400 Received: from mail pickup service by livemail.cellnethunt.com with Microsoft SMTPSVC; Fri, 19 Mar 2010 10:13:49 -0400 Content-Transfer-Encoding: 7bit Importance: normal Priority: normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.4325 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CAC76E.64B0BB9D" X-ASG-Orig-Subj: RE: [Roll] P2P performance with current RPL proposal Date: Fri, 19 Mar 2010 10:13:47 -0400 Message-ID: <09D9C0631368C244941E610D99FEA71001ED25C7@usatlsv105.am.bm.net> In-Reply-To: <6D9687E95918C04A8B30A7D6DA805A3E01AD45C5@zensys17.zensys.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] P2P performance with current RPL proposal Thread-Index: AcrEbU1tfn0308v7QGeWK3YmnqapOAClmO0QAAIVugAACsDrwwANupow References: <6D9687E95918C04A8B30A7D6DA805A3E01429F5F@zensys17.zensys.local><4B9553B8.6010001@eecs.berkeley.edu> <4B98F374.4030301@gridmerge.com> <6A2A459175DABE4BB11DE2026AA50A5D0170DFA9@XMB-AMS-107.cisco.com> <4B9E7BE8.9060109@gridmerge.com><6A2A459175DABE4BB11DE2026AA50A5D01792E48@XMB-AMS-107.cisco.com><02c901cac70d$ac1c7990$04556cb0$@sturek@att.net> <6D9687E95918C04A8B30A7D6DA805A3E01AD45C5@zensys17.zensys.local> From: "Salazar, Ruben" To: "Anders Brandt" , , "Pascal Thubert \(pthubert\)" , X-OriginalArrivalTime: 19 Mar 2010 14:13:49.0780 (UTC) FILETIME=[6590D140:01CAC76E] X-Barracuda-Connect: usatlsv15.am.bm.net[10.1.130.15] X-Barracuda-Start-Time: 1269008032 X-Barracuda-Virus-Scanned: by Barracuda Spam Firewall at cellnet.com Cc: ROLL WG , Ted.Humpal@jci.com Subject: Re: [Roll] P2P performance with current RPL proposal X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Mar 2010 14:14:00 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CAC76E.64B0BB9D Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I would correct Anders on one point:=20 We DO have requirements for low latency P2P in the smart grid in the = USA. The Distribution system (at least) counts on it already today. Regards =20 Ruben Salazar, PhD Director of Research and Technology Landys+Gyr EMS Office: 678 258 3165 Cellular: 678 438 0063 ruben.salazar@landysgyr.com www.landisgyr.com manage energy better =20 =20 From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of = Anders Brandt Sent: Friday, March 19, 2010 3:38 AM To: d.sturek@att.net; Pascal Thubert (pthubert); = robert.cragie@gridmerge.com Cc: ROLL WG; Ted.Humpal@jci.com Subject: Re: [Roll] P2P performance with current RPL proposal =20 +1 =20 Anders =20 Ruben Salazar Director of Technology Landis+Gyr Energy Management Solutions Office: +1 678 258 3165 Fax: +1 678 258 1550 Ruben.Salazar@landisgyr.com www.landisgyr.com manage energy better ________________________________ Fra: roll-bounces@ietf.org p=E5 vegne af Don Sturek Sendt: fr 19-03-2010 03:41 Til: 'Pascal Thubert (pthubert)'; robert.cragie@gridmerge.com Cc: 'ROLL WG'; Ted.Humpal@jci.com Emne: Re: [Roll] P2P performance with current RPL proposal Hi Pascal, =20 I have to say I am skeptical of a solution where destination devices = advertise themselves as DAG roots and sources join those DAGs. It is = not clear to me at network formation how this is known and the number of = destination devices and potential source devices would indicate that too = much routing information would need to be retained to make such a = solution make sense economically. =20 >From my experience with Smart Energy, we seem resigned to creating = relatively few DAGs (maybe only one) then using source routing to reach = devices lower in the DAG. I would doubt we would invest the time in = forming multiple DAGs or trying to optimize with multiple destination = devices as DAG roots and devices lower in the DAG joining multiple DAG = depending on the destination address of their packets. Keep in mind we = don't have the requirement right now for low latency P2P communication = in Smart Energy which I would maintain IS NOT supported in the current = RPL proposal. =20 I encourage you to look at some of the alternative I-Ds to create a = workable solution for P2P communication. If you believe that low = latency P2P communication is currently supported, I would encourage you = to take some of the requirements from the Building Controls or Home = Automation requirements and show how this works with RPL today = (particularly showing the memory storage requirements on the individual = devices in the DAG). I think you will quickly conclude there is a = problem with respect to P2P routing. =20 Don =20 =20 From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of = Pascal Thubert (pthubert) Sent: Thursday, March 18, 2010 7:23 PM To: robert.cragie@gridmerge.com Cc: ROLL WG; Ted.Humpal@jci.com Subject: Re: [Roll] P2P performance with current RPL proposal =20 Hi Robert : =20 At least from a distance, the proposed mechanism emulates AODV, with the = DIO as RREQ and the DAO as RREP. So if we decide to dig along those = lines, we'll certainly appreciate help from MANET experts. I'd say that = if you already have RPL for P2MP and MP2P, the proposed extension are = probably simpler to add than doing AODV from scratch. =20 For the setup, the major differences are that we build a DAG and that we = can indicate multiple targets. If you look at it, the DAG capability is = a MUST for RPL, and I have not seen that this MUST goes away for P2P = flows. The multiple targets is something that appears in a number of use = cases and it seems more economical to build a single DAG for multiple = targets when possible. =20 For the maintenance, the major differences are that we have the DAG as = first line of defense, and the RPL detection to stimulate the local = repair. =20 About your questions: =20 The DODAG root is the one that spawns the DAG. The targets can reach the = root because the root advertises itself in the DIO. The idea is that the = root ID is the address that the targets need to talk to. If needed, the = root can also advertise a prefix that it can reach and that the targets = need to reach too. =20 All the intermediate nodes that are confirmed by the DAO need to retain = at least info about the DAG. That enables the targets to reach the root. = The flooding should cost about the same as that of AODV but the RPL way = will require more states in the nodes on the way if the OF requires a = DAG. =20 The way back (down) can be stateful of stateless, depending on which DAO = we're using. With fully stateful DAO, we are really in AODV-land. With = stateless, we could drift into DSR-land for that direction. Which limits = we place to keep it simple will be determined by the resolution of issue = #26 I guess... =20 And please, no apologize or on one will dare post anything anymore. Your = questions are fully relevant and at the core of the discussion. =20 I hope we can talk in Anaheim for sure, =20 Pascal =20 From: Robert Cragie [mailto:robert.cragie@gridmerge.com]=20 Sent: Monday, March 15, 2010 11:27 AM To: Pascal Thubert (pthubert) Cc: Ted.Humpal@jci.com; ROLL WG Subject: Re: [Roll] P2P performance with current RPL proposal =20 Hi Pascal, So in your slideware T can end up talking to R (DODAG root) through the = DODAG. So are you proposing that all potential targets can act as a = DODAG root? And therefore all intermediates have to retain DIO = propagation support for that DODAG as well? This may work for limited = P2P but seems less efficient than simple distance vector flooding = RREQ/RREP like AODV or DYMO for generic P2P. What about R to T (or = anyone else for that matter)? Do we source route, maintain state, some = undefined hybrid of the two? I apologise if some of these questions have been answered in detail in = earlier reflector posts but I have only recently started to concentrate = my efforts on RPL and have 82 pages to wade through :-). I look forward = to a productive session in Anaheim. Robert Robert Cragie (Pacific Gas & Electric) Gridmerge Ltd. 89 Greenfield Crescent, Wakefield, WF4 4WA, UK +44 (0) 1924 910888 http://www.gridmerge.com =20 Pascal Thubert (pthubert) wrote:=20 HI Robert : =20 I respectfully have to disagree. =20 My understanding is that we are considering a limited set of P2P pairs, = for which the specific path that we need to create might have to obey = specific constraints.=20 So it makes sense to use an on-demand technique, probably inspired by = the MANET Reactive protocols. =20 As it goes, those protocols usually use flooding for a node to locate = another. Forking a DAG is just another flooding. It does not take a lot = of addition to the existing DIO for a root to use RPL to build a DAG = that contains one or multiple Targets as leaves, under a set of = constraints expressed as an objective function. Please find attached a = slideware that illustrates that. =20 Pascal =20 From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of = Robert Cragie Sent: Thursday, March 11, 2010 2:43 PM To: Ted.Humpal@jci.com Cc: ROLL WG Subject: Re: [Roll] P2P performance with current RPL proposal =20 I agree with Ted's comments below. Creating a DODAG for every reachable = node as a root seems a very inefficient approach compared to alternative = routing algorithms. I am concerned that RPL does not actually meet the = original requirements in I-D.ietf-roll-building-routing-reqs, = I-D.ietf-roll-home-routing-reqs, RFC5673 and RFC5548. The traffic = pattern requirement for a sink node features prominently in only two of = those documents. Even in this case, as Ted points out, communication is = likely to be bidirectional (e.g. end-to-end acks.) therefore the DODAG = approach is fundamentally asymmetric, especially if no intermediate = storage is allowed for destination routes and source routing has to be = used. Also, RPL seems highly complex for what are constrained nodes in terms = of memory as well as power and bandwidth. The RPL draft as it stands is = 82 pages long and that doesn't include text about the objective = function. Robert Robert Cragie (Pacific Gas & Electric) Gridmerge Ltd. 89 Greenfield Crescent, Wakefield, WF4 4WA, UK +44 (0) 1924 910888 http://www.gridmerge.com =20 Ted.Humpal@jci.com wrote:=20 A concern also will be how much overhead (memory space) will be required = for a DODAG Root?=20 and based on the first question how many DODAG roots a lamp may need to = be a member of?=20 For example in lighting a single lamp may be a root for a single switch = (1 DODAG root), this lamp / luminaire may also=20 be a member of another group - - which could be all lights on the floor = (2nd DODAG root), and a third group=20 of all the lights in the building. There can be many more speciality = groups associated based on the building configuration.=20 Consider also during the installation time - how these DODAG roots will = be configured? Must I commission each device=20 to tell it which DODAG it must use for its Object Function? How easy = will this be to change and add in a new DODAG root=20 for the end user if the lighting group changes??=20 With respect to Jerry Martocci's - commercial building requirements - = every device may need to communicate to any or=20 all of the end devices. If each device must establish a DODAG for the = other 499 devices in a 500 node network - How much memory=20 space will this require for each end device to maintain? =20 Keep in mind that the end devices are very limited processor and memory = wise.=20 Not to mention all of the network maintenance messages that would need = to be transmitted to maintain all of these DODAGs.=20 Consider the reconvergence time when one device is turned off and it was = in the middle of the majority of the 100+ DODAGS?=20 In many lighting and building application an application acknowledgement = - must be returned {Back down the DODAG} so . . . the=20 requirement is not just getting to the Root - a return path must also be = maintained and have a low latency path.=20 Ted Humpal=20 From:=20 Kris Pister = =20 To:=20 Anders Brandt =20 Cc:=20 ROLL WG =20 Date:=20 03/08/2010 01:45 PM=20 Subject:=20 Re: [Roll] P2P performance with current RPL proposal =20 ________________________________ Anders - if we take JP's suggestion to make The Lamp a DODAG root, and = take Phoebus' recommendation that we use path diversity to improve = end-to-end reliability, do you see a chance of success? In my experience, with diverse paths and order-minutes updates you get = extremely high reliability. I have no aversion to TTL-limited floods as a part of a solution either. = I'm open to ideas on how to bring those in as (presumably infrequently = used) options. ksjp Anders Brandt wrote:=20 Hello=20 =20 I would like to probe the temperature of the WG on using DAOs to=20 support P2P.=20 =20 The building and home application spaces (and maybe others) have=20 a few clearly defined requirements.=20 It is not obvious to me how the current RPL proposal (cRPLp) can=20 satisfy those requirements:=20 =20 =20 In both cases it is the worst case scenario that hurts:=20 =20 =20 P2P routing inside the PAN=20 =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=20 cRPLp has no way of routing inside the PAN if you need more than=20 one repeater. cRPLp has to go all the way to the top (maybe 4 hops up)=20 and down again (maybe 4 hops down) to get just 2 hops to the side.=20 =20 The consequence is high latency and high levels of background noise for nodes just outside the direct radio range.=20 At the same time the risk of meeting a failing link is 4 times higher = =3D>=20 latency may be much more than 4 times larger.=20 =20 Latency may sound like a minor issue but it actually translates directly into lower battery lifetime. In the above (very realistic) example,=20 the battery lifetime is reduced to 25% of what it should be.=20 =20 We have lots of battery devices sending into the network:=20 * PIR sensors turning on lights=20 * Door locks sending alarms=20 * Door/window sensors starting chimes=20 * Smoke sensors triggering an alarm system=20 =20 =20 =20 =20 Response time=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=20 The latency issue is important.=20 When a user (real human being) presses a light button the user expects=20 the light to turn on.=20 cRPLp proposes that nodes in the tree periodically advertises their=20 presence using DAOs.=20 The periodicity is a real beast:=20 Thanks to Trickle, the rate of updates in a (apparently) stable network is low. This is good since it leaves bandwidth for data.=20 But it is not good if existing routes to my lamp fail and I do not get=20 new routes to my lamp until it decides to send out a new DAO.=20 My user will (with a good reason) not tolerate waiting for minutes for=20 the light to turn on.=20 =20 I have met two arguments to counter this concern:=20 =20 A1: Well, your lamp can always send a DAO when it detects a problem.=20 My answer:=20 True, except that my lamp does not intend to send anything=20 so it will never experience any problems from its side of the network. = =20 A2: Well, you can increase the DAO rate to sub-second updates.=20 My answer:=20 Oh no. I get a very high degree of management traffic which=20 limits my available bandwidth, increases the risk of collisions and=20 even run the risk of violating EU legislation requiring me to only=20 transmit in less than 1% of the time:=20 http://focus.ti.com/lit/an/swra048/swra048.pdf = =20 868 - 868.6 MHz: <1%=20 =20 Reactiveness is hard to achieve via polling.=20 =20 =20 =20 If you agree that this seems to be critical issues please raise your=20 voice on the list.=20 =20 Going forward=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=20 =20 We need some reactive mechanism to reach lamps before the user decides=20 to sue our companies.=20 So is this possible? I think so.=20 Existing commercial (non-IP) solutions are capable of re-routing quickly = if they really have to.=20 =20 Let me try scoping the requirements to a potential solution:=20 (no different from the req. docs for home and building)=20 =20 * P2P routing in any direction independent of the tree.=20 =20 * On-demand P2P route discovery if requested by a real-time critical = app. Data collection apps may be able to just wait for the next DAO update.=20 =20 * Limited range of discovery mechanism: max 4 repeaters.=20 A TTL field may limit the scope of the repeaters.=20 =20 * Suboptimal routing and traffic bursts are accepted in exchange=20 for quick route repair. But only as an exception.=20 =20 =20 Just as an example, one existing home control technology uses a (source routing) variant of AODV for quick route repair.=20 Nothing comes for free. The price is flooding - but not just flooding: Managed flooding using a distributed algorithm running in all participating nodes.=20 The algorithm dampens the flooding in a time, volume and range = perspective.=20 Some similar mechanism could be built into RPL for quick route repair.=20 =20 =20 If anyone have alternative proposals, please bring it to the list.=20 Now is the time.=20 =20 =20 =20 Thanks,=20 Anders=20 ________________________________ _______________________________________________ Roll mailing list Roll@ietf.org =20 https://www.ietf.org/mailman/listinfo/roll = =20 _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll = =20 =20 =20 =20 ________________________________ =20 =20 =20 _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll =20 ------_=_NextPart_001_01CAC76E.64B0BB9D Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

I would correct Anders on one point: =

We DO have requirements for low latency P2P in the smart = grid in the USA.

The Distribution system (at least) counts on it already = today.

Regards

 

Ruben Salazar, PhD

Director of Research  and = Technology

Landys+Gyr EMS

Office: 678 258 3165

Cellular: 678 438 0063

ruben.salazar@landysgyr.com

www.landisgyr.com=

manage energy better

 

 



Ruben Salazar
Director of Technology
Landis+Gyr
Energy Management Solutions
Office: +1 678 258 3165
Fax: +1 678 258 = 1550        
Ruben.Salazar@landisgyr.com
www.landisgyr.com =
manage energy = better

From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Anders Brandt
Sent: Friday, March 19, 2010 3:38 AM
To: d.sturek@att.net; Pascal Thubert (pthubert); robert.cragie@gridmerge.com
Cc: ROLL WG; Ted.Humpal@jci.com
Subject: Re: [Roll] P2P performance with current RPL = proposal

 

+1

 

Anders

 

Fra: roll-bounces@ietf.org på vegne af Don Sturek
Sendt: fr 19-03-2010 03:41
Til: 'Pascal Thubert (pthubert)'; robert.cragie@gridmerge.com
Cc: 'ROLL WG'; Ted.Humpal@jci.com
Emne: Re: [Roll] P2P performance with current RPL = proposal

Hi Pascal,

 

I have to say I am skeptical of a solution where = destination devices advertise themselves as DAG roots and sources join those = DAGs.  It is not clear to me at network formation how this is known and the number = of destination devices and potential source devices would indicate that too = much routing information would need to be retained to make such a solution = make sense economically.

 

From my experience with Smart Energy, we seem resigned to creating relatively few DAGs (maybe only one) then using source routing = to reach devices lower in the DAG.  I would doubt we would invest the = time in forming multiple DAGs or trying to optimize with multiple destination = devices as DAG roots and devices lower in the DAG joining multiple DAG depending = on the destination address of their packets.  Keep in mind we don’t = have the requirement right now for low latency P2P communication in Smart Energy = which I would maintain IS NOT supported in the current RPL = proposal.

 

I encourage you to look at some of the alternative I-Ds = to create a workable solution for P2P communication.  If you believe = that low latency P2P communication is currently supported, I would encourage you = to take some of the requirements from the Building Controls or Home Automation requirements and show how this works with RPL today (particularly = showing the memory storage requirements on the individual devices in the DAG).  = I think you will quickly conclude there is a problem with respect to P2P = routing.

 

Don

 

 

From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Pascal Thubert = (pthubert)
Sent: Thursday, March 18, 2010 7:23 PM
To: robert.cragie@gridmerge.com
Cc: ROLL WG; Ted.Humpal@jci.com
Subject: Re: [Roll] P2P performance with current RPL = proposal

 

Hi Robert :

 

At least from a distance, the proposed mechanism emulates = AODV, with the DIO as RREQ and the DAO as RREP. So if we decide to dig along = those lines, we’ll certainly appreciate help from MANET experts. = I’d say that if you already have RPL for P2MP and MP2P, the proposed extension are probably = simpler to add than doing AODV from scratch.

 

For the setup, the major differences are that we build a = DAG and that we can indicate multiple targets. If you look at it, the DAG = capability is a MUST for RPL, and I have not seen that this MUST goes away for P2P = flows. The multiple targets is something that appears in a number of use cases and = it seems more economical to build a single DAG for multiple targets when = possible.

 

For the maintenance, the major differences are that we = have the DAG as first line of defense, and the RPL detection to stimulate the = local repair.

 

About your questions:

 

The DODAG root is the one that spawns the DAG. The = targets can reach the root because the root advertises itself in the DIO. The idea = is that the root ID is the address that the targets need to talk to. If needed, = the root can also advertise a prefix that it can reach and that the targets = need to reach too.

 

All the intermediate nodes that are confirmed by the DAO = need to retain at least info about the DAG. That enables the targets to reach = the root. The flooding should cost about the same as that of AODV but the RPL way = will require more states in the nodes on the way if the OF requires a = DAG.

 

The way back (down) can be stateful of stateless, = depending on which DAO we’re using. With fully stateful DAO, we are really in = AODV-land. With stateless, we could drift into DSR-land for that direction. Which = limits we place to keep it simple will be determined by the resolution of issue = #26 I guess…

 

And please, no apologize or on one will dare post = anything anymore. Your questions are fully relevant and at the core of the = discussion.

 

I hope we can talk in Anaheim for = sure,

 

Pascal

 

From: Robert Cragie [mailto:robert.cragie@gridmerge.com]
Sent: Monday, March 15, 2010 11:27 AM
To: Pascal Thubert (pthubert)
Cc: Ted.Humpal@jci.com; ROLL WG
Subject: Re: [Roll] P2P performance with current RPL = proposal

 

Hi Pascal,

So in your slideware T can end up talking to R (DODAG root) through the = DODAG. So are you proposing that all potential targets can act as a DODAG root? = And therefore all intermediates have to retain DIO propagation support for = that DODAG as well? This may work for limited P2P but seems less efficient = than simple distance vector flooding RREQ/RREP like AODV or DYMO for generic = P2P. What about R to T (or anyone else for that matter)? Do we source route, maintain state, some undefined hybrid of the two?

I apologise if some of these questions have been answered in detail in = earlier reflector posts but I have only recently started to concentrate my = efforts on RPL and have 82 pages to wade through :-). I look forward to a = productive session in Anaheim.

Robert

Robert Cragie (Pacific Gas & = Electric)

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



Pascal Thubert (pthubert) wrote:

HI Robert :

 

I respectfully have to disagree.

 

My understanding is that we are considering a limited set = of P2P pairs, for which the specific path that we need to create might have to = obey specific constraints.

So it makes sense to use an on-demand technique, probably inspired by the MANET Reactive protocols.

 

As it goes, those protocols usually use flooding for a = node to locate another. Forking a DAG is just another flooding. It does not take = a lot of addition to the existing DIO for a root to use RPL to build a DAG = that contains one or multiple Targets as leaves, under a set of constraints expressed as an objective function. Please find attached a slideware = that illustrates that.

 

Pascal

 

From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] = On Behalf Of Robert Cragie
Sent: Thursday, March 11, 2010 2:43 PM
To: Ted.Humpal@jci.com
Cc: ROLL WG
Subject: Re: [Roll] P2P performance with current RPL = proposal

 

I agree with Ted's comments below. Creating a DODAG for every reachable = node as a root seems a very inefficient approach compared to alternative routing algorithms. I am concerned that RPL does not actually meet the original requirements in I-D.ietf-roll-building-routing-reqs, I-D.ietf-roll-home-routing-reqs, RFC5673 and RFC5548. The traffic = pattern requirement for a sink node features prominently in only two of those documents. Even in this case, as Ted points out, communication is likely = to be bidirectional (e.g. end-to-end acks.) therefore the DODAG approach is fundamentally asymmetric, especially if no intermediate storage is = allowed for destination routes and source routing has to be used.

Also, RPL seems highly complex for what are constrained nodes in terms = of memory as well as power and bandwidth. The RPL draft as it stands is 82 = pages long and that doesn't include text about the objective function.

Robert

Robert Cragie (Pacific Gas & = Electric)

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



Ted.Humpal@jci.com wrote: =


A concern also will be how much overhead (memory space) will be required = for a DODAG Root?

and based on the first question how many DODAG roots a lamp may need to be a = member of?

For example in lighting  a single lamp may be a root for a single = switch (1 DODAG root),  this lamp / luminaire may also =
be a member of another group - -  which could be all lights on the = floor (2nd DODAG root), and a third group
of all the lights in the building.  There can be many more speciality = groups associated based on the building configuration. =
Consider also during the installation time - how these DODAG roots will be = configured?  Must I commission each device
to tell it which DODAG it must use for its Object Function?  How easy = will this be to change and add in a new DODAG root =
for the end user if the lighting group changes??

With respect to Jerry Martocci's - commercial building requirements - every = device may need to communicate to any or
all of the end devices.  If each device must establish a DODAG for the = other 499 devices in a 500 node network - How much memory
space will this require for each end device to maintain?  

Keep in mind that the end devices are very limited processor and memory = wise.

Not to mention all of the network maintenance messages that would need to be transmitted to maintain all of these DODAGs.

Consider the reconvergence time when one device is turned off and it was in the = middle of the majority of the 100+ DODAGS?

In many lighting and building application an application acknowledgement - = must be returned {Back down the DODAG} so . . . the
requirement is not just getting to the Root - a return path must also be maintained = and have a  low latency path.

Ted Humpal


From:

Kris Pister <pister@eecs.berkeley.edu>=

To:

Anders Brandt <abr@sdesigns.dk> =

Cc:

ROLL WG <roll@ietf.org> =

Date:

03/08/2010 01:45 PM

Subject:

Re: [Roll] P2P performance with current RPL proposal

 




Anders - if we take JP's suggestion to make The Lamp a DODAG root, and = take Phoebus' recommendation that we use path diversity to improve end-to-end reliability, do you see a chance of success?
In my experience, with diverse paths and order-minutes updates you get extremely high reliability.

I have no aversion to TTL-limited floods as a part of a solution either.  I'm open to ideas on how to bring those in as (presumably = infrequently used) options.

ksjp

Anders Brandt wrote:
Hello
 
I = would like to probe the temperature of the WG on using DAOs to
support P2P.
 
The = building and home application spaces (and maybe others) have
a = few clearly defined requirements.
It = is not obvious to me how the current RPL proposal (cRPLp) can
satisfy those requirements:
 
 
In = both cases it is the worst case scenario that hurts:
 
 
P2P = routing inside the PAN
=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
cRPLp has no way of routing inside the PAN if you need more than
one = repeater. cRPLp has to go all the way to the top (maybe 4 hops up)
and = down again (maybe 4 hops down) to get just 2 hops to the side.
 
The consequence is high latency and high levels of background noise
for nodes just outside the direct radio range. =
At = the same time the risk of meeting a failing link is 4 times higher = =3D>
latency may be much more than 4 times larger.
 
Latency may sound like a minor issue but it actually translates directly
into lower battery lifetime. In the above (very realistic) = example,
the = battery lifetime is reduced to 25% of what it should be. =
 
We = have lots of battery devices sending into the network:
* = PIR sensors turning on lights
* = Door locks sending alarms
* = Door/window sensors starting chimes
* = Smoke sensors triggering an alarm system
 
 
 
 
Response time
=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D
The = latency issue is important.
When a user (real human being) presses a light button the user expects
the = light to turn on.
cRPLp proposes that nodes in the tree periodically advertises their
presence using DAOs.
The periodicity is a real beast:
Thanks to Trickle, the rate of updates in a (apparently) stable network
is low. This is good since it leaves bandwidth for data.
But = it is not good if existing routes to my lamp fail and I do not get
new = routes to my lamp until it decides to send out a new DAO. =
My = user will (with a good reason) not tolerate waiting for minutes for
the = light to turn on.
 
I = have met two arguments to counter this concern:
 
A1: = Well, your lamp can always send a DAO when it detects a problem.
  My answer:
  True, except that my lamp does not intend to send anything
  so it will never experience any problems from its side of the = network.
 
A2: = Well, you can increase the DAO rate to sub-second updates. =
  My answer:
  Oh no. I get a very high degree = of management traffic which
  limits my available bandwidth, increases the risk of collisions and
  even run the risk of violating EU legislation requiring me to = only
  transmit in less than 1% of the time:
  http://focus.ti.com/lit/an/= swra048/swra048.pdf
 868 - 868.6 MHz: <1%
 
  Reactiveness is hard to achieve via polling.
 
 
 
If = you agree that this seems to be critical issues please raise your
voice on the list.
 
Going forward
=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D
 
We = need some reactive mechanism to reach lamps before the user decides
to = sue our companies.
So = is this possible? I think so.

Existing commercial (non-IP) solutions are capable of re-routing = quickly
if = they really have to.
 
Let = me try scoping the requirements to a potential solution: =
(no = different from the req. docs for home and building)
 
* = P2P routing in any direction independent of the tree.
 
* = On-demand P2P route discovery if requested by a real-time critical app.
 Data collection apps may be able to just wait for the next DAO = update.
 
* = Limited range of discovery mechanism: max 4 repeaters. =
  A TTL field may limit the scope of the repeaters.
 
* = Suboptimal routing and traffic bursts are accepted in exchange
  for quick route repair. But only as an exception. =
 
 
Just as an example, one existing home control technology uses a
(source routing) variant of AODV for quick route repair.
Nothing comes for free. The price is flooding - but not just flooding:
Managed flooding using a distributed algorithm running in all
participating nodes.
The = algorithm dampens the flooding in a time, volume and range perspective. =
Some similar mechanism could be built into RPL for quick route repair.
 
 
If = anyone have alternative proposals, please bring it to the list.
Now = is the time.
 
 
 
Thanks,
  Anders


______________________________________________= _
Roll mailing = 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_01CAC76E.64B0BB9D-- From d.sturek@att.net Fri Mar 19 07:23: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 EB5B43A6A6A for ; Fri, 19 Mar 2010 07:23:42 -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=[AWL=-0.583, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, HTML_MESSAGE=0.001, J_CHICKENPOX_63=0.6, 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 x8kty+LpFBy1 for ; Fri, 19 Mar 2010 07:23:23 -0700 (PDT) Received: from smtp111.sbc.mail.mud.yahoo.com (smtp111.sbc.mail.mud.yahoo.com [68.142.198.207]) by core3.amsl.com (Postfix) with SMTP id 0DFED3A681A for ; Fri, 19 Mar 2010 07:23:23 -0700 (PDT) Received: (qmail 85267 invoked from network); 19 Mar 2010 14:23:35 -0000 Received: from Studio (d.sturek@69.226.30.134 with login) by smtp111.sbc.mail.mud.yahoo.com with SMTP; 19 Mar 2010 07:23:34 -0700 PDT X-Yahoo-SMTP: fvjol_aswBAraSJvMLe2r1XTzhBhbFxY8q8c3jo- X-YMail-OSG: qCH19TIVM1kNSZjVZB98iI4_cTNU2.bx.kjgmDWj6Mdj0IJomzGi7atGFUX0ya7MLM5zzo0PejXEZeV_R3f73bAhaI7umd_BzMF1AeYLokNfD0Fdh0QQSy9wQhI9nQqmGVIOoCqd7Fj_IV7Dqwcrvxb4X3PKOWvVU8vewrKAxxuBnbKIZvMvufcQIGn78mdRyaGmDbfvKcchkFFG2ouWXdxk1ysv4U2ZrkJJeumllRztWAzWEfOU1EnYUoKwkvbusLhn_etwcOItq0CTGq.O0xcEyeuTI7dca3b6aSlw7VPsbngmKZoq8Q-- X-Yahoo-Newman-Property: ymail-3 From: "Don Sturek" To: "'Salazar, Ruben'" , "'Anders Brandt'" , "'Pascal Thubert \(pthubert\)'" , References: <6D9687E95918C04A8B30A7D6DA805A3E01429F5F@zensys17.zensys.local><4B9553B8.6010001@eecs.berkeley.edu> <4B98F374.4030301@gridmerge.com> <6A2A459175DABE4BB11DE2026AA50A5D0170DFA9@XMB-AMS-107.cisco.com> <4B9E7BE8.9060109@gridmerge.com><6A2A459175DABE4BB11DE2026AA50A5D01792E48@XMB-AMS-107.cisco.com><02c901cac70d$ac1c7990$04556cb0$@sturek@att.net> <6D9687E95918C04A8B30A7D6DA805A3E01AD45C5@zensys17.zensys.local> <09D9C0631368C244941E610D99FEA71001ED25C7@usatlsv105.am.bm.net> In-Reply-To: <09D9C0631368C244941E610D99FEA71001ED25C7@usatlsv105.am.bm.net> Date: Fri, 19 Mar 2010 07:23:32 -0700 Message-ID: <007601cac76f$c18e0d90$44aa28b0$@sturek@att.net> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0077_01CAC735.152F3590" X-Mailer: Microsoft Office Outlook 12.0 thread-index: AcrEbU1tfn0308v7QGeWK3YmnqapOAClmO0QAAIVugAACsDrwwANupowAABdoFA= Content-Language: en-us Cc: 'ROLL WG' , Ted.Humpal@jci.com Subject: Re: [Roll] P2P performance with current RPL proposal 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, 19 Mar 2010 14:23:43 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0077_01CAC735.152F3590 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Ruben, =20 Yes, I was just speaking for the Home Area Network portion of the Smart Energy solution (where we schedule events on minute boundaries). If = ROLL is used as a mesh routing solution in the access side of the meter (towards = the utility) then there are low latency requirements. =20 Ruben: It might be worth reviewing the building controls and home = controls requirements in ROLL to see whether these fit the application you are thinking about. Don =20 =20 From: Salazar, Ruben [mailto:Ruben.Salazar@landisgyr.com]=20 Sent: Friday, March 19, 2010 7:14 AM To: Anders Brandt; d.sturek@att.net; Pascal Thubert (pthubert); robert.cragie@gridmerge.com Cc: ROLL WG; Ted.Humpal@jci.com Subject: RE: [Roll] P2P performance with current RPL proposal =20 I would correct Anders on one point:=20 We DO have requirements for low latency P2P in the smart grid in the = USA. The Distribution system (at least) counts on it already today. Regards =20 Ruben Salazar, PhD Director of Research and Technology Landys+Gyr EMS Office: 678 258 3165 Cellular: 678 438 0063 ruben.salazar@landysgyr.com www.landisgyr.com manage energy better =20 =20 =20 Ruben Salazar Director of Technology Landis+Gyr Energy Management Solutions Office: +1 678 258 3165 Fax: +1 678 258 1550 =20 Ruben.Salazar@landisgyr.com www.landisgyr.com =20 manage energy better From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Anders Brandt Sent: Friday, March 19, 2010 3:38 AM To: d.sturek@att.net; Pascal Thubert (pthubert); = robert.cragie@gridmerge.com Cc: ROLL WG; Ted.Humpal@jci.com Subject: Re: [Roll] P2P performance with current RPL proposal =20 +1 =20 Anders =20 _____ =20 Fra: roll-bounces@ietf.org p=E5 vegne af Don Sturek Sendt: fr 19-03-2010 03:41 Til: 'Pascal Thubert (pthubert)'; robert.cragie@gridmerge.com Cc: 'ROLL WG'; Ted.Humpal@jci.com Emne: Re: [Roll] P2P performance with current RPL proposal Hi Pascal, =20 I have to say I am skeptical of a solution where destination devices advertise themselves as DAG roots and sources join those DAGs. It is = not clear to me at network formation how this is known and the number of destination devices and potential source devices would indicate that too much routing information would need to be retained to make such a = solution make sense economically. =20 >From my experience with Smart Energy, we seem resigned to creating relatively few DAGs (maybe only one) then using source routing to reach devices lower in the DAG. I would doubt we would invest the time in = forming multiple DAGs or trying to optimize with multiple destination devices as = DAG roots and devices lower in the DAG joining multiple DAG depending on the destination address of their packets. Keep in mind we don=92t have the requirement right now for low latency P2P communication in Smart Energy which I would maintain IS NOT supported in the current RPL proposal. =20 I encourage you to look at some of the alternative I-Ds to create a = workable solution for P2P communication. If you believe that low latency P2P communication is currently supported, I would encourage you to take some = of the requirements from the Building Controls or Home Automation = requirements and show how this works with RPL today (particularly showing the memory storage requirements on the individual devices in the DAG). I think you will quickly conclude there is a problem with respect to P2P routing. =20 Don =20 =20 From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Pascal Thubert (pthubert) Sent: Thursday, March 18, 2010 7:23 PM To: robert.cragie@gridmerge.com Cc: ROLL WG; Ted.Humpal@jci.com Subject: Re: [Roll] P2P performance with current RPL proposal =20 Hi Robert : =20 At least from a distance, the proposed mechanism emulates AODV, with the = DIO as RREQ and the DAO as RREP. So if we decide to dig along those lines, = we=92ll certainly appreciate help from MANET experts. I=92d say that if you = already have RPL for P2MP and MP2P, the proposed extension are probably simpler = to add than doing AODV from scratch. =20 For the setup, the major differences are that we build a DAG and that we = can indicate multiple targets. If you look at it, the DAG capability is a = MUST for RPL, and I have not seen that this MUST goes away for P2P flows. The multiple targets is something that appears in a number of use cases and = it seems more economical to build a single DAG for multiple targets when possible. =20 For the maintenance, the major differences are that we have the DAG as = first line of defense, and the RPL detection to stimulate the local repair. =20 About your questions: =20 The DODAG root is the one that spawns the DAG. The targets can reach the root because the root advertises itself in the DIO. The idea is that the root ID is the address that the targets need to talk to. If needed, the = root can also advertise a prefix that it can reach and that the targets need = to reach too. =20 All the intermediate nodes that are confirmed by the DAO need to retain = at least info about the DAG. That enables the targets to reach the root. = The flooding should cost about the same as that of AODV but the RPL way will require more states in the nodes on the way if the OF requires a DAG. =20 The way back (down) can be stateful of stateless, depending on which DAO we=92re using. With fully stateful DAO, we are really in AODV-land. With stateless, we could drift into DSR-land for that direction. Which limits = we place to keep it simple will be determined by the resolution of issue = #26 I guess=85 =20 And please, no apologize or on one will dare post anything anymore. Your questions are fully relevant and at the core of the discussion. =20 I hope we can talk in Anaheim for sure, =20 Pascal =20 From: Robert Cragie [mailto:robert.cragie@gridmerge.com]=20 Sent: Monday, March 15, 2010 11:27 AM To: Pascal Thubert (pthubert) Cc: Ted.Humpal@jci.com; ROLL WG Subject: Re: [Roll] P2P performance with current RPL proposal =20 Hi Pascal, So in your slideware T can end up talking to R (DODAG root) through the DODAG. So are you proposing that all potential targets can act as a = DODAG root? And therefore all intermediates have to retain DIO propagation = support for that DODAG as well? This may work for limited P2P but seems less efficient than simple distance vector flooding RREQ/RREP like AODV or = DYMO for generic P2P. What about R to T (or anyone else for that matter)? Do = we source route, maintain state, some undefined hybrid of the two? I apologise if some of these questions have been answered in detail in earlier reflector posts but I have only recently started to concentrate = my efforts on RPL and have 82 pages to wade through :-). I look forward to = a productive session in Anaheim. Robert Robert Cragie (Pacific Gas & Electric) Gridmerge Ltd. 89 Greenfield Crescent, Wakefield, WF4 4WA, UK +44 (0) 1924 910888 http://www.gridmerge.com =20 Pascal Thubert (pthubert) wrote:=20 HI Robert : =20 I respectfully have to disagree. =20 My understanding is that we are considering a limited set of P2P pairs, = for which the specific path that we need to create might have to obey = specific constraints.=20 So it makes sense to use an on-demand technique, probably inspired by = the MANET Reactive protocols. =20 As it goes, those protocols usually use flooding for a node to locate another. Forking a DAG is just another flooding. It does not take a lot = of addition to the existing DIO for a root to use RPL to build a DAG that contains one or multiple Targets as leaves, under a set of constraints expressed as an objective function. Please find attached a slideware = that illustrates that. =20 Pascal =20 From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Robert Cragie Sent: Thursday, March 11, 2010 2:43 PM To: Ted.Humpal@jci.com Cc: ROLL WG Subject: Re: [Roll] P2P performance with current RPL proposal =20 I agree with Ted's comments below. Creating a DODAG for every reachable = node as a root seems a very inefficient approach compared to alternative = routing algorithms. I am concerned that RPL does not actually meet the original requirements in I-D.ietf-roll-building-routing-reqs, I-D.ietf-roll-home-routing-reqs, RFC5673 and RFC5548. The traffic = pattern requirement for a sink node features prominently in only two of those documents. Even in this case, as Ted points out, communication is likely = to be bidirectional (e.g. end-to-end acks.) therefore the DODAG approach is fundamentally asymmetric, especially if no intermediate storage is = allowed for destination routes and source routing has to be used. Also, RPL seems highly complex for what are constrained nodes in terms = of memory as well as power and bandwidth. The RPL draft as it stands is 82 pages long and that doesn't include text about the objective function. Robert Robert Cragie (Pacific Gas & Electric) Gridmerge Ltd. 89 Greenfield Crescent, Wakefield, WF4 4WA, UK +44 (0) 1924 910888 http://www.gridmerge.com =20 Ted.Humpal@jci.com wrote:=20 A concern also will be how much overhead (memory space) will be required = for a DODAG Root?=20 and based on the first question how many DODAG roots a lamp may need to = be a member of?=20 For example in lighting a single lamp may be a root for a single switch = (1 DODAG root), this lamp / luminaire may also=20 be a member of another group - - which could be all lights on the floor (2nd DODAG root), and a third group=20 of all the lights in the building. There can be many more speciality = groups associated based on the building configuration.=20 Consider also during the installation time - how these DODAG roots will = be configured? Must I commission each device=20 to tell it which DODAG it must use for its Object Function? How easy = will this be to change and add in a new DODAG root=20 for the end user if the lighting group changes??=20 With respect to Jerry Martocci's - commercial building requirements - = every device may need to communicate to any or=20 all of the end devices. If each device must establish a DODAG for the = other 499 devices in a 500 node network - How much memory=20 space will this require for each end device to maintain? =20 Keep in mind that the end devices are very limited processor and memory wise.=20 Not to mention all of the network maintenance messages that would need = to be transmitted to maintain all of these DODAGs.=20 Consider the reconvergence time when one device is turned off and it was = in the middle of the majority of the 100+ DODAGS?=20 In many lighting and building application an application acknowledgement = - must be returned {Back down the DODAG} so . . . the=20 requirement is not just getting to the Root - a return path must also be maintained and have a low latency path.=20 Ted Humpal=20 From:=20 Kris Pister = =20 To:=20 Anders Brandt =20 Cc:=20 ROLL WG =20 Date:=20 03/08/2010 01:45 PM=20 Subject:=20 Re: [Roll] P2P performance with current RPL proposal =20 _____ =20 Anders - if we take JP's suggestion to make The Lamp a DODAG root, and = take Phoebus' recommendation that we use path diversity to improve end-to-end reliability, do you see a chance of success? In my experience, with diverse paths and order-minutes updates you get extremely high reliability. I have no aversion to TTL-limited floods as a part of a solution either. I'm open to ideas on how to bring those in as (presumably infrequently = used) options. ksjp Anders Brandt wrote:=20 Hello=20 =20 I would like to probe the temperature of the WG on using DAOs to=20 support P2P.=20 =20 The building and home application spaces (and maybe others) have=20 a few clearly defined requirements.=20 It is not obvious to me how the current RPL proposal (cRPLp) can=20 satisfy those requirements:=20 =20 =20 In both cases it is the worst case scenario that hurts:=20 =20 =20 P2P routing inside the PAN=20 =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=20 cRPLp has no way of routing inside the PAN if you need more than=20 one repeater. cRPLp has to go all the way to the top (maybe 4 hops up)=20 and down again (maybe 4 hops down) to get just 2 hops to the side.=20 =20 The consequence is high latency and high levels of background noise for nodes just outside the direct radio range.=20 At the same time the risk of meeting a failing link is 4 times higher = =3D>=20 latency may be much more than 4 times larger.=20 =20 Latency may sound like a minor issue but it actually translates directly into lower battery lifetime. In the above (very realistic) example,=20 the battery lifetime is reduced to 25% of what it should be.=20 =20 We have lots of battery devices sending into the network:=20 * PIR sensors turning on lights=20 * Door locks sending alarms=20 * Door/window sensors starting chimes=20 * Smoke sensors triggering an alarm system=20 =20 =20 =20 =20 Response time=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=20 The latency issue is important.=20 When a user (real human being) presses a light button the user expects=20 the light to turn on.=20 cRPLp proposes that nodes in the tree periodically advertises their=20 presence using DAOs.=20 The periodicity is a real beast:=20 Thanks to Trickle, the rate of updates in a (apparently) stable network is low. This is good since it leaves bandwidth for data.=20 But it is not good if existing routes to my lamp fail and I do not get=20 new routes to my lamp until it decides to send out a new DAO.=20 My user will (with a good reason) not tolerate waiting for minutes for=20 the light to turn on.=20 =20 I have met two arguments to counter this concern:=20 =20 A1: Well, your lamp can always send a DAO when it detects a problem.=20 My answer:=20 True, except that my lamp does not intend to send anything=20 so it will never experience any problems from its side of the network. = =20 A2: Well, you can increase the DAO rate to sub-second updates.=20 My answer:=20 Oh no. I get a very high degree of management traffic which=20 limits my available bandwidth, increases the risk of collisions and=20 even run the risk of violating EU legislation requiring me to only=20 transmit in less than 1% of the time:=20 http://focus.ti.com/lit/an/swra048/swra048.pdf 868 - 868.6 MHz: <1%=20 =20 Reactiveness is hard to achieve via polling.=20 =20 =20 =20 If you agree that this seems to be critical issues please raise your=20 voice on the list.=20 =20 Going forward=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=20 =20 We need some reactive mechanism to reach lamps before the user decides=20 to sue our companies.=20 So is this possible? I think so.=20 Existing commercial (non-IP) solutions are capable of re-routing quickly = if they really have to.=20 =20 Let me try scoping the requirements to a potential solution:=20 (no different from the req. docs for home and building)=20 =20 * P2P routing in any direction independent of the tree.=20 =20 * On-demand P2P route discovery if requested by a real-time critical = app. Data collection apps may be able to just wait for the next DAO update.=20 =20 * Limited range of discovery mechanism: max 4 repeaters.=20 A TTL field may limit the scope of the repeaters.=20 =20 * Suboptimal routing and traffic bursts are accepted in exchange=20 for quick route repair. But only as an exception.=20 =20 =20 Just as an example, one existing home control technology uses a (source routing) variant of AODV for quick route repair.=20 Nothing comes for free. The price is flooding - but not just flooding: Managed flooding using a distributed algorithm running in all participating nodes.=20 The algorithm dampens the flooding in a time, volume and range = perspective.=20 Some similar mechanism could be built into RPL for quick route repair.=20 =20 =20 If anyone have alternative proposals, please bring it to the list.=20 Now is the time.=20 =20 =20 =20 Thanks,=20 Anders=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 =20 =20 =20 =20 _____ =20 =20 =20 =20 =20 =20 _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll =20 ------=_NextPart_000_0077_01CAC735.152F3590 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Ruben,

 

Yes, I was just speaking for the Home Area Network = portion of the Smart Energy solution (where we schedule events on minute = boundaries).=A0 If ROLL is used as a mesh routing solution in the access side of the meter (towards the utility) then there are low latency = requirements.

 

Ruben:=A0 It might be worth reviewing the building = controls and home controls requirements in ROLL to see whether these fit the = application you are thinking about.


Don

 

 

From: Salazar, Ruben [mailto:Ruben.Salazar@landisgyr.com]
Sent: Friday, March 19, 2010 7:14 AM
To: Anders Brandt; d.sturek@att.net; Pascal Thubert (pthubert); robert.cragie@gridmerge.com
Cc: ROLL WG; Ted.Humpal@jci.com
Subject: RE: [Roll] P2P performance with current RPL = proposal

 

I would correct Anders on one point: =

We DO have requirements for low latency P2P in the smart = grid in the USA.

The Distribution system (at least) counts on it already = today.

Regards

 

Ruben Salazar, PhD

Director of Research  and = Technology

Landys+Gyr EMS

Office: 678 258 3165

Cellular: 678 438 0063

ruben.salazar@landysgyr.com

www.landisgyr.com=

manage energy better

 

 

 

Ruben Salazar
Director of Technology
Landis+Gyr
Energy Management Solutions
Office: +1 678 258 3165
Fax: +1 678 258 1550        
Ruben.Salazar@landisgyr.com
www.landisgyr.com
manage energy better

From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Anders Brandt
Sent: Friday, March 19, 2010 3:38 AM
To: d.sturek@att.net; Pascal Thubert (pthubert); robert.cragie@gridmerge.com
Cc: ROLL WG; Ted.Humpal@jci.com
Subject: Re: [Roll] P2P performance with current RPL = proposal

 

+1

 

Anders

 

Fra: roll-bounces@ietf.org p=E5 vegne af Don Sturek
Sendt: fr 19-03-2010 03:41
Til: 'Pascal Thubert (pthubert)'; robert.cragie@gridmerge.com
Cc: 'ROLL WG'; Ted.Humpal@jci.com
Emne: Re: [Roll] P2P performance with current RPL = proposal

Hi Pascal,

 

I have to say I am skeptical of a solution where = destination devices advertise themselves as DAG roots and sources join those = DAGs.  It is not clear to me at network formation how this is known and the number = of destination devices and potential source devices would indicate that too = much routing information would need to be retained to make such a solution = make sense economically.

 

From my experience with Smart Energy, we seem resigned to creating relatively few DAGs (maybe only one) then using source routing = to reach devices lower in the DAG.  I would doubt we would invest the = time in forming multiple DAGs or trying to optimize with multiple destination = devices as DAG roots and devices lower in the DAG joining multiple DAG depending = on the destination address of their packets.  Keep in mind we don’t = have the requirement right now for low latency P2P communication in Smart Energy = which I would maintain IS NOT supported in the current RPL = proposal.

 

I encourage you to look at some of the alternative I-Ds = to create a workable solution for P2P communication.  If you believe = that low latency P2P communication is currently supported, I would encourage you = to take some of the requirements from the Building Controls or Home Automation requirements and show how this works with RPL today (particularly = showing the memory storage requirements on the individual devices in the DAG).  = I think you will quickly conclude there is a problem with respect to P2P = routing.

 

Don

 

 

From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Pascal Thubert = (pthubert)
Sent: Thursday, March 18, 2010 7:23 PM
To: robert.cragie@gridmerge.com
Cc: ROLL WG; Ted.Humpal@jci.com
Subject: Re: [Roll] P2P performance with current RPL = proposal

 

Hi Robert :

 

At least from a distance, the proposed mechanism emulates = AODV, with the DIO as RREQ and the DAO as RREP. So if we decide to dig along = those lines, we’ll certainly appreciate help from MANET experts. = I’d say that if you already have RPL for P2MP and MP2P, the proposed extension are probably = simpler to add than doing AODV from scratch.

 

For the setup, the major differences are that we build a = DAG and that we can indicate multiple targets. If you look at it, the DAG = capability is a MUST for RPL, and I have not seen that this MUST goes away for P2P = flows. The multiple targets is something that appears in a number of use cases and = it seems more economical to build a single DAG for multiple targets when = possible.

 

For the maintenance, the major differences are that we = have the DAG as first line of defense, and the RPL detection to stimulate the = local repair.

 

About your questions:

 

The DODAG root is the one that spawns the DAG. The = targets can reach the root because the root advertises itself in the DIO. The idea = is that the root ID is the address that the targets need to talk to. If needed, = the root can also advertise a prefix that it can reach and that the targets = need to reach too.

 

All the intermediate nodes that are confirmed by the DAO = need to retain at least info about the DAG. That enables the targets to reach = the root. The flooding should cost about the same as that of AODV but the RPL way = will require more states in the nodes on the way if the OF requires a = DAG.

 

The way back (down) can be stateful of stateless, = depending on which DAO we’re using. With fully stateful DAO, we are really in = AODV-land. With stateless, we could drift into DSR-land for that direction. Which = limits we place to keep it simple will be determined by the resolution of issue = #26 I guess…

 

And please, no apologize or on one will dare post = anything anymore. Your questions are fully relevant and at the core of the = discussion.

 

I hope we can talk in Anaheim for = sure,

 

Pascal

 

From: Robert Cragie [mailto:robert.cragie@gridmerge.com]
Sent: Monday, March 15, 2010 11:27 AM
To: Pascal Thubert (pthubert)
Cc: Ted.Humpal@jci.com; ROLL WG
Subject: Re: [Roll] P2P performance with current RPL = proposal

 

Hi Pascal,

So in your slideware T can end up talking to R (DODAG root) through the = DODAG. So are you proposing that all potential targets can act as a DODAG root? = And therefore all intermediates have to retain DIO propagation support for = that DODAG as well? This may work for limited P2P but seems less efficient = than simple distance vector flooding RREQ/RREP like AODV or DYMO for generic = P2P. What about R to T (or anyone else for that matter)? Do we source route, maintain state, some undefined hybrid of the two?

I apologise if some of these questions have been answered in detail in = earlier reflector posts but I have only recently started to concentrate my = efforts on RPL and have 82 pages to wade through :-). I look forward to a = productive session in Anaheim.

Robert

Robert Cragie (Pacific Gas & = Electric)

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



Pascal Thubert (pthubert) wrote:

HI Robert :

 

I respectfully have to disagree.

 

My understanding is that we are considering a limited set = of P2P pairs, for which the specific path that we need to create might have to = obey specific constraints.

So it makes sense to use an on-demand technique, probably inspired by the MANET Reactive protocols.

 

As it goes, those protocols usually use flooding for a = node to locate another. Forking a DAG is just another flooding. It does not take = a lot of addition to the existing DIO for a root to use RPL to build a DAG = that contains one or multiple Targets as leaves, under a set of constraints expressed as an objective function. Please find attached a slideware = that illustrates that.

 

Pascal

 

From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] = On Behalf Of Robert Cragie
Sent: Thursday, March 11, 2010 2:43 PM
To: Ted.Humpal@jci.com
Cc: ROLL WG
Subject: Re: [Roll] P2P performance with current RPL = proposal

 

I agree with Ted's comments below. Creating a DODAG for every reachable = node as a root seems a very inefficient approach compared to alternative routing algorithms. I am concerned that RPL does not actually meet the original requirements in I-D.ietf-roll-building-routing-reqs, I-D.ietf-roll-home-routing-reqs, RFC5673 and RFC5548. The traffic = pattern requirement for a sink node features prominently in only two of those documents. Even in this case, as Ted points out, communication is likely = to be bidirectional (e.g. end-to-end acks.) therefore the DODAG approach is fundamentally asymmetric, especially if no intermediate storage is = allowed for destination routes and source routing has to be used.

Also, RPL seems highly complex for what are constrained nodes in terms = of memory as well as power and bandwidth. The RPL draft as it stands is 82 = pages long and that doesn't include text about the objective function.

Robert

Robert Cragie (Pacific Gas & = Electric)

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



Ted.Humpal@jci.com wrote: =


A concern also will be how much overhead (memory space) will be required = for a DODAG Root?

and based on the first question how many DODAG roots a lamp may need to be a = member of?

For example in lighting  a single lamp may be a root for a single = switch (1 DODAG root),  this lamp / luminaire may also =
be a member of another group - -  which could be all lights on the = floor (2nd DODAG root), and a third group
of all the lights in the building.  There can be many more speciality = groups associated based on the building configuration. =
Consider also during the installation time - how these DODAG roots will be = configured?  Must I commission each device
to tell it which DODAG it must use for its Object Function?  How easy = will this be to change and add in a new DODAG root =
for the end user if the lighting group changes??

With respect to Jerry Martocci's - commercial building requirements - every = device may need to communicate to any or
all of the end devices.  If each device must establish a DODAG for the = other 499 devices in a 500 node network - How much memory
space will this require for each end device to maintain?  

Keep in mind that the end devices are very limited processor and memory = wise.

Not to mention all of the network maintenance messages that would need to be transmitted to maintain all of these DODAGs.

Consider the reconvergence time when one device is turned off and it was in the = middle of the majority of the 100+ DODAGS?

In many lighting and building application an application acknowledgement - = must be returned {Back down the DODAG} so . . . the
requirement is not just getting to the Root - a return path must also be maintained = and have a  low latency path.

Ted Humpal

From:

Kris Pister <pister@eecs.berkeley.edu>=

To:

Anders Brandt <abr@sdesigns.dk> =

Cc:

ROLL WG <roll@ietf.org> =

Date:

03/08/2010 01:45 PM

Subject:

Re: [Roll] P2P performance with current RPL proposal

 




Anders - if we take JP's suggestion to make The Lamp a DODAG root, and = take Phoebus' recommendation that we use path diversity to improve end-to-end reliability, do you see a chance of success?
In my experience, with diverse paths and order-minutes updates you get extremely high reliability.

I have no aversion to TTL-limited floods as a part of a solution either.  I'm open to ideas on how to bring those in as (presumably = infrequently used) options.

ksjp

Anders Brandt wrote:
Hello
 
I = would like to probe the temperature of the WG on using DAOs to
support P2P.
 
The = building and home application spaces (and maybe others) have
a = few clearly defined requirements.
It = is not obvious to me how the current RPL proposal (cRPLp) can
satisfy those requirements:
 
 
In = both cases it is the worst case scenario that hurts:
 
 
P2P = routing inside the PAN
=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
cRPLp has no way of routing inside the PAN if you need more than
one = repeater. cRPLp has to go all the way to the top (maybe 4 hops up)
and = down again (maybe 4 hops down) to get just 2 hops to the side.
 
The consequence is high latency and high levels of background noise
for nodes just outside the direct radio range. =
At = the same time the risk of meeting a failing link is 4 times higher = =3D>
latency may be much more than 4 times larger.
 
Latency may sound like a minor issue but it actually translates directly
into lower battery lifetime. In the above (very realistic) = example,
the = battery lifetime is reduced to 25% of what it should be. =
 
We = have lots of battery devices sending into the network:
* = PIR sensors turning on lights
* = Door locks sending alarms
* = Door/window sensors starting chimes
* = Smoke sensors triggering an alarm system
 
 
 
 
Response time
=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D
The = latency issue is important.
When a user (real human being) presses a light button the user expects
the = light to turn on.
cRPLp proposes that nodes in the tree periodically advertises their
presence using DAOs.
The periodicity is a real beast:
Thanks to Trickle, the rate of updates in a (apparently) stable network
is low. This is good since it leaves bandwidth for data.
But = it is not good if existing routes to my lamp fail and I do not get
new = routes to my lamp until it decides to send out a new DAO. =
My = user will (with a good reason) not tolerate waiting for minutes for
the = light to turn on.
 
I = have met two arguments to counter this concern:
 
A1: = Well, your lamp can always send a DAO when it detects a problem.
  My answer:
  True, except that my lamp does not intend to send anything
  so it will never experience any problems from its side of the = network.
 
A2: = Well, you can increase the DAO rate to sub-second updates. =
  My answer:
  Oh no. I get a very high degree = of management traffic which
  limits my available bandwidth, increases the risk of collisions and
  even run the risk of violating EU legislation requiring me to = only
  transmit in less than 1% of the time:
  http://focus.ti.com/lit/an/= swra048/swra048.pdf
 868 - 868.6 MHz: <1%
 
  Reactiveness is hard to achieve via polling.
 
 
 
If = you agree that this seems to be critical issues please raise your
voice on the list.
 
Going forward
=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D
 
We = need some reactive mechanism to reach lamps before the user decides
to = sue our companies.
So = is this possible? I think so.

Existing commercial (non-IP) solutions are capable of re-routing = quickly
if = they really have to.
 
Let = me try scoping the requirements to a potential solution: =
(no = different from the req. docs for home and building)
 
* = P2P routing in any direction independent of the tree.
 
* = On-demand P2P route discovery if requested by a real-time critical app.
 Data collection apps may be able to just wait for the next DAO = update.
 
* = Limited range of discovery mechanism: max 4 repeaters. =
  A TTL field may limit the scope of the repeaters.
 
* = Suboptimal routing and traffic bursts are accepted in exchange
  for quick route repair. But only as an exception.
 
 
Just as an example, one existing home control technology uses a
(source routing) variant of AODV for quick route repair.
Nothing comes for free. The price is flooding - but not just flooding:
Managed flooding using a distributed algorithm running in all
participating nodes.
The = algorithm dampens the flooding in a time, volume and range perspective. =
Some similar mechanism could be built into RPL for quick route repair.
 
 
If = anyone have alternative proposals, please bring it to the list.
Now = is the time.
 
 
 
Thanks,
  Anders


______________________________________________= _
Roll mailing = 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_0077_01CAC735.152F3590-- From robert.assimiti@nivis.com Fri Mar 19 08:14: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 974983A6A82 for ; Fri, 19 Mar 2010 08:14:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.124 X-Spam-Level: X-Spam-Status: No, score=-0.124 tagged_above=-999 required=5 tests=[AWL=1.345, 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 3riXFjknl1iB for ; Fri, 19 Mar 2010 08:14:48 -0700 (PDT) Received: from smtp.nivis.com (smtp.nivis.com [65.205.163.2]) by core3.amsl.com (Postfix) with ESMTP id D66BD3A6A71 for ; Fri, 19 Mar 2010 08:14:42 -0700 (PDT) Received: from ATLEXCH02.nivis.com ([10.0.0.18]) by ATLEXCH02.nivis.com ([10.0.0.18]) with mapi; Fri, 19 Mar 2010 11:14:55 -0400 From: Robert Assimiti To: "roll@ietf.org" , "Pascal Thubert (pthubert)" Date: Fri, 19 Mar 2010 11:14:54 -0400 Thread-Topic: Triggering a new DODAG iteration Thread-Index: AcrG6wlYaNf74zqBQ2GhOedUbXbg+QAi2Wxg Message-ID: <67442429D9C35E4C975B89BE73BD33D015FB21430C@ATLEXCH02.nivis.com> 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] Triggering a new DODAG iteration X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 19 Mar 2010 15:14:49 -0000 Hello Pascal, It seems that we see eye to eye on this issue and that we both agree that t= his would be very useful for multiple reasons. Should we start identifying a set of various error/info reporting messages? Robert Assimiti Office: [678]-202-6859 Mobile: [404]-578-0205 robert.assimiti@nivis.com -----Original Message----- From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of rol= l-request@ietf.org Sent: Thursday, March 18, 2010 6:33 PM To: roll@ietf.org Subject: Roll Digest, Vol 26, Issue 46 If you have received this digest without all the individual message attachments you will need to update your digest options in your list subscription. To do so, go to=20 https://www.ietf.org/mailman/listinfo/roll Click the 'Unsubscribe or edit options' button, log in, and set "Get MIME or Plain Text Digests?" to MIME. You can set this option globally for all the list digests you receive at this point. Send Roll mailing list submissions to roll@ietf.org To subscribe or unsubscribe via the World Wide Web, visit https://www.ietf.org/mailman/listinfo/roll or, via email, send a message with subject or body 'help' to roll-request@ietf.org You can reach the person managing the list at roll-owner@ietf.org When replying, please edit your Subject line so it is more specific than "Re: Contents of Roll digest..." Today's Topics: 1. Triggering a new DODAG iteration (Robert Assimiti) 2. Re: Triggering a new DODAG iteration (Pascal Thubert (pthubert)) ---------------------------------------------------------------------- Message: 1 Date: Thu, 18 Mar 2010 16:24:28 -0400 From: Robert Assimiti Subject: [Roll] Triggering a new DODAG iteration To: "roll@ietf.org" Message-ID: <67442429D9C35E4C975B89BE73BD33D015FB214273@ATLEXCH02.nivis.com> Content-Type: text/plain; charset=3D"us-ascii" As you can imagine, triggering a new DODAG iteration in a wireless subnet t= hat scales to thousands of wireless nodes can be quite disruptive to the op= eration of the subnet. The criteria that will trigger a new DODAG iteration should (in my opinion)= be left to the implementation. The decision of triggering a new DODAG iteration lies with the root. A well informed root can make better decisions than an un-informed root. Hence I propose that we discuss additional standardized error messages repo= rted by the routers. At this point nodes can flag rank and forwarding errors through the usage o= f the 'R' and 'F' bits present in the flow label. In my opinion, this is a very limited set of error messages. Since we are seeking interoperability, we should define a new ICMPv6 error= message that allows the nodes to report various DODAG inconsistencies and = discrepancies with more details and precision than the 'R' and 'F' bits. Some suggestions for potential reported errors: 1. Preferred parent not reachable 2. Parent not reachable 3. Parent set nears depletion Etc ....etc Armed with this information (sent in an interoperable manner) the root is n= ow capable of making a more informed decision when to trigger a new DODAG i= teration. Any thoughts? Suggestions? Robert Assimiti Office: [678]-202-6859 Mobile: [404]-578-0205 robert.assimiti@nivis.com ________________________________ This e-mail (including any attachments to it) is confidential, proprietary,= legally privileged, subject to copyright and is sent for the personal atte= ntion of the intended recipient only. If you have received this e-mail in e= rror, please reply to advise us immediately, delete it and destroy any prin= ted copies of it. You are notified that reading, disclosing, copying, distr= ibuting or taking any action in reliance on the contents of this informatio= n is strictly prohibited. No employee is authorized to conclude any binding= agreement on behalf of NIVIS LLC with another party by e-mail without expr= ess written confirmation by an officer of the company. Although we have tak= en reasonable precautions to ensure no viruses are present in this e-mail, = we cannot accept responsibility for any loss or damage arising from the vir= uses in this e-mail or attachments. -------------- next part -------------- An HTML attachment was scrubbed... URL: ------------------------------ Message: 2 Date: Thu, 18 Mar 2010 23:33:05 +0100 From: "Pascal Thubert (pthubert)" Subject: Re: [Roll] Triggering a new DODAG iteration To: "Robert Assimiti" , Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D01792E3C@XMB-AMS-107.cisco.com> Content-Type: text/plain; charset=3D"us-ascii" HI Robert : =20 This makes a lot of sense to me. Other root decisions like a source route path selection could also benefit from such error/info reporting. =20 Pascal =20 From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Robert Assimiti Sent: Thursday, March 18, 2010 1:24 PM To: roll@ietf.org Subject: [Roll] Triggering a new DODAG iteration =20 As you can imagine, triggering a new DODAG iteration in a wireless subnet that scales to thousands of wireless nodes can be quite disruptive to the operation of the subnet. =20 The criteria that will trigger a new DODAG iteration should (in my opinion) be left to the implementation. The decision of triggering a new DODAG iteration lies with the root.=20 A well informed root can make better decisions than an un-informed root. =20 Hence I propose that we discuss additional standardized error messages reported by the routers. At this point nodes can flag rank and forwarding errors through the usage of the 'R' and 'F' bits present in the flow label. =20 In my opinion, this is a very limited set of error messages.=20 Since we are seeking interoperability, we should define a new ICMPv6 error message that allows the nodes to report various DODAG inconsistencies and discrepancies with more details and precision than the 'R' and 'F' bits.=20 Some suggestions for potential reported errors: 1. Preferred parent not reachable 2. Parent not reachable 3. Parent set nears depletion Etc ....etc =20 Armed with this information (sent in an interoperable manner) the root is now capable of making a more informed decision when to trigger a new DODAG iteration. =20 Any thoughts? Suggestions? =20 =20 =20 =20 Robert Assimiti Office: [678]-202-6859 Mobile: [404]-578-0205 robert.assimiti@nivis.com =20 =20 ________________________________ This e-mail (including any attachments to it) is confidential, proprietary, legally privileged, subject to copyright and is sent for the personal attention of the intended recipient only. If you have received this e-mail in error, please reply to advise us immediately, delete it and destroy any printed copies of it. You are notified that reading, disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited. No employee is authorized to conclude any binding agreement on behalf of NIVIS LLC with another party by e-mail without express written confirmation by an officer of the company. Although we have taken reasonable precautions to ensure no viruses are present in this e-mail, we cannot accept responsibility for any loss or damage arising from the viruses in this e-mail or attachments. -------------- next part -------------- An HTML attachment was scrubbed... URL: ------------------------------ _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll End of Roll Digest, Vol 26, Issue 46 ************************************ From robert.cragie@gridmerge.com Fri Mar 19 08:38: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 798643A6AA6 for ; Fri, 19 Mar 2010 08:38:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.468 X-Spam-Level: X-Spam-Status: No, score=-2.468 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, 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 nkxzJCq-FiPl for ; Fri, 19 Mar 2010 08:37:59 -0700 (PDT) Received: from mail78.extendcp.co.uk (mail78.extendcp.co.uk [79.170.40.78]) by core3.amsl.com (Postfix) with ESMTP id AC86C3A6A64 for ; Fri, 19 Mar 2010 08:37:56 -0700 (PDT) Received: from client-86-23-13-26.brhm.adsl.virginmedia.com ([86.23.13.26] helo=[192.168.1.68]) by mail78.extendcp.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.70) id 1NseGq-0005gu-SF; Fri, 19 Mar 2010 15:38:00 +0000 Message-ID: <4BA39A4E.4070406@gridmerge.com> Date: Fri, 19 Mar 2010 15:37:50 +0000 From: Robert Cragie Organization: Gridmerge Ltd. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.8) Gecko/20100227 Lightning/1.0b1 Thunderbird/3.0.3 MIME-Version: 1.0 To: Mukul Goyal References: <836717245.7606741268982546867.JavaMail.root@mail02.pantherlink.uwm.edu> In-Reply-To: <836717245.7606741268982546867.JavaMail.root@mail02.pantherlink.uwm.edu> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms010206030802000101080601" Cc: ROLL WG , Ted Humpal Subject: Re: [Roll] P2P performance with current RPL proposal 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, 19 Mar 2010 15:38:02 -0000 This is a cryptographically signed message in MIME format. --------------ms010206030802000101080601 Content-Type: multipart/alternative; boundary="------------060800090205050407070504" This is a multi-part message in MIME format. --------------060800090205050407070504 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable I think we are starting to get somewhere with the concept of DIO as RREQ = and DAO as RREP. However, to make it on-demand and efficient, we need to = be able to initiate a DIO immediately from any node and not have it=20 associated with a trickle timer. Similarly, nodes with a higher rank=20 number based on the origin of the DIO would need to store DAG=20 information temporarily and expire it if a corresponding DAO is not=20 received going back to the originator. So the concept of root goes away=20 somewhat; in this case it is more originator. The DAG information can be = set bidirectionally to allow route discovery in both directions=20 (outbound on the DIO and return on the DAO) thus potentially eliminating = the need for source routing. I think this would allow DODAGs and this new route formations (not sure=20 what to call them) to coexist without having to maintain the overhead of = multiple DODAGs with different roots. Robert Robert Cragie (Pacific Gas & Electric) Gridmerge Ltd. 89 Greenfield Crescent, Wakefield, WF4 4WA, UK +44 (0) 1924 910888 http://www.gridmerge.com On 19/03/2010 7:09 AM, Mukul Goyal wrote: > Pascal, WG: > > Here I have attempted to formulate a simple DV algorithm in RPL/DAG ter= ms. I will appreciate it if you could let me know about your objections t= o this proposal: > > Node A needs to reach a destination D. Node A initiates a discovery DAG= towards D. As the DIOs reach D, it sends a DAO back to selected parents.= As the DAO travels towards node A, in-route nodes store the cost to reac= h D. > > When node B needs to reach D, it similarly initiates a discovery dag. D= uring this discovery, when a DIO reaches a node C that maintains a cost t= o reach D, node C responds back with a DAO that travels towards B and sto= res in in-route nodes the cost to reach D. > > Thus, as more and more nodes try to discover a route to D, a destinatio= n oriented DAG (DODAG) emerges that leads these nodes to D. The differenc= e from the traditional DODAG, as explained in RPL draft, is that the DAG = root does not initiate DAG formation. The leaf nodes initiate the discove= ry of the DAG root. > > Now, we can go one step further in order to save on memory =E2=80=93 co= mbine DODAGs leading to D and another destination E into one. This can be= done by aggregating the cost to reach D and E into one cost (the higher = of the two) and letting parent nodes know about the aggregated cost. Repe= ated aggregations can help reduce memory requirements at the cost of subo= ptimality. > > Thanks > Mukul > > > ----- Original Message ----- > From: "Pascal Thubert (pthubert)" > To: "robert cragie" > Cc: "ROLL WG", "Ted Humpal" > Sent: Thursday, March 18, 2010 9:23:14 PM GMT -06:00 US/Canada Central > Subject: Re: [Roll] P2P performance with current RPL proposal > > > > > > Hi Robert : > > =20 > > At least from a distance, the proposed mechanism emulates AODV, with th= e DIO as RREQ and the DAO as RREP. So if we decide to dig along those lin= es, we=E2=80=99ll certainly appreciate help from MANET experts. I=E2=80=99= d say that if you already have RPL for P2MP and MP2P, the proposed extens= ion are probably simpler to add than doing AODV from scratch. > > =20 > > For the setup, the major differences are that we build a DAG and that w= e can indicate multiple targets. If you look at it, the DAG capability is= a MUST for RPL, and I have not seen that this MUST goes away for P2P flo= ws. The multiple targets is something that appears in a number of use cas= es and it seems more economical to build a single DAG for multiple target= s when possible. > > =20 > > For the maintenance, the major differences are that we have the DAG as = first line of defense, and the RPL detection to stimulate the local repai= r. > > =20 > > About your questions: > > =20 > > The DODAG root is the one that spawns the DAG. The targets can reach th= e root because the root advertises itself in the DIO. The idea is that th= e root ID is the address that the targets need to talk to. If needed, the= root can also advertise a prefix that it can reach and that the targets = need to reach too. > > =20 > > All the intermediate nodes that are confirmed by the DAO need to retain= at least info about the DAG. That enables the targets to reach the root.= The flooding should cost about the same as that of AODV but the RPL way = will require more states in the nodes on the way if the OF requires a DAG= =2E > > =20 > > The way back (down) can be stateful of stateless, depending on which DA= O we=E2=80=99re using. With fully stateful DAO, we are really in AODV-lan= d. With stateless, we could drift into DSR-land for that direction. Which= limits we place to keep it simple will be determined by the resolution o= f issue #26 I guess=E2=80=A6 > > =20 > > And please, no apologize or on one will dare post anything anymore. You= r questions are fully relevant and at the core of the discussion. > > =20 > > I hope we can talk in Anaheim for sure, > > > > > Pascal > > =20 > > > > > From: Robert Cragie [mailto:robert.cragie@gridmerge.com] > Sent: Monday, March 15, 2010 11:27 AM > To: Pascal Thubert (pth ubert) > Cc: Ted.Humpal@jci.com; ROLL WG > Subject: Re: [Roll] P2P performance with current RPL proposal > > =20 > > Hi Pascal, > > So in your slideware T can end up talking to R (DODAG root) through the= DODAG. So are you proposing that all potential targets can act as a DODA= G root? And therefore all intermediates have to retain DIO propagation su= pport for that DODAG as well? This may work for limited P2P but seems les= s efficient than simple distance vector flooding RREQ/RREP like AODV or D= YMO for generic P2P. What about R to T (or anyone else for that matter)? = Do we source route, maintain state, some undefined hybrid of the two? > > I apologise if some of these questions have been answered in detail in = earlier reflector posts but I have only recently started to concentrate m= y efforts on RPL and have 82 pages to wade through :-). I look forward to= a productive session in Anaheim. > > Robert > > > Robert Cragie (Pacific Gas& Electric) > > Gridmerge Ltd. > 89 Greenfield Crescent, > Wakefield, WF4 4WA, UK > +44 (0) 1924 910888 > http://www.gridmerge.com > > > > Pascal Thubert (pthubert) wrote: > > HI Robert : > > =20 > > I respectfully have to disagree. > > =20 > > My understanding is that we are considering a limited set of P2P pairs,= for which the specific path that we need to create might have to obey sp= ecific constraints. > > So it makes sense to use an on-demand technique, probably inspired by t= he MANET Reactive protocols. > > =20 > > As it goes, those protocols usually use flooding for a node to locate a= nother. Forking a DAG is just another flooding. It does not take a lot of= addition to the existing DIO for a root to use RPL to build a DAG that c= ontains one or multiple Targets as leaves, under a set of constraints exp= ressed as an objective function. Please find attached a slideware that il= lustrates that. > > =20 > > > Pascal > > =20 > > > > > From: roll-bounces@ietf.org [ mailto:roll-bounces@ietf.org ] On Behalf = Of Robert Cragie > Sent: Thursday, March 11, 2010 2:43 PM > To: Ted.Humpal@jci.com > Cc: ROLL WG > Subject: Re: [Roll] P2P performance with current RPL proposal > > =20 > > I agree with Ted's comments below. Creating a DODAG for every reachable= node as a root seems a very inefficient approach compared to alternative= routing algorithms. I am concerned that RPL does not actually meet the o= riginal requirements in I-D.ietf-roll-building-routing-reqs, I-D.ietf-rol= l-home-routing-reqs, RFC5673 and RFC5548. The traffic pattern requirement= for a sink node features prominently in only two of those documents. Eve= n in this case, as Ted points out, communication is likely to be bidirect= ional (e.g. end-to-end acks.) therefore the DODAG approach is fundamental= ly asymmetric, especially if no intermediate storage is allowed for desti= nation routes and source routing has to be used. > > Also, RPL seems highly complex for what are constrained nodes in terms = of memory as well as power and bandwidth. The RPL draft as it stands is 8= 2 pages long and that doesn't include text about the objective function. > > Robert > > > Robert Cragie (Pacific Gas& Electric) > > Gridmerge Ltd. > 89 Greenfield Crescent, > Wakefield, WF4 4WA, UK > +44 (0) 1924 910888 > http://www.gridmerge.com > > > > Ted.Humpal@jci.com wrote: > > > A concern also will be how much overhead (memory space) will be require= d for a DODAG Root? > > and based on the first question how many DODAG roots a lamp may need to= be a member of? > > For example in lighting a single lamp may be a root for a single switc= h (1 DODAG root), this lamp / luminaire may also > be a member of another group - - which could be all lights on the floo= r (2nd DODAG root), and a third group > of all the lights in the building. There can be many more speciality g= roups associated based on the building configuration. > Consider also during the installation time - how these DODAG roots will= be configured? Must I commission each device > to tell it which DODAG it must use for its Object Function? How easy w= ill this be to change and add in a new DODAG root > for the end user if the lighting group changes?? > > With respect to Jerry Martocci's - commercial building requirements - e= very device may need to communicate to any or > all of the end devices. If each device must establish a DODAG for the = other 499 devices in a 500 node network - How much memory > space will this require for each end device to maintain? =20 > > Keep in mind that the end devices are very limited processor and memory= wise. > > Not to mention all of the network maintenance messages that would need = to be transmitted to maintain all of these DODAGs. > > Consider the reconvergence time when one device is turned off and it wa= s in the middle of the majority of the 100+ DODAGS? > > In many lighting and building application an application acknowledgemen= t - must be returned {Back down the DODAG} so . . . the > requirement is not just getting to the Root - a return path must also b= e maintained and have a low latency path. > > Ted Humpal > > > > > > > From: =09 > > Kris Pister > > > To: =09 > > Anders Brandt > > > Cc: =09 > > ROLL WG > > > Date: =09 > > 03/08/2010 01:45 PM > > > Subject: =09 > > Re: [Roll] P2P performance with current RPL proposal > > =20 > > > > > > > Anders - if we take JP's suggestion to make The Lamp a DODAG root, and = take Phoebus' recommendation that we use path diversity to improve end-to= -end reliability, do you see a chance of success? > In my experience, with diverse paths and order-minutes updates you get = extremely high reliability. > > I have no aversion to TTL-limited floods as a part of a solution either= =2E I'm open to ideas on how to bring those in as (presumably infrequent= ly used) options. > > ksjp > > Anders Brandt wrote: > Hello > =20 > I would like to probe the temperature of the WG on using DAOs to > support P2P. > =20 > The building and home application spaces (and maybe others) have > a few clearly defined requirements. > It is not obvious to me how the current RPL proposal (cRPLp) can > satisfy those requirements: > =20 > =20 > In both cases it is the worst case scenario that hurts: > =20 > =20 > P2P routing inside the PAN > =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 > cRPLp has no way of routing inside the PAN if you need more than > one repeater. cRPLp has to go all the way to the top (maybe 4 hops up) > and down again (maybe 4 hops down) to get just 2 hops to the side. > =20 > The consequence is high latency and high levels of background noise > for nodes just outside the direct radio range. > At the same time the risk of meeting a failing link is 4 times higher =3D= > > latency may be much more than 4 times larger. > =20 > Latency may sound like a minor issue but it actually translates directl= y > into lower battery lifetime. In the above (very realistic) example, > the battery lifetime is reduced to 25% of what it should be. > =20 > We have lots of battery devices sending into the network: > * PIR sensors turning on lights > * Door locks sending alarms > * Door/window sensors starting chimes > * Smoke sensors triggering an alarm system > =20 > =20 > =20 > =20 > Response time > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > The latency issue is important. > When a user (real human being) presses a light button the user expects > the light to turn on. > cRPLp proposes that nodes in the tree periodically advertises their > presence using DAOs. > The periodicity is a real beast: > Thanks to Trickle, the rate of updates in a (apparently) stable network= > is low. This is good since it leaves bandwidth for data. > But it is not good if existing routes to my lamp fail and I do not get > new routes to my lamp until it decides to send out a new DAO. > My user will (with a good reason) not tolerate waiting for minutes for > the light to turn on. > =20 > I have met two arguments to counter this concern: > =20 > A1: Well, your lamp can always send a DAO when it detects a problem. > My answer: > True, except that my lamp does not intend to send anything > so it will never experience any problems from its side of the networ= k. > =20 > A2: Well, you can increase the DAO rate to sub-second updates. > My answer: > Oh no. I get a very high degree of management traffic which > limits my available bandwidth, increases the risk of collisions and > even run the risk of violating EU legislation requiring me to only > transmit in less than 1% of the time: > http://focus.ti.com/lit/an/swra048/swra048.pdf > 868 - 868.6 MHz:<1% > =20 > Reactiveness is hard to achieve via polling. > =20 > =20 > =20 > If you agree that this seems to be critical issues please raise your > voice on the list. > =20 > Going forward > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > =20 > We need some reactive mechanism to reach lamps before the user decides > to sue our companies. > So is this possible? I think so. > > Existing commercial (non-IP) solutions are capable of re-routing quickl= y > if they really have to. > =20 > Let me try scoping the requirements to a potential solution: > (no different from the req. docs for home and building) > =20 > * P2P routing in any direction independent of the tree. > =20 > * On-demand P2P route discovery if requested by a real-time critical ap= p. > Data collection apps may be able to just wait for the next DAO update= =2E > =20 > * Limited range of discovery mechanism: max 4 repeaters. > A TTL field may limit the scope of the repeaters. > =20 > * Suboptimal routing and traffic bursts are accepted in exchange > for quick route repair. But only as an exception. > =20 > =20 > Just as an example, one existing home control technology uses a > (source routing) variant of AODV for quick route repair. > Nothing comes for free. The price is flooding - but not just flooding: > Managed flooding using a distributed algorithm running in all > participating nodes. > The algorithm dampens the flooding in a time, volume and range perspect= ive. > Some similar mechanism could be built into RPL for quick route repair. > =20 > =20 > If anyone have alternative proposals, please bring it to the list. > Now is the time. > =20 > =20 > =20 > Thanks, > Anders > > > > > _______________________________________________ > Roll mailing 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 Ro= ll@ietf.org https://www.ietf.org/mailman/listinfo/roll =20 > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > > =20 --------------060800090205050407070504 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I think we are starting to get somewhere with the concept of DIO as RREQ and DAO as RREP. However, to make it on-demand and efficient, we need to be able to initiate a DIO immediately from any node and not have it associated with a trickle timer. Similarly, nodes with a higher rank number based on the origin of the DIO would need to store DAG information temporarily and expire it if a corresponding DAO is not received going back to the originator. So the concept of root goes away somewhat; in this case it is more originator. The DAG information can be set bidirectionally to allow route discovery in both directions (outbound on the DIO and return on the DAO) thus potentially eliminating the need for source routing.

I think this would allow DODAGs and this new route formations (not sure what to call them) to coexist without having to maintain the overhead of multiple DODAGs with different roots.

Robert

Robert Cragie (Pacific Gas & Electric)

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


On 19/03/2010 7:09 AM, Mukul Goyal wrote: 
Pascal, WG:

Here I have attempted to formulate a simple DV algorithm in RPL/DAG terms=
=2E I will appreciate it if you could let me know about your objections t=
o this proposal:

Node A needs to reach a destination D. Node A initiates a discovery DAG t=
owards D. As the DIOs reach D, it sends a DAO back to selected parents. A=
s the DAO travels towards node A, in-route nodes store the cost to reach =
D.

When node B needs to reach D, it similarly initiates a discovery dag. Dur=
ing this discovery, when a DIO reaches a node C that maintains a cost to =
reach D, node C responds back with a DAO that travels towards B and store=
s in in-route nodes the cost to reach D.

Thus, as more and more nodes try to discover a route to D, a destination =
oriented DAG (DODAG) emerges that leads these nodes to D. The difference =
from the traditional DODAG, as explained in RPL draft, is that the DAG ro=
ot does not initiate DAG formation. The leaf nodes initiate the discovery=
 of the DAG root.

Now, we can go one step further in order to save on memory =E2=80=93 comb=
ine DODAGs leading to D and another destination E into one. This can be d=
one by aggregating the cost to reach D and E into one cost (the higher of=
 the two) and letting parent nodes know about the aggregated cost. Repeat=
ed aggregations can help reduce memory requirements at the cost of subopt=
imality.

Thanks
Mukul


----- Original Message -----
From: "Pascal Thubert (pthubert)" <pthubert@cisco.com>
To: "robert cragie" <robert.cragie@gridmerge.com>
Cc: "ROLL WG" <roll@ietf.org>, "Ted Humpal" <Ted.Humpal@jci.com>
Sent: Thursday, March 18, 2010 9:23:14 PM GMT -06:00 US/Canada Central
Subject: Re: [Roll] P2P performance with current RPL proposal





Hi Robert=C2=A0:=20

=C2=A0=20

At least from a distance, the proposed mechanism emulates AODV, with the =
DIO as RREQ and the DAO as RREP. So if we decide to dig along those lines=
, we=E2=80=99ll certainly appreciate help from MANET experts. I=E2=80=99d=
 say that if you already have RPL for P2MP and MP2P, the proposed extensi=
on are probably simpler to add than doing AODV from scratch.=20

=C2=A0=20

For the setup, the major differences are that we build a DAG and that we =
can indicate multiple targets. If you look at it, the DAG capability is a=
 MUST for RPL, and I have not seen that this MUST goes away for P2P flows=
=2E The multiple targets is something that appears in a number of use cas=
es and it seems more economical to build a single DAG for multiple target=
s when possible.=20

=C2=A0=20

For the maintenance, the major differences are that we have the DAG as fi=
rst line of defense, and the RPL detection to stimulate the local repair.=
=20

=C2=A0=20

About your questions:=20

=C2=A0=20

The DODAG root is the one that spawns the DAG. The targets can reach the =
root because the root advertises itself in the DIO. The idea is that the =
root ID is the address that the targets need to talk to. If needed, the r=
oot can also advertise a prefix that it can reach and that the targets ne=
ed to reach too.=20

=C2=A0=20

All the intermediate nodes that are confirmed by the DAO need to retain a=
t least info about the DAG. That enables the targets to reach the root. T=
he flooding should cost about the same as that of AODV but the RPL way wi=
ll require more states in the nodes on the way if the OF requires a DAG. =


=C2=A0=20

The way back (down) can be stateful of stateless, depending on which DAO =
we=E2=80=99re using. With fully stateful DAO, we are really in AODV-land.=
 With stateless, we could drift into DSR-land for that direction. Which l=
imits we place to keep it simple will be determined by the resolution of =
issue #26 I guess=E2=80=A6=20

=C2=A0=20

And please, no apologize or on one will dare post anything anymore. Your =
questions are fully relevant and at the core of the discussion.=20

=C2=A0=20

I hope we can talk in Anaheim for sure,=20




Pascal=20

=C2=A0=20




From: Robert Cragie [mailto:robert.cragie@gridmerge.com]=20
Sent: Monday, March 15, 2010 11:27 AM=20
To: Pascal Thubert (pth ubert)=20
Cc: Ted.Humpal@jci.com; ROLL WG=20
Subject: Re: [Roll] P2P performance with current RPL proposal=20

=C2=A0=20

Hi Pascal,=20

So in your slideware T can end up talking to R (DODAG root) through the D=
ODAG. So are you proposing that all potential targets can act as a DODAG =
root? And therefore all intermediates have to retain DIO propagation supp=
ort for that DODAG as well? This may work for limited P2P but seems less =
efficient than simple distance vector flooding RREQ/RREP like AODV or DYM=
O for generic P2P. What about R to T (or anyone else for that matter)? Do=
 we source route, maintain state, some undefined hybrid of the two?=20

I apologise if some of these questions have been answered in detail in ea=
rlier reflector posts but I have only recently started to concentrate my =
efforts on RPL and have 82 pages to wade through :-). I look forward to a=
 productive session in Anaheim.=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



Pascal Thubert (pthubert) wrote:=20

HI Robert=C2=A0:=20

=C2=A0=20

I respectfully have to disagree.=20

=C2=A0=20

My understanding is that we are considering a limited set of P2P pairs, f=
or which the specific path that we need to create might have to obey spec=
ific constraints.=20

So it makes sense to use an on-demand technique, probably inspired by the=
 MANET Reactive protocols.=20

=C2=A0=20

As it goes, those protocols usually use flooding for a node to locate ano=
ther. Forking a DAG is just another flooding. It does not take a lot of a=
ddition to the existing DIO for a root to use RPL to build a DAG that con=
tains one or multiple Targets as leaves, under a set of constraints expre=
ssed as an objective function. Please find attached a slideware that illu=
strates that.=20

=C2=A0=20


Pascal=20

=C2=A0=20




From: roll-bounces@ietf.org [ mailto:roll-bounces@ietf.org ] O=
n Behalf Of Robert Cragie=20
Sent: Thursday, March 11, 2010 2:43 PM=20
To: Ted.Humpal@jci.com=20
Cc: ROLL WG=20
Subject: Re: [Roll] P2P performance with current RPL proposal=20

=C2=A0=20

I agree with Ted's comments below. Creating a DODAG for every reachable n=
ode as a root seems a very inefficient approach compared to alternative r=
outing algorithms. I am concerned that RPL does not actually meet the ori=
ginal requirements in I-D.ietf-roll-building-routing-reqs, I-D.ietf-roll-=
home-routing-reqs, RFC5673 and RFC5548. The traffic pattern requirement f=
or a sink node features prominently in only two of those documents. Even =
in this case, as Ted points out, communication is likely to be bidirectio=
nal (e.g. end-to-end acks.) therefore the DODAG approach is fundamentally=
 asymmetric, especially if no intermediate storage is allowed for destina=
tion routes and source routing has to be used.=20

Also, RPL seems highly complex for what are constrained nodes in terms of=
 memory as well as power and bandwidth. The RPL draft as it stands is 82 =
pages long and that doesn't include text about the objective function.=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



=
Ted.Humpal@jci.com wrote:=20


A concern also will be how much overhead (memory space) will be required =
for a DODAG Root?=20

and based on the first question how many DODAG roots a lamp may need to b=
e a member of?=20

For example in lighting =C2=A0a single lamp may be a root for a single sw=
itch (1 DODAG root), =C2=A0this lamp / luminaire may also=20
be a member of another group - - =C2=A0which could be all lights on the f=
loor (2nd DODAG root), and a third group=20
of all the lights in the building. =C2=A0There can be many more specialit=
y groups associated based on the building configuration.=20
Consider also during the installation time - how these DODAG roots will b=
e configured? =C2=A0Must I commission each device=20
to tell it which DODAG it must use for its Object Function? =C2=A0How eas=
y will this be to change and add in a new DODAG root=20
for the end user if the lighting group changes??=20

With respect to Jerry Martocci's - commercial building requirements - eve=
ry device may need to communicate to any or=20
all of the end devices. =C2=A0If each device must establish a DODAG for t=
he other 499 devices in a 500 node network - How much memory=20
space will this require for each end device to maintain? =C2=A0=20

Keep in mind that the end devices are very limited processor and memory w=
ise.=20

Not to mention all of the network maintenance messages that would need to=
 be transmitted to maintain all of these DODAGs.=20

Consider the reconvergence time when one device is turned off and it was =
in the middle of the majority of the 100+ DODAGS?=20

In many lighting and building application an application acknowledgement =
- must be returned {Back down the DODAG} so . . . the=20
requirement is not just getting to the Root - a return path must also be =
maintained and have a =C2=A0low latency path.=20

Ted Humpal=20






From: =09

Kris Pister <pister@eecs.berkeley.edu>=20


To: =09

Anders Brandt <abr@sdesigns.dk>=20


Cc: =09

ROLL WG =
<roll@ietf.org>=20


Date: =09

03/08/2010 01:45 PM=20


Subject: =09

Re: [Roll] P2P performance with current RPL proposal=20

=C2=A0=20






Anders - if we take JP's suggestion to make The Lamp a DODAG root, and ta=
ke Phoebus' recommendation that we use path diversity to improve end-to-e=
nd reliability, do you see a chance of success?=20
In my experience, with diverse paths and order-minutes updates you get ex=
tremely high reliability.=20

I have no aversion to TTL-limited floods as a part of a solution either. =
=C2=A0I'm open to ideas on how to bring those in as (presumably infrequen=
tly used) options.=20

ksjp=20

Anders Brandt wrote:=20
Hello=20
=C2=A0=20
I would like to probe the temperature of the WG on using DAOs to=20
support P2P.=20
=C2=A0=20
The building and home application spaces (and maybe others) have=20
a few clearly defined requirements.=20
It is not obvious to me how the current RPL proposal (cRPLp) can=20
satisfy those requirements:=20
=C2=A0=20
=C2=A0=20
In both cases it is the worst case scenario that hurts:=20
=C2=A0=20
=C2=A0=20
P2P routing inside the PAN=20
=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=20
cRPLp has no way of routing inside the PAN if you need more than=20
one repeater. cRPLp has to go all the way to the top (maybe 4 hops up)=20
and down again (maybe 4 hops down) to get just 2 hops to the side.=20
=C2=A0=20
The consequence is high latency and high levels of background noise=20
for nodes just outside the direct radio range.=20
At the same time the risk of meeting a failing link is 4 times higher =3D=
>=20
latency may be much more than 4 times larger.=20
=C2=A0=20
Latency may sound like a minor issue but it actually translates directly =

into lower battery lifetime. In the above (very realistic) example,=20
the battery lifetime is reduced to 25% of what it should be.=20
=C2=A0=20
We have lots of battery devices sending into the network:=20
* PIR sensors turning on lights=20
* Door locks sending alarms=20
* Door/window sensors starting chimes=20
* Smoke sensors triggering an alarm system=20
=C2=A0=20
=C2=A0=20
=C2=A0=20
=C2=A0=20
Response time=20
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=20
The latency issue is important.=20
When a user (real human being) presses a light button the user expects=20
the light to turn on.=20
cRPLp proposes that nodes in the tree periodically advertises their=20
presence using DAOs.=20
The periodicity is a real beast:=20
Thanks to Trickle, the rate of updates in a (apparently) stable network=20
is low. This is good since it leaves bandwidth for data.=20
But it is not good if existing routes to my lamp fail and I do not get=20
new routes to my lamp until it decides to send out a new DAO.=20
My user will (with a good reason) not tolerate waiting for minutes for=20
the light to turn on.=20
=C2=A0=20
I have met two arguments to counter this concern:=20
=C2=A0=20
A1: Well, your lamp can always send a DAO when it detects a problem.=20
=C2=A0 My answer:=20
=C2=A0 True, except that my lamp does not intend to send anything=20
=C2=A0 so it will never experience any problems from its side of the netw=
ork.=20
=C2=A0=20
A2: Well, you can increase the DAO rate to sub-second updates.=20
=C2=A0 My answer:=20
=C2=A0 Oh no. I get a very high degree of management traffic which=20
=C2=A0 limits my available bandwidth, increases the risk of collisions an=
d=20
=C2=A0 even run the risk of violating EU legislation requiring me to only=
=20
=C2=A0 transmit in less than 1% of the time:=20
=C2=A0 http://focus.ti.com/lit/an/swra048/swra048.pdf=20
=C2=A0868 - 868.6 MHz: <1%=20
=C2=A0=20
=C2=A0 Reactiveness is hard to achieve via polling.=20
=C2=A0=20
=C2=A0=20
=C2=A0=20
If you agree that this seems to be critical issues please raise your=20
voice on the list.=20
=C2=A0=20
Going forward=20
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=20
=C2=A0=20
We need some reactive mechanism to reach lamps before the user decides=20
to sue our companies.=20
So is this possible? I think so.=20

Existing commercial (non-IP) solutions are capable of re-routing quickly =

if they really have to.=20
=C2=A0=20
Let me try scoping the requirements to a potential solution:=20
(no different from the req. docs for home and building)=20
=C2=A0=20
* P2P routing in any direction independent of the tree.=20
=C2=A0=20
* On-demand P2P route discovery if requested by a real-time critical app.=
=20
=C2=A0Data collection apps may be able to just wait for the next DAO upda=
te.=20
=C2=A0=20
* Limited range of discovery mechanism: max 4 repeaters.=20
=C2=A0 A TTL field may limit the scope of the repeaters.=20
=C2=A0=20
* Suboptimal routing and traffic bursts are accepted in exchange=20
=C2=A0 for quick route repair. But only as an exception.=20
=C2=A0=20
=C2=A0=20
Just as an example, one existing home control technology uses a=20
(source routing) variant of AODV for quick route repair.=20
Nothing comes for free. The price is flooding - but not just flooding:=20
Managed flooding using a distributed algorithm running in all=20
participating nodes.=20
The algorithm dampens the flooding in a time, volume and range perspectiv=
e.=20
Some similar mechanism could be built into RPL for quick route repair.=20
=C2=A0=20
=C2=A0=20
If anyone have alternative proposals, please bring it to the list.=20
Now is the time.=20
=C2=A0=20
=C2=A0=20
=C2=A0=20
Thanks,=20
=C2=A0 Anders=20




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




=C2=A0=20
=C2=A0 _______________________________________________ Roll mailing list =
Roll@=
ietf.org https://www.ietf.org/mailman/listinfo/roll=
 =C2=A0=20
_______________________________________________
Roll mailing list
Roll@=
ietf.org
https://www.ietf.org/mailman/listinfo/roll
--------------060800090205050407070504-- --------------ms010206030802000101080601 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 GgUAoIIB0DAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMDAz MTkxNTM3NTBaMCMGCSqGSIb3DQEJBDEWBBTsn8tnAwU1drAQlvuXWgNy5KOxYjBfBgkqhkiG 9w0BCQ8xUjBQMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYI KoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgYUGCSsGAQQBgjcQBDF4MHYw YjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4x LDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhB0FYYcRpgg E7/iD53vjpAfMIGHBgsqhkiG9w0BCRACCzF4oHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoT HFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25h bCBGcmVlbWFpbCBJc3N1aW5nIENBAhB0FYYcRpggE7/iD53vjpAfMA0GCSqGSIb3DQEBAQUA BIIBACZdgD3kURe+2h7/qiWpP5kDPJZVGUxHJhUMT4OBLYvAJLrQU+yHasYtjq+KokK3nt0W EG8rZ51Kq7XV+0G08Z4nt4+cNU/JApdA2vtnBuKg67sJLgVfw8Hx9Bg/4FB93mCoq2w0CNqo agn3BCqYIwKdQavuTzRVFNLViANpFj6KAiRZoL1e8I9/cuyyFoszOW8ogkO97o/cFqO3XCmd ulParnrX98CbMK/Xhx9XUocHSGYsZ/s5ino7tG1OJL4FnUJAqeGgNMEkqV4m43rowoAJIDG3 F488/LDqw54lvV5cES9ZhTr+rTE9vdXG9lfEg5hrQChJWqzXPqYc0fyveC4AAAAAAAA= --------------ms010206030802000101080601-- From pthubert@cisco.com Fri Mar 19 09: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 7DB843A6ACD for ; Fri, 19 Mar 2010 09:20:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.403 X-Spam-Level: X-Spam-Status: No, score=-8.403 tagged_above=-999 required=5 tests=[AWL=1.066, 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 79s4vzvEWZJx for ; Fri, 19 Mar 2010 09:20:51 -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 B666C3A6A40 for ; Fri, 19 Mar 2010 09:20:50 -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: AjoBAIdBo0uQ/uCWe2dsb2JhbACDCpdKZhYBCwskBhyhYogxkFCBLIJkagSOUg X-IronPort-AV: E=Sophos;i="4.51,275,1267401600"; d="scan'208";a="58297227" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 19 Mar 2010 16:21:02 +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 o2JGL2RT025846; Fri, 19 Mar 2010 16:21:02 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, 19 Mar 2010 17:21:02 +0100 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, 19 Mar 2010 17:20:58 +0100 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D01793172@XMB-AMS-107.cisco.com> In-Reply-To: <836717245.7606741268982546867.JavaMail.root@mail02.pantherlink.uwm.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] P2P performance with current RPL proposal Thread-Index: AcrHMyXltxfvaHHfTWi9EZDIKP+ZgQASI26g References: <6A2A459175DABE4BB11DE2026AA50A5D01792E48@XMB-AMS-107.cisco.com> <836717245.7606741268982546867.JavaMail.root@mail02.pantherlink.uwm.edu> From: "Pascal Thubert (pthubert)" To: "Mukul Goyal" X-OriginalArrivalTime: 19 Mar 2010 16:21:02.0297 (UTC) FILETIME=[2AE67C90:01CAC780] Cc: ROLL WG , Ted Humpal Subject: Re: [Roll] P2P performance with current RPL proposal X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Mar 2010 16:20:58 -0000 SGkgTXVrdWwNCj4gSGVyZSBJIGhhdmUgYXR0ZW1wdGVkIHRvIGZvcm11bGF0ZSBhIHNpbXBsZSBE ViBhbGdvcml0aG0gaW4gUlBML0RBRyB0ZXJtcy4NCj4gSSB3aWxsIGFwcHJlY2lhdGUgaXQgaWYg eW91IGNvdWxkIGxldCBtZSBrbm93IGFib3V0IHlvdXIgb2JqZWN0aW9ucyB0byB0aGlzDQo+IHBy b3Bvc2FsOg0KDQpbUGFzY2FsXSBJdCdzIGNvb2wgdGhhdCB5b3UgZG8gaXQgaXMgdGhlIGZpcnN0 IGltcHJlc3Npb24uDQogDQo+IE5vZGUgQSBuZWVkcyB0byByZWFjaCBhIGRlc3RpbmF0aW9uIEQu IE5vZGUgQSBpbml0aWF0ZXMgYSBkaXNjb3ZlcnkgREFHDQo+IHRvd2FyZHMgRC4gQXMgdGhlIERJ T3MgcmVhY2ggRCwgaXQgc2VuZHMgYSBEQU8gYmFjayB0byBzZWxlY3RlZCBwYXJlbnRzLiBBcw0K PiB0aGUgREFPIHRyYXZlbHMgdG93YXJkcyBub2RlIEEsIGluLXJvdXRlIG5vZGVzIHN0b3JlIHRo ZSBjb3N0IHRvIHJlYWNoIEQuDQo+IA0KPiBXaGVuIG5vZGUgQiBuZWVkcyB0byByZWFjaCBELCBp dCBzaW1pbGFybHkgaW5pdGlhdGVzIGEgZGlzY292ZXJ5IGRhZy4gRHVyaW5nDQo+IHRoaXMgZGlz Y292ZXJ5LCB3aGVuIGEgRElPIHJlYWNoZXMgYSBub2RlIEMgdGhhdCBtYWludGFpbnMgYSBjb3N0 IHRvIHJlYWNoIEQsDQo+IG5vZGUgQyByZXNwb25kcyBiYWNrIHdpdGggYSBEQU8gdGhhdCB0cmF2 ZWxzIHRvd2FyZHMgQiBhbmQgc3RvcmVzIGluIGluLQ0KPiByb3V0ZSBub2RlcyB0aGUgY29zdCB0 byByZWFjaCBELg0KDQpbUGFzY2FsXSAgdW5kZXJzdGFuZCB0aGF0IHlvdSdyZSB0cnlpbmcgdG8g bWFrZSBSUEwgZXZlbiBjbG9zZXIgdG8gQU9EVi4NCkkgYWdyZWUgd2UgbmVlZCB0byBnYXRoZXIg YXMgbXVjaCBhcyB3ZSBjYW4gZnJvbSB0aGF0IHdvcmsuIA0KDQpGb3IgdGhlIHNwZWNpZmljcyBv ZiB5b3VyIHByb3Bvc2FsOg0KDQotIEItQyBtaWdodCBiZSBvcnRob2dvbmFsIHRvIEEtRCBzbyB0 aGF0IEIvQ1xEIGZvcm1zIGFuIGFuZ2xlLiBZb3UgZG8gbm90IGVuZCB1cCB3aXRoIHRoZSBiZXN0 IHBhdGggdGhhdCB5b3UncmUgbG9va2luZyBmb3IuDQoNCi0gdGhlcmUgbWlnaHQgYmUgbXVsdGlw bGUgQydzLiBXaGljaCBvbmUgaXMgdGhlIHJpZ2h0IG9uZT8NCg0KLSBSUEwgZG9lcyBub3QgYWxs b3cgcGFja2V0cyB0byBzd2l0Y2ggaW5zdGFuY2VzLiBGb2xsb3dpbmcgbXVsdGlwbGUgREFHcyBp cyB0aGUgcmVjaXBlIGZvciBsb29wcyAtIHVubGVzcyB5b3UgaGF2ZSB0aGVtIHN0cmljdGx5IG9y ZGVyZWQgYnkgc29tZSBtZWFucyBsaWtlIHRoZSBSUEwgc2VxdWVuY2UgYmV0d2VlbiBpdGVyYXRp b25zLCBtb3JlIHNwZWNpZmljIHJvdXRlcywgYmxhaCBibGFoLi4uKQ0KDQotIHRoZSBBIHRvIEQg cGF0aCBpcyBvcHRpbWl6ZWQgZm9yIGEgY2VydGFpbiBjb25zdHJhaW50LiBZb3Ugc2VlbSB0byBp bXBseSB0aGF0IHRoZSBCIHRvIEQgcGF0aCBoYXMgdGhlIHNhbWUgY29uc3RyYWludHMgYW5kIG1l dHJpY3Mgc28gd2UgY2FuIGNvbXBhcmUgYXBwbGUgdG8gYXBwbGUuIEJlY2F1c2UgdGhpcyBpcyBh IHZlcnkgZGVsaWNhdGUgb3BlcmF0aW9uLCBSUEwgaGFzIGludHJvZHVjZWQgdGhlIFJhbmssIHdo aWNoIGhhcyB0aGUgcmlnaHQgcHJvcGVydGllcyB0byBtYWtlIHRoYXQgY29tcGFyaXNvbiBlZmZp Y2llbnRseS5TbyBmb3IgUlBMLCB0aGUgbG9vcCBhdm9pZGFuY2UgbWV0cmljIGlzIHRoZSBSYW5r LCBhbmQgaXQgaXMgb25seSB2YWxpZCB3aXRoaW4gYW4gaXRlcmF0aW9uLg0KDQotIEEgUDJQIHBh dGggZG9lcyBub3QgY29tZSBvdXQgb2YgdGhlIGJsdWUuIFRoZXJlIG11c3QgYmUgc29tZSBwcm92 aXNpb25uaW5nIHN5c3RlbSB0aGF0IGRldGVybWluZXMgdGhhdCB0aG9zZSBub2RlcywgQSBhbmQg QiwgYXJlIHZlcnkgc3BlY2lhbCBzbyB0aGV5IG5lZWQgYSBQMlAgb3B0aW1pemF0aW9uLCB3aXRo IGEgZ2l2ZW4gc3BlY2lhbCBPRiwgYW5kIHRoYXQgdGhleSBib3RoIG5lZWQgdG8gdGFsayB0byBE LiBXZWxsLCBpZiB0aGF0J3Mgc28sIHRoZSBtb3N0IGVjb25vbWljYWwgaXMgZm9yIHRoYXQgc3lz dGVtIHRvIGZvcmsgdGhlIERBRyBvdXQgb2YgRCwgd2l0aCBkdWFsIHRhcmdldHMgQSBhbmQgQi4g VGhlcmUgeW91IG9idGFpbiB0aGUgc2hvcnRlc3QgcGF0aCBmb3IgYm90aCBBLUQgYW5kIEItRCBm b3IgdGhlIGNvc3Qgb2YgYSBzaW5nbGUgZmxvb2RpbmcuDQoNCkkgc2VlIHRoYXQgeW91J3JlIHRy eWluZyB0byBnZXQgdGhlIGlkZWEgdG8gd29yayBiZXR0ZXIsIGFuZCBJIGhvcGUgd2UgZmluZCBh IHdheSB0byBkbyBzbywgbWF5YmUgYWxvbmcgeW91ciBsaW5lcyBpZiB3ZSBjYW4gc29sdmUgdGhl IGlzc3VlcyBhYm92ZS4gQnV0IGJlZm9yZSB3ZSBnZXQgdGhlcmUsIHdlIG5lZWQgdG8gYWdyZWUg dGhhdCB0aGlzIGlzIHRoZSBwYXRoIHdlIHdpc2ggdG8gdGFrZS4NCg0KQ2hlZXJzLA0KDQpQYXNj YWwNCg0KIA0KPiANCj4gLS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLQ0KPiBGcm9tOiAiUGFz Y2FsIFRodWJlcnQgKHB0aHViZXJ0KSIgPHB0aHViZXJ0QGNpc2NvLmNvbT4NCj4gVG86ICJyb2Jl cnQgY3JhZ2llIiA8cm9iZXJ0LmNyYWdpZUBncmlkbWVyZ2UuY29tPg0KPiBDYzogIlJPTEwgV0ci IDxyb2xsQGlldGYub3JnPiwgIlRlZCBIdW1wYWwiIDxUZWQuSHVtcGFsQGpjaS5jb20+DQo+IFNl bnQ6IFRodXJzZGF5LCBNYXJjaCAxOCwgMjAxMCA5OjIzOjE0IFBNIEdNVCAtMDY6MDAgVVMvQ2Fu YWRhIENlbnRyYWwNCj4gU3ViamVjdDogUmU6IFtSb2xsXSBQMlAgcGVyZm9ybWFuY2Ugd2l0aCBj dXJyZW50IFJQTCBwcm9wb3NhbA0KPiANCj4gDQo+IA0KPiANCj4gDQo+IEhpIFJvYmVydMKgOg0K PiANCj4gDQo+IA0KPiBBdCBsZWFzdCBmcm9tIGEgZGlzdGFuY2UsIHRoZSBwcm9wb3NlZCBtZWNo YW5pc20gZW11bGF0ZXMgQU9EViwgd2l0aCB0aGUNCj4gRElPIGFzIFJSRVEgYW5kIHRoZSBEQU8g YXMgUlJFUC4gU28gaWYgd2UgZGVjaWRlIHRvIGRpZyBhbG9uZyB0aG9zZSBsaW5lcywNCj4gd2Xi gJlsbCBjZXJ0YWlubHkgYXBwcmVjaWF0ZSBoZWxwIGZyb20gTUFORVQgZXhwZXJ0cy4gSeKAmWQg c2F5IHRoYXQgaWYgeW91DQo+IGFscmVhZHkgaGF2ZSBSUEwgZm9yIFAyTVAgYW5kIE1QMlAsIHRo ZSBwcm9wb3NlZCBleHRlbnNpb24gYXJlIHByb2JhYmx5DQo+IHNpbXBsZXIgdG8gYWRkIHRoYW4g ZG9pbmcgQU9EViBmcm9tIHNjcmF0Y2guDQo+IA0KPiANCj4gDQo+IEZvciB0aGUgc2V0dXAsIHRo ZSBtYWpvciBkaWZmZXJlbmNlcyBhcmUgdGhhdCB3ZSBidWlsZCBhIERBRyBhbmQgdGhhdCB3ZSBj YW4NCj4gaW5kaWNhdGUgbXVsdGlwbGUgdGFyZ2V0cy4gSWYgeW91IGxvb2sgYXQgaXQsIHRoZSBE QUcgY2FwYWJpbGl0eSBpcyBhIE1VU1QgZm9yDQo+IFJQTCwgYW5kIEkgaGF2ZSBub3Qgc2VlbiB0 aGF0IHRoaXMgTVVTVCBnb2VzIGF3YXkgZm9yIFAyUCBmbG93cy4gVGhlDQo+IG11bHRpcGxlIHRh cmdldHMgaXMgc29tZXRoaW5nIHRoYXQgYXBwZWFycyBpbiBhIG51bWJlciBvZiB1c2UgY2FzZXMg YW5kIGl0DQo+IHNlZW1zIG1vcmUgZWNvbm9taWNhbCB0byBidWlsZCBhIHNpbmdsZSBEQUcgZm9y IG11bHRpcGxlIHRhcmdldHMgd2hlbg0KPiBwb3NzaWJsZS4NCj4gDQo+IA0KPiANCj4gRm9yIHRo ZSBtYWludGVuYW5jZSwgdGhlIG1ham9yIGRpZmZlcmVuY2VzIGFyZSB0aGF0IHdlIGhhdmUgdGhl IERBRyBhcw0KPiBmaXJzdCBsaW5lIG9mIGRlZmVuc2UsIGFuZCB0aGUgUlBMIGRldGVjdGlvbiB0 byBzdGltdWxhdGUgdGhlIGxvY2FsIHJlcGFpci4NCj4gDQo+IA0KPiANCj4gQWJvdXQgeW91ciBx dWVzdGlvbnM6DQo+IA0KPiANCj4gDQo+IFRoZSBET0RBRyByb290IGlzIHRoZSBvbmUgdGhhdCBz cGF3bnMgdGhlIERBRy4gVGhlIHRhcmdldHMgY2FuIHJlYWNoIHRoZQ0KPiByb290IGJlY2F1c2Ug dGhlIHJvb3QgYWR2ZXJ0aXNlcyBpdHNlbGYgaW4gdGhlIERJTy4gVGhlIGlkZWEgaXMgdGhhdCB0 aGUgcm9vdCBJRA0KPiBpcyB0aGUgYWRkcmVzcyB0aGF0IHRoZSB0YXJnZXRzIG5lZWQgdG8gdGFs ayB0by4gSWYgbmVlZGVkLCB0aGUgcm9vdCBjYW4gYWxzbw0KPiBhZHZlcnRpc2UgYSBwcmVmaXgg dGhhdCBpdCBjYW4gcmVhY2ggYW5kIHRoYXQgdGhlIHRhcmdldHMgbmVlZCB0byByZWFjaCB0b28u DQo+IA0KPiANCj4gDQo+IEFsbCB0aGUgaW50ZXJtZWRpYXRlIG5vZGVzIHRoYXQgYXJlIGNvbmZp cm1lZCBieSB0aGUgREFPIG5lZWQgdG8gcmV0YWluIGF0DQo+IGxlYXN0IGluZm8gYWJvdXQgdGhl IERBRy4gVGhhdCBlbmFibGVzIHRoZSB0YXJnZXRzIHRvIHJlYWNoIHRoZSByb290LiBUaGUNCj4g Zmxvb2Rpbmcgc2hvdWxkIGNvc3QgYWJvdXQgdGhlIHNhbWUgYXMgdGhhdCBvZiBBT0RWIGJ1dCB0 aGUgUlBMIHdheSB3aWxsDQo+IHJlcXVpcmUgbW9yZSBzdGF0ZXMgaW4gdGhlIG5vZGVzIG9uIHRo ZSB3YXkgaWYgdGhlIE9GIHJlcXVpcmVzIGEgREFHLg0KPiANCj4gDQo+IA0KPiBUaGUgd2F5IGJh Y2sgKGRvd24pIGNhbiBiZSBzdGF0ZWZ1bCBvZiBzdGF0ZWxlc3MsIGRlcGVuZGluZyBvbiB3aGlj aCBEQU8NCj4gd2XigJlyZSB1c2luZy4gV2l0aCBmdWxseSBzdGF0ZWZ1bCBEQU8sIHdlIGFyZSBy ZWFsbHkgaW4gQU9EVi1sYW5kLiBXaXRoDQo+IHN0YXRlbGVzcywgd2UgY291bGQgZHJpZnQgaW50 byBEU1ItbGFuZCBmb3IgdGhhdCBkaXJlY3Rpb24uIFdoaWNoIGxpbWl0cyB3ZQ0KPiBwbGFjZSB0 byBrZWVwIGl0IHNpbXBsZSB3aWxsIGJlIGRldGVybWluZWQgYnkgdGhlIHJlc29sdXRpb24gb2Yg aXNzdWUgIzI2IEkNCj4gZ3Vlc3PigKYNCj4gDQo+IA0KPiANCj4gQW5kIHBsZWFzZSwgbm8gYXBv bG9naXplIG9yIG9uIG9uZSB3aWxsIGRhcmUgcG9zdCBhbnl0aGluZyBhbnltb3JlLiBZb3VyDQo+ IHF1ZXN0aW9ucyBhcmUgZnVsbHkgcmVsZXZhbnQgYW5kIGF0IHRoZSBjb3JlIG9mIHRoZSBkaXNj dXNzaW9uLg0KPiANCj4gDQo+IA0KPiBJIGhvcGUgd2UgY2FuIHRhbGsgaW4gQW5haGVpbSBmb3Ig c3VyZSwNCj4gDQo+IA0KPiANCj4gDQo+IFBhc2NhbA0KPiANCj4gDQo+IA0KPiANCj4gDQo+IA0K PiBGcm9tOiBSb2JlcnQgQ3JhZ2llIFttYWlsdG86cm9iZXJ0LmNyYWdpZUBncmlkbWVyZ2UuY29t XQ0KPiBTZW50OiBNb25kYXksIE1hcmNoIDE1LCAyMDEwIDExOjI3IEFNDQo+IFRvOiBQYXNjYWwg VGh1YmVydCAocHRoIHViZXJ0KQ0KPiBDYzogVGVkLkh1bXBhbEBqY2kuY29tOyBST0xMIFdHDQo+ IFN1YmplY3Q6IFJlOiBbUm9sbF0gUDJQIHBlcmZvcm1hbmNlIHdpdGggY3VycmVudCBSUEwgcHJv cG9zYWwNCj4gDQo+IA0KPiANCj4gSGkgUGFzY2FsLA0KPiANCj4gU28gaW4geW91ciBzbGlkZXdh cmUgVCBjYW4gZW5kIHVwIHRhbGtpbmcgdG8gUiAoRE9EQUcgcm9vdCkgdGhyb3VnaCB0aGUNCj4g RE9EQUcuIFNvIGFyZSB5b3UgcHJvcG9zaW5nIHRoYXQgYWxsIHBvdGVudGlhbCB0YXJnZXRzIGNh biBhY3QgYXMgYSBET0RBRw0KPiByb290PyBBbmQgdGhlcmVmb3JlIGFsbCBpbnRlcm1lZGlhdGVz IGhhdmUgdG8gcmV0YWluIERJTyBwcm9wYWdhdGlvbg0KPiBzdXBwb3J0IGZvciB0aGF0IERPREFH IGFzIHdlbGw/IFRoaXMgbWF5IHdvcmsgZm9yIGxpbWl0ZWQgUDJQIGJ1dCBzZWVtcw0KPiBsZXNz IGVmZmljaWVudCB0aGFuIHNpbXBsZSBkaXN0YW5jZSB2ZWN0b3IgZmxvb2RpbmcgUlJFUS9SUkVQ IGxpa2UgQU9EViBvcg0KPiBEWU1PIGZvciBnZW5lcmljIFAyUC4gV2hhdCBhYm91dCBSIHRvIFQg KG9yIGFueW9uZSBlbHNlIGZvciB0aGF0IG1hdHRlcik/DQo+IERvIHdlIHNvdXJjZSByb3V0ZSwg bWFpbnRhaW4gc3RhdGUsIHNvbWUgdW5kZWZpbmVkIGh5YnJpZCBvZiB0aGUgdHdvPw0KPiANCj4g SSBhcG9sb2dpc2UgaWYgc29tZSBvZiB0aGVzZSBxdWVzdGlvbnMgaGF2ZSBiZWVuIGFuc3dlcmVk IGluIGRldGFpbCBpbiBlYXJsaWVyDQo+IHJlZmxlY3RvciBwb3N0cyBidXQgSSBoYXZlIG9ubHkg cmVjZW50bHkgc3RhcnRlZCB0byBjb25jZW50cmF0ZSBteSBlZmZvcnRzIG9uDQo+IFJQTCBhbmQg aGF2ZSA4MiBwYWdlcyB0byB3YWRlIHRocm91Z2ggOi0pLiBJIGxvb2sgZm9yd2FyZCB0byBhIHBy b2R1Y3RpdmUNCj4gc2Vzc2lvbiBpbiBBbmFoZWltLg0KPiANCj4gUm9iZXJ0DQo+IA0KPiANCj4g Um9iZXJ0IENyYWdpZSAoUGFjaWZpYyBHYXMgJiBFbGVjdHJpYykNCj4gDQo+IEdyaWRtZXJnZSBM dGQuDQo+IDg5IEdyZWVuZmllbGQgQ3Jlc2NlbnQsDQo+IFdha2VmaWVsZCwgV0Y0IDRXQSwgVUsN Cj4gKzQ0ICgwKSAxOTI0IDkxMDg4OA0KPiBodHRwOi8vd3d3LmdyaWRtZXJnZS5jb20NCj4gDQo+ IA0KPiANCj4gUGFzY2FsIFRodWJlcnQgKHB0aHViZXJ0KSB3cm90ZToNCj4gDQo+IEhJIFJvYmVy dMKgOg0KPiANCj4gDQo+IA0KPiBJIHJlc3BlY3RmdWxseSBoYXZlIHRvIGRpc2FncmVlLg0KPiAN Cj4gDQo+IA0KPiBNeSB1bmRlcnN0YW5kaW5nIGlzIHRoYXQgd2UgYXJlIGNvbnNpZGVyaW5nIGEg bGltaXRlZCBzZXQgb2YgUDJQIHBhaXJzLCBmb3INCj4gd2hpY2ggdGhlIHNwZWNpZmljIHBhdGgg dGhhdCB3ZSBuZWVkIHRvIGNyZWF0ZSBtaWdodCBoYXZlIHRvIG9iZXkgc3BlY2lmaWMNCj4gY29u c3RyYWludHMuDQo+IA0KPiBTbyBpdCBtYWtlcyBzZW5zZSB0byB1c2UgYW4gb24tZGVtYW5kIHRl Y2huaXF1ZSwgcHJvYmFibHkgaW5zcGlyZWQgYnkgdGhlDQo+IE1BTkVUIFJlYWN0aXZlIHByb3Rv Y29scy4NCj4gDQo+IA0KPiANCj4gQXMgaXQgZ29lcywgdGhvc2UgcHJvdG9jb2xzIHVzdWFsbHkg dXNlIGZsb29kaW5nIGZvciBhIG5vZGUgdG8gbG9jYXRlIGFub3RoZXIuDQo+IEZvcmtpbmcgYSBE QUcgaXMganVzdCBhbm90aGVyIGZsb29kaW5nLiBJdCBkb2VzIG5vdCB0YWtlIGEgbG90IG9mIGFk ZGl0aW9uIHRvIHRoZQ0KPiBleGlzdGluZyBESU8gZm9yIGEgcm9vdCB0byB1c2UgUlBMIHRvIGJ1 aWxkIGEgREFHIHRoYXQgY29udGFpbnMgb25lIG9yIG11bHRpcGxlDQo+IFRhcmdldHMgYXMgbGVh dmVzLCB1bmRlciBhIHNldCBvZiBjb25zdHJhaW50cyBleHByZXNzZWQgYXMgYW4gb2JqZWN0aXZl DQo+IGZ1bmN0aW9uLiBQbGVhc2UgZmluZCBhdHRhY2hlZCBhIHNsaWRld2FyZSB0aGF0IGlsbHVz dHJhdGVzIHRoYXQuDQo+IA0KPiANCj4gDQo+IA0KPiBQYXNjYWwNCj4gDQo+IA0KPiANCj4gDQo+ IA0KPiANCj4gRnJvbTogcm9sbC1ib3VuY2VzQGlldGYub3JnIFsgbWFpbHRvOnJvbGwtYm91bmNl c0BpZXRmLm9yZyBdIE9uIEJlaGFsZiBPZg0KPiBSb2JlcnQgQ3JhZ2llDQo+IFNlbnQ6IFRodXJz ZGF5LCBNYXJjaCAxMSwgMjAxMCAyOjQzIFBNDQo+IFRvOiBUZWQuSHVtcGFsQGpjaS5jb20NCj4g Q2M6IFJPTEwgV0cNCj4gU3ViamVjdDogUmU6IFtSb2xsXSBQMlAgcGVyZm9ybWFuY2Ugd2l0aCBj dXJyZW50IFJQTCBwcm9wb3NhbA0KPiANCj4gDQo+IA0KPiBJIGFncmVlIHdpdGggVGVkJ3MgY29t bWVudHMgYmVsb3cuIENyZWF0aW5nIGEgRE9EQUcgZm9yIGV2ZXJ5IHJlYWNoYWJsZQ0KPiBub2Rl IGFzIGEgcm9vdCBzZWVtcyBhIHZlcnkgaW5lZmZpY2llbnQgYXBwcm9hY2ggY29tcGFyZWQgdG8g YWx0ZXJuYXRpdmUNCj4gcm91dGluZyBhbGdvcml0aG1zLiBJIGFtIGNvbmNlcm5lZCB0aGF0IFJQ TCBkb2VzIG5vdCBhY3R1YWxseSBtZWV0IHRoZQ0KPiBvcmlnaW5hbCByZXF1aXJlbWVudHMgaW4g SS1ELmlldGYtcm9sbC1idWlsZGluZy1yb3V0aW5nLXJlcXMsIEktRC5pZXRmLXJvbGwtaG9tZS0N Cj4gcm91dGluZy1yZXFzLCBSRkM1NjczIGFuZCBSRkM1NTQ4LiBUaGUgdHJhZmZpYyBwYXR0ZXJu IHJlcXVpcmVtZW50IGZvciBhDQo+IHNpbmsgbm9kZSBmZWF0dXJlcyBwcm9taW5lbnRseSBpbiBv bmx5IHR3byBvZiB0aG9zZSBkb2N1bWVudHMuIEV2ZW4gaW4gdGhpcw0KPiBjYXNlLCBhcyBUZWQg cG9pbnRzIG91dCwgY29tbXVuaWNhdGlvbiBpcyBsaWtlbHkgdG8gYmUgYmlkaXJlY3Rpb25hbCAo ZS5nLiBlbmQtDQo+IHRvLWVuZCBhY2tzLikgdGhlcmVmb3JlIHRoZSBET0RBRyBhcHByb2FjaCBp cyBmdW5kYW1lbnRhbGx5IGFzeW1tZXRyaWMsDQo+IGVzcGVjaWFsbHkgaWYgbm8gaW50ZXJtZWRp YXRlIHN0b3JhZ2UgaXMgYWxsb3dlZCBmb3IgZGVzdGluYXRpb24gcm91dGVzIGFuZA0KPiBzb3Vy Y2Ugcm91dGluZyBoYXMgdG8gYmUgdXNlZC4NCj4gDQo+IEFsc28sIFJQTCBzZWVtcyBoaWdobHkg Y29tcGxleCBmb3Igd2hhdCBhcmUgY29uc3RyYWluZWQgbm9kZXMgaW4gdGVybXMgb2YNCj4gbWVt b3J5IGFzIHdlbGwgYXMgcG93ZXIgYW5kIGJhbmR3aWR0aC4gVGhlIFJQTCBkcmFmdCBhcyBpdCBz dGFuZHMgaXMgODINCj4gcGFnZXMgbG9uZyBhbmQgdGhhdCBkb2Vzbid0IGluY2x1ZGUgdGV4dCBh Ym91dCB0aGUgb2JqZWN0aXZlIGZ1bmN0aW9uLg0KPiANCj4gUm9iZXJ0DQo+IA0KPiANCj4gUm9i ZXJ0IENyYWdpZSAoUGFjaWZpYyBHYXMgJiBFbGVjdHJpYykNCj4gDQo+IEdyaWRtZXJnZSBMdGQu DQo+IDg5IEdyZWVuZmllbGQgQ3Jlc2NlbnQsDQo+IFdha2VmaWVsZCwgV0Y0IDRXQSwgVUsNCj4g KzQ0ICgwKSAxOTI0IDkxMDg4OA0KPiBodHRwOi8vd3d3LmdyaWRtZXJnZS5jb20NCj4gDQo+IA0K PiANCj4gVGVkLkh1bXBhbEBqY2kuY29tIHdyb3RlOg0KPiANCj4gDQo+IEEgY29uY2VybiBhbHNv IHdpbGwgYmUgaG93IG11Y2ggb3ZlcmhlYWQgKG1lbW9yeSBzcGFjZSkgd2lsbCBiZSByZXF1aXJl ZA0KPiBmb3IgYSBET0RBRyBSb290Pw0KPiANCj4gYW5kIGJhc2VkIG9uIHRoZSBmaXJzdCBxdWVz dGlvbiBob3cgbWFueSBET0RBRyByb290cyBhIGxhbXAgbWF5IG5lZWQgdG8NCj4gYmUgYSBtZW1i ZXIgb2Y/DQo+IA0KPiBGb3IgZXhhbXBsZSBpbiBsaWdodGluZyDCoGEgc2luZ2xlIGxhbXAgbWF5 IGJlIGEgcm9vdCBmb3IgYSBzaW5nbGUgc3dpdGNoICgxDQo+IERPREFHIHJvb3QpLCDCoHRoaXMg bGFtcCAvIGx1bWluYWlyZSBtYXkgYWxzbw0KPiBiZSBhIG1lbWJlciBvZiBhbm90aGVyIGdyb3Vw IC0gLSDCoHdoaWNoIGNvdWxkIGJlIGFsbCBsaWdodHMgb24gdGhlIGZsb29yICgybmQNCj4gRE9E QUcgcm9vdCksIGFuZCBhIHRoaXJkIGdyb3VwDQo+IG9mIGFsbCB0aGUgbGlnaHRzIGluIHRoZSBi dWlsZGluZy4gwqBUaGVyZSBjYW4gYmUgbWFueSBtb3JlIHNwZWNpYWxpdHkgZ3JvdXBzDQo+IGFz c29jaWF0ZWQgYmFzZWQgb24gdGhlIGJ1aWxkaW5nIGNvbmZpZ3VyYXRpb24uDQo+IENvbnNpZGVy IGFsc28gZHVyaW5nIHRoZSBpbnN0YWxsYXRpb24gdGltZSAtIGhvdyB0aGVzZSBET0RBRyByb290 cyB3aWxsIGJlDQo+IGNvbmZpZ3VyZWQ/IMKgTXVzdCBJIGNvbW1pc3Npb24gZWFjaCBkZXZpY2UN Cj4gdG8gdGVsbCBpdCB3aGljaCBET0RBRyBpdCBtdXN0IHVzZSBmb3IgaXRzIE9iamVjdCBGdW5j dGlvbj8gwqBIb3cgZWFzeSB3aWxsIHRoaXMNCj4gYmUgdG8gY2hhbmdlIGFuZCBhZGQgaW4gYSBu ZXcgRE9EQUcgcm9vdA0KPiBmb3IgdGhlIGVuZCB1c2VyIGlmIHRoZSBsaWdodGluZyBncm91cCBj aGFuZ2VzPz8NCj4gDQo+IFdpdGggcmVzcGVjdCB0byBKZXJyeSBNYXJ0b2NjaSdzIC0gY29tbWVy Y2lhbCBidWlsZGluZyByZXF1aXJlbWVudHMgLSBldmVyeQ0KPiBkZXZpY2UgbWF5IG5lZWQgdG8g Y29tbXVuaWNhdGUgdG8gYW55IG9yDQo+IGFsbCBvZiB0aGUgZW5kIGRldmljZXMuIMKgSWYgZWFj aCBkZXZpY2UgbXVzdCBlc3RhYmxpc2ggYSBET0RBRyBmb3IgdGhlIG90aGVyDQo+IDQ5OSBkZXZp Y2VzIGluIGEgNTAwIG5vZGUgbmV0d29yayAtIEhvdyBtdWNoIG1lbW9yeQ0KPiBzcGFjZSB3aWxs IHRoaXMgcmVxdWlyZSBmb3IgZWFjaCBlbmQgZGV2aWNlIHRvIG1haW50YWluPw0KPiANCj4gS2Vl cCBpbiBtaW5kIHRoYXQgdGhlIGVuZCBkZXZpY2VzIGFyZSB2ZXJ5IGxpbWl0ZWQgcHJvY2Vzc29y IGFuZCBtZW1vcnkNCj4gd2lzZS4NCj4gDQo+IE5vdCB0byBtZW50aW9uIGFsbCBvZiB0aGUgbmV0 d29yayBtYWludGVuYW5jZSBtZXNzYWdlcyB0aGF0IHdvdWxkIG5lZWQNCj4gdG8gYmUgdHJhbnNt aXR0ZWQgdG8gbWFpbnRhaW4gYWxsIG9mIHRoZXNlIERPREFHcy4NCj4gDQo+IENvbnNpZGVyIHRo ZSByZWNvbnZlcmdlbmNlIHRpbWUgd2hlbiBvbmUgZGV2aWNlIGlzIHR1cm5lZCBvZmYgYW5kIGl0 IHdhcyBpbg0KPiB0aGUgbWlkZGxlIG9mIHRoZSBtYWpvcml0eSBvZiB0aGUgMTAwKyBET0RBR1M/ DQo+IA0KPiBJbiBtYW55IGxpZ2h0aW5nIGFuZCBidWlsZGluZyBhcHBsaWNhdGlvbiBhbiBhcHBs aWNhdGlvbiBhY2tub3dsZWRnZW1lbnQgLQ0KPiBtdXN0IGJlIHJldHVybmVkIHtCYWNrIGRvd24g dGhlIERPREFHfSBzbyAuIC4gLiB0aGUNCj4gcmVxdWlyZW1lbnQgaXMgbm90IGp1c3QgZ2V0dGlu ZyB0byB0aGUgUm9vdCAtIGEgcmV0dXJuIHBhdGggbXVzdCBhbHNvIGJlDQo+IG1haW50YWluZWQg YW5kIGhhdmUgYSDCoGxvdyBsYXRlbmN5IHBhdGguDQo+IA0KPiBUZWQgSHVtcGFsDQo+IA0KPiAN Cj4gDQo+IA0KPiANCj4gDQo+IEZyb206DQo+IA0KPiBLcmlzIFBpc3RlciA8cGlzdGVyQGVlY3Mu YmVya2VsZXkuZWR1Pg0KPiANCj4gDQo+IFRvOg0KPiANCj4gQW5kZXJzIEJyYW5kdCA8YWJyQHNk ZXNpZ25zLmRrPg0KPiANCj4gDQo+IENjOg0KPiANCj4gUk9MTCBXRyA8cm9sbEBpZXRmLm9yZz4N Cj4gDQo+IA0KPiBEYXRlOg0KPiANCj4gMDMvMDgvMjAxMCAwMTo0NSBQTQ0KPiANCj4gDQo+IFN1 YmplY3Q6DQo+IA0KPiBSZTogW1JvbGxdIFAyUCBwZXJmb3JtYW5jZSB3aXRoIGN1cnJlbnQgUlBM IHByb3Bvc2FsDQo+IA0KPiANCj4gDQo+IA0KPiANCj4gDQo+IA0KPiANCj4gQW5kZXJzIC0gaWYg d2UgdGFrZSBKUCdzIHN1Z2dlc3Rpb24gdG8gbWFrZSBUaGUgTGFtcCBhIERPREFHIHJvb3QsIGFu ZA0KPiB0YWtlIFBob2VidXMnIHJlY29tbWVuZGF0aW9uIHRoYXQgd2UgdXNlIHBhdGggZGl2ZXJz aXR5IHRvIGltcHJvdmUgZW5kLQ0KPiB0by1lbmQgcmVsaWFiaWxpdHksIGRvIHlvdSBzZWUgYSBj aGFuY2Ugb2Ygc3VjY2Vzcz8NCj4gSW4gbXkgZXhwZXJpZW5jZSwgd2l0aCBkaXZlcnNlIHBhdGhz IGFuZCBvcmRlci1taW51dGVzIHVwZGF0ZXMgeW91IGdldA0KPiBleHRyZW1lbHkgaGlnaCByZWxp YWJpbGl0eS4NCj4gDQo+IEkgaGF2ZSBubyBhdmVyc2lvbiB0byBUVEwtbGltaXRlZCBmbG9vZHMg YXMgYSBwYXJ0IG9mIGEgc29sdXRpb24gZWl0aGVyLiDCoEknbQ0KPiBvcGVuIHRvIGlkZWFzIG9u IGhvdyB0byBicmluZyB0aG9zZSBpbiBhcyAocHJlc3VtYWJseSBpbmZyZXF1ZW50bHkgdXNlZCkN Cj4gb3B0aW9ucy4NCj4gDQo+IGtzanANCj4gDQo+IEFuZGVycyBCcmFuZHQgd3JvdGU6DQo+IEhl bGxvDQo+IA0KPiBJIHdvdWxkIGxpa2UgdG8gcHJvYmUgdGhlIHRlbXBlcmF0dXJlIG9mIHRoZSBX RyBvbiB1c2luZyBEQU9zIHRvDQo+IHN1cHBvcnQgUDJQLg0KPiANCj4gVGhlIGJ1aWxkaW5nIGFu ZCBob21lIGFwcGxpY2F0aW9uIHNwYWNlcyAoYW5kIG1heWJlIG90aGVycykgaGF2ZQ0KPiBhIGZl dyBjbGVhcmx5IGRlZmluZWQgcmVxdWlyZW1lbnRzLg0KPiBJdCBpcyBub3Qgb2J2aW91cyB0byBt ZSBob3cgdGhlIGN1cnJlbnQgUlBMIHByb3Bvc2FsIChjUlBMcCkgY2FuDQo+IHNhdGlzZnkgdGhv c2UgcmVxdWlyZW1lbnRzOg0KPiANCj4gDQo+IEluIGJvdGggY2FzZXMgaXQgaXMgdGhlIHdvcnN0 IGNhc2Ugc2NlbmFyaW8gdGhhdCBodXJ0czoNCj4gDQo+IA0KPiBQMlAgcm91dGluZyBpbnNpZGUg dGhlIFBBTg0KPiA9PT09PT09PT09PT09PT09PT09PT09PT09PQ0KPiBjUlBMcCBoYXMgbm8gd2F5 IG9mIHJvdXRpbmcgaW5zaWRlIHRoZSBQQU4gaWYgeW91IG5lZWQgbW9yZSB0aGFuDQo+IG9uZSBy ZXBlYXRlci4gY1JQTHAgaGFzIHRvIGdvIGFsbCB0aGUgd2F5IHRvIHRoZSB0b3AgKG1heWJlIDQg aG9wcyB1cCkNCj4gYW5kIGRvd24gYWdhaW4gKG1heWJlIDQgaG9wcyBkb3duKSB0byBnZXQganVz dCAyIGhvcHMgdG8gdGhlIHNpZGUuDQo+IA0KPiBUaGUgY29uc2VxdWVuY2UgaXMgaGlnaCBsYXRl bmN5IGFuZCBoaWdoIGxldmVscyBvZiBiYWNrZ3JvdW5kIG5vaXNlDQo+IGZvciBub2RlcyBqdXN0 IG91dHNpZGUgdGhlIGRpcmVjdCByYWRpbyByYW5nZS4NCj4gQXQgdGhlIHNhbWUgdGltZSB0aGUg cmlzayBvZiBtZWV0aW5nIGEgZmFpbGluZyBsaW5rIGlzIDQgdGltZXMgaGlnaGVyID0+DQo+IGxh dGVuY3kgbWF5IGJlIG11Y2ggbW9yZSB0aGFuIDQgdGltZXMgbGFyZ2VyLg0KPiANCj4gTGF0ZW5j eSBtYXkgc291bmQgbGlrZSBhIG1pbm9yIGlzc3VlIGJ1dCBpdCBhY3R1YWxseSB0cmFuc2xhdGVz IGRpcmVjdGx5DQo+IGludG8gbG93ZXIgYmF0dGVyeSBsaWZldGltZS4gSW4gdGhlIGFib3ZlICh2 ZXJ5IHJlYWxpc3RpYykgZXhhbXBsZSwNCj4gdGhlIGJhdHRlcnkgbGlmZXRpbWUgaXMgcmVkdWNl ZCB0byAyNSUgb2Ygd2hhdCBpdCBzaG91bGQgYmUuDQo+IA0KPiBXZSBoYXZlIGxvdHMgb2YgYmF0 dGVyeSBkZXZpY2VzIHNlbmRpbmcgaW50byB0aGUgbmV0d29yazoNCj4gKiBQSVIgc2Vuc29ycyB0 dXJuaW5nIG9uIGxpZ2h0cw0KPiAqIERvb3IgbG9ja3Mgc2VuZGluZyBhbGFybXMNCj4gKiBEb29y L3dpbmRvdyBzZW5zb3JzIHN0YXJ0aW5nIGNoaW1lcw0KPiAqIFNtb2tlIHNlbnNvcnMgdHJpZ2dl cmluZyBhbiBhbGFybSBzeXN0ZW0NCj4gDQo+IA0KPiANCj4gDQo+IFJlc3BvbnNlIHRpbWUNCj4g PT09PT09PT09PT09PQ0KPiBUaGUgbGF0ZW5jeSBpc3N1ZSBpcyBpbXBvcnRhbnQuDQo+IFdoZW4g YSB1c2VyIChyZWFsIGh1bWFuIGJlaW5nKSBwcmVzc2VzIGEgbGlnaHQgYnV0dG9uIHRoZSB1c2Vy IGV4cGVjdHMNCj4gdGhlIGxpZ2h0IHRvIHR1cm4gb24uDQo+IGNSUExwIHByb3Bvc2VzIHRoYXQg bm9kZXMgaW4gdGhlIHRyZWUgcGVyaW9kaWNhbGx5IGFkdmVydGlzZXMgdGhlaXINCj4gcHJlc2Vu Y2UgdXNpbmcgREFPcy4NCj4gVGhlIHBlcmlvZGljaXR5IGlzIGEgcmVhbCBiZWFzdDoNCj4gVGhh bmtzIHRvIFRyaWNrbGUsIHRoZSByYXRlIG9mIHVwZGF0ZXMgaW4gYSAoYXBwYXJlbnRseSkgc3Rh YmxlIG5ldHdvcmsNCj4gaXMgbG93LiBUaGlzIGlzIGdvb2Qgc2luY2UgaXQgbGVhdmVzIGJhbmR3 aWR0aCBmb3IgZGF0YS4NCj4gQnV0IGl0IGlzIG5vdCBnb29kIGlmIGV4aXN0aW5nIHJvdXRlcyB0 byBteSBsYW1wIGZhaWwgYW5kIEkgZG8gbm90IGdldA0KPiBuZXcgcm91dGVzIHRvIG15IGxhbXAg dW50aWwgaXQgZGVjaWRlcyB0byBzZW5kIG91dCBhIG5ldyBEQU8uDQo+IE15IHVzZXIgd2lsbCAo d2l0aCBhIGdvb2QgcmVhc29uKSBub3QgdG9sZXJhdGUgd2FpdGluZyBmb3IgbWludXRlcyBmb3IN Cj4gdGhlIGxpZ2h0IHRvIHR1cm4gb24uDQo+IA0KPiBJIGhhdmUgbWV0IHR3byBhcmd1bWVudHMg dG8gY291bnRlciB0aGlzIGNvbmNlcm46DQo+IA0KPiBBMTogV2VsbCwgeW91ciBsYW1wIGNhbiBh bHdheXMgc2VuZCBhIERBTyB3aGVuIGl0IGRldGVjdHMgYSBwcm9ibGVtLg0KPiDCoCBNeSBhbnN3 ZXI6DQo+IMKgIFRydWUsIGV4Y2VwdCB0aGF0IG15IGxhbXAgZG9lcyBub3QgaW50ZW5kIHRvIHNl bmQgYW55dGhpbmcNCj4gwqAgc28gaXQgd2lsbCBuZXZlciBleHBlcmllbmNlIGFueSBwcm9ibGVt cyBmcm9tIGl0cyBzaWRlIG9mIHRoZSBuZXR3b3JrLg0KPiANCj4gQTI6IFdlbGwsIHlvdSBjYW4g aW5jcmVhc2UgdGhlIERBTyByYXRlIHRvIHN1Yi1zZWNvbmQgdXBkYXRlcy4NCj4gwqAgTXkgYW5z d2VyOg0KPiDCoCBPaCBuby4gSSBnZXQgYSB2ZXJ5IGhpZ2ggZGVncmVlIG9mIG1hbmFnZW1lbnQg dHJhZmZpYyB3aGljaA0KPiDCoCBsaW1pdHMgbXkgYXZhaWxhYmxlIGJhbmR3aWR0aCwgaW5jcmVh c2VzIHRoZSByaXNrIG9mIGNvbGxpc2lvbnMgYW5kDQo+IMKgIGV2ZW4gcnVuIHRoZSByaXNrIG9m IHZpb2xhdGluZyBFVSBsZWdpc2xhdGlvbiByZXF1aXJpbmcgbWUgdG8gb25seQ0KPiDCoCB0cmFu c21pdCBpbiBsZXNzIHRoYW4gMSUgb2YgdGhlIHRpbWU6DQo+IMKgIGh0dHA6Ly9mb2N1cy50aS5j b20vbGl0L2FuL3N3cmEwNDgvc3dyYTA0OC5wZGYNCj4gwqA4NjggLSA4NjguNiBNSHo6IDwxJQ0K PiANCj4gwqAgUmVhY3RpdmVuZXNzIGlzIGhhcmQgdG8gYWNoaWV2ZSB2aWEgcG9sbGluZy4NCj4g DQo+IA0KPiANCj4gSWYgeW91IGFncmVlIHRoYXQgdGhpcyBzZWVtcyB0byBiZSBjcml0aWNhbCBp c3N1ZXMgcGxlYXNlIHJhaXNlIHlvdXINCj4gdm9pY2Ugb24gdGhlIGxpc3QuDQo+IA0KPiBHb2lu ZyBmb3J3YXJkDQo+ID09PT09PT09PT09PT0NCj4gDQo+IFdlIG5lZWQgc29tZSByZWFjdGl2ZSBt ZWNoYW5pc20gdG8gcmVhY2ggbGFtcHMgYmVmb3JlIHRoZSB1c2VyIGRlY2lkZXMNCj4gdG8gc3Vl IG91ciBjb21wYW5pZXMuDQo+IFNvIGlzIHRoaXMgcG9zc2libGU/IEkgdGhpbmsgc28uDQo+IA0K PiBFeGlzdGluZyBjb21tZXJjaWFsIChub24tSVApIHNvbHV0aW9ucyBhcmUgY2FwYWJsZSBvZiBy ZS1yb3V0aW5nIHF1aWNrbHkNCj4gaWYgdGhleSByZWFsbHkgaGF2ZSB0by4NCj4gDQo+IExldCBt ZSB0cnkgc2NvcGluZyB0aGUgcmVxdWlyZW1lbnRzIHRvIGEgcG90ZW50aWFsIHNvbHV0aW9uOg0K PiAobm8gZGlmZmVyZW50IGZyb20gdGhlIHJlcS4gZG9jcyBmb3IgaG9tZSBhbmQgYnVpbGRpbmcp DQo+IA0KPiAqIFAyUCByb3V0aW5nIGluIGFueSBkaXJlY3Rpb24gaW5kZXBlbmRlbnQgb2YgdGhl IHRyZWUuDQo+IA0KPiAqIE9uLWRlbWFuZCBQMlAgcm91dGUgZGlzY292ZXJ5IGlmIHJlcXVlc3Rl ZCBieSBhIHJlYWwtdGltZSBjcml0aWNhbCBhcHAuDQo+IMKgRGF0YSBjb2xsZWN0aW9uIGFwcHMg bWF5IGJlIGFibGUgdG8ganVzdCB3YWl0IGZvciB0aGUgbmV4dCBEQU8gdXBkYXRlLg0KPiANCj4g KiBMaW1pdGVkIHJhbmdlIG9mIGRpc2NvdmVyeSBtZWNoYW5pc206IG1heCA0IHJlcGVhdGVycy4N Cj4gwqAgQSBUVEwgZmllbGQgbWF5IGxpbWl0IHRoZSBzY29wZSBvZiB0aGUgcmVwZWF0ZXJzLg0K PiANCj4gKiBTdWJvcHRpbWFsIHJvdXRpbmcgYW5kIHRyYWZmaWMgYnVyc3RzIGFyZSBhY2NlcHRl ZCBpbiBleGNoYW5nZQ0KPiDCoCBmb3IgcXVpY2sgcm91dGUgcmVwYWlyLiBCdXQgb25seSBhcyBh biBleGNlcHRpb24uDQo+IA0KPiANCj4gSnVzdCBhcyBhbiBleGFtcGxlLCBvbmUgZXhpc3Rpbmcg aG9tZSBjb250cm9sIHRlY2hub2xvZ3kgdXNlcyBhDQo+IChzb3VyY2Ugcm91dGluZykgdmFyaWFu dCBvZiBBT0RWIGZvciBxdWljayByb3V0ZSByZXBhaXIuDQo+IE5vdGhpbmcgY29tZXMgZm9yIGZy ZWUuIFRoZSBwcmljZSBpcyBmbG9vZGluZyAtIGJ1dCBub3QganVzdCBmbG9vZGluZzoNCj4gTWFu YWdlZCBmbG9vZGluZyB1c2luZyBhIGRpc3RyaWJ1dGVkIGFsZ29yaXRobSBydW5uaW5nIGluIGFs bA0KPiBwYXJ0aWNpcGF0aW5nIG5vZGVzLg0KPiBUaGUgYWxnb3JpdGhtIGRhbXBlbnMgdGhlIGZs b29kaW5nIGluIGEgdGltZSwgdm9sdW1lIGFuZCByYW5nZQ0KPiBwZXJzcGVjdGl2ZS4NCj4gU29t ZSBzaW1pbGFyIG1lY2hhbmlzbSBjb3VsZCBiZSBidWlsdCBpbnRvIFJQTCBmb3IgcXVpY2sgcm91 dGUgcmVwYWlyLg0KPiANCj4gDQo+IElmIGFueW9uZSBoYXZlIGFsdGVybmF0aXZlIHByb3Bvc2Fs cywgcGxlYXNlIGJyaW5nIGl0IHRvIHRoZSBsaXN0Lg0KPiBOb3cgaXMgdGhlIHRpbWUuDQo+IA0K PiANCj4gDQo+IFRoYW5rcywNCj4gwqAgQW5kZXJzDQo+IA0KPiANCj4gDQo+IA0KPiBfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBSb2xsIG1haWxpbmcg bGlzdA0KPiBSb2xsQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vcm9sbA0KPiDCoF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fDQo+IFJvbGwgbWFpbGluZyBsaXN0DQo+IFJvbGxAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9yb2xsDQo+IA0KPiANCj4gDQo+IA0KPiANCj4g wqAgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18gUm9sbCBt YWlsaW5nDQo+IGxpc3QgUm9sbEBpZXRmLm9yZyBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL3JvbGwNCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18NCj4gUm9sbCBtYWlsaW5nIGxpc3QNCj4gUm9sbEBpZXRmLm9yZw0KPiBodHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3JvbGwNCg== From dominique.barthel@orange-ftgroup.com Fri Mar 19 10:45: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 063C93A68B2 for ; Fri, 19 Mar 2010 10:45:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.084 X-Spam-Level: X-Spam-Status: No, score=-1.084 tagged_above=-999 required=5 tests=[AWL=-2.165, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, HELO_EQ_FR=0.35, J_CHICKENPOX_32=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id skvRT5O-Qgoo for ; Fri, 19 Mar 2010 10:45:54 -0700 (PDT) Received: from p-mail1.rd.francetelecom.com (p-mail1.rd.francetelecom.com [195.101.245.15]) by core3.amsl.com (Postfix) with ESMTP id 9F5FE3A659A for ; Fri, 19 Mar 2010 10:45:53 -0700 (PDT) Received: from p-mail1.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 60D718B8006 for ; Fri, 19 Mar 2010 18:45:06 +0000 (UTC) Received: from ftrdsmtp2.rd.francetelecom.fr (unknown [10.192.128.47]) by p-mail1.rd.francetelecom.com (Postfix) with ESMTP id 5A7C18B8005 for ; Fri, 19 Mar 2010 18:45:06 +0000 (UTC) Received: from ftrdmel0.rd.francetelecom.fr ([10.192.128.56]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Fri, 19 Mar 2010 18:45:59 +0100 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, 19 Mar 2010 18:44:44 +0100 Message-ID: <8E09C72DBC577D489F13A71228C0B7BF010FEFE9@ftrdmel0.rd.francetelecom.fr> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Options in DIS Thread-Index: AcrHi9wWlpfHs1orQvmKxfkHFdpxbg== From: To: X-OriginalArrivalTime: 19 Mar 2010 17:45:59.0380 (UTC) FILETIME=[08FFA140:01CAC78C] Subject: [Roll] Options in DIS X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 19 Mar 2010 17:45:55 -0000 Hi all, I have already expressed a desire for options in the DIS packet http://www.ietf.org/mail-archive/web/roll/current/msg02765.html Jerry and Mukul expressed their support to the request. http://www.ietf.org/mail-archive/web/roll/current/msg02766.html http://www.ietf.org/mail-archive/web/roll/current/msg02770.html Then Phil asked for a justification for the request, which I admit I haven't provided yet. http://www.ietf.org/mail-archive/web/roll/current/msg02774.html More recently, Tzeta suggested that DIS have security options http://www.ietf.org/mail-archive/web/roll/current/msg03101.html Independently, Yaov and Matteo both again expressed the need for DIS option. http://www.ietf.org/mail-archive/web/roll/current/msg03185.html http://www.ietf.org/mail-archive/web/roll/current/msg03290.html I do believe we have a serious point here. Please find the justification below. Can we please have a ticket to work on it ? I volunteer to gather others contributors' opinions/requests and and propose detailed text to be included in future revisions of the RPL draft. Best, Dominique ------------------------------------------- The following is extracted from a typical water/gas smart metering infrastructure. The utility company worker adds new metering points into the network as meters are replaced or fitted with sensing/transmission electronics.=20 Before the worker leaves the premises, he/she is requested to check that the meter has actually joined the network. This cannot wait for a trickled-down DAO to arrive. Therefore, the meter will send a DIS to collect information from the network. Without DIS options, all neighbor routers will respond, spending energy for their own transmission and triggering energy expenditure in all neighbor nodes that overhear the responses. Let's consider a "wheel" model for the network topology, with a sink at the center and spokes connecting outward to ring-1 routers, ring-2 routers and periphery meters. The meters have routing capability themselves, although I'll call them meters in the following text to distinguish them from devices solely intended at providing connectivity, which I'll call routers. Let's consider a generic "pizza slice" of this wheel. Since there's central symmetry in the network, there's no border effect in the slice We typically have - one mains-powered sink at the center, - N severely energy-limited meters at the periphery, deeply burried into basements or manholes - N/20 fairly energy-limited ring-1 routers, located on high spots - N/10 fairly energy-limited ring-2 routers, located on high spots In RPL parlance, ring-1 routers would have a typical rank of 4, and ring-2 routers would have a typical rank of 8 The N/10 and N/20 ratios above are dictated by energy/lifetime considerations, not radio coverage. A typical connectivity is the following - each meter is in range of N/10 and N/20 routers, albeit with *very* different link qualities - each router is in range of N/10 and N/20 routers, with various link qualities=20 - each meter is in range of N/20 meters The ratios and assumptions above hold for values of N in the [20..200] range.=20 **** Without DIS options, we have NT0 =3D Number of DIS multicast transmission =3D 1 NR0 =3D Number of DIS active receptions =3D N/5 (due to N/20 meters and (N/10+N/20) routeurs),=20 NT1 =3D N/20 DIO transmissions from meters; each one being overheard by N/20 meters and (N/10+N/20) routers NT2 =3D N/10+N/20 DIO transmissions from routers; each one being = overheard by N meters and (N/10+N/20) routers NR1 ~=3D NT1 * (3N/20 + N/20) =3D N^2/100 =3D 0.01 * N^2 receptions due = to DIO coming from meters NR2 ~=3D NT2 * (N + N/20 + N/10) =3D N^2*69/400 =3D 0.17 * N^2 = receptions due to DIO coming from routers We therefore have Number of transmissions: NT =3D NT0 + NT1 + NT2 =3D 1 + N/20 + (N/10 + = N/20) =3D 24/20 * N =3D 1 + 0.2 * N Number of receptions : NR =3D NR0 + NR1 + NR2 =3D 0.2 * N + 0.18 * N^2 Total energy cost Etotal =3D NT * Et + NR * Er If the network is asynchronous and uses basic preamble sampling, the cost of overhearing Eo is the cost of receiving the expected duration (half) of the preamble. Since the DIS packet is small, its unit reception cost Er is about the same as the overhearing cost Eo. With a small (<1KB) DIO packet, the cost of transmission Et is essentially the cost of sending the preamble. Let's assume transmission cost Et is 6 times Eo (full preamble length accounts for x2, power consumption for x3) Etotal ~=3D Eo * ( 1 * 6 + N * (0.2 * 6 + 0.2) + 0.18 * N^2) ~=3D Eo * ( = 6 + 1.4 * N + 0.18 * N^2)=20 **** With DIS options A typical protocol currently in use in widely deployed proprietary smart metering networks is the following. Newborn nodes send successive DIS'es with decreasing demands on rank and link quality - iteration 1: only sinks, LQI >=3D 0,75*maxLQI - iteration 2: only sinks, LQI >=3D 0,5*maxLQI - iteration 3: only sinks, LQI >=3D 0,25*maxLQI - iteration 4: ring-1 routers, LQI >=3D 0,75*maxLQI, - iteration 5: ring-1 routers, LQI >=3D 0,50*maxLQI, - iteration 6: ring-1 routers, LQI >=3D 0,25*maxLQI, - iteration 7: ring-2 routers, LQI >=3D 0,75*maxLQI, - iteration 8: ring-2 routers, LQI >=3D 0,50*maxLQI, - iteration 9: ring-2 routers, LQI >=3D 0,25*maxLQI, - etc The newborn node will usually send several DIS's instead of just one. Its direct neighbors (N/20 meters, N/10+N/20 routers) will also incur the cost of receiving these extra DIS'es. Let's suppose iteration 7 is successful and prompts 25% of the neighbor ring-2 routers to send their DIOs. Number of DIS transmissions =3D 7 Number of DIS receptions =3D 7 * (N/20 + N/10 + N/20) =3D 7/5 * N Number of DIO transmissions =3D 25% of N/10 =3D N/40, overheard by 23/20 = * N nodes (N meters and N/10+N/20 routers). Number of DIOs overheard =3D 23/800 * N^2 =3D 0.029 * N^2 Etotal ~=3D Eo * ( 7*6 + N * ( 7/5 + 6/40) + 0.029 * N^2) ~=3D Eo * (42 = + 1.6 * N + 0.029 * N^2) In this case, the global energy cost of inserting a new node in the network is reduced by a factor ranging from 2 to 5 depending on N in [20..200]. Additional analysis shows that this saving affect both meters and routers (specifically, we are not pushing the burden towards the energy-critical meters). Similar results are obtained with differents iterations numbers. Just to re-inforce this calculation, it has been our experience that node insertion into a dense low-power network, if done wrong, is a significant energy drain. Please let us enhance RPL to do it right. From jhui@archrock.com Fri Mar 19 11:15: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 3E91C3A67D9 for ; Fri, 19 Mar 2010 11:15:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.618 X-Spam-Level: X-Spam-Status: No, score=-0.618 tagged_above=-999 required=5 tests=[AWL=-1.563, BAYES_40=-0.185, 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 RHmIsI4rwhZi for ; Fri, 19 Mar 2010 11:15:18 -0700 (PDT) Received: from mail.sf.archrock.com (mail.sf.archrock.com [216.121.16.71]) by core3.amsl.com (Postfix) with ESMTP id 273353A659B for ; Fri, 19 Mar 2010 11:15:17 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.sf.archrock.com (Postfix) with ESMTP id 71AC9AF99A for ; Fri, 19 Mar 2010 11:15:31 -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 DbR8N1+KGd5R for ; Fri, 19 Mar 2010 11:15:26 -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 C442CAF920 for ; Fri, 19 Mar 2010 11:15:26 -0700 (PDT) Message-Id: From: Jonathan Hui 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: Fri, 19 Mar 2010 11:15:25 -0700 X-Mailer: Apple Mail (2.936) Subject: [Roll] When source routing fails... X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 19 Mar 2010 18:15:19 -0000 ROLL WG, RPL-07 currently supports routers that do not maintain downward routing state. To route through these 'non-storing' nodes, it is expected that an ancestor node will maintain state about the downward routing topology and utilize source routing. When routing information no longer correctly reflects changes in link connectivity, a storing node may attempt to utilize a path that can no longer reach the intended destination. With source routing, the delivery failure may occur several hops away, or more generally anywhere between the storing node and the destination. RPL-07 currently does not make any attempt to specify what actions a non- storing node should take when using source route information fails. A few obvious actions are: 1) Drop the packet and nothing else. This is the most simple option and has the benefit that routing failures do not generate any extra traffic. Route repair timescales are dependent on control traffic rather than data traffic. 2) Drop the packet and send back an ICMPv6 error or RPL message indicating where the route failed. Allows quick notification to a storing node that route information is invalid. Route repair timescales are dependent on data traffic rather than control traffic. While this generates extra control traffic on link failures, the error/ repair messages can be small and constant size. Rate limiting can be used to bound error/repair message generation. 3) Backtrack by returning the packet towards the root and indicating where the route failed. Implements a form of depth-first search and gives the data packet another chance to reach its destination. Allows quick notification to a storing node that route information is invalid. Route repair on timescales are dependent on data traffic rather than control traffic. While this does not generate any extra control traffic per-se, data packets that experience source route failures can remain "live" within the network for extended periods of time. If these data packets or failures occur repeatedly, channel utilization can increase unexpectedly while data packets traverse up and down the DAG. 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. The per-packet option may be specified as part of the source route information or based on the payload (e.g. simply drop ICMPv6 errors but backtrack UDP datagrams). What are other people's thoughts? Are there additional pros/cons of the options above? Are there other options that we should consider? -- Jonathan Hui From mcr@sandelman.ca Fri Mar 19 12:14: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 80C2A3A6A21 for ; Fri, 19 Mar 2010 12:14:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.258 X-Spam-Level: X-Spam-Status: No, score=0.258 tagged_above=-999 required=5 tests=[AWL=-1.518, BAYES_50=0.001, 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 a-+wX-8xq9ID for ; Fri, 19 Mar 2010 12:14:22 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by core3.amsl.com (Postfix) with ESMTP id 98BAF3A6A34 for ; Fri, 19 Mar 2010 12:14:10 -0700 (PDT) Received: from sandelman.ottawa.on.ca (unknown [132.213.238.4]) by relay.sandelman.ca (Postfix) with ESMTPS id 1A96734726; Fri, 19 Mar 2010 15:11:03 -0400 (EDT) Received: from marajade.sandelman.ca (unknown [127.0.0.1]) by sandelman.ottawa.on.ca (Postfix) with ESMTP id 3E2314E7D6; Fri, 19 Mar 2010 15:14:21 -0400 (EDT) From: Michael Richardson To: Jonathan Hui In-Reply-To: References: X-Mailer: MH-E 8.1; nmh 1.1; XEmacs 21.4 (patch 21) Date: Fri, 19 Mar 2010 15:14:20 -0400 Message-ID: <28510.1269026060@marajade.sandelman.ca> Sender: mcr@sandelman.ca Cc: ROLL WG Subject: Re: [Roll] When source routing fails... X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 19 Mar 2010 19:14:23 -0000 >>>>> "Jonathan" == Jonathan Hui writes: Jonathan> ROLL WG, Jonathan> RPL-07 currently supports routers that do not maintain Jonathan> downward routing state. To route through these Jonathan> 'non-storing' nodes, it is expected that an ancestor node Jonathan> will maintain state about the downward routing topology Jonathan> and utilize source routing. ... Jonathan> A few obvious actions are: Jonathan> 1) Drop the packet and nothing else. This is the most Jonathan> simple option and has the benefit that routing failures do Jonathan> not generate any extra traffic. Route repair timescales Jonathan> are dependent on control traffic rather than data traffic. Jonathan> 2) Drop the packet and send back an ICMPv6 error or RPL Jonathan> message indicating where the route failed. Allows quick Jonathan> notification to a storing node that route information is Jonathan> invalid. Route repair timescales are dependent on data Jonathan> traffic rather than control traffic. While this generates Jonathan> extra control traffic on link failures, the error/ repair Jonathan> messages can be small and constant size. Rate limiting Jonathan> can be used to bound error/repair message generation. I'd like to make this a bit more fine-grained. 1a) drop the packet, do nothing else. (non-ordinary router behaviour) 1b) drop the packet, send ICMPv6 error message (normal router behaviour) 2) drop the packet, send RPL message (extra-ordinary RPL router mode) 3) backtrack mechanism, that I think is interesting, but I choose not to discuss right now. As you note: My vote is to send an RPL message --- such as a DAO -- which one would send anyway (advance the timer, but rate limit it). Send extra info in it. Jonathan> On a separate dimension, it is important to note that the Jonathan> above options are not mutually exclusive and we have the Jonathan> following options: Jonathan> 1) Specify only a single action when source route failures Jonathan> occur. Jonathan> 2) Provide an option that can select which action to take Jonathan> on a per- instance, per-dag, or per-packet basis. The Jonathan> per-packet option may be specified as part of the source Jonathan> route information or based on the payload (e.g. simply Jonathan> drop ICMPv6 errors but backtrack UDP datagrams). Some of this is really a local decision. Some of it is not. Jonathan> What are other people's thoughts? Are there additional Jonathan> pros/cons of the options above? Are there other options Jonathan> that we should consider? I dislike magic local knobs. I also dislike extra options in the processing. I especially dislike options in the packet forwarding path. SO: Not per-packet. Not per-dag. MAY per-instance. -- ] 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 jpv@cisco.com Fri Mar 19 13: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 9BC083A6922 for ; Fri, 19 Mar 2010 13:06:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.425 X-Spam-Level: X-Spam-Status: No, score=-9.425 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DATE_IN_PAST_03_06=0.044, 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 QcrwQTAF-1n5 for ; Fri, 19 Mar 2010 13:06: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 172BB3A694E for ; Fri, 19 Mar 2010 13:06:17 -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: Am4FAI51o0urR7H+/2dsb2JhbAAumxBzoTOYcYR6BA X-IronPort-AV: E=Sophos;i="4.51,276,1267401600"; d="scan'208";a="103065394" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-4.cisco.com with ESMTP; 19 Mar 2010 20:06:01 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o2JK61WY012197 for ; Fri, 19 Mar 2010 20:06:01 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 19 Mar 2010 13:06:01 -0700 Received: from sjcd-noc-cs3-con.cisco.com ([10.61.97.198]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 19 Mar 2010 13:06:01 -0700 Message-Id: <73057E8A-B3D2-42FA-B2C1-1C9BFD0F7E5E@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: Fri, 19 Mar 2010 15:51:49 +0100 X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 19 Mar 2010 20:06:01.0392 (UTC) FILETIME=[98FCEB00:01CAC79F] Subject: [Roll] Slides please X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 19 Mar 2010 20:06:20 -0000 Dear all, Please send your slides if you have a slot during the ROLL WG meeting on Monday no later than tomorrow. Thanks. JP. From d.sturek@att.net Fri Mar 19 17:23: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 830FE3A67B2 for ; Fri, 19 Mar 2010 17:23:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.107 X-Spam-Level: X-Spam-Status: No, score=-0.107 tagged_above=-999 required=5 tests=[AWL=-0.088, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, 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 mWWZ5S34E+ga for ; Fri, 19 Mar 2010 17:23:46 -0700 (PDT) Received: from smtp109.sbc.mail.mud.yahoo.com (smtp109.sbc.mail.mud.yahoo.com [68.142.198.205]) by core3.amsl.com (Postfix) with SMTP id 803FB3A65A6 for ; Fri, 19 Mar 2010 17:23:46 -0700 (PDT) Received: (qmail 8682 invoked from network); 20 Mar 2010 00:23:57 -0000 Received: from Studio (d.sturek@69.226.30.134 with login) by smtp109.sbc.mail.mud.yahoo.com with SMTP; 19 Mar 2010 17:23:56 -0700 PDT X-Yahoo-SMTP: fvjol_aswBAraSJvMLe2r1XTzhBhbFxY8q8c3jo- X-YMail-OSG: wCOGef0VM1nEJ8GLv83247mCEXNRSSL5cgktGBjiYo_2dtV8CdulKXEV5Hq4RO2NVyAhFim_ly_uFTOtB.c7kldM.U52Ip1x8jiTX.JNEr6S_GhDujzyc9r3muA72GwkGeFuYhkL2vxAynoIglp3zQIIfZLf4t86m9RnZ1HsmbPMXTEf2JovNGS24pf0DDMM3yRbnWTDnAcYcrcCfOLggKxntgaj4XM2SwEUVAfc7GP9T13LIr4ueLCZSYw2QPzq1EfqjygMGMa7VImkFovaucGQAJbi33l9_5ZWNupFklXJa2gMuC0- X-Yahoo-Newman-Property: ymail-3 From: "Don Sturek" To: "'Jonathan Hui'" , "'ROLL WG'" References: In-Reply-To: Date: Fri, 19 Mar 2010 17:23:53 -0700 Message-ID: <008601cac7c3$9fb4d920$df1e8b60$@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: AcrHkCtZ8BeuzohiSAyn1ll2nwrlSgAMyZLA Content-Language: en-us Subject: Re: [Roll] When source routing fails... 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, 20 Mar 2010 00:23:47 -0000 Hi Jonathan, For unreachable destinations, action 2 is best (Drop the packet and send back an ICMPv6 error or RPL message indicating where the route failed). I would prefer selection of a single action since this reduces options and complexity. Don -----Original Message----- From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Jonathan Hui Sent: Friday, March 19, 2010 11:15 AM To: ROLL WG Subject: [Roll] When source routing fails... ROLL WG, RPL-07 currently supports routers that do not maintain downward routing state. To route through these 'non-storing' nodes, it is expected that an ancestor node will maintain state about the downward routing topology and utilize source routing. When routing information no longer correctly reflects changes in link connectivity, a storing node may attempt to utilize a path that can no longer reach the intended destination. With source routing, the delivery failure may occur several hops away, or more generally anywhere between the storing node and the destination. RPL-07 currently does not make any attempt to specify what actions a non- storing node should take when using source route information fails. A few obvious actions are: 1) Drop the packet and nothing else. This is the most simple option and has the benefit that routing failures do not generate any extra traffic. Route repair timescales are dependent on control traffic rather than data traffic. 2) Drop the packet and send back an ICMPv6 error or RPL message indicating where the route failed. Allows quick notification to a storing node that route information is invalid. Route repair timescales are dependent on data traffic rather than control traffic. While this generates extra control traffic on link failures, the error/ repair messages can be small and constant size. Rate limiting can be used to bound error/repair message generation. 3) Backtrack by returning the packet towards the root and indicating where the route failed. Implements a form of depth-first search and gives the data packet another chance to reach its destination. Allows quick notification to a storing node that route information is invalid. Route repair on timescales are dependent on data traffic rather than control traffic. While this does not generate any extra control traffic per-se, data packets that experience source route failures can remain "live" within the network for extended periods of time. If these data packets or failures occur repeatedly, channel utilization can increase unexpectedly while data packets traverse up and down the DAG. 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. The per-packet option may be specified as part of the source route information or based on the payload (e.g. simply drop ICMPv6 errors but backtrack UDP datagrams). What are other people's thoughts? Are there additional pros/cons of the options above? Are there other options that we should consider? -- Jonathan Hui _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From abr@sdesigns.dk Sun Mar 21 01:00: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 411E13A67E6 for ; Sun, 21 Mar 2010 01:00:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.643 X-Spam-Level: X-Spam-Status: No, score=0.643 tagged_above=-999 required=5 tests=[AWL=-1.885, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OFrBzoNb0pFx for ; Sun, 21 Mar 2010 01:00:14 -0700 (PDT) Received: from mail.zen-sys.com (mail.zen-sys.com [195.215.56.170]) by core3.amsl.com (Postfix) with ESMTP id DE9D53A6781 for ; Sun, 21 Mar 2010 01:00:13 -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_01CAC8CC.92380AAE" Date: Sun, 21 Mar 2010 08:58:20 +0100 Message-ID: <6D9687E95918C04A8B30A7D6DA805A3E01AD45CC@zensys17.zensys.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] P2P performance with current RPL proposal Thread-Index: AcrHMyXltxfvaHHfTWi9EZDIKP+ZgQASI26gAFQknZM= References: <6A2A459175DABE4BB11DE2026AA50A5D01792E48@XMB-AMS-107.cisco.com><836717245.7606741268982546867.JavaMail.root@mail02.pantherlink.uwm.edu> <6A2A459175DABE4BB11DE2026AA50A5D01793172@XMB-AMS-107.cisco.com> From: "Anders Brandt" To: "Pascal Thubert (pthubert)" , "Mukul Goyal" Cc: ROLL WG , Ted Humpal Subject: Re: [Roll] P2P performance with current RPL proposal X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Mar 2010 08:00:26 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CAC8CC.92380AAE Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Pascal wrote: =20 >- A P2P path does not come out of the blue. There must be some = provisionning system that determines >that those nodes, A and B, are very special so they need a P2P = optimization, with a given special OF, >and that they both need to talk to D. Well, if=20 =20 I would claim that in a home control environment they have to come out = of the blue! I need application association and low-latency control to work beyond = direct range an my users have NO interest in setting up network rules for provisioning, etc. Sorry. =20 - Anders =20 ________________________________ Fra: roll-bounces@ietf.org p=E5 vegne af Pascal Thubert (pthubert) Sendt: fr 19-03-2010 17:20 Til: Mukul Goyal Cc: ROLL WG; Ted Humpal Emne: Re: [Roll] P2P performance with current RPL proposal Hi Mukul > Here I have attempted to formulate a simple DV algorithm in RPL/DAG = terms. > I will appreciate it if you could let me know about your objections to = this > proposal: [Pascal] It's cool that you do it is the first impression. > Node A needs to reach a destination D. Node A initiates a discovery = DAG > towards D. As the DIOs reach D, it sends a DAO back to selected = parents. As > the DAO travels towards node A, in-route nodes store the cost to reach = D. > > When node B needs to reach D, it similarly initiates a discovery dag. = During > this discovery, when a DIO reaches a node C that maintains a cost to = reach D, > node C responds back with a DAO that travels towards B and stores in = in- > route nodes the cost to reach D. [Pascal] understand that you're trying to make RPL even closer to AODV. I agree we need to gather as much as we can from that work. For the specifics of your proposal: - B-C might be orthogonal to A-D so that B/C\D forms an angle. You do = not end up with the best path that you're looking for. - there might be multiple C's. Which one is the right one? - RPL does not allow packets to switch instances. Following multiple = DAGs is the recipe for loops - unless you have them strictly ordered by = some means like the RPL sequence between iterations, more specific = routes, blah blah...) - the A to D path is optimized for a certain constraint. You seem to = imply that the B to D path has the same constraints and metrics so we = can compare apple to apple. Because this is a very delicate operation, = RPL has introduced the Rank, which has the right properties to make that = comparison efficiently.So for RPL, the loop avoidance metric is the = Rank, and it is only valid within an iteration. - A P2P path does not come out of the blue. There must be some = provisionning system that determines that those nodes, A and B, are very = special so they need a P2P optimization, with a given special OF, and = that they both need to talk to D. Well, if that's so, the most = economical is for that system to fork the DAG out of D, with dual = targets A and B. There you obtain the shortest path for both A-D and B-D = for the cost of a single flooding. I see that you're trying to get the idea to work better, and I hope we = find a way to do so, maybe along your lines if we can solve the issues = above. But before we get there, we need to agree that this is the path = we wish to take. Cheers, Pascal > > ----- Original Message ----- > From: "Pascal Thubert (pthubert)" > To: "robert cragie" > Cc: "ROLL WG" , "Ted Humpal" > Sent: Thursday, March 18, 2010 9:23:14 PM GMT -06:00 US/Canada Central > Subject: Re: [Roll] P2P performance with current RPL proposal > > > > > > Hi Robert : > > > > At least from a distance, the proposed mechanism emulates AODV, with = the > DIO as RREQ and the DAO as RREP. So if we decide to dig along those = lines, > we'll certainly appreciate help from MANET experts. I'd say that if = you > already have RPL for P2MP and MP2P, the proposed extension are = probably > simpler to add than doing AODV from scratch. > > > > For the setup, the major differences are that we build a DAG and that = we can > indicate multiple targets. If you look at it, the DAG capability is a = MUST for > RPL, and I have not seen that this MUST goes away for P2P flows. The > multiple targets is something that appears in a number of use cases = and it > seems more economical to build a single DAG for multiple targets when > possible. > > > > For the maintenance, the major differences are that we have the DAG as > first line of defense, and the RPL detection to stimulate the local = repair. > > > > About your questions: > > > > The DODAG root is the one that spawns the DAG. The targets can reach = the > root because the root advertises itself in the DIO. The idea is that = the root ID > is the address that the targets need to talk to. If needed, the root = can also > advertise a prefix that it can reach and that the targets need to = reach too. > > > > All the intermediate nodes that are confirmed by the DAO need to = retain at > least info about the DAG. That enables the targets to reach the root. = The > flooding should cost about the same as that of AODV but the RPL way = will > require more states in the nodes on the way if the OF requires a DAG. > > > > The way back (down) can be stateful of stateless, depending on which = DAO > we're using. With fully stateful DAO, we are really in AODV-land. With > stateless, we could drift into DSR-land for that direction. Which = limits we > place to keep it simple will be determined by the resolution of issue = #26 I > guess... > > > > And please, no apologize or on one will dare post anything anymore. = Your > questions are fully relevant and at the core of the discussion. > > > > I hope we can talk in Anaheim for sure, > > > > > Pascal > > > > > > > From: Robert Cragie [mailto:robert.cragie@gridmerge.com] > Sent: Monday, March 15, 2010 11:27 AM > To: Pascal Thubert (pth ubert) > Cc: Ted.Humpal@jci.com; ROLL WG > Subject: Re: [Roll] P2P performance with current RPL proposal > > > > Hi Pascal, > > So in your slideware T can end up talking to R (DODAG root) through = the > DODAG. So are you proposing that all potential targets can act as a = DODAG > root? And therefore all intermediates have to retain DIO propagation > support for that DODAG as well? This may work for limited P2P but = seems > less efficient than simple distance vector flooding RREQ/RREP like = AODV or > DYMO for generic P2P. What about R to T (or anyone else for that = matter)? > Do we source route, maintain state, some undefined hybrid of the two? > > I apologise if some of these questions have been answered in detail in = earlier > reflector posts but I have only recently started to concentrate my = efforts on > RPL and have 82 pages to wade through :-). I look forward to a = productive > session in Anaheim. > > Robert > > > Robert Cragie (Pacific Gas & Electric) > > Gridmerge Ltd. > 89 Greenfield Crescent, > Wakefield, WF4 4WA, UK > +44 (0) 1924 910888 > http://www.gridmerge.com =20 > > > > Pascal Thubert (pthubert) wrote: > > HI Robert : > > > > I respectfully have to disagree. > > > > My understanding is that we are considering a limited set of P2P = pairs, for > which the specific path that we need to create might have to obey = specific > constraints. > > So it makes sense to use an on-demand technique, probably inspired by = the > MANET Reactive protocols. > > > > As it goes, those protocols usually use flooding for a node to locate = another. > Forking a DAG is just another flooding. It does not take a lot of = addition to the > existing DIO for a root to use RPL to build a DAG that contains one or = multiple > Targets as leaves, under a set of constraints expressed as an = objective > function. Please find attached a slideware that illustrates that. > > > > > Pascal > > > > > > > From: roll-bounces@ietf.org [ mailto:roll-bounces@ietf.org ] On Behalf = Of > Robert Cragie > Sent: Thursday, March 11, 2010 2:43 PM > To: Ted.Humpal@jci.com > Cc: ROLL WG > Subject: Re: [Roll] P2P performance with current RPL proposal > > > > I agree with Ted's comments below. Creating a DODAG for every = reachable > node as a root seems a very inefficient approach compared to = alternative > routing algorithms. I am concerned that RPL does not actually meet the > original requirements in I-D.ietf-roll-building-routing-reqs, = I-D.ietf-roll-home- > routing-reqs, RFC5673 and RFC5548. The traffic pattern requirement for = a > sink node features prominently in only two of those documents. Even in = this > case, as Ted points out, communication is likely to be bidirectional = (e.g. end- > to-end acks.) therefore the DODAG approach is fundamentally = asymmetric, > especially if no intermediate storage is allowed for destination = routes and > source routing has to be used. > > Also, RPL seems highly complex for what are constrained nodes in terms = of > memory as well as power and bandwidth. The RPL draft as it stands is = 82 > pages long and that doesn't include text about the objective function. > > Robert > > > Robert Cragie (Pacific Gas & Electric) > > Gridmerge Ltd. > 89 Greenfield Crescent, > Wakefield, WF4 4WA, UK > +44 (0) 1924 910888 > http://www.gridmerge.com =20 > > > > Ted.Humpal@jci.com wrote: > > > A concern also will be how much overhead (memory space) will be = required > for a DODAG Root? > > and based on the first question how many DODAG roots a lamp may need = to > be a member of? > > For example in lighting a single lamp may be a root for a single = switch (1 > DODAG root), this lamp / luminaire may also > be a member of another group - - which could be all lights on the = floor (2nd > DODAG root), and a third group > of all the lights in the building. There can be many more speciality = groups > associated based on the building configuration. > Consider also during the installation time - how these DODAG roots = will be > configured? Must I commission each device > to tell it which DODAG it must use for its Object Function? How easy = will this > be to change and add in a new DODAG root > for the end user if the lighting group changes?? > > With respect to Jerry Martocci's - commercial building requirements - = every > device may need to communicate to any or > all of the end devices. If each device must establish a DODAG for the = other > 499 devices in a 500 node network - How much memory > space will this require for each end device to maintain? > > Keep in mind that the end devices are very limited processor and = memory > wise. > > Not to mention all of the network maintenance messages that would need > to be transmitted to maintain all of these DODAGs. > > Consider the reconvergence time when one device is turned off and it = was in > the middle of the majority of the 100+ DODAGS? > > In many lighting and building application an application = acknowledgement - > must be returned {Back down the DODAG} so . . . the > requirement is not just getting to the Root - a return path must also = be > maintained and have a low latency path. > > Ted Humpal > > > > > > > From: > > Kris Pister > > > To: > > Anders Brandt > > > Cc: > > ROLL WG > > > Date: > > 03/08/2010 01:45 PM > > > Subject: > > Re: [Roll] P2P performance with current RPL proposal > > > > > > > > > Anders - if we take JP's suggestion to make The Lamp a DODAG root, and > take Phoebus' recommendation that we use path diversity to improve = end- > to-end reliability, do you see a chance of success? > In my experience, with diverse paths and order-minutes updates you get > extremely high reliability. > > I have no aversion to TTL-limited floods as a part of a solution = either. I'm > open to ideas on how to bring those in as (presumably infrequently = used) > options. > > ksjp > > Anders Brandt wrote: > Hello > > I would like to probe the temperature of the WG on using DAOs to > support P2P. > > The building and home application spaces (and maybe others) have > a few clearly defined requirements. > It is not obvious to me how the current RPL proposal (cRPLp) can > satisfy those requirements: > > > In both cases it is the worst case scenario that hurts: > > > P2P routing inside the PAN > = =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 > cRPLp has no way of routing inside the PAN if you need more than > one repeater. cRPLp has to go all the way to the top (maybe 4 hops up) > and down again (maybe 4 hops down) to get just 2 hops to the side. > > The consequence is high latency and high levels of background noise > for nodes just outside the direct radio range. > At the same time the risk of meeting a failing link is 4 times higher = =3D> > latency may be much more than 4 times larger. > > Latency may sound like a minor issue but it actually translates = directly > into lower battery lifetime. In the above (very realistic) example, > the battery lifetime is reduced to 25% of what it should be. > > We have lots of battery devices sending into the network: > * PIR sensors turning on lights > * Door locks sending alarms > * Door/window sensors starting chimes > * Smoke sensors triggering an alarm system > > > > > Response time > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > The latency issue is important. > When a user (real human being) presses a light button the user expects > the light to turn on. > cRPLp proposes that nodes in the tree periodically advertises their > presence using DAOs. > The periodicity is a real beast: > Thanks to Trickle, the rate of updates in a (apparently) stable = network > is low. This is good since it leaves bandwidth for data. > But it is not good if existing routes to my lamp fail and I do not get > new routes to my lamp until it decides to send out a new DAO. > My user will (with a good reason) not tolerate waiting for minutes for > the light to turn on. > > I have met two arguments to counter this concern: > > A1: Well, your lamp can always send a DAO when it detects a problem. > My answer: > True, except that my lamp does not intend to send anything > so it will never experience any problems from its side of the = network. > > A2: Well, you can increase the DAO rate to sub-second updates. > My answer: > Oh no. I get a very high degree of management traffic which > limits my available bandwidth, increases the risk of collisions and > even run the risk of violating EU legislation requiring me to only > transmit in less than 1% of the time: > http://focus.ti.com/lit/an/swra048/swra048.pdf > 868 - 868.6 MHz: <1% > > Reactiveness is hard to achieve via polling. > > > > If you agree that this seems to be critical issues please raise your > voice on the list. > > Going forward > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > We need some reactive mechanism to reach lamps before the user decides > to sue our companies. > So is this possible? I think so. > > Existing commercial (non-IP) solutions are capable of re-routing = quickly > if they really have to. > > Let me try scoping the requirements to a potential solution: > (no different from the req. docs for home and building) > > * P2P routing in any direction independent of the tree. > > * On-demand P2P route discovery if requested by a real-time critical = app. > Data collection apps may be able to just wait for the next DAO = update. > > * Limited range of discovery mechanism: max 4 repeaters. > A TTL field may limit the scope of the repeaters. > > * Suboptimal routing and traffic bursts are accepted in exchange > for quick route repair. But only as an exception. > > > Just as an example, one existing home control technology uses a > (source routing) variant of AODV for quick route repair. > Nothing comes for free. The price is flooding - but not just flooding: > Managed flooding using a distributed algorithm running in all > participating nodes. > The algorithm dampens the flooding in a time, volume and range > perspective. > Some similar mechanism could be built into RPL for quick route repair. > > > If anyone have alternative proposals, please bring it to the list. > Now is the time. > > > > Thanks, > Anders > > > > > _______________________________________________ > Roll mailing 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_01CAC8CC.92380AAE Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [Roll] P2P performance with current RPL = proposal=0A= =0A= =0A= =0A=
=0A=
Pascal = wrote:
=0A=
 
=0A=
>- A P2P = path does not come out of the blue. There must be some provisionning = system that determines
=0A=
>that = those nodes, A and B, are very special so they need a P2P optimization, = with a given special OF,
=0A=
>and that = they both need to talk to D. Well, if
=0A=
 
=0A=
I would claim that in a home = control environment they have to come out of the blue!
=0A=
I need application = association and low-latency control to work beyond direct range an my = users have NO
interest in setting up network rules for provisioning, = etc.
=0A=
Sorry.
=0A=
 
=0A=
- Anders
=0A=
 
=0A=

=0A=
=0A= Fra: roll-bounces@ietf.org p=E5 = vegne af Pascal Thubert (pthubert)
Sendt: fr 19-03-2010 = 17:20
Til: Mukul Goyal
Cc: ROLL WG; Ted = Humpal
Emne: Re: [Roll] P2P performance with current RPL = proposal

=0A=
=0A=

Hi Mukul
> Here I have attempted to formulate a = simple DV algorithm in RPL/DAG terms.
> I will appreciate it if = you could let me know about your objections to this
> = proposal:

[Pascal] It's cool that you do it is the first = impression.

> Node A needs to reach a destination D. Node A = initiates a discovery DAG
> towards D. As the DIOs reach D, it = sends a DAO back to selected parents. As
> the DAO travels towards = node A, in-route nodes store the cost to reach D.
>
> When = node B needs to reach D, it similarly initiates a discovery dag. = During
> this discovery, when a DIO reaches a node C that = maintains a cost to reach D,
> node C responds back with a DAO = that travels towards B and stores in in-
> route nodes the cost to = reach D.

[Pascal]  understand that you're trying to make RPL = even closer to AODV.
I agree we need to gather as much as we can from = that work.

For the specifics of your proposal:

- B-C might = be orthogonal to A-D so that B/C\D forms an angle. You do not end up = with the best path that you're looking for.

- there might be = multiple C's. Which one is the right one?

- RPL does not allow = packets to switch instances. Following multiple DAGs is the recipe for = loops - unless you have them strictly ordered by some means like the RPL = sequence between iterations, more specific routes, blah = blah...)

- the A to D path is optimized for a certain constraint. = You seem to imply that the B to D path has the same constraints and = metrics so we can compare apple to apple. Because this is a very = delicate operation, RPL has introduced the Rank, which has the right = properties to make that comparison efficiently.So for RPL, the loop = avoidance metric is the Rank, and it is only valid within an = iteration.

- A P2P path does not come out of the blue. There must = be some provisionning system that determines that those nodes, A and B, = are very special so they need a P2P optimization, with a given special = OF, and that they both need to talk to D. Well, if that's so, the most = economical is for that system to fork the DAG out of D, with dual = targets A and B. There you obtain the shortest path for both A-D and B-D = for the cost of a single flooding.

I see that you're trying to = get the idea to work better, and I hope we find a way to do so, maybe = along your lines if we can solve the issues above. But before we get = there, we need to agree that this is the path we wish to = take.

Cheers,

Pascal


>
> ----- = Original Message -----
> From: "Pascal Thubert (pthubert)" = <pthubert@cisco.com>
> To: "robert cragie" = <robert.cragie@gridmerge.com>
> Cc: "ROLL WG" = <roll@ietf.org>, "Ted Humpal" <Ted.Humpal@jci.com>
> = Sent: Thursday, March 18, 2010 9:23:14 PM GMT -06:00 US/Canada = Central
> Subject: Re: [Roll] P2P performance with current RPL = proposal
>
>
>
>
>
> Hi = Robert :
>
>
>
> At least from a distance, = the proposed mechanism emulates AODV, with the
> DIO as RREQ and = the DAO as RREP. So if we decide to dig along those lines,
> = we’ll certainly appreciate help from MANET experts. I’d say = that if you
> already have RPL for P2MP and MP2P, the proposed = extension are probably
> simpler to add than doing AODV from = scratch.
>
>
>
> For the setup, the major = differences are that we build a DAG and that we can
> indicate = multiple targets. If you look at it, the DAG capability is a MUST = for
> RPL, and I have not seen that this MUST goes away for P2P = flows. The
> multiple targets is something that appears in a = number of use cases and it
> seems more economical to build a = single DAG for multiple targets when
> = possible.
>
>
>
> For the maintenance, the major = differences are that we have the DAG as
> first line of defense, = and the RPL detection to stimulate the local = repair.
>
>
>
> About your = questions:
>
>
>
> The DODAG root is the one = that spawns the DAG. The targets can reach the
> root because the = root advertises itself in the DIO. The idea is that the root ID
> = is the address that the targets need to talk to. If needed, the root can = also
> advertise a prefix that it can reach and that the targets = need to reach too.
>
>
>
> All the intermediate = nodes that are confirmed by the DAO need to retain at
> least info = about the DAG. That enables the targets to reach the root. The
> = flooding should cost about the same as that of AODV but the RPL way = will
> require more states in the nodes on the way if the OF = requires a DAG.
>
>
>
> The way back (down) can = be stateful of stateless, depending on which DAO
> we’re = using. With fully stateful DAO, we are really in AODV-land. With
> = stateless, we could drift into DSR-land for that direction. Which limits = we
> place to keep it simple will be determined by the resolution = of issue #26 I
> guess…
>
>
>
> And = please, no apologize or on one will dare post anything anymore. = Your
> questions are fully relevant and at the core of the = discussion.
>
>
>
> I hope we can talk in = Anaheim for sure,
>
>
>
>
> = Pascal
>
>
>
>
>
>
> From: = Robert Cragie [mailto:robert.cragie@gridmerg= e.com]
> Sent: Monday, March 15, 2010 11:27 AM
> To: = Pascal Thubert (pth ubert)
> Cc: Ted.Humpal@jci.com; ROLL = WG
> Subject: Re: [Roll] P2P performance with current RPL = proposal
>
>
>
> Hi Pascal,
>
> So = in your slideware T can end up talking to R (DODAG root) through = the
> DODAG. So are you proposing that all potential targets can = act as a DODAG
> root? And therefore all intermediates have to = retain DIO propagation
> support for that DODAG as well? This may = work for limited P2P but seems
> less efficient than simple = distance vector flooding RREQ/RREP like AODV or
> DYMO for generic = P2P. What about R to T (or anyone else for that matter)?
> Do we = source route, maintain state, some undefined hybrid of the = two?
>
> I apologise if some of these questions have been = answered in detail in earlier
> reflector posts but I have only = recently started to concentrate my efforts on
> RPL and have 82 = pages to wade through :-). I look forward to a productive
> = session in Anaheim.
>
> Robert
>
>
> = Robert Cragie (Pacific Gas & Electric)
>
> Gridmerge = Ltd.
> 89 Greenfield Crescent,
> Wakefield, WF4 4WA, = UK
> +44 (0) 1924 910888
> http://www.gridmerge.com
>>
>
> Pascal Thubert (pthubert) wrote:
>
> = HI Robert :
>
>
>
> I respectfully have to = disagree.
>
>
>
> My understanding is that we = are considering a limited set of P2P pairs, for
> which the = specific path that we need to create might have to obey specific
> = constraints.
>
> So it makes sense to use an on-demand = technique, probably inspired by the
> MANET Reactive = protocols.
>
>
>
> As it goes, those protocols = usually use flooding for a node to locate another.
> Forking a DAG = is just another flooding. It does not take a lot of addition to = the
> existing DIO for a root to use RPL to build a DAG that = contains one or multiple
> Targets as leaves, under a set of = constraints expressed as an objective
> function. Please find = attached a slideware that illustrates = that.
>
>
>
>
> = Pascal
>
>
>
>
>
>
> From: = roll-bounces@ietf.org [ mailto:roll-bounces@ietf.org ] = On Behalf Of
> Robert Cragie
> Sent: Thursday, March 11, = 2010 2:43 PM
> To: Ted.Humpal@jci.com
> Cc: ROLL WG
> = Subject: Re: [Roll] P2P performance with current RPL = proposal
>
>
>
> I agree with Ted's comments = below. Creating a DODAG for every reachable
> node as a root seems = a very inefficient approach compared to alternative
> routing = algorithms. I am concerned that RPL does not actually meet the
> = original requirements in I-D.ietf-roll-building-routing-reqs, = I-D.ietf-roll-home-
> routing-reqs, RFC5673 and RFC5548. The = traffic pattern requirement for a
> sink node features prominently = in only two of those documents. Even in this
> case, as Ted points = out, communication is likely to be bidirectional (e.g. end-
> = to-end acks.) therefore the DODAG approach is fundamentally = asymmetric,
> especially if no intermediate storage is allowed for = destination routes and
> source routing has to be = used.
>
> Also, RPL seems highly complex for what are = constrained nodes in terms of
> memory as well as power and = bandwidth. The RPL draft as it stands is 82
> pages long and that = doesn't include text about the objective function.
>
> = Robert
>
>
> Robert Cragie (Pacific Gas & = Electric)
>
> Gridmerge Ltd.
> 89 Greenfield = Crescent,
> Wakefield, WF4 4WA, UK
> +44 (0) 1924 = 910888
> http://www.gridmerge.com
>>
>
> Ted.Humpal@jci.com wrote:
>
>
> = A concern also will be how much overhead (memory space) will be = required
> for a DODAG Root?
>
> and based on the = first question how many DODAG roots a lamp may need to
> be a = member of?
>
> For example in lighting  a single lamp = may be a root for a single switch (1
> DODAG root),  this = lamp / luminaire may also
> be a member of another group - - =  which could be all lights on the floor (2nd
> DODAG root), = and a third group
> of all the lights in the building.  There = can be many more speciality groups
> associated based on the = building configuration.
> Consider also during the installation = time - how these DODAG roots will be
> configured?  Must I = commission each device
> to tell it which DODAG it must use for = its Object Function?  How easy will this
> be to change and = add in a new DODAG root
> for the end user if the lighting group = changes??
>
> With respect to Jerry Martocci's - commercial = building requirements - every
> device may need to communicate to = any or
> all of the end devices.  If each device must = establish a DODAG for the other
> 499 devices in a 500 node = network - How much memory
> space will this require for each end = device to maintain?
>
> Keep in mind that the end devices = are very limited processor and memory
> wise.
>
> Not = to mention all of the network maintenance messages that would = need
> to be transmitted to maintain all of these = DODAGs.
>
> Consider the reconvergence time when one device = is turned off and it was in
> the middle of the majority of the = 100+ DODAGS?
>
> In many lighting and building application = an application acknowledgement -
> must be returned {Back down the = DODAG} so . . . the
> requirement is not just getting to the Root = - a return path must also be
> maintained and have a  low = latency path.
>
> Ted = Humpal
>
>
>
>
>
>
> = From:
>
> Kris Pister = <pister@eecs.berkeley.edu>
>
>
> = To:
>
> Anders Brandt = <abr@sdesigns.dk>
>
>
> Cc:
>
> ROLL = WG <roll@ietf.org>
>
>
> Date:
>
> = 03/08/2010 01:45 PM
>
>
> Subject:
>
> Re: = [Roll] P2P performance with current RPL = proposal
>
>
>
>
>
>
>
><= BR>> Anders - if we take JP's suggestion to make The Lamp a DODAG = root, and
> take Phoebus' recommendation that we use path = diversity to improve end-
> to-end reliability, do you see a = chance of success?
> In my experience, with diverse paths and = order-minutes updates you get
> extremely high = reliability.
>
> I have no aversion to TTL-limited floods as = a part of a solution either.  I'm
> open to ideas on how to = bring those in as (presumably infrequently used)
> = options.
>
> ksjp
>
> Anders Brandt = wrote:
> Hello
>
> I would like to probe the = temperature of the WG on using DAOs to
> support = P2P.
>
> The building and home application spaces (and maybe = others) have
> a few clearly defined requirements.
> It is = not obvious to me how the current RPL proposal (cRPLp) can
> = satisfy those requirements:
>
>
> In both cases it is = the worst case scenario that hurts:
>
>
> P2P routing = inside the PAN
> = =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
> cRPLp has no way of routing inside the PAN if you need more = than
> one repeater. cRPLp has to go all the way to the top (maybe = 4 hops up)
> and down again (maybe 4 hops down) to get just 2 hops = to the side.
>
> The consequence is high latency and high = levels of background noise
> for nodes just outside the direct = radio range.
> At the same time the risk of meeting a failing link = is 4 times higher =3D>
> latency may be much more than 4 times = larger.
>
> Latency may sound like a minor issue but it = actually translates directly
> into lower battery lifetime. In the = above (very realistic) example,
> the battery lifetime is reduced = to 25% of what it should be.
>
> We have lots of battery = devices sending into the network:
> * PIR sensors turning on = lights
> * Door locks sending alarms
> * Door/window sensors = starting chimes
> * Smoke sensors triggering an alarm = system
>
>
>
>
> Response time
> = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> The latency issue is = important.
> When a user (real human being) presses a light button = the user expects
> the light to turn on.
> cRPLp proposes = that nodes in the tree periodically advertises their
> presence = using DAOs.
> The periodicity is a real beast:
> Thanks to = Trickle, the rate of updates in a (apparently) stable network
> is = low. This is good since it leaves bandwidth for data.
> But it is = not good if existing routes to my lamp fail and I do not get
> new = routes to my lamp until it decides to send out a new DAO.
> My = user will (with a good reason) not tolerate waiting for minutes = for
> the light to turn on.
>
> I have met two = arguments to counter this concern:
>
> A1: Well, your lamp = can always send a DAO when it detects a problem.
>   My = answer:
>   True, except that my lamp does not intend to send = anything
>   so it will never experience any problems from = its side of the network.
>
> A2: Well, you can increase the = DAO rate to sub-second updates.
>   My answer:
>   = Oh no. I get a very high degree of management traffic which
> =   limits my available bandwidth, increases the risk of collisions = and
>   even run the risk of violating EU legislation = requiring me to only
>   transmit in less than 1% of the = time:
>   http://focus.ti.c= om/lit/an/swra048/swra048.pdf
>  868 - 868.6 MHz: = <1%
>
>   Reactiveness is hard to achieve via = polling.
>
>
>
> If you agree that this seems to = be critical issues please raise your
> voice on the = list.
>
> Going forward
> = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>
> We need some = reactive mechanism to reach lamps before the user decides
> to sue = our companies.
> So is this possible? I think so.
>
> = Existing commercial (non-IP) solutions are capable of re-routing = quickly
> if they really have to.
>
> Let me try = scoping the requirements to a potential solution:
> (no different = from the req. docs for home and building)
>
> * P2P routing = in any direction independent of the tree.
>
> * On-demand = P2P route discovery if requested by a real-time critical app.
> =  Data collection apps may be able to just wait for the next DAO = update.
>
> * Limited range of discovery mechanism: max 4 = repeaters.
>   A TTL field may limit the scope of the = repeaters.
>
> * Suboptimal routing and traffic bursts are = accepted in exchange
>   for quick route repair. But only as = an exception.
>
>
> Just as an example, one existing = home control technology uses a
> (source routing) variant of AODV = for quick route repair.
> Nothing comes for free. The price is = flooding - but not just flooding:
> Managed flooding using a = distributed algorithm running in all
> participating = nodes.
> The algorithm dampens the flooding in a time, volume and = range
> perspective.
> Some similar mechanism could be built = into RPL for quick route repair.
>
>
> If anyone have = alternative proposals, please bring it to the list.
> Now is the = time.
>
>
>
> Thanks,
>   = Anders
>
>
>
>
> = _______________________________________________
> Roll mailing = 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_01CAC8CC.92380AAE-- From d.sturek@att.net Sun Mar 21 08:08: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 E18A63A6907 for ; Sun, 21 Mar 2010 08:08:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.701 X-Spam-Level: * X-Spam-Status: No, score=1.701 tagged_above=-999 required=5 tests=[AWL=-1.215, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, 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 PlKli+p+b+3H for ; Sun, 21 Mar 2010 08:08:15 -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 E971B3A6967 for ; Sun, 21 Mar 2010 08:08:13 -0700 (PDT) Received: (qmail 98052 invoked from network); 21 Mar 2010 15:08:28 -0000 Received: from adsl-67-124-201-182.dsl.sndg02.pacbell.net (d.sturek@67.124.201.182 with login) by smtp126.sbc.mail.sp1.yahoo.com with SMTP; 21 Mar 2010 08:08:27 -0700 PDT X-Yahoo-SMTP: fvjol_aswBAraSJvMLe2r1XTzhBhbFxY8q8c3jo- X-YMail-OSG: B3RUsfcVM1lxthilBbY7JLJSeaerY4l6.xbQG1_ljeTZFWnhMmhM7Th7SE92BTx0meVWDNRFGZo6DdMjp9OC8w8Xzw0DC1HLWYuzAvXuY_3qjNv.uMma2XOwk6MU.NNV8qOL7RTFj.sk5MwtG1O_8Zu7evVyVkSGEjmzkwHMlt1aFLfbHn0vS76P4U3xKLkPAEGZg5IDWFWwBJxjrase2gGx.8iS.qGKb3erihi5MX5Keb6aFIsmT3cZVTx9298lKGJ6JWIuEYcghJFspb4.eiefW.vGCh2HvDC.a8ISCjWr366mwg-- X-Yahoo-Newman-Property: ymail-3 From: "Don Sturek" To: "'Anders Brandt'" , "'Pascal Thubert \(pthubert\)'" , "'Mukul Goyal'" References: <6A2A459175DABE4BB11DE2026AA50A5D01792E48@XMB-AMS-107.cisco.com><836717245.7606741268982546867.JavaMail.root@mail02.pantherlink.uwm.edu> <6A2A459175DABE4BB11DE2026AA50A5D01793172@XMB-AMS-107.cisco.com> <6D9687E95918C04A8B30A7D6DA805A3E01AD45CC@zensys17.zensys.local> In-Reply-To: <6D9687E95918C04A8B30A7D6DA805A3E01AD45CC@zensys17.zensys.local> Date: Sun, 21 Mar 2010 08:08:25 -0700 Message-ID: <002401cac908$5b119240$1134b6c0$@sturek@att.net> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0025_01CAC8CD.AEB2BA40" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcrHMyXltxfvaHHfTWi9EZDIKP+ZgQASI26gAFQknZMADuxBEA== Content-Language: en-us Cc: 'ROLL WG' , 'Ted Humpal' Subject: Re: [Roll] P2P performance with current RPL proposal 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: Sun, 21 Mar 2010 15:08:30 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0025_01CAC8CD.AEB2BA40 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Anders, =20 Let me add one more point. =20 In a Smart Energy Home Area Network, the customer should not even know = there is a network let alone have any role in commissioning. Network = formation and joining needs to happen autonomously and P2P routing needs to be = enabled and made to work without any action from the customer. =20 Don =20 From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Anders Brandt Sent: Sunday, March 21, 2010 12:58 AM To: Pascal Thubert (pthubert); Mukul Goyal Cc: ROLL WG; Ted Humpal Subject: Re: [Roll] P2P performance with current RPL proposal =20 Pascal wrote: =20 >- A P2P path does not come out of the blue. There must be some provisionning system that determines >that those nodes, A and B, are very special so they need a P2P optimization, with a given special OF, >and that they both need to talk to D. Well, if=20 =20 I would claim that in a home control environment they have to come out = of the blue! I need application association and low-latency control to work beyond = direct range an my users have NO interest in setting up network rules for provisioning, etc. Sorry. =20 - Anders =20 =20 _____ =20 Fra: roll-bounces@ietf.org p=E5 vegne af Pascal Thubert (pthubert) Sendt: fr 19-03-2010 17:20 Til: Mukul Goyal Cc: ROLL WG; Ted Humpal Emne: Re: [Roll] P2P performance with current RPL proposal Hi Mukul > Here I have attempted to formulate a simple DV algorithm in RPL/DAG = terms. > I will appreciate it if you could let me know about your objections to this > proposal: [Pascal] It's cool that you do it is the first impression. > Node A needs to reach a destination D. Node A initiates a discovery = DAG > towards D. As the DIOs reach D, it sends a DAO back to selected = parents. As > the DAO travels towards node A, in-route nodes store the cost to reach = D. > > When node B needs to reach D, it similarly initiates a discovery dag. During > this discovery, when a DIO reaches a node C that maintains a cost to = reach D, > node C responds back with a DAO that travels towards B and stores in = in- > route nodes the cost to reach D. [Pascal] understand that you're trying to make RPL even closer to AODV. I agree we need to gather as much as we can from that work. For the specifics of your proposal: - B-C might be orthogonal to A-D so that B/C\D forms an angle. You do = not end up with the best path that you're looking for. - there might be multiple C's. Which one is the right one? - RPL does not allow packets to switch instances. Following multiple = DAGs is the recipe for loops - unless you have them strictly ordered by some = means like the RPL sequence between iterations, more specific routes, blah blah...) - the A to D path is optimized for a certain constraint. You seem to = imply that the B to D path has the same constraints and metrics so we can = compare apple to apple. Because this is a very delicate operation, RPL has introduced the Rank, which has the right properties to make that = comparison efficiently.So for RPL, the loop avoidance metric is the Rank, and it is only valid within an iteration. - A P2P path does not come out of the blue. There must be some = provisionning system that determines that those nodes, A and B, are very special so = they need a P2P optimization, with a given special OF, and that they both = need to talk to D. Well, if that's so, the most economical is for that system to fork the DAG out of D, with dual targets A and B. There you obtain the shortest path for both A-D and B-D for the cost of a single flooding. I see that you're trying to get the idea to work better, and I hope we = find a way to do so, maybe along your lines if we can solve the issues above. = But before we get there, we need to agree that this is the path we wish to = take. Cheers, Pascal > > ----- Original Message ----- > From: "Pascal Thubert (pthubert)" > To: "robert cragie" > Cc: "ROLL WG" , "Ted Humpal" > Sent: Thursday, March 18, 2010 9:23:14 PM GMT -06:00 US/Canada Central > Subject: Re: [Roll] P2P performance with current RPL proposal > > > > > > Hi Robert : > > > > At least from a distance, the proposed mechanism emulates AODV, with = the > DIO as RREQ and the DAO as RREP. So if we decide to dig along those = lines, > we=92ll certainly appreciate help from MANET experts. I=92d say that = if you > already have RPL for P2MP and MP2P, the proposed extension are = probably > simpler to add than doing AODV from scratch. > > > > For the setup, the major differences are that we build a DAG and that = we can > indicate multiple targets. If you look at it, the DAG capability is a = MUST for > RPL, and I have not seen that this MUST goes away for P2P flows. The > multiple targets is something that appears in a number of use cases = and it > seems more economical to build a single DAG for multiple targets when > possible. > > > > For the maintenance, the major differences are that we have the DAG as > first line of defense, and the RPL detection to stimulate the local repair. > > > > About your questions: > > > > The DODAG root is the one that spawns the DAG. The targets can reach = the > root because the root advertises itself in the DIO. The idea is that = the root ID > is the address that the targets need to talk to. If needed, the root = can also > advertise a prefix that it can reach and that the targets need to = reach too. > > > > All the intermediate nodes that are confirmed by the DAO need to = retain at > least info about the DAG. That enables the targets to reach the root. = The > flooding should cost about the same as that of AODV but the RPL way = will > require more states in the nodes on the way if the OF requires a DAG. > > > > The way back (down) can be stateful of stateless, depending on which = DAO > we=92re using. With fully stateful DAO, we are really in AODV-land. = With > stateless, we could drift into DSR-land for that direction. Which = limits we > place to keep it simple will be determined by the resolution of issue = #26 I > guess=85 > > > > And please, no apologize or on one will dare post anything anymore. = Your > questions are fully relevant and at the core of the discussion. > > > > I hope we can talk in Anaheim for sure, > > > > > Pascal > > > > > > > From: Robert Cragie [mailto:robert.cragie@gridmerge.com] > Sent: Monday, March 15, 2010 11:27 AM > To: Pascal Thubert (pth ubert) > Cc: Ted.Humpal@jci.com; ROLL WG > Subject: Re: [Roll] P2P performance with current RPL proposal > > > > Hi Pascal, > > So in your slideware T can end up talking to R (DODAG root) through = the > DODAG. So are you proposing that all potential targets can act as a = DODAG > root? And therefore all intermediates have to retain DIO propagation > support for that DODAG as well? This may work for limited P2P but = seems > less efficient than simple distance vector flooding RREQ/RREP like = AODV or > DYMO for generic P2P. What about R to T (or anyone else for that = matter)? > Do we source route, maintain state, some undefined hybrid of the two? > > I apologise if some of these questions have been answered in detail in earlier > reflector posts but I have only recently started to concentrate my = efforts on > RPL and have 82 pages to wade through :-). I look forward to a = productive > session in Anaheim. > > Robert > > > Robert Cragie (Pacific Gas & Electric) > > Gridmerge Ltd. > 89 Greenfield Crescent, > Wakefield, WF4 4WA, UK > +44 (0) 1924 910888 > http://www.gridmerge.com =20 > > > > Pascal Thubert (pthubert) wrote: > > HI Robert : > > > > I respectfully have to disagree. > > > > My understanding is that we are considering a limited set of P2P = pairs, for > which the specific path that we need to create might have to obey = specific > constraints. > > So it makes sense to use an on-demand technique, probably inspired by = the > MANET Reactive protocols. > > > > As it goes, those protocols usually use flooding for a node to locate another. > Forking a DAG is just another flooding. It does not take a lot of = addition to the > existing DIO for a root to use RPL to build a DAG that contains one or multiple > Targets as leaves, under a set of constraints expressed as an = objective > function. Please find attached a slideware that illustrates that. > > > > > Pascal > > > > > > > From: roll-bounces@ietf.org [ mailto:roll-bounces@ietf.org ] On Behalf = Of > Robert Cragie > Sent: Thursday, March 11, 2010 2:43 PM > To: Ted.Humpal@jci.com > Cc: ROLL WG > Subject: Re: [Roll] P2P performance with current RPL proposal > > > > I agree with Ted's comments below. Creating a DODAG for every = reachable > node as a root seems a very inefficient approach compared to = alternative > routing algorithms. I am concerned that RPL does not actually meet the > original requirements in I-D.ietf-roll-building-routing-reqs, I-D.ietf-roll-home- > routing-reqs, RFC5673 and RFC5548. The traffic pattern requirement for = a > sink node features prominently in only two of those documents. Even in this > case, as Ted points out, communication is likely to be bidirectional = (e.g. end- > to-end acks.) therefore the DODAG approach is fundamentally = asymmetric, > especially if no intermediate storage is allowed for destination = routes and > source routing has to be used. > > Also, RPL seems highly complex for what are constrained nodes in terms = of > memory as well as power and bandwidth. The RPL draft as it stands is = 82 > pages long and that doesn't include text about the objective function. > > Robert > > > Robert Cragie (Pacific Gas & Electric) > > Gridmerge Ltd. > 89 Greenfield Crescent, > Wakefield, WF4 4WA, UK > +44 (0) 1924 910888 > http://www.gridmerge.com =20 > > > > Ted.Humpal@jci.com wrote: > > > A concern also will be how much overhead (memory space) will be = required > for a DODAG Root? > > and based on the first question how many DODAG roots a lamp may need = to > be a member of? > > For example in lighting a single lamp may be a root for a single = switch (1 > DODAG root), this lamp / luminaire may also > be a member of another group - - which could be all lights on the = floor (2nd > DODAG root), and a third group > of all the lights in the building. There can be many more speciality groups > associated based on the building configuration. > Consider also during the installation time - how these DODAG roots = will be > configured? Must I commission each device > to tell it which DODAG it must use for its Object Function? How easy = will this > be to change and add in a new DODAG root > for the end user if the lighting group changes?? > > With respect to Jerry Martocci's - commercial building requirements - every > device may need to communicate to any or > all of the end devices. If each device must establish a DODAG for the other > 499 devices in a 500 node network - How much memory > space will this require for each end device to maintain? > > Keep in mind that the end devices are very limited processor and = memory > wise. > > Not to mention all of the network maintenance messages that would need > to be transmitted to maintain all of these DODAGs. > > Consider the reconvergence time when one device is turned off and it = was in > the middle of the majority of the 100+ DODAGS? > > In many lighting and building application an application = acknowledgement - > must be returned {Back down the DODAG} so . . . the > requirement is not just getting to the Root - a return path must also = be > maintained and have a low latency path. > > Ted Humpal > > > > > > > From: > > Kris Pister > > > To: > > Anders Brandt > > > Cc: > > ROLL WG > > > Date: > > 03/08/2010 01:45 PM > > > Subject: > > Re: [Roll] P2P performance with current RPL proposal > > > > > > > > > Anders - if we take JP's suggestion to make The Lamp a DODAG root, and > take Phoebus' recommendation that we use path diversity to improve = end- > to-end reliability, do you see a chance of success? > In my experience, with diverse paths and order-minutes updates you get > extremely high reliability. > > I have no aversion to TTL-limited floods as a part of a solution = either. I'm > open to ideas on how to bring those in as (presumably infrequently = used) > options. > > ksjp > > Anders Brandt wrote: > Hello > > I would like to probe the temperature of the WG on using DAOs to > support P2P. > > The building and home application spaces (and maybe others) have > a few clearly defined requirements. > It is not obvious to me how the current RPL proposal (cRPLp) can > satisfy those requirements: > > > In both cases it is the worst case scenario that hurts: > > > P2P routing inside the PAN > = =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 > cRPLp has no way of routing inside the PAN if you need more than > one repeater. cRPLp has to go all the way to the top (maybe 4 hops up) > and down again (maybe 4 hops down) to get just 2 hops to the side. > > The consequence is high latency and high levels of background noise > for nodes just outside the direct radio range. > At the same time the risk of meeting a failing link is 4 times higher = =3D> > latency may be much more than 4 times larger. > > Latency may sound like a minor issue but it actually translates = directly > into lower battery lifetime. In the above (very realistic) example, > the battery lifetime is reduced to 25% of what it should be. > > We have lots of battery devices sending into the network: > * PIR sensors turning on lights > * Door locks sending alarms > * Door/window sensors starting chimes > * Smoke sensors triggering an alarm system > > > > > Response time > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > The latency issue is important. > When a user (real human being) presses a light button the user expects > the light to turn on. > cRPLp proposes that nodes in the tree periodically advertises their > presence using DAOs. > The periodicity is a real beast: > Thanks to Trickle, the rate of updates in a (apparently) stable = network > is low. This is good since it leaves bandwidth for data. > But it is not good if existing routes to my lamp fail and I do not get > new routes to my lamp until it decides to send out a new DAO. > My user will (with a good reason) not tolerate waiting for minutes for > the light to turn on. > > I have met two arguments to counter this concern: > > A1: Well, your lamp can always send a DAO when it detects a problem. > My answer: > True, except that my lamp does not intend to send anything > so it will never experience any problems from its side of the = network. > > A2: Well, you can increase the DAO rate to sub-second updates. > My answer: > Oh no. I get a very high degree of management traffic which > limits my available bandwidth, increases the risk of collisions and > even run the risk of violating EU legislation requiring me to only > transmit in less than 1% of the time: > http://focus.ti.com/lit/an/swra048/swra048.pdf > 868 - 868.6 MHz: <1% > > Reactiveness is hard to achieve via polling. > > > > If you agree that this seems to be critical issues please raise your > voice on the list. > > Going forward > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > We need some reactive mechanism to reach lamps before the user decides > to sue our companies. > So is this possible? I think so. > > Existing commercial (non-IP) solutions are capable of re-routing = quickly > if they really have to. > > Let me try scoping the requirements to a potential solution: > (no different from the req. docs for home and building) > > * P2P routing in any direction independent of the tree. > > * On-demand P2P route discovery if requested by a real-time critical = app. > Data collection apps may be able to just wait for the next DAO = update. > > * Limited range of discovery mechanism: max 4 repeaters. > A TTL field may limit the scope of the repeaters. > > * Suboptimal routing and traffic bursts are accepted in exchange > for quick route repair. But only as an exception. > > > Just as an example, one existing home control technology uses a > (source routing) variant of AODV for quick route repair. > Nothing comes for free. The price is flooding - but not just flooding: > Managed flooding using a distributed algorithm running in all > participating nodes. > The algorithm dampens the flooding in a time, volume and range > perspective. > Some similar mechanism could be built into RPL for quick route repair. > > > If anyone have alternative proposals, please bring it to the list. > Now is the time. > > > > Thanks, > Anders > > > > > _______________________________________________ > Roll mailing 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_0025_01CAC8CD.AEB2BA40 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [Roll] P2P performance with current RPL proposal

Hi Anders,

 

Let me add one more point.

 

In a Smart Energy Home Area Network, the customer should = not even know there is a network let alone have any role in = commissioning.=A0 Network formation and joining needs to happen autonomously and P2P routing needs = to be enabled and made to work without any action from the = customer.

 

Don

 

From:= roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of = Anders Brandt
Sent: Sunday, March 21, 2010 12:58 AM
To: Pascal Thubert (pthubert); Mukul Goyal
Cc: ROLL WG; Ted Humpal
Subject: Re: [Roll] P2P performance with current RPL = proposal

 

Pascal wrote:

 

>- A P2P path does not come out of the blue. There must = be some provisionning system that determines

>that those nodes, A and B, are very special so they = need a P2P optimization, with a given special OF,

>and that they both need to talk to D. Well, if =

 

I would claim that in a home control environment they have to come out of = the blue!

I need application association and low-latency control to work beyond = direct range an my users have NO
interest in setting up network rules for provisioning, = etc.

Sorry.=

 

- Anders

 

 

Fra: roll-bounces@ietf.org p=E5 vegne af = Pascal Thubert (pthubert)
Sendt: fr 19-03-2010 17:20
Til: Mukul Goyal
Cc: ROLL WG; Ted Humpal
Emne: Re: [Roll] P2P performance with current RPL = proposal

Hi Mukul
> Here I have attempted to formulate a simple DV algorithm in RPL/DAG = terms.
> I will appreciate it if you could let me know about your objections = to this
> proposal:

[Pascal] It's cool that you do it is the first impression.

> Node A needs to reach a destination D. Node A initiates a discovery = DAG
> towards D. As the DIOs reach D, it sends a DAO back to selected = parents. As
> the DAO travels towards node A, in-route nodes store the cost to = reach D.
>
> When node B needs to reach D, it similarly initiates a discovery = dag. During
> this discovery, when a DIO reaches a node C that maintains a cost = to reach D,
> node C responds back with a DAO that travels towards B and stores = in in-
> route nodes the cost to reach D.

[Pascal]  understand that you're trying to make RPL even closer to = AODV.
I agree we need to gather as much as we can from that work.

For the specifics of your proposal:

- B-C might be orthogonal to A-D so that B/C\D forms an angle. You do = not end up with the best path that you're looking for.

- there might be multiple C's. Which one is the right one?

- RPL does not allow packets to switch instances. Following multiple = DAGs is the recipe for loops - unless you have them strictly ordered by some = means like the RPL sequence between iterations, more specific routes, blah = blah...)

- the A to D path is optimized for a certain constraint. You seem to = imply that the B to D path has the same constraints and metrics so we can compare = apple to apple. Because this is a very delicate operation, RPL has introduced the = Rank, which has the right properties to make that comparison efficiently.So = for RPL, the loop avoidance metric is the Rank, and it is only valid within an iteration.

- A P2P path does not come out of the blue. There must be some = provisionning system that determines that those nodes, A and B, are very special so = they need a P2P optimization, with a given special OF, and that they both need to = talk to D. Well, if that's so, the most economical is for that system to fork = the DAG out of D, with dual targets A and B. There you obtain the shortest path = for both A-D and B-D for the cost of a single flooding.

I see that you're trying to get the idea to work better, and I hope we = find a way to do so, maybe along your lines if we can solve the issues above. = But before we get there, we need to agree that this is the path we wish to = take.

Cheers,

Pascal


>
> ----- Original Message -----
> From: "Pascal Thubert (pthubert)" = <pthubert@cisco.com>
> To: "robert cragie" = <robert.cragie@gridmerge.com>
> Cc: "ROLL WG" <roll@ietf.org>, "Ted = Humpal" <Ted.Humpal@jci.com>
> Sent: Thursday, March 18, 2010 9:23:14 PM GMT -06:00 US/Canada = Central
> Subject: Re: [Roll] P2P performance with current RPL proposal
>
>
>
>
>
> Hi Robert :
>
>
>
> At least from a distance, the proposed mechanism emulates AODV, = with the
> DIO as RREQ and the DAO as RREP. So if we decide to dig along those = lines,
> we’ll certainly appreciate help from MANET experts. I’d = say that if you
> already have RPL for P2MP and MP2P, the proposed extension are = probably
> simpler to add than doing AODV from scratch.
>
>
>
> For the setup, the major differences are that we build a DAG and = that we can
> indicate multiple targets. If you look at it, the DAG capability is = a MUST for
> RPL, and I have not seen that this MUST goes away for P2P flows. = The
> multiple targets is something that appears in a number of use cases = and it
> seems more economical to build a single DAG for multiple targets = when
> possible.
>
>
>
> For the maintenance, the major differences are that we have the DAG = as
> first line of defense, and the RPL detection to stimulate the local repair.
>
>
>
> About your questions:
>
>
>
> The DODAG root is the one that spawns the DAG. The targets can = reach the
> root because the root advertises itself in the DIO. The idea is = that the root ID
> is the address that the targets need to talk to. If needed, the = root can also
> advertise a prefix that it can reach and that the targets need to = reach too.
>
>
>
> All the intermediate nodes that are confirmed by the DAO need to = retain at
> least info about the DAG. That enables the targets to reach the = root. The
> flooding should cost about the same as that of AODV but the RPL way = will
> require more states in the nodes on the way if the OF requires a = DAG.
>
>
>
> The way back (down) can be stateful of stateless, depending on = which DAO
> we’re using. With fully stateful DAO, we are really in = AODV-land. With
> stateless, we could drift into DSR-land for that direction. Which = limits we
> place to keep it simple will be determined by the resolution of = issue #26 I
> guess…
>
>
>
> And please, no apologize or on one will dare post anything anymore. = Your
> questions are fully relevant and at the core of the discussion.
>
>
>
> I hope we can talk in Anaheim for sure,
>
>
>
>
> Pascal
>
>
>
>
>
>
> From: Robert Cragie [mailto:robert.cragie@gridmerg= e.com]
> Sent: Monday, March 15, 2010 11:27 AM
> To: Pascal Thubert (pth ubert)
> Cc: Ted.Humpal@jci.com; ROLL WG
> Subject: Re: [Roll] P2P performance with current RPL proposal
>
>
>
> Hi Pascal,
>
> So in your slideware T can end up talking to R (DODAG root) through = the
> DODAG. So are you proposing that all potential targets can act as a = DODAG
> root? And therefore all intermediates have to retain DIO = propagation
> support for that DODAG as well? This may work for limited P2P but = seems
> less efficient than simple distance vector flooding RREQ/RREP like = AODV or
> DYMO for generic P2P. What about R to T (or anyone else for that = matter)?
> Do we source route, maintain state, some undefined hybrid of the = two?
>
> I apologise if some of these questions have been answered in detail = in earlier
> reflector posts but I have only recently started to concentrate my = efforts on
> RPL and have 82 pages to wade through :-). I look forward to a = productive
> session in Anaheim.
>
> Robert
>
>
> Robert Cragie (Pacific Gas & Electric)
>
> Gridmerge Ltd.
> 89 Greenfield Crescent,
> Wakefield, WF4 4WA, UK
> +44 (0) 1924 910888
> http://www.gridmerge.com
>
>
>
> Pascal Thubert (pthubert) wrote:
>
> HI Robert :
>
>
>
> I respectfully have to disagree.
>
>
>
> My understanding is that we are considering a limited set of P2P = pairs, for
> which the specific path that we need to create might have to obey = specific
> constraints.
>
> So it makes sense to use an on-demand technique, probably inspired = by the
> MANET Reactive protocols.
>
>
>
> As it goes, those protocols usually use flooding for a node to = locate another.
> Forking a DAG is just another flooding. It does not take a lot of = addition to the
> existing DIO for a root to use RPL to build a DAG that contains one = or multiple
> Targets as leaves, under a set of constraints expressed as an = objective
> function. Please find attached a slideware that illustrates = that.
>
>
>
>
> Pascal
>
>
>
>
>
>
> From: roll-bounces@ietf.org [ mailto:roll-bounces@ietf.org ] On Behalf Of
> Robert Cragie
> Sent: Thursday, March 11, 2010 2:43 PM
> To: Ted.Humpal@jci.com
> Cc: ROLL WG
> Subject: Re: [Roll] P2P performance with current RPL proposal
>
>
>
> I agree with Ted's comments below. Creating a DODAG for every = reachable
> node as a root seems a very inefficient approach compared to = alternative
> routing algorithms. I am concerned that RPL does not actually meet = the
> original requirements in I-D.ietf-roll-building-routing-reqs, I-D.ietf-roll-home-
> routing-reqs, RFC5673 and RFC5548. The traffic pattern requirement = for a
> sink node features prominently in only two of those documents. Even = in this
> case, as Ted points out, communication is likely to be = bidirectional (e.g. end-
> to-end acks.) therefore the DODAG approach is fundamentally = asymmetric,
> especially if no intermediate storage is allowed for destination = routes and
> source routing has to be used.
>
> Also, RPL seems highly complex for what are constrained nodes in = terms of
> memory as well as power and bandwidth. The RPL draft as it stands = is 82
> pages long and that doesn't include text about the objective = function.
>
> Robert
>
>
> Robert Cragie (Pacific Gas & Electric)
>
> Gridmerge Ltd.
> 89 Greenfield Crescent,
> Wakefield, WF4 4WA, UK
> +44 (0) 1924 910888
> http://www.gridmerge.com
>
>
>
> Ted.Humpal@jci.com wrote:
>
>
> A concern also will be how much overhead (memory space) will be = required
> for a DODAG Root?
>
> and based on the first question how many DODAG roots a lamp may = need to
> be a member of?
>
> For example in lighting  a single lamp may be a root for a = single switch (1
> DODAG root),  this lamp / luminaire may also
> be a member of another group - -  which could be all lights on = the floor (2nd
> DODAG root), and a third group
> of all the lights in the building.  There can be many more = speciality groups
> associated based on the building configuration.
> Consider also during the installation time - how these DODAG roots = will be
> configured?  Must I commission each device
> to tell it which DODAG it must use for its Object Function? =  How easy will this
> be to change and add in a new DODAG root
> for the end user if the lighting group changes??
>
> With respect to Jerry Martocci's - commercial building requirements = - every
> device may need to communicate to any or
> all of the end devices.  If each device must establish a DODAG = for the other
> 499 devices in a 500 node network - How much memory
> space will this require for each end device to maintain?
>
> Keep in mind that the end devices are very limited processor and = memory
> wise.
>
> Not to mention all of the network maintenance messages that would = need
> to be transmitted to maintain all of these DODAGs.
>
> Consider the reconvergence time when one device is turned off and = it was in
> the middle of the majority of the 100+ DODAGS?
>
> In many lighting and building application an application = acknowledgement -
> must be returned {Back down the DODAG} so . . . the
> requirement is not just getting to the Root - a return path must = also be
> maintained and have a  low latency path.
>
> Ted Humpal
>
>
>
>
>
>
> From:
>
> Kris Pister <pister@eecs.berkeley.edu>
>
>
> To:
>
> Anders Brandt <abr@sdesigns.dk>
>
>
> Cc:
>
> ROLL WG <roll@ietf.org>
>
>
> Date:
>
> 03/08/2010 01:45 PM
>
>
> Subject:
>
> Re: [Roll] P2P performance with current RPL proposal
>
>
>
>
>
>
>
>
> Anders - if we take JP's suggestion to make The Lamp a DODAG root, = and
> take Phoebus' recommendation that we use path diversity to improve = end-
> to-end reliability, do you see a chance of success?
> In my experience, with diverse paths and order-minutes updates you = get
> extremely high reliability.
>
> I have no aversion to TTL-limited floods as a part of a solution = either.  I'm
> open to ideas on how to bring those in as (presumably infrequently = used)
> options.
>
> ksjp
>
> Anders Brandt wrote:
> Hello
>
> I would like to probe the temperature of the WG on using DAOs = to
> support P2P.
>
> The building and home application spaces (and maybe others) = have
> a few clearly defined requirements.
> It is not obvious to me how the current RPL proposal (cRPLp) = can
> satisfy those requirements:
>
>
> In both cases it is the worst case scenario that hurts:
>
>
> P2P routing inside the PAN
> = =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
> cRPLp has no way of routing inside the PAN if you need more = than
> one repeater. cRPLp has to go all the way to the top (maybe 4 hops = up)
> and down again (maybe 4 hops down) to get just 2 hops to the = side.
>
> The consequence is high latency and high levels of background = noise
> for nodes just outside the direct radio range.
> At the same time the risk of meeting a failing link is 4 times = higher =3D>
> latency may be much more than 4 times larger.
>
> Latency may sound like a minor issue but it actually translates = directly
> into lower battery lifetime. In the above (very realistic) = example,
> the battery lifetime is reduced to 25% of what it should be.
>
> We have lots of battery devices sending into the network:
> * PIR sensors turning on lights
> * Door locks sending alarms
> * Door/window sensors starting chimes
> * Smoke sensors triggering an alarm system
>
>
>
>
> Response time
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> The latency issue is important.
> When a user (real human being) presses a light button the user = expects
> the light to turn on.
> cRPLp proposes that nodes in the tree periodically advertises = their
> presence using DAOs.
> The periodicity is a real beast:
> Thanks to Trickle, the rate of updates in a (apparently) stable = network
> is low. This is good since it leaves bandwidth for data.
> But it is not good if existing routes to my lamp fail and I do not = get
> new routes to my lamp until it decides to send out a new DAO.
> My user will (with a good reason) not tolerate waiting for minutes = for
> the light to turn on.
>
> I have met two arguments to counter this concern:
>
> A1: Well, your lamp can always send a DAO when it detects a = problem.
>   My answer:
>   True, except that my lamp does not intend to send = anything
>   so it will never experience any problems from its side of = the network.
>
> A2: Well, you can increase the DAO rate to sub-second updates.
>   My answer:
>   Oh no. I get a very high degree of management traffic = which
>   limits my available bandwidth, increases the risk of = collisions and
>   even run the risk of violating EU legislation requiring me = to only
>   transmit in less than 1% of the time:
>   http://focus.ti.c= om/lit/an/swra048/swra048.pdf
>  868 - 868.6 MHz: <1%
>
>   Reactiveness is hard to achieve via polling.
>
>
>
> If you agree that this seems to be critical issues please raise = your
> voice on the list.
>
> Going forward
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>
> We need some reactive mechanism to reach lamps before the user = decides
> to sue our companies.
> So is this possible? I think so.
>
> Existing commercial (non-IP) solutions are capable of re-routing = quickly
> if they really have to.
>
> Let me try scoping the requirements to a potential solution:
> (no different from the req. docs for home and building)
>
> * P2P routing in any direction independent of the tree.
>
> * On-demand P2P route discovery if requested by a real-time = critical app.
>  Data collection apps may be able to just wait for the next = DAO update.
>
> * Limited range of discovery mechanism: max 4 repeaters.
>   A TTL field may limit the scope of the repeaters.
>
> * Suboptimal routing and traffic bursts are accepted in = exchange
>   for quick route repair. But only as an exception.
>
>
> Just as an example, one existing home control technology uses a
> (source routing) variant of AODV for quick route repair.
> Nothing comes for free. The price is flooding - but not just = flooding:
> Managed flooding using a distributed algorithm running in all
> participating nodes.
> The algorithm dampens the flooding in a time, volume and range
> perspective.
> Some similar mechanism could be built into RPL for quick route = repair.
>
>
> If anyone have alternative proposals, please bring it to the = list.
> Now is the time.
>
>
>
> Thanks,
>   Anders
>
>
>
>
> _______________________________________________
> Roll mailing 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_0025_01CAC8CD.AEB2BA40-- From pthubert@cisco.com Sun Mar 21 10:40: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 E93ED3A684D for ; Sun, 21 Mar 2010 10:40:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.849 X-Spam-Level: X-Spam-Status: No, score=-2.849 tagged_above=-999 required=5 tests=[AWL=-4.580, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, J_CHICKENPOX_32=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 FL28aN60QpAQ for ; Sun, 21 Mar 2010 10:40:05 -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 140B93A6359 for ; Sun, 21 Mar 2010 10:40:04 -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: AigBAEb3pUuQ/uCWe2dsb2JhbACbOxUBAQsLJAYcoC+XY4R9BA X-IronPort-AV: E=Sophos;i="4.51,283,1267401600"; d="scan'208";a="4607635" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-2.cisco.com with ESMTP; 21 Mar 2010 17:06:17 +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 o2LHeJNq019304; Sun, 21 Mar 2010 17:40:20 GMT Received: from xmb-ams-107.cisco.com ([144.254.74.82]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Sun, 21 Mar 2010 18:40:19 +0100 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, 21 Mar 2010 18:40:13 +0100 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D0180D60F@XMB-AMS-107.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] Options in DIS Thread-Index: AcrJHY+UYUjvc9PHRpG5uWQhRnrY+A== From: "Pascal Thubert (pthubert)" To: , X-OriginalArrivalTime: 21 Mar 2010 17:40:19.0944 (UTC) FILETIME=[93814E80:01CAC91D] Subject: Re: [Roll] Options in DIS X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 21 Mar 2010 17:40:07 -0000 Hi Dominique: I'd add that it can be interesting for a node to specify what it is looking for, like the instance that it belongs to and for which it is searching for a parent. Yes, you have my support to make this a ticket. Pascal > -----Original Message----- > From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of > dominique.barthel@orange-ftgroup.com > Sent: Friday, March 19, 2010 10:45 AM > To: roll@ietf.org > Subject: [Roll] Options in DIS >=20 > Hi all, >=20 > I have already expressed a desire for options in the DIS packet > http://www.ietf.org/mail-archive/web/roll/current/msg02765.html > Jerry and Mukul expressed their support to the request. > http://www.ietf.org/mail-archive/web/roll/current/msg02766.html > http://www.ietf.org/mail-archive/web/roll/current/msg02770.html >=20 > Then Phil asked for a justification for the request, which I admit I > haven't provided yet. > http://www.ietf.org/mail-archive/web/roll/current/msg02774.html >=20 > More recently, Tzeta suggested that DIS have security options > http://www.ietf.org/mail-archive/web/roll/current/msg03101.html >=20 > Independently, Yaov and Matteo both again expressed the need for DIS > option. > http://www.ietf.org/mail-archive/web/roll/current/msg03185.html > http://www.ietf.org/mail-archive/web/roll/current/msg03290.html >=20 > I do believe we have a serious point here. > Please find the justification below. > Can we please have a ticket to work on it ? > I volunteer to gather others contributors' opinions/requests and and > propose detailed text to be included in future revisions of the RPL > draft. > Best, >=20 > Dominique >=20 > ------------------------------------------- > The following is extracted from a typical water/gas smart metering > infrastructure. > The utility company worker adds new metering points into the network as > meters are replaced or fitted with sensing/transmission electronics. > Before the worker leaves the premises, he/she is requested to check that > the meter has actually joined the network. > This cannot wait for a trickled-down DAO to arrive. > Therefore, the meter will send a DIS to collect information from the > network. > Without DIS options, all neighbor routers will respond, spending energy > for their own transmission and triggering energy expenditure in all > neighbor nodes that overhear the responses. >=20 > Let's consider a "wheel" model for the network topology, with a sink at > the center and spokes connecting outward to ring-1 routers, ring-2 > routers and periphery meters. The meters have routing capability > themselves, although I'll call them meters in the following text to > distinguish them from devices solely intended at providing connectivity, > which I'll call routers. > Let's consider a generic "pizza slice" of this wheel. Since there's > central symmetry in the network, there's no border effect in the slice > We typically have > - one mains-powered sink at the center, > - N severely energy-limited meters at the periphery, deeply burried into > basements or manholes > - N/20 fairly energy-limited ring-1 routers, located on high spots > - N/10 fairly energy-limited ring-2 routers, located on high spots > In RPL parlance, ring-1 routers would have a typical rank of 4, and > ring-2 routers would have a typical rank of 8 > The N/10 and N/20 ratios above are dictated by energy/lifetime > considerations, not radio coverage. > A typical connectivity is the following > - each meter is in range of N/10 and N/20 routers, albeit with *very* > different link qualities > - each router is in range of N/10 and N/20 routers, with various link > qualities > - each meter is in range of N/20 meters > The ratios and assumptions above hold for values of N in the [20..200] > range. >=20 > **** Without DIS options, we have > NT0 =3D Number of DIS multicast transmission =3D 1 > NR0 =3D Number of DIS active receptions =3D N/5 (due to N/20 meters = and > (N/10+N/20) routeurs), > NT1 =3D N/20 DIO transmissions from meters; each one being overheard = by > N/20 meters and (N/10+N/20) routers > NT2 =3D N/10+N/20 DIO transmissions from routers; each one being overheard > by N meters and (N/10+N/20) routers > NR1 ~=3D NT1 * (3N/20 + N/20) =3D N^2/100 =3D 0.01 * N^2 receptions = due to DIO > coming from meters > NR2 ~=3D NT2 * (N + N/20 + N/10) =3D N^2*69/400 =3D 0.17 * N^2 = receptions due > to DIO coming from routers >=20 > We therefore have > Number of transmissions: NT =3D NT0 + NT1 + NT2 =3D 1 + N/20 + (N/10 + N/20) > =3D 24/20 * N =3D 1 + 0.2 * N > Number of receptions : NR =3D NR0 + NR1 + NR2 =3D 0.2 * N + 0.18 * = N^2 >=20 > Total energy cost Etotal =3D NT * Et + NR * Er >=20 > If the network is asynchronous and uses basic preamble sampling, the > cost of overhearing Eo is the cost of receiving the expected duration > (half) of the preamble. > Since the DIS packet is small, its unit reception cost Er is about the > same as the overhearing cost Eo. > With a small (<1KB) DIO packet, the cost of transmission Et is > essentially the cost of sending the preamble. > Let's assume transmission cost Et is 6 times Eo (full preamble length > accounts for x2, power consumption for x3) >=20 > Etotal ~=3D Eo * ( 1 * 6 + N * (0.2 * 6 + 0.2) + 0.18 * N^2) ~=3D Eo * = ( 6 + > 1.4 * N + 0.18 * N^2) >=20 > **** With DIS options > A typical protocol currently in use in widely deployed proprietary smart > metering networks is the following. > Newborn nodes send successive DIS'es with decreasing demands on rank > and > link quality > - iteration 1: only sinks, LQI >=3D 0,75*maxLQI > - iteration 2: only sinks, LQI >=3D 0,5*maxLQI > - iteration 3: only sinks, LQI >=3D 0,25*maxLQI > - iteration 4: ring-1 routers, LQI >=3D 0,75*maxLQI, > - iteration 5: ring-1 routers, LQI >=3D 0,50*maxLQI, > - iteration 6: ring-1 routers, LQI >=3D 0,25*maxLQI, > - iteration 7: ring-2 routers, LQI >=3D 0,75*maxLQI, > - iteration 8: ring-2 routers, LQI >=3D 0,50*maxLQI, > - iteration 9: ring-2 routers, LQI >=3D 0,25*maxLQI, > - etc > The newborn node will usually send several DIS's instead of just one. > Its direct neighbors (N/20 meters, N/10+N/20 routers) will also incur > the cost of receiving these extra DIS'es. > Let's suppose iteration 7 is successful and prompts 25% of the neighbor > ring-2 routers to send their DIOs. > Number of DIS transmissions =3D 7 > Number of DIS receptions =3D 7 * (N/20 + N/10 + N/20) =3D 7/5 * N > Number of DIO transmissions =3D 25% of N/10 =3D N/40, overheard by = 23/20 * N > nodes (N meters and N/10+N/20 routers). > Number of DIOs overheard =3D 23/800 * N^2 =3D 0.029 * N^2 > Etotal ~=3D Eo * ( 7*6 + N * ( 7/5 + 6/40) + 0.029 * N^2) ~=3D Eo * = (42 + > 1.6 * N + 0.029 * N^2) >=20 > In this case, the global energy cost of inserting a new node in the > network is reduced by a factor ranging from 2 to 5 depending on N in > [20..200]. Additional analysis shows that this saving affect both meters > and routers (specifically, we are not pushing the burden towards the > energy-critical meters). > Similar results are obtained with differents iterations numbers. >=20 > Just to re-inforce this calculation, it has been our experience that > node insertion into a dense low-power network, if done wrong, is a > significant energy drain. Please let us enhance RPL to do it right. > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From pthubert@cisco.com Sun Mar 21 10: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 B93153A6B03 for ; Sun, 21 Mar 2010 10:40:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.958 X-Spam-Level: X-Spam-Status: No, score=-6.958 tagged_above=-999 required=5 tests=[AWL=-0.090, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, 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 7wgKJddzMoWl for ; Sun, 21 Mar 2010 10:40: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 3E8203A6AF2 for ; Sun, 21 Mar 2010 10:40:16 -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: AkcBAIL3pUuQ/uCWe2dsb2JhbACBQpl5FQEBCwskBhygMYsIjFuEfQSOUw X-IronPort-AV: E=Sophos;i="4.51,283,1267401600"; d="scan'208,217";a="58345820" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 21 Mar 2010 17:40:18 +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 o2LHeIP1019298; Sun, 21 Mar 2010 17:40: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); Sun, 21 Mar 2010 18:40:18 +0100 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_01CAC91D.92360FAC" Date: Sun, 21 Mar 2010 18:36:09 +0100 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D0180D60E@XMB-AMS-107.cisco.com> In-Reply-To: <002401cac908$5b119240$1134b6c0$@sturek@att.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] P2P performance with current RPL proposal Thread-Index: AcrHMyXltxfvaHHfTWi9EZDIKP+ZgQASI26gAFQknZMADuxBEAAEAPsg References: <6A2A459175DABE4BB11DE2026AA50A5D01792E48@XMB-AMS-107.cisco.com><836717245.7606741268982546867.JavaMail.root@mail02.pantherlink.uwm.edu> <6A2A459175DABE4BB11DE2026AA50A5D01793172@XMB-AMS-107.cisco.com> <6D9687E95918C04A8B30A7D6DA805A3E01AD45CC@zensys17.zensys.local> <002401cac908$5b119240$1134b6c0$@sturek@att.net> From: "Pascal Thubert (pthubert)" To: , "Anders Brandt" , "Mukul Goyal" X-OriginalArrivalTime: 21 Mar 2010 17:40:18.0413 (UTC) FILETIME=[9297B1D0:01CAC91D] Cc: ROLL WG , Ted Humpal Subject: Re: [Roll] P2P performance with current RPL proposal X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Mar 2010 17:40:37 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CAC91D.92360FAC Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Don and Anders, The existence of small sets of things tied together, like the lamp(s) = and the switch(es), or the remote and the TV, etc..., is what enable a = P2P optimization within the sets that's cheaper than the general any to = any. =20 I can understand that the end-user should be mostly transparent to this. = But figuring out which nodes are in which sets is an application thing = and out of scope for RPL. You give RPL a set of IP addresses and RPL = builds on-demand routes between those. =20 Some additional optimizations are possible with RPL. For instance, one = on-demand DAG with multiple targets is cheaper and more efficient than = one DAG per target. But an optimization like this can only happen if the = something that builds the sets is smart enough to benefit from those in = the first place. =20 Pascal =20 From: Don Sturek [mailto:d.sturek@att.net]=20 Sent: Sunday, March 21, 2010 8:08 AM To: 'Anders Brandt'; Pascal Thubert (pthubert); 'Mukul Goyal' Cc: 'ROLL WG'; 'Ted Humpal' Subject: RE: [Roll] P2P performance with current RPL proposal =20 Hi Anders, =20 Let me add one more point. =20 In a Smart Energy Home Area Network, the customer should not even know = there is a network let alone have any role in commissioning. Network = formation and joining needs to happen autonomously and P2P routing needs = to be enabled and made to work without any action from the customer. =20 Don =20 From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of = Anders Brandt Sent: Sunday, March 21, 2010 12:58 AM To: Pascal Thubert (pthubert); Mukul Goyal Cc: ROLL WG; Ted Humpal Subject: Re: [Roll] P2P performance with current RPL proposal =20 Pascal wrote: =20 >- A P2P path does not come out of the blue. There must be some = provisionning system that determines >that those nodes, A and B, are very special so they need a P2P = optimization, with a given special OF, >and that they both need to talk to D. Well, if=20 =20 I would claim that in a home control environment they have to come out = of the blue! I need application association and low-latency control to work beyond = direct range an my users have NO interest in setting up network rules for provisioning, etc. Sorry. =20 - Anders =20 =20 ________________________________ Fra: roll-bounces@ietf.org p=E5 vegne af Pascal Thubert (pthubert) Sendt: fr 19-03-2010 17:20 Til: Mukul Goyal Cc: ROLL WG; Ted Humpal Emne: Re: [Roll] P2P performance with current RPL proposal Hi Mukul > Here I have attempted to formulate a simple DV algorithm in RPL/DAG = terms. > I will appreciate it if you could let me know about your objections to = this > proposal: [Pascal] It's cool that you do it is the first impression. > Node A needs to reach a destination D. Node A initiates a discovery = DAG > towards D. As the DIOs reach D, it sends a DAO back to selected = parents. As > the DAO travels towards node A, in-route nodes store the cost to reach = D. > > When node B needs to reach D, it similarly initiates a discovery dag. = During > this discovery, when a DIO reaches a node C that maintains a cost to = reach D, > node C responds back with a DAO that travels towards B and stores in = in- > route nodes the cost to reach D. [Pascal] understand that you're trying to make RPL even closer to AODV. I agree we need to gather as much as we can from that work. For the specifics of your proposal: - B-C might be orthogonal to A-D so that B/C\D forms an angle. You do = not end up with the best path that you're looking for. - there might be multiple C's. Which one is the right one? - RPL does not allow packets to switch instances. Following multiple = DAGs is the recipe for loops - unless you have them strictly ordered by = some means like the RPL sequence between iterations, more specific = routes, blah blah...) - the A to D path is optimized for a certain constraint. You seem to = imply that the B to D path has the same constraints and metrics so we = can compare apple to apple. Because this is a very delicate operation, = RPL has introduced the Rank, which has the right properties to make that = comparison efficiently.So for RPL, the loop avoidance metric is the = Rank, and it is only valid within an iteration. - A P2P path does not come out of the blue. There must be some = provisionning system that determines that those nodes, A and B, are very = special so they need a P2P optimization, with a given special OF, and = that they both need to talk to D. Well, if that's so, the most = economical is for that system to fork the DAG out of D, with dual = targets A and B. There you obtain the shortest path for both A-D and B-D = for the cost of a single flooding. I see that you're trying to get the idea to work better, and I hope we = find a way to do so, maybe along your lines if we can solve the issues = above. But before we get there, we need to agree that this is the path = we wish to take. Cheers, Pascal > > ----- Original Message ----- > From: "Pascal Thubert (pthubert)" > To: "robert cragie" > Cc: "ROLL WG" , "Ted Humpal" > Sent: Thursday, March 18, 2010 9:23:14 PM GMT -06:00 US/Canada Central > Subject: Re: [Roll] P2P performance with current RPL proposal > > > > > > Hi Robert : > > > > At least from a distance, the proposed mechanism emulates AODV, with = the > DIO as RREQ and the DAO as RREP. So if we decide to dig along those = lines, > we'll certainly appreciate help from MANET experts. I'd say that if = you > already have RPL for P2MP and MP2P, the proposed extension are = probably > simpler to add than doing AODV from scratch. > > > > For the setup, the major differences are that we build a DAG and that = we can > indicate multiple targets. If you look at it, the DAG capability is a = MUST for > RPL, and I have not seen that this MUST goes away for P2P flows. The > multiple targets is something that appears in a number of use cases = and it > seems more economical to build a single DAG for multiple targets when > possible. > > > > For the maintenance, the major differences are that we have the DAG as > first line of defense, and the RPL detection to stimulate the local = repair. > > > > About your questions: > > > > The DODAG root is the one that spawns the DAG. The targets can reach = the > root because the root advertises itself in the DIO. The idea is that = the root ID > is the address that the targets need to talk to. If needed, the root = can also > advertise a prefix that it can reach and that the targets need to = reach too. > > > > All the intermediate nodes that are confirmed by the DAO need to = retain at > least info about the DAG. That enables the targets to reach the root. = The > flooding should cost about the same as that of AODV but the RPL way = will > require more states in the nodes on the way if the OF requires a DAG. > > > > The way back (down) can be stateful of stateless, depending on which = DAO > we're using. With fully stateful DAO, we are really in AODV-land. With > stateless, we could drift into DSR-land for that direction. Which = limits we > place to keep it simple will be determined by the resolution of issue = #26 I > guess... > > > > And please, no apologize or on one will dare post anything anymore. = Your > questions are fully relevant and at the core of the discussion. > > > > I hope we can talk in Anaheim for sure, > > > > > Pascal > > > > > > > From: Robert Cragie [mailto:robert.cragie@gridmerge.com] > Sent: Monday, March 15, 2010 11:27 AM > To: Pascal Thubert (pth ubert) > Cc: Ted.Humpal@jci.com; ROLL WG > Subject: Re: [Roll] P2P performance with current RPL proposal > > > > Hi Pascal, > > So in your slideware T can end up talking to R (DODAG root) through = the > DODAG. So are you proposing that all potential targets can act as a = DODAG > root? And therefore all intermediates have to retain DIO propagation > support for that DODAG as well? This may work for limited P2P but = seems > less efficient than simple distance vector flooding RREQ/RREP like = AODV or > DYMO for generic P2P. What about R to T (or anyone else for that = matter)? > Do we source route, maintain state, some undefined hybrid of the two? > > I apologise if some of these questions have been answered in detail in = earlier > reflector posts but I have only recently started to concentrate my = efforts on > RPL and have 82 pages to wade through :-). I look forward to a = productive > session in Anaheim. > > Robert > > > Robert Cragie (Pacific Gas & Electric) > > Gridmerge Ltd. > 89 Greenfield Crescent, > Wakefield, WF4 4WA, UK > +44 (0) 1924 910888 > http://www.gridmerge.com =20 > > > > Pascal Thubert (pthubert) wrote: > > HI Robert : > > > > I respectfully have to disagree. > > > > My understanding is that we are considering a limited set of P2P = pairs, for > which the specific path that we need to create might have to obey = specific > constraints. > > So it makes sense to use an on-demand technique, probably inspired by = the > MANET Reactive protocols. > > > > As it goes, those protocols usually use flooding for a node to locate = another. > Forking a DAG is just another flooding. It does not take a lot of = addition to the > existing DIO for a root to use RPL to build a DAG that contains one or = multiple > Targets as leaves, under a set of constraints expressed as an = objective > function. Please find attached a slideware that illustrates that. > > > > > Pascal > > > > > > > From: roll-bounces@ietf.org [ mailto:roll-bounces@ietf.org ] On Behalf = Of > Robert Cragie > Sent: Thursday, March 11, 2010 2:43 PM > To: Ted.Humpal@jci.com > Cc: ROLL WG > Subject: Re: [Roll] P2P performance with current RPL proposal > > > > I agree with Ted's comments below. Creating a DODAG for every = reachable > node as a root seems a very inefficient approach compared to = alternative > routing algorithms. I am concerned that RPL does not actually meet the > original requirements in I-D.ietf-roll-building-routing-reqs, = I-D.ietf-roll-home- > routing-reqs, RFC5673 and RFC5548. The traffic pattern requirement for = a > sink node features prominently in only two of those documents. Even in = this > case, as Ted points out, communication is likely to be bidirectional = (e.g. end- > to-end acks.) therefore the DODAG approach is fundamentally = asymmetric, > especially if no intermediate storage is allowed for destination = routes and > source routing has to be used. > > Also, RPL seems highly complex for what are constrained nodes in terms = of > memory as well as power and bandwidth. The RPL draft as it stands is = 82 > pages long and that doesn't include text about the objective function. > > Robert > > > Robert Cragie (Pacific Gas & Electric) > > Gridmerge Ltd. > 89 Greenfield Crescent, > Wakefield, WF4 4WA, UK > +44 (0) 1924 910888 > http://www.gridmerge.com =20 > > > > Ted.Humpal@jci.com wrote: > > > A concern also will be how much overhead (memory space) will be = required > for a DODAG Root? > > and based on the first question how many DODAG roots a lamp may need = to > be a member of? > > For example in lighting a single lamp may be a root for a single = switch (1 > DODAG root), this lamp / luminaire may also > be a member of another group - - which could be all lights on the = floor (2nd > DODAG root), and a third group > of all the lights in the building. There can be many more speciality = groups > associated based on the building configuration. > Consider also during the installation time - how these DODAG roots = will be > configured? Must I commission each device > to tell it which DODAG it must use for its Object Function? How easy = will this > be to change and add in a new DODAG root > for the end user if the lighting group changes?? > > With respect to Jerry Martocci's - commercial building requirements - = every > device may need to communicate to any or > all of the end devices. If each device must establish a DODAG for the = other > 499 devices in a 500 node network - How much memory > space will this require for each end device to maintain? > > Keep in mind that the end devices are very limited processor and = memory > wise. > > Not to mention all of the network maintenance messages that would need > to be transmitted to maintain all of these DODAGs. > > Consider the reconvergence time when one device is turned off and it = was in > the middle of the majority of the 100+ DODAGS? > > In many lighting and building application an application = acknowledgement - > must be returned {Back down the DODAG} so . . . the > requirement is not just getting to the Root - a return path must also = be > maintained and have a low latency path. > > Ted Humpal > > > > > > > From: > > Kris Pister > > > To: > > Anders Brandt > > > Cc: > > ROLL WG > > > Date: > > 03/08/2010 01:45 PM > > > Subject: > > Re: [Roll] P2P performance with current RPL proposal > > > > > > > > > Anders - if we take JP's suggestion to make The Lamp a DODAG root, and > take Phoebus' recommendation that we use path diversity to improve = end- > to-end reliability, do you see a chance of success? > In my experience, with diverse paths and order-minutes updates you get > extremely high reliability. > > I have no aversion to TTL-limited floods as a part of a solution = either. I'm > open to ideas on how to bring those in as (presumably infrequently = used) > options. > > ksjp > > Anders Brandt wrote: > Hello > > I would like to probe the temperature of the WG on using DAOs to > support P2P. > > The building and home application spaces (and maybe others) have > a few clearly defined requirements. > It is not obvious to me how the current RPL proposal (cRPLp) can > satisfy those requirements: > > > In both cases it is the worst case scenario that hurts: > > > P2P routing inside the PAN > = =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 > cRPLp has no way of routing inside the PAN if you need more than > one repeater. cRPLp has to go all the way to the top (maybe 4 hops up) > and down again (maybe 4 hops down) to get just 2 hops to the side. > > The consequence is high latency and high levels of background noise > for nodes just outside the direct radio range. > At the same time the risk of meeting a failing link is 4 times higher = =3D> > latency may be much more than 4 times larger. > > Latency may sound like a minor issue but it actually translates = directly > into lower battery lifetime. In the above (very realistic) example, > the battery lifetime is reduced to 25% of what it should be. > > We have lots of battery devices sending into the network: > * PIR sensors turning on lights > * Door locks sending alarms > * Door/window sensors starting chimes > * Smoke sensors triggering an alarm system > > > > > Response time > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > The latency issue is important. > When a user (real human being) presses a light button the user expects > the light to turn on. > cRPLp proposes that nodes in the tree periodically advertises their > presence using DAOs. > The periodicity is a real beast: > Thanks to Trickle, the rate of updates in a (apparently) stable = network > is low. This is good since it leaves bandwidth for data. > But it is not good if existing routes to my lamp fail and I do not get > new routes to my lamp until it decides to send out a new DAO. > My user will (with a good reason) not tolerate waiting for minutes for > the light to turn on. > > I have met two arguments to counter this concern: > > A1: Well, your lamp can always send a DAO when it detects a problem. > My answer: > True, except that my lamp does not intend to send anything > so it will never experience any problems from its side of the = network. > > A2: Well, you can increase the DAO rate to sub-second updates. > My answer: > Oh no. I get a very high degree of management traffic which > limits my available bandwidth, increases the risk of collisions and > even run the risk of violating EU legislation requiring me to only > transmit in less than 1% of the time: > http://focus.ti.com/lit/an/swra048/swra048.pdf > 868 - 868.6 MHz: <1% > > Reactiveness is hard to achieve via polling. > > > > If you agree that this seems to be critical issues please raise your > voice on the list. > > Going forward > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > We need some reactive mechanism to reach lamps before the user decides > to sue our companies. > So is this possible? I think so. > > Existing commercial (non-IP) solutions are capable of re-routing = quickly > if they really have to. > > Let me try scoping the requirements to a potential solution: > (no different from the req. docs for home and building) > > * P2P routing in any direction independent of the tree. > > * On-demand P2P route discovery if requested by a real-time critical = app. > Data collection apps may be able to just wait for the next DAO = update. > > * Limited range of discovery mechanism: max 4 repeaters. > A TTL field may limit the scope of the repeaters. > > * Suboptimal routing and traffic bursts are accepted in exchange > for quick route repair. But only as an exception. > > > Just as an example, one existing home control technology uses a > (source routing) variant of AODV for quick route repair. > Nothing comes for free. The price is flooding - but not just flooding: > Managed flooding using a distributed algorithm running in all > participating nodes. > The algorithm dampens the flooding in a time, volume and range > perspective. > Some similar mechanism could be built into RPL for quick route repair. > > > If anyone have alternative proposals, please bring it to the list. > Now is the time. > > > > Thanks, > Anders > > > > > _______________________________________________ > Roll mailing 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_01CAC91D.92360FAC Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [Roll] P2P performance with current RPL = proposal

Hi Don and Anders,

The existence of small sets of things tied together, like the lamp(s) = and the switch(es), or the remote and the TV, etc…, is what enable = a P2P optimization within the sets that’s cheaper than the general = any to any.

 

I can understand that the end-user should be mostly transparent to = this. But figuring out which nodes are in which sets is an application = thing and out of scope for RPL. You give RPL a set of IP addresses and = RPL builds on-demand routes between those.

 

Some additional optimizations are possible with RPL. For=A0 instance, = one on-demand DAG with multiple targets is cheaper and more efficient = than one DAG per target. But an optimization like this can only happen = if the something that builds the sets is smart enough to benefit from = those in the first place.

 

Pascal

 

From:= = Don Sturek [mailto:d.sturek@att.net]
Sent: Sunday, March 21, = 2010 8:08 AM
To: 'Anders Brandt'; Pascal Thubert (pthubert); = 'Mukul Goyal'
Cc: 'ROLL WG'; 'Ted Humpal'
Subject: = RE: [Roll] P2P performance with current RPL = proposal

 

Hi Anders,

 

Let me add one more point.

 

In a Smart Energy Home Area Network, the customer should not even = know there is a network let alone have any role in commissioning.  = Network formation and joining needs to happen autonomously and P2P = routing needs to be enabled and made to work without any action from the = customer.

 

Don

 

From:= = roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of = Anders Brandt
Sent: Sunday, March 21, 2010 12:58 = AM
To: Pascal Thubert (pthubert); Mukul Goyal
Cc: = ROLL WG; Ted Humpal
Subject: Re: [Roll] P2P performance with = current RPL proposal

 

P= ascal wrote:

 

&= gt;- A P2P path does not come out of the blue. There must be some = provisionning system that determines

&= gt;that those nodes, A and B, are very special so they need a P2P = optimization, with a given special OF,

&= gt;and that they both need to talk to D. Well, if

 

I would = claim that in a home control environment they have to come out of the = blue!

I need = application association and low-latency control to work beyond direct = range an my users have NO
interest in setting up network rules for = provisioning, etc.

Sorry.=

 

- = Anders

 

 

Fra:<= /b> = roll-bounces@ietf.org p=E5 vegne af Pascal Thubert = (pthubert)
Sendt: fr 19-03-2010 17:20
Til: Mukul = Goyal
Cc: ROLL WG; Ted Humpal
Emne: Re: [Roll] P2P = performance with current RPL proposal

Hi Mukul
> Here I have attempted to = formulate a simple DV algorithm in RPL/DAG terms.
> I will = appreciate it if you could let me know about your objections to = this
> proposal:

[Pascal] It's cool that you do it is the = first impression.

> Node A needs to reach a destination D. = Node A initiates a discovery DAG
> towards D. As the DIOs reach D, = it sends a DAO back to selected parents. As
> the DAO travels = towards node A, in-route nodes store the cost to reach = D.
>
> When node B needs to reach D, it similarly initiates = a discovery dag. During
> this discovery, when a DIO reaches a = node C that maintains a cost to reach D,
> node C responds back = with a DAO that travels towards B and stores in in-
> route nodes = the cost to reach D.

[Pascal]  understand that you're trying = to make RPL even closer to AODV.
I agree we need to gather as much as = we can from that work.

For the specifics of your = proposal:

- B-C might be orthogonal to A-D so that B/C\D forms an = angle. You do not end up with the best path that you're looking = for.

- there might be multiple C's. Which one is the right = one?

- RPL does not allow packets to switch instances. Following = multiple DAGs is the recipe for loops - unless you have them strictly = ordered by some means like the RPL sequence between iterations, more = specific routes, blah blah...)

- the A to D path is optimized for = a certain constraint. You seem to imply that the B to D path has the = same constraints and metrics so we can compare apple to apple. Because = this is a very delicate operation, RPL has introduced the Rank, which = has the right properties to make that comparison efficiently.So for RPL, = the loop avoidance metric is the Rank, and it is only valid within an = iteration.

- A P2P path does not come out of the blue. There must = be some provisionning system that determines that those nodes, A and B, = are very special so they need a P2P optimization, with a given special = OF, and that they both need to talk to D. Well, if that's so, the most = economical is for that system to fork the DAG out of D, with dual = targets A and B. There you obtain the shortest path for both A-D and B-D = for the cost of a single flooding.

I see that you're trying to = get the idea to work better, and I hope we find a way to do so, maybe = along your lines if we can solve the issues above. But before we get = there, we need to agree that this is the path we wish to = take.

Cheers,

Pascal


>
> ----- = Original Message -----
> From: "Pascal Thubert = (pthubert)" <pthubert@cisco.com>
> To: "robert = cragie" <robert.cragie@gridmerge.com>
> Cc: "ROLL = WG" <roll@ietf.org>, "Ted Humpal" = <Ted.Humpal@jci.com>
> Sent: Thursday, March 18, 2010 = 9:23:14 PM GMT -06:00 US/Canada Central
> Subject: Re: [Roll] P2P = performance with current RPL = proposal
>
>
>
>
>
> Hi = Robert :
>
>
>
> At least from a distance, = the proposed mechanism emulates AODV, with the
> DIO as RREQ and = the DAO as RREP. So if we decide to dig along those lines,
> = we’ll certainly appreciate help from MANET experts. I’d say = that if you
> already have RPL for P2MP and MP2P, the proposed = extension are probably
> simpler to add than doing AODV from = scratch.
>
>
>
> For the setup, the major = differences are that we build a DAG and that we can
> indicate = multiple targets. If you look at it, the DAG capability is a MUST = for
> RPL, and I have not seen that this MUST goes away for P2P = flows. The
> multiple targets is something that appears in a = number of use cases and it
> seems more economical to build a = single DAG for multiple targets when
> = possible.
>
>
>
> For the maintenance, the major = differences are that we have the DAG as
> first line of defense, = and the RPL detection to stimulate the local = repair.
>
>
>
> About your = questions:
>
>
>
> The DODAG root is the one = that spawns the DAG. The targets can reach the
> root because the = root advertises itself in the DIO. The idea is that the root ID
> = is the address that the targets need to talk to. If needed, the root can = also
> advertise a prefix that it can reach and that the targets = need to reach too.
>
>
>
> All the intermediate = nodes that are confirmed by the DAO need to retain at
> least info = about the DAG. That enables the targets to reach the root. The
> = flooding should cost about the same as that of AODV but the RPL way = will
> require more states in the nodes on the way if the OF = requires a DAG.
>
>
>
> The way back (down) can = be stateful of stateless, depending on which DAO
> we’re = using. With fully stateful DAO, we are really in AODV-land. With
> = stateless, we could drift into DSR-land for that direction. Which limits = we
> place to keep it simple will be determined by the resolution = of issue #26 I
> guess…
>
>
>
> And = please, no apologize or on one will dare post anything anymore. = Your
> questions are fully relevant and at the core of the = discussion.
>
>
>
> I hope we can talk in = Anaheim for sure,
>
>
>
>
> = Pascal
>
>
>
>
>
>
> From: = Robert Cragie [mailto:robert.cragie@gridmerg= e.com]
> Sent: Monday, March 15, 2010 11:27 AM
> To: = Pascal Thubert (pth ubert)
> Cc: Ted.Humpal@jci.com; ROLL = WG
> Subject: Re: [Roll] P2P performance with current RPL = proposal
>
>
>
> Hi Pascal,
>
> So = in your slideware T can end up talking to R (DODAG root) through = the
> DODAG. So are you proposing that all potential targets can = act as a DODAG
> root? And therefore all intermediates have to = retain DIO propagation
> support for that DODAG as well? This may = work for limited P2P but seems
> less efficient than simple = distance vector flooding RREQ/RREP like AODV or
> DYMO for generic = P2P. What about R to T (or anyone else for that matter)?
> Do we = source route, maintain state, some undefined hybrid of the = two?
>
> I apologise if some of these questions have been = answered in detail in earlier
> reflector posts but I have only = recently started to concentrate my efforts on
> RPL and have 82 = pages to wade through :-). I look forward to a productive
> = session in Anaheim.
>
> Robert
>
>
> = Robert Cragie (Pacific Gas & Electric)
>
> Gridmerge = Ltd.
> 89 Greenfield Crescent,
> Wakefield, WF4 4WA, = UK
> +44 (0) 1924 910888
> http://www.gridmerge.com
>>
>
> Pascal Thubert (pthubert) wrote:
>
> = HI Robert :
>
>
>
> I respectfully have to = disagree.
>
>
>
> My understanding is that we = are considering a limited set of P2P pairs, for
> which the = specific path that we need to create might have to obey specific
> = constraints.
>
> So it makes sense to use an on-demand = technique, probably inspired by the
> MANET Reactive = protocols.
>
>
>
> As it goes, those protocols = usually use flooding for a node to locate another.
> Forking a DAG = is just another flooding. It does not take a lot of addition to = the
> existing DIO for a root to use RPL to build a DAG that = contains one or multiple
> Targets as leaves, under a set of = constraints expressed as an objective
> function. Please find = attached a slideware that illustrates = that.
>
>
>
>
> = Pascal
>
>
>
>
>
>
> From: = roll-bounces@ietf.org [ mailto:roll-bounces@ietf.org ] = On Behalf Of
> Robert Cragie
> Sent: Thursday, March 11, = 2010 2:43 PM
> To: Ted.Humpal@jci.com
> Cc: ROLL WG
> = Subject: Re: [Roll] P2P performance with current RPL = proposal
>
>
>
> I agree with Ted's comments = below. Creating a DODAG for every reachable
> node as a root seems = a very inefficient approach compared to alternative
> routing = algorithms. I am concerned that RPL does not actually meet the
> = original requirements in I-D.ietf-roll-building-routing-reqs, = I-D.ietf-roll-home-
> routing-reqs, RFC5673 and RFC5548. The = traffic pattern requirement for a
> sink node features prominently = in only two of those documents. Even in this
> case, as Ted points = out, communication is likely to be bidirectional (e.g. end-
> = to-end acks.) therefore the DODAG approach is fundamentally = asymmetric,
> especially if no intermediate storage is allowed for = destination routes and
> source routing has to be = used.
>
> Also, RPL seems highly complex for what are = constrained nodes in terms of
> memory as well as power and = bandwidth. The RPL draft as it stands is 82
> pages long and that = doesn't include text about the objective function.
>
> = Robert
>
>
> Robert Cragie (Pacific Gas & = Electric)
>
> Gridmerge Ltd.
> 89 Greenfield = Crescent,
> Wakefield, WF4 4WA, UK
> +44 (0) 1924 = 910888
> http://www.gridmerge.com
>>
>
> Ted.Humpal@jci.com wrote:
>
>
> = A concern also will be how much overhead (memory space) will be = required
> for a DODAG Root?
>
> and based on the = first question how many DODAG roots a lamp may need to
> be a = member of?
>
> For example in lighting  a single lamp = may be a root for a single switch (1
> DODAG root),  this = lamp / luminaire may also
> be a member of another group - - =  which could be all lights on the floor (2nd
> DODAG root), = and a third group
> of all the lights in the building.  There = can be many more speciality groups
> associated based on the = building configuration.
> Consider also during the installation = time - how these DODAG roots will be
> configured?  Must I = commission each device
> to tell it which DODAG it must use for = its Object Function?  How easy will this
> be to change and = add in a new DODAG root
> for the end user if the lighting group = changes??
>
> With respect to Jerry Martocci's - commercial = building requirements - every
> device may need to communicate to = any or
> all of the end devices.  If each device must = establish a DODAG for the other
> 499 devices in a 500 node = network - How much memory
> space will this require for each end = device to maintain?
>
> Keep in mind that the end devices = are very limited processor and memory
> wise.
>
> Not = to mention all of the network maintenance messages that would = need
> to be transmitted to maintain all of these = DODAGs.
>
> Consider the reconvergence time when one device = is turned off and it was in
> the middle of the majority of the = 100+ DODAGS?
>
> In many lighting and building application = an application acknowledgement -
> must be returned {Back down the = DODAG} so . . . the
> requirement is not just getting to the Root = - a return path must also be
> maintained and have a  low = latency path.
>
> Ted = Humpal
>
>
>
>
>
>
> = From:
>
> Kris Pister = <pister@eecs.berkeley.edu>
>
>
> = To:
>
> Anders Brandt = <abr@sdesigns.dk>
>
>
> Cc:
>
> ROLL = WG <roll@ietf.org>
>
>
> Date:
>
> = 03/08/2010 01:45 PM
>
>
> Subject:
>
> Re: = [Roll] P2P performance with current RPL = proposal
>
>
>
>
>
>
>
><= br>> Anders - if we take JP's suggestion to make The Lamp a DODAG = root, and
> take Phoebus' recommendation that we use path = diversity to improve end-
> to-end reliability, do you see a = chance of success?
> In my experience, with diverse paths and = order-minutes updates you get
> extremely high = reliability.
>
> I have no aversion to TTL-limited floods as = a part of a solution either.  I'm
> open to ideas on how to = bring those in as (presumably infrequently used)
> = options.
>
> ksjp
>
> Anders Brandt = wrote:
> Hello
>
> I would like to probe the = temperature of the WG on using DAOs to
> support = P2P.
>
> The building and home application spaces (and maybe = others) have
> a few clearly defined requirements.
> It is = not obvious to me how the current RPL proposal (cRPLp) can
> = satisfy those requirements:
>
>
> In both cases it is = the worst case scenario that hurts:
>
>
> P2P routing = inside the PAN
> = =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
> cRPLp has no way of routing inside the PAN if you need more = than
> one repeater. cRPLp has to go all the way to the top (maybe = 4 hops up)
> and down again (maybe 4 hops down) to get just 2 hops = to the side.
>
> The consequence is high latency and high = levels of background noise
> for nodes just outside the direct = radio range.
> At the same time the risk of meeting a failing link = is 4 times higher =3D>
> latency may be much more than 4 times = larger.
>
> Latency may sound like a minor issue but it = actually translates directly
> into lower battery lifetime. In the = above (very realistic) example,
> the battery lifetime is reduced = to 25% of what it should be.
>
> We have lots of battery = devices sending into the network:
> * PIR sensors turning on = lights
> * Door locks sending alarms
> * Door/window sensors = starting chimes
> * Smoke sensors triggering an alarm = system
>
>
>
>
> Response time
> = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> The latency issue is = important.
> When a user (real human being) presses a light button = the user expects
> the light to turn on.
> cRPLp proposes = that nodes in the tree periodically advertises their
> presence = using DAOs.
> The periodicity is a real beast:
> Thanks to = Trickle, the rate of updates in a (apparently) stable network
> is = low. This is good since it leaves bandwidth for data.
> But it is = not good if existing routes to my lamp fail and I do not get
> new = routes to my lamp until it decides to send out a new DAO.
> My = user will (with a good reason) not tolerate waiting for minutes = for
> the light to turn on.
>
> I have met two = arguments to counter this concern:
>
> A1: Well, your lamp = can always send a DAO when it detects a problem.
>   My = answer:
>   True, except that my lamp does not intend to send = anything
>   so it will never experience any problems from = its side of the network.
>
> A2: Well, you can increase the = DAO rate to sub-second updates.
>   My answer:
>   = Oh no. I get a very high degree of management traffic which
> =   limits my available bandwidth, increases the risk of collisions = and
>   even run the risk of violating EU legislation = requiring me to only
>   transmit in less than 1% of the = time:
>   http://focus.ti.c= om/lit/an/swra048/swra048.pdf
>  868 - 868.6 MHz: = <1%
>
>   Reactiveness is hard to achieve via = polling.
>
>
>
> If you agree that this seems to = be critical issues please raise your
> voice on the = list.
>
> Going forward
> = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>
> We need some = reactive mechanism to reach lamps before the user decides
> to sue = our companies.
> So is this possible? I think so.
>
> = Existing commercial (non-IP) solutions are capable of re-routing = quickly
> if they really have to.
>
> Let me try = scoping the requirements to a potential solution:
> (no different = from the req. docs for home and building)
>
> * P2P routing = in any direction independent of the tree.
>
> * On-demand = P2P route discovery if requested by a real-time critical app.
> =  Data collection apps may be able to just wait for the next DAO = update.
>
> * Limited range of discovery mechanism: max 4 = repeaters.
>   A TTL field may limit the scope of the = repeaters.
>
> * Suboptimal routing and traffic bursts are = accepted in exchange
>   for quick route repair. But only as = an exception.
>
>
> Just as an example, one existing = home control technology uses a
> (source routing) variant of AODV = for quick route repair.
> Nothing comes for free. The price is = flooding - but not just flooding:
> Managed flooding using a = distributed algorithm running in all
> participating = nodes.
> The algorithm dampens the flooding in a time, volume and = range
> perspective.
> Some similar mechanism could be built = into RPL for quick route repair.
>
>
> If anyone have = alternative proposals, please bring it to the list.
> Now is the = time.
>
>
>
> Thanks,
>   = Anders
>
>
>
>
> = _______________________________________________
> Roll mailing = 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_01CAC91D.92360FAC-- From pthubert@cisco.com Sun Mar 21 10:50: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 4B94E3A69FD for ; Sun, 21 Mar 2010 10:50:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.255 X-Spam-Level: X-Spam-Status: No, score=-4.255 tagged_above=-999 required=5 tests=[AWL=-2.786, 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 nglnW1CqvNm9 for ; Sun, 21 Mar 2010 10:50:37 -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 612F93A69A6 for ; Sun, 21 Mar 2010 10:50: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: AigBAJ/5pUuQ/uCWe2dsb2JhbACbOxUBAQsLJAYcoDSXYIR9BA X-IronPort-AV: E=Sophos;i="4.51,283,1267401600"; d="scan'208";a="4607841" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-2.cisco.com with ESMTP; 21 Mar 2010 17:16: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 o2LHoobC020791; Sun, 21 Mar 2010 17:50:50 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, 21 Mar 2010 18:50:50 +0100 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, 21 Mar 2010 18:50:46 +0100 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D0180D615@XMB-AMS-107.cisco.com> In-Reply-To: <008601cac7c3$9fb4d920$df1e8b60$@sturek@att.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] When source routing fails... Thread-Index: AcrHkCtZ8BeuzohiSAyn1ll2nwrlSgAMyZLAAFamslA= References: <008601cac7c3$9fb4d920$df1e8b60$@sturek@att.net> From: "Pascal Thubert (pthubert)" To: "Jonathan Hui" , "ROLL WG" X-OriginalArrivalTime: 21 Mar 2010 17:50:50.0182 (UTC) FILETIME=[0B27FE60:01CAC91F] Cc: Robert Assimiti Subject: Re: [Roll] When source routing fails... X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 21 Mar 2010 17:50:38 -0000 Hi Jonathan: I'm with Don on this. Robert has recently expressed the concern that we'll need to inform the root on some events and this is probably such an event. With the current spec the cache with the obsolete source route info is not necessarily the root. So we end up with the requirement to be able to send an exception back up the DAG, either to an ancestor or the root itself. If what we are doing with this event is really RPL specific, then maybe it's better to have our own message as opposed to consumed ICMP space. What do you think? Pascal > -----Original Message----- > From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of > Don Sturek > Sent: Friday, March 19, 2010 5:24 PM > To: 'Jonathan Hui'; 'ROLL WG' > Subject: Re: [Roll] When source routing fails... >=20 > Hi Jonathan, >=20 > For unreachable destinations, action 2 is best (Drop the packet and send back > an ICMPv6 error or RPL message indicating where the route failed). I would > prefer selection of a single action since this reduces options and complexity. >=20 > Don >=20 >=20 > -----Original Message----- > From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of > Jonathan Hui > Sent: Friday, March 19, 2010 11:15 AM > To: ROLL WG > Subject: [Roll] When source routing fails... >=20 >=20 > ROLL WG, >=20 > RPL-07 currently supports routers that do not maintain downward routing > state. To route through these 'non-storing' nodes, it is expected that an > ancestor node will maintain state about the downward routing topology and > utilize source routing. >=20 > When routing information no longer correctly reflects changes in link > connectivity, a storing node may attempt to utilize a path that can no longer > reach the intended destination. With source routing, the delivery failure may > occur several hops away, or more generally anywhere between the storing > node and the destination. RPL-07 currently does not make any attempt to > specify what actions a non- storing node should take when using source > route information fails. >=20 > A few obvious actions are: >=20 > 1) Drop the packet and nothing else. This is the most simple option and has > the benefit that routing failures do not generate any extra traffic. Route > repair timescales are dependent on control traffic rather than data traffic. >=20 > 2) Drop the packet and send back an ICMPv6 error or RPL message indicating > where the route failed. Allows quick notification to a storing node that route > information is invalid. Route repair > timescales are dependent on data traffic rather than control traffic. > While this generates extra control traffic on link failures, the error/ repair > messages can be small and constant size. Rate limiting can be used to bound > error/repair message generation. >=20 > 3) Backtrack by returning the packet towards the root and indicating where > the route failed. Implements a form of depth-first search and gives the data > packet another chance to reach its destination. Allows quick notification to a > storing node that route information is invalid. Route repair on timescales are > dependent on data traffic rather than control traffic. While this does not > generate any extra control traffic per-se, data packets that experience > source route failures can remain "live" within the network for extended > periods of time. If these data packets or failures occur repeatedly, channel > utilization can increase unexpectedly while data packets traverse up and > down the DAG. >=20 > On a separate dimension, it is important to note that the above options are > not mutually exclusive and we have the following options: >=20 > 1) Specify only a single action when source route failures occur. >=20 > 2) Provide an option that can select which action to take on a per- instance, > per-dag, or per-packet basis. The per-packet option may be specified as part > of the source route information or based on the payload (e.g. simply drop > ICMPv6 errors but backtrack UDP datagrams). >=20 > What are other people's thoughts? Are there additional pros/cons of the > options above? Are there other options that we should consider? >=20 > -- > Jonathan Hui >=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 From prvs=690d97458=mukul@uwm.edu Mon Mar 22 00:46: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 A7F5B3A6833 for ; Mon, 22 Mar 2010 00:46:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.926 X-Spam-Level: X-Spam-Status: No, score=-0.926 tagged_above=-999 required=5 tests=[AWL=-1.257, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, J_CHICKENPOX_12=0.6, J_CHICKENPOX_17=0.6, J_CHICKENPOX_51=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 jXrWPE1C-d1K for ; Mon, 22 Mar 2010 00:46:45 -0700 (PDT) Received: from ip1mta.uwm.edu (ip1mta.uwm.edu [129.89.7.18]) by core3.amsl.com (Postfix) with ESMTP id 42FCB3A681C for ; Mon, 22 Mar 2010 00:46:45 -0700 (PDT) Received: from mta02.pantherlink.uwm.edu ([129.89.7.82]) by ip1mta.uwm.edu with ESMTP; 22 Mar 2010 02:47:01 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by mta02.pantherlink.uwm.edu (Postfix) with ESMTP id ADAE62C3800E; Mon, 22 Mar 2010 02:47:01 -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 A-yQdg7pL+Ho; Mon, 22 Mar 2010 02:47:00 -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 E98A02C3800D; Mon, 22 Mar 2010 02:47:00 -0500 (CDT) Date: Mon, 22 Mar 2010 02:47:00 -0500 (CDT) From: Mukul Goyal To: "Pascal Thubert (pthubert)" Message-ID: <1161577952.8138041269244020805.JavaMail.root@mail02.pantherlink.uwm.edu> In-Reply-To: <6A2A459175DABE4BB11DE2026AA50A5D01793172@XMB-AMS-107.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Originating-IP: [129.89.7.91] X-Mailer: Zimbra 5.0.22_GA_3210.RHEL4_64 (ZimbraWebClient - [unknown] (Win)/5.0.22_GA_3210.RHEL4_64) X-Authenticated-User: mukul@uwm.edu Cc: ROLL WG , Ted Humpal Subject: Re: [Roll] P2P performance with current RPL proposal X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Mar 2010 07:46:47 -0000 Hi Pascal Thanks for your comments (let me send my response in the next email).=20 Based on further thoughts, it seems to me that a DAG based P2P solution wou= ld work if we do the following: (a) allowing multicast DIS messages to spread to an originator-specified nu= mber of hops and=20 (b) allowing nodes to join a DAG temporarily and leave it if there is not s= ufficient =E2=80=9Crouting interest=E2=80=9D in being part of the DAG. With these points in mind, a P2P scheme could work as follows: 1. When a node wants to join a DODAG(D,F), where D is the DODAG's root and = F is the OF being used, it does the following: a. Initiates a discovery table entry for DODAG(D,F). The discovery tabl= e entries are removed after a certain lifetime. b. sends out a DIS via link-local multicast asking specifically for inf= ormation about DODAG(D,F). It also lists in the DIS the number of hops the = DIS can travel. 2. On receiving a DIS, a node does the following: a.if it does not know about DODAG(D,F) and the DIS hop limit is not yet= reached=20 i. Initiates a discovery table entry for DODAG(D,F). This entry mai= ntains information about the nodes from whom the DIS were received. ii. sends out the DIS (via link-local multicast with trickle contro= lled timing) further. b. If it is already a part of DODAG(D,F) or is node D itself i. Send out a DIO about DODAG(D,F) to the node from whom the DIS wa= s received. 3. On receiving a DIO about DODAG(D,F), a node does the following: a. Ignore the DIO if the node does not have a discovery table entry for= DODAG(D,F) b. Otherwise, the node joins the DODAG(D,F) (if not already part of it)= or updates its parent set in DODAG(D,F) and sends the DIO by unicast to th= e nodes that had sent it the DIS. 4. Once, the node is part of the DODAG(D,F), it maintains a =E2=80=9Croutin= g interest=E2=80=9D for the DODAG in the following manner: a. Routing interest is a value between 0 and 1 b. Routing interest is 1 if the node recently forwarded a packet along = the DODAG(D,F) c. Otherwise, the routing interest is x*maximum routing interest of the= neighbors in DODAG(D,F), where x is a fraction. The node comes to know of = neighbor=E2=80=99s routing interest via the neighbor=E2=80=99s DIO.=20 d. A node leaves a DODAG if its routing interest in the DODAG goes belo= w a threshold. Thanks Mukul ----- Original Message ----- From: "Pascal Thubert (pthubert)" To: "Mukul Goyal" Cc: "ROLL WG" , "Ted Humpal" , "robert c= ragie" Sent: Friday, March 19, 2010 11:20:58 AM GMT -06:00 US/Canada Central Subject: RE: [Roll] P2P performance with current RPL proposal Hi Mukul > Here I have attempted to formulate a simple DV algorithm in RPL/DAG terms= . > I will appreciate it if you could let me know about your objections to th= is > proposal: [Pascal] It's cool that you do it is the first impression. =20 > Node A needs to reach a destination D. Node A initiates a discovery DAG > towards D. As the DIOs reach D, it sends a DAO back to selected parents. = As > the DAO travels towards node A, in-route nodes store the cost to reach D. >=20 > When node B needs to reach D, it similarly initiates a discovery dag. Dur= ing > this discovery, when a DIO reaches a node C that maintains a cost to reac= h D, > node C responds back with a DAO that travels towards B and stores in in- > route nodes the cost to reach D. [Pascal] understand that you're trying to make RPL even closer to AODV. I agree we need to gather as much as we can from that work.=20 For the specifics of your proposal: - B-C might be orthogonal to A-D so that B/C\D forms an angle. You do not e= nd up with the best path that you're looking for. - there might be multiple C's. Which one is the right one? - RPL does not allow packets to switch instances. Following multiple DAGs i= s the recipe for loops - unless you have them strictly ordered by some mean= s like the RPL sequence between iterations, more specific routes, blah blah= ...) - the A to D path is optimized for a certain constraint. You seem to imply = that the B to D path has the same constraints and metrics so we can compare= apple to apple. Because this is a very delicate operation, RPL has introdu= ced the Rank, which has the right properties to make that comparison effici= ently.So for RPL, the loop avoidance metric is the Rank, and it is only val= id within an iteration. - A P2P path does not come out of the blue. There must be some provisionnin= g system that determines that those nodes, A and B, are very special so the= y need a P2P optimization, with a given special OF, and that they both need= to talk to D. Well, if that's so, the most economical is for that system t= o fork the DAG out of D, with dual targets A and B. There you obtain the sh= ortest path for both A-D and B-D for the cost of a single flooding. I see that you're trying to get the idea to work better, and I hope we find= a way to do so, maybe along your lines if we can solve the issues above. B= ut before we get there, we need to agree that this is the path we wish to t= ake. Cheers, Pascal =20 >=20 > ----- Original Message ----- > From: "Pascal Thubert (pthubert)" > To: "robert cragie" > Cc: "ROLL WG" , "Ted Humpal" > Sent: Thursday, March 18, 2010 9:23:14 PM GMT -06:00 US/Canada Central > Subject: Re: [Roll] P2P performance with current RPL proposal >=20 >=20 >=20 >=20 >=20 > Hi Robert=C2=A0: >=20 >=20 >=20 > At least from a distance, the proposed mechanism emulates AODV, with the > DIO as RREQ and the DAO as RREP. So if we decide to dig along those lines= , > we=E2=80=99ll certainly appreciate help from MANET experts. I=E2=80=99d s= ay that if you > already have RPL for P2MP and MP2P, the proposed extension are probably > simpler to add than doing AODV from scratch. >=20 >=20 >=20 > For the setup, the major differences are that we build a DAG and that we = can > indicate multiple targets. If you look at it, the DAG capability is a MUS= T for > RPL, and I have not seen that this MUST goes away for P2P flows. The > multiple targets is something that appears in a number of use cases and i= t > seems more economical to build a single DAG for multiple targets when > possible. >=20 >=20 >=20 > For the maintenance, the major differences are that we have the DAG as > first line of defense, and the RPL detection to stimulate the local repai= r. >=20 >=20 >=20 > About your questions: >=20 >=20 >=20 > The DODAG root is the one that spawns the DAG. The targets can reach the > root because the root advertises itself in the DIO. The idea is that the = root ID > is the address that the targets need to talk to. If needed, the root can = also > advertise a prefix that it can reach and that the targets need to reach t= oo. >=20 >=20 >=20 > All the intermediate nodes that are confirmed by the DAO need to retain a= t > least info about the DAG. That enables the targets to reach the root. The > flooding should cost about the same as that of AODV but the RPL way will > require more states in the nodes on the way if the OF requires a DAG. >=20 >=20 >=20 > The way back (down) can be stateful of stateless, depending on which DAO > we=E2=80=99re using. With fully stateful DAO, we are really in AODV-land.= With > stateless, we could drift into DSR-land for that direction. Which limits = we > place to keep it simple will be determined by the resolution of issue #26= I > guess=E2=80=A6 >=20 >=20 >=20 > And please, no apologize or on one will dare post anything anymore. Your > questions are fully relevant and at the core of the discussion. >=20 >=20 >=20 > I hope we can talk in Anaheim for sure, >=20 >=20 >=20 >=20 > Pascal >=20 >=20 >=20 >=20 >=20 >=20 > From: Robert Cragie [mailto:robert.cragie@gridmerge.com] > Sent: Monday, March 15, 2010 11:27 AM > To: Pascal Thubert (pth ubert) > Cc: Ted.Humpal@jci.com; ROLL WG > Subject: Re: [Roll] P2P performance with current RPL proposal >=20 >=20 >=20 > Hi Pascal, >=20 > So in your slideware T can end up talking to R (DODAG root) through the > DODAG. So are you proposing that all potential targets can act as a DODAG > root? And therefore all intermediates have to retain DIO propagation > support for that DODAG as well? This may work for limited P2P but seems > less efficient than simple distance vector flooding RREQ/RREP like AODV o= r > DYMO for generic P2P. What about R to T (or anyone else for that matter)? > Do we source route, maintain state, some undefined hybrid of the two? >=20 > I apologise if some of these questions have been answered in detail in ea= rlier > reflector posts but I have only recently started to concentrate my effort= s on > RPL and have 82 pages to wade through :-). I look forward to a productive > session in Anaheim. >=20 > Robert >=20 >=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 > Pascal Thubert (pthubert) wrote: >=20 > HI Robert=C2=A0: >=20 >=20 >=20 > I respectfully have to disagree. >=20 >=20 >=20 > My understanding is that we are considering a limited set of P2P pairs, f= or > which the specific path that we need to create might have to obey specifi= c > constraints. >=20 > So it makes sense to use an on-demand technique, probably inspired by the > MANET Reactive protocols. >=20 >=20 >=20 > As it goes, those protocols usually use flooding for a node to locate ano= ther. > Forking a DAG is just another flooding. It does not take a lot of additio= n to the > existing DIO for a root to use RPL to build a DAG that contains one or mu= ltiple > Targets as leaves, under a set of constraints expressed as an objective > function. Please find attached a slideware that illustrates that. >=20 >=20 >=20 >=20 > Pascal >=20 >=20 >=20 >=20 >=20 >=20 > From: roll-bounces@ietf.org [ mailto:roll-bounces@ietf.org ] On Behalf Of > Robert Cragie > Sent: Thursday, March 11, 2010 2:43 PM > To: Ted.Humpal@jci.com > Cc: ROLL WG > Subject: Re: [Roll] P2P performance with current RPL proposal >=20 >=20 >=20 > I agree with Ted's comments below. Creating a DODAG for every reachable > node as a root seems a very inefficient approach compared to alternative > routing algorithms. I am concerned that RPL does not actually meet the > original requirements in I-D.ietf-roll-building-routing-reqs, I-D.ietf-ro= ll-home- > routing-reqs, RFC5673 and RFC5548. The traffic pattern requirement for a > sink node features prominently in only two of those documents. Even in th= is > case, as Ted points out, communication is likely to be bidirectional (e.g= . end- > to-end acks.) therefore the DODAG approach is fundamentally asymmetric, > especially if no intermediate storage is allowed for destination routes a= nd > source routing has to be used. >=20 > Also, RPL seems highly complex for what are constrained nodes in terms of > memory as well as power and bandwidth. The RPL draft as it stands is 82 > pages long and that doesn't include text about the objective function. >=20 > Robert >=20 >=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 > Ted.Humpal@jci.com wrote: >=20 >=20 > A concern also will be how much overhead (memory space) will be required > for a DODAG Root? >=20 > and based on the first question how many DODAG roots a lamp may need to > be a member of? >=20 > For example in lighting =C2=A0a single lamp may be a root for a single sw= itch (1 > DODAG root), =C2=A0this lamp / luminaire may also > be a member of another group - - =C2=A0which could be all lights on the f= loor (2nd > DODAG root), and a third group > of all the lights in the building. =C2=A0There can be many more specialit= y groups > associated based on the building configuration. > Consider also during the installation time - how these DODAG roots will b= e > configured? =C2=A0Must I commission each device > to tell it which DODAG it must use for its Object Function? =C2=A0How eas= y will this > be to change and add in a new DODAG root > for the end user if the lighting group changes?? >=20 > With respect to Jerry Martocci's - commercial building requirements - eve= ry > device may need to communicate to any or > all of the end devices. =C2=A0If each device must establish a DODAG for t= he other > 499 devices in a 500 node network - How much memory > space will this require for each end device to maintain? >=20 > Keep in mind that the end devices are very limited processor and memory > wise. >=20 > Not to mention all of the network maintenance messages that would need > to be transmitted to maintain all of these DODAGs. >=20 > Consider the reconvergence time when one device is turned off and it was = in > the middle of the majority of the 100+ DODAGS? >=20 > In many lighting and building application an application acknowledgement = - > must be returned {Back down the DODAG} so . . . the > requirement is not just getting to the Root - a return path must also be > maintained and have a =C2=A0low latency path. >=20 > Ted Humpal >=20 >=20 >=20 >=20 >=20 >=20 > From: >=20 > Kris Pister >=20 >=20 > To: >=20 > Anders Brandt >=20 >=20 > Cc: >=20 > ROLL WG >=20 >=20 > Date: >=20 > 03/08/2010 01:45 PM >=20 >=20 > Subject: >=20 > Re: [Roll] P2P performance with current RPL proposal >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > Anders - if we take JP's suggestion to make The Lamp a DODAG root, and > take Phoebus' recommendation that we use path diversity to improve end- > to-end reliability, do you see a chance of success? > In my experience, with diverse paths and order-minutes updates you get > extremely high reliability. >=20 > I have no aversion to TTL-limited floods as a part of a solution either. = =C2=A0I'm > open to ideas on how to bring those in as (presumably infrequently used) > options. >=20 > ksjp >=20 > Anders Brandt wrote: > Hello >=20 > I would like to probe the temperature of the WG on using DAOs to > support P2P. >=20 > The building and home application spaces (and maybe others) have > a few clearly defined requirements. > It is not obvious to me how the current RPL proposal (cRPLp) can > satisfy those requirements: >=20 >=20 > In both cases it is the worst case scenario that hurts: >=20 >=20 > P2P routing inside the PAN > =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 > cRPLp has no way of routing inside the PAN if you need more than > one repeater. cRPLp has to go all the way to the top (maybe 4 hops up) > and down again (maybe 4 hops down) to get just 2 hops to the side. >=20 > The consequence is high latency and high levels of background noise > for nodes just outside the direct radio range. > At the same time the risk of meeting a failing link is 4 times higher =3D= > > latency may be much more than 4 times larger. >=20 > Latency may sound like a minor issue but it actually translates directly > into lower battery lifetime. In the above (very realistic) example, > the battery lifetime is reduced to 25% of what it should be. >=20 > We have lots of battery devices sending into the network: > * PIR sensors turning on lights > * Door locks sending alarms > * Door/window sensors starting chimes > * Smoke sensors triggering an alarm system >=20 >=20 >=20 >=20 > Response time > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > The latency issue is important. > When a user (real human being) presses a light button the user expects > the light to turn on. > cRPLp proposes that nodes in the tree periodically advertises their > presence using DAOs. > The periodicity is a real beast: > Thanks to Trickle, the rate of updates in a (apparently) stable network > is low. This is good since it leaves bandwidth for data. > But it is not good if existing routes to my lamp fail and I do not get > new routes to my lamp until it decides to send out a new DAO. > My user will (with a good reason) not tolerate waiting for minutes for > the light to turn on. >=20 > I have met two arguments to counter this concern: >=20 > A1: Well, your lamp can always send a DAO when it detects a problem. > =C2=A0 My answer: > =C2=A0 True, except that my lamp does not intend to send anything > =C2=A0 so it will never experience any problems from its side of the netw= ork. >=20 > A2: Well, you can increase the DAO rate to sub-second updates. > =C2=A0 My answer: > =C2=A0 Oh no. I get a very high degree of management traffic which > =C2=A0 limits my available bandwidth, increases the risk of collisions an= d > =C2=A0 even run the risk of violating EU legislation requiring me to only > =C2=A0 transmit in less than 1% of the time: > =C2=A0 http://focus.ti.com/lit/an/swra048/swra048.pdf > =C2=A0868 - 868.6 MHz: <1% >=20 > =C2=A0 Reactiveness is hard to achieve via polling. >=20 >=20 >=20 > If you agree that this seems to be critical issues please raise your > voice on the list. >=20 > Going forward > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > We need some reactive mechanism to reach lamps before the user decides > to sue our companies. > So is this possible? I think so. >=20 > Existing commercial (non-IP) solutions are capable of re-routing quickly > if they really have to. >=20 > Let me try scoping the requirements to a potential solution: > (no different from the req. docs for home and building) >=20 > * P2P routing in any direction independent of the tree. >=20 > * On-demand P2P route discovery if requested by a real-time critical app. > =C2=A0Data collection apps may be able to just wait for the next DAO upda= te. >=20 > * Limited range of discovery mechanism: max 4 repeaters. > =C2=A0 A TTL field may limit the scope of the repeaters. >=20 > * Suboptimal routing and traffic bursts are accepted in exchange > =C2=A0 for quick route repair. But only as an exception. >=20 >=20 > Just as an example, one existing home control technology uses a > (source routing) variant of AODV for quick route repair. > Nothing comes for free. The price is flooding - but not just flooding: > Managed flooding using a distributed algorithm running in all > participating nodes. > The algorithm dampens the flooding in a time, volume and range > perspective. > Some similar mechanism could be built into RPL for quick route repair. >=20 >=20 > If anyone have alternative proposals, please bring it to the list. > Now is the time. >=20 >=20 >=20 > Thanks, > =C2=A0 Anders >=20 >=20 >=20 >=20 > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > =C2=A0_______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll >=20 >=20 >=20 >=20 >=20 > =C2=A0 _______________________________________________ Roll mailing > 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 quentin.lampin@orange-ftgroup.com Mon Mar 22 01:09: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 991B63A69F4 for ; Mon, 22 Mar 2010 01:09:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.081 X-Spam-Level: * X-Spam-Status: No, score=1.081 tagged_above=-999 required=5 tests=[BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, HELO_EQ_FR=0.35, J_CHICKENPOX_32=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8DROkKidxPGu for ; Mon, 22 Mar 2010 01:09:52 -0700 (PDT) Received: from p-mail2.rd.francetelecom.com (p-mail2.rd.francetelecom.com [195.101.245.16]) by core3.amsl.com (Postfix) with ESMTP id CB1EC3A68FA for ; Mon, 22 Mar 2010 01:09:51 -0700 (PDT) Received: from p-mail2.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 1C739768009; Mon, 22 Mar 2010 09:14:18 +0000 (UTC) Received: from ftrdsmtp2.rd.francetelecom.fr (unknown [10.192.128.47]) by p-mail2.rd.francetelecom.com (Postfix) with ESMTP id 144AD6FCC26; Mon, 22 Mar 2010 09:14:18 +0000 (UTC) Received: from ftrdmel10.rd.francetelecom.fr ([10.192.128.44]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Mon, 22 Mar 2010 09:10:08 +0100 Received: from [10.194.4.239] ([10.194.4.239]) by ftrdmel10.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Mon, 22 Mar 2010 09:10:07 +0100 Message-ID: Date: Mon, 22 Mar 2010 09:10:06 +0100 From: User-Agent: Thunderbird 2.0.0.23 (X11/20090817) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.4073 MIME-Version: 1.0 To: "Pascal Thubert \(pthubert\)" References: <6A2A459175DABE4BB11DE2026AA50A5D0180D60F@XMB-AMS-107.cisco.com> In-Reply-To: <6A2A459175DABE4BB11DE2026AA50A5D0180D60F@XMB-AMS-107.cisco.com> Content-Type: text/plain; format=flowed; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 22 Mar 2010 08:10:07.0228 (UTC) FILETIME=[158CE3C0:01CAC997] Cc: roll@ietf.org Subject: Re: [Roll] Options in DIS X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 22 Mar 2010 08:09:53 -0000 Hi Dominique, all, I also support this request. Regards, Quentin Pascal Thubert (pthubert) a écrit : > Hi Dominique: > > I'd add that it can be interesting for a node to specify what it is > looking for, like the instance that it belongs to and for which it is > searching for a parent. > > Yes, you have my support to make this a ticket. > > Pascal > > > >> -----Original Message----- >> From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf >> > Of > >> dominique.barthel@orange-ftgroup.com >> Sent: Friday, March 19, 2010 10:45 AM >> To: roll@ietf.org >> Subject: [Roll] Options in DIS >> >> Hi all, >> >> I have already expressed a desire for options in the DIS packet >> http://www.ietf.org/mail-archive/web/roll/current/msg02765.html >> Jerry and Mukul expressed their support to the request. >> http://www.ietf.org/mail-archive/web/roll/current/msg02766.html >> http://www.ietf.org/mail-archive/web/roll/current/msg02770.html >> >> Then Phil asked for a justification for the request, which I admit I >> haven't provided yet. >> http://www.ietf.org/mail-archive/web/roll/current/msg02774.html >> >> More recently, Tzeta suggested that DIS have security options >> http://www.ietf.org/mail-archive/web/roll/current/msg03101.html >> >> Independently, Yaov and Matteo both again expressed the need for DIS >> option. >> http://www.ietf.org/mail-archive/web/roll/current/msg03185.html >> http://www.ietf.org/mail-archive/web/roll/current/msg03290.html >> >> I do believe we have a serious point here. >> Please find the justification below. >> Can we please have a ticket to work on it ? >> I volunteer to gather others contributors' opinions/requests and and >> propose detailed text to be included in future revisions of the RPL >> draft. >> Best, >> >> Dominique >> >> ------------------------------------------- >> The following is extracted from a typical water/gas smart metering >> infrastructure. >> The utility company worker adds new metering points into the network >> > as > >> meters are replaced or fitted with sensing/transmission electronics. >> Before the worker leaves the premises, he/she is requested to check >> > that > >> the meter has actually joined the network. >> This cannot wait for a trickled-down DAO to arrive. >> Therefore, the meter will send a DIS to collect information from the >> network. >> Without DIS options, all neighbor routers will respond, spending >> > energy > >> for their own transmission and triggering energy expenditure in all >> neighbor nodes that overhear the responses. >> >> Let's consider a "wheel" model for the network topology, with a sink >> > at > >> the center and spokes connecting outward to ring-1 routers, ring-2 >> routers and periphery meters. The meters have routing capability >> themselves, although I'll call them meters in the following text to >> distinguish them from devices solely intended at providing >> > connectivity, > >> which I'll call routers. >> Let's consider a generic "pizza slice" of this wheel. Since there's >> central symmetry in the network, there's no border effect in the slice >> We typically have >> - one mains-powered sink at the center, >> - N severely energy-limited meters at the periphery, deeply burried >> > into > >> basements or manholes >> - N/20 fairly energy-limited ring-1 routers, located on high spots >> - N/10 fairly energy-limited ring-2 routers, located on high spots >> In RPL parlance, ring-1 routers would have a typical rank of 4, and >> ring-2 routers would have a typical rank of 8 >> The N/10 and N/20 ratios above are dictated by energy/lifetime >> considerations, not radio coverage. >> A typical connectivity is the following >> - each meter is in range of N/10 and N/20 routers, albeit with *very* >> different link qualities >> - each router is in range of N/10 and N/20 routers, with various link >> qualities >> - each meter is in range of N/20 meters >> The ratios and assumptions above hold for values of N in the [20..200] >> range. >> >> **** Without DIS options, we have >> NT0 = Number of DIS multicast transmission = 1 >> NR0 = Number of DIS active receptions = N/5 (due to N/20 meters and >> (N/10+N/20) routeurs), >> NT1 = N/20 DIO transmissions from meters; each one being overheard by >> N/20 meters and (N/10+N/20) routers >> NT2 = N/10+N/20 DIO transmissions from routers; each one being >> > overheard > >> by N meters and (N/10+N/20) routers >> NR1 ~= NT1 * (3N/20 + N/20) = N^2/100 = 0.01 * N^2 receptions due to >> > DIO > >> coming from meters >> NR2 ~= NT2 * (N + N/20 + N/10) = N^2*69/400 = 0.17 * N^2 receptions >> > due > >> to DIO coming from routers >> >> We therefore have >> Number of transmissions: NT = NT0 + NT1 + NT2 = 1 + N/20 + (N/10 + >> > N/20) > >> = 24/20 * N = 1 + 0.2 * N >> Number of receptions : NR = NR0 + NR1 + NR2 = 0.2 * N + 0.18 * N^2 >> >> Total energy cost Etotal = NT * Et + NR * Er >> >> If the network is asynchronous and uses basic preamble sampling, the >> cost of overhearing Eo is the cost of receiving the expected duration >> (half) of the preamble. >> Since the DIS packet is small, its unit reception cost Er is about the >> same as the overhearing cost Eo. >> With a small (<1KB) DIO packet, the cost of transmission Et is >> essentially the cost of sending the preamble. >> Let's assume transmission cost Et is 6 times Eo (full preamble length >> accounts for x2, power consumption for x3) >> >> Etotal ~= Eo * ( 1 * 6 + N * (0.2 * 6 + 0.2) + 0.18 * N^2) ~= Eo * ( 6 >> > + > >> 1.4 * N + 0.18 * N^2) >> >> **** With DIS options >> A typical protocol currently in use in widely deployed proprietary >> > smart > >> metering networks is the following. >> Newborn nodes send successive DIS'es with decreasing demands on rank >> and >> link quality >> - iteration 1: only sinks, LQI >= 0,75*maxLQI >> - iteration 2: only sinks, LQI >= 0,5*maxLQI >> - iteration 3: only sinks, LQI >= 0,25*maxLQI >> - iteration 4: ring-1 routers, LQI >= 0,75*maxLQI, >> - iteration 5: ring-1 routers, LQI >= 0,50*maxLQI, >> - iteration 6: ring-1 routers, LQI >= 0,25*maxLQI, >> - iteration 7: ring-2 routers, LQI >= 0,75*maxLQI, >> - iteration 8: ring-2 routers, LQI >= 0,50*maxLQI, >> - iteration 9: ring-2 routers, LQI >= 0,25*maxLQI, >> - etc >> The newborn node will usually send several DIS's instead of just one. >> Its direct neighbors (N/20 meters, N/10+N/20 routers) will also incur >> the cost of receiving these extra DIS'es. >> Let's suppose iteration 7 is successful and prompts 25% of the >> > neighbor > >> ring-2 routers to send their DIOs. >> Number of DIS transmissions = 7 >> Number of DIS receptions = 7 * (N/20 + N/10 + N/20) = 7/5 * N >> Number of DIO transmissions = 25% of N/10 = N/40, overheard by 23/20 * >> > N > >> nodes (N meters and N/10+N/20 routers). >> Number of DIOs overheard = 23/800 * N^2 = 0.029 * N^2 >> Etotal ~= Eo * ( 7*6 + N * ( 7/5 + 6/40) + 0.029 * N^2) ~= Eo * (42 + >> 1.6 * N + 0.029 * N^2) >> >> In this case, the global energy cost of inserting a new node in the >> network is reduced by a factor ranging from 2 to 5 depending on N in >> [20..200]. Additional analysis shows that this saving affect both >> > meters > >> and routers (specifically, we are not pushing the burden towards the >> energy-critical meters). >> Similar results are obtained with differents iterations numbers. >> >> Just to re-inforce this calculation, it has been our experience that >> node insertion into a dense low-power network, if done wrong, is a >> significant energy drain. Please let us enhance RPL to do it right. >> _______________________________________________ >> Roll mailing list >> Roll@ietf.org >> https://www.ietf.org/mailman/listinfo/roll >> > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > -- *LAMPIN Quentin RD-TECH-GRE* * GRE/TECH/MATIS* Tel : 04 76 76 41 22 Email: quentin.lampin@orange-ftgroup.com R&D Grenoble 28 chemin du Vieux Chêne - BP98 38243 Meylan Cedex - France From geoffreyriggs@gmail.com Mon Mar 22 01:21: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 7BF633A6B13 for ; Mon, 22 Mar 2010 01:21:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.732 X-Spam-Level: * X-Spam-Status: No, score=1.732 tagged_above=-999 required=5 tests=[BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, HTML_MESSAGE=0.001, J_CHICKENPOX_32=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 dLzzFumQ3vlK for ; Mon, 22 Mar 2010 01:21:49 -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 A192E3A6881 for ; Mon, 22 Mar 2010 01:21:48 -0700 (PDT) Received: by wwg30 with SMTP id 30so2020172wwg.31 for ; Mon, 22 Mar 2010 01:22:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=9nEh+WaY03fscd/q6GPq2eqXv0znq2MvJUkcrDmfoWg=; b=OoEZ8FRmBBKA+cMHEDRulX05vxY4e6AtVSFj3ZU91u4fpm02YWhXlbyXNM6RU98IcO LiRAf51p1zmTvvObOH/MoKQx3iV6kP/y7b21kvfCvy1r0jRI4tHRydEjlqDEuYxP1nLC tQWWLsdvhvMgdOiuYwTDSauzES3r5qphyH5jU= 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=j+5TFCAEymlaWzTnafkLCiAKxvNGwVZVGp5bn7jRZcu2RauNkeM6NeuBK1OaZ1YuTO sym9mr1knAEs7lXnVZS9+aZVPkuPorkslmgmaAb5PLlX5nd3+3XEJmjTVGPU1S7XdWrP yayVxzwH51Mwqe9GN2vxWV3pK22MPUOO+jPGA= MIME-Version: 1.0 Received: by 10.216.164.85 with SMTP id b63mr1996555wel.111.1269246122245; Mon, 22 Mar 2010 01:22:02 -0700 (PDT) In-Reply-To: <6A2A459175DABE4BB11DE2026AA50A5D0180D60F@XMB-AMS-107.cisco.com> References: <6A2A459175DABE4BB11DE2026AA50A5D0180D60F@XMB-AMS-107.cisco.com> Date: Mon, 22 Mar 2010 09:22:02 +0100 Message-ID: From: Geoffrey Riggs To: "Pascal Thubert (pthubert)" Content-Type: multipart/alternative; boundary=0016e6497e383fbf0d04825f6477 Cc: roll@ietf.org Subject: Re: [Roll] Options in DIS X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 22 Mar 2010 08:21:51 -0000 --0016e6497e383fbf0d04825f6477 Content-Type: text/plain; charset=ISO-8859-1 Hello Everyone, Dominique, you have my support as well regarding your proposal. Best regards, \\ Geoffrey On Sun, Mar 21, 2010 at 6:40 PM, Pascal Thubert (pthubert) < pthubert@cisco.com> wrote: > Hi Dominique: > > I'd add that it can be interesting for a node to specify what it is > looking for, like the instance that it belongs to and for which it is > searching for a parent. > > Yes, you have my support to make this a ticket. > > Pascal > > > > -----Original Message----- > > From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf > Of > > dominique.barthel@orange-ftgroup.com > > Sent: Friday, March 19, 2010 10:45 AM > > To: roll@ietf.org > > Subject: [Roll] Options in DIS > > > > Hi all, > > > > I have already expressed a desire for options in the DIS packet > > http://www.ietf.org/mail-archive/web/roll/current/msg02765.html > > Jerry and Mukul expressed their support to the request. > > http://www.ietf.org/mail-archive/web/roll/current/msg02766.html > > http://www.ietf.org/mail-archive/web/roll/current/msg02770.html > > > > Then Phil asked for a justification for the request, which I admit I > > haven't provided yet. > > http://www.ietf.org/mail-archive/web/roll/current/msg02774.html > > > > More recently, Tzeta suggested that DIS have security options > > http://www.ietf.org/mail-archive/web/roll/current/msg03101.html > > > > Independently, Yaov and Matteo both again expressed the need for DIS > > option. > > http://www.ietf.org/mail-archive/web/roll/current/msg03185.html > > http://www.ietf.org/mail-archive/web/roll/current/msg03290.html > > > > I do believe we have a serious point here. > > Please find the justification below. > > Can we please have a ticket to work on it ? > > I volunteer to gather others contributors' opinions/requests and and > > propose detailed text to be included in future revisions of the RPL > > draft. > > Best, > > > > Dominique > > > > ------------------------------------------- > > The following is extracted from a typical water/gas smart metering > > infrastructure. > > The utility company worker adds new metering points into the network > as > > meters are replaced or fitted with sensing/transmission electronics. > > Before the worker leaves the premises, he/she is requested to check > that > > the meter has actually joined the network. > > This cannot wait for a trickled-down DAO to arrive. > > Therefore, the meter will send a DIS to collect information from the > > network. > > Without DIS options, all neighbor routers will respond, spending > energy > > for their own transmission and triggering energy expenditure in all > > neighbor nodes that overhear the responses. > > > > Let's consider a "wheel" model for the network topology, with a sink > at > > the center and spokes connecting outward to ring-1 routers, ring-2 > > routers and periphery meters. The meters have routing capability > > themselves, although I'll call them meters in the following text to > > distinguish them from devices solely intended at providing > connectivity, > > which I'll call routers. > > Let's consider a generic "pizza slice" of this wheel. Since there's > > central symmetry in the network, there's no border effect in the slice > > We typically have > > - one mains-powered sink at the center, > > - N severely energy-limited meters at the periphery, deeply burried > into > > basements or manholes > > - N/20 fairly energy-limited ring-1 routers, located on high spots > > - N/10 fairly energy-limited ring-2 routers, located on high spots > > In RPL parlance, ring-1 routers would have a typical rank of 4, and > > ring-2 routers would have a typical rank of 8 > > The N/10 and N/20 ratios above are dictated by energy/lifetime > > considerations, not radio coverage. > > A typical connectivity is the following > > - each meter is in range of N/10 and N/20 routers, albeit with *very* > > different link qualities > > - each router is in range of N/10 and N/20 routers, with various link > > qualities > > - each meter is in range of N/20 meters > > The ratios and assumptions above hold for values of N in the [20..200] > > range. > > > > **** Without DIS options, we have > > NT0 = Number of DIS multicast transmission = 1 > > NR0 = Number of DIS active receptions = N/5 (due to N/20 meters and > > (N/10+N/20) routeurs), > > NT1 = N/20 DIO transmissions from meters; each one being overheard by > > N/20 meters and (N/10+N/20) routers > > NT2 = N/10+N/20 DIO transmissions from routers; each one being > overheard > > by N meters and (N/10+N/20) routers > > NR1 ~= NT1 * (3N/20 + N/20) = N^2/100 = 0.01 * N^2 receptions due to > DIO > > coming from meters > > NR2 ~= NT2 * (N + N/20 + N/10) = N^2*69/400 = 0.17 * N^2 receptions > due > > to DIO coming from routers > > > > We therefore have > > Number of transmissions: NT = NT0 + NT1 + NT2 = 1 + N/20 + (N/10 + > N/20) > > = 24/20 * N = 1 + 0.2 * N > > Number of receptions : NR = NR0 + NR1 + NR2 = 0.2 * N + 0.18 * N^2 > > > > Total energy cost Etotal = NT * Et + NR * Er > > > > If the network is asynchronous and uses basic preamble sampling, the > > cost of overhearing Eo is the cost of receiving the expected duration > > (half) of the preamble. > > Since the DIS packet is small, its unit reception cost Er is about the > > same as the overhearing cost Eo. > > With a small (<1KB) DIO packet, the cost of transmission Et is > > essentially the cost of sending the preamble. > > Let's assume transmission cost Et is 6 times Eo (full preamble length > > accounts for x2, power consumption for x3) > > > > Etotal ~= Eo * ( 1 * 6 + N * (0.2 * 6 + 0.2) + 0.18 * N^2) ~= Eo * ( 6 > + > > 1.4 * N + 0.18 * N^2) > > > > **** With DIS options > > A typical protocol currently in use in widely deployed proprietary > smart > > metering networks is the following. > > Newborn nodes send successive DIS'es with decreasing demands on rank > > and > > link quality > > - iteration 1: only sinks, LQI >= 0,75*maxLQI > > - iteration 2: only sinks, LQI >= 0,5*maxLQI > > - iteration 3: only sinks, LQI >= 0,25*maxLQI > > - iteration 4: ring-1 routers, LQI >= 0,75*maxLQI, > > - iteration 5: ring-1 routers, LQI >= 0,50*maxLQI, > > - iteration 6: ring-1 routers, LQI >= 0,25*maxLQI, > > - iteration 7: ring-2 routers, LQI >= 0,75*maxLQI, > > - iteration 8: ring-2 routers, LQI >= 0,50*maxLQI, > > - iteration 9: ring-2 routers, LQI >= 0,25*maxLQI, > > - etc > > The newborn node will usually send several DIS's instead of just one. > > Its direct neighbors (N/20 meters, N/10+N/20 routers) will also incur > > the cost of receiving these extra DIS'es. > > Let's suppose iteration 7 is successful and prompts 25% of the > neighbor > > ring-2 routers to send their DIOs. > > Number of DIS transmissions = 7 > > Number of DIS receptions = 7 * (N/20 + N/10 + N/20) = 7/5 * N > > Number of DIO transmissions = 25% of N/10 = N/40, overheard by 23/20 * > N > > nodes (N meters and N/10+N/20 routers). > > Number of DIOs overheard = 23/800 * N^2 = 0.029 * N^2 > > Etotal ~= Eo * ( 7*6 + N * ( 7/5 + 6/40) + 0.029 * N^2) ~= Eo * (42 + > > 1.6 * N + 0.029 * N^2) > > > > In this case, the global energy cost of inserting a new node in the > > network is reduced by a factor ranging from 2 to 5 depending on N in > > [20..200]. Additional analysis shows that this saving affect both > meters > > and routers (specifically, we are not pushing the burden towards the > > energy-critical meters). > > Similar results are obtained with differents iterations numbers. > > > > Just to re-inforce this calculation, it has been our experience that > > node insertion into a dense low-power network, if done wrong, is a > > significant energy drain. Please let us enhance RPL to do it right. > > _______________________________________________ > > Roll mailing list > > Roll@ietf.org > > https://www.ietf.org/mailman/listinfo/roll > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > --0016e6497e383fbf0d04825f6477 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hello Everyone,
=A0
Dominique, you have my support as well regarding your proposal.
=A0
Best regards,
=A0
\\ Geoffrey


= --Apple-Mail-97--463687274-- --Apple-Mail-96--463687275-- From jpv@cisco.com Mon Mar 29 15:24: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 9EB0A3A6937 for ; Mon, 29 Mar 2010 15:24:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.307 X-Spam-Level: X-Spam-Status: No, score=-6.307 tagged_above=-999 required=5 tests=[AWL=-0.039, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, HTML_MESSAGE=0.001, J_CHICKENPOX_63=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mS7VW3z6kYnu for ; Mon, 29 Mar 2010 15:24:10 -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 649093A63C9 for ; Mon, 29 Mar 2010 15:24:09 -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: AhsFANfFsEurRN+J/2dsb2JhbACBPplpcacBmH4CgmyCEwQ X-IronPort-AV: E=Sophos;i="4.51,330,1267401600"; d="scan'208,217";a="107241485" Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-4.cisco.com with ESMTP; 29 Mar 2010 22:24:37 +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 o2TMOa7d017874; Mon, 29 Mar 2010 22:24:37 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, 30 Mar 2010 00:24:35 +0200 Received: from dhcp-144-254-20-202.cisco.com ([144.254.20.202]) by xfe-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 30 Mar 2010 00:24:35 +0200 Message-Id: From: JP Vasseur To: "Monnerie, Emmanuel" In-Reply-To: <76DBCE2AA6605F42A49F1BD7454C841BA2B4FA@usatlsv105.am.bm.net> Content-Type: multipart/alternative; boundary=Apple-Mail-100--463501892 Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 30 Mar 2010 00:24:34 +0200 References: <68182A3F-0D29-4F8A-9711-F71A8950DC21@cisco.com> <76DBCE2AA6605F42A49F1BD7454C841BA2B4FA@usatlsv105.am.bm.net> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 29 Mar 2010 22:24:35.0504 (UTC) FILETIME=[9CB73B00:01CACF8E] Cc: ROLL WG Subject: Re: [Roll] Ticket # 25 - Tracking the MUST requirement X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 29 Mar 2010 22:24:18 -0000 --Apple-Mail-100--463501892 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Hi Emmanuel, On Mar 30, 2010, at 12:21 AM, Monnerie, Emmanuel wrote: > Jean-Pierre, > > Thanks for compiling this summary. This is very helpful. > > In the case of a satisfied requirement (Green), would it be possible > to add a reference (chapter number) to the text in the draft > standard that describe the corresponding RPL feature? This would > help a lot. I can try but most likely, this will be a collection of places. > > In the case of a deferred requirement (Grey), could you please > provide additional information explaining how this choice was made? > Is it a recommendation or a decision? Just a first take, to be discussed of course, the WG ends up deciding of course! Cheers. JP. > > Best Regards > > > > > Emmanuel Monnerie > Senior Research Engineer > Landis+Gyr > Energy Management Solutions > Office: +1 678 258 1695 > Fax: +1 678 258 1316 > Emmanuel.Monnerie@landisgyr.com > www.landisgyr.com > manage energy better > > From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf > Of JP Vasseur > Sent: Monday, March 29, 2010 3:31 PM > To: ROLL WG > Subject: [Roll] Ticket # 25 - Tracking the MUST requirement > > Dear WG, > > I put together a spreadsheet to track the "MUST requirements" > spelled out in our four requirements documents. > > To that end, I listed all MUST and used the following color code: > > GREEN: Satisfied requirement > > YELLOW: the requirement is partially satisfied and the WG thinks > that the requirement is not sufficiently satisfied. > > For example: > Support of Point-to-Point: "The routing protocol MUST provide routes > between arbitrary hosts within the appropriate > administrative domain". Strictly speaking RPL supports P2P but the > WG thinks that more work is required, thus the > Yellow color > > RED: the requirement is not satisfied (e.g. additional mechanisms > required) or not yet done (e.g. security) > > PINK: the requirement is partially satisfied or non satisfied but > the WG decided that this was acceptable. It may > be wise to document it. > > GREY: Evaluation is differed (not a show stopper for LC). For > example, it may take time to deploy a network with > few dozens of thousands of nodes. Note that in this case, > simulations may help. > > Let's continue to work on our opened tickets and update that > spreadsheet accordingly. > > Note that in both the YELLOW and RED cases, RPL could not be last > called until they turn GREEN. > > Comments very welcome of course. > > Thanks. > > JP. > --Apple-Mail-100--463501892 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Hi = Emmanuel,

On Mar 30, 2010, at 12:21 AM, Monnerie, = Emmanuel wrote:

In = the case of a satisfied requirement (Green), would it be possible to add = a reference (chapter number) to the text in the draft standard that = describe the corresponding RPL feature? This would help a = lot.
In = the case of a deferred requirement (Grey), could you please provide = additional information explaining how this choice was made? Is it a = recommendation or a = decision?

= Just a first take, to be discussed of course, the WG ends up deciding of = course!

Cheers.

JP.

Best = Regards

Emmanuel = Monnerie
Senior Research Engineer
Landis+Gyr
Energy = Management Solutions
Office: +1 678 258 1695
Fax: +1 678 258 = 1316        
Emmanuel.Monnerie@landisgyr.com
www.landisgyr.com 
manage energy = better

From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of JP = Vasseur
Sent: Monday, March 29, 2010 3:31 = PM
To: ROLL = WG
Subject: [Roll] Ticket # 25 - = Tracking the MUST requirement
 
Dear = WG,
I put together a = spreadsheet to track the "MUST requirements" spelled out in our four = requirements documents.
 
To that end, I = listed all MUST and used the following color = code:
GREEN: Satisfied = requirement
YELLOW: the requirement is partially = satisfied and the WG thinks that the requirement is not sufficiently = satisfied.
For = example:
Support = of Point-to-Point: "The routing protocol MUST provide routes between = arbitrary hosts within the = appropriate 
administrative domain". Strictly = speaking RPL supports P2P but the WG thinks that more work is required, = thus the 
Yellow color
 
RED: the requirement is not satisfied = (e.g. additional mechanisms required) or not yet done (e.g. = security)
PINK: the requirement is partially = satisfied or non satisfied but the WG decided that this was acceptable. = It may 
be wise to document = it.
GREY: Evaluation is differed (not a = show stopper for LC). For example, it may take time to deploy a network = with
few dozens of thousands = of nodes. Note that in this case, simulations may = help.
Let's continue to work on = our opened tickets and update that spreadsheet = accordingly.
Note that in both the = YELLOW and RED cases, RPL could not be last called until they turn = GREEN.
Comments very welcome of = course.
spelled out in our four requirements documents. > > To that end, I listed all MUST and used the following color code: > > GREEN: Satisfied requirement > > YELLOW: the requirement is partially satisfied and the WG thinks > that the requirement is not sufficiently satisfied. > > For example: > Support of Point-to-Point: "The routing protocol MUST provide routes > between arbitrary hosts within the appropriate > administrative domain". Strictly speaking RPL supports P2P but the > WG thinks that more work is required, thus the > Yellow color > > RED: the requirement is not satisfied (e.g. additional mechanisms > required) or not yet done (e.g. security) > > PINK: the requirement is partially satisfied or non satisfied but > the WG decided that this was acceptable. It may > be wise to document it. > > GREY: Evaluation is differed (not a show stopper for LC). For > example, it may take time to deploy a network with > few dozens of thousands of nodes. Note that in this case, > simulations may help. > > Let's continue to work on our opened tickets and update that > spreadsheet accordingly. > > Note that in both the YELLOW and RED cases, RPL could not be last > called until they turn GREEN. > > Comments very welcome of course. > > Thanks. > > JP. > > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll --Apple-Mail-20--464084132 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Any chance of getting that in a = format that we can read without spending several KUSD on special-purpose = software?

Thanks,

Thomas
On Mar 29, 2010, at 21:31 PM, JP Vasseur wrote:

Dear WG,

I = put together a spreadsheet to track the "MUST requirements" spelled out = in our four requirements documents.

To that = end, I listed all MUST and used the following color = code:

GREEN: Satisfied = requirement

YELLOW: the = requirement is partially satisfied and the WG thinks that the = requirement is not sufficiently satisfied.

For = example:
Support of = Point-to-Point: "The routing protocol MUST provide routes between = arbitrary hosts within the = appropriate 
administrative domain". Strictly speaking RPL supports P2P but the = WG thinks that more work is required, thus = the 

RED: the = requirement is not satisfied (e.g. additional mechanisms required) or = not yet done (e.g. security)

PINK: the = requirement is partially satisfied or non satisfied but the WG decided = that this was acceptable. It may 
be wise to document = it.

GREY: Evaluation is differed (not a show = stopper for LC). For example, it may take time to deploy a network = with
few dozens of thousands of nodes. Note that in this case, = simulations may help.

Let's continue to work on = our opened tickets and update that spreadsheet = accordingly.

Note that in both the = YELLOW and RED cases, RPL could not be last called until they turn = GREEN.

Comments very welcome = of = course.

Thanks.

JP. = ;

<RPL-MUST.xlsx><= /span>
=
_______________________________________________
Roll mailing = list
Roll@ietf.org
https://www.ietf.org/m= ailman/listinfo/roll

= --Apple-Mail-20--464084132-- From thomas@thomasclausen.org Mon Mar 29 15:25: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 ABEB33A69A6 for ; Mon, 29 Mar 2010 15:25:48 -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=1.300, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, 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 mZ4UhQ+62KXp for ; Mon, 29 Mar 2010 15:25:47 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id A887B3A68A6 for ; Mon, 29 Mar 2010 15:25:47 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 82D61430059; Mon, 29 Mar 2010 15:26:16 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hermes.tigertech.net Received: from [192.168.147.148] (AMontsouris-552-1-19-226.w86-212.abo.wanadoo.fr [86.212.50.226]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by hermes.tigertech.net (Postfix) with ESMTPSA id 445AA43004E; Mon, 29 Mar 2010 15:26:15 -0700 (PDT) Message-Id: <84F6875F-7DA3-423F-AF9F-AB822F705135@thomasclausen.org> From: Thomas Heide Clausen To: JP Vasseur In-Reply-To: <38602B90-4346-455D-9405-39E529CB4CF3@cisco.com> Content-Type: multipart/alternative; boundary=Apple-Mail-22--463401904 Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 30 Mar 2010 00:26:14 +0200 References: <68182A3F-0D29-4F8A-9711-F71A8950DC21@cisco.com> <38602B90-4346-455D-9405-39E529CB4CF3@cisco.com> X-Mailer: Apple Mail (2.936) X-Mailman-Approved-At: Mon, 29 Mar 2010 15:31:03 -0700 Cc: ROLL WG Subject: Re: [Roll] Ticket # 25 - Tracking the MUST requirement X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 29 Mar 2010 22:25:48 -0000 --Apple-Mail-22--463401904 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Thanks a bunch, JP! Thomas On Mar 30, 2010, at 00:21 AM, JP Vasseur wrote: > Here you are: > > > > On Mar 30, 2010, at 12:14 AM, Thomas Heide Clausen wrote: > >> Any chance of getting that in a format that we can read without >> spending several KUSD on special-purpose software? >> >> Thanks, >> >> Thomas >> On Mar 29, 2010, at 21:31 PM, JP Vasseur wrote: >> >>> Dear WG, >>> >>> I put together a spreadsheet to track the "MUST requirements" >>> spelled out in our four requirements documents. >>> >>> To that end, I listed all MUST and used the following color code: >>> >>> GREEN: Satisfied requirement >>> >>> YELLOW: the requirement is partially satisfied and the WG thinks >>> that the requirement is not sufficiently satisfied. >>> >>> For example: >>> Support of Point-to-Point: "The routing protocol MUST provide >>> routes between arbitrary hosts within the appropriate >>> administrative domain". Strictly speaking RPL supports P2P but the >>> WG thinks that more work is required, thus the >>> Yellow color >>> >>> RED: the requirement is not satisfied (e.g. additional mechanisms >>> required) or not yet done (e.g. security) >>> >>> PINK: the requirement is partially satisfied or non satisfied but >>> the WG decided that this was acceptable. It may >>> be wise to document it. >>> >>> GREY: Evaluation is differed (not a show stopper for LC). For >>> example, it may take time to deploy a network with >>> few dozens of thousands of nodes. Note that in this case, >>> simulations may help. >>> >>> Let's continue to work on our opened tickets and update that >>> spreadsheet accordingly. >>> >>> Note that in both the YELLOW and RED cases, RPL could not be last >>> called until they turn GREEN. >>> >>> Comments very welcome of course. >>> >>> 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 --Apple-Mail-22--463401904 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Thanks a bunch, = JP!

Thomas

On Mar = 30, 2010, at 00:21 AM, JP Vasseur wrote:

Here you = are:

<RPL-MUST.pdf>
Any chance of getting that in a = format that we can read without spending several KUSD on special-purpose = software?

Thanks,

Thomas
On Mar 29, 2010, at 21:31 PM, JP Vasseur wrote:

Dear WG,

I = put together a spreadsheet to track the "MUST requirements" spelled out = in our four requirements documents.

To that = end, I listed all MUST and used the following color = code:

GREEN: Satisfied = requirement

YELLOW: the = requirement is partially satisfied and the WG thinks that the = requirement is not sufficiently satisfied.

For = example:
Support of = Point-to-Point: "The routing protocol MUST provide routes between = arbitrary hosts within the = appropriate 
administrative domain". Strictly speaking RPL supports P2P but the = WG thinks that more work is required, thus = the 

RED: the = requirement is not satisfied (e.g. additional mechanisms required) or = not yet done (e.g. security)

PINK: the = requirement is partially satisfied or non satisfied but the WG decided = that this was acceptable. It may 
be wise to document = it.

GREY: Evaluation is differed (not a show = stopper for LC). For example, it may take time to deploy a network = with
few dozens of thousands of nodes. Note that in this case, = simulations may help.

Let's continue to work on = our opened tickets and update that spreadsheet = accordingly.

Note that in both the = YELLOW and RED cases, RPL could not be last called until they turn = GREEN.

Comments very welcome = of = course.

Thanks.

JP. = ;

<RPL-MUST.xlsx><= /span>
=
_______________________________________________
Roll mailing = list
Roll@ietf.org
https://www.ietf.org/m= ailman/listinfo/roll


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

= --Apple-Mail-22--463401904-- From roger.alexander@ekasystems.com Mon Mar 29 15:32: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 9640D3A690B for ; Mon, 29 Mar 2010 15:32:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.581 X-Spam-Level: ** X-Spam-Status: No, score=2.581 tagged_above=-999 required=5 tests=[BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, 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 9YOPuJyO+hEz for ; Mon, 29 Mar 2010 15:32:13 -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 8546C3A6851 for ; Mon, 29 Mar 2010 15:32:13 -0700 (PDT) Received: (qmail 28491 invoked from network); 29 Mar 2010 22:32:42 -0000 Received: from dallas (roger.alexander@209.48.242.70 with login) by smtp113.biz.mail.re2.yahoo.com with SMTP; 29 Mar 2010 15:32:41 -0700 PDT X-Yahoo-SMTP: 1dQRPo6swBBzwSsRzMLy_tvdRrLDyF0J X-YMail-OSG: QtGf17sVM1mcit.2MAYbfclYVNrqqL4RF_wjHaz.41nmtCBwknLKREtG35wEeGRxQ1n4sns5T.TuQc5yGL7mQtTAFI3k289P7FW6gR7Z53ChFcTnQ1qdD2Kv4AXIatiwOxlJoMSOUoQJjXGbMVtMHPUR7sfBDazyhzkQNfEf1zlOE_0BqEw44wIgYO9lroGVIViQdEe_lTE2OVVu4AKuStzmDPHR1ygmzS0.WoaTpHgvbdoC5lgp.miOSRiAqyLI7lA42haM0ZTZD64u0k9V1jtLf446FSmpQCwksLDBwoBVyn4BlupGcsZzBP3yObtbhBcnEni_Ev3zGhbi4GKOjdXJWZe660.by7pSUMznamPPOXx4UDTVtH2hXvJm71WE X-Yahoo-Newman-Property: ymail-3 From: "Roger Alexander" To: "'JeongGil Ko \(John\)'" 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> In-Reply-To: <207C6B80-B20B-4553-B04C-CC88841E1002@cs.jhu.edu> Date: Mon, 29 Mar 2010 18:31:32 -0400 Message-ID: <009201cacf8f$95d779c0$c1866d40$@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: AcrPi8oBmLugu0lzRw+4JQgRPQq70wAAIg/A Content-Language: en-us 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, 29 Mar 2010 22:32:15 -0000 Hi John, > -----Original Message----- > From: JeongGil (John) Ko [mailto:jeonggil.ko@gmail.com] On Behalf Of > JeongGil Ko (John) > Sent: Monday, March 29, 2010 6:04 PM > To: Roger Alexander > Cc: roll@ietf.org > Subject: Re: [Roll] proposal for DAOs in non-caching DODAGs > > Roger, > > On Mar 29, 2010, at 2:58 PM, Roger Alexander wrote: > > > Hi John, > > > >> -----Original Message----- > >> From: JeongGil (John) Ko [mailto:jeonggil.ko@gmail.com] On Behalf Of > >> JeongGil Ko (John) > >> Sent: Monday, March 29, 2010 5:48 PM > >> To: Roger Alexander > >> Cc: 'Pascal Thubert (pthubert)'; roll@ietf.org > >> Subject: Re: [Roll] proposal for DAOs in non-caching DODAGs > >> > >> Hey Roger, > >> > >> > >> Maybe a stupid question but I keep making this point without getting > an > >> answer. I agree that if we have a DAO parent set and if this is > >> reported to the root then the need for DAO ranks go away. However, > how > >> would a node know its DAO parents without using DAO ranks? I am > (once > >> again) not in favor of DAOs but I just want to know how we can > achieve > >> this. > >> > > > > The selection of DAO Parents is based on the Rank that the candidate > nodes > > advertise in their DIO. As for sending the DAO Parent set to the > root, that > > is only applicable for non-storing nodes. For storing nodes the > DAO(s) is > > sent to each of the set of DAO Parents. > > > > Better understood. Then the selection of the DODAG preferred parent set > and DAO parent set MAY be identical. Correct? Since both decisions are > made using the DODAG rank values. Now it makes more sense :) I > understand that all this is unneeded when storing mode is used in the > network. The node will use the received Rank plus the local link cost to determine Parents. The sets MAY indeed be identical but there is no requirement that they be identical as a node can always have more Preferred Parents than DAO Parents. The node is required to advertise destination addresses to DAO Parents but can always forward traffic to any Preferred Parent at no control cost. Furthermore, with link asymmetry as discussed earlier the Preferred and DAO Parent sets may even be non-overlapping. By choosing the DAO Parents the node is dictating its desired downward routing alternatives (no current mechanism for priority but that can be addressed) while remaining free to choose different parents for upward routing. For storing and non-storing alike (based on Richard's proposal), the system can operate without a rank in the DAO, or the need to maintain rank as part of the routing table entry. > > Thanks for the clarification! > > -John > > >> Thanks. > >> > >> -John > >> > >>> > >>>> The current spec enables the OF in a node to compute a DAO Rank > >> based > >>>> on > >>>> the metrics option pretty much like a DIO Rank would be computed > >> using > >>>> a > >>>> DAO DAG Metric Container. This was introduced at some point along > >> the > >>>> path and provides an additional capability to rate non preferred > >> paths. > >>>> I figure that you're willing to emulate that in the source route > DAO > >>>> > >>>> My take is that we have already added too much complexity even > >> though > >>>> we > >>>> made it optional. I'd rather remove the DAO DAG Metric Container. > >> But > >>>> in > >>>> any fashion I have to agree with your desire to make things > >> consistent. > >>>> Then again, slippery slope towards link state... > >>>> > >>>> Pascal > >>>> > >>>> > >>>>> -----Original Message----- > >>>>> From: JeongGil (John) Ko [mailto:jeonggil.ko@gmail.com] On Behalf > >> Of > >>>>> JeongGil Ko (John) > >>>>> Sent: Monday, March 29, 2010 8:04 AM > >>>>> To: Pascal Thubert (pthubert) > >>>>> Cc: Richard Kelsey; roll@ietf.org > >>>>> Subject: Re: [Roll] proposal for DAOs in non-caching DODAGs > >>>>> > >>>>> Hi Pascal, > >>>>> > >>>>> I see your point. One question, that confuses me is how the set > of > >>>> 'preferred > >>>>> DAO parents' are determined. Is this set different from the > >> preferred > >>>> parent > >>>>> set in DIOs? I guess another way of asking is to ask is how the > >>>> DAORank is > >>>>> defined and computed (this question was asked previously but I > >> didn't > >>>> really > >>>>> get a clear answer). Will each node that initiates a DAO for a > >>>> specific prefix be > >>>>> DAORank = 1 and the rank computation continue just like the DIO > >>>> process? In > >>>>> this case is it true that each node may need to maintain > different > >>>> DAORank > >>>>> values for many different prefixes? > >>>>> > >>>>> Thanks! > >>>>> > >>>>> -John > >>>>> > >>>>> On Mar 28, 2010, at 10:44 PM, Pascal Thubert (pthubert) wrote: > >>>>> > >>>>>> Hi John: > >>>>>> > >>>>>> Obviously, having multiple parents enables the root to compute > >>>>>> multiple paths down to the node. So your proposal is tempting. > But > >>>>>> beware, this is a slippery slope towards centralized Link State > >>>>>> computation and away from the RPL core design, and we can't be > >>>>>> designing 2 protocols, by charter. > >>>>>> > >>>>>> The RPL design is that the choice of the best parents belongs to > >>>> the > >>>>>> OF in the node, not the root. Richard's proposal centralizes in > >> the > >>>>>> root the forwarding decision along the DAG that happens hop by > hop > >>>>>> with stateful DAOs, but the routing states are built in the > exact > >>>>>> same fashion whether it is stateful or stateless, by having each > >>>> node > >>>>>> select a set of preferred DAO parents. Note that we do not > specify > >>>> how > >>>>>> a node selects the next hop between multiple DAO children in the > >>>> stateful > >>>>> mode. > >>>>>> In the same fashion, we do not specify how the root makes the > >> multi > >>>>>> hop decision. > >>>>>> > >>>>>> My suggestion to address your problem would be that the OF in > the > >>>> node > >>>>>> provides more info on how it orders the parents, maybe by > setting > >> a > >>>>>> preference level (like 0-3) for each parent in the source route > >>>> DAO. > >>>>>> The root retains the possibility to build multiple non- > overlapping > >>>>>> path, do load balancing, signal to L2 when L2 paths/circuits > need > >>>> to > >>>>>> be enabled, etc... We have not made the step towards a > centralized > >>>>> routing model. > >>>>>> > >>>>>> Cheers, > >>>>>> > >>>>>> Pascal > >>>>>> > >>>>>> > >>>>>>> -----Original Message----- > >>>>>>> From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On > >>>> Behalf > >>>>>> Of > >>>>>>> JeongGil Ko (John) > >>>>>>> Sent: Sunday, March 28, 2010 11:42 PM > >>>>>>> To: Richard Kelsey > >>>>>>> Cc: roll@ietf.org > >>>>>>> Subject: Re: [Roll] proposal for DAOs in non-caching DODAGs > >>>>>>> > >>>>>>> Richard, > >>>>>>> > >>>>>>> I agree that if we start adding downwards routes then the root > >>>> will > >>>>>> have > >>>>>>> many sub-route (or sub-path) information that it already has. > If > >>>> we > >>>>>> decide > >>>>>>> the add the neighbor (parent) information in the DAOs do we > also > >>>> add > >>>>>> link > >>>>>>> quality estimation values for each link associated with a > parent > >>>> node? > >>>>>>> Otherwise the root will have a connectivity graph of the > network > >>>>>>> (DAG) > >>>>>> but > >>>>>>> will have no way to figure out which path is cost-efficient to > >>>> select > >>>>>> (the root > >>>>>>> can come up with many combinations of paths to select from)? > >>>>>>> > >>>>>>> Thanks. > >>>>>>> > >>>>>>> -John > >>>>>>> > >>>>>>> On Mar 28, 2010, at 2:20 PM, Richard Kelsey wrote: > >>>>>>> > >>>>>>>> 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. > >>>>>>>> > >>>>>>>> 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. > >>>>>>>> > >>>>>>>> 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. > >>>>>>>> > >>>>>>>> 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. > >>>>>>>> > >>>>>>>> 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 > >>>>>>>> > >>>>>>>> What do people think? > >>>>>>>> -Richard Kelsey > >>>>>>>> _______________________________________________ > >>>>>>>> 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 > >>>>>> > >>>>> > >>>>> ------ > >>>>> 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 > >>> > >> > >> ------ > >> 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 jeonggil.ko@gmail.com Mon Mar 29 15:36: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 A89E23A6937 for ; Mon, 29 Mar 2010 15:36:44 -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 bsVe5DuUnj0t for ; Mon, 29 Mar 2010 15:36:43 -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 04C443A690B for ; Mon, 29 Mar 2010 15:36:42 -0700 (PDT) Received: by gwj23 with SMTP id 23so3580490gwj.31 for ; Mon, 29 Mar 2010 15:37:08 -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=aGd3ZjlC/Mcp6jBuT8zsmrizCl5eerCT9ygdeU8lqpA=; b=TFU5r00HfF8CjBCVcTqZ7+rbAECjNYc5yFwb1op4J84WITwELiv6x9lkA3REjVfuqc JpqBd7bC/puUfzEeGtcnoVOSP7lOEd1bgNO0VUfi6H6GzTrN6LOAlI40s+U3R13Gadrn pAQncXFeLAyPqby3BY/XlnM8IoU5zHvxD23kU= 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=NQPjyuPfGdiD2KAz3FNVlxqlN0olXxDFO8fTuL1HB1NKnEOtNeRv57ViLvGdWHPJB/ 1bdGWEDIGxvOZF0QbnjuZl0StSyVcVwq+uK7UKPsGPOw4G5gahoJtL69TMEvtfdQl4nl mS+2+PQZm4Aop3WlIJyXYF+eCECCjfuQKu6ZM= Received: by 10.100.23.19 with SMTP id 19mr5561435anw.15.1269902228721; Mon, 29 Mar 2010 15:37:08 -0700 (PDT) Received: from dnab404649.stanford.edu (DNab404649.Stanford.EDU [171.64.70.73]) by mx.google.com with ESMTPS id 8sm1139913yxb.25.2010.03.29.15.37.07 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 29 Mar 2010 15:37:08 -0700 (PDT) Sender: "JeongGil (John) Ko" Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: "JeongGil Ko (John)" In-Reply-To: <009201cacf8f$95d779c0$c1866d40$@alexander@ekasystems.com> Date: Mon, 29 Mar 2010 15:37:04 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <0146F5F5-5D51-443D-A18F-F0333759BC83@cs.jhu.edu> 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> To: Roger Alexander X-Mailer: Apple Mail (2.1077) 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, 29 Mar 2010 22:36:44 -0000 Roger,=20 On Mar 29, 2010, at 3:31 PM, Roger Alexander wrote: > Hi John, >=20 >> -----Original Message----- >> From: JeongGil (John) Ko [mailto:jeonggil.ko@gmail.com] On Behalf Of >> JeongGil Ko (John) >> Sent: Monday, March 29, 2010 6:04 PM >> To: Roger Alexander >> Cc: roll@ietf.org >> Subject: Re: [Roll] proposal for DAOs in non-caching DODAGs >>=20 >> Roger, >>=20 >> On Mar 29, 2010, at 2:58 PM, Roger Alexander wrote: >>=20 >>> Hi John, >>>=20 >>>> -----Original Message----- >>>> From: JeongGil (John) Ko [mailto:jeonggil.ko@gmail.com] On Behalf = Of >>>> JeongGil Ko (John) >>>> Sent: Monday, March 29, 2010 5:48 PM >>>> To: Roger Alexander >>>> Cc: 'Pascal Thubert (pthubert)'; roll@ietf.org >>>> Subject: Re: [Roll] proposal for DAOs in non-caching DODAGs >>>>=20 >>>> Hey Roger, >>>>=20 >>>>=20 >>>> Maybe a stupid question but I keep making this point without = getting >> an >>>> answer. I agree that if we have a DAO parent set and if this is >>>> reported to the root then the need for DAO ranks go away. However, >> how >>>> would a node know its DAO parents without using DAO ranks? I am >> (once >>>> again) not in favor of DAOs but I just want to know how we can >> achieve >>>> this. >>>>=20 >>>=20 >>> The selection of DAO Parents is based on the Rank that the candidate >> nodes >>> advertise in their DIO. As for sending the DAO Parent set to the >> root, that >>> is only applicable for non-storing nodes. For storing nodes the >> DAO(s) is >>> sent to each of the set of DAO Parents. >>>=20 >>=20 >> Better understood. Then the selection of the DODAG preferred parent = set >> and DAO parent set MAY be identical. Correct? Since both decisions = are >> made using the DODAG rank values. Now it makes more sense :) I >> understand that all this is unneeded when storing mode is used in the >> network. >=20 > The node will use the received Rank plus the local link cost to = determine > Parents. The sets MAY indeed be identical but there is no requirement = that > they be identical as a node can always have more Preferred Parents = than DAO > Parents. The node is required to advertise destination addresses to = DAO > Parents but can always forward traffic to any Preferred Parent at no = control > cost. Furthermore, with link asymmetry as discussed earlier the = Preferred > and DAO Parent sets may even be non-overlapping. By choosing the DAO = Parents > the node is dictating its desired downward routing alternatives (no = current > mechanism for priority but that can be addressed) while remaining free = to > choose different parents for upward routing. >=20 Yup. Point taken. > For storing and non-storing alike (based on Richard's proposal), the = system > can operate without a rank in the DAO, or the need to maintain rank as = part > of the routing table entry. >=20 Indeed having DAO ranks separately can turn in to a nightmare :) Thanks! -John >>=20 >> Thanks for the clarification! >>=20 >> -John >>=20 >>>> Thanks. >>>>=20 >>>> -John >>>>=20 >>>>>=20 >>>>>> The current spec enables the OF in a node to compute a DAO Rank >>>> based >>>>>> on >>>>>> the metrics option pretty much like a DIO Rank would be computed >>>> using >>>>>> a >>>>>> DAO DAG Metric Container. This was introduced at some point along >>>> the >>>>>> path and provides an additional capability to rate non preferred >>>> paths. >>>>>> I figure that you're willing to emulate that in the source route >> DAO >>>>>>=20 >>>>>> My take is that we have already added too much complexity even >>>> though >>>>>> we >>>>>> made it optional. I'd rather remove the DAO DAG Metric Container. >>>> But >>>>>> in >>>>>> any fashion I have to agree with your desire to make things >>>> consistent. >>>>>> Then again, slippery slope towards link state... >>>>>>=20 >>>>>> Pascal >>>>>>=20 >>>>>>=20 >>>>>>> -----Original Message----- >>>>>>> From: JeongGil (John) Ko [mailto:jeonggil.ko@gmail.com] On = Behalf >>>> Of >>>>>>> JeongGil Ko (John) >>>>>>> Sent: Monday, March 29, 2010 8:04 AM >>>>>>> To: Pascal Thubert (pthubert) >>>>>>> Cc: Richard Kelsey; roll@ietf.org >>>>>>> Subject: Re: [Roll] proposal for DAOs in non-caching DODAGs >>>>>>>=20 >>>>>>> Hi Pascal, >>>>>>>=20 >>>>>>> I see your point. One question, that confuses me is how the set >> of >>>>>> 'preferred >>>>>>> DAO parents' are determined. Is this set different from the >>>> preferred >>>>>> parent >>>>>>> set in DIOs? I guess another way of asking is to ask is how the >>>>>> DAORank is >>>>>>> defined and computed (this question was asked previously but I >>>> didn't >>>>>> really >>>>>>> get a clear answer). Will each node that initiates a DAO for a >>>>>> specific prefix be >>>>>>> DAORank =3D 1 and the rank computation continue just like the = DIO >>>>>> process? In >>>>>>> this case is it true that each node may need to maintain >> different >>>>>> DAORank >>>>>>> values for many different prefixes? >>>>>>>=20 >>>>>>> Thanks! >>>>>>>=20 >>>>>>> -John >>>>>>>=20 >>>>>>> On Mar 28, 2010, at 10:44 PM, Pascal Thubert (pthubert) wrote: >>>>>>>=20 >>>>>>>> Hi John: >>>>>>>>=20 >>>>>>>> Obviously, having multiple parents enables the root to compute >>>>>>>> multiple paths down to the node. So your proposal is tempting. >> But >>>>>>>> beware, this is a slippery slope towards centralized Link State >>>>>>>> computation and away from the RPL core design, and we can't be >>>>>>>> designing 2 protocols, by charter. >>>>>>>>=20 >>>>>>>> The RPL design is that the choice of the best parents belongs = to >>>>>> the >>>>>>>> OF in the node, not the root. Richard's proposal centralizes in >>>> the >>>>>>>> root the forwarding decision along the DAG that happens hop by >> hop >>>>>>>> with stateful DAOs, but the routing states are built in the >> exact >>>>>>>> same fashion whether it is stateful or stateless, by having = each >>>>>> node >>>>>>>> select a set of preferred DAO parents. Note that we do not >> specify >>>>>> how >>>>>>>> a node selects the next hop between multiple DAO children in = the >>>>>> stateful >>>>>>> mode. >>>>>>>> In the same fashion, we do not specify how the root makes the >>>> multi >>>>>>>> hop decision. >>>>>>>>=20 >>>>>>>> My suggestion to address your problem would be that the OF in >> the >>>>>> node >>>>>>>> provides more info on how it orders the parents, maybe by >> setting >>>> a >>>>>>>> preference level (like 0-3) for each parent in the source route >>>>>> DAO. >>>>>>>> The root retains the possibility to build multiple non- >> overlapping >>>>>>>> path, do load balancing, signal to L2 when L2 paths/circuits >> need >>>>>> to >>>>>>>> be enabled, etc... We have not made the step towards a >> centralized >>>>>>> routing model. >>>>>>>>=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: Sunday, March 28, 2010 11:42 PM >>>>>>>>> To: Richard Kelsey >>>>>>>>> Cc: roll@ietf.org >>>>>>>>> Subject: Re: [Roll] proposal for DAOs in non-caching DODAGs >>>>>>>>>=20 >>>>>>>>> Richard, >>>>>>>>>=20 >>>>>>>>> I agree that if we start adding downwards routes then the root >>>>>> will >>>>>>>> have >>>>>>>>> many sub-route (or sub-path) information that it already has. >> If >>>>>> we >>>>>>>> decide >>>>>>>>> the add the neighbor (parent) information in the DAOs do we >> also >>>>>> add >>>>>>>> link >>>>>>>>> quality estimation values for each link associated with a >> parent >>>>>> node? >>>>>>>>> Otherwise the root will have a connectivity graph of the >> network >>>>>>>>> (DAG) >>>>>>>> but >>>>>>>>> will have no way to figure out which path is cost-efficient to >>>>>> select >>>>>>>> (the root >>>>>>>>> can come up with many combinations of paths to select from)? >>>>>>>>>=20 >>>>>>>>> Thanks. >>>>>>>>>=20 >>>>>>>>> -John >>>>>>>>>=20 >>>>>>>>> On Mar 28, 2010, at 2:20 PM, Richard Kelsey wrote: >>>>>>>>>=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 >>>>>>>>>>=20 >>>>>>>>>=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 >>>>>>> ------ >>>>>>> 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 >>>> ------ >>>> JeongGil Ko (John) >>>> Ph.D. Student >>>> Department of Computer Science >>>> Johns Hopkins University >>>> http://www.cs.jhu.edu/~jgko >>>=20 >>=20 >> ------ >> JeongGil Ko (John) >> Ph.D. Student >> Department of Computer Science >> Johns Hopkins University >> http://www.cs.jhu.edu/~jgko >=20 ------ JeongGil Ko (John) Ph.D. Student Department of Computer Science Johns Hopkins University http://www.cs.jhu.edu/~jgko From mcr@sandelman.ca Mon Mar 29 16:08: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 C9C323A68F0 for ; Mon, 29 Mar 2010 16:08:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.104 X-Spam-Level: * X-Spam-Status: No, score=1.104 tagged_above=-999 required=5 tests=[AWL=0.069, BAYES_20=-0.74, 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 CaLNTcZ0DimG for ; Mon, 29 Mar 2010 16:08:54 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by core3.amsl.com (Postfix) with ESMTP id 1D4093A682F for ; Mon, 29 Mar 2010 16:08:54 -0700 (PDT) Received: from sandelman.ottawa.on.ca (desk.marajade.sandelman.ca [209.87.252.247]) by relay.sandelman.ca (Postfix) with ESMTPS id CB01F34741; Mon, 29 Mar 2010 19:06:47 -0400 (EDT) Received: from marajade.sandelman.ca (unknown [127.0.0.1]) by sandelman.ottawa.on.ca (Postfix) with ESMTP id A70C94E7ED; Mon, 29 Mar 2010 19:09:21 -0400 (EDT) From: Michael Richardson To: d.sturek@att.net In-Reply-To: <00fa01cacf8c$c0f4cc00$42de6400$@sturek@att.net> 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> X-Mailer: MH-E 8.1; nmh 1.1; XEmacs 21.4 (patch 21) Date: Mon, 29 Mar 2010 19:09:21 -0400 Message-ID: <7375.1269904161@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: Mon, 29 Mar 2010 23:08:54 -0000 >>>>> "Don" == Don Sturek writes: Don> Many of these implementations do some route table management Don> when the routing table is full. However, these actions (in the Don> proprietary solutions I am familiar with) come at a cost of Don> flooding the network when the removed route table entry is Don> re-established. If you make your route table entries too small Don> to support the size of network you are deploying then I don't Don> see route table maintenance itself solving the problem. I certainly won't disagree with that statement. The situation I want to think about is what happens when there are n+1 entries needed, and only n available. Not 2n, or 10n. So in AODV and other situations, the network falls back to network flooding to get packets through, when it can't find an entry. So that's what happens if an attacker manages to push an important node out. What I'm trying to determine if there is any determinism in which entry is pushed out that the attacker can exploit. -- ] 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 d.sturek@att.net Mon Mar 29 17:42: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 E37783A6403 for ; Mon, 29 Mar 2010 17:42:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.58 X-Spam-Level: ** X-Spam-Status: No, score=2.58 tagged_above=-999 required=5 tests=[BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, MSGID_MULTIPLE_AT=1.449] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IrFAoGWLqq-Z for ; Mon, 29 Mar 2010 17:42:07 -0700 (PDT) Received: from smtp104.sbc.mail.ac4.yahoo.com (smtp104.sbc.mail.ac4.yahoo.com [76.13.13.243]) by core3.amsl.com (Postfix) with SMTP id A346D3A63EC for ; Mon, 29 Mar 2010 17:42:07 -0700 (PDT) Received: (qmail 85481 invoked from network); 30 Mar 2010 00:42:31 -0000 Received: from (d.sturek@64.163.235.68 with login) by smtp104.sbc.mail.ac4.yahoo.com with SMTP; 29 Mar 2010 17:42:31 -0700 PDT X-Yahoo-SMTP: fvjol_aswBAraSJvMLe2r1XTzhBhbFxY8q8c3jo- X-YMail-OSG: KV7xuiUVM1nqHJkkp95icu6iWtdEF3Y99Cp4QCYd90JE8Oy5Ll8cKS1xRXMV77l_nnPdfw68wN3HKbq4FkXyhqEuItaD_8oxlM9ayelqDUhC6EYoXvC6SyUZq2CvSfjoZLGrlX80JP53bXIt.x7NWUeq1FLOt8MGIxMaSb3f6u.jilGfjwF2qIcAz5DwOPD0jfVCPSJ9CdSpOKFcwb7EpMjtVSFI1ZzTUkzXRiOBXTVn37PP9dCoCfcxFu3Sydj1Hve0GfeuVrQXlijPyoCHy5pDc7WoH.fHX217ym_TuBT44pbDDA-- X-Yahoo-Newman-Property: ymail-3 From: "Don Sturek" 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> In-Reply-To: <7375.1269904161@marajade.sandelman.ca> Date: Mon, 29 Mar 2010 17:42:26 -0700 Message-ID: <01e801cacfa1$df8b67e0$9ea237a0$@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: AcrPlPGpNUjk+MZMR6K0FuDJ/pXomgAC+ItA Content-Language: en-us Cc: 'roll' Subject: Re: [Roll] Mixed mode 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: Tue, 30 Mar 2010 00:42:09 -0000 Hi Michael, It would make sense to recommend to vendors they implement a route entry management solution and to even provide a best practices. On the point below on hacker exploitation, mesh routing relies on distributed routing. I think all router devices need to be authenticated before being allowed to participate. For any mesh routing solution (distance vector, source routing, link state) it would be easy to could come up with ways for a malicious router to disrupt routing (eg, depleting route table entries in distance vector routing, extending route records in source routing to deplete packet header field support, etc.) Don -----Original Message----- From: mcr@sandelman.ca [mailto:mcr@sandelman.ca] Sent: Monday, March 29, 2010 4:09 PM To: d.sturek@att.net Cc: 'roll' Subject: Re: [Roll] Mixed mode operation >>>>> "Don" == Don Sturek writes: Don> Many of these implementations do some route table management Don> when the routing table is full. However, these actions (in the Don> proprietary solutions I am familiar with) come at a cost of Don> flooding the network when the removed route table entry is Don> re-established. If you make your route table entries too small Don> to support the size of network you are deploying then I don't Don> see route table maintenance itself solving the problem. I certainly won't disagree with that statement. The situation I want to think about is what happens when there are n+1 entries needed, and only n available. Not 2n, or 10n. So in AODV and other situations, the network falls back to network flooding to get packets through, when it can't find an entry. So that's what happens if an attacker manages to push an important node out. What I'm trying to determine if there is any determinism in which entry is pushed out that the attacker can exploit. -- ] 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 Mar 29 18:25: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 BDB933A67D4 for ; Mon, 29 Mar 2010 18:25:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.467 X-Spam-Level: * X-Spam-Status: No, score=1.467 tagged_above=-999 required=5 tests=[AWL=-0.309, BAYES_50=0.001, 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 zgXgRFV5jtts for ; Mon, 29 Mar 2010 18:25:51 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by core3.amsl.com (Postfix) with ESMTP id A96243A6774 for ; Mon, 29 Mar 2010 18:25:50 -0700 (PDT) Received: from sandelman.ottawa.on.ca (desk.marajade.sandelman.ca [209.87.252.247]) by relay.sandelman.ca (Postfix) with ESMTPS id 1E35B346B3; Mon, 29 Mar 2010 21:23:44 -0400 (EDT) Received: from marajade.sandelman.ca (unknown [127.0.0.1]) by sandelman.ottawa.on.ca (Postfix) with ESMTP id 753914E7ED; Mon, 29 Mar 2010 21:26:17 -0400 (EDT) From: Michael Richardson To: d.sturek@att.net In-Reply-To: <01e801cacfa1$df8b67e0$9ea237a0$@sturek@att.net> 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> X-Mailer: MH-E 8.1; nmh 1.1; XEmacs 21.4 (patch 21) Date: Mon, 29 Mar 2010 21:26:17 -0400 Message-ID: <17256.1269912377@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, 30 Mar 2010 01:25:52 -0000 -----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. 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. 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? - -- ] 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 iQEVAwUBS7FTNYCLcPvd0N1lAQLeowgAn2043p/1x9+TmWB09nJAHPvGVdHpBASJ fZRnHjnOjrv5H/lIe+FHC8iQUae/1+Orjyii4ev4nB3pD1alJy31pylM02bhWS9t lFBozHKBH3GlIq6Bh8RRyRrzE0WVdQFlvQaRcqcvhfvTxc/knc5aoEos5zMX1nx3 aNDA55wTsWapuue8+T1Py4L6O/aOBHJQcOfHhHFdgX8R8ITM9N8wb1Jaoa3yVcXd tAVhB42NmP9l+Bn+pZJlstK1BrYTe/RuP2jQUjGwMqfhjfwXjD6KTKmCBmr+b8xP Ztmla/UjKwrXoACEhavCF7sJnHkmJxtdwfwLsjLz7md9PvQJLWP2UA== =0QxQ -----END PGP SIGNATURE----- From pal@cs.stanford.edu Mon Mar 29 19:28: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 EC04C3A67C0 for ; Mon, 29 Mar 2010 19:28:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.446 X-Spam-Level: X-Spam-Status: No, score=-4.446 tagged_above=-999 required=5 tests=[AWL=-0.466, 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 CFsRlJRnyb4s for ; Mon, 29 Mar 2010 19:28:30 -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 DCCFC3A63EC for ; Mon, 29 Mar 2010 19:28:30 -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 1NwRCN-0006W7-B5; Mon, 29 Mar 2010 19:28:59 -0700 In-Reply-To: <17256.1269912377@marajade.sandelman.ca> 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> Mime-Version: 1.0 (Apple Message framework v753.1) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <93B6031E-ECE1-4C63-848C-1C43B48F69C8@cs.stanford.edu> Content-Transfer-Encoding: 7bit From: Philip Levis Date: Mon, 29 Mar 2010 19:27:03 -0700 To: Michael Richardson X-Mailer: Apple Mail (2.753.1) X-Scan-Signature: ae35470b07fbe4e2dbb6b33d1de23969 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, 30 Mar 2010 02:28:32 -0000 On Mar 29, 2010, at 6:26 PM, 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. > > 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 came up in Anaheim; one approach to defending from this is requiring a node to respond to a nonce before handling its packets (e.g., inserting a routing table entry). There are of course timeliness issues, etc. Phil From pthubert@cisco.com Mon Mar 29 22:48: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 22D4B3A6933 for ; Mon, 29 Mar 2010 22:48:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.186 X-Spam-Level: X-Spam-Status: No, score=-1.186 tagged_above=-999 required=5 tests=[AWL=-4.738, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, EXTRA_MPART_TYPE=1, HTML_MESSAGE=0.001, SARE_GIF_ATTACH=1.42] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RGZOwWlMOWiO for ; Mon, 29 Mar 2010 22:48:41 -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 C2C2B3A699C for ; Mon, 29 Mar 2010 22:48:36 -0700 (PDT) Authentication-Results: ams-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-Files: image001.png, image002.gif : 6279, 87 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkcEAHMtsUuQ/uCWe2dsb2JhbABvT4FTlztfFQEBCwsiBhynPYg9kE4ChBRqBA X-IronPort-AV: E=Sophos;i="4.51,332,1267401600"; d="gif'147?png'147,150?scan'147,150,208,217,147,150";a="4953011" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-2.cisco.com with ESMTP; 30 Mar 2010 05:14: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 o2U5n4gk001929; Tue, 30 Mar 2010 05:49:04 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); Tue, 30 Mar 2010 07:49:04 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----_=_NextPart_001_01CACFCC.B453C36D" Date: Tue, 30 Mar 2010 07:49:00 +0200 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D0188AF8D@XMB-AMS-107.cisco.com> In-Reply-To: <006301cac059$b2da3e30$188eba90$@alexander@ekasystems.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] Ack the DAO? Thread-Index: AcrAPfPIyxeYBGuWTw+gDRQ3zVwt/QAGegBQA90urwA= References: <6A2A459175DABE4BB11DE2026AA50A5D016982C5@XMB-AMS-107.cisco.com> <006301cac059$b2da3e30$188eba90$@alexander@ekasystems.com> From: "Pascal Thubert (pthubert)" To: "Roger Alexander" , X-OriginalArrivalTime: 30 Mar 2010 05:49:04.0411 (UTC) FILETIME=[B49F7EB0:01CACFCC] 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: Tue, 30 Mar 2010 05:48:43 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CACFCC.B453C36D Content-Type: multipart/alternative; boundary="----_=_NextPart_002_01CACFCC.B453C36D" ------_=_NextPart_002_01CACFCC.B453C36D Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 SGkgUm9nZXI6DQoNCiANCg0KVGhpcyBsb29rcyBpbnRlcmVzdGluZy4gQ291bGQgeW91IHBsZWFz ZSByZWZpbmUgeW91ciBpZGVhcyBvbiB0aGlzIHN1YmplY3Q/IA0KDQogDQoNClBhc2NhbA0KDQog DQoNCkZyb206IFJvZ2VyIEFsZXhhbmRlciBbbWFpbHRvOnJvZ2VyLmFsZXhhbmRlckBla2FzeXN0 ZW1zLmNvbV0gDQpTZW50OiBXZWRuZXNkYXksIE1hcmNoIDEwLCAyMDEwIDI6NTggUE0NClRvOiBQ YXNjYWwgVGh1YmVydCAocHRodWJlcnQpOyByb2xsQGlldGYub3JnDQpTdWJqZWN0OiBSRTogW1Jv bGxdIEFjayB0aGUgREFPPw0KDQogDQoNCkhpIFBhc2NhbCwgV0csDQoNCiANCg0KSSBkbyB0aGlu ayBEQU9zIHNob3VsZCBiZSBhY2tub3dsZWRnZWQuIEZyb20gdGhlIHBlcnNwZWN0aXZlIG9mIGEg c3lzdGVtIGVtcGxveWluZyDigJhzdG9yaW5n4oCZIG5vZGVzLCB0aGVyZSB3aWxsIGJlIGFkZGl0 aW9uYWwgYmVuZWZpdHMgaW4gdGVybXMgb2Ygb3B0aW1pemF0aW9ucyB0aGF0IHJlZHVjZSB0aGUg b3ZlcmhlYWQgb2YgZXhjaGFuZ2VkIHN0YXRlIGluZm9ybWF0aW9uIGlmIHRoZSBEQU8gbWVzc2Fn ZXMgYXJlIHJlbGlhYmx5IHRyYW5zbWl0dGVkLiBUaGlzIG1heSByZXF1aXJlIHNvbWUgYWRkaXRp b25hbCB1cGRhdGUgdG8gdGhlIERBTyBtZXNzYWdlIHN0cnVjdHVyZSBidXQgd2lsbCBvcGVuIHRo ZSBwb3NzaWJpbGl0eSBmb3IgaW1wbGVtZW50YXRpb25zIHRvIGZ1cnRoZXIgcmVkdWNlIFJQTCBv dmVyaGVhZC4NCg0KIA0KDQpSb2dlcg0KDQogDQoNCkZyb206IHJvbGwtYm91bmNlc0BpZXRmLm9y ZyBbbWFpbHRvOnJvbGwtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIFBhc2NhbCBUaHVi ZXJ0IChwdGh1YmVydCkNClNlbnQ6IFdlZG5lc2RheSwgTWFyY2ggMTAsIDIwMTAgNTozOSBBTQ0K VG86IHJvbGxAaWV0Zi5vcmcNClN1YmplY3Q6IFtSb2xsXSBBY2sgdGhlIERBTz8NCg0KIA0KDQpX RzoNCg0KIA0KDQpSUEwgMDcgcHJvdmlkZXMgbWVhbnMgZm9yIGEgbm9kZSB0byBhZHZlcnRpc2Ug c29tZSByZWFjaGFiaWxpdHkgdXNpbmcgYSBEQU8gbWVjaGFuaXNtLiBUaGUgREFPIGNhbiBiZSB0 cmlnZ2VyZWQgYnkgdGhlIG5vZGUgdG8gbWF0Y2ggaXRzIG93biBuZWVkcy4gSXQgY2FuIGFsc28g YmUgc3RpbXVsYXRlZCBieSBhIHBhcmVudCwgYnkgaW5jcmVtZW50aW5nIHRoZSBEVFNOLCBvciBi eSB0aGUgcm9vdCwgYnkgc2V0dGluZyB0aGUgVCBiaXQgdGhhdCBjYXVzZXMgdGhlIERUU04gaW5j cmVtZW50IHRvIHNwYW4gdGhlIHdob2xlIERPREFHLg0KDQogDQoNClRoZSBEVFNOIHdhcyBhZGRl ZCBhcyBhIHJlcGxhY2VtZW50IHRvIGEgc2luZ2xlIGJpdCBiZWNhdXNlLCBkdWUgdG8gdGhlIG5h dHVyZSBvZiBhbiBMTE4sIHdlIHRob3VnaHQgdGhhdCB0aGUgYml0IG1pZ2h0IGJlIGxvc3Qgd2hl cmVhcyBhIERUU04gaW5jcmVtZW50IG11c3QgYmUgc2VlbiBhdCBzb21lIHBvaW50LiBCdXQgdGhl IG90aGVyIHdheSBhcm91bmQsIHRoZSBEQU8gbWVzc2FnZSBpcyBub3QgYWNrbm93bGVkZ2VkIHNv IGEgbm9kZSBtaWdodCBub3Qgb2J0YWluIHRoZSBzZXJ2aWNlIHRoYXQgaXQgZXhwZWN0cywgYW5k IGEgcm91dGUgcHJvcGFnYXRpb24gbWlnaHQgYmUgaW5hcHByb3ByaWF0ZWx5IGRlbGF5ZWQuDQoN CiANCg0KU28gdGhlIHNpbXBsZSBxdWVzdGlvbiBpcywgc2hvdWxkIHdlIG1ha2UgdGhlIERBTyBh IGJpdCBtb3JlIHJlbGlhYmxlIGJ5IGFkZGluZyBhbiBhY2s/IA0KDQogDQoNCiANCg0KCQ0KUGFz Y2FsIFRodWJlcnQNCkVuZ2luZWVyLnNvZnR3YXJlIEVuZ2luZWVyaW5nDQpQcm9kdWN0IERldmVs b3BtZW50DQpwdGh1YmVydEBjaXNjby5jb20gPG1haWx0bzpwdGh1YmVydEBjaXNjby5jb20+IA0K UGhvbmU6ICszMyA0IDk3MjMgMjYzNA0KTW9iaWxlOiArMzMgNiAxOTk4IDI5ODUNCg0KQ2lzY28g U3lzdGVtcyBGcmFuY2UNClZpbGxhZ2UgZCdFbnRyZXByaXNlcyBHcmVlbiBTaWRlDQo0MDAgQXZl bnVlIGRlIFJvdW1hbmlsbGUgDQpCYXRpbWVudCBUIDMgDQowNjQxMCANCkJJT1QgLSBTT1BISUEg QU5USVBPTElTDQpGcmFuY2UNCkNpc2NvLmNvbSA8aHR0cDovL3d3dy5jaXNjby5jb20vZ2xvYmFs L0ZSLz4gDQoNCiAgDQoNCiANCg0KIFRoaW5rIGJlZm9yZSB5b3UgcHJpbnQuDQoNCkNpc2NvIFN5 c3RlbXMgRnJhbmNlLCBTb2Npw6l0w6kgw6AgcmVzcG9uc2FiaWl0w6kgbGltaXTDqWUsIFJ1ZSBD YW1pbGxlIERlc21vdWxpbnMg4oCTIEltbSBBdGxhbnRpcyBaYWMgRm9ydW0gU2VpbmUgSWxvdCA3 IDkyMTMwIElzc3kgbGVzIE1vdWxpbmVhdXgsIEF1IGNhcGl0YWwgZGUgOTEuNDcwIOKCrCwgMzQ5 IDE2NiA1NjEgUkNTIE5hbnRlcnJlLCBEaXJlY3RldXIgZGUgbGEgcHVibGljYXRpb246IEplYW4t THVjIE1pY2hlbCBHaXZvbmUsIEZvciBjb3Jwb3JhdGUgbGVnYWwgaW5mb3JtYXRpb24gZ28gdG86 DQpodHRwOi8vd3d3LmNpc2NvLmNvbS93ZWIvYWJvdXQvZG9pbmdfYnVzaW5lc3MvbGVnYWwvY3Jp L2luZGV4Lmh0bWwNCg0KIA0KDQogDQoNCg== ------_=_NextPart_002_01CACFCC.B453C36D Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij48bWV0YSBuYW1lPUdlbmVyYXRvciBjb250ZW50 PSJNaWNyb3NvZnQgV29yZCAxNCAoZmlsdGVyZWQgbWVkaXVtKSI+PCEtLVtpZiAhbXNvXT48c3R5 bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7YmVoYXZpb3I6dXJs KCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0KLnNo YXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwhW2VuZGlmXS0tPjxz dHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFt aWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7 fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRp di5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9u dC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO30NCmE6 bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9y OmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNv SHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBs ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAuTXNvQWNldGF0ZSwgbGkuTXNvQWNl dGF0ZSwgZGl2Lk1zb0FjZXRhdGUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHls ZS1saW5rOiJUZXh0ZSBkZSBidWxsZXMgQ2FyIjsNCgltYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwi c2Fucy1zZXJpZiI7fQ0Kc3Bhbi5UZXh0ZWRlYnVsbGVzQ2FyDQoJe21zby1zdHlsZS1uYW1lOiJU ZXh0ZSBkZSBidWxsZXMgQ2FyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxl LWxpbms6IlRleHRlIGRlIGJ1bGxlcyI7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2Vy aWYiO30NCnAuQmFsbG9vblRleHQsIGxpLkJhbGxvb25UZXh0LCBkaXYuQmFsbG9vblRleHQNCgl7 bXNvLXN0eWxlLW5hbWU6IkJhbGxvb24gVGV4dCI7DQoJbXNvLXN0eWxlLWxpbms6IkJhbGxvb24g VGV4dCBDaGFyIjsNCgltYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250 LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7fQ0Kc3Bh bi5CYWxsb29uVGV4dENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkJhbGxvb24gVGV4dCBDaGFyIjsN Cgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkJhbGxvb24gVGV4dCI7 DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiO30NCnNwYW4uRW1haWxTdHlsZTIx DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fu cy1zZXJpZiI7DQoJY29sb3I6d2luZG93dGV4dDt9DQpzcGFuLkVtYWlsU3R5bGUyMg0KCXttc28t c3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYi Ow0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjMNCgl7bXNvLXN0eWxlLXR5cGU6 cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCglj b2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1v bmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEy LjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3MC44NXB0IDcwLjg1cHQgNzAuODVwdCA3MC44NXB0O30N CmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0t W2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRt YXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4N CjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRh PSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPjwvaGVhZD48Ym9keSBs YW5nPUVOLVVTIGxpbms9Ymx1ZSB2bGluaz1wdXJwbGU+PGRpdiBjbGFzcz1Xb3JkU2VjdGlvbjE+ PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xvcjojMUY0OTdEJz5IaSBSb2dlcjo8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xv cjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFs PjxzcGFuIHN0eWxlPSdjb2xvcjojMUY0OTdEJz5UaGlzIGxvb2tzIGludGVyZXN0aW5nLiBDb3Vs ZCB5b3UgcGxlYXNlIHJlZmluZSB5b3VyIGlkZWFzIG9uIHRoaXMgc3ViamVjdD8gPG86cD48L286 cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6IzFGNDk3 RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxz cGFuIHN0eWxlPSdjb2xvcjojMUY0OTdEJz5QYXNjYWw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9k aXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xvcjojMUY0OTdEJz48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+PGRpdiBzdHlsZT0nYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6 c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDQuMHB0Jz48ZGl2PjxkaXYgc3R5 bGU9J2JvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMu MHB0IDBjbSAwY20gMGNtJz48cCBjbGFzcz1Nc29Ob3JtYWw+PGI+PHNwYW4gc3R5bGU9J2ZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiJz5Gcm9tOjwvc3Bh bj48L2I+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IlRhaG9tYSIs InNhbnMtc2VyaWYiJz4gUm9nZXIgQWxleGFuZGVyIFttYWlsdG86cm9nZXIuYWxleGFuZGVyQGVr YXN5c3RlbXMuY29tXSA8YnI+PGI+U2VudDo8L2I+IFdlZDwvc3Bhbj48c3BhbiBsYW5nPUZSIHN0 eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIic+ bmVzZGF5LCBNYXJjaCAxMCwgMjAxMCAyOjU4IFBNPGJyPjxiPlRvOjwvYj4gUGFzY2FsIFRodWJl cnQgKHB0aHViZXJ0KTsgcm9sbEBpZXRmLm9yZzxicj48Yj5TdWJqZWN0OjwvYj4gUkU6IFtSb2xs XSBBY2sgdGhlIERBTz88bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PC9kaXY+PHAgY2xhc3M9 TXNvTm9ybWFsPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBz dHlsZT0nY29sb3I6IzFGNDk3RCc+SGkgUGFzY2FsLCBXRyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xvcjoj MUY0OTdEJz5JIGRvIHRoaW5rIERBT3Mgc2hvdWxkIGJlIGFja25vd2xlZGdlZC4gRnJvbSB0aGUg cGVyc3BlY3RpdmUgb2YgYSBzeXN0ZW0gZW1wbG95aW5nIOKAmHN0b3JpbmfigJkgbm9kZXMsIHRo ZXJlIHdpbGwgYmUgYWRkaXRpb25hbCBiZW5lZml0cyBpbiB0ZXJtcyBvZiBvcHRpbWl6YXRpb25z IHRoYXQgcmVkdWNlIHRoZSBvdmVyaGVhZCBvZiBleGNoYW5nZWQgc3RhdGUgaW5mb3JtYXRpb24g aWYgdGhlIERBTyBtZXNzYWdlcyBhcmUgcmVsaWFibHkgdHJhbnNtaXR0ZWQuIFRoaXMgbWF5IHJl cXVpcmUgc29tZSBhZGRpdGlvbmFsIHVwZGF0ZSB0byB0aGUgREFPIG1lc3NhZ2Ugc3RydWN0dXJl IGJ1dCB3aWxsIG9wZW4gdGhlIHBvc3NpYmlsaXR5IGZvciBpbXBsZW1lbnRhdGlvbnMgdG8gZnVy dGhlciByZWR1Y2UgUlBMIG92ZXJoZWFkLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1N c29Ob3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9yOiMxRjQ5N0QnPlJv Z2VyPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0n Y29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxkaXY+PGRpdiBzdHls ZT0nYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4w cHQgMGNtIDBjbSAwY20nPjxwIGNsYXNzPU1zb05vcm1hbD48Yj48c3BhbiBzdHlsZT0nZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiInPkZyb206PC9zcGFu PjwvYj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiVGFob21hIiwi c2Fucy1zZXJpZiInPiByb2xsLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpyb2xsLWJvdW5jZXNA aWV0Zi5vcmddIDxiPk9uIEJlaGFsZiBPZiA8L2I+UGFzY2FsIFRodWJlcnQgKHB0aHViZXJ0KTxi cj48Yj5TZW50OjwvYj4gV2VkbmVzZGF5LCBNYXJjaCAxMCwgMjAxMCA1OjM5IEFNPGJyPjxiPlRv OjwvYj4gcm9sbEBpZXRmLm9yZzxicj48Yj5TdWJqZWN0OjwvYj4gW1JvbGxdIEFjayB0aGUgREFP PzxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48L2Rpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PG86 cD4mbmJzcDs8L286cD48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPldHOjxvOnA+PC9vOnA+PC9wPjxw IGNsYXNzPU1zb05vcm1hbD48bzpwPiZuYnNwOzwvbzpwPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+ UlBMIDA3IHByb3ZpZGVzIG1lYW5zIGZvciBhIG5vZGUgdG8gYWR2ZXJ0aXNlIHNvbWUgcmVhY2hh YmlsaXR5IHVzaW5nIGEgREFPIG1lY2hhbmlzbS4gVGhlIERBTyBjYW4gYmUgdHJpZ2dlcmVkIGJ5 IHRoZSBub2RlIHRvIG1hdGNoIGl0cyBvd24gbmVlZHMuIEl0IGNhbiBhbHNvIGJlIHN0aW11bGF0 ZWQgYnkgYSBwYXJlbnQsIGJ5IGluY3JlbWVudGluZyB0aGUgRFRTTiwgb3IgYnkgdGhlIHJvb3Qs IGJ5IHNldHRpbmcgdGhlIFQgYml0IHRoYXQgY2F1c2VzIHRoZSBEVFNOIGluY3JlbWVudCB0byBz cGFuIHRoZSB3aG9sZSBET0RBRy48bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PG86 cD4mbmJzcDs8L286cD48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPlRoZSBEVFNOIHdhcyBhZGRlZCBh cyBhIHJlcGxhY2VtZW50IHRvIGEgc2luZ2xlIGJpdCBiZWNhdXNlLCBkdWUgdG8gdGhlIG5hdHVy ZSBvZiBhbiBMTE4sIHdlIHRob3VnaHQgdGhhdCB0aGUgYml0IG1pZ2h0IGJlIGxvc3Qgd2hlcmVh cyBhIERUU04gaW5jcmVtZW50IG11c3QgYmUgc2VlbiBhdCBzb21lIHBvaW50LiBCdXQgdGhlIG90 aGVyIHdheSBhcm91bmQsIHRoZSBEQU8gbWVzc2FnZSBpcyBub3QgYWNrbm93bGVkZ2VkIHNvIGEg bm9kZSBtaWdodCBub3Qgb2J0YWluIHRoZSBzZXJ2aWNlIHRoYXQgaXQgZXhwZWN0cywgYW5kIGEg cm91dGUgcHJvcGFnYXRpb24gbWlnaHQgYmUgaW5hcHByb3ByaWF0ZWx5IGRlbGF5ZWQuPG86cD48 L286cD48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPjxwIGNsYXNz PU1zb05vcm1hbD5TbyB0aGUgc2ltcGxlIHF1ZXN0aW9uIGlzLCBzaG91bGQgd2UgbWFrZSB0aGUg REFPIGEgYml0IG1vcmUgcmVsaWFibGUgYnkgYWRkaW5nIGFuIGFjaz8gPG86cD48L286cD48L3A+ PHAgY2xhc3M9TXNvTm9ybWFsPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPjxwIGNsYXNzPU1zb05vcm1h bD48bzpwPiZuYnNwOzwvbzpwPjwvcD48dGFibGUgY2xhc3M9TXNvTm9ybWFsVGFibGUgYm9yZGVy PTAgY2VsbHNwYWNpbmc9MCBjZWxscGFkZGluZz0wIHdpZHRoPTU0MyBzdHlsZT0nd2lkdGg6NDA3 LjI1cHQnPjx0cj48dGQgc3R5bGU9J3BhZGRpbmc6MGNtIDBjbSAwY20gMGNtJz48dGFibGUgY2xh c3M9TXNvTm9ybWFsVGFibGUgYm9yZGVyPTAgY2VsbHNwYWNpbmc9MCBjZWxscGFkZGluZz0wIHdp ZHRoPTYwMCBzdHlsZT0nd2lkdGg6NDUwLjA1cHQnPjx0cj48dGQgY29sc3Bhbj0zIHN0eWxlPSdw YWRkaW5nOjBjbSAwY20gMGNtIDBjbSc+PC90ZD48L3RyPjx0ciBzdHlsZT0naGVpZ2h0Ojk0LjA1 cHQnPjx0ZCBub3dyYXAgdmFsaWduPXRvcCBzdHlsZT0ncGFkZGluZzowY20gMGNtIDExLjI1cHQg MTguMHB0O2hlaWdodDo5NC4wNXB0Jz48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21zby1tYXJn aW4tdG9wLWFsdDphdXRvO21hcmdpbi1ib3R0b206MTIuMHB0Jz48Yj48c3BhbiBzdHlsZT0nZm9u dC1zaXplOjguNXB0O2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiO2NvbG9yOiM2NjY2 NjYnPlBhc2NhbCBUaHViZXJ0PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjguNXB0 O2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiO2NvbG9yOiM2NjY2NjYnPjxicj48Yj5F bmdpbmVlci5zb2Z0d2FyZSBFbmdpbmVlcmluZzwvYj48YnI+PGI+UHJvZHVjdCBEZXZlbG9wbWVu dDwvYj48YnI+PGEgaHJlZj0ibWFpbHRvOnB0aHViZXJ0QGNpc2NvLmNvbSI+PHNwYW4gc3R5bGU9 J2NvbG9yOiM2NjY2NjYnPnB0aHViZXJ0QGNpc2NvLmNvbTwvc3Bhbj48L2E+PGJyPlBob25lOiA8 Yj4rMzMgNCA5NzIzIDI2MzQ8L2I+PGJyPk1vYmlsZTogPGI+KzMzIDYgMTk5OCAyOTg1PC9iPjxv OnA+PC9vOnA+PC9zcGFuPjwvcD48L3RkPjx0ZCBub3dyYXAgdmFsaWduPXRvcCBzdHlsZT0ncGFk ZGluZzowY20gMGNtIDcuNXB0IDE1LjBwdDtoZWlnaHQ6OTQuMDVwdCc+PHAgY2xhc3M9TXNvTm9y bWFsIHN0eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJnaW4tYm90dG9tOjEyLjBwdCc+ PGI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTo4LjVwdDtmb250LWZhbWlseToiQXJpYWwiLCJzYW5z LXNlcmlmIjtjb2xvcjojNjY2NjY2Jz5DaXNjbyBTeXN0ZW1zIEZyYW5jZTwvc3Bhbj48L2I+PHNw YW4gc3R5bGU9J2ZvbnQtc2l6ZTo4LjVwdDtmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlm Ijtjb2xvcjojNjY2NjY2Jz48YnI+VmlsbGFnZSBkJ0VudHJlcHJpc2VzIEdyZWVuIFNpZGU8YnI+ NDAwIEF2ZW51ZSBkZSBSb3VtYW5pbGxlIDxicj5CYXRpbWVudCBUIDMgPGJyPjA2NDEwIDxicj5C SU9UIC0gU09QSElBIEFOVElQT0xJUzxicj5GcmFuY2U8YnI+PGEgaHJlZj0iaHR0cDovL3d3dy5j aXNjby5jb20vZ2xvYmFsL0ZSLyI+PHNwYW4gc3R5bGU9J2NvbG9yOiM2NjY2NjYnPkNpc2NvLmNv bTwvc3Bhbj48L2E+PG86cD48L286cD48L3NwYW4+PC9wPjwvdGQ+PHRkIHdpZHRoPTE4NiBzdHls ZT0nd2lkdGg6MTM5Ljc1cHQ7cGFkZGluZzowY20gMGNtIDBjbSAwY207aGVpZ2h0Ojk0LjA1cHQn PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEyLjBwdDtmb250LWZh bWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiJz4mbmJzcDs8aW1nIGJvcmRlcj0wIHdpZHRo PTE2NCBoZWlnaHQ9MTA4IGlkPSJJbWFnZV94MDAyMF8xIiBzcmM9ImNpZDppbWFnZTAwMS5wbmdA MDFDQUNGREQuNzQ1MjhFOTAiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L3RkPjwvdHI+PC90YWJs ZT48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1m YW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjtkaXNwbGF5Om5vbmUnPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD48dGFibGUgY2xhc3M9TXNvTm9ybWFsVGFibGUgYm9yZGVyPTAgY2Vs bHNwYWNpbmc9MCBjZWxscGFkZGluZz0wIHdpZHRoPTcxOSBzdHlsZT0nd2lkdGg6NTM5LjE1cHQn Pjx0ciBzdHlsZT0naGVpZ2h0OjkwLjhwdCc+PHRkIHdpZHRoPTcxOSBzdHlsZT0nd2lkdGg6NTM5 LjE1cHQ7cGFkZGluZzowY20gMTguMHB0IDBjbSAxOC4wcHQ7aGVpZ2h0OjkwLjhwdCc+PHAgY2xh c3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6Ny41cHQ7Zm9udC1mYW1pbHk6IkFy aWFsIiwic2Fucy1zZXJpZiI7Y29sb3I6IzAwOTkwMCc+PGltZyBib3JkZXI9MCB3aWR0aD0xOCBo ZWlnaHQ9MTkgaWQ9IkltYWdlX3gwMDIwXzIiIHNyYz0iY2lkOmltYWdlMDAyLmdpZkAwMUNBQ0ZE RC43NDUyOEU5MCIgYWx0PSJUaGluayBiZWZvcmUgeW91IHByaW50LiI+VGhpbmsgYmVmb3JlIHlv dSBwcmludC48YnI+PGJyPjwvc3Bhbj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjcuNXB0O2ZvbnQt ZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiO2NvbG9yOiM5OTk5OTknPkNpc2NvIFN5c3RlbXMg RnJhbmNlLCBTb2Npw6l0w6kgw6AgcmVzcG9uc2FiaWl0w6kgbGltaXTDqWUsIFJ1ZSBDYW1pbGxl IERlc21vdWxpbnMg4oCTIEltbSBBdGxhbnRpcyBaYWMgRm9ydW0gU2VpbmUgSWxvdCA3IDkyMTMw IElzc3kgbGVzIE1vdWxpbmVhdXgsIEF1IGNhcGl0YWwgZGUgOTEuNDcwIOKCrCwgMzQ5IDE2NiA1 NjEgUkNTIE5hbnRlcnJlLCBEaXJlY3RldXIgZGUgbGEgcHVibGljYXRpb246IEplYW4tTHVjIE1p Y2hlbCBHaXZvbmUsIEZvciBjb3Jwb3JhdGUgbGVnYWwgaW5mb3JtYXRpb24gZ28gdG86PGJyPjxh IGhyZWY9Imh0dHA6Ly93d3cuY2lzY28uY29tL3dlYi9hYm91dC9kb2luZ19idXNpbmVzcy9sZWdh bC9jcmkvaW5kZXguaHRtbCI+aHR0cDovL3d3dy5jaXNjby5jb20vd2ViL2Fib3V0L2RvaW5nX2J1 c2luZXNzL2xlZ2FsL2NyaS9pbmRleC5odG1sPC9hPjwvc3Bhbj48c3BhbiBzdHlsZT0nZm9udC1z aXplOjcuNXB0O2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiO2NvbG9yOiMwMDk5MDAn PjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L3RkPjwvdHI+PC90YWJsZT48cCBjbGFzcz1Nc29Ob3Jt YWw+PG86cD48L286cD48L3A+PC90ZD48L3RyPjwvdGFibGU+PHAgY2xhc3M9TXNvTm9ybWFsPjxz cGFuIGxhbmc9RlI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1h bD48c3BhbiBsYW5nPUZSPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48L2Rpdj48 L2JvZHk+PC9odG1sPg== ------_=_NextPart_002_01CACFCC.B453C36D-- ------_=_NextPart_001_01CACFCC.B453C36D Content-Type: image/png; name="image001.png" Content-Transfer-Encoding: base64 Content-ID: Content-Description: image001.png Content-Location: image001.png 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_001_01CACFCC.B453C36D Content-Type: image/gif; name="image002.gif" Content-Transfer-Encoding: base64 Content-ID: Content-Description: image002.gif Content-Location: image002.gif R0lGODlhEgATAJEAAAAAAP///wCZAP///yH5BAEAAAMALAAAAAASABMAAAIojI+pGyK8nINqUiTf bVnfvHEg1UmhdZRqaawu6XZVjKb0/CYxo8JOAQA7 ------_=_NextPart_001_01CACFCC.B453C36D-- From pthubert@cisco.com Mon Mar 29 23:35: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 2A6EB3A69D1 for ; Mon, 29 Mar 2010 23:35:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.301 X-Spam-Level: X-Spam-Status: No, score=-7.301 tagged_above=-999 required=5 tests=[AWL=2.168, 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 wTfb6mqK8D3t for ; Mon, 29 Mar 2010 23:35:35 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 539503A69CB for ; Mon, 29 Mar 2010 23:35:34 -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: AtwBADc4sUuQ/uCWe2dsb2JhbACbLBUBAQsLIgYcpzGZDYUABI4c X-IronPort-AV: E=Sophos;i="4.51,333,1267401600"; d="scan'208";a="58722903" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 30 Mar 2010 06:36:02 +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 o2U6a2ud009334; Tue, 30 Mar 2010 06:36:02 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); Tue, 30 Mar 2010 08:36: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="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 30 Mar 2010 08:35:58 +0200 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D0188AF9F@XMB-AMS-107.cisco.com> In-Reply-To: <93B6031E-ECE1-4C63-848C-1C43B48F69C8@cs.stanford.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] Mixed mode operation Thread-Index: AcrPsMyyKzPLOmDSTL+9iPHR6vLsvAAHS38g 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> <93B6031E-ECE1-4C63-848C-1C43B48F69C8@cs.stanford.edu> From: "Pascal Thubert (pthubert)" To: "Philip Levis" , "Michael Richardson" X-OriginalArrivalTime: 30 Mar 2010 06:36:02.0038 (UTC) FILETIME=[440F4160:01CACFD3] 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, 30 Mar 2010 06:35:36 -0000 Hi: As Phil said the anti-replay came up in Anaheim. This 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 appropriately (too small) just causes permanent look ups that 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 becomes a deployment issue. Usually what we address there is the bandwidth capacity on the root radio space. In this thread, the 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 capacity needs is probably divide and conquer, and nothing will replace a proper capacity planning overall. RPL enables DAGs that are made of multiple DODAGs. RPL enables the radio roots to be connected to a backbone, with a super-root there if you want a single DODAG. RPL dynamically adapts to the addition or the removal of a root in an instance so adapting the capacity to new requirements has only a local impact on the network. It also adapts dynamically to the addition of a parent in the DODAG to 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 somewhere, then we might have an issue with the parent selection. At the moment, a parent cannot indicate the capacity of its routing 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.=20 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 pushback mechanism from the nodes where the capacity is 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. Pascal > -----Original Message----- > From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of > Philip Levis > Sent: Tuesday, March 30, 2010 4:27 AM > To: Michael Richardson > Cc: 'roll' > Subject: Re: [Roll] Mixed mode operation >=20 >=20 > On Mar 29, 2010, at 6:26 PM, Michael Richardson wrote: >=20 > > -----BEGIN PGP SIGNED MESSAGE----- > > Hash: SHA1 > > > > > >>>>>> "Don" =3D=3D 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. > > > > 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. >=20 > This came up in Anaheim; one approach to defending from this is requiring a > node to respond to a nonce before handling its packets (e.g., inserting a > routing table entry). There are of course timeliness issues, etc. >=20 > Phil >=20 > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From joydeep.tripathi@gmail.com Tue Mar 30 00:45: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 767AC3A67D3 for ; Tue, 30 Mar 2010 00:45:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.39 X-Spam-Level: X-Spam-Status: No, score=0.39 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, 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 yDTvinbKcunM for ; Tue, 30 Mar 2010 00:45:58 -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 E74DB3A67EF for ; Tue, 30 Mar 2010 00:45:57 -0700 (PDT) Received: by bwz9 with SMTP id 9so917628bwz.29 for ; Tue, 30 Mar 2010 00:46:22 -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:content-type :content-transfer-encoding; bh=fWSIbLhFJWvB4fZck3MehAAY4l7W1ivQ3Joh3CtuCIA=; b=RpmicM6GWTV1y/yn82Pa+qpzgIjd6UzmFEu5CFpj8aT/DnsHVsi7nLQOROOqLJlGxq NPHEO7u3j6LAaCRP2Ch7Omd5iyKaR4KnAe5ZWcwHBuhIbaib0i5UWQy337SQrOP6ZXBr 8nijKtVUmjnch3VKs+DzTvaS6+l8wDxTwsO+k= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=pzmOXl/1Ftl1j0WuzO0X2EYJZQDM+k3/nUM8iqSnKdP/H4oQ1kb+xYMZjxJwAK2WLG yySCcTM/Vp1a6AaN4TfAoDyLl9LZxFVzjdzOFonWJGpJPlGSTfDMyorAX1w+ZqBGsNwg Z7CLwOyvnnkN8a/ai3fVGQpqHWbH5XbChzRaw= MIME-Version: 1.0 Received: by 10.204.119.12 with HTTP; Tue, 30 Mar 2010 00:46:22 -0700 (PDT) In-Reply-To: <19e8ae197e37.197e3719e8ae@drexel.edu> References: <19e8ae197e37.197e3719e8ae@drexel.edu> Date: Tue, 30 Mar 2010 03:46:22 -0400 Received: by 10.204.136.15 with SMTP id p15mr1353835bkt.172.1269935182618; Tue, 30 Mar 2010 00:46:22 -0700 (PDT) Message-ID: From: Joydeep Tripathi To: ROLL WG Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: [Roll] Fwd: New Version Notification for draft-tripathi-roll-rpl-simulation-03 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 30 Mar 2010 07:45:59 -0000 Hi, We published another draft on Simulation results of RPL. In this revision, we added path stretch and delay metric comparison of the packets in RPL routing with shortest path routing. We also added Simulation results of RPL in a typical home/building routing traffic scenario. Thanks to Jerry for providing the details of message length and distribution in such a network. Note, we did not attempt to use any random topology with a random link quality, cause that might not provide us with intuition into how real deployment may behave in presence of link quality variation and link PDR distribution. We also simulate RPL with a 86 node topology, and in process of simulating it in another real network of few thousand nodes. This simulation study shows, the path stretch is very less in the home/building routing scenario. Also, the delay bound in RPL is not worse than that of shortest path routing, showing P2P routing in RPL a viable option for this kind of applications in terms of Path quality. Looking forward to any comments/suggestions. Thanks, Joydeep ---------- Forwarded message ---------- From: Joydeep Tripathi Date: Thu, Mar 25, 2010 at 3:10 PM Subject: Fwd: New Version Notification for draft-tripathi-roll-rpl-simulati= on-03 To: joydeep.tripathi@gmail.com ---------- Forwarded message ---------- From:=A0IETF I-D Submission Tool To:=A0jt369@drexel.edu Date:=A0Tue, 23 Mar 2010 21:35:34 -0700 (PDT) Subject:=A0New Version Notification for draft-tripathi-roll-rpl-simulation-= 03 A new version of I-D, draft-tripathi-roll-rpl-simulation-03.txt has been successfully submitted by Joydeep Tripathi and posted to the IETF repository. Filename: =A0 =A0 =A0 =A0draft-tripathi-roll-rpl-simulation Revision: =A0 =A0 =A0 =A003 Title: =A0 =A0 =A0 =A0 =A0 Performance Evaluation of Routing Protocol for L= ow Power and Lossy Networks (RPL) Creation_date: =A0 2010-03-23 WG ID: =A0 =A0 =A0 =A0 =A0 Independent Submission Number_of_pages: 15 Abstract: This document presents a performance evaluation of the Routing Protocol for Low power and Lossy Networks (RPL). =A0Detailed simulations are carried out to produce several routing performance metrics using a set of real-life scenarios. The IETF Secretariat. From m.pouillot@watteco.com Tue Mar 30 02:02: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 CA89F3A6974 for ; Tue, 30 Mar 2010 02:02:50 -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=[BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, HELO_EQ_FR=0.35, J_CHICKENPOX_54=0.6, J_CHICKENPOX_73=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 xowGXVSkn1V7 for ; Tue, 30 Mar 2010 02:02:49 -0700 (PDT) Received: from mail.abrisite.fr (mx197.abrisite.fr [85.31.209.197]) by core3.amsl.com (Postfix) with ESMTP id 2D4DB3A6A09 for ; Tue, 30 Mar 2010 02:02:43 -0700 (PDT) Received: from [192.168.4.247] ([82.241.54.131]) by mail.abrisite.fr (POL Mail Securise v2.0) with ASMTP id MMH32909 for ; Tue, 30 Mar 2010 11:03:09 +0200 Message-ID: <4BB1BE50.7080009@watteco.com> Date: Tue, 30 Mar 2010 11:03:12 +0200 From: Mathieu Pouillot User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; fr; rv:1.9.1.8) Gecko/20100227 Thunderbird/3.0.3 MIME-Version: 1.0 To: roll@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [Roll] Clarification request about RPL X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: m.pouillot@watteco.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, 30 Mar 2010 09:02:50 -0000 Hi all, Watteco is implementing a RPL (draft-05 for the moment) on PLC nodes in a low power and low data rate context. After some tests, we have some interogations: - The DAO request generates a lot of traffic on the network, and most of the time it is not necessary to have the downward routes of all devices. Is there a mechanism to ask a DAO to specified devices? If not, what do you think to add a sub-option in the DIO to ask DAO to a specified device or maybe(more complex) a group of devices? - A point that is not very clear: Can the same node belong to several DoDag of the same instance? If yes, how the data traffic(UDP,TCP, or others) knows which route has to be used? By the way, when you are in different instance how the flow label has to be filled? - Is there a way to broadcast or multicast some data traffic in all our DoDag? - Is there a mechanism to annonce a broken route during data traffic? Thanks for the clarifications, best regards, Mathieu -- Mathieu Pouillot R&D Engineer m.pouillot@watteco.com Tel : +33(0)4 98 01 60 05 (Poste 43) Fax : +33(0)4 94 14 10 80 1766 Chemin de la Planquette 83130 LA GARDE - France www.watteco.com From mcr@sandelman.ca Tue Mar 30 07:23: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 2731F3A6BC9 for ; Tue, 30 Mar 2010 07:23:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.793 X-Spam-Level: X-Spam-Status: No, score=0.793 tagged_above=-999 required=5 tests=[AWL=1.617, 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 vtuxcYYMX2JT for ; Tue, 30 Mar 2010 07:23:34 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by core3.amsl.com (Postfix) with ESMTP id 577013A6BC5 for ; Tue, 30 Mar 2010 07:23:21 -0700 (PDT) Received: from sandelman.ottawa.on.ca (unknown [132.213.238.4]) by relay.sandelman.ca (Postfix) with ESMTPS id 3C28634740 for ; Tue, 30 Mar 2010 10:21:18 -0400 (EDT) Received: from marajade.sandelman.ca (unknown [127.0.0.1]) by sandelman.ottawa.on.ca (Postfix) with ESMTP id A9E3E4E798 for ; Tue, 30 Mar 2010 10:23:49 -0400 (EDT) From: Michael Richardson To: "roll" In-Reply-To: <6A2A459175DABE4BB11DE2026AA50A5D0188AF9F@XMB-AMS-107.cisco.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> <93B6031E-ECE1-4C63-848C-1C43B48F69C8@cs.stanford.edu> <6A2A459175DABE4BB11DE2026AA50A5D0188AF9F@XMB-AMS-107.cisco.com> X-Mailer: MH-E 8.1; nmh 1.1; XEmacs 21.4 (patch 21) Date: Tue, 30 Mar 2010 10:23:49 -0400 Message-ID: <8239.1269959029@marajade.sandelman.ca> Sender: mcr@sandelman.ca 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, 30 Mar 2010 14:23:38 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >>>>> "Pascal" == Pascal Thubert <(pthubert)" > writes: Pascal> As Phil said the anti-replay came up in Anaheim. This piece Pascal> is to be covered in the security analysis. So I think we Pascal> should only consider the saturation of routing tables in Pascal> this thread. okay. Pascal> If there are enough roots and still one DODAG is overloaded Pascal> somewhere, then we might have an issue with the DODAG Pascal> selection. We need is to push nodes on the ridge between Pascal> DADOGs to jump onto the other DODAG in order to balance the Pascal> load between DODAGs. To do that, we need a pushback Pascal> mechanism from the nodes where the capacity is reached to Pascal> the nodes on the ridge that can jump elsewhere. I think this is the most important part. Nodes have to agree to be parents. I think that this also makes the security arrangements easier. Do they need to do it with an individual ACK, or are there ways to accumulate this into a single message... I note that the intermediate node has to inform it's parent who it's children are (in the DIO), so that message could also be sent to the children! I think that in many layer-2s, that the children will see the DIO to the parent anyway. However, if the children include a nonce which the parent must return inorder to ack, then the DIO might grow too much. - -- ] 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 iQEUAwUBS7IJbICLcPvd0N1lAQJisAf1Eob9QBotH4Ebbb7hz0NrmINPRTUr2wyV Oh3EjP0q98RDiLnREO2d1YBB2T74k2Um3tyfEn6u4UlUNbvQCutTMOhWqfASfXHJ M5WmRxdkqcz3aaBfjiOMYBuBHy6GROulpCV2daFt7s8l8ZNQMXKGIqxnu4Oo1T+Y HgRnCu2+jGlLw0T62pd3A1KyPu7lzmliW3Jx3LlC4ZJFIS2UDM7f2zeU59XRI45h e4be/m6lXnsJej9NQd0zhxSHpxkzCaXedg9iYTbLoY1qLsfH4rjU4Eca4YZkX0s/ PLL4V0cGRzu50JBOSPflDiHkALr/MWKj4S3VV3JG7bbgWMutkxdC =rUPY -----END PGP SIGNATURE----- >>>>> "Pascal" == Pascal Thubert <(pthubert)" > writes: Pascal> Hi: Pascal> As Phil said the anti-replay came up in Anaheim. This piece Pascal> is to be covered in the security analysis. So I think we Pascal> should only consider the saturation of routing tables in Pascal> this thread. Pascal> Also I do not believe in churn in routing tables to address Pascal> capacity overload. We've seen in ND that a cache that's not Pascal> dimensioned appropriately (too small) just causes permanent Pascal> look ups that multiply the traffic in the network, loss and Pascal> latency. Pascal> In classical mesh networking, what you do when the network Pascal> gets fully busy is that you add another root. Capacity Pascal> management becomes a deployment issue. Usually what we Pascal> address there is the bandwidth capacity on the root radio Pascal> space. In this thread, the problem is a bit different and Pascal> the routing table overload might occur one or more hops away Pascal> from the root. Still, the solution to increase capacity Pascal> needs is probably divide and conquer, and nothing will Pascal> replace a proper capacity planning overall. Pascal> RPL enables DAGs that are made of multiple DODAGs. RPL Pascal> enables the radio roots to be connected to a backbone, with Pascal> a super-root there if you want a single DODAG. RPL Pascal> dynamically adapts to the addition or the removal of a root Pascal> in an instance so adapting the capacity to new requirements Pascal> has only a local impact on the network. It also adapts Pascal> dynamically to the addition of a parent in the DODAG to Pascal> share the load close to the root. So we can do divide and Pascal> conquer dynamically. Pascal> If there are enough parents and still one parent is Pascal> overloaded somewhere, then we might have an issue with the Pascal> parent selection. At the moment, a parent cannot indicate Pascal> the capacity of its routing table, so a node might attach to Pascal> parent that has no room for it. Also, one of the reasons for Pascal> a DAO ack is for a parent to reject a DAO for lack of Pascal> capacity. Pascal> If there are enough roots and still one DODAG is overloaded Pascal> somewhere, then we might have an issue with the DODAG Pascal> selection. We need is to push nodes on the ridge between Pascal> DADOGs to jump onto the other DODAG in order to balance the Pascal> load between DODAGs. To do that, we need a pushback Pascal> mechanism from the nodes where the capacity is reached to Pascal> the nodes on the ridge that can jump elsewhere. Pascal> I'm not saying that this is easy, but I think it can be Pascal> done. Pascal> Pascal >> -----Original Message----- From: roll-bounces@ietf.org >> [mailto:roll-bounces@ietf.org] On Behalf Pascal> Of >> Philip Levis Sent: Tuesday, March 30, 2010 4:27 AM To: Michael >> Richardson Cc: 'roll' Subject: Re: [Roll] Mixed mode operation >> >> >> On Mar 29, 2010, at 6:26 PM, Michael Richardson wrote: >> >> > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 >> > >> > >> >>>>>> "Don" == Don Sturek writes: > Don> It >> would make sense to recommend to vendors they implement Pascal> 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" Pascal> is >> > that it does not provide this. >> > >> > 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 Pascal> 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 Pascal> attacker >> > just installed a high-gain antenna in one part of the building, >> a Pascal> 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 came up in Anaheim; one approach to defending from this is Pascal> requiring a >> node to respond to a nonce before handling its packets (e.g., Pascal> inserting a >> routing table entry). There are of course timeliness issues, etc. >> >> Phil >> >> _______________________________________________ Roll mailing list >> Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From pthubert@cisco.com Tue Mar 30 07:47: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 1C08B3A6C0C for ; Tue, 30 Mar 2010 07:47:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.757 X-Spam-Level: X-Spam-Status: No, score=-6.757 tagged_above=-999 required=5 tests=[AWL=1.290, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, HTML_MESSAGE=0.001, NORMAL_HTTP_TO_IP=0.001, RCVD_IN_DNSWL_HI=-8, SARE_GIF_ATTACH=1.42] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fuZ4hq2z8ZTV for ; Tue, 30 Mar 2010 07:46:59 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id F0F6C3A6BE8 for ; Tue, 30 Mar 2010 07:41:04 -0700 (PDT) Authentication-Results: sj-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-Files: ATT2045215.txt : 127 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkcFACSqsUurR7Hu/2dsb2JhbACBP4FTlz4gP3GmQ4g+gl4BjXwChBRqBA X-IronPort-AV: E=Sophos;i="4.51,334,1267401600"; d="gif'147?txt'147?png'147,150?scan'147,150,208,217,147,150"; a="312838080" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-1.cisco.com with ESMTP; 30 Mar 2010 14:41:34 +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 o2UEfJMQ013418 for ; Tue, 30 Mar 2010 14:41:34 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, 30 Mar 2010 16:41:10 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01CAD017.09F084AA" Date: Tue, 30 Mar 2010 16:41:06 +0200 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D0192337A@XMB-AMS-107.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Consensus call on Issue #17 Thread-Index: AcrQFwZ630Ll+TewR3emngcAicQbmA== From: "Pascal Thubert (pthubert)" To: "roll" X-OriginalArrivalTime: 30 Mar 2010 14:41:10.0412 (UTC) FILETIME=[0A00A4C0:01CAD017] Subject: [Roll] Consensus call on Issue #17 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 30 Mar 2010 14:47:01 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CAD017.09F084AA Content-Type: multipart/related; type="multipart/alternative"; boundary="----_=_NextPart_002_01CAD017.09F084AA" ------_=_NextPart_002_01CAD017.09F084AA Content-Type: multipart/alternative; boundary="----_=_NextPart_003_01CAD017.09F084AA" ------_=_NextPart_003_01CAD017.09F084AA Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 SGk6DQoNCiANCg0KVGhpcyBpcyBhIGNhbGwgb24gY2xvc2luZyBpc3N1ZSAjMTcuIA0KDQpUaWNr ZXQgVVJMOiBodHRwOi8vNjQuMTcwLjk4LjQyL3dnL3JvbGwvdHJhYy90aWNrZXQvMTcgIA0KDQog DQoNCkFzIEkgaW5kaWNhdGVkIGluIHRoZSBhdHRhY2hlZCBtYWlsLCAjMTcgd2FzIHByb2Nlc3Nl ZCBhbmQgdGhlIHJlc3VsdCBhcHBlYXJlZCB0b28gY29tcGxleCAvIHRvbyAgbXVjaCBleHBlcmlt ZW50YWwuIFNvIHdlIHB1bGxlZCBpc3N1ZSAjMjYNCg0KIA0KDQpJIGdvdCBubyBjb250cmFkaWN0 aW9uIHNpbmNlIEkgcG9zdGVkIHNvIEkgdGhpbmsgd2UgY2FuIG5vdyBjbG9zZSAjMTcuIElmIGFu eW9uZSBkaXNhZ3JlZSB0aGF0IHdlIGNhbiBkbyBzbyBhbmQgcHVyc3VlIHdpdGggMjYgcGxlYXNl IGxldCB1cyBrbm93IG5vdyENCg0KIA0KDQpDaGVlcnMsDQoNCiANCg0KUGFzY2FsDQoNCiANCg0K RnJvbTogcm9sbC1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86cm9sbC1ib3VuY2VzQGlldGYub3Jn XSBPbiBCZWhhbGYgT2YgUGFzY2FsIFRodWJlcnQgKHB0aHViZXJ0KQ0KU2VudDogTW9uZGF5LCBN YXJjaCAxNSwgMjAxMCAyOjI5IFBNDQpUbzogcm9sbEBpZXRmLm9yZw0KU3ViamVjdDogW1JvbGxd IElzc3VlICMxNw0KDQogDQoNCldHOg0KDQogDQoNClRpY2tldCAxNyBzYXlzOg0KDQrigJwNCg0K UlBMIGFsbG93cyBzb3VyY2Ugcm91dGluZyBkb3duIHRoZSBEQUcuIFR5cGljYWxseSwgdGhlIHNv dXJjZSB3aWxsIGJlIHRoZSByb290LCBhbmQgdGhlIGRlc3RpbmF0aW9uIGEgbm9kZSBzb21ld2hl cmUgZG93bi4gVGhlIHNvdXJjZSByb3V0ZSBwYXRoIG1pZ2h0IGJlIHN0cmljdCBvciBsb29zZSwg ZGVwZW5kaW5nIG9uIHdoZXRoZXIgaW50ZXJtZWRpYXRlIG5vZGVzIGNhbiBhY3R1YWxseSBzdG9y ZSBzdGF0ZXMuIA0KDQphKSBXZSBjYW4gY2hvb3NlIGJldHdlZW4gMiBtb2RlbHM6IGtlZXAgaW50 ZXJtZWRpYXRlIFNSUCBpbiB0aGUgbm9kZXMgZG93biB0aGUgREFHIG9yIG9ubHkgZG8gTFNSUiBm cm9tIHRoZSByb290IA0KDQpiKSBBIHNvdXJjZSByb3V0ZSBwYXRoIG11c3QgYmUgcmVjb21wdXRl ZCBmcm9tIHRoZSBkZXN0aW5hdGlvbiB1cCB3aGVuIHRoZSBwYXRoIGJldHdlZW4gdGhlIHNvdXJj ZSBhbmQgdGhlIGRlc3RpbmF0aW9uIGNoYW5nZXMuIEJ1dCB0aGVyZSBpcyBubyB3YXkgZm9yIHRo ZSBkZXN0aW5hdGlvbiB0byBrbm93IHRoYXQuIFRoYXQgaXMgd2hhdCB0aGUgZGlnZXN0IHdhcyBm b3IgDQoNCuKAnA0KDQogDQoNCkZvciBiKSBXZSBoYXZlIGludHJvZHVjZWQgdGhlIERUU04gdG8g cmVwbGFjZSB0aGUgZGlnZXN0LiANCg0KIA0KDQpGb3IgYSkgdGhlIGN1cnJlbnQgc3BlYyBwaWNr ZWQgdGhlIGZpcnN0IG1vZGVsLiBXZSBhcmUgb2JzZXJ2aW5nIGEgbGlnaHQgY29uc2Vuc3VzIHRo YXQgdGhpcyBwYXRoIGxlYWQgdG9vIGZhci4gVGh1cyBpc3N1ZSAjMjYgYWJvdXQgc3RvcmluZyAv IG5vbi1zdG9yaW5nIC8gbWl4ZWQgY2FjaGluZyBub2Rlcy4gU28gbXkgdGFrZSBpcyB0aGF0IHRo aXMgcGFydCBvZiB0aWNrZXQgIzE3IGlzIG5vdyBpcnJlbGV2YW50LCB0byBiZSBmb2xsb3dlZCBv biB3aXRoICMyNi4gVG8gbWVyZ2UgdGhlIDIsIHdlIG5lZWQgdG8gY29uc2lkZXIgTFNSUiBhcyBh biBhbHRlcm5hdGUgaW4gIzI2Lg0KDQogDQoNCkZvciBhbGwgSSBrbm93LCBJIHRoaW5rIHRoYXQg d2UgY2FuIGNsb3NlICMxNywgYXQgbGVhc3QgaWYgd2UgaW5jbHVkZSB0aGUgTFNSUiBvcHRpb24g aW4gIzI2LiANCg0KIA0KDQpXaGF0IGRvIHlvdSB0aGluaz8NCg0KIA0KDQogDQoNCgkNClBhc2Nh bCBUaHViZXJ0DQpFbmdpbmVlci5zb2Z0d2FyZSBFbmdpbmVlcmluZw0KUHJvZHVjdCBEZXZlbG9w bWVudA0KcHRodWJlcnRAY2lzY28uY29tIDxtYWlsdG86cHRodWJlcnRAY2lzY28uY29tPiANClBo b25lOiArMzMgNCA5NzIzIDI2MzQNCk1vYmlsZTogKzMzIDYgMTk5OCAyOTg1DQoNCkNpc2NvIFN5 c3RlbXMgRnJhbmNlDQpWaWxsYWdlIGQnRW50cmVwcmlzZXMgR3JlZW4gU2lkZQ0KNDAwIEF2ZW51 ZSBkZSBSb3VtYW5pbGxlIA0KQmF0aW1lbnQgVCAzIA0KMDY0MTAgDQpCSU9UIC0gU09QSElBIEFO VElQT0xJUw0KRnJhbmNlDQpDaXNjby5jb20gPGh0dHA6Ly93d3cuY2lzY28uY29tL2dsb2JhbC9G Ui8+IA0KDQogDQoNCiANCg0KVGhpbmsgYmVmb3JlIHlvdSBwcmludC4NCg0KQ2lzY28gU3lzdGVt cyBGcmFuY2UsIFNvY2nDqXTDqSDDoCByZXNwb25zYWJpaXTDqSBsaW1pdMOpZSwgUnVlIENhbWls bGUgRGVzbW91bGlucyDigJMgSW1tIEF0bGFudGlzIFphYyBGb3J1bSBTZWluZSBJbG90IDcgOTIx MzAgSXNzeSBsZXMgTW91bGluZWF1eCwgQXUgY2FwaXRhbCBkZSA5MS40NzAg4oKsLCAzNDkgMTY2 IDU2MSBSQ1MgTmFudGVycmUsIERpcmVjdGV1ciBkZSBsYSBwdWJsaWNhdGlvbjogSmVhbi1MdWMg TWljaGVsIEdpdm9uZSwgRm9yIGNvcnBvcmF0ZSBsZWdhbCBpbmZvcm1hdGlvbiBnbyB0bzoNCmh0 dHA6Ly93d3cuY2lzY28uY29tL3dlYi9hYm91dC9kb2luZ19idXNpbmVzcy9sZWdhbC9jcmkvaW5k ZXguaHRtbA0KDQogDQoNCiANCg0K ------_=_NextPart_003_01CAD017.09F084AA Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij48bWV0YSBuYW1lPUdlbmVyYXRvciBjb250ZW50 PSJNaWNyb3NvZnQgV29yZCAxNCAoZmlsdGVyZWQgbWVkaXVtKSI+PCEtLVtpZiAhbXNvXT48c3R5 bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7YmVoYXZpb3I6dXJs KCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0KLnNo YXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwhW2VuZGlmXS0tPjxz dHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFt aWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7 fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRp di5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9u dC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO30NCmE6 bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9y OmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNv SHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBs ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAuTXNvUGxhaW5UZXh0LCBsaS5Nc29Q bGFpblRleHQsIGRpdi5Nc29QbGFpblRleHQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1z by1zdHlsZS1saW5rOiJUZXh0ZSBicnV0IENhciI7DQoJbWFyZ2luOjBjbTsNCgltYXJnaW4tYm90 dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIs InNhbnMtc2VyaWYiO30NCnAuTXNvQWNldGF0ZSwgbGkuTXNvQWNldGF0ZSwgZGl2Lk1zb0FjZXRh dGUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJUZXh0ZSBkZSBi dWxsZXMgQ2FyIjsNCgltYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250 LXNpemU6OC4wcHQ7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiO30NCnNwYW4u VGV4dGVkZWJ1bGxlc0Nhcg0KCXttc28tc3R5bGUtbmFtZToiVGV4dGUgZGUgYnVsbGVzIENhciI7 DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJUZXh0ZSBkZSBidWxs ZXMiOw0KCWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9DQpzcGFuLkVtYWlsU3R5 bGUxOQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIs InNhbnMtc2VyaWYiOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjANCgl7 bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJz YW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4uVGV4dGVicnV0Q2FyDQoJe21zby1z dHlsZS1uYW1lOiJUZXh0ZSBicnV0IENhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1z by1zdHlsZS1saW5rOiJUZXh0ZSBicnV0IjsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMt c2VyaWYiO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0K CWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3 OTIuMHB0Ow0KCW1hcmdpbjo3MC44NXB0IDcwLjg1cHQgNzAuODVwdCA3MC44NXB0O30NCmRpdi5X b3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0 ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEw MjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNo YXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAv Pg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPjwvaGVhZD48Ym9keSBsYW5nPUVO LVVTIGxpbms9Ymx1ZSB2bGluaz1wdXJwbGU+PGRpdiBjbGFzcz1Xb3JkU2VjdGlvbjE+PHAgY2xh c3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xvcjojMUY0OTdEJz5IaTo8bzpwPjwvbzpwPjwv c3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xvcjojMUY0OTdEJz48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvUGxhaW5UZXh0PjxzcGFuIHN0 eWxlPSdjb2xvcjojMUY0OTdEJz5UaGlzIGlzIGEgY2FsbCBvbiBjbG9zaW5nIGlzc3VlICMxNy4g PG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb1BsYWluVGV4dD5UaWNrZXQgVVJMOiA8 YSBocmVmPSJodHRwOi8vNjQuMTcwLjk4LjQyL3dnL3JvbGwvdHJhYy90aWNrZXQvMTciPmh0dHA6 Ly82NC4xNzAuOTguNDIvd2cvcm9sbC90cmFjL3RpY2tldC8xNzwvYT4gwqA8bzpwPjwvbzpwPjwv cD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9y OiMxRjQ5N0QnPkFzIEkgaW5kaWNhdGVkIGluIHRoZSBhdHRhY2hlZCBtYWlsLCAjMTcgd2FzIHBy b2Nlc3NlZCBhbmQgdGhlIHJlc3VsdCBhcHBlYXJlZCB0b28gY29tcGxleCAvIHRvb8KgIG11Y2gg ZXhwZXJpbWVudGFsLiBTbyB3ZSBwdWxsZWQgaXNzdWUgIzI2PG86cD48L286cD48L3NwYW4+PC9w PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6IzFGNDk3RCc+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6 IzFGNDk3RCc+SSBnb3Qgbm8gY29udHJhZGljdGlvbiBzaW5jZSBJIHBvc3RlZCBzbyBJIHRoaW5r IHdlIGNhbiBub3cgY2xvc2UgIzE3LiBJZiBhbnlvbmUgZGlzYWdyZWUgdGhhdCB3ZSBjYW4gZG8g c28gYW5kIHB1cnN1ZSB3aXRoIDI2IHBsZWFzZSBsZXQgdXMga25vdyBub3chPG86cD48L286cD48 L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6IzFGNDk3RCc+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHls ZT0nY29sb3I6IzFGNDk3RCc+Q2hlZXJzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1N c29Ob3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6IzFGNDk3 RCc+UGFzY2FsPG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48 c3BhbiBzdHlsZT0nY29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxk aXY+PGRpdiBzdHlsZT0nYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0 O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20nPjxwIGNsYXNzPU1zb05vcm1hbD48Yj48c3BhbiBz dHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiIn PkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eToiVGFob21hIiwic2Fucy1zZXJpZiInPiByb2xsLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpy b2xsLWJvdW5jZXNAaWV0Zi5vcmddIDxiPk9uIEJlaGFsZiBPZiA8L2I+UGFzY2FsIFRodTwvc3Bh bj48c3BhbiBsYW5nPUZSIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJUYWhv bWEiLCJzYW5zLXNlcmlmIic+YmVydCAocHRodWJlcnQpPGJyPjxiPlNlbnQ6PC9iPiBNb25kYXks IE1hcmNoIDE1LCAyMDEwIDI6MjkgUE08YnI+PGI+VG86PC9iPiByb2xsQGlldGYub3JnPGJyPjxi PlN1YmplY3Q6PC9iPiBbUm9sbF0gSXNzdWUgIzE3PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2 PjwvZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48bzpwPiZuYnNwOzwvbzpwPjwvcD48cCBjbGFzcz1N c29Ob3JtYWw+V0c6PG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD5UaWNrZXQgMTcgc2F5czo8bzpwPjwvbzpwPjwv cD48cCBjbGFzcz1Nc29Ob3JtYWw+4oCcPG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvTm9ybWFs PlJQTCBhbGxvd3Mgc291cmNlIHJvdXRpbmcgZG93biB0aGUgREFHLiBUeXBpY2FsbHksIHRoZSBz b3VyY2Ugd2lsbCBiZSB0aGUgcm9vdCwgYW5kIHRoZSBkZXN0aW5hdGlvbiBhIG5vZGUgc29tZXdo ZXJlIGRvd24uIFRoZSBzb3VyY2Ugcm91dGUgcGF0aCBtaWdodCBiZSBzdHJpY3Qgb3IgbG9vc2Us IGRlcGVuZGluZyBvbiB3aGV0aGVyIGludGVybWVkaWF0ZSBub2RlcyBjYW4gYWN0dWFsbHkgc3Rv cmUgc3RhdGVzLiA8bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+YSkgV2UgY2FuIGNo b29zZSBiZXR3ZWVuIDIgbW9kZWxzOiBrZWVwIGludGVybWVkaWF0ZSBTUlAgaW4gdGhlIG5vZGVz IGRvd24gdGhlIERBRyBvciBvbmx5IGRvIExTUlIgZnJvbSB0aGUgcm9vdCA8bzpwPjwvbzpwPjwv cD48cCBjbGFzcz1Nc29Ob3JtYWw+YikgQSBzb3VyY2Ugcm91dGUgcGF0aCBtdXN0IGJlIHJlY29t cHV0ZWQgZnJvbSB0aGUgZGVzdGluYXRpb24gdXAgd2hlbiB0aGUgcGF0aCBiZXR3ZWVuIHRoZSBz b3VyY2UgYW5kIHRoZSBkZXN0aW5hdGlvbiBjaGFuZ2VzLiBCdXQgdGhlcmUgaXMgbm8gd2F5IGZv ciB0aGUgZGVzdGluYXRpb24gdG8ga25vdyB0aGF0LiBUaGF0IGlzIHdoYXQgdGhlIGRpZ2VzdCB3 YXMgZm9yIDxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD7igJw8bzpwPjwvbzpwPjwv cD48cCBjbGFzcz1Nc29Ob3JtYWw+PG86cD4mbmJzcDs8L286cD48L3A+PHAgY2xhc3M9TXNvTm9y bWFsPkZvciBiKSBXZSBoYXZlIGludHJvZHVjZWQgdGhlIERUU04gdG8gcmVwbGFjZSB0aGUgZGln ZXN0LiA8bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PG86cD4mbmJzcDs8L286cD48 L3A+PHAgY2xhc3M9TXNvTm9ybWFsPkZvciBhKSB0aGUgY3VycmVudCBzcGVjIHBpY2tlZCB0aGUg Zmlyc3QgbW9kZWwuIFdlIGFyZSBvYnNlcnZpbmcgYSBsaWdodCBjb25zZW5zdXMgdGhhdCB0aGlz IHBhdGggbGVhZCB0b28gZmFyLiBUaHVzIGlzc3VlICMyNiBhYm91dCBzdG9yaW5nIC8gbm9uLXN0 b3JpbmcgLyBtaXhlZCBjYWNoaW5nIG5vZGVzLiBTbyBteSB0YWtlIGlzIHRoYXQgdGhpcyBwYXJ0 IG9mIHRpY2tldCAjMTcgaXMgbm93IGlycmVsZXZhbnQsIHRvIGJlIGZvbGxvd2VkIG9uIHdpdGgg IzI2LiBUbyBtZXJnZSB0aGUgMiwgd2UgbmVlZCB0byBjb25zaWRlciBMU1JSIGFzIGFuIGFsdGVy bmF0ZSBpbiAjMjYuPG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD5Gb3IgYWxsIEkga25vdywgSSB0aGluayB0aGF0 IHdlIGNhbiBjbG9zZSAjMTcsIGF0IGxlYXN0IGlmIHdlIGluY2x1ZGUgdGhlIExTUlIgb3B0aW9u IGluICMyNi4gPG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD5XaGF0IGRvIHlvdSB0aGluaz88bzpwPjwvbzpwPjwv cD48cCBjbGFzcz1Nc29Ob3JtYWw+PG86cD4mbmJzcDs8L286cD48L3A+PHAgY2xhc3M9TXNvTm9y bWFsPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPjx0YWJsZSBjbGFzcz1Nc29Ob3JtYWxUYWJsZSBib3Jk ZXI9MCBjZWxsc3BhY2luZz0wIGNlbGxwYWRkaW5nPTAgd2lkdGg9NTQzIHN0eWxlPSd3aWR0aDo0 MDcuMjVwdCc+PHRyPjx0ZCBzdHlsZT0ncGFkZGluZzowY20gMGNtIDBjbSAwY20nPjx0YWJsZSBj bGFzcz1Nc29Ob3JtYWxUYWJsZSBib3JkZXI9MCBjZWxsc3BhY2luZz0wIGNlbGxwYWRkaW5nPTAg d2lkdGg9NjAwIHN0eWxlPSd3aWR0aDo0NTAuMDVwdCc+PHRyPjx0ZCBjb2xzcGFuPTMgc3R5bGU9 J3BhZGRpbmc6MGNtIDBjbSAwY20gMGNtJz48L3RkPjwvdHI+PHRyIHN0eWxlPSdoZWlnaHQ6OTQu MDVwdCc+PHRkIG5vd3JhcCB2YWxpZ249dG9wIHN0eWxlPSdwYWRkaW5nOjBjbSAwY20gMTEuMjVw dCAxOC4wcHQ7aGVpZ2h0Ojk0LjA1cHQnPjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bWFyZ2luLWJvdHRvbToxMi4wcHQnPjxiPjxzcGFuIHN0eWxlPSdm b250LXNpemU6OC41cHQ7Zm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiI7Y29sb3I6IzY2 NjY2Njttc28tZmFyZWFzdC1sYW5ndWFnZTpGUic+UGFzY2FsIFRodWJlcnQ8L3NwYW4+PC9iPjxz cGFuIHN0eWxlPSdmb250LXNpemU6OC41cHQ7Zm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJp ZiI7Y29sb3I6IzY2NjY2Njttc28tZmFyZWFzdC1sYW5ndWFnZTpGUic+PGJyPjxiPkVuZ2luZWVy LnNvZnR3YXJlIEVuZ2luZWVyaW5nPC9iPjxicj48Yj5Qcm9kdWN0IERldmVsb3BtZW50PC9iPjxi cj48YSBocmVmPSJtYWlsdG86cHRodWJlcnRAY2lzY28uY29tIj48c3BhbiBzdHlsZT0nY29sb3I6 IzY2NjY2Nic+cHRodWJlcnRAY2lzY28uY29tPC9zcGFuPjwvYT48YnI+UGhvbmU6IDxiPiszMyA0 IDk3MjMgMjYzNDwvYj48YnI+TW9iaWxlOiA8Yj4rMzMgNiAxOTk4IDI5ODU8L2I+PG86cD48L286 cD48L3NwYW4+PC9wPjwvdGQ+PHRkIG5vd3JhcCB2YWxpZ249dG9wIHN0eWxlPSdwYWRkaW5nOjBj bSAwY20gNy41cHQgMTUuMHB0O2hlaWdodDo5NC4wNXB0Jz48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5 bGU9J21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21hcmdpbi1ib3R0b206MTIuMHB0Jz48Yj48c3Bh biBzdHlsZT0nZm9udC1zaXplOjguNXB0O2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYi O2NvbG9yOiM2NjY2NjY7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RlInPkNpc2NvIFN5c3RlbXMgRnJh bmNlPC9zcGFuPjwvYj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjguNXB0O2ZvbnQtZmFtaWx5OiJB cmlhbCIsInNhbnMtc2VyaWYiO2NvbG9yOiM2NjY2NjY7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RlIn Pjxicj5WaWxsYWdlIGQnRW50cmVwcmlzZXMgR3JlZW4gU2lkZTxicj40MDAgQXZlbnVlIGRlIFJv dW1hbmlsbGUgPGJyPkJhdGltZW50IFQgMyA8YnI+MDY0MTAgPGJyPkJJT1QgLSBTT1BISUEgQU5U SVBPTElTPGJyPkZyYW5jZTxicj48YSBocmVmPSJodHRwOi8vd3d3LmNpc2NvLmNvbS9nbG9iYWwv RlIvIj48c3BhbiBzdHlsZT0nY29sb3I6IzY2NjY2Nic+Q2lzY28uY29tPC9zcGFuPjwvYT48bzpw PjwvbzpwPjwvc3Bhbj48L3A+PC90ZD48dGQgd2lkdGg9MTg2IHN0eWxlPSd3aWR0aDoxMzkuNzVw dDtwYWRkaW5nOjBjbSAwY20gMGNtIDBjbTtoZWlnaHQ6OTQuMDVwdCc+PHAgY2xhc3M9TXNvTm9y bWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiJUaW1lcyBOZXcg Um9tYW4iLCJzZXJpZiI7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RlInPiZuYnNwOzxpbWcgYm9yZGVy PTAgd2lkdGg9MTY0IGhlaWdodD0xMDggaWQ9IkltYWdlX3gwMDIwXzEiIHNyYz0iY2lkOmltYWdl MDA0LnBuZ0AwMUNBQzQ0Qi5DQUVFRjY1MCI+PG86cD48L286cD48L3NwYW4+PC9wPjwvdGQ+PC90 cj48L3RhYmxlPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEyLjBw dDtmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO2Rpc3BsYXk6bm9uZTttc28t ZmFyZWFzdC1sYW5ndWFnZTpGUic+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjx0YWJsZSBj bGFzcz1Nc29Ob3JtYWxUYWJsZSBib3JkZXI9MCBjZWxsc3BhY2luZz0wIGNlbGxwYWRkaW5nPTAg d2lkdGg9NzE5IHN0eWxlPSd3aWR0aDo1MzkuMTVwdCc+PHRyIHN0eWxlPSdoZWlnaHQ6OTAuOHB0 Jz48dGQgd2lkdGg9NzE5IHN0eWxlPSd3aWR0aDo1MzkuMTVwdDtwYWRkaW5nOjBjbSAxOC4wcHQg MGNtIDE4LjBwdDtoZWlnaHQ6OTAuOHB0Jz48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9 J2ZvbnQtc2l6ZTo3LjVwdDtmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIjtjb2xvcjoj MDA5OTAwO21zby1mYXJlYXN0LWxhbmd1YWdlOkZSJz48aW1nIGJvcmRlcj0wIHdpZHRoPTE4IGhl aWdodD0xOSBpZD0iSW1hZ2VfeDAwMjBfMiIgc3JjPSJjaWQ6aW1hZ2UwMDMuZ2lmQDAxQ0FDNDQ5 LjhDMjZDQzEwIiBhbHQ9IlRoaW5rIGJlZm9yZSB5b3UgcHJpbnQuIj5UaGluayBiZWZvcmUgeW91 IHByaW50Ljxicj48YnI+PC9zcGFuPjxzcGFuIHN0eWxlPSdmb250LXNpemU6Ny41cHQ7Zm9udC1m YW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiI7Y29sb3I6Izk5OTk5OTttc28tZmFyZWFzdC1sYW5n dWFnZTpGUic+Q2lzY28gU3lzdGVtcyBGcmFuY2UsIFNvY2nDqXTDqSDDoCByZXNwb25zYWJpaXTD qSBsaW1pdMOpZSwgUnVlIENhbWlsbGUgRGVzbW91bGlucyDigJMgSW1tIEF0bGFudGlzIFphYyBG b3J1bSBTZWluZSBJbG90IDcgOTIxMzAgSXNzeSBsZXMgTW91bGluZWF1eCwgQXUgY2FwaXRhbCBk ZSA5MS40NzAg4oKsLCAzNDkgMTY2IDU2MSBSQ1MgTmFudGVycmUsIERpcmVjdGV1ciBkZSBsYSBw dWJsaWNhdGlvbjogSmVhbi1MdWMgTWljaGVsIEdpdm9uZSwgRm9yIGNvcnBvcmF0ZSBsZWdhbCBp bmZvcm1hdGlvbiBnbyB0bzo8YnI+PGEgaHJlZj0iaHR0cDovL3d3dy5jaXNjby5jb20vd2ViL2Fi b3V0L2RvaW5nX2J1c2luZXNzL2xlZ2FsL2NyaS9pbmRleC5odG1sIj5odHRwOi8vd3d3LmNpc2Nv LmNvbS93ZWIvYWJvdXQvZG9pbmdfYnVzaW5lc3MvbGVnYWwvY3JpL2luZGV4Lmh0bWw8L2E+PC9z cGFuPjxzcGFuIHN0eWxlPSdmb250LXNpemU6Ny41cHQ7Zm9udC1mYW1pbHk6IkFyaWFsIiwic2Fu cy1zZXJpZiI7Y29sb3I6IzAwOTkwMDttc28tZmFyZWFzdC1sYW5ndWFnZTpGUic+PG86cD48L286 cD48L3NwYW4+PC9wPjwvdGQ+PC90cj48L3RhYmxlPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBz dHlsZT0nbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RlInPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L3Rk PjwvdHI+PC90YWJsZT48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gbGFuZz1GUiBzdHlsZT0nbXNv LWZhcmVhc3QtbGFuZ3VhZ2U6RlInPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFz cz1Nc29Ob3JtYWw+PHNwYW4gbGFuZz1GUj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PC9k aXY+PC9ib2R5PjwvaHRtbD4= ------_=_NextPart_003_01CAD017.09F084AA-- ------_=_NextPart_002_01CAD017.09F084AA Content-Type: image/png; name="image004.png" Content-Transfer-Encoding: base64 Content-ID: Content-Description: image004.png Content-Location: image004.png 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_002_01CAD017.09F084AA Content-Type: image/gif; name="image003.gif" Content-Transfer-Encoding: base64 Content-ID: Content-Description: image003.gif Content-Location: image003.gif R0lGODlhEgATAJEAAAAAAP///wCZAP///yH5BAEAAAMALAAAAAASABMAAAIojI+pGyK8nINqUiTf bVnfvHEg1UmhdZRqaawu6XZVjKb0/CYxo8JOAQA7 ------_=_NextPart_002_01CAD017.09F084AA-- ------_=_NextPart_001_01CAD017.09F084AA Content-Type: text/plain; name="ATT2045215.txt" Content-Transfer-Encoding: base64 Content-Description: ATT2045215.txt Content-Disposition: inline; filename="ATT2045215.txt" X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NClJvbGwgbWFp bGluZyBsaXN0DQpSb2xsQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL3JvbGwNCg== ------_=_NextPart_001_01CAD017.09F084AA-- From pthubert@cisco.com Tue Mar 30 07:57: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 DA3B23A6A58 for ; Tue, 30 Mar 2010 07:57:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.96 X-Spam-Level: X-Spam-Status: No, score=-2.96 tagged_above=-999 required=5 tests=[AWL=-2.691, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, J_CHICKENPOX_54=0.6, J_CHICKENPOX_73=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 W-HUjKIB5KLo for ; Tue, 30 Mar 2010 07:57:13 -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 DB3F43A6890 for ; Tue, 30 Mar 2010 07:57:12 -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: Aj0CAFuusUuQ/uCWe2dsb2JhbACbLxUBAQsLIgYcpm6ZG4UABA X-IronPort-AV: E=Sophos;i="4.51,334,1267401600"; d="scan'208";a="4979340" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-2.cisco.com with ESMTP; 30 Mar 2010 14:22:58 +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 o2UEvfmT026106; Tue, 30 Mar 2010 14:57:41 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); Tue, 30 Mar 2010 16:57: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: Tue, 30 Mar 2010 16:57:38 +0200 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D019233A0@XMB-AMS-107.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Target in DIO [was Clarification request about RPL] Thread-Index: AcrQFzDgbp9CnholTGODvZn2IDB84g== From: "Pascal Thubert (pthubert)" To: , X-OriginalArrivalTime: 30 Mar 2010 14:57:41.0193 (UTC) FILETIME=[588DD390:01CAD019] Subject: [Roll] Target in DIO [was Clarification request about RPL] X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Mar 2010 14:57:16 -0000 Hi Mathieu You'll note that all nodes do not have to send DAOs. Only destinations (nodes|prefixes|mcast) that need to be reachable do.=20 During this IETF, there were a number of corridor discussions asking the same question. Basically we have this node sitting there in the RPL network and for a number of reasons, this node is not reachable by some other party in the network.=20 Reasons can be: - this node is a deep sleeper leaf, does not want to spend everybody's energy when it does not expect to be reached (your case) - RPL inconsistency, the route to the node is temporary lost - another node wants to start a P2P conversation with this node In all those cases, it appears that the capability to indicate one or more targets in a DIO is a useful thing.=20 Is that what you are asking for? Pascal > -----Original Message----- > From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of > Mathieu Pouillot > Sent: Tuesday, March 30, 2010 11:03 AM > To: roll@ietf.org > Subject: [Roll] Clarification request about RPL >=20 > Hi all, >=20 > Watteco is implementing a RPL (draft-05 for the moment) on PLC nodes in a > low power and low data rate context. After some tests, we have some > interogations: >=20 > - The DAO request generates a lot of traffic on the network, and most of the > time it is not necessary to have the downward routes of all devices. > Is there a mechanism to ask a DAO to specified devices? If not, what do you > think to add a sub-option in the DIO to ask DAO to a specified device or > maybe(more complex) a group of devices? > - A point that is not very clear: Can the same node belong to several DoDag of > the same instance? If yes, how the data traffic(UDP,TCP, or > others) knows which route has to be used? By the way, when you are in > different instance how the flow label has to be filled? > - Is there a way to broadcast or multicast some data traffic in all our DoDag? > - Is there a mechanism to annonce a broken route during data traffic? >=20 > Thanks for the clarifications, >=20 > best regards, >=20 > Mathieu >=20 > -- > Mathieu Pouillot > R&D Engineer > m.pouillot@watteco.com >=20 > Tel : +33(0)4 98 01 60 05 (Poste 43) > Fax : +33(0)4 94 14 10 80 > 1766 Chemin de la Planquette > 83130 LA GARDE - France > www.watteco.com >=20 > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From tzeta.tsao@ekasystems.com Tue Mar 30 08:37: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 9AF7A3A68C7 for ; Tue, 30 Mar 2010 08:37:04 -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 YFfQoqytSgrS for ; Tue, 30 Mar 2010 08:37:04 -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 CF4593A67A5 for ; Tue, 30 Mar 2010 08:37:03 -0700 (PDT) Received: (qmail 64510 invoked from network); 30 Mar 2010 15:37:30 -0000 Received: from [192.168.0.182] (tzeta.tsao@209.48.242.70 with plain) by smtp114.biz.mail.re2.yahoo.com with SMTP; 30 Mar 2010 08:37:30 -0700 PDT X-Yahoo-SMTP: oSTnanOswBB7CsQprEGEdQm86hOa9bg- X-YMail-OSG: BlYFvWsVM1k8_bGS2hsx45eIXkxs0f7U.1LP15TVu1n2uLvYUufQr1nXR0_8Hhs5CT4Bhgy7XaZhkQyUDJnpWLQPA0O6OYfFQOostYfTupeDGd2sDQLe1sRlmKOZa3AC49HFuLoBasF.1U5vmYhQItn4lcyLSRis2POHUMjq4aanpZJJ7kN4JX5Z10paiPxX6baO8zDe9_8nRJjVpzgO6BR2EERZ7lUj5taGxigVomLmn4KWvD3GKzLD96wGeki7nkrWwSOVcLkHhARDv04al7DcSuneT2wKnKiprX5MtQL5_e2Hu62mAhDG2bjeQS9Iqw5vcDXUgnrtBTnyKRmwi8gNOONQj6WTvlyY3.mPFK89RU3MoQrCgB0jB.vMneWNa0TR X-Yahoo-Newman-Property: ymail-3 Message-ID: <4BB21AA3.50108@ekasystems.com> Date: Tue, 30 Mar 2010 11:37:07 -0400 From: Tzeta Tsao User-Agent: Mozilla-Thunderbird 2.0.0.22 (X11/20090706) MIME-Version: 1.0 To: ROLL WG Content-Type: multipart/mixed; boundary="------------090309090300070609080002" Subject: [Roll] [Fwd: New Version Notification for draft-ietf-roll-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: Tue, 30 Mar 2010 15:37:04 -0000 This is a multi-part message in MIME format. --------------090309090300070609080002 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit WG, We have posted draft-ietf-roll-security-framework-00, which updates the references in draft-tsao-roll-security-framework-02 and should be available from the repository shortly. Please comment. Thanks, Tzeta --------------090309090300070609080002 Content-Type: message/rfc822; name="New Version Notification for draft-ietf-roll-security-framework-00.eml" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename*0="New Version Notification for draft-ietf-roll-securi"; filename*1="ty-framework-00.eml" X-Account-Key: account3 X-Mozilla-Keys: X-Apparently-To: tzeta.tsao@ekasystems.com via 68.142.199.180; Tue, 30 Mar 2010 08:32:27 -0700 X-YMailISG: GWtNjPIWLDst30GfyrGedtaoBx9QBXJxpDcssaA.9otSbHtCWbhK0XfhnYT3vYyrs37nusopBnWhYYioVj1ChFxiK3E2QXs.CsNb6G799O1trJjs.nzOglQh6NGbf2tmrvR6napfxi0Dv.qG5PyqURU02R1.V6607KfNMpFeDyNCJHiEMLOW3qltGKBTKRzD5JRQF1yYhvdYWzhnpZtXKS1GsZyitHg4kmT_HsAoaIdTHmeWPUmRdBQ8PVKrXmuiegMsV2dwM8lC2QAmyW7RmjecpNIoRDfnmJ5BvSC7ngS3gzVnjEV0fMvcuchTUrZ3WRnp1BwmuGCulEXGSxyEpFKkS_hWoNu2FT1TIBIOTivJyO3iywTnlxv78Q.QN_An2n0isKG1Cyp7EPQ- X-Originating-IP: [64.170.98.32] Authentication-Results: mta100.biz.mail.re3.yahoo.com from=ietf.org; domainkeys=neutral (no sig); from=ietf.org; dkim=neutral (no sig) Received: from 64.170.98.32 (EHLO mail.ietf.org) (64.170.98.32) by mta100.biz.mail.re3.yahoo.com with SMTP; Tue, 30 Mar 2010 08:32:24 -0700 Received: by core3.amsl.com (Postfix, from userid 30) id A6D163A6BBB; Tue, 30 Mar 2010 08:31:34 -0700 (PDT) From: IETF I-D Submission Tool To: tzeta.tsao@ekasystems.com Cc: roger.alexander@ekasystems.com,vanesa.daza@upf.edu,angel.lozano@upf.edu Subject: New Version Notification for draft-ietf-roll-security-framework-00 Content-Type: text/plain; charset="utf-8" Mime-Version: 1.0 Message-Id: <20100330153134.A6D163A6BBB@core3.amsl.com> Date: Tue, 30 Mar 2010 08:31:34 -0700 (PDT) A new version of I-D, draft-ietf-roll-security-framework-00.txt has been successfully submitted by Tzeta Tsao and posted to the IETF repository. Filename: draft-ietf-roll-security-framework Revision: 00 Title: A Security Framework for Routing over Low Power and Lossy Networks Creation_date: 2010-03-30 WG ID: roll Number_of_pages: 41 Abstract: This document presents a security framework for routing over low power and lossy networks. The development builds upon previous work on routing security and adapts the assessments to the issues and constraints specific to low power and lossy networks. A systematic approach is used in defining and evaluating the security threats and identifying applicable countermeasures. These assessments provide the basis of the security recommendations for incorporation into low power, lossy network routing protocols. As an illustration, this framework is applied to RPL. The IETF Secretariat. --------------090309090300070609080002-- From root@core3.amsl.com Tue Mar 30 08: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 5CF993A6BEF; Tue, 30 Mar 2010 08:45:02 -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: <20100330154502.5CF993A6BEF@core3.amsl.com> Date: Tue, 30 Mar 2010 08:45:02 -0700 (PDT) Cc: roll@ietf.org Subject: [Roll] I-D Action:draft-ietf-roll-security-framework-00.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Mar 2010 15: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 : A Security Framework for Routing over Low Power and Lossy Networks Author(s) : T. Tsao, et al. Filename : draft-ietf-roll-security-framework-00.txt Pages : 41 Date : 2010-03-30 This document presents a security framework for routing over low power and lossy networks. The development builds upon previous work on routing security and adapts the assessments to the issues and constraints specific to low power and lossy networks. A systematic approach is used in defining and evaluating the security threats and identifying applicable countermeasures. These assessments provide the basis of the security recommendations for incorporation into low power, lossy network routing protocols. As an illustration, this framework is applied to RPL. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-roll-security-framework-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-roll-security-framework-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-03-30083133.I-D@ietf.org> --NextPart-- From pal@cs.stanford.edu Tue Mar 30 10:02: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 04F523A67EC for ; Tue, 30 Mar 2010 10:02:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.169 X-Spam-Level: X-Spam-Status: No, score=-4.169 tagged_above=-999 required=5 tests=[AWL=1.300, 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 8QRfNT-BrTqW for ; Tue, 30 Mar 2010 10:02:44 -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 F327C3A67CF for ; Tue, 30 Mar 2010 10:02:43 -0700 (PDT) Received: from dnab404680.stanford.edu ([171.64.70.128]) by cs-smtp-3.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1NweqP-0003OY-7u; Tue, 30 Mar 2010 10:03:13 -0700 Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Philip Levis In-Reply-To: <6A2A459175DABE4BB11DE2026AA50A5D0188AF9F@XMB-AMS-107.cisco.com> Date: Tue, 30 Mar 2010 10:03:12 -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> <93B6031E-ECE1-4C63-848C-1C43B48F69C8@cs.stanford.edu> <6A2A459175DABE4BB11DE2026AA50A5D0188AF9F@XMB-AMS-107.cisco.com> To: Pascal Thubert (pthubert) X-Mailer: Apple Mail (2.1077) X-Scan-Signature: 3fe17504c5843e76b9e439a63759b02e 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, 30 Mar 2010 17:02:45 -0000 On Mar 29, 2010, at 11:35 PM, Pascal Thubert (pthubert) wrote: > Hi: >=20 > As Phil said the anti-replay came up in Anaheim. This piece is to be > covered in the security analysis. So I think we should only consider = the > saturation of routing tables in this thread. >=20 > 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 > appropriately (too small) just causes permanent look ups that = multiply > the traffic in the network, loss and latency. >=20 > In classical mesh networking, what you do when the network gets fully > busy is that you add another root. Capacity management becomes a > deployment issue. Usually what we address there is the bandwidth > capacity on the root radio space. In this thread, the 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 capacity needs is > probably divide and conquer, and nothing will replace a proper = capacity > planning overall. >=20 > RPL enables DAGs that are made of multiple DODAGs. RPL enables the = radio > roots to be connected to a backbone, with a super-root there if you = want > a single DODAG. RPL dynamically adapts to the addition or the removal = of > a root in an instance so adapting the capacity to new requirements has > only a local impact on the network. It also adapts dynamically to the > addition of a parent in the DODAG to share the load close to the root. > So we can do divide and conquer dynamically. >=20 > If there are enough parents and still one parent is overloaded > somewhere, then we might have an issue with the parent selection. At = the > moment, a parent cannot indicate the capacity of its routing 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.=20 >=20 > 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 pushback > mechanism from the nodes where the capacity is reached to the nodes on > the ridge that can jump elsewhere. >=20 > I'm not saying that this is easy, but I think it can be done. I really think this is outside the protocol 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 = implementation-specific decision. At the very least, it should be = outside the core specification.=20 It's an operational/administrative issue: if the network's routing = tables are overloaded, add another root. Rank and incrementing DODAG = sequence numbers are a perfectly reasonable way to achieve this. We = don't need additional complexity. Phil= From pal@cs.stanford.edu Tue Mar 30 10:03: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 19ED03A67A5 for ; Tue, 30 Mar 2010 10:03:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.889 X-Spam-Level: X-Spam-Status: No, score=-3.889 tagged_above=-999 required=5 tests=[AWL=-0.279, BAYES_20=-0.74, 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 OcMyJqqFCGiN for ; Tue, 30 Mar 2010 10:03:52 -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 D1F183A67CF for ; Tue, 30 Mar 2010 10:03:38 -0700 (PDT) Received: from dnab404680.stanford.edu ([171.64.70.128]) by cs-smtp-3.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1NwerI-0003OY-CX; Tue, 30 Mar 2010 10:04:08 -0700 Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Philip Levis In-Reply-To: <0146F5F5-5D51-443D-A18F-F0333759BC83@cs.jhu.edu> Date: Tue, 30 Mar 2010 10:04:08 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: 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> To: JeongGil Ko (John) X-Mailer: Apple Mail (2.1077) X-Scan-Signature: d28feff3406e72e6317b3bc92234f5b9 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, 30 Mar 2010 17:03:53 -0000 On Mar 29, 2010, at 3:37 PM, JeongGil Ko (John) wrote: > Roger,=20 >=20 > On Mar 29, 2010, at 3:31 PM, Roger Alexander wrote: >=20 >> Hi John, >>=20 >>> -----Original Message----- >>> From: JeongGil (John) Ko [mailto:jeonggil.ko@gmail.com] On Behalf Of >>> JeongGil Ko (John) >>> Sent: Monday, March 29, 2010 6:04 PM >>> To: Roger Alexander >>> Cc: roll@ietf.org >>> Subject: Re: [Roll] proposal for DAOs in non-caching DODAGs >>>=20 >>> Roger, >>>=20 >>> On Mar 29, 2010, at 2:58 PM, Roger Alexander wrote: >>>=20 >>>> Hi John, >>>>=20 >>>>> -----Original Message----- >>>>> From: JeongGil (John) Ko [mailto:jeonggil.ko@gmail.com] On Behalf = Of >>>>> JeongGil Ko (John) >>>>> Sent: Monday, March 29, 2010 5:48 PM >>>>> To: Roger Alexander >>>>> Cc: 'Pascal Thubert (pthubert)'; roll@ietf.org >>>>> Subject: Re: [Roll] proposal for DAOs in non-caching DODAGs >>>>>=20 >>>>> Hey Roger, >>>>>=20 >>>>>=20 >>>>> Maybe a stupid question but I keep making this point without = getting >>> an >>>>> answer. I agree that if we have a DAO parent set and if this is >>>>> reported to the root then the need for DAO ranks go away. However, >>> how >>>>> would a node know its DAO parents without using DAO ranks? I am >>> (once >>>>> again) not in favor of DAOs but I just want to know how we can >>> achieve >>>>> this. >>>>>=20 >>>>=20 >>>> The selection of DAO Parents is based on the Rank that the = candidate >>> nodes >>>> advertise in their DIO. As for sending the DAO Parent set to the >>> root, that >>>> is only applicable for non-storing nodes. For storing nodes the >>> DAO(s) is >>>> sent to each of the set of DAO Parents. >>>>=20 >>>=20 >>> Better understood. Then the selection of the DODAG preferred parent = set >>> and DAO parent set MAY be identical. Correct? Since both decisions = are >>> made using the DODAG rank values. Now it makes more sense :) I >>> understand that all this is unneeded when storing mode is used in = the >>> network. >>=20 >> The node will use the received Rank plus the local link cost to = determine >> Parents. The sets MAY indeed be identical but there is no requirement = that >> they be identical as a node can always have more Preferred Parents = than DAO >> Parents. The node is required to advertise destination addresses to = DAO >> Parents but can always forward traffic to any Preferred Parent at no = control >> cost. Furthermore, with link asymmetry as discussed earlier the = Preferred >> and DAO Parent sets may even be non-overlapping. By choosing the DAO = Parents >> the node is dictating its desired downward routing alternatives (no = current >> mechanism for priority but that can be addressed) while remaining = free to >> choose different parents for upward routing. >>=20 >=20 > Yup. Point taken. >=20 >> For storing and non-storing alike (based on Richard's proposal), the = system >> can operate without a rank in the DAO, or the need to maintain rank = as part >> of the routing table entry. >>=20 >=20 > Indeed having DAO ranks separately can turn in to a nightmare :) >=20 What if the metric in the two directions is drastically different? One = example would be latency with low-power MAC layers. Phil= From jeonggil.ko@gmail.com Tue Mar 30 10:27: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 4F5D03A6A18 for ; Tue, 30 Mar 2010 10:27:57 -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.001, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, 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 Yv2eQw+-6qYv for ; Tue, 30 Mar 2010 10:27:55 -0700 (PDT) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.156]) by core3.amsl.com (Postfix) with ESMTP id 13F273A67A5 for ; Tue, 30 Mar 2010 10:27:52 -0700 (PDT) Received: by fg-out-1718.google.com with SMTP id d23so3450560fga.13 for ; Tue, 30 Mar 2010 10:28:21 -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:message-id:references:to :x-mailer; bh=cH+p9gqnIVZJpjANTruBLWV35dr7C7D1IUSUxaxB9x4=; b=Km/iNdztCz2Nvb5P/Of67c+Qh/2VC8rqTETDdCWP981avv901yrzLE87SIVuwU/T45 dTZuPDQ39+EzzH972yQIqyHJZpIBZusirkn3d4CF2NrU/rOdVz+TAzYlkrhcDpTABJ4u Ly+/VRuImsoSM24s7UiSHUsNBmSbZsqDieLjk= 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 :message-id:references:to:x-mailer; b=dWkGkHBM3prqDJpRj0+wZBni7pNVJ+/a0pvalUC9GVRqAtdVtRjidFWYGEpjCPveBU 9czXM7qBbJ5SaIxkH8CCk8jnjpyg8byOwobivcNQM3kZ/WG0dx1laLLaGt9/3rgWVexs qSrFrSW/SvFax25S6D5/Ubna0fSvq0nr3xhXo= Received: by 10.87.35.9 with SMTP id n9mr3549563fgj.45.1269970100554; Tue, 30 Mar 2010 10:28:20 -0700 (PDT) Received: from dnab4046f4.stanford.edu (DNab4046f4.Stanford.EDU [171.64.70.244]) by mx.google.com with ESMTPS id 14sm4134104fxm.9.2010.03.30.10.28.17 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 30 Mar 2010 10:28:19 -0700 (PDT) Sender: "JeongGil (John) Ko" Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: multipart/alternative; boundary=Apple-Mail-94--394881571 From: "JeongGil Ko (John)" In-Reply-To: Date: Tue, 30 Mar 2010 10:28:14 -0700 Message-Id: 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> To: Philip Levis X-Mailer: Apple Mail (2.1078) 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, 30 Mar 2010 17:27:57 -0000 --Apple-Mail-94--394881571 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Mar 30, 2010, at 10:04 AM, Philip Levis wrote: >=20 > On Mar 29, 2010, at 3:37 PM, JeongGil Ko (John) wrote: >=20 >> Roger,=20 >>=20 >> On Mar 29, 2010, at 3:31 PM, Roger Alexander wrote: >>=20 >>> Hi John, >>>=20 >>>> -----Original Message----- >>>> From: JeongGil (John) Ko [mailto:jeonggil.ko@gmail.com] On Behalf = Of >>>> JeongGil Ko (John) >>>> Sent: Monday, March 29, 2010 6:04 PM >>>> To: Roger Alexander >>>> Cc: roll@ietf.org >>>> Subject: Re: [Roll] proposal for DAOs in non-caching DODAGs >>>>=20 >>>> Roger, >>>>=20 >>>> On Mar 29, 2010, at 2:58 PM, Roger Alexander wrote: >>>>=20 >>>>> Hi John, >>>>>=20 >>>>>> -----Original Message----- >>>>>> From: JeongGil (John) Ko [mailto:jeonggil.ko@gmail.com] On Behalf = Of >>>>>> JeongGil Ko (John) >>>>>> Sent: Monday, March 29, 2010 5:48 PM >>>>>> To: Roger Alexander >>>>>> Cc: 'Pascal Thubert (pthubert)'; roll@ietf.org >>>>>> Subject: Re: [Roll] proposal for DAOs in non-caching DODAGs >>>>>>=20 >>>>>> Hey Roger, >>>>>>=20 >>>>>>=20 >>>>>> Maybe a stupid question but I keep making this point without = getting >>>> an >>>>>> answer. I agree that if we have a DAO parent set and if this is >>>>>> reported to the root then the need for DAO ranks go away. = However, >>>> how >>>>>> would a node know its DAO parents without using DAO ranks? I am >>>> (once >>>>>> again) not in favor of DAOs but I just want to know how we can >>>> achieve >>>>>> this. >>>>>>=20 >>>>>=20 >>>>> The selection of DAO Parents is based on the Rank that the = candidate >>>> nodes >>>>> advertise in their DIO. As for sending the DAO Parent set to the >>>> root, that >>>>> is only applicable for non-storing nodes. For storing nodes the >>>> DAO(s) is >>>>> sent to each of the set of DAO Parents. >>>>>=20 >>>>=20 >>>> Better understood. Then the selection of the DODAG preferred parent = set >>>> and DAO parent set MAY be identical. Correct? Since both decisions = are >>>> made using the DODAG rank values. Now it makes more sense :) I >>>> understand that all this is unneeded when storing mode is used in = the >>>> network. >>>=20 >>> The node will use the received Rank plus the local link cost to = determine >>> Parents. The sets MAY indeed be identical but there is no = requirement that >>> they be identical as a node can always have more Preferred Parents = than DAO >>> Parents. The node is required to advertise destination addresses to = DAO >>> Parents but can always forward traffic to any Preferred Parent at no = control >>> cost. Furthermore, with link asymmetry as discussed earlier the = Preferred >>> and DAO Parent sets may even be non-overlapping. By choosing the DAO = Parents >>> the node is dictating its desired downward routing alternatives (no = current >>> mechanism for priority but that can be addressed) while remaining = free to >>> choose different parents for upward routing. >>>=20 >>=20 >> Yup. Point taken. >>=20 >>> For storing and non-storing alike (based on Richard's proposal), the = system >>> can operate without a rank in the DAO, or the need to maintain rank = as part >>> of the routing table entry. >>>=20 >>=20 >> Indeed having DAO ranks separately can turn in to a nightmare :) >>=20 >=20 > What if the metric in the two directions is drastically different? One = example would be latency with low-power MAC layers. >=20 > Phil This is the reason I was initially asking about metrics added for each = DAO parent that a node reports. I am guessing that this proposal does = not deal with such cases yet. It can assure 'a' routing path to a = specific prefix but not always a 'good' one. Of course good is defined = as whatever the system designer intends ( e.g., latency). John --Apple-Mail-94--394881571 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

On Mar 29, 2010, at 3:37 PM, JeongGil Ko (John) = wrote:

Roger, =

On Mar 29, 2010, at 3:31 PM, Roger Alexander = wrote:

Hi John,

-----Original = Message-----
From: = JeongGil (John) Ko [mailto:jeonggil.ko@gmail.com] On Behalf = Of
JeongGil= Ko (John)
Sent: = Monday, March 29, 2010 6:04 = PM
To: = Roger Alexander
Cc: roll@ietf.org
Subject: Re: [Roll] proposal for = DAOs in non-caching = DODAGs

Roger,

On Mar = 29, 2010, at 2:58 PM, Roger Alexander = wrote:

Hi = John,

-----Original = Message-----
From: = JeongGil (John) Ko [mailto:jeonggil.ko@gmail.com] On Behalf = Of
JeongGil= Ko = (John)
Sent: = Monday, March 29, 2010 5:48 = PM
To: = Roger = Alexander
Cc: = 'Pascal Thubert (pthubert)'; roll@ietf.org
Subject:= Re: [Roll] proposal for DAOs in non-caching = DODAGs

Hey = Roger,


Maybe = a stupid question but I keep making this point without = getting
an
answer. = I agree that if we have a DAO parent set and if this = is
reported= to the root then the need for DAO ranks go away. = However,
how
would = a node know its DAO parents without using DAO ranks? I = am
(once
again) = not in favor of DAOs but I just want to know how we = can
achieve
this.


The selection of DAO Parents is = based on the Rank that the = candidate
nodes
advertise in their DIO. As for = sending the DAO Parent set to = the
root, = that
is only applicable for = non-storing nodes. For storing nodes = the
DAO(s) = is
sent to each of the set of DAO = Parents.


Better = understood. Then the selection of the DODAG preferred parent = set
and = DAO parent set MAY be identical. Correct? Since both decisions = are
made = using the DODAG rank values. Now it makes more sense :) = I
understand that all this is unneeded when storing mode is = used in the
network.

The node will use the received = Rank plus the local link cost to = determine
Parents. The sets MAY indeed be = identical but there is no requirement = that
they be identical as a node can always have more Preferred = Parents than DAO
Parents. The node is required to = advertise destination addresses to = DAO
Parents but can always forward traffic to any Preferred = Parent at no control
cost. Furthermore, with link = asymmetry as discussed earlier the = Preferred
and DAO Parent sets may even be = non-overlapping. By choosing the DAO = Parents
the node is dictating its desired downward routing = alternatives (no current
mechanism for priority but that = can be addressed) while remaining free = to
choose different parents for upward = routing.


Yup. Point = taken.

For storing and non-storing alike (based on Richard's = proposal), the system
can operate without a rank in = the DAO, or the need to maintain rank as = part
of the routing table = entry.


Indeed having = DAO ranks separately can turn in to a nightmare = :)


What = if the metric in the two directions is drastically different? One = example would be latency with low-power MAC = layers.

Phil

This is the reason I was = initially asking about metrics added for each DAO parent that a node = reports. I am guessing that this proposal does not deal with such cases = yet. It can assure 'a' routing path to a specific prefix but not always = a 'good' one. Of course good is defined as whatever the system designer = intends ( e.g., latency).

John

= --Apple-Mail-94--394881571-- From jeonggil.ko@gmail.com Tue Mar 30 10:28: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 799B03A6AB3 for ; Tue, 30 Mar 2010 10:28:30 -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 zvc7tyFP8jUo for ; Tue, 30 Mar 2010 10:28:29 -0700 (PDT) Received: from mail-fx0-f213.google.com (mail-fx0-f213.google.com [209.85.220.213]) by core3.amsl.com (Postfix) with ESMTP id 858593A6850 for ; Tue, 30 Mar 2010 10:28:28 -0700 (PDT) Received: by fxm5 with SMTP id 5so4875451fxm.29 for ; Tue, 30 Mar 2010 10:28:54 -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=JiQ9NGkdPtldqpbJ3QtO2Nx6GrFdVB5RvMMiH72HEjM=; b=JNMME9cKtRFrmxtKs8bfLOnhQ51oDYm07HoU/jJo9wiQHfel14UE9DsOQOhJi9p/LX B0Pz2TNNe1R2r3GqEVRFyiadscppzJyUyuI5kHQF4MOgkIr+O2RmaAqrZ2St8fy/NYT8 DgTYoUwa3fCqBiKCgdHv43v0gK6IRLOPeO8VU= 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=kTWoowVb4tdDzSkSG28Sbm75zNP5LAWKkEvKR2asqU0WqVE3IsxX1qn7S5QDtKIYey WGasQkvm4HftOHBYtl2mOJc9EZGG+/3Ylla7K2IJQMRh6oaAoASzuvsB2MR+NbghcxRF XNM+U9PFWKeY3NTMIQQqyLzygBeVYOglJm13M= Received: by 10.86.124.4 with SMTP id w4mr1961100fgc.54.1269970134625; Tue, 30 Mar 2010 10:28:54 -0700 (PDT) Received: from dnab4046f4.stanford.edu (DNab4046f4.Stanford.EDU [171.64.70.244]) by mx.google.com with ESMTPS id 14sm4134104fxm.9.2010.03.30.10.28.52 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 30 Mar 2010 10:28:53 -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: Tue, 30 Mar 2010 10:28:51 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <6F2E97C8-6AFA-4A7D-83A2-5F1EC14DE480@cs.jhu.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> <93B6031E-ECE1-4C63-848C-1C43B48F69C8@cs.stanford.edu> <6A2A459175DABE4BB11DE2026AA50A5D0188AF9F@XMB-AMS-107.cisco.com> To: Philip Levis X-Mailer: Apple Mail (2.1078) 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, 30 Mar 2010 17:28:30 -0000 +1=20 -John On Mar 30, 2010, at 10:03 AM, Philip Levis wrote: > On Mar 29, 2010, at 11:35 PM, Pascal Thubert (pthubert) wrote: >=20 >> Hi: >>=20 >> As Phil said the anti-replay came up in Anaheim. This piece is to be >> covered in the security analysis. So I think we should only consider = the >> saturation of routing tables in this thread. >>=20 >> 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 >> appropriately (too small) just causes permanent look ups that = multiply >> the traffic in the network, loss and latency. >>=20 >> In classical mesh networking, what you do when the network gets fully >> busy is that you add another root. Capacity management becomes a >> deployment issue. Usually what we address there is the bandwidth >> capacity on the root radio space. In this thread, the 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 capacity needs is >> probably divide and conquer, and nothing will replace a proper = capacity >> planning overall. >>=20 >> RPL enables DAGs that are made of multiple DODAGs. RPL enables the = radio >> roots to be connected to a backbone, with a super-root there if you = want >> a single DODAG. RPL dynamically adapts to the addition or the removal = of >> a root in an instance so adapting the capacity to new requirements = has >> only a local impact on the network. It also adapts dynamically to the >> addition of a parent in the DODAG to share the load close to the = root. >> So we can do divide and conquer dynamically. >>=20 >> If there are enough parents and still one parent is overloaded >> somewhere, then we might have an issue with the parent selection. At = the >> moment, a parent cannot indicate the capacity of its routing 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.=20 >>=20 >> 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 pushback >> mechanism from the nodes where the capacity is reached to the nodes = on >> the ridge that can jump elsewhere. >>=20 >> I'm not saying that this is easy, but I think it can be done. >=20 > I really think this is outside the protocol 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 = implementation-specific decision. At the very least, it should be = outside the core specification.=20 >=20 > It's an operational/administrative issue: if the network's routing = tables are overloaded, add another root. Rank and incrementing DODAG = sequence numbers are a perfectly reasonable way to achieve this. We = don't need additional complexity. >=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 pal@cs.stanford.edu Tue Mar 30 10:29: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 9AE7F3A6AAE for ; Tue, 30 Mar 2010 10:29:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.426 X-Spam-Level: X-Spam-Status: No, score=-3.426 tagged_above=-999 required=5 tests=[AWL=-0.557, BAYES_50=0.001, 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 1HKQq8eNJJw5 for ; Tue, 30 Mar 2010 10:29:00 -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 9ED0D3A6850 for ; Tue, 30 Mar 2010 10:29:00 -0700 (PDT) Received: from dnab404680.stanford.edu ([171.64.70.128]) by cs-smtp-2.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1NwfFo-0003Ly-3G; Tue, 30 Mar 2010 10:29:30 -0700 Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Philip Levis In-Reply-To: Date: Tue, 30 Mar 2010 10:29:27 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <19e8ae197e37.197e3719e8ae@drexel.edu> To: Joydeep Tripathi X-Mailer: Apple Mail (2.1077) X-Scan-Signature: 3e263c829a24e9e508d860775f9d44fb Cc: ROLL WG Subject: Re: [Roll] Fwd: New Version Notification for draft-tripathi-roll-rpl-simulation-03 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 30 Mar 2010 17:29:01 -0000 On Mar 30, 2010, at 12:46 AM, Joydeep Tripathi wrote: > Hi, >=20 > We published another draft on Simulation results of RPL. In this > revision, we added path stretch and delay metric comparison of the > packets in RPL routing with shortest path routing. We also added > Simulation results of RPL in a typical home/building routing traffic > scenario. Thanks to Jerry for providing the details of message length > and distribution in such a network. Note, we did not attempt to use > any random topology with a random link quality, cause that might not > provide us with intuition into how real deployment may behave in > presence of link quality variation and link PDR distribution. We also > simulate RPL with a 86 node topology, and in process of simulating it > in another real network of few thousand nodes. >=20 > This simulation study shows, the path stretch is very less in > the home/building routing scenario. Also, the delay bound in RPL is > not worse than that of shortest path routing, showing P2P routing in > RPL a viable option for this kind of applications in terms of Path = quality. >=20 > Looking forward to any comments/suggestions. >=20 Joydeep, I have concerns with the simulation methodology. In particular: 1) Links are selected randomly. Links in real networks can be correlated = in behavior, either due to hardware variations or correlated = environmental effects (e.g., interference). The problem with random = selection is that as a node has more links, it will inevitably have some = good ones. In practice this isn't always true (e.g., a node is near an = interference source). This will lead the simulation results to think = that RPL behaves better than it does in practice. 2) Links vary on the time scale of 10 minutes and have iid losses within = those ten minute intervals. Links are bursty, and protocols respond to = bursty losses very differently than iid ones. In particular, = retransmission policies. I'm a big fan of simulation as a debugging tool to find problems early = and easily. I'm just very wary of using it for any kind of definite = conclusion. Phil From jpv@cisco.com Tue Mar 30 11:31: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 5D0003A68DA for ; Tue, 30 Mar 2010 11:31:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.901 X-Spam-Level: X-Spam-Status: No, score=-7.901 tagged_above=-999 required=5 tests=[AWL=1.568, 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 qJjQOyJ7vzSS for ; Tue, 30 Mar 2010 11:31:49 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 2AE2E3A6925 for ; Tue, 30 Mar 2010 11:31:49 -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: Aj0CAAHhsUuQ/uCWe2dsb2JhbACbLhUBAQsLIgYcp0aZHoUABI4f X-IronPort-AV: E=Sophos;i="4.51,335,1267401600"; d="scan'208";a="58759121" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 30 Mar 2010 18:32:17 +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 o2UIWHHr006422; Tue, 30 Mar 2010 18:32:17 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); Tue, 30 Mar 2010 20:32:17 +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); Tue, 30 Mar 2010 20:32:16 +0200 Message-Id: <4D897440-F028-44C9-A02B-4FDED690C1FE@cisco.com> From: JP Vasseur To: Philip Levis In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 30 Mar 2010 20:32:15 +0200 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> <93B6031E-ECE1-4C63-848C-1C43B48F69C8@cs.stanford.edu> <6A2A459175DABE4BB11DE2026AA50A5D0188AF9F@XMB-AMS-107.cisco.com> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 30 Mar 2010 18:32:16.0313 (UTC) FILETIME=[52B93A90:01CAD037] 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, 30 Mar 2010 18:31:51 -0000 On Mar 30, 2010, at 7:03 PM, Philip Levis wrote: > On Mar 29, 2010, at 11:35 PM, Pascal Thubert (pthubert) wrote: > >> Hi: >> >> As Phil said the anti-replay came up in Anaheim. This 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 >> appropriately (too small) just causes permanent look ups that >> 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 becomes a >> deployment issue. Usually what we address there is the bandwidth >> capacity on the root radio space. In this thread, the 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 capacity needs is >> probably divide and conquer, and nothing will replace a proper >> capacity >> planning overall. >> >> RPL enables DAGs that are made of multiple DODAGs. RPL enables the >> radio >> roots to be connected to a backbone, with a super-root there if you >> want >> a single DODAG. RPL dynamically adapts to the addition or the >> removal of >> a root in an instance so adapting the capacity to new requirements >> has >> only a local impact on the network. It also adapts dynamically to the >> addition of a parent in the DODAG to 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 >> somewhere, then we might have an issue with the parent selection. >> At the >> moment, a parent cannot indicate the capacity of its routing 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 pushback >> mechanism from the nodes where the capacity is 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 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 > implementation-specific decision. At the very least, it should be > outside the core specification. Yes I do agree. This is either an implementation specific issue or even more likely a deployment issue. > > It's an operational/administrative issue: if the network's routing > tables are overloaded, add another root. Rank and incrementing DODAG > sequence numbers are a perfectly reasonable way to achieve this. We > don't need additional complexity. Definitely. Thanks. JP. > > Phil > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From phoebus@ieee.org Tue Mar 30 14: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 1FF1C3A6B18 for ; Tue, 30 Mar 2010 14:15:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.63 X-Spam-Level: X-Spam-Status: No, score=-103.63 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, DNS_FROM_OPENWHOIS=1.13, 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 0MhObIpsTWDx for ; Tue, 30 Mar 2010 14:15:50 -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 DCDA63A6987 for ; Tue, 30 Mar 2010 14:15:49 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp-1.sys.kth.se (Postfix) with ESMTP id AF3EC1558A9 for ; Tue, 30 Mar 2010 23:15:48 +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 F2P9Hu7rjw+C for ; Tue, 30 Mar 2010 23:15:45 +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 02FF5154137 for ; Tue, 30 Mar 2010 23:15:44 +0200 (CEST) Message-ID: <4BB26A00.5020400@ieee.org> Date: Tue, 30 Mar 2010 23:15:44 +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.8) Gecko/20100227 Thunderbird/3.0.3 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> <93B6031E-ECE1-4C63-848C-1C43B48F69C8@cs.stanford.edu> <6A2A459175DABE4BB11DE2026AA50A5D0188AF9F@XMB-AMS-107.cisco.com> <4D897440-F028-44C9-A02B-4FDED690C1FE@cisco.com> In-Reply-To: <4D897440-F028-44C9-A02B-4FDED690C1FE@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Roll] Mixed mode 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: Tue, 30 Mar 2010 21:15:52 -0000 JP and Phil, Umm, are you sure it's a good idea to punt on this issue? Limited memory and interoperability has been stressed so much on this mailing list. I would hate to be the poor guy trying to debug a network where the devices came from different vendors and each had a different table eviction policy. Are you going to at least specify some sort of a standard error message to send back to the root in this situation? BTW, I support the proposal to just not add new entries if the table is full, rather than try to evict different entries. It's simpler to understand, and requires less debating on this mailing list (since the focus is on other issues right now). It makes sense to revisit the issues Pascal brought up later. -- Phoebus Chen Postdoctoral Researcher Automatic Control Lab, KTH (Royal Institute of Technology) http://www.ee.kth.se/~phoebus On 3/30/10 8:32 PM, JP Vasseur wrote: > > On Mar 30, 2010, at 7:03 PM, Philip Levis wrote: > >> On Mar 29, 2010, at 11:35 PM, Pascal Thubert (pthubert) wrote: >> >>> Hi: >>> >>> As Phil said the anti-replay came up in Anaheim. This 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 >>> appropriately (too small) just causes permanent look ups that >>> 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 becomes a >>> deployment issue. Usually what we address there is the bandwidth >>> capacity on the root radio space. In this thread, the 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 capacity needs is >>> probably divide and conquer, and nothing will replace a proper >>> capacity >>> planning overall. >>> >>> RPL enables DAGs that are made of multiple DODAGs. RPL enables the >>> radio >>> roots to be connected to a backbone, with a super-root there if you >>> want >>> a single DODAG. RPL dynamically adapts to the addition or the >>> removal of >>> a root in an instance so adapting the capacity to new requirements >>> has >>> only a local impact on the network. It also adapts dynamically to the >>> addition of a parent in the DODAG to 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 >>> somewhere, then we might have an issue with the parent selection. >>> At the >>> moment, a parent cannot indicate the capacity of its routing 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 pushback >>> mechanism from the nodes where the capacity is 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 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 >> implementation-specific decision. At the very least, it should be >> outside the core specification. > > Yes I do agree. This is either an implementation specific issue or > even more likely a deployment issue. > >> >> It's an operational/administrative issue: if the network's routing >> tables are overloaded, add another root. Rank and incrementing DODAG >> sequence numbers are a perfectly reasonable way to achieve this. We >> don't need additional complexity. > > Definitely. > > Thanks. > > JP. > >> >> 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 pal@cs.stanford.edu Tue Mar 30 14:36: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 724FB3A6B4B for ; Tue, 30 Mar 2010 14:36:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.587 X-Spam-Level: X-Spam-Status: No, score=-4.587 tagged_above=-999 required=5 tests=[AWL=0.882, 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 MaFg81RWBT1s for ; Tue, 30 Mar 2010 14:36: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 937EE3A6B48 for ; Tue, 30 Mar 2010 14:36:32 -0700 (PDT) Received: from dnab404680.stanford.edu ([171.64.70.128]) by cs-smtp-3.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1Nwj7O-0003te-GU; Tue, 30 Mar 2010 14:37:02 -0700 Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Philip Levis In-Reply-To: <4BB26A00.5020400@ieee.org> Date: Tue, 30 Mar 2010 14:37:02 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <2DF09A97-3E30-43CA-AF9C-7E18F5AD2D6C@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> <93B6031E-ECE1-4C63-848C-1C43B48F69C8@cs.stanford.edu> <6A2A459175DABE4BB11DE2026AA50A5D0188AF9F@XMB-AMS-107.cisco.com> <4D897440-F028-44C9-A02B-4FDED690C1FE@cisco.com> <4BB26A00.5020400@ieee.org> To: phoebus@ieee.org X-Mailer: Apple Mail (2.1077) X-Scan-Signature: 10362da83454c0a30f3f1339bddfed40 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: Tue, 30 Mar 2010 21:36:33 -0000 On Mar 30, 2010, at 2:15 PM, Phoebus Chen wrote: > JP and Phil, >=20 > Umm, are you sure it's a good idea to punt on this issue? = Limited memory and interoperability has been stressed so much on this = mailing list. I would hate to be the poor guy trying to debug a network = where the devices came from different vendors and each had a different = table eviction policy. Are you going to at least specify some sort of a = standard error message to send back to the root in this situation? I don't think the question is whether to punt; it's whether it's in the = core spec. Please, someone correct me if I'm wrong, but *no routing = protocol today* deals with this issue. Putting a research question on = the critical path seems like a bad idea to me. I mean, I suppose we = could make something up and convince ourselves it's reasonable, but the = history of wireless protocol design has shown us the success of such = ventures. :) Keep in mind the situation here: someone has greatly underprovisioned = their network. How would this manifest? A good implementation is going = to limit the amount of energy it spends on route discovery. If there's = routing table churn beyond this budget, then there won't be routes: = ICMPv6 code 1. Getting a report of this to a management layer lies above = RPL. But I think that's where the answer lies. E.g., in a home = automation network, nodes report what their general routing state is. If = it starts to look cramped, then the home automation network can = initialize another node to be a DODAG root. >=20 > BTW, I support the proposal to just not add new entries if the table = is full, rather than try to evict different entries. It's simpler to = understand, and requires less debating on this mailing list (since the = focus is on other issues right now). It makes sense to revisit the = issues Pascal brought up later. Let's get back to the basic requirement Anders keeps on reiterating: if = I flick a light switch, the light should turn on. What happens if = routing table entries are full? Phil= From roger.alexander@ekasystems.com Tue Mar 30 15:39: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 9B1AC3A68FE for ; Tue, 30 Mar 2010 15:39:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.488 X-Spam-Level: ** X-Spam-Status: No, score=2.488 tagged_above=-999 required=5 tests=[AWL=0.093, BAYES_40=-0.185, DNS_FROM_OPENWHOIS=1.13, 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 dP3c0jdYtoWc for ; Tue, 30 Mar 2010 15:39:13 -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 268173A6BE6 for ; Tue, 30 Mar 2010 15:39:12 -0700 (PDT) Received: (qmail 95598 invoked from network); 30 Mar 2010 22:39:39 -0000 Received: from dallas (roger.alexander@209.48.242.70 with login) by smtp114.biz.mail.re2.yahoo.com with SMTP; 30 Mar 2010 15:39:39 -0700 PDT X-Yahoo-SMTP: 1dQRPo6swBBzwSsRzMLy_tvdRrLDyF0J X-YMail-OSG: _Lh6Lk0VM1mXgTI2yaCPCTyT.06PyGMJ1g3RCegK50RJTNokIoZ74DMYuPfcYgI_6DGL.7aLgbQLqvm6P9lZkBbhcor2ozPDv5xwaUHig5ZJcw0EsbqCy1l.i2TKTvWNYbOIot1Ay9P0.7DBlu9Mv7L2M5Mm1wGQuYfpcpE6CT1YcUhUD9h8fpYDAFb.5qckQ6mJO02e_sZlRL0yc0rrQuYNQXaqPswyFPcPkz3VtB.SCJgMLtQOd6LJlPVOkw6jNj3egIXfR613z501pwO8QmoTLO.It_ZJqF3NOq0vrtBVx2o9jdgOWHJ0RGuSF0E857tFjxtoi0PnFbVFaU7wFpC2SWvbRM5J9t9TJwYLKRpI1BT.dmM.hvfJ.p.S9VNN X-Yahoo-Newman-Property: ymail-3 From: "Roger Alexander" To: "'Philip Levis'" , "'JeongGil Ko \(John\)'" 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> In-Reply-To: Date: Tue, 30 Mar 2010 18:38:28 -0400 Message-ID: <010301cad059$b8017350$280459f0$@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: AcrQKwKkhjqy0ZckTWmNZSGNqFrUUwAJ5ncQ Content-Language: en-us 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, 30 Mar 2010 22:39:14 -0000 Hi Phil, John, > -----Original Message----- > From: Philip Levis [mailto:pal@cs.stanford.edu] > Sent: Tuesday, March 30, 2010 1:04 PM > To: JeongGil Ko (John) > Cc: Roger Alexander; roll@ietf.org > Subject: Re: [Roll] proposal for DAOs in non-caching DODAGs > > > On Mar 29, 2010, at 3:37 PM, JeongGil Ko (John) wrote: > > > Roger, > > > > On Mar 29, 2010, at 3:31 PM, Roger Alexander wrote: > > > >> Hi John, > >> > >>> -----Original Message----- > >>> From: JeongGil (John) Ko [mailto:jeonggil.ko@gmail.com] On Behalf > Of > >>> JeongGil Ko (John) > >>> Sent: Monday, March 29, 2010 6:04 PM > >>> To: Roger Alexander > >>> Cc: roll@ietf.org > >>> Subject: Re: [Roll] proposal for DAOs in non-caching DODAGs > >>> > >>> Roger, > >>> > >>> On Mar 29, 2010, at 2:58 PM, Roger Alexander wrote: > >>> > >>>> Hi John, > >>>> > >>>>> -----Original Message----- > >>>>> From: JeongGil (John) Ko [mailto:jeonggil.ko@gmail.com] On Behalf > Of > >>>>> JeongGil Ko (John) > >>>>> Sent: Monday, March 29, 2010 5:48 PM > >>>>> To: Roger Alexander > >>>>> Cc: 'Pascal Thubert (pthubert)'; roll@ietf.org > >>>>> Subject: Re: [Roll] proposal for DAOs in non-caching DODAGs > >>>>> > >>>>> Hey Roger, > >>>>> > >>>>> > >>>>> Maybe a stupid question but I keep making this point without > getting > >>> an > >>>>> answer. I agree that if we have a DAO parent set and if this is > >>>>> reported to the root then the need for DAO ranks go away. > However, > >>> how > >>>>> would a node know its DAO parents without using DAO ranks? I am > >>> (once > >>>>> again) not in favor of DAOs but I just want to know how we can > >>> achieve > >>>>> this. > >>>>> > >>>> > >>>> The selection of DAO Parents is based on the Rank that the > candidate > >>> nodes > >>>> advertise in their DIO. As for sending the DAO Parent set to the > >>> root, that > >>>> is only applicable for non-storing nodes. For storing nodes the > >>> DAO(s) is > >>>> sent to each of the set of DAO Parents. > >>>> > >>> > >>> Better understood. Then the selection of the DODAG preferred parent > set > >>> and DAO parent set MAY be identical. Correct? Since both decisions > are > >>> made using the DODAG rank values. Now it makes more sense :) I > >>> understand that all this is unneeded when storing mode is used in > the > >>> network. > >> > >> The node will use the received Rank plus the local link cost to > determine > >> Parents. The sets MAY indeed be identical but there is no > requirement that > >> they be identical as a node can always have more Preferred Parents > than DAO > >> Parents. The node is required to advertise destination addresses to > DAO > >> Parents but can always forward traffic to any Preferred Parent at no > control > >> cost. Furthermore, with link asymmetry as discussed earlier the > Preferred > >> and DAO Parent sets may even be non-overlapping. By choosing the DAO > Parents > >> the node is dictating its desired downward routing alternatives (no > current > >> mechanism for priority but that can be addressed) while remaining > free to > >> choose different parents for upward routing. > >> > > > > Yup. Point taken. > > > >> For storing and non-storing alike (based on Richard's proposal), the > system > >> can operate without a rank in the DAO, or the need to maintain rank > as part > >> of the routing table entry. > >> > > > > Indeed having DAO ranks separately can turn in to a nightmare :) > > > > What if the metric in the two directions is drastically different? One > example would be latency with low-power MAC layers. > 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. > Phil= From jhui@archrock.com Tue Mar 30 19:08: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 0F1C03A68EE for ; Tue, 30 Mar 2010 19:08:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.425 X-Spam-Level: X-Spam-Status: No, score=-0.425 tagged_above=-999 required=5 tests=[AWL=-0.445, BAYES_05=-1.11, 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 3OXNHmbZoeB8 for ; Tue, 30 Mar 2010 19:08:17 -0700 (PDT) Received: from mail.sf.archrock.com (mail.sf.archrock.com [216.121.16.71]) by core3.amsl.com (Postfix) with ESMTP id 26BF63A68DC for ; Tue, 30 Mar 2010 19:08:17 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.sf.archrock.com (Postfix) with ESMTP id 9C137AF947; Tue, 30 Mar 2010 19:08:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at Received: from mail.sf.archrock.com ([127.0.0.1]) by localhost (mail.sf.archrock.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YUh1y4sINpKN; Tue, 30 Mar 2010 19:08:43 -0700 (PDT) Received: from [10.0.1.5] (adsl-71-142-73-125.dsl.pltn13.pacbell.net [71.142.73.125]) by mail.sf.archrock.com (Postfix) with ESMTP id 77381AF835; Tue, 30 Mar 2010 19:08:43 -0700 (PDT) Message-Id: <8F278AA8-105B-40C8-BC67-A0A5E30B47BE@archrock.com> From: Jonathan Hui To: Richard Kelsey In-Reply-To: <87vdcg5eis.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: Tue, 30 Mar 2010 19:08:42 -0700 References: <87vdcg5eis.fsf@kelsey-ws.hq.ember.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: Wed, 31 Mar 2010 02:08:18 -0000 Hi Richard, I like the proposal in general, though it does need to be fleshed out a bit more. Specifically, this works well in the non-storing case if all nodes source DAOs to the root so that the root can properly construct paths back to any individual node that is sending DAOs. But is there any desire to allow some nodes not to source DAOs if they don't need to? If so, we should specify that a node MUST source DAOs as long as they are forwarding DAOs for descendants. Separately, it might be nice to include a record-route mechanism (not the same as reverse route stack DAOs) so that nodes that only want to quickly establish routes can do so without having to possibly wait for all ancestors to source their own DAOs as well. I've found that record-route works really well in short request-response transactions, especially in cases where you don't want to continuously maintain downward routing state. -- Jonathan Hui On Mar 28, 2010, at 2:20 PM, Richard Kelsey wrote: > 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. > > 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. > > 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. > > 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. > > 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 > > What do people think? > -Richard Kelsey > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From jhui@archrock.com Tue Mar 30 19:18: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 897223A6952 for ; Tue, 30 Mar 2010 19:18:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.26 X-Spam-Level: X-Spam-Status: No, score=0.26 tagged_above=-999 required=5 tests=[AWL=-0.685, BAYES_40=-0.185, 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 8qAmOGzd+e-x for ; Tue, 30 Mar 2010 19:18:00 -0700 (PDT) Received: from mail.sf.archrock.com (mail.sf.archrock.com [216.121.16.71]) by core3.amsl.com (Postfix) with ESMTP id 4F1473A6801 for ; Tue, 30 Mar 2010 19:18:00 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.sf.archrock.com (Postfix) with ESMTP id A6125AF94A; Tue, 30 Mar 2010 19:18:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at Received: from mail.sf.archrock.com ([127.0.0.1]) by localhost (mail.sf.archrock.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CJlFo3q3NXL6; Tue, 30 Mar 2010 19:18:25 -0700 (PDT) Received: from [10.0.1.5] (adsl-71-142-73-125.dsl.pltn13.pacbell.net [71.142.73.125]) by mail.sf.archrock.com (Postfix) with ESMTP id 83C15AF947; Tue, 30 Mar 2010 19:18:25 -0700 (PDT) Message-Id: <322B249E-6EE0-4FC8-8AC2-9AC227E4B66C@archrock.com> From: Jonathan Hui To: Roger Alexander In-Reply-To: <010301cad059$b8017350$280459f0$@alexander@ekasystems.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, 30 Mar 2010 19:18:24 -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> 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: Wed, 31 Mar 2010 02:18:01 -0000 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. 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 jeonggil.ko@gmail.com Tue Mar 30 20: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 427593A6A01 for ; Tue, 30 Mar 2010 20:26:17 -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.341, BAYES_40=-0.185, DNS_FROM_OPENWHOIS=1.13, 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 QnpjLklbW6Mx for ; Tue, 30 Mar 2010 20:26:16 -0700 (PDT) Received: from mail-iw0-f194.google.com (mail-iw0-f194.google.com [209.85.223.194]) by core3.amsl.com (Postfix) with ESMTP id 28E843A6952 for ; Tue, 30 Mar 2010 20:26:16 -0700 (PDT) Received: by iwn32 with SMTP id 32so639047iwn.18 for ; Tue, 30 Mar 2010 20:26:44 -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:message-id:references:to :x-mailer; bh=97czl6tkLJvJXXgqZKiAofziD2/EwEFVLapjWaMSifY=; b=LaLN8/vburoo2wveXw4PdNhRjOfeh2gIDhzruB9p1Bs43Qcdt/+wHNhcUwwjPBZoq0 7f2RgrycAn3mjlOIbTIZO8G8sKPDkdS7HHl8y8L8HZj4UBbQHw+RjK4RkXYW07H7qILC UEZQ9xpEUsS5qzA5j1XQo/A9dYujDygTuYYfY= 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 :message-id:references:to:x-mailer; b=cnQtzyARxG3javZjXHWTF/wInJsgY+mdhMl/3oXDmKy70HakRLYSjb2dk+FBHd2zWx xqepXrgUewC7nq0Ui1K9GCE5rLxm7TfWHURt6YZVDWnyiZBNTFZWDadmadzM+GSpIS1L oLcBtFmfaCpYe1dy1IqJqz9zc/GFAxsQZL17A= Received: by 10.231.191.72 with SMTP id dl8mr3770153ibb.22.1270006003810; Tue, 30 Mar 2010 20:26:43 -0700 (PDT) Received: from [192.168.1.103] ([76.14.51.89]) by mx.google.com with ESMTPS id j42sm6334131ibr.19.2010.03.30.20.26.41 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 30 Mar 2010 20:26:43 -0700 (PDT) Sender: "JeongGil (John) Ko" Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: multipart/alternative; boundary=Apple-Mail-659--358975884 From: "JeongGil Ko (John)" In-Reply-To: <322B249E-6EE0-4FC8-8AC2-9AC227E4B66C@archrock.com> Date: Tue, 30 Mar 2010 20:26:40 -0700 Message-Id: <45AE56C8-66D7-466C-8E5E-89DAC23BE196@cs.jhu.edu> 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> To: Jonathan Hui X-Mailer: Apple Mail (2.1078) 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 03:26:17 -0000 --Apple-Mail-659--358975884 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Mar 30, 2010, at 7:18 PM, Jonathan Hui wrote: >=20 > 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. >>=20 >> 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. >=20 >=20 > 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. >=20 So let me see if I got it correctly. A DIO will contain the rank = information for both downwards 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. >=20 > -- > Jonathan Hui >=20 --Apple-Mail-659--358975884 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

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 the rank information for both downwards = 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


= --Apple-Mail-659--358975884-- From jhui@archrock.com Tue Mar 30 22:53: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 722193A6BEE for ; Tue, 30 Mar 2010 22:53:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.023 X-Spam-Level: X-Spam-Status: No, score=0.023 tagged_above=-999 required=5 tests=[AWL=-0.367, BAYES_20=-0.74, 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 nd8UZV9Qz-zn for ; Tue, 30 Mar 2010 22:53:56 -0700 (PDT) Received: from mail.sf.archrock.com (mail.sf.archrock.com [216.121.16.71]) by core3.amsl.com (Postfix) with ESMTP id 8E1D53A6A2D for ; Tue, 30 Mar 2010 22:53:36 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.sf.archrock.com (Postfix) with ESMTP id 1BC15AF98F; Tue, 30 Mar 2010 22:54:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at Received: from mail.sf.archrock.com ([127.0.0.1]) by localhost (mail.sf.archrock.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D-qVzazu6Z93; Tue, 30 Mar 2010 22:54:02 -0700 (PDT) Received: from [10.0.1.5] (adsl-71-142-73-125.dsl.pltn13.pacbell.net [71.142.73.125]) by mail.sf.archrock.com (Postfix) with ESMTP id 47271AF835; Tue, 30 Mar 2010 22:54:02 -0700 (PDT) Message-Id: <03A6E62B-5EF5-497F-98DC-6B38E882918D@archrock.com> From: Jonathan Hui To: JeongGil Ko (John) In-Reply-To: <45AE56C8-66D7-466C-8E5E-89DAC23BE196@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: Tue, 30 Mar 2010 22:54:01 -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> X-Mailer: Apple Mail (2.936) Cc: roll WG 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 05:53:57 -0000 On Mar 30, 2010, at 8:26 PM, JeongGil Ko (John) wrote: > On Mar 30, 2010, at 7:18 PM, Jonathan Hui wrote: > >> 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 the rank > information for both downwards 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 :) To be more precise, a DIO may contain separate metric information for upwards and downwards paths (i.e. directional cost metrics) if having the DAG and DAO parents being different sets is desirable. Alternatively, a DIO may contain the same metric information for both directions paths (i.e. bidirectional cost metrics) if having the DAG and DAO parents being the same set is acceptable. >> 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 pthubert@cisco.com Wed Mar 31 00:06: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 421993A6985 for ; Wed, 31 Mar 2010 00:06:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.38 X-Spam-Level: X-Spam-Status: No, score=-3.38 tagged_above=-999 required=5 tests=[AWL=-1.912, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, 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 4j7FWf-f8mw3 for ; Wed, 31 Mar 2010 00:06:06 -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 696F83A6926 for ; Wed, 31 Mar 2010 00:06: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: AgwCALORskuQ/uCWe2dsb2JhbACBP5lqFQEBCwsiBhymFpkVhQAEjiA X-IronPort-AV: E=Sophos;i="4.51,340,1267401600"; d="scan'208,217";a="5003974" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-2.cisco.com with ESMTP; 31 Mar 2010 06:31: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 o2V76UPa002755; Wed, 31 Mar 2010 07:06:30 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); Wed, 31 Mar 2010 09:06:29 +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_01CAD0A0.AFAC63A0" Date: Wed, 31 Mar 2010 09:06:26 +0200 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D0192352A@XMB-AMS-107.cisco.com> In-Reply-To: <45AE56C8-66D7-466C-8E5E-89DAC23BE196@cs.jhu.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] proposal for DAOs in non-caching DODAGs Thread-Index: AcrQggL79yHdrg+zQbGy/g9q3FSvkwAHZIkA 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> From: "Pascal Thubert (pthubert)" To: "JeongGil Ko (John)" , "Jonathan Hui" X-OriginalArrivalTime: 31 Mar 2010 07:06:29.0966 (UTC) FILETIME=[B000AEE0:01CAD0A0] 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 07:06:18 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CAD0A0.AFAC63A0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi John: =20 The Rank is derived from the decision of the parent set, that includes both DIO parents that optimize the path towards the root and DAO parents that optimize the path from the root to this node. =20 So the Rank mechanism does not depend whether the metrics are all bidirectional or if some metrics are unidirectional. The Rank mechanism belongs to the generic RPL and is designed for loop avoidance, whatever the specific things the OF does with the metrics of the day. =20 If you really need to have the rank represent finely the metrics cost, and the metrics are really assymetrical, then probably you want 2 DAGs, one for which the RANK increment is mostly derived from the up metrics and one for which it is mostly derived from the down metrics. =20 Mukul's point stands. Sometimes, the Rank increment for the parent-child link depends on metrics that are available at the parent after communication from the child, so we might have a chicken and an egg problem in the parent selection. I think we need to refine our text on the link evaluation with candidate neighbors that enables a neighbor to become a candidate parent in the first place. =20 =20 Pascal =20 From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of JeongGil Ko (John) Sent: Wednesday, March 31, 2010 5:27 AM To: Jonathan Hui Cc: roll@ietf.org Subject: Re: [Roll] proposal for DAOs in non-caching DODAGs =20 =20 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. =20 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. =20 So let me see if I got it correctly. A DIO will contain the rank information for both downwards 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 :) =20 -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 =20 ------_=_NextPart_001_01CAD0A0.AFAC63A0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi John:

 

The Rank is derived from the decision of the parent set, that = includes both DIO parents that optimize the path towards the root and = DAO parents that optimize the path from the root to this = node.

 

So the Rank mechanism does not depend whether the metrics are all = bidirectional or if some metrics are unidirectional. The Rank mechanism = belongs to the generic RPL and is designed for loop avoidance, whatever = the specific things the OF does with the metrics of the = day.

 

If you really need to have the rank represent finely the metrics = cost, and the metrics are really assymetrical, then probably you want 2 = DAGs, one for which the RANK increment is mostly derived from the up = metrics and one for which it is mostly derived from the down = metrics.

 

Mukul’s point stands. Sometimes, the Rank increment for the = parent-child link depends on metrics that are available at the parent = after communication from the child, so we might have a chicken and an = egg problem in the parent selection. I think we need to refine our text = on the link evaluation with candidate neighbors that enables a neighbor = to become a candidate parent in the first place. =  

 

Pascal

 

From:= = roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of = JeongGil Ko (John)
Sent: Wednesday, March 31, 2010 5:27 = AM
To: Jonathan Hui
Cc: = roll@ietf.org
Subject: Re: [Roll] proposal for DAOs in = non-caching DODAGs

 

 

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 the rank information for = both downwards 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<= /span>



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

 

------_=_NextPart_001_01CAD0A0.AFAC63A0-- From pal@cs.stanford.edu Wed Mar 31 00:12: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 9BA6F3A695F for ; Wed, 31 Mar 2010 00:12:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.138 X-Spam-Level: X-Spam-Status: No, score=-5.138 tagged_above=-999 required=5 tests=[AWL=0.330, 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 RRDoC5q1sP2r for ; Wed, 31 Mar 2010 00:12:51 -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 4BF6E3A6A0A for ; Wed, 31 Mar 2010 00:12:37 -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 1Nws6t-00068F-Ew; Wed, 31 Mar 2010 00:13:07 -0700 Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: multipart/alternative; boundary=Apple-Mail-10--345389401 From: Philip Levis In-Reply-To: <6A2A459175DABE4BB11DE2026AA50A5D0192352A@XMB-AMS-107.cisco.com> Date: Wed, 31 Mar 2010 00:13:06 -0700 Message-Id: <7C1C35FC-0FA6-4F65-B045-D8BDEF2B30CF@cs.stanford.edu> 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> <6A2A459175DABE4BB11DE2026AA50A5D0192352A@XMB-AMS-107.cisco.com> To: Pascal Thubert (pthubert) X-Mailer: Apple Mail (2.1077) X-Scan-Signature: f9ef471525bfb2768cd458964c721f6b 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 07:12:54 -0000 --Apple-Mail-10--345389401 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Mar 31, 2010, at 12:06 AM, Pascal Thubert (pthubert) wrote: > Hi John: > =20 > The Rank is derived from the decision of the parent set, that includes = both DIO parents that optimize the path towards the root and DAO parents = that optimize the path from the root to this node. > =20 > So the Rank mechanism does not depend whether the metrics are all = bidirectional or if some metrics are unidirectional. The Rank mechanism = belongs to the generic RPL and is designed for loop avoidance, whatever = the specific things the OF does with the metrics of the day. I thought we'd gone over this: this can't be true. The rules in RPL in = Rank adjustment means that Rank generally comes first in parent set = selection. This is part of why we agreed to increase Rank to 16 bits, in = order to allow it to better represent metrics as necessary. > =20 > If you really need to have the rank represent finely the metrics cost, = and the metrics are really assymetrical, then probably you want 2 DAGs, = one for which the RANK increment is mostly derived from the up metrics = and one for which it is mostly derived from the down metrics. I totally disagree -- this seems completely backwards. You're suggesting = that my TCP packets from A->B traverse one DAG while B->A traverse = another? > =20 > Mukul=92s point stands. Sometimes, the Rank increment for the = parent-child link depends on metrics that are available at the parent = after communication from the child, so we might have a chicken and an = egg problem in the parent selection. I think we need to refine our text = on the link evaluation with candidate neighbors that enables a neighbor = to become a candidate parent in the first place. =20 The child gets to pick the parent. Note that link metrics can persist = across DODAG iterations. I'm not sure I understand the problem? Phil= --Apple-Mail-10--345389401 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
On Mar 31, 2010, at 12:06 AM, Pascal = Thubert (pthubert) wrote:

Hi John:
The = Rank is derived from the decision of the parent set, that includes both = DIO parents that optimize the path towards the root and DAO parents that = optimize the path from the root to this = node.
So = the Rank mechanism does not depend whether the metrics are all = bidirectional or if some metrics are unidirectional. The Rank mechanism = belongs to the generic RPL and is designed for loop avoidance, whatever = the specific things the OF does with the metrics of the = day.

I = thought we'd gone over this: this can't be true. The rules in RPL in = Rank adjustment means that Rank generally comes first in parent set = selection. This is part of why we agreed to increase Rank to 16 bits, in = order to allow it to better represent metrics as = necessary.

 
If you really need to have the = rank represent finely the metrics cost, and the metrics are really = assymetrical, then probably you want 2 DAGs, one for which the RANK = increment is mostly derived from the up metrics and one for which it is = mostly derived from the down = metrics.

I= totally disagree -- this seems completely backwards. You're suggesting = that my TCP packets from A->B traverse one DAG while B->A traverse = another?

 
Mukul=92s point stands. = Sometimes, the Rank increment for the parent-child link depends on = metrics that are available at the parent after communication from the = child, so we might have a chicken and an egg problem in the parent = selection. I think we need to refine our text on the link evaluation = with candidate neighbors that enables a neighbor to become a candidate = parent in the first place. =  

The = child gets to pick the parent. Note that link metrics can persist across = DODAG iterations. I'm not sure I understand the = problem?

Phil
= --Apple-Mail-10--345389401-- From jeonggil.ko@gmail.com Wed Mar 31 00:24: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 2069F3A69A8 for ; Wed, 31 Mar 2010 00:24:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.228 X-Spam-Level: X-Spam-Status: No, score=0.228 tagged_above=-999 required=5 tests=[AWL=0.207, BAYES_05=-1.11, DNS_FROM_OPENWHOIS=1.13, 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 7c0atxejF1y0 for ; Wed, 31 Mar 2010 00:24:57 -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 4EC233A6AEE for ; Wed, 31 Mar 2010 00:23:52 -0700 (PDT) Received: by vws9 with SMTP id 9so1289891vws.31 for ; Wed, 31 Mar 2010 00:24:20 -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:message-id:references:to :x-mailer; bh=VYwi6C/ol90hPXr+UuErXQv60myCUJTjr09Sj+En5R0=; b=sq3FlDZCiCK6mf/p1AQaKpiuZtV9Xl0hp8beIBbzI4URQpmwFPweMjciUltjxKYWl3 apMAWwPZemczYuaRfsgfWZfKmMZx1EtXKG+YTADFFR8KCIK/w0eKsQWX9c3tGoC8jgXa 6EUhiOeqePw+p8TbX1ReFv3TlKG+YNp1ghwLk= 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 :message-id:references:to:x-mailer; b=q6SNyIMItWDfFt7rYkOvszf6mL/ViRs9G0RF5M9GfU6LXWvF4th9WPb2QCMl4kMq3F XqnW71PTknqPgJm5XmipXZ/Qo4zqv3KBY3rDPmz363dGH1A1hCDwulw9r7mQ6ngl1IkN y6oswDEtk61Rf94OwDyCzsxEukeVBVtHMGNUs= Received: by 10.220.107.71 with SMTP id a7mr1186388vcp.111.1270020260265; Wed, 31 Mar 2010 00:24:20 -0700 (PDT) Received: from [192.168.1.103] ([76.14.51.89]) by mx.google.com with ESMTPS id 25sm137793584vws.1.2010.03.31.00.24.17 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 31 Mar 2010 00:24:19 -0700 (PDT) Sender: "JeongGil (John) Ko" Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: multipart/alternative; boundary=Apple-Mail-706--344720232 From: "JeongGil Ko (John)" In-Reply-To: <6A2A459175DABE4BB11DE2026AA50A5D0192352A@XMB-AMS-107.cisco.com> Date: Wed, 31 Mar 2010 00:24:15 -0700 Message-Id: <73660B5D-8B98-4686-8090-B58B8F05C948@cs.jhu.edu> 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> <6A2A459175DABE4BB11DE2026AA50A5D0192352A@XMB-AMS-107.cisco.com> To: Pascal Thubert (pthubert) X-Mailer: Apple Mail (2.1078) 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 07:24:59 -0000 --Apple-Mail-706--344720232 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Jonathan, I can see how we can play with the DIOs having both upwards = and downwards rank values (or just the upwards in some cases). Thanks = for the clarification! Pascal, this email confuses me. I can understand up to Jonathan and = Robert's emails and see how that proposal would work but with this email = I am suddenly confused. Shouldn't rank be a representation of the = metrics that I am using (e.g., ETX in my implementation). Why does the = argument on rank not representing metric costs suddenly come up? Are you = talking about the case where the OFs for computing downwards and upwards = routes are different and the DIO metric container can only carry one at = a time? Thanks. -John On Mar 31, 2010, at 12:06 AM, Pascal Thubert (pthubert) wrote: > Hi John: > =20 > The Rank is derived from the decision of the parent set, that includes = both DIO parents that optimize the path towards the root and DAO parents = that optimize the path from the root to this node. > =20 > So the Rank mechanism does not depend whether the metrics are all = bidirectional or if some metrics are unidirectional. The Rank mechanism = belongs to the generic RPL and is designed for loop avoidance, whatever = the specific things the OF does with the metrics of the day. > =20 > If you really need to have the rank represent finely the metrics cost, = and the metrics are really assymetrical, then probably you want 2 DAGs, = one for which the RANK increment is mostly derived from the up metrics = and one for which it is mostly derived from the down metrics. > =20 > Mukul=92s point stands. Sometimes, the Rank increment for the = parent-child link depends on metrics that are available at the parent = after communication from the child, so we might have a chicken and an = egg problem in the parent selection. I think we need to refine our text = on the link evaluation with candidate neighbors that enables a neighbor = to become a candidate parent in the first place. =20 > =20 > Pascal > =20 > From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf = Of JeongGil Ko (John) > Sent: Wednesday, March 31, 2010 5:27 AM > To: Jonathan Hui > Cc: roll@ietf.org > Subject: Re: [Roll] proposal for DAOs in non-caching DODAGs > =20 > =20 > On Mar 30, 2010, at 7:18 PM, Jonathan Hui wrote: >=20 >=20 >=20 > On Mar 30, 2010, at 3:38 PM, Roger Alexander wrote: >=20 > 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. > =20 > 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. >=20 >=20 > 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. >=20 > =20 > So let me see if I got it correctly. A DIO will contain the rank = information for both downwards 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 :) > =20 > -John >=20 >=20 > 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. >=20 > -- > Jonathan Hui >=20 > =20 --Apple-Mail-706--344720232 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Jonathan, I can see how we can play with the = DIOs having both upwards and downwards rank values (or just the upwards = in some cases). Thanks for the clarification!

Pascal, = this email confuses me. I can understand up to Jonathan and Robert's = emails and see how that proposal would work but with this email I am = suddenly confused. Shouldn't rank be a representation of the metrics = that I am using (e.g., ETX in my implementation). Why does the argument = on rank not representing metric costs suddenly come up? Are you talking = about the case where the OFs for computing downwards and upwards routes = are different and the DIO metric container can only carry one at a = time?

Thanks.

-John


On Mar 31, 2010, at 12:06 AM, Pascal = Thubert (pthubert) wrote:

Hi John:
The = Rank is derived from the decision of the parent set, that includes both = DIO parents that optimize the path towards the root and DAO parents that = optimize the path from the root to this = node.
So = the Rank mechanism does not depend whether the metrics are all = bidirectional or if some metrics are unidirectional. The Rank mechanism = belongs to the generic RPL and is designed for loop avoidance, whatever = the specific things the OF does with the metrics of the = day.
If = you really need to have the rank represent finely the metrics cost, and = the metrics are really assymetrical, then probably you want 2 DAGs, one = for which the RANK increment is mostly derived from the up metrics and = one for which it is mostly derived from the down = metrics.
Pascal
 roll-bounces@ietf.org [mailto:roll-bounces@ietf.org= ] On Behalf Of JeongGil Ko = (John)
Sent: Wednesday, March 31, 2010 = 5:27 AM
To: Jonathan = Hui
Cc: roll@ietf.org
Subject: Re: [Roll] proposal for = DAOs in non-caching DODAGs
 
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
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 the rank information for both downwards 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

In-Reply-To: <73660B5D-8B98-4686-8090-B58B8F05C948@cs.jhu.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] proposal for DAOs in non-caching DODAGs Thread-Index: AcrQozLw+ZaIpsz1T/mHyp62MRacEQAAjavw 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> <6A2A459175DABE4BB11DE2026AA50A5D0192352A@XMB-AMS-107.cisco.com> <73660B5D-8B98-4686-8090-B58B8F05C948@cs.jhu.edu> From: "Pascal Thubert (pthubert)" To: "JeongGil Ko (John)" X-OriginalArrivalTime: 31 Mar 2010 07:51:54.0468 (UTC) FILETIME=[07EEB240:01CAD0A7] 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 07:51:37 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CAD0A7.078577E4 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi John: =20 This discussion comes from the fact that your Rank has to be higher than the Rank of all your parents. Say you pick a number of parents for going up, and that results in a Rank that represents more or less a given ETX. But then, none of those parents is good enough for the way back. What do you do? =20 You have to pick a DAO parent that's not one of those parents. And it might happen that this DAO parent has a Rank that's a lot higher than the one you would have calculated otherwise. Guess what, you end up with a Rank that has to grow and stretch away from the real ETX upwards. =20 Or you make 2 DAGs. =20 Pascal =20 From: JeongGil (John) Ko [mailto:jeonggil.ko@gmail.com] On Behalf Of JeongGil Ko (John) Sent: Wednesday, March 31, 2010 9:24 AM To: Pascal Thubert (pthubert) Cc: Jonathan Hui; roll@ietf.org Subject: Re: [Roll] proposal for DAOs in non-caching DODAGs =20 Jonathan, I can see how we can play with the DIOs having both upwards and downwards rank values (or just the upwards in some cases). Thanks for the clarification! =20 Pascal, this email confuses me. I can understand up to Jonathan and Robert's emails and see how that proposal would work but with this email I am suddenly confused. Shouldn't rank be a representation of the metrics that I am using (e.g., ETX in my implementation). Why does the argument on rank not representing metric costs suddenly come up? Are you talking about the case where the OFs for computing downwards and upwards routes are different and the DIO metric container can only carry one at a time? =20 Thanks. =20 -John =20 =20 On Mar 31, 2010, at 12:06 AM, Pascal Thubert (pthubert) wrote: Hi John: =20 The Rank is derived from the decision of the parent set, that includes both DIO parents that optimize the path towards the root and DAO parents that optimize the path from the root to this node. =20 So the Rank mechanism does not depend whether the metrics are all bidirectional or if some metrics are unidirectional. The Rank mechanism belongs to the generic RPL and is designed for loop avoidance, whatever the specific things the OF does with the metrics of the day. =20 If you really need to have the rank represent finely the metrics cost, and the metrics are really assymetrical, then probably you want 2 DAGs, one for which the RANK increment is mostly derived from the up metrics and one for which it is mostly derived from the down metrics. =20 Mukul's point stands. Sometimes, the Rank increment for the parent-child link depends on metrics that are available at the parent after communication from the child, so we might have a chicken and an egg problem in the parent selection. I think we need to refine our text on the link evaluation with candidate neighbors that enables a neighbor to become a candidate parent in the first place. =20 =20 Pascal =20 From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of JeongGil Ko (John) Sent: Wednesday, March 31, 2010 5:27 AM To: Jonathan Hui Cc: roll@ietf.org Subject: Re: [Roll] proposal for DAOs in non-caching DODAGs =20 =20 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. =20 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. =20 So let me see if I got it correctly. A DIO will contain the rank information for both downwards 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 :) =20 -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 =20 =20 =20 ------_=_NextPart_001_01CAD0A7.078577E4 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi John:

 

This discussion comes from the fact that your Rank has to be higher = than the Rank of all your parents.

Say you pick a number of parents for going up, and that results in a = Rank that represents more or less a given ETX.

But then, none of those parents is good enough for the way back. What = do you do?

 

You have to pick a DAO parent that’s not one of those parents. = And it might happen that this DAO parent has a Rank that’s a lot = higher than the one you would have calculated = otherwise.

Guess what, you end up with a Rank that has to grow and stretch away = from the real  ETX upwards.

 

Or you make 2 DAGs.

 

Pascal

 

From:= JeongGil = (John) Ko [mailto:jeonggil.ko@gmail.com] On Behalf Of JeongGil Ko = (John)
Sent: Wednesday, March 31, 2010 9:24 AM
To: = Pascal Thubert (pthubert)
Cc: Jonathan Hui; = roll@ietf.org
Subject: Re: [Roll] proposal for DAOs in = non-caching DODAGs

 

Jonathan, I can see how we can play with the DIOs = having both upwards and downwards rank values (or just the upwards in = some cases). Thanks for the clarification!

 

Pascal, this email confuses me. I can understand up to = Jonathan and Robert's emails and see how that proposal would work but = with this email I am suddenly confused. Shouldn't rank be a = representation of the metrics that I am using (e.g., ETX in my = implementation). Why does the argument on rank not representing metric = costs suddenly come up? Are you talking about the case where the OFs for = computing downwards and upwards routes are different and the DIO metric = container can only carry one at a time?

 

Thanks.

 

-John

 

 

On = Mar 31, 2010, at 12:06 AM, Pascal Thubert (pthubert) = wrote:



Hi John:

 

The Rank is derived from the decision of the parent set, that = includes both DIO parents that optimize the path towards the root and = DAO parents that optimize the path from the root to this = node.

 

So the Rank mechanism does not depend whether the metrics are all = bidirectional or if some metrics are unidirectional. The Rank mechanism = belongs to the generic RPL and is designed for loop avoidance, whatever = the specific things the OF does with the metrics of the = day.

 

If you really need to have the rank represent finely the metrics = cost, and the metrics are really assymetrical, then probably you want 2 = DAGs, one for which the RANK increment is mostly derived from the up = metrics and one for which it is mostly derived from the down = metrics.

 

Mukul’s point stands. Sometimes, the Rank increment for the = parent-child link depends on metrics that are available at the parent = after communication from the child, so we might have a chicken and an = egg problem in the parent selection. I think we need to refine our text = on the link evaluation with candidate neighbors that enables a neighbor = to become a candidate parent in the first place. =  

 

Pascal

 

From:=  roll-bounces@ietf.org [mailto:roll-bounces@ietf.org]=  On Behalf Of JeongGil Ko = (John)
Sent: Wednesday, March 31, 2010 = 5:27 AM
To: Jonathan = Hui
Cc: roll@ietf.org
Subject: Re: [Roll] proposal for DAOs = in non-caching DODAGs

 

 

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 the rank information for = both downwards 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<= /span>




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

 

 

 

------_=_NextPart_001_01CAD0A7.078577E4-- From jeonggil.ko@gmail.com Wed Mar 31 01:11: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 4F9803A6784 for ; Wed, 31 Mar 2010 01:11:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.558 X-Spam-Level: X-Spam-Status: No, score=-0.558 tagged_above=-999 required=5 tests=[AWL=0.910, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, 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 pcU2rTZli03z for ; Wed, 31 Mar 2010 01:11:39 -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 2C71B3A67A7 for ; Wed, 31 Mar 2010 01:11:39 -0700 (PDT) Received: by vws9 with SMTP id 9so1302206vws.31 for ; Wed, 31 Mar 2010 01:12:06 -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:message-id:references:to :x-mailer; bh=O/OstlJAeAky9hHqua7KBsgPr2w1NV/VDGfzEhvYHEI=; b=Rim07PyFtmwuIkBIIekMPPYMvLQwfe4VQQRWrsiw6k8KgYjveZSOvr4gmZu9VYOskq lgtgeIQAScc8oUdXKdkU46Gs/2+hMuXcgIZaIDzn7tZVcO1gbEhZhiqV+IU2RqP0YwHQ rg0tll0K8ciFwJOi6UuxO6PiwbIzcpcHDf8uM= 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 :message-id:references:to:x-mailer; b=bi+nvziXIJdxv4WKcI6jVk1j6ih2K1bs1hqpNzRBTETpw0LGq10e7rS6JVyncqS0qt WC9/Ns7HeUIFEfnEeR9QQRflx+fd9+Cm09875WNs5RObjawvFqntPi4JBhc/Vj0Nb8ze 6hPQplU2PGlW2Twqirrhv8/K3V5x2SnOhvwMg= Received: by 10.220.107.94 with SMTP id a30mr3922940vcp.135.1270023126090; Wed, 31 Mar 2010 01:12:06 -0700 (PDT) Received: from [192.168.1.103] ([76.14.51.89]) by mx.google.com with ESMTPS id 21sm138586556vws.2.2010.03.31.01.12.03 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 31 Mar 2010 01:12:05 -0700 (PDT) Sender: "JeongGil (John) Ko" Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: multipart/alternative; boundary=Apple-Mail-896--341854147 From: "JeongGil Ko (John)" In-Reply-To: <6A2A459175DABE4BB11DE2026AA50A5D0192355B@XMB-AMS-107.cisco.com> Date: Wed, 31 Mar 2010 01:12:01 -0700 Message-Id: <8321E8BA-9511-4227-8372-6B55EE65B6B5@cs.jhu.edu> 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> <6A2A459175DABE4BB11DE2026AA50A5D0192352A@XMB-AMS-107.cisco.com> <73660B5D-8B98-4686-8090-B58B8F05C948@cs.jhu.edu> <6A2A459175DABE4BB11DE2026AA50A5D0192355B@XMB-AMS-107.cisco. com> To: Pascal Thubert (pthubert) X-Mailer: Apple Mail (2.1078) 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 08:11:42 -0000 --Apple-Mail-896--341854147 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Pascal, On Mar 31, 2010, at 12:51 AM, Pascal Thubert (pthubert) wrote: > Hi John: > =20 > This discussion comes from the fact that your Rank has to be higher = than the Rank of all your parents. > Say you pick a number of parents for going up, and that results in a = Rank that represents more or less a given ETX. > But then, none of those parents is good enough for the way back. What = do you do? Honestly, I don't think I understand what scenario you are talking about = here. a node will select DAG parents that have lower DIO ranks than the = node itself. These DIO ranks are computed with the link quality (e.g., = etx) of the 'uplink' connection. What do you mean by "none of those = parents is good enough for the way back"? Are you trying to imply that = in some cases the downwards link quality can be different from the = upwards connection? This should be addressable with what I explain = below.=20 To my understanding in Jonathan and Robert's discussions, there MAY be a = separate rank value computed for the downwards links that helps the = selection of "downwards path parents". So one rank value is computed = using the uplink quality (this would be used to compute the DAG rank and = DAG parent set) and the other is computed using the downlink quality = (used to compute the downwards rank and downwards path parent set). This = downwards path parent set is reported to the root where the DAG topology = can be reconstructed and used to form a source route to a specific = destination from the root (we have the rank information for the = downwards path so the root can construct a loop-free and 'effective' = path to the target node). Because this downwards path parent set is = computed with downwards link quality, the downwards path parent set can = be an effective way to reconstruct the path. Does this not make sense = for any reason? Please correct me if I have something wrong. Thanks. -John > =20 > You have to pick a DAO parent that=92s not one of those parents. And = it might happen that this DAO parent has a Rank that=92s a lot higher = than the one you would have calculated otherwise. > Guess what, you end up with a Rank that has to grow and stretch away = from the real ETX upwards. > =20 > Or you make 2 DAGs. > =20 > Pascal > =20 > From: JeongGil (John) Ko [mailto:jeonggil.ko@gmail.com] On Behalf Of = JeongGil Ko (John) > Sent: Wednesday, March 31, 2010 9:24 AM > To: Pascal Thubert (pthubert) > Cc: Jonathan Hui; roll@ietf.org > Subject: Re: [Roll] proposal for DAOs in non-caching DODAGs > =20 > Jonathan, I can see how we can play with the DIOs having both upwards = and downwards rank values (or just the upwards in some cases). Thanks = for the clarification! > =20 > Pascal, this email confuses me. I can understand up to Jonathan and = Robert's emails and see how that proposal would work but with this email = I am suddenly confused. Shouldn't rank be a representation of the = metrics that I am using (e.g., ETX in my implementation). Why does the = argument on rank not representing metric costs suddenly come up? Are you = talking about the case where the OFs for computing downwards and upwards = routes are different and the DIO metric container can only carry one at = a time? > =20 > Thanks. > =20 > -John > =20 > =20 > On Mar 31, 2010, at 12:06 AM, Pascal Thubert (pthubert) wrote: >=20 >=20 > Hi John: > =20 > The Rank is derived from the decision of the parent set, that includes = both DIO parents that optimize the path towards the root and DAO parents = that optimize the path from the root to this node. > =20 > So the Rank mechanism does not depend whether the metrics are all = bidirectional or if some metrics are unidirectional. The Rank mechanism = belongs to the generic RPL and is designed for loop avoidance, whatever = the specific things the OF does with the metrics of the day. > =20 > If you really need to have the rank represent finely the metrics cost, = and the metrics are really assymetrical, then probably you want 2 DAGs, = one for which the RANK increment is mostly derived from the up metrics = and one for which it is mostly derived from the down metrics. > =20 > Mukul=92s point stands. Sometimes, the Rank increment for the = parent-child link depends on metrics that are available at the parent = after communication from the child, so we might have a chicken and an = egg problem in the parent selection. I think we need to refine our text = on the link evaluation with candidate neighbors that enables a neighbor = to become a candidate parent in the first place. =20 > =20 > Pascal > =20 > From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf = Of JeongGil Ko (John) > Sent: Wednesday, March 31, 2010 5:27 AM > To: Jonathan Hui > Cc: roll@ietf.org > Subject: Re: [Roll] proposal for DAOs in non-caching DODAGs > =20 > =20 > On Mar 30, 2010, at 7:18 PM, Jonathan Hui wrote: >=20 >=20 >=20 >=20 > On Mar 30, 2010, at 3:38 PM, Roger Alexander wrote: >=20 >=20 > 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. > =20 > 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. >=20 >=20 > 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. >=20 > =20 > So let me see if I got it correctly. A DIO will contain the rank = information for both downwards 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 :) > =20 > -John >=20 >=20 >=20 > 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. >=20 > -- > Jonathan Hui >=20 > =20 > =20 > =20 ------ JeongGil Ko (John) Ph.D. Student Department of Computer Science Johns Hopkins University http://www.cs.jhu.edu/~jgko --Apple-Mail-896--341854147 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Pascal,

On Mar 31, = 2010, at 12:51 AM, Pascal Thubert (pthubert) wrote:

Hi John:
This = discussion comes from the fact that your Rank has to be higher than the = Rank of all your parents.
Say you pick a number of parents for going up, and = that results in a Rank that represents more or less a given = ETX.
But then, = none of those parents is good enough for the way back. What do you = do?

To my understanding in Jonathan = and Robert's discussions, there MAY be a separate rank value computed = for the downwards links that helps the selection of "downwards path = parents". So one rank value is computed using the uplink quality (this = would be used to compute the DAG rank and DAG parent set) and the other = is computed using the downlink quality (used to compute the downwards = rank and downwards path parent set). This downwards path parent set = is reported to the root where the DAG topology can be reconstructed and = used to form a source route to a specific destination from the root (we = have the rank information for the downwards path so the root can = construct a loop-free and 'effective' path to the target node). Because = this downwards path parent set is computed with downwards link quality, = the downwards path parent set can be an effective way to reconstruct the = path. Does this not make sense for any reason? Please correct me if I = have something = wrong.

Thanks.

-John
 
You have to pick a DAO parent = that=92s not one of those parents. And it might happen that this DAO = parent has a Rank that=92s a lot higher than the one you would have = calculated otherwise.
Guess what, you end up with a Rank that has to grow = and stretch away from the real  ETX = upwards.
Or = you make 2 DAGs.
Pascal
 JeongGil (John) Ko = [mailto:jeonggil.ko@gmail.com] On Behalf Of JeongGil Ko = (John)
Sent: Wednesday, March 31, 2010 = 9:24 AM
To: Pascal Thubert = (pthubert)
Cc: Jonathan Hui; roll@ietf.org
Subject: Re: [Roll] proposal for = DAOs in non-caching DODAGs
 
Jonathan, I can see = how we can play with the DIOs having both upwards and downwards rank = values (or just the upwards in some cases). Thanks for the = clarification!
Pascal, this email = confuses me. I can understand up to Jonathan and Robert's emails and see = how that proposal would work but with this email I am suddenly confused. = Shouldn't rank be a representation of the metrics that I am using (e.g., = ETX in my implementation). Why does the argument on rank not = representing metric costs suddenly come up? Are you talking about the = case where the OFs for computing downwards and upwards routes are = different and the DIO metric container can only carry one at a = time?
On Mar 31, 2010, at 12:06 = AM, Pascal Thubert (pthubert) wrote:


Hi John:
The Rank is derived from the decision of the parent = set, that includes both DIO parents that optimize the path towards the = root and DAO parents that optimize the path from the root to this = node.
So the Rank mechanism does not depend whether the = metrics are all bidirectional or if some metrics are unidirectional. The = Rank mechanism belongs to the generic RPL and is designed for loop = avoidance, whatever the specific things the OF does with the metrics of = the day.
 
If you really need to have the = rank represent finely the metrics cost, and the metrics are really = assymetrical, then probably you want 2 DAGs, one for which the RANK = increment is mostly derived from the up metrics and one for which it is = mostly derived from the down = metrics.
 
Mukul=92s point stands. = Sometimes, the Rank increment for the parent-child link depends on = metrics that are available at the parent after communication from the = child, so we might have a chicken and an egg problem in the parent = selection. I think we need to refine our text on the link evaluation = with candidate neighbors that enables a neighbor to become a candidate = parent in the first place.  
 
From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org= ] On Behalf Of JeongGil Ko = (John)
Sent: Wednesday, March 31, 2010 = 5:27 AM
To: Jonathan = Hui
Cc: roll@ietf.org
Subject: Re: [Roll] proposal for = DAOs in non-caching = DODAGs
 
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 the rank information for both downwards 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 = :)
 



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

 
------
JeongGil Ko = (John)
Ph.D. Student
Department of Computer = Science
Johns Hopkins University
=

= --Apple-Mail-896--341854147-- From pthubert@cisco.com Wed Mar 31 01:47: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 874243A6BD9 for ; Wed, 31 Mar 2010 01:47:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.391 X-Spam-Level: X-Spam-Status: No, score=-7.391 tagged_above=-999 required=5 tests=[AWL=2.077, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, 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 mjYekEOeCgZv for ; Wed, 31 Mar 2010 01:46:58 -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 089F03A6BC5 for ; Wed, 31 Mar 2010 01:46:58 -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: AncFAFupskurR7Hu/2dsb2JhbACBP5lycaYzmR2FAASOIw X-IronPort-AV: E=Sophos;i="4.51,340,1267401600"; d="scan'208,217";a="175064928" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-5.cisco.com with ESMTP; 31 Mar 2010 08:47:28 +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 o2V8lOV2026687; Wed, 31 Mar 2010 08:47:27 GMT Received: from xmb-ams-107.cisco.com ([144.254.74.82]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 31 Mar 2010 10:47:25 +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_01CAD0AE.C922B2A4" Date: Wed, 31 Mar 2010 10:47:22 +0200 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D019235C6@XMB-AMS-107.cisco.com> In-Reply-To: <8321E8BA-9511-4227-8372-6B55EE65B6B5@cs.jhu.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] proposal for DAOs in non-caching DODAGs Thread-Index: AcrQqfkD0E/+ohpLRS2F/j2gcO6SBwAA93oA 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> <6A2A459175DABE4BB11DE2026AA50A5D0192352A@XMB-AMS-107.cisco.com> <73660B5D-8B98-4686-8090-B58B8F05C948@cs.jhu.edu> <6A2A459175DABE4BB11DE2026AA50A5D0192355B@XMB-AMS-107.cisco. com> <83 21E8BA-9511-4227-8372-6B55EE65B6B5@cs.jhu.edu> From: "Pascal Thubert (pthubert)" To: "JeongGil Ko (John)" X-OriginalArrivalTime: 31 Mar 2010 08:47:25.0494 (UTC) FILETIME=[C960ED60:01CAD0AE] 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 08:47:09 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CAD0AE.C922B2A4 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi John: =20 The Rank is what makes the DAG a DAG. If you have 2 Ranks, one up one down, then essentially you have 2 DAGs. =20 You do not select parents that have a lower Rank than yourself. You select parents and then you derive a Rank that is higher than theirs. If your selection includes finding a parent that has a good path down to you, your Rank must be higher than that of that node as well. =20 Usually we mostly care about the way out, so you can have the collection tree state of mind, then probably one of your DIO parents will enable a good enough path back to you, and your rank will probably ressemble ETX. All I'm saying is that it does not have to be the case. =20 Pascal =20 From: JeongGil (John) Ko [mailto:jeonggil.ko@gmail.com] On Behalf Of JeongGil Ko (John) Sent: Wednesday, March 31, 2010 10:12 AM To: Pascal Thubert (pthubert) Cc: Jonathan Hui; roll@ietf.org Subject: Re: [Roll] proposal for DAOs in non-caching DODAGs =20 Pascal, =20 On Mar 31, 2010, at 12:51 AM, Pascal Thubert (pthubert) wrote: Hi John: =20 This discussion comes from the fact that your Rank has to be higher than the Rank of all your parents. Say you pick a number of parents for going up, and that results in a Rank that represents more or less a given ETX. But then, none of those parents is good enough for the way back. What do you do? =20 Honestly, I don't think I understand what scenario you are talking about here. a node will select DAG parents that have lower DIO ranks than the node itself. These DIO ranks are computed with the link quality (e.g., etx) of the 'uplink' connection. What do you mean by "none of those parents is good enough for the way back"? Are you trying to imply that in some cases the downwards link quality can be different from the upwards connection? This should be addressable with what I explain below.=20 =20 To my understanding in Jonathan and Robert's discussions, there MAY be a separate rank value computed for the downwards links that helps the selection of "downwards path parents". So one rank value is computed using the uplink quality (this would be used to compute the DAG rank and DAG parent set) and the other is computed using the downlink quality (used to compute the downwards rank and downwards path parent set). This downwards path parent set is reported to the root where the DAG topology can be reconstructed and used to form a source route to a specific destination from the root (we have the rank information for the downwards path so the root can construct a loop-free and 'effective' path to the target node). Because this downwards path parent set is computed with downwards link quality, the downwards path parent set can be an effective way to reconstruct the path. Does this not make sense for any reason? Please correct me if I have something wrong. =20 Thanks. =20 -John =20 You have to pick a DAO parent that's not one of those parents. And it might happen that this DAO parent has a Rank that's a lot higher than the one you would have calculated otherwise. Guess what, you end up with a Rank that has to grow and stretch away from the real ETX upwards. =20 Or you make 2 DAGs. =20 Pascal =20 From: JeongGil (John) Ko [mailto:jeonggil.ko@gmail.com] On Behalf Of JeongGil Ko (John) Sent: Wednesday, March 31, 2010 9:24 AM To: Pascal Thubert (pthubert) Cc: Jonathan Hui; roll@ietf.org Subject: Re: [Roll] proposal for DAOs in non-caching DODAGs =20 Jonathan, I can see how we can play with the DIOs having both upwards and downwards rank values (or just the upwards in some cases). Thanks for the clarification! =20 Pascal, this email confuses me. I can understand up to Jonathan and Robert's emails and see how that proposal would work but with this email I am suddenly confused. Shouldn't rank be a representation of the metrics that I am using (e.g., ETX in my implementation). Why does the argument on rank not representing metric costs suddenly come up? Are you talking about the case where the OFs for computing downwards and upwards routes are different and the DIO metric container can only carry one at a time? =20 Thanks. =20 -John =20 =20 On Mar 31, 2010, at 12:06 AM, Pascal Thubert (pthubert) wrote: Hi John: =20 The Rank is derived from the decision of the parent set, that includes both DIO parents that optimize the path towards the root and DAO parents that optimize the path from the root to this node. =20 So the Rank mechanism does not depend whether the metrics are all bidirectional or if some metrics are unidirectional. The Rank mechanism belongs to the generic RPL and is designed for loop avoidance, whatever the specific things the OF does with the metrics of the day. =20 If you really need to have the rank represent finely the metrics cost, and the metrics are really assymetrical, then probably you want 2 DAGs, one for which the RANK increment is mostly derived from the up metrics and one for which it is mostly derived from the down metrics. =20 Mukul's point stands. Sometimes, the Rank increment for the parent-child link depends on metrics that are available at the parent after communication from the child, so we might have a chicken and an egg problem in the parent selection. I think we need to refine our text on the link evaluation with candidate neighbors that enables a neighbor to become a candidate parent in the first place. =20 =20 Pascal =20 From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of JeongGil Ko (John) Sent: Wednesday, March 31, 2010 5:27 AM To: Jonathan Hui Cc: roll@ietf.org Subject: Re: [Roll] proposal for DAOs in non-caching DODAGs =20 =20 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. =20 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. =20 So let me see if I got it correctly. A DIO will contain the rank information for both downwards 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 :) =20 -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 =20 =20 =20 =20 ------ JeongGil Ko (John) Ph.D. Student Department of Computer Science Johns Hopkins University http://www.cs.jhu.edu/~jgko =20 ------_=_NextPart_001_01CAD0AE.C922B2A4 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi John:

 

The Rank is what makes the DAG a DAG. If you have 2 Ranks, one up one = down, then essentially you have 2 DAGs.

 

You do not select parents that have a lower Rank than yourself. You = select parents and then you derive a Rank that is higher than theirs. If = your selection includes finding a parent that has a good path down to = you, your Rank must be higher than that of that node as = well.

 

Usually we mostly care about the way out, so you can have the = collection tree state of mind, then probably one of your DIO parents = will enable a good enough path back to you, and your rank will probably = ressemble ETX. All I’m saying is that it does not have to be the = case.

 

Pascal

 

From:= JeongGil = (John) Ko [mailto:jeonggil.ko@gmail.com] On Behalf Of JeongGil Ko = (John)
Sent: Wednesday, March 31, 2010 10:12 AM
To: = Pascal Thubert (pthubert)
Cc: Jonathan Hui; = roll@ietf.org
Subject: Re: [Roll] proposal for DAOs in = non-caching DODAGs

 

Pascal,

 

On Mar 31, 2010, at 12:51 AM, Pascal Thubert = (pthubert) wrote:



Hi John:

 

This discussion comes from the fact that your Rank has to be higher = than the Rank of all your parents.

Say you pick a number of parents for going up, and that results in a = Rank that represents more or less a given = ETX.

But then, none of those parents is good enough for the way back. What = do you do?

 

Honestly, I don't think I understand what scenario you = are talking about here. a node will select DAG parents that have lower = DIO ranks than the node itself. These DIO ranks are computed with the = link quality (e.g., etx) of the 'uplink' connection. What do you mean by = "none of those parents is good enough for the way back"? Are = you trying to imply that in some cases the downwards link quality can be = different from the upwards connection? This should be addressable with = what I explain below. 

 

To my understanding in Jonathan and Robert's = discussions, there MAY be a separate rank value computed for the = downwards links that helps the selection of "downwards path = parents". So one rank value is computed using the uplink quality = (this would be used to compute the DAG rank and DAG parent set) and the = other is computed using the downlink quality (used to compute the = downwards rank and downwards path parent set). This downwards path = parent set is reported to the root where the DAG topology can be = reconstructed and used to form a source route to a specific destination = from the root (we have the rank information for the downwards path so = the root can construct a loop-free and 'effective' path to the target = node). Because this downwards path parent set is computed with downwards = link quality, the downwards path parent set can be an effective way to = reconstruct the path. Does this not make sense for any reason? Please = correct me if I have something wrong.

 

Thanks.

 

-John



 

You have to pick a DAO parent that’s not one of those parents. = And it might happen that this DAO parent has a Rank that’s a lot = higher than the one you would have calculated = otherwise.

Guess what, you end up with a Rank that has to grow and stretch away = from the real  ETX upwards.

 

Or you make 2 DAGs.

 

Pascal

 

From:=  JeongGil = (John) Ko [mailto:jeonggil.ko@gmail.com] On Behalf Of JeongGil Ko = (John)
Sent: Wednesday, March 31, 2010 = 9:24 AM
To: Pascal Thubert = (pthubert)
Cc: Jonathan Hui; roll@ietf.org
Subject: Re: [Roll] proposal for DAOs = in non-caching DODAGs

 

Jonathan, I can see how we can play with the DIOs = having both upwards and downwards rank values (or just the upwards in = some cases). Thanks for the = clarification!

 

Pascal, this email confuses me. I can understand up to = Jonathan and Robert's emails and see how that proposal would work but = with this email I am suddenly confused. Shouldn't rank be a = representation of the metrics that I am using (e.g., ETX in my = implementation). Why does the argument on rank not representing metric = costs suddenly come up? Are you talking about the case where the OFs for = computing downwards and upwards routes are different and the DIO metric = container can only carry one at a = time?

 

Thanks.

 

-John

 

 

On Mar 31, 2010, at 12:06 AM, Pascal Thubert = (pthubert) wrote:




Hi John:

 

The Rank is derived from the decision of the parent set, that = includes both DIO parents that optimize the path towards the root and = DAO parents that optimize the path from the root to this = node.

 

So the Rank mechanism does not depend whether the metrics are all = bidirectional or if some metrics are unidirectional. The Rank mechanism = belongs to the generic RPL and is designed for loop avoidance, whatever = the specific things the OF does with the metrics of the = day.

 

If you really need to have the rank represent finely the metrics = cost, and the metrics are really assymetrical, then probably you want 2 = DAGs, one for which the RANK increment is mostly derived from the up = metrics and one for which it is mostly derived from the down = metrics.

 

Mukul’s point stands. Sometimes, the Rank increment for the = parent-child link depends on metrics that are available at the parent = after communication from the child, so we might have a chicken and an = egg problem in the parent selection. I think we need to refine our text = on the link evaluation with candidate neighbors that enables a neighbor = to become a candidate parent in the first place. =  

 

Pascal

 

From:=  roll-bounces@ietf.org [mailto:roll-bounces@ietf.org]=  On Behalf Of JeongGil Ko = (John)
Sent: Wednesday, March 31, 2010 = 5:27 AM
To: Jonathan = Hui
Cc: roll@ietf.org
Subject: Re: [Roll] proposal for DAOs = in non-caching = DODAGs

 

 

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.

 

<= p class=3DMsoNormal>So let me = see if I got it correctly. A DIO will contain the rank information for = both downwards 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 = :)

 

<= p class=3DMsoNormal>-John<= /span>





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

 

 

 

 

= ------

= JeongGil Ko (John)

= Ph.D. Student

= Department of Computer Science

= Johns Hopkins University

 

------_=_NextPart_001_01CAD0AE.C922B2A4-- From pthubert@cisco.com Wed Mar 31 01:56: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 EC08C3A6968 for ; Wed, 31 Mar 2010 01:56:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.506 X-Spam-Level: X-Spam-Status: No, score=-7.506 tagged_above=-999 required=5 tests=[AWL=1.962, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, 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 tPJ2ZzmvtmeM for ; Wed, 31 Mar 2010 01:56:42 -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 C2E083A692F for ; Wed, 31 Mar 2010 01:56:42 -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: AncFALKrskurR7Hu/2dsb2JhbACBP5lycaYzmRqFAASOIw X-IronPort-AV: E=Sophos;i="4.51,340,1267401600"; d="scan'208,217";a="175068307" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-5.cisco.com with ESMTP; 31 Mar 2010 08:57:12 +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 o2V8vAdh002029; Wed, 31 Mar 2010 08:57: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); Wed, 31 Mar 2010 10:57:00 +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_01CAD0B0.2025F24A" Date: Wed, 31 Mar 2010 10:56:58 +0200 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D019235D3@XMB-AMS-107.cisco.com> In-Reply-To: <7C1C35FC-0FA6-4F65-B045-D8BDEF2B30CF@cs.stanford.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] proposal for DAOs in non-caching DODAGs Thread-Index: AcrQoZ8qwDzoI4iKRX6eApzl6UmHwgADTAGg 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> <6A2A459175DABE4BB11DE2026AA50A5D0192352A@XMB-AMS-107.cisco.com> <7C1C35FC-0FA6-4F65-B045-D8BDEF2B30CF@cs.stanford.edu> From: "Pascal Thubert (pthubert)" To: "Philip Levis" X-OriginalArrivalTime: 31 Mar 2010 08:57:00.0811 (UTC) FILETIME=[204B55B0:01CAD0B0] 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 08:56:49 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CAD0B0.2025F24A Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Phil =20 Pascal =20 From: Philip Levis [mailto:pal@cs.stanford.edu]=20 Sent: Wednesday, March 31, 2010 9:13 AM To: Pascal Thubert (pthubert) Cc: JeongGil Ko (John); Jonathan Hui; roll@ietf.org Subject: Re: [Roll] proposal for DAOs in non-caching DODAGs =20 =20 On Mar 31, 2010, at 12:06 AM, Pascal Thubert (pthubert) wrote: Hi John: =20 The Rank is derived from the decision of the parent set, that includes both DIO parents that optimize the path towards the root and DAO parents that optimize the path from the root to this node. =20 So the Rank mechanism does not depend whether the metrics are all bidirectional or if some metrics are unidirectional. The Rank mechanism belongs to the generic RPL and is designed for loop avoidance, whatever the specific things the OF does with the metrics of the day. =20 I thought we'd gone over this: this can't be true. The rules in RPL in Rank adjustment means that Rank generally comes first in parent set selection. This is part of why we agreed to increase Rank to 16 bits, in order to allow it to better represent metrics as necessary. [Pascal] When you can do that, well that's fine. Typically for the collection tree I'd think. I already elaborated with John on why the parent selection on the way back might blur this optimistic vision. =20 If you really need to have the rank represent finely the metrics cost, and the metrics are really assymetrical, then probably you want 2 DAGs, one for which the RANK increment is mostly derived from the up metrics and one for which it is mostly derived from the down metrics. =20 I totally disagree -- this seems completely backwards. You're suggesting that my TCP packets from A->B traverse one DAG while B->A traverse another? =20 [Pascal] Welcome to the Internet. Whatever you do, there is a large probability that the way back is not the way in. Note that whether you make 1 or 2 DAGs, as soon as you have different metrics for upwards and downwards you get a different path. Mukul's point stands. Sometimes, the Rank increment for the parent-child link depends on metrics that are available at the parent after communication from the child, so we might have a chicken and an egg problem in the parent selection. I think we need to refine our text on the link evaluation with candidate neighbors that enables a neighbor to become a candidate parent in the first place. =20 =20 The child gets to pick the parent. Note that link metrics can persist across DODAG iterations. I'm not sure I understand the problem? =20 [Pascal] If the child needs link metrics that the parent gathers upon messages from the child, then the parent cannot place them in the first mcast DIO. Some unicast communication must come first to assert the link quality and exchange the perceptions from both ends. At that point, the candidate neighbor becomes a candidate parent. In 07 and I think we lost a lot of that discussion and se do not even define what candidate parents and neighbors are. I think we need a few words to explain what we expect from the out-of-scope neighboring mechanism that does a metric aware NUD of some form. =20 =20 Pascal ------_=_NextPart_001_01CAD0B0.2025F24A Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Phil

 

Pascal

 

From:= Philip = Levis [mailto:pal@cs.stanford.edu]
Sent: Wednesday, March 31, = 2010 9:13 AM
To: Pascal Thubert (pthubert)
Cc: = JeongGil Ko (John); Jonathan Hui; roll@ietf.org
Subject: Re: = [Roll] proposal for DAOs in non-caching = DODAGs

 

 

On = Mar 31, 2010, at 12:06 AM, Pascal Thubert (pthubert) = wrote:



Hi John:

 

The Rank is derived from the decision of the parent set, that = includes both DIO parents that optimize the path towards the root and = DAO parents that optimize the path from the root to this = node.

 

So the Rank mechanism does not depend whether the metrics are all = bidirectional or if some metrics are unidirectional. The Rank mechanism = belongs to the generic RPL and is designed for loop avoidance, whatever = the specific things the OF does with the metrics of the = day.

 

I = thought we'd gone over this: this can't be true. The rules in RPL in = Rank adjustment means that Rank generally comes first in parent set = selection. This is part of why we agreed to increase Rank to 16 bits, in = order to allow it to better represent metrics as = necessary.



[Pascal] When you can do that, well that’s fine. Typically for = the collection tree I‘d think. I already elaborated with John on = why the parent selection on the way back might blur this optimistic = vision.

 

If you really need to have the rank represent finely the metrics = cost, and the metrics are really assymetrical, then probably you want 2 = DAGs, one for which the RANK increment is mostly derived from the up = metrics and one for which it is mostly derived from the down = metrics.

 

I = totally disagree -- this seems completely backwards. You're suggesting = that my TCP packets from A->B traverse one DAG while B->A traverse = another?

 

[Pascal] Welcome to the Internet. Whatever you do, there is a large = probability that the way back is not the way in. Note that whether you = make 1 or 2 DAGs, as soon as you have different metrics for upwards and = downwards you get  a different = path.



Mukul’s point stands. Sometimes, the Rank increment for the = parent-child link depends on metrics that are available at the parent = after communication from the child, so we might have a chicken and an = egg problem in the parent selection. I think we need to refine our text = on the link evaluation with candidate neighbors that enables a neighbor = to become a candidate parent in the first place. =  

 

The child gets to pick the parent. Note that link = metrics can persist across DODAG iterations. I'm not sure I understand = the problem?

 

[Pascal] If the child needs link metrics that the parent gathers upon = messages from the child, then the parent cannot place them in the first = mcast DIO. Some unicast communication must come first to assert the link = quality and exchange the perceptions from both ends. At that point, the = candidate neighbor becomes a candidate parent. In 07 and I think we lost = a lot of that discussion and se do not even define what candidate = parents and neighbors are. I think we need a few words to explain what = we expect from the out-of-scope neighboring mechanism that does a metric = aware NUD of some form.

 

 

Pascal

------_=_NextPart_001_01CAD0B0.2025F24A-- From pthubert@cisco.com Wed Mar 31 02:27: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 1E5EE3A67AD for ; Wed, 31 Mar 2010 02:27:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.61 X-Spam-Level: X-Spam-Status: No, score=-7.61 tagged_above=-999 required=5 tests=[AWL=1.859, 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 1EzFpWNxZ1uY for ; Wed, 31 Mar 2010 02:27:45 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 7679A3A6888 for ; Wed, 31 Mar 2010 02:27:44 -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: AroBAL+yskuQ/uCWe2dsb2JhbACbMRUBAQsLIgYcpjOZF4UABI4j X-IronPort-AV: E=Sophos;i="4.51,340,1267401600"; d="scan'208";a="58787158" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 31 Mar 2010 09:28:13 +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 o2V9SDss013464; Wed, 31 Mar 2010 09:28:13 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); Wed, 31 Mar 2010 11:28:13 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 31 Mar 2010 11:28:09 +0200 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D01923609@XMB-AMS-107.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] Mixed mode operation Thread-Index: AcrQKvEGIpFS3PUXRlKSVubLtRT/ugAhsdCA 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> <93B6031E-ECE1-4C63-848C-1C43B48F69C8@cs.stanford.edu> <6A2A459175DABE4BB11DE2026AA50A5D0188AF9F@XMB-AMS-107.cisco.com> From: "Pascal Thubert (pthubert)" To: "Philip Levis" X-OriginalArrivalTime: 31 Mar 2010 09:28:13.0807 (UTC) FILETIME=[7CAFD7F0:01CAD0B4] 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, 31 Mar 2010 09:27:46 -0000 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 enough capacity 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 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 probably failing short when the capacity problem is the routing table in a node hops 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 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 the child can select an alternate parent for that DAO and the light will come up. This is the bare minimum we can do. We already have an issue on this 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 >=20 > On Mar 29, 2010, at 11:35 PM, Pascal Thubert (pthubert) wrote: >=20 > > Hi: > > > > As Phil said the anti-replay came up in Anaheim. This 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 > > appropriately (too small) just causes permanent look ups that > > 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 becomes a > > deployment issue. Usually what we address there is the bandwidth > > capacity on the root radio space. In this thread, the 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 capacity needs is > > probably divide and conquer, and nothing will replace a proper > > capacity planning overall. > > > > RPL enables DAGs that are made of multiple DODAGs. RPL enables the > > radio roots to be connected to a backbone, with a super-root there if > > you want a single DODAG. RPL dynamically adapts to the addition or the > > removal of a root in an instance so adapting the capacity to new > > requirements has only a local impact on the network. It also adapts > > dynamically to the addition of a parent in the DODAG to 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 > > somewhere, then we might have an issue with the parent selection. At > > the moment, a parent cannot indicate the capacity of its routing > > 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 > > pushback mechanism from the nodes where the capacity is 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. >=20 > I really think this is outside the protocol 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 implementation-specific decision. At the very > least, it should be outside the core specification. >=20 > It's an operational/administrative issue: if the network's routing tables are > overloaded, add another root. Rank and incrementing DODAG sequence > numbers are a perfectly reasonable way to achieve this. We don't need > additional complexity. >=20 > Phil From pthubert@cisco.com Wed Mar 31 02:56: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 60D1A3A6841 for ; Wed, 31 Mar 2010 02:56:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.703 X-Spam-Level: X-Spam-Status: No, score=-7.703 tagged_above=-999 required=5 tests=[AWL=1.766, 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 P0JGBHOUu9H4 for ; Wed, 31 Mar 2010 02:56:20 -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 60E483A67AE for ; Wed, 31 Mar 2010 02:56:20 -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: AvsEAMK5skurR7Ht/2dsb2JhbACbMnGmQJkYhQAE X-IronPort-AV: E=Sophos;i="4.51,340,1267401600"; d="scan'208";a="175094654" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-5.cisco.com with ESMTP; 31 Mar 2010 09:56:39 +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 o2V9u6u7028677; Wed, 31 Mar 2010 09:56:38 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); Wed, 31 Mar 2010 11:56: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: Wed, 31 Mar 2010 11:56:27 +0200 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D01923636@XMB-AMS-107.cisco.com> In-Reply-To: <8F278AA8-105B-40C8-BC67-A0A5E30B47BE@archrock.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] proposal for DAOs in non-caching DODAGs Thread-Index: AcrQdx8xtYsLd5AUTbulaKdtUVx4RQAKZHIw References: <87vdcg5eis.fsf@kelsey-ws.hq.ember.com> <8F278AA8-105B-40C8-BC67-A0A5E30B47BE@archrock.com> From: "Pascal Thubert (pthubert)" To: "Jonathan Hui" , "Richard Kelsey" X-OriginalArrivalTime: 31 Mar 2010 09:56:31.0443 (UTC) FILETIME=[708E8A30:01CAD0B8] 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 09:56:21 -0000 Hi Jonathan: 100% with you. Richard's broad lines show the way. And we need to refine a bit to make sure that the root has all the hops in all cases. I see actually 2 cases: - In one, all routers are supposed to send their parent set in a DAO. If the root computes a path and finds one hop missing, then that is an inconsistency. The new target option in the DIO can be a powerful toot to fix that inconsistency. - in the other, routers would advertise their parent on demand, that is as soon as they know that they are on the path of at least one source route. I see at least one case where we want to do that, that's when we apply the P2P proposal that we discussed in another DAO thread to source route. In that case, it appears that there is a need to trigger that the parents also send their source route DAO on the way back. It is probably enough to mandate that a parent that forwards a source route DAO makes sure that it also has sent its source route DAO, and if not yet, then it should now. What do you think? Pascal > -----Original Message----- > From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of > Jonathan Hui > Sent: Wednesday, March 31, 2010 4:09 AM > To: Richard Kelsey > Cc: roll@ietf.org > Subject: Re: [Roll] proposal for DAOs in non-caching DODAGs >=20 >=20 > Hi Richard, >=20 > I like the proposal in general, though it does need to be fleshed out a bit > more. Specifically, this works well in the non-storing case if all nodes source > DAOs to the root so that the root can properly construct paths back to any > individual node that is sending DAOs. But is there any desire to allow some > nodes not to source DAOs if they don't need to? If so, we should specify that > a node MUST source DAOs as long as they are forwarding DAOs for > descendants. >=20 > Separately, it might be nice to include a record-route mechanism (not the > same as reverse route stack DAOs) so that nodes that only want to quickly > establish routes can do so without having to possibly wait for all ancestors to > source their own DAOs as well. I've found that record-route works really well > in short request-response transactions, especially in cases where you don't > want to continuously maintain downward routing state. >=20 > -- > Jonathan Hui >=20 > On Mar 28, 2010, at 2:20 PM, Richard Kelsey wrote: >=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. > > > > 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. > > > > 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. > > > > 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. > > > > 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 > > > > What do people think? > > -Richard Kelsey > > _______________________________________________ > > 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 From prvs=699228876=mukul@uwm.edu Wed Mar 31 04:18: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 04C253A6967 for ; Wed, 31 Mar 2010 04:18:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.483 X-Spam-Level: X-Spam-Status: No, score=0.483 tagged_above=-999 required=5 tests=[AWL=0.463, BAYES_05=-1.11, 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 Z1-NeTeDilkN for ; Wed, 31 Mar 2010 04:18:43 -0700 (PDT) Received: from ip2mta.uwm.edu (ip2mta.uwm.edu [129.89.7.20]) by core3.amsl.com (Postfix) with ESMTP id 7671A3A687D for ; Wed, 31 Mar 2010 04:18:40 -0700 (PDT) Received: from mta03.pantherlink.uwm.edu ([129.89.7.83]) by ip2mta.uwm.edu with ESMTP; 31 Mar 2010 06:19:10 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by mta03.pantherlink.uwm.edu (Postfix) with ESMTP id DEC28C085AC; Wed, 31 Mar 2010 06:19:10 -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 oJK3I4ef3uVn; Wed, 31 Mar 2010 06:19:10 -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 60372C085A0; Wed, 31 Mar 2010 06:19:10 -0500 (CDT) Date: Wed, 31 Mar 2010 06:19:10 -0500 (CDT) From: Mukul Goyal To: "Pascal Thubert (pthubert)" Message-ID: <1143143317.1971991270034350013.JavaMail.root@mail02.pantherlink.uwm.edu> In-Reply-To: <6A2A459175DABE4BB11DE2026AA50A5D019235D3@XMB-AMS-107.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Originating-IP: [129.89.7.91] X-Mailer: Zimbra 5.0.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: Wed, 31 Mar 2010 11:18:45 -0000 >>>Mukul=E2=80=99s point stands. Sometimes, the Rank increment for the pare= nt-child link depends on metrics that are available at the parent after com= munication from the child, so we might have a chicken and an egg problem in= the parent selection. I think we need to refine our text on the link evalu= ation with candidate neighbors that enables a neighbor to become a candidat= e parent in the first place. =C2=A0=20 =C2=A0=20 [Phil]The child gets to pick the parent. Note that link metrics can persist= across DODAG iterations. I'm not sure I understand the problem?=20 =C2=A0=20 [Pascal] If the child needs link metrics that the parent gathers upon messa= ges from the child, then the parent cannot place them in the first mcast DI= O. Some unicast communication must come first to assert the link quality an= d exchange the perceptions from both ends. At that point, the candidate nei= ghbor becomes a candidate parent. In 07 and I think we lost a lot of that d= iscussion and se do not even define what candidate parents and neighbors ar= e. I think we need a few words to explain what we expect from the out-of-sc= ope neighboring mechanism that does a metric aware NUD of some form.=20 I totally agree. Mukul=C2=A0=20 =C2=A0=20 Pascal=20 _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From jpv@cisco.com Wed Mar 31 07:08: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 5359A3A68EA for ; Wed, 31 Mar 2010 07:08:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.125 X-Spam-Level: X-Spam-Status: No, score=-8.125 tagged_above=-999 required=5 tests=[AWL=1.344, 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 kEXxiZmaCnyf for ; Wed, 31 Mar 2010 07:08:01 -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 DC7513A6898 for ; Wed, 31 Mar 2010 07:08:00 -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: AvsEAKvzskurR7Ht/2dsb2JhbACbNXGncZkXhQAEjiM X-IronPort-AV: E=Sophos;i="4.51,341,1267401600"; d="scan'208";a="108196286" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-4.cisco.com with ESMTP; 31 Mar 2010 14:08:31 +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 o2VE89B9005556; Wed, 31 Mar 2010 14:08:31 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); Wed, 31 Mar 2010 16:08:30 +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); Wed, 31 Mar 2010 16:08:29 +0200 Message-Id: <3A622CB8-1EAD-4A05-9FA2-217754643D8E@cisco.com> From: JP Vasseur To: Philip Levis , phoebus@ieee.org In-Reply-To: <2DF09A97-3E30-43CA-AF9C-7E18F5AD2D6C@cs.stanford.edu> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Wed, 31 Mar 2010 16:08:29 +0200 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> <93B6031E-ECE1-4C63-848C-1C43B48F69C8@cs.stanford.edu> <6A2A459175DABE4BB11DE2026AA50A5D0188AF9F@XMB-AMS-107.cisco.com> <4D897440-F028-44C9-A02B-4FDED690C1FE@cisco.com> <4BB26A00.5020400@ieee.org> <2DF09A97-3E30-43CA-AF9C-7E18F5AD2D6C@cs.stanford.edu> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 31 Mar 2010 14:08:30.0174 (UTC) FILETIME=[A405CFE0:01CAD0DB] 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, 31 Mar 2010 14:08:02 -0000 Agreeing on all points mentioned here. One more comment though (in line) On Mar 30, 2010, at 11:37 PM, Philip Levis wrote: > > On Mar 30, 2010, at 2:15 PM, Phoebus Chen wrote: > >> JP and Phil, >> >> Umm, are you sure it's a good idea to punt on this issue? Limited >> memory and interoperability has been stressed so much on this >> mailing list. I would hate to be the poor guy trying to debug a >> network where the devices came from different vendors and each had >> a different table eviction policy. Are you going to at least >> specify some sort of a standard error message to send back to the >> root in this situation? The answer to this question is "yes", this will go in the manageability section of the I-D (I'll open a ticket for this), good point. > > I don't think the question is whether to punt; it's whether it's in > the core spec. Please, someone correct me if I'm wrong, but *no > routing protocol today* deals with this issue. Putting a research > question on the critical path seems like a bad idea to me. I mean, I > suppose we could make something up and convince ourselves it's > reasonable, but the history of wireless protocol design has shown us > the success of such ventures. :) > > Keep in mind the situation here: someone has greatly > underprovisioned their network. How would this manifest? A good > implementation is going to limit the amount of energy it spends on > route discovery. If there's routing table churn beyond this budget, > then there won't be routes: ICMPv6 code 1. Getting a report of this > to a management layer lies above RPL. But I think that's where the > answer lies. E.g., in a home automation network, nodes report what > their general routing state is. If it starts to look cramped, then > the home automation network can initialize another node to be a > DODAG root. > >> >> BTW, I support the proposal to just not add new entries if the >> table is full, rather than try to evict different entries. It's >> simpler to understand, and requires less debating on this mailing >> list (since the focus is on other issues right now). It makes >> sense to revisit the issues Pascal brought up later. > > Let's get back to the basic requirement Anders keeps on reiterating: > if I flick a light switch, the light should turn on. What happens if > routing table entries are full? > > Phil > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From trac@tools.ietf.org Wed Mar 31 07:10: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 D6FC93A6876 for ; Wed, 31 Mar 2010 07:10:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.91 X-Spam-Level: X-Spam-Status: No, score=-100.91 tagged_above=-999 required=5 tests=[AWL=0.560, 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 kUvzFXcXB-wj for ; Wed, 31 Mar 2010 07:10:35 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 3E68E3A68EA for ; Wed, 31 Mar 2010 07:10:32 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1NwydL-0003C9-Aw; Wed, 31 Mar 2010 07:11:03 -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: jpv@cisco.com X-Trac-Project: roll Date: Wed, 31 Mar 2010 14:11:03 -0000 X-URL: http://tools.ietf.org/wg/roll/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/roll/trac/ticket/31 Message-ID: <055.3cecd2da0acc069419fbbe68dc942e61@tools.ietf.org> X-Trac-Ticket-ID: 31 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: 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] #31: Update of manageability section 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: Wed, 31 Mar 2010 14:10:36 -0000 #31: Update of manageability section --------------------------------+------------------------------------------- Reporter: jpv@… | Owner: jpv@… Type: task | Status: new Priority: major | Milestone: Component: rpl | Version: Severity: Active WG Document | Keywords: --------------------------------+------------------------------------------- Phoebus> Umm, are you sure it's a good idea to punt on this issue? Limited memory and interoperability has been stressed so much on this mailing list. I would hate to be the poor guy trying to debug a network where the devices came from different vendors and each had a different table eviction policy. Are you going to at least specify some sort of a standard error message to send back to the root in this situation? JP> The answer to this question is "yes", this will go in the manageability section of the I-D (I'll open a ticket for this), good point. -- Ticket URL: roll From richard.kelsey@ember.com Wed Mar 31 07:23: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 A2C8D3A6967 for ; Wed, 31 Mar 2010 07:23:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.169 X-Spam-Level: X-Spam-Status: No, score=-0.169 tagged_above=-999 required=5 tests=[AWL=1.300, 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 AtbCn-Kv-6R7 for ; Wed, 31 Mar 2010 07:23:16 -0700 (PDT) Received: from EMPIRE.hq.ember.com (mail.ember.com [74.10.175.227]) by core3.amsl.com (Postfix) with ESMTP id A91243A6931 for ; Wed, 31 Mar 2010 07:23:16 -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, 31 Mar 2010 10:26:39 -0400 Date: Wed, 31 Mar 2010 10:20:28 -0400 Message-Id: <87vdcc374j.fsf@kelsey-ws.hq.ember.com> To: Jonathan Hui In-reply-to: <03A6E62B-5EF5-497F-98DC-6B38E882918D@archrock.com> (message from Jonathan Hui on Tue, 30 Mar 2010 22:54:01 -0700) From: Richard Kelsey 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> X-OriginalArrivalTime: 31 Mar 2010 14:26:39.0484 (UTC) FILETIME=[2D4D53C0:01CAD0DE] 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 14:23:17 -0000 > From: Jonathan Hui > Date: Tue, 30 Mar 2010 22:54:01 -0700 > > On Mar 30, 2010, at 8:26 PM, JeongGil Ko (John) wrote: > > > On Mar 30, 2010, at 7:18 PM, Jonathan Hui wrote: > > > >> 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 the rank > > information for both downwards 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 :) > > To be more precise, a DIO may contain separate metric information for > upwards and downwards paths (i.e. directional cost metrics) if having > the DAG and DAO parents being different sets is desirable. This makes no sense to me. If you want to optimize two different metrics, in this case the upward and downward costs, you need two separate DODAGs. While you can use two different criteria for DIO parents and DAO parents, both sets need to be parents as defined by the rank in the DIO. The DODAG is going to optimize the metric that determines the rank. Another metric can be used to tweak the DAO parent choice, but it only gets to pick between parents chosen by the rank metric. If the upward and downward link or node qualities diverge enough that one metric won't work for both, then you need two RPL instances. This is no different from optmizing latency and bandwidth, for example. -Richard From richard.kelsey@ember.com Wed Mar 31 07:38: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 7BDEC3A69DA for ; Wed, 31 Mar 2010 07:38:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.494 X-Spam-Level: X-Spam-Status: No, score=-0.494 tagged_above=-999 required=5 tests=[AWL=0.975, 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 EXKhrS9q9X+c for ; Wed, 31 Mar 2010 07:38:49 -0700 (PDT) Received: from EMPIRE.hq.ember.com (mail.ember.com [74.10.175.227]) by core3.amsl.com (Postfix) with ESMTP id 895613A6967 for ; Wed, 31 Mar 2010 07:38:49 -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, 31 Mar 2010 10:42:15 -0400 Date: Wed, 31 Mar 2010 10:36:04 -0400 Message-Id: <87tyrw36ej.fsf@kelsey-ws.hq.ember.com> To: Philip Levis In-reply-to: <7C1C35FC-0FA6-4F65-B045-D8BDEF2B30CF@cs.stanford.edu> (message from Philip Levis on Wed, 31 Mar 2010 00:13:06 -0700) From: Richard Kelsey 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> <6A2A459175DABE4BB11DE2026AA50A5D0192352A@XMB-AMS-107.cisco.com> <7C1C35FC-0FA6-4F65-B045-D8BDEF2B30CF@cs.stanford.edu> X-OriginalArrivalTime: 31 Mar 2010 14:42:15.0781 (UTC) FILETIME=[5B60E950:01CAD0E0] 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 14:38:50 -0000 > From: Philip Levis > Date: Wed, 31 Mar 2010 00:13:06 -0700 > > On Mar 31, 2010, at 12:06 AM, Pascal Thubert (pthubert) wrote: > > > If you really need to have the rank represent finely the metrics cost, > > and the metrics are really assymetrical, then probably you want 2 DAGs, > > one for which the RANK increment is mostly derived from the up metrics > > and one for which it is mostly derived from the down metrics. > > I totally disagree -- this seems completely backwards. You're suggesting > that my TCP packets from A->B traverse one DAG while B->A traverse > another? The whole issue here is dealing with links that work better in one direction than the other. Given the presence of such links, it makes perfect sense that packets in one direction would take a different path than packets in the other. As an example, I can easily imagine low-duty-cycle networks where the nodes' different wake cycles makes links have very different upward and downwards latency. Low latency in such a network would require separate upward and downward routes, chosen by separate RPL instances. In the extreme, if there were a smattering of always-on nodes with links between them having very low latency, you could get links that were traversed in the same direction for both the upwards and downwards paths to a particular node. This clearly requires separate DAGs. Given the way RPL works, it can only use links that have at least some capacity in both directions. Upwards routes require that the downward DIO be received and downwards routes require that the upward DAO be received. -Richard Kelsey From prvs=699228876=mukul@uwm.edu Wed Mar 31 07:48: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 A63E63A68C0 for ; Wed, 31 Mar 2010 07:48:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.328 X-Spam-Level: X-Spam-Status: No, score=-0.328 tagged_above=-999 required=5 tests=[AWL=1.141, 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 3VjdFuULpGtv for ; Wed, 31 Mar 2010 07:48:35 -0700 (PDT) Received: from ip1mta.uwm.edu (ip1mta.uwm.edu [129.89.7.18]) by core3.amsl.com (Postfix) with ESMTP id B628D3A6898 for ; Wed, 31 Mar 2010 07:48:35 -0700 (PDT) Received: from mta03.pantherlink.uwm.edu ([129.89.7.83]) by ip1mta.uwm.edu with ESMTP; 31 Mar 2010 09:49:06 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by mta03.pantherlink.uwm.edu (Postfix) with ESMTP id 4C53AC085D0; Wed, 31 Mar 2010 09:49:06 -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 UgECEKON8vVr; Wed, 31 Mar 2010 09:49:05 -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 BFEB8C085A1; Wed, 31 Mar 2010 09:49:05 -0500 (CDT) Date: Wed, 31 Mar 2010 09:49:05 -0500 (CDT) From: Mukul Goyal To: Richard Kelsey Message-ID: <1146633082.2070561270046945620.JavaMail.root@mail02.pantherlink.uwm.edu> In-Reply-To: <617278889.2062741270046472928.JavaMail.root@mail02.pantherlink.uwm.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [129.89.7.91] X-Mailer: Zimbra 5.0.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: Wed, 31 Mar 2010 14:48:36 -0000 Richard > To be more precise, a DIO may contain separate metric information for > upwards and downwards paths (i.e. directional cost metrics) if having > the DAG and DAO parents being different sets is desirable. [Richard] This makes no sense to me. If you want to optimize two different metrics, in this case the upward and downward costs, you need two separate DODAGs. While you can use two different criteria for DIO parents and DAO parents, both sets need to be parents as defined by the rank in the DIO. The DODAG is going to optimize the metric that determines the rank. Another metric can be used to tweak the DAO parent choice, but it only gets to pick between parents chosen by the rank metric. [Mukul] I think Jonathan was talking about sending both upwards and downwards aggregated/local values for a metric in a DIO. You will agree that these costs could be very different in two directions. Having these directional costs available in the DIO will remove the guess work involved in picking a DAO parent. I agree that both DIO parents and DAO parents are parents and a node's rank should be higher than that of any of its DIO/DAO parent. A rank is a loop avoidance mechanism. It can reflect the upwards costs if you want it to. But it need not. Thanks Mukul _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From richard.kelsey@ember.com Wed Mar 31 08:16: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 A46703A6953 for ; Wed, 31 Mar 2010 08:16:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.689 X-Spam-Level: X-Spam-Status: No, score=-0.689 tagged_above=-999 required=5 tests=[AWL=0.780, 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 YDSfCYK8m1hO for ; Wed, 31 Mar 2010 08:16:28 -0700 (PDT) Received: from EMPIRE.hq.ember.com (mail.ember.com [74.10.175.227]) by core3.amsl.com (Postfix) with ESMTP id 88B113A698B for ; Wed, 31 Mar 2010 08:16:24 -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, 31 Mar 2010 11:19:50 -0400 Date: Wed, 31 Mar 2010 11:13:39 -0400 Message-Id: <87r5n034nw.fsf@kelsey-ws.hq.ember.com> To: Jonathan Hui In-reply-to: <8F278AA8-105B-40C8-BC67-A0A5E30B47BE@archrock.com> (message from Jonathan Hui on Tue, 30 Mar 2010 19:08:42 -0700) From: Richard Kelsey References: <87vdcg5eis.fsf@kelsey-ws.hq.ember.com> <8F278AA8-105B-40C8-BC67-A0A5E30B47BE@archrock.com> X-OriginalArrivalTime: 31 Mar 2010 15:19:50.0578 (UTC) FILETIME=[9B57A120:01CAD0E5] 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 15:16:46 -0000 > From: Jonathan Hui > Date: Tue, 30 Mar 2010 19:08:42 -0700 > > I like the proposal in general, though it does need to be fleshed out > a bit more. I have not gone over the draft to see exactly what changes would be required. If there is enough support for going forward, I will do so. This is all assuming that we stop supporting mixed mode, which will require its own set of changes to the text. > Specifically, this works well in the non-storing case if > all nodes source DAOs to the root so that the root can properly > construct paths back to any individual node that is sending DAOs. But > is there any desire to allow some nodes not to source DAOs if they > don't need to? If so, we should specify that a node MUST source DAOs > as long as they are forwarding DAOs for descendants. The current draft requires that all nodes send DAOs: 13. A node that receives a newly incremented DTSN from a DAO Parent MUST schedule a DAO transmission. If we wanted to relax this, then yes, forwarding a DAO would require that the forwarder also send their own DIO. > Separately, it might be nice to include a record-route mechanism (not > the same as reverse route stack DAOs) so that nodes that only want to > quickly establish routes can do so without having to possibly wait for > all ancestors to source their own DAOs as well. I've found that > record-route works really well in short request-response transactions, > especially in cases where you don't want to continuously maintain > downward routing state. Yes. Would record route go in the RPL draft? I associate it what source route, which apparently cannot be in the RPL draft. -Richard Kelsey From jhui@archrock.com Wed Mar 31 08:28: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 7CBCA3A69E6 for ; Wed, 31 Mar 2010 08:28:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.252 X-Spam-Level: X-Spam-Status: No, score=-1.252 tagged_above=-999 required=5 tests=[AWL=0.217, 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 r6tnUfFloy2k for ; Wed, 31 Mar 2010 08:28:02 -0700 (PDT) Received: from mail.sf.archrock.com (mail.sf.archrock.com [216.121.16.71]) by core3.amsl.com (Postfix) with ESMTP id A1B593A69DA for ; Wed, 31 Mar 2010 08:28:02 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.sf.archrock.com (Postfix) with ESMTP id C6BE3AF920; Wed, 31 Mar 2010 08:28: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 hRicCYIn0dUV; Wed, 31 Mar 2010 08:28: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 289E4AF90F; Wed, 31 Mar 2010 08:28:29 -0700 (PDT) Message-Id: <74BABD6C-D44A-48FD-A636-B65D425CE507@archrock.com> From: Jonathan Hui To: Richard Kelsey In-Reply-To: <87vdcc374j.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: Wed, 31 Mar 2010 08:28:28 -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> 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: Wed, 31 Mar 2010 15:28:03 -0000 On Mar 31, 2010, at 7:20 AM, Richard Kelsey wrote: >> From: Jonathan Hui >> Date: Tue, 30 Mar 2010 22:54:01 -0700 >> >> On Mar 30, 2010, at 8:26 PM, JeongGil Ko (John) wrote: >> >> To be more precise, a DIO may contain separate metric information for >> upwards and downwards paths (i.e. directional cost metrics) if having >> the DAG and DAO parents being different sets is desirable. > > This makes no sense to me. If you want to optimize two > different metrics, in this case the upward and downward > costs, you need two separate DODAGs. While you can use two > different criteria for DIO parents and DAO parents, both > sets need to be parents as defined by the rank in the DIO. > The DODAG is going to optimize the metric that determines > the rank. Another metric can be used to tweak the DAO > parent choice, but it only gets to pick between parents > chosen by the rank metric. > > If the upward and downward link or node qualities diverge > enough that one metric won't work for both, then you need > two RPL instances. This is no different from optmizing > latency and bandwidth, for example. Are you talking about initiating a DODAG from the root and each individual node? Or initiating two DODAGs from the root? I hope you meant the latter. I tried to avoid the subject of how many instances or DODAGs in my prior mail. We all agree that sometimes you want to have different criteria for selecting DAG parents and DAO parents. It gets confusing because a single DODAG is attempting to select both DAG and DAO parents. A single DODAG (as currently written) is responsible for coordinating DIO sequence numbers, triggering DAOs, etc. Today, a DODAG selects both DAG and DAO parents using a set of metrics, an OF, and a single Rank value. I could see a single DODAG approach work by accepting that a DODAG can optimizing for DAG and DAO parents separately if requested to do so. We could make a two DODAG approach work, but you would need some way to tell which DODAG to use for selecting DAG vs. DAO parents. The single DODAG approach seems to make better sense architecturally since a single DODAG is tasked with selecting both DAG and DAO parents. There would be no duplicated effort in selecting the two sets of parents between the two DODAGs. I could also see a two DODAG solution work if we can completely decouple the DAG and DAO parent selection process and eliminate any of the effort, which BTW I've been advocating for a while. -- Jonathan Hui From prvs=699228876=mukul@uwm.edu Wed Mar 31 09:43: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 C97893A6BAB for ; Wed, 31 Mar 2010 09:43:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.737 X-Spam-Level: X-Spam-Status: No, score=0.737 tagged_above=-999 required=5 tests=[AWL=-0.208, BAYES_40=-0.185, 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 V4UPfsNXs87P for ; Wed, 31 Mar 2010 09:43:57 -0700 (PDT) Received: from ip2mta.uwm.edu (ip2mta.uwm.edu [129.89.7.20]) by core3.amsl.com (Postfix) with ESMTP id 4CB203A6BB3 for ; Wed, 31 Mar 2010 09:34:02 -0700 (PDT) Received: from mta03.pantherlink.uwm.edu ([129.89.7.83]) by ip2mta.uwm.edu with ESMTP; 31 Mar 2010 11:34:33 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by mta03.pantherlink.uwm.edu (Postfix) with ESMTP id 1971CC085F5 for ; Wed, 31 Mar 2010 11:34:33 -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 wy2VdttAXbZq for ; Wed, 31 Mar 2010 11:34:32 -0500 (CDT) Received: from mail02.pantherlink.uwm.edu (mail02.pantherlink.uwm.edu [129.89.7.86]) by mta03.pantherlink.uwm.edu (Postfix) with ESMTP id 890ADC085D4 for ; Wed, 31 Mar 2010 11:34:32 -0500 (CDT) Date: Wed, 31 Mar 2010 11:34:32 -0500 (CDT) From: Mukul Goyal To: roll Message-ID: <404399966.2160291270053272403.JavaMail.root@mail02.pantherlink.uwm.edu> In-Reply-To: <6A2A459175DABE4BB11DE2026AA50A5D0188AF9F@XMB-AMS-107.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [129.89.7.91] X-Mailer: Zimbra 5.0.22_GA_3210.RHEL4_64 (ZimbraWebClient - [unknown] (Win)/5.0.22_GA_3210.RHEL4_64) X-Authenticated-User: mukul@uwm.edu 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, 31 Mar 2010 16:43:58 -0000 Catching up on this thread. My main concern was what happens in a storing LLN when a parent can not store the child's DAO. I thought it has to become a leaf. This has consequences in terms of what happens to its children and the fact that it could snowball into a catastrophe: node A becomes a leaf node => reachability information stored in node A now needs to be stored in other nodes (say B and C) and these nodes also dont have memory to store this additional information => nodes B and C become leaf nodes => .... => the network as a whole goes down. But what Pascal is saying is that this is not going to happen because I as a parent can always refuse to accept a child's DAO and still stay a storing router. The child simply finds another parent to store its DAO. The problem occurs only when it cant find another parent to store its DAO or all its parents refuse to store its DAO. Please let me know if this understanding is not correct. Thanks Mukul ----- Forwarded Message ----- From: "Pascal Thubert (pthubert)" To: "Philip Levis" , "Michael Richardson" Cc: "roll" Sent: Tuesday, March 30, 2010 1:35:58 AM GMT -06:00 US/Canada Central Subject: Re: [Roll] Mixed mode operation Hi: As Phil said the anti-replay came up in Anaheim. This 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 appropriately (too small) just causes permanent look ups that 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 becomes a deployment issue. Usually what we address there is the bandwidth capacity on the root radio space. In this thread, the 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 capacity needs is probably divide and conquer, and nothing will replace a proper capacity planning overall. RPL enables DAGs that are made of multiple DODAGs. RPL enables the radio roots to be connected to a backbone, with a super-root there if you want a single DODAG. RPL dynamically adapts to the addition or the removal of a root in an instance so adapting the capacity to new requirements has only a local impact on the network. It also adapts dynamically to the addition of a parent in the DODAG to 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 somewhere, then we might have an issue with the parent selection. At the moment, a parent cannot indicate the capacity of its routing 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 pushback mechanism from the nodes where the capacity is 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. Pascal > -----Original Message----- > From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of > Philip Levis > Sent: Tuesday, March 30, 2010 4:27 AM > To: Michael Richardson > Cc: 'roll' > Subject: Re: [Roll] Mixed mode operation > > > On Mar 29, 2010, at 6:26 PM, 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. > > > > 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 came up in Anaheim; one approach to defending from this is requiring a > node to respond to a nonce before handling its packets (e.g., inserting a > routing table entry). There are of course timeliness issues, etc. > > 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 richard.kelsey@ember.com Wed Mar 31 09:49: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 42F9E3A6B7B for ; Wed, 31 Mar 2010 09:49:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.819 X-Spam-Level: X-Spam-Status: No, score=-0.819 tagged_above=-999 required=5 tests=[AWL=0.650, 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 vT-rUldwLutC for ; Wed, 31 Mar 2010 09:49:58 -0700 (PDT) Received: from EMPIRE.hq.ember.com (mail.ember.com [74.10.175.227]) by core3.amsl.com (Postfix) with ESMTP id 469A23A6BD1 for ; Wed, 31 Mar 2010 09:41:35 -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, 31 Mar 2010 12:45:01 -0400 Date: Wed, 31 Mar 2010 12:38:48 -0400 Message-Id: <87pr2k30pz.fsf@kelsey-ws.hq.ember.com> To: Jonathan Hui In-reply-to: <74BABD6C-D44A-48FD-A636-B65D425CE507@archrock.com> (message from Jonathan Hui on Wed, 31 Mar 2010 08:28:28 -0700) From: Richard Kelsey 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> X-OriginalArrivalTime: 31 Mar 2010 16:45:01.0328 (UTC) FILETIME=[81963100:01CAD0F1] 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 16:49:59 -0000 > From: Jonathan Hui > Date: Wed, 31 Mar 2010 08:28:28 -0700 > On Mar 31, 2010, at 7:20 AM, Richard Kelsey wrote: > > > If you want to optimize two > > different metrics, in this case the upward and downward > > costs, you need two separate DODAGs. While you can use two > > different criteria for DIO parents and DAO parents, both > > sets need to be parents as defined by the rank in the DIO. > > The DODAG is going to optimize the metric that determines > > the rank. Another metric can be used to tweak the DAO > > parent choice, but it only gets to pick between parents > > chosen by the rank metric. > > > > If the upward and downward link or node qualities diverge > > enough that one metric won't work for both, then you need > > two RPL instances. This is no different from optmizing > > latency and bandwidth, for example. > > > Are you talking about initiating a DODAG from the root and each > individual node? Or initiating two DODAGs from the root? I hope you > meant the latter. Yes. It would require that the metric indicate whether the upward or downward cost should be considered. This is required whenever you use an asymmetric link metric, regardless of how many DODAGs you have. Just saying latency, say, is not enough if a link has a different latency in different directions. Perhaps this could go in the DODAG Configuration option. > I tried to avoid the subject of how many instances or DODAGs in my > prior mail. We all agree that sometimes you want to have different > criteria for selecting DAG parents and DAO parents. I guess so. Doing so is a minor tweak to get local improvement in upward routes. Those two criteria have to be broadly similar for upwards and downwards routes to both work well in the same DODAG. > I could see a single DODAG approach work by accepting that > a DODAG can optimizing for DAG and DAO parents separately > if requested to do so. Wouldn't this require two rank values? How is that different from having two DODAGs? > We could make a two DODAG approach work, but you would need some way > to tell which DODAG to use for selecting DAG vs. DAO parents. The two DODAG approach works today, modulo the question of how you specify whether the upwards or downwards link cost is to be used. Both optimize their metric and pick parents with the lowest cost. The 'upwards' DODAG is not used for sending downwards, so it would not set the 'A' flag in the DIOs and no DAOs would be sent. The only upwards messages in the 'downwards' DODAG would be the DAOs used to establish the downwards routes. I am at a loss as to why upwards vs. downwards costs should be treated differently than any other two different metrics. > The single DODAG approach seems to make better sense > architecturally since a single DODAG is tasked with > selecting both DAG and DAO parents. Can you explain the single DODAG approach in more detail? -Richard Kelsey From prvs=699228876=mukul@uwm.edu Wed Mar 31 10:16: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 2BCED3A6B85 for ; Wed, 31 Mar 2010 10:16:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.447 X-Spam-Level: X-Spam-Status: No, score=-0.447 tagged_above=-999 required=5 tests=[AWL=1.022, 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 JCSAei6GVw86 for ; Wed, 31 Mar 2010 10:16:47 -0700 (PDT) Received: from ip1mta.uwm.edu (ip1mta.uwm.edu [129.89.7.18]) by core3.amsl.com (Postfix) with ESMTP id 572653A69BE for ; Wed, 31 Mar 2010 10:10:26 -0700 (PDT) Received: from mta03.pantherlink.uwm.edu ([129.89.7.83]) by ip1mta.uwm.edu with ESMTP; 31 Mar 2010 12:10:54 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by mta03.pantherlink.uwm.edu (Postfix) with ESMTP id A9A10C085AD; Wed, 31 Mar 2010 12:10:54 -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 ngne2TckJxYu; Wed, 31 Mar 2010 12:10:54 -0500 (CDT) Received: from mail02.pantherlink.uwm.edu (mail02.pantherlink.uwm.edu [129.89.7.86]) by mta03.pantherlink.uwm.edu (Postfix) with ESMTP id 36506C085A0; Wed, 31 Mar 2010 12:10:54 -0500 (CDT) Date: Wed, 31 Mar 2010 12:10:54 -0500 (CDT) From: Mukul Goyal To: "Pascal Thubert (pthubert)" Message-ID: <1354702033.2188271270055454111.JavaMail.root@mail02.pantherlink.uwm.edu> In-Reply-To: <6A2A459175DABE4BB11DE2026AA50A5D01923609@XMB-AMS-107.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [129.89.7.91] X-Mailer: Zimbra 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] 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, 31 Mar 2010 17:16:48 -0000 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 will come up. This is the bare minimum we can do. We already have an issue on this 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 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 enough capacity 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 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 probably failing short when the capacity problem is the routing table in a node hops 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 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 the child can select an alternate parent for that DAO and the light will come up. This is the bare minimum we can do. We already have an issue on this 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 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 > > appropriately (too small) just causes permanent look ups that > > 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 becomes a > > deployment issue. Usually what we address there is the bandwidth > > capacity on the root radio space. In this thread, the 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 capacity needs is > > probably divide and conquer, and nothing will replace a proper > > capacity planning overall. > > > > RPL enables DAGs that are made of multiple DODAGs. RPL enables the > > radio roots to be connected to a backbone, with a super-root there if > > you want a single DODAG. RPL dynamically adapts to the addition or the > > removal of a root in an instance so adapting the capacity to new > > requirements has only a local impact on the network. It also adapts > > dynamically to the addition of a parent in the DODAG to 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 > > somewhere, then we might have an issue with the parent selection. At > > the moment, a parent cannot indicate the capacity of its routing > > 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 > > pushback mechanism from the nodes where the capacity is 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 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 implementation-specific decision. At the very > least, it should be outside the core specification. > > It's an operational/administrative issue: if the network's routing tables are > overloaded, add another root. Rank and incrementing DODAG sequence > 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 From jhui@archrock.com Wed Mar 31 10:47: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 9AF1D3A67D7 for ; Wed, 31 Mar 2010 10:47:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.19 X-Spam-Level: X-Spam-Status: No, score=-1.19 tagged_above=-999 required=5 tests=[AWL=0.279, 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 ve5zuLQxQREZ for ; Wed, 31 Mar 2010 10:47:03 -0700 (PDT) Received: from mail.sf.archrock.com (mail.sf.archrock.com [216.121.16.71]) by core3.amsl.com (Postfix) with ESMTP id 080AD3A6A29 for ; Wed, 31 Mar 2010 10:46:56 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.sf.archrock.com (Postfix) with ESMTP id 05C5EAF835; Wed, 31 Mar 2010 10:47:28 -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 nShV1ZCzd5Jw; Wed, 31 Mar 2010 10:47:23 -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 500EFAF81F; Wed, 31 Mar 2010 10:47:23 -0700 (PDT) Message-Id: <8AAC1025-AA82-4772-BEDB-A40154A173D9@archrock.com> From: Jonathan Hui To: Richard Kelsey In-Reply-To: <87pr2k30pz.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: Wed, 31 Mar 2010 10:47:22 -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@kelse y-ws.hq.ember.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: Wed, 31 Mar 2010 17:47:04 -0000 Richard, I think there isn't any real difference in what you and I are trying to achieve with one or two instances. What I had in mind for the single instance approach is nearly identical to the two instance approach as you indicated. What was confusing me was the discussion starting around selecting non-overlapping sets of DAG and DAO parents. I think the two instance solution would make sense if we stick with the current constraint in rpl-07 that DAO parents must be a subset of the DAG parents (i.e. all DAO parents are also DAG parents). Then all we need is a way to specify whether or not an instance is building upward routes, downward routes, or both. The only other minor issue is whether we need to think through any cases where coordination between the upwards and downwards instances is useful. For example, what needs to happen when packet delivery fails on the downward route? Does the error/backtracking happen on the same instance or a different instance? Do we need to specify such behavior in the core spec? I recognize that we tried to avoid specifying how multiple instances work together. This is one case where I though having a single instance was conceptually easier to understand than having two, but I can get over that :) As for indicating which direction of routes to build, it might make sense to generalize the A-bit to indicate whether the DODAG is building upward, downward, or both. -- Jonathan Hui On Mar 31, 2010, at 9:38 AM, Richard Kelsey wrote: >> From: Jonathan Hui >> Date: Wed, 31 Mar 2010 08:28:28 -0700 > >> On Mar 31, 2010, at 7:20 AM, Richard Kelsey wrote: >> >>> If you want to optimize two >>> different metrics, in this case the upward and downward >>> costs, you need two separate DODAGs. While you can use two >>> different criteria for DIO parents and DAO parents, both >>> sets need to be parents as defined by the rank in the DIO. >>> The DODAG is going to optimize the metric that determines >>> the rank. Another metric can be used to tweak the DAO >>> parent choice, but it only gets to pick between parents >>> chosen by the rank metric. >>> >>> If the upward and downward link or node qualities diverge >>> enough that one metric won't work for both, then you need >>> two RPL instances. This is no different from optmizing >>> latency and bandwidth, for example. >> >> >> Are you talking about initiating a DODAG from the root and each >> individual node? Or initiating two DODAGs from the root? I hope you >> meant the latter. > > Yes. It would require that the metric indicate whether the > upward or downward cost should be considered. This is > required whenever you use an asymmetric link metric, > regardless of how many DODAGs you have. Just saying > latency, say, is not enough if a link has a different > latency in different directions. Perhaps this could go in > the DODAG Configuration option. > >> I tried to avoid the subject of how many instances or DODAGs in my >> prior mail. We all agree that sometimes you want to have different >> criteria for selecting DAG parents and DAO parents. > > I guess so. Doing so is a minor tweak to get local > improvement in upward routes. Those two criteria have to be > broadly similar for upwards and downwards routes to both > work well in the same DODAG. > >> I could see a single DODAG approach work by accepting that >> a DODAG can optimizing for DAG and DAO parents separately >> if requested to do so. > > Wouldn't this require two rank values? How is that > different from having two DODAGs? > >> We could make a two DODAG approach work, but you would need some way >> to tell which DODAG to use for selecting DAG vs. DAO parents. > > The two DODAG approach works today, modulo the question of > how you specify whether the upwards or downwards link cost > is to be used. Both optimize their metric and pick parents > with the lowest cost. The 'upwards' DODAG is not used for > sending downwards, so it would not set the 'A' flag in the > DIOs and no DAOs would be sent. The only upwards messages > in the 'downwards' DODAG would be the DAOs used to establish > the downwards routes. > > I am at a loss as to why upwards vs. downwards costs should > be treated differently than any other two different metrics. > >> The single DODAG approach seems to make better sense >> architecturally since a single DODAG is tasked with >> selecting both DAG and DAO parents. > > Can you explain the single DODAG approach in more detail? > > -Richard Kelsey From jhui@archrock.com Wed Mar 31 10:49: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 5CE9F3A69BA for ; Wed, 31 Mar 2010 10:49:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.218 X-Spam-Level: X-Spam-Status: No, score=-1.218 tagged_above=-999 required=5 tests=[AWL=0.251, 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 yQjaMKZUNLSg for ; Wed, 31 Mar 2010 10:49: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 13A3D3A6816 for ; Wed, 31 Mar 2010 10:49:51 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.sf.archrock.com (Postfix) with ESMTP id 6BB50AF90F; Wed, 31 Mar 2010 10:50: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 MGLKuHDvM7P6; Wed, 31 Mar 2010 10:50:17 -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 BB381AF835; Wed, 31 Mar 2010 10:50:17 -0700 (PDT) Message-Id: <1BA55E9C-C3DD-4988-A581-A16BDB456A4B@archrock.com> From: Jonathan Hui To: Richard Kelsey In-Reply-To: <87r5n034nw.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: Wed, 31 Mar 2010 10:50:16 -0700 References: <87vdcg5eis.fsf@kelsey-ws.hq.ember.com> <8F278AA8-105B-40C8-BC67-A0A5E30B47BE@archrock.com> <87r5n034nw.fsf@kelsey-ws.hq.ember.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: Wed, 31 Mar 2010 17:49:55 -0000 On Mar 31, 2010, at 8:13 AM, Richard Kelsey wrote: >> From: Jonathan Hui >> Date: Tue, 30 Mar 2010 19:08:42 -0700 >> >> I like the proposal in general, though it does need to be fleshed out >> a bit more. > > I have not gone over the draft to see exactly what changes > would be required. If there is enough support for going > forward, I will do so. This is all assuming that we stop > supporting mixed mode, which will require its own set of > changes to the text. I'm in support. >> Specifically, this works well in the non-storing case if >> all nodes source DAOs to the root so that the root can properly >> construct paths back to any individual node that is sending DAOs. >> But >> is there any desire to allow some nodes not to source DAOs if they >> don't need to? If so, we should specify that a node MUST source DAOs >> as long as they are forwarding DAOs for descendants. > > The current draft requires that all nodes send DAOs: > > 13. A node that receives a newly incremented DTSN from a DAO Parent > MUST schedule a DAO transmission. > > If we wanted to relax this, then yes, forwarding a DAO would > require that the forwarder also send their own DIO. Is there anything in the draft that says a node cannot source its own DAOs asynchronously? >> Separately, it might be nice to include a record-route mechanism (not >> the same as reverse route stack DAOs) so that nodes that only want to >> quickly establish routes can do so without having to possibly wait >> for >> all ancestors to source their own DAOs as well. I've found that >> record-route works really well in short request-response >> transactions, >> especially in cases where you don't want to continuously maintain >> downward routing state. > > Yes. Would record route go in the RPL draft? I associate > it what source route, which apparently cannot be in the RPL > draft. The difference in my mind is that record-route information can/will update RPL routing information. -- Jonathan Hui From pister@eecs.berkeley.edu Wed Mar 31 10:57: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 D9AD73A6928 for ; Wed, 31 Mar 2010 10:57:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.602 X-Spam-Level: X-Spam-Status: No, score=-4.602 tagged_above=-999 required=5 tests=[AWL=0.867, 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 4wjWkexvvW9f for ; Wed, 31 Mar 2010 10:57:00 -0700 (PDT) Received: from gateway0.EECS.Berkeley.EDU (gateway0.EECS.Berkeley.EDU [169.229.60.87]) by core3.amsl.com (Postfix) with ESMTP id 3F1A73A681A for ; Wed, 31 Mar 2010 10:57: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 o2VHvSx2016271 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 31 Mar 2010 10:57:29 -0700 (PDT) Message-ID: <4BB38D08.7060004@eecs.berkeley.edu> Date: Wed, 31 Mar 2010 10:57:28 -0700 From: Kris Pister User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: d.sturek@att.net 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> In-Reply-To: <01e801cacfa1$df8b67e0$9ea237a0$%sturek@att.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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, 31 Mar 2010 17:57:00 -0000 Don Sturek wrote: > [...] mesh routing relies on > distributed routing. Hmm. There are some very nice centralized approaches that work just fine. :) All of wirelessHART and ISA100.11A use centralized route computation. ksjp From pister@eecs.berkeley.edu Wed Mar 31 11:04: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 3380D3A67D7 for ; Wed, 31 Mar 2010 11:04:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.518 X-Spam-Level: X-Spam-Status: No, score=-3.518 tagged_above=-999 required=5 tests=[AWL=-0.650, BAYES_50=0.001, 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 Ivzdz25vAtMO for ; Wed, 31 Mar 2010 11:04:47 -0700 (PDT) Received: from gateway0.EECS.Berkeley.EDU (gateway0.EECS.Berkeley.EDU [169.229.60.87]) by core3.amsl.com (Postfix) with ESMTP id 5C7893A6A84 for ; Wed, 31 Mar 2010 11:04:31 -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 o2VI50Gl016489 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 31 Mar 2010 11:05:01 -0700 (PDT) Message-ID: <4BB38ECC.5050604@eecs.berkeley.edu> Date: Wed, 31 Mar 2010 11:05:00 -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> In-Reply-To: <17256.1269912377@marajade.sandelman.ca> Content-Type: multipart/alternative; boundary="------------050004000009060806000507" 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, 31 Mar 2010 18:04:49 -0000 This is a multi-part message in MIME format. --------------050004000009060806000507 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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. > 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. 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? > > - -- > ] 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 > > iQEVAwUBS7FTNYCLcPvd0N1lAQLeowgAn2043p/1x9+TmWB09nJAHPvGVdHpBASJ > fZRnHjnOjrv5H/lIe+FHC8iQUae/1+Orjyii4ev4nB3pD1alJy31pylM02bhWS9t > lFBozHKBH3GlIq6Bh8RRyRrzE0WVdQFlvQaRcqcvhfvTxc/knc5aoEos5zMX1nx3 > aNDA55wTsWapuue8+T1Py4L6O/aOBHJQcOfHhHFdgX8R8ITM9N8wb1Jaoa3yVcXd > tAVhB42NmP9l+Bn+pZJlstK1BrYTe/RuP2jQUjGwMqfhjfwXjD6KTKmCBmr+b8xP > Ztmla/UjKwrXoACEhavCF7sJnHkmJxtdwfwLsjLz7md9PvQJLWP2UA== > =0QxQ > -----END PGP SIGNATURE----- > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > --------------050004000009060806000507 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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.
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.

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?

- -- 
]       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.youtube.com/watch?v=kzx1ycLXQSE>
	               then sign the petition. 
-----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==
=0QxQ
-----END PGP SIGNATURE-----
_______________________________________________
Roll mailing list
Roll@ietf.org
https://www.ietf.org/mailman/listinfo/roll
--------------050004000009060806000507-- From pal@cs.stanford.edu Wed Mar 31 11:20: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 92E413A67B2 for ; Wed, 31 Mar 2010 11:20:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.763 X-Spam-Level: X-Spam-Status: No, score=-4.763 tagged_above=-999 required=5 tests=[AWL=0.705, 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 LJWQy9ashqtt for ; Wed, 31 Mar 2010 11:20:08 -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 A7E613A685B for ; Wed, 31 Mar 2010 11:20:02 -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 1Nx2Wn-0004UY-KZ; Wed, 31 Mar 2010 11:20:33 -0700 Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: multipart/alternative; boundary=Apple-Mail-14--306652504 From: Philip Levis In-Reply-To: <6A2A459175DABE4BB11DE2026AA50A5D019235C6@XMB-AMS-107.cisco.com> Date: Wed, 31 Mar 2010 10:58:43 -0700 Message-Id: <4D76D125-B26C-4302-B67C-00E551FD0F53@cs.stanford.edu> 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> <6A2A459175DABE4BB11DE2026AA50A5D0192352A@XMB-AMS-107.cisco.com> <73660B5D-8B98-4686-8090-B58B8F05C948@cs.jhu.edu> <6A2A459175DABE4BB11DE2026AA50A5D0192355B@XMB-AMS-107.cisco. com> <83 21E8BA-9511-4227-8372-6B55EE65B6B5@cs.jhu.edu> <6A2A459175DABE4BB11DE2026AA50A5D019235C6@XMB-AMS-107.cisco.com> To: Pascal Thubert (pthubert) X-Mailer: Apple Mail (2.1077) X-Scan-Signature: b6c1f4b091abe5b5a29b37e1ccaa2d85 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 18:20:12 -0000 --Apple-Mail-14--306652504 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Mar 31, 2010, at 1:47 AM, Pascal Thubert (pthubert) wrote: > Hi John: > =20 > The Rank is what makes the DAG a DAG. If you have 2 Ranks, one up one = down, then essentially you have 2 DAGs. >=20 Ah, OK, sorry. I think we have a confusion of terminology? Using *graph = theoretic* terminology, yes, there are two DAGs. Using *I-D* = terminology, there's only one DAG[1]. I was assuming the latter, you = were assuming the former? I think the confusion is due to the wording of the draft: we should = probably clean it up to adjust the "root node" text ("destination = node"?) so there isn't an ambiguity between RPL roots and graph roots. = This would make bring the text closer to the graph theoretic definition = (which we want to be consistent with). Phil [1] DAG: Directed Acyclic Graph. A directed graph having the = property that all edges are oriented in such a way that no cycles exist. All edges are contained in paths oriented toward and terminating at one or more root nodes. --Apple-Mail-14--306652504 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
On Mar 31, 2010, at 1:47 AM, Pascal = Thubert (pthubert) wrote:

Hi John:
The = Rank is what makes the DAG a DAG. If you have 2 Ranks, one up one down, = then essentially you have 2 DAGs.


<= div>Ah, OK, sorry. I think we have a confusion of terminology? Using = *graph theoretic* terminology, yes, there are two DAGs. Using *I-D* = terminology, there's only one DAG[1]. I was assuming the latter, you = were assuming the former?

I think the confusion = is due to the wording of the draft: we should probably clean it up to = adjust the "root node" text ("destination node"?) so there isn't an = ambiguity between RPL roots and graph roots. This would make bring the = text closer to the graph theoretic definition (which we want to be = consistent = with).

Phil

[1] &nb= sp;  DAG:  Directed Acyclic Graph.  A directed graph = having the property
         that all = edges are oriented in such a way that no cycles = exist.
         All edges are = contained in paths oriented toward and
     =     terminating at one or more root = nodes.


= --Apple-Mail-14--306652504-- From pal@cs.stanford.edu Wed Mar 31 11: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 C26963A69AD for ; Wed, 31 Mar 2010 11:20:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.881 X-Spam-Level: X-Spam-Status: No, score=-4.881 tagged_above=-999 required=5 tests=[AWL=0.588, 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 Kpi1-lVZuULq for ; Wed, 31 Mar 2010 11: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 5533C3A685B for ; Wed, 31 Mar 2010 11:20:29 -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 1Nx2XD-0004UY-P4; Wed, 31 Mar 2010 11:21:00 -0700 Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=windows-1252 From: Philip Levis In-Reply-To: <1143143317.1971991270034350013.JavaMail.root@mail02.pantherlink.uwm.edu> Date: Wed, 31 Mar 2010 11:02:20 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <208F5A41-E66B-4963-8AD1-078DBF9E6FB2@cs.stanford.edu> References: <1143143317.1971991270034350013.JavaMail.root@mail02.pantherlink.uwm.edu> To: Mukul Goyal X-Mailer: Apple Mail (2.1077) X-Scan-Signature: 1423d2bdf1536ba32d3e1b7a7c800682 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 18:20:32 -0000 On Mar 31, 2010, at 4:19 AM, Mukul Goyal wrote: >>>> Mukul=92s point stands. Sometimes, the Rank increment for the = parent-child link depends on metrics that are available at the parent = after communication from the child, so we might have a chicken and an = egg problem in the parent selection. I think we need to refine our text = on the link evaluation with candidate neighbors that enables a neighbor = to become a candidate parent in the first place. =20 >=20 >=20 >=20 >=20 > [Phil]The child gets to pick the parent. Note that link metrics can = persist across DODAG iterations. I'm not sure I understand the problem?=20= >=20 >=20 >=20 >=20 > [Pascal] If the child needs link metrics that the parent gathers upon = messages from the child, then the parent cannot place them in the first = mcast DIO. Some unicast communication must come first to assert the link = quality and exchange the perceptions from both ends. At that point, the = candidate neighbor becomes a candidate parent. In 07 and I think we lost = a lot of that discussion and se do not even define what candidate = parents and neighbors are. I think we need a few words to explain what = we expect from the out-of-scope neighboring mechanism that does a metric = aware NUD of some form.=20 >=20 >=20 > I totally agree. I still don't understand. Is the assumption that the only messages used = for link metric calculation are RPL messages? How could a node N send = unicast RPL messages to a DIO parent P before having an estimate of the = link N->P? Such an estimate would have required that N send packets... This is the basic link metric bootstrapping problem: to measure the link = A->B node A must send messages to B (either as unicast or = broadcast/multicast). The first transmission has zero knowledge of A->B. = Link estimators use a variety of approaches, such as: 1) A sends broadcasts/multicasts; B sends information on these messages = back to A (DeCouto's and Woo's ETX) 2) A measures B->A and assumes A-B is symmetric; it validates this by = using A->B and observing the result (4B link estimator) 3) A measures B->A and applies a very harsh filter to avoid = intermediate links, assuming that an almost-perfect B->A implies A->B is = at least very good (many RSSI/chip error approaches) Your concern seems to be based on assuming 1) is in use? I'd argue we = don't want to assume how the link metric estimator works and incorporate = that assumption into RPL. It should be the link metric estimator's job = to do its job given RPL's traffic, rather than RPL's job to generate = traffic to support a link metric estimator. A link metric estimator can = always generate its own packets if needed, after all. Phil= From mcr@sandelman.ca Wed Mar 31 11:42: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 5D2813A6A46 for ; Wed, 31 Mar 2010 11:42:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.389 X-Spam-Level: X-Spam-Status: No, score=0.389 tagged_above=-999 required=5 tests=[AWL=1.213, 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 GZNHxjBCDPU9 for ; Wed, 31 Mar 2010 11:42:15 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by core3.amsl.com (Postfix) with ESMTP id 6E4793A67B1 for ; Wed, 31 Mar 2010 11:42:15 -0700 (PDT) Received: from sandelman.ottawa.on.ca (unknown [132.213.238.4]) by relay.sandelman.ca (Postfix) with ESMTPS id 58CB3345F3; Wed, 31 Mar 2010 14:40:19 -0400 (EDT) Received: from marajade.sandelman.ca (unknown [127.0.0.1]) by sandelman.ottawa.on.ca (Postfix) with ESMTP id 872CA4E7E6; Wed, 31 Mar 2010 14:42:45 -0400 (EDT) From: Michael Richardson To: Kris Pister In-Reply-To: <4BB38ECC.5050604@eecs.berkeley.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> X-Mailer: MH-E 8.1; nmh 1.1; XEmacs 21.4 (patch 21) Date: Wed, 31 Mar 2010 14:42:45 -0400 Message-ID: <15752.1270060965@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: Wed, 31 Mar 2010 18:42:16 -0000 >>>>> "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? -- ] 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 prvs=699228876=mukul@uwm.edu Wed Mar 31 12:09: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 C15E03A6A86 for ; Wed, 31 Mar 2010 12:09:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.195 X-Spam-Level: X-Spam-Status: No, score=0.195 tagged_above=-999 required=5 tests=[AWL=0.175, BAYES_05=-1.11, 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 5czcedk5KCEy for ; Wed, 31 Mar 2010 12:09:13 -0700 (PDT) Received: from ip1mta.uwm.edu (ip1mta.uwm.edu [129.89.7.18]) by core3.amsl.com (Postfix) with ESMTP id BE9193A6A81 for ; Wed, 31 Mar 2010 12:09:13 -0700 (PDT) Received: from mta03.pantherlink.uwm.edu ([129.89.7.83]) by ip1mta.uwm.edu with ESMTP; 31 Mar 2010 14:09:29 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by mta03.pantherlink.uwm.edu (Postfix) with ESMTP id 8CEA0C085A1; Wed, 31 Mar 2010 14:09:29 -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 9wY7Heb8Z-rO; Wed, 31 Mar 2010 14:09:29 -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 591F4C085AC; Wed, 31 Mar 2010 14:09:29 -0500 (CDT) Date: Wed, 31 Mar 2010 14:09:29 -0500 (CDT) From: Mukul Goyal To: Philip Levis Message-ID: <1255047199.2278351270062569244.JavaMail.root@mail02.pantherlink.uwm.edu> In-Reply-To: <1019616700.2268951270061861438.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] 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 19:09:14 -0000 Phil, Cost of unidirectional link A->B may naturally be available at A or B or bo= th depending on the definition of the link cost. A and B may even need info= rmation exchange before either determines this cost. 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 So if selection of a DIO/DAO parent depends on the link cost and B does not= already have the relevant cost (A->B or B->A) required to decide whether t= o choose A as DIO/DAO parent, we have a problem. I think Pascal is saying that B should consider A as a candidate DIO/DAO pa= rent only when B knows (or is willing to assume a value for) the relevant (= A->B or B->A) cost for the link between A and B. Earlier versions of the RPL draft did have some discussion of the distincti= on between a neighbor and a candidate parent. This discussion is no longer = there. The mechanism used to elevate a neighbor to a candidate parent status is cl= early out of scope for the RPL draft. But, the draft should mention the pro= perties that a candidate parent must satisfy. I think this is what Pascal i= s saying and I agree with it. Thanks Mukul >>>> Mukul=E2=80=99s point stands. Sometimes, the Rank increment for the pa= rent-child link depends on metrics that are available at the parent after c= ommunication from the child, so we might have a chicken and an egg problem = in the parent selection. I think we need to refine our text on the link eva= luation with candidate neighbors that enables a neighbor to become a candid= ate parent in the first place. =20 >=20 >=20 >=20 >=20 > [Phil]The child gets to pick the parent. Note that link metrics can persi= st across DODAG iterations. I'm not sure I understand the problem?=20 >=20 >=20 >=20 >=20 > [Pascal] If the child needs link metrics that the parent gathers upon mes= sages from the child, then the parent cannot place them in the first mcast = DIO. Some unicast communication must come first to assert the link quality = and exchange the perceptions from both ends. At that point, the candidate n= eighbor becomes a candidate parent. In 07 and I think we lost a lot of that= discussion and se do not even define what candidate parents and neighbors = are. I think we need a few words to explain what we expect from the out-of-= scope neighboring mechanism that does a metric aware NUD of some form.=20 >=20 >=20 > I totally agree. [Phil] I still don't understand. Is the assumption that the only messages u= sed for link metric calculation are RPL messages? How could a node N send u= nicast RPL messages to a DIO parent P before having an estimate of the link= N->P? Such an estimate would have required that N send packets... This is the basic link metric bootstrapping problem: to measure the link A-= >B node A must send messages to B (either as unicast or broadcast/multicast= ). The first transmission has zero knowledge of A->B. Link estimators use a= variety of approaches, such as: 1) A sends broadcasts/multicasts; B sends information on these messages ba= ck to A (DeCouto's and Woo's ETX) 2) A measures B->A and assumes A-B is symmetric; it validates this by usin= g A->B and observing the result (4B link estimator) 3) A measures B->A and applies a very harsh filter to avoid intermediate l= inks, assuming that an almost-perfect B->A implies A->B is at least very go= od (many RSSI/chip error approaches) Your concern seems to be based on assuming 1) is in use? I'd argue we don't= want to assume how the link metric estimator works and incorporate that as= sumption into RPL. It should be the link metric estimator's job to do its j= ob given RPL's traffic, rather than RPL's job to generate traffic to suppor= t a link metric estimator. A link metric estimator can always generate its = own packets if needed, after all. Phil From pal@cs.stanford.edu Wed Mar 31 12:26: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 26C8F3A6B34 for ; Wed, 31 Mar 2010 12:26:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.965 X-Spam-Level: X-Spam-Status: No, score=-4.965 tagged_above=-999 required=5 tests=[AWL=0.504, 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 iJYGQIXSyq6w for ; Wed, 31 Mar 2010 12:26:29 -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 D187C3A6A84 for ; Wed, 31 Mar 2010 12:22:27 -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 1Nx3Uw-0008R2-JQ; Wed, 31 Mar 2010 12:22:42 -0700 Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Philip Levis In-Reply-To: <1255047199.2278351270062569244.JavaMail.root@mail02.pantherlink.uwm.edu> Date: Wed, 31 Mar 2010 12:22:42 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <4CDB0015-53FB-477C-AD8F-D08F7FFACCE8@cs.stanford.edu> References: <1255047199.2278351270062569244.JavaMail.root@mail02.pantherlink.uwm.edu> To: Mukul Goyal X-Mailer: Apple Mail (2.1077) X-Scan-Signature: 6bee508a35d8245455fa42c2dd36c733 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 19:26:32 -0000 On Mar 31, 2010, at 12:09 PM, Mukul Goyal wrote: >=20 > The mechanism used to elevate a neighbor to a candidate parent status = is clearly out of scope for the RPL draft. But, the draft should mention = the properties that a candidate parent must satisfy. I think this is = what Pascal is saying and I agree with it. What properties are they? This sounds like an implementation decision to = me.=20 There seems to be a tension between writing the draft to tell coders how = to implement the protocol and writing the draft to specify how the = protocol works for the purpose of interoperability. I thought a Proposed = Standard RFC is the latter? Implementation guidance seems like an = informational RFC topic. Phil= From prvs=699228876=mukul@uwm.edu Wed Mar 31 12:34: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 E989B3A681E for ; Wed, 31 Mar 2010 12:34:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.642 X-Spam-Level: X-Spam-Status: No, score=0.642 tagged_above=-999 required=5 tests=[AWL=-0.303, BAYES_40=-0.185, 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 2gv469ijLkyq for ; Wed, 31 Mar 2010 12:34:45 -0700 (PDT) Received: from ip2mta.uwm.edu (ip2mta.uwm.edu [129.89.7.20]) by core3.amsl.com (Postfix) with ESMTP id 10EAD3A63D3 for ; Wed, 31 Mar 2010 12:34:45 -0700 (PDT) Received: from mta03.pantherlink.uwm.edu ([129.89.7.83]) by ip2mta.uwm.edu with ESMTP; 31 Mar 2010 14:35:15 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by mta03.pantherlink.uwm.edu (Postfix) with ESMTP id 0209FC085D1; Wed, 31 Mar 2010 14:35:15 -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 fj+mXlHP5Chm; Wed, 31 Mar 2010 14:35:15 -0500 (CDT) Received: from mail02.pantherlink.uwm.edu (mail02.pantherlink.uwm.edu [129.89.7.86]) by mta03.pantherlink.uwm.edu (Postfix) with ESMTP id BEEFBC085DE; Wed, 31 Mar 2010 14:35:15 -0500 (CDT) Date: Wed, 31 Mar 2010 14:35:15 -0500 (CDT) From: Mukul Goyal To: Philip Levis Message-ID: <131162441.2300761270064115672.JavaMail.root@mail02.pantherlink.uwm.edu> In-Reply-To: <2007442142.2292561270063514856.JavaMail.root@mail02.pantherlink.uwm.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [129.89.7.91] X-Mailer: Zimbra 5.0.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: Wed, 31 Mar 2010 19:34:46 -0000 > > The mechanism used to elevate a neighbor to a candidate parent status is clearly out of scope for the RPL draft. But, the draft should mention the properties that a candidate parent must satisfy. I think this is what Pascal is saying and I agree with it. [Phil] What properties are they? This sounds like an implementation decision to me. [Mukul] I think the property is: A node may consider a neighbor as a candidate parent only if: 1) the node knows the relevant local cost required to evaluate the neighbor's suitability as a parent as per the objective function; or 2) the neighbor's DIO carries the information about such cost; or 3) the node is willing to assume a value for such cost. I dont think that it is an implementation decision. I think that it qualifies as part of "how the protocol works". Thanks Mukul [Phil] There seems to be a tension between writing the draft to tell coders how to implement the protocol and writing the draft to specify how the protocol works for the purpose of interoperability. I thought a Proposed Standard RFC is the latter? Implementation guidance seems like an informational RFC topic. Phil From osk@exegin.com Wed Mar 31 12:39: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 E01673A6971 for ; Wed, 31 Mar 2010 12:39:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.54 X-Spam-Level: X-Spam-Status: No, score=-0.54 tagged_above=-999 required=5 tests=[AWL=0.929, 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 ANkOjJmRZeK3 for ; Wed, 31 Mar 2010 12:39:41 -0700 (PDT) Received: from mail-pv0-f172.google.com (mail-pv0-f172.google.com [74.125.83.172]) by core3.amsl.com (Postfix) with ESMTP id BD07B3A68BC for ; Wed, 31 Mar 2010 12:39:41 -0700 (PDT) Received: by pvh1 with SMTP id 1so42339pvh.31 for ; Wed, 31 Mar 2010 12:40:09 -0700 (PDT) Received: by 10.142.1.34 with SMTP id 34mr3704826wfa.206.1270064409121; Wed, 31 Mar 2010 12:40:09 -0700 (PDT) Received: from [172.16.1.66] (209-139-203-37.bc.skyweb.ca [209.139.203.37]) by mx.google.com with ESMTPS id 23sm6154531pzk.2.2010.03.31.12.40.08 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 31 Mar 2010 12:40:08 -0700 (PDT) Message-ID: <4BB3A519.1060603@exegin.com> Date: Wed, 31 Mar 2010 12:40:09 -0700 From: Owen Kirby Organization: Exegin Technologies Limited User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Mukul Goyal References: <1354702033.2188271270055454111.JavaMail.root@mail02.pantherlink.uwm.edu> In-Reply-To: <1354702033.2188271270055454111.JavaMail.root@mail02.pantherlink.uwm.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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, 31 Mar 2010 19:39:43 -0000 Mukul, Pascal, Please correct me if I'm wrong, but are we really sure a *negative* ack is what we need in this case? 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 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. To illustrate how this might happen on a non-caching network: A -> B -> C -> ... -> Root 1) C sends a DAO, and fills up the routing table on the DAG 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. 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. Thanks, Owen 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 will come up. This > is the bare minimum we can do. We already have an issue on this 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 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 enough capacity > 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 > 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 probably failing short > when the capacity problem is the routing table in a node hops 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 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 the child can > select an alternate parent for that DAO and the light will come up. This > is the bare minimum we can do. We already have an issue on this 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 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 >>> appropriately (too small) just causes permanent look ups that >>> 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 becomes a >>> deployment issue. Usually what we address there is the bandwidth >>> capacity on the root radio space. In this thread, the 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 capacity needs >>> > is > >>> probably divide and conquer, and nothing will replace a proper >>> capacity planning overall. >>> >>> RPL enables DAGs that are made of multiple DODAGs. RPL enables the >>> radio roots to be connected to a backbone, with a super-root there >>> > if > >>> you want a single DODAG. RPL dynamically adapts to the addition or >>> > the > >>> removal of a root in an instance so adapting the capacity to new >>> requirements has only a local impact on the network. It also adapts >>> dynamically to the addition of a parent in the DODAG to 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 >>> somewhere, then we might have an issue with the parent selection. At >>> the moment, a parent cannot indicate the capacity of its routing >>> 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 >>> pushback mechanism from the nodes where the capacity is 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 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 implementation-specific decision. At >> > the very > >> least, it should be outside the core specification. >> >> It's an operational/administrative issue: if the network's routing >> > tables are > >> overloaded, add another root. Rank and incrementing DODAG sequence >> 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 > From mcr@sandelman.ca Wed Mar 31 12:49: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 47C253A6A34 for ; Wed, 31 Mar 2010 12:49:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.146 X-Spam-Level: X-Spam-Status: No, score=0.146 tagged_above=-999 required=5 tests=[AWL=0.970, 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 v0RavCwEWxpP for ; Wed, 31 Mar 2010 12:49:23 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by core3.amsl.com (Postfix) with ESMTP id 9D7C43A6A29 for ; Wed, 31 Mar 2010 12:49:23 -0700 (PDT) Received: from sandelman.ottawa.on.ca (unknown [132.213.238.4]) by relay.sandelman.ca (Postfix) with ESMTPS id 44ACE34375; Wed, 31 Mar 2010 15:47:28 -0400 (EDT) Received: from marajade.sandelman.ca (unknown [127.0.0.1]) by sandelman.ottawa.on.ca (Postfix) with ESMTP id 37F804E7ED; Wed, 31 Mar 2010 15:49:54 -0400 (EDT) From: Michael Richardson To: Philip Levis In-Reply-To: <4CDB0015-53FB-477C-AD8F-D08F7FFACCE8@cs.stanford.edu> References: <1255047199.2278351270062569244.JavaMail.root@mail02.pantherlink.uwm.edu> <4CDB0015-53FB-477C-AD8F-D08F7FFACCE8@cs.stanford.edu> X-Mailer: MH-E 8.1; nmh 1.1; XEmacs 21.4 (patch 21) Date: Wed, 31 Mar 2010 15:49:54 -0400 Message-ID: <20811.1270064994@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: Wed, 31 Mar 2010 19:49:24 -0000 >>>>> "Philip" == Philip Levis writes: >> The mechanism used to elevate a neighbor to a candidate parent >> status is clearly out of scope for the RPL draft. But, the draft >> should mention the properties that a candidate parent must >> satisfy. I think this is what Pascal is saying and I agree with >> it. Philip> What properties are they? This sounds like an implementation Philip> decision to me. Philip> There seems to be a tension between writing the draft to Philip> tell coders how to implement the protocol and writing the Philip> draft to specify how the protocol works for the purpose of Philip> interoperability. I thought a Proposed Standard RFC is the Philip> latter? Implementation guidance seems like an informational Philip> RFC topic. It's neither one or the other. If we have done our job right, then the developers will understand enough from the document to be able to write interoperable implementations. -- ] 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 prvs=699228876=mukul@uwm.edu Wed Mar 31 12: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 7D4093A6A94 for ; Wed, 31 Mar 2010 12:51:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.76 X-Spam-Level: X-Spam-Status: No, score=0.76 tagged_above=-999 required=5 tests=[AWL=-0.371, 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 rsRCON0LY5ep for ; Wed, 31 Mar 2010 12:51:12 -0700 (PDT) Received: from ip2mta.uwm.edu (ip2mta.uwm.edu [129.89.7.20]) by core3.amsl.com (Postfix) with ESMTP id A1A873A6AA2 for ; Wed, 31 Mar 2010 12:51:09 -0700 (PDT) Received: from mta03.pantherlink.uwm.edu ([129.89.7.83]) by ip2mta.uwm.edu with ESMTP; 31 Mar 2010 14:51:40 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by mta03.pantherlink.uwm.edu (Postfix) with ESMTP id C1240C085A0; Wed, 31 Mar 2010 14:51: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 hUBG4yS0Mfrs; Wed, 31 Mar 2010 14:51:40 -0500 (CDT) Received: from mail02.pantherlink.uwm.edu (mail02.pantherlink.uwm.edu [129.89.7.86]) by mta03.pantherlink.uwm.edu (Postfix) with ESMTP id 42024C085AC; Wed, 31 Mar 2010 14:51:40 -0500 (CDT) Date: Wed, 31 Mar 2010 14:51:40 -0500 (CDT) From: Mukul Goyal To: Owen Kirby Message-ID: <1857505560.2313361270065100167.JavaMail.root@mail02.pantherlink.uwm.edu> In-Reply-To: <958835153.2313221270065076040.JavaMail.root@mail02.pantherlink.uwm.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [129.89.7.91] X-Mailer: Zimbra 5.0.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] 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, 31 Mar 2010 19:51:13 -0000 Hi Owen This makes sense to me. Thanks Mukul ----- 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 Mukul, Pascal, Please correct me if I'm wrong, but are we really sure a *negative* ack is what we need in this case? 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 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. To illustrate how this might happen on a non-caching network: A -> B -> C -> ... -> Root 1) C sends a DAO, and fills up the routing table on the DAG 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. 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. Thanks, Owen 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 will come up. This > is the bare minimum we can do. We already have an issue on this 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 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 enough capacity > 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 > 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 probably failing short > when the capacity problem is the routing table in a node hops 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 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 the child can > select an alternate parent for that DAO and the light will come up. This > is the bare minimum we can do. We already have an issue on this 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 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 >>> appropriately (too small) just causes permanent look ups that >>> 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 becomes a >>> deployment issue. Usually what we address there is the bandwidth >>> capacity on the root radio space. In this thread, the 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 capacity needs >>> > is > >>> probably divide and conquer, and nothing will replace a proper >>> capacity planning overall. >>> >>> RPL enables DAGs that are made of multiple DODAGs. RPL enables the >>> radio roots to be connected to a backbone, with a super-root there >>> > if > >>> you want a single DODAG. RPL dynamically adapts to the addition or >>> > the > >>> removal of a root in an instance so adapting the capacity to new >>> requirements has only a local impact on the network. It also adapts >>> dynamically to the addition of a parent in the DODAG to 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 >>> somewhere, then we might have an issue with the parent selection. At >>> the moment, a parent cannot indicate the capacity of its routing >>> 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 >>> pushback mechanism from the nodes where the capacity is 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 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 implementation-specific decision. At >> > the very > >> least, it should be outside the core specification. >> >> It's an operational/administrative issue: if the network's routing >> > tables are > >> overloaded, add another root. Rank and incrementing DODAG sequence >> 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 > From pierre.colle@fr.schneider-electric.com Wed Mar 31 13:06: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 A8C8D3A682C for ; Wed, 31 Mar 2010 13:06:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.132 X-Spam-Level: X-Spam-Status: No, score=0.132 tagged_above=-999 required=5 tests=[BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, 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 3BRPlMJ2Z0hf for ; Wed, 31 Mar 2010 13:06:03 -0700 (PDT) Received: from mailX02.eud.schneider-electric.com (mailx02.eud.schneider-electric.com [205.167.7.38]) by core3.amsl.com (Postfix) with ESMTP id E6E833A681E for ; Wed, 31 Mar 2010 13:06:02 -0700 (PDT) Received: from ATEUI01.schneider-electric.com ([10.198.14.9]) by mailX02.eud.schneider-electric.com with ESMTP id 2010033122013550-60644 ; Wed, 31 Mar 2010 22:01:35 +0200 From: pierre.colle@fr.schneider-electric.com To: roll@ietf.org Message-ID: Date: Wed, 31 Mar 2010 22:06:43 +0200 MIME-Version: 1.0 X-MIMETrack: Serialize by Router on ATEUI01.Schneider-Electric.com/T/SVR/Schneider at 31/03/2010 22:06:33, Itemize by SMTP Server on AXEU2OUT.schneider-electric.com/X/SVR/SEIxtra at 31/03/2010 22:01:35, Serialize by Router on AXEU2OUT.schneider-electric.com/X/SVR/SEIxtra at 31/03/2010 22:01:37, Serialize complete at 31/03/2010 22:01:37 Content-type: multipart/alternative; Boundary="0__=4EBBFC64DFFDFCEB8f9e8a93df938690918c4EBBFC64DFFDFCEB" Content-Disposition: inline Subject: [Roll] Pierre Colle/FR/Schneider est absent(e). X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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 20:06:03 -0000 --0__=4EBBFC64DFFDFCEB8f9e8a93df938690918c4EBBFC64DFFDFCEB Content-transfer-encoding: quoted-printable Content-type: text/plain; charset=ISO-8859-1 Je serai absent(e) =E0 partir du 29/03/2010 de retour le 01/04/2010. I am currently on training. You might contact my manager Didier Pellegr= in regarding HOMES project. Best regards, Pierre = --0__=4EBBFC64DFFDFCEB8f9e8a93df938690918c4EBBFC64DFFDFCEB Content-transfer-encoding: quoted-printable Content-type: text/html; charset=ISO-8859-1 Content-Disposition: inline

Je serai absent(e) =E0 partir du 29/03/2010 de retour le 01/04/201= 0.

I am currently on training. You might contact my manager Didier Pellegr= in regarding HOMES project.

Best regards,

Pierre

= --0__=4EBBFC64DFFDFCEB8f9e8a93df938690918c4EBBFC64DFFDFCEB-- From prvs=699228876=mukul@uwm.edu Wed Mar 31 13:28: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 212423A6A73 for ; Wed, 31 Mar 2010 13:28:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.788 X-Spam-Level: X-Spam-Status: No, score=0.788 tagged_above=-999 required=5 tests=[AWL=-0.343, 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 imJ9xD+7PD2o for ; Wed, 31 Mar 2010 13:28:15 -0700 (PDT) Received: from ip1mta.uwm.edu (ip1mta.uwm.edu [129.89.7.18]) by core3.amsl.com (Postfix) with ESMTP id 9D8B03A6A6E for ; Wed, 31 Mar 2010 13:28:15 -0700 (PDT) Received: from mta03.pantherlink.uwm.edu ([129.89.7.83]) by ip1mta.uwm.edu with ESMTP; 31 Mar 2010 15:28:46 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by mta03.pantherlink.uwm.edu (Postfix) with ESMTP id 742AAC085AC; Wed, 31 Mar 2010 15:28:46 -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 VPT9uWl9MocI; Wed, 31 Mar 2010 15:28:45 -0500 (CDT) Received: from mail02.pantherlink.uwm.edu (mail02.pantherlink.uwm.edu [129.89.7.86]) by mta03.pantherlink.uwm.edu (Postfix) with ESMTP id E5C89C085A1; Wed, 31 Mar 2010 15:28:45 -0500 (CDT) Date: Wed, 31 Mar 2010 15:28:45 -0500 (CDT) From: Mukul Goyal To: Owen Kirby Message-ID: <1902982307.2341771270067325823.JavaMail.root@mail02.pantherlink.uwm.edu> In-Reply-To: <1857505560.2313361270065100167.JavaMail.root@mail02.pantherlink.uwm.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [129.89.7.91] X-Mailer: Zimbra 5.0.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] 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, 31 Mar 2010 20:28:17 -0000 Hi Owen I guess one could argue that in a non-storing LLN the DAG root is the only storing node. So if it can not store a DAO, the DAO can not 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. Now, in case of a storing LLN, a parent does not need to "route" a DAO ACK back. So, negative DAO ACKs would work fine. The benefit of negative DAO ACK is less message generation. Thanks Mukul ----- 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 Hi Owen This makes sense to me. Thanks Mukul ----- 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 Mukul, Pascal, Please correct me if I'm wrong, but are we really sure a *negative* ack is what we need in this case? 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 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. To illustrate how this might happen on a non-caching network: A -> B -> C -> ... -> Root 1) C sends a DAO, and fills up the routing table on the DAG 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. 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. Thanks, Owen 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 will come up. This > is the bare minimum we can do. We already have an issue on this 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 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 enough capacity > 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 > 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 probably failing short > when the capacity problem is the routing table in a node hops 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 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 the child can > select an alternate parent for that DAO and the light will come up. This > is the bare minimum we can do. We already have an issue on this 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 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 >>> appropriately (too small) just causes permanent look ups that >>> 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 becomes a >>> deployment issue. Usually what we address there is the bandwidth >>> capacity on the root radio space. In this thread, the 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 capacity needs >>> > is > >>> probably divide and conquer, and nothing will replace a proper >>> capacity planning overall. >>> >>> RPL enables DAGs that are made of multiple DODAGs. RPL enables the >>> radio roots to be connected to a backbone, with a super-root there >>> > if > >>> you want a single DODAG. RPL dynamically adapts to the addition or >>> > the > >>> removal of a root in an instance so adapting the capacity to new >>> requirements has only a local impact on the network. It also adapts >>> dynamically to the addition of a parent in the DODAG to 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 >>> somewhere, then we might have an issue with the parent selection. At >>> the moment, a parent cannot indicate the capacity of its routing >>> 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 >>> pushback mechanism from the nodes where the capacity is 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 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 implementation-specific decision. At >> > the very > >> least, it should be outside the core specification. >> >> It's an operational/administrative issue: if the network's routing >> > tables are > >> overloaded, add another root. Rank and incrementing DODAG sequence >> 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 > _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From pal@cs.stanford.edu Wed Mar 31 13:32: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 8DE323A6A6C for ; Wed, 31 Mar 2010 13:32:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.028 X-Spam-Level: X-Spam-Status: No, score=-5.028 tagged_above=-999 required=5 tests=[AWL=0.441, 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 E-q7ImYfVZxW for ; Wed, 31 Mar 2010 13:32: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 AD0A53A695D for ; Wed, 31 Mar 2010 13:32: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 1Nx4bC-0004w2-1K; Wed, 31 Mar 2010 13:33:14 -0700 Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Philip Levis In-Reply-To: <131162441.2300761270064115672.JavaMail.root@mail02.pantherlink.uwm.edu> Date: Wed, 31 Mar 2010 13:33:13 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <37A74A65-8C10-466B-8B51-B77B35847B71@cs.stanford.edu> References: <131162441.2300761270064115672.JavaMail.root@mail02.pantherlink.uwm.edu> To: Mukul Goyal X-Mailer: Apple Mail (2.1077) X-Scan-Signature: 2d1a4fa5d0150c38835749a59b44c419 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 20:32:44 -0000 On Mar 31, 2010, at 12:35 PM, Mukul Goyal wrote: >>=20 >> The mechanism used to elevate a neighbor to a candidate parent status = is clearly out of scope for the RPL draft. But, the draft should mention = the properties that a candidate parent must satisfy. I think this is = what Pascal is saying and I agree with it. >=20 > [Phil] What properties are they? This sounds like an implementation = decision to me.=20 >=20 > [Mukul] I think the property is: >=20 > A node may consider a neighbor as a candidate parent only if: >=20 > 1) the node knows the relevant local cost required to evaluate the = neighbor's suitability as a parent as per the objective function; or > 2) the neighbor's DIO carries the information about such cost; or > 3) the node is willing to assume a value for such cost. >=20 > I dont think that it is an implementation decision. I think that it = qualifies as part of "how the protocol works". By "candidate parent" I assume you mean member of the parent set? Let me try to reword this -- for a node A to consider a node B in its = parent set, then it must be able to compute its DAGRank if B were the = next hop.=20 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? Phil= From prvs=699228876=mukul@uwm.edu Wed Mar 31 13:37: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 915A83A681B for ; Wed, 31 Mar 2010 13:37:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.442 X-Spam-Level: X-Spam-Status: No, score=0.442 tagged_above=-999 required=5 tests=[AWL=0.052, BAYES_20=-0.74, 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 UvTlfinphYoa for ; Wed, 31 Mar 2010 13:37:09 -0700 (PDT) Received: from ip1mta.uwm.edu (ip1mta.uwm.edu [129.89.7.18]) by core3.amsl.com (Postfix) with ESMTP id C66553A6807 for ; Wed, 31 Mar 2010 13:37:08 -0700 (PDT) Received: from mta03.pantherlink.uwm.edu ([129.89.7.83]) by ip1mta.uwm.edu with ESMTP; 31 Mar 2010 15:37:39 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by mta03.pantherlink.uwm.edu (Postfix) with ESMTP id 016B7C085D3; Wed, 31 Mar 2010 15:37: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 48EWV4ucSY2t; Wed, 31 Mar 2010 15:37: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 D1562C085A1; Wed, 31 Mar 2010 15:37:39 -0500 (CDT) Date: Wed, 31 Mar 2010 15:37:39 -0500 (CDT) From: Mukul Goyal To: Philip Levis Message-ID: <1282609114.2348961270067859739.JavaMail.root@mail02.pantherlink.uwm.edu> In-Reply-To: <37A74A65-8C10-466B-8B51-B77B35847B71@cs.stanford.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [129.89.7.91] X-Mailer: Zimbra 5.0.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: Wed, 31 Mar 2010 20:37:09 -0000 > By "candidate parent" I assume you mean member of the parent set? No. I mean a neighbor that is a candidate to become a parent. It is not yet a parent. Thanks Mukul >Let me try to reword this -- for a node A to consider a node B in its parent set, then it must be able to compute its DAGRank if B were the next hop. >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? >Phil From prvs=699228876=mukul@uwm.edu Wed Mar 31 13:48: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 2D9C53A6AD3 for ; Wed, 31 Mar 2010 13:48:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.254 X-Spam-Level: X-Spam-Status: No, score=0.254 tagged_above=-999 required=5 tests=[AWL=0.234, BAYES_05=-1.11, 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 ByCMuR8Yf+ev for ; Wed, 31 Mar 2010 13:48:32 -0700 (PDT) Received: from ip1mta.uwm.edu (ip1mta.uwm.edu [129.89.7.18]) by core3.amsl.com (Postfix) with ESMTP id 42FCA3A681B for ; Wed, 31 Mar 2010 13:48:25 -0700 (PDT) Received: from mta03.pantherlink.uwm.edu ([129.89.7.83]) by ip1mta.uwm.edu with ESMTP; 31 Mar 2010 15:48:56 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by mta03.pantherlink.uwm.edu (Postfix) with ESMTP id 6E055C085AD; Wed, 31 Mar 2010 15:48: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 E+y2lCNFmaJ5; Wed, 31 Mar 2010 15:48: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 06CEFC085A1; Wed, 31 Mar 2010 15:48:56 -0500 (CDT) Date: Wed, 31 Mar 2010 15:48:55 -0500 (CDT) From: Mukul Goyal To: Philip Levis Message-ID: <1723229.2357171270068535884.JavaMail.root@mail02.pantherlink.uwm.edu> In-Reply-To: <1282609114.2348961270067859739.JavaMail.root@mail02.pantherlink.uwm.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [129.89.7.91] X-Mailer: Zimbra 5.0.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: Wed, 31 Mar 2010 20:48:33 -0000 Sorry for the previous incomplete response. > By "candidate parent" I assume you mean member of the parent set? No. I mean a neighbor that is a candidate to become a parent. It is not yet a parent. >Let me try to reword this -- for a node A to consider a node B in its parent set, then it must be able to compute its DAGRank if B were the next hop. >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. Thanks Mukul >Phil _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From pal@cs.stanford.edu Wed Mar 31 13:56: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 945ED3A68AA for ; Wed, 31 Mar 2010 13:56:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.077 X-Spam-Level: X-Spam-Status: No, score=-5.077 tagged_above=-999 required=5 tests=[AWL=0.392, 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 TQXluqt41eqS for ; Wed, 31 Mar 2010 13:56:07 -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 D863A3A67A5 for ; Wed, 31 Mar 2010 13:56:07 -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 1Nx4xr-0005c4-8w; Wed, 31 Mar 2010 13:56:39 -0700 Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Philip Levis In-Reply-To: <1723229.2357171270068535884.JavaMail.root@mail02.pantherlink.uwm.edu> Date: Wed, 31 Mar 2010 13:56:38 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <47BE8B6B-FA6F-48F0-9784-4173EE5101C8@cs.stanford.edu> References: <1723229.2357171270068535884.JavaMail.root@mail02.pantherlink.uwm.edu> To: Mukul Goyal X-Mailer: Apple Mail (2.1077) X-Scan-Signature: d568c20fab0e2ccae07d583947984559 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 20:56:08 -0000 On Mar 31, 2010, at 1:48 PM, Mukul Goyal wrote: > Sorry for the previous incomplete response. >=20 >> By "candidate parent" I assume you mean member of the parent set? >=20 > No. I mean a neighbor that is a candidate to become a parent. It is = not yet a parent. >=20 >> Let me try to reword this -- for a node A to consider a node B in its = parent set, then it must be able to compute its DAGRank if B were the = next hop.=20 >=20 >> 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? >=20 > 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. =20 So a node A MUST NOT select node B as a parent if the OF cannot compute = the DAGRank of the resulting route? Phil= From prvs=699228876=mukul@uwm.edu Wed Mar 31 14:06: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 25F0B3A6819 for ; Wed, 31 Mar 2010 14:06:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.795 X-Spam-Level: X-Spam-Status: No, score=0.795 tagged_above=-999 required=5 tests=[AWL=-0.336, 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 0u8RYkT10Uvn for ; Wed, 31 Mar 2010 14:06:07 -0700 (PDT) Received: from ip1mta.uwm.edu (ip1mta.uwm.edu [129.89.7.18]) by core3.amsl.com (Postfix) with ESMTP id 33F7D3A6811 for ; Wed, 31 Mar 2010 14:06:07 -0700 (PDT) Received: from mta03.pantherlink.uwm.edu ([129.89.7.83]) by ip1mta.uwm.edu with ESMTP; 31 Mar 2010 16:06:38 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by mta03.pantherlink.uwm.edu (Postfix) with ESMTP id 19952C085A1; Wed, 31 Mar 2010 16:06:38 -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 EhcbWdmXB0nO; Wed, 31 Mar 2010 16:06:37 -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 E7DA3C085A0; Wed, 31 Mar 2010 16:06:37 -0500 (CDT) Date: Wed, 31 Mar 2010 16:06:37 -0500 (CDT) From: Mukul Goyal To: Philip Levis Message-ID: <1555819628.2369521270069597858.JavaMail.root@mail02.pantherlink.uwm.edu> In-Reply-To: <694785010.2366641270069323044.JavaMail.root@mail02.pantherlink.uwm.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [129.89.7.91] X-Mailer: Zimbra 5.0.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: Wed, 31 Mar 2010 21:06:08 -0000 >> 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). Mukul From richard.kelsey@ember.com Wed Mar 31 14:26: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 72EFC3A6853 for ; Wed, 31 Mar 2010 14:26:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.912 X-Spam-Level: X-Spam-Status: No, score=-0.912 tagged_above=-999 required=5 tests=[AWL=0.557, 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 E-zitGq0jfAm for ; Wed, 31 Mar 2010 14:26:24 -0700 (PDT) Received: from EMPIRE.hq.ember.com (mail.ember.com [74.10.175.227]) by core3.amsl.com (Postfix) with ESMTP id 306323A67F6 for ; Wed, 31 Mar 2010 14:26:24 -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, 31 Mar 2010 17:29:49 -0400 Date: Wed, 31 Mar 2010 17:23:34 -0400 Message-Id: <87oci42njd.fsf@kelsey-ws.hq.ember.com> To: Jonathan Hui In-reply-to: <8AAC1025-AA82-4772-BEDB-A40154A173D9@archrock.com> (message from Jonathan Hui on Wed, 31 Mar 2010 10:47:22 -0700) From: Richard Kelsey 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@kelse y-ws.hq.ember.com> <8AAC1025-AA82-4772-BEDB-A40154A173D9@archrock.com> X-OriginalArrivalTime: 31 Mar 2010 21:29:49.0749 (UTC) FILETIME=[4B144E50:01CAD119] 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 21:26:25 -0000 > From: Jonathan Hui > Date: Wed, 31 Mar 2010 10:47:22 -0700 > > I think there isn't any real difference in what you and I are trying > to achieve with one or two instances. What I had in mind for the > single instance approach is nearly identical to the two instance > approach as you indicated. Jonathan, 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 think the two instance solution would make sense if we > stick with the current constraint in rpl-07 that DAO > parents must be a subset of the DAG parents (i.e. all DAO > parents are also DAG parents). Yes. I am having trouble seeing how DAOs would work if DAO parents were not also DAG parents. > Then all we need is a way to specify whether or not an > instance is building upward routes, downward routes, or > both. I think a better way to put it would be to specify how asymmetric link metrics are to be combined (downward value only, upward value only, max of the two, min of the two, average, ...). I will ask JP to open a ticket. > The only other minor issue > is whether we need to think through any cases where coordination > between the upwards and downwards instances is useful. For example, > what needs to happen when packet delivery fails on the downward > route? Does the error/backtracking happen on the same instance or a > different instance? Do we need to specify such behavior in the core > spec? Again, I do not see how this is different from other collections of instances. What happens when a packet delivery fails on a low-latency instance? Does the error get forwarded on that instance or some other instance? -Richard Kelsey From richard.kelsey@ember.com Wed Mar 31 14:37: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 EBFFE3A6807 for ; Wed, 31 Mar 2010 14:37:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.237 X-Spam-Level: X-Spam-Status: No, score=-0.237 tagged_above=-999 required=5 tests=[AWL=-0.257, BAYES_05=-1.11, 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 Pc468a4GABFa for ; Wed, 31 Mar 2010 14:37:05 -0700 (PDT) Received: from EMPIRE.hq.ember.com (mail.ember.com [74.10.175.227]) by core3.amsl.com (Postfix) with ESMTP id 299EB3A67D2 for ; Wed, 31 Mar 2010 14:37:05 -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, 31 Mar 2010 17:40:31 -0400 Date: Wed, 31 Mar 2010 17:34:17 -0400 Message-Id: <87mxxo2n1i.fsf@kelsey-ws.hq.ember.com> To: jpv@cisco.com From: Richard Kelsey X-OriginalArrivalTime: 31 Mar 2010 21:40:32.0203 (UTC) FILETIME=[CA0301B0:01CAD11A] Cc: roll@ietf.org Subject: [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: Wed, 31 Mar 2010 21:37:06 -0000 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 From jhui@archrock.com Wed Mar 31 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 820E43A6A2B for ; Wed, 31 Mar 2010 14:47:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.241 X-Spam-Level: X-Spam-Status: No, score=-1.241 tagged_above=-999 required=5 tests=[AWL=0.228, 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 4HIb3AmNIB35 for ; Wed, 31 Mar 2010 14:47:33 -0700 (PDT) Received: from mail.sf.archrock.com (mail.sf.archrock.com [216.121.16.71]) by core3.amsl.com (Postfix) with ESMTP id AD08D3A6807 for ; Wed, 31 Mar 2010 14:47:33 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.sf.archrock.com (Postfix) with ESMTP id AAB83AF920; Wed, 31 Mar 2010 14:48:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at Received: from mail.sf.archrock.com ([127.0.0.1]) by localhost (mail.sf.archrock.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uDWXaa5c5Zpx; Wed, 31 Mar 2010 14:48:00 -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 062EAAF844; Wed, 31 Mar 2010 14:48:00 -0700 (PDT) Message-Id: From: Jonathan Hui To: Richard Kelsey In-Reply-To: <87oci42njd.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: Wed, 31 Mar 2010 14:47:59 -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@kelse y-ws.hq.ember.com> <8AAC1025-AA82-4772-BEDB-A40154A173D9@archrock.com> <87oci42njd.fsf@kelsey-ws.hq.ember.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: Wed, 31 Mar 2010 21:47:34 -0000 Richard, On Mar 31, 2010, at 2:23 PM, Richard Kelsey wrote: >> From: Jonathan Hui >> Date: Wed, 31 Mar 2010 10:47:22 -0700 >> >> I think there isn't any real difference in what you and I are trying >> to achieve with one or two instances. What I had in mind for the >> single instance approach is nearly identical to the two instance >> approach as you indicated. > > 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. Yes, I agree this is desirable. >> I think the two instance solution would make sense if we >> stick with the current constraint in rpl-07 that DAO >> parents must be a subset of the DAG parents (i.e. all DAO >> parents are also DAG parents). > > Yes. I am having trouble seeing how DAOs would work if DAO > parents were not also DAG parents. > >> Then all we need is a way to specify whether or not an >> instance is building upward routes, downward routes, or >> both. > > I think a better way to put it would be to specify how > asymmetric link metrics are to be combined (downward value > only, upward value only, max of the two, min of the two, > average, ...). I will ask JP to open a ticket. Metrics are important, yes. But a node also needs to know whether or not to install forwarding table entries for its DAG parents. If the instance is only for downward routes, then one approach is to say a node need not install default/destination forwarding entries. But maybe this isn't the best approach (see below). >> The only other minor issue >> is whether we need to think through any cases where coordination >> between the upwards and downwards instances is useful. For example, >> what needs to happen when packet delivery fails on the downward >> route? Does the error/backtracking happen on the same instance or a >> different instance? Do we need to specify such behavior in the core >> spec? > > Again, I do not see how this is different from other > collections of instances. What happens when a packet > delivery fails on a low-latency instance? Does the error > get forwarded on that instance or some other instance? The difference in my mind is whether or not we require all instances to maintain upward routes. Then backtracking within an instance works as we have envisioned it so far. If we allow backtracking to occur across instances, then the benefits of backtracking become less obvious because you are no longer 'backtracking' in the literal sense of the word. Of course, this assumes we even want backtracking at all and I'm not convinced yet... In any case, it seems that we need a mechanism to identify how instances are tied together (minimally what instance to use what routes fail). This is the kind of coordination that I was alluding to. -- Jonathan Hui From prvs=699228876=mukul@uwm.edu Wed Mar 31 14:58: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 337193A6A89 for ; Wed, 31 Mar 2010 14:58:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.444 X-Spam-Level: X-Spam-Status: No, score=0.444 tagged_above=-999 required=5 tests=[AWL=0.054, BAYES_20=-0.74, 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 u0XdKxGGNAMW for ; Wed, 31 Mar 2010 14:58:57 -0700 (PDT) Received: from ip1mta.uwm.edu (ip1mta.uwm.edu [129.89.7.18]) by core3.amsl.com (Postfix) with ESMTP id 3CC453A6A40 for ; Wed, 31 Mar 2010 14:58:57 -0700 (PDT) Received: from mta03.pantherlink.uwm.edu ([129.89.7.83]) by ip1mta.uwm.edu with ESMTP; 31 Mar 2010 16:59:28 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by mta03.pantherlink.uwm.edu (Postfix) with ESMTP id 769CBC085D1; Wed, 31 Mar 2010 16:59:28 -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 hfBPpAyAh-kB; Wed, 31 Mar 2010 16:59:28 -0500 (CDT) Received: from mail02.pantherlink.uwm.edu (mail02.pantherlink.uwm.edu [129.89.7.86]) by mta03.pantherlink.uwm.edu (Postfix) with ESMTP id 262ABC085D0; Wed, 31 Mar 2010 16:59:28 -0500 (CDT) Date: Wed, 31 Mar 2010 16:59:28 -0500 (CDT) From: Mukul Goyal To: Richard Kelsey Message-ID: <643398615.2404291270072768068.JavaMail.root@mail02.pantherlink.uwm.edu> In-Reply-To: <677908518.2401541270072502887.JavaMail.root@mail02.pantherlink.uwm.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [129.89.7.91] X-Mailer: Zimbra 5.0.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: Wed, 31 Mar 2010 21:58:58 -0000 Richard >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? I guess this is probably not going to be an issue since, even if the metrics are significantly asymmetrical, a node can simply choose all its DAO parents as DAG parents but not actually use them for upward communication. I guess we need more opinions. Thanks Mukul > I think the two instance solution would make sense if we > stick with the current constraint in rpl-07 that DAO > parents must be a subset of the DAG parents (i.e. all DAO > parents are also DAG parents). Yes. I am having trouble seeing how DAOs would work if DAO parents were not also DAG parents. > Then all we need is a way to specify whether or not an > instance is building upward routes, downward routes, or > both. I think a better way to put it would be to specify how asymmetric link metrics are to be combined (downward value only, upward value only, max of the two, min of the two, average, ...). I will ask JP to open a ticket. > The only other minor issue > is whether we need to think through any cases where coordination > between the upwards and downwards instances is useful. For example, > what needs to happen when packet delivery fails on the downward > route? Does the error/backtracking happen on the same instance or a > different instance? Do we need to specify such behavior in the core > spec? Again, I do not see how this is different from other collections of instances. What happens when a packet delivery fails on a low-latency instance? Does the error get forwarded on that instance or some other instance? -Richard Kelsey _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From pister@eecs.berkeley.edu Wed Mar 31 15:25: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 16BC43A69AB for ; Wed, 31 Mar 2010 15:25:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.688 X-Spam-Level: X-Spam-Status: No, score=-4.688 tagged_above=-999 required=5 tests=[AWL=0.780, 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 N6936lT5Y54E for ; Wed, 31 Mar 2010 15:25:35 -0700 (PDT) Received: from gateway0.EECS.Berkeley.EDU (gateway0.EECS.Berkeley.EDU [169.229.60.87]) by core3.amsl.com (Postfix) with ESMTP id 32BF13A6889 for ; Wed, 31 Mar 2010 15:25:35 -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 o2VMQ4rq022635 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 31 Mar 2010 15:26:05 -0700 (PDT) Message-ID: <4BB3CBFC.7050509@eecs.berkeley.edu> Date: Wed, 31 Mar 2010 15:26:04 -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="------------040800080203030009040501" 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, 31 Mar 2010 22:25:36 -0000 This is a multi-part message in MIME format. --------------040800080203030009040501 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Michael Richardson wrote: > 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? > 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 --------------040800080203030009040501 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Michael Richardson wrote: 

    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?
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
--------------040800080203030009040501-- From roger.alexander@ekasystems.com Wed Mar 31 15:53: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 EE0383A6986 for ; Wed, 31 Mar 2010 15:53:21 -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.542, BAYES_05=-1.11, DNS_FROM_OPENWHOIS=1.13, 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 wHETWxTz1qaE for ; Wed, 31 Mar 2010 15:53:15 -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 F3A8F3A6917 for ; Wed, 31 Mar 2010 15:53:14 -0700 (PDT) Received: (qmail 96776 invoked from network); 31 Mar 2010 22:53:46 -0000 Received: from dallas (roger.alexander@209.48.242.70 with login) by smtp115.biz.mail.re2.yahoo.com with SMTP; 31 Mar 2010 15:53:46 -0700 PDT X-Yahoo-SMTP: 1dQRPo6swBBzwSsRzMLy_tvdRrLDyF0J X-YMail-OSG: fR0VqG0VM1lPMitlShcd8NFTFGvf6zUqAVqTqO1nonIsy3asPHIcPDtywYB7VRx9IdkeZ9eZEkAdnifKRO84essVBAlealClrAfqkT0vhmNBNJDJWGU09Oft_YbEogHqkIYJIpbxlHM2dT8QLa4_eSMFF7rBW7070Cfvve6WHvllam22.eJPUV1OwmiWp5C8ksapSohxUq_vCcVmCqc8b3Smw0ZOK7IKyryK5XfZZ2WngtZbv7stRL5gvh2i0bcOjfh_QZwnnjQOIRpUepQxGEGiGwVZgEATG5CkSGJOUztD1UsyTvRUHHZTyzOMts6nZwyUsB638k.uP7QeEv3lZBhbECcMl86xd0Hco6DaDDksSdyEYrPeBcwQbiY0G3eY X-Yahoo-Newman-Property: ymail-3 From: "Roger Alexander" To: "'Pascal Thubert \(pthubert\)'" , "'Philip Levis'" 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> <6A2A459175DABE4BB11DE2026AA50A5D0192352A@XMB-AMS-107.cisco.com> <7C1C35FC-0FA6-4F65-B045-D8BDEF2B30CF@cs.stanford.edu> <6A2A459175DABE4BB11DE2026AA50A5D019235D3@XMB-AMS-107.c isco.com> In-Reply-To: <6A2A459175DABE4BB11DE2026AA50A5D019235D3@XMB-AMS-107.cisco.com> Date: Wed, 31 Mar 2010 18:52:34 -0400 Message-ID: <01a201cad124$da591720$8f0b4560$@alexander@ekasystems.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_01A3_01CAD103.53477720" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcrQoZ8qwDzoI4iKRX6eApzl6UmHwgADTAGgAAoC3qA= Content-Language: en-us 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 22:53:22 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_01A3_01CAD103.53477720 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Phil, Pascal, From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Pascal Thubert (pthubert) Sent: Wednesday, March 31, 2010 4:57 AM To: Philip Levis Cc: roll@ietf.org Subject: Re: [Roll] proposal for DAOs in non-caching DODAGs Hi Phil Pascal From: Philip Levis [mailto:pal@cs.stanford.edu] Sent: Wednesday, March 31, 2010 9:13 AM To: Pascal Thubert (pthubert) Cc: JeongGil Ko (John); Jonathan Hui; roll@ietf.org Subject: Re: [Roll] proposal for DAOs in non-caching DODAGs On Mar 31, 2010, at 12:06 AM, Pascal Thubert (pthubert) wrote: Hi John: The Rank is derived from the decision of the parent set, that includes both DIO parents that optimize the path towards the root and DAO parents that optimize the path from the root to this node. So the Rank mechanism does not depend whether the metrics are all bidirectional or if some metrics are unidirectional. The Rank mechanism belongs to the generic RPL and is designed for loop avoidance, whatever the specific things the OF does with the metrics of the day. I thought we'd gone over this: this can't be true. The rules in RPL in Rank adjustment means that Rank generally comes first in parent set selection. This is part of why we agreed to increase Rank to 16 bits, in order to allow it to better represent metrics as necessary. [Pascal] When you can do that, well that's fine. Typically for the collection tree I'd think. I already elaborated with John on why the parent selection on the way back might blur this optimistic vision. If you really need to have the rank represent finely the metrics cost, and the metrics are really assymetrical, then probably you want 2 DAGs, one for which the RANK increment is mostly derived from the up metrics and one for which it is mostly derived from the down metrics. I totally disagree -- this seems completely backwards. You're suggesting that my TCP packets from A->B traverse one DAG while B->A traverse another? [Pascal] Welcome to the Internet. Whatever you do, there is a large probability that the way back is not the way in. Note that whether you make 1 or 2 DAGs, as soon as you have different metrics for upwards and downwards you get a different path. Mukul's point stands. Sometimes, the Rank increment for the parent-child link depends on metrics that are available at the parent after communication from the child, so we might have a chicken and an egg problem in the parent selection. I think we need to refine our text on the link evaluation with candidate neighbors that enables a neighbor to become a candidate parent in the first place. The child gets to pick the parent. Note that link metrics can persist across DODAG iterations. I'm not sure I understand the problem? [Pascal] If the child needs link metrics that the parent gathers upon messages from the child, then the parent cannot place them in the first mcast DIO. Some unicast communication must come first to assert the link quality and exchange the perceptions from both ends. At that point, the candidate neighbor becomes a candidate parent. In 07 and I think we lost a lot of that discussion and se do not even define what candidate parents and neighbors are. I think we need a few words to explain what we expect from the out-of-scope neighboring mechanism that does a metric aware NUD of some form. >>[RA] The Parent only needs to convey aggregated metrics, upward (downward) from itself to the root (from the root to itself). Even if the Child node needs link statistics that the Parent node gathers, that would be derived and conveyed through a separate process. Pascal ------=_NextPart_000_01A3_01CAD103.53477720 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Phil, Pascal,

 

From:= roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of = Pascal Thubert (pthubert)
Sent: Wednesday, March 31, 2010 4:57 AM
To: Philip Levis
Cc: roll@ietf.org
Subject: Re: [Roll] proposal for DAOs in non-caching = DODAGs

 

Hi Phil

 

Pascal

 

From:= = Philip Levis [mailto:pal@cs.stanford.edu]
Sent: Wednesday, March 31, 2010 9:13 AM
To: Pascal Thubert (pthubert)
Cc: JeongGil Ko (John); Jonathan Hui; roll@ietf.org
Subject: Re: [Roll] proposal for DAOs in non-caching = DODAGs

 

 

On Mar 31, 2010, at 12:06 AM, Pascal Thubert = (pthubert) wrote:

 

Hi John:

 

The Rank is derived from the decision of the parent set, = that includes both DIO parents that optimize the path towards the root and = DAO parents that optimize the path from the root to this = node.

 

So the Rank mechanism does not depend whether the metrics = are all bidirectional or if some metrics are unidirectional. The Rank = mechanism belongs to the generic RPL and is designed for loop avoidance, whatever = the specific things the OF does with the metrics of the = day.

 

I thought we'd gone over this: this can't be true. = The rules in RPL in Rank adjustment means that Rank generally comes first in = parent set selection. This is part of why we agreed to increase Rank to 16 bits, in = order to allow it to better represent metrics as necessary.

 

[Pascal] When you can do that, well that’s fine. = Typically for the collection tree I‘d think. I already elaborated with John = on why the parent selection on the way back might blur this optimistic = vision.

 

If you really need to have the rank represent finely the = metrics cost, and the metrics are really assymetrical, then probably you want 2 = DAGs, one for which the RANK increment is mostly derived from the up metrics = and one for which it is mostly derived from the down = metrics.

 

I totally disagree -- this seems completely = backwards. You're suggesting that my TCP packets from A->B traverse one DAG = while B->A traverse another?

 

[Pascal] Welcome to the Internet. Whatever you do, there = is a large probability that the way back is not the way in. Note that whether = you make 1 or 2 DAGs, as soon as you have different metrics for upwards and downwards you get  a different path.

 

Mukul’s point stands. Sometimes, the Rank increment = for the parent-child link depends on metrics that are available at the = parent after communication from the child, so we might have a chicken and an egg = problem in the parent selection. I think we need to refine our text on the link = evaluation with candidate neighbors that enables a neighbor to become a candidate = parent in the first place.  

 

The child gets to pick the parent. Note that link = metrics can persist across DODAG iterations. I'm not sure I understand the = problem?

 

[Pascal] If the child needs link metrics that the parent = gathers upon messages from the child, then the parent cannot place them in the = first mcast DIO. Some unicast communication must come first to assert the link quality and exchange the perceptions from both ends. At that point, the candidate neighbor becomes a candidate parent. In 07 and I think we lost = a lot of that discussion and se do not even define what candidate parents and neighbors are. I think we need a few words to explain what we expect = from the out-of-scope neighboring mechanism that does a metric aware NUD of some = form.

 

>>[RA] The Parent only needs to convey aggregated = metrics, upward (downward) from itself to the root (from the root to itself). = Even if the Child node needs link statistics that the Parent node gathers, that = would be derived and conveyed through a separate process. =

 

 

Pascal

------=_NextPart_000_01A3_01CAD103.53477720-- From roger.alexander@ekasystems.com Wed Mar 31 15: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 D352B3A6A20 for ; Wed, 31 Mar 2010 15:58:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.407 X-Spam-Level: ** X-Spam-Status: No, score=2.407 tagged_above=-999 required=5 tests=[AWL=0.012, BAYES_40=-0.185, DNS_FROM_OPENWHOIS=1.13, 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 z7+mdSS9pDy6 for ; Wed, 31 Mar 2010 15:58:19 -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 BF9D03A69A0 for ; Wed, 31 Mar 2010 15:58:18 -0700 (PDT) Received: (qmail 63120 invoked from network); 31 Mar 2010 22:58:47 -0000 Received: from dallas (roger.alexander@209.48.242.70 with login) by smtp113.biz.mail.re2.yahoo.com with SMTP; 31 Mar 2010 15:58:47 -0700 PDT X-Yahoo-SMTP: 1dQRPo6swBBzwSsRzMLy_tvdRrLDyF0J X-YMail-OSG: 1YVyNE8VM1n7q4goP7wkycEaNJoNJ1k.up.Bb4Y067yTqtRav2iZ45rCDjb_klW.uM1FeBGSj_L1ASU3AclaCxheWEn2.awHWRdtUkuuqcJXcWYiT.MZFinJwTK1h09NJkcgdDADgQZrzR8tEmRNruLGqsrgALbQlYHvgtrjVOh6CCfNHZLJhLcoc757fEHHlYSuJOyXN79KRbN1to5UjzIL1DjBVi_kegspQ8YDX6fjWZKjoyXnvCtsZRjjjALZ09SOWFwGKFBGsF97nE3DGNdFTVKTnQJHHHWNW62nu1i0U5eD.h0Q07bt5WdM.Ar2m8rEjo97wBttTCVOl.h31.TWHNwdu6nXPrHWnsxqETyCCmTk4YH3S6SM0KrfOlrh X-Yahoo-Newman-Property: ymail-3 From: "Roger Alexander" To: "'Jonathan Hui'" , "'Richard Kelsey'" 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@kelse y-ws.hq.ember.com> <8 AAC1025-AA82-4772-BEDB-A40154A173D9@archrock.com> <87oci42njd.fsf@kelsey-ws.hq.ember.com> In-Reply-To: Date: Wed, 31 Mar 2010 18:57:35 -0400 Message-ID: <01ad01cad125$8dcdf280$a969d780$@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: AcrRG9mwQBzkfYx0SOqvkN31RXd2nwAAUBww Content-Language: en-us 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 22:58:19 -0000 Hi Jonathan, I do think the case of two (or multiple) instances is already supported and could be used to implement separate upward and downward routing with different metrics and objective functions... > -----Original Message----- > From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of > Jonathan Hui > Sent: Wednesday, March 31, 2010 5:48 PM > To: Richard Kelsey > Cc: roll@ietf.org > Subject: Re: [Roll] proposal for DAOs in non-caching DODAGs > > > Richard, > > On Mar 31, 2010, at 2:23 PM, Richard Kelsey wrote: > > >> From: Jonathan Hui > >> Date: Wed, 31 Mar 2010 10:47:22 -0700 > >> > >> I think there isn't any real difference in what you and I are trying > >> to achieve with one or two instances. What I had in mind for the > >> single instance approach is nearly identical to the two instance > >> approach as you indicated. > > > > 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. > > Yes, I agree this is desirable. > > >> I think the two instance solution would make sense if we > >> stick with the current constraint in rpl-07 that DAO > >> parents must be a subset of the DAG parents (i.e. all DAO > >> parents are also DAG parents). > > > > Yes. I am having trouble seeing how DAOs would work if DAO > > parents were not also DAG parents. > > > >> Then all we need is a way to specify whether or not an > >> instance is building upward routes, downward routes, or > >> both. > > > > I think a better way to put it would be to specify how > > asymmetric link metrics are to be combined (downward value > > only, upward value only, max of the two, min of the two, > > average, ...). I will ask JP to open a ticket. > > Metrics are important, yes. But a node also needs to know whether or > not to install forwarding table entries for its DAG parents. If the > instance is only for downward routes, then one approach is to say a > node need not install default/destination forwarding entries. But > maybe this isn't the best approach (see below). > > >> The only other minor issue > >> is whether we need to think through any cases where coordination > >> between the upwards and downwards instances is useful. For example, > >> what needs to happen when packet delivery fails on the downward > >> route? Does the error/backtracking happen on the same instance or a > >> different instance? Do we need to specify such behavior in the core > >> spec? > > > > Again, I do not see how this is different from other > > collections of instances. What happens when a packet > > delivery fails on a low-latency instance? Does the error > > get forwarded on that instance or some other instance? > > > The difference in my mind is whether or not we require all instances > to maintain upward routes. Then backtracking within an instance works > as we have envisioned it so far. If we allow backtracking to occur > across instances, then the benefits of backtracking become less > obvious because you are no longer 'backtracking' in the literal sense > of the word. Of course, this assumes we even want backtracking at all > and I'm not convinced yet... > All instances will be required to maintain, though not necessarily use, upward routes as these are the bases of the DODAG. The 'backtracking' does not have to be across the instances. Another way to think of the two instances would be to consider them as two DODAGs formed on the same root but using different objective functions (OFs); each OF leading to a separate (logical) bidirectional DODAG. On one DODAG the node chooses to send DAOs to get downward routing and in the other the node sends no DAOs but uses preferred Parents for forwarding (the node may need to function as a leaf). The two instances would be distinguished by the RPLInstanceID which would require the node to maintain state and support operation in each instance. > In any case, it seems that we need a mechanism to identify how > instances are tied together (minimally what instance to use what > routes fail). This is the kind of coordination that I was alluding to. > > -- > Jonathan Hui > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From roger.alexander@ekasystems.com Wed Mar 31 16:05: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 0850E3A6827 for ; Wed, 31 Mar 2010 16:05:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.499 X-Spam-Level: ** X-Spam-Status: No, score=2.499 tagged_above=-999 required=5 tests=[AWL=-0.082, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, 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 RI6lFzo8CFUX for ; Wed, 31 Mar 2010 16:05:00 -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 55BDA3A6917 for ; Wed, 31 Mar 2010 16:04:59 -0700 (PDT) Received: (qmail 70334 invoked from network); 31 Mar 2010 23:05:28 -0000 Received: from dallas (roger.alexander@209.48.242.70 with login) by smtp111.biz.mail.re2.yahoo.com with SMTP; 31 Mar 2010 16:05:28 -0700 PDT X-Yahoo-SMTP: 1dQRPo6swBBzwSsRzMLy_tvdRrLDyF0J X-YMail-OSG: rm4cuvQVM1kCQuxhm_Z3.mPM9eI5HypL64ht0ZASERJAVAFquDcPltzDWINqMS1BHHFdlqcoai1dCwcSvA.d6ruKyc7WzfSIzRNH7qSm.MtuVIcT8QqSQFVl69LfBtMkVvbCE.QwifJBSd4Tlh2x9zSxT0FrXSeraxREFQxJ3t7DWa.Cv3vBPZFu6KfBHmp0mJ37MssBU7t1XNwSTCT.m.2fXZ41_2eojOQBQVcF83Kx0jNfdMHrwkwRiA4lHFTlko9On6nr9Kd0YNfIJjSXX8cdmi3RHl0ArMDuBiD5GxH71sk6QPABY4HP2AhT5x9N4l64aPGcTD8UyprURxOI31JqnhXm4C7pv2ON3k9K9Zqmcl5BFonDTbDI1FWlbHjk X-Yahoo-Newman-Property: ymail-3 From: "Roger Alexander" To: "'Mukul Goyal'" , "'Richard Kelsey'" References: <677908518.2401541270072502887.JavaMail.root@mail02.pantherlink.uwm.edu> <643398615.2404291270072768068.JavaMail.root@mail02.pantherlink.uwm.edu> In-Reply-To: <643398615.2404291270072768068.JavaMail.root@mail02.pantherlink.uwm.edu> Date: Wed, 31 Mar 2010 19:04:16 -0400 Message-ID: <01ae01cad126$7cb77240$762656c0$@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: AcrRHXFi1IM+tvTSQQOogOInR2O18AACEh4Q Content-Language: en-us 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 23:05:01 -0000 Hi Mukul, > -----Original Message----- > From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf 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 > > Richard > > >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? > > I guess this is probably not going to be an issue since, even if the > metrics are significantly asymmetrical, a node can simply choose all > its DAO parents as DAG parents but not actually use them for upward > communication. > > I guess we need more opinions. As indicated in my earlier response to Jonathan, it is possible to consider two instances for separate upward and downward routing but unless the intent is to allow for more diverse objective functions, it may be possible with separate directional metrics to use a single instance and so avoid additional potential state and operational overhead. > > Thanks > Mukul > > > > I think the two instance solution would make sense if we > > stick with the current constraint in rpl-07 that DAO > > parents must be a subset of the DAG parents (i.e. all DAO > > parents are also DAG parents). > > Yes. I am having trouble seeing how DAOs would work if DAO > parents were not also DAG parents. > > > Then all we need is a way to specify whether or not an > > instance is building upward routes, downward routes, or > > both. > > I think a better way to put it would be to specify how > asymmetric link metrics are to be combined (downward value > only, upward value only, max of the two, min of the two, > average, ...). I will ask JP to open a ticket. > > > The only other minor issue > > is whether we need to think through any cases where coordination > > between the upwards and downwards instances is useful. For example, > > what needs to happen when packet delivery fails on the downward > > route? Does the error/backtracking happen on the same instance or a > > different instance? Do we need to specify such behavior in the core > > spec? > > Again, I do not see how this is different from other > collections of instances. What happens when a packet > delivery fails on a low-latency instance? Does the error > get forwarded on that instance or some other instance? > > -Richard Kelsey > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From jhui@archrock.com Wed Mar 31 16:10: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 33FC13A6827 for ; Wed, 31 Mar 2010 16:10:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.26 X-Spam-Level: X-Spam-Status: No, score=-1.26 tagged_above=-999 required=5 tests=[AWL=0.209, 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 lg8vfgWxvB09 for ; Wed, 31 Mar 2010 16:10: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 629FE3A67E3 for ; Wed, 31 Mar 2010 16:10:01 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.sf.archrock.com (Postfix) with ESMTP id 259BDAF910; Wed, 31 Mar 2010 16:10: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 laJHhaRPu9UB; Wed, 31 Mar 2010 16:10:28 -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 77A3FAF81F; Wed, 31 Mar 2010 16:10:28 -0700 (PDT) Message-Id: From: Jonathan Hui To: Roger Alexander In-Reply-To: <01ad01cad125$8dcdf280$a969d780$@alexander@ekasystems.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, 31 Mar 2010 16:10:28 -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@kelse y-ws.hq.ember.com> <8 AAC1025-AA82-4772-BEDB-A40154A173D9@archrock.com> <87oci42njd.fsf@kelsey-ws.hq.ember.com> <01ad01cad125$8dcdf280$a969d780$@alexander@ekasystems.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: Wed, 31 Mar 2010 23:10:04 -0000 Hi Roger, On Mar 31, 2010, at 3:57 PM, Roger Alexander wrote: > I do think the case of two (or multiple) instances is already > supported and > could be used to implement separate upward and downward routing with > different metrics and objective functions... Yes, I fully understand that. >> The difference in my mind is whether or not we require all instances >> to maintain upward routes. Then backtracking within an instance >> works >> as we have envisioned it so far. If we allow backtracking to occur >> across instances, then the benefits of backtracking become less >> obvious because you are no longer 'backtracking' in the literal sense >> of the word. Of course, this assumes we even want backtracking at >> all >> and I'm not convinced yet... >> > > All instances will be required to maintain, though not necessarily > use, > upward routes as these are the bases of the DODAG. The > 'backtracking' does > not have to be across the instances. Another way to think of the two > instances would be to consider them as two DODAGs formed on the same > root > but using different objective functions (OFs); each OF leading to a > separate > (logical) bidirectional DODAG. On one DODAG the node chooses to send > DAOs to > get downward routing and in the other the node sends no DAOs but uses > preferred Parents for forwarding (the node may need to function as a > leaf). > The two instances would be distinguished by the RPLInstanceID which > would > require the node to maintain state and support operation in each > instance. Again, I understand that's how you see it to work. My question was whether a node also installs default routes in the forwarding (*not* routing) table for each instance and it seems to be that your answer is 'yes'. Note that if we don't care about 'backtracking', then an instance that is primarily used to maintain downward routes does not need to maintain default routes since RPL messages occur hop-by-hop. -- Jonathan Hui From pal@cs.stanford.edu Wed Mar 31 16:31: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 856493A6A95 for ; Wed, 31 Mar 2010 16:31:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.116 X-Spam-Level: X-Spam-Status: No, score=-5.116 tagged_above=-999 required=5 tests=[AWL=0.353, 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 5vYj35ePv8JW for ; Wed, 31 Mar 2010 16:31:45 -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 159593A6A89 for ; Wed, 31 Mar 2010 16:31:45 -0700 (PDT) Received: from dn0a201858.sunet ([10.32.24.88]) by cs-smtp-1.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1Nx7OS-0008D1-Ia; Wed, 31 Mar 2010 16:32:16 -0700 Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Philip Levis In-Reply-To: <1555819628.2369521270069597858.JavaMail.root@mail02.pantherlink.uwm.edu> Date: Wed, 31 Mar 2010 16:32:16 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <1555819628.2369521270069597858.JavaMail.root@mail02.pantherlink.uwm.edu> To: Mukul Goyal X-Mailer: Apple Mail (2.1077) X-Scan-Signature: 078eb853d78558c6c655f7b6c94b391a 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 23:31:49 -0000 On Mar 31, 2010, at 2:06 PM, Mukul Goyal wrote: >=20 >>> 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? >>=20 >> 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. =20 >=20 > [Phil] So a node A MUST NOT select node B as a parent if the OF cannot = compute the DAGRank of the resulting route? >=20 > 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). I'm sorry -- your sentence is kind of long and convoluted, and I can't = understand it. Does it say yes my sentence is correct or no it is not = correct? Note that my description did not qualify DAO parent, DIO parent, or = direction of the route: I think it's completely independent of this? I = personally think it seems so obvious that it doesn't warrant mention, = but if others feel otherwise, then probably better to include it than = not. Phil= From prvs=7008652d0=mukul@uwm.edu Wed Mar 31 17:42: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 185CE3A67A5 for ; Wed, 31 Mar 2010 17:42:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.812 X-Spam-Level: X-Spam-Status: No, score=0.812 tagged_above=-999 required=5 tests=[AWL=-0.319, 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 TnEctmzJFlNO for ; Wed, 31 Mar 2010 17:42:53 -0700 (PDT) Received: from ip2mta.uwm.edu (ip2mta.uwm.edu [129.89.7.20]) by core3.amsl.com (Postfix) with ESMTP id B5DD63A65A6 for ; Wed, 31 Mar 2010 17:42:53 -0700 (PDT) Received: from mta03.pantherlink.uwm.edu ([129.89.7.83]) by ip2mta.uwm.edu with ESMTP; 31 Mar 2010 19:43:25 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by mta03.pantherlink.uwm.edu (Postfix) with ESMTP id 18CDCC085A1; Wed, 31 Mar 2010 19:43:25 -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 cS39yzNivxGt; Wed, 31 Mar 2010 19:43:24 -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 DF054C085A0; Wed, 31 Mar 2010 19:43:24 -0500 (CDT) Date: Wed, 31 Mar 2010 19:43:24 -0500 (CDT) From: Mukul Goyal To: Philip Levis Message-ID: <1599677532.2460481270082604826.JavaMail.root@mail02.pantherlink.uwm.edu> In-Reply-To: <431449451.2458021270082263217.JavaMail.root@mail02.pantherlink.uwm.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [129.89.7.91] X-Mailer: Zimbra 5.0.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: Thu, 01 Apr 2010 00:42:55 -0000 >>> 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). [Phil] Note that my description did not qualify DAO parent, DIO parent, or direction of the route: I think it's completely independent of this? I think your description is based on an incorrect understanding of DAGrank. [Phil] I personally think it seems so obvious that it doesn't warrant mention, but if others feel otherwise, then probably better to include it than not. Thanks for your support!! Mukul From roger.alexander@ekasystems.com Wed Mar 31 17:47: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 E78C63A68E4 for ; Wed, 31 Mar 2010 17:47:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.689 X-Spam-Level: * X-Spam-Status: No, score=1.689 tagged_above=-999 required=5 tests=[AWL=0.744, BAYES_40=-0.185, 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 wtcIaUxZ9VbY for ; Wed, 31 Mar 2010 17:47:56 -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 EBD103A6858 for ; Wed, 31 Mar 2010 17:47:55 -0700 (PDT) Received: (qmail 53382 invoked from network); 1 Apr 2010 00:48:25 -0000 Received: from [10.121.186.192] (roger.alexander@166.137.9.170 with plain) by smtp114.biz.mail.re2.yahoo.com with SMTP; 31 Mar 2010 17:48:23 -0700 PDT X-Yahoo-SMTP: 1dQRPo6swBBzwSsRzMLy_tvdRrLDyF0J X-YMail-OSG: cj6DnQ4VM1kVBlknii4qciCwc1sq21ZRfwzvKLjHvCcD4a2NkhioCoDYffsxc9Axfam55E50scXte.qcEBvpU64qeHcFmoMBNuzho5oHtlpHrwN2gTT0EHKGnHQpNgCNlD.GntMgxEJxDIFeZW7BFhqb1wcmUGIbwRwfnpZuyaXkCzbLIPaFkxx54zkiFN5lT3YCSmoQGX35zjJhW59XTUcJrEt1MPulrIECK_W.TkoaonOpidJRV6Y9d7SoUAblRKksZSEh7D5mounaEHv2bHZDKS9tD7.mrFVJN1saDScQeIKQ.z5kkI_7rkLyC9U29ri2Pr8PsbCxEEAHvQW9wLkH.IdejYJuqXmizLOS3bH68sNhS7eFy3BBmF4CudgDBYxu4QxTBDUHaTGtumYUiyLoWwoBbmJKr5FCMFjX9UZ8riU5 X-Yahoo-Newman-Property: ymail-3 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@kelse y-ws.hq.ember.com> <8 AAC1025-AA82-4772-BEDB-A40154A173D9@archrock.com> <87oci42njd.fsf@kelsey-ws.hq.ember.com> <01ad01cad125$8dcdf280$a969d780$@alexander@ekasystems.com> Message-Id: <43B6B7A2-650D-45A2-95C9-3B502449BB9A@ekasystems.com> From: Roger Alexander To: Jonathan Hui In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (iPhone Mail 7E18) Date: Wed, 31 Mar 2010 20:43:04 -0400 X-Mailer: iPhone Mail (7E18) Cc: "" 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 00:47:57 -0000 Hi Jonathan, On Mar 31, 2010, at 7:10 PM, Jonathan Hui wrote: > > Hi Roger, > > On Mar 31, 2010, at 3:57 PM, Roger Alexander wrote: > >> I do think the case of two (or multiple) instances is already >> supported and >> could be used to implement separate upward and downward routing with >> different metrics and objective functions... > > Yes, I fully understand that. > >>> The difference in my mind is whether or not we require all instances >>> to maintain upward routes. Then backtracking within an instance >>> works >>> as we have envisioned it so far. If we allow backtracking to occur >>> across instances, then the benefits of backtracking become less >>> obvious because you are no longer 'backtracking' in the literal >>> sense >>> of the word. Of course, this assumes we even want backtracking at >>> all >>> and I'm not convinced yet... >>> >> >> All instances will be required to maintain, though not necessarily >> use, >> upward routes as these are the bases of the DODAG. The >> 'backtracking' does >> not have to be across the instances. Another way to think of the two >> instances would be to consider them as two DODAGs formed on the >> same root >> but using different objective functions (OFs); each OF leading to a >> separate >> (logical) bidirectional DODAG. On one DODAG the node chooses to >> send DAOs to >> get downward routing and in the other the node sends no DAOs but uses >> preferred Parents for forwarding (the node may need to function as >> a leaf). >> The two instances would be distinguished by the RPLInstanceID which >> would >> require the node to maintain state and support operation in each >> instance. > > Again, I understand that's how you see it to work. My question was > whether a node also installs default routes in the forwarding (*not* > routing) table for each instance and it seems to be that your answer > is 'yes'. Note that if we don't care about 'backtracking', then an > instance that is primarily used to maintain downward routes does not > need to maintain default routes since RPL messages occur hop-by-hop. We are fully in synch. However, even if forwarding routes are maintained in both instaces the state requirement may not be very significant being potentially as few as one for the downward instance. > > -- > Jonathan Hui > From jhui@archrock.com Wed Mar 31 19:03: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 3B18D3A67F0 for ; Wed, 31 Mar 2010 19:03:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.833 X-Spam-Level: X-Spam-Status: No, score=-0.833 tagged_above=-999 required=5 tests=[AWL=0.636, 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 Cs7FNs4XuM+o for ; Wed, 31 Mar 2010 19:03:55 -0700 (PDT) Received: from mail.sf.archrock.com (mail.sf.archrock.com [216.121.16.71]) by core3.amsl.com (Postfix) with ESMTP id 7A34A3A659A for ; Wed, 31 Mar 2010 19:03:55 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.sf.archrock.com (Postfix) with ESMTP id 67D26AF9A9; Wed, 31 Mar 2010 19:04:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at Received: from mail.sf.archrock.com ([127.0.0.1]) by localhost (mail.sf.archrock.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Eg9O7nuaUOcH; Wed, 31 Mar 2010 19:04:22 -0700 (PDT) Received: from [10.0.1.5] (adsl-71-142-73-125.dsl.pltn13.pacbell.net [71.142.73.125]) by mail.sf.archrock.com (Postfix) with ESMTP id 8FBDDAF9A6; Wed, 31 Mar 2010 19:04:22 -0700 (PDT) Message-Id: <3778E4BC-1393-4650-94A9-5222FC51B604@archrock.com> From: Jonathan Hui To: Roger Alexander In-Reply-To: <43B6B7A2-650D-45A2-95C9-3B502449BB9A@ekasystems.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, 31 Mar 2010 19:04:21 -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@kelse y-ws.hq.ember.com> <8 AAC1025-AA82-4772-BEDB-A40154A173D9@archrock.com> <87oci42njd.fsf@kelsey-ws.hq.ember.com> <01ad01cad125$8dcdf280$a969d780$@alexander@ekasystems.com> <43B6B7A2-650D-45A2-95C9-3B502449BB9A@ekasystems.com> X-Mailer: Apple Mail (2.936) Cc: "" 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 02:03:56 -0000 Hi Roger, On Mar 31, 2010, at 5:43 PM, Roger Alexander wrote: > On Mar 31, 2010, at 7:10 PM, Jonathan Hui wrote: > >> Again, I understand that's how you see it to work. My question was >> whether a node also installs default routes in the forwarding >> (*not* routing) table for each instance and it seems to be that >> your answer is 'yes'. Note that if we don't care about >> 'backtracking', then an instance that is primarily used to maintain >> downward routes does not need to maintain default routes since RPL >> messages occur hop-by-hop. > > We are fully in synch. However, even if forwarding routes are > maintained in both instaces the state requirement may not be very > significant being potentially as few as one for the downward instance. It was more a question of whether you want to allow arbitrary traffic to utilize any default route table entries generated for a 'downward instance'. Indicating what kind of forwarding table entries you would like to populate (if any) is what I had in mind in indicating what routes you would like an instance to maintain (upward, downward, or both). -- Jonathan Hui From richard.kelsey@ember.com Wed Mar 31 19:05: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 BC6E73A68B3 for ; Wed, 31 Mar 2010 19:05:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.953 X-Spam-Level: X-Spam-Status: No, score=-0.953 tagged_above=-999 required=5 tests=[AWL=0.516, 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 VHRG1ORDCoW6 for ; Wed, 31 Mar 2010 19:05:13 -0700 (PDT) Received: from EMPIRE.hq.ember.com (mail.ember.com [74.10.175.227]) by core3.amsl.com (Postfix) with ESMTP id B23013A659A for ; Wed, 31 Mar 2010 19:05:13 -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, 31 Mar 2010 22:08:40 -0400 Date: Wed, 31 Mar 2010 22:02:23 -0400 Message-Id: <87y6h8nd5c.fsf@kelsey-ws.hq.ember.com> To: Jonathan Hui In-reply-to: (message from Jonathan Hui on Wed, 31 Mar 2010 14:47:59 -0700) From: Richard Kelsey 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@kelse y-ws.hq.ember.com> <8AAC1025-AA82-4772-BEDB-A40154A173D9@archrock.com> <87oci42njd.fsf@kelsey-ws.hq.ember.com> X-OriginalArrivalTime: 01 Apr 2010 02:08:40.0765 (UTC) FILETIME=[3F8ABED0:01CAD140] 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 02:05:14 -0000 > From: Jonathan Hui > Date: Wed, 31 Mar 2010 14:47:59 -0700 > > The difference in my mind is whether or not we require all instances > to maintain upward routes. We don't currently. The DIO 'A' flag which enables/disables upward routes. Do you think that we should require upward routes for all instances? It doesn't seem necessary to me. > Then backtracking within an instance works > as we have envisioned it so far. If we allow backtracking to occur > across instances, then the benefits of backtracking become less > obvious because you are no longer 'backtracking' in the literal sense > of the word. Crossing between DODAGs when forwarding raises the possibility of looping. Care would have to be exercised. > Of course, this assumes we even want backtracking at all > and I'm not convinced yet... Neither am I. > In any case, it seems that we need a mechanism to identify how > instances are tied together (minimally what instance to use what > routes fail). I fully agree. -Richard Kelsey From jhui@archrock.com Wed Mar 31 19:15: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 F13583A6A7B for ; Wed, 31 Mar 2010 19:15:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.939 X-Spam-Level: X-Spam-Status: No, score=-0.939 tagged_above=-999 required=5 tests=[AWL=0.530, 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 A7bRIuF7499U for ; Wed, 31 Mar 2010 19:15:02 -0700 (PDT) Received: from mail.sf.archrock.com (mail.sf.archrock.com [216.121.16.71]) by core3.amsl.com (Postfix) with ESMTP id 5E9693A68FA for ; Wed, 31 Mar 2010 19:14:58 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.sf.archrock.com (Postfix) with ESMTP id B03F0AF9A6; Wed, 31 Mar 2010 19:15:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at Received: from mail.sf.archrock.com ([127.0.0.1]) by localhost (mail.sf.archrock.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YF4MUJuxp7Mh; Wed, 31 Mar 2010 19:15:23 -0700 (PDT) Received: from [10.0.1.5] (adsl-71-142-73-125.dsl.pltn13.pacbell.net [71.142.73.125]) by mail.sf.archrock.com (Postfix) with ESMTP id 43D4CAF937; Wed, 31 Mar 2010 19:15:23 -0700 (PDT) Message-Id: <5DCD0F2A-56CA-4962-A0A5-73E8D5C24F3C@archrock.com> From: Jonathan Hui To: Mukul Goyal In-Reply-To: <1555819628.2369521270069597858.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, 31 Mar 2010 19:15:22 -0700 References: <1555819628.2369521270069597858.JavaMail.root@mail02.pantherlink.uwm.edu> 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 02:15:03 -0000 Mukul, On Mar 31, 2010, at 2:06 PM, Mukul Goyal wrote: >> 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). It's obvious that if A's link cost estimation information about the path from A -> B, then whatever mechanism is used to generate that link cost metric needs to be communicated to be resident at A. It's not obvious to me that the routing protocol should be responsible for make sure this happens. I'd actually prefer that the link estimation mechanism handle the necessary propagation of information. -- Jonathan Hui From richard.kelsey@ember.com Wed Mar 31 19:16: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 6721A3A6890 for ; Wed, 31 Mar 2010 19:16:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.005 X-Spam-Level: X-Spam-Status: No, score=-1.005 tagged_above=-999 required=5 tests=[AWL=0.464, 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 YBp8XjpbaY0c for ; Wed, 31 Mar 2010 19:16:05 -0700 (PDT) Received: from EMPIRE.hq.ember.com (mail.ember.com [74.10.175.227]) by core3.amsl.com (Postfix) with ESMTP id 5528B3A67FA for ; Wed, 31 Mar 2010 19:16:05 -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, 31 Mar 2010 22:19:32 -0400 Date: Wed, 31 Mar 2010 22:13:15 -0400 Message-Id: <87wrwror7o.fsf@kelsey-ws.hq.ember.com> To: Mukul Goyal In-reply-to: <643398615.2404291270072768068.JavaMail.root@mail02.pantherlink.uwm.edu> (message from Mukul Goyal on Wed, 31 Mar 2010 16:59:28 -0500 (CDT)) From: Richard Kelsey References: <643398615.2404291270072768068.JavaMail.root@mail02.pantherlink.uwm.edu> X-OriginalArrivalTime: 01 Apr 2010 02:19:32.0749 (UTC) FILETIME=[C4279BD0:01CAD141] 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 02:16:06 -0000 > Date: Wed, 31 Mar 2010 16:59:28 -0500 (CDT) > From: Mukul Goyal > > 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? I was thinking more of complications in the spec and in implementations than of RAM usage. If we are really concerned about devices having enough RAM for only a single instance, then we should work harder on simplifying the basic protocol. In practice, I would expect severly limited devices to be used in constrained situations such that they would not need to implement the full generality of RPL. In such a situation I do not think that there would be any significant difference in RAM usage between having two instances versus a single instance with multiple ranks, parent sets, and so forth. -Richard Kelsey From richard.kelsey@ember.com Wed Mar 31 19:34: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 51FB93A67BD for ; Wed, 31 Mar 2010 19:34:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.047 X-Spam-Level: X-Spam-Status: No, score=-1.047 tagged_above=-999 required=5 tests=[AWL=0.422, 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 UfwQ-ExeFzPV for ; Wed, 31 Mar 2010 19:34:28 -0700 (PDT) Received: from EMPIRE.hq.ember.com (mail.ember.com [74.10.175.227]) by core3.amsl.com (Postfix) with ESMTP id 3CF953A684A for ; Wed, 31 Mar 2010 19:34:28 -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, 31 Mar 2010 22:37:55 -0400 Date: Wed, 31 Mar 2010 22:31:37 -0400 Message-Id: <87tyrvoqd2.fsf@kelsey-ws.hq.ember.com> To: Richard Kelsey In-reply-to: <87y6h8nd5c.fsf@kelsey-ws.hq.ember.com> (message from Richard Kelsey on Wed, 31 Mar 2010 22:02:23 -0400) From: Richard Kelsey 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@kelse y-ws.hq.ember.com> <8AAC1025-AA82-4772-BEDB-A40154A173D9@archrock.com> <87oci42njd.fsf@kelsey-ws.hq.ember.com> <87y6h8nd5c.fsf@kelsey-ws.hq.ember.com> X-OriginalArrivalTime: 01 Apr 2010 02:37:55.0718 (UTC) FILETIME=[55935260:01CAD144] 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 02:34:29 -0000 > Date: Wed, 31 Mar 2010 22:02:23 -0400 > From: Richard Kelsey > > > From: Jonathan Hui > > Date: Wed, 31 Mar 2010 14:47:59 -0700 > > > > The difference in my mind is whether or not we require all instances > > to maintain upward routes. > > We don't currently. The DIO 'A' flag which enables/disables > upward routes. Do you think that we should require upward > routes for all instances? It doesn't seem necessary to me. Sorry, I got my upward and downward confused. All instances have to maintain parent sets, so at least they have implicit upward routes. If your question is whether all instances have to contribute upward routes for use in forwarding, I would say no. Backtracking would seem to be a separate issue. Can a node return a packet to a parent without having a routing entry pointing that way? In any case, perhaps we can decide whether to use backtracking before worrying about the details of how it is accomplished. -Richard Kelsey From jhui@archrock.com Wed Mar 31 19:40: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 592DA3A683E for ; Wed, 31 Mar 2010 19:40:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.015 X-Spam-Level: X-Spam-Status: No, score=-1.015 tagged_above=-999 required=5 tests=[AWL=0.454, 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 dO2Yke1NS-Sp for ; Wed, 31 Mar 2010 19:40:24 -0700 (PDT) Received: from mail.sf.archrock.com (mail.sf.archrock.com [216.121.16.71]) by core3.amsl.com (Postfix) with ESMTP id 9C6F83A67FA for ; Wed, 31 Mar 2010 19:40:24 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.sf.archrock.com (Postfix) with ESMTP id 6601CAF937; Wed, 31 Mar 2010 19:40:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at Received: from mail.sf.archrock.com ([127.0.0.1]) by localhost (mail.sf.archrock.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hbMgmiaCIJxh; Wed, 31 Mar 2010 19:40:51 -0700 (PDT) Received: from [10.0.1.5] (adsl-71-142-73-125.dsl.pltn13.pacbell.net [71.142.73.125]) by mail.sf.archrock.com (Postfix) with ESMTP id 94E1CAF924; Wed, 31 Mar 2010 19:40:51 -0700 (PDT) Message-Id: <72AAAF46-55EA-45D0-9290-3223009069F1@archrock.com> From: Jonathan Hui To: Richard Kelsey In-Reply-To: <87tyrvoqd2.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: Wed, 31 Mar 2010 19:40:50 -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@kelse y-ws.hq.ember.com> <8AAC1025-AA82-4772-BEDB-A40154A173D9@archrock.com> <87oci42njd.fsf@kelsey-ws.hq.ember.com> <87y6h8nd5c.fsf@kelsey-ws.hq.ember.com> <87tyrvoqd2.fsf@kelsey-ws.hq.ember.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 02:40:25 -0000 Hi Richard, On Mar 31, 2010, at 7:31 PM, Richard Kelsey wrote: >> Date: Wed, 31 Mar 2010 22:02:23 -0400 >> From: Richard Kelsey >> >>> From: Jonathan Hui >>> Date: Wed, 31 Mar 2010 14:47:59 -0700 >>> >>> The difference in my mind is whether or not we require all instances >>> to maintain upward routes. >> >> We don't currently. The DIO 'A' flag which enables/disables >> upward routes. Do you think that we should require upward >> routes for all instances? It doesn't seem necessary to me. > > Sorry, I got my upward and downward confused. Thanks for the clarification. > All instances have to maintain parent sets, so at least they > have implicit upward routes. If your question is whether > all instances have to contribute upward routes for use in > forwarding, I would say no. That's exactly the question I was asking. So I think it would be a good idea to also indicate what kind of forwarding table entries an instance should contribute. That would be in addition to what kind of metrics the instance should use. > Backtracking would seem to be a separate issue. Can a node > return a packet to a parent without having a routing entry > pointing that way? In any case, perhaps we can decide whether > to use backtracking before worrying about the details of how > it is accomplished. Agree. I think it's fair to say that backtracking creates additional complications like the ones I was raising. An additional one is how backtracking works when nodes maintain more than one DAO parent. -- Jonathan Hui From joydeep.tripathi@gmail.com Wed Mar 31 20:30: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 18CC43A68D9 for ; Wed, 31 Mar 2010 20:30:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.76 X-Spam-Level: X-Spam-Status: No, score=0.76 tagged_above=-999 required=5 tests=[AWL=-0.370, 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 0rIPYEjDSbzu for ; Wed, 31 Mar 2010 20:30:44 -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 EA9EC3A63EC for ; Wed, 31 Mar 2010 20:30:43 -0700 (PDT) Received: by bwz9 with SMTP id 9so558957bwz.29 for ; Wed, 31 Mar 2010 20:31:12 -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=lkv8ny7iXVFlEWNT+JdCyKGKIzX2kq2PuuSoBKW8+48=; b=dk0GTCVVS4jUJyvAC33d2jtQhHry8XTfnUTnEm7nVjYZ/RPbTWxGpWNmR415u6jC5v tr070BjTpg7Pahh6nHL8teClIEdm+hXoUhUCQAY/l3d+b6eIp86s1vJgTbrhGAPE7UIU CqdQZM0rDg9gxb6gsaaieOZNc9YYR+43iQLz8= 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=AaWfjlqLQgGMAEIph5pOcQqwIcFFL71CrmVPGqFXEHAMeaMd3HKeESEsRoVGdbMCGs JOOANhwamH0jAz279ED8GwkifWPtUNz7iqSVxkqHSThNU/BjtlL/pmay/R8t3kqvG345 9xhw8a6YPWDLyOKGDWKAyYi55Vnbzt91mITXE= MIME-Version: 1.0 Received: by 10.204.119.12 with HTTP; Wed, 31 Mar 2010 20:31:12 -0700 (PDT) In-Reply-To: References: <19e8ae197e37.197e3719e8ae@drexel.edu> Date: Wed, 31 Mar 2010 23:31:12 -0400 Received: by 10.204.3.216 with SMTP id 24mr601808bko.30.1270092672631; Wed, 31 Mar 2010 20:31:12 -0700 (PDT) Message-ID: From: Joydeep Tripathi To: Philip Levis Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: ROLL WG Subject: Re: [Roll] Fwd: New Version Notification for draft-tripathi-roll-rpl-simulation-03 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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 03:30:45 -0000 On Tue, Mar 30, 2010 at 1:29 PM, Philip Levis wrote: > On Mar 30, 2010, at 12:46 AM, Joydeep Tripathi wrote: > >> Hi, >> >> We published another draft on Simulation results of RPL. In this >> revision, we added path stretch and delay metric comparison of the >> packets in RPL routing with shortest path routing. We also added >> Simulation results of RPL in a typical home/building routing traffic >> scenario. Thanks to Jerry for providing the details of message length >> and distribution in such a network. Note, we did not attempt to use >> any random topology with a random link quality, cause that might not >> provide us with intuition into how real deployment may behave in >> presence of link quality variation and link PDR distribution. We also >> simulate RPL with a 86 node topology, and in process of simulating it >> in another real network of few thousand nodes. >> >> This simulation study shows, the path stretch is very less in >> the home/building routing scenario. Also, the delay bound in RPL is >> not worse than that of shortest path routing, showing P2P routing in >> RPL a viable option for this kind of applications in terms of Path quali= ty. >> >> Looking forward to any comments/suggestions. >> > > Joydeep, > > I have concerns with the simulation methodology. In particular: > > 1) Links are selected randomly. Links in real networks can be correlated = in behavior, either due to hardware variations or correlated environmental = effects (e.g., interference). The problem with random selection is that as = a node has more links, it will inevitably have some good ones. In practice = this isn't always true (e.g., a node is near an interference source). This = will lead the simulation results to think that RPL behaves better than it d= oes in practice. Hi, I understand your concern. But these link data have been gathered from a real network. We will also try acquiring more data, where the link PDR may vary much more faster. We are also in the process a bigger network data and come up with simulation result for a bigger scale real network with real PDR variation. Thanks, Joydeep > > 2) Links vary on the time scale of 10 minutes and have iid losses within = those ten minute intervals. Links are bursty, and protocols respond to burs= ty losses very differently than iid ones. In particular, retransmission pol= icies. > > I'm a big fan of simulation as a debugging tool to find problems early an= d easily. I'm just very wary of using it for any kind of definite conclusio= n. > > Phil > > > From pal@cs.stanford.edu Wed Mar 31 21: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 BF2A13A684A for ; Wed, 31 Mar 2010 21:01:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.171 X-Spam-Level: X-Spam-Status: No, score=-5.171 tagged_above=-999 required=5 tests=[AWL=0.297, 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 oMqVe3B-T6ub for ; Wed, 31 Mar 2010 21:01:43 -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 C31073A68D9 for ; Wed, 31 Mar 2010 21:01:42 -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 1NxBbh-0008ED-Ri; Wed, 31 Mar 2010 21:02:14 -0700 Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: multipart/alternative; boundary=Apple-Mail-18--275911371 From: Philip Levis In-Reply-To: <1599677532.2460481270082604826.JavaMail.root@mail02.pantherlink.uwm.edu> Date: Wed, 31 Mar 2010 19:31:04 -0700 Message-Id: <56FAF6DE-2204-48FE-8E29-3533BEC7BE4A@cs.stanford.edu> References: <1599677532.2460481270082604826.JavaMail.root@mail02.pantherlink.uwm.edu> To: Mukul Goyal X-Mailer: Apple Mail (2.1077) X-Scan-Signature: 4e65f1e2d223ab0b315fa8bf04d06540 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 04:01:49 -0000 --Apple-Mail-18--275911371 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii 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? >>>=20 >>> 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. =20 >>=20 >> [Phil] So a node A MUST NOT select node B as a parent if the OF = cannot compute the DAGRank of the resulting route? >>=20 >> 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). >=20 > [Phil] > I'm sorry -- your sentence is kind of long and convoluted, and I can't = understand it. >=20 > 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). :) >=20 > Hey, I am kidding. Dont get mad at me. >=20 > [Phil] Does it say yes my sentence is correct or no it is not correct? >=20 > 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).=20 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= --Apple-Mail-18--275911371 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
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
= --Apple-Mail-18--275911371-- From pal@cs.stanford.edu Wed Mar 31 21:01: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 91A0A3A6AE7 for ; Wed, 31 Mar 2010 21:01:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.198 X-Spam-Level: X-Spam-Status: No, score=-5.198 tagged_above=-999 required=5 tests=[AWL=0.270, 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 JMFj-KKTSsSo for ; Wed, 31 Mar 2010 21:01: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 D49C13A6AE0 for ; Wed, 31 Mar 2010 21:01:42 -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 1NxBbf-0008ED-SI; Wed, 31 Mar 2010 21:02:12 -0700 Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: multipart/alternative; boundary=Apple-Mail-17--276079673 From: Philip Levis In-Reply-To: <4BB38ECC.5050604@eecs.berkeley.edu> Date: Wed, 31 Mar 2010 19:28:16 -0700 Message-Id: <5BE11B1B-6AAB-44D9-9A9A-87C3147F0476@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> To: Kris Pister X-Mailer: Apple Mail (2.1077) X-Scan-Signature: cd3796f73eb2a5219c1c12913d2c02cf 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 04:01:50 -0000 --Apple-Mail-17--276079673 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Mar 31, 2010, at 11:05 AM, Kris Pister wrote: > Michael Richardson wrote: >>=20 >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >>=20 >>=20 >> =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. >>=20 >> 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 >>=20 >> 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. 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=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 >>=20 >> This is not an active mitm attack, because no packets are actually >> removed or intercepted.=20 >>=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 >> =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. 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? Phil= --Apple-Mail-17--276079673 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii
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?

Phil
--Apple-Mail-17--276079673-- From pal@cs.stanford.edu Wed Mar 31 21:35: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 314CC3A67F0 for ; Wed, 31 Mar 2010 21:35:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.014 X-Spam-Level: X-Spam-Status: No, score=-4.014 tagged_above=-999 required=5 tests=[AWL=-0.959, BAYES_40=-0.185, 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 BMzjbfg5jBea for ; Wed, 31 Mar 2010 21:35:33 -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 1A58C3A67B2 for ; Wed, 31 Mar 2010 21:35:33 -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 1NxC8S-0002Gr-Oz; Wed, 31 Mar 2010 21:36:05 -0700 Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Philip Levis In-Reply-To: Date: Wed, 31 Mar 2010 21:36:04 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <55F65F58-A813-4D50-969B-D17C1C3BC027@cs.stanford.edu> References: <19e8ae197e37.197e3719e8ae@drexel.edu> To: Joydeep Tripathi X-Mailer: Apple Mail (2.1077) X-Scan-Signature: 34530ccd932157cd24ba9d2c27818ca4 Cc: ROLL WG Subject: Re: [Roll] Fwd: New Version Notification for draft-tripathi-roll-rpl-simulation-03 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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 04:35:34 -0000 On Mar 31, 2010, at 8:31 PM, Joydeep Tripathi wrote: > On Tue, Mar 30, 2010 at 1:29 PM, Philip Levis = wrote: >> On Mar 30, 2010, at 12:46 AM, Joydeep Tripathi wrote: >>=20 >>> Hi, >>>=20 >>> We published another draft on Simulation results of RPL. In this >>> revision, we added path stretch and delay metric comparison of the >>> packets in RPL routing with shortest path routing. We also added >>> Simulation results of RPL in a typical home/building routing traffic >>> scenario. Thanks to Jerry for providing the details of message = length >>> and distribution in such a network. Note, we did not attempt to use >>> any random topology with a random link quality, cause that might not >>> provide us with intuition into how real deployment may behave in >>> presence of link quality variation and link PDR distribution. We = also >>> simulate RPL with a 86 node topology, and in process of simulating = it >>> in another real network of few thousand nodes. >>>=20 >>> This simulation study shows, the path stretch is very less in >>> the home/building routing scenario. Also, the delay bound in RPL is >>> not worse than that of shortest path routing, showing P2P routing in >>> RPL a viable option for this kind of applications in terms of Path = quality. >>>=20 >>> Looking forward to any comments/suggestions. >>>=20 >>=20 >> Joydeep, >>=20 >> I have concerns with the simulation methodology. In particular: >>=20 >> 1) Links are selected randomly. Links in real networks can be = correlated in behavior, either due to hardware variations or correlated = environmental effects (e.g., interference). The problem with random = selection is that as a node has more links, it will inevitably have some = good ones. In practice this isn't always true (e.g., a node is near an = interference source). This will lead the simulation results to think = that RPL behaves better than it does in practice. >=20 > Hi, >=20 > I understand your concern. But these link data have been gathered from > a real network. We will also try acquiring more data, where the link > PDR may vary much more faster. We are also in the process a bigger > network data and come up with simulation result for a bigger scale > real network with real PDR variation. Joydeep, I realize those data have been collected from a real network. I collect = data from real networks too. :) The issue is not a network where the link PDR varies much faster: the = issue is the interval over which you compute the PDR. Do you have = experimental evidence that links exhibit iid losses for 10 minute = stretches? This goes against most measurement studies and RF = communication theory. The question here isn't size or scale: it's accuracy. Smoothing over = details such as these can lead to incorrect conclusions. E.g., if a link = has independent losses, the retransmissions can be used for arbitrary = reliability. A simulation could demonstrate perfect reliability with low = latency, something which clearly isn't true in practice. Phil= From pthubert@cisco.com Wed Mar 31 23:36: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 3F4CF3A681F for ; Wed, 31 Mar 2010 23:36:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.682 X-Spam-Level: X-Spam-Status: No, score=-7.682 tagged_above=-999 required=5 tests=[AWL=1.787, 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 C6EO5DdclF23 for ; Wed, 31 Mar 2010 23:36:49 -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 5A9C63A67E1 for ; Wed, 31 Mar 2010 23:36: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: AvsEAGPcs0urR7Ht/2dsb2JhbACbOnGbC5kghQEEjiI X-IronPort-AV: E=Sophos;i="4.51,346,1267401600"; d="scan'208";a="175744598" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-5.cisco.com with ESMTP; 01 Apr 2010 06:37:21 +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 o316bJ2X001828; Thu, 1 Apr 2010 06:37:21 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, 1 Apr 2010 08:37: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: Thu, 1 Apr 2010 08:34:43 +0200 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D01923A2F@XMB-AMS-107.cisco.com> In-Reply-To: <1902982307.2341771270067325823.JavaMail.root@mail02.pantherlink.uwm.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] Mixed mode operation Thread-Index: AcrREM19bqkOxVY3S6CkAvp10DeQNAAUTalQ References: <1857505560.2313361270065100167.JavaMail.root@mail02.pantherlink.uwm.edu> <1902982307.2341771270067325823.JavaMail.root@mail02.pantherlink.uwm.edu> From: "Pascal Thubert (pthubert)" To: "Mukul Goyal" , "Owen Kirby" X-OriginalArrivalTime: 01 Apr 2010 06:37:19.0628 (UTC) FILETIME=[C7220CC0:01CAD165] 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 06:36:51 -0000 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 pushes the saturation problem back up to the root, where it can be handled more easily. At this point, the question is whether the root itself is saturated or not. This problem is common to stateful and source route. And the answer is, again, network planning. As a network evolves and grows, if a root is getting close to capacity, the user needs to deploy an additional root. We could do better than that in some future, by pushing nodes from one DODAG to the next to improve the load balancing between roots. Like I said, I think that can be done. But Phil and JP indicated their reluctance to additional mechanisms, and certainly this has a lesser degree of criticality.=20 Finally, the NACK is just another ACK, with a failure Return code. What the issue is about is having an ACK. I take it that Owen agrees with us that it is useful for stateful? 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. I see what Owen is proposing. What do others think? Pascal > -----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 root is the only > storing node. So if it can not store a DAO, the DAO can not 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 "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 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 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 will come up. > > This is the bare minimum we can do. We already have an issue on this > > 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 > > 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 enough capacity > > 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 > > 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 probably failing > > short when the capacity problem is the routing table in a node hops > > 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 > > 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 the child can > > select an alternate parent for that DAO and the light will come up. > > This is the bare minimum we can do. We already have an issue on this > > 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 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 > >>> appropriately (too small) just causes permanent look ups that > >>> 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 becomes a > >>> deployment issue. Usually what we address there is the bandwidth > >>> capacity on the root radio space. In this thread, the 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 capacity needs > >>> > > is > > > >>> probably divide and conquer, and nothing will replace a proper > >>> capacity planning overall. > >>> > >>> RPL enables DAGs that are made of multiple DODAGs. RPL enables the > >>> radio roots to be connected to a backbone, with a super-root there > >>> > > if > > > >>> you want a single DODAG. RPL dynamically adapts to the addition or > >>> > > the > > > >>> removal of a root in an instance so adapting the capacity to new > >>> requirements has only a local impact on the network. It also adapts > >>> dynamically to the addition of a parent in the DODAG to 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 > >>> somewhere, then we might have an issue with the parent selection. At > >>> the moment, a parent cannot indicate the capacity of its routing > >>> 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 > >>> pushback mechanism from the nodes where the capacity is 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 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 implementation-specific decision. > >> At > >> > > the very > > > >> least, it should be outside the core specification. > >> > >> It's an operational/administrative issue: if the network's routing > >> > > tables are > > > >> overloaded, add another root. Rank and incrementing DODAG sequence > >> 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 From m.pouillot@watteco.com Wed Mar 31 23:55: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 14F4D3A67C0 for ; Wed, 31 Mar 2010 23:55:03 -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=[BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, HELO_EQ_FR=0.35, J_CHICKENPOX_54=0.6, J_CHICKENPOX_73=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 nQFDkmtTulNV for ; Wed, 31 Mar 2010 23:55:02 -0700 (PDT) Received: from mail.abrisite.fr (mx197.abrisite.fr [85.31.209.197]) by core3.amsl.com (Postfix) with ESMTP id A76B13A67AB for ; Wed, 31 Mar 2010 23:55:01 -0700 (PDT) Received: from [192.168.4.247] ([82.241.54.131]) by mail.abrisite.fr (POL Mail Securise v2.0) with ASMTP id JKE78230; Thu, 01 Apr 2010 08:55:30 +0200 Message-ID: <4BB4436B.3090607@watteco.com> Date: Thu, 01 Apr 2010 08:55:39 +0200 From: Mathieu Pouillot User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; fr; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: "Pascal Thubert (pthubert)" , roll@ietf.org References: <6A2A459175DABE4BB11DE2026AA50A5D019233A0@XMB-AMS-107.cisco.com> In-Reply-To: <6A2A459175DABE4BB11DE2026AA50A5D019233A0@XMB-AMS-107.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [Roll] Target in DIO [was Clarification request about RPL] X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: m.pouillot@watteco.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, 01 Apr 2010 06:55:03 -0000 Hi Pascal, Exactly, my mind is near your 3 reasons and I think too an application with a lot of sensor nodes which send automatically sample data to the sink. And for one of them I want to change the number of sample to send, and so I want just to communicate with him at this moment and not to be polluted by all other nodes which have the DAO capability. regards, Mathieu Le 30/03/2010 16:57, Pascal Thubert (pthubert) a écrit : > Hi Mathieu > > You'll note that all nodes do not have to send DAOs. Only destinations > (nodes|prefixes|mcast) that need to be reachable do. > > During this IETF, there were a number of corridor discussions asking the > same question. > > Basically we have this node sitting there in the RPL network and for a > number of reasons, this node is not reachable by some other party in the > network. > > Reasons can be: > - this node is a deep sleeper leaf, does not want to spend everybody's > energy when it does not expect to be reached (your case) > - RPL inconsistency, the route to the node is temporary lost > - another node wants to start a P2P conversation with this node > > In all those cases, it appears that the capability to indicate one or > more targets in a DIO is a useful thing. > > Is that what you are asking for? > > Pascal > > >> -----Original Message----- >> From:roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf >> > Of > >> Mathieu Pouillot >> Sent: Tuesday, March 30, 2010 11:03 AM >> To:roll@ietf.org >> Subject: [Roll] Clarification request about RPL >> >> Hi all, >> >> Watteco is implementing a RPL (draft-05 for the moment) on PLC nodes >> > in a > >> low power and low data rate context. After some tests, we have some >> interogations: >> >> - The DAO request generates a lot of traffic on the network, and most >> > of the > >> time it is not necessary to have the downward routes of all devices. >> Is there a mechanism to ask a DAO to specified devices? If not, what >> > do you > >> think to add a sub-option in the DIO to ask DAO to a specified device >> > or > >> maybe(more complex) a group of devices? >> - A point that is not very clear: Can the same node belong to several >> > DoDag of > >> the same instance? If yes, how the data traffic(UDP,TCP, or >> others) knows which route has to be used? By the way, when you are in >> different instance how the flow label has to be filled? >> - Is there a way to broadcast or multicast some data traffic in all >> > our DoDag? > >> - Is there a mechanism to annonce a broken route during data traffic? >> >> Thanks for the clarifications, >> >> best regards, >> >> Mathieu >> >> -- >> Mathieu Pouillot >> R&D Engineer >> m.pouillot@watteco.com >> >> Tel : +33(0)4 98 01 60 05 (Poste 43) >> Fax : +33(0)4 94 14 10 80 >> 1766 Chemin de la Planquette >> 83130 LA GARDE - France >> www.watteco.com >> >> _______________________________________________ >> Roll mailing list >> Roll@ietf.org >> https://www.ietf.org/mailman/listinfo/roll >> > -- Mathieu Pouillot R&D Engineer m.pouillot@watteco.com Tel : +33(0)4 98 01 60 05 (Poste 43) Fax : +33(0)4 94 14 10 80 1766 Chemin de la Planquette 83130 LA GARDE - France www.watteco.com From pthubert@cisco.com Wed Mar 31 23:56: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 874A93A694C for ; Wed, 31 Mar 2010 23:56:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.759 X-Spam-Level: X-Spam-Status: No, score=-7.759 tagged_above=-999 required=5 tests=[AWL=1.710, 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 tNQ20xyJh4Xo for ; Wed, 31 Mar 2010 23:56: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 93E413A6958 for ; Wed, 31 Mar 2010 23:56:39 -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: AvsEAJrgs0urR7H+/2dsb2JhbACbOnGacJkfglKCLwQ X-IronPort-AV: E=Sophos;i="4.51,346,1267401600"; d="scan'208";a="108634207" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-4.cisco.com with ESMTP; 01 Apr 2010 06:57:11 +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 o316v4lo024115; Thu, 1 Apr 2010 06:57: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); Thu, 1 Apr 2010 08:57: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: Thu, 1 Apr 2010 08:57:04 +0200 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D01923A3D@XMB-AMS-107.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] proposal for DAOs in non-caching DODAGs Thread-Index: AcrRG+KF+imymKoQTTmklaiM+o9U3QAS/EHQ 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> From: "Pascal Thubert (pthubert)" To: "Jonathan Hui" , "Richard Kelsey" X-OriginalArrivalTime: 01 Apr 2010 06:57:08.0480 (UTC) FILETIME=[8BBE7800:01CAD168] 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 06:56:42 -0000 Hi Jonathan: 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. The question is rather which instance is applied to a packet before the packet is sent out.=20 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. Pascal > -----Original Message----- > From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of > Jonathan Hui > Sent: Wednesday, March 31, 2010 11:48 PM > To: Richard Kelsey > Cc: roll@ietf.org > Subject: Re: [Roll] proposal for DAOs in non-caching DODAGs >=20 >=20 > Richard, >=20 > On Mar 31, 2010, at 2:23 PM, Richard Kelsey wrote: >=20 > >> From: Jonathan Hui > >> Date: Wed, 31 Mar 2010 10:47:22 -0700 > >> > >> I think there isn't any real difference in what you and I are trying > >> to achieve with one or two instances. What I had in mind for the > >> single instance approach is nearly identical to the two instance > >> approach as you indicated. > > > > 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. >=20 > Yes, I agree this is desirable. >=20 > >> I think the two instance solution would make sense if we stick with > >> the current constraint in rpl-07 that DAO parents must be a subset of > >> the DAG parents (i.e. all DAO parents are also DAG parents). > > > > Yes. I am having trouble seeing how DAOs would work if DAO parents > > were not also DAG parents. > > > >> Then all we need is a way to specify whether or not an instance is > >> building upward routes, downward routes, or both. > > > > I think a better way to put it would be to specify how asymmetric link > > metrics are to be combined (downward value only, upward value only, > > max of the two, min of the two, average, ...). I will ask JP to open > > a ticket. >=20 > Metrics are important, yes. But a node also needs to know whether or not to > install forwarding table entries for its DAG parents. If the instance is only for > downward routes, then one approach is to say a node need not install > default/destination forwarding entries. But maybe this isn't the best > approach (see below). >=20 > >> The only other minor issue > >> is whether we need to think through any cases where coordination > >> between the upwards and downwards instances is useful. For example, > >> what needs to happen when packet delivery fails on the downward > >> route? Does the error/backtracking happen on the same instance or a > >> different instance? Do we need to specify such behavior in the core > >> spec? > > > > Again, I do not see how this is different from other collections of > > instances. What happens when a packet delivery fails on a low-latency > > instance? Does the error get forwarded on that instance or some other > > instance? >=20 >=20 > The difference in my mind is whether or not we require all instances to > maintain upward routes. Then backtracking within an instance works as we > have envisioned it so far. If we allow backtracking to occur across instances, > then the benefits of backtracking become less obvious because you are no > longer 'backtracking' in the literal sense of the word. Of course, this assumes > we even want backtracking at all and I'm not convinced yet... >=20 > In any case, it seems that we need a mechanism to identify how instances > are tied together (minimally what instance to use what routes fail). This is > the kind of coordination that I was alluding to. >=20 > -- > Jonathan Hui >=20 > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll
On Sun, Mar 21, 2010 at 6:40 PM, Pascal Thubert = (pthubert) <pthu= bert@cisco.com> wrote:
Hi Dominique:

I'd add= that it can be interesting for a node to specify what it is
looking for= , like the instance that it belongs to and for which it is
searching for a parent.

Yes, you have my support to make this a tick= et.

Pascal


> -----Original Message-----
> From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf<= br> Of
> dominiqu= e.barthel@orange-ftgroup.com
> Sent: Friday, March 19, 2010 10:45= AM
> To: roll@ietf.org
> = Subject: [Roll] Options in DIS
>
> Hi all,
>
> I have already expressed a desire for = options in the DIS packet
> http://www.ietf.org/ma= il-archive/web/roll/current/msg02765.html
> Jerry and Mukul expressed their support to the request.
> http://www.ietf.org/mail-archive/web/roll/current/msg02766.htm= l
> http://www.ietf.org/mail-archive/web/roll/current/m= sg02770.html
>
> Then Phil asked for a justification for th= e request, which I admit I
> haven't provided yet.
> http://www.ietf.o= rg/mail-archive/web/roll/current/msg02774.html
>
> More rec= ently, Tzeta suggested that DIS have security options
> http://www.ietf.org/mail-archive/web/roll/current/m= sg03101.html
>
> Independently, Yaov and Matteo both again = expressed the need for DIS
> option.
> http://www.ietf.org/mail-archive/we= b/roll/current/msg03185.html
> http://www.ietf= .org/mail-archive/web/roll/current/msg03290.html
>
> I do believe we have a serious point here.
> Please find= the justification below.
> Can we please have a ticket to work on it= ?
> I volunteer to gather others contributors' opinions/requests= and and
> propose detailed text to be included in future revisions of the RPL> draft.
> Best,
>
> Dominique
>
> ------= -------------------------------------
> The following is extracted fr= om a typical water/gas smart metering
> infrastructure.
> The utility company worker adds new metering p= oints into the network
as
> meters are replaced or fitted with sen= sing/transmission =A0electronics.
> Before the worker leaves the prem= ises, he/she is requested to check
that
> the meter has actually joined the network.
> This cannot= wait for a trickled-down DAO to arrive.
> Therefore, the meter will = send a DIS to collect information from the
> network.
> Without= DIS options, all neighbor routers will respond, spending
energy
> for their own transmission and triggering energy expenditure= in =A0all
> neighbor nodes that overhear the responses.
>
&= gt; Let's consider a "wheel" model for the network topology, = with a sink
at
> the center and spokes connecting outward to ring-1 routers, ring= -2
> routers and periphery meters. The meters have routing capability=
> themselves, although I'll call them meters in the following te= xt to
> distinguish them from devices solely intended at providing
connecti= vity,
> which I'll call routers.
> Let's consider a gen= eric "pizza slice" of this wheel. Since there's
> centr= al symmetry in the network, there's no border effect in the slice
> We typically have
> - one mains-powered sink at the center,
&= gt; - N severely energy-limited meters at the periphery, deeply burried
= into
> basements or manholes
> - N/20 fairly energy-limited rin= g-1 routers, located on high spots
> - N/10 fairly energy-limited ring-2 routers, located on high spots
= > In RPL parlance, ring-1 routers would have a typical rank of 4, and> ring-2 routers would have a typical rank of 8
> The N/10 and N/= 20 ratios above are dictated by energy/lifetime
> considerations, not radio coverage.
> A typical connectivity is = the following
> - each meter is in range of N/10 and N/20 routers, al= beit with *very*
> different link qualities
> - each router is = in range of N/10 and N/20 routers, with various link
> qualities
> - each meter is in range of N/20 meters
> The = ratios and assumptions above hold for values of N in the [20..200]
> = range.
>
> **** Without DIS options, we have
> NT0 =3D Nu= mber of DIS multicast transmission =3D 1
> NR0 =3D Number of DIS active receptions =3D N/5 (due to N/20 meters an= d
> (N/10+N/20) routeurs),
> NT1 =3D N/20 DIO transmissions fro= m meters; each one being overheard by
> N/20 meters and (N/10+N/20) r= outers
> NT2 =3D N/10+N/20 DIO transmissions from routers; each one being
ov= erheard
> by N meters and (N/10+N/20) routers
> NR1 ~=3D NT1 * = (3N/20 + N/20) =3D N^2/100 =3D 0.01 * N^2 receptions due to
DIO
> = coming from meters
> NR2 ~=3D NT2 * (N + N/20 + N/10) =3D N^2*69/400 =3D 0.17 * N^2 recepti= ons
due
> to DIO coming from routers
>
> We therefore = have
> Number of transmissions: NT =3D NT0 + NT1 + NT2 =3D 1 + N/20 += (N/10 +
N/20)
> =3D 24/20 * N =3D 1 + 0.2 * N
> Number of receptions = =A0 : NR =3D NR0 + NR1 + NR2 =3D 0.2 * N + 0.18 * N^2
>
> Total= energy cost Etotal =3D NT * Et + NR * Er
>
> If the network is= asynchronous and uses basic preamble sampling, the
> cost of overhearing Eo is the cost of receiving the expected duration<= br>> (half) of the preamble.
> Since the DIS packet is small, its = unit reception cost Er is about the
> same as the overhearing cost Eo= .
> With a small (<1KB) DIO packet, the cost of transmission Et is
&= gt; essentially the cost of sending the preamble.
> Let's assume = transmission cost Et is 6 times Eo (full preamble length
> accounts f= or x2, power consumption for x3)
>
> Etotal ~=3D Eo * ( 1 * 6 + N * (0.2 * 6 + 0.2) + 0.18 * N^2) ~= =3D Eo * ( 6
+
> 1.4 * N + 0.18 * N^2)
>
> **** With D= IS options
> A typical protocol currently in use in widely deployed p= roprietary
smart
> metering networks is the following.
> Newborn nodes sen= d successive DIS'es with decreasing demands on rank
> and
>= link quality
> - iteration 1: only sinks, LQI >=3D 0,75*maxLQI > - iteration 2: only sinks, LQI >=3D 0,5*maxLQI
> - iteration = 3: only sinks, LQI >=3D 0,25*maxLQI
> - iteration 4: ring-1 router= s, LQI >=3D 0,75*maxLQI,
> - iteration 5: ring-1 routers, LQI >= =3D 0,50*maxLQI,
> - iteration 6: ring-1 routers, LQI >=3D 0,25*maxLQI,
> - iter= ation 7: ring-2 routers, LQI >=3D 0,75*maxLQI,
> - iteration 8: ri= ng-2 routers, LQI >=3D 0,50*maxLQI,
> - iteration 9: ring-2 router= s, LQI >=3D 0,25*maxLQI,
> - etc
> The newborn node will usually send several DIS's ins= tead of just one.
> Its direct neighbors (N/20 meters, N/10+N/20 rout= ers) will also incur
> the cost of receiving these extra DIS'es.<= br> > Let's suppose iteration 7 is successful and prompts 25% of the
= neighbor
> ring-2 routers to send their DIOs.
> Number of DIS t= ransmissions =3D 7
> Number of DIS receptions =3D 7 * (N/20 + N/10 + = N/20) =3D 7/5 * N
> Number of DIO transmissions =3D 25% of N/10 =3D N/40, overheard by 23/= 20 *
N
> nodes (N meters and N/10+N/20 routers).
> Number of= DIOs overheard =3D 23/800 * N^2 =3D 0.029 * N^2
> Etotal ~=3D Eo * (= 7*6 + N * ( 7/5 + 6/40) + 0.029 * N^2) ~=3D Eo * (42 +
> 1.6 * N + 0.029 * N^2)
>
> In this case, the global energy= cost of inserting a new node in the
> network is reduced by a factor= ranging from 2 to 5 depending on N in
> [20..200]. Additional analys= is shows that this saving affect both
meters
> and routers (specifically, we are not pushing the burden tow= ards the
> energy-critical meters).
> Similar results are obtai= ned with differents iterations numbers.
>
> Just to re-inforce = this calculation, it has been our experience that
> node insertion into a dense low-power network, if done wrong, is a
= > significant energy drain. Please let us enhance RPL to do it right.> _______________________________________________
> Roll mailing = list
> Roll@ietf.org
> https://www.i= etf.org/mailman/listinfo/roll
______________________________________= _________
Roll mailing list
Roll@ietf.org
= ht= tps://www.ietf.org/mailman/listinfo/roll

--0016e6497e383fbf0d04825f6477-- From root@core3.amsl.com Mon Mar 22 01:30:07 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 8C61F3A6B2E; Mon, 22 Mar 2010 01:30:05 -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: <20100322083007.8C61F3A6B2E@core3.amsl.com> Date: Mon, 22 Mar 2010 01:30:06 -0700 (PDT) Cc: roll@ietf.org Subject: [Roll] I-D Action:draft-ietf-roll-routing-metrics-05.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Mar 2010 08:30:07 -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-05.txt Pages : 29 Date : 2010-03-22 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-05.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-roll-routing-metrics-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-03-22011641.I-D@ietf.org> --NextPart-- From abr@sdesigns.dk Mon Mar 22 07:48: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 1E4293A691D for ; Mon, 22 Mar 2010 07:48:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.452 X-Spam-Level: X-Spam-Status: No, score=0.452 tagged_above=-999 required=5 tests=[AWL=-1.276, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, HTML_MESSAGE=0.001, J_CHICKENPOX_12=0.6, J_CHICKENPOX_17=0.6, J_CHICKENPOX_51=0.6, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eVQIKgICZWPU for ; Mon, 22 Mar 2010 07:48: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 A20AA3A686C for ; Mon, 22 Mar 2010 07:48:07 -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_01CAC9CE.B92FD6DE" Date: Mon, 22 Mar 2010 15:46:20 +0100 Message-ID: <6D9687E95918C04A8B30A7D6DA805A3E01AD45CF@zensys17.zensys.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] P2P performance with current RPL proposal Thread-Index: AcrJk+JCuyMtok55QmizMYmRCE2g7gAOo17n References: <1161577952.8138041269244020805.JavaMail.root@mail02.pantherlink.uwm.edu> From: "Anders Brandt" To: "Mukul Goyal" , "Pascal Thubert (pthubert)" Cc: ROLL WG , Ted Humpal Subject: Re: [Roll] P2P performance with current RPL proposal X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Mar 2010 14:48:21 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CAC9CE.B92FD6DE Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Add to this an element of promiscuos listening to dampen the storm =3D> = if node already detected a copy of the DIS with the same TTL (or lower) = - do not forward the DIS. Then you start getting closer to something. =20 Oh - and by the way - record the source route on the way ;-) =20 - Anders ________________________________ Fra: roll-bounces@ietf.org p=E5 vegne af Mukul Goyal Sendt: ma 22-03-2010 01:47 Til: Pascal Thubert (pthubert) Cc: ROLL WG; Ted Humpal Emne: Re: [Roll] P2P performance with current RPL proposal Hi Pascal Thanks for your comments (let me send my response in the next email). Based on further thoughts, it seems to me that a DAG based P2P solution = would work if we do the following: (a) allowing multicast DIS messages to spread to an originator-specified = number of hops and (b) allowing nodes to join a DAG temporarily and leave it if there is = not sufficient "routing interest" in being part of the DAG. With these points in mind, a P2P scheme could work as follows: 1. When a node wants to join a DODAG(D,F), where D is the DODAG's root = and F is the OF being used, it does the following: a. Initiates a discovery table entry for DODAG(D,F). The discovery = table entries are removed after a certain lifetime. b. sends out a DIS via link-local multicast asking specifically for = information about DODAG(D,F). It also lists in the DIS the number of = hops the DIS can travel. 2. On receiving a DIS, a node does the following: a.if it does not know about DODAG(D,F) and the DIS hop limit is not = yet reached i. Initiates a discovery table entry for DODAG(D,F). This entry = maintains information about the nodes from whom the DIS were received. ii. sends out the DIS (via link-local multicast with trickle = controlled timing) further. b. If it is already a part of DODAG(D,F) or is node D itself i. Send out a DIO about DODAG(D,F) to the node from whom the DIS = was received. 3. On receiving a DIO about DODAG(D,F), a node does the following: a. Ignore the DIO if the node does not have a discovery table entry = for DODAG(D,F) b. Otherwise, the node joins the DODAG(D,F) (if not already part of = it) or updates its parent set in DODAG(D,F) and sends the DIO by unicast = to the nodes that had sent it the DIS. 4. Once, the node is part of the DODAG(D,F), it maintains a "routing = interest" for the DODAG in the following manner: a. Routing interest is a value between 0 and 1 b. Routing interest is 1 if the node recently forwarded a packet = along the DODAG(D,F) c. Otherwise, the routing interest is x*maximum routing interest of = the neighbors in DODAG(D,F), where x is a fraction. The node comes to = know of neighbor's routing interest via the neighbor's DIO. d. A node leaves a DODAG if its routing interest in the DODAG goes = below a threshold. Thanks Mukul ----- Original Message ----- From: "Pascal Thubert (pthubert)" To: "Mukul Goyal" Cc: "ROLL WG" , "Ted Humpal" , = "robert cragie" Sent: Friday, March 19, 2010 11:20:58 AM GMT -06:00 US/Canada Central Subject: RE: [Roll] P2P performance with current RPL proposal Hi Mukul > Here I have attempted to formulate a simple DV algorithm in RPL/DAG = terms. > I will appreciate it if you could let me know about your objections to = this > proposal: [Pascal] It's cool that you do it is the first impression. > Node A needs to reach a destination D. Node A initiates a discovery = DAG > towards D. As the DIOs reach D, it sends a DAO back to selected = parents. As > the DAO travels towards node A, in-route nodes store the cost to reach = D. > > When node B needs to reach D, it similarly initiates a discovery dag. = During > this discovery, when a DIO reaches a node C that maintains a cost to = reach D, > node C responds back with a DAO that travels towards B and stores in = in- > route nodes the cost to reach D. [Pascal] understand that you're trying to make RPL even closer to AODV. I agree we need to gather as much as we can from that work. For the specifics of your proposal: - B-C might be orthogonal to A-D so that B/C\D forms an angle. You do = not end up with the best path that you're looking for. - there might be multiple C's. Which one is the right one? - RPL does not allow packets to switch instances. Following multiple = DAGs is the recipe for loops - unless you have them strictly ordered by = some means like the RPL sequence between iterations, more specific = routes, blah blah...) - the A to D path is optimized for a certain constraint. You seem to = imply that the B to D path has the same constraints and metrics so we = can compare apple to apple. Because this is a very delicate operation, = RPL has introduced the Rank, which has the right properties to make that = comparison efficiently.So for RPL, the loop avoidance metric is the = Rank, and it is only valid within an iteration. - A P2P path does not come out of the blue. There must be some = provisionning system that determines that those nodes, A and B, are very = special so they need a P2P optimization, with a given special OF, and = that they both need to talk to D. Well, if that's so, the most = economical is for that system to fork the DAG out of D, with dual = targets A and B. There you obtain the shortest path for both A-D and B-D = for the cost of a single flooding. I see that you're trying to get the idea to work better, and I hope we = find a way to do so, maybe along your lines if we can solve the issues = above. But before we get there, we need to agree that this is the path = we wish to take. Cheers, Pascal > > ----- Original Message ----- > From: "Pascal Thubert (pthubert)" > To: "robert cragie" > Cc: "ROLL WG" , "Ted Humpal" > Sent: Thursday, March 18, 2010 9:23:14 PM GMT -06:00 US/Canada Central > Subject: Re: [Roll] P2P performance with current RPL proposal > > > > > > Hi Robert : > > > > At least from a distance, the proposed mechanism emulates AODV, with = the > DIO as RREQ and the DAO as RREP. So if we decide to dig along those = lines, > we'll certainly appreciate help from MANET experts. I'd say that if = you > already have RPL for P2MP and MP2P, the proposed extension are = probably > simpler to add than doing AODV from scratch. > > > > For the setup, the major differences are that we build a DAG and that = we can > indicate multiple targets. If you look at it, the DAG capability is a = MUST for > RPL, and I have not seen that this MUST goes away for P2P flows. The > multiple targets is something that appears in a number of use cases = and it > seems more economical to build a single DAG for multiple targets when > possible. > > > > For the maintenance, the major differences are that we have the DAG as > first line of defense, and the RPL detection to stimulate the local = repair. > > > > About your questions: > > > > The DODAG root is the one that spawns the DAG. The targets can reach = the > root because the root advertises itself in the DIO. The idea is that = the root ID > is the address that the targets need to talk to. If needed, the root = can also > advertise a prefix that it can reach and that the targets need to = reach too. > > > > All the intermediate nodes that are confirmed by the DAO need to = retain at > least info about the DAG. That enables the targets to reach the root. = The > flooding should cost about the same as that of AODV but the RPL way = will > require more states in the nodes on the way if the OF requires a DAG. > > > > The way back (down) can be stateful of stateless, depending on which = DAO > we're using. With fully stateful DAO, we are really in AODV-land. With > stateless, we could drift into DSR-land for that direction. Which = limits we > place to keep it simple will be determined by the resolution of issue = #26 I > guess... > > > > And please, no apologize or on one will dare post anything anymore. = Your > questions are fully relevant and at the core of the discussion. > > > > I hope we can talk in Anaheim for sure, > > > > > Pascal > > > > > > > From: Robert Cragie [mailto:robert.cragie@gridmerge.com] > Sent: Monday, March 15, 2010 11:27 AM > To: Pascal Thubert (pth ubert) > Cc: Ted.Humpal@jci.com; ROLL WG > Subject: Re: [Roll] P2P performance with current RPL proposal > > > > Hi Pascal, > > So in your slideware T can end up talking to R (DODAG root) through = the > DODAG. So are you proposing that all potential targets can act as a = DODAG > root? And therefore all intermediates have to retain DIO propagation > support for that DODAG as well? This may work for limited P2P but = seems > less efficient than simple distance vector flooding RREQ/RREP like = AODV or > DYMO for generic P2P. What about R to T (or anyone else for that = matter)? > Do we source route, maintain state, some undefined hybrid of the two? > > I apologise if some of these questions have been answered in detail in = earlier > reflector posts but I have only recently started to concentrate my = efforts on > RPL and have 82 pages to wade through :-). I look forward to a = productive > session in Anaheim. > > Robert > > > Robert Cragie (Pacific Gas & Electric) > > Gridmerge Ltd. > 89 Greenfield Crescent, > Wakefield, WF4 4WA, UK > +44 (0) 1924 910888 > http://www.gridmerge.com =20 > > > > Pascal Thubert (pthubert) wrote: > > HI Robert : > > > > I respectfully have to disagree. > > > > My understanding is that we are considering a limited set of P2P = pairs, for > which the specific path that we need to create might have to obey = specific > constraints. > > So it makes sense to use an on-demand technique, probably inspired by = the > MANET Reactive protocols. > > > > As it goes, those protocols usually use flooding for a node to locate = another. > Forking a DAG is just another flooding. It does not take a lot of = addition to the > existing DIO for a root to use RPL to build a DAG that contains one or = multiple > Targets as leaves, under a set of constraints expressed as an = objective > function. Please find attached a slideware that illustrates that. > > > > > Pascal > > > > > > > From: roll-bounces@ietf.org [ mailto:roll-bounces@ietf.org ] On Behalf = Of > Robert Cragie > Sent: Thursday, March 11, 2010 2:43 PM > To: Ted.Humpal@jci.com > Cc: ROLL WG > Subject: Re: [Roll] P2P performance with current RPL proposal > > > > I agree with Ted's comments below. Creating a DODAG for every = reachable > node as a root seems a very inefficient approach compared to = alternative > routing algorithms. I am concerned that RPL does not actually meet the > original requirements in I-D.ietf-roll-building-routing-reqs, = I-D.ietf-roll-home- > routing-reqs, RFC5673 and RFC5548. The traffic pattern requirement for = a > sink node features prominently in only two of those documents. Even in = this > case, as Ted points out, communication is likely to be bidirectional = (e.g. end- > to-end acks.) therefore the DODAG approach is fundamentally = asymmetric, > especially if no intermediate storage is allowed for destination = routes and > source routing has to be used. > > Also, RPL seems highly complex for what are constrained nodes in terms = of > memory as well as power and bandwidth. The RPL draft as it stands is = 82 > pages long and that doesn't include text about the objective function. > > Robert > > > Robert Cragie (Pacific Gas & Electric) > > Gridmerge Ltd. > 89 Greenfield Crescent, > Wakefield, WF4 4WA, UK > +44 (0) 1924 910888 > http://www.gridmerge.com =20 > > > > Ted.Humpal@jci.com wrote: > > > A concern also will be how much overhead (memory space) will be = required > for a DODAG Root? > > and based on the first question how many DODAG roots a lamp may need = to > be a member of? > > For example in lighting a single lamp may be a root for a single = switch (1 > DODAG root), this lamp / luminaire may also > be a member of another group - - which could be all lights on the = floor (2nd > DODAG root), and a third group > of all the lights in the building. There can be many more speciality = groups > associated based on the building configuration. > Consider also during the installation time - how these DODAG roots = will be > configured? Must I commission each device > to tell it which DODAG it must use for its Object Function? How easy = will this > be to change and add in a new DODAG root > for the end user if the lighting group changes?? > > With respect to Jerry Martocci's - commercial building requirements - = every > device may need to communicate to any or > all of the end devices. If each device must establish a DODAG for the = other > 499 devices in a 500 node network - How much memory > space will this require for each end device to maintain? > > Keep in mind that the end devices are very limited processor and = memory > wise. > > Not to mention all of the network maintenance messages that would need > to be transmitted to maintain all of these DODAGs. > > Consider the reconvergence time when one device is turned off and it = was in > the middle of the majority of the 100+ DODAGS? > > In many lighting and building application an application = acknowledgement - > must be returned {Back down the DODAG} so . . . the > requirement is not just getting to the Root - a return path must also = be > maintained and have a low latency path. > > Ted Humpal > > > > > > > From: > > Kris Pister > > > To: > > Anders Brandt > > > Cc: > > ROLL WG > > > Date: > > 03/08/2010 01:45 PM > > > Subject: > > Re: [Roll] P2P performance with current RPL proposal > > > > > > > > > Anders - if we take JP's suggestion to make The Lamp a DODAG root, and > take Phoebus' recommendation that we use path diversity to improve = end- > to-end reliability, do you see a chance of success? > In my experience, with diverse paths and order-minutes updates you get > extremely high reliability. > > I have no aversion to TTL-limited floods as a part of a solution = either. I'm > open to ideas on how to bring those in as (presumably infrequently = used) > options. > > ksjp > > Anders Brandt wrote: > Hello > > I would like to probe the temperature of the WG on using DAOs to > support P2P. > > The building and home application spaces (and maybe others) have > a few clearly defined requirements. > It is not obvious to me how the current RPL proposal (cRPLp) can > satisfy those requirements: > > > In both cases it is the worst case scenario that hurts: > > > P2P routing inside the PAN > = =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 > cRPLp has no way of routing inside the PAN if you need more than > one repeater. cRPLp has to go all the way to the top (maybe 4 hops up) > and down again (maybe 4 hops down) to get just 2 hops to the side. > > The consequence is high latency and high levels of background noise > for nodes just outside the direct radio range. > At the same time the risk of meeting a failing link is 4 times higher = =3D> > latency may be much more than 4 times larger. > > Latency may sound like a minor issue but it actually translates = directly > into lower battery lifetime. In the above (very realistic) example, > the battery lifetime is reduced to 25% of what it should be. > > We have lots of battery devices sending into the network: > * PIR sensors turning on lights > * Door locks sending alarms > * Door/window sensors starting chimes > * Smoke sensors triggering an alarm system > > > > > Response time > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > The latency issue is important. > When a user (real human being) presses a light button the user expects > the light to turn on. > cRPLp proposes that nodes in the tree periodically advertises their > presence using DAOs. > The periodicity is a real beast: > Thanks to Trickle, the rate of updates in a (apparently) stable = network > is low. This is good since it leaves bandwidth for data. > But it is not good if existing routes to my lamp fail and I do not get > new routes to my lamp until it decides to send out a new DAO. > My user will (with a good reason) not tolerate waiting for minutes for > the light to turn on. > > I have met two arguments to counter this concern: > > A1: Well, your lamp can always send a DAO when it detects a problem. > My answer: > True, except that my lamp does not intend to send anything > so it will never experience any problems from its side of the = network. > > A2: Well, you can increase the DAO rate to sub-second updates. > My answer: > Oh no. I get a very high degree of management traffic which > limits my available bandwidth, increases the risk of collisions and > even run the risk of violating EU legislation requiring me to only > transmit in less than 1% of the time: > http://focus.ti.com/lit/an/swra048/swra048.pdf > 868 - 868.6 MHz: <1% > > Reactiveness is hard to achieve via polling. > > > > If you agree that this seems to be critical issues please raise your > voice on the list. > > Going forward > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > We need some reactive mechanism to reach lamps before the user decides > to sue our companies. > So is this possible? I think so. > > Existing commercial (non-IP) solutions are capable of re-routing = quickly > if they really have to. > > Let me try scoping the requirements to a potential solution: > (no different from the req. docs for home and building) > > * P2P routing in any direction independent of the tree. > > * On-demand P2P route discovery if requested by a real-time critical = app. > Data collection apps may be able to just wait for the next DAO = update. > > * Limited range of discovery mechanism: max 4 repeaters. > A TTL field may limit the scope of the repeaters. > > * Suboptimal routing and traffic bursts are accepted in exchange > for quick route repair. But only as an exception. > > > Just as an example, one existing home control technology uses a > (source routing) variant of AODV for quick route repair. > Nothing comes for free. The price is flooding - but not just flooding: > Managed flooding using a distributed algorithm running in all > participating nodes. > The algorithm dampens the flooding in a time, volume and range > perspective. > Some similar mechanism could be built into RPL for quick route repair. > > > If anyone have alternative proposals, please bring it to the list. > Now is the time. > > > > Thanks, > Anders > > > > > _______________________________________________ > Roll mailing 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_01CAC9CE.B92FD6DE Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [Roll] P2P performance with current RPL = proposal=0A= =0A= =0A= =0A=
=0A=
Add to this = an element of promiscuos listening to dampen the storm =3D> if node = already detected a copy of the DIS with the same TTL (or lower) - do not = forward the DIS. Then you start getting closer to something.
=0A=
 
=0A=
Oh - and by the way - record = the source route on the way ;-)
=0A=
 
=0A=
- Anders
=0A=

=0A=
=0A= Fra: roll-bounces@ietf.org p=E5 = vegne af Mukul Goyal
Sendt: ma 22-03-2010 01:47
Til: = Pascal Thubert (pthubert)
Cc: ROLL WG; Ted = Humpal
Emne: Re: [Roll] P2P performance with current RPL = proposal

=0A=
=0A=

Hi Pascal

Thanks for your comments (let me send = my response in the next email).

Based on further thoughts, it = seems to me that a DAG based P2P solution would work if we do the = following:

(a) allowing multicast DIS messages to spread to an = originator-specified number of hops and
(b) allowing nodes to join a = DAG temporarily and leave it if there is not sufficient “routing = interest” in being part of the DAG.

With these points in = mind, a P2P scheme could work as follows:

1. When a node wants to = join a DODAG(D,F), where D is the DODAG's root and F is the OF being = used, it does the following:
    a. Initiates a = discovery table entry for DODAG(D,F). The discovery table entries are = removed after a certain lifetime.
    b. sends out a = DIS via link-local multicast asking specifically for information about = DODAG(D,F). It also lists in the DIS the number of hops the DIS can = travel.

2. On receiving  a DIS, a node does the = following:
    a.if it does not know about DODAG(D,F) = and the DIS hop limit is not yet = reached
        i. Initiates a = discovery table entry for DODAG(D,F). This entry maintains information = about the nodes from whom the DIS were = received.
        ii. sends out = the DIS (via link-local multicast with trickle controlled timing) = further.
    b. If it is already a part of DODAG(D,F) = or is node D itself
        i. = Send out a DIO about DODAG(D,F) to the node from whom the DIS was = received.

3. On receiving a DIO about DODAG(D,F), a node does the = following:
    a. Ignore the DIO if the node does not = have a discovery table entry for DODAG(D,F)
    b. = Otherwise, the node joins the DODAG(D,F) (if not already part of it) or = updates its parent set in DODAG(D,F) and sends the DIO by unicast to the = nodes that had sent it the DIS.

4. Once, the node is part of the = DODAG(D,F), it maintains a “routing interest” for the DODAG = in the following manner:
    a. Routing interest is a = value between 0 and 1
    b. Routing interest is 1 if = the node recently forwarded a packet along the = DODAG(D,F)
    c. Otherwise, the routing interest is = x*maximum routing interest of the neighbors in DODAG(D,F), where x is a = fraction. The node comes to know of neighbor’s routing interest = via the neighbor’s DIO.
    d. A node leaves a = DODAG if its routing interest in the DODAG goes below a = threshold.

Thanks
Mukul

----- Original Message = -----
From: "Pascal Thubert (pthubert)" = <pthubert@cisco.com>
To: "Mukul Goyal" = <mukul@uwm.edu>
Cc: "ROLL WG" <roll@ietf.org>, "Ted = Humpal" <Ted.Humpal@jci.com>, "robert cragie" = <robert.cragie@gridmerge.com>
Sent: Friday, March 19, 2010 = 11:20:58 AM GMT -06:00 US/Canada Central
Subject: RE: [Roll] P2P = performance with current RPL proposal

Hi Mukul
> Here I = have attempted to formulate a simple DV algorithm in RPL/DAG = terms.
> I will appreciate it if you could let me know about your = objections to this
> proposal:

[Pascal] It's cool that you = do it is the first impression.

> Node A needs to reach a = destination D. Node A initiates a discovery DAG
> towards D. As = the DIOs reach D, it sends a DAO back to selected parents. As
> = the DAO travels towards node A, in-route nodes store the cost to reach = D.
>
> When node B needs to reach D, it similarly initiates = a discovery dag. During
> this discovery, when a DIO reaches a = node C that maintains a cost to reach D,
> node C responds back = with a DAO that travels towards B and stores in in-
> route nodes = the cost to reach D.

[Pascal]  understand that you're trying = to make RPL even closer to AODV.
I agree we need to gather as much as = we can from that work.

For the specifics of your = proposal:

- B-C might be orthogonal to A-D so that B/C\D forms an = angle. You do not end up with the best path that you're looking = for.

- there might be multiple C's. Which one is the right = one?

- RPL does not allow packets to switch instances. Following = multiple DAGs is the recipe for loops - unless you have them strictly = ordered by some means like the RPL sequence between iterations, more = specific routes, blah blah...)

- the A to D path is optimized for = a certain constraint. You seem to imply that the B to D path has the = same constraints and metrics so we can compare apple to apple. Because = this is a very delicate operation, RPL has introduced the Rank, which = has the right properties to make that comparison efficiently.So for RPL, = the loop avoidance metric is the Rank, and it is only valid within an = iteration.

- A P2P path does not come out of the blue. There must = be some provisionning system that determines that those nodes, A and B, = are very special so they need a P2P optimization, with a given special = OF, and that they both need to talk to D. Well, if that's so, the most = economical is for that system to fork the DAG out of D, with dual = targets A and B. There you obtain the shortest path for both A-D and B-D = for the cost of a single flooding.

I see that you're trying to = get the idea to work better, and I hope we find a way to do so, maybe = along your lines if we can solve the issues above. But before we get = there, we need to agree that this is the path we wish to = take.

Cheers,

Pascal


>
> ----- = Original Message -----
> From: "Pascal Thubert (pthubert)" = <pthubert@cisco.com>
> To: "robert cragie" = <robert.cragie@gridmerge.com>
> Cc: "ROLL WG" = <roll@ietf.org>, "Ted Humpal" <Ted.Humpal@jci.com>
> = Sent: Thursday, March 18, 2010 9:23:14 PM GMT -06:00 US/Canada = Central
> Subject: Re: [Roll] P2P performance with current RPL = proposal
>
>
>
>
>
> Hi = Robert :
>
>
>
> At least from a distance, = the proposed mechanism emulates AODV, with the
> DIO as RREQ and = the DAO as RREP. So if we decide to dig along those lines,
> = we’ll certainly appreciate help from MANET experts. I’d say = that if you
> already have RPL for P2MP and MP2P, the proposed = extension are probably
> simpler to add than doing AODV from = scratch.
>
>
>
> For the setup, the major = differences are that we build a DAG and that we can
> indicate = multiple targets. If you look at it, the DAG capability is a MUST = for
> RPL, and I have not seen that this MUST goes away for P2P = flows. The
> multiple targets is something that appears in a = number of use cases and it
> seems more economical to build a = single DAG for multiple targets when
> = possible.
>
>
>
> For the maintenance, the major = differences are that we have the DAG as
> first line of defense, = and the RPL detection to stimulate the local = repair.
>
>
>
> About your = questions:
>
>
>
> The DODAG root is the one = that spawns the DAG. The targets can reach the
> root because the = root advertises itself in the DIO. The idea is that the root ID
> = is the address that the targets need to talk to. If needed, the root can = also
> advertise a prefix that it can reach and that the targets = need to reach too.
>
>
>
> All the intermediate = nodes that are confirmed by the DAO need to retain at
> least info = about the DAG. That enables the targets to reach the root. The
> = flooding should cost about the same as that of AODV but the RPL way = will
> require more states in the nodes on the way if the OF = requires a DAG.
>
>
>
> The way back (down) can = be stateful of stateless, depending on which DAO
> we’re = using. With fully stateful DAO, we are really in AODV-land. With
> = stateless, we could drift into DSR-land for that direction. Which limits = we
> place to keep it simple will be determined by the resolution = of issue #26 I
> guess…
>
>
>
> And = please, no apologize or on one will dare post anything anymore. = Your
> questions are fully relevant and at the core of the = discussion.
>
>
>
> I hope we can talk in = Anaheim for sure,
>
>
>
>
> = Pascal
>
>
>
>
>
>
> From: = Robert Cragie [mailto:robert.cragie@gridmerg= e.com]
> Sent: Monday, March 15, 2010 11:27 AM
> To: = Pascal Thubert (pth ubert)
> Cc: Ted.Humpal@jci.com; ROLL = WG
> Subject: Re: [Roll] P2P performance with current RPL = proposal
>
>
>
> Hi Pascal,
>
> So = in your slideware T can end up talking to R (DODAG root) through = the
> DODAG. So are you proposing that all potential targets can = act as a DODAG
> root? And therefore all intermediates have to = retain DIO propagation
> support for that DODAG as well? This may = work for limited P2P but seems
> less efficient than simple = distance vector flooding RREQ/RREP like AODV or
> DYMO for generic = P2P. What about R to T (or anyone else for that matter)?
> Do we = source route, maintain state, some undefined hybrid of the = two?
>
> I apologise if some of these questions have been = answered in detail in earlier
> reflector posts but I have only = recently started to concentrate my efforts on
> RPL and have 82 = pages to wade through :-). I look forward to a productive
> = session in Anaheim.
>
> Robert
>
>
> = Robert Cragie (Pacific Gas & Electric)
>
> Gridmerge = Ltd.
> 89 Greenfield Crescent,
> Wakefield, WF4 4WA, = UK
> +44 (0) 1924 910888
> http://www.gridmerge.com
>>
>
> Pascal Thubert (pthubert) wrote:
>
> = HI Robert :
>
>
>
> I respectfully have to = disagree.
>
>
>
> My understanding is that we = are considering a limited set of P2P pairs, for
> which the = specific path that we need to create might have to obey specific
> = constraints.
>
> So it makes sense to use an on-demand = technique, probably inspired by the
> MANET Reactive = protocols.
>
>
>
> As it goes, those protocols = usually use flooding for a node to locate another.
> Forking a DAG = is just another flooding. It does not take a lot of addition to = the
> existing DIO for a root to use RPL to build a DAG that = contains one or multiple
> Targets as leaves, under a set of = constraints expressed as an objective
> function. Please find = attached a slideware that illustrates = that.
>
>
>
>
> = Pascal
>
>
>
>
>
>
> From: = roll-bounces@ietf.org [ mailto:roll-bounces@ietf.org ] = On Behalf Of
> Robert Cragie
> Sent: Thursday, March 11, = 2010 2:43 PM
> To: Ted.Humpal@jci.com
> Cc: ROLL WG
> = Subject: Re: [Roll] P2P performance with current RPL = proposal
>
>
>
> I agree with Ted's comments = below. Creating a DODAG for every reachable
> node as a root seems = a very inefficient approach compared to alternative
> routing = algorithms. I am concerned that RPL does not actually meet the
> = original requirements in I-D.ietf-roll-building-routing-reqs, = I-D.ietf-roll-home-
> routing-reqs, RFC5673 and RFC5548. The = traffic pattern requirement for a
> sink node features prominently = in only two of those documents. Even in this
> case, as Ted points = out, communication is likely to be bidirectional (e.g. end-
> = to-end acks.) therefore the DODAG approach is fundamentally = asymmetric,
> especially if no intermediate storage is allowed for = destination routes and
> source routing has to be = used.
>
> Also, RPL seems highly complex for what are = constrained nodes in terms of
> memory as well as power and = bandwidth. The RPL draft as it stands is 82
> pages long and that = doesn't include text about the objective function.
>
> = Robert
>
>
> Robert Cragie (Pacific Gas & = Electric)
>
> Gridmerge Ltd.
> 89 Greenfield = Crescent,
> Wakefield, WF4 4WA, UK
> +44 (0) 1924 = 910888
> http://www.gridmerge.com
>>
>
> Ted.Humpal@jci.com wrote:
>
>
> = A concern also will be how much overhead (memory space) will be = required
> for a DODAG Root?
>
> and based on the = first question how many DODAG roots a lamp may need to
> be a = member of?
>
> For example in lighting  a single lamp = may be a root for a single switch (1
> DODAG root),  this = lamp / luminaire may also
> be a member of another group - - =  which could be all lights on the floor (2nd
> DODAG root), = and a third group
> of all the lights in the building.  There = can be many more speciality groups
> associated based on the = building configuration.
> Consider also during the installation = time - how these DODAG roots will be
> configured?  Must I = commission each device
> to tell it which DODAG it must use for = its Object Function?  How easy will this
> be to change and = add in a new DODAG root
> for the end user if the lighting group = changes??
>
> With respect to Jerry Martocci's - commercial = building requirements - every
> device may need to communicate to = any or
> all of the end devices.  If each device must = establish a DODAG for the other
> 499 devices in a 500 node = network - How much memory
> space will this require for each end = device to maintain?
>
> Keep in mind that the end devices = are very limited processor and memory
> wise.
>
> Not = to mention all of the network maintenance messages that would = need
> to be transmitted to maintain all of these = DODAGs.
>
> Consider the reconvergence time when one device = is turned off and it was in
> the middle of the majority of the = 100+ DODAGS?
>
> In many lighting and building application = an application acknowledgement -
> must be returned {Back down the = DODAG} so . . . the
> requirement is not just getting to the Root = - a return path must also be
> maintained and have a  low = latency path.
>
> Ted = Humpal
>
>
>
>
>
>
> = From:
>
> Kris Pister = <pister@eecs.berkeley.edu>
>
>
> = To:
>
> Anders Brandt = <abr@sdesigns.dk>
>
>
> Cc:
>
> ROLL = WG <roll@ietf.org>
>
>
> Date:
>
> = 03/08/2010 01:45 PM
>
>
> Subject:
>
> Re: = [Roll] P2P performance with current RPL = proposal
>
>
>
>
>
>
>
><= BR>> Anders - if we take JP's suggestion to make The Lamp a DODAG = root, and
> take Phoebus' recommendation that we use path = diversity to improve end-
> to-end reliability, do you see a = chance of success?
> In my experience, with diverse paths and = order-minutes updates you get
> extremely high = reliability.
>
> I have no aversion to TTL-limited floods as = a part of a solution either.  I'm
> open to ideas on how to = bring those in as (presumably infrequently used)
> = options.
>
> ksjp
>
> Anders Brandt = wrote:
> Hello
>
> I would like to probe the = temperature of the WG on using DAOs to
> support = P2P.
>
> The building and home application spaces (and maybe = others) have
> a few clearly defined requirements.
> It is = not obvious to me how the current RPL proposal (cRPLp) can
> = satisfy those requirements:
>
>
> In both cases it is = the worst case scenario that hurts:
>
>
> P2P routing = inside the PAN
> = =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
> cRPLp has no way of routing inside the PAN if you need more = than
> one repeater. cRPLp has to go all the way to the top (maybe = 4 hops up)
> and down again (maybe 4 hops down) to get just 2 hops = to the side.
>
> The consequence is high latency and high = levels of background noise
> for nodes just outside the direct = radio range.
> At the same time the risk of meeting a failing link = is 4 times higher =3D>
> latency may be much more than 4 times = larger.
>
> Latency may sound like a minor issue but it = actually translates directly
> into lower battery lifetime. In the = above (very realistic) example,
> the battery lifetime is reduced = to 25% of what it should be.
>
> We have lots of battery = devices sending into the network:
> * PIR sensors turning on = lights
> * Door locks sending alarms
> * Door/window sensors = starting chimes
> * Smoke sensors triggering an alarm = system
>
>
>
>
> Response time
> = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> The latency issue is = important.
> When a user (real human being) presses a light button = the user expects
> the light to turn on.
> cRPLp proposes = that nodes in the tree periodically advertises their
> presence = using DAOs.
> The periodicity is a real beast:
> Thanks to = Trickle, the rate of updates in a (apparently) stable network
> is = low. This is good since it leaves bandwidth for data.
> But it is = not good if existing routes to my lamp fail and I do not get
> new = routes to my lamp until it decides to send out a new DAO.
> My = user will (with a good reason) not tolerate waiting for minutes = for
> the light to turn on.
>
> I have met two = arguments to counter this concern:
>
> A1: Well, your lamp = can always send a DAO when it detects a problem.
>   My = answer:
>   True, except that my lamp does not intend to send = anything
>   so it will never experience any problems from = its side of the network.
>
> A2: Well, you can increase the = DAO rate to sub-second updates.
>   My answer:
>   = Oh no. I get a very high degree of management traffic which
> =   limits my available bandwidth, increases the risk of collisions = and
>   even run the risk of violating EU legislation = requiring me to only
>   transmit in less than 1% of the = time:
>   http://focus.ti.c= om/lit/an/swra048/swra048.pdf
>  868 - 868.6 MHz: = <1%
>
>   Reactiveness is hard to achieve via = polling.
>
>
>
> If you agree that this seems to = be critical issues please raise your
> voice on the = list.
>
> Going forward
> = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>
> We need some = reactive mechanism to reach lamps before the user decides
> to sue = our companies.
> So is this possible? I think so.
>
> = Existing commercial (non-IP) solutions are capable of re-routing = quickly
> if they really have to.
>
> Let me try = scoping the requirements to a potential solution:
> (no different = from the req. docs for home and building)
>
> * P2P routing = in any direction independent of the tree.
>
> * On-demand = P2P route discovery if requested by a real-time critical app.
> =  Data collection apps may be able to just wait for the next DAO = update.
>
> * Limited range of discovery mechanism: max 4 = repeaters.
>   A TTL field may limit the scope of the = repeaters.
>
> * Suboptimal routing and traffic bursts are = accepted in exchange
>   for quick route repair. But only as = an exception.
>
>
> Just as an example, one existing = home control technology uses a
> (source routing) variant of AODV = for quick route repair.
> Nothing comes for free. The price is = flooding - but not just flooding:
> Managed flooding using a = distributed algorithm running in all
> participating = nodes.
> The algorithm dampens the flooding in a time, volume and = range
> perspective.
> Some similar mechanism could be built = into RPL for quick route repair.
>
>
> If anyone have = alternative proposals, please bring it to the list.
> Now is the = time.
>
>
>
> Thanks,
>   = Anders
>
>
>
>
> = _______________________________________________
> Roll mailing = 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_01CAC9CE.B92FD6DE-- From d.sturek@att.net Mon Mar 22 07:52: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 BC56A28C0FC for ; Mon, 22 Mar 2010 07:52:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.816 X-Spam-Level: X-Spam-Status: No, score=0.816 tagged_above=-999 required=5 tests=[AWL=-0.966, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, HTML_MESSAGE=0.001, J_CHICKENPOX_12=0.6, J_CHICKENPOX_17=0.6, J_CHICKENPOX_51=0.6, 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 VUsplSuVGTPF for ; Mon, 22 Mar 2010 07:52:30 -0700 (PDT) Received: from smtp111.sbc.mail.mud.yahoo.com (smtp111.sbc.mail.mud.yahoo.com [68.142.198.207]) by core3.amsl.com (Postfix) with SMTP id AE86B3A68D1 for ; Mon, 22 Mar 2010 07:52:27 -0700 (PDT) Received: (qmail 84974 invoked from network); 22 Mar 2010 14:52:44 -0000 Received: from Studio (d.sturek@69.224.122.108 with login) by smtp111.sbc.mail.mud.yahoo.com with SMTP; 22 Mar 2010 07:52:43 -0700 PDT X-Yahoo-SMTP: fvjol_aswBAraSJvMLe2r1XTzhBhbFxY8q8c3jo- X-YMail-OSG: o1i1PUoVM1kC6rkBchODTnr7lHDr5K0YynUJvj8wsurfb2bn0HxrWxMoFz1HupXlaJSfB.xhSuIhzWnyW6HTlCWUp69rteRnGnGfiqtAXBLZdPWBqUsMZ_NtAmIiTVwDuJ.1kDIRXJ0tCQEPXT4.lh252Y7HkuBds7KXiOdrFqXCE4yB_OfyEdvdTH1BCZ75HV_bwX3sQJv8._Zg7c5Fd8It_yqqh0N0K74Dd2J8P2aJU6GhqsZS55bNTthLi461dAKmRBMS6zxyiABiPaUQP57ZxEIHtX9FG24TVEbrnzyuhhwB.10- X-Yahoo-Newman-Property: ymail-3 From: "Don Sturek" To: "'Anders Brandt'" , "'Mukul Goyal'" , "'Pascal Thubert \(pthubert\)'" References: <1161577952.8138041269244020805.JavaMail.root@mail02.pantherlink.uwm.edu> <6D9687E95918C04A8B30A7D6DA805A3E01AD45CF@zensys17.zensys.local> In-Reply-To: <6D9687E95918C04A8B30A7D6DA805A3E01AD45CF@zensys17.zensys.local> Date: Mon, 22 Mar 2010 07:52:38 -0700 Message-ID: <009b01cac9cf$51934660$f4b9d320$@sturek@att.net> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_009C_01CAC994.A5346E60" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcrJk+JCuyMtok55QmizMYmRCE2g7gAOo17nAAAmJ9A= Content-Language: en-us Cc: 'ROLL WG' , 'Ted Humpal' Subject: Re: [Roll] P2P performance with current RPL proposal 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, 22 Mar 2010 14:52:46 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_009C_01CAC994.A5346E60 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Anders and Mukul, =20 This is all sounding quite promising in addressing P2P routing in RPL. = How can we organize a specific proposal we can gain WG approval for? I = would like to leave Anaheim with an agreed path towards P2P routing support we = all believe addresses the Home Automation and Building Controls use cases. =20 Don =20 =20 From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Anders Brandt Sent: Monday, March 22, 2010 7:46 AM To: Mukul Goyal; Pascal Thubert (pthubert) Cc: ROLL WG; Ted Humpal Subject: Re: [Roll] P2P performance with current RPL proposal =20 Add to this an element of promiscuos listening to dampen the storm =3D> = if node already detected a copy of the DIS with the same TTL (or lower) - = do not forward the DIS. Then you start getting closer to something. =20 Oh - and by the way - record the source route on the way ;-) =20 - Anders =20 _____ =20 Fra: roll-bounces@ietf.org p=E5 vegne af Mukul Goyal Sendt: ma 22-03-2010 01:47 Til: Pascal Thubert (pthubert) Cc: ROLL WG; Ted Humpal Emne: Re: [Roll] P2P performance with current RPL proposal Hi Pascal Thanks for your comments (let me send my response in the next email). Based on further thoughts, it seems to me that a DAG based P2P solution would work if we do the following: (a) allowing multicast DIS messages to spread to an originator-specified number of hops and (b) allowing nodes to join a DAG temporarily and leave it if there is = not sufficient =93routing interest=94 in being part of the DAG. With these points in mind, a P2P scheme could work as follows: 1. When a node wants to join a DODAG(D,F), where D is the DODAG's root = and F is the OF being used, it does the following: a. Initiates a discovery table entry for DODAG(D,F). The discovery = table entries are removed after a certain lifetime. b. sends out a DIS via link-local multicast asking specifically for information about DODAG(D,F). It also lists in the DIS the number of = hops the DIS can travel. 2. On receiving a DIS, a node does the following: a.if it does not know about DODAG(D,F) and the DIS hop limit is not = yet reached i. Initiates a discovery table entry for DODAG(D,F). This entry maintains information about the nodes from whom the DIS were received. ii. sends out the DIS (via link-local multicast with trickle controlled timing) further. b. If it is already a part of DODAG(D,F) or is node D itself i. Send out a DIO about DODAG(D,F) to the node from whom the DIS = was received. 3. On receiving a DIO about DODAG(D,F), a node does the following: a. Ignore the DIO if the node does not have a discovery table entry = for DODAG(D,F) b. Otherwise, the node joins the DODAG(D,F) (if not already part of = it) or updates its parent set in DODAG(D,F) and sends the DIO by unicast to = the nodes that had sent it the DIS. 4. Once, the node is part of the DODAG(D,F), it maintains a =93routing interest=94 for the DODAG in the following manner: a. Routing interest is a value between 0 and 1 b. Routing interest is 1 if the node recently forwarded a packet = along the DODAG(D,F) c. Otherwise, the routing interest is x*maximum routing interest of = the neighbors in DODAG(D,F), where x is a fraction. The node comes to know = of neighbor=92s routing interest via the neighbor=92s DIO. d. A node leaves a DODAG if its routing interest in the DODAG goes = below a threshold. Thanks Mukul ----- Original Message ----- From: "Pascal Thubert (pthubert)" To: "Mukul Goyal" Cc: "ROLL WG" , "Ted Humpal" , = "robert cragie" Sent: Friday, March 19, 2010 11:20:58 AM GMT -06:00 US/Canada Central Subject: RE: [Roll] P2P performance with current RPL proposal Hi Mukul > Here I have attempted to formulate a simple DV algorithm in RPL/DAG = terms. > I will appreciate it if you could let me know about your objections to this > proposal: [Pascal] It's cool that you do it is the first impression. > Node A needs to reach a destination D. Node A initiates a discovery = DAG > towards D. As the DIOs reach D, it sends a DAO back to selected = parents. As > the DAO travels towards node A, in-route nodes store the cost to reach = D. > > When node B needs to reach D, it similarly initiates a discovery dag. During > this discovery, when a DIO reaches a node C that maintains a cost to = reach D, > node C responds back with a DAO that travels towards B and stores in = in- > route nodes the cost to reach D. [Pascal] understand that you're trying to make RPL even closer to AODV. I agree we need to gather as much as we can from that work. For the specifics of your proposal: - B-C might be orthogonal to A-D so that B/C\D forms an angle. You do = not end up with the best path that you're looking for. - there might be multiple C's. Which one is the right one? - RPL does not allow packets to switch instances. Following multiple = DAGs is the recipe for loops - unless you have them strictly ordered by some = means like the RPL sequence between iterations, more specific routes, blah blah...) - the A to D path is optimized for a certain constraint. You seem to = imply that the B to D path has the same constraints and metrics so we can = compare apple to apple. Because this is a very delicate operation, RPL has introduced the Rank, which has the right properties to make that = comparison efficiently.So for RPL, the loop avoidance metric is the Rank, and it is only valid within an iteration. - A P2P path does not come out of the blue. There must be some = provisionning system that determines that those nodes, A and B, are very special so = they need a P2P optimization, with a given special OF, and that they both = need to talk to D. Well, if that's so, the most economical is for that system to fork the DAG out of D, with dual targets A and B. There you obtain the shortest path for both A-D and B-D for the cost of a single flooding. I see that you're trying to get the idea to work better, and I hope we = find a way to do so, maybe along your lines if we can solve the issues above. = But before we get there, we need to agree that this is the path we wish to = take. Cheers, Pascal > > ----- Original Message ----- > From: "Pascal Thubert (pthubert)" > To: "robert cragie" > Cc: "ROLL WG" , "Ted Humpal" > Sent: Thursday, March 18, 2010 9:23:14 PM GMT -06:00 US/Canada Central > Subject: Re: [Roll] P2P performance with current RPL proposal > > > > > > Hi Robert : > > > > At least from a distance, the proposed mechanism emulates AODV, with = the > DIO as RREQ and the DAO as RREP. So if we decide to dig along those = lines, > we=92ll certainly appreciate help from MANET experts. I=92d say that = if you > already have RPL for P2MP and MP2P, the proposed extension are = probably > simpler to add than doing AODV from scratch. > > > > For the setup, the major differences are that we build a DAG and that = we can > indicate multiple targets. If you look at it, the DAG capability is a = MUST for > RPL, and I have not seen that this MUST goes away for P2P flows. The > multiple targets is something that appears in a number of use cases = and it > seems more economical to build a single DAG for multiple targets when > possible. > > > > For the maintenance, the major differences are that we have the DAG as > first line of defense, and the RPL detection to stimulate the local repair. > > > > About your questions: > > > > The DODAG root is the one that spawns the DAG. The targets can reach = the > root because the root advertises itself in the DIO. The idea is that = the root ID > is the address that the targets need to talk to. If needed, the root = can also > advertise a prefix that it can reach and that the targets need to = reach too. > > > > All the intermediate nodes that are confirmed by the DAO need to = retain at > least info about the DAG. That enables the targets to reach the root. = The > flooding should cost about the same as that of AODV but the RPL way = will > require more states in the nodes on the way if the OF requires a DAG. > > > > The way back (down) can be stateful of stateless, depending on which = DAO > we=92re using. With fully stateful DAO, we are really in AODV-land. = With > stateless, we could drift into DSR-land for that direction. Which = limits we > place to keep it simple will be determined by the resolution of issue = #26 I > guess=85 > > > > And please, no apologize or on one will dare post anything anymore. = Your > questions are fully relevant and at the core of the discussion. > > > > I hope we can talk in Anaheim for sure, > > > > > Pascal > > > > > > > From: Robert Cragie [mailto:robert.cragie@gridmerge.com] > Sent: Monday, March 15, 2010 11:27 AM > To: Pascal Thubert (pth ubert) > Cc: Ted.Humpal@jci.com; ROLL WG > Subject: Re: [Roll] P2P performance with current RPL proposal > > > > Hi Pascal, > > So in your slideware T can end up talking to R (DODAG root) through = the > DODAG. So are you proposing that all potential targets can act as a = DODAG > root? And therefore all intermediates have to retain DIO propagation > support for that DODAG as well? This may work for limited P2P but = seems > less efficient than simple distance vector flooding RREQ/RREP like = AODV or > DYMO for generic P2P. What about R to T (or anyone else for that = matter)? > Do we source route, maintain state, some undefined hybrid of the two? > > I apologise if some of these questions have been answered in detail in earlier > reflector posts but I have only recently started to concentrate my = efforts on > RPL and have 82 pages to wade through :-). I look forward to a = productive > session in Anaheim. > > Robert > > > Robert Cragie (Pacific Gas & Electric) > > Gridmerge Ltd. > 89 Greenfield Crescent, > Wakefield, WF4 4WA, UK > +44 (0) 1924 910888 > http://www.gridmerge.com =20 > > > > Pascal Thubert (pthubert) wrote: > > HI Robert : > > > > I respectfully have to disagree. > > > > My understanding is that we are considering a limited set of P2P = pairs, for > which the specific path that we need to create might have to obey = specific > constraints. > > So it makes sense to use an on-demand technique, probably inspired by = the > MANET Reactive protocols. > > > > As it goes, those protocols usually use flooding for a node to locate another. > Forking a DAG is just another flooding. It does not take a lot of = addition to the > existing DIO for a root to use RPL to build a DAG that contains one or multiple > Targets as leaves, under a set of constraints expressed as an = objective > function. Please find attached a slideware that illustrates that. > > > > > Pascal > > > > > > > From: roll-bounces@ietf.org [ mailto:roll-bounces@ietf.org ] On Behalf = Of > Robert Cragie > Sent: Thursday, March 11, 2010 2:43 PM > To: Ted.Humpal@jci.com > Cc: ROLL WG > Subject: Re: [Roll] P2P performance with current RPL proposal > > > > I agree with Ted's comments below. Creating a DODAG for every = reachable > node as a root seems a very inefficient approach compared to = alternative > routing algorithms. I am concerned that RPL does not actually meet the > original requirements in I-D.ietf-roll-building-routing-reqs, I-D.ietf-roll-home- > routing-reqs, RFC5673 and RFC5548. The traffic pattern requirement for = a > sink node features prominently in only two of those documents. Even in this > case, as Ted points out, communication is likely to be bidirectional = (e.g. end- > to-end acks.) therefore the DODAG approach is fundamentally = asymmetric, > especially if no intermediate storage is allowed for destination = routes and > source routing has to be used. > > Also, RPL seems highly complex for what are constrained nodes in terms = of > memory as well as power and bandwidth. The RPL draft as it stands is = 82 > pages long and that doesn't include text about the objective function. > > Robert > > > Robert Cragie (Pacific Gas & Electric) > > Gridmerge Ltd. > 89 Greenfield Crescent, > Wakefield, WF4 4WA, UK > +44 (0) 1924 910888 > http://www.gridmerge.com =20 > > > > Ted.Humpal@jci.com wrote: > > > A concern also will be how much overhead (memory space) will be = required > for a DODAG Root? > > and based on the first question how many DODAG roots a lamp may need = to > be a member of? > > For example in lighting a single lamp may be a root for a single = switch (1 > DODAG root), this lamp / luminaire may also > be a member of another group - - which could be all lights on the = floor (2nd > DODAG root), and a third group > of all the lights in the building. There can be many more speciality groups > associated based on the building configuration. > Consider also during the installation time - how these DODAG roots = will be > configured? Must I commission each device > to tell it which DODAG it must use for its Object Function? How easy = will this > be to change and add in a new DODAG root > for the end user if the lighting group changes?? > > With respect to Jerry Martocci's - commercial building requirements - every > device may need to communicate to any or > all of the end devices. If each device must establish a DODAG for the other > 499 devices in a 500 node network - How much memory > space will this require for each end device to maintain? > > Keep in mind that the end devices are very limited processor and = memory > wise. > > Not to mention all of the network maintenance messages that would need > to be transmitted to maintain all of these DODAGs. > > Consider the reconvergence time when one device is turned off and it = was in > the middle of the majority of the 100+ DODAGS? > > In many lighting and building application an application = acknowledgement - > must be returned {Back down the DODAG} so . . . the > requirement is not just getting to the Root - a return path must also = be > maintained and have a low latency path. > > Ted Humpal > > > > > > > From: > > Kris Pister > > > To: > > Anders Brandt > > > Cc: > > ROLL WG > > > Date: > > 03/08/2010 01:45 PM > > > Subject: > > Re: [Roll] P2P performance with current RPL proposal > > > > > > > > > Anders - if we take JP's suggestion to make The Lamp a DODAG root, and > take Phoebus' recommendation that we use path diversity to improve = end- > to-end reliability, do you see a chance of success? > In my experience, with diverse paths and order-minutes updates you get > extremely high reliability. > > I have no aversion to TTL-limited floods as a part of a solution = either. I'm > open to ideas on how to bring those in as (presumably infrequently = used) > options. > > ksjp > > Anders Brandt wrote: > Hello > > I would like to probe the temperature of the WG on using DAOs to > support P2P. > > The building and home application spaces (and maybe others) have > a few clearly defined requirements. > It is not obvious to me how the current RPL proposal (cRPLp) can > satisfy those requirements: > > > In both cases it is the worst case scenario that hurts: > > > P2P routing inside the PAN > = =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 > cRPLp has no way of routing inside the PAN if you need more than > one repeater. cRPLp has to go all the way to the top (maybe 4 hops up) > and down again (maybe 4 hops down) to get just 2 hops to the side. > > The consequence is high latency and high levels of background noise > for nodes just outside the direct radio range. > At the same time the risk of meeting a failing link is 4 times higher = =3D> > latency may be much more than 4 times larger. > > Latency may sound like a minor issue but it actually translates = directly > into lower battery lifetime. In the above (very realistic) example, > the battery lifetime is reduced to 25% of what it should be. > > We have lots of battery devices sending into the network: > * PIR sensors turning on lights > * Door locks sending alarms > * Door/window sensors starting chimes > * Smoke sensors triggering an alarm system > > > > > Response time > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > The latency issue is important. > When a user (real human being) presses a light button the user expects > the light to turn on. > cRPLp proposes that nodes in the tree periodically advertises their > presence using DAOs. > The periodicity is a real beast: > Thanks to Trickle, the rate of updates in a (apparently) stable = network > is low. This is good since it leaves bandwidth for data. > But it is not good if existing routes to my lamp fail and I do not get > new routes to my lamp until it decides to send out a new DAO. > My user will (with a good reason) not tolerate waiting for minutes for > the light to turn on. > > I have met two arguments to counter this concern: > > A1: Well, your lamp can always send a DAO when it detects a problem. > My answer: > True, except that my lamp does not intend to send anything > so it will never experience any problems from its side of the = network. > > A2: Well, you can increase the DAO rate to sub-second updates. > My answer: > Oh no. I get a very high degree of management traffic which > limits my available bandwidth, increases the risk of collisions and > even run the risk of violating EU legislation requiring me to only > transmit in less than 1% of the time: > http://focus.ti.com/lit/an/swra048/swra048.pdf > 868 - 868.6 MHz: <1% > > Reactiveness is hard to achieve via polling. > > > > If you agree that this seems to be critical issues please raise your > voice on the list. > > Going forward > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > We need some reactive mechanism to reach lamps before the user decides > to sue our companies. > So is this possible? I think so. > > Existing commercial (non-IP) solutions are capable of re-routing = quickly > if they really have to. > > Let me try scoping the requirements to a potential solution: > (no different from the req. docs for home and building) > > * P2P routing in any direction independent of the tree. > > * On-demand P2P route discovery if requested by a real-time critical = app. > Data collection apps may be able to just wait for the next DAO = update. > > * Limited range of discovery mechanism: max 4 repeaters. > A TTL field may limit the scope of the repeaters. > > * Suboptimal routing and traffic bursts are accepted in exchange > for quick route repair. But only as an exception. > > > Just as an example, one existing home control technology uses a > (source routing) variant of AODV for quick route repair. > Nothing comes for free. The price is flooding - but not just flooding: > Managed flooding using a distributed algorithm running in all > participating nodes. > The algorithm dampens the flooding in a time, volume and range > perspective. > Some similar mechanism could be built into RPL for quick route repair. > > > If anyone have alternative proposals, please bring it to the list. > Now is the time. > > > > Thanks, > Anders > > > > > _______________________________________________ > Roll mailing 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_009C_01CAC994.A5346E60 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [Roll] P2P performance with current RPL proposal

Hi Anders and Mukul,

 

This is all sounding quite promising in addressing P2P = routing in RPL.=A0 How can we organize a specific proposal we can gain WG = approval for?=A0 I would like to leave Anaheim with an agreed path towards P2P routing = support we all believe addresses the Home Automation and Building Controls use = cases.

 

Don

 

 

From:= roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of = Anders Brandt
Sent: Monday, March 22, 2010 7:46 AM
To: Mukul Goyal; Pascal Thubert (pthubert)
Cc: ROLL WG; Ted Humpal
Subject: Re: [Roll] P2P performance with current RPL = proposal

 

Add to this an element of promiscuos listening to dampen = the storm =3D> if node already detected a copy of the DIS with the same TTL (or = lower) - do not forward the DIS. Then you start getting closer to = something.

 

Oh - and by the way - record the source route on the way = ;-)

 

- Anders

 

Fra: roll-bounces@ietf.org p=E5 vegne af = Mukul Goyal
Sendt: ma 22-03-2010 01:47
Til: Pascal Thubert (pthubert)
Cc: ROLL WG; Ted Humpal
Emne: Re: [Roll] P2P performance with current RPL = proposal

Hi Pascal

Thanks for your comments (let me send my response in the next = email).

Based on further thoughts, it seems to me that a DAG based P2P solution = would work if we do the following:

(a) allowing multicast DIS messages to spread to an originator-specified = number of hops and
(b) allowing nodes to join a DAG temporarily and leave it if there is = not sufficient “routing interest” in being part of the DAG.

With these points in mind, a P2P scheme could work as follows:

1. When a node wants to join a DODAG(D,F), where D is the DODAG's root = and F is the OF being used, it does the following:
    a. Initiates a discovery table entry for DODAG(D,F). = The discovery table entries are removed after a certain lifetime.
    b. sends out a DIS via link-local multicast asking specifically for information about DODAG(D,F). It also lists in the DIS = the number of hops the DIS can travel.

2. On receiving  a DIS, a node does the following:
    a.if it does not know about DODAG(D,F) and the DIS = hop limit is not yet reached
        i. Initiates a discovery = table entry for DODAG(D,F). This entry maintains information about the nodes from = whom the DIS were received.
        ii. sends out the DIS (via link-local multicast with trickle controlled timing) further.
    b. If it is already a part of DODAG(D,F) or is node D = itself
        i. Send out a DIO about = DODAG(D,F) to the node from whom the DIS was received.

3. On receiving a DIO about DODAG(D,F), a node does the following:
    a. Ignore the DIO if the node does not have a = discovery table entry for DODAG(D,F)
    b. Otherwise, the node joins the DODAG(D,F) (if not = already part of it) or updates its parent set in DODAG(D,F) and sends the DIO by unicast to the nodes that had sent it the DIS.

4. Once, the node is part of the DODAG(D,F), it maintains a = “routing interest” for the DODAG in the following manner:
    a. Routing interest is a value between 0 and 1
    b. Routing interest is 1 if the node recently = forwarded a packet along the DODAG(D,F)
    c. Otherwise, the routing interest is x*maximum = routing interest of the neighbors in DODAG(D,F), where x is a fraction. The node = comes to know of neighbor’s routing interest via the neighbor’s = DIO.
    d. A node leaves a DODAG if its routing interest in = the DODAG goes below a threshold.

Thanks
Mukul

----- Original Message -----
From: "Pascal Thubert (pthubert)" = <pthubert@cisco.com>
To: "Mukul Goyal" <mukul@uwm.edu>
Cc: "ROLL WG" <roll@ietf.org>, "Ted Humpal" <Ted.Humpal@jci.com>, "robert cragie" <robert.cragie@gridmerge.com>
Sent: Friday, March 19, 2010 11:20:58 AM GMT -06:00 US/Canada = Central
Subject: RE: [Roll] P2P performance with current RPL proposal

Hi Mukul
> Here I have attempted to formulate a simple DV algorithm in RPL/DAG = terms.
> I will appreciate it if you could let me know about your objections = to this
> proposal:

[Pascal] It's cool that you do it is the first impression.

> Node A needs to reach a destination D. Node A initiates a discovery = DAG
> towards D. As the DIOs reach D, it sends a DAO back to selected = parents. As
> the DAO travels towards node A, in-route nodes store the cost to = reach D.
>
> When node B needs to reach D, it similarly initiates a discovery = dag. During
> this discovery, when a DIO reaches a node C that maintains a cost = to reach D,
> node C responds back with a DAO that travels towards B and stores = in in-
> route nodes the cost to reach D.

[Pascal]  understand that you're trying to make RPL even closer to = AODV.
I agree we need to gather as much as we can from that work.

For the specifics of your proposal:

- B-C might be orthogonal to A-D so that B/C\D forms an angle. You do = not end up with the best path that you're looking for.

- there might be multiple C's. Which one is the right one?

- RPL does not allow packets to switch instances. Following multiple = DAGs is the recipe for loops - unless you have them strictly ordered by some = means like the RPL sequence between iterations, more specific routes, blah = blah...)

- the A to D path is optimized for a certain constraint. You seem to = imply that the B to D path has the same constraints and metrics so we can compare = apple to apple. Because this is a very delicate operation, RPL has introduced the = Rank, which has the right properties to make that comparison efficiently.So = for RPL, the loop avoidance metric is the Rank, and it is only valid within an iteration.

- A P2P path does not come out of the blue. There must be some = provisionning system that determines that those nodes, A and B, are very special so = they need a P2P optimization, with a given special OF, and that they both need to = talk to D. Well, if that's so, the most economical is for that system to fork = the DAG out of D, with dual targets A and B. There you obtain the shortest path = for both A-D and B-D for the cost of a single flooding.

I see that you're trying to get the idea to work better, and I hope we = find a way to do so, maybe along your lines if we can solve the issues above. = But before we get there, we need to agree that this is the path we wish to = take.

Cheers,

Pascal


>
> ----- Original Message -----
> From: "Pascal Thubert (pthubert)" = <pthubert@cisco.com>
> To: "robert cragie" = <robert.cragie@gridmerge.com>
> Cc: "ROLL WG" <roll@ietf.org>, "Ted = Humpal" <Ted.Humpal@jci.com>
> Sent: Thursday, March 18, 2010 9:23:14 PM GMT -06:00 US/Canada = Central
> Subject: Re: [Roll] P2P performance with current RPL proposal
>
>
>
>
>
> Hi Robert :
>
>
>
> At least from a distance, the proposed mechanism emulates AODV, = with the
> DIO as RREQ and the DAO as RREP. So if we decide to dig along those = lines,
> we’ll certainly appreciate help from MANET experts. I’d = say that if you
> already have RPL for P2MP and MP2P, the proposed extension are = probably
> simpler to add than doing AODV from scratch.
>
>
>
> For the setup, the major differences are that we build a DAG and = that we can
> indicate multiple targets. If you look at it, the DAG capability is = a MUST for
> RPL, and I have not seen that this MUST goes away for P2P flows. = The
> multiple targets is something that appears in a number of use cases = and it
> seems more economical to build a single DAG for multiple targets = when
> possible.
>
>
>
> For the maintenance, the major differences are that we have the DAG = as
> first line of defense, and the RPL detection to stimulate the local repair.
>
>
>
> About your questions:
>
>
>
> The DODAG root is the one that spawns the DAG. The targets can = reach the
> root because the root advertises itself in the DIO. The idea is = that the root ID
> is the address that the targets need to talk to. If needed, the = root can also
> advertise a prefix that it can reach and that the targets need to = reach too.
>
>
>
> All the intermediate nodes that are confirmed by the DAO need to = retain at
> least info about the DAG. That enables the targets to reach the = root. The
> flooding should cost about the same as that of AODV but the RPL way = will
> require more states in the nodes on the way if the OF requires a = DAG.
>
>
>
> The way back (down) can be stateful of stateless, depending on = which DAO
> we’re using. With fully stateful DAO, we are really in = AODV-land. With
> stateless, we could drift into DSR-land for that direction. Which = limits we
> place to keep it simple will be determined by the resolution of = issue #26 I
> guess…
>
>
>
> And please, no apologize or on one will dare post anything anymore. = Your
> questions are fully relevant and at the core of the discussion.
>
>
>
> I hope we can talk in Anaheim for sure,
>
>
>
>
> Pascal
>
>
>
>
>
>
> From: Robert Cragie [mailto:robert.cragie@gridmerg= e.com]
> Sent: Monday, March 15, 2010 11:27 AM
> To: Pascal Thubert (pth ubert)
> Cc: Ted.Humpal@jci.com; ROLL WG
> Subject: Re: [Roll] P2P performance with current RPL proposal
>
>
>
> Hi Pascal,
>
> So in your slideware T can end up talking to R (DODAG root) through = the
> DODAG. So are you proposing that all potential targets can act as a = DODAG
> root? And therefore all intermediates have to retain DIO = propagation
> support for that DODAG as well? This may work for limited P2P but = seems
> less efficient than simple distance vector flooding RREQ/RREP like = AODV or
> DYMO for generic P2P. What about R to T (or anyone else for that = matter)?
> Do we source route, maintain state, some undefined hybrid of the = two?
>
> I apologise if some of these questions have been answered in detail = in earlier
> reflector posts but I have only recently started to concentrate my = efforts on
> RPL and have 82 pages to wade through :-). I look forward to a = productive
> session in Anaheim.
>
> Robert
>
>
> Robert Cragie (Pacific Gas & Electric)
>
> Gridmerge Ltd.
> 89 Greenfield Crescent,
> Wakefield, WF4 4WA, UK
> +44 (0) 1924 910888
> http://www.gridmerge.com
>
>
>
> Pascal Thubert (pthubert) wrote:
>
> HI Robert :
>
>
>
> I respectfully have to disagree.
>
>
>
> My understanding is that we are considering a limited set of P2P = pairs, for
> which the specific path that we need to create might have to obey = specific
> constraints.
>
> So it makes sense to use an on-demand technique, probably inspired = by the
> MANET Reactive protocols.
>
>
>
> As it goes, those protocols usually use flooding for a node to = locate another.
> Forking a DAG is just another flooding. It does not take a lot of = addition to the
> existing DIO for a root to use RPL to build a DAG that contains one = or multiple
> Targets as leaves, under a set of constraints expressed as an = objective
> function. Please find attached a slideware that illustrates = that.
>
>
>
>
> Pascal
>
>
>
>
>
>
> From: roll-bounces@ietf.org [ mailto:roll-bounces@ietf.org ] On Behalf Of
> Robert Cragie
> Sent: Thursday, March 11, 2010 2:43 PM
> To: Ted.Humpal@jci.com
> Cc: ROLL WG
> Subject: Re: [Roll] P2P performance with current RPL proposal
>
>
>
> I agree with Ted's comments below. Creating a DODAG for every = reachable
> node as a root seems a very inefficient approach compared to = alternative
> routing algorithms. I am concerned that RPL does not actually meet = the
> original requirements in I-D.ietf-roll-building-routing-reqs, I-D.ietf-roll-home-
> routing-reqs, RFC5673 and RFC5548. The traffic pattern requirement = for a
> sink node features prominently in only two of those documents. Even = in this
> case, as Ted points out, communication is likely to be = bidirectional (e.g. end-
> to-end acks.) therefore the DODAG approach is fundamentally = asymmetric,
> especially if no intermediate storage is allowed for destination = routes and
> source routing has to be used.
>
> Also, RPL seems highly complex for what are constrained nodes in = terms of
> memory as well as power and bandwidth. The RPL draft as it stands = is 82
> pages long and that doesn't include text about the objective = function.
>
> Robert
>
>
> Robert Cragie (Pacific Gas & Electric)
>
> Gridmerge Ltd.
> 89 Greenfield Crescent,
> Wakefield, WF4 4WA, UK
> +44 (0) 1924 910888
> http://www.gridmerge.com
>
>
>
> Ted.Humpal@jci.com wrote:
>
>
> A concern also will be how much overhead (memory space) will be = required
> for a DODAG Root?
>
> and based on the first question how many DODAG roots a lamp may = need to
> be a member of?
>
> For example in lighting  a single lamp may be a root for a = single switch (1
> DODAG root),  this lamp / luminaire may also
> be a member of another group - -  which could be all lights on = the floor (2nd
> DODAG root), and a third group
> of all the lights in the building.  There can be many more = speciality groups
> associated based on the building configuration.
> Consider also during the installation time - how these DODAG roots = will be
> configured?  Must I commission each device
> to tell it which DODAG it must use for its Object Function? =  How easy will this
> be to change and add in a new DODAG root
> for the end user if the lighting group changes??
>
> With respect to Jerry Martocci's - commercial building requirements = - every
> device may need to communicate to any or
> all of the end devices.  If each device must establish a DODAG = for the other
> 499 devices in a 500 node network - How much memory
> space will this require for each end device to maintain?
>
> Keep in mind that the end devices are very limited processor and = memory
> wise.
>
> Not to mention all of the network maintenance messages that would = need
> to be transmitted to maintain all of these DODAGs.
>
> Consider the reconvergence time when one device is turned off and = it was in
> the middle of the majority of the 100+ DODAGS?
>
> In many lighting and building application an application = acknowledgement -
> must be returned {Back down the DODAG} so . . . the
> requirement is not just getting to the Root - a return path must = also be
> maintained and have a  low latency path.
>
> Ted Humpal
>
>
>
>
>
>
> From:
>
> Kris Pister <pister@eecs.berkeley.edu>
>
>
> To:
>
> Anders Brandt <abr@sdesigns.dk>
>
>
> Cc:
>
> ROLL WG <roll@ietf.org>
>
>
> Date:
>
> 03/08/2010 01:45 PM
>
>
> Subject:
>
> Re: [Roll] P2P performance with current RPL proposal
>
>
>
>
>
>
>
>
> Anders - if we take JP's suggestion to make The Lamp a DODAG root, = and
> take Phoebus' recommendation that we use path diversity to improve = end-
> to-end reliability, do you see a chance of success?
> In my experience, with diverse paths and order-minutes updates you = get
> extremely high reliability.
>
> I have no aversion to TTL-limited floods as a part of a solution = either.  I'm
> open to ideas on how to bring those in as (presumably infrequently = used)
> options.
>
> ksjp
>
> Anders Brandt wrote:
> Hello
>
> I would like to probe the temperature of the WG on using DAOs = to
> support P2P.
>
> The building and home application spaces (and maybe others) = have
> a few clearly defined requirements.
> It is not obvious to me how the current RPL proposal (cRPLp) = can
> satisfy those requirements:
>
>
> In both cases it is the worst case scenario that hurts:
>
>
> P2P routing inside the PAN
> = =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
> cRPLp has no way of routing inside the PAN if you need more = than
> one repeater. cRPLp has to go all the way to the top (maybe 4 hops = up)
> and down again (maybe 4 hops down) to get just 2 hops to the = side.
>
> The consequence is high latency and high levels of background = noise
> for nodes just outside the direct radio range.
> At the same time the risk of meeting a failing link is 4 times = higher =3D>
> latency may be much more than 4 times larger.
>
> Latency may sound like a minor issue but it actually translates = directly
> into lower battery lifetime. In the above (very realistic) = example,
> the battery lifetime is reduced to 25% of what it should be.
>
> We have lots of battery devices sending into the network:
> * PIR sensors turning on lights
> * Door locks sending alarms
> * Door/window sensors starting chimes
> * Smoke sensors triggering an alarm system
>
>
>
>
> Response time
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> The latency issue is important.
> When a user (real human being) presses a light button the user = expects
> the light to turn on.
> cRPLp proposes that nodes in the tree periodically advertises = their
> presence using DAOs.
> The periodicity is a real beast:
> Thanks to Trickle, the rate of updates in a (apparently) stable = network
> is low. This is good since it leaves bandwidth for data.
> But it is not good if existing routes to my lamp fail and I do not = get
> new routes to my lamp until it decides to send out a new DAO.
> My user will (with a good reason) not tolerate waiting for minutes = for
> the light to turn on.
>
> I have met two arguments to counter this concern:
>
> A1: Well, your lamp can always send a DAO when it detects a = problem.
>   My answer:
>   True, except that my lamp does not intend to send = anything
>   so it will never experience any problems from its side of = the network.
>
> A2: Well, you can increase the DAO rate to sub-second updates.
>   My answer:
>   Oh no. I get a very high degree of management traffic = which
>   limits my available bandwidth, increases the risk of = collisions and
>   even run the risk of violating EU legislation requiring me = to only
>   transmit in less than 1% of the time:
>   http://focus.ti.c= om/lit/an/swra048/swra048.pdf
>  868 - 868.6 MHz: <1%
>
>   Reactiveness is hard to achieve via polling.
>
>
>
> If you agree that this seems to be critical issues please raise = your
> voice on the list.
>
> Going forward
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>
> We need some reactive mechanism to reach lamps before the user = decides
> to sue our companies.
> So is this possible? I think so.
>
> Existing commercial (non-IP) solutions are capable of re-routing = quickly
> if they really have to.
>
> Let me try scoping the requirements to a potential solution:
> (no different from the req. docs for home and building)
>
> * P2P routing in any direction independent of the tree.
>
> * On-demand P2P route discovery if requested by a real-time = critical app.
>  Data collection apps may be able to just wait for the next = DAO update.
>
> * Limited range of discovery mechanism: max 4 repeaters.
>   A TTL field may limit the scope of the repeaters.
>
> * Suboptimal routing and traffic bursts are accepted in = exchange
>   for quick route repair. But only as an exception.
>
>
> Just as an example, one existing home control technology uses a
> (source routing) variant of AODV for quick route repair.
> Nothing comes for free. The price is flooding - but not just = flooding:
> Managed flooding using a distributed algorithm running in all
> participating nodes.
> The algorithm dampens the flooding in a time, volume and range
> perspective.
> Some similar mechanism could be built into RPL for quick route = repair.
>
>
> If anyone have alternative proposals, please bring it to the = list.
> Now is the time.
>
>
>
> Thanks,
>   Anders
>
>
>
>
> _______________________________________________
> Roll mailing 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_009C_01CAC994.A5346E60-- From pal@cs.stanford.edu Mon Mar 22 09:21: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 A18FD28C15F for ; Mon, 22 Mar 2010 09:21:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.272 X-Spam-Level: X-Spam-Status: No, score=-2.272 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, HTML_MESSAGE=0.001, J_CHICKENPOX_12=0.6, J_CHICKENPOX_17=0.6, J_CHICKENPOX_51=0.6, MIME_QP_LONG_LINE=1.396, 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 XxbUELo-J2ic for ; Mon, 22 Mar 2010 09:21:15 -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 ADF893A68CC for ; Mon, 22 Mar 2010 09:20:57 -0700 (PDT) Received: from [166.205.136.70] (helo=[10.38.236.162]) by cs-smtp-2.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1NtkN9-0003SR-GR; Mon, 22 Mar 2010 09:21:15 -0700 References: <1161577952.8138041269244020805.JavaMail.root@mail02.pantherlink.uwm.edu> <6D9687E95918C04A8B30A7D6DA805A3E01AD45CF@zensys17.zensys.local> <009b01cac9cf$51934660$f4b9d320$@sturek@att.net> Message-Id: From: Philip Levis To: "d.sturek@att.net" In-Reply-To: <009b01cac9cf$51934660$f4b9d320$@sturek@att.net> Content-Type: multipart/alternative; boundary=Apple-Mail-1-1057359222 Content-Transfer-Encoding: 7bit X-Mailer: iPhone Mail (7D11) Mime-Version: 1.0 (iPhone Mail 7D11) Date: Mon, 22 Mar 2010 09:20:46 -0700 X-Scan-Signature: 4387dd59fc7aae1bf029d1a4baafca23 Cc: Ted Humpal , ROLL WG Subject: Re: [Roll] P2P performance with current RPL proposal X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Mar 2010 16:21:21 -0000 --Apple-Mail-1-1057359222 Content-Type: text/plain; charset=utf-8; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Just to be sure I am hearing this right -the proposal is to use =20 hopcount-based route selection? Phil On Mar 22, 2010, at 7:52 AM, "Don Sturek" wrote: > Hi Anders and Mukul, > > > > This is all sounding quite promising in addressing P2P routing in =20 > RPL. How can we organize a specific proposal we can gain WG =20 > approval for? I would like to leave Anaheim with an agreed path =20 > towards P2P routing support we all believe addresses the Home =20 > Automation and Building Controls use cases. > > > > Don > > > > > > From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf =20= > Of Anders Brandt > Sent: Monday, March 22, 2010 7:46 AM > To: Mukul Goyal; Pascal Thubert (pthubert) > Cc: ROLL WG; Ted Humpal > Subject: Re: [Roll] P2P performance with current RPL proposal > > > > Add to this an element of promiscuos listening to dampen the storm =20 > =3D> if node already detected a copy of the DIS with the same TTL (or =20= > lower) - do not forward the DIS. Then you start getting closer to =20 > something. > > > > Oh - and by the way - record the source route on the way ;-) > > > > - Anders > > > > Fra: roll-bounces@ietf.org p=C3=A5 vegne af Mukul Goyal > Sendt: ma 22-03-2010 01:47 > Til: Pascal Thubert (pthubert) > Cc: ROLL WG; Ted Humpal > Emne: Re: [Roll] P2P performance with current RPL proposal > > Hi Pascal > > Thanks for your comments (let me send my response in the next email). > > Based on further thoughts, it seems to me that a DAG based P2P =20 > solution would work if we do the following: > > (a) allowing multicast DIS messages to spread to an originator-=20 > specified number of hops and > (b) allowing nodes to join a DAG temporarily and leave it if there =20 > is not sufficient =E2=80=9Crouting interest=E2=80=9D in being part of = the DAG. > > With these points in mind, a P2P scheme could work as follows: > > 1. When a node wants to join a DODAG(D,F), where D is the DODAG's =20 > root and F is the OF being used, it does the following: > a. Initiates a discovery table entry for DODAG(D,F). The =20 > discovery table entries are removed after a certain lifetime. > b. sends out a DIS via link-local multicast asking specifically =20= > for information about DODAG(D,F). It also lists in the DIS the =20 > number of hops the DIS can travel. > > 2. On receiving a DIS, a node does the following: > a.if it does not know about DODAG(D,F) and the DIS hop limit is =20= > not yet reached > i. Initiates a discovery table entry for DODAG(D,F). This =20 > entry maintains information about the nodes from whom the DIS were =20 > received. > ii. sends out the DIS (via link-local multicast with trickle =20= > controlled timing) further. > b. If it is already a part of DODAG(D,F) or is node D itself > i. Send out a DIO about DODAG(D,F) to the node from whom the =20= > DIS was received. > > 3. On receiving a DIO about DODAG(D,F), a node does the following: > a. Ignore the DIO if the node does not have a discovery table =20 > entry for DODAG(D,F) > b. Otherwise, the node joins the DODAG(D,F) (if not already part =20= > of it) or updates its parent set in DODAG(D,F) and sends the DIO by =20= > unicast to the nodes that had sent it the DIS. > > 4. Once, the node is part of the DODAG(D,F), it maintains a =E2=80=9Crou= ting=20 > interest=E2=80=9D for the DODAG in the following manner: > a. Routing interest is a value between 0 and 1 > b. Routing interest is 1 if the node recently forwarded a packet =20= > along the DODAG(D,F) > c. Otherwise, the routing interest is x*maximum routing interest =20= > of the neighbors in DODAG(D,F), where x is a fraction. The node =20 > comes to know of neighbor=E2=80=99s routing interest via the = neighbor=E2=80=99s DI=20 > O. > d. A node leaves a DODAG if its routing interest in the DODAG =20 > goes below a threshold. > > Thanks > Mukul > > ----- Original Message ----- > From: "Pascal Thubert (pthubert)" > To: "Mukul Goyal" > Cc: "ROLL WG" , "Ted Humpal" , =20 > "robert cragie" > Sent: Friday, March 19, 2010 11:20:58 AM GMT -06:00 US/Canada Central > Subject: RE: [Roll] P2P performance with current RPL proposal > > Hi Mukul > > Here I have attempted to formulate a simple DV algorithm in RPL/=20 > DAG terms. > > I will appreciate it if you could let me know about your =20 > objections to this > > proposal: > > [Pascal] It's cool that you do it is the first impression. > > > Node A needs to reach a destination D. Node A initiates a =20 > discovery DAG > > towards D. As the DIOs reach D, it sends a DAO back to selected =20 > parents. As > > the DAO travels towards node A, in-route nodes store the cost to =20 > reach D. > > > > When node B needs to reach D, it similarly initiates a discovery =20 > dag. During > > this discovery, when a DIO reaches a node C that maintains a cost =20= > to reach D, > > node C responds back with a DAO that travels towards B and stores =20= > in in- > > route nodes the cost to reach D. > > [Pascal] understand that you're trying to make RPL even closer to =20 > AODV. > I agree we need to gather as much as we can from that work. > > For the specifics of your proposal: > > - B-C might be orthogonal to A-D so that B/C\D forms an angle. You =20 > do not end up with the best path that you're looking for. > > - there might be multiple C's. Which one is the right one? > > - RPL does not allow packets to switch instances. Following multiple =20= > DAGs is the recipe for loops - unless you have them strictly ordered =20= > by some means like the RPL sequence between iterations, more =20 > specific routes, blah blah...) > > - the A to D path is optimized for a certain constraint. You seem to =20= > imply that the B to D path has the same constraints and metrics so =20 > we can compare apple to apple. Because this is a very delicate =20 > operation, RPL has introduced the Rank, which has the right =20 > properties to make that comparison efficiently.So for RPL, the loop =20= > avoidance metric is the Rank, and it is only valid within an =20 > iteration. > > - A P2P path does not come out of the blue. There must be some =20 > provisionning system that determines that those nodes, A and B, are =20= > very special so they need a P2P optimization, with a given special =20 > OF, and that they both need to talk to D. Well, if that's so, the =20 > most economical is for that system to fork the DAG out of D, with =20 > dual targets A and B. There you obtain the shortest path for both A-=20= > D and B-D for the cost of a single flooding. > > I see that you're trying to get the idea to work better, and I hope =20= > we find a way to do so, maybe along your lines if we can solve the =20 > issues above. But before we get there, we need to agree that this is =20= > the path we wish to take. > > Cheers, > > Pascal > > > > > > ----- Original Message ----- > > From: "Pascal Thubert (pthubert)" > > To: "robert cragie" > > Cc: "ROLL WG" , "Ted Humpal" > > Sent: Thursday, March 18, 2010 9:23:14 PM GMT -06:00 US/Canada =20 > Central > > Subject: Re: [Roll] P2P performance with current RPL proposal > > > > > > > > > > > > Hi Robert : > > > > > > > > At least from a distance, the proposed mechanism emulates AODV, =20 > with the > > DIO as RREQ and the DAO as RREP. So if we decide to dig along =20 > those lines, > > we=E2=80=99ll certainly appreciate help from MANET experts. I=E2=80=99= d say =20 > that if you > > already have RPL for P2MP and MP2P, the proposed extension are =20 > probably > > simpler to add than doing AODV from scratch. > > > > > > > > For the setup, the major differences are that we build a DAG and =20 > that we can > > indicate multiple targets. If you look at it, the DAG capability =20 > is a MUST for > > RPL, and I have not seen that this MUST goes away for P2P flows. The > > multiple targets is something that appears in a number of use =20 > cases and it > > seems more economical to build a single DAG for multiple targets =20 > when > > possible. > > > > > > > > For the maintenance, the major differences are that we have the =20 > DAG as > > first line of defense, and the RPL detection to stimulate the =20 > local repair. > > > > > > > > About your questions: > > > > > > > > The DODAG root is the one that spawns the DAG. The targets can =20 > reach the > > root because the root advertises itself in the DIO. The idea is =20 > that the root ID > > is the address that the targets need to talk to. If needed, the =20 > root can also > > advertise a prefix that it can reach and that the targets need to =20= > reach too. > > > > > > > > All the intermediate nodes that are confirmed by the DAO need to =20 > retain at > > least info about the DAG. That enables the targets to reach the =20 > root. The > > flooding should cost about the same as that of AODV but the RPL =20 > way will > > require more states in the nodes on the way if the OF requires a =20 > DAG. > > > > > > > > The way back (down) can be stateful of stateless, depending on =20 > which DAO > > we=E2=80=99re using. With fully stateful DAO, we are really in = AODV-land. =20 > With > > stateless, we could drift into DSR-land for that direction. Which =20= > limits we > > place to keep it simple will be determined by the resolution of =20 > issue #26 I > > guess=E2=80=A6 > > > > > > > > And please, no apologize or on one will dare post anything =20 > anymore. Your > > questions are fully relevant and at the core of the discussion. > > > > > > > > I hope we can talk in Anaheim for sure, > > > > > > > > > > Pascal > > > > > > > > > > > > > > From: Robert Cragie [mailto:robert.cragie@gridmerge.com] > > Sent: Monday, March 15, 2010 11:27 AM > > To: Pascal Thubert (pth ubert) > > Cc: Ted.Humpal@jci.com; ROLL WG > > Subject: Re: [Roll] P2P performance with current RPL proposal > > > > > > > > Hi Pascal, > > > > So in your slideware T can end up talking to R (DODAG root) =20 > through the > > DODAG. So are you proposing that all potential targets can act as =20= > a DODAG > > root? And therefore all intermediates have to retain DIO propagation > > support for that DODAG as well? This may work for limited P2P but =20= > seems > > less efficient than simple distance vector flooding RREQ/RREP like =20= > AODV or > > DYMO for generic P2P. What about R to T (or anyone else for that =20 > matter)? > > Do we source route, maintain state, some undefined hybrid of the =20 > two? > > > > I apologise if some of these questions have been answered in =20 > detail in earlier > > reflector posts but I have only recently started to concentrate my =20= > efforts on > > RPL and have 82 pages to wade through :-). I look forward to a =20 > productive > > session in Anaheim. > > > > Robert > > > > > > Robert Cragie (Pacific Gas & Electric) > > > > Gridmerge Ltd. > > 89 Greenfield Crescent, > > Wakefield, WF4 4WA, UK > > +44 (0) 1924 910888 > > http://www.gridmerge.com > > > > > > > > Pascal Thubert (pthubert) wrote: > > > > HI Robert : > > > > > > > > I respectfully have to disagree. > > > > > > > > My understanding is that we are considering a limited set of P2P =20 > pairs, for > > which the specific path that we need to create might have to obey =20= > specific > > constraints. > > > > So it makes sense to use an on-demand technique, probably inspired =20= > by the > > MANET Reactive protocols. > > > > > > > > As it goes, those protocols usually use flooding for a node to =20 > locate another. > > Forking a DAG is just another flooding. It does not take a lot of =20= > addition to the > > existing DIO for a root to use RPL to build a DAG that contains =20 > one or multiple > > Targets as leaves, under a set of constraints expressed as an =20 > objective > > function. Please find attached a slideware that illustrates that. > > > > > > > > > > Pascal > > > > > > > > > > > > > > From: roll-bounces@ietf.org [ mailto:roll-bounces@ietf.org ] On =20 > Behalf Of > > Robert Cragie > > Sent: Thursday, March 11, 2010 2:43 PM > > To: Ted.Humpal@jci.com > > Cc: ROLL WG > > Subject: Re: [Roll] P2P performance with current RPL proposal > > > > > > > > I agree with Ted's comments below. Creating a DODAG for every =20 > reachable > > node as a root seems a very inefficient approach compared to =20 > alternative > > routing algorithms. I am concerned that RPL does not actually meet =20= > the > > original requirements in I-D.ietf-roll-building-routing-reqs, I-=20 > D.ietf-roll-home- > > routing-reqs, RFC5673 and RFC5548. The traffic pattern requirement =20= > for a > > sink node features prominently in only two of those documents. =20 > Even in this > > case, as Ted points out, communication is likely to be =20 > bidirectional (e.g. end- > > to-end acks.) therefore the DODAG approach is fundamentally =20 > asymmetric, > > especially if no intermediate storage is allowed for destination =20 > routes and > > source routing has to be used. > > > > Also, RPL seems highly complex for what are constrained nodes in =20 > terms of > > memory as well as power and bandwidth. The RPL draft as it stands =20= > is 82 > > pages long and that doesn't include text about the objective =20 > function. > > > > Robert > > > > > > Robert Cragie (Pacific Gas & Electric) > > > > Gridmerge Ltd. > > 89 Greenfield Crescent, > > Wakefield, WF4 4WA, UK > > +44 (0) 1924 910888 > > http://www.gridmerge.com > > > > > > > > Ted.Humpal@jci.com wrote: > > > > > > A concern also will be how much overhead (memory space) will be =20 > required > > for a DODAG Root? > > > > and based on the first question how many DODAG roots a lamp may =20 > need to > > be a member of? > > > > For example in lighting a single lamp may be a root for a single =20= > switch (1 > > DODAG root), this lamp / luminaire may also > > be a member of another group - - which could be all lights on the =20= > floor (2nd > > DODAG root), and a third group > > of all the lights in the building. There can be many more =20 > speciality groups > > associated based on the building configuration. > > Consider also during the installation time - how these DODAG roots =20= > will be > > configured? Must I commission each device > > to tell it which DODAG it must use for its Object Function? How =20 > easy will this > > be to change and add in a new DODAG root > > for the end user if the lighting group changes?? > > > > With respect to Jerry Martocci's - commercial building =20 > requirements - every > > device may need to communicate to any or > > all of the end devices. If each device must establish a DODAG for =20= > the other > > 499 devices in a 500 node network - How much memory > > space will this require for each end device to maintain? > > > > Keep in mind that the end devices are very limited processor and =20 > memory > > wise. > > > > Not to mention all of the network maintenance messages that would =20= > need > > to be transmitted to maintain all of these DODAGs. > > > > Consider the reconvergence time when one device is turned off and =20= > it was in > > the middle of the majority of the 100+ DODAGS? > > > > In many lighting and building application an application =20 > acknowledgement - > > must be returned {Back down the DODAG} so . . . the > > requirement is not just getting to the Root - a return path must =20 > also be > > maintained and have a low latency path. > > > > Ted Humpal > > > > > > > > > > > > > > From: > > > > Kris Pister > > > > > > To: > > > > Anders Brandt > > > > > > Cc: > > > > ROLL WG > > > > > > Date: > > > > 03/08/2010 01:45 PM > > > > > > Subject: > > > > Re: [Roll] P2P performance with current RPL proposal > > > > > > > > > > > > > > > > > > Anders - if we take JP's suggestion to make The Lamp a DODAG root, =20= > and > > take Phoebus' recommendation that we use path diversity to improve =20= > end- > > to-end reliability, do you see a chance of success? > > In my experience, with diverse paths and order-minutes updates you =20= > get > > extremely high reliability. > > > > I have no aversion to TTL-limited floods as a part of a solution =20 > either. I'm > > open to ideas on how to bring those in as (presumably infrequently =20= > used) > > options. > > > > ksjp > > > > Anders Brandt wrote: > > Hello > > > > I would like to probe the temperature of the WG on using DAOs to > > support P2P. > > > > The building and home application spaces (and maybe others) have > > a few clearly defined requirements. > > It is not obvious to me how the current RPL proposal (cRPLp) can > > satisfy those requirements: > > > > > > In both cases it is the worst case scenario that hurts: > > > > > > P2P routing inside the PAN > > =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 > > cRPLp has no way of routing inside the PAN if you need more than > > one repeater. cRPLp has to go all the way to the top (maybe 4 hops =20= > up) > > and down again (maybe 4 hops down) to get just 2 hops to the side. > > > > The consequence is high latency and high levels of background noise > > for nodes just outside the direct radio range. > > At the same time the risk of meeting a failing link is 4 times =20 > higher =3D> > > latency may be much more than 4 times larger. > > > > Latency may sound like a minor issue but it actually translates =20 > directly > > into lower battery lifetime. In the above (very realistic) example, > > the battery lifetime is reduced to 25% of what it should be. > > > > We have lots of battery devices sending into the network: > > * PIR sensors turning on lights > > * Door locks sending alarms > > * Door/window sensors starting chimes > > * Smoke sensors triggering an alarm system > > > > > > > > > > Response time > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > The latency issue is important. > > When a user (real human being) presses a light button the user =20 > expects > > the light to turn on. > > cRPLp proposes that nodes in the tree periodically advertises their > > presence using DAOs. > > The periodicity is a real beast: > > Thanks to Trickle, the rate of updates in a (apparently) stable =20 > network > > is low. This is good since it leaves bandwidth for data. > > But it is not good if existing routes to my lamp fail and I do not =20= > get > > new routes to my lamp until it decides to send out a new DAO. > > My user will (with a good reason) not tolerate waiting for minutes =20= > for > > the light to turn on. > > > > I have met two arguments to counter this concern: > > > > A1: Well, your lamp can always send a DAO when it detects a problem. > > My answer: > > True, except that my lamp does not intend to send anything > > so it will never experience any problems from its side of the =20 > network. > > > > A2: Well, you can increase the DAO rate to sub-second updates. > > My answer: > > Oh no. I get a very high degree of management traffic which > > limits my available bandwidth, increases the risk of collisions =20= > and > > even run the risk of violating EU legislation requiring me to only > > transmit in less than 1% of the time: > > http://focus.ti.com/lit/an/swra048/swra048.pdf > > 868 - 868.6 MHz: <1% > > > > Reactiveness is hard to achieve via polling. > > > > > > > > If you agree that this seems to be critical issues please raise your > > voice on the list. > > > > Going forward > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > > We need some reactive mechanism to reach lamps before the user =20 > decides > > to sue our companies. > > So is this possible? I think so. > > > > Existing commercial (non-IP) solutions are capable of re-routing =20 > quickly > > if they really have to. > > > > Let me try scoping the requirements to a potential solution: > > (no different from the req. docs for home and building) > > > > * P2P routing in any direction independent of the tree. > > > > * On-demand P2P route discovery if requested by a real-time =20 > critical app. > > Data collection apps may be able to just wait for the next DAO =20 > update. > > > > * Limited range of discovery mechanism: max 4 repeaters. > > A TTL field may limit the scope of the repeaters. > > > > * Suboptimal routing and traffic bursts are accepted in exchange > > for quick route repair. But only as an exception. > > > > > > Just as an example, one existing home control technology uses a > > (source routing) variant of AODV for quick route repair. > > Nothing comes for free. The price is flooding - but not just =20 > flooding: > > Managed flooding using a distributed algorithm running in all > > participating nodes. > > The algorithm dampens the flooding in a time, volume and range > > perspective. > > Some similar mechanism could be built into RPL for quick route =20 > repair. > > > > > > If anyone have alternative proposals, please bring it to the list. > > Now is the time. > > > > > > > > Thanks, > > Anders > > > > > > > > > > _______________________________________________ > > Roll mailing 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 --Apple-Mail-1-1057359222 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Just to be sure I am hearing this = right -the proposal is to use hopcount-based route = selection?

Phil

On Mar 22, 2010, = at 7:52 AM, "Don Sturek" <d.sturek@att.net> = wrote:

Hi Anders and Mukul,

 

This is all sounding quite promising in addressing P2P = routing in RPL.  How can we organize a specific proposal we can gain WG = approval for?  I would like to leave Anaheim with an agreed path towards P2P routing = support we all believe addresses the Home Automation and Building Controls use = cases.

 

Don

 

 

From: roll-bounces@ietf.org = [mailto:roll-bounces@ietf.org] On Behalf Of Anders Brandt
Sent: Monday, March 22, 2010 7:46 AM
To: Mukul Goyal; Pascal Thubert (pthubert)
Cc: ROLL WG; Ted Humpal
Subject: Re: [Roll] P2P performance with current RPL = proposal

 

Add to this an element of promiscuos listening to dampen = the storm =3D> if node already detected a copy of the DIS with the same TTL (or = lower) - do not forward the DIS. Then you start getting closer to = something.

 

Oh - and by the way - record the source route on the way = ;-)

 

- Anders

 

Fra: roll-bounces@ietf.org p=C3=A5 = vegne af Mukul Goyal
Sendt: ma 22-03-2010 01:47
Til: Pascal Thubert (pthubert)
Cc: ROLL WG; Ted Humpal
Emne: Re: [Roll] P2P performance with current RPL = proposal

Hi Pascal

Thanks for your comments (let me send my response in the next = email).

Based on further thoughts, it seems to me that a DAG based P2P solution = would work if we do the following:

(a) allowing multicast DIS messages to spread to an originator-specified = number of hops and
(b) allowing nodes to join a DAG temporarily and leave it if there is = not sufficient =E2=80=9Crouting interest=E2=80=9D in being part of the = DAG.

With these points in mind, a P2P scheme could work as follows:

1. When a node wants to join a DODAG(D,F), where D is the DODAG's root = and F is the OF being used, it does the following:
    a. Initiates a discovery table entry for DODAG(D,F). = The discovery table entries are removed after a certain lifetime.
    b. sends out a DIS via link-local multicast asking specifically for information about DODAG(D,F). It also lists in the DIS = the number of hops the DIS can travel.

2. On receiving  a DIS, a node does the following:
    a.if it does not know about DODAG(D,F) and the DIS = hop limit is not yet reached
        i. Initiates a discovery = table entry for DODAG(D,F). This entry maintains information about the nodes from = whom the DIS were received.
        ii. sends out the DIS (via link-local multicast with trickle controlled timing) further.
    b. If it is already a part of DODAG(D,F) or is node D = itself
        i. Send out a DIO about = DODAG(D,F) to the node from whom the DIS was received.

3. On receiving a DIO about DODAG(D,F), a node does the following:
    a. Ignore the DIO if the node does not have a = discovery table entry for DODAG(D,F)
    b. Otherwise, the node joins the DODAG(D,F) (if not = already part of it) or updates its parent set in DODAG(D,F) and sends the DIO by unicast to the nodes that had sent it the DIS.

4. Once, the node is part of the DODAG(D,F), it maintains a =E2=80=9Crouti= ng interest=E2=80=9D for the DODAG in the following manner:
    a. Routing interest is a value between 0 and 1
    b. Routing interest is 1 if the node recently = forwarded a packet along the DODAG(D,F)
    c. Otherwise, the routing interest is x*maximum = routing interest of the neighbors in DODAG(D,F), where x is a fraction. The node = comes to know of neighbor=E2=80=99s routing interest via the neighbor=E2=80=99s = DIO.
    d. A node leaves a DODAG if its routing interest in = the DODAG goes below a threshold.

Thanks
Mukul

----- Original Message -----
From: "Pascal Thubert (pthubert)" <pthubert@cisco.com>
To: "Mukul Goyal" <mukul@uwm.edu>
Cc: "ROLL WG" <roll@ietf.org>, = "Ted Humpal" <Ted.Humpal@jci.com>, = "robert cragie" <robert.cragie@gridmerge.com>
Sent: Friday, March 19, 2010 11:20:58 AM GMT -06:00 US/Canada = Central
Subject: RE: [Roll] P2P performance with current RPL proposal

Hi Mukul
> Here I have attempted to formulate a simple DV algorithm in RPL/DAG = terms.
> I will appreciate it if you could let me know about your objections = to this
> proposal:

[Pascal] It's cool that you do it is the first impression.

> Node A needs to reach a destination D. Node A initiates a discovery = DAG
> towards D. As the DIOs reach D, it sends a DAO back to selected = parents. As
> the DAO travels towards node A, in-route nodes store the cost to = reach D.
>
> When node B needs to reach D, it similarly initiates a discovery = dag. During
> this discovery, when a DIO reaches a node C that maintains a cost = to reach D,
> node C responds back with a DAO that travels towards B and stores = in in-
> route nodes the cost to reach D.

[Pascal]  understand that you're trying to make RPL even closer to = AODV.
I agree we need to gather as much as we can from that work.

For the specifics of your proposal:

- B-C might be orthogonal to A-D so that B/C\D forms an angle. You do = not end up with the best path that you're looking for.

- there might be multiple C's. Which one is the right one?

- RPL does not allow packets to switch instances. Following multiple = DAGs is the recipe for loops - unless you have them strictly ordered by some = means like the RPL sequence between iterations, more specific routes, blah = blah...)

- the A to D path is optimized for a certain constraint. You seem to = imply that the B to D path has the same constraints and metrics so we can compare = apple to apple. Because this is a very delicate operation, RPL has introduced the = Rank, which has the right properties to make that comparison efficiently.So = for RPL, the loop avoidance metric is the Rank, and it is only valid within an iteration.

- A P2P path does not come out of the blue. There must be some = provisionning system that determines that those nodes, A and B, are very special so = they need a P2P optimization, with a given special OF, and that they both need to = talk to D. Well, if that's so, the most economical is for that system to fork = the DAG out of D, with dual targets A and B. There you obtain the shortest path = for both A-D and B-D for the cost of a single flooding.

I see that you're trying to get the idea to work better, and I hope we = find a way to do so, maybe along your lines if we can solve the issues above. = But before we get there, we need to agree that this is the path we wish to = take.

Cheers,

Pascal


>
> ----- Original Message -----
> From: "Pascal Thubert (pthubert)" <pthubert@cisco.com>
> To: "robert cragie" <robert.cragie@gridmerge.com>
> Cc: "ROLL WG" <roll@ietf.org>, "Ted Humpal" <Ted.Humpal@jci.com>
> Sent: Thursday, March 18, 2010 9:23:14 PM GMT -06:00 US/Canada = Central
> Subject: Re: [Roll] P2P performance with current RPL proposal
>
>
>
>
>
> Hi Robert :
>
>
>
> At least from a distance, the proposed mechanism emulates AODV, = with the
> DIO as RREQ and the DAO as RREP. So if we decide to dig along those = lines,
> we=E2=80=99ll certainly appreciate help from MANET experts. I=E2=80=99= d say that if you
> already have RPL for P2MP and MP2P, the proposed extension are = probably
> simpler to add than doing AODV from scratch.
>
>
>
> For the setup, the major differences are that we build a DAG and = that we can
> indicate multiple targets. If you look at it, the DAG capability is = a MUST for
> RPL, and I have not seen that this MUST goes away for P2P flows. = The
> multiple targets is something that appears in a number of use cases = and it
> seems more economical to build a single DAG for multiple targets = when
> possible.
>
>
>
> For the maintenance, the major differences are that we have the DAG = as
> first line of defense, and the RPL detection to stimulate the local repair.
>
>
>
> About your questions:
>
>
>
> The DODAG root is the one that spawns the DAG. The targets can = reach the
> root because the root advertises itself in the DIO. The idea is = that the root ID
> is the address that the targets need to talk to. If needed, the = root can also
> advertise a prefix that it can reach and that the targets need to = reach too.
>
>
>
> All the intermediate nodes that are confirmed by the DAO need to = retain at
> least info about the DAG. That enables the targets to reach the = root. The
> flooding should cost about the same as that of AODV but the RPL way = will
> require more states in the nodes on the way if the OF requires a = DAG.
>
>
>
> The way back (down) can be stateful of stateless, depending on = which DAO
> we=E2=80=99re using. With fully stateful DAO, we are really in = AODV-land. With
> stateless, we could drift into DSR-land for that direction. Which = limits we
> place to keep it simple will be determined by the resolution of = issue #26 I
> guess=E2=80=A6
>
>
>
> And please, no apologize or on one will dare post anything anymore. = Your
> questions are fully relevant and at the core of the discussion.
>
>
>
> I hope we can talk in Anaheim for sure,
>
>
>
>
> Pascal
>
>
>
>
>
>
> From: Robert Cragie [mailto:robert.cragie@gridmerge= .com]
> Sent: Monday, March 15, 2010 11:27 AM
> To: Pascal Thubert (pth ubert)
> Cc: Ted.Humpal@jci.com; = ROLL WG
> Subject: Re: [Roll] P2P performance with current RPL proposal
>
>
>
> Hi Pascal,
>
> So in your slideware T can end up talking to R (DODAG root) through = the
> DODAG. So are you proposing that all potential targets can act as a = DODAG
> root? And therefore all intermediates have to retain DIO = propagation
> support for that DODAG as well? This may work for limited P2P but = seems
> less efficient than simple distance vector flooding RREQ/RREP like = AODV or
> DYMO for generic P2P. What about R to T (or anyone else for that = matter)?
> Do we source route, maintain state, some undefined hybrid of the = two?
>
> I apologise if some of these questions have been answered in detail = in earlier
> reflector posts but I have only recently started to concentrate my = efforts on
> RPL and have 82 pages to wade through :-). I look forward to a = productive
> session in Anaheim.
>
> Robert
>
>
> Robert Cragie (Pacific Gas & Electric)
>
> Gridmerge Ltd.
> 89 Greenfield Crescent,
> Wakefield, WF4 4WA, UK
> +44 (0) 1924 910888
> http://www.gridmerge.com
>
>
>
> Pascal Thubert (pthubert) wrote:
>
> HI Robert :
>
>
>
> I respectfully have to disagree.
>
>
>
> My understanding is that we are considering a limited set of P2P = pairs, for
> which the specific path that we need to create might have to obey = specific
> constraints.
>
> So it makes sense to use an on-demand technique, probably inspired = by the
> MANET Reactive protocols.
>
>
>
> As it goes, those protocols usually use flooding for a node to = locate another.
> Forking a DAG is just another flooding. It does not take a lot of = addition to the
> existing DIO for a root to use RPL to build a DAG that contains one = or multiple
> Targets as leaves, under a set of constraints expressed as an = objective
> function. Please find attached a slideware that illustrates = that.
>
>
>
>
> Pascal
>
>
>
>
>
>
> From: roll-bounces@ietf.org [ mailto:roll-bounces@ietf.org= ] On Behalf Of
> Robert Cragie
> Sent: Thursday, March 11, 2010 2:43 PM
> To: Ted.Humpal@jci.com
> Cc: ROLL WG
> Subject: Re: [Roll] P2P performance with current RPL proposal
>
>
>
> I agree with Ted's comments below. Creating a DODAG for every = reachable
> node as a root seems a very inefficient approach compared to = alternative
> routing algorithms. I am concerned that RPL does not actually meet = the
> original requirements in I-D.ietf-roll-building-routing-reqs, I-D.ietf-roll-home-
> routing-reqs, RFC5673 and RFC5548. The traffic pattern requirement = for a
> sink node features prominently in only two of those documents. Even = in this
> case, as Ted points out, communication is likely to be = bidirectional (e.g. end-
> to-end acks.) therefore the DODAG approach is fundamentally = asymmetric,
> especially if no intermediate storage is allowed for destination = routes and
> source routing has to be used.
>
> Also, RPL seems highly complex for what are constrained nodes in = terms of
> memory as well as power and bandwidth. The RPL draft as it stands = is 82
> pages long and that doesn't include text about the objective = function.
>
> Robert
>
>
> Robert Cragie (Pacific Gas & Electric)
>
> Gridmerge Ltd.
> 89 Greenfield Crescent,
> Wakefield, WF4 4WA, UK
> +44 (0) 1924 910888
> http://www.gridmerge.com
>
>
>
> Ted.Humpal@jci.com = wrote:
>
>
> A concern also will be how much overhead (memory space) will be = required
> for a DODAG Root?
>
> and based on the first question how many DODAG roots a lamp may = need to
> be a member of?
>
> For example in lighting  a single lamp may be a root for a = single switch (1
> DODAG root),  this lamp / luminaire may also
> be a member of another group - -  which could be all lights on = the floor (2nd
> DODAG root), and a third group
> of all the lights in the building.  There can be many more = speciality groups
> associated based on the building configuration.
> Consider also during the installation time - how these DODAG roots = will be
> configured?  Must I commission each device
> to tell it which DODAG it must use for its Object Function? =  How easy will this
> be to change and add in a new DODAG root
> for the end user if the lighting group changes??
>
> With respect to Jerry Martocci's - commercial building requirements = - every
> device may need to communicate to any or
> all of the end devices.  If each device must establish a DODAG = for the other
> 499 devices in a 500 node network - How much memory
> space will this require for each end device to maintain?
>
> Keep in mind that the end devices are very limited processor and = memory
> wise.
>
> Not to mention all of the network maintenance messages that would = need
> to be transmitted to maintain all of these DODAGs.
>
> Consider the reconvergence time when one device is turned off and = it was in
> the middle of the majority of the 100+ DODAGS?
>
> In many lighting and building application an application = acknowledgement -
> must be returned {Back down the DODAG} so . . . the
> requirement is not just getting to the Root - a return path must = also be
> maintained and have a  low latency path.
>
> Ted Humpal
>
>
>
>
>
>
> From:
>
> Kris Pister <pister@eecs.berkeley.edu><= br> >
>
> To:
>
> Anders Brandt <abr@sdesigns.dk>
>
>
> Cc:
>
> ROLL WG <roll@ietf.org>
>
>
> Date:
>
> 03/08/2010 01:45 PM
>
>
> Subject:
>
> Re: [Roll] P2P performance with current RPL proposal
>
>
>
>
>
>
>
>
> Anders - if we take JP's suggestion to make The Lamp a DODAG root, = and
> take Phoebus' recommendation that we use path diversity to improve = end-
> to-end reliability, do you see a chance of success?
> In my experience, with diverse paths and order-minutes updates you = get
> extremely high reliability.
>
> I have no aversion to TTL-limited floods as a part of a solution = either.  I'm
> open to ideas on how to bring those in as (presumably infrequently = used)
> options.
>
> ksjp
>
> Anders Brandt wrote:
> Hello
>
> I would like to probe the temperature of the WG on using DAOs = to
> support P2P.
>
> The building and home application spaces (and maybe others) = have
> a few clearly defined requirements.
> It is not obvious to me how the current RPL proposal (cRPLp) = can
> satisfy those requirements:
>
>
> In both cases it is the worst case scenario that hurts:
>
>
> P2P routing inside the PAN
> =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
> cRPLp has no way of routing inside the PAN if you need more = than
> one repeater. cRPLp has to go all the way to the top (maybe 4 hops = up)
> and down again (maybe 4 hops down) to get just 2 hops to the = side.
>
> The consequence is high latency and high levels of background = noise
> for nodes just outside the direct radio range.
> At the same time the risk of meeting a failing link is 4 times = higher =3D>
> latency may be much more than 4 times larger.
>
> Latency may sound like a minor issue but it actually translates = directly
> into lower battery lifetime. In the above (very realistic) = example,
> the battery lifetime is reduced to 25% of what it should be.
>
> We have lots of battery devices sending into the network:
> * PIR sensors turning on lights
> * Door locks sending alarms
> * Door/window sensors starting chimes
> * Smoke sensors triggering an alarm system
>
>
>
>
> Response time
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> The latency issue is important.
> When a user (real human being) presses a light button the user = expects
> the light to turn on.
> cRPLp proposes that nodes in the tree periodically advertises = their
> presence using DAOs.
> The periodicity is a real beast:
> Thanks to Trickle, the rate of updates in a (apparently) stable = network
> is low. This is good since it leaves bandwidth for data.
> But it is not good if existing routes to my lamp fail and I do not = get
> new routes to my lamp until it decides to send out a new DAO.
> My user will (with a good reason) not tolerate waiting for minutes = for
> the light to turn on.
>
> I have met two arguments to counter this concern:
>
> A1: Well, your lamp can always send a DAO when it detects a = problem.
>   My answer:
>   True, except that my lamp does not intend to send = anything
>   so it will never experience any problems from its side of = the network.
>
> A2: Well, you can increase the DAO rate to sub-second updates.
>   My answer:
>   Oh no. I get a very high degree of management traffic = which
>   limits my available bandwidth, increases the risk of = collisions and
>   even run the risk of violating EU legislation requiring me = to only
>   transmit in less than 1% of the time:
>   http://focus.ti.co= m/lit/an/swra048/swra048.pdf
>  868 - 868.6 MHz: <1%
>
>   Reactiveness is hard to achieve via polling.
>
>
>
> If you agree that this seems to be critical issues please raise = your
> voice on the list.
>
> Going forward
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>
> We need some reactive mechanism to reach lamps before the user = decides
> to sue our companies.
> So is this possible? I think so.
>
> Existing commercial (non-IP) solutions are capable of re-routing = quickly
> if they really have to.
>
> Let me try scoping the requirements to a potential solution:
> (no different from the req. docs for home and building)
>
> * P2P routing in any direction independent of the tree.
>
> * On-demand P2P route discovery if requested by a real-time = critical app.
>  Data collection apps may be able to just wait for the next = DAO update.
>
> * Limited range of discovery mechanism: max 4 repeaters.
>   A TTL field may limit the scope of the repeaters.
>
> * Suboptimal routing and traffic bursts are accepted in = exchange
>   for quick route repair. But only as an exception.
>
>
> Just as an example, one existing home control technology uses a
> (source routing) variant of AODV for quick route repair.
> Nothing comes for free. The price is flooding - but not just = flooding:
> Managed flooding using a distributed algorithm running in all
> participating nodes.
> The algorithm dampens the flooding in a time, volume and range
> perspective.
> Some similar mechanism could be built into RPL for quick route = repair.
>
>
> If anyone have alternative proposals, please bring it to the = list.
> Now is the time.
>
>
>
> Thanks,
>   Anders
>
>
>
>
> _______________________________________________
> Roll mailing list
> Roll@ietf.org
> https://www.ietf.org/m= ailman/listinfo/roll
>  _______________________________________________
> Roll mailing list
> Roll@ietf.org
> https://www.ietf.org/m= ailman/listinfo/roll
>
>
>
>
>
>   _______________________________________________ Roll = mailing
> list Roll@ietf.org https://www.ietf.org/m= ailman/listinfo/roll
> _______________________________________________
> Roll mailing list
> Roll@ietf.org
> https://www.ietf.org/m= ailman/listinfo/roll
_______________________________________________
Roll mailing list
Roll@ietf.org
https://www.ietf.org/m= ailman/listinfo/roll

_______________________________________________
Roll mailing list
Roll@ietf.org
https://www.ietf.org/m= ailman/listinfo/roll
= --Apple-Mail-1-1057359222-- From abr@sdesigns.dk Mon Mar 22 09:31: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 6624728C16F for ; Mon, 22 Mar 2010 09:31:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.58 X-Spam-Level: X-Spam-Status: No, score=0.58 tagged_above=-999 required=5 tests=[AWL=-1.148, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, HTML_MESSAGE=0.001, J_CHICKENPOX_12=0.6, J_CHICKENPOX_17=0.6, J_CHICKENPOX_51=0.6, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2wR-PcCEB7Qg for ; Mon, 22 Mar 2010 09:30:58 -0700 (PDT) Received: from mail.zen-sys.com (mail.zen-sys.com [195.215.56.170]) by core3.amsl.com (Postfix) with ESMTP id 405403A68B2 for ; Mon, 22 Mar 2010 09:30:54 -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_01CAC9DD.15338D9E" Date: Mon, 22 Mar 2010 17:31:11 +0100 Message-ID: <6D9687E95918C04A8B30A7D6DA805A3E01AD45D2@zensys17.zensys.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] P2P performance with current RPL proposal Thread-Index: AcrJ27QCOcDu36d8SkWfPrOHLFLUZwAAKJZg References: <1161577952.8138041269244020805.JavaMail.root@mail02.pantherlink.uwm.edu> <6D9687E95918C04A8B30A7D6DA805A3E01AD45CF@zensys17.zensys.local> <009b01cac9cf$51934660$f4b9d320$@sturek@att.net> From: "Anders Brandt" To: "Philip Levis" , Cc: ROLL WG , Ted Humpal Subject: Re: [Roll] P2P performance with current RPL proposal X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Mar 2010 16:31:14 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CAC9DD.15338D9E Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Well, yes. =20 But it needs to be seen in the right context: I really need to get my lamp turned on within seconds when my users = press the button. Even if this meens that I get a less-than-optimal route. =20 The intention is not to skip all the nice DODAG DIO work that was done. = It serves a good purpose in large networks. The case is just that home & building have some tougher requirements = within restricted areas (<=3D 4 repeaters) such as battery-friendly (i.e. short routes) and reactive discovery to = "guarantee" low response times always. =20 The challenge is to get this for free. =20 - Anders ________________________________ Fra: Philip Levis [mailto:pal@cs.stanford.edu] Sendt: ma 22-03-2010 10:20 Til: d.sturek@att.net Cc: Anders Brandt; Mukul Goyal; Pascal Thubert (pthubert); ROLL WG; Ted = Humpal Emne: Re: [Roll] P2P performance with current RPL proposal Just to be sure I am hearing this right -the proposal is to use = hopcount-based route selection? Phil On Mar 22, 2010, at 7:52 AM, "Don Sturek" wrote: Hi Anders and Mukul, =20 This is all sounding quite promising in addressing P2P routing in RPL. = How can we organize a specific proposal we can gain WG approval for? I = would like to leave Anaheim with an agreed path towards P2P routing = support we all believe addresses the Home Automation and Building = Controls use cases. =20 Don =20 =20 From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of = Anders Brandt Sent: Monday, March 22, 2010 7:46 AM To: Mukul Goyal; Pascal Thubert (pthubert) Cc: ROLL WG; Ted Humpal Subject: Re: [Roll] P2P performance with current RPL proposal =20 Add to this an element of promiscuos listening to dampen the storm =3D> = if node already detected a copy of the DIS with the same TTL (or lower) = - do not forward the DIS. Then you start getting closer to something. =20 Oh - and by the way - record the source route on the way ;-) =20 - Anders =20 ________________________________ Fra: roll-bounces@ietf.org p=E5 vegne af Mukul Goyal Sendt: ma 22-03-2010 01:47 Til: Pascal Thubert (pthubert) Cc: ROLL WG; Ted Humpal Emne: Re: [Roll] P2P performance with current RPL proposal Hi Pascal =09 Thanks for your comments (let me send my response in the next email). =09 Based on further thoughts, it seems to me that a DAG based P2P solution = would work if we do the following: =09 (a) allowing multicast DIS messages to spread to an = originator-specified number of hops and (b) allowing nodes to join a DAG temporarily and leave it if there is = not sufficient "routing interest" in being part of the DAG. =09 With these points in mind, a P2P scheme could work as follows: =09 1. When a node wants to join a DODAG(D,F), where D is the DODAG's root = and F is the OF being used, it does the following: a. Initiates a discovery table entry for DODAG(D,F). The discovery = table entries are removed after a certain lifetime. b. sends out a DIS via link-local multicast asking specifically for = information about DODAG(D,F). It also lists in the DIS the number of = hops the DIS can travel. =09 2. On receiving a DIS, a node does the following: a.if it does not know about DODAG(D,F) and the DIS hop limit is not = yet reached i. Initiates a discovery table entry for DODAG(D,F). This entry = maintains information about the nodes from whom the DIS were received. ii. sends out the DIS (via link-local multicast with trickle = controlled timing) further. b. If it is already a part of DODAG(D,F) or is node D itself i. Send out a DIO about DODAG(D,F) to the node from whom the = DIS was received. =09 3. On receiving a DIO about DODAG(D,F), a node does the following: a. Ignore the DIO if the node does not have a discovery table entry = for DODAG(D,F) b. Otherwise, the node joins the DODAG(D,F) (if not already part of = it) or updates its parent set in DODAG(D,F) and sends the DIO by unicast = to the nodes that had sent it the DIS. =09 4. Once, the node is part of the DODAG(D,F), it maintains a "routing = interest" for the DODAG in the following manner: a. Routing interest is a value between 0 and 1 b. Routing interest is 1 if the node recently forwarded a packet = along the DODAG(D,F) c. Otherwise, the routing interest is x*maximum routing interest of = the neighbors in DODAG(D,F), where x is a fraction. The node comes to = know of neighbor's routing interest via the neighbor's DIO. d. A node leaves a DODAG if its routing interest in the DODAG goes = below a threshold. =09 Thanks Mukul =09 ----- Original Message ----- From: "Pascal Thubert (pthubert)" To: "Mukul Goyal" Cc: "ROLL WG" , "Ted Humpal" , = "robert cragie" Sent: Friday, March 19, 2010 11:20:58 AM GMT -06:00 US/Canada Central Subject: RE: [Roll] P2P performance with current RPL proposal =09 Hi Mukul > Here I have attempted to formulate a simple DV algorithm in RPL/DAG = terms. > I will appreciate it if you could let me know about your objections = to this > proposal: =09 [Pascal] It's cool that you do it is the first impression. =09 > Node A needs to reach a destination D. Node A initiates a discovery = DAG > towards D. As the DIOs reach D, it sends a DAO back to selected = parents. As > the DAO travels towards node A, in-route nodes store the cost to = reach D. > > When node B needs to reach D, it similarly initiates a discovery dag. = During > this discovery, when a DIO reaches a node C that maintains a cost to = reach D, > node C responds back with a DAO that travels towards B and stores in = in- > route nodes the cost to reach D. =09 [Pascal] understand that you're trying to make RPL even closer to = AODV. I agree we need to gather as much as we can from that work. =09 For the specifics of your proposal: =09 - B-C might be orthogonal to A-D so that B/C\D forms an angle. You do = not end up with the best path that you're looking for. =09 - there might be multiple C's. Which one is the right one? =09 - RPL does not allow packets to switch instances. Following multiple = DAGs is the recipe for loops - unless you have them strictly ordered by = some means like the RPL sequence between iterations, more specific = routes, blah blah...) =09 - the A to D path is optimized for a certain constraint. You seem to = imply that the B to D path has the same constraints and metrics so we = can compare apple to apple. Because this is a very delicate operation, = RPL has introduced the Rank, which has the right properties to make that = comparison efficiently.So for RPL, the loop avoidance metric is the = Rank, and it is only valid within an iteration. =09 - A P2P path does not come out of the blue. There must be some = provisionning system that determines that those nodes, A and B, are very = special so they need a P2P optimization, with a given special OF, and = that they both need to talk to D. Well, if that's so, the most = economical is for that system to fork the DAG out of D, with dual = targets A and B. There you obtain the shortest path for both A-D and B-D = for the cost of a single flooding. =09 I see that you're trying to get the idea to work better, and I hope we = find a way to do so, maybe along your lines if we can solve the issues = above. But before we get there, we need to agree that this is the path = we wish to take. =09 Cheers, =09 Pascal =09 =09 > > ----- Original Message ----- > From: "Pascal Thubert (pthubert)" > To: "robert cragie" > Cc: "ROLL WG" , "Ted Humpal" > Sent: Thursday, March 18, 2010 9:23:14 PM GMT -06:00 US/Canada = Central > Subject: Re: [Roll] P2P performance with current RPL proposal > > > > > > Hi Robert : > > > > At least from a distance, the proposed mechanism emulates AODV, with = the > DIO as RREQ and the DAO as RREP. So if we decide to dig along those = lines, > we'll certainly appreciate help from MANET experts. I'd say that if = you > already have RPL for P2MP and MP2P, the proposed extension are = probably > simpler to add than doing AODV from scratch. > > > > For the setup, the major differences are that we build a DAG and that = we can > indicate multiple targets. If you look at it, the DAG capability is a = MUST for > RPL, and I have not seen that this MUST goes away for P2P flows. The > multiple targets is something that appears in a number of use cases = and it > seems more economical to build a single DAG for multiple targets when > possible. > > > > For the maintenance, the major differences are that we have the DAG = as > first line of defense, and the RPL detection to stimulate the local = repair. > > > > About your questions: > > > > The DODAG root is the one that spawns the DAG. The targets can reach = the > root because the root advertises itself in the DIO. The idea is that = the root ID > is the address that the targets need to talk to. If needed, the root = can also > advertise a prefix that it can reach and that the targets need to = reach too. > > > > All the intermediate nodes that are confirmed by the DAO need to = retain at > least info about the DAG. That enables the targets to reach the root. = The > flooding should cost about the same as that of AODV but the RPL way = will > require more states in the nodes on the way if the OF requires a DAG. > > > > The way back (down) can be stateful of stateless, depending on which = DAO > we're using. With fully stateful DAO, we are really in AODV-land. = With > stateless, we could drift into DSR-land for that direction. Which = limits we > place to keep it simple will be determined by the resolution of issue = #26 I > guess... > > > > And please, no apologize or on one will dare post anything anymore. = Your > questions are fully relevant and at the core of the discussion. > > > > I hope we can talk in Anaheim for sure, > > > > > Pascal > > > > > > > From: Robert Cragie [ = mailto:robert.cragie@gridmerge.com] > Sent: Monday, March 15, 2010 11:27 AM > To: Pascal Thubert (pth ubert) > Cc: Ted.Humpal@jci.com; ROLL WG > Subject: Re: [Roll] P2P performance with current RPL proposal > > > > Hi Pascal, > > So in your slideware T can end up talking to R (DODAG root) through = the > DODAG. So are you proposing that all potential targets can act as a = DODAG > root? And therefore all intermediates have to retain DIO propagation > support for that DODAG as well? This may work for limited P2P but = seems > less efficient than simple distance vector flooding RREQ/RREP like = AODV or > DYMO for generic P2P. What about R to T (or anyone else for that = matter)? > Do we source route, maintain state, some undefined hybrid of the two? > > I apologise if some of these questions have been answered in detail = in earlier > reflector posts but I have only recently started to concentrate my = efforts on > RPL and have 82 pages to wade through :-). I look forward to a = productive > session in Anaheim. > > Robert > > > Robert Cragie (Pacific Gas & Electric) > > Gridmerge Ltd. > 89 Greenfield Crescent, > Wakefield, WF4 4WA, UK > +44 (0) 1924 910888 > http://www.gridmerge.com = =20 > > > > Pascal Thubert (pthubert) wrote: > > HI Robert : > > > > I respectfully have to disagree. > > > > My understanding is that we are considering a limited set of P2P = pairs, for > which the specific path that we need to create might have to obey = specific > constraints. > > So it makes sense to use an on-demand technique, probably inspired by = the > MANET Reactive protocols. > > > > As it goes, those protocols usually use flooding for a node to locate = another. > Forking a DAG is just another flooding. It does not take a lot of = addition to the > existing DIO for a root to use RPL to build a DAG that contains one = or multiple > Targets as leaves, under a set of constraints expressed as an = objective > function. Please find attached a slideware that illustrates that. > > > > > Pascal > > > > > > > From: roll-bounces@ietf.org [ = mailto:roll-bounces@ietf.org ] On Behalf Of > Robert Cragie > Sent: Thursday, March 11, 2010 2:43 PM > To: Ted.Humpal@jci.com > Cc: ROLL WG > Subject: Re: [Roll] P2P performance with current RPL proposal > > > > I agree with Ted's comments below. Creating a DODAG for every = reachable > node as a root seems a very inefficient approach compared to = alternative > routing algorithms. I am concerned that RPL does not actually meet = the > original requirements in I-D.ietf-roll-building-routing-reqs, = I-D.ietf-roll-home- > routing-reqs, RFC5673 and RFC5548. The traffic pattern requirement = for a > sink node features prominently in only two of those documents. Even = in this > case, as Ted points out, communication is likely to be bidirectional = (e.g. end- > to-end acks.) therefore the DODAG approach is fundamentally = asymmetric, > especially if no intermediate storage is allowed for destination = routes and > source routing has to be used. > > Also, RPL seems highly complex for what are constrained nodes in = terms of > memory as well as power and bandwidth. The RPL draft as it stands is = 82 > pages long and that doesn't include text about the objective = function. > > Robert > > > Robert Cragie (Pacific Gas & Electric) > > Gridmerge Ltd. > 89 Greenfield Crescent, > Wakefield, WF4 4WA, UK > +44 (0) 1924 910888 > http://www.gridmerge.com = =20 > > > > Ted.Humpal@jci.com wrote: > > > A concern also will be how much overhead (memory space) will be = required > for a DODAG Root? > > and based on the first question how many DODAG roots a lamp may need = to > be a member of? > > For example in lighting a single lamp may be a root for a single = switch (1 > DODAG root), this lamp / luminaire may also > be a member of another group - - which could be all lights on the = floor (2nd > DODAG root), and a third group > of all the lights in the building. There can be many more speciality = groups > associated based on the building configuration. > Consider also during the installation time - how these DODAG roots = will be > configured? Must I commission each device > to tell it which DODAG it must use for its Object Function? How easy = will this > be to change and add in a new DODAG root > for the end user if the lighting group changes?? > > With respect to Jerry Martocci's - commercial building requirements - = every > device may need to communicate to any or > all of the end devices. If each device must establish a DODAG for = the other > 499 devices in a 500 node network - How much memory > space will this require for each end device to maintain? > > Keep in mind that the end devices are very limited processor and = memory > wise. > > Not to mention all of the network maintenance messages that would = need > to be transmitted to maintain all of these DODAGs. > > Consider the reconvergence time when one device is turned off and it = was in > the middle of the majority of the 100+ DODAGS? > > In many lighting and building application an application = acknowledgement - > must be returned {Back down the DODAG} so . . . the > requirement is not just getting to the Root - a return path must also = be > maintained and have a low latency path. > > Ted Humpal > > > > > > > From: > > Kris Pister > > > To: > > Anders Brandt > > > Cc: > > ROLL WG > > > Date: > > 03/08/2010 01:45 PM > > > Subject: > > Re: [Roll] P2P performance with current RPL proposal > > > > > > > > > Anders - if we take JP's suggestion to make The Lamp a DODAG root, = and > take Phoebus' recommendation that we use path diversity to improve = end- > to-end reliability, do you see a chance of success? > In my experience, with diverse paths and order-minutes updates you = get > extremely high reliability. > > I have no aversion to TTL-limited floods as a part of a solution = either. I'm > open to ideas on how to bring those in as (presumably infrequently = used) > options. > > ksjp > > Anders Brandt wrote: > Hello > > I would like to probe the temperature of the WG on using DAOs to > support P2P. > > The building and home application spaces (and maybe others) have > a few clearly defined requirements. > It is not obvious to me how the current RPL proposal (cRPLp) can > satisfy those requirements: > > > In both cases it is the worst case scenario that hurts: > > > P2P routing inside the PAN > = =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 > cRPLp has no way of routing inside the PAN if you need more than > one repeater. cRPLp has to go all the way to the top (maybe 4 hops = up) > and down again (maybe 4 hops down) to get just 2 hops to the side. > > The consequence is high latency and high levels of background noise > for nodes just outside the direct radio range. > At the same time the risk of meeting a failing link is 4 times higher = =3D> > latency may be much more than 4 times larger. > > Latency may sound like a minor issue but it actually translates = directly > into lower battery lifetime. In the above (very realistic) example, > the battery lifetime is reduced to 25% of what it should be. > > We have lots of battery devices sending into the network: > * PIR sensors turning on lights > * Door locks sending alarms > * Door/window sensors starting chimes > * Smoke sensors triggering an alarm system > > > > > Response time > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > The latency issue is important. > When a user (real human being) presses a light button the user = expects > the light to turn on. > cRPLp proposes that nodes in the tree periodically advertises their > presence using DAOs. > The periodicity is a real beast: > Thanks to Trickle, the rate of updates in a (apparently) stable = network > is low. This is good since it leaves bandwidth for data. > But it is not good if existing routes to my lamp fail and I do not = get > new routes to my lamp until it decides to send out a new DAO. > My user will (with a good reason) not tolerate waiting for minutes = for > the light to turn on. > > I have met two arguments to counter this concern: > > A1: Well, your lamp can always send a DAO when it detects a problem. > My answer: > True, except that my lamp does not intend to send anything > so it will never experience any problems from its side of the = network. > > A2: Well, you can increase the DAO rate to sub-second updates. > My answer: > Oh no. I get a very high degree of management traffic which > limits my available bandwidth, increases the risk of collisions and > even run the risk of violating EU legislation requiring me to only > transmit in less than 1% of the time: > = http://focus.ti.com/lit/an/swra048/swra048.pdf > 868 - 868.6 MHz: <1% > > Reactiveness is hard to achieve via polling. > > > > If you agree that this seems to be critical issues please raise your > voice on the list. > > Going forward > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > We need some reactive mechanism to reach lamps before the user = decides > to sue our companies. > So is this possible? I think so. > > Existing commercial (non-IP) solutions are capable of re-routing = quickly > if they really have to. > > Let me try scoping the requirements to a potential solution: > (no different from the req. docs for home and building) > > * P2P routing in any direction independent of the tree. > > * On-demand P2P route discovery if requested by a real-time critical = app. > Data collection apps may be able to just wait for the next DAO = update. > > * Limited range of discovery mechanism: max 4 repeaters. > A TTL field may limit the scope of the repeaters. > > * Suboptimal routing and traffic bursts are accepted in exchange > for quick route repair. But only as an exception. > > > Just as an example, one existing home control technology uses a > (source routing) variant of AODV for quick route repair. > Nothing comes for free. The price is flooding - but not just = flooding: > Managed flooding using a distributed algorithm running in all > participating nodes. > The algorithm dampens the flooding in a time, volume and range > perspective. > Some similar mechanism could be built into RPL for quick route = repair. > > > If anyone have alternative proposals, please bring it to the list. > Now is the time. > > > > Thanks, > Anders > > > > > _______________________________________________ > Roll mailing 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 =09 ------_=_NextPart_001_01CAC9DD.15338D9E Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =0A= =0A= =0A= =0A=
=0A=
Well, = yes.
=0A=
 
=0A=
But it needs to be seen in = the right context:
=0A=
I really need to get my lamp = turned on within seconds when my users press the button.
=0A=
Even if this meens that I get = a less-than-optimal route.
=0A=
 
=0A=
The intention is not to skip = all the nice DODAG DIO work that was done. It serves a good = purpose
=0A=
in large = networks.
=0A=
The case is just that home = & building have some tougher requirements within restricted areas = (<=3D 4 repeaters)
such as battery-friendly (i.e. short routes) = and reactive discovery to "guarantee" low response times = always.
=0A=
 
=0A=
The challenge is to get this = for free.
=0A=
 
=0A=
- Anders
=0A=

=0A=
=0A= Fra: Philip Levis = [mailto:pal@cs.stanford.edu]
Sendt: ma 22-03-2010 = 10:20
Til: d.sturek@att.net
Cc: Anders Brandt; Mukul = Goyal; Pascal Thubert (pthubert); ROLL WG; Ted Humpal
Emne: = Re: [Roll] P2P performance with current RPL proposal

=0A=
=0A=
Just to be sure I am hearing this right -the proposal is to use = hopcount-based route selection?
=0A=

=0A=
Phil
=0A=

On Mar 22, 2010, at 7:52 AM, "Don Sturek" <d.sturek@att.net> = wrote:

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

Hi = Anders and Mukul,

=0A=

 

=0A=

This is all sounding quite promising in addressing P2P routing in = RPL.  How can we organize a specific proposal we can gain WG = approval for?  I would like to leave Anaheim with an agreed path = towards P2P routing support we all believe addresses the Home Automation = and Building Controls use cases.

=0A=

 

=0A=

Don

=0A=

 

=0A=

 

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

From: roll-bounces@ietf.org = [mailto:roll-bounces@ietf.org] On Behalf Of Anders = Brandt
Sent: Monday, March 22, 2010 7:46 AM
To: = Mukul Goyal; Pascal Thubert (pthubert)
Cc: ROLL WG; Ted = Humpal
Subject: Re: [Roll] P2P performance with current RPL = proposal

=0A=

 

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

Add = to this an element of promiscuos listening to dampen the storm =3D> = if node already detected a copy of the DIS with the same TTL (or lower) = - do not forward the DIS. Then you start getting closer to = something.

=0A=
=0A=

 

=0A=
=0A=

Oh - and by the way = - record the source route on the way ;-)

=0A=
=0A=

 

=0A=
=0A=

- = Anders

=0A=
=0A=

 

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

Fra: roll-bounces@ietf.org p=E5 = vegne af Mukul Goyal
Sendt: ma 22-03-2010 01:47
Til: = Pascal Thubert (pthubert)
Cc: ROLL WG; Ted = Humpal
Emne: Re: [Roll] P2P performance with current RPL = proposal

=0A=
=0A=

Hi Pascal

Thanks for your = comments (let me send my response in the next email).

Based on = further thoughts, it seems to me that a DAG based P2P solution would = work if we do the following:

(a) allowing multicast DIS messages = to spread to an originator-specified number of hops and
(b) allowing = nodes to join a DAG temporarily and leave it if there is not sufficient = “routing interest” in being part of the DAG.

With = these points in mind, a P2P scheme could work as follows:

1. When = a node wants to join a DODAG(D,F), where D is the DODAG's root and F is = the OF being used, it does the following:
    a. = Initiates a discovery table entry for DODAG(D,F). The discovery table = entries are removed after a certain lifetime.
    b. = sends out a DIS via link-local multicast asking specifically for = information about DODAG(D,F). It also lists in the DIS the number of = hops the DIS can travel.

2. On receiving  a DIS, a node does = the following:
    a.if it does not know about = DODAG(D,F) and the DIS hop limit is not yet = reached
        i. Initiates a = discovery table entry for DODAG(D,F). This entry maintains information = about the nodes from whom the DIS were = received.
        ii. sends out = the DIS (via link-local multicast with trickle controlled timing) = further.
    b. If it is already a part of DODAG(D,F) = or is node D itself
        i. = Send out a DIO about DODAG(D,F) to the node from whom the DIS was = received.

3. On receiving a DIO about DODAG(D,F), a node does the = following:
    a. Ignore the DIO if the node does not = have a discovery table entry for DODAG(D,F)
    b. = Otherwise, the node joins the DODAG(D,F) (if not already part of it) or = updates its parent set in DODAG(D,F) and sends the DIO by unicast to the = nodes that had sent it the DIS.

4. Once, the node is part of the = DODAG(D,F), it maintains a “routing interest” for the DODAG = in the following manner:
    a. Routing interest is a = value between 0 and 1
    b. Routing interest is 1 if = the node recently forwarded a packet along the = DODAG(D,F)
    c. Otherwise, the routing interest is = x*maximum routing interest of the neighbors in DODAG(D,F), where x is a = fraction. The node comes to know of neighbor’s routing interest = via the neighbor’s DIO.
    d. A node leaves a = DODAG if its routing interest in the DODAG goes below a = threshold.

Thanks
Mukul

----- Original Message = -----
From: "Pascal Thubert (pthubert)" <pthubert@cisco.com>
To: = "Mukul Goyal" <mukul@uwm.edu>
Cc: "ROLL WG" = <roll@ietf.org>, "Ted Humpal" = <Ted.Humpal@jci.com>, = "robert cragie" <robert.cragie@gridmerge.com>
Sent: Friday, March 19, 2010 11:20:58 AM GMT -06:00 US/Canada = Central
Subject: RE: [Roll] P2P performance with current RPL = proposal

Hi Mukul
> Here I have attempted to formulate a = simple DV algorithm in RPL/DAG terms.
> I will appreciate it if = you could let me know about your objections to this
> = proposal:

[Pascal] It's cool that you do it is the first = impression.

> Node A needs to reach a destination D. Node A = initiates a discovery DAG
> towards D. As the DIOs reach D, it = sends a DAO back to selected parents. As
> the DAO travels towards = node A, in-route nodes store the cost to reach D.
>
> When = node B needs to reach D, it similarly initiates a discovery dag. = During
> this discovery, when a DIO reaches a node C that = maintains a cost to reach D,
> node C responds back with a DAO = that travels towards B and stores in in-
> route nodes the cost to = reach D.

[Pascal]  understand that you're trying to make RPL = even closer to AODV.
I agree we need to gather as much as we can from = that work.

For the specifics of your proposal:

- B-C might = be orthogonal to A-D so that B/C\D forms an angle. You do not end up = with the best path that you're looking for.

- there might be = multiple C's. Which one is the right one?

- RPL does not allow = packets to switch instances. Following multiple DAGs is the recipe for = loops - unless you have them strictly ordered by some means like the RPL = sequence between iterations, more specific routes, blah = blah...)

- the A to D path is optimized for a certain constraint. = You seem to imply that the B to D path has the same constraints and = metrics so we can compare apple to apple. Because this is a very = delicate operation, RPL has introduced the Rank, which has the right = properties to make that comparison efficiently.So for RPL, the loop = avoidance metric is the Rank, and it is only valid within an = iteration.

- A P2P path does not come out of the blue. There must = be some provisionning system that determines that those nodes, A and B, = are very special so they need a P2P optimization, with a given special = OF, and that they both need to talk to D. Well, if that's so, the most = economical is for that system to fork the DAG out of D, with dual = targets A and B. There you obtain the shortest path for both A-D and B-D = for the cost of a single flooding.

I see that you're trying to = get the idea to work better, and I hope we find a way to do so, maybe = along your lines if we can solve the issues above. But before we get = there, we need to agree that this is the path we wish to = take.

Cheers,

Pascal


>
> ----- = Original Message -----
> From: "Pascal Thubert (pthubert)" <pthubert@cisco.com>
> = To: "robert cragie" <robert.cragie@gridmerge.com>
> Cc: "ROLL WG" <roll@ietf.org>, "Ted Humpal" <Ted.Humpal@jci.com>
> = Sent: Thursday, March 18, 2010 9:23:14 PM GMT -06:00 US/Canada = Central
> Subject: Re: [Roll] P2P performance with current RPL = proposal
>
>
>
>
>
> Hi = Robert :
>
>
>
> At least from a distance, = the proposed mechanism emulates AODV, with the
> DIO as RREQ and = the DAO as RREP. So if we decide to dig along those lines,
> = we’ll certainly appreciate help from MANET experts. I’d say = that if you
> already have RPL for P2MP and MP2P, the proposed = extension are probably
> simpler to add than doing AODV from = scratch.
>
>
>
> For the setup, the major = differences are that we build a DAG and that we can
> indicate = multiple targets. If you look at it, the DAG capability is a MUST = for
> RPL, and I have not seen that this MUST goes away for P2P = flows. The
> multiple targets is something that appears in a = number of use cases and it
> seems more economical to build a = single DAG for multiple targets when
> = possible.
>
>
>
> For the maintenance, the major = differences are that we have the DAG as
> first line of defense, = and the RPL detection to stimulate the local = repair.
>
>
>
> About your = questions:
>
>
>
> The DODAG root is the one = that spawns the DAG. The targets can reach the
> root because the = root advertises itself in the DIO. The idea is that the root ID
> = is the address that the targets need to talk to. If needed, the root can = also
> advertise a prefix that it can reach and that the targets = need to reach too.
>
>
>
> All the intermediate = nodes that are confirmed by the DAO need to retain at
> least info = about the DAG. That enables the targets to reach the root. The
> = flooding should cost about the same as that of AODV but the RPL way = will
> require more states in the nodes on the way if the OF = requires a DAG.
>
>
>
> The way back (down) can = be stateful of stateless, depending on which DAO
> we’re = using. With fully stateful DAO, we are really in AODV-land. With
> = stateless, we could drift into DSR-land for that direction. Which limits = we
> place to keep it simple will be determined by the resolution = of issue #26 I
> guess…
>
>
>
> And = please, no apologize or on one will dare post anything anymore. = Your
> questions are fully relevant and at the core of the = discussion.
>
>
>
> I hope we can talk in = Anaheim for sure,
>
>
>
>
> = Pascal
>
>
>
>
>
>
> From: = Robert Cragie [mailto:robert.cragie@gridmerg= e.com]
> Sent: Monday, March 15, 2010 11:27 AM
> To: = Pascal Thubert (pth ubert)
> Cc: Ted.Humpal@jci.com; ROLL = WG
> Subject: Re: [Roll] P2P performance with current RPL = proposal
>
>
>
> Hi Pascal,
>
> So = in your slideware T can end up talking to R (DODAG root) through = the
> DODAG. So are you proposing that all potential targets can = act as a DODAG
> root? And therefore all intermediates have to = retain DIO propagation
> support for that DODAG as well? This may = work for limited P2P but seems
> less efficient than simple = distance vector flooding RREQ/RREP like AODV or
> DYMO for generic = P2P. What about R to T (or anyone else for that matter)?
> Do we = source route, maintain state, some undefined hybrid of the = two?
>
> I apologise if some of these questions have been = answered in detail in earlier
> reflector posts but I have only = recently started to concentrate my efforts on
> RPL and have 82 = pages to wade through :-). I look forward to a productive
> = session in Anaheim.
>
> Robert
>
>
> = Robert Cragie (Pacific Gas & Electric)
>
> Gridmerge = Ltd.
> 89 Greenfield Crescent,
> Wakefield, WF4 4WA, = UK
> +44 (0) 1924 910888
> http://www.gridmerge.com
&g= t;
>
>
> Pascal Thubert (pthubert) = wrote:
>
> HI Robert :
>
>
>
> = I respectfully have to disagree.
>
>
>
> My = understanding is that we are considering a limited set of P2P pairs, = for
> which the specific path that we need to create might have to = obey specific
> constraints.
>
> So it makes sense to = use an on-demand technique, probably inspired by the
> MANET = Reactive protocols.
>
>
>
> As it goes, those = protocols usually use flooding for a node to locate another.
> = Forking a DAG is just another flooding. It does not take a lot of = addition to the
> existing DIO for a root to use RPL to build a = DAG that contains one or multiple
> Targets as leaves, under a set = of constraints expressed as an objective
> function. Please find = attached a slideware that illustrates = that.
>
>
>
>
> = Pascal
>
>
>
>
>
>
> From: roll-bounces@ietf.org [ mailto:roll-bounces@ietf.org ] On Behalf Of
> Robert Cragie
> Sent: Thursday, March 11, = 2010 2:43 PM
> To: Ted.Humpal@jci.com
> = Cc: ROLL WG
> Subject: Re: [Roll] P2P performance with current RPL = proposal
>
>
>
> I agree with Ted's comments = below. Creating a DODAG for every reachable
> node as a root seems = a very inefficient approach compared to alternative
> routing = algorithms. I am concerned that RPL does not actually meet the
> = original requirements in I-D.ietf-roll-building-routing-reqs, = I-D.ietf-roll-home-
> routing-reqs, RFC5673 and RFC5548. The = traffic pattern requirement for a
> sink node features prominently = in only two of those documents. Even in this
> case, as Ted points = out, communication is likely to be bidirectional (e.g. end-
> = to-end acks.) therefore the DODAG approach is fundamentally = asymmetric,
> especially if no intermediate storage is allowed for = destination routes and
> source routing has to be = used.
>
> Also, RPL seems highly complex for what are = constrained nodes in terms of
> memory as well as power and = bandwidth. The RPL draft as it stands is 82
> pages long and that = doesn't include text about the objective function.
>
> = Robert
>
>
> Robert Cragie (Pacific Gas & = Electric)
>
> Gridmerge Ltd.
> 89 Greenfield = Crescent,
> Wakefield, WF4 4WA, UK
> +44 (0) 1924 = 910888
> http://www.gridmerge.com
&g= t;
>
>
> Ted.Humpal@jci.com = wrote:
>
>
> A concern also will be how much overhead = (memory space) will be required
> for a DODAG = Root?
>
> and based on the first question how many DODAG = roots a lamp may need to
> be a member of?
>
> For = example in lighting  a single lamp may be a root for a single = switch (1
> DODAG root),  this lamp / luminaire may = also
> be a member of another group - -  which could be all = lights on the floor (2nd
> DODAG root), and a third group
> = of all the lights in the building.  There can be many more = speciality groups
> associated based on the building = configuration.
> Consider also during the installation time - how = these DODAG roots will be
> configured?  Must I commission = each device
> to tell it which DODAG it must use for its Object = Function?  How easy will this
> be to change and add in a new = DODAG root
> for the end user if the lighting group = changes??
>
> With respect to Jerry Martocci's - commercial = building requirements - every
> device may need to communicate to = any or
> all of the end devices.  If each device must = establish a DODAG for the other
> 499 devices in a 500 node = network - How much memory
> space will this require for each end = device to maintain?
>
> Keep in mind that the end devices = are very limited processor and memory
> wise.
>
> Not = to mention all of the network maintenance messages that would = need
> to be transmitted to maintain all of these = DODAGs.
>
> Consider the reconvergence time when one device = is turned off and it was in
> the middle of the majority of the = 100+ DODAGS?
>
> In many lighting and building application = an application acknowledgement -
> must be returned {Back down the = DODAG} so . . . the
> requirement is not just getting to the Root = - a return path must also be
> maintained and have a  low = latency path.
>
> Ted = Humpal
>
>
>
>
>
>
> = From:
>
> Kris Pister <pister@eecs.berkeley.edu>=
>
>
> To:
>
> Anders Brandt <abr@sdesigns.dk>
>
>> Cc:
>
> ROLL WG <roll@ietf.org>
>
>
&g= t; Date:
>
> 03/08/2010 01:45 PM
>
>
> = Subject:
>
> Re: [Roll] P2P performance with current RPL = proposal
>
>
>
>
>
>
>
><= BR>> Anders - if we take JP's suggestion to make The Lamp a DODAG = root, and
> take Phoebus' recommendation that we use path = diversity to improve end-
> to-end reliability, do you see a = chance of success?
> In my experience, with diverse paths and = order-minutes updates you get
> extremely high = reliability.
>
> I have no aversion to TTL-limited floods as = a part of a solution either.  I'm
> open to ideas on how to = bring those in as (presumably infrequently used)
> = options.
>
> ksjp
>
> Anders Brandt = wrote:
> Hello
>
> I would like to probe the = temperature of the WG on using DAOs to
> support = P2P.
>
> The building and home application spaces (and maybe = others) have
> a few clearly defined requirements.
> It is = not obvious to me how the current RPL proposal (cRPLp) can
> = satisfy those requirements:
>
>
> In both cases it is = the worst case scenario that hurts:
>
>
> P2P routing = inside the PAN
> = =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
> cRPLp has no way of routing inside the PAN if you need more = than
> one repeater. cRPLp has to go all the way to the top (maybe = 4 hops up)
> and down again (maybe 4 hops down) to get just 2 hops = to the side.
>
> The consequence is high latency and high = levels of background noise
> for nodes just outside the direct = radio range.
> At the same time the risk of meeting a failing link = is 4 times higher =3D>
> latency may be much more than 4 times = larger.
>
> Latency may sound like a minor issue but it = actually translates directly
> into lower battery lifetime. In the = above (very realistic) example,
> the battery lifetime is reduced = to 25% of what it should be.
>
> We have lots of battery = devices sending into the network:
> * PIR sensors turning on = lights
> * Door locks sending alarms
> * Door/window sensors = starting chimes
> * Smoke sensors triggering an alarm = system
>
>
>
>
> Response time
> = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> The latency issue is = important.
> When a user (real human being) presses a light button = the user expects
> the light to turn on.
> cRPLp proposes = that nodes in the tree periodically advertises their
> presence = using DAOs.
> The periodicity is a real beast:
> Thanks to = Trickle, the rate of updates in a (apparently) stable network
> is = low. This is good since it leaves bandwidth for data.
> But it is = not good if existing routes to my lamp fail and I do not get
> new = routes to my lamp until it decides to send out a new DAO.
> My = user will (with a good reason) not tolerate waiting for minutes = for
> the light to turn on.
>
> I have met two = arguments to counter this concern:
>
> A1: Well, your lamp = can always send a DAO when it detects a problem.
>   My = answer:
>   True, except that my lamp does not intend to send = anything
>   so it will never experience any problems from = its side of the network.
>
> A2: Well, you can increase the = DAO rate to sub-second updates.
>   My answer:
>   = Oh no. I get a very high degree of management traffic which
> =   limits my available bandwidth, increases the risk of collisions = and
>   even run the risk of violating EU legislation = requiring me to only
>   transmit in less than 1% of the = time:
>   http://focus.ti.c= om/lit/an/swra048/swra048.pdf
>  868 - 868.6 MHz: = <1%
>
>   Reactiveness is hard to achieve via = polling.
>
>
>
> If you agree that this seems to = be critical issues please raise your
> voice on the = list.
>
> Going forward
> = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>
> We need some = reactive mechanism to reach lamps before the user decides
> to sue = our companies.
> So is this possible? I think so.
>
> = Existing commercial (non-IP) solutions are capable of re-routing = quickly
> if they really have to.
>
> Let me try = scoping the requirements to a potential solution:
> (no different = from the req. docs for home and building)
>
> * P2P routing = in any direction independent of the tree.
>
> * On-demand = P2P route discovery if requested by a real-time critical app.
> =  Data collection apps may be able to just wait for the next DAO = update.
>
> * Limited range of discovery mechanism: max 4 = repeaters.
>   A TTL field may limit the scope of the = repeaters.
>
> * Suboptimal routing and traffic bursts are = accepted in exchange
>   for quick route repair. But only as = an exception.
>
>
> Just as an example, one existing = home control technology uses a
> (source routing) variant of AODV = for quick route repair.
> Nothing comes for free. The price is = flooding - but not just flooding:
> Managed flooding using a = distributed algorithm running in all
> participating = nodes.
> The algorithm dampens the flooding in a time, volume and = range
> perspective.
> Some similar mechanism could be built = into RPL for quick route repair.
>
>
> If anyone have = alternative proposals, please bring it to the list.
> Now is the = time.
>
>
>
> Thanks,
>   = Anders
>
>
>
>
> = _______________________________________________
> Roll mailing = 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

=0A=
=0A=
_______________________________________________
Roll mailing list
Roll@ietf.org
https://www.ietf.org/= mailman/listinfo/roll
------_=_NextPart_001_01CAC9DD.15338D9E-- From d.sturek@att.net Mon Mar 22 09:35: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 73C963A681C for ; Mon, 22 Mar 2010 09:35:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.856 X-Spam-Level: ** X-Spam-Status: No, score=2.856 tagged_above=-999 required=5 tests=[AWL=-1.560, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_12=0.6, J_CHICKENPOX_17=0.6, J_CHICKENPOX_51=0.6, MANGLED_OFF=2.3, 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 jRa-KNu+JryQ for ; Mon, 22 Mar 2010 09:35:08 -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 A18CC3A68B2 for ; Mon, 22 Mar 2010 09:35:08 -0700 (PDT) Received: (qmail 12726 invoked from network); 22 Mar 2010 16:35:23 -0000 Received: from adsl-69-224-122-108.dsl.sndg02.pacbell.net (d.sturek@69.224.122.108 with login) by smtp126.sbc.mail.sp1.yahoo.com with SMTP; 22 Mar 2010 09:35:22 -0700 PDT X-Yahoo-SMTP: fvjol_aswBAraSJvMLe2r1XTzhBhbFxY8q8c3jo- X-YMail-OSG: r9G6b6oVM1mpDsYJbLeXbpe3HCyyjB40H6nxy7kA6YJBtFX8TjDwhWlXk1TS0qQvmaxmqVdQCHn3CAYpaIbiIP.weL2iBRjOcxoTP4oaHrBHwIi4NvPtAnGe3wro5ynIxlADzbH8AxzqDDVX9TdYaXygHvc_cIEjV4e92YpnONcbbWIAHblnDxIkqKS3lBI5m1O0B307pGxpQCupViMLvqrI1FWRd7c_Zh4Bw25inrhspEcaYka0psQv8gKtRho_uvmYteEkSrBy_w1f8t7UfsEXcQjqUMyeOTpL1GXaL1uUKaFReA-- X-Yahoo-Newman-Property: ymail-3 From: "Don Sturek" To: "'Anders Brandt'" , "'Philip Levis'" References: <1161577952.8138041269244020805.JavaMail.root@mail02.pantherlink.uwm.edu> <6D9687E95918C04A8B30A7D6DA805A3E01AD45CF@zensys17.zensys.local> <009b01cac9cf$51934660$f4b9d320$@sturek@att.net> <6D9687E95918C04A8B30A7D6DA805A3E01AD45D2@zensys17.zensys.local> In-Reply-To: <6D9687E95918C04A8B30A7D6DA805A3E01AD45D2@zensys17.zensys.local> Date: Mon, 22 Mar 2010 09:35:17 -0700 Message-ID: <012b01cac9dd$a8836820$f98a3860$@sturek@att.net> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_012C_01CAC9A2.FC249020" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcrJ27QCOcDu36d8SkWfPrOHLFLUZwAAKJZgAABEZCA= Content-Language: en-us Cc: 'ROLL WG' , 'Ted Humpal' Subject: Re: [Roll] P2P performance with current RPL proposal 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, 22 Mar 2010 16:35:26 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_012C_01CAC9A2.FC249020 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I would be interested in hearing Mukul=92s thoughts on this. I did not = read his proposal to say that hop count is the only metric. I would expect = the metric used for the DODAG(D,F) to be the OF =93F=94 (whatever that = happens to be for the DODAG). =20 Don =20 =20 From: Anders Brandt [mailto:abr@sdesigns.dk]=20 Sent: Monday, March 22, 2010 9:31 AM To: Philip Levis; d.sturek@att.net Cc: Mukul Goyal; Pascal Thubert (pthubert); ROLL WG; Ted Humpal Subject: SV: [Roll] P2P performance with current RPL proposal =20 Well, yes. =20 But it needs to be seen in the right context: I really need to get my lamp turned on within seconds when my users = press the button. Even if this meens that I get a less-than-optimal route. =20 The intention is not to skip all the nice DODAG DIO work that was done. = It serves a good purpose in large networks. The case is just that home & building have some tougher requirements = within restricted areas (<=3D 4 repeaters) such as battery-friendly (i.e. short routes) and reactive discovery to "guarantee" low response times always. =20 The challenge is to get this for free. =20 - Anders =20 _____ =20 Fra: Philip Levis [mailto:pal@cs.stanford.edu] Sendt: ma 22-03-2010 10:20 Til: d.sturek@att.net Cc: Anders Brandt; Mukul Goyal; Pascal Thubert (pthubert); ROLL WG; Ted Humpal Emne: Re: [Roll] P2P performance with current RPL proposal Just to be sure I am hearing this right -the proposal is to use hopcount-based route selection? =20 Phil On Mar 22, 2010, at 7:52 AM, "Don Sturek" wrote: Hi Anders and Mukul, =20 This is all sounding quite promising in addressing P2P routing in RPL. = How can we organize a specific proposal we can gain WG approval for? I = would like to leave Anaheim with an agreed path towards P2P routing support we = all believe addresses the Home Automation and Building Controls use cases. =20 Don =20 =20 From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Anders Brandt Sent: Monday, March 22, 2010 7:46 AM To: Mukul Goyal; Pascal Thubert (pthubert) Cc: ROLL WG; Ted Humpal Subject: Re: [Roll] P2P performance with current RPL proposal =20 Add to this an element of promiscuos listening to dampen the storm =3D> = if node already detected a copy of the DIS with the same TTL (or lower) - = do not forward the DIS. Then you start getting closer to something. =20 Oh - and by the way - record the source route on the way ;-) =20 - Anders =20 _____ =20 Fra: roll-bounces@ietf.org p=E5 vegne af Mukul Goyal Sendt: ma 22-03-2010 01:47 Til: Pascal Thubert (pthubert) Cc: ROLL WG; Ted Humpal Emne: Re: [Roll] P2P performance with current RPL proposal Hi Pascal Thanks for your comments (let me send my response in the next email). Based on further thoughts, it seems to me that a DAG based P2P solution would work if we do the following: (a) allowing multicast DIS messages to spread to an originator-specified number of hops and (b) allowing nodes to join a DAG temporarily and leave it if there is = not sufficient =93routing interest=94 in being part of the DAG. With these points in mind, a P2P scheme could work as follows: 1. When a node wants to join a DODAG(D,F), where D is the DODAG's root = and F is the OF being used, it does the following: a. Initiates a discovery table entry for DODAG(D,F). The discovery = table entries are removed after a certain lifetime. b. sends out a DIS via link-local multicast asking specifically for information about DODAG(D,F). It also lists in the DIS the number of = hops the DIS can travel. 2. On receiving a DIS, a node does the following: a.if it does not know about DODAG(D,F) and the DIS hop limit is not = yet reached i. Initiates a discovery table entry for DODAG(D,F). This entry maintains information about the nodes from whom the DIS were received. ii. sends out the DIS (via link-local multicast with trickle controlled timing) further. b. If it is already a part of DODAG(D,F) or is node D itself i. Send out a DIO about DODAG(D,F) to the node from whom the DIS = was received. 3. On receiving a DIO about DODAG(D,F), a node does the following: a. Ignore the DIO if the node does not have a discovery table entry = for DODAG(D,F) b. Otherwise, the node joins the DODAG(D,F) (if not already part of = it) or updates its parent set in DODAG(D,F) and sends the DIO by unicast to = the nodes that had sent it the DIS. 4. Once, the node is part of the DODAG(D,F), it maintains a =93routing interest=94 for the DODAG in the following manner: a. Routing interest is a value between 0 and 1 b. Routing interest is 1 if the node recently forwarded a packet = along the DODAG(D,F) c. Otherwise, the routing interest is x*maximum routing interest of = the neighbors in DODAG(D,F), where x is a fraction. The node comes to know = of neighbor=92s routing interest via the neighbor=92s DIO. d. A node leaves a DODAG if its routing interest in the DODAG goes = below a threshold. Thanks Mukul ----- Original Message ----- From: "Pascal Thubert (pthubert)" To: "Mukul Goyal" Cc: "ROLL WG" , "Ted Humpal" , = "robert cragie" Sent: Friday, March 19, 2010 11:20:58 AM GMT -06:00 US/Canada Central Subject: RE: [Roll] P2P performance with current RPL proposal Hi Mukul > Here I have attempted to formulate a simple DV algorithm in RPL/DAG = terms. > I will appreciate it if you could let me know about your objections to this > proposal: [Pascal] It's cool that you do it is the first impression. > Node A needs to reach a destination D. Node A initiates a discovery = DAG > towards D. As the DIOs reach D, it sends a DAO back to selected = parents. As > the DAO travels towards node A, in-route nodes store the cost to reach = D. > > When node B needs to reach D, it similarly initiates a discovery dag. During > this discovery, when a DIO reaches a node C that maintains a cost to = reach D, > node C responds back with a DAO that travels towards B and stores in = in- > route nodes the cost to reach D. [Pascal] understand that you're trying to make RPL even closer to AODV. I agree we need to gather as much as we can from that work. For the specifics of your proposal: - B-C might be orthogonal to A-D so that B/C\D forms an angle. You do = not end up with the best path that you're looking for. - there might be multiple C's. Which one is the right one? - RPL does not allow packets to switch instances. Following multiple = DAGs is the recipe for loops - unless you have them strictly ordered by some = means like the RPL sequence between iterations, more specific routes, blah blah...) - the A to D path is optimized for a certain constraint. You seem to = imply that the B to D path has the same constraints and metrics so we can = compare apple to apple. Because this is a very delicate operation, RPL has introduced the Rank, which has the right properties to make that = comparison efficiently.So for RPL, the loop avoidance metric is the Rank, and it is only valid within an iteration. - A P2P path does not come out of the blue. There must be some = provisionning system that determines that those nodes, A and B, are very special so = they need a P2P optimization, with a given special OF, and that they both = need to talk to D. Well, if that's so, the most economical is for that system to fork the DAG out of D, with dual targets A and B. There you obtain the shortest path for both A-D and B-D for the cost of a single flooding. I see that you're trying to get the idea to work better, and I hope we = find a way to do so, maybe along your lines if we can solve the issues above. = But before we get there, we need to agree that this is the path we wish to = take. Cheers, Pascal > > ----- Original Message ----- > From: "Pascal Thubert (pthubert)" > To: "robert cragie" > Cc: "ROLL WG" , "Ted Humpal" > Sent: Thursday, March 18, 2010 9:23:14 PM GMT -06:00 US/Canada Central > Subject: Re: [Roll] P2P performance with current RPL proposal > > > > > > Hi Robert : > > > > At least from a distance, the proposed mechanism emulates AODV, with = the > DIO as RREQ and the DAO as RREP. So if we decide to dig along those = lines, > we=92ll certainly appreciate help from MANET experts. I=92d say that = if you > already have RPL for P2MP and MP2P, the proposed extension are = probably > simpler to add than doing AODV from scratch. > > > > For the setup, the major differences are that we build a DAG and that = we can > indicate multiple targets. If you look at it, the DAG capability is a = MUST for > RPL, and I have not seen that this MUST goes away for P2P flows. The > multiple targets is something that appears in a number of use cases = and it > seems more economical to build a single DAG for multiple targets when > possible. > > > > For the maintenance, the major differences are that we have the DAG as > first line of defense, and the RPL detection to stimulate the local repair. > > > > About your questions: > > > > The DODAG root is the one that spawns the DAG. The targets can reach = the > root because the root advertises itself in the DIO. The idea is that = the root ID > is the address that the targets need to talk to. If needed, the root = can also > advertise a prefix that it can reach and that the targets need to = reach too. > > > > All the intermediate nodes that are confirmed by the DAO need to = retain at > least info about the DAG. That enables the targets to reach the root. = The > flooding should cost about the same as that of AODV but the RPL way = will > require more states in the nodes on the way if the OF requires a DAG. > > > > The way back (down) can be stateful of stateless, depending on which = DAO > we=92re using. With fully stateful DAO, we are really in AODV-land. = With > stateless, we could drift into DSR-land for that direction. Which = limits we > place to keep it simple will be determined by the resolution of issue = #26 I > guess=85 > > > > And please, no apologize or on one will dare post anything anymore. = Your > questions are fully relevant and at the core of the discussion. > > > > I hope we can talk in Anaheim for sure, > > > > > Pascal > > > > > > > From: Robert Cragie [mailto:robert.cragie@gridmerge.com] > Sent: Monday, March 15, 2010 11:27 AM > To: Pascal Thubert (pth ubert) > Cc: Ted.Humpal@jci.com; ROLL WG > Subject: Re: [Roll] P2P performance with current RPL proposal > > > > Hi Pascal, > > So in your slideware T can end up talking to R (DODAG root) through = the > DODAG. So are you proposing that all potential targets can act as a = DODAG > root? And therefore all intermediates have to retain DIO propagation > support for that DODAG as well? This may work for limited P2P but = seems > less efficient than simple distance vector flooding RREQ/RREP like = AODV or > DYMO for generic P2P. What about R to T (or anyone else for that = matter)? > Do we source route, maintain state, some undefined hybrid of the two? > > I apologise if some of these questions have been answered in detail in earlier > reflector posts but I have only recently started to concentrate my = efforts on > RPL and have 82 pages to wade through :-). I look forward to a = productive > session in Anaheim. > > Robert > > > Robert Cragie (Pacific Gas & Electric) > > Gridmerge Ltd. > 89 Greenfield Crescent, > Wakefield, WF4 4WA, UK > +44 (0) 1924 910888 > http://www.gridmerge.com =20 > > > > Pascal Thubert (pthubert) wrote: > > HI Robert : > > > > I respectfully have to disagree. > > > > My understanding is that we are considering a limited set of P2P = pairs, for > which the specific path that we need to create might have to obey = specific > constraints. > > So it makes sense to use an on-demand technique, probably inspired by = the > MANET Reactive protocols. > > > > As it goes, those protocols usually use flooding for a node to locate another. > Forking a DAG is just another flooding. It does not take a lot of = addition to the > existing DIO for a root to use RPL to build a DAG that contains one or multiple > Targets as leaves, under a set of constraints expressed as an = objective > function. Please find attached a slideware that illustrates that. > > > > > Pascal > > > > > > > From: roll-bounces@ietf.org [ mailto:roll-bounces@ietf.org ] On Behalf = Of > Robert Cragie > Sent: Thursday, March 11, 2010 2:43 PM > To: Ted.Humpal@jci.com > Cc: ROLL WG > Subject: Re: [Roll] P2P performance with current RPL proposal > > > > I agree with Ted's comments below. Creating a DODAG for every = reachable > node as a root seems a very inefficient approach compared to = alternative > routing algorithms. I am concerned that RPL does not actually meet the > original requirements in I-D.ietf-roll-building-routing-reqs, I-D.ietf-roll-home- > routing-reqs, RFC5673 and RFC5548. The traffic pattern requirement for = a > sink node features prominently in only two of those documents. Even in this > case, as Ted points out, communication is likely to be bidirectional = (e.g. end- > to-end acks.) therefore the DODAG approach is fundamentally = asymmetric, > especially if no intermediate storage is allowed for destination = routes and > source routing has to be used. > > Also, RPL seems highly complex for what are constrained nodes in terms = of > memory as well as power and bandwidth. The RPL draft as it stands is = 82 > pages long and that doesn't include text about the objective function. > > Robert > > > Robert Cragie (Pacific Gas & Electric) > > Gridmerge Ltd. > 89 Greenfield Crescent, > Wakefield, WF4 4WA, UK > +44 (0) 1924 910888 > http://www.gridmerge.com =20 > > > > Ted.Humpal@jci.com wrote: > > > A concern also will be how much overhead (memory space) will be = required > for a DODAG Root? > > and based on the first question how many DODAG roots a lamp may need = to > be a member of? > > For example in lighting a single lamp may be a root for a single = switch (1 > DODAG root), this lamp / luminaire may also > be a member of another group - - which could be all lights on the = floor (2nd > DODAG root), and a third group > of all the lights in the building. There can be many more speciality groups > associated based on the building configuration. > Consider also during the installation time - how these DODAG roots = will be > configured? Must I commission each device > to tell it which DODAG it must use for its Object Function? How easy = will this > be to change and add in a new DODAG root > for the end user if the lighting group changes?? > > With respect to Jerry Martocci's - commercial building requirements - every > device may need to communicate to any or > all of the end devices. If each device must establish a DODAG for the other > 499 devices in a 500 node network - How much memory > space will this require for each end device to maintain? > > Keep in mind that the end devices are very limited processor and = memory > wise. > > Not to mention all of the network maintenance messages that would need > to be transmitted to maintain all of these DODAGs. > > Consider the reconvergence time when one device is turned off and it = was in > the middle of the majority of the 100+ DODAGS? > > In many lighting and building application an application = acknowledgement - > must be returned {Back down the DODAG} so . . . the > requirement is not just getting to the Root - a return path must also = be > maintained and have a low latency path. > > Ted Humpal > > > > > > > From: > > Kris Pister > > > To: > > Anders Brandt > > > Cc: > > ROLL WG > > > Date: > > 03/08/2010 01:45 PM > > > Subject: > > Re: [Roll] P2P performance with current RPL proposal > > > > > > > > > Anders - if we take JP's suggestion to make The Lamp a DODAG root, and > take Phoebus' recommendation that we use path diversity to improve = end- > to-end reliability, do you see a chance of success? > In my experience, with diverse paths and order-minutes updates you get > extremely high reliability. > > I have no aversion to TTL-limited floods as a part of a solution = either. I'm > open to ideas on how to bring those in as (presumably infrequently = used) > options. > > ksjp > > Anders Brandt wrote: > Hello > > I would like to probe the temperature of the WG on using DAOs to > support P2P. > > The building and home application spaces (and maybe others) have > a few clearly defined requirements. > It is not obvious to me how the current RPL proposal (cRPLp) can > satisfy those requirements: > > > In both cases it is the worst case scenario that hurts: > > > P2P routing inside the PAN > = =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 > cRPLp has no way of routing inside the PAN if you need more than > one repeater. cRPLp has to go all the way to the top (maybe 4 hops up) > and down again (maybe 4 hops down) to get just 2 hops to the side. > > The consequence is high latency and high levels of background noise > for nodes just outside the direct radio range. > At the same time the risk of meeting a failing link is 4 times higher = =3D> > latency may be much more than 4 times larger. > > Latency may sound like a minor issue but it actually translates = directly > into lower battery lifetime. In the above (very realistic) example, > the battery lifetime is reduced to 25% of what it should be. > > We have lots of battery devices sending into the network: > * PIR sensors turning on lights > * Door locks sending alarms > * Door/window sensors starting chimes > * Smoke sensors triggering an alarm system > > > > > Response time > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > The latency issue is important. > When a user (real human being) presses a light button the user expects > the light to turn on. > cRPLp proposes that nodes in the tree periodically advertises their > presence using DAOs. > The periodicity is a real beast: > Thanks to Trickle, the rate of updates in a (apparently) stable = network > is low. This is good since it leaves bandwidth for data. > But it is not good if existing routes to my lamp fail and I do not get > new routes to my lamp until it decides to send out a new DAO. > My user will (with a good reason) not tolerate waiting for minutes for > the light to turn on. > > I have met two arguments to counter this concern: > > A1: Well, your lamp can always send a DAO when it detects a problem. > My answer: > True, except that my lamp does not intend to send anything > so it will never experience any problems from its side of the = network. > > A2: Well, you can increase the DAO rate to sub-second updates. > My answer: > Oh no. I get a very high degree of management traffic which > limits my available bandwidth, increases the risk of collisions and > even run the risk of violating EU legislation requiring me to only > transmit in less than 1% of the time: > http://focus.ti.com/lit/an/swra048/swra048.pdf > 868 - 868.6 MHz: <1% > > Reactiveness is hard to achieve via polling. > > > > If you agree that this seems to be critical issues please raise your > voice on the list. > > Going forward > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > We need some reactive mechanism to reach lamps before the user decides > to sue our companies. > So is this possible? I think so. > > Existing commercial (non-IP) solutions are capable of re-routing = quickly > if they really have to. > > Let me try scoping the requirements to a potential solution: > (no different from the req. docs for home and building) > > * P2P routing in any direction independent of the tree. > > * On-demand P2P route discovery if requested by a real-time critical = app. > Data collection apps may be able to just wait for the next DAO = update. > > * Limited range of discovery mechanism: max 4 repeaters. > A TTL field may limit the scope of the repeaters. > > * Suboptimal routing and traffic bursts are accepted in exchange > for quick route repair. But only as an exception. > > > Just as an example, one existing home control technology uses a > (source routing) variant of AODV for quick route repair. > Nothing comes for free. The price is flooding - but not just flooding: > Managed flooding using a distributed algorithm running in all > participating nodes. > The algorithm dampens the flooding in a time, volume and range > perspective. > Some similar mechanism could be built into RPL for quick route repair. > > > If anyone have alternative proposals, please bring it to the list. > Now is the time. > > > > Thanks, > Anders > > > > > _______________________________________________ > Roll mailing 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 ------=_NextPart_000_012C_01CAC9A2.FC249020 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

I would be interested in hearing Mukul’s thoughts = on this.=A0 I did not read his proposal to say that hop count is the only = metric.=A0=A0 I would expect the metric used for the DODAG(D,F) to be the OF “F” (whatever that happens to be for the = DODAG).

 

Don

 

 

From:= Anders = Brandt [mailto:abr@sdesigns.dk]
Sent: Monday, March 22, 2010 9:31 AM
To: Philip Levis; d.sturek@att.net
Cc: Mukul Goyal; Pascal Thubert (pthubert); ROLL WG; Ted = Humpal
Subject: SV: [Roll] P2P performance with current RPL = proposal

 

Well, yes.

 

But it needs to be seen in the right context:

I really need to get my lamp turned on within seconds when my users press = the button.

Even if this meens that I get a less-than-optimal = route.

 

The intention is not to skip all the nice DODAG DIO work that was done. It = serves a good purpose

in large networks.

The case is just that home & building have some tougher requirements = within restricted areas (<=3D 4 repeaters)
such as battery-friendly (i.e. short routes) and reactive discovery to = "guarantee" low response times always.

 

The challenge is to get this for free.

 

- Anders

 

Fra: Philip Levis = [mailto:pal@cs.stanford.edu]
Sendt: ma 22-03-2010 10:20
Til: d.sturek@att.net
Cc: Anders Brandt; Mukul Goyal; Pascal Thubert (pthubert); ROLL = WG; Ted Humpal
Emne: Re: [Roll] P2P performance with current RPL = proposal

Just to be sure I am hearing this right -the = proposal is to use hopcount-based route selection?

 

Phil


On Mar 22, 2010, at 7:52 AM, "Don Sturek" <d.sturek@att.net> = wrote:

Hi Anders and = Mukul,

 <= /o:p>

This is all sounding quite = promising in addressing P2P routing in RPL.  How can we organize a specific = proposal we can gain WG approval for?  I would like to leave Anaheim with an = agreed path towards P2P routing support we all believe addresses the Home = Automation and Building Controls use cases.

 <= /o:p>

Don

 <= /o:p>

 <= /o:p>

From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Anders Brandt
Sent: Monday, March 22, 2010 7:46 AM
To: Mukul Goyal; Pascal Thubert (pthubert)
Cc: ROLL WG; Ted Humpal
Subject: Re: [Roll] P2P performance with current RPL = proposal

 <= /o:p>

Add to this an element of = promiscuos listening to dampen the storm =3D> if node already detected a copy of = the DIS with the same TTL (or lower) - do not forward the DIS. Then you start = getting closer to something.

 <= /o:p>

Oh - and by the way - record the source route = on the way ;-)

 <= /o:p>

- Anders

 <= /o:p>

Fra: roll-bounces@ietf.org p=E5 = vegne af Mukul Goyal
Sendt: ma 22-03-2010 01:47
Til: Pascal Thubert (pthubert)
Cc: ROLL WG; Ted Humpal
Emne: Re: [Roll] P2P performance with current RPL = proposal

Hi Pascal

Thanks for your comments (let me send my response in the next = email).

Based on further thoughts, it seems to me that a DAG based P2P solution = would work if we do the following:

(a) allowing multicast DIS messages to spread to an originator-specified = number of hops and
(b) allowing nodes to join a DAG temporarily and leave it if there is = not sufficient “routing interest” in being part of the DAG.

With these points in mind, a P2P scheme could work as follows:

1. When a node wants to join a DODAG(D,F), where D is the DODAG's root = and F is the OF being used, it does the following:
    a. Initiates a discovery table entry for DODAG(D,F). = The discovery table entries are removed after a certain lifetime.
    b. sends out a DIS via link-local multicast asking specifically for information about DODAG(D,F). It also lists in the DIS = the number of hops the DIS can travel.

2. On receiving  a DIS, a node does the following:
    a.if it does not know about DODAG(D,F) and the DIS = hop limit is not yet reached
        i. Initiates a discovery = table entry for DODAG(D,F). This entry maintains information about the nodes from = whom the DIS were received.
        ii. sends out the DIS (via link-local multicast with trickle controlled timing) further.
    b. If it is already a part of DODAG(D,F) or is node D = itself
        i. Send out a DIO about = DODAG(D,F) to the node from whom the DIS was received.

3. On receiving a DIO about DODAG(D,F), a node does the following:
    a. Ignore the DIO if the node does not have a = discovery table entry for DODAG(D,F)
    b. Otherwise, the node joins the DODAG(D,F) (if not = already part of it) or updates its parent set in DODAG(D,F) and sends the DIO by = unicast to the nodes that had sent it the DIS.

4. Once, the node is part of the DODAG(D,F), it maintains a = “routing interest” for the DODAG in the following manner:
    a. Routing interest is a value between 0 and 1
    b. Routing interest is 1 if the node recently = forwarded a packet along the DODAG(D,F)
    c. Otherwise, the routing interest is x*maximum = routing interest of the neighbors in DODAG(D,F), where x is a fraction. The node = comes to know of neighbor’s routing interest via the neighbor’s = DIO.
    d. A node leaves a DODAG if its routing interest in = the DODAG goes below a threshold.

Thanks
Mukul

----- Original Message -----
From: "Pascal Thubert (pthubert)" <pthubert@cisco.com>
To: "Mukul Goyal" <mukul@uwm.edu>
Cc: "ROLL WG" <roll@ietf.org>, "Ted Humpal" <Ted.Humpal@jci.com>, "robert cragie" <robert.cragie@gridmerge.com>
Sent: Friday, March 19, 2010 11:20:58 AM GMT -06:00 US/Canada = Central
Subject: RE: [Roll] P2P performance with current RPL proposal

Hi Mukul
> Here I have attempted to formulate a simple DV algorithm in RPL/DAG = terms.
> I will appreciate it if you could let me know about your objections = to this
> proposal:

[Pascal] It's cool that you do it is the first impression.

> Node A needs to reach a destination D. Node A initiates a discovery = DAG
> towards D. As the DIOs reach D, it sends a DAO back to selected = parents. As
> the DAO travels towards node A, in-route nodes store the cost to = reach D.
>
> When node B needs to reach D, it similarly initiates a discovery = dag. During
> this discovery, when a DIO reaches a node C that maintains a cost = to reach D,
> node C responds back with a DAO that travels towards B and stores = in in-
> route nodes the cost to reach D.

[Pascal]  understand that you're trying to make RPL even closer to = AODV.
I agree we need to gather as much as we can from that work.

For the specifics of your proposal:

- B-C might be orthogonal to A-D so that B/C\D forms an angle. You do = not end up with the best path that you're looking for.

- there might be multiple C's. Which one is the right one?

- RPL does not allow packets to switch instances. Following multiple = DAGs is the recipe for loops - unless you have them strictly ordered by some = means like the RPL sequence between iterations, more specific routes, blah = blah...)

- the A to D path is optimized for a certain constraint. You seem to = imply that the B to D path has the same constraints and metrics so we can compare = apple to apple. Because this is a very delicate operation, RPL has introduced the = Rank, which has the right properties to make that comparison efficiently.So = for RPL, the loop avoidance metric is the Rank, and it is only valid within an iteration.

- A P2P path does not come out of the blue. There must be some = provisionning system that determines that those nodes, A and B, are very special so = they need a P2P optimization, with a given special OF, and that they both need to = talk to D. Well, if that's so, the most economical is for that system to fork = the DAG out of D, with dual targets A and B. There you obtain the shortest path = for both A-D and B-D for the cost of a single flooding.

I see that you're trying to get the idea to work better, and I hope we = find a way to do so, maybe along your lines if we can solve the issues above. = But before we get there, we need to agree that this is the path we wish to = take.

Cheers,

Pascal


>
> ----- Original Message -----
> From: "Pascal Thubert (pthubert)" <pthubert@cisco.com>
> To: "robert cragie" <robert.cragie@gridmerge.com>
> Cc: "ROLL WG" <roll@ietf.org>, "Ted Humpal" <Ted.Humpal@jci.com>
> Sent: Thursday, March 18, 2010 9:23:14 PM GMT -06:00 US/Canada = Central
> Subject: Re: [Roll] P2P performance with current RPL proposal
>
>
>
>
>
> Hi Robert :
>
>
>
> At least from a distance, the proposed mechanism emulates AODV, = with the
> DIO as RREQ and the DAO as RREP. So if we decide to dig along those = lines,
> we’ll certainly appreciate help from MANET experts. I’d = say that if you
> already have RPL for P2MP and MP2P, the proposed extension are = probably
> simpler to add than doing AODV from scratch.
>
>
>
> For the setup, the major differences are that we build a DAG and = that we can
> indicate multiple targets. If you look at it, the DAG capability is = a MUST for
> RPL, and I have not seen that this MUST goes away for P2P flows. = The
> multiple targets is something that appears in a number of use cases = and it
> seems more economical to build a single DAG for multiple targets = when
> possible.
>
>
>
> For the maintenance, the major differences are that we have the DAG = as
> first line of defense, and the RPL detection to stimulate the local repair.
>
>
>
> About your questions:
>
>
>
> The DODAG root is the one that spawns the DAG. The targets can = reach the
> root because the root advertises itself in the DIO. The idea is = that the root ID
> is the address that the targets need to talk to. If needed, the = root can also
> advertise a prefix that it can reach and that the targets need to = reach too.
>
>
>
> All the intermediate nodes that are confirmed by the DAO need to = retain at
> least info about the DAG. That enables the targets to reach the = root. The
> flooding should cost about the same as that of AODV but the RPL way = will
> require more states in the nodes on the way if the OF requires a = DAG.
>
>
>
> The way back (down) can be stateful of stateless, depending on = which DAO
> we’re using. With fully stateful DAO, we are really in = AODV-land. With
> stateless, we could drift into DSR-land for that direction. Which = limits we
> place to keep it simple will be determined by the resolution of = issue #26 I
> guess…
>
>
>
> And please, no apologize or on one will dare post anything anymore. = Your
> questions are fully relevant and at the core of the discussion.
>
>
>
> I hope we can talk in Anaheim for sure,
>
>
>
>
> Pascal
>
>
>
>
>
>
> From: Robert Cragie [mailto:robert.cragie@gridmerg= e.com]
> Sent: Monday, March 15, 2010 11:27 AM
> To: Pascal Thubert (pth ubert)
> Cc: Ted.Humpal@jci.com; = ROLL WG
> Subject: Re: [Roll] P2P performance with current RPL proposal
>
>
>
> Hi Pascal,
>
> So in your slideware T can end up talking to R (DODAG root) through = the
> DODAG. So are you proposing that all potential targets can act as a = DODAG
> root? And therefore all intermediates have to retain DIO = propagation
> support for that DODAG as well? This may work for limited P2P but = seems
> less efficient than simple distance vector flooding RREQ/RREP like = AODV or
> DYMO for generic P2P. What about R to T (or anyone else for that = matter)?
> Do we source route, maintain state, some undefined hybrid of the = two?
>
> I apologise if some of these questions have been answered in detail = in earlier
> reflector posts but I have only recently started to concentrate my = efforts on
> RPL and have 82 pages to wade through :-). I look forward to a = productive
> session in Anaheim.
>
> Robert
>
>
> Robert Cragie (Pacific Gas & Electric)
>
> Gridmerge Ltd.
> 89 Greenfield Crescent,
> Wakefield, WF4 4WA, UK
> +44 (0) 1924 910888
> http://www.gridmerge.com
>
>
>
> Pascal Thubert (pthubert) wrote:
>
> HI Robert :
>
>
>
> I respectfully have to disagree.
>
>
>
> My understanding is that we are considering a limited set of P2P = pairs, for
> which the specific path that we need to create might have to obey = specific
> constraints.
>
> So it makes sense to use an on-demand technique, probably inspired = by the
> MANET Reactive protocols.
>
>
>
> As it goes, those protocols usually use flooding for a node to = locate another.
> Forking a DAG is just another flooding. It does not take a lot of = addition to the
> existing DIO for a root to use RPL to build a DAG that contains one = or multiple
> Targets as leaves, under a set of constraints expressed as an = objective
> function. Please find attached a slideware that illustrates = that.
>
>
>
>
> Pascal
>
>
>
>
>
>
> From: roll-bounces@ietf.org [ mailto:roll-bounces@ietf.org ] = On Behalf Of
> Robert Cragie
> Sent: Thursday, March 11, 2010 2:43 PM
> To: Ted.Humpal@jci.com
> Cc: ROLL WG
> Subject: Re: [Roll] P2P performance with current RPL proposal
>
>
>
> I agree with Ted's comments below. Creating a DODAG for every = reachable
> node as a root seems a very inefficient approach compared to = alternative
> routing algorithms. I am concerned that RPL does not actually meet = the
> original requirements in I-D.ietf-roll-building-routing-reqs, I-D.ietf-roll-home-
> routing-reqs, RFC5673 and RFC5548. The traffic pattern requirement = for a
> sink node features prominently in only two of those documents. Even = in this
> case, as Ted points out, communication is likely to be = bidirectional (e.g. end-
> to-end acks.) therefore the DODAG approach is fundamentally = asymmetric,
> especially if no intermediate storage is allowed for destination = routes and
> source routing has to be used.
>
> Also, RPL seems highly complex for what are constrained nodes in = terms of
> memory as well as power and bandwidth. The RPL draft as it stands = is 82
> pages long and that doesn't include text about the objective = function.
>
> Robert
>
>
> Robert Cragie (Pacific Gas & Electric)
>
> Gridmerge Ltd.
> 89 Greenfield Crescent,
> Wakefield, WF4 4WA, UK
> +44 (0) 1924 910888
> http://www.gridmerge.com
>
>
>
> Ted.Humpal@jci.com = wrote:
>
>
> A concern also will be how much overhead (memory space) will be = required
> for a DODAG Root?
>
> and based on the first question how many DODAG roots a lamp may = need to
> be a member of?
>
> For example in lighting  a single lamp may be a root for a = single switch (1
> DODAG root),  this lamp / luminaire may also
> be a member of another group - -  which could be all lights on = the floor (2nd
> DODAG root), and a third group
> of all the lights in the building.  There can be many more = speciality groups
> associated based on the building configuration.
> Consider also during the installation time - how these DODAG roots = will be
> configured?  Must I commission each device
> to tell it which DODAG it must use for its Object Function? =  How easy will this
> be to change and add in a new DODAG root
> for the end user if the lighting group changes??
>
> With respect to Jerry Martocci's - commercial building requirements = - every
> device may need to communicate to any or
> all of the end devices.  If each device must establish a DODAG = for the other
> 499 devices in a 500 node network - How much memory
> space will this require for each end device to maintain?
>
> Keep in mind that the end devices are very limited processor and = memory
> wise.
>
> Not to mention all of the network maintenance messages that would = need
> to be transmitted to maintain all of these DODAGs.
>
> Consider the reconvergence time when one device is turned off and = it was in
> the middle of the majority of the 100+ DODAGS?
>
> In many lighting and building application an application = acknowledgement -
> must be returned {Back down the DODAG} so . . . the
> requirement is not just getting to the Root - a return path must = also be
> maintained and have a  low latency path.
>
> Ted Humpal
>
>
>
>
>
>
> From:
>
> Kris Pister <pister@eecs.berkeley.edu>=
>
>
> To:
>
> Anders Brandt <abr@sdesigns.dk>
>
>
> Cc:
>
> ROLL WG <roll@ietf.org>
>
>
> Date:
>
> 03/08/2010 01:45 PM
>
>
> Subject:
>
> Re: [Roll] P2P performance with current RPL proposal
>
>
>
>
>
>
>
>
> Anders - if we take JP's suggestion to make The Lamp a DODAG root, = and
> take Phoebus' recommendation that we use path diversity to improve = end-
> to-end reliability, do you see a chance of success?
> In my experience, with diverse paths and order-minutes updates you = get
> extremely high reliability.
>
> I have no aversion to TTL-limited floods as a part of a solution = either.  I'm
> open to ideas on how to bring those in as (presumably infrequently = used)
> options.
>
> ksjp
>
> Anders Brandt wrote:
> Hello
>
> I would like to probe the temperature of the WG on using DAOs = to
> support P2P.
>
> The building and home application spaces (and maybe others) = have
> a few clearly defined requirements.
> It is not obvious to me how the current RPL proposal (cRPLp) = can
> satisfy those requirements:
>
>
> In both cases it is the worst case scenario that hurts:
>
>
> P2P routing inside the PAN
> = =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
> cRPLp has no way of routing inside the PAN if you need more = than
> one repeater. cRPLp has to go all the way to the top (maybe 4 hops = up)
> and down again (maybe 4 hops down) to get just 2 hops to the = side.
>
> The consequence is high latency and high levels of background = noise
> for nodes just outside the direct radio range.
> At the same time the risk of meeting a failing link is 4 times = higher =3D>
> latency may be much more than 4 times larger.
>
> Latency may sound like a minor issue but it actually translates = directly
> into lower battery lifetime. In the above (very realistic) = example,
> the battery lifetime is reduced to 25% of what it should be.
>
> We have lots of battery devices sending into the network:
> * PIR sensors turning on lights
> * Door locks sending alarms
> * Door/window sensors starting chimes
> * Smoke sensors triggering an alarm system
>
>
>
>
> Response time
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> The latency issue is important.
> When a user (real human being) presses a light button the user = expects
> the light to turn on.
> cRPLp proposes that nodes in the tree periodically advertises = their
> presence using DAOs.
> The periodicity is a real beast:
> Thanks to Trickle, the rate of updates in a (apparently) stable = network
> is low. This is good since it leaves bandwidth for data.
> But it is not good if existing routes to my lamp fail and I do not = get
> new routes to my lamp until it decides to send out a new DAO.
> My user will (with a good reason) not tolerate waiting for minutes = for
> the light to turn on.
>
> I have met two arguments to counter this concern:
>
> A1: Well, your lamp can always send a DAO when it detects a = problem.
>   My answer:
>   True, except that my lamp does not intend to send = anything
>   so it will never experience any problems from its side of = the network.
>
> A2: Well, you can increase the DAO rate to sub-second updates.
>   My answer:
>   Oh no. I get a very high degree of management traffic = which
>   limits my available bandwidth, increases the risk of = collisions and
>   even run the risk of violating EU legislation requiring me = to only
>   transmit in less than 1% of the time:
>   http://focus.ti.c= om/lit/an/swra048/swra048.pdf
>  868 - 868.6 MHz: <1%
>
>   Reactiveness is hard to achieve via polling.
>
>
>
> If you agree that this seems to be critical issues please raise = your
> voice on the list.
>
> Going forward
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>
> We need some reactive mechanism to reach lamps before the user = decides
> to sue our companies.
> So is this possible? I think so.
>
> Existing commercial (non-IP) solutions are capable of re-routing = quickly
> if they really have to.
>
> Let me try scoping the requirements to a potential solution:
> (no different from the req. docs for home and building)
>
> * P2P routing in any direction independent of the tree.
>
> * On-demand P2P route discovery if requested by a real-time = critical app.
>  Data collection apps may be able to just wait for the next = DAO update.
>
> * Limited range of discovery mechanism: max 4 repeaters.
>   A TTL field may limit the scope of the repeaters.
>
> * Suboptimal routing and traffic bursts are accepted in = exchange
>   for quick route repair. But only as an exception.
>
>
> Just as an example, one existing home control technology uses a
> (source routing) variant of AODV for quick route repair.
> Nothing comes for free. The price is flooding - but not just = flooding:
> Managed flooding using a distributed algorithm running in all
> participating nodes.
> The algorithm dampens the flooding in a time, volume and range
> perspective.
> Some similar mechanism could be built into RPL for quick route = repair.
>
>
> If anyone have alternative proposals, please bring it to the = list.
> Now is the time.
>
>
>
> Thanks,
>   Anders
>
>
>
>
> _______________________________________________
> Roll mailing 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

------=_NextPart_000_012C_01CAC9A2.FC249020-- From abr@sdesigns.dk Mon Mar 22 09:40: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 6CCF83A68B2 for ; Mon, 22 Mar 2010 09:40:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.834 X-Spam-Level: * X-Spam-Status: No, score=1.834 tagged_above=-999 required=5 tests=[AWL=-2.194, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, HTML_MESSAGE=0.001, J_CHICKENPOX_12=0.6, J_CHICKENPOX_17=0.6, J_CHICKENPOX_51=0.6, MANGLED_OFF=2.3, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P1YXlBHTN0Pc for ; Mon, 22 Mar 2010 09:40:10 -0700 (PDT) Received: from mail.zen-sys.com (mail.zen-sys.com [195.215.56.170]) by core3.amsl.com (Postfix) with ESMTP id 0790D28C1A9 for ; Mon, 22 Mar 2010 09:40: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_01CAC9DE.5BC87B76" Date: Mon, 22 Mar 2010 17:40:06 +0100 Message-ID: <6D9687E95918C04A8B30A7D6DA805A3E01AD45D4@zensys17.zensys.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] P2P performance with current RPL proposal Thread-Index: AcrJ27QCOcDu36d8SkWfPrOHLFLUZwAAKJZgAABEZCAAADsfBg== References: <1161577952.8138041269244020805.JavaMail.root@mail02.pantherlink.uwm.edu> <6D9687E95918C04A8B30A7D6DA805A3E01AD45CF@zensys17.zensys.local> <009b01cac9cf$51934660$f4b9d320$@sturek@att.net> <6D9687E95918C04A8B30A7D6DA805A3E01AD45D2@zensys17.zensys.local> <012b01cac9dd$a8836820$f98a3860$@sturek@att.net> From: "Anders Brandt" To: , "Philip Levis" Cc: ROLL WG , Ted Humpal Subject: Re: [Roll] P2P performance with current RPL proposal X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Mar 2010 16:40:26 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CAC9DE.5BC87B76 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I guess you are right! ________________________________ Fra: Don Sturek [mailto:d.sturek@att.net] Sendt: ma 22-03-2010 10:35 Til: Anders Brandt; 'Philip Levis' Cc: 'Mukul Goyal'; 'Pascal Thubert (pthubert)'; 'ROLL WG'; 'Ted Humpal' Emne: RE: [Roll] P2P performance with current RPL proposal I would be interested in hearing Mukul's thoughts on this. I did not = read his proposal to say that hop count is the only metric. I would = expect the metric used for the DODAG(D,F) to be the OF "F" (whatever = that happens to be for the DODAG). =20 Don =20 =20 From: Anders Brandt [mailto:abr@sdesigns.dk]=20 Sent: Monday, March 22, 2010 9:31 AM To: Philip Levis; d.sturek@att.net Cc: Mukul Goyal; Pascal Thubert (pthubert); ROLL WG; Ted Humpal Subject: SV: [Roll] P2P performance with current RPL proposal =20 Well, yes. =20 But it needs to be seen in the right context: I really need to get my lamp turned on within seconds when my users = press the button. Even if this meens that I get a less-than-optimal route. =20 The intention is not to skip all the nice DODAG DIO work that was done. = It serves a good purpose in large networks. The case is just that home & building have some tougher requirements = within restricted areas (<=3D 4 repeaters) such as battery-friendly (i.e. short routes) and reactive discovery to = "guarantee" low response times always. =20 The challenge is to get this for free. =20 - Anders =20 ________________________________ Fra: Philip Levis [mailto:pal@cs.stanford.edu] Sendt: ma 22-03-2010 10:20 Til: d.sturek@att.net Cc: Anders Brandt; Mukul Goyal; Pascal Thubert (pthubert); ROLL WG; Ted = Humpal Emne: Re: [Roll] P2P performance with current RPL proposal Just to be sure I am hearing this right -the proposal is to use = hopcount-based route selection? =20 Phil On Mar 22, 2010, at 7:52 AM, "Don Sturek" wrote: Hi Anders and Mukul, =20 This is all sounding quite promising in addressing P2P routing in RPL. = How can we organize a specific proposal we can gain WG approval for? I = would like to leave Anaheim with an agreed path towards P2P routing = support we all believe addresses the Home Automation and Building = Controls use cases. =20 Don =20 =20 From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of = Anders Brandt Sent: Monday, March 22, 2010 7:46 AM To: Mukul Goyal; Pascal Thubert (pthubert) Cc: ROLL WG; Ted Humpal Subject: Re: [Roll] P2P performance with current RPL proposal =20 Add to this an element of promiscuos listening to dampen the storm =3D> = if node already detected a copy of the DIS with the same TTL (or lower) = - do not forward the DIS. Then you start getting closer to something. =20 Oh - and by the way - record the source route on the way ;-) =20 - Anders =20 ________________________________ Fra: roll-bounces@ietf.org p=E5 vegne af Mukul Goyal Sendt: ma 22-03-2010 01:47 Til: Pascal Thubert (pthubert) Cc: ROLL WG; Ted Humpal Emne: Re: [Roll] P2P performance with current RPL proposal Hi Pascal =09 Thanks for your comments (let me send my response in the next email). =09 Based on further thoughts, it seems to me that a DAG based P2P solution = would work if we do the following: =09 (a) allowing multicast DIS messages to spread to an = originator-specified number of hops and (b) allowing nodes to join a DAG temporarily and leave it if there is = not sufficient "routing interest" in being part of the DAG. =09 With these points in mind, a P2P scheme could work as follows: =09 1. When a node wants to join a DODAG(D,F), where D is the DODAG's root = and F is the OF being used, it does the following: a. Initiates a discovery table entry for DODAG(D,F). The discovery = table entries are removed after a certain lifetime. b. sends out a DIS via link-local multicast asking specifically for = information about DODAG(D,F). It also lists in the DIS the number of = hops the DIS can travel. =09 2. On receiving a DIS, a node does the following: a.if it does not know about DODAG(D,F) and the DIS hop limit is not = yet reached i. Initiates a discovery table entry for DODAG(D,F). This entry = maintains information about the nodes from whom the DIS were received. ii. sends out the DIS (via link-local multicast with trickle = controlled timing) further. b. If it is already a part of DODAG(D,F) or is node D itself i. Send out a DIO about DODAG(D,F) to the node from whom the = DIS was received. =09 3. On receiving a DIO about DODAG(D,F), a node does the following: a. Ignore the DIO if the node does not have a discovery table entry = for DODAG(D,F) b. Otherwise, the node joins the DODAG(D,F) (if not already part of = it) or updates its parent set in DODAG(D,F) and sends the DIO by unicast = to the nodes that had sent it the DIS. =09 4. Once, the node is part of the DODAG(D,F), it maintains a "routing = interest" for the DODAG in the following manner: a. Routing interest is a value between 0 and 1 b. Routing interest is 1 if the node recently forwarded a packet = along the DODAG(D,F) c. Otherwise, the routing interest is x*maximum routing interest of = the neighbors in DODAG(D,F), where x is a fraction. The node comes to = know of neighbor's routing interest via the neighbor's DIO. d. A node leaves a DODAG if its routing interest in the DODAG goes = below a threshold. =09 Thanks Mukul =09 ----- Original Message ----- From: "Pascal Thubert (pthubert)" To: "Mukul Goyal" Cc: "ROLL WG" , "Ted Humpal" , = "robert cragie" Sent: Friday, March 19, 2010 11:20:58 AM GMT -06:00 US/Canada Central Subject: RE: [Roll] P2P performance with current RPL proposal =09 Hi Mukul > Here I have attempted to formulate a simple DV algorithm in RPL/DAG = terms. > I will appreciate it if you could let me know about your objections = to this > proposal: =09 [Pascal] It's cool that you do it is the first impression. =09 > Node A needs to reach a destination D. Node A initiates a discovery = DAG > towards D. As the DIOs reach D, it sends a DAO back to selected = parents. As > the DAO travels towards node A, in-route nodes store the cost to = reach D. > > When node B needs to reach D, it similarly initiates a discovery dag. = During > this discovery, when a DIO reaches a node C that maintains a cost to = reach D, > node C responds back with a DAO that travels towards B and stores in = in- > route nodes the cost to reach D. =09 [Pascal] understand that you're trying to make RPL even closer to = AODV. I agree we need to gather as much as we can from that work. =09 For the specifics of your proposal: =09 - B-C might be orthogonal to A-D so that B/C\D forms an angle. You do = not end up with the best path that you're looking for. =09 - there might be multiple C's. Which one is the right one? =09 - RPL does not allow packets to switch instances. Following multiple = DAGs is the recipe for loops - unless you have them strictly ordered by = some means like the RPL sequence between iterations, more specific = routes, blah blah...) =09 - the A to D path is optimized for a certain constraint. You seem to = imply that the B to D path has the same constraints and metrics so we = can compare apple to apple. Because this is a very delicate operation, = RPL has introduced the Rank, which has the right properties to make that = comparison efficiently.So for RPL, the loop avoidance metric is the = Rank, and it is only valid within an iteration. =09 - A P2P path does not come out of the blue. There must be some = provisionning system that determines that those nodes, A and B, are very = special so they need a P2P optimization, with a given special OF, and = that they both need to talk to D. Well, if that's so, the most = economical is for that system to fork the DAG out of D, with dual = targets A and B. There you obtain the shortest path for both A-D and B-D = for the cost of a single flooding. =09 I see that you're trying to get the idea to work better, and I hope we = find a way to do so, maybe along your lines if we can solve the issues = above. But before we get there, we need to agree that this is the path = we wish to take. =09 Cheers, =09 Pascal =09 =09 > > ----- Original Message ----- > From: "Pascal Thubert (pthubert)" > To: "robert cragie" > Cc: "ROLL WG" , "Ted Humpal" > Sent: Thursday, March 18, 2010 9:23:14 PM GMT -06:00 US/Canada = Central > Subject: Re: [Roll] P2P performance with current RPL proposal > > > > > > Hi Robert : > > > > At least from a distance, the proposed mechanism emulates AODV, with = the > DIO as RREQ and the DAO as RREP. So if we decide to dig along those = lines, > we'll certainly appreciate help from MANET experts. I'd say that if = you > already have RPL for P2MP and MP2P, the proposed extension are = probably > simpler to add than doing AODV from scratch. > > > > For the setup, the major differences are that we build a DAG and that = we can > indicate multiple targets. If you look at it, the DAG capability is a = MUST for > RPL, and I have not seen that this MUST goes away for P2P flows. The > multiple targets is something that appears in a number of use cases = and it > seems more economical to build a single DAG for multiple targets when > possible. > > > > For the maintenance, the major differences are that we have the DAG = as > first line of defense, and the RPL detection to stimulate the local = repair. > > > > About your questions: > > > > The DODAG root is the one that spawns the DAG. The targets can reach = the > root because the root advertises itself in the DIO. The idea is that = the root ID > is the address that the targets need to talk to. If needed, the root = can also > advertise a prefix that it can reach and that the targets need to = reach too. > > > > All the intermediate nodes that are confirmed by the DAO need to = retain at > least info about the DAG. That enables the targets to reach the root. = The > flooding should cost about the same as that of AODV but the RPL way = will > require more states in the nodes on the way if the OF requires a DAG. > > > > The way back (down) can be stateful of stateless, depending on which = DAO > we're using. With fully stateful DAO, we are really in AODV-land. = With > stateless, we could drift into DSR-land for that direction. Which = limits we > place to keep it simple will be determined by the resolution of issue = #26 I > guess... > > > > And please, no apologize or on one will dare post anything anymore. = Your > questions are fully relevant and at the core of the discussion. > > > > I hope we can talk in Anaheim for sure, > > > > > Pascal > > > > > > > From: Robert Cragie [mailto:robert.cragie@gridmerge.com] > Sent: Monday, March 15, 2010 11:27 AM > To: Pascal Thubert (pth ubert) > Cc: Ted.Humpal@jci.com; ROLL WG > Subject: Re: [Roll] P2P performance with current RPL proposal > > > > Hi Pascal, > > So in your slideware T can end up talking to R (DODAG root) through = the > DODAG. So are you proposing that all potential targets can act as a = DODAG > root? And therefore all intermediates have to retain DIO propagation > support for that DODAG as well? This may work for limited P2P but = seems > less efficient than simple distance vector flooding RREQ/RREP like = AODV or > DYMO for generic P2P. What about R to T (or anyone else for that = matter)? > Do we source route, maintain state, some undefined hybrid of the two? > > I apologise if some of these questions have been answered in detail = in earlier > reflector posts but I have only recently started to concentrate my = efforts on > RPL and have 82 pages to wade through :-). I look forward to a = productive > session in Anaheim. > > Robert > > > Robert Cragie (Pacific Gas & Electric) > > Gridmerge Ltd. > 89 Greenfield Crescent, > Wakefield, WF4 4WA, UK > +44 (0) 1924 910888 > http://www.gridmerge.com =20 > > > > Pascal Thubert (pthubert) wrote: > > HI Robert : > > > > I respectfully have to disagree. > > > > My understanding is that we are considering a limited set of P2P = pairs, for > which the specific path that we need to create might have to obey = specific > constraints. > > So it makes sense to use an on-demand technique, probably inspired by = the > MANET Reactive protocols. > > > > As it goes, those protocols usually use flooding for a node to locate = another. > Forking a DAG is just another flooding. It does not take a lot of = addition to the > existing DIO for a root to use RPL to build a DAG that contains one = or multiple > Targets as leaves, under a set of constraints expressed as an = objective > function. Please find attached a slideware that illustrates that. > > > > > Pascal > > > > > > > From: roll-bounces@ietf.org [ mailto:roll-bounces@ietf.org ] On = Behalf Of > Robert Cragie > Sent: Thursday, March 11, 2010 2:43 PM > To: Ted.Humpal@jci.com > Cc: ROLL WG > Subject: Re: [Roll] P2P performance with current RPL proposal > > > > I agree with Ted's comments below. Creating a DODAG for every = reachable > node as a root seems a very inefficient approach compared to = alternative > routing algorithms. I am concerned that RPL does not actually meet = the > original requirements in I-D.ietf-roll-building-routing-reqs, = I-D.ietf-roll-home- > routing-reqs, RFC5673 and RFC5548. The traffic pattern requirement = for a > sink node features prominently in only two of those documents. Even = in this > case, as Ted points out, communication is likely to be bidirectional = (e.g. end- > to-end acks.) therefore the DODAG approach is fundamentally = asymmetric, > especially if no intermediate storage is allowed for destination = routes and > source routing has to be used. > > Also, RPL seems highly complex for what are constrained nodes in = terms of > memory as well as power and bandwidth. The RPL draft as it stands is = 82 > pages long and that doesn't include text about the objective = function. > > Robert > > > Robert Cragie (Pacific Gas & Electric) > > Gridmerge Ltd. > 89 Greenfield Crescent, > Wakefield, WF4 4WA, UK > +44 (0) 1924 910888 > http://www.gridmerge.com =20 > > > > Ted.Humpal@jci.com wrote: > > > A concern also will be how much overhead (memory space) will be = required > for a DODAG Root? > > and based on the first question how many DODAG roots a lamp may need = to > be a member of? > > For example in lighting a single lamp may be a root for a single = switch (1 > DODAG root), this lamp / luminaire may also > be a member of another group - - which could be all lights on the = floor (2nd > DODAG root), and a third group > of all the lights in the building. There can be many more speciality = groups > associated based on the building configuration. > Consider also during the installation time - how these DODAG roots = will be > configured? Must I commission each device > to tell it which DODAG it must use for its Object Function? How easy = will this > be to change and add in a new DODAG root > for the end user if the lighting group changes?? > > With respect to Jerry Martocci's - commercial building requirements - = every > device may need to communicate to any or > all of the end devices. If each device must establish a DODAG for = the other > 499 devices in a 500 node network - How much memory > space will this require for each end device to maintain? > > Keep in mind that the end devices are very limited processor and = memory > wise. > > Not to mention all of the network maintenance messages that would = need > to be transmitted to maintain all of these DODAGs. > > Consider the reconvergence time when one device is turned off and it = was in > the middle of the majority of the 100+ DODAGS? > > In many lighting and building application an application = acknowledgement - > must be returned {Back down the DODAG} so . . . the > requirement is not just getting to the Root - a return path must also = be > maintained and have a low latency path. > > Ted Humpal > > > > > > > From: > > Kris Pister > > > To: > > Anders Brandt > > > Cc: > > ROLL WG > > > Date: > > 03/08/2010 01:45 PM > > > Subject: > > Re: [Roll] P2P performance with current RPL proposal > > > > > > > > > Anders - if we take JP's suggestion to make The Lamp a DODAG root, = and > take Phoebus' recommendation that we use path diversity to improve = end- > to-end reliability, do you see a chance of success? > In my experience, with diverse paths and order-minutes updates you = get > extremely high reliability. > > I have no aversion to TTL-limited floods as a part of a solution = either. I'm > open to ideas on how to bring those in as (presumably infrequently = used) > options. > > ksjp > > Anders Brandt wrote: > Hello > > I would like to probe the temperature of the WG on using DAOs to > support P2P. > > The building and home application spaces (and maybe others) have > a few clearly defined requirements. > It is not obvious to me how the current RPL proposal (cRPLp) can > satisfy those requirements: > > > In both cases it is the worst case scenario that hurts: > > > P2P routing inside the PAN > = =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 > cRPLp has no way of routing inside the PAN if you need more than > one repeater. cRPLp has to go all the way to the top (maybe 4 hops = up) > and down again (maybe 4 hops down) to get just 2 hops to the side. > > The consequence is high latency and high levels of background noise > for nodes just outside the direct radio range. > At the same time the risk of meeting a failing link is 4 times higher = =3D> > latency may be much more than 4 times larger. > > Latency may sound like a minor issue but it actually translates = directly > into lower battery lifetime. In the above (very realistic) example, > the battery lifetime is reduced to 25% of what it should be. > > We have lots of battery devices sending into the network: > * PIR sensors turning on lights > * Door locks sending alarms > * Door/window sensors starting chimes > * Smoke sensors triggering an alarm system > > > > > Response time > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > The latency issue is important. > When a user (real human being) presses a light button the user = expects > the light to turn on. > cRPLp proposes that nodes in the tree periodically advertises their > presence using DAOs. > The periodicity is a real beast: > Thanks to Trickle, the rate of updates in a (apparently) stable = network > is low. This is good since it leaves bandwidth for data. > But it is not good if existing routes to my lamp fail and I do not = get > new routes to my lamp until it decides to send out a new DAO. > My user will (with a good reason) not tolerate waiting for minutes = for > the light to turn on. > > I have met two arguments to counter this concern: > > A1: Well, your lamp can always send a DAO when it detects a problem. > My answer: > True, except that my lamp does not intend to send anything > so it will never experience any problems from its side of the = network. > > A2: Well, you can increase the DAO rate to sub-second updates. > My answer: > Oh no. I get a very high degree of management traffic which > limits my available bandwidth, increases the risk of collisions and > even run the risk of violating EU legislation requiring me to only > transmit in less than 1% of the time: > http://focus.ti.com/lit/an/swra048/swra048.pdf > 868 - 868.6 MHz: <1% > > Reactiveness is hard to achieve via polling. > > > > If you agree that this seems to be critical issues please raise your > voice on the list. > > Going forward > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > We need some reactive mechanism to reach lamps before the user = decides > to sue our companies. > So is this possible? I think so. > > Existing commercial (non-IP) solutions are capable of re-routing = quickly > if they really have to. > > Let me try scoping the requirements to a potential solution: > (no different from the req. docs for home and building) > > * P2P routing in any direction independent of the tree. > > * On-demand P2P route discovery if requested by a real-time critical = app. > Data collection apps may be able to just wait for the next DAO = update. > > * Limited range of discovery mechanism: max 4 repeaters. > A TTL field may limit the scope of the repeaters. > > * Suboptimal routing and traffic bursts are accepted in exchange > for quick route repair. But only as an exception. > > > Just as an example, one existing home control technology uses a > (source routing) variant of AODV for quick route repair. > Nothing comes for free. The price is flooding - but not just = flooding: > Managed flooding using a distributed algorithm running in all > participating nodes. > The algorithm dampens the flooding in a time, volume and range > perspective. > Some similar mechanism could be built into RPL for quick route = repair. > > > If anyone have alternative proposals, please bring it to the list. > Now is the time. > > > > Thanks, > Anders > > > > > _______________________________________________ > Roll mailing 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 ------_=_NextPart_001_01CAC9DE.5BC87B76 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =0A= =0A= =0A= =0A= =0A= =0A=
=0A=
I guess you = are right!
=0A=

=0A=
=0A= Fra: Don Sturek = [mailto:d.sturek@att.net]
Sendt: ma 22-03-2010 = 10:35
Til: Anders Brandt; 'Philip Levis'
Cc: 'Mukul = Goyal'; 'Pascal Thubert (pthubert)'; 'ROLL WG'; 'Ted = Humpal'
Emne: RE: [Roll] P2P performance with current RPL = proposal

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

I would be interested in hearing = Mukul’s thoughts on this.  I did not read his proposal to say = that hop count is the only metric.   I would expect the metric = used for the DODAG(D,F) to be the = OF “F” (whatever that happens to be for the = DODAG).

=0A=

 

=0A=

Don

=0A=

 

=0A=

 

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

From: Anders = Brandt [mailto:abr@sdesigns.dk]
Sent: Monday, March 22, 2010 = 9:31 AM
To: Philip Levis; d.sturek@att.net
Cc: Mukul = Goyal; Pascal Thubert (pthubert); ROLL WG; Ted Humpal
Subject: = SV: [Roll] P2P performance with current RPL = proposal

=0A=

 

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

Well, yes.

=0A=
=0A=

 

=0A=
=0A=

But it needs to be seen in the right = context:

=0A=
=0A=

I really need to get my lamp turned on within seconds = when my users press the button.

=0A=
=0A=

Even if this meens that I get a less-than-optimal = route.

=0A=
=0A=

 

=0A=
=0A=

The intention is not to skip all the nice DODAG DIO = work that was done. It serves a good purpose

=0A=
=0A=

in large networks.

=0A=
=0A=

The case is just that home & building have some = tougher requirements within restricted areas (<=3D 4 = repeaters)
such as battery-friendly (i.e. short routes) and reactive = discovery to "guarantee" low response times always.

=0A=
=0A=

 

=0A=
=0A=

The challenge is to get this for free.

=0A=
=0A=

 

=0A=
=0A=

- Anders

=0A=
=0A=

 

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

Fra: Philip Levis = [mailto:pal@cs.stanford.edu]
Sendt: ma 22-03-2010 = 10:20
Til: d.sturek@att.net
Cc: Anders Brandt; Mukul = Goyal; Pascal Thubert (pthubert); ROLL WG; Ted Humpal
Emne: = Re: [Roll] P2P performance with current RPL proposal

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

Just to be sure I am hearing this right -the = proposal is to use hopcount-based route selection?

=0A=
=0A=

 

=0A=
=0A=

Phil

=0A=
=0A=


On Mar 22, 2010, = at 7:52 AM, "Don Sturek" <d.sturek@att.net> = wrote:

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

Hi = Anders and Mukul,

=0A=

 

=0A=

This is all sounding quite promising in addressing P2P routing in = RPL.  How can we organize a specific proposal we can gain WG = approval for?  I would like to leave Anaheim with an agreed path = towards P2P routing support we all believe addresses the Home Automation = and Building Controls use cases.

=0A=

 

=0A=

Don

=0A=

 

=0A=

 

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

From: roll-bounces@ietf.org = [mailto:roll-bounces@ietf.org] On Behalf Of Anders = Brandt
Sent: Monday, March 22, 2010 7:46 AM
To: = Mukul Goyal; Pascal Thubert (pthubert)
Cc: ROLL WG; Ted = Humpal
Subject: Re: [Roll] P2P performance with current RPL = proposal

=0A=

 

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

Add = to this an element of promiscuos listening to dampen the storm =3D> = if node already detected a copy of the DIS with the same TTL (or lower) = - do not forward the DIS. Then you start getting closer to = something.

=0A=
=0A=

 

=0A=
=0A=

Oh - and by the way = - record the source route on the way ;-)

=0A=
=0A=

 

=0A=
=0A=

- = Anders

=0A=
=0A=

 

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

Fra: roll-bounces@ietf.org p=E5 = vegne af Mukul Goyal
Sendt: ma 22-03-2010 01:47
Til: = Pascal Thubert (pthubert)
Cc: ROLL WG; Ted = Humpal
Emne: Re: [Roll] P2P performance with current RPL = proposal

=0A=
=0A=

Hi Pascal

Thanks for your = comments (let me send my response in the next email).

Based on = further thoughts, it seems to me that a DAG based P2P solution would = work if we do the following:

(a) allowing multicast DIS messages = to spread to an originator-specified number of hops and
(b) allowing = nodes to join a DAG temporarily and leave it if there is not sufficient = “routing interest” in being part of the DAG.

With = these points in mind, a P2P scheme could work as follows:

1. When = a node wants to join a DODAG(D,F), where D is the DODAG's root and F is = the OF being used, it does the following:
    a. = Initiates a discovery table entry for DODAG(D,F). The discovery table = entries are removed after a certain lifetime.
    b. = sends out a DIS via link-local multicast asking specifically for = information about DODAG(D,F). It also lists in the DIS the number of = hops the DIS can travel.

2. On receiving  a DIS, a node does = the following:
    a.if it does not know about = DODAG(D,F) and the DIS hop limit is not yet = reached
        i. Initiates a = discovery table entry for DODAG(D,F). This entry maintains information = about the nodes from whom the DIS were = received.
        ii. sends out = the DIS (via link-local multicast with trickle controlled timing) = further.
    b. If it is already a part of DODAG(D,F) = or is node D itself
        i. = Send out a DIO about DODAG(D,F) to the node from whom the DIS was = received.

3. On receiving a DIO about DODAG(D,F), a node does the = following:
    a. Ignore the DIO if the node does not = have a discovery table entry for DODAG(D,F)
    b. = Otherwise, the node joins the DODAG(D,F) (if not already part of it) or = updates its parent set in DODAG(D,F) and sends the DIO by unicast to the = nodes that had sent it the DIS.

4. Once, the node is part of the = DODAG(D,F), it maintains a “routing interest” for the DODAG = in the following manner:
    a. Routing interest is a = value between 0 and 1
    b. Routing interest is 1 if = the node recently forwarded a packet along the = DODAG(D,F)
    c. Otherwise, the routing interest is = x*maximum routing interest of the neighbors in DODAG(D,F), where x is a = fraction. The node comes to know of neighbor’s routing interest = via the neighbor’s DIO.
    d. A node leaves a = DODAG if its routing interest in the DODAG goes below a = threshold.

Thanks
Mukul

----- Original Message = -----
From: "Pascal Thubert (pthubert)" <pthubert@cisco.com>
To: = "Mukul Goyal" <mukul@uwm.edu>
Cc: "ROLL WG" = <roll@ietf.org>, "Ted Humpal" = <Ted.Humpal@jci.com>, = "robert cragie" <robert.cragie@gridmerge.com>
Sent: Friday, March 19, 2010 11:20:58 AM GMT -06:00 US/Canada = Central
Subject: RE: [Roll] P2P performance with current RPL = proposal

Hi Mukul
> Here I have attempted to formulate a = simple DV algorithm in RPL/DAG terms.
> I will appreciate it if = you could let me know about your objections to this
> = proposal:

[Pascal] It's cool that you do it is the first = impression.

> Node A needs to reach a destination D. Node A = initiates a discovery DAG
> towards D. As the DIOs reach D, it = sends a DAO back to selected parents. As
> the DAO travels towards = node A, in-route nodes store the cost to reach D.
>
> When = node B needs to reach D, it similarly initiates a discovery dag. = During
> this discovery, when a DIO reaches a node C that = maintains a cost to reach D,
> node C responds back with a DAO = that travels towards B and stores in in-
> route nodes the cost to = reach D.

[Pascal]  understand that you're trying to make RPL = even closer to AODV.
I agree we need to gather as much as we can from = that work.

For the specifics of your proposal:

- B-C might = be orthogonal to A-D so that B/C\D forms an angle. You do not end up = with the best path that you're looking for.

- there might be = multiple C's. Which one is the right one?

- RPL does not allow = packets to switch instances. Following multiple DAGs is the recipe for = loops - unless you have them strictly ordered by some means like the RPL = sequence between iterations, more specific routes, blah = blah...)

- the A to D path is optimized for a certain constraint. = You seem to imply that the B to D path has the same constraints and = metrics so we can compare apple to apple. Because this is a very = delicate operation, RPL has introduced the Rank, which has the right = properties to make that comparison efficiently.So for RPL, the loop = avoidance metric is the Rank, and it is only valid within an = iteration.

- A P2P path does not come out of the blue. There must = be some provisionning system that determines that those nodes, A and B, = are very special so they need a P2P optimization, with a given special = OF, and that they both need to talk to D. Well, if that's so, the most = economical is for that system to fork the DAG out of D, with dual = targets A and B. There you obtain the shortest path for both A-D and B-D = for the cost of a single flooding.

I see that you're trying to = get the idea to work better, and I hope we find a way to do so, maybe = along your lines if we can solve the issues above. But before we get = there, we need to agree that this is the path we wish to = take.

Cheers,

Pascal


>
> ----- = Original Message -----
> From: "Pascal Thubert (pthubert)" <pthubert@cisco.com>
> = To: "robert cragie" <robert.cragie@gridmerge.com>
> Cc: "ROLL WG" <roll@ietf.org>, "Ted Humpal" <Ted.Humpal@jci.com>
> = Sent: Thursday, March 18, 2010 9:23:14 PM GMT -06:00 US/Canada = Central
> Subject: Re: [Roll] P2P performance with current RPL = proposal
>
>
>
>
>
> Hi = Robert :
>
>
>
> At least from a distance, = the proposed mechanism emulates AODV, with the
> DIO as RREQ and = the DAO as RREP. So if we decide to dig along those lines,
> = we’ll certainly appreciate help from MANET experts. I’d say = that if you
> already have RPL for P2MP and MP2P, the proposed = extension are probably
> simpler to add than doing AODV from = scratch.
>
>
>
> For the setup, the major = differences are that we build a DAG and that we can
> indicate = multiple targets. If you look at it, the DAG capability is a MUST = for
> RPL, and I have not seen that this MUST goes away for P2P = flows. The
> multiple targets is something that appears in a = number of use cases and it
> seems more economical to build a = single DAG for multiple targets when
> = possible.
>
>
>
> For the maintenance, the major = differences are that we have the DAG as
> first line of defense, = and the RPL detection to stimulate the local = repair.
>
>
>
> About your = questions:
>
>
>
> The DODAG root is the one = that spawns the DAG. The targets can reach the
> root because the = root advertises itself in the DIO. The idea is that the root ID
> = is the address that the targets need to talk to. If needed, the root can = also
> advertise a prefix that it can reach and that the targets = need to reach too.
>
>
>
> All the intermediate = nodes that are confirmed by the DAO need to retain at
> least info = about the DAG. That enables the targets to reach the root. The
> = flooding should cost about the same as that of AODV but the RPL way = will
> require more states in the nodes on the way if the OF = requires a DAG.
>
>
>
> The way back (down) can = be stateful of stateless, depending on which DAO
> we’re = using. With fully stateful DAO, we are really in AODV-land. With
> = stateless, we could drift into DSR-land for that direction. Which limits = we
> place to keep it simple will be determined by the resolution = of issue #26 I
> guess…
>
>
>
> And = please, no apologize or on one will dare post anything anymore. = Your
> questions are fully relevant and at the core of the = discussion.
>
>
>
> I hope we can talk in = Anaheim for sure,
>
>
>
>
> = Pascal
>
>
>
>
>
>
> From: = Robert Cragie [mailto:robert.cragie@gridmerg= e.com]
> Sent: Monday, March 15, 2010 11:27 AM
> To: = Pascal Thubert (pth ubert)
> Cc: Ted.Humpal@jci.com; ROLL = WG
> Subject: Re: [Roll] P2P performance with current RPL = proposal
>
>
>
> Hi Pascal,
>
> So = in your slideware T can end up talking to R (DODAG root) through = the
> DODAG. So are you proposing that all potential targets can = act as a DODAG
> root? And therefore all intermediates have to = retain DIO propagation
> support for that DODAG as well? This may = work for limited P2P but seems
> less efficient than simple = distance vector flooding RREQ/RREP like AODV or
> DYMO for generic = P2P. What about R to T (or anyone else for that matter)?
> Do we = source route, maintain state, some undefined hybrid of the = two?
>
> I apologise if some of these questions have been = answered in detail in earlier
> reflector posts but I have only = recently started to concentrate my efforts on
> RPL and have 82 = pages to wade through :-). I look forward to a productive
> = session in Anaheim.
>
> Robert
>
>
> = Robert Cragie (Pacific Gas & Electric)
>
> Gridmerge = Ltd.
> 89 Greenfield Crescent,
> Wakefield, WF4 4WA, = UK
> +44 (0) 1924 910888
> http://www.gridmerge.com
>>
>
> Pascal Thubert (pthubert) wrote:
>
> = HI Robert :
>
>
>
> I respectfully have to = disagree.
>
>
>
> My understanding is that we = are considering a limited set of P2P pairs, for
> which the = specific path that we need to create might have to obey specific
> = constraints.
>
> So it makes sense to use an on-demand = technique, probably inspired by the
> MANET Reactive = protocols.
>
>
>
> As it goes, those protocols = usually use flooding for a node to locate another.
> Forking a DAG = is just another flooding. It does not take a lot of addition to = the
> existing DIO for a root to use RPL to build a DAG that = contains one or multiple
> Targets as leaves, under a set of = constraints expressed as an objective
> function. Please find = attached a slideware that illustrates = that.
>
>
>
>
> = Pascal
>
>
>
>
>
>
> From: roll-bounces@ietf.org [ mailto:roll-bounces@ietf.org ] = On Behalf Of
> Robert Cragie
> Sent: Thursday, March 11, = 2010 2:43 PM
> To: Ted.Humpal@jci.com
> Cc: = ROLL WG
> Subject: Re: [Roll] P2P performance with current RPL = proposal
>
>
>
> I agree with Ted's comments = below. Creating a DODAG for every reachable
> node as a root seems = a very inefficient approach compared to alternative
> routing = algorithms. I am concerned that RPL does not actually meet the
> = original requirements in I-D.ietf-roll-building-routing-reqs, = I-D.ietf-roll-home-
> routing-reqs, RFC5673 and RFC5548. The = traffic pattern requirement for a
> sink node features prominently = in only two of those documents. Even in this
> case, as Ted points = out, communication is likely to be bidirectional (e.g. end-
> = to-end acks.) therefore the DODAG approach is fundamentally = asymmetric,
> especially if no intermediate storage is allowed for = destination routes and
> source routing has to be = used.
>
> Also, RPL seems highly complex for what are = constrained nodes in terms of
> memory as well as power and = bandwidth. The RPL draft as it stands is 82
> pages long and that = doesn't include text about the objective function.
>
> = Robert
>
>
> Robert Cragie (Pacific Gas & = Electric)
>
> Gridmerge Ltd.
> 89 Greenfield = Crescent,
> Wakefield, WF4 4WA, UK
> +44 (0) 1924 = 910888
> http://www.gridmerge.com
>>
>
> Ted.Humpal@jci.com = wrote:
>
>
> A concern also will be how much overhead = (memory space) will be required
> for a DODAG = Root?
>
> and based on the first question how many DODAG = roots a lamp may need to
> be a member of?
>
> For = example in lighting  a single lamp may be a root for a single = switch (1
> DODAG root),  this lamp / luminaire may = also
> be a member of another group - -  which could be all = lights on the floor (2nd
> DODAG root), and a third group
> = of all the lights in the building.  There can be many more = speciality groups
> associated based on the building = configuration.
> Consider also during the installation time - how = these DODAG roots will be
> configured?  Must I commission = each device
> to tell it which DODAG it must use for its Object = Function?  How easy will this
> be to change and add in a new = DODAG root
> for the end user if the lighting group = changes??
>
> With respect to Jerry Martocci's - commercial = building requirements - every
> device may need to communicate to = any or
> all of the end devices.  If each device must = establish a DODAG for the other
> 499 devices in a 500 node = network - How much memory
> space will this require for each end = device to maintain?
>
> Keep in mind that the end devices = are very limited processor and memory
> wise.
>
> Not = to mention all of the network maintenance messages that would = need
> to be transmitted to maintain all of these = DODAGs.
>
> Consider the reconvergence time when one device = is turned off and it was in
> the middle of the majority of the = 100+ DODAGS?
>
> In many lighting and building application = an application acknowledgement -
> must be returned {Back down the = DODAG} so . . . the
> requirement is not just getting to the Root = - a return path must also be
> maintained and have a  low = latency path.
>
> Ted = Humpal
>
>
>
>
>
>
> = From:
>
> Kris Pister <pister@eecs.berkeley.edu>=
>
>
> To:
>
> Anders Brandt <abr@sdesigns.dk>
>
>> Cc:
>
> ROLL WG <roll@ietf.org>
>
>
&g= t; Date:
>
> 03/08/2010 01:45 PM
>
>
> = Subject:
>
> Re: [Roll] P2P performance with current RPL = proposal
>
>
>
>
>
>
>
><= BR>> Anders - if we take JP's suggestion to make The Lamp a DODAG = root, and
> take Phoebus' recommendation that we use path = diversity to improve end-
> to-end reliability, do you see a = chance of success?
> In my experience, with diverse paths and = order-minutes updates you get
> extremely high = reliability.
>
> I have no aversion to TTL-limited floods as = a part of a solution either.  I'm
> open to ideas on how to = bring those in as (presumably infrequently used)
> = options.
>
> ksjp
>
> Anders Brandt = wrote:
> Hello
>
> I would like to probe the = temperature of the WG on using DAOs to
> support = P2P.
>
> The building and home application spaces (and maybe = others) have
> a few clearly defined requirements.
> It is = not obvious to me how the current RPL proposal (cRPLp) can
> = satisfy those requirements:
>
>
> In both cases it is = the worst case scenario that hurts:
>
>
> P2P routing = inside the PAN
> = =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
> cRPLp has no way of routing inside the PAN if you need more = than
> one repeater. cRPLp has to go all the way to the top (maybe = 4 hops up)
> and down again (maybe 4 hops down) to get just 2 hops = to the side.
>
> The consequence is high latency and high = levels of background noise
> for nodes just outside the direct = radio range.
> At the same time the risk of meeting a failing link = is 4 times higher =3D>
> latency may be much more than 4 times = larger.
>
> Latency may sound like a minor issue but it = actually translates directly
> into lower battery lifetime. In the = above (very realistic) example,
> the battery lifetime is reduced = to 25% of what it should be.
>
> We have lots of battery = devices sending into the network:
> * PIR sensors turning on = lights
> * Door locks sending alarms
> * Door/window sensors = starting chimes
> * Smoke sensors triggering an alarm = system
>
>
>
>
> Response time
> = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> The latency issue is = important.
> When a user (real human being) presses a light button = the user expects
> the light to turn on.
> cRPLp proposes = that nodes in the tree periodically advertises their
> presence = using DAOs.
> The periodicity is a real beast:
> Thanks to = Trickle, the rate of updates in a (apparently) stable network
> is = low. This is good since it leaves bandwidth for data.
> But it is = not good if existing routes to my lamp fail and I do not get
> new = routes to my lamp until it decides to send out a new DAO.
> My = user will (with a good reason) not tolerate waiting for minutes = for
> the light to turn on.
>
> I have met two = arguments to counter this concern:
>
> A1: Well, your lamp = can always send a DAO when it detects a problem.
>   My = answer:
>   True, except that my lamp does not intend to send = anything
>   so it will never experience any problems from = its side of the network.
>
> A2: Well, you can increase the = DAO rate to sub-second updates.
>   My answer:
>   = Oh no. I get a very high degree of management traffic which
> =   limits my available bandwidth, increases the risk of collisions = and
>   even run the risk of violating EU legislation = requiring me to only
>   transmit in less than 1% of the = time:
>   http://focus.ti.c= om/lit/an/swra048/swra048.pdf
>  868 - 868.6 MHz: = <1%
>
>   Reactiveness is hard to achieve via = polling.
>
>
>
> If you agree that this seems to = be critical issues please raise your
> voice on the = list.
>
> Going forward
> = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>
> We need some = reactive mechanism to reach lamps before the user decides
> to sue = our companies.
> So is this possible? I think so.
>
> = Existing commercial (non-IP) solutions are capable of re-routing = quickly
> if they really have to.
>
> Let me try = scoping the requirements to a potential solution:
> (no different = from the req. docs for home and building)
>
> * P2P routing = in any direction independent of the tree.
>
> * On-demand = P2P route discovery if requested by a real-time critical app.
> =  Data collection apps may be able to just wait for the next DAO = update.
>
> * Limited range of discovery mechanism: max 4 = repeaters.
>   A TTL field may limit the scope of the = repeaters.
>
> * Suboptimal routing and traffic bursts are = accepted in exchange
>   for quick route repair. But only as = an exception.
>
>
> Just as an example, one existing = home control technology uses a
> (source routing) variant of AODV = for quick route repair.
> Nothing comes for free. The price is = flooding - but not just flooding:
> Managed flooding using a = distributed algorithm running in all
> participating = nodes.
> The algorithm dampens the flooding in a time, volume and = range
> perspective.
> Some similar mechanism could be built = into RPL for quick route repair.
>
>
> If anyone have = alternative proposals, please bring it to the list.
> Now is the = time.
>
>
>
> Thanks,
>   = Anders
>
>
>
>
> = _______________________________________________
> Roll mailing = 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

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

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

= ------_=_NextPart_001_01CAC9DE.5BC87B76-- From prvs=690d97458=mukul@uwm.edu Mon Mar 22 10:15: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 464553A69A4 for ; Mon, 22 Mar 2010 10:15:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.876 X-Spam-Level: X-Spam-Status: No, score=-0.876 tagged_above=-999 required=5 tests=[AWL=-1.207, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, J_CHICKENPOX_12=0.6, J_CHICKENPOX_17=0.6, J_CHICKENPOX_51=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 WAmfDBtQbjDe for ; Mon, 22 Mar 2010 10:15:33 -0700 (PDT) Received: from ip2mta.uwm.edu (ip2mta.uwm.edu [129.89.7.20]) by core3.amsl.com (Postfix) with ESMTP id 73EEA3A6942 for ; Mon, 22 Mar 2010 10:15:33 -0700 (PDT) Received: from mta02.pantherlink.uwm.edu ([129.89.7.82]) by ip2mta.uwm.edu with ESMTP; 22 Mar 2010 12:15:50 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by mta02.pantherlink.uwm.edu (Postfix) with ESMTP id 9C8B72C3800F; Mon, 22 Mar 2010 12:15:50 -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 EdHWvcBwLBm6; Mon, 22 Mar 2010 12:15:49 -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 D37792C3800D; Mon, 22 Mar 2010 12:15:49 -0500 (CDT) Date: Mon, 22 Mar 2010 12:15:49 -0500 (CDT) From: Mukul Goyal To: Philip Levis Message-ID: <446723647.8292711269278149739.JavaMail.root@mail02.pantherlink.uwm.edu> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Originating-IP: [129.89.7.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 Subject: Re: [Roll] P2P performance with current RPL proposal X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Mar 2010 17:15:36 -0000 No. As Don pointed out, the route selection is based on an object function = desired by the node initiating the route discovery. The only thing based on= hop count at this point is the scope of discovery - how far the DIS travel= s. I guess this also could be changed to a "discovery scope" function if de= sired. Thanks Mukul ----- Original Message ----- From: "Philip Levis" To: "d sturek" Cc: "Anders Brandt" , "Mukul Goyal" , "Pasc= al Thubert (pthubert)" , "ROLL WG" , "Te= d Humpal" Sent: Monday, March 22, 2010 11:20:46 AM GMT -06:00 US/Canada Central Subject: Re: [Roll] P2P performance with current RPL proposal Just to be sure I am hearing this right -the proposal is to use hopcount-ba= sed route selection?=20 Phil=20 On Mar 22, 2010, at 7:52 AM, "Don Sturek" < d.sturek@att.net > wrote:=20 Hi Anders and Mukul,=20 =C2=A0=20 This is all sounding quite promising in addressing P2P routing in RPL.=C2= =A0 How can we organize a specific proposal we can gain WG approval for?=C2= =A0 I would like to leave Anaheim with an agreed path towards P2P routing s= upport we all believe addresses the Home Automation and Building Controls u= se cases.=20 =C2=A0=20 Don=20 =C2=A0=20 =C2=A0=20 From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of And= ers Brandt=20 Sent: Monday, March 22, 2010 7:46 AM=20 To: Mukul Goyal; Pascal Thubert (pthubert)=20 Cc: ROLL WG; Ted Humpal=20 Subject: Re: [Roll] P2P performance with current RPL proposal=20 =C2=A0=20 Add to this an element of promiscuos listening to dampen the storm =3D> if = node already detected a copy of the DIS with the same TTL (or lower) - do n= ot forward the DIS. Then you start getting closer to something.=20 =C2=A0=20 Oh - and by the way - record the source route on the way ;-)=20 =C2=A0=20 - Anders=20 =C2=A0=20 Fra: roll-bounces@ietf.org p=C3=A5 vegne af Mukul Goyal=20 Sendt: ma 22-03-2010 01:47=20 Til: Pascal Thubert (pthubert)=20 Cc: ROLL WG; Ted Humpal=20 Emne: Re: [Roll] P2P performance with current RPL proposal=20 Hi Pascal=20 Thanks for your comments (let me send my response in the next email).=20 Based on further thoughts, it seems to me that a DAG based P2P solution wou= ld work if we do the following:=20 (a) allowing multicast DIS messages to spread to an originator-specified nu= mber of hops and=20 (b) allowing nodes to join a DAG temporarily and leave it if there is not s= ufficient =E2=80=9Crouting interest=E2=80=9D in being part of the DAG.=20 With these points in mind, a P2P scheme could work as follows:=20 1. When a node wants to join a DODAG(D,F), where D is the DODAG's root and = F is the OF being used, it does the following:=20 =C2=A0=C2=A0=C2=A0 a. Initiates a discovery table entry for DODAG(D,F). The= discovery table entries are removed after a certain lifetime.=20 =C2=A0=C2=A0=C2=A0 b. sends out a DIS via link-local multicast asking speci= fically for information about DODAG(D,F). It also lists in the DIS the numb= er of hops the DIS can travel.=20 2. On receiving=C2=A0 a DIS, a node does the following:=20 =C2=A0=C2=A0=C2=A0 a.if it does not know about DODAG(D,F) and the DIS hop l= imit is not yet reached=20 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 i. Initiates a discovery table e= ntry for DODAG(D,F). This entry maintains information about the nodes from = whom the DIS were received.=20 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ii. sends out the DIS (via link-= local multicast with trickle controlled timing) further.=20 =C2=A0=C2=A0=C2=A0 b. If it is already a part of DODAG(D,F) or is node D it= self=20 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 i. Send out a DIO about DODAG(D,= F) to the node from whom the DIS was received.=20 3. On receiving a DIO about DODAG(D,F), a node does the following:=20 =C2=A0=C2=A0=C2=A0 a. Ignore the DIO if the node does not have a discovery = table entry for DODAG(D,F)=20 =C2=A0=C2=A0=C2=A0 b. Otherwise, the node joins the DODAG(D,F) (if not alre= ady part of it) or updates its parent set in DODAG(D,F) and sends the DIO b= y unicast to the nodes that had sent it the DIS.=20 4. Once, the node is part of the DODAG(D,F), it maintains a =E2=80=9Croutin= g interest=E2=80=9D for the DODAG in the following manner:=20 =C2=A0=C2=A0=C2=A0 a. Routing interest is a value between 0 and 1=20 =C2=A0=C2=A0=C2=A0 b. Routing interest is 1 if the node recently forwarded = a packet along the DODAG(D,F)=20 =C2=A0=C2=A0=C2=A0 c. Otherwise, the routing interest is x*maximum routing = interest of the neighbors in DODAG(D,F), where x is a fraction. The node co= mes to know of neighbor=E2=80=99s routing interest via the neighbor=E2=80= =99s DIO.=20 =C2=A0=C2=A0=C2=A0 d. A node leaves a DODAG if its routing interest in the = DODAG goes below a threshold.=20 Thanks=20 Mukul=20 ----- Original Message -----=20 From: "Pascal Thubert (pthubert)" < pthubert@cisco.com >=20 To: "Mukul Goyal" < mukul@uwm.edu >=20 Cc: "ROLL WG" < roll@ietf.org >, "Ted Humpal" < Ted.Humpal@jci.com >, "robe= rt cragie" < robert.cragie@gridmerge.com >=20 Sent: Friday, March 19, 2010 11:20:58 AM GMT -06:00 US/Canada Central=20 Subject: RE: [Roll] P2P performance with current RPL proposal=20 Hi Mukul=20 > Here I have attempted to formulate a simple DV algorithm in RPL/DAG terms= .=20 > I will appreciate it if you could let me know about your objections to th= is=20 > proposal:=20 [Pascal] It's cool that you do it is the first impression.=20 > Node A needs to reach a destination D. Node A initiates a discovery DAG= =20 > towards D. As the DIOs reach D, it sends a DAO back to selected parents. = As=20 > the DAO travels towards node A, in-route nodes store the cost to reach D.= =20 >=20 > When node B needs to reach D, it similarly initiates a discovery dag. Dur= ing=20 > this discovery, when a DIO reaches a node C that maintains a cost to reac= h D,=20 > node C responds back with a DAO that travels towards B and stores in in-= =20 > route nodes the cost to reach D.=20 [Pascal]=C2=A0 understand that you're trying to make RPL even closer to AOD= V.=20 I agree we need to gather as much as we can from that work.=20 For the specifics of your proposal:=20 - B-C might be orthogonal to A-D so that B/C\D forms an angle. You do not e= nd up with the best path that you're looking for.=20 - there might be multiple C's. Which one is the right one?=20 - RPL does not allow packets to switch instances. Following multiple DAGs i= s the recipe for loops - unless you have them strictly ordered by some mean= s like the RPL sequence between iterations, more specific routes, blah blah= ...)=20 - the A to D path is optimized for a certain constraint. You seem to imply = that the B to D path has the same constraints and metrics so we can compare= apple to apple. Because this is a very delicate operation, RPL has introdu= ced the Rank, which has the right properties to make that comparison effici= ently.So for RPL, the loop avoidance metric is the Rank, and it is only val= id within an iteration.=20 - A P2P path does not come out of the blue. There must be some provisionnin= g system that determines that those nodes, A and B, are very special so the= y need a P2P optimization, with a given special OF, and that they both need= to talk to D. Well, if that's so, the most economical is for that system t= o fork the DAG out of D, with dual targets A and B. There you obtain the sh= ortest path for both A-D and B-D for the cost of a single flooding.=20 I see that you're trying to get the idea to work better, and I hope we find= a way to do so, maybe along your lines if we can solve the issues above. B= ut before we get there, we need to agree that this is the path we wish to t= ake.=20 Cheers,=20 Pascal=20 >=20 > ----- Original Message -----=20 > From: "Pascal Thubert (pthubert)" < pthubert@cisco.com >=20 > To: "robert cragie" < robert.cragie@gridmerge.com >=20 > Cc: "ROLL WG" < roll@ietf.org >, "Ted Humpal" < Ted.Humpal@jci.com >=20 > Sent: Thursday, March 18, 2010 9:23:14 PM GMT -06:00 US/Canada Central=20 > Subject: Re: [Roll] P2P performance with current RPL proposal=20 >=20 >=20 >=20 >=20 >=20 > Hi Robert=C2=A0:=20 >=20 >=20 >=20 > At least from a distance, the proposed mechanism emulates AODV, with the= =20 > DIO as RREQ and the DAO as RREP. So if we decide to dig along those lines= ,=20 > we=E2=80=99ll certainly appreciate help from MANET experts. I=E2=80=99d s= ay that if you=20 > already have RPL for P2MP and MP2P, the proposed extension are probably= =20 > simpler to add than doing AODV from scratch.=20 >=20 >=20 >=20 > For the setup, the major differences are that we build a DAG and that we = can=20 > indicate multiple targets. If you look at it, the DAG capability is a MUS= T for=20 > RPL, and I have not seen that this MUST goes away for P2P flows. The=20 > multiple targets is something that appears in a number of use cases and i= t=20 > seems more economical to build a single DAG for multiple targets when=20 > possible.=20 >=20 >=20 >=20 > For the maintenance, the major differences are that we have the DAG as=20 > first line of defense, and the RPL detection to stimulate the local repai= r.=20 >=20 >=20 >=20 > About your questions:=20 >=20 >=20 >=20 > The DODAG root is the one that spawns the DAG. The targets can reach the= =20 > root because the root advertises itself in the DIO. The idea is that the = root ID=20 > is the address that the targets need to talk to. If needed, the root can = also=20 > advertise a prefix that it can reach and that the targets need to reach t= oo.=20 >=20 >=20 >=20 > All the intermediate nodes that are confirmed by the DAO need to retain a= t=20 > least info about the DAG. That enables the targets to reach the root. The= =20 > flooding should cost about the same as that of AODV but the RPL way will= =20 > require more states in the nodes on the way if the OF requires a DAG.=20 >=20 >=20 >=20 > The way back (down) can be stateful of stateless, depending on which DAO= =20 > we=E2=80=99re using. With fully stateful DAO, we are really in AODV-land.= With=20 > stateless, we could drift into DSR-land for that direction. Which limits = we=20 > place to keep it simple will be determined by the resolution of issue #26= I=20 > guess=E2=80=A6=20 >=20 >=20 >=20 > And please, no apologize or on one will dare post anything anymore. Your= =20 > questions are fully relevant and at the core of the discussion.=20 >=20 >=20 >=20 > I hope we can talk in Anaheim for sure,=20 >=20 >=20 >=20 >=20 > Pascal=20 >=20 >=20 >=20 >=20 >=20 >=20 > From: Robert Cragie [ mailto:robert.cragie@gridmerge.com ]=20 > Sent: Monday, March 15, 2010 11:27 AM=20 > To: Pascal Thubert (pth ubert)=20 > Cc: Ted.Humpal@jci.com ; ROLL WG=20 > Subject: Re: [Roll] P2P performance with current RPL proposal=20 >=20 >=20 >=20 > Hi Pascal,=20 >=20 > So in your slideware T can end up talking to R (DODAG root) through the= =20 > DODAG. So are you proposing that all potential targets can act as a DODAG= =20 > root? And therefore all intermediates have to retain DIO propagation=20 > support for that DODAG as well? This may work for limited P2P but seems= =20 > less efficient than simple distance vector flooding RREQ/RREP like AODV o= r=20 > DYMO for generic P2P. What about R to T (or anyone else for that matter)?= =20 > Do we source route, maintain state, some undefined hybrid of the two?=20 >=20 > I apologise if some of these questions have been answered in detail in ea= rlier=20 > reflector posts but I have only recently started to concentrate my effort= s on=20 > RPL and have 82 pages to wade through :-). I look forward to a productive= =20 > session in Anaheim.=20 >=20 > Robert=20 >=20 >=20 > Robert Cragie (Pacific Gas & Electric)=20 >=20 > Gridmerge Ltd.=20 > 89 Greenfield Crescent,=20 > Wakefield, WF4 4WA, UK=20 > +44 (0) 1924 910888=20 > http://www.gridmerge.com=20 >=20 >=20 >=20 > Pascal Thubert (pthubert) wrote:=20 >=20 > HI Robert=C2=A0:=20 >=20 >=20 >=20 > I respectfully have to disagree.=20 >=20 >=20 >=20 > My understanding is that we are considering a limited set of P2P pairs, f= or=20 > which the specific path that we need to create might have to obey specifi= c=20 > constraints.=20 >=20 > So it makes sense to use an on-demand technique, probably inspired by the= =20 > MANET Reactive protocols.=20 >=20 >=20 >=20 > As it goes, those protocols usually use flooding for a node to locate ano= ther.=20 > Forking a DAG is just another flooding. It does not take a lot of additio= n to the=20 > existing DIO for a root to use RPL to build a DAG that contains one or mu= ltiple=20 > Targets as leaves, under a set of constraints expressed as an objective= =20 > function. Please find attached a slideware that illustrates that.=20 >=20 >=20 >=20 >=20 > Pascal=20 >=20 >=20 >=20 >=20 >=20 >=20 > From: roll-bounces@ietf.org [ mailto:roll-bounces@ietf.org ] On Behalf Of= =20 > Robert Cragie=20 > Sent: Thursday, March 11, 2010 2:43 PM=20 > To: Ted.Humpal@jci.com=20 > Cc: ROLL WG=20 > Subject: Re: [Roll] P2P performance with current RPL proposal=20 >=20 >=20 >=20 > I agree with Ted's comments below. Creating a DODAG for every reachable= =20 > node as a root seems a very inefficient approach compared to alternative= =20 > routing algorithms. I am concerned that RPL does not actually meet the=20 > original requirements in I-D.ietf-roll-building-routing-reqs, I-D.ietf-ro= ll-home-=20 > routing-reqs, RFC5673 and RFC5548. The traffic pattern requirement for a= =20 > sink node features prominently in only two of those documents. Even in th= is=20 > case, as Ted points out, communication is likely to be bidirectional (e.g= . end-=20 > to-end acks.) therefore the DODAG approach is fundamentally asymmetric,= =20 > especially if no intermediate storage is allowed for destination routes a= nd=20 > source routing has to be used.=20 >=20 > Also, RPL seems highly complex for what are constrained nodes in terms of= =20 > memory as well as power and bandwidth. The RPL draft as it stands is 82= =20 > pages long and that doesn't include text about the objective function.=20 >=20 > Robert=20 >=20 >=20 > Robert Cragie (Pacific Gas & Electric)=20 >=20 > Gridmerge Ltd.=20 > 89 Greenfield Crescent,=20 > Wakefield, WF4 4WA, UK=20 > +44 (0) 1924 910888=20 > http://www.gridmerge.com=20 >=20 >=20 >=20 > Ted.Humpal@jci.com wrote:=20 >=20 >=20 > A concern also will be how much overhead (memory space) will be required= =20 > for a DODAG Root?=20 >=20 > and based on the first question how many DODAG roots a lamp may need to= =20 > be a member of?=20 >=20 > For example in lighting =C2=A0a single lamp may be a root for a single sw= itch (1=20 > DODAG root), =C2=A0this lamp / luminaire may also=20 > be a member of another group - - =C2=A0which could be all lights on the f= loor (2nd=20 > DODAG root), and a third group=20 > of all the lights in the building. =C2=A0There can be many more specialit= y groups=20 > associated based on the building configuration.=20 > Consider also during the installation time - how these DODAG roots will b= e=20 > configured? =C2=A0Must I commission each device=20 > to tell it which DODAG it must use for its Object Function? =C2=A0How eas= y will this=20 > be to change and add in a new DODAG root=20 > for the end user if the lighting group changes??=20 >=20 > With respect to Jerry Martocci's - commercial building requirements - eve= ry=20 > device may need to communicate to any or=20 > all of the end devices. =C2=A0If each device must establish a DODAG for t= he other=20 > 499 devices in a 500 node network - How much memory=20 > space will this require for each end device to maintain?=20 >=20 > Keep in mind that the end devices are very limited processor and memory= =20 > wise.=20 >=20 > Not to mention all of the network maintenance messages that would need=20 > to be transmitted to maintain all of these DODAGs.=20 >=20 > Consider the reconvergence time when one device is turned off and it was = in=20 > the middle of the majority of the 100+ DODAGS?=20 >=20 > In many lighting and building application an application acknowledgement = -=20 > must be returned {Back down the DODAG} so . . . the=20 > requirement is not just getting to the Root - a return path must also be= =20 > maintained and have a =C2=A0low latency path.=20 >=20 > Ted Humpal=20 >=20 >=20 >=20 >=20 >=20 >=20 > From:=20 >=20 > Kris Pister < pister@eecs.berkeley.edu >=20 >=20 >=20 > To:=20 >=20 > Anders Brandt < abr@sdesigns.dk >=20 >=20 >=20 > Cc:=20 >=20 > ROLL WG < roll@ietf.org >=20 >=20 >=20 > Date:=20 >=20 > 03/08/2010 01:45 PM=20 >=20 >=20 > Subject:=20 >=20 > Re: [Roll] P2P performance with current RPL proposal=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > Anders - if we take JP's suggestion to make The Lamp a DODAG root, and=20 > take Phoebus' recommendation that we use path diversity to improve end-= =20 > to-end reliability, do you see a chance of success?=20 > In my experience, with diverse paths and order-minutes updates you get=20 > extremely high reliability.=20 >=20 > I have no aversion to TTL-limited floods as a part of a solution either. = =C2=A0I'm=20 > open to ideas on how to bring those in as (presumably infrequently used)= =20 > options.=20 >=20 > ksjp=20 >=20 > Anders Brandt wrote:=20 > Hello=20 >=20 > I would like to probe the temperature of the WG on using DAOs to=20 > support P2P.=20 >=20 > The building and home application spaces (and maybe others) have=20 > a few clearly defined requirements.=20 > It is not obvious to me how the current RPL proposal (cRPLp) can=20 > satisfy those requirements:=20 >=20 >=20 > In both cases it is the worst case scenario that hurts:=20 >=20 >=20 > P2P routing inside the PAN=20 > =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=20 > cRPLp has no way of routing inside the PAN if you need more than=20 > one repeater. cRPLp has to go all the way to the top (maybe 4 hops up)=20 > and down again (maybe 4 hops down) to get just 2 hops to the side.=20 >=20 > The consequence is high latency and high levels of background noise=20 > for nodes just outside the direct radio range.=20 > At the same time the risk of meeting a failing link is 4 times higher =3D= >=20 > latency may be much more than 4 times larger.=20 >=20 > Latency may sound like a minor issue but it actually translates directly= =20 > into lower battery lifetime. In the above (very realistic) example,=20 > the battery lifetime is reduced to 25% of what it should be.=20 >=20 > We have lots of battery devices sending into the network:=20 > * PIR sensors turning on lights=20 > * Door locks sending alarms=20 > * Door/window sensors starting chimes=20 > * Smoke sensors triggering an alarm system=20 >=20 >=20 >=20 >=20 > Response time=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=20 > The latency issue is important.=20 > When a user (real human being) presses a light button the user expects=20 > the light to turn on.=20 > cRPLp proposes that nodes in the tree periodically advertises their=20 > presence using DAOs.=20 > The periodicity is a real beast:=20 > Thanks to Trickle, the rate of updates in a (apparently) stable network= =20 > is low. This is good since it leaves bandwidth for data.=20 > But it is not good if existing routes to my lamp fail and I do not get=20 > new routes to my lamp until it decides to send out a new DAO.=20 > My user will (with a good reason) not tolerate waiting for minutes for=20 > the light to turn on.=20 >=20 > I have met two arguments to counter this concern:=20 >=20 > A1: Well, your lamp can always send a DAO when it detects a problem.=20 > =C2=A0 My answer:=20 > =C2=A0 True, except that my lamp does not intend to send anything=20 > =C2=A0 so it will never experience any problems from its side of the netw= ork.=20 >=20 > A2: Well, you can increase the DAO rate to sub-second updates.=20 > =C2=A0 My answer:=20 > =C2=A0 Oh no. I get a very high degree of management traffic which=20 > =C2=A0 limits my available bandwidth, increases the risk of collisions an= d=20 > =C2=A0 even run the risk of violating EU legislation requiring me to only= =20 > =C2=A0 transmit in less than 1% of the time:=20 > =C2=A0 http://focus.ti.com/lit/an/swra048/swra048.pdf=20 > =C2=A0868 - 868.6 MHz: <1%=20 >=20 > =C2=A0 Reactiveness is hard to achieve via polling.=20 >=20 >=20 >=20 > If you agree that this seems to be critical issues please raise your=20 > voice on the list.=20 >=20 > Going forward=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=20 >=20 > We need some reactive mechanism to reach lamps before the user decides=20 > to sue our companies.=20 > So is this possible? I think so.=20 >=20 > Existing commercial (non-IP) solutions are capable of re-routing quickly= =20 > if they really have to.=20 >=20 > Let me try scoping the requirements to a potential solution:=20 > (no different from the req. docs for home and building)=20 >=20 > * P2P routing in any direction independent of the tree.=20 >=20 > * On-demand P2P route discovery if requested by a real-time critical app.= =20 > =C2=A0Data collection apps may be able to just wait for the next DAO upda= te.=20 >=20 > * Limited range of discovery mechanism: max 4 repeaters.=20 > =C2=A0 A TTL field may limit the scope of the repeaters.=20 >=20 > * Suboptimal routing and traffic bursts are accepted in exchange=20 > =C2=A0 for quick route repair. But only as an exception.=20 >=20 >=20 > Just as an example, one existing home control technology uses a=20 > (source routing) variant of AODV for quick route repair.=20 > Nothing comes for free. The price is flooding - but not just flooding:=20 > Managed flooding using a distributed algorithm running in all=20 > participating nodes.=20 > The algorithm dampens the flooding in a time, volume and range=20 > perspective.=20 > Some similar mechanism could be built into RPL for quick route repair.=20 >=20 >=20 > If anyone have alternative proposals, please bring it to the list.=20 > Now is the time.=20 >=20 >=20 >=20 > Thanks,=20 > =C2=A0 Anders=20 >=20 >=20 >=20 >=20 > _______________________________________________=20 > Roll mailing list=20 > Roll@ietf.org=20 > https://www.ietf.org/mailman/listinfo/roll=20 > =C2=A0_______________________________________________=20 > Roll mailing list=20 > Roll@ietf.org=20 > https://www.ietf.org/mailman/listinfo/roll=20 >=20 >=20 >=20 >=20 >=20 > =C2=A0 _______________________________________________ Roll mailing=20 > list Roll@ietf.org 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 From robert.cragie@gridmerge.com Mon Mar 22 12:06: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 03CF93A67F9 for ; Mon, 22 Mar 2010 12:06:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.821 X-Spam-Level: X-Spam-Status: No, score=0.821 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, DNS_FROM_OPENWHOIS=1.13, HTML_MESSAGE=0.001, J_CHICKENPOX_12=0.6, J_CHICKENPOX_17=0.6, J_CHICKENPOX_51=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CNhNVfQjJkFW for ; Mon, 22 Mar 2010 12:06:32 -0700 (PDT) Received: from mail78.extendcp.co.uk (mail78.extendcp.co.uk [79.170.40.78]) by core3.amsl.com (Postfix) with ESMTP id 896343A6784 for ; Mon, 22 Mar 2010 12:06:31 -0700 (PDT) Received: from 72-254-89-212.client.stsn.net ([72.254.89.212] helo=[10.7.39.204]) by mail78.extendcp.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.70) id 1NtmxV-0007Fg-JB; Mon, 22 Mar 2010 19:06:42 +0000 Message-ID: <4BA7BFB9.10501@gridmerge.com> Date: Mon, 22 Mar 2010 19:06:33 +0000 From: Robert Cragie Organization: Gridmerge Ltd. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.8) Gecko/20100227 Lightning/1.0b1 Thunderbird/3.0.3 MIME-Version: 1.0 To: Mukul Goyal References: <446723647.8292711269278149739.JavaMail.root@mail02.pantherlink.uwm.edu> In-Reply-To: <446723647.8292711269278149739.JavaMail.root@mail02.pantherlink.uwm.edu> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms010803030503010605090506" Cc: roll Subject: Re: [Roll] P2P performance with current RPL proposal 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, 22 Mar 2010 19:06:36 -0000 This is a cryptographically signed message in MIME format. --------------ms010803030503010605090506 Content-Type: multipart/alternative; boundary="------------090404020209050102090200" This is a multi-part message in MIME format. --------------090404020209050102090200 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable I think the idea of multiple DODAGs could work for P2P if it is possible = to provide some sort of pruned DODAGs. I think the DIS mechanism below=20 could work but I think using DIOs to me seems more orthogonal and symmetr= ic. I think the solution could be to use a 'targeted' DIO which can be=20 emitted and propagated immediately. Consider A trying to communicate with= B: 1. A does not have a routing table entry for B 2. A (now effectively a DODAG root) sends a DIO targeted at B to all routers multicast immediately (with jitter) 3. If a router hears it and has a DODAG entry to B it can then be routed as normal to B 4. If a router hears it and doesn't have a DODAG entry to B, it will propagate it all routers multicast (with a TTL) immediately (with jitter) 5. When B hears the DIO, it responds with a DAO destined for A and sent back along the DODAG to A. 6. Intermediate routers can set up the route to B if desired or A can use source routing. Some points: * The standard DAG processing of rank relative to A using the OF would assure propagation of the targeted DIO away from A and formation of a DAG back to A * Routers which do not see the corresponding DAO would time out and discard the DODAG entry for A. This would give the ability to create a 'pruned' DODAG thus giving the=20 P2P needed without all routers having to set up DODAG entries back to A. = As far as I can see, this stays pretty close to RPL but adds the idea of = a DIO target and an alternative delivery mechanism as opposed to trickle = timer (even then, it is really a subset of a trickle timer). As always, I am sure there are still some other issues to consider. Robert Robert Cragie (Pacific Gas & Electric) Gridmerge Ltd. 89 Greenfield Crescent, Wakefield, WF4 4WA, UK +44 (0) 1924 910888 http://www.gridmerge.com On 22/03/2010 5:15 PM, Mukul Goyal wrote: > No. As Don pointed out, the route selection is based on an object funct= ion desired by the node initiating the route discovery. The only thing ba= sed on hop count at this point is the scope of discovery - how far the DI= S travels. I guess this also could be changed to a "discovery scope" func= tion if desired. > > Thanks > Mukul > > ----- Original Message ----- > From: "Philip Levis" > To: "d sturek" > Cc: "Anders Brandt", "Mukul Goyal", "Pa= scal Thubert (pthubert)", "ROLL WG", "= Ted Humpal" > Sent: Monday, March 22, 2010 11:20:46 AM GMT -06:00 US/Canada Central > Subject: Re: [Roll] P2P performance with current RPL proposal > > > Just to be sure I am hearing this right -the proposal is to use hopcoun= t-based route selection? > > > Phil > > On Mar 22, 2010, at 7:52 AM, "Don Sturek"< d.sturek@att.net > wrote:= > > > > > > > > > Hi Anders and Mukul, > > =20 > > This is all sounding quite promising in addressing P2P routing in RPL. = How can we organize a specific proposal we can gain WG approval for? I = would like to leave Anaheim with an agreed path towards P2P routing suppo= rt we all believe addresses the Home Automation and Building Controls use= cases. > > =20 > > Don > > =20 > > =20 > > > > From:roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of= Anders Brandt > Sent: Monday, March 22, 2010 7:46 AM > To: Mukul Goyal; Pascal Thubert (pthubert) > Cc: ROLL WG; Ted Humpal > Subject: Re: [Roll] P2P performance with current RPL proposal > > =20 > > > > Add to this an element of promiscuos listening to dampen the storm =3D>= if node already detected a copy of the DIS with the same TTL (or lower)= - do not forward the DIS. Then you start getting closer to something. > > > =20 > > > Oh - and by the way - record the source route on the way ;-) > > > =20 > > > - Anders > > > =20 > > > > Fra:roll-bounces@ietf.org p=C3=A5 vegne af Mukul Goyal > Sendt: ma 22-03-2010 01:47 > Til: Pascal Thubert (pthubert) > Cc: ROLL WG; Ted Humpal > Emne: Re: [Roll] P2P performance with current RPL proposal > > > Hi Pascal > > Thanks for your comments (let me send my response in the next email). > > Based on further thoughts, it seems to me that a DAG based P2P solution= would work if we do the following: > > (a) allowing multicast DIS messages to spread to an originator-specifie= d number of hops and > (b) allowing nodes to join a DAG temporarily and leave it if there is n= ot sufficient =E2=80=9Crouting interest=E2=80=9D in being part of the DAG= =2E > > With these points in mind, a P2P scheme could work as follows: > > 1. When a node wants to join a DODAG(D,F), where D is the DODAG's root = and F is the OF being used, it does the following: > a. Initiates a discovery table entry for DODAG(D,F). The discovery= table entries are removed after a certain lifetime. > b. sends out a DIS via link-local multicast asking specifically fo= r information about DODAG(D,F). It also lists in the DIS the number of ho= ps the DIS can travel. > > 2. On receiving a DIS, a node does the following: > a.if it does not know about DODAG(D,F) and the DIS hop limit is no= t yet reached > i. Initiates a discovery table entry for DODAG(D,F). This entr= y maintains information about the nodes from whom the DIS were received. > ii. sends out the DIS (via link-local multicast with trickle c= ontrolled timing) further. > b. If it is already a part of DODAG(D,F) or is node D itself > i. Send out a DIO about DODAG(D,F) to the node from whom the D= IS was received. > > 3. On receiving a DIO about DODAG(D,F), a node does the following: > a. Ignore the DIO if the node does not have a discovery table entr= y for DODAG(D,F) > b. Otherwise, the node joins the DODAG(D,F) (if not already part o= f it) or updates its parent set in DODAG(D,F) and sends the DIO by unicas= t to the nodes that had sent it the DIS. > > 4. Once, the node is part of the DODAG(D,F), it maintains a =E2=80=9Cro= uting interest=E2=80=9D for the DODAG in the following manner: > a. Routing interest is a value between 0 and 1 > b. Routing interest is 1 if the node recently forwarded a packet a= long the DODAG(D,F) > c. Otherwise, the routing interest is x*maximum routing interest o= f the neighbors in DODAG(D,F), where x is a fraction. The node comes to k= now of neighbor=E2=80=99s routing interest via the neighbor=E2=80=99s DIO= =2E > d. A node leaves a DODAG if its routing interest in the DODAG goes= below a threshold. > > Thanks > Mukul > > ----- Original Message ----- > From: "Pascal Thubert (pthubert)"< pthubert@cisco.com > > To: "Mukul Goyal"< mukul@uwm.edu > > Cc: "ROLL WG"< roll@ietf.org >, "Ted Humpal"< Ted.Humpal@jci.com >,= "robert cragie"< robert.cragie@gridmerge.com > > Sent: Friday, March 19, 2010 11:20:58 AM GMT -06:00 US/Canada Central > Subject: RE: [Roll] P2P performance with current RPL proposal > > Hi Mukul > =20 >> Here I have attempted to formulate a simple DV algorithm in RPL/DAG te= rms. >> I will appreciate it if you could let me know about your objections to= this >> proposal: >> =20 > [Pascal] It's cool that you do it is the first impression. > > =20 >> Node A needs to reach a destination D. Node A initiates a discovery DA= G >> towards D. As the DIOs reach D, it sends a DAO back to selected parent= s. As >> the DAO travels towards node A, in-route nodes store the cost to reach= D. >> >> When node B needs to reach D, it similarly initiates a discovery dag. = During >> this discovery, when a DIO reaches a node C that maintains a cost to r= each D, >> node C responds back with a DAO that travels towards B and stores in i= n- >> route nodes the cost to reach D. >> =20 > [Pascal] understand that you're trying to make RPL even closer to AODV= =2E > I agree we need to gather as much as we can from that work. > > For the specifics of your proposal: > > - B-C might be orthogonal to A-D so that B/C\D forms an angle. You do n= ot end up with the best path that you're looking for. > > - there might be multiple C's. Which one is the right one? > > - RPL does not allow packets to switch instances. Following multiple DA= Gs is the recipe for loops - unless you have them strictly ordered by som= e means like the RPL sequence between iterations, more specific routes, b= lah blah...) > > - the A to D path is optimized for a certain constraint. You seem to im= ply that the B to D path has the same constraints and metrics so we can c= ompare apple to apple. Because this is a very delicate operation, RPL has= introduced the Rank, which has the right properties to make that compari= son efficiently.So for RPL, the loop avoidance metric is the Rank, and it= is only valid within an iteration. > > - A P2P path does not come out of the blue. There must be some provisio= nning system that determines that those nodes, A and B, are very special = so they need a P2P optimization, with a given special OF, and that they b= oth need to talk to D. Well, if that's so, the most economical is for tha= t system to fork the DAG out of D, with dual targets A and B. There you o= btain the shortest path for both A-D and B-D for the cost of a single flo= oding. > > I see that you're trying to get the idea to work better, and I hope we = find a way to do so, maybe along your lines if we can solve the issues ab= ove. But before we get there, we need to agree that this is the path we w= ish to take. > > Cheers, > > Pascal > > > =20 >> ----- Original Message ----- >> From: "Pascal Thubert (pthubert)"< pthubert@cisco.com > >> To: "robert cragie"< robert.cragie@gridmerge.com > >> Cc: "ROLL WG"< roll@ietf.org >, "Ted Humpal"< Ted.Humpal@jci.com >= >> Sent: Thursday, March 18, 2010 9:23:14 PM GMT -06:00 US/Canada Central= >> Subject: Re: [Roll] P2P performance with current RPL proposal >> >> >> >> >> >> Hi Robert : >> >> >> >> At least from a distance, the proposed mechanism emulates AODV, with t= he >> DIO as RREQ and the DAO as RREP. So if we decide to dig along those li= nes, >> we=E2=80=99ll certainly appreciate help from MANET experts. I=E2=80=99= d say that if you >> already have RPL for P2MP and MP2P, the proposed extension are probabl= y >> simpler to add than doing AODV from scratch. >> >> >> >> For the setup, the major differences are that we build a DAG and that = we can >> indicate multiple targets. If you look at it, the DAG capability is a = MUST for >> RPL, and I have not seen that this MUST goes away for P2P flows. The >> multiple targets is something that appears in a number of use cases an= d it >> seems more economical to build a single DAG for multiple targets when >> possible. >> >> >> >> For the maintenance, the major differences are that we have the DAG as= >> first line of defense, and the RPL detection to stimulate the local re= pair. >> >> >> >> About your questions: >> >> >> >> The DODAG root is the one that spawns the DAG. The targets can reach t= he >> root because the root advertises itself in the DIO. The idea is that t= he root ID >> is the address that the targets need to talk to. If needed, the root c= an also >> advertise a prefix that it can reach and that the targets need to reac= h too. >> >> >> >> All the intermediate nodes that are confirmed by the DAO need to retai= n at >> least info about the DAG. That enables the targets to reach the root. = The >> flooding should cost about the same as that of AODV but the RPL way wi= ll >> require more states in the nodes on the way if the OF requires a DAG. >> >> >> >> The way back (down) can be stateful of stateless, depending on which D= AO >> we=E2=80=99re using. With fully stateful DAO, we are really in AODV-la= nd. With >> stateless, we could drift into DSR-land for that direction. Which limi= ts we >> place to keep it simple will be determined by the resolution of issue = #26 I >> guess=E2=80=A6 >> >> >> >> And please, no apologize or on one will dare post anything anymore. Yo= ur >> questions are fully relevant and at the core of the discussion. >> >> >> >> I hope we can talk in Anaheim for sure, >> >> >> >> >> Pascal >> >> >> >> >> >> >> From: Robert Cragie [mailto:robert.cragie@gridmerge.com ] >> Sent: Monday, March 15, 2010 11:27 AM >> To: Pascal Thubert (pth ubert) >> Cc:Ted.Humpal@jci.com ; ROLL WG >> Subject: Re: [Roll] P2P performance with current RPL proposal >> >> >> >> Hi Pascal, >> >> So in your slideware T can end up talking to R (DODAG root) through th= e >> DODAG. So are you proposing that all potential targets can act as a DO= DAG >> root? And therefore all intermediates have to retain DIO propagation >> support for that DODAG as well? This may work for limited P2P but seem= s >> less efficient than simple distance vector flooding RREQ/RREP like AOD= V or >> DYMO for generic P2P. What about R to T (or anyone else for that matte= r)? >> Do we source route, maintain state, some undefined hybrid of the two? >> >> I apologise if some of these questions have been answered in detail in= earlier >> reflector posts but I have only recently started to concentrate my eff= orts on >> RPL and have 82 pages to wade through :-). I look forward to a product= ive >> session in Anaheim. >> >> Robert >> >> >> Robert Cragie (Pacific Gas& Electric) >> >> Gridmerge Ltd. >> 89 Greenfield Crescent, >> Wakefield, WF4 4WA, UK >> +44 (0) 1924 910888 >> http://www.gridmerge.com >> >> >> >> Pascal Thubert (pthubert) wrote: >> >> HI Robert : >> >> >> >> I respectfully have to disagree. >> >> >> >> My understanding is that we are considering a limited set of P2P pairs= , for >> which the specific path that we need to create might have to obey spec= ific >> constraints. >> >> So it makes sense to use an on-demand technique, probably inspired by = the >> MANET Reactive protocols. >> >> >> >> As it goes, those protocols usually use flooding for a node to locate = another. >> Forking a DAG is just another flooding. It does not take a lot of addi= tion to the >> existing DIO for a root to use RPL to build a DAG that contains one or= multiple >> Targets as leaves, under a set of constraints expressed as an objectiv= e >> function. Please find attached a slideware that illustrates that. >> >> >> >> >> Pascal >> >> >> >> >> >> >> From:roll-bounces@ietf.org [mailto:roll-bounces@ietf.org ] On Behalf= Of >> Robert Cragie >> Sent: Thursday, March 11, 2010 2:43 PM >> To:Ted.Humpal@jci.com >> Cc: ROLL WG >> Subject: Re: [Roll] P2P performance with current RPL proposal >> >> >> >> I agree with Ted's comments below. Creating a DODAG for every reachabl= e >> node as a root seems a very inefficient approach compared to alternati= ve >> routing algorithms. I am concerned that RPL does not actually meet the= >> original requirements in I-D.ietf-roll-building-routing-reqs, I-D.ietf= -roll-home- >> routing-reqs, RFC5673 and RFC5548. The traffic pattern requirement for= a >> sink node features prominently in only two of those documents. Even in= this >> case, as Ted points out, communication is likely to be bidirectional (= e.g. end- >> to-end acks.) therefore the DODAG approach is fundamentally asymmetric= , >> especially if no intermediate storage is allowed for destination route= s and >> source routing has to be used. >> >> Also, RPL seems highly complex for what are constrained nodes in terms= of >> memory as well as power and bandwidth. The RPL draft as it stands is 8= 2 >> pages long and that doesn't include text about the objective function.= >> >> Robert >> >> >> Robert Cragie (Pacific Gas& Electric) >> >> Gridmerge Ltd. >> 89 Greenfield Crescent, >> Wakefield, WF4 4WA, UK >> +44 (0) 1924 910888 >> http://www.gridmerge.com >> >> >> >> Ted.Humpal@jci.com wrote: >> >> >> A concern also will be how much overhead (memory space) will be requir= ed >> for a DODAG Root? >> >> and based on the first question how many DODAG roots a lamp may need t= o >> be a member of? >> >> For example in lighting a single lamp may be a root for a single swit= ch (1 >> DODAG root), this lamp / luminaire may also >> be a member of another group - - which could be all lights on the flo= or (2nd >> DODAG root), and a third group >> of all the lights in the building. There can be many more speciality = groups >> associated based on the building configuration. >> Consider also during the installation time - how these DODAG roots wil= l be >> configured? Must I commission each device >> to tell it which DODAG it must use for its Object Function? How easy = will this >> be to change and add in a new DODAG root >> for the end user if the lighting group changes?? >> >> With respect to Jerry Martocci's - commercial building requirements - = every >> device may need to communicate to any or >> all of the end devices. If each device must establish a DODAG for the= other >> 499 devices in a 500 node network - How much memory >> space will this require for each end device to maintain? >> >> Keep in mind that the end devices are very limited processor and memor= y >> wise. >> >> Not to mention all of the network maintenance messages that would need= >> to be transmitted to maintain all of these DODAGs. >> >> Consider the reconvergence time when one device is turned off and it w= as in >> the middle of the majority of the 100+ DODAGS? >> >> In many lighting and building application an application acknowledgeme= nt - >> must be returned {Back down the DODAG} so . . . the >> requirement is not just getting to the Root - a return path must also = be >> maintained and have a low latency path. >> >> Ted Humpal >> >> >> >> >> >> >> From: >> >> Kris Pister< pister@eecs.berkeley.edu > >> >> >> To: >> >> Anders Brandt< abr@sdesigns.dk > >> >> >> Cc: >> >> ROLL WG< roll@ietf.org > >> >> >> Date: >> >> 03/08/2010 01:45 PM >> >> >> Subject: >> >> Re: [Roll] P2P performance with current RPL proposal >> >> >> >> >> >> >> >> >> Anders - if we take JP's suggestion to make The Lamp a DODAG root, and= >> take Phoebus' recommendation that we use path diversity to improve end= - >> to-end reliability, do you see a chance of success? >> In my experience, with diverse paths and order-minutes updates you get= >> extremely high reliability. >> >> I have no aversion to TTL-limited floods as a part of a solution eithe= r. I'm >> open to ideas on how to bring those in as (presumably infrequently use= d) >> options. >> >> ksjp >> >> Anders Brandt wrote: >> Hello >> >> I would like to probe the temperature of the WG on using DAOs to >> support P2P. >> >> The building and home application spaces (and maybe others) have >> a few clearly defined requirements. >> It is not obvious to me how the current RPL proposal (cRPLp) can >> satisfy those requirements: >> >> >> In both cases it is the worst case scenario that hurts: >> >> >> P2P routing inside the PAN >> =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 >> cRPLp has no way of routing inside the PAN if you need more than >> one repeater. cRPLp has to go all the way to the top (maybe 4 hops up)= >> and down again (maybe 4 hops down) to get just 2 hops to the side. >> >> The consequence is high latency and high levels of background noise >> for nodes just outside the direct radio range. >> At the same time the risk of meeting a failing link is 4 times higher = =3D> >> latency may be much more than 4 times larger. >> >> Latency may sound like a minor issue but it actually translates direct= ly >> into lower battery lifetime. In the above (very realistic) example, >> the battery lifetime is reduced to 25% of what it should be. >> >> We have lots of battery devices sending into the network: >> * PIR sensors turning on lights >> * Door locks sending alarms >> * Door/window sensors starting chimes >> * Smoke sensors triggering an alarm system >> >> >> >> >> Response time >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> The latency issue is important. >> When a user (real human being) presses a light button the user expects= >> the light to turn on. >> cRPLp proposes that nodes in the tree periodically advertises their >> presence using DAOs. >> The periodicity is a real beast: >> Thanks to Trickle, the rate of updates in a (apparently) stable networ= k >> is low. This is good since it leaves bandwidth for data. >> But it is not good if existing routes to my lamp fail and I do not get= >> new routes to my lamp until it decides to send out a new DAO. >> My user will (with a good reason) not tolerate waiting for minutes for= >> the light to turn on. >> >> I have met two arguments to counter this concern: >> >> A1: Well, your lamp can always send a DAO when it detects a problem. >> My answer: >> True, except that my lamp does not intend to send anything >> so it will never experience any problems from its side of the netwo= rk. >> >> A2: Well, you can increase the DAO rate to sub-second updates. >> My answer: >> Oh no. I get a very high degree of management traffic which >> limits my available bandwidth, increases the risk of collisions and= >> even run the risk of violating EU legislation requiring me to only >> transmit in less than 1% of the time: >> http://focus.ti.com/lit/an/swra048/swra048.pdf >> 868 - 868.6 MHz:<1% >> >> Reactiveness is hard to achieve via polling. >> >> >> >> If you agree that this seems to be critical issues please raise your >> voice on the list. >> >> Going forward >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> >> We need some reactive mechanism to reach lamps before the user decides= >> to sue our companies. >> So is this possible? I think so. >> >> Existing commercial (non-IP) solutions are capable of re-routing quick= ly >> if they really have to. >> >> Let me try scoping the requirements to a potential solution: >> (no different from the req. docs for home and building) >> >> * P2P routing in any direction independent of the tree. >> >> * On-demand P2P route discovery if requested by a real-time critical a= pp. >> Data collection apps may be able to just wait for the next DAO updat= e. >> >> * Limited range of discovery mechanism: max 4 repeaters. >> A TTL field may limit the scope of the repeaters. >> >> * Suboptimal routing and traffic bursts are accepted in exchange >> for quick route repair. But only as an exception. >> >> >> Just as an example, one existing home control technology uses a >> (source routing) variant of AODV for quick route repair. >> Nothing comes for free. The price is flooding - but not just flooding:= >> Managed flooding using a distributed algorithm running in all >> participating nodes. >> The algorithm dampens the flooding in a time, volume and range >> perspective. >> Some similar mechanism could be built into RPL for quick route repair.= >> >> >> If anyone have alternative proposals, please bring it to the list. >> Now is the time. >> >> >> >> Thanks, >> Anders >> >> >> >> >> _______________________________________________ >> Roll mailing 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 >> listRoll@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 --------------090404020209050102090200 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I think the idea of multiple DODAGs could work for P2P if it is possible to provide some sort of pruned DODAGs. I think the DIS mechanism below could work but I think using DIOs to me seems more orthogonal and symmetric.

I think the solution could be to use a 'targeted' DIO which can be emitted and propagated immediately. Consider A trying to communicate with B:
  1. A does not have a routing table entry for B
  2. A (now effectively a DODAG root) sends a DIO targeted at B to all routers multicast immediately (with jitter)
  3. If a router hears it and has a DODAG entry to B it can then be routed as normal to B
  4. If a router hears it and doesn't have a DODAG entry to B, it will propagate it all routers multicast (with a TTL) immediately (with jitter)
  5. When B hears the DIO, it responds with a DAO d= estined for A and sent back along the DODAG to A.
  6. Intermediate routers can set up the route to B= if desired or A can use source routing.
Some points:
  • The standard DAG processing of rank relative to A using the OF would assure propagation of the targeted DIO away from A and formation of a DAG back to A
  • Routers which do not see the corresponding DAO would time out and discard the DODAG entry for A.
This would give the ability to create a 'pruned' DODAG thus giving the P2P needed without all routers having to set up DODAG entries back to A. As far as I can see, this stays pretty close to RPL but adds the idea of a DIO target and an alternative delivery mechanism as opposed to trickle timer (even then, it is really a subset of a trickle timer).
As always, I am sure there are still some other issues to consider.

Robert

Robert Cragie (Pacific Gas & Electric)

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


On 22/03/2010 5:15 PM, Mukul Goyal wrote: 
No. As Don pointed out, the route selection is based on =
an object function desired by the node initiating the route discovery. Th=
e only thing based on hop count at this point is the scope of discovery -=
 how far the DIS travels. I guess this also could be changed to a "discov=
ery scope" function if desired.

Thanks
Mukul

----- Original Message -----
From: "Philip Levis" <pal@cs.stanford.edu>
To: "d sturek" <d.sturek@att.net>
Cc: "Anders Brandt" <abr@sdesigns.dk>, "Mukul Goya=
l" <mukul@=
uwm.edu>, "Pascal Thubert (pthubert)" <p=
thubert@cisco.com>, "ROLL WG" <roll@i=
etf.org>, "Ted Humpal" <T=
ed.Humpal@jci.com>
Sent: Monday, March 22, 2010 11:20:46 AM GMT -06:00 US/Canada Central
Subject: Re: [Roll] P2P performance with current RPL proposal


Just to be sure I am hearing this right -the proposal is to use hopcount-=
based route selection?=20


Phil=20

On Mar 22, 2010, at 7:52 AM, "Don Sturek" < d.st=
urek@att.net > wrote:=20








Hi Anders and Mukul,=20

=C2=A0=20

This is all sounding quite promising in addressing P2P routing in RPL.=C2=
=A0 How can we organize a specific proposal we can gain WG approval for?=C2=
=A0 I would like to leave Anaheim with an agreed path towards P2P routing=
 support we all believe addresses the Home Automation and Building Contro=
ls use cases.=20

=C2=A0=20

Don=20

=C2=A0=20

=C2=A0=20



From: roll-bounces@ietf.org [ma=
ilto:roll-bounces@ietf.org] On Behalf Of Anders Brandt=20
Sent: Monday, March 22, 2010 7:46 AM=20
To: Mukul Goyal; Pascal Thubert (pthubert)=20
Cc: ROLL WG; Ted Humpal=20
Subject: Re: [Roll] P2P performance with current RPL proposal=20

=C2=A0=20



Add to this an element of promiscuos listening to dampen the storm =3D>=
; if node already detected a copy of the DIS with the same TTL (or lower)=
 - do not forward the DIS. Then you start getting closer to something.=20


=C2=A0=20


Oh - and by the way - record the source route on the way ;-)=20


=C2=A0=20


- Anders=20


=C2=A0=20



Fra: roll-bounces@ietf.org p=C3=A5 =
vegne af Mukul Goyal=20
Sendt: ma 22-03-2010 01:47=20
Til: Pascal Thubert (pthubert)=20
Cc: ROLL WG; Ted Humpal=20
Emne: Re: [Roll] P2P performance with current RPL proposal=20


Hi Pascal=20

Thanks for your comments (let me send my response in the next email).=20

Based on further thoughts, it seems to me that a DAG based P2P solution w=
ould work if we do the following:=20

(a) allowing multicast DIS messages to spread to an originator-specified =
number of hops and=20
(b) allowing nodes to join a DAG temporarily and leave it if there is not=
 sufficient =E2=80=9Crouting interest=E2=80=9D in being part of the DAG. =


With these points in mind, a P2P scheme could work as follows:=20

1. When a node wants to join a DODAG(D,F), where D is the DODAG's root an=
d F is the OF being used, it does the following:=20
=C2=A0=C2=A0=C2=A0 a. Initiates a discovery table entry for DODAG(D,F). T=
he discovery table entries are removed after a certain lifetime.=20
=C2=A0=C2=A0=C2=A0 b. sends out a DIS via link-local multicast asking spe=
cifically for information about DODAG(D,F). It also lists in the DIS the =
number of hops the DIS can travel.=20

2. On receiving=C2=A0 a DIS, a node does the following:=20
=C2=A0=C2=A0=C2=A0 a.if it does not know about DODAG(D,F) and the DIS hop=
 limit is not yet reached=20
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 i. Initiates a discovery table=
 entry for DODAG(D,F). This entry maintains information about the nodes f=
rom whom the DIS were received.=20
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ii. sends out the DIS (via lin=
k-local multicast with trickle controlled timing) further.=20
=C2=A0=C2=A0=C2=A0 b. If it is already a part of DODAG(D,F) or is node D =
itself=20
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 i. Send out a DIO about DODAG(=
D,F) to the node from whom the DIS was received.=20

3. On receiving a DIO about DODAG(D,F), a node does the following:=20
=C2=A0=C2=A0=C2=A0 a. Ignore the DIO if the node does not have a discover=
y table entry for DODAG(D,F)=20
=C2=A0=C2=A0=C2=A0 b. Otherwise, the node joins the DODAG(D,F) (if not al=
ready part of it) or updates its parent set in DODAG(D,F) and sends the D=
IO by unicast to the nodes that had sent it the DIS.=20

4. Once, the node is part of the DODAG(D,F), it maintains a =E2=80=9Crout=
ing interest=E2=80=9D for the DODAG in the following manner:=20
=C2=A0=C2=A0=C2=A0 a. Routing interest is a value between 0 and 1=20
=C2=A0=C2=A0=C2=A0 b. Routing interest is 1 if the node recently forwarde=
d a packet along the DODAG(D,F)=20
=C2=A0=C2=A0=C2=A0 c. Otherwise, the routing interest is x*maximum routin=
g interest of the neighbors in DODAG(D,F), where x is a fraction. The nod=
e comes to know of neighbor=E2=80=99s routing interest via the neighbor=E2=
=80=99s DIO.=20
=C2=A0=C2=A0=C2=A0 d. A node leaves a DODAG if its routing interest in th=
e DODAG goes below a threshold.=20

Thanks=20
Mukul=20

----- Original Message -----=20
From: "Pascal Thubert (pthubert)" < pt=
hubert@cisco.com >=20
To: "Mukul Goyal" < mukul@uwm.edu >=20
Cc: "ROLL WG" < roll@ietf.org >, "Ted Humpal" < =
Te=
d.Humpal@jci.com >, "robert cragie" < robert.cragie@gridmerge.com<=
/a> >=20
Sent: Friday, March 19, 2010 11:20:58 AM GMT -06:00 US/Canada Central=20
Subject: RE: [Roll] P2P performance with current RPL proposal=20

Hi Mukul=20
  
Here I have attempted to formulate a simple DV algorit=
hm in RPL/DAG terms.=20
I will appreciate it if you could let me know about your objections to th=
is=20
proposal:=20
    
[Pascal] It's cool that you do it is the first impressio=
n.=20

  
Node A needs to reach a destination D. Node A initiate=
s a discovery DAG=20
towards D. As the DIOs reach D, it sends a DAO back to selected parents. =
As=20
the DAO travels towards node A, in-route nodes store the cost to reach D.=
=20

When node B needs to reach D, it similarly initiates a discovery dag. Dur=
ing=20
this discovery, when a DIO reaches a node C that maintains a cost to reac=
h D,=20
node C responds back with a DAO that travels towards B and stores in in- =

route nodes the cost to reach D.=20
    
[Pascal]=C2=A0 understand that you're trying to make RPL=
 even closer to AODV.=20
I agree we need to gather as much as we can from that work.=20

For the specifics of your proposal:=20

- B-C might be orthogonal to A-D so that B/C\D forms an angle. You do not=
 end up with the best path that you're looking for.=20

- there might be multiple C's. Which one is the right one?=20

- RPL does not allow packets to switch instances. Following multiple DAGs=
 is the recipe for loops - unless you have them strictly ordered by some =
means like the RPL sequence between iterations, more specific routes, bla=
h blah...)=20

- the A to D path is optimized for a certain constraint. You seem to impl=
y that the B to D path has the same constraints and metrics so we can com=
pare apple to apple. Because this is a very delicate operation, RPL has i=
ntroduced the Rank, which has the right properties to make that compariso=
n efficiently.So for RPL, the loop avoidance metric is the Rank, and it i=
s only valid within an iteration.=20

- A P2P path does not come out of the blue. There must be some provisionn=
ing system that determines that those nodes, A and B, are very special so=
 they need a P2P optimization, with a given special OF, and that they bot=
h need to talk to D. Well, if that's so, the most economical is for that =
system to fork the DAG out of D, with dual targets A and B. There you obt=
ain the shortest path for both A-D and B-D for the cost of a single flood=
ing.=20

I see that you're trying to get the idea to work better, and I hope we fi=
nd a way to do so, maybe along your lines if we can solve the issues abov=
e. But before we get there, we need to agree that this is the path we wis=
h to take.=20

Cheers,=20

Pascal=20


  
----- Original Message -----=20
From: "Pascal Thubert (pthubert)" < pt=
hubert@cisco.com >=20
To: "robert cragie" < robert.cragie@gridmerge.com<=
/a> >=20
Cc: "ROLL WG" < roll@ietf.org >, "Ted Humpal" < =
Te=
d.Humpal@jci.com >=20
Sent: Thursday, March 18, 2010 9:23:14 PM GMT -06:00 US/Canada Central=20
Subject: Re: [Roll] P2P performance with current RPL proposal=20





Hi Robert=C2=A0:=20



At least from a distance, the proposed mechanism emulates AODV, with the =

DIO as RREQ and the DAO as RREP. So if we decide to dig along those lines=
,=20
we=E2=80=99ll certainly appreciate help from MANET experts. I=E2=80=99d s=
ay that if you=20
already have RPL for P2MP and MP2P, the proposed extension are probably=20
simpler to add than doing AODV from scratch.=20



For the setup, the major differences are that we build a DAG and that we =
can=20
indicate multiple targets. If you look at it, the DAG capability is a MUS=
T for=20
RPL, and I have not seen that this MUST goes away for P2P flows. The=20
multiple targets is something that appears in a number of use cases and i=
t=20
seems more economical to build a single DAG for multiple targets when=20
possible.=20



For the maintenance, the major differences are that we have the DAG as=20
first line of defense, and the RPL detection to stimulate the local repai=
r.=20



About your questions:=20



The DODAG root is the one that spawns the DAG. The targets can reach the =

root because the root advertises itself in the DIO. The idea is that the =
root ID=20
is the address that the targets need to talk to. If needed, the root can =
also=20
advertise a prefix that it can reach and that the targets need to reach t=
oo.=20



All the intermediate nodes that are confirmed by the DAO need to retain a=
t=20
least info about the DAG. That enables the targets to reach the root. The=
=20
flooding should cost about the same as that of AODV but the RPL way will =

require more states in the nodes on the way if the OF requires a DAG.=20



The way back (down) can be stateful of stateless, depending on which DAO =

we=E2=80=99re using. With fully stateful DAO, we are really in AODV-land.=
 With=20
stateless, we could drift into DSR-land for that direction. Which limits =
we=20
place to keep it simple will be determined by the resolution of issue #26=
 I=20
guess=E2=80=A6=20



And please, no apologize or on one will dare post anything anymore. Your =

questions are fully relevant and at the core of the discussion.=20



I hope we can talk in Anaheim for sure,=20




Pascal=20






From: Robert Cragie [ mailto:robert.cragie@gridmer=
ge.com ]=20
Sent: Monday, March 15, 2010 11:27 AM=20
To: Pascal Thubert (pth ubert)=20
Cc: Ted.Humpal@jci.com ; ROLL WG=20
Subject: Re: [Roll] P2P performance with current RPL proposal=20



Hi Pascal,=20

So in your slideware T can end up talking to R (DODAG root) through the=20
DODAG. So are you proposing that all potential targets can act as a DODAG=
=20
root? And therefore all intermediates have to retain DIO propagation=20
support for that DODAG as well? This may work for limited P2P but seems=20
less efficient than simple distance vector flooding RREQ/RREP like AODV o=
r=20
DYMO for generic P2P. What about R to T (or anyone else for that matter)?=
=20
Do we source route, maintain state, some undefined hybrid of the two?=20

I apologise if some of these questions have been answered in detail in ea=
rlier=20
reflector posts but I have only recently started to concentrate my effort=
s on=20
RPL and have 82 pages to wade through :-). I look forward to a productive=
=20
session in Anaheim.=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



Pascal Thubert (pthubert) wrote:=20

HI Robert=C2=A0:=20



I respectfully have to disagree.=20



My understanding is that we are considering a limited set of P2P pairs, f=
or=20
which the specific path that we need to create might have to obey specifi=
c=20
constraints.=20

So it makes sense to use an on-demand technique, probably inspired by the=
=20
MANET Reactive protocols.=20



As it goes, those protocols usually use flooding for a node to locate ano=
ther.=20
Forking a DAG is just another flooding. It does not take a lot of additio=
n to the=20
existing DIO for a root to use RPL to build a DAG that contains one or mu=
ltiple=20
Targets as leaves, under a set of constraints expressed as an objective=20
function. Please find attached a slideware that illustrates that.=20




Pascal=20






From: roll-bounces@ietf.org [ ma=
ilto:roll-bounces@ietf.org ] On Behalf Of=20
Robert Cragie=20
Sent: Thursday, March 11, 2010 2:43 PM=20
To: Ted.Humpal@jci.com=20
Cc: ROLL WG=20
Subject: Re: [Roll] P2P performance with current RPL proposal=20



I agree with Ted's comments below. Creating a DODAG for every reachable=20
node as a root seems a very inefficient approach compared to alternative =

routing algorithms. I am concerned that RPL does not actually meet the=20
original requirements in I-D.ietf-roll-building-routing-reqs, I-D.ietf-ro=
ll-home-=20
routing-reqs, RFC5673 and RFC5548. The traffic pattern requirement for a =

sink node features prominently in only two of those documents. Even in th=
is=20
case, as Ted points out, communication is likely to be bidirectional (e.g=
=2E end-=20
to-end acks.) therefore the DODAG approach is fundamentally asymmetric,=20
especially if no intermediate storage is allowed for destination routes a=
nd=20
source routing has to be used.=20

Also, RPL seems highly complex for what are constrained nodes in terms of=
=20
memory as well as power and bandwidth. The RPL draft as it stands is 82=20
pages long and that doesn't include text about the objective function.=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



=
Ted.Humpal@jci.com wrote:=20


A concern also will be how much overhead (memory space) will be required =

for a DODAG Root?=20

and based on the first question how many DODAG roots a lamp may need to=20
be a member of?=20

For example in lighting =C2=A0a single lamp may be a root for a single sw=
itch (1=20
DODAG root), =C2=A0this lamp / luminaire may also=20
be a member of another group - - =C2=A0which could be all lights on the f=
loor (2nd=20
DODAG root), and a third group=20
of all the lights in the building. =C2=A0There can be many more specialit=
y groups=20
associated based on the building configuration.=20
Consider also during the installation time - how these DODAG roots will b=
e=20
configured? =C2=A0Must I commission each device=20
to tell it which DODAG it must use for its Object Function? =C2=A0How eas=
y will this=20
be to change and add in a new DODAG root=20
for the end user if the lighting group changes??=20

With respect to Jerry Martocci's - commercial building requirements - eve=
ry=20
device may need to communicate to any or=20
all of the end devices. =C2=A0If each device must establish a DODAG for t=
he other=20
499 devices in a 500 node network - How much memory=20
space will this require for each end device to maintain?=20

Keep in mind that the end devices are very limited processor and memory=20
wise.=20

Not to mention all of the network maintenance messages that would need=20
to be transmitted to maintain all of these DODAGs.=20

Consider the reconvergence time when one device is turned off and it was =
in=20
the middle of the majority of the 100+ DODAGS?=20

In many lighting and building application an application acknowledgement =
-=20
must be returned {Back down the DODAG} so . . . the=20
requirement is not just getting to the Root - a return path must also be =

maintained and have a =C2=A0low latency path.=20

Ted Humpal=20






From:=20

Kris Pister < pister@eecs.berkeley.edu &g=
t;=20


To:=20

Anders Brandt < abr@sdesigns.dk >=20


Cc:=20

ROLL WG < roll@ietf.org >=20


Date:=20

03/08/2010 01:45 PM=20


Subject:=20

Re: [Roll] P2P performance with current RPL proposal=20








Anders - if we take JP's suggestion to make The Lamp a DODAG root, and=20
take Phoebus' recommendation that we use path diversity to improve end-=20
to-end reliability, do you see a chance of success?=20
In my experience, with diverse paths and order-minutes updates you get=20
extremely high reliability.=20

I have no aversion to TTL-limited floods as a part of a solution either. =
=C2=A0I'm=20
open to ideas on how to bring those in as (presumably infrequently used) =

options.=20

ksjp=20

Anders Brandt wrote:=20
Hello=20

I would like to probe the temperature of the WG on using DAOs to=20
support P2P.=20

The building and home application spaces (and maybe others) have=20
a few clearly defined requirements.=20
It is not obvious to me how the current RPL proposal (cRPLp) can=20
satisfy those requirements:=20


In both cases it is the worst case scenario that hurts:=20


P2P routing inside the PAN=20
=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=20
cRPLp has no way of routing inside the PAN if you need more than=20
one repeater. cRPLp has to go all the way to the top (maybe 4 hops up)=20
and down again (maybe 4 hops down) to get just 2 hops to the side.=20

The consequence is high latency and high levels of background noise=20
for nodes just outside the direct radio range.=20
At the same time the risk of meeting a failing link is 4 times higher =3D=
>=20
latency may be much more than 4 times larger.=20

Latency may sound like a minor issue but it actually translates directly =

into lower battery lifetime. In the above (very realistic) example,=20
the battery lifetime is reduced to 25% of what it should be.=20

We have lots of battery devices sending into the network:=20
* PIR sensors turning on lights=20
* Door locks sending alarms=20
* Door/window sensors starting chimes=20
* Smoke sensors triggering an alarm system=20




Response time=20
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=20
The latency issue is important.=20
When a user (real human being) presses a light button the user expects=20
the light to turn on.=20
cRPLp proposes that nodes in the tree periodically advertises their=20
presence using DAOs.=20
The periodicity is a real beast:=20
Thanks to Trickle, the rate of updates in a (apparently) stable network=20
is low. This is good since it leaves bandwidth for data.=20
But it is not good if existing routes to my lamp fail and I do not get=20
new routes to my lamp until it decides to send out a new DAO.=20
My user will (with a good reason) not tolerate waiting for minutes for=20
the light to turn on.=20

I have met two arguments to counter this concern:=20

A1: Well, your lamp can always send a DAO when it detects a problem.=20
=C2=A0 My answer:=20
=C2=A0 True, except that my lamp does not intend to send anything=20
=C2=A0 so it will never experience any problems from its side of the netw=
ork.=20

A2: Well, you can increase the DAO rate to sub-second updates.=20
=C2=A0 My answer:=20
=C2=A0 Oh no. I get a very high degree of management traffic which=20
=C2=A0 limits my available bandwidth, increases the risk of collisions an=
d=20
=C2=A0 even run the risk of violating EU legislation requiring me to only=
=20
=C2=A0 transmit in less than 1% of the time:=20
=C2=A0 http://focus.ti.=
com/lit/an/swra048/swra048.pdf=20
=C2=A0868 - 868.6 MHz: <1%=20

=C2=A0 Reactiveness is hard to achieve via polling.=20



If you agree that this seems to be critical issues please raise your=20
voice on the list.=20

Going forward=20
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=20

We need some reactive mechanism to reach lamps before the user decides=20
to sue our companies.=20
So is this possible? I think so.=20

Existing commercial (non-IP) solutions are capable of re-routing quickly =

if they really have to.=20

Let me try scoping the requirements to a potential solution:=20
(no different from the req. docs for home and building)=20

* P2P routing in any direction independent of the tree.=20

* On-demand P2P route discovery if requested by a real-time critical app.=
=20
=C2=A0Data collection apps may be able to just wait for the next DAO upda=
te.=20

* Limited range of discovery mechanism: max 4 repeaters.=20
=C2=A0 A TTL field may limit the scope of the repeaters.=20

* Suboptimal routing and traffic bursts are accepted in exchange=20
=C2=A0 for quick route repair. But only as an exception.=20


Just as an example, one existing home control technology uses a=20
(source routing) variant of AODV for quick route repair.=20
Nothing comes for free. The price is flooding - but not just flooding:=20
Managed flooding using a distributed algorithm running in all=20
participating nodes.=20
The algorithm dampens the flooding in a time, volume and range=20
perspective.=20
Some similar mechanism could be built into RPL for quick route repair.=20


If anyone have alternative proposals, please bring it to the list.=20
Now is the time.=20



Thanks,=20
=C2=A0 Anders=20




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





=C2=A0 _______________________________________________ Roll mailing=20
list =
Roll@ietf.org 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
_______________________________________________
Roll mailing list
Roll@=
ietf.org
https://www.ietf.org=
/mailman/listinfo/roll
--------------090404020209050102090200-- --------------ms010803030503010605090506 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 GgUAoIIB0DAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMDAz MjIxOTA2MzNaMCMGCSqGSIb3DQEJBDEWBBSW0ywNjLmxbkJ6jN0WGsdO329fbzBfBgkqhkiG 9w0BCQ8xUjBQMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYI KoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgYUGCSsGAQQBgjcQBDF4MHYw YjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4x LDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhB0FYYcRpgg E7/iD53vjpAfMIGHBgsqhkiG9w0BCRACCzF4oHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoT HFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25h bCBGcmVlbWFpbCBJc3N1aW5nIENBAhB0FYYcRpggE7/iD53vjpAfMA0GCSqGSIb3DQEBAQUA BIIBAJfMzWopVScnUn7WUb1TdR2uMvu+2lCnjNcVd0TFmcb+HybTkLhkAunVVCj5TlYlvN40 xvbVWyjwVrupb++btLFMVpoW962GtTAEI27oB3P0VwvmWco4qUrfaXuyUWY8jKvAPh1KvHPb 4Tgh8HWcuryiUROGahWgHJZzt0g6aX3qPqlUzPVOVoOKKk74UAMxpirdOcHtoyLVmhahE1Sk fwexXWcvQgnmmgwO/S1YMiGK5OTbCUWhVTtnLYYdm2+mULSO9vTK1pXRWdEC5hDgFqQNAMRA JW9dhhhly7/haWF7k4EKRBHws1cWCfe3kUWv40kPdVOsgdbIOwnTam8XmMMAAAAAAAA= --------------ms010803030503010605090506-- From pal@cs.stanford.edu Mon Mar 22 12:35: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 3EFF93A685A for ; Mon, 22 Mar 2010 12:35:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.055 X-Spam-Level: X-Spam-Status: No, score=-3.055 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, 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 uvUVIOm4ENqe for ; Mon, 22 Mar 2010 12:35:02 -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 9239528C101 for ; Mon, 22 Mar 2010 12:34:57 -0700 (PDT) Received: from dhcp-wireless-open-abg-29-78.meeting.ietf.org ([130.129.29.78]) by cs-smtp-1.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1NtnP9-0003xn-G1; Mon, 22 Mar 2010 12:35:15 -0700 Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=windows-1252 From: Philip Levis In-Reply-To: <446723647.8292711269278149739.JavaMail.root@mail02.pantherlink.uwm.edu> Date: Mon, 22 Mar 2010 12:35:15 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <94F03BC2-2287-4298-83C1-D5543869A353@cs.stanford.edu> References: <446723647.8292711269278149739.JavaMail.root@mail02.pantherlink.uwm.edu> To: Mukul Goyal X-Mailer: Apple Mail (2.1077) X-Scan-Signature: 9c8d7c79e82d9ccd3af9a51b4d3246f3 Cc: roll Subject: Re: [Roll] P2P performance with current RPL proposal X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Mar 2010 19:35:03 -0000 On Mar 22, 2010, at 10:15 AM, Mukul Goyal wrote: > No. As Don pointed out, the route selection is based on an object = function desired by the node initiating the route discovery. The only = thing based on hop count at this point is the scope of discovery - how = far the DIS travels. I guess this also could be changed to a "discovery = scope" function if desired. So then this assumes that the OF has a monotonically increasing (or = increasing?) scalar value to "scope" the flood? Your prior message said "(a) allowing multicast DIS messages to spread to an = originator-specified number of hops and=20 (b) allowing nodes to join a DAG temporarily and leave it if there is = not sufficient =93routing interest=94 in being part of the DAG." Phil= From bernard.tourancheau@ens-lyon.fr Mon Mar 22 13:17: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 33D493A6A18 for ; Mon, 22 Mar 2010 13:17:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.081 X-Spam-Level: ** X-Spam-Status: No, score=2.081 tagged_above=-999 required=5 tests=[BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, HELO_EQ_FR=0.35, J_CHICKENPOX_32=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 HlX+bpKpnKAm for ; Mon, 22 Mar 2010 13:17:31 -0700 (PDT) Received: from jabiru.ens-lyon.fr (jabiru.ens-lyon.fr [140.77.51.2]) by core3.amsl.com (Postfix) with ESMTP id B7B3D3A6880 for ; Mon, 22 Mar 2010 13:17:22 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by jabiru.ens-lyon.fr (Postfix) with ESMTP id 4CE17AFA85; Mon, 22 Mar 2010 21:17:40 +0100 (CET) X-Virus-Scanned: by amavisd-new-2.6.1 (20080629) (Debian) at ens-lyon.fr Received: from jabiru.ens-lyon.fr ([127.0.0.1]) by localhost (jabiru.ens-lyon.fr [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZpZV1l+XXTLc; Mon, 22 Mar 2010 21:17:38 +0100 (CET) Received: from [192.168.0.1] (mir01-2-82-245-104-81.fbx.proxad.net [82.245.104.81]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client did not present a certificate) by jabiru.ens-lyon.fr (Postfix) with ESMTPSA id C7FE81EB27A; Mon, 22 Mar 2010 21:17:37 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=iso-8859-1 From: Bernard Tourancheau In-Reply-To: <8E09C72DBC577D489F13A71228C0B7BF010FEFE9@ftrdmel0.rd.francetelecom.fr> Date: Mon, 22 Mar 2010 21:17:35 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <8E09C72DBC577D489F13A71228C0B7BF010FEFE9@ftrdmel0.rd.francetelecom.fr> To: X-Mailer: Apple Mail (2.1077) Cc: roll@ietf.org Subject: Re: [Roll] Options in DIS X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 22 Mar 2010 20:17:32 -0000 Dominique, We are supporting your proposal as well. Best regards, Bernard. Le 19 mars 2010 =E0 18:44, = a =E9crit : > Hi all, >=20 > I have already expressed a desire for options in the DIS packet > http://www.ietf.org/mail-archive/web/roll/current/msg02765.html > Jerry and Mukul expressed their support to the request. > http://www.ietf.org/mail-archive/web/roll/current/msg02766.html > http://www.ietf.org/mail-archive/web/roll/current/msg02770.html >=20 > Then Phil asked for a justification for the request, which I admit I > haven't provided yet. > http://www.ietf.org/mail-archive/web/roll/current/msg02774.html >=20 > More recently, Tzeta suggested that DIS have security options > http://www.ietf.org/mail-archive/web/roll/current/msg03101.html >=20 > Independently, Yaov and Matteo both again expressed the need for DIS > option. > http://www.ietf.org/mail-archive/web/roll/current/msg03185.html > http://www.ietf.org/mail-archive/web/roll/current/msg03290.html >=20 > I do believe we have a serious point here. > Please find the justification below. > Can we please have a ticket to work on it ? > I volunteer to gather others contributors' opinions/requests and and > propose detailed text to be included in future revisions of the RPL > draft. > Best, >=20 > Dominique >=20 > ------------------------------------------- > The following is extracted from a typical water/gas smart metering > infrastructure. > The utility company worker adds new metering points into the network = as > meters are replaced or fitted with sensing/transmission electronics.=20= > Before the worker leaves the premises, he/she is requested to check = that > the meter has actually joined the network. > This cannot wait for a trickled-down DAO to arrive. > Therefore, the meter will send a DIS to collect information from the > network. > Without DIS options, all neighbor routers will respond, spending = energy > for their own transmission and triggering energy expenditure in all > neighbor nodes that overhear the responses. >=20 > Let's consider a "wheel" model for the network topology, with a sink = at > the center and spokes connecting outward to ring-1 routers, ring-2 > routers and periphery meters. The meters have routing capability > themselves, although I'll call them meters in the following text to > distinguish them from devices solely intended at providing = connectivity, > which I'll call routers. > Let's consider a generic "pizza slice" of this wheel. Since there's > central symmetry in the network, there's no border effect in the slice > We typically have > - one mains-powered sink at the center, > - N severely energy-limited meters at the periphery, deeply burried = into > basements or manholes > - N/20 fairly energy-limited ring-1 routers, located on high spots > - N/10 fairly energy-limited ring-2 routers, located on high spots > In RPL parlance, ring-1 routers would have a typical rank of 4, and > ring-2 routers would have a typical rank of 8 > The N/10 and N/20 ratios above are dictated by energy/lifetime > considerations, not radio coverage. > A typical connectivity is the following > - each meter is in range of N/10 and N/20 routers, albeit with *very* > different link qualities > - each router is in range of N/10 and N/20 routers, with various link > qualities=20 > - each meter is in range of N/20 meters > The ratios and assumptions above hold for values of N in the [20..200] > range.=20 >=20 > **** Without DIS options, we have > NT0 =3D Number of DIS multicast transmission =3D 1 > NR0 =3D Number of DIS active receptions =3D N/5 (due to N/20 meters = and > (N/10+N/20) routeurs),=20 > NT1 =3D N/20 DIO transmissions from meters; each one being overheard = by > N/20 meters and (N/10+N/20) routers > NT2 =3D N/10+N/20 DIO transmissions from routers; each one being = overheard > by N meters and (N/10+N/20) routers > NR1 ~=3D NT1 * (3N/20 + N/20) =3D N^2/100 =3D 0.01 * N^2 receptions = due to DIO > coming from meters > NR2 ~=3D NT2 * (N + N/20 + N/10) =3D N^2*69/400 =3D 0.17 * N^2 = receptions due > to DIO coming from routers >=20 > We therefore have > Number of transmissions: NT =3D NT0 + NT1 + NT2 =3D 1 + N/20 + (N/10 + = N/20) > =3D 24/20 * N =3D 1 + 0.2 * N > Number of receptions : NR =3D NR0 + NR1 + NR2 =3D 0.2 * N + 0.18 * = N^2 >=20 > Total energy cost Etotal =3D NT * Et + NR * Er >=20 > If the network is asynchronous and uses basic preamble sampling, the > cost of overhearing Eo is the cost of receiving the expected duration > (half) of the preamble. > Since the DIS packet is small, its unit reception cost Er is about the > same as the overhearing cost Eo. > With a small (<1KB) DIO packet, the cost of transmission Et is > essentially the cost of sending the preamble. > Let's assume transmission cost Et is 6 times Eo (full preamble length > accounts for x2, power consumption for x3) >=20 > Etotal ~=3D Eo * ( 1 * 6 + N * (0.2 * 6 + 0.2) + 0.18 * N^2) ~=3D Eo * = ( 6 + > 1.4 * N + 0.18 * N^2)=20 >=20 > **** With DIS options > A typical protocol currently in use in widely deployed proprietary = smart > metering networks is the following. > Newborn nodes send successive DIS'es with decreasing demands on rank = and > link quality > - iteration 1: only sinks, LQI >=3D 0,75*maxLQI > - iteration 2: only sinks, LQI >=3D 0,5*maxLQI > - iteration 3: only sinks, LQI >=3D 0,25*maxLQI > - iteration 4: ring-1 routers, LQI >=3D 0,75*maxLQI, > - iteration 5: ring-1 routers, LQI >=3D 0,50*maxLQI, > - iteration 6: ring-1 routers, LQI >=3D 0,25*maxLQI, > - iteration 7: ring-2 routers, LQI >=3D 0,75*maxLQI, > - iteration 8: ring-2 routers, LQI >=3D 0,50*maxLQI, > - iteration 9: ring-2 routers, LQI >=3D 0,25*maxLQI, > - etc > The newborn node will usually send several DIS's instead of just one. > Its direct neighbors (N/20 meters, N/10+N/20 routers) will also incur > the cost of receiving these extra DIS'es. > Let's suppose iteration 7 is successful and prompts 25% of the = neighbor > ring-2 routers to send their DIOs. > Number of DIS transmissions =3D 7 > Number of DIS receptions =3D 7 * (N/20 + N/10 + N/20) =3D 7/5 * N > Number of DIO transmissions =3D 25% of N/10 =3D N/40, overheard by = 23/20 * N > nodes (N meters and N/10+N/20 routers). > Number of DIOs overheard =3D 23/800 * N^2 =3D 0.029 * N^2 > Etotal ~=3D Eo * ( 7*6 + N * ( 7/5 + 6/40) + 0.029 * N^2) ~=3D Eo * = (42 + > 1.6 * N + 0.029 * N^2) >=20 > In this case, the global energy cost of inserting a new node in the > network is reduced by a factor ranging from 2 to 5 depending on N in > [20..200]. Additional analysis shows that this saving affect both = meters > and routers (specifically, we are not pushing the burden towards the > energy-critical meters). > Similar results are obtained with differents iterations numbers. >=20 > Just to re-inforce this calculation, it has been our experience that > node insertion into a dense low-power network, if done wrong, is a > significant energy drain. Please let us enhance RPL to do it right. > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From laurent.toutain@gmail.com Mon Mar 22 13:26: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 8EBC23A6846 for ; Mon, 22 Mar 2010 13:26:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.354 X-Spam-Level: ** X-Spam-Status: No, score=2.354 tagged_above=-999 required=5 tests=[BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_32=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 KwA8cVhYrlZM for ; Mon, 22 Mar 2010 13:26:52 -0700 (PDT) Received: from mail-fx0-f213.google.com (mail-fx0-f213.google.com [209.85.220.213]) by core3.amsl.com (Postfix) with ESMTP id A83C63A6A39 for ; Mon, 22 Mar 2010 13:26:38 -0700 (PDT) Received: by fxm5 with SMTP id 5so1883520fxm.29 for ; Mon, 22 Mar 2010 13:26:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:from:date:x-google-sender-auth:message-id:subject:to:cc :content-type; bh=n/RK8SOmNJM3iHO+9vrjzBlmBH2uBqvH14Zg5HtEq2k=; b=UclYpCMgX7wUZuV+QnXGZy4d7BUXqtHm6pq/NDQZoRSopkuoGB2ETplNykMXTGD8jK y8XEukA4IvN0jxIyIa7byIatoeOvErB+Wmc4+URnW1VTkleAzP5ggpyc5CLbM8veLxBb u7L9EHSq+fhgIhO6IiTm/fVENAX9YFQmDhlLE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; b=wqnT+PF1Yq02AxGsEoNQHnWladN/VZyUQKNwiPvvpSiEJz0TlfUNA1ylNjOh314O5y MfR9xcl+M3VWcnLdFewQXW2oUUL9YViERXHhj4VswPUrokyrIzEk7Rxv6/+O8do1EuZD tQUei/rXwXY48i3S8XAP7VfwrEKvum37n8wM0= MIME-Version: 1.0 Sender: laurent.toutain@gmail.com Received: by 10.223.63.138 with SMTP id b10mr1506114fai.95.1269289613135; Mon, 22 Mar 2010 13:26:53 -0700 (PDT) In-Reply-To: References: <8E09C72DBC577D489F13A71228C0B7BF010FEFE9@ftrdmel0.rd.francetelecom.fr> From: Laurent Toutain Date: Mon, 22 Mar 2010 21:26:33 +0100 X-Google-Sender-Auth: ba2430f5a84fc73f Message-ID: <147a29c81003221326s7f9791cct45ba55375ddc9d6a@mail.gmail.com> To: Bernard Tourancheau Content-Type: multipart/alternative; boundary=001517475482821d9804826984b0 Cc: roll@ietf.org Subject: Re: [Roll] Options in DIS X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 22 Mar 2010 20:26:53 -0000 --001517475482821d9804826984b0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable We also support the idea, it offers the possibility to make the standard evolves. Laurent On Mon, Mar 22, 2010 at 21:17, Bernard Tourancheau < bernard.tourancheau@ens-lyon.fr> wrote: > Dominique, > We are supporting your proposal as well. > Best regards, > Bernard. > Le 19 mars 2010 =E0 18:44, < > dominique.barthel@orange-ftgroup.com> a =E9crit : > > > Hi all, > > > > I have already expressed a desire for options in the DIS packet > > http://www.ietf.org/mail-archive/web/roll/current/msg02765.html > > Jerry and Mukul expressed their support to the request. > > http://www.ietf.org/mail-archive/web/roll/current/msg02766.html > > http://www.ietf.org/mail-archive/web/roll/current/msg02770.html > > > > Then Phil asked for a justification for the request, which I admit I > > haven't provided yet. > > http://www.ietf.org/mail-archive/web/roll/current/msg02774.html > > > > More recently, Tzeta suggested that DIS have security options > > http://www.ietf.org/mail-archive/web/roll/current/msg03101.html > > > > Independently, Yaov and Matteo both again expressed the need for DIS > > option. > > http://www.ietf.org/mail-archive/web/roll/current/msg03185.html > > http://www.ietf.org/mail-archive/web/roll/current/msg03290.html > > > > I do believe we have a serious point here. > > Please find the justification below. > > Can we please have a ticket to work on it ? > > I volunteer to gather others contributors' opinions/requests and and > > propose detailed text to be included in future revisions of the RPL > > draft. > > Best, > > > > Dominique > > > > ------------------------------------------- > > The following is extracted from a typical water/gas smart metering > > infrastructure. > > The utility company worker adds new metering points into the network as > > meters are replaced or fitted with sensing/transmission electronics. > > Before the worker leaves the premises, he/she is requested to check tha= t > > the meter has actually joined the network. > > This cannot wait for a trickled-down DAO to arrive. > > Therefore, the meter will send a DIS to collect information from the > > network. > > Without DIS options, all neighbor routers will respond, spending energy > > for their own transmission and triggering energy expenditure in all > > neighbor nodes that overhear the responses. > > > > Let's consider a "wheel" model for the network topology, with a sink at > > the center and spokes connecting outward to ring-1 routers, ring-2 > > routers and periphery meters. The meters have routing capability > > themselves, although I'll call them meters in the following text to > > distinguish them from devices solely intended at providing connectivity= , > > which I'll call routers. > > Let's consider a generic "pizza slice" of this wheel. Since there's > > central symmetry in the network, there's no border effect in the slice > > We typically have > > - one mains-powered sink at the center, > > - N severely energy-limited meters at the periphery, deeply burried int= o > > basements or manholes > > - N/20 fairly energy-limited ring-1 routers, located on high spots > > - N/10 fairly energy-limited ring-2 routers, located on high spots > > In RPL parlance, ring-1 routers would have a typical rank of 4, and > > ring-2 routers would have a typical rank of 8 > > The N/10 and N/20 ratios above are dictated by energy/lifetime > > considerations, not radio coverage. > > A typical connectivity is the following > > - each meter is in range of N/10 and N/20 routers, albeit with *very* > > different link qualities > > - each router is in range of N/10 and N/20 routers, with various link > > qualities > > - each meter is in range of N/20 meters > > The ratios and assumptions above hold for values of N in the [20..200] > > range. > > > > **** Without DIS options, we have > > NT0 =3D Number of DIS multicast transmission =3D 1 > > NR0 =3D Number of DIS active receptions =3D N/5 (due to N/20 meters and > > (N/10+N/20) routeurs), > > NT1 =3D N/20 DIO transmissions from meters; each one being overheard by > > N/20 meters and (N/10+N/20) routers > > NT2 =3D N/10+N/20 DIO transmissions from routers; each one being overhe= ard > > by N meters and (N/10+N/20) routers > > NR1 ~=3D NT1 * (3N/20 + N/20) =3D N^2/100 =3D 0.01 * N^2 receptions due= to DIO > > coming from meters > > NR2 ~=3D NT2 * (N + N/20 + N/10) =3D N^2*69/400 =3D 0.17 * N^2 receptio= ns due > > to DIO coming from routers > > > > We therefore have > > Number of transmissions: NT =3D NT0 + NT1 + NT2 =3D 1 + N/20 + (N/10 + = N/20) > > =3D 24/20 * N =3D 1 + 0.2 * N > > Number of receptions : NR =3D NR0 + NR1 + NR2 =3D 0.2 * N + 0.18 * N^= 2 > > > > Total energy cost Etotal =3D NT * Et + NR * Er > > > > If the network is asynchronous and uses basic preamble sampling, the > > cost of overhearing Eo is the cost of receiving the expected duration > > (half) of the preamble. > > Since the DIS packet is small, its unit reception cost Er is about the > > same as the overhearing cost Eo. > > With a small (<1KB) DIO packet, the cost of transmission Et is > > essentially the cost of sending the preamble. > > Let's assume transmission cost Et is 6 times Eo (full preamble length > > accounts for x2, power consumption for x3) > > > > Etotal ~=3D Eo * ( 1 * 6 + N * (0.2 * 6 + 0.2) + 0.18 * N^2) ~=3D Eo * = ( 6 + > > 1.4 * N + 0.18 * N^2) > > > > **** With DIS options > > A typical protocol currently in use in widely deployed proprietary smar= t > > metering networks is the following. > > Newborn nodes send successive DIS'es with decreasing demands on rank an= d > > link quality > > - iteration 1: only sinks, LQI >=3D 0,75*maxLQI > > - iteration 2: only sinks, LQI >=3D 0,5*maxLQI > > - iteration 3: only sinks, LQI >=3D 0,25*maxLQI > > - iteration 4: ring-1 routers, LQI >=3D 0,75*maxLQI, > > - iteration 5: ring-1 routers, LQI >=3D 0,50*maxLQI, > > - iteration 6: ring-1 routers, LQI >=3D 0,25*maxLQI, > > - iteration 7: ring-2 routers, LQI >=3D 0,75*maxLQI, > > - iteration 8: ring-2 routers, LQI >=3D 0,50*maxLQI, > > - iteration 9: ring-2 routers, LQI >=3D 0,25*maxLQI, > > - etc > > The newborn node will usually send several DIS's instead of just one. > > Its direct neighbors (N/20 meters, N/10+N/20 routers) will also incur > > the cost of receiving these extra DIS'es. > > Let's suppose iteration 7 is successful and prompts 25% of the neighbor > > ring-2 routers to send their DIOs. > > Number of DIS transmissions =3D 7 > > Number of DIS receptions =3D 7 * (N/20 + N/10 + N/20) =3D 7/5 * N > > Number of DIO transmissions =3D 25% of N/10 =3D N/40, overheard by 23/2= 0 * N > > nodes (N meters and N/10+N/20 routers). > > Number of DIOs overheard =3D 23/800 * N^2 =3D 0.029 * N^2 > > Etotal ~=3D Eo * ( 7*6 + N * ( 7/5 + 6/40) + 0.029 * N^2) ~=3D Eo * (42= + > > 1.6 * N + 0.029 * N^2) > > > > In this case, the global energy cost of inserting a new node in the > > network is reduced by a factor ranging from 2 to 5 depending on N in > > [20..200]. Additional analysis shows that this saving affect both meter= s > > and routers (specifically, we are not pushing the burden towards the > > energy-critical meters). > > Similar results are obtained with differents iterations numbers. > > > > Just to re-inforce this calculation, it has been our experience that > > node insertion into a dense low-power network, if done wrong, is a > > significant energy drain. Please let us enhance RPL to do it right. > > _______________________________________________ > > Roll mailing 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 Laurent Toutain Tel: +33 2 22 06 82 37 --001517475482821d9804826984b0 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable We also support the idea, it offers the possibility to make the standard ev= olves.

Laurent

On Mon,= Mar 22, 2010 at 21:17, Bernard Tourancheau <bernard.tourancheau@ens-lyon.fr= > wrote:
Dominique,
We are supporting your proposal as well.
Best regards,
Bernard.
Le 19 mars 2010 =E0 18:44, <dominique.barthel@orange-ftgroup.com> <dominique.barthel@orange-ftgroup.= com> a =E9crit :

> Hi all,
>
> I have already expressed a desire for options in the DIS packet
> http://www.ietf.org/mail-archive/web/roll/current/m= sg02765.html
> Jerry and Mukul expressed their support to the request.
> http://www.ietf.org/mail-archive/web/roll/current/m= sg02766.html
> http://www.ietf.org/mail-archive/web/roll/current/m= sg02770.html
>
> Then Phil asked for a justification for the request, which I admit I > haven't provided yet.
> http://www.ietf.org/mail-archive/web/roll/current/m= sg02774.html
>
> More recently, Tzeta suggested that DIS have security options
> http://www.ietf.org/mail-archive/web/roll/current/m= sg03101.html
>
> Independently, Yaov and Matteo both again expressed the need for DIS > option.
> http://www.ietf.org/mail-archive/web/roll/current/m= sg03185.html
> http://www.ietf.org/mail-archive/web/roll/current/m= sg03290.html
>
> I do believe we have a serious point here.
> Please find the justification below.
> Can we please have a ticket to work on it ?
> I volunteer to gather others contributors' opinions/requests and a= nd
> propose detailed text to be included in future revisions of the RPL > draft.
> Best,
>
> Dominique
>
> -------------------------------------------
> The following is extracted from a typical water/gas smart metering
> infrastructure.
> The utility company worker adds new metering points into the network a= s
> meters are replaced or fitted with sensing/transmission =A0electronics= .
> Before the worker leaves the premises, he/she is requested to check th= at
> the meter has actually joined the network.
> This cannot wait for a trickled-down DAO to arrive.
> Therefore, the meter will send a DIS to collect information from the > network.
> Without DIS options, all neighbor routers will respond, spending energ= y
> for their own transmission and triggering energy expenditure in =A0all=
> neighbor nodes that overhear the responses.
>
> Let's consider a "wheel" model for the network topology,= with a sink at
> the center and spokes connecting outward to ring-1 routers, ring-2
> routers and periphery meters. The meters have routing capability
> themselves, although I'll call them meters in the following text t= o
> distinguish them from devices solely intended at providing connectivit= y,
> which I'll call routers.
> Let's consider a generic "pizza slice" of this wheel. Si= nce there's
> central symmetry in the network, there's no border effect in the s= lice
> We typically have
> - one mains-powered sink at the center,
> - N severely energy-limited meters at the periphery, deeply burried in= to
> basements or manholes
> - N/20 fairly energy-limited ring-1 routers, located on high spots
> - N/10 fairly energy-limited ring-2 routers, located on high spots
> In RPL parlance, ring-1 routers would have a typical rank of 4, and > ring-2 routers would have a typical rank of 8
> The N/10 and N/20 ratios above are dictated by energy/lifetime
> considerations, not radio coverage.
> A typical connectivity is the following
> - each meter is in range of N/10 and N/20 routers, albeit with *very*<= br> > different link qualities
> - each router is in range of N/10 and N/20 routers, with various link<= br> > qualities
> - each meter is in range of N/20 meters
> The ratios and assumptions above hold for values of N in the [20..200]=
> range.
>
> **** Without DIS options, we have
> NT0 =3D Number of DIS multicast transmission =3D 1
> NR0 =3D Number of DIS active receptions =3D N/5 (due to N/20 meters an= d
> (N/10+N/20) routeurs),
> NT1 =3D N/20 DIO transmissions from meters; each one being overheard b= y
> N/20 meters and (N/10+N/20) routers
> NT2 =3D N/10+N/20 DIO transmissions from routers; each one being overh= eard
> by N meters and (N/10+N/20) routers
> NR1 ~=3D NT1 * (3N/20 + N/20) =3D N^2/100 =3D 0.01 * N^2 receptions du= e to DIO
> coming from meters
> NR2 ~=3D NT2 * (N + N/20 + N/10) =3D N^2*69/400 =3D 0.17 * N^2 recepti= ons due
> to DIO coming from routers
>
> We therefore have
> Number of transmissions: NT =3D NT0 + NT1 + NT2 =3D 1 + N/20 + (N/10 += N/20)
> =3D 24/20 * N =3D 1 + 0.2 * N
> Number of receptions =A0 : NR =3D NR0 + NR1 + NR2 =3D 0.2 * N + 0.18 *= N^2
>
> Total energy cost Etotal =3D NT * Et + NR * Er
>
> If the network is asynchronous and uses basic preamble sampling, the > cost of overhearing Eo is the cost of receiving the expected duration<= br> > (half) of the preamble.
> Since the DIS packet is small, its unit reception cost Er is about the=
> same as the overhearing cost Eo.
> With a small (<1KB) DIO packet, the cost of transmission Et is
> essentially the cost of sending the preamble.
> Let's assume transmission cost Et is 6 times Eo (full preamble len= gth
> accounts for x2, power consumption for x3)
>
> Etotal ~=3D Eo * ( 1 * 6 + N * (0.2 * 6 + 0.2) + 0.18 * N^2) ~=3D Eo *= ( 6 +
> 1.4 * N + 0.18 * N^2)
>
> **** With DIS options
> A typical protocol currently in use in widely deployed proprietary sma= rt
> metering networks is the following.
> Newborn nodes send successive DIS'es with decreasing demands on ra= nk and
> link quality
> - iteration 1: only sinks, LQI >=3D 0,75*maxLQI
> - iteration 2: only sinks, LQI >=3D 0,5*maxLQI
> - iteration 3: only sinks, LQI >=3D 0,25*maxLQI
> - iteration 4: ring-1 routers, LQI >=3D 0,75*maxLQI,
> - iteration 5: ring-1 routers, LQI >=3D 0,50*maxLQI,
> - iteration 6: ring-1 routers, LQI >=3D 0,25*maxLQI,
> - iteration 7: ring-2 routers, LQI >=3D 0,75*maxLQI,
> - iteration 8: ring-2 routers, LQI >=3D 0,50*maxLQI,
> - iteration 9: ring-2 routers, LQI >=3D 0,25*maxLQI,
> - etc
> The newborn node will usually send several DIS's instead of just o= ne.
> Its direct neighbors (N/20 meters, N/10+N/20 routers) will also incur<= br> > the cost of receiving these extra DIS'es.
> Let's suppose iteration 7 is successful and prompts 25% of the nei= ghbor
> ring-2 routers to send their DIOs.
> Number of DIS transmissions =3D 7
> Number of DIS receptions =3D 7 * (N/20 + N/10 + N/20) =3D 7/5 * N
> Number of DIO transmissions =3D 25% of N/10 =3D N/40, overheard by 23/= 20 * N
> nodes (N meters and N/10+N/20 routers).
> Number of DIOs overheard =3D 23/800 * N^2 =3D 0.029 * N^2
> Etotal ~=3D Eo * ( 7*6 + N * ( 7/5 + 6/40) + 0.029 * N^2) ~=3D Eo * (4= 2 +
> 1.6 * N + 0.029 * N^2)
>
> In this case, the global energy cost of inserting a new node in the > network is reduced by a factor ranging from 2 to 5 depending on N in > [20..200]. Additional analysis shows that this saving affect both mete= rs
> and routers (specifically, we are not pushing the burden towards the > energy-critical meters).
> Similar results are obtained with differents iterations numbers.
>
> Just to re-inforce this calculation, it has been our experience that > node insertion into a dense low-power network, if done wrong, is a
> significant energy drain. Please let us enhance RPL to do it right. > _______________________________________________
> Roll mailing list
> Roll@ietf.org
> https://www.ietf.org/mailman/listinfo/roll

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




--
Laurent Tou= tain
Tel: +33 2 22 06 82 37

--001517475482821d9804826984b0-- From pal@cs.stanford.edu Mon Mar 22 14:08: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 CFE8A28C1E9 for ; Mon, 22 Mar 2010 14:08:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.518 X-Spam-Level: X-Spam-Status: No, score=-3.518 tagged_above=-999 required=5 tests=[AWL=0.462, 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 xtpkIJiOYt84 for ; Mon, 22 Mar 2010 14:08:40 -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 93C6528C1C1 for ; Mon, 22 Mar 2010 14:02:11 -0700 (PDT) Received: from dhcp-wireless-open-abg-29-78.meeting.ietf.org ([130.129.29.78]) by cs-smtp-2.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1NtolY-0001Na-An; Mon, 22 Mar 2010 14:02:29 -0700 Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Philip Levis In-Reply-To: <8E09C72DBC577D489F13A71228C0B7BF010FEFE9@ftrdmel0.rd.francetelecom.fr> Date: Mon, 22 Mar 2010 14:02:24 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <5C4CCBDE-4397-4797-89CD-81C0EA59E1B1@cs.stanford.edu> References: <8E09C72DBC577D489F13A71228C0B7BF010FEFE9@ftrdmel0.rd.francetelecom.fr> To: X-Mailer: Apple Mail (2.1077) X-Scan-Signature: d1b7ebe10773c68371983edd1a66f504 Cc: roll@ietf.org Subject: Re: [Roll] Options in DIS X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 22 Mar 2010 21:08:41 -0000 On Mar 19, 2010, at 10:44 AM, = wrote: > Hi all, >=20 > I have already expressed a desire for options in the DIS packet > http://www.ietf.org/mail-archive/web/roll/current/msg02765.html > Jerry and Mukul expressed their support to the request. > http://www.ietf.org/mail-archive/web/roll/current/msg02766.html > http://www.ietf.org/mail-archive/web/roll/current/msg02770.html >=20 > Then Phil asked for a justification for the request, which I admit I > haven't provided yet. > http://www.ietf.org/mail-archive/web/roll/current/msg02774.html >=20 > More recently, Tzeta suggested that DIS have security options > http://www.ietf.org/mail-archive/web/roll/current/msg03101.html >=20 > Independently, Yaov and Matteo both again expressed the need for DIS > option. > http://www.ietf.org/mail-archive/web/roll/current/msg03185.html > http://www.ietf.org/mail-archive/web/roll/current/msg03290.html >=20 > I do believe we have a serious point here. > Please find the justification below. > Can we please have a ticket to work on it ? > I volunteer to gather others contributors' opinions/requests and and > propose detailed text to be included in future revisions of the RPL > draft. > Best, Dominique: This is an interesting problem; I think the basic question is the speed = with which you generate a very good route. Make no mistake -- using = Trickle timers for DIOs means that you can quickly find a route, but not = necessarily the best one. The assumption is that, over time, nodes will = hear DIOs from a larger set of possible next hops and continuously = improve their routes. We see this in practice with CTP: a node joining = the network can almost immediately find a route, but the route churns a = little as it incrementally finds better ones. DIOs currently have a mechanism to reduce transmission load: redundant = packet suppression. For example, RPL can define "redundant" as a DIO = whose Rank <=3D the local Rank. If you set a redundancy constant > 1, = (e.g., 3), then the probability all nodes at the best possible Rank will = be suppressed is amazingly low, and decreases exponentially with each = Trickle interval. Why isn't this sufficient? Given all of the dangerous = edge cases in wireless, randomized algorithms that converge tend to be = much more reliable than deterministic ones which seek to find the = optimal solution. Phil From dominique.barthel@orange-ftgroup.com Mon Mar 22 16:51: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 1D61E28C264 for ; Mon, 22 Mar 2010 16:51:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.481 X-Spam-Level: * X-Spam-Status: No, score=1.481 tagged_above=-999 required=5 tests=[BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, 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 kmnng7FmsgtY for ; Mon, 22 Mar 2010 16:51:15 -0700 (PDT) Received: from r-mail1.rd.francetelecom.com (r-mail1.rd.francetelecom.com [217.108.152.41]) by core3.amsl.com (Postfix) with ESMTP id A35BC28C262 for ; Mon, 22 Mar 2010 16:51:11 -0700 (PDT) Received: from r-mail1.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 6D90157C34C; Tue, 23 Mar 2010 00:53:48 +0000 (UTC) Received: from ftrdsmtp1.rd.francetelecom.fr (unknown [10.192.128.46]) by r-mail1.rd.francetelecom.com (Postfix) with ESMTP id A9EB657C34B; Tue, 23 Mar 2010 00:53:44 +0000 (UTC) Received: from ftrdmel0.rd.francetelecom.fr ([10.192.128.56]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Tue, 23 Mar 2010 00:51:23 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 23 Mar 2010 00:48:36 +0100 Message-ID: <8E09C72DBC577D489F13A71228C0B7BF010FF65D@ftrdmel0.rd.francetelecom.fr> In-Reply-To: <5C4CCBDE-4397-4797-89CD-81C0EA59E1B1@cs.stanford.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] Options in DIS Thread-Index: AcrKAv7HYmVbvjVgT1G2R8ZW/mcDygAEkBzw References: <8E09C72DBC577D489F13A71228C0B7BF010FEFE9@ftrdmel0.rd.francetelecom.fr> <5C4CCBDE-4397-4797-89CD-81C0EA59E1B1@cs.stanford.edu> From: To: X-OriginalArrivalTime: 22 Mar 2010 23:51:23.0332 (UTC) FILETIME=[93EE7840:01CACA1A] Cc: roll@ietf.org Subject: Re: [Roll] Options in DIS X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 22 Mar 2010 23:51:16 -0000 Hi Phil, Thanks for your reply. Maybe I was not clear enough that we do = understand the benefit of DIO trickle timers and of routing improvements = over time, and we indeed intend to use them. The use of DIS, in my mind, = was not substitute to DIOs. As you mention, Trickle timers are so powerful that they will suppress = many DIO transmissions and that's good for energy consumption. Yet, relying solely on DIOs, the worker on the field might have to wait = for a very long time for anything to happen on the node that he/she just = installed. I already mentioned we don't want him/her to leave the = premises until he/she has ascertained that decent minimal connectivity = can be established: the node might need to be moved, or "coverage = extenders" installed in the vicinity, which he/she needs to find during = the same field trip. In some networks I'm interested in, recuring background activity happens = about every hour. If I want these networks to have a similar lifetime = with RPL than they currently have with proprietary protocols, the max = interval for Trickle timers should also be about an hour. Trickle timers will, as you just mentioned, suppress most transmissions = in a given radio neighborhood. Therefore, even in dense networks, my = field worker will sit waiting for dozens of minutes, typically. Do you = know any commercial company that will tolerate this? The mandate is more = like less than a minute. Current proprietary procotols do achieve this = through some router discovery protocol [Maleysson2005]. If we want to transition these networks to RPL, there needs to be a way = for the new node to trigger its insertion into the network, and my = understanding is that DIS are meant just for that. Am I missing something here? With best regards, Dominique [Maleysson2005] Maleysson, L. and Dugas, C. "Configuring and managing a = large-scale monitoring network solving real world challenges for ultra low powered and = long-range wireless mesh networks", in Proceedings of the 2005 Joint Conference on Smart Objects and Ambient = intelligence: innovative Context-Aware Services: Usages and Technologies (sOc-EUSAI '05), = Grenoble, France, October 12 - 14, 2005, vol. 121. ACM, New York, NY, =20 -----Message d'origine----- De : Philip Levis [mailto:pal@cs.stanford.edu]=20 Envoy=E9 : lundi 22 mars 2010 14:02 =C0 : BARTHEL Dominique RD-TECH-GRE Cc : roll@ietf.org Objet : Re: [Roll] Options in DIS On Mar 19, 2010, at 10:44 AM, = wrote: > Hi all, >=20 > I have already expressed a desire for options in the DIS packet=20 > http://www.ietf.org/mail-archive/web/roll/current/msg02765.html > Jerry and Mukul expressed their support to the request. > http://www.ietf.org/mail-archive/web/roll/current/msg02766.html > http://www.ietf.org/mail-archive/web/roll/current/msg02770.html >=20 > Then Phil asked for a justification for the request, which I admit I=20 > haven't provided yet. > http://www.ietf.org/mail-archive/web/roll/current/msg02774.html >=20 > More recently, Tzeta suggested that DIS have security options=20 > http://www.ietf.org/mail-archive/web/roll/current/msg03101.html >=20 > Independently, Yaov and Matteo both again expressed the need for DIS=20 > option. > http://www.ietf.org/mail-archive/web/roll/current/msg03185.html > http://www.ietf.org/mail-archive/web/roll/current/msg03290.html >=20 > I do believe we have a serious point here. > Please find the justification below. > Can we please have a ticket to work on it ? > I volunteer to gather others contributors' opinions/requests and and=20 > propose detailed text to be included in future revisions of the RPL=20 > draft. > Best, Dominique: This is an interesting problem; I think the basic question is the speed = with which you generate a very good route. Make no mistake -- using = Trickle timers for DIOs means that you can quickly find a route, but not = necessarily the best one. The assumption is that, over time, nodes will = hear DIOs from a larger set of possible next hops and continuously = improve their routes. We see this in practice with CTP: a node joining = the network can almost immediately find a route, but the route churns a = little as it incrementally finds better ones. DIOs currently have a mechanism to reduce transmission load: redundant = packet suppression. For example, RPL can define "redundant" as a DIO = whose Rank <=3D the local Rank. If you set a redundancy constant > 1, = (e.g., 3), then the probability all nodes at the best possible Rank will = be suppressed is amazingly low, and decreases exponentially with each = Trickle interval. Why isn't this sufficient? Given all of the dangerous = edge cases in wireless, randomized algorithms that converge tend to be = much more reliable than deterministic ones which seek to find the = optimal solution. Phil From prvs=691b79a33=mukul@uwm.edu Mon Mar 22 17:28: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 7C75E28C29C for ; Mon, 22 Mar 2010 17:28:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.523 X-Spam-Level: X-Spam-Status: No, score=-0.523 tagged_above=-999 required=5 tests=[AWL=-1.468, BAYES_40=-0.185, 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 FbpmhAesUZyT for ; Mon, 22 Mar 2010 17:28:52 -0700 (PDT) Received: from ip1mta.uwm.edu (ip1mta.uwm.edu [129.89.7.18]) by core3.amsl.com (Postfix) with ESMTP id 5D91928C299 for ; Mon, 22 Mar 2010 17:28:52 -0700 (PDT) Received: from mta02.pantherlink.uwm.edu ([129.89.7.82]) by ip1mta.uwm.edu with ESMTP; 22 Mar 2010 19:29:10 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by mta02.pantherlink.uwm.edu (Postfix) with ESMTP id 4D73D2C3800E; Mon, 22 Mar 2010 19:29:10 -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 INFTJjate6Dj; Mon, 22 Mar 2010 19:29:10 -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 26C412C3800D; Mon, 22 Mar 2010 19:29:10 -0500 (CDT) Date: Mon, 22 Mar 2010 19:29:10 -0500 (CDT) From: Mukul Goyal To: Philip Levis Message-ID: <853133623.8471101269304150064.JavaMail.root@mail02.pantherlink.uwm.edu> In-Reply-To: <94F03BC2-2287-4298-83C1-D5543869A353@cs.stanford.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 Subject: Re: [Roll] P2P performance with current RPL proposal X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Mar 2010 00:28:53 -0000 Yes, I am assuming that we can define a monotonically increasing scope func= tion. A simple example is hop-count. The two points you quoted are not currently there in RPL draft. The scheme = I proposed is based on these points. So, these two points are the delta cha= nge we will need to add in the RPL draft to allow the formation of localize= d P2P-oriented DAGs. Thanks Mukul ----- Original Message ----- From: "Philip Levis" To: "Mukul Goyal" Cc: "roll" Sent: Monday, March 22, 2010 2:35:15 PM GMT -06:00 US/Canada Central Subject: Re: [Roll] P2P performance with current RPL proposal On Mar 22, 2010, at 10:15 AM, Mukul Goyal wrote: > No. As Don pointed out, the route selection is based on an object functio= n desired by the node initiating the route discovery. The only thing based = on hop count at this point is the scope of discovery - how far the DIS trav= els. I guess this also could be changed to a "discovery scope" function if = desired. So then this assumes that the OF has a monotonically increasing (or increas= ing?) scalar value to "scope" the flood? Your prior message said "(a) allowing multicast DIS messages to spread to an originator-specified n= umber of hops and=20 (b) allowing nodes to join a DAG temporarily and leave it if there is not s= ufficient =E2=80=9Crouting interest=E2=80=9D in being part of the DAG." Phil From zach@sensinode.com Mon Mar 22 18:30: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 D57483A6817 for ; Mon, 22 Mar 2010 18:30:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.469 X-Spam-Level: X-Spam-Status: No, score=-2.469 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, 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 psjcdjA+Eh5L for ; Mon, 22 Mar 2010 18:30:29 -0700 (PDT) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by core3.amsl.com (Postfix) with ESMTP id 0C6E83A67E5 for ; Mon, 22 Mar 2010 18:30:28 -0700 (PDT) Received: from dhcp-wireless-open-abg-26-31.meeting.ietf.org (dhcp-wireless-open-abg-26-31.meeting.ietf.org [130.129.26.31]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.4/8.13.4) with ESMTP id o2N1UVTU015031 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 23 Mar 2010 03:30:35 +0200 Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=windows-1252 From: Zach Shelby In-Reply-To: <853133623.8471101269304150064.JavaMail.root@mail02.pantherlink.uwm.edu> Date: Mon, 22 Mar 2010 18:30:30 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <1B97B066-D0DA-4B0E-8071-30B1DDF712A8@sensinode.com> References: <853133623.8471101269304150064.JavaMail.root@mail02.pantherlink.uwm.edu> To: Mukul Goyal X-Mailer: Apple Mail (2.1077) Cc: roll Subject: Re: [Roll] P2P performance with current RPL proposal X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Mar 2010 01:30:31 -0000 Hi Mukul, This starts to sound promising! It would be great if you guys could = write an I-D explaining how this would work, which could later be = integrated into the rpl document. That makes it easier to evaluate and = refine, and we can read it a whole lot faster than rpl-08 ;-) Thanks, Zach On Mar 22, 2010, at 17:29 , Mukul Goyal wrote: > Yes, I am assuming that we can define a monotonically increasing scope = function. A simple example is hop-count. >=20 > The two points you quoted are not currently there in RPL draft. The = scheme I proposed is based on these points. So, these two points are the = delta change we will need to add in the RPL draft to allow the formation = of localized P2P-oriented DAGs. >=20 > Thanks > Mukul >=20 > ----- Original Message ----- > From: "Philip Levis" > To: "Mukul Goyal" > Cc: "roll" > Sent: Monday, March 22, 2010 2:35:15 PM GMT -06:00 US/Canada Central > Subject: Re: [Roll] P2P performance with current RPL proposal >=20 >=20 > On Mar 22, 2010, at 10:15 AM, Mukul Goyal wrote: >=20 >> No. As Don pointed out, the route selection is based on an object = function desired by the node initiating the route discovery. The only = thing based on hop count at this point is the scope of discovery - how = far the DIS travels. I guess this also could be changed to a "discovery = scope" function if desired. >=20 > So then this assumes that the OF has a monotonically increasing (or = increasing?) scalar value to "scope" the flood? Your prior message said >=20 > "(a) allowing multicast DIS messages to spread to an = originator-specified number of hops and=20 > (b) allowing nodes to join a DAG temporarily and leave it if there is = not sufficient =93routing interest=94 in being part of the DAG." >=20 > Phil > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll --=20 http://www.sensinode.com http://zachshelby.org - My blog "On the Internet of Things" http://6lowpan.net - New book - "6LoWPAN: The Wireless Embedded = Internet" Mobile: +358 40 7796297 Zach Shelby Head of Research Sensinode Ltd. Kidekuja 2 88610 Vuokatti, FINLAND This e-mail and all attached material are confidential and may contain = legally privileged information. If you are not the intended recipient, = please contact the sender and delete the e-mail from your system without = producing, distributing or retaining copies thereof.=20 From pal@cs.stanford.edu Mon Mar 22 18:36: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 AA0713A68F6 for ; Mon, 22 Mar 2010 18:36:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.493 X-Spam-Level: X-Spam-Status: No, score=-4.493 tagged_above=-999 required=5 tests=[AWL=0.976, 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 O5p-GzboSAy0 for ; Mon, 22 Mar 2010 18:36:26 -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 C27B63A68F3 for ; Mon, 22 Mar 2010 18:36:26 -0700 (PDT) Received: from dhcp-wireless-open-abg-29-78.meeting.ietf.org ([130.129.29.78]) by cs-smtp-1.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1Ntt2y-00059J-D1; Mon, 22 Mar 2010 18:36:44 -0700 Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Philip Levis In-Reply-To: <8E09C72DBC577D489F13A71228C0B7BF010FF65D@ftrdmel0.rd.francetelecom.fr> Date: Mon, 22 Mar 2010 18:36:43 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <8E09C72DBC577D489F13A71228C0B7BF010FEFE9@ftrdmel0.rd.francetelecom.fr> <5C4CCBDE-4397-4797-89CD-81C0EA59E1B1@cs.stanford.edu> <8E09C72DBC577D489F13A71228C0B7BF010FF65D@ftrdmel0.rd.francetelecom.fr> To: X-Mailer: Apple Mail (2.1077) X-Scan-Signature: 7e839a9fe5d3c1ffc6f045e071031982 Cc: roll@ietf.org Subject: Re: [Roll] Options in DIS X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 23 Mar 2010 01:36:27 -0000 On Mar 22, 2010, at 4:48 PM, = wrote: > Hi Phil, >=20 > Thanks for your reply. Maybe I was not clear enough that we do = understand the benefit of DIO trickle timers and of routing improvements = over time, and we indeed intend to use them. The use of DIS, in my mind, = was not substitute to DIOs. >=20 > As you mention, Trickle timers are so powerful that they will suppress = many DIO transmissions and that's good for energy consumption. > Yet, relying solely on DIOs, the worker on the field might have to = wait for a very long time for anything to happen on the node that he/she = just installed. I already mentioned we don't want him/her to leave the = premises until he/she has ascertained that decent minimal connectivity = can be established: the node might need to be moved, or "coverage = extenders" installed in the vicinity, which he/she needs to find during = the same field trip. >=20 > In some networks I'm interested in, recuring background activity = happens about every hour. If I want these networks to have a similar = lifetime with RPL than they currently have with proprietary protocols, = the max interval for Trickle timers should also be about an hour. > Trickle timers will, as you just mentioned, suppress most = transmissions in a given radio neighborhood. Therefore, even in dense = networks, my field worker will sit waiting for dozens of minutes, = typically. Do you know any commercial company that will tolerate this? = The mandate is more like less than a minute. Current proprietary = procotols do achieve this through some router discovery protocol = [Maleysson2005]. > If we want to transition these networks to RPL, there needs to be a = way for the new node to trigger its insertion into the network, and my = understanding is that DIS are meant just for that. > Am I missing something here? >=20 If a node sends a DIS, this will cause all node that receive the DIS to = reset their Trickle timers. They will now have small transmission = intervals for DIOs. However, these transmissions will suppress one = another, such that you don't get an O(neighbors) response : Trickle's = suppression will reduce the transmissions to k * log(neighbors). If the = concern is that "bad" DIOs suppress "better" DIOs, this is a problem = generally: we can define redundancy such that "bad" DIOs are not = redundant to "better" DIOs. Does that make sense? Am I understanding the problem correctly? Phil From dominique.barthel@orange-ftgroup.com Mon Mar 22 18:42: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 D0C743A6407 for ; Mon, 22 Mar 2010 18:42:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.301 X-Spam-Level: X-Spam-Status: No, score=-0.301 tagged_above=-999 required=5 tests=[AWL=-0.783, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, HELO_EQ_FR=0.35, 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 8wW-orH4NZVY for ; Mon, 22 Mar 2010 18:42:00 -0700 (PDT) Received: from p-mail1.rd.francetelecom.com (p-mail1.rd.francetelecom.com [195.101.245.15]) by core3.amsl.com (Postfix) with ESMTP id A9EB93A67B4 for ; Mon, 22 Mar 2010 18:41:59 -0700 (PDT) Received: from p-mail1.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 3943E8B8003 for ; Tue, 23 Mar 2010 02:38:46 +0000 (UTC) Received: from ftrdsmtp1.rd.francetelecom.fr (unknown [10.192.128.46]) by p-mail1.rd.francetelecom.com (Postfix) with ESMTP id 492DA8B8001 for ; Tue, 23 Mar 2010 02:38:37 +0000 (UTC) Received: from ftrdmel0.rd.francetelecom.fr ([10.192.128.56]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Tue, 23 Mar 2010 02:39:10 +0100 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_01CACA29.A1E51CD6" Date: Tue, 23 Mar 2010 02:37:43 +0100 Message-ID: <8E09C72DBC577D489F13A71228C0B7BF010FF664@ftrdmel0.rd.francetelecom.fr> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: DIS and ticket #24 Thread-Index: AcrKKW7f/z0Bz0zYQqanCpGkpOmiCg== From: To: X-OriginalArrivalTime: 23 Mar 2010 01:39:10.0044 (UTC) FILETIME=[A26469C0:01CACA29] Subject: [Roll] DIS and ticket #24 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 23 Mar 2010 01:42:01 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CACA29.A1E51CD6 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, Due to limited time during today's meeting, I couldn't get a slot at the microphone. Let me then express my comment on the mailing list. I like Phil's and Pascal's proposal to distinguish establishing good (P2P) routes on the long run from quickly (and efficiently) establishing a reasonable route, and splitting ticket #24 into two for that purpose. If #24 were indeed split in two, I'd be happy to contribute to the latter half. Any connection to the "Options in DIS" thread would obviously be accidental ;-) Dominique ------_=_NextPart_001_01CACA29.A1E51CD6 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable DIS and ticket #24

Hi all,

Due to limited time during today's = meeting, I couldn't get a slot at the microphone.
Let me then express my comment on the = mailing list.
I like Phil's and Pascal's proposal to = distinguish establishing good (P2P) routes on the long run from quickly = (and efficiently) establishing a reasonable route, and splitting ticket = #24 into two for that purpose.

If #24 were indeed split in two, I'd be = happy to contribute to the latter half. Any connection to the = "Options in DIS" thread would obviously be accidental = ;-)

Dominique

------_=_NextPart_001_01CACA29.A1E51CD6-- From gnawali@cs.stanford.edu Mon Mar 22 18:55: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 68BF23A6824 for ; Mon, 22 Mar 2010 18:55:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.112 X-Spam-Level: X-Spam-Status: No, score=-4.112 tagged_above=-999 required=5 tests=[AWL=-1.865, BAYES_50=0.001, 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 eQ4LZteKcZIF for ; Mon, 22 Mar 2010 18:55:07 -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 C97073A680C for ; Mon, 22 Mar 2010 18:55:07 -0700 (PDT) Received: from mail-qy0-f177.google.com ([209.85.221.177]) by cs-smtp-1.Stanford.EDU with esmtpsa (TLSv1:RC4-MD5:128) (Exim 4.60) (envelope-from ) id 1NttL3-0006Vb-U2 for roll@ietf.org; Mon, 22 Mar 2010 18:55:26 -0700 Received: by qyk7 with SMTP id 7so3017753qyk.17 for ; Mon, 22 Mar 2010 18:55:25 -0700 (PDT) MIME-Version: 1.0 Received: by 10.224.72.154 with SMTP id m26mr1533808qaj.63.1269309325093; Mon, 22 Mar 2010 18:55:25 -0700 (PDT) From: Omprakash Gnawali Date: Mon, 22 Mar 2010 18:55:05 -0700 Message-ID: To: ROLL WG Content-Type: text/plain; charset=ISO-8859-1 X-Scan-Signature: c34b9e52c8715c7e60548704bd659ba6 Subject: [Roll] typo 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, 23 Mar 2010 01:55:08 -0000 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. ... Val: LQL value from 0 to 3 where 0 means undetermined and 1 indicates the lowest link quality. Is 1 lowest or highest quality? Is that a typo? - om_p From teco@inf-net.nl Mon Mar 22 20:20: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 1D4293A69EA for ; Mon, 22 Mar 2010 20:20:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.431 X-Spam-Level: ** X-Spam-Status: No, score=2.431 tagged_above=-999 required=5 tests=[DNS_FROM_OPENWHOIS=2.431] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YXM0nkXQYVuJ for ; Mon, 22 Mar 2010 20:20:20 -0700 (PDT) Received: from mail-iw0-f197.google.com (mail-iw0-f197.google.com [209.85.223.197]) by core3.amsl.com (Postfix) with ESMTP id 639823A6A38 for ; Mon, 22 Mar 2010 20:19:56 -0700 (PDT) Received: by iwn35 with SMTP id 35so3398492iwn.31 for ; Mon, 22 Mar 2010 20:20:09 -0700 (PDT) Received: by 10.231.169.145 with SMTP id z17mr2319096iby.83.1269314408899; Mon, 22 Mar 2010 20:20:08 -0700 (PDT) Received: from dhcp-wireless-open-abg-24-146.meeting.ietf.org (dhcp-wireless-open-abg-24-146.meeting.ietf.org [130.129.24.146]) by mx.google.com with ESMTPS id a1sm2108980ibs.0.2010.03.22.20.20.07 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 22 Mar 2010 20:20:08 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1077) From: Teco Boot In-Reply-To: <4B8B0A9B.3020005@acm.org> Date: Tue, 23 Mar 2010 04:20:05 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <5C7956DC-0656-44A0-810E-6F5368EF61C5@inf-net.nl> References: <6A2A459175DABE4BB11DE2026AA50A5D0151C08B@XMB-AMS-107.cisco.com> <054001cab646$432d5210$c987f630$@sturek@att.net> <4B8B0A9B.3020005@acm.org> To: roll@ietf.org X-Mailer: Apple Mail (2.1077) Subject: [Roll] Question on RPL source / destination addresses X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 23 Mar 2010 03:20:21 -0000 Hi, With the switch from ND RA option to ICMP messages, there is more = freedom on addresses used. Current RLP draft does not specify the addresses used, or at least not = always. We could ask for a AllRplRouters multicast (link-local) address. Open a ticket for this? Regards, Teco From mijeom@gmail.com Mon Mar 22 21:24: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 8C6113A6962 for ; Mon, 22 Mar 2010 21:24:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.431 X-Spam-Level: ** X-Spam-Status: No, score=2.431 tagged_above=-999 required=5 tests=[DNS_FROM_OPENWHOIS=2.431] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9gL9LNr7PNz4 for ; Mon, 22 Mar 2010 21:24:22 -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 CBDA33A6921 for ; Mon, 22 Mar 2010 21:24:21 -0700 (PDT) Received: by gwj23 with SMTP id 23so445571gwj.31 for ; Mon, 22 Mar 2010 21:24:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=jjNbRaU0VAxYwMThKYrxlB9OKFo1EV4T6cms/nviYs8=; b=I24j+WH/dRbdhfu0IuIaDdwxkDvWenColTWMxDn4ukf+Pb7SKW0TpGNHQOMy36KlPf JyHy7kekVX6xRvdWAWwLYYu8qgOJjIwv7UAvDBx0wD5NY+cT1Ro+QDYiVOJkGtj15FMI roZQRDlerY6S3e5wS+642KyVd91LNEsAU9ohA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=tQ6l06eG0MJlQy3P1XSzKYI2oTu/OSwTnWWJy6okdDLryJY4+ajMjovDa5aRfGEKhx ZlIYzAtx4X5DHtTsjj2iTDxrooyYL/LW74ztDI73uoWMgr1ViTsu7G9739q9tXHKt4LO nTaaxRikGs4c0REBCiRmr32uF0sFqVSzUSmAQ= MIME-Version: 1.0 Received: by 10.91.22.14 with SMTP id z14mr5163344agi.99.1269318276902; Mon, 22 Mar 2010 21:24:36 -0700 (PDT) In-Reply-To: References: Date: Tue, 23 Mar 2010 13:24:36 +0900 Message-ID: From: MiJeom Kim To: ROLL WG Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [Roll] typo 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, 23 Mar 2010 04:24:22 -0000 Hi, That's definitely typo. 1 is the lowest and 3 is the highest. Thanks, Mijeom. On Tue, Mar 23, 2010 at 10:55 AM, Omprakash Gnawali wrote: > 4.3.1. > ... > =A0 The Link Quality Level (LQL) object is used to quantify the link > =A0 reliability using a discrete value, from 0 to 3 where 0 indicates > =A0 that the link quality level is unknown and 1 reports the highest link > =A0 quality level. > > ... > > =A0 Val: LQL value from 0 to 3 where 0 means undetermined and 1 indicates > =A0 the lowest link quality. > > Is 1 lowest or highest quality? Is that a typo? > > - om_p > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > From gnawali@cs.stanford.edu Mon Mar 22 23:26: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 5950D3A6967 for ; Mon, 22 Mar 2010 23:26:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.947 X-Spam-Level: X-Spam-Status: No, score=-0.947 tagged_above=-999 required=5 tests=[DNS_FROM_OPENWHOIS=2.431, 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 nCKIuUFiNZ5T for ; Mon, 22 Mar 2010 23:26:33 -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 675A43A698F for ; Mon, 22 Mar 2010 23:26:33 -0700 (PDT) Received: from mail-qy0-f177.google.com ([209.85.221.177]) by cs-smtp-1.Stanford.EDU with esmtpsa (TLSv1:RC4-MD5:128) (Exim 4.60) (envelope-from ) id 1NtxZj-0002zo-KY for roll@ietf.org; Mon, 22 Mar 2010 23:26:52 -0700 Received: by qyk7 with SMTP id 7so3155300qyk.17 for ; Mon, 22 Mar 2010 23:26:50 -0700 (PDT) MIME-Version: 1.0 Received: by 10.224.96.134 with SMTP id h6mr2652562qan.122.1269325609217; Mon, 22 Mar 2010 23:26:49 -0700 (PDT) From: Omprakash Gnawali Date: Mon, 22 Mar 2010 23:26:29 -0700 Message-ID: To: ROLL WG Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-Scan-Signature: 2ecb59bd28923317bd193fe54b7794cd Subject: [Roll] state overhead for ETX computation / draft-gnawali-roll-etxof X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 23 Mar 2010 06:26:34 -0000 Dear all, There was a question during my presentation today on the ETX Objective Func= tion about the state requirement to estimate the ETX metric of links. The concer= n was a parent needs to keep track of PRR for link to each child. If a parent has= 1000 children, the PRR estimation table needs to have 1000 entries. Although the draft I was presenting or the metrics draft does not go into t= he details of ETX computation, it is important to be convinced that it is poss= ible to compute ETX without such unacceptable state overhead. Traditionally, ETX is estimated by collecting unidirectional PRR estimates and combining them using 1 / (Pr*Pb). This method is presented as an example in the metrics draft, for example. I= f we use this approach, it is true that if a parent had n children, you would need n entries in the ETX estimation table. However, there are newer, and also mature, ways to compute ETX that does not require an entry for each children to estimate bi-directional ETX. There was a paper in Mobicom 2006 [EAR], that showed how to use the data-link acks to measure ETX without estimating PRR for each direction separately. There was a paper in HotNets 2007 [4bitle] that showed ETX measurements that also used data-link acks. This paper compares a DAG formed using the "traditional" ETX estimates and using the [4bitle] estimator. The observation was, if we don't have room in our ETX estimation table for each neighboring node, the DAG formed is sub-optimal due to the unavailability of bi-directional ETX on many links that are perfectly usable. However, with the 4bitle ETX estimation, you can maintain a small number of entries on the ETX witho= ut compromising the quality of the DAG, while still routing based on the ETX metric. In later work, a routing protocol called CTP Noe [CTP] showed how to use the 4bitle ETX estimator in a number of scenarios in sparse and dense networks. Even in the densest network, which had a (min,max) node degree of (214,305), CTP Noe was able t= o estimate the link ETX and compute efficient and reliable routes between the nodes and the root using ETX. Even in such a network, it was sufficient to have 10 entries in the ETX estimation table. We cannot use the "traditional" estimation technique in these dense networks with high node degree, but there are proven, and now mature techniques to compute ETX for dense networks. So, state overhead is not a concern for link ETX measurement even in dense networks with a large number of neighbors and children. [EAR] K.-H. Kim and K. Shin. On Accurate Measurement of Link Quality in Multi-hop Wireless Mesh Networks. In Proc. of the ACM MobiCom Conf., pages 38=9649, Los Angeles, CA, Sept. 2006. [4bitle] R. Fonseca, O. Gnawali, K. Jamieson, and P. Levis. Four Bit Wireless Link Estimation. In Hotnets-VI, Atlanta, GA, Nov. 2007. [CTP] O. Gnawali, R. Fonseca, K. Jamieson, D. Moss, and P. Levis. Collection Tree Protocol. In Proceedings of the 7th ACM Conference on Embedded Networked Sensor Systems (SenSys), 2009. - om_p From Matteo.Paris@ember.com Tue Mar 23 06:34: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 280A93A6A50 for ; Tue, 23 Mar 2010 06:34:53 -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 01PYrImj0JSs for ; Tue, 23 Mar 2010 06:34:49 -0700 (PDT) Received: from EMPIRE.hq.ember.com (mail.ember.com [74.10.175.227]) by core3.amsl.com (Postfix) with ESMTP id 24F083A6A45 for ; Tue, 23 Mar 2010 06:34:49 -0700 (PDT) Received: from [192.168.1.102] ([192.168.81.20]) by EMPIRE.hq.ember.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 23 Mar 2010 09:37:57 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: References: <8E09C72DBC577D489F13A71228C0B7BF010FEFE9@ftrdmel0.rd.francetelecom.fr> <5C4CCBDE-4397-4797-89CD-81C0EA59E1B1@cs.stanford.edu> <8E09C72DBC577D489F13A71228C0B7BF010FF65D@ftrdmel0.rd.francetelecom.fr> Date: Tue, 23 Mar 2010 09:35:06 -0400 To: Philip Levis From: Matteo Paris Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-OriginalArrivalTime: 23 Mar 2010 13:37:57.0639 (UTC) FILETIME=[0C712970:01CACA8E] Cc: roll@ietf.org Subject: Re: [Roll] Options in DIS X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 23 Mar 2010 13:34:53 -0000 Hi Phil, The concern that I raised did not have to do with trying to further suppress DIO messages within a single DODAG beyond what is provided by Trickle. Rather, I described the scenario in which there are multiple DODAGS (dozens) in a dense network (eg, hundreds of nodes within radio range of each other). It is often the case that the node sending the DIS has specific information about which DODAG it is interested in, in the form of destination prefixes, dag ids, instance ids, etc. If this information were contained in the DIS, the filtering could happen prior to transmission of DIOs, saving the network from significant unneccessary disruption. What do you think? Matteo At 6:36 PM -0700 3/22/10, Philip Levis wrote: >On Mar 22, 2010, at 4:48 PM, > wrote: > >> Hi Phil, >> >> Thanks for your reply. Maybe I was not clear enough that we do >>understand the benefit of DIO trickle timers and of routing >>improvements over time, and we indeed intend to use them. The use >>of DIS, in my mind, was not substitute to DIOs. >> >> As you mention, Trickle timers are so powerful that they will >>suppress many DIO transmissions and that's good for energy >>consumption. >> Yet, relying solely on DIOs, the worker on the field might have to >>wait for a very long time for anything to happen on the node that >>he/she just installed. I already mentioned we don't want him/her to >>leave the premises until he/she has ascertained that decent minimal >>connectivity can be established: the node might need to be moved, >>or "coverage extenders" installed in the vicinity, which he/she >>needs to find during the same field trip. >> >> In some networks I'm interested in, recuring background activity >>happens about every hour. If I want these networks to have a >>similar lifetime with RPL than they currently have with proprietary >>protocols, the max interval for Trickle timers should also be about >>an hour. >> Trickle timers will, as you just mentioned, suppress most >>transmissions in a given radio neighborhood. Therefore, even in >>dense networks, my field worker will sit waiting for dozens of >>minutes, typically. Do you know any commercial company that will >>tolerate this? The mandate is more like less than a minute. Current >>proprietary procotols do achieve this through some router discovery >>protocol [Maleysson2005]. >> If we want to transition these networks to RPL, there needs to be >>a way for the new node to trigger its insertion into the network, >>and my understanding is that DIS are meant just for that. >> Am I missing something here? > > > >If a node sends a DIS, this will cause all node that receive the DIS >to reset their Trickle timers. They will now have small transmission >intervals for DIOs. However, these transmissions will suppress one >another, such that you don't get an O(neighbors) response : >Trickle's suppression will reduce the transmissions to k * >log(neighbors). If the concern is that "bad" DIOs suppress "better" >DIOs, this is a problem generally: we can define redundancy such >that "bad" DIOs are not redundant to "better" DIOs. > >Does that make sense? Am I understanding the problem correctly? > >Phil > >_______________________________________________ >Roll mailing list >Roll@ietf.org >https://www.ietf.org/mailman/listinfo/roll From pal@cs.stanford.edu Tue Mar 23 08:09: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 CED9D3A6BE5 for ; Tue, 23 Mar 2010 08:09:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.869 X-Spam-Level: X-Spam-Status: No, score=-2.869 tagged_above=-999 required=5 tests=[BAYES_50=0.001, 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 NOjGL78xw3IN for ; Tue, 23 Mar 2010 08:09:02 -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 E08273A68C2 for ; Tue, 23 Mar 2010 08:08:22 -0700 (PDT) Received: from [76.14.71.8] (helo=[192.168.1.103]) by cs-smtp-1.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1Nu5ik-0007gy-0i; Tue, 23 Mar 2010 08:08:42 -0700 Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Philip Levis In-Reply-To: Date: Tue, 23 Mar 2010 08:08:41 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <8E09C72DBC577D489F13A71228C0B7BF010FEFE9@ftrdmel0.rd.francetelecom.fr> <5C4CCBDE-4397-4797-89CD-81C0EA59E1B1@cs.stanford.edu> <8E09C72DBC577D489F13A71228C0B7BF010FF65D@ftrdmel0.rd.francetelecom.fr> To: Matteo Paris X-Mailer: Apple Mail (2.1077) X-Scan-Signature: b64bce576883819501cf77c9371f4538 Cc: roll@ietf.org Subject: Re: [Roll] Options in DIS X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 23 Mar 2010 15:09:03 -0000 On Mar 23, 2010, at 6:35 AM, Matteo Paris wrote: >=20 > Hi Phil, >=20 > The concern that I raised did not have to do with trying to further = suppress DIO messages within a single DODAG beyond what is provided by = Trickle. >=20 > Rather, I described the scenario in which there are multiple DODAGS = (dozens) in a dense network (eg, hundreds of nodes within radio range of = each other). It is often the case that the node sending the DIS has = specific information about which DODAG it is interested in, in the form = of destination prefixes, dag ids, instance ids, etc. If this = information were contained in the DIS, the filtering could happen prior = to transmission of DIOs, saving the network from significant = unneccessary disruption. >=20 > What do you think? >=20 I think this makes total sense. But should it be a standard DIS field, = or a DIS option? If a standard field there will need to be an all = IDs/broadcast value. Phil From jpv@cisco.com Tue Mar 23 09:59: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 853513A6874 for ; Tue, 23 Mar 2010 09:59:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.169 X-Spam-Level: X-Spam-Status: No, score=-8.169 tagged_above=-999 required=5 tests=[AWL=1.300, 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 TCmH6CJ9eyzH for ; Tue, 23 Mar 2010 09:59:44 -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 9DFFD3A69A4 for ; Tue, 23 Mar 2010 09:59:36 -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: AvsEAKuQqEurR7H+/2dsb2JhbACbKXOkFZkwhH0Egx4 X-IronPort-AV: E=Sophos;i="4.51,296,1267401600"; d="scan'208";a="104464749" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-4.cisco.com with ESMTP; 23 Mar 2010 16:59:55 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o2NGxtm6002184 for ; Tue, 23 Mar 2010 16:59:55 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 23 Mar 2010 09:59:55 -0700 Received: from [130.129.26.235] ([10.21.70.100]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 23 Mar 2010 09:59:55 -0700 Message-Id: <4DD685CB-4642-446F-9AC9-238CF22E0B5A@cisco.com> From: JP Vasseur To: ROLL WG Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 23 Mar 2010 09:55:26 -0700 X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 23 Mar 2010 16:59:55.0534 (UTC) FILETIME=[434532E0:01CACAAA] Subject: [Roll] Security Framework moving to WG document X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Mar 2010 16:59:45 -0000 Dear WG, The security framework has been presented several times and reach a point where it was time to poll the WG for WG adoption. There was a really good consensus to make it a WG document but as usual let's confirm on the mailing list. Should you be opposed to make it a WG please voice your opinion on the list before March 30. Thanks. JP. From jpv@cisco.com Tue Mar 23 09:59: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 986B23A69A4 for ; Tue, 23 Mar 2010 09:59:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.169 X-Spam-Level: X-Spam-Status: No, score=-8.169 tagged_above=-999 required=5 tests=[AWL=1.300, 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 lgczbt7i0hvU for ; Tue, 23 Mar 2010 09:59:45 -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 7E8883A69D9 for ; Tue, 23 Mar 2010 09:59:37 -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: AvsEALuPqEurR7Ht/2dsb2JhbACbKXOkB5kvhH0Egx4 X-IronPort-AV: E=Sophos;i="4.51,296,1267401600"; d="scan'208";a="170920976" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-5.cisco.com with ESMTP; 23 Mar 2010 16:59:56 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o2NGxuEP012623 for ; Tue, 23 Mar 2010 16:59:56 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 23 Mar 2010 09:59:56 -0700 Received: from [130.129.26.235] ([10.21.70.100]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 23 Mar 2010 09:59:56 -0700 Message-Id: <67027460-07B2-4098-A53F-4C82B885801A@cisco.com> From: JP Vasseur To: ROLL WG Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 23 Mar 2010 09:57:29 -0700 X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 23 Mar 2010 16:59:56.0534 (UTC) FILETIME=[43DDC960:01CACAAA] Subject: [Roll] Security Framework moving to WG document X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Mar 2010 16:59:45 -0000 Dear WG, The security framework has been presented several times and reach a point where it was time to poll the WG for WG adoption. There was a really good consensus to make it a WG document but as usual let's confirm on the mailing list. Should you be opposed to make it a WG please voice your opinion on the list before March 30. Thanks. JP. From alexandru.petrescu@gmail.com Tue Mar 23 11:01: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 2ABB53A6C6C for ; Tue, 23 Mar 2010 11:01:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.481 X-Spam-Level: * X-Spam-Status: No, score=1.481 tagged_above=-999 required=5 tests=[BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, 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 mNcVSn6FKg9r for ; Tue, 23 Mar 2010 11:01:14 -0700 (PDT) Received: from smtp5-g21.free.fr (smtp5-g21.free.fr [212.27.42.5]) by core3.amsl.com (Postfix) with ESMTP id 408F13A6CF0 for ; Tue, 23 Mar 2010 10:59:28 -0700 (PDT) Received: from smtp5-g21.free.fr (localhost [127.0.0.1]) by smtp5-g21.free.fr (Postfix) with ESMTP id 424F3D48102; Tue, 23 Mar 2010 18:59:43 +0100 (CET) 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 9A85ED4804B; Tue, 23 Mar 2010 18:59:40 +0100 (CET) Message-ID: <4BA9018A.2050308@gmail.com> Date: Tue, 23 Mar 2010 18:59:38 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; fr; rv:1.9.1.8) Gecko/20100227 Thunderbird/3.0.3 MIME-Version: 1.0 To: "JeongGil Ko (John)" References: <5F75FA0E-5654-4B15-81E1-01F9EDEA16FE@cs.jhu.edu> In-Reply-To: <5F75FA0E-5654-4B15-81E1-01F9EDEA16FE@cs.jhu.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 100323-1, 23/03/2010), Outbound message X-Antivirus-Status: Clean Cc: ROLL WG Subject: Re: [Roll] Questions while implementing RPL. X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Mar 2010 18:01:15 -0000 Hi JeongGil, Someone is asking me about implementation of RPL. Could you please suggest whether the implementation you were about to write could somehow be available to other researchers, PhDs, for evaluation. Thanks in advance, Alex Le 25/01/2010 22:32, JeongGil Ko (John) a écrit : > Hi. > > I am in the process of trying to implement RPL with respect to the > rpl and metrics drafts. In the process, I had a few questions that > was unclear in the writeups. Maybe someone can clear them up for me > :) > > I will take ETX as an example. Let's say our goal is to find a route > that 'minimizes' the aggregated ETX to the gateway (root of the > DODAG). The flags of the routing metric/constraint header will > indicate R=0, G=1, A=0x00, C=0, and O=0. When nodes send DIO messages > will include this information for nodes that receive the DIO to parse > and compute its own ETX for a specific path/parent. In this case, how > would we indicate that 'minimizing' the ETX metric is our goal? On a > receiving node's perspective it just received a DIO message saying > that it is including a metric and the routing object type will be 7 > (recommended for ETX; pp. 20 of [draft-ietf-roll-routing-metrics]). > As a result, the node will have different ETX values from different > potential next hops and would have to select one from them as the > preferred parent node. In the selection process, should it be already > known that minimizing the ETX is the goal (OF) at the node in compile > time? Or is there a way/scheme to infer that minimizing the ETX is > the goal? To make nodes support different OFs dynamically in-run > time, having a way to infer/notify the new OFs (goals) would be nice > but I wonder if this is interesting. If everything is given in > compile time, then we can simply make the nodes that do not recognize > what to do with the OFs as leaf nodes (as stated in the rpl draft). > > Thanks. > > -John > > _______________________________________________ Roll mailing list > Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll > From jeonggil.ko@gmail.com Tue Mar 23 11:12: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 899C63A6D13 for ; Tue, 23 Mar 2010 11:12:11 -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 k5kC4gfb7YPT for ; Tue, 23 Mar 2010 11:12:09 -0700 (PDT) Received: from mail-ew0-f216.google.com (mail-ew0-f216.google.com [209.85.219.216]) by core3.amsl.com (Postfix) with ESMTP id 776A13A6D11 for ; Tue, 23 Mar 2010 11:12:09 -0700 (PDT) Received: by ewy8 with SMTP id 8so749693ewy.28 for ; Tue, 23 Mar 2010 11:12:24 -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=xJbtweMzSlavKiukDDXTgKJmhOTRSR6043sFjGUp9Sw=; b=JE7sjVa9xDrpAnSmFJZUP1cHXMEafvdnfKtzSeWWF8i04khx+C0RRqgSfSyLpbPaTG PtHH1vHwFXvdKfdB9MADB+b0XTUfOYzCLcGAGYg0A9S2HxdQUDKk4IkpaPQW4YvzEVN2 i2eJ8AvFx6h2RMP7AZ1n1EPhDm6+57A1lzaAc= 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=xV6ujuoWFgtBUZYRjiqtmL2XBnfqjMARCaZdpAqU11K7eSOUupb5sAJrchLMB0LD5I Jh7vIJswIdN0REaMEBGAX9utrgr4T3JmvFUqv8dmYlgQ11j3na0YPrIUrZCJb0mBP2sl FCdGU3QktH4ZD3/lb0nBIz+e8e5atGOFrK+Es= Received: by 10.102.164.10 with SMTP id m10mr8838751mue.52.1269367944224; Tue, 23 Mar 2010 11:12:24 -0700 (PDT) Received: from [192.168.1.108] ([76.14.51.89]) by mx.google.com with ESMTPS id w5sm31248782mue.54.2010.03.23.11.12.20 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 23 Mar 2010 11:12:22 -0700 (PDT) Sender: "JeongGil (John) Ko" Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=iso-8859-1 From: "JeongGil Ko (John)" In-Reply-To: <4BA9018A.2050308@gmail.com> Date: Tue, 23 Mar 2010 11:12:17 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5F75FA0E-5654-4B15-81E1-01F9EDEA16FE@cs.jhu.edu> <4BA9018A.2050308@gmail.com> To: Alexandru Petrescu X-Mailer: Apple Mail (2.1077) Cc: ROLL WG Subject: Re: [Roll] Questions while implementing RPL. X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Mar 2010 18:12:11 -0000 Hey Alex, I didn't fully get your question but are you asking about the code = release? The code is still in its pre-pre-pre alpha stage so I wouldn't = say we can evaluate the performance of RPL yet with this code :) = However, I was able to clear many things up in yesterday's meeting so I = can get the speed up a bit now :) The goal, of course, is to make the = code open in TinyOS 2.x. You can tell the person who asked about the = implementation to directly contact me so that I can find someway to make = him/her happy :) Thanks! -John On Mar 23, 2010, at 10:59 AM, Alexandru Petrescu wrote: > Hi JeongGil, >=20 > Someone is asking me about implementation of RPL. Could you please > suggest whether the implementation you were about to write could = somehow > be available to other researchers, PhDs, for evaluation. >=20 > Thanks in advance, >=20 > Alex >=20 > Le 25/01/2010 22:32, JeongGil Ko (John) a =E9crit : >> Hi. >>=20 >> I am in the process of trying to implement RPL with respect to the >> rpl and metrics drafts. In the process, I had a few questions that >> was unclear in the writeups. Maybe someone can clear them up for me >> :) >>=20 >> I will take ETX as an example. Let's say our goal is to find a route >> that 'minimizes' the aggregated ETX to the gateway (root of the >> DODAG). The flags of the routing metric/constraint header will >> indicate R=3D0, G=3D1, A=3D0x00, C=3D0, and O=3D0. When nodes send = DIO messages >> will include this information for nodes that receive the DIO to parse >> and compute its own ETX for a specific path/parent. In this case, how >> would we indicate that 'minimizing' the ETX metric is our goal? On a >> receiving node's perspective it just received a DIO message saying >> that it is including a metric and the routing object type will be 7 >> (recommended for ETX; pp. 20 of [draft-ietf-roll-routing-metrics]). >> As a result, the node will have different ETX values from different >> potential next hops and would have to select one from them as the >> preferred parent node. In the selection process, should it be already >> known that minimizing the ETX is the goal (OF) at the node in compile >> time? Or is there a way/scheme to infer that minimizing the ETX is >> the goal? To make nodes support different OFs dynamically in-run >> time, having a way to infer/notify the new OFs (goals) would be nice >> but I wonder if this is interesting. If everything is given in >> compile time, then we can simply make the nodes that do not recognize >> what to do with the OFs as leaf nodes (as stated in the rpl draft). >>=20 >> Thanks. >>=20 >> -John >>=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 From pal@cs.stanford.edu Tue Mar 23 11:14: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 D6CE63A696E for ; Tue, 23 Mar 2010 11:14:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.869 X-Spam-Level: X-Spam-Status: No, score=-2.869 tagged_above=-999 required=5 tests=[BAYES_50=0.001, 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 wJzNSSQ6cGFb for ; Tue, 23 Mar 2010 11:14:19 -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 47B6E3A69C6 for ; Tue, 23 Mar 2010 11:13:49 -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 1Nu8c8-0002v6-DV; Tue, 23 Mar 2010 11:14:04 -0700 Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Philip Levis In-Reply-To: Date: Tue, 23 Mar 2010 11:14:04 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <29E60EEC-8BC8-4331-B2CD-EB481A901DE0@cs.stanford.edu> References: <5F75FA0E-5654-4B15-81E1-01F9EDEA16FE@cs.jhu.edu> <4BA9018A.2050308@gmail.com> To: JeongGil Ko (John) X-Mailer: Apple Mail (2.1077) X-Scan-Signature: 6bee508a35d8245455fa42c2dd36c733 Cc: ROLL WG Subject: Re: [Roll] Questions while implementing RPL. X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Mar 2010 18:14:24 -0000 On Mar 23, 2010, at 11:12 AM, JeongGil Ko (John) wrote: > Hey Alex, >=20 > I didn't fully get your question but are you asking about the code = release? The code is still in its pre-pre-pre alpha stage so I wouldn't = say we can evaluate the performance of RPL yet with this code :) = However, I was able to clear many things up in yesterday's meeting so I = can get the speed up a bit now :) The goal, of course, is to make the = code open in TinyOS 2.x. You can tell the person who asked about the = implementation to directly contact me so that I can find someway to make = him/her happy :) >=20 > Thanks! One side note -- TinyOS code is under a BSD license. Phil= From root@core3.amsl.com Tue Mar 23 11:15:04 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 1FEA93A6A2B; Tue, 23 Mar 2010 11:15:02 -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: <20100323181503.1FEA93A6A2B@core3.amsl.com> Date: Tue, 23 Mar 2010 11:15:02 -0700 (PDT) Cc: roll@ietf.org Subject: [Roll] I-D Action:draft-ietf-roll-trickle-00.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Mar 2010 18:15:04 -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, T. Clausen Filename : draft-ietf-roll-trickle-00.txt Pages : 8 Date : 2010-03-23 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-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-roll-trickle-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-03-23111215.I-D@ietf.org> --NextPart-- From alexandru.petrescu@gmail.com Tue Mar 23 11:25: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 EE5BD3A6B70 for ; Tue, 23 Mar 2010 11:25:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.481 X-Spam-Level: * X-Spam-Status: No, score=1.481 tagged_above=-999 required=5 tests=[BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, 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 QLoGcgi0IUUl for ; Tue, 23 Mar 2010 11:25:32 -0700 (PDT) Received: from smtp5-g21.free.fr (smtp5-g21.free.fr [212.27.42.5]) by core3.amsl.com (Postfix) with ESMTP id 5D1203A684F for ; Tue, 23 Mar 2010 11:25:28 -0700 (PDT) Received: from smtp5-g21.free.fr (localhost [127.0.0.1]) by smtp5-g21.free.fr (Postfix) with ESMTP id 05CEDD4804E; Tue, 23 Mar 2010 19:25:44 +0100 (CET) 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 E0162D48179; Tue, 23 Mar 2010 19:25:41 +0100 (CET) Message-ID: <4BA907A3.7040909@gmail.com> Date: Tue, 23 Mar 2010 19:25:39 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; fr; rv:1.9.1.8) Gecko/20100227 Thunderbird/3.0.3 MIME-Version: 1.0 To: "JeongGil Ko (John)" References: <5F75FA0E-5654-4B15-81E1-01F9EDEA16FE@cs.jhu.edu> <4BA9018A.2050308@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 100323-1, 23/03/2010), Outbound message X-Antivirus-Status: Clean Cc: ROLL WG Subject: Re: [Roll] Questions while implementing RPL. X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Mar 2010 18:25:34 -0000 Le 23/03/2010 19:12, JeongGil Ko (John) a écrit : > Hey Alex, > > I didn't fully get your question but are you asking about the code > release? The code is still in its pre-pre-pre alpha stage so I > wouldn't say we can evaluate the performance of RPL yet with this > code :) However, I was able to clear many things up in yesterday's > meeting so I can get the speed up a bit now :) The goal, of course, > is to make the code open in TinyOS 2.x. You can tell the person who > asked about the implementation to directly contact me so that I can > find someway to make him/her happy :) Sure, Cc'ed you in private, check private email. Thanks for the reply, Alex > > Thanks! > > -John > > On Mar 23, 2010, at 10:59 AM, Alexandru Petrescu wrote: > >> Hi JeongGil, >> >> Someone is asking me about implementation of RPL. Could you >> please suggest whether the implementation you were about to write >> could somehow be available to other researchers, PhDs, for >> evaluation. >> >> Thanks in advance, >> >> Alex >> >> Le 25/01/2010 22:32, JeongGil Ko (John) a écrit : >>> Hi. >>> >>> I am in the process of trying to implement RPL with respect to >>> the rpl and metrics drafts. In the process, I had a few questions >>> that was unclear in the writeups. Maybe someone can clear them up >>> for me :) >>> >>> I will take ETX as an example. Let's say our goal is to find a >>> route that 'minimizes' the aggregated ETX to the gateway (root of >>> the DODAG). The flags of the routing metric/constraint header >>> will indicate R=0, G=1, A=0x00, C=0, and O=0. When nodes send DIO >>> messages will include this information for nodes that receive the >>> DIO to parse and compute its own ETX for a specific path/parent. >>> In this case, how would we indicate that 'minimizing' the ETX >>> metric is our goal? On a receiving node's perspective it just >>> received a DIO message saying that it is including a metric and >>> the routing object type will be 7 (recommended for ETX; pp. 20 of >>> [draft-ietf-roll-routing-metrics]). As a result, the node will >>> have different ETX values from different potential next hops and >>> would have to select one from them as the preferred parent node. >>> In the selection process, should it be already known that >>> minimizing the ETX is the goal (OF) at the node in compile time? >>> Or is there a way/scheme to infer that minimizing the ETX is the >>> goal? To make nodes support different OFs dynamically in-run >>> time, having a way to infer/notify the new OFs (goals) would be >>> nice but I wonder if this is interesting. If everything is given >>> in compile time, then we can simply make the nodes that do not >>> recognize what to do with the OFs as leaf nodes (as stated in the >>> rpl draft). >>> >>> Thanks. >>> >>> -John >>> >>> _______________________________________________ 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 pister@eecs.berkeley.edu Tue Mar 23 13:14: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 48D1B3A6876 for ; Tue, 23 Mar 2010 13:14:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.868 X-Spam-Level: X-Spam-Status: No, score=-2.868 tagged_above=-999 required=5 tests=[BAYES_50=0.001, 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 wpct2Y2PEj9D for ; Tue, 23 Mar 2010 13:14:09 -0700 (PDT) Received: from gateway0.EECS.Berkeley.EDU (gateway0.EECS.Berkeley.EDU [169.229.60.87]) by core3.amsl.com (Postfix) with ESMTP id DD5A43A6784 for ; Tue, 23 Mar 2010 13:14:07 -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 o2NKEPC3018747 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 23 Mar 2010 13:14:26 -0700 (PDT) Message-ID: <4BA92120.4000907@eecs.berkeley.edu> Date: Tue, 23 Mar 2010 13:14:24 -0700 From: Kris Pister User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Robert Assimiti References: <67442429D9C35E4C975B89BE73BD33D015FB214273@ATLEXCH02.nivis.com> In-Reply-To: <67442429D9C35E4C975B89BE73BD33D015FB214273@ATLEXCH02.nivis.com> Content-Type: multipart/alternative; boundary="------------020909070909060508040901" Cc: "roll@ietf.org" Subject: Re: [Roll] Triggering a new DODAG iteration X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 23 Mar 2010 20:14:14 -0000 This is a multi-part message in MIME format. --------------020909070909060508040901 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit I'm a big fan of having error messages as well as status/summary messages reported to the DAG root. Status is one of the important tools for detecting insider attacks on the network. Having a regular summary of what each node is hearing from its neighbors about rank, etc., would help catch attacks as well as bugs, and help with your iteration trigger. ksjp Robert Assimiti wrote: > > As you can imagine, triggering a new DODAG iteration in a wireless > subnet that scales to thousands of wireless nodes can be quite > disruptive to the operation of the subnet. > > > > The criteria that will trigger a new DODAG iteration should (in my > opinion) be left to the implementation. > > The decision of triggering a new DODAG iteration lies with the root. > > A well informed root can make better decisions than an un-informed root. > > > > Hence I propose that we discuss additional standardized error messages > reported by the routers. > > At this point nodes can flag rank and forwarding errors through the > usage of the 'R' and 'F' bits present in the flow label. > > > > In my opinion, this is a very limited set of error messages. > > Since we are seeking interoperability, we should define a new ICMPv6 > error message that allows the nodes to report various DODAG > inconsistencies and discrepancies with more details and precision than > the 'R' and 'F' bits. > > Some suggestions for potential reported errors: > > 1. Preferred parent not reachable > > 2. Parent not reachable > > 3. Parent set nears depletion > > Etc ....etc > > > > Armed with this information (sent in an interoperable manner) the root > is now capable of making a more informed decision when to trigger a > new DODAG iteration. > > > > Any thoughts? Suggestions? > > > > > > > > > > *Robert Assimiti* > > *Office: [678]-202-6859* > > *Mobile: [404]-578-0205* > > *robert.assimiti@nivis.com * > > > > > ------------------------------------------------------------------------ > This e-mail (including any attachments to it) is confidential, > proprietary, legally privileged, subject to copyright and is sent for > the personal attention of the intended recipient only. If you have > received this e-mail in error, please reply to advise us immediately, > delete it and destroy any printed copies of it. You are notified that > reading, disclosing, copying, distributing or taking any action in > reliance on the contents of this information is strictly prohibited. > No employee is authorized to conclude any binding agreement on behalf > of NIVIS LLC with another party by e-mail without express written > confirmation by an officer of the company. Although we have taken > reasonable precautions to ensure no viruses are present in this > e-mail, we cannot accept responsibility for any loss or damage arising > from the viruses in this e-mail or attachments. > ------------------------------------------------------------------------ > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > --------------020909070909060508040901 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit I'm a big fan of having error messages as well as status/summary messages reported to the DAG root.
Status is one of the important tools for detecting insider attacks on the network.  Having a regular summary of what each node is hearing from its neighbors about rank, etc., would help catch attacks as well as bugs, and help with your iteration trigger.

ksjp

Robert Assimiti wrote:

As you can imagine, triggering a new DODAG iteration in a wireless subnet that scales to thousands of wireless nodes can be quite disruptive to the operation of the subnet.

 

The criteria that will trigger a new DODAG iteration should (in my opinion) be left to the implementation.

The decision of triggering a new DODAG iteration lies with the root.

A well informed root can make better decisions than an un-informed root.

 

Hence I propose that we discuss additional standardized error messages reported by the routers.

At this point nodes can flag rank and forwarding errors through the usage of the ‘R’ and ‘F’ bits present in the flow label.

 

In my opinion, this is a very limited set of error messages.

Since we are seeking interoperability,  we should define a new ICMPv6 error message that allows the nodes to report various DODAG inconsistencies and discrepancies with more details and precision than the ‘R’ and ‘F’ bits.

Some suggestions for potential reported errors:

1.       Preferred parent not reachable

2.       Parent not reachable

3.       Parent set nears depletion

Etc ….etc

 

Armed with this information (sent in an interoperable manner) the root is now capable of making a more informed decision when to trigger a new DODAG iteration.

 

Any thoughts? Suggestions?

 

 

 

 

Robert Assimiti

Office: [678]-202-6859

Mobile: [404]-578-0205

robert.assimiti@nivis.com

 


This e-mail (including any attachments to it) is confidential, proprietary, legally privileged, subject to copyright and is sent for the personal attention of the intended recipient only. If you have received this e-mail in error, please reply to advise us immediately, delete it and destroy any printed copies of it. You are notified that reading, disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited. No employee is authorized to conclude any binding agreement on behalf of NIVIS LLC with another party by e-mail without express written confirmation by an officer of the company. Although we have taken reasonable precautions to ensure no viruses are present in this e-mail, we cannot accept responsibility for any loss or damage arising from the viruses in this e-mail or attachments.
 

_______________________________________________
Roll mailing list
Roll@ietf.org
https://www.ietf.org/mailman/listinfo/roll
--------------020909070909060508040901-- From Jerald.P.Martocci@jci.com Tue Mar 23 13: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 D78093A6933; Tue, 23 Mar 2010 13:45:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.314 X-Spam-Level: X-Spam-Status: No, score=-1.314 tagged_above=-999 required=5 tests=[BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, 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 pug+wqFM3nHl; Tue, 23 Mar 2010 13:45:20 -0700 (PDT) Received: from exprod8og109.obsmtp.com (exprod8og109.obsmtp.com [64.18.3.98]) by core3.amsl.com (Postfix) with ESMTP id 677653A68DC; Tue, 23 Mar 2010 13:45:20 -0700 (PDT) Received: from source ([192.132.24.137]) (using SSLv3) by exprod8ob109.postini.com ([64.18.7.12]) with SMTP ID DSNKS6koVAEMWPHbnucfbJPewURuvLjUw6RA@postini.com; Tue, 23 Mar 2010 13:45:40 PDT Received: from jwimkrs1.na.jci.com ([10.10.6.31]) by smtpmke01.jci.com (Lotus Domino Release 8.0.1) with ESMTP id 2010032315451476-1081494 ; Tue, 23 Mar 2010 15:45:14 -0500 In-Reply-To: <4DD685CB-4642-446F-9AC9-238CF22E0B5A@cisco.com> References: <4DD685CB-4642-446F-9AC9-238CF22E0B5A@cisco.com> To: JP Vasseur MIME-Version: 1.0 X-KeepSent: 34AD4012:0FD06855-862576EF:007126A5; 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: Tue, 23 Mar 2010 15:44:53 -0500 X-MIMETrack: Serialize by Router on jwimkrs1.na.jci.com/NA/Johnson_Controls at 03/23/2010 03:44:54 PM, Serialize complete at 03/23/2010 03:44:54 PM, Itemize by SMTP Server on smtpmke01.jci.com/JCI_SMTP(Release 8.0.1|February 07, 2008) at 03/23/2010 03:45:14 PM, Serialize by Router on smtpmke01.jci.com/JCI_SMTP(Release 8.0.1|February 07, 2008) at 03/23/2010 03:45:59 PM, Serialize complete at 03/23/2010 03:45:59 PM Content-Type: text/html; charset="US-ASCII" Cc: ROLL WG , roll-bounces@ietf.org Subject: Re: [Roll] Security Framework moving to WG document X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Mar 2010 20:45:21 -0000
Yes,

 I think Kris and Txeta have done a nice job defining the security model.  I am a bit concerned, from what I noted at yesterday's meeting that this policy will only be applied to RPL messages (i.e., DIO, DAO and DIS).  Kris didn't discuss the security policy for the LLN/RPL data packets.  Maybe I just missed it.  Hopefully the plan is to use the same policy across different layers.  Otherwise the poor little sensors will be pummelled with processing work.


Jerry




From: JP Vasseur <jpv@cisco.com>
To: ROLL WG <roll@ietf.org>
Date: 03/23/2010 12:00 PM
Subject: [Roll] Security Framework moving to WG document




Dear WG,

The security framework has been presented several times and reach a  
point where it was time to poll the WG for WG adoption.
There was a really good consensus to make it a WG document but as  
usual let's confirm on the mailing list.
Should you be opposed to make it a WG please voice your opinion on the  
list before March 30.

Thanks.

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

From ulrich@herberg.name Tue Mar 23 16:48: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 145DA3A6938 for ; Tue, 23 Mar 2010 16:48:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.754 X-Spam-Level: * X-Spam-Status: No, score=1.754 tagged_above=-999 required=5 tests=[BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, 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 cg-2Dm+g7VhI for ; Tue, 23 Mar 2010 16:48:52 -0700 (PDT) Received: from mail-bw0-f211.google.com (mail-bw0-f211.google.com [209.85.218.211]) by core3.amsl.com (Postfix) with ESMTP id A718A3A67AE for ; Tue, 23 Mar 2010 16:48:51 -0700 (PDT) Received: by bwz3 with SMTP id 3so5912117bwz.29 for ; Tue, 23 Mar 2010 16:49:09 -0700 (PDT) MIME-Version: 1.0 Received: by 10.204.9.23 with SMTP id j23mr322730bkj.132.1269388149660; Tue, 23 Mar 2010 16:49:09 -0700 (PDT) Date: Tue, 23 Mar 2010 16:49:09 -0700 Message-ID: <25c114b91003231649j450a87a4sdd3d071145a49a42@mail.gmail.com> From: Ulrich Herberg To: roll@ietf.org Content-Type: multipart/alternative; boundary=00151758a602be1de50482807529 Subject: [Roll] Comments on security presentation yesterday X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 23 Mar 2010 23:48:53 -0000 --00151758a602be1de50482807529 Content-Type: text/plain; charset=ISO-8859-1 Hi, I have some questions and comments on the security presentation yesterday (and the corresponding drafts) - draft-struik-roll-rpl-security-design-00 proposes to modify the header of the DIO/DAO base. Does this break compatibility with the rpl specification, or is it intended to merge this header format into the rpl spec? - why is the signature algorithm limited to AES128 CCM? This makes it very hard to change to security algorithm at a later point (e.g. if another, more secure / shorter / faster algorithm has been found). I suggest using an IANA registry. I am author of similar drafts for MANET (NHDP/OLSRv2) [1], [2] where I suggest exactly this. - the Auxiliary Security Header seems to me rather inflexible (fixed number of octets). Maybe it would be more advantageous to use some TLV structure, which allows to transmit different security options (depending on the signature algorithm, see my previous point). - I have some doubts whether it will be sufficient to consider only outsider attacks. - I am against assuming a chain of trust, and propose to provide end-to-end protection. For the latter two points, I understand that providing end-to-end security and considering insider attacks makes the problem harder -- but I think that we may want to offer them (at least optionally). [1] http://tools.ietf.org/html/draft-herberg-manet-packetbb-sec-03 [2] http://tools.ietf.org/html/draft-herberg-manet-nhdp-sec-00 Ulrich --00151758a602be1de50482807529 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi,

I have some questions and comments on the security presentation = yesterday (and the corresponding drafts)

- draft-struik-roll-rpl-sec= urity-design-00 proposes to modify the header of the DIO/DAO base. Does thi= s break compatibility with the rpl specification, or is it intended to merg= e this header format into the rpl spec?
- why is the signature algorithm limited to AES128 CCM? This makes it very = hard to change to security algorithm at a later point (e.g. if another, mor= e secure / shorter / faster algorithm has been found). I suggest using an I= ANA registry. I am author of similar drafts for MANET (NHDP/OLSRv2) [1], [2= ] where I suggest exactly this.
- the Auxiliary Security Header seems to me rather inflexible (fixed number= of octets). Maybe it would be more advantageous to use some TLV structure,= which allows to transmit different security options (depending on the sign= ature algorithm, see my previous point).
- I have some doubts whether it will be sufficient to consider only outside= r attacks.
- I am against assuming a chain of trust, and propose to prov= ide end-to-end protection.
For the latter two points, I understand that = providing end-to-end security and considering insider attacks makes the pro= blem harder -- but I think that we may want to offer them (at least optiona= lly).

[1] http://tools.ietf.org/html/draft-herberg-manet-packetbb-sec-03<= br>[2] http://tools.ietf.org/html/draft-herberg-manet-nhdp-sec-00

Ulrich
--00151758a602be1de50482807529-- From pister@eecs.berkeley.edu Tue Mar 23 16:54: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 641DC3A68C0; Tue, 23 Mar 2010 16:54:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.168 X-Spam-Level: X-Spam-Status: No, score=-4.168 tagged_above=-999 required=5 tests=[AWL=1.300, 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 LVc6CzHSXoy2; Tue, 23 Mar 2010 16:54:34 -0700 (PDT) Received: from gateway0.EECS.Berkeley.EDU (gateway0.EECS.Berkeley.EDU [169.229.60.87]) by core3.amsl.com (Postfix) with ESMTP id 407CB3A67AE; Tue, 23 Mar 2010 16:54:34 -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 o2NNsA8p021021 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 23 Mar 2010 16:54:11 -0700 (PDT) Message-ID: <4BA954A1.3000303@eecs.berkeley.edu> Date: Tue, 23 Mar 2010 16:54:09 -0700 From: Kris Pister User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Jerald.P.Martocci@jci.com References: <4DD685CB-4642-446F-9AC9-238CF22E0B5A@cisco.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------030707020306040508040409" Cc: roll-bounces@ietf.org, ROLL WG Subject: [Roll] mote spam X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 23 Mar 2010 23:54:35 -0000 This is a multi-part message in MIME format. --------------030707020306040508040409 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Jerry - the direction given was that we should focus exclusively on protecting the routing information. I think that this is the right (first) thing to do, and I'm pretty sure we'd need to recharter to do more than that anyway. I agree with you that we need to protect the data packets as well, but I think that needs to be either at L2, or end-to-end at transport or application, or preferably both. Hopefully security is within scope for the CoRE charter. ksjp Jerald.P.Martocci@jci.com wrote: > > Yes, > > I think Kris and Txeta have done a nice job defining the security > model. I am a bit concerned, from what I noted at yesterday's meeting > that this policy will only be applied to RPL messages (i.e., DIO, DAO > and DIS). Kris didn't discuss the security policy for the LLN/RPL > data packets. Maybe I just missed it. Hopefully the plan is to use > the same policy across different layers. Otherwise the poor little > sensors will be pummelled with processing work. > > > Jerry > > > > > From: JP Vasseur > To: ROLL WG > Date: 03/23/2010 12:00 PM > Subject: [Roll] Security Framework moving to WG document > > > ------------------------------------------------------------------------ > > > > Dear WG, > > The security framework has been presented several times and reach a > point where it was time to poll the WG for WG adoption. > There was a really good consensus to make it a WG document but as > usual let's confirm on the mailing list. > Should you be opposed to make it a WG please voice your opinion on the > list before March 30. > > 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 > --------------030707020306040508040409 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Jerry - the direction given was that we should focus exclusively on protecting the routing information.  I think that this is the right (first) thing to do, and I'm pretty sure we'd need to recharter to do more than that anyway.
I agree with you that we need to protect the data packets as well, but I think that needs to be either at L2, or end-to-end at transport or application, or preferably both.  Hopefully security is within scope for the CoRE charter.

ksjp

Jerald.P.Martocci@jci.com wrote:

Yes,

 I think Kris and Txeta have done a nice job defining the security model.  I am a bit concerned, from what I noted at yesterday's meeting that this policy will only be applied to RPL messages (i.e., DIO, DAO and DIS).  Kris didn't discuss the security policy for the LLN/RPL data packets.  Maybe I just missed it.  Hopefully the plan is to use the same policy across different layers.  Otherwise the poor little sensors will be pummelled with processing work.


Jerry




From: JP Vasseur <jpv@cisco.com>
To: ROLL WG <roll@ietf.org>
Date: 03/23/2010 12:00 PM
Subject: [Roll] Security Framework moving to WG document




Dear WG,

The security framework has been presented several times and reach a  
point where it was time to poll the WG for WG adoption.
There was a really good consensus to make it a WG document but as  
usual let's confirm on the mailing list.
Should you be opposed to make it a WG please voice your opinion on the  
list before March 30.

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
--------------030707020306040508040409-- From pister@eecs.berkeley.edu Tue Mar 23 17:29: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 7ABEF3A6D49 for ; Tue, 23 Mar 2010 17:29:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.518 X-Spam-Level: X-Spam-Status: No, score=-3.518 tagged_above=-999 required=5 tests=[AWL=-0.650, BAYES_50=0.001, 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 V8CW-+Dsz9m9 for ; Tue, 23 Mar 2010 17:29:36 -0700 (PDT) Received: from gateway0.EECS.Berkeley.EDU (gateway0.EECS.Berkeley.EDU [169.229.60.87]) by core3.amsl.com (Postfix) with ESMTP id 398543A6861 for ; Tue, 23 Mar 2010 17:23:27 -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 o2O0NgUV021250 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 23 Mar 2010 17:23:44 -0700 (PDT) Message-ID: <4BA95B8E.9070700@eecs.berkeley.edu> Date: Tue, 23 Mar 2010 17:23:42 -0700 From: Kris Pister User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Ulrich Herberg References: <25c114b91003231649j450a87a4sdd3d071145a49a42@mail.gmail.com> In-Reply-To: <25c114b91003231649j450a87a4sdd3d071145a49a42@mail.gmail.com> Content-Type: multipart/alternative; boundary="------------030205090205030903030302" Cc: roll@ietf.org Subject: Re: [Roll] Comments on security presentation yesterday X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 24 Mar 2010 00:29:37 -0000 This is a multi-part message in MIME format. --------------030205090205030903030302 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Ulrich - the plan is to incorporate security into the RPL document, so whichever path we choose will be compatible by design. Regarding flexibility and algorithms for RPL security, I would propose that if we want flexibility we have IPsec. If we want to define something simple and efficient we should do so with as much flexibility as possible, but always with the emphasis on simplicity and efficiency. AES128 is a natural choice right now because it is built in to most of the phy/mac chips that we are targeting (15.4, 802.11, ...), and increasingly comes built in to small microprocessors that run the other phy/macs. I agree that it is not sufficient to consider only insider attacks. Our goal right now is to design the mechanisms that will protect us against outsider attacks. Insider attacks *tend* to require completely different mechanisms, and then usually it's primarily about detection not protection. We're very open to ideas on how to protect against insider attacks. I'd like to see regular reporting of status information to a central authority. There are other ideas as well. >- I am against assuming a chain of trust, For DIS, DIO, DAO, and flowlabel.rank information, single-hop *is* end-to-end to a large extent. Each router is providing information to its immediate neighbor about its rank, descendants, etc. I'm not sure how to avoid a chain of trust in normal operation. ksjp Ulrich Herberg wrote: > Hi, > > I have some questions and comments on the security presentation > yesterday (and the corresponding drafts) > > - draft-struik-roll-rpl-security-design-00 proposes to modify the > header of the DIO/DAO base. Does this break compatibility with the rpl > specification, or is it intended to merge this header format into the > rpl spec? > - why is the signature algorithm limited to AES128 CCM? This makes it > very hard to change to security algorithm at a later point (e.g. if > another, more secure / shorter / faster algorithm has been found). I > suggest using an IANA registry. I am author of similar drafts for > MANET (NHDP/OLSRv2) [1], [2] where I suggest exactly this. > - the Auxiliary Security Header seems to me rather inflexible (fixed > number of octets). Maybe it would be more advantageous to use some TLV > structure, which allows to transmit different security options > (depending on the signature algorithm, see my previous point). > - I have some doubts whether it will be sufficient to consider only > outsider attacks. > - I am against assuming a chain of trust, and propose to provide > end-to-end protection. > For the latter two points, I understand that providing end-to-end > security and considering insider attacks makes the problem harder -- > but I think that we may want to offer them (at least optionally). > > [1] http://tools.ietf.org/html/draft-herberg-manet-packetbb-sec-03 > [2] http://tools.ietf.org/html/draft-herberg-manet-nhdp-sec-00 > > Ulrich > ------------------------------------------------------------------------ > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > --------------030205090205030903030302 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Ulrich -
 the plan is to incorporate security into the RPL document, so whichever path we choose will be compatible by design.

Regarding flexibility and algorithms for RPL security, I would propose that if we want flexibility we have IPsec.  If we want to define something simple and efficient we should do so with as much flexibility as possible, but always with the emphasis on simplicity and efficiency.  AES128 is a natural choice right now because it is built in to most of the phy/mac chips that we are targeting (15.4, 802.11, ...), and increasingly comes built in to small microprocessors that run the other phy/macs.

I agree that it is not sufficient to consider only insider attacks.  Our goal right now is to design the mechanisms that will protect us against outsider attacks.  Insider attacks *tend* to require completely different mechanisms, and then usually it's primarily about detection not protection.  We're very open to ideas on how to protect against insider attacks.  I'd like to see regular reporting of status information to a central authority.  There are other ideas as well.

>- I am against assuming a chain of trust,
For DIS, DIO, DAO, and flowlabel.rank information, single-hop *is* end-to-end to a large extent.  Each router is providing information to its immediate neighbor about its rank, descendants, etc.  I'm not sure how to avoid a chain of trust in normal operation.

ksjp

Ulrich Herberg wrote:
Hi,

I have some questions and comments on the security presentation yesterday (and the corresponding drafts)

- draft-struik-roll-rpl-security-design-00 proposes to modify the header of the DIO/DAO base. Does this break compatibility with the rpl specification, or is it intended to merge this header format into the rpl spec?
- why is the signature algorithm limited to AES128 CCM? This makes it very hard to change to security algorithm at a later point (e.g. if another, more secure / shorter / faster algorithm has been found). I suggest using an IANA registry. I am author of similar drafts for MANET (NHDP/OLSRv2) [1], [2] where I suggest exactly this.
- the Auxiliary Security Header seems to me rather inflexible (fixed number of octets). Maybe it would be more advantageous to use some TLV structure, which allows to transmit different security options (depending on the signature algorithm, see my previous point).
- I have some doubts whether it will be sufficient to consider only outsider attacks.
- I am against assuming a chain of trust, and propose to provide end-to-end protection.
For the latter two points, I understand that providing end-to-end security and considering insider attacks makes the problem harder -- but I think that we may want to offer them (at least optionally).

[1] http://tools.ietf.org/html/draft-herberg-manet-packetbb-sec-03
[2] http://tools.ietf.org/html/draft-herberg-manet-nhdp-sec-00

Ulrich

_______________________________________________
Roll mailing list
Roll@ietf.org
https://www.ietf.org/mailman/listinfo/roll
--------------030205090205030903030302-- From pthubert@cisco.com Tue Mar 23 19:49: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 DF5833A68B4 for ; Tue, 23 Mar 2010 19:49:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.269 X-Spam-Level: X-Spam-Status: No, score=-3.269 tagged_above=-999 required=5 tests=[AWL=-6.200, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, HTML_MESSAGE=0.001, J_CHICKENPOX_12=0.6, J_CHICKENPOX_17=0.6, J_CHICKENPOX_51=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 opmtSKzSLNTr for ; Tue, 23 Mar 2010 19:49:02 -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 843823A6784 for ; Tue, 23 Mar 2010 19:48:59 -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: AnYBAAMaqUuQ/uCWe2dsb2JhbACBQoFSly1mFQEBCwskBhylP4gxgleOCoQTagSOQw X-IronPort-AV: E=Sophos;i="4.51,298,1267401600"; d="scan'208,217";a="4713626" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-2.cisco.com with ESMTP; 24 Mar 2010 02:15:04 +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 o2O2nHTm013257; Wed, 24 Mar 2010 02:49:17 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); Wed, 24 Mar 2010 03:49:17 +0100 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_01CACAFC.9831DB45" Date: Wed, 24 Mar 2010 03:49:13 +0100 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D0180E1B4@XMB-AMS-107.cisco.com> In-Reply-To: <4BA7BFB9.10501@gridmerge.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] P2P performance with current RPL proposal Thread-Index: AcrJ8t3SEg6KcawZRoeX5uYX7XHAVQBB4SRg References: <446723647.8292711269278149739.JavaMail.root@mail02.pantherlink.uwm.edu> <4BA7BFB9.10501@gridmerge.com> From: "Pascal Thubert (pthubert)" To: , "Mukul Goyal" X-OriginalArrivalTime: 24 Mar 2010 02:49:17.0705 (UTC) FILETIME=[98C44790:01CACAFC] Cc: roll Subject: Re: [Roll] P2P performance with current RPL proposal X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Mar 2010 02:49:08 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CACAFC.9831DB45 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 SGkgUm9iZXJ0IGFuZCBNdWt1bDoNCg0KIA0KDQpXZeKAmXZlIGJlZW4gbGl2aW5nIHdpdGggYSBk aXNjb25uZWN0IGZvciBzb21lIHRpbWUgaXQgYXBwZWFycy4NCg0KIA0KDQpNeSBjdXJyZW50IHVu ZGVyc3RhbmRpbmcgaXMgdGhhdCB0aGUgRElTIHRoYXQgTXVrdWwgcHJvcG9zZXMgaXMgYSBmaW5l IGFwcHJvYWNoIHRvIHJlbG9jYXRlIGEgREFHIHRoYXQgdGhlIG5vZGUgdXNlZCB0byBiZWxvbmcg dG8gb3Igd2lzaGVzIHRvIGJlbG9uZyB0by4gSXQgaXMgbW9yZSBsaWtlIGEgcXVpY2sgcmVwYWly IG1lY2hhbmlzbSB0byBlbnN1cmUgdGhhdCB0aGUgbGlnaHQgY29tZXMgdXAgaW4gYSByZWFzb25h YmxlIHRpbWUgdGhhbiBmaW5kaW5nIGEgcGF0aCB0aGF04oCZcyBiZXR0ZXIgdGhhbiB0aGUgb25l IHRoZSBEQUcgcHJvdmlkZXMuIE11a3VsLCBpcyB0aGF0IGNvcnJlY3Q/DQoNCiANCg0KVGhlIERJ TyB0aGF0IHdlIGFyZSBkaXNjdXNzaW5nIGhlcmUgZGVhbHMgd2l0aCB3aGF0IEnigJlkIGNhbGwg dGhlIHJlYWxseSBQMlAgcHJvYmxlbSwgdGhhdCBpcyB0byBjcmVhdGUgb3B0aW1pemVkIHJvdXRl cyB3aXRoaW4gYSBzZXQgb2YgIG5vZGVzIHdpdGhpbiBzcGVjaWZpYyBjb25zdHJhaW50cyB0aGF0 IGFyZSBub3QgdGhvc2Ugb2YgdGhlIG1haW4gREFHLCBhbmQgd2UgZG8gdGhhdCBieSBjcmVhdGlu ZyBhIG5ldyBEQUcgaW4gYSBzb21ld2hhdCBBT0RWIGZhc2hpb24uIFJQTCBuZWVkcyBzbWFsbCBh ZGRpdGlvbnMgdG8gZG8gdGhhdDoNCg0KIA0KDQotICAgICAgICAgIEVuYWJsZSDigJhsb2NhbOKA mSBpbnN0YW5jZUlEcyBzbyB0aGF0IHRoZSByb290IGVuZHBvaW50IGNhbiBhdXRvY29uZiBhbiBp bnN0YW5jZUlEIGZvciBhIERBRyB0aGF0IGl0IGlzIHRoZSBzb2xlIHJvb3QuDQoNCi0gICAgICAg ICAgQWRkIOKAmHRhcmdldHPigJkgdG8gdGhlIERJTw0KDQotICAgICAgICAgIEVuYWJsZSBhIHF1 aWNrIHRpbWUgb3V0IG9mIERJTyBzdGF0ZXMgd2hlbiBubyBEQU8gaXMgc2Vlbg0KDQogDQoNClNv bWUgb2YgdGhpcyBjYW4gYmUgaGlkZGVuIGluIGFuIHNvLWZhci11bnNwZWNpZmllZCAgb2JqZWN0 aXZlIGZ1bmN0aW9uLCBidXQgSSB0aGluayB3ZSBuZWVkIHRvIGRpc2N1c3MgdGhlIGluc3RhbmNl IElEIHBpZWNlIGEgYml0IG1vcmUuDQoNCiANCg0KUGFzY2FsDQoNCiANCg0KRnJvbTogcm9sbC1i b3VuY2VzQGlldGYub3JnIFttYWlsdG86cm9sbC1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYg T2YgUm9iZXJ0IENyYWdpZQ0KU2VudDogTW9uZGF5LCBNYXJjaCAyMiwgMjAxMCAxMjowNyBQTQ0K VG86IE11a3VsIEdveWFsDQpDYzogcm9sbA0KU3ViamVjdDogUmU6IFtSb2xsXSBQMlAgcGVyZm9y bWFuY2Ugd2l0aCBjdXJyZW50IFJQTCBwcm9wb3NhbA0KDQogDQoNCkkgdGhpbmsgdGhlIGlkZWEg b2YgbXVsdGlwbGUgRE9EQUdzIGNvdWxkIHdvcmsgZm9yIFAyUCBpZiBpdCBpcyBwb3NzaWJsZSB0 byBwcm92aWRlIHNvbWUgc29ydCBvZiBwcnVuZWQgRE9EQUdzLiBJIHRoaW5rIHRoZSBESVMgbWVj aGFuaXNtIGJlbG93IGNvdWxkIHdvcmsgYnV0IEkgdGhpbmsgdXNpbmcgRElPcyB0byBtZSBzZWVt cyBtb3JlIG9ydGhvZ29uYWwgYW5kIHN5bW1ldHJpYy4NCg0KSSB0aGluayB0aGUgc29sdXRpb24g Y291bGQgYmUgdG8gdXNlIGEgJ3RhcmdldGVkJyBESU8gd2hpY2ggY2FuIGJlIGVtaXR0ZWQgYW5k IHByb3BhZ2F0ZWQgaW1tZWRpYXRlbHkuIENvbnNpZGVyIEEgdHJ5aW5nIHRvIGNvbW11bmljYXRl IHdpdGggQjoNCg0KMS4JQSBkb2VzIG5vdCBoYXZlIGEgcm91dGluZyB0YWJsZSBlbnRyeSBmb3Ig Qg0KMi4JQSAobm93IGVmZmVjdGl2ZWx5IGEgRE9EQUcgcm9vdCkgc2VuZHMgYSBESU8gdGFyZ2V0 ZWQgYXQgQiB0byBhbGwgcm91dGVycyBtdWx0aWNhc3QgaW1tZWRpYXRlbHkgKHdpdGggaml0dGVy KQ0KMy4JSWYgYSByb3V0ZXIgaGVhcnMgaXQgYW5kIGhhcyBhIERPREFHIGVudHJ5IHRvIEIgaXQg Y2FuIHRoZW4gYmUgcm91dGVkIGFzIG5vcm1hbCB0byBCDQo0LglJZiBhIHJvdXRlciBoZWFycyBp dCBhbmQgZG9lc24ndCBoYXZlIGEgRE9EQUcgZW50cnkgdG8gQiwgaXQgd2lsbCBwcm9wYWdhdGUg aXQgYWxsIHJvdXRlcnMgbXVsdGljYXN0ICh3aXRoIGEgVFRMKSBpbW1lZGlhdGVseSAod2l0aCBq aXR0ZXIpDQo1LglXaGVuIEIgaGVhcnMgdGhlIERJTywgaXQgcmVzcG9uZHMgd2l0aCBhIERBTyBk ZXN0aW5lZCBmb3IgQSBhbmQgc2VudCBiYWNrIGFsb25nIHRoZSBET0RBRyB0byBBLg0KNi4JSW50 ZXJtZWRpYXRlIHJvdXRlcnMgY2FuIHNldCB1cCB0aGUgcm91dGUgdG8gQiBpZiBkZXNpcmVkIG9y IEEgY2FuIHVzZSBzb3VyY2Ugcm91dGluZy4NCg0KU29tZSBwb2ludHM6DQoNCioJVGhlIHN0YW5k YXJkIERBRyBwcm9jZXNzaW5nIG9mIHJhbmsgcmVsYXRpdmUgdG8gQSB1c2luZyB0aGUgT0Ygd291 bGQgYXNzdXJlIHByb3BhZ2F0aW9uIG9mIHRoZSB0YXJnZXRlZCBESU8gYXdheSBmcm9tIEEgYW5k IGZvcm1hdGlvbiBvZiBhIERBRyBiYWNrIHRvIEENCioJUm91dGVycyB3aGljaCBkbyBub3Qgc2Vl IHRoZSBjb3JyZXNwb25kaW5nIERBTyB3b3VsZCB0aW1lIG91dCBhbmQgZGlzY2FyZCB0aGUgRE9E QUcgZW50cnkgZm9yIEEuDQoNClRoaXMgd291bGQgZ2l2ZSB0aGUgYWJpbGl0eSB0byBjcmVhdGUg YSAncHJ1bmVkJyBET0RBRyB0aHVzIGdpdmluZyB0aGUgUDJQIG5lZWRlZCB3aXRob3V0IGFsbCBy b3V0ZXJzIGhhdmluZyB0byBzZXQgdXAgRE9EQUcgZW50cmllcyBiYWNrIHRvIEEuIEFzIGZhciBh cyBJIGNhbiBzZWUsIHRoaXMgc3RheXMgcHJldHR5IGNsb3NlIHRvIFJQTCBidXQgYWRkcyB0aGUg aWRlYSBvZiBhIERJTyB0YXJnZXQgYW5kIGFuIGFsdGVybmF0aXZlIGRlbGl2ZXJ5IG1lY2hhbmlz bSBhcyBvcHBvc2VkIHRvIHRyaWNrbGUgdGltZXIgKGV2ZW4gdGhlbiwgaXQgaXMgcmVhbGx5IGEg c3Vic2V0IG9mIGEgdHJpY2tsZSB0aW1lcikuDQoNCkFzIGFsd2F5cywgSSBhbSBzdXJlIHRoZXJl IGFyZSBzdGlsbCBzb21lIG90aGVyIGlzc3VlcyB0byBjb25zaWRlci4NCg0KUm9iZXJ0DQoNClJv YmVydCBDcmFnaWUgKFBhY2lmaWMgR2FzICYgRWxlY3RyaWMpDQoNCkdyaWRtZXJnZSBMdGQuDQo4 OSBHcmVlbmZpZWxkIENyZXNjZW50LA0KV2FrZWZpZWxkLCBXRjQgNFdBLCBVSw0KKzQ0ICgwKSAx OTI0IDkxMDg4OA0KaHR0cDovL3d3dy5ncmlkbWVyZ2UuY29tIDxodHRwOi8vd3d3LmdyaWRtZXJn ZS5jb20vPiANCg0KDQpPbiAyMi8wMy8yMDEwIDU6MTUgUE0sIE11a3VsIEdveWFsIHdyb3RlOiAN Cg0KTm8uIEFzIERvbiBwb2ludGVkIG91dCwgdGhlIHJvdXRlIHNlbGVjdGlvbiBpcyBiYXNlZCBv biBhbiBvYmplY3QgZnVuY3Rpb24gZGVzaXJlZCBieSB0aGUgbm9kZSBpbml0aWF0aW5nIHRoZSBy b3V0ZSBkaXNjb3ZlcnkuIFRoZSBvbmx5IHRoaW5nIGJhc2VkIG9uIGhvcCBjb3VudCBhdCB0aGlz IHBvaW50IGlzIHRoZSBzY29wZSBvZiBkaXNjb3ZlcnkgLSBob3cgZmFyIHRoZSBESVMgdHJhdmVs cy4gSSBndWVzcyB0aGlzIGFsc28gY291bGQgYmUgY2hhbmdlZCB0byBhICJkaXNjb3Zlcnkgc2Nv cGUiIGZ1bmN0aW9uIGlmIGRlc2lyZWQuDQogDQpUaGFua3MNCk11a3VsDQogDQotLS0tLSBPcmln aW5hbCBNZXNzYWdlIC0tLS0tDQpGcm9tOiAiUGhpbGlwIExldmlzIiA8cGFsQGNzLnN0YW5mb3Jk LmVkdT4gPG1haWx0bzpwYWxAY3Muc3RhbmZvcmQuZWR1PiANClRvOiAiZCBzdHVyZWsiIDxkLnN0 dXJla0BhdHQubmV0PiA8bWFpbHRvOmQuc3R1cmVrQGF0dC5uZXQ+IA0KQ2M6ICJBbmRlcnMgQnJh bmR0IiA8YWJyQHNkZXNpZ25zLmRrPiA8bWFpbHRvOmFickBzZGVzaWducy5kaz4gLCAiTXVrdWwg R295YWwiIDxtdWt1bEB1d20uZWR1PiA8bWFpbHRvOm11a3VsQHV3bS5lZHU+ICwgIlBhc2NhbCBU aHViZXJ0IChwdGh1YmVydCkiIDxwdGh1YmVydEBjaXNjby5jb20+IDxtYWlsdG86cHRodWJlcnRA Y2lzY28uY29tPiAsICJST0xMIFdHIiA8cm9sbEBpZXRmLm9yZz4gPG1haWx0bzpyb2xsQGlldGYu b3JnPiAsICJUZWQgSHVtcGFsIiA8VGVkLkh1bXBhbEBqY2kuY29tPiA8bWFpbHRvOlRlZC5IdW1w YWxAamNpLmNvbT4gDQpTZW50OiBNb25kYXksIE1hcmNoIDIyLCAyMDEwIDExOjIwOjQ2IEFNIEdN VCAtMDY6MDAgVVMvQ2FuYWRhIENlbnRyYWwNClN1YmplY3Q6IFJlOiBbUm9sbF0gUDJQIHBlcmZv cm1hbmNlIHdpdGggY3VycmVudCBSUEwgcHJvcG9zYWwNCiANCiANCkp1c3QgdG8gYmUgc3VyZSBJ IGFtIGhlYXJpbmcgdGhpcyByaWdodCAtdGhlIHByb3Bvc2FsIGlzIHRvIHVzZSBob3Bjb3VudC1i YXNlZCByb3V0ZSBzZWxlY3Rpb24/IA0KIA0KIA0KUGhpbCANCiANCk9uIE1hciAyMiwgMjAxMCwg YXQgNzo1MiBBTSwgIkRvbiBTdHVyZWsiIDwgZC5zdHVyZWtAYXR0Lm5ldCA+IHdyb3RlOiANCiAN CiANCiANCiANCiANCiANCiANCiANCkhpIEFuZGVycyBhbmQgTXVrdWwsIA0KIA0KICANCiANClRo aXMgaXMgYWxsIHNvdW5kaW5nIHF1aXRlIHByb21pc2luZyBpbiBhZGRyZXNzaW5nIFAyUCByb3V0 aW5nIGluIFJQTC4gIEhvdyBjYW4gd2Ugb3JnYW5pemUgYSBzcGVjaWZpYyBwcm9wb3NhbCB3ZSBj YW4gZ2FpbiBXRyBhcHByb3ZhbCBmb3I/ICBJIHdvdWxkIGxpa2UgdG8gbGVhdmUgQW5haGVpbSB3 aXRoIGFuIGFncmVlZCBwYXRoIHRvd2FyZHMgUDJQIHJvdXRpbmcgc3VwcG9ydCB3ZSBhbGwgYmVs aWV2ZSBhZGRyZXNzZXMgdGhlIEhvbWUgQXV0b21hdGlvbiBhbmQgQnVpbGRpbmcgQ29udHJvbHMg dXNlIGNhc2VzLiANCiANCiAgDQogDQpEb24gDQogDQogIA0KIA0KICANCiANCiANCiANCkZyb206 IHJvbGwtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOnJvbGwtYm91bmNlc0BpZXRmLm9yZ10gT24g QmVoYWxmIE9mIEFuZGVycyBCcmFuZHQgDQpTZW50OiBNb25kYXksIE1hcmNoIDIyLCAyMDEwIDc6 NDYgQU0gDQpUbzogTXVrdWwgR295YWw7IFBhc2NhbCBUaHViZXJ0IChwdGh1YmVydCkgDQpDYzog Uk9MTCBXRzsgVGVkIEh1bXBhbCANClN1YmplY3Q6IFJlOiBbUm9sbF0gUDJQIHBlcmZvcm1hbmNl IHdpdGggY3VycmVudCBSUEwgcHJvcG9zYWwgDQogDQogIA0KIA0KIA0KIA0KQWRkIHRvIHRoaXMg YW4gZWxlbWVudCBvZiBwcm9taXNjdW9zIGxpc3RlbmluZyB0byBkYW1wZW4gdGhlIHN0b3JtID0+ IGlmIG5vZGUgYWxyZWFkeSBkZXRlY3RlZCBhIGNvcHkgb2YgdGhlIERJUyB3aXRoIHRoZSBzYW1l IFRUTCAob3IgbG93ZXIpIC0gZG8gbm90IGZvcndhcmQgdGhlIERJUy4gVGhlbiB5b3Ugc3RhcnQg Z2V0dGluZyBjbG9zZXIgdG8gc29tZXRoaW5nLiANCiANCiANCiAgDQogDQogDQpPaCAtIGFuZCBi eSB0aGUgd2F5IC0gcmVjb3JkIHRoZSBzb3VyY2Ugcm91dGUgb24gdGhlIHdheSA7LSkgDQogDQog DQogIA0KIA0KIA0KLSBBbmRlcnMgDQogDQogDQogIA0KIA0KIA0KIA0KRnJhOiByb2xsLWJvdW5j ZXNAaWV0Zi5vcmcgcMOlIHZlZ25lIGFmIE11a3VsIEdveWFsIA0KU2VuZHQ6IG1hIDIyLTAzLTIw MTAgMDE6NDcgDQpUaWw6IFBhc2NhbCBUaHViZXJ0IChwdGh1YmVydCkgDQpDYzogUk9MTCBXRzsg VGVkIEh1bXBhbCANCkVtbmU6IFJlOiBbUm9sbF0gUDJQIHBlcmZvcm1hbmNlIHdpdGggY3VycmVu dCBSUEwgcHJvcG9zYWwgDQogDQogDQpIaSBQYXNjYWwgDQogDQpUaGFua3MgZm9yIHlvdXIgY29t bWVudHMgKGxldCBtZSBzZW5kIG15IHJlc3BvbnNlIGluIHRoZSBuZXh0IGVtYWlsKS4gDQogDQpC YXNlZCBvbiBmdXJ0aGVyIHRob3VnaHRzLCBpdCBzZWVtcyB0byBtZSB0aGF0IGEgREFHIGJhc2Vk IFAyUCBzb2x1dGlvbiB3b3VsZCB3b3JrIGlmIHdlIGRvIHRoZSBmb2xsb3dpbmc6IA0KIA0KKGEp IGFsbG93aW5nIG11bHRpY2FzdCBESVMgbWVzc2FnZXMgdG8gc3ByZWFkIHRvIGFuIG9yaWdpbmF0 b3Itc3BlY2lmaWVkIG51bWJlciBvZiBob3BzIGFuZCANCihiKSBhbGxvd2luZyBub2RlcyB0byBq b2luIGEgREFHIHRlbXBvcmFyaWx5IGFuZCBsZWF2ZSBpdCBpZiB0aGVyZSBpcyBub3Qgc3VmZmlj aWVudCDigJxyb3V0aW5nIGludGVyZXN04oCdIGluIGJlaW5nIHBhcnQgb2YgdGhlIERBRy4gDQog DQpXaXRoIHRoZXNlIHBvaW50cyBpbiBtaW5kLCBhIFAyUCBzY2hlbWUgY291bGQgd29yayBhcyBm b2xsb3dzOiANCiANCjEuIFdoZW4gYSBub2RlIHdhbnRzIHRvIGpvaW4gYSBET0RBRyhELEYpLCB3 aGVyZSBEIGlzIHRoZSBET0RBRydzIHJvb3QgYW5kIEYgaXMgdGhlIE9GIGJlaW5nIHVzZWQsIGl0 IGRvZXMgdGhlIGZvbGxvd2luZzogDQogICAgYS4gSW5pdGlhdGVzIGEgZGlzY292ZXJ5IHRhYmxl IGVudHJ5IGZvciBET0RBRyhELEYpLiBUaGUgZGlzY292ZXJ5IHRhYmxlIGVudHJpZXMgYXJlIHJl bW92ZWQgYWZ0ZXIgYSBjZXJ0YWluIGxpZmV0aW1lLiANCiAgICBiLiBzZW5kcyBvdXQgYSBESVMg dmlhIGxpbmstbG9jYWwgbXVsdGljYXN0IGFza2luZyBzcGVjaWZpY2FsbHkgZm9yIGluZm9ybWF0 aW9uIGFib3V0IERPREFHKEQsRikuIEl0IGFsc28gbGlzdHMgaW4gdGhlIERJUyB0aGUgbnVtYmVy IG9mIGhvcHMgdGhlIERJUyBjYW4gdHJhdmVsLiANCiANCjIuIE9uIHJlY2VpdmluZyAgYSBESVMs IGEgbm9kZSBkb2VzIHRoZSBmb2xsb3dpbmc6IA0KICAgIGEuaWYgaXQgZG9lcyBub3Qga25vdyBh Ym91dCBET0RBRyhELEYpIGFuZCB0aGUgRElTIGhvcCBsaW1pdCBpcyBub3QgeWV0IHJlYWNoZWQg DQogICAgICAgIGkuIEluaXRpYXRlcyBhIGRpc2NvdmVyeSB0YWJsZSBlbnRyeSBmb3IgRE9EQUco RCxGKS4gVGhpcyBlbnRyeSBtYWludGFpbnMgaW5mb3JtYXRpb24gYWJvdXQgdGhlIG5vZGVzIGZy b20gd2hvbSB0aGUgRElTIHdlcmUgcmVjZWl2ZWQuIA0KICAgICAgICBpaS4gc2VuZHMgb3V0IHRo ZSBESVMgKHZpYSBsaW5rLWxvY2FsIG11bHRpY2FzdCB3aXRoIHRyaWNrbGUgY29udHJvbGxlZCB0 aW1pbmcpIGZ1cnRoZXIuIA0KICAgIGIuIElmIGl0IGlzIGFscmVhZHkgYSBwYXJ0IG9mIERPREFH KEQsRikgb3IgaXMgbm9kZSBEIGl0c2VsZiANCiAgICAgICAgaS4gU2VuZCBvdXQgYSBESU8gYWJv dXQgRE9EQUcoRCxGKSB0byB0aGUgbm9kZSBmcm9tIHdob20gdGhlIERJUyB3YXMgcmVjZWl2ZWQu IA0KIA0KMy4gT24gcmVjZWl2aW5nIGEgRElPIGFib3V0IERPREFHKEQsRiksIGEgbm9kZSBkb2Vz IHRoZSBmb2xsb3dpbmc6IA0KICAgIGEuIElnbm9yZSB0aGUgRElPIGlmIHRoZSBub2RlIGRvZXMg bm90IGhhdmUgYSBkaXNjb3ZlcnkgdGFibGUgZW50cnkgZm9yIERPREFHKEQsRikgDQogICAgYi4g T3RoZXJ3aXNlLCB0aGUgbm9kZSBqb2lucyB0aGUgRE9EQUcoRCxGKSAoaWYgbm90IGFscmVhZHkg cGFydCBvZiBpdCkgb3IgdXBkYXRlcyBpdHMgcGFyZW50IHNldCBpbiBET0RBRyhELEYpIGFuZCBz ZW5kcyB0aGUgRElPIGJ5IHVuaWNhc3QgdG8gdGhlIG5vZGVzIHRoYXQgaGFkIHNlbnQgaXQgdGhl IERJUy4gDQogDQo0LiBPbmNlLCB0aGUgbm9kZSBpcyBwYXJ0IG9mIHRoZSBET0RBRyhELEYpLCBp dCBtYWludGFpbnMgYSDigJxyb3V0aW5nIGludGVyZXN04oCdIGZvciB0aGUgRE9EQUcgaW4gdGhl IGZvbGxvd2luZyBtYW5uZXI6IA0KICAgIGEuIFJvdXRpbmcgaW50ZXJlc3QgaXMgYSB2YWx1ZSBi ZXR3ZWVuIDAgYW5kIDEgDQogICAgYi4gUm91dGluZyBpbnRlcmVzdCBpcyAxIGlmIHRoZSBub2Rl IHJlY2VudGx5IGZvcndhcmRlZCBhIHBhY2tldCBhbG9uZyB0aGUgRE9EQUcoRCxGKSANCiAgICBj LiBPdGhlcndpc2UsIHRoZSByb3V0aW5nIGludGVyZXN0IGlzIHgqbWF4aW11bSByb3V0aW5nIGlu dGVyZXN0IG9mIHRoZSBuZWlnaGJvcnMgaW4gRE9EQUcoRCxGKSwgd2hlcmUgeCBpcyBhIGZyYWN0 aW9uLiBUaGUgbm9kZSBjb21lcyB0byBrbm93IG9mIG5laWdoYm9y4oCZcyByb3V0aW5nIGludGVy ZXN0IHZpYSB0aGUgbmVpZ2hib3LigJlzIERJTy4gDQogICAgZC4gQSBub2RlIGxlYXZlcyBhIERP REFHIGlmIGl0cyByb3V0aW5nIGludGVyZXN0IGluIHRoZSBET0RBRyBnb2VzIGJlbG93IGEgdGhy ZXNob2xkLiANCiANClRoYW5rcyANCk11a3VsIA0KIA0KLS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAt LS0tLSANCkZyb206ICJQYXNjYWwgVGh1YmVydCAocHRodWJlcnQpIiA8IHB0aHViZXJ0QGNpc2Nv LmNvbSA+IA0KVG86ICJNdWt1bCBHb3lhbCIgPCBtdWt1bEB1d20uZWR1ID4gDQpDYzogIlJPTEwg V0ciIDwgcm9sbEBpZXRmLm9yZyA+LCAiVGVkIEh1bXBhbCIgPCBUZWQuSHVtcGFsQGpjaS5jb20g PiwgInJvYmVydCBjcmFnaWUiIDwgcm9iZXJ0LmNyYWdpZUBncmlkbWVyZ2UuY29tID4gDQpTZW50 OiBGcmlkYXksIE1hcmNoIDE5LCAyMDEwIDExOjIwOjU4IEFNIEdNVCAtMDY6MDAgVVMvQ2FuYWRh IENlbnRyYWwgDQpTdWJqZWN0OiBSRTogW1JvbGxdIFAyUCBwZXJmb3JtYW5jZSB3aXRoIGN1cnJl bnQgUlBMIHByb3Bvc2FsIA0KIA0KSGkgTXVrdWwgDQogIA0KDQoJSGVyZSBJIGhhdmUgYXR0ZW1w dGVkIHRvIGZvcm11bGF0ZSBhIHNpbXBsZSBEViBhbGdvcml0aG0gaW4gUlBML0RBRyB0ZXJtcy4g DQoJSSB3aWxsIGFwcHJlY2lhdGUgaXQgaWYgeW91IGNvdWxkIGxldCBtZSBrbm93IGFib3V0IHlv dXIgb2JqZWN0aW9ucyB0byB0aGlzIA0KCXByb3Bvc2FsOiANCgkgICAgDQoNCltQYXNjYWxdIEl0 J3MgY29vbCB0aGF0IHlvdSBkbyBpdCBpcyB0aGUgZmlyc3QgaW1wcmVzc2lvbi4gDQogDQogIA0K DQoJTm9kZSBBIG5lZWRzIHRvIHJlYWNoIGEgZGVzdGluYXRpb24gRC4gTm9kZSBBIGluaXRpYXRl cyBhIGRpc2NvdmVyeSBEQUcgDQoJdG93YXJkcyBELiBBcyB0aGUgRElPcyByZWFjaCBELCBpdCBz ZW5kcyBhIERBTyBiYWNrIHRvIHNlbGVjdGVkIHBhcmVudHMuIEFzIA0KCXRoZSBEQU8gdHJhdmVs cyB0b3dhcmRzIG5vZGUgQSwgaW4tcm91dGUgbm9kZXMgc3RvcmUgdGhlIGNvc3QgdG8gcmVhY2gg RC4gDQoJIA0KCVdoZW4gbm9kZSBCIG5lZWRzIHRvIHJlYWNoIEQsIGl0IHNpbWlsYXJseSBpbml0 aWF0ZXMgYSBkaXNjb3ZlcnkgZGFnLiBEdXJpbmcgDQoJdGhpcyBkaXNjb3ZlcnksIHdoZW4gYSBE SU8gcmVhY2hlcyBhIG5vZGUgQyB0aGF0IG1haW50YWlucyBhIGNvc3QgdG8gcmVhY2ggRCwgDQoJ bm9kZSBDIHJlc3BvbmRzIGJhY2sgd2l0aCBhIERBTyB0aGF0IHRyYXZlbHMgdG93YXJkcyBCIGFu ZCBzdG9yZXMgaW4gaW4tIA0KCXJvdXRlIG5vZGVzIHRoZSBjb3N0IHRvIHJlYWNoIEQuIA0KCSAg ICANCg0KW1Bhc2NhbF0gIHVuZGVyc3RhbmQgdGhhdCB5b3UncmUgdHJ5aW5nIHRvIG1ha2UgUlBM IGV2ZW4gY2xvc2VyIHRvIEFPRFYuIA0KSSBhZ3JlZSB3ZSBuZWVkIHRvIGdhdGhlciBhcyBtdWNo IGFzIHdlIGNhbiBmcm9tIHRoYXQgd29yay4gDQogDQpGb3IgdGhlIHNwZWNpZmljcyBvZiB5b3Vy IHByb3Bvc2FsOiANCiANCi0gQi1DIG1pZ2h0IGJlIG9ydGhvZ29uYWwgdG8gQS1EIHNvIHRoYXQg Qi9DXEQgZm9ybXMgYW4gYW5nbGUuIFlvdSBkbyBub3QgZW5kIHVwIHdpdGggdGhlIGJlc3QgcGF0 aCB0aGF0IHlvdSdyZSBsb29raW5nIGZvci4gDQogDQotIHRoZXJlIG1pZ2h0IGJlIG11bHRpcGxl IEMncy4gV2hpY2ggb25lIGlzIHRoZSByaWdodCBvbmU/IA0KIA0KLSBSUEwgZG9lcyBub3QgYWxs b3cgcGFja2V0cyB0byBzd2l0Y2ggaW5zdGFuY2VzLiBGb2xsb3dpbmcgbXVsdGlwbGUgREFHcyBp cyB0aGUgcmVjaXBlIGZvciBsb29wcyAtIHVubGVzcyB5b3UgaGF2ZSB0aGVtIHN0cmljdGx5IG9y ZGVyZWQgYnkgc29tZSBtZWFucyBsaWtlIHRoZSBSUEwgc2VxdWVuY2UgYmV0d2VlbiBpdGVyYXRp b25zLCBtb3JlIHNwZWNpZmljIHJvdXRlcywgYmxhaCBibGFoLi4uKSANCiANCi0gdGhlIEEgdG8g RCBwYXRoIGlzIG9wdGltaXplZCBmb3IgYSBjZXJ0YWluIGNvbnN0cmFpbnQuIFlvdSBzZWVtIHRv IGltcGx5IHRoYXQgdGhlIEIgdG8gRCBwYXRoIGhhcyB0aGUgc2FtZSBjb25zdHJhaW50cyBhbmQg bWV0cmljcyBzbyB3ZSBjYW4gY29tcGFyZSBhcHBsZSB0byBhcHBsZS4gQmVjYXVzZSB0aGlzIGlz IGEgdmVyeSBkZWxpY2F0ZSBvcGVyYXRpb24sIFJQTCBoYXMgaW50cm9kdWNlZCB0aGUgUmFuaywg d2hpY2ggaGFzIHRoZSByaWdodCBwcm9wZXJ0aWVzIHRvIG1ha2UgdGhhdCBjb21wYXJpc29uIGVm ZmljaWVudGx5LlNvIGZvciBSUEwsIHRoZSBsb29wIGF2b2lkYW5jZSBtZXRyaWMgaXMgdGhlIFJh bmssIGFuZCBpdCBpcyBvbmx5IHZhbGlkIHdpdGhpbiBhbiBpdGVyYXRpb24uIA0KIA0KLSBBIFAy UCBwYXRoIGRvZXMgbm90IGNvbWUgb3V0IG9mIHRoZSBibHVlLiBUaGVyZSBtdXN0IGJlIHNvbWUg cHJvdmlzaW9ubmluZyBzeXN0ZW0gdGhhdCBkZXRlcm1pbmVzIHRoYXQgdGhvc2Ugbm9kZXMsIEEg YW5kIEIsIGFyZSB2ZXJ5IHNwZWNpYWwgc28gdGhleSBuZWVkIGEgUDJQIG9wdGltaXphdGlvbiwg d2l0aCBhIGdpdmVuIHNwZWNpYWwgT0YsIGFuZCB0aGF0IHRoZXkgYm90aCBuZWVkIHRvIHRhbGsg dG8gRC4gV2VsbCwgaWYgdGhhdCdzIHNvLCB0aGUgbW9zdCBlY29ub21pY2FsIGlzIGZvciB0aGF0 IHN5c3RlbSB0byBmb3JrIHRoZSBEQUcgb3V0IG9mIEQsIHdpdGggZHVhbCB0YXJnZXRzIEEgYW5k IEIuIFRoZXJlIHlvdSBvYnRhaW4gdGhlIHNob3J0ZXN0IHBhdGggZm9yIGJvdGggQS1EIGFuZCBC LUQgZm9yIHRoZSBjb3N0IG9mIGEgc2luZ2xlIGZsb29kaW5nLiANCiANCkkgc2VlIHRoYXQgeW91 J3JlIHRyeWluZyB0byBnZXQgdGhlIGlkZWEgdG8gd29yayBiZXR0ZXIsIGFuZCBJIGhvcGUgd2Ug ZmluZCBhIHdheSB0byBkbyBzbywgbWF5YmUgYWxvbmcgeW91ciBsaW5lcyBpZiB3ZSBjYW4gc29s dmUgdGhlIGlzc3VlcyBhYm92ZS4gQnV0IGJlZm9yZSB3ZSBnZXQgdGhlcmUsIHdlIG5lZWQgdG8g YWdyZWUgdGhhdCB0aGlzIGlzIHRoZSBwYXRoIHdlIHdpc2ggdG8gdGFrZS4gDQogDQpDaGVlcnMs IA0KIA0KUGFzY2FsIA0KIA0KIA0KICANCg0KCS0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0g DQoJRnJvbTogIlBhc2NhbCBUaHViZXJ0IChwdGh1YmVydCkiIDwgcHRodWJlcnRAY2lzY28uY29t ID4gDQoJVG86ICJyb2JlcnQgY3JhZ2llIiA8IHJvYmVydC5jcmFnaWVAZ3JpZG1lcmdlLmNvbSA+ IA0KCUNjOiAiUk9MTCBXRyIgPCByb2xsQGlldGYub3JnID4sICJUZWQgSHVtcGFsIiA8IFRlZC5I dW1wYWxAamNpLmNvbSA+IA0KCVNlbnQ6IFRodXJzZGF5LCBNYXJjaCAxOCwgMjAxMCA5OjIzOjE0 IFBNIEdNVCAtMDY6MDAgVVMvQ2FuYWRhIENlbnRyYWwgDQoJU3ViamVjdDogUmU6IFtSb2xsXSBQ MlAgcGVyZm9ybWFuY2Ugd2l0aCBjdXJyZW50IFJQTCBwcm9wb3NhbCANCgkgDQoJIA0KCSANCgkg DQoJIA0KCUhpIFJvYmVydCA6IA0KCSANCgkgDQoJIA0KCUF0IGxlYXN0IGZyb20gYSBkaXN0YW5j ZSwgdGhlIHByb3Bvc2VkIG1lY2hhbmlzbSBlbXVsYXRlcyBBT0RWLCB3aXRoIHRoZSANCglESU8g YXMgUlJFUSBhbmQgdGhlIERBTyBhcyBSUkVQLiBTbyBpZiB3ZSBkZWNpZGUgdG8gZGlnIGFsb25n IHRob3NlIGxpbmVzLCANCgl3ZeKAmWxsIGNlcnRhaW5seSBhcHByZWNpYXRlIGhlbHAgZnJvbSBN QU5FVCBleHBlcnRzLiBJ4oCZZCBzYXkgdGhhdCBpZiB5b3UgDQoJYWxyZWFkeSBoYXZlIFJQTCBm b3IgUDJNUCBhbmQgTVAyUCwgdGhlIHByb3Bvc2VkIGV4dGVuc2lvbiBhcmUgcHJvYmFibHkgDQoJ c2ltcGxlciB0byBhZGQgdGhhbiBkb2luZyBBT0RWIGZyb20gc2NyYXRjaC4gDQoJIA0KCSANCgkg DQoJRm9yIHRoZSBzZXR1cCwgdGhlIG1ham9yIGRpZmZlcmVuY2VzIGFyZSB0aGF0IHdlIGJ1aWxk IGEgREFHIGFuZCB0aGF0IHdlIGNhbiANCglpbmRpY2F0ZSBtdWx0aXBsZSB0YXJnZXRzLiBJZiB5 b3UgbG9vayBhdCBpdCwgdGhlIERBRyBjYXBhYmlsaXR5IGlzIGEgTVVTVCBmb3IgDQoJUlBMLCBh bmQgSSBoYXZlIG5vdCBzZWVuIHRoYXQgdGhpcyBNVVNUIGdvZXMgYXdheSBmb3IgUDJQIGZsb3dz LiBUaGUgDQoJbXVsdGlwbGUgdGFyZ2V0cyBpcyBzb21ldGhpbmcgdGhhdCBhcHBlYXJzIGluIGEg bnVtYmVyIG9mIHVzZSBjYXNlcyBhbmQgaXQgDQoJc2VlbXMgbW9yZSBlY29ub21pY2FsIHRvIGJ1 aWxkIGEgc2luZ2xlIERBRyBmb3IgbXVsdGlwbGUgdGFyZ2V0cyB3aGVuIA0KCXBvc3NpYmxlLiAN CgkgDQoJIA0KCSANCglGb3IgdGhlIG1haW50ZW5hbmNlLCB0aGUgbWFqb3IgZGlmZmVyZW5jZXMg YXJlIHRoYXQgd2UgaGF2ZSB0aGUgREFHIGFzIA0KCWZpcnN0IGxpbmUgb2YgZGVmZW5zZSwgYW5k IHRoZSBSUEwgZGV0ZWN0aW9uIHRvIHN0aW11bGF0ZSB0aGUgbG9jYWwgcmVwYWlyLiANCgkgDQoJ IA0KCSANCglBYm91dCB5b3VyIHF1ZXN0aW9uczogDQoJIA0KCSANCgkgDQoJVGhlIERPREFHIHJv b3QgaXMgdGhlIG9uZSB0aGF0IHNwYXducyB0aGUgREFHLiBUaGUgdGFyZ2V0cyBjYW4gcmVhY2gg dGhlIA0KCXJvb3QgYmVjYXVzZSB0aGUgcm9vdCBhZHZlcnRpc2VzIGl0c2VsZiBpbiB0aGUgRElP LiBUaGUgaWRlYSBpcyB0aGF0IHRoZSByb290IElEIA0KCWlzIHRoZSBhZGRyZXNzIHRoYXQgdGhl IHRhcmdldHMgbmVlZCB0byB0YWxrIHRvLiBJZiBuZWVkZWQsIHRoZSByb290IGNhbiBhbHNvIA0K CWFkdmVydGlzZSBhIHByZWZpeCB0aGF0IGl0IGNhbiByZWFjaCBhbmQgdGhhdCB0aGUgdGFyZ2V0 cyBuZWVkIHRvIHJlYWNoIHRvby4gDQoJIA0KCSANCgkgDQoJQWxsIHRoZSBpbnRlcm1lZGlhdGUg bm9kZXMgdGhhdCBhcmUgY29uZmlybWVkIGJ5IHRoZSBEQU8gbmVlZCB0byByZXRhaW4gYXQgDQoJ bGVhc3QgaW5mbyBhYm91dCB0aGUgREFHLiBUaGF0IGVuYWJsZXMgdGhlIHRhcmdldHMgdG8gcmVh Y2ggdGhlIHJvb3QuIFRoZSANCglmbG9vZGluZyBzaG91bGQgY29zdCBhYm91dCB0aGUgc2FtZSBh cyB0aGF0IG9mIEFPRFYgYnV0IHRoZSBSUEwgd2F5IHdpbGwgDQoJcmVxdWlyZSBtb3JlIHN0YXRl cyBpbiB0aGUgbm9kZXMgb24gdGhlIHdheSBpZiB0aGUgT0YgcmVxdWlyZXMgYSBEQUcuIA0KCSAN CgkgDQoJIA0KCVRoZSB3YXkgYmFjayAoZG93bikgY2FuIGJlIHN0YXRlZnVsIG9mIHN0YXRlbGVz cywgZGVwZW5kaW5nIG9uIHdoaWNoIERBTyANCgl3ZeKAmXJlIHVzaW5nLiBXaXRoIGZ1bGx5IHN0 YXRlZnVsIERBTywgd2UgYXJlIHJlYWxseSBpbiBBT0RWLWxhbmQuIFdpdGggDQoJc3RhdGVsZXNz LCB3ZSBjb3VsZCBkcmlmdCBpbnRvIERTUi1sYW5kIGZvciB0aGF0IGRpcmVjdGlvbi4gV2hpY2gg bGltaXRzIHdlIA0KCXBsYWNlIHRvIGtlZXAgaXQgc2ltcGxlIHdpbGwgYmUgZGV0ZXJtaW5lZCBi eSB0aGUgcmVzb2x1dGlvbiBvZiBpc3N1ZSAjMjYgSSANCglndWVzc+KApiANCgkgDQoJIA0KCSAN CglBbmQgcGxlYXNlLCBubyBhcG9sb2dpemUgb3Igb24gb25lIHdpbGwgZGFyZSBwb3N0IGFueXRo aW5nIGFueW1vcmUuIFlvdXIgDQoJcXVlc3Rpb25zIGFyZSBmdWxseSByZWxldmFudCBhbmQgYXQg dGhlIGNvcmUgb2YgdGhlIGRpc2N1c3Npb24uIA0KCSANCgkgDQoJIA0KCUkgaG9wZSB3ZSBjYW4g dGFsayBpbiBBbmFoZWltIGZvciBzdXJlLCANCgkgDQoJIA0KCSANCgkgDQoJUGFzY2FsIA0KCSAN CgkgDQoJIA0KCSANCgkgDQoJIA0KCUZyb206IFJvYmVydCBDcmFnaWUgWyBtYWlsdG86cm9iZXJ0 LmNyYWdpZUBncmlkbWVyZ2UuY29tIF0gDQoJU2VudDogTW9uZGF5LCBNYXJjaCAxNSwgMjAxMCAx MToyNyBBTSANCglUbzogUGFzY2FsIFRodWJlcnQgKHB0aCB1YmVydCkgDQoJQ2M6IFRlZC5IdW1w YWxAamNpLmNvbSA7IFJPTEwgV0cgDQoJU3ViamVjdDogUmU6IFtSb2xsXSBQMlAgcGVyZm9ybWFu Y2Ugd2l0aCBjdXJyZW50IFJQTCBwcm9wb3NhbCANCgkgDQoJIA0KCSANCglIaSBQYXNjYWwsIA0K CSANCglTbyBpbiB5b3VyIHNsaWRld2FyZSBUIGNhbiBlbmQgdXAgdGFsa2luZyB0byBSIChET0RB RyByb290KSB0aHJvdWdoIHRoZSANCglET0RBRy4gU28gYXJlIHlvdSBwcm9wb3NpbmcgdGhhdCBh bGwgcG90ZW50aWFsIHRhcmdldHMgY2FuIGFjdCBhcyBhIERPREFHIA0KCXJvb3Q/IEFuZCB0aGVy ZWZvcmUgYWxsIGludGVybWVkaWF0ZXMgaGF2ZSB0byByZXRhaW4gRElPIHByb3BhZ2F0aW9uIA0K CXN1cHBvcnQgZm9yIHRoYXQgRE9EQUcgYXMgd2VsbD8gVGhpcyBtYXkgd29yayBmb3IgbGltaXRl ZCBQMlAgYnV0IHNlZW1zIA0KCWxlc3MgZWZmaWNpZW50IHRoYW4gc2ltcGxlIGRpc3RhbmNlIHZl Y3RvciBmbG9vZGluZyBSUkVRL1JSRVAgbGlrZSBBT0RWIG9yIA0KCURZTU8gZm9yIGdlbmVyaWMg UDJQLiBXaGF0IGFib3V0IFIgdG8gVCAob3IgYW55b25lIGVsc2UgZm9yIHRoYXQgbWF0dGVyKT8g DQoJRG8gd2Ugc291cmNlIHJvdXRlLCBtYWludGFpbiBzdGF0ZSwgc29tZSB1bmRlZmluZWQgaHli cmlkIG9mIHRoZSB0d28/IA0KCSANCglJIGFwb2xvZ2lzZSBpZiBzb21lIG9mIHRoZXNlIHF1ZXN0 aW9ucyBoYXZlIGJlZW4gYW5zd2VyZWQgaW4gZGV0YWlsIGluIGVhcmxpZXIgDQoJcmVmbGVjdG9y IHBvc3RzIGJ1dCBJIGhhdmUgb25seSByZWNlbnRseSBzdGFydGVkIHRvIGNvbmNlbnRyYXRlIG15 IGVmZm9ydHMgb24gDQoJUlBMIGFuZCBoYXZlIDgyIHBhZ2VzIHRvIHdhZGUgdGhyb3VnaCA6LSku IEkgbG9vayBmb3J3YXJkIHRvIGEgcHJvZHVjdGl2ZSANCglzZXNzaW9uIGluIEFuYWhlaW0uIA0K CSANCglSb2JlcnQgDQoJIA0KCSANCglSb2JlcnQgQ3JhZ2llIChQYWNpZmljIEdhcyAmIEVsZWN0 cmljKSANCgkgDQoJR3JpZG1lcmdlIEx0ZC4gDQoJODkgR3JlZW5maWVsZCBDcmVzY2VudCwgDQoJ V2FrZWZpZWxkLCBXRjQgNFdBLCBVSyANCgkrNDQgKDApIDE5MjQgOTEwODg4IA0KCWh0dHA6Ly93 d3cuZ3JpZG1lcmdlLmNvbSANCgkgDQoJIA0KCSANCglQYXNjYWwgVGh1YmVydCAocHRodWJlcnQp IHdyb3RlOiANCgkgDQoJSEkgUm9iZXJ0IDogDQoJIA0KCSANCgkgDQoJSSByZXNwZWN0ZnVsbHkg aGF2ZSB0byBkaXNhZ3JlZS4gDQoJIA0KCSANCgkgDQoJTXkgdW5kZXJzdGFuZGluZyBpcyB0aGF0 IHdlIGFyZSBjb25zaWRlcmluZyBhIGxpbWl0ZWQgc2V0IG9mIFAyUCBwYWlycywgZm9yIA0KCXdo aWNoIHRoZSBzcGVjaWZpYyBwYXRoIHRoYXQgd2UgbmVlZCB0byBjcmVhdGUgbWlnaHQgaGF2ZSB0 byBvYmV5IHNwZWNpZmljIA0KCWNvbnN0cmFpbnRzLiANCgkgDQoJU28gaXQgbWFrZXMgc2Vuc2Ug dG8gdXNlIGFuIG9uLWRlbWFuZCB0ZWNobmlxdWUsIHByb2JhYmx5IGluc3BpcmVkIGJ5IHRoZSAN CglNQU5FVCBSZWFjdGl2ZSBwcm90b2NvbHMuIA0KCSANCgkgDQoJIA0KCUFzIGl0IGdvZXMsIHRo b3NlIHByb3RvY29scyB1c3VhbGx5IHVzZSBmbG9vZGluZyBmb3IgYSBub2RlIHRvIGxvY2F0ZSBh bm90aGVyLiANCglGb3JraW5nIGEgREFHIGlzIGp1c3QgYW5vdGhlciBmbG9vZGluZy4gSXQgZG9l cyBub3QgdGFrZSBhIGxvdCBvZiBhZGRpdGlvbiB0byB0aGUgDQoJZXhpc3RpbmcgRElPIGZvciBh IHJvb3QgdG8gdXNlIFJQTCB0byBidWlsZCBhIERBRyB0aGF0IGNvbnRhaW5zIG9uZSBvciBtdWx0 aXBsZSANCglUYXJnZXRzIGFzIGxlYXZlcywgdW5kZXIgYSBzZXQgb2YgY29uc3RyYWludHMgZXhw cmVzc2VkIGFzIGFuIG9iamVjdGl2ZSANCglmdW5jdGlvbi4gUGxlYXNlIGZpbmQgYXR0YWNoZWQg YSBzbGlkZXdhcmUgdGhhdCBpbGx1c3RyYXRlcyB0aGF0LiANCgkgDQoJIA0KCSANCgkgDQoJUGFz Y2FsIA0KCSANCgkgDQoJIA0KCSANCgkgDQoJIA0KCUZyb206IHJvbGwtYm91bmNlc0BpZXRmLm9y ZyBbIG1haWx0bzpyb2xsLWJvdW5jZXNAaWV0Zi5vcmcgXSBPbiBCZWhhbGYgT2YgDQoJUm9iZXJ0 IENyYWdpZSANCglTZW50OiBUaHVyc2RheSwgTWFyY2ggMTEsIDIwMTAgMjo0MyBQTSANCglUbzog VGVkLkh1bXBhbEBqY2kuY29tIA0KCUNjOiBST0xMIFdHIA0KCVN1YmplY3Q6IFJlOiBbUm9sbF0g UDJQIHBlcmZvcm1hbmNlIHdpdGggY3VycmVudCBSUEwgcHJvcG9zYWwgDQoJIA0KCSANCgkgDQoJ SSBhZ3JlZSB3aXRoIFRlZCdzIGNvbW1lbnRzIGJlbG93LiBDcmVhdGluZyBhIERPREFHIGZvciBl dmVyeSByZWFjaGFibGUgDQoJbm9kZSBhcyBhIHJvb3Qgc2VlbXMgYSB2ZXJ5IGluZWZmaWNpZW50 IGFwcHJvYWNoIGNvbXBhcmVkIHRvIGFsdGVybmF0aXZlIA0KCXJvdXRpbmcgYWxnb3JpdGhtcy4g SSBhbSBjb25jZXJuZWQgdGhhdCBSUEwgZG9lcyBub3QgYWN0dWFsbHkgbWVldCB0aGUgDQoJb3Jp Z2luYWwgcmVxdWlyZW1lbnRzIGluIEktRC5pZXRmLXJvbGwtYnVpbGRpbmctcm91dGluZy1yZXFz LCBJLUQuaWV0Zi1yb2xsLWhvbWUtIA0KCXJvdXRpbmctcmVxcywgUkZDNTY3MyBhbmQgUkZDNTU0 OC4gVGhlIHRyYWZmaWMgcGF0dGVybiByZXF1aXJlbWVudCBmb3IgYSANCglzaW5rIG5vZGUgZmVh dHVyZXMgcHJvbWluZW50bHkgaW4gb25seSB0d28gb2YgdGhvc2UgZG9jdW1lbnRzLiBFdmVuIGlu IHRoaXMgDQoJY2FzZSwgYXMgVGVkIHBvaW50cyBvdXQsIGNvbW11bmljYXRpb24gaXMgbGlrZWx5 IHRvIGJlIGJpZGlyZWN0aW9uYWwgKGUuZy4gZW5kLSANCgl0by1lbmQgYWNrcy4pIHRoZXJlZm9y ZSB0aGUgRE9EQUcgYXBwcm9hY2ggaXMgZnVuZGFtZW50YWxseSBhc3ltbWV0cmljLCANCgllc3Bl Y2lhbGx5IGlmIG5vIGludGVybWVkaWF0ZSBzdG9yYWdlIGlzIGFsbG93ZWQgZm9yIGRlc3RpbmF0 aW9uIHJvdXRlcyBhbmQgDQoJc291cmNlIHJvdXRpbmcgaGFzIHRvIGJlIHVzZWQuIA0KCSANCglB bHNvLCBSUEwgc2VlbXMgaGlnaGx5IGNvbXBsZXggZm9yIHdoYXQgYXJlIGNvbnN0cmFpbmVkIG5v ZGVzIGluIHRlcm1zIG9mIA0KCW1lbW9yeSBhcyB3ZWxsIGFzIHBvd2VyIGFuZCBiYW5kd2lkdGgu IFRoZSBSUEwgZHJhZnQgYXMgaXQgc3RhbmRzIGlzIDgyIA0KCXBhZ2VzIGxvbmcgYW5kIHRoYXQg ZG9lc24ndCBpbmNsdWRlIHRleHQgYWJvdXQgdGhlIG9iamVjdGl2ZSBmdW5jdGlvbi4gDQoJIA0K CVJvYmVydCANCgkgDQoJIA0KCVJvYmVydCBDcmFnaWUgKFBhY2lmaWMgR2FzICYgRWxlY3RyaWMp IA0KCSANCglHcmlkbWVyZ2UgTHRkLiANCgk4OSBHcmVlbmZpZWxkIENyZXNjZW50LCANCglXYWtl ZmllbGQsIFdGNCA0V0EsIFVLIA0KCSs0NCAoMCkgMTkyNCA5MTA4ODggDQoJaHR0cDovL3d3dy5n cmlkbWVyZ2UuY29tIA0KCSANCgkgDQoJIA0KCVRlZC5IdW1wYWxAamNpLmNvbSB3cm90ZTogDQoJ IA0KCSANCglBIGNvbmNlcm4gYWxzbyB3aWxsIGJlIGhvdyBtdWNoIG92ZXJoZWFkIChtZW1vcnkg c3BhY2UpIHdpbGwgYmUgcmVxdWlyZWQgDQoJZm9yIGEgRE9EQUcgUm9vdD8gDQoJIA0KCWFuZCBi YXNlZCBvbiB0aGUgZmlyc3QgcXVlc3Rpb24gaG93IG1hbnkgRE9EQUcgcm9vdHMgYSBsYW1wIG1h eSBuZWVkIHRvIA0KCWJlIGEgbWVtYmVyIG9mPyANCgkgDQoJRm9yIGV4YW1wbGUgaW4gbGlnaHRp bmcgIGEgc2luZ2xlIGxhbXAgbWF5IGJlIGEgcm9vdCBmb3IgYSBzaW5nbGUgc3dpdGNoICgxIA0K CURPREFHIHJvb3QpLCAgdGhpcyBsYW1wIC8gbHVtaW5haXJlIG1heSBhbHNvIA0KCWJlIGEgbWVt YmVyIG9mIGFub3RoZXIgZ3JvdXAgLSAtICB3aGljaCBjb3VsZCBiZSBhbGwgbGlnaHRzIG9uIHRo ZSBmbG9vciAoMm5kIA0KCURPREFHIHJvb3QpLCBhbmQgYSB0aGlyZCBncm91cCANCglvZiBhbGwg dGhlIGxpZ2h0cyBpbiB0aGUgYnVpbGRpbmcuICBUaGVyZSBjYW4gYmUgbWFueSBtb3JlIHNwZWNp YWxpdHkgZ3JvdXBzIA0KCWFzc29jaWF0ZWQgYmFzZWQgb24gdGhlIGJ1aWxkaW5nIGNvbmZpZ3Vy YXRpb24uIA0KCUNvbnNpZGVyIGFsc28gZHVyaW5nIHRoZSBpbnN0YWxsYXRpb24gdGltZSAtIGhv dyB0aGVzZSBET0RBRyByb290cyB3aWxsIGJlIA0KCWNvbmZpZ3VyZWQ/ICBNdXN0IEkgY29tbWlz c2lvbiBlYWNoIGRldmljZSANCgl0byB0ZWxsIGl0IHdoaWNoIERPREFHIGl0IG11c3QgdXNlIGZv ciBpdHMgT2JqZWN0IEZ1bmN0aW9uPyAgSG93IGVhc3kgd2lsbCB0aGlzIA0KCWJlIHRvIGNoYW5n ZSBhbmQgYWRkIGluIGEgbmV3IERPREFHIHJvb3QgDQoJZm9yIHRoZSBlbmQgdXNlciBpZiB0aGUg bGlnaHRpbmcgZ3JvdXAgY2hhbmdlcz8/IA0KCSANCglXaXRoIHJlc3BlY3QgdG8gSmVycnkgTWFy dG9jY2kncyAtIGNvbW1lcmNpYWwgYnVpbGRpbmcgcmVxdWlyZW1lbnRzIC0gZXZlcnkgDQoJZGV2 aWNlIG1heSBuZWVkIHRvIGNvbW11bmljYXRlIHRvIGFueSBvciANCglhbGwgb2YgdGhlIGVuZCBk ZXZpY2VzLiAgSWYgZWFjaCBkZXZpY2UgbXVzdCBlc3RhYmxpc2ggYSBET0RBRyBmb3IgdGhlIG90 aGVyIA0KCTQ5OSBkZXZpY2VzIGluIGEgNTAwIG5vZGUgbmV0d29yayAtIEhvdyBtdWNoIG1lbW9y eSANCglzcGFjZSB3aWxsIHRoaXMgcmVxdWlyZSBmb3IgZWFjaCBlbmQgZGV2aWNlIHRvIG1haW50 YWluPyANCgkgDQoJS2VlcCBpbiBtaW5kIHRoYXQgdGhlIGVuZCBkZXZpY2VzIGFyZSB2ZXJ5IGxp bWl0ZWQgcHJvY2Vzc29yIGFuZCBtZW1vcnkgDQoJd2lzZS4gDQoJIA0KCU5vdCB0byBtZW50aW9u IGFsbCBvZiB0aGUgbmV0d29yayBtYWludGVuYW5jZSBtZXNzYWdlcyB0aGF0IHdvdWxkIG5lZWQg DQoJdG8gYmUgdHJhbnNtaXR0ZWQgdG8gbWFpbnRhaW4gYWxsIG9mIHRoZXNlIERPREFHcy4gDQoJ IA0KCUNvbnNpZGVyIHRoZSByZWNvbnZlcmdlbmNlIHRpbWUgd2hlbiBvbmUgZGV2aWNlIGlzIHR1 cm5lZCBvZmYgYW5kIGl0IHdhcyBpbiANCgl0aGUgbWlkZGxlIG9mIHRoZSBtYWpvcml0eSBvZiB0 aGUgMTAwKyBET0RBR1M/IA0KCSANCglJbiBtYW55IGxpZ2h0aW5nIGFuZCBidWlsZGluZyBhcHBs aWNhdGlvbiBhbiBhcHBsaWNhdGlvbiBhY2tub3dsZWRnZW1lbnQgLSANCgltdXN0IGJlIHJldHVy bmVkIHtCYWNrIGRvd24gdGhlIERPREFHfSBzbyAuIC4gLiB0aGUgDQoJcmVxdWlyZW1lbnQgaXMg bm90IGp1c3QgZ2V0dGluZyB0byB0aGUgUm9vdCAtIGEgcmV0dXJuIHBhdGggbXVzdCBhbHNvIGJl IA0KCW1haW50YWluZWQgYW5kIGhhdmUgYSAgbG93IGxhdGVuY3kgcGF0aC4gDQoJIA0KCVRlZCBI dW1wYWwgDQoJIA0KCSANCgkgDQoJIA0KCSANCgkgDQoJRnJvbTogDQoJIA0KCUtyaXMgUGlzdGVy IDwgcGlzdGVyQGVlY3MuYmVya2VsZXkuZWR1ID4gDQoJIA0KCSANCglUbzogDQoJIA0KCUFuZGVy cyBCcmFuZHQgPCBhYnJAc2Rlc2lnbnMuZGsgPiANCgkgDQoJIA0KCUNjOiANCgkgDQoJUk9MTCBX RyA8IHJvbGxAaWV0Zi5vcmcgPiANCgkgDQoJIA0KCURhdGU6IA0KCSANCgkwMy8wOC8yMDEwIDAx OjQ1IFBNIA0KCSANCgkgDQoJU3ViamVjdDogDQoJIA0KCVJlOiBbUm9sbF0gUDJQIHBlcmZvcm1h bmNlIHdpdGggY3VycmVudCBSUEwgcHJvcG9zYWwgDQoJIA0KCSANCgkgDQoJIA0KCSANCgkgDQoJ IA0KCSANCglBbmRlcnMgLSBpZiB3ZSB0YWtlIEpQJ3Mgc3VnZ2VzdGlvbiB0byBtYWtlIFRoZSBM YW1wIGEgRE9EQUcgcm9vdCwgYW5kIA0KCXRha2UgUGhvZWJ1cycgcmVjb21tZW5kYXRpb24gdGhh dCB3ZSB1c2UgcGF0aCBkaXZlcnNpdHkgdG8gaW1wcm92ZSBlbmQtIA0KCXRvLWVuZCByZWxpYWJp bGl0eSwgZG8geW91IHNlZSBhIGNoYW5jZSBvZiBzdWNjZXNzPyANCglJbiBteSBleHBlcmllbmNl LCB3aXRoIGRpdmVyc2UgcGF0aHMgYW5kIG9yZGVyLW1pbnV0ZXMgdXBkYXRlcyB5b3UgZ2V0IA0K CWV4dHJlbWVseSBoaWdoIHJlbGlhYmlsaXR5LiANCgkgDQoJSSBoYXZlIG5vIGF2ZXJzaW9uIHRv IFRUTC1saW1pdGVkIGZsb29kcyBhcyBhIHBhcnQgb2YgYSBzb2x1dGlvbiBlaXRoZXIuICBJJ20g DQoJb3BlbiB0byBpZGVhcyBvbiBob3cgdG8gYnJpbmcgdGhvc2UgaW4gYXMgKHByZXN1bWFibHkg aW5mcmVxdWVudGx5IHVzZWQpIA0KCW9wdGlvbnMuIA0KCSANCglrc2pwIA0KCSANCglBbmRlcnMg QnJhbmR0IHdyb3RlOiANCglIZWxsbyANCgkgDQoJSSB3b3VsZCBsaWtlIHRvIHByb2JlIHRoZSB0 ZW1wZXJhdHVyZSBvZiB0aGUgV0cgb24gdXNpbmcgREFPcyB0byANCglzdXBwb3J0IFAyUC4gDQoJ IA0KCVRoZSBidWlsZGluZyBhbmQgaG9tZSBhcHBsaWNhdGlvbiBzcGFjZXMgKGFuZCBtYXliZSBv dGhlcnMpIGhhdmUgDQoJYSBmZXcgY2xlYXJseSBkZWZpbmVkIHJlcXVpcmVtZW50cy4gDQoJSXQg aXMgbm90IG9idmlvdXMgdG8gbWUgaG93IHRoZSBjdXJyZW50IFJQTCBwcm9wb3NhbCAoY1JQTHAp IGNhbiANCglzYXRpc2Z5IHRob3NlIHJlcXVpcmVtZW50czogDQoJIA0KCSANCglJbiBib3RoIGNh c2VzIGl0IGlzIHRoZSB3b3JzdCBjYXNlIHNjZW5hcmlvIHRoYXQgaHVydHM6IA0KCSANCgkgDQoJ UDJQIHJvdXRpbmcgaW5zaWRlIHRoZSBQQU4gDQoJPT09PT09PT09PT09PT09PT09PT09PT09PT0g DQoJY1JQTHAgaGFzIG5vIHdheSBvZiByb3V0aW5nIGluc2lkZSB0aGUgUEFOIGlmIHlvdSBuZWVk IG1vcmUgdGhhbiANCglvbmUgcmVwZWF0ZXIuIGNSUExwIGhhcyB0byBnbyBhbGwgdGhlIHdheSB0 byB0aGUgdG9wIChtYXliZSA0IGhvcHMgdXApIA0KCWFuZCBkb3duIGFnYWluIChtYXliZSA0IGhv cHMgZG93bikgdG8gZ2V0IGp1c3QgMiBob3BzIHRvIHRoZSBzaWRlLiANCgkgDQoJVGhlIGNvbnNl cXVlbmNlIGlzIGhpZ2ggbGF0ZW5jeSBhbmQgaGlnaCBsZXZlbHMgb2YgYmFja2dyb3VuZCBub2lz ZSANCglmb3Igbm9kZXMganVzdCBvdXRzaWRlIHRoZSBkaXJlY3QgcmFkaW8gcmFuZ2UuIA0KCUF0 IHRoZSBzYW1lIHRpbWUgdGhlIHJpc2sgb2YgbWVldGluZyBhIGZhaWxpbmcgbGluayBpcyA0IHRp bWVzIGhpZ2hlciA9PiANCglsYXRlbmN5IG1heSBiZSBtdWNoIG1vcmUgdGhhbiA0IHRpbWVzIGxh cmdlci4gDQoJIA0KCUxhdGVuY3kgbWF5IHNvdW5kIGxpa2UgYSBtaW5vciBpc3N1ZSBidXQgaXQg YWN0dWFsbHkgdHJhbnNsYXRlcyBkaXJlY3RseSANCglpbnRvIGxvd2VyIGJhdHRlcnkgbGlmZXRp bWUuIEluIHRoZSBhYm92ZSAodmVyeSByZWFsaXN0aWMpIGV4YW1wbGUsIA0KCXRoZSBiYXR0ZXJ5 IGxpZmV0aW1lIGlzIHJlZHVjZWQgdG8gMjUlIG9mIHdoYXQgaXQgc2hvdWxkIGJlLiANCgkgDQoJ V2UgaGF2ZSBsb3RzIG9mIGJhdHRlcnkgZGV2aWNlcyBzZW5kaW5nIGludG8gdGhlIG5ldHdvcms6 IA0KCSogUElSIHNlbnNvcnMgdHVybmluZyBvbiBsaWdodHMgDQoJKiBEb29yIGxvY2tzIHNlbmRp bmcgYWxhcm1zIA0KCSogRG9vci93aW5kb3cgc2Vuc29ycyBzdGFydGluZyBjaGltZXMgDQoJKiBT bW9rZSBzZW5zb3JzIHRyaWdnZXJpbmcgYW4gYWxhcm0gc3lzdGVtIA0KCSANCgkgDQoJIA0KCSAN CglSZXNwb25zZSB0aW1lIA0KCT09PT09PT09PT09PT0gDQoJVGhlIGxhdGVuY3kgaXNzdWUgaXMg aW1wb3J0YW50LiANCglXaGVuIGEgdXNlciAocmVhbCBodW1hbiBiZWluZykgcHJlc3NlcyBhIGxp Z2h0IGJ1dHRvbiB0aGUgdXNlciBleHBlY3RzIA0KCXRoZSBsaWdodCB0byB0dXJuIG9uLiANCglj UlBMcCBwcm9wb3NlcyB0aGF0IG5vZGVzIGluIHRoZSB0cmVlIHBlcmlvZGljYWxseSBhZHZlcnRp c2VzIHRoZWlyIA0KCXByZXNlbmNlIHVzaW5nIERBT3MuIA0KCVRoZSBwZXJpb2RpY2l0eSBpcyBh IHJlYWwgYmVhc3Q6IA0KCVRoYW5rcyB0byBUcmlja2xlLCB0aGUgcmF0ZSBvZiB1cGRhdGVzIGlu IGEgKGFwcGFyZW50bHkpIHN0YWJsZSBuZXR3b3JrIA0KCWlzIGxvdy4gVGhpcyBpcyBnb29kIHNp bmNlIGl0IGxlYXZlcyBiYW5kd2lkdGggZm9yIGRhdGEuIA0KCUJ1dCBpdCBpcyBub3QgZ29vZCBp ZiBleGlzdGluZyByb3V0ZXMgdG8gbXkgbGFtcCBmYWlsIGFuZCBJIGRvIG5vdCBnZXQgDQoJbmV3 IHJvdXRlcyB0byBteSBsYW1wIHVudGlsIGl0IGRlY2lkZXMgdG8gc2VuZCBvdXQgYSBuZXcgREFP LiANCglNeSB1c2VyIHdpbGwgKHdpdGggYSBnb29kIHJlYXNvbikgbm90IHRvbGVyYXRlIHdhaXRp bmcgZm9yIG1pbnV0ZXMgZm9yIA0KCXRoZSBsaWdodCB0byB0dXJuIG9uLiANCgkgDQoJSSBoYXZl IG1ldCB0d28gYXJndW1lbnRzIHRvIGNvdW50ZXIgdGhpcyBjb25jZXJuOiANCgkgDQoJQTE6IFdl bGwsIHlvdXIgbGFtcCBjYW4gYWx3YXlzIHNlbmQgYSBEQU8gd2hlbiBpdCBkZXRlY3RzIGEgcHJv YmxlbS4gDQoJICBNeSBhbnN3ZXI6IA0KCSAgVHJ1ZSwgZXhjZXB0IHRoYXQgbXkgbGFtcCBkb2Vz IG5vdCBpbnRlbmQgdG8gc2VuZCBhbnl0aGluZyANCgkgIHNvIGl0IHdpbGwgbmV2ZXIgZXhwZXJp ZW5jZSBhbnkgcHJvYmxlbXMgZnJvbSBpdHMgc2lkZSBvZiB0aGUgbmV0d29yay4gDQoJIA0KCUEy OiBXZWxsLCB5b3UgY2FuIGluY3JlYXNlIHRoZSBEQU8gcmF0ZSB0byBzdWItc2Vjb25kIHVwZGF0 ZXMuIA0KCSAgTXkgYW5zd2VyOiANCgkgIE9oIG5vLiBJIGdldCBhIHZlcnkgaGlnaCBkZWdyZWUg b2YgbWFuYWdlbWVudCB0cmFmZmljIHdoaWNoIA0KCSAgbGltaXRzIG15IGF2YWlsYWJsZSBiYW5k d2lkdGgsIGluY3JlYXNlcyB0aGUgcmlzayBvZiBjb2xsaXNpb25zIGFuZCANCgkgIGV2ZW4gcnVu IHRoZSByaXNrIG9mIHZpb2xhdGluZyBFVSBsZWdpc2xhdGlvbiByZXF1aXJpbmcgbWUgdG8gb25s eSANCgkgIHRyYW5zbWl0IGluIGxlc3MgdGhhbiAxJSBvZiB0aGUgdGltZTogDQoJICBodHRwOi8v Zm9jdXMudGkuY29tL2xpdC9hbi9zd3JhMDQ4L3N3cmEwNDgucGRmIA0KCSA4NjggLSA4NjguNiBN SHo6IDwxJSANCgkgDQoJICBSZWFjdGl2ZW5lc3MgaXMgaGFyZCB0byBhY2hpZXZlIHZpYSBwb2xs aW5nLiANCgkgDQoJIA0KCSANCglJZiB5b3UgYWdyZWUgdGhhdCB0aGlzIHNlZW1zIHRvIGJlIGNy aXRpY2FsIGlzc3VlcyBwbGVhc2UgcmFpc2UgeW91ciANCgl2b2ljZSBvbiB0aGUgbGlzdC4gDQoJ IA0KCUdvaW5nIGZvcndhcmQgDQoJPT09PT09PT09PT09PSANCgkgDQoJV2UgbmVlZCBzb21lIHJl YWN0aXZlIG1lY2hhbmlzbSB0byByZWFjaCBsYW1wcyBiZWZvcmUgdGhlIHVzZXIgZGVjaWRlcyAN Cgl0byBzdWUgb3VyIGNvbXBhbmllcy4gDQoJU28gaXMgdGhpcyBwb3NzaWJsZT8gSSB0aGluayBz by4gDQoJIA0KCUV4aXN0aW5nIGNvbW1lcmNpYWwgKG5vbi1JUCkgc29sdXRpb25zIGFyZSBjYXBh YmxlIG9mIHJlLXJvdXRpbmcgcXVpY2tseSANCglpZiB0aGV5IHJlYWxseSBoYXZlIHRvLiANCgkg DQoJTGV0IG1lIHRyeSBzY29waW5nIHRoZSByZXF1aXJlbWVudHMgdG8gYSBwb3RlbnRpYWwgc29s dXRpb246IA0KCShubyBkaWZmZXJlbnQgZnJvbSB0aGUgcmVxLiBkb2NzIGZvciBob21lIGFuZCBi dWlsZGluZykgDQoJIA0KCSogUDJQIHJvdXRpbmcgaW4gYW55IGRpcmVjdGlvbiBpbmRlcGVuZGVu dCBvZiB0aGUgdHJlZS4gDQoJIA0KCSogT24tZGVtYW5kIFAyUCByb3V0ZSBkaXNjb3ZlcnkgaWYg cmVxdWVzdGVkIGJ5IGEgcmVhbC10aW1lIGNyaXRpY2FsIGFwcC4gDQoJIERhdGEgY29sbGVjdGlv biBhcHBzIG1heSBiZSBhYmxlIHRvIGp1c3Qgd2FpdCBmb3IgdGhlIG5leHQgREFPIHVwZGF0ZS4g DQoJIA0KCSogTGltaXRlZCByYW5nZSBvZiBkaXNjb3ZlcnkgbWVjaGFuaXNtOiBtYXggNCByZXBl YXRlcnMuIA0KCSAgQSBUVEwgZmllbGQgbWF5IGxpbWl0IHRoZSBzY29wZSBvZiB0aGUgcmVwZWF0 ZXJzLiANCgkgDQoJKiBTdWJvcHRpbWFsIHJvdXRpbmcgYW5kIHRyYWZmaWMgYnVyc3RzIGFyZSBh Y2NlcHRlZCBpbiBleGNoYW5nZSANCgkgIGZvciBxdWljayByb3V0ZSByZXBhaXIuIEJ1dCBvbmx5 IGFzIGFuIGV4Y2VwdGlvbi4gDQoJIA0KCSANCglKdXN0IGFzIGFuIGV4YW1wbGUsIG9uZSBleGlz dGluZyBob21lIGNvbnRyb2wgdGVjaG5vbG9neSB1c2VzIGEgDQoJKHNvdXJjZSByb3V0aW5nKSB2 YXJpYW50IG9mIEFPRFYgZm9yIHF1aWNrIHJvdXRlIHJlcGFpci4gDQoJTm90aGluZyBjb21lcyBm b3IgZnJlZS4gVGhlIHByaWNlIGlzIGZsb29kaW5nIC0gYnV0IG5vdCBqdXN0IGZsb29kaW5nOiAN CglNYW5hZ2VkIGZsb29kaW5nIHVzaW5nIGEgZGlzdHJpYnV0ZWQgYWxnb3JpdGhtIHJ1bm5pbmcg aW4gYWxsIA0KCXBhcnRpY2lwYXRpbmcgbm9kZXMuIA0KCVRoZSBhbGdvcml0aG0gZGFtcGVucyB0 aGUgZmxvb2RpbmcgaW4gYSB0aW1lLCB2b2x1bWUgYW5kIHJhbmdlIA0KCXBlcnNwZWN0aXZlLiAN CglTb21lIHNpbWlsYXIgbWVjaGFuaXNtIGNvdWxkIGJlIGJ1aWx0IGludG8gUlBMIGZvciBxdWlj ayByb3V0ZSByZXBhaXIuIA0KCSANCgkgDQoJSWYgYW55b25lIGhhdmUgYWx0ZXJuYXRpdmUgcHJv cG9zYWxzLCBwbGVhc2UgYnJpbmcgaXQgdG8gdGhlIGxpc3QuIA0KCU5vdyBpcyB0aGUgdGltZS4g DQoJIA0KCSANCgkgDQoJVGhhbmtzLCANCgkgIEFuZGVycyANCgkgDQoJIA0KCSANCgkgDQoJX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18gDQoJUm9sbCBtYWls aW5nIGxpc3QgDQoJUm9sbEBpZXRmLm9yZyANCglodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL3JvbGwgDQoJIF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fIA0KCVJvbGwgbWFpbGluZyBsaXN0IA0KCVJvbGxAaWV0Zi5vcmcgDQoJaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9yb2xsIA0KCSANCgkgDQoJIA0KCSANCgkg DQoJICBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXyBSb2xs IG1haWxpbmcgDQoJbGlzdCBSb2xsQGlldGYub3JnIGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vcm9sbCANCglfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXyANCglSb2xsIG1haWxpbmcgbGlzdCANCglSb2xsQGlldGYub3JnIA0KCWh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcm9sbCANCgkgICAgDQoNCl9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fIA0KUm9sbCBtYWlsaW5nIGxp c3QgDQpSb2xsQGlldGYub3JnIA0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9yb2xsIA0KIA0KIA0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18gDQpSb2xsIG1haWxpbmcgbGlzdCANClJvbGxAaWV0Zi5vcmcgDQpodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3JvbGwgDQpfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXw0KUm9sbCBtYWlsaW5nIGxpc3QNClJvbGxAaWV0Zi5vcmcN Cmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcm9sbA0KICANCg== ------_=_NextPart_001_01CACAFC.9831DB45 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij48bWV0YSBuYW1lPUdlbmVyYXRvciBjb250ZW50 PSJNaWNyb3NvZnQgV29yZCAxNCAoZmlsdGVyZWQgbWVkaXVtKSI+PHN0eWxlPjwhLS0NCi8qIEZv bnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6V2luZ2RpbmdzOw0K CXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWls eTpXaW5nZGluZ3M7DQoJcGFub3NlLTE6NSAwIDAgMCAwIDAgMCAwIDAgMDt9DQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7 fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2IDQg MyA1IDQgNCAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsNCglwYW5v c2UtMToyIDExIDYgOSAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlZl cmRhbmE7DQoJcGFub3NlLTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5p dGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFy Z2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglm b250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiOw0KCWNvbG9yOmJsYWNrO30NCmE6 bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9y OmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNv SHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBs ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnANCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowY207DQoJbXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGNtOw0KCWZvbnQtc2l6ZTo4 LjBwdDsNCglmb250LWZhbWlseToiVmVyZGFuYSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOmJsYWNr O30NCnByZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IlByw6lm b3JtYXTDqSBIVE1MIENhciI7DQoJbWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7 DQoJZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBOZXciOw0KCWNvbG9y OmJsYWNrO30NCnAuTXNvQWNldGF0ZSwgbGkuTXNvQWNldGF0ZSwgZGl2Lk1zb0FjZXRhdGUNCgl7 bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJUZXh0ZSBkZSBidWxsZXMg Q2FyIjsNCgltYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6 OC4wcHQ7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOmJsYWNr O30NCnAuTXNvTGlzdFBhcmFncmFwaCwgbGkuTXNvTGlzdFBhcmFncmFwaCwgZGl2Lk1zb0xpc3RQ YXJhZ3JhcGgNCgl7bXNvLXN0eWxlLXByaW9yaXR5OjM0Ow0KCW1hcmdpbi10b3A6MGNtOw0KCW1h cmdpbi1yaWdodDowY207DQoJbWFyZ2luLWJvdHRvbTowY207DQoJbWFyZ2luLWxlZnQ6MzYuMHB0 Ow0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFt aWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7DQoJY29sb3I6YmxhY2s7fQ0KcC5uYW1lLCBs aS5uYW1lLCBkaXYubmFtZQ0KCXttc28tc3R5bGUtbmFtZTpuYW1lOw0KCW1zby1tYXJnaW4tdG9w LWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowY207DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG87DQoJbWFyZ2luLWxlZnQ6MGNtOw0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6 IlZlcmRhbmEiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjpibGFjazt9DQpzcGFuLlByZm9ybWF0SFRN TENhcg0KCXttc28tc3R5bGUtbmFtZToiUHLDqWZvcm1hdMOpIEhUTUwgQ2FyIjsNCgltc28tc3R5 bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IlByw6lmb3JtYXTDqSBIVE1MIjsNCglm b250LWZhbWlseToiQ29uc29sYXMiLCJzZXJpZiI7DQoJY29sb3I6YmxhY2s7fQ0Kc3Bhbi5FbWFp bFN0eWxlMjENCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6 IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4uVGV4dGVkZWJ1 bGxlc0Nhcg0KCXttc28tc3R5bGUtbmFtZToiVGV4dGUgZGUgYnVsbGVzIENhciI7DQoJbXNvLXN0 eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJUZXh0ZSBkZSBidWxsZXMiOw0KCWZv bnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjpibGFjazt9DQouTXNvQ2hw RGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0 O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46 NzAuODVwdCA3MC44NXB0IDcwLjg1cHQgNzAuODVwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3Bh Z2U6V29yZFNlY3Rpb24xO30NCi8qIExpc3QgRGVmaW5pdGlvbnMgKi8NCkBsaXN0IGwwDQoJe21z by1saXN0LWlkOjExNDUwNTA3OTk7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOi0zNzk2ODkzNjI7 fQ0KQGxpc3QgbDA6bGV2ZWwxDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCglt c28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjM2LjBwdDsNCgltc28tbGV2 ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCgltc28tYW5z aS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZl bDINCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87 DQoJbXNvLWxldmVsLXRhYi1zdG9wOjcyLjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9u OmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0 Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7DQoJbXNvLWJpZGktZm9udC1mYW1pbHk6IlRp bWVzIE5ldyBSb21hbiI7fQ0KQGxpc3QgbDA6bGV2ZWwzDQoJe21zby1sZXZlbC1udW1iZXItZm9y bWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjEw OC4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0x OC4wcHQ7DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGlu Z3M7fQ0KQGxpc3QgbDA6bGV2ZWw0DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsN Cgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjE0NC4wcHQ7DQoJbXNv LWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJbXNv LWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3Qg bDA6bGV2ZWw1DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwt dGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjE4MC4wcHQ7DQoJbXNvLWxldmVsLW51bWJl ci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJbXNvLWFuc2ktZm9udC1z aXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDA6bGV2ZWw2DQoJ e21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJ bXNvLWxldmVsLXRhYi1zdG9wOjIxNi4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjps ZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsN Cglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDA6bGV2ZWw3DQoJe21zby1sZXZlbC1u dW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRh Yi1zdG9wOjI1Mi4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQt aW5kZW50Oi0xOC4wcHQ7DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWls eTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDA6bGV2ZWw4DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0 OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjI4OC4w cHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4w cHQ7DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7 fQ0KQGxpc3QgbDA6bGV2ZWw5DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCglt c28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjMyNC4wcHQ7DQoJbXNvLWxl dmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJbXNvLWFu c2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDEN Cgl7bXNvLWxpc3QtaWQ6MTE2NDAxMjUxNjsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6LTE3Njk4 MzI1MDQ7fQ0KQGxpc3QgbDINCgl7bXNvLWxpc3QtaWQ6MTI0OTA4MDQxODsNCgltc28tbGlzdC10 ZW1wbGF0ZS1pZHM6ODM5NjcyMDA2O30NCkBsaXN0IGwyOmxldmVsMQ0KCXttc28tbGV2ZWwtbnVt YmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWIt c3RvcDozNi4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5k ZW50Oi0xOC4wcHQ7DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpT eW1ib2w7fQ0KQGxpc3QgbDI6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxl dDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDo3Mi4wcHQ7DQoJbXNv LWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJbXNv LWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBOZXciOw0KCW1z by1iaWRpLWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iO30NCkBsaXN0IGwyOmxldmVsMw0K CXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0K CW1zby1sZXZlbC10YWItc3RvcDoxMDguMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246 bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7 DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwyOmxldmVsNA0KCXttc28tbGV2ZWwt bnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10 YWItc3RvcDoxNDQuMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0 LWluZGVudDotMTguMHB0Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1p bHk6V2luZ2RpbmdzO30NCkBsaXN0IGwyOmxldmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1h dDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDoxODAu MHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTgu MHB0Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2Rpbmdz O30NCkBsaXN0IGwyOmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJ bXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDoyMTYuMHB0Ow0KCW1zby1s ZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCW1zby1h bnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwy OmxldmVsNw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRl eHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDoyNTIuMHB0Ow0KCW1zby1sZXZlbC1udW1iZXIt cG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCW1zby1hbnNpLWZvbnQtc2l6 ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwyOmxldmVsOA0KCXtt c28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1z by1sZXZlbC10YWItc3RvcDoyODguMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVm dDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJ Zm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwyOmxldmVsOQ0KCXttc28tbGV2ZWwtbnVt YmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWIt c3RvcDozMjQuMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWlu ZGVudDotMTguMHB0Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6 V2luZ2RpbmdzO30NCkBsaXN0IGwzDQoJe21zby1saXN0LWlkOjE2NTQ4NzIyMDk7DQoJbXNvLWxp c3QtdHlwZTpoeWJyaWQ7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOjQ5Njc4OTA5MiA1NTA5MDI5 NjIgNjc2OTg2OTEgNjc2OTg2OTMgNjc2OTg2ODkgNjc2OTg2OTEgNjc2OTg2OTMgNjc2OTg2ODkg Njc2OTg2OTEgNjc2OTg2OTM7fQ0KQGxpc3QgbDM6bGV2ZWwxDQoJe21zby1sZXZlbC1zdGFydC1h dDowOw0KCW1zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDot Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246 bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fu cy1zZXJpZiI7DQoJbXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6Q2FsaWJyaTt9DQpAbGlzdCBsMzps ZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0 Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlv bjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3 Ijt9DQpAbGlzdCBsMzpsZXZlbDMNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0K CW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2 ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglmb250LWZh bWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDM6bGV2ZWw0DQoJe21zby1sZXZlbC1udW1iZXItZm9y bWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5v bmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4w cHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwzOmxldmVsNQ0KCXttc28tbGV2ZWwt bnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFi LXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRl bnQ6LTE4LjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCkBsaXN0IGwzOmxldmVs Ng0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674Kn Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246 bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpA bGlzdCBsMzpsZXZlbDcNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1s ZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVt YmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglmb250LWZhbWlseTpT eW1ib2w7fQ0KQGxpc3QgbDM6bGV2ZWw4DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxl dDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1s ZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCWZvbnQt ZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDM6bGV2ZWw5DQoJe21zby1sZXZlbC1udW1i ZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1z dG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50 Oi0xOC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGw0DQoJe21zby1saXN0 LWlkOjIwNDEyNzMyODM7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOi0yODc1NzM2O30NCm9sDQoJ e21hcmdpbi1ib3R0b206MGNtO30NCnVsDQoJe21hcmdpbi1ib3R0b206MGNtO30NCi0tPjwvc3R5 bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0 IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDld Pjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRp dCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT48L2hlYWQ+ PGJvZHkgYmdjb2xvcj13aGl0ZSBsYW5nPUVOLVVTIGxpbms9Ymx1ZSB2bGluaz1wdXJwbGU+PGRp diBjbGFzcz1Xb3JkU2VjdGlvbjE+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFG NDk3RCc+SGkgUm9iZXJ0IGFuZCBNdWt1bDo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9 TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxp YnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPldl4oCZdmUgYmVl biBsaXZpbmcgd2l0aCBhIGRpc2Nvbm5lY3QgZm9yIHNvbWUgdGltZSBpdCBhcHBlYXJzLjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdE Jz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0 eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7 Y29sb3I6IzFGNDk3RCc+TXkgY3VycmVudCB1bmRlcnN0YW5kaW5nIGlzIHRoYXQgdGhlIERJUyB0 aGF0IE11a3VsIHByb3Bvc2VzIGlzIGEgZmluZSBhcHByb2FjaCB0byByZWxvY2F0ZSBhIERBRyB0 aGF0IHRoZSBub2RlIHVzZWQgdG8gYmVsb25nIHRvIG9yIHdpc2hlcyB0byBiZWxvbmcgdG8uIEl0 IGlzIG1vcmUgbGlrZSBhIHF1aWNrIHJlcGFpciBtZWNoYW5pc20gdG8gZW5zdXJlIHRoYXQgdGhl IGxpZ2h0IGNvbWVzIHVwIGluIGEgcmVhc29uYWJsZSB0aW1lIHRoYW4gZmluZGluZyBhIHBhdGgg dGhhdOKAmXMgYmV0dGVyIHRoYW4gdGhlIG9uZSB0aGUgREFHIHByb3ZpZGVzLiBNdWt1bCwgaXMg dGhhdCBjb3JyZWN0PzxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNw YW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNl cmlmIjtjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9 TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxp YnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+VGhlIERJTyB0aGF0IHdlIGFyZSBkaXNj dXNzaW5nIGhlcmUgZGVhbHMgd2l0aCB3aGF0IEnigJlkIGNhbGwgdGhlIHJlYWxseSBQMlAgcHJv YmxlbSwgdGhhdCBpcyB0byBjcmVhdGUgb3B0aW1pemVkIHJvdXRlcyB3aXRoaW4gYSBzZXQgb2Yg wqBub2RlcyB3aXRoaW4gc3BlY2lmaWMgY29uc3RyYWludHMgdGhhdCBhcmUgbm90IHRob3NlIG9m IHRoZSBtYWluIERBRywgYW5kIHdlIGRvIHRoYXQgYnkgY3JlYXRpbmcgYSBuZXcgREFHIGluIGEg c29tZXdoYXQgQU9EViBmYXNoaW9uLiBSUEwgbmVlZHMgc21hbGwgYWRkaXRpb25zIHRvIGRvIHRo YXQ6PG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0n Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9y OiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29MaXN0UGFy YWdyYXBoIHN0eWxlPSd0ZXh0LWluZGVudDotMTguMHB0O21zby1saXN0OmwzIGxldmVsMSBsZm81 Jz48IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPjxzcGFuIHN0eWxl PSdtc28tbGlzdDpJZ25vcmUnPi08c3BhbiBzdHlsZT0nZm9udDo3LjBwdCAiVGltZXMgTmV3IFJv bWFuIic+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7IDwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBzdHlsZT0nZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0Qn PkVuYWJsZSDigJhsb2NhbOKAmSBpbnN0YW5jZUlEcyBzbyB0aGF0IHRoZSByb290IGVuZHBvaW50 IGNhbiBhdXRvY29uZiBhbiBpbnN0YW5jZUlEIGZvciBhIERBRyB0aGF0IGl0IGlzIHRoZSBzb2xl IHJvb3QuPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb0xpc3RQYXJhZ3JhcGggc3R5 bGU9J3RleHQtaW5kZW50Oi0xOC4wcHQ7bXNvLWxpc3Q6bDMgbGV2ZWwxIGxmbzUnPjwhW2lmICFz dXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJD YWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+PHNwYW4gc3R5bGU9J21zby1saXN0 Oklnbm9yZSc+LTxzcGFuIHN0eWxlPSdmb250OjcuMHB0ICJUaW1lcyBOZXcgUm9tYW4iJz4mbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgPC9zcGFu Pjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+QWRkIOKAmHRh cmdldHPigJkgdG8gdGhlIERJTzxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29MaXN0 UGFyYWdyYXBoIHN0eWxlPSd0ZXh0LWluZGVudDotMTguMHB0O21zby1saXN0OmwzIGxldmVsMSBs Zm81Jz48IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPjxzcGFuIHN0 eWxlPSdtc28tbGlzdDpJZ25vcmUnPi08c3BhbiBzdHlsZT0nZm9udDo3LjBwdCAiVGltZXMgTmV3 IFJvbWFuIic+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7IDwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBzdHlsZT0nZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5 N0QnPkVuYWJsZSBhIHF1aWNrIHRpbWUgb3V0IG9mIERJTyBzdGF0ZXMgd2hlbiBubyBEQU8gaXMg c2VlbjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29MaXN0UGFyYWdyYXBoPjxzcGFu IHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJp ZiI7Y29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1z b05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJy aSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPlNvbWUgb2YgdGhpcyBjYW4gYmUgaGlkZGVu IGluIGFuIHNvLWZhci11bnNwZWNpZmllZCDCoG9iamVjdGl2ZSBmdW5jdGlvbiwgYnV0IEkgdGhp bmsgd2UgbmVlZCB0byBkaXNjdXNzIHRoZSBpbnN0YW5jZSBJRCBwaWVjZSBhIGJpdCBtb3JlLjxv OnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0 OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+ PHNwYW4gbGFuZz1GUiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJy aSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPlBhc2NhbDxvOnA+PC9vOnA+PC9zcGFuPjwv cD48L2Rpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+PGRpdiBzdHlsZT0nYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6 c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDQuMHB0Jz48ZGl2PjxkaXYgc3R5 bGU9J2JvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMu MHB0IDBjbSAwY20gMGNtJz48cCBjbGFzcz1Nc29Ob3JtYWw+PGI+PHNwYW4gbGFuZz1GUiBzdHls ZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7Y29s b3I6d2luZG93dGV4dCc+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9RlIgc3R5bGU9J2ZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiO2NvbG9yOndpbmRv d3RleHQnPiByb2xsLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpyb2xsLWJvdW5jZXNAaWV0Zi5v cmddIDxiPk9uIEJlaGFsZiBPZiA8L2I+Um9iZXJ0IENyYWdpZTxicj48Yj5TZW50OjwvYj4gTW9u ZGF5LCBNYXJjaCAyMiwgMjAxMCAxMjowNyBQTTxicj48Yj5Ubzo8L2I+IE11a3VsIEdveWFsPGJy PjxiPkNjOjwvYj4gcm9sbDxicj48Yj5TdWJqZWN0OjwvYj4gUmU6IFtSb2xsXSBQMlAgcGVyZm9y bWFuY2Ugd2l0aCBjdXJyZW50IFJQTCBwcm9wb3NhbDxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rp dj48L2Rpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PG86cD4mbmJzcDs8L286cD48L3A+PHAgY2xhc3M9 TXNvTm9ybWFsPkkgdGhpbmsgdGhlIGlkZWEgb2YgbXVsdGlwbGUgRE9EQUdzIGNvdWxkIHdvcmsg Zm9yIFAyUCBpZiBpdCBpcyBwb3NzaWJsZSB0byBwcm92aWRlIHNvbWUgc29ydCBvZiBwcnVuZWQg RE9EQUdzLiBJIHRoaW5rIHRoZSBESVMgbWVjaGFuaXNtIGJlbG93IGNvdWxkIHdvcmsgYnV0IEkg dGhpbmsgdXNpbmcgRElPcyB0byBtZSBzZWVtcyBtb3JlIG9ydGhvZ29uYWwgYW5kIHN5bW1ldHJp Yy48YnI+PGJyPjxzcGFuIHN0eWxlPSdmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIic+ SSB0aGluayB0aGUgc29sdXRpb24gY291bGQgYmUgdG8gdXNlIGEgJ3RhcmdldGVkJyBESU8gd2hp Y2ggY2FuIGJlIGVtaXR0ZWQgYW5kIHByb3BhZ2F0ZWQgaW1tZWRpYXRlbHkuIENvbnNpZGVyIEEg dHJ5aW5nIHRvIGNvbW11bmljYXRlIHdpdGggQjo8L3NwYW4+PG86cD48L286cD48L3A+PG9sIHN0 YXJ0PTEgdHlwZT0xPjxsaSBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21zby1saXN0Omw0IGxldmVsMSBsZm8z Jz48c3BhbiBzdHlsZT0nZm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiInPkEgZG9lcyBu b3QgaGF2ZSBhIHJvdXRpbmcgdGFibGUgZW50cnkgZm9yIEI8L3NwYW4+PG86cD48L286cD48L2xp PjxsaSBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvO21zby1saXN0Omw0IGxldmVsMSBsZm8zJz48c3BhbiBzdHls ZT0nZm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiInPkEgKG5vdyBlZmZlY3RpdmVseSBh IERPREFHIHJvb3QpIHNlbmRzIGEgRElPIHRhcmdldGVkIGF0IEIgdG8gYWxsIHJvdXRlcnMgbXVs dGljYXN0IGltbWVkaWF0ZWx5ICh3aXRoIGppdHRlcik8L3NwYW4+PG86cD48L286cD48L2xpPjxs aSBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvO21zby1saXN0Omw0IGxldmVsMSBsZm8zJz48c3BhbiBzdHlsZT0n Zm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiInPklmIGEgcm91dGVyIGhlYXJzIGl0IGFu ZCBoYXMgYSBET0RBRyBlbnRyeSB0byBCIGl0IGNhbiB0aGVuIGJlIHJvdXRlZCBhcyBub3JtYWwg dG8gQjwvc3Bhbj48bzpwPjwvbzpwPjwvbGk+PGxpIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bXNvLWxpc3Q6 bDQgbGV2ZWwxIGxmbzMnPklmIGEgcm91dGVyIGhlYXJzIGl0IGFuZCBkb2Vzbid0IGhhdmUgYSBE T0RBRyBlbnRyeSB0byBCLCBpdCB3aWxsIHByb3BhZ2F0ZSBpdCBhbGwgcm91dGVycyBtdWx0aWNh c3QgKHdpdGggYSBUVEwpIDxzcGFuIHN0eWxlPSdmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNl cmlmIic+aW1tZWRpYXRlbHkgKHdpdGggaml0dGVyKTwvc3Bhbj48bzpwPjwvbzpwPjwvbGk+PGxp IGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG87bXNvLWxpc3Q6bDQgbGV2ZWwxIGxmbzMnPldoZW4gQiBoZWFycyB0 aGUgRElPLCBpdCByZXNwb25kcyB3aXRoIGEgREFPIDxzcGFuIHN0eWxlPSdmb250LWZhbWlseToi QXJpYWwiLCJzYW5zLXNlcmlmIic+ZGVzdGluZWQgZm9yIEEgYW5kIHNlbnQgYmFjayBhbG9uZyB0 aGUgRE9EQUcgdG8gQS48L3NwYW4+PG86cD48L286cD48L2xpPjxsaSBjbGFzcz1Nc29Ob3JtYWwg c3R5bGU9J21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv O21zby1saXN0Omw0IGxldmVsMSBsZm8zJz48c3BhbiBzdHlsZT0nZm9udC1mYW1pbHk6IkFyaWFs Iiwic2Fucy1zZXJpZiInPkludGVybWVkaWF0ZSByb3V0ZXJzIGNhbiBzZXQgdXAgdGhlIHJvdXRl IHRvIEIgaWYgZGVzaXJlZCBvciBBIGNhbiB1c2Ugc291cmNlIHJvdXRpbmcuPC9zcGFuPjxvOnA+ PC9vOnA+PC9saT48L29sPjxwIGNsYXNzPU1zb05vcm1hbD5Tb21lIHBvaW50czo8bzpwPjwvbzpw PjwvcD48dWwgdHlwZT1kaXNjPjxsaSBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21zby1saXN0OmwwIGxldmVs MSBsZm80Jz5UaGUgc3RhbmRhcmQgREFHIHByb2Nlc3Npbmcgb2YgcmFuayByZWxhdGl2ZSB0byBB IHVzaW5nIHRoZSBPRiB3b3VsZCBhc3N1cmUgcHJvcGFnYXRpb24gb2YgdGhlIHRhcmdldGVkIERJ TyBhd2F5IGZyb20gQSBhbmQgZm9ybWF0aW9uIG9mIGEgREFHIGJhY2sgdG8gQTxvOnA+PC9vOnA+ PC9saT48bGkgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttc28tbGlzdDpsMCBsZXZlbDEgbGZvNCc+Um91dGVy cyB3aGljaCBkbyBub3Qgc2VlIHRoZSBjb3JyZXNwb25kaW5nIERBTyB3b3VsZCB0aW1lIG91dCBh bmQgZGlzY2FyZCB0aGUgRE9EQUcgZW50cnkgZm9yIEEuPG86cD48L286cD48L2xpPjwvdWw+PHAg Y2xhc3M9TXNvTm9ybWFsPlRoaXMgd291bGQgZ2l2ZSB0aGUgYWJpbGl0eSB0byBjcmVhdGUgYSAn cHJ1bmVkJyBET0RBRyB0aHVzIGdpdmluZyB0aGUgUDJQIG5lZWRlZCB3aXRob3V0IGFsbCByb3V0 ZXJzIGhhdmluZyB0byBzZXQgdXAgRE9EQUcgZW50cmllcyBiYWNrIHRvIEEuIEFzIGZhciBhcyBJ IGNhbiBzZWUsIHRoaXMgc3RheXMgcHJldHR5IGNsb3NlIHRvIFJQTCBidXQgYWRkcyB0aGUgaWRl YSBvZiBhIERJTyB0YXJnZXQgYW5kIGFuIGFsdGVybmF0aXZlIGRlbGl2ZXJ5IG1lY2hhbmlzbSBh cyBvcHBvc2VkIHRvIHRyaWNrbGUgdGltZXIgKGV2ZW4gdGhlbiwgaXQgaXMgcmVhbGx5IGEgc3Vi c2V0IG9mIGEgdHJpY2tsZSB0aW1lcikuPGJyPjxicj5BcyBhbHdheXMsIEkgYW0gc3VyZSB0aGVy ZSBhcmUgc3RpbGwgc29tZSBvdGhlciBpc3N1ZXMgdG8gY29uc2lkZXIuPGJyPjxicj5Sb2JlcnQ8 bzpwPjwvbzpwPjwvcD48ZGl2PjxwIGNsYXNzPW5hbWU+Um9iZXJ0IENyYWdpZSAoUGFjaWZpYyBH YXMgJmFtcDsgRWxlY3RyaWMpPG86cD48L286cD48L3A+PHA+R3JpZG1lcmdlIEx0ZC48YnI+ODkg R3JlZW5maWVsZCBDcmVzY2VudCw8YnI+V2FrZWZpZWxkLCBXRjQgNFdBLCBVSzxicj4rNDQgKDAp IDE5MjQgOTEwODg4PGJyPjxhIGhyZWY9Imh0dHA6Ly93d3cuZ3JpZG1lcmdlLmNvbS8iPmh0dHA6 Ly93d3cuZ3JpZG1lcmdlLmNvbTwvYT48bzpwPjwvbzpwPjwvcD48L2Rpdj48cCBjbGFzcz1Nc29O b3JtYWw+PGJyPk9uIDIyLzAzLzIwMTAgNToxNSBQTSwgTXVrdWwgR295YWwgd3JvdGU6IDxvOnA+ PC9vOnA+PC9wPjxwcmU+Tm8uIEFzIERvbiBwb2ludGVkIG91dCwgdGhlIHJvdXRlIHNlbGVjdGlv biBpcyBiYXNlZCBvbiBhbiBvYmplY3QgZnVuY3Rpb24gZGVzaXJlZCBieSB0aGUgbm9kZSBpbml0 aWF0aW5nIHRoZSByb3V0ZSBkaXNjb3ZlcnkuIFRoZSBvbmx5IHRoaW5nIGJhc2VkIG9uIGhvcCBj b3VudCBhdCB0aGlzIHBvaW50IGlzIHRoZSBzY29wZSBvZiBkaXNjb3ZlcnkgLSBob3cgZmFyIHRo ZSBESVMgdHJhdmVscy4gSSBndWVzcyB0aGlzIGFsc28gY291bGQgYmUgY2hhbmdlZCB0byBhICZx dW90O2Rpc2NvdmVyeSBzY29wZSZxdW90OyBmdW5jdGlvbiBpZiBkZXNpcmVkLjxvOnA+PC9vOnA+ PC9wcmU+PHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPjxwcmU+VGhhbmtzPG86cD48L286cD48 L3ByZT48cHJlPk11a3VsPG86cD48L286cD48L3ByZT48cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9w cmU+PHByZT4tLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tPG86cD48L286cD48L3ByZT48cHJl PkZyb206ICZxdW90O1BoaWxpcCBMZXZpcyZxdW90OyA8YSBocmVmPSJtYWlsdG86cGFsQGNzLnN0 YW5mb3JkLmVkdSI+Jmx0O3BhbEBjcy5zdGFuZm9yZC5lZHUmZ3Q7PC9hPjxvOnA+PC9vOnA+PC9w cmU+PHByZT5UbzogJnF1b3Q7ZCBzdHVyZWsmcXVvdDsgPGEgaHJlZj0ibWFpbHRvOmQuc3R1cmVr QGF0dC5uZXQiPiZsdDtkLnN0dXJla0BhdHQubmV0Jmd0OzwvYT48bzpwPjwvbzpwPjwvcHJlPjxw cmU+Q2M6ICZxdW90O0FuZGVycyBCcmFuZHQmcXVvdDsgPGEgaHJlZj0ibWFpbHRvOmFickBzZGVz aWducy5kayI+Jmx0O2FickBzZGVzaWducy5kayZndDs8L2E+LCAmcXVvdDtNdWt1bCBHb3lhbCZx dW90OyA8YSBocmVmPSJtYWlsdG86bXVrdWxAdXdtLmVkdSI+Jmx0O211a3VsQHV3bS5lZHUmZ3Q7 PC9hPiwgJnF1b3Q7UGFzY2FsIFRodWJlcnQgKHB0aHViZXJ0KSZxdW90OyA8YSBocmVmPSJtYWls dG86cHRodWJlcnRAY2lzY28uY29tIj4mbHQ7cHRodWJlcnRAY2lzY28uY29tJmd0OzwvYT4sICZx dW90O1JPTEwgV0cmcXVvdDsgPGEgaHJlZj0ibWFpbHRvOnJvbGxAaWV0Zi5vcmciPiZsdDtyb2xs QGlldGYub3JnJmd0OzwvYT4sICZxdW90O1RlZCBIdW1wYWwmcXVvdDsgPGEgaHJlZj0ibWFpbHRv OlRlZC5IdW1wYWxAamNpLmNvbSI+Jmx0O1RlZC5IdW1wYWxAamNpLmNvbSZndDs8L2E+PG86cD48 L286cD48L3ByZT48cHJlPlNlbnQ6IE1vbmRheSwgTWFyY2ggMjIsIDIwMTAgMTE6MjA6NDYgQU0g R01UIC0wNjowMCBVUy9DYW5hZGEgQ2VudHJhbDxvOnA+PC9vOnA+PC9wcmU+PHByZT5TdWJqZWN0 OiBSZTogW1JvbGxdIFAyUCBwZXJmb3JtYW5jZSB3aXRoIGN1cnJlbnQgUlBMIHByb3Bvc2FsPG86 cD48L286cD48L3ByZT48cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+PHByZT48bzpwPiZuYnNw OzwvbzpwPjwvcHJlPjxwcmU+SnVzdCB0byBiZSBzdXJlIEkgYW0gaGVhcmluZyB0aGlzIHJpZ2h0 IC10aGUgcHJvcG9zYWwgaXMgdG8gdXNlIGhvcGNvdW50LWJhc2VkIHJvdXRlIHNlbGVjdGlvbj8g PG86cD48L286cD48L3ByZT48cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+PHByZT48bzpwPiZu YnNwOzwvbzpwPjwvcHJlPjxwcmU+UGhpbCA8bzpwPjwvbzpwPjwvcHJlPjxwcmU+PG86cD4mbmJz cDs8L286cD48L3ByZT48cHJlPk9uIE1hciAyMiwgMjAxMCwgYXQgNzo1MiBBTSwgJnF1b3Q7RG9u IFN0dXJlayZxdW90OyAmbHQ7IDxhIGhyZWY9Im1haWx0bzpkLnN0dXJla0BhdHQubmV0Ij5kLnN0 dXJla0BhdHQubmV0PC9hPiAmZ3Q7IHdyb3RlOiA8bzpwPjwvbzpwPjwvcHJlPjxwcmU+PG86cD4m bmJzcDs8L286cD48L3ByZT48cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+PHByZT48bzpwPiZu YnNwOzwvbzpwPjwvcHJlPjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT48cHJlPjxvOnA+Jm5i c3A7PC9vOnA+PC9wcmU+PHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPjxwcmU+PG86cD4mbmJz cDs8L286cD48L3ByZT48cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+PHByZT5IaSBBbmRlcnMg YW5kIE11a3VsLCA8bzpwPjwvbzpwPjwvcHJlPjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT48 cHJlPiZuYnNwOyA8bzpwPjwvbzpwPjwvcHJlPjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT48 cHJlPlRoaXMgaXMgYWxsIHNvdW5kaW5nIHF1aXRlIHByb21pc2luZyBpbiBhZGRyZXNzaW5nIFAy UCByb3V0aW5nIGluIFJQTC4mbmJzcDsgSG93IGNhbiB3ZSBvcmdhbml6ZSBhIHNwZWNpZmljIHBy b3Bvc2FsIHdlIGNhbiBnYWluIFdHIGFwcHJvdmFsIGZvcj8mbmJzcDsgSSB3b3VsZCBsaWtlIHRv IGxlYXZlIEFuYWhlaW0gd2l0aCBhbiBhZ3JlZWQgcGF0aCB0b3dhcmRzIFAyUCByb3V0aW5nIHN1 cHBvcnQgd2UgYWxsIGJlbGlldmUgYWRkcmVzc2VzIHRoZSBIb21lIEF1dG9tYXRpb24gYW5kIEJ1 aWxkaW5nIENvbnRyb2xzIHVzZSBjYXNlcy4gPG86cD48L286cD48L3ByZT48cHJlPjxvOnA+Jm5i c3A7PC9vOnA+PC9wcmU+PHByZT4mbmJzcDsgPG86cD48L286cD48L3ByZT48cHJlPjxvOnA+Jm5i c3A7PC9vOnA+PC9wcmU+PHByZT5Eb24gPG86cD48L286cD48L3ByZT48cHJlPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wcmU+PHByZT4mbmJzcDsgPG86cD48L286cD48L3ByZT48cHJlPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wcmU+PHByZT4mbmJzcDsgPG86cD48L286cD48L3ByZT48cHJlPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wcmU+PHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPjxwcmU+PG86cD4mbmJzcDs8 L286cD48L3ByZT48cHJlPkZyb206IDxhIGhyZWY9Im1haWx0bzpyb2xsLWJvdW5jZXNAaWV0Zi5v cmciPnJvbGwtYm91bmNlc0BpZXRmLm9yZzwvYT4gWzxhIGhyZWY9Im1haWx0bzpyb2xsLWJvdW5j ZXNAaWV0Zi5vcmciPm1haWx0bzpyb2xsLWJvdW5jZXNAaWV0Zi5vcmc8L2E+XSBPbiBCZWhhbGYg T2YgQW5kZXJzIEJyYW5kdCA8bzpwPjwvbzpwPjwvcHJlPjxwcmU+U2VudDogTW9uZGF5LCBNYXJj aCAyMiwgMjAxMCA3OjQ2IEFNIDxvOnA+PC9vOnA+PC9wcmU+PHByZT5UbzogTXVrdWwgR295YWw7 IFBhc2NhbCBUaHViZXJ0IChwdGh1YmVydCkgPG86cD48L286cD48L3ByZT48cHJlPkNjOiBST0xM IFdHOyBUZWQgSHVtcGFsIDxvOnA+PC9vOnA+PC9wcmU+PHByZT5TdWJqZWN0OiBSZTogW1JvbGxd IFAyUCBwZXJmb3JtYW5jZSB3aXRoIGN1cnJlbnQgUlBMIHByb3Bvc2FsIDxvOnA+PC9vOnA+PC9w cmU+PHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPjxwcmU+Jm5ic3A7IDxvOnA+PC9vOnA+PC9w cmU+PHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPjxwcmU+PG86cD4mbmJzcDs8L286cD48L3By ZT48cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+PHByZT5BZGQgdG8gdGhpcyBhbiBlbGVtZW50 IG9mIHByb21pc2N1b3MgbGlzdGVuaW5nIHRvIGRhbXBlbiB0aGUgc3Rvcm0gPSZndDsgaWYgbm9k ZSBhbHJlYWR5IGRldGVjdGVkIGEgY29weSBvZiB0aGUgRElTIHdpdGggdGhlIHNhbWUgVFRMIChv ciBsb3dlcikgLSBkbyBub3QgZm9yd2FyZCB0aGUgRElTLiBUaGVuIHlvdSBzdGFydCBnZXR0aW5n IGNsb3NlciB0byBzb21ldGhpbmcuIDxvOnA+PC9vOnA+PC9wcmU+PHByZT48bzpwPiZuYnNwOzwv bzpwPjwvcHJlPjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT48cHJlPiZuYnNwOyA8bzpwPjwv bzpwPjwvcHJlPjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT48cHJlPjxvOnA+Jm5ic3A7PC9v OnA+PC9wcmU+PHByZT5PaCAtIGFuZCBieSB0aGUgd2F5IC0gcmVjb3JkIHRoZSBzb3VyY2Ugcm91 dGUgb24gdGhlIHdheSA7LSkgPG86cD48L286cD48L3ByZT48cHJlPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wcmU+PHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPjxwcmU+Jm5ic3A7IDxvOnA+PC9vOnA+ PC9wcmU+PHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPjxwcmU+PG86cD4mbmJzcDs8L286cD48 L3ByZT48cHJlPi0gQW5kZXJzIDxvOnA+PC9vOnA+PC9wcmU+PHByZT48bzpwPiZuYnNwOzwvbzpw PjwvcHJlPjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT48cHJlPiZuYnNwOyA8bzpwPjwvbzpw PjwvcHJlPjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT48cHJlPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wcmU+PHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPjxwcmU+RnJhOiA8YSBocmVmPSJtYWls dG86cm9sbC1ib3VuY2VzQGlldGYub3JnIj5yb2xsLWJvdW5jZXNAaWV0Zi5vcmc8L2E+IHDDpSB2 ZWduZSBhZiBNdWt1bCBHb3lhbCA8bzpwPjwvbzpwPjwvcHJlPjxwcmU+U2VuZHQ6IG1hIDIyLTAz LTIwMTAgMDE6NDcgPG86cD48L286cD48L3ByZT48cHJlPlRpbDogUGFzY2FsIFRodWJlcnQgKHB0 aHViZXJ0KSA8bzpwPjwvbzpwPjwvcHJlPjxwcmU+Q2M6IFJPTEwgV0c7IFRlZCBIdW1wYWwgPG86 cD48L286cD48L3ByZT48cHJlPkVtbmU6IFJlOiBbUm9sbF0gUDJQIHBlcmZvcm1hbmNlIHdpdGgg Y3VycmVudCBSUEwgcHJvcG9zYWwgPG86cD48L286cD48L3ByZT48cHJlPjxvOnA+Jm5ic3A7PC9v OnA+PC9wcmU+PHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPjxwcmU+SGkgUGFzY2FsIDxvOnA+ PC9vOnA+PC9wcmU+PHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPjxwcmU+VGhhbmtzIGZvciB5 b3VyIGNvbW1lbnRzIChsZXQgbWUgc2VuZCBteSByZXNwb25zZSBpbiB0aGUgbmV4dCBlbWFpbCku IDxvOnA+PC9vOnA+PC9wcmU+PHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPjxwcmU+QmFzZWQg b24gZnVydGhlciB0aG91Z2h0cywgaXQgc2VlbXMgdG8gbWUgdGhhdCBhIERBRyBiYXNlZCBQMlAg c29sdXRpb24gd291bGQgd29yayBpZiB3ZSBkbyB0aGUgZm9sbG93aW5nOiA8bzpwPjwvbzpwPjwv cHJlPjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT48cHJlPihhKSBhbGxvd2luZyBtdWx0aWNh c3QgRElTIG1lc3NhZ2VzIHRvIHNwcmVhZCB0byBhbiBvcmlnaW5hdG9yLXNwZWNpZmllZCBudW1i ZXIgb2YgaG9wcyBhbmQgPG86cD48L286cD48L3ByZT48cHJlPihiKSBhbGxvd2luZyBub2RlcyB0 byBqb2luIGEgREFHIHRlbXBvcmFyaWx5IGFuZCBsZWF2ZSBpdCBpZiB0aGVyZSBpcyBub3Qgc3Vm ZmljaWVudCDigJxyb3V0aW5nIGludGVyZXN04oCdIGluIGJlaW5nIHBhcnQgb2YgdGhlIERBRy4g PG86cD48L286cD48L3ByZT48cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+PHByZT5XaXRoIHRo ZXNlIHBvaW50cyBpbiBtaW5kLCBhIFAyUCBzY2hlbWUgY291bGQgd29yayBhcyBmb2xsb3dzOiA8 bzpwPjwvbzpwPjwvcHJlPjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT48cHJlPjEuIFdoZW4g YSBub2RlIHdhbnRzIHRvIGpvaW4gYSBET0RBRyhELEYpLCB3aGVyZSBEIGlzIHRoZSBET0RBRydz IHJvb3QgYW5kIEYgaXMgdGhlIE9GIGJlaW5nIHVzZWQsIGl0IGRvZXMgdGhlIGZvbGxvd2luZzog PG86cD48L286cD48L3ByZT48cHJlPiZuYnNwOyZuYnNwOyZuYnNwOyBhLiBJbml0aWF0ZXMgYSBk aXNjb3ZlcnkgdGFibGUgZW50cnkgZm9yIERPREFHKEQsRikuIFRoZSBkaXNjb3ZlcnkgdGFibGUg ZW50cmllcyBhcmUgcmVtb3ZlZCBhZnRlciBhIGNlcnRhaW4gbGlmZXRpbWUuIDxvOnA+PC9vOnA+ PC9wcmU+PHByZT4mbmJzcDsmbmJzcDsmbmJzcDsgYi4gc2VuZHMgb3V0IGEgRElTIHZpYSBsaW5r LWxvY2FsIG11bHRpY2FzdCBhc2tpbmcgc3BlY2lmaWNhbGx5IGZvciBpbmZvcm1hdGlvbiBhYm91 dCBET0RBRyhELEYpLiBJdCBhbHNvIGxpc3RzIGluIHRoZSBESVMgdGhlIG51bWJlciBvZiBob3Bz IHRoZSBESVMgY2FuIHRyYXZlbC4gPG86cD48L286cD48L3ByZT48cHJlPjxvOnA+Jm5ic3A7PC9v OnA+PC9wcmU+PHByZT4yLiBPbiByZWNlaXZpbmcmbmJzcDsgYSBESVMsIGEgbm9kZSBkb2VzIHRo ZSBmb2xsb3dpbmc6IDxvOnA+PC9vOnA+PC9wcmU+PHByZT4mbmJzcDsmbmJzcDsmbmJzcDsgYS5p ZiBpdCBkb2VzIG5vdCBrbm93IGFib3V0IERPREFHKEQsRikgYW5kIHRoZSBESVMgaG9wIGxpbWl0 IGlzIG5vdCB5ZXQgcmVhY2hlZCA8bzpwPjwvbzpwPjwvcHJlPjxwcmU+Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGkuIEluaXRpYXRlcyBhIGRpc2NvdmVyeSB0YWJs ZSBlbnRyeSBmb3IgRE9EQUcoRCxGKS4gVGhpcyBlbnRyeSBtYWludGFpbnMgaW5mb3JtYXRpb24g YWJvdXQgdGhlIG5vZGVzIGZyb20gd2hvbSB0aGUgRElTIHdlcmUgcmVjZWl2ZWQuIDxvOnA+PC9v OnA+PC9wcmU+PHByZT4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg aWkuIHNlbmRzIG91dCB0aGUgRElTICh2aWEgbGluay1sb2NhbCBtdWx0aWNhc3Qgd2l0aCB0cmlj a2xlIGNvbnRyb2xsZWQgdGltaW5nKSBmdXJ0aGVyLiA8bzpwPjwvbzpwPjwvcHJlPjxwcmU+Jm5i c3A7Jm5ic3A7Jm5ic3A7IGIuIElmIGl0IGlzIGFscmVhZHkgYSBwYXJ0IG9mIERPREFHKEQsRikg b3IgaXMgbm9kZSBEIGl0c2VsZiA8bzpwPjwvbzpwPjwvcHJlPjxwcmU+Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGkuIFNlbmQgb3V0IGEgRElPIGFib3V0IERPREFH KEQsRikgdG8gdGhlIG5vZGUgZnJvbSB3aG9tIHRoZSBESVMgd2FzIHJlY2VpdmVkLiA8bzpwPjwv bzpwPjwvcHJlPjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT48cHJlPjMuIE9uIHJlY2Vpdmlu ZyBhIERJTyBhYm91dCBET0RBRyhELEYpLCBhIG5vZGUgZG9lcyB0aGUgZm9sbG93aW5nOiA8bzpw PjwvbzpwPjwvcHJlPjxwcmU+Jm5ic3A7Jm5ic3A7Jm5ic3A7IGEuIElnbm9yZSB0aGUgRElPIGlm IHRoZSBub2RlIGRvZXMgbm90IGhhdmUgYSBkaXNjb3ZlcnkgdGFibGUgZW50cnkgZm9yIERPREFH KEQsRikgPG86cD48L286cD48L3ByZT48cHJlPiZuYnNwOyZuYnNwOyZuYnNwOyBiLiBPdGhlcndp c2UsIHRoZSBub2RlIGpvaW5zIHRoZSBET0RBRyhELEYpIChpZiBub3QgYWxyZWFkeSBwYXJ0IG9m IGl0KSBvciB1cGRhdGVzIGl0cyBwYXJlbnQgc2V0IGluIERPREFHKEQsRikgYW5kIHNlbmRzIHRo ZSBESU8gYnkgdW5pY2FzdCB0byB0aGUgbm9kZXMgdGhhdCBoYWQgc2VudCBpdCB0aGUgRElTLiA8 bzpwPjwvbzpwPjwvcHJlPjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT48cHJlPjQuIE9uY2Us IHRoZSBub2RlIGlzIHBhcnQgb2YgdGhlIERPREFHKEQsRiksIGl0IG1haW50YWlucyBhIOKAnHJv dXRpbmcgaW50ZXJlc3TigJ0gZm9yIHRoZSBET0RBRyBpbiB0aGUgZm9sbG93aW5nIG1hbm5lcjog PG86cD48L286cD48L3ByZT48cHJlPiZuYnNwOyZuYnNwOyZuYnNwOyBhLiBSb3V0aW5nIGludGVy ZXN0IGlzIGEgdmFsdWUgYmV0d2VlbiAwIGFuZCAxIDxvOnA+PC9vOnA+PC9wcmU+PHByZT4mbmJz cDsmbmJzcDsmbmJzcDsgYi4gUm91dGluZyBpbnRlcmVzdCBpcyAxIGlmIHRoZSBub2RlIHJlY2Vu dGx5IGZvcndhcmRlZCBhIHBhY2tldCBhbG9uZyB0aGUgRE9EQUcoRCxGKSA8bzpwPjwvbzpwPjwv cHJlPjxwcmU+Jm5ic3A7Jm5ic3A7Jm5ic3A7IGMuIE90aGVyd2lzZSwgdGhlIHJvdXRpbmcgaW50 ZXJlc3QgaXMgeCptYXhpbXVtIHJvdXRpbmcgaW50ZXJlc3Qgb2YgdGhlIG5laWdoYm9ycyBpbiBE T0RBRyhELEYpLCB3aGVyZSB4IGlzIGEgZnJhY3Rpb24uIFRoZSBub2RlIGNvbWVzIHRvIGtub3cg b2YgbmVpZ2hib3LigJlzIHJvdXRpbmcgaW50ZXJlc3QgdmlhIHRoZSBuZWlnaGJvcuKAmXMgRElP LiA8bzpwPjwvbzpwPjwvcHJlPjxwcmU+Jm5ic3A7Jm5ic3A7Jm5ic3A7IGQuIEEgbm9kZSBsZWF2 ZXMgYSBET0RBRyBpZiBpdHMgcm91dGluZyBpbnRlcmVzdCBpbiB0aGUgRE9EQUcgZ29lcyBiZWxv dyBhIHRocmVzaG9sZC4gPG86cD48L286cD48L3ByZT48cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9w cmU+PHByZT5UaGFua3MgPG86cD48L286cD48L3ByZT48cHJlPk11a3VsIDxvOnA+PC9vOnA+PC9w cmU+PHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPjxwcmU+LS0tLS0gT3JpZ2luYWwgTWVzc2Fn ZSAtLS0tLSA8bzpwPjwvbzpwPjwvcHJlPjxwcmU+RnJvbTogJnF1b3Q7UGFzY2FsIFRodWJlcnQg KHB0aHViZXJ0KSZxdW90OyAmbHQ7IDxhIGhyZWY9Im1haWx0bzpwdGh1YmVydEBjaXNjby5jb20i PnB0aHViZXJ0QGNpc2NvLmNvbTwvYT4gJmd0OyA8bzpwPjwvbzpwPjwvcHJlPjxwcmU+VG86ICZx dW90O011a3VsIEdveWFsJnF1b3Q7ICZsdDsgPGEgaHJlZj0ibWFpbHRvOm11a3VsQHV3bS5lZHUi Pm11a3VsQHV3bS5lZHU8L2E+ICZndDsgPG86cD48L286cD48L3ByZT48cHJlPkNjOiAmcXVvdDtS T0xMIFdHJnF1b3Q7ICZsdDsgPGEgaHJlZj0ibWFpbHRvOnJvbGxAaWV0Zi5vcmciPnJvbGxAaWV0 Zi5vcmc8L2E+ICZndDssICZxdW90O1RlZCBIdW1wYWwmcXVvdDsgJmx0OyA8YSBocmVmPSJtYWls dG86VGVkLkh1bXBhbEBqY2kuY29tIj5UZWQuSHVtcGFsQGpjaS5jb208L2E+ICZndDssICZxdW90 O3JvYmVydCBjcmFnaWUmcXVvdDsgJmx0OyA8YSBocmVmPSJtYWlsdG86cm9iZXJ0LmNyYWdpZUBn cmlkbWVyZ2UuY29tIj5yb2JlcnQuY3JhZ2llQGdyaWRtZXJnZS5jb208L2E+ICZndDsgPG86cD48 L286cD48L3ByZT48cHJlPlNlbnQ6IEZyaWRheSwgTWFyY2ggMTksIDIwMTAgMTE6MjA6NTggQU0g R01UIC0wNjowMCBVUy9DYW5hZGEgQ2VudHJhbCA8bzpwPjwvbzpwPjwvcHJlPjxwcmU+U3ViamVj dDogUkU6IFtSb2xsXSBQMlAgcGVyZm9ybWFuY2Ugd2l0aCBjdXJyZW50IFJQTCBwcm9wb3NhbCA8 bzpwPjwvbzpwPjwvcHJlPjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT48cHJlPkhpIE11a3Vs IDxvOnA+PC9vOnA+PC9wcmU+PHByZT7CoMKgPG86cD48L286cD48L3ByZT48YmxvY2txdW90ZSBz dHlsZT0nbWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Jz48cHJlPkhlcmUgSSBo YXZlIGF0dGVtcHRlZCB0byBmb3JtdWxhdGUgYSBzaW1wbGUgRFYgYWxnb3JpdGhtIGluIFJQTC9E QUcgdGVybXMuIDxvOnA+PC9vOnA+PC9wcmU+PHByZT5JIHdpbGwgYXBwcmVjaWF0ZSBpdCBpZiB5 b3UgY291bGQgbGV0IG1lIGtub3cgYWJvdXQgeW91ciBvYmplY3Rpb25zIHRvIHRoaXMgPG86cD48 L286cD48L3ByZT48cHJlPnByb3Bvc2FsOiA8bzpwPjwvbzpwPjwvcHJlPjxwcmU+wqDCoMKgwqA8 bzpwPjwvbzpwPjwvcHJlPjwvYmxvY2txdW90ZT48cHJlPltQYXNjYWxdIEl0J3MgY29vbCB0aGF0 IHlvdSBkbyBpdCBpcyB0aGUgZmlyc3QgaW1wcmVzc2lvbi4gPG86cD48L286cD48L3ByZT48cHJl PjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+PHByZT7CoCA8bzpwPjwvbzpwPjwvcHJlPjxibG9ja3F1 b3RlIHN0eWxlPSdtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQnPjxwcmU+Tm9k ZSBBIG5lZWRzIHRvIHJlYWNoIGEgZGVzdGluYXRpb24gRC4gTm9kZSBBIGluaXRpYXRlcyBhIGRp c2NvdmVyeSBEQUcgPG86cD48L286cD48L3ByZT48cHJlPnRvd2FyZHMgRC4gQXMgdGhlIERJT3Mg cmVhY2ggRCwgaXQgc2VuZHMgYSBEQU8gYmFjayB0byBzZWxlY3RlZCBwYXJlbnRzLiBBcyA8bzpw PjwvbzpwPjwvcHJlPjxwcmU+dGhlIERBTyB0cmF2ZWxzIHRvd2FyZHMgbm9kZSBBLCBpbi1yb3V0 ZSBub2RlcyBzdG9yZSB0aGUgY29zdCB0byByZWFjaCBELiA8bzpwPjwvbzpwPjwvcHJlPjxwcmU+ PG86cD4mbmJzcDs8L286cD48L3ByZT48cHJlPldoZW4gbm9kZSBCIG5lZWRzIHRvIHJlYWNoIEQs IGl0IHNpbWlsYXJseSBpbml0aWF0ZXMgYSBkaXNjb3ZlcnkgZGFnLiBEdXJpbmcgPG86cD48L286 cD48L3ByZT48cHJlPnRoaXMgZGlzY292ZXJ5LCB3aGVuIGEgRElPIHJlYWNoZXMgYSBub2RlIEMg dGhhdCBtYWludGFpbnMgYSBjb3N0IHRvIHJlYWNoIEQsIDxvOnA+PC9vOnA+PC9wcmU+PHByZT5u b2RlIEMgcmVzcG9uZHMgYmFjayB3aXRoIGEgREFPIHRoYXQgdHJhdmVscyB0b3dhcmRzIEIgYW5k IHN0b3JlcyBpbiBpbi0gPG86cD48L286cD48L3ByZT48cHJlPnJvdXRlIG5vZGVzIHRoZSBjb3N0 IHRvIHJlYWNoIEQuIDxvOnA+PC9vOnA+PC9wcmU+PHByZT7CoMKgwqDCoDxvOnA+PC9vOnA+PC9w cmU+PC9ibG9ja3F1b3RlPjxwcmU+W1Bhc2NhbF0mbmJzcDsgdW5kZXJzdGFuZCB0aGF0IHlvdSdy ZSB0cnlpbmcgdG8gbWFrZSBSUEwgZXZlbiBjbG9zZXIgdG8gQU9EVi4gPG86cD48L286cD48L3By ZT48cHJlPkkgYWdyZWUgd2UgbmVlZCB0byBnYXRoZXIgYXMgbXVjaCBhcyB3ZSBjYW4gZnJvbSB0 aGF0IHdvcmsuIDxvOnA+PC9vOnA+PC9wcmU+PHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPjxw cmU+Rm9yIHRoZSBzcGVjaWZpY3Mgb2YgeW91ciBwcm9wb3NhbDogPG86cD48L286cD48L3ByZT48 cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+PHByZT4tIEItQyBtaWdodCBiZSBvcnRob2dvbmFs IHRvIEEtRCBzbyB0aGF0IEIvQ1xEIGZvcm1zIGFuIGFuZ2xlLiBZb3UgZG8gbm90IGVuZCB1cCB3 aXRoIHRoZSBiZXN0IHBhdGggdGhhdCB5b3UncmUgbG9va2luZyBmb3IuIDxvOnA+PC9vOnA+PC9w cmU+PHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPjxwcmU+LSB0aGVyZSBtaWdodCBiZSBtdWx0 aXBsZSBDJ3MuIFdoaWNoIG9uZSBpcyB0aGUgcmlnaHQgb25lPyA8bzpwPjwvbzpwPjwvcHJlPjxw cmU+PG86cD4mbmJzcDs8L286cD48L3ByZT48cHJlPi0gUlBMIGRvZXMgbm90IGFsbG93IHBhY2tl dHMgdG8gc3dpdGNoIGluc3RhbmNlcy4gRm9sbG93aW5nIG11bHRpcGxlIERBR3MgaXMgdGhlIHJl Y2lwZSBmb3IgbG9vcHMgLSB1bmxlc3MgeW91IGhhdmUgdGhlbSBzdHJpY3RseSBvcmRlcmVkIGJ5 IHNvbWUgbWVhbnMgbGlrZSB0aGUgUlBMIHNlcXVlbmNlIGJldHdlZW4gaXRlcmF0aW9ucywgbW9y ZSBzcGVjaWZpYyByb3V0ZXMsIGJsYWggYmxhaC4uLikgPG86cD48L286cD48L3ByZT48cHJlPjxv OnA+Jm5ic3A7PC9vOnA+PC9wcmU+PHByZT4tIHRoZSBBIHRvIEQgcGF0aCBpcyBvcHRpbWl6ZWQg Zm9yIGEgY2VydGFpbiBjb25zdHJhaW50LiBZb3Ugc2VlbSB0byBpbXBseSB0aGF0IHRoZSBCIHRv IEQgcGF0aCBoYXMgdGhlIHNhbWUgY29uc3RyYWludHMgYW5kIG1ldHJpY3Mgc28gd2UgY2FuIGNv bXBhcmUgYXBwbGUgdG8gYXBwbGUuIEJlY2F1c2UgdGhpcyBpcyBhIHZlcnkgZGVsaWNhdGUgb3Bl cmF0aW9uLCBSUEwgaGFzIGludHJvZHVjZWQgdGhlIFJhbmssIHdoaWNoIGhhcyB0aGUgcmlnaHQg cHJvcGVydGllcyB0byBtYWtlIHRoYXQgY29tcGFyaXNvbiBlZmZpY2llbnRseS5TbyBmb3IgUlBM LCB0aGUgbG9vcCBhdm9pZGFuY2UgbWV0cmljIGlzIHRoZSBSYW5rLCBhbmQgaXQgaXMgb25seSB2 YWxpZCB3aXRoaW4gYW4gaXRlcmF0aW9uLiA8bzpwPjwvbzpwPjwvcHJlPjxwcmU+PG86cD4mbmJz cDs8L286cD48L3ByZT48cHJlPi0gQSBQMlAgcGF0aCBkb2VzIG5vdCBjb21lIG91dCBvZiB0aGUg Ymx1ZS4gVGhlcmUgbXVzdCBiZSBzb21lIHByb3Zpc2lvbm5pbmcgc3lzdGVtIHRoYXQgZGV0ZXJt aW5lcyB0aGF0IHRob3NlIG5vZGVzLCBBIGFuZCBCLCBhcmUgdmVyeSBzcGVjaWFsIHNvIHRoZXkg bmVlZCBhIFAyUCBvcHRpbWl6YXRpb24sIHdpdGggYSBnaXZlbiBzcGVjaWFsIE9GLCBhbmQgdGhh dCB0aGV5IGJvdGggbmVlZCB0byB0YWxrIHRvIEQuIFdlbGwsIGlmIHRoYXQncyBzbywgdGhlIG1v c3QgZWNvbm9taWNhbCBpcyBmb3IgdGhhdCBzeXN0ZW0gdG8gZm9yayB0aGUgREFHIG91dCBvZiBE LCB3aXRoIGR1YWwgdGFyZ2V0cyBBIGFuZCBCLiBUaGVyZSB5b3Ugb2J0YWluIHRoZSBzaG9ydGVz dCBwYXRoIGZvciBib3RoIEEtRCBhbmQgQi1EIGZvciB0aGUgY29zdCBvZiBhIHNpbmdsZSBmbG9v ZGluZy4gPG86cD48L286cD48L3ByZT48cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+PHByZT5J IHNlZSB0aGF0IHlvdSdyZSB0cnlpbmcgdG8gZ2V0IHRoZSBpZGVhIHRvIHdvcmsgYmV0dGVyLCBh bmQgSSBob3BlIHdlIGZpbmQgYSB3YXkgdG8gZG8gc28sIG1heWJlIGFsb25nIHlvdXIgbGluZXMg aWYgd2UgY2FuIHNvbHZlIHRoZSBpc3N1ZXMgYWJvdmUuIEJ1dCBiZWZvcmUgd2UgZ2V0IHRoZXJl LCB3ZSBuZWVkIHRvIGFncmVlIHRoYXQgdGhpcyBpcyB0aGUgcGF0aCB3ZSB3aXNoIHRvIHRha2Uu IDxvOnA+PC9vOnA+PC9wcmU+PHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPjxwcmU+Q2hlZXJz LCA8bzpwPjwvbzpwPjwvcHJlPjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT48cHJlPlBhc2Nh bCA8bzpwPjwvbzpwPjwvcHJlPjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT48cHJlPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wcmU+PHByZT7CoCA8bzpwPjwvbzpwPjwvcHJlPjxibG9ja3F1b3RlIHN0 eWxlPSdtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQnPjxwcmU+LS0tLS0gT3Jp Z2luYWwgTWVzc2FnZSAtLS0tLSA8bzpwPjwvbzpwPjwvcHJlPjxwcmU+RnJvbTogJnF1b3Q7UGFz Y2FsIFRodWJlcnQgKHB0aHViZXJ0KSZxdW90OyAmbHQ7IDxhIGhyZWY9Im1haWx0bzpwdGh1YmVy dEBjaXNjby5jb20iPnB0aHViZXJ0QGNpc2NvLmNvbTwvYT4gJmd0OyA8bzpwPjwvbzpwPjwvcHJl PjxwcmU+VG86ICZxdW90O3JvYmVydCBjcmFnaWUmcXVvdDsgJmx0OyA8YSBocmVmPSJtYWlsdG86 cm9iZXJ0LmNyYWdpZUBncmlkbWVyZ2UuY29tIj5yb2JlcnQuY3JhZ2llQGdyaWRtZXJnZS5jb208 L2E+ICZndDsgPG86cD48L286cD48L3ByZT48cHJlPkNjOiAmcXVvdDtST0xMIFdHJnF1b3Q7ICZs dDsgPGEgaHJlZj0ibWFpbHRvOnJvbGxAaWV0Zi5vcmciPnJvbGxAaWV0Zi5vcmc8L2E+ICZndDss ICZxdW90O1RlZCBIdW1wYWwmcXVvdDsgJmx0OyA8YSBocmVmPSJtYWlsdG86VGVkLkh1bXBhbEBq Y2kuY29tIj5UZWQuSHVtcGFsQGpjaS5jb208L2E+ICZndDsgPG86cD48L286cD48L3ByZT48cHJl PlNlbnQ6IFRodXJzZGF5LCBNYXJjaCAxOCwgMjAxMCA5OjIzOjE0IFBNIEdNVCAtMDY6MDAgVVMv Q2FuYWRhIENlbnRyYWwgPG86cD48L286cD48L3ByZT48cHJlPlN1YmplY3Q6IFJlOiBbUm9sbF0g UDJQIHBlcmZvcm1hbmNlIHdpdGggY3VycmVudCBSUEwgcHJvcG9zYWwgPG86cD48L286cD48L3By ZT48cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+PHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJl PjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT48cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+ PHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPjxwcmU+SGkgUm9iZXJ0Jm5ic3A7OiA8bzpwPjwv bzpwPjwvcHJlPjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT48cHJlPjxvOnA+Jm5ic3A7PC9v OnA+PC9wcmU+PHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPjxwcmU+QXQgbGVhc3QgZnJvbSBh IGRpc3RhbmNlLCB0aGUgcHJvcG9zZWQgbWVjaGFuaXNtIGVtdWxhdGVzIEFPRFYsIHdpdGggdGhl IDxvOnA+PC9vOnA+PC9wcmU+PHByZT5ESU8gYXMgUlJFUSBhbmQgdGhlIERBTyBhcyBSUkVQLiBT byBpZiB3ZSBkZWNpZGUgdG8gZGlnIGFsb25nIHRob3NlIGxpbmVzLCA8bzpwPjwvbzpwPjwvcHJl PjxwcmU+d2XigJlsbCBjZXJ0YWlubHkgYXBwcmVjaWF0ZSBoZWxwIGZyb20gTUFORVQgZXhwZXJ0 cy4gSeKAmWQgc2F5IHRoYXQgaWYgeW91IDxvOnA+PC9vOnA+PC9wcmU+PHByZT5hbHJlYWR5IGhh dmUgUlBMIGZvciBQMk1QIGFuZCBNUDJQLCB0aGUgcHJvcG9zZWQgZXh0ZW5zaW9uIGFyZSBwcm9i YWJseSA8bzpwPjwvbzpwPjwvcHJlPjxwcmU+c2ltcGxlciB0byBhZGQgdGhhbiBkb2luZyBBT0RW IGZyb20gc2NyYXRjaC4gPG86cD48L286cD48L3ByZT48cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9w cmU+PHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPjxwcmU+PG86cD4mbmJzcDs8L286cD48L3By ZT48cHJlPkZvciB0aGUgc2V0dXAsIHRoZSBtYWpvciBkaWZmZXJlbmNlcyBhcmUgdGhhdCB3ZSBi dWlsZCBhIERBRyBhbmQgdGhhdCB3ZSBjYW4gPG86cD48L286cD48L3ByZT48cHJlPmluZGljYXRl IG11bHRpcGxlIHRhcmdldHMuIElmIHlvdSBsb29rIGF0IGl0LCB0aGUgREFHIGNhcGFiaWxpdHkg aXMgYSBNVVNUIGZvciA8bzpwPjwvbzpwPjwvcHJlPjxwcmU+UlBMLCBhbmQgSSBoYXZlIG5vdCBz ZWVuIHRoYXQgdGhpcyBNVVNUIGdvZXMgYXdheSBmb3IgUDJQIGZsb3dzLiBUaGUgPG86cD48L286 cD48L3ByZT48cHJlPm11bHRpcGxlIHRhcmdldHMgaXMgc29tZXRoaW5nIHRoYXQgYXBwZWFycyBp biBhIG51bWJlciBvZiB1c2UgY2FzZXMgYW5kIGl0IDxvOnA+PC9vOnA+PC9wcmU+PHByZT5zZWVt cyBtb3JlIGVjb25vbWljYWwgdG8gYnVpbGQgYSBzaW5nbGUgREFHIGZvciBtdWx0aXBsZSB0YXJn ZXRzIHdoZW4gPG86cD48L286cD48L3ByZT48cHJlPnBvc3NpYmxlLiA8bzpwPjwvbzpwPjwvcHJl PjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT48cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+ PHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPjxwcmU+Rm9yIHRoZSBtYWludGVuYW5jZSwgdGhl IG1ham9yIGRpZmZlcmVuY2VzIGFyZSB0aGF0IHdlIGhhdmUgdGhlIERBRyBhcyA8bzpwPjwvbzpw PjwvcHJlPjxwcmU+Zmlyc3QgbGluZSBvZiBkZWZlbnNlLCBhbmQgdGhlIFJQTCBkZXRlY3Rpb24g dG8gc3RpbXVsYXRlIHRoZSBsb2NhbCByZXBhaXIuIDxvOnA+PC9vOnA+PC9wcmU+PHByZT48bzpw PiZuYnNwOzwvbzpwPjwvcHJlPjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT48cHJlPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wcmU+PHByZT5BYm91dCB5b3VyIHF1ZXN0aW9uczogPG86cD48L286cD48 L3ByZT48cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+PHByZT48bzpwPiZuYnNwOzwvbzpwPjwv cHJlPjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT48cHJlPlRoZSBET0RBRyByb290IGlzIHRo ZSBvbmUgdGhhdCBzcGF3bnMgdGhlIERBRy4gVGhlIHRhcmdldHMgY2FuIHJlYWNoIHRoZSA8bzpw PjwvbzpwPjwvcHJlPjxwcmU+cm9vdCBiZWNhdXNlIHRoZSByb290IGFkdmVydGlzZXMgaXRzZWxm IGluIHRoZSBESU8uIFRoZSBpZGVhIGlzIHRoYXQgdGhlIHJvb3QgSUQgPG86cD48L286cD48L3By ZT48cHJlPmlzIHRoZSBhZGRyZXNzIHRoYXQgdGhlIHRhcmdldHMgbmVlZCB0byB0YWxrIHRvLiBJ ZiBuZWVkZWQsIHRoZSByb290IGNhbiBhbHNvIDxvOnA+PC9vOnA+PC9wcmU+PHByZT5hZHZlcnRp c2UgYSBwcmVmaXggdGhhdCBpdCBjYW4gcmVhY2ggYW5kIHRoYXQgdGhlIHRhcmdldHMgbmVlZCB0 byByZWFjaCB0b28uIDxvOnA+PC9vOnA+PC9wcmU+PHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJl PjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT48cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+ PHByZT5BbGwgdGhlIGludGVybWVkaWF0ZSBub2RlcyB0aGF0IGFyZSBjb25maXJtZWQgYnkgdGhl IERBTyBuZWVkIHRvIHJldGFpbiBhdCA8bzpwPjwvbzpwPjwvcHJlPjxwcmU+bGVhc3QgaW5mbyBh Ym91dCB0aGUgREFHLiBUaGF0IGVuYWJsZXMgdGhlIHRhcmdldHMgdG8gcmVhY2ggdGhlIHJvb3Qu IFRoZSA8bzpwPjwvbzpwPjwvcHJlPjxwcmU+Zmxvb2Rpbmcgc2hvdWxkIGNvc3QgYWJvdXQgdGhl IHNhbWUgYXMgdGhhdCBvZiBBT0RWIGJ1dCB0aGUgUlBMIHdheSB3aWxsIDxvOnA+PC9vOnA+PC9w cmU+PHByZT5yZXF1aXJlIG1vcmUgc3RhdGVzIGluIHRoZSBub2RlcyBvbiB0aGUgd2F5IGlmIHRo ZSBPRiByZXF1aXJlcyBhIERBRy4gPG86cD48L286cD48L3ByZT48cHJlPjxvOnA+Jm5ic3A7PC9v OnA+PC9wcmU+PHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPjxwcmU+PG86cD4mbmJzcDs8L286 cD48L3ByZT48cHJlPlRoZSB3YXkgYmFjayAoZG93bikgY2FuIGJlIHN0YXRlZnVsIG9mIHN0YXRl bGVzcywgZGVwZW5kaW5nIG9uIHdoaWNoIERBTyA8bzpwPjwvbzpwPjwvcHJlPjxwcmU+d2XigJly ZSB1c2luZy4gV2l0aCBmdWxseSBzdGF0ZWZ1bCBEQU8sIHdlIGFyZSByZWFsbHkgaW4gQU9EVi1s YW5kLiBXaXRoIDxvOnA+PC9vOnA+PC9wcmU+PHByZT5zdGF0ZWxlc3MsIHdlIGNvdWxkIGRyaWZ0 IGludG8gRFNSLWxhbmQgZm9yIHRoYXQgZGlyZWN0aW9uLiBXaGljaCBsaW1pdHMgd2UgPG86cD48 L286cD48L3ByZT48cHJlPnBsYWNlIHRvIGtlZXAgaXQgc2ltcGxlIHdpbGwgYmUgZGV0ZXJtaW5l ZCBieSB0aGUgcmVzb2x1dGlvbiBvZiBpc3N1ZSAjMjYgSSA8bzpwPjwvbzpwPjwvcHJlPjxwcmU+ Z3Vlc3PigKYgPG86cD48L286cD48L3ByZT48cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+PHBy ZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT48cHJl PkFuZCBwbGVhc2UsIG5vIGFwb2xvZ2l6ZSBvciBvbiBvbmUgd2lsbCBkYXJlIHBvc3QgYW55dGhp bmcgYW55bW9yZS4gWW91ciA8bzpwPjwvbzpwPjwvcHJlPjxwcmU+cXVlc3Rpb25zIGFyZSBmdWxs eSByZWxldmFudCBhbmQgYXQgdGhlIGNvcmUgb2YgdGhlIGRpc2N1c3Npb24uIDxvOnA+PC9vOnA+ PC9wcmU+PHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPjxwcmU+PG86cD4mbmJzcDs8L286cD48 L3ByZT48cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+PHByZT5JIGhvcGUgd2UgY2FuIHRhbGsg aW4gQW5haGVpbSBmb3Igc3VyZSwgPG86cD48L286cD48L3ByZT48cHJlPjxvOnA+Jm5ic3A7PC9v OnA+PC9wcmU+PHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPjxwcmU+PG86cD4mbmJzcDs8L286 cD48L3ByZT48cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+PHByZT5QYXNjYWwgPG86cD48L286 cD48L3ByZT48cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+PHByZT48bzpwPiZuYnNwOzwvbzpw PjwvcHJlPjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT48cHJlPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wcmU+PHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPjxwcmU+PG86cD4mbmJzcDs8L286cD48 L3ByZT48cHJlPkZyb206IFJvYmVydCBDcmFnaWUgWyA8YSBocmVmPSJtYWlsdG86cm9iZXJ0LmNy YWdpZUBncmlkbWVyZ2UuY29tIj5tYWlsdG86cm9iZXJ0LmNyYWdpZUBncmlkbWVyZ2UuY29tPC9h PiBdIDxvOnA+PC9vOnA+PC9wcmU+PHByZT5TZW50OiBNb25kYXksIE1hcmNoIDE1LCAyMDEwIDEx OjI3IEFNIDxvOnA+PC9vOnA+PC9wcmU+PHByZT5UbzogUGFzY2FsIFRodWJlcnQgKHB0aCB1YmVy dCkgPG86cD48L286cD48L3ByZT48cHJlPkNjOiA8YSBocmVmPSJtYWlsdG86VGVkLkh1bXBhbEBq Y2kuY29tIj5UZWQuSHVtcGFsQGpjaS5jb208L2E+IDsgUk9MTCBXRyA8bzpwPjwvbzpwPjwvcHJl PjxwcmU+U3ViamVjdDogUmU6IFtSb2xsXSBQMlAgcGVyZm9ybWFuY2Ugd2l0aCBjdXJyZW50IFJQ TCBwcm9wb3NhbCA8bzpwPjwvbzpwPjwvcHJlPjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT48 cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+PHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPjxw cmU+SGkgUGFzY2FsLCA8bzpwPjwvbzpwPjwvcHJlPjxwcmU+PG86cD4mbmJzcDs8L286cD48L3By ZT48cHJlPlNvIGluIHlvdXIgc2xpZGV3YXJlIFQgY2FuIGVuZCB1cCB0YWxraW5nIHRvIFIgKERP REFHIHJvb3QpIHRocm91Z2ggdGhlIDxvOnA+PC9vOnA+PC9wcmU+PHByZT5ET0RBRy4gU28gYXJl IHlvdSBwcm9wb3NpbmcgdGhhdCBhbGwgcG90ZW50aWFsIHRhcmdldHMgY2FuIGFjdCBhcyBhIERP REFHIDxvOnA+PC9vOnA+PC9wcmU+PHByZT5yb290PyBBbmQgdGhlcmVmb3JlIGFsbCBpbnRlcm1l ZGlhdGVzIGhhdmUgdG8gcmV0YWluIERJTyBwcm9wYWdhdGlvbiA8bzpwPjwvbzpwPjwvcHJlPjxw cmU+c3VwcG9ydCBmb3IgdGhhdCBET0RBRyBhcyB3ZWxsPyBUaGlzIG1heSB3b3JrIGZvciBsaW1p dGVkIFAyUCBidXQgc2VlbXMgPG86cD48L286cD48L3ByZT48cHJlPmxlc3MgZWZmaWNpZW50IHRo YW4gc2ltcGxlIGRpc3RhbmNlIHZlY3RvciBmbG9vZGluZyBSUkVRL1JSRVAgbGlrZSBBT0RWIG9y IDxvOnA+PC9vOnA+PC9wcmU+PHByZT5EWU1PIGZvciBnZW5lcmljIFAyUC4gV2hhdCBhYm91dCBS IHRvIFQgKG9yIGFueW9uZSBlbHNlIGZvciB0aGF0IG1hdHRlcik/IDxvOnA+PC9vOnA+PC9wcmU+ PHByZT5EbyB3ZSBzb3VyY2Ugcm91dGUsIG1haW50YWluIHN0YXRlLCBzb21lIHVuZGVmaW5lZCBo eWJyaWQgb2YgdGhlIHR3bz8gPG86cD48L286cD48L3ByZT48cHJlPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wcmU+PHByZT5JIGFwb2xvZ2lzZSBpZiBzb21lIG9mIHRoZXNlIHF1ZXN0aW9ucyBoYXZlIGJl ZW4gYW5zd2VyZWQgaW4gZGV0YWlsIGluIGVhcmxpZXIgPG86cD48L286cD48L3ByZT48cHJlPnJl ZmxlY3RvciBwb3N0cyBidXQgSSBoYXZlIG9ubHkgcmVjZW50bHkgc3RhcnRlZCB0byBjb25jZW50 cmF0ZSBteSBlZmZvcnRzIG9uIDxvOnA+PC9vOnA+PC9wcmU+PHByZT5SUEwgYW5kIGhhdmUgODIg cGFnZXMgdG8gd2FkZSB0aHJvdWdoIDotKS4gSSBsb29rIGZvcndhcmQgdG8gYSBwcm9kdWN0aXZl IDxvOnA+PC9vOnA+PC9wcmU+PHByZT5zZXNzaW9uIGluIEFuYWhlaW0uIDxvOnA+PC9vOnA+PC9w cmU+PHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPjxwcmU+Um9iZXJ0IDxvOnA+PC9vOnA+PC9w cmU+PHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPjxwcmU+PG86cD4mbmJzcDs8L286cD48L3By ZT48cHJlPlJvYmVydCBDcmFnaWUgKFBhY2lmaWMgR2FzICZhbXA7IEVsZWN0cmljKSA8bzpwPjwv bzpwPjwvcHJlPjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT48cHJlPkdyaWRtZXJnZSBMdGQu IDxvOnA+PC9vOnA+PC9wcmU+PHByZT44OSBHcmVlbmZpZWxkIENyZXNjZW50LCA8bzpwPjwvbzpw PjwvcHJlPjxwcmU+V2FrZWZpZWxkLCBXRjQgNFdBLCBVSyA8bzpwPjwvbzpwPjwvcHJlPjxwcmU+ KzQ0ICgwKSAxOTI0IDkxMDg4OCA8bzpwPjwvbzpwPjwvcHJlPjxwcmU+PGEgaHJlZj0iaHR0cDov L3d3dy5ncmlkbWVyZ2UuY29tIj5odHRwOi8vd3d3LmdyaWRtZXJnZS5jb208L2E+IDxvOnA+PC9v OnA+PC9wcmU+PHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPjxwcmU+PG86cD4mbmJzcDs8L286 cD48L3ByZT48cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+PHByZT5QYXNjYWwgVGh1YmVydCAo cHRodWJlcnQpIHdyb3RlOiA8bzpwPjwvbzpwPjwvcHJlPjxwcmU+PG86cD4mbmJzcDs8L286cD48 L3ByZT48cHJlPkhJIFJvYmVydCZuYnNwOzogPG86cD48L286cD48L3ByZT48cHJlPjxvOnA+Jm5i c3A7PC9vOnA+PC9wcmU+PHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPjxwcmU+PG86cD4mbmJz cDs8L286cD48L3ByZT48cHJlPkkgcmVzcGVjdGZ1bGx5IGhhdmUgdG8gZGlzYWdyZWUuIDxvOnA+ PC9vOnA+PC9wcmU+PHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPjxwcmU+PG86cD4mbmJzcDs8 L286cD48L3ByZT48cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+PHByZT5NeSB1bmRlcnN0YW5k aW5nIGlzIHRoYXQgd2UgYXJlIGNvbnNpZGVyaW5nIGEgbGltaXRlZCBzZXQgb2YgUDJQIHBhaXJz LCBmb3IgPG86cD48L286cD48L3ByZT48cHJlPndoaWNoIHRoZSBzcGVjaWZpYyBwYXRoIHRoYXQg d2UgbmVlZCB0byBjcmVhdGUgbWlnaHQgaGF2ZSB0byBvYmV5IHNwZWNpZmljIDxvOnA+PC9vOnA+ PC9wcmU+PHByZT5jb25zdHJhaW50cy4gPG86cD48L286cD48L3ByZT48cHJlPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wcmU+PHByZT5TbyBpdCBtYWtlcyBzZW5zZSB0byB1c2UgYW4gb24tZGVtYW5kIHRl Y2huaXF1ZSwgcHJvYmFibHkgaW5zcGlyZWQgYnkgdGhlIDxvOnA+PC9vOnA+PC9wcmU+PHByZT5N QU5FVCBSZWFjdGl2ZSBwcm90b2NvbHMuIDxvOnA+PC9vOnA+PC9wcmU+PHByZT48bzpwPiZuYnNw OzwvbzpwPjwvcHJlPjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT48cHJlPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wcmU+PHByZT5BcyBpdCBnb2VzLCB0aG9zZSBwcm90b2NvbHMgdXN1YWxseSB1c2Ug Zmxvb2RpbmcgZm9yIGEgbm9kZSB0byBsb2NhdGUgYW5vdGhlci4gPG86cD48L286cD48L3ByZT48 cHJlPkZvcmtpbmcgYSBEQUcgaXMganVzdCBhbm90aGVyIGZsb29kaW5nLiBJdCBkb2VzIG5vdCB0 YWtlIGEgbG90IG9mIGFkZGl0aW9uIHRvIHRoZSA8bzpwPjwvbzpwPjwvcHJlPjxwcmU+ZXhpc3Rp bmcgRElPIGZvciBhIHJvb3QgdG8gdXNlIFJQTCB0byBidWlsZCBhIERBRyB0aGF0IGNvbnRhaW5z IG9uZSBvciBtdWx0aXBsZSA8bzpwPjwvbzpwPjwvcHJlPjxwcmU+VGFyZ2V0cyBhcyBsZWF2ZXMs IHVuZGVyIGEgc2V0IG9mIGNvbnN0cmFpbnRzIGV4cHJlc3NlZCBhcyBhbiBvYmplY3RpdmUgPG86 cD48L286cD48L3ByZT48cHJlPmZ1bmN0aW9uLiBQbGVhc2UgZmluZCBhdHRhY2hlZCBhIHNsaWRl d2FyZSB0aGF0IGlsbHVzdHJhdGVzIHRoYXQuIDxvOnA+PC9vOnA+PC9wcmU+PHByZT48bzpwPiZu YnNwOzwvbzpwPjwvcHJlPjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT48cHJlPjxvOnA+Jm5i c3A7PC9vOnA+PC9wcmU+PHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPjxwcmU+UGFzY2FsIDxv OnA+PC9vOnA+PC9wcmU+PHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPjxwcmU+PG86cD4mbmJz cDs8L286cD48L3ByZT48cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+PHByZT48bzpwPiZuYnNw OzwvbzpwPjwvcHJlPjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT48cHJlPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wcmU+PHByZT5Gcm9tOiA8YSBocmVmPSJtYWlsdG86cm9sbC1ib3VuY2VzQGlldGYu b3JnIj5yb2xsLWJvdW5jZXNAaWV0Zi5vcmc8L2E+IFsgPGEgaHJlZj0ibWFpbHRvOnJvbGwtYm91 bmNlc0BpZXRmLm9yZyI+bWFpbHRvOnJvbGwtYm91bmNlc0BpZXRmLm9yZzwvYT4gXSBPbiBCZWhh bGYgT2YgPG86cD48L286cD48L3ByZT48cHJlPlJvYmVydCBDcmFnaWUgPG86cD48L286cD48L3By ZT48cHJlPlNlbnQ6IFRodXJzZGF5LCBNYXJjaCAxMSwgMjAxMCAyOjQzIFBNIDxvOnA+PC9vOnA+ PC9wcmU+PHByZT5UbzogPGEgaHJlZj0ibWFpbHRvOlRlZC5IdW1wYWxAamNpLmNvbSI+VGVkLkh1 bXBhbEBqY2kuY29tPC9hPiA8bzpwPjwvbzpwPjwvcHJlPjxwcmU+Q2M6IFJPTEwgV0cgPG86cD48 L286cD48L3ByZT48cHJlPlN1YmplY3Q6IFJlOiBbUm9sbF0gUDJQIHBlcmZvcm1hbmNlIHdpdGgg Y3VycmVudCBSUEwgcHJvcG9zYWwgPG86cD48L286cD48L3ByZT48cHJlPjxvOnA+Jm5ic3A7PC9v OnA+PC9wcmU+PHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPjxwcmU+PG86cD4mbmJzcDs8L286 cD48L3ByZT48cHJlPkkgYWdyZWUgd2l0aCBUZWQncyBjb21tZW50cyBiZWxvdy4gQ3JlYXRpbmcg YSBET0RBRyBmb3IgZXZlcnkgcmVhY2hhYmxlIDxvOnA+PC9vOnA+PC9wcmU+PHByZT5ub2RlIGFz IGEgcm9vdCBzZWVtcyBhIHZlcnkgaW5lZmZpY2llbnQgYXBwcm9hY2ggY29tcGFyZWQgdG8gYWx0 ZXJuYXRpdmUgPG86cD48L286cD48L3ByZT48cHJlPnJvdXRpbmcgYWxnb3JpdGhtcy4gSSBhbSBj b25jZXJuZWQgdGhhdCBSUEwgZG9lcyBub3QgYWN0dWFsbHkgbWVldCB0aGUgPG86cD48L286cD48 L3ByZT48cHJlPm9yaWdpbmFsIHJlcXVpcmVtZW50cyBpbiBJLUQuaWV0Zi1yb2xsLWJ1aWxkaW5n LXJvdXRpbmctcmVxcywgSS1ELmlldGYtcm9sbC1ob21lLSA8bzpwPjwvbzpwPjwvcHJlPjxwcmU+ cm91dGluZy1yZXFzLCBSRkM1NjczIGFuZCBSRkM1NTQ4LiBUaGUgdHJhZmZpYyBwYXR0ZXJuIHJl cXVpcmVtZW50IGZvciBhIDxvOnA+PC9vOnA+PC9wcmU+PHByZT5zaW5rIG5vZGUgZmVhdHVyZXMg cHJvbWluZW50bHkgaW4gb25seSB0d28gb2YgdGhvc2UgZG9jdW1lbnRzLiBFdmVuIGluIHRoaXMg PG86cD48L286cD48L3ByZT48cHJlPmNhc2UsIGFzIFRlZCBwb2ludHMgb3V0LCBjb21tdW5pY2F0 aW9uIGlzIGxpa2VseSB0byBiZSBiaWRpcmVjdGlvbmFsIChlLmcuIGVuZC0gPG86cD48L286cD48 L3ByZT48cHJlPnRvLWVuZCBhY2tzLikgdGhlcmVmb3JlIHRoZSBET0RBRyBhcHByb2FjaCBpcyBm dW5kYW1lbnRhbGx5IGFzeW1tZXRyaWMsIDxvOnA+PC9vOnA+PC9wcmU+PHByZT5lc3BlY2lhbGx5 IGlmIG5vIGludGVybWVkaWF0ZSBzdG9yYWdlIGlzIGFsbG93ZWQgZm9yIGRlc3RpbmF0aW9uIHJv dXRlcyBhbmQgPG86cD48L286cD48L3ByZT48cHJlPnNvdXJjZSByb3V0aW5nIGhhcyB0byBiZSB1 c2VkLiA8bzpwPjwvbzpwPjwvcHJlPjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT48cHJlPkFs c28sIFJQTCBzZWVtcyBoaWdobHkgY29tcGxleCBmb3Igd2hhdCBhcmUgY29uc3RyYWluZWQgbm9k ZXMgaW4gdGVybXMgb2YgPG86cD48L286cD48L3ByZT48cHJlPm1lbW9yeSBhcyB3ZWxsIGFzIHBv d2VyIGFuZCBiYW5kd2lkdGguIFRoZSBSUEwgZHJhZnQgYXMgaXQgc3RhbmRzIGlzIDgyIDxvOnA+ PC9vOnA+PC9wcmU+PHByZT5wYWdlcyBsb25nIGFuZCB0aGF0IGRvZXNuJ3QgaW5jbHVkZSB0ZXh0 IGFib3V0IHRoZSBvYmplY3RpdmUgZnVuY3Rpb24uIDxvOnA+PC9vOnA+PC9wcmU+PHByZT48bzpw PiZuYnNwOzwvbzpwPjwvcHJlPjxwcmU+Um9iZXJ0IDxvOnA+PC9vOnA+PC9wcmU+PHByZT48bzpw PiZuYnNwOzwvbzpwPjwvcHJlPjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT48cHJlPlJvYmVy dCBDcmFnaWUgKFBhY2lmaWMgR2FzICZhbXA7IEVsZWN0cmljKSA8bzpwPjwvbzpwPjwvcHJlPjxw cmU+PG86cD4mbmJzcDs8L286cD48L3ByZT48cHJlPkdyaWRtZXJnZSBMdGQuIDxvOnA+PC9vOnA+ PC9wcmU+PHByZT44OSBHcmVlbmZpZWxkIENyZXNjZW50LCA8bzpwPjwvbzpwPjwvcHJlPjxwcmU+ V2FrZWZpZWxkLCBXRjQgNFdBLCBVSyA8bzpwPjwvbzpwPjwvcHJlPjxwcmU+KzQ0ICgwKSAxOTI0 IDkxMDg4OCA8bzpwPjwvbzpwPjwvcHJlPjxwcmU+PGEgaHJlZj0iaHR0cDovL3d3dy5ncmlkbWVy Z2UuY29tIj5odHRwOi8vd3d3LmdyaWRtZXJnZS5jb208L2E+IDxvOnA+PC9vOnA+PC9wcmU+PHBy ZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT48cHJl PjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+PHByZT48YSBocmVmPSJtYWlsdG86VGVkLkh1bXBhbEBq Y2kuY29tIj5UZWQuSHVtcGFsQGpjaS5jb208L2E+IHdyb3RlOiA8bzpwPjwvbzpwPjwvcHJlPjxw cmU+PG86cD4mbmJzcDs8L286cD48L3ByZT48cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+PHBy ZT5BIGNvbmNlcm4gYWxzbyB3aWxsIGJlIGhvdyBtdWNoIG92ZXJoZWFkIChtZW1vcnkgc3BhY2Up IHdpbGwgYmUgcmVxdWlyZWQgPG86cD48L286cD48L3ByZT48cHJlPmZvciBhIERPREFHIFJvb3Q/ IDxvOnA+PC9vOnA+PC9wcmU+PHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPjxwcmU+YW5kIGJh c2VkIG9uIHRoZSBmaXJzdCBxdWVzdGlvbiBob3cgbWFueSBET0RBRyByb290cyBhIGxhbXAgbWF5 IG5lZWQgdG8gPG86cD48L286cD48L3ByZT48cHJlPmJlIGEgbWVtYmVyIG9mPyA8bzpwPjwvbzpw PjwvcHJlPjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT48cHJlPkZvciBleGFtcGxlIGluIGxp Z2h0aW5nICZuYnNwO2Egc2luZ2xlIGxhbXAgbWF5IGJlIGEgcm9vdCBmb3IgYSBzaW5nbGUgc3dp dGNoICgxIDxvOnA+PC9vOnA+PC9wcmU+PHByZT5ET0RBRyByb290KSwgJm5ic3A7dGhpcyBsYW1w IC8gbHVtaW5haXJlIG1heSBhbHNvIDxvOnA+PC9vOnA+PC9wcmU+PHByZT5iZSBhIG1lbWJlciBv ZiBhbm90aGVyIGdyb3VwIC0gLSAmbmJzcDt3aGljaCBjb3VsZCBiZSBhbGwgbGlnaHRzIG9uIHRo ZSBmbG9vciAoMm5kIDxvOnA+PC9vOnA+PC9wcmU+PHByZT5ET0RBRyByb290KSwgYW5kIGEgdGhp cmQgZ3JvdXAgPG86cD48L286cD48L3ByZT48cHJlPm9mIGFsbCB0aGUgbGlnaHRzIGluIHRoZSBi dWlsZGluZy4gJm5ic3A7VGhlcmUgY2FuIGJlIG1hbnkgbW9yZSBzcGVjaWFsaXR5IGdyb3VwcyA8 bzpwPjwvbzpwPjwvcHJlPjxwcmU+YXNzb2NpYXRlZCBiYXNlZCBvbiB0aGUgYnVpbGRpbmcgY29u ZmlndXJhdGlvbi4gPG86cD48L286cD48L3ByZT48cHJlPkNvbnNpZGVyIGFsc28gZHVyaW5nIHRo ZSBpbnN0YWxsYXRpb24gdGltZSAtIGhvdyB0aGVzZSBET0RBRyByb290cyB3aWxsIGJlIDxvOnA+ PC9vOnA+PC9wcmU+PHByZT5jb25maWd1cmVkPyAmbmJzcDtNdXN0IEkgY29tbWlzc2lvbiBlYWNo IGRldmljZSA8bzpwPjwvbzpwPjwvcHJlPjxwcmU+dG8gdGVsbCBpdCB3aGljaCBET0RBRyBpdCBt dXN0IHVzZSBmb3IgaXRzIE9iamVjdCBGdW5jdGlvbj8gJm5ic3A7SG93IGVhc3kgd2lsbCB0aGlz IDxvOnA+PC9vOnA+PC9wcmU+PHByZT5iZSB0byBjaGFuZ2UgYW5kIGFkZCBpbiBhIG5ldyBET0RB RyByb290IDxvOnA+PC9vOnA+PC9wcmU+PHByZT5mb3IgdGhlIGVuZCB1c2VyIGlmIHRoZSBsaWdo dGluZyBncm91cCBjaGFuZ2VzPz8gPG86cD48L286cD48L3ByZT48cHJlPjxvOnA+Jm5ic3A7PC9v OnA+PC9wcmU+PHByZT5XaXRoIHJlc3BlY3QgdG8gSmVycnkgTWFydG9jY2kncyAtIGNvbW1lcmNp YWwgYnVpbGRpbmcgcmVxdWlyZW1lbnRzIC0gZXZlcnkgPG86cD48L286cD48L3ByZT48cHJlPmRl dmljZSBtYXkgbmVlZCB0byBjb21tdW5pY2F0ZSB0byBhbnkgb3IgPG86cD48L286cD48L3ByZT48 cHJlPmFsbCBvZiB0aGUgZW5kIGRldmljZXMuICZuYnNwO0lmIGVhY2ggZGV2aWNlIG11c3QgZXN0 YWJsaXNoIGEgRE9EQUcgZm9yIHRoZSBvdGhlciA8bzpwPjwvbzpwPjwvcHJlPjxwcmU+NDk5IGRl dmljZXMgaW4gYSA1MDAgbm9kZSBuZXR3b3JrIC0gSG93IG11Y2ggbWVtb3J5IDxvOnA+PC9vOnA+ PC9wcmU+PHByZT5zcGFjZSB3aWxsIHRoaXMgcmVxdWlyZSBmb3IgZWFjaCBlbmQgZGV2aWNlIHRv IG1haW50YWluPyA8bzpwPjwvbzpwPjwvcHJlPjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT48 cHJlPktlZXAgaW4gbWluZCB0aGF0IHRoZSBlbmQgZGV2aWNlcyBhcmUgdmVyeSBsaW1pdGVkIHBy b2Nlc3NvciBhbmQgbWVtb3J5IDxvOnA+PC9vOnA+PC9wcmU+PHByZT53aXNlLiA8bzpwPjwvbzpw PjwvcHJlPjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT48cHJlPk5vdCB0byBtZW50aW9uIGFs bCBvZiB0aGUgbmV0d29yayBtYWludGVuYW5jZSBtZXNzYWdlcyB0aGF0IHdvdWxkIG5lZWQgPG86 cD48L286cD48L3ByZT48cHJlPnRvIGJlIHRyYW5zbWl0dGVkIHRvIG1haW50YWluIGFsbCBvZiB0 aGVzZSBET0RBR3MuIDxvOnA+PC9vOnA+PC9wcmU+PHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJl PjxwcmU+Q29uc2lkZXIgdGhlIHJlY29udmVyZ2VuY2UgdGltZSB3aGVuIG9uZSBkZXZpY2UgaXMg dHVybmVkIG9mZiBhbmQgaXQgd2FzIGluIDxvOnA+PC9vOnA+PC9wcmU+PHByZT50aGUgbWlkZGxl IG9mIHRoZSBtYWpvcml0eSBvZiB0aGUgMTAwKyBET0RBR1M/IDxvOnA+PC9vOnA+PC9wcmU+PHBy ZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPjxwcmU+SW4gbWFueSBsaWdodGluZyBhbmQgYnVpbGRp bmcgYXBwbGljYXRpb24gYW4gYXBwbGljYXRpb24gYWNrbm93bGVkZ2VtZW50IC0gPG86cD48L286 cD48L3ByZT48cHJlPm11c3QgYmUgcmV0dXJuZWQge0JhY2sgZG93biB0aGUgRE9EQUd9IHNvIC4g LiAuIHRoZSA8bzpwPjwvbzpwPjwvcHJlPjxwcmU+cmVxdWlyZW1lbnQgaXMgbm90IGp1c3QgZ2V0 dGluZyB0byB0aGUgUm9vdCAtIGEgcmV0dXJuIHBhdGggbXVzdCBhbHNvIGJlIDxvOnA+PC9vOnA+ PC9wcmU+PHByZT5tYWludGFpbmVkIGFuZCBoYXZlIGEgJm5ic3A7bG93IGxhdGVuY3kgcGF0aC4g PG86cD48L286cD48L3ByZT48cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+PHByZT5UZWQgSHVt cGFsIDxvOnA+PC9vOnA+PC9wcmU+PHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPjxwcmU+PG86 cD4mbmJzcDs8L286cD48L3ByZT48cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+PHByZT48bzpw PiZuYnNwOzwvbzpwPjwvcHJlPjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT48cHJlPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wcmU+PHByZT5Gcm9tOiA8bzpwPjwvbzpwPjwvcHJlPjxwcmU+PG86cD4m bmJzcDs8L286cD48L3ByZT48cHJlPktyaXMgUGlzdGVyICZsdDsgPGEgaHJlZj0ibWFpbHRvOnBp c3RlckBlZWNzLmJlcmtlbGV5LmVkdSI+cGlzdGVyQGVlY3MuYmVya2VsZXkuZWR1PC9hPiAmZ3Q7 IDxvOnA+PC9vOnA+PC9wcmU+PHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPjxwcmU+PG86cD4m bmJzcDs8L286cD48L3ByZT48cHJlPlRvOiA8bzpwPjwvbzpwPjwvcHJlPjxwcmU+PG86cD4mbmJz cDs8L286cD48L3ByZT48cHJlPkFuZGVycyBCcmFuZHQgJmx0OyA8YSBocmVmPSJtYWlsdG86YWJy QHNkZXNpZ25zLmRrIj5hYnJAc2Rlc2lnbnMuZGs8L2E+ICZndDsgPG86cD48L286cD48L3ByZT48 cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+PHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPjxw cmU+Q2M6IDxvOnA+PC9vOnA+PC9wcmU+PHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPjxwcmU+ Uk9MTCBXRyAmbHQ7IDxhIGhyZWY9Im1haWx0bzpyb2xsQGlldGYub3JnIj5yb2xsQGlldGYub3Jn PC9hPiAmZ3Q7IDxvOnA+PC9vOnA+PC9wcmU+PHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPjxw cmU+PG86cD4mbmJzcDs8L286cD48L3ByZT48cHJlPkRhdGU6IDxvOnA+PC9vOnA+PC9wcmU+PHBy ZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPjxwcmU+MDMvMDgvMjAxMCAwMTo0NSBQTSA8bzpwPjwv bzpwPjwvcHJlPjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT48cHJlPjxvOnA+Jm5ic3A7PC9v OnA+PC9wcmU+PHByZT5TdWJqZWN0OiA8bzpwPjwvbzpwPjwvcHJlPjxwcmU+PG86cD4mbmJzcDs8 L286cD48L3ByZT48cHJlPlJlOiBbUm9sbF0gUDJQIHBlcmZvcm1hbmNlIHdpdGggY3VycmVudCBS UEwgcHJvcG9zYWwgPG86cD48L286cD48L3ByZT48cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+ PHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT48 cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+PHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPjxw cmU+PG86cD4mbmJzcDs8L286cD48L3ByZT48cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+PHBy ZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPjxwcmU+QW5kZXJzIC0gaWYgd2UgdGFrZSBKUCdzIHN1 Z2dlc3Rpb24gdG8gbWFrZSBUaGUgTGFtcCBhIERPREFHIHJvb3QsIGFuZCA8bzpwPjwvbzpwPjwv cHJlPjxwcmU+dGFrZSBQaG9lYnVzJyByZWNvbW1lbmRhdGlvbiB0aGF0IHdlIHVzZSBwYXRoIGRp dmVyc2l0eSB0byBpbXByb3ZlIGVuZC0gPG86cD48L286cD48L3ByZT48cHJlPnRvLWVuZCByZWxp YWJpbGl0eSwgZG8geW91IHNlZSBhIGNoYW5jZSBvZiBzdWNjZXNzPyA8bzpwPjwvbzpwPjwvcHJl PjxwcmU+SW4gbXkgZXhwZXJpZW5jZSwgd2l0aCBkaXZlcnNlIHBhdGhzIGFuZCBvcmRlci1taW51 dGVzIHVwZGF0ZXMgeW91IGdldCA8bzpwPjwvbzpwPjwvcHJlPjxwcmU+ZXh0cmVtZWx5IGhpZ2gg cmVsaWFiaWxpdHkuIDxvOnA+PC9vOnA+PC9wcmU+PHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJl PjxwcmU+SSBoYXZlIG5vIGF2ZXJzaW9uIHRvIFRUTC1saW1pdGVkIGZsb29kcyBhcyBhIHBhcnQg b2YgYSBzb2x1dGlvbiBlaXRoZXIuICZuYnNwO0knbSA8bzpwPjwvbzpwPjwvcHJlPjxwcmU+b3Bl biB0byBpZGVhcyBvbiBob3cgdG8gYnJpbmcgdGhvc2UgaW4gYXMgKHByZXN1bWFibHkgaW5mcmVx dWVudGx5IHVzZWQpIDxvOnA+PC9vOnA+PC9wcmU+PHByZT5vcHRpb25zLiA8bzpwPjwvbzpwPjwv cHJlPjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT48cHJlPmtzanAgPG86cD48L286cD48L3By ZT48cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+PHByZT5BbmRlcnMgQnJhbmR0IHdyb3RlOiA8 bzpwPjwvbzpwPjwvcHJlPjxwcmU+SGVsbG8gPG86cD48L286cD48L3ByZT48cHJlPjxvOnA+Jm5i c3A7PC9vOnA+PC9wcmU+PHByZT5JIHdvdWxkIGxpa2UgdG8gcHJvYmUgdGhlIHRlbXBlcmF0dXJl IG9mIHRoZSBXRyBvbiB1c2luZyBEQU9zIHRvIDxvOnA+PC9vOnA+PC9wcmU+PHByZT5zdXBwb3J0 IFAyUC4gPG86cD48L286cD48L3ByZT48cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+PHByZT5U aGUgYnVpbGRpbmcgYW5kIGhvbWUgYXBwbGljYXRpb24gc3BhY2VzIChhbmQgbWF5YmUgb3RoZXJz KSBoYXZlIDxvOnA+PC9vOnA+PC9wcmU+PHByZT5hIGZldyBjbGVhcmx5IGRlZmluZWQgcmVxdWly ZW1lbnRzLiA8bzpwPjwvbzpwPjwvcHJlPjxwcmU+SXQgaXMgbm90IG9idmlvdXMgdG8gbWUgaG93 IHRoZSBjdXJyZW50IFJQTCBwcm9wb3NhbCAoY1JQTHApIGNhbiA8bzpwPjwvbzpwPjwvcHJlPjxw cmU+c2F0aXNmeSB0aG9zZSByZXF1aXJlbWVudHM6IDxvOnA+PC9vOnA+PC9wcmU+PHByZT48bzpw PiZuYnNwOzwvbzpwPjwvcHJlPjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT48cHJlPkluIGJv dGggY2FzZXMgaXQgaXMgdGhlIHdvcnN0IGNhc2Ugc2NlbmFyaW8gdGhhdCBodXJ0czogPG86cD48 L286cD48L3ByZT48cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+PHByZT48bzpwPiZuYnNwOzwv bzpwPjwvcHJlPjxwcmU+UDJQIHJvdXRpbmcgaW5zaWRlIHRoZSBQQU4gPG86cD48L286cD48L3By ZT48cHJlPj09PT09PT09PT09PT09PT09PT09PT09PT09IDxvOnA+PC9vOnA+PC9wcmU+PHByZT5j UlBMcCBoYXMgbm8gd2F5IG9mIHJvdXRpbmcgaW5zaWRlIHRoZSBQQU4gaWYgeW91IG5lZWQgbW9y ZSB0aGFuIDxvOnA+PC9vOnA+PC9wcmU+PHByZT5vbmUgcmVwZWF0ZXIuIGNSUExwIGhhcyB0byBn byBhbGwgdGhlIHdheSB0byB0aGUgdG9wIChtYXliZSA0IGhvcHMgdXApIDxvOnA+PC9vOnA+PC9w cmU+PHByZT5hbmQgZG93biBhZ2FpbiAobWF5YmUgNCBob3BzIGRvd24pIHRvIGdldCBqdXN0IDIg aG9wcyB0byB0aGUgc2lkZS4gPG86cD48L286cD48L3ByZT48cHJlPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wcmU+PHByZT5UaGUgY29uc2VxdWVuY2UgaXMgaGlnaCBsYXRlbmN5IGFuZCBoaWdoIGxldmVs cyBvZiBiYWNrZ3JvdW5kIG5vaXNlIDxvOnA+PC9vOnA+PC9wcmU+PHByZT5mb3Igbm9kZXMganVz dCBvdXRzaWRlIHRoZSBkaXJlY3QgcmFkaW8gcmFuZ2UuIDxvOnA+PC9vOnA+PC9wcmU+PHByZT5B dCB0aGUgc2FtZSB0aW1lIHRoZSByaXNrIG9mIG1lZXRpbmcgYSBmYWlsaW5nIGxpbmsgaXMgNCB0 aW1lcyBoaWdoZXIgPSZndDsgPG86cD48L286cD48L3ByZT48cHJlPmxhdGVuY3kgbWF5IGJlIG11 Y2ggbW9yZSB0aGFuIDQgdGltZXMgbGFyZ2VyLiA8bzpwPjwvbzpwPjwvcHJlPjxwcmU+PG86cD4m bmJzcDs8L286cD48L3ByZT48cHJlPkxhdGVuY3kgbWF5IHNvdW5kIGxpa2UgYSBtaW5vciBpc3N1 ZSBidXQgaXQgYWN0dWFsbHkgdHJhbnNsYXRlcyBkaXJlY3RseSA8bzpwPjwvbzpwPjwvcHJlPjxw cmU+aW50byBsb3dlciBiYXR0ZXJ5IGxpZmV0aW1lLiBJbiB0aGUgYWJvdmUgKHZlcnkgcmVhbGlz dGljKSBleGFtcGxlLCA8bzpwPjwvbzpwPjwvcHJlPjxwcmU+dGhlIGJhdHRlcnkgbGlmZXRpbWUg aXMgcmVkdWNlZCB0byAyNSUgb2Ygd2hhdCBpdCBzaG91bGQgYmUuIDxvOnA+PC9vOnA+PC9wcmU+ PHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPjxwcmU+V2UgaGF2ZSBsb3RzIG9mIGJhdHRlcnkg ZGV2aWNlcyBzZW5kaW5nIGludG8gdGhlIG5ldHdvcms6IDxvOnA+PC9vOnA+PC9wcmU+PHByZT4q IFBJUiBzZW5zb3JzIHR1cm5pbmcgb24gbGlnaHRzIDxvOnA+PC9vOnA+PC9wcmU+PHByZT4qIERv b3IgbG9ja3Mgc2VuZGluZyBhbGFybXMgPG86cD48L286cD48L3ByZT48cHJlPiogRG9vci93aW5k b3cgc2Vuc29ycyBzdGFydGluZyBjaGltZXMgPG86cD48L286cD48L3ByZT48cHJlPiogU21va2Ug c2Vuc29ycyB0cmlnZ2VyaW5nIGFuIGFsYXJtIHN5c3RlbSA8bzpwPjwvbzpwPjwvcHJlPjxwcmU+ PG86cD4mbmJzcDs8L286cD48L3ByZT48cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+PHByZT48 bzpwPiZuYnNwOzwvbzpwPjwvcHJlPjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT48cHJlPlJl c3BvbnNlIHRpbWUgPG86cD48L286cD48L3ByZT48cHJlPj09PT09PT09PT09PT0gPG86cD48L286 cD48L3ByZT48cHJlPlRoZSBsYXRlbmN5IGlzc3VlIGlzIGltcG9ydGFudC4gPG86cD48L286cD48 L3ByZT48cHJlPldoZW4gYSB1c2VyIChyZWFsIGh1bWFuIGJlaW5nKSBwcmVzc2VzIGEgbGlnaHQg YnV0dG9uIHRoZSB1c2VyIGV4cGVjdHMgPG86cD48L286cD48L3ByZT48cHJlPnRoZSBsaWdodCB0 byB0dXJuIG9uLiA8bzpwPjwvbzpwPjwvcHJlPjxwcmU+Y1JQTHAgcHJvcG9zZXMgdGhhdCBub2Rl cyBpbiB0aGUgdHJlZSBwZXJpb2RpY2FsbHkgYWR2ZXJ0aXNlcyB0aGVpciA8bzpwPjwvbzpwPjwv cHJlPjxwcmU+cHJlc2VuY2UgdXNpbmcgREFPcy4gPG86cD48L286cD48L3ByZT48cHJlPlRoZSBw ZXJpb2RpY2l0eSBpcyBhIHJlYWwgYmVhc3Q6IDxvOnA+PC9vOnA+PC9wcmU+PHByZT5UaGFua3Mg dG8gVHJpY2tsZSwgdGhlIHJhdGUgb2YgdXBkYXRlcyBpbiBhIChhcHBhcmVudGx5KSBzdGFibGUg bmV0d29yayA8bzpwPjwvbzpwPjwvcHJlPjxwcmU+aXMgbG93LiBUaGlzIGlzIGdvb2Qgc2luY2Ug aXQgbGVhdmVzIGJhbmR3aWR0aCBmb3IgZGF0YS4gPG86cD48L286cD48L3ByZT48cHJlPkJ1dCBp dCBpcyBub3QgZ29vZCBpZiBleGlzdGluZyByb3V0ZXMgdG8gbXkgbGFtcCBmYWlsIGFuZCBJIGRv IG5vdCBnZXQgPG86cD48L286cD48L3ByZT48cHJlPm5ldyByb3V0ZXMgdG8gbXkgbGFtcCB1bnRp bCBpdCBkZWNpZGVzIHRvIHNlbmQgb3V0IGEgbmV3IERBTy4gPG86cD48L286cD48L3ByZT48cHJl Pk15IHVzZXIgd2lsbCAod2l0aCBhIGdvb2QgcmVhc29uKSBub3QgdG9sZXJhdGUgd2FpdGluZyBm b3IgbWludXRlcyBmb3IgPG86cD48L286cD48L3ByZT48cHJlPnRoZSBsaWdodCB0byB0dXJuIG9u LiA8bzpwPjwvbzpwPjwvcHJlPjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT48cHJlPkkgaGF2 ZSBtZXQgdHdvIGFyZ3VtZW50cyB0byBjb3VudGVyIHRoaXMgY29uY2VybjogPG86cD48L286cD48 L3ByZT48cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+PHByZT5BMTogV2VsbCwgeW91ciBsYW1w IGNhbiBhbHdheXMgc2VuZCBhIERBTyB3aGVuIGl0IGRldGVjdHMgYSBwcm9ibGVtLiA8bzpwPjwv bzpwPjwvcHJlPjxwcmU+Jm5ic3A7IE15IGFuc3dlcjogPG86cD48L286cD48L3ByZT48cHJlPiZu YnNwOyBUcnVlLCBleGNlcHQgdGhhdCBteSBsYW1wIGRvZXMgbm90IGludGVuZCB0byBzZW5kIGFu eXRoaW5nIDxvOnA+PC9vOnA+PC9wcmU+PHByZT4mbmJzcDsgc28gaXQgd2lsbCBuZXZlciBleHBl cmllbmNlIGFueSBwcm9ibGVtcyBmcm9tIGl0cyBzaWRlIG9mIHRoZSBuZXR3b3JrLiA8bzpwPjwv bzpwPjwvcHJlPjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT48cHJlPkEyOiBXZWxsLCB5b3Ug Y2FuIGluY3JlYXNlIHRoZSBEQU8gcmF0ZSB0byBzdWItc2Vjb25kIHVwZGF0ZXMuIDxvOnA+PC9v OnA+PC9wcmU+PHByZT4mbmJzcDsgTXkgYW5zd2VyOiA8bzpwPjwvbzpwPjwvcHJlPjxwcmU+Jm5i c3A7IE9oIG5vLiBJIGdldCBhIHZlcnkgaGlnaCBkZWdyZWUgb2YgbWFuYWdlbWVudCB0cmFmZmlj IHdoaWNoIDxvOnA+PC9vOnA+PC9wcmU+PHByZT4mbmJzcDsgbGltaXRzIG15IGF2YWlsYWJsZSBi YW5kd2lkdGgsIGluY3JlYXNlcyB0aGUgcmlzayBvZiBjb2xsaXNpb25zIGFuZCA8bzpwPjwvbzpw PjwvcHJlPjxwcmU+Jm5ic3A7IGV2ZW4gcnVuIHRoZSByaXNrIG9mIHZpb2xhdGluZyBFVSBsZWdp c2xhdGlvbiByZXF1aXJpbmcgbWUgdG8gb25seSA8bzpwPjwvbzpwPjwvcHJlPjxwcmU+Jm5ic3A7 IHRyYW5zbWl0IGluIGxlc3MgdGhhbiAxJSBvZiB0aGUgdGltZTogPG86cD48L286cD48L3ByZT48 cHJlPiZuYnNwOyA8YSBocmVmPSJodHRwOi8vZm9jdXMudGkuY29tL2xpdC9hbi9zd3JhMDQ4L3N3 cmEwNDgucGRmIj5odHRwOi8vZm9jdXMudGkuY29tL2xpdC9hbi9zd3JhMDQ4L3N3cmEwNDgucGRm PC9hPiA8bzpwPjwvbzpwPjwvcHJlPjxwcmU+Jm5ic3A7ODY4IC0gODY4LjYgTUh6OiAmbHQ7MSUg PG86cD48L286cD48L3ByZT48cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+PHByZT4mbmJzcDsg UmVhY3RpdmVuZXNzIGlzIGhhcmQgdG8gYWNoaWV2ZSB2aWEgcG9sbGluZy4gPG86cD48L286cD48 L3ByZT48cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+PHByZT48bzpwPiZuYnNwOzwvbzpwPjwv cHJlPjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT48cHJlPklmIHlvdSBhZ3JlZSB0aGF0IHRo aXMgc2VlbXMgdG8gYmUgY3JpdGljYWwgaXNzdWVzIHBsZWFzZSByYWlzZSB5b3VyIDxvOnA+PC9v OnA+PC9wcmU+PHByZT52b2ljZSBvbiB0aGUgbGlzdC4gPG86cD48L286cD48L3ByZT48cHJlPjxv OnA+Jm5ic3A7PC9vOnA+PC9wcmU+PHByZT5Hb2luZyBmb3J3YXJkIDxvOnA+PC9vOnA+PC9wcmU+ PHByZT49PT09PT09PT09PT09IDxvOnA+PC9vOnA+PC9wcmU+PHByZT48bzpwPiZuYnNwOzwvbzpw PjwvcHJlPjxwcmU+V2UgbmVlZCBzb21lIHJlYWN0aXZlIG1lY2hhbmlzbSB0byByZWFjaCBsYW1w cyBiZWZvcmUgdGhlIHVzZXIgZGVjaWRlcyA8bzpwPjwvbzpwPjwvcHJlPjxwcmU+dG8gc3VlIG91 ciBjb21wYW5pZXMuIDxvOnA+PC9vOnA+PC9wcmU+PHByZT5TbyBpcyB0aGlzIHBvc3NpYmxlPyBJ IHRoaW5rIHNvLiA8bzpwPjwvbzpwPjwvcHJlPjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT48 cHJlPkV4aXN0aW5nIGNvbW1lcmNpYWwgKG5vbi1JUCkgc29sdXRpb25zIGFyZSBjYXBhYmxlIG9m IHJlLXJvdXRpbmcgcXVpY2tseSA8bzpwPjwvbzpwPjwvcHJlPjxwcmU+aWYgdGhleSByZWFsbHkg aGF2ZSB0by4gPG86cD48L286cD48L3ByZT48cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+PHBy ZT5MZXQgbWUgdHJ5IHNjb3BpbmcgdGhlIHJlcXVpcmVtZW50cyB0byBhIHBvdGVudGlhbCBzb2x1 dGlvbjogPG86cD48L286cD48L3ByZT48cHJlPihubyBkaWZmZXJlbnQgZnJvbSB0aGUgcmVxLiBk b2NzIGZvciBob21lIGFuZCBidWlsZGluZykgPG86cD48L286cD48L3ByZT48cHJlPjxvOnA+Jm5i c3A7PC9vOnA+PC9wcmU+PHByZT4qIFAyUCByb3V0aW5nIGluIGFueSBkaXJlY3Rpb24gaW5kZXBl bmRlbnQgb2YgdGhlIHRyZWUuIDxvOnA+PC9vOnA+PC9wcmU+PHByZT48bzpwPiZuYnNwOzwvbzpw PjwvcHJlPjxwcmU+KiBPbi1kZW1hbmQgUDJQIHJvdXRlIGRpc2NvdmVyeSBpZiByZXF1ZXN0ZWQg YnkgYSByZWFsLXRpbWUgY3JpdGljYWwgYXBwLiA8bzpwPjwvbzpwPjwvcHJlPjxwcmU+Jm5ic3A7 RGF0YSBjb2xsZWN0aW9uIGFwcHMgbWF5IGJlIGFibGUgdG8ganVzdCB3YWl0IGZvciB0aGUgbmV4 dCBEQU8gdXBkYXRlLiA8bzpwPjwvbzpwPjwvcHJlPjxwcmU+PG86cD4mbmJzcDs8L286cD48L3By ZT48cHJlPiogTGltaXRlZCByYW5nZSBvZiBkaXNjb3ZlcnkgbWVjaGFuaXNtOiBtYXggNCByZXBl YXRlcnMuIDxvOnA+PC9vOnA+PC9wcmU+PHByZT4mbmJzcDsgQSBUVEwgZmllbGQgbWF5IGxpbWl0 IHRoZSBzY29wZSBvZiB0aGUgcmVwZWF0ZXJzLiA8bzpwPjwvbzpwPjwvcHJlPjxwcmU+PG86cD4m bmJzcDs8L286cD48L3ByZT48cHJlPiogU3Vib3B0aW1hbCByb3V0aW5nIGFuZCB0cmFmZmljIGJ1 cnN0cyBhcmUgYWNjZXB0ZWQgaW4gZXhjaGFuZ2UgPG86cD48L286cD48L3ByZT48cHJlPiZuYnNw OyBmb3IgcXVpY2sgcm91dGUgcmVwYWlyLiBCdXQgb25seSBhcyBhbiBleGNlcHRpb24uIDxvOnA+ PC9vOnA+PC9wcmU+PHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPjxwcmU+PG86cD4mbmJzcDs8 L286cD48L3ByZT48cHJlPkp1c3QgYXMgYW4gZXhhbXBsZSwgb25lIGV4aXN0aW5nIGhvbWUgY29u dHJvbCB0ZWNobm9sb2d5IHVzZXMgYSA8bzpwPjwvbzpwPjwvcHJlPjxwcmU+KHNvdXJjZSByb3V0 aW5nKSB2YXJpYW50IG9mIEFPRFYgZm9yIHF1aWNrIHJvdXRlIHJlcGFpci4gPG86cD48L286cD48 L3ByZT48cHJlPk5vdGhpbmcgY29tZXMgZm9yIGZyZWUuIFRoZSBwcmljZSBpcyBmbG9vZGluZyAt IGJ1dCBub3QganVzdCBmbG9vZGluZzogPG86cD48L286cD48L3ByZT48cHJlPk1hbmFnZWQgZmxv b2RpbmcgdXNpbmcgYSBkaXN0cmlidXRlZCBhbGdvcml0aG0gcnVubmluZyBpbiBhbGwgPG86cD48 L286cD48L3ByZT48cHJlPnBhcnRpY2lwYXRpbmcgbm9kZXMuIDxvOnA+PC9vOnA+PC9wcmU+PHBy ZT5UaGUgYWxnb3JpdGhtIGRhbXBlbnMgdGhlIGZsb29kaW5nIGluIGEgdGltZSwgdm9sdW1lIGFu ZCByYW5nZSA8bzpwPjwvbzpwPjwvcHJlPjxwcmU+cGVyc3BlY3RpdmUuIDxvOnA+PC9vOnA+PC9w cmU+PHByZT5Tb21lIHNpbWlsYXIgbWVjaGFuaXNtIGNvdWxkIGJlIGJ1aWx0IGludG8gUlBMIGZv ciBxdWljayByb3V0ZSByZXBhaXIuIDxvOnA+PC9vOnA+PC9wcmU+PHByZT48bzpwPiZuYnNwOzwv bzpwPjwvcHJlPjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT48cHJlPklmIGFueW9uZSBoYXZl IGFsdGVybmF0aXZlIHByb3Bvc2FscywgcGxlYXNlIGJyaW5nIGl0IHRvIHRoZSBsaXN0LiA8bzpw PjwvbzpwPjwvcHJlPjxwcmU+Tm93IGlzIHRoZSB0aW1lLiA8bzpwPjwvbzpwPjwvcHJlPjxwcmU+ PG86cD4mbmJzcDs8L286cD48L3ByZT48cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+PHByZT48 bzpwPiZuYnNwOzwvbzpwPjwvcHJlPjxwcmU+VGhhbmtzLCA8bzpwPjwvbzpwPjwvcHJlPjxwcmU+ Jm5ic3A7IEFuZGVycyA8bzpwPjwvbzpwPjwvcHJlPjxwcmU+PG86cD4mbmJzcDs8L286cD48L3By ZT48cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+PHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJl PjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT48cHJlPl9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fIDxvOnA+PC9vOnA+PC9wcmU+PHByZT5Sb2xsIG1haWxp bmcgbGlzdCA8bzpwPjwvbzpwPjwvcHJlPjxwcmU+PGEgaHJlZj0ibWFpbHRvOlJvbGxAaWV0Zi5v cmciPlJvbGxAaWV0Zi5vcmc8L2E+IDxvOnA+PC9vOnA+PC9wcmU+PHByZT48YSBocmVmPSJodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3JvbGwiPmh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vcm9sbDwvYT4gPG86cD48L286cD48L3ByZT48cHJlPiZuYnNw O19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fIDxvOnA+PC9v OnA+PC9wcmU+PHByZT5Sb2xsIG1haWxpbmcgbGlzdCA8bzpwPjwvbzpwPjwvcHJlPjxwcmU+PGEg aHJlZj0ibWFpbHRvOlJvbGxAaWV0Zi5vcmciPlJvbGxAaWV0Zi5vcmc8L2E+IDxvOnA+PC9vOnA+ PC9wcmU+PHByZT48YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L3JvbGwiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcm9sbDwvYT4gPG86 cD48L286cD48L3ByZT48cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+PHByZT48bzpwPiZuYnNw OzwvbzpwPjwvcHJlPjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT48cHJlPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wcmU+PHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPjxwcmU+Jm5ic3A7IF9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fIFJvbGwgbWFpbGluZyA8 bzpwPjwvbzpwPjwvcHJlPjxwcmU+bGlzdCA8YSBocmVmPSJtYWlsdG86Um9sbEBpZXRmLm9yZyI+ Um9sbEBpZXRmLm9yZzwvYT4gPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9yb2xsIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3JvbGw8 L2E+IDxvOnA+PC9vOnA+PC9wcmU+PHByZT5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXyA8bzpwPjwvbzpwPjwvcHJlPjxwcmU+Um9sbCBtYWlsaW5nIGxpc3Qg PG86cD48L286cD48L3ByZT48cHJlPjxhIGhyZWY9Im1haWx0bzpSb2xsQGlldGYub3JnIj5Sb2xs QGlldGYub3JnPC9hPiA8bzpwPjwvbzpwPjwvcHJlPjxwcmU+PGEgaHJlZj0iaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9yb2xsIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL3JvbGw8L2E+IDxvOnA+PC9vOnA+PC9wcmU+PHByZT7CoMKgwqDCoDxvOnA+ PC9vOnA+PC9wcmU+PC9ibG9ja3F1b3RlPjxwcmU+X19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18gPG86cD48L286cD48L3ByZT48cHJlPlJvbGwgbWFpbGluZyBs aXN0IDxvOnA+PC9vOnA+PC9wcmU+PHByZT48YSBocmVmPSJtYWlsdG86Um9sbEBpZXRmLm9yZyI+ Um9sbEBpZXRmLm9yZzwvYT4gPG86cD48L286cD48L3ByZT48cHJlPjxhIGhyZWY9Imh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcm9sbCI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9yb2xsPC9hPiA8bzpwPjwvbzpwPjwvcHJlPjxwcmU+PG86cD4mbmJz cDs8L286cD48L3ByZT48cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+PHByZT5fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXyA8bzpwPjwvbzpwPjwvcHJlPjxw cmU+Um9sbCBtYWlsaW5nIGxpc3QgPG86cD48L286cD48L3ByZT48cHJlPjxhIGhyZWY9Im1haWx0 bzpSb2xsQGlldGYub3JnIj5Sb2xsQGlldGYub3JnPC9hPiA8bzpwPjwvbzpwPjwvcHJlPjxwcmU+ PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9yb2xsIj5odHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3JvbGw8L2E+IDxvOnA+PC9vOnA+PC9w cmU+PHByZT5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxv OnA+PC9vOnA+PC9wcmU+PHByZT5Sb2xsIG1haWxpbmcgbGlzdDxvOnA+PC9vOnA+PC9wcmU+PHBy ZT48YSBocmVmPSJtYWlsdG86Um9sbEBpZXRmLm9yZyI+Um9sbEBpZXRmLm9yZzwvYT48bzpwPjwv bzpwPjwvcHJlPjxwcmU+PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9yb2xsIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3JvbGw8L2E+ PG86cD48L286cD48L3ByZT48cHJlPsKgIDxvOnA+PC9vOnA+PC9wcmU+PC9kaXY+PC9kaXY+PC9i b2R5PjwvaHRtbD4= ------_=_NextPart_001_01CACAFC.9831DB45-- From christophe.dugas@free.fr Wed Mar 24 01:00: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 6168E3A6C72; Wed, 24 Mar 2010 01:00:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.531 X-Spam-Level: *** X-Spam-Status: No, score=3.531 tagged_above=-999 required=5 tests=[BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, J_CHICKENPOX_32=0.6, MSGID_MULTIPLE_AT=1.449] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4DC4ZDqdMZP8; Wed, 24 Mar 2010 01:00:37 -0700 (PDT) Received: from smtp21.services.sfr.fr (smtp21.services.sfr.fr [93.17.128.1]) by core3.amsl.com (Postfix) with ESMTP id AD56D3A6AB3; Wed, 24 Mar 2010 01:00:36 -0700 (PDT) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2104.sfr.fr (SMTP Server) with ESMTP id 6482870000A7; Wed, 24 Mar 2010 09:00:56 +0100 (CET) Received: from CDS (35.226.98-84.rev.gaoland.net [84.98.226.35]) by msfrf2104.sfr.fr (SMTP Server) with ESMTP id C292D70000A5; Wed, 24 Mar 2010 09:00:55 +0100 (CET) X-SFR-UUID: 20100324080055797.C292D70000A5@msfrf2104.sfr.fr From: "CDS" To: Cc: References: <6A2A459175DABE4BB11DE2026AA50A5D0180D60F@XMB-AMS-107.cisco.com> In-Reply-To: Date: Wed, 24 Mar 2010 09:00:59 +0100 Message-ID: <00bc01cacb28$2408fe60$6c1afb20$@dugas@free.fr> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00BD_01CACB30.85CD6660" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcrJmMwayKxTTvSbSl2jUUFo5VlqIgBjjlyA Content-Language: fr Subject: Re: [Roll] Options in DIS X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 24 Mar 2010 08:00:39 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_00BD_01CACB30.85CD6660 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Dominique, =20 I fully support this proposal that contributes to power savings in self-routing algorithms. =20 Best regards =20 Christophe On Sun, Mar 21, 2010 at 6:40 PM, Pascal Thubert (pthubert) wrote: Hi Dominique: I'd add that it can be interesting for a node to specify what it is looking for, like the instance that it belongs to and for which it is searching for a parent. Yes, you have my support to make this a ticket. Pascal > -----Original Message----- > From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of > dominique.barthel@orange-ftgroup.com > Sent: Friday, March 19, 2010 10:45 AM > To: roll@ietf.org > Subject: [Roll] Options in DIS > > Hi all, > > I have already expressed a desire for options in the DIS packet > http://www.ietf.org/mail-archive/web/roll/current/msg02765.html > Jerry and Mukul expressed their support to the request. > http://www.ietf.org/mail-archive/web/roll/current/msg02766.html > http://www.ietf.org/mail-archive/web/roll/current/msg02770.html > > Then Phil asked for a justification for the request, which I admit I > haven't provided yet. > http://www.ietf.org/mail-archive/web/roll/current/msg02774.html > > More recently, Tzeta suggested that DIS have security options > http://www.ietf.org/mail-archive/web/roll/current/msg03101.html > > Independently, Yaov and Matteo both again expressed the need for DIS > option. > http://www.ietf.org/mail-archive/web/roll/current/msg03185.html > http://www.ietf.org/mail-archive/web/roll/current/msg03290.html > > I do believe we have a serious point here. > Please find the justification below. > Can we please have a ticket to work on it ? > I volunteer to gather others contributors' opinions/requests and and > propose detailed text to be included in future revisions of the RPL > draft. > Best, > > Dominique > > ------------------------------------------- > The following is extracted from a typical water/gas smart metering > infrastructure. > The utility company worker adds new metering points into the network as > meters are replaced or fitted with sensing/transmission electronics. > Before the worker leaves the premises, he/she is requested to check that > the meter has actually joined the network. > This cannot wait for a trickled-down DAO to arrive. > Therefore, the meter will send a DIS to collect information from the > network. > Without DIS options, all neighbor routers will respond, spending energy > for their own transmission and triggering energy expenditure in all > neighbor nodes that overhear the responses. > > Let's consider a "wheel" model for the network topology, with a sink at > the center and spokes connecting outward to ring-1 routers, ring-2 > routers and periphery meters. The meters have routing capability > themselves, although I'll call them meters in the following text to > distinguish them from devices solely intended at providing connectivity, > which I'll call routers. > Let's consider a generic "pizza slice" of this wheel. Since there's > central symmetry in the network, there's no border effect in the slice > We typically have > - one mains-powered sink at the center, > - N severely energy-limited meters at the periphery, deeply burried into > basements or manholes > - N/20 fairly energy-limited ring-1 routers, located on high spots > - N/10 fairly energy-limited ring-2 routers, located on high spots > In RPL parlance, ring-1 routers would have a typical rank of 4, and > ring-2 routers would have a typical rank of 8 > The N/10 and N/20 ratios above are dictated by energy/lifetime > considerations, not radio coverage. > A typical connectivity is the following > - each meter is in range of N/10 and N/20 routers, albeit with *very* > different link qualities > - each router is in range of N/10 and N/20 routers, with various link > qualities > - each meter is in range of N/20 meters > The ratios and assumptions above hold for values of N in the [20..200] > range. > > **** Without DIS options, we have > NT0 =3D Number of DIS multicast transmission =3D 1 > NR0 =3D Number of DIS active receptions =3D N/5 (due to N/20 meters = and > (N/10+N/20) routeurs), > NT1 =3D N/20 DIO transmissions from meters; each one being overheard = by > N/20 meters and (N/10+N/20) routers > NT2 =3D N/10+N/20 DIO transmissions from routers; each one being overheard > by N meters and (N/10+N/20) routers > NR1 ~=3D NT1 * (3N/20 + N/20) =3D N^2/100 =3D 0.01 * N^2 receptions = due to DIO > coming from meters > NR2 ~=3D NT2 * (N + N/20 + N/10) =3D N^2*69/400 =3D 0.17 * N^2 = receptions due > to DIO coming from routers > > We therefore have > Number of transmissions: NT =3D NT0 + NT1 + NT2 =3D 1 + N/20 + (N/10 + N/20) > =3D 24/20 * N =3D 1 + 0.2 * N > Number of receptions : NR =3D NR0 + NR1 + NR2 =3D 0.2 * N + 0.18 * = N^2 > > Total energy cost Etotal =3D NT * Et + NR * Er > > If the network is asynchronous and uses basic preamble sampling, the > cost of overhearing Eo is the cost of receiving the expected duration > (half) of the preamble. > Since the DIS packet is small, its unit reception cost Er is about the > same as the overhearing cost Eo. > With a small (<1KB) DIO packet, the cost of transmission Et is > essentially the cost of sending the preamble. > Let's assume transmission cost Et is 6 times Eo (full preamble length > accounts for x2, power consumption for x3) > > Etotal ~=3D Eo * ( 1 * 6 + N * (0.2 * 6 + 0.2) + 0.18 * N^2) ~=3D Eo * = ( 6 + > 1.4 * N + 0.18 * N^2) > > **** With DIS options > A typical protocol currently in use in widely deployed proprietary smart > metering networks is the following. > Newborn nodes send successive DIS'es with decreasing demands on rank > and > link quality > - iteration 1: only sinks, LQI >=3D 0,75*maxLQI > - iteration 2: only sinks, LQI >=3D 0,5*maxLQI > - iteration 3: only sinks, LQI >=3D 0,25*maxLQI > - iteration 4: ring-1 routers, LQI >=3D 0,75*maxLQI, > - iteration 5: ring-1 routers, LQI >=3D 0,50*maxLQI, > - iteration 6: ring-1 routers, LQI >=3D 0,25*maxLQI, > - iteration 7: ring-2 routers, LQI >=3D 0,75*maxLQI, > - iteration 8: ring-2 routers, LQI >=3D 0,50*maxLQI, > - iteration 9: ring-2 routers, LQI >=3D 0,25*maxLQI, > - etc > The newborn node will usually send several DIS's instead of just one. > Its direct neighbors (N/20 meters, N/10+N/20 routers) will also incur > the cost of receiving these extra DIS'es. > Let's suppose iteration 7 is successful and prompts 25% of the neighbor > ring-2 routers to send their DIOs. > Number of DIS transmissions =3D 7 > Number of DIS receptions =3D 7 * (N/20 + N/10 + N/20) =3D 7/5 * N > Number of DIO transmissions =3D 25% of N/10 =3D N/40, overheard by = 23/20 * N > nodes (N meters and N/10+N/20 routers). > Number of DIOs overheard =3D 23/800 * N^2 =3D 0.029 * N^2 > Etotal ~=3D Eo * ( 7*6 + N * ( 7/5 + 6/40) + 0.029 * N^2) ~=3D Eo * = (42 + > 1.6 * N + 0.029 * N^2) > > In this case, the global energy cost of inserting a new node in the > network is reduced by a factor ranging from 2 to 5 depending on N in > [20..200]. Additional analysis shows that this saving affect both meters > and routers (specifically, we are not pushing the burden towards the > energy-critical meters). > Similar results are obtained with differents iterations numbers. > > Just to re-inforce this calculation, it has been our experience that > node insertion into a dense low-power network, if done wrong, is a > significant energy drain. Please let us enhance RPL to do it right. > _______________________________________________ > Roll mailing 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 Ce message entrant est certifi=E9 sans virus connu. Analyse effectu=E9e par AVG - www.avg.fr Version: 8.5.437 / Base de donn=E9es virale: 271.1.1/2762 - Date: = 03/21/10 19:33:00 ------=_NextPart_000_00BD_01CACB30.85CD6660 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi = Dominique,

 

I fully = support this proposal that contributes to power savings in self-routing = algorithms.

 

Best = regards

 

Christophe

On Sun, Mar 21, 2010 at 6:40 PM, Pascal Thubert = (pthubert) <pthubert@cisco.com> = wrote:

Hi Dominique:

I'd add that it can be interesting for a node to specify what it is
looking for, like the instance that it belongs to and for which it = is
searching for a parent.

Yes, you have my support to make this a ticket.

Pascal



> -----Original Message-----
> From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf
Of
> dominique.barthel@or= ange-ftgroup.com
> Sent: Friday, March 19, 2010 10:45 AM
> To: roll@ietf.org
> Subject: [Roll] Options in DIS
>
> Hi all,
>
> I have already expressed a desire for options in the DIS packet
> http://www.ietf.org/mail-archive/web/roll/current/msg02= 765.html
> Jerry and Mukul expressed their support to the request.
> http://www.ietf.org/mail-archive/web/roll/current/msg02= 766.html
> http://www.ietf.org/mail-archive/web/roll/current/msg02= 770.html
>
> Then Phil asked for a justification for the request, which I admit = I
> haven't provided yet.
> http://www.ietf.org/mail-archive/web/roll/current/msg02= 774.html
>
> More recently, Tzeta suggested that DIS have security options
> http://www.ietf.org/mail-archive/web/roll/current/msg03= 101.html
>
> Independently, Yaov and Matteo both again expressed the need for = DIS
> option.
> http://www.ietf.org/mail-archive/web/roll/current/msg03= 185.html
> http://www.ietf.org/mail-archive/web/roll/current/msg03= 290.html
>
> I do believe we have a serious point here.
> Please find the justification below.
> Can we please have a ticket to work on it ?
> I volunteer to gather others contributors' opinions/requests and = and
> propose detailed text to be included in future revisions of the = RPL
> draft.
> Best,
>
> Dominique
>
> -------------------------------------------
> The following is extracted from a typical water/gas smart = metering
> infrastructure.
> The utility company worker adds new metering points into the = network
as
> meters are replaced or fitted with sensing/transmission =  electronics.
> Before the worker leaves the premises, he/she is requested to = check
that
> the meter has actually joined the network.
> This cannot wait for a trickled-down DAO to arrive.
> Therefore, the meter will send a DIS to collect information from = the
> network.
> Without DIS options, all neighbor routers will respond, = spending
energy
> for their own transmission and triggering energy expenditure in =  all
> neighbor nodes that overhear the responses.
>
> Let's consider a "wheel" model for the network topology, = with a sink
at
> the center and spokes connecting outward to ring-1 routers, = ring-2
> routers and periphery meters. The meters have routing = capability
> themselves, although I'll call them meters in the following text = to
> distinguish them from devices solely intended at providing
connectivity,
> which I'll call routers.
> Let's consider a generic "pizza slice" of this wheel. = Since there's
> central symmetry in the network, there's no border effect in the = slice
> We typically have
> - one mains-powered sink at the center,
> - N severely energy-limited meters at the periphery, deeply = burried
into
> basements or manholes
> - N/20 fairly energy-limited ring-1 routers, located on high = spots
> - N/10 fairly energy-limited ring-2 routers, located on high = spots
> In RPL parlance, ring-1 routers would have a typical rank of 4, = and
> ring-2 routers would have a typical rank of 8
> The N/10 and N/20 ratios above are dictated by energy/lifetime
> considerations, not radio coverage.
> A typical connectivity is the following
> - each meter is in range of N/10 and N/20 routers, albeit with = *very*
> different link qualities
> - each router is in range of N/10 and N/20 routers, with various = link
> qualities
> - each meter is in range of N/20 meters
> The ratios and assumptions above hold for values of N in the = [20..200]
> range.
>
> **** Without DIS options, we have
> NT0 =3D Number of DIS multicast transmission =3D 1
> NR0 =3D Number of DIS active receptions =3D N/5 (due to N/20 meters = and
> (N/10+N/20) routeurs),
> NT1 =3D N/20 DIO transmissions from meters; each one being = overheard by
> N/20 meters and (N/10+N/20) routers
> NT2 =3D N/10+N/20 DIO transmissions from routers; each one = being
overheard
> by N meters and (N/10+N/20) routers
> NR1 ~=3D NT1 * (3N/20 + N/20) =3D N^2/100 =3D 0.01 * N^2 receptions = due to
DIO
> coming from meters
> NR2 ~=3D NT2 * (N + N/20 + N/10) =3D N^2*69/400 =3D 0.17 * N^2 = receptions
due
> to DIO coming from routers
>
> We therefore have
> Number of transmissions: NT =3D NT0 + NT1 + NT2 =3D 1 + N/20 + = (N/10 +
N/20)
> =3D 24/20 * N =3D 1 + 0.2 * N
> Number of receptions   : NR =3D NR0 + NR1 + NR2 =3D 0.2 * N + = 0.18 * N^2
>
> Total energy cost Etotal =3D NT * Et + NR * Er
>
> If the network is asynchronous and uses basic preamble sampling, = the
> cost of overhearing Eo is the cost of receiving the expected = duration
> (half) of the preamble.
> Since the DIS packet is small, its unit reception cost Er is about = the
> same as the overhearing cost Eo.
> With a small (<1KB) DIO packet, the cost of transmission Et = is
> essentially the cost of sending the preamble.
> Let's assume transmission cost Et is 6 times Eo (full preamble = length
> accounts for x2, power consumption for x3)
>
> Etotal ~=3D Eo * ( 1 * 6 + N * (0.2 * 6 + 0.2) + 0.18 * N^2) ~=3D = Eo * ( 6
+
> 1.4 * N + 0.18 * N^2)
>
> **** With DIS options
> A typical protocol currently in use in widely deployed = proprietary
smart
> metering networks is the following.
> Newborn nodes send successive DIS'es with decreasing demands on = rank
> and
> link quality
> - iteration 1: only sinks, LQI >=3D 0,75*maxLQI
> - iteration 2: only sinks, LQI >=3D 0,5*maxLQI
> - iteration 3: only sinks, LQI >=3D 0,25*maxLQI
> - iteration 4: ring-1 routers, LQI >=3D 0,75*maxLQI,
> - iteration 5: ring-1 routers, LQI >=3D 0,50*maxLQI,
> - iteration 6: ring-1 routers, LQI >=3D 0,25*maxLQI,
> - iteration 7: ring-2 routers, LQI >=3D 0,75*maxLQI,
> - iteration 8: ring-2 routers, LQI >=3D 0,50*maxLQI,
> - iteration 9: ring-2 routers, LQI >=3D 0,25*maxLQI,
> - etc
> The newborn node will usually send several DIS's instead of just = one.
> Its direct neighbors (N/20 meters, N/10+N/20 routers) will also = incur
> the cost of receiving these extra DIS'es.
> Let's suppose iteration 7 is successful and prompts 25% of the
neighbor
> ring-2 routers to send their DIOs.
> Number of DIS transmissions =3D 7
> Number of DIS receptions =3D 7 * (N/20 + N/10 + N/20) =3D 7/5 * = N
> Number of DIO transmissions =3D 25% of N/10 =3D N/40, overheard by = 23/20 *
N
> nodes (N meters and N/10+N/20 routers).
> Number of DIOs overheard =3D 23/800 * N^2 =3D 0.029 * N^2
> Etotal ~=3D Eo * ( 7*6 + N * ( 7/5 + 6/40) + 0.029 * N^2) ~=3D Eo * = (42 +
> 1.6 * N + 0.029 * N^2)
>
> In this case, the global energy cost of inserting a new node in = the
> network is reduced by a factor ranging from 2 to 5 depending on N = in
> [20..200]. Additional analysis shows that this saving affect = both
meters
> and routers (specifically, we are not pushing the burden towards = the
> energy-critical meters).
> Similar results are obtained with differents iterations = numbers.
>
> Just to re-inforce this calculation, it has been our experience = that
> node insertion into a dense low-power network, if done wrong, is = a
> significant energy drain. Please let us enhance RPL to do it = right.
> _______________________________________________
> Roll mailing list
> Roll@ietf.org
> https://www.ietf.org/mailman/listinfo/roll
_______________________________________________
Roll mailing list
Roll@ietf.org
https://www.ietf.org/mailman/listinfo/roll

 

Ce = message entrant est certifi=E9 sans virus connu.
Analyse effectu=E9e par AVG - www.avg.fr
Version: 8.5.437 / Base de donn=E9es virale: 271.1.1/2762 - Date: = 03/21/10 19:33:00

------=_NextPart_000_00BD_01CACB30.85CD6660-- From trac@tools.ietf.org Wed Mar 24 22:17: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 174F03A6935 for ; Wed, 24 Mar 2010 22:17:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.669 X-Spam-Level: X-Spam-Status: No, score=-100.669 tagged_above=-999 required=5 tests=[AWL=0.800, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, NORMAL_HTTP_TO_IP=0.001, 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 CgzH+QeGMBvM for ; Wed, 24 Mar 2010 22:17:29 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 4B9D93A6921 for ; Wed, 24 Mar 2010 22:17:29 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1NufS1-0008IV-Fy; Wed, 24 Mar 2010 22:17:49 -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: wintert@acm.org, jpv@cisco.com X-Trac-Project: roll Date: Thu, 25 Mar 2010 05:17:49 -0000 X-URL: http://tools.ietf.org/wg/roll/ X-Trac-Ticket-URL: http://64.170.98.42/wg/roll/trac/ticket/28 Message-ID: <055.c8b369fc6d851e8e67a30bbedc694225@tools.ietf.org> X-Trac-Ticket-ID: 28 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: wintert@acm.org, 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] #28: Remove the Trickle Section from RPL specification 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, 25 Mar 2010 05:17:36 -0000 X-List-Received-Date: Thu, 25 Mar 2010 05:17:36 -0000 #28: Remove the Trickle Section from RPL specification --------------------------------+------------------------------------------- Reporter: jpv@… | Owner: wintert@… Type: task | Status: new Priority: major | Milestone: Component: rpl | Version: Severity: Active WG Document | Keywords: --------------------------------+------------------------------------------- and refer to draft-ietf-roll-tickle as a normative reference -- Ticket URL: roll From jpv@cisco.com Thu Mar 25 19:54: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 35B353A67F8 for ; Thu, 25 Mar 2010 19:54:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.4 X-Spam-Level: X-Spam-Status: No, score=-8.4 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DATE_IN_PAST_06_12=1.069, 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 ZafJO4MRYctc for ; Thu, 25 Mar 2010 19:54:31 -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 8B3F53A67A2 for ; Thu, 25 Mar 2010 19:54:31 -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: AqoFAB6/q0tAaHte/2dsb2JhbAAvmntzpSuZE4R9BIMe X-IronPort-AV: E=Sophos;i="4.51,311,1267401600"; d="scan'208";a="106009289" Received: from hkg-core-1.cisco.com ([64.104.123.94]) by sj-iport-4.cisco.com with ESMTP; 26 Mar 2010 02:54:53 +0000 Received: from xbh-hkg-411.apac.cisco.com (xbh-hkg-411.cisco.com [64.104.123.72]) by hkg-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o2Q2sror001723 for ; Fri, 26 Mar 2010 02:54:53 GMT Received: from xfe-hkg-411.apac.cisco.com ([64.104.123.70]) by xbh-hkg-411.apac.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 26 Mar 2010 10:54:53 +0800 Received: from dhcp-wireless-open-abg-26-235.meeting.ietf.org ([10.21.83.247]) by xfe-hkg-411.apac.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 26 Mar 2010 10:54:52 +0800 Message-Id: <54B8E8AD-579C-4B04-A034-003D9D45622B@cisco.com> From: JP Vasseur To: "Mathilde Durvy (mdurvy)" 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, 25 Mar 2010 09:51:13 -0700 X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 26 Mar 2010 02:54:53.0096 (UTC) FILETIME=[B5806280:01CACC8F] Cc: ROLL WG Subject: [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: Fri, 26 Mar 2010 02:54:32 -0000 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 jpv@cisco.com Thu Mar 25 19:54: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 3D9CE3A67F8 for ; Thu, 25 Mar 2010 19:54:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.4 X-Spam-Level: X-Spam-Status: No, score=-8.4 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DATE_IN_PAST_06_12=1.069, 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 LIeXRnjeRXv0 for ; Thu, 25 Mar 2010 19:54:59 -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 279243A67A2 for ; Thu, 25 Mar 2010 19:54:59 -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: AvsEAGu+q0tAaHte/2dsb2JhbACbKnOlNZkThH0Egx4 X-IronPort-AV: E=Sophos;i="4.51,311,1267401600"; d="scan'208";a="172630632" Received: from hkg-core-1.cisco.com ([64.104.123.94]) by sj-iport-5.cisco.com with ESMTP; 26 Mar 2010 02:55:21 +0000 Received: from xbh-hkg-412.apac.cisco.com (xbh-hkg-412.cisco.com [64.104.123.69]) by hkg-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o2Q2tLEe001870 for ; Fri, 26 Mar 2010 02:55:21 GMT Received: from xfe-hkg-411.apac.cisco.com ([64.104.123.70]) by xbh-hkg-412.apac.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 26 Mar 2010 10:55:20 +0800 Received: from dhcp-wireless-open-abg-26-235.meeting.ietf.org ([10.21.83.247]) by xfe-hkg-411.apac.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 26 Mar 2010 10:55:20 +0800 Message-Id: From: JP Vasseur To: "Mathilde Durvy (mdurvy)" 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, 25 Mar 2010 19:54:49 -0700 X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 26 Mar 2010 02:55:20.0658 (UTC) FILETIME=[C5EE0320:01CACC8F] Cc: ROLL WG Subject: [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: Fri, 26 Mar 2010 02:54:59 -0000 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 ietf@thomasclausen.org Thu Mar 25 22:42: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 A19C23A697E for ; Thu, 25 Mar 2010 22:42:16 -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 Ur-5Lq9v-bIF for ; Thu, 25 Mar 2010 22:42:16 -0700 (PDT) Received: from hgblob.mail.tigertech.net (hgblob.mail.tigertech.net [64.62.209.71]) by core3.amsl.com (Postfix) with ESMTP id 2E0EA3A6955 for ; Thu, 25 Mar 2010 22:42:16 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hgblob.tigertech.net (Postfix) with ESMTP id 82BCE32358B8; Thu, 25 Mar 2010 22:42:39 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from dhcp-wireless-open-abg-27-86.meeting.ietf.org (dhcp-wireless-open-abg-27-86.meeting.ietf.org [130.129.27.86]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by hgblob.tigertech.net (Postfix) with ESMTPSA id 2EEC632358A9; Thu, 25 Mar 2010 22:42:38 -0700 (PDT) Message-Id: From: Thomas Heide Clausen To: JP Vasseur 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, 26 Mar 2010 06:42:33 +0100 References: X-Mailer: Apple Mail (2.936) 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: Fri, 26 Mar 2010 05:42:16 -0000 I'd like to state my surprise that a "closed-door-no-transparency- interop-event" is organized, and allowed to be run, during an IETF meeting -- otherwise the cathedral of open processes..... Sincerely, Thomas (representing an RPL implementation, which was not deemed worthy of participation in this event) On Mar 26, 2010, at 03:54 AM, JP Vasseur wrote: > 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 pal@cs.stanford.edu Thu Mar 25 23:27: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 3175C3A6995 for ; Thu, 25 Mar 2010 23:27:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.169 X-Spam-Level: X-Spam-Status: No, score=-4.169 tagged_above=-999 required=5 tests=[AWL=1.300, 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 Q02g07+AFq8B for ; Thu, 25 Mar 2010 23:27:05 -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 874873A6889 for ; Thu, 25 Mar 2010 23:27:05 -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 1Nv30y-0006I6-DW; Thu, 25 Mar 2010 23:27:28 -0700 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v753.1) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <649A5094-5C7E-4E88-BC53-CF4E1F05B14B@cs.stanford.edu> Content-Transfer-Encoding: 7bit From: Philip Levis Date: Thu, 25 Mar 2010 23:25:30 -0700 To: Thomas Heide Clausen X-Mailer: Apple Mail (2.753.1) X-Scan-Signature: f219e97bb238ccbb8ed40879dafdba3c 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: Fri, 26 Mar 2010 06:27:06 -0000 On Mar 25, 2010, at 10:42 PM, Thomas Heide Clausen wrote: > I'd like to state my surprise that a "closed-door-no-transparency- > interop-event" is organized, and allowed to be run, during an IETF > meeting -- otherwise the cathedral of open processes..... > > Sincerely, > > Thomas > (representing an RPL implementation, which was not deemed worthy of > participation in this event) > > On Mar 26, 2010, at 03:54 AM, JP Vasseur wrote: > >> 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. Agreed -- it's kind of weird to ask for feed-back given that the event was closed. Why are we using these rather than standard, open, bake-off events? I can understand the role and need for IPSO, it just doesn't seem very relevant to IETF activities. Phil From jpv@cisco.com Fri Mar 26 00:43: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 B953F3A6829 for ; Fri, 26 Mar 2010 00:43:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.036 X-Spam-Level: X-Spam-Status: No, score=-9.036 tagged_above=-999 required=5 tests=[AWL=0.433, 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 jxDRzlz-I6BI for ; Fri, 26 Mar 2010 00:43:16 -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 C0DF63A6987 for ; Fri, 26 Mar 2010 00:43:07 -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: AvsEAJ8CrEurR7Hu/2dsb2JhbACbKnOkcJkVhH4Egx4 X-IronPort-AV: E=Sophos;i="4.51,312,1267401600"; d="scan'208";a="218023264" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-3.cisco.com with ESMTP; 26 Mar 2010 07:43:30 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id o2Q7hUSD023493; Fri, 26 Mar 2010 07:43:31 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 26 Mar 2010 00:43:31 -0700 Received: from dhcp-wireless-open-abg-26-235.meeting.ietf.org ([10.21.84.25]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 26 Mar 2010 00:43:29 -0700 Message-Id: <6E3A7DBA-140E-4042-9362-388A718F003F@cisco.com> From: JP Vasseur To: Thomas Heide Clausen 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, 26 Mar 2010 00:43:29 -0700 References: X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 26 Mar 2010 07:43:30.0365 (UTC) FILETIME=[0765EED0:01CACCB8] 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: Fri, 26 Mar 2010 07:43:16 -0000 Hi Thomas, On Mar 25, 2010, at 10:42 PM, Thomas Heide Clausen wrote: > I'd like to state my surprise that a "closed-door-no-transparency- > interop-event" is organized, and allowed to be run, during an IETF > meeting -- otherwise the cathedral of open processes..... > Do not blame me for that ... The IPSO alliance organized an RPL interop event during the IETF week. Any feed-back is useful for us to keep improving our spec. Cheers. JP. > Sincerely, > > Thomas > (representing an RPL implementation, which was not deemed worthy of > participation in this event) > > On Mar 26, 2010, at 03:54 AM, JP Vasseur wrote: > >> 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 mcr@sandelman.ca Fri Mar 26 05:48: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 F14743A672F for ; Fri, 26 Mar 2010 05:48:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.035 X-Spam-Level: * X-Spam-Status: No, score=1.035 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, 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 7qaFxDnpnSmL for ; Fri, 26 Mar 2010 05:48:50 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by core3.amsl.com (Postfix) with ESMTP id 4A3DE3A6839 for ; Fri, 26 Mar 2010 05:48:49 -0700 (PDT) Received: from sandelman.ottawa.on.ca (wlan202.sandelman.ca [209.87.252.202]) by relay.sandelman.ca (Postfix) with ESMTPS id A9BAD34732; Fri, 26 Mar 2010 08:46:22 -0400 (EDT) Received: from marajade.sandelman.ca (unknown [127.0.0.1]) by sandelman.ottawa.on.ca (Postfix) with ESMTP id A50274E7DC; Fri, 26 Mar 2010 08:49:11 -0400 (EDT) From: Michael Richardson To: Thomas Heide Clausen In-Reply-To: References: X-Mailer: MH-E 8.1; nmh 1.1; XEmacs 21.4 (patch 21) Date: Fri, 26 Mar 2010 08:49:11 -0400 Message-ID: <22290.1269607751@marajade.sandelman.ca> Sender: mcr@sandelman.ca 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: Fri, 26 Mar 2010 12:48:51 -0000 >>>>> "Thomas" == Thomas Heide Clausen writes: Thomas> I'd like to state my surprise that a Thomas> "closed-door-no-transparency- interop-event" is organized, Thomas> and allowed to be run, during an IETF meeting -- otherwise Thomas> the cathedral of open processes..... +1 From hrogge@googlemail.com Fri Mar 26 06:13: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 A38753A6B0D for ; Fri, 26 Mar 2010 06:13:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.76 X-Spam-Level: X-Spam-Status: No, score=0.76 tagged_above=-999 required=5 tests=[AWL=0.370, BAYES_20=-0.74, 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 KT09mQxC5dPO for ; Fri, 26 Mar 2010 06:13:02 -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 29A523A6B06 for ; Fri, 26 Mar 2010 06:12:27 -0700 (PDT) Received: by pwi10 with SMTP id 10so5061200pwi.31 for ; Fri, 26 Mar 2010 06:12:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:from:to:subject:date :user-agent:cc:references:in-reply-to:mime-version:content-type :content-transfer-encoding:message-id; bh=19757pCJW2jSCZmE7Mns2Wg5ztRFV0/EMxL6xhnVIHE=; b=OdAAJpLCvFvV/KtdebVy99clxy+tGQ0dGbr326HZcrCYO6GKFeA7VZ0Yz79Q8l73kk QHEFQF2xj4PxY6A1k/Q8WvrUQuRaCktPweQmfJ3lT2o+S3bxcybIpwtNDlyqvrmNm7AW EM69/RcLw1hJ2Lw3Fkt07p/Q8WZVy/rcGgkq8= 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=IEVk/PDI7m0mt0cgbDVyQORcLcLsJuwJG1Vqv/iPvZazKMgZ3URrLlWI5n7uAIPNDH OgFTX5bdXY2Tk20hN5vEfyIwBXuA5mFQvPuLKgN72oo9MbwCqpwaFpblIYZ07GMp3VTR LRjR3G//6fInS2EAa/yakNfTLcs9Q6WUgqybI= Received: by 10.114.186.39 with SMTP id j39mr801740waf.80.1269609166330; Fri, 26 Mar 2010 06:12:46 -0700 (PDT) Received: from core2.localnet (static-87-79-93-195.netcologne.de [87.79.93.195]) by mx.google.com with ESMTPS id 15sm155596pwi.2.2010.03.26.06.12.42 (version=SSLv3 cipher=RC4-MD5); Fri, 26 Mar 2010 06:12:43 -0700 (PDT) From: Henning Rogge To: roll@ietf.org Date: Fri, 26 Mar 2010 14:12:35 +0100 User-Agent: KMail/1.13.1 (Linux/2.6.33-gentoo; KDE/4.4.1; x86_64; ; ) References: <649A5094-5C7E-4E88-BC53-CF4E1F05B14B@cs.stanford.edu> In-Reply-To: <649A5094-5C7E-4E88-BC53-CF4E1F05B14B@cs.stanford.edu> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart2636951.bJfhNuoFKb"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <201003261412.40485.hrogge@googlemail.com> 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: Fri, 26 Mar 2010 13:13:02 -0000 --nextPart2636951.bJfhNuoFKb Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Am Freitag 26 M=C3=A4rz 2010 07:25:30 schrieb Philip Levis: > Agreed -- it's kind of weird to ask for feed-back given that the > event was closed. Why are we using these rather than standard, open, > bake-off events? I can understand the role and need for IPSO, it just > doesn't seem very relevant to IETF activities. Just a question, what is the use of an interop event without a wide audienc= e ?=20 I don't think there are too many Ripple implementations at the moment. 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 --nextPart2636951.bJfhNuoFKb 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) iEYEABECAAYFAkusssgACgkQcenvcwAcHWfrngCgkTpbJPf4639UIcmI7863A0hZ BlUAnAjfeulUg9JDb+uMQPnUIL9iDR3B =Yh7W -----END PGP SIGNATURE----- --nextPart2636951.bJfhNuoFKb-- From ulrich@herberg.name Fri Mar 26 07: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 4FAA93A680F for ; Fri, 26 Mar 2010 07:40:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.642 X-Spam-Level: X-Spam-Status: No, score=0.642 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_05=-1.11, DNS_FROM_OPENWHOIS=1.13, 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 jIGqraT5Rz7G for ; Fri, 26 Mar 2010 07:40:55 -0700 (PDT) Received: from mail-bw0-f211.google.com (mail-bw0-f211.google.com [209.85.218.211]) by core3.amsl.com (Postfix) with ESMTP id 874033A690B for ; Fri, 26 Mar 2010 07:40:52 -0700 (PDT) Received: by bwz3 with SMTP id 3so8436537bwz.29 for ; Fri, 26 Mar 2010 07:41:13 -0700 (PDT) MIME-Version: 1.0 Received: by 10.204.103.208 with HTTP; Fri, 26 Mar 2010 07:41:12 -0700 (PDT) In-Reply-To: <201003261412.40485.hrogge@googlemail.com> References: <649A5094-5C7E-4E88-BC53-CF4E1F05B14B@cs.stanford.edu> <201003261412.40485.hrogge@googlemail.com> Date: Fri, 26 Mar 2010 07:41:12 -0700 Received: by 10.204.133.25 with SMTP id d25mr1183824bkt.141.1269614472771; Fri, 26 Mar 2010 07:41:12 -0700 (PDT) Message-ID: <25c114b91003260741t37c43be7r9d9496c07cd13ebc@mail.gmail.com> From: Ulrich Herberg To: Henning Rogge Content-Type: multipart/alternative; boundary=001517447ee2a6b7a50482b5271b Cc: roll@ietf.org 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: Fri, 26 Mar 2010 14:40:56 -0000 --001517447ee2a6b7a50482b5271b Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable I agree with Henning and the others on this topic. I would have liked to participate. Ulrich On Fri, Mar 26, 2010 at 6:12 AM, Henning Rogge wrote= : > Am Freitag 26 M=E4rz 2010 07:25:30 schrieb Philip Levis: > > Agreed -- it's kind of weird to ask for feed-back given that the > > event was closed. Why are we using these rather than standard, open, > > bake-off events? I can understand the role and need for IPSO, it just > > doesn't seem very relevant to IETF activities. > Just a question, what is the use of an interop event without a wide > audience ? > I don't think there are too many Ripple implementations at the moment. > > Henning Rogge > > -- > 1) You can't win. > 2) You can't break even. > 3) You can't leave the game. > =97 The Laws of Thermodynamics, summarized > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > > --001517447ee2a6b7a50482b5271b Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable I agree with Henning and the others on this topic. I would have liked to pa= rticipate.

Ulrich


On Fri, Mar = 26, 2010 at 6:12 AM, Henning Rogge <hrogge@googlemail.com> wrote:
Am Freitag 26 M= =E4rz 2010 07:25:30 schrieb Philip Levis:
> Agreed -- it's kind of weird to ask for feed-bac= k given that the
> event was closed. Why are we using these rather than standard, open, > bake-off events? I can understand the role and need for IPSO, it just<= br> > doesn't seem very relevant to IETF activities.
Just a question, what is the use of an interop event without a wide a= udience ?
I don't think there are too many Ripple implementations at the moment.<= br>
Henning Rogge

--
1) You can't win.
2) You can't break even.
3) You can't leave the game.
=97 The Laws of Thermodynamics, summarized

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


--001517447ee2a6b7a50482b5271b-- From A.Ramrekha@kingston.ac.uk Fri Mar 26 07:53: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 30E353A6827 for ; Fri, 26 Mar 2010 07:53:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.469 X-Spam-Level: X-Spam-Status: No, score=-5.469 tagged_above=-999 required=5 tests=[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 R5qNZvPWYfsm for ; Fri, 26 Mar 2010 07:53:51 -0700 (PDT) Received: from mail84.messagelabs.com (mail84.messagelabs.com [195.245.231.99]) by core3.amsl.com (Postfix) with ESMTP id 6056A3A6AF4 for ; Fri, 26 Mar 2010 07:53:47 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: A.Ramrekha@kingston.ac.uk X-Msg-Ref: server-8.tower-84.messagelabs.com!1269615249!38529349!1 X-StarScan-Version: 6.2.4; banners=kingston.ac.uk,-,- X-Originating-IP: [141.241.2.32] Received: (qmail 7178 invoked from network); 26 Mar 2010 14:54:09 -0000 Received: from kuexim5.king.ac.uk (HELO kuexim5.king.ac.uk) (141.241.2.32) by server-8.tower-84.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 26 Mar 2010 14:54:09 -0000 Received: from kucahtpr01.king.ac.uk ([141.241.71.33] helo=KUCAHTPR01.kuds.kingston.ac.uk) by kuexim5.king.ac.uk with esmtp (Exim 4.69) (envelope-from ) id 1NvAvN-0001pN-15; Fri, 26 Mar 2010 14:54:13 +0000 Received: from KUMBX.kuds.kingston.ac.uk ([141.241.71.40]) by KUCAHTPR01 ([141.241.71.33]) with mapi; Fri, 26 Mar 2010 14:53:38 +0000 From: "Ramrekha, Arvind" To: Ulrich Herberg , Henning Rogge Date: Fri, 26 Mar 2010 14:53:02 +0000 Thread-Topic: [Roll] IPSO Interop event - Feed-back welcome Thread-Index: AcrM8nwE57ODHzZcTx+JOQN+dhcQ+wAAYx81 Message-ID: <31FA0235108C2F43A69AEC26D34E28010172D396D012@KUMBX.kuds.kingston.ac.uk> References: <649A5094-5C7E-4E88-BC53-CF4E1F05B14B@cs.stanford.edu> <201003261412.40485.hrogge@googlemail.com>, <25c114b91003260741t37c43be7r9d9496c07cd13ebc@mail.gmail.com> In-Reply-To: <25c114b91003260741t37c43be7r9d9496c07cd13ebc@mail.gmail.com> Accept-Language: en-US, en-GB Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "roll@ietf.org" 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: Fri, 26 Mar 2010 14:53:56 -0000 >> agree with Henning and the others on this topic. I would have liked to = participate. +1 Arvind. _____________________________________ From: roll-bounces@ietf.org [roll-bounces@ietf.org] On Behalf Of Ulrich He= rberg [ulrich@herberg.name] Sent: 26 March 2010 14:41 To: Henning Rogge Cc: roll@ietf.org Subject: Re: [Roll] IPSO Interop event - Feed-back welcome I agree with Henning and the others on this topic. I would have liked to p= articipate. Ulrich On Fri, Mar 26, 2010 at 6:12 AM, Henning Rogge > wrote: Am Freitag 26 M=E4rz 2010 07:25:30 schrieb Philip Levis: > Agreed -- it's kind of weird to ask for feed-back given that the > event was closed. Why are we using these rather than standard, open, > bake-off events? I can understand the role and need for IPSO, it just > doesn't seem very relevant to IETF activities. Just a question, what is the use of an interop event without a wide audien= ce ? I don't think there are too many Ripple implementations at the=20moment. Henning Rogge -- 1) You can't win. 2) You can't break even. 3) You can't leave the game. =97 The Laws of Thermodynamics, summarized _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll This email has been scanned for all viruses by the MessageLabs Email Security System. This email has been scanned for all viruses by the MessageLabs Email Security System. From jpv@cisco.com Fri Mar 26 08:39: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 397753A699C for ; Fri, 26 Mar 2010 08:39:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.144 X-Spam-Level: X-Spam-Status: No, score=-9.144 tagged_above=-999 required=5 tests=[AWL=0.325, 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 HNag5GAhZJdj for ; Fri, 26 Mar 2010 08:39:00 -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 598BF3A695A for ; Fri, 26 Mar 2010 08:39:00 -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: AvsEAGpyrEurR7H+/2dsb2JhbACbKXOnLpkVhH4Egx6Keg X-IronPort-AV: E=Sophos;i="4.51,315,1267401600"; d="scan'208";a="106233269" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-4.cisco.com with ESMTP; 26 Mar 2010 15:39:23 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o2QFdN6x007363; Fri, 26 Mar 2010 15:39:23 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 26 Mar 2010 08:39:24 -0700 Received: from dhcp-wireless-open-abg-26-235.meeting.ietf.org ([10.21.127.55]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 26 Mar 2010 08:39:23 -0700 Message-Id: <7D0FB48F-C04A-4DE5-A7FE-D2C4DF898B1A@cisco.com> From: JP Vasseur To: "Ramrekha, Arvind" , Ulrich Herberg , Henning Rogge In-Reply-To: <31FA0235108C2F43A69AEC26D34E28010172D396D012@KUMBX.kuds.kingston.ac.uk> 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, 26 Mar 2010 08:39:22 -0700 References: <649A5094-5C7E-4E88-BC53-CF4E1F05B14B@cs.stanford.edu> <201003261412.40485.hrogge@googlemail.com>, <25c114b91003260741t37c43be7r9d9496c07cd13ebc@mail.gmail.com> <31FA0235108C2F43A69AEC26D34E28010172D396D012@KUMBX.kuds.kingston.ac.uk> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 26 Mar 2010 15:39:23.0182 (UTC) FILETIME=[82340CE0:01CACCFA] Cc: ROLL WG Subject: [Roll] * closing * Re: 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, 26 Mar 2010 15:39:01 -0000 Hello, Just to close on this thread ;-) We (IETF) do not make decision on behalf of other alliances. Just =20 welcome feed-back on implementations from anyone. Thanks. JP. On Mar 26, 2010, at 7:53 AM, Ramrekha, Arvind wrote: >>> agree with Henning and the others on this topic. I would have =20 >>> liked to participate. > > +1 > > Arvind. > > _____________________________________ > From: roll-bounces@ietf.org [roll-bounces@ietf.org] On Behalf Of =20 > Ulrich Herberg [ulrich@herberg.name] > Sent: 26 March 2010 14:41 > To: Henning Rogge > Cc: roll@ietf.org > Subject: Re: [Roll] IPSO Interop event - Feed-back welcome > > I agree with Henning and the others on this topic. I would have =20 > liked to participate. > > Ulrich > > > On Fri, Mar 26, 2010 at 6:12 AM, Henning Rogge =20 > > wrote: > Am Freitag 26 M=E4rz 2010 07:25:30 schrieb Philip Levis: >> Agreed -- it's kind of weird to ask for feed-back given that the >> event was closed. Why are we using these rather than standard, open, >> bake-off events? I can understand the role and need for IPSO, it just >> doesn't seem very relevant to IETF activities. > Just a question, what is the use of an interop event without a wide =20= > audience ? > I don't think there are too many Ripple implementations at the moment. > > Henning Rogge > > -- > 1) You can't win. > 2) You can't break even. > 3) You can't leave the game. > =97 The Laws of Thermodynamics, summarized > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > > > > This email has been scanned for all viruses by the MessageLabs Email > Security System. > > This email has been scanned for all viruses by the MessageLabs Email > Security System. > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From robert.cragie@gridmerge.com Fri Mar 26 08:57: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 A6A763A6B43 for ; Fri, 26 Mar 2010 08:57:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.132 X-Spam-Level: X-Spam-Status: No, score=0.132 tagged_above=-999 required=5 tests=[BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, 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 yh0qQsF1Q1aj for ; Fri, 26 Mar 2010 08:56:59 -0700 (PDT) Received: from mail78.extendcp.co.uk (mail78.extendcp.co.uk [79.170.40.78]) by core3.amsl.com (Postfix) with ESMTP id 8C07E3A6B47 for ; Fri, 26 Mar 2010 08:56:34 -0700 (PDT) Received: from 72-254-61-93.client.stsn.net ([72.254.61.93] helo=[10.7.39.29]) by mail78.extendcp.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.70) id 1NvBu2-0007xX-6U for roll@ietf.org; Fri, 26 Mar 2010 15:56:56 +0000 Message-ID: <4BACD941.2080608@gridmerge.com> Date: Fri, 26 Mar 2010 08:56:49 -0700 From: Robert Cragie Organization: Gridmerge Ltd. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.8) Gecko/20100227 Lightning/1.0b1 Thunderbird/3.0.3 MIME-Version: 1.0 To: roll@ietf.org References: <649A5094-5C7E-4E88-BC53-CF4E1F05B14B@cs.stanford.edu> <201003261412.40485.hrogge@googlemail.com>, <25c114b91003260741t37c43be7r9d9496c07cd13ebc@mail.gmail.com> <31FA0235108C2F43A69AEC26D34E28010172D396D012@KUMBX.kuds.kingston.ac.uk> <7D0FB48F-C04A-4DE5-A7FE-D2C4DF898B1A@cisco.com> In-Reply-To: <7D0FB48F-C04A-4DE5-A7FE-D2C4DF898B1A@cisco.com> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms000705040001050401060600" Subject: Re: [Roll] * closing * Re: IPSO Interop event - Feed-back welcome 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, 26 Mar 2010 15:57:00 -0000 This is a cryptographically signed message in MIME format. --------------ms000705040001050401060600 Content-Type: multipart/alternative; boundary="------------040307080802050801080203" This is a multi-part message in MIME format. --------------040307080802050801080203 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable I would just like to add that alliances like IPSO and ZigBee have a=20 primary role in conformance testing and the aim of the interops is to=20 support conformance testing. Therefore PICS and test plans are developed = alongside the specifications to achieve this. The interops have to be=20 controlled or else nothing would be achieved in them. It is highly=20 unlikely that anyone just turning up with a platform which hadn't been=20 developed in accordance with the additional PICS and test plans would=20 have managed to do any useful interop with other platforms; indeed it is = likely to be disruptive for the alliance members moving towards=20 conformance, even in these early stages. However it is entirely reasonable to ask for and expect feedback from=20 alliance interop testing (or indeed from any form of interop testing) as = it hardly benefits alliance members if this information is not=20 propagated back into the IETF. 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/03/2010 8:39 AM, JP Vasseur wrote: > Hello, > > Just to close on this thread ;-) > > We (IETF) do not make decision on behalf of other alliances. Just=20 > welcome feed-back on implementations > from anyone. > > Thanks. > > JP. > > On Mar 26, 2010, at 7:53 AM, Ramrekha, Arvind wrote: > >>>> agree with Henning and the others on this topic. I would have liked = >>>> to participate. >> >> +1 >> >> Arvind. >> >> _____________________________________ >> From: roll-bounces@ietf.org [roll-bounces@ietf.org] On Behalf Of=20 >> Ulrich Herberg [ulrich@herberg.name] >> Sent: 26 March 2010 14:41 >> To: Henning Rogge >> Cc: roll@ietf.org >> Subject: Re: [Roll] IPSO Interop event - Feed-back welcome >> >> I agree with Henning and the others on this topic. I would have liked = >> to participate. >> >> Ulrich >> >> >> On Fri, Mar 26, 2010 at 6:12 AM, Henning Rogge=20 >> > wrote: >> Am Freitag 26 M=E4rz 2010 07:25:30 schrieb Philip Levis: >>> Agreed -- it's kind of weird to ask for feed-back given that the >>> event was closed. Why are we using these rather than standard, open, >>> bake-off events? I can understand the role and need for IPSO, it just= >>> doesn't seem very relevant to IETF activities. >> Just a question, what is the use of an interop event without a wide=20 >> audience ? >> I don't think there are too many Ripple implementations at the moment.= >> >> Henning Rogge >> >> --=20 >> 1) You can't win. >> 2) You can't break even. >> 3) You can't leave the game. >> =97 The Laws of Thermodynamics, summarized >> >> _______________________________________________ >> Roll mailing list >> Roll@ietf.org >> https://www.ietf.org/mailman/listinfo/roll >> >> >> >> This email has been scanned for all viruses by the MessageLabs Email >> Security System. >> >> This email has been scanned for all viruses by the MessageLabs Email >> Security System. >> _______________________________________________ >> Roll mailing list >> Roll@ietf.org >> https://www.ietf.org/mailman/listinfo/roll > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > --------------040307080802050801080203 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable I would just like to add that alliances like IPSO and ZigBee have a primary role in conformance testing and the aim of the interops is to support conformance testing. Therefore PICS and test plans are developed alongside the specifications to achieve this. The interops have to be controlled or else nothing would be achieved in them. It is highly unlikely that anyone just turning up with a platform which hadn't been developed in accordance with the additional PICS and test plans would have managed to do any useful interop with other platforms; indeed it is likely to be disruptive for the alliance members moving towards conformance, even in these early stages.

However it is entirely reasonable to ask for and expect feedback from alliance interop testing (or indeed from any form of interop testing) as it hardly benefits alliance members if this information is not propagated back into the IETF.

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/03/2010 8:39 AM, JP Vasseur wrote:
Hello,

Just to close on this thread ;-)

We (IETF) do not make decision on behalf of other alliances. Just welcome feed-back on implementations
from anyone.

Thanks.

JP.

On Mar 26, 2010, at 7:53 AM, Ramrekha, Arvind wrote:

agree with Henning and the others on this= topic. I would have liked to participate.

+1

Arvind.

_____________________________________
From: roll-bounces@ietf.org [roll-bounces@ietf.org] On Beha= lf Of Ulrich Herberg [ulrich@herberg.name]
Sent: 26 March 2010 14:41
To: Henning Rogge
Cc: r= oll@ietf.org
Subject: Re: [Roll] IPSO Interop event - Feed-back welcome

I agree with Henning and the others on this topic. I would have liked to participate.

Ulrich


On Fri, Mar 26, 2010 at 6:12 AM, Henning Rogge <hrogge@googlemail.com<mailto:hrogge@googlemail.com>&g= t; wrote:
Am Freitag 26 M=E4rz 2010 07:25:30 schrieb Philip Levis:
Agreed -- it's kind of weird to ask for feed-back given that the
event was closed. Why are we using these rather than standard, open,
bake-off events? I can understand the role and need for IPSO, it just
doesn't seem very relevant to IETF activities.
Just a question, what is the use of an interop event without a wide audience ?
I don't think there are too many Ripple implementations at the moment.

Henning Rogge

--
1) You can't win.
2) You can't break even.
3) You can't leave the game.
=97 The Laws of Thermodynamics, summarized

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



This email has been scanned for all viruses by the MessageLabs Email
Security System.

This email has been scanned for all viruses by the MessageLabs Email
Security System.
_______________________________________________
Roll mailing list
Roll@= ietf.org
https://www.ietf.org/mailman/listinfo/roll

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

--------------040307080802050801080203-- --------------ms000705040001050401060600 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 GgUAoIIB0DAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMDAz MjYxNTU2NDlaMCMGCSqGSIb3DQEJBDEWBBSLklCQbbsonKHwbevSbiw8gAAaaDBfBgkqhkiG 9w0BCQ8xUjBQMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYI KoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgYUGCSsGAQQBgjcQBDF4MHYw YjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4x LDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhB0FYYcRpgg E7/iD53vjpAfMIGHBgsqhkiG9w0BCRACCzF4oHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoT HFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25h bCBGcmVlbWFpbCBJc3N1aW5nIENBAhB0FYYcRpggE7/iD53vjpAfMA0GCSqGSIb3DQEBAQUA BIIBACTXKZi3DZGJ2h4r7O8PRZLRx7PbzAxJK5fMjazHRJXUB5syktL7p8VUIUy/Lb7IXIH7 xCIEKutPr+vyGn+ty+qybA2KcbXI+Q1/hdW2Ye7/op3g86hybIW+6dGUtQ21O9/pXgWxXcjQ F5V3rf9am6x74qyVaSt1oS37DprhG9Rh/NBEAXzLFue8FPzCW3V2C0aVOPrsJUPld7LVxGFA QayI2lmzd73gw9eeBFtrEkb632yzkupoubapBH0WBYrMPGG+4AKQapyvMfxF58yM4RVi/tGP NTVCZ7B80YQe62+nnx7qkZlrkIxHhV/ZrMXKG45Ev3rT8ZS2cHyhYRk4OWgAAAAAAAA= --------------ms000705040001050401060600-- From pal@cs.stanford.edu Fri Mar 26 09: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 810AE3A68D4 for ; Fri, 26 Mar 2010 09:23:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.819 X-Spam-Level: X-Spam-Status: No, score=-4.819 tagged_above=-999 required=5 tests=[AWL=0.650, 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 kLJXw9PE1VP6 for ; Fri, 26 Mar 2010 09:23: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 ACA213A6A73 for ; Fri, 26 Mar 2010 09:19:45 -0700 (PDT) Received: from [76.14.71.8] (helo=[192.168.1.103]) by cs-smtp-1.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1NvCGX-0007Rd-9M; Fri, 26 Mar 2010 09:20:09 -0700 Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Philip Levis In-Reply-To: <6E3A7DBA-140E-4042-9362-388A718F003F@cisco.com> Date: Fri, 26 Mar 2010 09:20:10 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <6BED9020-F520-4105-B470-31B59E75EA01@cs.stanford.edu> References: <6E3A7DBA-140E-4042-9362-388A718F003F@cisco.com> To: JP Vasseur X-Mailer: Apple Mail (2.1077) X-Scan-Signature: acf3039aa8d32d1ac60a71149e52b94c 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: Fri, 26 Mar 2010 16:24:00 -0000 On Mar 26, 2010, at 12:43 AM, JP Vasseur wrote: > Hi Thomas, >=20 > On Mar 25, 2010, at 10:42 PM, Thomas Heide Clausen wrote: >=20 >> I'd like to state my surprise that a = "closed-door-no-transparency-interop-event" is organized, and allowed to = be run, during an IETF meeting -- otherwise the cathedral of open = processes..... >>=20 >=20 > Do not blame me for that ... The IPSO alliance organized an RPL = interop event during the IETF week. > Any feed-back is useful for us to keep improving our spec. No blame -- it's just a question of whether we (as a WG) should try to = push IPSO to be more open. At the very least, a bake-off once -08 (with = resolution of DAOs, flow labels, etc.) is released seems like a good = idea. Phil= From dominique.barthel@orange-ftgroup.com Fri Mar 26 09:28: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 42FF53A6C55 for ; Fri, 26 Mar 2010 09:28:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.119 X-Spam-Level: X-Spam-Status: No, score=-2.119 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, HELO_EQ_FR=0.35, 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 L1GYS-60ySq4 for ; Fri, 26 Mar 2010 09:28:04 -0700 (PDT) Received: from p-mail1.rd.francetelecom.com (p-mail1.rd.francetelecom.com [195.101.245.15]) by core3.amsl.com (Postfix) with ESMTP id D500D3A6BBA for ; Fri, 26 Mar 2010 09:21:56 -0700 (PDT) Received: from p-mail1.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 4F3108B8017 for ; Fri, 26 Mar 2010 17:20:53 +0000 (UTC) Received: from ftrdsmtp2.rd.francetelecom.fr (unknown [10.192.128.47]) by p-mail1.rd.francetelecom.com (Postfix) with ESMTP id C88478B81DC for ; Fri, 26 Mar 2010 15:41:37 +0000 (UTC) Received: from ftrdmel0.rd.francetelecom.fr ([10.192.128.56]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Fri, 26 Mar 2010 15:42:31 +0100 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, 26 Mar 2010 15:39:18 +0100 Message-ID: <8E09C72DBC577D489F13A71228C0B7BF011438E0@ftrdmel0.rd.francetelecom.fr> In-Reply-To: <54B8E8AD-579C-4B04-A034-003D9D45622B@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] IPSO Interop event - Feed-back welcome Thread-Index: AcrMj7qlCivLQgpyR9OT+kBxpG91zQAYdN7g References: <54B8E8AD-579C-4B04-A034-003D9D45622B@cisco.com> From: To: X-OriginalArrivalTime: 26 Mar 2010 14:42:31.0669 (UTC) FILETIME=[90C87A50:01CACCF2] 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: Fri, 26 Mar 2010 16:28:05 -0000 Hi Working Group, If you pay close attention to the orginal email, you'll see that JP was = writing to Mathilde, who was part of the event. I take it that he was encouraging *her* to provide feedback, not the = Working Group. I wouldn't go as far as implying that the cc to the list was by = accident, but who knows... Speaking for myself, I would welcome feedback from Mathilde or whoever = was there, Dominique -----Message d'origine----- De : roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] De la part de = JP Vasseur Envoy=E9 : jeudi 25 mars 2010 09:51 =C0 : Mathilde Durvy (mdurvy) Cc : ROLL WG Objet : [Roll] 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 pal@cs.stanford.edu Fri Mar 26 09:29: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 408BD3A6BFF for ; Fri, 26 Mar 2010 09:29:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.106 X-Spam-Level: X-Spam-Status: No, score=-4.106 tagged_above=-999 required=5 tests=[AWL=-0.496, BAYES_20=-0.74, 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 661tpdKvdhyA for ; Fri, 26 Mar 2010 09:28: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 52AAE3A6C07 for ; Fri, 26 Mar 2010 09:23:19 -0700 (PDT) Received: from [76.14.71.8] (helo=[192.168.1.103]) by cs-smtp-1.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1NvCJy-0007o0-FT; Fri, 26 Mar 2010 09:23:42 -0700 Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Philip Levis In-Reply-To: <4BACD941.2080608@gridmerge.com> Date: Fri, 26 Mar 2010 09:23:43 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <5D0CD0B3-8F19-4900-83C5-B9388C71CDB8@cs.stanford.edu> References: <649A5094-5C7E-4E88-BC53-CF4E1F05B14B@cs.stanford.edu> <201003261412.40485.hrogge@googlemail.com>, <25c114b91003260741t37c43be7r9d9496c07cd13ebc@mail.gmail.com> <31FA0235108C2F43A69AEC26D34E28010172D396D012@KUMBX.kuds.kingston.ac.uk> <7D0FB48F-C04A-4DE5-A7FE-D2C4DF898B1A@cisco.com> <4BACD941.2080608@gridmerge.com> To: robert.cragie@gridmerge.com X-Mailer: Apple Mail (2.1077) X-Scan-Signature: 9dddbef7dbf47a29383c7a3c8e5dce6e Cc: roll@ietf.org Subject: Re: [Roll] * closing * Re: 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, 26 Mar 2010 16:29:00 -0000 On Mar 26, 2010, at 8:56 AM, Robert Cragie wrote: > I would just like to add that alliances like IPSO and ZigBee have a = primary role in conformance testing and the aim of the interops is to = support conformance testing. Therefore PICS and test plans are developed = alongside the specifications to achieve this. The interops have to be = controlled or else nothing would be achieved in them. It is highly = unlikely that anyone just turning up with a platform which hadn't been = developed in accordance with the additional PICS and test plans would = have managed to do any useful interop with other platforms; indeed it is = likely to be disruptive for the alliance members moving towards = conformance, even in these early stages. But Robert, the IETF has a history of open inter-op events; I think this = history has shown that the concerns above are really not an issue. This = mentality comes from closed, industrial consortia, which the IETF is = not. You want some kind of gating function so we don't waste people's = time, but things like NDAs and pay-to-play really don't lead to the best = standards. Phil= From d.sturek@att.net Fri Mar 26 09:41: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 897053A6B99 for ; Fri, 26 Mar 2010 09:41:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.884 X-Spam-Level: ** X-Spam-Status: No, score=2.884 tagged_above=-999 required=5 tests=[AWL=-0.031, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, 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 FRpW9D-fber6 for ; Fri, 26 Mar 2010 09:41:30 -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 CDEAC3A6AF4 for ; Fri, 26 Mar 2010 09:38:37 -0700 (PDT) Received: (qmail 20131 invoked from network); 26 Mar 2010 16:38:58 -0000 Received: from adsl-69-225-120-125.dsl.sndg02.pacbell.net (d.sturek@69.225.120.125 with login) by smtp127.sbc.mail.sp1.yahoo.com with SMTP; 26 Mar 2010 09:38:57 -0700 PDT X-Yahoo-SMTP: fvjol_aswBAraSJvMLe2r1XTzhBhbFxY8q8c3jo- X-YMail-OSG: A6mFrhkVM1m9wNV81RYFtaJOCPa65OmZ5BJBUhBhsXBZX.5OUGl7QLCMGk1urwbcT5h0bjLOyXexxb3gxRINf6CCozdbIDVraXUxMNx5RGUmstUsZB8clAmh7p_kAI_1WjWr23a_lMhNVDJzgfyKd7lDVyEpDL79etsDQTLlG9Ykf96iSwM_iUkfXMZQpXeDNkjdEZnUI6DclgQckUuRRY9c5bStgK_0Zg6lDxopD957Jlh103LDKq.83LwjRoU_6rvXsRm6c3NfMbaakajSi0oa9tIhgQV4U7xPvLo7WcxO1r9ZDWs- X-Yahoo-Newman-Property: ymail-3 From: "Don Sturek" To: "'Philip Levis'" , References: <649A5094-5C7E-4E88-BC53-CF4E1F05B14B@cs.stanford.edu> <201003261412.40485.hrogge@googlemail.com>, <25c114b91003260741t37c43be7r9d9496c07cd13ebc@mail.gmail.com> <31FA0235108C2F43A69AEC26D34E28010172D396D012@KUMBX.kuds.kingston.ac.uk> <7D0FB48F-C04A-4DE5-A7FE-D2C4DF898B1A@cisco.com> <4BACD941.2080608@gridmerge.com> <5D0CD0B3-8F19-4900-83C5-B9388C71CDB8@cs.stanford.edu> In-Reply-To: <5D0CD0B3-8F19-4900-83C5-B9388C71CDB8@cs.stanford.edu> Date: Fri, 26 Mar 2010 09:38:55 -0700 Message-ID: <006401cacd02$d3e613a0$7bb23ae0$@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: AcrNAYCe57VhXPTZQMGYR+CzYTDXyAAABXsw Content-Language: en-us Cc: roll@ietf.org Subject: Re: [Roll] * closing * Re: IPSO Interop event - Feed-back welcome 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, 26 Mar 2010 16:41:31 -0000 Hi Phil, I think Roberts point is that to deploy products, using IETF standards such as ROLL, industry defined mandatory/optional features and test plans/certification are needed. This leads to creation of paid-membership industry groups like IPSO and ZigBee to support the commercial aspects of deployment (testing, labeling, etc). Have a look at the WiFi Alliance for an example. No one could say this group led to poor standards. We all used WiFi at the IETF event! However, groups like WiFi charge membership fees, create industry standards based on IETF RFCs, certify to subsets of IETF standards. I would expect there to be membership fees associated with this. Personally, I welcome input from groups like this. I think the IETF standards profit from having these groups report back (I would prefer this to them taking IETF standards and creating "one off" versions) Don -----Original Message----- From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Philip Levis Sent: Friday, March 26, 2010 9:24 AM To: robert.cragie@gridmerge.com Cc: roll@ietf.org Subject: Re: [Roll] * closing * Re: IPSO Interop event - Feed-back welcome On Mar 26, 2010, at 8:56 AM, Robert Cragie wrote: > I would just like to add that alliances like IPSO and ZigBee have a primary role in conformance testing and the aim of the interops is to support conformance testing. Therefore PICS and test plans are developed alongside the specifications to achieve this. The interops have to be controlled or else nothing would be achieved in them. It is highly unlikely that anyone just turning up with a platform which hadn't been developed in accordance with the additional PICS and test plans would have managed to do any useful interop with other platforms; indeed it is likely to be disruptive for the alliance members moving towards conformance, even in these early stages. But Robert, the IETF has a history of open inter-op events; I think this history has shown that the concerns above are really not an issue. This mentality comes from closed, industrial consortia, which the IETF is not. You want some kind of gating function so we don't waste people's time, but things like NDAs and pay-to-play really don't lead to the best standards. Phil _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From mcr@sandelman.ca Fri Mar 26 15:02: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 E5AB83A659A for ; Fri, 26 Mar 2010 15:02:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.776 X-Spam-Level: * X-Spam-Status: No, score=1.776 tagged_above=-999 required=5 tests=[BAYES_50=0.001, 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 XjamVUUikeKf for ; Fri, 26 Mar 2010 15:02:19 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by core3.amsl.com (Postfix) with ESMTP id B21BA3A6B0D for ; Fri, 26 Mar 2010 15:02:19 -0700 (PDT) Received: from sandelman.ottawa.on.ca (CPE001839ea7787-CM001a6670fc8c.cpe.net.cable.rogers.com [99.241.126.78]) by relay.sandelman.ca (Postfix) with ESMTPS id EC4C0343EF; Fri, 26 Mar 2010 17:59:54 -0400 (EDT) Received: from marajade.sandelman.ca (unknown [127.0.0.1]) by sandelman.ottawa.on.ca (Postfix) with ESMTP id 4162A4E7EC; Fri, 26 Mar 2010 18:02:42 -0400 (EDT) From: Michael Richardson To: robert.cragie@gridmerge.com In-Reply-To: <4BACD941.2080608@gridmerge.com> References: <649A5094-5C7E-4E88-BC53-CF4E1F05B14B@cs.stanford.edu> <201003261412.40485.hrogge@googlemail.com>, <25c114b91003260741t37c43be7r9d9496c07cd13ebc@mail.gmail.com> <31FA0235108C2F43A69AEC26D34E28010172D396D012@KUMBX.kuds.kingston.ac.uk> <7D0FB48F-C04A-4DE5-A7FE-D2C4DF898B1A@cisco.com> <4BACD941.2080608@gridmerge.com> X-Mailer: MH-E 8.1; nmh 1.1; XEmacs 21.4 (patch 21) Date: Fri, 26 Mar 2010 18:02:42 -0400 Message-ID: <10545.1269640962@marajade.sandelman.ca> Sender: mcr@sandelman.ca Cc: roll@ietf.org Subject: Re: [Roll] * closing * Re: 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, 26 Mar 2010 22:02:21 -0000 >>>>> "Robert" == Robert Cragie writes: Robert> I would just like to add that alliances like IPSO and ZigBee Robert> have a primary role in conformance testing and the aim of Robert> the interops is to support conformance testing. Therefore Robert> PICS and test plans are developed alongside the Robert> specifications to achieve this. The interops have to be Robert> controlled or else nothing would be achieved in them. It is Robert> highly unlikely that anyone just turning up with a platform Robert> which hadn't been developed in accordance with the Robert> additional PICS and test plans would have managed to do any Robert> useful interop with other platforms; indeed it is likely to Robert> be disruptive for the alliance members moving towards Robert> conformance, even in these early stages. Yes, and entirely appropriate that the list be told about such events and organizations in sufficient time that we can join the appropriate organizations, and make plans to show up at the right places at the right places. This is what I am complaining about. -- ] 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 robert.cragie@gridmerge.com Fri Mar 26 16:38: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 683443A6A97 for ; Fri, 26 Mar 2010 16:38:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.192 X-Spam-Level: *** X-Spam-Status: No, score=3.192 tagged_above=-999 required=5 tests=[BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, HELO_MISMATCH_UK=1.749, HOST_MISMATCH_COM=0.311, 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 2xSSu9OgOecS for ; Fri, 26 Mar 2010 16:38:51 -0700 (PDT) Received: from webmail2.extendcp.co.uk (www.outitgoes.com [79.170.40.67]) by core3.amsl.com (Postfix) with ESMTP id 1E83C3A6A30 for ; Fri, 26 Mar 2010 16:38:50 -0700 (PDT) Received: from localhost ([127.0.0.1]) by webmail2.extendcp.co.uk with esmtp (Exim 4.43) id 1NvJ7R-0001K3-Dy for roll@ietf.org; Fri, 26 Mar 2010 23:39:13 +0000 Message-Id: <43a1ca817d13de2b954494185e35d897125244ce@webmail.hosting.heartinternet.co.uk> From: Robert Cragie To: roll@ietf.org X-Mailer: Atmail Date: Fri, 26 Mar 2010 23:39:13 +0000 Content-Type: multipart/alternative; boundary="=_9292e6c1ee0756d1af569980cfaff93a" MIME-Version: 1.0 Subject: Re: [Roll] * closing * Re: 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, 26 Mar 2010 23:38:52 -0000 --=_9292e6c1ee0756d1af569980cfaff93a Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable These events are not a secret as such nor are the alliances'=0Aintention= s with respect to IETF standards (e.g. see=0Ahttp://zigbee.org/imwp/idms= /popups/pop_download.asp?contentID=3D15754 -=0Aplease note the release d= ate of April 27 2009). Alliances don't tend=0Ato actively post to public= reflectors like IETF as it may be construed=0Aas trying to solicit busi= ness, which is always frowned upon.=0A '=0A Robert=0A=0A=09Robert Cragie= (Pacific Gas indeed it is likely to=0A Robert> be disruptive for the al= liance members moving towards=0A Robert> conformance, even in these earl= y stages.=0A=0AYes, and entirely appropriate that the list be told about= such events=0Aand organizations in sufficient time that we can join the= appropriate=0Aorganizations, and make plans to show up at the right pla= ces at the=0Aright places.=0A=0AThis is what I am complaining about.=0A= =0A=0A=0ALinks:=0A------=0A[1] http://www.gridmerge.com/=0A --=_9292e6c1ee0756d1af569980cfaff93a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable These events are not a secret as such nor are the alliances'= intentions=0Awith respect to IETF standards (e.g. see=0Ahttp://zigbee.o= rg/imwp/idms/popups/pop_download.asp?contentID=3D15754 -=0Aplease note t= he release date of April 27 2009). Alliances don't tend to=0Aactively po= st to public reflectors like IETF as it may be construed as=0Atrying to= solicit business, which is always frowned upon.
=0A'
=0ARober= t
=0A

Robert Cragie (= Pacific Gas & Electric)

=0A

Gridmerge Ltd.
=0A89 Greenfiel= d Crescent,
=0AWakefield, WF4 4WA, UK
=0A+44 (0) 1924 910888http://www.gridmerge.com=0A

=0A
=0AOn 26/03/2010 3:02 PM, Michael Richardson wrote:= =0A
=0A 
"Robert" =3D=3D Robert Cragie <robert.cragie@gridmerge.c=
om> writes:
=0A 
    Robert> I would just like to add tha=
t alliances like IPSO and ZigBee
    Robert> have a primary role=
 in conformance testing and the aim of
    Robert> the interops=
 is to support conformance testing. Therefore
    Robert> PICS a=
nd test plans are developed alongside the
    Robert> specificat=
ions to achieve this. The interops have to be
    Robert> contro=
lled or else nothing would be achieved in them. It is
    Robert>=
; highly unlikely that anyone just turning up with a platform
    R=
obert> which hadn't been developed in accordance with the
    Ro=
bert> additional PICS and test plans would have managed to do any    Robert> useful interop with other platforms; indeed it is like=
ly to
    Robert> be disruptive for the alliance members moving=
 towards
    Robert> conformance, even in these early stages.
Yes, and entirely appropriate that the list be told about such=
 events
and organizations in sufficient time that we can join the a=
ppropriate
organizations, and make plans to show up at the right pl=
aces at the
right places.

This is what I am complaining=
 about.

=0A=09=09

--=_9292e6c1ee0756d1af569980cfaff93a-- From prvs=696ec4d62=mukul@uwm.edu Sat Mar 27 23:36: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 43DFB3A6A57 for ; Sat, 27 Mar 2010 23:36:08 -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 07+gRByYwxaJ for ; Sat, 27 Mar 2010 23:36:07 -0700 (PDT) Received: from ip1mta.uwm.edu (ip1mta.uwm.edu [129.89.7.18]) by core3.amsl.com (Postfix) with ESMTP id 3553A3A6A56 for ; Sat, 27 Mar 2010 23:36:07 -0700 (PDT) Received: from mta03.pantherlink.uwm.edu ([129.89.7.83]) by ip1mta.uwm.edu with ESMTP; 28 Mar 2010 01:36:32 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by mta03.pantherlink.uwm.edu (Postfix) with ESMTP id 94DE4C085A1 for ; Sun, 28 Mar 2010 01:36:32 -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 PGi1sCCWesG8 for ; Sun, 28 Mar 2010 01:36:32 -0500 (CDT) Received: from mail02.pantherlink.uwm.edu (mail02.pantherlink.uwm.edu [129.89.7.86]) by mta03.pantherlink.uwm.edu (Postfix) with ESMTP id 6CA30C085A0 for ; Sun, 28 Mar 2010 01:36:32 -0500 (CDT) Date: Sun, 28 Mar 2010 01:36:32 -0500 (CDT) From: Mukul Goyal To: roll Message-ID: <1513203275.517921269758192360.JavaMail.root@mail02.pantherlink.uwm.edu> In-Reply-To: <304209155.517851269758032041.JavaMail.root@mail02.pantherlink.uwm.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [129.89.7.91] X-Mailer: Zimbra 5.0.22_GA_3210.RHEL4_64 (ZimbraWebClient - [unknown] (Win)/5.0.22_GA_3210.RHEL4_64) X-Authenticated-User: mukul@uwm.edu Subject: [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: Sun, 28 Mar 2010 06:36:08 -0000 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. 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. 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. Thanks Mukul From yoav@yitran.com Sun Mar 28 00:44: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 26CB83A6784 for ; Sun, 28 Mar 2010 00:44:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.247 X-Spam-Level: X-Spam-Status: No, score=-2.247 tagged_above=-999 required=5 tests=[BAYES_50=0.001, 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 Gp4ZC-7tJ0js for ; Sun, 28 Mar 2010 00:44:06 -0700 (PDT) Received: from na3sys009aog111.obsmtp.com (na3sys009aog111.obsmtp.com [74.125.149.205]) by core3.amsl.com (Postfix) with SMTP id EF8C03A68AC for ; Sun, 28 Mar 2010 00:44:05 -0700 (PDT) Received: from source ([74.125.82.173]) by na3sys009aob111.postini.com ([74.125.148.12]) with SMTP ID DSNKS68I32wfA6+sJgAcfHl4kddH8ICatAD3@postini.com; Sun, 28 Mar 2010 00:44:32 PDT Received: by wyb42 with SMTP id 42so4409881wyb.32 for ; Sun, 28 Mar 2010 00:44:31 -0700 (PDT) From: Yoav Ben-Yehezkel References: <8E09C72DBC577D489F13A71228C0B7BF010FEFE9@ftrdmel0.rd.francetelecom.fr> <5C4CCBDE-4397-4797-89CD-81C0EA59E1B1@cs.stanford.edu> <8E09C72DBC577D489F13A71228C0B7BF010FF65D@ftrdmel0.rd.francetelecom.fr> In-Reply-To: MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcrKmtTzrcDLpBliQPeVA7YqHbXkyQDr3orQ Date: Sun, 28 Mar 2010 10:44:31 +0300 Received: by 10.216.86.193 with SMTP id w43mr2007940wee.16.1269762271095; Sun, 28 Mar 2010 00:44:31 -0700 (PDT) Message-ID: <4de5bea503af5a5b2db5611105cbed13@mail.gmail.com> To: Philip Levis , Matteo Paris Content-Type: text/plain; charset=ISO-8859-1 Cc: roll@ietf.org Subject: Re: [Roll] Options in DIS X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 28 Mar 2010 07:44:07 -0000 Hi, To my understanding, DIS's are not so commonly used. It could be that introducing the DIS fields to all packets would be the simplest solution. Thanks, Yoav -----Original Message----- From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Philip Levis Sent: Tuesday, March 23, 2010 5:09 PM To: Matteo Paris Cc: roll@ietf.org Subject: Re: [Roll] Options in DIS On Mar 23, 2010, at 6:35 AM, Matteo Paris wrote: > > Hi Phil, > > The concern that I raised did not have to do with trying to further suppress DIO messages within a single DODAG beyond what is provided by Trickle. > > Rather, I described the scenario in which there are multiple DODAGS (dozens) in a dense network (eg, hundreds of nodes within radio range of each other). It is often the case that the node sending the DIS has specific information about which DODAG it is interested in, in the form of destination prefixes, dag ids, instance ids, etc. If this information were contained in the DIS, the filtering could happen prior to transmission of DIOs, saving the network from significant unneccessary disruption. > > What do you think? > I think this makes total sense. But should it be a standard DIS field, or a DIS option? If a standard field there will need to be an all IDs/broadcast value. Phil _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From robert.cragie@gridmerge.com Sun Mar 28 07: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 912D53A697B for ; Sun, 28 Mar 2010 07:47:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.751 X-Spam-Level: X-Spam-Status: No, score=0.751 tagged_above=-999 required=5 tests=[BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, 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 V+K5UWHLiSM9 for ; Sun, 28 Mar 2010 07:47: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 9C3F93A6971 for ; Sun, 28 Mar 2010 07:47:32 -0700 (PDT) Received: from c-205-201-170-136.sd2.redwire.net ([205.201.170.136] helo=[10.59.25.223]) by mail78.extendcp.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.70) id 1NvtmO-000263-C1 for roll@ietf.org; Sun, 28 Mar 2010 15:47:57 +0100 Message-ID: <4BAF6C19.6040004@gridmerge.com> Date: Sun, 28 Mar 2010 07:47:53 -0700 From: Robert Cragie Organization: Gridmerge Ltd. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.8) Gecko/20100227 Lightning/1.0b1 Thunderbird/3.0.3 MIME-Version: 1.0 To: roll@ietf.org References: <1513203275.517921269758192360.JavaMail.root@mail02.pantherlink.uwm.edu> In-Reply-To: <1513203275.517921269758192360.JavaMail.root@mail02.pantherlink.uwm.edu> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms070102010702000708090709" 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 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: Sun, 28 Mar 2010 14:47:34 -0000 This is a cryptographically signed message in MIME format. --------------ms070102010702000708090709 Content-Type: multipart/alternative; boundary="------------090706050903030505050409" This is a multi-part message in MIME format. --------------090706050903030505050409 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable 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=20 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 sure = if people have already identified these issues. > > 1) I am concerned about the fact that the metrics draft does not curren= tly allow a metric to be declared "multiplicative" in nature. > > The natural way to aggregate the link-level reliabilities into a path-l= evel reliability is by multiplication. > > Quoating from section 4.3.1 ("Link Quality Level Reliability Metric") i= n 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), th= e > 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 re= liabilities, to have same aggregated LQL values. > > 2) The beginning text in Section 4.3 (Link Reliability) identifies exte= rnal 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= =2E > > 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 li= nk > 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 b= e > 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 > > =20 --------------090706050903030505050409 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 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)

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-metric=
s-05. Not sure if people have already identified these issues.

1) I am concerned about the fact that the metrics draft does not currentl=
y allow a metric to be declared "multiplicative" in nature.

The natural way to aggregate the link-level reliabilities into a path-lev=
el 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 ma=
ke any sense. This allows two routes, with very different end-to-end reli=
abilities, to have same aggregated LQL values.

2) The beginning text in Section 4.3 (Link Reliability) identifies extern=
al and multipath interefence as the reasons for poor link reliability. I =
think that external interference should be described a little more. For C=
SMA based MAC layers, too much contention for channel access is also a ma=
jor 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:=20

"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.

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.

Thanks
Mukul

_______________________________________________
Roll mailing list
Roll@=
ietf.org
https://www.ietf.org/mailman/listinfo/roll
--------------090706050903030505050409-- --------------ms070102010702000708090709 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 GgUAoIIB0DAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMDAz MjgxNDQ3NTNaMCMGCSqGSIb3DQEJBDEWBBRzJ0J9nT+7MSZgf9nM3fKJSqTlIzBfBgkqhkiG 9w0BCQ8xUjBQMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYI KoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgYUGCSsGAQQBgjcQBDF4MHYw YjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4x LDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhB0FYYcRpgg E7/iD53vjpAfMIGHBgsqhkiG9w0BCRACCzF4oHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoT HFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25h bCBGcmVlbWFpbCBJc3N1aW5nIENBAhB0FYYcRpggE7/iD53vjpAfMA0GCSqGSIb3DQEBAQUA BIIBAKuiMtvqf0yQffD+VjuzZfc7dHG1pyKykHLGPD6wEb1ge1iweEsayA7u0ZMwsj61tXgO d+JlnB3NMtU4dI/r4tQ1thALBhMJ65wP7IK/HKoqSzZeNoNhBna2zDTaR1T9YQTWJNo+9juF 9BZ9DQv3tCGKL9HRKnEELpYFnssP8hbn4TiuSYfCcFMp1QJH0LjRhsmgUuGDPS3eaOY56Rvl Vfmue1QT1qHFJ5i/JSc/dZFcSZKhjQPtmh/DERuQPxkdFf5bxvMgprP6PKmoxsPz1OJMZGxx W3QAMiB9myau822BrhfLRiAaG3WYvv4oYnMVydDI4L07kmld3dHlE5tN6s0AAAAAAAA= --------------ms070102010702000708090709-- From yoav@yitran.com Sun Mar 28 09:31: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 6E91D3A686A for ; Sun, 28 Mar 2010 09:31:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.558 X-Spam-Level: X-Spam-Status: No, score=-2.558 tagged_above=-999 required=5 tests=[AWL=0.310, BAYES_50=0.001, 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 pQVUdapHCP+0 for ; Sun, 28 Mar 2010 09:31:28 -0700 (PDT) Received: from na3sys009aog110.obsmtp.com (na3sys009aog110.obsmtp.com [74.125.149.203]) by core3.amsl.com (Postfix) with SMTP id 5A7483A659C for ; Sun, 28 Mar 2010 09:31:25 -0700 (PDT) Received: from source ([74.125.82.41]) by na3sys009aob110.postini.com ([74.125.148.12]) with SMTP ID DSNKS6+EdwohL3Dgaho28IZ/+tGmGzhRAboQ@postini.com; Sun, 28 Mar 2010 09:31:52 PDT Received: by mail-ww0-f41.google.com with SMTP id 39so1394143wwb.28 for ; Sun, 28 Mar 2010 09:31:51 -0700 (PDT) From: Yoav Ben-Yehezkel References: <1513203275.517921269758192360.JavaMail.root@mail02.pantherlink.uwm.edu> <4BAF6C19.6040004@gridmerge.com> In-Reply-To: <4BAF6C19.6040004@gridmerge.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcrOhbB2yMZFunuvS4uZo7R2RLy24wADijPA Date: Sun, 28 Mar 2010 19:31:51 +0300 Received: by 10.216.87.18 with SMTP id x18mr2417288wee.85.1269793911152; Sun, 28 Mar 2010 09:31:51 -0700 (PDT) Message-ID: <039e01cace94$2be881e0$83b985a0$@com> To: robert.cragie@gridmerge.com, roll@ietf.org Content-Type: multipart/alternative; boundary=0016e6db29990322bc0482deef8f 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: Sun, 28 Mar 2010 16:31:30 -0000 --0016e6db29990322bc0482deef8f Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable 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 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 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 pat= hs (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 th= e 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 *From:* 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 comment= s 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) 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 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 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 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 --0016e6db29990322bc0482deef8f Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable

Hi,

=A0

Just a quick question, is 1 reports the highest o= r lowest link quality level?

=A0

It seems contradicting in the text.

=A0

"

4.3.1.=A0 The Link Quality Level Reliability Metr= ic

=A0

=A0=A0 The Link Quality Level (LQL) object is use= d to quantify the link

=A0=A0 reliability using a discrete value, from 0 to 3 where 0 indicates

=A0=A0 that the link quality level is unknown and= 1 reports the highest link

=A0=A0 quality level.=A0 The mechanisms and algorithms used to compute the LQL

=A0=A0 is implementation specific and outside of the scope of this document.

"

=A0

=A0

Whereas in the following text it says:

=A0

"

=A0=A0 The format of the LQL Type 1 sub-object is as follows

=A0

=A0=A0=A0=A0 0 1 2 3 4 5 6 7

=A0=A0=A0 +-+-+-+-+-+-+-+-+

=A0=A0=A0 |Val| Counter=A0=A0 |

=A0=A0=A0 +-+-+-+-+-+-+-+-+

=A0

=A0=A0=A0 Figure 12: LQL Type 1 sub-Object format

=A0

=A0=A0 Val: LQL value from 0 to 3 where 0 mean= s undetermined and 1 indicates

=A0=A0 the lowest link quality.

=A0

=A0=A0 Counter: number of links.

"

=A0

So =96 which is it?

=A0

Anyway, WRT to reliability and LQL - there=92s a = problem with long good paths (in the following assume 1 indicates the good link). T= he 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 definitio= ns?

=A0

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 counter= s, respectively. I don=92t think this is the intent though.

=A0

Thoughts?

=A0

Yoav

=A0

=A0

From: 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

=A0

Hi Mukul,

Multiplicative metrics make sense if the metric is a probability. If the me= tric 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, perh= aps it would be necessary to define what 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 sure=
 if people have already identified these issues.
=A0
1)=
 I am concerned about the fact that the metrics draft does not currently al=
low a metric to be declared "multiplicative" in nature.
=A0
The natural way to aggregate the link-level reliabilitie=
s into a path-level reliability is by multiplication.
=A0
Quoating from section 4.3.1 ("Link Quality Level Reliability Metric= ") in the metrics draft: 
=A0
"Aggregated LQL Value: when used an an additive met=
ric (A=3D0x00), the
=A0=A0 aggregated LQL value reports the sum o=
f all the LQL values for all
=A0=A0 links along the path.=A0 When=
 used to report a minimum (A=3D0x02), the
=A0=A0 field reports the minimum LQL value of all links along the path=
."
=A0
=A0
Aggregating the "Link Qu=
ality Levels" by adding them together does not make any sense. This al=
lows two routes, with very different end-to-end reliabilities, to have same=
 aggregated LQL values.
=A0
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 littl=
e more. For CSMA based MAC layers, too much contention for channel access i=
s also a major cause for high packet loss rates, which should be mentioned =
as well.
=A0
3) There are two typos in the draft:
=A0
= 
1. At the beginning of section 4.3.1: 
=A0
"T=
he Link Quality Level (LQL) object is used to quantify the link
=
=A0=A0 reliability using a discrete value, from 0 to 3 where 0 indicates

=A0=A0 that the link quality level is unknown and 1 reports the highes=
t link
=A0=A0 quality level."
=A0
1 shou=
ld be replaced by 3.
=A0
2. Towards the end of 4.3.2:
=A0
"The ETX object may be used as a constraint or a path me=
tric.=A0 For
=A0=A0 example, an Objective Function may indicate t=
hat the ETX must not be
=A0=A0 below some specified value."<=
/pre>
=A0
Should be: ETX must not be more than some specified value.
=A0
Thanks
Mukul
=A0
______=
_________________________________________
Roll mailing list
=

Roll@ietf.org
https://www.ietf.org/mailman/listi=
nfo/roll
=A0
=A0
--0016e6db29990322bc0482deef8f-- From hrogge@googlemail.com Sun Mar 28 09:58: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 DF6AA3A67AB for ; Sun, 28 Mar 2010 09:58:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.853 X-Spam-Level: X-Spam-Status: No, score=0.853 tagged_above=-999 required=5 tests=[AWL=-0.092, BAYES_40=-0.185, 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 BugAmET+xu4E for ; Sun, 28 Mar 2010 09:58:33 -0700 (PDT) Received: from mail-bw0-f211.google.com (mail-bw0-f211.google.com [209.85.218.211]) by core3.amsl.com (Postfix) with ESMTP id 1A0B53A659C for ; Sun, 28 Mar 2010 09:58:32 -0700 (PDT) Received: by bwz3 with SMTP id 3so9654056bwz.29 for ; Sun, 28 Mar 2010 09:58:56 -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=hGLZNmYI0loJcmkywqr8vd0+h0ZehP0dhq+AQG8TRwM=; b=msdP8to5cQPmX+GRj75FWIt6NgZ7V1FnSYu4yJkXBSRj38+iHbsRVaIq88tbDEqwoF y/zAROwN7agraIdN8aSIljNp1GC9VI+bfaDNicgjAyhnoIDFPVXglTGlGkH08GmNuGx9 rvSUGH0Q5Si66NH/k72+3MlOWOs2G6cPcetxU= 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=tTinoBxdoI5FhvVkdbBE78gesXnsizURviZpBeTk2pWoNVfbRqYJnc4aNFjGiJIZ3Z AX+wiUIMqYvR6atVqKnZmkXK13bzN7JxT7Dthk18X3uC5/wvzjneTH1xHZ7Smvpw7g6G JPCJKxGtyspQSaMLsGGd3NiDcSB2lfAU2RopU= Received: by 10.204.22.9 with SMTP id l9mr5223644bkb.49.1269795521315; Sun, 28 Mar 2010 09:58:41 -0700 (PDT) Received: from core2.localnet (static-87-79-93-195.netcologne.de [87.79.93.195]) by mx.google.com with ESMTPS id l1sm29661679bkl.14.2010.03.28.09.58.40 (version=SSLv3 cipher=RC4-MD5); Sun, 28 Mar 2010 09:58:40 -0700 (PDT) From: Henning Rogge To: roll@ietf.org Date: Sun, 28 Mar 2010 18:58:34 +0200 User-Agent: KMail/1.13.1 (Linux/2.6.33-gentoo; KDE/4.4.1; x86_64; ; ) References: <1513203275.517921269758192360.JavaMail.root@mail02.pantherlink.uwm.edu> In-Reply-To: <1513203275.517921269758192360.JavaMail.root@mail02.pantherlink.uwm.edu> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart26457004.3XghdlKa28"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <201003281858.39619.hrogge@googlemail.com> 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: Sun, 28 Mar 2010 16:58:35 -0000 --nextPart26457004.3XghdlKa28 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Am Sonntag 28 M=C3=A4rz 2010 08:36:32 schrieb Mukul Goyal: > Here are some comments on draft-ietf-roll-routing-metrics-05. Not sure if > people have already identified these issues. >=20 > 1) I am concerned about the fact that the metrics draft does not currently > allow a metric to be declared "multiplicative" in nature. >=20 > The natural way to aggregate the link-level reliabilities into a path-lev= el > reliability is by multiplication. You can transform any multiplicative metric into an additive one and the ot= her=20 way around by applying a logarithm or exponential function. 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 --nextPart26457004.3XghdlKa28 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) iEYEABECAAYFAkuvir8ACgkQcenvcwAcHWcdHQCggD1qIhd5bEBlI+8aA/EohGCj mdAAnRDjeJRktgwSJ07zPfctuKKX4qNU =P2XA -----END PGP SIGNATURE----- --nextPart26457004.3XghdlKa28-- From prvs=696ec4d62=mukul@uwm.edu Sun Mar 28 11:21: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 A299E3A68C3 for ; Sun, 28 Mar 2010 11:21:10 -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 KFrMQOzpk78o for ; Sun, 28 Mar 2010 11:21:08 -0700 (PDT) Received: from ip1mta.uwm.edu (ip1mta.uwm.edu [129.89.7.18]) by core3.amsl.com (Postfix) with ESMTP id 67CEA3A65A6 for ; Sun, 28 Mar 2010 11:21:05 -0700 (PDT) Received: from mta03.pantherlink.uwm.edu ([129.89.7.83]) by ip1mta.uwm.edu with ESMTP; 28 Mar 2010 13:21:31 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by mta03.pantherlink.uwm.edu (Postfix) with ESMTP id ACF5EC085A1; Sun, 28 Mar 2010 13:21:31 -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 NMbEhJjrxU57; Sun, 28 Mar 2010 13:21:31 -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 56714C085AC; Sun, 28 Mar 2010 13:21:31 -0500 (CDT) Date: Sun, 28 Mar 2010 13:21:31 -0500 (CDT) From: Mukul Goyal To: robert cragie Message-ID: <1416532970.593661269800491259.JavaMail.root@mail02.pantherlink.uwm.edu> In-Reply-To: <1809990827.593481269800379784.JavaMail.root@mail02.pantherlink.uwm.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [129.89.7.91] X-Mailer: Zimbra 5.0.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] 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: Sun, 28 Mar 2010 18:21:11 -0000 Hi Robert Link reliability is indeed a probability. I see LQL as a mapping from this probability to a discrete value space (in this case: 1, 2, 3). Yes, rather than multiplying reliabilities, we can simply add their log values. But, the LQL value space is too small to represent the log value with fine-enough granularity. Here is one mapping that I tried: Here, col 1 is the reliability, col 2 is ln(rel), col 3 is 3.1+ln(rel) and col 4 is the LQL 0.99 -0.010050336 3.089949664 3 0.9 -0.105360516 2.994639484 3 0.8 -0.223143551 2.876856449 3 0.7 -0.356674944 2.743325056 3 0.6 -0.510825624 2.589174376 3 0.5 -0.693147181 2.406852819 2 0.4 -0.916290732 2.183709268 2 0.3 -1.203972804 1.896027196 2 0.2 -1.609437912 1.490562088 1 0.1 -2.302585093 0.797414907 1 So, the mapping is: rel. range (0.6 and higher) => LQL 3 rel. range (between 0.2 and 0.6) => LQL 2 rel. range (0.2 and lower) => LQL 1 Suppose that we were to use this mapping. Suppose there is a path with 3 links with rel. values 0.1, 0.1 and 0.1. The sum of the log values is 3*(-2.3) = -6.9. But, if rel. 0.1 is mapped to LQL value 1, the addition of 3 LQLs is 3. When I receive a DIO with aggregated (summed) LQL 3, I dont know that this value is sum of 3 link-level LQLs 1, 1 and 1. If I were to "record", rather than aggregate, link-level LQL values, I will be able to determine e2e rel. reasonably accurately. But, summing LQL values does not help me. Summed up LQL value 3 does not tell me if the e2e rel. is 0.99 or 0.001. Now, if I were to declare "reliability" as a "multiplicative" metric and specify a mapping between rel. and LQL, I can aggregate the LQL values in the following manner: 1. Suppose I receive aggregated LQL value 3 in a DIO. 2. I map it back to the reli. range 0.6-1.0. 3. I multiply my local rel. (say 0.7) to upper/lower ends of this range (so I get range 0.42-0.7) which I map to LQL value 2 and put this value in the DIO that I send out. Thanks Mukul ----- Original Message ----- From: "Robert Cragie" To: roll@ietf.org Sent: Sunday, March 28, 2010 9:47:53 AM GMT -06:00 US/Canada Central 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) 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 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. 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. 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. Thanks Mukul _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From prvs=696ec4d62=mukul@uwm.edu Sun Mar 28 11:41: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 A8C883A681C for ; Sun, 28 Mar 2010 11:41:46 -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 7JW6lG5MsBXi for ; Sun, 28 Mar 2010 11:41:45 -0700 (PDT) Received: from ip2mta.uwm.edu (ip2mta.uwm.edu [129.89.7.20]) by core3.amsl.com (Postfix) with ESMTP id B8AD33A67E9 for ; Sun, 28 Mar 2010 11:41:45 -0700 (PDT) Received: from mta03.pantherlink.uwm.edu ([129.89.7.83]) by ip2mta.uwm.edu with ESMTP; 28 Mar 2010 13:42:11 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by mta03.pantherlink.uwm.edu (Postfix) with ESMTP id 09ED3C085A1; Sun, 28 Mar 2010 13:42:12 -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 AXRMLJ9en6Hb; Sun, 28 Mar 2010 13:42:11 -0500 (CDT) Received: from mail02.pantherlink.uwm.edu (mail02.pantherlink.uwm.edu [129.89.7.86]) by mta03.pantherlink.uwm.edu (Postfix) with ESMTP id D4A9EC085AD; Sun, 28 Mar 2010 13:42:11 -0500 (CDT) Date: Sun, 28 Mar 2010 13:42:11 -0500 (CDT) From: Mukul Goyal To: Henning Rogge Message-ID: <729879668.597241269801731792.JavaMail.root@mail02.pantherlink.uwm.edu> In-Reply-To: <1819966176.596211269801557950.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] 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: Sun, 28 Mar 2010 18:41:46 -0000 Hi Henning The problem is not how do we do multiplication - in a straight forward mann= er or by adding the log values. The issue is that one should be able to ind= icate in the "routing object" (contained in the "metrics container" inside = a "DIO") that this metric is multiplicative. Right now, I can only indicate= a metric as either additive or max or min. I would like the "A field" in the Routing Object header (Section 2 of the m= etrics draft) to include an option to specify the metric as 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 comments = on draft-ietf-roll-routing-metrics-05 Am Sonntag 28 M=C3=A4rz 2010 08:36:32 schrieb Mukul Goyal: > Here are some comments on draft-ietf-roll-routing-metrics-05. Not sure if > people have already identified these issues. >=20 > 1) I am concerned about the fact that the metrics draft does not currentl= y > allow a metric to be declared "multiplicative" in nature. >=20 > The natural way to aggregate the link-level reliabilities into a path-lev= el > reliability is by multiplication. You can transform any multiplicative metric into an additive one and the ot= her=20 way around by applying a logarithm or exponential function. Henning Rogge --=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 From richard.kelsey@ember.com Sun Mar 28 14:23: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 6A5FA3A69A6 for ; Sun, 28 Mar 2010 14:23:17 -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 NFtfZ45+8mtO for ; Sun, 28 Mar 2010 14:23:16 -0700 (PDT) Received: from EMPIRE.hq.ember.com (mail.ember.com [74.10.175.227]) by core3.amsl.com (Postfix) with ESMTP id 103E43A69A3 for ; Sun, 28 Mar 2010 14:23:15 -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); Sun, 28 Mar 2010 17:26:36 -0400 Date: Sun, 28 Mar 2010 17:20:59 -0400 Message-Id: <87vdcg5eis.fsf@kelsey-ws.hq.ember.com> To: roll@ietf.org From: Richard Kelsey X-OriginalArrivalTime: 28 Mar 2010 21:26:36.0074 (UTC) FILETIME=[586698A0:01CACEBD] Subject: [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, 28 Mar 2010 21:23:17 -0000 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. 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. 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. 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. 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 What do people think? -Richard Kelsey From jeonggil.ko@gmail.com Sun Mar 28 14:42: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 42B813A68C2 for ; Sun, 28 Mar 2010 14:42:09 -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 FMXhiIojVOYM for ; Sun, 28 Mar 2010 14:42:08 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by core3.amsl.com (Postfix) with ESMTP id 044F43A680A for ; Sun, 28 Mar 2010 14:42:07 -0700 (PDT) Received: by gyh4 with SMTP id 4so5557264gyh.31 for ; Sun, 28 Mar 2010 14:42:30 -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=3tkofOYDcuESDdNmJcd5+rWG5SQmRcq+U4nFEiayg3g=; b=LLFNXScP4XN4pemMg0ZxubiRQWcW+tq0WbwkVLyLnKuUi99BS123qU2UIvL0aBCSjL y64brf6g7WnJwW0UQH8UefIb5vwTW/xI/RFCR4sniv4jTdO178JQC6qpwLG0fBAWsrnF leaDB4la0iaIhlCLrHuMAnGE0QyJPRws4x/Z4= 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=W4hjbNDRl9t/6cOmj35TVhI08TEChcmuVp4xuoXTvYGKB4h7tz1NFpnQzrhhi4Dhb2 XYwm3RNrLPqqsDUjyE/tl+ROGKvUCeXRhEv0WgFCoEeRG6IIgsb+Xlv//JQ3oAzIDct0 S5Owy/31nv0ISq640G3469bwxnt+hG154XZzE= Received: by 10.101.180.14 with SMTP id h14mr6602478anp.34.1269812546675; Sun, 28 Mar 2010 14:42:26 -0700 (PDT) Received: from dn0a2103ef.sunet ([171.66.49.212]) by mx.google.com with ESMTPS id 6sm893457ywc.11.2010.03.28.14.42.24 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sun, 28 Mar 2010 14:42:25 -0700 (PDT) Sender: "JeongGil (John) Ko" Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: "JeongGil Ko (John)" In-Reply-To: <87vdcg5eis.fsf@kelsey-ws.hq.ember.com> Date: Sun, 28 Mar 2010 14:42:22 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <97AEE12B-4FAE-4AA6-AFE2-3BCDA85F3126@cs.jhu.edu> References: <87vdcg5eis.fsf@kelsey-ws.hq.ember.com> To: Richard Kelsey X-Mailer: Apple Mail (2.1077) 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, 28 Mar 2010 21:42:09 -0000 Richard, I agree that if we start adding downwards routes then the root will have = many sub-route (or sub-path) information that it already has. If we = decide the add the neighbor (parent) information in the DAOs do we also = add link quality estimation values for each link associated with a = parent node? Otherwise the root will have a connectivity graph of the = network (DAG) but will have no way to figure out which path is = cost-efficient to select (the root can come up with many combinations of = paths to select from)? Thanks. -John On Mar 28, 2010, at 2:20 PM, Richard Kelsey wrote: > 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 >=20 ------ JeongGil Ko (John) Ph.D. Student Department of Computer Science Johns Hopkins University http://www.cs.jhu.edu/~jgko From jpv@cisco.com Sun Mar 28 20: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 307093A686D for ; Sun, 28 Mar 2010 20:43:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.469 X-Spam-Level: X-Spam-Status: No, score=-9.469 tagged_above=-999 required=5 tests=[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 9fbSInko-CHP for ; Sun, 28 Mar 2010 20:43:27 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 1E9393A66B4 for ; Sun, 28 Mar 2010 20:43:27 -0700 (PDT) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAKO+r0utJV2c/2dsb2JhbACbKnGlfZgehQEE X-IronPort-AV: E=Sophos;i="4.51,326,1267401600"; d="scan'208";a="96893040" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rtp-iport-1.cisco.com with ESMTP; 29 Mar 2010 03:43:53 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by rcdn-core-5.cisco.com (8.14.3/8.14.3) with ESMTP id o2T3hqbS020144; Mon, 29 Mar 2010 03:43:53 GMT Received: from xfe-ams-101.cisco.com ([144.254.231.93]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 29 Mar 2010 05:43:52 +0200 Received: from ams-jvasseur-8712.cisco.com ([10.55.201.131]) by xfe-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 29 Mar 2010 05:43:51 +0200 Message-Id: From: JP Vasseur To: ROLL WG , "dominique.barthel@orange-ftgroup.com> In-Reply-To: <4de5bea503af5a5b2db5611105cbed13@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: Mon, 29 Mar 2010 05:43:51 +0200 References: <8E09C72DBC577D489F13A71228C0B7BF010FEFE9@ftrdmel0.rd.francetelecom.fr> <5C4CCBDE-4397-4797-89CD-81C0EA59E1B1@cs.stanford.edu> <8E09C72DBC577D489F13A71228C0B7BF010FF65D@ftrdmel0.rd.francetelecom.fr> <4de5bea503af5a5b2db5611105cbed13@mail.gmail.com> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 29 Mar 2010 03:43:51.0937 (UTC) FILETIME=[0C6D2F10:01CACEF2] Subject: Re: [Roll] Options in DIS X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 29 Mar 2010 03:43:28 -0000 Dear all, Since there is a consensus in adding the possibility to have TLVs in the future in the DIS I opened a ticket. The idea would be to simply have an empty body with no TLV for the moment but that could in the future carry TLVs. Thanks. JP. On Mar 28, 2010, at 9:44 AM, Yoav Ben-Yehezkel wrote: > Hi, > > To my understanding, DIS's are not so commonly used. > It could be that introducing the DIS fields to all packets would be > the > simplest solution. > > Thanks, > Yoav > > > > -----Original Message----- > From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf > Of > Philip Levis > Sent: Tuesday, March 23, 2010 5:09 PM > To: Matteo Paris > Cc: roll@ietf.org > Subject: Re: [Roll] Options in DIS > > > On Mar 23, 2010, at 6:35 AM, Matteo Paris wrote: > >> >> Hi Phil, >> >> The concern that I raised did not have to do with trying to further > suppress DIO messages within a single DODAG beyond what is provided by > Trickle. >> >> Rather, I described the scenario in which there are multiple DODAGS > (dozens) in a dense network (eg, hundreds of nodes within radio > range of > each other). It is often the case that the node sending the DIS has > specific information about which DODAG it is interested in, in the > form of > destination prefixes, dag ids, instance ids, etc. If this information > were contained in the DIS, the filtering could happen prior to > transmission of DIOs, saving the network from significant unneccessary > disruption. >> >> What do you think? >> > > I think this makes total sense. But should it be a standard DIS > field, or > a DIS option? If a standard field there will need to be an all > IDs/broadcast value. > > 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 trac@tools.ietf.org Sun Mar 28 20:46: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 3567F3A686D for ; Sun, 28 Mar 2010 20:46:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.944 X-Spam-Level: X-Spam-Status: No, score=-100.944 tagged_above=-999 required=5 tests=[AWL=0.526, 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 y7+zs6HHCpjA for ; Sun, 28 Mar 2010 20:46:15 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 9148D3A6805 for ; Sun, 28 Mar 2010 20:46:15 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1Nw5w1-0003vn-AI; Sun, 28 Mar 2010 20:46:41 -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: wintert@acm.org, jpv@cisco.com X-Trac-Project: roll Date: Mon, 29 Mar 2010 03:46:41 -0000 X-URL: http://tools.ietf.org/wg/roll/ X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/roll/trac/ticket/29 Message-ID: <055.b43390f66a61cbc1df0908a0b90c9553@tools.ietf.org> X-Trac-Ticket-ID: 29 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: wintert@acm.org, 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] #29: DIS packet format 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, 29 Mar 2010 03:46:16 -0000 #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 From Matteo.Paris@ember.com Sun Mar 28 21: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 C72E73A68A2 for ; Sun, 28 Mar 2010 21:49:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.829 X-Spam-Level: * X-Spam-Status: No, score=1.829 tagged_above=-999 required=5 tests=[AWL=-0.698, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3W1n1Rcjbilv for ; Sun, 28 Mar 2010 21:49:25 -0700 (PDT) Received: from EMPIRE.hq.ember.com (mail.ember.com [74.10.175.227]) by core3.amsl.com (Postfix) with ESMTP id 122143A6876 for ; Sun, 28 Mar 2010 21:49:24 -0700 (PDT) Received: from [10.5.50.215] ([192.168.90.52]) by EMPIRE.hq.ember.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 29 Mar 2010 00:52:45 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <729879668.597241269801731792.JavaMail.root@mail02.pantherlink.uwm.edu> References: <729879668.597241269801731792.JavaMail.root@mail02.pantherlink.uwm.edu> Date: Mon, 29 Mar 2010 00:49:47 -0400 To: Mukul Goyal From: Matteo Paris Content-Type: text/plain; charset="iso-8859-1" ; format="flowed" Content-Transfer-Encoding: quoted-printable X-OriginalArrivalTime: 29 Mar 2010 04:52:45.0652 (UTC) FILETIME=[AC500940:01CACEFB] 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: Mon, 29 Mar 2010 04:49:26 -0000 Hi Mukul, I agree that the available flags do not cover all=20 the possibilities for metric calculations.=20 However, I believe we should eliminate the flags=20 rather than extend them. In order to participate in routing, a node must=20 implement the Objective Function, which already=20 defines how to compute and propagate the metric.=20 Thus for nodes implementing the OF, the common=20 flags are redundant. Nodes not implementing the=20 metric do not know what the metric is and are not=20 allowed to propagate the metric, so the flags are=20 of no use to them. I believe the thinking behind the flags was that=20 it would allow any node to do something useful=20 with the metric container, even if it did not=20 implement the OF. After discussion on the list,=20 this concept was ruled out, in favor of limiting=20 such nodes to join as leaves. So now, the flags=20 no longer serve a purpose. Matteo At 1:42 PM -0500 3/28/10, Mukul Goyal wrote: >Hi Henning > >The problem is not how do we do multiplication -=20 >in a straight forward manner or by adding the=20 >log values. The issue is that one should be able=20 >to indicate in the "routing object" (contained=20 >in the "metrics container" inside a "DIO") that=20 >this metric is multiplicative. Right now, I can=20 >only indicate a metric as either additive or max=20 >or min. > >I would like the "A field" in the Routing Object=20 >header (Section 2 of the metrics draft) to=20 >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=20 >metrics and other comments on=20 >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 sure i= f >> people have already identified these issues. >> >> 1) I am concerned about the fact that the metrics draft does not current= ly >> allow a metric to be declared "multiplicative" in nature. >> >> The natural way to aggregate the link-level reliabilities into a path-le= vel >> reliability is by multiplication. >You can transform any multiplicative metric into an additive one and the ot= her >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 From pal@cs.stanford.edu Sun Mar 28 21:51: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 651263A6876 for ; Sun, 28 Mar 2010 21:51:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.912 X-Spam-Level: X-Spam-Status: No, score=-4.912 tagged_above=-999 required=5 tests=[AWL=0.557, 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 2z7BmwKQImbP for ; Sun, 28 Mar 2010 21:51: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 AFEA73A6804 for ; Sun, 28 Mar 2010 21:51:36 -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 1Nw6xH-0008UW-N7; Sun, 28 Mar 2010 21:52:03 -0700 In-Reply-To: References: <8E09C72DBC577D489F13A71228C0B7BF010FEFE9@ftrdmel0.rd.francetelecom.fr> <5C4CCBDE-4397-4797-89CD-81C0EA59E1B1@cs.stanford.edu> <8E09C72DBC577D489F13A71228C0B7BF010FF65D@ftrdmel0.rd.francetelecom.fr> <4de5bea503af5a5b2db5611105cbed13@mail.gmail.com> 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: Sun, 28 Mar 2010 21:50:08 -0700 To: JP Vasseur X-Mailer: Apple Mail (2.753.1) X-Scan-Signature: 9c8d7c79e82d9ccd3af9a51b4d3246f3 Cc: ROLL WG Subject: Re: [Roll] Options in DIS X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 29 Mar 2010 04:51:37 -0000 On Mar 28, 2010, at 8:43 PM, JP Vasseur wrote: > Dear all, > > Since there is a consensus in adding the possibility to have TLVs > in the future in the DIS > I opened a ticket. The idea would be to simply have an empty body > with no TLV for the > moment but that could in the future carry TLVs. > > Thanks. Remember, code size is an issue: arbitrary options are a bad idea. We should concretely specify the expected common options (which seem to be basic predicates on whom should respond). Phil From prvs=6972f6f3a=mukul@uwm.edu Sun Mar 28 21:57: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 CFE363A6955 for ; Sun, 28 Mar 2010 21:57:04 -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 80Rma7uXGICg for ; Sun, 28 Mar 2010 21:57:04 -0700 (PDT) Received: from ip2mta.uwm.edu (ip2mta.uwm.edu [129.89.7.20]) by core3.amsl.com (Postfix) with ESMTP id 0B9523A691F for ; Sun, 28 Mar 2010 21:57:03 -0700 (PDT) Received: from mta03.pantherlink.uwm.edu ([129.89.7.83]) by ip2mta.uwm.edu with ESMTP; 28 Mar 2010 23:57:31 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by mta03.pantherlink.uwm.edu (Postfix) with ESMTP id 34749C085AD for ; Sun, 28 Mar 2010 23:57:31 -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 xf9OeZz4pfvR for ; Sun, 28 Mar 2010 23:57:31 -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 11743C085AC for ; Sun, 28 Mar 2010 23:57:31 -0500 (CDT) Date: Sun, 28 Mar 2010 23:57:29 -0500 (CDT) From: Mukul Goyal To: roll Message-ID: <1130942942.736211269838649762.JavaMail.root@mail02.pantherlink.uwm.edu> In-Reply-To: <1848278505.734981269838238602.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 Subject: [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: Mon, 29 Mar 2010 04:57:04 -0000 Hi all I was wondering if there was ever a discussion on the mailing list or else where regarding why is it difficult to support mixed mode operation. We know from the WG meeting at Anaheim that mixed mode operation is difficult to support but it is not clear why. Not supporting mixed mode operation is a major climb down for RPL. This means that the introduction of even a single non-storing router can turn a hitherto storing LLN into a non-storing one thereby causing a major upheaval in the network as all the DAOs now have to reach the root. Thanks Mukul From pthubert@cisco.com Sun Mar 28 22:16: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 37F883A687E for ; Sun, 28 Mar 2010 22:16:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.402 X-Spam-Level: X-Spam-Status: No, score=-7.402 tagged_above=-999 required=5 tests=[AWL=2.067, 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 vS11Mjp+jrIZ for ; Sun, 28 Mar 2010 22:15:55 -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 4D1AE3A6942 for ; Sun, 28 Mar 2010 22:15:54 -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: AvsEAG/Ur0urR7H+/2dsb2JhbACbKnGlW5gmhQEEjho X-IronPort-AV: E=Sophos;i="4.51,326,1267401600"; d="scan'208";a="106858458" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-4.cisco.com with ESMTP; 29 Mar 2010 05:16:20 +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 o2T5GJ2h025417; Mon, 29 Mar 2010 05:16:20 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, 29 Mar 2010 07:16: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, 29 Mar 2010 07:16:14 +0200 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D0188AAE1@XMB-AMS-107.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] Options in DIS Thread-Index: AcrKmtZjbD6BDfzCQ5S1SgUMzYhZHQEY662g References: <8E09C72DBC577D489F13A71228C0B7BF010FEFE9@ftrdmel0.rd.francetelecom.fr><5C4CCBDE-4397-4797-89CD-81C0EA59E1B1@cs.stanford.edu><8E09C72DBC577D489F13A71228C0B7BF010FF65D@ftrdmel0.rd.francetelecom.fr> From: "Pascal Thubert (pthubert)" To: "Philip Levis" , "Matteo Paris" X-OriginalArrivalTime: 29 Mar 2010 05:16:19.0211 (UTC) FILETIME=[F6DC05B0:01CACEFE] Cc: roll@ietf.org Subject: Re: [Roll] Options in DIS X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 29 Mar 2010 05:16:01 -0000 I agree with this. There are obvious fields that could be in the base, without even an option. For instance, root id, instance id, or OF, if either is known.=20 If we can get a consensus on adding those in the base DIS, this can be added in the 08 respin. Cheers, Pascal > -----Original Message----- > From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of > Philip Levis > Sent: Tuesday, March 23, 2010 4:09 PM > To: Matteo Paris > Cc: roll@ietf.org > Subject: Re: [Roll] Options in DIS >=20 >=20 > On Mar 23, 2010, at 6:35 AM, Matteo Paris wrote: >=20 > > > > Hi Phil, > > > > The concern that I raised did not have to do with trying to further suppress > DIO messages within a single DODAG beyond what is provided by Trickle. > > > > Rather, I described the scenario in which there are multiple DODAGS > (dozens) in a dense network (eg, hundreds of nodes within radio range of > each other). It is often the case that the node sending the DIS has specific > information about which DODAG it is interested in, in the form of destination > prefixes, dag ids, instance ids, etc. If this information were contained in the > DIS, the filtering could happen prior to transmission of DIOs, saving the > network from significant unneccessary disruption. > > > > What do you think? > > >=20 > I think this makes total sense. But should it be a standard DIS field, or a DIS > option? If a standard field there will need to be an all IDs/broadcast value. >=20 > Phil >=20 > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From pthubert@cisco.com Sun Mar 28 22:44: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 421BD3A6817 for ; Sun, 28 Mar 2010 22:44:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.619 X-Spam-Level: X-Spam-Status: No, score=-2.619 tagged_above=-999 required=5 tests=[AWL=-3.750, 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 7L18TOotRW3a for ; Sun, 28 Mar 2010 22:44:13 -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 4E0173A67B4 for ; Sun, 28 Mar 2010 22:44:12 -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: AvAAANDar0uQ/uCWe2dsb2JhbACbKhUBAQsLIgYcpVGYJoUBBI4a X-IronPort-AV: E=Sophos;i="4.51,327,1267401600"; d="scan'208";a="4907262" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-2.cisco.com with ESMTP; 29 Mar 2010 05:10:02 +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 o2T5icoH026337; Mon, 29 Mar 2010 05:44:38 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, 29 Mar 2010 07:44:38 +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, 29 Mar 2010 07:44:34 +0200 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D0188AAE9@XMB-AMS-107.cisco.com> In-Reply-To: <97AEE12B-4FAE-4AA6-AFE2-3BCDA85F3126@cs.jhu.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] proposal for DAOs in non-caching DODAGs Thread-Index: AcrOv5fsnmnec492Qy2Zhkv5fvLB4wAP65Mw References: <87vdcg5eis.fsf@kelsey-ws.hq.ember.com> <97AEE12B-4FAE-4AA6-AFE2-3BCDA85F3126@cs.jhu.edu> From: "Pascal Thubert (pthubert)" To: "JeongGil Ko (John)" , "Richard Kelsey" X-OriginalArrivalTime: 29 Mar 2010 05:44:38.0192 (UTC) FILETIME=[EB87F300:01CACF02] 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, 29 Mar 2010 05:44:16 -0000 Hi John: Obviously, having multiple parents enables the root to compute multiple paths down to the node. So your proposal is tempting. But beware, this is a slippery slope towards centralized Link State computation and away from the RPL core design, and we can't be designing 2 protocols, by charter. The RPL design is that the choice of the best parents belongs to the OF in the node, not the root. Richard's proposal centralizes in the root the forwarding decision along the DAG that happens hop by hop with stateful DAOs, but the routing states are built in the exact same fashion whether it is stateful or stateless, by having each node select a set of preferred DAO parents. Note that we do not specify how a node selects the next hop between multiple DAO children in the stateful mode. In the same fashion, we do not specify how the root makes the multi hop decision. My suggestion to address your problem would be that the OF in the node provides more info on how it orders the parents, maybe by setting a preference level (like 0-3) for each parent in the source route DAO. The root retains the possibility to build multiple non-overlapping path, do load balancing, signal to L2 when L2 paths/circuits need to be enabled, etc... We have not made the step towards a centralized routing model.=20 Cheers, Pascal > -----Original Message----- > From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of > JeongGil Ko (John) > Sent: Sunday, March 28, 2010 11:42 PM > To: Richard Kelsey > Cc: roll@ietf.org > Subject: Re: [Roll] proposal for DAOs in non-caching DODAGs >=20 > Richard, >=20 > I agree that if we start adding downwards routes then the root will have > many sub-route (or sub-path) information that it already has. If we decide > the add the neighbor (parent) information in the DAOs do we also add link > quality estimation values for each link associated with a parent node? > Otherwise the root will have a connectivity graph of the network (DAG) but > will have no way to figure out which path is cost-efficient to select (the root > can come up with many combinations of paths to select from)? >=20 > Thanks. >=20 > -John >=20 > On Mar 28, 2010, at 2:20 PM, Richard Kelsey wrote: >=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. > > > > 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. > > > > 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. > > > > 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. > > > > 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 > > > > What do people think? > > -Richard Kelsey > > _______________________________________________ > > 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 jeonggil.ko@gmail.com Sun Mar 28 23:03: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 54C1C3A672E for ; Sun, 28 Mar 2010 23:03:15 -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 AsaBAX+gP4Ne for ; Sun, 28 Mar 2010 23:03:14 -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 94A1B3A691E for ; Sun, 28 Mar 2010 23:03:11 -0700 (PDT) Received: by vws12 with SMTP id 12so2942225vws.31 for ; Sun, 28 Mar 2010 23:03:36 -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=6ascUKoJn9yX+MHwbtK1CN8mDqR21Msl+t3w8tdYuVI=; b=NtLeSNFnVBIcaXA/xsn6HyTcyGaPHHLZJtR6bS8l6DMvaWev2JU5xMgAF3Lw1Wvw0N zqERSYjqDNLHB1LwEV/wv7bT+1uL3BWa42DvHyrkLZ5RypdCcAtPP86QEm/f1Yq3mCUq 9GARvkNnQ8sa80juZfe086UVaIC2gg05EUKtc= 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=jwEP+Kh+mjtN+s0GOvcaXgKlqd4sImNJV2X/6vgVLzFRTPAhsP2q2XeM2bGIETrBod msr8zbP4xcjFYvVH5DidRUXy+O32fZx2Z6+tJyZ4XYNbl69a0PKP93Mi2NGHQ3KqC0n3 ML7WJrc7xNK+0PF/MDoHPYnbWD9LAfpy9jzTs= Received: by 10.220.128.30 with SMTP id i30mr2933521vcs.28.1269842615688; Sun, 28 Mar 2010 23:03:35 -0700 (PDT) Received: from [192.168.1.103] ([76.14.51.89]) by mx.google.com with ESMTPS id 21sm88790222vws.2.2010.03.28.23.03.33 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sun, 28 Mar 2010 23:03:34 -0700 (PDT) Sender: "JeongGil (John) Ko" Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: "JeongGil Ko (John)" In-Reply-To: <6A2A459175DABE4BB11DE2026AA50A5D0188AAE9@XMB-AMS-107.cisco.com> Date: Sun, 28 Mar 2010 23:03:32 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <68E6C8D6-65C6-4ED7-9927-1DEEB078A404@cs.jhu.edu> References: <87vdcg5eis.fsf@kelsey-ws.hq.ember.com> <97AEE12B-4FAE-4AA6-AFE2-3BCDA85F3126@cs.jhu.edu> <6A2A459175DABE4BB11DE2026AA50A5D0188AAE9@XMB-AMS-107.cisco.com> To: Pascal Thubert (pthubert) X-Mailer: Apple Mail (2.1077) 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, 29 Mar 2010 06:03:15 -0000 Hi Pascal, I see your point. One question, that confuses me is how the set of = 'preferred DAO parents' are determined. Is this set different from the = preferred parent set in DIOs? I guess another way of asking is to ask is = how the DAORank is defined and computed (this question was asked = previously but I didn't really get a clear answer). Will each node that = initiates a DAO for a specific prefix be DAORank =3D 1 and the rank = computation continue just like the DIO process? In this case is it true = that each node may need to maintain different DAORank values for many = different prefixes? Thanks! -John On Mar 28, 2010, at 10:44 PM, Pascal Thubert (pthubert) wrote: > Hi John: >=20 > Obviously, having multiple parents enables the root to compute = multiple > paths down to the node. So your proposal is tempting. But beware, this > is a slippery slope towards centralized Link State computation and = away > from the RPL core design, and we can't be designing 2 protocols, by > charter. >=20 > The RPL design is that the choice of the best parents belongs to the = OF > in the node, not the root. Richard's proposal centralizes in the root > the forwarding decision along the DAG that happens hop by hop with > stateful DAOs, but the routing states are built in the exact same > fashion whether it is stateful or stateless, by having each node = select > a set of preferred DAO parents. Note that we do not specify how a node > selects the next hop between multiple DAO children in the stateful = mode. > In the same fashion, we do not specify how the root makes the multi = hop > decision. >=20 > My suggestion to address your problem would be that the OF in the node > provides more info on how it orders the parents, maybe by setting a > preference level (like 0-3) for each parent in the source route DAO. = The > root retains the possibility to build multiple non-overlapping path, = do > load balancing, signal to L2 when L2 paths/circuits need to be = enabled, > etc... We have not made the step towards a centralized routing model.=20= >=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: Sunday, March 28, 2010 11:42 PM >> To: Richard Kelsey >> Cc: roll@ietf.org >> Subject: Re: [Roll] proposal for DAOs in non-caching DODAGs >>=20 >> Richard, >>=20 >> I agree that if we start adding downwards routes then the root will > have >> many sub-route (or sub-path) information that it already has. If we > decide >> the add the neighbor (parent) information in the DAOs do we also add > link >> quality estimation values for each link associated with a parent = node? >> Otherwise the root will have a connectivity graph of the network = (DAG) > but >> will have no way to figure out which path is cost-efficient to select > (the root >> can come up with many combinations of paths to select from)? >>=20 >> Thanks. >>=20 >> -John >>=20 >> On Mar 28, 2010, at 2:20 PM, Richard Kelsey wrote: >>=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 >>>=20 >>=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 prvs=6972f6f3a=mukul@uwm.edu Sun Mar 28 23:17: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 24C643A68D7 for ; Sun, 28 Mar 2010 23:17:06 -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 Nzjgre04Uzzv for ; Sun, 28 Mar 2010 23:17:04 -0700 (PDT) Received: from ip2mta.uwm.edu (ip2mta.uwm.edu [129.89.7.20]) by core3.amsl.com (Postfix) with ESMTP id 5E36A3A681B for ; Sun, 28 Mar 2010 23:17:04 -0700 (PDT) Received: from mta03.pantherlink.uwm.edu ([129.89.7.83]) by ip2mta.uwm.edu with ESMTP; 29 Mar 2010 01:17:31 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by mta03.pantherlink.uwm.edu (Postfix) with ESMTP id 99B64C085D5; Mon, 29 Mar 2010 01:17:31 -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 5UGrCvdZoXbm; Mon, 29 Mar 2010 01:17:31 -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 34B60C085D0; Mon, 29 Mar 2010 01:17:31 -0500 (CDT) Date: Mon, 29 Mar 2010 01:17:31 -0500 (CDT) From: Mukul Goyal To: "JeongGil Ko (John)" Message-ID: <1005359930.745161269843451128.JavaMail.root@mail02.pantherlink.uwm.edu> In-Reply-To: <2011780176.744741269843206812.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: Mon, 29 Mar 2010 06:17:06 -0000 A related question that has been bugging me for a while is: Does RPL assume routing metrics to be essentially symmetric in nature? When node B receives a DIO from node A about a DAG with root R, it can choose whether link B->A is going to be part of the route from B to R. Node B can use its knowledge of link cost B->A in making this decision. But when node B picks parent A as a DAO parent, it is deciding that link A->B can be on the path from root R to itself. But B does not know the link cost A->B unless it is assumed to be same as link cost B->A!!! If RPL indeed assumes symmetrical link costs, it would be good to admit it in the draft explicitly. Thanks Mukul ----- Original Message ----- From: "JeongGil Ko (John)" To: "Pascal Thubert (pthubert)" Cc: roll@ietf.org Sent: Monday, March 29, 2010 1:03:32 AM GMT -06:00 US/Canada Central Subject: Re: [Roll] proposal for DAOs in non-caching DODAGs Hi Pascal, I see your point. One question, that confuses me is how the set of 'preferred DAO parents' are determined. Is this set different from the preferred parent set in DIOs? I guess another way of asking is to ask is how the DAORank is defined and computed (this question was asked previously but I didn't really get a clear answer). Will each node that initiates a DAO for a specific prefix be DAORank = 1 and the rank computation continue just like the DIO process? In this case is it true that each node may need to maintain different DAORank values for many different prefixes? Thanks! -John On Mar 28, 2010, at 10:44 PM, Pascal Thubert (pthubert) wrote: > Hi John: > > Obviously, having multiple parents enables the root to compute multiple > paths down to the node. So your proposal is tempting. But beware, this > is a slippery slope towards centralized Link State computation and away > from the RPL core design, and we can't be designing 2 protocols, by > charter. > > The RPL design is that the choice of the best parents belongs to the OF > in the node, not the root. Richard's proposal centralizes in the root > the forwarding decision along the DAG that happens hop by hop with > stateful DAOs, but the routing states are built in the exact same > fashion whether it is stateful or stateless, by having each node select > a set of preferred DAO parents. Note that we do not specify how a node > selects the next hop between multiple DAO children in the stateful mode. > In the same fashion, we do not specify how the root makes the multi hop > decision. > > My suggestion to address your problem would be that the OF in the node > provides more info on how it orders the parents, maybe by setting a > preference level (like 0-3) for each parent in the source route DAO. The > root retains the possibility to build multiple non-overlapping path, do > load balancing, signal to L2 when L2 paths/circuits need to be enabled, > etc... We have not made the step towards a centralized routing model. > > Cheers, > > Pascal > > >> -----Original Message----- >> From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf > Of >> JeongGil Ko (John) >> Sent: Sunday, March 28, 2010 11:42 PM >> To: Richard Kelsey >> Cc: roll@ietf.org >> Subject: Re: [Roll] proposal for DAOs in non-caching DODAGs >> >> Richard, >> >> I agree that if we start adding downwards routes then the root will > have >> many sub-route (or sub-path) information that it already has. If we > decide >> the add the neighbor (parent) information in the DAOs do we also add > link >> quality estimation values for each link associated with a parent node? >> Otherwise the root will have a connectivity graph of the network (DAG) > but >> will have no way to figure out which path is cost-efficient to select > (the root >> can come up with many combinations of paths to select from)? >> >> Thanks. >> >> -John >> >> On Mar 28, 2010, at 2:20 PM, Richard Kelsey wrote: >> >>> 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. >>> >>> 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. >>> >>> 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. >>> >>> 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. >>> >>> 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 >>> >>> What do people think? >>> -Richard Kelsey >>> _______________________________________________ >>> 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 > ------ 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 jpv@cisco.com Sun Mar 28 23:28: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 A1BC43A681F for ; Sun, 28 Mar 2010 23:28:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.169 X-Spam-Level: X-Spam-Status: No, score=-8.169 tagged_above=-999 required=5 tests=[AWL=-1.300, BAYES_50=0.001, 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 0F87cgCFJ97z for ; Sun, 28 Mar 2010 23:28:40 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 901CD3A680A for ; Sun, 28 Mar 2010 23:28:39 -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: AvAAAIvlr0uQ/uCWe2dsb2JhbACbKRUBAQsLIgYcpUeYLYUBBI4a X-IronPort-AV: E=Sophos;i="4.51,327,1267401600"; d="scan'208";a="58672934" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 29 Mar 2010 06:29:05 +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 o2T6T55A002902; Mon, 29 Mar 2010 06:29:05 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); Mon, 29 Mar 2010 08:29:05 +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); Mon, 29 Mar 2010 08:29:04 +0200 Message-Id: From: JP Vasseur To: Mukul Goyal In-Reply-To: <1005359930.745161269843451128.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: Mon, 29 Mar 2010 08:29:03 +0200 References: <1005359930.745161269843451128.JavaMail.root@mail02.pantherlink.uwm.edu> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 29 Mar 2010 06:29:04.0956 (UTC) FILETIME=[210BD7C0:01CACF09] 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, 29 Mar 2010 06:28:41 -0000 On Mar 29, 2010, at 8:17 AM, Mukul Goyal wrote: > A related question that has been bugging me for a while is: > > Does RPL assume routing metrics to be essentially symmetric in nature? > > When node B receives a DIO from node A about a DAG with root R, it > can choose whether link B->A is going to be part of the route from B > to R. Node B can use its knowledge of link cost B->A in making this > decision. > > But when node B picks parent A as a DAO parent, it is deciding that > link A->B can be on the path from root R to itself. But B does not > know the link cost A->B unless it is assumed to be same as link cost > B->A!!! > > If RPL indeed assumes symmetrical link costs, it would be good to > admit it in the draft explicitly. You can add the DAG metric container in both the DIO and DAO. > > Thanks > Mukul > > ----- Original Message ----- > From: "JeongGil Ko (John)" > To: "Pascal Thubert (pthubert)" > Cc: roll@ietf.org > Sent: Monday, March 29, 2010 1:03:32 AM GMT -06:00 US/Canada Central > Subject: Re: [Roll] proposal for DAOs in non-caching DODAGs > > Hi Pascal, > > I see your point. One question, that confuses me is how the set of > 'preferred DAO parents' are determined. Is this set different from > the preferred parent set in DIOs? I guess another way of asking is > to ask is how the DAORank is defined and computed (this question was > asked previously but I didn't really get a clear answer). Will each > node that initiates a DAO for a specific prefix be DAORank = 1 and > the rank computation continue just like the DIO process? In this > case is it true that each node may need to maintain different > DAORank values for many different prefixes? > > Thanks! > > -John > > On Mar 28, 2010, at 10:44 PM, Pascal Thubert (pthubert) wrote: > >> Hi John: >> >> Obviously, having multiple parents enables the root to compute >> multiple >> paths down to the node. So your proposal is tempting. But beware, >> this >> is a slippery slope towards centralized Link State computation and >> away >> from the RPL core design, and we can't be designing 2 protocols, by >> charter. >> >> The RPL design is that the choice of the best parents belongs to >> the OF >> in the node, not the root. Richard's proposal centralizes in the root >> the forwarding decision along the DAG that happens hop by hop with >> stateful DAOs, but the routing states are built in the exact same >> fashion whether it is stateful or stateless, by having each node >> select >> a set of preferred DAO parents. Note that we do not specify how a >> node >> selects the next hop between multiple DAO children in the stateful >> mode. >> In the same fashion, we do not specify how the root makes the multi >> hop >> decision. >> >> My suggestion to address your problem would be that the OF in the >> node >> provides more info on how it orders the parents, maybe by setting a >> preference level (like 0-3) for each parent in the source route >> DAO. The >> root retains the possibility to build multiple non-overlapping >> path, do >> load balancing, signal to L2 when L2 paths/circuits need to be >> enabled, >> etc... We have not made the step towards a centralized routing model. >> >> Cheers, >> >> Pascal >> >> >>> -----Original Message----- >>> From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf >> Of >>> JeongGil Ko (John) >>> Sent: Sunday, March 28, 2010 11:42 PM >>> To: Richard Kelsey >>> Cc: roll@ietf.org >>> Subject: Re: [Roll] proposal for DAOs in non-caching DODAGs >>> >>> Richard, >>> >>> I agree that if we start adding downwards routes then the root will >> have >>> many sub-route (or sub-path) information that it already has. If we >> decide >>> the add the neighbor (parent) information in the DAOs do we also add >> link >>> quality estimation values for each link associated with a parent >>> node? >>> Otherwise the root will have a connectivity graph of the network >>> (DAG) >> but >>> will have no way to figure out which path is cost-efficient to >>> select >> (the root >>> can come up with many combinations of paths to select from)? >>> >>> Thanks. >>> >>> -John >>> >>> On Mar 28, 2010, at 2:20 PM, Richard Kelsey wrote: >>> >>>> 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. >>>> >>>> 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. >>>> >>>> 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. >>>> >>>> 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. >>>> >>>> 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 >>>> >>>> What do people think? >>>> -Richard Kelsey >>>> _______________________________________________ >>>> 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 >> > > ------ > 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 pthubert@cisco.com Sun Mar 28 23:33: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 2F5A53A683B for ; Sun, 28 Mar 2010 23:33:13 -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=[AWL=-1.700, 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 aJUQnrpcKVru for ; Sun, 28 Mar 2010 23:33: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 4EC113A680A for ; Sun, 28 Mar 2010 23:33: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: AvAAAI7mr0uQ/uCWe2dsb2JhbACbKRUBAQsLIgYcpUeYMoUBBI4a X-IronPort-AV: E=Sophos;i="4.51,327,1267401600"; d="scan'208";a="4908336" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-2.cisco.com with ESMTP; 29 Mar 2010 05:59: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 o2T6XbZl003647; Mon, 29 Mar 2010 06:33:37 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, 29 Mar 2010 08:33: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: Mon, 29 Mar 2010 08:33:27 +0200 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D0188AAFB@XMB-AMS-107.cisco.com> In-Reply-To: <68E6C8D6-65C6-4ED7-9927-1DEEB078A404@cs.jhu.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] proposal for DAOs in non-caching DODAGs Thread-Index: AcrPBZhM1eTe7mwEQYWYbf4/FDhErAAAMQqg 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> From: "Pascal Thubert (pthubert)" To: "JeongGil Ko (John)" X-OriginalArrivalTime: 29 Mar 2010 06:33:37.0586 (UTC) FILETIME=[C38BE120:01CACF09] 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, 29 Mar 2010 06:33:13 -0000 Hi John: I think I see what you're saying. If the metrics are asymmetrical, then it might occur that the DAO parents set is not the exact same as DIO parent set. A node would prefer a DAO parent for which the metrics from the root to the node are optimal. So theoretically following the preferred parent path provides the best metrics without using the DAO rank.=20 The current spec enables the OF in a node to compute a DAO Rank based on the metrics option pretty much like a DIO Rank would be computed using a DAO DAG Metric Container. This was introduced at some point along the path and provides an additional capability to rate non preferred paths. I figure that you're willing to emulate that in the source route DAO My take is that we have already added too much complexity even though we made it optional. I'd rather remove the DAO DAG Metric Container. But in any fashion I have to agree with your desire to make things consistent. Then again, slippery slope towards link state... Pascal > -----Original Message----- > From: JeongGil (John) Ko [mailto:jeonggil.ko@gmail.com] On Behalf Of > JeongGil Ko (John) > Sent: Monday, March 29, 2010 8:04 AM > To: Pascal Thubert (pthubert) > Cc: Richard Kelsey; roll@ietf.org > Subject: Re: [Roll] proposal for DAOs in non-caching DODAGs >=20 > Hi Pascal, >=20 > I see your point. One question, that confuses me is how the set of 'preferred > DAO parents' are determined. Is this set different from the preferred parent > set in DIOs? I guess another way of asking is to ask is how the DAORank is > defined and computed (this question was asked previously but I didn't really > get a clear answer). Will each node that initiates a DAO for a specific prefix be > DAORank =3D 1 and the rank computation continue just like the DIO process? In > this case is it true that each node may need to maintain different DAORank > values for many different prefixes? >=20 > Thanks! >=20 > -John >=20 > On Mar 28, 2010, at 10:44 PM, Pascal Thubert (pthubert) wrote: >=20 > > Hi John: > > > > Obviously, having multiple parents enables the root to compute > > multiple paths down to the node. So your proposal is tempting. But > > beware, this is a slippery slope towards centralized Link State > > computation and away from the RPL core design, and we can't be > > designing 2 protocols, by charter. > > > > The RPL design is that the choice of the best parents belongs to the > > OF in the node, not the root. Richard's proposal centralizes in the > > root the forwarding decision along the DAG that happens hop by hop > > with stateful DAOs, but the routing states are built in the exact > > same fashion whether it is stateful or stateless, by having each node > > select a set of preferred DAO parents. Note that we do not specify how > > a node selects the next hop between multiple DAO children in the stateful > mode. > > In the same fashion, we do not specify how the root makes the multi > > hop decision. > > > > My suggestion to address your problem would be that the OF in the node > > provides more info on how it orders the parents, maybe by setting a > > preference level (like 0-3) for each parent in the source route DAO. > > The root retains the possibility to build multiple non-overlapping > > path, do load balancing, signal to L2 when L2 paths/circuits need to > > be enabled, etc... We have not made the step towards a centralized > routing model. > > > > Cheers, > > > > Pascal > > > > > >> -----Original Message----- > >> From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf > > Of > >> JeongGil Ko (John) > >> Sent: Sunday, March 28, 2010 11:42 PM > >> To: Richard Kelsey > >> Cc: roll@ietf.org > >> Subject: Re: [Roll] proposal for DAOs in non-caching DODAGs > >> > >> Richard, > >> > >> I agree that if we start adding downwards routes then the root will > > have > >> many sub-route (or sub-path) information that it already has. If we > > decide > >> the add the neighbor (parent) information in the DAOs do we also add > > link > >> quality estimation values for each link associated with a parent node? > >> Otherwise the root will have a connectivity graph of the network > >> (DAG) > > but > >> will have no way to figure out which path is cost-efficient to select > > (the root > >> can come up with many combinations of paths to select from)? > >> > >> Thanks. > >> > >> -John > >> > >> On Mar 28, 2010, at 2:20 PM, Richard Kelsey wrote: > >> > >>> 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. > >>> > >>> 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. > >>> > >>> 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. > >>> > >>> 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. > >>> > >>> 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 > >>> > >>> What do people think? > >>> -Richard Kelsey > >>> _______________________________________________ > >>> 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 > > >=20 > ------ > JeongGil Ko (John) > Ph.D. Student > Department of Computer Science > Johns Hopkins University > http://www.cs.jhu.edu/~jgko From pthubert@cisco.com Sun Mar 28 23:41: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 6BE8F3A680A for ; Sun, 28 Mar 2010 23:41:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.886 X-Spam-Level: X-Spam-Status: No, score=-6.886 tagged_above=-999 required=5 tests=[AWL=2.583, 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 D3+0tEbnN3gx for ; Sun, 28 Mar 2010 23:41:10 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id E7E153A67A3 for ; Sun, 28 Mar 2010 23:41:09 -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: AvEAAOXor0uQ/uCWe2dsb2JhbACDGJctXhUBAQsLIgYcpUeIPY92gSuCbGoEjho X-IronPort-AV: E=Sophos;i="4.51,327,1267401600"; d="scan'208";a="58673257" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 29 Mar 2010 06:41: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 o2T6faoT004852; Mon, 29 Mar 2010 06:41:36 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, 29 Mar 2010 08:41:36 +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, 29 Mar 2010 08:41:32 +0200 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D0188AAFC@XMB-AMS-107.cisco.com> In-Reply-To: <1005359930.745161269843451128.JavaMail.root@mail02.pantherlink.uwm.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] proposal for DAOs in non-caching DODAGs Thread-Index: AcrPB5zT6Q9tNdvbRxysQOgiloFtZgAAmBWg References: <2011780176.744741269843206812.JavaMail.root@mail02.pantherlink.uwm.edu> <1005359930.745161269843451128.JavaMail.root@mail02.pantherlink.uwm.edu> From: "Pascal Thubert (pthubert)" To: "Mukul Goyal" , "JeongGil Ko (John)" X-OriginalArrivalTime: 29 Mar 2010 06:41:36.0104 (UTC) FILETIME=[E0C3EE80:01CACF0A] 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, 29 Mar 2010 06:41:12 -0000 SGkgTXVrdWwNCiANCj4gRG9lcyBSUEwgYXNzdW1lIHJvdXRpbmcgbWV0cmljcyB0byBiZSBlc3Nl bnRpYWxseSBzeW1tZXRyaWMgaW4gbmF0dXJlPw0KDQpbUGFzY2FsXSBDZXJ0YWlubHkgbm90ICEg QW4gaW5zdGFuY2UgYnVpbGRzIGEgc2luZ2xlIERBRyB0aG91Z2guIFNvIGEgbm9kZSBoYXMgdG8g bWljayBEQU8gYW5kIERJTyBwYXJlbnRzIGFuZCBjb21wdXRlIGEgUmFuayB0aGF0J3MgaGlnaGVy IHRoYW4gYW55IG9mIHRob3NlLg0KVG8gZG8gYmV0dGVyIHRoYW4gdGhhdCwgb25lIGNhbiBkZXBs b3kgYW4gdXAgYW5kIGEgZG93biBpbnN0YW5jZSwgZWFjaCBvcHRpbWl6aW5nIGZvciBvbmUgZGly ZWN0aW9uIG9ubHkuDQoNCj4gV2hlbiBub2RlIEIgcmVjZWl2ZXMgYSBESU8gZnJvbSBub2RlIEEg YWJvdXQgYSBEQUcgd2l0aCByb290IFIsIGl0IGNhbg0KPiBjaG9vc2Ugd2hldGhlciBsaW5rIEIt PkEgaXMgZ29pbmcgdG8gYmUgcGFydCBvZiB0aGUgcm91dGUgZnJvbSBCIHRvIFIuIE5vZGUgQg0K PiBjYW4gdXNlIGl0cyBrbm93bGVkZ2Ugb2YgbGluayBjb3N0IEItPkEgaW4gbWFraW5nIHRoaXMg ZGVjaXNpb24uDQo+IA0KPiBCdXQgd2hlbiBub2RlIEIgcGlja3MgcGFyZW50IEEgYXMgYSBEQU8g cGFyZW50LCBpdCBpcyBkZWNpZGluZyB0aGF0IGxpbmsgQS0+Qg0KPiBjYW4gYmUgb24gdGhlIHBh dGggZnJvbSByb290IFIgdG8gaXRzZWxmLiBCdXQgQiBkb2VzIG5vdCBrbm93IHRoZSBsaW5rIGNv c3QgQS0NCj4gPkIgdW5sZXNzIGl0IGlzIGFzc3VtZWQgdG8gYmUgc2FtZSBhcyBsaW5rIGNvc3Qg Qi0+QSEhIQ0KDQpbUGFzY2FsXSBSUEwgZW5hYmxlcyBtdWx0aXBsZSBtZXRyaWNzIGluIHRoZSBz YW1lIERJTyB3aXRoIHNvbWUgbG9naWMgdG8gdGllIHRoZW0gaW4uIFNvbWUgbWV0cmljcyBjYW4g ZGVhbCB3aXRoIHRoZSB1cCBhbmQgb3RoZXJzIHdpdGggdGhlIGRvd24gZGlyZWN0aW9uLiANCk1h a2VzIHNlbnNlPw0KDQpQYXNjYWwNCj4gLS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLQ0KPiBG cm9tOiAiSmVvbmdHaWwgS28gKEpvaG4pIiA8amdrb0Bjcy5qaHUuZWR1Pg0KPiBUbzogIlBhc2Nh bCBUaHViZXJ0IChwdGh1YmVydCkiIDxwdGh1YmVydEBjaXNjby5jb20+DQo+IENjOiByb2xsQGll dGYub3JnDQo+IFNlbnQ6IE1vbmRheSwgTWFyY2ggMjksIDIwMTAgMTowMzozMiBBTSBHTVQgLTA2 OjAwIFVTL0NhbmFkYSBDZW50cmFsDQo+IFN1YmplY3Q6IFJlOiBbUm9sbF0gcHJvcG9zYWwgZm9y IERBT3MgaW4gbm9uLWNhY2hpbmcgRE9EQUdzDQo+IA0KPiBIaSBQYXNjYWwsDQo+IA0KPiBJIHNl ZSB5b3VyIHBvaW50LiBPbmUgcXVlc3Rpb24sIHRoYXQgY29uZnVzZXMgbWUgaXMgaG93IHRoZSBz ZXQgb2YgJ3ByZWZlcnJlZA0KPiBEQU8gcGFyZW50cycgYXJlIGRldGVybWluZWQuIElzIHRoaXMg c2V0IGRpZmZlcmVudCBmcm9tIHRoZSBwcmVmZXJyZWQgcGFyZW50DQo+IHNldCBpbiBESU9zPyBJ IGd1ZXNzIGFub3RoZXIgd2F5IG9mIGFza2luZyBpcyB0byBhc2sgaXMgaG93IHRoZSBEQU9SYW5r IGlzDQo+IGRlZmluZWQgYW5kIGNvbXB1dGVkICh0aGlzIHF1ZXN0aW9uIHdhcyBhc2tlZCBwcmV2 aW91c2x5IGJ1dCBJIGRpZG4ndCByZWFsbHkNCj4gZ2V0IGEgY2xlYXIgYW5zd2VyKS4gV2lsbCBl YWNoIG5vZGUgdGhhdCBpbml0aWF0ZXMgYSBEQU8gZm9yIGEgc3BlY2lmaWMgcHJlZml4IGJlDQo+ IERBT1JhbmsgPSAxIGFuZCB0aGUgcmFuayBjb21wdXRhdGlvbiBjb250aW51ZSBqdXN0IGxpa2Ug dGhlIERJTyBwcm9jZXNzPyBJbg0KPiB0aGlzIGNhc2UgaXMgaXQgdHJ1ZSB0aGF0IGVhY2ggbm9k ZSBtYXkgbmVlZCB0byBtYWludGFpbiBkaWZmZXJlbnQgREFPUmFuaw0KPiB2YWx1ZXMgZm9yIG1h bnkgZGlmZmVyZW50IHByZWZpeGVzPw0KPiANCj4gVGhhbmtzIQ0KPiANCj4gLUpvaG4NCj4gDQo+ IE9uIE1hciAyOCwgMjAxMCwgYXQgMTA6NDQgUE0sIFBhc2NhbCBUaHViZXJ0IChwdGh1YmVydCkg d3JvdGU6DQo+IA0KPiA+IEhpIEpvaG46DQo+ID4NCj4gPiBPYnZpb3VzbHksIGhhdmluZyBtdWx0 aXBsZSBwYXJlbnRzIGVuYWJsZXMgdGhlIHJvb3QgdG8gY29tcHV0ZQ0KPiA+IG11bHRpcGxlIHBh dGhzIGRvd24gdG8gdGhlIG5vZGUuIFNvIHlvdXIgcHJvcG9zYWwgaXMgdGVtcHRpbmcuIEJ1dA0K PiA+IGJld2FyZSwgdGhpcyBpcyBhIHNsaXBwZXJ5IHNsb3BlIHRvd2FyZHMgY2VudHJhbGl6ZWQg TGluayBTdGF0ZQ0KPiA+IGNvbXB1dGF0aW9uIGFuZCBhd2F5IGZyb20gdGhlIFJQTCBjb3JlIGRl c2lnbiwgYW5kIHdlIGNhbid0IGJlDQo+ID4gZGVzaWduaW5nIDIgcHJvdG9jb2xzLCBieSBjaGFy dGVyLg0KPiA+DQo+ID4gVGhlIFJQTCBkZXNpZ24gaXMgdGhhdCB0aGUgY2hvaWNlIG9mIHRoZSBi ZXN0IHBhcmVudHMgYmVsb25ncyB0byB0aGUNCj4gPiBPRiBpbiB0aGUgbm9kZSwgbm90IHRoZSBy b290LiBSaWNoYXJkJ3MgcHJvcG9zYWwgY2VudHJhbGl6ZXMgaW4gdGhlDQo+ID4gcm9vdCB0aGUg Zm9yd2FyZGluZyBkZWNpc2lvbiBhbG9uZyB0aGUgREFHIHRoYXQgaGFwcGVucyBob3AgYnkgaG9w DQo+ID4gd2l0aCBzdGF0ZWZ1bCBEQU9zLCBidXQgdGhlIHJvdXRpbmcgIHN0YXRlcyBhcmUgYnVp bHQgaW4gdGhlIGV4YWN0DQo+ID4gc2FtZSBmYXNoaW9uIHdoZXRoZXIgaXQgaXMgc3RhdGVmdWwg b3Igc3RhdGVsZXNzLCBieSBoYXZpbmcgZWFjaCBub2RlDQo+ID4gc2VsZWN0IGEgc2V0IG9mIHBy ZWZlcnJlZCBEQU8gcGFyZW50cy4gTm90ZSB0aGF0IHdlIGRvIG5vdCBzcGVjaWZ5IGhvdw0KPiA+ IGEgbm9kZSBzZWxlY3RzIHRoZSBuZXh0IGhvcCBiZXR3ZWVuIG11bHRpcGxlIERBTyBjaGlsZHJl biBpbiB0aGUgc3RhdGVmdWwNCj4gbW9kZS4NCj4gPiBJbiB0aGUgc2FtZSBmYXNoaW9uLCB3ZSBk byBub3Qgc3BlY2lmeSBob3cgdGhlIHJvb3QgbWFrZXMgdGhlIG11bHRpDQo+ID4gaG9wIGRlY2lz aW9uLg0KPiA+DQo+ID4gTXkgc3VnZ2VzdGlvbiB0byBhZGRyZXNzIHlvdXIgcHJvYmxlbSB3b3Vs ZCBiZSB0aGF0IHRoZSBPRiBpbiB0aGUgbm9kZQ0KPiA+IHByb3ZpZGVzIG1vcmUgaW5mbyBvbiBo b3cgaXQgb3JkZXJzIHRoZSBwYXJlbnRzLCBtYXliZSBieSBzZXR0aW5nIGENCj4gPiBwcmVmZXJl bmNlIGxldmVsIChsaWtlIDAtMykgZm9yIGVhY2ggcGFyZW50IGluIHRoZSBzb3VyY2Ugcm91dGUg REFPLg0KPiA+IFRoZSByb290IHJldGFpbnMgdGhlIHBvc3NpYmlsaXR5IHRvIGJ1aWxkIG11bHRp cGxlIG5vbi1vdmVybGFwcGluZw0KPiA+IHBhdGgsIGRvIGxvYWQgYmFsYW5jaW5nLCBzaWduYWwg dG8gTDIgd2hlbiBMMiBwYXRocy9jaXJjdWl0cyBuZWVkIHRvDQo+ID4gYmUgZW5hYmxlZCwgZXRj Li4uIFdlIGhhdmUgbm90IG1hZGUgdGhlIHN0ZXAgdG93YXJkcyBhIGNlbnRyYWxpemVkDQo+IHJv dXRpbmcgbW9kZWwuDQo+ID4NCj4gPiBDaGVlcnMsDQo+ID4NCj4gPiBQYXNjYWwNCj4gPg0KPiA+ DQo+ID4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID4+IEZyb206IHJvbGwtYm91bmNl c0BpZXRmLm9yZyBbbWFpbHRvOnJvbGwtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmDQo+ID4g T2YNCj4gPj4gSmVvbmdHaWwgS28gKEpvaG4pDQo+ID4+IFNlbnQ6IFN1bmRheSwgTWFyY2ggMjgs IDIwMTAgMTE6NDIgUE0NCj4gPj4gVG86IFJpY2hhcmQgS2Vsc2V5DQo+ID4+IENjOiByb2xsQGll dGYub3JnDQo+ID4+IFN1YmplY3Q6IFJlOiBbUm9sbF0gcHJvcG9zYWwgZm9yIERBT3MgaW4gbm9u LWNhY2hpbmcgRE9EQUdzDQo+ID4+DQo+ID4+IFJpY2hhcmQsDQo+ID4+DQo+ID4+IEkgYWdyZWUg dGhhdCBpZiB3ZSBzdGFydCBhZGRpbmcgZG93bndhcmRzIHJvdXRlcyB0aGVuIHRoZSByb290IHdp bGwNCj4gPiBoYXZlDQo+ID4+IG1hbnkgc3ViLXJvdXRlIChvciBzdWItcGF0aCkgaW5mb3JtYXRp b24gdGhhdCBpdCBhbHJlYWR5IGhhcy4gSWYgd2UNCj4gPiBkZWNpZGUNCj4gPj4gdGhlIGFkZCB0 aGUgbmVpZ2hib3IgKHBhcmVudCkgaW5mb3JtYXRpb24gaW4gdGhlIERBT3MgZG8gd2UgYWxzbyBh ZGQNCj4gPiBsaW5rDQo+ID4+IHF1YWxpdHkgZXN0aW1hdGlvbiB2YWx1ZXMgZm9yIGVhY2ggbGlu ayBhc3NvY2lhdGVkIHdpdGggYSBwYXJlbnQgbm9kZT8NCj4gPj4gT3RoZXJ3aXNlIHRoZSByb290 IHdpbGwgaGF2ZSBhIGNvbm5lY3Rpdml0eSBncmFwaCBvZiB0aGUgbmV0d29yaw0KPiA+PiAoREFH KQ0KPiA+IGJ1dA0KPiA+PiB3aWxsIGhhdmUgbm8gd2F5IHRvIGZpZ3VyZSBvdXQgd2hpY2ggcGF0 aCBpcyBjb3N0LWVmZmljaWVudCB0byBzZWxlY3QNCj4gPiAodGhlIHJvb3QNCj4gPj4gY2FuIGNv bWUgdXAgd2l0aCBtYW55IGNvbWJpbmF0aW9ucyBvZiBwYXRocyB0byBzZWxlY3QgZnJvbSk/DQo+ ID4+DQo+ID4+IFRoYW5rcy4NCj4gPj4NCj4gPj4gLUpvaG4NCj4gPj4NCj4gPj4gT24gTWFyIDI4 LCAyMDEwLCBhdCAyOjIwIFBNLCBSaWNoYXJkIEtlbHNleSB3cm90ZToNCj4gPj4NCj4gPj4+IFBh c2NhbCBhbmQgSSBoYWQgYSBkaXNjdXNzaW9uIG9uIGhvdyB0byBzaW1wbGlmeSBEQU9zIGlmIHRo ZSBncm91cA0KPiA+Pj4gY29uZmlybXMgdGhlIGRlY2lzaW9uIHRvIG5vdCBleHBsaWNpdGx5IHN1 cHBvcnQgREFHcyB3aXRoIG1peGVkDQo+ID4+PiBjYWNoaW5nIGFuZCBub24tY2FjaGluZyByb3V0 ZXJzLiAgVGhlIG9idmlvdXMgc2ltcGxpZmljYXRpb24gaXMgdGhhdA0KPiA+Pj4gdGhlIERJTyAn UycgZmxhZyBpcyBlaXRoZXIgb24gb3Igb2ZmIHRocm91Z2hvdXQgYSBET0RBRywgZWxpbWluYXRp bmcNCj4gPj4+IHRoZSBuZWVkIHRvIGRvIGFueXRoaW5nIHdoZW4gaXQgY2hhbmdlcy4NCj4gPj4+ DQo+ID4+PiBNb3JlIGludGVyZXN0aW5nbHksIHRoZSByZXZlcnNlIHJvdXRlIHN0YWNrIGlzIG5v IGxvbmdlciBuZWVkZWQuICBJdA0KPiA+Pj4gaXMgbm90IHVzZWQgaWYgYWxsIG5vZGVzIGNhY2hl IERBT3MuICBJZiBvbmx5IHRoZSByb290IGRvZXMgc28sDQo+ID4+PiBpbmNsdWRpbmcgaW50ZXJt ZWRpYXRlIGhvcHMgd2hlbiBmb3J3YXJkaW5nIERBT3Mgb25seSBkdXBsaWNhdGVzDQo+ID4+PiBp bmZvcm1hdGlvbiB0aGF0IHRoZSByb290IHdpbGwgcmVjZWl2ZSBmcm9tIG90aGVycy4NCj4gPj4+ DQo+ID4+PiBPdXIgcHJvcG9zYWwgaXMgdG8gcmVwbGFjZSB0aGUgcmV2ZXJzZSByb3V0ZSBzdGFj ayB3aXRoIGEgc2V0IG9mDQo+ID4+PiBwYXJlbnRzIHRoYXQgaXMgZm9yd2FyZGVkIHVwIHRoZSBE QUcgdG8gdGhlIHJvb3QuDQo+ID4+PiBUaGUgREFPIGZvcm1hdCBzdGF5cyB0aGUgc2FtZSwgZXhj ZXB0IHRoYXQgdGhlIHJldmVyc2Ugcm91dGUgc3RhY2sNCj4gPiBpcw0KPiA+Pj4gbm93IGEgc2V0 IG9mIHBhcmVudHMgYW5kIGlzIG5vdCBjaGFuZ2VkIHdoZW4gZm9yd2FyZGVkLg0KPiA+Pj4NCj4g Pj4+IFRoZSByb290IGNhbiB0aGVuIHJlY29uc3RydWN0IHRoZSBEQUcgYW5kIGNvbXB1dGUgZG93 bndhcmRzIHJvdXRlcw0KPiA+IGFzDQo+ID4+PiBuZWVkZWQuICBUaGlzIGlzIG5vdCBhcyBiaWcg YSBjaGFuZ2UgYXMgaXQgbWF5DQo+ID4+PiBzZWVtOiBpbiB0aGUgY3VycmVudCBkcmFmdCB0aGUg cm9vdCBtYXkgaGF2ZSB0byBjb21wdXRlIHRoZSBwYXRocyB0bw0KPiA+Pj4gbm9kZXMgd2hvc2Ug UyBiaXQgaXMgbm90IHNldC4gIFBhdGggY29tcHV0YXRpb24gaXMgc2ltcGxlciB0aGFuIGZvcg0K PiA+IGENCj4gPj4+IGZ1bGwgbGluay1zdGF0ZSBwcm90b2NvbCwgYXMgdGhlIERJT3MgaGF2ZSBw cmVzZWxlY3RlZCB0aGUgYmV0dGVyDQo+ID4+PiB1cC9kb3duIGxpbmtzIGluIGZvcm1pbmcgdGhl IERBRyBhbmQgb3RoZXIgbGlua3MgYXJlIG5vdCByZXBvcnRlZC4NCj4gPj4+DQo+ID4+PiBUaGUg YWR2YW50YWdlcyBvZiB1c2luZyBhIHBhcmVudCBzZXQgcmF0aGVyIHRoYW4gYSByZXZlcnNlIHJv dXRlDQo+ID4gc3RhY2sNCj4gPj4+IGFyZToNCj4gPj4+IC0gZG93bndhcmQgcGF0aCBkaXZlcnNp dHkgd2hpbGUgb25seSBzZW5kaW5nIERBT3MNCj4gPj4+ICAgdG8gdGhlIHByZWZlcnJlZCBwYXJl bnQNCj4gPj4+IC0gREFPcyBkbyBub3QgZ3JvdyB3aXRoIERBRyBkZXB0aA0KPiA+Pj4gLSBEQU8g Zm9yd2FyZGluZyBpcyBzaW1wbGVyDQo+ID4+Pg0KPiA+Pj4gV2hhdCBkbyBwZW9wbGUgdGhpbms/ DQo+ID4+PiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIC1SaWNoYXJkIEtlbHNleQ0K PiA+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4g Pj4+IFJvbGwgbWFpbGluZyBsaXN0DQo+ID4+PiBSb2xsQGlldGYub3JnDQo+ID4+PiBodHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3JvbGwNCj4gPj4+DQo+ID4+DQo+ID4+IC0t LS0tLQ0KPiA+PiBKZW9uZ0dpbCBLbyAoSm9obikNCj4gPj4gUGguRC4gU3R1ZGVudA0KPiA+PiBE ZXBhcnRtZW50IG9mIENvbXB1dGVyIFNjaWVuY2UNCj4gPj4gSm9obnMgSG9wa2lucyBVbml2ZXJz aXR5DQo+ID4+IGh0dHA6Ly93d3cuY3Muamh1LmVkdS9+amdrbw0KPiA+Pg0KPiA+PiBfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+PiBSb2xsIG1haWxp bmcgbGlzdA0KPiA+PiBSb2xsQGlldGYub3JnDQo+ID4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vcm9sbA0KPiA+DQo+IA0KPiAtLS0tLS0NCj4gSmVvbmdHaWwgS28gKEpv aG4pDQo+IFBoLkQuIFN0dWRlbnQNCj4gRGVwYXJ0bWVudCBvZiBDb21wdXRlciBTY2llbmNlDQo+ IEpvaG5zIEhvcGtpbnMgVW5pdmVyc2l0eQ0KPiBodHRwOi8vd3d3LmNzLmpodS5lZHUvfmpna28N Cj4gDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ IFJvbGwgbWFpbGluZyBsaXN0DQo+IFJvbGxAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9yb2xsDQo= From jeonggil.ko@gmail.com Sun Mar 28 23:53: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 3CAF13A683B for ; Sun, 28 Mar 2010 23:53:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.169 X-Spam-Level: X-Spam-Status: No, score=-0.169 tagged_above=-999 required=5 tests=[AWL=1.300, 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 8p8aBn4kYK3X for ; Sun, 28 Mar 2010 23:53:57 -0700 (PDT) Received: from mail-yw0-f182.google.com (mail-yw0-f182.google.com [209.85.211.182]) by core3.amsl.com (Postfix) with ESMTP id 80F793A68E4 for ; Sun, 28 Mar 2010 23:53:56 -0700 (PDT) Received: by ywh12 with SMTP id 12so5497616ywh.32 for ; Sun, 28 Mar 2010 23:54:21 -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=YBVQN8w9dlS0aVUol9c3kCqz/FDdTraLmBY+YjqgcR4=; b=xUFEuG+/nKrwO3D02a3I/kR4MyjzXnqZfVpQPimKU6FUR+QR2O570vql9EYfZLHsH/ PixwPTsDyYJrtAeZsy2twOcIByJ70RmubSQpHILmJkbYeai+zIaWbKHgGahBGhfb2F+C efm/qW1FLXYXOaJR1C/3GfsV2qyVghak7qRtI= 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=N5q7VyMUjY/Ebl//W5eb3hSEktzJDSBvzbLIC+WHKnaCG/ik2E9ybs/R6YxGoq6IpG /PcRDZPC//00brrjdm5CjqPnWWqBiWURf7CkyDTtWpvhzTGlqbIAo2AEQmhUiE2soiEz GJ41Zg+8P5mz2AGdq+Tkev5vOPUAzXRHnEWuw= Received: by 10.101.148.2 with SMTP id a2mr332718ano.230.1269845621567; Sun, 28 Mar 2010 23:53:41 -0700 (PDT) Received: from [192.168.1.103] ([76.14.51.89]) by mx.google.com with ESMTPS id 20sm937962yxe.41.2010.03.28.23.53.40 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sun, 28 Mar 2010 23:53:41 -0700 (PDT) Sender: "JeongGil (John) Ko" Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: "JeongGil Ko (John)" In-Reply-To: <6A2A459175DABE4BB11DE2026AA50A5D0188AAFB@XMB-AMS-107.cisco.com> Date: Sun, 28 Mar 2010 23:53:38 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: 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> To: Pascal Thubert (pthubert) X-Mailer: Apple Mail (2.1077) 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, 29 Mar 2010 06:53:59 -0000 Pascal, On Mar 28, 2010, at 11:33 PM, Pascal Thubert (pthubert) wrote: > Hi John: >=20 > I think I see what you're saying. >=20 > If the metrics are asymmetrical, then it might occur that the DAO > parents set is not the exact same as DIO parent set. A node would = prefer > a DAO parent for which the metrics from the root to the node are > optimal. So theoretically following the preferred parent path provides > the best metrics without using the DAO rank.=20 >=20 Exactly. We will need a way to find what the preferred DAO parent set is = though. Since we have agreed that the set can be different from the = DODAG preferred parent set, how can we do this without using DAO rank = values? (Read below and you will find out that I am not a big fan of = this DAO rank either :) Just that I don't have a smart answer yet.) > The current spec enables the OF in a node to compute a DAO Rank based = on > the metrics option pretty much like a DIO Rank would be computed using = a > DAO DAG Metric Container. This was introduced at some point along the > path and provides an additional capability to rate non preferred = paths. > I figure that you're willing to emulate that in the source route DAO >=20 > My take is that we have already added too much complexity even though = we > made it optional. I'd rather remove the DAO DAG Metric Container. But = in > any fashion I have to agree with your desire to make things = consistent. > Then again, slippery slope towards link state... >=20 I was asking about the DAO rank process just to make things clear before = I go and implement the stuff (after all this is what the specs want me = to use at least until now). I agree that computing separate rank values = for DAOs are a pain and can easily take up a lot of resources as the = number of supported prefixes increase. So I must say that I have little = desire to make things consistent but rather have the desire to make = things simpler and working :) Thanks. -John > Pascal >=20 >=20 >> -----Original Message----- >> From: JeongGil (John) Ko [mailto:jeonggil.ko@gmail.com] On Behalf Of >> JeongGil Ko (John) >> Sent: Monday, March 29, 2010 8:04 AM >> To: Pascal Thubert (pthubert) >> Cc: Richard Kelsey; roll@ietf.org >> Subject: Re: [Roll] proposal for DAOs in non-caching DODAGs >>=20 >> Hi Pascal, >>=20 >> I see your point. One question, that confuses me is how the set of > 'preferred >> DAO parents' are determined. Is this set different from the preferred > parent >> set in DIOs? I guess another way of asking is to ask is how the > DAORank is >> defined and computed (this question was asked previously but I didn't > really >> get a clear answer). Will each node that initiates a DAO for a > specific prefix be >> DAORank =3D 1 and the rank computation continue just like the DIO > process? In >> this case is it true that each node may need to maintain different > DAORank >> values for many different prefixes? >>=20 >> Thanks! >>=20 >> -John >>=20 >> On Mar 28, 2010, at 10:44 PM, Pascal Thubert (pthubert) wrote: >>=20 >>> Hi John: >>>=20 >>> Obviously, having multiple parents enables the root to compute >>> multiple paths down to the node. So your proposal is tempting. But >>> beware, this is a slippery slope towards centralized Link State >>> computation and away from the RPL core design, and we can't be >>> designing 2 protocols, by charter. >>>=20 >>> The RPL design is that the choice of the best parents belongs to the >>> OF in the node, not the root. Richard's proposal centralizes in the >>> root the forwarding decision along the DAG that happens hop by hop >>> with stateful DAOs, but the routing states are built in the exact >>> same fashion whether it is stateful or stateless, by having each > node >>> select a set of preferred DAO parents. Note that we do not specify > how >>> a node selects the next hop between multiple DAO children in the > stateful >> mode. >>> In the same fashion, we do not specify how the root makes the multi >>> hop decision. >>>=20 >>> My suggestion to address your problem would be that the OF in the > node >>> provides more info on how it orders the parents, maybe by setting a >>> preference level (like 0-3) for each parent in the source route DAO. >>> The root retains the possibility to build multiple non-overlapping >>> path, do load balancing, signal to L2 when L2 paths/circuits need to >>> be enabled, etc... We have not made the step towards a centralized >> routing model. >>>=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: Sunday, March 28, 2010 11:42 PM >>>> To: Richard Kelsey >>>> Cc: roll@ietf.org >>>> Subject: Re: [Roll] proposal for DAOs in non-caching DODAGs >>>>=20 >>>> Richard, >>>>=20 >>>> I agree that if we start adding downwards routes then the root will >>> have >>>> many sub-route (or sub-path) information that it already has. If we >>> decide >>>> the add the neighbor (parent) information in the DAOs do we also > add >>> link >>>> quality estimation values for each link associated with a parent > node? >>>> Otherwise the root will have a connectivity graph of the network >>>> (DAG) >>> but >>>> will have no way to figure out which path is cost-efficient to > select >>> (the root >>>> can come up with many combinations of paths to select from)? >>>>=20 >>>> Thanks. >>>>=20 >>>> -John >>>>=20 >>>> On Mar 28, 2010, at 2:20 PM, Richard Kelsey wrote: >>>>=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 >>>>>=20 >>>>=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 >> ------ >> JeongGil Ko (John) >> Ph.D. Student >> Department of Computer Science >> Johns Hopkins University >> http://www.cs.jhu.edu/~jgko >=20 ------ JeongGil Ko (John) Ph.D. Student Department of Computer Science Johns Hopkins University http://www.cs.jhu.edu/~jgko From prvs=6972f6f3a=mukul@uwm.edu Sun Mar 28 23:57: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 66E323A683B for ; Sun, 28 Mar 2010 23:57:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.575 X-Spam-Level: X-Spam-Status: No, score=0.575 tagged_above=-999 required=5 tests=[AWL=0.555, BAYES_05=-1.11, 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 jlkh4I26M+PR for ; Sun, 28 Mar 2010 23:57:06 -0700 (PDT) Received: from ip2mta.uwm.edu (ip2mta.uwm.edu [129.89.7.20]) by core3.amsl.com (Postfix) with ESMTP id 962D33A67A7 for ; Sun, 28 Mar 2010 23:57:06 -0700 (PDT) Received: from mta03.pantherlink.uwm.edu ([129.89.7.83]) by ip2mta.uwm.edu with ESMTP; 29 Mar 2010 01:57:33 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by mta03.pantherlink.uwm.edu (Postfix) with ESMTP id EB9FEC085AC; Mon, 29 Mar 2010 01:57:33 -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 Mlf7PAxPKSm2; Mon, 29 Mar 2010 01:57:33 -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 C4FCFC085A0; Mon, 29 Mar 2010 01:57:33 -0500 (CDT) Date: Mon, 29 Mar 2010 01:57:33 -0500 (CDT) From: Mukul Goyal To: "Pascal Thubert (pthubert)" Message-ID: <1260275736.748331269845853720.JavaMail.root@mail02.pantherlink.uwm.edu> In-Reply-To: <6A2A459175DABE4BB11DE2026AA50A5D0188AAFC@XMB-AMS-107.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [129.89.7.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: Mon, 29 Mar 2010 06:57:07 -0000 Hi Pascal > > But when node B picks parent A as a DAO parent, it is deciding that link A->B > can be on the path from root R to itself. But B does not know the link cost A- > >B unless it is assumed to be same as link cost B->A!!! [Pascal] RPL enables multiple metrics in the same DIO with some logic to tie them in. Some metrics can deal with the up and others with the down direction. Makes sense? [MG] So, when node A sends out a DIO, one metric object would indicate the aggregated metric from root till A and another metric object would indicate the local link/node level metric value? This works for a node-level metric value. But, the link-level metric value (e.g. link LQL) would be different for different receivers of the DIO. A DIO is sent via link-local multicast. So, in order to send a local link-level metric value, node A would have to identify the receiver(s) for which this value is valid. No? Mukul From pthubert@cisco.com Mon Mar 29 02:57: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 4E47F3A67B6 for ; Mon, 29 Mar 2010 02:57:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.255 X-Spam-Level: X-Spam-Status: No, score=-7.255 tagged_above=-999 required=5 tests=[AWL=2.214, 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 PW9CFlGq9e4G for ; Mon, 29 Mar 2010 02:57:58 -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 724803A680D for ; Mon, 29 Mar 2010 02:57:58 -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: Av0EAIcWsEurR7H+/2dsb2JhbACDGJcvXXGleog9kAaBK4EngUVqBI4a X-IronPort-AV: E=Sophos;i="4.51,327,1267401600"; d="scan'208";a="173810504" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-5.cisco.com with ESMTP; 29 Mar 2010 09:58:26 +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 o2T9wKL4027481; Mon, 29 Mar 2010 09:58:26 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, 29 Mar 2010 11:58:19 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 Date: Mon, 29 Mar 2010 11:58:08 +0200 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D0188AC61@XMB-AMS-107.cisco.com> In-Reply-To: <1260275736.748331269845853720.JavaMail.root@mail02.pantherlink.uwm.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] proposal for DAOs in non-caching DODAGs Thread-Index: AcrPDR/fqhOMYdpxTYm7wvDM1RXZHwAFiyAQ References: <6A2A459175DABE4BB11DE2026AA50A5D0188AAFC@XMB-AMS-107.cisco.com> <1260275736.748331269845853720.JavaMail.root@mail02.pantherlink.uwm.edu> From: "Pascal Thubert (pthubert)" To: "Mukul Goyal" X-OriginalArrivalTime: 29 Mar 2010 09:58:19.0179 (UTC) FILETIME=[5BF23FB0:01CACF26] 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, 29 Mar 2010 09:57:59 -0000 SGkgTXVrdWwsDQoNCkkgdGhpbmsgSSB1bmRlcnN0YW5kIHdoYXQgeW91J3JlIHNheWluZy4gDQoN CkhlcmUsIHdlIGFyZSB0YWxraW5nIGFib3V0IGxpbmsgaW5kaWNhdG9ycywgYXMgY2FuIGJlIGV2 YWx1YXRlZCBieSBlaXRoZXIgb25lIGVuZCBvciB0aGUgb3RoZXIgZnJvbSBsaW5rIGxheWVyIGlu Zm9ybWF0aW9uLCBhcyBvcHBvc2VkIHRvIG1ldHJpY3MgaW4gdGhlIG1ldHJpY3MgY29udGFpbmVy cyBpbiBESU8vREFPIHRoYXQgYXJlIEwzIGFic3RyYWN0aW9uIGFnZ3JlZ2F0ZWQgYWxvbmcgdGhl IHJlc3Qgb2YgdGhlIHJvdXRlLiBBbmQgeWVzLCBmb3IgYWxsIEkga25vdywgc29tZSBpbmRpY2F0 b3JzIGFyZSByZWNlaXZlciBzaWRlIChsaWtlIFJTU0kvUkNQSSkgd2hpbGUgb3RoZXJzIGFyZSBz ZW5kZXIgc2lkZSAobGlrZSBhIHN0YXRzIG9uIHJldHJpZXMgb3IgeG1pdCBxdWV1ZSBsYXRlbmN5 KS4NCiANCkRlcGVuZGluZyBvbiB0aGUgaW5kaWNhdG9yLCBpdCBzZWVtcyB0aGF0IHRoZSBjaGls ZCBpcyBpbiBwb3NpdGlvbiB0byBjb21wdXRlIHRoZSAoMSBob3ApIGxpbmsgbWV0cmljIHVwb24g RElPKHMpIGZvciBlaXRoZXIgdGhlIHVwd2FyZCBvciB0aGUgZG93bndhcmQgcGF0aC4NCg0KSWRl YWxseSwgd2UnZCBsaWtlIHRoZW0gYWxsIHRvIGJlIHJlY2VpdmVyIHNpZGUgc28gdGhhdCBhIGNo aWxkIGNhbiBjb21wdXRlIGV2ZXJ5dGhpbmcgdXBvbiBhIERJTywgcHJlZmVycmVkIERJTyBwYXJl bnQocykgZm9yIGRlZmF1bHQgcm91dGUgYW5kIHByZWZlcnJlZCBEQU8gcGFyZW50KHMpIGZvciBk b3dud2FyZCByb3V0ZS4gSWYgd2UgY2Fubm90IGRvIHRoYXQgYW5kIHdlIHN0aWxsIHdhbnQgdGhl IGNoaWxkIHRvIGdldCBtZXRyaWNzIGZvciB0aGUgb3RoZXIgZGlyZWN0aW9uLCBpdCBhcHBlYXJz IHRoYXQgc29tZSBhZGRpdGlvbmFsIG1lY2hhbmlzbSBtdXN0IGJlIHB1dCBpbiBwbGFjZSB3aGVy ZWJ5IHRoZSBjaGlsZCBzZW5kcyBzb21ldGhpbmcgdG8gdGhlIHBhcmVudCwgYW5kIHRoZSBwYXJl bnQgc2VuZHMgYmFjayBpdHMgb3duIHZpZXcgb2YgdGhlIGxpbmsgY2hpbGQtPnBhcmVudCBzbyB0 aGF0IG5vdyB0aGUgY2hpbGQgY2FuIG1ha2UgYW4gaW5mb3JtZWQgZGVjaXNpb24uDQoNCldlIGhh dmUgbm8gdW5pY2FzdCBtZXNzYWdlIGZyb20gcGFyZW50IHRvIGNoaWxkIGF0IHRoaXMgcG9pbnQu IFRoZSB0aGluZyBjbG9zZXN0IHRvIHdoeSB5b3Ugc2VlbSB0byBiZSBhc2tpbmcgZm9yIHdvdWxk IGJlIGEgdW5pY2FzdCBESVMgZm9sbG93ZWQgYnkgYSB1bmljYXN0IERJTyB3aGVyZWJ5IHRoZSBw YXJlbnQgcGxhY2VzIGEgbGluayBtZXRyaWNzIGNvbnRhaW5lciB0aGF0IGluZm9ybXMgdGhlIGNo aWxkIG9mIHRoZSBwYXJlbnQncyB2aWV3IG9mIHRoZSBsaW5rLiBJdCBtYWtlcyBzZW5zZSB0byBt ZSB0aGF0IHN1Y2ggYSBwcm9jZXNzIGJlbG9uZyB0byB0aGUgZ3JleSB6b25lIHdoZXJlIGEgY2hp bGQgYXNzZXNzZXMgdGhlIHF1YWxpdHkgb2YgYSBsaW5rIHdpdGggYSBjYW5kaWRhdGUgbmVpZ2hi b3IgcHJpb3IgdG8gYWxsb3dpbmcgaXQgYXMgYSBwYXJlbnQuDQoNCklzIHRoYXQgeW91ciBxdWVz dGlvbj8NCg0KUGFzY2FsDQoNCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9t OiBNdWt1bCBHb3lhbCBbbWFpbHRvOm11a3VsQHV3bS5lZHVdDQo+IFNlbnQ6IE1vbmRheSwgTWFy Y2ggMjksIDIwMTAgODo1OCBBTQ0KPiBUbzogUGFzY2FsIFRodWJlcnQgKHB0aHViZXJ0KQ0KPiBD Yzogcm9sbEBpZXRmLm9yZzsgSmVvbmdHaWwgS28gKEpvaG4pDQo+IFN1YmplY3Q6IFJlOiBbUm9s bF0gcHJvcG9zYWwgZm9yIERBT3MgaW4gbm9uLWNhY2hpbmcgRE9EQUdzDQo+IA0KPiBIaSBQYXNj YWwNCj4gDQo+ID4NCj4gPiBCdXQgd2hlbiBub2RlIEIgcGlja3MgcGFyZW50IEEgYXMgYSBEQU8g cGFyZW50LCBpdCBpcyBkZWNpZGluZyB0aGF0DQo+ID4gbGluayBBLT5CIGNhbiBiZSBvbiB0aGUg cGF0aCBmcm9tIHJvb3QgUiB0byBpdHNlbGYuIEJ1dCBCIGRvZXMgbm90DQo+ID4ga25vdyB0aGUg bGluayBjb3N0IEEtDQo+ID4gPkIgdW5sZXNzIGl0IGlzIGFzc3VtZWQgdG8gYmUgc2FtZSBhcyBs aW5rIGNvc3QgQi0+QSEhIQ0KPiANCj4gW1Bhc2NhbF0gUlBMIGVuYWJsZXMgbXVsdGlwbGUgbWV0 cmljcyBpbiB0aGUgc2FtZSBESU8gd2l0aCBzb21lIGxvZ2ljIHRvIHRpZQ0KPiB0aGVtIGluLiBT b21lIG1ldHJpY3MgY2FuIGRlYWwgd2l0aCB0aGUgdXAgYW5kIG90aGVycyB3aXRoIHRoZSBkb3du DQo+IGRpcmVjdGlvbi4NCj4gTWFrZXMgc2Vuc2U/DQo+IA0KPiBbTUddIFNvLCB3aGVuIG5vZGUg QSBzZW5kcyBvdXQgYSBESU8sIG9uZSBtZXRyaWMgb2JqZWN0IHdvdWxkIGluZGljYXRlIHRoZQ0K PiBhZ2dyZWdhdGVkIG1ldHJpYyBmcm9tIHJvb3QgdGlsbCBBIGFuZCBhbm90aGVyIG1ldHJpYyBv YmplY3Qgd291bGQgaW5kaWNhdGUNCj4gdGhlIGxvY2FsIGxpbmsvbm9kZSBsZXZlbCBtZXRyaWMg dmFsdWU/IFRoaXMgd29ya3MgZm9yIGEgbm9kZS1sZXZlbCBtZXRyaWMNCj4gdmFsdWUuIEJ1dCwg dGhlIGxpbmstbGV2ZWwgbWV0cmljIHZhbHVlIChlLmcuIGxpbmsgTFFMKSB3b3VsZCBiZSBkaWZm ZXJlbnQgZm9yDQo+IGRpZmZlcmVudCByZWNlaXZlcnMgb2YgdGhlIERJTy4gQSBESU8gaXMgc2Vu dCB2aWEgbGluay1sb2NhbCBtdWx0aWNhc3QuIFNvLCBpbg0KPiBvcmRlciB0byBzZW5kIGEgbG9j YWwgbGluay1sZXZlbCBtZXRyaWMgdmFsdWUsIG5vZGUgQSB3b3VsZCBoYXZlIHRvIGlkZW50aWZ5 DQo+IHRoZSByZWNlaXZlcihzKSBmb3Igd2hpY2ggdGhpcyB2YWx1ZSBpcyB2YWxpZC4gTm8/DQo+ IA0KPiANCj4gTXVrdWwNCg0K From pthubert@cisco.com Mon Mar 29 03: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 BEDCA3A69FF for ; Mon, 29 Mar 2010 03:24:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.531 X-Spam-Level: X-Spam-Status: No, score=-7.531 tagged_above=-999 required=5 tests=[AWL=1.938, 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 nICqpSVoTiFg for ; Mon, 29 Mar 2010 03:24:39 -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 D580E3A69FC for ; Mon, 29 Mar 2010 03:24:38 -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: ApsBAJ4csEuQ/uCWe2dsb2JhbACbJBcLCyIGHKYSmEOFAQSOGg X-IronPort-AV: E=Sophos;i="4.51,327,1267401600"; d="scan'208";a="58685835" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 29 Mar 2010 10:25:05 +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 o2TAP4Ij006642; Mon, 29 Mar 2010 10:25:05 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, 29 Mar 2010 12:25:04 +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, 29 Mar 2010 12:24:59 +0200 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D0188AC85@XMB-AMS-107.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] proposal for DAOs in non-caching DODAGs Thread-Index: AcrPDK28BkXcFUErRpGuhtny+Jx5bwAGhDEg 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> From: "Pascal Thubert (pthubert)" To: "JeongGil Ko (John)" X-OriginalArrivalTime: 29 Mar 2010 10:25:04.0550 (UTC) FILETIME=[18D26C60:01CACF2A] 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, 29 Mar 2010 10:24:41 -0000 Hi John: The DAO metrics enable an ancestor to assess a path that was mostly already assessed by the child that selected its parents, so it has limited value, and could be already very simplified. When adapt the DAO metric to the source route, yes, it appears that all one hop link metrics would be sent to the root so that it explores all the possible paths along the dag and computes the best(s).=20 But this might become very complex/costly in terms of CPU in the root, for something that, again, was mostly already evaluated by the destination node that picked and ordered its DAO parents. So my take for making things simple is not to add DAO metrics container per parent in the source route DAO, but rather to challenge the use of the DAO metrics even in non-source route case.=20 Apart from this, would you support Richard's proposal? Pascal > -----Original Message----- > From: JeongGil (John) Ko [mailto:jeonggil.ko@gmail.com] On Behalf Of > JeongGil Ko (John) > Sent: Monday, March 29, 2010 8:54 AM > To: Pascal Thubert (pthubert) > Cc: Richard Kelsey; roll@ietf.org > Subject: Re: [Roll] proposal for DAOs in non-caching DODAGs >=20 > Pascal, >=20 > On Mar 28, 2010, at 11:33 PM, Pascal Thubert (pthubert) wrote: >=20 > > Hi John: > > > > I think I see what you're saying. > > > > If the metrics are asymmetrical, then it might occur that the DAO > > parents set is not the exact same as DIO parent set. A node would > > prefer a DAO parent for which the metrics from the root to the node > > are optimal. So theoretically following the preferred parent path > > provides the best metrics without using the DAO rank. > > >=20 > Exactly. We will need a way to find what the preferred DAO parent set is > though. Since we have agreed that the set can be different from the DODAG > preferred parent set, how can we do this without using DAO rank values? > (Read below and you will find out that I am not a big fan of this DAO rank > either :) Just that I don't have a smart answer yet.) >=20 > > The current spec enables the OF in a node to compute a DAO Rank based > > on the metrics option pretty much like a DIO Rank would be computed > > using a DAO DAG Metric Container. This was introduced at some point > > along the path and provides an additional capability to rate non preferred > paths. > > I figure that you're willing to emulate that in the source route DAO > > > > My take is that we have already added too much complexity even though > > we made it optional. I'd rather remove the DAO DAG Metric Container. > > But in any fashion I have to agree with your desire to make things > consistent. > > Then again, slippery slope towards link state... > > >=20 > I was asking about the DAO rank process just to make things clear before I go > and implement the stuff (after all this is what the specs want me to use at > least until now). I agree that computing separate rank values for DAOs are a > pain and can easily take up a lot of resources as the number of supported > prefixes increase. So I must say that I have little desire to make things > consistent but rather have the desire to make things simpler and working :) >=20 > Thanks. >=20 > -John >=20 > > Pascal > > > > > >> -----Original Message----- > >> From: JeongGil (John) Ko [mailto:jeonggil.ko@gmail.com] On Behalf Of > >> JeongGil Ko (John) > >> Sent: Monday, March 29, 2010 8:04 AM > >> To: Pascal Thubert (pthubert) > >> Cc: Richard Kelsey; roll@ietf.org > >> Subject: Re: [Roll] proposal for DAOs in non-caching DODAGs > >> > >> Hi Pascal, > >> > >> I see your point. One question, that confuses me is how the set of > > 'preferred > >> DAO parents' are determined. Is this set different from the preferred > > parent > >> set in DIOs? I guess another way of asking is to ask is how the > > DAORank is > >> defined and computed (this question was asked previously but I didn't > > really > >> get a clear answer). Will each node that initiates a DAO for a > > specific prefix be > >> DAORank =3D 1 and the rank computation continue just like the DIO > > process? In > >> this case is it true that each node may need to maintain different > > DAORank > >> values for many different prefixes? > >> > >> Thanks! > >> > >> -John > >> > >> On Mar 28, 2010, at 10:44 PM, Pascal Thubert (pthubert) wrote: > >> > >>> Hi John: > >>> > >>> Obviously, having multiple parents enables the root to compute > >>> multiple paths down to the node. So your proposal is tempting. But > >>> beware, this is a slippery slope towards centralized Link State > >>> computation and away from the RPL core design, and we can't be > >>> designing 2 protocols, by charter. > >>> > >>> The RPL design is that the choice of the best parents belongs to the > >>> OF in the node, not the root. Richard's proposal centralizes in the > >>> root the forwarding decision along the DAG that happens hop by hop > >>> with stateful DAOs, but the routing states are built in the exact > >>> same fashion whether it is stateful or stateless, by having each > > node > >>> select a set of preferred DAO parents. Note that we do not specify > > how > >>> a node selects the next hop between multiple DAO children in the > > stateful > >> mode. > >>> In the same fashion, we do not specify how the root makes the multi > >>> hop decision. > >>> > >>> My suggestion to address your problem would be that the OF in the > > node > >>> provides more info on how it orders the parents, maybe by setting a > >>> preference level (like 0-3) for each parent in the source route DAO. > >>> The root retains the possibility to build multiple non-overlapping > >>> path, do load balancing, signal to L2 when L2 paths/circuits need to > >>> be enabled, etc... We have not made the step towards a centralized > >> routing model. > >>> > >>> Cheers, > >>> > >>> Pascal > >>> > >>> > >>>> -----Original Message----- > >>>> From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On > > Behalf > >>> Of > >>>> JeongGil Ko (John) > >>>> Sent: Sunday, March 28, 2010 11:42 PM > >>>> To: Richard Kelsey > >>>> Cc: roll@ietf.org > >>>> Subject: Re: [Roll] proposal for DAOs in non-caching DODAGs > >>>> > >>>> Richard, > >>>> > >>>> I agree that if we start adding downwards routes then the root will > >>> have > >>>> many sub-route (or sub-path) information that it already has. If we > >>> decide > >>>> the add the neighbor (parent) information in the DAOs do we also > > add > >>> link > >>>> quality estimation values for each link associated with a parent > > node? > >>>> Otherwise the root will have a connectivity graph of the network > >>>> (DAG) > >>> but > >>>> will have no way to figure out which path is cost-efficient to > > select > >>> (the root > >>>> can come up with many combinations of paths to select from)? > >>>> > >>>> Thanks. > >>>> > >>>> -John > >>>> > >>>> On Mar 28, 2010, at 2:20 PM, Richard Kelsey wrote: > >>>> > >>>>> 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. > >>>>> > >>>>> 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. > >>>>> > >>>>> 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. > >>>>> > >>>>> 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. > >>>>> > >>>>> 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 > >>>>> > >>>>> What do people think? > >>>>> -Richard Kelsey > >>>>> _______________________________________________ > >>>>> 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 > >>> > >> > >> ------ > >> JeongGil Ko (John) > >> Ph.D. Student > >> Department of Computer Science > >> Johns Hopkins University > >> http://www.cs.jhu.edu/~jgko > > >=20 > ------ > JeongGil Ko (John) > Ph.D. Student > Department of Computer Science > Johns Hopkins University > http://www.cs.jhu.edu/~jgko From richard.kelsey@ember.com Mon Mar 29 04:32: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 B57A53A6A29 for ; Mon, 29 Mar 2010 04:32:34 -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 R7HxD01PGhdw for ; Mon, 29 Mar 2010 04:32:34 -0700 (PDT) Received: from EMPIRE.hq.ember.com (mail.ember.com [74.10.175.227]) by core3.amsl.com (Postfix) with ESMTP id 846C03A6A34 for ; Mon, 29 Mar 2010 04:32:03 -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, 29 Mar 2010 07:35:24 -0400 Date: Mon, 29 Mar 2010 07:29:41 -0400 Message-Id: <87fx3jmkm2.fsf@kelsey-ws.hq.ember.com> To: Mukul Goyal In-reply-to: <1130942942.736211269838649762.JavaMail.root@mail02.pantherlink.uwm.edu> (message from Mukul Goyal on Sun, 28 Mar 2010 23:57:29 -0500 (CDT)) From: Richard Kelsey References: <1130942942.736211269838649762.JavaMail.root@mail02.pantherlink.uwm.edu> X-OriginalArrivalTime: 29 Mar 2010 11:35:24.0873 (UTC) FILETIME=[EC549B90:01CACF33] 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: Mon, 29 Mar 2010 11:32:34 -0000 > Date: Sun, 28 Mar 2010 23:57:29 -0500 (CDT) > From: Mukul Goyal > > I was wondering if there was ever a discussion on the mailing list or > else where regarding why is it difficult to support mixed mode > operation. We know from the WG meeting at Anaheim that mixed mode > operation is difficult to support but it is not clear why. Speaking for myself, supporting mixed mode is both complex and can use up a lot of bandwidth. Numerous people have commented that RPL is too complicated, and much of the complexity comes from attempting to handle mixed-mode DODAGs efficiently. A key issue is the response to a change in parents. With caching, a node with a new parent sends a (potentially) large amount of data, its cache, one hop to the new parent. The parent in turn only forwards up those DAOs that are new to it. Without caching the node can send a small amount of data, its new parent, a (potentially) long distance. In a mixed network you get the worst of both. Because there may be a cache, the entire sub-DAGs worth of DAOs must be sent to the new parent, and non-caching nodes have to elicit and forward all of these DAOs, whether or not they are redundant. > Not supporting mixed mode operation is a major climb down for > RPL. In what way? It would definitely be nice to have, but there is no requirement for it. At least at Anaheim, there was a sense that no mixed-mode style of networks exist today. > This means that the introduction of even a single non-storing > router can turn a hitherto storing LLN into a non-storing one thereby > causing a major upheaval in the network as all the DAOs now have to > reach the root. My understanding is that a non-storing router can only join a storing DODAG as a host, the same as a router that does not understand the metric in use in the DODAG. There is no mechanism for changing a storing DODAG into a non-storing one. -Richard Kelsey From abr@sdesigns.dk Mon Mar 29 04:32: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 C365C3A6A38 for ; Mon, 29 Mar 2010 04:32:57 -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 VUncyezv2wuy for ; Mon, 29 Mar 2010 04:32:56 -0700 (PDT) Received: from mail.zen-sys.com (mail.zen-sys.com [195.215.56.170]) by core3.amsl.com (Postfix) with ESMTP id ADB483A6A26 for ; Mon, 29 Mar 2010 04:32:46 -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: Mon, 29 Mar 2010 13:33:13 +0200 Message-ID: <6D9687E95918C04A8B30A7D6DA805A3E01429FA1@zensys17.zensys.local> 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: AcrOvPYYMXCZA0o7SvShDKSUGdKOoAAcXRWw References: <87vdcg5eis.fsf@kelsey-ws.hq.ember.com> From: "Anders Brandt" To: "Richard Kelsey" , 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, 29 Mar 2010 11:32:57 -0000 > More interestingly, the reverse route stack is no longer=20 > needed. It is not used if all nodes cache DAOs. I think some very important details are missing here: Home and building requirements call for * P2P support - in particular * Expedited discovery of destination nodes for turning on lights * Near optimal (but not perfect) routing latency for saving battery Home requirements in particular call for * Support for low-cost nodes in the consumer space It is completely unrealistic for low-cost nodes to hold routing entries for all potential destinations downstream. Sorry. It is completely unrealistic for low-cost nodes to be in several DAGs. Sorry. To get a decent P2P route across branches, a DAG mechanism would have to do a lot of coordination. Let's face it: DAGs are good for P2MP and MP2P as long as there are only a few Ps. To get across branches would require a lot of neighbor monitoring, metric analysis, etc. Neighbor monitoring requires a lot of memory which low-cost nodes do not have. Communicating neighbor maps to other neighbors - or to the root - costs bandwidth and takes time that we may not have. I would prefer if we started to see the nodes as a mesh and used them as such. Expedited discovery messages with limited scope and Trickle scheduling is the way forward. Also start considering the notion of trading node cost against route quality. A low-cost node should be able to find a P2P route which works _good_enough_ within only a short period of time and do this with almost no RAM involved. We started some very interesting discussions in Anaheim. I really look forward to a proposal that claims to do all of the above. Please do not start finetuning DIOs, DAOs without considering P2P support as described above. My guess is that you may indeed end up needing route stacks in some more messages. =20 While we cannot see the need, neither know how to make it work, mixed mode may prove needed and powerful in the future. I therefore think that it is not so bad that we planned for one frame format in RPL until now. For the same reason I think that we should stick with the same frame format even when running RPL in single-mode, be that storing or non-storing. - Anders > -----Original Message----- > From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On=20 > Behalf Of Richard Kelsey > Sent: Sunday, March 28, 2010 23:21 > 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=20 > group confirms the decision to not explicitly support DAGs=20 > with mixed caching and non-caching routers. The obvious=20 > simplification is that the DIO 'S' flag is either on or off=20 > throughout a DODAG, eliminating the need to do anything when=20 > it changes. >=20 > More interestingly, the reverse route stack is no longer=20 > needed. It is not used if all nodes cache DAOs. If only the=20 > root does so, including intermediate hops when forwarding=20 > DAOs only duplicates information that the root will receive=20 > from others. >=20 > Our proposal is to replace the reverse route stack with a set=20 > of parents that is forwarded up the DAG to the root. > The DAO format stays the same, except that the reverse route=20 > stack is now a set of parents and is not changed when forwarded. >=20 > The root can then reconstruct the DAG and compute downwards=20 > 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=20 > paths to nodes whose S bit is not set. Path computation is=20 > simpler than for a full link-state protocol, as the DIOs have=20 > preselected the better up/down links in forming the DAG and=20 > other links are not reported. >=20 > The advantages of using a parent set rather than a reverse=20 > 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=20 > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll >=20 From richard.kelsey@ember.com Mon Mar 29 05:35: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 8FC193A68DB for ; Mon, 29 Mar 2010 05:35:00 -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 d8K5TMKqIBDW for ; Mon, 29 Mar 2010 05:34:59 -0700 (PDT) Received: from EMPIRE.hq.ember.com (mail.ember.com [74.10.175.227]) by core3.amsl.com (Postfix) with ESMTP id A71FE3A68BE for ; Mon, 29 Mar 2010 05:34: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); Mon, 29 Mar 2010 08:38:21 -0400 Date: Mon, 29 Mar 2010 08:32:37 -0400 Message-Id: <87eij3mhp6.fsf@kelsey-ws.hq.ember.com> To: "Anders Brandt" In-reply-to: <6D9687E95918C04A8B30A7D6DA805A3E01429FA1@zensys17.zensys.local> (abr@sdesigns.dk) From: Richard Kelsey References: <87vdcg5eis.fsf@kelsey-ws.hq.ember.com> <6D9687E95918C04A8B30A7D6DA805A3E01429FA1@zensys17.zensys.local> X-OriginalArrivalTime: 29 Mar 2010 12:38:21.0337 (UTC) FILETIME=[B7474890:01CACF3C] 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, 29 Mar 2010 12:35:00 -0000 > Date: Mon, 29 Mar 2010 13:33:13 +0200 > From: "Anders Brandt" > > > More interestingly, the reverse route stack is no longer > > needed. It is not used if all nodes cache DAOs. > > I think some very important details are missing here: > > Home and building requirements call for > * P2P support - in particular > * Expedited discovery of destination nodes for turning on lights > * Near optimal (but not perfect) routing latency for saving battery > > Home requirements in particular call for > * Support for low-cost nodes in the consumer space > > It is completely unrealistic for low-cost nodes to hold routing > entries for all potential destinations downstream. Sorry. I completely agree. What I was proposing was a relatively minor change to the DAO mechanism in order to make DAOs simpler, and also more efficient in networks of low-cost, non-DAO-storing nodes. The proposal is not intended to address P2P routing or expedited discovery or indeed any other requirement not met by the current DAO mechanism. I did not mention P2P routing in my posting. While P2P routing is a very important issue for ROLL, it is not the only issue. -Richard Kelsey From abr@sdesigns.dk Mon Mar 29 05:47: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 3C8483A6A62 for ; Mon, 29 Mar 2010 05:47:48 -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 F-apVacHKJUP for ; Mon, 29 Mar 2010 05:47:47 -0700 (PDT) Received: from mail.zen-sys.com (mail.zen-sys.com [195.215.56.170]) by core3.amsl.com (Postfix) with ESMTP id 453CE3A6898 for ; Mon, 29 Mar 2010 05:47:47 -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: Mon, 29 Mar 2010 14:48:14 +0200 Message-ID: <6D9687E95918C04A8B30A7D6DA805A3E01429FA6@zensys17.zensys.local> In-Reply-To: <87eij3mhp6.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: AcrPPFDW4lkayE3+SXeadV0qOmmRfAAASegA References: <87vdcg5eis.fsf@kelsey-ws.hq.ember.com> <6D9687E95918C04A8B30A7D6DA805A3E01429FA1@zensys17.zensys.local> <87eij3mhp6.fsf@kelsey-ws.hq.ember.com> From: "Anders Brandt" To: "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: Mon, 29 Mar 2010 12:47:48 -0000 Hi Richard I'm am sorry. I did not mean to hijack your threat. Just tried to suggest that this simplification may prevent us from adding P2P support. - Anders > -----Original Message----- > From: Richard Kelsey [mailto:richard.kelsey@ember.com]=20 > Sent: Monday, March 29, 2010 14:33 > To: Anders Brandt > Cc: roll@ietf.org > Subject: Re: [Roll] proposal for DAOs in non-caching DODAGs >=20 > > Date: Mon, 29 Mar 2010 13:33:13 +0200 > > From: "Anders Brandt" > >=20 > > > More interestingly, the reverse route stack is no longer=20 > needed. It=20 > > > is not used if all nodes cache DAOs. > >=20 > > I think some very important details are missing here: > >=20 > > Home and building requirements call for > > * P2P support - in particular > > * Expedited discovery of destination nodes for turning on lights > > * Near optimal (but not perfect) routing latency for=20 > saving battery > >=20 > > Home requirements in particular call for > > * Support for low-cost nodes in the consumer space > >=20 > > It is completely unrealistic for low-cost nodes to hold routing=20 > > entries for all potential destinations downstream. Sorry. >=20 > I completely agree. What I was proposing was a relatively=20 > minor change to the DAO mechanism in order to make DAOs=20 > simpler, and also more efficient in networks of low-cost,=20 > non-DAO-storing nodes. >=20 > The proposal is not intended to address P2P routing or=20 > expedited discovery or indeed any other requirement not met=20 > by the current DAO mechanism. I did not mention P2P routing=20 > in my posting. While P2P routing is a very important issue=20 > for ROLL, it is not the only issue. >=20 > -Richard Kelsey >=20 From Jerald.P.Martocci@jci.com Mon Mar 29 07:39: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 D707B3A693B; Mon, 29 Mar 2010 07:39:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.314 X-Spam-Level: X-Spam-Status: No, score=-1.314 tagged_above=-999 required=5 tests=[BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, 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 c5wn9-c3a21u; Mon, 29 Mar 2010 07:39:39 -0700 (PDT) Received: from exprod8og106.obsmtp.com (exprod8og106.obsmtp.com [64.18.3.92]) by core3.amsl.com (Postfix) with ESMTP id 7B36D3A696D; Mon, 29 Mar 2010 07:39:38 -0700 (PDT) Received: from source ([192.132.24.137]) (using SSLv3) by exprod8ob106.postini.com ([64.18.7.12]) with SMTP ID DSNKS7C7xDWq8oQAemC6fOfRAul709MjdalU@postini.com; Mon, 29 Mar 2010 07:40:07 PDT Received: from jwimkrs1.na.jci.com ([10.10.6.31]) by smtpmke01.jci.com (Lotus Domino Release 8.0.1) with ESMTP id 2010032909395807-87007 ; Mon, 29 Mar 2010 09:39:58 -0500 In-Reply-To: <87fx3jmkm2.fsf@kelsey-ws.hq.ember.com> References: <1130942942.736211269838649762.JavaMail.root@mail02.pantherlink.uwm.edu> <87fx3jmkm2.fsf@kelsey-ws.hq.ember.com> To: Richard Kelsey MIME-Version: 1.0 X-KeepSent: 82D55F36:B6E16F35-862576F5:004CC920; 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, 29 Mar 2010 09:39:52 -0500 X-MIMETrack: Serialize by Router on jwimkrs1.na.jci.com/NA/Johnson_Controls at 03/29/2010 09:39:58 AM, Serialize complete at 03/29/2010 09:39:58 AM, Itemize by SMTP Server on smtpmke01.jci.com/JCI_SMTP(Release 8.0.1|February 07, 2008) at 03/29/2010 09:39:58 AM, Serialize by Router on smtpmke01.jci.com/JCI_SMTP(Release 8.0.1|February 07, 2008) at 03/29/2010 09:40:05 AM, Serialize complete at 03/29/2010 09:40:05 AM Content-Type: text/html; charset="US-ASCII" Cc: roll@ietf.org, 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: Mon, 29 Mar 2010 14:39:40 -0000

Richard,

In Anaheim, we touched on the issue where a storing node has reached its storing capacity.  However, I don't believe we resolved the issue; that being if a node has max'd out  its storage, is the node now considered a 'non-storing' node and hence has to retreat to life as a leaf node?  I wouldn't think so, especially if the node is spatially defined in the middle of the DAG.  

I think that with the limited RAM available on these devices, running out of routing table space will be a frequent issue that we must consider.

Jerry



From: Richard Kelsey <richard.kelsey@ember.com>
To: Mukul Goyal <mukul@uwm.edu>
Cc: roll@ietf.org
Date: 03/29/2010 06:33 AM
Subject: Re: [Roll] Mixed mode operation




> Date: Sun, 28 Mar 2010 23:57:29 -0500 (CDT)
> From: Mukul Goyal <mukul@uwm.edu>
>
> I was wondering if there was ever a discussion on the mailing list or
> else where regarding why is it difficult to support mixed mode
> operation. We know from the WG meeting at Anaheim that mixed mode
> operation is difficult to support but it is not clear why.

Speaking for myself, supporting mixed mode is both complex
and can use up a lot of bandwidth.  Numerous people have
commented that RPL is too complicated, and much of the
complexity comes from attempting to handle mixed-mode DODAGs
efficiently.

A key issue is the response to a change in parents.  With
caching, a node with a new parent sends a (potentially)
large amount of data, its cache, one hop to the new parent.
The parent in turn only forwards up those DAOs that are new
to it.  Without caching the node can send a small amount of
data, its new parent, a (potentially) long distance.  In a
mixed network you get the worst of both.  Because there may
be a cache, the entire sub-DAGs worth of DAOs must be sent
to the new parent, and non-caching nodes have to elicit and
forward all of these DAOs, whether or not they are
redundant.

> Not supporting mixed mode operation is a major climb down for
> RPL.

In what way?  It would definitely be nice to have, but there
is no requirement for it.  At least at Anaheim, there was a
sense that no mixed-mode style of networks exist today.

> This means that the introduction of even a single non-storing
> router can turn a hitherto storing LLN into a non-storing one thereby
> causing a major upheaval in the network as all the DAOs now have to
> reach the root.

My understanding is that a non-storing router can only join
a storing DODAG as a host, the same as a router that does
not understand the metric in use in the DODAG.  There is no
mechanism for changing a storing DODAG into a non-storing one.

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

From Jerald.P.Martocci@jci.com Mon Mar 29 07:45: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 C3AB93A6941; Mon, 29 Mar 2010 07:45:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.314 X-Spam-Level: X-Spam-Status: No, score=-1.314 tagged_above=-999 required=5 tests=[BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, 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 O4fhRELb18J2; Mon, 29 Mar 2010 07:45:57 -0700 (PDT) Received: from exprod8og115.obsmtp.com (exprod8og115.obsmtp.com [64.18.3.30]) by core3.amsl.com (Postfix) with ESMTP id 7F4603A68B3; Mon, 29 Mar 2010 07:45:53 -0700 (PDT) Received: from source ([192.132.24.137]) (using SSLv3) by exprod8ob115.postini.com ([64.18.7.12]) with SMTP ID DSNKS7C9OrWzr9J2k8f6CeW5IewjA4dkhV6u@postini.com; Mon, 29 Mar 2010 07:46:22 PDT Received: from jwimkrs1.na.jci.com ([10.10.6.31]) by smtpmke01.jci.com (Lotus Domino Release 8.0.1) with ESMTP id 2010032909461196-87841 ; Mon, 29 Mar 2010 09:46:11 -0500 In-Reply-To: <6D9687E95918C04A8B30A7D6DA805A3E01429FA1@zensys17.zensys.local> References: <87vdcg5eis.fsf@kelsey-ws.hq.ember.com> <6D9687E95918C04A8B30A7D6DA805A3E01429FA1@zensys17.zensys.local> To: "Anders Brandt" MIME-Version: 1.0 X-KeepSent: ABC5E54D:796D950C-862576F5:0050C58F; 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, 29 Mar 2010 09:46:08 -0500 X-MIMETrack: Serialize by Router on jwimkrs1.na.jci.com/NA/Johnson_Controls at 03/29/2010 09:46:13 AM, Serialize complete at 03/29/2010 09:46:13 AM, Itemize by SMTP Server on smtpmke01.jci.com/JCI_SMTP(Release 8.0.1|February 07, 2008) at 03/29/2010 09:46:11 AM, Serialize by Router on smtpmke01.jci.com/JCI_SMTP(Release 8.0.1|February 07, 2008) at 03/29/2010 09:46:20 AM, Serialize complete at 03/29/2010 09:46:20 AM Content-Type: text/html; charset="US-ASCII" Cc: roll@ietf.org, roll-bounces@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, 29 Mar 2010 14:45:58 -0000
I completely agree with Anders.  We need P2P and we need it without undo routing overhead.  Please keep in mind that these devices are not routers; rather they are building (or home) controllers that happen to also route as a sidelight.  Most of their memory and processor resource is used up controlling the building, with a bit left over to route packets.

Jerry





From: "Anders Brandt" <abr@sdesigns.dk>
To: "Richard Kelsey" <richard.kelsey@ember.com>, <roll@ietf.org>
Date: 03/29/2010 06:33 AM
Subject: Re: [Roll] proposal for DAOs in non-caching DODAGs





> More interestingly, the reverse route stack is no longer
> needed.  It is not used if all nodes cache DAOs.

I think some very important details are missing here:

Home and building requirements call for
* P2P support - in particular
 * Expedited discovery of destination nodes for turning on lights
 * Near optimal (but not perfect) routing latency for saving battery

Home requirements in particular call for
* Support for low-cost nodes in the consumer space

It is completely unrealistic for low-cost nodes to hold routing
entries for all potential destinations downstream. Sorry.

It is completely unrealistic for low-cost nodes to be in several DAGs.
Sorry.

To get a decent P2P route across branches, a DAG mechanism would have
to do a lot of coordination. Let's face it: DAGs are good for P2MP and
MP2P as long as there are only a few Ps.
To get across branches would require a lot of neighbor monitoring,
metric analysis, etc.
Neighbor monitoring requires a lot of memory which low-cost nodes do not
have.
Communicating neighbor maps to other neighbors - or to the root - costs
bandwidth and takes time that we may not have.

I would prefer if we started to see the nodes as a mesh and used them as
such.
Expedited discovery messages with limited scope and Trickle scheduling
is the
way forward.
Also start considering the notion of trading node cost against route
quality.
A low-cost node should be able to find a P2P route which works
_good_enough_ within
only a short period of time and do this with almost no RAM involved.

We started some very interesting discussions in Anaheim.
I really look forward to a proposal that claims to do all of the above.

Please do not start finetuning DIOs, DAOs without considering P2P
support as described above.
My guess is that you may indeed end up needing route stacks in some more
messages.


While we cannot see the need, neither know how to make it work, mixed
mode may prove needed and
powerful in the future.
I therefore think that it is not so bad that we planned for one frame
format in RPL until now.
For the same reason I think that we should stick with the same frame
format even when running
RPL in single-mode, be that storing or non-storing.

- Anders

> -----Original Message-----
> From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On
> Behalf Of Richard Kelsey
> Sent: Sunday, March 28, 2010 23:21
> To: roll@ietf.org
> Subject: [Roll] proposal for DAOs in non-caching DODAGs
>
> 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.
>
> 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.
>
> 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.
>
> 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.
>
> 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
>
> What do people think?
>                                   -Richard Kelsey
> _______________________________________________
> Roll mailing list
> Roll@ietf.org
> https://www.ietf.org/mailman/listinfo/roll
>
_______________________________________________
Roll mailing list
Roll@ietf.org
https://www.ietf.org/mailman/listinfo/roll

From jhui@archrock.com Mon Mar 29 07:52: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 AD3563A693B for ; Mon, 29 Mar 2010 07:52:51 -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 6AF87wzrmCfc for ; Mon, 29 Mar 2010 07:52: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 C87093A68B3 for ; Mon, 29 Mar 2010 07:52:50 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.sf.archrock.com (Postfix) with ESMTP id 60F56AF94C; Mon, 29 Mar 2010 07:53:18 -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 L-qia8IlXD6K; Mon, 29 Mar 2010 07:53:13 -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 BAE5DAF915; Mon, 29 Mar 2010 07:53:13 -0700 (PDT) Message-Id: From: Jonathan Hui To: Mukul Goyal In-Reply-To: <1130942942.736211269838649762.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: Mon, 29 Mar 2010 07:53:13 -0700 References: <1130942942.736211269838649762.JavaMail.root@mail02.pantherlink.uwm.edu> X-Mailer: Apple Mail (2.936) 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: Mon, 29 Mar 2010 14:52:51 -0000 On Mar 28, 2010, at 9:57 PM, Mukul Goyal wrote: > I was wondering if there was ever a discussion on the mailing list > or else where regarding why is it difficult to support mixed mode > operation. We know from the WG meeting at Anaheim that mixed mode > operation is difficult to support but it is not clear why. Yes, we've had discussions on this mailing list explaining the asymptotic analysis of the currently proposed mechanism. I think it is more beneficial to ask the question from a different angle: Is there a mechanism to support mixed mode operation that is both well understood and widely deployed in LLNs today? This isn't the first time we've asked this question and we have yet to see a better proposal than what exists today. > Not supporting mixed mode operation is a major climb down for RPL. > This means that the introduction of even a single non-storing router > can turn a hitherto storing LLN into a non-storing one thereby > causing a major upheaval in the network as all the DAOs now have to > reach the root. Not supporting mixed-mode operation would be on-par with the industry today (which, for me, is a major goal). The point is that the LLN solutions that are shipping today assume either fully non-storing or fully storing. Any issues around that are being addressed without having to resort to mixed mode operation. A single non-storing router attaching to a storing LLN simply attaches as a host - any attempt to change the state of the entire network would not scale well. -- Jonathan Hui From pal@cs.stanford.edu Mon Mar 29 08:08: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 B3DF93A6A7E; Mon, 29 Mar 2010 08:08:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.023 X-Spam-Level: X-Spam-Status: No, score=-5.023 tagged_above=-999 required=5 tests=[AWL=0.445, 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 gdUfaP7Bs68E; Mon, 29 Mar 2010 08:08:31 -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 ED8DF3A6A5B; Mon, 29 Mar 2010 08:08:30 -0700 (PDT) Received: from [76.14.71.8] (helo=[192.168.1.103]) by cs-smtp-1.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1NwGaI-0000dh-Jq; Mon, 29 Mar 2010 08:08:58 -0700 Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: multipart/alternative; boundary=Apple-Mail-54--489637921 From: Philip Levis In-Reply-To: Date: Mon, 29 Mar 2010 08:08:58 -0700 Message-Id: References: <1130942942.736211269838649762.JavaMail.root@mail02.pantherlink.uwm.edu> <87fx3jmkm2.fsf@kelsey-ws.hq.ember.com> To: Jerald.P.Martocci@jci.com X-Mailer: Apple Mail (2.1077) X-Scan-Signature: 47150f6aa31409442f7db1cf5c00e98a Cc: roll@ietf.org, 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: Mon, 29 Mar 2010 15:08:31 -0000 --Apple-Mail-54--489637921 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Mar 29, 2010, at 7:39 AM, Jerald.P.Martocci@jci.com wrote: >=20 >=20 > Richard,=20 >=20 > In Anaheim, we touched on the issue where a storing node has reached = its storing capacity. However, I don't believe we resolved the issue; = that being if a node has max'd out its storage, is the node now = considered a 'non-storing' node and hence has to retreat to life as a = leaf node? I wouldn't think so, especially if the node is spatially = defined in the middle of the DAG. =20 >=20 > I think that with the limited RAM available on these devices, running = out of routing table space will be a frequent issue that we must = consider.=20 >=20 > Jerry=20 Jerry, As far as I know, there is no routing protocol today which resolves this = issue (RIP, OSPF, BGP, IS-IS, AODV, DSDV, DSR, DYMO, OLSR, Srcr, = CTP....?). It therefore seems like a (challenging) research problem: we = really should not put it on the critical path for specifying a standard. Phil= --Apple-Mail-54--489637921 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii
On Mar 29, 2010, at 7:39 AM, Jerald.P.Martocci@jci.com wrote:



Richard,

In Anaheim, we touched on the issue where a storing node has reached its storing capacity.  However, I don't believe we resolved the issue; that being if a node has max'd out  its storage, is the node now considered a 'non-storing' node and hence has to retreat to life as a leaf node?  I wouldn't think so, especially if the node is spatially defined in the middle of the DAG.  

I think that with the limited RAM available on these devices, running out of routing table space will be a frequent issue that we must consider.

Jerry

Jerry,

As far as I know, there is no routing protocol today which resolves this issue (RIP, OSPF, BGP, IS-IS, AODV, DSDV, DSR, DYMO, OLSR, Srcr, CTP....?). It therefore seems like a (challenging) research problem: we really should not put it on the critical path for specifying a standard.

Phil
--Apple-Mail-54--489637921-- From pal@cs.stanford.edu Mon Mar 29 08:15: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 3EBE43A67A5 for ; Mon, 29 Mar 2010 08:15:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.097 X-Spam-Level: X-Spam-Status: No, score=-5.097 tagged_above=-999 required=5 tests=[AWL=0.372, 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 1iwZ+0B4mgxz for ; Mon, 29 Mar 2010 08:15:27 -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 5AAC93A6781 for ; Mon, 29 Mar 2010 08:15:27 -0700 (PDT) Received: from [76.14.71.8] (helo=[192.168.1.103]) by cs-smtp-1.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1NwGh1-00012R-2T; Mon, 29 Mar 2010 08:15:55 -0700 Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Philip Levis In-Reply-To: <1130942942.736211269838649762.JavaMail.root@mail02.pantherlink.uwm.edu> Date: Mon, 29 Mar 2010 08:15:54 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <765E90E1-2E85-4213-8E4A-D38A29E241F8@cs.stanford.edu> References: <1130942942.736211269838649762.JavaMail.root@mail02.pantherlink.uwm.edu> To: Mukul Goyal X-Mailer: Apple Mail (2.1077) X-Scan-Signature: f219e97bb238ccbb8ed40879dafdba3c 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: Mon, 29 Mar 2010 15:15:28 -0000 On Mar 28, 2010, at 9:57 PM, Mukul Goyal wrote: > Hi all >=20 > I was wondering if there was ever a discussion on the mailing list or = else where regarding why is it difficult to support mixed mode = operation. We know from the WG meeting at Anaheim that mixed mode = operation is difficult to support but it is not clear why.=20 The simplest version of one of the problems is this: A -> ... -> B -> C -> ... -> Root B's sub-DAG is non-storing. C is storing. B changes its parent set such = that it has a new preferred parent D that is a storing node: A -> ... -> B -> D -> .... -> Root B now must request DAOs (and source routes) from its entire sub-DAG, so = they can be stored in D. D must also issue a new DAO to advertise these = prefixes. There might be cute and elegant solutions to these kinds of problems, = but I think Jonathan's point still holds: there are no networks today = which support this mode of operation. This means that 1) it's not a = critical requirement and 2) there are not well-understood solutions that = we can standardize and feel confident in. Phil= From pthubert@cisco.com Mon Mar 29 08:35: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 288FA3A6405 for ; Mon, 29 Mar 2010 08:35:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.747 X-Spam-Level: X-Spam-Status: No, score=-3.747 tagged_above=-999 required=5 tests=[AWL=-2.278, 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 zuVBMOIFw76X for ; Mon, 29 Mar 2010 08:35:34 -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 6C49F3A6ABD for ; Mon, 29 Mar 2010 08:35:34 -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: AokBAEtmsEuQ/uCWe2dsb2JhbACbKhUBAQsLIgYcp1mYZYUBBI4a X-IronPort-AV: E=Sophos;i="4.51,329,1267401600"; d="scan'208";a="4935686" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-2.cisco.com with ESMTP; 29 Mar 2010 15:01: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 o2TFZmpX000409; Mon, 29 Mar 2010 15:35:48 GMT Received: from xmb-ams-107.cisco.com ([144.254.74.82]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 29 Mar 2010 17:35: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: Mon, 29 Mar 2010 17:35:45 +0200 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D0188AE88@XMB-AMS-107.cisco.com> In-Reply-To: <765E90E1-2E85-4213-8E4A-D38A29E241F8@cs.stanford.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] Mixed mode operation Thread-Index: AcrPUr5rK9uskRB1Tfe+f8ezCz1/YAAAIbEg References: <1130942942.736211269838649762.JavaMail.root@mail02.pantherlink.uwm.edu> <765E90E1-2E85-4213-8E4A-D38A29E241F8@cs.stanford.edu> From: "Pascal Thubert (pthubert)" To: "Philip Levis" , "Mukul Goyal" X-OriginalArrivalTime: 29 Mar 2010 15:35:48.0483 (UTC) FILETIME=[8178D530:01CACF55] 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: Mon, 29 Mar 2010 15:35:36 -0000 Another angle is to ask ourselves what we can do simpler if we have the assumption that there is no mixed mode. I think that one such thing is illustrated by Richard's proposal in a parallel thread "Proposal for DAOs in non-caching DODAGs". Before (in 07) we had the complex S flag mechanism to sometimes save the costly cache repopulation that Phil depicts below. Implicitly, 07 also implied a tree so that when we are in non-caching world, and B advertises a SR path via D, the root knows that C->B is broken and recomputes D-> B-> A to reach A. After (with Richard's new proposal) a node can advertise multiple parents to the root, and in particular if C->B still works, B can advertise both C and D as DAO parents.=20 Suppressing the mixed mode operation enables us to support DAGs with no fan outs, and simplifies the protocol by removing the S-flag thing. Pascal > -----Original Message----- > From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of > Philip Levis > Sent: Monday, March 29, 2010 5:16 PM > To: Mukul Goyal > Cc: roll > Subject: Re: [Roll] Mixed mode operation >=20 >=20 > On Mar 28, 2010, at 9:57 PM, Mukul Goyal wrote: >=20 > > Hi all > > > > I was wondering if there was ever a discussion on the mailing list or else > where regarding why is it difficult to support mixed mode operation. We > know from the WG meeting at Anaheim that mixed mode operation is > difficult to support but it is not clear why. >=20 > The simplest version of one of the problems is this: >=20 > A -> ... -> B -> C -> ... -> Root >=20 > B's sub-DAG is non-storing. C is storing. B changes its parent set such that it > has a new preferred parent D that is a storing node: >=20 > A -> ... -> B -> D -> .... -> Root >=20 > B now must request DAOs (and source routes) from its entire sub-DAG, so > they can be stored in D. D must also issue a new DAO to advertise these > prefixes. >=20 > There might be cute and elegant solutions to these kinds of problems, but I > think Jonathan's point still holds: there are no networks today which support > this mode of operation. This means that 1) it's not a critical requirement and > 2) there are not well-understood solutions that we can standardize and feel > confident in. >=20 > Phil > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From root@core3.amsl.com Mon Mar 29 09:00: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 066BA3A6AAA; Mon, 29 Mar 2010 09:00:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20100329160002.066BA3A6AAA@core3.amsl.com> Date: Mon, 29 Mar 2010 09:00:02 -0700 (PDT) Cc: roll@ietf.org Subject: [Roll] I-D Action:draft-ietf-roll-terminology-03.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Mar 2010 16:00:02 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Routing Over Low power and Lossy networks Working Group of the IETF. Title : Terminology in Low power And Lossy Networks Author(s) : J. Vasseur Filename : draft-ietf-roll-terminology-03.txt Pages : 9 Date : 2010-03-29 The documents defines a terminology for discussing routing requirements and solutions for networks referred to as Low power and Lossy Networks (LLN). A LLN is typically composed of many embedded devices with limited power, memory, and processing resources interconnected by a variety of links. There is a wide scope of application areas for LLNs, including industrial monitoring, building automation (e.g. Heating, Ventilating, Air Conditioning, lighting, access control, fire), connected home, healthcare, environmental monitoring, urban sensor networks, energy management, assets tracking, refrigeration. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-roll-terminology-03.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-roll-terminology-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-03-29085231.I-D@ietf.org> --NextPart-- From mcr@sandelman.ca Mon Mar 29 09:13: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 5D61A3A6ABC for ; Mon, 29 Mar 2010 09:13:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.22 X-Spam-Level: * X-Spam-Status: No, score=1.22 tagged_above=-999 required=5 tests=[AWL=0.185, BAYES_20=-0.74, 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 xiOdPHRj91K1 for ; Mon, 29 Mar 2010 09:13:03 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by core3.amsl.com (Postfix) with ESMTP id 9E10D3A6AAF for ; Mon, 29 Mar 2010 09:12:28 -0700 (PDT) Received: from sandelman.ottawa.on.ca (desk.marajade.sandelman.ca [209.87.252.247]) by relay.sandelman.ca (Postfix) with ESMTPS id 52E6B34737 for ; Mon, 29 Mar 2010 12:10:20 -0400 (EDT) Received: from marajade.sandelman.ca (unknown [127.0.0.1]) by sandelman.ottawa.on.ca (Postfix) with ESMTP id 7A6064E7ED for ; Mon, 29 Mar 2010 12:12:55 -0400 (EDT) From: Michael Richardson To: roll In-Reply-To: References: <1130942942.736211269838649762.JavaMail.root@mail02.pantherlink.uwm.edu> X-Mailer: MH-E 8.1; nmh 1.1; XEmacs 21.4 (patch 21) Date: Mon, 29 Mar 2010 12:12:55 -0400 Message-ID: <9317.1269879175@marajade.sandelman.ca> Sender: mcr@sandelman.ca 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: Mon, 29 Mar 2010 16:13:06 -0000 >>>>> "Jonathan" == Jonathan Hui writes: Jonathan> Not supporting mixed-mode operation would be on-par with Jonathan> the industry today (which, for me, is a major goal). The Jonathan> point is that the LLN solutions that are shipping today Jonathan> assume either fully non-storing or fully storing. Any Jonathan> issues around that are being addressed without having to Jonathan> resort to mixed mode operation. What do deployed storing solutions do when the node runs out of space? -- ] 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 Mar 29 09:46: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 5AE713A6A8B for ; Mon, 29 Mar 2010 09:46:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.529 X-Spam-Level: * X-Spam-Status: No, score=1.529 tagged_above=-999 required=5 tests=[AWL=-0.247, BAYES_50=0.001, 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 pl1clITPt9-O for ; Mon, 29 Mar 2010 09:46:13 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by core3.amsl.com (Postfix) with ESMTP id 6EE343A6AF7 for ; Mon, 29 Mar 2010 09:46:05 -0700 (PDT) Received: from sandelman.ottawa.on.ca (desk.marajade.sandelman.ca [209.87.252.247]) by relay.sandelman.ca (Postfix) with ESMTPS id 299FF3439A for ; Mon, 29 Mar 2010 12:43:57 -0400 (EDT) Received: from marajade.sandelman.ca (unknown [127.0.0.1]) by sandelman.ottawa.on.ca (Postfix) with ESMTP id 36BC44E7ED for ; Mon, 29 Mar 2010 12:46:32 -0400 (EDT) From: Michael Richardson To: roll@ietf.org In-Reply-To: References: <1130942942.736211269838649762.JavaMail.root@mail02.pantherlink.uwm.edu> <87fx3jmkm2.fsf@kelsey-ws.hq.ember.com> X-Mailer: MH-E 8.1; nmh 1.1; XEmacs 21.4 (patch 21) Date: Mon, 29 Mar 2010 12:46:32 -0400 Message-ID: <11642.1269881192@marajade.sandelman.ca> Sender: mcr@sandelman.ca 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: Mon, 29 Mar 2010 16:46:14 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >>>>> "Jerald" == Jerald P Martocci writes: Jerald> In Anaheim, we touched on the issue where a storing node has Jerald> reached its storing capacity. However, I don't believe we Jerald> resolved the issue; Jerald> that being if a node has max'd out its storage, is the node Jerald> now considered a 'non-storing' node and hence has to retreat Jerald> to life as a leaf node? I wouldn't think so, especially if Jerald> the node is spatially defined in the middle of the DAG. I was an advocate of not dealing with mix storing/non-storing. If we have an efficient solution for the storing/non-storing, then we could say that a storing node that is full becomes non-storing. If we do not have such a solution, then it seems that when a node becomes full in an all-storing network, then yes, it has to become a leaf. I think it was clear from the beginning that all-storing networks have the downside that all storing nodes have to have enough capacity at every intermediate node. And that this is a natural limit to scaling of the network. If we get the set of MUSTs and MAYs correct, then all-storing networks should always be able to operate as non-storing networks (at least for some DODAGs!), so I see this as less of a serious issue. I think we should maintain the mixed-mode flag bits in the headers, but define the value to be non-mixed for now. This leaves us the ability to signal a mixed-DAG for those that want to experiment. I think that the better p2p algorithms will come out this experimentation. - -- ] 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 iQEVAwUBS7DZZoCLcPvd0N1lAQI+Owf/dwqsPM59aK6V4U+l1sQ06klu2V6djSMQ jqyWi57kqLH9YRR3SugHAO7wZOqiTbduBag94FviDPIUmieonf++YFXLRdit6ipf 8l/KscZa2ijbR+ZgT1i1gDlS1/Ong3EieZIP0pDKrpcclz7Qdio6X1nYHfMqeT1y OsNZjFmHrreQkKKJHfOczNdFXLyPhHZssH53WVYMBVUdCR2dVbrvxlNpVfP73wGt aF3HaHEIB6VWcmsCZm/ovxPo3ffg5aiXXyEHD1ojB1L09qpqjwHCzCKk5dPO9/ns OoQ8tEKtoQVRRaUukaoHj6kzBmt6qe8p0wtffRTMGOvFs+Ud3rN7yA== =U5nv -----END PGP SIGNATURE----- From Jerald.P.Martocci@jci.com Mon Mar 29 09:55: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 764B73A6AC7; Mon, 29 Mar 2010 09:55:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.614 X-Spam-Level: X-Spam-Status: No, score=-2.614 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, 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 g1tNyFxcNgYM; Mon, 29 Mar 2010 09:55:41 -0700 (PDT) Received: from exprod8og112.obsmtp.com (exprod8og112.obsmtp.com [64.18.3.24]) by core3.amsl.com (Postfix) with ESMTP id 2F9113A6AB0; Mon, 29 Mar 2010 09:55:41 -0700 (PDT) Received: from source ([192.132.24.139]) (using SSLv3) by exprod8ob112.postini.com ([64.18.7.12]) with SMTP ID DSNKS7DbqOrg53904OKgJy7xFR0GlzVzcQNz@postini.com; Mon, 29 Mar 2010 09:56:09 PDT Received: from jwimkrs1.na.jci.com ([10.10.6.31]) by smtpmke02.jci.com (Lotus Domino Release 8.0.1) with ESMTP id 2010032911555479-106639 ; Mon, 29 Mar 2010 11:55:54 -0500 In-Reply-To: References: <1130942942.736211269838649762.JavaMail.root@mail02.pantherlink.uwm.edu> <87fx3jmkm2.fsf@kelsey-ws.hq.ember.com> To: Philip Levis MIME-Version: 1.0 X-KeepSent: E34361AF:3549D84E-862576F5:00575960; 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, 29 Mar 2010 11:55:54 -0500 X-MIMETrack: Serialize by Router on jwimkrs1.na.jci.com/NA/Johnson_Controls at 03/29/2010 11:56:01 AM, Serialize complete at 03/29/2010 11:56:01 AM, Itemize by SMTP Server on smtpmke02.jci.com/JCI_SMTP(Release 8.0.1|February 07, 2008) at 03/29/2010 11:55:54 AM, Serialize by Router on smtpmke02.jci.com/JCI_SMTP(Release 8.0.1|February 07, 2008) at 03/29/2010 11:56:03 AM, Serialize complete at 03/29/2010 11:56:03 AM Content-Type: text/html; charset="US-ASCII" Cc: roll@ietf.org, 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: Mon, 29 Mar 2010 16:55:42 -0000

Phil,

I'm only trying to be pragmatic.  If nodes are holding state for other nodes in the DAG, then I would think that depending on the node's relative rank in the DAG; nodes higher (i.e. closer to the LBR) in the DAG would be required to hold more state. That is, nodes would need to hold state for all nodes 'below' them in the DAG.  Since rank is a function of spatial placement, this means that a node cannot a priori set aside a fixed set of RAM for routing tables.  That said, I would think filling up the routing table would be quite common.

What I'm asking is what should a node do when its table fills?  Should it not accept new requests? Drop the Least Recently Used? Drop the first entry? the last entry?  I think this needs to be documented for interoperability.  What table management policy would have the least impact on node-to-node connectivity?

Jerry




From: Philip Levis <pal@cs.stanford.edu>
To: Jerald.P.Martocci@jci.com
Cc: Richard Kelsey <richard.kelsey@ember.com>, roll@ietf.org, roll-bounces@ietf.org
Date: 03/29/2010 10:09 AM
Subject: Re: [Roll] Mixed mode operation





On Mar 29, 2010, at 7:39 AM, Jerald.P.Martocci@jci.com wrote:



Richard,

In Anaheim, we touched on the issue where a storing node has reached its storing capacity.  However, I don't believe we resolved the issue; that being if a node has max'd out  its storage, is the node now considered a 'non-storing' node and hence has to retreat to life as a leaf node?  I wouldn't think so, especially if the node is spatially defined in the middle of the DAG.  

I think that with the limited RAM available on these devices, running out of routing table space will be a frequent issue that we must consider.

Jerry

Jerry,

As far as I know, there is no routing protocol today which resolves this issue (RIP, OSPF, BGP, IS-IS, AODV, DSDV, DSR, DYMO, OLSR, Srcr, CTP....?). It therefore seems like a (challenging) research problem: we really should not put it on the critical path for specifying a standard.

Phil

From d.sturek@att.net Mon Mar 29 10:08: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 8601E3A6AF8 for ; Mon, 29 Mar 2010 10:08:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.317 X-Spam-Level: ** X-Spam-Status: No, score=2.317 tagged_above=-999 required=5 tests=[AWL=-0.264, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, 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 KZdfc2nHiN2S for ; Mon, 29 Mar 2010 10:08:31 -0700 (PDT) Received: from smtp111.sbc.mail.mud.yahoo.com (smtp111.sbc.mail.mud.yahoo.com [68.142.198.207]) by core3.amsl.com (Postfix) with SMTP id 410653A6B00 for ; Mon, 29 Mar 2010 10:08:28 -0700 (PDT) Received: (qmail 95042 invoked from network); 29 Mar 2010 17:08:50 -0000 Received: from Studio (d.sturek@69.224.122.37 with login) by smtp111.sbc.mail.mud.yahoo.com with SMTP; 29 Mar 2010 10:08:50 -0700 PDT X-Yahoo-SMTP: fvjol_aswBAraSJvMLe2r1XTzhBhbFxY8q8c3jo- X-YMail-OSG: 4c_24OIVM1kiM9paJecdEMgX8cGnx.OeUS6Hh8w4Iza4os_SZewjrBIaNByTtSyGVHICf7FnMB9CSLIOtlSNtcmHU2j08f0SjCkyG4SizDl0ZAvHeOBnHSW1RqBy7hrSKPYyS1YqqRJzL_M.ErFR_cVJpNbX7dplEnS7HFd5u2mXPehiGiMR80ySBruCHkSJ7fEmYGTNoXFZ00dYjgPVX.ckwmUTIQXyjJdGC2D6GCRdOXmKdqs.6NxNiJfEo0cVbsIoELwnZKgYBPG44NGYlcmonGQ0Lv_cDchppupuOtLllblVESKI X-Yahoo-Newman-Property: ymail-3 From: "Don Sturek" To: "'Michael Richardson'" , "'roll'" References: <1130942942.736211269838649762.JavaMail.root@mail02.pantherlink.uwm.edu> <9317.1269879175@marajade.sandelman.ca> In-Reply-To: <9317.1269879175@marajade.sandelman.ca> Date: Mon, 29 Mar 2010 10:08:47 -0700 Message-ID: <01b901cacf62$7f3e89b0$7dbb9d10$@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: AcrPWsmd+GLeIrniSKisorsusXAmGgAB4yqQ Content-Language: en-us Subject: Re: [Roll] Mixed mode 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: Mon, 29 Mar 2010 17:08:32 -0000 Storing devices that are out of resources to store either need to become non-storing (if that is legal in the DAG they are a member) or must become leaf devices. I don't see any other alternative. Internally, they can do some table management/freeing of resources but I would not expect to see that in the specification. Don -----Original Message----- From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Michael Richardson Sent: Monday, March 29, 2010 9:13 AM To: roll Subject: Re: [Roll] Mixed mode operation >>>>> "Jonathan" == Jonathan Hui writes: Jonathan> Not supporting mixed-mode operation would be on-par with Jonathan> the industry today (which, for me, is a major goal). The Jonathan> point is that the LLN solutions that are shipping today Jonathan> assume either fully non-storing or fully storing. Any Jonathan> issues around that are being addressed without having to Jonathan> resort to mixed mode operation. What do deployed storing solutions do when the node runs out of space? -- ] He who is tired of Weird Al is tired of life! | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ Kyoto Plus: watch the video then sign the petition. _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From mcr@sandelman.ca Mon Mar 29 10:41: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 B0F003A6ABF for ; Mon, 29 Mar 2010 10:41:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.591 X-Spam-Level: * X-Spam-Status: No, score=1.591 tagged_above=-999 required=5 tests=[AWL=-0.185, BAYES_50=0.001, 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 exwXxX1uNUam for ; Mon, 29 Mar 2010 10:41:18 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by core3.amsl.com (Postfix) with ESMTP id 826643A6894 for ; Mon, 29 Mar 2010 10:41:18 -0700 (PDT) Received: from sandelman.ottawa.on.ca (desk.marajade.sandelman.ca [209.87.252.247]) by relay.sandelman.ca (Postfix) with ESMTPS id CBF0234573; Mon, 29 Mar 2010 13:39:10 -0400 (EDT) Received: from marajade.sandelman.ca (unknown [127.0.0.1]) by sandelman.ottawa.on.ca (Postfix) with ESMTP id 837DD4E7ED; Mon, 29 Mar 2010 13:41:45 -0400 (EDT) From: Michael Richardson To: roll@ietf.org In-Reply-To: <6D9687E95918C04A8B30A7D6DA805A3E01429FA1@zensys17.zensys.local> References: <87vdcg5eis.fsf@kelsey-ws.hq.ember.com> <6D9687E95918C04A8B30A7D6DA805A3E01429FA1@zensys17.zensys.local> X-Mailer: MH-E 8.1; nmh 1.1; XEmacs 21.4 (patch 21) Date: Mon, 29 Mar 2010 13:41:45 -0400 Message-ID: <16096.1269884505@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, 29 Mar 2010 17:41:20 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >>>>> "Anders" == Anders Brandt writes: >> More interestingly, the reverse route stack is no longer >> needed. It is not used if all nodes cache DAOs. Anders> I think some very important details are missing here: Anders> Home and building requirements call for I agree that the protocol as it is misses this. But, I do not understand how the proposal changes the situation? Anders> I would prefer if we started to see the nodes as a mesh and Anders> used them as such. Anders> Expedited discovery messages with limited scope and Trickle Anders> scheduling is the way forward. I think you are saying that RPL (whether all-storing, non-storing, or mixed-storing) does not solve your requirements. - -- ] 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 iQEVAwUBS7DmV4CLcPvd0N1lAQKvKgf/bbztV8er87hLwPKhSAaX++8W0z9Aitev 6yt3l0x05QQ3M82FGxcV37M3Nyq9O4bz073buTAkFgBZdYbGu4Kz3iLEaSJnf+Fq fv02+uW9wSfX1crW53D6liuV3PS9FNj9njmQu+zcBXA9RhfHrDTQJFgFS+OLJw0m ITRi4XwCt7ODbJSaSZ6SDvsPgLV96VFCWypWcuUEby4EarbmdMGTN7NqAOvrnZUI ekai/WFw6P0o4cpkywcUPPvSOFFdHKE5kmUnL4Yve9FcQWAeeWtfNAK9Fy2AoiKq 2tJvqG9Nn+ZEqf4qvCZbUp6naUxYVeUjYulUhZHOHnT7v9Lb5Gj1iw== =L1jf -----END PGP SIGNATURE----- From mcr@sandelman.ca Mon Mar 29 11: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 45F893A6927 for ; Mon, 29 Mar 2010 11:36:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.328 X-Spam-Level: X-Spam-Status: No, score=0.328 tagged_above=-999 required=5 tests=[AWL=1.152, 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 bksUJIDi8+ja for ; Mon, 29 Mar 2010 11:36:49 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by core3.amsl.com (Postfix) with ESMTP id 613D03A690F for ; Mon, 29 Mar 2010 11:36:48 -0700 (PDT) Received: from sandelman.ottawa.on.ca (desk.marajade.sandelman.ca [209.87.252.247]) by relay.sandelman.ca (Postfix) with ESMTPS id 5C1273471A; Mon, 29 Mar 2010 14:34:41 -0400 (EDT) Received: from marajade.sandelman.ca (unknown [127.0.0.1]) by sandelman.ottawa.on.ca (Postfix) with ESMTP id 0504C4E7EE; Mon, 29 Mar 2010 14:37:16 -0400 (EDT) From: Michael Richardson To: d.sturek@att.net In-Reply-To: <01b901cacf62$7f3e89b0$7dbb9d10$@sturek@att.net> References: <1130942942.736211269838649762.JavaMail.root@mail02.pantherlink.uwm.edu> <9317.1269879175@marajade.sandelman.ca> <01b901cacf62$7f3e89b0$7dbb9d10$@sturek@att.net> X-Mailer: MH-E 8.1; nmh 1.1; XEmacs 21.4 (patch 21) Date: Mon, 29 Mar 2010 14:37:15 -0400 Message-ID: <20100.1269887835@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: Mon, 29 Mar 2010 18:36:50 -0000 >>>>> "Don" == Don Sturek writes: Don> Storing devices that are out of resources to store either need Don> to become non-storing (if that is legal in the DAG they are a Don> member) or must become Don> leaf devices. I don't see any other alternative. I wasn't asking about RPL. I was asking about current (proprietary) deployed solutions. There is a belief that the mixed mode has never been deployed in any proprietary solution. Given that, in networks with storing nodes, when the node gets full, what happens? -- ] 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 Mar 29 11:48: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 6E4BF3A6858 for ; Mon, 29 Mar 2010 11:48:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.436 X-Spam-Level: * X-Spam-Status: No, score=1.436 tagged_above=-999 required=5 tests=[AWL=-0.340, BAYES_50=0.001, 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 HntTXfMRWKda for ; Mon, 29 Mar 2010 11:48:04 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by core3.amsl.com (Postfix) with ESMTP id 3FB303A6AC3 for ; Mon, 29 Mar 2010 11:48:04 -0700 (PDT) Received: from sandelman.ottawa.on.ca (desk.marajade.sandelman.ca [209.87.252.247]) by relay.sandelman.ca (Postfix) with ESMTPS id 7CE71345E6 for ; Mon, 29 Mar 2010 14:45:56 -0400 (EDT) Received: from marajade.sandelman.ca (unknown [127.0.0.1]) by sandelman.ottawa.on.ca (Postfix) with ESMTP id 30E764E7ED for ; Mon, 29 Mar 2010 14:48:31 -0400 (EDT) From: Michael Richardson To: roll@ietf.org In-Reply-To: References: <1130942942.736211269838649762.JavaMail.root@mail02.pantherlink.uwm.edu> <87fx3jmkm2.fsf@kelsey-ws.hq.ember.com> X-Mailer: MH-E 8.1; nmh 1.1; XEmacs 21.4 (patch 21) Date: Mon, 29 Mar 2010 14:48:31 -0400 Message-ID: <20899.1269888511@marajade.sandelman.ca> Sender: mcr@sandelman.ca 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: Mon, 29 Mar 2010 18:48:05 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >>>>> "Jerald" == Jerald P Martocci writes: Jerald> Phil, I'm only trying to be pragmatic. If nodes are Jerald> holding state for other nodes in the DAG, then I would think Jerald> that depending on the node's relative rank in the DAG; nodes Jerald> higher (i.e. closer to the LBR) in the DAG would be required Jerald> to hold more state. That is, nodes would need to hold state Jerald> for all nodes 'below' them in the DAG. And, since the network is self-organizing, we may not know apriori which nodes are closer to the LBR, and which are not (and how this changes when nodes fail, batteries run down, etc.) so in fact, we can't really guess which nodes need more storage than others. (I imagine that there could be quite an on-site industry to optimize such networks given some actual data) Jerald> Since rank is a Jerald> function of spatial placement, this means that a node cannot Jerald> a priori set aside a fixed set of RAM for routing tables. Jerald> That said, I would think filling up the routing table would Jerald> be quite common. What I'm asking is what should a node do Jerald> when its table fills? Should it not accept new requests? Jerald> Drop the Least Recently Used? Drop the first entry? the last Jerald> entry? I think this needs to be documented for Jerald> interoperability. What table management policy would have Jerald> the least impact on node-to-node connectivity? Jerry Let me rewrite your options, because I agree the question is very important, and has not been addressed. (Can we open an issue for this?) 1) Drop the Least Recently Used? LRU here means that we've relayed traffic to this node. If the node is in fact active, but not through this node, this is appealing because it might be that in fact the layers above this node have already decided that our node is not in the path. I have major concerns that this mechanism is too traffic dependant to properly analyze in a simulation. 2) Drop the first entry? This entry would be the oldest, and therefore we might never hear from this node again. The major concern I have is that it will lead to a kind of race where nodes work for awhile, and then we can't talk to them again as the network grows. However, when we hear from this node again, it displaces another node. This is LRU, but now not based upon traffic to the node, but rather based upon hearing DIOs from it. 3) Drop the last entry? This might be a compelling mechanism. When the table is full, it's full. No churn. No needless processing. This might be the lowest power mechanism for some architectures. This does create a different kind of race -- first nodes to boot and network win. But, if you have a stable network, it likely STAYS that way. - -- ] 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 iQEVAwUBS7D1/ICLcPvd0N1lAQIlyQf9HhuN0LV35pIfjE70i/ZsuBvMw14e3IT3 /a7AVg5xW6QzueQbZIlPqQdw2YPj3sDk0ca1MPFQPyD1eSt+8CEbleBYQ0/hzjln N7aDGsdhHrLYKMZ5bAd6v2gT+UPH0x4lkKdwHFHav8mhn5EnVXsqm5y2cSpokR/6 0BdRQdNnNeXInsxGfdchWa32bTsgrES99vQAlBCO2rsekEfKP+W1pn4Tc3TPgGNR ad2ilMkb1J2v0UeqmlUKz4+tKrxvsSMdDKZfpN2r6HgTvaq/CDgHqrmTT8LFJ0YT C1uh4EgKVddiDUXkuMoZXu0jsHK4/05eqc0WscXw+8sEtKxF9ON/Yw== =LETv -----END PGP SIGNATURE----- From Jerald.P.Martocci@jci.com Mon Mar 29 12:10: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 C6F153A69E7; Mon, 29 Mar 2010 12:10:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[AWL=0.046, BAYES_20=-0.74, DNS_FROM_OPENWHOIS=1.13, 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 Fa7n864-elRJ; Mon, 29 Mar 2010 12:10:58 -0700 (PDT) Received: from exprod8og104.obsmtp.com (exprod8og104.obsmtp.com [64.18.3.88]) by core3.amsl.com (Postfix) with ESMTP id C668C3A6971; Mon, 29 Mar 2010 12:10:57 -0700 (PDT) Received: from source ([192.132.24.139]) (using SSLv3) by exprod8ob104.postini.com ([64.18.7.12]) with SMTP ID DSNKS7D7XbM0OG7Osf5IZRc/IeMyH/KCCczp@postini.com; Mon, 29 Mar 2010 12:11:26 PDT Received: from jwimkrs1.na.jci.com ([10.10.6.31]) by smtpmke02.jci.com (Lotus Domino Release 8.0.1) with ESMTP id 2010032914111115-124290 ; Mon, 29 Mar 2010 14:11:11 -0500 In-Reply-To: <01b901cacf62$7f3e89b0$7dbb9d10$@sturek@att.net> References: <1130942942.736211269838649762.JavaMail.root@mail02.pantherlink.uwm.edu> <9317.1269879175@marajade.sandelman.ca> <01b901cacf62$7f3e89b0$7dbb9d10$@sturek@att.net> To: d.sturek@att.net MIME-Version: 1.0 X-KeepSent: CD2329CD:BB40133F-862576F5:0068B3C2; 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, 29 Mar 2010 14:11:15 -0500 X-MIMETrack: Serialize by Router on jwimkrs1.na.jci.com/NA/Johnson_Controls at 03/29/2010 02:11:17 PM, Serialize complete at 03/29/2010 02:11:17 PM, Itemize by SMTP Server on smtpmke02.jci.com/JCI_SMTP(Release 8.0.1|February 07, 2008) at 03/29/2010 02:11:11 PM, Serialize by Router on smtpmke02.jci.com/JCI_SMTP(Release 8.0.1|February 07, 2008) at 03/29/2010 02:11:20 PM, Serialize complete at 03/29/2010 02:11:20 PM Content-Type: text/html; charset="US-ASCII" Cc: roll-bounces@ietf.org, '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: Mon, 29 Mar 2010 19:10:59 -0000

Hi Don,

Don't you think it's scary for a node to just down-shift to being a leaf node if it's out of resources?  In our implementations, nodes closest to the LBR tend to have the most traffic.  The traffic level diminishes as the node is placed farther from the LBR.  Since we can't control node placement in a jobsite, it's likely that all the LBR neighbors will run our of memory first.  If they drop down to 'leafs', that renders the whole DAG beneath them unusable.  That would not be a good thing!  somehow, we need to manage the routing table resource.

Jerry



From: "Don Sturek" <d.sturek@att.net>
To: "'Michael Richardson'" <mcr@sandelman.ca>, "'roll'" <roll@ietf.org>
Date: 03/29/2010 12:09 PM
Subject: Re: [Roll] Mixed mode operation




Storing devices that are out of resources to store either need to become
non-storing (if that is legal in the DAG they are a member) or must become
leaf devices.  I don't see any other alternative.

Internally, they can do some table management/freeing of resources but I
would not expect to see that in the specification.

Don


-----Original Message-----
From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of
Michael Richardson
Sent: Monday, March 29, 2010 9:13 AM
To: roll
Subject: Re: [Roll] Mixed mode operation


>>>>> "Jonathan" == Jonathan Hui <jhui@archrock.com> writes:
   Jonathan> Not supporting mixed-mode operation would be on-par with
   Jonathan> the industry  today (which, for me, is a major goal).  The
   Jonathan> point is that the LLN  solutions that are shipping today
   Jonathan> assume either fully non-storing or  fully storing.  Any
   Jonathan> issues around that are being addressed without  having to
   Jonathan> resort to mixed mode operation.

What do deployed storing solutions do when the node runs out of space?

--
]       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.youtube.com/watch?v=kzx1ycLXQSE>
                               then sign the petition.
_______________________________________________
Roll mailing 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 Mon Mar 29 12:30: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 B94AD3A69E7 for ; Mon, 29 Mar 2010 12:30:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.519 X-Spam-Level: X-Spam-Status: No, score=-3.519 tagged_above=-999 required=5 tests=[AWL=-4.651, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, 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 jaIDwbkp7mMk for ; Mon, 29 Mar 2010 12:30:46 -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 A43883A65A6 for ; Mon, 29 Mar 2010 12:30:42 -0700 (PDT) Authentication-Results: ams-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: AsoBAEudsEuQ/uCWe2dsb2JhbACBPplnFQEBCwsiBhynHZhmhQEE X-IronPort-AV: E=Sophos;i="4.51,329,1267401600"; d="xml'?xlsx'72,48?scan'72,48,208,145,48,72,217?jpeg'72,48,208,145,48,72,217,145?rels'72,48,208,145,48,72,217,145"; a="4941989" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-2.cisco.com with ESMTP; 29 Mar 2010 18:56:30 +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 o2TJV9io009283 for ; Mon, 29 Mar 2010 19:31:09 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); Mon, 29 Mar 2010 21:31:09 +0200 Received: from dhcp-144-254-20-202.cisco.com ([144.254.20.202]) by xfe-ams-202.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 29 Mar 2010 21:31:08 +0200 Message-Id: <68182A3F-0D29-4F8A-9711-F71A8950DC21@cisco.com> From: JP Vasseur To: ROLL WG Content-Type: multipart/alternative; boundary=Apple-Mail-83--473908197 Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 29 Mar 2010 21:31:07 +0200 X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 29 Mar 2010 19:31:08.0506 (UTC) FILETIME=[61A95BA0:01CACF76] Subject: [Roll] Ticket # 25 - Tracking the MUST requirement X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 29 Mar 2010 19:30:47 -0000 --Apple-Mail-83--473908197 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Dear WG, I put together a spreadsheet to track the "MUST requirements" spelled out in our four requirements documents. To that end, I listed all MUST and used the following color code: GREEN: Satisfied requirement YELLOW: the requirement is partially satisfied and the WG thinks that the requirement is not sufficiently satisfied. For example: Support of Point-to-Point: "The routing protocol MUST provide routes between arbitrary hosts within the appropriate administrative domain". Strictly speaking RPL supports P2P but the WG thinks that more work is required, thus the Yellow color RED: the requirement is not satisfied (e.g. additional mechanisms required) or not yet done (e.g. security) PINK: the requirement is partially satisfied or non satisfied but the WG decided that this was acceptable. It may be wise to document it. GREY: Evaluation is differed (not a show stopper for LC). For example, it may take time to deploy a network with few dozens of thousands of nodes. Note that in this case, simulations may help. Let's continue to work on our opened tickets and update that spreadsheet accordingly. Note that in both the YELLOW and RED cases, RPL could not be last called until they turn GREEN. Comments very welcome of course. Thanks. JP. --Apple-Mail-83--473908197 Content-Type: multipart/mixed; boundary=Apple-Mail-84--473908197 --Apple-Mail-84--473908197 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Dear WG,

I = put together a spreadsheet to track the "MUST requirements" spelled out = in our four requirements documents.

To that = end, I listed all MUST and used the following color = code:

GREEN: Satisfied = requirement

YELLOW: the = requirement is partially satisfied and the WG thinks that the = requirement is not sufficiently satisfied.

For = example:
Support of = Point-to-Point: "The routing protocol MUST provide routes between = arbitrary hosts within the = appropriate 
administrative domain". Strictly speaking RPL supports P2P but the = WG thinks that more work is required, thus = the 

RED: the = requirement is not satisfied (e.g. additional mechanisms required) or = not yet done (e.g. security)

PINK: the = requirement is partially satisfied or non satisfied but the WG decided = that this was acceptable. It may 
be wise to document = it.

GREY: Evaluation is differed (not a show = stopper for LC). For example, it may take time to deploy a network = with
few dozens of thousands of nodes. Note that in this case, = simulations may help.

Let's continue to work on = our opened tickets and update that spreadsheet = accordingly.

Note that in both the = YELLOW and RED cases, RPL could not be last called until they turn = GREEN.

Comments very welcome = of = course.

Thanks.

JP. = ;

= --Apple-Mail-84--473908197 Content-Disposition: attachment; filename=RPL-MUST.xlsx Content-Type: application/vnd.openxmlformats-officedocument.spreadsheetml.sheet; x-mac-creator=5843454C; x-unix-mode=0644; x-mac-type=584C5358; name="RPL-MUST.xlsx" Content-Transfer-Encoding: base64 UEsDBBQABgAIAAAAIQDdsQorbwEAAMQEAAATAM0BW0NvbnRlbnRfVHlwZXNdLnhtbCCiyQEooAAC AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAArFRb T8IwFH438T8sfTVbwQdjDIMHL49KIv6A2p5tld7SUxD+vV1BossECbxsWZvvkvN9Z6PJSqtsCR6l NSUZFgOSgeFWSFOX5G32lN+SDAMzgilroCRrQDIZX16MZmsHmEW0wZI0Ibg7SpE3oBkW1oGJN5X1 moX46WvqGJ+zGuj1YHBDuTUBTMhDy0HGo5dowEsB2ZT58Mx01KHC8qm3DilzrohkJLvfoFrhksRT JTkL0TZdGtGRzG1VSQ6RY6GjUAGrqCdA5C5Sgg8S8KrlpP3aK0U/rZ9jAxCQptfwZA/oPDCRyLQq dvz/8PFu7fzM8slGoZk0+/R3GXDr4XgH28yLFt0z+Qeo2EKF7LENZ9O//TlvE+vBfTioOwWRuq1b uvg75RD7CjQ9Tw840ewbZ6wVhrUCPH6UnT7/7tKG9JBywzyI1+DjZp/dwE/ubx89MXlQ2InpwB5/ Vygi065jI91udWn6B42/AAAA//8DAFBLAwQUAAYACAAAACEAfRPQWAwBAADdAgAACwC3AV9yZWxz Ly5yZWxzIKKzASigAAIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAKySTU7DMBCF90jc wfK+mbQghFCdbhBSdwiFA0ztSeIm/pHtQnp7zIKWSG1h0aX9xm++eePlajQD+6AQtbOCz4uSM7LS KW1bwd/rl9kjZzGhVTg4S4LvKfJVdXuzfKMBU34UO+0jyy42Ct6l5J8AouzIYCycJ5uVxgWDKR9D Cx5ljy3BoiwfIPz24NXEk62V4GGt7jmr9z53/tvbNY2W9OzkzpBNJ1oAjYmsIjXzIbOFpPM0rMbQ UhJcOfmaryOg90XG5nCaaH5NoinzEWYc4NOFfuNcf4ll8X+W88mDoYQKE0LqdmZjUQ9HkEMqB63Y emrPhXN3XSDpAl1e1nfFT0Iw+ZTVFwAAAP//AwBQSwMEFAAGAAgAAAAhALhIHLX0AAAAugIAABoA CAF4bC9fcmVscy93b3JrYm9vay54bWwucmVscyCiBAEooAABAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAKySz2rDMAzG74O9g9F9cdKNMUadXsag1617AGMrf2hiB0tbm7efCGxZoHSXXASfhD79 bGm7O/ed+sJEbQwGiiwHhcFF34bawMfh9e4JFLEN3nYxoIERCXbl7c32DTvL0kRNO5ASl0AGGubh WWtyDfaWsjhgkEoVU29ZZKr1YN3R1qg3ef6o018PKBeeau8NpL1/AHUYB5n8v3esqtbhS3SfPQa+ MEJTYxP6d07yPBJjm2pkA4t0JsSgL8MUa8KcYjpSg8gzyG+KBFUqxTWYzZowLBvDGWSSeopXGe7X ZCAeOzmveS2T/vkCvbi48hsAAP//AwBQSwMEFAAGAAgAAAAhAAWWz2W2AQAACgMAAA8AAAB4bC93 b3JrYm9vay54bWycUt9P2zAQfp/E/2D5nTotbQdVEsRgaJWmCQ0Gz8a5NFZtX2Q7S/jvd3HaDcQL 2tP9sr/7vrvLLwdr2G/wQaMr+HyWcQZOYaXdruC/Hm5PzzkLUbpKGnRQ8BcI/LI8+ZT36PfPiHtG AC4UvImx3QgRVANWhhm24KhSo7cyUuh3IrQeZBUagGiNWGTZWlipHZ8QNv4jGFjXWsENqs6CixOI ByMj0Q+NbgMv81obeJwUMdm2P6Ql3oPhzMgQv1Y6QlXwJYXYw5uE79ovnTZjdZWtuCj/irzzrJIR 5hfZkoZEE2mw37r9lXMYU++C0+BkF/EaLckM4U6r2JEzFghonNSjhj78wxxDNjxpV2Ff8NMFAby8 ifpUetJVbAq+OLtY04sp9w30ronEZL0ak1E+/xxZFHyVpW7iVbs0b2qbLHNpGPfjDpIMslvSS77f aHL8tpqPfMXxm5JGkfrRpIdn2TL7zJlCpzrvaQfXVDmIhCF+D7HMyR52aod3S7VaeQxYx5lCK6Z9 0h0oAYOCdBbnh7PovP7/32Vuh82VV832ht0auaNFLJIwIkfyjlTF8YzLPwAAAP//AwBQSwMEFAAG AAgAAAAhANMwgz+uDwAAFDEAABQAAAB4bC9zaGFyZWRTdHJpbmdzLnhtbNRba4/cthX9XqD/gZgv 3gX2ZTcJgmC9gbNGEAO242Z3+7EAR+LMKJZEhaRmPf71PeeS1GheTtKxgxaoEVsjkfd57rmX7PX3 H5paLY3zlW2fT55eXE2UaQtbVu38+eTh/sfzbyfKB92WurateT5ZGT/5/ubvf7v2Pih82/rnk0UI 3XeXl75YmEb7C9uZFr/MrGt0wD/d/NJ3zujSL4wJTX357Orqm8tGV+1EFbZvA/b9x7OJ6tvqt97c xifffjO5ufbVzXW4uV8Y5WwfIJLqnA22sLV683B3r3zfddYF9ezrK1WaZVUYr6pWBXzQmvBo3fuL 68twc90tIHuoindOzWwbXpXPJ9gvrDoo1Npb2yYDTC5vri+56e9tXMgnc6Meq7DAjlcXXytv8LRU 1Uy1Fv8rIctCL41q7NKUUY7R2j/9NYJ9lcSCXSjX7wi119L4ppq3poTpnFrYxijdBwvXImKymX30 B7yzrEq8gF2DsjM1Mzr0TrxS1D2DSn00zp7DUrNq3ru4CF6ky3Z8zA01tngUyVWwaoq1yxKy4O8j L4stR8alHj/dnr9+/TbKxc+mteFXkH1hWsSCDpRzWLxzFXbjC3VtHyloFfjPTju8XHV8PYVWlrM0 RcW0YVAi8vyOjylGfhnv7AncBp9phFHVBjN3VVjtrPHGFAvdVr5JJoYqEKOrdSHqlKZdKY0/9C1M ooPSIZimC15spN8jAHUNDWzvYbulbgM3hMm9qWdbjkCax8fIWWz6MbpH1Cvpxh3pXsR9JRk3LFsF Li/2VMH1PsBnaxEriFITESC797aoYN1Sckm8mlw3NQgAKmUYeo1xqtBIbqpEr9AOe3SAF+XpWIVD cou9FnokzSg6StgVfw7LJ1rTAWdiaojZ6A9V0zfKfAiIMdVZ7yvEHX7HjwwsRB0DBtaHNW3vCFiM OTiwb8cGLFVnjNuRe19EnfjTGOUSC9444mBedW1zqtnaoIraaFevlAGqT+sKmIxsooe27b+z+S9b GMyNERvQEkuk3EBiB2hPDaMXU9hmpB7pSEPQwkPsq8ZozzDbTud/xfIElH36ZVBTYgpywBOFVKRU TRRyz+kiGFd5oIBHwSkWCAl49hHhOO3LuQnHiHRXG9MRbHL1kpgawZUzhalQRKp2irpYqlIHvW2e NxFEIB2DDkpMCQFuFaVMibeGj2k/mxmHxzS+M8FV+Pt0JTFaa8TBwnYCW9AwInAH/W1JnwJeED54 59kVdmO98+oReCofo1CgRqe6QDhCmhe9c5AK8YYAASgoT41VsUIYbuvxwzGWzMG5wQuQVwWkPSO1 iH+hzk1fE/992Inwfem1yTQ0ghQWKySFkQ9G/dYDXgNBGBbqQtVUHw0RyBSS6gwoJ4UPjpHwiQvA bpE6wIg+OJAhGGeckzR9XbXvCU4WEUIIYTHZg8K3tmlEQ9kxvrQufKWGVAghCojNQHWA/8E+apcE jvLDu9yiWCCd26zlibmYX5wpEgBdZ1XPJEIkT07pVuhs/oQp58goM+trxAQqW4myTImZBKxb1mEj hFbPaqj6DgEPjExylKtWNzD+e7MC9tCg2/kDTIEWlVNP9CMLRYw0QUNPbMGviOGdz1hYWI8qCEU7 mdkMJTMGLjyIBBPjJFK5HbivjgncwzE3goHCNh2DbSBWcHdZARzocRgs+ZwhpRTynuWnQsFZqbKS bAcwFNaTFAhFgCG4pCA3HA92rBBuDctta1uygrnriSbgPYsdPD5K3y9EfHOBWafT+VSzMA3Bpd8L qxujvFTHDiXMgOQxzG7fPZwh9mEIFPXaLE3NRDctcgYPInaxXrmlrj0e6JkJq0vJqhbhgrqL10nY 5twr4fDpbnKQvQIdTVtGbpCFhCzCEoeantUC4dEADuPom4gXa93OiMFwnfmgm66GHhBCoGb4alM1 5PNHkJJcJkTPM2VCcXEaW5apAQTMARrA7Ijt6N+WQiG5JDK4W1yoVyAySDan0GiVsAbhY1uRNQxl /l0CgELlGWgoEYXu9LQCgNL8EpuPVV2T55sP6Bg8ZEAQ93RkKlE7OyiYEeYWkjjsn7l5NP1n7/+y W6hylB/10wJCcqJK3sDCFByYpHKjdF7rFSymp/ShZK94i+ugvBsQMwYOcZ883lVTAv5lLhlioEav YogZlfCQib4bY3/EG5viImxaG85bcA60JQ5geG5Y3gQ6csnQKTDG1d6DOAmRNa30WbXVJdKv1m1B dXThwIQBXkssioRhfO4FlocvDqQsx01jWVXAejVhHjTOERkRX2psUUHIWJhYElJJhzrCH5BnUYdk l1ggPJIUXG7gQdte4cTkO9+hAD6fIKVI1s3k5kEdo/cvW7QchkZgLaWlQvb2borihprugfCpgG2R 8sSO1Em2CKApc0lUHLgQys4qU4N/ypTlFCCZSdShr+IAIPPaoez4fuoLxDXyAgnDuBebrZebI8E7 bECbJ/6mTiK+DYYfywJ1AX0o9GmkEBdm0e5AhpOLRRv2G1mbV++GxTFQgCfIJ5xufVOhZ8ObMsza bUXuD2bVAUg4ceZ0M8sGUEjOOAAJGG0B7SNcDJjPAm7RZqIG4Y+Yb6hSrGKRfCdm6ZC84AhoJXPx 2G3gD+sDCM4zk035/3KU2E6iTwwER0KjlMosivUCtUWo0YgMbTZ2CLcaIOYMOiNaDEYGoE3+ae8m uaRIim7NmHZqkXQfu93kNs/IbeST1/bxXHpJ7MmXnqCSV2gxIXzZg00MPFRhKKVq5HRbrESiXC6b qo0thwN7teqJbZ8IIZfWDemFQpty8JNm1PXcgnEvms12hzLtYxyZkENVAvxG68ycNh/YMOOXSJ04 QSZ7ZQ2IZT+TmHB6od4KERiecITLYSHwVbpsAkGmZFjh0YAf4L/jnJBxmBRabh71zXwB3MGBqaXG feA81Wy3Z/ns5WcLZ9FaIYGpjwSlS4wHU7lEiQaAe/Vu+Q0nnQSmPQ3fz64C4zmmaBzVax8GDTgl 9pd6Bq4q+AQtwO6AqMCNOG9N/kko5cGy2fMhkJmoZ9t59gKzsZxn6ygVRogsLcmJ8alBT/rItBXL AvGK9wa2ThiZkPZsYKNCO1HUIFNeO3/C1IeHZs42UV62hDJz/qTcXIrzjaxuLGB3P/388PqljK0T /wVIc5gJ06DIzvpWOGCeBSC9I3mPo5VPZmy3MVAukW+RLSLUc/MK9blXLAp6CiCMzHKmq5pzNtor MbZcKPEEGCpGBOVh0sTKjZzLk8VUVhq0h2zMfYcxuLSaCZ5OmZpI/l6GkFgN7HWfU9fOlC1SkfFx c9gGdCX7ZNONgxdzfco2jb6PC4nSEgAy9I6dWWtMHsUggCQ85ZsdQ98VIK/Sl6yOybLDiTIqVJk4 DNxMStVo0nZ1JaApkzZn1NOr9QPbg5OB7hEQRRNgCqOXMBh7s523sbPg0I7O+4Qd+lB8NcqZJDIB XnYanxZImteaQ6a2b6ZAATwh/eTbBH86hYlq5kAFwXFyGf4KkIjLoRHiV0+v/v2MMYr/frW1hNHF 4k9r4MWrSPuhXxm3A2hPODSNotOIKEOYCUW5B02iBnQR00ngBwdHiDbIH1sEEq6Y5Gh/5Kgidu7o MAyrOLIjnn0JIiyQhwtbl7vU7CiIfrE+yCD2dhZHQHG0lUdqedLMsJFEwjGlO4f9z3W19+ABCbOR +pjW019y4pSmwpwj8dCNa9IgXcYob2s8Ia0mWqDpipgkMuRqn/OAib95TLDt6P1d1A9HdVH7oj8C Dc9tHgeVdAIlAGfhVt1wbgVbKKW7DnaOumFGCevAEvMFsYzjVpokkTFBfEZQNCl/YUhHdpTgThKa 8S/HyMyMrfW37SLEOMk18vrGSHwKWMiy8x2kGVfu9IpNO1IQ5Q4OSI85RgTkRBze2e5lhHh+X4OE 0haI5nSshRVgE0RDHAwNI90UiqWZoWrHQ7+k777j2sjYYzWWWEuCYZ+QhUQvl7BzqKOQaKYLzpVW aoVONBeSaIqQRky5fgyGhuLZZVSKApEHXMIH+DcSIGP0jinu8XqO+pxZOdGhJeGk0S1OXksMsyJW YMTN2igHwBG1c7okXthh5sYZLMLE41QdWRECeE18VwwOiNr8RVjLZneMVwJCGBvDzPgHR+vwVzqK HCgSKHS7/0DkYX2OLieMPKwUEi/+yMeKMjIcpS32i1ZT8XtagD+jy/gYf0NXOpysp1ezBfP07uDJ +gu08mIMWGXNsZLBsLzYAQavuh6shPaGa8GR4HH+g87Ne2UOdiaMI41QMRzFkA0TcngfZ/z4JL9O buNw/yQ77kKp+z89zf1/O/ZX6k76pxR/nEDyiBG3DLasBj8WmtTqpb07UyWPtcTYqQ1E8kpPt9FS JkQ8o4vwvVKL6leE+YaTGpNuQewk3pe5gRBj9n/2AsJWSgJh4yjts98/QHCPUiXj08AKBQ9yXwAZ 9kMDjnp/78aBKLTj21tbIyZuwRmPIeF3AAAPTCyPWeQdwUq6HP85lnuLyvtZ5DoZBDsFKINfZekw 1eaRH/C+9X08wfsvT0FexhNEcAOn3l6+OMaK+4IpkiyE1nhaN8XtPZ5BaTet0JqClsfZSZoZEL/B hXBw53h1CE03x2A8UpGT7hK3044bj2S0H0c8tztw1UXCd2vYM6qF5FmxoUi3vFA94k0XeZwKWOa/ QhuQWYw38peTLEymUKfD53syJs2vUbKOcdSrMDTZ+RITMSae2qMu5il55l2HWS0hIc9E5CQpf8ui miYq6XS/xkUF252K3H9o0JpnF4gGSsYCX7CLiY0OriD2XeaIpl1WzrYcWqgTvcQARMifXLDAdFCu a4A38NKVPwOLBReXF5KCmFIKEuZ4iNYZ7T/MXxKn5ijIPrbrZk+6H5gQjXTqDrEdSIbnhUreF3M8 xx/qXJ4/FRAY0zHhTJFAigqJhdT7roj9YTYCZQ7c1lTsfQ/f10TLlx2PU+nuvO/O1El6ci7H49Dl lFadnY+v4Um0S3gPVz/L1EIgtWo7R++Ew0Yen2MQKG9LpsdBDAMw58iwW7YcbqLpgPvHkRxv7pE6 3p1kOYxGchiQ91ofGsRjWLk3HOdT0rLJYW2eR8bhUxwtQSJcFtu4/0Nn2+mvvLeBGzmZeuZpOkFM rg8Nk7TSdLgjwFQBhNAWuF5F+p66IIQGZ32f1Gw9Zst9SW575mRlhM+1hoQa2FAmUOun8MjGLbiU r/m2EydQo0tOo+84704XC3ZkfGl4DoirSbY9BqnucLJwXH27rzgrPkaGd+txz1GV9jafgQAafpCr A7/EQcoxwt2lu1THrPFjusZ9zBovbdETu45aA7cft4YXG509wDVlbQRXELY9Myi1OYUaT94u8f9q uPkPAAAA//8DAFBLAwQUAAYACAAAACEAkKTVGrMCAACODgAADQAAAHhsL3N0eWxlcy54bWy8V1tv 2jAUfp+0/2D5fQ3QQtmUpJomIe1hfVjptFeTOMGSL5Ft2tBfv2OHhMAGTbqUJ+yD/Z3bd45PwrtS cPREtWFKRnh8NcKIykSlTOYRflwuPs0xMpbIlHAlaYS31OC7+OOH0Ngtpw9rSi0CCGkivLa2+BIE JllTQcyVKqiEfzKlBbGw1XlgCk1JatwlwYPJaDQLBGESx2GmpDUoURtpIzzfCeLQvKAnwsGuEQ7i UBJBq/0vqlMiiRMG7moFEIcrEPS9U5+fd1NRHx9PDs8vmaAG3dNn9FMJIv8yrbnnXUkUVxoxmdKS pm/0zxswGNBbgttbuU+WgWwxzpt037p0gyAOC2It1XIBG7RbL7cFsE4C96qI+nOvnM412Y4n0+4X jOIsdVbk347ycuNAVsfimRcHLXMdD7uYdlqTp8VFNF1fzKfxpTRNfbL7RM+nC5i4UjqF7le3njGw oBLFIaeZhexrlq/dr1WF44KyVglYpIzkShIOy6C+sVsAbEI5f3Ad8nd2gF1mSG7EQtjvUPXQa13z qpfAn92ywqs2Dr+NVmG3YCcjsLk/LiqzRsF/3EakKPj2K2e5FNQ1bxdBUm/RsybFkpZe7jwps9O2 XkM4/h2DxtZK2wKC5hQNqBvABtW9Vpq9gJnu8UogLlT7bnTO/QuY0CsdQ9vThwrTvukAbp0i8WxA LFexO4qCie0yPaYonHIUPWNXC+tmQCyoosHsmgyI1S1eA5Z0K75AgcFi0g3rffzoxpP30d2NVwPq BmfrWntF98FzsNhV3oCW9H6YzlT97d4rIOg5Vh541euB9fMCTAitMeRgCGnGCeSG/gjfu080jvct bLVh3DLZzAf7AQQw03I/0vih1ZIVfAm6YafRAq6lNCMbbpfNnxHer3/QlG3EZ/8m7j8k4z8AAAD/ /wMAUEsDBBQABgAIAAAAIQDIe9ap/AYAAIodAAATAAAAeGwvdGhlbWUvdGhlbWUxLnhtbOxZTW8b RRi+I/EfRntvYydOGkd1qtixG2jTRrFb1ON4PfZOM7uzmhkn8Q21RyQkREFckLhxQEClVuJSfk2g CIrUv8A7M7vrnXjcOCGAgObQemef9/trZvb6jeOYoUMiJOVJI6herQSIJCEf0GTUCO71OlfWAyQV TgaY8YQ0ggmRwY3Nd9+5jjdURGKCgD6RG7gRREqlG0tLMoRlLK/ylCTwbshFjBU8itHSQOAj4Buz peVKZW0pxjQJUIJjYHt3OKQhQT3NMtjMmbcZPCZK6oWQia5mTRwKgx0cVDVCTmSLCXSIWSMAOQN+ 1CPHKkAMSwUvGkHF/AVLm9eX8EZGxNQc2hJdx/xldBnB4GDZyBSjfiG02qnVr20X/A2AqVlcu91u tasFPwPAYQiWWl3KPGud9Woz51kC2Z+zvFuV1UrNxZf4r8zoXG82m6v1TBfL1IDsz9oMfr2yVtta dvAGZPGrM/hac6vVWnPwBmTxazP4zrX6Ws3FG1DEaHIwg9YB7XQy7gVkyNmOF74O8PVKBp+iIBuK 7NIihjxR83Itxg+56ABAAxlWNEFqkpIhDiGLWzjuC4q1ALxBcOmNXQrlzJKWhWQoaKoawfsphoqY 8nv94tvXL56h1y+enjx6fvLoh5PHj08efW95OYQ7OBmVCV99/cnvX36Ifnv21asnn/nxsoz/+buP fvrxUz8QKmiq0cvPn/7y/OnLLz7+9ZsnHviWwP0yvEdjItEdcoT2eQy2Gce4mpO+OB9FL8LUocAR 8PawbqvIAd6ZYObDNYnrvPsCmocPeHP80NG1G4mxoh7Jt6LYAe5yzppceB1wS8sqebg3TkZ+4WJc xu1jfOiT3cKJE9r2OIWumSel4/tWRBw19xhOFB6RhCik3/EDQjzWPaDU8esuDQWXfKjQA4qamHpd 0qN9J5GmRDs0hrhMfDZDqB3f7N5HTc58Vm+TQxcJBYGZR/keYY4bb+KxwrGPZQ/HrOzw21hFPiW7 ExGWcW2pINIjwjhqD4iUPpq7AuwtBf0Whn7lDfsum8QuUih64ON5G3NeRm7zg1aE49SH7dIkKmPf kweQohjtceWD73K3QvQzxAEnc8N9nxIn3Gc3gnt05Kg0TRD9Zix0LKFRO/03psmbmjGj0I1tDrxt xo1gC0aTryR2TrXgebh/YePdxuNkj0Cuzw6et333bd8N/vN9d14tL9ptpw0Weq/ePNh9sdklx3M3 yUPKWFdNGLktzT5ZwrAYdGBR05kDIikOTWkEP7Pm7uBGAhsaJLj6gKqoG+EU9tjVQDMZyYz1SKKU SzjbmWUvb42HfbqyJ8NVfWaw/UBitcsHdnlFL+dHg4KNGTkjc/7MBa1oBosKW7mWMQWzLyKsqpVa WFrVqGZanSOtMBliOGsaLBbehF0Igr0LeHkNjuhaNJxNMCMD7Xc7gPOwmCj8NSHKrLaGRHhAbIic 5ZI3qyZ2eQqZOwJIKU/ozufNwmvgtLOVMGkxP38WdHLOYOpkXXanqokl5dpiCTpqBPXV5dUAhTht BEM4lcLPOIWgSb1vw2wEVzuhEjZrz6xFU6RTi+v+rKrCRcOcgnHKOBVSbWMZ2RiaV1moWKIlWf2X V2s62S7HAJuoF9BiZR1S5B/TAkLthpYMhyRU5WCXVrTv7GPWCflYEdGNBkeoz8ZiH0P4wafangGV cLlgClo/wE2Y9rZ55fbWrNOU758Mzq5jlkY465b6JiWvOAs39VboYJ5K6oFtXt2Ncec3RVf8ZZlS TuP/mSl6HMBpf2WgIxDCRazASNdrI+BCRRy6UBrRsCNg7pveAdkCt6nwGpwP18Hmf0EO9f+25iwP U9ZwaFP7dIQEhXGiIkHIHrQlk31nMKtmo8eyZBkjk1EldWVq1e6TQ8J6ugeu6R4coAhS3XSTrA0Y 3On8c5+zCuqP9B6lXG9ODylGp62Bv3vjYosZjDq1l9D5m/u/UNEz/Sy9Ic9nZNkQ/WK6S6rlVeEM v3o9E3VBFRYZwKVZazvWjMXLq7lyEMVZi2Gx2M+kcGeD9D8w/6gImf22oAdqj+9Db0XwqcD6D0FW X9FdDTJIN0j7qw/7Hrtok0mzsq7Ndj7aa/mwvuSNaiH3lLO1ZovE+5zOLjZRrjinFi/T2ZmHHV/b tbmuhsieLlFYGubnEBMY81Gq/N2I9x9CoLfhhn7M7JckmcKTqYN0T5js6vPBJPvJpB24Nuv0GUYj WbJPhogOjvPzR+EJW0L2a0a+RTZoTaYTrSBc8R0aXMIMr0nttCyIl88mLiiMZGjZBbG5JvMxgG9Z WePWRzvA2yZrrdbFlXuKJX/GZQso73eZ9+SzqMvsQfGNgbqAy9Txm12WeQqcN5t48DVSYDiadE3/ haFjM92k7OYfAAAA//8DAFBLAwQUAAYACAAAACEAt/UTRF4JAABeJgAAGAAAAHhsL3dvcmtzaGVl dHMvc2hlZXQxLnhtbJxaW2/jNhZ+X2D/g6CHPix2Yutiy3FtF5GmgxbIYINJO30sFJlJhLEsV5Kd ZH59zyFpkTw8MYp9iROdy8dz+0g5XP302uyCk+j6ut2vw+hqGgZiX7Xbev+0Dn//7dOHRRj0Q7nf lrt2L9bhm+jDnzb//tfqpe2+9c9CDAF42Pfr8HkYDsvJpK+eRVP2V+1B7EHy2HZNOcCf3dOkP3Si 3EqjZjeJp9P5pCnrfag8LLt/4qN9fKwr8bGtjo3YD8pJJ3blAOvvn+tDf/bWVP/EXVN2346HD1Xb HMDFQ72rhzfpdHRzWofHbr/UYX1o6qpr+/ZxQJtlU1bLU7MLg6Za/vq0b7vyYQdJak7yyV0netGd xM0wdPXDcRCQpea0/E+4WW1rWD7mPOjE4zq8iZY/L5JwslnJ7HytxUtv/R4M5cO92IlqEFsoUhic QGEdHsoncVu+tcchDIb2cCseh0LsduAuS8Lge9s291WJ64niWRhgwR7a9hs6/xXcTGEZvXSKyyir oT4JZZ4vUij6X3Jl+DssazKuy/79vMZPssh3XfBQ9qJod3/U2+EZYKGZtuKxPO6GL+3LL6J+eh7g qYyzandgDT+DpsbGg4SVr/LzRRsnV1E6nePKq2M/tM3ZKS5ntIu1HXxquyy6SuNZtpAx98ObjP+i D8iVxIbPM3Z6lUXT6yQD8EsuJioKmZuP5VBuVl37EkAfQzj9ocSpiJbgQ4Y9h3xXKLxB6TrMoGjr sIenp808WU1OkNlKqxRKJbq2dKJ41JkAzIgFoVtYZwx8ug4XMlkImqsHsBgDmvIOIQ+MQ3y6Dq+N Q/XAcTjjHWI3mWycV4hPIT9T41E9cTzOeY+gw3jEp+AxMh7VE8djxnucsx7xKXhUHSvTqJ44Hhe8 RyROEzX6gYypVlbzAo7HlkBlqTBWJ52ObmXX5EoFcjSqZCYWqVIwKmZxUuWjD5Rdu0A/+yqLdzoF Uu3ESPtcdTGkbFzywjS608SQYt/TbEwPikcfaeQuOJfG6xA6fNSJDI5KjdaJYmwOF9ptTzWsFrSd cR9a9awDbZKloZVOpIjUHt0I+9PqEcxfgrwsDW9QPEbkQ6MxidoMoIZWOhy02/AyahvaLlpkplC6 zSM1BXbUc9JFhdaBGLyEA/ONUUNhZddYCbeJ0Y8ajUnUdAwipcNBY2+fE66h7ahBPCbcj1oNhh11 RMariJQO12bA5ZegHar3Eo7GJGov4UqHgY5hH6bQqUk4it+PWhq70DGhpkLrQMlprWObIfyEo3iE julcS2MCbTZB1eFah4saCkWjtmod23WMCV3kKCUJj2mbaR0OGiK9BA3iC1GjMYmatlmsdDhom81A i1BKbLNZTFooRymBTrxaazbziRSPajTquWEzFI9RJ16tfTZLvFprNmOgbTZjorbZzG8zn80S0g9F rHS4hDNsZreZzWZ+m/lsltDtI9ZsxkTNsBmQnt4+8vjMV3QoYXleoWB2z9uOFK9DO2cLUy5n70wu jzeKx5J7VC6N3UZP6AamdZi8J5fHG8UXoP3xTgjnFhIAzmh+3hOcPrKLWHyK4hHaK7k0JlFTZtE6 HDQz3taMJfZ4J4Q1cpSS8Y69qN8d74QZb6vRUWyiJk2cS2M36tir9bvjneD0kYRbjS7F6NxrdGY2 bbvz9Hl23GBZA6IGyxkQQ5PugDC7vlnBTWLv+h4xoZTUK6WcqHWYVkmZKbe6FMWmXma+1QlPGrv1 Siknah0O+jItpDYteFGjlEZN2qnQOhz0ZVpIbVrwoX1aSGmXogdYHgft0sKZTlOHDkgkOUrRHbTU WA1SjOKs479ApC4djJA2DZCOyaUNQfRKq1mAQWRYwDR0Dg2mw6EzlXKzaGZKit1NJzXc5MxUykyn RUQoHlPpbTrSmDQ2pV+tw7w1pcw429DOONPTlTQm0ISiC63DQM+YcbagUTxG7R3spDGBJssrtA4H zYyzqfnNzBln2uAoJeNsuFKd4bUKh+z2t3pVNE0zU23qELFpd6dpZhf79gbFY/pmZIG5NHbTN6ND qnXg3ZN2/ozZvezK2cv3+lUaE2gTos4fAsBEM9Dc0I0nxJsZiE3UhARylJLKLSgbah0O+vKUzi5O KUoJ9Iw0VqF1OGhmSu1+tafUTzgak4R7USsdBhrOYt5Jxdp0UTwm3IOWxgTacKCqtdZhXrXnzJRa bYbiEdrb+aQxgaa0qHU46Mub7tzZdAnv5CilCae0qHU4aHfTlQxhJ9zZfD1otfnay5sRnWKuN2j/ u405Q042NIhNwonbXBq7CZ8T2im0Dhc1w2Z2rW028zaDORoTaMpmWoeDZtjMjtpmMx9aMZWd8Dll s7lmMybhDJvZUdts5kP7bJZ5CVc6XNSX2Wxus5k/XD6bZZRS0AMUhYNm2MyO2mYzH9pns8yjFM1m fsIzhs0saBSbDidfyktbt8tozFqFiTlzuex8rsXH7wOiDTnX0lClXzbLGbIQecW0Q7VblnRsLm3d UCl3ahUuVIbAbGCHwGiOff6izIn/Ceb7KmPoywZ26IsCo60bMSG4QrrnU32ZvPCfru8X2eeuiE6x /K8tj8xwlx2yw100ZJ+6Isqa2bvUlTH8Ac0wNraafhs/M86dg2x2mQ5QPGbPO2FIY7duGenmQusw L7gLhg6scxWK34eWxi50QntG63DQLiHIbR6OQuf8LRxiMJlTX2aglHRrRg67hdZh3kEWDDNYGx6K x6i9b/uksRt1Rg+yWoeL+jI3wI0RC5r0KwpJ0B6w5gbrizN1z0PdZTg8w42foa7gXsdjux/wzgjG +naAGyX7tmj3+toQvvDgVZTPZfdU7/tgB/dQ4HrJFc5hp+58qD/gjgqMZRg8tAPc55C/PsOFIAHX E6ZXoPzYtsP5D+3zXgzHQ3AoD6K7r78DMPRY29Vw9Ufe+FmHO7ia1Fcgh391gOA7LLTcfTzU6zCN r9PreRZfw6JhpRCILwAUtYJPEnqzarfbX+SSNj+UzeHHQv4Mv4puW+7L/+btbhvKR1H65e42+Pz7 /W/BF/HXse7wNpKr/EU8HXdlp/Wnf75Op9OPf64mBmI1ccHF63DbD5sVfOorUQ1ciSH3qsYLSFdw AWmirkPBNapqIl4rIW9VLfStqmMHWfh/rTer5nV5d/s1+Nxu8QZRGPxvL+6gyrIEf+iLRfLyBiDD ovGnXP1kvBm2+RsAAP//AwBQSwMECgAAAAAAAAAhACAm9mdgNAAAYDQAABcAAABkb2NQcm9wcy90 aHVtYm5haWwuanBlZ//Y/+AAEEpGSUYAAQEBAEgASAAA/+IFwElDQ19QUk9GSUxFAAEBAAAFsGFw cGwCIAAAbW50clJHQiBYWVogB9IABQANAAwAAAAAYWNzcEFQUEwAAAAAYXBwbAAAAAAAAAAAAAAA AAAAAAAAAPbWAAEAAAAA0y1hcHBsAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAANclhZWgAAASAAAAAUZ1hZWgAAATQAAAAUYlhZWgAAAUgAAAAUd3RwdAAAAVwA AAAUY2hhZAAAAXAAAAAsclRSQwAAAZwAAAAOZ1RSQwAAAZwAAAAOYlRSQwAAAZwAAAAOZGVzYwAA BUAAAABvY3BydAAAAhQAAAA4dmNndAAAAawAAAAwbmRpbgAAAdwAAAA4ZHNjbQAAAkwAAALyWFla IAAAAAAAAHRLAAA+HQAAA8tYWVogAAAAAAAAWnMAAKymAAAXJlhZWiAAAAAAAAAoGAAAFVcAALgz WFlaIAAAAAAAAPNSAAEAAAABFs9zZjMyAAAAAAABDEIAAAXe///zJgAAB5IAAP2R///7ov///aMA AAPcAADAbGN1cnYAAAAAAAAAAQHNAAB2Y2d0AAAAAAAAAAEAALhSAAAAAAABAAAAALhSAAAAAAAB AAAAALhSAAAAAAABAABuZGluAAAAAAAAADgAAKFIAABXCgAAS4UAAJrhAAAnrgAAE7YAAFANAABU OQACgAAAAoAAAAKAAHRleHQAAAAAQ29weXJpZ2h0IDIwMDcgQXBwbGUgSW5jLiwgYWxsIHJpZ2h0 cyByZXNlcnZlZC4AbWx1YwAAAAAAAAARAAAADGVuVVMAAAAmAAACfmVzRVMAAAAmAAABgmRhREsA AAAuAAAB6mRlREUAAAAsAAABqGZpRkkAAAAoAAAA3GZyRlUAAAAoAAABKml0SVQAAAAoAAACVm5s TkwAAAAoAAACGG5iTk8AAAAmAAABBHB0QlIAAAAmAAABgnN2U0UAAAAmAAABBGphSlAAAAAaAAAB UmtvS1IAAAAWAAACQHpoVFcAAAAWAAABbHpoQ04AAAAWAAAB1HJ1UlUAAAAiAAACpHBsUEwAAAAs AAACxgBZAGwAZQBpAG4AZQBuACAAUgBHAEIALQBwAHIAbwBmAGkAaQBsAGkARwBlAG4AZQByAGkA cwBrACAAUgBHAEIALQBwAHIAbwBmAGkAbABQAHIAbwBmAGkAbAAgAEcA6QBuAOkAcgBpAHEAdQBl ACAAUgBWAEJOAIIsACAAUgBHAEIAIDDXMO0w1TChMKQw65AadSgAIABSAEcAQgAggnJfaWPPj/AA UABlAHIAZgBpAGwAIABSAEcAQgAgAEcAZQBuAOkAcgBpAGMAbwBBAGwAbABnAGUAbQBlAGkAbgBl AHMAIABSAEcAQgAtAFAAcgBvAGYAaQBsZm6QGgAgAFIARwBCACBjz4/wZYdO9gBHAGUAbgBlAHIA ZQBsACAAUgBHAEIALQBiAGUAcwBrAHIAaQB2AGUAbABzAGUAQQBsAGcAZQBtAGUAZQBuACAAUgBH AEIALQBwAHIAbwBmAGkAZQBsx3y8GAAgAFIARwBCACDVBLhc0wzHfABQAHIAbwBmAGkAbABvACAA UgBHAEIAIABHAGUAbgBlAHIAaQBjAG8ARwBlAG4AZQByAGkAYwAgAFIARwBCACAAUAByAG8AZgBp AGwAZQQeBDEESQQ4BDkAIAQ/BEAEPgREBDgEOwRMACAAUgBHAEIAVQBuAGkAdwBlAHIAcwBhAGwA bgB5ACAAcAByAG8AZgBpAGwAIABSAEcAQgAAZGVzYwAAAAAAAAAUR2VuZXJpYyBSR0IgUHJvZmls ZQAAAAAAAAAAAAAAFEdlbmVyaWMgUkdCIFByb2ZpbGUAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAP/hAHRFeGlmAABNTQAqAAAACAAEARoABQAAAAEAAAA+ ARsABQAAAAEAAABGASgAAwAAAAEAAgAAh2kABAAAAAEAAABOAAAAAAAAAEgAAAABAAAASAAAAAEA AqACAAQAAAABAAABAKADAAQAAAABAAAARAAAAAD/2wBDAAEBAQEBAQEBAQEBAQEBAQEBAQEBAQEB AQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQH/2wBDAQEBAQEBAQEBAQEB AQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQH/wAAR CABEAQADAREAAhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgED AwIEAwUFBAQAAAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRol JicoKSo0NTY3ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWW l5iZmqKjpKWmp6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3 +Pn6/8QAHwEAAwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3 AAECAxEEBSExBhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5 OkNERUZHSElKU1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaan qKmqsrO0tba3uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIR AxEAPwD+sH4o+HfjDc+FfANx8JtP8KeGortNKsdTuvE2i+ELK+8Q6lqljZWvhqLw/wCI9esfF+lC OXWGaXV9BuPBl34g8WWcn9naDr3hvU/31x1UIUW5e1al7t1yubslrLmjFQle20lUtF6yjJHLWnW9 32acdWndQTk38PLKTkt94uDlJbOL39T0288P/DDRx4y/aIsvBHhjSPDngexTxr4v1jT/AAx4C8Bp 4hvdZ0rTxqNnF4k8UXqaTZajqcw07SLPUNcvtQkub+z0yGa6urqONspqCUlBp3qKUVfmlGFpK0pO MddVqkk2noawc3KLkmrQak2lFOTcdVFSlbZ7t22uepp4w/Z4kbw4sdv8PHPjCxutT8LFNT+HzLr+ nWOgW/iu8v8AS3GvFLqztfC95aeI57mNjFHod1b6q7ixmjnbI1PL/wBpAeAdE8B2niSLxt8OvgBp PhTxl4V1XxD438Xw+BItCvfKvo30XwFrFzeeLNIt7Sw8cavJp2l6jb/aJNS1TSpbjT9Lsrie+Vk1 pThCTdSn7ROMopXtyuStzq6fvRWsdPis+hnUjOSShPkakpN2vdLXl3WknpLurrqet6l4i+Auj6dp mr6rpngXT9L1vxD4c8I6PqN3e+AYrPVfFfjC903TvCvhnT7htc8u81/xHfazpFtoukQNJf6jLqdj 9mgkW6iZ8jQ6200L4f6hbxXun/DnTdQs5wWgvLDTfCt7aTqGKFobq21OWCZVdWRjHIwDqyn5lIAB ieD/AAh4bg8L6DFqvw1iu9RTTLVby5Ok+H5zPN5Y3SGZ74PKW4y7Dc3U1c2nOTjs22un4EwTUIqW 6SvrfX1Ok/4RXwZ/0S2H/wAEnhz/AOT6goP+EV8Gf9Eth/8ABJ4c/wDk+gA/4RXwZ/0S2H/wSeHP /k+gA/4RXwZ/0S2H/wAEnhz/AOT6AD/hFfBn/RLYf/BJ4c/+T6AD/hFfBn/RLYf/AASeHP8A5PoA P+EV8Gf9Eth/8Enhz/5PoAP+EV8Gf9Eth/8ABJ4c/wDk+gA/4RXwZ/0S2H/wSeHP/k+gA/4RXwZ/ 0S2H/wAEnhz/AOT6AD/hFfBn/RLYf/BJ4c/+T6APHH+D2pn48R/ENLML8Kx8NV8Ky/CttA0prdvG S69c6kfGcZXVV09bhtMkg0tpXjluvKgMKoscnmrrzw9i4cn7z2nN7T+5y25e++vRfrlyT9tz879n ycvs/wC/dvm+6y/E9j/4RXwZ/wBEth/8Enhz/wCT6yNQ/wCEV8Gf9Eth/wDBJ4c/+T6AD/hFfBn/ AES2H/wSeHP/AJPoAP8AhFfBn/RLYf8AwSeHP/k+gA/4RXwZ/wBEth/8Enhz/wCT6AD/AIRXwZ/0 S2H/AMEnhz/5PoAP+EV8Gf8ARLYf/BJ4c/8Ak+gA/wCEV8Gf9Eth/wDBJ4c/+T6AD/hFfBn/AES2 H/wSeHP/AJPoAP8AhFfBn/RLYf8AwSeHP/k+gA/4RXwZ/wBEth/8Enhz/wCT6AOe8W+D/Ddx4X8Q QaV8M47bUpdIv0sbhdI8PwtDdNbSCGUSpfF4yj4YOgLLjIBNVBpTi3qlKLel9Lq+nX06kVL8k7Oz 5JWbdrOzs2+mvUi0u5+DmsRytpXhzwhqotVQ3T6dL4FvVg3RrJumNtrcgiBR1kzJtwjoxwrqTy08 XhavN7PFYepy/FyV6UuXS/vcsnbRp3fRp9T18VkmdYJwWMyfNsI6rapLE5djKDqNScGqaq0YubU1 KPu395SW6Z5B8Q7zW7D4TfCJNWj0PVLC/wDHnwYi8OaXZSavousP4gsfEOla94eupNQa7n025j0a 90iPXNTsbyTRbHU9P0y7tBqEUs0Fld+lQUG52501SqOTbjJWcXGWnLfXmsn7zTadnqeFW9paOsGn UhZJSTupXTvzdLXe10n6P5K/4Kd/F65+Hfh34deD/iD4M0bxzp/jLWtP8Y6NqHhrxP4r+HfiHwT4 y+C3jXwZ4/8AAni3w9rmn3Gp3EWt6H4ui0rV7NpEksHOnfY9TsdS0++urST8A8d/GDGeEOW8OY/L 8jw2dSzvHZhhKtPG4utho4eOCw+GrRnTeHpSlN1HiJKXNZR5I8t+aVvzPxM8QcfwFSyaeGy7B5jL NKmPjNV516apRwccI1yqlK8ud4rVtrl5Fa/Mz8S9U8b/ALNmuax4p8Saz+zDdar4l8Y60/iTWvEO o/tA/Eu91SbxDL4g1bxhPrMhuoJbLU7258Za9rXii7HiGy1u2u7zUpNFurabwbZ6X4Y0/wDmz/id fP8A/ogMl/8ADtmX/wAqPyf/AImIzr/omsq/8KMd/wDLD0bw/wDtE/Bbwf8ADCy+E/gj9l7TPBGi aV8TPCfxj0PxL4Y+Mnj+z+I2h/ErwNodn4Y8K+KLHx7dwX2uXVzpHhqzPh6Cz1uTV9MfRr7U7GWy eG9kAX/E63EF0/8AULJvNf2tmFnvr/A5vul09Rf8TD53e/8Aq5lfp9Yxtnvr8d/xPJtX139lbX9f vPEus/spS6jq2o+M9T8dajcT/tDfFfN/rGseLrbx7qMV1JG6XTQ3HjO2/wCEgbVIrmLxaJLi40Ye Jh4YaHQoH/xOvn//AEQGS/8Ah2zH/wCVeo/+JiM6/wCiayr/AMKMd/8ALD7P/Z2/4KOWX7K3wj8N /BH4M/s8+FtD+HvhOXWZ9IsNT8e+INXv1n17Wb7XtUnu9Rk0qB7ue61PUbqeSd4hNM8hmuXnupJ7 iaX9NbiBvTgPJ4+SzXH29few7f4if0h87f8AzTmVr0r4z79Zt/ifoTH/AMFWfBfhCaPwl4y+DPxs k8Q2vhT4NX+lv8P/AIb6l4/0XxnrXxb+HMXjux0zw1qOk6qLaystJmZ/DV9deJ7vSNXi1GN9VudB tfCxh8QXH91cJZ3U4l4W4b4irYeGEq57kWU5xVwtKcqtPDVMywFDGTw9OpNRnUhRlWdOM5xUpKKl JJs/pjIMynnOR5Nm9SlCjUzTK8BmE6NOUp06U8ZhaWIlThKXvShB1HGMpatJN6lyX/grH4NuDo1n 4f8AgD+0P4g1vUbqO41XT4Phldw6d4b8JvH8SJ28VXniGHVr+w1ry4vhreoNE8KRa9d3d14h8Nxa Zc6ha3/25PoD1j3D4C/t++BP2j/inpPwt+Hfgb4v6dc6j8O/F/xGvPEvxG+E+vfDzQ9IsfCvjDRv BsGi3MWv6mmq3Gt+IbrVLrUNPigsfs9jaaNqFlq89nr8N3o9kAfdG3XP+e+lf+At3/8AJtABt1z/ AJ76V/4C3f8A8m0AG3XP+e+lf+At3/8AJtABt1z/AJ76V/4C3f8A8m0AG3XP+e+lf+At3/8AJtAB t1z/AJ76V/4C3f8A8m0AG3XP+e+lf+At3/8AJtABt1z/AJ76V/4C3f8A8m0AG3XP+e+lf+At3/8A JtABt1z/AJ76V/4C3f8A8m0AG3XP+e+lf+At3/8AJtABt1z/AJ76V/4C3f8A8m0AG3XP+e+lf+At 3/8AJtABt1z/AJ76V/4C3f8A8m0AG3XP+e+lf+At3/8AJtABt1z/AJ76V/4C3f8A8m0AG3XP+e+l f+At3/8AJtABt1z/AJ76V/4C3f8A8m0AG3XP+e+lf+At3/8AJtABt1z/AJ76V/4C3f8A8m0AG3XP +e+lf+At3/8AJtAGbrC63/ZOpkzaYQLC7J22t2GwIHJwfthwe+ecdeaA33Pme+/Yh/Z31LxDL4ov fhZ4UudYuPE3iPxheSy3Xi2S1vdf8Waxpuva9dXenSeJH06e1vdT0mxkXSmtf7JtrZJtOtbKHTru 6tJvmp8H8OVK7xM8rpSrSxOIxcpOpXcZ18XWp168p03VdOUZ1KNN+zcfZxinTjBQlOMv1yh47+LW Gy2OU0OMsbSwVPKssyWjCGEy2NWhl2T4LF5dl1GjiY4OOIhVoYTHYmLxaq/XKtWUMVWrzxVGlWh4 t48+Gfw/i+G/hHWvDei6zo3iu/8AEnw2XXtZ1m98e6f4dvtN1jxFpFr4i00XV3NPppn8R293LpOh Q6HbzX9xrV/pkWkQOzLGft8PicRdRlUg4KnJRio4dtcsPdfw8z5bXlzvZS5nc/EK2FwzvP2U1OVR OTcq6i+afvbSt7zdo2+01ZHlH7UHj79j39mLXPBV38Rf+KF0rxho/iO30o+OPCvxG8TnU9R0a/0C W6GnQappHiKe0+yW2oRG5mhitYpPtEMckkrBFT/MD9pvwh4icb8J+EVPgnB4zMK2W8R8XVMy/s/M svyx0aWKyzI44X2s6uNwMayqToV+SMZVHHknJqN7v9+8BPBjPvFrNOJMFwtwVh+LauS5fl2LxtDG vKeXBQxmJxNGhVg8+xNCkpV5UasH9XlKo1T/AHiUVFv5g/4b2/4Jv/8ARQvAP/hpPGn/AM76v8gP +IIfSF/6EWff+JVlH/z+P6a/4ko8UP8AoyWTf+BcB/8AzyD/AIb2/wCCb/8A0ULwD/4aTxp/876j /iCH0hf+hFn3/iVZR/8AP4P+JKPFD/oyWTf+BcB//PIP+G9v+Cb/AP0ULwD/AOGk8af/ADvqP+II fSF/6EWff+JVlH/z+D/iSjxQ/wCjJZN/4FwH/wDPIP8Ahvb/AIJwf9FC8A/+Gk8af/O+o/4gf9IV /wDMhz7/AMSrKP8A5/B/xJR4of8ARksm/wDAuA//AJ5HuVl4k/ax8S+J9T8Qfs1eKP2Svih8I/EF 18Hbr4ZfCfxTr/j/AMKeM/CHwj1b4U/D/wAQ+L/Guv3Hhe9sNYstb1zxP4vtF8L+DdT0CeG28O+I vBmr+ZY2uq2um3n/AEr+BWBzHK/BTwiy3OKVWjm2X+GnA+CzOjWqxr1aWPwvDWW0cXTq1oTqQq1I V4TjOpGpUjOScozkmm/4a4sybFcOcUcR8PY7BRy3G5FnubZPi8uh7FRwGJy3HV8HXwcVhpTw6jhq lGVFewlKjaC9nJw5W6viy5/4KMeFLxdJubr9jGe+8b+IbXQ/BF7rvjP4i/D+H7K+kazda6/g7w1q niXxJq/i3xR4e1KfRLW2tL7VdTguk0qdr7QWtr46lX6qfPnUeG/En7Z1j4L+OmgeKtH/AGW9d+J3 w90Pwlq3w31rU/iL430nwt4ov9S8V3V78QYfiJBpPie1k8F6V8OvhxLoK2muHSbA61rPibTriWye 20e6bxIAcDL4j/4KEanourfEzQ9H/YYbwI/9oHwWlr8VPiJqHgrVopb/AMeaP4Yn8RfEiTXYvMk1 7Vr34e6UkOgrYQDUtD12ZbiC4u/+ETvwDqofBn/BU7Q21aEeD/2UPHUWqXPjfUrPUNU1b4t6Bd+F ludQkfwP4a0jS9Jl0u11TTtH0mWNLnVvEWqajqniHVLMQanc+HLO9l1e0AP0b+GvgFYfhz4Ah+Km lPefE+LwT4Vj+I934ebxjHoF148TQrBfF9xocaSQImjz+IRqMumIsEKrZNAFijA2AA7b/hBvAP8A 0Atb/wC/vjP/AOSaAD/hBvAP/QC1v/v74z/+SaAD/hBvAP8A0Atb/wC/vjP/AOSaAD/hBvAP/QC1 v/v74z/+SaAD/hBvAP8A0Atb/wC/vjP/AOSaAD/hBvAP/QC1v/v74z/+SaAD/hBvAP8A0Atb/wC/ vjP/AOSaAD/hBvAP/QC1v/v74z/+SaAD/hBvAP8A0Atb/wC/vjP/AOSaAD/hBvAP/QC1v/v74z/+ SaAD/hBvAP8A0Atb/wC/vjP/AOSaAD/hBvAP/QC1v/v74z/+SaAD/hBvAP8A0Atb/wC/vjP/AOSa AD/hBvAP/QC1v/v74z/+SaAD/hBvAP8A0Atb/wC/vjP/AOSaAD/hBvAP/QC1v/v74z/+SaAD/hBv AP8A0Atb/wC/vjP/AOSaAD/hBvAP/QC1v/v74z/+SaAKGq+CfAkemahJHoetCRLK5dC0njEqHWFy pbfc7MAjJ35X+9kZoAv/APCDeAf+gFrf/f3xn/8AJNAHy58ULH+2PhP8KLfU18N+PrGz8a/Cy8i8 PrYagmt+FJoL23+y+K7L+wNeTUNRvfDU7RS3ltcDT7JtMk1G41CZYLd7efsw7s5NRnBulJc101O6 1i+aFkpdGm3e1tWcla8lG8qc0qkXa2sbS0lpPXle+ytdvTR/jn/wX406TW4/2YBqfirT/EAt3+LX lTaLZ2titr5o+Hu6O42ahqokabyw0W5oSBFJtD/MU+e4g8Kch8U8BRweeYrOcBDJ8ZHEYd5VVwsK lWWMoV6dX231vA4qLhFYeny8kYuMpS5m1JH+mn7NTN/7K4t8WJSr4X9/w5wtH99JQ0p5pnDvG9RX 1mr77rufzj/8Idpv/P1ef9/IP/jFfH/8ShcAf9DvjX/woyb/AOch/rp/rfH/AJ/5d/4Pj/8ALg/4 Q7Tf+fq8/wC/kH/xij/iULgD/od8a/8AhRk3/wA5A/1vj/z/AMu/8Hx/+XB/wh2m/wDP1ef9/IP/ AIxR/wAShcAf9DvjX/woyb/5yB/rfH/n/l3/AIPj/wDLg/4Q7Tf+fq8/7+Qf/GKT+iFwAk3/AG3x rs3/ALxk3/zkD/W+P/P/AC7/AMHx/wDlx/RJ4Z+DPwL16H4VeIZf2CPiH8afE0HwK+Gn/C6fi78P PiL4v8M+JV8M/Dz9lv8AZb8WaJqc/g/S7yysfGM/iGz1fTvh78NvDmjXp8Va1rXw5+JDeG4bbU4r hbT9Co5PhuH6NLIcHUrVsJktOGVYariJQliKmHy+KwtGpXlThTpyqzp0oyqShCEHNtxjFWR/zZeN 9dYnxo8XMQnCXt/EvjmrzU5c0Je04lzKV4S1Ti76NNrze79J1zRPgRq/w8+EXg8f8E0P2ydE+E3g 6D4g/ELwnAr+MfDvj3wv4j8R+CvBEvjrR7bRvA/i7WvGttea1b63babjU9f0TSfEniTQPFDrY65Z /wBq3M2h+Xnl2m/Cr9kC50a18H+Lv+Ccv7RXw18J6xYR6r8N28d+L/HfhvS72+8K/A/xPrWswfF2 9k8SQ3/gyw0n4X/B6HTfFeradL8Qbe41GeDwuy3WoeKtG0nxWAe7eOvgT+x74b8eaJq7f8E+f2vv E114iPwr+JA8SeA7TxVq/hLTvE2oT23je28P3GnD4nwDS7nwdfeOZtOv9Gi0mz8Ltr1jcaTZrp82 j3OrWwB+guvft7+I/DvgHwX44vf2Sf2t7i88YXfxJtZvBOmfCO01nxb4V/4QDwza+J9NufFNhofi bVW0+z+IMV9b6R4TvEWazi16LU9L1y40y404rcAHleof8FJvjJBpl/caf+wN+1Te6ze6frkvg3Qp vBYtjd6nY6X451nQ7LxzqMa3cXgtNfsfDPh5JJdPtvFq6Ff+MbGyv5JJIYmvgDq9C/4KCfFHVfEv hPwNe/sW/tN6N4l1r4k/CzwBr3iDUfAPk/C3QbDx3rlrY+KPHMPjBLyfVb3wr4D0aS81ifUL7wvo 9lqsun3dlNfaKkT3YAKeof8ABRX4k6avijTJf2Jf2qb7xToHjfx14W06PTfhzcS+CPE2i+CNdvbW bxlp3jZ8SW2lal4bhsddsILvw6JdVv8AU4NE8Ny+IRFdalAAel/Ef9uLxF8P/GeueDbL9lr9qX4g yaR4i1/w7ba34H+Fthf6FrMmieH9F1y21ix1K98UWVinh7xDLrX2DQtWnvFinGka9dXa2c2nDT7g A4Af8FHfFMl/FpkX7Ef7bj3c32mNXk+DWg22nJeW/gjw94uWyl1e48dx6YJri/19/CcZiuZhDq+h 67c3gtrK0jaYAhf/AIKUa1FY6rczfsW/twR3mn2utz2ul/8ACiLeWfVZ9C8D6R41urK31CDxbLol vPcvq3/CL6abvVIlv/EljeafCPtcf2SgD9FfC3iG88UeGPDniVp5fD7eItB0jXW0HxForaZ4g0Q6 tp9vfnSNd02fUEn0/WNNNx9j1OxmRZbS9hngkVXjYAA3vMu/+g9pn/gGn/yyoAPMu/8AoPaZ/wCA af8AyyoAPMu/+g9pn/gGn/yyoAPMu/8AoPaZ/wCAaf8AyyoAPMu/+g9pn/gGn/yyoAPMu/8AoPaZ /wCAaf8AyyoAPMu/+g9pn/gGn/yyoAPMu/8AoPaZ/wCAaf8AyyoAPMu/+g9pn/gGn/yyoAPMu/8A oPaZ/wCAaf8AyyoAPMu/+g9pn/gGn/yyoAPMu/8AoPaZ/wCAaf8AyyoAzdZkujpOp513TWH2C7yo s4wW/cPwCdSOCemefxoA0vMu/wDoPaZ/4Bp/8sqAPhf4srInwz+C+tadosfh2Hwx418C6r4iv9d8 Hyax4f8AF9hdaJqvh+10m/XwvfNq9xHJrut6Rren/wBpJa6dcatpOnJe3dhcNbXEfbh/tpz5nKlJ K02pRd1JtcytdJNO12k3ZM46+0X7NpRqJtuEWpXuukr7tPXS61a3PE/29PgJ8S/j1f8AwztvhB8K 7pZvDVt4puNdgvZvB3hn93qcuiRWM0Zn1yKO8+e0uUbazPDwSMSZrCTahy+1Un7RSsnN2SjNX1S3 bXrr2NoXVTmjCVNcjTekb+8ml7rd7a799D8+v+Hen7XX/RKY/wDwsfAn/wA0VZcz7v73/mdHPP8A ml/4Ew/4d6ftdf8ARKY//Cx8Cf8AzRUcz7v73/mHPP8Aml/4Ew/4d6ftdf8ARKY//Cx8Cf8AzRUc z7v73/mHPP8Aml/4ExG/4J5/tdFWH/CqY+QR/wAjj4E7j/sYqOZ9397/AMw55/zS/wDAmfTN1+wp +27res+Ldf8ABv7Rl78PfCPxC+HHw48Hw+B9S8a/EjxBZ+BrXw98FPAPgu4u/AfhWwvLfwZ8MPF+ k+NNE+IN/feIvCF1rFv8Q9I+Ixu9ctNJ8QeE9K1G9RO+rPaPAfwF/wCCnHw58JXPgjRv2h/gJrmm 6L4dkXwd4h8cfDDxZ4r8Yan4ouPDPiG5vZPHetX+uebe2V58StWtNTOo2G+Wy8J6fZ6bY6NHLDdW l+AdX4U+EX/BR/RrL4peItX+MPwH1P4meNfFXwoHhsN4O8XTfDPwz4C8G2XieDxZaaf4Snk87RfE vie81bQb3VJrS51T+3k0XVYY9Z8MS6n4duvCIBlfEz9nT9u/X/H/AOzV8W/Dfx80FtX+EngvxFZ/ Gz4T2dl4g8EfC/48eKdV1mHxVpf2Ww0nULi30C30DVND0Dwtputa9b6teXfgjU/Gdpqll9v1i2ur QA9f/Zk+A/7Q/wAHPi38Xde+KPxWl+Lfwm8W+AvgV4R+G3hfUpdfvfEngjWPg/4JXwn4q8W3h1u+ n0OXVPjTq13qPjXxpJpfkT2+sWulW8s+tnz9QiAPuLzLb/oXLvnr/oenc85/5+vXn60AJ5lt0/4R y6xzx9j07v1/5eu/egBfNtv+hcu//APTu3/b1QAnmW3/AELl1/4B6b65/wCfr15+tAC+Zbf9C5d+ n/Hnp3TOcf8AH168/WgA823/AOhdu/8AwD07tz/z9evNADd1p/0LVz/4Bab/APJVAButP+hauf8A wC03/wCSqADdaf8AQtXP/gFpv/yVQAbrT/oWrn/wC03/AOSqADdaf9C1c/8AgFpv/wAlUAG60/6F q5/8AtN/+SqADdaf9C1c/wDgFpv/AMlUAG60/wChauf/AAC03/5KoAN1p/0LVz/4Bab/APJVABut P+hauf8AwC03/wCSqADdaf8AQtXP/gFpv/yVQAbrT/oWrn/wC03/AOSqADdaf9C1c/8AgFpv/wAl UAZ2sNa/2TqePDtyh+wXfzmy035f3D/Nxck8deMn0yaANHdaf9C1c/8AgFpv/wAlUAfEnxG8UeIN J+G3wjk8E6vY+O9Xg8a/Dg6l4YvbnwekfhDSIFlnv/E0ccltaTz6j4dlit/7Jj1a4ns4dUns7vUG hFt9vtezD07ufPTlBeylaSVX3m0rJ+80lJauyV1dLc5K02uXlqKb9pG8b0/dV229Vq49E/tWb2bP pzRNT0+48STPF8So9fVdECtcLJ4SH2ZjfgiHOn6ZDH+9AMn71Wf5PlIXcDzTTVr03T335/e1/vt7 eXzN4NO/7xVNv5dN/wCW2/mdVq+qvZ6Vqd3pWuLrOqWun3txpukf2l4b0/8AtW/gtpZbPTft9xYN b2X264WO2+2Tq0Nt5vnSgojCoND8sV/bh/bZ8N/DrUPHfxA/Yb8TovhuK21PX7Tw1460MarqOl3f hXxnql7b6B4Mk8Pa94oin8HeKPDum+Gde1D/AIn194mt9Z0TXPAng7WbTxVYx6OAfQ/7N37S/wAf fjB4isrP4pfs1eNPgX4O1fwbqfi3TvG/iXxh4MuHt9Q/tnTU0HwRrHhD+x49astYvfDWqHU7jVp7 i1K6jpGq2F14b0dvIFAH2v8AbbP/AKG5f+/2g/8AyFQBm6NeWg0rTg3itUIs4Mp52hDb+7Hy4ayJ 49yT680AaX22z/6G5f8Av9oP/wAhUAH22z/6G5f+/wBoP/yFQAfbbP8A6G5f+/2g/wDyFQAfbbP/ AKG5f+/2g/8AyFQAfbbP/obl/wC/2g//ACFQAfbbP/obl/7/AGg//IVAB9ts/wDobl/7/aD/APIV AB9ts/8Aobl/7/aD/wDIVAB9ts/+huX/AL/aD/8AIVAHK+O/EWr6D4I8Za54OvF8X+LtG8K+IdW8 LeE/t+gWf/CUeI9O0i8vNE8O/bDZgWv9t6nDa6b9pJAg+0+aSNuaAPzh8P8A7bH7a8drpVv4t/4J 8fFG91C5OhNc6v4S+Jfwz03Sry11nxreaBPeWmg+JbOfU/Dc+ieG4LfxVrGi+Mtd06/top/JaUWb w6k4Bf179t39rHQoPC2pv+wt8SL+18T6onhq30TTviL4bufEUHiG60PwDrkE+rtN8PbKDwx4dt5d f8beF21nW7AaNfeIPAmpX91r3hzwvLpWs6+AR6X+2Z+20thYprX7Anjm916+ttNkkj0P4ueANM8O aTfT6H4Sl1ayvdY1zw1PqFzZ6L4k1TxJp9xq6aLZS6hY6XaXXhbRPFenxa1rmngH6Q+GfEEmt+G/ D+tatqF54W1XV9D0nVNT8ManeeGLjUvDmoahYW93e6DqFxZ2slnPfaRcyy6fdzWsj20txbyPA7RM rEA3Pttn/wBDcv8A3+0H/wCQqAD7bZ/9Dcv/AH+0H/5CoAPttn/0Ny/9/tB/+QqAD7bZ/wDQ3L/3 +0H/AOQqAD7bZ/8AQ3L/AN/tB/8AkKgA+22f/Q3L/wB/tB/+QqAD7bZ/9Dcv/f7Qf/kKgA+22f8A 0Ny/9/tB/wDkKgA+22f/AENy/wDf7Qf/AJCoAzdYvLQ6TqQHitXJsboBPN0I7iYX+XC2Qbnpwc+h zQBpfbbP/obl/wC/2g//ACFQB8I/HXVNB1j4S/DLwb4q0zX/AA/dIvhrxt4d8Q6XLc3d7NH4Xv8A w34dvP7Ct9A1S2e58S6pN440rQvDuk6tIZH1HXIdStLKW70lJ7XtwsbSlNShJcvJKLTtecZTXM5R tyrkblJaWTTepyYiV4qMoyi+ZSTTTbs1HS0k7tzSSfWSdtD648HeMf8AhMZ9G8VaRoNyuh+IfBWn a7oV2t/pEkeq6PrMltqOn6jCsV3vijntJ4JVjuUinAmUNGpDgctSHJJxck5JuMlaS5XF2ad0r632 vsdEJuaUuVpNJptxfMnqno366npH22//AOgNdf8AgXp3/wAlVBYfbb//AKA11/4F6d/8lUAH22// AOgNdf8AgXp3/wAlUAH22/8A+gNdf+Benf8AyVQBl6JeXw0jTQNHuWAs4MMLrT8H92OebrPPvzQB qfbb/wD6A11/4F6d/wDJVAB9tv8A/oDXX/gXp3/yVQAfbb//AKA11/4F6d/8lUAH22//AOgNdf8A gXp3/wAlUAH22/8A+gNdf+Benf8AyVQAfbb/AP6A11/4F6d/8lUAH22//wCgNdf+Benf/JVAB9tv /wDoDXX/AIF6d/8AJVAB9tv/APoDXX/gXp3/AMlUAH22/wD+gNdf+Benf/JVAB9tv/8AoDXX/gXp 3/yVQAfbb/8A6A11/wCBenf/ACVQAfbb/wD6A11/4F6d/wDJVAB9tv8A/oDXX/gXp3/yVQAfbb// AKA11/4F6d/8lUAH22//AOgNdf8AgXp3/wAlUAH22/8A+gNdf+Benf8AyVQAfbb/AP6A11/4F6d/ 8lUAH22//wCgNdf+Benf/JVAB9tv/wDoDXX/AIF6d/8AJVAB9tv/APoDXX/gXp3/AMlUAH22/wD+ gNdf+Benf/JVAB9tv/8AoDXX/gXp3/yVQBma1eXx0jVAdHuVBsLvLG60/A/cPknF1k49uTQBp/bb /wD6A11/4F6d/wDJVAHwP8QrC2l8NeDpLXwx/wALNuE+CnxKvreDUJotWj0rxLp+heGL3w/4BiSH T7o2Fl8QrmK5sJbMul5NdaJpzQMZbVSO2g5W6Q/eUlomuaDcuabd9XBWd9fifc46yjd6ub5Klk5J 2l7vueSnt8uux6N8QtT8e+EPAsN5+z9a2njTx41n8ONE0Twn4l1XHh/w9pGueOPDWheIbjULTR5N Gu9L0vwd4VvtV1maCOS3+yRaKN8DxQSWz+Bn2IzbD4GVTKMHQxeYSxODo06VdTjRdKvjsPRxWIqy hOE3DC4apWxLan/y7+1ez+88PMt4MzTiWjheO87x+ScMQyvP8bjMblrw8sweLy3Icxx+UZbglicP iaDxGbZrh8HllKNSjLnlilGMqcmqkfHtZ/aY/aqsX1LRtM/Y/wDG+p63b+JPFXhnTdY/4TiIeFry DRbOWDRfGVzNFoLRw6D4j1c2eoWlja61eAeHLmeJtfj1+wlsJPl6vEXFEXUpU+DsVUrLE4rDU6jx SWGlGjGUaGMlKNJpUMTV5KkIQqzaw05KVaOIpuk/1/A+FPg5XWFxuL8esowuAqZXk+a4rB/2Snm9 Grj68KmPyOlTnjVKpmOV4L2+GrYmtgqClmlKnOOXzy7EQxMdrS/2kv2j9QZbJf2SfHzahZ6at7qV 7eeOj4a0HUJ4/BnivxU9n4cuNd8Fi5nvtR1DQtD8JabZ6smnpZ+JfGGm6d4g1DSjY301bw4h4hm+ RcI4xzhTU6k5Yp4ejUf1PF4rkw8q+FUpTqVKFDC04VlSUMRjKcK9Sl7Oo1wYrwt8LKCeIl46ZHDD V8VKhhaFHKKWa5hh6cs8yfKFXzSnl+cOlTw+Hw2Y5hnOJr4OWKlWyvJMVicuw+M+s4eD9G+A/wAa fi58T/EepaP8S/gP42+CulWfhKw1208Saz4qGp6dqWtXOpy2Vz4aSK/8L+G7u2v7ezWPU9nkXOyA yR3EkUgiEvfkucZtmOIqUsw4fxOU044WnXhiKtZ1adStOpKE8OlOhh5xqRgo1LcsrRbUmnv814g8 B8D8K5Zhcdwt4p5Rx1i6+c4rL6+V4LA08JicLgaWFp16WaueHzPNKNXDVa8p4W/tKTlUUZ04zi58 n1R5Np/0H7v/AMGNt/8AG6+kPyQzNGhtDpOnE69dqfsdvlf7RtuP3a8f6vtQBp+Taf8AQfu//Bjb f/G6ADybT/oP3f8A4Mbb/wCN0AHk2n/Qfu//AAY23/xugA8m0/6D93/4Mbb/AON0AHk2n/Qfu/8A wY23/wAboAPJtP8AoP3f/gxtv/jdAB5Np/0H7v8A8GNt/wDG6ADybT/oP3f/AIMbb/43QAeTaf8A Qfu//Bjbf/G6ADybT/oP3f8A4Mbb/wCN0AHk2n/Qfu//AAY23/xugA8m0/6D93/4Mbb/AON0AHk2 n/Qfu/8AwY23/wAboAPJtP8AoP3f/gxtv/jdAB5Np/0H7v8A8GNt/wDG6ADybT/oP3f/AIMbb/43 QAeTaf8AQfu//Bjbf/G6ADybT/oP3f8A4Mbb/wCN0AHk2n/Qfu//AAY23/xugA8m0/6D93/4Mbb/ AON0AHk2n/Qfu/8AwY23/wAboAPJtP8AoP3f/gxtv/jdAB5Np/0H7v8A8GNt/wDG6AM3WIbQaTqZ GvXbH7Bd4U6jbfMfIfg4jBOemM5PTvQBpeTaf9B+7/8ABjbf/G6APxZ/b/8AjLr3wQ8J/CW78I6B 4RvJda/Zg+PuqagNd07UbiG4v9Kh+EMWn3U1vpur6TBc3NmdRuprW7u47i7tZpHa1nhWa4Sb1cup qrzKUpq1aglZ6pWq7XTte2vfqeZj5+yacYwd6VZvmju1yWvZq+732u+7P1a+FVlps3h74e3iaXYW 76j8KPCt9cqkUk7PPcWOmSs813fy3mo3sgMjg3eo3t7fTktLdXdxO8kr+dVbdSd23acrX9X02Xy0 PQppckGkleMW7en3v56nsH2Cx/58rT/wHh/+IrMsPsFj/wA+Vp/4Dw//ABFAB9gsf+fK0/8AAeH/ AOIoAPsFj/z5Wn/gPD/8RQBl6JY2TaRppNnaEmytySbeHJPljk/JQBqfYLH/AJ8rT/wHh/8AiKAD 7BY/8+Vp/wCA8P8A8RQAfYLH/nytP/AeH/4igA+wWP8Az5Wn/gPD/wDEUAH2Cx/58rT/AMB4f/iK AD7BY/8APlaf+A8P/wARQAfYLH/nytP/AAHh/wDiKAD7BY/8+Vp/4Dw//EUAH2Cx/wCfK0/8B4f/ AIigA+wWP/Plaf8AgPD/APEUAH2Cx/58rT/wHh/+IoAPsFj/AM+Vp/4Dw/8AxFAB9gsf+fK0/wDA eH/4igA+wWP/AD5Wn/gPD/8AEUAH2Cx/58rT/wAB4f8A4igA+wWP/Plaf+A8P/xFAB9gsf8AnytP /AeH/wCIoAPsFj/z5Wn/AIDw/wDxFAB9gsf+fK0/8B4f/iKAD7BY/wDPlaf+A8P/AMRQAfYLH/ny tP8AwHh/+IoAPsFj/wA+Vp/4Dw//ABFAB9gsf+fK0/8AAeH/AOIoAzNasbIaPqhFnaAjT7sg/Z4c g+RJz9ygDT+wWP8Az5Wn/gPD/wDEUAf/2c5QSwMEFAAGAAgAAAAhAHu5WRdIAQAAZQIAABEACAFk b2NQcm9wcy9jb3JlLnhtbCCiBAEooAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIySX0vD MBTF3wW/Q8l7m6bFoaHtQGUP4mBg/YNvIbnbik0aksxu39603WrHfPAx95z8cs4l2Xwv6+AbjK0a lSMSxSgAxRtRqU2OXstFeIsC65gSrG4U5OgAFs2L66uMa8obAyvTaDCuAht4krKU6xxtndMUY8u3 IJmNvEN5cd0YyZw/mg3WjH+xDeAkjmdYgmOCOYY7YKhHIjoiBR+RemfqHiA4hhokKGcxiQj+9Tow 0v55oVcmTlm5g/adjnGnbMEHcXTvbTUa27aN2rSP4fMT/LF8fumrhpXqdsUBFZnglBtgrjHF0yp4 Y9bCzmR4Mu5WWDPrln7b6wrE/eHMeal6Zl9hAIMIfCg6VDgp7+nDY7lARRKTOIzTMJmVSUJvCI3T z+7xs/tdyGEgjxH+Q7wryR1NZjQlE+IJUGT44mMUPwAAAP//AwBQSwMEFAAGAAgAAAAhAKuYraaZ AQAAKAMAABAACAFkb2NQcm9wcy9hcHAueG1sIKIEASigAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAnJLBbtswDIbvA/oOgu6NnGAYhkBWUaQdemixAE7bsybTsVBbEkTWiPf0k214cbqe5hNF /vj5kaa8ObUN6yCi9S7n61XGGTjjS+uOOX8+/Lj+zhmSdqVuvIOc94D8Rl19kfvoA0SygCxZOMx5 TRS2QqCpodW4SmWXKpWPrab0jEfhq8oauPPmvQVHYpNl3wScCFwJ5XX4a8gnx21H/2taejPw4cuh DwlYydsQGms0pSnVkzXRo6+IPWljHXms2f3JQCPFUiYTZwHmPVrqVSbF8ikLoxvYpRaq0g2CFOeE fAA9rG+vbUQlO9p2YMhHhvZ3WuCGs18aYQDLeaej1Y4S4CCbHmPcBKSoXn18wxqAUIokmJJjuNQu Y/tVrUdBCi6Fg8EEkgqXiAdLDeDPaq8jfUK8XhKPDBPvhFMMfFPPJd84cur0wXvn26Bdr3YWjWdF jwRtGm5Oy0fr3vA5HPydJph3e5mURa0jlOl3zPVzQj6ktcZmMNnV2h2hnDX/FoabeJkOX603qyx9 4wHMOSnOJ67+AAAA//8DAFBLAQItABQABgAIAAAAIQDdsQorbwEAAMQEAAATAAAAAAAAAAAAAAAA AAAAAABbQ29udGVudF9UeXBlc10ueG1sUEsBAi0AFAAGAAgAAAAhAH0T0FgMAQAA3QIAAAsAAAAA AAAAAAAAAAAAbQMAAF9yZWxzLy5yZWxzUEsBAi0AFAAGAAgAAAAhALhIHLX0AAAAugIAABoAAAAA AAAAAAAAAAAAWQYAAHhsL19yZWxzL3dvcmtib29rLnhtbC5yZWxzUEsBAi0AFAAGAAgAAAAhAAWW z2W2AQAACgMAAA8AAAAAAAAAAAAAAAAAjQgAAHhsL3dvcmtib29rLnhtbFBLAQItABQABgAIAAAA IQDTMIM/rg8AABQxAAAUAAAAAAAAAAAAAAAAAHAKAAB4bC9zaGFyZWRTdHJpbmdzLnhtbFBLAQIt ABQABgAIAAAAIQCQpNUaswIAAI4OAAANAAAAAAAAAAAAAAAAAFAaAAB4bC9zdHlsZXMueG1sUEsB Ai0AFAAGAAgAAAAhAMh71qn8BgAAih0AABMAAAAAAAAAAAAAAAAALh0AAHhsL3RoZW1lL3RoZW1l MS54bWxQSwECLQAUAAYACAAAACEAt/UTRF4JAABeJgAAGAAAAAAAAAAAAAAAAABbJAAAeGwvd29y a3NoZWV0cy9zaGVldDEueG1sUEsBAi0ACgAAAAAAAAAhACAm9mdgNAAAYDQAABcAAAAAAAAAAAAA AAAA7y0AAGRvY1Byb3BzL3RodW1ibmFpbC5qcGVnUEsBAi0AFAAGAAgAAAAhAHu5WRdIAQAAZQIA ABEAAAAAAAAAAAAAAAAAhGIAAGRvY1Byb3BzL2NvcmUueG1sUEsBAi0AFAAGAAgAAAAhAKuYraaZ AQAAKAMAABAAAAAAAAAAAAAAAAAAA2UAAGRvY1Byb3BzL2FwcC54bWxQSwUGAAAAAAsACwDFAgAA 0mcAAAAA --Apple-Mail-84--473908197 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit
--Apple-Mail-84--473908197-- --Apple-Mail-83--473908197-- From trac@tools.ietf.org Mon Mar 29 12:39: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 3633F3A67EA for ; Mon, 29 Mar 2010 12:39:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.948 X-Spam-Level: X-Spam-Status: No, score=-100.948 tagged_above=-999 required=5 tests=[AWL=0.522, 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 LWTJFsAC4ZjC for ; Mon, 29 Mar 2010 12:39:25 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 942813A67D2 for ; Mon, 29 Mar 2010 12:39:25 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1NwKoS-0003FK-TK; Mon, 29 Mar 2010 12:39:53 -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: wintert@acm.org, jpv@cisco.com X-Trac-Project: roll Date: Mon, 29 Mar 2010 19:39:52 -0000 X-URL: http://tools.ietf.org/wg/roll/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/roll/trac/ticket/30 Message-ID: <055.d2eab2c729c6835d4457709ee6cb8117@tools.ietf.org> X-Trac-Ticket-ID: 30 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: wintert@acm.org, 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] #30: Clearly documenting Multicast mode of operation 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, 29 Mar 2010 19:39:26 -0000 #30: Clearly documenting Multicast mode of operation --------------------------------+------------------------------------------- Reporter: jpv@… | Owner: wintert@… Type: task | Status: new Priority: minor | Milestone: Component: rpl | Version: Severity: Active WG Document | Keywords: --------------------------------+------------------------------------------- Dear all, Several of you mentioned that the RPL Multicast mode of operation was not clear in the ID. This ticket is to make sure that we address with concern. Thanks. JP. -- Ticket URL: roll From jpv@cisco.com Mon Mar 29 12:42: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 EC4A83A6AC3 for ; Mon, 29 Mar 2010 12:42:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.268 X-Spam-Level: X-Spam-Status: No, score=-7.268 tagged_above=-999 required=5 tests=[AWL=2.199, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, 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 0pbJk5wnVlAR for ; Mon, 29 Mar 2010 12:42:01 -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 D38DD3A6807 for ; Mon, 29 Mar 2010 12:42:01 -0700 (PDT) Authentication-Results: sj-iport-4.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: AhsFAE2fsEurR7H+/2dsb2JhbACBPplocacSmG6FAQQ X-IronPort-AV: E=Sophos;i="4.51,329,1267401600"; d="scan'208,217";a="107180663" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-4.cisco.com with ESMTP; 29 Mar 2010 19:42:29 +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 o2TJgRuW017860 for ; Mon, 29 Mar 2010 19:42:28 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); Mon, 29 Mar 2010 21:42:27 +0200 Received: from dhcp-144-254-20-202.cisco.com ([144.254.20.202]) by xfe-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 29 Mar 2010 21:42:26 +0200 Message-Id: From: JP Vasseur To: ROLL WG Content-Type: multipart/alternative; boundary=Apple-Mail-87--473229858 Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 29 Mar 2010 21:42:26 +0200 References: <20100329160002.066BA3A6AAA@core3.amsl.com> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 29 Mar 2010 19:42:26.0949 (UTC) FILETIME=[F60B8B50:01CACF77] Subject: [Roll] Fwd: I-D Action:draft-ietf-roll-terminology-03.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Mar 2010 19:42:03 -0000 --Apple-Mail-87--473229858 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit just a refresh Begin forwarded message: > From: Internet-Drafts@ietf.org > Date: March 29, 2010 6:00:02 PM CEDT > To: i-d-announce@ietf.org > Cc: roll@ietf.org > Subject: I-D Action:draft-ietf-roll-terminology-03.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 : Terminology in Low power And Lossy Networks > Author(s) : J. Vasseur > Filename : draft-ietf-roll-terminology-03.txt > Pages : 9 > Date : 2010-03-29 > > The documents defines a terminology for discussing routing > requirements and solutions for networks referred to as Low power and > Lossy Networks (LLN). A LLN is typically composed of many embedded > devices with limited power, memory, and processing resources > interconnected by a variety of links. There is a wide scope of > application areas for LLNs, including industrial monitoring, building > automation (e.g. Heating, Ventilating, Air Conditioning, lighting, > access control, fire), connected home, healthcare, environmental > monitoring, urban sensor networks, energy management, assets > tracking, refrigeration. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-roll-terminology-03.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > _______________________________________________ > 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-87--473229858 Content-Type: multipart/mixed; boundary=Apple-Mail-88--473229857 --Apple-Mail-88--473229857 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable just a = refresh

Begin forwarded message:

Date: March 29, 2010 6:00:02 PM = CEDT
To: i-d-announce@ietf.org
Subject: = I-D Action:draft-ietf-roll-terminology-03.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 =           : = Terminology in Low power And Lossy Networks
Author(s) =       : J. Vasseur
Filename =        : = draft-ietf-roll-terminology-03.txt
Pages =           : 9
Date =            : = 2010-03-29

The documents defines a terminology for discussing = routing
requirements and solutions for networks referred to as Low = power and
Lossy Networks (LLN).  A LLN is typically composed of = many embedded
devices with limited power, memory, and processing = resources
interconnected by a variety of links.  There is a wide = scope of
application areas for LLNs, including industrial monitoring, = building
automation (e.g.  Heating, Ventilating, Air = Conditioning, lighting,
access control, fire), connected home, = healthcare, environmental
monitoring, urban sensor networks, energy = management, assets
tracking, refrigeration.

A URL for this = Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-roll-terminology-03.t= xt

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-88--473229857 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-03-29085231.I-D@ietf.org>

--Apple-Mail-88--473229857 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-88--473229857-- --Apple-Mail-87--473229858-- From pal@cs.stanford.edu Mon Mar 29 12:50: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 801113A691B for ; Mon, 29 Mar 2010 12:50:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.15 X-Spam-Level: X-Spam-Status: No, score=-5.15 tagged_above=-999 required=5 tests=[AWL=0.319, 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 cvZP6mb3eRvB for ; Mon, 29 Mar 2010 12:50:10 -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 BB2C93A690D for ; Mon, 29 Mar 2010 12:50:10 -0700 (PDT) Received: from [76.14.71.8] (helo=[192.168.1.103]) by cs-smtp-3.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1NwKys-0005uQ-US; Mon, 29 Mar 2010 12:50:39 -0700 Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Philip Levis In-Reply-To: <20100.1269887835@marajade.sandelman.ca> Date: Mon, 29 Mar 2010 12:50:38 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <642963F2-F363-495D-97B1-04412446EFEA@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> To: Michael Richardson X-Mailer: Apple Mail (2.1077) X-Scan-Signature: 9dddbef7dbf47a29383c7a3c8e5dce6e 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: Mon, 29 Mar 2010 19:50:11 -0000 On Mar 29, 2010, at 11:37 AM, Michael Richardson wrote: >=20 >>>>>> "Don" =3D=3D Don Sturek writes: > Don> Storing devices that are out of resources to store either need > Don> to become non-storing (if that is legal in the DAG they are a > Don> member) or must become=20 > Don> leaf devices. I don't see any other alternative. >=20 > I wasn't asking about RPL. > I was asking about current (proprietary) deployed solutions. >=20 > There is a belief that the mixed mode has never been deployed in any > proprietary solution. Given that, in networks with storing nodes, = when > the node gets full, what happens? Jonathan mentioned this in his presentation at Anaheim: you = provision/design your network so this doesn't happen.=20 Phil= From roger.alexander@ekasystems.com Mon Mar 29 14:31: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 4D3E93A6996 for ; Mon, 29 Mar 2010 14:31:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.581 X-Spam-Level: ** X-Spam-Status: No, score=2.581 tagged_above=-999 required=5 tests=[BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, 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 LL8oeNsIBU8y for ; Mon, 29 Mar 2010 14:31:54 -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 7FB6A3A698E for ; Mon, 29 Mar 2010 14:31:54 -0700 (PDT) Received: (qmail 79845 invoked from network); 29 Mar 2010 21:32:20 -0000 Received: from dallas (roger.alexander@209.48.242.70 with login) by smtp113.biz.mail.re2.yahoo.com with SMTP; 29 Mar 2010 14:32:20 -0700 PDT X-Yahoo-SMTP: 1dQRPo6swBBzwSsRzMLy_tvdRrLDyF0J X-YMail-OSG: 7Mi5l24VM1mdYeIgM2gm3ya5I_0kBCRip7HNZaDPIo866Tj4l9q9ckw6v_yEZ2l3tu68C8PFxtTGLgsT0wDvRChYVpz953WMRE.nxAZlDxsLf_w.GWq9TyzU_DMcViM_jA.eAQF0i12b0eKNoLAuc6x_N61m9itjIb3jleoaBox3ufCE4EpjwmJTp45tEm3uwuMRA84qbbw0fnhAhFQLz5LJfwD88H1crAg0k3FXpkiajqBRm4nasseF54pCL6.Y3uaxt1NTFku9t4mVUaZY6eZFDxDf5VcQUX.N3ey.lJSnvqZLNBn.J2fU.veUrYX2aVsnuV__2y1md.qHhoR.l.T0sLtHU_bP_no57JLnfsj_J7VTkD_yYqVEqvce8sSE X-Yahoo-Newman-Property: ymail-3 From: "Roger Alexander" To: "'Pascal Thubert \(pthubert\)'" , "'JeongGil Ko \(John\)'" 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> In-Reply-To: <6A2A459175DABE4BB11DE2026AA50A5D0188AAFB@XMB-AMS-107.cisco.com> Date: Mon, 29 Mar 2010 17:31:11 -0400 Message-ID: <006f01cacf87$273db310$75b91930$@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: AcrPBZhM1eTe7mwEQYWYbf4/FDhErAAAMQqgABqo29A= Content-Language: en-us 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, 29 Mar 2010 21:31:56 -0000 Hi Pascal, John, > -----Original Message----- > From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of > Pascal Thubert (pthubert) > Sent: Monday, March 29, 2010 2:33 AM > To: JeongGil Ko (John) > Cc: roll@ietf.org > Subject: Re: [Roll] proposal for DAOs in non-caching DODAGs > > Hi John: > > I think I see what you're saying. > > If the metrics are asymmetrical, then it might occur that the DAO > parents set is not the exact same as DIO parent set. A node would > prefer > a DAO parent for which the metrics from the root to the node are > optimal. So theoretically following the preferred parent path provides > the best metrics without using the DAO rank. > I agree and I think this is an important point that does not seem consistently emphasized in the current draft. A central principle in the DAG connectivity is that a node chooses its DAO Parents and by so doing dictates the downward routing. Whether a DAG Metric is added to address link asymmetry, the key is that since nodes choose their DAO Parents and not vice-versa, downward routing is dictated by the nodes' choice of Parents. With storing nodes performing hop-by-hop routing there is no need to maintain node DAO Rank to derive downward routes. In the DAO message (Section 6.1, see Figure 11), DAO Rank is included as a communicated information element. Similarly in the DAO Routing Table Entry (Section 6.2.4.1), DAO Rank is maintained. For storing nodes, this information is not needed other than for local confirmation and validation of the DAO Parent-Child relationship during a DAO exchange (where rank may have changed since last broadcast DIO). Thus for storing and non-storing modes alike it appears the DAO rank information is not necessary for downward routing. > The current spec enables the OF in a node to compute a DAO Rank based > on > the metrics option pretty much like a DIO Rank would be computed using > a > DAO DAG Metric Container. This was introduced at some point along the > path and provides an additional capability to rate non preferred paths. > I figure that you're willing to emulate that in the source route DAO > > My take is that we have already added too much complexity even though > we > made it optional. I'd rather remove the DAO DAG Metric Container. But > in > any fashion I have to agree with your desire to make things consistent. > Then again, slippery slope towards link state... > > Pascal > > > > -----Original Message----- > > From: JeongGil (John) Ko [mailto:jeonggil.ko@gmail.com] On Behalf Of > > JeongGil Ko (John) > > Sent: Monday, March 29, 2010 8:04 AM > > To: Pascal Thubert (pthubert) > > Cc: Richard Kelsey; roll@ietf.org > > Subject: Re: [Roll] proposal for DAOs in non-caching DODAGs > > > > Hi Pascal, > > > > I see your point. One question, that confuses me is how the set of > 'preferred > > DAO parents' are determined. Is this set different from the preferred > parent > > set in DIOs? I guess another way of asking is to ask is how the > DAORank is > > defined and computed (this question was asked previously but I didn't > really > > get a clear answer). Will each node that initiates a DAO for a > specific prefix be > > DAORank = 1 and the rank computation continue just like the DIO > process? In > > this case is it true that each node may need to maintain different > DAORank > > values for many different prefixes? > > > > Thanks! > > > > -John > > > > On Mar 28, 2010, at 10:44 PM, Pascal Thubert (pthubert) wrote: > > > > > Hi John: > > > > > > Obviously, having multiple parents enables the root to compute > > > multiple paths down to the node. So your proposal is tempting. But > > > beware, this is a slippery slope towards centralized Link State > > > computation and away from the RPL core design, and we can't be > > > designing 2 protocols, by charter. > > > > > > The RPL design is that the choice of the best parents belongs to > the > > > OF in the node, not the root. Richard's proposal centralizes in the > > > root the forwarding decision along the DAG that happens hop by hop > > > with stateful DAOs, but the routing states are built in the exact > > > same fashion whether it is stateful or stateless, by having each > node > > > select a set of preferred DAO parents. Note that we do not specify > how > > > a node selects the next hop between multiple DAO children in the > stateful > > mode. > > > In the same fashion, we do not specify how the root makes the multi > > > hop decision. > > > > > > My suggestion to address your problem would be that the OF in the > node > > > provides more info on how it orders the parents, maybe by setting a > > > preference level (like 0-3) for each parent in the source route > DAO. > > > The root retains the possibility to build multiple non-overlapping > > > path, do load balancing, signal to L2 when L2 paths/circuits need > to > > > be enabled, etc... We have not made the step towards a centralized > > routing model. > > > > > > Cheers, > > > > > > Pascal > > > > > > > > >> -----Original Message----- > > >> From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On > Behalf > > > Of > > >> JeongGil Ko (John) > > >> Sent: Sunday, March 28, 2010 11:42 PM > > >> To: Richard Kelsey > > >> Cc: roll@ietf.org > > >> Subject: Re: [Roll] proposal for DAOs in non-caching DODAGs > > >> > > >> Richard, > > >> > > >> I agree that if we start adding downwards routes then the root > will > > > have > > >> many sub-route (or sub-path) information that it already has. If > we > > > decide > > >> the add the neighbor (parent) information in the DAOs do we also > add > > > link > > >> quality estimation values for each link associated with a parent > node? > > >> Otherwise the root will have a connectivity graph of the network > > >> (DAG) > > > but > > >> will have no way to figure out which path is cost-efficient to > select > > > (the root > > >> can come up with many combinations of paths to select from)? > > >> > > >> Thanks. > > >> > > >> -John > > >> > > >> On Mar 28, 2010, at 2:20 PM, Richard Kelsey wrote: > > >> > > >>> 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. > > >>> > > >>> 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. > > >>> > > >>> 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. > > >>> > > >>> 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. > > >>> > > >>> 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 > > >>> > > >>> What do people think? > > >>> -Richard Kelsey > > >>> _______________________________________________ > > >>> 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 > > > > > > > ------ > > 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 roger.alexander@ekasystems.com Mon Mar 29 14:35: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 46E2D3A698E for ; Mon, 29 Mar 2010 14:35:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.581 X-Spam-Level: ** X-Spam-Status: No, score=2.581 tagged_above=-999 required=5 tests=[BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, 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 yUh5b3Csc7sl for ; Mon, 29 Mar 2010 14:35:23 -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 6279A3A6989 for ; Mon, 29 Mar 2010 14:35:23 -0700 (PDT) Received: (qmail 14077 invoked from network); 29 Mar 2010 21:35:49 -0000 Received: from dallas (roger.alexander@209.48.242.70 with login) by smtp114.biz.mail.re2.yahoo.com with SMTP; 29 Mar 2010 14:35:49 -0700 PDT X-Yahoo-SMTP: 1dQRPo6swBBzwSsRzMLy_tvdRrLDyF0J X-YMail-OSG: wAlPAFwVM1nUXlIvuujGFM9XEswmgUzL_2xcUTcVPoqS.RxEWPtenyLWtmBlQZZ1S9bS7UWe_9L7syFxXekFvwklnoqXxt3MjuLR6D6CA0SJZyq5fwAa2JAdlcvYdKGgDLvaTanUZ9M01GIN_wwi9kEwQfzhAdMA9koYF7luKLGi.STKT6XZe.ijc0JeKGvhS0WikeC5g9tMycFfONtYjSr4nmSDRIAZiwf1ULRghtzVe0Es2VIVzRzdlYOy.Pkh2jEUp0qgOVLePW0fpP4mdb3_JgFR_PQ91sFccsJwQpP4oxTMl9BF_b5q9Q3ZBR76zWgoIcgkMpQrkM51Cqaox2G59Y_2ivusc_05HteiwZ1tdR.B5x1hQiCBnxx4I0Rp X-Yahoo-Newman-Property: ymail-3 From: "Roger Alexander" To: "'Richard Kelsey'" , References: <87vdcg5eis.fsf@kelsey-ws.hq.ember.com> In-Reply-To: <87vdcg5eis.fsf@kelsey-ws.hq.ember.com> Date: Mon, 29 Mar 2010 17:34:40 -0400 Message-ID: <007001cacf87$a3bb0dc0$eb312940$@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: AcrOvPOfzZAAtHECRpGV+S5gefbkgQAtMs9g Content-Language: en-us 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, 29 Mar 2010 21:35:24 -0000 Hi Richard, As indicated previously, I would support this focus on the storing-only and non-storing DODAGs models within the RPL effort. The benefits of your proposal for non-caching nodes further makes the case for the gains from a focus on the specific modes. Also, in the context of a network with storing-only nodes there are also a number of optimizations that can be introduced in the DAO mechanism, particularly where acknowledged exchanges occur between nodes and their DAO Parents. A separate proposal for storing nodes only will be put forward but at this point I would like to endorse your current proposal. Roger > -----Original Message----- > From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of > Richard Kelsey > Sent: Sunday, March 28, 2010 5:21 PM > To: roll@ietf.org > Subject: [Roll] proposal for DAOs in non-caching DODAGs > > 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. > > 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. > > 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. > > 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. > > 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 > > What do people think? > -Richard Kelsey > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From roger.alexander@ekasystems.com Mon Mar 29 14:42: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 118923A6B7F for ; Mon, 29 Mar 2010 14:42:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.581 X-Spam-Level: ** X-Spam-Status: No, score=2.581 tagged_above=-999 required=5 tests=[BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, 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 Qj6BMcyLZEVM for ; Mon, 29 Mar 2010 14:42:06 -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 092743A6B7A for ; Mon, 29 Mar 2010 14:42:05 -0700 (PDT) Received: (qmail 27184 invoked from network); 29 Mar 2010 21:42:31 -0000 Received: from dallas (roger.alexander@209.48.242.70 with login) by smtp115.biz.mail.re2.yahoo.com with SMTP; 29 Mar 2010 14:42:31 -0700 PDT X-Yahoo-SMTP: 1dQRPo6swBBzwSsRzMLy_tvdRrLDyF0J X-YMail-OSG: 51uT8BMVM1mRi5Ws3AOfD6cmeGMSpPRFFG43HBV6OOKLPva54vXesP5hNUPatzEiXviM45usHsqWKpesiR51bGaoEEb2rwaZa7iGNRH5Vs1jTgix.K7nscgQH8Mh3BRSxorHtkCRmCQFmjOXaEqcbDks3RlzGrCPLnZEEOXD5.1eJGt3Aay4K9m03VZLkMQnQ43JQKzqjHEfaBk1j41DPW_eLmCS4jbgWWDNgY3fL4ppVZbssSdbdEfDVfKSUcMMSQLWrbkQEkXFdnD_wcHVK8JP0P.ddrQb.aGz2WaO2COeMWGhFKLEuV9mkaNpzafYHM5x_x4wEdQGiSVEiOrHVmGFSAGH3HtOxL.gF_Yo1iM6yr07_KQJ2O0FexZTLjhx X-Yahoo-Newman-Property: ymail-3 From: "Roger Alexander" To: "'Anders Brandt'" , "'Richard Kelsey'" , References: <87vdcg5eis.fsf@kelsey-ws.hq.ember.com> <6D9687E95918C04A8B30A7D6DA805A3E01429FA1@zensys17.zensys.local> In-Reply-To: <6D9687E95918C04A8B30A7D6DA805A3E01429FA1@zensys17.zensys.local> Date: Mon, 29 Mar 2010 17:41:22 -0400 Message-ID: <007101cacf88$93bdecc0$bb39c640$@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: AcrOvPYYMXCZA0o7SvShDKSUGdKOoAAcXRWwABPgYwA= Content-Language: en-us 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, 29 Mar 2010 21:42:07 -0000 Hi Anders, > -----Original Message----- > From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of > Anders Brandt > Sent: Monday, March 29, 2010 7:33 AM > To: Richard Kelsey; roll@ietf.org > Subject: Re: [Roll] proposal for DAOs in non-caching DODAGs > > > > While we cannot see the need, neither know how to make it work, mixed > mode may prove needed and > powerful in the future. > I therefore think that it is not so bad that we planned for one frame > format in RPL until now. > For the same reason I think that we should stick with the same frame > format even when running > RPL in single-mode, be that storing or non-storing. > I would agree here. The option for mixed mode should fit within the proposed structure and formats for storing or non-storing only modes. > - Anders > > > -----Original Message----- > > From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On > > Behalf Of Richard Kelsey > > Sent: Sunday, March 28, 2010 23:21 > > To: roll@ietf.org > > Subject: [Roll] proposal for DAOs in non-caching DODAGs > > > > 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. > > > > 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. > > > > 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. > > > > 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. > > > > 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 > > > > What do people think? > > -Richard Kelsey > > _______________________________________________ > > Roll mailing list > > Roll@ietf.org > > https://www.ietf.org/mailman/listinfo/roll > > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From jeonggil.ko@gmail.com Mon Mar 29 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 E52533A69B6 for ; Mon, 29 Mar 2010 14:47:57 -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 dHbBHGkBMzd8 for ; Mon, 29 Mar 2010 14:47:56 -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 68E583A69B5 for ; Mon, 29 Mar 2010 14:47:56 -0700 (PDT) Received: by pwi10 with SMTP id 10so7262233pwi.31 for ; Mon, 29 Mar 2010 14:48:22 -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=WXDwXVBF70YdJ8+8FN9uSNuzTZOkg0ic/ydV2dN2Yqg=; b=BnHv4cQAqnxCV0yYVDJfMuuAkxZWgYMiW18yZY06LSgRCq8IoFKK/z2QtYPhsRLujL uqhHIFmc/cNMxQVUD4c51usH5M+mPtxguRTqe0A2vyfXI3lPR1cnwnms69mTu5fqCbm2 CQeXUAn7VD7TLCI+M9KqMbiVhWZlz42CAILvY= 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=XEoirdYs1mzyROPNL7PQLdxGDRir3uUqGAJ0+KHoEvABf2Gyqc26zH/XYNyWVt3RDZ CNmSWbsjYW2DcY3G/infzjBcjyc2JevTAdek7ZYEfYdychkx67qFuLMSgfKhyEue+CDI mpl31bvFukirUClVF7XrGC41zYSqUjU7fCA9c= Received: by 10.141.214.28 with SMTP id r28mr2209370rvq.105.1269899301889; Mon, 29 Mar 2010 14:48:21 -0700 (PDT) Received: from dnab404649.stanford.edu (DNab404649.Stanford.EDU [171.64.70.73]) by mx.google.com with ESMTPS id k17sm466493rvh.13.2010.03.29.14.48.17 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 29 Mar 2010 14:48:19 -0700 (PDT) Sender: "JeongGil (John) Ko" Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: "JeongGil Ko (John)" In-Reply-To: <006f01cacf87$273db310$75b91930$@alexander@ekasystems.com> Date: Mon, 29 Mar 2010 14:48:15 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <5A5438DD-F6D3-4E09-A3E4-A269319F8EEC@cs.jhu.edu> 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> To: Roger Alexander X-Mailer: Apple Mail (2.1077) 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, 29 Mar 2010 21:47:58 -0000 Hey Roger, On Mar 29, 2010, at 2:31 PM, Roger Alexander wrote: > Hi Pascal, John, >=20 >=20 >> -----Original Message----- >> From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf = Of >> Pascal Thubert (pthubert) >> Sent: Monday, March 29, 2010 2:33 AM >> To: JeongGil Ko (John) >> Cc: roll@ietf.org >> Subject: Re: [Roll] proposal for DAOs in non-caching DODAGs >>=20 >> Hi John: >>=20 >> I think I see what you're saying. >>=20 >> If the metrics are asymmetrical, then it might occur that the DAO >> parents set is not the exact same as DIO parent set. A node would >> prefer >> a DAO parent for which the metrics from the root to the node are >> optimal. So theoretically following the preferred parent path = provides >> the best metrics without using the DAO rank. >>=20 >=20 > I agree and I think this is an important point that does not seem > consistently emphasized in the current draft. A central principle in = the DAG > connectivity is that a node chooses its DAO Parents and by so doing = dictates > the downward routing. Whether a DAG Metric is added to address link > asymmetry, the key is that since nodes choose their DAO Parents and = not > vice-versa, downward routing is dictated by the nodes' choice of = Parents. >=20 > With storing nodes performing hop-by-hop routing there is no need to > maintain node DAO Rank to derive downward routes. In the DAO message > (Section 6.1, see Figure 11), DAO Rank is included as a communicated > information element. Similarly in the DAO Routing Table Entry (Section > 6.2.4.1), DAO Rank is maintained. For storing nodes, this information = is not > needed other than for local confirmation and validation of the DAO > Parent-Child relationship during a DAO exchange (where rank may have = changed > since last broadcast DIO). Thus for storing and non-storing modes = alike it > appears the DAO rank information is not necessary for downward = routing.=20 >=20 Maybe a stupid question but I keep making this point without getting an = answer. I agree that if we have a DAO parent set and if this is reported = to the root then the need for DAO ranks go away. However, how would a = node know its DAO parents without using DAO ranks? I am (once again) not = in favor of DAOs but I just want to know how we can achieve this.=20 Thanks. -John >=20 >> The current spec enables the OF in a node to compute a DAO Rank based >> on >> the metrics option pretty much like a DIO Rank would be computed = using >> a >> DAO DAG Metric Container. This was introduced at some point along the >> path and provides an additional capability to rate non preferred = paths. >> I figure that you're willing to emulate that in the source route DAO >>=20 >> My take is that we have already added too much complexity even though >> we >> made it optional. I'd rather remove the DAO DAG Metric Container. But >> in >> any fashion I have to agree with your desire to make things = consistent. >> Then again, slippery slope towards link state... >>=20 >> Pascal >>=20 >>=20 >>> -----Original Message----- >>> From: JeongGil (John) Ko [mailto:jeonggil.ko@gmail.com] On Behalf Of >>> JeongGil Ko (John) >>> Sent: Monday, March 29, 2010 8:04 AM >>> To: Pascal Thubert (pthubert) >>> Cc: Richard Kelsey; roll@ietf.org >>> Subject: Re: [Roll] proposal for DAOs in non-caching DODAGs >>>=20 >>> Hi Pascal, >>>=20 >>> I see your point. One question, that confuses me is how the set of >> 'preferred >>> DAO parents' are determined. Is this set different from the = preferred >> parent >>> set in DIOs? I guess another way of asking is to ask is how the >> DAORank is >>> defined and computed (this question was asked previously but I = didn't >> really >>> get a clear answer). Will each node that initiates a DAO for a >> specific prefix be >>> DAORank =3D 1 and the rank computation continue just like the DIO >> process? In >>> this case is it true that each node may need to maintain different >> DAORank >>> values for many different prefixes? >>>=20 >>> Thanks! >>>=20 >>> -John >>>=20 >>> On Mar 28, 2010, at 10:44 PM, Pascal Thubert (pthubert) wrote: >>>=20 >>>> Hi John: >>>>=20 >>>> Obviously, having multiple parents enables the root to compute >>>> multiple paths down to the node. So your proposal is tempting. But >>>> beware, this is a slippery slope towards centralized Link State >>>> computation and away from the RPL core design, and we can't be >>>> designing 2 protocols, by charter. >>>>=20 >>>> The RPL design is that the choice of the best parents belongs to >> the >>>> OF in the node, not the root. Richard's proposal centralizes in the >>>> root the forwarding decision along the DAG that happens hop by hop >>>> with stateful DAOs, but the routing states are built in the exact >>>> same fashion whether it is stateful or stateless, by having each >> node >>>> select a set of preferred DAO parents. Note that we do not specify >> how >>>> a node selects the next hop between multiple DAO children in the >> stateful >>> mode. >>>> In the same fashion, we do not specify how the root makes the multi >>>> hop decision. >>>>=20 >>>> My suggestion to address your problem would be that the OF in the >> node >>>> provides more info on how it orders the parents, maybe by setting a >>>> preference level (like 0-3) for each parent in the source route >> DAO. >>>> The root retains the possibility to build multiple non-overlapping >>>> path, do load balancing, signal to L2 when L2 paths/circuits need >> to >>>> be enabled, etc... We have not made the step towards a centralized >>> routing model. >>>>=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: Sunday, March 28, 2010 11:42 PM >>>>> To: Richard Kelsey >>>>> Cc: roll@ietf.org >>>>> Subject: Re: [Roll] proposal for DAOs in non-caching DODAGs >>>>>=20 >>>>> Richard, >>>>>=20 >>>>> I agree that if we start adding downwards routes then the root >> will >>>> have >>>>> many sub-route (or sub-path) information that it already has. If >> we >>>> decide >>>>> the add the neighbor (parent) information in the DAOs do we also >> add >>>> link >>>>> quality estimation values for each link associated with a parent >> node? >>>>> Otherwise the root will have a connectivity graph of the network >>>>> (DAG) >>>> but >>>>> will have no way to figure out which path is cost-efficient to >> select >>>> (the root >>>>> can come up with many combinations of paths to select from)? >>>>>=20 >>>>> Thanks. >>>>>=20 >>>>> -John >>>>>=20 >>>>> On Mar 28, 2010, at 2:20 PM, Richard Kelsey wrote: >>>>>=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 >>>>>>=20 >>>>>=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 >>> ------ >>> 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 roger.alexander@ekasystems.com Mon Mar 29 14: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 831E63A6901 for ; Mon, 29 Mar 2010 14:59:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.581 X-Spam-Level: ** X-Spam-Status: No, score=2.581 tagged_above=-999 required=5 tests=[BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, 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 NX1ufQlvZUFw for ; Mon, 29 Mar 2010 14:59:25 -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 223093A68F6 for ; Mon, 29 Mar 2010 14:59:25 -0700 (PDT) Received: (qmail 35549 invoked from network); 29 Mar 2010 21:59:53 -0000 Received: from dallas (roger.alexander@209.48.242.70 with login) by smtp114.biz.mail.re2.yahoo.com with SMTP; 29 Mar 2010 14:59:53 -0700 PDT X-Yahoo-SMTP: 1dQRPo6swBBzwSsRzMLy_tvdRrLDyF0J X-YMail-OSG: o61N8lMVM1lAN4auY2mf6_.5U84WhaUNZavkftGD3PSXK0mhM3ZTrItt1SXQQAwriZZ3wmJFITzg_BDAJPo0raETUKRlN8dDHHrqTZ0Zr8Z6SKlZuY9Pgt_.Qa9hfI0nAO4fyLyl27ygoIuxLirTIKhRyQuDDFbxEkSwuA2BVFaNiAnxc.cL_cQ_Yq44vgLdc2iDnWrc3eVgpSsB9A_HjNfBomRCOPlTA6YUJOioPCvpdLkIZ9ICKXIuR3Wp9DaB00jziTKOilAyoZVwI4Ukq1FkV6kEAN9mcnmQp6uGV7LiaKbLr7_dBIppeMPDxQ4oiQefMjY.NIKyuFxrbY.LZIrVqV76knmxlCQCfIj7yXUuGeFlk.QNCW1eZYL.Zmwy X-Yahoo-Newman-Property: ymail-3 From: "Roger Alexander" To: "'JeongGil Ko \(John\)'" 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> In-Reply-To: <5A5438DD-F6D3-4E09-A3E4-A269319F8EEC@cs.jhu.edu> Date: Mon, 29 Mar 2010 17:58:44 -0400 Message-ID: <007201cacf8b$00817b90$018472b0$@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: AcrPiY00cqbAuC9eQaqcePRBhPWH9wAAG8Ig Content-Language: en-us 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, 29 Mar 2010 21:59:27 -0000 Hi John, > -----Original Message----- > From: JeongGil (John) Ko [mailto:jeonggil.ko@gmail.com] On Behalf Of > JeongGil Ko (John) > Sent: Monday, March 29, 2010 5:48 PM > To: Roger Alexander > Cc: 'Pascal Thubert (pthubert)'; roll@ietf.org > Subject: Re: [Roll] proposal for DAOs in non-caching DODAGs > > Hey Roger, > > > Maybe a stupid question but I keep making this point without getting an > answer. I agree that if we have a DAO parent set and if this is > reported to the root then the need for DAO ranks go away. However, how > would a node know its DAO parents without using DAO ranks? I am (once > again) not in favor of DAOs but I just want to know how we can achieve > this. > The selection of DAO Parents is based on the Rank that the candidate nodes advertise in their DIO. As for sending the DAO Parent set to the root, that is only applicable for non-storing nodes. For storing nodes the DAO(s) is sent to each of the set of DAO Parents. > Thanks. > > -John > > > > >> The current spec enables the OF in a node to compute a DAO Rank > based > >> on > >> the metrics option pretty much like a DIO Rank would be computed > using > >> a > >> DAO DAG Metric Container. This was introduced at some point along > the > >> path and provides an additional capability to rate non preferred > paths. > >> I figure that you're willing to emulate that in the source route DAO > >> > >> My take is that we have already added too much complexity even > though > >> we > >> made it optional. I'd rather remove the DAO DAG Metric Container. > But > >> in > >> any fashion I have to agree with your desire to make things > consistent. > >> Then again, slippery slope towards link state... > >> > >> Pascal > >> > >> > >>> -----Original Message----- > >>> From: JeongGil (John) Ko [mailto:jeonggil.ko@gmail.com] On Behalf > Of > >>> JeongGil Ko (John) > >>> Sent: Monday, March 29, 2010 8:04 AM > >>> To: Pascal Thubert (pthubert) > >>> Cc: Richard Kelsey; roll@ietf.org > >>> Subject: Re: [Roll] proposal for DAOs in non-caching DODAGs > >>> > >>> Hi Pascal, > >>> > >>> I see your point. One question, that confuses me is how the set of > >> 'preferred > >>> DAO parents' are determined. Is this set different from the > preferred > >> parent > >>> set in DIOs? I guess another way of asking is to ask is how the > >> DAORank is > >>> defined and computed (this question was asked previously but I > didn't > >> really > >>> get a clear answer). Will each node that initiates a DAO for a > >> specific prefix be > >>> DAORank = 1 and the rank computation continue just like the DIO > >> process? In > >>> this case is it true that each node may need to maintain different > >> DAORank > >>> values for many different prefixes? > >>> > >>> Thanks! > >>> > >>> -John > >>> > >>> On Mar 28, 2010, at 10:44 PM, Pascal Thubert (pthubert) wrote: > >>> > >>>> Hi John: > >>>> > >>>> Obviously, having multiple parents enables the root to compute > >>>> multiple paths down to the node. So your proposal is tempting. But > >>>> beware, this is a slippery slope towards centralized Link State > >>>> computation and away from the RPL core design, and we can't be > >>>> designing 2 protocols, by charter. > >>>> > >>>> The RPL design is that the choice of the best parents belongs to > >> the > >>>> OF in the node, not the root. Richard's proposal centralizes in > the > >>>> root the forwarding decision along the DAG that happens hop by hop > >>>> with stateful DAOs, but the routing states are built in the exact > >>>> same fashion whether it is stateful or stateless, by having each > >> node > >>>> select a set of preferred DAO parents. Note that we do not specify > >> how > >>>> a node selects the next hop between multiple DAO children in the > >> stateful > >>> mode. > >>>> In the same fashion, we do not specify how the root makes the > multi > >>>> hop decision. > >>>> > >>>> My suggestion to address your problem would be that the OF in the > >> node > >>>> provides more info on how it orders the parents, maybe by setting > a > >>>> preference level (like 0-3) for each parent in the source route > >> DAO. > >>>> The root retains the possibility to build multiple non-overlapping > >>>> path, do load balancing, signal to L2 when L2 paths/circuits need > >> to > >>>> be enabled, etc... We have not made the step towards a centralized > >>> routing model. > >>>> > >>>> Cheers, > >>>> > >>>> Pascal > >>>> > >>>> > >>>>> -----Original Message----- > >>>>> From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On > >> Behalf > >>>> Of > >>>>> JeongGil Ko (John) > >>>>> Sent: Sunday, March 28, 2010 11:42 PM > >>>>> To: Richard Kelsey > >>>>> Cc: roll@ietf.org > >>>>> Subject: Re: [Roll] proposal for DAOs in non-caching DODAGs > >>>>> > >>>>> Richard, > >>>>> > >>>>> I agree that if we start adding downwards routes then the root > >> will > >>>> have > >>>>> many sub-route (or sub-path) information that it already has. If > >> we > >>>> decide > >>>>> the add the neighbor (parent) information in the DAOs do we also > >> add > >>>> link > >>>>> quality estimation values for each link associated with a parent > >> node? > >>>>> Otherwise the root will have a connectivity graph of the network > >>>>> (DAG) > >>>> but > >>>>> will have no way to figure out which path is cost-efficient to > >> select > >>>> (the root > >>>>> can come up with many combinations of paths to select from)? > >>>>> > >>>>> Thanks. > >>>>> > >>>>> -John > >>>>> > >>>>> On Mar 28, 2010, at 2:20 PM, Richard Kelsey wrote: > >>>>> > >>>>>> 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. > >>>>>> > >>>>>> 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. > >>>>>> > >>>>>> 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. > >>>>>> > >>>>>> 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. > >>>>>> > >>>>>> 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 > >>>>>> > >>>>>> What do people think? > >>>>>> -Richard Kelsey > >>>>>> _______________________________________________ > >>>>>> 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 > >>>> > >>> > >>> ------ > >>> 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 > > > > ------ > JeongGil Ko (John) > Ph.D. Student > Department of Computer Science > Johns Hopkins University > http://www.cs.jhu.edu/~jgko From d.sturek@att.net Mon Mar 29 15:01: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 9F6083A6B9A for ; Mon, 29 Mar 2010 15:01:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.582 X-Spam-Level: ** X-Spam-Status: No, score=2.582 tagged_above=-999 required=5 tests=[BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, 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 tcajZCESxu2U for ; Mon, 29 Mar 2010 15:01:24 -0700 (PDT) Received: from smtp104.sbc.mail.re3.yahoo.com (smtp104.sbc.mail.re3.yahoo.com [66.196.96.80]) by core3.amsl.com (Postfix) with SMTP id F2FC13A6B99 for ; Mon, 29 Mar 2010 15:01:17 -0700 (PDT) Received: (qmail 6068 invoked from network); 29 Mar 2010 22:01:44 -0000 Received: from Studio (d.sturek@64.163.235.68 with login) by smtp104.sbc.mail.re3.yahoo.com with SMTP; 29 Mar 2010 15:01:44 -0700 PDT X-Yahoo-SMTP: fvjol_aswBAraSJvMLe2r1XTzhBhbFxY8q8c3jo- X-YMail-OSG: Uws7PqQVM1myUfd152h6n3VOo89la4dG7TraAPUSrMnXZjacGleg1TukLvj8ltRBE26aVghi7kjeYmsueHj1Q5l2tNvCpl4t5pRgy4oHhnNYyxNxTBagd6v9PjK7RWEg4rO.6p9r_Z6ooY22Z04NPWfR_sIakTc5SrtgsjKPjIvABy1RtNRhEKWv0cA5twe580bx0u6DWZaqr4HuI5U_J1FYVTDp7_PmV0Q7DwYjy4.IJcW_WvDiT8XkwrY56pTjWqP_6HiP4K.6Fe5nxNop2zesC2OxTQ9dJ7exSRjq4rzbgNeCQKe3Yj9PmHppLyVbR6vqhsNWUfRT9ESfZEs3G9ChsvhWwwfTWSVNTKN4ZuZcc92vlgbrsRemw6XADE6zmB9wJa2xsESfc5fziMXyCJXPd7SiigGTqqKCjlCvNLOK X-Yahoo-Newman-Property: ymail-3 From: "Don Sturek" To: References: <1130942942.736211269838649762.JavaMail.root@mail02.pantherlink.uwm.edu> <9317.1269879175@marajade.sandelman.ca> <01b901cacf62$7f3e89b0$7dbb9d10$@sturek@att.net> In-Reply-To: Date: Mon, 29 Mar 2010 15:01:40 -0700 Message-ID: <00f501cacf8b$69fccf20$3df66d60$@sturek@att.net> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00F6_01CACF50.BD9DF720" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcrPc58LXgWrj4QURByqNcO/YXEiPQAFp8Qw Content-Language: en-us Cc: roll-bounces@ietf.org, 'roll' Subject: Re: [Roll] Mixed mode 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: Mon, 29 Mar 2010 22:01:24 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_00F6_01CACF50.BD9DF720 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Jerry, I think the table sizes need to be configured to meet the worst case placement of the device in the network. If you make the tables too small for wherever the device may be deployed in an operational environment then I don't see how the specification or protocol is going to make up for that. Don From: Jerald.P.Martocci@jci.com [mailto:Jerald.P.Martocci@jci.com] Sent: Monday, March 29, 2010 12:11 PM To: d.sturek@att.net Cc: 'Michael Richardson'; 'roll'; roll-bounces@ietf.org Subject: Re: [Roll] Mixed mode operation Hi Don, Don't you think it's scary for a node to just down-shift to being a leaf node if it's out of resources? In our implementations, nodes closest to the LBR tend to have the most traffic. The traffic level diminishes as the node is placed farther from the LBR. Since we can't control node placement in a jobsite, it's likely that all the LBR neighbors will run our of memory first. If they drop down to 'leafs', that renders the whole DAG beneath them unusable. That would not be a good thing! somehow, we need to manage the routing table resource. Jerry From: "Don Sturek" To: "'Michael Richardson'" , "'roll'" Date: 03/29/2010 12:09 PM Subject: Re: [Roll] Mixed mode operation _____ Storing devices that are out of resources to store either need to become non-storing (if that is legal in the DAG they are a member) or must become leaf devices. I don't see any other alternative. Internally, they can do some table management/freeing of resources but I would not expect to see that in the specification. Don -----Original Message----- From: roll-bounces@ietf.org [ mailto:roll-bounces@ietf.org] On Behalf Of Michael Richardson Sent: Monday, March 29, 2010 9:13 AM To: roll Subject: Re: [Roll] Mixed mode operation >>>>> "Jonathan" == Jonathan Hui writes: Jonathan> Not supporting mixed-mode operation would be on-par with Jonathan> the industry today (which, for me, is a major goal). The Jonathan> point is that the LLN solutions that are shipping today Jonathan> assume either fully non-storing or fully storing. Any Jonathan> issues around that are being addressed without having to Jonathan> resort to mixed mode operation. What do deployed storing solutions do when the node runs out of space? -- ] 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.youtube.com/watch?v=kzx1ycLXQSE> then sign the petition. _______________________________________________ Roll mailing 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_00F6_01CACF50.BD9DF720 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable ------=_NextPart_000_00F6_01CACF50.BD9DF720-- From jeonggil.ko@gmail.com Mon Mar 29 15:04: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 7E8413A6B9E for ; Mon, 29 Mar 2010 15:04:01 -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 y90GRV2eTC+W for ; Mon, 29 Mar 2010 15:04:00 -0700 (PDT) Received: from qw-out-2122.google.com (qw-out-2122.google.com [74.125.92.25]) by core3.amsl.com (Postfix) with ESMTP id 371913A6B9B for ; Mon, 29 Mar 2010 15:03:57 -0700 (PDT) Received: by qw-out-2122.google.com with SMTP id 9so424618qwb.31 for ; Mon, 29 Mar 2010 15:04:22 -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=WbaJseigH4zv5eiNsm85ZYlfr4oF0ZSd5OnnySC4KsU=; b=PflXJpIpNaje+t8t58mjxcMl1ahJ8Xd/v0ck0/aeSs0fXnHQa4s2JWVt2LstAAeVR1 zNn5UabhB6BOAEqCTVQttCLLRhgljiNefjfRwkKmh2WOOSuNE1gRSGftO+uQPj/muBuu kCcMW9PMTC1bgLuy/rJkRxq/2qVaoKdD9pBbA= 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=gOApnicAxJ1t03fndRDagtiTsNZ2P67uJmQOdSMjxByVH8yXmMNzOjD2iXm9VQ76Le wCVdEGHizAOWRsPqG5tewbQzHpgiUx/M0dUVUQBbvUgQfR9DdWrTWRDknLUEGPzhsV0M QRuMhDTFMyUi7lNx9q58gO6M4SFXZq1g4PbIk= Received: by 10.224.45.1 with SMTP id c1mr2198359qaf.87.1269900262278; Mon, 29 Mar 2010 15:04:22 -0700 (PDT) Received: from dnab404649.stanford.edu (DNab404649.Stanford.EDU [171.64.70.73]) by mx.google.com with ESMTPS id 7sm12334890qwf.44.2010.03.29.15.04.10 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 29 Mar 2010 15:04:11 -0700 (PDT) Sender: "JeongGil (John) Ko" Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: "JeongGil Ko (John)" In-Reply-To: <007201cacf8b$00817b90$018472b0$@alexander@ekasystems.com> Date: Mon, 29 Mar 2010 15:04:08 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <207C6B80-B20B-4553-B04C-CC88841E1002@cs.jhu.edu> 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> To: Roger Alexander X-Mailer: Apple Mail (2.1077) 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, 29 Mar 2010 22:04:01 -0000 Roger, On Mar 29, 2010, at 2:58 PM, Roger Alexander wrote: > Hi John, >=20 >> -----Original Message----- >> From: JeongGil (John) Ko [mailto:jeonggil.ko@gmail.com] On Behalf Of >> JeongGil Ko (John) >> Sent: Monday, March 29, 2010 5:48 PM >> To: Roger Alexander >> Cc: 'Pascal Thubert (pthubert)'; roll@ietf.org >> Subject: Re: [Roll] proposal for DAOs in non-caching DODAGs >>=20 >> Hey Roger, >>=20 >>=20 >> Maybe a stupid question but I keep making this point without getting = an >> answer. I agree that if we have a DAO parent set and if this is >> reported to the root then the need for DAO ranks go away. However, = how >> would a node know its DAO parents without using DAO ranks? I am (once >> again) not in favor of DAOs but I just want to know how we can = achieve >> this. >>=20 >=20 > The selection of DAO Parents is based on the Rank that the candidate = nodes > advertise in their DIO. As for sending the DAO Parent set to the root, = that > is only applicable for non-storing nodes. For storing nodes the DAO(s) = is > sent to each of the set of DAO Parents.=20 >=20 Better understood. Then the selection of the DODAG preferred parent set = and DAO parent set MAY be identical. Correct? Since both decisions are = made using the DODAG rank values. Now it makes more sense :) I = understand that all this is unneeded when storing mode is used in the = network.=20 Thanks for the clarification! -John >> Thanks. >>=20 >> -John >>=20 >>>=20 >>>> The current spec enables the OF in a node to compute a DAO Rank >> based >>>> on >>>> the metrics option pretty much like a DIO Rank would be computed >> using >>>> a >>>> DAO DAG Metric Container. This was introduced at some point along >> the >>>> path and provides an additional capability to rate non preferred >> paths. >>>> I figure that you're willing to emulate that in the source route = DAO >>>>=20 >>>> My take is that we have already added too much complexity even >> though >>>> we >>>> made it optional. I'd rather remove the DAO DAG Metric Container. >> But >>>> in >>>> any fashion I have to agree with your desire to make things >> consistent. >>>> Then again, slippery slope towards link state... >>>>=20 >>>> Pascal >>>>=20 >>>>=20 >>>>> -----Original Message----- >>>>> From: JeongGil (John) Ko [mailto:jeonggil.ko@gmail.com] On Behalf >> Of >>>>> JeongGil Ko (John) >>>>> Sent: Monday, March 29, 2010 8:04 AM >>>>> To: Pascal Thubert (pthubert) >>>>> Cc: Richard Kelsey; roll@ietf.org >>>>> Subject: Re: [Roll] proposal for DAOs in non-caching DODAGs >>>>>=20 >>>>> Hi Pascal, >>>>>=20 >>>>> I see your point. One question, that confuses me is how the set of >>>> 'preferred >>>>> DAO parents' are determined. Is this set different from the >> preferred >>>> parent >>>>> set in DIOs? I guess another way of asking is to ask is how the >>>> DAORank is >>>>> defined and computed (this question was asked previously but I >> didn't >>>> really >>>>> get a clear answer). Will each node that initiates a DAO for a >>>> specific prefix be >>>>> DAORank =3D 1 and the rank computation continue just like the DIO >>>> process? In >>>>> this case is it true that each node may need to maintain different >>>> DAORank >>>>> values for many different prefixes? >>>>>=20 >>>>> Thanks! >>>>>=20 >>>>> -John >>>>>=20 >>>>> On Mar 28, 2010, at 10:44 PM, Pascal Thubert (pthubert) wrote: >>>>>=20 >>>>>> Hi John: >>>>>>=20 >>>>>> Obviously, having multiple parents enables the root to compute >>>>>> multiple paths down to the node. So your proposal is tempting. = But >>>>>> beware, this is a slippery slope towards centralized Link State >>>>>> computation and away from the RPL core design, and we can't be >>>>>> designing 2 protocols, by charter. >>>>>>=20 >>>>>> The RPL design is that the choice of the best parents belongs to >>>> the >>>>>> OF in the node, not the root. Richard's proposal centralizes in >> the >>>>>> root the forwarding decision along the DAG that happens hop by = hop >>>>>> with stateful DAOs, but the routing states are built in the = exact >>>>>> same fashion whether it is stateful or stateless, by having each >>>> node >>>>>> select a set of preferred DAO parents. Note that we do not = specify >>>> how >>>>>> a node selects the next hop between multiple DAO children in the >>>> stateful >>>>> mode. >>>>>> In the same fashion, we do not specify how the root makes the >> multi >>>>>> hop decision. >>>>>>=20 >>>>>> My suggestion to address your problem would be that the OF in the >>>> node >>>>>> provides more info on how it orders the parents, maybe by setting >> a >>>>>> preference level (like 0-3) for each parent in the source route >>>> DAO. >>>>>> The root retains the possibility to build multiple = non-overlapping >>>>>> path, do load balancing, signal to L2 when L2 paths/circuits need >>>> to >>>>>> be enabled, etc... We have not made the step towards a = centralized >>>>> routing model. >>>>>>=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: Sunday, March 28, 2010 11:42 PM >>>>>>> To: Richard Kelsey >>>>>>> Cc: roll@ietf.org >>>>>>> Subject: Re: [Roll] proposal for DAOs in non-caching DODAGs >>>>>>>=20 >>>>>>> Richard, >>>>>>>=20 >>>>>>> I agree that if we start adding downwards routes then the root >>>> will >>>>>> have >>>>>>> many sub-route (or sub-path) information that it already has. If >>>> we >>>>>> decide >>>>>>> the add the neighbor (parent) information in the DAOs do we also >>>> add >>>>>> link >>>>>>> quality estimation values for each link associated with a parent >>>> node? >>>>>>> Otherwise the root will have a connectivity graph of the network >>>>>>> (DAG) >>>>>> but >>>>>>> will have no way to figure out which path is cost-efficient to >>>> select >>>>>> (the root >>>>>>> can come up with many combinations of paths to select from)? >>>>>>>=20 >>>>>>> Thanks. >>>>>>>=20 >>>>>>> -John >>>>>>>=20 >>>>>>> On Mar 28, 2010, at 2:20 PM, Richard Kelsey wrote: >>>>>>>=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 >>>>>>>>=20 >>>>>>>=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 >>>>> ------ >>>>> 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 >> ------ >> JeongGil Ko (John) >> Ph.D. Student >> Department of Computer Science >> Johns Hopkins University >> http://www.cs.jhu.edu/~jgko >=20 ------ JeongGil Ko (John) Ph.D. Student Department of Computer Science Johns Hopkins University http://www.cs.jhu.edu/~jgko From roger.alexander@ekasystems.com Mon Mar 29 15:05: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 598A73A68A6 for ; Mon, 29 Mar 2010 15:05:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.581 X-Spam-Level: ** X-Spam-Status: No, score=2.581 tagged_above=-999 required=5 tests=[BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, 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 tJrWQ4QuKy0c for ; Mon, 29 Mar 2010 15:05:10 -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 80FF03A68FE for ; Mon, 29 Mar 2010 15:05:10 -0700 (PDT) Received: (qmail 8916 invoked from network); 29 Mar 2010 22:05:36 -0000 Received: from dallas (roger.alexander@209.48.242.70 with login) by smtp113.biz.mail.re2.yahoo.com with SMTP; 29 Mar 2010 15:05:36 -0700 PDT X-Yahoo-SMTP: 1dQRPo6swBBzwSsRzMLy_tvdRrLDyF0J X-YMail-OSG: jQ7zIhQVM1lvlq0TdyiEUBM42eAC3GJnLzk3x1TTuGibWc5RVnqIVw6rCZxwU.RvZXaMg8I2XhEwdUhJRTw27kQv7aMXyM2DCINsjamAmPduLgi94O_I8lceWx6xIYf2rHfZrSSHAfFbAUN1IeWCKxlwxcLjGOEMuBILzr1Jw2pJ7Yiwd6moksIjRh2LuIOxPVHgrfWapRz.3PrquP90vls2IUdThS1MU0uR6TwM286m3GtrUDaKxzy5MLmPlW0g72rpbcVv2podcZub0FSrfX0GOmjD4hfdJvi2iAtdbZPPhbyhgRjJ0E6WuuMEAuIUndOWuGQS8gAUd8KXzbQbPQWamf9D2JWPEoyT47erijnOPkKDk.0ufnNzRVcviaAQ X-Yahoo-Newman-Property: ymail-3 From: "Roger Alexander" To: "'Richard Kelsey'" , "'Mukul Goyal'" References: <1130942942.736211269838649762.JavaMail.root@mail02.pantherlink.uwm.edu> <87fx3jmkm2.fsf@kelsey-ws.hq.ember.com> In-Reply-To: <87fx3jmkm2.fsf@kelsey-ws.hq.ember.com> Date: Mon, 29 Mar 2010 18:04:27 -0400 Message-ID: <007301cacf8b$cd0d5fd0$67281f70$@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: AcrPM78bZhdSEXH6SsawMzFF6kF7JwASNmnQ Content-Language: en-us 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: Mon, 29 Mar 2010 22:05:13 -0000 Hi Richard, Mukul, > -----Original Message----- > From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of > Richard Kelsey > Sent: Monday, March 29, 2010 7:30 AM > To: Mukul Goyal > Cc: roll@ietf.org > Subject: Re: [Roll] Mixed mode operation > > > Date: Sun, 28 Mar 2010 23:57:29 -0500 (CDT) > > From: Mukul Goyal > > > > I was wondering if there was ever a discussion on the mailing list or > > else where regarding why is it difficult to support mixed mode > > operation. We know from the WG meeting at Anaheim that mixed mode > > operation is difficult to support but it is not clear why. > > Speaking for myself, supporting mixed mode is both complex > and can use up a lot of bandwidth. Numerous people have > commented that RPL is too complicated, and much of the > complexity comes from attempting to handle mixed-mode DODAGs > efficiently. > > A key issue is the response to a change in parents. With > caching, a node with a new parent sends a (potentially) > large amount of data, its cache, one hop to the new parent. > The parent in turn only forwards up those DAOs that are new > to it. Without caching the node can send a small amount of > data, its new parent, a (potentially) long distance. In a > mixed network you get the worst of both. Because there may > be a cache, the entire sub-DAGs worth of DAOs must be sent > to the new parent, and non-caching nodes have to elicit and > forward all of these DAOs, whether or not they are > redundant. > I do concur here. Though with caching-only nodes there is an opportunity, in conjunction with acknowledged exchanges, to introduce further scalability optimizations that can include performing just incremental updates when refreshing DAO sub-DAG destination addresses. This does require some additional enhancement to the current DAO specification but can be introduced as part of a caching-only mode operation. > > Not supporting mixed mode operation is a major climb down for > > RPL. > > In what way? It would definitely be nice to have, but there > is no requirement for it. At least at Anaheim, there was a > sense that no mixed-mode style of networks exist today. > > > This means that the introduction of even a single non-storing > > router can turn a hitherto storing LLN into a non-storing one thereby > > causing a major upheaval in the network as all the DAOs now have to > > reach the root. > > My understanding is that a non-storing router can only join > a storing DODAG as a host, the same as a router that does > not understand the metric in use in the DODAG. There is no > mechanism for changing a storing DODAG into a non-storing one. > > -Richard Kelsey > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From mcr@sandelman.ca Mon Mar 29 15:09: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 42A243A68FE for ; Mon, 29 Mar 2010 15:09:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.114 X-Spam-Level: * X-Spam-Status: No, score=1.114 tagged_above=-999 required=5 tests=[AWL=0.079, BAYES_20=-0.74, 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 Fsztby6uAqXp for ; Mon, 29 Mar 2010 15:09:41 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by core3.amsl.com (Postfix) with ESMTP id ED4F83A687B for ; Mon, 29 Mar 2010 15:09:38 -0700 (PDT) Received: from sandelman.ottawa.on.ca (desk.marajade.sandelman.ca [209.87.252.247]) by relay.sandelman.ca (Postfix) with ESMTPS id 199B9346EA for ; Mon, 29 Mar 2010 18:07:32 -0400 (EDT) Received: from marajade.sandelman.ca (unknown [127.0.0.1]) by sandelman.ottawa.on.ca (Postfix) with ESMTP id E0CFB4E7ED for ; Mon, 29 Mar 2010 18:10:05 -0400 (EDT) From: Michael Richardson To: 'roll' In-Reply-To: <642963F2-F363-495D-97B1-04412446EFEA@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> <642963F2-F363-495D-97B1-04412446EFEA@cs.stanford.edu> X-Mailer: MH-E 8.1; nmh 1.1; XEmacs 21.4 (patch 21) Date: Mon, 29 Mar 2010 18:10:05 -0400 Message-ID: <2916.1269900605@marajade.sandelman.ca> Sender: mcr@sandelman.ca 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: Mon, 29 Mar 2010 22:09:42 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >>>>> "Philip" == Philip Levis writes: Don> Storing devices that are out of resources to store either need Don> to become non-storing (if that is legal in the DAG they are a Don> member) or must become leaf devices. I don't see any other Don> alternative. >> I wasn't asking about RPL. I was asking about current >> (proprietary) deployed solutions. >> >> There is a belief that the mixed mode has never been deployed in >> any proprietary solution. Given that, in networks with storing >> nodes, when the node gets full, what happens? Philip> Jonathan mentioned this in his presentation at Anaheim: you Philip> provision/design your network so this doesn't happen. Okay, but that's not an answer. Do you provision it so that every node can hold enough routes for any topology, or just for the topology that you care about? If, when I've provisioned the network, I'm WRONG and for some reason there are additional nodes, what does this mean? What policy is used to select which ones fit? Answers to the above question is important from a security design point of view: if an attacker can cause the topology to change through creative use of active (or even passive) repeaters, then it could overwhelm an "interior" node's capacity. What happens then? - -- ] 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 iQEVAwUBS7ElPICLcPvd0N1lAQIVNwf/Q94Bhgr6W8aniWHYrvxbubmAhvZOAjax bOfZGu49dyeieLxpWka+jJDeFNoWpXgdMCdVPmXQy+sj3dPsvzpUJN/KSAvHaOB/ HYzSS7uTy4IqGDJskhpRKf+pM87Kjxcrk6qxA/7sz75Jq6X9IT6+8RWIoyogfi8L ij8nusgwcFkudRpMNASv+mvnzFZN5k4URSbFvGiHB23yQhbOer9INW+K0sVRD7uC k5mF0RUwB6HEwGgSvehEE2d06MyUWCxXHrxMRg8ZI/J75hp6KzbXkoWLtTxRQ5cA F9gRlQDm1LQAHmnQ4Xulua14vPzsagezXs5S0DXGHmACmvymhxIXDw== =whIM -----END PGP SIGNATURE----- From d.sturek@att.net Mon Mar 29 15:10: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 42C5A3A69B7 for ; Mon, 29 Mar 2010 15:10:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.58 X-Spam-Level: ** X-Spam-Status: No, score=2.58 tagged_above=-999 required=5 tests=[BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, MSGID_MULTIPLE_AT=1.449] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XuJg8sVxyOEL for ; Mon, 29 Mar 2010 15:10:55 -0700 (PDT) Received: from smtp105.sbc.mail.ac4.yahoo.com (smtp105.sbc.mail.ac4.yahoo.com [76.13.13.244]) by core3.amsl.com (Postfix) with SMTP id 900943A68FE for ; Mon, 29 Mar 2010 15:10:55 -0700 (PDT) Received: (qmail 97791 invoked from network); 29 Mar 2010 22:11:20 -0000 Received: from (d.sturek@64.163.235.68 with login) by smtp105.sbc.mail.ac4.yahoo.com with SMTP; 29 Mar 2010 15:11:20 -0700 PDT X-Yahoo-SMTP: fvjol_aswBAraSJvMLe2r1XTzhBhbFxY8q8c3jo- X-YMail-OSG: PMj2uCoVM1nj.6me1qgFukK8xu1UnORx1UFt.dLFSg9DL3sgd3V1VKDM3aJr3KdXHsmHPndYEIyqg9vAMwt_xwoQvRhNYkfWX_G1ALdI2yQCAaTtjUUHdXjKAGL1d2UdpZFXyPRh5Db7tr6FLFv7o29G4kDLn6ZkcZKncL_OFELEsqp1DJbwcnykq0vWUdxFLw_KqrkNz2ALU.Ehbu3eGiITtYWRg4czux29yVLTV6RttyCQBXh29AXHZW01rrAIRPyLCVyYgyrzv8RpxWPfp14LCEKqI_4KTh.j5ITm2ZgnkL979w-- X-Yahoo-Newman-Property: ymail-3 From: "Don Sturek" 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> In-Reply-To: <20100.1269887835@marajade.sandelman.ca> Date: Mon, 29 Mar 2010 15:11:14 -0700 Message-ID: <00fa01cacf8c$c0f4cc00$42de6400$@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: AcrPbuR5aQvPUUZHQcWFLFcH1QDR/wAHPMRA Content-Language: en-us Cc: 'roll' Subject: Re: [Roll] Mixed mode 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: Mon, 29 Mar 2010 22:10:57 -0000 For the solutions that I am familiar with (which use a variation of AODV), we only have recommended practices on retiring or removing route table entries. Many of these implementations do some route table management when the routing table is full. However, these actions (in the proprietary solutions I am familiar with) come at a cost of flooding the network when the removed route table entry is re-established. If you make your route table entries too small to support the size of network you are deploying then I don't see route table maintenance itself solving the problem. Don -----Original Message----- From: mcr@sandelman.ca [mailto:mcr@sandelman.ca] Sent: Monday, March 29, 2010 11:37 AM To: d.sturek@att.net Cc: 'roll' Subject: Re: [Roll] Mixed mode operation >>>>> "Don" == Don Sturek writes: Don> Storing devices that are out of resources to store either need Don> to become non-storing (if that is legal in the DAG they are a Don> member) or must become Don> leaf devices. I don't see any other alternative. I wasn't asking about RPL. I was asking about current (proprietary) deployed solutions. There is a belief that the mixed mode has never been deployed in any proprietary solution. Given that, in networks with storing nodes, when the node gets full, what happens? -- ] 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 Emmanuel.Monnerie@landisgyr.com Mon Mar 29 15:19: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 9C5743A6951 for ; Mon, 29 Mar 2010 15:19:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.732 X-Spam-Level: * X-Spam-Status: No, score=1.732 tagged_above=-999 required=5 tests=[BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, HTML_MESSAGE=0.001, J_CHICKENPOX_63=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dzUlEIahlc+8 for ; Mon, 29 Mar 2010 15:19:42 -0700 (PDT) Received: from mta2.cellnet.com (cnsipm1.cellnet.com [148.80.254.17]) by core3.amsl.com (Postfix) with ESMTP id B50023A6827 for ; Mon, 29 Mar 2010 15:19:40 -0700 (PDT) X-ASG-Debug-ID: 1269901207-5289000b0002-BCmCR7 X-Barracuda-URL: http://172.25.128.17:8000/cgi-bin/mark.cgi Received: from livemail.cellnethunt.com (localhost [127.0.0.1]) by mta2.cellnet.com (Spam Firewall) with ESMTP id 1105F41F621 for ; Mon, 29 Mar 2010 18:20:08 -0400 (EDT) Received: from livemail.cellnethunt.com ([10.1.130.15]) by mta2.cellnet.com with ESMTP id UjaoXswcEBPdw7g9 for ; Mon, 29 Mar 2010 18:20:08 -0400 (EDT) X-ASG-Whitelist: Sender X-ASG-Whitelist: Client Received: from livemail.cellnethunt.com ([10.1.130.105]) by livemail.cellnethunt.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 29 Mar 2010 18:20:07 -0400 Received: from mail pickup service by livemail.cellnethunt.com with Microsoft SMTPSVC; Mon, 29 Mar 2010 18:20:07 -0400 Content-Transfer-Encoding: 7bit Importance: normal Priority: normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.4325 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CACF8D.FC5AC55D" X-ASG-Orig-Subj: RE: [Roll] Ticket # 25 - Tracking the MUST requirement Date: Mon, 29 Mar 2010 18:21:54 -0400 Message-ID: <76DBCE2AA6605F42A49F1BD7454C841BA2B4FA@usatlsv105.am.bm.net> In-Reply-To: <68182A3F-0D29-4F8A-9711-F71A8950DC21@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] Ticket # 25 - Tracking the MUST requirement Thread-Index: AcrPdnMpsg0ape/PTG2K6KD1s0ONkAAFW5AQ References: <68182A3F-0D29-4F8A-9711-F71A8950DC21@cisco.com> From: "Monnerie, Emmanuel" To: "JP Vasseur" X-OriginalArrivalTime: 29 Mar 2010 22:20:07.0415 (UTC) FILETIME=[FCEC1870:01CACF8D] X-Barracuda-Connect: UNKNOWN[10.1.130.15] X-Barracuda-Start-Time: 1269901208 X-Barracuda-Virus-Scanned: by Barracuda Spam Firewall at cellnet.com Cc: ROLL WG Subject: Re: [Roll] Ticket # 25 - Tracking the MUST requirement X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 29 Mar 2010 22:19:51 -0000 X-List-Received-Date: Mon, 29 Mar 2010 22:19:51 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CACF8D.FC5AC55D Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Jean-Pierre, Thanks for compiling this summary. This is very helpful. In the case of a satisfied requirement (Green), would it be possible to add a reference (chapter number) to the text in the draft standard that describe the corresponding RPL feature? This would help a lot. In the case of a deferred requirement (Grey), could you please provide additional information explaining how this choice was made? Is it a recommendation or a decision? Best Regards From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of JP Vasseur Sent: Monday, March 29, 2010 3:31 PM To: ROLL WG Subject: [Roll] Ticket # 25 - Tracking the MUST requirement Dear WG, I put together a spreadsheet to track the "MUST requirements" spelled out in our four requirements documents. To that end, I listed all MUST and used the following color code: GREEN: Satisfied requirement YELLOW: the requirement is partially satisfied and the WG thinks that the requirement is not sufficiently satisfied. For example: Support of Point-to-Point: "The routing protocol MUST provide routes between arbitrary hosts within the appropriate administrative domain". Strictly speaking RPL supports P2P but the WG thinks that more work is required, thus the Yellow color RED: the requirement is not satisfied (e.g. additional mechanisms required) or not yet done (e.g. security) PINK: the requirement is partially satisfied or non satisfied but the WG decided that this was acceptable. It may be wise to document it. GREY: Evaluation is differed (not a show stopper for LC). For example, it may take time to deploy a network with few dozens of thousands of nodes. Note that in this case, simulations may help. Let's continue to work on our opened tickets and update that spreadsheet accordingly. Note that in both the YELLOW and RED cases, RPL could not be last called until they turn GREEN. Comments very welcome of course. Thanks. JP. Emmanuel Monnerie Senior Research Engineer Landis+Gyr Energy Management Solutions Office: +1 678 258 1695 Fax: +1 678 258 1316 Emmanuel.Monnerie@landisgyr.com www.landisgyr.com manage energy better ------_=_NextPart_001_01CACF8D.FC5AC55D Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Jean-Pierre,

 

Thanks for compiling this summary. This is very = helpful.

 

In the case of a satisfied requirement (Green), would it = be possible to add a reference (chapter number) to the text in the draft = standard that describe the corresponding RPL feature? This would help a = lot.

 

In the case of a deferred requirement (Grey), could you = please provide additional information explaining how this choice was made? Is it a recommendation or a decision?

 

Best Regards

 

 



Emmanuel Monnerie
Senior Research Engineer
Landis+Gyr
Energy Management = Solutions
Office: +1 678 258 1695
Fax: +1 678 258 = 1316        
Emmanuel.Monnerie@landisg= yr.com
www.landisgyr.com =
manage energy = better

From:= roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of = JP Vasseur
Sent: Monday, March 29, 2010 3:31 PM
To: ROLL WG
Subject: [Roll] Ticket # 25 - Tracking the MUST = requirement

 

Dear WG,

 

I put together a spreadsheet to track the = "MUST requirements" spelled out in our four requirements = documents.

 

To that end, I listed all MUST and used the = following color code:

 

GREEN: = Satisfied requirement

 

YELLOW: = the requirement is partially satisfied and the WG thinks that the = requirement is not sufficiently satisfied.

 

For example:

Support of Point-to-Point: "The routing protocol MUST provide routes = between arbitrary hosts within the = appropriate 

administrative domain". Strictly speaking RPL supports P2P but the WG = thinks that more work is required, thus the 

Yellow color

 

RED: the = requirement is not satisfied (e.g. additional mechanisms required) or not yet done = (e.g. security)

 

PINK: = the requirement is partially satisfied or non satisfied but the WG decided = that this was acceptable. It may 

be wise to document it.

 

GREY: = Evaluation is differed (not a show stopper for LC). For example, it may take time = to deploy a network with

few dozens of thousands of nodes. Note that in this = case, simulations may help.

 

Let's continue to work on our opened tickets and = update that spreadsheet accordingly.

 

Note that in both the YELLOW and RED cases, RPL = could not be last called until they turn GREEN.

 

Comments very welcome of course.

 

Thanks.

 

JP. 

 

------_=_NextPart_001_01CACF8D.FC5AC55D-- From jpv@cisco.com Mon Mar 29 15:21: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 6A7523A6984 for ; Mon, 29 Mar 2010 15:21:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.611 X-Spam-Level: X-Spam-Status: No, score=-6.611 tagged_above=-999 required=5 tests=[AWL=0.443, BAYES_40=-0.185, DNS_FROM_OPENWHOIS=1.13, 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 tRMwsw3ueHaj for ; Mon, 29 Mar 2010 15:21:10 -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 DC11A3A69A6 for ; Mon, 29 Mar 2010 15:21:06 -0700 (PDT) Authentication-Results: sj-iport-4.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: AhsFALXEsEurR7Hu/2dsb2JhbACBPplpcacJmH6FAQQ X-IronPort-AV: E=Sophos;i="4.51,330,1267401600"; d="pdf'?scan'208,217";a="107239701" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-4.cisco.com with ESMTP; 29 Mar 2010 22:21:34 +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 o2TMLTkJ023513; Mon, 29 Mar 2010 22:21:33 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); Tue, 30 Mar 2010 00:21:30 +0200 Received: from dhcp-144-254-20-202.cisco.com ([144.254.20.202]) by xfe-ams-102.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 30 Mar 2010 00:21:30 +0200 Message-Id: <38602B90-4346-455D-9405-39E529CB4CF3@cisco.com> From: JP Vasseur To: Thomas Heide Clausen In-Reply-To: Content-Type: multipart/alternative; boundary=Apple-Mail-96--463687275 Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 30 Mar 2010 00:21:28 +0200 References: <68182A3F-0D29-4F8A-9711-F71A8950DC21@cisco.com> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 29 Mar 2010 22:21:30.0145 (UTC) FILETIME=[2E3BB110:01CACF8E] X-TM-AS-Product-Ver: SMEX-8.0.0.1181-6.000.1038-17288.002 X-TM-AS-Result: No--28.088800-8.000000-31 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No Cc: ROLL WG Subject: Re: [Roll] Ticket # 25 - Tracking the MUST requirement X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 29 Mar 2010 22:21:11 -0000 --Apple-Mail-96--463687275 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Here you are: On Mar 30, 2010, at 12:14 AM, Thomas Heide Clausen wrote: > Any chance of getting that in a format that we can read without > spending several KUSD on special-purpose software? > > Thanks, > > Thomas > On Mar 29, 2010, at 21:31 PM, JP Vasseur wrote: > >> Dear WG, >> >> I put together a spreadsheet to track the "MUST requirements" >> spelled out in our four requirements documents. >> >> To that end, I listed all MUST and used the following color code: >> >> GREEN: Satisfied requirement >> >> YELLOW: the requirement is partially satisfied and the WG thinks >> that the requirement is not sufficiently satisfied. >> >> For example: >> Support of Point-to-Point: "The routing protocol MUST provide >> routes between arbitrary hosts within the appropriate >> administrative domain". Strictly speaking RPL supports P2P but the >> WG thinks that more work is required, thus the >> Yellow color >> >> RED: the requirement is not satisfied (e.g. additional mechanisms >> required) or not yet done (e.g. security) >> >> PINK: the requirement is partially satisfied or non satisfied but >> the WG decided that this was acceptable. It may >> be wise to document it. >> >> GREY: Evaluation is differed (not a show stopper for LC). For >> example, it may take time to deploy a network with >> few dozens of thousands of nodes. Note that in this case, >> simulations may help. >> >> Let's continue to work on our opened tickets and update that >> spreadsheet accordingly. >> >> Note that in both the YELLOW and RED cases, RPL could not be last >> called until they turn GREEN. >> >> Comments very welcome of course. >> >> Thanks. >> >> JP. >> >> >> _______________________________________________ >> Roll mailing list >> Roll@ietf.org >> https://www.ietf.org/mailman/listinfo/roll > --Apple-Mail-96--463687275 Content-Type: multipart/mixed; boundary=Apple-Mail-97--463687274 --Apple-Mail-97--463687274 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Here you are:

--Apple-Mail-97--463687274 Content-Disposition: inline; filename=RPL-MUST.pdf Content-Type: application/pdf; x-unix-mode=0644; name="RPL-MUST.pdf" Content-Transfer-Encoding: base64 JVBERi0xLjMKJcTl8uXrp/Og0MTGCjQgMCBvYmoKPDwgL0xlbmd0aCA1IDAgUiAvRmlsdGVyIC9G bGF0ZURlY29kZSA+PgpzdHJlYW0KeAHFWcty20YQvPMr5hayyoKxeOMY23FVUrHjh1I5xDksgSW5 MQjQC1Aq5uvTgwcJAqReliz5IFoiF7MzPd09o2/0kb6R75EbWLZn24JC17XiiHzHseKAjKK/KKeX r0tBSUl2/a9M8BnbcvB+fDU/3P9PRCSi5qxJsqZXl+RH9VvwTbjCs3xyROxbUejT5ZpevhWWTYIu FzT99OF3evfn50v6pL5ttVmrvJrR5b/0y+XkYxdn6FthwHEGcchxel6IR4/itIQj/CAKEGYowsAL BV7ZYeS5wo0muIDvWR5uaceW51HsWK6H6Cw7sm2HD1vg7XEUOa7v8ivfiT3h8BEiDvgY2h/hxYHl Ob0jwjiOJ+0RUcBfIX8QDw4d3+eXOJXP650RudbZKLyYHzo5OsJv73SIIrQtNxpE0V3E31+kfYXD up8dTvBDyw3OnHBbNgMvslB4NxBcDGG7HIzwLRulcs+GgVz0wujO8IITZzQJ7d4i+m9xkZkaqHep WXuCE41OOHqCE44u0t3iplRwRbsneP0T6hiB2uOHiNFbuofcipv2KSIIOO9twj0fsO+gd8c4BRr/ cEIvl90T7NHvjy4R8q+5H9sYups2N2nIhYmEOw3tyl2LDhOOZftxHPJRD+cXavgF3cckhG++F5Bj +8Ci408G5PJZVrpcaJW2lAJCOUTHTYwge9EdUd/k3tR3JjQ0BnhvGNoHaSots2xH5Y1BgiVi7yjI J8ifiL3YCsb5e1/kdHMOQUGxcxQegwDlnTxMPk7mUETQDnecwy/TfRa/zChHsPtc0nxbUVLkpcrL bXmy/OC++Cjyp0hsBEo4Acw3erFQRqVUGHr/8udhfHSD4k0eqsyj1Dqha0GQReg6p4r/h9FLnQ9D 45aBoFqQ2XOdA9MwuZ9pGIUmPIjL+dDeqDIxelPpohfffezJgT6cMICZODxq6E8+V7IaA+hMgUYI QppuMQP3idpvsopvInAhtVBedMUw4rcKERvVA/39itE6uEOKRABDhQx5nsc4aZ4HMm8d3KtTEGFX EB6o32vN4WNQ/yELPgLqBdZQLAxdE9jfNL1cKTLFttL5kjamqIqkyGq3OQPqaUqV/KpI51VBMkmK bV5Rqq50oihZSSOTShldVhpCUG6TFcmSNsW1MuCWdKmq2eQfuvwNRnWvKmdQ0TLi9xnqcTncyGFq uVs5YLB+WDnawMbl+JwpteFaNFku+6WYK5LzTBFqYVSi9BUXZo6apJTKSj53sh2oxe3JFs1g4sKr Itu+bVtsTuInBb/rwHh32tgH/ztVlnKpAF7MVJzXuayA6F0DYmhPXqT4LQ9fbTugBvPtYjbh3mjk SSL9RlUGFormO6rQT5ksK1oVm7qx0AwLSJikGR2a4WGUxs0cxfA6SHMv1/sbTTfoxgKKuSBZUaY4 DMfG5aDyaUnXK5XX8eFO6Hd4KtgBviHpkpKtMUgCzJbOSVdICSORkl2SqdmknjafqYkFtPfOuOIJ 5ofhSsTRaVzdRqog2iuNvDPxAl9zVV0r1Eaaua6MBP5WRYkSXOtqhWowpOQGn9kYLStF/Ua/E5Ba 73CsCj7EkUSb3AERTWW61jmI3QAkoJm0WMuxzznD5SOFr8cQjID3iXXM5XbQ89+3SCvPqWMuH4jM wwzYcRJZWo8C2/cipPVTK6s9+ii3m01hKpL5LkF3vqBtrpsXTCPrbQYpxc+tfonbTdQNfvd7N1Gj ZMd3sjEtlTvw78ct57arnu8eYU8kW9iHUbGf7Ntabp95WjNZJ0ySdfvRt63MdLVDTcCcMMxr/Z8C Z2YqqQmSbY9JWZKhD7XJ6RfnPpju38a3HAf91yZ62H5NiHsC4CENrQgXVhKoGyZAlyvIDetKpvOv Jcms4ABbL6dKAOgZKTsSdaveYrs6+GDd86PgE0X1gnWQbrTq62K9rluxLnlLy72+ZeuVSoADZMg4 QUWulGFPMJku2ZFdS9OipwET0MXVSEDkIPYWcl+mylpaLx7FCQBA2BrTUar7/VDqZS6zDtwz7N9o +qI2JbWLxzKAlUWv1XNzTcCTcjeineX1Fiy82Aux0GpsI1jKBtXUa+XH5xqsxx+m7kvMRWqx5cXV CmCBY2dA1Qyi1qB/lAWWbGuYdLYbWHdYgA4a6S6Xa7DTV7UrUaPHoBqvWeH1tn99nDCpDWcO2EKA Vxv6SV7z+Ne4QOY/WZaYm/Fb+MvRxxKZQ2JlqnFxbhLV+WSd6MZa3tsCn3Au2J7znzka1Aw6eQqy hqWvWy+HqSrM1+Hkfca0IPDJd0NopKM+tsT7xeYB278eB9VhGyvnA7Z5JGIdfRrT4mOvBU89SN8d 1gG9GTQp1hvYV0w2papYTkGgqcZkyhwKjLcsyiaWCBNVBQw069xUd8jAgg+D12PAwrOcOIzBDL2M 73E+TWo/XcNWAr8cOoi5npSKXPGKcV3g59iPXoDal2bLYW1ktSqfVUjd6CQ3nsEPrn6MH+9RrHjf ttTLJF48Pgg8nQdjZZRzXbsukAog00KpzjiG8Lo0OVDTNvFFJneYox+HDQMbWthmdtwAcs5Wq8Zw yaDmWLFhUSbbMYOz3cJwDQeJ7bkqX3ZOrYbWWu54LZbDEbQ8zn+9mE1Ye60+yJ/B0sNtnpLZ01DC X69Ch2m2v595GjDxbuZBYDrBRA18ULS8qC5yrMiw3TFQowv83RyExCTQWTVJS3i5/FEgBUVyUOI2 wwNITfvLlpIVlHVU5fUmLytkejGXmcwTBpdMTAH1knSFsBXcAa4yJKH/ASyNw24KZW5kc3RyZWFt CmVuZG9iago1IDAgb2JqCjIwNzgKZW5kb2JqCjIgMCBvYmoKPDwgL1R5cGUgL1BhZ2UgL1BhcmVu dCAzIDAgUiAvUmVzb3VyY2VzIDYgMCBSIC9Db250ZW50cyA0IDAgUiAvTWVkaWFCb3ggWzAgMCA4 NDIgNTk1XQo+PgplbmRvYmoKNiAwIG9iago8PCAvUHJvY1NldCBbIC9QREYgL1RleHQgXSAvQ29s b3JTcGFjZSA8PCAvQ3MxIDcgMCBSID4+IC9Gb250IDw8IC9GMy4wIDEwIDAgUgovRjEuMCA4IDAg UiAvRjIuMCA5IDAgUiA+PiA+PgplbmRvYmoKMTEgMCBvYmoKPDwgL0xlbmd0aCAxMiAwIFIgL04g MyAvQWx0ZXJuYXRlIC9EZXZpY2VSR0IgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4Kc3RyZWFtCngB hZRNSBRhGMf/s40EsQbRlwjF0MEkVCYLUgLT9StTtmXVTAlinX13nRxnp5ndLUUihOiYdYwuVkSH iE7hoUOnOkQEmXWJoKNFEAVeIrb/O5O7Y1S+MDO/eZ7/+3y9wwBVj1KOY0U0YMrOu8nemHZ6dEzb /BpVqEYUXCnDczoSiQGfqZXP9Wv1LRRpWWqUsdb7NnyrdpkQUDQqd2QDPix5PODjki/knTw1ZyQb E6k02SE3uEPJTvIt8tZsiMdDnBaeAVS1U5MzHJdxIjvILUUjK2M+IOt22rTJ76U97RlT1LDfyDc5 C9q48v1A2x5g04uKbcwDHtwDdtdVbPU1wM4RYPFQxfY96c9H2fXKyxxq9sMp0Rhr+lAqfa8DNt8A fl4vlX7cLpV+3mEO1vHUMgpu0deyMOUlENQb7Gb85Br9i4OefFULsMA5jmwB+q8ANz8C+x8C2x8D iWpgqBWRy2w3uPLiIucCdOacadfMTuS1Zl0/onXwaIXWZxtNDVrKsjTf5Wmu8IRbFOkmTFkFztlf 23iPCnt4kE/2F7kkvO7frMylU12cJZrY1qe06OomN5DvZ8yePnI9r/cZt2c4YOWAme8bCjhyyrbi PBepidTY4/GTZMZXVCcfk/OQPOcVB2VM334udSJBrqU9OZnrl5pd3Ns+MzHEM5KsWDMTnfHf/MYt JGXefdTcdSz/m2dtkWcYhQUBEzbvNjQk0YsYGuHARQ4ZekwqTFqlX9BqwsPkX5UWEuVdFhW9WOGe FX/PeRS4W8Y/hVgccw3lCJr+Tv+iL+sL+l3983xtob7imXPPmsara18ZV2aW1ci4QY0yvqwpiG+w 2g56LWRpneIV9OSV9Y3h6jL2fG3Zo8kc4mp8NdSlCGVqxDjjya5l90WyxTfh51vL9q/pUft89klN JdeyunhmKfp8NlwNa/+zq2DSsqvw5I2QLjxroe5VD6p9aovaCk09prarbWoX346qA+Udw5yViQus 22X1KfZgY5reyklXZovg38Ivhv+lXmEL1zQ0+Q9NuLmMaQnfEdw2cIeU/8NfswMN3gplbmRzdHJl YW0KZW5kb2JqCjEyIDAgb2JqCjc5MgplbmRvYmoKNyAwIG9iagpbIC9JQ0NCYXNlZCAxMSAwIFIg XQplbmRvYmoKMTQgMCBvYmoKPDwgL0xlbmd0aCAxNSAwIFIgL0ZpbHRlciAvRmxhdGVEZWNvZGUg Pj4Kc3RyZWFtCngBxVnbbttGEH3XVwz6YgmwGS7vfE3QoCnSIhcHfaj7sCJX0ja8KFxKivL1Pbu8 ymIR25ATB4Fkk5Rnds6ZOXP8hd7TF/I9cgPL9mybUei6VhyR7zhWHFAl6C8q6MUrxShRZJt/KsEz tuXgfnw1P+y/YxGxqPmsWZLTy1vyI3MLXpjLPMsnh8W+FYU+3eb04jWzbGJ0u6L5h3dv6Y9PH2/p g/iyk1UuinpBt//Sr7ez912cUWBF+KWMgjjUcXoI3DkL02IO84MoQJQhCwMvZHhnh5HnMjeaIf7A iyxE6oaO5RGzXctFdL6N5/RnrbrrDIfhDDcgbDxkbjBp60960ElQcxKeY04CLyxAZD6xOGaWa05i 9uK105/EpzZvZK3rw7xQh+HFLvm2bXkBObFluzHynyrQY8Pymxrixfc8HZZj+6EVOLpACMvtwvqb 5rcbQVW5q2Wxpm1V1mVSZqZmC2IhzWkpiC8zQXVJPEnKPC9TXuPbiq8WM33HSia03FWqVrQ8ElF6 LHguE55lR8L92+ajeZHSgv6h299RfHMEj4DbSTaea4fjYwbg+nzmSmQiMbnku6yWWwS+5fVGIfwD r1K8Il3Fc0GpULiP17IsrMXMYLKtDbjzMEw+hTrngAk9BpC21BkBBsc1jqpDjAsWex1o/Nhimjuz KdDQI7F8BhoWu7Fm9cywuj9kgObDPcAoYKOWewAjJVnQrlrygpQoVFlRIepDWX1WDagMZEjtttuy qmlXACiqpru5wZNBnMaTVPrp2oCOFKCJOl4CPWA7ixnaWei2bBijB4mtpMhSYGMvE3G3uCaDonGI PeRPQxQ1lav2OQ0yXhNHTdRuqZJKLnEs4E+PveFTF7NHUqLtO6e18mIbDSiyQ915zqu1Br+3OhtN Ql4c23wOG4EQe56MU0c9cYnA32Il17uqiR/8F1sU5YT6pk5lQbyr05t3C8wedI7LFMz20fTZCUl6 JM67ZHiaVkKpu4UOrlC5VAq8BgE2Ihfqp9I7YMEUvd9Ms9ses1uPBD3Bn4ndQeRM4+V7I6Fjr8Yz X8pM1kcN77t5Bc40Lb9ru0uugB2Uou0CNxk/ioouA/vYDvXcbQ74HPZ8qYAG9KWyUJqd6DmiwlSL ad6GAXjrW2SB2YUEcv0O/w1RM7EXmX6sxFNmTNBB1htcrYyWQVpbXmGS1KJSmCADj1v99SNniAfR MTFDpkGmJdIwQp4ZZD50x2RT+h7IRrrjFFIoSVHWN4VIwHheyex4g4LwDM0Kk6SZ8+hGa7kXxUWA 5lu2E0Aytod8D2jzkZAgBZFkoCQKI5qykqc3S57xItH6iidVqdBbaY+4BViDXIw8eaoCsaJAf4Va C0MIh47v67eO6zuxx56uGlngQtpjnjSSsdH0s0bTv+pIAwa8NPRu1cDQ0Rq99lD50S4V58qIoUH1 AQzK6OXwi0ZS2okjK+500TOD2sGuMamLHgFqaO29TBvtLZTpLZTKTlNjMkP+JBt0mAQNRkKrJgoD PAPCKrESVTeS1UXGrGcFPgPET058GLO/vC8//tJtCaPTn5lF80c2umGNASa/C4ngx0GCOe7TIFHz zwKauV2vdqh6UQIWgAfmTi0BDbVLNrqtXL0tDzfb8gBspOamKzpsJK6Nh89jltdTEen6DEKrPeB7 TQ7KGAGlu0SQWDWLIWS61BjNygNlEP5FcjQIQcBG/uaykLn8BoDzVJZ0VRZXVEssXivsBFAOSq9g Wmb/7OEZBWbJaayLAVLTs9PRZe7XL+zWdoyvZxJoNtTgd2cnz9ZlBWGSj5f2TqFpKN30Kgew6Tb9 u7mw1tY1AX16MJ3gT8s68VW3HFy5DLb8wPMphrEDkXIOLVEYXQYvYX0kVWt7AXDnDRH66Ou7hUV/ am4MP1KIPMl2mi+aF2bByUVeVsfFDCN7jo6J1iqyTL+OH7vEbuLBt3JDeAUj/PQ9UzMm4wmOHOJX n2gDdm2R6O92CinPXEjR657fS16j1R8pkythjQN8gKCcPc3P+z8XK2CxnrxNqQZOTJtYEAtWCH+x 8bFgSRhO3POxZo/TBJNrLnysCE7kNCUW8A9prpdsbOaiSIFtnHOH987ZupvrJVFbkq291TGl1/Iw tfSC0INlIM012q3emMVXnsNYMjvFuEwPar2dg3piaWkFF/rOIOF7GM1N8++DU1iyXr37BF/CgBwr 9zdxTT1w9MpyTaJOLCS54XsB9w4iuJHC7V6zrdB1y50y28u64tuNRW+0UO7MpgelMVmfCBslBZFx gs9ZXqIeFcEKSiFkpmozLstI/fN0rwch5oUZjAnfNjunHo1m0hwk+I0HxFe0AgXZD+PxMm0L7nJE J1wYCgMGpx2b76MMzoko1rJohl13NRWJ1LbEU8X+RexGL4bWO3cbfxupusGe1mb5wOzWoX6maefD P3+Spu4Y3DO2xsali9Od+9SMu6+xLoMXbd+3B3yO/xPmoluZ8dS7DOMZ2F1UmRBbPZtFtYfyx6Tg K2yNL5ApdluoL8gxbJDYEjTY1l0fwJwcp/OA6TH8NWhioZwNC+XTHWW9ULqQM32Fh78RvRMVJGGO FRlO3WB5/weP1MASCmVuZHN0cmVhbQplbmRvYmoKMTUgMCBvYmoKMTk0MAplbmRvYmoKMTMgMCBv YmoKPDwgL1R5cGUgL1BhZ2UgL1BhcmVudCAzIDAgUiAvUmVzb3VyY2VzIDE2IDAgUiAvQ29udGVu dHMgMTQgMCBSIC9NZWRpYUJveApbMCAwIDg0MiA1OTVdID4+CmVuZG9iagoxNiAwIG9iago8PCAv UHJvY1NldCBbIC9QREYgL1RleHQgXSAvQ29sb3JTcGFjZSA8PCAvQ3MxIDcgMCBSID4+IC9Gb250 IDw8IC9GMy4wIDEwIDAgUgovRjEuMCA4IDAgUiAvRjIuMCA5IDAgUiA+PiA+PgplbmRvYmoKMTgg MCBvYmoKPDwgL0xlbmd0aCAxOSAwIFIgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4Kc3RyZWFtCngB xVnbbttGEH3XV8yjDKQsl3c9Nk2LtkivUdCHpgVW1MpiQ5EKLzbcr++Z3eVFlJxKahzbQSQLIjmc OXPmzOEH+pU+UBiQHzlu4LqCYt93FgmFnucsIqoU/U4Fffl1LSitydW/dYpjXMfD9/FjPuz/EgmJ xJxrlu7o5ZLCRH8FL8IXgROSJxahk8QhLXf05bfCcUnQckPz3355TT++fbOk39SHNqt2qmhuaPk3 fbOc/drFGePIhOOMFjHHGQSxI7yjOPGZCKMkQpixiKMgFnjnxkngCz+Z4QaiIHEQauB6TkDC9R0f 4XmuPdcG3w6TxPND/+S74QR+PDqBj2tEM+Rs053f83DmqL+AG+ILHCxfIIn4J+bAEFXshSG/xTW9 RSBouEQcOT7yLA7PYi5zWUHIFCTwdEHwIiLkBwVxQ58LMtMF8fqCfG/Tj+QbmDAkQjfRyXdxeIDQ F6jCMUxmLt/BWTCxUYXmXvASBsFxVH4X1R80X24VVWXbZMUt7auyKdMy18i5IRHTnNKyuFOV+eNW kdw0qqIGB8n1OmuysqByQ5IKdU9rdZeliu6zZpsVVCscJ3PaZUXbqPrFzexPWv4AAPYZoDMBeE2j HNVFACJApG2UR+si0ANeQEGElg1QH9cJIjSGIxg1jJPrW/ix2ghU3Yk8i5hxbb4qHvrayPy2rJDZ HbW1WlNTIt0oBbKraFve8wdcRkV7mb5XTU0oAZepUM19Wb1/YWo60zVdKUrlXq5yxcW7oaEwF4Bs NgZZ6IhAoDcXvuf4HRv1tzLvAWZjQ7CyWNOmKncGO/kD4wn39VEMcbQZbq2D3gt9ljff/fz29Su6 mWl60911BqGerEbgRyEo1yDFdPBwE8iaThmC36tqU1Y7JDiradMWqW4EC/xGFTVHWiv0zrp2uPFn zwb7OBAXwB7lG2DvLezseRrYJ27MWJmk+QxKWmd1U2UrBnvdbgw1bbI0w4wD6rkwUtdDrtAQlGfF e9rILG8rVXObqMKUsZKbG90POJY/R32vbAXwhBnLhm8xdYAim/jJ7elWAM7rNt0CPrIhmeeASqWp s9LDWvG0rundXNV7lWb4wgPlErBKH97dMCGDrFtlQ96pZkC+FSCflVcjcQmvQiN8NoBFiSajSQUA MObVgU91FdJyt+cxZUgUTV1WjzDphEinlGBI+GIgdfruAEgMo4P0DmRk4tU411Qv13eywPAF7xRK rXmaA9IYFXoI6KCc58VJCF2EKWeE6jB/vxt00VnD52SiMHHEwfn7RH2UTsw0nCgcy+IQrZbBKUNO S/xbAx5beadoV96pNXh9NDdn54+cY2kSLA45emY0/KWpOTnSODX2/MeNcKH4s6kJutFmMjNNy0jn nSHMryu6iHxsQBggPaKG1edNKnO5yvKseRiw1Yn72VnXs5k8rpQApfSXBIhtpV4OF2IKtiLSg65b dBqyG6Yn9D1mR51eFNjhvOESe9jB+jUQ6DeBfRT9Rt+PVE3d7vdl1XSSsdZKnjCiciXrBpsNFlTT BfdbBU3Amth+MBb3l2R4ciORH5OwOZ6gdX5ftvmaZIqJaVm6ghKEimSVW+K/ahyQ+TZublvWDTRY Lw6fY0S64QioA/W9PY2a6ARqnmjzEFip+131vzjz3byG/GBTwa6GyO5ojbDo0ZOHK1IZcXUri+wf o8cwmySEzLBMFu1uhbJprVzUfOQBp2KFP9sXGc1N+AJBsAAYxlnvb25uEJwVGI+VusUCW2tJJbOC A8A+q/FUrU1gwv3L40mKV6Y9E6U5hZLp9nmBxdvWmI2s9/MIrvwJruA2LJ4GV7zQ/i9Y1ZrCsZ7W WBS1aJcpFM+uXEMGA0RwFlgSdxDDR+CBrEgrEBVXcQDWpwAUOygwZg6yPcUTj0beNvRSnpUVEI84 apWrtIHctwujlmh7WUmodgX6WqkcqzsEyCa7bSsjJbdYU7Zlzovjc5JWErOB9zG5NthY7MwtJkbW E0HLhjUZDmfMuW64eRg5xmSYWiTI9yDoLhsTJ/xHCMKx/3jdUGSZEy2CoZlGKkelLfygExLnPKfQ 6ugjiRONHZxhVk0UThiwfSlglCTB5ym8jeu48F+1IGysxKkZMvsyz1KsdyCEds90UU9GFu9CutMg 4plAFjT/Amf4QmYYTHDv5wfC/hIcwKfl3wu92qMKhGNf5NEKWI0p8LABJbBGJYtMpvWJyLwusIk2 CymM9QZ3XILlVmHRPDAvdkryJGV/o9OPJZzK169/6h3N3m2uyxz+MyavtjvgxphKaqVhVjRQe96u P5k/42rr/ZT7NO9ogvd/eYAs7eOdYV9/kpF6BIoAHnQ/UkeggGLqbM+Bj/HA5kRfPg0oDgLrpyII +ZVsJLy2tHrYd48JOmv6UEPalGNKrtiWyYfHED0w6BAaPBqvpeqLWvQxkvTFgqsx9TImJGlbFMt9 oh8Hjpo0+CQoOepQP9Fe3MkOPe67URmQdgiRzqaX1vrqyofSsL4BqRKR3O/BsKZF36sHNDkOu93C fx9Kct2042dViYjwANWk9/g20JX3stLuVjfDO+Fl2IdFF+tyvZZ2j0C0+8UiXps3LO8n93Azw0Wv 530NqfN5/zFQedhX+mcnoxY/1eF4jmkwxY9u7dPDJ8KUDeu4GGD9DiBM3nbwjkDVcekK2/n4m9j3 uAh7+ZCXco2VC/426NZ+zLMc5oLhisNG/xew666/CmVuZHN0cmVhbQplbmRvYmoKMTkgMCBvYmoK MjAyNwplbmRvYmoKMTcgMCBvYmoKPDwgL1R5cGUgL1BhZ2UgL1BhcmVudCAzIDAgUiAvUmVzb3Vy Y2VzIDIwIDAgUiAvQ29udGVudHMgMTggMCBSIC9NZWRpYUJveApbMCAwIDg0MiA1OTVdID4+CmVu ZG9iagoyMCAwIG9iago8PCAvUHJvY1NldCBbIC9QREYgL1RleHQgXSAvQ29sb3JTcGFjZSA8PCAv Q3MxIDcgMCBSID4+IC9Gb250IDw8IC9GMy4wIDEwIDAgUgovRjEuMCA4IDAgUiAvRjIuMCA5IDAg UiA+PiA+PgplbmRvYmoKMjIgMCBvYmoKPDwgL0xlbmd0aCAyMyAwIFIgL0ZpbHRlciAvRmxhdGVE ZWNvZGUgPj4Kc3RyZWFtCngB1VlJc9tGFr7jV7wjWSXD2JdjEk/KmXJm4liuOYxzgMCm2DY2o0HL 9K+f7zV2AR5ttF2RDiJFkOzX/W3v4SO9po/ke+QGpuVZlk2h65pxRL7jmHFAtaD/UEHPf1E2pYos /atSvMcyHVyPn/afwzM7IjtqP8tIc/r5kvxIX4I/tmt7pk+OHftmFPp0mdPzX23TIpsu97T5849X 9PvbN5f0p/h4lHUuimZLl+/pH5fG636dUWBG+FKbgjjkdXpYuLNYphkF/BNilZZru6Hj+/zQcX0n 9mwDBQReZGKpUWg6Dn+cbbmmyx/nmy5/3P5xtXqOfh/+2IFlokQ7diIzcLpanaHWn7vKUBefgO1h IR55IYryyLcs0wvI80wrjuPIeNIpUHcK7UH5Fk7b45U5VmCbtuMb+hTcfmX/pc2Lo6CmpOYgKJO5 bMQOO6LKY50KReWekoJevfrXhb5AifRYy+ZEVZnJ9EQ7sZcF3nAjm4Ms9CW4Vh/r1rBD2tCVoOQq 09+wpb/o8p84X70H90DUSi2+6Vg2tjuOPcbUspqd3G+Jv3kvatrXZY5FJQ3XwQWisOHxb39swQMs sRDNTVl/mBaxT1KZcZ0n0VCVpB9Eo6ZVqUZm2bS2ujw2gh5cYc+Z+WnZEcgzQ9JwXhucVFmjFnzh 9WHYcC70eXuISvQFKXNraD51qAPv78cnDeoH0n5JhQgcW6HCb+tUACNGKjhxJynfhAp2FMTr4Llk iOAkZXHdnrZGEp9zWhZ7eX2sgfWk2FGeFMk1Hh8VX6pZISgXSuG/Sl9R1WVTpmWmWvxVtfgEgaOt 8XQOeKanZbfd31sU2GD5Su4A/qRpANx2NZrYJIv5K5oeeymyHYj8STLfcUmTZBlKA53xhPkOXSjT pJFlwa9rzFVZUjQ/Fl5BuKq0b9fhZX9HeIVQ3FVtYni9fTYIZAuunShOQMyJinIHmWSxOiQKzxrg ThSUHCFcRSNxAjiVTqjbT2Ek8stlLb+0r50HXnHIVtZt8G18VUmNxcgKy+lX01NmJ1KpABMC+AEm 6E/r53foz1kMb6k/XmyNxzBa8TpAEBpMqO5oxbaOHXP9MR4WiFbsS1uxHThIHwvz2vyEw9acBXnf vPz321cvWHk65cD5arpCeWR1zEBHCA+cYCcV/JWfaH/rxGt/LFIm7AXtcY34nORVJi6gPr0f3CvR rRYQh3BX2/fD9TRxdYJW5gBADihgVT02IKBNXWaDSJoEt2Sfvtwi3NGGA4hUJIpdmzT69/U6+m6j 3m1nFnysqrKGop4nVbihi1g2hczguchInbRD/hpxzQEIi/ZoA4CPct5F61WL/UYQd2EBQ6a7E+JO aEbOd4I4J2uY/y3xwE7+LtIDIKzyLk8NDgtngaukWlRWNBHMEHmFFMYKmHyA2yZIoLI8wuB2n+BG cF5OeUpk+2fnkcHA9biJQVhYkhWV9JFAO6P2fP3dZd3i+hpVfmlf03K4g5EqoP7NMT0M3pwn0P62 sltURZlpckSYe1G+YeKOOHs8dUPHAXVnoJmCfFcnnb2LQvRVnHhTq/JG/wM8fYayVcNXQpG61HCh I2lJRAf5HpljJkV5f+CIC2MR/48si/7uPHnURmAAWdo29C6yOOg3R7J84zzqIDCsQuynLTfr6FA4 GnCv3EJrlglINow75kVCTX1UHBPGLAFNTbJaJDsATakylTpGcL+mT6kNElcCNsHhAy3M5JCegLQw gpx2O74UAXxbDpNL0VpqLnOm4GipCTTnFexrQitjM9Lq3uK7iieeCjykvkW+iOEVODTAyXj+651w 8h0zDO7QXrJ0wHjgwtDi8+/Y6ds2hjmr+XMGpyFpDvCYBU2dLb8KGI3FtsFnrW7dEMbdjhHy5LPM j/nDrXm1HXY9H6pl+cHYTU5VS3xuuLGqSqUkBg1tekAL07UsLF/jOINJgqh9LOapuhKQN4OpNsaS SSu4kkFa25ra/73AtFKgD1EKYxrhhCHZUN9GO6ESNXdnmuKrjUKaiaTOToTpBodBdeBugKVAzzRG ov/Qji0KMGzThEGFdxIGGB4Jw/rrYjZ2lhi1IEzs2utZZT2DAg0AG3a4M0tOtgAhA02r6XxQ1KXU Cd64QWJ2DVnyTDzxbM/GgGeyySOMcpEozh/6i7veQnVL03oLnDUSiQojr3ebvu5+2ofg3X/AD0VQ 6PWSO0PQ+kQJA7TvhqDI0uK0NDru+Pvd7FVkZuSZKqk/iOnokiUtF00tU2pOFQ5O93EJoiN6vQ+Y OzHDERHRavHgkZ0bHfnhTPYdWJigd7u9LCpJ07Le6ZYTiy9z5O6r9wL95icM0rvGEygS5rV5Qbks MFT+ghkSgkeRnoClnajQ5un+tZ0mFUnDUyYQiOtAuNy3w+O9TJ9m8sReatx/0rww+cCe0AmaZbS3 Lr6CuGANcavpAwsz7mUYqy04RDSItGa1YRY8bxeGrmSKuCS7xmioOeRTyE0G8tec83mOcxt5DFlg TqdEfk07PQbqjEq0b3WSNqKWGILjJlF/0OfwQszNLKj+bNcHEUNxZdVoMGHsNcXgYomlatQFiSY1 320fhSDjwXe/uoNaIIhHCkO2H13v5Xw01t0Qst17IOhMUyi/DVRLejOCXv5ye0w5gc3Ey3BzB3cb btp+o6ol35pAxEL6umF+y4afTieGnWf2mniObsM3Lcuh2T4PmEF+etRIEqQ1Hn8n9KtY4AlMP/db xcKTNMGbfvywBbc0Yc2FegNaTrmMxZTrIStckMG1Jp3J6gZM7o7iZm0Y8M3abiirm/BbanomLvCM Z5ijTXfu7zatmm3wtJB5U83xc9JV06Srbmf37bAKkm70N2xf/w8ilA5ECmVuZHN0cmVhbQplbmRv YmoKMjMgMCBvYmoKMjEzNQplbmRvYmoKMjEgMCBvYmoKPDwgL1R5cGUgL1BhZ2UgL1BhcmVudCAz IDAgUiAvUmVzb3VyY2VzIDI0IDAgUiAvQ29udGVudHMgMjIgMCBSIC9NZWRpYUJveApbMCAwIDg0 MiA1OTVdID4+CmVuZG9iagoyNCAwIG9iago8PCAvUHJvY1NldCBbIC9QREYgL1RleHQgXSAvQ29s b3JTcGFjZSA8PCAvQ3MxIDcgMCBSID4+IC9Gb250IDw8IC9GMy4wIDEwIDAgUgovRjEuMCA4IDAg UiAvRjIuMCA5IDAgUiA+PiA+PgplbmRvYmoKMjYgMCBvYmoKPDwgL0xlbmd0aCAyNyAwIFIgL0Zp bHRlciAvRmxhdGVEZWNvZGUgPj4Kc3RyZWFtCngBzVjLjttGELzrK/ooAbs0h28eYyOBHTiB4yjI IZvDLDmSJiY5Mh9rr78+1XyI1GOzki0DkbCQVhKH3dNV1dXzkX6jj+R75AaW7dm2oNB1rTgi33Gs OKBS0Z9U0ItXlaCkIrt9VgmusS0Hv8ej+3D3n4hIRN1asySnl0vyo/YneBGu8CyfHBH7VhT6tMzp xU/CsknQckXz9+/e0i9//L6k9+pjo8tcFfWClv/Qj8vZb0OcInasKKIgDjlK17Ut4RxFaUUBP0IE abvCDR3f57eO6zuxJ2aIP/AiC5F6tmN5AQnbtVyE5+BHbc4r/Fw4wg+iAO9CEQZeKHiJMPKwYETj Eq4TWZ4zLOH5WGGGXeMV/CjCLd2T78YFnCCy3F0MwZDQJITZMyGIGOEPEYQ+IudCdkF8TcGQDleV s0I4qJOIY2G5Q8GcXcFe9+VBcRhGwgsBA/Jil3zb5o11YhQgjiPeka/HEfU46qDm28Crx2E5th9a gePPWhy5Q1h/0fyHBWN6ToVJVQupBYkQ/8um3gBVOpG1Il1XKltRbUhSXTZVrdLugnoja9IVyaxU Mn0kWVUm0bgkpU+63hDWoNevbt++/ZXu1cogt8Xsb1r+DKC2+3AGNU6m5HtuvNvr46T4trhbrkpK ZEG1/KBoK0uEWhBncpuYYqXXTSlrbQoyZfepKRczTn4tC/2l/cpa0Bhuz/+zeEX2zGbon8X+PsVj MIGcDKYuwWfBFOyBqZWoQzAhqIvDAor4OYIJJHLOAFOLjY2cgGMCqZRkgb+n4cLq1lWDUlU8LqBD NL9hCHJxc/lZ501O0/KctdWD0O7lFMSQHtFvdie1U4qozzWYQFtTVfo+UwgCEcgsM+BGC58VFKQy TZmoquVI8UhNMSVQSlulAC5m2jdA6oLa9XkeQyr0LtEn9whS30efRGQ/oU9L7HVpmloXa9qWpjaJ ye7m1d1iKlaMEFC4fNCJGirQCtoOg4WpKcmULLNHUlUt7zNdbaBSrZqNWnUddfIcDy2y3+kDdZp3 cggUtO267wcAxhmy0rL3Yv4eYyAQl8iKfYSBIxdxHVkJoidk5f3J+gMNoCRqCFFnRkLTa1CVzKpv OVUHkVbSqWq2W4MOMKElc5dVSOO6danrxyvJiRc4aE79Jh/IyTxXsmogF2fV/4hs/23Xzm44Ryoo 0DuEB6+5sy6j13xlcg3lMwUoOEbdCWiVzM6S3Sc7nBva4z3R4Wadv3053mhil1wPhjuYOqaTTa5t VxdGdtzkPPh8OKZd/brI4Jje1FPpuYez6BsDK8+qyaAwicn7PaNC1Z9M+QFNjMWpaqUGcAaF2Liz qklol0xTzb1EZlcySFEgUNF+dw8laAyP799FRndzZa2tG8rktjbbu8V+BZ4QqCOA9nv/jb7HRTfA 1HPoew5Q4XuMBp4q8MJjjg0b7vXD2b7z+TrlPAbFXmBTj3CqTfX60/npQX82pqphiSA73NVUCcfA HlqmD6qsdQVr02S13maK3rx7CBgYEItKVda0NV3mRK9hG/r5oWPD6ETf7KOkH2t4TosHmvqxJTD7 iqtA5bgiIuYx8MRgc6oiU+KqAiYAbgGdg0lLqa4SgyKAjChOpepmy62Ev1fFgy5NwVM2aCIfpM7a azNdfKhursRYD66BhHDcEflTgGFsUQnPVewkcVPMW8mmjaJXmLuFRWhgPL9w6oNXmvbAScrIti71 PXwVzz8rnvDIfCqu1AF91+E5v5s5dwranV1AQfenL6gmi6gq24ktpXtYOZNj12G7S1bEXCHTQlc5 rUqTYwRNUIhSZvoLtiOXhVyrtjRsAEqTZf8Ppx0F8Xhy8yxjuOzeQBnM7HaMx3eijI2jnN1UOcXY ElNWTHMesTDTqyLtRp1n7Tew9qBxfCCZNoymlZI1mxwimKska1LuM19UaQ4GbwjfVNYusRL7SoCD FIdidOyTUjD04FLm29tmewMS9x/dsvdjkGGeaA8GcATQUmg8AmjlYB+xadNOGWiTJjNrHJFkxAhd q6uJQRDFPvUIOuzeLE+sSvJeZ2xawZ+huYx5DeRBXltZJxvUgq/bz6PZpjiq4dZy+SzSNvrzZ5Gn 5tEQWN+db44sOX1cxqd3I0v6E7PvxJJIiNNgYnE9ZAQ8VKXXBeQIGkYbVi/MGSbvzgd6rO2NI09T ZiTMlQ43PBHQ3jbvKD8/Qcm+5R1lyIlJuNlP/cFfK9pwJ8i5P5Pp05yA6V+B3b0eCmVuZHN0cmVh bQplbmRvYmoKMjcgMCBvYmoKMTY3MwplbmRvYmoKMjUgMCBvYmoKPDwgL1R5cGUgL1BhZ2UgL1Bh cmVudCAzIDAgUiAvUmVzb3VyY2VzIDI4IDAgUiAvQ29udGVudHMgMjYgMCBSIC9NZWRpYUJveApb MCAwIDg0MiA1OTVdID4+CmVuZG9iagoyOCAwIG9iago8PCAvUHJvY1NldCBbIC9QREYgL1RleHQg XSAvQ29sb3JTcGFjZSA8PCAvQ3MxIDcgMCBSID4+IC9Gb250IDw8IC9GMy4wIDEwIDAgUgovRjEu MCA4IDAgUiAvRjIuMCA5IDAgUiA+PiA+PgplbmRvYmoKMyAwIG9iago8PCAvVHlwZSAvUGFnZXMg L01lZGlhQm94IFswIDAgODQyIDU5NV0gL0NvdW50IDUgL0tpZHMgWyAyIDAgUiAxMyAwIFIgMTcg MCBSCjIxIDAgUiAyNSAwIFIgXSA+PgplbmRvYmoKMjkgMCBvYmoKPDwgL1R5cGUgL0NhdGFsb2cg L1BhZ2VzIDMgMCBSID4+CmVuZG9iagozMCAwIG9iago8PCAvTGVuZ3RoIDMxIDAgUiAvTGVuZ3Ro MSAzOTk0MCAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PgpzdHJlYW0KeAGEvAl8VNXZP37OuTN39pk7 M5l9MnNnzSSTzEzIOiGQiyHsCMqWgCkBEXAliUoF9SUuiASVaN21gLXuvq9hNait0VetG5W21qKt lfZFi0ta2qK1lUx+33MnuPR9P/9/Jvfec/ezPOv3ec4llBBiJn1EIMq5F6/oFm7QTMaRN/ly7vrL 5L9XvncNIfRuQnSvrO5ec/GfJx24ixBDFyHa29dctGH14+dXeQmxniTkynPWnrdi1Wi1mCKkfz7u r1+LA85y8y+xfyP242svvuyKjwSzgP0nsX/8onXnrtj/5L3thGy7HfvrL15xRbe4XnqEkJvM2Jcv WXHxeZr61CzsV2K/onvdpZdp+8Xl2Mc95M7u3vO6jzXe/mPsnyDE5sQxih//MxORDGMrk2XqEcYP qn8C0RCtWhKJjuiJgRiJCdcTYiFWYite9G9rCft24hg/6iQlaslF3MRDvMRH/CRAgqSUhP7tPkLC 6hGZREiUxEicJEiSlJEUKScVJE0qSRXJkCzJkWoygdSQWlJH6kkDaSR57S3o4TkkjCUo3I7nk7E/ YDmG5Xhh1tgp7YUkVrhg7KjAW/2f4wvB8+8kO/GeE7SavIgemEUeJlPIfHI7mU7eIk+hhRvoG+iB GJlKHiUJGiaMTCMeqiX3kHfJOaSXfEiOon6zye+pA89pI91oZX7sY6xnkxvHDuIqI2kl/0WeoRfR Bah7K5nBKmkab94+Noz+SI0dGjuCvR+SD2l8bDeZgdJH6L0ysoncij68gLw+dgr1jZOV5BF6Ff0Y fdNFtmlqNf1jF5KJZD/5NZ2N0lyyQXvEsJ9chLsepB46PPbB2J/ITzWUnIcnXUtuRI33kGGWEVq1 uzDOSTKJnElW4OyV5F3qpNWCMlY2dsbYPTj6CPkbS7NXBB3qkSYzyXJyM3kAvfEOOUY+pyZaR39I n8DvF/TP2iOo22xyOdkInvgheu8R8iQ5SKtpNfMwD3rLg7FbhHPbyUN4/15ymM6mHXSYviA8pM0V WsZKxlxjfxobw/i2o4Y7yQt4x0mawzV4gxAVLtOENJdpJ4xegxauIveTw+QXqMfv0e+fky9pBX5/ YP/BNo0tGXt07EPURQ8aaiRnkaVkHVlPvk9+hFF9kbxE/kq/YgZc+ZbmZe1G7Ymx29C3SXIG6j4P Vy/As7dhlPaQIfzeQSvtVEYrGumZ9Gy6hm6nd9Ih+i59l4kswnrYJ8Kg8IbwO029VjvWhCe5Qcth UMkSshYj8B/o7dvQ3kfJy+Q16qJJWoUWvYP7v2AT2VT8HmRvsd8Lm4XtmlPaGwpHC58WvhrrB39N Bd21ozcfRy/8hbpRh3J6Ab2U/g9qPsD2CVZBEmJCnTBFWCh0CDcKtwuvCj/X9Gqe0LynnaldoX1C t6JwSeEXY7PHrkdfUHB1CJRUCU5pAP2sBjVdiPp149dLriLXkH5yC+jlNrKLPIF2P09eI78m75PP MAKERlDn8/H2i0F1m+kt+N1Dn6Qv0Jfpa/QP9Av+Y1H8UqyetbBWNo2tYZvxu50dZu+w40JQOFfY JPTht0M4ILyrIRqNZkw7Ab8Z2m3aR8Q3dCndDN1K/ZunRkYrRjtGf18gBX9hWeHOwguFP40tHtuA +idUjr+KbEEt7wENPoTf46DEA+QVyNzfqHX9G2VUC4r30hiooRKj1kKn05n4zaVn4bcIvyV0KX4r 6Eq6Fr9NtI9eS6+j19Ob6R3q72607SH6GD2A39P0Gfx+TT+gH9FP6N8YiJgJoOYEK2NZlkdLW9l0 No+djd8atg6/btbL1mOEHmF72UH2juAUEkKVsELoEe4R/kt4UXhb+KeGaSo1WU2zZrFmjeY6zVua X2iOaL7ShrVt2rXaHdoXxYBYKy4SLxDvFp8Sj4undKJuvm6l7ird27oxfQIS62do936M6Td/WfEt eqm2RHMF+wB84RW6tVvoIvSYyBYKFwm3CL/UrqYnBJm+R/uF84ULxx4UprEvhXV0MXueRoWwtklY TW4iY/QJ9gd2kv1J46IL2cc0pbmVPs3WCa1M5K/S/krj0lynPU4I+w1pYlfTYfaycJ1w3dhPSJN2 B/1Au4P9gsiao8xJPgBXb2HQduTn7Hy2jbRrarVfkfPR749pr0B/T2Y30grhbc0O8qEQY3+nJ+id kBqH6CxNnH2P5ekTkLijNERGaA/ppncQhT5L36dDhNJHhUfoHGbGaA0yC22AyjokROjbgpF08DrS JHPR+ewEWyQ8Jx4W6iiFlPgl2UgFmgOVn/4rkEvAAbezMsi0NkiTX9EJ0EZ3Qd6fLDzHJbb2iHYb 6OwBoZKcDR3Tyd4gTeCND/FrJzdA4zwDGryR5Njd5KqxProKcn8u5CcjQ/QCkqUmSEsP6rYJ+sLN opCF0LzkS8j/1yH1Z9M/k+9TGZw1TFIafuYmTRskUxfk7zb8VpFO7N1PbhP3a39F5lEPIRq5sANU /jvyPeic/8H7/aQZ9VtKHtBUotYyJHMP7ri/MIMo+N1A3qCMXI06Twafz9fMgOS9c+wCtPB86Kg5 0ImvkfPH7iKtGLuzx64b20aWjz0wdg5ZQxaMPQr5u35sD7TpFm0HW6xNa2ohY1+jL0Ef/ZZug9ye Qd6DPEpQL/kEv/9C/SdrnyX9mt9AdraM3TT2a+JCf0TRQyuhRY+Ri8mf0W8zhGFSUziT7R6bJnRD Q31Azhp7ZCxMjWTt2EWQvM+Rh3RayJ4+EtI+BNolyhmLFiotkyc1T2zKNzbU19XWTKjOZTNVlemK 8lRZMhGPRSNyOFQaDPh9Xo+7xOmwSzarxWwyGvQ6UasRGCWVbbFpXfJgsmtQk4zNmFHF92MrcGDF tw50Dco4NO271wzK/L4VOPWdKxVcufrfrlSKVypfX0kluZk0V1XKbTF58NDUmDxEl57VjvLNU2Md 8uCIWp6rlgfUsgXlSAQ3yG3etVPlQdoltw1OW7+2v61ralUl3W0ytsZazzNWVZLdRhOKJpQGPbHu 3dQzmaoF5mlr2s2I3oImDvpjU9sGfTHciscIibYVqwbnn9XeNjUQiXRUVQ7S1nNjKwdJ7IxBW1q9 hLSqrxkUWwd16mvk8wfRGrJN3l053H/TkERWdqXNq2KrVpzTPiiswDPaBu1pvHfqoGfjMe83u3i4 o7V9y7fPBoT+Nu/5Mr+4v3+LPLjrrPZv3RuI8Cd0dOAZgywxrat/Gl58E8Zp9gIZ72KbO9oH6Wa8 UObt4G0qtu68WBs/0nWBPGiInRFb239BFwbG3z9Izt4Q2eP3KwfHjhJ/m9y/sD0WGWwJxDpWTA3u LiH9Z2/Y61Nk33fPVFXuluzFbt1ttY0XzJZvF85DlxfPqSX1cl6affbX/Up5jWIzBxXQ07kyatIe Q5sa+eq8RtJ/biO6H38dFHcNrsJ4nD9oaO3ql5pwXEIT6aA2IcXk/s8Jxj828tl3j6wYPyImpM8J P8mp5GtCG4RCGye6wXR6sKKCE4iuFSOKOk5W9+uqKtcPscFYtyRjg+4j89G3Kzqasuj8SIQP77Yh hazEzmDfWe3FfZmsDOwhSjbdMci6+Jnh02dci/iZvtNnvr69KwY63qd6Dq5BffLrf5vkdratbRqk 7v+P0+cVz89eEJt91tJ2ua2/a5xmZy/8zl7xPO9Q9BvOjZdo8UZ0+KAmMSgmZsZAemcvBR0l+L82 MS3Wdn7XDLAa6jjobG0XAgwP4CUWENRHgX7PWXr6eXyn3cyfpUmIKv2vGtLpQcDqESpPG5S6ZhTX HcZIZJy9/v9uGho7we9SN9/cNt7mwab0eKuKbRyc+J3971TP3C/MXgjpxGYvXNrfb/zOuWmQe/39 02LytP6u/hVDY30rY7IU6z8otAvt/d1tkFjF4R8ae2ZbYHDaTR1oylraBCJn5AzOjK0L28erpHYu KsU7m0CmwhLgbqAAG3XubkafZT+Fbaljz+8hWs0Q++k+gRh1vLCfEp9e1D6P84wItJwY6IX0e8Sb lr5oHm0+UzrZPHe0mbSgLJ3CqjoXsUfsCawotOYpWRg+pWjJV7AohvFKRjbDUngOvpsFuu/+p4d8 r/r+YRbMQ2Nf7o0latVtVa6WDo0d31tRV0uGxl5VSlHwebHyN2L1DzPVmT1mZgxutq6pt0BTL9yr E/xWbPeUCGRIqNtnsRg1VhQUt9/vsRsv1vy352Jip/bNgeDtkQs2etPpLzpHvxixO/LZ4oq0jDbj vzqXpj2dafWP9lKhLFlXW18zwe0q0QkR4Vs7TKl3s8ZMOu/MF1Y2uMGSTf56IUbjG3y+lqam6kXn Fn5LUxsrlaaJ1WW3FN4l4KOzcN6PdpvJWUrAaO0Lrak38UaZeaOGTK+ajpiOmzRm3p6nRcHq8fgN vDGK0Ww2XCz0WRb+mPf4CKp8ptR23tSPSAu6vTpHe1Fd57crt6PeU1tVNVGtUOrKNOqQS9xarMPC wix2FfxqJ2lSYnfaH7GzG8xb7cx4t8FO7obHSIjR8Kg1Ol+kYl/Jwu/xF3aOjDY3SxjfkZaRalhQ tJO6kmVJVieRBpcoMleJJ8TYVXedN3A/nfDFlTvOjPhnXV1Yl5iz+lba/zatp2OXVEz9rHDny+88 1f/IveiHDOqwWK1DXomXayr0M7QCXm5HJZwwDA1GVEAWc6IiCmKfq11t9XcrQTuddW6P2+GSiK6u vt5RV1uWYZm7z9t+f+Gtf1y5c27EN/sq7aqK2atvK3z/14XXC/SSRNun9MKXfz3Y//C9oEFKLik8 ATznVXiyC5SyDtbhecktGDxdvsM+wUCJTqOx6R3kgEMxmzRNNlfY1ecSXEO0QjGFbcttzObz3o9q gfI75452jqBrjjny1O7w5DEcnbTHiUqhTslYVCfGol+TjXjJmh6DTmdKOEqqm2bXn7Fme+GJyuj2 +U6LocTQVFM97dLla3ajeqjfAtrH2pkHvNmiyEzbV7qqfpMWNjAjg4JAmETnQ2cM0F30MBXhxNbu J32ahUv5cI128sHKjmDNK5N2RlyRBUw7+hXzcDMez7517BhdB7vURNJKkCiiSVAMSlOdQWmpW26g Ow1PGZhhs5lzifRFD4iLt686l+BcMN4aSrLKlExmypQX1XUmq/DnCmPH2GSMq0DOVgxE+0Z4TT2G c0goUyxMKGEMFYfUMYG+w0qJLOSELqFb2CUcFUThWfqf7A3NEF23+wOVxk/yTm1uad6izaSvll7i bAlHkE0uuObTT7W3/Gux9nHeFkZmjR0XntauJRKwlGf2rNDDQBP3aLUYK3GPxeIfojbFYfCTpJJk SrIruSt5NKlJ2vlh63KACZsAYeyCDPQlnqEhdO/4mILBOnu+mMsbzpveukGZQ+OxeDQOpAAOCBN1 iWCgNBAKCKIzaUuYkl6fx8fEiMa+koRF/0paYkXJbUYpTuWVNKDHyiG5VhKfESsuXihfVahLRcU1 zlpHA+SMx20vYejjsmSD5HHXTKhvqLeDjIqExGbddNnSrvuvuu/GX6188ZqLX2rL99RfFsrk4vny pql1M2rZjuN03tlTdr5ceOqzwoE7PnzhH4Xju+9Y0fskzR+/79JcZNKCwv3q+AMnFET0mZvcpZQo 3i7vLu9Rr4Z4FS9bD4eDWac4gRFMgZTfBdtfUMt6lGMY5C+JjZ5P3DhL6N8UK7XZAMBQrUFvZgLg sH/g8pmKw2q1Kfa6nG2TbcC2y6ax+TzPsDg9Nt696ea50sgxLlEwwhDB1J4nn4+cop+n06p86el0 JmrsJW63xxWpm8zqeBdwVjpBZ0WczecUWFej26hL+BNnaH72wFdbehtDLJFgpdUb2e9ur5BDgBvh LqCNT6CNIbpWuVbnNeU93uCkWq+ClY+vbCG3u1zXrJupe0wnKvIyzVL9Ms9S74X6y+yXOe43/dB6 j/1J05PW17SveV71vut513tU/qfmnx6Xi5ZqfNqAy+f2eUq9OoPH5DWV1vqm+7Z6tss6r48xj99n 9okWwce0IpwZaA6nxjKEahgMSom5pc9ADUNCjWKWtP7tPrrT95SP+Z4RatBxN++lzBwaojcrFiL+ cZ5zuXOdc5NT4xyiOsWpoFF+Iitynyx0ybtkJvuepf8Er1moopQsB2CxiW1nzwOC+oD9hemZL/wM wJ2vKfpYc5GmO+eCtSTOXCOjnT1QeT27RW4hPL3dQJ83vGVgpLOnI32MizJ1ZBz5PJOKl+y72nez D+c7rM1bJO3VL1nBlrSntxMaAWRM0lSI1BFSV4uhEnWx+nG1KeqYLjKhvr5BeGL5qaMwbuUdl6za mUz43rrvofdzsx7+52S68qIl0/xUW/gqQc+gdz92zcOX9xx85e2BNWt+tL9wolGqhq1CZIznQYyn EVbDb5SU20JtpM2i2ATFRivM1KUDU1LBoBWpxmyyEI3ZohHNFvR7UHHo9CU6nV4vaHSiGUiihVqe pffD0jHRnYpFS0WDXhT1Wo3ZrHmWzkSP6ulqxWQw2AS6U3hKYMIQ/YfipS3qANhoFyj6qE2wiYqO 6nzWb/VyTzOXGp3N6GIUP5K4TdSSz0qQxNKINNrbbM/buZbIb8mkNZBqvGiz2UDzvVCqPb3UFbPH 7JE6WoMNFQ4eeGj0RXb5JQ8V4vTkLYV76eo+4dpTN7EHRjnQgNqshOzbAGw8QkNK64811NEROj+0 SbtJ3FR6k+bmUl0dq4ssEhbJSyIXBtdrNwS3sH5/f/BB4VHDrtjRmI3EqE2yO5wut0dfAgmNdgYV uxyBaNbIEX8gKOi8Gi2O7twryxHnM6A2r+BU0Kv0j4T9MRKBcfcMnUwCdPr+Pt0ujPMQ/VwxKjGq xLpiLOYeov88ILFdERrhD1EMsiLtkpjkiz4DeO5jVRgc64QokKCxsELXjRwDYaIMqTvCTTNIBk6J W/SZtBYdRvhOkRgVSy/tZb3ytfRadq0sgio5MYIWYecrpgs16xyrQt3a7lJtZwcUsi6i03BWFMVv 6WNVwIJcIV+psOHMwtoOarhv85Lrz7p0w8Z1mZi/LDt77uW7d2y7+Dmq0c55/EDZjhuHLjzQV9aw YEIwLUVqd2+68tdNVTqGcAkj7RiL3aBPL/CSU0rF5Yb1xu9brzW8m/g4IYoCvVrYqNno3uzRNOtT olaI+VI+UZCX66l+iLYekJM0mbRBjd+810u0XIXttVkoOlfhY6Q4TH5SoVQwpaKrYlfF0QpNha/Y 7zhFnJJTduacinPAucupc/rKv1Fkp2CcHBvXZCdV+62Z92rnSC+6UbVWxhnbBKCSM7aq6SqDCYOj NBgKMtGesCQThthKGpYCK0nEilLcmFxJgw55JYmaseKqTNVk6YprroEg6IFtaBV0p3mfazJ7rSNe X0NFVwksNqi0ooAQ7rz+kQcvjA/cuu3NNVe9uW3FT2+jti8vHH3TMX1azcwlW2+8OrlEuzZhmfej n2099+jg4zc9fs5eWnqAzii0j07dsqDrD2dkf3z3E/+CVEDfIzKlHYRdHSRh5t3NuDhTHDQcYqFS gnaQ0jBFa0p+KvyReLDosBiFPyoePQuGBJs+6C4l4W6gx4xSvY3pSbaF99Khw4eyWU5w0sjInz+j 2eKfdPWWl16SsFTnAkpAb7XZLJIxZAjPj4gum1Py2/2BQNBbKkaGxob3JOr4Zm+uvVbdpjPqdk95 8bCcLB72h4qHPerhPS51o9wlOWstNhMenrfNsk2TZobmRTpsS6RFJe2hC2xrpLWh9VKfZou137ZF 2uLYGroxfJ/tPuke+32hg7aD0k/8B0Nv2F6XXi19PfRb2xHpU9tx6Xjon7YvpX+W/jNUabDNDrAw DB50EikNhYIGqzFgcAc9Abee6QJ6l70k4LoiZJNkKRQMRu1Sib0b3hNAOesQe02xsxDMuVC49CEC UJd33BDdr5j1kk1wud16vUEfHKL/Ugw23MMesir2IZbbOy9EQ0PsM8UqK9b51hNWwfqIfGG/6mD4 /DCivX4uBLhm4gIT65MQC6PNW6xF3t/Sac1401ugd9JeIo1Qafh/r7dIV7/UrGvGvyoMQJvFP9oL KRDRqSQIkwJWVQOtoUX7QjXUTUx4bPTv50QnriwsWuSrmUzfj9Ej+c4Fox+flU9d8tFn9JV35pWF s7pEwubN/UBzzld333iWNpHQZCKVy6mFxUd/x+XxrLE/aG2gwzhlyhmGUJZmWVbIhu+03RN60Pag 44DtaYdJH6JuD8TBla4r3DcL/e4fCnf6nxSeFQxmwaphpTMQANJm9ZI9HoCZrN3PApQ+Aydw9gH5 Xm0qKNAh9sF+AHYSlYaEKfu3W3ZamGVIyCrZEgN7EtY2nSA9+ZSdhu0tdmb3KxAshmbZS23esJd5 IbrZIu/MxKpzVTs33dk7l1sFX/T2zB052YOuH+052Xnyo5aRz06ig0dOjkivqSJBdgVEMwyupCnp TogBQxUxu7DS+7RV1OixVHExUJQC6Wuu4VK4F3LAGeNGG3cPHaol6xE1MZn70444N3RrJmAUNL8I hyd/9MCW965eP3L39a9vCK8unHi28NTB/gO05Sc/2F7hCJT4TdoLCzVvHdhaePuDocLfBnoeLdn/ 6L+eOfUGXfjsDLczkOO6kHHbVMt1oRvaUFA6TAFT6Q3SHdKvJe16aX3JFulu5z2u1wKvlb4t6b12 R0lpSNC56Bb/jSGW0ovhAIlEdeGAJRLzRHzhlNVqYb6U2030weZ5DkockkN25ByKQ+sYGvv9Ad6L jpkxsLYyuaUO+k6O0e4Y16lCLOIRnU62yGOGYYw1v9QDJ9AsSWyRqB4U/fyguCO6YnwU0rCHR0Go sIphBKS/UIdF1YNcF9rzeW4WwwUJ+kM2l5QoSYZswcXU78Kq1B5eTANO3+LTA8CFcA/Ivaemjnew ajrHYnURWQNfWSdGytDvxC4RWNOxmsVxd7Bsbg1LISY46YUnXyhc/ttNi4/TCYWfn1h6aaIhcqlw 0Sa5MtFf+OmvCh/+9O2VQToNETkfnVrK+5yqff5D9Hkb/X5R6j49XeFtI4mhsS/2825I1A6NnVIc vFirNrtW7YJaJy5QnPywk0bNfBtVuyoK0AeWMfoqql4Y9U+RIK1LsVRiyWLJEDPWBiwtWJohx02T SDyemcQyQSMjLVlVeh+C0P7sM3VFs1wIDB9K8+376WH4kgGlp3v6rumHpx+drnFO3xFU6uejyBzh gCkSjYYDwUi0NhzIRKJt4cDkSJSFA8ZIzBkOBCKxRDhQFYnVhQOTIjH0QCweD0yeNMlkMrJMVVUw GNA7nFGmROkHUSpHc9Hu6K7o4ejRqBgdYrLil6Z3TR+eLsjT6fS2RLRufm1XLavdMW3F77zpudLJ Xg6jST29MB97AaN9IwkhD6GRcIi3hP9BvHWmKRdq4+4hhtiFMRVFSG4P17M1kHNFCoj8ryNFj/Kb W+hDbL3FKKdzOTY1l0vLHosxXJnLjT6XW5D0jfarp6pHn80tTHqLZ1gbOhEC5Tf0+rURn8ObSHik KatO3bGmuFMtb6Q/LJz7zZ5w4bcuK9JODZj2CtBOmLygrIsofMgjKvFElFSdL7LCvqpeHw6wSNQb DjgiUV84QCMxQzhgj8QcdsaoHq4WpxufnjOaT8Ppzhc1dOv79Ef1wpie5vTz9V16Ybl+WH9YL+g1 /DK9SoN6II37+L0oFJRS/mr9Crk70hc5GhFykfmRrogwHDkcYXxYzsRYSCd5n3f2YFSKjIqRaVHH At2Av8TXff3dnj09FuyKf+s8dKvaqYlEAn0lXPRNT526XS0X+6gc0cKn0UcyGVQCEpGoTGSqRJcg QP191i/fIz8mH5TNNDpEb1FqrKvqF7FzQgx9JESi7oaAfVLUGA5IkZgclhH4VODY/Clol1gwxgQ9 eZJexIbYS0rW/X8JLIPBqHKhUeVCo9ptxh2RFZ1FvaHKKlVknTypupIQVMc6uaDilNkLyqQeOIPf kUCu5DhxgjbhDmrujFz21Uc1ixMuVQStvmiJLJknXHfu/f+xln5fVxhINMqXCRdy8ZMA6rbh1JML wq6SzOWq3IkSIv4N/ZKjrynHbV5qJXqP1WdJ2cptFZqczjGJTsp2eNfRtd6Lsxu8d9F7s2943/Me p596LRYvFJaYm5YT6r31uelewZ0r8yZzgujV5jweIU3KsTeRNHny3jpfXa5lwrwJaxHPXu/d4Lss 10+2ejfn7iF35R4jD+d2TRic8KbnNe/whN8BHjg8YcTzifcT39EJX5B/ef6RS8ygMz3Tsktph2dx 9gLPFb5XvC/n3vG+k/vQ+2HOagsHDJGoHA74I9FMOJBSZYw+EpPCAXckFgkHyqCJvN4ooSXE6yPU 5/Vyu2tyLluS83pyWS9sC9QdUIPPwwx6PSG5XFlKn1sGrvJlM1FZjuyKDEY4FR+NiJEdygQ6gWK8 X1Mskk222dki245qlbxB21zqQPVwxxVArz2fLYC+VSNMNcNQ4t7C104YnDGv6o0BROd/XBaBN3p6 SI/qfAWyEmAOWlxJea/XnvdKjjzRe/OeobHD+z15T64kX4QMOGyQhoNGOiOUi6lviS0V86mLUFoU bCovfes0FaaNngwk5ucKqRz0WIl1NhBT+hk9RvuyS6DXEvOzo8O5JTH36Oeay0+tvzpckUjUyr3C +qWp0rLEV7/VqLun+r8+0f/VNui0sQ/HPtE+Dtoqoy8os/sd1LGdwpqbV7edUUcpo2WsytnovMJ5 N1CWMaZzRqMOjJkxEsWYBSJIwMC4xkr4uMYcDjtlLOqIljgcUfDojxRb2ZPUaDBQFvDrHQZBHQ+z Y4HdLks5SZEEaWjs6D47BgeFk/u4wOIF1dyQdpRzc0OCuVFO5XK6q/xoOSt3lvAhdUUiuSgdjkKT qppT4ndCk55QjFwqRn2pFT86zbcAJubCqD5taUCqofyRClRwkxv2xgjACdXXBi6XV4dYx4Fk0tnb 2q6kDA6foxxQSN4xj8xyLCdLHevIBY6NjvuQZvMs3e94g/6LOv7CKI8SdJAeBFPgjx8kbOzRvSFH C+PekNvSAivq+AEQlRLM8+Ke8U1A3Tvgy0O68+IRxebIO9wOIFAuLL48zIYje0x5POZwcfPl/pI8 UwAfFknxtBGqUhXpFEBUICNu/6jK0WWP/TuVJTm2GqDdwiROMfQIp6X4qWsDyXkgLE5IEydNLJ2o nXNKJ1hPk8pXWzVTT/3k9J7wVFul0wC5xMgM2P9XqPGdANmtVN/leFT3mPExSfN9ukG3hd6o07Tq LSkiuFKiwdscFrICgmmSwIFwRdAKM0v5CPtb6uRSpZSV2pslg2xgNkMYaPzM4LjJzi32uVIPolco fINOT6ABjkL7k86k1WyvAiTjraIlOpTcWpQko6WK+hhWDr2ring0WPEeG7fZ0+lrwMLQLjAMI3zd UM9tVrsKQSMVA7GeEaqn1xU2IqXteOG63z3/jwOXbL3l4r3P/3PrJbDO1xXeLrxRWAu4sZm2vrl7 5pZHC88V9u1FYhCdQs95AmmvDDgy0aRVfV9JrzhIMmjqD5rqspnLvZcFLgtelerO3BHUbfA+HX8m 9dvAb4PvxUVfmZRJJfOJfNnEVC6ztOz8su5MX8b0CqH+YHlwdvA3vt8GtI+m6Ovxdz3vxd8tO5L6 NC4GlVhpSm8NB/SRKA0HdJEYRK0rEiOlcmVFaaolNg/AVEznqoB172J6HYI8fsmf8yv+br/WPzPD hwA2PclQJTOYYTszw5nDGSFTSVWrnqrqkKqmKo3arCq/WdWDVlVHWndUZYbo9/dGuG2fPpPbDeMm wzjHdc5tBTskhaqPA+pmpEO1JWDmq8AM0FZHUYtyez9e7gl6E6lkuSdZQ+NBrMp8FTU0EYjVfMve n7lwgyKFIIBiEzXRkDwRQxgmlPvQYAPVGwOy2MsZMv3v1D/OHBPQF2pkp8w9DtBwtJ3+OJicWzv6 LHR0SQBuAv3rgV8O/PbV6t4pdWeXrr1rxvULa+azKwuX94WhoxvDlwkX8dLsPRsfPmydbjQ+0Nd+ 12yelwu+KKyDb3YhcSE3c1Qpb6PtujuoIFqRwNeuW03X0xvoALlT/zPbh8SgsSnkDCos1gt3IfJ8 WMnq3SlJIKEn9XpuxXSTPqCOZ+v1FiEdbQ47s072DQKmdc5MneahlJJiKX+zZJEtzGYJw0ueWfZ/ 8RDidtmRTnBSc8uIdHJEdbQUQ1JOBJMms9HMRC+ykxIxJoZd0SpaavCDfWxYJe3YjZSEqtCqgBkb g95ndVfRmAOrdBqdj3+Vvyp4lKc4Dp1ajjkk43Ee0uHxU85tJYR+zWzFcE9SuGH1yF39hVcKf1o9 sHDjFtqPNEgj3Qzu23hg3U23XLL/uUu3zMr/xDb4sFnWnrf3vKYpK2jgBXhxtxUuLhz6Z+FGzSfX PlgYLDy9Z+vWH9Hmvz/ct4GPA/eR14IHU6SWMWVP3MsVRUIl3y1R6ticfDn2cpUwM/5IFfOGPZnV cYRCDYlkAtmrFBmR8SvplezS8KXy+ugViX66Rb67Ctm8iaeTz1WNxV2ifD29KX592b3xh+iP2cPx p6qerzqS+0vVWJUFmbTUzxwp8Fl1U6Yptzp+ftZYAfQtSF3hgC0SJYlUgMDct0Zibu59xRRWmYjH o4wCZqLxJ5nMdBXlD+n44Hp4pXUSEim7dMKACjuTwJPB2iF6q2KbkCotDTKgVAh86B0qBtdehNPa 5tWRyFMRNg+GEYvsl+qpUt9df7heqK/Vq7ytV/tBr/K2Pup2qbztUg+6VN527ahbcZD6ijGsbxhb 6uT+WjrN+Tpb5GtsVL4ex7FGgGc78p292TS8u2YfYC5gWl4e1qSOvB9yQkWz0mpMpTrn5ZxfVR2K hRNVsWwNrQ5hlYlW1pBYPCdPqKHkNGUBagHOwrEWVccmxo7uMecp9P6ekjz44OgB6EYoTRRP7Jfy OckGNalSJOEmVzodiVARwemy/214cY1ZFAo6jpLRCeNiAVJBuxapvHU1siUkBZNz6lTxoJrw9M9H Dm1/8Anq7epfd2qSM2h48eWd1zWdyzYCVS2s/66QaHns8quHkoUrb2g3s9vpo9du2glBQUnf2B80 WsiJRrZE8TnuqKQ2amMmgdg0mCugTc+j85jB3jREpymH6xvr/UJAs9y73Lfcvzwgai1aK6kYbtJc ZrrMcpl1va071B3uznbntupvMG2xbLFeb9uSflTzaI3ksNRYai11pTWltaV1HKKr0sghOVxeXgXY bzJr0eR8uVAujHBp7aS6GZYZFQtNiy1LpMXli9PAkcMsUBOuC9Qv9C70LfR3TDin5pzac+rOqV/a YBVMpnKnKVAeM8lNE8tzTb2OXufW+N26u7P35B7NDqdeqHglPdx0oqnkTH1jgKxjgafoW0BON9Fx hE+x1N1bjajyunAgFHqmFJifUuu7twTCo9lsLTGbrWlzhVWTNKgbMUZH4QWlqoVYiiN/VAlFawHn Au8bojFFytqft7MPkO5uf8r+gV0AALvl6fCTobTEo4+4ILwzQ5/P/CUzBuWmTK9TMm9hRyAZOZOD ytNknqPTSB5wj3c8ZNuZ7oHB0XuSBw17R3vzWTUpAFKTa67xYAJHaq2gasCzp/FDtdRJpR5giapo rY/ndM5U0lRpqCHlNq7WnFjpctg1VplriMlcmS6ToORs1vKKhAOKTp8VOc2D6FWZelqqcqARtN8J o9Rwrmm1ZY10blrT2YEIRG8aCbSqJ2I2eW15Tc6Wr8HCDZ4Oao9lGEBJpKy4kbSiaj01toyApb0m xIrhibJkPFnM2VADFohcJhydT56z9sb05I9/um32X56bWBv+b7+vFHCwv33/RVff2tBUVvjxD+Yc /c+LNjR6/BEjbKL0ll3f23TW5JrZV6+++Paz7v3AoG0BIPyL227tun7phNWVof++7KaFt/2qzhfO QkWC9jHfSDOo2kd/VZqQ1s6Wli4NXUgvZBeWXhjSZyMtkXmRu7V3BR7VPhzQMVoagqCUIlF4+7ZI TOeNIfQh2fSRITasOA2YiaJ4rC0OGwlj2stT0JhDLKX49QZV0hlUoWZQJZ0h6nGH0yEuWK38DhKS QstDu0Ka0DMsRdxjnykm7lO4VQnoxtP3yqsAAkhfpNMn0fcHSQhhDlMdf8Aek60WXZxGYL8IDahj QxRTHZbTp5CzBD+DA1lUeo2jy9z341AxH4XYv0kiFdDSxZyaB2xJkzO8ZuHzsMuzoy9wI/3B5ana WbqkpJ1TeHFhvKnhq5OnDXKN2eq86BzEJdV+NY0d1e5Gv2bodQdJDu5HRbY2h9rulePqVlnoDtam xCZxjrjBpknEEmUTYhPK2mJtZQ+V6crL8mVsfu4y05W2e8ueL/syKTZbi6hUOBzwRaIVKioFYNAb icFFh65iiZTFUAFf7a/7eL+h8JHqyKkF7o2Vc49NMhj0ijmvR8KNrM/pGYCok4q9pARAlAqG6kUV lOLOH9d2ej+vsTK1pU7K0e7crtxg7mhOkwvL6nDK6nDK6nDKUYdjk5Ouc1Knqr+ciE8BYw3xNzt9 2ZPf+IHc71OHiccHgTnjDyrh9EHuWXBvcBzkmn3Wht0NeiimZCRltEeBUDDRlihLxK1yFZHsSXN5 FTUZI1KiiqRMWPHRVQ0gZLhwPgU/kh6ueujXnhhCsVz3JIFQf9tBK1F5cBy3Fn5Bj9bMT7vOGnnz 9x/l5DZA1bNqF8Z9pXO2r938y7kAjrRliURruGf0vTf/8MC913Z8zhxXn5lI1MV7R3fPe7N31mX7 j7AEMCTwV4LdJ9yH+KxIngM6q28HXHaEYTbJTDZNM03bQZEfr1msPZ+ez1ZrVmvN40Fms6AlTIsk SarV63i4Pk9aarI8ZyWwT0BauoYnNyHpoESrFXkAnac6ccxG0BCq1WgQF2P7FYOIBKM14hqB/ZRO RYjmAFI9DhANnbpf265rR4od0sjmjoyOwkwYBXuc4tjL6Yj3FhgKeshUHt0GsK9mQdEYpX+jj51T +FHhR9+jT2nXjqJfRg+wQ9zGmzk2ImwVnsK8gknCzPFYqNyiIqstQNzZIldAl0noTSZu+XGySBBz DccKTA4HW1Tj5pdg//cq+aJwUnFxEqpRr63J69StDl4OCFI24JZMDQlpyitztWbFgIealdJSvrbj FFI531ZC/CKkVmzyUq961Kte4ZUSIV1zpQaJai0jL4H4YIdzIjyUHeXd/Hb6EHD7Q+qh9PDw++n0 S9LbhzjcGlDWmYL9NcyxoJ465HC+r+VRwwGj4Eg7riZX19xAtpm21YmlDneT1NLXojEE52jniG1y W3ROk9KytVRvtOpkEp1JZxtnmmbWzW5obZo5aYlpjWmz4Xrj9SbbQvd1bhZuWd7CuvSYiticKa+q fZYGkLJpHhs+YMibU6Y8mgU/valOMs83MwWrLrMgq5v1Zo252cuBi3JTfp53uXedV8h6NyHy9h9h ROzQ4lyz0szQ7O6qvipWVYd+GxKmKXaNKTNcRau6EqTGYjbX1qLjT2EExEU1z9I1BDMm+RuteZII J/oSAwmNkjiRYH0JmpD4RYlnWStSeF2QweE8Mt/WKKFANl+tU6x5GXZyn06QdPSEjs5Hwkrr5NZL VIqDHu9NI+w3koYcwE4aUltlebA9oEDScnL0WKc00tMy0gudn7bn+TXpdLbIGXsEMzCeDu628uFS dfv0uonBmNbZ0FjfyJBTY9QjIS4qR5lYZ8rDzyl1BonDaQtbgjQam6jNB0mjvlamdbUmR1AKUmsU qyaxOcgVNZc8dNyJSlcgP47buhQII9Q7dHv7nhYHj350pkkvbN991WgpKPLoHkndHLDmG2S0nUNL Zr45qphMea+MJDAsQU7tflPeiKFswGJMGbE1YmvA1vA1lsSpkf91oJ0JcTxvpAGJTGoCA4LJntPZ kDyciewSnrGmRjVdRbMa9/CIc80ENv3meP2k5VeGyt/4bMmClkSSZZOJ7ODOjWdODDqMHptkdjV3 r65uondVzpu6uHHO9Rfbfdde0Fo99YrF8a2ro9HKpsyE2qrFA+XhM9KbC69dN7FEZ2luvHPqD2hn s6+yKz9DzQdiY1+NHUOO1C2IgcbpL4u8vzuk5TwMMmGLtCVm4lUhQS9I+CM1BILCKSRLq7x6StVU OHISKDGuN5u9HqJhBucQgmz2EsWAy0rg7SYMpkgH06noU8v76aIBqHIqomvSK2Bb5EaMC9AkHiHg EbiP38PvDWm1yQThsWhxkZdx+uXV+RK1ELnE+PPT/JDZnEyAsPBUsP4wLx0af98hbm/y5IsNUpL+ WDwg7td9EtZok62Wzno5ebmwXnODsEXzsPCEXjddR5v0JWWWKc5QyVSvx0w0ATeRkI50uibVYe2A lnVp+7RPaQXtp2Y3Id642SxZ5lu6LQMWTR9Wgxak2HEYIYfisOWwRWcB/z/dXGfpSrw4u4irgjW4 5uTsM9rZW8Tlelvsnrya1agyR8onCyZdUhZCMvUbvUHi85rMQT32wpqITH2mAPJUxIA8nlEzrnsR zu3hVN5Jezs6aH0xEb1IXbU8uq4rQ6Kk/TRqw+0lOnHzvTf/8kfbnpj/0GKb7A1WWKmzqubi/LIf /nBVXV2KfXHwr784eUdfU5Ow//4ZfinWPZoa/d2EmlefH/xJAEgEmQYamgX9EaGf79Fr6GkNwvzf CWGrWkB0J2wGXVekGw41ukQN+EYAYr69zwlLBoXXD3CdUlotQMhDgKc7W14aUaOxh3j2zG6HGkG/ tKKqlsT46HksS7Qs6FyoWaBdIC7UtQfag7o12vXaPtIX2Rd4WT4sHyUfag0NmAe62LsouDzW5e0K rvf2BvsdtzgH7APehwE8PBXbi9msP9P9zPex/ljwE/kk9YpslmOJY1t4m9wXOxHT2WX6HKYUyVjC EBmYsc5FcA500RXpizASkSKyGgTsjgx8K4pyImKJrC79AC7pz9wJgw7NOwI/m2+URkcejTRF3gyb 6TzzdjMzZyU14tYFvGqADGKy8lFi4CE4Rh6/1H+dn833051+iuxks+I4IWJGryQWE961Ymu09SC7 teh28byMzt6e0Z7OYz0qWaXTSIzrQWZMT+8xxziLGReUnlt6aanwg1JI5J4O8EZjYyPmOPNkOOB+ ENpcRBLJmw9A8h1w5rWSxGGCYUhLyMbh3VJR5NE0SKyHcruMYdqFSmsowzAHRA7KUkUZcjaEWYkj 191/nNJ9W/6runJiyG6KxSavmnTWA1tXntlQS8/Z/99U/OAItW6fm8wmXevDoVkrH/jxV60ZQFBo /9SxY/Dxb4FjUsVmj1NXMqvGf8tFxOeQGaFGdMfJjcilblVkuU2oK4xkTlGyaiTL6tU4+qVStIC9 XGjJwWeQFlDKlTX2SsMOLrwkp2KwwgIuIQkMXWUlJ0hYuJBdWSzFBIE0jIyXpGEux7idcVqAne3A XUQ2CQK/NdhdSpXSLsDzYRMeY3KrUsyt4SILNSzhWxmhZqwZl2eynM2Uq9eojcNcYDGbUeXaoXRR vPHEhDQXbe93dh5qGYFsa3mfy0+ASXBSpk+vzWKIlDOQOtaVvUpzlbZf05d9Kjuc1SnZviwjWXeF K71Iu0i/MH2nDhOvqZxtME43LjberXmkYldWN5w9kWayTOTIM6B3OENKW7M8T/6evNp4kbxR3kl2 yo/rDupeqTAl9c4y8xRHyDnVVVrmnhIMlU4N4zaTptKl9lq4klZWhgVTmJgiZqQorlEcri53n/sp txB2D7iZ+9Py+SLqujeVqeXbp6fXia2Z1k3jkScYuL2dcPz4H4zckV40GQJSUiUkKW5UQelPpjX6 skRSXy6TtAarlC4h0wptpSoauRPBc1xA4iqFI9eFT9fpgIYGrfLkIihjKGhOsVw2FlWyRxurs3PH f5yK2c9a+2bdefTL/94wDzLSn7ZQe5Ut4g5UmQonMmLzudn2tmWDFy1bM23SVy+/TKfPfeyHqqj8 6v0HpgftsZ7X6JGp3fl5a199/TcqTc+BzFwgDOKLGKXC1eM0ndK7ofPMNhAhQYQAG6sqNK2unEIo h7IZQeIiphmPDavykhcUO4/+EWIKJOw6ApATKbU4ze/mhf1crmJC1tg76h0ovP405wdNtckEEuIi FjKWp3hi29mpEjZUcvYQcl5O03Opqw8THgaJwKvAcwLUShTfqFcB1jgnYkkn6wZ1mBjWBfNxl06j u03zI80ejcBfpUPTOC8mOYWXlIRDaCcvorUgfN5abKxufshqDYe+q8bTSKtEXTtf6uxMT1Drippy ggfit9zb6esiXSXvCFqfHISxFsy7ESIM854xts6q1Ye5muC7e1OpWvXwgopMbUD0Gdqd33MvR/7+ Mr8OWeCiDvMRtK6Z4lZ2k7jF3C9tLn2QPeHd73ybvWt7TzrJ/i44HV26Ln03WrfV8ILuVdsJHbSd znI9EwycU0Rwyqx6wzQ23TAvvJAtNKzE1wC2Orf67nH+2PBj45B+v2HQ+DP2J3bUfNJYoj+sw5yh wzrWw7e87zgwPYjp/ldrSkjO7eItcCKWudy1ybXT9YFL43IFfqWhGMHDUCLYHN/j5JsjygxHnvfx OQHKaUD3JsIfgbzNTde5N7m3uwX3yZKSPp7cMqBnOf12/Qd6QdIrSHTp1g8i8UXUP251achWTldC peLIWXmupUCsklW2Cies1MprYkBfWltDrePWCxyBuaNIWIeZz/PWR2Dt8wkCnEXBbb1ICOAW9zoX LG44CTwvE+oHagbQTWMjgv60tX2fSBDr7ulQXQTcVLTLDxId3maK5c1KVd6CBTjH8J5UnpMZNlxK 7AkU9wLFc+N7xuKesXjOoO4pVkPeBTjbJ9vzFiwcZOBx3m/+Ojo6nGIRsfOMazFIA7crEVHRpaj4 Hl21asvSzVVh1+t3P/TpXw/c+8roFvqoVvKdW7/gOjbxzcsuO/eKkq1/oPTdT6nujceb2uONyjWw ieZh7sFG7U0kzfTj3J2oUjVWlcJ94yrVuw4A87CKVG8tp3quxqgDff2J4uAManXwI+OBQpErKOSv KUZ9PBHCFwGQtjJEA3scIs88HhmWhlsOAQooqiUopWHpJekV/oPRhMaOM/JBzMPh9yBLNKCUlotx PElfzkOT4iIqcg6kqm2tVuOIYlK5UT2Oar2n2thWa1XlaSUEKzs9jNcfgg7iM54CyuRt8j2ue5LC VGGqeYZvs7DZrL1XQ7NVmyID4oBup36nYYe0wz5YZZBEyKnlFcvTLKi37gvpb4vSfSHdkKBXwrHQ ztDzSMO2xxMemp4PFzhXUe6wi3qdUQKBD9Gz926H2zvEvthDK9JDVFIsqXLqsNml22w2GufEurer q1bdNjUVty0txW28Wt0q7mCkdsBKOYkvt3Zbh62HraLVV/kMJpXpxsFr7rem4euCdFUPtxmbjzqP 9apYZHMzJma0jMK/hdRUNZAjUVbiTiZcyYQ7FSRlJfEgcBc8gPugxXgLDKVvQZXIILbH6mowURQG ujrLAJpINZrg/7lqXPThYGLygtH3y1Nn+Pbsad/fc357U23IUzMrHE5mlOBnwpzRh/uilfF4aupK tnRG89afXj61qjFUF7nY6axe884ZM0B+ZFJhmvBb2OUTyUzSIdylXOtwz78reU+9QKqkZWx9xfoF jFSIGfHsbbKmpWHesnUNlye7l23XbNde57neu72uf/J1bdtn3zDvDs8d3nvmDWkOavd59nlfq31t 9vCyw8uOLjuxLOCXXTVSXUl9eJn2Ef2s+pYAcQv1kVkB4mv95nsMBqezxKAH9OBAkufv9zmgkVAY 3ouUH74FjGRq2Zl4KvF8QkgM0R3729N9cLhwqWLh1zp2Igj3fETgDgO/R93ilgiuVbwDs+gsPkdq FqY8tMyq5Kwza34JLRmiesW5Tk83Yb4EPFEgonXiPa20dUioVsy+Wcasj8739WEe1U/YL4HwGYS5 SAytVoyizodvxVRW2ub+VMhB34WwzpO5Qk4JA0ldl9ue25kTcl6uX3NmrvZydfmM0LeQLuRts4C3 UXh9n4Q3qkf4JSjwxBow2MJEOEURXRtWkIhVuz1F56W6U8OpwylNysqvxKliFg8Kf1Yc3DpNXS4v yy1Tlu1Cn2uX8VuDJnPtMuv2O6fRaSqWM61adlObu9v9FoT90NjfFDu/z23mhoFbrSNQ+J8oznta aEt1TpgvsPkCZl5KfJoSutRXWqtu8VRsT6o+Pi88zdsonL902TP0ChKhxt1bEXcsor7wLHpHQd6d PSPp3mNSuocfhg7o5dI/3SMdQxYDnFo+K0dVCqMfcRXRIo3wvEhYGb0Svx4XQ0vseyvyQYRBTyBS BLMMQdF9byU+SOBIL/douesOifP1zLLTyNHG2Uua2uJ1wVKPlwIcmFBdU11bLYhTkvOSmURFcnFi YZAGJ2Imx+y6uTLSA1pkMknbEiTzq+YGydnphTKd6p0WpIvKlgTp4iWlTQFcHphI5lTPkunsWXX1 CmuVIccna5qD9MzsWUGyoPwsmbR5WoOqu10EmlTEughbq1FS3nr+VwHG53/IqubKrkeFnBRjRgKN 1iGxLQOC2I38NlzagWk86nxxD/QOlwRAgGKxYnJFmQoGcaDIw9MtOJ7Ek+HhUNU3qHfRYlhKDUGV JeGH8SDV+B726xYuPbTruq4X01bM3RRs6e83vvTQ1OmV4Ugu2P3zSZ3rLrj/qxc2zzbZ63TLa9N5 6pq1amrt/Dkr22oKX2ZzTat+su+Jmtp7/0DPLP9Bx40vKVrR4PEbteKM7r4DJcl8iV3WaQStwdJ9 ds+5ty2ZUO/1Js4wnBuuDse+x7as37hjyRm9G3cuPePUNTXtiVx88qYZtW63Bkofs/GI8Hf4c/Vs +7huLG2E0kPqmtFuVBWh0Rvn+141hARw9EsVZkLhaDHT22vlmLM3ybVlmBN7MlJbV4bkCkzIQ1Kw +oxIlZc/o2po7F/7+FEUvlBhKxSKPIbCZ4qN316lPq+Kwg+bgmk+xIElgSWFpYzUQvHa6lQsq66e lNlLKzUcyULWODxBNV8cRDnuEarYk/TSKxOkl9TkcXiGcBG5Gj5tTbfXgq3FRXXqGm8sq8VD+SPt ZUZV/RpVlWtU1bJxHO1SD43jX97GBhpRr4yohyPqlRG05oSK/6LwN/SXyFt86mmuxKuqGhvGtbaq tMfLh0B+BK2AIwmEjCOyIOKAkm1UKuqMjV2wm20JW7KvcaBRM9g43Hi4UUiLdH5jV2M3P6Q0Ulnv LQ/ZhwRM3I1WlYfKZkWN5SFpVixSHkoOCVYlE6sry0ypDdVNpXJZPVFbCWzAbpeMPm/cMGCkg0Zq M3YbdxrfMmqMXEghEhSJZ8JV86u6qrqrNH1VA1VssIpCY1UNVx2u0lR1NTwM/xBwMwxKblnCAv12 4jtiUJj9MD4zeFw5l/iDWr2YCCSDWl+Q6vR+XSlXz+BbVUFzeBiBEu4RUjvXx0VgFixXTIgHt/GI E9xDUac6h65IHeZJnD4In5HOXXftlDO7A06rMacUJruUCUYhPDVXfcEsV35aoWlSrMRrC/tdWSt1 aG8ZXbmxbfE5yuOF55YAa+N5PdKZdOqd38vWzisEv5cJx+NOY+NiYVLRf+T4RzNWOvCLiUTZeHzm IIlDEZRyE9FhUcndElGxjIiaoBNxegUDNIgqy1E4qhI+Cu+ojITCzw9wujdYwFNFiY/CH9WrOJed Zrd39vOrvDIHRDzzIusim6CGo+vAw1342INqyap+O+dGMSo6YQ2+A6F+qFN6v+hKgvw5OpI+BJZA PD4NRqBfc4JFVnkgoq75c/bNng24gxemTCkWFF9Dg7hI4XDXLpHxlxIADFGdkzfvCyXIOclgiMcs Kj8gbQtkb1H5gbesyA8ofKHyAz+i8oPXG499iwfU4iHU/f1DLYdATqjvOCv4BuK0K94dH4jvip+I a+X4/DhT+CrOFeeECbXqtrGpuMUXSNR9fJGEb5WMz18LBnHOilrKQw6wRZlvihyKTDX7zM4BNCVP MCFS53QYB5Bhkec6eE9rHd8otpY64UKz2eKzxL1KOo+KI5ZT31Q74KXzvbTL2+0dwAT8E16td09s z4MqO/Bq8+838IkHI0UzFe4YmlbEScabhKaB1IvQ8Le+zeD8mq5VsgaPqlgILa+YOLGionnif/iq pxRaWzMBgy7kD6astER7Cz/RXFExsRAZlRfnQcj+5kV0xR2Vss8W7+YYx9i5hWl0u3Y76LacvjQu 6U0pp+oGOcN8BE/u4yJaLXBSRqFIeigcUZxFCi1St5F7TRb47wX1FhQ+U6kVhd+p1IrCEcXAbwkT sbyMU6w5hQMwoMrdgZ9LgO8OceROeudQUVRD+p0mzfQr8F4O3O+noo+meV+3NNRZ0nsgAJX0/PRA +lHro6W70qKMnb60IOHI4bTg16fK5CllodRUH2+SuMjpN1T4AnK5WYdZzFbEQ/A1VR3ebNuJ0DoH v5origON5Bkhk8anWjDCRbpV4T/Ox6DeeDg8IFObTPmM/ROyIMv84cAsP4fPiAvkPRXpX0T4qKvJ olz8fR2W5194mXsS4w9zCxqqpaWI9w6KhwL7VIob6e3AROnm8TnljvT4RxRUH0YKhqy20kTQFg7S kBWxBTX1q+jBQFH0IHj2XZKBOXI65YUbHcUI/DjlpNLNzWkQSN+ru5a1V2NmuH1FxJtxf0M/29XT Fenmgnxq9afHzojFJlh0SxJLbmU33ZWOjNMQxZf0MC8fsq9BeH6cgtJ+mLSYuKOuiykMdnA8vGd1 jSOcBtx8DfvguEolvKCk+W3JSH1ZJkzHTQR1hk9EVI2GjGoDZNycImGfFW0FFIq2Agp/VuPbKBQU NV0+I1F7WJM0evwJWOt4ESg09SwshiSpA/U56lWLob6BJH0YaFTQDKI8gBwaXIfPOfxxt1HEGKVH 0uOGxCiC1ghbITNKpUs1jJUefgWSE7YEJFIRuFBV9EFbPpxnDlGi+P+B4Q7jgGnAfJ/tXvt9jnvD O/N7jca8L+9fLi23Lw9fJK2zrwvfxwyfhkbCrM9wjfUV4RXbx+xj24j9Lw59i73F2xJulFvy02y9 xstt+iyrkOSEnMzmERGQdC5pET1bWihrYtISusT2kfS5pJ1pnxF+0fCi8X+MWo/BLYVLw+E2doZN NNltTovfXGoLWcPiAmERojId0kL7Qqfos5WWhsILmGY8AJGth7YCLVNJMJZhci25ykzNV0IMGpHD bTbj1eMWjgoMRtDpH6m2DQonVFmOwr9UWZ7J5BvHZTlsGzXsx22aQ1BCqlmjfl4HVs0iyUYZvlzg lHxhf8iXgblSFjUyQ8jIrZWyWH1ZdkpdqH4qyRITJE9cDpfIlMlh2Ic5ykowowMIrBx2Uk0Zsxkl yWtsIMQzRD9T5njNb2Iynwip6fN5jaacuc/MTpjpYfNRM+s2D/PYjsezE7kM/jDmR8C8IfFslmQk ZIvzVHHt/AztywzgY0RdjfkhesXeyMMIt4O58Z0MsDYszDOlXj7ThqNoQNsAQXDHCGucamn28dbD euOEIzXzuc9eNaVOnXPDc+sILvCOa4Fi2qi63sLPvaTTdUDX9fb28NBPL1L6+R+S4YpzMCSwTQl8 lnAKMzuwlCogvJSNz6ZA7lbexDf2vK24gdDme4jHDu/GNyu42j9Nsgi7w7bifgv/dgISevBRBZ1T 9Wu4jQXRUVsGeKQ4u5pP8v22cTXv41lmfSRJbzn74imffroymov7Jhdak4FU4U++zNxCZlrMZbJZ Zb+rwk4l7S2nun891WE2l5QihsEyE98t/ObKSNZqjMepy+mpoWsKhzsavTQet5s8kbOEM3ZOD9hj XF9RfAeZMBtkjYveWpQ1B4kHRoZqZZWYRaobR+lUqUFVqUHR2r+djop/ovoZOFI0pFB4RxUZKPx+ P9dfZu1PIB70WHTECRFhcn4dIddx8yM9gbsT4+zPrXN4DhJ009cWU5lTtZVKSlR9g2ABvi4+jt+p ioSqioRXqmj6oMDFlxokL5o+ZjO+F6Si/XBMuPnfosaOuFR5esAz7DnhETDjanhvy7RavlWa8hNr qWePZVX9fA9VPPM9XZ5uz4BnFy7UmctDullRWh4Sy2KnQ+aokk40Ehq34N3qY/hW8ddNrB0w0/lm 2mXuNg+Yd5lPmLXmPe5vGS8w5lVw7euv+vCPYqkomhrI/q6FctpAudJXO73Q0pLxW8NefwqfDtDe 8tWUxY2lqjUiKPdN5+FqPrbQI2IOWNgS4VfjesTTofqcHSoS67GrZoZ90RykzRUlPgqfqMPHjyg2 buLm0upV6eqGaaevQqF4FT+iRPhV06ZMn6JeN0UllCkqoUyZgyldbNGc0/ehUNQwKBQfgMK/FGgK XGTkj5mTVm9Pq7enGzCkSIkEETVIXJdg/21FzbNsCPIHYx+uML+7AVFEvubPaLCrz7Crz7DDhjhe fIac49dg/8XiM+QK/gzsv6eY+DN4JFLdPwUaxXNkty87oW0GN6rk6QsXKfya7CI6b9G6RZvwtZjF 4vRqb6LShOQsbTHHAx++4NFJ2P2jUGrDw6dVGie6ce32reI4qYMeQe88IpUGds19ha+ha6UZj8fT TTqtbuGixTpv9XS7SvF2WQ2kymnVFU6rx9INU9S9KerelDlo1yeqrpDldvTTl6omUQucNVD4m3q2 oaEdY/BnlV9QKHIQCl+qZ+fM6WgfZxxEN1BFvpZQc3VBY6B1VA8CKJc0Apk6aMGnKZ9HcsRx0oYl iyU3dny/34usTy+PReKvI6AEa3WHO/7iFvogIDu4z43I4kAHXGu5PIQJnKf2RRvKQ9UoKKbonPLQ 9FlRe3nIA+96XyxdHkIqmGVfbEp5aBoKyuTYorK5UxaGFk3VlzfMVfLlKT3RJaYvXsIHJlFpNpp0 okarmz4NUwY8xg5YoPhoRCQn0255UGYI0NYptobyTDremGug3Q2DDayBH3PPXTIlPmdOeO78uaxv 7sBcRuZKc9lc8PWBEnft3K72jiG2FFprk3eIrtqsmqXjVim8Ee6dHytums8sfoFQDehiuij+56oq bDwd/OsveqF3i7B6STRutlkSsWTcHEG6ly1qTXzbc4fjzj+9yNNc4I9zx/3/cN/HtQlPSIDS8Xwj R1Qlww8j5vbN0W9bsTV0/ipH1dr/V9qXgMdRXOt2dc++75pFM9Oj2TWjbUYjeWRhtYzkTQYJvMpg JG/sYBnZgImNlIXF2eQbCGuCHBIDiSGWR2C8hCCIb0IWg++7hJfwJcE3cQgkkDiEcFls+f6nZmST XO733vue7FNVXVXdVdNdderU2Sq/fJv7ii/3LNwU8ZgNLedNtztnR6oMqkByeeGaxaLobps33bS4 aFRHsr0thSV1vqae6dkdOT+ndZNW5sqIb623JmrXD9zc07Osbdv0jctlD7b5VbaovY99fqheKSww ZqZ7+N4f69LFyGtSgtnWafeqlgCcBcxexi67N3uOJsaZC9J/ApflxbO4rMBxGTGkxWVNPLTorJ4o IYV6yosGY2kYQGFSV6zaOUbQeTibraKpzTUkwD8uoz8kygqdSPxZSdCM9whBjk6C/EFB/ohgmnPZ 0px4Ts8QyUgQmcaVmctoDjkfklNKZAnVYgzj9reKvonvz5pyZnKzQ04bagDguyn6mDWW0/qzZY2x hgbOZLNh94YZ+I/kcQWZEAYB7jjCg4/LvJTLGjy0WJZ59U08zTvQVH6+NUbmO5plOo4rdBxv6Dxc EcPDszxQLYGihgfqLUFeM8gzgrwwyH8o3c8T1BAS7zxNt6TTheYKwvg/Mt1An7YVwHXTFQgDNBb6 CoOFocLOgrpOxRSeHsXVREEzUThWECcKbLAwWpgqSEGdJx2ylhlw6XQotqhGlw5ZFkWD6VC0zIBr StZ2NoaauqqFaC7P32gsGrVaLYYqT0y7U8cmdMwKQfC47iWdSkcMuEA6H4zVhtN96cH0UFo1mt6Z nkhLQtoG22FayfWY8unB5jITjpRA/y+ZcA6vT9Ko4j6pqprByZ3aPzORscGEljLpe5NTUprL/xMH DjOVRGgzbLkKU450NljPN77Sc63ssRib5k7Pdip5g6rzgptuNFpoKrrmNYH7Vl2eiW8/37O8fdv0 1hVhH+e9WXvZTds3fWY6uNoTxFybv54t3b3ATxwMEWgbupGYZ1YhKJoqVEM1CEGaUCauP1TZ19lI NdrkV9HcoUJKKE7KVPFqqipoT9vioPpIUsrXwgpb7JyShZ7KqZ6fbg7QmPKrXHzEuUzYb4KGw8KP EA8HJUBJlSpkMoW5sgRfjIjXjNWIN0Li2G7HqJs96tnvwUEN+iPBX+o1jj8Y2AJ9t2eF+zb2Rf0O 6y8D2rCSK6i4ksR4mP3Q/WO/qITZQt1MbxxobkrJYA/Qi6GoYsco7FMNqoZUO1UTKo3qLaijGTsU 0zi2OWf1A0hLmBi0mZ6J1JIeuB9ftc8UWrgvrFoIf8zPkF60oAKEz0zRInj+yu8JfikHkxOXlHvT 9mbgY5dYH2DuyuXLsCVoYUFH3JIQYWlpiGsSdqtLFoLMLzOPHimvFimn2SazgITAbaySBZ8aAa0n fD9CCTKshF4wxhpGHfQQFPsWcYvmFsMtllscN3u2eLdU62ATVLYG0lfb7MUAANoYJ/cZywIbDNGy yBb8D+7rF5bPJHmB4gDtYxKicOzWa258aeSlW67Y/rMlhWvmjn9mza1XzZf2PnTH3k+dGt39hSdu /eCmzo6Htr0w/ZtdP3j3i4PEK/tgepF0CGMtKRTFmspYS8/m2vc5Qy3RYCQWQOh1+gRZSjs5DnbK XPkeBM6HnM+BRFkjF4mKRq4spTIOlUXjJxUCuDJTjCBA6uOWln6NlnPJ9ALHwgLD6ASGhVwDkg0g 3HOcCOgTQEcX2BXI9ui53chBIXfm1FM0EHMGGpPQrdMsMxhmt6F3fNw6OY50oi+0BnAe1p/hlIT2 /TJqpTSWJNxUWNAZI/WGOkBfusNWFkeQ7QRaBPI8xrf1GN00qm81zCaVnqJtoe0S2w676vYsm53t mN2TvSR7tf3q7LBuq31r9nO63do3dR/ozY2zV+b7m69tVimzWYNOSqUdThBWvttrnCCvklEhGelN hoQu0ZFJSap6mHhST0SYO1iMPq8l1xQ27DSIg4ZRw16DZPiTLHJGXkCW+0iFFWJqUv0sO81QRwbb SLkXogkgRdLsLev1wkgYP+uGs4prmYxkwT69HQ4SMKLlhoLWrIs3J0yJxnhBm5NZgxlBXt8isyZj vUzCxsrQBaIkz5nQXevvl+J5N9E6ZYEhjUOYZFYwowe00AxuVJcRJrl1IsNtkDoi8yfmj/V+/tJN dw59Z1FLKldV7JmWfa1Jp9sWDXnjrFlvuW7J+jkXXaqsbGyIScUbXtm65trPvfz2gyNua930m5fl Q3Cv4jE2rZfW9jd6LSPT39kYbVt54eUH/9emC7046gn6mtOLVALGchAMxJcrY9mfwJAA+80NHS8Y lGAzHarspi20K+E6mhV7eE6HIPc4x6VIvM83zxY1jWBsnhWbNqixhhzRuFeT7ncYtZbyuAFpANr7 3PZ5io/Y8qCZCtQSCg3U0jgM1NIY9Fv9oeU2CRYURHTL3mRfnajAxOJbqV11qkZ/Y6Sjdlam16b4 lUhv7YLMSmufvz/UF1kFrZWNtrX+tZGNtdtsm/wjoU2Rkcxt/i9lvma9x/+10D2R+2ofyjzmecS/ p/qJzEHP9zFsX828lfkoUyvXDceHU2POe533uqbqtEvgxwqqPyFtsrKHDnitobAU9acZ/axoHL5i tRpLICCEw/BTfoXSIIThvlkchNOSvUxiOvoV7E+JJpu7zy0+637J/Rc4nOYaAe7zszNalGSDCWMN WqZpPvEt9tsdp2k8ktsAPgi9sZSzKlaVgOKkE0HcE5VZ0kXKlDT2ymJsspKcBR0t4E/SZJlZhflY g8SaOMGk/1sFZd+KsIwr/7ZI13jzi6ZzzllBl/eSOxfe9m/M9YPiYKKt8Nnk+o6hXd8cnn2ptPej y1fmquNxm7EI4vfa3nd++iaLy3J17HQD+y7W6+8/d3AKzp9oHw/Zsfg0xlaKPVUZWalajiU14Sp7 kpOnSW+YVbbzH9/9QkBQpmyRKNOkSPy5rCsR5pvzMCdikYu9FuHaMLiTXo+PWLpe+F/4rWLpTW5M jiSlZErrNUFVqOMo7XLfxh73v9GlJO8igvQculSi9LgE7t2oH4F/DjzAq0FPOaq0812sHW0TItcs Q+KPfCNKCa55FQ7Xps+Rk1DwAuvmaIXHSaJb2DhhC2fNiTmrIirWz6i0Si0bqGVhwnN8z3h7NAmB RSKU7BIMxlq7S7YxlZdcCxdtYL72w9O2FrvCAQ2DuE1TH8aJWoIdwoiwzEblnbIoyDbsEqegUq+W B9PEoiRX5mXpQ7vtBmib87EFHY+3V2NwlS3fPiZ8ugEUHpZON5F3ZdcRlZ1XhaL7Z7bf4uGtrQua Y9EVboe7rtFpnjtnOjOvxmdQm6P+cNLA3NLeF188P5ts6XalL5teuDgJ8i3m4XuqdbvOq+ZCKCas P3NC/DnGS5OquTJeknk+XvKw7xGXiYxLTRmXmjIrnOwkTZSfjICpWUZASLyr5Gg8WJu0uqQ1onJk 1Gyrml0LC794A2OsVuu7KcTWwVdlXPazQbgFEf0OaNdCXxVUUANiRKvBn+0g0g+U39GXj9peLq+l Z1l7uYg1qVPVekKOerVY26QtP8bn6FGza9SfUovqeK22K8TWhzZDOS7uMDLq4TsKNCQ0y6zWfM6v s1BSl4TeoGZZMpnP8dEC7YNyfARU1Gpo+q5eDa7v6g7bEW6FhU7R0Enrs76s6HDUK8ZiFvZNXle/ aVXiQdvdMbVBC2On9GB+KD+a11jzB5is3AGE+VPzTy1HYkfi/zv6SuyX2ddVr0dfj72ZNTo6squz 19dtz46xMXFMGnWP+kcDo9U76sbqzWSZb4DTSk21IftCzY+jumrJ43LAk6ovHcjer7/f8KB8V/Su mNGRMaeyi7K9+YH8zembs7dbHovuzb8hvV5tSuuaQsIzYoiFWQP48QdYpiQ8A+cpfsVe6w35ngmE /GE/s/llfAAq9D0DSZxfqXE4ICE2qqxJHqlD7EdCfUNtE1xb4KX6b/X5vGTO4fI00IsVf+ZgzEFK SX8hnTPJpRiHyIPzEPySS9C6bFF8Sb+vPgy9sux4kg0mh5KjSUlONibF5CEmCzkm7ytryWJykP07 11E4TfqwZyLggxcbYFtROsOQJOWoEygH0UMs/RMfM4wHXWrATi1mNrrMZuOMmXx/2U4ejHrytDlj KY9kWazyZL2sNzfDVQPH6tWpdFi22TXasB3ME01aV40pDIUobUpdTdbxHLXT7ovs4T/Svmd7z/5R CvbwMAAhY/iVim+cjYvj0rjxAfNO907/zsDO6vtr7o2O15lAIIPxwu1E4Dm5IdoQ+0L2wdiDWXhO xo9T7CnZV9Sn4JRJMRRFAKxIpkqGIrY2U4rPUKxHVpYDrCNtcPJkkSkAEQndXh75ijGQBVBwBguD IhMimKFkvc7ys+AEg54FX09Mga8nQFZ20D0noZSAataiZDOjHTM94KTiMKMdM+oA4FuMgG8K+Hbg kwK8G7Lhw0oX5Yof3Pi/oqfJ6SiY/mMJ5J6JocFRVuCi61ZxZyRx06Xzlsvhga/89JktS6+NuKvM kUj1Q2u7V6yZ/k1d3YOfarkgb7c5TNLe6RfuunpR3axUun7+uoe33x8y+Nn8L375omL3ZTvbiis2 3VdltXix5rnO/FVsVz0HD02nKzgsHoSDTJiqQO4sLjOaOAvG5HYytZMnnXwhc87oTSHxLt8eIHGy rEDlNOqyVo8LpyfgGB8oVXQcPQ3XxW8fqfBpfz1jk3eOAeurAlsJjBAekqeTmTS+7Ruco4ovUk74 kFBcVGPIyIzWAHNf5WILoZNJzSkYimjbGGBqvj1Qc3aKmq+CanSQpKyQpaOnfP1DoiznczqD1efW vwy3COg4fWz16ikblEtWc4UNfEl8VtjBmNGBTlNxgA2IYkfwfvv9vmfdz3oO+N7waceDbIcfJle9 5gHTgPnvXvAi3N4kHOO5vT6/xChwBXYxyd1Y6a3UCBt9jalAnfa8BEV8orI2uAI/E4wk/cvCm6Kp viE4AQMfGGqrVOqYq8/JRnEsCtxsTzinnMecx50a52D1HuhPljcH3OoPjt+5W30sohB8nD5Rlueh 6ATD8ilw+gxCX1IfBNV/A9dOysPbO1mHtrTmOc0FU/gopGdgcbJFr7yST0Xm2JPR0a76lbX/0jpc V5VWPTf97/NOf7d/Tjq1dl1+YJ14ZcRz1YLEhjItJYK/cRpnpMbFxsq48iQ5HxGojah0ZpRTFblA hSKSuVcAbOhOlLUzZD+v6HdwGQTcr5UV9ZAo70eReJerEDliM9tPizeuMcoWryaYtcAsBLP4KVLS 0BkEaGccxV6pTMbDeTbNy7IHVm5n9TFKaoW2bL4g6QxG2ei1QFUcTy0/0lihi6EwAuqYDysm+0EI Ej+FhpbfQAuk36HTJWQ+9mQNZchyAr19h48+JMoaQ5Tg3H+HA07Jy2Izzv1HQHx/zvzPTBGDogPD kGvRgSLEJjmgFFiSdhZyklaIiaSq2dgabpMXhBfIar/O2Uu7z0hvKJ6M6pKsUxvSdcnGeBCu3bsV pwHWU1iU6BVZDEaD0RjhxlMWHA0G/zZDbBxeYFTwEwB1OYfPDx5uHzy5i6MIJpwSDTu5MvAw7BLP l82pzlJqUJjDXgDrDcmRKy4buC+xGa25sjJIoNpqr7b6q+GrIWALwsKa9OXIjAq2pYQXaQeQayUr qZmRCBU5bSFSGZ/YAyQL0jpYSIWTluk/1924rfuCTdnq1gWss78jc11PcZV09+mfj3PbqOdH5/Z/ cZTd35kLsPjpB0f7WhaL2gtbxTjJ7TBG38YYlcXnymN0v14v+B0a7pndDspcBohQpoAON+wc33qr A7Jw1oAPUNE0aPIa9AGdXl8TwX1GF2cAu5waO98D2h0akedghss8IdNzjmbO/cfT6MP/+ii4EvRZ 9Y4lhpXeS3wSsBwcCxbgNHFKWeMuuHwuf1RfY4jYZUfMK/tkf5u+aGiD6L3ga/Mv0i3Udxm6vd2+ hf6rdF/T3a//uv+BwHjNt4XHdLv1D/se9j8W+D4MhPYb9nuf9h3yHw5M1fzc+57hPe9H/rpxPfy1 kr7ZYDOPM03lOJQux7D44/nJZDmORsux3c5jRfFVN1trtgl0+sGQepv8afVt9rEafZuu2dAMC88f aqYiv/Br7zTs8N7hk1odC7yi0+sKOYWAHBIcBnsIs+B2Jav3+2Svz9eoN7jg6jXg98f0OqT4YYsq HYgypwOEk6Dx+4yQA2GBGjDAiWAMup37DS8b1IbtehhvXKHYFE3DLt1B3YtwsLtd79viJ1cJsqDH 77M6mvX0O6GQTnEpV6DoaVNB0E9hw3SAPbvfVsNG4bSyUovi/VZnc4RQqw865eQHmdCG/7T3dR8Q q/dd/9sU3+AFqVV2VokxT/gVHitJ/wFnBZW1JT7JQTzWFNDtUAwt//Ghn2HkPeApgwyXlEBebzyN WB8DxYztAugUMMKOKwZnUSeDUAGAjqA1icgJWBqRS0lS0XY6OTsmQU4mNZA+wTsHGX8k7WxvdTLt /vkrVTojXDNlml3R6unD6emDnlTYnpPujifkaOO0RjTPClr0ViOcydtD8079WVK3NNj0uvL++MwJ 9ZOYL1npaGW+JCIhu0XMksDFIugTXp0qFQ9rrBoa6B1wfQ2DytPH8AcZ7dlZAz+DWEG7CC96qynU 8RB7JSBQ8B0o9Cb0KiHFH74Vdp7CFriWMG6BdYOx/PRsti4Sqa+jyQNsSW11rO4gxVDeGHEXuZyG KAxHPT6kUt1R8CSxybTHk3L9QP1V+qH6N+Nvpt6Pv58yUYWSs8DrvRAIN0fq69PrW4I++HiO2upV hkQwkU0UE8uqHq161PtoQmeMt8Zak73CYnaBdqFufmxe8oLUBek7taO2UfuX4nem7kyP1j9gu5sq xw/bDsYPpp6tfyH+QuqX8V+mjtWHcZYdzD5VVfq4NqlPadKFqvNt59v71Bdrl3svTu8wjtnu9O7w 7YjeGb8zMVpfdYf+9qo7EpJZ389ust1kV2FW4HvG4wamxbywVdlDNjkaCclCOhsSrAZLyBr2hULY 2t8+SUqEB85sVxT4DJThW1KvjaVTrnQ6hfEQTzbq9C4cjQAKxeeOGeIugyEO7+GNXp/L6/WlE3Ag VEXHnRrwHQ6ztzCNQuytyTCz2unKJlhAn2AdtNmwiZcFkTJxyhGqYJp6D+Os2jjOrXlEsaYUdBa2 REb5lHWDAfuqfU9OCRvSUbKhcSuBhj4f2+Vjz/he8r0GvPeVWAMmeOBp2RqHfxLGTXlgOxI/zGxQ fXNjjpsUQ8NAgimJ0YQI32JvPanfnmzQHcJE14EANIDNxEZTJ+FsEV/1Kdya2oVjYK5QAn1pNppm JGuS0wrETlPpY2lterDuLOX0NqxHNvn8b58+AVuRTZXZjSw/MrDAeU/44ZCRgKY7KUnR+RBY4xDQ Ff9XTiOkIUhnhXE8QFpT5DSHIwSemMnJfBJq+O/nSGhtunYdnSEBjMEdVBGnDGslYYsEOTamzQmZ L4GiPV4Kkl/js5GLrk6Wqop4lydLbn61z11GHoRAyriDW3c4ncATZRUqjNAKKqlcs6hUxiRmNoqF +Mi/NnuTnnb25IIQrE2fcyWLLLIiPf1i+vfTf49Pvxqc1Q6MogpVh7On/8qeuKO9ygJ7dQlSaZf7 9DvsoxbZSWdkma869Sdx4emnJXFhHsw34sEFIH/+A3DMLOmdCt1oShi8zQlVnYCHNQDTPFnntImz kNgv1IXsZVQDoQLwzBQPyrIFWk7vcHQb2Jh5zDJmvyNxR/MrxleqXk2+mtdb6yHhMcZMUEk0vp7T VrfVW1e1qOo71B22DvusREeq2NzYttDYa+u1zwstTCxO9TQrbct9y+N9bVu0I8YR24h9xDNS9VXt uG3c/qj3cCJkUVttVrs1G7aF7eFs2pCuamgz2NqW6Ve19LXN6CXG0O+t0HukH3IjPP3VJ5q9BpVQ T78hVB8MFuvr28gUiaM06Ht00C/hOG2qHNJvejiB2QmuVrK5uWCAPk0eJIhW60s04xDjQtwx5mmA olIBpKnHFNzu6wPfqCG+MToCL7NjURb1xaHSmK97J51O5vvwtrcXWEGt1sZ9Wm2sEHcVCnGTJ5ls zJtc+bwJ6nRevakqn4z7jLMaEl6DZGrWFqywZQrjSzTU02fAIm6308pcr4LhZF0oFDSYQGY+tdHD PPUwuLNMyj4GamYKW8OC4pvwHfed9Kkog1Zk32GxRchDzeyKUqE+CYwwKeRZ/rD4HKzi2sQLJiNH uVnYajAhyClQBm77Zg5kWT2z4pIJPwQimH+riZji2xuafHD+By3EI1xlkRLM6yhub/C+Bcfw9I5x ohhetANWlquRY+OXtm1vIaXV2dpxohjkKNuP4HZb+xHdES0iHXLB/IDZFXeAMqPGaMSsMpC24vtP 62EiDl4D0m+Qd2nI9d5Q9NX2DjMEUx1YxN+YxAXFihO+7dQk29R6EbRQqg3vBOexdKShAoknnNxv LcZlKy36vyhZyfD4OKIcov1mFJh5DvEoEuBNJGB/HAfgPvJHTYRCyVGO7GWyIWAu2vAC7IAqMDRs cL6J03PAKHGTE2vCC1DFoAj02BQi7LdPKk53sUXnLqbgHj0NsOs8RRBNx5WAp5hW7AB3MUeAlquo dQDdPqOgSdjlH//+mS/CKRiqwgs4EVPxhVhFQqWzNAzUOT109l5Z1JQk5MSvaXPaSgYFAbY3HYka PZ09C2oSrKUp1rRs+4mlC4rTfXVQoL/9rq66uumfxwKJVVPfXXTReUBN1VXenK3myivX+d1BICZv zQ2PTh/Y2iTFYi6cc7r6yJFL7N6kGIupXcGbzpy6Fuq4mC0m2Ly+C9yUOytFBY2aqZWEm5MsGcS+ ATQMXBIRarLzJMyXfrtf5EmRkjmezCFZ3lJAP/st/OtoOEoc3I/RSPBSlhGCLrt4CxzlC7Cq1kRv oTasLhdkFc15PniJ8Pn16iPYHRLdw8UETY0TNmiGPSMEzrwv+M6cFPwQLRtsEISTOtgePdkIWjJf TYvO5nrP+pbPqm/TiHq92qHz6fz6jMuf0MccMXi8mMVwhmlgvuNK/ZWGq3yX+9cFrszerNtq2Oq7 yb85cHN2h2GH7z7hPv29/nsyh4Vjzb/XREGXZDLZ2loD4/S6j4j8bK5C5Cd0ss/vb6w1uFAhm8lw 8j5Ti1tq/XqVQYeD1/0+UBu6aIXQT2IcKRb0NtkQLQatzVAn8xHFEBgzsNcMJ0lsOmT4C8Sm2zv0 vfoBvaTfju2tRQlmXoF1g1Ueh7xibCDLGrIdWTHryzd/m1TISH0MjspPrN504jQOFsJqerqiNoaD yTLlVZ0+BF+9ccbb2dUbizchl//xoKdzCzTbRN6RsKp+MkHOKfKKSKuFRKzEb2lltOwmkia2x11X F3ntqF2rq8mw2njKq/dNf6Fl70WzF7c2RoopQ2h+rHP6aWvEZ6vKYxQng8nu6Rz7MJ1y6I1mkOze iKXj1PW33dmVrc17rHP6x8XJcH3UZINWF8ZvGmvrtRi/bvZtpcGhU3lV46px87jl26oDKu14FTNX bTE3tfQJEEe64cy2yuK0Xqa62Pqa6phVW9nxpphU5ZGsokVtgvDgU2rWpx6E/KDRpOmyss1WNmDd iNNoG0UDuE5AlDzAi8N/en9FbHGF92y2TneIGFwxJadWP2kIGVVwCxmTVC4JPgyNosrKTJYqM7Wi 6oMcpNEMtZgBcPihK2+wHhbnCBa4AZujZCVWP46fVd9nZo1mBS6yJLO/oaqjqhd6xqZ6+PmE/0uf p+ob5WUEOu8XvEvHz5Gv+ndXnwBLnE73I2t7Cmb6SN0EYA93x/YjXvDCQez+vRL1E/oHuwx8CpBe BwXLmWOKHpheakTAlVnMSFgVuop5SHf9V/s9RVXKRclfwP+xaggnLB44s3M/vGp43ZR8Y78bSStP 7rOeI8sqWLGf4dwSFoF2ITzCtkbcDEdXAulJlxpP/UIcnH55TbszoEppJOH0A+zCq3qqbEbmm/5D TKr1RXOLpuOnXo5m5Svo2+PTm46uev3NZQPW9r9juiNDEH70yi+6ZmKyqMIpJmO41vP6VID7tJHp bmGFTfho8/TFtrazJVRKf22aIqsWkZC6hNvAtr9I/I6wFFCPvOsRww2A8C9ikTxQCpDcCycB8LKI s7cFYS1gpfpHgk29XFiEOEqAe/Kq3wlpbVCoUf/ozO+Rt0A1TGlhAepFkR5F+RxcG6XnoNH3JWGh SjjzEeJ5eF4X4sV4Ri/S5wHMaLtdLJ5Zh7Qd6fNgGWdH2gToxn0fIO5CfbMUFNaj3IVrEWDH882I AwATnom5A1vJduGA8CFOFbiVvchOiSlxrXhKul61XHVc/YhmvfYx3eV62TDHcMx4qenz5scsLdZm 6/v2BY4fOm9w3ej6o+cNrwHsmm9V3x18Ra6JHIp6YrMS1ycvTT+fuTH7eL2jQWlcmTuUf70wq+VY UZzd1z5x3nfRKn27NuEdQcLxwPD+ia1Xg7Ac4qWfWJ3Io1ePA8Eq30UDYbKwfNUFnau6Mkuvum7D 8IUbbrp443Vrru9bcsFS1KTa+DsTEdaXU/8UtuFaQisG2NWZoJtmE+x4tlNwwat8FZ7tE2LYhiWF jJBFLxqFJvj1hFtKoSC0CK3CLKFT6BK6hXnCfGEB/EIsEnqExcIFwoXwWNInXCRcLCwRlgrL0PsV wkqhX1glXCJcCleswiFh6Zkp6T8mu7tzygHEmXoel1Lp3EEqKPmrc89I/yE+jqah1yW9VvIEeMlv SnPnVhIts8qJydq63GswtP6N8BeAKP1Geg0O5vldcAWVO9lpRgaTboW/EgavX7ukX+ME61/jzSjS q5OxRG78WelnKP+J9GO8I7rtxyWzPYcH/kh6Gu8iLO2XnqqUPDVpseeEzmEMDyZMITwGOA44CVAJ G6VHhRHAGGAvQCVYEYYBDYBeypH2SHvQz92434qwAbARMAZQCUul7yD/Ggqlx6SrcWRFWPoioW/E X5Du4vG3EPtx/TDyQ4i/gWuKxyvXDyKm8gcq+ffj2oPr+yrxvciHDoh0D64p/mrl+kZpC79vcyXe JQ2XQmFbZwjlMqARICF1N1J349XdjSsBIZM+K13Le7APcQ5PvK4c40VuL0Wi/Bttn6zy5XbhlW7H q9+ON7cdb247ae1J22bqbCvXqZO2oc421NmGOtvwVhqlYbQ3TEMZoQ0gAyS892G8d8qfQDgFOAaQ hM8h3AnYRVfSTXiPafRqh3R1KRXGYLtisqjkOg5Ll+NVK9Ll4A/mxs5d6Q00EC+f1FsqsZXqbuB1 N0zqTZS7YdIfLMeodU2nRVonfAogQuFwnRADNAO6ACppXSnWED4kXShcpxMUS3hEHJFGVCNqVWMX czwLJcU+oOUwHATUCe2okA4PtLPWQf2QflQv0eErjXpF36dXb5RGpDFJogNbOqReaUBSE82ubcsT zTRf05bfadxlnDBOGY8Z1ROaKc0xzXHNSY1a5ifY92kGNUOaUc1O2DzryXOOOGgcMo4aJRukHY1G xdhnVIe1bFfnbdJa/EwBoQ0wBNgJUOEdDyBfli4DDOBrDOC1XYZ8AaGAKxvgGNLHEatxZUU9K+pZ kWtFrhW5AkIq6QMMAoYAVAoDbIRUIgMaAccBJwEaQBKlFuRaBBH5FuQjBViEKzOuzLgyo9Yx8RR6 aEMoA/oAEs87jhRGDcKZssZK+SBijUDlJwHQRkFIZQpAgnXEmuRUmk3QKUdsZ5op7R2dOaUGAZwp DUQH4gOpgd2qjdGN8Y2pjbtVvdHeeG+qd7eqI9oR70h17FZBhh1vSDXsVoVxiEI4Fd6tGlu8d/Gz i19arBpYvHHxyGIJdiJTk6VMI/Z3iGviFD9V8vlzrdbO2eJe/JwBhOOA1wASnKvvFRoAHYCNAJW4 F2FYfAK5TyD3CaEXMABQ444ncL8VIZVTGeWPA9Q89RpS4j+US/jhj5fa8r2di4ByBwDjADgpRNgB oNrl1F6eP4HwOM/vRUj1dwGol4+fvQenJkirqB8Iw4AOwABgCKAWXpJWCK8B8GSEYcAQYC9AJa3C vxXSCvEJ/HtcfBxuxMxN7rCA0zAFMB90tk6baMIYMLPHeHgfD3fwsIOHMcWyyPzeIvP3F5lvX2RO IgFX8p244W4eRhRjp/nJTnNvpzndacbTqoQIyAY4iEWooZD9iYcX8jCruCLmDyLmv0XMf42Yvx4x b4qYz4vQfTjuF3e4eGikkN3Dw0U8TCjGsPmHYfOKsLk1bO40s4cY+gDnMRSGeBigkMG/RpdV0B9m 72AxNYus1J4OHxAFHrEzpfbO8AE2XWqfj+h0qf0hRB+W2u8Kf499APkdljT2Xil2ItzpZu+yhSq6 /lsl/isOE9+D65OIr0D8iNDO4oi/VWr/NNX/Ju5/ANcPCzU6uu8bQh+/fxxuySn/65X7vlbKrkWr D5ayW9HqA2D6Uu17S9kTyL2rlN2B6Cul7LWIxkpx6uDVpfbacKedwXW0SHXXQSxMPVlcaRFn0wnX 4np++ebuUpbu6qIGcBx1KdqEKEm9/B6LCn28uXApyn9kUIjyzsEGgXc6IMR5bGFW3nmzUMNjXSn6 aTxF82T8RPg/2w/TDxf+zqylh8K/+x5+33Jc/pYtLO0J/9tBel2l8EvZAyy+P/xi9HD4X2MH2PJS eCp7QIeCZ7MHRPZUeB9e8gTqimx/eG/2ivATUV66O4pSfOrx9rrwg9FV4fvjuC6FP539HnVDuA6/ eDmK+7Nzwovb94TngUeGYqUdjSmGcFv0hnAR2bMOsIWTe8JNsQPUlUY8Y8/+cC1aTIBvjq4saz0k FsA326JktZu1a7XLtRdpZ2vz2jq4+gtqq7UunUNn01l0Jni91sELH2RoOkHnIuZNhuhFlwYOBMC1 A9pmgoqnbUCNDBOQQmycdCLmDiS+PWLPkrlswtEj9CydO9Ga6TmgPXPxxCwo3+v6Llm5j7Ev9+Nq QrzzABOWrjzAzlDWbYEJBx3GwFjDbV+CygRj2277EgS7PRNT64SetfLEe0vwOwwXrZpQR+d6Bc+N MBN3zLEX53V9QjDIMwe7PsZKwkb+Y3/e4MQ9PUtWTnwn2D+Ro8SZYH/PxPwlMrZo4iZxY3fXQXGI ov6VB9kt4qbuiymf3dLVf7YanJ8MoRp2Coio2qRQQ9WEGjbJqy3mT8Mwrenu2leDgCo9zxZSJQyf 53mlK3gljPFN9Kw+ilBNDAkx/qyYGKJqGA/lh1k//jCTwKz8YVaTwB9WTZX2xeNoL4ugf+W+1jgq 7Iu38uI954qjvPgg6xeowkEhzvp5O4y3U35EqlwHo6BSR9Shzsde4v9/csPc/4dnsMk1v1q/rntD tHsw2r0BMDjxhRuv9E6MrpXlfet/RQXyhJQYXLvuSorXbJj4VXRD18T6aJe8bw2/75+K11HxmmjX PmFd99KV+9YpG7pKa5Q13dE1Xf2Tj4yc3/MPbe0429b5I5/Q1gg97Hxq6xF+3z+11UPFj1BbPdRW D7X1iPIIb6vn4rmsp2/lPp0wl9TVeDwpGg2YD4OBSP9cj21oDp8csyPeWwOHVAKWLWOmf8IUnTth BtC8qeus66QizE4qsiDbWiny3jo7EjjEHqsU2ZBtj87FfszbfVXX2f/Dw8ObCbZsySDcvIUKkcCk jcBiZt5Fq1ZOtE+0d08og139nAe7pfJ3/krF9mz7S+3ixvaR9rH28fa97eotW2BEozierXmpRhyo 2VgzUjNWM16zt0ZDBZeu3K+0j9f8pUbagtHENuOvm5pC04jxny43b0FnhocFNDIMyGSotcwWeGPr rBHWgdploMzrYLVeJ0QBecASgFr4AcJ/B/wO8DeASvgswrsA3wRMUo5UJ9V1e6/qohb7+aFXXik3 2VjIQUKUm1xzeTlesqocd19Yjts7c1DLzJU68oZOKwhvJhxC+BPAq4A/Aj4EqKWclOMPR5/pr39Y GIa8fcsW4ldvpmA4s5kR95rR6948DE42AQoYvgCJ5vnrxXXlT2DDWwS8CnwQRKjE84fpNrSBe2f+ hP8CUm2FjwplbmRzdHJlYW0KZW5kb2JqCjMxIDAgb2JqCjI5MzIzCmVuZG9iagozMiAwIG9iago8 PCAvVHlwZSAvRm9udERlc2NyaXB0b3IgL0FzY2VudCA4OTEgL0NhcEhlaWdodCA2NzAgL0Rlc2Nl bnQgLTIxNiAvRmxhZ3MgMzIKL0ZvbnRCQm94IFstNTY4IC0zMDcgMjAyOSAxMDA2XSAvRm9udE5h bWUgL1ZaTUFaRCtUaW1lc05ld1JvbWFuUFNNVCAvSXRhbGljQW5nbGUKMCAvU3RlbVYgMCAvTGVh ZGluZyA0MiAvTWF4V2lkdGggMjAwMCAvWEhlaWdodCA0NTQgL0ZvbnRGaWxlMiAzMCAwIFIgPj4K ZW5kb2JqCjMzIDAgb2JqClsgMjUwIDAgNDA4IDAgMCAwIDAgMTgwIDMzMyAzMzMgMCAwIDI1MCAz MzMgMjUwIDI3OCA1MDAgNTAwIDUwMCAwIDUwMCA1MDAKNTAwIDAgMCAwIDAgMCAwIDAgMCAwIDAg NzIyIDAgNjY3IDcyMiAwIDAgMCA3MjIgMzMzIDAgMCA2MTEgODg5IDcyMiA3MjIgNTU2CjcyMiA2 NjcgNTU2IDYxMSA3MjIgMCAwIDAgMCAwIDAgMCAwIDQ2OSAwIDAgNDQ0IDUwMCA0NDQgNTAwIDQ0 NCAzMzMgNTAwIDUwMAoyNzggMjc4IDUwMCAyNzggNzc4IDUwMCA1MDAgNTAwIDUwMCAzMzMgMzg5 IDI3OCA1MDAgNTAwIDcyMiA1MDAgNTAwIDQ0NCBdCmVuZG9iagoxMCAwIG9iago8PCAvVHlwZSAv Rm9udCAvU3VidHlwZSAvVHJ1ZVR5cGUgL0Jhc2VGb250IC9WWk1BWkQrVGltZXNOZXdSb21hblBT TVQgL0ZvbnREZXNjcmlwdG9yCjMyIDAgUiAvV2lkdGhzIDMzIDAgUiAvRmlyc3RDaGFyIDMyIC9M YXN0Q2hhciAxMjIgL0VuY29kaW5nIC9NYWNSb21hbkVuY29kaW5nCj4+CmVuZG9iagozNCAwIG9i ago8PCAvTGVuZ3RoIDM1IDAgUiAvTGVuZ3RoMSAxMDE0NCAvRmlsdGVyIC9GbGF0ZURlY29kZSA+ PgpzdHJlYW0KeAGtegl4FFW66Dmntt7SXdVbOukk1Z3urJ3QWchGAimyYQhISAImgUgHkhCQpWUH wUSIgAFRwpZxGZcR0fjdsSMKiSLGucs4jjiiI+NzG72DOjri1RGd+QZSef+phM07773vft+r6nPq bHXO///nX081wgghE+pGDFKWrGwN489IMrS8Aen1JRvWeeZ7OzIRwv2Q/toRXroyve2h0wgxexHi 6peu2NyhyPFbENJ9glDMUGd7a9uPv7sMfYkwHuV3QoO0wPg21N+Cur9z5bpNbyLbWqhfhHr/itVL Wrd1bHgPIR+8g25e2bopTB4iK6D+IdQ9q1pXti9p/O5bqF+GelJ49dp1LMsRmMoP9VXhNe3hj+/4 6CzUDwJMemjDcNPLhHgEcCIPap5o0Zq1jACu1y72WvH/WOJgNgHpoJ+uceUyICOsE4XM0GBBIpKQ 9UrXT542ZEcO5ETRyIVioC9W63ejOBSPEpAMUHpRIvIhihW9khDi7cgAND4LvRP5eNd4zi6B0XCN farlH10pq21jP9Dy/4+LokvT/+TCZ0na/2T8PxuL78M7cTduwBvxSrweL8MKXoKbIN8BtdXol9o7 R9GX2INjsBlj7MMSFtAlnITjsQ2zyAD1r2EU5TGEHtbyi3gK+p5o1EJ7oOUV9Ht0Hl1AKjYDn5xG S+EeQI+hRtSIE3AKLsI3oW9g9jgY+wAaRMMw5jV45wP0OfoW63Az3oB78UESRWaQZhjnwuX4HjKb XGL9SMAbiRUvZV7EFzGPHdiPXgR5ep+JjP0ZP4o+YTLJcbQJzULv4MlYYY4y6YxMzpKjCClTGgoL 8vMm5+ZkZwUnZWYE0tNSU5KT/L5Er0dOiI9zx8a4op0Ou80qiRZzlMlo0OsEnmMZglEGjrjKGwdj hIDb6/U2ZU7UY2+sR5gk8a/eCLLeMMh946DBuJ/U439ST7havzmC7JEqX3kFnXgQVX0eQbYItkcQ XQXbZsNKE5BUti33VS6LxJS3hULwRoVP9ESqvg1OgKIBPGg0lPvK2w2ZGWjQYISiEUowNjyIq6Zh rUCqKqcMEqSLysyIWAMRklRJ0/KIsicEBV8FoA49tms9Q2Mje6/vQvDa+CAEw7QSjvDlEUFb17Ms orRG0B7PYMZI794hES0OBUxtvrbWhY0RphWIOoiYpMrOBqjBypBCnZ4IC+tqmRtaPJWdnl6o02Eh yH0V8NY/bYdmfXnjLu+IO2KFZ2VECkRmwJsztpx3M72VrmUeWu3t3eWJPDq38fpeLx3T1NTkyszw 9Fb6YKGKzIzK5WVAaVcwM4OSAF8hTVtoOYVleSuFs3K5p3dPuwbrXg02bWhlJ2xM6/9rVG9vZZuv sq21jS4Ds5dHlAbtgRqaKTk8lUC6iqaJpokB0MNqPaGKJqA1BaymrrEceit9rRXAg5RPr7aEJlqg ofJKp4fCWR1RQhHPEk8E1TX64OVCmrUXot4lhZSPYRqcmVFTe+2tCJck+jy9P6AIDvkufE0hvtbS OtHCJ4k/INpZ5asK9fZW+TxVvaHe1qGx7sU+j+jrHayp6Q1XhmDV2sYIhvYX97gjVXubImKoE08B 2lMOqKprLHV7JcBjvFp7pYqApYCxgIUBHaAC/KonHrAXqKHR6ymPoHmNTW4gZCMtN0B5/EkZCRi3 EPZ4gmyURu0UWViIlieKXi/lzj1DCloM+x7pnts4Xvegxe7nkBIMwH6EaM/IlR7HPNrTfaXn6ush H2zO85qpdER0yVd/FtFpq+ycEsHO/0t3+3h/xFbeyLgJZXgoETdDS4YASHpJJDoA5dRAL2zLW76I GIhwjSPukiaPKIEGoLtX76uZ29zoqey9ygXjLROYUj4AVve1dvZOiBhlelAFZYM+vHvuoIJ31zc3 Dotg8Xc3ND5HMCkPlTU1gesCuhGB8ebBQYCH/SRPWERT8MxHZ7QsO8sreaUkyDCM+kc3hy7RJ4IC vTB6VW1jjoM9dqASJWMOriE1/BxhEV4krMaryWp+tdCFu0gX3yWYBYTdOgulomWEfcEpXryQG2zJ RaWl2Vm4BXuTiSRaC7wOMxZ44rBboxNwNHNc3TUyPDyCN889UFpSUz2t5Eit2vYp/hC74f7w0/jq 4a0b1Y+feEb9auuGV2dQeJ4EePqvwFNBFEaxVdhrmVpbiISYkC1kD5MwE7aF7WYrYt2QMMsaR9CJ aPHHG+ARieDNm4YL8q15k0nKJJyS53Vamf7hEXVXbX/xtOqaktIDc/HmkWFSon6m+j+NnzGycSt2 PvMETty4dbg6/lOV+isY3aGeYn8N8DAoX7EwCON/JYydEAb8NDI09mfFrBcLkItmdDcIUCQYCKDS YHbWLm5SYNe2f9NjL2Z/ffkL9Qzj5O1/f0popCPBV0J8AnhAAnhCv1TqeKLXG3QE3wUNegPDbuc4 voAvFGr4CmEB3yCs5BcLd/K3CwZEdIQ5EDZgAzLoMQsWcguPeYbDhGF5Qac36DkD4sCNHBr7o2I1 iAWcFzJkMWFkkk2YC7ZIuS0AYos1uggFS+kj2HKhqKi8oVHRz0azuW1oG8e2NOGWXeLoyMiIlutG oPv5Uv1sPUEtTWmY8TJe7DUSPkFdu3T0vaXqNpKMXwycPIkz1Xe4s5dXEufoV4AmUA38VG4I8HSA /5eLmpXiGnsjaXAsI22OsCkctcans1kzDqIEMYGEEp5NIAkJQvwBHZN5QHDeac2wWISkbWgoLyGj S3hhsvjjaA6wnbUoaC26gIIXSmmx5XaAPjurBdt5wYx9wOk5TuA9B1QdCRhPTobND2ApNye/YBq2 3Vjlhm6Z1fjO46MbSNnzx+rm1a/p7HtGtScF07fd7i9Z0J002XNrQVnmz+c3xD2+t7gkE7+2YqCw rJA760oL7G9ZcXSSLv4E/l3STKvIqP/OS9HVo2/PmG2LIuq9JCamnuKP0dKxP3GruG8A953DKDDW czxKLHAMjT+lobFfKfP0poLgNMh08a54H5PMpumC+mC8z9dEmthbDE1x8/3rmS16S9BWaltt67Kx NlvsfhPryczKDGWGM9nMzOT9yGbLHMpDeXPyFuUxnm38yclAphbxxxxUSoVCy4BEgQAOBLhEf0oy yZtsLcj35wKpnM5oyZecnJKc7EvkBZ532GkbJVd+fkGuxNM2ZtGT6hft7auXt7dieeDWI0r5yrSM uHn5Bd3Vc/umFVfPKZl6uLrqninZDe7Uwo7C6u74xa2tOPH0IPYsXbLCIdmCdvWIq8zjycgtLjq1 c++p/IJguj++zKU+FJMhOpwgD8An/FTgEzNEDSVKepN1nrudLI/aQDZH8c4+HRPdJ1i2GdAWGDok y7Ii18pMNDBFAsh9i3ixZZwfND4gAs9qfMBGO63cjTvOTz29f6V6+bnR70ncCaxrfmBQXXvbuuI7 tra23tM9ddli8sVb6snGssnc2amFt6qvvnvgbHG84/LCGG/Jb8b3E+BkvwQ49ahMsXP7s4hCQqAN iID36xiBYUDuRhRJHwX6wBg0zjESwgGUBsq6IHnBQG4QpE7j2wugN6ly1m72y9F6csfo3ep2NsAO qn9RPxntgVUwpQv7LZQ45FPsIOP7Qf+GUBgkCwlsF36BB/xh3hYqDtlZaZhOx3576U3cTZ7jzl6a Q3mQ0vYPMIcJvTCMGICvDJiQVSAzGt3GgJFBepPBYhT1cQbZmMxksEFD0FhsKDbO0Vcbthh79L3G g/ojhgeN9nxDkwHMAccaKJpxZmsB120SCwjNOGJg9EG2lA2xYZZl6QAXNLNGxDKCnhGMeo50oRNm ZMYcdJ4EncltF16IAgQCwKsXpCKqkKg+0pRTdlYAtBRuAa4FrECJUsxAmfJ/ULerX6t/g3QYn8Zz 8M34NPPZ6Gay67KbOzvqIH/R5I7irNP26ZRSPYcoArmPdAuEJ05CEC/yHn4GruY3CTwimRjzRNBh wjI8w/j4LAjH6nEIh/FGYH5MBAVAFbrRCaMR4D4BZENGDMpfQ4F0s3R3AYUA7HEAkICtoFhQhRoT IH6hmEwWagiocQJqnCwWukhYMLU0AavCkIgEHo9iFDAh23nBDtK2S7MaTaCAUcvta7zjeAPyvE7d N7pbfRT/lsg4xKiXCSjaZ5h5IBBLxz7lO7hvIWL3oUolJ4VLE9KMYRwGzusyCo4+gz5Wn65n9Ky3 j2McTBLDMDYLqNWk0iTsBm3h17TFxQuotOUC/KgQicjrQZKW42k4TxMiqh/MoFipegX9wHeonWq/ +jO1E/fjpbgDP6AyhfnTcnLvvqn6rvyc0qk5OTtnztxJ/qw+pLbgX+A2GPSYumjUUzG8beepKSX5 k0sK/3373S8VFxcWUdnSdAC3B/ZMhHOBGUpMvdhhWc8yMX2CoHf1AXNJ26agmVQBaCJmAhHzyl7F S2KELv0LHvHihIhRXaCJmIaJZhbAAAD3aIbhJwqB21M1vemDX/yX2k027fvXmuZF6tqKzJI1i8pW Le4KJHmZS22vTG9sVoG1srOLh3pLF1hdnFrm8nuarsLMNwLMZoB5s1JnEmPFDHGqOFtcKM6LqY1d IXbEdolGSbzLIlty5XJ5rczIDt2BUmmO1CUxkmQXDjgYiz0s47AFo21xcpzdYvF6KFo6a5cd0JrQ HNaiouCFFmCu3An1YS1qAQ1C7TO4XzdqOZAW31WEqSVk8aTClM7KPRsWbk1PTSK3qAF1+aC6nfT0 nK5vWPKzfay+sDZaFNTVVo9cczmfJI5+zJ1NyMl5ZNPRtyoBUYxWjn3GdXBfgx07NYwSx7oVM8iB rhsyLkFvLpCHxv5TqYKC0eV25eMp7ko80z03t12/Qb/etil6Y7aJJ7BzUmyAjWdKwXnwJh2IZz1C lhAWGEEwHmBsnsC2WGmbJ1bbXj1MhVAetWSfU7VZVHQheCF4nTmTrogYG7AHpkh5gZlSZaBZmhe4 TWoP3CGtC4CIUadFCEQHiCZtmvXDduQFAyjlOtlxj2CctcFHyJuMvDkstYVwJHGN0YHXuQ51jzoy rF7YlL4Rp+z2rfFnFNXXNrxUd+ooHNokHcDysrRm9dLurEUZKYXN2+qO3PLML/DvP1QvTM/B7Ys6 TGZrfl72DJvd55569sG3sFAUUJ++qTXKapmaUlwaK3niCl+lvIQRnC5xNcBLAspQYjG7H7QRWoC7 uAVd1MvV60S9ou/SMy0SdXvOj54HNh+F05QrVoSrUYNqtxrkEtnBS3NYML4w59Njn3LnYE4JFSpJ ksCY+vKYSmY9VQFiV7d0v0QkyabYsK4LCfcJj8BmgDtILRVIEVUHuTC/pgZiYBk79QvyJC93To2o w3AP4u3b++6/G28nbtDH7+NkbGNOXl70YH/fY8xjgBNB88f+kz3J7oAzxCzUocywuLiMGFc1Vx3X xDXF3cYts9wWtyFpTVo4Mwp/J8sBZ4oSZSlISfEdC4hRx5zOLBln9QRfzAnmYEuqnEpSU4WemJey QeEChGA1RnNyqLADHYIBShZN5PMgBrlOUUVrVV9ict5kcGr8BbDldId9EjhAHtYheZm66oGM/CKT K1qpyF+dHj8/OW9NxaPvrWpvw6mP9B9sej3DW4TxXTgXS+qDOOkr3mGWpuf5Mux2W0avc5rVFf0f D9zxEDhier5lRqmELZa0l18fZTX8B8a+4qZB/CCCX1Oo+CtxZfwtlg5LF9cVw9sPm0U9cvczTp20 A52S+Whjj24YPBrAClSyhljphDoG8FME0GHSNNC9VpB3ioKkKWJumvrBB7fuUyzqMdxZ/y+3v/u5 em/HjtwV2SlV2fftJdPBVj6XmlzI20ffL6tTz6h/Ofy4HD/6htnwFPBHI+zP7ex2lIJ2K74splRf HJPtVphKdpZuln5WTIW7Rl4g3yZv9ZiTPWDN7UNj56gLax4a+0RxQINIjWOWiEUx+ohJLPVjP9XO MjT6/fFHkFNEftHf5Wf8wTTsTwul4dgd/Eup1ODQOITGj7CTgXEXNTBu8zlAlcojddiphyr5IHyb hAFhsD3jUguOqRmT7w9839y0eNmtC77pXvurhlxHcSBt8fT7H3ykr2KlP3GyM3fecEJVdfXHhx4+ XzOjLCdVPWPNinbGn3z48adkhz3DoZ5JDWp71Dz2KfsN7JENedA0JXWmYWbs7SLjSQc8GQ+woxW5 jphFnHCYc0p20oNeTHTv0L3kBSTGGbD0AmVBCnxLGgbm8yUS6Rr0YMGvA579Ru1veXz5mR/rb6r4 VWv7XRUYjGhyg2/fvjV3Zq9aP+smXIJN9300p6Y+4MUfX0okKaJ58OGjh5JAluheXWZ3QiwVh1Yp 9X4SMOSSEkM5mc3NNpSbZ4nN3ALDPPcy/jZ9yB6KXkc269eZ19nt+Lu4OFPMMauIdKKuXrdEt1bH 6XRsv8mp1zt70KmEYAKOwz2Wl+I1YwN4gZc6ETlckSmvxmoa3X1XPAMpSUNMYC9ffk03/Pyac9NS t7y3Q/2l2o/n4TRsxXb1AWZ5uHOnDv9Xz966oPrH7AycBQfbTlwJLu7lebevWbEReDAAgeJ2PgFi YkWBqJvtd2CjznxMskQZ4DNBrCVWjiU6i04y9VgWRa2OIlHANxD0BWksGyzSHOqiIqoCQFcBrwCj xGOvgwqLLy8X+IgyEbPd7ZqdsbwGO9Uf1f4HHvjg49rtOZxJsM5aqb94eT+z+qL85ptG/Tg/qE3s NyATyWDt5imFNztvzrw5t8XZkrvMuTx3m26Lab1vS67R4XcFjnjFZEv2YZfBYD7Cx+n1bn+KA/gj b9IO90sQrl6gPkkOkBBR6MBDp6abBqtJ48EqMLqUO07YaXgqnLT7EtE1zin4Kec0z5372f3r/1Sf UXa6pm2bV46b/vPWr8fQzTPKXm1fcGhqFG5R++Vm/759mzfmd9718/emTiuIs+OY2EBSoqetygHH IXE4cc/rNVU3B5JzLo/h0SjLL/oe706kevpRyOK0cw4BZSte7ufjTjID/rEFsw+jHu5hhEVMcK0+ pA+DEbpigTSHkcYdBUBwYoW97zSoPXgru+RRLAE5YX8HYG6rNne8YiXQ0DMxFRfiwhydiuq68ehl fAYYPP6ecA72IRXdqkxnnUycIy7Vdcz5pPuk84Rbl3woVpSiZcKa9YfsosViTuiRB6JxD5GieswD iIgErvQ0lJ6VXpseTmfHzSZsiHihSFOusBnRReP6FVjlqotLHSfHuObRcjAQVzvZi+phndVaXZbX lkoxbRlYunoga8Ubi0+8rB4WrNLM8sz5TNzl8yS7bq3f7w24Lp9nl2ytrlsSWtD5/pnRJJJdvwba 4bPXBH6cFfBzgmXwYYfNUSKFHSwWo3SHbKLZEoWBlVxZrpCLiMaeqGE44gIPF7gKiHWFkbwabOOx uwZ4PuV2B2dVD5sl++zK7PZiCmdocMWJMySzYpcHWMGnAVVT+/t3YN8bxz7ikkGn0NjBq1gd/XrR CwbJAvYoyQ2q2q9xMfgCcNpyxRWYiAvy4WvOPzk34JLVl9UP4X4ZV+JEcAmmq5U+n9/jaZ48eW6S NwW+9zQVZTeRbFABr+JS+IYUjaepI6PvBzbftmRnalpiXHrK7qULd6Wl+L2UTgQNqG3cNKAT1c+l SqCCVFgqPHWWOlu7pc22WdcVp48+LIkmS8IR3ml02wH0RLNb32Ma9o6bUqAYEAx+2vEAPdCg1vQq ua5aU+3Yg5s2r/KmE52hnVWUcGBO3/5SvTe8Gcypvy6VmtM952feXJuWpGZwY+vBnr6hfv3EQbCn vzXrjgGszWqbpjsorMVKCrUlsz0LPLd5wuIWj0DtiNVCDQl232BKJlTFdXB6wcLdYEj+mzpQ+xuf WvbmD5ohWXTXTZr4X7UkahsxzKi6ZkxA4N+5Zks0mWTeY5fCV93Ck9gUNsF5phayR8NpIXvIYjFa 9PB91B60Y5PQox+2abwH6hYgLB0NUFXbMqFrhesEhnnPE92ROHtDBaXdxshMW5aVMel0dteoyC45 2lEOsTfI9SKwt1tgP7PQdkXMCVa7ZgTX483Gze71PgECiU8UrxnCCg9kxRLokNhUiBlqIWagrgYE DsfiRYE6GTYalgvmY4zTm7ojVtrhjRW02MGgxQ454RwMviyAHACdezV6CIz7GzR8gPCJnjDYWa+m h+EgTGOAcaZOSQZ30U9DRno6Nu57QD/82C3qa+p3hy/O9LpnTC/cN3d5R0lD6j2FPzsI/qHhzi+m y7Vnlt2yMb+toEvZtxu3/fLdwkScasuMjfYGJ6UlSXqHJfXpOx//Q268er6gMisjNd1hdIhJjwBd AmNfMZu4J5AbzVQyDJybIxZj2EiMYpRwzGiwuN3RgKtZgZEo3hKPdVFij0G3WqBo5uaCgdHcdvCo oFiqGUjAsCWJslFyHjWF2kZRL348gC/IZTZN2X7r22cOHsSdeK76LLGYZ1TELbAmGCzSwJsk6iKI 7isX1TXFjT5fmgtMMaz8GMQTevhC7wRPKc3Ax/KzbAtsK2xdwhabQByc3iIdAubWvKRx1UVdWno4 rznrmks7bgInPCWA7DqIILTQq/1tT6598Td4udFum105KTwZd26dNefcWfLB6Dvzbk9KSkz0MvTL NUYJoBeiARYB3auU6riZXCPTxHUwHDRw8OX4GTwM9moXPat/QjghEGEnz/FGRuBccAQS4AqZ5dwd BM5WuXW8EY5z/qj49JYC3gsZQVweX8kT3sKxbkL0Qf0cOPmGUyPCQ9ShSQE9OqemHE5U6Ul5Cz0o bxnRwY1b6JG/14a95ChGeM3o/eqW59QavAXfS879A+Mn2AV0BxFH7htdlbV6kaXkB+Qe/y/Cr8+9 VwE9SHu61CbhHHhFGM4aQWy0C97TGdU6hMyFl46OeaOoB3/jlayDJnIKpLkJvQrpSa4H3cHnIxfv Qqe519FS/gl4ToYUg04Lh9Bp/j8gnUFLuY/gWQbtz6KV3DqUxnehp7lGNJ/rRwPsC6gRns1cLWpk WlGAlmGNRyEN6DaiAe44pDu1MQO0j/kHvPMKWsQchbHH0WNcHvwTBCEP3J0ogj7Etfgt0kaGyLeM ldnLEraDHeEmc58DhWv5twSP8Ljwo26xbkDv19fpV+k/NngMawyvGeOMzcbPTYWmO00fwmwU82R0 K5yEdsLpKIEIS0HzwFxweAm00V4M2o0+4SgQbAdqnFNWNX92YH77mrbWVa2ZZatXtNG+CdqOrUfv 0Op/u+g/hhjt3zBW+IaRBGumQKQeBO2VjXLAQ8xD+agAFaIKVImq0Ax0E6qGU6pZaA6qRXNRHapH DQDXfHQL/P9iIUKKvuHPX/jlLz6XQNWNKG3nTGK+8r/wH/ok+QykNyD9FtLrkH4D6VVITz/olx+C 9MCDHvlnD6bKD/a55e/6HfKx/hj5SH+6fLg/ST4EZaUf98Nwy1/xwb4Y+UBfQN7fB75GH6YLLewz ivmWU/Kp4Ckm+BJGw+IwsQxh9AL2/L3r70T8m+dvyt+Yrh+weNFzkXi+qf2GBL8u/XrO10zWu+F3 yfHnUuXnjkty8Hjp8VAkHAn/nvvsvF/+E6TgebrA8V8BInShseeh8HbXJPkspLe6PPLvuiR5BNIr kO47PXaaWF7GYy/jwWclOfwsFp/yPEX23JMl994TlO/pypV397jkXZB29lTLd/dI8o6eKXIPTLN6 4NGByMC3A6zyGBYXehYqC5nvYcbtXS75rq6Zcjc874QVt0Gq7Qp1hbsY0eKVnY50WeC9cowrXWYZ r2yzpssZmZb0gDk1zZKcYvYnWRJ9Zo/XkiCb3XHxUa6Y2CiHMzrKarNHWUTJZIoym/QGowm+rZkY ljMhTEyipdtCFL6bh8+T3QyxoFLY7C7EWoArSpESvxoqr6DfoTGkcxfrZMsUncwU6WRUqJNrc3HE WoNqGsoiNgzP+rJIbqBmSIfqIjmBmoi+dkHjIMb7mqA1QnbD9jRE2N1DBB7W8uYFjUM4hnbfrf2t AkpDuPvue+91Xy01NQXiI2019Y2RcHxTJIcW7o9vQnCSHli7bu3atbTwz65BPV29ra5s8EuW/umi NfKlr2Lwqy+1P2BEvvJV4IlXr58DpoNJr0wHBfq77kKB9dC5NrDuypCrT+0lEKv/Dejav+QKZW5k c3RyZWFtCmVuZG9iagozNSAwIG9iago3NTY4CmVuZG9iagozNiAwIG9iago8PCAvVHlwZSAvRm9u dERlc2NyaXB0b3IgL0FzY2VudCAxMDA1IC9DYXBIZWlnaHQgNzM1IC9EZXNjZW50IC0yMTAgL0Zs YWdzCjMyIC9Gb250QkJveCBbLTU0NCAtMzAzIDE3MDcgMTAxNF0gL0ZvbnROYW1lIC9YT0JGVk0r VmVyZGFuYS1Cb2xkIC9JdGFsaWNBbmdsZQowIC9TdGVtViAwIC9NYXhXaWR0aCAxNzc3IC9YSGVp Z2h0IDU1NyAvRm9udEZpbGUyIDM0IDAgUiA+PgplbmRvYmoKMzcgMCBvYmoKWyAzNDIgMCAwIDAg MCAwIDAgMCA1NDMgNTQzIDAgMCAwIDAgMCA2ODkgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAw IDAgMAowIDc3NiA3NjIgNzI0IDgzMCAwIDY1MCAwIDAgMCAwIDAgNjM3IDk0OCA4NDcgODUwIDcz MyAwIDc4MiA3MTAgNjgyIDgxMiAwCjAgMCAwIDAgMCAwIDAgMCAwIDAgNjY4IDY5OSA1ODggNjk5 IDY2NCA0MjIgNjk5IDAgMzQyIDAgMCAzNDIgMTA1OCA3MTIgNjg3CjY5OSA2OTkgNDk3IDU5MyA0 NTYgNzEyIDAgMCAwIDY1MSBdCmVuZG9iago4IDAgb2JqCjw8IC9UeXBlIC9Gb250IC9TdWJ0eXBl IC9UcnVlVHlwZSAvQmFzZUZvbnQgL1hPQkZWTStWZXJkYW5hLUJvbGQgL0ZvbnREZXNjcmlwdG9y CjM2IDAgUiAvV2lkdGhzIDM3IDAgUiAvRmlyc3RDaGFyIDMyIC9MYXN0Q2hhciAxMjEgL0VuY29k aW5nIC9NYWNSb21hbkVuY29kaW5nCj4+CmVuZG9iagozOCAwIG9iago8PCAvTGVuZ3RoIDM5IDAg UiAvTGVuZ3RoMSAyODc2IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+CnN0cmVhbQp4AZ1VfVBU1xU/ 9777lgV3eQu8BWUDb9cVqC4UXXZXqZB9IAvo0gkiMGBDZBHiDoKsQhAbpxInqGyMYhI/xqSpsW3S pJ1kXSguBiNKQzRprE6bTPqRqfYrZqYmZsbkjyhsz3uApYl/9e6ee8/5nftxPt69BwgA6KAXOJA3 tvsCUAqvIvJbpN0bu7vMFSeLKACpRDr2aGBT+/hO/xUAegPl+k1tOx4NX37wCAArAeBEf4uv+atN W44DxNThepcfgaSVmnqUB1Be5G/v6pH2ce+hPITy/LaOjT76C8pQVs6Lb/f1BHg99zeU/4KyeYuv veXThds3oXxXkQMdnV2PVbR/CaB9AOWCwLaWwI6Wj6Io43n074gR/ClNBxroxtEMrhlEhf/vDmNw r3GAFt+38QCadI3I3+Kvsp2sgfsYDADRT6LXp3qmmqfquedAwnVH4DUYgQm4fG+PUbig8t0QhjHA +MxpT8Bz8DLm40/w+T30GLwIv4TQPVlhBkBBf4bZex0G4QyMI7YPDiH6c/jVnJkdsBcOwvNwAn5P 0mbwcSqSaQs+BR29SjrJAUiFbCiBh6ETfgR70K6LpAKxQsQqEd0GPfAMoiNwcc7es2wh1EIDtMIW OIUzzqvwElxbDc2IKth02wo/hH54CV6BN6ED+b1oL34932pPUAu1QBf8E1e+Sw7TCfToFejTiBAH wF9Vosoa1NhC9DrAVHMUvxGuid6mJ+kheIO2QoUcX1O93JWZISUl6nU8o9nmEJfhsXqsPn/Q7PGb g9aSxpKcbG9VnafEZLHU52SbES4xh0ij2RMq7fbPD3qUCaFEW4hmeBRqDclPNSJjLbFYLKhJ+q8m Eh3bP0d1CvAsf3WdcqRCjX5ziOE6tTMhMmOBovM3Ym8tQQPui/+PiaXW0sZgsNRqLg02Bn2RaG+T 1WywBk95vcGAp9Ecgsq6EEH8zFOmUOn++pCh0U++h54pRpRW1blNlgQ8x7vO6l27vs7sCTbOuD6D rJgOxCkKxWgNXVVdN1eBSiVOSrKoculi8MrhKxID4mkN3mmFct//+H21W7bUkmBJyMCO4Kyve3m4 o4yAjNI45SvibZhJIyyCPOiX7bzOqMvS1dBa464FmsSEbEd6ekyaQ8vlOGK0ycbEbCFTr9fUCGad DnshJsMIkeg/hhQMmRuyQcFhq1Nwyk6ani3GRKJfqFqFGVaUMW0Ow1c226S9QRluJubn2myJ+TfB fdOtCDfz85ctJQ1E1MRoNFY03J6ckpxsRNGYnEwcmVmZmVYroq7lLlfStKhMUkTeVl1Wfen5yVtk 5Kcn11StaVt/9PWpwUXfyd2z8d8EGrbk5mbtcpUt7W+aukQ0u192rnCQdzteW168gr86P9O295HW wzla6T3KXGtSTPqpqqT09A2Tx9e3ZiwQJj80LcpqVl45JV4rMV7z4GE5h3OC1qClWi0fF8MRXhtL RRDUUCSpYejRC3pZX6nntJzIR6KfqYFQGDUQfJtuTiAm7eAucBdgBLbexKyhiwnWhDzs8/iVE5ML JiboJxP0j5NZ/NXJCC3H3BG8wUA/UG35rrwgltk1XBxnJ1p9e5x23vo4kePpeq4dz7htN0wi/Qvc k3b84+4WZ16C1Wkx4gn0g8mh8XFaMT5+jL107NidDcp3QSAcvc4vxr3T0M88a6J1fiFXGFvBVcRu T9qeon1AzxkdmjgTvgOqu3Gqu92SIEmSLHGCqItEb6veKozqrW5zuprv6awr2S5YtnQ2zQuVtDrR XVFJdp6aTRT5xWVrv3+5f/+VsrVlE5as7KOtm4/kZFkmaO3JLyorSteUV914lXv87uM79ucXFRcV 5z/bzgXVqkM78xaev/vWBqHgSzBpFY/gnQ8/wlo5M/ZHr6u3BiAWZisMXiXtvKkqLGHZ0eN3/jDv WXUnZcls02gRoliF+Z1wUYN3h3sE+vk/42sMYMZfBKZINgmipFxLDTTh/doMPJ5ggFx8mYEdxlrJ qVoCieqozIsHqCuqr/KustW2bGv2bfHN2hStwNf+fg0vPKGEI4zwRMN3BnwbW0gxKSerSc0IVEfH 5PTwYrvLEDaH5XBlOBDuDZ8Ih8JXwtfCcWPhW2GKz6Qc+HXKfJdUQoRaqZY+VLOhhnZUk59Uv1FN 165LYVXrktm6KiNbs7qKla5ezspW21k50mpnPitw21mhu5A96LawVe40VuyuYkVIMpLbaWf2vGaW 53Qwp6OaOZzp7IrjmuOWg8PvfnAoo9wViV4bHDJYcfxM1g/FCq6h1HLWPbhnEM26NTiozvhajg7G LnINiuWsf18SC7QFeqjwwl9fpPKPkxe45BeSTS75aApyR1JMrj19SZLwpNAnHBAOCgPSk9IB6WDu gd6+3n0HDw30Dewd2CfIu2MNLmGbtI3KW2N1LqGdmC8S8zvEPfH5BDW/Lb9NoYlAk6GJyr4TPir8 gOSICSxbzGA2MZ8tEZPYYtHIJDGdWcyrmFksYJdSPSzVVMZMqQUsVbQzI85LQnMTxVSWgBQQiSwW rXIJ8Usk0BD9uFfSXfBKcWNeKRaJH/VK7KxX4ka8Ej3jlciwV4LTXmn8whJp7NwS6axcO2qRzoxY pNPDFunC+G/058bO60fPvqUbOfOmbvh0RGcY7R2l8kjvCBWG3cMPDe8aZsJwLrIdyJ4b/t1wdFgb F7uc6fQUyy5HsVbQSp5ESLTv6afTQkew4oZ60+ojWvBigSQhcqA+pPWum2HBprTOrs5OlflGF+I8 IY3H7wtprCWdihCvCPFYWOM9IUHhBWuJjYREjz8kIvetTTpnG6qmldMHqTw89o3jVFGxpQststng PyLxu9AKZW5kc3RyZWFtCmVuZG9iagozOSAwIG9iagoyMTI0CmVuZG9iago0MCAwIG9iago8PCAv VHlwZSAvRm9udERlc2NyaXB0b3IgL0FzY2VudCAxMDA1IC9DYXBIZWlnaHQgNzM1IC9EZXNjZW50 IC0yMTAgL0ZsYWdzCjMyIC9Gb250QkJveCBbLTUwIC0yMDcgMTQ0NyAxMDAwXSAvRm9udE5hbWUg L1hBWVJLQytWZXJkYW5hIC9JdGFsaWNBbmdsZSAwCi9TdGVtViAwIC9NYXhXaWR0aCAxNTIxIC9Y SGVpZ2h0IDU1MyAvRm9udEZpbGUyIDM4IDAgUiA+PgplbmRvYmoKNDEgMCBvYmoKWyAzNTIgMCAw IDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAg MCAwIDAgNjg2CjAgMCAwIDAgMCA3NTEgNDIxIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCA3MzIgXQpl bmRvYmoKOSAwIG9iago8PCAvVHlwZSAvRm9udCAvU3VidHlwZSAvVHJ1ZVR5cGUgL0Jhc2VGb250 IC9YQVlSS0MrVmVyZGFuYSAvRm9udERlc2NyaXB0b3IKNDAgMCBSIC9XaWR0aHMgNDEgMCBSIC9G aXJzdENoYXIgMzIgL0xhc3RDaGFyIDg1IC9FbmNvZGluZyAvTWFjUm9tYW5FbmNvZGluZwo+Pgpl bmRvYmoKMSAwIG9iago8PCAvVGl0bGUgKFJQTC1NVVNULnhsc3gpIC9BdXRob3IgKEpQIFZhc3Nl dXIpIC9DcmVhdG9yIChNaWNyb3NvZnQgRXhjZWwpCi9Qcm9kdWNlciAoTWFjIE9TIFggMTAuNS44 IFF1YXJ0eiBQREZDb250ZXh0KSAvQ3JlYXRpb25EYXRlIChEOjIwMTAwMzI5MjIyMDUyWjAwJzAw JykKL01vZERhdGUgKEQ6MjAxMDAzMjkyMjIwNTJaMDAnMDAnKSA+PgplbmRvYmoKeHJlZgowIDQy CjAwMDAwMDAwMDAgNjU1MzUgZiAKMDAwMDA1MzkyOCAwMDAwMCBuIAowMDAwMDAyMTk0IDAwMDAw IG4gCjAwMDAwMTI0NTkgMDAwMDAgbiAKMDAwMDAwMDAyMiAwMDAwMCBuIAowMDAwMDAyMTc0IDAw MDAwIG4gCjAwMDAwMDIyOTggMDAwMDAgbiAKMDAwMDAwMzMzNiAwMDAwMCBuIAowMDAwMDUwOTg0 IDAwMDAwIG4gCjAwMDAwNTM3NTcgMDAwMDAgbiAKMDAwMDA0MjYxNyAwMDAwMCBuIAowMDAwMDAy NDIxIDAwMDAwIG4gCjAwMDAwMDMzMTYgMDAwMDAgbiAKMDAwMDAwNTQwOSAwMDAwMCBuIAowMDAw MDAzMzcyIDAwMDAwIG4gCjAwMDAwMDUzODggMDAwMDAgbiAKMDAwMDAwNTUxNiAwMDAwMCBuIAow MDAwMDA3NzY0IDAwMDAwIG4gCjAwMDAwMDU2NDAgMDAwMDAgbiAKMDAwMDAwNzc0MyAwMDAwMCBu IAowMDAwMDA3ODcxIDAwMDAwIG4gCjAwMDAwMTAyMjcgMDAwMDAgbiAKMDAwMDAwNzk5NSAwMDAw MCBuIAowMDAwMDEwMjA2IDAwMDAwIG4gCjAwMDAwMTAzMzQgMDAwMDAgbiAKMDAwMDAxMjIyOCAw MDAwMCBuIAowMDAwMDEwNDU4IDAwMDAwIG4gCjAwMDAwMTIyMDcgMDAwMDAgbiAKMDAwMDAxMjMz NSAwMDAwMCBuIAowMDAwMDEyNTcwIDAwMDAwIG4gCjAwMDAwMTI2MjAgMDAwMDAgbiAKMDAwMDA0 MjAzNCAwMDAwMCBuIAowMDAwMDQyMDU2IDAwMDAwIG4gCjAwMDAwNDIzMDEgMDAwMDAgbiAKMDAw MDA0MjgwMCAwMDAwMCBuIAowMDAwMDUwNDU5IDAwMDAwIG4gCjAwMDAwNTA0ODAgMDAwMDAgbiAK MDAwMDA1MDcwOSAwMDAwMCBuIAowMDAwMDUxMTYxIDAwMDAwIG4gCjAwMDAwNTMzNzUgMDAwMDAg biAKMDAwMDA1MzM5NiAwMDAwMCBuIAowMDAwMDUzNjE5IDAwMDAwIG4gCnRyYWlsZXIKPDwgL1Np emUgNDIgL1Jvb3QgMjkgMCBSIC9JbmZvIDEgMCBSIC9JRCBbIDxiN2Q3MTE0NjUzZjY1M2Y3NTI3 Mjg4YjQwODJjMzU0Zj4KPGI3ZDcxMTQ2NTNmNjUzZjc1MjcyODhiNDA4MmMzNTRmPiBdID4+CnN0 YXJ0eHJlZgo1NDE0MQolJUVPRgo= --Apple-Mail-97--463687274 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable
Any chance of getting that in a = format that we can read without spending several KUSD on special-purpose = software?

Thanks,

Thomas
On Mar 29, 2010, at 21:31 PM, JP Vasseur wrote:

Dear WG,

I = put together a spreadsheet to track the "MUST requirements" spelled out = in our four requirements documents.

To that = end, I listed all MUST and used the following color = code:

GREEN: Satisfied = requirement

YELLOW: the = requirement is partially satisfied and the WG thinks that the = requirement is not sufficiently satisfied.

For = example:
Support of = Point-to-Point: "The routing protocol MUST provide routes between = arbitrary hosts within the = appropriate 
administrative domain". Strictly speaking RPL supports P2P but the = WG thinks that more work is required, thus = the 

RED: the = requirement is not satisfied (e.g. additional mechanisms required) or = not yet done (e.g. security)

PINK: the = requirement is partially satisfied or non satisfied but the WG decided = that this was acceptable. It may 
be wise to document = it.

GREY: Evaluation is differed (not a show = stopper for LC). For example, it may take time to deploy a network = with
few dozens of thousands of nodes. Note that in this case, = simulations may help.

Let's continue to work on = our opened tickets and update that spreadsheet = accordingly.

Note that in both the = YELLOW and RED cases, RPL could not be last called until they turn = GREEN.

Comments very welcome = of = course.

Thanks.

JP. = ;

<RPL-MUST.xlsx><= /span>
=
_______________________________________________
Roll mailing = list
Roll@ietf.org
https://www.ietf.org/m= ailman/listinfo/roll

Hi Jerry,

 

I think the table sizes need to be configured to meet the = worst case placement of the device in the network.    If you = make the tables too small for wherever the device may be deployed in an = operational environment then I don’t see how the specification or protocol is = going to make up for that.

 

Don

 

 

 

From:= Jerald.P.Martocci@jci.com [mailto:Jerald.P.Martocci@jci.com]
Sent: Monday, March 29, 2010 12:11 PM
To: d.sturek@att.net
Cc: 'Michael Richardson'; 'roll'; roll-bounces@ietf.org
Subject: Re: [Roll] Mixed mode operation

 



Hi Don,

Don't = you think it's scary for a node to just down-shift to being a leaf node if it's = out of resources?  In our implementations, nodes closest to the LBR tend = to have the most traffic.  The traffic level diminishes as the node is = placed farther from the LBR.  Since we can't control node placement in a = jobsite, it's likely that all the LBR neighbors will run our of memory first. =  If they drop down to 'leafs', that renders the whole DAG beneath them = unusable.  That would not be a good thing!  somehow, we need to manage = the routing table resource.

Jerry =


From:

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

To:

"'Michael= Richardson'" <mcr@sandelman.ca>, "'roll'" <roll@ietf.org>

Date:

03/29/2010 12:09 PM

Subject:

Re: [Roll] Mixed mode operation

 




Storing devices that are out of = resources to store either need to become
non-storing (if that is legal in the DAG they are a member) or must = become
leaf devices.  I don't see any other alternative.

Internally, they can do some table management/freeing of resources = but I
would not expect to see that in the specification.

Don


-----Original Message-----
From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of
Michael Richardson
Sent: Monday, March 29, 2010 9:13 AM
To: roll
Subject: Re: [Roll] Mixed mode operation


>>>>> "Jonathan" =3D=3D Jonathan Hui <jhui@archrock.com> writes:
   Jonathan> Not supporting mixed-mode operation would = be on-par with
   Jonathan> the industry  today (which, for me, = is a major goal).  The
   Jonathan> point is that the LLN  solutions that = are shipping today
   Jonathan> assume either fully non-storing or =  fully storing.  Any
   Jonathan> issues around that are being addressed = without  having to
   Jonathan> resort to mixed mode operation.

What do deployed storing solutions do when the node runs out of = space?

--
]       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.youtube.com/watch?v=3Dkzx1ycLXQSE<= span style=3D'font-size:10.0pt'>>
                  =              then sign the petition. =
_______________________________________________
Roll mailing list
Roll@ietf.org
https://www.ietf.org/mailman/listinfo/roll

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