From trac@tools.ietf.org Tue Dec 1 03:40:45 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AF61B3A68BE for ; Tue, 1 Dec 2009 03:40:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.406 X-Spam-Level: X-Spam-Status: No, score=-102.406 tagged_above=-999 required=5 tests=[AWL=0.194, 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 rhPrnGQUx8HA for ; Tue, 1 Dec 2009 03:40:45 -0800 (PST) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:1112:1:214:22ff:fe1f:1e54]) by core3.amsl.com (Postfix) with ESMTP id 213BC3A681C for ; Tue, 1 Dec 2009 03:40:45 -0800 (PST) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1NFR5w-0005zy-Hm; Tue, 01 Dec 2009 03:40: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.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.5, by Edgewall Software To: jpv@cisco.com X-Trac-Project: roll Date: Tue, 01 Dec 2009 11:40:36 -0000 X-URL: http://tools.ietf.org/wg/roll/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/roll/trac/ticket/19 Message-ID: <055.9eab526527cfe1258e5e2097036a018a@tools.ietf.org> X-Trac-Ticket-ID: 19 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] #19: Add an Type to the OCP Object in the 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: Tue, 01 Dec 2009 11:40:45 -0000 #19: Add an Type to the OCP Object in the Metric ID --------------------------------+------------------------------------------- Reporter: jpv@… | Owner: jpv@… Type: defect | Status: new Priority: major | Milestone: Component: routing-metrics | Version: Severity: Active WG Document | Keywords: --------------------------------+------------------------------------------- Add an Type to the OCP Object in the Metric ID -- Ticket URL: roll From phoebus@ieee.org Tue Dec 1 05:34:06 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9CBD728C1EA for ; Tue, 1 Dec 2009 05:34: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 67Bcu-+xBekY for ; Tue, 1 Dec 2009 05:34:05 -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 9357528C268 for ; Tue, 1 Dec 2009 05:26:50 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by smtp-2.sys.kth.se (Postfix) with ESMTP id CB8F014DD35 for ; Tue, 1 Dec 2009 14:26:11 +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 Y4bkGfvP6lku for ; Tue, 1 Dec 2009 14:26:08 +0100 (CET) X-KTH-Auth: phoebus [130.237.50.89] Received: from dhcp-50-89.s3.kth.se (dhcp-50-89.s3.kth.se [130.237.50.89]) by smtp-2.sys.kth.se (Postfix) with ESMTP id CB7A114DCA2 for ; Tue, 1 Dec 2009 14:26:08 +0100 (CET) Message-ID: <4B151970.2080709@ieee.org> Date: Tue, 01 Dec 2009 14:26:08 +0100 From: Phoebus Chen Organization: KTH, Royal Institute of Technology User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: roll@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Roll] Trickle clarification: (in)consistency 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, 01 Dec 2009 13:40:29 -0000 Hello, I've been following this mailing list for some time, and I thought I should chime in. I'm hoping that the clarifications on Trickle in RPLv5 will address my questions below, but please read on and give some comments. I had a discussion with some other members in my research group on how DAGs are constructed in RPL, and we were unclear about how the timing of Trickle broadcasts would affect the choice of parents in the DAG. As I understand it, a node is suppose to choose the preferred parent from its set of parents when it receives a RA-DIO message with a new DAG sequence number. This is because it needs to compute its rank to rebroadcast (via Trickle) a new RA-DIO with it's new DAG rank. Should the node choose a new preferred parent upon receiving the *first* RA-DIO message with a new sequence number, or should it wait for a prespecified amount of time for more RA-DIO messages with the same sequence number from other potential parents? Let me elaborate with three alternate approaches below. 1) If the node chooses a preferred parent after hearing the first RA-DIO message, it would be deciding on the preferred parent using cached data (parents and associated metric + rank) associated with the previous sequence number. This seems to depart with the current line of thinking, that inefficient DAGs (because of local routing loop repairs, or a need to increase a node's rank so it has more parents, for example) will be rebuilt cleanly when the DAG sequence number is incremented. 2) If the node chooses to wait for a prespecified amount of time for more RA-DIO messages from other potential parents, then the node's rank does not need to depend on the ranks of neighboring nodes associated with an older DAG sequence number. However, this seems to depart from the way Trickle was initially designed to operate. Now, in addition to Trickle's listen-only period, we would have another "silent" period prepended to the first listen-only period of duration I_min/2. This silent period is another parameter to tune. It would affect both the performance of Trickle and the choice of parents in the DAG. I would also presume that all the nodes in the network should agree on one value for the length of this silent period for this to work, and this length should also be carried within the DIO. 3) Both alternatives described above assumes that for a given DAG sequence number, a node cannot decide to change its rank after it has broadcast an RA-DIO. Another alternative is to allow a node to change its rank multiple times (and reset the Trickle timer each time) during a single DAG iteration (the period of time when the DAG sequence number has not changed). This seems to go against Pascal's recent suggestion on this thread, that the rank is not part of the consistency check for resetting the Trickle timer. The consistency check would be against a cached value of the rank previously advertised by that neighbor for this DAG sequence number. I tried looking at the CTP paper (http://sing.stanford.edu/pubs/sensys09-ctp.pdf) to see how they resolve this, since it also runs into a similar situation when selecting the best parent from all nodes it has heard before. CTP does not use sequence numbers, but "uses the routing cost gradient" (pg.3, Section 3.2) for consistency. Thus, it seems most similar to the last approach (approach #3, without sequence numbers). I'm a bit nervous about this last approach, because now it sounds like a node can increase its rank during the RA-DIO rebroadcasts in one DAG iteration. This could lead to loops... this was the whole purpose of the DAG detach and merge mechanisms that were removed when going from RPLv3 to RPLv4. Could someone comment on the three alternatives I described above? Which one is being used in the current RPL? Is there another approach that I missed? Or maybe this will all be clear in RPLv5? ;) Phoebus Chen Postdoctoral Researcher Automatic Control Lab, KTH (Royal Institute of Technology) > Hi Pascal, Jonathan, > > Thanks for your answers. I think we agree that child and other nodes > could play a role to detect a consistent situation. > Hence, we need to see how this affects the DIO processing rules as you > actually typically don't process DIOs from node deeper than you in the > DAG... > I also agree with Pascal and Julien when they say that consistency > should concentrate on global or common DAG information. > > Best, > Mathilde > -----Original Message----- > From: Pascal Thubert (pthubert) > Sent: lundi, 23. novembre 2009 08:55 > To: Julien Abeille (jabeille); 'Jonathan Hui'; Mathilde Durvy (mdurvy) > Cc: 'roll at ietf.org' > Subject: RE: [Roll] Trickle clarification: (in)consistency > > Hi Julien > > Seems to me that so far we are saying the same thing. > > We'll be concentrating the DAG information in one option. That option > should be consistent in an iteration. It should thus be subject to > elision if it is redundant with C messages already heard during the > trickle period. Other fields in the DIO might not be redundant though. > My main concern is the routing information. My Rank is not my neighbor's > Rank. > > Pascal > >>-----Original Message----- >>From: Julien Abeille (jabeille) >>Sent: dimanche 22 novembre 2009 22:55 >>To: Pascal Thubert (pthubert); Jonathan Hui; Mathilde Durvy (mdurvy) >>Cc: roll at ietf.org >>Subject: RE: [Roll] Trickle clarification: (in)consistency >> >>Hi Pascal, >> >>Not sure I understand your explanation. In a DIO there are informations > >>that are global to the DAG and some that are node specific. We use >>trickle because we consider DIO sending a consitency problem, hence we >>focus on the global information. They come both from parents and > childs, so I would also increment C when hearing from a child. Am I > missing something? >> >>Julien >> >>> -----Original Message----- >>> From: roll-bounces at ietf.org [mailto:roll-bounces at ietf.org] On Behalf >>> Of Pascal Thubert (pthubert) >>> Sent: vendredi 20 novembre 2009 20:12 >>> To: Jonathan Hui; Mathilde Durvy (mdurvy) >>> Cc: roll at ietf.org >>> Subject: Re: [Roll] Trickle clarification: (in)consistency >>> >>> Hi Mathilde; >>> >>> I agree with Jonathan that we want to avoid redundancy. >>> >>> The rank of metric that a node advertises is an information about >>> self that cannot be inferred from the neighbors so it is *not* >>> redundant. If a number of nodes go down at the same time and one does > >>> not advertise, then that node will look better and will attract the >>> traffic. It will also attract the neighbors that went down and that >>> will be tempted to reattach to that apparent survivor. >>> >>> The information in the DIO that relates to the DAG configuration will > >>> be centralized in an option that IS redundant. We could add text that > >>> a node that see C of it MAY filter it out from its DIO. >>> >>> Finally the new sequence is redundant. I proposed to use it to limit >>> the density of routers using trickle. When you hear C router >>> advertising a new sequence you are entitled to stop being a router >>> for that sequence (stop trickle timer). The trickle timer would then >>> be restarted upon a DIS to serve orphans, and upon a next sequence to > >>> redistribute the load. >>> >>> Pascal >>> >>> >-----Original Message----- >>> >From: roll-bounces at ietf.org [mailto:roll-bounces at ietf.org] >>> On Behalf Of >>> Jonathan Hui >>> >Sent: vendredi 20 novembre 2009 16:41 >>> >To: Mathilde Durvy (mdurvy) >>> >Cc: roll at ietf.org >>> >Subject: Re: [Roll] Trickle clarification: (in)consistency >>> > >>> > >>> >Hi Mathilde, >>> > >>> >On Nov 19, 2009, at 9:24 AM, Mathilde Durvy (mdurvy) wrote: >>> > >>> >>> - when do we increment C? >>> >> >>> >> The node MAY increment C when it hears another DIO. >>> >> >>> >> I think the spec says that a node MAY increment C each >>> time it hears >>> a >>> >> "consistent DIO for this DAG from a DAG parent". What fields are >>> >> included in the consistency check? If only generic DAG information >>> are >>> >> checked you might want to look at DIO from non-DAG parents, no? >>> > >>> >You're right, this text in the draft is incorrect. There's an >>> >important distinction to make here. We want to quickly send DIO >>> >transmissions (reset the Trickle timer) whenever >>> *inconsistencies* are >>> >detected. But you want to suppress DIO transmissions (increment C) >>> >whenever *redundancies* are detected. While you can detect >>> >inconsistencies by listening to your DAG parent(s), >>> redundancies will >>> >probably come from your siblings/cousins. >>> > >>> >We are looking to update the text around incrementing C and >>> make what >>> >constitutes a redundancy more precise. >>> > >>> >-- >>> >Jonathan Hui >>> > >>> >_______________________________________________ >>> >Roll mailing list >>> >Roll at ietf.org >>> >https://www.ietf.org/mailman/listinfo/roll >>> _______________________________________________ >>> Roll mailing list >>> Roll at ietf.org >>> https://www.ietf.org/mailman/listinfo/roll >>> From richard.kelsey@ember.com Tue Dec 1 07:14:18 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5CCB23A682B for ; Tue, 1 Dec 2009 07:14:18 -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 L448tc9Ljk3S for ; Tue, 1 Dec 2009 07:14:17 -0800 (PST) Received: from EMPIRE.hq.ember.com (mail.ember.com [74.10.175.227]) by core3.amsl.com (Postfix) with ESMTP id 104D83A6918 for ; Tue, 1 Dec 2009 07:14:16 -0800 (PST) Received: from kelsey-ws.hq.ember.com ([192.168.81.60]) by EMPIRE.hq.ember.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 1 Dec 2009 10:15:49 -0500 Date: Tue, 01 Dec 2009 10:09:48 -0500 Message-Id: <877ht620jn.fsf@kelsey-ws.hq.ember.com> To: "Pascal Thubert (pthubert)" In-reply-to: <6A2A459175DABE4BB11DE2026AA50A5DBD5226@XMB-AMS-107.cisco.com> (pthubert@cisco.com) From: Richard Kelsey References: <6A2A459175DABE4BB11DE2026AA50A5DBD5226@XMB-AMS-107.cisco.com> X-OriginalArrivalTime: 01 Dec 2009 15:15:49.0281 (UTC) FILETIME=[29F2A110:01CA7299] Cc: roll@ietf.org Subject: Re: [Roll] updating DAO caches - a 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, 01 Dec 2009 15:14:18 -0000 > Date: Mon, 30 Nov 2009 14:53:27 +0100 > From: "Pascal Thubert (pthubert)" > > For R05 I think we will not have time to converge on source route. > I'll make a separate thread for R05 for the common pieces. > > This thread is about source route so I keep it this way. > > To integrate source route I think that we'll need to convert the routing > header in a string of shorter tags. > > Here's how that could happen: > > - ack the DAO. What about a DA Confirm (DAC) ? Acking the DAO seems like a partial patch. What is needed is an ack from the caching node, not from one's immediate parent. > - Multiple destination info may be piggy backed (BNF?) > > - DAO Originator and caching parent MAY send the DAO to multiple > parents, details left out. > > - A parent keeps track of its children. For each child, it maintains the > tag that points onto the child and associated to that, the link local > and the (destinations, originator sequence) for destinations owned by > that child. This is done to aggregate multiple destinations in one > messages, enable no-DAOs, etc... > - a caching parent also keeps track of destinations. For those > destinations, it maintains the tag that points onto the next_hop child > and associated to that, the link local and the (destinations, originator > sequence) for destinations owned by or reachable via that child. > > - A DAO emitted by the Originator node and a caching parent contains > only the destination and sequence set by the originator. > - A parent that propagates a DAO without caching it adds a local tag > that points onto the child (see that as a locally significant > compression of the child LLA, or an index on that child). That tag of yours sure looks like a label. If we are going to use labels I think that they need to be in a separate document. Either that or we should integrate the use of labels into all of RPL. > - A Node that sends DIOs maintains its own cache_sequence that it places > in the DIO. The sequence is increments to request the children to send > their DIOs. > - A child that changes its parent or gets a new cache_sequence from its > parent dumps its DAO info. If the node does not cache all DAOs or if the > D bit is set then the node needs to update its own cache_sequence, and > propagate the DIO with the same setting of the D bit. > > What do you think? RPL is starting to look schizophrenic. On one hand we have the DAG mechanism which, especially with local repair, aims to make it as cheap as possible to react to changes in the topology. On the other hand we have the DAO mechanism which maintains a distributed route database and where a single DAG link change can trigger widespread updates. How likely is it that topology changes will be common enough that we need fast local DAG repair and also rare enough that the resulting DAOs successfully maintain the downward routes without swamping the network with control messages? We are in danger of painting ourselves into a corner. -Richard Kelsey From pthubert@cisco.com Tue Dec 1 08:05:24 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 972123A68B9 for ; Tue, 1 Dec 2009 08:05:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.78 X-Spam-Level: X-Spam-Status: No, score=-7.78 tagged_above=-999 required=5 tests=[AWL=-1.181, 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 jRupsO03nso5 for ; Tue, 1 Dec 2009 08:05:23 -0800 (PST) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id AB7853A67F9 for ; Tue, 1 Dec 2009 08:05:23 -0800 (PST) Authentication-Results: sj-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAD/NFEurRN+K/2dsb2JhbADBKpgKhDEE X-IronPort-AV: E=Sophos;i="4.47,321,1257120000"; d="scan'208";a="226556109" Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-2.cisco.com with ESMTP; 01 Dec 2009 16:05:13 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by sj-core-4.cisco.com (8.13.8/8.14.3) with ESMTP id nB1G3sRe017782; Tue, 1 Dec 2009 16:05:12 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, 1 Dec 2009 17:05:00 +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, 1 Dec 2009 17:04:54 +0100 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5DC57E84@XMB-AMS-107.cisco.com> In-Reply-To: <877ht620jn.fsf@kelsey-ws.hq.ember.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] updating DAO caches - a proposal Thread-Index: AcpymPooEyTBTemeTvqFj7XVOyA2egABdIzQ References: <6A2A459175DABE4BB11DE2026AA50A5DBD5226@XMB-AMS-107.cisco.com> <877ht620jn.fsf@kelsey-ws.hq.ember.com> From: "Pascal Thubert (pthubert)" To: "Richard Kelsey" X-OriginalArrivalTime: 01 Dec 2009 16:05:00.0346 (UTC) FILETIME=[08EB69A0:01CA72A0] Cc: roll@ietf.org Subject: Re: [Roll] updating DAO caches - a 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, 01 Dec 2009 16:05:24 -0000 Hi Richard >> Here's how that could happen: >> >> - ack the DAO. What about a DA Confirm (DAC) ? > >Acking the DAO seems like a partial patch. What is >needed is an ack from the caching node, not from one's >immediate parent. Hop by hop you get some degree of recovery. The ack also enables the parent to Nack. This could happen for multiple reasons, like out of memory, or security/policies >> - A DAO emitted by the Originator node and a caching parent contains >> only the destination and sequence set by the originator. >> - A parent that propagates a DAO without caching it adds a local tag >> that points onto the child (see that as a locally significant >> compression of the child LLA, or an index on that child). > >That tag of yours sure looks like a label. If we are going >to use labels I think that they need to be in a separate >document. Either that or we should integrate the use of >labels into all of RPL. This is more like a locally significant compression of the next hop Link local address. The term label is encumbered with MPLS, and seems to imply a lot more than we do here, like LDP, switching... Maybe in some future we'll integrate more "real" labels, but we're far from doing that here. > >> - A Node that sends DIOs maintains its own cache_sequence that it places >> in the DIO. The sequence is increments to request the children to send >> their DIOs. >> - A child that changes its parent or gets a new cache_sequence from its >> parent dumps its DAO info. If the node does not cache all DAOs or if the >> D bit is set then the node needs to update its own cache_sequence, and >> propagate the DIO with the same setting of the D bit. >> >> What do you think? > >RPL is starting to look schizophrenic. On one hand we have >the DAG mechanism which, especially with local repair, aims >to make it as cheap as possible to react to changes in the >topology. On the other hand we have the DAO mechanism which >maintains a distributed route database and where a single >DAG link change can trigger widespread updates. How likely >is it that topology changes will be common enough that we >need fast local DAG repair and also rare enough that the >resulting DAOs successfully maintain the downward routes >without swamping the network with control messages? We >are in danger of painting ourselves into a corner. Good question that applies to DAO in general not just this mechanism :)=20 You'll note that the string of tags could be refreshed not only in DAOs, but with traffic if such thing is needed. That would adapt what's most needed to fast changes. Pascal From pal@cs.stanford.edu Tue Dec 1 09:50:45 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CB6423A6881 for ; Tue, 1 Dec 2009 09:50:45 -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=[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 v9XFBIcz0cSp for ; Tue, 1 Dec 2009 09:50:45 -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 2FD1F3A67F2 for ; Tue, 1 Dec 2009 09:50:45 -0800 (PST) Received: from dnab40460f.stanford.edu ([171.64.70.15]) by cs-smtp-3.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1NFWs0-0001eG-NM; Tue, 01 Dec 2009 09:50:37 -0800 Message-Id: From: Philip Levis To: JP Vasseur In-Reply-To: <8203DD69-8CF7-49B7-9429-382903BA67B0@cisco.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 1 Dec 2009 09:25:48 -0800 References: <9F5AB59D-5673-4C75-A953-33C3384527E6@cs.stanford.edu> <87k4xe207c.fsf@kelsey-ws.hq.ember.com> <8203DD69-8CF7-49B7-9429-382903BA67B0@cisco.com> X-Mailer: Apple Mail (2.936) X-Scan-Signature: 6bee508a35d8245455fa42c2dd36c733 Cc: roll@ietf.org Subject: Re: [Roll] multicast 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, 01 Dec 2009 17:50:45 -0000 On Nov 30, 2009, at 11:39 PM, JP Vasseur wrote: >> > > I do think so. It makes little sense to remove something just > because it makes it more simpler. It makes tremendous sense! Remember these are resource-constrained devices. 100 bytes of code can make the difference between price points. > Multicast DAO does help to come up with shorter path, which is quite > important for P2P and the level of complexity is close to 0. Given the current mandate of "simplify," it seems to me like we should remove it, then add it in later if there's strong evidence of its benefit. It addresses a narrow case. Phil From pal@cs.stanford.edu Tue Dec 1 09:50:49 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BD89D28C101 for ; Tue, 1 Dec 2009 09:50:49 -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=[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 t-Z9loHCQlo4 for ; Tue, 1 Dec 2009 09:50:48 -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 9C32A28C0ED for ; Tue, 1 Dec 2009 09:50:48 -0800 (PST) Received: from dnab40460f.stanford.edu ([171.64.70.15]) by cs-smtp-3.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1NFWs3-0001eG-Lz; Tue, 01 Dec 2009 09:50:40 -0800 Message-Id: From: Philip Levis To: phoebus@ieee.org In-Reply-To: <4B151970.2080709@ieee.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, 1 Dec 2009 09:50:01 -0800 References: <4B151970.2080709@ieee.org> X-Mailer: Apple Mail (2.936) X-Scan-Signature: ad8d31192ee589897252aca97298099a Cc: roll@ietf.org Subject: Re: [Roll] Trickle clarification: (in)consistency X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 01 Dec 2009 17:50:49 -0000 On Dec 1, 2009, at 5:26 AM, Phoebus Chen wrote: > Hello, > I've been following this mailing list for some time, and I thought > I should chime in. I'm hoping that the clarifications on Trickle in > RPLv5 will address my questions below, but please read on and give > some comments. > > I had a discussion with some other members in my research group on how > DAGs are constructed in RPL, and we were unclear about how the > timing of > Trickle broadcasts would affect the choice of parents in the DAG. > As I > understand it, a node is suppose to choose the preferred parent from > its > set of parents when it receives a RA-DIO message with a new DAG > sequence > number. This is because it needs to compute its rank to rebroadcast > (via Trickle) a new RA-DIO with it's new DAG rank. > > Should the node choose a new preferred parent upon receiving the > *first* RA-DIO message with a new sequence number, or should it wait > for > a prespecified amount of time for more RA-DIO messages with the same > sequence number from other potential parents? Let me elaborate with > three alternate approaches below. > > > 1) > If the node chooses a preferred parent after hearing the first RA-DIO > message, it would be deciding on the preferred parent using cached > data > (parents and associated metric + rank) associated with the previous > sequence number. This seems to depart with the current line of > thinking, that inefficient DAGs (because of local routing loop > repairs, > or a need to increase a node's rank so it has more parents, for > example) > will be rebuilt cleanly when the DAG sequence number is incremented. > > 2) > If the node chooses to wait for a prespecified amount of time for more > RA-DIO messages from other potential parents, then the node's rank > does > not need to depend on the ranks of neighboring nodes associated with > an > older DAG sequence number. However, this seems to depart from the way > Trickle was initially designed to operate. Now, in addition to > Trickle's listen-only period, we would have another "silent" period > prepended to the first listen-only period of duration I_min/2. This > silent period is another parameter to tune. It would affect both the > performance of Trickle and the choice of parents in the DAG. I would > also presume that all the nodes in the network should agree on one > value > for the length of this silent period for this to work, and this > length should also be carried within the DIO. > > 3) > Both alternatives described above assumes that for a given DAG > sequence > number, a node cannot decide to change its rank after it has broadcast > an RA-DIO. Another alternative is to allow a node to change its rank > multiple times (and reset the Trickle timer each time) during a > single DAG iteration (the period of time when the DAG sequence > number has not changed). This seems to go against Pascal's recent > suggestion on this thread, that the rank is not part of the > consistency check for resetting the Trickle timer. The consistency > check would be against a cached value of the rank previously > advertised by that neighbor for this DAG sequence number. > > > I tried looking at the CTP paper (http://sing.stanford.edu/pubs/sensys09-ctp.pdf > ) to see how they resolve > this, since it also runs into a similar situation when selecting the > best parent from all nodes it has heard before. CTP does not use > sequence numbers, but "uses the routing cost gradient" (pg.3, Section > 3.2) for consistency. Thus, it seems most similar to the last > approach > (approach #3, without sequence numbers). > > I'm a bit nervous about this last approach, because now it sounds like > a node can increase its rank during the RA-DIO rebroadcasts in one DAG > iteration. This could lead to loops... this was the whole purpose of > the DAG detach and merge mechanisms that were removed when going > from RPLv3 to RPLv4. > > Could someone comment on the three alternatives I described above? > Which one is being used in the current RPL? Is there another > approach that I missed? Or maybe this will all be clear in RPLv5? ;) We're hoping that the -05 text will clarify this. The basic answer is none of the above. :) A node can decrease its Rank within an iteration at any time (following rank computation rules): the constraint is on when it can increase its Rank. The rule is that all of a node's parent set must have the same sequence number. So after hearing one neighbor with a higher sequence number, a node may wait before becoming part of the next iteration, or could do so immediately. It's probably better to wait a little bit, as once the node has become part of the next iteration, it can't go back: having only one parent is a bit risky (unless it's the DODAG root with a high quality link). Phil From jvasseur@cisco.com Tue Dec 1 10:01:09 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6C9A428C12F for ; Tue, 1 Dec 2009 10:01:09 -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.001, 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 BLHVm+-6PUOc for ; Tue, 1 Dec 2009 10:01:08 -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 3C82F28C12E for ; Tue, 1 Dec 2009 10:01:07 -0800 (PST) Authentication-Results: sj-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAPDoFEtAZnwM/2dsb2JhbADAbJgUhDEEjRY X-IronPort-AV: E=Sophos;i="4.47,322,1257120000"; d="scan'208";a="276309536" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by sj-iport-1.cisco.com with ESMTP; 01 Dec 2009 18:00:59 +0000 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id nB1I0x4W016830; Tue, 1 Dec 2009 18:00:59 GMT Received: from xfe-rtp-211.amer.cisco.com ([64.102.31.113]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 1 Dec 2009 13:00:59 -0500 Received: from ams-jvasseur-8715.cisco.com ([10.55.201.134]) by xfe-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 1 Dec 2009 13:00:57 -0500 Message-Id: From: JP Vasseur To: Philip Levis In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 1 Dec 2009 19:00:51 +0100 References: <9F5AB59D-5673-4C75-A953-33C3384527E6@cs.stanford.edu> <87k4xe207c.fsf@kelsey-ws.hq.ember.com> <8203DD69-8CF7-49B7-9429-382903BA67B0@cisco.com> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 01 Dec 2009 18:00:58.0478 (UTC) FILETIME=[3C4A18E0:01CA72B0] Cc: roll@ietf.org Subject: Re: [Roll] multicast 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, 01 Dec 2009 18:01:09 -0000 On Dec 1, 2009, at 6:25 PM, Philip Levis wrote: > > On Nov 30, 2009, at 11:39 PM, JP Vasseur wrote: > >>> >> >> I do think so. It makes little sense to remove something just >> because it makes it more simpler. > > It makes tremendous sense! Remember these are resource-constrained > devices. 100 bytes of code can make the difference between price > points. > Is it how it cost to implement it ? I do not think so. >> Multicast DAO does help to come up with shorter path, which is >> quite important for P2P and the level of complexity is close to 0. > > Given the current mandate of "simplify," it seems to me like we > should remove it, then add it in later if there's strong evidence of > its benefit. It addresses a narrow case. > Well remember that you also told me that DAO packing was a last digit optimization ;-) I'l come back soon with numbers showing that we also need to be careful when removing something that it does not break a useful functionality. As far as mcast DAO is concerned, let me provide figures on how much of improvment it provides in term of P2P path quality. So I would suggest to keep for the time being, unless you show that it adds so much complexity ... JP. > Phil > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From phoebus@ieee.org Tue Dec 1 11:15:19 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0512A28C111 for ; Tue, 1 Dec 2009 11:15:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.173 X-Spam-Level: X-Spam-Status: No, score=-106.173 tagged_above=-999 required=5 tests=[AWL=0.076, 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 dMqUc4KtVHeI for ; Tue, 1 Dec 2009 11:15:17 -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 290E428C0ED for ; Tue, 1 Dec 2009 11:15:16 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by smtp-2.sys.kth.se (Postfix) with ESMTP id 1B6C514E27C; Tue, 1 Dec 2009 20:14:37 +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 Cpsx9sIlPMS0; Tue, 1 Dec 2009 20:14:32 +0100 (CET) X-KTH-Auth: phoebus [130.237.50.89] Received: from dhcp-50-89.s3.kth.se (dhcp-50-89.s3.kth.se [130.237.50.89]) by smtp-2.sys.kth.se (Postfix) with ESMTP id 68F7314E0A1; Tue, 1 Dec 2009 20:14:31 +0100 (CET) Message-ID: <4B156B17.909@ieee.org> Date: Tue, 01 Dec 2009 20:14:31 +0100 From: Phoebus Chen Organization: KTH, Royal Institute of Technology User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Philip Levis References: <4B151970.2080709@ieee.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "roll@ietf.org" Subject: Re: [Roll] Trickle clarification: (in)consistency 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, 01 Dec 2009 19:15:19 -0000 Phil, (comments below) Philip Levis wrote: > On Dec 1, 2009, at 5:26 AM, Phoebus Chen wrote: > >> Hello, >> I've been following this mailing list for some time, and I thought >> I should chime in. I'm hoping that the clarifications on Trickle in >> RPLv5 will address my questions below, but please read on and give >> some comments. >> >> I had a discussion with some other members in my research group on how >> DAGs are constructed in RPL, and we were unclear about how the >> timing of >> Trickle broadcasts would affect the choice of parents in the DAG. >> As I >> understand it, a node is suppose to choose the preferred parent from >> its >> set of parents when it receives a RA-DIO message with a new DAG >> sequence >> number. This is because it needs to compute its rank to rebroadcast >> (via Trickle) a new RA-DIO with it's new DAG rank. >> >> Should the node choose a new preferred parent upon receiving the >> *first* RA-DIO message with a new sequence number, or should it wait >> for >> a prespecified amount of time for more RA-DIO messages with the same >> sequence number from other potential parents? Let me elaborate with >> three alternate approaches below. >> >> >> 1) >> If the node chooses a preferred parent after hearing the first RA-DIO >> message, it would be deciding on the preferred parent using cached >> data >> (parents and associated metric + rank) associated with the previous >> sequence number. This seems to depart with the current line of >> thinking, that inefficient DAGs (because of local routing loop >> repairs, >> or a need to increase a node's rank so it has more parents, for >> example) >> will be rebuilt cleanly when the DAG sequence number is incremented. >> >> 2) >> If the node chooses to wait for a prespecified amount of time for more >> RA-DIO messages from other potential parents, then the node's rank >> does >> not need to depend on the ranks of neighboring nodes associated with >> an >> older DAG sequence number. However, this seems to depart from the way >> Trickle was initially designed to operate. Now, in addition to >> Trickle's listen-only period, we would have another "silent" period >> prepended to the first listen-only period of duration I_min/2. This >> silent period is another parameter to tune. It would affect both the >> performance of Trickle and the choice of parents in the DAG. I would >> also presume that all the nodes in the network should agree on one >> value >> for the length of this silent period for this to work, and this >> length should also be carried within the DIO. >> >> 3) >> Both alternatives described above assumes that for a given DAG >> sequence >> number, a node cannot decide to change its rank after it has broadcast >> an RA-DIO. Another alternative is to allow a node to change its rank >> multiple times (and reset the Trickle timer each time) during a >> single DAG iteration (the period of time when the DAG sequence >> number has not changed). This seems to go against Pascal's recent >> suggestion on this thread, that the rank is not part of the >> consistency check for resetting the Trickle timer. The consistency >> check would be against a cached value of the rank previously >> advertised by that neighbor for this DAG sequence number. >> >> >> I tried looking at the CTP paper (http://sing.stanford.edu/pubs/sensys09-ctp.pdf >> ) to see how they resolve >> this, since it also runs into a similar situation when selecting the >> best parent from all nodes it has heard before. CTP does not use >> sequence numbers, but "uses the routing cost gradient" (pg.3, Section >> 3.2) for consistency. Thus, it seems most similar to the last >> approach >> (approach #3, without sequence numbers). >> >> I'm a bit nervous about this last approach, because now it sounds like >> a node can increase its rank during the RA-DIO rebroadcasts in one DAG >> iteration. This could lead to loops... this was the whole purpose of >> the DAG detach and merge mechanisms that were removed when going >> from RPLv3 to RPLv4. >> >> Could someone comment on the three alternatives I described above? >> Which one is being used in the current RPL? Is there another >> approach that I missed? Or maybe this will all be clear in RPLv5? ;) > > We're hoping that the -05 text will clarify this. > > The basic answer is none of the above. :) A node can decrease its Rank > within an iteration at any time (following rank computation rules): > the constraint is on when it can increase its Rank. > > The rule is that all of a node's parent set must have the same > sequence number. So after hearing one neighbor with a higher sequence > number, a node may wait before becoming part of the next iteration, or > could do so immediately. It's probably better to wait a little bit, as > once the node has become part of the next iteration, it can't go back: > having only one parent is a bit risky (unless it's the DODAG root > with a high quality link). > > Phil > > Thanks for responding. Hmm, what you're describing sounds like approach #2 that I outlined above, except you allow a node to decrease rank at any time (oops, I forgot about that part of the draft) and that you do not impose the restriction that all nodes wait for the same prespecified 'silent period' before computing the rank (I can't think of a better name for now, so I'll continue to refer to this as the 'silent period' below). Focusing on the second point, this sounds like it will be tricky for a node to decide how long to wait before computing its rank based on RA-DIO messages it has heard thus far --- The node doesn't know how long the other nodes are waiting. And you can't just wait till all your neighbors compute their rank... some of them may want to be your children. I agree with you that there's a tradeoff between how long it takes to build the next DAG and how good of a DAG you build. Generally, a node would want to wait longer to see if more of its neighbors join the DAG, giving it a larger set of nodes ('potential parents') to choose parents from. I guess the DAG build time is less relevant if you can continue using your old DAG. One approach to sidestep choosing a fixed "silent period" is for a node to just wait till there are enough potential parents so that its metric is "good enough", i.e. greater than a threshold. But this threshold should probably drop over time. With a fixed threshold, you may have a situation where a group of nodes decide never to join the DAG because the first node in the group that joins would have a low or moderate metric. Determining how such a threshold drops over time is again a coordination and timing issue. Maybe I'm thinking too far ahead --- perhaps it's OK to have a fixed threshold and a partitioned network in these situations; if it's some sort of reliability or connectivity metric you can just deploy more relay nodes. I'm wondering how Trickle performs differently if nodes could choose their own 'silent period'... maybe RPL should bound how long nodes can wait before computing their ranks? Anyhow, I'll wait for RPLv5 to see how this all works out. I wanted to get my concerns on the table, in case this turns out to be an issue. Phoebus Chen Postdoctoral Researcher Automatic Control Lab, KTH (Royal Institute of Technology) From richard.kelsey@ember.com Tue Dec 1 18:54:39 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CFF6628C0ED for ; Tue, 1 Dec 2009 18:54:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.699 X-Spam-Level: X-Spam-Status: No, score=-1.699 tagged_above=-999 required=5 tests=[AWL=-0.900, BAYES_00=-2.599, J_CHICKENPOX_72=0.6, J_CHICKENPOX_73=0.6, J_CHICKENPOX_74=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 e9yvHzef9Swf for ; Tue, 1 Dec 2009 18:54:39 -0800 (PST) Received: from EMPIRE.hq.ember.com (mail.ember.com [74.10.175.227]) by core3.amsl.com (Postfix) with ESMTP id 0AF3E28C0DD for ; Tue, 1 Dec 2009 18:54:38 -0800 (PST) Received: from kelsey-ws.hq.ember.com ([192.168.81.60]) by EMPIRE.hq.ember.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 1 Dec 2009 21:56:11 -0500 Date: Tue, 01 Dec 2009 21:50:09 -0500 Message-Id: <87my22ks2m.fsf@kelsey-ws.hq.ember.com> To: "Pascal Thubert (pthubert)" In-reply-to: <6A2A459175DABE4BB11DE2026AA50A5DC57E84@XMB-AMS-107.cisco.com> (pthubert@cisco.com) From: Richard Kelsey References: <6A2A459175DABE4BB11DE2026AA50A5DBD5226@XMB-AMS-107.cisco.com> <877ht620jn.fsf@kelsey-ws.hq.ember.com> <6A2A459175DABE4BB11DE2026AA50A5DC57E84@XMB-AMS-107.cisco.com> X-OriginalArrivalTime: 02 Dec 2009 02:56:11.0730 (UTC) FILETIME=[01477B20:01CA72FB] Cc: roll@ietf.org Subject: Re: [Roll] updating DAO caches - a 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, 02 Dec 2009 02:54:39 -0000 > Date: Tue, 1 Dec 2009 17:04:54 +0100 > From: "Pascal Thubert (pthubert)" > > The term label is encumbered with MPLS, and seems to imply a lot more > than we do here, like LDP, switching... Maybe in some future we'll > integrate more "real" labels, but we're far from doing that here. If we do use labels, why only use them a little bit? We need to maximize the utility of whatever mechanisms we have. It really seems like we are piling on patch after patch and losing sight of the big picture. > Richard>RPL is starting to look schizophrenic. On one hand we have > Richard>the DAG mechanism which, especially with local repair, aims > Richard>to make it as cheap as possible to react to changes in the > Richard>topology. On the other hand we have the DAO mechanism which > Richard>maintains a distributed route database and where a single > Richard>DAG link change can trigger widespread updates. How likely > Richard>is it that topology changes will be common enough that we > Richard>need fast local DAG repair and also rare enough that the > Richard>resulting DAOs successfully maintain the downward routes > Richard>without swamping the network with control messages? We > Richard>are in danger of painting ourselves into a corner. > > Good question that applies to DAO in general not just this mechanism :) To some extent yes, but it doesn't apply to all DAO mechanisms equally. For example, sending plain record routes, either periodically or on demand, would have much less interaction with DIOs and DAG changes and would have a much more predictable behavior. -Richard Kelsey From Jerald.P.Martocci@jci.com Wed Dec 2 14:37:11 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B64CB28C108 for ; Wed, 2 Dec 2009 14:37:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.295 X-Spam-Level: X-Spam-Status: No, score=-6.295 tagged_above=-999 required=5 tests=[AWL=0.076, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XlUmAMTfyraN for ; Wed, 2 Dec 2009 14:37:10 -0800 (PST) Received: from exprod8og106.obsmtp.com (exprod8og106.obsmtp.com [64.18.3.92]) by core3.amsl.com (Postfix) with ESMTP id 89D7128C106 for ; Wed, 2 Dec 2009 14:37:07 -0800 (PST) Received: from source ([192.132.24.139]) (using SSLv3) by exprod8ob106.postini.com ([64.18.7.12]) with SMTP ID DSNKSxbsC7EeibNA19XXCFuIOKTuv515z/Mq@postini.com; Wed, 02 Dec 2009 14:37:03 PST Received: from jwimkrs1.na.jci.com ([10.10.6.31]) by smtpmke02.jci.com (Lotus Domino Release 8.0.1) with ESMTP id 2009120216411661-882884 ; Wed, 2 Dec 2009 16:41:16 -0600 MIME-Version: 1.0 To: roll@ietf.org X-Mailer: Lotus Notes Release 6.5.2 June 01, 2004 From: Jerald.P.Martocci@jci.com Message-ID: Date: Wed, 2 Dec 2009 16:36:44 -0600 X-MIMETrack: Serialize by Router on jwimkrs1.na.jci.com/NA/Johnson_Controls at 12/02/2009 04:36:50 PM, Serialize complete at 12/02/2009 04:36:50 PM, Itemize by SMTP Server on smtpmke02.jci.com/JCI_SMTP(Release 8.0.1|February 07, 2008) at 12/02/2009 04:41:16 PM, Serialize by Router on smtpmke02.jci.com/JCI_SMTP(Release 8.0.1|February 07, 2008) at 12/02/2009 04:41:28 PM, Serialize complete at 12/02/2009 04:41:28 PM Content-Type: multipart/alternative; boundary="=_alternative 007C372786257680_=" Subject: [Roll] Fw: New Version Notification for draft-ietf-roll-building-routing-reqs-08 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 02 Dec 2009 22:37:11 -0000 This is a multipart message in MIME format. --=_alternative 007C372786257680_= Content-Type: text/plain; charset="US-ASCII" All, I have submitted a new version of the ROLL Building Requirements draft (-08) with responses to IESG commenters. Regards, Jerry ----- Forwarded by Jerald P Martocci/CORP/Johnson_Controls on 12/02/2009 04:34 PM ----- IETF I-D Submission Tool 12/02/2009 04:30 PM To jerald.p.martocci@jci.com cc nicolas.riou@fr.schneider-electric.com, pieter.demil@intec.ugent.be, wouter@vooruit.be Subject New Version Notification for draft-ietf-roll-building-routing-reqs-08 A new version of I-D, draft-ietf-roll-building-routing-reqs-08.txt has been successfuly submitted by Jerry Martocci and posted to the IETF repository. Filename: draft-ietf-roll-building-routing-reqs Revision: 08 Title: Building Automation Routing Requirements in Low Power and Lossy Networks Creation_date: 2009-12-02 WG ID: roll Number_of_pages: 25 Abstract: 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. The IETF Secretariat. --=_alternative 007C372786257680_= Content-Type: text/html; charset="US-ASCII"
All,

I have submitted a new version of the ROLL Building Requirements draft (-08) with responses to IESG commenters.

Regards,

Jerry
----- Forwarded by Jerald P Martocci/CORP/Johnson_Controls on 12/02/2009 04:34 PM -----
IETF I-D Submission Tool <idsubmission@ietf.org>

12/02/2009 04:30 PM

To
jerald.p.martocci@jci.com
cc
nicolas.riou@fr.schneider-electric.com, pieter.demil@intec.ugent.be, wouter@vooruit.be
Subject
New Version Notification for          draft-ietf-roll-building-routing-reqs-08






A new version of I-D, draft-ietf-roll-building-routing-reqs-08.txt has been successfuly submitted by Jerry Martocci and posted to the IETF repository.

Filename:                  draft-ietf-roll-building-routing-reqs
Revision:                  08
Title:                                   Building Automation Routing Requirements in Low Power and Lossy Networks
Creation_date:                  2009-12-02
WG ID:                                   roll
Number_of_pages: 25

Abstract:
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.
                                                                                 


The IETF Secretariat.


 --=_alternative 007C372786257680_=-- From root@core3.amsl.com Wed Dec 2 14:45:01 2009 Return-Path: X-Original-To: roll@ietf.org Delivered-To: roll@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 77DE728C0F1; Wed, 2 Dec 2009 14:45: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: <20091202224501.77DE728C0F1@core3.amsl.com> Date: Wed, 2 Dec 2009 14:45:01 -0800 (PST) Cc: roll@ietf.org Subject: [Roll] I-D Action:draft-ietf-roll-building-routing-reqs-08.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, 02 Dec 2009 22:45:01 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Routing Over Low power and Lossy networks Working Group of the IETF. Title : Building Automation Routing Requirements in Low Power and Lossy Networks Author(s) : J. Martocci, et al. Filename : draft-ietf-roll-building-routing-reqs-08.txt Pages : 25 Date : 2009-12-02 The Routing Over Low power and Lossy network (ROLL) Working Group has been chartered to work on routing solutions for Low Power and Lossy networks (LLN) in various markets: Industrial, Commercial (Building), Home and Urban networks. Pursuant to this effort, this document defines the IPv6 routing requirements for building automation. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-roll-building-routing-reqs-08.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-roll-building-routing-reqs-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-12-02143044.I-D@ietf.org> --NextPart-- From trac@tools.ietf.org Thu Dec 3 03:55:04 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 34FC23A68ED for ; Thu, 3 Dec 2009 03:55:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.422 X-Spam-Level: X-Spam-Status: No, score=-102.422 tagged_above=-999 required=5 tests=[AWL=0.178, 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 uBvJbyd1seOT for ; Thu, 3 Dec 2009 03:55:03 -0800 (PST) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:1112:1:214:22ff:fe1f:1e54]) by core3.amsl.com (Postfix) with ESMTP id 9A3623A67A4 for ; Thu, 3 Dec 2009 03:55:03 -0800 (PST) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1NGAGq-0003V0-GR; Thu, 03 Dec 2009 03:54:52 -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.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.5, by Edgewall Software To: mjkim@kt.com, jpv@cisco.com X-Trac-Project: roll Date: Thu, 03 Dec 2009 11:54:52 -0000 X-URL: http://tools.ietf.org/wg/roll/ X-Trac-Ticket-URL: https://wiki.tools.ietf.org/wg/roll/trac/ticket/20 Message-ID: <055.a3c60804880e85f93fc1826167be4fb6@tools.ietf.org> X-Trac-Ticket-ID: 20 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: [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: Thu, 03 Dec 2009 11:55:04 -0000 #20: Question on Metric ID --------------------------------+------------------------------------------- Reporter: jpv@… | Owner: mjkim@… Type: defect | Status: new Priority: major | Milestone: Component: routing-metrics | Version: Severity: Active WG Document | Keywords: --------------------------------+------------------------------------------- Question on the METRIC ID asked during IETF-76 - Throughput and latency should be IEEE 32 floating point? - Is there IEEE 8 floating point format? -- Ticket URL: roll From trac@tools.ietf.org Thu Dec 3 04:24:18 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 298C13A6A2E for ; Thu, 3 Dec 2009 04:24:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.436 X-Spam-Level: X-Spam-Status: No, score=-102.436 tagged_above=-999 required=5 tests=[AWL=0.164, 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 fkVmkfZzb3uy for ; Thu, 3 Dec 2009 04:24:17 -0800 (PST) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:1112:1:214:22ff:fe1f:1e54]) by core3.amsl.com (Postfix) with ESMTP id 08EE83A690E for ; Thu, 3 Dec 2009 04:24:17 -0800 (PST) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1NGAjB-000595-7R; Thu, 03 Dec 2009 04:24:09 -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.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.5, by Edgewall Software To: jpv@cisco.com X-Trac-Project: roll Date: Thu, 03 Dec 2009 12:24:09 -0000 X-URL: http://tools.ietf.org/wg/roll/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/roll/trac/ticket/19#comment:1 Message-ID: <064.61cffe84303e1891202f91ccbc69ef31@tools.ietf.org> References: <055.9eab526527cfe1258e5e2097036a018a@tools.ietf.org> X-Trac-Ticket-ID: 19 In-Reply-To: <055.9eab526527cfe1258e5e2097036a018a@tools.ietf.org> 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: Re: [Roll] [roll] #19: Add an Type to the OCP Object in the 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: Thu, 03 Dec 2009 12:24:18 -0000 #19: Add an Type to the OCP Object in the Metric ID --------------------------------+------------------------------------------- Reporter: jpv@… | Owner: jpv@… Type: defect | Status: closed Priority: major | Milestone: Component: routing-metrics | Version: Severity: Active WG Document | Resolution: fixed Keywords: | --------------------------------+------------------------------------------- Changes (by jpv@…): * status: new => closed * resolution: => fixed Comment: The OCP Object defined in this ID has been modified in revision 04 to be carried as a suboption of the DIO Base option, with makes more sense than in the DAG Metric Container and a new suboption type has been assigned TBC by IANA. Thanks. JP, Mijeom and Kris. -- Ticket URL: roll From root@core3.amsl.com Thu Dec 3 04:30:05 2009 Return-Path: X-Original-To: roll@ietf.org Delivered-To: roll@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 888203A6A42; Thu, 3 Dec 2009 04:30:05 -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: <20091203123005.888203A6A42@core3.amsl.com> Date: Thu, 3 Dec 2009 04:30:05 -0800 (PST) Cc: roll@ietf.org Subject: [Roll] I-D Action:draft-ietf-roll-routing-metrics-04.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Dec 2009 12:30:05 -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, D. Networks Filename : draft-ietf-roll-routing-metrics-04.txt Pages : 29 Date : 2009-12-03 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-04.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-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-12-03042026.I-D@ietf.org> --NextPart-- From trac@tools.ietf.org Thu Dec 3 06:58:55 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C14683A6A36 for ; Thu, 3 Dec 2009 06:58:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.447 X-Spam-Level: X-Spam-Status: No, score=-102.447 tagged_above=-999 required=5 tests=[AWL=0.153, 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 gfsA2bbC2Mth for ; Thu, 3 Dec 2009 06:58:55 -0800 (PST) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:1112:1:214:22ff:fe1f:1e54]) by core3.amsl.com (Postfix) with ESMTP id 1D9333A6974 for ; Thu, 3 Dec 2009 06:58:55 -0800 (PST) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1NGD8m-000624-UF; Thu, 03 Dec 2009 06:58:44 -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.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.5, by Edgewall Software To: wintert@acm.org, jpv@cisco.com X-Trac-Project: roll Date: Thu, 03 Dec 2009 14:58:44 -0000 X-URL: http://tools.ietf.org/wg/roll/ X-Trac-Ticket-URL: http://tools.ietf.org/wg/roll/trac/ticket/12#comment:1 Message-ID: <064.a0debcb7f3f3224fe1dd2f980dbfac72@tools.ietf.org> References: <055.c2df21e47095fbec7400989f77132d30@tools.ietf.org> X-Trac-Ticket-ID: 12 In-Reply-To: <055.c2df21e47095fbec7400989f77132d30@tools.ietf.org> 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: Re: [Roll] [roll] #12: DIS 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, 03 Dec 2009 14:58:55 -0000 #12: DIS --------------------------------+------------------------------------------- Reporter: jpv@… | Owner: wintert@… Type: defect | Status: closed Priority: trivial | Milestone: Component: rpl | Version: Severity: Active WG Document | Resolution: fixed Keywords: | --------------------------------+------------------------------------------- Changes (by jpv@…): * status: new => closed * resolution: => fixed Comment: The use of Trickle serves to randomize the response to DIS messages. For -05, RPL text is updated to clarify: o When a node receives a multicast DIS message, it MUST reset the trickle timer to the minimum value. o When a node receives a unicast DIS message, it MUST unicast a DIO message in response, and include the DAG Configuration Object. In this case the node SHOULD NOT reset the trickle timer. -- Ticket URL: roll From trac@tools.ietf.org Thu Dec 3 06:59:18 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 36C763A6A36 for ; Thu, 3 Dec 2009 06:59:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.458 X-Spam-Level: X-Spam-Status: No, score=-102.458 tagged_above=-999 required=5 tests=[AWL=0.142, 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 orPgYzuF2thU for ; Thu, 3 Dec 2009 06:59:17 -0800 (PST) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:1112:1:214:22ff:fe1f:1e54]) by core3.amsl.com (Postfix) with ESMTP id 87DD73A6974 for ; Thu, 3 Dec 2009 06:59:17 -0800 (PST) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1NGD9B-000658-Nk; Thu, 03 Dec 2009 06:59:09 -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.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.5, by Edgewall Software To: jpv@cisco.com X-Trac-Project: roll Date: Thu, 03 Dec 2009 14:59:09 -0000 X-URL: http://tools.ietf.org/wg/roll/ X-Trac-Ticket-URL: http://tools.ietf.org/wg/roll/trac/ticket/15#comment:1 Message-ID: <066.4d56e8510719dd8fc9beb459ad94aec9@tools.ietf.org> References: <057.91a0dc0643969b3a1f112b3cac4096e0@tools.ietf.org> X-Trac-Ticket-ID: 15 In-Reply-To: <057.91a0dc0643969b3a1f112b3cac4096e0@tools.ietf.org> 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: Re: [Roll] [roll] #15: Inconsistent prefix-length 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, 03 Dec 2009 14:59:18 -0000 #15: Inconsistent prefix-length ---------------------------------------+------------------------------------ Reporter: joakime@… | Owner: Type: defect | Status: closed Priority: minor | Milestone: Component: rpl | Version: Severity: Active WG Document | Resolution: fixed Keywords: destination prefix length | ---------------------------------------+------------------------------------ Changes (by jpv@…): * status: new => closed * resolution: => fixed Comment: For -05, RPL text is corrected: The Prefix Length is an 8-bit unsigned integer that indicates the number of leading bits in the destination prefix. -- Ticket URL: roll From trac@tools.ietf.org Thu Dec 3 06:59:45 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 42F2428C183 for ; Thu, 3 Dec 2009 06:59:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.466 X-Spam-Level: X-Spam-Status: No, score=-102.466 tagged_above=-999 required=5 tests=[AWL=0.134, 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 q9MtzInoKITT for ; Thu, 3 Dec 2009 06:59:44 -0800 (PST) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:1112:1:214:22ff:fe1f:1e54]) by core3.amsl.com (Postfix) with ESMTP id 97A5A28C182 for ; Thu, 3 Dec 2009 06:59:44 -0800 (PST) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1NGD9a-0006RG-Qy; Thu, 03 Dec 2009 06:59:34 -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.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.5, by Edgewall Software To: wintert@acm.org, jpv@cisco.com X-Trac-Project: roll Date: Thu, 03 Dec 2009 14:59:34 -0000 X-URL: http://tools.ietf.org/wg/roll/ X-Trac-Ticket-URL: http://tools.ietf.org/wg/roll/trac/ticket/5#comment:1 Message-ID: <064.b8ca6a061866dc4f523f20d720aef9ec@tools.ietf.org> References: <055.cd43776192c185ba307f01db1a65a371@tools.ietf.org> X-Trac-Ticket-ID: 5 In-Reply-To: <055.cd43776192c185ba307f01db1a65a371@tools.ietf.org> 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: Re: [Roll] [roll] #5: DODAG 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, 03 Dec 2009 14:59:45 -0000 #5: DODAG --------------------------------+------------------------------------------- Reporter: jpv@… | Owner: wintert@… Type: defect | Status: closed Priority: major | Milestone: Component: rpl | Version: Severity: Active WG Document | Resolution: fixed Keywords: | --------------------------------+------------------------------------------- Changes (by jpv@…): * status: new => closed * resolution: => fixed Comment: For -05, RPL text has been updated throughout to use the terminology "DAG Instance", "DODAG", and "DODAG Iteration". "DODAG" is the more appropriate term than "DAG". -- Ticket URL: roll From trac@tools.ietf.org Thu Dec 3 07:00:59 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 602883A6A65 for ; Thu, 3 Dec 2009 07:00:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.474 X-Spam-Level: X-Spam-Status: No, score=-102.474 tagged_above=-999 required=5 tests=[AWL=0.126, 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 xDG8hqpRDtmN for ; Thu, 3 Dec 2009 07:00:58 -0800 (PST) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:1112:1:214:22ff:fe1f:1e54]) by core3.amsl.com (Postfix) with ESMTP id AB53628C0F5 for ; Thu, 3 Dec 2009 07:00:58 -0800 (PST) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1NGDAo-0007kO-NN; Thu, 03 Dec 2009 07:00:50 -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.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.5, by Edgewall Software To: wintert@acm.org, jpv@cisco.com X-Trac-Project: roll Date: Thu, 03 Dec 2009 15:00:50 -0000 X-URL: http://tools.ietf.org/wg/roll/ X-Trac-Ticket-URL: http://tools.ietf.org/wg/roll/trac/ticket/4#comment:1 Message-ID: <064.2f9a8516ec0f046c415fa79e21b196b0@tools.ietf.org> References: <055.78d9321183257c63ddf9765eee95d643@tools.ietf.org> X-Trac-Ticket-ID: 4 In-Reply-To: <055.78d9321183257c63ddf9765eee95d643@tools.ietf.org> 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: Re: [Roll] [roll] #4: Write an FSM for RPL 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, 03 Dec 2009 15:00:59 -0000 #4: Write an FSM for RPL --------------------------------+------------------------------------------- Reporter: jpv@… | Owner: wintert@… Type: task | Status: new Priority: major | Milestone: Component: rpl | Version: Severity: Active WG Document | Keywords: --------------------------------+------------------------------------------- Changes (by jpv@…): * type: defect => task Comment: The FSM may be added as a separate informational document -- Ticket URL: roll From jvasseur@cisco.com Thu Dec 3 07:40:40 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 069303A6A6D for ; Thu, 3 Dec 2009 07:40:40 -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.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_HTML_MOSTLY=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 88NKXhSp6zhi for ; Thu, 3 Dec 2009 07:40:39 -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 B92C73A6A65 for ; Thu, 3 Dec 2009 07:40:38 -0800 (PST) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-Files: None : None X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlUFAFNrF0tAZnwN/2dsb2JhbACCIi6+WJdphDIE X-IronPort-AV: E=Sophos;i="4.47,335,1257120000"; d="scan'208,217";a="71881290" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 03 Dec 2009 15:40:16 +0000 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id nB3FeFTJ011625 for ; Thu, 3 Dec 2009 15:40:15 GMT Received: from xfe-rtp-212.amer.cisco.com ([64.102.31.100]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 3 Dec 2009 10:40:15 -0500 Received: from ams-jvasseur-8715.cisco.com ([10.55.201.134]) by xfe-rtp-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 3 Dec 2009 10:40:14 -0500 Message-Id: From: JP Vasseur To: ROLL WG Content-Type: multipart/alternative; boundary=Apple-Mail-37-227253471 Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 3 Dec 2009 16:40:11 +0100 References: <20091203123005.888203A6A42@core3.amsl.com> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 03 Dec 2009 15:40:15.0561 (UTC) FILETIME=[E8BEB390:01CA742E] Subject: [Roll] Fwd: I-D Action:draft-ietf-roll-routing-metrics-04.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Dec 2009 15:40:40 -0000 --Apple-Mail-37-227253471 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit The OCP Object defined in this ID has been modified in revision 04 to be carried as a suboption of the DIO Base option, with makes more sense than in the DAG Metric Container and a new suboption type has been assigned TBC by IANA. Thanks. JP, Mijeom and Kris. Begin forwarded message: > From: Internet-Drafts@ietf.org > Date: December 3, 2009 1:30:05 PM CEST > To: i-d-announce@ietf.org > Cc: roll@ietf.org > Subject: I-D Action:draft-ietf-roll-routing-metrics-04.txt > Reply-To: internet-drafts@ietf.org > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Routing Over Low power and Lossy > networks Working Group of the IETF. > > > Title : Routing Metrics used for Path Calculation in Low > Power and Lossy Networks > Author(s) : J. Vasseur, D. Networks > Filename : draft-ietf-roll-routing-metrics-04.txt > Pages : 29 > Date : 2009-12-03 > > 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-04.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-37-227253471 Content-Type: multipart/mixed; boundary=Apple-Mail-38-227253471 --Apple-Mail-38-227253471 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable

The OCP Object defined in this ID has been modified in = revision 04 to be carried as a suboption of the DIO Base option, with = makes more sense than in the DAG Metric Container and a new suboption = type has been assigned TBC by IANA.

Thanks.

JP, Mijeom and = Kris.


Begin forwarded message:

Date: December 3, 2009 1:30:05 PM = CEST
To: i-d-announce@ietf.org
Subject: = I-D Action:draft-ietf-roll-routing-metrics-04.txt 

A New = Internet-Draft is available from the on-line Internet-Drafts = directories.
This draft is a work item of the Routing Over Low power = and Lossy networks Working Group of the IETF.


Title =           : Routing = Metrics used for Path Calculation in Low Power and Lossy = Networks
= Author(s)       : J. Vasseur, D. = Networks
= Filename        : = draft-ietf-roll-routing-metrics-04.txt
Pages =           : = 29
= Date =            : = 2009-12-03

Low power and Lossy Networks (LLNs) have unique = characteristics
compared with traditional wired and ad-hoc networks = that require the
specification of new routing metrics and = constraints.  By contrast
with typical Interior Gateway Protocol = (IGP) routing metrics using
hop counts or link metrics, this document = specifies a set of link and
node routing metrics and constraints = suitable to LLNs.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-roll-routing-metr= ics-04.txt

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

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

--Apple-Mail-38-227253471 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-38-227253471-- --Apple-Mail-37-227253471-- From alexandru.petrescu@gmail.com Thu Dec 3 08:37:03 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C41E23A682B for ; Thu, 3 Dec 2009 08:37:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.294 X-Spam-Level: X-Spam-Status: No, score=-2.294 tagged_above=-999 required=5 tests=[AWL=-0.045, BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7t33Rl7z2M8S for ; Thu, 3 Dec 2009 08:37:03 -0800 (PST) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.166.172.107]) by core3.amsl.com (Postfix) with ESMTP id D307D3A66B4 for ; Thu, 3 Dec 2009 08:37:02 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.0) with ESMTP id nB3Gaqbg021245 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 3 Dec 2009 17:36:52 +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 nB3GaqNm024120; Thu, 3 Dec 2009 17:36:52 +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 nB3GapRE028067; Thu, 3 Dec 2009 17:36:51 +0100 Message-ID: <4B17E923.5030604@gmail.com> Date: Thu, 03 Dec 2009 17:36:51 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: roll@ietf.org References: <20091203123005.888203A6A42@core3.amsl.com> In-Reply-To: <20091203123005.888203A6A42@core3.amsl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [Roll] I-D Action:draft-ietf-roll-routing-metrics-04.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Dec 2009 16:37:03 -0000 Internet-Drafts@ietf.org a écrit : > 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, D. Networks ROLLers, I believe we should do something about this. It's now the 5th revision of this draft that I see authored by a mysterious D. Networks :-) Alex > Filename : draft-ietf-roll-routing-metrics-04.txt > Pages : 29 > Date : 2009-12-03 > > 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-04.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 From jvasseur@cisco.com Thu Dec 3 08:39:26 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A245B3A67FA for ; Thu, 3 Dec 2009 08:39:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.551 X-Spam-Level: X-Spam-Status: No, score=-7.551 tagged_above=-999 required=5 tests=[AWL=-0.952, 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 1u7AOe5e+lle for ; Thu, 3 Dec 2009 08:39:25 -0800 (PST) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id B95253A676A for ; Thu, 3 Dec 2009 08:39:25 -0800 (PST) Authentication-Results: sj-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAPp3F0urRN+J/2dsb2JhbADBH5dfhDIE X-IronPort-AV: E=Sophos;i="4.47,336,1257120000"; d="scan'208";a="227010768" Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-2.cisco.com with ESMTP; 03 Dec 2009 16:39:17 +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 nB3GdCZ9009347; Thu, 3 Dec 2009 16:39:17 GMT Received: from xfe-ams-101.cisco.com ([144.254.231.93]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 3 Dec 2009 17:39:14 +0100 Received: from ams-jvasseur-8715.cisco.com ([10.55.201.134]) by xfe-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 3 Dec 2009 17:39:13 +0100 Message-Id: From: JP Vasseur To: Alexandru Petrescu In-Reply-To: <4B17E923.5030604@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 3 Dec 2009 17:39:13 +0100 References: <20091203123005.888203A6A42@core3.amsl.com> <4B17E923.5030604@gmail.com> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 03 Dec 2009 16:39:14.0248 (UTC) FILETIME=[25F77C80:01CA7437] Cc: roll@ietf.org Subject: Re: [Roll] I-D Action:draft-ietf-roll-routing-metrics-04.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Dec 2009 16:39:26 -0000 On Dec 3, 2009, at 5:36 PM, Alexandru Petrescu wrote: > Internet-Drafts@ietf.org a =E9crit : >> A New Internet-Draft is available from the on-line Internet-Drafts =20= >> directories. >> This draft is a work item of the Routing Over Low power and Lossy =20 >> networks Working Group of the IETF. >> Title : Routing Metrics used for Path Calculation in = Low =20 >> Power and Lossy Networks >> Author(s) : J. Vasseur, D. Networks > > ROLLers, > > I believe we should do something about this. > > It's now the 5th revision of this draft that I see authored by a =20 > mysterious D. Networks :-) ;-) Automatically generated by the uploader ... that may trigger =20 curiosity and interest of people to read the document, good thing ;-) > > Alex > >> Filename : draft-ietf-roll-routing-metrics-04.txt >> Pages : 29 >> Date : 2009-12-03 >> 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-04.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 > > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From jhui@archrock.com Thu Dec 3 10:32:51 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 879BB3A681F for ; Thu, 3 Dec 2009 10:32:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.656 X-Spam-Level: X-Spam-Status: No, score=-1.656 tagged_above=-999 required=5 tests=[AWL=-0.857, BAYES_00=-2.599, J_CHICKENPOX_72=0.6, J_CHICKENPOX_73=0.6, J_CHICKENPOX_74=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 VusBsTmZDT5Q for ; Thu, 3 Dec 2009 10:32: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 C8EF13A6807 for ; Thu, 3 Dec 2009 10:32:50 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.sf.archrock.com (Postfix) with ESMTP id 46EEAAF840; Thu, 3 Dec 2009 10:32:41 -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 c-Tm7Jsgackj; Thu, 3 Dec 2009 10:32:36 -0800 (PST) Received: from [192.168.7.30] (69-12-164-136.sfo.archrock.com [69.12.164.136]) by mail.sf.archrock.com (Postfix) with ESMTP id 540BBAF81F; Thu, 3 Dec 2009 10:32:36 -0800 (PST) Message-Id: <48F0D412-4C69-41D9-A04C-C8989DA49226@archrock.com> From: Jonathan Hui To: Richard Kelsey In-Reply-To: <87my22ks2m.fsf@kelsey-ws.hq.ember.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 3 Dec 2009 10:32:35 -0800 References: <6A2A459175DABE4BB11DE2026AA50A5DBD5226@XMB-AMS-107.cisco.com> <877ht620jn.fsf@kelsey-ws.hq.ember.com> <6A2A459175DABE4BB11DE2026AA50A5DC57E84@XMB-AMS-107.cisco.com> <87my22ks2m.fsf@kelsey-ws.hq.ember.com> X-Mailer: Apple Mail (2.936) Cc: roll@ietf.org Subject: Re: [Roll] updating DAO caches - a 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, 03 Dec 2009 18:32:51 -0000 On Dec 1, 2009, at 6:50 PM, Richard Kelsey wrote: >> Date: Tue, 1 Dec 2009 17:04:54 +0100 >> From: "Pascal Thubert (pthubert)" >> >> The term label is encumbered with MPLS, and seems to imply a lot more >> than we do here, like LDP, switching... Maybe in some future we'll >> integrate more "real" labels, but we're far from doing that here. > > If we do use labels, why only use them a little bit? We > need to maximize the utility of whatever mechanisms we have. > It really seems like we are piling on patch after patch and > losing sight of the big picture. Agree. In general, if we have an end-goal in mind, I'd much rather design for that end-goal than patch our way to it. In the end, if we want to use "labels" (which I think is a useful path to explore thoroughly for a number of reasons), then we should at least agree on what the solution will look like even if it is not specified in the core RPL spec. >> Richard>RPL is starting to look schizophrenic. On one hand we have >> Richard>the DAG mechanism which, especially with local repair, aims >> Richard>to make it as cheap as possible to react to changes in the >> Richard>topology. On the other hand we have the DAO mechanism which >> Richard>maintains a distributed route database and where a single >> Richard>DAG link change can trigger widespread updates. How likely >> Richard>is it that topology changes will be common enough that we >> Richard>need fast local DAG repair and also rare enough that the >> Richard>resulting DAOs successfully maintain the downward routes >> Richard>without swamping the network with control messages? We >> Richard>are in danger of painting ourselves into a corner. >> >> Good question that applies to DAO in general not just this >> mechanism :) > > To some extent yes, but it doesn't apply to all DAO > mechanisms equally. For example, sending plain record > routes, either periodically or on demand, would have much > less interaction with DIOs and DAG changes and would have a > much more predictable behavior. I also believe that DIO and DAO mechanisms should be decoupled. The coupling in small scale networks doesn't matter much. Global coordination in large scale networks is challenging. -- Jonathan Hui From Adrian.Farrel@huawei.com Thu Dec 3 10:42:56 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 682173A6359 for ; Thu, 3 Dec 2009 10:42:56 -0800 (PST) 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=[AWL=0.245, 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 vJuMkKyw+uIn for ; Thu, 3 Dec 2009 10:42:55 -0800 (PST) Received: from usaga03-in.huawei.com (usaga03-in.huawei.com [206.16.17.220]) by core3.amsl.com (Postfix) with ESMTP id 68FE63A67A5 for ; Thu, 3 Dec 2009 10:42:55 -0800 (PST) Received: from huawei.com (usaga03-in [172.18.4.17]) by usaga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KU300CGJANAOA@usaga03-in.huawei.com> for roll@ietf.org; Thu, 03 Dec 2009 12:42:46 -0600 (CST) Received: from your029b8cecfe (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) by usaga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KU3006EVAN8OI@usaga03-in.huawei.com> for roll@ietf.org; Thu, 03 Dec 2009 12:42:46 -0600 (CST) Date: Thu, 03 Dec 2009 18:42:38 +0000 From: Adrian Farrel To: JP Vasseur , Alexandru Petrescu Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-Mailer: Microsoft Outlook Express 6.00.2900.5843 Content-type: text/plain; format=flowed; charset=iso-8859-1; reply-type=response Content-transfer-encoding: 8BIT X-Priority: 3 X-MSMail-priority: Normal References: <20091203123005.888203A6A42@core3.amsl.com> <4B17E923.5030604@gmail.com> Cc: roll@ietf.org Subject: Re: [Roll] I-D Action:draft-ietf-roll-routing-metrics-04.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Adrian Farrel List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Dec 2009 18:42:56 -0000 I'm guessing this would be fixed if you used full names in the Authors' Addresses section. BTW, running idnits before submitting a draft is a nice idea (and fixing the nits :-) Cheers, Adrian ----- Original Message ----- From: "JP Vasseur" To: "Alexandru Petrescu" Cc: Sent: Thursday, December 03, 2009 4:39 PM Subject: Re: [Roll] I-D Action:draft-ietf-roll-routing-metrics-04.txt On Dec 3, 2009, at 5:36 PM, Alexandru Petrescu wrote: > Internet-Drafts@ietf.org a écrit : >> 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, D. Networks > > ROLLers, > > I believe we should do something about this. > > It's now the 5th revision of this draft that I see authored by a > mysterious D. Networks :-) ;-) Automatically generated by the uploader ... that may trigger curiosity and interest of people to read the document, good thing ;-) > > Alex > >> Filename : draft-ietf-roll-routing-metrics-04.txt >> Pages : 29 >> Date : 2009-12-03 >> 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-04.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 > > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From jvasseur@cisco.com Thu Dec 3 12:28:34 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7551C3A68EA for ; Thu, 3 Dec 2009 12:28:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.51 X-Spam-Level: X-Spam-Status: No, score=-5.51 tagged_above=-999 required=5 tests=[AWL=-2.912, 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 5vjGgkCj5ExH for ; Thu, 3 Dec 2009 12:28:33 -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 A9E483A68C2 for ; Thu, 3 Dec 2009 12:28:32 -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: AjMAADSuF0uQ/uCWe2dsb2JhbACCUJkyAQELCyQGo2iXXIQyBA X-IronPort-AV: E=Sophos;i="4.47,337,1257120000"; d="scan'208,217";a="531292" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-2.cisco.com with ESMTP; 03 Dec 2009 20:02:31 +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 nB3KSMVA018202; Thu, 3 Dec 2009 20:28:23 GMT Received: from xfe-ams-101.cisco.com ([144.254.231.93]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 3 Dec 2009 21:28:22 +0100 Received: from ams-jvasseur-8715.cisco.com ([10.55.201.134]) by xfe-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 3 Dec 2009 21:28:21 +0100 Message-Id: <9F264211-294D-4454-B439-5576CEF0BE3A@cisco.com> From: JP Vasseur To: Adrian Farrel In-Reply-To: Content-Type: multipart/alternative; boundary=Apple-Mail-62-244542964 Mime-Version: 1.0 (Apple Message framework v936) X-Priority: 3 Date: Thu, 3 Dec 2009 21:28:20 +0100 References: <20091203123005.888203A6A42@core3.amsl.com> <4B17E923.5030604@gmail.com> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 03 Dec 2009 20:28:21.0461 (UTC) FILETIME=[27F1B850:01CA7457] Cc: roll@ietf.org Subject: Re: [Roll] I-D Action:draft-ietf-roll-routing-metrics-04.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Dec 2009 20:28:34 -0000 --Apple-Mail-62-244542964 Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable On Dec 3, 2009, at 7:42 PM, Adrian Farrel wrote: > I'm guessing this would be fixed if you used full names in the =20 > Authors' Addresses section. > > BTW, running idnits before submitting a draft is a nice idea (and =20 > fixing the nits :-) > Not a catastrophic error ;-) ** There are 3 instances of too long lines in the document, the =20 longest one being 2 characters in excess of 72. > Cheers, > Adrian > ----- Original Message ----- From: "JP Vasseur" > To: "Alexandru Petrescu" > Cc: > Sent: Thursday, December 03, 2009 4:39 PM > Subject: Re: [Roll] I-D Action:draft-ietf-roll-routing-metrics-04.txt > > > > On Dec 3, 2009, at 5:36 PM, Alexandru Petrescu wrote: > >> Internet-Drafts@ietf.org a =E9crit : >>> A New Internet-Draft is available from the on-line Internet-Drafts =20= >>> directories. >>> This draft is a work item of the Routing Over Low power and Lossy =20= >>> networks Working Group of the IETF. >>> Title : Routing Metrics used for Path Calculation in =20 >>> Low Power and Lossy Networks >>> Author(s) : J. Vasseur, D. Networks >> >> ROLLers, >> >> I believe we should do something about this. >> >> It's now the 5th revision of this draft that I see authored by a =20 >> mysterious D. Networks :-) > > ;-) Automatically generated by the uploader ... that may trigger > curiosity and interest of people to read the document, good thing ;-) > >> >> Alex >> >>> Filename : draft-ietf-roll-routing-metrics-04.txt >>> Pages : 29 >>> Date : 2009-12-03 >>> 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 =20= >>> 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-04.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 >> >> >> _______________________________________________ >> Roll mailing list >> Roll@ietf.org >> https://www.ietf.org/mailman/listinfo/roll > > _______________________________________________ > Roll mailing 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-62-244542964 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Dec 3, 2009, = at 7:42 PM, Adrian Farrel wrote:

I'm = guessing this would be fixed if you used full names in the Authors' = Addresses section.

BTW, running idnits before submitting a draft = is a nice idea (and fixing the nits = :-)


Not a catastrophic = error ;-)
 =
** There are 3 instances of too long lines in the document, the longest =
one
     being 2 characters in excess of =
72.

Cheers,
Adrian
----- Original Message ----- = From: "JP Vasseur" <jvasseur@cisco.com>
To: = "Alexandru Petrescu" <alexandru.petrescu@gmail.com<= /a>>
Cc: <roll@ietf.org>
Sent: Thursday, = December 03, 2009 4:39 PM
Subject: Re: [Roll] I-D = Action:draft-ietf-roll-routing-metrics-04.txt



On Dec 3, = 2009, at 5:36 PM, Alexandru Petrescu wrote:

Internet-Drafts@ietf.org a = =E9crit :
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, D. = Networks

ROLLers,

I believe we = should do something about this.

It's now the = 5th revision of this draft that I see authored by a mysterious D. = Networks :-)

;-) Automatically generated by the = uploader ... that may trigger
curiosity and interest of people to = read the document, good thing ;-)


Alex

Filename        : = draft-ietf-roll-routing-metrics-04.txt
Pages =           : = 29
Date =            : = 2009-12-03
Low power and Lossy Networks = (LLNs) have unique = characteristics
compared with traditional wired = and ad-hoc networks that require = the
specification of new routing metrics and constraints. =  By contrast
with typical Interior Gateway = Protocol (IGP) routing metrics = using
hop counts or link metrics, this document specifies a set = of link and
node routing metrics and = constraints suitable to LLNs.
A URL for this Internet-Draft = is:
http://www.ietf.org/internet-drafts/draft-ietf-roll-routing-metr= ics-04.txt
Internet-Drafts are also = available by anonymous FTP at:
ftp://ftp.ietf.org/internet-d= rafts/
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.ie= tf.org/mailman/listinfo/i-d-announce
Internet-Draft = directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf= /1shadow-sites.txt


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

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

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

= --Apple-Mail-62-244542964-- From pal@cs.stanford.edu Thu Dec 3 15:42:47 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 392CC3A68F1 for ; Thu, 3 Dec 2009 15:42:47 -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=[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 ezAWRqC3MbR3 for ; Thu, 3 Dec 2009 15:42:46 -0800 (PST) Received: from cs-smtp-1.Stanford.EDU (cs-smtp-1.Stanford.EDU [171.64.64.25]) by core3.amsl.com (Postfix) with ESMTP id 7F3493A68DF for ; Thu, 3 Dec 2009 15:42:46 -0800 (PST) Received: from dnab40461d.stanford.edu ([171.64.70.29]) by cs-smtp-1.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1NGLJj-00032y-Qc; Thu, 03 Dec 2009 15:42:36 -0800 Message-Id: <0272DA19-AA52-4B8C-A434-6C45E6B7919F@cs.stanford.edu> From: Philip Levis To: Richard Kelsey In-Reply-To: <87k4xe207c.fsf@kelsey-ws.hq.ember.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 3 Dec 2009 15:42:35 -0800 References: <9F5AB59D-5673-4C75-A953-33C3384527E6@cs.stanford.edu> <87k4xe207c.fsf@kelsey-ws.hq.ember.com> X-Mailer: Apple Mail (2.936) X-Scan-Signature: f9929892efd47015c544d6ca2fb551e9 Cc: roll@ietf.org Subject: Re: [Roll] multicast DAO X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Dec 2009 23:42:47 -0000 On Nov 25, 2009, at 5:39 AM, Richard Kelsey wrote: >> Date: Wed, 25 Nov 2009 10:43:41 +0100 >> From: "Julien Abeille (jabeille)" > >>> From: Philip Levis [mailto:pal@cs.stanford.edu] >>> Sent: vendredi 20 novembre 2009 19:31 >>> >>> Point-to-point communication between nodes is needed by some >>> applications. Section 5.2.2 of >>> draft-ietf-roll-building-routing-reqs-07: >>> >>> "A network device MUST be able to communicate in a >>> point-to-point manner with any other device on the network." >> >> Sure, and DAOs (whether stored only at root are not) solve this >> issue. >> May not be the most efficient, but the sceanrios multicast DAOs solve >> are so limited that we will end up with 10 solutions for 10 >> scenarios if >> we go that path. >> >> I would personaly drop multicast DAOs > > I agree. As we have done with unicasts, we need to look > carefully at the multicast requirements and find ways to > solve the easy and/or common cases first. I do not think > that there is a workable one-size-fits-all multicast > solution. Richard and I discussed this further: turns out he was misunderstanding the case I was describing. Based on the fact that many application domains require point-to-point routing and the expectation is many networks will be at most a few hops across, there seems to be some consensus that keeping multicast DAOs in is worthwhile. JP will have some results indicating how much complexity they might add to an implementation: his experience is not much. So the current resolution is to keep multicast DAOs in, as the belief is the use case described originally by Julien is an important enough optimization to warrant their inclusion. Phil From pthubert@cisco.com Fri Dec 4 02:21:38 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 64E793A68B6 for ; Fri, 4 Dec 2009 02:21:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.238 X-Spam-Level: X-Spam-Status: No, score=-5.238 tagged_above=-999 required=5 tests=[AWL=-3.640, BAYES_00=-2.599, EXTRA_MPART_TYPE=1, 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 gZPgarBeMxLN for ; Fri, 4 Dec 2009 02:21:32 -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 E1E923A68B3 for ; Fri, 4 Dec 2009 02:21:31 -0800 (PST) Authentication-Results: ams-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-Files: image003.jpg : 1983 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjsAAN5xGEuQ/uCWiWdsb2JhbACCJSuWIoMQAQEBCgsREwahTJdLAoQxBA X-IronPort-AV: E=Sophos;i="4.47,340,1257120000"; d="jpg'145?scan'145,208,217,145";a="571071" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-2.cisco.com with ESMTP; 04 Dec 2009 09:55:28 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id nB4ALMep003156 for ; Fri, 4 Dec 2009 10: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); Fri, 4 Dec 2009 11:21:21 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 MIME-Version: 1.0 Content-Type: multipart/related; boundary="----_=_NextPart_001_01CA74CB.8698864B"; type="multipart/alternative" X-CR-Puzzleid: {967C6087-7B1C-4396-81C5-0730A4245F77} X-CR-Hashedpuzzle: +MQ= AZdD AdMr DKKu DZ2s DbOZ DcGP DxtF D05v E1Po FokJ GX1P Ibj8 JYui Jav7 J2zY; 1; cgBvAGwAbABAAGkAZQB0AGYALgBvAHIAZwA=; Sosha1_v1; 7; {967C6087-7B1C-4396-81C5-0730A4245F77}; cAB0AGgAdQBiAGUAcgB0AEAAYwBpAHMAYwBvAC4AYwBvAG0A; Fri, 04 Dec 2009 10:13:38 GMT; IwAxADYA Content-class: urn:content-classes:message Date: Fri, 4 Dec 2009 11:21:21 +0100 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5DCB61E4@XMB-AMS-107.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: #16 Thread-Index: Acp0ynJLQoXUd6iTTJCP8JXamj5kxw== From: "Pascal Thubert (pthubert)" To: "Mathilde Durvy (mdurvy)" X-OriginalArrivalTime: 04 Dec 2009 10:21:21.0899 (UTC) FILETIME=[869B53B0:01CA74CB] Cc: roll@ietf.org Subject: [Roll] #16 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 04 Dec 2009 10:21:38 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA74CB.8698864B Content-Type: multipart/alternative; boundary="----_=_NextPart_002_01CA74CB.8698864B" ------_=_NextPart_002_01CA74CB.8698864B Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Mathilde =20 Issue 16 says "Hi All, This is my current understanding: - Parents are removed based on OF selection (decision to move within the DAG, change DAG, etc) - Destination prefixes are removed after the retry / RemoveTimer? procedure described in section 5.10.1.1.1. This is essentially a keep alive mechanism based on DIO (D bit set) - DAO exchanges. - Route corresponding to destination prefixes are removed when DAO lifetime expires? Are they also removed when the corresponding destination prefix is removed? - When are routes corresponding to parents removed? Do they also have a lifetime? - What happens when a neighbor disappears, are the corresponding parents/destination/routes removed? The current behavior seems quite asymmetric... There is some kind of keep alive mechanism for destination prefixes, but not for parents. There is a lifetime associated with routes corresponding to destination prefixes but not for routes corresponding to parents. Is that a design choice? I would appreciate some clarifications. " =20 Proposed new text : =20 If Neighbor Unreachability Detection (NUD), or an equivalent mechanism, determines that a neighbor is no longer reachable, then a RPL node MUST NOT consider this node in the neighbor set when calculating and advertising routes until the node determines it is reachable again. =20 Routes via that neighbor MUST be eliminated from the routing table, and the node SHOULD poison using no-DAO all DAO routes that it has advertised via DAO and that it can reach only via that neighbor. =20 The internals (keeping info about the DAOs to resync more quickly) are not described, long as the node behaves as if it has cleaned everything reachable only via the lost neighbor. =20 We'll be working on solidifying the D-bit and the DAO for ticket #17, making it more reliable. But that cannot be done in the time frame for rel 5. Would the text above satisfy you for the time being? =20 =20 =20 =20 Pascal Thubert IP Engineering TC pthubert@cisco.com =20 Phone :+33 497 23 26 34 Mobile :+33 619 98 29 85 Cisco Systems Village d'Entreprises Green Side bat. T3=20 400, Avenue Roumanille 06410 Biot - Sophia Antipolis =20 France www.cisco.com/global/FR/ =20 This e-mail may contain confidential and privileged material for the sole use of the intended recipient. Any review, use, distribution or disclosure by others is strictly prohibited. If you are not the intended recipient (or authorized to receive for the recipient), please contact the sender by reply e-mail and delete all copies of this message. =20 =20 ------_=_NextPart_002_01CA74CB.8698864B Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Mathilde

 

Issue 16 says “Hi All, This is my current understanding: - Parents are removed based on OF selection (decision to = move within the DAG, change DAG, etc) - Destination prefixes are removed = after the retry / RemoveTimer? procedure described in section 5.10.1.1.1. This is = essentially a keep alive mechanism based on DIO (D bit set) - DAO exchanges. - Route corresponding to destination prefixes are removed when DAO lifetime = expires? Are they also removed when the corresponding destination prefix is = removed? - When are routes corresponding to parents removed? Do they also have a = lifetime? - What happens when a neighbor disappears, are the corresponding parents/destination/routes removed? The current behavior seems quite asymmetric... There is some kind of keep alive mechanism for destination prefixes, but not for parents. There is a lifetime associated with = routes corresponding to destination prefixes but not for routes corresponding = to parents. Is that a design choice? I would appreciate some = clarifications. ”

 

Proposed new text :

 

   If Neighbor Unreachability Detection (NUD), or an = equivalent

   mechanism, determines that a neighbor is no longer reachable, then = a

   RPL node MUST NOT consider this node in the neighbor set = when

   calculating and advertising routes until the node determines it = is

   reachable again.

 

   Routes via that neighbor MUST be eliminated from the routing = table,

   and the node SHOULD poison using no-DAO all DAO routes that = it

   has advertised via DAO and that it can reach only via that = neighbor.

 

The internals (keeping info about the DAOs to = resync more quickly) are not described, long as the node behaves as if it has = cleaned everything reachable only via the lost neighbor.

 

We’ll be working on solidifying the D-bit and = the DAO for ticket #17, making it more reliable. But that cannot be done in the = time frame for rel 5.

Would the text above satisfy you for the time = being?

 

 

 

<= /p>

= Pascal Thubert
IP Engineering TC

pthubert@cisco.com
Phone :+33 497 23 26 34
Mobile :+33 619 98 29 85

Cisco = Systems=
  Village d'Entreprises Green Side bat. T3
  400, Avenue Roumanille
  06410 Biot - Sophia Antipolis 
  France
  www.cisco.com/global/FR/

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

 

 

------_=_NextPart_002_01CA74CB.8698864B-- ------_=_NextPart_001_01CA74CB.8698864B Content-Type: image/jpeg; name="image003.jpg" Content-Transfer-Encoding: base64 Content-ID: Content-Description: image003.jpg Content-Location: image003.jpg /9j/4AAQSkZJRgABAQEAYABgAAD/2wBDAAoHBwgHBgoICAgLCgoLDhgQDg0NDh0VFhEYIx8lJCIf IiEmKzcvJik0KSEiMEExNDk7Pj4+JS5ESUM8SDc9Pjv/2wBDAQoLCw4NDhwQEBw7KCIoOzs7Ozs7 Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozv/wAARCABWAIEDASIA AhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQA AAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3 ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWm p6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEA AwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSEx BhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElK U1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3 uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwD2aiii gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKoXms2djqFrYzybZrokRi nLq1m2rNpYlH2lU3lPauP8Yf8j94d/3l/wDQ6uMbuzM5zsro72iqeparaaTAs95J5aO4QH3NW1IZ QwOQRkVFi79BaKazBFLMcBRkmqumapaatbG4s5N8YYqT7iiwX6DLLWbPUL26tLeTdLattkFX64Lw R/yOfiH/AK6H/wBDNdh/a1mNXGl+aPtRj8zZ7Vco2dkRCd43ZdoooqDQKKKKACiiigAooooAK5fw n4ivNa1PVre5VAlrLiPb6ZI/pXUVTstKs9PmuJraII9y++QjuapNWZLTurHHW3/JYbj/AK4f+yLR 4w/5H7w7/vD/ANDrsV0qzXVG1MRD7SybC/tWJr/h651LxTpGoxMBFaN+8z7HNaKS5l6GMoNRa8zO +Kn/ACA7P/r5/wDZTW9reozaT4SlvrcKZYoFK7unOB/Wr+o6ZaarAsN5EJEVw4B9RUl1ZwXlnJaT oGhkXay+1RzKyRfI7ya6mXpeoTar4OS+nCiWa2YsF6ZwRWJ8LP8AkXJ/+vk/+giuvt7SC1s0tIkC wouwL7VHp2mWulWxt7OMRxlixHuaOZWaHyPmTfQ43wR/yOfiH/rof/QzSt/yWRf+vb/2nWr4c8PX OleIdXvpmBju3zHj0JJ/rW3/AGXaHVRqflD7SE2b/arclzP0M4wfKl5mH4n8RXmka5pFnbqhju5M SbuuMgf1rqKp3mlWd9c29xcRB5LZt0ZPY1crNtWVjZJpu4UUUVJQUUUUAFFFFABSMwVSzHAAyTS1 S1iGW40e8hgz5jwsFx64oGld2OH1X4qEahJZ6Fpj3/lEhn5wcemO1dXpWvSah4XGsSWphk8tnMLc YK9v0rzz4X65o+hpf2eqyJa3ZlzvkHUAYK5+ua9HnvrTUvDV1dWMiyQPDJtZRweDmsYSbV2z0cVS hTkqcYbW17lHwl4s/wCEl0efUZrUWqwOVID7uAOvQVzh+J2o3l5N/Y+gS3lpC2HkGc/pUnwoWJ/C d6s2PLMzB8+mOa5fV7c+C2Oo+GvEqSwyy824bLd+o7ipcpcqZtChR9vOnbXpvY9Y1DXbTStDGq35 MMexWKH72SPu/WuJtfinfXt7GYNBkNk8oTzeSRn8MUz4gyXmtfDzTtS8srkrJMqjgZHWtnwx4v8A DC+HbGBbmGB1RY2gI539Dx7mqcm5WvYyhRhCjzuHM7tehq+KfFth4WsUnug0ksv+qhXq3/1q5PTv i0TeImr6W9pbynCSjPT15/pVP4oIbXxXpGp3cRlsFChh1Bw2SPypfiP4l0DV/D9vaaa8dzcu6tH5 a8xj0/piplN3euxrQw1NwgnFvm3fY9SjkSaJZY2DI4BUjuKfWV4YgmtvDOnQXAIlS3UOD1zitWt1 seTJJSaQUUUUyQooooAKKKKACiiigDntW8C+HdZuTc3dgPOPLPGxUt9cVp2Wj2NhpS6Xbw7bVUKb Mk8HrzV6ilyq9zR1ZuKi27IzdL8P6Xo1lLZWFqIYJSS6bic5+prGh+GvhaC5WcWBZlbdh5CR+VdX RS5Y9hqvVTbUnruRPbQSWxtniRoSu0xkcY9MVzi/Dnwwl8t2lhtdXDhRIdoP0rqKKbinuKFWcL8r auVNQ0yy1W0a0vrdJ4W/hYVjab4A8N6Vdi6t7AGVfumRi20+oBrpKKHFN3YRq1IxcYtpBRRRTMwo oooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKAP/Z ------_=_NextPart_001_01CA74CB.8698864B-- From mdurvy@cisco.com Fri Dec 4 05:59:46 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A20E53A6868 for ; Fri, 4 Dec 2009 05:59:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.064 X-Spam-Level: X-Spam-Status: No, score=-5.064 tagged_above=-999 required=5 tests=[AWL=-2.466, 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 U7tFW+f4sDoF for ; Fri, 4 Dec 2009 05:59:41 -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 CE2773A659B for ; Fri, 4 Dec 2009 05:59:40 -0800 (PST) Authentication-Results: ams-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-Files: smime.p7s : 4235 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjoAADekGEuQ/uCWiWdsb2JhbACCJSuZMgEBAQoLERMGoxCXRYQzBA X-IronPort-AV: E=Sophos;i="4.47,341,1257120000"; d="p7s'?scan'208,217";a="594045" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-2.cisco.com with ESMTP; 04 Dec 2009 13:33: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 nB4DxVtB006489 for ; Fri, 4 Dec 2009 13:59:31 GMT Received: from xmb-ams-103.cisco.com ([144.254.74.78]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 4 Dec 2009 14:59:30 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 4 Dec 2009 14:59:29 +0100 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_04EB_01CA74F2.6123BC40" Message-ID: <8A977BDC5A7B0E429B0F521E8D6F91EEDF9592@XMB-AMS-103.cisco.com> In-Reply-To: <6A2A459175DABE4BB11DE2026AA50A5DCB61E4@XMB-AMS-107.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: #16 Thread-Index: Acp0ynJLQoXUd6iTTJCP8JXamj5kxwAHX6tg References: <6A2A459175DABE4BB11DE2026AA50A5DCB61E4@XMB-AMS-107.cisco.com> From: "Mathilde Durvy (mdurvy)" To: "Pascal Thubert (pthubert)" X-OriginalArrivalTime: 04 Dec 2009 13:59:30.0910 (UTC) FILETIME=[0043E7E0:01CA74EA] Cc: roll@ietf.org Subject: Re: [Roll] #16 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 04 Dec 2009 13:59:46 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_04EB_01CA74F2.6123BC40 Content-Type: multipart/alternative; boundary="----=_NextPart_001_04EC_01CA74F2.6123BC40" ------=_NextPart_001_04EC_01CA74F2.6123BC40 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Pascal, Thanks for the update. Please see my questions below. Best, Mathilde _____ Issue 16 says "Hi All, This is my current understanding: - Parents are removed based on OF selection (decision to move within the DAG, change DAG, etc) - Destination prefixes are removed after the retry / RemoveTimer? procedure described in section 5.10.1.1.1. This is essentially a keep alive mechanism based on DIO (D bit set) - DAO exchanges. - Route corresponding to destination prefixes are removed when DAO lifetime expires? Are they also removed when the corresponding destination prefix is removed? - When are routes corresponding to parents removed? Do they also have a lifetime? - What happens when a neighbor disappears, are the corresponding parents/destination/routes removed? The current behavior seems quite asymmetric... There is some kind of keep alive mechanism for destination prefixes, but not for parents. There is a lifetime associated with routes corresponding to destination prefixes but not for routes corresponding to parents. Is that a design choice? I would appreciate some clarifications. " Proposed new text : If Neighbor Unreachability Detection (NUD), or an equivalent mechanism, determines that a neighbor is no longer reachable, then a RPL node MUST NOT consider this node in the neighbor set when calculating and advertising routes until the node determines it is reachable again. Routes via that neighbor MUST be eliminated from the routing table, and the node SHOULD poison using no-DAO all DAO routes that it has advertised via DAO and that it can reach only via that neighbor. The internals (keeping info about the DAOs to resync more quickly) are not described, long as the node behaves as if it has cleaned everything reachable only via the lost neighbor. >> Does this mean that there is no lifetime associated with DAO routes? >> Is the retry_count + RemoveTimer procedure maintained in version 05? >> Does this mean that the local confidence is the only criteria to assess neighbor (including parents and child) reachability? Best, Mathilde ------=_NextPart_001_04EC_01CA74F2.6123BC40 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi Pascal,
 
Thanks for the update. Please see my questions=20 below.
Best,
Mathilde

 

Issue 16 says “Hi All, This is my current = understanding: -=20 Parents are removed based on OF selection (decision to move within the = DAG,=20 change DAG, etc) - Destination prefixes are removed after the retry /=20 RemoveTimer? procedure described in section 5.10.1.1.1. This is = essentially a=20 keep alive mechanism based on DIO (D bit set) - DAO exchanges. - Route=20 corresponding to destination prefixes are removed when DAO lifetime = expires? Are=20 they also removed when the corresponding destination prefix is removed? = - When=20 are routes corresponding to parents removed? Do they also have a = lifetime? -=20 What happens when a neighbor disappears, are the corresponding=20 parents/destination/routes removed? The current behavior seems quite=20 asymmetric... There is some kind of keep alive mechanism for destination = prefixes, but not for parents. There is a lifetime associated with = routes=20 corresponding to destination prefixes but not for routes corresponding = to=20 parents. Is that a design choice? I would appreciate some = clarifications.=20 ”

 

Proposed new text :

 

   If = Neighbor=20 Unreachability Detection (NUD), or an equivalent

   = mechanism,=20 determines that a neighbor is no longer reachable, then = a

   RPL = node MUST=20 NOT consider this node in the neighbor set when

   = calculating and=20 advertising routes until the node determines it is

   = reachable=20 again.  

 

   = Routes via that=20 neighbor MUST be eliminated from the routing = table,

   and = the node=20 SHOULD poison using no-DAO all DAO routes that it

   has = advertised=20 via DAO and that it can reach only via that = neighbor.

 

The internals (keeping info about the DAOs to = resync more=20 quickly) are not described, long as the node behaves as if it has = cleaned=20 everything reachable only via the lost neighbor.

>> Does this mean that there is no = lifetime=20 associated with DAO routes?

>> Is the retry_count + RemoveTimer = procedure=20 maintained in version 05?

>> Does this mean that the local = confidence is the=20 only criteria to assess neighbor (including parents and child)=20 reachability?

 

Best,

Mathilde 

 

------=_NextPart_001_04EC_01CA74F2.6123BC40-- ------=_NextPart_000_04EB_01CA74F2.6123BC40 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIL2jCCAj0w ggGmAhEAzbp/VvDf5LxU/iKss3KqVTANBgkqhkiG9w0BAQIFADBfMQswCQYDVQQGEwJVUzEXMBUG A1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDEgUHVibGljIFByaW1hcnkgQ2Vy dGlmaWNhdGlvbiBBdXRob3JpdHkwHhcNOTYwMTI5MDAwMDAwWhcNMjgwODAxMjM1OTU5WjBfMQsw CQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDEgUHVi bGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwgZ8wDQYJKoZIhvcNAQEBBQADgY0A MIGJAoGBAOUZv22jVmEtmUhx9mfeuY3rt56GgAqRDvo4Ja9GiILlc6igmyRdDR/MZW4MsNBWhBiH mgabEKFz37RYOWtuwfYV1aioP6oSBo0xrH+wNNePNGeICc0UEeJORVZpH3gCgNrcR5EpuzbJY1zF 4Ncth3uhtzKwezC6Ki8xqu6jZ9rbAgMBAAEwDQYJKoZIhvcNAQECBQADgYEATD+4i8Zo3+5DMw5d 6abLB4RNejP/khv0Nq3YlSI2aBFsfELM85wuxAc/FLAPT/+Qknb54rxK6Y/NoIAK98Up8YIiXbix 3YEjo3slFUYweRb46gVLlH8dwhzI47f0EEA8E8NfH1PoSOSGtHuhNbB7Jbq4046rPzidADQAmPPR cZQwggTFMIIDraADAgECAhABGiiLJme3TYjnRHtF1qTNMA0GCSqGSIb3DQEBBQUAMIHdMQswCQYD VQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0 IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5j b20vcnBhIChjKTA1MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlZl cmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzIwHhcNMDkxMTI2MDAw MDAwWhcNMTAxMTI2MjM1OTU5WjCCARIxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9z aXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQLExVQZXJzb25h IE5vdCBWYWxpZGF0ZWQxNDAyBgNVBAsTK0RpZ2l0YWwgSUQgQ2xhc3MgMSAtIE1pY3Jvc29mdCBG dWxsIFNlcnZpY2UxFzAVBgNVBAMUDk1hdGhpbGRlIER1cnZ5MR8wHQYJKoZIhvcNAQkBFhBtZHVy dnlAY2lzY28uY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDR9oVSAz6Tlt7xUvAb+IKp aqKdu1dh0cihpjNNzndIzit+ZWpixDZ8tWBtpZ7T2jBC+SiyquqIrin/TD4jlk60y4OBBeF2zlJa c6P0Ay8g4WjDRnvJP93Wz93W32bgjtV1R7FRlWUxPjn9QUDcq4PIHd4qFKSiOMfKk1OijYeWRQID AQABo4HMMIHJMAkGA1UdEwQCMAAwRAYDVR0gBD0wOzA5BgtghkgBhvhFAQcXATAqMCgGCCsGAQUF BwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMAsGA1UdDwQEAwIFoDAdBgNVHSUEFjAU BggrBgEFBQcDBAYIKwYBBQUHAwIwSgYDVR0fBEMwQTA/oD2gO4Y5aHR0cDovL0luZEMxRGlnaXRh bElELWNybC52ZXJpc2lnbi5jb20vSW5kQzFEaWdpdGFsSUQuY3JsMA0GCSqGSIb3DQEBBQUAA4IB AQA9I2FwWjWGMNapHvMFY2LZN+qr3cX6ILBUZ1AxypApr5B2Hl8YXDMA6o8Gtd5J2wxkJmEAbqXT zkoVWspigsclFSbGDu5V0ITLLZzzCXvwnpeaUD4F9GngqdkNUZkqXirqaMZxQTiaI5Hue2RX3f7b Ew4GqU+KMg6meor5iMoyGl/mtZ0LSPj6ZltNaG7ElQoyTXfdBGXlEm8z2uJhtb42Ys2OUptP1v3x jhxT2njv9NMcBH4q7S6y+op0aFrVsNLP7+qcPSBZlEcav3vyNSygxnqyx+pMJmgWH+/VdwsbSIDB FAo4DoI+fe2pUIeqRx6yP9s+e21BRiSPxvBtVe+JMIIEzDCCBDWgAwIBAgIQHK6da5r05i8iiqPa dGFsHjANBgkqhkiG9w0BAQUFADBfMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIElu Yy4xNzA1BgNVBAsTLkNsYXNzIDEgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3Jp dHkwHhcNMDUxMDI4MDAwMDAwWhcNMTUxMDI3MjM1OTU5WjCB3TELMAkGA1UEBhMCVVMxFzAVBgNV BAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYD VQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwNTEe MBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAx IEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIB CgKCAQEAyd+s5+r4+AMUxACS1cF+NsI873xyFcvAq4w9HJXObx4QLD8A7Zcm5rbH5q1DHT+kh0dH TD5U+Gz4x/yxnr0wcLyXsQMF6pXxrUDFRHpLBaLyYPzXOmVi7/8Qe6JWu8VOcC3Woh887bBC6F6N VyGsppnZEenSGgfAdEdCC/zFNOr95rok0R0IFTei13PPAUEvY7I6P76lGm70yUpbPZWmFbs1Ahn5 1O+8jw5xdlm7S7Y+1vxaFvTWDonySf5sDO0V6dmIdZx5zmAn3bmtdc4vc5V6QDqFdUmwuN9ovKvN E4KFEVCj4DwLrsAKU83XMG+FMkYb5EkQwmzirx95/9u0tQIDAQABo4IBhDCCAYAwEgYDVR0TAQH/ BAgwBgEB/wIBADBEBgNVHSAEPTA7MDkGC2CGSAGG+EUBBxcBMCowKAYIKwYBBQUHAgEWHGh0dHBz Oi8vd3d3LnZlcmlzaWduLmNvbS9ycGEwCwYDVR0PBAQDAgEGMBEGCWCGSAGG+EIBAQQEAwIBBjAu BgNVHREEJzAlpCMwITEfMB0GA1UEAxMWUHJpdmF0ZUxhYmVsMy0yMDQ4LTE1NTAdBgNVHQ4EFgQU EX1eGX08BN9qbNaiiho/Mdg7lFIwMQYDVR0fBCowKDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2ln bi5jb20vcGNhMS5jcmwwgYEGA1UdIwR6MHihY6RhMF8xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5W ZXJpU2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMSBQdWJsaWMgUHJpbWFyeSBDZXJ0aWZpY2F0 aW9uIEF1dGhvcml0eYIRAM26f1bw3+S8VP4irLNyqlUwDQYJKoZIhvcNAQEFBQADgYEAsS/ZluGS ou6BYOXIKiD74Wcs1gCYU6MCG+mQS/gYRJ8PRvf6oP7THRij0r8c7NYZn0pNQ/jKu74TgEkF3SFz M1fCQlq++gCTsuYEMZFOXTzwcwU3Y+u/g1mY/Wbe6YYympIpPDquVNqmElGxj8jK00d45tulHocG 49EUwMIh9roxggRzMIIEbwIBATCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWdu LCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBv ZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwNTEeMBwGA1UECxMVUGVy c29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwg U3Vic2NyaWJlciBDQSAtIEcyAhABGiiLJme3TYjnRHtF1qTNMAkGBSsOAwIaBQCgggLWMBgGCSqG SIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTA5MTIwNDEzNTkyOVowIwYJKoZI hvcNAQkEMRYEFAmkGGUA4IOQLyNHmnJF/wRaenkYMGcGCSqGSIb3DQEJDzFaMFgwCgYIKoZIhvcN AwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEo MAcGBSsOAwIaMAoGCCqGSIb3DQIFMIIBAwYJKwYBBAGCNxAEMYH1MIHyMIHdMQswCQYDVQQGEwJV UzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdv cmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBh IChjKTA1MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlZlcmlTaWdu IENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzICEAEaKIsmZ7dNiOdEe0XWpM0w ggEFBgsqhkiG9w0BCRACCzGB9aCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWdu LCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBv ZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwNTEeMBwGA1UECxMVUGVy c29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwg U3Vic2NyaWJlciBDQSAtIEcyAhABGiiLJme3TYjnRHtF1qTNMA0GCSqGSIb3DQEBAQUABIGAiOFa n9It1nGyBn6t1JMGXZ8h8XlgVbtm8foTj5sTyMyti7NJCob05RFbhzVXwPWZtDr5SjX2pTU8lhK1 Kb5keqhPLXvgAKopwwVjChhQsh8kaFHSRSiUj5fPvm7E778ycJgnrLNYcZpgZrQ8mNvdM4L4XQI0 VCDIn8LUGTJeQE4AAAAAAAA= ------=_NextPart_000_04EB_01CA74F2.6123BC40-- From pthubert@cisco.com Fri Dec 4 06:19:35 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C938A3A68A2 for ; Fri, 4 Dec 2009 06:19:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.612 X-Spam-Level: X-Spam-Status: No, score=-5.612 tagged_above=-999 required=5 tests=[AWL=-3.014, 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 ppvS+Abm8g9O for ; Fri, 4 Dec 2009 06:19:26 -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 A30123A6806 for ; Fri, 4 Dec 2009 06:19:25 -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: AjoAAOeoGEuQ/uCWiWdsb2JhbACCJSuZMgEBAQoLERMGoxWXQYQzBA X-IronPort-AV: E=Sophos;i="4.47,341,1257120000"; d="scan'208,217";a="595921" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-2.cisco.com with ESMTP; 04 Dec 2009 13:53:20 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id nB4EJFf7011685 for ; Fri, 4 Dec 2009 14:19:15 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, 4 Dec 2009 15:19: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_01CA74EC.C26D94EF" Date: Fri, 4 Dec 2009 15:19:12 +0100 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5DCB63D6@XMB-AMS-107.cisco.com> In-Reply-To: <8A977BDC5A7B0E429B0F521E8D6F91EEDF9592@XMB-AMS-103.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: #16 Thread-Index: Acp0ynJLQoXUd6iTTJCP8JXamj5kxwAHX6tgAACzPlA= References: <6A2A459175DABE4BB11DE2026AA50A5DCB61E4@XMB-AMS-107.cisco.com> <8A977BDC5A7B0E429B0F521E8D6F91EEDF9592@XMB-AMS-103.cisco.com> From: "Pascal Thubert (pthubert)" To: "Mathilde Durvy (mdurvy)" X-OriginalArrivalTime: 04 Dec 2009 14:19:15.0856 (UTC) FILETIME=[C28C5100:01CA74EC] Cc: roll@ietf.org Subject: Re: [Roll] #16 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 04 Dec 2009 14:19:36 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA74EC.C26D94EF Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Mathilde: =20 >> Does this mean that there is no lifetime associated with DAO routes? =20 There is no lifetime per se. The routes are periodically checked using = the D bit in DIO. =20 >>Is the retry_count + RemoveTimer procedure maintained in version 05?=20 =20 The retry count and remove timers are maintained. The unconfirmed = entries are inconsistencies that cause additional trickled DIO that act = as retries. =20 >> Does this mean that the local confidence is the only criteria to = assess neighbor (including parents and child) reachability? =20 Yes.=20 =20 What we have today: =20 If an interface goes down all neighbors across that interface go down. = If the confidence mechanism declares that a neighbor is no more = reachable, the neighbor goes down. =20 If a neighbor goes down all adjacencies via that neighbors are removed. = This boils down to all routes that are only via that neighbor go away, = while a same route with a higher cost via an alternate neighbor might = pop up. =20 If a DAO entry was not refreshed after retry count then the entry and = the associated adjacency are clean up. The remove timer allows a small = jitter to avoid no-DAO collisions. =20 All this is pretty classical. =20 What we do not have today (I understand that's your question) is = something like if we lose all the DAO entries via a given neighbor from = the retry count then we would declare that the neighbor is down. We do = not have such inference. =20 Would you need more? =20 Pascal From: Mathilde Durvy (mdurvy)=20 Sent: vendredi 4 d=E9cembre 2009 14:59 To: Pascal Thubert (pthubert) Cc: 'roll@ietf.org' Subject: RE: #16 =20 Hi Pascal, =20 Thanks for the update. Please see my questions below. Best, Mathilde =20 ________________________________ =20 Issue 16 says "Hi All, This is my current understanding: - Parents are = removed based on OF selection (decision to move within the DAG, change = DAG, etc) - Destination prefixes are removed after the retry / = RemoveTimer? procedure described in section 5.10.1.1.1. This is = essentially a keep alive mechanism based on DIO (D bit set) - DAO = exchanges. - Route corresponding to destination prefixes are removed = when DAO lifetime expires? Are they also removed when the corresponding = destination prefix is removed? - When are routes corresponding to = parents removed? Do they also have a lifetime? - What happens when a = neighbor disappears, are the corresponding parents/destination/routes = removed? The current behavior seems quite asymmetric... There is some = kind of keep alive mechanism for destination prefixes, but not for = parents. There is a lifetime associated with routes corresponding to = destination prefixes but not for routes corresponding to parents. Is = that a design choice? I would appreciate some clarifications. " =20 Proposed new text : =20 If Neighbor Unreachability Detection (NUD), or an equivalent mechanism, determines that a neighbor is no longer reachable, then a RPL node MUST NOT consider this node in the neighbor set when calculating and advertising routes until the node determines it is reachable again. =20 =20 Routes via that neighbor MUST be eliminated from the routing table, and the node SHOULD poison using no-DAO all DAO routes that it has advertised via DAO and that it can reach only via that neighbor. =20 The internals (keeping info about the DAOs to resync more quickly) are = not described, long as the node behaves as if it has cleaned everything = reachable only via the lost neighbor. >> Does this mean that there is no lifetime associated with DAO routes? >>Is the retry_count + RemoveTimer procedure maintained in version 05?=20 >> Does this mean that the local confidence is the only criteria to = assess neighbor (including parents and child) reachability? =20 Best, Mathilde =20 ------_=_NextPart_001_01CA74EC.C26D94EF Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi = Mathilde:

 

>> Does this mean that there is no lifetime associated = with DAO routes?

 

There is no lifetime per se. The routes are periodically = checked using the D bit in DIO.

 

>>Is the retry_count + RemoveTimer procedure = maintained in version 05?

 

The retry count and remove timers are maintained. The = unconfirmed entries are inconsistencies that cause additional trickled DIO that act = as retries.

 

>> Does this mean that the local confidence is the = only criteria to assess neighbor (including parents and child) = reachability?

 

Yes.

 

What we have today:

 

If an interface goes down all neighbors across that = interface go down. If the confidence mechanism declares that a neighbor is no more = reachable, the neighbor goes down.

 

If a neighbor goes down all adjacencies via that = neighbors are removed. This boils down to all routes that are only via that neighbor = go away, while a same route with a higher cost via an alternate neighbor might = pop up.

 

If a DAO entry was not refreshed after retry count then = the entry and the associated adjacency are clean up. The remove timer allows = a small jitter to avoid no-DAO collisions.

 

All this is pretty = classical.

 

What we do not have = today (I understand that’s your question) is something like if we lose all = the DAO entries via a given neighbor from the retry count then we would declare = that the neighbor is down. We do not have such = inference.

 

Would you need more?

 

Pascal

From:= Mathilde = Durvy (mdurvy)
Sent: vendredi 4 d=E9cembre 2009 14:59
To: Pascal Thubert (pthubert)
Cc: 'roll@ietf.org'
Subject: RE: #16

 

Hi Pascal,

 

Thanks for the update. Please see my questions = below.

Best,

Mathilde

 

 

Issue 16 says “Hi All, This is my current understanding: - Parents are removed based on OF selection (decision to = move within the DAG, change DAG, etc) - Destination prefixes are removed = after the retry / RemoveTimer? procedure described in section 5.10.1.1.1. This is essentially a keep alive mechanism based on DIO (D bit set) - DAO = exchanges. - Route corresponding to destination prefixes are removed when DAO = lifetime expires? Are they also removed when the corresponding destination prefix = is removed? - When are routes corresponding to parents removed? Do they = also have a lifetime? - What happens when a neighbor disappears, are the = corresponding parents/destination/routes removed? The current behavior seems quite = asymmetric... There is some kind of keep alive mechanism for destination prefixes, but = not for parents. There is a lifetime associated with routes corresponding to destination prefixes but not for routes corresponding to parents. Is = that a design choice? I would appreciate some clarifications. = ”

 

Proposed new text :

 

   If Neighbor Unreachability Detection (NUD), or an = equivalent

   mechanism, determines that a neighbor is no longer reachable, then = a

   RPL node MUST NOT consider this node in the neighbor set = when

   calculating and advertising routes until the node determines it = is

   reachable again.  

 

   Routes via that neighbor MUST be eliminated from the routing = table,

   and the node SHOULD poison using no-DAO all DAO routes that = it

   has advertised via DAO and that it can reach only via that = neighbor.

 

The internals (keeping info about the DAOs to = resync more quickly) are not described, long as the node behaves as if it has = cleaned everything reachable only via the lost neighbor.

>> Does this mean that there is no lifetime associated = with DAO routes?

>>Is the retry_count + RemoveTimer procedure = maintained in version 05?

>> Does this mean that the local confidence is the = only criteria to assess neighbor (including parents and child) = reachability?

 

Best,

Mathilde

 

------_=_NextPart_001_01CA74EC.C26D94EF-- From mdurvy@cisco.com Fri Dec 4 07:39:28 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9181A3A68EA for ; Fri, 4 Dec 2009 07:39:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.57 X-Spam-Level: X-Spam-Status: No, score=-4.57 tagged_above=-999 required=5 tests=[AWL=-1.972, 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 0FN4-Zb5UAdo for ; Fri, 4 Dec 2009 07:39:27 -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 089E13A6825 for ; Fri, 4 Dec 2009 07:39:25 -0800 (PST) Authentication-Results: ams-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-Files: smime.p7s : 4235 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjoAAKe7GEuQ/uCWiWdsb2JhbACCJSuZMgEBAQoLERMGo1WXQYQzBA X-IronPort-AV: E=Sophos;i="4.47,342,1257120000"; d="p7s'?scan'208,217";a="604258" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-2.cisco.com with ESMTP; 04 Dec 2009 15:13:21 +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 nB4EgxES004692 for ; Fri, 4 Dec 2009 14:42:59 GMT Received: from xmb-ams-103.cisco.com ([144.254.74.78]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 4 Dec 2009 16:39:15 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 4 Dec 2009 16:39:13 +0100 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0000_01CA7500.50267D70" Message-ID: <8A977BDC5A7B0E429B0F521E8D6F91EEE5ECD9@XMB-AMS-103.cisco.com> In-Reply-To: <6A2A459175DABE4BB11DE2026AA50A5DCB63D6@XMB-AMS-107.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: #16 Thread-Index: Acp0ynJLQoXUd6iTTJCP8JXamj5kxwAHX6tgAACzPlAAAounsA== References: <6A2A459175DABE4BB11DE2026AA50A5DCB61E4@XMB-AMS-107.cisco.com> <8A977BDC5A7B0E429B0F521E8D6F91EEDF9592@XMB-AMS-103.cisco.com> <6A2A459175DABE4BB11DE2026AA50A5DCB63D6@XMB-AMS-107.cisco.com> From: "Mathilde Durvy (mdurvy)" To: "Pascal Thubert (pthubert)" X-OriginalArrivalTime: 04 Dec 2009 15:39:15.0981 (UTC) FILETIME=[EFA543D0:01CA74F7] Cc: roll@ietf.org Subject: Re: [Roll] #16 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 04 Dec 2009 15:39:28 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0000_01CA7500.50267D70 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0001_01CA7500.50267D70" ------=_NextPart_001_0001_01CA7500.50267D70 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Pascal, =20 >> Does this mean that there is no lifetime associated with DAO routes? =20 There is no lifetime per se. The routes are periodically checked using = the D bit in DIO. [Mathilde] So if I understand correctly the DAO lifetime is removed for = the DAO packet =20 >>Is the retry_count + RemoveTimer procedure maintained in version 05?=20 =20 The retry count and remove timers are maintained. The unconfirmed = entries are inconsistencies that cause additional trickled DIO that act as = retries. =20 >> Does this mean that the local confidence is the only criteria to = assess neighbor (including parents and child) reachability? =20 Yes.=20 =20 [Mathilde] I guess my point is that I see a small contradiction in your answers to the 2 previous questions. If we use only local confidence to assess neighbor reachability why do we need an extra mechanism to assess = the reachability to the neighbors that are sending DAOs to us? In other word the retry_count + RemoveTimer test reachability to a = neighbor, the local confidence tests the reachability to the same neighbor, why do = we use both? Is it that the local confidence is too 'slow' for DAO neighbors = (children) but good enough for DIO neighbors (parents)? =20 I would just like to understand the reasoning, otherwise I'm happy with = the change you propose. =20 What we have today ... [Mathilde] Agree=20 =20 Best, Mathilde =20 =20 =20 From: Mathilde Durvy (mdurvy)=20 Sent: vendredi 4 d=E9cembre 2009 14:59 To: Pascal Thubert (pthubert) Cc: 'roll@ietf.org' Subject: RE: #16 =20 Hi Pascal, =20 Thanks for the update. Please see my questions below. Best, Mathilde =20 _____ =20 =20 Issue 16 says =93Hi All, This is my current understanding: - Parents are removed based on OF selection (decision to move within the DAG, change = DAG, etc) - Destination prefixes are removed after the retry / RemoveTimer? procedure described in section 5.10.1.1.1. This is essentially a keep = alive mechanism based on DIO (D bit set) - DAO exchanges. - Route = corresponding to destination prefixes are removed when DAO lifetime expires? Are they = also removed when the corresponding destination prefix is removed? - When are routes corresponding to parents removed? Do they also have a lifetime? - What happens when a neighbor disappears, are the corresponding parents/destination/routes removed? The current behavior seems quite asymmetric... There is some kind of keep alive mechanism for destination prefixes, but not for parents. There is a lifetime associated with = routes corresponding to destination prefixes but not for routes corresponding = to parents. Is that a design choice? I would appreciate some = clarifications. =94 =20 Proposed new text : =20 If Neighbor Unreachability Detection (NUD), or an equivalent mechanism, determines that a neighbor is no longer reachable, then a RPL node MUST NOT consider this node in the neighbor set when calculating and advertising routes until the node determines it is reachable again. =20 =20 Routes via that neighbor MUST be eliminated from the routing table, and the node SHOULD poison using no-DAO all DAO routes that it has advertised via DAO and that it can reach only via that neighbor. =20 The internals (keeping info about the DAOs to resync more quickly) are = not described, long as the node behaves as if it has cleaned everything reachable only via the lost neighbor. >> Does this mean that there is no lifetime associated with DAO routes? >>Is the retry_count + RemoveTimer procedure maintained in version 05?=20 >> Does this mean that the local confidence is the only criteria to = assess neighbor (including parents and child) reachability? =20 Best, Mathilde =20 ------=_NextPart_001_0001_01CA7500.50267D70 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi Pascal,

 

>>=20 Does this mean that there is no lifetime associated with DAO=20 routes?

 

There=20 is no lifetime per se. The routes are periodically checked using the D = bit in=20 DIO.

[Mathilde] So if I understand correctly the = DAO=20 lifetime is removed for the DAO packet

 

>>Is=20 the retry_count + RemoveTimer procedure maintained in version 05?=20

 

The=20 retry count and remove timers are maintained. The unconfirmed entries = are=20 inconsistencies that cause additional trickled DIO that act as=20 retries.

 

>>=20 Does this mean that the local confidence is the only criteria to assess = neighbor=20 (including parents and child) reachability?

 

Yes.=20

 

[Mathilde] I guess my = point is that=20 I see a small contradiction in your answers to the 2 previous questions. = If we=20 use only local confidence to assess neighbor reachability why do we = need an=20 extra mechanism to assess the reachability to the neighbors that are = sending=20 DAOs to us?

In other word the = retry_count +=20 RemoveTimer test reachability to a neighbor, the local confidence tests = the=20 reachability to the same neighbor, why do we use=20 both?

Is it that the local = confidence is=20 too 'slow' for DAO neighbors (children) but good enough for DIO = neighbors=20 (parents)?

 

I would just like to = understand the=20 reasoning, otherwise I'm happy with the change you=20 propose.

 

What=20 we have today ...

 [Mathilde] Agree 

 

Best,

Mathilde

 

 

 

From: Mathilde = Durvy=20 (mdurvy)
Sent: vendredi 4 d=E9cembre 2009 14:59
To: = Pascal=20 Thubert (pthubert)
Cc: 'roll@ietf.org'
Subject: RE:=20 #16

 

Hi=20 Pascal,

 

Thanks=20 for the update. Please see my questions below.

Best,

Mathilde

 

 

Issue 16 says =93Hi All, This is my current = understanding: -=20 Parents are removed based on OF selection (decision to move within the = DAG,=20 change DAG, etc) - Destination prefixes are removed after the retry /=20 RemoveTimer? procedure described in section 5.10.1.1.1. This is = essentially a=20 keep alive mechanism based on DIO (D bit set) - DAO exchanges. - Route=20 corresponding to destination prefixes are removed when DAO lifetime = expires? Are=20 they also removed when the corresponding destination prefix is removed? = - When=20 are routes corresponding to parents removed? Do they also have a = lifetime? -=20 What happens when a neighbor disappears, are the corresponding=20 parents/destination/routes removed? The current behavior seems quite=20 asymmetric... There is some kind of keep alive mechanism for destination = prefixes, but not for parents. There is a lifetime associated with = routes=20 corresponding to destination prefixes but not for routes corresponding = to=20 parents. Is that a design choice? I would appreciate some = clarifications.=20 =94

 

Proposed new text :

 

   If = Neighbor=20 Unreachability Detection (NUD), or an equivalent

   = mechanism,=20 determines that a neighbor is no longer reachable, then = a

   RPL = node MUST=20 NOT consider this node in the neighbor set when

   = calculating and=20 advertising routes until the node determines it is

   = reachable=20 again.  

 

   = Routes via that=20 neighbor MUST be eliminated from the routing = table,

   and = the node=20 SHOULD poison using no-DAO all DAO routes that it

   has = advertised=20 via DAO and that it can reach only via that = neighbor.

 

The internals (keeping info about the DAOs to = resync more=20 quickly) are not described, long as the node behaves as if it has = cleaned=20 everything reachable only via the lost neighbor.

>>=20 Does this mean that there is no lifetime associated with DAO=20 routes?

>>Is=20 the retry_count + RemoveTimer procedure maintained in version 05?=20

>>=20 Does this mean that the local confidence is the only criteria to assess = neighbor=20 (including parents and child) reachability?

 

Best,

Mathilde

 

------=_NextPart_001_0001_01CA7500.50267D70-- ------=_NextPart_000_0000_01CA7500.50267D70 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIL2jCCAj0w ggGmAhEAzbp/VvDf5LxU/iKss3KqVTANBgkqhkiG9w0BAQIFADBfMQswCQYDVQQGEwJVUzEXMBUG A1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDEgUHVibGljIFByaW1hcnkgQ2Vy dGlmaWNhdGlvbiBBdXRob3JpdHkwHhcNOTYwMTI5MDAwMDAwWhcNMjgwODAxMjM1OTU5WjBfMQsw CQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDEgUHVi bGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwgZ8wDQYJKoZIhvcNAQEBBQADgY0A MIGJAoGBAOUZv22jVmEtmUhx9mfeuY3rt56GgAqRDvo4Ja9GiILlc6igmyRdDR/MZW4MsNBWhBiH mgabEKFz37RYOWtuwfYV1aioP6oSBo0xrH+wNNePNGeICc0UEeJORVZpH3gCgNrcR5EpuzbJY1zF 4Ncth3uhtzKwezC6Ki8xqu6jZ9rbAgMBAAEwDQYJKoZIhvcNAQECBQADgYEATD+4i8Zo3+5DMw5d 6abLB4RNejP/khv0Nq3YlSI2aBFsfELM85wuxAc/FLAPT/+Qknb54rxK6Y/NoIAK98Up8YIiXbix 3YEjo3slFUYweRb46gVLlH8dwhzI47f0EEA8E8NfH1PoSOSGtHuhNbB7Jbq4046rPzidADQAmPPR cZQwggTFMIIDraADAgECAhABGiiLJme3TYjnRHtF1qTNMA0GCSqGSIb3DQEBBQUAMIHdMQswCQYD VQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0 IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5j b20vcnBhIChjKTA1MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlZl cmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzIwHhcNMDkxMTI2MDAw MDAwWhcNMTAxMTI2MjM1OTU5WjCCARIxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9z aXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQLExVQZXJzb25h IE5vdCBWYWxpZGF0ZWQxNDAyBgNVBAsTK0RpZ2l0YWwgSUQgQ2xhc3MgMSAtIE1pY3Jvc29mdCBG dWxsIFNlcnZpY2UxFzAVBgNVBAMUDk1hdGhpbGRlIER1cnZ5MR8wHQYJKoZIhvcNAQkBFhBtZHVy dnlAY2lzY28uY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDR9oVSAz6Tlt7xUvAb+IKp aqKdu1dh0cihpjNNzndIzit+ZWpixDZ8tWBtpZ7T2jBC+SiyquqIrin/TD4jlk60y4OBBeF2zlJa c6P0Ay8g4WjDRnvJP93Wz93W32bgjtV1R7FRlWUxPjn9QUDcq4PIHd4qFKSiOMfKk1OijYeWRQID AQABo4HMMIHJMAkGA1UdEwQCMAAwRAYDVR0gBD0wOzA5BgtghkgBhvhFAQcXATAqMCgGCCsGAQUF BwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMAsGA1UdDwQEAwIFoDAdBgNVHSUEFjAU BggrBgEFBQcDBAYIKwYBBQUHAwIwSgYDVR0fBEMwQTA/oD2gO4Y5aHR0cDovL0luZEMxRGlnaXRh bElELWNybC52ZXJpc2lnbi5jb20vSW5kQzFEaWdpdGFsSUQuY3JsMA0GCSqGSIb3DQEBBQUAA4IB AQA9I2FwWjWGMNapHvMFY2LZN+qr3cX6ILBUZ1AxypApr5B2Hl8YXDMA6o8Gtd5J2wxkJmEAbqXT zkoVWspigsclFSbGDu5V0ITLLZzzCXvwnpeaUD4F9GngqdkNUZkqXirqaMZxQTiaI5Hue2RX3f7b Ew4GqU+KMg6meor5iMoyGl/mtZ0LSPj6ZltNaG7ElQoyTXfdBGXlEm8z2uJhtb42Ys2OUptP1v3x jhxT2njv9NMcBH4q7S6y+op0aFrVsNLP7+qcPSBZlEcav3vyNSygxnqyx+pMJmgWH+/VdwsbSIDB FAo4DoI+fe2pUIeqRx6yP9s+e21BRiSPxvBtVe+JMIIEzDCCBDWgAwIBAgIQHK6da5r05i8iiqPa dGFsHjANBgkqhkiG9w0BAQUFADBfMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIElu Yy4xNzA1BgNVBAsTLkNsYXNzIDEgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3Jp dHkwHhcNMDUxMDI4MDAwMDAwWhcNMTUxMDI3MjM1OTU5WjCB3TELMAkGA1UEBhMCVVMxFzAVBgNV BAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYD VQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwNTEe MBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAx IEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIB CgKCAQEAyd+s5+r4+AMUxACS1cF+NsI873xyFcvAq4w9HJXObx4QLD8A7Zcm5rbH5q1DHT+kh0dH TD5U+Gz4x/yxnr0wcLyXsQMF6pXxrUDFRHpLBaLyYPzXOmVi7/8Qe6JWu8VOcC3Woh887bBC6F6N VyGsppnZEenSGgfAdEdCC/zFNOr95rok0R0IFTei13PPAUEvY7I6P76lGm70yUpbPZWmFbs1Ahn5 1O+8jw5xdlm7S7Y+1vxaFvTWDonySf5sDO0V6dmIdZx5zmAn3bmtdc4vc5V6QDqFdUmwuN9ovKvN E4KFEVCj4DwLrsAKU83XMG+FMkYb5EkQwmzirx95/9u0tQIDAQABo4IBhDCCAYAwEgYDVR0TAQH/ BAgwBgEB/wIBADBEBgNVHSAEPTA7MDkGC2CGSAGG+EUBBxcBMCowKAYIKwYBBQUHAgEWHGh0dHBz Oi8vd3d3LnZlcmlzaWduLmNvbS9ycGEwCwYDVR0PBAQDAgEGMBEGCWCGSAGG+EIBAQQEAwIBBjAu BgNVHREEJzAlpCMwITEfMB0GA1UEAxMWUHJpdmF0ZUxhYmVsMy0yMDQ4LTE1NTAdBgNVHQ4EFgQU EX1eGX08BN9qbNaiiho/Mdg7lFIwMQYDVR0fBCowKDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2ln bi5jb20vcGNhMS5jcmwwgYEGA1UdIwR6MHihY6RhMF8xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5W ZXJpU2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMSBQdWJsaWMgUHJpbWFyeSBDZXJ0aWZpY2F0 aW9uIEF1dGhvcml0eYIRAM26f1bw3+S8VP4irLNyqlUwDQYJKoZIhvcNAQEFBQADgYEAsS/ZluGS ou6BYOXIKiD74Wcs1gCYU6MCG+mQS/gYRJ8PRvf6oP7THRij0r8c7NYZn0pNQ/jKu74TgEkF3SFz M1fCQlq++gCTsuYEMZFOXTzwcwU3Y+u/g1mY/Wbe6YYympIpPDquVNqmElGxj8jK00d45tulHocG 49EUwMIh9roxggRzMIIEbwIBATCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWdu LCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBv ZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwNTEeMBwGA1UECxMVUGVy c29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwg U3Vic2NyaWJlciBDQSAtIEcyAhABGiiLJme3TYjnRHtF1qTNMAkGBSsOAwIaBQCgggLWMBgGCSqG SIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTA5MTIwNDE1MzkxM1owIwYJKoZI hvcNAQkEMRYEFBL+hSZyNXKDlQr+/sS512vI80IDMGcGCSqGSIb3DQEJDzFaMFgwCgYIKoZIhvcN AwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEo MAcGBSsOAwIaMAoGCCqGSIb3DQIFMIIBAwYJKwYBBAGCNxAEMYH1MIHyMIHdMQswCQYDVQQGEwJV UzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdv cmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBh IChjKTA1MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlZlcmlTaWdu IENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzICEAEaKIsmZ7dNiOdEe0XWpM0w ggEFBgsqhkiG9w0BCRACCzGB9aCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWdu LCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBv ZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwNTEeMBwGA1UECxMVUGVy c29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwg U3Vic2NyaWJlciBDQSAtIEcyAhABGiiLJme3TYjnRHtF1qTNMA0GCSqGSIb3DQEBAQUABIGAa9Uv Hu6MoVBi6G4SPJbJYG1YavLeBOeb+kqjQs5PAYD5HnzdfjdCxlszlq+/j50bTG4oJUY3cmvDD8Rc GIOcw1uQkwMXqWHVJDcDfsAmJrhMogASZPpUVsavO9wNKfRNMer2tdD/EH4u9d7lL/Mm6U3dhG2J NNRG+DbHBeLT85cAAAAAAAA= ------=_NextPart_000_0000_01CA7500.50267D70-- From pthubert@cisco.com Fri Dec 4 08:14:42 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 757CD3A67A8 for ; Fri, 4 Dec 2009 08:14:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.512 X-Spam-Level: X-Spam-Status: No, score=-5.512 tagged_above=-999 required=5 tests=[AWL=-2.914, 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 lOhey3K+LRSS for ; Fri, 4 Dec 2009 08:14:28 -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 18B203A63EC for ; Fri, 4 Dec 2009 08:14:26 -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: AjsAANvDGEuQ/uCWiWdsb2JhbACCJiqZMgEBAQoLERMGo1mXM4QzBA X-IronPort-AV: E=Sophos;i="4.47,342,1257120000"; d="scan'208,217";a="607326" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-2.cisco.com with ESMTP; 04 Dec 2009 15:48:20 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id nB4FHwFU013150 for ; Fri, 4 Dec 2009 15:17:58 GMT Received: from xmb-ams-107.cisco.com ([144.254.74.82]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 4 Dec 2009 17:14: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_01CA74FC.D31F99CB" Date: Fri, 4 Dec 2009 17:14:12 +0100 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5DCB64BA@XMB-AMS-107.cisco.com> In-Reply-To: <8A977BDC5A7B0E429B0F521E8D6F91EEE5ECD9@XMB-AMS-103.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: #16 Thread-Index: Acp0ynJLQoXUd6iTTJCP8JXamj5kxwAHX6tgAACzPlAAAounsAABnBAw References: <6A2A459175DABE4BB11DE2026AA50A5DCB61E4@XMB-AMS-107.cisco.com> <8A977BDC5A7B0E429B0F521E8D6F91EEDF9592@XMB-AMS-103.cisco.com> <6A2A459175DABE4BB11DE2026AA50A5DCB63D6@XMB-AMS-107.cisco.com> <8A977BDC5A7B0E429B0F521E8D6F91EEE5ECD9@XMB-AMS-103.cisco.com> From: "Pascal Thubert (pthubert)" To: "Mathilde Durvy (mdurvy)" X-OriginalArrivalTime: 04 Dec 2009 16:14:15.0834 (UTC) FILETIME=[D34167A0:01CA74FC] Cc: roll@ietf.org Subject: Re: [Roll] #16 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 04 Dec 2009 16:14:42 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA74FC.D31F99CB Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Mathilde: =20 =20 [Mathilde] So if I understand correctly the DAO lifetime is removed for = the DAO packet =20 The DAO lifetime is the lifetime of the prefix, not that of the route. = You can hardly say how long a route can be valid. After that lifetime expires, the prefix will not exist anymore so = obviously, if the lifetime was not refreshed, the route associated has = to be removed. =20 =20 =20 [Mathilde] I guess my point is that I see a small contradiction in your = answers to the 2 previous questions. If we useonly local confidence to = assess neighbor reachability why do we need an extra mechanism to assess = the reachability to the neighbors that are sending DAOs to us? In other word the retry_count + RemoveTimer test reachability to a = neighbor, the local confidence tests the reachability to the same = neighbor, why do weuse both? Is it that the local confidence is too 'slow' for DAO neighbors = (children) but good enough for DIO neighbors (parents)? =20 I would just like to understand the reasoning, otherwise I'm happy with = the change you propose. =20 The local confidence assesses reachability of the neighbor. =20 A neighbor might be lost if - NUD declares it unreachable - The link goes down =20 The retry_count + RemoveTimer test assesses reachability of the final = destination, may far behind the neighbor =20 A final destination might be lost for a number of reasons if you look at = it - No DAO (null lifetime) - Prefix Lifetime expires - Retry count expires - Last neighbor via which we have a route to destination goes = down - Routing shutdown - ... =20 Makes sense? =20 Pascal =20 =20 From: Mathilde Durvy (mdurvy)=20 Sent: vendredi 4 d=E9cembre 2009 14:59 To: Pascal Thubert (pthubert) Cc: 'roll@ietf.org' Subject: RE: #16 =20 Hi Pascal, =20 Thanks for the update. Please see my questions below. Best, Mathilde =20 ________________________________ =20 Issue 16 says "Hi All, This is my current understanding: - Parents are = removed based on OF selection (decision to move within the DAG, change = DAG, etc) - Destination prefixes are removed after the retry / = RemoveTimer? procedure described in section 5.10.1.1.1. This is = essentially a keep alive mechanism based on DIO (D bit set) - DAO = exchanges. - Route corresponding to destination prefixes are removed = when DAO lifetime expires? Are they also removed when the corresponding = destination prefix is removed? - When are routes corresponding to = parents removed? Do they also have a lifetime? - What happens when a = neighbor disappears, are the corresponding parents/destination/routes = removed? The current behavior seems quite asymmetric... There is some = kind of keep alive mechanism for destination prefixes, but not for = parents. There is a lifetime associated with routes corresponding to = destination prefixes but not for routes corresponding to parents. Is = that a design choice? I would appreciate some clarifications. " =20 Proposed new text : =20 If Neighbor Unreachability Detection (NUD), or an equivalent mechanism, determines that a neighbor is no longer reachable, then a RPL node MUST NOT consider this node in the neighbor set when calculating and advertising routes until the node determines it is reachable again. =20 =20 Routes via that neighbor MUST be eliminated from the routing table, and the node SHOULD poison using no-DAO all DAO routes that it has advertised via DAO and that it can reach only via that neighbor. =20 The internals (keeping info about the DAOs to resync more quickly) are = not described, long as the node behaves as if it has cleaned everything = reachable only via the lost neighbor. >> Does this mean that there is no lifetime associated with DAO routes? >>Is the retry_count + RemoveTimer procedure maintained in version 05?=20 >> Does this mean that the local confidence is the only criteria to = assess neighbor (including parents and child) reachability? =20 Best, Mathilde =20 ------_=_NextPart_001_01CA74FC.D31F99CB Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi = Mathilde:

 

 

=A0[Mathilde] So if I understand correctly the DAO lifetime = is removed for the DAO packet

 

The DAO lifetime is = the lifetime of the prefix, not that of the route. You can hardly say = how long a route can be valid.

After that lifetime = expires, the prefix will not exist anymore so obviously, if the lifetime was not = refreshed, =A0the route associated has to be removed.

 

 

 

[Mathilde] I guess my point is that I see a small = contradiction in your answers to the 2 previous questions. If we useonly local confidence = to assess neighbor reachability why do we need an extra mechanism to assess = the reachability to the neighbors that are sending DAOs to us?

In other word the retry_count + RemoveTimer test = reachability to a neighbor, the local confidence tests the reachability to the same = neighbor, why do weuse both?

Is it that the local confidence is too 'slow' for DAO = neighbors (children) but good enough for DIO neighbors (parents)?

 

I would just like to understand the reasoning, otherwise I'm = happy with the change you propose.

 

The local confidence = assesses reachability of the neighbor.

 

A neighbor might be = lost if

-          NUD = declares it unreachable

-          The link = goes down

 

The retry_count + = RemoveTimer test assesses reachability of the final destination, may far behind the = neighbor

 

A final destination = might be lost for a number of reasons if you look at it

-          No DAO = (null lifetime)

-          Prefix = Lifetime expires

-          Retry count = expires

-          Last = neighbor via which we have a route to destination goes down

-          Routing = shutdown

-          …

 

 Makes = sense?

 

Pascal

 

 

From:= Mathilde = Durvy (mdurvy)
Sent: vendredi 4 d=E9cembre 2009 14:59
To: Pascal Thubert (pthubert)
Cc: 'roll@ietf.org'
Subject: RE: #16

 

Hi Pascal,

 

Thanks for the update. Please see my questions = below.

Best,

Mathilde

 

 

Issue 16 says “Hi All, This is my current understanding: - Parents are removed based on OF selection (decision to = move within the DAG, change DAG, etc) - Destination prefixes are removed = after the retry / RemoveTimer? procedure described in section 5.10.1.1.1. This is essentially a keep alive mechanism based on DIO (D bit set) - DAO = exchanges. - Route corresponding to destination prefixes are removed when DAO = lifetime expires? Are they also removed when the corresponding destination prefix = is removed? - When are routes corresponding to parents removed? Do they = also have a lifetime? - What happens when a neighbor disappears, are the = corresponding parents/destination/routes removed? The current behavior seems quite asymmetric... There is some kind of keep alive mechanism for destination prefixes, but not for parents. There is a lifetime associated with = routes corresponding to destination prefixes but not for routes corresponding = to parents. Is that a design choice? I would appreciate some = clarifications. ”

 

Proposed new text :

 

   If Neighbor Unreachability Detection (NUD), or an = equivalent

   mechanism, determines that a neighbor is no longer reachable, then = a

   RPL node MUST NOT consider this node in the neighbor set = when

   calculating and advertising routes until the node determines it = is

   reachable again.  

 

   Routes via that neighbor MUST be eliminated from the routing = table,

   and the node SHOULD poison using no-DAO all DAO routes that = it

   has advertised via DAO and that it can reach only via that = neighbor.

 

The internals (keeping info about the DAOs to = resync more quickly) are not described, long as the node behaves as if it has = cleaned everything reachable only via the lost neighbor.

>> Does this mean that there is no lifetime associated = with DAO routes?

>>Is the retry_count + RemoveTimer procedure = maintained in version 05?

>> Does this mean that the local confidence is the = only criteria to assess neighbor (including parents and child) = reachability?

 

Best,

Mathilde

 

------_=_NextPart_001_01CA74FC.D31F99CB-- From pthubert@cisco.com Fri Dec 4 08:22:43 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6D56D3A68EA for ; Fri, 4 Dec 2009 08:22:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.418 X-Spam-Level: X-Spam-Status: No, score=-7.418 tagged_above=-999 required=5 tests=[AWL=-0.820, 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 CeH0Jf6CCp-Z for ; Fri, 4 Dec 2009 08:22:36 -0800 (PST) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 5DFCE3A67A8 for ; Fri, 4 Dec 2009 08:22:36 -0800 (PST) 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: AsQEAG7GGEurRN+J/2dsb2JhbACCJSu9SJczhDME X-IronPort-AV: E=Sophos;i="4.47,342,1257120000"; d="scan'208,217";a="114131063" Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-5.cisco.com with ESMTP; 04 Dec 2009 16:22:27 +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 nB4GMP9f017883 for ; Fri, 4 Dec 2009 16:22: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); Fri, 4 Dec 2009 17:22:24 +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_01CA74FD.F6969AED" Date: Fri, 4 Dec 2009 17:22:20 +0100 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5DCB64C8@XMB-AMS-107.cisco.com> In-Reply-To: <8A977BDC5A7B0E429B0F521E8D6F91EEE5ECD9@XMB-AMS-103.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: #16 Thread-Index: Acp0ynJLQoXUd6iTTJCP8JXamj5kxwAHX6tgAACzPlAAAounsAACELcw References: <6A2A459175DABE4BB11DE2026AA50A5DCB61E4@XMB-AMS-107.cisco.com> <8A977BDC5A7B0E429B0F521E8D6F91EEDF9592@XMB-AMS-103.cisco.com> <6A2A459175DABE4BB11DE2026AA50A5DCB63D6@XMB-AMS-107.cisco.com> <8A977BDC5A7B0E429B0F521E8D6F91EEE5ECD9@XMB-AMS-103.cisco.com> From: "Pascal Thubert (pthubert)" To: "Mathilde Durvy (mdurvy)" X-OriginalArrivalTime: 04 Dec 2009 16:22:24.0794 (UTC) FILETIME=[F6B2C7A0:01CA74FD] Cc: roll@ietf.org Subject: Re: [Roll] #16 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 04 Dec 2009 16:22:43 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA74FD.F6969AED Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable BTW Mathilde,=20 =20 1) You right, the periods are decoupled. And it's unclear to me = that all nodes would always send DAOs. 2) You can use the fact that the neighbors answers to the DIO with = a DAO as a upper layer reachability confirmation 3) We'll propose to make the ack more explicit in 6 with a DAO = trigger sequence that ensures that the D bit is not lost =20 Cheers, =20 Pascal From: Mathilde Durvy (mdurvy)=20 Sent: vendredi 4 d=E9cembre 2009 16:39 To: Pascal Thubert (pthubert) Cc: 'roll@ietf.org' Subject: RE: #16 =20 Hi Pascal, =20 >> Does this mean that there is no lifetime associated with DAO routes? =20 There is no lifetime per se. The routes are periodically checked using = the D bit in DIO. [Mathilde] So if I understand correctly the DAO lifetime is removed for = the DAO packet =20 >>Is the retry_count + RemoveTimer procedure maintained in version 05?=20 =20 The retry count and remove timers are maintained. The unconfirmed = entries are inconsistencies that cause additional trickled DIO that act = as retries. =20 >> Does this mean that the local confidence is the only criteria to = assess neighbor (including parents and child) reachability? =20 Yes.=20 =20 [Mathilde] I guess my point is that I see a small contradiction in your = answers to the 2 previous questions. If we useonly local confidence to = assess neighbor reachability why do we need an extra mechanism to assess = the reachability to the neighbors that are sending DAOs to us? In other word the retry_count + RemoveTimer test reachability to a = neighbor, the local confidence tests the reachability to the same = neighbor, why do weuse both? Is it that the local confidence is too 'slow' for DAO neighbors = (children) but good enough for DIO neighbors (parents)? =20 I would just like to understand the reasoning, otherwise I'm happy with = the change you propose. =20 What we have today ... [Mathilde] Agree=20 =20 Best, Mathilde =20 =20 =20 From: Mathilde Durvy (mdurvy)=20 Sent: vendredi 4 d=E9cembre 2009 14:59 To: Pascal Thubert (pthubert) Cc: 'roll@ietf.org' Subject: RE: #16 =20 Hi Pascal, =20 Thanks for the update. Please see my questions below. Best, Mathilde =20 ________________________________ =20 Issue 16 says "Hi All, This is my current understanding: - Parents are = removed based on OF selection (decision to move within the DAG, change = DAG, etc) - Destination prefixes are removed after the retry / = RemoveTimer? procedure described in section 5.10.1.1.1. This is = essentially a keep alive mechanism based on DIO (D bit set) - DAO = exchanges. - Route corresponding to destination prefixes are removed = when DAO lifetime expires? Are they also removed when the corresponding = destination prefix is removed? - When are routes corresponding to = parents removed? Do they also have a lifetime? - What happens when a = neighbor disappears, are the corresponding parents/destination/routes = removed? The current behavior seems quite asymmetric... There is some = kind of keep alive mechanism for destination prefixes, but not for = parents. There is a lifetime associated with routes corresponding to = destination prefixes but not for routes corresponding to parents. Is = that a design choice? I would appreciate some clarifications. " =20 Proposed new text : =20 If Neighbor Unreachability Detection (NUD), or an equivalent mechanism, determines that a neighbor is no longer reachable, then a RPL node MUST NOT consider this node in the neighbor set when calculating and advertising routes until the node determines it is reachable again. =20 =20 Routes via that neighbor MUST be eliminated from the routing table, and the node SHOULD poison using no-DAO all DAO routes that it has advertised via DAO and that it can reach only via that neighbor. =20 The internals (keeping info about the DAOs to resync more quickly) are = not described, long as the node behaves as if it has cleaned everything = reachable only via the lost neighbor. >> Does this mean that there is no lifetime associated with DAO routes? >>Is the retry_count + RemoveTimer procedure maintained in version 05?=20 >> Does this mean that the local confidence is the only criteria to = assess neighbor (including parents and child) reachability? =20 Best, Mathilde =20 ------_=_NextPart_001_01CA74FD.F6969AED Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

BTW Mathilde, =

 

1)      You right, = the periods are decoupled. And it’s unclear to me that all nodes would = always send DAOs.

2)      You can use = the fact that the neighbors answers to the DIO with a DAO as a upper layer = reachability confirmation

3)      We’ll = propose to make the ack more explicit in 6 with a DAO trigger sequence that = ensures that the D bit is not lost

 

Cheers,

 

Pascal

From:= Mathilde = Durvy (mdurvy)
Sent: vendredi 4 d=E9cembre 2009 16:39
To: Pascal Thubert (pthubert)
Cc: 'roll@ietf.org'
Subject: RE: #16

 

Hi Pascal,

 

>> Does this mean that there is no lifetime associated = with DAO routes?

 

There is no lifetime per se. The routes are periodically = checked using the D bit in DIO.

[Mathilde] So if I understand correctly the DAO lifetime is = removed for the DAO packet

 

>>Is the retry_count + RemoveTimer procedure = maintained in version 05?

 

The retry count and remove timers are maintained. The unconfirmed entries are inconsistencies that cause additional trickled = DIO that act as retries.

 

>> Does this mean that the local confidence is the = only criteria to assess neighbor (including parents and child) = reachability?

 

Yes.

 

[Mathilde] I guess my point is that I see a small = contradiction in your answers to the 2 previous questions. If we useonly local confidence = to assess neighbor reachability why do we need an extra mechanism to assess = the reachability to the neighbors that are sending DAOs to us?

In other word the retry_count + RemoveTimer test = reachability to a neighbor, the local confidence tests the reachability to the same = neighbor, why do weuse both?

Is it that the local confidence is too 'slow' for DAO = neighbors (children) but good enough for DIO neighbors (parents)?

 

I would just like to understand the reasoning, otherwise I'm = happy with the change you propose.

 

What we have today ...<= /p>

 [Mathilde] Agree 

 

Best,

Mathilde

 

 

 

From:= Mathilde = Durvy (mdurvy)
Sent: vendredi 4 d=E9cembre 2009 14:59
To: Pascal Thubert (pthubert)
Cc: 'roll@ietf.org'
Subject: RE: #16

 

Hi Pascal,

 

Thanks for the update. Please see my questions = below.

Best,

Mathilde

 

 

Issue 16 says “Hi All, This is my current understanding: - Parents are removed based on OF selection (decision to = move within the DAG, change DAG, etc) - Destination prefixes are removed = after the retry / RemoveTimer? procedure described in section 5.10.1.1.1. This is essentially a keep alive mechanism based on DIO (D bit set) - DAO = exchanges. - Route corresponding to destination prefixes are removed when DAO = lifetime expires? Are they also removed when the corresponding destination prefix = is removed? - When are routes corresponding to parents removed? Do they = also have a lifetime? - What happens when a neighbor disappears, are the = corresponding parents/destination/routes removed? The current behavior seems quite asymmetric... There is some kind of keep alive mechanism for destination prefixes, but not for parents. There is a lifetime associated with = routes corresponding to destination prefixes but not for routes corresponding = to parents. Is that a design choice? I would appreciate some = clarifications. ”

 

Proposed new text :

 

   If Neighbor Unreachability Detection (NUD), or an = equivalent

   mechanism, determines that a neighbor is no longer reachable, then = a

   RPL node MUST NOT consider this node in the neighbor set = when

   calculating and advertising routes until the node determines it = is

   reachable again.  

 

   Routes via that neighbor MUST be eliminated from the routing = table,

   and the node SHOULD poison using no-DAO all DAO routes that = it

   has advertised via DAO and that it can reach only via that = neighbor.

 

The internals (keeping info about the DAOs to = resync more quickly) are not described, long as the node behaves as if it has = cleaned everything reachable only via the lost neighbor.

>> Does this mean that there is no lifetime associated = with DAO routes?

>>Is the retry_count + RemoveTimer procedure = maintained in version 05?

>> Does this mean that the local confidence is the = only criteria to assess neighbor (including parents and child) = reachability?

 

Best,

Mathilde

 

------_=_NextPart_001_01CA74FD.F6969AED-- From trac@tools.ietf.org Fri Dec 4 08:55:02 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7588B3A684A for ; Fri, 4 Dec 2009 08:55:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.481 X-Spam-Level: X-Spam-Status: No, score=-102.481 tagged_above=-999 required=5 tests=[AWL=0.119, 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 JQCpPmIWzrbg for ; Fri, 4 Dec 2009 08:55:01 -0800 (PST) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:1112:1:214:22ff:fe1f:1e54]) by core3.amsl.com (Postfix) with ESMTP id C96343A67EC for ; Fri, 4 Dec 2009 08:55: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 1NGbQf-0001pa-Ts; Fri, 04 Dec 2009 08:54:49 -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.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.5, by Edgewall Software To: pal@cs.stanford.edu, jpv@cisco.com X-Trac-Project: roll Date: Fri, 04 Dec 2009 16:54:49 -0000 X-URL: http://tools.ietf.org/wg/roll/ X-Trac-Ticket-URL: http://svn.tools.ietf.org/wg/roll/trac/ticket/6#comment:2 Message-ID: <064.69e7375c77b4520f3f95b20b6d5c9fdc@tools.ietf.org> References: <055.82953fb7ca07ae4f993dd45d9f020003@tools.ietf.org> X-Trac-Ticket-ID: 6 In-Reply-To: <055.82953fb7ca07ae4f993dd45d9f020003@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: pal@cs.stanford.edu, 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] #6: Multicast DAO 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, 04 Dec 2009 16:55:02 -0000 #6: Multicast DAO --------------------------------+------------------------------------------- Reporter: jpv@… | Owner: pal@… Type: defect | Status: closed Priority: major | Milestone: Component: rpl | Version: Severity: Active WG Document | Resolution: fixed Keywords: | --------------------------------+------------------------------------------- Changes (by jpv@…): * status: new => closed * resolution: => fixed Comment: After discussion on the mailing list, some people thought that it brought extra complexity while others could see a real value add for minor added complexity. Thus it was decided to keep the mechanism as part of the core specification. -- Ticket URL: roll From trac@tools.ietf.org Fri Dec 4 08:56:39 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DBB653A688E for ; Fri, 4 Dec 2009 08:56:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.488 X-Spam-Level: X-Spam-Status: No, score=-102.488 tagged_above=-999 required=5 tests=[AWL=0.112, 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 0rN-u4ebjAHj for ; Fri, 4 Dec 2009 08:56:39 -0800 (PST) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:1112:1:214:22ff:fe1f:1e54]) by core3.amsl.com (Postfix) with ESMTP id 37A3E3A67EC for ; Fri, 4 Dec 2009 08:56:39 -0800 (PST) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1NGbSG-00028u-PX; Fri, 04 Dec 2009 08:56: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.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.5, by Edgewall Software To: mjkim@kt.com, jpv@cisco.com X-Trac-Project: roll Date: Fri, 04 Dec 2009 16:56:28 -0000 X-URL: http://tools.ietf.org/wg/roll/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/roll/trac/ticket/18#comment:1 Message-ID: <064.22ff5a9870a778978417ee46694b8a2a@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, 04 Dec 2009 16:56:39 -0000 #18: Numeric Ranges in Routing Metric --------------------------------+------------------------------------------- Reporter: jpv@… | Owner: mjkim@… Type: defect | Status: new Priority: minor | Milestone: Component: routing-metrics | Version: Severity: Active WG Document | Keywords: --------------------------------+------------------------------------------- Changes (by jpv@…): * owner: jpv@… => mjkim@… -- Ticket URL: roll From Matthew.Anderson@us.elster.com Fri Dec 4 09:21:09 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 205A63A6A50 for ; Fri, 4 Dec 2009 09:21:09 -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=[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 t1TozeVXzSKp for ; Fri, 4 Dec 2009 09:21:08 -0800 (PST) Received: from mail196.messagelabs.com (mail196.messagelabs.com [216.82.254.67]) by core3.amsl.com (Postfix) with SMTP id 0CB393A6A42 for ; Fri, 4 Dec 2009 09:21:08 -0800 (PST) X-VirusChecked: Checked X-Env-Sender: Matthew.Anderson@us.elster.com X-Msg-Ref: server-10.tower-196.messagelabs.com!1259947200!62884160!1 X-StarScan-Version: 6.2.4; banners=-,-,- X-Originating-IP: [206.182.155.20] Received: (qmail 27552 invoked from network); 4 Dec 2009 17:20:00 -0000 Received: from unknown (HELO us-smtp01.smtp.elster.com) (206.182.155.20) by server-10.tower-196.messagelabs.com with SMTP; 4 Dec 2009 17:20:00 -0000 Auto-Submitted: auto-generated From: Matthew.Anderson@us.elster.com To: roll@ietf.org Message-ID: Date: Fri, 4 Dec 2009 12:20:33 -0500 X-MIMETrack: Serialize by Router on US-SMTP01.domino.elster-group.com/RIM-TEMP(Release 8.5.1|September 28, 2009) at 12/04/2009 12:18:20 PM MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Subject: [Roll] AUTO: Matthew Anderson is out of the office (returning 12/14/2009) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 04 Dec 2009 17:21:09 -0000 I am out of the office until 12/14/2009. I am out of the office on vacation. I will occasionally check emails at night, but any critical matters should be sent to Gerald Paprocki. Also - please make sure you have the correct Matt Anderson on this email if you are surprised by this out of office. Note: This is an automated response to your message "Re: [Roll] [roll] #6: Multicast DAO" sent on 12/4/2009 11:54:49 AM. This is the only notification you will receive while this person is away. From trac@tools.ietf.org Sun Dec 6 10:56:37 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 43B363A6962 for ; Sun, 6 Dec 2009 10:56:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.511 X-Spam-Level: X-Spam-Status: No, score=-102.511 tagged_above=-999 required=5 tests=[AWL=0.089, 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 JPhyi97nWEEu for ; Sun, 6 Dec 2009 10:56:36 -0800 (PST) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:1112:1:214:22ff:fe1f:1e54]) by core3.amsl.com (Postfix) with ESMTP id E90623A6948 for ; Sun, 6 Dec 2009 10:56:35 -0800 (PST) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1NHMHQ-0007hZ-IH; Sun, 06 Dec 2009 10:56:24 -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.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.5, by Edgewall Software To: wintert@acm.org, jpv@cisco.com X-Trac-Project: roll Date: Sun, 06 Dec 2009 18:56:24 -0000 X-URL: http://tools.ietf.org/wg/roll/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/roll/trac/ticket/14#comment:1 Message-ID: <064.851d756040f83cfd459d80f2b9bd3994@tools.ietf.org> References: <055.c5c47346603d477241129dd6450f54d1@tools.ietf.org> X-Trac-Ticket-ID: 14 In-Reply-To: <055.c5c47346603d477241129dd6450f54d1@tools.ietf.org> 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: Re: [Roll] [roll] #14: Local Repair Mechanism for RPL 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: Sun, 06 Dec 2009 18:56:37 -0000 #14: Local Repair Mechanism for RPL --------------------------------+------------------------------------------- Reporter: jpv@… | Owner: wintert@… Type: defect | Status: closed Priority: major | Milestone: Component: rpl | Version: Severity: Active WG Document | Resolution: fixed Keywords: Local Repair | --------------------------------+------------------------------------------- Changes (by jpv@…): * status: new => closed * resolution: => fixed Comment: RPL -05 includes proposed mechanisms for local repair. These mechanisms, which may be configured according to policy and applied in a complementary manner, include: * Allowing a node to - Poison its sub-DAG by advertising an effective rank of INFINITY OR - detach and `float' its sub-DAG by starting a floating DODAG with a new DAGID while preserving inner-connectivity * Allowing a node, possibly after waiting for an appropriate poisoning interval, to move down the DODAG iteration within a bounded distance. The distance (a limited rank increase) is configured from the root, and serves to avoid counting all of the way to infinity while allowing the node to attempt restoration of connectivity to the DODAG iteration without waiting for a new DAGSequenceNumber. The authors await WG feedback but this closes the ticket. -- Ticket URL: roll From trac@tools.ietf.org Sun Dec 6 10:57:03 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B672D3A693E for ; Sun, 6 Dec 2009 10:57:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.515 X-Spam-Level: X-Spam-Status: No, score=-102.515 tagged_above=-999 required=5 tests=[AWL=0.085, 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 bsgoWRq6I3ba for ; Sun, 6 Dec 2009 10:57:03 -0800 (PST) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:1112:1:214:22ff:fe1f:1e54]) by core3.amsl.com (Postfix) with ESMTP id 17DE03A67F4 for ; Sun, 6 Dec 2009 10:57:03 -0800 (PST) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1NHMHt-0000BR-PA; Sun, 06 Dec 2009 10:56:53 -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.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.5, by Edgewall Software To: wintert@acm.org, jpv@cisco.com X-Trac-Project: roll Date: Sun, 06 Dec 2009 18:56:53 -0000 X-URL: http://tools.ietf.org/wg/roll/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/roll/trac/ticket/3#comment:1 Message-ID: <064.d58c9cb2785cd60d7a106a55f19a84b9@tools.ietf.org> References: <055.26a8e6525010f4a9eb8b7f6b1c6a38be@tools.ietf.org> X-Trac-Ticket-ID: 3 In-Reply-To: <055.26a8e6525010f4a9eb8b7f6b1c6a38be@tools.ietf.org> 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: Re: [Roll] [roll] #3: Need Clarification on Candidate Neighbor 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: Sun, 06 Dec 2009 18:57:03 -0000 #3: Need Clarification on Candidate Neighbor --------------------------------+------------------------------------------- Reporter: jpv@… | Owner: wintert@… Type: defect | Status: closed Priority: major | Milestone: Component: rpl | Version: Severity: Active WG Document | Resolution: fixed Keywords: | --------------------------------+------------------------------------------- Changes (by jpv@…): * status: new => closed * resolution: => fixed Comment: The text in RPL -05 is relaxed to not specify how an implementation should keep candidate neighbors. An implementor is free to choose whatever data structures are best suited to the task, for example candidate neighbors may be maintained as a discrete set or may be maintained as a property/flag in a neighbor set, etc. Implementation guidelines / suggestions for the selection and maintenance of candidate neighbors may be provided in a future appendix or companion document, but are considered to be outside of scope for the core RPL specification. -- Ticket URL: roll From trac@tools.ietf.org Sun Dec 6 23:58:04 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0431628C12C for ; Sun, 6 Dec 2009 23:58:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.521 X-Spam-Level: X-Spam-Status: No, score=-102.521 tagged_above=-999 required=5 tests=[AWL=0.079, 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 zMQ3eIX86vGi for ; Sun, 6 Dec 2009 23:58:03 -0800 (PST) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:1112:1:214:22ff:fe1f:1e54]) by core3.amsl.com (Postfix) with ESMTP id 5FD2528C118 for ; Sun, 6 Dec 2009 23:58:03 -0800 (PST) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1NHYTg-000843-ID; Sun, 06 Dec 2009 23:57:52 -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.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.5, by Edgewall Software To: jpv@cisco.com X-Trac-Project: roll Date: Mon, 07 Dec 2009 07:57:52 -0000 X-URL: http://tools.ietf.org/wg/roll/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/roll/trac/ticket/21 Message-ID: <055.eab678e68fd776d630ae59dfee53583b@tools.ietf.org> X-Trac-Ticket-ID: 21 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] #21: RPL control Bits in flow Label 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, 07 Dec 2009 07:58:04 -0000 #21: RPL control Bits in flow Label --------------------------------+------------------------------------------- Reporter: jpv@… | Owner: jpv@… Type: task | Status: new Priority: major | Milestone: Component: rpl | Version: Severity: Active WG Document | Keywords: --------------------------------+------------------------------------------- A decision has to be made on whether the control bits of RPL currently specified in the Flow Label should be moved to a newly defined IPv6 extended header. -- Ticket URL: roll From jabeille@cisco.com Mon Dec 7 06:37:36 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C89D03A6A5F for ; Mon, 7 Dec 2009 06:37:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.69 X-Spam-Level: X-Spam-Status: No, score=-5.69 tagged_above=-999 required=5 tests=[AWL=-3.091, 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 LxCaldBZF4Aj for ; Mon, 7 Dec 2009 06:37:35 -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 2AEEA3A6A5D for ; Mon, 7 Dec 2009 06:37:35 -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: AhYAAFOiHEuQ/uCWiWdsb2JhbACbcQEBAQoLERMGplyWEYQzBI0k X-IronPort-AV: E=Sophos;i="4.47,355,1257120000"; d="scan'208";a="753155" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-2.cisco.com with ESMTP; 07 Dec 2009 14:11:15 +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 nB7EbOFP028411; Mon, 7 Dec 2009 14:37:24 GMT Received: from xmb-ams-113.cisco.com ([144.254.74.88]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 7 Dec 2009 15:37: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: Mon, 7 Dec 2009 15:37:18 +0100 Message-ID: In-Reply-To: <0272DA19-AA52-4B8C-A434-6C45E6B7919F@cs.stanford.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] multicast DAO Thread-Index: Acp0ck22RsRysMxQTOeqZ2ee+4xt8wC2HOrQ References: <9F5AB59D-5673-4C75-A953-33C3384527E6@cs.stanford.edu> <87k4xe207c.fsf@kelsey-ws.hq.ember.com> <0272DA19-AA52-4B8C-A434-6C45E6B7919F@cs.stanford.edu> From: "Julien Abeille (jabeille)" To: "Philip Levis" , "Richard Kelsey" X-OriginalArrivalTime: 07 Dec 2009 14:37:23.0871 (UTC) FILETIME=[CA4B7AF0:01CA774A] Cc: roll@ietf.org Subject: Re: [Roll] multicast 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: Mon, 07 Dec 2009 14:37:36 -0000 Agreed. Julien =20 > -----Original Message----- > From: Philip Levis [mailto:pal@cs.stanford.edu]=20 > Sent: vendredi 4 d=E9cembre 2009 00:43 > To: Richard Kelsey > Cc: Julien Abeille (jabeille); roll@ietf.org > Subject: Re: [Roll] multicast DAO >=20 >=20 > On Nov 25, 2009, at 5:39 AM, Richard Kelsey wrote: >=20 > >> Date: Wed, 25 Nov 2009 10:43:41 +0100 > >> From: "Julien Abeille (jabeille)" > > > >>> From: Philip Levis [mailto:pal@cs.stanford.edu] > >>> Sent: vendredi 20 novembre 2009 19:31 > >>> > >>> Point-to-point communication between nodes is needed by some=20 > >>> applications. Section 5.2.2 of > >>> draft-ietf-roll-building-routing-reqs-07: > >>> > >>> "A network device MUST be able to communicate in a point-to-point=20 > >>> manner with any other device on the network." > >> > >> Sure, and DAOs (whether stored only at root are not) solve this=20 > >> issue. > >> May not be the most efficient, but the sceanrios multicast=20 > DAOs solve=20 > >> are so limited that we will end up with 10 solutions for=20 > 10 scenarios=20 > >> if we go that path. > >> > >> I would personaly drop multicast DAOs > > > > I agree. As we have done with unicasts, we need to look=20 > carefully at=20 > > the multicast requirements and find ways to solve the easy and/or=20 > > common cases first. I do not think that there is a workable=20 > > one-size-fits-all multicast solution. >=20 > Richard and I discussed this further: turns out he was=20 > misunderstanding the case I was describing. Based on the fact=20 > that many application domains require point-to-point routing=20 > and the expectation is many networks will be at most a few=20 > hops across, there seems to be some consensus that keeping=20 > multicast DAOs in is worthwhile. JP will have some results=20 > indicating how much complexity they might add to an=20 > implementation: his experience is not much. >=20 > So the current resolution is to keep multicast DAOs in, as=20 > the belief is the use case described originally by Julien is=20 > an important enough optimization to warrant their inclusion. >=20 > Phil >=20 From jabeille@cisco.com Mon Dec 7 06:42:31 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 708833A6A55 for ; Mon, 7 Dec 2009 06:42:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.432 X-Spam-Level: X-Spam-Status: No, score=-5.432 tagged_above=-999 required=5 tests=[AWL=-2.834, 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 V4iT9M+NUJsh for ; Mon, 7 Dec 2009 06:42: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 B28FD3A6A4C for ; Mon, 7 Dec 2009 06:42:28 -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: AhgAAH6jHEuQ/uCWiWdsb2JhbACCHJlVAQEBCgsREwamUpYUhDME X-IronPort-AV: E=Sophos;i="4.47,356,1257120000"; d="scan'208,217";a="753744" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-2.cisco.com with ESMTP; 07 Dec 2009 14:16:08 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id nB7EgHAu029984 for ; Mon, 7 Dec 2009 14:42:17 GMT Received: from xmb-ams-113.cisco.com ([144.254.74.88]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 7 Dec 2009 15:42: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_01CA774B.793AF43E" Date: Mon, 7 Dec 2009 15:42:12 +0100 Message-ID: In-Reply-To: <6A2A459175DABE4BB11DE2026AA50A5DCB64BA@XMB-AMS-107.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] #16 Thread-Index: Acp0ynJLQoXUd6iTTJCP8JXamj5kxwAHX6tgAACzPlAAAounsAABnBAwAJPwX/A= References: <6A2A459175DABE4BB11DE2026AA50A5DCB61E4@XMB-AMS-107.cisco.com><8A977BDC5A7B0E429B0F521E8D6F91EEDF9592@XMB-AMS-103.cisco.com><6A2A459175DABE4BB11DE2026AA50A5DCB63D6@XMB-AMS-107.cisco.com><8A977BDC5A7B0E429B0F521E8D6F91EEE5ECD9@XMB-AMS-103.cisco.com> <6A2A459175DABE4BB11DE2026AA50A5DCB64BA@XMB-AMS-107.cisco.com> From: "Julien Abeille (jabeille)" To: "Pascal Thubert (pthubert)" , "Mathilde Durvy (mdurvy)" X-OriginalArrivalTime: 07 Dec 2009 14:42:17.0531 (UTC) FILETIME=[795470B0:01CA774B] Cc: roll@ietf.org Subject: Re: [Roll] #16 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 07 Dec 2009 14:42:31 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA774B.793AF43E Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Pascal, =20 I agree with NUD or others being used for neighbor reachability = (different from e.g. parent reachability and applies to all RPL "peers") .=20 what is the difference between the lifetime of a prefix and the lifetime = of a route? we still have two mechanisms here to decide whether a route is still = valid (if i get it right): - DIO with D bit - lifetime why? Best, Julien =20 ________________________________ From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of = Pascal Thubert (pthubert) Sent: vendredi 4 d=E9cembre 2009 17:14 To: Mathilde Durvy (mdurvy) Cc: roll@ietf.org Subject: Re: [Roll] #16 =09 =09 Hi Mathilde: =20 =20 [Mathilde] So if I understand correctly the DAO lifetime is removed = for the DAO packet =20 The DAO lifetime is the lifetime of the prefix, not that of the route. = You can hardly say how long a route can be valid. After that lifetime expires, the prefix will not exist anymore so = obviously, if the lifetime was not refreshed, the route associated has = to be removed. =20 =20 =20 [Mathilde] I guess my point is that I see a small contradiction in your = answers to the 2 previous questions. If we useonly local confidence to = assess neighbor reachability why do we need an extra mechanism to assess = the reachability to the neighbors that are sending DAOs to us? In other word the retry_count + RemoveTimer test reachability to a = neighbor, the local confidence tests the reachability to the same = neighbor, why do weuse both? Is it that the local confidence is too 'slow' for DAO neighbors = (children) but good enough for DIO neighbors (parents)? =20 I would just like to understand the reasoning, otherwise I'm happy with = the change you propose. =20 The local confidence assesses reachability of the neighbor. =20 A neighbor might be lost if - NUD declares it unreachable - The link goes down =20 The retry_count + RemoveTimer test assesses reachability of the final = destination, may far behind the neighbor =20 A final destination might be lost for a number of reasons if you look = at it - No DAO (null lifetime) - Prefix Lifetime expires - Retry count expires - Last neighbor via which we have a route to destination goes = down - Routing shutdown - ... =20 Makes sense? =20 Pascal =20 =20 From: Mathilde Durvy (mdurvy)=20 Sent: vendredi 4 d=E9cembre 2009 14:59 To: Pascal Thubert (pthubert) Cc: 'roll@ietf.org' Subject: RE: #16 =20 Hi Pascal, =20 Thanks for the update. Please see my questions below. Best, Mathilde =20 =09 ________________________________ =20 Issue 16 says "Hi All, This is my current understanding: - Parents are = removed based on OF selection (decision to move within the DAG, change = DAG, etc) - Destination prefixes are removed after the retry / = RemoveTimer? procedure described in section 5.10.1.1.1. This is = essentially a keep alive mechanism based on DIO (D bit set) - DAO = exchanges. - Route corresponding to destination prefixes are removed = when DAO lifetime expires? Are they also removed when the corresponding = destination prefix is removed? - When are routes corresponding to = parents removed? Do they also have a lifetime? - What happens when a = neighbor disappears, are the corresponding parents/destination/routes = removed? The current behavior seems quite asymmetric... There is some = kind of keep alive mechanism for destination prefixes, but not for = parents. There is a lifetime associated with routes corresponding to = destination prefixes but not for routes corresponding to parents. Is = that a design choice? I would appreciate some clarifications. " =20 Proposed new text : =20 If Neighbor Unreachability Detection (NUD), or an equivalent mechanism, determines that a neighbor is no longer reachable, then a RPL node MUST NOT consider this node in the neighbor set when calculating and advertising routes until the node determines it is reachable again. =20 =20 Routes via that neighbor MUST be eliminated from the routing table, and the node SHOULD poison using no-DAO all DAO routes that it has advertised via DAO and that it can reach only via that neighbor. =20 The internals (keeping info about the DAOs to resync more quickly) are = not described, long as the node behaves as if it has cleaned everything = reachable only via the lost neighbor. >> Does this mean that there is no lifetime associated with DAO routes? >>Is the retry_count + RemoveTimer procedure maintained in version 05?=20 >> Does this mean that the local confidence is the only criteria to = assess neighbor (including parents and child) reachability? =20 Best, Mathilde =20 ------_=_NextPart_001_01CA774B.793AF43E Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi Pascal,
 
I agree with NUD or others being used for = neighbor=20 reachability (different from e.g. parent reachability and applies to all = RPL=20 "peers")
.
what is the difference between the lifetime of = a prefix and=20 the lifetime of a route?
we still have two mechanisms here to decide = whether a route=20 is still valid (if i get it right):
- DIO with D bit
- lifetime
why?
Best,
Julien
 

From: roll-bounces@ietf.org=20 [mailto:roll-bounces@ietf.org] On Behalf Of Pascal Thubert=20 (pthubert)
Sent: vendredi 4 d=E9cembre 2009 = 17:14
To:=20 Mathilde Durvy (mdurvy)
Cc: roll@ietf.org
Subject: = Re:=20 [Roll] #16

Hi=20 Mathilde:

 

 

 [Mathilde]=20 So if I understand correctly the DAO lifetime is removed for the DAO=20 packet

 

The DAO lifetime = is the=20 lifetime of the prefix, not that of the route. You can = hardly=20 say how long a route can be valid.

After that = lifetime expires,=20 the prefix will not exist anymore so obviously, if the lifetime was = not=20 refreshed,  the route associated has to be = removed.

 

 

 

[Mathilde]=20 I guess my point is that I see a small contradiction in your answers = to the 2=20 previous questions. If we useonly local confidence to assess neighbor=20 reachability why do we need an extra mechanism to assess the = reachability to=20 the neighbors that are sending DAOs to us?

In=20 other word the retry_count + RemoveTimer test reachability to a = neighbor, the=20 local confidence tests the reachability to the same neighbor, why do = weuse=20 both?

Is it=20 that the local confidence is too 'slow' for DAO neighbors (children) = but good=20 enough for DIO neighbors (parents)?

 

I=20 would just like to understand the reasoning, otherwise I'm happy with = the=20 change you propose.

 

The local = confidence assesses=20 reachability of the neighbor.

 

A neighbor might = be lost=20 if

-         =20 NUD = declares it=20 unreachable

-         =20 The link = goes=20 down

 

The retry_count + = RemoveTimer=20 test assesses reachability of the final destination, may far behind = the=20 neighbor

 

A final = destination might be=20 lost for a number of reasons if you look at it

-         =20 No DAO = (null=20 lifetime)

-         =20 Prefix = Lifetime=20 expires

-         =20 Retry = count=20 expires

-         =20 Last = neighbor via=20 which we have a route to destination goes down

-         =20 Routing=20 shutdown

-         =20 =85

 

 Makes=20 sense?

 

Pascal

 

 

From: = Mathilde Durvy=20 (mdurvy)
Sent: vendredi 4 d=E9cembre 2009 = 14:59
To: Pascal=20 Thubert (pthubert)
Cc: 'roll@ietf.org'
Subject: = RE:=20 #16

 

Hi=20 Pascal,

 

Thanks=20 for the update. Please see my questions below.

Best,

Mathilde

 

 

Issue 16 says =93Hi All, This is my current = understanding: -=20 Parents are removed based on OF selection (decision to move within the = DAG,=20 change DAG, etc) - Destination prefixes are removed after the retry /=20 RemoveTimer? procedure described in section 5.10.1.1.1. This is = essentially a=20 keep alive mechanism based on DIO (D bit set) - DAO exchanges. - Route = corresponding to destination prefixes are removed when DAO lifetime = expires?=20 Are they also removed when the corresponding destination prefix is = removed? -=20 When are routes corresponding to parents removed? Do they also have a=20 lifetime? - What happens when a neighbor disappears, are the = corresponding=20 parents/destination/routes removed? The current behavior seems quite=20 asymmetric... There is some kind of keep alive mechanism for = destination=20 prefixes, but not for parents. There is a lifetime associated with = routes=20 corresponding to destination prefixes but not for routes corresponding = to=20 parents. Is that a design choice? I would appreciate some = clarifications.=20 =94

 

Proposed new text :

 

   If = Neighbor=20 Unreachability Detection (NUD), or an equivalent

   = mechanism,=20 determines that a neighbor is no longer reachable, then=20 a

   RPL = node MUST=20 NOT consider this node in the neighbor set when

   = calculating=20 and advertising routes until the node determines it = is

   = reachable=20 again.  

 

   = Routes via=20 that neighbor MUST be eliminated from the routing = table,

   and = the node=20 SHOULD poison using no-DAO all DAO routes that = it

   has = advertised via DAO and that it can reach only via that=20 neighbor.

 

The internals (keeping info about the DAOs to = resync more=20 quickly) are not described, long as the node behaves as if it has = cleaned=20 everything reachable only via the lost neighbor.

>>=20 Does this mean that there is no lifetime associated with DAO=20 routes?

>>Is=20 the retry_count + RemoveTimer procedure maintained in version 05?=20

>>=20 Does this mean that the local confidence is the only criteria to = assess=20 neighbor (including parents and child) = reachability?

 

Best,

Mathilde

 

------_=_NextPart_001_01CA774B.793AF43E-- From pthubert@cisco.com Mon Dec 7 07:57:35 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6DDFB3A6A6A for ; Mon, 7 Dec 2009 07:57:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.392 X-Spam-Level: X-Spam-Status: No, score=-7.392 tagged_above=-999 required=5 tests=[AWL=-0.794, 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 tmtPKARNprBL for ; Mon, 7 Dec 2009 07:57:27 -0800 (PST) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 7B9E23A681C for ; Mon, 7 Dec 2009 07:57:27 -0800 (PST) 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: AsoEACC1HEtAZnwN/2dsb2JhbACCHME6lhmEMwSBZw X-IronPort-AV: E=Sophos;i="4.47,356,1257120000"; d="scan'208,217";a="446038162" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by sj-iport-6.cisco.com with ESMTP; 07 Dec 2009 15:57: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 nB7Fv4b8024214 for ; Mon, 7 Dec 2009 15:57: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, 7 Dec 2009 16:57:05 +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_01CA7755.EC21EFAF" Date: Mon, 7 Dec 2009 16:56:59 +0100 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5DCB6BCE@XMB-AMS-107.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] #16 Thread-Index: Acp0ynJLQoXUd6iTTJCP8JXamj5kxwAHX6tgAACzPlAAAounsAABnBAwAJPwX/AAAnkvYA== References: <6A2A459175DABE4BB11DE2026AA50A5DCB61E4@XMB-AMS-107.cisco.com><8A977BDC5A7B0E429B0F521E8D6F91EEDF9592@XMB-AMS-103.cisco.com><6A2A459175DABE4BB11DE2026AA50A5DCB63D6@XMB-AMS-107.cisco.com><8A977BDC5A7B0E429B0F521E8D6F91EEE5ECD9@XMB-AMS-103.cisco.com> <6A2A459175DABE4BB11DE2026AA50A5DCB64BA@XMB-AMS-107.cisco.com> From: "Pascal Thubert (pthubert)" To: "Julien Abeille (jabeille)" , "Mathilde Durvy (mdurvy)" X-OriginalArrivalTime: 07 Dec 2009 15:57:05.0224 (UTC) FILETIME=[EC340C80:01CA7755] Cc: roll@ietf.org Subject: Re: [Roll] #16 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 07 Dec 2009 15:57:35 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA7755.EC21EFAF Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Julien: =20 There is no such thing as a lifetime of a route. The routing protocol = maintain the routes for as long as they can be they cannot predict how = long that will be. A prefix, a registration, a router and an address all have a lifetime = with IPv6 because administratively, there's some process to lock = resourced, and then renew or renumber. This is what the prefix lifetime in DAO is about. A capping of how long = things are administratively expected to be there. So that a peer does = not keep associated resources a lot longer than the parent resource it = depends on. =20 Cheers, =20 Pascal From: Julien Abeille (jabeille)=20 Sent: lundi 7 d=E9cembre 2009 15:42 To: Pascal Thubert (pthubert); Mathilde Durvy (mdurvy) Cc: roll@ietf.org Subject: RE: [Roll] #16 =20 Hi Pascal, =20 I agree with NUD or others being used for neighbor reachability = (different from e.g. parent reachability and applies to all RPL "peers") .=20 what is the difference between the lifetime of a prefix and the lifetime = of a route? we still have two mechanisms here to decide whether a route is still = valid (if i get it right): - DIO with D bit - lifetime why? Best, Julien =20 =20 =09 ________________________________ From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of = Pascal Thubert (pthubert) Sent: vendredi 4 d=E9cembre 2009 17:14 To: Mathilde Durvy (mdurvy) Cc: roll@ietf.org Subject: Re: [Roll] #16 Hi Mathilde: =20 =20 [Mathilde] So if I understand correctly the DAO lifetime is removed = for the DAO packet =20 The DAO lifetime is the lifetime of the prefix, not that of the route. = You can hardly say how long a route can be valid. After that lifetime expires, the prefix will not exist anymore so = obviously, if the lifetime was not refreshed, the route associated has = to be removed. =20 =20 =20 [Mathilde] I guess my point is that I see a small contradiction in your = answers to the 2 previous questions. If we useonly local confidence to = assess neighbor reachability why do we need an extra mechanism to assess = the reachability to the neighbors that are sending DAOs to us? In other word the retry_count + RemoveTimer test reachability to a = neighbor, the local confidence tests the reachability to the same = neighbor, why do weuse both? Is it that the local confidence is too 'slow' for DAO neighbors = (children) but good enough for DIO neighbors (parents)? =20 I would just like to understand the reasoning, otherwise I'm happy with = the change you propose. =20 The local confidence assesses reachability of the neighbor. =20 A neighbor might be lost if - NUD declares it unreachable - The link goes down =20 The retry_count + RemoveTimer test assesses reachability of the final = destination, may far behind the neighbor =20 A final destination might be lost for a number of reasons if you look = at it - No DAO (null lifetime) - Prefix Lifetime expires - Retry count expires - Last neighbor via which we have a route to destination goes = down - Routing shutdown - ... =20 Makes sense? =20 Pascal =20 =20 From: Mathilde Durvy (mdurvy)=20 Sent: vendredi 4 d=E9cembre 2009 14:59 To: Pascal Thubert (pthubert) Cc: 'roll@ietf.org' Subject: RE: #16 =20 Hi Pascal, =20 Thanks for the update. Please see my questions below. Best, Mathilde =20 =09 ________________________________ =20 Issue 16 says "Hi All, This is my current understanding: - Parents are = removed based on OF selection (decision to move within the DAG, change = DAG, etc) - Destination prefixes are removed after the retry / = RemoveTimer? procedure described in section 5.10.1.1.1. This is = essentially a keep alive mechanism based on DIO (D bit set) - DAO = exchanges. - Route corresponding to destination prefixes are removed = when DAO lifetime expires? Are they also removed when the corresponding = destination prefix is removed? - When are routes corresponding to = parents removed? Do they also have a lifetime? - What happens when a = neighbor disappears, are the corresponding parents/destination/routes = removed? The current behavior seems quite asymmetric... There is some = kind of keep alive mechanism for destination prefixes, but not for = parents. There is a lifetime associated with routes corresponding to = destination prefixes but not for routes corresponding to parents. Is = that a design choice? I would appreciate some clarifications. " =20 Proposed new text : =20 If Neighbor Unreachability Detection (NUD), or an equivalent mechanism, determines that a neighbor is no longer reachable, then a RPL node MUST NOT consider this node in the neighbor set when calculating and advertising routes until the node determines it is reachable again. =20 =20 Routes via that neighbor MUST be eliminated from the routing table, and the node SHOULD poison using no-DAO all DAO routes that it has advertised via DAO and that it can reach only via that neighbor. =20 The internals (keeping info about the DAOs to resync more quickly) are = not described, long as the node behaves as if it has cleaned everything = reachable only via the lost neighbor. >> Does this mean that there is no lifetime associated with DAO routes? >>Is the retry_count + RemoveTimer procedure maintained in version 05?=20 >> Does this mean that the local confidence is the only criteria to = assess neighbor (including parents and child) reachability? =20 Best, Mathilde =20 ------_=_NextPart_001_01CA7755.EC21EFAF Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi = Julien:

 

There is no such = thing as a lifetime of a route. The routing protocol maintain the routes for as = long as they can be they cannot predict how long that will = be.

A prefix, a = registration, a router and an address all have a lifetime with IPv6 because = administratively, there’s some process to lock resourced, and then renew or = renumber.

This is what the = prefix lifetime in DAO is about. A capping of how long things are administratively = expected to be there. So that a peer does not keep associated resources a lot longer = than the parent resource it depends on.

 

Cheers,

 

Pascal

From:= Julien = Abeille (jabeille)
Sent: lundi 7 d=E9cembre 2009 15:42
To: Pascal Thubert (pthubert); Mathilde Durvy (mdurvy)
Cc: roll@ietf.org
Subject: RE: [Roll] #16

 

Hi Pascal,

 

I agree with NUD or others being used for neighbor = reachability (different from e.g. parent reachability and applies to all RPL "peers")

.

what is the difference between the lifetime of a prefix and = the lifetime of a route?

we still have two mechanisms here to decide whether a route = is still valid (if i get it right):

- DIO with D bit

- lifetime

why?

Best,

Julien

 

 

From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Pascal Thubert = (pthubert)
Sent: vendredi 4 d=E9cembre 2009 17:14
To: Mathilde Durvy (mdurvy)
Cc: roll@ietf.org
Subject: Re: [Roll] #16

Hi = Mathilde:

 

 

 [Mathilde] So if I understand correctly the DAO = lifetime is removed for the DAO packet

 

The DAO lifetime is = the lifetime of the prefix, not that of the route. You can hardly say = how long a route can be valid.

After that lifetime = expires, the prefix will not exist anymore so obviously, if the lifetime was not = refreshed,  the route associated has to be removed.

 

 

 

[Mathilde] I guess my point is that I see a small = contradiction in your answers to the 2 previous questions. If we useonly local confidence = to assess neighbor reachability why do we need an extra mechanism to assess = the reachability to the neighbors that are sending DAOs to us?

In other word the retry_count + RemoveTimer test = reachability to a neighbor, the local confidence tests the reachability to the same = neighbor, why do weuse both?

Is it that the local confidence is too 'slow' for DAO = neighbors (children) but good enough for DIO neighbors (parents)?

 

I would just like to understand the reasoning, otherwise I'm = happy with the change you propose.

 

The local confidence = assesses reachability of the neighbor.

 

A neighbor might be = lost if

-       &= nbsp;  NUD declares it = unreachable

-       &= nbsp;  The link goes = down

 

The retry_count + = RemoveTimer test assesses reachability of the final destination, may far behind the neighbor

 

A final destination = might be lost for a number of reasons if you look at it

-       &= nbsp;  No DAO (null = lifetime)

-       &= nbsp;  Prefix Lifetime = expires

-       &= nbsp;  Retry count = expires

-       &= nbsp;  Last neighbor via which we have a = route to destination goes down

-       &= nbsp;  Routing = shutdown

-       &= nbsp;  …

 

 Makes = sense?

 

Pascal

 

 

From:= Mathilde = Durvy (mdurvy)
Sent: vendredi 4 d=E9cembre 2009 14:59
To: Pascal Thubert (pthubert)
Cc: 'roll@ietf.org'
Subject: RE: #16

 

Hi Pascal,

 

Thanks for the update. Please see my questions = below.

Best,

Mathilde

 

 

Issue 16 says “Hi All, This is my current understanding: - Parents are removed based on OF selection (decision to = move within the DAG, change DAG, etc) - Destination prefixes are removed = after the retry / RemoveTimer? procedure described in section 5.10.1.1.1. This is essentially a keep alive mechanism based on DIO (D bit set) - DAO = exchanges. - Route corresponding to destination prefixes are removed when DAO = lifetime expires? Are they also removed when the corresponding destination prefix = is removed? - When are routes corresponding to parents removed? Do they = also have a lifetime? - What happens when a neighbor disappears, are the = corresponding parents/destination/routes removed? The current behavior seems quite asymmetric... There is some kind of keep alive mechanism for destination prefixes, but not for parents. There is a lifetime associated with = routes corresponding to destination prefixes but not for routes corresponding = to parents. Is that a design choice? I would appreciate some = clarifications. ”

 

Proposed new text :

 

   If Neighbor Unreachability Detection (NUD), or an = equivalent

   mechanism, determines that a neighbor is no longer reachable, then = a

   RPL node MUST NOT consider this node in the neighbor set = when

   calculating and advertising routes until the node determines it = is

   reachable again.  

 

   Routes via that neighbor MUST be eliminated from the routing = table,

   and the node SHOULD poison using no-DAO all DAO routes that = it

   has advertised via DAO and that it can reach only via that = neighbor.

 

The internals (keeping info about the DAOs to = resync more quickly) are not described, long as the node behaves as if it has = cleaned everything reachable only via the lost neighbor.

>> Does this mean that there is no lifetime associated = with DAO routes?

>>Is the retry_count + RemoveTimer procedure = maintained in version 05?

>> Does this mean that the local confidence is the = only criteria to assess neighbor (including parents and child) = reachability?

 

Best,

Mathilde

 

------_=_NextPart_001_01CA7755.EC21EFAF-- From jabeille@cisco.com Mon Dec 7 08:01:51 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1BC603A681D for ; Mon, 7 Dec 2009 08:01:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.214 X-Spam-Level: X-Spam-Status: No, score=-7.214 tagged_above=-999 required=5 tests=[AWL=-0.616, 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 UJqZ9Ew-0Zv2 for ; Mon, 7 Dec 2009 08:01:49 -0800 (PST) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id 8F1873A681C for ; Mon, 7 Dec 2009 08:01:49 -0800 (PST) Authentication-Results: sj-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AsoEAAS2HEtAZnwM/2dsb2JhbACCHME6lhmEMwSBZw X-IronPort-AV: E=Sophos;i="4.47,356,1257120000"; d="scan'208,217";a="227511382" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by sj-iport-2.cisco.com with ESMTP; 07 Dec 2009 16:01:32 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id nB7G0s36010841 for ; Mon, 7 Dec 2009 16:01:32 GMT Received: from xmb-ams-113.cisco.com ([144.254.74.88]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 7 Dec 2009 17:01:31 +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_01CA7756.8ABB6F1F" Date: Mon, 7 Dec 2009 17:01:25 +0100 Message-ID: In-Reply-To: <6A2A459175DABE4BB11DE2026AA50A5DCB6BCE@XMB-AMS-107.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] #16 Thread-Index: Acp0ynJLQoXUd6iTTJCP8JXamj5kxwAHX6tgAACzPlAAAounsAABnBAwAJPwX/AAAnkvYAAAQ0DA References: <6A2A459175DABE4BB11DE2026AA50A5DCB61E4@XMB-AMS-107.cisco.com><8A977BDC5A7B0E429B0F521E8D6F91EEDF9592@XMB-AMS-103.cisco.com><6A2A459175DABE4BB11DE2026AA50A5DCB63D6@XMB-AMS-107.cisco.com><8A977BDC5A7B0E429B0F521E8D6F91EEE5ECD9@XMB-AMS-103.cisco.com> <6A2A459175DABE4BB11DE2026AA50A5DCB64BA@XMB-AMS-107.cisco.com> <6A2A459175DABE4BB11DE2026AA50A5DCB6BCE@XMB-AMS-107.cisco.com> From: "Julien Abeille (jabeille)" To: "Pascal Thubert (pthubert)" , "Mathilde Durvy (mdurvy)" X-OriginalArrivalTime: 07 Dec 2009 16:01:31.0302 (UTC) FILETIME=[8ACC5460:01CA7756] Cc: roll@ietf.org Subject: Re: [Roll] #16 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 07 Dec 2009 16:01:51 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA7756.8ABB6F1F Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Pascal, =20 I get it, I think we just disagreed on terms. I'll still call it a route = lifetime ;-) (even though it is an admin concept, decoupling totally the = admin from the actual route does not help as the forwarding engine will = use the route even if it is supposedly just administratively up). =20 Best, Julien ________________________________ From: Pascal Thubert (pthubert)=20 Sent: lundi 7 d=E9cembre 2009 16:57 To: Julien Abeille (jabeille); Mathilde Durvy (mdurvy) Cc: 'roll@ietf.org' Subject: RE: [Roll] #16 =09 =09 Hi Julien: =20 There is no such thing as a lifetime of a route. The routing protocol = maintain the routes for as long as they can be they cannot predict how = long that will be. A prefix, a registration, a router and an address all have a lifetime = with IPv6 because administratively, there's some process to lock = resourced, and then renew or renumber. This is what the prefix lifetime in DAO is about. A capping of how long = things are administratively expected to be there. So that a peer does = not keep associated resources a lot longer than the parent resource it = depends on. =20 Cheers, =20 Pascal From: Julien Abeille (jabeille)=20 Sent: lundi 7 d=E9cembre 2009 15:42 To: Pascal Thubert (pthubert); Mathilde Durvy (mdurvy) Cc: roll@ietf.org Subject: RE: [Roll] #16 =20 Hi Pascal, =20 I agree with NUD or others being used for neighbor reachability = (different from e.g. parent reachability and applies to all RPL "peers") .=20 what is the difference between the lifetime of a prefix and the = lifetime of a route? we still have two mechanisms here to decide whether a route is still = valid (if i get it right): - DIO with D bit - lifetime why? Best, Julien =20 =20 =09 ________________________________ From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf = Of Pascal Thubert (pthubert) Sent: vendredi 4 d=E9cembre 2009 17:14 To: Mathilde Durvy (mdurvy) Cc: roll@ietf.org Subject: Re: [Roll] #16 Hi Mathilde: =20 =20 [Mathilde] So if I understand correctly the DAO lifetime is removed = for the DAO packet =20 The DAO lifetime is the lifetime of the prefix, not that of the route. = You can hardly say how long a route can be valid. After that lifetime expires, the prefix will not exist anymore so = obviously, if the lifetime was not refreshed, the route associated has = to be removed. =20 =20 =20 [Mathilde] I guess my point is that I see a small contradiction in = your answers to the 2 previous questions. If we useonly local confidence = to assess neighbor reachability why do we need an extra mechanism to = assess the reachability to the neighbors that are sending DAOs to us? In other word the retry_count + RemoveTimer test reachability to a = neighbor, the local confidence tests the reachability to the same = neighbor, why do weuse both? Is it that the local confidence is too 'slow' for DAO neighbors = (children) but good enough for DIO neighbors (parents)? =20 I would just like to understand the reasoning, otherwise I'm happy = with the change you propose. =20 The local confidence assesses reachability of the neighbor. =20 A neighbor might be lost if - NUD declares it unreachable - The link goes down =20 The retry_count + RemoveTimer test assesses reachability of the final = destination, may far behind the neighbor =20 A final destination might be lost for a number of reasons if you look = at it - No DAO (null lifetime) - Prefix Lifetime expires - Retry count expires - Last neighbor via which we have a route to destination goes = down - Routing shutdown - ... =20 Makes sense? =20 Pascal =20 =20 From: Mathilde Durvy (mdurvy)=20 Sent: vendredi 4 d=E9cembre 2009 14:59 To: Pascal Thubert (pthubert) Cc: 'roll@ietf.org' Subject: RE: #16 =20 Hi Pascal, =20 Thanks for the update. Please see my questions below. Best, Mathilde =20 =09 ________________________________ =20 Issue 16 says "Hi All, This is my current understanding: - Parents are = removed based on OF selection (decision to move within the DAG, change = DAG, etc) - Destination prefixes are removed after the retry / = RemoveTimer? procedure described in section 5.10.1.1.1. This is = essentially a keep alive mechanism based on DIO (D bit set) - DAO = exchanges. - Route corresponding to destination prefixes are removed = when DAO lifetime expires? Are they also removed when the corresponding = destination prefix is removed? - When are routes corresponding to = parents removed? Do they also have a lifetime? - What happens when a = neighbor disappears, are the corresponding parents/destination/routes = removed? The current behavior seems quite asymmetric... There is some = kind of keep alive mechanism for destination prefixes, but not for = parents. There is a lifetime associated with routes corresponding to = destination prefixes but not for routes corresponding to parents. Is = that a design choice? I would appreciate some clarifications. " =20 Proposed new text : =20 If Neighbor Unreachability Detection (NUD), or an equivalent mechanism, determines that a neighbor is no longer reachable, then = a RPL node MUST NOT consider this node in the neighbor set when calculating and advertising routes until the node determines it is reachable again. =20 =20 Routes via that neighbor MUST be eliminated from the routing table, and the node SHOULD poison using no-DAO all DAO routes that it has advertised via DAO and that it can reach only via that = neighbor. =20 The internals (keeping info about the DAOs to resync more quickly) are = not described, long as the node behaves as if it has cleaned everything = reachable only via the lost neighbor. >> Does this mean that there is no lifetime associated with DAO = routes? >>Is the retry_count + RemoveTimer procedure maintained in version 05? = >> Does this mean that the local confidence is the only criteria to = assess neighbor (including parents and child) reachability? =20 Best, Mathilde =20 ------_=_NextPart_001_01CA7756.8ABB6F1F Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi Pascal,
 
I get it, I think we just disagreed on terms. = I'll still=20 call it a route lifetime ;-) (even though it is an admin concept,=20 decoupling totally the admin from the actual route does not help as the=20 forwarding engine will use the route even if it is supposedly just=20 administratively up).
 
Best,
Julien

From: Pascal Thubert (pthubert)=20
Sent: lundi 7 d=E9cembre 2009 16:57
To: Julien = Abeille=20 (jabeille); Mathilde Durvy (mdurvy)
Cc:=20 'roll@ietf.org'
Subject: RE: [Roll] #16

Hi=20 Julien:

 

There is no such = thing as a=20 lifetime of a route. The routing protocol maintain the routes for as = long as=20 they can be they cannot predict how long that will = be.

A prefix, a = registration, a=20 router and an address all have a lifetime with IPv6 because = administratively,=20 there=92s some process to lock resourced, and then renew or=20 renumber.

This is what the = prefix=20 lifetime in DAO is about. A capping of how long things are = administratively=20 expected to be there. So that a peer does not keep associated = resources a lot=20 longer than the parent resource it depends on.

 

Cheers,

 

Pascal

From: Julien = Abeille=20 (jabeille)
Sent: lundi 7 d=E9cembre 2009 = 15:42
To: Pascal=20 Thubert (pthubert); Mathilde Durvy (mdurvy)
Cc:=20 roll@ietf.org
Subject: RE: [Roll]=20 #16

 

Hi=20 Pascal,

 

I=20 agree with NUD or others being used for neighbor reachability = (different from=20 e.g. parent reachability and applies to all RPL "peers")

.=20

what=20 is the difference between the lifetime of a prefix and the lifetime of = a=20 route?

we=20 still have two mechanisms here to decide whether a route is still = valid (if i=20 get it right):

- DIO=20 with D bit

-=20 lifetime

why?

Best,

Julien

 

 

From:=20 roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of = Pascal Thubert (pthubert)
Sent: vendredi 4 d=E9cembre = 2009=20 17:14
To: Mathilde Durvy (mdurvy)
Cc:=20 roll@ietf.org
Subject: Re: [Roll] #16

Hi=20 Mathilde:

 

 

 [Mathilde]=20 So if I understand correctly the DAO lifetime is removed for the DAO = packet

 

The DAO lifetime = is the=20 lifetime of the prefix, not that of the route. You can = hardly=20 say how long a route can be valid.

After that = lifetime expires,=20 the prefix will not exist anymore so obviously, if the lifetime was = not=20 refreshed,  the route associated has to be=20 removed.

 

 

 

[Mathilde]=20 I guess my point is that I see a small contradiction in your answers = to the=20 2 previous questions. If we useonly local confidence to assess = neighbor=20 reachability why do we need an extra mechanism to assess the = reachability to=20 the neighbors that are sending DAOs to us?

In=20 other word the retry_count + RemoveTimer test reachability to a = neighbor,=20 the local confidence tests the reachability to the same neighbor, = why do=20 weuse both?

Is=20 it that the local confidence is too 'slow' for DAO neighbors = (children) but=20 good enough for DIO neighbors (parents)?

 

I=20 would just like to understand the reasoning, otherwise I'm happy = with the=20 change you propose.

 

The local = confidence=20 assesses reachability of the neighbor.

 

A neighbor might = be lost=20 if

-         =20 NUD declares it=20 unreachable

-         =20 The link goes = down

 

The retry_count = +=20 RemoveTimer test assesses reachability of the final destination, may = far=20 behind the neighbor

 

A final = destination might be=20 lost for a number of reasons if you look at it

-         =20 No DAO (null=20 lifetime)

-         =20 Prefix Lifetime=20 expires

-         =20 Retry count=20 expires

-         =20 Last neighbor via which we = have a route=20 to destination goes down

-         =20 Routing = shutdown

-         =20 =85

 

 Makes=20 sense?

 

Pascal

 

 

From: = Mathilde Durvy=20 (mdurvy)
Sent: vendredi 4 d=E9cembre 2009 = 14:59
To:=20 Pascal Thubert (pthubert)
Cc: = 'roll@ietf.org'
Subject:=20 RE: #16

 

Hi=20 Pascal,

 

Thanks=20 for the update. Please see my questions below.

Best,

Mathilde

 

 

Issue 16 says =93Hi All, This is my current = understanding:=20 - Parents are removed based on OF selection (decision to move within = the=20 DAG, change DAG, etc) - Destination prefixes are removed after the = retry /=20 RemoveTimer? procedure described in section 5.10.1.1.1. This is = essentially=20 a keep alive mechanism based on DIO (D bit set) - DAO exchanges. - = Route=20 corresponding to destination prefixes are removed when DAO lifetime = expires?=20 Are they also removed when the corresponding destination prefix is = removed?=20 - When are routes corresponding to parents removed? Do they also = have a=20 lifetime? - What happens when a neighbor disappears, are the = corresponding=20 parents/destination/routes removed? The current behavior seems quite = asymmetric... There is some kind of keep alive mechanism for = destination=20 prefixes, but not for parents. There is a lifetime associated with = routes=20 corresponding to destination prefixes but not for routes = corresponding to=20 parents. Is that a design choice? I would appreciate some = clarifications.=20 =94

 

Proposed new text :

 

   = If Neighbor=20 Unreachability Detection (NUD), or an = equivalent

   = mechanism,=20 determines that a neighbor is no longer reachable, then=20 a

   = RPL node=20 MUST NOT consider this node in the neighbor set = when

   = calculating=20 and advertising routes until the node determines it = is

   = reachable=20 again.  

 

   = Routes via=20 that neighbor MUST be eliminated from the routing=20 table,

   = and the=20 node SHOULD poison using no-DAO all DAO routes that = it

  =  has=20 advertised via DAO and that it can reach only via that=20 neighbor.

 

The internals (keeping info about the DAOs to = resync more=20 quickly) are not described, long as the node behaves as if it has = cleaned=20 everything reachable only via the lost neighbor.

>>=20 Does this mean that there is no lifetime associated with DAO=20 routes?

>>Is=20 the retry_count + RemoveTimer procedure maintained in version 05?=20

>>=20 Does this mean that the local confidence is the only criteria to = assess=20 neighbor (including parents and child) = reachability?

 

Best,

Mathilde

 

------_=_NextPart_001_01CA7756.8ABB6F1F-- From pthubert@cisco.com Mon Dec 7 08:15:23 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 204A428C18F for ; Mon, 7 Dec 2009 08:15:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.368 X-Spam-Level: X-Spam-Status: No, score=-5.368 tagged_above=-999 required=5 tests=[AWL=-2.770, 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 kgwLVTfw-dbV for ; Mon, 7 Dec 2009 08:15:13 -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 C5B5E28C194 for ; Mon, 7 Dec 2009 08:15:10 -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: AhgAAJa4HEuQ/uCWiWdsb2JhbACCHJlVAQEBCgsREwanPpYYhDMEgWc X-IronPort-AV: E=Sophos;i="4.47,356,1257120000"; d="scan'208,217";a="763637" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-2.cisco.com with ESMTP; 07 Dec 2009 15:48:50 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id nB7GExm9027447 for ; Mon, 7 Dec 2009 16:14:59 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, 7 Dec 2009 17:14:59 +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_01CA7758.6C5E3741" Date: Mon, 7 Dec 2009 17:14:55 +0100 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5DCB6BFC@XMB-AMS-107.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] #16 Thread-Index: Acp0ynJLQoXUd6iTTJCP8JXamj5kxwAHX6tgAACzPlAAAounsAABnBAwAJPwX/AAAnkvYAAAQ0DAAAB9uvA= References: <6A2A459175DABE4BB11DE2026AA50A5DCB61E4@XMB-AMS-107.cisco.com><8A977BDC5A7B0E429B0F521E8D6F91EEDF9592@XMB-AMS-103.cisco.com><6A2A459175DABE4BB11DE2026AA50A5DCB63D6@XMB-AMS-107.cisco.com><8A977BDC5A7B0E429B0F521E8D6F91EEE5ECD9@XMB-AMS-103.cisco.com> <6A2A459175DABE4BB11DE2026AA50A5DCB64BA@XMB-AMS-107.cisco.com> <6A2A459175DABE4BB11DE2026AA50A5DCB6BCE@XMB-AMS-107.cisco.com> From: "Pascal Thubert (pthubert)" To: "Julien Abeille (jabeille)" , "Mathilde Durvy (mdurvy)" X-OriginalArrivalTime: 07 Dec 2009 16:14:59.0412 (UTC) FILETIME=[6C782140:01CA7758] Cc: roll@ietf.org Subject: Re: [Roll] #16 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 07 Dec 2009 16:15:23 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA7758.6C5E3741 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Julien, Mathilde: =20 Would this change help? =20 time the packet is sent) that the Destination Prefix is = valid - for route determination. A value of all one bits = (0xFFFFFFFF) - represents infinity. A value of all zero bits = (0x00000000) - indicates a loss of reachability. + for route determination. + The lifetime is initially set by the node that owns the = prefix + and denotes the valid lifetime for that prefix (aka = AdvValidLifetime). + + The value might be reduced by the originator and/or = en-route nodes + that would not provide connectivity for the whole valid = lifetime. + =20 + A value of all one bits (0xFFFFFFFF) represents = infinity.=20 + A value of all zero bits (0x00000000) indicates a loss = of=20 + reachability. =20 And yes, that value caps the time a node should maintain a route learnt = from DAO though the default for AdvValidLifetime is a month... =20 Pascal From: Julien Abeille (jabeille)=20 Sent: lundi 7 d=E9cembre 2009 17:01 To: Pascal Thubert (pthubert); Mathilde Durvy (mdurvy) Cc: 'roll@ietf.org' Subject: RE: [Roll] #16 =20 Hi Pascal, =20 I get it, I think we just disagreed on terms. I'll still call it a route = lifetime ;-) (even though it is an admin concept, decoupling totally the = admin from the actual route does not help as the forwarding engine will = use the route even if it is supposedly just administratively up). =20 Best, Julien =20 =09 ________________________________ From: Pascal Thubert (pthubert)=20 Sent: lundi 7 d=E9cembre 2009 16:57 To: Julien Abeille (jabeille); Mathilde Durvy (mdurvy) Cc: 'roll@ietf.org' Subject: RE: [Roll] #16 Hi Julien: =20 There is no such thing as a lifetime of a route. The routing protocol = maintain the routes for as long as they can be they cannot predict how = long that will be. A prefix, a registration, a router and an address all have a lifetime = with IPv6 because administratively, there's some process to lock = resourced, and then renew or renumber. This is what the prefix lifetime in DAO is about. A capping of how long = things are administratively expected to be there. So that a peer does = not keep associated resources a lot longer than the parent resource it = depends on. =20 Cheers, =20 Pascal From: Julien Abeille (jabeille)=20 Sent: lundi 7 d=E9cembre 2009 15:42 To: Pascal Thubert (pthubert); Mathilde Durvy (mdurvy) Cc: roll@ietf.org Subject: RE: [Roll] #16 =20 Hi Pascal, =20 I agree with NUD or others being used for neighbor reachability = (different from e.g. parent reachability and applies to all RPL "peers") .=20 what is the difference between the lifetime of a prefix and the = lifetime of a route? we still have two mechanisms here to decide whether a route is still = valid (if i get it right): - DIO with D bit - lifetime why? Best, Julien =20 =20 =09 ________________________________ From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf = Of Pascal Thubert (pthubert) Sent: vendredi 4 d=E9cembre 2009 17:14 To: Mathilde Durvy (mdurvy) Cc: roll@ietf.org Subject: Re: [Roll] #16 Hi Mathilde: =20 =20 [Mathilde] So if I understand correctly the DAO lifetime is removed = for the DAO packet =20 The DAO lifetime is the lifetime of the prefix, not that of the route. = You can hardly say how long a route can be valid. After that lifetime expires, the prefix will not exist anymore so = obviously, if the lifetime was not refreshed, the route associated has = to be removed. =20 =20 =20 [Mathilde] I guess my point is that I see a small contradiction in = your answers to the 2 previous questions. If we useonly local confidence = to assess neighbor reachability why do we need an extra mechanism to = assess the reachability to the neighbors that are sending DAOs to us? In other word the retry_count + RemoveTimer test reachability to a = neighbor, the local confidence tests the reachability to the same = neighbor, why do weuse both? Is it that the local confidence is too 'slow' for DAO neighbors = (children) but good enough for DIO neighbors (parents)? =20 I would just like to understand the reasoning, otherwise I'm happy = with the change you propose. =20 The local confidence assesses reachability of the neighbor. =20 A neighbor might be lost if - NUD declares it unreachable - The link goes down =20 The retry_count + RemoveTimer test assesses reachability of the final = destination, may far behind the neighbor =20 A final destination might be lost for a number of reasons if you look = at it - No DAO (null lifetime) - Prefix Lifetime expires - Retry count expires - Last neighbor via which we have a route to destination goes = down - Routing shutdown - ... =20 Makes sense? =20 Pascal =20 =20 From: Mathilde Durvy (mdurvy)=20 Sent: vendredi 4 d=E9cembre 2009 14:59 To: Pascal Thubert (pthubert) Cc: 'roll@ietf.org' Subject: RE: #16 =20 Hi Pascal, =20 Thanks for the update. Please see my questions below. Best, Mathilde =20 =09 ________________________________ =20 Issue 16 says "Hi All, This is my current understanding: - Parents are = removed based on OF selection (decision to move within the DAG, change = DAG, etc) - Destination prefixes are removed after the retry / = RemoveTimer? procedure described in section 5.10.1.1.1. This is = essentially a keep alive mechanism based on DIO (D bit set) - DAO = exchanges. - Route corresponding to destination prefixes are removed = when DAO lifetime expires? Are they also removed when the corresponding = destination prefix is removed? - When are routes corresponding to = parents removed? Do they also have a lifetime? - What happens when a = neighbor disappears, are the corresponding parents/destination/routes = removed? The current behavior seems quite asymmetric... There is some = kind of keep alive mechanism for destination prefixes, but not for = parents. There is a lifetime associated with routes corresponding to = destination prefixes but not for routes corresponding to parents. Is = that a design choice? I would appreciate some clarifications. " =20 Proposed new text : =20 If Neighbor Unreachability Detection (NUD), or an equivalent mechanism, determines that a neighbor is no longer reachable, then = a RPL node MUST NOT consider this node in the neighbor set when calculating and advertising routes until the node determines it is reachable again. =20 =20 Routes via that neighbor MUST be eliminated from the routing table, and the node SHOULD poison using no-DAO all DAO routes that it has advertised via DAO and that it can reach only via that = neighbor. =20 The internals (keeping info about the DAOs to resync more quickly) are = not described, long as the node behaves as if it has cleaned everything = reachable only via the lost neighbor. >> Does this mean that there is no lifetime associated with DAO = routes? >>Is the retry_count + RemoveTimer procedure maintained in version 05? = >> Does this mean that the local confidence is the only criteria to = assess neighbor (including parents and child) reachability? =20 Best, Mathilde =20 ------_=_NextPart_001_01CA7758.6C5E3741 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Julien, = Mathilde:

 

Would this change = help?

 

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = time the packet is sent) that the Destination Prefix is valid

-=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = for route determination. A value of all one bits = (0xFFFFFFFF)

-=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = represents infinity. A value of all zero bits (0x00000000)

-=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = indicates a loss of reachability.

+=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = for route determination.

+=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =A0 The = lifetime is initially set by the node that owns the prefix

+=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =A0 and = denotes the valid lifetime for that prefix (aka = AdvValidLifetime).

+

+=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =A0 The = value might be reduced by the originator and/or en-route nodes

+=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =A0 that = would not provide connectivity for the whole valid lifetime.

+=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =

+=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =A0 A = value of all one bits (0xFFFFFFFF) represents infinity.

+=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =A0 A = value of all zero bits (0x00000000) indicates a loss of

+=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =A0 = reachability.

 

And yes, that value = caps the time a node should maintain a route learnt from DAO though the default = for AdvValidLifetime is a month…

 

Pascal

From:= Julien = Abeille (jabeille)
Sent: lundi 7 d=E9cembre 2009 17:01
To: Pascal Thubert (pthubert); Mathilde Durvy (mdurvy)
Cc: 'roll@ietf.org'
Subject: RE: [Roll] #16

 

Hi Pascal,

 

I get it, I think we just disagreed on terms. I'll still = call it a route lifetime ;-) (even though it is an admin concept, decoupling = totally the admin from the actual route does not help as the forwarding engine = will use the route even if it is supposedly just administratively = up).

 

Best,

Julien

 

From: Pascal Thubert (pthubert)
Sent: lundi 7 d=E9cembre 2009 16:57
To: Julien Abeille (jabeille); Mathilde Durvy (mdurvy)
Cc: 'roll@ietf.org'
Subject: RE: [Roll] #16

Hi = Julien:

 

There is no such = thing as a lifetime of a route. The routing protocol maintain the routes for as = long as they can be they cannot predict how long that will = be.

A prefix, a = registration, a router and an address all have a lifetime with IPv6 because = administratively, there’s some process to lock resourced, and then renew or = renumber.

This is what the = prefix lifetime in DAO is about. A capping of how long things are administratively = expected to be there. So that a peer does not keep associated resources a lot longer = than the parent resource it depends on.

 

Cheers,

 

Pascal

From:= Julien = Abeille (jabeille)
Sent: lundi 7 d=E9cembre 2009 15:42
To: Pascal Thubert (pthubert); Mathilde Durvy (mdurvy)
Cc: roll@ietf.org
Subject: RE: [Roll] #16

 

Hi Pascal,

 

I agree with NUD or others being used for neighbor = reachability (different from e.g. parent reachability and applies to all RPL "peers")

.

what is the difference between the lifetime of a prefix and = the lifetime of a route?

we still have two mechanisms here to decide whether a route = is still valid (if i get it right):

- DIO with D bit

- lifetime

why?

Best,

Julien

 

 

From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Pascal Thubert = (pthubert)
Sent: vendredi 4 d=E9cembre 2009 17:14
To: Mathilde Durvy (mdurvy)
Cc: roll@ietf.org
Subject: Re: [Roll] #16

Hi = Mathilde:

 

 

 [Mathilde] So if I understand correctly the DAO = lifetime is removed for the DAO packet

 

The DAO lifetime is = the lifetime of the prefix, not that of the route. You can hardly say = how long a route can be valid.

After that lifetime = expires, the prefix will not exist anymore so obviously, if the lifetime was not = refreshed,  the route associated has to be removed.

 

 

 

[Mathilde] I guess my point is that I see a small = contradiction in your answers to the 2 previous questions. If we useonly local confidence = to assess neighbor reachability why do we need an extra mechanism to assess = the reachability to the neighbors that are sending DAOs to us?

In other word the retry_count + RemoveTimer test = reachability to a neighbor, the local confidence tests the reachability to the same = neighbor, why do weuse both?

Is it that the local confidence is too 'slow' for DAO = neighbors (children) but good enough for DIO neighbors (parents)?

 

I would just like to understand the reasoning, otherwise I'm = happy with the change you propose.

 

The local confidence = assesses reachability of the neighbor.

 

A neighbor might be = lost if

-       &= nbsp;  NUD declares it = unreachable

-       &= nbsp;  The link goes = down

 

The retry_count + = RemoveTimer test assesses reachability of the final destination, may far behind the neighbor

 

A final destination = might be lost for a number of reasons if you look at it

-       &= nbsp;  No DAO (null = lifetime)

-       &= nbsp;  Prefix Lifetime = expires

-       &= nbsp;  Retry count = expires

-       &= nbsp;  Last neighbor via which we have a = route to destination goes down

-       &= nbsp;  Routing = shutdown

-       &= nbsp;  …

 

 Makes = sense?

 

Pascal

 

 

From:= Mathilde = Durvy (mdurvy)
Sent: vendredi 4 d=E9cembre 2009 14:59
To: Pascal Thubert (pthubert)
Cc: 'roll@ietf.org'
Subject: RE: #16

 

Hi Pascal,

 

Thanks for the update. Please see my questions = below.

Best,

Mathilde

 

 

Issue 16 says “Hi All, This is my current understanding: - Parents are removed based on OF selection (decision to = move within the DAG, change DAG, etc) - Destination prefixes are removed = after the retry / RemoveTimer? procedure described in section 5.10.1.1.1. This is essentially a keep alive mechanism based on DIO (D bit set) - DAO = exchanges. - Route corresponding to destination prefixes are removed when DAO = lifetime expires? Are they also removed when the corresponding destination prefix = is removed? - When are routes corresponding to parents removed? Do they = also have a lifetime? - What happens when a neighbor disappears, are the = corresponding parents/destination/routes removed? The current behavior seems quite = asymmetric... There is some kind of keep alive mechanism for destination prefixes, but = not for parents. There is a lifetime associated with routes corresponding to destination prefixes but not for routes corresponding to parents. Is = that a design choice? I would appreciate some clarifications. = ”

 

Proposed new text :

 

   If Neighbor Unreachability Detection (NUD), or an = equivalent

   mechanism, determines that a neighbor is no longer reachable, then = a

   RPL node MUST NOT consider this node in the neighbor set = when

   calculating and advertising routes until the node determines it = is

   reachable again.  

 

   Routes via that neighbor MUST be eliminated from the routing = table,

   and the node SHOULD poison using no-DAO all DAO routes that = it

   has advertised via DAO and that it can reach only via that = neighbor.

 

The internals (keeping info about the DAOs to = resync more quickly) are not described, long as the node behaves as if it has = cleaned everything reachable only via the lost neighbor.

>> Does this mean that there is no lifetime associated = with DAO routes?

>>Is the retry_count + RemoveTimer procedure = maintained in version 05?

>> Does this mean that the local confidence is the = only criteria to assess neighbor (including parents and child) = reachability?

 

Best,

Mathilde

 

------_=_NextPart_001_01CA7758.6C5E3741-- From jabeille@cisco.com Mon Dec 7 08:17:44 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1106C28C1B2 for ; Mon, 7 Dec 2009 08:17:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.17 X-Spam-Level: X-Spam-Status: No, score=-5.17 tagged_above=-999 required=5 tests=[AWL=-2.572, 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 Y4O-ocZToL1d for ; Mon, 7 Dec 2009 08:17:42 -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 A98FB28C1AA for ; Mon, 7 Dec 2009 08:17:40 -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: AhgAAMK5HEuQ/uCWiWdsb2JhbACCHJlVAQEBCgsREwanPZYahDMEgWc X-IronPort-AV: E=Sophos;i="4.47,356,1257120000"; d="scan'208,217";a="763883" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-2.cisco.com with ESMTP; 07 Dec 2009 15:50: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 nB7GH7mR028207 for ; Mon, 7 Dec 2009 16:17:07 GMT Received: from xmb-ams-113.cisco.com ([144.254.74.88]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 7 Dec 2009 17:17:07 +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_01CA7758.B8C19BBE" Date: Mon, 7 Dec 2009 17:17:02 +0100 Message-ID: In-Reply-To: <6A2A459175DABE4BB11DE2026AA50A5DCB6BFC@XMB-AMS-107.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] #16 Thread-Index: Acp0ynJLQoXUd6iTTJCP8JXamj5kxwAHX6tgAACzPlAAAounsAABnBAwAJPwX/AAAnkvYAAAQ0DAAAB9uvAAACZmIA== References: <6A2A459175DABE4BB11DE2026AA50A5DCB61E4@XMB-AMS-107.cisco.com><8A977BDC5A7B0E429B0F521E8D6F91EEDF9592@XMB-AMS-103.cisco.com><6A2A459175DABE4BB11DE2026AA50A5DCB63D6@XMB-AMS-107.cisco.com><8A977BDC5A7B0E429B0F521E8D6F91EEE5ECD9@XMB-AMS-103.cisco.com> <6A2A459175DABE4BB11DE2026AA50A5DCB64BA@XMB-AMS-107.cisco.com> <6A2A459175DABE4BB11DE2026AA50A5DCB6BCE@XMB-AMS-107.cisco.com> <6A2A459175DABE4BB11DE2026AA50A5DCB6BFC@XMB-AMS-107.cisco.com> From: "Julien Abeille (jabeille)" To: "Pascal Thubert (pthubert)" , "Mathilde Durvy (mdurvy)" X-OriginalArrivalTime: 07 Dec 2009 16:17:07.0474 (UTC) FILETIME=[B8CCD720:01CA7758] Cc: roll@ietf.org Subject: Re: [Roll] #16 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 07 Dec 2009 16:17:44 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA7758.B8C19BBE Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Pascal, =20 this works for me. Julien ________________________________ From: Pascal Thubert (pthubert)=20 Sent: lundi 7 d=E9cembre 2009 17:15 To: Julien Abeille (jabeille); Mathilde Durvy (mdurvy) Cc: 'roll@ietf.org' Subject: RE: [Roll] #16 =09 =09 Julien, Mathilde: =20 Would this change help? =20 time the packet is sent) that the Destination Prefix = is valid - for route determination. A value of all one bits = (0xFFFFFFFF) - represents infinity. A value of all zero bits = (0x00000000) - indicates a loss of reachability. + for route determination. + The lifetime is initially set by the node that owns the = prefix + and denotes the valid lifetime for that prefix (aka = AdvValidLifetime). + + The value might be reduced by the originator and/or = en-route nodes + that would not provide connectivity for the whole valid = lifetime. + =20 + A value of all one bits (0xFFFFFFFF) represents = infinity.=20 + A value of all zero bits (0x00000000) indicates a loss = of=20 + reachability. =20 And yes, that value caps the time a node should maintain a route learnt = from DAO though the default for AdvValidLifetime is a month... =20 Pascal From: Julien Abeille (jabeille)=20 Sent: lundi 7 d=E9cembre 2009 17:01 To: Pascal Thubert (pthubert); Mathilde Durvy (mdurvy) Cc: 'roll@ietf.org' Subject: RE: [Roll] #16 =20 Hi Pascal, =20 I get it, I think we just disagreed on terms. I'll still call it a = route lifetime ;-) (even though it is an admin concept, decoupling = totally the admin from the actual route does not help as the forwarding = engine will use the route even if it is supposedly just administratively = up). =20 Best, Julien =20 =09 ________________________________ From: Pascal Thubert (pthubert)=20 Sent: lundi 7 d=E9cembre 2009 16:57 To: Julien Abeille (jabeille); Mathilde Durvy (mdurvy) Cc: 'roll@ietf.org' Subject: RE: [Roll] #16 Hi Julien: =20 There is no such thing as a lifetime of a route. The routing protocol = maintain the routes for as long as they can be they cannot predict how = long that will be. A prefix, a registration, a router and an address all have a lifetime = with IPv6 because administratively, there's some process to lock = resourced, and then renew or renumber. This is what the prefix lifetime in DAO is about. A capping of how = long things are administratively expected to be there. So that a peer = does not keep associated resources a lot longer than the parent resource = it depends on. =20 Cheers, =20 Pascal From: Julien Abeille (jabeille)=20 Sent: lundi 7 d=E9cembre 2009 15:42 To: Pascal Thubert (pthubert); Mathilde Durvy (mdurvy) Cc: roll@ietf.org Subject: RE: [Roll] #16 =20 Hi Pascal, =20 I agree with NUD or others being used for neighbor reachability = (different from e.g. parent reachability and applies to all RPL "peers") .=20 what is the difference between the lifetime of a prefix and the = lifetime of a route? we still have two mechanisms here to decide whether a route is still = valid (if i get it right): - DIO with D bit - lifetime why? Best, Julien =20 =20 =09 ________________________________ From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf = Of Pascal Thubert (pthubert) Sent: vendredi 4 d=E9cembre 2009 17:14 To: Mathilde Durvy (mdurvy) Cc: roll@ietf.org Subject: Re: [Roll] #16 Hi Mathilde: =20 =20 [Mathilde] So if I understand correctly the DAO lifetime is removed = for the DAO packet =20 The DAO lifetime is the lifetime of the prefix, not that of the = route. You can hardly say how long a route can be valid. After that lifetime expires, the prefix will not exist anymore so = obviously, if the lifetime was not refreshed, the route associated has = to be removed. =20 =20 =20 [Mathilde] I guess my point is that I see a small contradiction in = your answers to the 2 previous questions. If we useonly local confidence = to assess neighbor reachability why do we need an extra mechanism to = assess the reachability to the neighbors that are sending DAOs to us? In other word the retry_count + RemoveTimer test reachability to a = neighbor, the local confidence tests the reachability to the same = neighbor, why do weuse both? Is it that the local confidence is too 'slow' for DAO neighbors = (children) but good enough for DIO neighbors (parents)? =20 I would just like to understand the reasoning, otherwise I'm happy = with the change you propose. =20 The local confidence assesses reachability of the neighbor. =20 A neighbor might be lost if - NUD declares it unreachable - The link goes down =20 The retry_count + RemoveTimer test assesses reachability of the final = destination, may far behind the neighbor =20 A final destination might be lost for a number of reasons if you look = at it - No DAO (null lifetime) - Prefix Lifetime expires - Retry count expires - Last neighbor via which we have a route to destination = goes down - Routing shutdown - ... =20 Makes sense? =20 Pascal =20 =20 From: Mathilde Durvy (mdurvy)=20 Sent: vendredi 4 d=E9cembre 2009 14:59 To: Pascal Thubert (pthubert) Cc: 'roll@ietf.org' Subject: RE: #16 =20 Hi Pascal, =20 Thanks for the update. Please see my questions below. Best, Mathilde =20 =09 ________________________________ =20 Issue 16 says "Hi All, This is my current understanding: - Parents = are removed based on OF selection (decision to move within the DAG, = change DAG, etc) - Destination prefixes are removed after the retry / = RemoveTimer? procedure described in section 5.10.1.1.1. This is = essentially a keep alive mechanism based on DIO (D bit set) - DAO = exchanges. - Route corresponding to destination prefixes are removed = when DAO lifetime expires? Are they also removed when the corresponding = destination prefix is removed? - When are routes corresponding to = parents removed? Do they also have a lifetime? - What happens when a = neighbor disappears, are the corresponding parents/destination/routes = removed? The current behavior seems quite asymmetric... There is some = kind of keep alive mechanism for destination prefixes, but not for = parents. There is a lifetime associated with routes corresponding to = destination prefixes but not for routes corresponding to parents. Is = that a design choice? I would appreciate some clarifications. " =20 Proposed new text : =20 If Neighbor Unreachability Detection (NUD), or an equivalent mechanism, determines that a neighbor is no longer reachable, then = a RPL node MUST NOT consider this node in the neighbor set when calculating and advertising routes until the node determines it is reachable again. =20 =20 Routes via that neighbor MUST be eliminated from the routing = table, and the node SHOULD poison using no-DAO all DAO routes that it has advertised via DAO and that it can reach only via that = neighbor. =20 The internals (keeping info about the DAOs to resync more quickly) = are not described, long as the node behaves as if it has cleaned = everything reachable only via the lost neighbor. >> Does this mean that there is no lifetime associated with DAO = routes? >>Is the retry_count + RemoveTimer procedure maintained in version = 05?=20 >> Does this mean that the local confidence is the only criteria to = assess neighbor (including parents and child) reachability? =20 Best, Mathilde =20 ------_=_NextPart_001_01CA7758.B8C19BBE Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi Pascal,
 
this works for me.
Julien

From: Pascal Thubert (pthubert)=20
Sent: lundi 7 d=E9cembre 2009 17:15
To: Julien = Abeille=20 (jabeille); Mathilde Durvy (mdurvy)
Cc:=20 'roll@ietf.org'
Subject: RE: [Roll] #16

Julien,=20 Mathilde:

 

Would this change=20 help?

 

          &nbs= p;     =20 time the packet is sent) that the Destination Prefix is=20 valid

-          &nb= sp;    =20 for route determination. A value of all one bits=20 (0xFFFFFFFF)

-          &nb= sp;    =20 represents infinity. A value of all zero bits=20 (0x00000000)

-          &nb= sp;    =20 indicates a loss of reachability.

+          &nb= sp;    =20 for route determination.

+          &nb= sp; =20   The lifetime is initially set by the node that owns the=20 prefix

+          &nb= sp; =20   and denotes the valid lifetime for that prefix (aka=20 AdvValidLifetime).

+

+          &nb= sp; =20   The value might be reduced by the originator and/or en-route=20 nodes

+          &nb= sp; =20   that would not provide connectivity for the whole valid=20 lifetime.

+          &nb= sp;           &nbs= p;            = ;            =             &= nbsp;=20

+          &nb= sp; =20   A value of all one bits (0xFFFFFFFF) represents infinity.=20

+          &nb= sp; =20   A value of all zero bits (0x00000000) indicates a loss of=20

+          &nb= sp; =20   reachability.

 

And yes, that = value caps the=20 time a node should maintain a route learnt from DAO though the default = for=20 AdvValidLifetime is a month=85

 

Pascal

From: Julien = Abeille=20 (jabeille)
Sent: lundi 7 d=E9cembre 2009 = 17:01
To: Pascal=20 Thubert (pthubert); Mathilde Durvy (mdurvy)
Cc:=20 'roll@ietf.org'
Subject: RE: [Roll]=20 #16

 

Hi=20 Pascal,

 

I get=20 it, I think we just disagreed on terms. I'll still call it a route = lifetime=20 ;-) (even though it is an admin concept, decoupling totally the = admin=20 from the actual route does not help as the forwarding engine will use = the=20 route even if it is supposedly just administratively up).

 

Best,

Julien

 

From: = Pascal Thubert=20 (pthubert)
Sent: lundi 7 d=E9cembre 2009 = 16:57
To: Julien=20 Abeille (jabeille); Mathilde Durvy (mdurvy)
Cc:=20 'roll@ietf.org'
Subject: RE: [Roll] #16

Hi=20 Julien:

 

There is no such = thing as a=20 lifetime of a route. The routing protocol maintain the routes for as = long as=20 they can be they cannot predict how long that will = be.

A prefix, a = registration, a=20 router and an address all have a lifetime with IPv6 because=20 administratively, there=92s some process to lock resourced, and then = renew or=20 renumber.

This is what the = prefix=20 lifetime in DAO is about. A capping of how long things are = administratively=20 expected to be there. So that a peer does not keep associated = resources a=20 lot longer than the parent resource it depends = on.

 

Cheers,

 

Pascal

From: = Julien Abeille=20 (jabeille)
Sent: lundi 7 d=E9cembre 2009 = 15:42
To: Pascal=20 Thubert (pthubert); Mathilde Durvy (mdurvy)
Cc:=20 roll@ietf.org
Subject: RE: [Roll]=20 #16

 

Hi=20 Pascal,

 

I=20 agree with NUD or others being used for neighbor reachability = (different=20 from e.g. parent reachability and applies to all RPL = "peers")

.=20

what=20 is the difference between the lifetime of a prefix and the lifetime = of a=20 route?

we=20 still have two mechanisms here to decide whether a route is still = valid (if=20 i get it right):

-=20 DIO with D bit

-=20 lifetime

why?

Best,

Julien

 

 

From:=20 roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf = Of=20 Pascal Thubert (pthubert)
Sent: vendredi 4 = d=E9cembre 2009=20 17:14
To: Mathilde Durvy (mdurvy)
Cc:=20 roll@ietf.org
Subject: Re: [Roll] #16

Hi=20 Mathilde:

 

 

 [Mathilde]=20 So if I understand correctly the DAO lifetime is removed for the = DAO=20 packet

 

The DAO = lifetime is the=20 lifetime of the prefix, not that of the route. You = can=20 hardly say how long a route can be valid.

After that = lifetime=20 expires, the prefix will not exist anymore so obviously, if the = lifetime=20 was not refreshed,  the route associated has to be=20 removed.

 

 

 

[Mathilde]=20 I guess my point is that I see a small contradiction in your = answers to=20 the 2 previous questions. If we useonly local confidence to assess = neighbor reachability why do we need an extra mechanism to assess = the=20 reachability to the neighbors that are sending DAOs to = us?

In=20 other word the retry_count + RemoveTimer test reachability to a = neighbor,=20 the local confidence tests the reachability to the same neighbor, = why do=20 weuse both?

Is=20 it that the local confidence is too 'slow' for DAO neighbors = (children)=20 but good enough for DIO neighbors (parents)?

 

I=20 would just like to understand the reasoning, otherwise I'm happy = with the=20 change you propose.

 

The local = confidence=20 assesses reachability of the neighbor.

 

A neighbor = might be lost=20 if

-         =20 NUD declares it=20 unreachable

-         =20 The link goes=20 down

 

The = retry_count +=20 RemoveTimer test assesses reachability of the final destination, = may far=20 behind the neighbor

 

A final = destination might=20 be lost for a number of reasons if you look at = it

-         =20 No DAO (null=20 lifetime)

-         =20 Prefix Lifetime=20 expires

-         =20 Retry count=20 expires

-         =20 Last neighbor via which we = have a=20 route to destination goes down

-         =20 Routing = shutdown

-         =20 =85

 

 Makes=20 sense?

 

Pascal

 

 

From: = Mathilde=20 Durvy (mdurvy)
Sent: vendredi 4 d=E9cembre 2009=20 14:59
To: Pascal Thubert (pthubert)
Cc:=20 'roll@ietf.org'
Subject: RE:=20 #16

 

Hi=20 Pascal,

 

Thanks=20 for the update. Please see my questions below.

Best,

Mathilde

 

 

Issue 16 says =93Hi All, This is my current=20 understanding: - Parents are removed based on OF selection = (decision to=20 move within the DAG, change DAG, etc) - Destination prefixes are = removed=20 after the retry / RemoveTimer? procedure described in section = 5.10.1.1.1.=20 This is essentially a keep alive mechanism based on DIO (D bit = set) - DAO=20 exchanges. - Route corresponding to destination prefixes are = removed when=20 DAO lifetime expires? Are they also removed when the corresponding = destination prefix is removed? - When are routes corresponding to = parents=20 removed? Do they also have a lifetime? - What happens when a = neighbor=20 disappears, are the corresponding parents/destination/routes = removed? The=20 current behavior seems quite asymmetric... There is some kind of = keep=20 alive mechanism for destination prefixes, but not for parents. = There is a=20 lifetime associated with routes corresponding to destination = prefixes but=20 not for routes corresponding to parents. Is that a design choice? = I would=20 appreciate some clarifications. =94

 

Proposed new text :

 

   = If=20 Neighbor Unreachability Detection (NUD), or an=20 equivalent

   = mechanism, determines that a neighbor is no longer reachable, then = a

   = RPL node=20 MUST NOT consider this node in the neighbor set = when

   = calculating and advertising routes until the node determines it=20 is

   = reachable=20 again.  

 

   = Routes=20 via that neighbor MUST be eliminated from the routing=20 table,

   = and the=20 node SHOULD poison using no-DAO all DAO routes that=20 it

  =  has=20 advertised via DAO and that it can reach only via that=20 neighbor.

 

The internals (keeping info about the DAOs to = resync=20 more quickly) are not described, long as the node behaves as if it = has=20 cleaned everything reachable only via the lost = neighbor.

>>=20 Does this mean that there is no lifetime associated with DAO=20 routes?

>>Is=20 the retry_count + RemoveTimer procedure maintained in version 05?=20

>>=20 Does this mean that the local confidence is the only criteria to = assess=20 neighbor (including parents and child) = reachability?

 

Best,

Mathilde

 

------_=_NextPart_001_01CA7758.B8C19BBE-- From mdurvy@cisco.com Mon Dec 7 08:22:16 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8159D3A68CC for ; Mon, 7 Dec 2009 08:22:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.242 X-Spam-Level: X-Spam-Status: No, score=-6.242 tagged_above=-999 required=5 tests=[AWL=0.356, 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 svIkiGUbdsDe for ; Mon, 7 Dec 2009 08:22:14 -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 9F63E3A68C2 for ; Mon, 7 Dec 2009 08:22:13 -0800 (PST) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-Files: smime.p7s : 4235 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AsoEAL+6HEtAZnwM/2dsb2JhbACCHMFXlhmEMwSBZw X-IronPort-AV: E=Sophos;i="4.47,356,1257120000"; d="p7s'?scan'208,217";a="72589595" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 07 Dec 2009 16:22:02 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id nB7GM1KG019506 for ; Mon, 7 Dec 2009 16:22:02 GMT Received: from xmb-ams-103.cisco.com ([144.254.74.78]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 7 Dec 2009 17:22:01 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 7 Dec 2009 17:22:00 +0100 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0046_01CA7761.C9497CD0" Message-ID: <8A977BDC5A7B0E429B0F521E8D6F91EEE5F483@XMB-AMS-103.cisco.com> In-Reply-To: <6A2A459175DABE4BB11DE2026AA50A5DCB6BFC@XMB-AMS-107.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] #16 Thread-Index: Acp0ynJLQoXUd6iTTJCP8JXamj5kxwAHX6tgAACzPlAAAounsAABnBAwAJPwX/AAAnkvYAAAQ0DAAAB9uvAAAFW6oA== References: <6A2A459175DABE4BB11DE2026AA50A5DCB61E4@XMB-AMS-107.cisco.com><8A977BDC5A7B0E429B0F521E8D6F91EEDF9592@XMB-AMS-103.cisco.com><6A2A459175DABE4BB11DE2026AA50A5DCB63D6@XMB-AMS-107.cisco.com><8A977BDC5A7B0E429B0F521E8D6F91EEE5ECD9@XMB-AMS-103.cisco.com> <6A2A459175DABE4BB11DE2026AA50A5DCB64BA@XMB-AMS-107.cisco.com> <6A2A459175DABE4BB11DE2026AA50A5DCB6BCE@XMB-AMS-107.cisco.com> <6A2A459175DABE4BB11DE2026AA50A5DCB6BFC@XMB-AMS-107.cisco.com> From: "Mathilde Durvy (mdurvy)" To: "Pascal Thubert (pthubert)" , "Julien Abeille (jabeille)" X-OriginalArrivalTime: 07 Dec 2009 16:22:01.0630 (UTC) FILETIME=[68217BE0:01CA7759] Cc: roll@ietf.org Subject: Re: [Roll] #16 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 07 Dec 2009 16:22:16 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0046_01CA7761.C9497CD0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0047_01CA7761.C9497CD0" ------=_NextPart_001_0047_01CA7761.C9497CD0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable OK for me too! Best, Mathilde _____ =20 From: Pascal Thubert (pthubert)=20 Sent: lundi, 7. d=E9cembre 2009 17:15 To: Julien Abeille (jabeille); Mathilde Durvy (mdurvy) Cc: 'roll@ietf.org' Subject: RE: [Roll] #16 Julien, Mathilde: =20 Would this change help? =20 time the packet is sent) that the Destination Prefix is valid - for route determination. A value of all one bits (0xFFFFFFFF) - represents infinity. A value of all zero bits = (0x00000000) - indicates a loss of reachability. + for route determination. + The lifetime is initially set by the node that owns the prefix + and denotes the valid lifetime for that prefix (aka AdvValidLifetime). + + The value might be reduced by the originator and/or = en-route nodes + that would not provide connectivity for the whole valid lifetime. + =20 + A value of all one bits (0xFFFFFFFF) represents = infinity.=20 + A value of all zero bits (0x00000000) indicates a loss = of=20 + reachability. =20 And yes, that value caps the time a node should maintain a route learnt = from DAO though the default for AdvValidLifetime is a month=85 =20 Pascal From: Julien Abeille (jabeille)=20 Sent: lundi 7 d=E9cembre 2009 17:01 To: Pascal Thubert (pthubert); Mathilde Durvy (mdurvy) Cc: 'roll@ietf.org' Subject: RE: [Roll] #16 =20 Hi Pascal, =20 I get it, I think we just disagreed on terms. I'll still call it a route lifetime ;-) (even though it is an admin concept, decoupling totally the admin from the actual route does not help as the forwarding engine will = use the route even if it is supposedly just administratively up). =20 Best, Julien =20 _____ =20 From: Pascal Thubert (pthubert)=20 Sent: lundi 7 d=E9cembre 2009 16:57 To: Julien Abeille (jabeille); Mathilde Durvy (mdurvy) Cc: 'roll@ietf.org' Subject: RE: [Roll] #16 Hi Julien: =20 There is no such thing as a lifetime of a route. The routing protocol maintain the routes for as long as they can be they cannot predict how = long that will be. A prefix, a registration, a router and an address all have a lifetime = with IPv6 because administratively, there=92s some process to lock resourced, = and then renew or renumber. This is what the prefix lifetime in DAO is about. A capping of how long things are administratively expected to be there. So that a peer does = not keep associated resources a lot longer than the parent resource it = depends on. =20 Cheers, =20 Pascal From: Julien Abeille (jabeille)=20 Sent: lundi 7 d=E9cembre 2009 15:42 To: Pascal Thubert (pthubert); Mathilde Durvy (mdurvy) Cc: roll@ietf.org Subject: RE: [Roll] #16 =20 Hi Pascal, =20 I agree with NUD or others being used for neighbor reachability = (different from e.g. parent reachability and applies to all RPL "peers") .=20 what is the difference between the lifetime of a prefix and the lifetime = of a route? we still have two mechanisms here to decide whether a route is still = valid (if i get it right): - DIO with D bit - lifetime why? Best, Julien =20 =20 _____ =20 From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Pascal Thubert (pthubert) Sent: vendredi 4 d=E9cembre 2009 17:14 To: Mathilde Durvy (mdurvy) Cc: roll@ietf.org Subject: Re: [Roll] #16 Hi Mathilde: =20 =20 [Mathilde] So if I understand correctly the DAO lifetime is removed for = the DAO packet =20 The DAO lifetime is the lifetime of the prefix, not that of the route. = You can hardly say how long a route can be valid. After that lifetime expires, the prefix will not exist anymore so = obviously, if the lifetime was not refreshed, the route associated has to be = removed. =20 =20 =20 [Mathilde] I guess my point is that I see a small contradiction in your answers to the 2 previous questions. If we useonly local confidence to assess neighbor reachability why do we need an extra mechanism to assess = the reachability to the neighbors that are sending DAOs to us? In other word the retry_count + RemoveTimer test reachability to a = neighbor, the local confidence tests the reachability to the same neighbor, why do weuse both? Is it that the local confidence is too 'slow' for DAO neighbors = (children) but good enough for DIO neighbors (parents)? =20 I would just like to understand the reasoning, otherwise I'm happy with = the change you propose. =20 The local confidence assesses reachability of the neighbor. =20 A neighbor might be lost if - NUD declares it unreachable - The link goes down =20 The retry_count + RemoveTimer test assesses reachability of the final destination, may far behind the neighbor =20 A final destination might be lost for a number of reasons if you look at = it - No DAO (null lifetime) - Prefix Lifetime expires - Retry count expires - Last neighbor via which we have a route to destination goes = down - Routing shutdown - =85 =20 Makes sense? =20 Pascal =20 =20 From: Mathilde Durvy (mdurvy)=20 Sent: vendredi 4 d=E9cembre 2009 14:59 To: Pascal Thubert (pthubert) Cc: 'roll@ietf.org' Subject: RE: #16 =20 Hi Pascal, =20 Thanks for the update. Please see my questions below. Best, Mathilde =20 _____ =20 =20 Issue 16 says =93Hi All, This is my current understanding: - Parents are removed based on OF selection (decision to move within the DAG, change = DAG, etc) - Destination prefixes are removed after the retry / RemoveTimer? procedure described in section 5.10.1.1.1. This is essentially a keep = alive mechanism based on DIO (D bit set) - DAO exchanges. - Route = corresponding to destination prefixes are removed when DAO lifetime expires? Are they = also removed when the corresponding destination prefix is removed? - When are routes corresponding to parents removed? Do they also have a lifetime? - What happens when a neighbor disappears, are the corresponding parents/destination/routes removed? The current behavior seems quite asymmetric... There is some kind of keep alive mechanism for destination prefixes, but not for parents. There is a lifetime associated with = routes corresponding to destination prefixes but not for routes corresponding = to parents. Is that a design choice? I would appreciate some = clarifications. =94 =20 Proposed new text : =20 If Neighbor Unreachability Detection (NUD), or an equivalent mechanism, determines that a neighbor is no longer reachable, then a RPL node MUST NOT consider this node in the neighbor set when calculating and advertising routes until the node determines it is reachable again. =20 =20 Routes via that neighbor MUST be eliminated from the routing table, and the node SHOULD poison using no-DAO all DAO routes that it has advertised via DAO and that it can reach only via that neighbor. =20 The internals (keeping info about the DAOs to resync more quickly) are = not described, long as the node behaves as if it has cleaned everything reachable only via the lost neighbor. >> Does this mean that there is no lifetime associated with DAO routes? >>Is the retry_count + RemoveTimer procedure maintained in version 05?=20 >> Does this mean that the local confidence is the only criteria to = assess neighbor (including parents and child) reachability? =20 Best, Mathilde =20 ------=_NextPart_001_0047_01CA7761.C9497CD0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
OK for me too!
Best,
Mathilde

From: Pascal Thubert (pthubert) =
Sent:=20 lundi, 7. d=E9cembre 2009 17:15
To: Julien Abeille (jabeille); = Mathilde=20 Durvy (mdurvy)
Cc: 'roll@ietf.org'
Subject: RE: = [Roll]=20 #16

Julien,=20 Mathilde:

 

Would this change=20 help?

 

          &nbs= p;     =20 time the packet is sent) that the Destination Prefix is=20 valid

-          &nb= sp;    =20 for route determination. A value of all one bits=20 (0xFFFFFFFF)

-          &nb= sp;    =20 represents infinity. A value of all zero bits = (0x00000000)

-          &nb= sp;    =20 indicates a loss of reachability.

+          &nb= sp;    =20 for route determination.

+          &nb= sp; =20   The lifetime is initially set by the node that owns the=20 prefix

+          &nb= sp; =20   and denotes the valid lifetime for that prefix (aka=20 AdvValidLifetime).

+

+          &nb= sp; =20   The value might be reduced by the originator and/or en-route=20 nodes

+          &nb= sp; =20   that would not provide connectivity for the whole valid=20 lifetime.

+          &nb= sp;           &nbs= p;            = ;            =             &= nbsp;=20

+          &nb= sp; =20   A value of all one bits (0xFFFFFFFF) represents infinity.=20

+          &nb= sp; =20   A value of all zero bits (0x00000000) indicates a loss of=20

+          &nb= sp; =20   reachability.

 

And yes, that value = caps the=20 time a node should maintain a route learnt from DAO though the default = for=20 AdvValidLifetime is a month=85

 

Pascal

From: Julien = Abeille=20 (jabeille)
Sent: lundi 7 d=E9cembre 2009 17:01
To: = Pascal=20 Thubert (pthubert); Mathilde Durvy (mdurvy)
Cc:=20 'roll@ietf.org'
Subject: RE: [Roll]=20 #16

 

Hi=20 Pascal,

 

I get=20 it, I think we just disagreed on terms. I'll still call it a route = lifetime=20 ;-) (even though it is an admin concept, decoupling totally the = admin from=20 the actual route does not help as the forwarding engine will use the = route even=20 if it is supposedly just administratively up).

 

Best,

Julien

 

From: Pascal = Thubert=20 (pthubert)
Sent: lundi 7 d=E9cembre 2009 = 16:57
To: Julien=20 Abeille (jabeille); Mathilde Durvy (mdurvy)
Cc:=20 'roll@ietf.org'
Subject: RE: [Roll] #16

Hi=20 Julien:

 

There is no such = thing as a=20 lifetime of a route. The routing protocol maintain the routes for as = long as=20 they can be they cannot predict how long that will = be.

A prefix, a = registration, a=20 router and an address all have a lifetime with IPv6 because = administratively,=20 there=92s some process to lock resourced, and then renew or=20 renumber.

This is what the = prefix=20 lifetime in DAO is about. A capping of how long things are = administratively=20 expected to be there. So that a peer does not keep associated = resources a lot=20 longer than the parent resource it depends on.

 

Cheers,

 

Pascal

From: Julien = Abeille=20 (jabeille)
Sent: lundi 7 d=E9cembre 2009 = 15:42
To: Pascal=20 Thubert (pthubert); Mathilde Durvy (mdurvy)
Cc:=20 roll@ietf.org
Subject: RE: [Roll]=20 #16

 

Hi=20 Pascal,

 

I=20 agree with NUD or others being used for neighbor reachability = (different from=20 e.g. parent reachability and applies to all RPL "peers")

.=20

what=20 is the difference between the lifetime of a prefix and the lifetime of = a=20 route?

we=20 still have two mechanisms here to decide whether a route is still = valid (if i=20 get it right):

- DIO=20 with D bit

-=20 lifetime

why?

Best,

Julien

 

 

From:=20 roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of = Pascal Thubert (pthubert)
Sent: vendredi 4 d=E9cembre = 2009=20 17:14
To: Mathilde Durvy (mdurvy)
Cc:=20 roll@ietf.org
Subject: Re: [Roll] #16

Hi=20 Mathilde:

 

 

 [Mathilde]=20 So if I understand correctly the DAO lifetime is removed for the DAO = packet

 

The DAO lifetime = is the=20 lifetime of the prefix, not that of the route. You can = hardly=20 say how long a route can be valid.

After that = lifetime expires,=20 the prefix will not exist anymore so obviously, if the lifetime was = not=20 refreshed,  the route associated has to be=20 removed.

 

 

 

[Mathilde]=20 I guess my point is that I see a small contradiction in your answers = to the=20 2 previous questions. If we useonly local confidence to assess = neighbor=20 reachability why do we need an extra mechanism to assess the = reachability to=20 the neighbors that are sending DAOs to us?

In=20 other word the retry_count + RemoveTimer test reachability to a = neighbor,=20 the local confidence tests the reachability to the same neighbor, = why do=20 weuse both?

Is=20 it that the local confidence is too 'slow' for DAO neighbors = (children) but=20 good enough for DIO neighbors (parents)?

 

I=20 would just like to understand the reasoning, otherwise I'm happy = with the=20 change you propose.

 

The local = confidence=20 assesses reachability of the neighbor.

 

A neighbor might = be lost=20 if

-         =20 NUD declares it=20 unreachable

-         =20 The link goes = down

 

The retry_count = +=20 RemoveTimer test assesses reachability of the final destination, may = far=20 behind the neighbor

 

A final = destination might be=20 lost for a number of reasons if you look at it

-         =20 No DAO (null=20 lifetime)

-         =20 Prefix Lifetime=20 expires

-         =20 Retry count=20 expires

-         =20 Last neighbor via which we = have a route=20 to destination goes down

-         =20 Routing = shutdown

-         =20 =85

 

 Makes=20 sense?

 

Pascal

 

 

From: = Mathilde Durvy=20 (mdurvy)
Sent: vendredi 4 d=E9cembre 2009 = 14:59
To:=20 Pascal Thubert (pthubert)
Cc: = 'roll@ietf.org'
Subject:=20 RE: #16

 

Hi=20 Pascal,

 

Thanks=20 for the update. Please see my questions below.

Best,

Mathilde

 

 

Issue 16 says =93Hi All, This is my current = understanding:=20 - Parents are removed based on OF selection (decision to move within = the=20 DAG, change DAG, etc) - Destination prefixes are removed after the = retry /=20 RemoveTimer? procedure described in section 5.10.1.1.1. This is = essentially=20 a keep alive mechanism based on DIO (D bit set) - DAO exchanges. - = Route=20 corresponding to destination prefixes are removed when DAO lifetime = expires?=20 Are they also removed when the corresponding destination prefix is = removed?=20 - When are routes corresponding to parents removed? Do they also = have a=20 lifetime? - What happens when a neighbor disappears, are the = corresponding=20 parents/destination/routes removed? The current behavior seems quite = asymmetric... There is some kind of keep alive mechanism for = destination=20 prefixes, but not for parents. There is a lifetime associated with = routes=20 corresponding to destination prefixes but not for routes = corresponding to=20 parents. Is that a design choice? I would appreciate some = clarifications.=20 =94

 

Proposed new text :

 

   = If Neighbor=20 Unreachability Detection (NUD), or an = equivalent

   = mechanism,=20 determines that a neighbor is no longer reachable, then=20 a

   = RPL node=20 MUST NOT consider this node in the neighbor set = when

   = calculating=20 and advertising routes until the node determines it = is

   = reachable=20 again.  

 

   = Routes via=20 that neighbor MUST be eliminated from the routing=20 table,

   = and the=20 node SHOULD poison using no-DAO all DAO routes that = it

  =  has=20 advertised via DAO and that it can reach only via that=20 neighbor.

 

The internals (keeping info about the DAOs to = resync more=20 quickly) are not described, long as the node behaves as if it has = cleaned=20 everything reachable only via the lost neighbor.

>>=20 Does this mean that there is no lifetime associated with DAO=20 routes?

>>Is=20 the retry_count + RemoveTimer procedure maintained in version 05?=20

>>=20 Does this mean that the local confidence is the only criteria to = assess=20 neighbor (including parents and child) = reachability?

 

Best,

Mathilde

 

------=_NextPart_001_0047_01CA7761.C9497CD0-- ------=_NextPart_000_0046_01CA7761.C9497CD0 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIL2jCCAj0w ggGmAhEAzbp/VvDf5LxU/iKss3KqVTANBgkqhkiG9w0BAQIFADBfMQswCQYDVQQGEwJVUzEXMBUG A1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDEgUHVibGljIFByaW1hcnkgQ2Vy dGlmaWNhdGlvbiBBdXRob3JpdHkwHhcNOTYwMTI5MDAwMDAwWhcNMjgwODAxMjM1OTU5WjBfMQsw CQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDEgUHVi bGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwgZ8wDQYJKoZIhvcNAQEBBQADgY0A MIGJAoGBAOUZv22jVmEtmUhx9mfeuY3rt56GgAqRDvo4Ja9GiILlc6igmyRdDR/MZW4MsNBWhBiH mgabEKFz37RYOWtuwfYV1aioP6oSBo0xrH+wNNePNGeICc0UEeJORVZpH3gCgNrcR5EpuzbJY1zF 4Ncth3uhtzKwezC6Ki8xqu6jZ9rbAgMBAAEwDQYJKoZIhvcNAQECBQADgYEATD+4i8Zo3+5DMw5d 6abLB4RNejP/khv0Nq3YlSI2aBFsfELM85wuxAc/FLAPT/+Qknb54rxK6Y/NoIAK98Up8YIiXbix 3YEjo3slFUYweRb46gVLlH8dwhzI47f0EEA8E8NfH1PoSOSGtHuhNbB7Jbq4046rPzidADQAmPPR cZQwggTFMIIDraADAgECAhABGiiLJme3TYjnRHtF1qTNMA0GCSqGSIb3DQEBBQUAMIHdMQswCQYD VQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0 IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5j b20vcnBhIChjKTA1MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlZl cmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzIwHhcNMDkxMTI2MDAw MDAwWhcNMTAxMTI2MjM1OTU5WjCCARIxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9z aXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQLExVQZXJzb25h IE5vdCBWYWxpZGF0ZWQxNDAyBgNVBAsTK0RpZ2l0YWwgSUQgQ2xhc3MgMSAtIE1pY3Jvc29mdCBG dWxsIFNlcnZpY2UxFzAVBgNVBAMUDk1hdGhpbGRlIER1cnZ5MR8wHQYJKoZIhvcNAQkBFhBtZHVy dnlAY2lzY28uY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDR9oVSAz6Tlt7xUvAb+IKp aqKdu1dh0cihpjNNzndIzit+ZWpixDZ8tWBtpZ7T2jBC+SiyquqIrin/TD4jlk60y4OBBeF2zlJa c6P0Ay8g4WjDRnvJP93Wz93W32bgjtV1R7FRlWUxPjn9QUDcq4PIHd4qFKSiOMfKk1OijYeWRQID AQABo4HMMIHJMAkGA1UdEwQCMAAwRAYDVR0gBD0wOzA5BgtghkgBhvhFAQcXATAqMCgGCCsGAQUF BwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMAsGA1UdDwQEAwIFoDAdBgNVHSUEFjAU BggrBgEFBQcDBAYIKwYBBQUHAwIwSgYDVR0fBEMwQTA/oD2gO4Y5aHR0cDovL0luZEMxRGlnaXRh bElELWNybC52ZXJpc2lnbi5jb20vSW5kQzFEaWdpdGFsSUQuY3JsMA0GCSqGSIb3DQEBBQUAA4IB AQA9I2FwWjWGMNapHvMFY2LZN+qr3cX6ILBUZ1AxypApr5B2Hl8YXDMA6o8Gtd5J2wxkJmEAbqXT zkoVWspigsclFSbGDu5V0ITLLZzzCXvwnpeaUD4F9GngqdkNUZkqXirqaMZxQTiaI5Hue2RX3f7b Ew4GqU+KMg6meor5iMoyGl/mtZ0LSPj6ZltNaG7ElQoyTXfdBGXlEm8z2uJhtb42Ys2OUptP1v3x jhxT2njv9NMcBH4q7S6y+op0aFrVsNLP7+qcPSBZlEcav3vyNSygxnqyx+pMJmgWH+/VdwsbSIDB FAo4DoI+fe2pUIeqRx6yP9s+e21BRiSPxvBtVe+JMIIEzDCCBDWgAwIBAgIQHK6da5r05i8iiqPa dGFsHjANBgkqhkiG9w0BAQUFADBfMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIElu Yy4xNzA1BgNVBAsTLkNsYXNzIDEgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3Jp dHkwHhcNMDUxMDI4MDAwMDAwWhcNMTUxMDI3MjM1OTU5WjCB3TELMAkGA1UEBhMCVVMxFzAVBgNV BAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYD VQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwNTEe MBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAx IEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIB CgKCAQEAyd+s5+r4+AMUxACS1cF+NsI873xyFcvAq4w9HJXObx4QLD8A7Zcm5rbH5q1DHT+kh0dH TD5U+Gz4x/yxnr0wcLyXsQMF6pXxrUDFRHpLBaLyYPzXOmVi7/8Qe6JWu8VOcC3Woh887bBC6F6N VyGsppnZEenSGgfAdEdCC/zFNOr95rok0R0IFTei13PPAUEvY7I6P76lGm70yUpbPZWmFbs1Ahn5 1O+8jw5xdlm7S7Y+1vxaFvTWDonySf5sDO0V6dmIdZx5zmAn3bmtdc4vc5V6QDqFdUmwuN9ovKvN E4KFEVCj4DwLrsAKU83XMG+FMkYb5EkQwmzirx95/9u0tQIDAQABo4IBhDCCAYAwEgYDVR0TAQH/ BAgwBgEB/wIBADBEBgNVHSAEPTA7MDkGC2CGSAGG+EUBBxcBMCowKAYIKwYBBQUHAgEWHGh0dHBz Oi8vd3d3LnZlcmlzaWduLmNvbS9ycGEwCwYDVR0PBAQDAgEGMBEGCWCGSAGG+EIBAQQEAwIBBjAu BgNVHREEJzAlpCMwITEfMB0GA1UEAxMWUHJpdmF0ZUxhYmVsMy0yMDQ4LTE1NTAdBgNVHQ4EFgQU EX1eGX08BN9qbNaiiho/Mdg7lFIwMQYDVR0fBCowKDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2ln bi5jb20vcGNhMS5jcmwwgYEGA1UdIwR6MHihY6RhMF8xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5W ZXJpU2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMSBQdWJsaWMgUHJpbWFyeSBDZXJ0aWZpY2F0 aW9uIEF1dGhvcml0eYIRAM26f1bw3+S8VP4irLNyqlUwDQYJKoZIhvcNAQEFBQADgYEAsS/ZluGS ou6BYOXIKiD74Wcs1gCYU6MCG+mQS/gYRJ8PRvf6oP7THRij0r8c7NYZn0pNQ/jKu74TgEkF3SFz M1fCQlq++gCTsuYEMZFOXTzwcwU3Y+u/g1mY/Wbe6YYympIpPDquVNqmElGxj8jK00d45tulHocG 49EUwMIh9roxggRzMIIEbwIBATCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWdu LCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBv ZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwNTEeMBwGA1UECxMVUGVy c29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwg U3Vic2NyaWJlciBDQSAtIEcyAhABGiiLJme3TYjnRHtF1qTNMAkGBSsOAwIaBQCgggLWMBgGCSqG SIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTA5MTIwNzE2MjIwMFowIwYJKoZI hvcNAQkEMRYEFBPg3hJZJYHFy+wS8deM1bPWgqLyMGcGCSqGSIb3DQEJDzFaMFgwCgYIKoZIhvcN AwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEo MAcGBSsOAwIaMAoGCCqGSIb3DQIFMIIBAwYJKwYBBAGCNxAEMYH1MIHyMIHdMQswCQYDVQQGEwJV UzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdv cmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBh IChjKTA1MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlZlcmlTaWdu IENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzICEAEaKIsmZ7dNiOdEe0XWpM0w ggEFBgsqhkiG9w0BCRACCzGB9aCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWdu LCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBv ZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwNTEeMBwGA1UECxMVUGVy c29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwg U3Vic2NyaWJlciBDQSAtIEcyAhABGiiLJme3TYjnRHtF1qTNMA0GCSqGSIb3DQEBAQUABIGAWKU+ oBzhTKI6GVYssP5Q1NAjhZMqnnV1Tdg/G4KZPdue3PnRnUXMmtx+ljiwuIJy3L4TTTBdruZJmvzO RnMkbbzXHuo886gubNODAwDFGenZwMwuiYCvouW3nK578OiyHESbnYwqRHTNzoKP2d3YwTddaQvw mnmXfXJOfTTfL/gAAAAAAAA= ------=_NextPart_000_0046_01CA7761.C9497CD0-- From root@core3.amsl.com Mon Dec 7 16:30:02 2009 Return-Path: X-Original-To: roll@ietf.org Delivered-To: roll@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id E4E243A6862; Mon, 7 Dec 2009 16: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: <20091208003001.E4E243A6862@core3.amsl.com> Date: Mon, 7 Dec 2009 16:30:01 -0800 (PST) Cc: roll@ietf.org Subject: [Roll] I-D Action:draft-ietf-roll-rpl-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: Tue, 08 Dec 2009 00: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-05.txt Pages : 80 Date : 2009-12-07 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. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on June 10, 2010. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-roll-rpl-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-rpl-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-12-07162955.I-D@ietf.org> --NextPart-- From jvasseur@cisco.com Mon Dec 7 21:58:30 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2CAA03A68E3 for ; Mon, 7 Dec 2009 21:58:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.186 X-Spam-Level: X-Spam-Status: No, score=-5.186 tagged_above=-999 required=5 tests=[AWL=-2.589, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_HTML_MOSTLY=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 h7SKX-0bm7v9 for ; Mon, 7 Dec 2009 21:58:28 -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 0930A3A6859 for ; Mon, 7 Dec 2009 21:58:27 -0800 (PST) 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: AlIAAPN5HUuQ/uCWiWdsb2JhbACbVAEBAQoLERMGpS2Wc4QyBIFn X-IronPort-AV: E=Sophos;i="4.47,360,1257120000"; d="scan'208,217";a="798981" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-2.cisco.com with ESMTP; 08 Dec 2009 05:32: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 nB85wGIC010870 for ; Tue, 8 Dec 2009 05:58:16 GMT Received: from xfe-ams-102.cisco.com ([144.254.231.94]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 8 Dec 2009 06:58:15 +0100 Received: from ams-jvasseur-8715.cisco.com ([10.55.201.134]) by xfe-ams-102.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 8 Dec 2009 06:58:14 +0100 Message-Id: <9E3489EC-FC0A-4C46-919C-BCE2C487D335@cisco.com> From: JP Vasseur To: ROLL WG Content-Type: multipart/alternative; boundary=Apple-Mail-44-624336058 Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 8 Dec 2009 06:58:13 +0100 References: <20091208003001.E4E243A6862@core3.amsl.com> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 08 Dec 2009 05:58:14.0787 (UTC) FILETIME=[6E683530:01CA77CB] X-TM-AS-Product-Ver: SMEX-8.0.0.1181-6.000.1038-17056.002 X-TM-AS-Result: No--30.841600-8.000000-31 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No Subject: [Roll] Update on RPL X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Dec 2009 05:58:30 -0000 --Apple-Mail-44-624336058 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Dear all, As you know the WG at large and the RPL's authors have been working really hard on the I-D for the past 6-8 months and the I-D is getting in a really good shape. Tim will probably send a detailed update about this revision but in a nutshell, we now have all the necessary mechanisms in place. Several implementers asked us when the specification would be fairly stable, this is the case with -05. In the next revision (planned for the next 2 weeks), we will flesh out the DAO mechanism in light of the recent discussion before starting to work on security (for -07). For information, there are on-going simulations and implementations that we should soon hear about, which is a great news. Thanks, let's continue and we will undoubtedly meet our milestone. JP. Begin forwarded message: > From: Internet-Drafts@ietf.org > Date: December 8, 2009 1:30:01 AM CEST > To: i-d-announce@ietf.org > Cc: roll@ietf.org > Subject: [Roll] I-D Action:draft-ietf-roll-rpl-05.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 : RPL: IPv6 Routing Protocol for Low power and > Lossy Networks > Author(s) : T. Winter, et al. > Filename : draft-ietf-roll-rpl-05.txt > Pages : 80 > Date : 2009-12-07 > > 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. > > Status of this Memo > > This Internet-Draft is submitted to IETF in full conformance with the > provisions of BCP 78 and BCP 79. > > Internet-Drafts are working documents of the Internet Engineering > Task Force (IETF), its areas, and its working groups. Note that > other groups may also distribute working documents as Internet- > Drafts. > > Internet-Drafts are draft documents valid for a maximum of six months > and may be updated, replaced, or obsoleted by other documents at any > time. It is inappropriate to use Internet-Drafts as reference > material or to cite them other than as "work in progress." > > The list of current Internet-Drafts can be accessed at > http://www.ietf.org/ietf/1id-abstracts.txt. > The list of Internet-Draft Shadow Directories can be accessed at > http://www.ietf.org/shadow.html. > > This Internet-Draft will expire on June 10, 2010. > > Copyright Notice > > Copyright (c) 2009 IETF Trust and the persons identified as the > document authors. All rights reserved. > > This document is subject to BCP 78 and the IETF Trust's Legal > Provisions Relating to IETF Documents > (http://trustee.ietf.org/license-info) in effect on the date of > publication of this document. Please review these documents > carefully, as they describe your rights and restrictions with respect > to this document. Code Components extracted from this document must > include Simplified BSD License text as described in Section 4.e of > the Trust Legal Provisions and are provided without warranty as > described in the BSD License. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-roll-rpl-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. > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll --Apple-Mail-44-624336058 Content-Type: multipart/mixed; boundary=Apple-Mail-45-624336059 --Apple-Mail-45-624336059 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Dear all,

As = you know the WG at large and the RPL's authors have been working really = hard on the I-D for the past 6-8 months and the I-D is getting in a = really good shape. Tim will probably send a detailed update about this = revision but in a nutshell, we now have all the necessary mechanisms in = place. Several implementers asked us when the specification would be = fairly stable, this is the case with -05. In the next revision (planned = for the next 2 weeks), we will flesh out the DAO mechanism in light of = the recent discussion before starting to work on security (for = -07). 

For information, there are on-going = simulations and implementations that we should soon hear about, which is = a great news.

Thanks, let's continue and we = will undoubtedly meet our = milestone.

JP.

Begin forwarded = message:

Date: December 8, 2009 1:30:01 AM = CEST
To: i-d-announce@ietf.org
Subject: = [Roll] I-D = Action:draft-ietf-roll-rpl-05.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 =           : RPL: IPv6 = Routing Protocol for Low power and Lossy Networks
Author(s) =       : T. Winter, et al.
Filename =        : = draft-ietf-roll-rpl-05.txt
Pages =           : = 80
= Date =            : = 2009-12-07

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.

Status of this = Memo

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

Internet-Drafts are = working documents of the Internet Engineering
Task Force (IETF), its = areas, and its working groups.  Note that
other groups may also = distribute working documents as = Internet-
Drafts.

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

The list of current Internet-Drafts = can be accessed at
http://www.ietf.org/ie= tf/1id-abstracts.txt.
The list of Internet-Draft Shadow = Directories can be accessed at
http://www.ietf.org/shadow.html.

This Internet-Draft will expire on June 10, = 2010.

Copyright Notice

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

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

A URL for this Internet-Draft is:
ht= tp://www.ietf.org/internet-drafts/draft-ietf-roll-rpl-05.txt

In= ternet-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-45-624336059 Content-Disposition: attachment; filename=mime-attachment Content-Type: message/external-body; x-unix-mode=0666; name="mime-attachment" Content-Transfer-Encoding: 7bit Content-Type: text/plain
Content-ID: <2009-12-07162955.I-D@ietf.org>

--Apple-Mail-45-624336059 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit
_______________________________________________
Roll mailing list
Roll@ietf.org
https://www.ietf.org/mailman/listinfo/roll

--Apple-Mail-45-624336059-- --Apple-Mail-44-624336058-- From trac@tools.ietf.org Tue Dec 8 01:03:05 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D163C28C0EF for ; Tue, 8 Dec 2009 01:03:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.524 X-Spam-Level: X-Spam-Status: No, score=-102.524 tagged_above=-999 required=5 tests=[AWL=0.076, 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 GQX+m6W-47BL for ; Tue, 8 Dec 2009 01:03:05 -0800 (PST) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:1112:1:214:22ff:fe1f:1e54]) by core3.amsl.com (Postfix) with ESMTP id 2092028C0DD for ; Tue, 8 Dec 2009 01:03:05 -0800 (PST) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1NHvyA-0004o5-CG; Tue, 08 Dec 2009 01:02:54 -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.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.5, by Edgewall Software To: wintert@acm.org, jpv@cisco.com X-Trac-Project: roll Date: Tue, 08 Dec 2009 09:02:54 -0000 X-URL: http://tools.ietf.org/wg/roll/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/roll/trac/ticket/22 Message-ID: <055.1a1aaaeaf2030dd5f8fdc2f8ac1702f7@tools.ietf.org> X-Trac-Ticket-ID: 22 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] #22: RPL Variables 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, 08 Dec 2009 09:03:05 -0000 #22: RPL Variables --------------------------------+------------------------------------------- Reporter: jpv@… | Owner: wintert@… Type: task | Status: new Priority: major | Milestone: Component: rpl | Version: Severity: Active WG Document | Keywords: --------------------------------+------------------------------------------- There are several RPL variables/constants in the RPL specification to be determined: DEFAULT_DIO_INTERVAL_MIN To be determined DEFAULT_DIO_INTERVAL_DOUBLINGS To be determined DEFAULT_DIO_REDUNDANCY_CONSTANT To be determined DEF_DAO_LATENCY To be determined MAX_DESTROY_INTERVAL To be determined -- Ticket URL: roll From mdurvy@cisco.com Tue Dec 8 07:23:00 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 01ECA28C15E for ; Tue, 8 Dec 2009 07:23:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.583 X-Spam-Level: X-Spam-Status: No, score=-3.583 tagged_above=-999 required=5 tests=[AWL=-2.405, 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 ooL2v+VqyZp1 for ; Tue, 8 Dec 2009 07:22:58 -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 5463528C15F for ; Tue, 8 Dec 2009 07:22:56 -0800 (PST) Authentication-Results: ams-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-Files: smime.p7s : 4235 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmYAAGn+HUuQ/uCWiWdsb2JhbACCXph5AQEBCgsREwalNpcbAoQwBIFo X-IronPort-AV: E=Sophos;i="4.47,362,1257120000"; d="gif'147?p7s'147?scan'147,208,217,147";a="844076" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-2.cisco.com with ESMTP; 08 Dec 2009 14:56:30 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id nB8FMiwh023615 for ; Tue, 8 Dec 2009 15:22:44 GMT Received: from xmb-ams-103.cisco.com ([144.254.74.78]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 8 Dec 2009 16:22:44 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 8 Dec 2009 16:22:43 +0100 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_00B3_01CA7822.AB492840" Message-ID: <8A977BDC5A7B0E429B0F521E8D6F91EEE5F892@XMB-AMS-103.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: IPv6 alignment requirement Thread-Index: Acp4GkjnkvhSyhxITZKfmWfoYSrFRA== From: "Mathilde Durvy (mdurvy)" To: X-OriginalArrivalTime: 08 Dec 2009 15:22:44.0100 (UTC) FILETIME=[4A173C40:01CA781A] Subject: [Roll] IPv6 alignment 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: Tue, 08 Dec 2009 15:23:00 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_00B3_01CA7822.AB492840 Content-Type: multipart/related; boundary="----=_NextPart_001_00B4_01CA7822.AB492840" ------=_NextPart_001_00B4_01CA7822.AB492840 Content-Type: multipart/alternative; boundary="----=_NextPart_002_00B5_01CA7822.AB492840" ------=_NextPart_002_00B5_01CA7822.AB492840 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi All, =20 As mentioned in rpl-05 page 23 "Following the convention in IPv6, these options are aligned in a packet such that multi-octet values within the Option Data field of each option fall on natural boundaries (i.e., fields of width n octets are placed at an integer multiple of n octets from the start of the header, for n =3D 1, 2, 4, or 8)." It would be good if RLP would follow the IPv6 guidelines as code = structures that don't follow this principle are difficult to handle (due to = automatic padding in between fields). In particular the DIO suboption header is a big problem has you have a 2 byte field (the length) placed 1 byte from the start of the header. =20 Best, Mathilde =20 =20 =09 Durvy Mathilde Software Engineer Technology center mdurvy@cisco.com Phone: +41 21 822 1725 Mobile: +41 76 396 8116 Cisco Systems International S=E0rl Av. des Uttins, 5 CH-1180 Rolle Cisco home page =20 =09 Think before you print. = Think before you print.=09 This e-mail may contain confidential and privileged material for the = sole use of the intended recipient. Any review, use, distribution or = disclosure by others is strictly prohibited. If you are not the intended recipient = (or authorized to receive for the recipient), please contact the sender by = reply e-mail and delete all copies of this message.=09 =20 ------=_NextPart_002_00B5_01CA7822.AB492840 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi=20 All,
 
As = mentioned in=20 rpl-05 page 23

  "Following
   the convention in IPv6, = these=20 options are aligned in a packet such
   that multi-octet values = within the=20 Option Data field of each option
  =20 fall on natural boundaries (i.e., fields of width n octets are=20 placed
   at an = integer=20 multiple of n octets from the start of the header, for
   n =3D 1, 2, 4, or = 8)."

It would be good if RLP = would follow=20 the IPv6 guidelines as code structures that=20 don't follow this principle are difficult to = handle=20 (due to automatic padding in between fields).

In = particular the=20 DIO suboption header is a big problem has you have a 2 byte field (the = length)=20 placed 1 byte from the start of the = header.

 
Best,
=
Mathilde


 
 
Durvy=20 Mathilde
Software=20 Engineer
Technology=20 center

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

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

Cisco home = page

  
=20 Think before you print.This=20 e-mail may contain confidential and privileged material for = the sole=20 use of the intended recipient. Any review, use, distribution = or=20 disclosure by others is strictly prohibited. If you are not = the=20 intended recipient (or authorized to receive for the = recipient),=20 please contact the sender by reply e-mail and delete all = copies of=20 this = message.
 
------=_NextPart_002_00B5_01CA7822.AB492840-- ------=_NextPart_001_00B4_01CA7822.AB492840 Content-Type: image/gif; name="logo.gif" Content-Transfer-Encoding: base64 Content-Location: http://www.cisco.com/swa/i/logo.gif R0lGODlhbgBJAMQAAP///3OXqtapqq1MTcmRki9mgZkAALpqbMl/f6g5O/Xq6+vX2OTIyaMqK/nz 9OW/v5sVFsbV3Nfh5p0PD5kFBf78/P38/Pz6+v/+/rZdXpcKDKAhIvv396QvMO/g4Ny4uSH5BAAA AAAALAAAAABuAEkAQAX/ICCOZGmeaKqubOu+cCzPdG3feK6nkln8pp5LSPoVgrucsbQsAp1HKPM5 alapImtyy+16SwKDmJBCiBEWgMUsPgg8JMHEQCGTMACP2HDgiBQZYglfOQ+GDy2HhiqKKI2EkJGS k5SVlpeYmZpfWkpYmypEV1GjU6QjolmfnZ0AqZWvrj6fski2UiWxsZkcHxkNYg0IABUibAjFIgsH wAYNBwokvb8QEMIOJAwICQYQCQgLoCgLHWIdHwoKCwzExmdpGBwcxRgDYhkXAOTm6OoMfg4CiRGg wAOBOXzEKVzIsKHDhxAjSpxIsaKNCAEibMGo0WKLVjdAVgxQIICpEiRN/7JIeZIEy4WsVsk8BSAm TZstLb0csVMVzZ4AgALtJLQkRY4bM3pcupDAHgMduA1Q484AGmJO7x04kCCaCAIaxFCISmGAVwZP u+1pEK5hVgPYUBxLQ4yBvacfvlIwMCFuCbRi2I34sHfDQ0BpDUyFNxfABTZPGwgGACjsU7MiLLx9 ukEA08+gQ4seTbq06dOoU6tezbq169evd92QHRooDtujRdbQDZr3DN8RkeIaIXxFcZ8ljkPEOVwF 81ILlT9HTkL6zJwilE+aXvN68+43vUO3xL28eOrj0VdSbp0me6XV4acH8L6jRNw28IumXYM/7P8k PJLIISkIWIKBD3GwmcIYiwGAQWP6cJMWHCIoCEFamInwQTNPdYCIQwqUM8YCC3zgWTKNOXAAg14p kA9lIkJAAIkmYsPBim0YcsBeVjn0llcnQAjYHh14phdfQGazx2QAEGaAYQ2FMVAZ75BggTZ7HFCM HHQYWcICeyAjgormPASZYgN00CAAjV0gwAEEEACZlsbwCMEAaWb4wFMJJMDjBkwypAABErbRzoNn FFPBghnkRcKgCVimwQF+VSDAXXw1CuCmnHbq6aeghirqqDiEAAA7 ------=_NextPart_001_00B4_01CA7822.AB492840 Content-Type: image/gif; name="green.gif" Content-Transfer-Encoding: base64 Content-Location: http://www.cisco.com/global/EMEA/brand/signature/capital/green.gif R0lGODlhEgATAJEAAAAAAP///wCZAP///yH5BAEAAAMALAAAAAASABMAAAIojI+pGyK8nINqUiTf bVnfvHEg1UmhdZRqaawu6XZVjKb0/CYxo8JOAQA7 ------=_NextPart_001_00B4_01CA7822.AB492840-- ------=_NextPart_000_00B3_01CA7822.AB492840 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIL2jCCAj0w ggGmAhEAzbp/VvDf5LxU/iKss3KqVTANBgkqhkiG9w0BAQIFADBfMQswCQYDVQQGEwJVUzEXMBUG A1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDEgUHVibGljIFByaW1hcnkgQ2Vy dGlmaWNhdGlvbiBBdXRob3JpdHkwHhcNOTYwMTI5MDAwMDAwWhcNMjgwODAxMjM1OTU5WjBfMQsw CQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDEgUHVi bGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwgZ8wDQYJKoZIhvcNAQEBBQADgY0A MIGJAoGBAOUZv22jVmEtmUhx9mfeuY3rt56GgAqRDvo4Ja9GiILlc6igmyRdDR/MZW4MsNBWhBiH mgabEKFz37RYOWtuwfYV1aioP6oSBo0xrH+wNNePNGeICc0UEeJORVZpH3gCgNrcR5EpuzbJY1zF 4Ncth3uhtzKwezC6Ki8xqu6jZ9rbAgMBAAEwDQYJKoZIhvcNAQECBQADgYEATD+4i8Zo3+5DMw5d 6abLB4RNejP/khv0Nq3YlSI2aBFsfELM85wuxAc/FLAPT/+Qknb54rxK6Y/NoIAK98Up8YIiXbix 3YEjo3slFUYweRb46gVLlH8dwhzI47f0EEA8E8NfH1PoSOSGtHuhNbB7Jbq4046rPzidADQAmPPR cZQwggTFMIIDraADAgECAhABGiiLJme3TYjnRHtF1qTNMA0GCSqGSIb3DQEBBQUAMIHdMQswCQYD VQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0 IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5j b20vcnBhIChjKTA1MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlZl cmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzIwHhcNMDkxMTI2MDAw MDAwWhcNMTAxMTI2MjM1OTU5WjCCARIxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9z aXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQLExVQZXJzb25h IE5vdCBWYWxpZGF0ZWQxNDAyBgNVBAsTK0RpZ2l0YWwgSUQgQ2xhc3MgMSAtIE1pY3Jvc29mdCBG dWxsIFNlcnZpY2UxFzAVBgNVBAMUDk1hdGhpbGRlIER1cnZ5MR8wHQYJKoZIhvcNAQkBFhBtZHVy dnlAY2lzY28uY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDR9oVSAz6Tlt7xUvAb+IKp aqKdu1dh0cihpjNNzndIzit+ZWpixDZ8tWBtpZ7T2jBC+SiyquqIrin/TD4jlk60y4OBBeF2zlJa c6P0Ay8g4WjDRnvJP93Wz93W32bgjtV1R7FRlWUxPjn9QUDcq4PIHd4qFKSiOMfKk1OijYeWRQID AQABo4HMMIHJMAkGA1UdEwQCMAAwRAYDVR0gBD0wOzA5BgtghkgBhvhFAQcXATAqMCgGCCsGAQUF BwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMAsGA1UdDwQEAwIFoDAdBgNVHSUEFjAU BggrBgEFBQcDBAYIKwYBBQUHAwIwSgYDVR0fBEMwQTA/oD2gO4Y5aHR0cDovL0luZEMxRGlnaXRh bElELWNybC52ZXJpc2lnbi5jb20vSW5kQzFEaWdpdGFsSUQuY3JsMA0GCSqGSIb3DQEBBQUAA4IB AQA9I2FwWjWGMNapHvMFY2LZN+qr3cX6ILBUZ1AxypApr5B2Hl8YXDMA6o8Gtd5J2wxkJmEAbqXT zkoVWspigsclFSbGDu5V0ITLLZzzCXvwnpeaUD4F9GngqdkNUZkqXirqaMZxQTiaI5Hue2RX3f7b Ew4GqU+KMg6meor5iMoyGl/mtZ0LSPj6ZltNaG7ElQoyTXfdBGXlEm8z2uJhtb42Ys2OUptP1v3x jhxT2njv9NMcBH4q7S6y+op0aFrVsNLP7+qcPSBZlEcav3vyNSygxnqyx+pMJmgWH+/VdwsbSIDB FAo4DoI+fe2pUIeqRx6yP9s+e21BRiSPxvBtVe+JMIIEzDCCBDWgAwIBAgIQHK6da5r05i8iiqPa dGFsHjANBgkqhkiG9w0BAQUFADBfMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIElu Yy4xNzA1BgNVBAsTLkNsYXNzIDEgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3Jp dHkwHhcNMDUxMDI4MDAwMDAwWhcNMTUxMDI3MjM1OTU5WjCB3TELMAkGA1UEBhMCVVMxFzAVBgNV BAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYD VQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwNTEe MBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAx IEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIB CgKCAQEAyd+s5+r4+AMUxACS1cF+NsI873xyFcvAq4w9HJXObx4QLD8A7Zcm5rbH5q1DHT+kh0dH TD5U+Gz4x/yxnr0wcLyXsQMF6pXxrUDFRHpLBaLyYPzXOmVi7/8Qe6JWu8VOcC3Woh887bBC6F6N VyGsppnZEenSGgfAdEdCC/zFNOr95rok0R0IFTei13PPAUEvY7I6P76lGm70yUpbPZWmFbs1Ahn5 1O+8jw5xdlm7S7Y+1vxaFvTWDonySf5sDO0V6dmIdZx5zmAn3bmtdc4vc5V6QDqFdUmwuN9ovKvN E4KFEVCj4DwLrsAKU83XMG+FMkYb5EkQwmzirx95/9u0tQIDAQABo4IBhDCCAYAwEgYDVR0TAQH/ BAgwBgEB/wIBADBEBgNVHSAEPTA7MDkGC2CGSAGG+EUBBxcBMCowKAYIKwYBBQUHAgEWHGh0dHBz Oi8vd3d3LnZlcmlzaWduLmNvbS9ycGEwCwYDVR0PBAQDAgEGMBEGCWCGSAGG+EIBAQQEAwIBBjAu BgNVHREEJzAlpCMwITEfMB0GA1UEAxMWUHJpdmF0ZUxhYmVsMy0yMDQ4LTE1NTAdBgNVHQ4EFgQU EX1eGX08BN9qbNaiiho/Mdg7lFIwMQYDVR0fBCowKDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2ln bi5jb20vcGNhMS5jcmwwgYEGA1UdIwR6MHihY6RhMF8xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5W ZXJpU2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMSBQdWJsaWMgUHJpbWFyeSBDZXJ0aWZpY2F0 aW9uIEF1dGhvcml0eYIRAM26f1bw3+S8VP4irLNyqlUwDQYJKoZIhvcNAQEFBQADgYEAsS/ZluGS ou6BYOXIKiD74Wcs1gCYU6MCG+mQS/gYRJ8PRvf6oP7THRij0r8c7NYZn0pNQ/jKu74TgEkF3SFz M1fCQlq++gCTsuYEMZFOXTzwcwU3Y+u/g1mY/Wbe6YYympIpPDquVNqmElGxj8jK00d45tulHocG 49EUwMIh9roxggRzMIIEbwIBATCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWdu LCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBv ZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwNTEeMBwGA1UECxMVUGVy c29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwg U3Vic2NyaWJlciBDQSAtIEcyAhABGiiLJme3TYjnRHtF1qTNMAkGBSsOAwIaBQCgggLWMBgGCSqG SIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTA5MTIwODE1MjI0M1owIwYJKoZI hvcNAQkEMRYEFH3kIbWgx/UVTXT1BGcDqRMHVwA4MGcGCSqGSIb3DQEJDzFaMFgwCgYIKoZIhvcN AwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEo MAcGBSsOAwIaMAoGCCqGSIb3DQIFMIIBAwYJKwYBBAGCNxAEMYH1MIHyMIHdMQswCQYDVQQGEwJV UzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdv cmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBh IChjKTA1MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlZlcmlTaWdu IENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzICEAEaKIsmZ7dNiOdEe0XWpM0w ggEFBgsqhkiG9w0BCRACCzGB9aCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWdu LCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBv ZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwNTEeMBwGA1UECxMVUGVy c29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwg U3Vic2NyaWJlciBDQSAtIEcyAhABGiiLJme3TYjnRHtF1qTNMA0GCSqGSIb3DQEBAQUABIGAtJ3g aP7S5U3HmHM9NR7IuGetrYEuRjWOkZFHeHz4RKSUTv1MWMm6DfvHZSu5XpCoeitdjjCkSy1PdVAe Ea10jDRdh7Bp+3n6Nm/Wy5UM1c97BIquok0k6DZJFo4JF+M4Gvzyi6dUHPZC+A7gtzQdvUJbIgLj UlsPJB13rJ6yb/0AAAAAAAA= ------=_NextPart_000_00B3_01CA7822.AB492840-- From wintert@acm.org Tue Dec 8 15:26:26 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 62E5D3A683D for ; Tue, 8 Dec 2009 15:26:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.598 X-Spam-Level: X-Spam-Status: No, score=-102.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p8mihlwp5wGP for ; Tue, 8 Dec 2009 15:26:25 -0800 (PST) Received: from smtp102.prem.mail.ac4.yahoo.com (smtp102.prem.mail.ac4.yahoo.com [76.13.13.41]) by core3.amsl.com (Postfix) with SMTP id 32E9D3A682B for ; Tue, 8 Dec 2009 15:26:25 -0800 (PST) Received: (qmail 72689 invoked from network); 8 Dec 2009 23:26:08 -0000 Received: from 206-83-249-194.edurostream.com (wintert@206.83.249.194 with plain) by smtp102.prem.mail.ac4.yahoo.com with SMTP; 08 Dec 2009 15:26:08 -0800 PST X-Yahoo-SMTP: 30iEHGKswBCbca_Y5pX7d6RVQMoT5Mk- X-YMail-OSG: qr0gIUwVM1mhkKDl3o7O.k3emy2zA.BqjVh6F7TMYh_7NBCauYgQhR3l3K7YSlXOfcc8v9.v9qR_Q079isuE9IxajFlSo2Msai6M8vcW4uT5Kr.b40cizXVIIg1raHwngzaG8NhMjsdM34sOatnnNWJdkwereWmEgVm3oeHnkc9jC8w0PRYQ3g0YSxk2DbCdqtecfIxq8FjdQURYzCUsMBkquvtfXMFqbNhjtObvDXyaIAnyD2REvyVse7X1IycF9AWUYrAfn8LaSr67rQ0DS77tXkcJaUVVgOOmxkCkvLpJCjSz.Qh9EI4J X-Yahoo-Newman-Property: ymail-3 Message-ID: <4B1EE090.7060807@acm.org> Date: Tue, 08 Dec 2009 18:26:08 -0500 From: Tim Winter User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: ROLL WG References: <20091208003001.E4E243A6862@core3.amsl.com> In-Reply-To: <20091208003001.E4E243A6862@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-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: Tue, 08 Dec 2009 23:26:26 -0000 WG, This revision includes the following: (http://tools.ietf.org/wg/roll/trac/query?status=new&status=assigned&status=reopened&component=rpl) Ticket 3 Ticket 5 Ticket 7 Ticket 9 Ticket 10 Ticket 12 Ticket 13 Ticket 14 Ticket 15 Ticket 16 - OF0 is removed from RPL and will be described in a companion draft - Many editorial cleanups, especially to Sections 3 and 5 - Section 5 (Specification) broken out into normative/non-normative parts - Non-normative guidlines/suggestions broken out into other sections - clarifications of DAG Instance / DODAG / DODAG Iteration - Introduction of `Goal' -- Grounded is defined as a DODAG that can reach the Goal. Floating DODAG cannot reach the goal (note that this changes slightly the meaning of floating as compared to prior revisions, but is more inline with the intention of the text) - Addition of DIORedundancyConstant, DAGMaxRankIncrease to DAG Configuration option of DIO - Add mechanisms for local repair - Clarification of operation as a leaf node Thanks, -RPL Authors 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-05.txt > Pages : 80 > Date : 2009-12-07 > > 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. > > Status of this Memo > > This Internet-Draft is submitted to IETF in full conformance with the > provisions of BCP 78 and BCP 79. > > Internet-Drafts are working documents of the Internet Engineering > Task Force (IETF), its areas, and its working groups. Note that > other groups may also distribute working documents as Internet- > Drafts. > > Internet-Drafts are draft documents valid for a maximum of six months > and may be updated, replaced, or obsoleted by other documents at any > time. It is inappropriate to use Internet-Drafts as reference > material or to cite them other than as "work in progress." > > The list of current Internet-Drafts can be accessed at > http://www.ietf.org/ietf/1id-abstracts.txt. > The list of Internet-Draft Shadow Directories can be accessed at > http://www.ietf.org/shadow.html. > > This Internet-Draft will expire on June 10, 2010. > > Copyright Notice > > Copyright (c) 2009 IETF Trust and the persons identified as the > document authors. All rights reserved. > > This document is subject to BCP 78 and the IETF Trust's Legal > Provisions Relating to IETF Documents > (http://trustee.ietf.org/license-info) in effect on the date of > publication of this document. Please review these documents > carefully, as they describe your rights and restrictions with respect > to this document. Code Components extracted from this document must > include Simplified BSD License text as described in Section 4.e of > the Trust Legal Provisions and are provided without warranty as > described in the BSD License. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-roll-rpl-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. > > > ------------------------------------------------------------------------ > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From dominique.barthel@orange-ftgroup.com Wed Dec 9 05:40:38 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4EBBC3A69E7 for ; Wed, 9 Dec 2009 05:40:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.334 X-Spam-Level: X-Spam-Status: No, score=-2.334 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_32=0.6, RCVD_IN_DNSWL_LOW=-1, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dopajxvGsLZ0 for ; Wed, 9 Dec 2009 05:40:37 -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 192773A67C2 for ; Wed, 9 Dec 2009 05:40:36 -0800 (PST) Received: from ftrdmel0.rd.francetelecom.fr ([10.192.128.56]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Wed, 9 Dec 2009 14:40: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: Wed, 9 Dec 2009 14:37:50 +0100 Message-ID: <8E09C72DBC577D489F13A71228C0B7BFB66EE2@ftrdmel0.rd.francetelecom.fr> In-Reply-To: <064.a0debcb7f3f3224fe1dd2f980dbfac72@tools.ietf.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] [roll] #12: DIS Thread-Index: Acp0KSK7b/35nwY4QhGt35KGwRCRBwEqh6Bg References: <055.c2df21e47095fbec7400989f77132d30@tools.ietf.org> <064.a0debcb7f3f3224fe1dd2f980dbfac72@tools.ietf.org> From: To: , , X-OriginalArrivalTime: 09 Dec 2009 13:40:23.0390 (UTC) FILETIME=[285AFFE0:01CA78D5] Subject: Re: [Roll] [roll] #12: 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, 09 Dec 2009 13:40:38 -0000 Hello all, Where there is a high density of nodes/routers, we want to be more = selective as to who shall respond to a multicast DIS. DIS currently has no message body. Would it be possible to have the = message body indicate a range of ranks and a maximal link cost for nodes = requested to respond ? (default would be a catch all). It's much better to have to send a few selective DIS'es, lowering the = requirements as needed, rather than have all neighbors respond = irrespective of their quality to becoming a parent/sibling. And I guess the magic sentence is : there are sensor networks in the = field, with millions of devices deployed, that do it today and need it = in the future. Your comments ? Thanks Dominique =20 -----Message d'origine----- De : roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] De la part de = roll issue tracker Envoy=E9 : jeudi 3 d=E9cembre 2009 15:59 =C0 : wintert@acm.org; jpv@cisco.com Cc : roll@ietf.org Objet : Re: [Roll] [roll] #12: DIS #12: DIS --------------------------------+--------------------------------------- --------------------------------+---- Reporter: jpv@... | Owner: wintert@... =20 Type: defect | Status: closed =20 Priority: trivial | Milestone: =20 Component: rpl | Version: =20 Severity: Active WG Document | Resolution: fixed =20 Keywords: | =20 --------------------------------+--------------------------------------- --------------------------------+---- Changes (by jpv@...): * status: new =3D> closed * resolution: =3D> fixed Comment: The use of Trickle serves to randomize the response to DIS messages. For -05, RPL text is updated to clarify: o When a node receives a multicast DIS message, it MUST reset the trickle timer to the minimum value. o When a node receives a unicast DIS message, it MUST unicast a DIO message in response, and include the DAG Configuration Object. In this case the node SHOULD NOT reset the trickle timer. -- Ticket URL: roll _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From Jerald.P.Martocci@jci.com Wed Dec 9 07:03:45 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A975B3A69EE; Wed, 9 Dec 2009 07:03:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.958 X-Spam-Level: X-Spam-Status: No, score=-5.958 tagged_above=-999 required=5 tests=[AWL=-0.275, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_32=0.6, RCVD_IN_DNSWL_MED=-4, SARE_MILLIONSOF=0.315] Received: 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+NNJLyONHI1; Wed, 9 Dec 2009 07:03:44 -0800 (PST) Received: from exprod8og107.obsmtp.com (exprod8og107.obsmtp.com [64.18.3.94]) by core3.amsl.com (Postfix) with ESMTP id 06B8B3A67F5; Wed, 9 Dec 2009 07:03:42 -0800 (PST) Received: from source ([192.132.24.137]) (using SSLv3) by exprod8ob107.postini.com ([64.18.7.12]) with SMTP ID DSNKSx+8Qjnk7RKBOEr2S42IutTk3+nQwfqz@postini.com; Wed, 09 Dec 2009 07:03:33 PST Received: from jwimkrs1.na.jci.com ([10.10.6.31]) by smtpmke01.jci.com (Lotus Domino Release 8.0.1) with ESMTP id 2009120909041180-6261262 ; Wed, 9 Dec 2009 09:04:11 -0600 In-Reply-To: <8E09C72DBC577D489F13A71228C0B7BFB66EE2@ftrdmel0.rd.francetelecom.fr> MIME-Version: 1.0 To: X-Mailer: Lotus Notes Release 6.5.2 June 01, 2004 From: Jerald.P.Martocci@jci.com Message-ID: Date: Wed, 9 Dec 2009 09:02:45 -0600 X-MIMETrack: Serialize by Router on jwimkrs1.na.jci.com/NA/Johnson_Controls at 12/09/2009 09:02:53 AM, Serialize complete at 12/09/2009 09:02:53 AM, Itemize by SMTP Server on smtpmke01.jci.com/JCI_SMTP(Release 8.0.1|February 07, 2008) at 12/09/2009 09:04:11 AM, Serialize by Router on smtpmke01.jci.com/JCI_SMTP(Release 8.0.1|February 07, 2008) at 12/09/2009 09:04:51 AM, Serialize complete at 12/09/2009 09:04:51 AM Content-Type: multipart/alternative; boundary="=_alternative 0052A62586257687_=" Cc: roll-bounces@ietf.org, roll@ietf.org Subject: Re: [Roll] [roll] #12: 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, 09 Dec 2009 15:03:45 -0000 This is a multipart message in MIME format. --=_alternative 0052A62586257687_= Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="ISO-8859-1" Hey Dominique, +1 for me. I like it.=20 =20 Sent by: roll-bounces@ietf.org 12/09/2009 07:40 AM To , , cc Subject Re: [Roll] [roll] #12: DIS Hello all, Where there is a high density of nodes/routers, we want to be more=20 selective as to who shall respond to a multicast DIS. DIS currently has no message body. Would it be possible to have the=20 message body indicate a range of ranks and a maximal link cost for nodes=20 requested to respond ? (default would be a catch all). It's much better to have to send a few selective DIS'es, lowering the=20 requirements as needed, rather than have all neighbors respond=20 irrespective of their quality to becoming a parent/sibling. And I guess the magic sentence is : there are sensor networks in the=20 field, with millions of devices deployed, that do it today and need it in=20 the future. Your comments ? Thanks Dominique =20 -----Message d'origine----- De : roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] De la part de=20 roll issue tracker Envoy=E9 : jeudi 3 d=E9cembre 2009 15:59 =C0 : wintert@acm.org; jpv@cisco.com Cc : roll@ietf.org Objet : Re: [Roll] [roll] #12: DIS #12: DIS --------------------------------+--------------------------------------- --------------------------------+---- Reporter: jpv@... | Owner: wintert@...=20 Type: defect | Status: closed=20 Priority: trivial | Milestone:=20 Component: rpl | Version:=20 Severity: Active WG Document | Resolution: fixed=20 Keywords: |=20 --------------------------------+--------------------------------------- --------------------------------+---- Changes (by jpv@...): * status: new =3D> closed * resolution: =3D> fixed Comment: The use of Trickle serves to randomize the response to DIS messages. For -05, RPL text is updated to clarify: o When a node receives a multicast DIS message, it MUST reset the trickle timer to the minimum value. o When a node receives a unicast DIS message, it MUST unicast a DIO message in response, and include the DAG Configuration Object. In this case the node SHOULD NOT reset the trickle timer. -- Ticket URL: roll =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll --=_alternative 0052A62586257687_= Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="ISO-8859-1"
Hey Dominique,

+1 for me.  I like it.



<dominique.barthel= @orange-ftgroup.com>
Sent by: roll-bounces@ietf.org

12/09/2009 07:40 AM

To
<roll@ietf.org>, <wintert@a= cm.org>, <jpv@cisco.com>
cc
Subject
Re: [Roll] [roll] #12: DIS




Hello all,

Where there is a high density of nodes/routers, we want to be more selective as to who shall respond to a multicast DIS.
DIS currently has no message body. Would it be possible to have the message body indicate a range of ranks and a maximal link cost for nodes requested to respond ? (default would be a catch all).
It's much better to have to send a few selective DIS'es, lowering the requi= rements as needed, rather than have all neighbors respond irrespective of their quality to becoming a parent/sibling.
And I guess the magic sentence is : there are sensor networks in the field, with millions of devices deployed, that do it today and need it in the future.
Your comments ?
Thanks

Dominique



-----Message d'origine-----
De : roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] De la part de roll issue tracker
Envoy=E9 : jeudi 3 d=E9cembre 2009 15:59
=C0 : wintert@acm.org; jpv@cisco.com
Cc : roll@ietf.org
Objet : Re: [Roll] [roll] #12: DIS

#12: DIS
--------------------------------+---------------------------------------
--------------------------------+----
Reporter:  jpv@...               |        Owner:  wintert@...      <= br>     Type:  defect              |       Status:  closed        
Priority:  trivial             |    Milestone:                
Component:  rpl                 |      Version:                
Severity:  Active WG Document  |   Resolution:  fixed          
Keywords:                      |  
--------------------------------+---------------------------------------
--------------------------------+----
Changes (by jpv@...):

 * status:  new =3D> closed
 * resolution:  =3D> fixed


Comment:

The use of Trickle serves to randomize the response to DIS messages.
  For -05, RPL text is updated to clarify:

  o  When a node receives a multicast DIS message, it MUST reset the
     trickle timer to the minimum value.

  o  When a node receives a unicast DIS message, it MUST unicast a DIO
     message in response, and include the DAG Configuration Object.  In
     this case the node SHOULD NOT reset the trickle timer.=

--
Ticket URL: <http://tools.ietf.org/wg/roll/trac/ticket/12#comment:1><= br> roll <http://tools.ietf.org/wg/roll/>

=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F
Roll mailing list
Roll@ietf.org
https://www.ietf.org/mailman/listinfo/roll
=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F
Roll mailing list
Roll@ietf.org
https://www.ietf.org/mailman/listinfo/roll
--=_alternative 0052A62586257687_=-- From prvs=58760f53d=mukul@uwm.edu Wed Dec 9 07:14:22 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 35D673A67BE for ; Wed, 9 Dec 2009 07:14:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.405 X-Spam-Level: X-Spam-Status: No, score=-1.405 tagged_above=-999 required=5 tests=[AWL=0.279, BAYES_00=-2.599, J_CHICKENPOX_32=0.6, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IU70-G+wCNXN for ; Wed, 9 Dec 2009 07:14:20 -0800 (PST) Received: from ip2mta2.uwm.edu (ip2mta2.uwm.edu [129.89.7.131]) by core3.amsl.com (Postfix) with ESMTP id 8E9EE3A69E7 for ; Wed, 9 Dec 2009 07:14:19 -0800 (PST) Received: from mta03.pantherlink.uwm.edu ([129.89.7.83]) by ip2mta2.uwm.edu with ESMTP; 09 Dec 2009 09:13:56 -0600 Received: from localhost (localhost.localdomain [127.0.0.1]) by mta03.pantherlink.uwm.edu (Postfix) with ESMTP id 3C52EC085D0; Wed, 9 Dec 2009 09:13:56 -0600 (CST) 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 ly3hT5YTtaBy; Wed, 9 Dec 2009 09:13:55 -0600 (CST) Received: from mail02.pantherlink.uwm.edu (mail02.pantherlink.uwm.edu [129.89.7.86]) by mta03.pantherlink.uwm.edu (Postfix) with ESMTP id C04C8C085D3; Wed, 9 Dec 2009 09:13:55 -0600 (CST) Date: Wed, 9 Dec 2009 09:13:55 -0600 (CST) From: Mukul Goyal To: Jerald P Martocci Message-ID: <1169506894.8671601260371635708.JavaMail.root@mail02.pantherlink.uwm.edu> In-Reply-To: <1400987288.8669081260371426738.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.19_GA_3083.RHEL4_64 (ZimbraWebClient - [unknown] (Win)/5.0.19_GA_3083.RHEL4_64) X-Authenticated-User: mukul@uwm.edu Cc: roll@ietf.org Subject: Re: [Roll] [roll] #12: 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, 09 Dec 2009 15:17:53 -0000 Hi Jerry, Dominique, I am not sure if a node, that has just arrived in this world, would know wh= at desired rank range to advertize in its DIS. I really like Pascal's proposal that a trickle style mechanism decides whet= her a node advertises itself as a router or not. Thanks Mukul ----- Original Message ----- From: "Jerald P Martocci" To: "dominique barthel" Cc: roll-bounces@ietf.org, roll@ietf.org Sent: Wednesday, December 9, 2009 9:02:45 AM GMT -06:00 US/Canada Central Subject: Re: [Roll] [roll] #12: DIS Hey Dominique,=20 +1 for me. =C2=A0I like it.=20 =20 Sent by: roll-bounces@ietf.org=20 12/09/2009 07:40 AM =09 To =09, , =20 cc =09 Subject =09Re: [Roll] [roll] #12: DIS=20 =09 Hello all,=20 Where there is a high density of nodes/routers, we want to be more selectiv= e as to who shall respond to a multicast DIS.=20 DIS currently has no message body. Would it be possible to have the message= body indicate a range of ranks and a maximal link cost for nodes requested= to respond ? (default would be a catch all).=20 It's much better to have to send a few selective DIS'es, lowering the requi= rements as needed, rather than have all neighbors respond irrespective of t= heir quality to becoming a parent/sibling.=20 And I guess the magic sentence is : there are sensor networks in the field,= with millions of devices deployed, that do it today and need it in the fut= ure.=20 Your comments ?=20 Thanks=20 Dominique=20 -----Message d'origine-----=20 De : roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] De la part de rol= l issue tracker=20 Envoy=C3=A9 : jeudi 3 d=C3=A9cembre 2009 15:59=20 =C3=80 : wintert@acm.org; jpv@cisco.com=20 Cc : roll@ietf.org=20 Objet : Re: [Roll] [roll] #12: DIS=20 #12: DIS=20 --------------------------------+---------------------------------------=20 --------------------------------+----=20 Reporter: =C2=A0jpv@... =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | = =C2=A0 =C2=A0 =C2=A0 =C2=A0Owner: =C2=A0wintert@... =C2=A0 =C2=A0 =C2=A0=20 =C2=A0 =C2=A0 Type: =C2=A0defect =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0| =C2=A0 =C2=A0 =C2=A0 Status: =C2=A0closed =C2=A0 =C2=A0 =C2=A0 =C2= =A0=20 Priority: =C2=A0trivial =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0 = =C2=A0Milestone: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=20 Component: =C2=A0rpl =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 | =C2=A0 =C2=A0 =C2=A0Version: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0=20 Severity: =C2=A0Active WG Document =C2=A0| =C2=A0 Resolution: =C2=A0fixed = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=20 Keywords: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0| =C2=A0=20 --------------------------------+---------------------------------------=20 --------------------------------+----=20 Changes (by jpv@...):=20 =C2=A0* status: =C2=A0new =3D> closed=20 =C2=A0* resolution: =C2=A0=3D> fixed=20 Comment:=20 The use of Trickle serves to randomize the response to DIS messages.=20 =C2=A0 For -05, RPL text is updated to clarify:=20 =C2=A0 o =C2=A0When a node receives a multicast DIS message, it MUST reset = the=20 =C2=A0 =C2=A0 =C2=A0trickle timer to the minimum value.=20 =C2=A0 o =C2=A0When a node receives a unicast DIS message, it MUST unicast = a DIO=20 =C2=A0 =C2=A0 =C2=A0message in response, and include the DAG Configuration = Object. =C2=A0In=20 =C2=A0 =C2=A0 =C2=A0this case the node SHOULD NOT reset the trickle timer.= =20 --=20 Ticket URL: =20 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 From Jerald.P.Martocci@jci.com Wed Dec 9 07:35:00 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A77A428C12C for ; Wed, 9 Dec 2009 07:35:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.935 X-Spam-Level: X-Spam-Status: No, score=-5.935 tagged_above=-999 required=5 tests=[AWL=-0.252, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_32=0.6, RCVD_IN_DNSWL_MED=-4, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K-z61+47fOuF for ; Wed, 9 Dec 2009 07:34:59 -0800 (PST) Received: from exprod8og109.obsmtp.com (exprod8og109.obsmtp.com [64.18.3.98]) by core3.amsl.com (Postfix) with ESMTP id B899428C125 for ; Wed, 9 Dec 2009 07:34:58 -0800 (PST) Received: from source ([192.132.24.137]) (using SSLv3) by exprod8ob109.postini.com ([64.18.7.12]) with SMTP ID DSNKSx/DlsGQKk/KiBHO0MmgBXxO9NAIBu7N@postini.com; Wed, 09 Dec 2009 07:34:48 PST Received: from jwimkrs1.na.jci.com ([10.10.6.31]) by smtpmke01.jci.com (Lotus Domino Release 8.0.1) with ESMTP id 2009120909360385-6266159 ; Wed, 9 Dec 2009 09:36:03 -0600 In-Reply-To: <1169506894.8671601260371635708.JavaMail.root@mail02.pantherlink.uwm.edu> MIME-Version: 1.0 To: Mukul Goyal X-Mailer: Lotus Notes Release 6.5.2 June 01, 2004 From: Jerald.P.Martocci@jci.com Message-ID: Date: Wed, 9 Dec 2009 09:34:38 -0600 X-MIMETrack: Serialize by Router on jwimkrs1.na.jci.com/NA/Johnson_Controls at 12/09/2009 09:34:45 AM, Serialize complete at 12/09/2009 09:34:45 AM, Itemize by SMTP Server on smtpmke01.jci.com/JCI_SMTP(Release 8.0.1|February 07, 2008) at 12/09/2009 09:36:03 AM, Serialize by Router on smtpmke01.jci.com/JCI_SMTP(Release 8.0.1|February 07, 2008) at 12/09/2009 09:36:06 AM, Serialize complete at 12/09/2009 09:36:06 AM Content-Type: multipart/alternative; boundary="=_alternative 005591AB86257687_=" Cc: roll@ietf.org Subject: Re: [Roll] [roll] #12: 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, 09 Dec 2009 15:35:00 -0000 This is a multipart message in MIME format. --=_alternative 005591AB86257687_= Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="ISO-8859-1" Agreed. A newborn wouldn't know and hence would solicit without any range = parameters set. However, once the node is established in the DAG and=20 wants to better its rank, why would it want responses from neighbor nodes=20 that a already are at a lower rank. Mukul Goyal =20 12/09/2009 09:14 AM To Jerald P Martocci cc roll@ietf.org, dominique barthel Subject Re: [Roll] [roll] #12: DIS Hi Jerry, Dominique, I am not sure if a node, that has just arrived in this world, would know=20 what desired rank range to advertize in its DIS. I really like Pascal's proposal that a trickle style mechanism decides=20 whether a node advertises itself as a router or not. Thanks Mukul ----- Original Message ----- From: "Jerald P Martocci" To: "dominique barthel" Cc: roll-bounces@ietf.org, roll@ietf.org Sent: Wednesday, December 9, 2009 9:02:45 AM GMT -06:00 US/Canada Central Subject: Re: [Roll] [roll] #12: DIS Hey Dominique,=20 +1 for me. I like it.=20 =20 Sent by: roll-bounces@ietf.org=20 12/09/2009 07:40 AM=20 To , , =20 cc=20 Subject Re: [Roll] [roll] #12: DIS=20 =20 Hello all,=20 Where there is a high density of nodes/routers, we want to be more=20 selective as to who shall respond to a multicast DIS.=20 DIS currently has no message body. Would it be possible to have the=20 message body indicate a range of ranks and a maximal link cost for nodes=20 requested to respond ? (default would be a catch all).=20 It's much better to have to send a few selective DIS'es, lowering the=20 requirements as needed, rather than have all neighbors respond=20 irrespective of their quality to becoming a parent/sibling.=20 And I guess the magic sentence is : there are sensor networks in the=20 field, with millions of devices deployed, that do it today and need it in=20 the future.=20 Your comments ?=20 Thanks=20 Dominique=20 -----Message d'origine-----=20 De : roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] De la part de=20 roll issue tracker=20 Envoy=E9 : jeudi 3 d=E9cembre 2009 15:59=20 =C0 : wintert@acm.org; jpv@cisco.com=20 Cc : roll@ietf.org=20 Objet : Re: [Roll] [roll] #12: DIS=20 #12: DIS=20 --------------------------------+---------------------------------------=20 --------------------------------+----=20 Reporter: jpv@... | Owner: wintert@... =20 Type: defect | Status: closed =20 Priority: trivial | Milestone: =20 Component: rpl | Version: =20 Severity: Active WG Document | Resolution: fixed =20 Keywords: | =20 --------------------------------+---------------------------------------=20 --------------------------------+----=20 Changes (by jpv@...):=20 * status: new =3D> closed=20 * resolution: =3D> fixed=20 Comment:=20 The use of Trickle serves to randomize the response to DIS messages.=20 For -05, RPL text is updated to clarify:=20 o When a node receives a multicast DIS message, it MUST reset the=20 trickle timer to the minimum value.=20 o When a node receives a unicast DIS message, it MUST unicast a DIO=20 message in response, and include the DAG Configuration Object. In=20 this case the node SHOULD NOT reset the trickle timer.=20 --=20 Ticket URL: =20 roll =20 =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=20 Roll mailing list=20 Roll@ietf.org=20 https://www.ietf.org/mailman/listinfo/roll=20 =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=20 Roll mailing list=20 Roll@ietf.org=20 https://www.ietf.org/mailman/listinfo/roll=20 =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll --=_alternative 005591AB86257687_= Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="ISO-8859-1"
Agreed.  A newborn wouldn't know and hence would solicit without any range parameters set.  However, once the node is established in the DAG and wants to better its rank, why would it want responses from neighbor nodes that a already are at a lower rank.






Mukul Goyal <mukul= @uwm.edu>

12/09/2009 09:14 AM

To
Jerald P Martocci <Jerald.P.Marto= cci@jci.com>
cc
roll@ietf.org, dominique barthel <= ;dominique.barthel@orange-ftgroup.com>
Subject
Re: [Roll] [roll] #12: DIS




Hi Jerry, Dominique,

I am not sure if a node, that has just arrived in this world, would know what desired rank range to advertize in its DIS.

I really like Pascal's proposal that a trickle style mechanism decides whether a node advertises itself as a router or not.

Thanks
Mukul

----- Original Message -----
From: "Jerald P Martocci" <Jerald.P.Martocci@jci.com>
To: "dominique barthel" <dominique.barthel@orange-ftgroup.com&= gt;
Cc: roll-bounces@ietf.org, roll@ietf.org
Sent: Wednesday, December 9, 2009 9:02:45 AM GMT -06:00 US/Canada Central Subject: Re: [Roll] [roll] #12: DIS



Hey Dominique,

+1 for me.  I like it.



<dominique.barthel@orange-ftgroup.com>
Sent by: roll-bounces@ietf.org

12/09/2009 07:40 AM                  
To                  <roll@i= etf.org>, <wintert@acm.org>, <jpv@cisco.com>

cc                  

Subject                  Re: [Roll] [roll] #12: DIS
               



Hello all,

Where there is a high density of nodes/routers, we want to be more selective as to who shall respond to a multicast DIS.
DIS currently has no message body. Would it be possible to have the message body indicate a range of ranks and a maximal link cost for nodes requested to respond ? (default would be a catch all).
It's much better to have to send a few selective DIS'es, lowering the requi= rements as needed, rather than have all neighbors respond irrespective of their quality to becoming a parent/sibling.
And I guess the magic sentence is : there are sensor networks in the field, with millions of devices deployed, that do it today and need it in the future.
Your comments ?
Thanks

Dominique



-----Message d'origine-----
De : roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] De la part de roll issue tracker
Envoy=E9 : jeudi 3 d=E9cembre 2009 15:59
=C0 : wintert@acm.org; jpv@cisco.com
Cc : roll@ietf.org
Objet : Re: [Roll] [roll] #12: DIS

#12: DIS
--------------------------------+---------------------------------------
--------------------------------+----
Reporter:  jpv@...               |        Owner:  wintert@...      
    Type:  defect              |       Status:  closed        
Priority:  trivial             |    Milestone:                
Component:  rpl                 |      Version:                
Severity:  Active WG Document  |   Resolution:  fixed          
Keywords:                      |  
--------------------------------+---------------------------------------
--------------------------------+----
Changes (by jpv@...):

 * status:  new =3D> closed
 * resolution:  =3D> fixed


Comment:

The use of Trickle serves to randomize the response to DIS messages.
  For -05, RPL text is updated to clarify:

  o  When a node receives a multicast DIS message, it MUST reset the
     trickle timer to the minimum value.

  o  When a node receives a unicast DIS message, it MUST unicast a DIO
     message in response, and include the DAG Configuration Object.  In
     this case the node SHOULD NOT reset the trickle timer.

--
Ticket URL: <http://tools.ietf.org/wg/roll/trac/ticket/12#comment:1>
roll <http://tools.ietf.org/wg/roll/>

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


=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F
Roll mailing list
Roll@ietf.org
https://www.ietf.org/mailman/listinfo/roll
--=_alternative 005591AB86257687_=-- From Peter.Siklosi@tritech.se Wed Dec 9 07:36:44 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3A7FF28C12F for ; Wed, 9 Dec 2009 07:36:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.759 X-Spam-Level: X-Spam-Status: No, score=-0.759 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XwOmVPjCK12n for ; Wed, 9 Dec 2009 07:36:41 -0800 (PST) Received: from tritech.se (tritech.se [91.191.137.61]) by core3.amsl.com (Postfix) with ESMTP id 6BCD128C12C for ; Wed, 9 Dec 2009 07:36:41 -0800 (PST) Received: from srvsund01.tritech.se (srvsund01.tritech.se [10.75.60.4]) by tritech.se (8.14.3/8.14.3) with ESMTP id nB9FaT78005934 for ; Wed, 9 Dec 2009 16:36:29 +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_01CA78E5.6042EDC3" Date: Wed, 9 Dec 2009 16:36:26 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: packet size issues Thread-Index: Acp45V6QqxFBG5r0QduM5QO82XwsUA== From: "Peter Siklosi" To: X-CT-RefID: str=0001.0A3C0009.4B1FC3F6.006B,ss=1,fgs=0 Subject: [Roll] packet size issues X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 09 Dec 2009 15:36:44 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA78E5.6042EDC3 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, =20 If I understand correctly, RPL is designed to be usable with for instance 6LoWPAN on 802.15.4 with very limiting frame sizes. Even if 1280 byte IPv6 packets are of course supported using fragmentation, large packets should be avoided at all cost given the low bandwidth and low packet delivery success rate. =20 Given this, I do not understand the alignment requirements specified in draft-ietf-roll-rpl-05 6.1.3.1.1.1 "Following the convention in IPv6, these options are aligned in a packet such that multi-octet values within the Option Data field of each option fall on natural boundaries". It seems that it would be more important to keep the messages short and avoid padding options. I am also curious on allocating 16 bits for a length field of a sub option. If sub option length exceeding 255 bytes (as could be specified by 8 bits) are needed, it seems that the routing messages are expected to get very large. =20 Regards, Peter Siklosi =20 ------_=_NextPart_001_01CA78E5.6042EDC3 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi all,

 

If I understand correctly, RPL = is designed to be usable with for instance 6LoWPAN on 802.15.4 with very limiting = frame sizes. Even if 1280 byte IPv6 packets are of course supported using = fragmentation, large packets should be avoided at all cost given the low bandwidth and = low packet delivery success rate.

 

Given this, I do not understand = the alignment requirements specified in draft-ietf-roll-rpl-05 6.1.3.1.1.1 = “Following the convention in IPv6, these options are aligned in a packet such that multi-octet values within the Option Data field of each option fall on = natural boundaries”. It seems that it would be more important to keep the = messages short and avoid padding options. I am also curious on allocating 16 bits = for a length field of a sub option. If sub option length exceeding 255 bytes = (as could be specified by 8 bits) are needed, it seems that the routing = messages are expected to get very large.

 

Regards,
Peter Siklosi

 

------_=_NextPart_001_01CA78E5.6042EDC3-- From prvs=58760f53d=mukul@uwm.edu Wed Dec 9 07:58:27 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3591128C133 for ; Wed, 9 Dec 2009 07:58:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.627 X-Spam-Level: X-Spam-Status: No, score=-1.627 tagged_above=-999 required=5 tests=[AWL=0.057, BAYES_00=-2.599, J_CHICKENPOX_32=0.6, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GPOhDHv+dURS for ; Wed, 9 Dec 2009 07:58:26 -0800 (PST) Received: from ip1mta2.uwm.edu (ip1mta2.uwm.edu [129.89.7.130]) by core3.amsl.com (Postfix) with ESMTP id F126728C132 for ; Wed, 9 Dec 2009 07:58:25 -0800 (PST) Received: from mta03.pantherlink.uwm.edu ([129.89.7.83]) by ip1mta2.uwm.edu with ESMTP; 09 Dec 2009 09:58:13 -0600 Received: from localhost (localhost.localdomain [127.0.0.1]) by mta03.pantherlink.uwm.edu (Postfix) with ESMTP id D3B73C085D8; Wed, 9 Dec 2009 09:58:12 -0600 (CST) 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 1jiKyk-5ky2l; Wed, 9 Dec 2009 09:58:12 -0600 (CST) Received: from mail02.pantherlink.uwm.edu (mail02.pantherlink.uwm.edu [129.89.7.86]) by mta03.pantherlink.uwm.edu (Postfix) with ESMTP id 047A1C085A0; Wed, 9 Dec 2009 09:58:12 -0600 (CST) Date: Wed, 9 Dec 2009 09:58:11 -0600 (CST) From: Mukul Goyal To: Jerald P Martocci Message-ID: <2121280537.8701351260374291900.JavaMail.root@mail02.pantherlink.uwm.edu> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Originating-IP: [129.89.7.91] X-Mailer: Zimbra 5.0.19_GA_3083.RHEL4_64 (ZimbraWebClient - [unknown] (Win)/5.0.19_GA_3083.RHEL4_64) X-Authenticated-User: mukul@uwm.edu Cc: roll@ietf.org Subject: Re: [Roll] [roll] #12: 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, 09 Dec 2009 15:58:27 -0000 Yes, in that case, it makes sense to specify a rank range in the DIS. Thanks Mukul ----- Original Message ----- From: "Jerald P Martocci" To: "Mukul Goyal" Cc: "dominique barthel" , roll@ietf.o= rg Sent: Wednesday, December 9, 2009 9:34:38 AM GMT -06:00 US/Canada Central Subject: Re: [Roll] [roll] #12: DIS Agreed. =C2=A0A newborn wouldn't know and hence would solicit without any r= ange parameters set. =C2=A0However, once the node is established in the DAG= and wants to better its rank, why would it want responses from neighbor no= des that a already are at a lower rank.=20 Mukul Goyal =20 12/09/2009 09:14 AM =09 To =09Jerald P Martocci =20 cc =09roll@ietf.org, dominique barthel =20 Subject =09Re: [Roll] [roll] #12: DIS=20 =09 Hi Jerry, Dominique,=20 I am not sure if a node, that has just arrived in this world, would know wh= at desired rank range to advertize in its DIS.=20 I really like Pascal's proposal that a trickle style mechanism decides whet= her a node advertises itself as a router or not.=20 Thanks=20 Mukul=20 ----- Original Message -----=20 From: "Jerald P Martocci" =20 To: "dominique barthel" =20 Cc: roll-bounces@ietf.org, roll@ietf.org=20 Sent: Wednesday, December 9, 2009 9:02:45 AM GMT -06:00 US/Canada Central= =20 Subject: Re: [Roll] [roll] #12: DIS=20 Hey Dominique,=20 +1 for me. =C2=A0I like it.=20 =20 Sent by: roll-bounces@ietf.org=20 12/09/2009 07:40 AM =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0=20 To =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0, , =20 cc =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=20 Subject =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Re: [= Roll] [roll] #12: DIS=20 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=20 Hello all,=20 Where there is a high density of nodes/routers, we want to be more selectiv= e as to who shall respond to a multicast DIS.=20 DIS currently has no message body. Would it be possible to have the message= body indicate a range of ranks and a maximal link cost for nodes requested= to respond ? (default would be a catch all).=20 It's much better to have to send a few selective DIS'es, lowering the requi= rements as needed, rather than have all neighbors respond irrespective of t= heir quality to becoming a parent/sibling.=20 And I guess the magic sentence is : there are sensor networks in the field,= with millions of devices deployed, that do it today and need it in the fut= ure.=20 Your comments ?=20 Thanks=20 Dominique=20 -----Message d'origine-----=20 De : roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] De la part de rol= l issue tracker=20 Envoy=C3=A9 : jeudi 3 d=C3=A9cembre 2009 15:59=20 =C3=80 : wintert@acm.org; jpv@cisco.com=20 Cc : roll@ietf.org=20 Objet : Re: [Roll] [roll] #12: DIS=20 #12: DIS=20 --------------------------------+---------------------------------------=20 --------------------------------+----=20 Reporter: =C2=A0jpv@... =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | = =C2=A0 =C2=A0 =C2=A0 =C2=A0Owner: =C2=A0wintert@... =C2=A0 =C2=A0 =C2=A0=20 =C2=A0 =C2=A0 Type: =C2=A0defect =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0| =C2=A0 =C2=A0 =C2=A0 Status: =C2=A0closed =C2=A0 =C2=A0 =C2=A0 =C2= =A0=20 Priority: =C2=A0trivial =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0 = =C2=A0Milestone: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=20 Component: =C2=A0rpl =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 | =C2=A0 =C2=A0 =C2=A0Version: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0=20 Severity: =C2=A0Active WG Document =C2=A0| =C2=A0 Resolution: =C2=A0fixed = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=20 Keywords: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0| =C2=A0=20 --------------------------------+---------------------------------------=20 --------------------------------+----=20 Changes (by jpv@...):=20 =C2=A0* status: =C2=A0new =3D> closed=20 =C2=A0* resolution: =C2=A0=3D> fixed=20 Comment:=20 The use of Trickle serves to randomize the response to DIS messages.=20 =C2=A0 For -05, RPL text is updated to clarify:=20 =C2=A0 o =C2=A0When a node receives a multicast DIS message, it MUST reset = the=20 =C2=A0 =C2=A0 =C2=A0trickle timer to the minimum value.=20 =C2=A0 o =C2=A0When a node receives a unicast DIS message, it MUST unicast = a DIO=20 =C2=A0 =C2=A0 =C2=A0message in response, and include the DAG Configuration = Object. =C2=A0In=20 =C2=A0 =C2=A0 =C2=A0this case the node SHOULD NOT reset the trickle timer.= =20 --=20 Ticket URL: =20 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 joakime@sics.se Wed Dec 9 09:26:46 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BEDE928C13F for ; Wed, 9 Dec 2009 09:26:46 -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 RaVBimTKwZoh for ; Wed, 9 Dec 2009 09:26:46 -0800 (PST) Received: from proxy3.bredband.net (proxy3.bredband.net [195.54.101.73]) by core3.amsl.com (Postfix) with ESMTP id C2A313A659B for ; Wed, 9 Dec 2009 09:26:45 -0800 (PST) Received: from ipb1.telenor.se (195.54.127.164) by proxy3.bredband.net (7.3.140.3) id 4AD3E1BA01869119 for roll@ietf.org; Wed, 9 Dec 2009 18:26:33 +0100 X-SMTPAUTH-B2: X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Am4aADtsH0tV5B4RPGdsb2JhbAAImHuCUwEBAQE3u26ELASBYg X-IronPort-AV: E=Sophos;i="4.47,369,1257116400"; d="scan'208";a="13420804" Received: from c-111ee455.013-276-73746f7.cust.bredbandsbolaget.se (HELO [127.0.0.1]) ([85.228.30.17]) by ipb1.telenor.se with ESMTP; 09 Dec 2009 18:26:33 +0100 Message-ID: <4B1FDDC8.7030001@sics.se> Date: Wed, 09 Dec 2009 18:26:32 +0100 From: Joakim Eriksson User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Peter Siklosi References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: roll@ietf.org Subject: Re: [Roll] packet size issues X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 09 Dec 2009 17:26:46 -0000 Hi Peter, I totally agree on the goal of minimizing packet sizes, but I would like to keep alignment requirements since it simplifies implementations. I also think (as you mention) that we need to question the 16-bit sub-option length. Is it really needed? Both IPv6 options and ICMPv6 option lenghts are encoded as 8-bit values. Going down to 8-bits would also help the alignment of the options. Best Regards, -- Joakim Eriksson, SICS Peter Siklosi skrev: > Hi all, > > > > If I understand correctly, RPL is designed to be usable with for > instance 6LoWPAN on 802.15.4 with very limiting frame sizes. Even if > 1280 byte IPv6 packets are of course supported using fragmentation, > large packets should be avoided at all cost given the low bandwidth and > low packet delivery success rate. > > > > Given this, I do not understand the alignment requirements specified in > draft-ietf-roll-rpl-05 6.1.3.1.1.1 “Following the convention in IPv6, > these options are aligned in a packet such that multi-octet values > within the Option Data field of each option fall on natural boundaries”. > It seems that it would be more important to keep the messages short and > avoid padding options. I am also curious on allocating 16 bits for a > length field of a sub option. If sub option length exceeding 255 bytes > (as could be specified by 8 bits) are needed, it seems that the routing > messages are expected to get very large. > > > > Regards, > Peter Siklosi > > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From wintert@acm.org Wed Dec 9 15:34:53 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 755423A67EB for ; Wed, 9 Dec 2009 15:34:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.598 X-Spam-Level: X-Spam-Status: No, score=-102.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d5JiKiI2pQOL for ; Wed, 9 Dec 2009 15:34:52 -0800 (PST) Received: from smtp103.prem.mail.ac4.yahoo.com (smtp103.prem.mail.ac4.yahoo.com [76.13.13.42]) by core3.amsl.com (Postfix) with SMTP id 46EFA3A63EB for ; Wed, 9 Dec 2009 15:34:52 -0800 (PST) Received: (qmail 32833 invoked from network); 9 Dec 2009 23:34:36 -0000 Received: from 206-83-249-194.edurostream.com (wintert@206.83.249.194 with plain) by smtp103.prem.mail.ac4.yahoo.com with SMTP; 09 Dec 2009 15:34:36 -0800 PST X-Yahoo-SMTP: 30iEHGKswBCbca_Y5pX7d6RVQMoT5Mk- X-YMail-OSG: IBdPCPEVM1lEnbbZVaaUwBvihuOM4JHc190tiEp96vS5EZmVs_DRXbL0q4QHOHq7fg9mowai0NysrYACRp1G1CYQhZ3BgoMVzkJdBuXcs_YG5poOMnzAk3AXqbMz1Iuc4j9iLjpovEVCjsuvD0QL69QZBwdoLKSl56zXqWy8xX9JqyMIVmkHCfsINcmP5q5vSvwRCfMAZHDKCzH9324zM2pUopDFixoALjMeGkKPZlLlqifxNArPmT_CPEbkkPZhZISoCoBWhWD5_4iUBgcMKK8VCXC17shfJa8p8Q_ifgACuBgdroeh4.4ywhzDJ_KcoLS3XM2HX0wgk.on7nUi X-Yahoo-Newman-Property: ymail-3 Message-ID: <4B203410.4030102@acm.org> Date: Wed, 09 Dec 2009 18:34:40 -0500 From: Tim Winter User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: roll@ietf.org References: <4B1FDDC8.7030001@sics.se> In-Reply-To: <4B1FDDC8.7030001@sics.se> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Subject: Re: [Roll] packet size issues X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 09 Dec 2009 23:34:53 -0000 I agree with Peter that we should consider to remove alignment requirements- including the Pad1 and PadN options. I would expect that it is often cheaper (energy/time/processing) to handle the alignment issues in the implementation versus transporting extra padding over LLN links. The 16-bit sub-option length is driven by the DAG Metric Container. Perhaps once we begin to see some proposed objective functions we can better determine how large the Metric Container may need to be. Perhaps the DAG Metric Container could be chained such that each piece fits into 255 bytes or less... -Tim Joakim Eriksson wrote: > Hi Peter, > > I totally agree on the goal of minimizing packet sizes, but I would > like to keep alignment requirements since it simplifies implementations. > I also think (as you mention) that we need to question the 16-bit > sub-option length. Is it really needed? Both IPv6 options and ICMPv6 > option lenghts are encoded as 8-bit values. Going down to 8-bits would > also help the alignment of the options. > > > Best Regards, > -- Joakim Eriksson, SICS > > Peter Siklosi skrev: >> Hi all, >> >> >> >> If I understand correctly, RPL is designed to be usable with for >> instance 6LoWPAN on 802.15.4 with very limiting frame sizes. Even if >> 1280 byte IPv6 packets are of course supported using fragmentation, >> large packets should be avoided at all cost given the low bandwidth >> and low packet delivery success rate. >> >> >> >> Given this, I do not understand the alignment requirements specified >> in draft-ietf-roll-rpl-05 6.1.3.1.1.1 “Following the convention in >> IPv6, these options are aligned in a packet such that multi-octet >> values within the Option Data field of each option fall on natural >> boundaries”. It seems that it would be more important to keep the >> messages short and avoid padding options. I am also curious on >> allocating 16 bits for a length field of a sub option. If sub option >> length exceeding 255 bytes (as could be specified by 8 bits) are >> needed, it seems that the routing messages are expected to get very >> large. >> >> >> >> Regards, >> Peter Siklosi >> >> >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> Roll mailing 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 Dec 9 16:10:07 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7E5C828C0E7 for ; Wed, 9 Dec 2009 16:10:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.759 X-Spam-Level: X-Spam-Status: No, score=-1.759 tagged_above=-999 required=5 tests=[AWL=0.490, 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 CbpZel-hAQ8M for ; Wed, 9 Dec 2009 16:10:05 -0800 (PST) Received: from smtp5-g21.free.fr (smtp5-g21.free.fr [212.27.42.5]) by core3.amsl.com (Postfix) with ESMTP id 5B44B3A6AF2 for ; Wed, 9 Dec 2009 16:10:02 -0800 (PST) Received: from smtp5-g21.free.fr (localhost [127.0.0.1]) by smtp5-g21.free.fr (Postfix) with ESMTP id 3686ED4804E; Thu, 10 Dec 2009 01:09:47 +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 E990CD48076; Thu, 10 Dec 2009 01:09:36 +0100 (CET) Message-ID: <4B203C37.90207@gmail.com> Date: Thu, 10 Dec 2009 01:09:27 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Tim Winter References: <4B1FDDC8.7030001@sics.se> <4B203410.4030102@acm.org> In-Reply-To: <4B203410.4030102@acm.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 091209-1, 09/12/2009), Outbound message X-Antivirus-Status: Clean Cc: roll@ietf.org Subject: Re: [Roll] packet size issues X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 10 Dec 2009 00:10:07 -0000 Tim Winter a écrit : > I agree with Peter that we should consider to remove alignment requirements- > including the Pad1 and PadN options. I disagree. I suggest to keep them. The reason is because an IP stack uses them already - why removing them? Alex > I would expect that it is often cheaper > (energy/time/processing) to handle the alignment issues in the implementation versus > transporting extra padding over LLN links. > > The 16-bit sub-option length is driven by the DAG Metric Container. Perhaps once we > begin to see some proposed objective functions we can better determine how large the > Metric Container may need to be. Perhaps the DAG Metric Container could be chained > such that each piece fits into 255 bytes or less... > > -Tim > > > Joakim Eriksson wrote: >> Hi Peter, >> >> I totally agree on the goal of minimizing packet sizes, but I would >> like to keep alignment requirements since it simplifies implementations. >> I also think (as you mention) that we need to question the 16-bit >> sub-option length. Is it really needed? Both IPv6 options and ICMPv6 >> option lenghts are encoded as 8-bit values. Going down to 8-bits would >> also help the alignment of the options. >> >> >> Best Regards, >> -- Joakim Eriksson, SICS >> >> Peter Siklosi skrev: >>> Hi all, >>> >>> >>> >>> If I understand correctly, RPL is designed to be usable with for >>> instance 6LoWPAN on 802.15.4 with very limiting frame sizes. Even if >>> 1280 byte IPv6 packets are of course supported using fragmentation, >>> large packets should be avoided at all cost given the low bandwidth >>> and low packet delivery success rate. >>> >>> >>> >>> Given this, I do not understand the alignment requirements specified >>> in draft-ietf-roll-rpl-05 6.1.3.1.1.1 “Following the convention in >>> IPv6, these options are aligned in a packet such that multi-octet >>> values within the Option Data field of each option fall on natural >>> boundaries”. It seems that it would be more important to keep the >>> messages short and avoid padding options. I am also curious on >>> allocating 16 bits for a length field of a sub option. If sub option >>> length exceeding 255 bytes (as could be specified by 8 bits) are >>> needed, it seems that the routing messages are expected to get very >>> large. >>> >>> >>> >>> Regards, >>> Peter Siklosi >>> >>> >>> >>> >>> ------------------------------------------------------------------------ >>> >>> _______________________________________________ >>> Roll mailing list >>> Roll@ietf.org >>> https://www.ietf.org/mailman/listinfo/roll >> _______________________________________________ >> Roll mailing 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 Dec 9 17:05:35 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 74F4D3A6891 for ; Wed, 9 Dec 2009 17:05:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.684 X-Spam-Level: X-Spam-Status: No, score=-5.684 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_32=0.6, RCVD_IN_DNSWL_MED=-4, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yT9DX69utRQC for ; Wed, 9 Dec 2009 17:05:31 -0800 (PST) Received: from cs-smtp-1.Stanford.EDU (cs-smtp-1.Stanford.EDU [171.64.64.25]) by core3.amsl.com (Postfix) with ESMTP id 27D773A6803 for ; Wed, 9 Dec 2009 17:05:29 -0800 (PST) Received: from adsl-76-252-223-227.dsl.pltn13.sbcglobal.net ([76.252.223.227] helo=[192.168.1.106]) by cs-smtp-1.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1NIXT3-0005hO-Bu; Wed, 09 Dec 2009 17:05:17 -0800 Message-Id: <00F8662F-4B69-41D9-BA83-7AC7580DE7D8@cs.stanford.edu> From: Philip Levis To: In-Reply-To: <8E09C72DBC577D489F13A71228C0B7BFB66EE2@ftrdmel0.rd.francetelecom.fr> 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, 9 Dec 2009 17:05:21 -0800 References: <055.c2df21e47095fbec7400989f77132d30@tools.ietf.org> <064.a0debcb7f3f3224fe1dd2f980dbfac72@tools.ietf.org> <8E09C72DBC577D489F13A71228C0B7BFB66EE2@ftrdmel0.rd.francetelecom.fr> X-Mailer: Apple Mail (2.936) X-Scan-Signature: a11a15d02c0ec4233875b3872b0caebb Cc: roll@ietf.org Subject: Re: [Roll] [roll] #12: 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: Thu, 10 Dec 2009 01:05:35 -0000 On Dec 9, 2009, at 5:37 AM, wrote: > Hello all, > > Where there is a high density of nodes/routers, we want to be more > selective as to who shall respond to a multicast DIS. > DIS currently has no message body. Would it be possible to have the > message body indicate a range of ranks and a maximal link cost for > nodes requested to respond ? (default would be a catch all). > It's much better to have to send a few selective DIS'es, lowering > the requirements as needed, rather than have all neighbors respond > irrespective of their quality to becoming a parent/sibling. > And I guess the magic sentence is : there are sensor networks in the > field, with millions of devices deployed, that do it today and need > it in the future. Is the concern subselecting who might answer a DIS, reducing the number of potential replies, or both? Barring very aberrant topologies, the Ranks of neighbors are unlikely to be from a large range. This is a proposed mechanism: what is its goal? Phil From Peter.Siklosi@tritech.se Wed Dec 9 23:15:18 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D736F3A6A63 for ; Wed, 9 Dec 2009 23:15:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.504 X-Spam-Level: X-Spam-Status: No, score=-1.504 tagged_above=-999 required=5 tests=[AWL=0.745, 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 pGlkzTK0xgRd for ; Wed, 9 Dec 2009 23:15:16 -0800 (PST) Received: from tritech.se (tritech.se [91.191.137.61]) by core3.amsl.com (Postfix) with ESMTP id 1838E3A6A79 for ; Wed, 9 Dec 2009 23:15:15 -0800 (PST) Received: from srvsund01.tritech.se (srvsund01.tritech.se [10.75.60.4]) by tritech.se (8.14.3/8.14.3) with ESMTP id nBA7F2F5010390; Thu, 10 Dec 2009 08:15: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="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 10 Dec 2009 08:14:59 +0100 Message-ID: In-Reply-To: <4B203C37.90207@gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] packet size issues Thread-Index: Acp5LSCacKj2bcl9TTyhV+J2JlApBQAOB2YA References: <4B1FDDC8.7030001@sics.se><4B203410.4030102@acm.org> <4B203C37.90207@gmail.com> From: "Peter Siklosi" To: "Alexandru Petrescu" X-CT-RefID: str=0001.0A3C0009.4B209FEF.006E,ss=1,fgs=0 Cc: roll@ietf.org Subject: Re: [Roll] packet size issues X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 10 Dec 2009 07:15:19 -0000 Alex, Short answer, the reason to remove them is that they waste valuable = space. I think it may be a challenge in the first place to get the = messages short enough that it would work reasonably well in a real = system where the radio environment is less than optimal. Messages should = preferably travel unfragmented, or else as very few fragments, and this = does certainly not leave many bytes for say LoWPAN over 802.15.4. I do not see so much focus in the draft on making the representations = compact, which I think is actually quite important. Padding makes the = situation worse, not better. While simplifying implementations is a good = thing, I think this is less important, we cannot waste bytes for this = reason (running uncompressed IPv6 instead of applying LoWPAN compression = would also make implementations easier..). The same goes for = representation of IP addresses. They need to be compressed. If used on = LoWPAN, I assume that context based compression would be a common case, = since I assume that routing would typically be used within a subnet = sharing the same prefix. Regards, Peter -----Ursprungligt meddelande----- Fr=E5n: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] F=F6r = Alexandru Petrescu Skickat: den 10 december 2009 01:09 Till: Tim Winter Kopia: roll@ietf.org =C4mne: Re: [Roll] packet size issues Tim Winter a =E9crit : > I agree with Peter that we should consider to remove alignment = requirements- > including the Pad1 and PadN options. I disagree. I suggest to keep them. The reason is because an IP stack uses them already - why removing them? Alex > I would expect that it is often cheaper > (energy/time/processing) to handle the alignment issues in the = implementation versus > transporting extra padding over LLN links. >=20 > The 16-bit sub-option length is driven by the DAG Metric Container. = Perhaps once we > begin to see some proposed objective functions we can better determine = how large the > Metric Container may need to be. Perhaps the DAG Metric Container = could be chained > such that each piece fits into 255 bytes or less... >=20 > -Tim >=20 >=20 > Joakim Eriksson wrote: >> Hi Peter, >> >> I totally agree on the goal of minimizing packet sizes, but I would >> like to keep alignment requirements since it simplifies = implementations. >> I also think (as you mention) that we need to question the 16-bit >> sub-option length. Is it really needed? Both IPv6 options and ICMPv6 >> option lenghts are encoded as 8-bit values. Going down to 8-bits = would >> also help the alignment of the options. >> >> >> Best Regards, >> -- Joakim Eriksson, SICS >> >> Peter Siklosi skrev: >>> Hi all, >>> >>> =20 >>> >>> If I understand correctly, RPL is designed to be usable with for >>> instance 6LoWPAN on 802.15.4 with very limiting frame sizes. Even if >>> 1280 byte IPv6 packets are of course supported using fragmentation, >>> large packets should be avoided at all cost given the low bandwidth >>> and low packet delivery success rate. >>> >>> =20 >>> >>> Given this, I do not understand the alignment requirements specified >>> in draft-ietf-roll-rpl-05 6.1.3.1.1.1 "Following the convention in >>> IPv6, these options are aligned in a packet such that multi-octet >>> values within the Option Data field of each option fall on natural >>> boundaries". It seems that it would be more important to keep the >>> messages short and avoid padding options. I am also curious on >>> allocating 16 bits for a length field of a sub option. If sub option >>> length exceeding 255 bytes (as could be specified by 8 bits) are >>> needed, it seems that the routing messages are expected to get very >>> large. >>> >>> =20 >>> >>> Regards, >>> Peter Siklosi >>> >>> =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 _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From Matteo.Paris@ember.com Thu Dec 10 08:03:45 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 87CCE3A69F8 for ; Thu, 10 Dec 2009 08:03:45 -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 7PO9Lec72NdF for ; Thu, 10 Dec 2009 08:03:44 -0800 (PST) Received: from EMPIRE.hq.ember.com (mail.ember.com [74.10.175.227]) by core3.amsl.com (Postfix) with ESMTP id 4DE943A6AB7 for ; Thu, 10 Dec 2009 08:03:44 -0800 (PST) Received: from [192.168.1.102] ([192.168.81.83]) by EMPIRE.hq.ember.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 10 Dec 2009 11:05:18 -0500 Mime-Version: 1.0 Message-Id: In-Reply-To: <4B203410.4030102@acm.org> References: <4B1FDDC8.7030001@sics.se> <4B203410.4030102@acm.org> Date: Thu, 10 Dec 2009 11:03:30 -0500 To: roll@ietf.org From: Matteo Paris Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-OriginalArrivalTime: 10 Dec 2009 16:05:18.0414 (UTC) FILETIME=[91681EE0:01CA79B2] Subject: Re: [Roll] packet size issues X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 10 Dec 2009 16:03:45 -0000 I agree that we should remove alignment requirements and reduce the suboption length field to 1 byte. As Peter wrote, if RPL is to work over constrained link layers, we have to keep in mind the frame size and bandwidth constraints of those layers. For example, in 802.15.4 after link-layer overhead, the usable payload is only 81 bytes (see RFC4944). Because limited bandwidth and large dense networks are a common use case, it is desirable for a DIO message to fit in a single packet. The current size of a DIO message not including the DAG Metric Container is already 59 bytes (3 6lowpan ip header + 4 icmp header + 20 base option + 25 dest prefix + 7 dag config). Padding could increase this by tens of bytes. If the DAG Metric Container is longer than 255 bytes I think it will pose serious challenges to RPL operation over constrained link layers. Matteo At 6:34 PM -0500 12/9/09, Tim Winter wrote: >I agree with Peter that we should consider to remove alignment requirements- >including the Pad1 and PadN options. I would expect that it is often cheaper >(energy/time/processing) to handle the alignment issues in the >implementation versus >transporting extra padding over LLN links. > >The 16-bit sub-option length is driven by the DAG Metric Container. >Perhaps once we >begin to see some proposed objective functions we can better >determine how large the >Metric Container may need to be. Perhaps the DAG Metric Container >could be chained >such that each piece fits into 255 bytes or less... > >-Tim > > >Joakim Eriksson wrote: >> Hi Peter, >> >> I totally agree on the goal of minimizing packet sizes, but I would >> like to keep alignment requirements since it simplifies implementations. >> I also think (as you mention) that we need to question the 16-bit >> sub-option length. Is it really needed? Both IPv6 options and ICMPv6 >> option lenghts are encoded as 8-bit values. Going down to 8-bits would >> also help the alignment of the options. >> >> >> Best Regards, >> -- Joakim Eriksson, SICS >> >> Peter Siklosi skrev: >>> Hi all, >>> >>> >>> >>> If I understand correctly, RPL is designed to be usable with for >>> instance 6LoWPAN on 802.15.4 with very limiting frame sizes. Even if >>> 1280 byte IPv6 packets are of course supported using fragmentation, >>> large packets should be avoided at all cost given the low bandwidth >>> and low packet delivery success rate. >>> >>> >>> >>> Given this, I do not understand the alignment requirements specified >>> in draft-ietf-roll-rpl-05 6.1.3.1.1.1 "Following the convention in >>> IPv6, these options are aligned in a packet such that multi-octet >>> values within the Option Data field of each option fall on natural >>> boundaries". It seems that it would be more important to keep the >>> messages short and avoid padding options. I am also curious on >>> allocating 16 bits for a length field of a sub option. If sub option >>> length exceeding 255 bytes (as could be specified by 8 bits) are >>> needed, it seems that the routing messages are expected to get very >>> large. >>> >>> >>> >>> Regards, >>> Peter Siklosi >>> >>> >>> >>> >>> ------------------------------------------------------------------------ >>> >>> _______________________________________________ >>> Roll mailing list >>> Roll@ietf.org >>> https://www.ietf.org/mailman/listinfo/roll >> >> _______________________________________________ >> Roll mailing 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 Kuor-Hsin.Chang@us.elster.com Thu Dec 10 15:42:07 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9E3DA3A680F for ; Thu, 10 Dec 2009 15:42:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.203 X-Spam-Level: X-Spam-Status: No, score=-5.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 c9IaNqk3oUiR for ; Thu, 10 Dec 2009 15:42:06 -0800 (PST) Received: from mail136.messagelabs.com (mail136.messagelabs.com [216.82.249.3]) by core3.amsl.com (Postfix) with SMTP id 8D37A3A68AD for ; Thu, 10 Dec 2009 15:42:06 -0800 (PST) X-VirusChecked: Checked X-Env-Sender: Kuor-Hsin.Chang@us.elster.com X-Msg-Ref: server-15.tower-136.messagelabs.com!1260488514!72552187!1 X-StarScan-Version: 6.2.4; banners=-,-,- X-Originating-IP: [206.182.155.20] Received: (qmail 10119 invoked from network); 10 Dec 2009 23:41:54 -0000 Received: from unknown (HELO us-smtp01.smtp.elster.com) (206.182.155.20) by server-15.tower-136.messagelabs.com with SMTP; 10 Dec 2009 23:41:54 -0000 From: Kuor-Hsin.Chang@us.elster.com Date: Thu, 10 Dec 2009 18:45:36 -0500 To: "Matteo Paris" , "roll" Importance: Normal MIME-Version: 1.0 Message-ID: X-MIMETrack: Serialize by Router on US-SMTP01.domino.elster-group.com/RIM-TEMP(Release 8.5.1|September 28, 2009) at 12/10/2009 06:39:12 PM, Serialize complete at 12/10/2009 06:39:12 PM Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8"; Format="flowed" Subject: Re: [Roll] packet size issues X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 10 Dec 2009 23:42:07 -0000 Hi all, If the main concern about the packet size is what kind of payload that an 802= .15.4 device can support; I would like to let everyone know that even though = the current 802.15.4 device only can support a maximum packet length of 127 b= ytes, for the ongoing new standard 802.15.4g which is intended for smart util= ity network (SUN) applications, it does be able to support a maximum length o= f 1500 bytes. I would think that ROLL probably wants to be able to support t= hat as well. Best Regards, Kuor-Hsin Chang ----- Original Message ----- From: Matteo Paris [matteo@ember.com] Sent: 12/10/2009 11:03 AM EST To: roll@ietf.org Subject: Re: [Roll] packet size issues I agree that we should remove alignment requirements and reduce the suboption length field to 1 byte. As Peter wrote, if RPL is to work over constrained link layers, we have to keep in mind the frame size and bandwidth constraints of those layers. For example, in 802.15.4 after link-layer overhead, the usable payload is only 81 bytes (see RFC4944). Because limited bandwidth and large dense networks are a common use case, it is desirable for a DIO message to fit in a single packet. The current size of a DIO message not including the DAG Metric Container is already 59 bytes (3 6lowpan ip header + 4 icmp header + 20 base option + 25 dest prefix + 7 dag config). Padding could increase this by tens of bytes. If the DAG Metric Container is longer than 255 bytes I think it will pose serious challenges to RPL operation over constrained link layers. Matteo At 6:34 PM -0500 12/9/09, Tim Winter wrote: >I agree with Peter that we should consider to remove alignment requirements- >including the Pad1 and PadN options. I would expect that it is often cheaper >(energy/time/processing) to handle the alignment issues in the >implementation versus >transporting extra padding over LLN links. > >The 16-bit sub-option length is driven by the DAG Metric Container. >Perhaps once we >begin to see some proposed objective functions we can better >determine how large the >Metric Container may need to be. Perhaps the DAG Metric Container >could be chained >such that each piece fits into 255 bytes or less... > >-Tim > > >Joakim Eriksson wrote: >> Hi Peter, >> >> I totally agree on the goal of minimizing packet sizes, but I would >> like to keep alignment requirements since it simplifies implementations. >> I also think (as you mention) that we need to question the 16-bit >> sub-option length. Is it really needed? Both IPv6 options and ICMPv6 >> option lenghts are encoded as 8-bit values. Going down to 8-bits would >> also help the alignment of the options. >> >> >> Best Regards, >> -- Joakim Eriksson, SICS >> >> Peter Siklosi skrev: >>> Hi all, >>> >>> >>> >>> If I understand correctly, RPL is designed to be usable with for >>> instance 6LoWPAN on 802.15.4 with very limiting frame sizes. Even if >>> 1280 byte IPv6 packets are of course supported using fragmentation, >>> large packets should be avoided at all cost given the low bandwidth >>> and low packet delivery success rate. >>> >>> >>> >>> Given this, I do not understand the alignment requirements specified >>> in draft-ietf-roll-rpl-05 6.1.3.1.1.1 "Following the convention in >>> IPv6, these options are aligned in a packet such that multi-octet >>> values within the Option Data field of each option fall on natural >>> boundaries". It seems that it would be more important to keep the >>> messages short and avoid padding options. I am also curious on >>> allocating 16 bits for a length field of a sub option. If sub option >>> length exceeding 255 bytes (as could be specified by 8 bits) are >>> needed, it seems that the routing messages are expected to get very >>> large. >>> >>> >>> >>> Regards, >>> Peter Siklosi >>> >>> >>> >>> >>> ------------------------------------------------------------------------ >>> >>> _______________________________________________ >>> Roll mailing list >>> Roll@ietf.org >>> https://www.ietf.org/mailman/listinfo/roll >> >> _______________________________________________ >> Roll mailing list >> Roll@ietf.org >> https://www.ietf.org/mailman/listinfo/roll >> >_______________________________________________ >Roll mailing list >Roll@ietf.org >https://www.ietf.org/mailman/listinfo/roll _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll ______________________________________________________________________ This email has been spam and virus checked by Elster IT Services. From alexandru.petrescu@gmail.com Fri Dec 11 02:43:25 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 618A43A6A73 for ; Fri, 11 Dec 2009 02:43:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.29 X-Spam-Level: X-Spam-Status: No, score=-2.29 tagged_above=-999 required=5 tests=[AWL=-0.041, 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 1myFAs7RKDGO for ; Fri, 11 Dec 2009 02:43:24 -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 D7C633A688F for ; Fri, 11 Dec 2009 02:43:23 -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 nBBAhAnd003743 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 11 Dec 2009 11:43:10 +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 nBBAhAJ4008985; Fri, 11 Dec 2009 11:43:10 +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 nBBAh9tc031160; Fri, 11 Dec 2009 11:43:10 +0100 Message-ID: <4B22223D.2020502@gmail.com> Date: Fri, 11 Dec 2009 11:43:09 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Peter Siklosi References: <4B1FDDC8.7030001@sics.se><4B203410.4030102@acm.org> <4B203C37.90207@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] packet size issues X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 11 Dec 2009 10:43:25 -0000 Peter Siklosi a écrit : > Alex, > > Short answer, the reason to remove them is that they waste valuable > space. Hi, sorry - how much does one gain? Figures? For example, I doubt removal of few bytes here and there are any gain in wireless bandwidth when considering that the base header alone is 40bytes already, the ICMP header is 8 bytes fixed, and so on. How much would one save compared to one _has_ to always send? (between using or not using padding). > I think it may be a challenge in the first place to get the messages > short enough that it would work reasonably well in a real system > where the radio environment is less than optimal. Well yes - let's discuss it. I thought the shortest IPv6 packet could be 41 bytes, i.e. 40bytes of base header and 1 byte of data (provided a new Protocol number is defined, but we don't go that way, because ICMP). 41 bytes is not byte-aligned, it would need an additional pad of 8bytes, making it 48bytes. Comparing 48bytes to 41bytes, I do not consider eliminating padding 7bytes a significant save in bandwidth. How do you see things? > Messages should preferably travel unfragmented, or else as very few > fragments, and this does certainly not leave many bytes for say > LoWPAN over 802.15.4. When you say "fragmented" - do you mean IP fragmentation (happening each 1280bytes) or link-layer fragmentation? Traditionally, IPdoesn't care about the latter - why should RPL care? > I do not see so much focus in the draft on making the representations > compact, which I think is actually quite important. Padding makes > the situation worse, not better. Well... padding comes from a requirement of matching packet buffers to chip memory layout. I believe today's smallest chipsets act like earlier bigger chipsets, which had those requirements. I.e. I think a small 8bit micro-controller has strong requirements on its memory alignment and addressing, i.e. probably 32bits are addressed only at 32bit edges, and not 8bit. Thus padded packets may help a lot when addressing bytes within memory. > While simplifying implementations is a good thing, I think this is > less important, we cannot waste bytes for this reason (running > uncompressed IPv6 instead of applying LoWPAN compression would also > make implementations easier..). Hmm... I believe this is wrong, because simplifying must happen on all fronts not only the wireless communication part (i.e. the computing power is also restrained). > The same goes for representation of IP addresses. They need to be > compressed. Well I disagree. If one touches _anything_ in the representation of an IP address then one will no longer connect that node to the Internet. > If used on LoWPAN, I assume that context based compression would be a > common case, since I assume that routing would typically be used > within a subnet sharing the same prefix. Thinking over it... Alex > > Regards, Peter > > -----Ursprungligt meddelande----- Från: roll-bounces@ietf.org > [mailto:roll-bounces@ietf.org] För Alexandru Petrescu Skickat: den 10 > december 2009 01:09 Till: Tim Winter Kopia: roll@ietf.org Ämne: Re: > [Roll] packet size issues > > Tim Winter a écrit : >> I agree with Peter that we should consider to remove alignment >> requirements- including the Pad1 and PadN options. > > I disagree. I suggest to keep them. > > The reason is because an IP stack uses them already - why removing > them? > > Alex > >> I would expect that it is often cheaper (energy/time/processing) to >> handle the alignment issues in the implementation versus >> transporting extra padding over LLN links. >> >> The 16-bit sub-option length is driven by the DAG Metric Container. >> Perhaps once we begin to see some proposed objective functions we >> can better determine how large the Metric Container may need to >> be. Perhaps the DAG Metric Container could be chained such that >> each piece fits into 255 bytes or less... >> >> -Tim >> >> >> Joakim Eriksson wrote: >>> Hi Peter, >>> >>> I totally agree on the goal of minimizing packet sizes, but I >>> would like to keep alignment requirements since it simplifies >>> implementations. I also think (as you mention) that we need to >>> question the 16-bit sub-option length. Is it really needed? Both >>> IPv6 options and ICMPv6 option lenghts are encoded as 8-bit >>> values. Going down to 8-bits would also help the alignment of the >>> options. >>> >>> >>> Best Regards, -- Joakim Eriksson, SICS >>> >>> Peter Siklosi skrev: >>>> Hi all, >>>> >>>> >>>> >>>> If I understand correctly, RPL is designed to be usable with >>>> for instance 6LoWPAN on 802.15.4 with very limiting frame >>>> sizes. Even if 1280 byte IPv6 packets are of course supported >>>> using fragmentation, large packets should be avoided at all >>>> cost given the low bandwidth and low packet delivery success >>>> rate. >>>> >>>> >>>> >>>> Given this, I do not understand the alignment requirements >>>> specified in draft-ietf-roll-rpl-05 6.1.3.1.1.1 "Following the >>>> convention in IPv6, these options are aligned in a packet such >>>> that multi-octet values within the Option Data field of each >>>> option fall on natural boundaries". It seems that it would be >>>> more important to keep the messages short and avoid padding >>>> options. I am also curious on allocating 16 bits for a length >>>> field of a sub option. If sub option length exceeding 255 bytes >>>> (as could be specified by 8 bits) are needed, it seems that >>>> the routing messages are expected to get very large. >>>> >>>> >>>> >>>> Regards, Peter Siklosi >>>> >>>> >>>> >>>> >>>> ------------------------------------------------------------------------ >>>> >>>> >>>> >>>> >>>> _______________________________________________ Roll mailing >>>> list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll >>> _______________________________________________ Roll mailing list >>> Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll >>> >> _______________________________________________ Roll mailing list >> Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll >> > > _______________________________________________ Roll mailing list > Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll > From alexandru.petrescu@gmail.com Fri Dec 11 02:45:40 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 71DCC3A6998 for ; Fri, 11 Dec 2009 02:45:40 -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.040, 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 4VNEOc1ju0O5 for ; Fri, 11 Dec 2009 02:45:39 -0800 (PST) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.166.172.107]) by core3.amsl.com (Postfix) with ESMTP id 425AC3A688F for ; Fri, 11 Dec 2009 02:45:39 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.0) with ESMTP id nBBAjMon029248 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 11 Dec 2009 11:45:22 +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 nBBAjM7F009547; Fri, 11 Dec 2009 11:45:22 +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 nBBAjLRH031966; Fri, 11 Dec 2009 11:45:21 +0100 Message-ID: <4B2222C1.7060105@gmail.com> Date: Fri, 11 Dec 2009 11:45:21 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Matteo Paris References: <4B1FDDC8.7030001@sics.se> <4B203410.4030102@acm.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: roll@ietf.org Subject: Re: [Roll] packet size issues X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 11 Dec 2009 10:45:40 -0000 Well - make sure you know how much bandwidth you gain with this removal and how much additional computing power you require too. Matteo Paris a écrit : > > I agree that we should remove alignment requirements and reduce the > suboption length field to 1 byte. > > As Peter wrote, if RPL is to work over constrained link layers, we have > to keep in mind the frame size and bandwidth constraints of those > layers. For example, in 802.15.4 after link-layer overhead, the usable > payload is only 81 bytes (see RFC4944). Well let 802.15.4 do its fragmentation when it feels so, don't interfere with it. I mean (one should, IMHO, etc), Alex > > Because limited bandwidth and large dense networks are a common use > case, it is desirable for a DIO message to fit in a single packet. The > current size of a DIO message not including the DAG Metric Container is > already 59 bytes (3 6lowpan ip header + 4 icmp header + 20 base option + > 25 dest prefix + 7 dag config). Padding could increase this by tens of > bytes. If the DAG Metric Container is longer than 255 bytes I think it > will pose serious challenges to RPL operation over constrained link layers. > > Matteo > > > At 6:34 PM -0500 12/9/09, Tim Winter wrote: >> I agree with Peter that we should consider to remove alignment >> requirements- >> including the Pad1 and PadN options. I would expect that it is often >> cheaper >> (energy/time/processing) to handle the alignment issues in the >> implementation versus >> transporting extra padding over LLN links. >> >> The 16-bit sub-option length is driven by the DAG Metric Container. >> Perhaps once we >> begin to see some proposed objective functions we can better determine >> how large the >> Metric Container may need to be. Perhaps the DAG Metric Container >> could be chained >> such that each piece fits into 255 bytes or less... >> >> -Tim >> >> >> Joakim Eriksson wrote: >>> Hi Peter, >>> >>> I totally agree on the goal of minimizing packet sizes, but I would >>> like to keep alignment requirements since it simplifies >>> implementations. >>> I also think (as you mention) that we need to question the 16-bit >>> sub-option length. Is it really needed? Both IPv6 options and ICMPv6 >>> option lenghts are encoded as 8-bit values. Going down to 8-bits would >>> also help the alignment of the options. >>> >>> >>> Best Regards, >>> -- Joakim Eriksson, SICS >>> >>> Peter Siklosi skrev: >>>> Hi all, >>>> >>>> >>>> >>>> If I understand correctly, RPL is designed to be usable with for >>>> instance 6LoWPAN on 802.15.4 with very limiting frame sizes. Even if >>>> 1280 byte IPv6 packets are of course supported using fragmentation, >>>> large packets should be avoided at all cost given the low bandwidth >>>> and low packet delivery success rate. >>>> >>>> >>>> >>>> Given this, I do not understand the alignment requirements specified >>>> in draft-ietf-roll-rpl-05 6.1.3.1.1.1 "Following the convention in >>>> IPv6, these options are aligned in a packet such that multi-octet >>>> values within the Option Data field of each option fall on natural >>>> boundaries". It seems that it would be more important to keep the >>>> messages short and avoid padding options. I am also curious on >>>> allocating 16 bits for a length field of a sub option. If sub option >>>> length exceeding 255 bytes (as could be specified by 8 bits) are >>>> needed, it seems that the routing messages are expected to get very >>>> large. >>>> >>>> >>>> >>>> Regards, >>>> Peter Siklosi >>>> >>>> >>>> >>>> >>>> ------------------------------------------------------------------------ >>>> >>>> >>>> _______________________________________________ >>>> Roll mailing list >>>> Roll@ietf.org >>>> https://www.ietf.org/mailman/listinfo/roll >>> >>> _______________________________________________ >>> Roll mailing list >>> Roll@ietf.org >>> https://www.ietf.org/mailman/listinfo/roll >>> >> _______________________________________________ >> Roll mailing list >> Roll@ietf.org >> https://www.ietf.org/mailman/listinfo/roll > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > From alexandru.petrescu@gmail.com Fri Dec 11 03:25:06 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 580993A6AAF for ; Fri, 11 Dec 2009 03:25:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.288 X-Spam-Level: X-Spam-Status: No, score=-2.288 tagged_above=-999 required=5 tests=[AWL=-0.039, 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 p1GVg4JnTi8f for ; Fri, 11 Dec 2009 03:25:05 -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 9B8963A6978 for ; Fri, 11 Dec 2009 03:25:04 -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 nBBBOpij012311 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 11 Dec 2009 12:24:51 +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 nBBBOopU022037; Fri, 11 Dec 2009 12:24:51 +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 nBBBOopP016241; Fri, 11 Dec 2009 12:24:50 +0100 Message-ID: <4B222C02.3060303@gmail.com> Date: Fri, 11 Dec 2009 12:24:50 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Alexandru Petrescu References: <4B1FDDC8.7030001@sics.se><4B203410.4030102@acm.org> <4B203C37.90207@gmail.com> <4B22223D.2020502@gmail.com> In-Reply-To: <4B22223D.2020502@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: roll@ietf.org, Peter Siklosi Subject: Re: [Roll] packet size issues X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 11 Dec 2009 11:25:06 -0000 Alexandru Petrescu a écrit : > Peter Siklosi a écrit : >> Alex, >> >> Short answer, the reason to remove them is that they waste valuable >> space. > > Hi, sorry - how much does one gain? Figures? > > For example, I doubt removal of few bytes here and there are any gain in > wireless bandwidth when considering that the base header alone is > 40bytes already, the ICMP header is 8 bytes fixed, and so on. > > How much would one save compared to one _has_ to always send? (between > using or not using padding). > >> I think it may be a challenge in the first place to get the messages >> short enough that it would work reasonably well in a real system where >> the radio environment is less than optimal. > > Well yes - let's discuss it. > > I thought the shortest IPv6 packet could be 41 bytes, i.e. 40bytes of > base header and 1 byte of data (provided a new Protocol number is > defined, but we don't go that way, because ICMP). > > 41 bytes is not byte-aligned, it would need an additional pad of 8bytes, > making it 48bytes. I meant "is not 8byte-aligned" above (and not "is not byte-aligned"). Alex > > Comparing 48bytes to 41bytes, I do not consider eliminating padding > 7bytes a significant save in bandwidth. > > How do you see things? > > >> Messages should preferably travel unfragmented, or else as very few >> fragments, and this does certainly not leave many bytes for say LoWPAN >> over 802.15.4. > > When you say "fragmented" - do you mean IP fragmentation (happening each > 1280bytes) or link-layer fragmentation? Traditionally, IPdoesn't care > about the latter - why should RPL care? > >> I do not see so much focus in the draft on making the representations >> compact, which I think is actually quite important. Padding makes the >> situation worse, not better. > > Well... padding comes from a requirement of matching packet buffers to > chip memory layout. I believe today's smallest chipsets act like > earlier bigger chipsets, which had those requirements. > > I.e. I think a small 8bit micro-controller has strong requirements on > its memory alignment and addressing, i.e. probably 32bits are addressed > only at 32bit edges, and not 8bit. Thus padded packets may help a lot > when addressing bytes within memory. > >> While simplifying implementations is a good thing, I think this is >> less important, we cannot waste bytes for this reason (running >> uncompressed IPv6 instead of applying LoWPAN compression would also >> make implementations easier..). > > Hmm... I believe this is wrong, because simplifying must happen on all > fronts not only the wireless communication part (i.e. the computing > power is also restrained). > >> The same goes for representation of IP addresses. They need to be >> compressed. > > Well I disagree. If one touches _anything_ in the representation of an > IP address then one will no longer connect that node to the Internet. > >> If used on LoWPAN, I assume that context based compression would be a >> common case, since I assume that routing would typically be used >> within a subnet sharing the same prefix. > > Thinking over it... > > Alex > > >> >> Regards, Peter >> >> -----Ursprungligt meddelande----- Från: roll-bounces@ietf.org >> [mailto:roll-bounces@ietf.org] För Alexandru Petrescu Skickat: den 10 >> december 2009 01:09 Till: Tim Winter Kopia: roll@ietf.org Ämne: Re: >> [Roll] packet size issues >> >> Tim Winter a écrit : >>> I agree with Peter that we should consider to remove alignment >>> requirements- including the Pad1 and PadN options. >> >> I disagree. I suggest to keep them. >> >> The reason is because an IP stack uses them already - why removing them? >> >> Alex >> >>> I would expect that it is often cheaper (energy/time/processing) to >>> handle the alignment issues in the implementation versus >>> transporting extra padding over LLN links. >>> >>> The 16-bit sub-option length is driven by the DAG Metric Container. >>> Perhaps once we begin to see some proposed objective functions we >>> can better determine how large the Metric Container may need to >>> be. Perhaps the DAG Metric Container could be chained such that >>> each piece fits into 255 bytes or less... >>> >>> -Tim >>> >>> >>> Joakim Eriksson wrote: >>>> Hi Peter, >>>> >>>> I totally agree on the goal of minimizing packet sizes, but I would >>>> like to keep alignment requirements since it simplifies >>>> implementations. I also think (as you mention) that we need to >>>> question the 16-bit sub-option length. Is it really needed? Both >>>> IPv6 options and ICMPv6 option lenghts are encoded as 8-bit values. >>>> Going down to 8-bits would also help the alignment of the >>>> options. >>>> >>>> >>>> Best Regards, -- Joakim Eriksson, SICS >>>> >>>> Peter Siklosi skrev: >>>>> Hi all, >>>>> >>>>> >>>>> >>>>> If I understand correctly, RPL is designed to be usable with for >>>>> instance 6LoWPAN on 802.15.4 with very limiting frame sizes. Even >>>>> if 1280 byte IPv6 packets are of course supported using >>>>> fragmentation, large packets should be avoided at all cost given >>>>> the low bandwidth and low packet delivery success rate. >>>>> >>>>> >>>>> >>>>> Given this, I do not understand the alignment requirements >>>>> specified in draft-ietf-roll-rpl-05 6.1.3.1.1.1 "Following the >>>>> convention in IPv6, these options are aligned in a packet such >>>>> that multi-octet values within the Option Data field of each >>>>> option fall on natural boundaries". It seems that it would be more >>>>> important to keep the messages short and avoid padding options. I >>>>> am also curious on allocating 16 bits for a length field of a sub >>>>> option. If sub option length exceeding 255 bytes >>>>> (as could be specified by 8 bits) are needed, it seems that the >>>>> routing messages are expected to get very large. >>>>> >>>>> >>>>> >>>>> Regards, Peter Siklosi >>>>> >>>>> >>>>> >>>>> >>>>> ------------------------------------------------------------------------ >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> _______________________________________________ Roll mailing list >>>>> Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll >>>> _______________________________________________ Roll mailing list >>>> Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll >>>> >>> _______________________________________________ Roll mailing 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 Peter.Siklosi@tritech.se Fri Dec 11 03:29:29 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8951E3A6AA9 for ; Fri, 11 Dec 2009 03:29:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.877 X-Spam-Level: X-Spam-Status: No, score=-1.877 tagged_above=-999 required=5 tests=[AWL=0.373, 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 Cuy-L8ZR2AU5 for ; Fri, 11 Dec 2009 03:29:28 -0800 (PST) Received: from tritech.se (tritech.se [91.191.137.61]) by core3.amsl.com (Postfix) with ESMTP id 187D93A6AA8 for ; Fri, 11 Dec 2009 03:29:27 -0800 (PST) Received: from srvsund01.tritech.se (srvsund01.tritech.se [10.75.60.4]) by tritech.se (8.14.3/8.14.3) with ESMTP id nBBBTEqw019804; Fri, 11 Dec 2009 12:29:14 +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, 11 Dec 2009 12:29:10 +0100 Message-ID: In-Reply-To: <4B22223D.2020502@gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: SV: [Roll] packet size issues Thread-Index: Acp6Tr818e/PkIoQSPW/2whnM6Ms1gAA1QlA References: <4B1FDDC8.7030001@sics.se><4B203410.4030102@acm.org> <4B203C37.90207@gmail.com> <4B22223D.2020502@gmail.com> From: "Peter Siklosi" To: "Alexandru Petrescu" X-CT-RefID: str=0001.0A3C0009.4B222D02.00F1,ss=1,fgs=0 Cc: roll@ietf.org Subject: Re: [Roll] packet size issues X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 11 Dec 2009 11:29:29 -0000 Alex, > I thought the shortest IPv6 packet could be 41 bytes [...] I would not expect anyone to use uncompressed IPv6 in a low bandwidth = radio network. This is what 6LoWPAN is all about, compressing the = headers to reasonable sizes. Every byte is valuable. There is certainly = no padding there. =20 > For example, I doubt removal of few bytes here and there are any gain This may be your opinion. I do not agree. > When you say "fragmented" - do you mean IP fragmentation (happening = each 1280bytes) or link-layer fragmentation? > Traditionally, IPdoesn't care about the latter - why should RPL care? I mean fragmentation by 6LoWPAN for instance. RPL does not need to care, = unless the goal is to get it working in real life. Regards, Peter -----Ursprungligt meddelande----- Fr=E5n: Alexandru Petrescu [mailto:alexandru.petrescu@gmail.com]=20 Skickat: den 11 december 2009 11:43 Till: Peter Siklosi Kopia: Alexandru Petrescu; roll@ietf.org =C4mne: Re: SV: [Roll] packet size issues Peter Siklosi a =E9crit : > Alex, >=20 > Short answer, the reason to remove them is that they waste valuable=20 > space. Hi, sorry - how much does one gain? Figures? For example, I doubt removal of few bytes here and there are any gain in wireless bandwidth when considering that the base header alone is 40bytes already, the ICMP header is 8 bytes fixed, and so on. How much would one save compared to one _has_ to always send? (between using or not using padding). > I think it may be a challenge in the first place to get the messages=20 > short enough that it would work reasonably well in a real system=20 > where the radio environment is less than optimal. Well yes - let's discuss it. I thought the shortest IPv6 packet could be 41 bytes, i.e. 40bytes of base header and 1 byte of data (provided a new Protocol number is defined, but we don't go that way, because ICMP). 41 bytes is not byte-aligned, it would need an additional pad of 8bytes, making it 48bytes. Comparing 48bytes to 41bytes, I do not consider eliminating padding 7bytes a significant save in bandwidth. How do you see things? > Messages should preferably travel unfragmented, or else as very few=20 > fragments, and this does certainly not leave many bytes for say=20 > LoWPAN over 802.15.4. When you say "fragmented" - do you mean IP fragmentation (happening each 1280bytes) or link-layer fragmentation? Traditionally, IPdoesn't care about the latter - why should RPL care? > I do not see so much focus in the draft on making the representations > compact, which I think is actually quite important. Padding makes=20 > the situation worse, not better. Well... padding comes from a requirement of matching packet buffers to chip memory layout. I believe today's smallest chipsets act like earlier bigger chipsets, which had those requirements. I.e. I think a small 8bit micro-controller has strong requirements on its memory alignment and addressing, i.e. probably 32bits are addressed only at 32bit edges, and not 8bit. Thus padded packets may help a lot when addressing bytes within memory. > While simplifying implementations is a good thing, I think this is=20 > less important, we cannot waste bytes for this reason (running=20 > uncompressed IPv6 instead of applying LoWPAN compression would also=20 > make implementations easier..). Hmm... I believe this is wrong, because simplifying must happen on all fronts not only the wireless communication part (i.e. the computing power is also restrained). > The same goes for representation of IP addresses. They need to be > compressed. Well I disagree. If one touches _anything_ in the representation of an IP address then one will no longer connect that node to the Internet. > If used on LoWPAN, I assume that context based compression would be a > common case, since I assume that routing would typically be used > within a subnet sharing the same prefix. Thinking over it... Alex >=20 > Regards, Peter >=20 > -----Ursprungligt meddelande----- Fr=E5n: roll-bounces@ietf.org=20 > [mailto:roll-bounces@ietf.org] F=F6r Alexandru Petrescu Skickat: den = 10 > december 2009 01:09 Till: Tim Winter Kopia: roll@ietf.org =C4mne: Re: > [Roll] packet size issues >=20 > Tim Winter a =E9crit : >> I agree with Peter that we should consider to remove alignment=20 >> requirements- including the Pad1 and PadN options. >=20 > I disagree. I suggest to keep them. >=20 > The reason is because an IP stack uses them already - why removing=20 > them? >=20 > Alex >=20 >> I would expect that it is often cheaper (energy/time/processing) to >> handle the alignment issues in the implementation versus=20 >> transporting extra padding over LLN links. >>=20 >> The 16-bit sub-option length is driven by the DAG Metric Container. >> Perhaps once we begin to see some proposed objective functions we >> can better determine how large the Metric Container may need to >> be. Perhaps the DAG Metric Container could be chained such that >> each piece fits into 255 bytes or less... >>=20 >> -Tim >>=20 >>=20 >> Joakim Eriksson wrote: >>> Hi Peter, >>>=20 >>> I totally agree on the goal of minimizing packet sizes, but I=20 >>> would like to keep alignment requirements since it simplifies=20 >>> implementations. I also think (as you mention) that we need to=20 >>> question the 16-bit sub-option length. Is it really needed? Both >>> IPv6 options and ICMPv6 option lenghts are encoded as 8-bit=20 >>> values. Going down to 8-bits would also help the alignment of the >>> options. >>>=20 >>>=20 >>> Best Regards, -- Joakim Eriksson, SICS >>>=20 >>> Peter Siklosi skrev: >>>> Hi all, >>>>=20 >>>>=20 >>>>=20 >>>> If I understand correctly, RPL is designed to be usable with=20 >>>> for instance 6LoWPAN on 802.15.4 with very limiting frame=20 >>>> sizes. Even if 1280 byte IPv6 packets are of course supported=20 >>>> using fragmentation, large packets should be avoided at all=20 >>>> cost given the low bandwidth and low packet delivery success=20 >>>> rate. >>>>=20 >>>>=20 >>>>=20 >>>> Given this, I do not understand the alignment requirements=20 >>>> specified in draft-ietf-roll-rpl-05 6.1.3.1.1.1 "Following the >>>> convention in IPv6, these options are aligned in a packet such >>>> that multi-octet values within the Option Data field of each=20 >>>> option fall on natural boundaries". It seems that it would be=20 >>>> more important to keep the messages short and avoid padding=20 >>>> options. I am also curious on allocating 16 bits for a length=20 >>>> field of a sub option. If sub option length exceeding 255 bytes >>>> (as could be specified by 8 bits) are needed, it seems that=20 >>>> the routing messages are expected to get very large. >>>>=20 >>>>=20 >>>>=20 >>>> Regards, Peter Siklosi >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> = ------------------------------------------------------------------------ >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> _______________________________________________ Roll mailing=20 >>>> 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=20 >> Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll >>=20 >=20 > _______________________________________________ Roll mailing list=20 > Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll >=20 From jvasseur@cisco.com Fri Dec 11 06:20:42 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 66E9B3A6842 for ; Fri, 11 Dec 2009 06:20:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.995 X-Spam-Level: X-Spam-Status: No, score=-4.995 tagged_above=-999 required=5 tests=[AWL=-2.396, 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 vyppz6CTwM-j for ; Fri, 11 Dec 2009 06:20:41 -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 1766D3A635F for ; Fri, 11 Dec 2009 06:20:39 -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: AjMAAK3jIUuQ/uCWiWdsb2JhbACbPwEBAQoLERMGokqXJ4QrBA X-IronPort-AV: E=Sophos;i="4.47,382,1257120000"; d="scan'208";a="1130273" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-2.cisco.com with ESMTP; 11 Dec 2009 13:54:00 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id nBBEKRmY016543 for ; Fri, 11 Dec 2009 14:20:27 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); Fri, 11 Dec 2009 15:20:26 +0100 Received: from ams-jvasseur-8715.cisco.com ([10.55.201.134]) by xfe-ams-202.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 11 Dec 2009 15:20:26 +0100 Message-Id: <46A68908-B700-47D1-92CC-0C56B21C98F5@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, 11 Dec 2009 15:20:26 +0100 X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 11 Dec 2009 14:20:26.0747 (UTC) FILETIME=[15B1ACB0:01CA7A6D] Subject: [Roll] Potential RPL Enhancements X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 11 Dec 2009 14:20:42 -0000 Dear all, As a follow up to my previous email with regards to the version 05 of RPL, I wanted to elaborate a little bit on the process that we will be following with regards to further RPL enhancements. We reached a point where the protocol is getting stable with all must- have features (except security, our next top priority item). It is now time to get feed-back from implementers. There will of course be proposals to enhance and improve the protocol and here is the proposed way to proceed: 1) If there is a request to modify RPL because an issue has been found, a ticket will be opened and the issue will be solved. 2) If there is "nice to have" enhancements, we'll open a ticket flagged as "enhancement", to be addressed at some point (e.g. DIS enhancement) 3) New features will be addressed in separate documents. Plan for rev-06 and -07: 1) clarification and potential enhancements to DAO processing 2) potentially DAO packing if it is shown that such mechanism is needed 3) Security Thanks. JP. From Matteo.Paris@ember.com Fri Dec 11 06:26:29 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B9A8628C0CE for ; Fri, 11 Dec 2009 06:26:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[AWL=-0.698, BAYES_00=-2.599, 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 N5gTmNXBpnui for ; Fri, 11 Dec 2009 06:26:28 -0800 (PST) Received: from EMPIRE.hq.ember.com (mail.ember.com [74.10.175.227]) by core3.amsl.com (Postfix) with ESMTP id 7F7DB3A69A5 for ; Fri, 11 Dec 2009 06:26:28 -0800 (PST) Received: from [192.168.1.102] ([192.168.81.84]) by EMPIRE.hq.ember.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 11 Dec 2009 09:28:02 -0500 Mime-Version: 1.0 Message-Id: In-Reply-To: <4B2222C1.7060105@gmail.com> References: <4B1FDDC8.7030001@sics.se> <4B203410.4030102@acm.org> <4B2222C1.7060105@gmail.com> Date: Fri, 11 Dec 2009 09:26:15 -0500 To: Alexandru Petrescu From: Matteo Paris Content-Type: text/plain; charset="iso-8859-1" ; format="flowed" Content-Transfer-Encoding: quoted-printable X-OriginalArrivalTime: 11 Dec 2009 14:28:02.0881 (UTC) FILETIME=[25923310:01CA7A6E] Cc: roll@ietf.org Subject: Re: [Roll] packet size issues X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 11 Dec 2009 14:26:29 -0000 At 11:45 AM +0100 12/11/09, Alexandru Petrescu wrote: >Well - make sure you know how much bandwidth you=20 >gain with this removal and how much additional=20 >computing power you require too. Hi Alex, I quite agree. I can offer my=20 experience, which is a decade of working on a=20 variety of commercial wireless LLNs. Bandwidth=20 and RAM have always been the dominant bottlenecks=20 and computing power not a constraint. The=20 tradeoff may be different on other LLN platforms=20 of course. Are there any where one would trade=20 bandwidth and RAM for processing speed? As for fragmentation, due to medium acess=20 overhead (at least in CSMA systems), and link=20 layer header duplication, if a common packet like=20 DIO goes from fitting into one packet to=20 requiring fragmentation, it incurs a substantial=20 discrete performance and scalability penalty on=20 the lowpan >Traditionally, IP doesn't care about [link layer=20 >fragmentation] - why should RPL care? ... let=20 >802.15.4 do its fragmentation when it feels so,=20 >don't interfere with it. It would be nice if RPL did not need to care=20 about the limitations of the link layer, but if=20 we had that luxury there would be no need for=20 roll and 6lowpan... and maybe that would be nice=20 ;-). But in all seriousness, the roll charter=20 addresses this issue explicitly: " - In most cases, LLNs will be employed over link layers with restricted frame-sizes, thus a routing protocol for LLNs should be specifically adapted for such link layers." Matteo > >Matteo Paris a =E9crit : >> >>I agree that we should remove alignment=20 >>requirements and reduce the suboption length=20 >>field to 1 byte. >> >>As Peter wrote, if RPL is to work over=20 >>constrained link layers, we have to keep in=20 >>mind the frame size and bandwidth constraints=20 >>of those layers. For example, in 802.15.4=20 >>after link-layer overhead, the usable payload=20 >>is only 81 bytes (see RFC4944). > >Well let 802.15.4 do its fragmentation when it=20 >feels so, don't interfere with it. > >I mean (one should, IMHO, etc), > >Alex > >> >>Because limited bandwidth and large dense=20 >>networks are a common use case, it is desirable=20 >>for a DIO message to fit in a single packet.=20 >>The current size of a DIO message not including=20 >>the DAG Metric Container is already 59 bytes (3=20 >>6lowpan ip header + 4 icmp header + 20 base=20 >>option + 25 dest prefix + 7 dag config).=20 >>Padding could increase this by tens of bytes.=20 >>If the DAG Metric Container is longer than 255=20 >>bytes I think it will pose serious challenges=20 >>to RPL operation over constrained link layers. >> >>Matteo >> >> >>At 6:34 PM -0500 12/9/09, Tim Winter wrote: >>>I agree with Peter that we should consider to remove alignment requiremen= ts- >>>including the Pad1 and PadN options. I would=20 >>>expect that it is often cheaper >>>(energy/time/processing) to handle the=20 >>>alignment issues in the implementation versus >>>transporting extra padding over LLN links. >>> >>>The 16-bit sub-option length is driven by the=20 >>>DAG Metric Container. Perhaps once we >>>begin to see some proposed objective functions=20 >>>we can better determine how large the >>>Metric Container may need to be. Perhaps the=20 >>>DAG Metric Container could be chained >>>such that each piece fits into 255 bytes or less... >>> >>>-Tim >>> >>> >>>Joakim Eriksson wrote: >>>> Hi Peter, >>>> >>>> I totally agree on the goal of minimizing packet sizes, but I would >>>> like to keep alignment requirements since it simplifies implementation= s. >>>> I also think (as you mention) that we need to question the 16-bit >>>> sub-option length. Is it really needed? Both IPv6 options and ICMPv6 >>>> option lenghts are encoded as 8-bit values. Going down to 8-bits would >>>> also help the alignment of the options. >>>> >>>> >>>> Best Regards, >>>> -- Joakim Eriksson, SICS >>>> >>>> Peter Siklosi skrev: >>>>> Hi all, >>>>> >>>>> >>>>> >>>>> If I understand correctly, RPL is designed to be usable with for >>>>> instance 6LoWPAN on 802.15.4 with very limiting frame sizes. Even if >>>>> 1280 byte IPv6 packets are of course supported using fragmentation, >>>>> large packets should be avoided at all cost given the low bandwidth >>>>> and low packet delivery success rate. >>>>> >>>>> >>>>> >>>>> Given this, I do not understand the alignment requirements specified >>>>> in draft-ietf-roll-rpl-05 6.1.3.1.1.1 "Following the convention in >>>>> IPv6, these options are aligned in a packet such that multi-octet >>>>> values within the Option Data field of each option fall on natural >>>>> boundaries". It seems that it would be more important to keep the >>>>> messages short and avoid padding options. I am also curious on >>>>> allocating 16 bits for a length field of a sub option. If sub option >>>>> length exceeding 255 bytes (as could be specified by 8 bits) are >>>>> needed, it seems that the routing messages are expected to get very >>>>> large. >>>>> >>>>> >>>>> >>>>> Regards, >>>>> Peter Siklosi >>>>> >>>>> >>>>> >>>>> >>>>> ---------------------------------------------------------------------= --- >>>>> >>>>> _______________________________________________ >>>>> Roll mailing list >>>>> Roll@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/roll >>>> >>>> _______________________________________________ >>>> Roll mailing list >>>> Roll@ietf.org >>>> https://www.ietf.org/mailman/listinfo/roll >>>> >>>_______________________________________________ >>>Roll mailing 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=589a0a4ee=mukul@uwm.edu Fri Dec 11 06:32:36 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 984B33A6ABC for ; Fri, 11 Dec 2009 06:32:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[AWL=0.503, 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 2s8HLiWdgbJw for ; Fri, 11 Dec 2009 06:32:35 -0800 (PST) Received: from ip1mta2.uwm.edu (ip1mta2.uwm.edu [129.89.7.130]) by core3.amsl.com (Postfix) with ESMTP id 8C3173A67E2 for ; Fri, 11 Dec 2009 06:32:35 -0800 (PST) Received: from mta03.pantherlink.uwm.edu ([129.89.7.83]) by ip1mta2.uwm.edu with ESMTP; 11 Dec 2009 08:32:23 -0600 Received: from localhost (localhost.localdomain [127.0.0.1]) by mta03.pantherlink.uwm.edu (Postfix) with ESMTP id 7D771C085D0; Fri, 11 Dec 2009 08:32:23 -0600 (CST) 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 frDE3KqMAOdd; Fri, 11 Dec 2009 08:32:22 -0600 (CST) Received: from mail02.pantherlink.uwm.edu (mail02.pantherlink.uwm.edu [129.89.7.86]) by mta03.pantherlink.uwm.edu (Postfix) with ESMTP id 7168EC085C8; Fri, 11 Dec 2009 08:32:22 -0600 (CST) Date: Fri, 11 Dec 2009 08:32:22 -0600 (CST) From: Mukul Goyal To: JP Vasseur Message-ID: <645896496.9714841260541942388.JavaMail.root@mail02.pantherlink.uwm.edu> In-Reply-To: <2050276922.9714591260541913420.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.19_GA_3083.RHEL4_64 (ZimbraWebClient - [unknown] (Win)/5.0.19_GA_3083.RHEL4_64) X-Authenticated-User: mukul@uwm.edu Cc: ROLL WG Subject: Re: [Roll] Potential RPL Enhancements X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 11 Dec 2009 14:32:50 -0000 JP "We reached a point where the protocol is getting stable with all must- have features (except security, our next top priority item)." I am not sure if many people are convinced regarding the suitability of RPL for P2P routing. Thanks Mukul ----- Original Message ----- From: "JP Vasseur" To: "ROLL WG" Sent: Friday, December 11, 2009 8:20:26 AM GMT -06:00 US/Canada Central Subject: [Roll] Potential RPL Enhancements Dear all, As a follow up to my previous email with regards to the version 05 of RPL, I wanted to elaborate a little bit on the process that we will be following with regards to further RPL enhancements. We reached a point where the protocol is getting stable with all must- have features (except security, our next top priority item). It is now time to get feed-back from implementers. There will of course be proposals to enhance and improve the protocol and here is the proposed way to proceed: 1) If there is a request to modify RPL because an issue has been found, a ticket will be opened and the issue will be solved. 2) If there is "nice to have" enhancements, we'll open a ticket flagged as "enhancement", to be addressed at some point (e.g. DIS enhancement) 3) New features will be addressed in separate documents. Plan for rev-06 and -07: 1) clarification and potential enhancements to DAO processing 2) potentially DAO packing if it is shown that such mechanism is needed 3) Security Thanks. JP. _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From jvasseur@cisco.com Fri Dec 11 06:44:03 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ED9643A6778 for ; Fri, 11 Dec 2009 06:44:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.918 X-Spam-Level: X-Spam-Status: No, score=-6.918 tagged_above=-999 required=5 tests=[AWL=-0.319, 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 TN2K+ZTuboN8 for ; Fri, 11 Dec 2009 06:44:03 -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 CAD3E28B797 for ; Fri, 11 Dec 2009 06:44: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: ApoEAITpIUtAZnwN/2dsb2JhbAC+UZcphCsEjR4 X-IronPort-AV: E=Sophos;i="4.47,382,1257120000"; d="scan'208";a="73692668" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 11 Dec 2009 14:43:50 +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 nBBEhjJN014891; Fri, 11 Dec 2009 14:43:50 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); Fri, 11 Dec 2009 15:42:59 +0100 Received: from ams-jvasseur-8715.cisco.com ([10.55.201.134]) by xfe-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 11 Dec 2009 15:42:59 +0100 Message-Id: <0830BA97-47A1-484C-AE65-A159947EC1D8@cisco.com> From: JP Vasseur To: Mukul Goyal In-Reply-To: <645896496.9714841260541942388.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: Fri, 11 Dec 2009 15:42:58 +0100 References: <645896496.9714841260541942388.JavaMail.root@mail02.pantherlink.uwm.edu> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 11 Dec 2009 14:42:59.0569 (UTC) FILETIME=[3C09EE10:01CA7A70] Cc: ROLL WG Subject: Re: [Roll] Potential RPL Enhancements X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 11 Dec 2009 14:44:04 -0000 Hi Mukul, On Dec 11, 2009, at 3:32 PM, Mukul Goyal wrote: > JP > > "We reached a point where the protocol is getting stable with all > must- > have features (except security, our next top priority item)." > > I am not sure if many people are convinced regarding the suitability > of RPL for P2P routing. > Thanks for the comment. Could you elaborate with data points? Thanks. JP. > Thanks > Mukul > > ----- Original Message ----- > From: "JP Vasseur" > To: "ROLL WG" > Sent: Friday, December 11, 2009 8:20:26 AM GMT -06:00 US/Canada > Central > Subject: [Roll] Potential RPL Enhancements > > Dear all, > > As a follow up to my previous email with regards to the version 05 of > RPL, I wanted to elaborate a little bit on the process that we will be > following with regards to further RPL enhancements. > > We reached a point where the protocol is getting stable with all must- > have features (except security, our next top priority item). It is now > time to get feed-back from implementers. > > There will of course be proposals to enhance and improve the protocol > and here is the proposed way to proceed: > > 1) If there is a request to modify RPL because an issue has been > found, a ticket will be opened and the issue will be solved. > 2) If there is "nice to have" enhancements, we'll open a ticket > flagged as "enhancement", to be addressed at some point (e.g. DIS > enhancement) > 3) New features will be addressed in separate documents. > > Plan for rev-06 and -07: > 1) clarification and potential enhancements to DAO processing > 2) potentially DAO packing if it is shown that such mechanism is > needed > 3) Security > > Thanks. > > JP. > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From prvs=589a0a4ee=mukul@uwm.edu Fri Dec 11 06:53:35 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 159D23A69F2 for ; Fri, 11 Dec 2009 06:53:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.178 X-Spam-Level: X-Spam-Status: No, score=-2.178 tagged_above=-999 required=5 tests=[AWL=0.421, 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 i-mL-V4cX63V for ; Fri, 11 Dec 2009 06:53:34 -0800 (PST) Received: from ip1mta2.uwm.edu (ip1mta2.uwm.edu [129.89.7.130]) by core3.amsl.com (Postfix) with ESMTP id 0CFBF3A690A for ; Fri, 11 Dec 2009 06:53:33 -0800 (PST) Received: from mta03.pantherlink.uwm.edu ([129.89.7.83]) by ip1mta2.uwm.edu with ESMTP; 11 Dec 2009 08:53:19 -0600 Received: from localhost (localhost.localdomain [127.0.0.1]) by mta03.pantherlink.uwm.edu (Postfix) with ESMTP id D75F1C085CB; Fri, 11 Dec 2009 08:53:19 -0600 (CST) 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 4psA6gpJYLFA; Fri, 11 Dec 2009 08:53:19 -0600 (CST) Received: from mail02.pantherlink.uwm.edu (mail02.pantherlink.uwm.edu [129.89.7.86]) by mta03.pantherlink.uwm.edu (Postfix) with ESMTP id 8310EC085C8; Fri, 11 Dec 2009 08:53:19 -0600 (CST) Date: Fri, 11 Dec 2009 08:53:19 -0600 (CST) From: Mukul Goyal To: JP Vasseur Message-ID: <1148229719.9727081260543199501.JavaMail.root@mail02.pantherlink.uwm.edu> In-Reply-To: <260125047.9726421260543123552.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.19_GA_3083.RHEL4_64 (ZimbraWebClient - [unknown] (Win)/5.0.19_GA_3083.RHEL4_64) X-Authenticated-User: mukul@uwm.edu Cc: ROLL WG Subject: Re: [Roll] Potential RPL Enhancements X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 11 Dec 2009 14:53:35 -0000 Hi JP, Would simulation results suffice? I plan to run simulations on sample topologies to compare: the "cost" for P2P routes (for each source to each destination in the network) through a DAG (up the DAG and then down; with and without non-root nodes storing DAO state) versus "minimum cost" versus the cost under the protocol that I suggested a few months ago. Thanks Mukul ----- Original Message ----- From: "JP Vasseur" To: "Mukul Goyal" Cc: "ROLL WG" Sent: Friday, December 11, 2009 8:42:58 AM GMT -06:00 US/Canada Central Subject: Re: [Roll] Potential RPL Enhancements Hi Mukul, On Dec 11, 2009, at 3:32 PM, Mukul Goyal wrote: > JP > > "We reached a point where the protocol is getting stable with all > must- > have features (except security, our next top priority item)." > > I am not sure if many people are convinced regarding the suitability > of RPL for P2P routing. > Thanks for the comment. Could you elaborate with data points? Thanks. JP. > Thanks > Mukul > > ----- Original Message ----- > From: "JP Vasseur" > To: "ROLL WG" > Sent: Friday, December 11, 2009 8:20:26 AM GMT -06:00 US/Canada > Central > Subject: [Roll] Potential RPL Enhancements > > Dear all, > > As a follow up to my previous email with regards to the version 05 of > RPL, I wanted to elaborate a little bit on the process that we will be > following with regards to further RPL enhancements. > > We reached a point where the protocol is getting stable with all must- > have features (except security, our next top priority item). It is now > time to get feed-back from implementers. > > There will of course be proposals to enhance and improve the protocol > and here is the proposed way to proceed: > > 1) If there is a request to modify RPL because an issue has been > found, a ticket will be opened and the issue will be solved. > 2) If there is "nice to have" enhancements, we'll open a ticket > flagged as "enhancement", to be addressed at some point (e.g. DIS > enhancement) > 3) New features will be addressed in separate documents. > > Plan for rev-06 and -07: > 1) clarification and potential enhancements to DAO processing > 2) potentially DAO packing if it is shown that such mechanism is > needed > 3) Security > > Thanks. > > JP. > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From alexandru.petrescu@gmail.com Fri Dec 11 09:07:32 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D1D373A69A0 for ; Fri, 11 Dec 2009 09:07:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.287 X-Spam-Level: X-Spam-Status: No, score=-2.287 tagged_above=-999 required=5 tests=[AWL=-0.038, 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 PGd7iULUzVbg for ; Fri, 11 Dec 2009 09:07:31 -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 189243A687B for ; Fri, 11 Dec 2009 09:07:30 -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 nBBH7GGl032061 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 11 Dec 2009 18:07:17 +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 nBBH7FrW022897; Fri, 11 Dec 2009 18:07:15 +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 nBBH7Ec2026087; Fri, 11 Dec 2009 18:07:15 +0100 Message-ID: <4B227C42.5080704@gmail.com> Date: Fri, 11 Dec 2009 18:07:14 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Peter Siklosi References: <4B1FDDC8.7030001@sics.se><4B203410.4030102@acm.org> <4B203C37.90207@gmail.com> <4B22223D.2020502@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] packet size issues X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 11 Dec 2009 17:07:32 -0000 Peter Siklosi a écrit : > Alex, > >> I thought the shortest IPv6 packet could be 41 bytes [...] > > I would not expect anyone to use uncompressed IPv6 in a low bandwidth > radio network. Hmm... I used IPv6 over 2400baud serial lines, worked ok. That's as low bandwidth as it can get. > This is what 6LoWPAN is all about, compressing the headers to > reasonable sizes. Well, I think 6LoWPAN is more than just that. For example there is 6lowpan-nd which doesn't consider this header compression (not that I know of). > Every byte is valuable. There is certainly no padding there. In a sense it makes sense that every byte is valuable. But I also think there is paramount importance in being able to connect one such end-node to the Internet, i.e. to any other Internet node. And that's impossible if you start talking removing padding, shortening IPv6 addresses, etc. This is a large topic of discussion and I think it's not currently settled. >> For example, I doubt removal of few bytes here and there are any >> gain > > This may be your opinion. I do not agree. Yes, we have disagreement. >> When you say "fragmented" - do you mean IP fragmentation (happening >> each 1280bytes) or link-layer fragmentation? Traditionally, >> IPdoesn't care about the latter - why should RPL care? > > I mean fragmentation by 6LoWPAN for instance. RPL does not need to > care, unless the goal is to get it working in real life. If 6lowpan does fragmentation (a big if already) then why would one prefer to eliminate padding, or shorten the IPv6 packet length in the base header? Alex > > Regards, Peter > > -----Ursprungligt meddelande----- Från: Alexandru Petrescu > [mailto:alexandru.petrescu@gmail.com] Skickat: den 11 december 2009 > 11:43 Till: Peter Siklosi Kopia: Alexandru Petrescu; roll@ietf.org > Ämne: Re: SV: [Roll] packet size issues > > Peter Siklosi a écrit : >> Alex, >> >> Short answer, the reason to remove them is that they waste valuable >> space. > > Hi, sorry - how much does one gain? Figures? > > For example, I doubt removal of few bytes here and there are any gain > in wireless bandwidth when considering that the base header alone is > 40bytes already, the ICMP header is 8 bytes fixed, and so on. > > How much would one save compared to one _has_ to always send? > (between using or not using padding). > >> I think it may be a challenge in the first place to get the >> messages short enough that it would work reasonably well in a real >> system where the radio environment is less than optimal. > > Well yes - let's discuss it. > > I thought the shortest IPv6 packet could be 41 bytes, i.e. 40bytes of > base header and 1 byte of data (provided a new Protocol number is > defined, but we don't go that way, because ICMP). > > 41 bytes is not byte-aligned, it would need an additional pad of > 8bytes, making it 48bytes. > > Comparing 48bytes to 41bytes, I do not consider eliminating padding > 7bytes a significant save in bandwidth. > > How do you see things? > > >> Messages should preferably travel unfragmented, or else as very few >> fragments, and this does certainly not leave many bytes for say >> LoWPAN over 802.15.4. > > When you say "fragmented" - do you mean IP fragmentation (happening > each 1280bytes) or link-layer fragmentation? Traditionally, > IPdoesn't care about the latter - why should RPL care? > >> I do not see so much focus in the draft on making the >> representations compact, which I think is actually quite important. >> Padding makes the situation worse, not better. > > Well... padding comes from a requirement of matching packet buffers > to chip memory layout. I believe today's smallest chipsets act like > earlier bigger chipsets, which had those requirements. > > I.e. I think a small 8bit micro-controller has strong requirements on > its memory alignment and addressing, i.e. probably 32bits are > addressed only at 32bit edges, and not 8bit. Thus padded packets may > help a lot when addressing bytes within memory. > >> While simplifying implementations is a good thing, I think this is >> less important, we cannot waste bytes for this reason (running >> uncompressed IPv6 instead of applying LoWPAN compression would also >> make implementations easier..). > > Hmm... I believe this is wrong, because simplifying must happen on > all fronts not only the wireless communication part (i.e. the > computing power is also restrained). > >> The same goes for representation of IP addresses. They need to be >> compressed. > > Well I disagree. If one touches _anything_ in the representation of > an IP address then one will no longer connect that node to the > Internet. > >> If used on LoWPAN, I assume that context based compression would be >> a common case, since I assume that routing would typically be used >> within a subnet sharing the same prefix. > > Thinking over it... > > Alex > > >> Regards, Peter >> >> -----Ursprungligt meddelande----- Från: roll-bounces@ietf.org >> [mailto:roll-bounces@ietf.org] För Alexandru Petrescu Skickat: den >> 10 december 2009 01:09 Till: Tim Winter Kopia: roll@ietf.org Ämne: >> Re: [Roll] packet size issues >> >> Tim Winter a écrit : >>> I agree with Peter that we should consider to remove alignment >>> requirements- including the Pad1 and PadN options. >> I disagree. I suggest to keep them. >> >> The reason is because an IP stack uses them already - why removing >> them? >> >> Alex >> >>> I would expect that it is often cheaper (energy/time/processing) >>> to handle the alignment issues in the implementation versus >>> transporting extra padding over LLN links. >>> >>> The 16-bit sub-option length is driven by the DAG Metric >>> Container. Perhaps once we begin to see some proposed objective >>> functions we can better determine how large the Metric Container >>> may need to be. Perhaps the DAG Metric Container could be chained >>> such that each piece fits into 255 bytes or less... >>> >>> -Tim >>> >>> >>> Joakim Eriksson wrote: >>>> Hi Peter, >>>> >>>> I totally agree on the goal of minimizing packet sizes, but I >>>> would like to keep alignment requirements since it simplifies >>>> implementations. I also think (as you mention) that we need to >>>> question the 16-bit sub-option length. Is it really needed? >>>> Both IPv6 options and ICMPv6 option lenghts are encoded as >>>> 8-bit values. Going down to 8-bits would also help the >>>> alignment of the options. >>>> >>>> >>>> Best Regards, -- Joakim Eriksson, SICS >>>> >>>> Peter Siklosi skrev: >>>>> Hi all, >>>>> >>>>> >>>>> >>>>> If I understand correctly, RPL is designed to be usable with >>>>> for instance 6LoWPAN on 802.15.4 with very limiting frame >>>>> sizes. Even if 1280 byte IPv6 packets are of course supported >>>>> using fragmentation, large packets should be avoided at all >>>>> cost given the low bandwidth and low packet delivery success >>>>> rate. >>>>> >>>>> >>>>> >>>>> Given this, I do not understand the alignment requirements >>>>> specified in draft-ietf-roll-rpl-05 6.1.3.1.1.1 "Following >>>>> the convention in IPv6, these options are aligned in a packet >>>>> such that multi-octet values within the Option Data field of >>>>> each option fall on natural boundaries". It seems that it >>>>> would be more important to keep the messages short and avoid >>>>> padding options. I am also curious on allocating 16 bits for >>>>> a length field of a sub option. If sub option length >>>>> exceeding 255 bytes (as could be specified by 8 bits) are >>>>> needed, it seems that the routing messages are expected to >>>>> get very large. >>>>> >>>>> >>>>> >>>>> Regards, Peter Siklosi >>>>> >>>>> >>>>> >>>>> >>>>> ------------------------------------------------------------------------ >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> _______________________________________________ Roll mailing >>>>> list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll >>>>> >>>> _______________________________________________ Roll mailing >>>> list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll >>>> >>> _______________________________________________ Roll mailing list >>> Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll >>> >> _______________________________________________ Roll mailing list >> Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll >> > > > From alexandru.petrescu@gmail.com Fri Dec 11 09:20:05 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EBB0E3A69FB for ; Fri, 11 Dec 2009 09:20:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.541 X-Spam-Level: X-Spam-Status: No, score=-1.541 tagged_above=-999 required=5 tests=[AWL=-0.781, BAYES_05=-1.11, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9ZsofuMThxSR for ; Fri, 11 Dec 2009 09:20:03 -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 3DD8B3A69BB for ; Fri, 11 Dec 2009 09:20:03 -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 nBBHJoXp008175 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 11 Dec 2009 18:19:50 +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 nBBHJnW2025385; Fri, 11 Dec 2009 18:19:49 +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 nBBHJnB7015890; Fri, 11 Dec 2009 18:19:49 +0100 Message-ID: <4B227F35.4070807@gmail.com> Date: Fri, 11 Dec 2009 18:19:49 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Michael Richardson References: <4B1FDDC8.7030001@sics.se><4B203410.4030102@acm.org> <4B203C37.90207@gmail.com> <4B22223D.2020502@gmail.com> <20525.1260540454@localhost> In-Reply-To: <20525.1260540454@localhost> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: roll@ietf.org Subject: Re: [Roll] packet size issues X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 11 Dec 2009 17:20:05 -0000 Michael Richardson a écrit : > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > >>>>>> "Alexandru" == Alexandru Petrescu writes: > Alexandru> Hi, sorry - how much does one gain? Figures? > > Alexandru> For example, I doubt removal of few bytes here and there > Alexandru> are any gain in wireless bandwidth when considering that > Alexandru> the base header alone is 40bytes already, the ICMP header > Alexandru> is 8 bytes fixed, and so on. > > Alexandru> How much would one save compared to one _has_ to always > Alexandru> send? (between using or not using padding). > > Padding is only there so that we can have nicely 64-bit aligned items. Padding is there not only for beautifullness. There are real constraints for computing - Alignment. A processor trying to read a byte at an (memory) address which is not multiple of 4 will spend more cycles - ie more computing power, take longer, spend more energy. If the data in the buffer _is_ aligned at the most common order (I believe it to be 4 bytes now) then reading an arbitrary byte is much quicker. Consider "processor" to not be the current i7, but something similar to a 4004 or so, which has strong alignment necessities. > This is an IPv6 goal --- we can work with it, or work without it. IPv7 anyone? > The > padding doesn't need to be there if the payloads are all multiples of > 64-bits. Hmm, in a sense it's very good to have no padding, but I hope the important bytes are going to be easy to locate and read, and not necessitate expensive shifting on processors having no shifter. Absent that (please list the proc's on which RPL is going to work) - I prefer be conservative and keep padding. > The real overhead of the padding is the code space. To me, the overhead of _not_ using padding is code space, cycles, energy consumed. _Data_ space may be bigger when using padding. > It's nice to have > a way to "NOP" out some pieces, particularly if you want to reuse the > same memory that you received something (such as a DAO) when you send it > again upwards. > > >> Messages should preferably travel unfragmented, or else as very > >> few fragments, and this does certainly not leave many bytes for > >> say LoWPAN over > >> 802.15.4. > > Alexandru> When you say "fragmented" - do you mean IP fragmentation > Alexandru> (happening each 1280bytes) or link-layer fragmentation? > Alexandru> Traditionally, IPdoesn't care about the latter - why > Alexandru> should RPL care? > > No, he means 6lowpan fragmentation, below layer-3. I am not sure what 6lowpan fragmentation is. I do know what IP fragmentation is. Iprefer to consider the latter. Avoid cross-layer violation. > > Alexandru> I.e. I think a small 8bit micro-controller has strong > Alexandru> requirements on its memory alignment and addressing, > Alexandru> i.e. probably 32bits are addressed only at 32bit edges, > Alexandru> and not 8bit. Thus padded packets may help a lot when > Alexandru> addressing bytes within memory. > > Exactly. 32-bit accesses save power, and the only time we care about > padding if if we create payloads that are not multiples of that... Well, I agree. Alex > > > - -- > ] 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 > > iQEVAwUBSyJSI4CLcPvd0N1lAQKd6Af8CDkKbHctnOYAt7gS8V5jDcbzN2KO5yag > qqjdwmsQY44WQAXRw942L4UaCq4/XQo1l8b4UdTHb2/nShy1EGkRIcfPHuoYrALd > yQMsB6KAAfGeLkZK9+9O1hsKgV5U1q3HQxfFhx16p+t3jmwxbAiFS4DM5QehnfOb > 1lfHrDQy3R/OCph3HNsBGBH8CoyAxUP8hLMAtRsVntGJsW9BgUkowODXMW/7QBGx > NgnvcPvsdShHAz6t9mvICPJJbebHVUKUKSbqrlU1KIup7J5KL0spIQEViBsGP5oV > FnozOJGwZa7eMCpN+LyjwCEV8OEQb5XPDddeODkah1MC9mHMXjzNWA== > =aUlU > -----END PGP SIGNATURE----- > From alexandru.petrescu@gmail.com Fri Dec 11 09:31:24 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2F4023A6844 for ; Fri, 11 Dec 2009 09:31:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.266 X-Spam-Level: X-Spam-Status: No, score=-2.266 tagged_above=-999 required=5 tests=[AWL=-0.017, 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 bW2P-xw51MCT for ; Fri, 11 Dec 2009 09:31:23 -0800 (PST) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.166.172.107]) by core3.amsl.com (Postfix) with ESMTP id ABAFC3A67FE for ; Fri, 11 Dec 2009 09:31:22 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.0) with ESMTP id nBBHV6bx004167 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 11 Dec 2009 18:31:06 +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 nBBHV5lQ027072; Fri, 11 Dec 2009 18:31:05 +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 nBBHV5Fe031065; Fri, 11 Dec 2009 18:31:05 +0100 Message-ID: <4B2281D9.1010203@gmail.com> Date: Fri, 11 Dec 2009 18:31:05 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Matteo Paris References: <4B1FDDC8.7030001@sics.se> <4B203410.4030102@acm.org> <4B2222C1.7060105@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] packet size issues X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 11 Dec 2009 17:31:24 -0000 Matteo Paris a écrit : > > At 11:45 AM +0100 12/11/09, Alexandru Petrescu wrote: >> Well - make sure you know how much bandwidth you gain with this >> removal and how much additional computing power you require too. > > Hi Alex, I quite agree. I can offer my experience, which is a decade of > working on a variety of commercial wireless LLNs. Bandwidth and RAM > have always been the dominant bottlenecks and computing power not a > constraint. The tradeoff may be different on other LLN platforms of > course. Are there any where one would trade bandwidth and RAM for > processing speed? Hm... thinking... I agree that bandwidth and RAM are bottlenecks (compared to computing power)... but it's also easy to plug a 500Mbit/s "n" wifi card on a very low cpu such as a 600MHz pentium, in which case the bottleneck is the processor. I would not dare to eliminate padding and think IPv6 layout designers were not _already_ aware of any supposed relationships between bandwidth/cpu/ram. > As for fragmentation, due to medium acess overhead (at least in CSMA > systems), and link layer header duplication, if a common packet like DIO > goes from fitting into one packet to requiring fragmentation, it incurs > a substantial discrete performance and scalability penalty on the lowpan > >> Traditionally, IP doesn't care about [link layer fragmentation] - why >> should RPL care? ... let 802.15.4 do its fragmentation when it feels >> so, don't interfere with it. > > It would be nice if RPL did not need to care about the limitations of > the link layer, but if we had that luxury there would be no need for > roll and 6lowpan... and maybe that would be nice ;-). But in all > seriousness, the roll charter addresses this issue explicitly: > > " - In most cases, LLNs will be employed over link layers with > restricted frame-sizes, thus a routing protocol for LLNs should be > specifically adapted for such link layers." Right. I take these constraints as indication that RPL packets shouldn't be too large. For example I believe that's satisfied when we say we use ICMP instead of http. But going towards shortening the IPv6 address, or eliminating the base header, seems too much, IMHO. Alex > > Matteo > > >> >> Matteo Paris a écrit : >>> >>> I agree that we should remove alignment requirements and reduce the >>> suboption length field to 1 byte. >>> >>> As Peter wrote, if RPL is to work over constrained link layers, we >>> have to keep in mind the frame size and bandwidth constraints of >>> those layers. For example, in 802.15.4 after link-layer overhead, >>> the usable payload is only 81 bytes (see RFC4944). >> >> Well let 802.15.4 do its fragmentation when it feels so, don't >> interfere with it. >> >> I mean (one should, IMHO, etc), >> >> Alex >> >>> >>> Because limited bandwidth and large dense networks are a common use >>> case, it is desirable for a DIO message to fit in a single packet. >>> The current size of a DIO message not including the DAG Metric >>> Container is already 59 bytes (3 6lowpan ip header + 4 icmp header + >>> 20 base option + 25 dest prefix + 7 dag config). Padding could >>> increase this by tens of bytes. If the DAG Metric Container is longer >>> than 255 bytes I think it will pose serious challenges to RPL >>> operation over constrained link layers. >>> >>> Matteo >>> >>> >>> At 6:34 PM -0500 12/9/09, Tim Winter wrote: >>>> I agree with Peter that we should consider to remove alignment >>>> requirements- >>>> including the Pad1 and PadN options. I would expect that it is >>>> often cheaper >>>> (energy/time/processing) to handle the alignment issues in the >>>> implementation versus >>>> transporting extra padding over LLN links. >>>> >>>> The 16-bit sub-option length is driven by the DAG Metric Container. >>>> Perhaps once we >>>> begin to see some proposed objective functions we can better >>>> determine how large the >>>> Metric Container may need to be. Perhaps the DAG Metric Container >>>> could be chained >>>> such that each piece fits into 255 bytes or less... >>>> >>>> -Tim >>>> >>>> >>>> Joakim Eriksson wrote: >>>>> Hi Peter, >>>>> >>>>> I totally agree on the goal of minimizing packet sizes, but I would >>>>> like to keep alignment requirements since it simplifies >>>>> implementations. >>>>> I also think (as you mention) that we need to question the 16-bit >>>>> sub-option length. Is it really needed? Both IPv6 options and ICMPv6 >>>>> option lenghts are encoded as 8-bit values. Going down to 8-bits >>>>> would >>>>> also help the alignment of the options. >>>>> >>>>> >>>>> Best Regards, >>>>> -- Joakim Eriksson, SICS >>>>> >>>>> Peter Siklosi skrev: >>>>>> Hi all, >>>>>> >>>>>> >>>>>> >>>>>> If I understand correctly, RPL is designed to be usable with for >>>>>> instance 6LoWPAN on 802.15.4 with very limiting frame sizes. Even if >>>>>> 1280 byte IPv6 packets are of course supported using fragmentation, >>>>>> large packets should be avoided at all cost given the low bandwidth >>>>>> and low packet delivery success rate. >>>>>> >>>>>> >>>>>> >>>>>> Given this, I do not understand the alignment requirements specified >>>>>> in draft-ietf-roll-rpl-05 6.1.3.1.1.1 "Following the convention in >>>>>> IPv6, these options are aligned in a packet such that multi-octet >>>>>> values within the Option Data field of each option fall on natural >>>>>> boundaries". It seems that it would be more important to keep the >>>>>> messages short and avoid padding options. I am also curious on >>>>>> allocating 16 bits for a length field of a sub option. If sub option >>>>>> length exceeding 255 bytes (as could be specified by 8 bits) are >>>>>> needed, it seems that the routing messages are expected to get very >>>>>> large. >>>>>> >>>>>> >>>>>> >>>>>> Regards, >>>>>> Peter Siklosi >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> ------------------------------------------------------------------------ >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Roll mailing list >>>>>> Roll@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/roll >>>>> >>>>> _______________________________________________ >>>>> Roll mailing list >>>>> Roll@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/roll >>>>> >>>> _______________________________________________ >>>> Roll mailing list >>>> Roll@ietf.org >>>> https://www.ietf.org/mailman/listinfo/roll >>> >>> _______________________________________________ >>> Roll mailing list >>> Roll@ietf.org >>> https://www.ietf.org/mailman/listinfo/roll > > From alexandru.petrescu@gmail.com Fri Dec 11 09:35:38 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D6B3A3A6832 for ; Fri, 11 Dec 2009 09:35:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[AWL=-0.016, 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 IX4DpH5X+lGm for ; Fri, 11 Dec 2009 09:35:36 -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 2C3073A67FE for ; Fri, 11 Dec 2009 09:35:36 -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 nBBHYtIX017704 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 11 Dec 2009 18:34:55 +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 nBBHYs7r027722; Fri, 11 Dec 2009 18:34:55 +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 nBBHYsXb032099; Fri, 11 Dec 2009 18:34:54 +0100 Message-ID: <4B2282BE.9060507@gmail.com> Date: Fri, 11 Dec 2009 18:34:54 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Mukul Goyal References: <645896496.9714841260541942388.JavaMail.root@mail02.pantherlink.uwm.edu> In-Reply-To: <645896496.9714841260541942388.JavaMail.root@mail02.pantherlink.uwm.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: ROLL WG Subject: Re: [Roll] Potential RPL Enhancements X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 11 Dec 2009 17:35:38 -0000 Mukul Goyal a écrit : > JP > > "We reached a point where the protocol is getting stable with all must- > have features (except security, our next top priority item)." > > I am not sure if many people are convinced regarding the suitability of RPL for P2P routing. I agree with the doubts. I was struck to see the comment by JP too... - enhancements? Do we have a basis? It may have been a wrong interpretation though... Alex > > Thanks > Mukul > > ----- Original Message ----- > From: "JP Vasseur" > To: "ROLL WG" > Sent: Friday, December 11, 2009 8:20:26 AM GMT -06:00 US/Canada Central > Subject: [Roll] Potential RPL Enhancements > > Dear all, > > As a follow up to my previous email with regards to the version 05 of > RPL, I wanted to elaborate a little bit on the process that we will be > following with regards to further RPL enhancements. > > We reached a point where the protocol is getting stable with all must- > have features (except security, our next top priority item). It is now > time to get feed-back from implementers. > > There will of course be proposals to enhance and improve the protocol > and here is the proposed way to proceed: > > 1) If there is a request to modify RPL because an issue has been > found, a ticket will be opened and the issue will be solved. > 2) If there is "nice to have" enhancements, we'll open a ticket > flagged as "enhancement", to be addressed at some point (e.g. DIS > enhancement) > 3) New features will be addressed in separate documents. > > Plan for rev-06 and -07: > 1) clarification and potential enhancements to DAO processing > 2) potentially DAO packing if it is shown that such mechanism is needed > 3) Security > > Thanks. > > JP. > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > From Jerald.P.Martocci@jci.com Fri Dec 11 10:25:58 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 89ED93A699D; Fri, 11 Dec 2009 10:25:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.373 X-Spam-Level: X-Spam-Status: No, score=-6.373 tagged_above=-999 required=5 tests=[AWL=0.225, 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 6bqRcisAgwwr; Fri, 11 Dec 2009 10:25:57 -0800 (PST) Received: from exprod8og113.obsmtp.com (exprod8og113.obsmtp.com [64.18.3.26]) by core3.amsl.com (Postfix) with ESMTP id 172AE3A6999; Fri, 11 Dec 2009 10:25:57 -0800 (PST) Received: from source ([192.132.24.139]) (using SSLv3) by exprod8ob113.postini.com ([64.18.7.12]) with SMTP ID DSNKSyKOqK2XVir2I+ZY0eVbk+sxBYlic8yf@postini.com; Fri, 11 Dec 2009 10:25:46 PST Received: from jwimkrs1.na.jci.com ([10.10.6.31]) by smtpmke02.jci.com (Lotus Domino Release 8.0.1) with ESMTP id 2009121112312257-1691535 ; Fri, 11 Dec 2009 12:31:22 -0600 In-Reply-To: <46A68908-B700-47D1-92CC-0C56B21C98F5@cisco.com> MIME-Version: 1.0 To: JP Vasseur X-Mailer: Lotus Notes Release 6.5.2 June 01, 2004 From: Jerald.P.Martocci@jci.com Message-ID: Date: Fri, 11 Dec 2009 12:25:35 -0600 X-MIMETrack: Serialize by Router on jwimkrs1.na.jci.com/NA/Johnson_Controls at 12/11/2009 12:25:38 PM, Serialize complete at 12/11/2009 12:25:38 PM, Itemize by SMTP Server on smtpmke02.jci.com/JCI_SMTP(Release 8.0.1|February 07, 2008) at 12/11/2009 12:31:22 PM, Serialize by Router on smtpmke02.jci.com/JCI_SMTP(Release 8.0.1|February 07, 2008) at 12/11/2009 12:31:29 PM, Serialize complete at 12/11/2009 12:31:29 PM Content-Type: multipart/alternative; boundary="=_alternative 006537DF86257689_=" Cc: ROLL WG , roll-bounces@ietf.org Subject: Re: [Roll] Potential RPL Enhancements X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 11 Dec 2009 18:25:58 -0000 This is a multipart message in MIME format. --=_alternative 006537DF86257689_= Content-Type: text/plain; charset="US-ASCII" JP, Can you please clearly explain your position on P2P messaging. In September, you stated that P2P messaging would be added to a future RPL version. It now seems to have slipped off your 'to do' list. I'd like a clear understanding when there will be a robust method for passing packets between two LLN nodes efficiently. Thanks, Jerry JP Vasseur Sent by: roll-bounces@ietf.org 12/11/2009 08:20 AM To ROLL WG cc Subject [Roll] Potential RPL Enhancements Dear all, As a follow up to my previous email with regards to the version 05 of RPL, I wanted to elaborate a little bit on the process that we will be following with regards to further RPL enhancements. We reached a point where the protocol is getting stable with all must- have features (except security, our next top priority item). It is now time to get feed-back from implementers. There will of course be proposals to enhance and improve the protocol and here is the proposed way to proceed: 1) If there is a request to modify RPL because an issue has been found, a ticket will be opened and the issue will be solved. 2) If there is "nice to have" enhancements, we'll open a ticket flagged as "enhancement", to be addressed at some point (e.g. DIS enhancement) 3) New features will be addressed in separate documents. Plan for rev-06 and -07: 1) clarification and potential enhancements to DAO processing 2) potentially DAO packing if it is shown that such mechanism is needed 3) Security Thanks. JP. _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll --=_alternative 006537DF86257689_= Content-Type: text/html; charset="US-ASCII"

JP,

Can you please clearly explain your position on P2P messaging.   In September, you stated that P2P messaging would be added to a future RPL version.  It now seems to have slipped off your 'to do' list.  I'd like a clear understanding when there will be a robust method for passing packets between two LLN nodes efficiently.

Thanks,

Jerry






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

12/11/2009 08:20 AM

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





Dear all,

As a follow up to my previous email with regards to the version 05 of  
RPL, I wanted to elaborate a little bit on the process that we will be  
following with regards to further RPL enhancements.

We reached a point where the protocol is getting stable with all must-
have features (except security, our next top priority item). It is now  
time to get feed-back from implementers.

There will of course be proposals to enhance and improve the protocol  
and here is the proposed way to proceed:

1) If there is a request to modify RPL because an issue has been  
found, a ticket will be opened and the issue will be solved.
2) If there is "nice to have" enhancements, we'll open a ticket  
flagged as "enhancement", to be addressed at some point (e.g. DIS  
enhancement)
3) New features will be addressed in separate documents.

Plan for rev-06 and -07:
1) clarification and potential enhancements to DAO processing
2) potentially DAO packing if it is shown that such mechanism is needed
3) Security

Thanks.

JP.
_______________________________________________
Roll mailing list
Roll@ietf.org
https://www.ietf.org/mailman/listinfo/roll
--=_alternative 006537DF86257689_=-- From pister@eecs.berkeley.edu Mon Dec 14 16:42:50 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1526D3A6872 for ; Mon, 14 Dec 2009 16:42:50 -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=[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 NINmllJeav82 for ; Mon, 14 Dec 2009 16:42:49 -0800 (PST) Received: from gateway0.EECS.Berkeley.EDU (gateway0.EECS.Berkeley.EDU [169.229.60.87]) by core3.amsl.com (Postfix) with ESMTP id 2E8243A685B for ; Mon, 14 Dec 2009 16:42:49 -0800 (PST) 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.3/8.13.5) with ESMTP id nBF0gWau012146 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 14 Dec 2009 16:42:34 -0800 (PST) Message-ID: <4B26DB78.4050602@eecs.berkeley.edu> Date: Mon, 14 Dec 2009 16:42:32 -0800 From: Kris Pister User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Joakim Eriksson References: <4B1FDDC8.7030001@sics.se> In-Reply-To: <4B1FDDC8.7030001@sics.se> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: roll@ietf.org, Peter Siklosi Subject: Re: [Roll] packet size issues X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 15 Dec 2009 00:42:50 -0000 Joakim - can you say more about how important alignment is in simplifying implementations? In my experience, alignment or its absence doesn't have a big impact on code complexity. On the motes that I've used, in the 8 bit processors (e.g. AVR) memory access on byte boundaries is what you get. On 16 bit processors (e.g. MSP430), there's support for byte operations. On the 32 bit embedded processors (e.g. ARM7, Cortex-M3), there's a *lot* of support for byte and two-byte operations. Alex - it's worth thinking about your energy question. The cost of sending a byte over the radio is on the order of (20mW)*(8bits)/(250kbps) = 640 nJ The cost of a single processor cycle is on the order of (1mW/MHz)/(10^6 cycles/MHz) = 1nJ So from an energy perspective, we'd rather spend hundreds of cycles than send or receive a single byte. ksjp Joakim Eriksson wrote: > Hi Peter, > > I totally agree on the goal of minimizing packet sizes, but I would > like to keep alignment requirements since it simplifies implementations. > I also think (as you mention) that we need to question the 16-bit > sub-option length. Is it really needed? Both IPv6 options and ICMPv6 > option lenghts are encoded as 8-bit values. Going down to 8-bits would > also help the alignment of the options. > > > Best Regards, > -- Joakim Eriksson, SICS > > Peter Siklosi skrev: >> Hi all, >> >> >> >> If I understand correctly, RPL is designed to be usable with for >> instance 6LoWPAN on 802.15.4 with very limiting frame sizes. Even if >> 1280 byte IPv6 packets are of course supported using fragmentation, >> large packets should be avoided at all cost given the low bandwidth >> and low packet delivery success rate. >> >> >> >> Given this, I do not understand the alignment requirements specified >> in draft-ietf-roll-rpl-05 6.1.3.1.1.1 “Following the convention in >> IPv6, these options are aligned in a packet such that multi-octet >> values within the Option Data field of each option fall on natural >> boundaries”. It seems that it would be more important to keep the >> messages short and avoid padding options. I am also curious on >> allocating 16 bits for a length field of a sub option. If sub option >> length exceeding 255 bytes (as could be specified by 8 bits) are >> needed, it seems that the routing messages are expected to get very >> large. >> >> >> >> Regards, >> Peter Siklosi >> >> >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> Roll mailing 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 joakime@sics.se Tue Dec 15 00:20:56 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DBB4D3A67BD for ; Tue, 15 Dec 2009 00:20:56 -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 q0DLaP2g2sBr for ; Tue, 15 Dec 2009 00:20:55 -0800 (PST) Received: from proxy3.bredband.net (proxy3.bredband.net [195.54.101.73]) by core3.amsl.com (Postfix) with ESMTP id 598203A688C for ; Tue, 15 Dec 2009 00:20:54 -0800 (PST) Received: from ipb2.telenor.se (195.54.127.165) by proxy3.bredband.net (7.3.140.3) id 4AD3E1BA01A658B7 for roll@ietf.org; Tue, 15 Dec 2009 09:20:40 +0100 X-SMTPAUTH-B2: X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4xAMXVJktV5BbdPGdsb2JhbAAImGWCRwEBAQE3u3GEKwSBYotB X-IronPort-AV: E=Sophos;i="4.47,399,1257116400"; d="scan'208";a="15760856" Received: from c-dd16e455.013-276-73746f7.cust.bredbandsbolaget.se (HELO [127.0.0.1]) ([85.228.22.221]) by ipb2.telenor.se with ESMTP; 15 Dec 2009 09:20:39 +0100 Message-ID: <4B2746DB.5040203@sics.se> Date: Tue, 15 Dec 2009 09:20:43 +0100 From: Joakim Eriksson User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Kris Pister References: <4B1FDDC8.7030001@sics.se> <4B26DB78.4050602@eecs.berkeley.edu> In-Reply-To: <4B26DB78.4050602@eecs.berkeley.edu> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: roll@ietf.org, Peter Siklosi Subject: Re: [Roll] packet size issues X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 15 Dec 2009 08:20:57 -0000 The thing that can be made when data is aligned is mapping (type-cast) the incoming data into structs without risking that the struct is automatically "padded" for alignment. If we do not have alignment in the packets this is impossible on processors above 8-bits. Best regards, -- Joakim Eriksson, SICS Kris Pister skrev: > Joakim - can you say more about how important alignment is in > simplifying implementations? > In my experience, alignment or its absence doesn't have a big impact on > code complexity. > On the motes that I've used, in the 8 bit processors (e.g. AVR) memory > access on byte boundaries is what you get. On 16 bit processors (e.g. > MSP430), there's support for byte operations. On the 32 bit embedded > processors (e.g. ARM7, Cortex-M3), there's a *lot* of support for byte > and two-byte operations. > > Alex - it's worth thinking about your energy question. The cost of > sending a byte over the radio is on the order of > (20mW)*(8bits)/(250kbps) = 640 nJ > The cost of a single processor cycle is on the order of (1mW/MHz)/(10^6 > cycles/MHz) = 1nJ > So from an energy perspective, we'd rather spend hundreds of cycles than > send or receive a single byte. > > ksjp > > Joakim Eriksson wrote: >> Hi Peter, >> >> I totally agree on the goal of minimizing packet sizes, but I would >> like to keep alignment requirements since it simplifies implementations. >> I also think (as you mention) that we need to question the 16-bit >> sub-option length. Is it really needed? Both IPv6 options and ICMPv6 >> option lenghts are encoded as 8-bit values. Going down to 8-bits would >> also help the alignment of the options. >> >> >> Best Regards, >> -- Joakim Eriksson, SICS >> >> Peter Siklosi skrev: >>> Hi all, >>> >>> >>> >>> If I understand correctly, RPL is designed to be usable with for >>> instance 6LoWPAN on 802.15.4 with very limiting frame sizes. Even if >>> 1280 byte IPv6 packets are of course supported using fragmentation, >>> large packets should be avoided at all cost given the low bandwidth >>> and low packet delivery success rate. >>> >>> >>> >>> Given this, I do not understand the alignment requirements specified >>> in draft-ietf-roll-rpl-05 6.1.3.1.1.1 “Following the convention in >>> IPv6, these options are aligned in a packet such that multi-octet >>> values within the Option Data field of each option fall on natural >>> boundaries”. It seems that it would be more important to keep the >>> messages short and avoid padding options. I am also curious on >>> allocating 16 bits for a length field of a sub option. If sub option >>> length exceeding 255 bytes (as could be specified by 8 bits) are >>> needed, it seems that the routing messages are expected to get very >>> large. >>> >>> >>> >>> Regards, >>> Peter Siklosi >>> >>> >>> >>> >>> ------------------------------------------------------------------------ >>> >>> _______________________________________________ >>> Roll mailing 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 Peter.Siklosi@tritech.se Tue Dec 15 01:36:27 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 23C753A6958 for ; Tue, 15 Dec 2009 01:36:27 -0800 (PST) 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=-0.052, BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_31=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 vMtma+jsL6aE for ; Tue, 15 Dec 2009 01:36:26 -0800 (PST) Received: from tritech.se (tritech.se [91.191.137.61]) by core3.amsl.com (Postfix) with ESMTP id E16C13A6915 for ; Tue, 15 Dec 2009 01:36:25 -0800 (PST) Received: from srvsund01.tritech.se (srvsund01.tritech.se [10.75.60.4]) by tritech.se (8.14.3/8.14.3) with ESMTP id nBF9Zvqc013464; Tue, 15 Dec 2009 10:35:57 +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, 15 Dec 2009 10:35:56 +0100 Message-ID: In-Reply-To: <4B2746DB.5040203@sics.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] packet size issues Thread-Index: Acp9X36hUultpxuGRnGC6BbUb1k+eAACCeIA References: <4B1FDDC8.7030001@sics.se> <4B26DB78.4050602@eecs.berkeley.edu> <4B2746DB.5040203@sics.se> From: "Peter Siklosi" To: "Joakim Eriksson" , "Kris Pister" X-CT-RefID: str=0001.0A3C0009.4B275875.008A,ss=1,fgs=0 Cc: roll@ietf.org Subject: Re: [Roll] packet size issues X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 15 Dec 2009 09:36:27 -0000 In general, I think that you can store data in a struct in whatever way = you like and then have serialization and deserialization functions = taking care of reading the received byte sequence and putting the right = data into the struct and the other way around. These routines can also = take care of byte ordering and other issues. Getting meshed LLN:s to = work well can be a challenge in itself and making sure to keep the = packets short helps. The ability to take some shortcuts in = serialization/deserialization is a non-issue as far as I see it. It does = not make sense to have 6LoWPAN trying very hard to reduce packet size = and then waste it in RPL.. Regards, Peter -----Ursprungligt meddelande----- Fr=E5n: Joakim Eriksson [mailto:joakime@sics.se]=20 Skickat: den 15 december 2009 09:21 Till: Kris Pister Kopia: Peter Siklosi; roll@ietf.org =C4mne: Re: [Roll] packet size issues The thing that can be made when data is aligned is mapping (type-cast) the incoming data into structs without risking that the struct is automatically "padded" for alignment. If we do not have alignment in the packets this is impossible on processors above 8-bits. Best regards, -- Joakim Eriksson, SICS Kris Pister skrev: > Joakim - can you say more about how important alignment is in=20 > simplifying implementations? > In my experience, alignment or its absence doesn't have a big impact = on=20 > code complexity. > On the motes that I've used, in the 8 bit processors (e.g. AVR) memory = > access on byte boundaries is what you get. On 16 bit processors (e.g. = > MSP430), there's support for byte operations. On the 32 bit embedded=20 > processors (e.g. ARM7, Cortex-M3), there's a *lot* of support for byte = > and two-byte operations. >=20 > Alex - it's worth thinking about your energy question. The cost of=20 > sending a byte over the radio is on the order of=20 > (20mW)*(8bits)/(250kbps) =3D 640 nJ > The cost of a single processor cycle is on the order of = (1mW/MHz)/(10^6=20 > cycles/MHz) =3D 1nJ > So from an energy perspective, we'd rather spend hundreds of cycles = than=20 > send or receive a single byte. >=20 > ksjp >=20 > Joakim Eriksson wrote: >> Hi Peter, >> >> I totally agree on the goal of minimizing packet sizes, but I would >> like to keep alignment requirements since it simplifies = implementations. >> I also think (as you mention) that we need to question the 16-bit >> sub-option length. Is it really needed? Both IPv6 options and ICMPv6=20 >> option lenghts are encoded as 8-bit values. Going down to 8-bits = would >> also help the alignment of the options. >> >> >> Best Regards, >> -- Joakim Eriksson, SICS >> >> Peter Siklosi skrev: >>> Hi all, >>> >>> =20 >>> >>> If I understand correctly, RPL is designed to be usable with for=20 >>> instance 6LoWPAN on 802.15.4 with very limiting frame sizes. Even if = >>> 1280 byte IPv6 packets are of course supported using fragmentation,=20 >>> large packets should be avoided at all cost given the low bandwidth=20 >>> and low packet delivery success rate. >>> >>> =20 >>> >>> Given this, I do not understand the alignment requirements specified = >>> in draft-ietf-roll-rpl-05 6.1.3.1.1.1 "Following the convention in=20 >>> IPv6, these options are aligned in a packet such that multi-octet=20 >>> values within the Option Data field of each option fall on natural=20 >>> boundaries". It seems that it would be more important to keep the=20 >>> messages short and avoid padding options. I am also curious on=20 >>> allocating 16 bits for a length field of a sub option. If sub option = >>> length exceeding 255 bytes (as could be specified by 8 bits) are=20 >>> needed, it seems that the routing messages are expected to get very=20 >>> large. >>> >>> =20 >>> >>> Regards, >>> Peter Siklosi >>> >>> =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 joakime@sics.se Tue Dec 15 02:02:47 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7F7BD3A6991 for ; Tue, 15 Dec 2009 02:02:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.649 X-Spam-Level: X-Spam-Status: No, score=-1.649 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_31=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 fLpkglDdGexX for ; Tue, 15 Dec 2009 02:02:46 -0800 (PST) Received: from letter.sics.se (letter.sics.se [193.10.64.6]) by core3.amsl.com (Postfix) with ESMTP id 6FCD33A67B3 for ; Tue, 15 Dec 2009 02:02:46 -0800 (PST) Received: from [127.0.0.1] (grayling.sics.se [193.10.67.143]) by letter.sics.se (Postfix) with ESMTP id D5B48400F0; Tue, 15 Dec 2009 11:02:31 +0100 (CET) Message-ID: <4B275EB0.7030906@sics.se> Date: Tue, 15 Dec 2009 11:02:24 +0100 From: Joakim Eriksson User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Peter Siklosi References: <4B1FDDC8.7030001@sics.se> <4B26DB78.4050602@eecs.berkeley.edu> <4B2746DB.5040203@sics.se> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: roll@ietf.org Subject: Re: [Roll] packet size issues X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 15 Dec 2009 10:02:47 -0000 Peter Siklosi wrote: > In general, I think that you can store data in a struct in > whatever way you like and then have serialization and > deserialization functions taking care of reading the > received byte sequence and putting the right data into the > struct and the other way around. These routines can also > take care of byte ordering and other issues. Getting > meshed LLN:s to work well can be a challenge in > itself and making sure to keep the packets short helps. > The ability to take some shortcuts in serialization/deserialization > is a non-issue as far as I see it. It is not a very big issue but it makes the code smaller and more efficient (since there is no need for a copy/deserialization). > It does not make sense to have > 6LoWPAN trying very hard to reduce packet size and then waste it > in RPL. I definitively agree with this. But I think that we can keep alignment and avoid too much padding if we place the different options and fields in smart ways. How much padding would we currently get in a typical case (assuming that we get rid of the already non-aligned 16-bit lenght of the sub-option)? Best regards, -- Joakim Eriksson, SICS > Regards, > Peter > > -----Ursprungligt meddelande----- > Från: Joakim Eriksson [mailto:joakime@sics.se] > Skickat: den 15 december 2009 09:21 > Till: Kris Pister > Kopia: Peter Siklosi; roll@ietf.org > Ämne: Re: [Roll] packet size issues > > The thing that can be made when data is aligned is mapping > (type-cast) the incoming data into structs without > risking that the struct is automatically "padded" for > alignment. If we do not have alignment in the packets this > is impossible on processors above 8-bits. > > > Best regards, > -- Joakim Eriksson, SICS > > Kris Pister skrev: >> Joakim - can you say more about how important alignment is in >> simplifying implementations? >> In my experience, alignment or its absence doesn't have a big impact on >> code complexity. >> On the motes that I've used, in the 8 bit processors (e.g. AVR) memory >> access on byte boundaries is what you get. On 16 bit processors (e.g. >> MSP430), there's support for byte operations. On the 32 bit embedded >> processors (e.g. ARM7, Cortex-M3), there's a *lot* of support for byte >> and two-byte operations. >> >> Alex - it's worth thinking about your energy question. The cost of >> sending a byte over the radio is on the order of >> (20mW)*(8bits)/(250kbps) = 640 nJ >> The cost of a single processor cycle is on the order of (1mW/MHz)/(10^6 >> cycles/MHz) = 1nJ >> So from an energy perspective, we'd rather spend hundreds of cycles than >> send or receive a single byte. >> >> ksjp >> >> Joakim Eriksson wrote: >>> Hi Peter, >>> >>> I totally agree on the goal of minimizing packet sizes, but I would >>> like to keep alignment requirements since it simplifies implementations. >>> I also think (as you mention) that we need to question the 16-bit >>> sub-option length. Is it really needed? Both IPv6 options and ICMPv6 >>> option lenghts are encoded as 8-bit values. Going down to 8-bits would >>> also help the alignment of the options. >>> >>> >>> Best Regards, >>> -- Joakim Eriksson, SICS >>> >>> Peter Siklosi skrev: >>>> Hi all, >>>> >>>> >>>> >>>> If I understand correctly, RPL is designed to be usable with for >>>> instance 6LoWPAN on 802.15.4 with very limiting frame sizes. Even if >>>> 1280 byte IPv6 packets are of course supported using fragmentation, >>>> large packets should be avoided at all cost given the low bandwidth >>>> and low packet delivery success rate. >>>> >>>> >>>> >>>> Given this, I do not understand the alignment requirements specified >>>> in draft-ietf-roll-rpl-05 6.1.3.1.1.1 "Following the convention in >>>> IPv6, these options are aligned in a packet such that multi-octet >>>> values within the Option Data field of each option fall on natural >>>> boundaries". It seems that it would be more important to keep the >>>> messages short and avoid padding options. I am also curious on >>>> allocating 16 bits for a length field of a sub option. If sub option >>>> length exceeding 255 bytes (as could be specified by 8 bits) are >>>> needed, it seems that the routing messages are expected to get very >>>> large. >>>> >>>> >>>> >>>> Regards, >>>> Peter Siklosi >>>> >>>> >>>> >>>> >>>> ------------------------------------------------------------------------ >>>> >>>> _______________________________________________ >>>> Roll mailing 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 paul.chilton@jennic.com Tue Dec 15 02:24:31 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8EBAD3A6819 for ; Tue, 15 Dec 2009 02:24:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.446 X-Spam-Level: X-Spam-Status: No, score=-1.446 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_31=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 f54PRAYIWy3s for ; Tue, 15 Dec 2009 02:24:30 -0800 (PST) Received: from mail.jennic.com (proxy.jennic.co.uk [213.143.5.74]) by core3.amsl.com (Postfix) with ESMTP id BA9D43A6984 for ; Tue, 15 Dec 2009 02:24:27 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.jennic.com (Postfix) with ESMTP id 65224D6BAA; Tue, 15 Dec 2009 10:24:12 +0000 (GMT) Received: from mail.jennic.com ([127.0.0.1]) by localhost (smithers.jennic.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ex6kIK-a639p; Tue, 15 Dec 2009 10:24:12 +0000 (GMT) Received: from [10.99.98.249] (pc1lp.jennic.com [10.99.98.249]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mail.jennic.com (Postfix) with ESMTPSA id 39969D6BA1; Tue, 15 Dec 2009 10:24:12 +0000 (GMT) Message-ID: <4B2763CC.3020402@jennic.com> Date: Tue, 15 Dec 2009 10:24:12 +0000 From: Paul Chilton User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Joakim Eriksson References: <4B1FDDC8.7030001@sics.se> <4B26DB78.4050602@eecs.berkeley.edu> <4B2746DB.5040203@sics.se> <4B275EB0.7030906@sics.se> In-Reply-To: <4B275EB0.7030906@sics.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: roll@ietf.org, Peter.Siklosi@tritech.se Subject: Re: [Roll] packet size issues X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: paul.chilton@jennic.com List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Dec 2009 10:24:31 -0000 My preference would be for byte alignment of all fields (ie bit padding if necessary) and serialize/deserialize access to the raw received packet. The overhead of the extra code in my opinion is far outweighed by the need to keep the overall amount of redundant data transmitted in a frame to an absolute minimum both from the point of view of maximising payload space and in the worst case causing fragmentation Joakim Eriksson wrote: > Peter Siklosi wrote: >> In general, I think that you can store data in a struct in > > whatever way you like and then have serialization and > > deserialization functions taking care of reading the > > received byte sequence and putting the right data into the >> struct and the other way around. These routines can also > > take care of byte ordering and other issues. Getting > > meshed LLN:s to work well can be a challenge in > > itself and making sure to keep the packets short helps. >> The ability to take some shortcuts in serialization/deserialization > > is a non-issue as far as I see it. > > It is not a very big issue but it makes the code smaller and > more efficient (since there is no need for a copy/deserialization). > >> It does not make sense to have > > 6LoWPAN trying very hard to reduce packet size and then waste it > > in RPL. > > I definitively agree with this. But I think that we can keep > alignment and avoid too much padding if we place the different > options and fields in smart ways. > > How much padding would we currently get in a typical case (assuming > that we get rid of the already non-aligned 16-bit lenght of the > sub-option)? > > > Best regards, > -- Joakim Eriksson, SICS > >> Regards, >> Peter >> >> -----Ursprungligt meddelande----- >> Från: Joakim Eriksson [mailto:joakime@sics.se] Skickat: den 15 >> december 2009 09:21 >> Till: Kris Pister >> Kopia: Peter Siklosi; roll@ietf.org >> Ämne: Re: [Roll] packet size issues >> >> The thing that can be made when data is aligned is mapping >> (type-cast) the incoming data into structs without >> risking that the struct is automatically "padded" for >> alignment. If we do not have alignment in the packets this >> is impossible on processors above 8-bits. >> >> >> Best regards, >> -- Joakim Eriksson, SICS >> >> Kris Pister skrev: >>> Joakim - can you say more about how important alignment is in >>> simplifying implementations? >>> In my experience, alignment or its absence doesn't have a big impact >>> on code complexity. >>> On the motes that I've used, in the 8 bit processors (e.g. AVR) >>> memory access on byte boundaries is what you get. On 16 bit >>> processors (e.g. MSP430), there's support for byte operations. On >>> the 32 bit embedded processors (e.g. ARM7, Cortex-M3), there's a >>> *lot* of support for byte and two-byte operations. >>> >>> Alex - it's worth thinking about your energy question. The cost of >>> sending a byte over the radio is on the order of >>> (20mW)*(8bits)/(250kbps) = 640 nJ >>> The cost of a single processor cycle is on the order of >>> (1mW/MHz)/(10^6 cycles/MHz) = 1nJ >>> So from an energy perspective, we'd rather spend hundreds of cycles >>> than send or receive a single byte. >>> >>> ksjp >>> >>> Joakim Eriksson wrote: >>>> Hi Peter, >>>> >>>> I totally agree on the goal of minimizing packet sizes, but I would >>>> like to keep alignment requirements since it simplifies >>>> implementations. >>>> I also think (as you mention) that we need to question the 16-bit >>>> sub-option length. Is it really needed? Both IPv6 options and >>>> ICMPv6 option lenghts are encoded as 8-bit values. Going down to >>>> 8-bits would >>>> also help the alignment of the options. >>>> >>>> >>>> Best Regards, >>>> -- Joakim Eriksson, SICS >>>> >>>> Peter Siklosi skrev: >>>>> Hi all, >>>>> >>>>> >>>>> >>>>> If I understand correctly, RPL is designed to be usable with for >>>>> instance 6LoWPAN on 802.15.4 with very limiting frame sizes. Even >>>>> if 1280 byte IPv6 packets are of course supported using >>>>> fragmentation, large packets should be avoided at all cost given >>>>> the low bandwidth and low packet delivery success rate. >>>>> >>>>> >>>>> >>>>> Given this, I do not understand the alignment requirements >>>>> specified in draft-ietf-roll-rpl-05 6.1.3.1.1.1 "Following the >>>>> convention in IPv6, these options are aligned in a packet such >>>>> that multi-octet values within the Option Data field of each >>>>> option fall on natural boundaries". It seems that it would be more >>>>> important to keep the messages short and avoid padding options. I >>>>> am also curious on allocating 16 bits for a length field of a sub >>>>> option. If sub option length exceeding 255 bytes (as could be >>>>> specified by 8 bits) are needed, it seems that the routing >>>>> messages are expected to get very large. >>>>> >>>>> >>>>> >>>>> Regards, >>>>> Peter Siklosi >>>>> >>>>> >>>>> >>>>> >>>>> ------------------------------------------------------------------------ >>>>> >>>>> >>>>> _______________________________________________ >>>>> Roll mailing list >>>>> Roll@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/roll >>>> _______________________________________________ >>>> Roll mailing list >>>> Roll@ietf.org >>>> https://www.ietf.org/mailman/listinfo/roll >> > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > From root@core3.amsl.com Wed Dec 16 03:30:01 2009 Return-Path: X-Original-To: roll@ietf.org Delivered-To: roll@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id E7C273A6970; Wed, 16 Dec 2009 03: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: <20091216113001.E7C273A6970@core3.amsl.com> Date: Wed, 16 Dec 2009 03:30:01 -0800 (PST) Cc: roll@ietf.org Subject: [Roll] I-D Action:draft-ietf-roll-of0-00.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Dec 2009 11: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 Objective Function 0 Author(s) : P. Thubert Filename : draft-ietf-roll-of0-00.txt Pages : 8 Date : 2009-12-16 The Routing Protocol for Low Power and Lossy Networks (RPL) defines a generic Distance Vector protocol for Low Power and Lossy Networks (LLNs). RPL is instantiated to honor a particular routing objective/ constraint by the adding a specific Objective Function (OF) that is designed to solve that problem. This specification defines a basic OF, OF0, that uses only the abstract properties exposed in RPL messages to maximize connectivity. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-roll-of0-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-of0-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-12-16032205.I-D@ietf.org> --NextPart-- From alexandru.petrescu@gmail.com Wed Dec 16 12:26:12 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 797363A6A61 for ; Wed, 16 Dec 2009 12:26:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.44 X-Spam-Level: X-Spam-Status: No, score=-0.44 tagged_above=-999 required=5 tests=[AWL=-1.205, BAYES_40=-0.185, HELO_EQ_FR=0.35, J_CHICKENPOX_31=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 91VCRoRFwgVz for ; Wed, 16 Dec 2009 12:26:11 -0800 (PST) Received: from smtp5-g21.free.fr (smtp5-g21.free.fr [212.27.42.5]) by core3.amsl.com (Postfix) with ESMTP id 139393A6A5A for ; Wed, 16 Dec 2009 12:26:09 -0800 (PST) Received: from smtp5-g21.free.fr (localhost [127.0.0.1]) by smtp5-g21.free.fr (Postfix) with ESMTP id 644E8D48082; Wed, 16 Dec 2009 21:25:50 +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 D24E1D480D9; Wed, 16 Dec 2009 21:25:47 +0100 (CET) Message-ID: <4B294248.5090503@gmail.com> Date: Wed, 16 Dec 2009 21:25:44 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Peter Siklosi References: <4B1FDDC8.7030001@sics.se> <4B26DB78.4050602@eecs.berkeley.edu> <4B2746DB.5040203@sics.se> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 091216-0, 16/12/2009), Outbound message X-Antivirus-Status: Clean Cc: roll@ietf.org Subject: Re: [Roll] packet size issues X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 16 Dec 2009 20:26:12 -0000 Peter Siklosi a écrit : > In general, I think that you can store data in a struct in whatever > way you like and then have serialization and deserialization > functions taking care of reading the received byte sequence and > putting the right data into the struct and the other way around. > These routines can also take care of byte ordering and other issues. > Getting meshed LLN:s to work well can be a challenge in itself and > making sure to keep the packets short helps. The ability to take some > shortcuts in serialization/deserialization is a non-issue as far as I > see it. It does not make sense to have 6LoWPAN trying very hard to > reduce packet size and then waste it in RPL.. WEll... Which part of 6LoWPAN do you refer to to try very hard to reduce packet size? 6LoWPAN Header Compression draft-ietf-6lowpan-hc-06.txt? Does that compress ICMP headers? I don't think 6LoWPAN HC understands ICMP at all. RPL uses ICMP. I am not sure 6LoWPAN header compression is of any relevance outside 802.15.4... whereas RPL sounded as if yes. I am not sure header compression in general is of any use anywhere beyond one hop. And of course I am not sure RPL subnet structure comprises more than one hop. At which point I am not sure why is this about IP at all. No IP addresses ('short' IP addresses), all within a single IP hop, no header alignment requirements - sounds as no IP at all. I guess I am completely lost. Alex > > Regards, Peter > > -----Ursprungligt meddelande----- Från: Joakim Eriksson > [mailto:joakime@sics.se] Skickat: den 15 december 2009 09:21 Till: > Kris Pister Kopia: Peter Siklosi; roll@ietf.org Ämne: Re: [Roll] > packet size issues > > The thing that can be made when data is aligned is mapping > (type-cast) the incoming data into structs without risking that the > struct is automatically "padded" for alignment. If we do not have > alignment in the packets this is impossible on processors above > 8-bits. > > > Best regards, -- Joakim Eriksson, SICS > > Kris Pister skrev: >> Joakim - can you say more about how important alignment is in >> simplifying implementations? In my experience, alignment or its >> absence doesn't have a big impact on code complexity. On the motes >> that I've used, in the 8 bit processors (e.g. AVR) memory access on >> byte boundaries is what you get. On 16 bit processors (e.g. >> MSP430), there's support for byte operations. On the 32 bit >> embedded processors (e.g. ARM7, Cortex-M3), there's a *lot* of >> support for byte and two-byte operations. >> >> Alex - it's worth thinking about your energy question. The cost of >> sending a byte over the radio is on the order of >> (20mW)*(8bits)/(250kbps) = 640 nJ The cost of a single processor >> cycle is on the order of (1mW/MHz)/(10^6 cycles/MHz) = 1nJ So from >> an energy perspective, we'd rather spend hundreds of cycles than >> send or receive a single byte. >> >> ksjp >> >> Joakim Eriksson wrote: >>> Hi Peter, >>> >>> I totally agree on the goal of minimizing packet sizes, but I >>> would like to keep alignment requirements since it simplifies >>> implementations. I also think (as you mention) that we need to >>> question the 16-bit sub-option length. Is it really needed? Both >>> IPv6 options and ICMPv6 option lenghts are encoded as 8-bit >>> values. Going down to 8-bits would also help the alignment of the >>> options. >>> >>> >>> Best Regards, -- Joakim Eriksson, SICS >>> >>> Peter Siklosi skrev: >>>> Hi all, >>>> >>>> >>>> >>>> If I understand correctly, RPL is designed to be usable with >>>> for instance 6LoWPAN on 802.15.4 with very limiting frame >>>> sizes. Even if 1280 byte IPv6 packets are of course supported >>>> using fragmentation, large packets should be avoided at all >>>> cost given the low bandwidth and low packet delivery success >>>> rate. >>>> >>>> >>>> >>>> Given this, I do not understand the alignment requirements >>>> specified in draft-ietf-roll-rpl-05 6.1.3.1.1.1 "Following the >>>> convention in IPv6, these options are aligned in a packet such >>>> that multi-octet values within the Option Data field of each >>>> option fall on natural boundaries". It seems that it would be >>>> more important to keep the messages short and avoid padding >>>> options. I am also curious on allocating 16 bits for a length >>>> field of a sub option. If sub option length exceeding 255 bytes >>>> (as could be specified by 8 bits) are needed, it seems that the >>>> routing messages are expected to get very large. >>>> >>>> >>>> >>>> Regards, Peter Siklosi >>>> >>>> >>>> >>>> >>>> ------------------------------------------------------------------------ >>>> >>>> >>>> _______________________________________________ Roll mailing >>>> list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll >>> _______________________________________________ Roll mailing 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 Dec 16 12:29:37 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 90BE93A6A5A for ; Wed, 16 Dec 2009 12:29:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.561 X-Spam-Level: X-Spam-Status: No, score=-0.561 tagged_above=-999 required=5 tests=[AWL=-0.912, BAYES_50=0.001, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1QQrzBV8Dg0W for ; Wed, 16 Dec 2009 12:29:36 -0800 (PST) Received: from smtp5-g21.free.fr (smtp5-g21.free.fr [212.27.42.5]) by core3.amsl.com (Postfix) with ESMTP id 5F2AD3A6918 for ; Wed, 16 Dec 2009 12:29:34 -0800 (PST) Received: from smtp5-g21.free.fr (localhost [127.0.0.1]) by smtp5-g21.free.fr (Postfix) with ESMTP id AF77AD4816C; Wed, 16 Dec 2009 21:29:16 +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 79C75D4805C; Wed, 16 Dec 2009 21:29:13 +0100 (CET) Message-ID: <4B294316.5030503@gmail.com> Date: Wed, 16 Dec 2009 21:29:10 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Kris Pister References: <4B1FDDC8.7030001@sics.se> <4B26DB78.4050602@eecs.berkeley.edu> In-Reply-To: <4B26DB78.4050602@eecs.berkeley.edu> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 091216-0, 16/12/2009), Outbound message X-Antivirus-Status: Clean Cc: roll@ietf.org, Peter Siklosi Subject: Re: [Roll] packet size issues X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 16 Dec 2009 20:29:37 -0000 Kris Pister a écrit : > Joakim - can you say more about how important alignment is in > simplifying implementations? In my experience, alignment or its > absence doesn't have a big impact on code complexity. On the motes > that I've used, in the 8 bit processors (e.g. AVR) memory access on > byte boundaries is what you get. On 16 bit processors (e.g. MSP430), > there's support for byte operations. On the 32 bit embedded > processors (e.g. ARM7, Cortex-M3), there's a *lot* of support for > byte and two-byte operations. > > Alex - it's worth thinking about your energy question. The cost of > sending a byte over the radio is on the order of > (20mW)*(8bits)/(250kbps) = 640 nJ The cost of a single processor > cycle is on the order of (1mW/MHz)/(10^6 cycles/MHz) = 1nJ So from an > energy perspective, we'd rather spend hundreds of cycles than send or > receive a single byte. Hmm... if so many cycles are available, at some extreme one could propose to encode the entire packet with BZIP2 and decode it upon reception. That would save lots of bandwidth space. What could prevent that from happening so? And yes, I agree the energy consumption perspective is worth contemplating, thanks for the figures showing more energy is spent on sending than on computing. Alex > > ksjp > > Joakim Eriksson wrote: >> Hi Peter, >> >> I totally agree on the goal of minimizing packet sizes, but I would >> like to keep alignment requirements since it simplifies >> implementations. I also think (as you mention) that we need to >> question the 16-bit sub-option length. Is it really needed? Both >> IPv6 options and ICMPv6 option lenghts are encoded as 8-bit values. >> Going down to 8-bits would also help the alignment of the options. >> >> >> Best Regards, -- Joakim Eriksson, SICS >> >> Peter Siklosi skrev: >>> Hi all, >>> >>> >>> >>> If I understand correctly, RPL is designed to be usable with for >>> instance 6LoWPAN on 802.15.4 with very limiting frame sizes. >>> Even if 1280 byte IPv6 packets are of course supported using >>> fragmentation, large packets should be avoided at all cost given >>> the low bandwidth and low packet delivery success rate. >>> >>> >>> >>> Given this, I do not understand the alignment requirements >>> specified in draft-ietf-roll-rpl-05 6.1.3.1.1.1 “Following the >>> convention in IPv6, these options are aligned in a packet such >>> that multi-octet values within the Option Data field of each >>> option fall on natural boundaries”. It seems that it would be >>> more important to keep the messages short and avoid padding >>> options. I am also curious on allocating 16 bits for a length >>> field of a sub option. If sub option length exceeding 255 bytes >>> (as could be specified by 8 bits) are needed, it seems that the >>> routing messages are expected to get very large. >>> >>> >>> >>> Regards, Peter Siklosi >>> >>> >>> >>> >>> ------------------------------------------------------------------------ >>> >>> >>> _______________________________________________ Roll mailing list >>> Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll >> >> _______________________________________________ Roll mailing 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 Peter.Siklosi@tritech.se Thu Dec 17 00:40:52 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E6B9D3A682B for ; Thu, 17 Dec 2009 00:40:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.688 X-Spam-Level: X-Spam-Status: No, score=-1.688 tagged_above=-999 required=5 tests=[AWL=-0.039, BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_31=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 Mw76j7-IxgKa for ; Thu, 17 Dec 2009 00:40:51 -0800 (PST) Received: from tritech.se (tritech.se [91.191.137.61]) by core3.amsl.com (Postfix) with ESMTP id 84FD23A6835 for ; Thu, 17 Dec 2009 00:40:51 -0800 (PST) Received: from srvsund01.tritech.se (srvsund01.tritech.se [10.75.60.4]) by tritech.se (8.14.3/8.14.3) with ESMTP id nBH8eY8W030436; Thu, 17 Dec 2009 09:40:35 +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: Thu, 17 Dec 2009 09:40:32 +0100 Message-ID: In-Reply-To: <4B294248.5090503@gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] packet size issues Thread-Index: Acp+jfsBBlNSrPtyRUqXIkQ1zeF8SwAZV2CQ References: <4B1FDDC8.7030001@sics.se> <4B26DB78.4050602@eecs.berkeley.edu> <4B2746DB.5040203@sics.se> <4B294248.5090503@gmail.com> From: "Peter Siklosi" To: "Alexandru Petrescu" X-CT-RefID: str=0001.0A3C0009.4B29EE7A.012B,ss=1,fgs=0 Cc: roll@ietf.org Subject: Re: [Roll] packet size issues X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 17 Dec 2009 08:40:53 -0000 > Which part of 6LoWPAN do you refer to to try very hard to reduce = packet size? > 6LoWPAN Header Compression draft-ietf-6lowpan-hc-06.txt? Yes. > I am not sure 6LoWPAN header compression is of any relevance outside=20 > 802.15.4... whereas RPL sounded as if yes. The total length of a frame is the sum of the parts of which it is = built. To get a short total length, all parts should be as short as = possible. 6LoWPAN takes care of the IP header and tries hard to make = that short. The reason to try hard to make it short is that a short = frame is important in an LLN. If this was not the case, there would be = no need for header compression at all, and IPv6 frames could travel = uncompressed. What I am saying is that a chain is no stronger than the weakest link, = if one part is compressed reasonably, while another part wastes bytes, = this results in an unnecessary long frame. That is all. > I am not sure header compression in general is of any use anywhere = beyond one hop. And of course I am not sure=20 > RPL subnet structure comprises more than one hop. I do not follow you. The whole point of RPL is to be able to route more = than one hop. If you only need only one hop, there is no need for RPL. Regards, Peter -----Ursprungligt meddelande----- Fr=E5n: Alexandru Petrescu [mailto:alexandru.petrescu@gmail.com]=20 Skickat: den 16 december 2009 21:26 Till: Peter Siklosi Kopia: Joakim Eriksson; Kris Pister; roll@ietf.org =C4mne: Re: [Roll] packet size issues Peter Siklosi a =E9crit : > In general, I think that you can store data in a struct in whatever > way you like and then have serialization and deserialization > functions taking care of reading the received byte sequence and > putting the right data into the struct and the other way around. > These routines can also take care of byte ordering and other issues. > Getting meshed LLN:s to work well can be a challenge in itself and > making sure to keep the packets short helps. The ability to take some > shortcuts in serialization/deserialization is a non-issue as far as I > see it. It does not make sense to have 6LoWPAN trying very hard to > reduce packet size and then waste it in RPL.. WEll... Which part of 6LoWPAN do you refer to to try very hard to reduce packet=20 size? 6LoWPAN Header Compression draft-ietf-6lowpan-hc-06.txt? Does that compress ICMP headers? I don't think 6LoWPAN HC understands=20 ICMP at all. RPL uses ICMP. I am not sure 6LoWPAN header compression is of any relevance outside=20 802.15.4... whereas RPL sounded as if yes. I am not sure header compression in general is of any use anywhere=20 beyond one hop. And of course I am not sure RPL subnet structure=20 comprises more than one hop. At which point I am not sure why is this=20 about IP at all. No IP addresses ('short' IP addresses), all within a=20 single IP hop, no header alignment requirements - sounds as no IP at = all. I guess I am completely lost. Alex >=20 > Regards, Peter >=20 > -----Ursprungligt meddelande----- Fr=E5n: Joakim Eriksson > [mailto:joakime@sics.se] Skickat: den 15 december 2009 09:21 Till: > Kris Pister Kopia: Peter Siklosi; roll@ietf.org =C4mne: Re: [Roll] > packet size issues >=20 > The thing that can be made when data is aligned is mapping=20 > (type-cast) the incoming data into structs without risking that the > struct is automatically "padded" for alignment. If we do not have > alignment in the packets this is impossible on processors above > 8-bits. >=20 >=20 > Best regards, -- Joakim Eriksson, SICS >=20 > Kris Pister skrev: >> Joakim - can you say more about how important alignment is in=20 >> simplifying implementations? In my experience, alignment or its >> absence doesn't have a big impact on code complexity. On the motes >> that I've used, in the 8 bit processors (e.g. AVR) memory access on >> byte boundaries is what you get. On 16 bit processors (e.g.=20 >> MSP430), there's support for byte operations. On the 32 bit >> embedded processors (e.g. ARM7, Cortex-M3), there's a *lot* of >> support for byte and two-byte operations. >>=20 >> Alex - it's worth thinking about your energy question. The cost of >> sending a byte over the radio is on the order of=20 >> (20mW)*(8bits)/(250kbps) =3D 640 nJ The cost of a single processor >> cycle is on the order of (1mW/MHz)/(10^6 cycles/MHz) =3D 1nJ So from >> an energy perspective, we'd rather spend hundreds of cycles than=20 >> send or receive a single byte. >>=20 >> ksjp >>=20 >> Joakim Eriksson wrote: >>> Hi Peter, >>>=20 >>> I totally agree on the goal of minimizing packet sizes, but I >>> would like to keep alignment requirements since it simplifies >>> implementations. I also think (as you mention) that we need to >>> question the 16-bit sub-option length. Is it really needed? Both >>> IPv6 options and ICMPv6 option lenghts are encoded as 8-bit >>> values. Going down to 8-bits would also help the alignment of the >>> options. >>>=20 >>>=20 >>> Best Regards, -- Joakim Eriksson, SICS >>>=20 >>> Peter Siklosi skrev: >>>> Hi all, >>>>=20 >>>>=20 >>>>=20 >>>> If I understand correctly, RPL is designed to be usable with >>>> for instance 6LoWPAN on 802.15.4 with very limiting frame >>>> sizes. Even if 1280 byte IPv6 packets are of course supported >>>> using fragmentation, large packets should be avoided at all >>>> cost given the low bandwidth and low packet delivery success >>>> rate. >>>>=20 >>>>=20 >>>>=20 >>>> Given this, I do not understand the alignment requirements >>>> specified in draft-ietf-roll-rpl-05 6.1.3.1.1.1 "Following the >>>> convention in IPv6, these options are aligned in a packet such >>>> that multi-octet values within the Option Data field of each >>>> option fall on natural boundaries". It seems that it would be >>>> more important to keep the messages short and avoid padding >>>> options. I am also curious on allocating 16 bits for a length >>>> field of a sub option. If sub option length exceeding 255 bytes >>>> (as could be specified by 8 bits) are needed, it seems that the >>>> routing messages are expected to get very large. >>>>=20 >>>>=20 >>>>=20 >>>> Regards, Peter Siklosi >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> = ------------------------------------------------------------------------ >>>>=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 > _______________________________________________ Roll mailing list=20 > Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll >=20 From alexandru.petrescu@gmail.com Thu Dec 17 05:13:52 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 69CE33A68D0 for ; Thu, 17 Dec 2009 05:13:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.965 X-Spam-Level: X-Spam-Status: No, score=-1.965 tagged_above=-999 required=5 tests=[AWL=-0.316, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_31=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 W9H-EEk7xV5C for ; Thu, 17 Dec 2009 05:13:51 -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 B99473A69DA for ; Thu, 17 Dec 2009 05:13:49 -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 nBHDDXPx013906 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 17 Dec 2009 14:13: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 nBHDDWjB029514; Thu, 17 Dec 2009 14:13:32 +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 nBHDDWKP026445; Thu, 17 Dec 2009 14:13:32 +0100 Message-ID: <4B2A2E7C.8070305@gmail.com> Date: Thu, 17 Dec 2009 14:13:32 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Peter Siklosi References: <4B1FDDC8.7030001@sics.se> <4B26DB78.4050602@eecs.berkeley.edu> <4B2746DB.5040203@sics.se> <4B294248.5090503@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] packet size issues X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 17 Dec 2009 13:13:52 -0000 Peter Siklosi a écrit : >> Which part of 6LoWPAN do you refer to to try very hard to reduce >> packet size? 6LoWPAN Header Compression >> draft-ietf-6lowpan-hc-06.txt? > > Yes. > >> I am not sure 6LoWPAN header compression is of any relevance >> outside 802.15.4... whereas RPL sounded as if yes. > > The total length of a frame is the sum of the parts of which it is > built. To get a short total length, all parts should be as short as > possible. 6LoWPAN takes care of the IP header and tries hard to make > that short. The reason to try hard to make it short is that a short > frame is important in an LLN. If this was not the case, there would > be no need for header compression at all, and IPv6 frames could > travel uncompressed. > > What I am saying is that a chain is no stronger than the weakest > link, if one part is compressed reasonably, while another part wastes > bytes, this results in an unnecessary long frame. That is all. In a sense yes, if every part of the chain is non-compressed (header compression not applied) then the overall message length is longer. But we couldn't request all protocols to shorten their payloads, could we. (ICMP is payload for IP, ICMP has its own payload, etc). >> I am not sure header compression in general is of any use anywhere >> beyond one hop. And of course I am not sure RPL subnet structure >> comprises more than one hop. > > I do not follow you. The whole point of RPL is to be able to route > more than one hop. If you only need only one hop, there is no need > for RPL. Hmm... but if RPL is about more than one hop, and header compression is usually happening over a single hop (ROHC), then I believe RPL and header compression are incompatible from the start. Alex > > > Regards, Peter > > -----Ursprungligt meddelande----- Från: Alexandru Petrescu > [mailto:alexandru.petrescu@gmail.com] Skickat: den 16 december 2009 > 21:26 Till: Peter Siklosi Kopia: Joakim Eriksson; Kris Pister; > roll@ietf.org Ämne: Re: [Roll] packet size issues > > Peter Siklosi a écrit : >> In general, I think that you can store data in a struct in whatever >> way you like and then have serialization and deserialization >> functions taking care of reading the received byte sequence and >> putting the right data into the struct and the other way around. >> These routines can also take care of byte ordering and other >> issues. Getting meshed LLN:s to work well can be a challenge in >> itself and making sure to keep the packets short helps. The ability >> to take some shortcuts in serialization/deserialization is a >> non-issue as far as I see it. It does not make sense to have >> 6LoWPAN trying very hard to reduce packet size and then waste it in >> RPL.. > > WEll... > > Which part of 6LoWPAN do you refer to to try very hard to reduce > packet size? > > 6LoWPAN Header Compression draft-ietf-6lowpan-hc-06.txt? > > Does that compress ICMP headers? I don't think 6LoWPAN HC > understands ICMP at all. RPL uses ICMP. > > I am not sure 6LoWPAN header compression is of any relevance outside > 802.15.4... whereas RPL sounded as if yes. > > I am not sure header compression in general is of any use anywhere > beyond one hop. And of course I am not sure RPL subnet structure > comprises more than one hop. At which point I am not sure why is > this about IP at all. No IP addresses ('short' IP addresses), all > within a single IP hop, no header alignment requirements - sounds as > no IP at all. > > I guess I am completely lost. > > Alex > >> Regards, Peter >> >> -----Ursprungligt meddelande----- Från: Joakim Eriksson >> [mailto:joakime@sics.se] Skickat: den 15 december 2009 09:21 Till: >> Kris Pister Kopia: Peter Siklosi; roll@ietf.org Ämne: Re: [Roll] >> packet size issues >> >> The thing that can be made when data is aligned is mapping >> (type-cast) the incoming data into structs without risking that the >> struct is automatically "padded" for alignment. If we do not have >> alignment in the packets this is impossible on processors above >> 8-bits. >> >> >> Best regards, -- Joakim Eriksson, SICS >> >> Kris Pister skrev: >>> Joakim - can you say more about how important alignment is in >>> simplifying implementations? In my experience, alignment or its >>> absence doesn't have a big impact on code complexity. On the >>> motes that I've used, in the 8 bit processors (e.g. AVR) memory >>> access on byte boundaries is what you get. On 16 bit processors >>> (e.g. MSP430), there's support for byte operations. On the 32 >>> bit embedded processors (e.g. ARM7, Cortex-M3), there's a *lot* >>> of support for byte and two-byte operations. >>> >>> Alex - it's worth thinking about your energy question. The cost >>> of sending a byte over the radio is on the order of >>> (20mW)*(8bits)/(250kbps) = 640 nJ The cost of a single processor >>> cycle is on the order of (1mW/MHz)/(10^6 cycles/MHz) = 1nJ So >>> from an energy perspective, we'd rather spend hundreds of cycles >>> than send or receive a single byte. >>> >>> ksjp >>> >>> Joakim Eriksson wrote: >>>> Hi Peter, >>>> >>>> I totally agree on the goal of minimizing packet sizes, but I >>>> would like to keep alignment requirements since it simplifies >>>> implementations. I also think (as you mention) that we need to >>>> question the 16-bit sub-option length. Is it really needed? >>>> Both IPv6 options and ICMPv6 option lenghts are encoded as >>>> 8-bit values. Going down to 8-bits would also help the >>>> alignment of the options. >>>> >>>> >>>> Best Regards, -- Joakim Eriksson, SICS >>>> >>>> Peter Siklosi skrev: >>>>> Hi all, >>>>> >>>>> >>>>> >>>>> If I understand correctly, RPL is designed to be usable with >>>>> for instance 6LoWPAN on 802.15.4 with very limiting frame >>>>> sizes. Even if 1280 byte IPv6 packets are of course supported >>>>> using fragmentation, large packets should be avoided at all >>>>> cost given the low bandwidth and low packet delivery success >>>>> rate. >>>>> >>>>> >>>>> >>>>> Given this, I do not understand the alignment requirements >>>>> specified in draft-ietf-roll-rpl-05 6.1.3.1.1.1 "Following >>>>> the convention in IPv6, these options are aligned in a packet >>>>> such that multi-octet values within the Option Data field of >>>>> each option fall on natural boundaries". It seems that it >>>>> would be more important to keep the messages short and avoid >>>>> padding options. I am also curious on allocating 16 bits for >>>>> a length field of a sub option. If sub option length >>>>> exceeding 255 bytes (as could be specified by 8 bits) are >>>>> needed, it seems that the routing messages are expected to >>>>> get very large. >>>>> >>>>> >>>>> >>>>> Regards, Peter Siklosi >>>>> >>>>> >>>>> >>>>> >>>>> ------------------------------------------------------------------------ >>>>> >>>>> >>>>> >>>>> _______________________________________________ Roll mailing >>>>> list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll >>>>> >>>> _______________________________________________ Roll mailing >>>> 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 nvt@sics.se Thu Dec 17 08:07:36 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 41B433A6962 for ; Thu, 17 Dec 2009 08:07:36 -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 o1MhezW9i4TJ for ; Thu, 17 Dec 2009 08:07:35 -0800 (PST) Received: from letter.sics.se (letter.sics.se [193.10.64.6]) by core3.amsl.com (Postfix) with ESMTP id 5220C3A68B4 for ; Thu, 17 Dec 2009 08:07:35 -0800 (PST) Received: from [193.10.67.9] (conjecture.sics.se [193.10.67.9]) by letter.sics.se (Postfix) with ESMTPS id 0A828400CB for ; Thu, 17 Dec 2009 17:07:19 +0100 (CET) Message-ID: <4B2A5737.6040400@sics.se> Date: Thu, 17 Dec 2009 17:07:19 +0100 From: Nicolas Tsiftes User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: roll@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [Roll] Concerns regarding the RPL terminology X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 17 Dec 2009 16:07:36 -0000 Hello, We are currently implementing RPL for the Contiki operating system, and have been reading the drafts thoroughly for this purpose. We would like to share some suggestions regarding the terminology used in RPL draft 05. 1. DAG Instance There is a mixture of terms that seem to refer to the same concept: "instances of RPL" (RPL instance) "DAG Instance" "DAG instance" "DODAG Instance" "topology instance" It's also difficult to understand how a DAG Instance really is an instance of a DAG, since DAGs are part of DAG Instances. Perhaps it would be clearer to call it "RPL instance." 2. DODAG "DODAG", "DAG", and "DA" seem to be used interchangeably in the draft. "DODAG root" - "DAG root" "DODAG Parent" - "DAG Parent" - "DA Parent" (?!) Suggestion: Replace "DODAG" and "DA" with "DAG". 3. Goal The addition of a "goal" in version 5 of the draft is confusing matters further. The "goal" and the "objective" of the objective functions seem to be different concepts, even though the words are listed as synonyms. From draft-ietf-roll-of0-00: "The Goal of the OF0 is to join a DODAG iteration that offers connectivity to a specific set of nodes or to a larger routing infrastructure. For the purpose of OF0, Grounded thus means that the root provides such connectivity." From draft-ietf-roll-rpl-05: "Goal: The Goal is a host or set of hosts that satisfy a particular application objective / OF. Whether or not a DODAG can provide connectivity to a goal is a property of the DODAG." "Grounded: A DAG is grounded when the root can reach the Goal of the objective function." Isn't the term "goal" superfluous when we have "objective function" and "grounded", where state of being "grounded" means connectivity to a network that is left to be determined by the network operator. We prefer the definition in draft-ietf-roll-rpl-04, which leaves the grounded state unspecified, instead of tying it to the objective function: "Grounded: A DAG is grounded if it contains a DAG root offering connectivity to an external routed infrastructure such as the public Internet or a private core (non-LLN) IP network." The state of being grounded appears to be unrelated to the metrics, constraints and objective function used to construct a DAG. Best regards, Nicolas Tsiftes & Joakim Eriksson, SICS From jvasseur@cisco.com Thu Dec 17 11:39:55 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DBD6428C150 for ; Thu, 17 Dec 2009 11:39:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.702 X-Spam-Level: X-Spam-Status: No, score=-6.702 tagged_above=-999 required=5 tests=[AWL=-0.105, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_HTML_MOSTLY=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 B8IUksf2+sEV for ; Thu, 17 Dec 2009 11:39:54 -0800 (PST) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id E398028C0F5 for ; Thu, 17 Dec 2009 11:39:54 -0800 (PST) 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: AswEADYXKkurRN+K/2dsb2JhbACCKL0Ply2ELQSBYw X-IronPort-AV: E=Sophos;i="4.47,414,1257120000"; d="scan'208,217";a="64322090" Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-4.cisco.com with ESMTP; 17 Dec 2009 19:39:38 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by sj-core-4.cisco.com (8.13.8/8.14.3) with ESMTP id nBHJdb1j019571 for ; Thu, 17 Dec 2009 19:39: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); Thu, 17 Dec 2009 20:39:36 +0100 Received: from ams-jvasseur-8712.cisco.com ([10.55.201.131]) by xfe-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 17 Dec 2009 20:39:36 +0100 Message-Id: <3D8F6921-724A-4EFA-A709-3F6BE1030477@cisco.com> From: JP Vasseur To: ROLL WG Content-Type: multipart/alternative; boundary=Apple-Mail-7--702111553 Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 17 Dec 2009 19:02:09 +0100 References: <20091216113001.E7C273A6970@core3.amsl.com> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 17 Dec 2009 19:39:36.0503 (UTC) FILETIME=[AA510C70:01CA7F50] Subject: [Roll] Fwd: I-D Action:draft-ietf-roll-of0-00.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Dec 2009 19:39:56 -0000 --Apple-Mail-7--702111553 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Note that this text used to be part of the RPL specification; as decided on the mailing the text related to OCP0 has been removed from the core spec and is now in this ID. Thanks. JP. Begin forwarded message: > From: Internet-Drafts@ietf.org > Date: December 16, 2009 12:30:01 PM CEST > To: i-d-announce@ietf.org > Cc: roll@ietf.org > Subject: [Roll] I-D Action:draft-ietf-roll-of0-00.txt > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Routing Over Low power and Lossy > networks Working Group of the IETF. > > > Title : RPL Objective Function 0 > Author(s) : P. Thubert > Filename : draft-ietf-roll-of0-00.txt > Pages : 8 > Date : 2009-12-16 > > The Routing Protocol for Low Power and Lossy Networks (RPL) defines a > generic Distance Vector protocol for Low Power and Lossy Networks > (LLNs). RPL is instantiated to honor a particular routing objective/ > constraint by the adding a specific Objective Function (OF) that is > designed to solve that problem. This specification defines a basic > OF, OF0, that uses only the abstract properties exposed in RPL > messages to maximize connectivity. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-roll-of0-00.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll --Apple-Mail-7--702111553 Content-Type: multipart/mixed; boundary=Apple-Mail-8--702111553 --Apple-Mail-8--702111553 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Note that this text used to be = part of the RPL specification; as decided on the mailing the text = related to OCP0 has been removed from the core spec and is now in this = ID.

Thanks.

JP.

Begin forwarded message:

Date: December 16, 2009 12:30:01 PM = CEST
To: i-d-announce@ietf.org
Subject: = [Roll] I-D = Action:draft-ietf-roll-of0-00.txt

A New = Internet-Draft is available from the on-line Internet-Drafts = directories.
This draft is a work item of the Routing Over Low power = and Lossy networks Working Group of the IETF.


Title =           : RPL = Objective Function 0
Author(s) =       : P. Thubert
Filename =        : = draft-ietf-roll-of0-00.txt
Pages =           : 8
Date =            : = 2009-12-16

The Routing Protocol for Low Power and Lossy Networks = (RPL) defines a
generic Distance Vector protocol for Low Power and = Lossy Networks
(LLNs).  RPL is instantiated to honor a = particular routing objective/
constraint by the adding a specific = Objective Function (OF) that is
designed to solve that problem. =  This specification defines a basic
OF, OF0, that uses only the = abstract properties exposed in RPL
messages to maximize = connectivity.

A URL for this Internet-Draft is:
ht= tp://www.ietf.org/internet-drafts/draft-ietf-roll-of0-00.txt

In= ternet-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-8--702111553 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<BR>Content-ID: &lt;2009-12-16032205.I-D@ietf.org&gt;<BR><BR> --Apple-Mail-8--702111553 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit
_______________________________________________
Roll mailing list
Roll@ietf.org
https://www.ietf.org/mailman/listinfo/roll

--Apple-Mail-8--702111553-- --Apple-Mail-7--702111553-- From robert.assimiti@nivis.com Thu Dec 17 12:34:35 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DD1A03A68E1 for ; Thu, 17 Dec 2009 12:34:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.002 X-Spam-Level: X-Spam-Status: No, score=0.002 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LfqByCS+6cv3 for ; Thu, 17 Dec 2009 12:34:31 -0800 (PST) Received: from smtp.nivis.com (smtp.nivis.com [65.205.163.2]) by core3.amsl.com (Postfix) with ESMTP id 17C4C3A62C1 for ; Thu, 17 Dec 2009 12:34:30 -0800 (PST) Received: from ATLEXCH02.nivis.com ([10.0.0.18]) by ATLEXCH02.nivis.com ([10.0.0.18]) with mapi; Thu, 17 Dec 2009 15:34:14 -0500 From: Robert Assimiti To: "roll@ietf.org" Date: Thu, 17 Dec 2009 15:34:13 -0500 Thread-Topic: Routing/metrics draft 04 - conflicting assignment of highest LQL (editorial) Thread-Index: Acp/WEtVnLpHJAW6S527BUYgRJ623Q== Message-ID: <67442429D9C35E4C975B89BE73BD33D0159DEBA49F@ATLEXCH02.nivis.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_67442429D9C35E4C975B89BE73BD33D0159DEBA49FATLEXCH02nivi_" MIME-Version: 1.0 Subject: [Roll] Routing/metrics draft 04 - conflicting assignment of highest LQL (editorial) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 17 Dec 2009 20:34:36 -0000 --_000_67442429D9C35E4C975B89BE73BD33D0159DEBA49FATLEXCH02nivi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, Going through draft-iett-roll-routing metrics-04, I discovered an editorial= inconsistency in terms of assignment of the highest LQL level. On page 17, the highest LQL is defined as 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." On page 18, the lowest LQL is defined as 1 "Val: LQL value from 0 to 3 where 0 means undetermined and 1 indicates the lowest link quality. Please note and rectify in the next revision. Robert Assimiti Executive Staff Engineer 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_67442429D9C35E4C975B89BE73BD33D0159DEBA49FATLEXCH02nivi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello,=

&= nbsp;

Going = through draft-iett-roll-routing metrics-04, I discovered an editorial incon= sistency in terms of assignment of the highest LQL level.=

&= nbsp;

On pag= e 17, the highest LQL is defined as 1

“= The Link Quality Level (LQL) object is used to quantify the link=

reliability using a discrete valu= e, from 0 to 3 where 0 indicates

that the link quality level i= s unknown and 1 reports the highest link

quality level.”

On pag= e 18, the lowest LQL is defined as 1

“Val: LQL value from 0 to 3 where 0 means und= etermined and 1 indicates

the lowest link quality.

Please= note and rectify in the next revision.

 

Robert Assimiti=

Executive Staff E= ngineer

Office: [678]-202-6859=

Mobile: [404]-578-0205=

robert.assimiti@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_67442429D9C35E4C975B89BE73BD33D0159DEBA49FATLEXCH02nivi_-- From pal@cs.stanford.edu Fri Dec 18 12:58:05 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C94983A67A1 for ; Fri, 18 Dec 2009 12:58:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.825 X-Spam-Level: X-Spam-Status: No, score=-5.825 tagged_above=-999 required=5 tests=[AWL=-0.714, 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 KndBlyCPJ1TI for ; Fri, 18 Dec 2009 12:58:05 -0800 (PST) Received: from cs-smtp-1.Stanford.EDU (cs-smtp-1.Stanford.EDU [171.64.64.25]) by core3.amsl.com (Postfix) with ESMTP id 29CEE3A68F1 for ; Fri, 18 Dec 2009 12:58:05 -0800 (PST) Received: from [76.14.71.8] (helo=[192.168.1.105]) by cs-smtp-1.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1NLjtW-0003SB-Dw for roll@ietf.org; Fri, 18 Dec 2009 12:57:50 -0800 From: Philip Levis Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Date: Fri, 18 Dec 2009 12:57:49 -0800 Message-Id: To: roll@ietf.org Mime-Version: 1.0 (Apple Message framework v1075.2) X-Mailer: Apple Mail (2.1075.2) X-Scan-Signature: 9c8d7c79e82d9ccd3af9a51b4d3246f3 Subject: [Roll] DIO DAGRank field X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 18 Dec 2009 20:58:05 -0000 Currently, the DIO DAGRank field is 8 bits. Is this sufficient? I am concerned with the compression of metrics to Rank. Some metrics one can expect to have a reasonably small range (ETX/ETT). Others, such as latency, can have a very large range (latency). I am a bit worried whether an 8-bit Rank will be sufficient for these kinds of metrics. Looking at OF0, for example, a given link can lead to a Rank increase of up to 16: an 8-bit value means that there can be a 16-hop limit. Since OF0 does not define how a link cost of 16 is determined, it could be that an implementation leans towards high values and so the network cannot scale out. It seems to me that a 16-bit value would be much safer. We don't want to end up painting ourselves into the same corner that RIP did. Thoughts? Phil From jvasseur@cisco.com Sat Dec 19 01:13:49 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 041323A6A45 for ; Sat, 19 Dec 2009 01:13:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.637 X-Spam-Level: X-Spam-Status: No, score=-4.637 tagged_above=-999 required=5 tests=[AWL=-2.038, 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 EVhCOV5USdDh for ; Sat, 19 Dec 2009 01:13:48 -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 B78933A6855 for ; Sat, 19 Dec 2009 01:13:47 -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: AmAAAJ4oLEuQ/uCWiWdsb2JhbACbWAEBCgsREwageJZphC4EjTM X-IronPort-AV: E=Sophos;i="4.47,423,1257120000"; d="scan'208";a="1532111" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-2.cisco.com with ESMTP; 19 Dec 2009 08:46:25 +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 nBJ9DR38012408; Sat, 19 Dec 2009 09:13:27 GMT Received: from xfe-ams-101.cisco.com ([144.254.231.93]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Sat, 19 Dec 2009 10:13:27 +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); Sat, 19 Dec 2009 10:13:26 +0100 Message-Id: <7FA5EF01-E149-4D8C-91F1-A16898FC0D54@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: Sat, 19 Dec 2009 10:13:25 +0100 References: X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 19 Dec 2009 09:13:26.0517 (UTC) FILETIME=[85AFA250:01CA808B] Cc: roll@ietf.org Subject: Re: [Roll] DIO DAGRank field X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Dec 2009 09:13:49 -0000 On Dec 18, 2009, at 9:57 PM, Philip Levis wrote: > Currently, the DIO DAGRank field is 8 bits. Is this sufficient? > > I am concerned with the compression of metrics to Rank. Some metrics > one can expect to have a reasonably small range (ETX/ETT). Others, > such as latency, can have a very large range (latency). I am a bit > worried whether an 8-bit Rank will be sufficient for these kinds of > metrics. Looking at OF0, for example, a given link can lead to a > Rank increase of up to 16: an 8-bit value means that there can be a > 16-hop limit. Since OF0 does not define how a link cost of 16 is > determined, it could be that an implementation leans towards high > values and so the network cannot scale out. > > It seems to me that a 16-bit value would be much safer. We don't > want to end up painting ourselves into the same corner that RIP did. > > Thoughts? Right, on the other hand if there is a need for a more sophisticated metric, we use the metrics defined in the metric-ID. I have the feeling that OF0 is to be used in fairly simple network where the metric and the rank are tightly coupled but in other networks other metrics will be used. Since you refer to latency there is a latency metric that has been defined. Let's see what others think. > > Phil > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From richard.kelsey@ember.com Mon Dec 21 05:35:34 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 763143A69A3 for ; Mon, 21 Dec 2009 05:35:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.317 X-Spam-Level: X-Spam-Status: No, score=-1.317 tagged_above=-999 required=5 tests=[AWL=-1.132, BAYES_40=-0.185] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j49JYjJbB8s7 for ; Mon, 21 Dec 2009 05:35:33 -0800 (PST) Received: from EMPIRE.hq.ember.com (mail.ember.com [74.10.175.227]) by core3.amsl.com (Postfix) with ESMTP id 904443A689A for ; Mon, 21 Dec 2009 05:35:33 -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); Mon, 21 Dec 2009 08:37:11 -0500 Date: Mon, 21 Dec 2009 08:34:31 -0500 Message-Id: <87k4wgsb6g.fsf@kelsey-ws.hq.ember.com> To: JP Vasseur In-reply-to: <7FA5EF01-E149-4D8C-91F1-A16898FC0D54@cisco.com> (message from JP Vasseur on Sat, 19 Dec 2009 10:13:25 +0100) From: Richard Kelsey References: <7FA5EF01-E149-4D8C-91F1-A16898FC0D54@cisco.com> X-OriginalArrivalTime: 21 Dec 2009 13:37:11.0065 (UTC) FILETIME=[B2AD8890:01CA8242] Cc: roll@ietf.org Subject: Re: [Roll] DIO DAGRank field X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 21 Dec 2009 13:35:34 -0000 > From: JP Vasseur > Date: Sat, 19 Dec 2009 10:13:25 +0100 >> > On Dec 18, 2009, at 9:57 PM, Philip Levis wrote: > > > I am concerned with the compression of metrics to Rank. Some metrics > > one can expect to have a reasonably small range (ETX/ETT). Others, > > such as latency, can have a very large range (latency). I am a bit > > worried whether an 8-bit Rank will be sufficient for these kinds of > > metrics. [...] > > > > It seems to me that a 16-bit value would be much safer. We don't > > want to end up painting ourselves into the same corner that RIP did. > > Right, on the other hand if there is a need for a more sophisticated > metric, we use the metrics defined in the metric-ID. I have the > feeling that OF0 is to be used in fairly simple network where the > metric and the rank are tightly coupled but in other networks other > metrics will be used. Since you refer to latency there is a latency > metric that has been defined. Let's see what others think. Yes, there is a latency metric with a 32-bit floating point latency in milliseconds. It seems silly to have that much precision and range in the metric and then use an 8-bit rank. For a DAG based on latency you need to pick the latency that corresponds to a rank increase of one. Here are some possibilities: latency per rank increment 10ms 30ms 100ms maximum path latency 2.5 sec 7.5 sec 25 sec For a very low power 802.15.4 network, a maximum path latency of 25 seconds seems none too high. At the same time, a pair of line-powered 802.15.4 neighbors should have a latency of 30ms or less. All that range in the metric doesn't help because it gets lost in the translation to the rank. -Richard Kelsey From jvasseur@cisco.com Mon Dec 21 05:41:29 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D10A63A6817 for ; Mon, 21 Dec 2009 05:41:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.533 X-Spam-Level: X-Spam-Status: No, score=-4.533 tagged_above=-999 required=5 tests=[AWL=-1.934, 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 wmNto7VwvRCr for ; Mon, 21 Dec 2009 05:41:29 -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 6D73628C0D0 for ; Mon, 21 Dec 2009 05:41:28 -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: AnkAALoJL0uQ/uCWiWdsb2JhbACbUgEBAQoLERMGoyuVH4QuBA X-IronPort-AV: E=Sophos;i="4.47,431,1257120000"; d="scan'208";a="1651966" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-2.cisco.com with ESMTP; 21 Dec 2009 13:13:59 +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 nBLDfBNK025508; Mon, 21 Dec 2009 13:41:11 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, 21 Dec 2009 14:41:11 +0100 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, 21 Dec 2009 14:41:10 +0100 Message-Id: From: JP Vasseur To: Richard Kelsey In-Reply-To: <87k4wgsb6g.fsf@kelsey-ws.hq.ember.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 21 Dec 2009 14:41:10 +0100 References: <7FA5EF01-E149-4D8C-91F1-A16898FC0D54@cisco.com> <87k4wgsb6g.fsf@kelsey-ws.hq.ember.com> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 21 Dec 2009 13:41:10.0774 (UTC) FILETIME=[418E3960:01CA8243] Cc: roll@ietf.org Subject: Re: [Roll] DIO DAGRank field X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 21 Dec 2009 13:41:30 -0000 On Dec 21, 2009, at 2:34 PM, Richard Kelsey wrote: >> From: JP Vasseur >> Date: Sat, 19 Dec 2009 10:13:25 +0100 >>> >> On Dec 18, 2009, at 9:57 PM, Philip Levis wrote: >> >>> I am concerned with the compression of metrics to Rank. Some metrics >>> one can expect to have a reasonably small range (ETX/ETT). Others, >>> such as latency, can have a very large range (latency). I am a bit >>> worried whether an 8-bit Rank will be sufficient for these kinds of >>> metrics. [...] >>> >>> It seems to me that a 16-bit value would be much safer. We don't >>> want to end up painting ourselves into the same corner that RIP did. >> >> Right, on the other hand if there is a need for a more sophisticated >> metric, we use the metrics defined in the metric-ID. I have the >> feeling that OF0 is to be used in fairly simple network where the >> metric and the rank are tightly coupled but in other networks other >> metrics will be used. Since you refer to latency there is a latency >> metric that has been defined. Let's see what others think. > > Yes, there is a latency metric with a 32-bit floating point > latency in milliseconds. We can certainly change the way we encode this metric and others. > It seems silly to have that much > precision and range in the metric and then use an 8-bit > rank. They may not be correlated at all, the rank only being used for "loop management" and the latency for path computation. > For a DAG based on latency you need to pick the > latency that corresponds to a rank increase of one. Why ? > Here > are some possibilities: > > latency per rank increment 10ms 30ms 100ms > maximum path latency 2.5 sec 7.5 sec 25 sec > > For a very low power 802.15.4 network, a maximum path > latency of 25 seconds seems none too high. At the same > time, a pair of line-powered 802.15.4 neighbors should have > a latency of 30ms or less. All that range in the metric > doesn't help because it gets lost in the translation to > the rank. But it does not have to be translated to the rank at all ? Cheers. JP. > -Richard Kelsey > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From pal@cs.stanford.edu Mon Dec 21 09:02:15 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4A20C3A6A46 for ; Mon, 21 Dec 2009 09:02:15 -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 SARsUz0q-5IN for ; Mon, 21 Dec 2009 09:02:14 -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 0EB693A6A0B for ; Mon, 21 Dec 2009 09:02:14 -0800 (PST) Received: from dnab40462b.stanford.edu ([171.64.70.43]) by cs-smtp-2.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1NMldt-0007g9-Jc; Mon, 21 Dec 2009 09:01:58 -0800 Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Philip Levis In-Reply-To: Date: Mon, 21 Dec 2009 08:46:02 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <7FA5EF01-E149-4D8C-91F1-A16898FC0D54@cisco.com> <87k4wgsb6g.fsf@kelsey-ws.hq.ember.com> To: JP Vasseur X-Mailer: Apple Mail (2.1077) X-Scan-Signature: fb418a055a615a79fddacbea7bf2a8e8 Cc: roll@ietf.org Subject: Re: [Roll] DIO DAGRank field X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 21 Dec 2009 17:02:15 -0000 On Dec 21, 2009, at 5:41 AM, JP Vasseur wrote: >=20 > On Dec 21, 2009, at 2:34 PM, Richard Kelsey wrote: >=20 >>> From: JP Vasseur >>> Date: Sat, 19 Dec 2009 10:13:25 +0100 >>>>=20 >>> On Dec 18, 2009, at 9:57 PM, Philip Levis wrote: >>>=20 >>>> I am concerned with the compression of metrics to Rank. Some = metrics >>>> one can expect to have a reasonably small range (ETX/ETT). Others, >>>> such as latency, can have a very large range (latency). I am a bit >>>> worried whether an 8-bit Rank will be sufficient for these kinds of >>>> metrics. [...] >>>>=20 >>>> It seems to me that a 16-bit value would be much safer. We don't >>>> want to end up painting ourselves into the same corner that RIP = did. >>>=20 >>> Right, on the other hand if there is a need for a more sophisticated >>> metric, we use the metrics defined in the metric-ID. I have the >>> feeling that OF0 is to be used in fairly simple network where the >>> metric and the rank are tightly coupled but in other networks other >>> metrics will be used. Since you refer to latency there is a latency >>> metric that has been defined. Let's see what others think. >>=20 >> Yes, there is a latency metric with a 32-bit floating point >> latency in milliseconds. >=20 > We can certainly change the way we encode this metric and others. >=20 >> It seems silly to have that much >> precision and range in the metric and then use an 8-bit >> rank. >=20 > They may not be correlated at all, the rank only being used for "loop = management" > and the latency for path computation. >=20 >> For a DAG based on latency you need to pick the >> latency that corresponds to a rank increase of one. >=20 > Why ? >=20 >> Here >> are some possibilities: >>=20 >> latency per rank increment 10ms 30ms 100ms >> maximum path latency 2.5 sec 7.5 sec 25 sec >>=20 >> For a very low power 802.15.4 network, a maximum path >> latency of 25 seconds seems none too high. At the same >> time, a pair of line-powered 802.15.4 neighbors should have >> a latency of 30ms or less. All that range in the metric >> doesn't help because it gets lost in the translation to >> the rank. >=20 > But it does not have to be translated to the rank at all ? JP, I don't think we can have it both ways. Rank should either be a = topological property or a metric property. That is, I think it's = problematic to overload Rank so that it could either be a coarse = distillation of a route metric *or* a hopcount. If it's the former, it = needs 16 bits; if it's the latter, 8 is fine. But to keep it at 8 and = say that it could be either means that metrics with large ranges must = use it as a hopcount. This seems like an arbitrary decision. For example, OF0 equates Rank with link (and route) quality, such that = nodes choose the best route by choosing the lowest Rank next hop. This = kind of conflation is at the core of the problem, I think. Shouldn't = this be a metric container decision? Phil= From jvasseur@cisco.com Mon Dec 21 14:21:15 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 094B628C15C for ; Mon, 21 Dec 2009 14:21:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.488 X-Spam-Level: X-Spam-Status: No, score=-6.488 tagged_above=-999 required=5 tests=[AWL=0.111, 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 mdNw89F2lpTD for ; Mon, 21 Dec 2009 14:21:14 -0800 (PST) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id 39A5C28C14A for ; Mon, 21 Dec 2009 14:21:14 -0800 (PST) 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: ApoEABOEL0urRN+J/2dsb2JhbADAdpVrhC4E X-IronPort-AV: E=Sophos;i="4.47,433,1257120000"; d="scan'208";a="65973721" Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-4.cisco.com with ESMTP; 21 Dec 2009 22:20:56 +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 nBLMKsc0010365; Mon, 21 Dec 2009 22:20:55 GMT Received: from xfe-ams-102.cisco.com ([144.254.231.94]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 21 Dec 2009 23:20:54 +0100 Received: from ams-emgil-8719.cisco.com ([10.55.88.37]) by xfe-ams-102.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 21 Dec 2009 23:20:53 +0100 Message-Id: <03BD6676-6DFD-4D91-8AE2-8B670D111136@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: Mon, 21 Dec 2009 23:20:53 +0100 X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 21 Dec 2009 22:20:53.0635 (UTC) FILETIME=[DBFD3530:01CA828B] X-TM-AS-Product-Ver: SMEX-8.0.0.1181-6.000.1038-17084.002 X-TM-AS-Result: No--7.813600-8.000000-31 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No Subject: [Roll] Heads-up on RPL Security X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 21 Dec 2009 22:21:15 -0000 Dear WG, Just to provide you a quick heads-up ... The aim of the next revision will be to continue to improve the text, work on the DAO item, potentially DAO packing, .. Then we will move to Security for revision 07, with the objective to have the security piece fleshed out by end of January. Stay tuned, the next revision of the individual security framework document should be out soon, for which we will ask you whether you support its adoption as a WG document, before starting RPL security, our next major item. Merry Christmas. Thanks. JP. From richard.kelsey@ember.com Mon Dec 21 20:01:45 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C8B6C3A6AD4 for ; Mon, 21 Dec 2009 20:01:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.437 X-Spam-Level: X-Spam-Status: No, score=-2.437 tagged_above=-999 required=5 tests=[AWL=0.162, 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 rXv-gDEpUUlU for ; Mon, 21 Dec 2009 20:01:45 -0800 (PST) Received: from EMPIRE.hq.ember.com (mail.ember.com [74.10.175.227]) by core3.amsl.com (Postfix) with ESMTP id DDBCC3A697A for ; Mon, 21 Dec 2009 20:01:44 -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); Mon, 21 Dec 2009 23:03:22 -0500 Date: Mon, 21 Dec 2009 23:00:34 -0500 Message-Id: <87hbrju07x.fsf@kelsey-ws.hq.ember.com> To: JP Vasseur In-reply-to: (message from JP Vasseur on Mon, 21 Dec 2009 14:41:10 +0100) From: Richard Kelsey References: <7FA5EF01-E149-4D8C-91F1-A16898FC0D54@cisco.com> <87k4wgsb6g.fsf@kelsey-ws.hq.ember.com> X-OriginalArrivalTime: 22 Dec 2009 04:03:22.0439 (UTC) FILETIME=[B407DD70:01CA82BB] Cc: roll@ietf.org Subject: Re: [Roll] DIO DAGRank field X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 22 Dec 2009 04:01:45 -0000 > From: JP Vasseur > Date: Mon, 21 Dec 2009 14:41:10 +0100 > > On Dec 21, 2009, at 2:34 PM, Richard Kelsey wrote: > > > Yes, there is a latency metric with a 32-bit floating point > > latency in milliseconds. > > We can certainly change the way we encode this metric and others. > > > It seems silly to have that much > > precision and range in the metric and then use an 8-bit > > rank. > > They may not be correlated at all, the rank only being > used for "loop management" and the latency for path > computation. This has been gone over in detail before on this list. The rank trumps the metric. It may only be for "loop management", but if the rank makes a neighbor ineligble as a parent, it doesn't matter what the neighbor's metric is, the neighbor cannot be a parent. > > For a DAG based on latency you need to pick the > > latency that corresponds to a rank increase of one. > > Why ? To minimize the discrepancy between the metric and the rank. The set of possible parents is based on rank, not metric. If the metric and rank are not in sync, then the best parents according to the metric may easily not be in the set of possible parents allowed by the rank. > > Here > > are some possibilities: > > > > latency per rank increment 10ms 30ms 100ms > > maximum path latency 2.5 sec 7.5 sec 25 sec > > > > For a very low power 802.15.4 network, a maximum path > > latency of 25 seconds seems none too high. At the same > > time, a pair of line-powered 802.15.4 neighbors should have > > a latency of 30ms or less. All that range in the metric > > doesn't help because it gets lost in the translation to > > the rank. > > But it does not have to be translated to the rank at all ? If the latency is not translated into the rank then the DAG will not optimize latency. RPL optimizes rank first and metric second. -Richard Kelsey From jau@ece.drexel.edu Mon Dec 21 20:12:24 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1CD1B3A69A0 for ; Mon, 21 Dec 2009 20:12:24 -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 8uwYliJud3Vb for ; Mon, 21 Dec 2009 20:12:22 -0800 (PST) Received: from mail.ece.drexel.edu (mail.ece.drexel.edu [129.25.60.32]) by core3.amsl.com (Postfix) with ESMTP id 7AE843A6977 for ; Mon, 21 Dec 2009 20:12:22 -0800 (PST) Received: from [192.168.0.104] (c-68-81-121-20.hsd1.nj.comcast.net [68.81.121.20]) by mail.ece.drexel.edu (Postfix) with ESMTP id CFF1733A9F; Mon, 21 Dec 2009 23:12:05 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v753.1) References: <20091222035821.C522A3A6966@core3.amsl.com> Content-Type: multipart/alternative; boundary=Apple-Mail-23--319917027 Message-Id: From: Jaudelice de Oliveira Date: Mon, 21 Dec 2009 23:12:04 -0500 To: ROLL WG X-Mailer: Apple Mail (2.753.1) Cc: Joydeep Tripathi Subject: [Roll] Fwd: New Version Notification for draft-tripathi-roll-rpl-simulation-01 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Dec 2009 04:12:24 -0000 --Apple-Mail-23--319917027 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Dear WG, We have just posted draft-tripathi-roll-rpl-simulation-01with a detailed performance evaluation of RPL for several metrics of interest (please see PDF file with plots). We are currently working on results with local repair and shall post them shortly. We would love feedback/suggestions from the WG. Are there other metrics you would like to see? Cheers, Jau. Jaudelice C. de Oliveira Associate Professor ECE Dept., Drexel University http://www.ece.drexel.edu/faculty/deoliveira/ Begin forwarded message: > From: IETF I-D Submission Tool > Date: December 21, 2009 10:58:21 PM EST > To: jau@ece.drexel.edu > Cc: jt369@drexel.edu,jpv@cisco.com > Subject: New Version Notification for draft-tripathi-roll-rpl- > simulation-01 > > > A new version of I-D, draft-tripathi-roll-rpl-simulation-01.txt has > been successfuly submitted by Jaudelice Oliveira and posted to the > IETF repository. > > Filename: draft-tripathi-roll-rpl-simulation > Revision: 01 > Title: Performance Evaluation of Routing Protocol for Low Power > and Lossy Networks (RPL) > Creation_date: 2009-12-21 > WG ID: Independent Submission > Number_of_pages: 12 > > Abstract: > This document presents a performance evaluation of the Routing > Protocol for Low power and Lossy Networks (RPL). Detailed > simulations are carried out to produce several routing performance > metrics using a set of real-life scenarios. > > Status of this Memo > > This Internet-Draft is submitted to IETF in full conformance with the > provisions of BCP 78 and BCP 79. > > Internet-Drafts are working documents of the Internet Engineering > Task Force (IETF), its areas, and its working groups. Note that > other groups may also distribute working documents as Internet- > Drafts. > > Internet-Drafts are draft documents valid for a maximum of six months > and may be updated, replaced, or obsoleted by other documents at any > time. It is inappropriate to use Internet-Drafts as reference > material or to cite them other than as "work in progress." > > The list of current Internet-Drafts can be accessed at > http://www.ietf.org/ietf/1id-abstracts.txt. > > The list of Internet-Draft Shadow Directories can be accessed at > http://www.ietf.org/shadow.html. > > This Internet-Draft will expire on June 24, 2010. > > Copyright Notice > > Copyright (c) 2009 IETF Trust and the persons identified as the > document authors. All rights reserved. > > This document is subject to BCP 78 and the IETF Trust's Legal > Provisions Relating to IETF Documents > (http://trustee.ietf.org/license-info) in effect on the date of > publication of this document. Please review these documents > carefully, as they describe your rights and restrictions with respect > to this document. Code Components extracted from this document must > include Simplified BSD License text as described in Section 4.e of > the Trust Legal Provisions and are provided without warranty as > described in the BSD License. > > > > The IETF Secretariat. > > --Apple-Mail-23--319917027 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=US-ASCII Dear WG,

We have just posted = draft-tripathi-roll-rpl-simulation-01with a detailed performance = evaluation of RPL for several metrics of interest (please see PDF file = with plots). We are currently working on results with local repair and = shall post them shortly. We would love feedback/suggestions from the WG. = Are there other metrics you would like to = see?

Cheers,

Jau.
<= div>




=
http://www.ece.drex= el.edu/faculty/deoliveira/






Begin forwarded = message:

From: IETF I-D Submission Tool <idsubmission@ietf.org>=
Date: December 21, 2009 10:58:21 PM = EST
Cc: jt369@drexel.edu,jpv@cisco.com
Subject: = New Version Notification for  = draft-tripathi-roll-rpl-simulation-01 


A new version = of I-D, draft-tripathi-roll-rpl-simulation-01.txt has been successfuly = submitted by Jaudelice Oliveira and posted to the IETF = repository.

Filename: = draft-tripathi-roll-rpl-simulation
= 01
Title: = Performance Evaluation of Routing Protocol for Low Power and Lossy = Networks (RPL)
Creation_date: = 2009-12-21
WG ID: = Independent Submission
Number_of_pages: = 12

Abstract:
This document = presents a performance evaluation of the Routing
Protocol for Low power and Lossy Networks = (RPL).  = Detailed
simulations are carried out to = produce several routing performance
metrics using = a set of real-life scenarios.

Status of this Memo

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

Internet-Drafts are working documents of the = Internet Engineering
Task Force (IETF), its = areas, and its working groups. = Note that
other groups may also distribute = working documents as Internet-

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

The list of current Internet-Drafts can be accessed = at

The list of Internet-Draft = Shadow Directories can be accessed at




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



The IETF = Secretariat.


=
= --Apple-Mail-23--319917027-- From gnawali@cs.stanford.edu Tue Dec 22 23:10:21 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1A1093A695C for ; Tue, 22 Dec 2009 23:10:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.677 X-Spam-Level: X-Spam-Status: No, score=-5.677 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CHnrtCC6paOa for ; Tue, 22 Dec 2009 23:10:19 -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 EC23A3A67D8 for ; Tue, 22 Dec 2009 23:10:19 -0800 (PST) Received: from qw-out-2122.google.com ([74.125.92.25]) by cs-smtp-2.Stanford.EDU with esmtpsa (TLSv1:RC4-MD5:128) (Exim 4.60) (envelope-from ) id 1NNLMA-0007EE-Jo for roll@ietf.org; Tue, 22 Dec 2009 23:10:03 -0800 Received: by qw-out-2122.google.com with SMTP id 9so1513657qwb.31 for ; Tue, 22 Dec 2009 23:10:01 -0800 (PST) MIME-Version: 1.0 Received: by 10.224.51.222 with SMTP id e30mr5096325qag.82.1261552199989; Tue, 22 Dec 2009 23:09:59 -0800 (PST) In-Reply-To: References: <20091222035821.C522A3A6966@core3.amsl.com> Date: Tue, 22 Dec 2009 23:09:59 -0800 Message-ID: From: Omprakash Gnawali To: Jaudelice de Oliveira Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Scan-Signature: a2fe995cb7ed4309b2d212c2bd713a7d Cc: Joydeep Tripathi , ROLL WG Subject: Re: [Roll] Fwd: New Version Notification for draft-tripathi-roll-rpl-simulation-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, 23 Dec 2009 07:10:21 -0000 It is great to start understanding how RPL would work. On this file: http://tools.ietf.org/html/draft-tripathi-roll-rpl-simulation-00 I don't see the figures... - om_p On Mon, Dec 21, 2009 at 8:12 PM, Jaudelice de Oliveira wrote: > Dear WG, > We have just posted draft-tripathi-roll-rpl-simulation-01with a detailed > performance evaluation of RPL for several metrics of interest (please see > PDF file with plots). We are currently working on results with local repa= ir > and shall post them shortly. We would love feedback/suggestions from the = WG. > Are there other metrics you would like to see? > Cheers, > Jau. > > > > > Jaudelice C. de Oliveira > Associate Professor > ECE Dept.,=A0Drexel University > http://www.ece.drexel.edu/faculty/deoliveira/ > > > > > > Begin forwarded message: > > From: IETF I-D Submission Tool > Date: December 21, 2009 10:58:21 PM EST > To: jau@ece.drexel.edu > Cc: jt369@drexel.edu,jpv@cisco.com > Subject: New Version Notification for > draft-tripathi-roll-rpl-simulation-01 > > A new version of I-D, draft-tripathi-roll-rpl-simulation-01.txt has been > successfuly submitted by Jaudelice Oliveira and posted to the IETF > repository. > Filename: draft-tripathi-roll-rpl-simulation > Revision: 01 > Title: Performance Evaluation of Routing Protocol for Low Power and Lossy > Networks (RPL) > Creation_date: 2009-12-21 > WG ID: Independent Submission > Number_of_pages: 12 > Abstract: > This document presents a performance evaluation of the Routing > Protocol for Low power and Lossy Networks (RPL).=A0 Detailed > simulations are carried out to produce several routing performance > metrics using a set of real-life scenarios. > Status of this Memo > This Internet-Draft is submitted to IETF in full conformance with the > provisions of BCP 78 and BCP 79. > Internet-Drafts are working documents of the Internet Engineering > Task Force (IETF), its areas, and its working groups.=A0 Note that > other groups may also distribute working documents as Internet- > Drafts. > Internet-Drafts are draft documents valid for a maximum of six months > and may be updated, replaced, or obsoleted by other documents at any > time.=A0 It is inappropriate to use Internet-Drafts as reference > material or to cite them other than as "work in progress." > The list of current Internet-Drafts can be accessed at > http://www.ietf.org/ietf/1id-abstracts.txt. > The list of Internet-Draft Shadow Directories can be accessed at > http://www.ietf.org/shadow.html. > This Internet-Draft will expire on June 24, 2010. > Copyright Notice > Copyright (c) 2009 IETF Trust and the persons identified as the > document authors.=A0 All rights reserved. > This document is subject to BCP 78 and the IETF Trust's Legal > Provisions Relating to IETF Documents > (http://trustee.ietf.org/license-info) in effect on the date of > publication of this document.=A0 Please review these documents > carefully, as they describe your rights and restrictions with respect > to this document.=A0 Code Components extracted from this document must > include Simplified BSD License text as described in Section 4.e of > the Trust Legal Provisions and are provided without warranty as > described in the BSD License. > > > The IETF Secretariat. > > > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > > From gnawali@cs.stanford.edu Tue Dec 22 23:52:37 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 018493A6959 for ; Tue, 22 Dec 2009 23:52:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.827 X-Spam-Level: X-Spam-Status: No, score=-5.827 tagged_above=-999 required=5 tests=[AWL=0.150, 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 kONZ1igCJGGU for ; Tue, 22 Dec 2009 23:52:35 -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 B45103A6950 for ; Tue, 22 Dec 2009 23:52:35 -0800 (PST) Received: from qw-out-2122.google.com ([74.125.92.26]) by cs-smtp-2.Stanford.EDU with esmtpsa (TLSv1:RC4-MD5:128) (Exim 4.60) (envelope-from ) id 1NNM13-0001XL-LK for roll@ietf.org; Tue, 22 Dec 2009 23:52:19 -0800 Received: by qw-out-2122.google.com with SMTP id 9so1517851qwb.31 for ; Tue, 22 Dec 2009 23:52:16 -0800 (PST) MIME-Version: 1.0 Received: by 10.224.15.210 with SMTP id l18mr5110481qaa.91.1261554736821; Tue, 22 Dec 2009 23:52:16 -0800 (PST) In-Reply-To: References: <20091222035821.C522A3A6966@core3.amsl.com> Date: Tue, 22 Dec 2009 23:52:16 -0800 Message-ID: From: Omprakash Gnawali To: Jaudelice de Oliveira Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Scan-Signature: 68b71d4cdf0c69f77def38598aa9caf5 Cc: Joydeep Tripathi , ROLL WG Subject: Re: [Roll] Fwd: New Version Notification for draft-tripathi-roll-rpl-simulation-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, 23 Dec 2009 07:52:37 -0000 I managed to find the pdf with the graphs. Here are some comments. It will help greatly if more information about the link model were included. -01 mentions: "* Link failure model: Time varying real network traces containing packet delivery probability for each link and over all channels for both indoor network deployment and outdoor network deployment were used. Thus, di erent types of link characteristics are used in the study. * Topology: The topologies are gathered from real-life deployment (traces mentioned above) as opposed to random topology simulations. are repeated here:" Is the simulation topology a topology from real-world deployment or the one mentioned in figure 1? Some graphs showing link characteristics (including temporal characteristics) will also be helpful. Right now, we just know that the link is modeled on real world deployments. What radio was used? Indoor/outdoor? And any other relevant information. These additional information will help us understand how and why of RPL's performance. A lot of people are interested in path stretch for p2p routing. Some of this information is available on the plots but not directly. It will be great if we can have a plot that shows the distribution of path stretch for p2p routing. - om_p On Tue, Dec 22, 2009 at 11:09 PM, Omprakash Gnawali wrote: > It is great to start understanding how RPL would work. > > On this file: > http://tools.ietf.org/html/draft-tripathi-roll-rpl-simulation-00 > > I don't see the figures... > > - om_p > > On Mon, Dec 21, 2009 at 8:12 PM, Jaudelice de Oliveira > wrote: >> Dear WG, >> We have just posted draft-tripathi-roll-rpl-simulation-01with a detailed >> performance evaluation of RPL for several metrics of interest (please se= e >> PDF file with plots). We are currently working on results with local rep= air >> and shall post them shortly. We would love feedback/suggestions from the= WG. >> Are there other metrics you would like to see? >> Cheers, >> Jau. >> >> >> >> >> Jaudelice C. de Oliveira >> Associate Professor >> ECE Dept.,=A0Drexel University >> http://www.ece.drexel.edu/faculty/deoliveira/ >> >> >> >> >> >> Begin forwarded message: >> >> From: IETF I-D Submission Tool >> Date: December 21, 2009 10:58:21 PM EST >> To: jau@ece.drexel.edu >> Cc: jt369@drexel.edu,jpv@cisco.com >> Subject: New Version Notification for >> draft-tripathi-roll-rpl-simulation-01 >> >> A new version of I-D, draft-tripathi-roll-rpl-simulation-01.txt has been >> successfuly submitted by Jaudelice Oliveira and posted to the IETF >> repository. >> Filename: draft-tripathi-roll-rpl-simulation >> Revision: 01 >> Title: Performance Evaluation of Routing Protocol for Low Power and Loss= y >> Networks (RPL) >> Creation_date: 2009-12-21 >> WG ID: Independent Submission >> Number_of_pages: 12 >> Abstract: >> This document presents a performance evaluation of the Routing >> Protocol for Low power and Lossy Networks (RPL).=A0 Detailed >> simulations are carried out to produce several routing performance >> metrics using a set of real-life scenarios. >> Status of this Memo >> This Internet-Draft is submitted to IETF in full conformance with the >> provisions of BCP 78 and BCP 79. >> Internet-Drafts are working documents of the Internet Engineering >> Task Force (IETF), its areas, and its working groups.=A0 Note that >> other groups may also distribute working documents as Internet- >> Drafts. >> Internet-Drafts are draft documents valid for a maximum of six months >> and may be updated, replaced, or obsoleted by other documents at any >> time.=A0 It is inappropriate to use Internet-Drafts as reference >> material or to cite them other than as "work in progress." >> The list of current Internet-Drafts can be accessed at >> http://www.ietf.org/ietf/1id-abstracts.txt. >> The list of Internet-Draft Shadow Directories can be accessed at >> http://www.ietf.org/shadow.html. >> This Internet-Draft will expire on June 24, 2010. >> Copyright Notice >> Copyright (c) 2009 IETF Trust and the persons identified as the >> document authors.=A0 All rights reserved. >> This document is subject to BCP 78 and the IETF Trust's Legal >> Provisions Relating to IETF Documents >> (http://trustee.ietf.org/license-info) in effect on the date of >> publication of this document.=A0 Please review these documents >> carefully, as they describe your rights and restrictions with respect >> to this document.=A0 Code Components extracted from this document must >> include Simplified BSD License text as described in Section 4.e of >> the Trust Legal Provisions and are provided without warranty as >> described in the BSD License. >> >> >> The IETF Secretariat. >> >> >> >> _______________________________________________ >> Roll mailing list >> Roll@ietf.org >> https://www.ietf.org/mailman/listinfo/roll >> >> > From jau@ece.drexel.edu Tue Dec 22 16:41:18 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1BC963A6909 for ; Tue, 22 Dec 2009 16:41:18 -0800 (PST) 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 FZOR9v0bFwdz for ; Tue, 22 Dec 2009 16:41:17 -0800 (PST) Received: from mail.ece.drexel.edu (mail.ece.drexel.edu [129.25.60.32]) by core3.amsl.com (Postfix) with ESMTP id 5997F3A68C6 for ; Tue, 22 Dec 2009 16:41:17 -0800 (PST) Received: from [192.168.0.104] (c-68-81-121-20.hsd1.pa.comcast.net [68.81.121.20]) by mail.ece.drexel.edu (Postfix) with ESMTP id 9136A33ACC for ; Tue, 22 Dec 2009 19:40:59 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v753.1) To: ROLL WG Message-Id: Content-Type: multipart/alternative; boundary=Apple-Mail-32--246182828 References: <7E1DF37F1F42AB4E877E492C308E6AC402EEF846@XCH57YKF.rim.net> From: Jaudelice de Oliveira Date: Tue, 22 Dec 2009 19:40:58 -0500 X-Mailer: Apple Mail (2.753.1) X-Mailman-Approved-At: Wed, 23 Dec 2009 09:37:52 -0800 Subject: [Roll] draft-tripathi-roll-rpl-simulation-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, 23 Dec 2009 00:41:18 -0000 --Apple-Mail-32--246182828 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=UTF-8; delsp=yes; format=flowed Dear all, I'm attaching the file in case others are having difficulties to =20 access it. Cheers, Jau =EF=BF=BC Begin forwarded message: > From: "Rene Struik" > Date: December 22, 2009 7:36:50 AM EST > To: "Jaudelice de Oliveira" > Subject: RE: [Roll] Fwd: New Version Notification fordraft-tripathi-=20= > roll-rpl-simulation-01 > > Hi Jau: > > Thanks for the document. I could not find the text or pdf version =20 > rev1 (the link takes one to rev0). > > Best regards, Rene > > From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On =20 > Behalf Of Jaudelice de Oliveira > Sent: Monday, December 21, 2009 11:12 PM > To: ROLL WG > Cc: Joydeep Tripathi > Subject: [Roll] Fwd: New Version Notification fordraft-tripathi-=20 > roll-rpl-simulation-01 > > Dear WG, > > We have just posted draft-tripathi-roll-rpl-simulation-01with a =20 > detailed performance evaluation of RPL for several metrics of =20 > interest (please see PDF file with plots). We are currently working =20= > on results with local repair and shall post them shortly. We would =20 > love feedback/suggestions from the WG. Are there other metrics you =20 > would like to see? > > Cheers, > > Jau. > > > > > > Jaudelice C. de Oliveira > Associate Professor > ECE Dept., Drexel University > http://www.ece.drexel.edu/faculty/deoliveira/ > > > > > > > Begin forwarded message: > > > From: IETF I-D Submission Tool > Date: December 21, 2009 10:58:21 PM EST > To: jau@ece.drexel.edu > Cc: jt369@drexel.edu,jpv@cisco.com > Subject: New Version Notification for draft-tripathi-roll-rpl-=20 > simulation-01 > > > A new version of I-D, draft-tripathi-roll-rpl-simulation-01.txt has =20= > been successfuly submitted by Jaudelice Oliveira and posted to the =20 > IETF repository. > > Filename: draft-tripathi-roll-rpl-simulation > Revision: 01 > Title: Performance Evaluation of Routing Protocol =20 > for Low Power and Lossy Networks (RPL) > Creation_date: 2009-12-21 > WG ID: Independent Submission > Number_of_pages: 12 > > Abstract: > This document presents a performance evaluation of the Routing > Protocol for Low power and Lossy Networks (RPL). Detailed > simulations are carried out to produce several routing performance > metrics using a set of real-life scenarios. > > Status of this Memo > > This Internet-Draft is submitted to IETF in full conformance with the > provisions of BCP 78 and BCP 79. > > Internet-Drafts are working documents of the Internet Engineering > Task Force (IETF), its areas, and its working groups. Note that > other groups may also distribute working documents as Internet- > Drafts. > > Internet-Drafts are draft documents valid for a maximum of six months > and may be updated, replaced, or obsoleted by other documents at any > time. It is inappropriate to use Internet-Drafts as reference > material or to cite them other than as "work in progress." > > The list of current Internet-Drafts can be accessed at > http://www.ietf.org/ietf/1id-abstracts.txt. > > The list of Internet-Draft Shadow Directories can be accessed at > http://www.ietf.org/shadow.html. > > This Internet-Draft will expire on June 24, 2010. > > Copyright Notice > > Copyright (c) 2009 IETF Trust and the persons identified as the > document authors. All rights reserved. > > This document is subject to BCP 78 and the IETF Trust's Legal > Provisions Relating to IETF Documents > (http://trustee.ietf.org/license-info) in effect on the date of > publication of this document. Please review these documents > carefully, as they describe your rights and restrictions with respect > to this document. Code Components extracted from this document must > include Simplified BSD License text as described in Section 4.e of > the Trust Legal Provisions and are provided without warranty as > described in the BSD License. > > > > The IETF Secretariat. > > > > --------------------------------------------------------------------- > This transmission (including any attachments) may contain =20 > confidential information, privileged material (including material =20 > protected by the solicitor-client or other applicable privileges), =20 > or constitute non-public information. Any use of this information =20 > by anyone other than the intended recipient is prohibited. If you =20 > have received this transmission in error, please immediately reply =20 > to the sender and delete this information from your system. Use, =20 > dissemination, distribution, or reproduction of this transmission =20 > by unintended recipients is not authorized and may be unlawful. --Apple-Mail-32--246182828 Content-Type: multipart/mixed; boundary=Apple-Mail-33--246182827 --Apple-Mail-33--246182827 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=US-ASCII Dear all,

I'm attaching the file in case others are having difficulties to access it.

Cheers,
Jau


--Apple-Mail-33--246182827 Content-Transfer-Encoding: base64 Content-Type: application/pdf; x-unix-mode=0644; name=draft-tripathi-roll-rpl-simulation-01.pdf Content-Disposition: inline; filename=draft-tripathi-roll-rpl-simulation-01.pdf JVBERi0xLjQKJdDUxdgKNSAwIG9iago8PCAvUyAvR29UbyAvRCAoc2VjdGlvbi4xKSA+PgplbmRv YmoKOCAwIG9iagooVGVybWlub2xvZ3kpCmVuZG9iago5IDAgb2JqCjw8IC9TIC9Hb1RvIC9EIChz ZWN0aW9uLjIpID4+CmVuZG9iagoxMiAwIG9iagooSW50cm9kdWN0aW9uKQplbmRvYmoKMTMgMCBv YmoKPDwgL1MgL0dvVG8gL0QgKHNlY3Rpb24uMykgPj4KZW5kb2JqCjE2IDAgb2JqCihNZXRob2Qp CmVuZG9iagoxNyAwIG9iago8PCAvUyAvR29UbyAvRCAoc2VjdGlvbi40KSA+PgplbmRvYmoKMjAg MCBvYmoKKFNpbXVsYXRpb24gU2V0dXApCmVuZG9iagoyMSAwIG9iago8PCAvUyAvR29UbyAvRCAo c2VjdGlvbi41KSA+PgplbmRvYmoKMjQgMCBvYmoKKE1ldHJpY3MgdG8gZXZhbHVhdGUgUlBMKQpl bmRvYmoKMjUgMCBvYmoKPDwgL1MgL0dvVG8gL0QgKHN1YnNlY3Rpb24uNS4xKSA+PgplbmRvYmoK MjggMCBvYmoKKENvbW1vbiBBc3N1bXB0aW9ucykKZW5kb2JqCjI5IDAgb2JqCjw8IC9TIC9Hb1Rv IC9EIChzdWJzZWN0aW9uLjUuMikgPj4KZW5kb2JqCjMyIDAgb2JqCihQYXRoIFF1YWxpdHkpCmVu ZG9iagozMyAwIG9iago8PCAvUyAvR29UbyAvRCAoc3Vic2VjdGlvbi41LjMpID4+CmVuZG9iagoz NiAwIG9iagooUm91dGluZyBUYWJsZSBTaXplKQplbmRvYmoKMzcgMCBvYmoKPDwgL1MgL0dvVG8g L0QgKHN1YnNlY3Rpb24uNS40KSA+PgplbmRvYmoKNDAgMCBvYmoKKENvbnRyb2wgUGFja2V0IE92 ZXJoZWFkKQplbmRvYmoKNDEgMCBvYmoKPDwgL1MgL0dvVG8gL0QgKHN1YnNlY3Rpb24uNS41KSA+ PgplbmRvYmoKNDQgMCBvYmoKKExvc3Mgb2YgY29ubmVjdGl2aXR5KQplbmRvYmoKNDUgMCBvYmoK PDwgL1MgL0dvVG8gL0QgKHNlY3Rpb24uNikgPj4KZW5kb2JqCjQ4IDAgb2JqCihSZWZlcmVuY2Vz KQplbmRvYmoKNDkgMCBvYmoKPDwgL1MgL0dvVG8gL0QgKHN1YnNlY3Rpb24uNi4xKSA+PgplbmRv YmoKNTIgMCBvYmoKKE5vcm1hdGl2ZSBSZWZlcmVuY2VzKQplbmRvYmoKNTMgMCBvYmoKPDwgL1Mg L0dvVG8gL0QgKHN1YnNlY3Rpb24uNi4yKSA+PgplbmRvYmoKNTYgMCBvYmoKKEluZm9ybWF0aXZl IFJlZmVyZW5jZXMpCmVuZG9iago1NyAwIG9iago8PCAvUyAvR29UbyAvRCBbNTggMCBSICAvRml0 IF0gPj4KZW5kb2JqCjYwIDAgb2JqIDw8Ci9MZW5ndGggMTQ2MSAgICAgIAovRmlsdGVyIC9GbGF0 ZURlY29kZQo+PgpzdHJlYW0KeNqFV0uT2zYMvudXeHKpPBNpRT0sObc8NplktulO4raHpgeuRNts 9PCQVHb33xcgIK+1ltuLRYIACXz8ANDxYreIFx9fxPx9u3lx9UHkCxFH63gtFpvtIs8WBUzzOFls 6sVfwRfllkkZ3ONPb37obrcM0zQL/lyW2UTw0fTDYfn35jPsHIo0yrM17fCpQ1unTKdc+N7IrTvV yqdKXa1q3C8N7DIUgZNuKYLBvl6GWZaD1rY3rXS672Qzd9b1w0EbRepZ8HnoFDmXZK9o1yQWMRoe IRi/iywpo7QoF5mIirik7T5HZLVZlmlg9EG6veaNruvIO4DHx+nUi9Gs5tN/a/RPDE9pI5+ZZ1PL 90Y9qIZUfu/YCoEwAINHRMMAbqQIHr19HolEPDv9Fr1lF/7AsbRWDWbG8VKUU9t32lY96X17tE61 /ky2/NRVZJqcH/peVapFb++WIfpsGG7xii8gjtfzuIdpEUerHPZL0igZ+XDrIzf+uruKcbyG2H8u 8zyQzeBJQIf0W/p+7Qd3pOOt6R1EAkBVfUMi2IwUb3qiNCl6Zh85Pnouu5rWb3prH0n2lAsFUt+S 9Hucx19vb+AjPDoiWUUiT6b41Mj70DGHQtM3TWgOTWi1R21ofDxhLPhuVmWUFECrJIdUzGiPN3fW GVlR+ohVtE5XoFBE8ZoP2ew1+lSWQd37a6iGVlFioXgdHCA3WMCKkhc8UhO8QaoA7NUp2GDgwYY1 zMs96z0BDwoj8CUDDyICHgZPwPOZZ8ijSx55UCDkGQ+K9hTSZ5UJAkry4vQ2IpSsgJpO6gbLCq5P AbekIo2i1Uoao0l1FUBUNPDxwOrBEKPqoWJ9qyhFDZQjL4AiiAnq0fAmnA4IgQhazCbZwajCkaLt WwW8qNiVwaLtTGmTXBaVI16OrDdKNmGjt4rXK9VJo3sbjZucMuQbFNTBnqZNFgAfqbjg5FfV9uf8 Kif8EqUv18W0pnv5uG6Hu1Y752u5WHsAvdn15gNJdEeS7dA0NKr67oR9oHKv3Z6WnCcaDPAC4Nyf 2tLdocyHAd+3727JrihJQDwCAa5cZFGxji7m03nnwjPzNfElzZ+3RVg5SzxLit5LWKdQ8imCJLnu drpTyvBeJXUdaX+Q5QdquB4dmCLPEU4k+ivS1yfuSYvCVe5RuBg8WQAXxpKmkZtcQXfY0IFGvpV+ 6Z0a6QIqciQhxMMFk9Rp3ErqUFRJG8stpdZQwPTd4NTzU3esMIcebsHsnFwILdG1RBc5O3uHyVpw zsOgJvr64cz5KOc6qGua+nrm96BPKx+4qrQkwNvGr9UPrNHTfvvx8K4eTVH+SBPunTQZqCbXErII 7zKOIdUPjaxwevFGfaUVkNx3tm8UJ2AKO9MpfonvTDDexRhvQXiLhK5XYBM8sXO6VciGFMjL65Tu 8O3kAXLzAMwwWvrrRYOevoNlwXw+Cb5fgbVsq4ziCoA0ciqceSzCGfxGoo6e0VEwr/TILQiyPeOo 28tuyqiXYwaTWPMyBLODXmmjl/9RDPmkBlg9LcnVYMxT38WXE1b72eBRe/TpeP3ewYpaBDzd+EEs ebO938cdXl9d3d/fR1q5bdSb3RUOroSuQ8nvBBu5BzdtA//v+8xrnZ6De1n74nvPeQfv7Mr10C2n YWQ+jCLgagFhnIWQXQzB0iFQVyNSaZvZNsaNiN0tZty91w1TRPm/BEwXdnH8Y5BO/xhE07w6Rewd kBtTwejd/nixvixqYOulBjJjlRSJr92Vfy/6qX8b+xH1x6QQ/I9jsGxB9QLkvn+gZHxYWHrEwJKu OYn191hkig2kJf2j4UnOP7GSdQe3740v+UkWvEEE0eLoPW+Fj0hD7576Ar3G65l7hwJs4zI8E5Yh lNZ/gEqcoZzI1M1B1Xfzp/d4yh0UmwH+HfDvCZhssDsiXr9wYt+oHf1FPPvHcb158S8yDvaxCmVu ZHN0cmVhbQplbmRvYmoKNTggMCBvYmogPDwKL1R5cGUgL1BhZ2UKL0NvbnRlbnRzIDYwIDAgUgov UmVzb3VyY2VzIDU5IDAgUgovTWVkaWFCb3ggWzAgMCA2MTIgNzkyXQovUGFyZW50IDY0IDAgUgo+ PiBlbmRvYmoKNjEgMCBvYmogPDwKL0QgWzU4IDAgUiAvWFlaIDU0IDc0NC4wNDUgbnVsbF0KPj4g ZW5kb2JqCjYyIDAgb2JqIDw8Ci9EIFs1OCAwIFIgL1hZWiA1NCA3MTkuMTM4IG51bGxdCj4+IGVu ZG9iago1OSAwIG9iaiA8PAovRm9udCA8PCAvRjE1IDYzIDAgUiA+PgovUHJvY1NldCBbIC9QREYg L1RleHQgXQo+PiBlbmRvYmoKODAgMCBvYmogPDwKL0xlbmd0aCAxMDk4ICAgICAgCi9GaWx0ZXIg L0ZsYXRlRGVjb2RlCj4+CnN0cmVhbQp42u0Yy3LbNvDur+ARnAlpgOCztya2O864rWvr5uRAUysJ U4rUgKAS9+u7wIKKJCtpM60vbi8CuNj3ExAPlgEPfjp7Ozs7vxJZIHhc8UoEs0WQpUGR5nEm8mA2 Dx7YdRcmJTOgOzDRha4XJoyqRFZsbveR0WpTm5WKdN+2kd600aDWlmJsa6P6LuIijMoir9gFNIAn BXsMI/wFHUZSpizhvAo/zt6fca9TIPK4knkQyTKWsiAtbnVvmW7VgDwHorwDK6ILBVsSwPR2lez6 cnZFuwuEIFkzroHMGKyoIJpECBlnaUUiPvCMrxyS2fxwfm70OBiAWIFZxL1enreqgW6ASHWLHnHR LFlxhvLdCh+4kNAY+uo91KyANvPauJ1g/YIgG9R7fESmzk2ebDGRqcHTHRsQh1EuMnbbQj143hq2 Cj45w/ihSSjeIiXFCUaDhQvW1BoWY9s+hWXK3lgcyWp/huRPnhqGRqtHx8IzfLJc+lETqkZr1HJl w0ucOau7OW00DJgljaHIWexPyqx2Zxvial1nITaIbnU+sNhO9WJSHQXE7wgyh1NGv+vXxLLv9kxN Kgafja4bA1YtBC90v6YDLwphz7xECJTQg/9SXdOOcyCKe7XetAqDnxLfir29v6CjG0oYLwOlE7j2 6hz41Otks8me3YNz1ynz0hgot12y2KxfecAsxNhpp6b9vIFl3dL2VPW48NhDTADabCxWwbY2lHOY E5oNVT96lp8sl1rr2jsHsZ88k4HWY6MszJXIvqLOQ05F8lBs7Ty/wloXaSzTPLF9CM2W+FXIKapd KDElgZbBk5T7rQtJkjROs5JIhG1UGbqlyrHbrFXXt/3yyfk0rYq4SAqkcJiSusIEPeCSEBdsgzJh RtsWk7D5+CU+38FLEq+fAX1KfE5xSE9xmKJPHDDrrDq+xyIrLN57MOPmb/PzGmU7jbBCbQwxhVwb RYawDXPMk3ak3oUnd7c3uBF5XrKcAnA4O7Ctyjw9zNcsxjgIniS2MNe9z4Ufh2Fcb3xLyIqEYV/L ON9b0qp6DnxFyzfsO5iGDzishPf3Fyg/dnLinXzrStS2V+vm38a6VcaCsE7LLHnNXnuJ5Xkkiq9E IpsCIX0g7rBrqm6515rrx9Y3wHv1B9i0z/73+Xe5vviLIkh3nYYGFN5JqQ6oKhr7+7v9AUPwX7fu S6+gxmFVZeWrdOXLOj3zTr/pB3+1oJuJZE3fdfYis921oKr8D7Xxf+b2w0fR8VUnmkbt/jDPaZjf wQI0dA0M/jYgECWbbgMiOTW5o7TIYrvfb2b5bnT/0us1XjWoWqbX106Kk/o6CuDfSYfjeAoc4OT3 r9ZRvpvg1/i+/Ka301cwx1+yegRWz5G3d8e7upEyj4vc/8dBLyf6I+MN9S7wT566RTkYP3yHXn7e KA3+ofN+7HxoktSTJFxwxE1LnrIHmjjLCefjgTqXs7M/AU434JgKZW5kc3RyZWFtCmVuZG9iago3 OSAwIG9iaiA8PAovVHlwZSAvUGFnZQovQ29udGVudHMgODAgMCBSCi9SZXNvdXJjZXMgNzggMCBS Ci9NZWRpYUJveCBbMCAwIDYxMiA3OTJdCi9QYXJlbnQgNjQgMCBSCi9Bbm5vdHMgWyA2NSAwIFIg NjYgMCBSIDY3IDAgUiA2OCAwIFIgNjkgMCBSIDcwIDAgUiA3MSAwIFIgNzIgMCBSIDczIDAgUiA3 NCAwIFIgNzUgMCBSIDc2IDAgUiA3NyAwIFIgXQo+PiBlbmRvYmoKNjUgMCBvYmogPDwKL1R5cGUg L0Fubm90Ci9Cb3JkZXJbMCAwIDFdL0gvSS9DWzEgMCAwXQovUmVjdCBbNTMuMDA0IDU5Mi4wMzUg MTM5Ljc5MSA2MDMuNzI0XQovU3VidHlwZSAvTGluawovQSA8PCAvUyAvR29UbyAvRCAoc2VjdGlv bi4xKSA+Pgo+PiBlbmRvYmoKNjYgMCBvYmogPDwKL1R5cGUgL0Fubm90Ci9Cb3JkZXJbMCAwIDFd L0gvSS9DWzEgMCAwXQovUmVjdCBbNTMuMDA0IDU2OS42OTggMTQwLjUyNiA1NzkuMjY2XQovU3Vi dHlwZSAvTGluawovQSA8PCAvUyAvR29UbyAvRCAoc2VjdGlvbi4yKSA+Pgo+PiBlbmRvYmoKNjcg MCBvYmogPDwKL1R5cGUgL0Fubm90Ci9Cb3JkZXJbMCAwIDFdL0gvSS9DWzEgMCAwXQovUmVjdCBb NTMuMDA0IDU0NS4yMzkgMTE0LjQ1OCA1NTQuODA4XQovU3VidHlwZSAvTGluawovQSA8PCAvUyAv R29UbyAvRCAoc2VjdGlvbi4zKSA+Pgo+PiBlbmRvYmoKNjggMCBvYmogPDwKL1R5cGUgL0Fubm90 Ci9Cb3JkZXJbMCAwIDFdL0gvSS9DWzEgMCAwXQovUmVjdCBbNTMuMDA0IDUxOC42NiAxNjUuNzk5 IDUzMC4zNDldCi9TdWJ0eXBlIC9MaW5rCi9BIDw8IC9TIC9Hb1RvIC9EIChzZWN0aW9uLjQpID4+ Cj4+IGVuZG9iago2OSAwIG9iaiA8PAovVHlwZSAvQW5ub3QKL0JvcmRlclswIDAgMV0vSC9JL0Nb MSAwIDBdCi9SZWN0IFs1My4wMDQgNDk2LjMyMyAyMDcuMjU1IDUwNS44OTFdCi9TdWJ0eXBlIC9M aW5rCi9BIDw8IC9TIC9Hb1RvIC9EIChzZWN0aW9uLjUpID4+Cj4+IGVuZG9iago3MCAwIG9iaiA8 PAovVHlwZSAvQW5ub3QKL0JvcmRlclswIDAgMV0vSC9JL0NbMSAwIDBdCi9SZWN0IFs2OS4zNjcg NDgwLjY1MiAyMDQuMjA5IDQ5Mi4yMl0KL1N1YnR5cGUgL0xpbmsKL0EgPDwgL1MgL0dvVG8gL0Qg KHN1YnNlY3Rpb24uNS4xKSA+Pgo+PiBlbmRvYmoKNzEgMCBvYmogPDwKL1R5cGUgL0Fubm90Ci9C b3JkZXJbMCAwIDFdL0gvSS9DWzEgMCAwXQovUmVjdCBbNjkuMzY3IDQ2Ny4xMDMgMTU4LjcyNCA0 NzguNzkyXQovU3VidHlwZSAvTGluawovQSA8PCAvUyAvR29UbyAvRCAoc3Vic2VjdGlvbi41LjIp ID4+Cj4+IGVuZG9iago3MiAwIG9iaiA8PAovVHlwZSAvQW5ub3QKL0JvcmRlclswIDAgMV0vSC9J L0NbMSAwIDBdCi9SZWN0IFs2OS4zNjcgNDUzLjU1NCAxODcuMjA5IDQ2NS4yNDNdCi9TdWJ0eXBl IC9MaW5rCi9BIDw8IC9TIC9Hb1RvIC9EIChzdWJzZWN0aW9uLjUuMykgPj4KPj4gZW5kb2JqCjcz IDAgb2JqIDw8Ci9UeXBlIC9Bbm5vdAovQm9yZGVyWzAgMCAxXS9IL0kvQ1sxIDAgMF0KL1JlY3Qg WzY5LjM2NyA0NDIuMTI2IDIxNi45NjYgNDUxLjY5NF0KL1N1YnR5cGUgL0xpbmsKL0EgPDwgL1Mg L0dvVG8gL0QgKHN1YnNlY3Rpb24uNS40KSA+Pgo+PiBlbmRvYmoKNzQgMCBvYmogPDwKL1R5cGUg L0Fubm90Ci9Cb3JkZXJbMCAwIDFdL0gvSS9DWzEgMCAwXQovUmVjdCBbNjkuMzY3IDQyNi40NTUg MTkxLjI2OSA0MzguMTQ1XQovU3VidHlwZSAvTGluawovQSA8PCAvUyAvR29UbyAvRCAoc3Vic2Vj dGlvbi41LjUpID4+Cj4+IGVuZG9iago3NSAwIG9iaiA8PAovVHlwZSAvQW5ub3QKL0JvcmRlclsw IDAgMV0vSC9JL0NbMSAwIDBdCi9SZWN0IFs1My4wMDQgNDA0LjExOCAxMzAuMjYzIDQxMy42ODdd Ci9TdWJ0eXBlIC9MaW5rCi9BIDw8IC9TIC9Hb1RvIC9EIChzZWN0aW9uLjYpID4+Cj4+IGVuZG9i ago3NiAwIG9iaiA8PAovVHlwZSAvQW5ub3QKL0JvcmRlclswIDAgMV0vSC9JL0NbMSAwIDBdCi9S ZWN0IFs2OS4zNjcgMzkwLjU2OSAyMDAuMzYgNDAwLjEzN10KL1N1YnR5cGUgL0xpbmsKL0EgPDwg L1MgL0dvVG8gL0QgKHN1YnNlY3Rpb24uNi4xKSA+Pgo+PiBlbmRvYmoKNzcgMCBvYmogPDwKL1R5 cGUgL0Fubm90Ci9Cb3JkZXJbMCAwIDFdL0gvSS9DWzEgMCAwXQovUmVjdCBbNjkuMzY3IDM3Ny4w MiAyMDUuNTEyIDM4Ni41ODhdCi9TdWJ0eXBlIC9MaW5rCi9BIDw8IC9TIC9Hb1RvIC9EIChzdWJz ZWN0aW9uLjYuMikgPj4KPj4gZW5kb2JqCjgxIDAgb2JqIDw8Ci9EIFs3OSAwIFIgL1hZWiA1NCA3 NDQuMDQ1IG51bGxdCj4+IGVuZG9iago4MyAwIG9iaiA8PAovRCBbNzkgMCBSIC9YWVogNTQgNjA4 LjgwNyBudWxsXQo+PiBlbmRvYmoKNzggMCBvYmogPDwKL0ZvbnQgPDwgL0YxNSA2MyAwIFIgL0Yz NyA4MiAwIFIgL0YzOCA4NCAwIFIgPj4KL1Byb2NTZXQgWyAvUERGIC9UZXh0IF0KPj4gZW5kb2Jq Cjg3IDAgb2JqIDw8Ci9MZW5ndGggMTc1OSAgICAgIAovRmlsdGVyIC9GbGF0ZURlY29kZQo+Pgpz dHJlYW0KeNq1GF2P2zbsvb8ib3OA2vVnHG9PXa9XtDhsh2uAPrT3oNhKIlSxUsm+2+3XjxSpxElv wzpgL7FEkRS/SSWdbWfp7N2LX1cvXl1n1SxLkyZtstlqM6vKWV0ukipbzFbd7HP0vp/ny2iQtpdD fGXFZpjHTV40UYfreLDqIIadiq3ROrYHHTu1R4pRi0GZPk6zebysF010JVsJJ3W0nsfwK+08Looy ytO0md+vPrxIWaZX10U9y8qkKBc5CpTO4qJJmiIjeYBdluVVtJo3JTDZq95os31CFpeqAGUOfKqc KG+v7vDKIorp5lsUU7T4+xV/5EDwK6nVgwfYJyK4Q1Xwhlm2AEkWwLdO0mbJfLUUThKmlZug2GAI JLpOoSWEpv0wEdoDVE8En9/HV4mSw4ZsOcG7T0i9c8PEQZiyTpqclczZPOC2IosGi0JkUTe2KMK/ MNKVdGrbq34LdMsmsmYcjhsvKHy1QTc+0uYA3lxGBu31SEYjeCcfVCsdbJo0En0XSJ174qXqv9IK IosYIiP71fFte2btJEO2VoqBli0S7ITWst9K93Iel2kR7YXqNXPvRkmLgRwHamZFUpUNqalZ4DgH 6ToxCFpZMXhuedNEO7XdEfRgzVqslVZzsChe/ERws+HziyDyPM+CCCEbofRoJXP3FkGwgwxqmUj2 0m4ZvTU9HIFGPv0Ihg7Ab298CnXSJaB5kUarnaST929X18/pe4dcfr+5IXd8mi9LtDR5FgDvwM8H stdOsM8cmV+26kualZIdOOBNeHw3jYxbazDcAb01mkAbYwnxJpgaNwcvuDm6O0QLBYjHPgbIb8+G xZe0Su9ub+CTEYXqn1P4IpmgMFESnWdwsM7tDUYQxJyjb+ezAHXGHaqG371E73oIWgEXrbG8svLb CPGhLBS5OANXer8xP0d6SzwhewKq3/krlt6ziHgh9s7sZcw5GMMN7v7lCcOrcywCU+U97XpUuvN0 J3oqOGdcPK7qu9GdX8TFy/sFFp/vrtEZb6qqXD5nSa6Fqx2aMG8gODkexj2b4id/gBFCe6vWoy9K Hj2Q+TCCL+QcYj2oThKZk5xOWEcR41iaPDrFqoWo24u+lQTdS0wuvpeytSZn42J0R3LBMsvWykF+ b9iKtGMRQkqWaMtTt8OAL4ucfAlHD/NqEQmrzOgIAOVLx1ptyPcI6eSBKtHT/pxrK3ukxPyuyyx6 K6jg0QVWulEPtPbpiiRrsoDsCe4r0k56MipMHR2ILdQUF+6ZGPWZJAoCc3M7SYtcJUeGr97LU5pi SSqr6OPUX741HgsG9LqjZ3yQWb4ASKoqEnqEMtxNmyN0TR9YSNpR8ePAgoj5+WJ8yLNpfwM3FosS orRKqrQkvSAB6wui86ZISziiBu8HhWFHknwbhVahDSCAdfnlH8WImWWc56fZ6gfleBMyx7BJD1r0 kqxC2UIW30nR/Yg01X+S5jV2xIHCgVxkSJTWcDYS+FEFy40Qd2KtGe7UMPoRkf2KhZ1nAjil+PWp ZXtsyYhy7HscCU8QT9gI/n/T30F1h9LehSnPmdG2Mug77dQc04bjtqcy2MmJlpgJ2CpCMpwZ5U/5 kpMB28PQJqhgwiUpTQpfcSexfD1fAq7s1mEIiWGWizbW7HFVcMMG0B2GLI0AsPuEZMcRAABhBKhC PgKMWrRuoQsxM0MHMNMSoJePBJmkrq/pCDslOWBi+UUgD3UD1zvly0OFiT5taPV5IYJZWLrhfFze jBZ0s8EjD8qFWOLLvq8a03Y06WH1+TTwWg87M+LwV2RNdP6cIVgr+t4MtA6Nas4Rn8OkB87FPqT9 MJrhuCAYWxDGATAuRiY4DHnjp9Aj9wAMzBQLAeyDhCGRMHJyaEB8WWtG3f29UbfqKHRTeMngszU8 ofmoJZjmUq5p643b5Bj3OMl00vdbPPGiwffAutWsW3NsTztBXZ2Gw0CR+2HbKwgwSCbp3GZkSriG HlBgM4c54ad9mBg2LDiNjjmkXOCgWELsX6wCNrFnOhyN/kWacdDDYnSyS6g9frz0PRz7gILvQdhB tXBEjiFCEjqFSf40PXMYAMLjTjITCFwYHIHeyweAfahsvBfOjftDqI6IIEKlhQ0FHyzYqs9pJg4H DfypstRLSl34ehPipBomCgRe9nCEhqEcaSbjSAUH8NyAh67xjxkcwdnO9fJsRKCZAxldsGdUMj0c Q/GklyJAOUBCYMLp+jQ6e/MBErpoqjM3sPDi3oeay20ydJUy8MJLah+FLjlrAp5hA8/hrOB5Fssk /8UR6jLXIaETfGsvaxjP/jhAc+Da82EMPTkvmSRPsxRwy2UKr3yaJraMU9yfCfB29eIv4fGuqQpl bmRzdHJlYW0KZW5kb2JqCjg2IDAgb2JqIDw8Ci9UeXBlIC9QYWdlCi9Db250ZW50cyA4NyAwIFIK L1Jlc291cmNlcyA4NSAwIFIKL01lZGlhQm94IFswIDAgNjEyIDc5Ml0KL1BhcmVudCA2NCAwIFIK Pj4gZW5kb2JqCjg4IDAgb2JqIDw8Ci9EIFs4NiAwIFIgL1hZWiA1NCA3NDIuNDUxIG51bGxdCj4+ IGVuZG9iago2IDAgb2JqIDw8Ci9EIFs4NiAwIFIgL1hZWiA1NCA3MTcuNTQ0IG51bGxdCj4+IGVu ZG9iagoxMCAwIG9iaiA8PAovRCBbODYgMCBSIC9YWVogNTQgNjI1LjE0NiBudWxsXQo+PiBlbmRv YmoKODUgMCBvYmogPDwKL0ZvbnQgPDwgL0YxNSA2MyAwIFIgL0YzNyA4MiAwIFIgL0YyMSA4OSAw IFIgPj4KL1Byb2NTZXQgWyAvUERGIC9UZXh0IF0KPj4gZW5kb2JqCjkzIDAgb2JqIDw8Ci9MZW5n dGggMjE1MCAgICAgIAovRmlsdGVyIC9GbGF0ZURlY29kZQo+PgpzdHJlYW0KeNqNWEtz2zYQvvtX 6FaoDRmCT7G3NHY67cRu6mimBzcHWoQk1BTJgmRc9dd3F7ugSEmZ6XjGXCxei8W33y4ULHaLYPHz zU/rm7cfZLKQgZ8HuVyst4skXmRx6icyXazLxZP4pV6GK9ErU6veuzXFtl96eRjlokTZ641ui36v PdNUlWfayuv0AWcMVdHrpvYCufRWWZqLW7VR0JOJ56UH/5VZelEUizAI8uWX9a83Adv09kOULWTs R3EaokHBwotyP48k2RMtPSnDRNyrft/AElKUOP38GDArhDWSkGY9fvoIuyapeEXbig4biYCPFHop hbULLVYl9Qydrnc047f7h7v1Dz+Q/sm22vbLGzyEFMVkVQUOeKkbFF9r0pe62xjVK2qpr3YYOZRU z0VHW6Zi4rfG0G6vRve94rV0jefEg8nIT+KcDvbeWpbBmWpcJ8vEw92tT6r3RdcXlS680A9J8zRV fSHd3nojo3sB8+x+oB/IsozdBd8/tFGV6nj4Z1V31lDoeVC9PTa6sTEvPECPbqVxmdia4qDGUVeO 86oBS2BAFObO8XCYOI7Eeq8QMIFohr4dehpiD43KmWs70rl1ejdziky8XbuC4c6vuhvAM/8qXhEt OZu/B6QohEwFQsvWbM8GnVyx+tYh39X6nnwSRZFw34d3928oJF73eoPT99ShO1IDmCDangfYvLdm lNTPluISn+n7Z5AE1o7sZIft+DzFGIyStPITTJTCwzUBFVL41mqZQtSlEEeZH+Rs+kODW0dhCgcu epLsrvC1B4FvYW/hyMotfbW9FRDookwH3MAaCh7D69YNL0v4s3Nrt6XmKXOOYV0/lMflKhIWMKH4 ra6Obh6v7e54MquH4zYW+E1lT+25Y89g6Vgjyl2cNMY040VbS6Fra30AAp9S/xnIeOO2A307mJam d6oDQ9MoEe94XTi5KgECsYyEUUVF2krXLywtkW/gTo+0OGnLoi9I2gEPgxudKaY5oAQenSOBdytV WzV0UXSAK0C1VicZOzBZCTyOqkrSTu4NWnxdMKhvSLNpDhCo6myJT7ePpEGQfrJ+tWB/QRtVT323 qtLswiNpHtGJjFhYhRwNelWMoQItizY0Yc/bovc6Ei2KbB+FMcr1PFj9a074CS2I8DjELgYoFDWr MfDs6Rrgeb2xtwaKA2GqVFVHCjyt8neITeDy+wIiEvfEf19pxPt9oevOBWU2Z4GVOBQuqqBvX9BE 9BB1F103HFoLNCk60lEowfCibSuw7blSbG4zPWhC56yarjsSTVivMRkhEr1KbxV1MdxAsnkDR3A+ x7yBTQYCjNg6apskB1IUHUWB2hBZR3RzMJt5NDoL8e7HGSVN7+d7DORMfKQ4gZDeFroaiE6mF/Ej 0oIUa33grq9LuInCHDkXZC7oQDrDBSnh5jeqI9mBAa5snN6OQF4RkEOMshmQcZRpnotnXel+ZEkI VmQhQ7JFNFzxt9mIKCHMYpf0YwTSSDrcVVUkEIiKurZYDLOE7gW7mMkQxdjUddnYu6T+5NINOIqJ A2kICyfIGaeKZmbS0JfMrLxdPasSYPYLbXOiosNsKTvQEgy2EFdXA3S9t0BxgC1hYeTdyOZI43K2 W3jE45EheAZA5lvQsOPg1qH6hdyrNwx4rhmiCdQ1gx/TCSE4dgkpPkunZ9gN00CsMW01Lfm+anZH xGqwopoHB/QNZw3o1GgxKq0ZKJyIH1tE/ChNQhebV90MeqQmh+0whTvlXgg7t2ZBMT5BGfGU7WNz mnbMbOUldplkeiYAAzCx+Ql9Nj05u24e/D5V+JfvAmhlXOHH/C7AEgceBafSAAD2WfVD+z9eCe/I uDghK2qKhlJdsxNu7A0z1d765bWeQiESH/RucECRjM1JikZ+pBSNfHjiWqbZi7tyteFYiUzwF4+b zukTsjLgcerE8ZV1t76RIAQLuQhl4qd5uAgj6SfZarE53Px9E/jhapXldshUtp1uJive/nKQi9vm 5nf4c+u7IZ5b3Zssf+XZKZPUTxMwJlj5Qcpvz5kLLX8nF/U1HXsSHwyhkVJBbuHdog+6LszxWnJh SKpuqPozN7nvwlslfgYmYzWchsmsGrZ+t9WwTWC6m9btkfhr6LiPMyc8wYxjooZ6KBdVGtKrmt1k fNVWfqoBkY9MRGkIk3dhdm4q1CM8YM69L93IpNPqHvAfh6HN8fgwpRYSI357mzhRAmMTSpzg4x3q IlucWubEAX9jld1TjhhXxMo2noYAdlAIoETYR+ki69gV5gGR2YDA9caAwFHw2MY3vP/t3Hl3qheh GGCyjyUFEHzJ7SicQQpURFoVt75rqT6z9SW0h/Y7EorztW2SdFxSkY5jf7qjcztGOjx46W0LD5kx p4BsF4W9O2pSMQ1zuZbB3HAlQxabTWNKQogMCHTS7SynCQRbaAfWqVAoXtbnHY2hFIiDjeN9N33i JemyEe1mQwR07Bk5PrJBuiyLYApmJkn9Hn3gwJh5rtYBk6uFV497N6VcqIJQ0Ieclo9P2Dydus+2 2S4cQ+UiSGiMRUnuXpT5+UPUPt7CU2+tXmdbJsQJoACcliSd3mnjtDH+Lot0dSom4yAUMqAvcJtj e/ppoCMveWkSTPyCQzmMQSrwE12UrbbLGC5bO1Zwh7URhcei1A2JliDceiFlTay4rTfy05RpGAwV K3eqVgZitputweXBlUu2yXCwTmcSNI4SiW5mWfBemU5B5Ut0uH6FKs6NfxwrkEiMzpv+PknVo+1n I0f6PdBvj3hKn1ho7djazJe9bqvuZkkGzxgnfh5zPYu1Bf+syiWG4nRRVD6WOatMirt/Wm1c8frr 4M4YxjwlDBAcMl4FsXiiOHZpIf5yXgr8B+HpxPkKZW5kc3RyZWFtCmVuZG9iago5MiAwIG9iaiA8 PAovVHlwZSAvUGFnZQovQ29udGVudHMgOTMgMCBSCi9SZXNvdXJjZXMgOTEgMCBSCi9NZWRpYUJv eCBbMCAwIDYxMiA3OTJdCi9QYXJlbnQgNjQgMCBSCj4+IGVuZG9iago5MCAwIG9iaiA8PAovVHlw ZSAvWE9iamVjdAovU3VidHlwZSAvRm9ybQovRm9ybVR5cGUgMQovUFRFWC5GaWxlTmFtZSAoLi9C S19OZXQucGRmKQovUFRFWC5QYWdlTnVtYmVyIDEKL1BURVguSW5mb0RpY3QgOTYgMCBSCi9CQm94 IFswIDAgNjM4IDYxMl0KL1Jlc291cmNlcyA8PAovUHJvY1NldCBbIC9QREYgL0ltYWdlQiAvSW1h Z2VDIC9JbWFnZUkgXQovWE9iamVjdCA8PAovSW0xIDk3IDAgUgo+Pj4+Ci9MZW5ndGggOTggMCBS Ci9GaWx0ZXIgL0ZsYXRlRGVjb2RlCj4+CnN0cmVhbQp42itUCFQoVNAPSC1KTi0oKU3MUSjKBAqY GVsoGAChmaERmE7OVdD3zDVUcMkHqg8EAJVpDfkKZW5kc3RyZWFtCmVuZG9iago5NiAwIG9iago8 PAovQ3JlYXRpb25EYXRlIChEOjIwMDkxMjIxMTcxNzAzLTA1JzAwJykKL01vZERhdGUgKEQ6MjAw OTEyMjExNzE3MDMtMDUnMDAnKQovUHJvZHVjZXIgKE1hYyBPUyBYIDEwLjQuMTEgUXVhcnR6IFBE RkNvbnRleHQpCj4+CmVuZG9iago5NyAwIG9iago8PAovTGVuZ3RoIDk5IDAgUgovVHlwZSAvWE9i amVjdAovU3VidHlwZSAvSW1hZ2UKL1dpZHRoIDYzOAovSGVpZ2h0IDYxMgovQ29sb3JTcGFjZSAx MDAgMCBSCi9JbnRlcnBvbGF0ZSB0cnVlCi9CaXRzUGVyQ29tcG9uZW50IDgKL0ZpbHRlciAvRmxh dGVEZWNvZGUKPj4Kc3RyZWFtCnja7d0Lkqy41ljhnH94OB6J58A40n+4722fk4DQ+8W3oqOjuyqr CoTYiy0k7eMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAb8n/+9//65x9NAQBAaz7fz/8493/+/c8/GgQAgKba /de8Ml8AAPpku//Y9l8LaxkAANolvP8K908LAwCA1pkv7QIA0AdveAEAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAA6MPn8z3/o1kAAOggXAoGAGCgdskXAIDqzi35GAAAiNdu9c8DAIA7k7b7 EQAAUOJQ8gUAoJt2yRcAgBJ1/vd//+Lq879fZ14AAPLM+6dVL+V780XmBQAgM+ENpLeBXJh8AQDI MO/pu5eSZV4AAOqbN/49L/MCAFBi3sD0KuYFAKCdeeW8AAB0MG8482Xeea6axdQAsJN5DzOsVhAu BQPAfmnv4xfF/Hm060IAAPOiunNLPgYAmCyw/+5hdandvz8m1PfTbvXPAwBGh/dPcKOqM4J8P/O2 +xEAgAiPQ/VGAHhNkDequbR2yRcAFpWvmTyTXI7//m/si4C73wAAWMW/SatXvjd7TqLEvOHqjf/+ 793kN40JAHvI91K7//yjDasnvOcM9/zfV/9LvgCwvIIDn//zc1qvonlP3w0t/pL2AsB7+JG0Bmlh 3nCSy7wA8HL/ao2K5r2cXsW8AADybW3ec857lwUzLwDs4oXr0r3k29S8YdVeLjtiXgDYRrufCJ+S bwvzHsERZnObAYB8ybdR2vsoZdoFgBeal3x7mlfCCwDMS77l5k2q3nj54xoTALYxb558+Tddvreb Nt98kXYB4O1pL/mWZ77tfgQAsKV5ybfQvKo3AgDzkm9/+areCADkm/qD5FvFv0llpAAAbzbv2b8a s6J8NRQAMC/5dlCwZgEA8iVfAABmMy/5PrawRgAA1DUv+T42L/8CAMh3wrbVegDADuTbWbuaDgAI Ilu+b5ZI3jizdgMA8iXfnk3KvABAE+TbLeFlXgBgXvLt3J7GCgBAjka+nR9jmBcA+KKifz3DMC8A oLV5XyXfirtx6pMAQBnk2zrhJV8AIF/y7d+AzAsAzEu+3RJe5gUA5iXfntolXwAgX/Lt327MCwDM 206+q/ulxWpo5gUA5iXfno1mMysAIF/y7ZbwSnsBgHnJt7N2mRcAmJd8O7cV8wLA28z76Rvzl5Nv h4YiXwCQ9pJvz1biXABgXvIdOzIAANjbvORLuwCA7dPe+eXbuXH+noD2n390UQBg3pfIt1vCeylc CgYA5n2bfKfSLvkCAPm2k+8M/u2Q8EaKlX8BYEvzznAY88i3v3arfx4AgIXk22EQIEOjzAsA2FK+ nRPePj8IAMC08p1Wu+QLAOjm3y0T3sc/+vmbwG8AACzKbCtZ+su35xveS73++6fP//3H/zLvbl0d gEA0T1DqKd9R2r3R60X+K+3duKsDEIjmCUp95Ntnx6qzeQN6Zd63dXUAL4xF2Z/ZQL6dd6yK0Wvg 6wSxa1cH8J5YVPfDy8m3/xbNkea9Oyp22LirAxCL3iDfbvtnBhrwxrB3056pYeeuDmDvcNThpxrJ t5Z/e25bnWreuyPkhe27OoCXxKKAfeZZ0hJp3shpM93GmR9b/vNwOsxbp8HDL9Ot3gLQM/5HTqyd Z51vknPv/Nu/TlO8C2a+BIt29fv35v/54p8f0M4AOmg3nAtMlXB9rw81bdlIn4T3G3xFe2rbNR5+ ltbu01ppTQ2AedPOK6XWbUPt3o2KXx5AzB5W5x/XmauM7QS+oqkBNApHf46znbV7rPCSsaDWbWXt 3uXYNwfwYN67N49cwLwA1g1Hl4lV+FuzhaMZlo0ExrWnPWbmZV4A/cPR3eutp2+FJuh+BtT1Sw6P /+8w6wTVVOde5d2peToR1DfvZYfX4ABmNu/niW4pfHj+6t/kx9U84QZkGv1umgUqm/eu9zIvgOrh KKDIsD3zzNtIx3dzle+zmCLzlgv3Uay28e9v3nMPyR5OAYBgRMoxb0ws+pRRot2fAzgH27zdEqoL N0O++m0V+cZvWqLlAYzKBWplAS10fDdyftysykl9kGgq3EgFP14RVDSvhBfAJBGpXRbwKSVqG+RU 83YWbkmj6ckZAyPhV720C6B1OLrbTOkqKHUa+cwwb8xOFDGD55M7l3zLuvrD0unA3QEAjeRb68Md dfwwWyz8IvvP81pCuOT7hq4O4D0RKXJVyyrpTGTCfGfeGc4uYlFwrHxN2Vq9q7uIwMYRaa3ptSXr m75X5p0nf4x8BgjL16zpDbq6iwi8NijNf+R/muhSTz/p8TdlsHpa8x6hyndWCi/f1V1E4J1BaZVj Pm624bqsTvRNNG9/F2eY97Kwgt2xFu3qLiKASy+MCEeBMdXQBKzv3188qu7E1ULHSW+c70/ajtA7 PBi4iACGzESKeJsZeJlbtGxklI5z5asK0lbmdREB9JdvjMv+DDvnYcTPfW36ikdVXcfpJRjy11zv HbfXWnjlIgIveLrODEod5BvjrO/FS9v/+Dec6raITnV1XFb86JN+8HvG7Z8W/s5t4cKrQL7AckFp Hvk+iulycuecE0FLd8bMMe/Fbpkxwwh7mzfveWaUeWNu0k/w8VJ8w1RPknrmXVCaQb55zv3zAJZY fJG5M2Zc/YjHnPr+67vdGueEdy3zxl9EO05jfufyby3z1opm5cI9/bYVV0jl7Ix5jrd3NR///Cvx OZeEd6x2L08kct9p8R8TOvfl/q21HKbQvGHnZpQw2GZD4xjzxuRKx03lpu3NG+hOq5j3fDqP32Je zKPd7M9IeNvJN6CSkppBGfOHJzdvzDmG3w/eVW5i3pnNe3k6Md9iXgzXbt0PM28V+d45t7xIX1LC O/lbv8Qmfd4YJKahtrkXwu8smBcYqN3XyrfptkuRQ8HXmy6V1QxKPa9V5JsdtJ8mZe1p3vCbi/lj V4l2mRcTPjfW/SnmjRdZa+ceuW94Z5ZvRfN+cketJbzMC2THn8eI9J7u+jjSWDIIcLXMp61wS7Q7 uXzrmjcg3zmDdl6HfJwev2L4itcu82KSrhu5k8ALzRsOcdn+vZuU20K4VbL4Dcx73E+yOiJ2Y5gt Ypd0yFp7gk0SwWgX62r3vAL98rsv6bSXzxsV1171FG55wjuzfEvMG9h4YeaEt7BDrpvwRl7E+2tn Jw3Mbt75n/mHaDcmEsYbsINwqyS8M8s3z7wxFYcDj50D+395h1w64Y25iHejduc7mhEwcKDmeN46 4KXmrbv2aohwayW808q3cOvm+BoNs2k378MVy0/MId8089IuJhmouRyWyTBvN4nMqd3HwPjo3KYt 1mhh8ormffTXHtq9+5FAT5j8zv0WF7KkXcxg3sALkTvt3pn3m/TmaW5Bn81bOKoQbqIOWWT15VEb pb1R8p1kJ7fyDhmj3VUWjqVP57YXPZh3XkFfajepDFlME3WLe422aJ4qUBemvcGXod/JtZu0DGrF hDdw40ReHVvQYx7zRlYeL1mB3kHH7dbd3NW1eZwEHk57+7usXWWEeeRbsJ3XMhVDIhcDHg8L4m57 wsyz1sPHpuwLlpLvs3n7bPwylaDvtHsZ0y5bLLuh5lxJtIR8yzb1iuw1nwnu2e/jM1XEDjALmDf1 oZp2sVDa+yTZi3VGo/pwHx3fJbx3zRKsB1q0vUatANihFODq5n2K3lOUU4w3b/Yz82zDF3nHQ7hY S76BLQUKZxwtIejTWcfuDRtZCnaIfPsoY4a0N6Na0zzjBtk37HE/PeOql4Y65FSPTxusjwAenwx3 Mm/hc3WGeY/bQb/8thq+RfNy8k3cTCO5ZX7ugeHmfVwMuJx5ORevlW+tDy/bIM/bU0fObT6Kh+Ur yrd/5JzZvNkPJK3lG/ZO6pKEq3cik5qXc/Fm+VbZF/GF5n3cZnDdRLJp4jnkTxeOA2T/ePkkwC3N 22htgsCO5eT72pmBMSWZYiah1S3q9A3tKjbdBZo/7S0ffj/Lt88M/OzFgDEvUPpftQ5lQcR2bODf F7TAw3Bx9GLnti/EJ39GGijfx7+bl7F+73fn77wUvcy8EyW8TYeXmRd7+Pc15x4y732tsa7mXWKA YpR8nzZbuJBUniIz5Fv36oef/c7nO495VynIBaziqS1P57EYypH+Qq2Wc0s+tqV8f/5i06Xfo9YZ RVaET12S0OFi9a/JJUpjV+0y71Wgq2+9FXeGbx1gh293NuQueFwMeFyvB4xKeL/tdzlbqyAXQL6j zmWGtVcrVkMribRL7PI9KvONvLLxz4HthNh/ZwzmBfmunvAmpZDt0szsXzunfDtbtWkvnUG+5R2y kROHrNJlXpDvNuY9xk1tKvy1/eU7MF29WYzTtlrE8Be+5R2yuhknqO/JvCDffY6//3Tiuxk1cW/3 Kle4mH8QuGfCO1y+tTpkRT8O342KeUG+2yS8MeGuUSi4nE5zbvDAGs/UxGf+AsqREunWLcfK9wiW WOqm3Ul2gGRekK/D/pTF5MAs1rN5z386kDh3FutY87buRWPXGRXap+I4wwybnTIvyHfLhLenfO/K 05xFfPlHq5u3Vk7Uwbyde+M88k09hsKLMluxA+YF+TJvoXyfJq+GzPv4e/oHzA5/7mzePh1p1N8t 79IVV369544GyHeJQ82Tb55561YKbmSoPgbsf2qjX/h+Hot6lF+OaYv60S6YdyHz9m+ZT2wB91tj xg81z2ne1tslfcbVaxi3zuh2a9O7g0m9FpMX0mVekO/8t8CIDRA6mTcpd95JvgPNO1y+4aJFhead ahoV8wKLynfcAsyc5cMlCe9x/553M/l+JpDCKPk+lgu8/FZkc83vXOYFlpDvDC/j8uT7tNHlJ2N6 1cBautVLoo+1w6h6RuE/dPndmEuwinOZF5hfvsMPLP4AwoVpwst4k8w7sDZ63SadJ+09Rkyej/9A /BLs+Z3LvMD88p3hkCJb5r4qbNQs1vAuWwM3m6or38sajcPN2y3tjetIseZd0bnMC8wv39n2GoqW b5p5M/bM76zgKn/lpzVm8EXPTSyje9HvxyLLSK0YakRdYDb5TnV7ZmS+0b85p45DfwVXlG84lRuV 9rbu/ylzBkLmXdq5zAtMLt9pE/DCAsElnx9r4eq/bQZx9KmalLhI7XpMfgPn0i4ws3wnf+8cL9/I eugdigM2bpnx1WZr5fIt+l76rmi/5t3AucwLRPrlo4hY1iNBxXrokys4++zmkcj5SOp2v6ydwG/N u014EWmB2VLOJZYYV5Fvt4SuegwvfLqYSiXt0t6CAlgbapd5gWnlO/+9mbfJRjfhdrBwxoj6Emlv dfnm/ZItnfvTJmIsMJV819pNerkYUq7g7FlkC6W9VS5xxm/4bprqApjZL3uUL1xCx3kKrrhyak7z tpBv4eWQIQLkK+ENN85y6XCSf/MGzOc3793xdLiady3PvAD5zrCl/BKNs+4ckiTthufAXzXLr3yn Ne9Zvj0fe85f92IUIF/aDTTOuu9/z0YImDf8pHH+7hLmzTikkulz4RGG81akK0ePKSYZAuS7k3kv 5btjB/gr4T2f/vm/f3LGn6g75wyiyKMqWS8WM6o/qoJwB+fyLzCPfFfX1qvMe3nul49PgQHnyc37 va3lV2chc2TJ3UWfSMduJgOQ7/YJ7zYPD3nmvSvGdDUKvcCAc/ioyhcyRy4X6llHqbV2sz8DgHlf nvaeg2TgTG/KIy5m3m9KGeWAWc6/P1X9C3WqWq0EoLV899PufvINmDdmbvNC5r1xX6cSkEebbT0m 1C75AmPlu5N5j02HncOjzZdzm5dbWBRIeysuZM4w77HM3m79Wgkg39mS6OGtsZ98k2ZY3TyQLGPe 4/dNa+xC5qsukayVUXt61O0h4QN+HA8B0NSYmyW8Oz1RJKW9lxH1j3ZYYBurOwNGLmS+/Hr2Ot/l 7pTA88nnKX9nXqCzfPdLeHeV7zvNG7mQ+e4rqVqJMe+Upat/tXsv2U/kBDwAjeS701Dzrid4FR6f Vfuo3fnN+88RRg6zH/f1EWqZd+bH1KTnk5tuw7xAb/lufO47yfdqa6WH7GyVQoGp5o1MeOuad1r5 xj+fMC8wiXw3OPH3tE/dBZvzyzdyIXPgzWZ8c8UVamReAK+Wb/wp7yrfwk2KFjLvNzhxPVg2Itm8 tXrdcPNGzm1mXqDEQZGxeo9bLDUAbizf8vIBC5n38uoHBp+Zl3mBCePzS8x77DvbOfvKTmXeyyP5 07zfxCJNjcw7oXwvz/Fx5iHzAtOmRZNrNzX6bbzON+aC/pz7cPPG1Oy7k2/2cqrjNAF4dfMeNztp hI+fdoGmobjkY9skvBvLN+PE/zn3IeZ9fBDMNu/VwtXbZLCwKWZOe89NwbxAT+1W//zSCS/5fm5W HI1VbcSM4v+/nOrP4n13KnxMeM+sbt7jZtHZ4/ZutAvUNW+7H5nEIGP1vZN8R9m2xClPp/Y45nP9 6fguMbb/3A8OfIJrrG4fOgRPoJt215XvDLkz+bawbXhDjPM858L+fGnemI4xqvPEvBNXnxeYXLvk u5N8U+cI/TmE20i13/T5549dtHAh892JhJlBvvET0qq3EoDA3XQZWgNR91NWBbXPs0S7Y9tJvkmm i0/uWiS2ecfTaMb++bAjFdyz51w28idCvlsuKgQmNG98vZI5pzh2DhfbyDd7mlD43NvZNvwoeHcw 1btHZImiy+Ps0HPumjpj/xzOBZomvOfokXS3TuvcRqFjD/lmj+7+nHiLYeSKqfepbm9pl4g5nU/6 WHQ758b3WM4Fupn3MmjMb96Br6g6RNE55fu9mxDcTLV5qe6dj+raLe+wW3SecMtv012BXc0bWRp7 uHmHT8vcI5olSeRyZlFT22Y491u231SLgYJIC9dy7je4IBfAVOaNXPk4g3knWYa8gXzDHgkks+VT nRtp9/KMKj4YVPk9tRQcsaPXw1xrwRCYxLyFG6d3MFHhMuR2XtjAvPFvbFufeKqSwnoNu2kq86Y+ Y8RM90r9LoCe5kpajRgoRN7uxdZ5Vvbdb+6zEip7ectU5o2fH9VHvtkzqWLy95KnxFq582Xhwpi7 JnJ4P/JBmnaBGcx7pNQLyzNvoY5/hjzvnwou5ok1XWcUKdwZFFwyG/lyrUrFGJ7XN2LGk8OvQXtq N9xud/dIys7VsdplXqB1sE1Kex8VE19jrqKOfxLe4FPB9Qztbr6bbYOCWgt/slesNHLukfIatzDt rTuL7PFPh+eQZ2tXwgv0jLeF5q2yk0axjaMOu0rp84rOLflYn9z2m665ujlUlVlGGR+ewbyp25JE 1jgo+bsAKobcm7B/66y7vXeq+yLVvDHb9A0x79jCixmezTBv3XheOBOg8Mkh6e9WXzkV/tOPE9vy Xt/QLtAtxwnG/NjqnI20m6LjyO3qP/ePEP3M2+5HMmzbwSap9iyffVeSs6emva23B3l0btLDqoQX mEq4YzVRGMBTzRs/Xl0lInUrvFhxALn/COpA7YbT3v7mPf/1vDqJ8QqmXezEkGkz9WqIDxgazRs0 i/FmyXh1yezrpoUX2+2NXNhnsheGV9y+qVDZqUtoG5k371J2WE0wfyQE4XboeHUDb+vpQHVnOKfO sKpo3ogB7VsNxbTJ3W9ovTdyxvDIY1ePXzJT5S4oP+uB5j0idoCMvLmyE+FFIyFot0OXaxp+C8/l U5XIQ40x7+kIK2s34PS7eB4sIRdr3hZhv273uNrG5DOJds8nnjTHeAbnHgnlh5orWIVfjHJu3Tyx m3Czbp9Ohi0x75G+k0Zd7aa+eguf3bfl3sjR0/CSu3q7gF+l/1/26Z4J7+WtVVe7rRU8zwI6vE27 1T8f49wRufxEr5MeF0NdmjfjEsScXa1s+nE4vR33exqXdvUW/aHRSHukfNs5N2VGQWXt5l2jsQvo 8GbztviRUdVO83K8IfMkHxdDXZ1jzVu+1hbWMbnzJObN7urTavec9vZs6uzdtHL3XE3bqTLpvc9U KyNAu0k/2Ei4jd7AdkvAq1yILiuhosbAI65IbO7c2rwVu3qtw27R67p14MKKflW0G/mbk/Zxbb2A Dmi0bKRcuD0nOM0p38gXTB0O5tG8d9+tO2pdaN7qXb3uxKq14kb83d2ozEHh9ibV99IhX1SJrsdV jen4hScZG6FXXQtTIWJPIt+Bkyqzzfv4ezo8UAXMG98Vk05kxc7WKNWNdGuVzTlLhssee3vkaHZM BwNKRhSv/vv6N9xVfumQwI7azaCnf6fqG0+RKn4IvVoPSTJvyZ4n5Zsz9+lpVXpR4RLdGANWT3gj HxEDj1WR+mZeVAmtkeZtlNSU3FAzrKycJ1pW7yFJ5u25Odjlq+XIhPfxK9Xl262PVXmKq/XmqKJ2 PzWrPMSOZjwN+JAvapr3ScT55m1wUpPOe9mmh4TN2zMWxcs36TCCJ1hni+w+HazKm4sq0yMr3v4t Qkfe0B/zom5cPYJ7OMSY9xhUQGTatR6r95D4TRTDP96zD5SYNyO0xnf4IdrN+0ytJQnVtTvWvI+z o8kFqWMsl10uw7yDzqjmXcm8x1XV48iBuOGzPfPMW5LUjK1TkP3ME/hw1d1cq2ww1eRhPnVKQ8Ye 7MBdPwmodgnzVn8elvZmO3SGRRb9zRvTCTt0qrrXq3qZ43LtDjfv4yAPueCF5m0RvQfKd/gBLLql XrZ5M0J0pCA6jzN3+KkM7c6W8Baa1/RmlPS3p613Zzdvu+fh4fKdc5VTycemNW9ElZyE3zNkk7SS 8fAWV63W3Ko+BQHT+wPzojCiZpp344R3EvfNM+K9Vum0pIVFcTlO8gTpP39h5+Ig4bMrXHmdrcux a3hT2y3JvLSLFg97qTtpbGneIfqb6l3zWhVLU9PeKgnvpXeGJ7yXd3TTtDe8v1z1XZr7m1fCiyqB NMO8kwTbDsuXBsp3zlleScLtv74sYN7wSGzqnRLTM/tXw3y8BK0HnGM2jZzqBo9cQHfeD6Ske4B8 L7fCCN9N83S2PoF9lHxXn189ZGX3ZdOFe2zMBhoZXf3Tsdsk7U1dJa/PuOKp/aFb/4lZQNei2gLI d8WqlD0DO/OuJd8qFYsKu3rPgrnlgw+FN3XkNKq8SgciITY270LLRnomvAPT3j3WFA+Rb9i8Hbr6 ZRI1g3lb5LytN4YVCbG9fJdYNjIknveX7za7eQy8WKO6+t8vmsdMEzpnji0WFm2g3aUjITbz7+Tz V8eOYX77JtpbdLDPkDGKIV39e1Eyqe3px7/FTqqE2EG7s0WY5SIhXiLfd+ZQQ2y42Q6Wy8m37uPZ KPnGlN0Zot1pQw3tYp6ON2cM7/+ne6a9++0dPdukuOpdPdw9JtmOqYp5mzp35vyXIPDiZ4ORL5W6 yXfLqg3d5DvndPTh8p1Nu9mfAfAe7faU7671kvrId+Bc9G/ExoNNK+/cybdKJeVa2q37YQDbm7dP YN+4UmEH+Y6aiB7zF6uc/uMr7BZq66Zd8gXeli5NkvYyb+vWq9i2qRersAUCf6vdcG6tacwdfqpd jxKEIeHdW74bm7eDfCPNW6WF83pCXgt8I7aDbjGFqbp2I+sB/bkB9gw3uyAMCe888nWzryjfKi1c 8gCW2gLflCoMec79tJmVfVeVIOYBm3kBCW+3W/INN3tT+XY2b9MWOIszVXl5taWqbFEVUwwonAsP ly/zQsI7p3mr35UvudnbXdkO5q1y9R9b4Nul4OBZsrV2hoyvgdu6iKGbEdgg4W0q3/fc7I3kG27A SbQbboHsVLeKfGtdF+YFmHeVG/NVN3sL+TY1b3Ub/rRAZ+eG5Vv8O6PMG/i7zAvQbp+09203e3X5 9jFvixYocW7dBLzKtUgy7+X/Mi/AvH3k+8KbvW7Ab2feDi/3s39/YV3g4Tnv5VfmMS/5QjTeW77v vNMrXu7w5ShXW2vtfgqOLe95dex73pnNK+2FhHcJ+brTy81bUb4tzNs01c1rgRLznpu9qXzjzTvJ NlbMCxnQG9Le197pM5u36Qv9szSTGuHul5S0ebuFRYG/xbyAhHeUfN98p9eSb13ztnuVf/61Gcpr tJVWC/k+in427TIvhN+XyPfld3qtgj4tzNso1S1UXt7hxfyJujtZhV8i//2dL/MCEt6e96k7vTza 37Xh2IQ3fgJzvPLaabeNfNerz+t+BPO+Ie11px+VqumVm7eddpNa4FNvJ8wMk1aXb90ihswLvFy7 VcK1O71cvlXMW/3FfXVLfi+233hwVl6rtpBvlSKGzAswb5Wg7U5vJ9888/ZMdS9bINtiFe+v6hOu 5ndut/txiXaASLuWfJl3SJcoNG/FtwYNdpssSh4/NSob1lrnO79rmt6Pyz2HQMK7a9rLvFXkW2Le Wu8Lql/Kc2T+xmXELa7F5x1dtNH9uOjYOwTYXeXLvFX6RhXzzpzqRkyQJt9JzbvufDNIeHeVL/OO NW/5YEWHLCnyrzQK3a+Sb9OBi7ofBpg3+85l3iryzTNvLe02OP2/InDK6iTynci8GZeDfEG7HdJe 5q0i33MzJiW886S6l7E36W9NJd/vshvT1b2UHX4KeLN5U+XLvI3k2yLhbe3cy8B7/ouPzdIodPfc ZXqVJ+ckgV6222Wrki9ot+n9y7y15Jtk3uyhiZ7rPS9P5FRr4NMzaeqzy/Qeae/PVQjsX33+APOC eZvev8xbS77x5i3UbuOT/Q2555qA4RxqHvku2rerHPadds/mvRcx+WJACvOStJd5a3Wbu90jS9q8 Z6qblPA+yrdp3G60y/TG5n18UmJe9ImibzjTmIjNvJ2f2TJeBPS8QO3M+0Ect2UOg5Sb9zSgwbxA qzjPvD3lmzoQ0f/qXC4mYt69zXszEM28QJF8Ww9tkW+qfCd0bsC8gRDNvDuZV84LdE6KNUW8eTsM UHS7Iie3PmygERP2e8btwJF4z5sx2uw9L8p7nf1YtNISTdot1b3bJf98CoEj+VlYFB/5e8p33UdK M6ywR+hjFq00c5M2dW58iZo7+WaMAPTvSGf5vty8R/ROGjfPVEIB6oQ+ZtFKEzZpde1+kw4o6M2n 4kRTJLx38mVe5kXn6Jf9mRe20mnyKvl27XiFYTbVs1WqHkRuHdm//1zK97Xm/RHozTSq3z2saBcZ 0a/uh9/QSjezaMi3X8crrJhQ6Nl/o27M0T7O6x7ec87yZd7LidKXzeXeR4vo91qtZORcbsAZOl6L lPYxgf1vpF71zlq9pODAQoHuemQMp7T+qS1bKeZ9n27WreO19myMpM7mTQ3aw/vM0vKt/obayzi0 i36R99oL58zfnenPFFDFwmoJNGOhazfV3rnpc1VZOHLS3YRz874RK47fY97D1Eq0CYB3ta4uow3z /tkUf2r33IBuxlTzXk5ZKTFv63zwcfeJFYN24GFyIfNWv/qci+oJ7130OwecyMxle+3+mNcjSsWE N9APw/JtfOTPMnqccbdE3A6P5Lwz7Q1fTfc16uYdzBtj3i/ztul48Wlv+8NO0O43YsXQtB3j5yxW lK89XbFcALzT7hFXBitjNulU/zy20k9T3O2K/6rnk73N+4lO/fYI+IFCD6vIl3mxUAC8L9vxiXfK 3uY9N8VldjA8QXuneau/4PskDrfuat7l5Fv3QjA4+pj3Z5OWpGxuY/NeNsXduBzzdjZv7X2okl9x Fkb7eYx2fy8sI99Gu4m6edEuAJ43aUky78at9GjemwZk3unMG/7nkzWzqCQ+T2W0xypL7zSvOxfd AmC4ivSrzPtYhvvOF8zb07wdxl4aZUZLmPeIqhowfhYZ82LdtDds3vet580xL+3mdbzgV6IS3shw 2sfLC5m3LHOfZdlULV3SLsYGwDencjE7aTBvOHzlpb21hpojlXd+muop5UkGcvNcM9tuIcyLhRK6 x9Gk1wolUKnzbg8r2o0sYptk3nC5olT9Fb7Pre7lRc074bbGVYxpbhX6mDdm0+ZPVhGWbcz75/Ki s3kVCwu46bFJH7O/x0KNSe95P1U3aOo85X4eZ81ZyqeueWkCfbQyw72zSiupzxsjoKYd7/HPTeK1 JaSc9GunrYRY3jgSXnTWijJYSa30c3uGW+mz6V1csGy2QseL/+tTZZcTejn1B6etMVrRvOyAnlpR kqN6K61baryFc2t1vD//Yswr1KRpVDGHWruDPZRAaurlFtr9jChdzbzYzCyaKLuV1i013kK4tTpe /EveyEoHNz/b775I7STfYZOxn889qdrUPOalXcxjFs1S3krrVhtv59zyjnd3JHnHmerc6vdI3e7R SMTx2v08veVv3UuZF9iP9Lmgy1cbLw9rrQ/vz3bOPuyzdm/GsWeXbxUvZye8Q8xbYk9zq4D9zHss W/alSpLbYVLuedFQXv4bdm4gNV7IvOHOXGLey7qia5lXcAN2Mu8S8m0xqvzze7Jn3gZaNWN50aN2 I1umonyH9I2K06vituWZ0bwSXmBj887s30Zvcs/aTR37DaZgt5OW804wxgsB+a64jXMt8waqmy1k XpEN2NW8U8m36dSp8y8MpKWp+cjjiqGkUz6Cm4XeXcGAfAtHRZiXeQFUv1WHy7f1nhIB7SYtKY1Z pRufJsekro8SPH8r5tXwnPKtYt5wXdHJzUu7wHvMew5Zewg3INkYvT7+tpgnlvhTu0xaw9flcX/p o2zjypnNewRreD2at8Mmb8wLMO9UyW/PjROTEt4k837jGirpNO/e1cYU8AprJWvlzqf/8qKU7lp5 J426/T/1jGgXeKd5W8u3/07FqQlv+Lvnd7jZGz3FCCVS8fGlDDMsPLN5j7i1RUkJb/xgNfMCzFvx hm0h3yHVAR73lUpqz9TZU9nyDZg38DyQmgzGW3gJ84Z3TM34kXIFZ8+cF9OAF5q3on8HluO5+3Px 850CobjkXB6b4uyFb/DvFpo3ycITduN2NUYLFZxnXgENeLN5C+U7TyHa1MwiZuryt6V8A68gA1WQ qpg3XsFjy/IGfNqixmiegvN26hbQgJebN0O+M9ScLSlCdzdvOW+5UJ58A+Y9rpcg1TdvfwsXL0vv UVciScEZ5hXNAOa9DDgzOzdSuxnmTc1bC/37uJNG4BVw07qBjRRcb2Vcp1qKMQpmXoB5GyW/kwi3 SsJ7ad6MpLVcvpF7WP2Y93IXjrpXv1EiPEOpx+oWjjwp2gUQH2Fmc25hwnvyV/LQejv5Rm6m0Ui7 j4Me5Rbewz6BG6TK62AAr5XvhMKNcevjKt2kPOXOOLWO//v7FHA94BDItFqsNctrk5gm2sw+n4uB iOcJA8ILgPigOtuxxX83e4Swetr7JN+09TKTXKN4C+9qn8CEvZ/5csILgJj4OU95wbyUqkokbFrK 8Hsa1H907r+fmfbl+3fiYZPO5pXwAkhNcicpLxiv3bsj/5QlX61rGpasl5lQcK9ScHhXlvjpfADm odEczqR4OE95wZjoV3ENZru0Nyb5Tbru1e1Wq+Ntr+Dw7ILIxeMAZnZuuX/zAuDAoJGU8CYV9Stp t0bpYaHyqqitRcfbeCw6cspf3UoNAPo7t1ZMTqzX9hlb3vfxM9V3/OuQ9rbQeva1brdJVKCG4+oW Tp1sX6tYA4B22s3+TEXnjpJvknbjX6W1q4Mwj3wzUuB2GyPHT0pf0cLxcw/CdxMFAzNot/DD7YJY nxARJ4ucOne1zLuEfCMPu10xoCO3rMAGw9HRQw0UDKyh3fCPtI5arYND6m5UfbYx7COC1v5t2vFq Nfg7FyhRMDDQvOU/1SFGtQsLT9lZ/p4YhebtI99P4xfKTTte9QZ/p4UpGOiv3fCNdv7WnXw7x4fq 8o3U7n7m/XQ0S2THC28U0dS8SRam4Ebdo09lCmCUef9W6vMuvkebmnF5waHdXVy+CWQtC7SO9pfb bbUcu3juePexv7d5Z7NwTzH1VHDrIsjAhAnv+Xa7++9Py4KtqTGh5EZOCjhHwS70a5m3tXzjO975 ICM7XgcPDhmOHmil1olwu8VlwLTmDUgtGBsH3wif26lQRXdxxR0gK4qgz+y1wF/s3PGCfXK8eTtb eB4xVVdw5PHzL/Y2b/gOmsq8MXdoxmfC2n2PeRvJN7vjxbh7iHmTLDykS0+r4NTDJl/sZ96Yu2Zy 89ZaIlpl4+XqImgk38h9L+stzU7ueKeJB/Oat7qFm656Hq7g1ovLgIXMGzPiN6F5293FhepZ2rzV /duh48026zh7OHotMaUqOPtQyRc7mfcxDq9i3uo/VWtxaIsY3se8FeWb1/HiL9nk632S/Nt61XN/ BdeyJ/liM/MeN2/crpZbTtTz85aI9onke5i3lnxbd7yFltkWajc4SjDLvXl/J14cYfiZf/Inf6BK 9rGQdo+UJaLnb7WO5K1LEnQzby3/Jk2yWn2oOb5Jk+z5ND4/4RyMhwAS3sbn6r+ZFzub9/y/kye8 gdv2/lvXp1NFcJuZt1y+qeZNcsoeW0tFavcTUQdqibN73EAv7zEMmPsGD/Tt/H2EZghThUtE6y4I qpsi1ZvylLMYs5J8bztedqR9g3kf+/Zy5r07o/BXmBcbmLf63rkT3shJIb2W2jqYt2zKU/42CNnH 8NjxAmGWebPN+03akqPqP8wLXN4F1dfAzjB4FSmacJiqJcr9zFtDvjVXqm5TxYB5mRevkm/hvk+z mTem7tLlb6j4IrVR6b1a8i2/dlXkW2V3JuZlXmBd+dba63hsmIrPfAPmrWjJCc1b8ZLlHUzdHYmZ N+k3zHZ2zAv+LazvM0mYypthVXfBbM+KdQPNWzH5zd4en3mZF9jJv0lhfB75xph3uYR3WvMeZXOe yyvvrGvez6Y7aSTdsEnmpV1guH8rmneJhLeWfBtdpv714hfVbnBCAvOek1wJLzCnfB/WJvdMeF9r 3iHyXcu8MWUFImdWLKfd42qyenhh491ty7zAWP+mrk2+vH+/P9tQTjmxuaJ8m16dzvJdwrxJ1fTu /NKuEsEo+YYb5PG2BTCBfPOXiN4FgvnNm/e3Olyabv6d2bx9KtgupyT1eYFGcexTz2LpD9JpS0RD j+DFuzx1U1viop4eF6WPfCc0b7Zwa3XppdLeb/XPA681b//kN3uJ6PmUy/3bOdeb07xHm/qGM5v3 U+/h7ai96nlm+UY+WtAumHeJ5Pfxzg1WSs0PoX10kJ32dp4F106+k2i3SpJbq0sv7d8tTxMYFcoG vvktrMObF047mzf1L/ZffN1IvmPN21S42V16S/mKzGDeJeSbqoOMGDtnzht/LmMbvO4CrkmcK4B4 tAAmTCKmilTZr0cfT2HImpr5zXsM2m1jxSQXAPPuJ9/ybSgCZ9HfvPFGm6rll5Av4QJY3byT+LdW lb3Lsxi1idMS5l3Iv4QLYCfzjpVvrZh/F5aHmDdSvvPoY1r5SnIB7Greo/uao0aneT6LgVUDFjJv hnybzsMhXABvMO+Q5LdRnnXW7pAFs48XcUKbxFyRpgtPCBfA28zbOflteo6fq70op0p759RK8IBb 7bcgyQXwZvN2S3577iTcM5j/nFTgHKeVy83R1t++mHABMO8Q+XZow86x/TLtDeyKOX9vrF6yh3AB MO9A/3Zrw26hPibt3VW7jz9CuACYd2P5hpXX9KQe094VzVvlpzgXAPM29e/YPWBj3rE2ssBj2ruK ep5e7IZaLyBfNzgA5q0u3xmKnjSqf5T0p+/S3g3M+9h09tsHwLx95DtPrc9G9Y+qpL1LmPdRu4/n Qr4AmLeif2O0m/2Z/m1Y3b+Rae+65o3pEswLgHkryjes1Pio3i4sZ7RhXf/+/OnlSvKlrsxlXgDM OyRKV1l7MrYNW48/r3JZmRcA8+4RpbtF5qb1B99wWSOvTszbB3c0AObtFqIfzdUuODetP7hZ2lsy OZl5ATDvPOaNmQE7uXkr+nfs6uaYk8q4NOGmYF4AzNs/4Y2J0o3ic/U2zPbvDKubA6eQLV/aBcC8 s5k3MlC3CNHtGjDJv8NXN3+iOa6mrEcu6U39WQBg3g7m7fw2sHUDxsj3Tqzfv2oH15dvvGrPn4+8 Oo+PH7QLgHkHmjc+MVyuASO1+3h45fJNte0RXarv8tieVP5lXgDMO4N5k3LewklNPRsw0laXh1ci 3wzbJjk3z6S0C4B5h5s3Pj1MdUqAsQ0Y0yZXBYwyC8pHOjT183c+Hb4vKAAwb/UZVhXNmyepno8i MfItOYta5z5PLQwAeLl5j7JJVkmxuoV5CxPJjNYIJOZJ5s1urirXOsm5avICYN5FzZvRgB3I0G7g QsdsS5L9fFL9isfkuasUIwbAvBvs23zew6qPdpMasG4inLr1RMbb3oHCzeoYsxwJAOxq3sDr2pgf mbkBG236dDfJudy50/QN8gXAvP3kW+XDCzVgfPGIfx30s8IodcbazM4lXwDM21O+Y9eeTGvey/9N Mu/Mwo1f0+QeB8C8jeQ7au3J/Ob98yuX+0nGO3e2xFbmC4B5J/Tvrg2YZ97jr8nYsaub57voH/IF wLwT+nf7BoxfFnQ2758/u9Br3Pi0l3wBMK8G7Gzeu1e9/xxzeAuQFZ61og6VfAEQh9brL9/ALhzf ZcWUvb+WTguAO7ReFfOG94H8+yvfs3lXbHzyBcAdWm82+V555y/tLj657pO90aWuC4B5tV4t+d7P Vf79zKvMS74AuEPrNZVvzEqr7+jiwrXMS74AuEPrjTNR2urmt6W95AuAO7Re9ezvzr/h4//uPsmK fAFwx2YNOIdwc1TyQvOSLwDmRRXhZgy6vjbtJV8AzIs+wj3/qtemveQLgHmR6txav3PptLewNcgX APMuEu17FGionuQGnPVa85IvAOZdTrjVFVy9ctDdj28z5ky+AJj3zdotkW+jUn2B33M55vxC85Iv AOad3LklH+uQ5CaJaQP5Vn9EIV8AmEe7FT/fsx59pHxXNy/5AsBm5q31I92EK+0lXwDYXrvhH+zv 3Egxrb7CqNH4PPkCwBLaDfz4qJAe8xeXTnurNyn5AsBA815G4xgF3KW9c4pJ2ku+AHrmdO22g9jG vI9DxOevz9OqkfqQ9pIvgJ7O5d9H7QYi/P2C2SXlu2La28iP5AugtXP59868Ac8Gpw0vZt6zfF9u XvIFUFG72Z95oXkvQ/FLzEu+5AugXLt1P7xmazws7Yk3b8nvmdZK/8r38/pXveQLoIN215Xvp4xI Y4YT3tUnWf35+XUfqPp0MIEFQIxGO/zUbD7Nk2+2eU8Z8armfXwem/DBrIMWyRdAhkAjF6W2Fsdn KNlPHTGzmic3b1Z532Wm5PXcipN8AcRIJMZBJeKY3KeFKX9gGe/lV2bLCvMaaq358H2ESL4AkrQb DlCR467r+rRwrOBqWOBzN/68unlbl0dc17zkCyDevOFkrad5F2q6/07yDbwU/nPHyF/tLmreduUR yRfAe8x7GTd+vnJEz85d1Ke58n2cC/253LF5zglIqebNeFZ5g3nJF0CheX+GT2N+w6sacIMFWRkT zGqVR9zVvOQLIN68d9pl3oBK1hp0zVZSi/KIG5uXfAEwb2v5LjHRqMRKgTf7YenM02fGylfYAZj3 MYqGJ0Ex751YVyw2kWfex5nws/WZIRKMb1hbowNvk294dtDdTCHNeCy1oUS2kgLaDW4YMlfaO1v6 qS4Y8GbzBgaZbyKqyLBV8pJh3sADW3AgZQrzDpevupzA603xSdrDSkDYsSdUM2/4A+8ccA5rN/sz AF5iXtGAeaub9zLT29W86nICEAcQo6Q888aUWfwmDbwWO3qseV9SlxNA0q1t7Ku6y5i3tXlTNT1Q vkvX5QTQVL7me7QW2RvMe7PgKLYXdTZyh+Hux43jAq973H3Aa/2riV5r3iNrJ40++ljF0fHmlfYC /Ot+Z94k895v/T24Ow00clKNklRxAwD2Nu/P7isxW58dk80Uirk6dRNh5gUA5s044HBt4oB5Zxs/ qXt1qpg3b99sAMC65s2Qb/Sv/d4t433P1XlstEf/Mi8AMG9JecTWO2ZEnmnHcr1RLca8APAq+WYU 6s0uj9hnx6p5rk6SeU1vBgDmjRFr6nq0sfKd07xHaKEW8wLAW8x7Z8byrVe6bdc8w9UpGXCmXQB4 j3ljzFi4Bvwl8o1pGQkvALzKvOdj7ubEIcnvJGnvH0uebR0JAK82b38Vdv6LA837p0Yj941kXgDY 27yREqzux57J75ALpC4nADDv+Zjj3dfIj++Rr7qcAMC8n9Ha7Zn8jrpG6nICAPP+e8zxsus/82qz a8S5AMC8SZrrMxWqqXz7byMZ6V+3DwC8wbw/hYgmMW9r/674gAQA2CCkn+v/zaPdpvJlXgBg3hm0 O6F5G/mXeQGAfAe6LP6YB5YZIl8AwLoh/aywmGMeW123un+ZFwCYd5R2FzJvRfkyLwAw7yjtRh72 JOY9Km24McPaIgDA3uYNq2oh89ZKfpkXAJh3lHYfD3s27VZJfjkXAJh3lHYXNW+t5BcAwLydtbu0 eY++dQYBAMxbrt3wYa+iM/IFAOZdRbvhI1/IZXnJr/oFAMC8/bW7h3lTk181+wCAeUdpdyfzxshX nXoAYN6x2j1uVtks/do0Ursx6bCODQDMW1e7Gf5aRb4BpUZcTfIFAPLtqt3tLk2ySckXAJiXdsvN 2+GnAAAbm5d2MwQaKJpw/hb5AgDzVtfu9tN6/zypz4mfy/fz38wLAMxbUbtvWFZz1u7dxbo0L/kC APNW0e57lrX+mPd8vc7/Le0FAOZtqt3szyxn3svrxbwAwLzdtFv3w8wLANjMvJ21u4d87w4+8JKX eQGAeY/aU6o6/BTzAgDWNW8j7d4d7U7LWi+PPOBZ5gUA5q2+bjd8tPsta7088XAK/Ef70C4AvMu8 rbUbk/rtlPaeB5k3fuQAAOYdpd0jcdB1vw0l/nvwn6Q9rGgXAF4l37p7Mkea9zjtrxj+DTuZ93Tu ahUBwIvMW70UQrx5785im4W96vMCAPO21m62ebfJec8+3X7zLgBg3oHaPdJHm4+Ld75bbeO8/YbV AMC8A7V75C5r/fN0tixgxLkA8Gbzti5zH7OTxquWtXIuALzZvK21y7wAgF3NW5jtfluWOjrvKRGW L+0CAPajm3aPv8ZXLWsFANDup8NftKwVAEC73bR79qllrQAA2u0vX0tsAACLkmSuUdqN968LCgBY y7lLWIxzAQCbOZfRAABopN3szwAAgCTt1v0wAAAoNyn5AgBQbt4OPwUAAO0+Vh84/chWhW4BABho 3scSRfuVmAcAYLh278x7/i75AgCQbd5zVsu8AACMMu8/X2ReAAA6mPenxDzzAgDQzrx/q5Z5AQBg XgAANjHv5wbmBQCginzjzUu7AABUN+/p8xJeAACqyTdyMw3aBQCg3Lx3L3PP5lWrCACASvJVnxcA gN7yvVNqzGcAAECefMP/aC4AAPr4VxMBANDHv5oFAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABgM/4vLJHkAgplbmRzdHJl YW0KZW5kb2JqCjk4IDAgb2JqCjU0CmVuZG9iago5OSAwIG9iagoxNDczNgplbmRvYmoKMTAwIDAg b2JqClsvSUNDQmFzZWQgMTAxIDAgUl0KZW5kb2JqCjEwMSAwIG9iago8PAovTGVuZ3RoIDEwMiAw IFIKL04gMwovQWx0ZXJuYXRlIC9EZXZpY2VSR0IKL0ZpbHRlciAvRmxhdGVEZWNvZGUKPj4Kc3Ry ZWFtCnjafZJPSBRRHMe/syVCrAVlJlLwTrYHVwbtYB2M3fVvyrasa6YIss6+2R2dnZ3ezG4lHkKI LkHWMbpY0Uk6hgcPHQIPEYJiXSLoKBkEgpeQ7Tczu+6I2oM37zO//7/fe0BdKG2aeoABecMWyf4o uzs+weo3UIcGBEErrVhmJJEYdplscWTtfYXknJvh4/X/XQ2CEgISVYDGrMfXHJ72eMDh+7ZpE086 rOTSGWKTuE2kkjHiV8Rnsz6e9nGGWwrxMvFNxRQUJ5AiHigpWSfmDrFsZDSD5JeJuzKWkicm38BT ZxZemfYQ0H0FOPW5JpuwgOV3wKXWmizUDFwcA1Y6a7LdpDsfqWndUjs7XJEUjAJ1P8rl3Vag/gWw /7xc/vu6XN5/Qzm+Ax91pShKlRlJ0hfA68Ndjf3c4EJTmHNfCVFQNZ37Rnq82uvXi0f1Jat0Ensz cVcXsET3MHYGGHoMvPwJXH0PXPgAJBqA1HUEHqG6bf7AzRMrmA+Fls3ZrEOWO1jYOTpZhF4IZ7FC 3izaXLBBQ2lvY2ldZ66pxQS3uCjxTDvyerHa7znaQW6MjtBJ8wqo3OqtsDSTSffQ3aCdeCPDe3qd d0G8qGp9g86F0P6kir5Rj6Xzmj2Y8jjQbejx4QrDKMRvezGxY9rRZDW+VRrprcpn0rcSdLaQ/MZs YcixaSLf0FwuNeaxlJrLxeIVXsU4dHBoMOhrgCGJfkQRhgmBAlTSaGShkZS7NoLYwuyxljoSPmak 3yafbdfnHork7XjdQTSOhbaDCEz+Jv+Wt+Ql+a38a7GlGKppFsSUpqw/+0NxnczVuBVtpSYvvkJ5 I6TVkSVp/qAny1eprzrVWGypRXJy8CfxPV+X3JcpjGk30qybqeTqLPpGfNlOmh7Zrs2vNtdybZ1e mdwMrs0fmlXhSFf8oKvD/zU7vz//B82wAWgKZW5kc3RyZWFtCmVuZG9iagoxMDIgMCBvYmoKNzA2 CmVuZG9iago5NCAwIG9iaiA8PAovRCBbOTIgMCBSIC9YWVogNTQgNzQyLjQ1MSBudWxsXQo+PiBl bmRvYmoKMTQgMCBvYmogPDwKL0QgWzkyIDAgUiAvWFlaIDU0IDcxNy41NDQgbnVsbF0KPj4gZW5k b2JqCjE4IDAgb2JqIDw8Ci9EIFs5MiAwIFIgL1hZWiA1NCA0NzMuOTg0IG51bGxdCj4+IGVuZG9i ago5NSAwIG9iaiA8PAovRCBbOTIgMCBSIC9YWVogMjA0LjQwOSAyMjEuNjE1IG51bGxdCj4+IGVu ZG9iago5MSAwIG9iaiA8PAovRm9udCA8PCAvRjE1IDYzIDAgUiAvRjM3IDgyIDAgUiA+PgovWE9i amVjdCA8PCAvSW0xIDkwIDAgUiA+PgovUHJvY1NldCBbIC9QREYgL1RleHQgXQo+PiBlbmRvYmoK MTA1IDAgb2JqIDw8Ci9MZW5ndGggMjYwMyAgICAgIAovRmlsdGVyIC9GbGF0ZURlY29kZQo+Pgpz dHJlYW0KeNqtWUlz3LYSvutXTL0TVeWZcF+OduS4nHKe9WTdbB9gEtIg4jImSMvOr09vwJAS/SqH XDREo9Fo9PKhGwp397tw9+bi1e3FL79F2S4KD1VYRbvbu12W7oo0P2RRvrttdh+Dt/1lXAaTHns9 7a9GdTdd7qs4qYIGv/fTaE5qOpr9OLTtfjy1e2s6XDG3ajJDvw+jy31Z5FVwpWsNM0Xw5XIPf/V4 uU+SNIjDsLr8fPv7RSg6wZ99Uh2qJGIF6qE7qVE3sCpPgmnA3zSYjpoJ11c365nmMgpgLkKdO9ML 2+NRw5JRWHlxGpyAV9Wo1APqrCeet8dhbhtmEW1F9jicTkyQ6UFE9sN0uNyncRT8d5i020ZNzKVx kzI4Mr01/QN/zVYEKzQBnjxKDlla8ckb8ymMEj1qdgFwVnEwqr4ZOvyGTcnQZG5UsySjItO97vWo pkGGZBrg75RhUfjLM+Osl3J7bS2PmcPZCggLvw7jC3BeCLbrwYCNMA7Mp5DrG/4ZjEzVwzhqjoet c4ruE655JD/AifdJGZOlLNg1K6vgZWsH3NbphPMntqt3HtLQ/+AmHqjTqTXa4iAiDYnYtkx4MH1j mTbcMalRk+IvsAdP1QMbDSJcdn0aNSLjU5iFN9cw+Q6+IqbZ2XmednaawAE2DHH19j2eMEmCK5T+ Eld6ytsP/HF6tjUQGw2hkvYYlThE52FyfXy7vzoYPd359PwM6h1o7yiHHMt3EMyHsKp8su+TNF/6 2vT3TLu5foeqpJmYH0jvXt3wB24+2okHBoPCTEZNZHgUp/vGyxlm4YPTsrwOgk7dU85a2qIU4wOT 3+sKFSKLvJFtRPj9qJoZXPqDhYG39nS+vTvg0sIWAr6edAMxlSd5cEvSqwKcaziSWkcwnXxhysDY ocr47TLLIYR48g5TDD90ZyaxFYz4aPDhj4YD9D4cce7ILrjJ0e+B9hKZssEscxSZ8IsBVZVgSzhh A2ZKo4TMtBFHILfnQKBQOVKaioGZPvgkdTi8hm3mEiPArJJ1nWARsPyDWNsItFICjSD/9e3F14sI tA930a7IDlmyy8r0UKbxru4uPn4Odw1MwfEOcPLdIzF2u+QQFwl8tbsPF//busKK8lCGLCpPE96w QzXTsKSwScPKmRzDBskW4QPpCBJIiHjI5maS4o9qS/s4Kw9VXPwr+sd5fIjX6jfD/KWl8FqeQX+d MWiQxGpXQZRjaIDTrRD4EkKWTn0XH3cyRe7FqScIXDACk1xPGjir4rAE5SjcMndB92CleTIcTxAN USkZAB+QGNZCuGAARXj5A88PnlL80w90ozayElF07huKS8cEx5m0amRdv7gqhvGBiegmg3Ep2Atr CCFgKgKN+Qvu9RHvkxTql5dwZR95FzgcWACy7k9d+2Ns5BWlItmURYeg1kxaYUAJiW4Z+L0/24PC zZr7o9zjSzbGAODoF+bnUwFRNRC4BlCLL3MkUXLCwuPA7GdpqNnZg+rBKauFZ4VxQPBAwyYhOCSI Eo1GXe83zdABDDSEE1gsFAXADKwaZkAZKpuKUiAI5yS2mAwFT8NkI9N0Q9fqi2nNJLGBjHaC66M7 Vz5AajhO6rkjJOMpUj3Og98uyzSYR6nxgHvU34wlJMNd0HP4y57z0kqSJptsnPTRYKmQRimoW7cz hijCLmFlAViJhYCYAZnoNsCPVo33jhd1rVUrQ/Jy4WPXMvXRTEdeCT7JAjXiDUqnbJgBKmDVaaho ZSeGIviwPgyQDQeFG3ydDVcKhHGRlE24CEv5zeP6jIrTRA4fpzE6A/3zl36B1WokJTnBETJizfTL qkrCRRCzUBbkNfOQwvhBGUMlgqzmAhM/4CLXA5a8LGAblHBmhHoa8vQcMMsNWgOy7zSD2/8rdl77 ojxJIkahklEIhnyrRZI9SfjUcS942kEIcar1mgjrI+FTLeIxfmGhYPnzXNK8Z4JUCzKt5Nee2BA1 tgMpX7tOwfDptfvz0gcvZCrbUynV8+UdGEOFwfsMWN5iGaCZKg1AAUU1YLxzHE6oL622/M0BjDI9 +2mkmvQ7s+SIJhohUXonoNyN3MggfqAjTNuM5GKY+2bUk+1X1orPtZXdimSyTgH4PEu/NowTUwjD cweLQLjmVsUhDZIITTemYBneTtfxtVwywMOVKsxcE3CvmJ2cP+Z2MmLdNYPPEWRj2X844Xnlj+GV /RQlacMZ3/+HeRoz4q019IctQ1BFn2G/jJBieXDGRhyRRTLXVQFhE2gxdDIoPSbmYVGQdpYADqG/ o6ujccKUcJ57X6Qv02whplYnjKa1QhbuPC6pUWeIPs100wPQdq5OzRh3F2eXusTlJrTXvsSwPCa7 ulcEYliXFNhywn1IxoM2/W4+i1rYLhdVqdU3Ivr5vbKpASYMd0IwwINylwADMsXiNkTxDMWJPEf8 pDpRTaOpQA2lGnRxU1VP0WvNZbVw8QUBFANVVJTNuq+FgOfEX/0dQlZWTdzg0XT/RIB3szBI6Rye ORT26VyxcQ0brhttJJxa1W8XYov25QiFIXcglG7YIUP7r+4JwKiLOUoT40IIaJAyw9hYx6D6B7uW caNFvJXFN+fFHyZ5drDrDkg2Sp4Ce+qh6ucNEdQviTwmQYELplkYEEmmO7W+HuKbF6jck+OXPGmV gtIyP3FSxXkh2dkN4w8ej9A8AHKQyIJKrLxw1Ydxu6oazXQWNzCb30wwzRrORVK0f34FZb4tRXPE 3j5F8ObAlFs3JRFqp32trNB833ya8G733SlDDDBgdgovpSH89gP/ep/jU0zXwdn+8g1uLJ6Lz557 3losZHZQn2C5maagLxWAm3eP4pxdtjUwrNvBMobwU1ni3iGTPF4897xhgkt4KOncexo9QuKcW42o IcI7+YrP7keyhAv6kxAtWZfJyLKEs0TgLPZwlmzDmQDSxtn191NLusSlKwXKYg0nOEPlOPxKZTMi nnOUATcWv+w1HD3xGq5S7eB4ZYvV89ALnno8Gv/oCgy1POmWy47kiQpUmJDiBAhbLysUVjn5GH56 /UjvTvC5eoHLg/fPG0qiU57Pfe1iMKekF1kiu4EyyFoeAJaR/8lJ7FigTpofdnrMh68zd20Ymlkc vJ2Yx4gEKD2pO5ORxfcnUdJlUE5PohvHXcI4psfx/LgrsChPEPw2xOiCZLzE6vMVliQeWF3ULvHy HLTEgPfKC88y6jtZkUhWAw/08fUC1f1iYx2+E7o1/6T6j/F+PJclMT2y0cMwzizaGBg5QHRVcCW1 dBUoXvkrNIOT8pgKlFdmYo4bKan5iePXV+iVG671kOgFUdcFBKlfVupZnuLH+coVx+Xz+50EIMk9 8v20L/Be8F3t4gXQZYcRMCP4y4JbhJHh2cOhCFLP/p8TJ8khcdfALaaA/NtIHrfp7R5XtrBBFJVF FLz+fgIHijt/n3vxdpzKkjiMQuBNS+hnPlKhzhUU8GSfVwq8vr34GyMfInQKZW5kc3RyZWFtCmVu ZG9iagoxMDQgMCBvYmogPDwKL1R5cGUgL1BhZ2UKL0NvbnRlbnRzIDEwNSAwIFIKL1Jlc291cmNl cyAxMDMgMCBSCi9NZWRpYUJveCBbMCAwIDYxMiA3OTJdCi9QYXJlbnQgNjQgMCBSCj4+IGVuZG9i agoxMDYgMCBvYmogPDwKL0QgWzEwNCAwIFIgL1hZWiA1NCA3NDIuNDUxIG51bGxdCj4+IGVuZG9i agoxMDMgMCBvYmogPDwKL0ZvbnQgPDwgL0YxNSA2MyAwIFIgPj4KL1Byb2NTZXQgWyAvUERGIC9U ZXh0IF0KPj4gZW5kb2JqCjExMCAwIG9iaiA8PAovTGVuZ3RoIDIzMTkgICAgICAKL0ZpbHRlciAv RmxhdGVEZWNvZGUKPj4Kc3RyZWFtCnjajVhLk+O2Eb7vr9DFVVRqKZMUn7mt5+Gs7djjWVUlVeM5 cChIQpYkZBCc2cmvd79AUbuaVC4i0Gg0uhv9+KBosV9Eix/f/bB59/1tnC3iaFVFVbzY7BZZuijS fJXF+WKzXTwEH/tlUgZO2V658NrWO7cMq2RdBVsch87qY+0OOrSmbUN7bMNBd7hjbGunTR9G8TIs i7wKrlWjYKUInpYh/Cq7DNfrNEiiqFo+bn56F4lO8BOuq1W1jlmBzlgFrEUVWFW3enC6gWkZBUOj +tpq8x6mVQyCvmM2s+N1d5B9e9UrWzu1ZfqxblDBz/ij3MDEJ5y9Mr9ihgOv9Ab0LYPtMg4UU2qv 0FaBNr2X6wxT+VwgWEOWGica1v32K82sCtF2NDler7K0EpNr3et+jzxpULJdKdsFX9mdzgwpxBAg inJpMPZ6Z2yn21dZGAa9Z2Vpxt+ZCSja8NfbrITLwJnWn173X+lhmdu41TLM8jzYALPa4bVdsI12 pUly8o5MITz0M5kyIAXcxQuN6Qe9hQt8QkuQ0tZ2j+rguO7MCDfT40bH+9BPuLStnYhgnWmNDUHi yUZQu4gjVHsQ3Z6XWR7U7ciqJHAhEh44kfj1aj/rAdx3wdKXg0JPxUkwuHH7qnvQc88Edh0M7pI7 HMSBs/UfUZw3ssHwl24JV2V+ID2eKXKFgz+gYJhlwX+M1c5HMpApZPC8mXRQwnBw4YJhUt22TDi7 eVwYRNLxyJc8UKzMtk62zMIAvRHnkMP5Any1iipxyYZTI7sQukDk0IWBNaNkawbiYbY/+IlwXOPG DyjiRyY8jbp1MvQOgPH93S8iuwHj4f4tXMKWzS9ztmEut1Oc+nWvh07UGthy1WjwYer10j2LeACB H1E0Z3LozZ5HwvVKK7ebSuTjBQeVzPlJ9w2qkhaiepoHemAC5R3MP97xHL3ElgDxaI1j/zemxXqT ceXCNcj8sTtiNeaNLDCHoNnKWUZEsx+A0Or+M5PaGl39SiFnRbA7UIUXMRIYTnGn0HXLMvZQxYQF nPWmc6C1kKfXaw5X6AkHBZpZpjWmO1oFtYt0BAJYiho9a6nIcJ+8MN07jPPW/OtuWa6DD78ygWxe Y2VzTBj72RFSYdx0yAN3N308NI9vh/MHrARRQHaP1PWeOFQsL6A9+KWrxMGxtnWnwOKB5xTxOAAV MLj2o8X4QsofURYNo29ExCyb7tD8sx4mp0CL49HOmo5Hp1aGs4FSAOulbchz71HdJNjoTk2yS3aq 1cDmW9+ZNRgkb97mLz/cgweTPFCddhKeMOvVCw4KTNzylLiwMqg/R8VBD8sXXAmOiJmVshW+5mlQ diqCWPgPSls5Fty4Vo0Tzp6/nEuJj1VlsTPWciokggIY07AsisGEQpZxDzRIioDvb9fFIk5XEM8J AiWo9mmxqhKBKRk4LU6y4J8ki/pmJv00C9TzMk+wodTgVKeYeI9uBsUm2fGqyjIvO0lXReZlr2KR fmW6joyC/R+mtB5YxjmQQxnRKqsylnE/VYuqCDaYGtBQFU8/6f+qv0MDKaTjVIVUgmp+Yb8xoUO1 ISHrvRLeg2qPssvwd6eoTM7l2Pn5Ds+W3VRI55wANDHCX/BMYz9DjKbx+sL+Sz13AEvgilEFY3kw SwEU7vsbTzkBUT3VGLtVW8AC6ToJrtBIShSrGFsA+ChTTJh1JNAnqcoA24lXLJkUo6FXpaTaw2c7 HqDJxO0rGFVApFCOwfdnLmZOnZM7BWj4lccj3sAlHzyNGP2AuDtVD1xQcEZ+hq+vt5LRSLpYwHDB M0hpt1rJTvIurZywMgry3kUkmCXBzdmqeBK9+spiDhRuuFF9EaUP5viVLJ4yeIYBPjd41JjBXXIA 9DtphVpQP4DUF03biuyEWxn7+qo/h70EZEt8+xB9N9oTACbEp30S1kwcIAJayevd2IKJLU/ipAyf tBPQvd1iK+OV4+kZBLNW1QLvj+04nMneQe28dM3aSdukrIPeNjh+KmEnFX2x8/VU7E69jT0J/FAq s3ovQl40QUDqo6GUVmyTA+bE/8RzSbUObjb/xkFKbesGzP/iQRNdAK5sMH9s3Q+dlm6OG6+mlsTB wdUeV3xRxjFnEGkjDR9nBHjgi9jPk7xCZwARCbWI+BbN0QE9K/nwMZyDtbf7nJSjkLUcHqlulMEt GjlFC5YtiZZhDshRTwIkMNpKqI6dJBkzynXEqFrTjpQF8eleEfKTKyibuN/E/mpjhjQA+qWJyeoJ ThDvcHqLXAivf1AeEjoaWcrqjU6VJqsCWyJ3qkQ61d1yDa8Hn3O/j/B0d0uorK//R6/69ZtalEpj TktUbIBmlUKzusU2ZmR9VomA6wh+qQkUwIS3Qkk2o/Xwml2VlvMqMMFbxUuz15bFYkvEy8VyUrDA CjYw687r9iQQ+XAG7VmJS13sYKwDtcQU9iKMZoi/nJ4F/K7pjiNBC2pgZRV8OtBTx1GQsKTiLUnw WCdEimOqJWh6z19C+q8e4h+U0w3je1BgqzzUPxN39hS5/BdAjQpBunGPH1sCCxCS7QthWzpzYJYj tVhB/Ir5BCqkc0chK5sn6YwU7HU8osuBFUI+xpHiQKa6hXSsW3RbqNVBcygpuXsmTygRxuR8Lkhb AahI9cdeTikCNuUEbOCm8nUOGsENHeTfJUALV+Pp/7MJ5CIQ05DRGpo7F3KgUPiPfXOioBVX17de I4nJqpCuCtK3IKXGfyIobEQ0xynCISo6FUfKcJLJHikouSp5QCK0+nOs2wn5zSyWPO7/hpv7MBaF Zs9mii+Y+8+s2Zf51576dvv0YD9xFsjJROn1+E+Cmuq9O3/yX05jYOC/DzOfxnjowCvH1jh3/v7P gluNjzZmSJiE7rzUsGdFAIoXF4HCF20YDN/kLLBJUBcTAiZskgS/9YrJDf8fl0zPIvpvCgmSZ4VP GBhAcPAaoN3JN6aXf0QK+VcHGFP+iBNggZyA2oIal6tWln3HHYPDCQDGPb9uzv7ajbNyFSWF4AeM YPkH+T1vVvI+r9sVdpKyiIObL0dtleCUn0YyHP85TmVLEsUR8KYlIPMHesFysQae/PFMgZvNu78A xOgMqwplbmRzdHJlYW0KZW5kb2JqCjEwOSAwIG9iaiA8PAovVHlwZSAvUGFnZQovQ29udGVudHMg MTEwIDAgUgovUmVzb3VyY2VzIDEwOCAwIFIKL01lZGlhQm94IFswIDAgNjEyIDc5Ml0KL1BhcmVu dCA2NCAwIFIKL0Fubm90cyBbIDEwNyAwIFIgXQo+PiBlbmRvYmoKMTA3IDAgb2JqIDw8Ci9UeXBl IC9Bbm5vdAovQm9yZGVyWzAgMCAxXS9IL0kvQ1sxIDAgMF0KL1JlY3QgWzUzNC4yODQgMjIxLjA1 OCA1NDEuNzMxIDIzMy45NTldCi9TdWJ0eXBlIC9MaW5rCi9BIDw8IC9TIC9Hb1RvIC9EIChmaWd1 cmUuMikgPj4KPj4gZW5kb2JqCjExMSAwIG9iaiA8PAovRCBbMTA5IDAgUiAvWFlaIDU0IDc0Mi40 NTEgbnVsbF0KPj4gZW5kb2JqCjIyIDAgb2JqIDw8Ci9EIFsxMDkgMCBSIC9YWVogNTQgNTE0LjAw NiBudWxsXQo+PiBlbmRvYmoKMjYgMCBvYmogPDwKL0QgWzEwOSAwIFIgL1hZWiA1NCA0ODUuMjcx IG51bGxdCj4+IGVuZG9iagozMCAwIG9iaiA8PAovRCBbMTA5IDAgUiAvWFlaIDU0IDMxMy41MiBu dWxsXQo+PiBlbmRvYmoKMTA4IDAgb2JqIDw8Ci9Gb250IDw8IC9GMTUgNjMgMCBSIC9GMzcgODIg MCBSID4+Ci9Qcm9jU2V0IFsgL1BERiAvVGV4dCBdCj4+IGVuZG9iagoxMjEgMCBvYmogPDwKL0xl bmd0aCAyMDgzICAgICAgCi9GaWx0ZXIgL0ZsYXRlRGVjb2RlCj4+CnN0cmVhbQp42o1Y3Y/jNg5/ n7/CLwUcYO2V/BHbfWu73esWi3auF+AOaPvgSZSJbmwr9cfOzf31xy85duAWhwHGEklRJEX9SEUF z4EK/vbw7eHh/UedB1rFlap0cDgHeRYU2T7O9T44nIJfw0/dLinD0fSdGaMPfX0ed1GVpFV4wnE0 9vZajxcb9a5pov7aRINtccXU1KN1XaT0LiqLfRV+MEcDnCJ82kXw3/S7KE2zMFGq2v1++PFBiU3w L0qruEo1G1B3J5BUSVipr3hwdrhW6XC4uH40w8hktINHvZtG2z3HuyiDHQ4XOzC9NXU3vMNx6ZUk 4XgxrO3ZfkHzTMfT0V3B0DJ0jXt+25VpKAtnM9xZ9t3pELaWPV5t0/DoUmMcvuA/c29hY7pnGIPf 6K5O4zyr2F3Sutdhxp+Lu6LivQrJXqA0Zhh49GpJHYzqjr/2ZOqGh4vYwEx2BjUSGya3Zrw48vIk bmbk5r4MXy+mN7XsZEX/L4+fefCIXjnLuRGNLloRWOY3lavH5BE+estRMQS3g6hzVJM9+w/fq4QU hhLSJKeQFreQAq9mhsSTSOx5L+rka/6YKDIwHB2vyXmKEcZMyRKfKUDszTA146wPN3wV1niphXEy w9WOZmUahnbDWTQTNugcBjJLQ4dJM9rW/ncX6dCcmA3R4sHtkGAyHFHzBRYYFG4NhizLJHGzOa1A LTppR7T2jVkUTfjywYEEOUiWjDzgyypbEOWVjrIfDK8Yceda7OYv6L2S8d5w15l4y+1vYJsLH4UO MZ3Ifxi3tTcSJgII6BxlQyquAWuw3QuP+GRUyMHXN5Gj8QjFc06ghQAAF50fu/VCW2Th4MQqN9FR ULRpGVCeL3c67u2gbYBvxJ9j4yBeiwjkHADKNZ1w3LTmuFEiAhEvyOKaaj5Jui8kvISxwicnSM3J CeNbIGEyBxInJ/ub0ilc4vlOApEuMtrDO6wxjjh074V7EVXiPa4XExpwnoHjWI+QBVspj1umKeYG I70hIEfKmb+sHzh3JxSv6sH3hwcNAxXoQBdlnGU6yFQZV4UOju3DHw8qzvI8L0hkOSamXymE95/a JPjgHv4Of16/F4m89mihfqNA6lLFqUqDtMxhN3H2o32eKGzgVvI1okkefvfh49dMuWCYcXCyw1h3 R3GbcawfpoG5dFDTRo30AWOoWgZnLpqRVlWc7osA1sVaZWzWAeuWGynhKhV+f/gXWlTp8J8XytxK +5vM+Q9zkGFhqA29PTKxbpzn86FVc0kBSUoKoEwD4QHKC6X2m4A/eR7+2xxHO6M30M9Td8QuAe5k pvKb7pFsxqSK9B5agf06tdjGfTbbtfdrgeZLXc52AeXo2us0km1A5cIPZFPPqEfLbA83LU/L22GC dMrcZQ1YbgZnzBQu2x6UUUTCDrTtc10sEn9w0dZNOplGoobrioxuL3yo8SAfXog7MvncuxZHqZcb 3NRTzsGYAKkgIId1bzyBQgZAQ/0aS3XSFBjmS6MBDIAeRgw4Seaxwmz2t/DuFHLRCx+UYj4bYHkj 5RjKcLMZmi3PKt4IvrM8zcB0rBtgPnVh7AHQ+ZRx2UXWE8gUqzKQpze5JwbCUfRCwXzHI+4/ccCf BWLDzNfeCu4L21V3dmgRs6sk/IGxFBc3g9iPeLjV9z0NpudTpk5SSaORVNUcW6U4tkjzqU+Chgds DHIlvECrsXdC0hxLXOG8ElG7ygDkWDGCC9tqkTRAQMHzJTU8XbbjyrfFG0WRY/4XBYC5VKsQ/SYR X78sCAjff0yLQOu4yvMEwRk2yhJ4vMhOeQz3V2toz36ZO6oiB1is4BI9NYan/4BGhpWtkR6UJSrO K1F24CxOGM32d2hWSLNV4IuCogdZPmNoIaUTuc5r4QMv/PLR68cq0dunyd/Hpea17KJmlJLBjBG3 JVL+e2vEpusNgnC9o+nJIPZB0y7Yt5GgGV+YJRLm/ghhwEiYy8ZA6KHltj2hbv5ndubpTXw+INAx yuEAfW3/fGNhwMmbL3zAPj5XafhzJ4uPVIDQakNdc1767M39e3JhAvqy4fgMhr5MGyONDB0lZOgw Ol/85XWWIujR5kDTir9rV0DEdvM9sJLjtzDA5IjQJnBn/jLf9z7fM8n37yB1UsBFeJZzkj/u0gR1 AfEF/3G1yMOfv9Csv5j69P9eggw2ODrxBjdAwrWpO+E5efhims3vFlAPzIzuQYYvt07mrfSg/Vj7 VhWVzJHAib9IOLYdfz9zIsrurENQhPMb6YTeLD0Mbzz8aY02A1OxG//8+acB++/Nx8yn7gQnj2kE AbPU3Urvg/P2envF9FyL5sudKkkV5cvMxL2wx25QsIonciSeyHO3HxLonOi5mkGac2xJ5HynD0HE dkuEAq5UqB569h75x2G9Gp+JG54zdM13pyjYfaC09ctcsmA6Ua0APqMPJTvt+cJYW+KbFzpeHlNF BOHaq3f87X3KnPBpRpdA1ArslX8Ge6VsXNyFExg+nDi875tk/yf/lIL10HK1VBC33/OAa3CEc76m Cdb/YaifDf+WkEq1AHZtWxbgh2npywMtkfKQSMElLrkmEvxbBSjp6uaNgpv4lgYGayeTm5O4213O yC4dCw4eYVnLyUZbj1euPwBEeDc6AbvOn85GyTaNaQ11lvL4O9e2mR9GK1gAk+Slm6bSY801f9EZ XKHjNPJiur0cRe3dY4jQMI3hsbx4/cjvk+/EQLGrbmIEyrKAB89/rlCmBNt/nPxrNclkSaIQv3VW qiz8lX7mglNmmeL3+5fq/wC45pBHCmVuZHN0cmVhbQplbmRvYmoKMTIwIDAgb2JqIDw8Ci9UeXBl IC9QYWdlCi9Db250ZW50cyAxMjEgMCBSCi9SZXNvdXJjZXMgMTE5IDAgUgovTWVkaWFCb3ggWzAg MCA2MTIgNzkyXQovUGFyZW50IDEyMyAwIFIKL0Fubm90cyBbIDExNCAwIFIgMTE2IDAgUiBdCj4+ IGVuZG9iagoxMTMgMCBvYmogPDwKL1R5cGUgL1hPYmplY3QKL1N1YnR5cGUgL0Zvcm0KL0Zvcm1U eXBlIDEKL1BURVguRmlsZU5hbWUgKC4vaG9wX1BfMTAucGRmKQovUFRFWC5QYWdlTnVtYmVyIDEK L1BURVguSW5mb0RpY3QgMTI0IDAgUgovQkJveCBbMCAwIDU2MCA0MjBdCi9SZXNvdXJjZXMgPDwK L1Byb2NTZXQgWyAvUERGIC9JbWFnZUIgL0ltYWdlQyAvSW1hZ2VJIF0KL1hPYmplY3QgPDwKL0lt MSAxMjUgMCBSCj4+Pj4KL0xlbmd0aCAxMjYgMCBSCi9GaWx0ZXIgL0ZsYXRlRGVjb2RlCj4+CnN0 cmVhbQp42itUCFQoVNAPSC1KTi0oKU3MUSjKBAqYmhkogKCJEYROzlXQ98w1VHDJB6oPBACUgw3w CmVuZHN0cmVhbQplbmRvYmoKMTI0IDAgb2JqCjw8Ci9DcmVhdGlvbkRhdGUgKEQ6MjAwOTEyMjEx NzE2MTQtMDUnMDAnKQovTW9kRGF0ZSAoRDoyMDA5MTIyMTE3MTYxNC0wNScwMCcpCi9Qcm9kdWNl ciAoTWFjIE9TIFggMTAuNC4xMSBRdWFydHogUERGQ29udGV4dCkKPj4KZW5kb2JqCjEyNSAwIG9i ago8PAovTGVuZ3RoIDEyNyAwIFIKL1R5cGUgL1hPYmplY3QKL1N1YnR5cGUgL0ltYWdlCi9XaWR0 aCA1NjAKL0hlaWdodCA0MjAKL0NvbG9yU3BhY2UgMTI4IDAgUgovSW50ZXJwb2xhdGUgdHJ1ZQov Qml0c1BlckNvbXBvbmVudCA4Ci9GaWx0ZXIgL0ZsYXRlRGVjb2RlCj4+CnN0cmVhbQp42u3djY6j uBIG0H7/l2alHW1vJoAxBv+Vz9Hoaja3Jx0Xpj4cINk2AAAAAAAAAAAAAAAAAAAAAAAAAGAsPx/a /+qWY0z/6ocv5udvmc/csuYFm/hsUInHm82T/AfLJuGLAywo+60JlniG9js1vLWnh5y9mY3reR4V PFvLRH5xUJmPz5tH7w7wrTzKf055RIxGvT8e+/r5w6n++3/t95rEk+wPuTP/bXrF8fkDZ8eT6UcK fnXiCc+GeflS86uaGOmtX9Qgj+4OM6c/H/5kZpVu5VrBPM+ZkAUzNjHSz//M2WVg8Dw63GE/J/k+ m/ZNKf0khz9Z8G9zXvaT+Cj41fmje1KrywfLRlc1j8qmROaIzrZR/oNnGXEWHO9uu1sTLP85rZWI mke32mnB7pOfLM/zaO+tX53fZ16pVY36H1Yp5/GC6VcpYQv++WUqlcXck8l/WfP8KSePWDyPMrv9 kx2/2froeR5dDvNuMuY3q+I8yo+8u+/XNVjxpZP01mt+K3oSr6rsLcT0oOQR8qi4z7wYCmPm0bsF zG81z/Oo4OcLNlC9FfeTetZbCuWX99YxgzwiQCQVv9H98EzH62dJtt7njxoHer3367rnUZfzRw3y 6OH5I3lE1Ei6eyXS2V/ST3J4BdTZWxbb1aVQl6c8ipczW+n1dTn3HyXeqLlbq/zr6zJH90oe5Zzj uDslKl1fl3jyLeP+o/yS3rq+bju/lOJyF95PVHmEdZYBAqBdGyCAPDJAAAAAAAAAAACABZ193u+t OxMB4EkSXd53n3gQAOqtj+QRAJPm0Q8AGR91SIM8WqEyxmVolV7zZUMzFVu9nvI/6+xl8sjOYlwh h5Z5XG0qDps7C+5l8khzM64YQyu7bNVUbJw79jJ5pLkZV7Chpa9ftcleGVeDxY5N1nFK3L3/SOVh v6c4rx1msSOPHJTCvBkkjBbJHV1RHsHIeaQg9XJHV0TlITHn7QKxFzu6osrDUAsfc37ZxY6uqPLQ PYO8Cyd3dEWVh0GSSO7IHV1R5aHx1F0tg4SOrqjyME4AyR25oyuqPDSbn4u8/yZ0dEVUnsEzKFgY yR1dEZXHgmjk6EFXROUxIVtmECYhKg+NMwhdEZUHGYSuqPJQNg8Hn4regtMVUXmQQeiKKg8ySADp iqg8yCB0RZWHBQPI3oCuqPKYh7WnYq8M+mFUuqI8gmZ5NMIiyC42XeuzyeQR8ihMBtnF5BF2FtbM o5FPBtnF5BF2FgLn0UQXJNjF5BF2FoLl0aQXxdnF5NHi+3X+VzmrPCPnUYCrsu1i8kiFf/9++KDK M2weBbszyC4mj1RYHjHhuj7g3al2MXmkwvl5FO8roZk6j9bpe4zTLXXCmvv1j/URU83bsJ/VM+Yu dtZ+E49bH/G82vIIeTRa37v8WvMafxKv6rBdJB6XR8gj5JE8kkfyaLoKyyPk0eB9b5xXJY90xUpF dv8Rk85bedS+UTh/pCvaWcD6aJBXlZM78gh5hDyyizV4VZfvy8kj5BHyyC4mj+SRPAJ5JI9+Hw92 u6g8srNAot3ZxZBHNgrII7uY1meT2VlAHiGPUHnkkV1M67PJ7Cwgj5BHqDzyyC6m9dlkdhaQR8gj VB55ZBcz5WwyOwvII+QRKo88soshj+wscD4PfV4Q8shGUXnkkV1M67PJ7Cwgj7q9sCffu3f5k3cH fvaFofmf43rr22zlkZ0F5NG+zSa67tl3PRf8w5z/HDCP8p9THskjeOtYXR71yqOvxw+f7XAllXjw 8/86e4XpH0i/7MSvOBuFPJJHYH00yzHAV4c/TIH0T+b/85xFTc46LvNlyCM7C8ijiVam6T5f6cH8 hWS6wunfKI/sLCCPJnqRlaLn7NqJy+BIp8b+LTt5ZGcBeTTXLlb2PthbS6HLX30rTeSRnQXenYc+ n2GFPHp4/kgeySOQR/F2scv7jxIXs2VGT/71ddv59RWXr3/bXVAnj0abY5cPqjzyyCGfQ3GbrEGF M5euKo88kkfyyCaTRyCPkEex9+ucN4S/fj5wQ0AeySPSR+86ofURyCOsj+SRyiOP5JFuaZPJI1gn jxiTPJJHsFQeYUm7+H7t/iNmm7ebmYg8UnlFQB6BrqjyII/QFVF55BHoiioPn/PQVERXVHlFwPoI dEWVB3mErojKI49AV1R5kEfoiqg8o81DUxFdUeUVAXkEuqLKgy+dQVdE5emeQb4EDV0RlWeQPNpc z4CuiMozxkyTR+iKqDxVFz7yCF0RladLBpWdD5JH6IqoPK8nUdHzyCN0RZVXeconzFuXxskjdEVU nsvlT4MJI4/QFVF5DjOo8W1B8ghdEZVnO78gQR6hK6LytNzu3T8qQR6hK6Lytvs2wMeZyiN0RVQ+ /PYtuDtVHqErovK8GEATfVqpPEJXjN2L9o+rvDCSRyCPepX0K5hUPvCOM+/XN8gj5NEK9ZRHsQMo wNb8E0ZmIvJIHvlCtIk2a4wA+sygzz/Qcc/SCRsfQlsfBcujABkkj7A+kkcqL4+6B5AYQh7JI5WX RzII5FHjSsojeSSDQB4NUkn3H8mjLhkE8giVl0cWQaArqjxh8kgGoSui8vTKIxmEHU0RVJ4ueSSA QFdUefptdxkEuqLKI4NAV0TlZZAAAl1R5bEIAl0RlY+wsU5uapZBoCuqPNZBoCui8mJIAIGuqPKM EkaArvhuBX7PDrSshspPmkeArlh1+Pu/qDxfBy3qALqiPEIegTySRyqPPAJdsVmrSXxxnsojj0BX VHnkEeiKqDzyCHTFln3mkMojj0Ae9arA2d9V3iSxvUAeNR5+swvt9Dd5BOiK8gh5BPJozFbzddrI +SP+3lg+KQjkkcojj0BXVJCSddblgyovjwBdMZEjT84RHF6Yl75aT+XlEaArJrKjrCCXKyB5FOCg RR1AHs2SR19d6zKPunxuHtZHMNSRnk74eh6ln8r6SB4B1kf5keT8EfII5FGYMsojeQTIo+fDf349 gzwKOU9sL5BHVTvMi5/s7f4jeQTIoxmHr7/JI0BXVHnkEeiKY7aa9hfAq7w8AnTFEYavv8kjQFeU R8gj0JBVQOXlEaArHvYZ54+QRyCPVB55BOiKKk/exvJ5QaArNjr0/f3CCJVHHoE86jj8h983ofLy CNAV5RHyCOSRPFL5ReaJ7QW6YptW0/7bclXe+gjQFVUeeQS6IiovjwBdMV0B79chj0AeDTJ81zNw uLFsL9AV5RHyCOSRPFJ55BHoii1bjeu9kUcgj1QeeQR4v07lkUcgj1augMrLI0BX/Oozvh8WeQTy SOWRR4CuWGmdtX9c5eURII8yo+RJNS4Tp+ONTrwxSXxeEMijRsN/+P1H8kgeAfJokDw6fLMunUdd 7sNFHsE4HVgnfD2P0s9pfSSPAOujuwFdI+PkUYxJog4gj+YqozyyPgLkkTxCHoE8mnHsL74Pc/hs 7j+SR4A8KljRqDzyCOSRPGLwpbQ6gK4oj5BHII/kkcojj0BXrN1hfN8E8gjkkcorgjwCdEWVRx6B rojKyyNAV1R55BHoiqi8PAJ0RZVHHoGuOHircb03yY3l84JAVww7fHkkjwBdUR4hj0BDVgGVl0eA rrgfvvNHZM4TdQBdUeWxPgJdEZVHHoGuWHvg3q9DHoE8UnlFkEeArqjy3NpYthfoiiqPPAJdEZVH HoGuqPLII9AVUXnkEeiK8w7862kT15Drb/II0BW/Bv5WEb66VvpX6G/yCNAVa+TR7w228kgeAfJo rjxq/6EQlO0XthHUO9LTCd/No99nsD4Kmkc+nwGsj9rlcnFA52SQPBp/GiR/TB6BPJp4ySmPwhyH yCOQR1PXUx7NcuSQ8Q/lEcijpg3q9Xq6/2io6V1cc3kE8qjx2FtWQx5VOrqoUWR5BLpi+4H7Pr55 l7f1rheVR6AryiMyY6hqPeUR6IryiO3OWTl5BPJIHql84FrJI9AVqw68/ds+Kp+/UQZ7YfIIdEWV d1Qgj0BXROWbhtHAL1Uega7YdOzuP2o55IkqII9AV2w/cOeP3l3+xBiyPAJdUR5NGkORvs3kTxjJ I9AV5dGkYRQjgz7/ALqiPJorjyJlkBgCedRl7K5nWC2PZBDIo6H6Z5e3mOTRUAEkg0Aeqbw8kkGA PFL5qHkkgEBXROVlEKArqrwAkkGgK6LyMgjQFVV+wQwCdEVU/mxQb41LBoGuiMpbBwG6osoLIBkE uiIqL4MAXTFAJQ+/8efslMpSlRdAgDxqX8bfvx8+GLvyn+ErgwB5NEhJl80jGQTIo3FWBzl5FOx7 VL/yCCCvY0TrhNZHAyYygPWRPJJHgDxavIzyyHwA5JE8kkeAPFJJ9x/JI0Aeqbw8AnRFVF4eAbqi yo80KHceAbqiyssjQFdE5eURoCuqvDwCdEVU/q9BmVGArqjy1keArojKyyNAV1R5eQToiqi8PAJ0 RZUfbVBmFKArqrw8AnRFVF4eAbqiyssjQFdE5eURoCuqvDwCdEVUXh4BuqLKyyNAV0Tl5RGgK6q8 PAJ0RVQ+OSifFwToiiovjwBdEZWXR4CuqPLyCNAV+b+S+7P5hw+GziPXMwDyaJQy/v798EHrIwB5 1Lik8ghAHg21UDrLo0/yCFiwYYbshAOGu/URgPXRCJVcMo8c4QDyaLgyyiMAeSSP5BEgj9Ys4+Ep OfcfAcgjlZdHgK6IPALQFVVeHgG6IvLIxgV0RZWXR4CuiMrLI0BXVPkxBuXzggBdUeXlEaArovLy CNAVVV4eAboiKv/XoMwoQFdUeesjQFdE5eURoCuqvDwCdEVUXh4BuqLKjzYoMwrQFVVeHgG6Iiov jwBdUeXlEaArovLyCNAVVV4eAboiKi+PAF1R5eURoCui8vII0BVVXh4BuiK3ivnzn2XyyOcFAfKo /7rgq5if/3kYVfIIQB41KOZqefRvGJlQgDyaL48+zbww3D7+mFDArQYSoRNaHw0zheQRYH0kj7od xuzzCEAeyaMKY/la9ZxEEYA8kkcVM+gnkUc2NCCPpivm+PcfJU4Dff6njQvII5WvmUGnlyXYQIA8 UvkKv+viNJD34QB5pPI1M+jn8rIEGwKQRypf4znTp4FkECCPqFT5y7tTbWFAHlGp8u5OBXRFulTe 3amArkivyrs7FdAV6VV5d6cCuiK9Ku/uVAB51Lfy7k4FkEdj5pGyAPKIXnmkFADySOUBdEWVVwQA XVHlAXRFVB5AV1R5AF0RlQfQFVUeQFdE5QF0RZUH0BVReQBdUeUBdEUWrLxxGZpxGZehqbxxGZeh GZehcVbesw/xtrMYl6EZl3HJo/a13dfZzmJchmZcxiWP5JEZZVw2mXEZmjz6fQQA35HdPY8AQB4B II8AQB4BsGYkOUkHAAAAAABAjpAnlaKeLwt/HjDY0ALfYhl+F3PC3Yx6vadFGl346yRDNu3whw2O jlBzDSHkiOSRcRmjPDI0iwh5VGljRV33eesYZTedAq8j9LfpDooCHx2h8ga1YHOzWrfJbCy2uGci Ym+peAfbId/acmmNHoI8kke2nU1mXCah4o92vB1yaGajTWZcJiEAAAAAAAAAAAAAAAAAAADd7e9S f3jfeuJzMxLP7GZ5AHn0eh4VPJs8ApBHiUf2y5zL72hLPOH+mQ9/S/4vPVuFxf70P4DV8ujw450v v6Mt5wlz/nL5S89+0poLYNI8OvtmorKGfyuPMp/q8pWcLe5sX4DA66PnebTt3nw7fJOwLI+ifgsJ gDyqkUc5S6eH6yMAYufRrURIR8lbeeT8EUDgPNpKr6/Luf9o/7SH19d9/m/Oy9tcXwewan4BgDwC QB4BAAAAAAAAAAAAAACs5h+TSxUdCmVuZHN0cmVhbQplbmRvYmoKMTI2IDAgb2JqCjUyCmVuZG9i agoxMjcgMCBvYmoKNDM2MAplbmRvYmoKMTI4IDAgb2JqClsvSUNDQmFzZWQgMTI5IDAgUl0KZW5k b2JqCjEyOSAwIG9iago8PAovTGVuZ3RoIDEzMCAwIFIKL04gMwovQWx0ZXJuYXRlIC9EZXZpY2VS R0IKL0ZpbHRlciAvRmxhdGVEZWNvZGUKPj4Kc3RyZWFtCnjafZJPSBRRHMe/syVCrAVlJlLwTrYH VwbtYB2M3fVvyrasa6YIss6+2R2dnZ3ezG4lHkKILkHWMbpY0Uk6hgcPHQIPEYJiXSLoKBkEgpeQ 7Tczu+6I2oM37zO//7/fe0BdKG2aeoABecMWyf4ouzs+weo3UIcGBEErrVhmJJEYdplscWTtfYXk nJvh4/X/XQ2CEgISVYDGrMfXHJ72eMDh+7ZpE086rOTSGWKTuE2kkjHiV8Rnsz6e9nGGWwrxMvFN xRQUJ5AiHigpWSfmDrFsZDSD5JeJuzKWkicm38BTZxZemfYQ0H0FOPW5JpuwgOV3wKXWmizUDFwc A1Y6a7LdpDsfqWndUjs7XJEUjAJ1P8rl3Vag/gWw/7xc/vu6XN5/Qzm+Ax91pShKlRlJ0hfA68Nd jf3c4EJTmHNfCVFQNZ37Rnq82uvXi0f1Jat0EnszcVcXsET3MHYGGHoMvPwJXH0PXPgAJBqA1HUE HqG6bf7AzRMrmA+Fls3ZrEOWO1jYOTpZhF4IZ7FC3izaXLBBQ2lvY2ldZ66pxQS3uCjxTDvyerHa 7znaQW6MjtBJ8wqo3OqtsDSTSffQ3aCdeCPDe3qdd0G8qGp9g86F0P6kir5Rj6Xzmj2Y8jjQbejx 4QrDKMRvezGxY9rRZDW+VRrprcpn0rcSdLaQ/MZsYcixaSLf0FwuNeaxlJrLxeIVXsU4dHBoMOhr gCGJfkQRhgmBAlTSaGShkZS7NoLYwuyxljoSPmak3yafbdfnHork7XjdQTSOhbaDCEz+Jv+Wt+Ql +a38a7GlGKppFsSUpqw/+0NxnczVuBVtpSYvvkJ5I6TVkSVp/qAny1eprzrVWGypRXJy8CfxPV+X 3JcpjGk30qybqeTqLPpGfNlOmh7Zrs2vNtdybZ1emdwMrs0fmlXhSFf8oKvD/zU7vz//B82wAWgK ZW5kc3RyZWFtCmVuZG9iagoxMzAgMCBvYmoKNzA2CmVuZG9iagoxMTQgMCBvYmogPDwKL1R5cGUg L0Fubm90Ci9Cb3JkZXJbMCAwIDFdL0gvSS9DWzEgMCAwXQovUmVjdCBbMzIxLjE3OCAzNDEuNjg5 IDMyOC42MjUgMzUzLjM3OF0KL1N1YnR5cGUgL0xpbmsKL0EgPDwgL1MgL0dvVG8gL0QgKGZpZ3Vy ZS4zKSA+Pgo+PiBlbmRvYmoKMTE2IDAgb2JqIDw8Ci9UeXBlIC9Bbm5vdAovQm9yZGVyWzAgMCAx XS9IL0kvQ1sxIDAgMF0KL1JlY3QgWzUzLjAwNCAyMTAuODMyIDYwLjQ1MSAyMjMuMTI4XQovU3Vi dHlwZSAvTGluawovQSA8PCAvUyAvR29UbyAvRCAoZmlndXJlLjQpID4+Cj4+IGVuZG9iagoxMjIg MCBvYmogPDwKL0QgWzEyMCAwIFIgL1hZWiA1NCA3NDIuNDUxIG51bGxdCj4+IGVuZG9iagoxMTIg MCBvYmogPDwKL0QgWzEyMCAwIFIgL1hZWiAyMjguMDYxIDM5OS4wMDggbnVsbF0KPj4gZW5kb2Jq CjM0IDAgb2JqIDw8Ci9EIFsxMjAgMCBSIC9YWVogNTQgMjYyLjA0MSBudWxsXQo+PiBlbmRvYmoK MzggMCBvYmogPDwKL0QgWzEyMCAwIFIgL1hZWiA1NCAxNzEuODMzIG51bGxdCj4+IGVuZG9iagox MTkgMCBvYmogPDwKL0ZvbnQgPDwgL0YxNSA2MyAwIFIgL0YzNyA4MiAwIFIgPj4KL1hPYmplY3Qg PDwgL0ltMiAxMTMgMCBSID4+Ci9Qcm9jU2V0IFsgL1BERiAvVGV4dCBdCj4+IGVuZG9iagoxMzkg MCBvYmogPDwKL0xlbmd0aCAxNDkwICAgICAgCi9GaWx0ZXIgL0ZsYXRlRGVjb2RlCj4+CnN0cmVh bQp42p0Xy67TOHTfr8gylUiw8w47hgIDG0DqYiRg4Zu4rXVTpxOnc4Gvn/Nw2qS3MyONKtX2efm8 jyOCfSCC96vftquX72QeSBHXopbBdhfkWVBmRZzLIti2wdfwg10nVTjqweox2gxqN66jOknrsMV9 NA7mpMaDiYa+66Lh1EXOHJHj3KnR9DYSch1VZVGHG91owJThwzqCfz2sozTNwkSIev19+3ElvE7T +na7krARgQxkWcVZJoM8KeJElEFzXP25EnGW53lJJPM9ISdOD3j54ZgGm371BX6T/IkkmqRHM/F3 HCOLKpaiCHKRxEWds3femf150GhJGqav1lGW5eGbzbtXDNmuqzTsR9Xx8e32D96orrd7Nh+dx8C/ 0Gt6cGe3oM4AkRfActbxXT/9i7+SuoyTSv4vf2X/7a+Z+Hv+yuCWMkjKNIbwP3dXdnUXA/odr0N/ Hg37Jw1H9dBp9oMzvzzrk5mcNmjwlgxPnFLNyJRjz1hK3TOlIyZd5ZNuuioLbU+MLUu5798gKuo4 T9MAOGIhfOA3alTAW2ehsi1u0rDpLab3CJXAgFOnrGaicVDfhCwaPjX98aQG44CBCHf9wAitGlT2 wCfSrgLt0FNJdvEe4nJe3KFHhifnrzno+zegwQsCdezPXNloNAS1iOu0hDWN88xHi7xUgwJkK+5O rN8jpSq6bHSMAPusO5px1C0DvolcGNt059bYtQwxmnWNhj4hrxpa3QKJZGJyIW7IhZV34bML+bKa ZG8+fLrh3SDNa/zzmKN2Tu21u95DWkZksFiaelU942ikdT6LRjqPBh+fDtoy2dFYczS/OGUBw4UL G+OY4Owm0Q8o7ydDKRQI/PTmM2+mtjBHXq16HzPqdz14XG81gxplPeTB6YEbydxKn7PjQWGBQI6C n51p9aAeIDZUXwCcpQSdKfxJMctdhJJRsGKVkllIcYDT/sAIVh2gzthHzzM63e1irPckfG09l+pc v2Apw52iEiaRk64XeV6/MvQkoN+dSC5TqJRz9cuE1QfooFXX/eS91fvO7A03Gjgby7R8MwBOQz9y 9JtJ6lWOsZAwjW7BvDyHWDlm1j9O3HIacNMLgFViEpgs+g6em6531JtQ355X7z7AYorfsdS7CAma aUPy0kWdDf6Og0KITw6i4jl9yXGgOfaDx/maB9iyBL1nuNwdtU0DOdRbZgOdvPN6MHaYWYuV49BH hQy3kx86rXa3NDfalstUvoYZG5wfDjJfJi+cKXlh9XYgBeUdbJYZAoBnFgLsYiG8YTB6smbnSqrN n154z6vtJy41tUaWO3g4ZRSs19Empxr3OtLsCaYunJSxqOv5pEmF9BaIJHyzsAAAnynYN1YAHB4g WTizhKF+fArMXnfJUsZR9gFmNEceOzW+AAnE48cxXYFOEVVY3qhWEXyqWgAsAgNnCgxwUGD+cfTw UIWSWQQLARSscjYRELgYPwjgiQqbWdfGo0x4xRFyMNiy4AGDHoIcfuQDxgpJZp0XJ8iLu/KylJlQ 3nrilX7MAv5o2rbTPIHwfLHrRk4qr3pRUdxJ+QsLilNUqEV5eQFgJaIV6P8S2jNsaUK7y9vIcDVB 14OkwErMSqxER4Kq6zPT8dmNHFS4gyciwO4/qAo/K4p787q4fRzM5c0mLJykYDQMVLpnBFXu+MFM XySgcY5ThOrTv/pEHR50d+Ld2WL783bA+Yk7JuyofUvsyOwn3LcahuI4TWgg4lStpx4CO99DbtIS Mc97iIARwNYpu9f+WsurL31IAz1y9OCvHx5xRKZF+Mne73mK0qtajHkCKMerz7tqmV4VmYvrNGeI tr/hwYGDWV6XV9h85tLNO15bcBu/gC/S67BTmHV7SrvBS/IJj+UvQ5ZaL3rCXOpNsVfX2T1/mKNb 0gq+UCt2C31l+c/QF/y+pwjQhxZ4VMoKxunbHyfD3QvgH8/Wf1QkmWdJBKafzCqRhV+5n+49TfV9 cT98aP0NXv/pIwplbmRzdHJlYW0KZW5kb2JqCjEzOCAwIG9iaiA8PAovVHlwZSAvUGFnZQovQ29u dGVudHMgMTM5IDAgUgovUmVzb3VyY2VzIDEzNyAwIFIKL01lZGlhQm94IFswIDAgNjEyIDc5Ml0K L1BhcmVudCAxMjMgMCBSCi9Bbm5vdHMgWyAxMTggMCBSIDEzNCAwIFIgMTM1IDAgUiAxMzYgMCBS IF0KPj4gZW5kb2JqCjExNSAwIG9iaiA8PAovVHlwZSAvWE9iamVjdAovU3VidHlwZSAvRm9ybQov Rm9ybVR5cGUgMQovUFRFWC5GaWxlTmFtZSAoLi9FVFhfUl8xMF9QXzEwLnBkZikKL1BURVguUGFn ZU51bWJlciAxCi9QVEVYLkluZm9EaWN0IDE0MSAwIFIKL0JCb3ggWzAgMCA1NjAgNDIwXQovUmVz b3VyY2VzIDw8Ci9Qcm9jU2V0IFsgL1BERiAvSW1hZ2VCIC9JbWFnZUMgL0ltYWdlSSBdCi9YT2Jq ZWN0IDw8Ci9JbTEgMTQyIDAgUgo+Pj4+Ci9MZW5ndGggMTQzIDAgUgovRmlsdGVyIC9GbGF0ZURl Y29kZQo+PgpzdHJlYW0KeNorVAhUKFTQD0gtSk4tKClNzFEoygQKmJoZKICgiRGETs5V0PfMNVRw yQeqDwQAlIMN8AplbmRzdHJlYW0KZW5kb2JqCjE0MSAwIG9iago8PAovQ3JlYXRpb25EYXRlIChE OjIwMDkxMjIxMTcxNTExLTA1JzAwJykKL01vZERhdGUgKEQ6MjAwOTEyMjExNzE1MTEtMDUnMDAn KQovUHJvZHVjZXIgKE1hYyBPUyBYIDEwLjQuMTEgUXVhcnR6IFBERkNvbnRleHQpCj4+CmVuZG9i agoxNDIgMCBvYmoKPDwKL0xlbmd0aCAxNDQgMCBSCi9UeXBlIC9YT2JqZWN0Ci9TdWJ0eXBlIC9J bWFnZQovV2lkdGggNTYwCi9IZWlnaHQgNDIwCi9Db2xvclNwYWNlIDE0NSAwIFIKL0ludGVycG9s YXRlIHRydWUKL0JpdHNQZXJDb21wb25lbnQgOAovRmlsdGVyIC9GbGF0ZURlY29kZQo+PgpzdHJl YW0KeNrt3Y1u47oRgNG8/0u7BS5ukGtJFEVKnKF4Dopim26y9ljiF/r38wEAAAAAAAAAAAAAAAAA AAAAAAAA7vfzx/h/euR1PLrWv//vz57dy7l7yY+uTvlqXvpR5Ztvex3DJ787/OYrVfj6sOOz8/aq OVruuoINY790gBV+wvjFhHfEKGqZiq3e1UbULA67J+zpWdw587ZbcORvAjdeqcqvz9uje6/gXT1q OHH0iHsP16Nf0nYPub/7i/ofsv3Vt/J7y7/5//0LR7/XRfWocPHKk6nffB3dQEczqZ/z0S7s6OLV /0MDenT1atasz7t/s3JKDVvsq+fI6YnQcKZcPZiFif4e7Z44X/dr7f5f5WCd/s2G76252Dfeh3Y6 tEsFb5vh1R7dMufT2ZYv3uk/9GiP2g7Fymt0dFjWf/HSbzW333aXzpSegxnu7dGlZa3hMK4vS3+P Gh55qalYT486V9r6deaW2+iJ23331qn5esNh/1BhG779tEptmes56U5nXn/I6RFJerR7v0H5ro9h PXpof1TI0O6pPaBHp+OtuY3aFqvmHl29p7T+/roBO75ySS9d5rvSU7hUbXchlq+UHpGtRw3n+11r xe09urQqFnp014p9dYb33nD1S01/jxr+fsOB8dxOv2eez22F6sd76XcGPeLGJDXf4dz5iMPtj1bE 9qjzun86Hj8a/IvEc/fXhfco5PGjAT3qfPxIj3g6SVefEXT0h/IPOXp45ej0Lz9McPrQw+k6Wf/4 UcPrj07vHNte8fpvqbzHrHzPzOlz/CovSf3T/+of92noUc1jHFcPxYeeX1e+4/f0AbL6kV56ft3n +KkUp0vHdgXQI3Le9QcAegSAHgEAAAAAAAAAAMCpo/fsvfTqQgDoKdHpa+cLXwSA5/ZHegTApD36 AaDi7QoZ0KNUV2HBC2AICYdw9Ajso+vVvLfC/7/pxv84FPXIKmQIhlDu0bK3wsjcOBT1yCpkCGsO 4ZYPK3/BrZBng+N81CNLsSEsMoTMjxo8egFmuT/N+fiaHn2uv/7I5FnqfHnrg9dvevhGj0weVrgD Yd4AyY1V0eRhru3PpIe3DY5VEZNn9gDNcueb3FgVMXlWyFB4jOTGqojJs9pRGtUgubEqYvI4SuUG q6LJw7BD8WjXc9dRqjhYFU0eahrUfy+c3GBVNHnoj5HcYFU0eRh/sO02SG6wKpo8PLH9KR9sioNV EZPn6RKd3gW3VG58wt1EH71nVdQj1inRb4ycaCS8XdxYThMWKdGCMXKi6RFOE3KWaMGDzommRzhN GNOjur+57nMSnGh6hNOENEfa0s+Oc6LpEU4TMhwznqrtRNMjnCaEHzNi5ETTI5wmhB8kYuRE0yOc JtxyePS/uylOND3CaUJ/icToxSfa0TsVFL6uR+gRE5VIjKrXvYD/FC7V7/+s/LoeoUfkL5HDSo/0 CD2iM0Z9P0SMZjrR9EiPxq8q3smWAQumEs3YI48fWRUHzHb3V5q9D6AxeUfLLT9NjObeH9V0R4/Q I5KvkGL0gh59Ku6X0yOe7tEtj2Kz8FEnRno09+1S8yF9tI33a6T2R4iRHt3Vo5ct2vZHg+esR4iR HqFHesRbF0Yx0iM9onK2esTuEXLLPS1ipEd6RNuC4/VH/D0SxEiP0COnCbNvjsTIiaZHOE0I3xyJ kRNNj3CaEL45EiMnmh7hNCF8cyRGTjQ9wmlC+OZIjJxoeoTThPDNkRg50fQIpwnhmyMxcqLpEU4T wjdHYuRE0yOcJiQ4MMRoiROt83P3Tv/m1St+FIj693G99Gm2euQ0QYycaJ+9jzk4WnWP3nGl4Rtr /mfCHtX/TD3SI8SI2Xv09fWadx7b/ZvbDxU6+vav7z3aARUuduGfOLoWeqRHiJETLecFO/qYzsJ2 42v9r/xiYQtT3tTU7OMqL4YeOU3Is9Sc9ogFT7TC40eVi3//F+s3kuUJV360gR45TbA5cqLlv5AP pefouROn4Sjf4Xb0idh65DRh6h6x1InWdj/YXVuh03/6Uk30yGmCzRF61P9FPcLkEaPFT7TT1x8V nsxWmZ7659d9jp9fcXr5P5sn1OmR04Q8i4weOdFouF3cWE4TonokRk40t4sby2nCczHSIycaeuQ0 weYIJ5oe4TRxg+qREw09cpowV4/EyInmdnFjOU14tEf1MXL7D/49gWysinqEzRFYFRdckfwmoEc2 R6BHUWOsfNMMk1+5R4Ae6RGhx4kegR4F/IZ82qP6D6bnTT0CdpdBK6H9ETZHYH+kR6xz+ogR6JEe 8dxdDTZHoEd6xFRHiBiBHg39bdnrj7A5Aj0yeWyOwKqIybvVbI7AqmjyjLnJmnsEWBVNnsAY6RFY FU0eMQKrIiYvRnoEVkWTR4zAqojJi5EegVXR5BEjsCpi8mKkR2BVNHnECKyKmPz7YqRHYFU0eea/ ZcUIrIomjx6BVRGTR4zAqmjy6BFYFTH5N9wc/beIGIFV0eSxOQKrIiaPGIFV0eTRI7AqYvKIEVgV TZ5bboVbbgg9AquiySNGYFXE5GePkR6BVRGTtzkCrIrP/bL9tcoVfgk3+RfESI9Aj6YY6VeYTF6M AD0Kmace6RGgR1P0aPcuPqaI0T8lcrtB//loJRwQd/sjMQLsj/QIPQI9Mkw9evWtLEagR5NNUo/E CNCjJJP0+qNX9gjQI5PH5gisipj8pHP2HAawKmLyL9scAVZFkyc8Rm4xsCqaPDZHYFXE5MXIbQVW RZOnebyexgBWRUz+ZT0CrIomjxiBVRGTFyPAqmjy6BFYFTF5MXL7gFUxZAX7Zw4jp2HyegRYFbdX f/sHkxcjQI/0CD0CPdIjk1+5R2IEehS7iBU+OM/kFzse9Aj0yOTRI7AqYvKIEVgVI6/+EZPXI0CP oiZw9GeTn+L3CjECPXrT1R/2RDs9sjkCrIp6hBiBHiWcwPZhI48f6RGgRyaPHoFVkeaB7D4xr/Bs PZO/cXsrRqBHr1nQOp/mvfvEvPKz9UxejwCrYqEdbQM53QHpkRgBejSsR1/L42mPQt43T4/0CFKd wlbC23tU/lH2R2IE2B/VJ8njR3oE6NFrxqhHYgToUf/V738+gx7pEaBHVxe0G9/Z2+uPxAjQoxmv vh6F9wiwIGPy0cPXI7AqJv1le/wT4E0+tkeAHrn6Jm9zBFgV9QiDBwuyCZh858Q8rQ6sxu9e4jx+ ZHME6JHJI0aAVdHk9QiwKuaZwO/ddCOnYfJiBFgVt1e/8/MmTH7A7wx6BHqkRyYvRoBVUY8cop2z 8hxv0KOJlrvxn5Zr8jZHgFXR5G2OAKsiJm9zBFgVyxNwf53NEaBHSa6+5zO8rEeAHumRydscAVZF PdIjAwY9mnHd83zv192segR6hMnrEWBVnObq65EYAVbFDBMw+ecmo0dgNZ7x6vt82Jw3ihiBHmHy kw9Wj8CqaJ/1vcMq7LlMXowAq+JuSnqmcVqcwBc66RGgRxNd/c7PP9KjDEejGIEe6dHRnXXlHoW8 Djf/XrUnRgYJ053yVsJ7e1T+mfZHw3oE2B+9JtBPNE6Pnu6RzRHoEYX06NHgHgF6hB4F9sjmCPTo HavfXRPY/Wlef2RzBOhRw47G5G2OAD3SI4dic48APdIjkw/skc0R6JEemXyeHgF69ILVz+dNzHwL 6hHoESafpUeAVRGTtzkCrIomr0fmB1ZFTP6JadQPxOYIrIqYvM0RYFU0eWyOwKr47gl4vrcYAXq0 7NXXo+YeARZkV9/kH92l2hyBBdkETD48RpU9AqzG714JPX6UvEc2R6BHmPyYHokRWAoMweSn6BFg VXzxFXd/Xf4e2RyBHmHyeXoEWBUx+QExOpqGzRFYFTH5PD0CrIqYfGCPbI7AqojJJ5iPGIFVEZPP 0iPAquiK3/Jji3dGWW1tjgCr4n+u+F1D+EpP+Z/QI5sjwKr4RI9+X2CrR1cLvtlU6hHokR4N7dH4 N4WwOQIS/ka6+Ep4b49+f4L9kR4B9kedXW4OdE2D9EiMAD2K2nLqUcOxp0dgTeD2eepRTcf1CLAq fh54UoHXH+kRoEf9133kNPwmcPRMb8Ca7IqPHIge2RwBVkU9Srg50iPQI1dcj2yOAD3SI5sjPQKs ire8Htbk+zdHegR41rHJZ+iRGAF6ZPJ6BFgVs113rz+Kuy30CKwDns8QMxA90iPAqqhHYgTokR6t OfnCcxf1CNAjPQqfuU8nBxbv0cfzGbLcCmIEWBU/gR/drkd6BFgVTX5Y62ti5BgE9Mjkn9512hwB VkWTTx4jPQL0yOSfjlHdX9YjQI9MPjhGNkeAHpl8hhjpEaBHJv9QicQIsCqa/Fwx0iNAj0w+yRXR I0CPTD7BdRcjwKr44CS3d1sV7svSIwCr4qNj/P3z7hdnn/wtb/SnR4AejRzp+3r0z2XuueReAwvo 0fi9w2mPot5aPG4+egQcLoN6ZH80uEcA9kd6lGFzBKBHY8aoRzZHgB7p0RNXrf9+XTEC9Ch23X7B 64/uipEDDdAjkw+Mkc0RoEcm/8SOT4wAPTJ5myPAqshqkxcjwKpo8m+KkeML0COT74mRzRFgVTT5 12yOAPTI5MNj5MgC9Mjko6+aGAFWRZMXI8CqiMnrEWBVNHkxAqyKzD15z6kDrIomb3MEoEcmL0aA VdHkxQhAj0z+3hg5jgCrosn3X5KeCyNGgB6ZfHiPxAjQI5MP75F76gA9Mvl7Y9TTIwA9MvnAHtkc AXpk8uE9EiNAj0w+T48A9Mjk7+2RzRFgVXzTJLdre2H3MWmPxAjQo1nG+Pvn3S+mmvzVO+vECNCj GUeav0fXr5oeAXo08UbpqEd/iRGw4II53Uo4adxftj8SI8D+aNJJ6hGAHmUY45uezyBGgB7pkc0R oEdc3Wh8bTfyv/5IjAA9MnkxAtAjk9cjwKrIJ9PzGcQIsCqafHiM9AiwKpp88h6JEaBHJq9HgFUR PRIjQI9MfnCPxAiwKpq8HgHokckfv3GEGAF6ZPJ6BFgVWb1HPnEP0COTz3GR9AiwKpq8GAFWRUxe jwCrosnrEYAerTv5zUcHihGgRyZvcwRYFa1BJq9HgFXR5BP1CMCqaPI2R4BV0RAWnPzfJzOIEWBV NHk9AtAjPfq4sw6wKpp8ph4B6NG7h1n4THA9AtCjh5b3zcc3/JRTpUcAejRgmPl7JEaAHunRz3/p EbDgmhm7EupR+G8Cf298tz9gf6RHQRfyo0SAHulRyOS/XmrkNgf0SI+ieqREgB6tPMyQ1x9t3wtI iQA9Ytjkt09UUSJAjxg5eSUCrIoETn77vH0lAvSIwB4pEWBVJHzySgRYFRk8+c3zyZUI0CMie6RE gFWRMZM/euGSEgF6xJjJH73brRIBesSAyRfedF2JAD1iwOSVCECPYif/70uHShly+wB6xJgebb6u RIAekaVHAHrEyB7t3lMHoEfE7o/0CNAjwnskRoAeEd4jMQKsioaQYfJ6BFgVDSF8fyRGAHqkRwB6 pEdiBKBHGXrkrRgA9ChPjwDQo9AeRcYo/KbPcOwZgiG4FQwBPXL8G4ILYAh6NDY6R++bGjx7x78h GIJbwRDWiVFhznrk+DcEF8AQ9ChJjxz/jn9DcAEMQY9y7I8A+Ck8tMGAHgGAHgGgRwCgRwCsmSQP 0gEAAAAAAFAj9kGl8Ae28jyyFnUZkrwMMPYCZBhChkMx6jIUXqcfewJ6zH2pFsTe7nmeeRi7DKZq 8ZrvV5NhAiGXYXcVGnxJji6D54CtuRx91n7XrH8/L16P1j0Ol+3R7j8XVUb7I0vBynuTJD1KslPO 8Ovoyncd65Ee6dHiG7Tff9djWEk2qsvujwJ/OdEjkuxNVp5DtrfOWPneKj0KHIUesfLpn2QRyPAu 94s/cqFHeqRHeqRH9iZpL4MJ6JEeLdgjL/pIdUPEXv08j+a7FcKH7/VHAAAAAAAAAAAAAAAAAAAA DLP7/ng/ez4Hr5Hf/ZlH/1b5klz9lsIVqfwhXlwPkKdHl/7fmvcN230Xl9O3dulMQ32D9AhAj7bb me3/3P737rfUX9TtDzm9DH+/sfKDqn16NcDIHn0qPqx2NyWFQGz/sPvFmktV7lHNH9ouSbYPgwCY sUcNj7zUVKynR+UFv3l/dPXxr/pLokcAafdHhQztFnBAjz57dxvuprmhR+EfjAKwVI8qHz867dEt u5KGHjVvyur3RwBk61HbOt/2AE3N54c2PH7U80UALvWo/vGjhtcfnd459vWVS99SuCKFy1PzdLuG S+LOOgAAAAAAAAAAAAAAAAAAAACYxf8AR7gVAQplbmRzdHJlYW0KZW5kb2JqCjE0MyAwIG9iago1 MgplbmRvYmoKMTQ0IDAgb2JqCjQ2OTkKZW5kb2JqCjE0NSAwIG9iagpbL0lDQ0Jhc2VkIDE0NiAw IFJdCmVuZG9iagoxNDYgMCBvYmoKPDwKL0xlbmd0aCAxNDcgMCBSCi9OIDMKL0FsdGVybmF0ZSAv RGV2aWNlUkdCCi9GaWx0ZXIgL0ZsYXRlRGVjb2RlCj4+CnN0cmVhbQp42n2ST0gUURzHv7MlQqwF ZSZS8E62B1cG7WAdjN31b8q2rGumCLLOvtkdnZ2d3sxuJR5CiC5B1jG6WNFJOoYHDx0CDxGCYl0i 6CgZBIKXkO03M7vuiNqDN+8zv/+/33tAXShtmnqAAXnDFsn+KLs7PsHqN1CHBgRBK61YZiSRGHaZ bHFk7X2F5Jyb4eP1/10NghICElWAxqzH1xye9njA4fu2aRNPOqzk0hlik7hNpJIx4lfEZ7M+nvZx hlsK8TLxTcUUFCeQIh4oKVkn5g6xbGQ0g+SXibsylpInJt/AU2cWXpn2ENB9BTj1uSabsIDld8Cl 1pos1AxcHANWOmuy3aQ7H6lp3VI7O1yRFIwCdT/K5d1WoP4FsP+8XP77ulzef0M5vgMfdaUoSpUZ SdIXwOvDXY393OBCU5hzXwlRUDWd+0Z6vNrr14tH9SWrdBJ7M3FXF7BE9zB2Bhh6DLz8CVx9D1z4 ACQagNR1BB6hum3+wM0TK5gPhZbN2axDljtY2Dk6WYReCGexQt4s2lywQUNpb2NpXWeuqcUEt7go 8Uw78nqx2u852kFujI7QSfMKqNzqrbA0k0n30N2gnXgjw3t6nXdBvKhqfYPOhdD+pIq+UY+l85o9 mPI40G3o8eEKwyjEb3sxsWPa0WQ1vlUa6a3KZ9K3EnS2kPzGbGHIsWki39BcLjXmsZSay8XiFV7F OHRwaDDoa4AhiX5EEYYJgQJU0mhkoZGUuzaC2MLssZY6Ej5mpN8mn23X5x6K5O143UE0joW2gwhM /ib/lrfkJfmt/GuxpRiqaRbElKasP/tDcZ3M1bgVbaUmL75CeSOk1ZElaf6gJ8tXqa861VhsqUVy cvAn8T1fl9yXKYxpN9Ksm6nk6iz6RnzZTpoe2a7NrzbXcm2dXpncDK7NH5pV4UhX/KCrw/81O78/ /wfNsAFoCmVuZHN0cmVhbQplbmRvYmoKMTQ3IDAgb2JqCjcwNgplbmRvYmoKMTE3IDAgb2JqIDw8 Ci9UeXBlIC9YT2JqZWN0Ci9TdWJ0eXBlIC9Gb3JtCi9Gb3JtVHlwZSAxCi9QVEVYLkZpbGVOYW1l ICguL3JvdXRpbmcucGRmKQovUFRFWC5QYWdlTnVtYmVyIDEKL1BURVguSW5mb0RpY3QgMTQ4IDAg UgovQkJveCBbMCAwIDU2MCA0MjBdCi9SZXNvdXJjZXMgPDwKL1Byb2NTZXQgWyAvUERGIC9JbWFn ZUIgL0ltYWdlQyAvSW1hZ2VJIF0KL1hPYmplY3QgPDwKL0ltMSAxNDkgMCBSCj4+Pj4KL0xlbmd0 aCAxNTAgMCBSCi9GaWx0ZXIgL0ZsYXRlRGVjb2RlCj4+CnN0cmVhbQp42itUCFQoVNAPSC1KTi0o KU3MUSjKBAqYmhkogKCJEYROzlXQ98w1VHDJB6oPBACUgw3wCmVuZHN0cmVhbQplbmRvYmoKMTQ4 IDAgb2JqCjw8Ci9DcmVhdGlvbkRhdGUgKEQ6MjAwOTEyMjExNzE2NDAtMDUnMDAnKQovTW9kRGF0 ZSAoRDoyMDA5MTIyMTE3MTY0MC0wNScwMCcpCi9Qcm9kdWNlciAoTWFjIE9TIFggMTAuNC4xMSBR dWFydHogUERGQ29udGV4dCkKPj4KZW5kb2JqCjE0OSAwIG9iago8PAovTGVuZ3RoIDE1MSAwIFIK L1R5cGUgL1hPYmplY3QKL1N1YnR5cGUgL0ltYWdlCi9XaWR0aCA1NjAKL0hlaWdodCA0MjAKL0Nv bG9yU3BhY2UgMTUyIDAgUgovSW50ZXJwb2xhdGUgdHJ1ZQovQml0c1BlckNvbXBvbmVudCA4Ci9G aWx0ZXIgL0ZsYXRlRGVjb2RlCj4+CnN0cmVhbQp42u3djW4iuRKA0bz/S/eOhBYh2m27f+gqt8/R 1dVsZpdADalvHCAsCwAAAAAAAAAAAAAAAAAAAAAAAADA8veh+MHPj69/6+t3ez7XJdf56xcnL6f/ d898xktue880fvSJ7rk5v7ifAEPEqGfPf6UqfDlcdVE39+i2P82he5TwfgIE7pP1b+3ddV+np63D 1OsjlX9t/evPf+frWm2d5rZuUf0aFi+zeIrs/Hv++nN1XlpzIMWxVK5bz03b+gOqX0h9kufvJ83P tfWHXv83gaf2qLLZKhu7+V9VvjFVvJzi7zZvVP9ldp6kKhPovLSeHjWveXPs9SEU/w6w90KuvZ80 7xt770XAcD1qPni0a8/0/1d769CfjF2ROnzhnd8F3Vu3k9ft8KgPXMi195MLPwg4H+Xp0TqyPX/9 bna5MzrNSxuoR/VJRvWo8j1SqwD0KE+Pznzq/mnUe9RzIev/z3w+at66kPPRri8EICpJVz2/7hc9 OvBoTtrHj/ofITo8qzM96rzhBx7TubNHHj+CEZO09/VHuy62fzEu3U+X2np+3dZ34Za+R8nXz09b cjy/rr9HxeeV7bqo/sPX3ufXXXU/6X/WnOfXAflPggAQ0iA9AiA2Sb4nAwAAAAAAAAAATKX59gGV DwLAJSWq/9CA/p+aAgDXno/0CIBBe/QHQMc7p3BDjzLfItfH9TGiUa7PvwtO9b8n3av1yBev66NH c16fZ2RFj/TIMnF9XKUk12eIprgL6ZEvXtdHj0a5Ps8+qrgLPbVHy/7XH5k8zHZgQY9MHmRFU2xF TB5kBVvR5OHZZcFWxOSRFU3BVjR5kBVsRUyeZ5cFbEWTR1ZkBVsRkydhVsBWxOSVRVbAVjR5ZAVs RUz+2cUBbEVM/sIYAbYiJn9bjwBbEZPXI8BWNHn0CGxFTF6PAFvR5NEjsBUxeT0CbEWTR4/AVjQE k9cjwFY0efQIsBVNXo8AW9HkDUGPAFvR5PUIsBUxeT0CbMXfTfKl+UGT1yPAVrxhjO9fFz9o8noE 6JEe6RGgR3q0/k8+meFXjIwEZticNuGvB+t85HAEOB/lGakeORwBeqRHDkeAHk0+Rj1yOAL0KHaS Xn/kcATokck7HAG2IibvcATYiibvcATYipi8wxFgK5q8wxFgK2LyDkeArWjyDkeArYjJOxwBtqLJ OxwBtiIm73AE2Iom73AE2IqYvBgBtqLJP7VHALaiyTscAbYieuR+B9iKJu9wBNiKTD55MQJsRZPP 0yMAW9HkHY4AWxE9cncDbEWTdzgCbEVMXowAW9HkHY4AWxGTFyPAVjT5PD0CsBVvm+RL84NTTd7h CNCjqDG+f1384Jw9AtAjPXI4AvRotkl+fWuu2aNPDkfAtGvz2ZvQ+UiMAOcjPdIjPQL0SI/ECNAj Y9QjPQL0KHySXn8kRoAemXyqHgHYiibvcATYipi8OxRgK5q8wxFgK2LyDkeArWjyDkeArYjJOxwB tqLJixFgK2LyegTYiiYvRoCtiMnrEWArmnyqErkHAbaiyesRYCti8noE2Iomr0eArYjJ6xFgK5q8 HgG2IiavR4CtaPJ6BNiKmLweAbaiyesRYCti8noE2Iomr0eArYjJ6xFgK5q8HgG2IgfG+Gn9cT0C 0KOokX6FSY8A9ChknnoEoEdD9Kj4LT49AuZZmM/YhPnj7nwE4HykR3oE6JFh6hGAHuWZpB4B6FGS SXr9EYAembweAbYiegSgRyavR4CtiB4B6JHJ6xFgK6JHAHpk8noE2IroEYCtaPJ6BNiK6JF7EGAr mrweAbYiJq9HgK147QTeP/L0zmk8pkcAtuKFN3/9C5PXI0CP9EiMAD3SI5PXI0CPQibwyeTFCNAj kx8oRu44gK1o8g5HgK34vJu/xeQdjgA9iprA1q9N3uEI0KObb/5tT7QbdPIOR4CtqEcOR4AePXsC 64eNPH7kcATokcmLEWArcnggxSfmVZ6tp0cAelRMxpmneRefmFd/tt5YkxcjQI/uufknHzlqnoD0 CECPbuvR1wmr2aOQn5t3rERiBPxiA4+yCcfqUf2ixj0fiRHgfHR/kjx+pEeAHj1mjHoEoEfnb/75 5zPoEYAe7brh1/5k76e+/kiPAD169s3XIwA9Mnk9AmzFhBMIeQK8HgHoUYabr0cAeqRHegRYyCag RwB6tL75Hj/SI0CPTF6PAPTI5PUIsBVTTeD9bbo7p6FHAHq0vvkn329CjwD0SI9u6JEkAbaiHjkf AXo0yQRC3i1XjwD0yOTFCLAV0SMAPapPwPfrxAjQoyQ33/MZPmOkR4Ae6ZHDEaBHejT55B2OAD0K mYDnezscAXpk8mIEoEfeH1aPAAt58gnknLwYAXoUdfO9P+xXjPQI0COTdzgCbEUuPGetP55/8g5H gB4lScmZaTSLE/hCJ4cjQI8Guvkn3/9o9B45HAF69JgeFb9ZV+9RyOtwHY6APBs41SZ8Ro/qlznK +QjA+ShPoH/ROD0C0KP7x6hHAHqkR3oE6NGIt/3CR9CKlzbK64/0CNCjVCeaaSevR4Ae6ZEeAeiR HukRoEd6pEcAevS3TY8A9Mjk9QiwFdEjAFvR5PUIsBXRI3cEwFY0eT0C0COT1yPAVkwygcmf7+3N YQE9mvnmZ+sRgB7pkcMRgO/XRU0gVY8A9Cj85s/8+JHDEaBH5OkRgK1o8g5HAJP36HXDZ/5+nRgB ekT45B2OAFuRPD0CsBUJfemTHgG2Ill6BGArskS+DlePAFuRLD0CsBWffcO/LrbyHPKQyTscAXqU +YZfNYSv9NQ/RWCPAPTowT16v8A2bY8cjgA90qNij+78oRBiBCTcwyE/HufZPXpfQtrzkRgBzkej dPlwoHsapEcAehR15NQjAD3KME89AtCjY0eby+eZ5/VHegTo0UC3/c5p6BGAHlVu+FPfj0+PAD3S Iz0C0CM90iNAj/RIjwD0qHnDr3o9rB4B6JHJ6xFgK6JHAHr0i9vu9UcAepTkhnv8CECP9EiPAD1y w/UIQI/0SI8APXLbQ6ahRwB69Hnzo966XY8A9GjCyesRYCuiRwB6ZPJ6BNiK6BGAHpm8HgG2InoE oEcmr0eArYgeAeiRyesRYCuiRwB6lGGS6x86VPlJRHoEoEc/HeP718UP6hGAHt08Uj0C0KOoYW41 qNijO3+0uB4BOXdm1JssOB85HwE4H+kRgB7NM0Y9AtAjPdIjQI9M0uuPAPTI5PUIsBXRIwA9Mnk9 AmxF9AhAj0xejwBbET0C0COT1yPAVkSPAPTI5PUIsBXRIwA9Mnk9AmxFntEjf9qArYjzEYAembwe AbYi4ZMXI8BWRI8A9MjkxQiwFckweTECbEX0CECPTF6MAFsRPQLQI5MXI8BWRI8A9MjkxQiwFckz eTECbMXJJ/nS/KAeAejRDWN8/7r4wV9PXowAPUKPAPQo80Fpq0efriqRP09goIV5+SakGJ2bz0di BDgf0SyOHgHoUdQY9QhAj/QIQI/mHGPxIbk7X3+kR4AekWHyegTYiugRgB6ZvB4BtiJ6BKBHJq9H gK2IHgHokcnrEWArokcAemTyegTYiugRgB6ZvB4BtiKj9MifJ2Ar4nwEoEcmr0eArUj45MUIsBXR IwA9MnkxAmxFMkxejABbET0C0COTFyPAVkSPAPTI5MUIsBXRIwA9MnkxAmxF8kxejABbkV3D/Puf HgHo0T1jXHfn8x+LqRIjAD26YZh6BKBHQ/TokxgBE+7MY5uQDOcjPQKcj9AjAD3SIz0C9Ag9AtCj oYd5+euP9AjQIzJMXo8AWxE9AtAjk9cjwFZEjwD0yOT1CLAV0SMAPTJ5PQJsRfQIQI9MXo8AWxE9 AtAjk9cjwFZEjwD0yOQ7Y+RPDLAVydAjAFuRwMk7HAG2Inl6BGArEjh5hyPAViRPjwBsRQIn73AE 2Irk6RGArUjg5B2OAFuRPD0CsBUJnLzDEWArkqdHALYigZO/+XCU7Z7g+gz3lWtEro8ePbtHvlhc H8vE9XEX4pLxvuyd/P2PHPlicX2MyPVxlWY4Aa3n3NMjXyyuj2Xi+rgLEdijkKfV+WJxfYzI9XGV pu0RAJ+EI6RHAKBHAOgRAOgRAHMmyYN0AAAAAAAANKV6XCnP69EqrxrOcH1iB1X8vOHz+frsRpR5 PvV7dZIvfC+PjR1+quuTKtCBg2penwz3mdg7UvMqTT6ibPP5vGOn2kWVq4Qe5bkm4YPK06Pi1chz R8qzb3OOKMl8Xp89VY/qV4k5e5TkdJy/R+GDyvaX28o3W/z9v3h9Yr9/OESPfLNu5h7lOQIk71H4 oLLNJ+GIkp+PAufTnEngt3y3PrUk6ZEe5Vy29bcsyTYfPUrVo54GZXh8TY/0KOHDEDn3bZIv3mx/ uU04oiGez3Bzj4rPW8vwlKE8V0mP9EiP9EiPMny9e1R05iSlesAu5/MZlmSvPwq8Plsvysjw4pqE VynJXSjhS8aW9K8/WvzYTwAAAAAAAAAAAAAAAAAAgFmdf8vLS95A56+k+RmbH+z5dMcuAYDLe3R4 q/9ijfdc2ske5XwrQwA92vrH+gni/W5l73/n66C09ePRlp1vlrF1NerXrXLCan4828++A5i5R/0/ Arr4i87f3dvHzsvvSU/9PZsOXCYAJ3vUfDDlQI8Or/Se3+q8GkvHu/JV/mVvNAAQdT7K2aPOt0Ur frdt16NR9TadfNYHAP09Wq77ft1VPTpzNS65yc5EAJl7dOARnDyPHzVvcv2hJW0CuLNHS/UtRIt1 aBbh/PPrvv7/2PPrltbrjzy/DmDOCAJASIP0CIDYJPmWFwAAAAAAAAAAAAAAMI//AOOwTZsKZW5k c3RyZWFtCmVuZG9iagoxNTAgMCBvYmoKNTIKZW5kb2JqCjE1MSAwIG9iagozNjE1CmVuZG9iagox NTIgMCBvYmoKWy9JQ0NCYXNlZCAxNTMgMCBSXQplbmRvYmoKMTUzIDAgb2JqCjw8Ci9MZW5ndGgg MTU0IDAgUgovTiAzCi9BbHRlcm5hdGUgL0RldmljZVJHQgovRmlsdGVyIC9GbGF0ZURlY29kZQo+ PgpzdHJlYW0KeNp9kk9IFFEcx7+zJUKsBWUmUvBOtgdXBu1gHYzd9W/Ktqxrpgiyzr7ZHZ2dnd7M biUeQoguQdYxuljRSTqGBw8dAg8RgmJdIugoGQSCl5DtNzO77ojagzfvM7//v997QF0obZp6gAF5 wxbJ/ii7Oz7B6jdQhwYEQSutWGYkkRh2mWxxZO19heScm+Hj9f9dDYISAhJVgMasx9ccnvZ4wOH7 tmkTTzqs5NIZYpO4TaSSMeJXxGezPp72cYZbCvEy8U3FFBQnkCIeKClZJ+YOsWxkNIPkl4m7MpaS JybfwFNnFl6Z9hDQfQU49bkmm7CA5XfApdaaLNQMXBwDVjprst2kOx+pad1SOztckRSMAnU/yuXd VqD+BbD/vFz++7pc3n9DOb4DH3WlKEqVGUnSF8Drw12N/dzgQlOYc18JUVA1nftGerza69eLR/Ul q3QSezNxVxewRPcwdgYYegy8/AlcfQ9c+AAkGoDUdQQeobpt/sDNEyuYD4WWzdmsQ5Y7WNg5OlmE XghnsULeLNpcsEFDaW9jaV1nrqnFBLe4KPFMO/J6sdrvOdpBboyO0EnzCqjc6q2wNJNJ99DdoJ14 I8N7ep13Qbyoan2DzoXQ/qSKvlGPpfOaPZjyONBt6PHhCsMoxG97MbFj2tFkNb5VGumtymfStxJ0 tpD8xmxhyLFpIt/QXC415rGUmsvF4hVexTh0cGgw6GuAIYl+RBGGCYECVNJoZKGRlLs2gtjC7LGW OhI+ZqTfJp9t1+ceiuTteN1BNI6FtoMITP4m/5a35CX5rfxrsaUYqmkWxJSmrD/7Q3GdzNW4FW2l Ji++QnkjpNWRJWn+oCfLV6mvOtVYbKlFcnLwJ/E9X5fclymMaTfSrJup5Oos+kZ82U6aHtmuza82 13JtnV6Z3AyuzR+aVeFIV/ygq8P/NTu/P/8HzbABaAplbmRzdHJlYW0KZW5kb2JqCjE1NCAwIG9i ago3MDYKZW5kb2JqCjExOCAwIG9iaiA8PAovVHlwZSAvQW5ub3QKL0JvcmRlclswIDAgMV0vSC9J L0NbMSAwIDBdCi9SZWN0IFszNzUuNDQzIDIzNy42NDYgMzgyLjg5MSAyNDkuMzM2XQovU3VidHlw ZSAvTGluawovQSA8PCAvUyAvR29UbyAvRCAoZmlndXJlLjUpID4+Cj4+IGVuZG9iagoxMzQgMCBv YmogPDwKL1R5cGUgL0Fubm90Ci9Cb3JkZXJbMCAwIDFdL0gvSS9DWzEgMCAwXQovUmVjdCBbNDEy LjYyOCAxMjkuMjUzIDQyMC4wNzUgMTQwLjk0Ml0KL1N1YnR5cGUgL0xpbmsKL0EgPDwgL1MgL0dv VG8gL0QgKGZpZ3VyZS42KSA+Pgo+PiBlbmRvYmoKMTM1IDAgb2JqIDw8Ci9UeXBlIC9Bbm5vdAov Qm9yZGVyWzAgMCAxXS9IL0kvQ1sxIDAgMF0KL1JlY3QgWzQyNC40NzIgMTI5LjI1MyA0MzEuOTE5 IDE0MC45NDJdCi9TdWJ0eXBlIC9MaW5rCi9BIDw8IC9TIC9Hb1RvIC9EIChmaWd1cmUuNykgPj4K Pj4gZW5kb2JqCjEzNiAwIG9iaiA8PAovVHlwZSAvQW5ub3QKL0JvcmRlclswIDAgMV0vSC9JL0Nb MSAwIDBdCi9SZWN0IFs0NTQuMDgxIDEyOS4yNTMgNDYxLjUyOCAxNDAuOTQyXQovU3VidHlwZSAv TGluawovQSA8PCAvUyAvR29UbyAvRCAoZmlndXJlLjgpID4+Cj4+IGVuZG9iagoxNDAgMCBvYmog PDwKL0QgWzEzOCAwIFIgL1hZWiA1NCA3NDIuNDUxIG51bGxdCj4+IGVuZG9iagoxMzEgMCBvYmog PDwKL0QgWzEzOCAwIFIgL1hZWiAyMTUuODY0IDUxNi4yNDQgbnVsbF0KPj4gZW5kb2JqCjEzMiAw IG9iaiA8PAovRCBbMTM4IDAgUiAvWFlaIDE4OC4yMjcgMjg3LjMxOSBudWxsXQo+PiBlbmRvYmoK MTM3IDAgb2JqIDw8Ci9Gb250IDw8IC9GMTUgNjMgMCBSID4+Ci9YT2JqZWN0IDw8IC9JbTMgMTE1 IDAgUiAvSW00IDExNyAwIFIgPj4KL1Byb2NTZXQgWyAvUERGIC9UZXh0IF0KPj4gZW5kb2JqCjE2 NSAwIG9iaiA8PAovTGVuZ3RoIDIzMzYgICAgICAKL0ZpbHRlciAvRmxhdGVEZWNvZGUKPj4Kc3Ry ZWFtCnjalVhLjxu5Eb7Pr9Al2Bbglvv9yM3J2BsvFruOMwEC7O6BkiiJcKspk90ez/761Iutbo1y CASIZLFYLBarvip2sjquktWPD397enj7IS1XabJpkzZdPR1WZbGqi2pTptXqab/6LfrYr7MmGrTr 9RA/OnUY1nGb5W20x348OHNRw8nEznZd7C5d7M0ZV4ydGozt4yRdx01dtdGj3mmYqaPtOoZ/7dZx nhdRliTt+o+nnx4S0Sm0758eUugkq3SV1s2mKNJVmVWbtG1Xu/PD14dkk7dNVRDLvE+TYaUQ3n48 l6tH+/BP+IWpOEiNZ2LvG6RMsk3VNGyQD+Y4Og3KN2lU/nUdl2CLd2c7sp2Ybg/YJtFeDYopqt9z Z2eZEezFhIvaIeEL/unBM3FwqvdnMwx6z5IO1vGMZvYTj3oLxmyivejzfNI9859Nb87mT9Mfeeb9 03+4YzwzjB5Eg93BFnGab8qST/fr3z/hveSR6iythSsaTpppj7jzO/z7cbO4MxSS55skESm0SV5F vT525mi26zTqNJNMz+3Oni/KGW9pXEaDZbpsVgbbIcmp35O02m3WcVGm0bvO2zc3zN/WZRmBOPI5 JoWNgpxykiOKeKaST46TUYHSKXdk96zE7kAUXa4Gn9muaPnYu856WpjUfB5ovem/oLZpFhx/HYMX KLA/MoQzAOde+8H04QRAIC9CUYHjtasAEY5e4dG1jC3OfluHEMMdzFmTCnCrPVzFnhmz5C//zz7K LfRcek+wAJ26LOjU3LN997JuiggurwRdPqybPCKblsGxoINaBcP6MKcG7vHG0DmMDlbIWoXKPeMf 9V6ExdnzrQZ49LINm+WvfAVYyFdgSnwFt7/6Coy2pJsGnw3qddrDVb+5E0Ec6RAt4pyg6hwdYILs nU+75YvdgM6eiSHoLc/7s+o67SjoVmm1afNqBb60SVoBpSfaK8sZXuoAL0CYiYYRu3MWlMsKduha 7A7jk/LMobh5RnFKfApsEHeG/YLZAfwxN2BoFulVjcWRgY2OHNRrZupdXa0WV5trSWBXU1zCaBl7 cbDD3P/2zl48e/3X0bDo7oUJyi8CrprDGRP8oLamM39q4dyPIUbtzVINNs31buARBxACVdhSXyPP oW0AQP5hxWPhoGxKR0GZToopbnr9/D/0+5f+Oup+J8LBTe5EoNqL8MEAwuMOVdAbg+CqIW5aJSG6 2shprwfusgtfY6a9ml5WgaWcMGtIU5xmYPD48VfuHBzpSpdNF4Bij4oCDdYzTrRXi9/sF45eS6a5 zVI9JTzwJ0X5Lou8Johry5Ap2YFhZpEiM8ZohGDHY9IEuANOtwGWmilAgevCjiiIyDTx8TqSMWfW POLy55ql8+hkjoxbuN+JVb6NhVebyHHwLu5cswcoemaIbAE7/c50UHBZ98IE5ewImEr3iENuzpr2 hh4njW7U4JxVWkvgtskNfgDh1clR3Dy6gUd/P5mtoei9bvaDZ4iOB74AO5x+4BnJgydGFWOXMBpO eAZnIc9Ji7Bih/em8GAee1pymmcmLnGgw1lBqKNEQdqIW89WSLkEvU+Pn7nD16b6o/a0qr6KZcdK CzrgxGq6PQ8nIOUh+RW0bJYUkdLpyWi3O905//PJTD4EVQ+E59iRLBhwvkqvMiQA0xvMAMJeXwYR QTAFrURZej0BQlTbgBcYti1OUpAwlkxqsx46qDEJWgIfEhD4uCtgkhJQcO/zuxiAYnPv1OCIToOl MZqzpoXyQaNZG4507NgtJN5vkoKQwJUC94RECo8UiJK6nSw+iLR57CHhVcmDRMht4IRhwA3GMvem GOIhuQftEVQ24enEFUcnRyKDsLprNPM9EF+8JzAqufCo4dnFaUTKfPIyoHaz5OKYJJuOYSG7L3T8 CBZkcGbsAtqtqh7LNYCkUGtD1AquJlD6qAOvWmSFOsA3sNzqb2XB3OyvUf112UmFmlR/Z8u9MkAo 0EK9Vt6ufSPJTYSIymWxVPlaXJaTeAhURzdIO0k5e1A7ocyidl46olLaSGk6S16iZojBAjW6c9/2 cmGM9DoUj5bbhb5QCU5PjBmPlLr5BGjX4jOPOpnMBeNyUXnOM1jZvrPHFyZx3UXPhSMhgdSk+5de nc0OylGp6uE0bz/k9SpNN21ZZvhihsMV2aauMj5cuSlBQJqV0c/Wk6eU4hAlOkQPZZT5BtCQp1DF k7jlAxzEZcmmbAsW92/RlSqJNJwPegdlOniZ8923hNLV8oVcZZBVwmsB19pgdZ7kNGPprmB4ooxe pTPo9jzze1ImF8Ap7RxdWBVgDjpbSZjjBbjSm0kTJHiz7Ri0gYrizIEnFG30gmsxBqH/sb8TKwMr lwM2KE+lD3RJBrSKm2VMMI3L+1yQA1rBRx74K9SjGNI6C3ENFKgqpNZDCWrbCX3PuU+L7N6KhBDv XPeRSG5lHypX8vB1A2UyJMpisK4Pt73Hfe+EzvLVnIZXLKT7C4i6LV5gnuwG0/hUuLDalP/yNvr8 6WdZ6ixPgWsI+zC9Ny3LOVMJEvDAnD2TpUqoEQXqayYGgtMXZRy5Z5ZGX/jNCzzPorgSCcfOblXH u/KauymCL6dmJ67BDToe8xJ6kGXoO0QUd8lqyejOs70yef1n4Y2AFQxHxW48yy2Rxk20/LAXNgtV SRa+EICoCxYJnF4oPDJ5QfHTh7OmGnRQTTqzpHEPIumTWk2VBfaaex/Ogg4wCzg5MCk83uWTS1NP sjrGo6aZKHM8IpyAOh1LZHhucYkMvGa/lupI8SIje/NTAtqxF1ZJiHV4Du1eRMuB55/R3c30xoUZ fPzdOf2srAuPwF/GxddUqTL5/NA56l47xfanChq4Xrj8lQgpbl20gPiWUj0wquFG7OiDxKkcvvpr MXO+HIBLFhvRTX+/yFVMatEOd76hIBY213cT9OcWhOEzvHe4B7l9zz2yP7T+ZN0Q1u1HhzggLlvJ VVfN8qrZNtXkEpg/BqaILhcocfVSwh0tHbv1cpt7JU+42NcYfSc/95pUZPRxX15/ey3LTZKHT0Ho s/JV/g2v10P4oLTBTNzUafT++8U4LUn9J3ZY/BpfyJIsSRPgLZqkiH77RA+qo/C0fyz2f//08F82 01lNCmVuZHN0cmVhbQplbmRvYmoKMTY0IDAgb2JqIDw8Ci9UeXBlIC9QYWdlCi9Db250ZW50cyAx NjUgMCBSCi9SZXNvdXJjZXMgMTYzIDAgUgovTWVkaWFCb3ggWzAgMCA2MTIgNzkyXQovUGFyZW50 IDEyMyAwIFIKPj4gZW5kb2JqCjEzMyAwIG9iaiA8PAovVHlwZSAvWE9iamVjdAovU3VidHlwZSAv Rm9ybQovRm9ybVR5cGUgMQovUFRFWC5GaWxlTmFtZSAoLi9PdmVyaGVhZF9Qa3QucGRmKQovUFRF WC5QYWdlTnVtYmVyIDEKL1BURVguSW5mb0RpY3QgMTY3IDAgUgovQkJveCBbMCAwIDY0MCA0ODBd Ci9SZXNvdXJjZXMgPDwKL1Byb2NTZXQgWyAvUERGIC9JbWFnZUIgL0ltYWdlQyAvSW1hZ2VJIF0K L1hPYmplY3QgPDwKL0ltMSAxNjggMCBSCj4+Pj4KL0xlbmd0aCAxNjkgMCBSCi9GaWx0ZXIgL0Zs YXRlRGVjb2RlCj4+CnN0cmVhbQp42itUCFQoVNAPSC1KTi0oKU3MUSjKBAqYmRgogKCJBYROzlXQ 98w1VHDJB6oPBACU5Q31CmVuZHN0cmVhbQplbmRvYmoKMTY3IDAgb2JqCjw8Ci9DcmVhdGlvbkRh dGUgKEQ6MjAwOTEyMjExNzE2MjktMDUnMDAnKQovTW9kRGF0ZSAoRDoyMDA5MTIyMTE3MTYyOS0w NScwMCcpCi9Qcm9kdWNlciAoTWFjIE9TIFggMTAuNC4xMSBRdWFydHogUERGQ29udGV4dCkKPj4K ZW5kb2JqCjE2OCAwIG9iago8PAovTGVuZ3RoIDE3MCAwIFIKL1R5cGUgL1hPYmplY3QKL1N1YnR5 cGUgL0ltYWdlCi9XaWR0aCA2NDAKL0hlaWdodCA0ODAKL0NvbG9yU3BhY2UgMTcxIDAgUgovSW50 ZXJwb2xhdGUgdHJ1ZQovQml0c1BlckNvbXBvbmVudCA4Ci9GaWx0ZXIgL0ZsYXRlRGVjb2RlCj4+ CnN0cmVhbQp42u3dgZaiOAJAUXIy///N092WJQiBkAQCet+ZXWeqVVCuhChtDYMkSZIkSZIkSZIk SZKkdoWQf81w4tLqbxSOuNvSu3v96Z4n/NQH0PS5yF63PVccP4mTJSzdSVhaibef5C28bDvs9bd4 /R2b+HHVnxvMbvdV/v6uWPOVm9zh2xKW/a1uho/zN7kBf6/d4M+O67k/ev7w979GO8zpn013pov+ ZncWEld5rcvW7Rb+LMzXZXSVsHxn73cZhv3rsnjX7/81jJ7I5XWZPIYwXfrSA1vcDsv3GcIFFY5e hP+enn8rOXrA4//6/b/XD6dPzeheFndu82vPxt/JXU83/fKecnNdhvd7GmY3SK/ujnWZ/XC29BAm r8/J/i/jMWys4NZjP2SkO9bf679mhy2rT01y/zd+6sJc4mR54xdvSIxWk9Vd1J30N96SS/4K1mX5 oYwXu+bv/ZWffpLHu7zkKzut/9L+EhdvTAr8re075isxH8tna5GxL67wt3tdFu96/oDX9n8bjtaf rKz932XnHwsvlWHZX8b4u+Uvz8p8zMscYzfG34WNtnD8t3tdFu86sYK/5GZ3lno+w67B9Ubj7+Jx dnI8TE4SVucf0yPrxePs2TH8bFIypOYfYXkzJdZzPH6Oj93r12V+12E2b3k/DJzf2dL8Y7bXn88q 0m4vPv+42buVX/vYv2qT8HfbzwgkSZIkSZIkSZJU3vTj86XTYn1yowP5Ddln/EiH+Vs+YY0/nWFw fA5j4mI0Xkvzyg8ARwzTBp9Xr4He5aZW+cqLnZzwmnNato1pldvdNvOvDvFnlQ/yt/3Gy/RvRNiY Vrn1ba+3GN1uFsufSo77+VONoxO/GYw/LTg67ZvB+FMC1xHfDMafduz/Wn8zWNyKPx35zWD2f8r0 d8Q3g/GnAn/NvhmMP2W//3LEN4Pxp/u8EPgTf+KPP/GnrrOSjHkzf9o7182EtPTbcNZu5vNfbfNb cpLjz/kHauPvtRvc89vAnH+gZv4KfhtY2fkH/23FH3+Zv43p5dD5B+riz/kHajH/KPhtYMs3d/6B St5/Oe+3gfGn27w4+BN/4o8/8Sf++BN/4o8/8Sf++BN/4o8/8Sf++BN/4o8/8Sf++BN/4o8/8Sf+ +BN/4k/q4i96qsWf+JP4E3/ijz/xJ/74E3/ijz/xJ/74E3/ijz/xJ/74E3/ijz/xJ/74E3/ijz/x J/74E3/6RH+T36m9esGfmvv7+TXsGRf8iT993vHfw1jYuPi9cgy+g0izg7hQftthE9/I32AHqJbz j8xhmD8dc/zHn/r5C88BOPP9F/7Udv6xczH8iT/xJ/En/sQff+JP/PEn/sQff+JP/PEn/sQff+JP /PEn/sQff+JP/PEn/sQff+JP/L0tBkDxJ/4k/sSf+ONP/Ik//sSf+ONP/Ik//sSf+ONP/Ik//sSf +ONP/Ik//sSf+ONP/Ik//sSf+ONP/Ik/qY8/AMWf+JP4E3/ijz/xJ/5SVwj8qZO/EP78E/hTJ39/ /+FP3fw1GYD5U+H4+3cA5k/mH/pCf+0Ww5+K/Nn/qeP81/Gfuvoz/1Uff+En/tTRn+M/9Rx/+VPH +S9/6uYvBO+/qN/4m/j8LYTfw8PH5ZC44E9Vx3+LH8A9if1a/GE6u+BP7f2F0f6PPx06/oaV8fdJ LaQuRnfDn+a2cq40JPw95ycrBu3/VDX/TU+LR/6Mvzrq+G/5Sm/jb44/AFVw/Ld0/kvOGy+z91/4 0/7xt93nv/yp4PivBT/+VOAvND3/ij/xp5uNv+0Ww5/2zz+a/f0j/rTb3/L7L/zpJH9tBmn+xJ9u OP6a/6rn/MPnH+ror+Fi+FPR/s/4K8d/+sr5bzD/FX/6Vn/GX/Wc/3r/RT39NVsMf9rpLwT+1M1f mw8/+FOhv1YDNH/iTzccf73/Iv70lfPfpovhTz39ASj+xJ/En/gTf/yJP/F3mE7+tF9Y4E89/Q1N zz/gTzv3f00//+VPO4//+FPf+a/xVz39mX+o6/6v3fdf8ae9/hz/qau/NoM0f+JPxl/J/EN38ddy MfyJP/En8Sf+xB9/4k/88adr+Wt5/h+A2skr8Kee/gb+xJ++dfxteP4Lf+JPd5r/Gn/V018IQ+BP /cbfwfirfvPfdr//lz/xJ/NfKXv+Ecw/1M1f08XwJ/s/Of6T8ua/g/mv+NP3+Vv5/ufHz37+bO2C P7X39yT2+Hx45YI/Vc1/E7fiT6f4Wxt//zELqxfTe+FPm7QWhuCkv7Bl0P5PVfPfhFDjr04af/lT z/3fwi7w+VPvv6iHv9LF8Ked42/TxfCnnvs/AMWfbjb+8if+ZPzlT+f7G/jTMRvv3Pdf+ONvj7/0 +af88cefPn78bXL4xx9/Rf5C2+8f548/468K/UX+1HH3d7q/5ovhjz/+xJ/440/8iT/+xJ/440/8 iT/+xJ+u4++Azcef+NMt+PEn/vjj767+AOSPP/En/vgTf+KPP/En/vhT0l/7zcef+BN//GmLH3/i jz/++BN//PHHn/jjjz/+xB9//PGnQ/w13378iT/xx5/406X58Sf++OOPP/HHH3+38gcgf/yJP/HH n/b5a739+BN/4o8/8Sf++FOKH3/ijz/++BN//PHHn/jjj7+T/YV/PS6HxAV/n+Wv8Qas9Pd78ed/ ixf88Xfs/o8//jru/x7UQupiKpU//ma7r9o7SeOz/+Pv6PlvauA1/vJ33vjL37fwu9T+b+2NF++/ 8HfC+Lt3Mfzxx5/4E3/8iT/dyF/bLXi6PwD540/8iT/+xJ/440/86fL8+BN//PHHn/jjjz/+dJq/ pluQP/En/vhTYhPxJ/74+xZ+/Knr7i/yJ/74+9Kjv7jncJA/8cffJ81+I3/qx48/Xddfy03In/jT tfhtfOMGf+KPP/5u6A/AG/DjT139rX7jOH+tnmXxx98F+fF36LMMYL6/OPDH3+kDQ+SPP/4+0F90 BJhxXLzir+XvIORP/PF3OX+Lb0Xz1+pJ/lKAMeby44+/5vjWZ178nTjGxC/Et/G4+ePvWHyrjzsO 3+EvRv46HvTFTH9Lp2J9gr8HwV4K43Xm4V1mtfxNFPJ3ur/UA0+dZvCx/rog+D5/uaevxPw3Cvhr sTFim815O3+Jh5C43mf7a/JQ4qRj/d3u3IXc4TN1vXjoi7C7v+qHMhMXj/QXhw/wl/sz/na+tbB5 h9W/SeB2nx3Hgb/1xcQKfHufnFp/9/vsbtexXvarjb+1j9LjUf7i7aYguXPdo/3F6/ornAfEgnus /Can2Pzlfxl/cTjUX3LWdgV/pcdhZ/uLR7wBkT/Bb8gv9zORVv5icodxT3+bGyN+ir/RW0oFBKsP RGITfyuHLZfwVzwOVk/7YulS40n4siZcJU9UzGVa72/tsOUa/vY5iEMPfwd+Cfyex7mHYOYh8rrS an9x7SHdz18svlrVJ0mtv4Q2ll8hm2DeO/EbSmPT7RWv6S/7AcVYvoFr/DX+S7B/T4SPFY+zfAzY OZmPsfH+It7ZX6zaT7b1VwMwbj2aWPBUzObIsXhWsP2Ml+8Gpvd4FX9Zc4q6g++aV3LTk0A2z4XP e6Bjbk97ccccPeuznFp/W0/cZfxtPxG17z7EcvfVg1Bqi8Y62DHO9nsx/03ynM+yK/3FBjCu4K/F u6+xkH3dKPl+B3Hrke17qHFxHM5cucwrtR02rurv7Sy+8XYrPU0/6x27WGZvc+Y4egSvf1+6w+m1 mryvE2OzA5oaf3G4k7+0yIrtsH1eakxW8pJZuXH6Lg/461gNJsgbh6gZDTf3p4/vBv7C7RZrlS/g L/zJxrTKnfz9xfcC+PiX/xLVrOLqXYbVq+cs9uBVzrlpzirs/fne+2+0gfr5K3oGcqp4UivuvtUq t1qF1Esm/ykJTR/i+iqc5G80AAdpsQMP/4Zg2qteE+vJ+Cvxp68CiJ8kSZIkyWx4103Lbvy4Vdmt /92mbNE/tym/6emLrVru87224m107AchozUsv20p3OJFv25b+lhLlju66ZmLrVru66OuMrqnfExW 56/s1RGGcn9htP/r4a9mZ1L+sgnl+87Cxf7c9vC3iqdnI5xl9+mv7FmtWfRji5QOZsW77FD6cH9v W7TvLH60v7cdDh9/63azVf7CUOqvcNHPg6nicX+o2oeVj99DzS67eNivOsg6fvyt9jec7O857Sk8 EKv1N5zsr3z8HU08Lj7/6OSvxlDp8V/NYhvMP049ZKi87Tnvv5Te9vnqKn0vo8Ntaxbb4P2X8me6 6v0Xp6pIkiRJkiRJkiSpqIVPmWpOs5E2tE1V8acz/YVtf1l/JpX7G51bMjvXI7z+ihR/au1vdGZm 4hS7utP8pbURdcnf+w6QP53pb+Gwjz8dNv81/qqnv7X5x/h8e/4kSVLH/gez+y9nCmVuZHN0cmVh bQplbmRvYmoKMTY5IDAgb2JqCjUyCmVuZG9iagoxNzAgMCBvYmoKMzI4OQplbmRvYmoKMTcxIDAg b2JqClsvSW5kZXhlZCAxNzIgMCBSIDk4IDxmZmZmZmYwMDAwMDBhMGEwYTBmZjAwMDAwMGMwMDAw MDgwZmZjMDAwZmYwMGVlZWVjMDQwMDBlZWVlMDAyMDIwYzBmZmMwMjAwMDgwNDBhMDgwZmY4MDQw MDBmZjgwZmYwMGMwNjAwMGMwYzAwMDYwODBjMDYwODAwMDgwMDA0MGZmODAzMDYwODA4MDYwMDA0 MDQwNDA0MDgwMDAwMDAwODA4MDYwMTA4MDYwNjA4MDYwODAwMDAwYzAwMDAwZmYwMDYwMDBlM2Iw YzA0MGMwODA2MGEwYzA2MGMwMDA2MGMwYTA4MDAwMDA4MDAwODA2MDIwODA2MDYwNjAyMDIwMjAy MDQwNDAyMDQwODA2MDgwMjA2MDgwNjA2MDgwODA4MDgwNDAyMDgwMjA4MDgwODBhMGEwYTBhMGQw ZTBjMDIwMjAwMDgwODBjMDYwMDA4MGMwZTBjMDYwYzBjMDgwMDBjMDgwNjBmZjQwMDBmZjQwNDA4 MGMwZmZmZjgwNjBmZjgwODBjMGEwMDBjMGMwYzBjMGZmYzBmZjAwMDBmZjAwZmZmZjgwYTBjMGMw YTBmZjYwNjAwMGZmMDBmZjgwMDBmZmEwMDA4MGUwZTBhMGUwZTBhMGZmMjBjMDAwMDBjMDAwYzBh MDIwMjBhMDIwZmY4MDIwMDA4MDIwMjA4MDQwMjA4MDQwODA4MDYwYzA4MDYwZmY4MDgwMDBjMGMw MDBmZjgwNDBmZmEwNDBmZmEwNjBmZmEwNzBmZmMwYzBmZmZmMDBmZmZmODBmZmZmYzA+XQplbmRv YmoKMTcyIDAgb2JqClsvSUNDQmFzZWQgMTczIDAgUl0KZW5kb2JqCjE3MyAwIG9iago8PAovTGVu Z3RoIDE3NCAwIFIKL04gMwovQWx0ZXJuYXRlIC9EZXZpY2VSR0IKL0ZpbHRlciAvRmxhdGVEZWNv ZGUKPj4Kc3RyZWFtCnjafZJPSBRRHMe/syVCrAVlJlLwTrYHVwbtYB2M3fVvyrasa6YIss6+2R2d nZ3ezG4lHkKILkHWMbpY0Uk6hgcPHQIPEYJiXSLoKBkEgpeQ7Tczu+6I2oM37zO//7/fe0BdKG2a eoABecMWyf4ouzs+weo3UIcGBEErrVhmJJEYdplscWTtfYXknJvh4/X/XQ2CEgISVYDGrMfXHJ72 eMDh+7ZpE086rOTSGWKTuE2kkjHiV8Rnsz6e9nGGWwrxMvFNxRQUJ5AiHigpWSfmDrFsZDSD5JeJ uzKWkicm38BTZxZemfYQ0H0FOPW5JpuwgOV3wKXWmizUDFwcA1Y6a7LdpDsfqWndUjs7XJEUjAJ1 P8rl3Vag/gWw/7xc/vu6XN5/Qzm+Ax91pShKlRlJ0hfA68Ndjf3c4EJTmHNfCVFQNZ37Rnq82uvX i0f1Jat0EnszcVcXsET3MHYGGHoMvPwJXH0PXPgAJBqA1HUEHqG6bf7AzRMrmA+Fls3ZrEOWO1jY OTpZhF4IZ7FC3izaXLBBQ2lvY2ldZ66pxQS3uCjxTDvyerHa7znaQW6MjtBJ8wqo3OqtsDSTSffQ 3aCdeCPDe3qdd0G8qGp9g86F0P6kir5Rj6Xzmj2Y8jjQbejx4QrDKMRvezGxY9rRZDW+VRrprcpn 0rcSdLaQ/MZsYcixaSLf0FwuNeaxlJrLxeIVXsU4dHBoMOhrgCGJfkQRhgmBAlTSaGShkZS7NoLY wuyxljoSPmak3yafbdfnHork7XjdQTSOhbaDCEz+Jv+Wt+Ql+a38a7GlGKppFsSUpqw/+0NxnczV uBVtpSYvvkJ5I6TVkSVp/qAny1eprzrVWGypRXJy8CfxPV+X3JcpjGk30qybqeTqLPpGfNlOmh7Z rs2vNtdybZ1emdwMrs0fmlXhSFf8oKvD/zU7vz//B82wAWgKZW5kc3RyZWFtCmVuZG9iagoxNzQg MCBvYmoKNzA2CmVuZG9iagoxNjYgMCBvYmogPDwKL0QgWzE2NCAwIFIgL1hZWiA1NCA3NDIuNDUx IG51bGxdCj4+IGVuZG9iagoxNTUgMCBvYmogPDwKL0QgWzE2NCAwIFIgL1hZWiAxMDMuMzA4IDUx Ni4yMzcgbnVsbF0KPj4gZW5kb2JqCjQyIDAgb2JqIDw8Ci9EIFsxNjQgMCBSIC9YWVogNTQgMjI0 LjA4MSBudWxsXQo+PiBlbmRvYmoKMTYzIDAgb2JqIDw8Ci9Gb250IDw8IC9GMTUgNjMgMCBSIC9G MzcgODIgMCBSID4+Ci9YT2JqZWN0IDw8IC9JbTUgMTMzIDAgUiA+PgovUHJvY1NldCBbIC9QREYg L1RleHQgXQo+PiBlbmRvYmoKMTgxIDAgb2JqIDw8Ci9MZW5ndGggMTI1MSAgICAgIAovRmlsdGVy IC9GbGF0ZURlY29kZQo+PgpzdHJlYW0KeNrFVsGO2zgMvecrfHSAsUeyZTvaW3fTGbQosO0iwB7a HpxYkwi1rVS2Z9q/X1KkM8lMtntcBIgkiqLIR/LJItpHIrpf/L5Z3N7JIpIi1ULLaPMQFSqqVJkW sow2TfQ5ftcvs1U8Gt+bMVn7+mFcJjrLddzgPBm9PdbjwSbetW3ij20y2A5PTG09WtcnQi6TVVXq eG12BnaqeLtM4N/4ZZLnKs6E0Muvm/cLwT7N49vNQsJERDKS1SpVSkZFVqaZqKJdt/i+EKkqiqIK KufzsDmfZMHtu66M1m7xCX6z/Vklma0nZ+avACPzIl2JPCpElpa6IHTu7H7yBiPJ4/K3ZaJUEb/p 3ESgkdw90NjUY00x131Dop0jRQCPBMd6hxB9Q6kZBxKOvu6Hzo6jaej8g/O00zvAchU37IHM0qtQ /gLSTOu0LMoZ0lyXEDVB+jz/F0ir/4b0zPwvIM2qMpVKvYa0+t8hVfl1SKOkVOmqrCLQSoV4WQ5a xRqHPB4ODm9+Gkg6Hnj7j/UdKYRYcMd2vDUcqUN69HskrS0a+Un7dX+2CP5W5C8sn+x4cNP4ShEc Mf7R7swNICp0/HQA8+cevQSKZL4e2fCDdx0iAcktU52XMOZpoTQFTkaUjCFMGbtpKWO/MzgfSG7D mMU1LcNdK7yrortAZkh2IEUp2KCBjDbDDa7mNIO4N0+kt8Yzb/DvngSD+T6Zfsf+BAynwEjbkNjA O2cO2WGYDBs1jyF2//PShc4GHKfRDCmgB1y2OcBxBEMQDJz+Y+swlhJwM1+ELMwu1BusCR+YHL07 sh/jnJySiwDGvz5+oAnmcYlIssE6BMLaHyjnu7rlU+ZYW0/zISQRzwb4OwMuF1DIf1PC0VTbvnSq 9oa6ht39IgpBUKNFu21tvx9AKM+DnnNfezYzmo4q1/na25adnXo/Z7betqwaqglmVBDlWdthoisx +5bNbVHmc/6gU3nLMjYHU3t2vKad9bs/X93TO7DpX9zGhoY5azvnG9PcXAvz6WDn+lRCxnv7GIp3 oGXwN0yCvzg7tSIuuPsgGaVa4aNKUkfKGeRyMFjkSkIWsLrC/uOyKCBfkMyJ9Tq7PzARBi8cjdOR b3cX7rxoD9yZawXnG/DVX4sV7i3h3ilkA9iRn+wdVlSNzR3anCmSmdm2TLjMyJQDWFvmXExTwwYp vSCEyvrGnD6N9d6cH0FyY8IfXEu92QQ6jmYOyqpU6BU5vQk2UQl6L4feo1VoLSTSefuSMWA4tQ9o bTAwCxF2IUKWup40uRhB8jTrzXQLu5xjWoQQQBE5gV4ZFLKd8E5Qi+JSCoQlC6zsWcbuVhD6hFT6 inqZc5ihlWDQNHxRMWfevmJ00AIikXHDJ3oan59cHUt5Q6w3+6LmZoQJ+xIUBwNXsE0ankn9+boL ShVEqeFw8DDQqQrtgNLTPb35MV6rS28e7QBflaFRikse1Po5kXoVeBCa1dCjCtBSferTO0AL2x1b 0OGnlkmzob26df2epoGOw4wYGgxiq6Fg57ojUaCes6b1WS2A9FTaeAxL6Bq90A1Q6/et24aIoAFO EeX5WUSXnyRoqaxSjd9UoQ+WK6Ay+iy/oaOG26huAXEpV5WM3/44Wm+4Nd9PveHPccVHMoG5kioX Kv78EW/m7lSQxK8XDsBn5T9pZR43CmVuZHN0cmVhbQplbmRvYmoKMTgwIDAgb2JqIDw8Ci9UeXBl IC9QYWdlCi9Db250ZW50cyAxODEgMCBSCi9SZXNvdXJjZXMgMTc5IDAgUgovTWVkaWFCb3ggWzAg MCA2MTIgNzkyXQovUGFyZW50IDEyMyAwIFIKL0Fubm90cyBbIDE2MiAwIFIgMTc1IDAgUiAxNzYg MCBSIF0KPj4gZW5kb2JqCjE1OSAwIG9iaiA8PAovVHlwZSAvWE9iamVjdAovU3VidHlwZSAvRm9y bQovRm9ybVR5cGUgMQovUFRFWC5GaWxlTmFtZSAoLi9EYXRhXzFoXCgyXCkucGRmKQovUFRFWC5Q YWdlTnVtYmVyIDEKL1BURVguSW5mb0RpY3QgMTgzIDAgUgovQkJveCBbMCAwIDU2MCA0MjBdCi9S ZXNvdXJjZXMgPDwKL1Byb2NTZXQgWyAvUERGIC9JbWFnZUIgL0ltYWdlQyAvSW1hZ2VJIF0KL1hP YmplY3QgPDwKL0ltMSAxODQgMCBSCj4+Pj4KL0xlbmd0aCAxODUgMCBSCi9GaWx0ZXIgL0ZsYXRl RGVjb2RlCj4+CnN0cmVhbQp42itUCFQoVNAPSC1KTi0oKU3MUSjKBAqYmhkogKCJEYROzlXQ98w1 VHDJB6oPBACUgw3wCmVuZHN0cmVhbQplbmRvYmoKMTgzIDAgb2JqCjw8Ci9DcmVhdGlvbkRhdGUg KEQ6MjAwOTEyMjExNzE0MzMtMDUnMDAnKQovTW9kRGF0ZSAoRDoyMDA5MTIyMTE3MTQzMy0wNScw MCcpCi9Qcm9kdWNlciAoTWFjIE9TIFggMTAuNC4xMSBRdWFydHogUERGQ29udGV4dCkKPj4KZW5k b2JqCjE4NCAwIG9iago8PAovTGVuZ3RoIDE4NiAwIFIKL1R5cGUgL1hPYmplY3QKL1N1YnR5cGUg L0ltYWdlCi9XaWR0aCA1NjAKL0hlaWdodCA0MjAKL0NvbG9yU3BhY2UgMTg3IDAgUgovSW50ZXJw b2xhdGUgdHJ1ZQovQml0c1BlckNvbXBvbmVudCA4Ci9GaWx0ZXIgL0ZsYXRlRGVjb2RlCj4+CnN0 cmVhbQp42u3djY7rrLkG0Ln/m3alttoaTWKM+X2B9ejoaHe+JAYMrGA79nWJiIiIiIiIiIiIiIiI iIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIjIbX5+fh7/UvxRDQvZ9sMzP63ty9qW/PMfZeUsK3xN t3m7xa/beuwSv/9r4pU1+67Tx47pyTltWFm1/B00uDUkskd/dmI0jyb224AeJWAa7FFxt3n1yvSG 7j7qd+OkZ93KfTd9AnwsQHEbBpGURweuj772z8QfE6/52vn//PFzo3cvvptP8reVKMBn+RObvpvW fr/ss3HuKv61hHftc/cJv/NY/bRHd+3z+K67t2QW4+1KJ/M/5VtZ0Gnfgvi4wM/stK96VH6D5Ozf 9FRQ0AiP/fbrgHrsPDw60KM/vevrjJ35ITnHWBIK5AOaVvXxvY+FSZQqv4kyGzmnbInPLG7J+q8x OU1UjE7ZscSyTpvZPol35ff5slLVe5TTA2vGRWVr588VspxHZfNbJQeVHuVPCG8PN709R5Nfr8wK vmrtgvYvmw+bdJtXWyk7zPjWo8rS5ne/Tj25oE2a7N/KRujd2rK0R68W6W+/53wuzzt5lLmtxJGQ xBezV9w8Fibx4cUe5W+xEuLibvNY4EpfVvToayPk9+QNPHqs7NcDzvkTi/Co4MttpUdv3/5qrq6Z fDKHcOWyqPLrd7ozdPLobRe98s7gL7o+6nGgYK31UbrAr8aXrO5R4kjvq7MeY47XNTlSVPOyVh41 /8dVff7olUfXm6P99eePJnrUaipuCOIJx+vyq8CjzTy6O46U3z9fXd6WOHyR09XT23q8eufuuMHd NJuYnNPHE668K4XezgaPly2li5duyaviHE3X6+sej/LVe3S9vDayxqMr41K6tz05s01eHYLu4VFm vXKqkP76JDKYUdHIXUve8NdbImKqlENamEciYrbUvLtWoeGdtURERERERERERERERERERERE5G0y f/eXf3d6ERGRtxK9/d339f6eISIiImXrIx6JiEgEj/JvvJbw6EdERPKebyKPS5uae/zGb3klPKGE mlEJFZJHOrAS1n3y//9PMyohj04+XscjJeSRHa2EPOKRvqGEPFJCHvHo318yf2r06vFkIlM8EuGR ltcIwqMeI0sWvaDOrMgj4ZGRJRF2ln1n1AiPjCzhkR0hwiMjy86y74wa4ZGRJTwSLS88MrLsLPvO qBEeGVnCI9HywiMjS3hk1AiPjCzhkWh54ZGRJTwyaoRHRtbEUr16yk9+LeqfH5T5rh4NyyOjRnh0 2sj611wj/69m4n3lUeXEwiPR8sKjYz26Pu7//3t1k/6f+VN65k2e7x5JkF8GHvFIeKQTrTKyEh6l aUg/tiYxpb99Ms7dhr6+l0dGjQiP9vPoUZPHtzyeP3r82LdPeeORUSPCoy09+gQl/V8z65v+2LRH me/lkVEjwqNtPGp7vK5gjZM+Xte1YXlk1Mg2GOlEi3qUf7Kmn0eJbTleZ9SI8GhjjxKH3X7//d// /3ptW+Z5qMQbE9fXPb7M9XVGjQiPjKwTdpZ9Z9TI0h7pR0YWj8SoER4ZWcIjo0Z4xCMji0di1AiP jCzhkVEjwiMji0di1AiPjCzhkVEjwiMji0di1AiPjCzhkVEjwiMji0di1AiPjCzhkVEjwiMji0di 1AiPjKy2Zat58Hf+u4qf3NekAMXlNCsaNcKjo0bWTzINX9l87q33aEwBeMQj4ZGE9ShdqrtnQKSf OpH5CImcyT9dqc+3JN779X/yiEfCIyMrfqkSjx+6UyDxZPMCj94+ua/gYYI5Dw00Kxo1wiMjK6ZH OfP8W48ezx/lfEJ+4XPWqmZFo0Z4ZGQd6FGiDJ/H2TI9Sr/X8TqjRnhkZPEoswxvP+HtiarL8Tqj RnhkZAUuWPHpm/EeZZ4Ycv7IqBEeySoj6/HyvEcjPlcoV+n1dXefkHnZXvplrq8zaoRHYmStu7Ps O6NGeGRkCY/sCBEeGVl2ln1n1AiPjCzhkWh54ZGRZWfZd0aN8MjIEh6JlhcedR1ZslDMijwSHomY FUXLC49EzIpaXngkYlYULS88EjErannhkYhZUbS88EjErKjl956TeSRiVhQtzyMeiZgVtTyPeMQj MSuKlucRj0TMilpeePS/ivNIzIqi5XnEIxGzopaXkz36XXEeyU5Dxqyo5Q0uHokhY1bkkX7OIx6J IcMjLc8jHgmPzIrCIx7xSAwZHml5HvFIeGRWFB7xiEfCIx5p+f08Oq0L88jUzSPR8jyK6ZFBzCMe iZbnEY94pFJmxZrK/vw3Wp5H67b2xtOmqZtHR2EUoe484hGPdGmV4hGPVnfh5Acu8MjUzaM9SAqC EY94xCNdmkcne6TlecQj4ZFZUXjUY07mEY94xKNFCfgTLc8jHgmPeHR4TXnEIx7p0urFI+XhEY/k KI+WOOV65u9hFYZHPBIemaIn1tT5Ix7xSHjEI+ERj3ikS/OIR1p+s37OIx7xiEfrzvyO1/GIR8Ij HgmPeMQjHvGIR1qeRzySsv68TdvyKGBlHa/jEY+ERzxSUx7xiEc84hGPLr+H5RGP5GXX4pFZsV9l Ha/jEY+ERzxSUx7xiEc84hGPLsfr+nfyWR4dNSHzSNfi0QYYOV7HIx4Jj3gkPDJp8IhHPOKRlucR j4RHPJLtPRo/eHnEI12LR6LlecSjvduWR2ZFHvGoZk7mkfCIR8IjHs3y6Lp4xCMerTf5h7rYm0c8 4hGPeHSgR3d19PsjHvFIeMQjHvGIR5UTJo8G9CsemRV5xCMe8YhHPNqVJOePeMQj4RGPhEc84hGP eMSj5k30dYWV/0ce8YhHPOIRj942zldiPv+d/0ce8YhHPJo+VHm0x/qIR9M9+rMtHhnEPOLRcsuc sksa+nkU5+IKHvFIvvYrHg2enA9c41gfNR+/POIRj3x1tD7iEY94JMUNyCMerWsZj3jEIx7xiEc8 4hGPeMQjHvHo91/8/miiCzziEY+W+OrIo3WZ4xGPeDSsAT8b7fOPPDIr8ohHBds9pCPfeWQc84hH wqNZHp05IfOIRzzahoA4v73axqPxg5dHPOIRj6xHtDyPeMQjhzLMijziEY/u5kweVXqU+COPzIrb V5ZHPOLRXI8eexGPzIo96lhzP1UtH80FHvFopEcbtC2PhEc84hGPeMQjHvGIR8IjHi1BwPSK84hH PJo4LfOIR6Fq6vzRHh5dF494xCMe8YhHPOLRwh6l7zrFI7Mij3jEIx71bj0e8Wh6ZeM8qH31lp94 owAe8aiTR4+dnEdmxUPWazziEY/Gr+h5ZFZUdx7xiEdBPErf0Y5HZsVOlXW8jkc84hGPeBSkpp// 0PI84tGxHj3e8ZtHZkUe8YhHPOIRj3ik5XnEo6Naj0c8mkiS80c84tGiPY1HPBItzyMe8WiDbsMj 4RGPeMQjHvHoX2X/HalzvI5HPOIRj3g0t6auZ1h9YuRRzh95xCMe8YhH1gg86uFRfR3T6PCIRzzi EY94FMGjrkszHvHos7LuF7Q6Cns/F4BHPBrmUcB6ub5Oy/NouZmZRzzikWh5HvFoFkbjPZretp0q ziPhEY94xCMe8YhHAzwaM3h5xCMe8Ui0fISJkUc84hGPRMuv6NFOVB3rUas6FnzIBh5NvJUKj9KV jXPJN494xCMe8ehMj6LVlEc84tFbj5rMzDzikZryiEc84hGPeBSwsjziEY9GelT2CRPbttWFHDyK iZHzRzziEY9W9KhtxXkkPJqyaR7xiEc8Eh5N33TDn67wiEc8Miu2qqPjdTziEY94FLnPWB9p+RU9 yvx721/382iiR/XVrPFoSvPySLQ8jzQ7j3hkVuSRiZFHPOrq0RjFeMQjHgWZGLvWjEeHe1RcUx7x SDb2aMrg5RGPeMQj0fI8OnZZGqG+POLRlgRMv9ibRzziEY8yC8yjvTGKUHceDdg0j3jEIx7xaOOW n3uzuAKProtHm9SXRzzaiaQgGPGIRzwq2NfnePR7uz0udOeR8IhHw+rOIx7xaKH53/G6vT1qOKJ5 xCMemRVb1fEuWp5HPArYkXj02XvbVpxHasojHvGo3qOymvKIR8IjHvGIRzzi0Wdl/x2mc30dj3jE Ix7xaG5N/f7oWI9W7+w8qplI1/XounjEIy3Po3M9GrYrecQjHvGIRzziUdc3NtzXnTyKNiLOPH/k fqrneBR59J3sUc59BXnEI9Hy+3l0XTyK69HdVnjEIyJo+bAevdo0j3jEIx4toY/jdTzaxqMetZvu UduH4Y6/UJxHPMqsbIRab+lR78GbP321fVQBj6J59LZga3k04EEbPApS3yBV5hGPlvCoU6PxiEdn euR+qid4dF08OsKjssryiEeysUdTBi+PeMSjJhXnkWzQ8mW/GeHRWh7lXPzGIx6ZFVtV1vV1PNqp 5Xl0gkcNLyzkUbSaOn/EIx4F96hVZXnEIx7xaK5Hc2cVHvGopnGalJ9HPOLRxDn57oFHPAro0XXx iEcnenS5nyqPeBTDo5xHJfKIR6Ll9/Zo3f7Oo5r68ohHROARj3gUx6NWOoz36Lp4tCFAjtfxiEdB PMqZMHnEo71XQ54Pu71HX1/GIx516vM84hGPeMSjMR41bzQeFQvSsPA84hGPeMQjHvHocI/+SOT8 0Wke9SvbmPmKRzwq9mj8UOXRojjyqJNHw8rGo+YeNe9mPOKR8KjfPMaj3h71azQe8YhHrvfuLQKP eMSjTp2cR3uvR1zP0GNgjrnpGY949KpgPOIRj3jEIx49lrbsYsgzPSq7cR+PgpMU+Xhd2CuTeXSC R3821O9J6Dzi0cnro0R4xKP6Zum6y3jEIx4Jj3jEIx7xiEc84lFwjwY8uo5HPOKR8GhLjzrNrjyq 9Cj9l4keDZ66eSQ84hGPRnr0dsVUU+X6vbOxR6HmmRM8illHHnX1aFjZDvGo08XkPMovKo928iha Te/KM2Zy6zcqeTTRoyYF4BGPeNS7mkEu837lUbyju6E9Gjlp84hHS6yCeRR5lbTW+ohHPOLRgR41 LAaPZEuPMovEIx6N9CinYDziUUwC4t/fm0c1n8yjfl7wiEc86ldT5496eHRdJ3o0YMra2KPrKlmR 8YhHPOIRj3jUvBZlRwh5xCMe8WhRj65reY/6Tbk84hGPBlfW+SMedfVo+rNxebS9R60ejMujjVH7 ylzCPh7xiEc86rqXxx++5lGEFvv6pL/04//SHl0Xj3j0ruQ84hGPeHSURxMHL48GePS1FjziEY/C evT1YF2BRzcfxaNlPPq9ue096vFj28qW5NHqHoW6h9s2a6VW66PPUcmjHh71+LbPo5pa8KhH77U+ im8Hj3jEowM9GtP5B+xiHiHp64ec49GrrssjHo30qOGdV3nEo2E1bXKscrBHQfbPKh6N+ZCvNeUR j3jEo4m0lf2RR1t61HXWyl8bLurRdfGol0djxgKPVkeNRzw6yqPMh801f7ARj3gUfF0T835BPOIR j3jEo3PWI1/P7wT06Lp4xKM5Ho3Ersaj6xrqUe/B2LwuPOJRvUeDv5U1J4ZHPOIRj3jEIx5N92ju te6re9T2kBSPeBSZpODPm+ARj3jEo2EjkUfCIx7xiEdlm2h7JpdHwiMeLepR18bnUfN78fEoOAGR j9d99jQe9ZgTeHSURwG/xvCIR/lPIOJR5WDkEY8GezTgrD2PeMQjHvFoM48e68gjHp1GkuN1POpR nqU9SmyFRzziUas63oVH/TxqXvLejyjl0VyP/pDEIx5JQI+m76K3ZeARj2qqwKPBHkV6zhqPeMQj HvFopkfNH7HBoyUIiH+8LmBv4RGPeMQjHm1cUx7xiEf1Hl3XPh417708QhKPjvJoZN3HeNTp83nE Ix79qazjdTziEY94xCM15RGPeMQjHvHoWvB43XUt6VGnYvPoHI+aF3sbjwrw4lFMjCIfr7vrGNN7 S48pYiIiPJo1sff26PG2eDzikfDoKI+6rg15tKVH/e5/wiPhEY94xCMe8ShdU8frhg1DHvGIRzzi 0SoV5xGPDvSo32J8dY96dGAeIanGo5GjgEc8GuZR5nt5NLgxecQjHs316Bpyax0e8YhHPErUNM7J Ix5F8KjTr2l4FNCjCN9heMSjVVZnXZ+DxqNzPOp3vQGPVvRo5LDiEY94xKPDPUq3eXCPiu+PxKN1 Z/74zyvn0WYeja/+Bh716KU84tFyy5ONPRpwmS6PInhU2exdveMRj3iUWC5Fa/mYHvU4fsKjRT2q /HLSdcwNOHzKIx5tXN/fJRnzXM6RrJzs0cTqR/69aufRtLZHs7488OjwZRGPeHSUR2Omu/TtTXb1 qP76fx6p5kiPfmPEo7tmaT4h8GjwdMcjHq21Mop8fV2/56BVTry7evS1ZZo/k3T8rDXeo0TrjZzr FvWo09chHklwj66LRy295tFX0D+pGjWaBnkUpFfzSHi0n0fFn3+4R+mF0vhZjkc8klU8Ku5753h0 XTx651HZC9b1KFSv5pGc5tH4X9FG8ChzEyM9avi8mybkjd/7POKRrO5R5SH90zx6VexjPYo6mnjE I+HRiR5l3uqNRzyauL8G9BkeHetRky9RY2Y2HvFoFkk84pFM8ajshsw8GubR+LtJ8Ohrb4/p0Zj7 sQcZWTziUeJdPKrZypintfKIRzySwS1f/GU78+LbKXMpj9byKNp5bR5Vvv1tn+ERjzI7eZlHNWd4 j/Xouo72aPEBxaOSovJI6j16/CF88R34m/TPxKZz3ssjHvGIR3KOR13vTV1zgHHAxMIjHvGIR9LJ o1fXLQzz6FWZM/8rj3jEIx5JTI+uq6VHrTpn4qe4d/eFzrlZ9MQn6fR4TSePIjxffiJJa3nU6RN4 JOM9SnxCzTV7PabQnNtBJ261N/1JOgVDuB/uzTe6k0f9vsaEekIxjySyR6+GYW+P7gD6Woacr7Xj H6Yzd8FS8yFhnyrOozEeDfgCw6NjPUosLmqGYc5RslaDJX2EsIyzJTxqMt6LfRlzr0IezfWo8i5J PJK2HtXM3v2eofZ4RDF/mAweMj2uVej6S/z6je7hUc5ICULSAI9GloRHPGri0ZiRu6JHzW+XOuXm CQW9a6clUqdePficII8kvkePwzDIN9WaM+w7eVQJWT/LeDR+idQVNR7JAI8S3MT3aLxoAT2asnQd eSvyczwafEKQRzKg5csu00p3wiAdrJVHPc5t1czh46ejID+cXIukrrXr+g2BR7KQRzm3V43jUZNj TZt5dE26Qu8ojyq/C3XdKV0v+Rv8bYdHPMrxKM600GQpMcWjwbew6Dd9Dfi5GY/GY3RdM++sxSMe 8Wgbj66X93noseLb26Pe3SbCrTB4JBE86kcAj4Z5dHW+diK9oc2uZBjfbQo2MeD3UEvvUx7xKLJH syo1zKPrGuTRNfWWF1t6dAW4DwaPhEcjvwrOqtRgjwqenFi5IR4N7uRjLj7nkQzzKPN5dqHmBB5V bqvHhjY+WDe424y8LoVHspBHoeaZPTyqvFllzba6Tl97Y3SsR6vvWR6t6NHgYwITMZpYqZEeXQNP BPBoSlfvfeU5jySgR9FmAx7VTCzxdw2ProtHPOLRUW3Fo9Hzp27TcEPD9iaPpLjlCx4zyqPx2x1Z mJP3Mo+Cf43hEY/MVNM9Gvn7dx4t2m0mXvXKI2noUfA52YQ2+H4s9vK6Ho25aP/u8zeYInjEIynw SHiUs61hv8nlkfDokDnNXuBR2cJ25AXnPBIeHUWSvSA84hGPzIQRvmbbC5I/QscfLeSR8Oicr772 guQvkXjEIx6JIS/TPZpyNcXqPZNHPJLTRr307iHXNeFSCh7JMI+ER7LQEolHPOKRDPsCLBKEBh4J j3gkwiMe8UhEIpO0PYI84pGI8IhH0sMjEZGGJPFIeCQiMOIRj0SERzwSHokIj3jEIxERHgmPRER4 xCMRER4Jj0REeMQjEREeCY9ERHjEIxERHgmPRER4xCMRER4Jj0REeKTlvykWTrIfuIoIj0716GtG GpGz9bd6vnpX/tZ7t5JBFOp7UWbnWb2CxVWI+Z3WUIrT8ok+VjnTpl/T6jPHvDL94gHlLNaw1beL Hq+8q1q0/V7wLSjnlY8r/cxXPg6u3j3k8fMTbRhHAR5F8yizq4Sa66LNtG8HfuXWF/V9v1e+6qWf 03XN1n+eMr2V0qXl0VEHEHJa/u23oJoi1Y/3VscZiteG43tv2RHI/De2PRrTluzMvpQ/1eRvtGCB kH9gqnKpUjZ4y1Y9NcfPE4OFR2eugPJbPsiXloBXTSzXe5cYX5qxfrj9+eIx66uvrijNPdI3lFAh lVBXlJEeiYhIwDNZp3kkIiLCIxER4ZGIiAiPRETkTJKcpBMREREREREREREREZHHBDyvlH+DylBl Drhn08270H7XFbWhQX0CRtEaf7lbGy03scd/3IyuqA2DDCJG6MArduC11kcLdcuwRQrejNqwvqg8 4lH+rfYM/2KPPJezvkiRu+IqRQo+nHnEo/wiOX9UXySsb9mMKxYp4JOPeMQjHh07ka47q/NoG4/c ykbj5xcpbG9Z9PyRx3E2mT/NpdsMZ0+d0IF5xCMeGc7WmLLE5cp//u16hoIiBW/DgF9KvxZplWY0 nHkkIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIi8dPqJsl3zynQwiIiUuxIww9BkoiI5Djy 76ZkfxZKd+umr/cx+7zRGY9kia9SIhJwUP/+xz+SEjYV/FGERyLyyqPHf7yix7whnZb22kHkZI/S T3b4OlGYN6QHRkgSsT7KWf44XifDuq6IHO6R80fCIxFpO6jvLlrIfNaq43UiIhL/myqMRESERyIi giQYSZOO5FI6EREZLNHjrT+0koiItF343OHCIxERGUZS/glHHomISCeS0qzwSEREeCQiIodg9CgL j0REZAxGaVx4JCIiAT26/P5IRESkOv8BgUWQWQplbmRzdHJlYW0KZW5kb2JqCjE4NSAwIG9iago1 MgplbmRvYmoKMTg2IDAgb2JqCjY2OTIKZW5kb2JqCjE4NyAwIG9iagpbL0lDQ0Jhc2VkIDE4OCAw IFJdCmVuZG9iagoxODggMCBvYmoKPDwKL0xlbmd0aCAxODkgMCBSCi9OIDMKL0FsdGVybmF0ZSAv RGV2aWNlUkdCCi9GaWx0ZXIgL0ZsYXRlRGVjb2RlCj4+CnN0cmVhbQp42n2ST0gUURzHv7MlQqwF ZSZS8E62B1cG7WAdjN31b8q2rGumCLLOvtkdnZ2d3sxuJR5CiC5B1jG6WNFJOoYHDx0CDxGCYl0i 6CgZBIKXkO03M7vuiNqDN+8zv/+/33tAXShtmnqAAXnDFsn+KLs7PsHqN1CHBgRBK61YZiSRGHaZ bHFk7X2F5Jyb4eP1/10NghICElWAxqzH1xye9njA4fu2aRNPOqzk0hlik7hNpJIx4lfEZ7M+nvZx hlsK8TLxTcUUFCeQIh4oKVkn5g6xbGQ0g+SXibsylpInJt/AU2cWXpn2ENB9BTj1uSabsIDld8Cl 1pos1AxcHANWOmuy3aQ7H6lp3VI7O1yRFIwCdT/K5d1WoP4FsP+8XP77ulzef0M5vgMfdaUoSpUZ SdIXwOvDXY393OBCU5hzXwlRUDWd+0Z6vNrr14tH9SWrdBJ7M3FXF7BE9zB2Bhh6DLz8CVx9D1z4 ACQagNR1BB6hum3+wM0TK5gPhZbN2axDljtY2Dk6WYReCGexQt4s2lywQUNpb2NpXWeuqcUEt7go 8Uw78nqx2u852kFujI7QSfMKqNzqrbA0k0n30N2gnXgjw3t6nXdBvKhqfYPOhdD+pIq+UY+l85o9 mPI40G3o8eEKwyjEb3sxsWPa0WQ1vlUa6a3KZ9K3EnS2kPzGbGHIsWki39BcLjXmsZSay8XiFV7F OHRwaDDoa4AhiX5EEYYJgQJU0mhkoZGUuzaC2MLssZY6Ej5mpN8mn23X5x6K5O143UE0joW2gwhM /ib/lrfkJfmt/GuxpRiqaRbElKasP/tDcZ3M1bgVbaUmL75CeSOk1ZElaf6gJ8tXqa861VhsqUVy cvAn8T1fl9yXKYxpN9Ksm6nk6iz6RnzZTpoe2a7NrzbXcm2dXpncDK7NH5pV4UhX/KCrw/81O78/ /wfNsAFoCmVuZHN0cmVhbQplbmRvYmoKMTg5IDAgb2JqCjcwNgplbmRvYmoKMTYwIDAgb2JqIDw8 Ci9UeXBlIC9YT2JqZWN0Ci9TdWJ0eXBlIC9Gb3JtCi9Gb3JtVHlwZSAxCi9QVEVYLkZpbGVOYW1l ICguL0RhdGFfMmhcKDJcKS5wZGYpCi9QVEVYLlBhZ2VOdW1iZXIgMQovUFRFWC5JbmZvRGljdCAx OTAgMCBSCi9CQm94IFswIDAgNjQ0IDQ3N10KL1Jlc291cmNlcyA8PAovUHJvY1NldCBbIC9QREYg L0ltYWdlQiAvSW1hZ2VDIC9JbWFnZUkgXQovWE9iamVjdCA8PAovSW0xIDE5MSAwIFIKPj4+Pgov TGVuZ3RoIDE5MiAwIFIKL0ZpbHRlciAvRmxhdGVEZWNvZGUKPj4Kc3RyZWFtCnjaK1QIVChU0A9I LUpOLSgpTcxRKMoECpiZmCgYAKGJuTmYTs5V0PfMNVRwyQeqDwQAlcwN/wplbmRzdHJlYW0KZW5k b2JqCjE5MCAwIG9iago8PAovQ3JlYXRpb25EYXRlIChEOjIwMDkxMjIxMTcxNDQzLTA1JzAwJykK L01vZERhdGUgKEQ6MjAwOTEyMjExNzE0NDMtMDUnMDAnKQovUHJvZHVjZXIgKE1hYyBPUyBYIDEw LjQuMTEgUXVhcnR6IFBERkNvbnRleHQpCj4+CmVuZG9iagoxOTEgMCBvYmoKPDwKL0xlbmd0aCAx OTMgMCBSCi9UeXBlIC9YT2JqZWN0Ci9TdWJ0eXBlIC9JbWFnZQovV2lkdGggNjQ0Ci9IZWlnaHQg NDc3Ci9Db2xvclNwYWNlIDE5NCAwIFIKL0ludGVycG9sYXRlIHRydWUKL0JpdHNQZXJDb21wb25l bnQgOAovRmlsdGVyIC9GbGF0ZURlY29kZQo+PgpzdHJlYW0KeNrt3Y1u67qxQOH9/i/tXqBobhBL FMV/Dr+FosjJdmxyyJklUrL0+QAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAKAx//79e/xN8Vs1bGTbN898t7Yva9vy7x/K2lnW+JppU/CJf/7k3/9IBCcxZ2rGK/G3 w6ZB8bRMh6XJkKVf2SNEI7MP6JrX34VuqaSYmL8Lujgh5cEuLp42bz/xz2c9/nz3glbjNb34Pzbg 0rmPYVnnKIKLcey6OL+m/Xn992sui8BlOb2rk79fnF4B5XxWogHf7U989N2C4vfLvoNz1/HLFt7F 5+4dfvPY/bSYMn2XM21eNeNxpZZoebF2CyZqjsi+cyTdr8rZ+7jCfevix1mX89GJVz7O1cskepww XIxjXfwnyy5tlfkmOaU1YcD8g4f0EcXj3z42JtGq/BBlBjmnbYn3LI5k/SFcTogyXZxTkBPvWTBR 8z/u7q8KlvOvWlXv4pxZV5MLldHOrw/Api4uq+2VKqx0cX5hfLvF+vacbH6/Mjv4KtoF8S/zQpNp U/kp+S/IlFRZC/Nb22n2vu1mqzGtDELvaAMBXPxqk+rtse739lQnF2d+VmInMHFw/tYIj2/4uMp7 +0P+J1YehBRPm8cGvzJOIvKv5vx4F192PH/2BnDxY2cvt0TyiwnAxa9M2tDFb/+8YJOzrAhnlrLK 5XDlEiw9GTq5OD0z848uXp1AXGpd3GNTaK91cbrBr3IKiOHiz/1ZnldnOT9D9qib7I7WvKyVi5v/ 8Kk+X/zKxZ83Z/reni9ucpBT4+JWGmp4MHDCHnV+F7gYIV18t3ean6evLmNOrIZyUj79WY9XbN7t m90p5vFaoMfGtN2jfrxUNd28dCQ/L79L2+k66oT6c85TlJ3gyJlmNS7+ZFwy/Xb2Zo7Rq1MtPVyc 2a+cLqQPFwFMOYTA4UEe9t1Vcw8A1EMR5mIAYArhPaTZDe8QCwAAAAAAAAAAAAAAAAAAEIac2wsU P7wbAAA8irj+aSwAAKBmRczFAAAs5eK3t439BwAIB0WOFPGn9MHxAVbKWq7xWq7xWh6v8ZvGmYu1 XONHttyC65C1oTxFQTVIaJeLtVzj27pYCTphxOUpmqyRuVjLNZ6L1UZ5iikxf3w4uCEDVDkjpe8w ZICUgZHSdxgyQMoYKX2HIQOkDIyUvsOQAVLGSOk7DBkgZWCk9N10FQRAyhgpfYchA6RMZate3W8q vxf1d7LK/KvmgeViGDLgqJT5v98N/l+6VY95/crFlRWDixV2GDLgQBd/bp7glvOf+S7OvLPQ3T0A 89uguOm7IQOwfsokXJzW4qsHoOe/7fcvX92tV3HTd0MGIJKLH036+CeP54sf3za9uOZihR2GDAjv 4sdnupXdsj79tmkXZ/6t4qbvhgxAABe33aMuWNum96j7BZaLYcgAKTOxVfknZ/u5OPFZ9qgVdhgy IKSLE1vNv3//8/+X1zC/esT55R8mrqN+fJnrqPXdkAGQMkZK32HIACkDI6XvhgyAlDFS+g5DBkgZ GCl9N2QApIyR0ncYMkDKwEjpuyEDIGXijdTd8zXMUhgyQMqAi81S0xWAlAk/UonnTpqlMGSAlAEX m6WmKwApE3ukfouYi2HIACkDLjZLYciAeCmTfhJxw64lnlM8oAFlL/vxLxfDkAHhU+ZfklavzFDP v37VYG4DuFhhN2SAlFnQxelW3T3HMP3kxMzHIOa4ON2p7z9J/O3lfz6O1B//cjEMGSBlRrYq8fjg OwNe/uudKx9dnGPbP0cIj41/254/8g2/NFbYDRkgZbZwcY7j3rr48XxxzjvkN/5xN+DOvFwMQwZI maguTrThe28508Xpv83z/l/tcjEMGSBljnLx23d4e2L66d24GBNinnmNhCEDglW5Vqdrx7s480Rw 2fniS+dyMZoH/FXWvL38EsBGKfN4GfZjrfhemX5Kr6O+e4fMy7PTL8u8jvrOuVyM5tHmYkCVQ8LF V//ExVjOxZW3ygG4GFy8zpaIYj6lIFgXA1wM62KzdG6cuRhQ5XDn4pt/4mJ03I7gYkCVAxebpQuu kbkYYyekKgcuNktPP0r3/WKsIOLYVQ77wMUwZDhRxJ8DHoKDjWYjF8OQ7ZKzaFv6uBiL7M9wMQxZ mLTF2xiKJ9ZPai6GIVswZ83chnVPPMHFCjsMGRfPLXpCihWmZf1rFHYYssEiNnPbHsYIKVZeFIc/ YuRiQ8bF50QsETchBRcr7DBkXNzbwjmvB2bN1VbKVthhyJaSi+L2KkRCCi5W2GHI8hOWi7kYB85V LoYhWy1hiYOLwcUKOwzZrEXxCVnJxTg2tbkYhmwjs3AxF4OLFXYYsrnZysVcjNMmKhfDkHExFwMT F8VcDEO2oFa4uHnJElJwscIOQ/YqW4mDi8HFCjsM2VytEEePkiWkWHyicjEM2VKpysVcjKMWxVwM QzbRJlzMxeBiLoYhm2jhHrrhYi4GFyvsMGRlC2Eu5mKYpVwMQ7ZUYnIxF+O0RTEXw5CtlpVczMU4 1sUhZykXGzIu5mIuBhcr7OBiLl7HxaIKLlbYcdqQFWcWa3AxuFhhhyHj4pAhFVWYogo7uJiLFTqY olwMQ7Z+ShJHp7AIKbhYYQcXy0ouBhdzMQwZF3MxwMUKOw4Zssqc4mIuBhcr7DBkXMzFgCmqsO8Y 7f/y/Zu733MxFyt0sCjmYvQI9c/Pj7b9fsFGQ5ZoaX1CcTEXg4u5GE3CHtjF6WcgcvHKLhZVcDEX h7fw3R51vosv/2rNdLur7VzMxeDik1387wtzY5FDoMvF8o7r4j/1/Lu8N8km1uBicLF1Mbg4P1n+ 7Fdz8eKFTlSx5rEiF6NtqNPa3drF6RPE6ZPIrMHF4GIuBhd3TbSGImYNLsaB8zPwFOXiwdH+Pkef /8vFhywnR9rmEWv0q3UQQC7mYuw4ZJkJ0rD5il6PMiWq9fEXQy7mYi4+Zy2g4nHxmhYWQy7mYi7e VAGswcVh1sJi2Ht+cjEM2TqpoeJx8YIiFkMu5mIuPtDFprBat4KLHc+Yn1zMxVwMtW5WwMWwMlyz 3kdhBxdzMRfHlosYcjEXDw7d4Nt6LzVkc+s2a3AxF3MxFxPx5+nph1zMxdvVOlFtEigx7DevuBhc zMVcjJxoiyEXc/Gw0I0XMRezBhdzMRdzMQwZF8d2MY9wMRdzMbiYi7mYi01OLkZ+6P5wrIvPPBLg YtHmYi7m4mPjts6QraBCFa/HcIhqKxcLY49ocDG4mIvPcbHAcvHKLg4WWy7eLnRczMVcvEW0xZCL uXhA3Jwv5mIutig2ObmYi63HuVi542Iu5mKFHVysDVzMxSbnyFBwMX4iZo+aiwOXOy7m4mUXxVwM Q7ZgOih3XMzFp7k4ZGy52JAFcLFZzMVczMUK+7FOPHmPmosDu5hHmsw6MeRiLg4cNy7mYi7eyMUR 7xD1rl9czMUhQ7eUix0SxHaxwHJxol+ZXeNiLu4dOnvUXMzFQn2yi2cdkHAxpseNiyljQBwEtsnk j6iM/+8UF3PxyaFbYcjWKdSUwcVcPHGmZd6Um4u5uF/cAu9RP6YPF3OxaHPx4zx5e2aZi2HINnXx xxW/XMzFU2fa3VTpOoW4GEe5OH24u11h5GIuHhyZqC5+LBe95w8Xg4u5eOuVGhdzcfO+f1/Q1bvj XIzwQ5bzhQUu5mIuPjCMie68+qKT+cnF06P9fZVX/i8HuzhR4bmYi7mYi+9cvNoocDHuQv3zc/4v 13HxalkwqzH94lDwzi5VXXO+hXTxChOGi/Fp8YUmLubiXVysQnDxmodnXEzENZH8I+4yF3f9UvPl ZRgrp8CU9nTdkSt4cy7m4tOWorsHdtYdKrh4x3Xx58PFXCzpl9uy4GLrYhzi4sSE5+JX9+PlYi6O 5GLt4eKV9xZywrjXtVuJ4rNmSo5sUnoPv6GI536PlYu5mIu5OPaCelkX55wgPtzF+TfjHSb6rrf8 VSG4mIu5OOqCuuyXc13cbyXIxVwc3sW7h3HZxOdihByyTBefXCWGufjz4eIIa0Mu5mIu5uJWGcfF l+k/xsWZj2s/ofxyMfFxMX4idkd4Fy9bVbiYi7mYi7nYyjTYujhRT052cXrHoKvuZ3WfjuujESCG a3aBi8HFXDzYxemP4GIu5mJaQZghy3lO4rEufjxK6fdBXLy7kmK4WKu4GEu5+MxawcXgYq3iYnDx xKwcFpbH75RxMRezHhfjZBevXJm7tmrkIcrjd8q4eF8XbxrGxbM+0PMopZkh4+K1XPy2g1y8+DQL 4GJt42IMdrFy8baKcrFFMRdrGxdPDF2we30oF8u6uPiflDsu5mIutjjlYi7u7eLedZ6LuZiLuVjc hn20clHp4iYNKHbxmg7i4t1juHizuRgTQ8fFw1Ly1e2ge7v4M+rGX1zMxbs0m4sPV3DIZ0P42sUu Li64YTUXc3FZg7mYizHFxQfWyXVc/PbjxjzFkoubxGGXGO5iYS4GF5/m4mHRe9WLYTWTi5sM8fox 3EjBXIy70I0MIxePaX+BGcdbj4t3OdhbPIxbn9HmYiKeEkku5uLvP1SluZiLuZiLuTiqi0d++smP weJiLuZiYuXiMI87n+viygZwMRdzMRejIHTjv9DExWOy8m1AuJiL900xtyLhYizl4gDVkovVai7m YoWdIrk4kosHVzO1mouNLxejIHTB9qi5uObduJiLuZiLuXhW3L5/4OLds7KsNKnVXOxYS8u5mIu5 eMCDC7mYi+OF0XNhuJiLVxiyGJWWi9VqLj5QZ1yM3xbe+nwxFzd0ceWzAzy0nYsdaHExzhyyGJN5 zFMLuZiLudjM5GJwcWwXq3iBu8/FZiYXdwrdz+50gD1q1bL+fbjYopiLzUwunhK3MNduKZhcHLhi czEXczEXXy6l//zm7vdcPLIjE58Xz8Un9H1ZF5+c9Vx8mov/qDbxV5ev5OLALl7fdFzc0MVLhZGL uThA6IrvgbmOi2PdRI6LuZiLuZiL8TrmdxvUaRc3vA82Fzd38fjvJit6XHzsIdbOdwz7N+uhBkgf /Fwulq2LuVjR42Iuti7GsGhz8e4u/nzOdXHgTWwu5mIuDi/ixwu6uJiLuTiSsLiYi7mYi7l4ZRfv G96fks7Fe+nPjei5+EwX53+VeNj3i7mYi7mYi7mYi8O4ddP7bnFx2yIZ3sWX7eRiLtYFLj4tblzc 1cVT2sDFXLx7v/SCi7mYi1dz8av32aWY3LXzt4i5mIv1gosPCR0Xr+zigvfZqJgkXPz5cPFmScfF hBJDxAHOFwdby3DxCi6OV1Fiu9jocDEWcXGwmsnFIyP8u/FcvNeIeygMF4OLF6yZXMzFY9KEi3WE i1tFLNIetbLJxZUu3q4jXMzFXAwuju3it2/FxQeW+umBijRYXAwu5uJWLt4xvH/qORdzMRdzMRdz MRcPLuAnuLhTp7iYi7nYkHHxgGhkvtteJfFSviHL+xgXT4yVLzNyMbiYi/f1V+KqaS7mYn3hYi7m Yi7mYi7mYoX9WCeO/EITF+/i4sw35OIzXTw9+7iYi+OJeHAkubhHj3qU3BNcvHVfuJiLuZiLuZiL 93XxZbO5eJfscyN6Lg6m4/Ei5uKNXJzTnkguDjyj+rl4SrjciJ6LwcUru3h8e7iYi8lLd7i4Ydy2 26MOvKO4VDqn33lrF59zdDdlbpDXUaWMiwsidgcX75uVc10cJsjxJhUXczEXixsXx3bxpkPAxVzM xVyMti4OF5zlXJx4cy7mYi7mYi6uD93P1vSO11GHdHFxv7i4Sd3j4vVz0G4YF4dcnO77/WIunuji 9NXIXLz7dFpZIlzMxVzMxWe6+Fu++7r4hKo4fmJwsU5xMRfLylkujhp8LuZiLubikaEb/4UmLt7U xYEDzsVczMVcfPKS3Ozdy8VnTE4u5mIu5uIjIsnFzfsVeNOYi7mYixnkHPPao+ZifII+AGjMhQS0 xcUKSGXoBseQi7lYVYx0aMHFOsXF9dEbH0Au5mJVkYttXHAx/0Z6NgQXcLGqeJqLzTouxiJD5iuu XKwqcrFZx8WHr6nLfsnFXV2MjfwVz8VjIsbFXBx7fZoTxsvX5/+Si7mYv6L2hYv1i4tbxe1VJLmY i7lYX7jYrOPiiS6+U22+i+svGONiLlYVudismyuRWTdS5uJP8iYh1sWzCg4Xc/EKLo4kfbPOunjW UU29wce7OLYORENV3KgvXMzFqsfEUHMxF6uK+sLFZh0XD4skF3MxF8eeSFxs1nHxlNC92qO+e/3E 7xdzMReriku52EO0uRhlcRv/hAgubts7N91S8BfpSLxnQnExF3MxFytQXMzFXMzFXMzFXMzFOrKO UHyTkYvD63hkGLmYi1VFLpb1XIwAQ3ZCVmZ2kItVxXU6wsVcjHOGLLx9uFhV5GIu5uJznDjlVqJc zMWqYmwXd/pQLubiExanG127xcVcvK9QYveCi7kYXHyyi8HFi/SCi7kYxaGzR83F4OLFP5eLuTik iBNwMRdzMRdzMRdz8SHrcS6uT0wu5mIuNuu4GFzMxaqiXvSek3bDuBhruvgEHYiGqrivi9t+NBdz MbiYi8/UsdrOxVzMxVEjxsUN++jLxVzMxVzMLPtGbGLcuJiLuTh8Fzq5OPyU4+LTdDz+q0xczMVE dpqLGzaAi7k48OrYunj3xORiLuZiLuZicDEXc7EucDEXc3FN6LZ+ThMXczEXczEXc3Gwxeku54sP sQ8XczEXczEXczEXczEX68I6DeBiLuZiLubiM128+b36l3Bxqzb49gQXB9bxjueLufi0AsXFXHxU 1nMxuJiLwcVczMVczMWykou5mIu5mIvBxRslJhcrjFxsynExuJiLFUbrei425biYi7kYCuOaacLF 53STi7eLWxMXc8HHF5q4+DAXHzLluJiOuZiLwcULNoOLCSWwiDd9ZuJpLk50lou5mIu5mIvBxVzM xao6F3MxF08P+N3KOrHW5mIu5uJDGs/FXIyc0P3oMieMl3p9tG3zG19zMRdz8VEuPu2rE1x85vL2 +4e36+KRLj7KPlxMZwEaz8VcjDEuvtygTru4+IIxLuZiLuZiLl5EIrMeMMTF6ZddvpV1MRcrjFzM xdbFyDyqqQ84F3OxwsjFzcPIxVyMx4BfapeLuVhh5GIu5mJw8TkuxglG42Iu5uLAVm2yR333Xace 3y/mYi7mYi7mYi6OurwdGUkublVRuZiLt2h5ExebclzMxVy8YGI6WawwcrEpx8XBdDwyjFzMxQoj F3MxF1PwHVy8ZmJe9peLFUYuNuW4GFzMxQqjlvdOWynPxVjWxae5gIsZbet6zsVcjHToNt2j5mIu 5mIu5mIuPnxxysVczMXq+ZhIcjGn0PFqn3ugfbiYi7mYiwklvIv32qPmYi7m4k2bzcVcjNXixsVc TGpcLOu5GHNDx8VcrDBysaznYnxu7vjBxVyMAEvjZV1c0Cou5mJwMReDi1dwsZTnYnAxF3OxNs9q lZTn4vBCtEcdwMXgYi7mYi62VuXiKRXMopiLT3Cxw28SoWMuXjk3uZiLuZiLuZiLuZiLuVibuZiL ubg+blNOFnMxF/MaF0t5Lsa+Q8bFXMxru7v4VcO4mIvBxVwMLp7bMJdrcnFsFd6xzpD5Fs9dOfr5 Ty5WG7nY0piLrVX7fZaV4GXHL/8HLuZiLubiMMvkpYbs0jVcTMTUxsVczMWWw1Nc/DMnTxYQ/1Ib F3Mxm1gOjxyyxLlRMgK1bV3JuZiLsU7Q8l18t0YGuHjH1pa5+Mz5xsWHrIiXvY46cdUWF4Pddm9t fvNcIsLFWMrFHydMoTZysfnGxZjt4o+7W4DgArk456sBXLzbhozqfISLPx8iBsEFd7HLNT/bfo2R iyO52MoXBHdOUzM1dOx842JwMcDFi/gIuxd2jAn45WXYiWuzuRhc3GP1JInAxYeE+tK53z9f/pKL YY3W1cW+bgAuPjbgXAwuXk3EkghczMU5Lr68wYgaAi5+26Q7OwMDXDDlblHovS5WQ7C+jjUGsC7m YoD+JAu4GFwMLtYSgIu5GOBigIsF/M9vmny/WIXB+i6ePkWlCbgY/YZMhQEXEzG4GFwMcDHAxVwM cDERg4vBxcCaNpQj4GJwMTBxlkoQcDG4GOBigItjD5k6g41cPH6uShBwMbgY4GKAi7kYONbFsgNc DC4GuBjgYi4GVtMxFwNcHGzIlBpwMRGDi8HFABcDXMzFwEYuHjNjpQa4GFwMcDHAxVwMcDHAxeBi YIqL5QW4GMOGTMEBF3MxuBhcDCxoSakBLsaYIZv+cHZgzaWxvAAXg4sBLga4mIuBY10sKcDF4GKA iwEu5mKAiwEuBhcDrVz88/r8/wFcDC4GWrm4QMQyAlyM8S4GQuqYW8HFWH/IlClEdTELg4vBxcAw F9tnBriYi4EFXQxwMbgYAMDF4GIA4GJwMQCAi8HFAMDFGBP/33z/nosBgIsxPv5/pMzFAMDF4GIA ABcHjv/lBnXaxf99ORcDQIDif3dGEnOPi/LXxQAA62JwMQCAi8PEn4sBgAuwi4udLAYALkbbIfg+ cZ/+fjEXAwAXY7a7uRgAuBhcDADgYi4WDGBY0vkGKLgYXAxwMbgYXAxwMcDF4GJgspHFAVwMLga4 GFyMdVwMgIvBxeBigIsBLuZiAGMU7AquBcclzHCYV1wM4JCCb2i4GFwMKPhoPjQxRscc42IAXLyv iLkYXAxwMbiYi7kYQO+aT82OkbgYXHx4/cdSBd/ogIvBxUQMLgYXg4vBxVwsOOY5FxsyLj6h/itW a/rC0Kzm4hgjYkZt6mKzKHyBqqwwfDFysYziA84mc5uLwcXqUlQXG9m2kQl2k6iavtS4OOqJA7l2 uIvr36vJhqp52NbFrQbFuDR38QohbZX1q7l46+kq17i4VbmOsaE6cTn5XU8mutg567ZWXeeQtdVB WsN5Xp9fXIytXdzWOw3P/uzr4h5nwaasbbk40fdKF89Nk0Vc3HxcuBjHurjtIm6dXGiynNzdxWFK 3Aodrz9k/T0T5m53tOpL8/za/dCRi491cY+cKniftrvcEytMp2rAxbNWgp1c3KT9E497e8yH/Dds u1nBxVjTxWV7bs1dXLNqaFWj1rlQ9m2nemT0CiWu/ijrbRhXvoYh0oXcr0KdfiUXY5aLJ35Br8kV FG2LTMMrM4sPKuaqsEkDljp3Xx/bGhevKeImx70L6riVizeVGhcHcHHD7eX6YtXExTUr9FY1qtXB yZo1bUDFbrsx26TMNjyqGVP2H7dkmzh9um4ygxn7YkIu3tfFxddy3E3pJpUqP1/qm9GqaNev8St3 7Bs6dJ2zgc3PdLfqXf7krH+rmjR5fE39wfPbSd7vCMe357g4gIs/jfbfWh12Vpa7Viv0YUuP9EHF sKP9hgdIzUXc8GqEMQcb+QPXaXbly3pkttZshaV7xMVcvOmQdbqxxsiM2KUZ/eptc8VUrqFarcKa 7LrUH6cVv0Org6ga2w47dqqf5A1n18k+4uIDXTxgjbZLM3p/SqvKP+AFrd7kU70d2uSQoEZzTRZ6 lR80/uzGgJ4OW+bv6DUu3tfFU/Q07A5+S7m43zd8mxjqcYWVX067Cv3tkUnvhW2/sp95Vf+YXfe3 C/yCPY2G2zJNtpi4GAGGrN9pnSYXmBVUmCaLrK7x7LrQy7yooOGitdW2bXHQRh7IVe6l99ZHwRZ0 2Wn66bsZ+YedXIxWaZ6f3X+unxm5//PdjIYr+imXRRWHtKuL8w9aGrqjVdlP/1NZbR9Ziisv2xvm 4uIZ/ml3cdd4F+9lZC5efFDKvrL6754aB5XduahhMyorTJO7+Ba8Z7rKFYc0MxTfcav8ulCron05 pvkurl8Ut7pdW06E63VZMDTFB8+Vh99NDo3KEm3kcQ4Xc3GTNV1vF/duRlm9LW5AZY73c/Hb6dTJ xfVl/zLO/ep2k0PWJi7usU6vvA1d5cRYxMXj90m4+DQXAwCCwX17uRgAAHAxAABcDAAAuBgAgNg6 djYfAAAAAAAAAAAAAPDDXrd0y3mKjdvTDWvtXmE31YX9nLDvWGcOF/Euo9b2Np5KU5PWblqUTHVh jx3238lLczJFppywLt592m/X1H2rq7CP7wIXc/F4F2+33ozhYrt2g5u6acz32ggKEHYu5uLpTXW+ eEprhV3MDwn+Rk9o4mIu5mIuFvPeTeViLt66qiOei7ebfvHOF280f8KIYK/jHxVmWEc8OZGLZQoX CzgXqzCmPYoPonZs6p+fXbs1prU7hn2jlcJlU7ee6iqMOgMAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAIpp9SSauwfkiTAAAAUObfgmdAwAQNqhP3cG/rNAvlsvX95M+Ptuw1wMR6oA8Lba/P7hR8cJ Lxf8EuBiAMh08eMPr7SroGHT1DB1Aazp4vRTCC8rmIKGTUVMxwAWXxfnr4VVM+yeHQCwpoudLwYX A0CranN3gdadWNNXStujBgBgqeUDEQMAwMUAAByrYyLGFnPVJdMAAAyz8ONd40QJAIBWC947sXIx AAADdJx/DQMXAwDQXMdppXIxAABcDABAYBE/WpWLAQDoLeK0WLkYAIClXPzx/WIAAAAAAAAAAAAA AAAAQCP+AxqV0V0KZW5kc3RyZWFtCmVuZG9iagoxOTIgMCBvYmoKNTQKZW5kb2JqCjE5MyAwIG9i ago3OTU1CmVuZG9iagoxOTQgMCBvYmoKWy9JQ0NCYXNlZCAxOTUgMCBSXQplbmRvYmoKMTk1IDAg b2JqCjw8Ci9MZW5ndGggMTk2IDAgUgovTiAzCi9BbHRlcm5hdGUgL0RldmljZVJHQgovRmlsdGVy IC9GbGF0ZURlY29kZQo+PgpzdHJlYW0KeNp9kk9IFFEcx7+zJUKsBWUmUvBOtgdXBu1gHYzd9W/K tqxrpgiyzr7ZHZ2dnd7MbiUeQoguQdYxuljRSTqGBw8dAg8RgmJdIugoGQSCl5DtNzO77ojagzfv M7//v997QF0obZp6gAF5wxbJ/ii7Oz7B6jdQhwYEQSutWGYkkRh2mWxxZO19heScm+Hj9f9dDYIS AhJVgMasx9ccnvZ4wOH7tmkTTzqs5NIZYpO4TaSSMeJXxGezPp72cYZbCvEy8U3FFBQnkCIeKClZ J+YOsWxkNIPkl4m7MpaSJybfwFNnFl6Z9hDQfQU49bkmm7CA5XfApdaaLNQMXBwDVjprst2kOx+p ad1SOztckRSMAnU/yuXdVqD+BbD/vFz++7pc3n9DOb4DH3WlKEqVGUnSF8Drw12N/dzgQlOYc18J UVA1nftGerza69eLR/Ulq3QSezNxVxewRPcwdgYYegy8/AlcfQ9c+AAkGoDUdQQeobpt/sDNEyuY D4WWzdmsQ5Y7WNg5OlmEXghnsULeLNpcsEFDaW9jaV1nrqnFBLe4KPFMO/J6sdrvOdpBboyO0Enz Cqjc6q2wNJNJ99DdoJ14I8N7ep13Qbyoan2DzoXQ/qSKvlGPpfOaPZjyONBt6PHhCsMoxG97MbFj 2tFkNb5VGumtymfStxJ0tpD8xmxhyLFpIt/QXC415rGUmsvF4hVexTh0cGgw6GuAIYl+RBGGCYEC VNJoZKGRlLs2gtjC7LGWOhI+ZqTfJp9t1+ceiuTteN1BNI6FtoMITP4m/5a35CX5rfxrsaUYqmkW xJSmrD/7Q3GdzNW4FW2lJi++QnkjpNWRJWn+oCfLV6mvOtVYbKlFcnLwJ/E9X5fclymMaTfSrJup 5Oos+kZ82U6aHtmuza8213JtnV6Z3AyuzR+aVeFIV/ygq8P/NTu/P/8HzbABaAplbmRzdHJlYW0K ZW5kb2JqCjE5NiAwIG9iago3MDYKZW5kb2JqCjE2MiAwIG9iaiA8PAovVHlwZSAvQW5ub3QKL0Jv cmRlclswIDAgMV0vSC9JL0NbMSAwIDBdCi9SZWN0IFsxMDUuMDIyIDI0MC4wMjEgMTEyLjQ2OSAy NTEuNzExXQovU3VidHlwZSAvTGluawovQSA8PCAvUyAvR29UbyAvRCAoZmlndXJlLjkpID4+Cj4+ IGVuZG9iagoxNzUgMCBvYmogPDwKL1R5cGUgL0Fubm90Ci9Cb3JkZXJbMCAwIDFdL0gvSS9DWzEg MCAwXQovUmVjdCBbNDU5LjQ4IDE0NS4xNzcgNDcyLjM4MiAxNTYuODY3XQovU3VidHlwZSAvTGlu awovQSA8PCAvUyAvR29UbyAvRCAoZmlndXJlLjEwKSA+Pgo+PiBlbmRvYmoKMTc2IDAgb2JqIDw8 Ci9UeXBlIC9Bbm5vdAovQm9yZGVyWzAgMCAxXS9IL0kvQ1sxIDAgMF0KL1JlY3QgWzI0MS42OSAx MzEuMDIyIDI1NC41OTEgMTQzLjkyM10KL1N1YnR5cGUgL0xpbmsKL0EgPDwgL1MgL0dvVG8gL0Qg KGZpZ3VyZS4xMSkgPj4KPj4gZW5kb2JqCjE4MiAwIG9iaiA8PAovRCBbMTgwIDAgUiAvWFlaIDU0 IDc0Mi40NTEgbnVsbF0KPj4gZW5kb2JqCjE1NiAwIG9iaiA8PAovRCBbMTgwIDAgUiAvWFlaIDE4 My41NiA1MTYuMjQ0IG51bGxdCj4+IGVuZG9iagoxNTcgMCBvYmogPDwKL0QgWzE4MCAwIFIgL1hZ WiAxODMuNTYgMjg5LjY5MyBudWxsXQo+PiBlbmRvYmoKMTc5IDAgb2JqIDw8Ci9Gb250IDw8IC9G MTUgNjMgMCBSID4+Ci9YT2JqZWN0IDw8IC9JbTYgMTU5IDAgUiAvSW03IDE2MCAwIFIgPj4KL1By b2NTZXQgWyAvUERGIC9UZXh0IF0KPj4gZW5kb2JqCjIwNSAwIG9iaiA8PAovTGVuZ3RoIDc1NCAg ICAgICAKL0ZpbHRlciAvRmxhdGVEZWNvZGUKPj4Kc3RyZWFtCnjanVXJbtswEL37K3ikgEjhqiW3 tE7SFD20gG9pDoxM20S0OBQdt39fUkO5duqmQGFAs3G2x+GYoDUi6G72YTG7vKUSUZJVpKJosUJS oELkmaQ5WizRA77vElZip22nXTq3auWStGK8wsvAp86arXIbk9q+aVK7bdLBtMFj1yhn+i4lNEnL Iq/wXNfaWwr8lKT+q22Sci4wI6RKHhefZyTWNNGbxYx6hiCKaFFmQlAkWZXlpUB1O3uZkYxXJYEj x/xonDyj4vK+LdG8n33zvyn+dCSdoqdH4c8AQ7nMSsKRJHlGCwbo3Jr1zurQCcflVZIKIfF12+8A NND3K6BL5RT0rLolqOoeDnrwQLFVdYDoOWi1G0DprOqG1jinl+C/6i1Yut5jWeJlrIDT7CyU70DK CckKWU6QCillESH9zf8F0urfkB6FPwMpo2WWS4pYUWRM5H9CWkVIP85vr0DzpR+GY1hFwLDTtTOv xgXUfiYlx+dh8HWJIit8Dd4xI0S+SUgYpgzosOlDsP0Aov5OKPdJQBozezoPR67D5w4Ud03/pBrg rd4qY4F3ptWR3Y4Xpq2JNxcjdoFSmIdimofgmVBslc+e10lKfV+p8K1fx7LcRr8X1fWxej87wHV6 H5DxQORZxXNPeSZFBTictMM8ioN+2emu1iCZrrZaDXq48HLFIXkwqKN5D3KAh5XstJmgcIdORrdm 6IFb6hgZxCdopla7QUfHKZXfNnXI9Nwciorb6TWREquYaD0+nWBvlF176EPP5LRbeEOMYK3GkBuQ Di/qIsgM7zfm2GwGoFurXRw30EMdO+PncHy74aYEwZ/6AMF+VIEhZvUrM4YaWtU0k/oYyyCPo+bp 6aII/gcswdzqGE5Fz7BqaOULNeECY6wjHOLwT7caF1KY1Dc7pvmPFzcmybmfsQLSLMKZ+FdxAdF0 XI+q8VhRWhYU3/zYGqtjts+7LpbCRHRhhBJ/VnAi8MPXkFut4xlKH08q8KvuFwtZtHoKZW5kc3Ry ZWFtCmVuZG9iagoyMDQgMCBvYmogPDwKL1R5cGUgL1BhZ2UKL0NvbnRlbnRzIDIwNSAwIFIKL1Jl c291cmNlcyAyMDMgMCBSCi9NZWRpYUJveCBbMCAwIDYxMiA3OTJdCi9QYXJlbnQgMTIzIDAgUgov QW5ub3RzIFsgMjAxIDAgUiBdCj4+IGVuZG9iagoxNjEgMCBvYmogPDwKL1R5cGUgL1hPYmplY3QK L1N1YnR5cGUgL0Zvcm0KL0Zvcm1UeXBlIDEKL1BURVguRmlsZU5hbWUgKC4vZGF0YV9sZWFmLnBk ZikKL1BURVguUGFnZU51bWJlciAxCi9QVEVYLkluZm9EaWN0IDIwNyAwIFIKL0JCb3ggWzAgMCA2 NDEgNDcyXQovUmVzb3VyY2VzIDw8Ci9Qcm9jU2V0IFsgL1BERiAvSW1hZ2VCIC9JbWFnZUMgL0lt YWdlSSBdCi9YT2JqZWN0IDw8Ci9JbTEgMjA4IDAgUgo+Pj4+Ci9MZW5ndGggMjA5IDAgUgovRmls dGVyIC9GbGF0ZURlY29kZQo+PgpzdHJlYW0KeNorVAhUKFTQD0gtSk4tKClNzFEoygQKmJkYKhgA oYm5EZhOzlXQ98w1VHDJB6oPBACVFA33CmVuZHN0cmVhbQplbmRvYmoKMjA3IDAgb2JqCjw8Ci9D cmVhdGlvbkRhdGUgKEQ6MjAwOTEyMjExNzE1MDAtMDUnMDAnKQovTW9kRGF0ZSAoRDoyMDA5MTIy MTE3MTUwMC0wNScwMCcpCi9Qcm9kdWNlciAoTWFjIE9TIFggMTAuNC4xMSBRdWFydHogUERGQ29u dGV4dCkKPj4KZW5kb2JqCjIwOCAwIG9iago8PAovTGVuZ3RoIDIxMCAwIFIKL1R5cGUgL1hPYmpl Y3QKL1N1YnR5cGUgL0ltYWdlCi9XaWR0aCA2NDEKL0hlaWdodCA0NzIKL0NvbG9yU3BhY2UgMjEx IDAgUgovSW50ZXJwb2xhdGUgdHJ1ZQovQml0c1BlckNvbXBvbmVudCA4Ci9GaWx0ZXIgL0ZsYXRl RGVjb2RlCj4+CnN0cmVhbQp42u3dDY+jPJaA0fr/fzo72tW0aitgDL62r805ao367akPYsBPICR8 PgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD08vPzc/kvj39U4ELG/vDKnxb7ZbFL/v2XZ8v5 bOFbNptbv/Hnv+ofy+NHVPjGYav48SZ3NlCBq6P8lT2GaOSeBbMS/Gc7z5bgibt2wgQXWjw4wY83 m2df+fvxlqPckqHpc/7lAhw+/MOByrbkEgw1Bw6H09Gffyx8zeH88OcfC0crf764PN/W/K7CAnwv f+FXnx1i/P6y78E5e+CHS3g2Pmc/4bfLh3955Hg2jVcebxZGsrAY9cdul8WvWaeXK/psSb63//Ih c+OWeTkmdxN8uUXV/OrCV15uh4c7yOXKkmAk+PAY5HBG/bMP1vyQyqOe8lFYzcRSfiJx+b2XC1NY qvohqhzkmmUr/MzHI9n+zK1miGqOuCsb1PiPt1Zx4JLUHJI/SHDNFtWynT97XPX/CBsn+NmUHjLj PU5w/Zx59zzq3ddb6x9X5QO8NdpRcXmcpH7hqz8KjnoUgV/5eMusfFrS+EsfP++6tbNc/vAHQwRb JvjW2aq7z36/z1N1SnDl7yqcEiw8Xb9V2MuFKfzwxwmu/42Nzz0ebzaXCxyb4MOf3zJKlcebd3/p Zgm+fLCHp/3rJwqQ4AfPfi/nlsYE3/32W3lqmZ8rZ7nGg9/Gg7LyxtApwXc3zsdHweOPlzud3lnr KLi8wLf2F9g+wZ/zV3luvYL5GXIiOuQUaMuXRSU4/C+f5teCbyX4c+eVvvYj9GcJDnwtuLG2ISfn lz4R3fgkCjZO8NkJ0vpd+NYFyYXzeDWzQfl3XV6feXYC7awshR6VT6x96q4FvTthXl6YWl688kje SsCn2xXRle8LfnBtds16eZbIyl9av2VWjv+t10p6JLjycdU8hJa3eAPjnznw8kEOWVrbFYCp0ghL MIBAGN6XLLaNCgAAAAAAAAAAAHiVy0+CNUQAMCDHf/7y8QYHABjVXwkGgJwJ/gFgIwqYp7+f6lvR rf4wLbklt+SW/OVL7lSnBNvSLLklt+SW3MJLsARbcktuyS25BDNx/CXYkltyS27JJZhZ4194md76 Atg7AVhfwELTAoteAm1Kl2DAtMCUlWXd2dcA0wISjH0NMC1IMPY1wLSABGN9AaYFCca+BpgWkGCr D8C0IMHY1wDTAhJsXwNMC0gw9jXghdPC3bvi1j+K9vvtVn5Xj4GVYPsasP208J9/G/+npTW3Etw4 K0owEgy8J8Gfr9vA/T6GLf9nfcXOPof5zz/+/kWViyTBWF/AKtNCIcHlGpZv2FqoWE1kf//l7Bcd fq8EY30BGyT4MqCX33L5WvDljy0fSkswEgzsmuDvhpb/38rHW/6x5QRXfq8E29cA1k1w7InoB0ey 5RPRXQdWgu1rgGlh8FLVv/DaL8GF3+VENBIM7JTgwvnk3//+738Pr0aufE258I2FK6Ivv8wV0Vhf gGlhy5Vl3dnXANMCEox9DTAtSDD2NcC0gARjfQGmBQnGvgaYFpBgqw/AtCDB2NcA0wISbF8DTAtI MPY1wLSABNvXANMCEox9DTAtSLAxsa8BM3bn4z87TQvlO/8GPrTCfYEHLMDj5TSlSzCQKsF39/LL aeGnKPArw3PTnuAxCyDBEgwsl+CzLm+Q4PJSnd1AsHzLwsr7D9b0rvygvr+l8L2H/ynBEgys1d9n FU57v+Ca/+uwXId/OavhgwTXRPbPE4PLha9ZHgmWYECCcya4Jm13E3z5WnDNT6hf+JozEqZ0CQZy 9vdBhSW48ij4rM53E1z+XieiJRiQYAmuORtc8xPuvuj8cSJagoGs/a1McOXunnZaiHopdnyCK1/k 9VqwBAObHQLfPRBe8X3B5Uuav6/CuvXtlUfi3z/81lKdnXx2IlqCgXUPgXdKMBIswcBah8C3Kmxa kGAkGIg6sJVgCUaCgVmHwPUVNi1IMBIMBB4CS7AEI8HA9ASXv9G0IME8Xh01l+tbX/DC/lZ+7w9L MaUnfDp0+Q506wvenGC7/hsOipk++O0JLtyE1B9//Jn1p73g/owfeQnePsE1H8ZydsbJruqPPxLs z0IJLp+XZvy6iD0R7YQVgBPR3Bp8CQaQYCQYAAmWYAkGkGA6jX/s+4IlGECCmbK+JBhAgpFgACT4 JevLp+gASDATEwyABCPBAEiwBAMgwUgwABIswQBIMBIMYEpHggGQYCQYQIKRYAAk2PqSYAAJRoIB kGAJBkCCkWAAJHjv9eU2SQASjAQDIMESDIAEMyDBAEgwEgyABEswABKMBAMgwRIMgAQjwQCmdCQY AAlGggEkGAkGQIKtLwkGkGAkGAAJfuf68gHRABKMBAMgwRIMgAQjwQBIsAQDIMFIMIApnajB/Plf 4xMMgAS/vL/9xlaCASQYCQZAgvMMZtf+SjCABJNtfUkwgAQjwQBI8PjB/EOCAZDgPUZSggGEAwkG QILfM5iHv8JHYwGoxstH8u5rwWdfXPh2CQaQYLod0v4UvkCCASQYCQZAgjOMYeOJ6PoEf3+XBAOs 0ove712l5bmQo2AAR8FIMAASvMpg3j0RHZhgACTYSD74FgkGEA4GV/j7ePnZ+4IBkOA3D+aU2zRI MIAEG8kpv0WCAYTDYEowABI8fiSdiAZAgt+zvrwpGECCkWAAJFiCAZBgJBgACZZgACQYCQYwpdM+ jGPuAinBABLM5RiOeV+wBANIsDGUYAAk+G0JBkCCXzuMc18LBkCCGby+JBhAgpFgACRYggGQYCQY AAnuNIZneq8v70gCkGDDOOUXSTCAdhhGCQZAgt+zviQYQIKRYAAkWIIBkGAkGAAJlmAAJBgJBjCl G4TAwfTRHABI8JYjKcEAwkGeBAMgHAZTggGQ4JFjOPc2DQBIMCPXlxeCASQYCQZAgtP08af/r5Bg AAnmYCR7vxYswQASjAQDIMESDIAEv3Awu74jSYIBJJgM60uCASSYYWMrwQAyweFgOhENgATPGsnv v0gwABIswQBIsARLMIBwEF7hWwP7df+j01eTvxMMgATzeBWcfbh04eM+HAIDSDDt4y/BABJM+/Hs d1VjE/zvl0gwwKKZ6Pr21Tc/mam/HOvwKx0FAzgKpmuCa7IrwQASTI8EH56OkGAACebBYD47w+8o GECCybAWat4XLMEAEsyU9SXBABKMBAMgwRIMgAQjwQBIsAQDIMF7D2bvTx6TYAAJZspISjCAcCDB AEjwewZTggFUg++R9FowABK8/fqSYAAJRoIBkOCJY+hENAAS7CgYAAlGggGQYAkGQIKRYABTukGQ YAAkGAkGkGAa+vjTaWAlGECCKfS339hKMIAEkyHBAEgwn/9//nnMiWgAJJjhx9oSDCDBHI+kE9EA SHDvMTzTaX25FgtAghk8khIMIBxMXF8SDCDB/BnMf+efu14RLcEAEsz3SA54X7AEA0gwEgyABEsw ABL82sHs+o4kCQaQYOauLwkGkGAGj60EA8gE5ZF0IhoACR4/mP1GVYIBJJiz8ew6pBIMIMH8ya7b NAAgwduvLwkGkGAkGAAJTjWYrogGQIJnjaTXggGQYAkGQIIlWIIBkODwwXSbBgAkeK1qX/6jBANI MFFje3gFdfmyagkGkGAKh7QPTkRLMIAE0ziSd2/W8KfXlwn+vy+XYIDVj9QkeHqCHQUDOApGggGQ 4NUrXDOwLscCUA2mD74EA0gwg8ff+4IBJJionvp0LAAkeOJI+oxoACRYggGQ4JcMphPRAEjwsJEs kGAAJHiD9SXBABKMBAMgwRIMgAQjwQBI8E5j+DvBAMiHMRw2khIMIMH8Gcau70WSYAAJZu5ISjCA cDBxfUkwgATzZzBH3ikJAAnmM+M2DQBIMBIMgARLMAAS/MLB9FowABK88fqSYAAJZsaBtgQDSDAS DIAESzAAEowEAyDBW42kBAMIB1MGU4IBVIOjOI64WaEEA0gwk0IvwQASjAQDIMFJ+vjz3w+w+un2 KyQYQII5GMnvv0gwABIswQBIsARLMIBwENfH7jcrlGAACWZS5SUYQIKRYAAkOEkfnYgGQIInj6TL sQCQYAkGQIJfMphORAMgwQPG8IwEAyDBG+VeggEkGAkGQIKT9NGJaAAkeMORlGAA4WDKYEowgGpw 0sd7J6IPv7Lw7RIMIMG0j+Th+4jLby6WYAAJJnYwJRhANXg8ko+viD7LbjnB1h3A6qUwJqmeBTkK BnAUzJTxl2AACebuSN49w3B2zXNNggGQYB4PrAQDKAVTxvbskLnmfcEA75xXd7qKSYLXGlsJBiRY gikf0nYaWAkGzLQSzLzNT4IBCZZgJBhAgiV4/iYx8n7BABIswYwcWAkGJFiCKW8hPX+4BANIMKPH U4IBtjkQluC1NgkJBpBgpgyjBANIMH82BldEA4ycbCWYGVugBAMSLMFIMIAES7AEA0iwBCPBABIs wRIMIMESjAQDz9NjHCQYCQYk2DhIsAQD0mMcJBgJBqSn9zhs9ohs3hIMSDASjAQDEvySI2LrVIIB FZZgCUaCASQYCQa0Ju15AAlGggEJlmAJlmBAgiVYgpFgIDw9L2+xBCPBgARLsARLMCDBL0/w6gMi wRIMSLAESzASDEhwTYK3eVC2cAkGcrbj9/dOD9DcCG75DESCJRiQYAmWYCQYJDhzAb1JWYIl2EoD CZZgl2MhwcAbEvzJd0GUBCPBwHLx2uOBSDASbFqAfptotg171r52+HslmCkJRoJZbuPcI8Gp9nEJ RoIl2HjSr6FJVkTO90NJMBIsGcaTMQlOdRI4T4KX3lDtZRIsGRjPnAn+XhESLMEkSbBJMnBnDNmX 239Iqrluj7N809dIkgS3f0LX3B1NgkmVYMcpCZ/n55nwQ37CNglOsk4f/BwJlmA2TrCOS7AEDzu7 smiCY0+GuzJcgvOvgsJWGpVgtz+TYAleJcH9jiIlWIJN+9+72FWd/86TLRvzHmdyoj76b27K29sX Us9tEhz7tGrKKdyoBEc9hFlPAySYYatAgieWK9W0L8EbbBjh+9rgBMe+Auu0mwTvkeD2CzyidooM 52/3S/DE6IT/kIkjme25RIYEPzsMz5zg5Zr+80UEX3UUnDbB7d8+9+Bxj+O+T+iJfQlePcH5D2Zd Ec1CR8HhV/VPT/D35S5z38K5QYKT5EaC024Yc3c0CWbRBB9+sQTnSfBO0Yk9Hz59NKaUK+1p2/E7 2tWbRBausAQvneCQzX7uS6ipLneZe8VmkiuiM0z4PY7a2hdj8Lt6N37lVIIlOPMqqH9fcMi+PPfi isBbuWW4GvkT8c7HJB+6MvGsQuy8GrKFD34rUNcEV/7M8AV4PJgSTJ71FZ7gJPP8xAR//5D2ubpx up71XKLHWYUkx1zjN4xOCR6zUjr199l4SjBLJ7j3zDbxBTsJzpzgTHvNtASHL3bjIaQESzCBCc7T 4okdb1mSkPa1lys8wSEDuO4nMGRYIxsnuP0txhIswesmOMNcHbUXTH8usU2Ce7wUPj3BEz9SuEeC H7wU2z4mEizBJE9whndtzNqVDmeGkA88WS7BUR/IH7sxpErwyLfhd0pwyLdMSfCuU7qu7Z3gmp1F gqcfPGZO8LCZttN5CQmWYAmma4Ibd5YpM+2AiWJW+tun6ykfPSrBgecE2l/JjU1w+Abc/oRk5NqU YCS4d7YmdrzTAemUBE/fMHokePyG0ektRe9M8N5TukFYOsGX23bNlh810w5+CTUwGR1W09AJp3BH mwwJnvsTPpku2hl88caDDaNyrDJ8NMEGcZfgvRN8a2+anuD2XS/w0G/BDSM+we1LIsHLJXi58C19 UbQELzrTxiY48Ihp5I6z7om+nAnulJiogE7fMFY8ZMuc4D1u0i3BEpwkweN3nG0S3OkGExKcbTV9 ep6Ymnu6Y8CxvASTM8Ehu8n4V3aSfHZQ2gS3r5EVj/uSHLUVFmPM9cxvePE06qMyJZixG23Ys8ds CQ55dpEkwYN/QtpnSp801+0kSfD0cfjUffLVgMGXYAmW4Gxze1SCR3Y8ajHmJjhkPDPPkIM3jK4n afvdBrHrXdUkWILfluCRs9ngg8fABLefPZDgRfadQRtG79dJG19gkmAJJjbBLzzKyDDThpTrcj6c u/pGnn3N/0DWSvCDTavH6m7cwiWY/M/kl7vwJskxV/tE1B7Qrj8hZN1lSHCPSxD7bRjtL7bOTXDs SglJcO81LsFMT/ALb9YgwdkSHPUi7NIJjvp8yN4fFpckwatP6bq2TYKnfzhSkktwkyxt+9vBOr2n u+tidCpXv3e4D34g4xPcb48Ys4VLMBIcPk923a+THHFnSHBIuST42QN5vOGtleDeDZVgXpXgMfNk yNzSLxlJjrKHJbj3eCZJ8LCPxRhw+dB7Erz9lG4Qtkxwv7uzZZjwa37C3A8g+gx8XXvMGpm7YYxM 8Ky9eGSCxz9pzz+kEszcBH/irtUcc5TRLxlr7dRJno303jAC38CSeZVNTPCUByLBurZBgj/N9959 YYLbFzLDjp8nOhKcqlxjhiLJ5ZcSjASP3F8GTC9jErzEUAQmuGU8Q9bIEpf9jwnKKgnO8KKSBHN3 S+uU4FU++X+tBA/4gvwvgI75EKQlrmceeQlBkg1DgpHgPAke8AVjErzKAxn2rGmJQ7/pTxWmJHjW Dap6fw6YBDM+wUnu+NbpGGHYseGA35LquUT+ZwIZDsY/825jFLtSJFiCWW4eG3OlcdRrgtMPcj/N pxyTHH7u9NbOMdvngH08ZNOSYAkmZPfMsxEOeMdQ7x1/2APJ0L4kh8mDzxH13jDWSvDj2aP3eZ4k H7MjwVxukBLc6XA+eYJXedU7z6bVdcNoD+haCe69hUswqyT4k+xdBslv1rDcZ0b1HuoBB4+9nwlI 8OOhaH/xuusWvveUrmubJTjkahAJHlCuYTdQGPNABpRLgjttGF0TPH0Ll2D2SHCq29eudUvEuRPU mMP5lsWQ4DcnOMN+KsHEJrjHb8lw6/ZP0N0MR+7a/S4tC0zwmJk2ydnX/BdTjWzf9CftL5/SDYIE d0pw5U0VOy1GnkvX+v2uRRPcsmG0Pzf7ZLp+O8MJlulPEQPHc7miSbAEp01w7yOdDa60HHYGOKom EpwzwTmfYUowb05wy+1Ekyc4aihWmcbH3Bl5zHiGrJEMt+rLsEZW+cj3lk1LglkuwWc/aol7JHWa ZkMS3Gk8F0rw2dbV/iaakW/Didrjpj+1S3LX4PDryhYKsQTvlODwXTjw8+tado3vbI0831h4NvIs wb8/DKFlvY+85Kbrxvxg2bo+s2rZQgY/kchT4U4zW6fP7JJguiY4w5FOVIJbDpeiRqP9qK1xKHZ9 s3b7RzPFjknIOp17/+g8vzFkCx+5l0kwElx5MD7mmuqoZwLt897PkZDf+Owl1KjiJNmhQk71tK+a x8/NQn5C4NPUqCeZg/cyCSbz+pp4IPb4w2zL3Rm2GFHHCBKcOcGf5pcnJDjkdYG1GifBErzEksd+ hvzdyaFHgpOMec4H8uB14cBzLPbQDE+HPneuNjSlY30NSHDsC7sPlnyto79177L6+DBw+jYmwYG7 pwST5NmgHfwz7w0UZ9esrp7gzA9kyvtQ3nDac4kll2CSrJHDM6hv3tKmHOn0+IARCY7dWiR4yxZI MBKcMMGDZ9qNx1yCe/wQLZBgCd44wQBsQ/UWSjAAIMEAIMEAgAQDwLoV9jI9AAAAAAAAwEss9Bpx +WOu13pb+kIvyp8t6nJ3l7CdG/M3zC3LzTAv7+8qq2ybz9jcY15a91mE7dyY7zrmf/ZcgbOb2E32 PgpefZtfblGNuTGvfAgSLMGDE7zWmaLNTkRrwZhFXXE7X31RF51bJFiCZy2q14LHL6oxN+ZvWNSF 7iUqwRIswXJgwPstqgRL8LrzOZsleLltb7PXghfaeLZJgByYW74X1S0LJdhuIsFGW4LNLbZ5bj1x WnFR//zd5VgDFnXFMV/o0OBwURfdzs0tZhgAAAAAAAAAAAAAAAAAAAAAAHiJqNvBnN2czggDQH06 A3+ICgPAYR//fWDvn8Phs6Pjw8/4/f4QYAnGs1OAynnm91/+VbiQ4wf/CBIMUE7w5V9u1dZUxor7 he0WyJbg8u3/DucuUxkr9leFgbRHwfVHvuYxlt41ALIl2GvBSDBA4zxzds3VWU/L1zw7EQ0AGY4X 9BcAJBgAXlJh/SX/huriZwDoHd/LD3YzSgDQeHh71lMJBoB+Fa6/OEGCASCqwuWSSjAASDAAbNPf y5hKMAB06m+5pxIMABkS/PG+YAAAAAAAAAAAAM79D8euVxkKZW5kc3RyZWFtCmVuZG9iagoyMDkg MCBvYmoKNTQKZW5kb2JqCjIxMCAwIG9iago2MjMxCmVuZG9iagoyMTEgMCBvYmoKWy9JQ0NCYXNl ZCAyMTIgMCBSXQplbmRvYmoKMjEyIDAgb2JqCjw8Ci9MZW5ndGggMjEzIDAgUgovTiAzCi9BbHRl cm5hdGUgL0RldmljZVJHQgovRmlsdGVyIC9GbGF0ZURlY29kZQo+PgpzdHJlYW0KeNp9kk9IFFEc x7+zJUKsBWUmUvBOtgdXBu1gHYzd9W/Ktqxrpgiyzr7ZHZ2dnd7MbiUeQoguQdYxuljRSTqGBw8d Ag8RgmJdIugoGQSCl5DtNzO77ojagzfvM7//v997QF0obZp6gAF5wxbJ/ii7Oz7B6jdQhwYEQSut WGYkkRh2mWxxZO19heScm+Hj9f9dDYISAhJVgMasx9ccnvZ4wOH7tmkTTzqs5NIZYpO4TaSSMeJX xGezPp72cYZbCvEy8U3FFBQnkCIeKClZJ+YOsWxkNIPkl4m7MpaSJybfwFNnFl6Z9hDQfQU49bkm m7CA5XfApdaaLNQMXBwDVjprst2kOx+pad1SOztckRSMAnU/yuXdVqD+BbD/vFz++7pc3n9DOb4D H3WlKEqVGUnSF8Drw12N/dzgQlOYc18JUVA1nftGerza69eLR/Ulq3QSezNxVxewRPcwdgYYegy8 /AlcfQ9c+AAkGoDUdQQeobpt/sDNEyuYD4WWzdmsQ5Y7WNg5OlmEXghnsULeLNpcsEFDaW9jaV1n rqnFBLe4KPFMO/J6sdrvOdpBboyO0EnzCqjc6q2wNJNJ99DdoJ14I8N7ep13Qbyoan2DzoXQ/qSK vlGPpfOaPZjyONBt6PHhCsMoxG97MbFj2tFkNb5VGumtymfStxJ0tpD8xmxhyLFpIt/QXC415rGU msvF4hVexTh0cGgw6GuAIYl+RBGGCYECVNJoZKGRlLs2gtjC7LGWOhI+ZqTfJp9t1+ceiuTteN1B NI6FtoMITP4m/5a35CX5rfxrsaUYqmkWxJSmrD/7Q3GdzNW4FW2lJi++QnkjpNWRJWn+oCfLV6mv OtVYbKlFcnLwJ/E9X5fclymMaTfSrJup5Oos+kZ82U6aHtmuza8213JtnV6Z3AyuzR+aVeFIV/yg q8P/NTu/P/8HzbABaAplbmRzdHJlYW0KZW5kb2JqCjIxMyAwIG9iago3MDYKZW5kb2JqCjE3NyAw IG9iaiA8PAovVHlwZSAvWE9iamVjdAovU3VidHlwZSAvRm9ybQovRm9ybVR5cGUgMQovUFRFWC5G aWxlTmFtZSAoLi9mYWlsdXJlX1JfMTBfUF8xMC5wZGYpCi9QVEVYLlBhZ2VOdW1iZXIgMQovUFRF WC5JbmZvRGljdCAyMTQgMCBSCi9CQm94IFswIDAgNTYwIDQyMF0KL1Jlc291cmNlcyA8PAovUHJv Y1NldCBbIC9QREYgL0ltYWdlQiAvSW1hZ2VDIC9JbWFnZUkgXQovWE9iamVjdCA8PAovSW0xIDIx NSAwIFIKPj4+PgovTGVuZ3RoIDIxNiAwIFIKL0ZpbHRlciAvRmxhdGVEZWNvZGUKPj4Kc3RyZWFt CnjaK1QIVChU0A9ILUpOLSgpTcxRKMoECpiaGSiAoIkRhE7OVdD3zDVUcMkHqg8EAJSDDfAKZW5k c3RyZWFtCmVuZG9iagoyMTQgMCBvYmoKPDwKL0NyZWF0aW9uRGF0ZSAoRDoyMDA5MTIyMTE3MTYw NS0wNScwMCcpCi9Nb2REYXRlIChEOjIwMDkxMjIxMTcxNjA1LTA1JzAwJykKL1Byb2R1Y2VyIChN YWMgT1MgWCAxMC40LjExIFF1YXJ0eiBQREZDb250ZXh0KQo+PgplbmRvYmoKMjE1IDAgb2JqCjw8 Ci9MZW5ndGggMjE3IDAgUgovVHlwZSAvWE9iamVjdAovU3VidHlwZSAvSW1hZ2UKL1dpZHRoIDU2 MAovSGVpZ2h0IDQyMAovQ29sb3JTcGFjZSAyMTggMCBSCi9JbnRlcnBvbGF0ZSB0cnVlCi9CaXRz UGVyQ29tcG9uZW50IDgKL0ZpbHRlciAvRmxhdGVEZWNvZGUKPj4Kc3RyZWFtCnja7d2LjqM6s4DR fv+XZo8U7SjiYowBV4HX0tHR/L1nEqhO/LVz62kCAAAAAAAAAAAAAAAAAAAAAAAAABr9/Vj94u/X l/9p9l9rrqtwUZ//eugyo4Z2+d+85BjKVxc+2O8B7B7JoQlfe141x9Z2+4+63ktursv/1DyB/Hdw MqyrW8vFLCKX390ed/vMcMBPXAfqexR4Rkdb2W2qHa5364ec1Z9L9YU+97vVn4UO3fZmt+Hyj1Ll LBYqubV9m11UYZe3+zdXL3z1kFYPe/nFrQMuzHz1z6sXuLr9rD/H+nE1/KvlFrjyJrH113ZvY+Xv Tv03or4L9TMvHG3N7aH+enf/ZuW5H+3RoXtK+V6MHp3pUeG2d7RHs1tszc179RJq/m35UHf/5u6V Vh5nfY/KF9h2jpUX1fav2qZ96K+1DaH8jWh4VKHtFrjb35Drbe7R7p23/jaMHhVW4/r9zskeHV1v K5f0yjv1oZO66otHR9Gwep8/x5NDbvu+XNWjhnNc3drUb8fOl/eS6z1z7m37o0vuxehRkv1R+We5 rVdi1Gwxlo/26NG1PSoM+ehl7v7k07lHu+e7e8mVw6m5w9Zf7yN65PE6PXpijzr82JykR4UnpNL2 qP7wKl8oeOHjdRf2qG3mDd+7o19/dI9slCRpuu71deGP1515FH1qev7o5I+mRx/8bFvw7+vRme1b h+eP6r87SZ4/au7RTTfCkMfr9GjMJB19/9Ghiz3zo9fuDfiS19etvgapcFJbjy20tWD3pU1tPZqq X2926JGowhFWDrly2kcfr5uqXzl26Btx6HUFU+vr68qvI628Bx19pHr3hl2zYz30UKrH61Bbh+rI A0/Nugo8YjV4x5sK37rkXnJeegQ8ZTW4/GNnDNlwAAAAAAAAAADgNSrfaPaCF2IBkLZElb/oym+/ AqDz/kiPAHhoj/4AqPjtbHToUeYzcjyOx4iGPZ5//+Xa/3vurVqP3Fkcjx45njuPJCY3eqRH7ryO x4iGOp6crdEjPXLndTxG9LLjeW5u9Kjb3I6+/8jkgaFyo0cmD8iNVRGTB7nRGquiyQNpi4NV0eQB ubEqYvIgN1gVTR7kRm6sipg8JMkNVkVMHuQGq6LJg9xgVcTkkRu5wapo8pAkPWBVNHno0CCwKpo8 dM4QWBVNHjQIqyImz2gNciPFqmjyYCuEVRGTR4PAqmjyIENYFTF5NAisiiYP9zXIzQ2rIiaPrRBY FU0eDQKrIiaPDIFV0eTRILAqYvLc1yA3HKyK7E7yY/eLJo+tEFgVO4zx++fVL5o8GgR6pEfIEOiR Hi3/yS8z1CAYcOW0Et49WPsjZAjsj/KMVI/QINAjPUKGQI8GH6MeaZAGgR7FTtL7j2RIhkCPTB4N AqsiJj9mg3wPwapo8tgKgVURk9cgwKpo8sgQWBUxeQ0CrIomjwyBVRGT1yDAqmjyyBBYFTF5DQKs iibPmQaZMVgVMfnAEgFWRUxehgCroskrEWBVxOT7lwiwKmLyNkSAVdHkbYgAqyImb0MEWBVN3oYI sCpi8koEWBVNXoYAqyImr0SAVdHk350hN0BAj0zehgiwKjLU5JUIsCr2nOTH7hfHmbwMAXoUOMbv n1e/OMjklQjQIz2SIUCPBp/k7KG53R79UiJg2GXzNSuh/VGqGAHYH+lRbIwA9EiPbIsAPWLMHokR oEdpJznI+4+UCNAjkxcjwKrI4JNXIsCqaPJiBFgVMXklAqyKJm9bBFgVGXzyYgRYFU1eiQCrIoNP XowAq6LJ54kRgFXR5G2LAKsiY05ejACrosnn6RGAVdHk9QiwKhrC4JMXI8CqaPJ6BKBHJi9GgFUR PQLQI5MXI8CqiB4B6JHJixFgVUSPAPTI5MUIsCqiRwB6ZPJiBFgV0SMAPeo5xl/Lr+eZvBgBejTa SGdh0iMAPQqZZ8IeiRGgR3q0/JurD/HdHSPfcCDPgtl/JRwz7qn2R2IE2B/pUZ4eAeiRHgVO3uYI 0KORJ5mkR2IE6JFJhr//SIwAPSLD5MUIsCoSPnmbI8CqSPjkxQiwKpKnRwBWRQInL0aAVZHwyXuk DrAqkqdHAFZFAicvRoBVkfDJixFgVSR88p42AqyK5OkRgFWRwMmLEWBVfMEEvh952vd3QOgRgB7N T3/5hwdNXowAPdIjPQLQIz3SI0CP3jSBX4+bvBgBeoQeAeiRyesRYFV80+lvecTkxQjQo1dOYOvP egSgR51Pv9sL7c5fvhgBeqRHegSgR5dPYPm00SOeP9IjQI8In7wYAVZFAynvs3a/qEcAelToyJmX ea++MK/8aj09AtCjQjvaBrK7A7q2R2IE6JEeFS5ntsPa7VHzvkyPgHeswFGfIPruHpUvyv4IwP6o PklPef5IjwA9IrxHYgTo0Qinf/71DHoEoEeHTvzaT/bu9v4jPQL0yOlnuGo9AizI6BGAHt03gZAX wOsRgB5lOP3WF06IEWBBdvp6BKBHb5uAHgHo0e/pP+v5Iz0C9Ag9AtAjk9cjwKr4+gl8H6brOY2G 6xIjQI9ef/onf9+EHgHokR4B6JEe6RGAHl01gZDflut3lAPo0RMnr0eAVRE9AtCjnhNI+3idGAF6 NNrp53w9gx4BeqRHegSgR3okRoAejTOB5K/31iNAjwif/CdGvkuAVdHpZ+gRgAXZBPQIQI86nH7m 3w/rwTpAj8jTIwCrIm37rOXX9QhAjypTcmYau8VpeKOTB+sAPRrw9E/+/qP7egSgR3rUsMnaatBq jwovorA5AkZYgaM+keDFPSpfZsP+SI8A+6PBA31H4/QIQI/6j/F8j8QI0CP0CECP+p/7hc+grV5a 2/uP9AjQo8F3NEkmr0eAHulRnh4B6JEe6RGAHg3eIw/WAZbl0U58ix4B6JHJixFgVUSPAPTI5PUI sCqiRwB6ZPJiBKBHegSgR0kmkOf13noE6JHTtz8C0CM90iNAj0xAjwD0KPz0PX8EoEcmv4yRbwhg VUSPAPQo5MRTPV6nR4AeYX8EoEcm/9sjAKsiegSgRyavR4BVET0C0COTn7yYAbAqjv167/srs/ka cj0C0KPZiV81hFl6ylehRwB6dEePvm+w1SMAPXpWj2YfC6FHwGjrcMjH47y7R99LsD8CsD862eXm QNc0SI8A9Chqy6lHAHqUYZ56BKBHbVuby+d59P1HAHrk3DtPQ48A9Khw4lG/j0+PAD1y4noEoEd6 NHkxA4Ae6RGAHkWf+FXvh9UjAD16x+T1CECP8vQIwKro3PtPQ48A9GhK+XoGAD1y4noEoEd6pEcA eqRHAHqU7dy9ngFAj6JOP+pXt+sRgB5lm7weAeiRHgHokcnrEYAe6RGAHqFHAHqkRwB6hB4B6JEe AegRegSgR3oEoEeDTHL5oUOFTyLSIwA9unmz81f4oh4B6FHnkeoRgB5FDXOrQas9+v1kcd8HYMw1 M+qXLNgf2R8B2B/pEYAejTNGPQLQIz0C0COT9P4jAD16+JZKjwCronVQjwD0yOT1CECPUkxejAD0 SI8A9Mjk9QhAj/QIQI/QIwA90iMAPUKPAPRIjwD0CD0C0CM9AtAj9AhAj/QIQI/QIwA90iMAPUKP APRIjwD0CD0C0KPHTf4TI98EAD3SIwA9Mnk9AtAjPQLQI/QIQI9umuTH7hf1CECPOozx54Xcf4U5 6xGAHvUZqR4B6FGqjdJWjz6P5OkRMOyCOWMmN8Xd/gjA/ijDJPUIQI8yjFGPAPRIjwD0aMwxrj4l 5/1HAHr0iMnrEYAe6RGAHqFHAHqUZPJiBKBHegSgR+gRgB7pEYAeoUcAeqRHAHqEHgHokR4B6BF6 BKBHegSgR+gRgB7pEYAeoUcAevSsHgGgR3oEoEcmr0cAeqRHAHqEHgHokR4B6BF6BKBHegSgR6z2 CAA96jDMv//pEYAe9drszAPz+z83UmVyAHp0+zD1CECPntKjwgN6AK9fM2fMxP4IwP5IjwDQIz0C 0CM9MnsAPeozTO8/AtCj/JM3ewA90iMAPUKPAPRIjwD0CD0C0CM9AtAj9AhAj/QIQI/QIwA90iMA PUKPAPRIjwD0CD0C0CM9AtAj9AhAj/QIQI/QIwA90iMAPUKPAPRIjwD0CD0C0COTB7AqYvIAVkWT B7Aq8srJOx7HY0SOxyHpkeNxPBYTx+MmpEd3j/dv44V0bpyOx2LieByPHvWf7XLObpyOx2LieByP HumRO4vjMSLH4yakR9+vAPBLOEJ6BAB6BIAeAYAeATBmkjxJBwAAAAAAwK7w55W23oMWcmCFNwuH DG3rekNmVT+KnvPZGoURJZxP+VYduC5lG9GwMSosxVEJCDmwrTvF8s99jm33eDrPqn4U3b53u9c+ +Iiyzef3hp3hLlZzSKmWSj0ap0dbP7nF3lny9Gj1GjMsJtnW25wjSjKfz4Wn6lH5kPRowB6tbo31 aCo+Xhc1q2w/3BYebPHz/+rxBM7nKT3KsyLpUYbj0aPdy8+2Xwt8sCXhzSnt/ihwPrtXF/iQ79a1 hK9IeqRHelR5MJnno0epelSz18jw/JoeDd6jPM9BTI96/ijwzpvth9uEI3rE6xk692j1dWsZXjKU 55D0SI/0SI/0qOfdLf9TkHoUmKTwF9VneANC4SGpPO8/CjyeQ2/K6PzmmoSHlOQmlPAtY1P69x+l WpEAAAAAAAAAAAAAAAAAAADo42/N1PGTjnY/QvnoBd56tAB0CFPs9WbuEQBRPZplYqsahc/sKn8E 5ff/z3ZkNR8LtnpphcOovMDCL4NL8vF3AIP3aFaKys80runR6hVNTR83XfkbfLb+beWF+2xngNj9 Uf3i3HwhJ3/9we4erSEolU9y6RFAeI9Wf6FDnh5Ni8frdn/D2lT9wF35MgEI2R8VLnP12ZluPWrY RjX0yO0HIEmPCtuT8p/PpKewx2m+lsppTJ4/AkjTo6nidWU1PSrsR6bi69m22rT6NwsXWN+jyevr AAAAAAAAAAAAAAAAAAAAAOD5/gOeJDZsCmVuZHN0cmVhbQplbmRvYmoKMjE2IDAgb2JqCjUyCmVu ZG9iagoyMTcgMCBvYmoKMzc0MAplbmRvYmoKMjE4IDAgb2JqClsvSUNDQmFzZWQgMjE5IDAgUl0K ZW5kb2JqCjIxOSAwIG9iago8PAovTGVuZ3RoIDIyMCAwIFIKL04gMwovQWx0ZXJuYXRlIC9EZXZp Y2VSR0IKL0ZpbHRlciAvRmxhdGVEZWNvZGUKPj4Kc3RyZWFtCnjafZJPSBRRHMe/syVCrAVlJlLw TrYHVwbtYB2M3fVvyrasa6YIss6+2R2dnZ3ezG4lHkKILkHWMbpY0Uk6hgcPHQIPEYJiXSLoKBkE gpeQ7Tczu+6I2oM37zO//7/fe0BdKG2aeoABecMWyf4ouzs+weo3UIcGBEErrVhmJJEYdplscWTt fYXknJvh4/X/XQ2CEgISVYDGrMfXHJ72eMDh+7ZpE086rOTSGWKTuE2kkjHiV8Rnsz6e9nGGWwrx MvFNxRQUJ5AiHigpWSfmDrFsZDSD5JeJuzKWkicm38BTZxZemfYQ0H0FOPW5JpuwgOV3wKXWmizU DFwcA1Y6a7LdpDsfqWndUjs7XJEUjAJ1P8rl3Vag/gWw/7xc/vu6XN5/Qzm+Ax91pShKlRlJ0hfA 68Ndjf3c4EJTmHNfCVFQNZ37Rnq82uvXi0f1Jat0EnszcVcXsET3MHYGGHoMvPwJXH0PXPgAJBqA 1HUEHqG6bf7AzRMrmA+Fls3ZrEOWO1jYOTpZhF4IZ7FC3izaXLBBQ2lvY2ldZ66pxQS3uCjxTDvy erHa7znaQW6MjtBJ8wqo3OqtsDSTSffQ3aCdeCPDe3qdd0G8qGp9g86F0P6kir5Rj6Xzmj2Y8jjQ bejx4QrDKMRvezGxY9rRZDW+VRrprcpn0rcSdLaQ/MZsYcixaSLf0FwuNeaxlJrLxeIVXsU4dHBo MOhrgCGJfkQRhgmBAlTSaGShkZS7NoLYwuyxljoSPmak3yafbdfnHork7XjdQTSOhbaDCEz+Jv+W t+Ql+a38a7GlGKppFsSUpqw/+0NxnczVuBVtpSYvvkJ5I6TVkSVp/qAny1eprzrVWGypRXJy8Cfx PV+X3JcpjGk30qybqeTqLPpGfNlOmh7Zrs2vNtdybZ1emdwMrs0fmlXhSFf8oKvD/zU7vz//B82w AWgKZW5kc3RyZWFtCmVuZG9iagoyMjAgMCBvYmoKNzA2CmVuZG9iagoyMDEgMCBvYmogPDwKL1R5 cGUgL0Fubm90Ci9Cb3JkZXJbMCAwIDFdL0gvSS9DWzEgMCAwXQovUmVjdCBbMTA0LjAyMiAyNDEu MTIzIDExNi45MjQgMjUyLjgxM10KL1N1YnR5cGUgL0xpbmsKL0EgPDwgL1MgL0dvVG8gL0QgKGZp Z3VyZS4xMikgPj4KPj4gZW5kb2JqCjIwNiAwIG9iaiA8PAovRCBbMjA0IDAgUiAvWFlaIDU0IDc0 Mi40NTEgbnVsbF0KPj4gZW5kb2JqCjE1OCAwIG9iaiA8PAovRCBbMjA0IDAgUiAvWFlaIDE4My41 NiA1MTkuNzIxIG51bGxdCj4+IGVuZG9iagoxOTcgMCBvYmogPDwKL0QgWzIwNCAwIFIgL1hZWiAy NjYuNDA5IDI5MC43OTYgbnVsbF0KPj4gZW5kb2JqCjIwMyAwIG9iaiA8PAovRm9udCA8PCAvRjE1 IDYzIDAgUiA+PgovWE9iamVjdCA8PCAvSW04IDE2MSAwIFIgL0ltOSAxNzcgMCBSID4+Ci9Qcm9j U2V0IFsgL1BERiAvVGV4dCBdCj4+IGVuZG9iagoyMjQgMCBvYmogPDwKL0xlbmd0aCA4MTQgICAg ICAgCi9GaWx0ZXIgL0ZsYXRlRGVjb2RlCj4+CnN0cmVhbQp42tVVTVPbMBC951d4uNSeiYRWH7Hd WwmkA6UMhcz0ABxMrARNHTuVFFr+fSVLTkML7aGnjmes9Wr3efdpd0WSVUKS96Oj+ehwBiIBgktS QjJfJoInOZ9gAZNkXic36Wmb0SK1UrfSomNdLW2GSsrKtPYyslptKvugkO6aBulNg4xae49tU1nV tYhAhop8UqbHciHdTp7eZ8i9pc4QYzylhJTZ3fxsRGJMw3oyH4ETSAIJ5AXmHBIXFC4LlizWo68j gjkBoL3JvtxvDp5RcXi6BpIcd6NP7hl+MNigAR7t4b/ATFFgQVnCS4Z5DoGdmVpttfSZsBTI2wxx LtLp8extUJ13xgSpW4Z0F13byoVVj8p6lp7C7rLTQajVLQEmtWw9UzYo3zfdfdUE+UpuKhWpu/QI UquuJ7Qe72mrhX9/6Q1s0F9VNgZKyaHBL3L+B+5pQXHOd9TTgoiB+p38GvXwd+p/wr/OPBUlprR4 gXn4T5iHV5k/nLE8AY4Zn1CfMmK8z9m54QnEaptkyFW5cKEsfaALaTxWcAVcCtG7Escmx7kYnDBE t4tOr11TPmYMUh9Q/jvSc949EsGi5AHp5mrm05pSgPLO+YNIj3RVt1J7AqBIr/H4Fhj/IJ/C7jdv 3unahM/AtRO2RgZBtWGNwNHOdn7lbvTUahG48zby61ZpuZZhIAXluXz0xyUbcxBjOJpehi3gUePB 83QaMH3sY5+rTw4YFiLk9rHS/cE9xIMqyxy/Qi53leoPKZBLI7mn7fJf6Z1WxlaNqhDF1PNLXDbd tlGmT4Sl73AUDgZLX/aMut889vXmVO0qOG6UXVZNY8JXz7Nba2nUqt0Z1cq4+X2/tbIOiqpZdVrZ h/Uvfp+vL8bPNZe6Q/s08jIksZCydvi/9J59iA0gbCRY7a6V/poITdY3aWQsArRhPdm/Oeq6j9eZ uzvJw8Q6C00Xt4xszdDb5slYuY4x3RJBrmV7/WTekNx9wMF4dxPlz5vTJycIhklspXlWsDReeOOA JuOkqBrsC6HIIT35vnF1Gv92tm1lhOfjYfwCcbacEZ7ehJmxijbgzn0/ADeHfwCjKuPSCmVuZHN0 cmVhbQplbmRvYmoKMjIzIDAgb2JqIDw8Ci9UeXBlIC9QYWdlCi9Db250ZW50cyAyMjQgMCBSCi9S ZXNvdXJjZXMgMjIyIDAgUgovTWVkaWFCb3ggWzAgMCA2MTIgNzkyXQovUGFyZW50IDEyMyAwIFIK Pj4gZW5kb2JqCjE3OCAwIG9iaiA8PAovVHlwZSAvWE9iamVjdAovU3VidHlwZSAvRm9ybQovRm9y bVR5cGUgMQovUFRFWC5GaWxlTmFtZSAoLi9jb21wX2ZhaWx1cmVfMjAucGRmKQovUFRFWC5QYWdl TnVtYmVyIDEKL1BURVguSW5mb0RpY3QgMjI2IDAgUgovQkJveCBbMCAwIDYzNiA1MDBdCi9SZXNv dXJjZXMgPDwKL1Byb2NTZXQgWyAvUERGIC9JbWFnZUIgL0ltYWdlQyAvSW1hZ2VJIF0KL1hPYmpl Y3QgPDwKL0ltMSAyMjcgMCBSCj4+Pj4KL0xlbmd0aCAyMjggMCBSCi9GaWx0ZXIgL0ZsYXRlRGVj b2RlCj4+CnN0cmVhbQp42itUCFQoVNAPSC1KTi0oKU3MUSjKBAqYGZspGAChqYEBmE7OVdD3zDVU cMkHqg8EAJTeDfMKZW5kc3RyZWFtCmVuZG9iagoyMjYgMCBvYmoKPDwKL0NyZWF0aW9uRGF0ZSAo RDoyMDA5MTIyMTE3MTM1OC0wNScwMCcpCi9Nb2REYXRlIChEOjIwMDkxMjIxMTcxMzU4LTA1JzAw JykKL1Byb2R1Y2VyIChNYWMgT1MgWCAxMC40LjExIFF1YXJ0eiBQREZDb250ZXh0KQo+PgplbmRv YmoKMjI3IDAgb2JqCjw8Ci9MZW5ndGggMjI5IDAgUgovVHlwZSAvWE9iamVjdAovU3VidHlwZSAv SW1hZ2UKL1dpZHRoIDYzNgovSGVpZ2h0IDUwMAovQ29sb3JTcGFjZSAyMzAgMCBSCi9JbnRlcnBv bGF0ZSB0cnVlCi9CaXRzUGVyQ29tcG9uZW50IDgKL0ZpbHRlciAvRmxhdGVEZWNvZGUKPj4Kc3Ry ZWFtCnja7d3bduumAkDR/P9Pqw9pM1xLIO5CMOc4D/ukucggs4Kt2McBAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAOzu58P4Hz3yNqZ88OvAGh5hj+85wyQ+MteXNzZ9BCKfc3meWCWAHivh ksvL5Y1KvKU9mrvnJHYaycvfZG5/luYCsy2D513D778jq1zK1uPzm3x9PP1r42vm5yekbIhCP+h2 ST8PSOjYPv9T5Mt77NpCNy33hsSPJ/4dUial4aMHt+dV5HS6/K+yC3RtbmgV+lqmzv8ppVORzyz4 2qwdUOJaXXk8iT8xPp5Z+6zQg+fptzdxQCK3LndI67eQib9LFJyKDQ8SoLi5xQtp+pJeufLnNvc2 iwXHU/zNK8OUvqVtMrAp51LZqZLy9HTkEfXc8yoUYs0F3tXc8+KZ+BjgyOZGDjIrVfFS5Da3+LKo grzWdzD0QHTbmxY5yJrzSnOBBZpbsLz32I51fWw5fWUu3ufmzmOn5qYfQ/rDvJHdenrf68+rw2PL wBPZLS5R1vO5/Ro3oLmJe/aGzc29Cjf9puWWqCB5PZ7PLZj6c0mPoksLAOqzm3id6u26FP8m8R1E 1gEc0ScQI18V+dGXB3l5hGVXGke+PP5gdcp+M30Si29IynXL8SFtdd1yaCMcv7GhX05uzzHXLQOT 75cxzgYTwPJlkDGegOULnLQAAAAAAAAAAABAE6H3DS9+FzMAILGt5397pVMAaL7P1VwAmLa5PwC8 nBq+qLmGMXecT//1MIpOJ6P04EBt3h1nlObuc0oLrtPJKGmuM0pzNVdz3feNUu6RTXU2a677neYa Z8113zdKmuuMMtSf51763+earIW2BYAQYLI0F8AyjsnSXMAyjskSXHBOYxk3WVifYK51zDVUmCzN BTTXMo7JElzQXMs4JktzAc21jJssBBdntuZaxjFZViawz7WMY7I0F9BcyzgmS3BBcy3jmCzNBTTX Mm6yNNeY4eTWXMs4JmvAgmTAWPPkxjKOyZqstprLIlWN/18s45isp1NrqFinqs5myzgma9bUGiRU Fcs4JsvGFlXFNVTOAZMltaCqmmsZx2SpLaqquZZxTJbUoqpormXcZKktqqqqmmsZx2RJLaqquZZx TNZsqXVuyqiqaq5lHJNlY4uqormWcZMltagqmmsZx2Sp7dZVNc1oruaaLKlVVVUFyzgLTZbaqiqg uSZLalVVVcEyznsny1/9qCqguRMO/vlygssPvmWypFZVIWXd01weHPm/f19+cP7JklpVBc3VXM1V 20UiC5qruQxv7qepakttc0Fz17298yzdzr3PWXjLPldtkzprdMA+1z534ll4RXOl1uiA5mqu5koK oLmaS3zk39JcjycDmqu5rz73XvT3uYILaK7mmizBfXxujAForuaaLME1QIBlnLdMlp4AaK7JElwA yzhrTJbgAmiuyRoWXCfIzRgBmeuYa6gwWYLrgQDQXM1l/GQJLqC5mutcFVxAcy3jLNZcAM3VXM0V 3BlmwhiA5mquyRJcDwSA5mouk0+Wp3EBzdVcBkyW4AKaq7kMmCzBBTRXcxnZXIwR6KzmormzZBfI 7OwnY6K5JktzRRa6plZlNNdkaa5Bgd7BNSCaa7LkBWiYV0HRXJOluUYBem9jbWY112SpTdVAAGmp 1Q7NNVmaC/RurgHRXJOluW42NGyrTGgumtv+loOFxePGmovmiiwMT60iaC5dJ2uv4DrbsYBcNdfg aC6aC7Tdz1r8NRfNtbGFfp21n9VcNHdcdkFt3RE0F80FWhQ21Fzjo7lobt9drfOZ/TazlnTNJeuO c/tBzc24PbBBZ+1nNZfikf/79+UHNdfGFsuF2moummtjC52qGvqvxkpzqbyXxUMculdqLrz3zn5E Hy72LO0mv02x1T5XcGHAGpuye7Uy2+eiudOOnd8VWKCkCqu57NNc4YJ4KBs21wijuZpr8tkwqc13 r4YXzX3XOnD7weaTJbjstmn1jCqay1OTpbkoqQUQzWXAZHkdDN7S08rmGlg0lxmaCw8mtdXu1cCi uUw+WbaJdEpqq5JKKpZxVmouNNmuujYJNNdk2eTSMKZKCpprsvYNrt8bWiS1cvdqSEFzTZZYbZ7U ypJKKmguTSZLcFfdsebuXo0haC4DmsvCJdVT0FwmmSyb3AmTqqRgGWfV5i4zBBPemFbXJjnD13uM gj1p7s7NtckducZGPtPQuVfilHDC7NBc+pVUUp05BgHNde+2yb3Na1lzwRKK5prKUHCXejK36X7W GYXmorlobr9Nu9qiuWgu/ZqL5qK5aC5d792rbXI1F81Fc9FczcW9EjRXc5d5IyHNRXPRXKZv7ho3 u+Et0Vx2aG6nP3a7rcnl39k9NUTnn1s8IJlrr+Zud+/2wLLm8uC98u8OOPJ/kaMafM4/fhcL/Q3+ mCPUXM0FNDfUo7/daOiFYs7fJ76BDf30r69K/HEVrzOf19zI4Z1vQuSoNHfb5gLL7+kKqnf+4PkT IsXJjc75q84PO98e2Jjm3h7e5Vhprnv3Cs11ZqK5FUd1+XxuvKTxDWBki5pb/NzEJ966JvvcguPU 3M3v3Ys8sGyvjua2OKrLB5ZD+7XQJw9obvzAxuxzNZfi5hL5Ddk4sE9zb1uZvvkds89NiZp9Lpqr ubhXvqi5lc/n9muufS6aq7mwQHOP0uuW45cc1zf3iF4m3Wpq4ltjzaVgsl7/ZG7nQ9dcdmjubjfh ReNptJds7qtv5NH5z9Wd8wiWCmjuhvMSupg/1IUtmjtk2I0DgqUCmmuO4k8WaK7mIlhoLq0mqLK5 gqu5aC6aS6vmxv8qTXM1F81lqlPi8r2WmGd2ttvnej8GNBf7XDTXrhY0F83VXMFNq63morloLilV 1Vy1RXPRXLpOTfHf52qu2qK5aC6jpvI9zW193ZTaorloLsOmcvOLf9UWzQ39FvrT9Jfb9B/69f4I T43A7Qebz7Lm7tNcQwFTnIpfHxz2fwNHNfj+8vjdM/0dge1z0dyCX19BcxObW/Zefpf9+sn86fE3 BIwcWJMJSnz/3JS39I0vQZqruYvV1knLK+6V8xxVj/esT4/O+avODzvfHljxihHf/F5+fuTwLsdK c3e7d7/jydyKQ1RbNLf4LnPbncQN4NHzPetvDyzl1jXZ5x7es541mqu2aO4TR3X5wHJovxb65AHN jR9Y/VBoLm2bu3BwTT2aW3NU8Yqlb37H7HNTonb3bi+Nt/Oa6969SXNNOs7STs2tfD63X3Pr97ma S7979zIPLNvSorm9m3uUXrccv+S4vrlH9DLp4vUk6+9zNZd3Nzf5yDxpi+a6CZucEkZbcx/f26ot guUmaC4vaq7agmBprubSdSrfuMlVWzQXzUVzRzbXbKK5aC6aW3+Ux6Ovrw6ai+ay4T7XY8hoLk4J J8xizZ25tk4wNBenhBNmgamccJPb6Z2yQXPRXDRXbXGvNAhoruY+Fdwt3soXLKForuYCmtvtcafb mpw9NUQFr7fcapY1d+3mTnIyg3tleoniRSj7zOha8TPVmIw8gKy3J7DPZarmetIW3t7csvcVuuxX 4hvrhL4q8ce12pYmvpdfytsLxhdAzdVctYVV93QF1Tt/sOD9c9Ojc/6q88POtwdWcPMj7wwYau7t 4V2OlebucO8e9mRudm09x4zmTnBUl3fb5m/mXlb8yvesv12U0n+LaHKcmqu5ze+2Bh9eus+9fGA5 tF8LffKA5sYPrP7may7z73OdHvD25t62Mr1QY/a5KVG73edqLj2a22Nja5xhh+ZWPp/br7n2uSzf XA8jww7NPUqvW45fclzf3CN6mXTNmnb7Qc1lWHPjf25Q/E1dQ4XmuglOCaOtuaHaGlvQXDR3+anJ evTj4/GN8uaqLQiWCmju3pvWpCcLvppb2XpTAIKF5u48L2OaC2gumrvhvGS9OtnXO+ZNe8P8QoAF FqfEad32jN7D85J7IXrxPtdEQ9c7MiRW1VI8w+9CmgvggRE0FwDN1VzNBdBcslJY/Pe5kzbXNVQA mrvQZNnnAmgumguA5mquAQTQXDQXQHPR3NxDdA0VgOYuM1myBqC5aC4Amqu5AGgumguguSzT3NHX UAGgue0G7a9iIwfwBc0FQHM7jNjlGxNoLgCaq7nmDkBzNVdzATSXSMIib7q3aXNdUQ2guWtNVm7Z bHIBNBfNBdBcIvG6NG1zBRdAc9FcAM1lpeaOPDhXTwFobuvkTfHYMgCai+YCoLmdRmy2fa7ncAE0 d4Gxmue6Zc0F0Fwj9mxzx786lpefAtDcRTfasb49EFwANLd7+555bFlzATTXiD3eXMEFUBAjNqC5 ggugIAZt8ea6egpAc/uG7+Hnc21yATSX8c0VXADNJWu/nNLQ+D7XkAJo7sK5rBnAUFUjnxBqLgCa u/aInf+xV3PlH0Bz39PcyweWU5rrwWSAtyTjkWtuNTfrex4eWwawzyV8+dPg5j72dgYAaO5rR/41 zf3NLgCaq7kAaO4GuSz7Pudopv99ruYCaO5uI/bUaz+OCK4ncAE0V3OHvfyUMwRAczXXA8sAmrvB oD3yB86aC6C5rNNcT+ACaK4R+6+5X3vtHj/GLANo7uaD5rFkAPnYbcSees1qzQXQXF7cXE/gAmgu w/a5zgEAzZ26ff/2b/zfCn0eg7kA0NwdRqzh++dqLoDmsmBzPYELoLmaO2yfa9IBNPc9g/bgaz82 aC4AmovmAmgumguA5o6u3s8Mr/2ouQCau8lYPTJutc11xTKA5mqufS6A5jJrcwHQXM3VXAA0t0Xy fryXHwCau0f0y7/YBVQAmktBc11DBaC5aC4Amqu5AGgumguguazQXBdQAWgu9rkAmovmAqC5S09B 5HU2NBdAc6nbul6/pOR5ajQXQHOpGfy+zXX1FIDmUtrcwS/yDEDNOv/I6/MT+m2nbJ8LgH0uucOu uQCaS9dhv3y0oXFzTS6A5pK55/1qbtKTAq6eAtBcolOQ8ve5nogH0Fx6T5bmAmgumguA5u7YXNMK oLkMa66ZBdBcBjQXAM2lurmCC6C5aC4AmrtRc00ogObSqLm3nyS7AJrLiOYCoLloLoDmorkAaC7f zQ1311QCaC7Dmms2ATSXAc0FQHPRXAA0V3MB0Fw0F0Bzma25v1dPmUoAzcU+FwDN1VwANBfNBdBc nmyuYQDQXJ5rrmuoADQX+1wANFdzAdBcYs01XwCai+YCoLmrN9c1VACai30uAJqruQBoLpoLoLl0 aOjXFERe4FFzATSXypH/+/flB++b6xoqAM0lcxYKmwuA5pIw/qHOhprr3YUA3rXIW7rtcwGwz9Vc zQXQXDqNfFVzXUAFoLmMaS4AmkvC4Pv7XADNZdpGGwcAzUVzAdDchZr7/SEXUAFoLiOaC4DmorkA aK7mAqC53DfXfAFoLsOb6+opAM3FPhcAzdVcADQXzQXQXDQXAM3dtrkuoALQXOxzAdBczQVAc9Fc AM1lruYaBgDNZWBzXUAFoLnY5wKguZoLgOaS0VzzBaC5aC4Amrtcc11DBaC52OcCoLmaC4DmorkA movmAqC52zbXBVQAmot9LgCaq7kAaC55zTUMAJqL5gKguTM39Lujlx/8X3NdQwWguZSO/N+/Lz9o nwuguTSfhYTmmi8AzaXlhjfW3PCDzwDMtsJ/MSbz/M6T2FzjBmCfS+Xgpz62bNYANJe6kfd8LoDm orkAaO57R/7yWfW7v881XwCay6BMGwcAzWVQc00ZgOZinwuA5posACzjZE2W+QLQXEwWAJbxxfa5 pgxAc+k/WeYLQHPRXAA0V3MB0Fw0F0Bz0VwANFdzAdBcNBcAzdVcADQXzQXQXDQXAM01WQBYxjFZ AFjGTRYAlnFMFoBlnHkmy3wBaC6aC4Dmai4AmovmAmgumguA5mouAJqL5gKguZoLgOaiuQCai+YC oLmbTpb5AtBcGo3/z39MFoDm0mrkz239/L+XOTZuAJpLk/HXXADNZZLmfjJ6APMv8pbuF+9zzReA fS5jmguA5qK5AGiu5gKgucbf3+cCaC5zTpb5AtBcTBYAlnGTBYBlHJMFYBnHZAFgGTdZAFjGMVkA WMZNFgCWcUwWgGUckwWAZdxkAWAZx2QBYBk3WQBYxjFZAJZxTBYAlnGTBYBlHJMFgGXcZAFgGcdk AVjGMVkAWMZNFgCWcUwWAJZxkwWAZRyTBWAZx2QBYBk3WQBYxjFZAJZxy7jJAsAyjskCsIxjsgCw jJsso4SBMkoGykBhsoySgTJKBspAMdOM/DJZTmkDZZQMlIFizHScp8ZkOaUNlFEyUAYKzXVKGyij ZKAwUIs1F4BXU7q3NBcA0FwA0FwAQHMB4Nnsep4dAAAAAAAA4EU8z3s5Gl9jcjlKew5d5DVVyj64 wyg5r9IXH6dTykA5oxZYGcxIaBAuR2nDoQvdnRMHZ5MRux0l51WTM8dAOaM0V3M3HCKLZO4oOa8i Q+F0KhgoZ5TmLrBJCY2MM1lzy0bJeZW7Cjmd4gPljNJcv3trrhG7vYFGyenkjJIV0+FMtkhaIR8f JadT7ulkoDR3vQFxJmuuURrTEQNloDTXgDiT1cQoSYmBotWE+tOt2wHxV2+Ru60RM0o1d7TivzA1 UAYKAAAAAAAAAAAAAAAAAAAAAIAZ/JzEP/nrH81/+u93bvL946/Dn/L5ANC2ucO+anDvNBeAtzQ3 8s7aKa/N/vl/03fQt98qfoSRb3v7tbevLe/FbwHo0dzE1IY+Lfe9USLN/ctupL9ZtyL91h3e5AWA ps29fTK3oLkpO830fW76j07f52ouAJPsc79yXJOnlAu0ypqb/p0j79CXtXn38DIAzZtb+dhy7paw cp97+52z3on+9kYBwIPNTXkOd/xjy6H/mn7rPLYMQO/mHv+/TDd+/VLl1cVlzT2SLyS+/ITIrbu8 UYfrlgEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAYCb/AIh1k/AKZW5kc3RyZWFt CmVuZG9iagoyMjggMCBvYmoKNTQKZW5kb2JqCjIyOSAwIG9iago1MjMwCmVuZG9iagoyMzAgMCBv YmoKWy9JQ0NCYXNlZCAyMzEgMCBSXQplbmRvYmoKMjMxIDAgb2JqCjw8Ci9MZW5ndGggMjMyIDAg UgovTiAzCi9BbHRlcm5hdGUgL0RldmljZVJHQgovRmlsdGVyIC9GbGF0ZURlY29kZQo+PgpzdHJl YW0KeNp9kk9IFFEcx7+zJUKsBWUmUvBOtgdXBu1gHYzd9W/Ktqxrpgiyzr7ZHZ2dnd7MbiUeQogu QdYxuljRSTqGBw8dAg8RgmJdIugoGQSCl5DtNzO77ojagzfvM7//v997QF0obZp6gAF5wxbJ/ii7 Oz7B6jdQhwYEQSutWGYkkRh2mWxxZO19heScm+Hj9f9dDYISAhJVgMasx9ccnvZ4wOH7tmkTTzqs 5NIZYpO4TaSSMeJXxGezPp72cYZbCvEy8U3FFBQnkCIeKClZJ+YOsWxkNIPkl4m7MpaSJybfwFNn Fl6Z9hDQfQU49bkmm7CA5XfApdaaLNQMXBwDVjprst2kOx+pad1SOztckRSMAnU/yuXdVqD+BbD/ vFz++7pc3n9DOb4DH3WlKEqVGUnSF8Drw12N/dzgQlOYc18JUVA1nftGerza69eLR/Ulq3QSezNx VxewRPcwdgYYegy8/AlcfQ9c+AAkGoDUdQQeobpt/sDNEyuYD4WWzdmsQ5Y7WNg5OlmEXghnsULe LNpcsEFDaW9jaV1nrqnFBLe4KPFMO/J6sdrvOdpBboyO0EnzCqjc6q2wNJNJ99DdoJ14I8N7ep13 Qbyoan2DzoXQ/qSKvlGPpfOaPZjyONBt6PHhCsMoxG97MbFj2tFkNb5VGumtymfStxJ0tpD8xmxh yLFpIt/QXC415rGUmsvF4hVexTh0cGgw6GuAIYl+RBGGCYECVNJoZKGRlLs2gtjC7LGWOhI+ZqTf Jp9t1+ceiuTteN1BNI6FtoMITP4m/5a35CX5rfxrsaUYqmkWxJSmrD/7Q3GdzNW4FW2lJi++Qnkj pNWRJWn+oCfLV6mvOtVYbKlFcnLwJ/E9X5fclymMaTfSrJup5Oos+kZ82U6aHtmuza8213JtnV6Z 3AyuzR+aVeFIV/ygq8P/NTu/P/8HzbABaAplbmRzdHJlYW0KZW5kb2JqCjIzMiAwIG9iago3MDYK ZW5kb2JqCjIwMCAwIG9iaiA8PAovVHlwZSAvWE9iamVjdAovU3VidHlwZSAvRm9ybQovRm9ybVR5 cGUgMQovUFRFWC5GaWxlTmFtZSAoLi9jb21wX2ZhaWx1cmVfUF8xMC5wZGYpCi9QVEVYLlBhZ2VO dW1iZXIgMQovUFRFWC5JbmZvRGljdCAyMzMgMCBSCi9CQm94IFswIDAgNTk2IDQ1OF0KL1Jlc291 cmNlcyA8PAovUHJvY1NldCBbIC9QREYgL0ltYWdlQiAvSW1hZ2VDIC9JbWFnZUkgXQovWE9iamVj dCA8PAovSW0xIDIzNCAwIFIKPj4+PgovTGVuZ3RoIDIzNSAwIFIKL0ZpbHRlciAvRmxhdGVEZWNv ZGUKPj4Kc3RyZWFtCnjaK1QIVChU0A9ILUpOLSgpTcxRKMoECphamikYAKGJqQWYTs5V0PfMNVRw yQeqDwQAlmEOBAplbmRzdHJlYW0KZW5kb2JqCjIzMyAwIG9iago8PAovQ3JlYXRpb25EYXRlIChE OjIwMDkxMjIxMTcxNDEzLTA1JzAwJykKL01vZERhdGUgKEQ6MjAwOTEyMjExNzE0MTMtMDUnMDAn KQovUHJvZHVjZXIgKE1hYyBPUyBYIDEwLjQuMTEgUXVhcnR6IFBERkNvbnRleHQpCj4+CmVuZG9i agoyMzQgMCBvYmoKPDwKL0xlbmd0aCAyMzYgMCBSCi9UeXBlIC9YT2JqZWN0Ci9TdWJ0eXBlIC9J bWFnZQovV2lkdGggNTk2Ci9IZWlnaHQgNDU4Ci9Db2xvclNwYWNlIDIzNyAwIFIKL0ludGVycG9s YXRlIHRydWUKL0JpdHNQZXJDb21wb25lbnQgOAovRmlsdGVyIC9GbGF0ZURlY29kZQo+PgpzdHJl YW0KeNrt3Q1zmzoagNH8/z/tvbOZuq4B8SKEPs+ZndneNE2wBDyRjcPrBQAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAPz186H+t675GCMf/Nqwglv4xNfsYRJbzfXRhEa+UeJzdr+sswTMF77pD/PdBxV8 pE+0b81JLDuS28Z9/ufp99I+EL74Geb3z7vrl/dfbc9IiS/y9fH4v02fuz4/4eg8mf6c7WNM/G36 e23/KvHPn1jFHD20qw8kvT3prxCZlILFP92vErvT7t/KHyzSvqOzwdfpYvtXkV4kPjPj30Y2O/GZ weRd2p7gd0yP56V1x9GTuvHHGxyQxKO7OqQ3l1SR9mXviqU2EpijfdkntPip9eYZ+Gr7TvOUsT3Z X/xmIOJLvCIDG9mX8naVyMuXl9oXWR6erhMB7YtXYPt8V+S5qZrtS2zkpWSkz9hX25d9+UpG5u73 6OgJ0rIP7Wr7gvuV9oH2FWxfxmn2ieXJo895xs+Q2eu+7Ao8tO6L7zB5D63gui9jqe45T1gwf9lF uPR633OtqdC+4Bq2YPuuXrUYf2hXi3B15F+dvd63uzgt+3MIMFD+gtf1nZ4f0l8k/RP1pQ14JV9g SvyrxLfe3cjdLcy7MjPxz9NPokbWX/FJzH4gkes800P66HWepw/2KJen+5jrPIH4iQjjbDABpxEM svEEnEbATgsAAAAAAAAAADCuS29fddUWAKNXL3h7Sr95D4CJ133aB4D2vQK/vx2ApwlWb+3r87HY EltScGP++xfv/5kgW/K9Zyx2BGmfQ8aWrNC+J6pngmyJ9mmfQ8aW9LkxDy33TJAt0T7tc8jYkg43 5unqmSBbon1djefV9/eZEWY8LmqEDz5PsNo3ej1B9Vhrj9E+7QPhA+3TPlA90D7tgy6rZ19G+9A+ LPdA+zAjqB7s7Enap30gfKB92geqB9qnfdC0evZZtA/tw3IPnGkxI1juwYU9zJlW+0D1WGQPc6bV PugyecJHsbql/9OZVvugj+TZNylZt8fa51oX7YMiybNX0nPstE/7QPKYvm7ap30geaxWN+3TPiiV PNRtlLppn/aB5LFa3bRP+0Dy1G21ummf9oHkqZup1T7tQ/Ikb/7YoX3ah91G8tQN7dM+Fk4e6oYz rRlB8lA3nGnNCJKHujnTGgQzguSpm9g502JGkDx1Y9yzqGtdOpmFr3He/aAZQfLUDe2bbBH3/vPu B82I87relYwd2qd92sc41VM3dUP71mzfJ2O4SPXETt14tH0/Gwaqwix8DrV1H5/hWzp2YN23zBpQ +1Rv5uqJHdqH9jF9+MQO7eN4eLVP9SapntihfcRmwfv7hG/g8Ikd2kfFpSKqJ3bgTGtGED6xA2da M4LqiR0405oRhE/swJnWjFA/fGIHDc+irnXRPlZZ7okdaJ/2MX34xA60T/uYvnpiB9qnfUwfPrED 7dM+pq+e2IH2aR/Th0/sQPswI9NXT+xA+zAjA1bvwhRtP9v8gvZhRsbpXeZyz4SC9qF9A/Zu5tus gzMtZkTv7q/yzCA402JGVlvfmUFwpsWMjNA7ow7OtJgRS7xrXxro6SzqWhft07vHl3imDLQP7Zu7 dyYItA/tW2d99/n9AO1D+7rpXYN7CQHah/ZN1jszAtqH9nWTvKpbAGgf2jflEs/SD7QP7Vuzdw4K 0D60b5313edmAdrHvVn4GufdDy4yI+ne9fLoHRdglUGJ4X3/efeDc89I771zFID2oX21qtfXVgKD n28TT6lpX6vpSAdxd/ommJ1hbpfgQIBhS7cV+XxjaN33dPUA7nftTvus+7SvZvgA0oHLK9rNdZz2 ad9D4bOVwP2iPfQspfZpn+UeUDxt2e2rf3Km/rp+phkRPpj+VFZkNdfbwgQzcjN8wJSLuKurOWda pp8Ryz0YvW557XOmZdkZGSx8Is1Kdbu/mnOmxYwoCfS/gpvy+UntMyOWe7B43fLah/aZEeGDno96 z08605qRPsMH3F/BXV3NGUPtMyOWe2pN/4HLax/aZ0aEDyZbzRk0Z1qGmBHVQ9QureaMnjMtQ8+I 5R7rBC5vNYczLZPNiPCxzlJut31GzJmW1WZk+OrJtsZ5fhLtMyNWfCy5uDMgaJ8ZET4WaZ9xQPvM yBLhsyejfWifGdE+tA+0z4xMHD7QPrTPjAgf2gfaZ0bmC59dF+1D+8zI7fYNN1L2FkD7zMhCiz4A 7TMjwgegfWZE+ODsd3iyJu1buX3jhc++Sjh2frwnfY61Y2if9qF9aB8rtM+znWgf2sdS7RM+tA/t MxRLtW+k8Nk50T60b9jDcHsrscTNxeq0b5ThswuhfWjfHAu69IH56Ix4thPtwx5ix6gfvobtEz6m L532oX3jtm/3adJS7et8mOwq7O78p29V1j7u7GA8Hb7m676uw2dvVLRk0U4/7fTo6200yp6E01+q t99wkvjJv+wDt+7TPrPNQyfwykW7eVZ8P/9f83/Bc0KT6HTyg1CdLdS+pdonfNxcj3RVtInbt3tZ +Ov4lc3d80n69H703b/+VfDbZU/r1fYlNm/7EBJbpX0N1/Xa93ezULSp1zgZ9dl+cPsJiTN/8OSf +Ebbp0NPN6xO+043b3estK+fQ6/++/t6bJ+1aLmcrVa0Cdp39M7fYBDT6Tx94S/4z4Opjf+sdX/d l7Gd2rfyoaozI+ZM0VZY9+0+4Xm0fjn65ArtS29YnXWf9jlUhW/cnCma9kWe88xYDNZZ90XiYt2H 9n1viqIpmvY9/3rfc+2z7kP7pll/3u+UomlfqdN+xnWe6Us077fvlbystNTUpI8R7XOoTtScNjlT NAeUh7D4LmFUtU/RFM0B5SFoH5Pt50OET9EQDu3TPvMyR/sUDeFA+5ijfYqG9qF9zNE+RcMBhfYx x6GqaDigDALaN9Oh2mPR/AYZtA/t47FDtdM1mvahfWgf1dsnRKB9aN/c7etiEWYXQvvQPvo4VOuF zy6E9qF9LNU+0L6srXrixffTX2G9+ypJkyFKX5/w6Cxr38SH6oPh01QmOKC+PljtPw+2qvJ5uPlp P+/29NZ92tc4UPYZtO+x9uXdw2i3Iz8Xv3v6RkiJDSsyQcH790VuKRi5Z672Ddq+5F2u1Al6WeNk 1Gf7wYx712bcMP3zWdBgaO4Mb+JugEftO9283bHSvhXaVz58Uor2PbBVu6/35T0Z2Nt92y+9mlnk Ybp3rfY9Uio7Cdr32FbtPuF5tH45+uQK7Utv2P2h0D6Hanb7LNFguPadNiu+GKyz7ovEJb3uK768 1T7tKzCfCor2ddC+m6/3Pde+++s+7aNg+0omy16B9rVo3yv3Os/0JZr32/dKXlaaNwJX39+nfQ7V 184lUvd6ZTdA+zyElXYJo6p9nuTEAeUhaB/DtU+7QPvQvt7G+dLT2jXaJ5ZoH9pHleMu+Grs1RnJ 7Jh5R/vQPioed120D7QP7ePhQY7/2rqLvw4oFj6BRPvg33OsoXh6kL+OwYLrvgtNM9FoH1j3VT/u yrbvgftegvahfYzRPoMM2of2aR+gfWhf83F+7v19oU/+fVHQRKN9/Z0Wyv4Ee/prPLdaDVHG7/Ms NcvaN/Shat0HRQ6on6SCn5nYqsoHcvPzRt59HKz7tE/7YNb25d3HYbcjpzdESP+r4LcrtUwL3sMo clul9LlR+7QPHFA9bNUT9+87PfknvtH26dDTDctbecXf+BzcvMht5bVP+8AB1WqrdpeExW/qmlfe m/eujdy3PePWe+7f51C9Fj4XuuCA6nirdp/wPFq/HH1yhfalN+z+w9c+h6pFH6zTvtNmxUtRZ90X icvpuk/7yGqflRxM3r6br/c91z7rvukPmSbvf9E+WLZ9r9zrPNOXaN5v3yt5WenNE2z6g9rXZM+8 /xOO9oH2Lf4QOhxPozp5+/xSFxzLHgLaN0n7XOsC2of2PTI+Py1uFBS7X632gXCgfQsdqtoH2of2 ad/pVzSqOKBA+9LDEvldtT20L/4V5Q9HNDS/cxNV2weAJwS0D8CZls2AdPuc55+362kfgPatMiMX 2mdmAbTv3rCMt+5ziQuA9oUHpOfrPAUNQPvmGxbtA9A+M6J9ANpXbWR6e84zGj5zCqB9Qw1LpH0n LbY4BNC+1doHgPYNNTLaB6B9rYal59f7tA9A+xaZkfP2mU0A7ets/bj9eHxGPi9gSbXPhAJo3+1s 3Rml07rFf3laqH0AaN/tYdn+QfsAtE/7IovHo97ttu/gX2kfQP5Zvcnli2u2L/01rfsArPt6/iHh iZ5mt2//70wlgPZ1NrwPtg8A7dM+ALSvULbyvs72WdOr7+/zpCaA9tUflra/0+yrfa51AdC+Rdtn KQigfdZ9AGjfvZFp8i5I7QPQPjPy2lzkqX0A2jfTsGgfgPatNjLn7fPL6AC075lh6eq+7dZ9ANq3 1Ixs382gfQDap30AaF+Rkbl/3/aH2geA9j03LAXv33ezffoHoH2rtc9EAWif9gGgfcVHppPfaeZa FwDtW21GtA9A+5aake2FLsIHoH1PjEnDvuy2z6IPQPvqDEiTwUm3T/gAtE/7ANA+7QNA+yZo3+// CR+A9j00IEdaxNeiD0D7Vlt4/m2f8AFo32rtA0D7tA8A7Zu1fRIIoH3WfQBo33DjnLh29OOuSe// ucoFQPvGG+Sjtw3u3bVB+wC0b4YRvtE+4QPQvvnb935C9PNPXvYDuHMqbnVH8pV/tMhd95kgAOu+ UcdW+wC0b+UltvYBaJ81oPYBaN/04xx+f9/HhS5mCkD7Zp8R6z4A7VuyfcYDQPu0DwDt0z4AtG+G Gfnn8hYVBNC+hdrnWhcA7dM+ALRP+wDQPu0DQPsGb59rXQC0z7oPAO3TPgC0T/sA0L5h22eOALRv xfaZJgDtW6N9AGif9gGgfdoHgPZpHwDaN2z7XOgCoH1Ltc+7GwC0T/sA0D7tA0D7JpkRv9EFQPuW bp9rXQC0b4n2WfQBaJ/2AaB92geA9vXestMPah+A9k02vO8/737w3/b9ucLFhS4A2jfFUF9oHwDa N+wgH/Uu3T6zA1DwPOxFJes+ACdkemqfuzcAaN8Mw5vTPgkE0L7V2geA9o05wlnv79M+AO1brZXa B6B92geA9i3QPgkE0D7rPgC0b972AaB92geA9s3bPk94Amjfqu1TQQDts+4DQPu0DwDtm6F9pgVA +7QPAO1bo32e/QTQvoXaZ14AtE/7ANA+7QNA+7QPAO0bvH2udQHQPus+ALRP+wDQvhna55lOAO3T PgC0b4H2SSCA9ln3AaB907bPtABon/YBoH3aB4D2Tdc+L/sBaJ91HwDaN1LLfk4/qH0A2jfZ8L7/ vPtB7QPQvomHWvsAtG/ZBWCifb8XupgdgFIn4S/GpPIPGKH2AWDdN9EIB9pn2AC0b6rh1T4A7dM+ 7QPQvpmGd/el1bP39/mlLgDat1wujQOA9mkfANqnfQBon/YBoH0Dt8+1LgDaZ90HgPZpHwDap30A aJ/2AaB9o7TPtS4A2rdW+wwDgPZpHwDaN/WMmBQA7bPuA0D7Jm+fa10AtG+99gGgfdoHgPZpHwDa p30AaN+47TMvANpn3QeA9mkfANqnfQBon/YBoH1DzIhrXQC0b7l1n2EA0D7tA0D7tA8A7RtpkH/+ OGifSQHQvqEXcd8t+/zPoywaOgDtm2mQtQ9A+7Rvd6koggAFz8POrp23z5v7AKz71lv3GTMA7bPu A0D7rPsA0L6RBvns/X3GDED7FpsRkwKgfYvNiDkB0D7rPgC0z7oPAO3TPgC0T/sA0D7tA0D7tA9A +9A+AO1D+wC0D+0D0D60D0D70D4A7UP7ALQPMwLgTIsZAXCmNSMAONOaEQCcac0IAM60ZgQAZ1oz AoAzrRkBcKbFjAA402JGAJxpMSMAzrSYEQBnWswIgDMtg86ILbElhsWW2Gmxo9oSW2JYbImdljvD /nNwoz47qi1xGrEltkT75l7ZbcffjmpLnEZsiS3RPu2zb9gSpxFbYku0b/r2AfA0MeqqfQCgfQCg fQCgfQDQf/682AoAAAAAAACTafg64NG7PitvUuLN/pUH6ug7Vh6f+MOvMyZHD3/ZYelnTNL7bf3z TFf7SeT7ugyjYfgSCagfncqbdLQ3bv/89Fadbkm18Yk//Aozdfp9FxyWfsbkc9dte/icbknNMYl/ X5ffa1/bTeqhfadb0upng36O3B7O870NS/Mx+f2yPbQvvSXaR2/t231mQPt6GJ9Ofpjf/V6thqXn NU6TMem8fa3GJPh9tW/Z9sV/ll6zfQ3Hp58x6WpYul33NRmT02/Udkt6OL109cwJ2qd9VzejzzHR vobtiyym2m6J9tFt+zrZH4Z4va/JpRTNx6SfjRnoWpdqxdm9oHHlLeltV0H7tE/7tK/+aWTNLdG+ gfLX8A0mPbznpdv39zXZkq7endTnxjTfVbp6A+ar1/f3vXp6U+rL+/sAAAAAAAAAAAAAAAAAAAAA +L+jX5N49Mlffyj+3bc3qbnzxU8/Ev9bAGZqX7V/Vbk72gfA1RN+4tackV/e+/mf8RXl6ZdKb2Hi y57+28iN6vxWRoCJ2xdM3tGnXf0l9on2vfOX6OClRxF/dC+/jR9g0vadvtiX0b7Iyiu+7ot/6/i6 T/sArPvSWbyTiciFNHnti3/lxH2jLi1mPe0JMHH7bj7neXWJdHPdd/qVL90v+PRBAaB9r9hrfPWf 8zz62/ij85wnwDrte/17WWP6OpObV2Pmte8VvvBy9xMSj273Qb1c5wkAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAACT+h92k3/dCmVuZHN0cmVhbQplbmRvYmoKMjM1IDAgb2JqCjU0CmVuZG9iagoyMzYg MCBvYmoKNTA4NQplbmRvYmoKMjM3IDAgb2JqClsvSUNDQmFzZWQgMjM4IDAgUl0KZW5kb2JqCjIz OCAwIG9iago8PAovTGVuZ3RoIDIzOSAwIFIKL04gMwovQWx0ZXJuYXRlIC9EZXZpY2VSR0IKL0Zp bHRlciAvRmxhdGVEZWNvZGUKPj4Kc3RyZWFtCnjafZJPSBRRHMe/syVCrAVlJlLwTrYHVwbtYB2M 3fVvyrasa6YIss6+2R2dnZ3ezG4lHkKILkHWMbpY0Uk6hgcPHQIPEYJiXSLoKBkEgpeQ7Tczu+6I 2oM37zO//7/fe0BdKG2aeoABecMWyf4ouzs+weo3UIcGBEErrVhmJJEYdplscWTtfYXknJvh4/X/ XQ2CEgISVYDGrMfXHJ72eMDh+7ZpE086rOTSGWKTuE2kkjHiV8Rnsz6e9nGGWwrxMvFNxRQUJ5Ai HigpWSfmDrFsZDSD5JeJuzKWkicm38BTZxZemfYQ0H0FOPW5JpuwgOV3wKXWmizUDFwcA1Y6a7Ld pDsfqWndUjs7XJEUjAJ1P8rl3Vag/gWw/7xc/vu6XN5/Qzm+Ax91pShKlRlJ0hfA68Ndjf3c4EJT mHNfCVFQNZ37Rnq82uvXi0f1Jat0EnszcVcXsET3MHYGGHoMvPwJXH0PXPgAJBqA1HUEHqG6bf7A zRMrmA+Fls3ZrEOWO1jYOTpZhF4IZ7FC3izaXLBBQ2lvY2ldZ66pxQS3uCjxTDvyerHa7znaQW6M jtBJ8wqo3OqtsDSTSffQ3aCdeCPDe3qdd0G8qGp9g86F0P6kir5Rj6Xzmj2Y8jjQbejx4QrDKMRv ezGxY9rRZDW+VRrprcpn0rcSdLaQ/MZsYcixaSLf0FwuNeaxlJrLxeIVXsU4dHBoMOhrgCGJfkQR hgmBAlTSaGShkZS7NoLYwuyxljoSPmak3yafbdfnHork7XjdQTSOhbaDCEz+Jv+Wt+Ql+a38a7Gl GKppFsSUpqw/+0NxnczVuBVtpSYvvkJ5I6TVkSVp/qAny1eprzrVWGypRXJy8CfxPV+X3JcpjGk3 0qybqeTqLPpGfNlOmh7Zrs2vNtdybZ1emdwMrs0fmlXhSFf8oKvD/zU7vz//B82wAWgKZW5kc3Ry ZWFtCmVuZG9iagoyMzkgMCBvYmoKNzA2CmVuZG9iagoyMjUgMCBvYmogPDwKL0QgWzIyMyAwIFIg L1hZWiA1NCA3NDIuNDUxIG51bGxdCj4+IGVuZG9iagoxOTggMCBvYmogPDwKL0QgWzIyMyAwIFIg L1hZWiAxNDEuNzM1IDUwNy4wMjEgbnVsbF0KPj4gZW5kb2JqCjE5OSAwIG9iaiA8PAovRCBbMjIz IDAgUiAvWFlaIDE0MS43MzUgMjcyLjc3OCBudWxsXQo+PiBlbmRvYmoKNDYgMCBvYmogPDwKL0Qg WzIyMyAwIFIgL1hZWiA1NCAyMzYuNTc2IG51bGxdCj4+IGVuZG9iago1MCAwIG9iaiA8PAovRCBb MjIzIDAgUiAvWFlaIDU0IDIxNC44MTQgbnVsbF0KPj4gZW5kb2JqCjU0IDAgb2JqIDw8Ci9EIFsy MjMgMCBSIC9YWVogNTQgMTM3LjkwOCBudWxsXQo+PiBlbmRvYmoKMjIyIDAgb2JqIDw8Ci9Gb250 IDw8IC9GMTUgNjMgMCBSIC9GMzcgODIgMCBSID4+Ci9YT2JqZWN0IDw8IC9JbTEwIDE3OCAwIFIg L0ltMTEgMjAwIDAgUiA+PgovUHJvY1NldCBbIC9QREYgL1RleHQgXQo+PiBlbmRvYmoKMjQyIDAg b2JqIDw8Ci9MZW5ndGggMTQ4NSAgICAgIAovRmlsdGVyIC9GbGF0ZURlY29kZQo+PgpzdHJlYW0K eNqlV1lTIzcQfvevmNqXyLXMMIfm4g0wuwsshICTfWB5GGxhq3YOM0eI/3261ZLtsYdkUylXWVKr JbW+T32May0s1/o8OpuOjj95oeW5TuqmnjV9sUJuxTxyQi+ypnPrkV2WYz9hrahL0dqTOntpx3bq BymbY99ua7nK2qW06yrP7XqV240scEWXZ62sStv1xnYSRymbiJmAmZg9j234F/XYDgLOfNdNx0/T q5GrbTLtxXTkQce1PMuLE4dzzwp97gRxaM2K0evIdYIoCkOlsttXk2alFhxfFp5vTarRb/AzBxgd 22xv7+w/gIznpY4fWqHrOkkUEDqf5KKrBd4kYJ5/MrY5D9lpUXWEGk1UL9TOqhLv3wJUJGjr7Lvr RTMavVQakrkEaSBqsbvJ57x6zvS6e7HKpFaeyoKgDNgdqotaVgBwwubOIKyWHYV4DVjhuK4m+fHS njhStC9E43Mn87ksFzDqWtWK1+YJDvE5u8nqlg6YzeQRyiJ25ahOzO5l1WnZraM7NzLXs3fjhDOj mpVz2vCbg23I/hgnAVhfiHUuSr32uxfwM20MaZ92bVVkNl4NrmN7gRPylC6Bzw0MA8vuyWw9EK+d rEWh0WxQmjKpVb9WKH2jgQKwQo7eCEoSK1NJuWnW1L0V7Uavqn80YLDPjVO8h+TYYwrMse2xVxg0 2LHdmLb87oau2W/ofmgy0ryqq0Utmgb0vQ9H9AoexKoVyu+eFTfmSaB3OWYzP3bcNBlkfFkVYp9t DvueoYU1mAoYtHAWj1x26ujOWVdXpe5fGaECC5d+drANNaj1rNMKyOkXOI60iE+iDrU31OHkvegR HZLp+3TiMlnSig2d25NJoDFB8cZCTSfKFJ1Jj060dZ/OJSBRFYiJQQsEA4wmdECP0Z6dexwOsP1/ GZXlvGsOHDiO2J1sIJrju0lidq3cMYnYdKmCtjmr1fNbl4XBRN0lqxs9fjATd0tZlmKNuloyNVPI 9iWaAolChS+wYMOxGohBZz4kmQ+RzPskx5pkDiQDG/s88yG35eGh2wJ4sBzwM89/B0bbjXrsxobd 4CfY1U/4qivFf6PTEFkIAHKGXPppQjEzaxrRKULdkF3doeiIpq9locU3ju5s2YfBtZGeL6tyoftf jBCp20ZS2O6GzsZByjrz2sWcZlX6wo5iBGqCIVrPs3ymKwM4JHQpqIXellMcDDguiillwCJNKMoG HDcIwwNC9+CzXU479T0UN5TasIMoC7tOht/q7Of8NB0mdpUrxwzYN2lKLeU7vnGiYNg5g13nhMzZ 0i5Z7ujlir+7ryck33E6WFlXJomrWiT2dfUBc1sm4mAoI6pDFBOwCpjAN6DYgCGwMYhQjx6scFRK 6TMEpaNi5SBuBtqz3st9t8rgP5V97xSYP+NhgHshyyqvFmtMfjxGX4I22vMyHpNrTHW9otfQEhUB oN2GKBislD19FFF+qhIRHGACFMiGAlR8+J4HYsqO/bbrE1w7IQoA/0GAvI9lANUdaq//LTbdPtj+ kz4CoVgKTUXfG0njQSpW0O2r2vb1SepJt+3q5Pj47e3NkY10xLw7LpsyK+D/+MPwyb/e3F5MVyuM fzFHZiDU14sMA14SbY3BSVAV048fcRCwiWxmtWj11AW9FirHSWHHSqojUbaGYFkcfaBFqmSEFpxH ETpT0U/MqQhoaBJrfWxbY8UFFEn0AATkpKFE3/te0jR0eSvhc+EFPwJmYusVFw83vwAtHnIGpxoX 6OUTbzjs3H/CY87DkCdPFMIn1TLXuSAyGSJi3xSmbSvWpdCi6WauF6J2Z6hGhug/cWjzM/hOWIpc T+/lknSoKgepziEp+71+zkrqalcajCsDyR9BoPAUBJtEcfg0G/PiEZaYndMAwflHT9h+RoElPHES n5MlKhrob2G9g9BfbhCR4aV4Seyxi79WcOmG5IY0CFH8yJzjuaDLA5ezR8qjC63jBU89A+Dz+G+p WhugCmVuZHN0cmVhbQplbmRvYmoKMjQxIDAgb2JqIDw8Ci9UeXBlIC9QYWdlCi9Db250ZW50cyAy NDIgMCBSCi9SZXNvdXJjZXMgMjQwIDAgUgovTWVkaWFCb3ggWzAgMCA2MTIgNzkyXQovUGFyZW50 IDI0NCAwIFIKPj4gZW5kb2JqCjIwMiAwIG9iaiA8PAovVHlwZSAvWE9iamVjdAovU3VidHlwZSAv Rm9ybQovRm9ybVR5cGUgMQovUFRFWC5GaWxlTmFtZSAoLi9Db250cm9sX1BfMjAucGRmKQovUFRF WC5QYWdlTnVtYmVyIDEKL1BURVguSW5mb0RpY3QgMjQ1IDAgUgovQkJveCBbMCAwIDY5NiA1Mjdd Ci9SZXNvdXJjZXMgPDwKL1Byb2NTZXQgWyAvUERGIC9JbWFnZUIgL0ltYWdlQyAvSW1hZ2VJIF0K L1hPYmplY3QgPDwKL0ltMSAyNDYgMCBSCj4+Pj4KL0xlbmd0aCAyNDcgMCBSCi9GaWx0ZXIgL0Zs YXRlRGVjb2RlCj4+CnN0cmVhbQp42itUCFQoVNAPSC1KTi0oKU3MUSjKBAqYWZopGAChqZE5mE7O VdD3zDVUcMkHqg8EAJZCDgIKZW5kc3RyZWFtCmVuZG9iagoyNDUgMCBvYmoKPDwKL0NyZWF0aW9u RGF0ZSAoRDoyMDA5MTIyMTE3MTQyMy0wNScwMCcpCi9Nb2REYXRlIChEOjIwMDkxMjIxMTcxNDIz LTA1JzAwJykKL1Byb2R1Y2VyIChNYWMgT1MgWCAxMC40LjExIFF1YXJ0eiBQREZDb250ZXh0KQo+ PgplbmRvYmoKMjQ2IDAgb2JqCjw8Ci9MZW5ndGggMjQ4IDAgUgovVHlwZSAvWE9iamVjdAovU3Vi dHlwZSAvSW1hZ2UKL1dpZHRoIDY5NgovSGVpZ2h0IDUyNwovQ29sb3JTcGFjZSAyNDkgMCBSCi9J bnRlcnBvbGF0ZSB0cnVlCi9CaXRzUGVyQ29tcG9uZW50IDgKL0ZpbHRlciAvRmxhdGVEZWNvZGUK Pj4Kc3RyZWFtCnja7d3hsqSq0mjRfv+X9p6IHbejvyqlEAEzYcw4P/qsvWoVZgI5RcXjAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAICn /PmH+V898xi7H3v9pwq/2Tf+HUNa86de7Dyv9LHTg62PQLkbvDU6AKB+4lpyaro6qOfH/twTusd/ piek6DyDAvL336c/5AkA1i6gV2dJ//27MEPWnGr9+0c+fl7/2ZrT8/K5XvOxn/7l78icfrymDT8L UE1IK895Cz98XvUKEfg4xnKyymfr5b9Q2RmejJ1ymgofuYrPv/+VKgAI6wlXM9jHFPf9n35OoeXf bPjsrTO+58d+1dqfLe/iCTVtqw9m4Yf1C+llB2tLaP3Zev1fuHXi37Cw8LAbn5qzOQpAOk9onoTv ltHmqjHOExpq0DRP6BW3tjpVv3TQJaE1eWzrojW3WxSuttztz2Ux4wkAdvCE74m3cp2WJxzXV2fq Q1qugPV/6lZ36usJ5dp9dZHiaoXk4Xr+LQH4mReeAGBzT2goDSNOPxfzhPqT7ofXaJrvYxy0nlCf rJ85KqyK1DvJ8/58uO4AIJsq3C2LIy6Lz/GEvmWurVIfFY8M3F3lflijb92f0Nx5RlwxOcbfn9DQ 5U7vCG24RQcA3lWFyvvMf85p5T9SPmO61YBy5a151qD52I+LGzu7t6FgDnfXtI+KRwnKB/Uz2m1P UjQ/lFFwle/+1ut5h5+Xb37KQGGw3H2uBwBSr0tAfiGYAGDqk1yIJwCY+gCDBQAAAAAAAAAAAAAA AAAAAEhN814xh1epAgCwtCHUb8v2/W8bmwMAsIMt/PzhXU/4A3xhrAEAT7C8gKtuBgDONXgCT8DP bpaxe2izNmuzNpvAeQJ4gnlVm7VZm8ETwBPMq9qszdoMngCeYF7VZm3WZkzwhOPm/gkSCp6gzdqs zTwBEgpdAoA5BBIKXQKAOQQSCl0CgDkEeyZ00JYd5T91tVvIWyGqvPOke5aNcQA8AeWE/u9n8/9X aNXkXvd6J69/c4cxDoAngCd8lMiPGvr3rP/nIx4fD4pedearb//4VOXXNQ+Zu55QaN73IRRaZYwD 4AkIntBypf7+4fcvlPeRuFUovz/1fUniZ8PmeMLP5p3GyhgHwBOQzhNO709oe2t22SIaLOWullQe XZf1hIZ2GuMAeALyriecXnS4Oi+++uUJnlBu2Jz1BJ4AQFnBbp7ws77XLzLMWU+oKcTWEwAoK5DQ oZ7w8P6EcZ5gPQGAsgIJfcUTjtbnHcqPKjz3hKP4eEWv1JSXIHgCAGUFEqpPiicAcwgkVJ8UTwDm EEioQxBPAOYQSCh0CQDmEEgodAkgbec/dH9zCCQUugTAE8whkFDoEsBdSdD9zSGQUOgSAE8wh0BC oUsAPMEcAgmFLgH0kgTd3xwCCYUuAfAEcwgkFLoEcMsTDo88mEOQJKGVb17ue7B/zngrRKfH3hyQ Wx8xxsETwBNQn9A/RTr+ZqFVk3vd653851uqh7bQGMe2ksATzCFYwBPa3it9WnMrX6x89anKr+t1 +v/TEwrN+z6EQquMcfAE8AQET2i5Un//8PsXyqfktwrl96e+L0n8bFjD4V9JTsETfjbvNFbGOHgC T+AJSOcJp0sNbQvyZYtosJS7WlJ5dN8Vv9dh3rp4YYxjW0ngCTwBGdcTTi86XJ0XX/3yBE8oN+z5 4fMEgCcoK5DQykrdVlXnrCfUFOKf6wk8AeAJygok9IknPLw/YZwnWE8AkkoCT+AJyO4JR+vzDuVH FZ57wlF8vKItAnf3T+AJAE9QVgS/uZpclZgFEqpPiifAE8whwl7eZKB+AfzdLYz0SfHEtJKHhogJ ozlkpeDzBH1SPKHA8QRzCHgCjHHwhGkRE8m7M0Z5f13wBPAExKl6sscTzCGCzxOQa4ybdWdKglA/ 75bCyBN4goSCJ/AEEeMJPIEn8ATwBJ4AnsATdg6+/RMQfIwrXpOrXrpov9LacpT0WJ4ACQVP4Alx mj2/wTxBWYGEgifwBJ7AE3rFRFlRFAK2asSjuD9f63D6FPArIWp4v0OvLA/yBDMHTwjSPX5+HU/g CfiZ0P/1l1f+71WrJve61zt52/sig68nmDmmzfCJov1v95jWZp7AE7C2J7S9L/K05la+MPHqU5Vf 93DI3H2vdM2TL+VFia4LOFlvruMJryyDzGk2T+AJWCChP9/s/PHDyhcon37k1rd/1Nn6hrUF4coN rjzhZ/NOY8UTeEKEls9pds237OwJXQ6cJ/CEOa06vT+hbUG+bBENlnJXSyqPrst6QkM7eQJPCHIC O6HllV+xYY/lCci7nnB60eHqvPjqlyd4Qrlhz0PBExCq4A4q2aNbzhPKksATkNETftb3hn0ph64n 1BTi8npC92WTVzxh/pIyT1jGE8Y1nifwBOzjCQ/vTxjnCc/XE3gCtvWEoY2v/8s8gScgqSccrc87 lB9VeO4JR/HxirYI3N0/gSeQhDU8YVz7eQJPwJ4J1SdjxpMnrHpWPqdqj2g/T/h5vF0O3JysKDgE XaJhpqUKPOFuC/sewq2/xhPMyeAJGBrPpFfMeQJP4Ak8ARIKnsATUnjC0XmTQJ7AEyCh4Ak8IU3M Jz+iyBN4AiQUPIEn8ASewBPQvSgA3V/kzRMilNrIMZ//6AFPqDlYngA5fT45qHdtYRQ3nvCiJ9z9 I9t6QpdjV1N4wuaeoOTxBJ6wvCds1WN5AuQ05sTFEzCh04YN++SrADyBJ0BO001cPAE8gSfwBPAE niCMgsYTeAJPAE/YShKUPJ7AE3gCT1BTeIL51jTCExbotDHDzhN4AnhCumFiGuEJPIEn8ITnx66m 8ASLCS/OJKk37ecJPIEn8ATwBJ6wsyfkfZyfJ0Tuxjxhci54AuT0e0TwBJ6wsN9Gi/xkT2j7OE9Q UyCnL05BPAGpPWHyqOEJPAE8gSfUf1fezXh5Ak9o/viTb+QJPAE84d0qP20+4QnrdZ45384TeMLd w3wWcJ7AE0z1PKElDjzhxW/v2NrnnTCFJ2yiCjwB03KacUD1qrk8oT4OK028PIEn8ASekKLE/0fb D3lClzbzhA094fVERPCEmYWbJ/AEPMzF33/X/7BjToNfNOcJPGG9XPAEnsATwBOyeMK0+SSyJ6Te G3AHT+guxjyBJ/CErTzhg7ZulmtM9W3thGP/9yvy7rDHE17sbzyBJ9Qf4J2nbv88LCIYrQofeZm/ nsATeAJP2McTno/3yY0nGM3tfHD4PCH02sJkTwhevHgCTxh6sDwhfvHlCTwBPCHCKOYJPCFFB+74 QiWewBN4QiI3eMsTPnoRT9jWE/K+kChpLngCT+AJqE/Hi/sn8ASewBO29YQjyZ0Gb234nKKr8wQM zel3F1pDocOqwhqesIAqRNDjtzyhy7HzBJ6AbT0hSwnI6AnBrYwnZOnAPIEn3DrA1gjwBJ4wZGsO nsATeML8Ws8Tun+cJ/AEnpDaE8a1cFtPeHEDYZ7AE3gCT0BAT+iyhRdP4Ak8gSfMKdmTo53FE8a9 kIUn8ASewBO29YQIt+XwhBSeEL+r8wQMyumg+2OzSwJP4AmJunGv+j6/cM/vbDyBJ4AnJF2sCBLq F99ayBNe94T5hTu+JyTaopYnYEROB930whPi1yaeECQXfd/RwBN4wpgxzhN4QsoqMHnLxAl/NkKo eQJP4Ak8gSfwhNGdiids5Ql5VSFCIngCT+AJ4Ak8gSekm1enHVGvL+q1EMQTyr8fuavzBPTN6QIv +uEJcY6XJ6TzhF6dkCfwBPCEmONiTqt4Ak/gCTyBJ/CEDT1hgd37eQJPGHqwPCGgJ8yPVaK36A6N JE/gCTxh5hdF3v2SJ6QW0S7jOvIJPk/gCYjpCQGHRrrb0QOexvIEntDFV3kCTwBP4Ak8gScs5gm9 jn3yQ50RPOFYYomVJ4An8ITJR7qeJxwJH6jhCTyBJ4AnHAn33ucJGSWBJ/AEnsATeAJP4Ak8YSVP ODo9GccTeAJP2NwTsm/gzxNiHunrd1bwBJ4wJ0prPAJ20yt4Ak9I4wmvtKTjl0Z+QWdeT/jvq7tP khnfRsoTeAJPwCuecGR+63EuT8h7jDwhiyd0lNU9PSGmKvAE8ASewBPKkjCi3Aw9qMm7fY7ohDM9 YfIwzOUJo1eJeQJPyOIJ71YinhA8OzwhqSfMHxc8gSeAJ/CEbT2hb3XjCTyBJ/AEnsATeMIanjCi uvGEVcfFw2/kCeAJAcdF3gcB3jpH28ETTt/52/GJkvU8oWMn5AmpPeGmMPMEnsATZnx7WE+YfNf6 0JZn8YS3DIQn9OonC+wqwxN4QvfuvUClzlJJM+4lFcoTeu1kxRN4Ak/gCbt5QsOT5hHGxRqrGWt7 Qpxm993x8q27CHgCT+AJeNET0hVrnsAT7npCryvLg7ZWDu4JkwslT+AJ4Ak8gSdEqIbvblresCXU 5MWWsJ4w/0UYPIEnRC7x/9H2wyU9YZlHMmN6wvzH0ue0vNeb/jqmfo4h9Dr8yYVy8vvRVvKECbM6 T4i5DvD33/U/5AmR2xDncbw1PKFtGn/FE+ZLAk/gCTyBJ/CEdM3gCfOb3fDU5IghM9kQeMK0r1tg auIJSVXh42pCmyd8wBNyecLMo+YJI47rwxCCbJzFE3hCXT/5UygisJ4QbVyssbjHE95qdsOuzr1y 95Yh9NKkjIWbJ0yoTeAJPIEnxE9W2x2hr3hCqB7LE3gCT+AJPIEnvBjemG7T8OLpLI53qxl9jyK7 JxyzdqPiCeAJm0gCT8jb7MmeENZs+97DyRN4Al5UhXH7JzxfC+UJ0z7LE7oHc076wnZanjDi6JbZ 3YUn7Lwu0bc77ewJx9xXaPGEjJ4Qucfm9YT5r9jgCTyBJ6Qo3NGm3GP6qzZj1tykbZ6zksYTRmR2 sifkWj6adULBE3hCxPLNE0ZHYPJabuqOMf9FRX2b3b0H8gSeAJ7AE3hCwKxF3uyLJ/AEngCecKS9 bs4TeMLQ743ZY49nmznwBJ7AE3gCT+AJPIEn8IQnXxdt102eAJ6QzhMm28XCnvBir6h5am89Tzj6 vXaTJ/AE8IQdPOGY+4QjT8gyIYftrjyBJ/AELOkJ8WfdBTxh/jPpq3pC5MWE53HbzRPCbnXCE5DI E451r0FH84ShofCXg1cxnsATeMKqpTnCq7ovNnPmCTwh8V8Oe2M5Txja1MkrVDyBJ0yQhAhRTe0J 6y3h8oSFPSG+JOQ66oyecMTe1oMn8IS7nhC/c/IEnsATeAJP4AlLqkIQSeAJoQZmzBd0ukMyfgnj CTyBJ4AnpJMEnvDWHw/SMT6asYMnTK7dPIEn7FOXXXdY1ROOudu68oSwnhD/cUiewBN4QhBDuGJh TzjWXVuO5gmH3ZBie8Ies9wunhBhq5Nb/skTUq8nBGxPfE/IMvHyhMl/PE7H+Hj94p6ekOIEf/6h 9Rrpt/bP5AngCTyBJ0T2hG3mE54wtpd+6wFPWLU0/73csPzzDjwhtSek23k7midstZjwridM3tJt vidc9ajKPsYTMp6/h90/ofvMxhOmHRFPCNUxdpOEd2v3wp7w0zlrehpP4AlbeUKiuZcnzPyKaB2D J/CELtPCcw2Y2Q95Ak/gCYNayxNW9YTN5rdlPaHj19VfJrh7m2KEt5nzhF5hDPJQZMETIs+Wi3lC 36vY6Zbxs7xxjCcEP8ef2VcH3Ur0/RRD2+UJnoB0nrD2OePDBne/1S1dqGMupIAnzPGEUzfovlLB E9ar1DyhXE+X8YQRh8MTwBOyeEL3ae3qT/GE1Faww3WH4/HeZamfL/u5wDji6xIV35i7RoAnzPGE QY188TVkPKFvGCPEM6YnLKAHhWOfcFxd/n4KTyAJYTt8ohsLAx7aiDmHJ6RThSDBjOMJgxbioo3Z mYc26FpnHE8gCTyBJ9QMfJ6Qyw3ivwdqvicsqQdBDvDJN072GZLAEx4OrsUOrePA5wnI6wmb7G37 7mE+ecZqcmXhCTwhvidk3AyWJ6BjTkffXbObIYyO6og2zM9Lw3eRhCxi7Lt2Oz3hCd3DGO15hwme sOH7cYIcafklMi/eHxJ5rQNqd1JPeKvBPGFEDEPdnzDhaZ0NN70Pe4rxrh60zWY6j/LEExrazBM2 9ISrOyFP740s3DB56gmG2Ia2ENBeSAJP4Ak8gSd0ierphgzlH873hP/+OELNHokWOngCT4hQuxfb EpYnRFaFjg9FXmlAQE8AegkDeAJPyHIujFBJafOED22RZIR1BvAEnhD5tDfOFoLs63o1wHoCVi49 yOUJizmJfmg94S0B65gRngBgN69b9bt4ghh2eRsUTwDAE3gCT+AJlengCQB4Ak/gCTyh8MEn+ye4 RQeA2g2eEEoVQu3bzBMA8ATwBPAEAABPQJsnAADAE94NY5wtKXgCAIAnRI5hnPdF8gQAAE/gCTwB AMATUoTRdQcAAE/AvzEswBMAADwBMXPKEwAAPAGnObV5AgCAJ4AnAAB4AngCAIAngCcAAHgC5ngC AAA84a3oxXkckicAAHgCeAIAgCeAJwAAeMIyYQz4vkieAADgCQFj6P4EAABPAE8AAPAEZPQEmycA AHhCnDBGuz+BJwAAeAJ4AgCAJ4ghTwAAqHHC2NcTAADgCa/HMOC+zTwBAMATwBMAADwhVwytJwAA eAIivy+SJwAAeIIY8gQAAE8ATwAA8IS8YQx13cHmCQAAniCGPAEAwBPEkCcAANQ4YTy9bFH/Q54A AOAJAWPY5f6Efz/199/1P+QJAACesFsunngCAAA8YbFcfCxHPFtPeP/hCwBArkoU6gm+VQP75I/U KIH1BACA9YS8MQxyfwIAADyBJ/AEAABP4Ak8AQDAE5KGscstH333TwAAgCeAJwAAeAJ4AgCAJ2QP 4+sh5QkAAJ4QOYZB3isNAABP4AmnngAAAE/gCTwBAMAT4ocxzlbYPAEAwBPAEwAAPAE8AQDAE8AT AAA8ATwBAMATRI8nAABUOtGLFkOeAADgCZGK8gk8AQDAE3BYTwAAqHGQUwCAmoL2U/hA+zHKCABA TQkbw9fvT5AUAICawhPkFACgpvAEOQUAqCmpw+j+BAAAT4CcAgDUFMgpAABqipwCAKCmyCkAAGoK 5BQAoKaIoZwCANQUYZRTAICakjqG0d4rLSkAADUFcgoAUFMgpwAANSV1GP9ebrBvMwCAJ+A7ht// kFMAAE8QQ54AAOAJGOoJV09MnD5DUXiwQk4BADwhWhifPxT5s+ifesj3p+QUAMATNskFTwAA8AQc /3dR4qEnxNn0CQCQtBIpIuMC29HfrCcAAKwnLBbD51HlCQAAnsATrj7FEwAAPGHJMHZ53oEnAAB4 wgLRu+LhH2z7oZwCAHgC5BQAoKZATgEAasoaYYzztKmcAgDUFDGUUwCAmiKMcgoAUFOyh9F1BwAA T0D8GMopAEBNEUY5BQCoKSli6LoDAIAnQE4BAGoK5BQAADWlVwxddwAA8ASkCKmcAgDUFFGVUwCA miKqcgoAUFNSxzDOzQlyCgBQUyCnAAA1BXIKAFBT8kbvCjkFAPAEBAypnAIA1JSYwYwQTzkFAKgp IimnAAA1JUUMvVcaAMATkCKAcgoAUFOCRM/zDgAAngA5BQCoKZBTAADUFDkFAEBNkVMA2HQy/N90 eJgP1RTIKQBATYGcAgDUFMgpADybBl1xUFMgpwAANQVyCgDN86GFBTVlg6Sc7vFY2PhRTgEAPGHh jPyblNN/X/2CnAIAeMLy6eAJANA4i7rQwBN4QoUnxHkpVbQJRBAAoFyGFJH4zmY9YcKJBmcArDDA ekLSRPAE8wYA8AR8JOJ0nYcnAAB4Am6tLfAEAPic+qwT8oRdk2L/hC4TiCAAAE+AnN460eAPwM4z ANQUOYWpAwDUFMgpAEBNgZwCwOekZ21QTYGcPptDBAEAfVJTIKfNg+VFl3AqBBhokQ9WTeEJeGsC YQhYbygJgpoCOQUwueBmqb/UV03BPjk13oE4BddgNE3xBMjphJMyQMfWTjalpkBOmwfIW9Oa0yLw BAMt7GGqKTxBzZp/7MQAvAXOPSGnACYU3NfLNO9VU7BtTg1/IHi13XOQmpp4AuT0lfMyAEblwmbV uGClpvAEpxsxJjSnSM5PeULARP/7keCdZFA3VlN4Qvypcv6z5ENDoSRB6SeTzj0hp6amZSKcdG/A LB2s5z7801NDetUUyKmpgCds5Qnze3u3l/ptM07NSDwBcmq1AVDoEST4PIEnGAUav3NXEXBTxN3f THEfl5qCjjmNPFXWtG1o4zu/xl1VwkLVlmaoKZBT85XZb9uT8dH+mX1ckF41BXL6fFowjcA54yuK tWoRJyc8AYvldPKgNoEAij66B58n8ATTjqPQT3aOxoay/bMPVK75BAnX8OUpnrCxJ8ycMJ/slbpA fVGbYnYz3PUEEd5wUPMEOTWgTHcP34XxVn6/v3fI5vbJu27fEBnLagrk9HlFMI2ARAUprw9VKs5Y 5ic8ASvl1IhGzFNpBAyg6SL+XM0TeAICTqEmz+45ElLUDLGG62jv9qsJHVtN2dAT3p0way5bxJ/P 7z1VpEJhm3NPYXHuiTU8wZgKvp6QMR1rbx+kRPIENQU84eF0sfkcYgpVIhVWfsITMCEd/9H2w3dz uvlwNpUBZo8l5xOeEDMXf/9d/8Np6wmYE1Uzp26AyXLyfC+RXh98+OZrnrCVMyzsCadDY7FpVq1f vvLuue8x+g724BMFTwiYkSsNqPeEDwJOYssX0NCjfsrdhh/PJLaFLub23TwB3SeBQJPzGbK5z3pC rpvbecIy0nWrtkauvHN2isYaJxR951vrCZjjCUbxqusJuYqXUovN55NkWznxhHhukGI9AS/OJzVv xRU6oH58zdjVMO0LuXgCT4hwamldIvh6BYBtxyxPiJaOcfsnxOylDGHmBCXaAOXgCcjlCZhgU1KP 3fo8T+AJkFMzA8AQoKagY04NPQCgJTwBPAEAwBNQn1OGAADgCeAJAACeADkFAKgp6JVT6wkAAJ4A ngAA4Am4lVOSAADgCeAJAACeADkFAKgp6JVT6wkAAJ4AngAA4AmozylDAADwBPAEAABPgJwCANQU 9Mqp9QQAAE8ATwAA8ATcyilJAADwBPCEj2PXpQGAJ0BOeQIAqClozum21x2oAgDwBPCEghhQBQDg CZBTngDg1uQANQW75fRqHjA/ADAPqCnYPKflScAUAeymBFYX1RTIKU8AdPJTPeAJg7qHiZQnLDwE zKLY8Ay6+9/PYgjmgUHdwyzKE9b2ZKqAtatA305ePj2PM5puFcENJ4F/D/l7gUVNAU9wINhHErp0 pD9FAvbYW83Y3BOerzOYo3iC2hpntgeau01zX6pcvQ81AO+2YauB9vNgGzJu3PEEkvDuhG8Y6lpd 3LK5/cvXXJ7w5DdNUDwBr0uClHG2XAM8XafdZ5SNOFITVPyThfofymmWieL7JjRZi9A3NklEr3vg dVqegBdPE05vVS3/UE4TzWxhbyPXMRa7sHUlqL0eq58cK8PklYwIe/ABzhNGnMVHCxFP4Gwj+sbp ofU9wJnhsvIWRzgRc2Hhliesd+277xmQGwOQQtse9tKa5xwThctVofnnU+bJFOZmPaH72DEKkKjP P+ycc7r6hEHUMRpUwXrCSpLAE4aOmvmeYLip7Kn/1AKTAFUwcS0mCTzhlSEzWkuMx7U9IWBlX0MS tvKEI9Lu9OYlnkASJpx/VUqC8Zi3U13tkbjh6X/wuyXXUwWesNvcdbVz+7b7J7wyqAd5wvIFYtvT tF57Ka90jaDXjUC5ntF4coxtrZ1zc4h5Y4d1CZLw4tSUaOf85V1lxHsBfu6l/FA2VvKEu0c3bnFv xJ9qbu2T92LzBLyS0zjz1YvN6Pjq9ixvwV7+MZDmOvUwv1aTCm+ffGVE9H2Q5GEen/SfOX2GJ/CE crHYUxJ6Td0jJo05AV/SFuaf6/V1iYX9IZcnlEfHiFOD8nfxBLyynhDhBCfj62snnMBGOA3cRxJ6 nc31ujaxz1JDZGnsssrU1oVe6TY8gSf8nL527iTz778KGPPs3aDXutDDQmM0hbKF5vTdEoChi0g8 ARNyWtPtzWzzy33MmGfsBh0vonV5DYTRFHNtYVDDhk6tNojD6Jzemj+7zLELTF/TjjrFaUKWs+No +/NQhXRda5Dz8wRE9oQGN+7yMhqpiTYJjHjHkGcqqcJ6IXr9olXew0fGnA56wrf8m4meDdxnKA16 zdACj7JO6JlUYStLCf7ucp7AE3oNgVvPfz3x54xTaLpT6aF7U7+1z7aVKzyf1rK/fZsnoIsnTJiu H5pGrvCmq1Cv3Fg+bu5lCOhSvnUkniCnQzPe65bIFJ5wOrEM2g1mgaWPQdcmGALYJk9AipzeHV/Z d5uZeUX+7pPaP5sUZO+sXi8GMrFj/gympkBOb31L86MTL+5B2r3YzVm7uGUIhauu0R43M7FDHRQf RMjp0EvDzZ/NKAkzT8xr9mnpuDtcounIxAXwBAT3hKP3pgqeFWpThcW6rlUCgCdgfk7D7gP8cUOg 3InS9yKJvgHwBOzpCblaGKR0bhKlrbZ5BHgC3s2pOXa9U+zdDlwfAHgCBuXUNGucOnYAxiB4AgCA J+BWTkkCAIAngCcAAHgCbuWUJAAAeAJ4AgCAJ6DBE4QCAMATIKcAADUFcgoAUFMgpwAANQVyCgBQ UyCnAAA1BXKqzdqszdqszdoMOdVmbdZmbdZmbQZP0GZt1mZt1mZtVliDZ+TP/+fnD/VDbdZmbdZm bdbmhQ3h1Ae+/336Q/1Qm7VZm7VZm7V5t/UEnqDN2qzN2qzN2oy+ngAAQC+U5sU8AQAA8ASeAAAA T+AJAACAJwAAgFuecNzfPwEAAAAAAAAAAAAAAGAo6e5byLWbR+XdI5HbHD/gGW/I+W6eOItzzTDM Mt3ZdmklSShUtCyVN5GABQ/4zzZn6cPx41xuszhvG+d/R2KuibrQZvAEnnDrpCDFeE8a8IwPAueq X+I8ram5PKHcZvCEt855s5wXLOAJGdc8U3Tsq3Va57lD2xz/WskanuCiA0+wtrCJJ6QIuDhbT2iI duRrJYk84edaDVXgCTxB/YrW4CznXzyBJ9T028hxrmkbT+AJ2ry2JyS6V02bJ487be7e4NPHBLQZ ai5P0GaeoOZq8921BW3GZBvU5jkVId2D28HbfPWYtjbPGXfaPE3XtRkAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAA0ED5dVF3P3vrN21JBwBAfE8ovLqCJwAAsLknHMVX1Vy9CKDmNwt/kycAAJDa E8o/vPW23PLHAQBAZE8o/6Pth+VvsZ4AAEAiT/heW7jlCaevhOYJAADwhJ8VnycAAJDdE46Kuw7c nwAAwLaecHjeAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAABQx/8DwrJyKwplbmRzdHJlYW0KZW5kb2JqCjI0NyAwIG9iago1 NAplbmRvYmoKMjQ4IDAgb2JqCjg2MjUKZW5kb2JqCjI0OSAwIG9iagpbL0lDQ0Jhc2VkIDI1MCAw IFJdCmVuZG9iagoyNTAgMCBvYmoKPDwKL0xlbmd0aCAyNTEgMCBSCi9OIDMKL0FsdGVybmF0ZSAv RGV2aWNlUkdCCi9GaWx0ZXIgL0ZsYXRlRGVjb2RlCj4+CnN0cmVhbQp42n2ST0gUURzHv7MlQqwF ZSZS8E62B1cG7WAdjN31b8q2rGumCLLOvtkdnZ2d3sxuJR5CiC5B1jG6WNFJOoYHDx0CDxGCYl0i 6CgZBIKXkO03M7vuiNqDN+8zv/+/33tAXShtmnqAAXnDFsn+KLs7PsHqN1CHBgRBK61YZiSRGHaZ bHFk7X2F5Jyb4eP1/10NghICElWAxqzH1xye9njA4fu2aRNPOqzk0hlik7hNpJIx4lfEZ7M+nvZx hlsK8TLxTcUUFCeQIh4oKVkn5g6xbGQ0g+SXibsylpInJt/AU2cWXpn2ENB9BTj1uSabsIDld8Cl 1pos1AxcHANWOmuy3aQ7H6lp3VI7O1yRFIwCdT/K5d1WoP4FsP+8XP77ulzef0M5vgMfdaUoSpUZ SdIXwOvDXY393OBCU5hzXwlRUDWd+0Z6vNrr14tH9SWrdBJ7M3FXF7BE9zB2Bhh6DLz8CVx9D1z4 ACQagNR1BB6hum3+wM0TK5gPhZbN2axDljtY2Dk6WYReCGexQt4s2lywQUNpb2NpXWeuqcUEt7go 8Uw78nqx2u852kFujI7QSfMKqNzqrbA0k0n30N2gnXgjw3t6nXdBvKhqfYPOhdD+pIq+UY+l85o9 mPI40G3o8eEKwyjEb3sxsWPa0WQ1vlUa6a3KZ9K3EnS2kPzGbGHIsWki39BcLjXmsZSay8XiFV7F OHRwaDDoa4AhiX5EEYYJgQJU0mhkoZGUuzaC2MLssZY6Ej5mpN8mn23X5x6K5O143UE0joW2gwhM /ib/lrfkJfmt/GuxpRiqaRbElKasP/tDcZ3M1bgVbaUmL75CeSOk1ZElaf6gJ8tXqa861VhsqUVy cvAn8T1fl9yXKYxpN9Ksm6nk6iz6RnzZTpoe2a7NrzbXcm2dXpncDK7NH5pV4UhX/KCrw/81O78/ /wfNsAFoCmVuZHN0cmVhbQplbmRvYmoKMjUxIDAgb2JqCjcwNgplbmRvYmoKMjQzIDAgb2JqIDw8 Ci9EIFsyNDEgMCBSIC9YWVogNTQgNzQyLjQ1MSBudWxsXQo+PiBlbmRvYmoKMjIxIDAgb2JqIDw8 Ci9EIFsyNDEgMCBSIC9YWVogMTcyLjQ2MiA1MTQuNDEyIG51bGxdCj4+IGVuZG9iagoyNDAgMCBv YmogPDwKL0ZvbnQgPDwgL0YxNSA2MyAwIFIgPj4KL1hPYmplY3QgPDwgL0ltMTIgMjAyIDAgUiA+ PgovUHJvY1NldCBbIC9QREYgL1RleHQgXQo+PiBlbmRvYmoKMjU0IDAgb2JqIDw8Ci9MZW5ndGgg NzAzICAgICAgIAovRmlsdGVyIC9GbGF0ZURlY29kZQo+PgpzdHJlYW0KeNq9VE1v1DAQvfdXRFxw pNq1Y2ez5tTtF3QFYqVuubQ9pIm7cZtNIscp23+PnfECFUEgDlwSf8ybefNmPDTaRDR6f3CyPji6 YGnEKJFUsmj9EKUiysSMpGwWrcvoBl02cTJHVplGWXxm8gcbY5lwiUq/xtboLreVxqata2y6Gvd6 6xFDnVvdNpiyGM+zmURnqlDuJkP3MXZfZWLMuUAJpTK+Wy8PaODkPphLIjkDAjcQSHdVceeQMkFL 4v8cLQfTP+lD54dSdMu4+Ki32qoSbi9XYP1B5aUP5ten7bYzqu9jzJCOGWobsG0942f/AUuOVqtV PBfoEHZA4XEwDjOCnzwa+1XnFl3nzBx2BzQxTYjdWYDe0pR+9Z5b8wQkdOPz9WkyTlIhIc3OtBtP zdmzNz4nztGn3BResQq2TqqMeOzRBc8iJggXs8TXzLkSGZFJUGwx2Ko1/VuHylK0KEvvV/WAfF1t h0ycnzQB5HIU4qVUqoPqrL0IocRAwuejSm1b45mC1ZlRO1XD/XWjg5C9tqO3n7NNIQ5ngoH5aaV6 2/gkBwsnV9YoFdYZ5oxPqbWqdO3KWneVzoNYrl4cLWDNJKNiCnd9tdgfJxmhcg7H59tc1+9iLIRA j5bP5HE5pkRUObyyD26W+eCC60KFJAjoUIb95zpooE0+qdoEs0kNfYN977kJOffg/65n+vdy5sOx e/nkN4IGxHIFgb74oLnr1sH8SbhA4VT3RRsyfemt2o5ahRwum4JMpevkEvsn1vd5eGR+arnQ1vZw t/hRhHEIDmrK18n4Znb34whoTTtsqv3zDepRljH5r93YeW7PrgeOi/3UGjMsWlK0218mZyLd7M4E OFp7NcPrDZz2nZDXrmcZm2cMne867SYEnC+HRoXBLA73Y4dRZys4Fehm5ZPNN8GGibtXDM7XB98A 76+hDgplbmRzdHJlYW0KZW5kb2JqCjI1MyAwIG9iaiA8PAovVHlwZSAvUGFnZQovQ29udGVudHMg MjU0IDAgUgovUmVzb3VyY2VzIDI1MiAwIFIKL01lZGlhQm94IFswIDAgNjEyIDc5Ml0KL1BhcmVu dCAyNDQgMCBSCj4+IGVuZG9iagoyNTUgMCBvYmogPDwKL0QgWzI1MyAwIFIgL1hZWiA1NCA3NDIu NDUxIG51bGxdCj4+IGVuZG9iagoyNTYgMCBvYmogPDwKL0QgWzI1MyAwIFIgL1hZWiA1NCA2MzQu MzEyIG51bGxdCj4+IGVuZG9iagoyNTIgMCBvYmogPDwKL0ZvbnQgPDwgL0YxNSA2MyAwIFIgL0Yz NyA4MiAwIFIgPj4KL1Byb2NTZXQgWyAvUERGIC9UZXh0IF0KPj4gZW5kb2JqCjI1NyAwIG9iagpb NTAwXQplbmRvYmoKMjU4IDAgb2JqCls1NzUgNTc1IDU3NSA1NzUgNTc1IDU3NSA1NzUgNTc1IDU3 NSAzMTkuNCAzMTkuNCAzNTAgODk0LjQgNTQzLjEgNTQzLjEgODk0LjQgODY5LjQgODE4LjEgODMw LjYgODgxLjkgNzU1LjUgNzIzLjYgOTA0LjIgOTAwIDQzNi4xIDU5NC40IDkwMS40IDY5MS43IDEw OTEuNyA5MDAgODYzLjkgNzg2LjEgODYzLjkgODYyLjUgNjM4LjkgODAwIDg4NC43IDg2OS40IDEx ODguOSA4NjkuNCA4NjkuNCA3MDIuOCAzMTkuNCA2MDIuOCAzMTkuNCA1NzUgMzE5LjQgMzE5LjQg NTU5IDYzOC45IDUxMS4xIDYzOC45IDUyNy4xIDM1MS40IDU3NSA2MzguOSAzMTkuNCAzNTEuNCA2 MDYuOSAzMTkuNCA5NTguMyA2MzguOSA1NzUgNjM4LjkgNjA2LjkgNDczLjYgNDUzLjYgNDQ3LjIg NjM4LjkgNjA2LjkgODMwLjYgNjA2LjkgNjA2LjldCmVuZG9iagoyNTkgMCBvYmoKWzMxMi41IDQz Ny41IDQzNy41IDU2Mi41IDg3NSAzMTIuNSAzNzUgMzEyLjUgNTYyLjUgNTYyLjUgNTYyLjUgNTYy LjUgNTYyLjUgNTYyLjUgNTYyLjUgNTYyLjUgNTYyLjUgNTYyLjUgNTYyLjUgMzEyLjUgMzEyLjUg MzQyLjYgODc1IDUzMS4yIDUzMS4yIDg3NSA4NDkuNSA3OTkuOCA4MTIuNSA4NjIuMyA3MzguNCA3 MDcuMiA4ODQuMyA4NzkuNiA0MTkgNTgxIDg4MC44IDY3NS45IDEwNjcuMSA4NzkuNiA4NDQuOSA3 NjguNSA4NDQuOSA4MzkuMSA2MjUgNzgyLjQgODY0LjYgODQ5LjUgMTE2MiA4NDkuNSA4NDkuNSA2 ODcuNSAzMTIuNSA1ODEgMzEyLjUgNTYyLjUgMzEyLjUgMzEyLjUgNTQ2LjkgNjI1IDUwMCA2MjUg NTEzLjMgMzQzLjcgNTYyLjUgNjI1IDMxMi41IDM0My43IDU5My43IDMxMi41IDkzNy41IDYyNSA1 NjIuNSA2MjUgNTkzLjcgNDU5LjUgNDQzLjggNDM3LjUgNjI1IDU5My43IDgxMi41IDU5My43IDU5 My43IDUwMF0KZW5kb2JqCjI2MCAwIG9iagpbNTgzLjMgNTU1LjYgNTU1LjYgODMzLjMgODMzLjMg Mjc3LjggMzA1LjYgNTAwIDUwMCA1MDAgNTAwIDUwMCA3NTAgNDQ0LjQgNTAwIDcyMi4yIDc3Ny44 IDUwMCA5MDIuOCAxMDEzLjkgNzc3LjggMjc3LjggMjc3LjggNTAwIDgzMy4zIDUwMCA4MzMuMyA3 NzcuOCAyNzcuOCAzODguOSAzODguOSA1MDAgNzc3LjggMjc3LjggMzMzLjMgMjc3LjggNTAwIDUw MCA1MDAgNTAwIDUwMCA1MDAgNTAwIDUwMCA1MDAgNTAwIDUwMCAyNzcuOCAyNzcuOCAyNzcuOCA3 NzcuOCA0NzIuMiA0NzIuMiA3NzcuOCA3NTAgNzA4LjMgNzIyLjIgNzYzLjkgNjgwLjYgNjUyLjgg Nzg0LjcgNzUwIDM2MS4xIDUxMy45IDc3Ny44IDYyNSA5MTYuNyA3NTAgNzc3LjggNjgwLjYgNzc3 LjggNzM2LjEgNTU1LjYgNzIyLjIgNzUwIDc1MCAxMDI3LjggNzUwIDc1MCA2MTEuMSAyNzcuOCA1 MDAgMjc3LjggNTAwIDI3Ny44IDI3Ny44IDUwMCA1NTUuNiA0NDQuNCA1NTUuNiA0NDQuNCAzMDUu NiA1MDAgNTU1LjYgMjc3LjggMzA1LjYgNTI3LjggMjc3LjggODMzLjMgNTU1LjYgNTAwIDU1NS42 IDUyNy44IDM5MS43IDM5NC40IDM4OC45IDU1NS42IDUyNy44IDcyMi4yIDUyNy44IDUyNy44IDQ0 NC40XQplbmRvYmoKMjYxIDAgb2JqIDw8Ci9MZW5ndGgxIDEyMDkKL0xlbmd0aDIgNjk3NAovTGVu Z3RoMyAwCi9MZW5ndGggNzcxMSAgICAgIAovRmlsdGVyIC9GbGF0ZURlY29kZQo+PgpzdHJlYW0K eNqtk3Vc1N22xmlwaJCSGhqpoZGOGbo7BQaYoRliAGmkpQVEQFq6pEM6paQVpEVKJaQFBO6877nn 1XvOv/cz88fvu9fa63n2WnuzMeno88rbIWxgSgg3JK8An4AEEKypYCLADxTg4+dXALCxgT1hUKQj wg0CRcIkgALi4oJAJZgN6gP1lxARluAXBbABwQh3P09HewckkBP88K8kMaC8K8zT0RbqBtSEIh1g rqgatlAXoD7C1hGG9OMDyru4APX+2uEF1IN5wTx9YHZ8AAEBoJ2jLRJoA7N3dAOA/vKk6gZHAMX+ tWzn7f7vkA/M0wtlCsj5t82HQJRJO4Sbix/QDgYHgLQQKDUYysv/h63/LK7k7eKiBXX9q/zfnfqv ONTV0cXvfzMQru7eSJgnUBNhB/N0+89UY9i/zCkgXP5LRhUJdXG0lXezd4EB+f+15Oil5PgEZqfj iLR1AMKhLl6wv9dhbnb/aQHVuL8NgPRUlOR19bj/d6Z/B3Wgjm5IAz/3f8r+lf03C/xmVHc8HZ8A zflR7RVAJaJ+//56/B9iim62CDtHN3ugoIgoEOrpCfUDoG4PikSAAQJARzc72BMg7AnKMYjPDYFE bQGiWhIEhCM8AX8NVEwICFL9a+lfJAoEafwmMSBI8x96xA8E6fwmQdTpfhOqiv5vEgaCDP4h1NRB 0N8kDgTZ/kMC/Kiidn+gABAE+wNRIvB/UAQlAnf0+R0X+SuM8Pb8YwMqxf4PRBlx+ANFgCDHP/AR EOTyB6Kcuf5G1LxAbn8gyhniHxRG5SLc/nAqgLLi/geihP+wJYAS9vptGxX0Qk33dxjVdeTvMEoJ 6eAJ++OcKCtIX8QfG1At9f4DUQfx+Y2CqAJ+f+N/X0sFBcSTAF4hVJ95BVFlUdLCQHFh0aD/k2nr 7ekJc0P+/ehRt/vfDHdEvQUY7AnMFvDpI8JWMsLpZXNUebDi66kKbC50BfuWZK2GntlO/PCF5+gu JaPqHlyr9SZXlVnkRNvY24y+v2i9YjsCdd8rHT71SM74cLvtY72d5d9Ga3Kcpem35c58Ef6duL15 7nRPBF17ZnWsPM20aDDnx9D3Ah1OiMEO7jITWq+5T2PvqwhRMROlLBfD6Mh6diEmPZIMj/IY4egV X5K0FKyVyfBgp2i8Vu6lI0SHN9nVa7z81FsrtEtbnLg4rwcx80h8wsV9WtmwoLa1RjFecZG+qC+5 O1V5zeVNE5qgGtqeLbN17l9K4Ce+becWLF/eNjJcfYGsjFTSSo31QMOSF6TfGV1+6Lodo+at/ZL5 8thuDq8TFwErJgpOGxlOiMiq/wrEnnxNWfX++Z2eWrWnTR2m7iDR26mkxveGM18cz3dFh3lMKXE+ b72TXZV9PTrjORTo0g1uRmy22ge9OShIiVFIwL2tO0WjrXDwr3Zd2hT00PLLvlJdKCjgPOGL48Rm 7QiVP9rWmpDTH8gD7DlmebdyoPHlvQhzbTgHCyVFhpKiJQrFPksGpjP5TMJL+CQOsVyfD8dHr9ZK bY+vaTfrZhITRU0j7x0x+Uo7+K6hRa7VO77u8S+BY9F0EhOdDEoXCsQVRAEatDjfDu3yLtGBt4AS I2spvveS+BR6Ljoxhz7h2+R89eVnNU9MfIbZxqyTgZtt+DpYy7SGK1e0WTivsOdV3dkpWEbr8J2l bAb/dzzLYEQXO7zKTDye95gTh2syb9TISBxAER6olrknJrfgNXnIxxoHGSVXSi0NM9WccuTW7Gak HHi/V5IyQAS56brAIiGl7tA3Nj/mENi58PATrvYw65d8LOrXEjEip7T9XgqwQDR9bsRepyU0uehW H/Z4AHJlcw9q3vPU644au/PXqDrpGaHzXPhNlPjl7hSruZI0LP+Ih3247OAhibdPev+RAGThm5Hq U6dqaLlqfylLZVNkJnbqMUDkvXMwcX51pO7EJiM0RbPfSUmNpKBOQ+jqGiuKj3/IhXbQCOaK+0ky ntDUjSR3o66i0e/i6rWeX3WjQwlrF/sHju6z/XV700TauCcMTS8cv0x90Ey8Wj/Z37Dx83V6SyHM oLAt6obx1D2sC7Feq6BaFEFAemkVu3rnSSWTZcVVf86jEGy+jE5EbcdQlexk+eOygwkPh0m49Oie EVO2iXLPAogoypbsk+062RrhQuZzhsGFe4jQxuzXEI2jh9rdlcZrVSNTdEonb0HSdPf3+Md+yhg/ POpBzh3BDbBHKq6W4jYZDsAVlOluPATjkVIa944VK2+UMAcqDL8tA0wr3PJMXlydzF6F7w9tGGBR 6QN2VsoOhVZb70MEEA2XMpeQT9c4SPOqzYjwjK4W5a1wkvbX2XZf5KktwsZ8v86Bc3vND4+ErJh/ /hDVDQTbsJ2SWX70H/WPYCHU4nYpJb9xlipW/25AqIT1ITZcpAOIzSo3kCwWdSsjZClENyFaIIt9 Qcp+HorrX71XQzIWiB3Ia3gS4SltwT9DPC0S3w6twD5UlJOSDKXZs9XZq5c7T+9YmS7/oWTRKBkG MY7kObg/Jk6pDst3QViDTgpL+F7YP3ItI1Cbh9FDbn2WThzdbanX+8MoJgRVBX2Y6eospXNpZqid JdtalBvpSSazKD88Hno+Dwidv8UZj+b96cMxVv4YHV31tSlT2tgwfFSrsKR0pymtVoygt5xpws60 +Jo4K+ppW1Fd08igHHMcOoc3EmOXv+6ByrOHq2ksIugbQfwN7jF9z7+oaznYbw+20gN9MSaaoTOR SO8IU6aRk48x2nm2j5Dgz2vOIO3ZdZw9KrLpWStfPOmPgxHi2evDzgeQhJTd85nv2TVN9Bh0asK0 sivnYLL0CusRB+8GxhiVoxkGHvOVHUlf3xaxY+zMHt/sfKr2d8MURmECRM6nPwy+KcQ+xwnQE4qU Egq/AZAVq+FG/cyxWQXzGGxGVZjRquE4sHvWzryxM3vTpNUp4pE8LsOr5XaAwWqvkzNmvDjls5wE AVvWuFgLDB2CHDfO6HemMColbzHFxKur0y/8xScvTL+BOxaGrGD6X0+0sh2Mz1R4o7kiKjfS23cX G14fOKYiU9eSzFMoula012zEGffXsWga7xycxxNLfHXMzYhvbhP3WtzkfegehPd5gZVlN3oIkrWj ap4zrgnr8TssYYtpcFVXsKogssJpC6he8b22Bm3jhscfZ0zAIx8TaO1xjJrf/zbVzzFf6KXeaioa 5fsIH0eCmn5MF8s4BHZbunD7dPyFabHDsHx/ynNFjvjJcRMD69khvTQmMaczCptMVYPn0D1GjlzO 1KbcA9MxSija5aA3dFrQBJaELehcW1FYfSzv+zAqiedp36nh0X4VhTHSPk77nYaRiWegOJvXmcLL 5eUraFtd0BURdEWAAx3cXPDoDXrk4abC+6+40++TnI9I1HkGjMDUFsgMaeIP1kajIBJFni/EWL9K IVtVRKEWI/TLLRPDk6406aCuoWJFSHJV3ZdRq8AxUoaDLf3HaO8TZxKdwDbVQcjvb54JRGt/Eu1+ Er1MX9J55tt6qmf4Td/7My3UzofC1KHEnRZ89i28e044nfNlvcsgH6ER3XRG6WyRir3yt+iNE1cy Bo5wXozyKJqP05if0K2iXvd1yaFX1XyOZVYVYDjOBw1e0MqUJtCmJDvEJyREgaW/QyZEFEzKbg64 hOB8g1D0hDaOPp6J5X4cAuLpiy0C7IsDrbnz0FjB5guxNcYP78eIbvWEq+4HEcTWePA8+FKeF6Ag DJJbdf3G6HIyzCx1QKR7lR5tiTRPZPLHMAt2tsrxess5jIeFx7CdKdZ+H79qQKxcnOSFIQHuzfHL Vp+En4GcNCpdwsaaceeuDLdbPBKngtboHE0jPwr9J7dCdB5s3m2snC32GzDJoB+Dz8kHXJl6nx/S 6Fi5yBZCcZkeF/WdvIium55v+Ll8LVylq0YrGUuTFl7dCUsJEYU33o4OP5QzcwAwajg5DNbwkFTA ZvW+7Gna8k+7QJpAlEk9BVkx9XeGdGMVCqMybEWHTTL7mz3Aj+adqbby7TuX/mVUZaTYpwc3ZnOB 5FEeTGgcTcqKt3xoVzTHZiFf8eeszEmKs1XuAcAZ5+ebgqCYOvYF+QXwKbjp5ILeByOQJaL5fbio +dPv3qWQvHcBNhDqNit5BfSkJyO0EcxyUZxERR35bSdR4DNAtHbp7vKrLJqfLWx7Q7pcK/0sYenS 1njlO3w/HF0LeBWcsEFQHBJI5pcG0s0p5RHVSB7jjgcZGGR2QK6WQ6aCrQayp1WcZsaHi74sCtv1 Dbg5xG+LZPiqSQrZNo4B1ZENm4OOMWLVR2/ew6FBHLtoLbUWAZhYo5G2zVbc3HV3SS7xiqNoSVy7 2orXoVakE6QIp+ZzHNJbEhKtn5vz5omYUhBiud7LZFutd1kfzCRcPe9DYYqZTE91LleaMGveSezt KlaefUV26naDa/SWRm32dXLCIL0cLO5NK+r40oSWOPv64qbayf7W15o77w96tpKkluFMpFWcpAlN ha/Z5MkNvl7ksNyu1ejKvIqtOyIcyPpAnZTHlBVFGt4VfoEzWCKAN2Lnr3L6TtSu9OaazV3nJOnX 3HAi/Y+2JGp8tnZROiEcp9RNMlW5eg17Tj21vCkLr8Vr9M3h/WfVmuUHq5m/okBqHlTfSvuFq9Q0 Ehb8nJPQQ2rEcL685DA8S5VOyHqz2/dq6INE+5Qb5aev467l19s9RW0vd+iNQ7yHSTkzs0J16u6b fJ56a1O3pCAY4mZtje/tywcO+JqNZBaV1mToWiq5BQ3NmKpvtFbVPAv9QUeruY/o8zqkCtvQ6M+V GgGY+93h4+YTbp1iniRBRlPKCJR81BGmj41v4oWZ2Gzaw8yuJz/5ZrgFSMi8pIhybHm1xroj8XTF KlMtOiSUQIVFmYkXbB6t9LR5z2Ox/ZiYRVArpwDZkIckwgDkVUilArE2r3KxKMXIM8ZIXGfnBULs r86f+PWvfi6jPe+Jt3yfshDSNANrD2jQQMNG2H9MpuNUZEpUbLIn4/7yE52P5ijxjW/n+NYer3RU nRl4lWLWgo/uY1i7E8PTwrUkBkv9AJeQJUY/QmQrgbgHXnEnD2mOYPwPUhuAwG5KbQOcc0Cy595P wHBKU665W7SYf4gl7Rrx8Q3NKxekRX0prGKdeOzL9230c2bfNy5q/CnPRC9zx42gY00ffO7ip+Ne sast9PU8J6eN2M6mqW5vbWgeunYS6XBiQtjRJmh92MWn+ECouWYnv4BIPfXC6oauOPPfUTpxWBuZ RRCQleJugy1fHBkk1IvC29ifyz/setnPiFe6+WhEHmkanxE1Z0cnByhSqEgqhUt0t9jys8mho1+n 5WgAiPPuFn08WUsSjkTMsDXekIqxnsSn2AsR0xkgxxYd6EW0QnKWEx29tlK0DMiXNaODWKEla919 mCfptMLkWRB3S9yvTIHpzATddDlvINwPs4TG+AZ0ihMHuIYpDfJ3tGIbOldaHps+HmelvVtwH5Sa xdPX0llkIR4lwTrAITcw3dHcMzZz5RCB+JxPup4IKEuQx1V4m14dn2afuGqs22GszzFvH5WdWxEm rLRF7JG4kETdv89kNryw/eBncLg1Rh7t+xoBf+6FDHEomX9EcfsmtRkt8aXekmpCeoEcmVnj7Juf JpWntUqx3F1WLRJexuCflB9c1hdMwhMW/fayh4zue+uqmlSOXoRrzGCUnDLrmXUYVo8c8lLAm+2c HszXS9m4V92IGs951lb8On4lzm2z5ds+6dLA3NElmFmmE2F8V5R3Cx+oXn0g/Cl0X+tz77gx7qJW hQnuhmzj0jg1bk1VLPF67LLUYiCJ5OaWE80GcanTgt7hitB99y2hL+QhLwqe2NWwpoiLyVisoIMe rHWMi671UapIuVnGjtElxeQKioOu5Zfg3IBani5N1mLTB5eFLylP75/Vy8di9Etj2toglKymDpEZ TVyXU19xJmpqQ9F6S8TNnPT8xYTqW0lIffxb0Kn1yKjy2+I88CLSn1gTMuRWYm0++kVbAUvhU4nz e/JqEwqGD6yRTH/DHmJnNlrJ0zZa5J5AVzaekmfyPnrUOLm9IrdnUdGkZCG4N3OvjLNTTm5exy3Q VXiNDKy10B6EXeaURKNHjEfhg2HTcdB0O8dnpKp0ZJw27bRfibP7asL4dmfmoTUk+4qioNDmcZtl DYbLENOIwevZOMvLNj0Aug7NPU79RTbOiE7tOtPsNiznuABtiuRPGbrFu1bCRgd+mAj8x1OYn9tv D3YROwxK++XKon0lEBVAmXXLNLO5pSIdeuH3NPShlu+KPanov1hSB5SVKCpZoGZUg+AVIhaS3EVe rmKZWhF+qofIYmkXND6WPf8XWHt49HlolzHCtS+DVcIqfMdJYy1+NKfmS9mLdqZC53RKlh9hbBtK h6GZSZ5ZC2IyviODPFfPkGl/7o35gsICbcFYHkdj5yOT7zykmQdwl9f/ozw8xZUI3fOBZy1Jwgiw UhwCfg3Te8B5Ky0KSxnMKOc+xXcZ+k54cn9gg1QQicOS61mYj4YWqe6RHSeUGVJ39it/Y0BzB7Py SejBoN4kXZ28dt/HYcXGj04bBjBCdl3WigfvQAReHCZj83NW9qv07GFFXE0rWE/TqR59/2lAP+ZT Tqtv9evIe+eIy5mDgjX7s+jHVUrmF4jqZtPIVF4GlltK0gQpjiiQhnhe9bpeX/7sG25qc5Y7yNmO DinD23tOnOUWZJiluiptkE7S0InGVsbIIRHN2J8DcEupzuSxTZlvQw0ML9OJB97lQXJUfLQhemLk /TOepkEYRR1Kq0aBvrqcF8VDlgdK8mTJYpUb6hPygs8Ro9y0ZYxTBKv625bdhLIaH1yeduMuavby 0nhdGz3BVsERc8jX5QpasJ9pqCawDTHI6X7RtLx6C6ZT/zxH0nhvg966VeLXO/+MUKkQncH1NPeC lAm8z7Z4QKVyvwC1hme9ovdwxYlHZF+NJXGsBAQ3ie6Fe//a2ogMOTlbZeUUp0F4JlpeGUm8ZANm NaRRByaAkqS02oJh27zyEIgDs/CNI26HhuzOd6HgbvLrS4mPasci+7+Ed6gDwHLS7yI13wyu8KYQ H8Gn9/Akhh8apmFHS+IZ2mfN0ly2hf4E9MbceGHq3Ewgvkyd93X12YnG/ggzAmYaqw3fw00UI7y7 l8O48jH83g/m79zgXdyUJi02PBFx+0XxcetViQA+aPDxacmP9MaeEjM06rTsfPZI8ev9F1jflqUZ 4a18pEYNlJN6j2bdPwn6qtRgL6YI37bqTVNiefaTANy5p+gtWLmiqKuxdxvIAm52OaoB18JEB5Gx ykecJhI/3kE6PfL3ZeYaQK3yZWbmqxC3PVmR9RexK3XAiaNKosVpcllN5RHpQe5NM6/GkwuJXtyi JCERoj72DW9fWvYICEOvuNG9U7nOzTfkET5yjtSnQwwiipTjNAcV+GOx8QE3ea48AozuKW/rFvD4 eeQwL+hc4xXuLQyFudgl4H2w/tVhY/WOikPTm4kZRL9ofY49YwLNS79rSqfBOSStbQwC2SkAdzkG muu1EjQWKqY5d6+wWz8nJg+L9FLEJWS3C5gHVt3W0O3Utuc6treJYGP0L9+L8Hdm7QRLS7m0uNUz t1w4g84oONUywSf1VKvC0iHu7F3zke1gQ1FTdfPIqIfYpQ50qSlIXEtyi7IZTUMLjHbBRGUyPQdP 2rNvt0+xryTeCGRACDqlYtazDHHhAaKrbEV9C2YlFF6qfKYyTvR+GPeQz9YG+LbdlB46hVh1nxf0 4/podHwntRdOTLMdFjhUeywrIIuuwqSsQed43OSIriUhAk8O2J/2O1+kZZ87hUuVSZPPZ8QM61wz ffTgh89JE4xgSjAM2Tc0aRmwTxvAYVfwejPRrZ5Ul8QLFf415ezWnR0Vkwfc4xUW3y5j72+wmF/v dzFcz/4UZf8WlNVyu4/7VQBTT1ZuKE/beEGCvuq0BPUcMNSmKURG9vEf04+4qazx67JRhP7QtILV c8holep1+DQUF9+wZQALxUhOK5mO15hzrXSwQBlUlnwfm8aLK6hm2PBh+kkrqp/eV4UYawZbd/lZ Y2VO7lqQ5KlWkgQaiX7gpeaKVWZrVn57EfUjIT26jznlPDiSd7H7eCkirJ9h5TEVpc2v2rS3jKry 1LXv4ZtV7M8MZTCqzmqT7Q0V0gzXcUswCvd0YyRYNH502A5Ij5iLHDXjexfvU891YhM92vFTt/vk nLDOc4QtfYgp/LygZ1Nuw/odvrzms8AzfhvKoWcns3Jq1/2VIq0FFJHyZw8FYqmCgp6ryUpbiCBp rThu3WXF+kKUEyKrQugsBp9q2w+lg/HHyTRJNQVbQYMtQhdXdN8XRCQpH6cH7ENgs+7vtXGQK4cj YnpSPb575jOfOZmPFW0tj8uqD5pbWeo/Ji7ZWgSSJ12JO+nPDIdJHbe1QHBpLGdH+5Bbj9+ScOdH LTzxOhR/Ar3Z1XpTalxL7rM8I1Nm+zn41XGhBs9iNJb7p5E6RyVpe64pLK9gWoZzvavJiT76CB9J tvGIGcj2kif8fDKyYkfxUPvb6tUDxjffnA5oP+wsz6oHlYqYtw3FOHO6cL+YMW1nWkUf0ewBqqe8 /K6x4OTvsqMwH2Sb8jT4YuCl24g9B2O+v4dzD/PbWUpVDn6m9P4YfGqO24rLvoPpWV0bWKvfjvpH zwBb3sATR+dO4WIGkp9SHmhkfV93JGPE2uMLgw7hEVMRJlVXRs+bdF2gezu8frMx+TW824MF5D8n 9p1vax8UZcfx+stYUhFHUnWGbDBLbvUtrj45Y6NqBto3vq4Ixuqtqc4mHrAx8DChW0pL0EID3l7a HRlwKOt5EX/hKU75cdpyDU+mosuKDm7g6S9sBzXK27oFN8o2W8RR5NRRbwFSus7Zcub0zmaCRIjf RWbEbD+AApKSra3aGp+yYh2gdWnY4lzQR4p2YRfUdPeTf37j6JtWmLAeHLuEmZ1bG0kNdPupZb3D Yf0akCHJ2oRBQX8ZN28TMLYoN2i5YV6We19OXbZFhs5sNrqvh+jEldBu1qLE25cjPtHsm8f7HUqT CcHoY7oSe8W5jl9ZpblFSffnLQf1AzBhTSQS7PB8ZoG8mA/I4fBgNx/iKSdK7Uyf+sCQE0C09Caj 08fUnzqdYbagpROjkXSXDZIf0nUKc1TNPomPrXIWRswRh6Cb06/sjW+B32lCR92uxfPmnl83n4zG pOTIPsXhlGqkvFvSWMi769uQkeiGvJuvnNO4iTeCqs87EqCl3HiTnpW5yLpzUcHHzeKh2KWaDw3N z4VPmBwfpp6U5+hf6rThbfR9HlKG1DNLUwgf1754FN5e38UnuK2KPZ0gxk1A/NFCVhsxrjh/blkF pjfuXveEJSgAfO/P5O9PINNyjZcic9geQAuWR5Mt2jIHHy+xu1bG4E60UvTK8q0+M1yNLXwNJyg4 kCbk15oDCdvmhWBK8NjBs1s/n8/n7470BIpb0OiSJTP4OBnyYHY2v9b8JeCr8FXQSjNUDOvOJysm LZ32SlWCUI1ZgH5T2ijs8UBvFDqf6PW6S1vws43tvHcTlXL2GHWSQeTOOhWJHftsnzoIrcJbcFUa ZyrUNg3QLOX9GCoJwW22mfprUoIYrFupOF40rZvgz+Tgfs6EOFlLDkviOpHcXmXfAiL7aSmc5X51 Av8i78pnV7h8RNQcTBV8bInkNU1qNo3rGr19jbmR8L6VRvEnbsa98DSiaQg73+HsWEmBhHKx+WfT mX5A8eKsoa2VykGwTqYEta+Avp1ULDNTzqbKGKbJFVcjrrNtrzZmPFmL7iZuw6KIaNYR7D3sipj+ iy8xEDqyl1OhouTfxhlV8wgncmfYzj2EdnA3MTlS0NyUzh1dQ2uzXixzOVfH6ubGgu3Ry+QZSVuA MuTtZoh9ZGZ6j27zzYNXhiPbWrc88p7ByWwx2C8XCzvg18IAqhcgXo6vd4qvCsfjQU9LXXWv0Wqx xdV7+aSK1sqTRzeUISojiCPuIgvJ0GJV60g19orBTyLgzpzKcTsnjI9Wgm6JRhsxRfYgfgPHVfCx 4iuxEKKos1rAgbjjJ1oP5cp5rKLMAtnqby8cVOYcSGSxJye4o5uZU21n1t737B/py9gPZb5kxzrE dZMkmniibWtmS1SO6X521M3VvVE+t6oRDuzJKoMbM2irV+ZVX+Io4lQWWHes3motFlZ2EJndWcXQ mXOEi6Uj6KN0qzePhr+ZBJbudffRP8Kv86jLb7Xc8Du6h89Srz7a0Rsdo28J6hndMFaXKucPW1gt L4p4NllpveYqFfc/ivbOzAplbmRzdHJlYW0KZW5kb2JqCjI2MiAwIG9iaiA8PAovVHlwZSAvRm9u dERlc2NyaXB0b3IKL0ZvbnROYW1lIC9SSEZBUVIrQ01CWDEwCi9GbGFncyA0Ci9Gb250QkJveCBb LTMwMSAtMjUwIDExNjQgOTQ2XQovQXNjZW50IDY5NAovQ2FwSGVpZ2h0IDY4NgovRGVzY2VudCAt MTk0Ci9JdGFsaWNBbmdsZSAwCi9TdGVtViAxMTQKL1hIZWlnaHQgNDQ0Ci9DaGFyU2V0ICgvSS9M L00vUC9SL1MvVC9hL2MvZC9lL2YvZml2ZS9mb3VyL2cvaC9pL2wvbS9uL28vb25lL3Avci9zL3Np eC90L3RocmVlL3R3by91L3YveSkKL0ZvbnRGaWxlIDI2MSAwIFIKPj4gZW5kb2JqCjI2MyAwIG9i aiA8PAovTGVuZ3RoMSAxMzYwCi9MZW5ndGgyIDcyNDkKL0xlbmd0aDMgMAovTGVuZ3RoIDgwNDYg ICAgICAKL0ZpbHRlciAvRmxhdGVEZWNvZGUKPj4Kc3RyZWFtCnjarZRlXNTrtsdJSQnpEIbuGLq7 u1NigKFhYGDo7u5GQlq6pFGQEAnpRqRDaVRC4s7e556t95y39zNv5vus+q31rOfPQKOlyyFtA7EC K0BcPTmAnEARgKy6jBGQBwDk5MZkYJCFgkGeDhBXOZAnWAQAFBYGAqRhdgAebgBQQISXT4SfD5MB IAtx84U62Nl7AphlWf5yEgRIu4ChDtYgV4A6yNMe7ALPYQ1yBuhCrB3Anr6cAGlnZ4DOXxEeAB2w BxjqBbbhxAQCATYO1p4AK7Cdgysm11+KlF1tIQDBfx3bwNz+bfICQz3gogDMcJEsALhEG4irsy/A BmyLyaUBgdcCw5X8f4j6z+QKMGdnDZDLX+n/ntJ/2UEuDs6+/+sBcXGDeYKhAHWIDRjq+p+uhuB/ iZOBOP9XGWVPkLODtbSrnTMYwP2vIwcPBQcfsI2Wg6e1PcAW5OwB/vsc7GrznxLgY/tbAJeKorq+ vgzb/97n30YtkIOrp56v2z9p//L+m4G/GT4dqIMPwJSbk5sbCHeE//79z+w/ism7WkNsHFzhC8Ev AABBoSBfTPhmwIkf4A8EOLjagH0AYB+4Yi5OV4gnPAQAH0kgwBYCxfzrOgX4AVzSfx39iwQBXLL/ kCAvgEv5NwkAuNR+E9xT/TcJAbg0fpMwgEvzHxLiBnBp/SYggEv7N/EAuHR+E7ye7m/iA3Dp/UPw 3eEC/SZ4PavfBK9n/Q8BueEFbf5AeEXwHwgvafsP8sNL2jp4/bbz/2WGwKB/BMBd7P5AuCz7PxA+ P4c/EC7T6Q+E63T+A+FCXX4jEC7U9Q+EC4X8g3xwX4jrH8LhC8Tl9tsMvw03+FuC/O6UFx7hDoPA 9/3vtf4dCFf8Rz9AuGKP3/3CjR7wVftthif+HcwP1+RpDwX/MSC4aE9vyB8B8JZhfyC8Za/fyANP 4PsHwpvw+xv/+8nIyEB8/DngN8LBAy8LBML7EeTnDvw/jtYwKBTs6vn31wj+8P7Ntg7wZwoG+4Ct MZcXINaiEY7ZbVGvg+RLp6pRWRFl7NpTNFr6ZnuxwpdSEZ0rRlXdWdebjW5r8ghw9lD3qL3vKDzi egK0JxROQ91TcuYf9rws9/L8OimMLvLUfXfdaK/Cv+F2t819P+JH1JxZH3udYVw2VHA2/O2VFrOc 3j7aGg1Cv6lXa39+hICgkUKes350ZDMjL40OXo776xi+6M/eeBlpKJ8nw4Mco9E72FbPIT2wZ7el 6MXpDxbINhMGlleqJ1m+T7dNblPGr541hZhVxW3DitVzjZPq7qxM16hfAk2dLxLy55gu2T1f5Na/ dVupnyssM7nRRCfjq1aMVRF86hDX1VtGo4/QlNLAGDzZ/rmkx97SROMn1XjpAqW9quLjmxg/0eON 1lmcpK53gBxsOiAj6TecBuZ8FvpHFV7VyOXkhUj5+7rW4Fwqj5QmnANHhfKGGNs+PFot+vndKA7l 9TdLR2OZyzLhQ5gC4vZlKe5yBnhnYtuWGPL4cU59LdXy6Xga8A/PcIKK4jXGYpDahb9A6M+2y1rl JHkBipsN6gZ9ph/b475PuSPsVCUYWSASyDwUL/TN6I0M42L3OYC2pUOLUi01TUyTMthAlxvDaPFi tbNVhkp+z7J1Tk0OM40kLNknepPBfOQUqxKM3v0ZXhp1RkOR3wvP0WUfkHCLviwjJNo+3cXKXyyp gub2AAttF0PxKDoNtp/IvspPH8kKIt9xL+LGejCyPVtYMR8yJyGnn21HOy1lmAtWFLQ5zB9pwksM fXFRW3frrGB9wB1pZid2GNeebBFWFFzCWGN45i8RqBGwjTPb/u0pN/8QYWLV8i2fEh/hfdX2WqGz YqHESR5+sV7wR3SLMmvy6ZeHAhvGScBsQHBlt6v+5PwptL6fIy8LRk/p5w504iRM3HrlwSbAhFdY pjDGg9O9tR8WOnEWi8MJbXMn4I8MpqLjDYDts7hRpc+/7bPGXgvWyITyHmHckOyOuokFpUcQ5eB4 REgOgwo2SEYURVwo2HYJOb6VRHYmvxo3t5mp6wzdU2Rxj4jQLpH//LNaNIzhsDZJgbvxkWfB94ip ti5yWFij4gqPrs3yJEY83s5e8PBb2Q5b1SVYViQF9/nA67ODOEYel1I0HdNMmWx3RQVFg/nOrauM KF5hScbRLxbsV4Jzxu9/UVsLNCTlfolRbtaVnvYJ73+qEMnBJLK2Loh/D8G2VhAQ03zEILp9hcRv 20BC/EbO/BnyI8GSzauwPVFJV8aCkJnKoO80kqwmLZeZRlzU8iYciHd1m/V1g2Jq8dQ7qS8Z3Bom aCmcLjzlnw0rfYrEaEd0Ff887xGN0doiXuNNQ4ziU23d6DvUfKO0DngiRUxtnCm52HEh0uf+Y6/g 8ciIrZrI0ol7LTdzZmW61k+QBFzesucStWDBTT6f3ir5i1aF4qD08ekhaT4f2+bKg97w4FqSRiRe CVa8JPtla/s3XeEO7mupFOdBf5QuYykfNkSSDHk3PO5AcycbMqb0ywaoNxJP8jn2p7199a5p1rkH ghDyCKoJvR5VZcQggV2ifB3eT4vugxEn1/caE4wZlEBuf1PogQ04rwfzhUihLmmrdtPJbVWXnT5t XTaS7bKrS1nXz2ABo0S3OMPKJGHBHtyonraKLspMTNbPOiDHyvBSnMrvIdwn6VGraJq85/s6DzPD hHOyZj3KGR/YrSg5lJwRv8Loradxzu8svjeqVSThMM2WahH3+XjJ6oKekKBqO0aDNxiGusnM7j5h g9BJn2AMaHa9ExyPyEYrtZ0b5zf+cfojUgAyjPu9f8K9dpml8/uF4ba/mhk9oiY6HqUJs2ZxSzCa s6xcwOcRptHnglkjtXTKU3ggX/0lMbYpKYQjC03TKeJRxZHcdONeRgWDW5c3irnDczMPs0bHo3ua jAXihs9Z/W5qf8KsP/YPCZZP1+BQ784fu+Y0zIp+xwzMMzOyUsV7QkM+Nmk4Bfj8BG3MlInqq/K3 dw116tiZBl/t8b7RalY3qFqh6y3ZktuYPcr2td9rqo3ZI5zocygvsQhl+jQe9bKa8hrjFnKXMsOG XD6IPtg8laUKvTDVHhZ7E6/dz6PMYiyC/mxg/j5dOZtoGFvhg0/l3u2ZYBdziQPJdU86eIIqvrnG h9FylAv2wh+vQrUO+N6tjP5j8t5K64dhaweSrEEDEQshzlolMFqlSI7N4RRI2Tx3QYhmpk3iwwkq wg73dpX3pR1+CMT1vSNN1DWdS9r1rw1yo5N02rraXUKLKRz/xXeIhtR2bkEwwos6m+95wuVi3BHi VjzlLrP805JsX0FOONq1BSiYRQSZyAFbSZbIbG/8Gn2634qU2Iy+M7zNmakpSMQ2kMCSZbn8lqWM /0vwahGZzrQ5SJiZwv0A/5m2QlKZ99ezrB2J3IFfEEe6az/gjb8KUrrHnqXY4refazelxaNXd0L4 X1BngTYPQfjlsyewasPaQHCgxBOep2J4OM8zmh5AfnrDYx/6pLsuUa3ZShnbaQPMQiaFLZFXj+xU fFQRx1Ku1kMs56zaxeytiXSFRiPNOi5kCilwKH4h2AFqWD6t2tPtEAO2OhdfZjJuq+jnxfFz4hHd OAXaObEN2BjyiMdarwE8e3JTJvB9q0IDX+gWfGlp/BwCNTk+rqSDOpULUoTnOtXz7zYiJshWh4h2 tRe1V/Rct6PUtw2Aw5zdYO6ASMFwCwo8RhbYGmsA+DrzjqQRrRUsjEsvn73HU78JVKqV1LFAhVop YtYfiXLVis+KSEy6VmwcdQcKs2s6oe73k1rTsOpaF/sIkMVTO9FZ6V2S0Ue8+vL8SyNlpZ83t5aK bsG42yT0kpGEYyWJoOrWolOhZFc//hxjgaZuX7cLTQYZQI3v+1RD0p10lbibw+K439DfnLGXIJSD 4UDaycNdGmQze636PTcHX91enjqzPCvjjoUCMSnbdUkp/N6dBEoqDLm5TjV0RCsTkaGiqGCXVt7K pJKcEeJcxeVg0tWwV0FYJhgEylC6RhxH6UhdnGNcwQRDXS5ytf29UROc8gcaQrur88TVGeilQuu5 SdEQH2vIDVkMvIQOcw8NkyJOJeNb6WePHe0gzJ2IM7Ej1wxpik1HZe3yGQTX6bFRZY9HWF7k4b2I wRYxK5dP5qq0wi60Xs9xCbzw8l+lzDrV2f+CUt7SWcH7ZpDcU5sTvJpYzrOeLERAdr/tIrg/QfVD tJBswXdPzjjpBWGizvuh8jLRYuoH8FqMaYige57JBKIbftKlEMV3uhT97pxj6ZGibGbB+0grirKL BccIkoDB1o7VQVOzOXIi9AIur7Zijnf5kvTvG9eZl798t1CSZEWVDxCa8vNlt3uVhkabX8bqOCCA PmVf0vh5c1M2XXqHJ8dLRyFXyl6+kKqrtlc1vAdr8RFcGTkZL2aZSvCk37dz2wYBxSxvvAnr1wnK YWa4CS1uYMiabSyKVzWm6oSzOAaxeA2HheLD7NjmdUsjdrtluuZyDCuR3EHw4lZEH9PO4GXop2jQ Kx36YHchCs447Xd6GzQL1y041XXGDxUEi90PqTRCFp/dKy2Z5TtTpoh1ejtx8pvDXmETP7cg4bQt 9X22jMLHLQ2eZu5blhbFMFQtkiCpHq18U/yl+3nIp7D2veFhG8ScuFoIUwYUga5wf87qefllrOD9 1WX5GdtAloWc/Pzbkg+d3a0POG3oWtZDi8IEnaiT9e825WUcX+/QDqHRDBy+DgwSTnaFoJDuhe9Z +vYFVo0SqTLHeseh58idTw3Py0S4AcY6jgNYQlpwZbifodiO7T4q3d5B8TdVaJDljPtAe52QVJ/N Isv4QO2VDCXuE29jDcyY2bePgRlkUJSy2EGf9Y3rAY5b8fW8r6e5ZEgaYBzDY7cSIaM85M8fwOhz 32R6FtmVDQxczmdgHAfPq2+/pUTpsouOjiGbVHT85JR7g1bTeX90Nx3IXQac3vuu92oKY8kvJuRd LH8bmYx7oIpwP88CKEPLxWaEas6irJZwcgMQIK7H7pGyRBqEE4AsvT4X3jQmM7+buR9ahdtPfFC3 fi8Fey97TZeEZvsKUKRE3o7gEG+B5qlr/PhJ0OJuBcfmld7lx4UIMyR7MzOD/l/+8uSiP63HrGi0 3gCE5RI/7kqqy2X/IDaOT2AT2uGUt6MeqnG5K1I6aTkiaH4SaWHK2tgyym68CMvmEZdYMvPDe3xb xB5Tp7NVHSerfNOMrqz8o3t88B1IoG50Ey17jCljWnKuXlo8SVtJGIiM2uwhU5fuUo3tXx8j3NOc vStkH+vRPZfstDf8MpLIL4GNpQEn6F0xzU3gNGcbg8aPKrtLVgsWXsLnYtOxhIPM08T3z8s5nSUY XiLEngDNVB6R5NGqU3BZXXWv8d6UfH8Ej/vr2etQ74/Ixda8UTNOAfJaxV2weaN32109/ZQXaXma s47XNeviLW5fCEG9OI7hjEUdwDEfDBK0gwaCZlOeWlbeAxIccE+TjhIJvJt6ZtFd9er6N3f8+IRu 32fVT3B0bas2b7K+UW0qKVMsp0E21bNCdf1KfWacCPZkIX2H617NmrpuxH02dT01GTitznuRPPCF YXTujsQ0ekS68hO7EgkMMIq84lZZgRHt6QJpI4vSrBwmeRznXm6x/7SWGvPRzznd3YLqxpAkCvXL mVX7VQnwC0JIcsmHNtMyjAax91LET5nM766+nNcJkiwuGjjuO5GO1udyLzn6HHLfJqhMoAk9EtGx kh6gJF2wLqf6xe3fJO+RHUjs/OKhYf+kUWzZI0vFy08a9LFCVWAC8lXJRNTu0pnqVfRzwuI7rJd+ XZOpR1PHMZuRrUuCbi0CNALDerv4ZIfeCGzhRgtln375R3LG1nKKkQabvPvRNt8MikrscDj1hlYs IYSUvp2KO1om+7p0hrXP6mGfiTQsISW+ivWWor6/gpL2Zn4jz1/yxW4Wg/m6ztpJYCsrohXD/WH9 S/kWbJHO1M9ZcwUG8Tl3oYvnJRqz57Yr2U4jzcUfXwcUB/wcKU2fylUylD49k82ym3fGxQi+iW6q FwE4kBARUDyN6ZNDyWAiVyhRLQ+RZw1+lwzaDqAMDa/V/3IDA4G+Ngvc/Zo48I0gbnG6GskbF8MD vB+50AHJ9yRkdV5cLEj2z//UTr1NKnmIaJ4f0NJvdN09jUQA8+QembN+a79m8MZUONCZEPObOHJn lSuVS4+EfLbfCPWearRidyivBPXQoXZNWa7GR1GAMZ8IcB1k9KOMaVGJNgnGovgerxA7tBqJOL0X Tu6MzNMlkdnjrK0pOCzuZBsujUTCFb3yDFrcPkffVQgfqNTlRaUxpj9z1q23H3to9+PDrPq+l86D gjdXBRKrIW80PVH8UVhZOO6HTS/VPvT4/E0QbAP0rRsGebv40kWv+eyjjKhd51CsAIf5gJbCIS16 wnH/BcG4ZlY301MT5ff+JHQlOzhRn2fWyELJSbtxB+al0zw+4BMnSxJmyqCTiLP5f5Q9Sx5UdbMQ 0wVuDMsMvXoBYcnrTt26C6tOLNlrypCxZs9FxL6hHlz/qYgE4zZwHiqO3RVe6vKIQMJIh5x6i508 57hcEbBE4+eYhfifbUA+REh9XYG9AZ6Lh9MVOk0RsOAgqHOGIQ66zzemhluK5lKkdJ6KFswlLdV1 MuHOlMq1Qpl0i8Pv5B9U5yqHFL0CJT0omDS76GJnuLKHLkunCEu/fnAihabIN36k8bG1AYwpURvq BtzV6O4auR3326s5B6rJDQcFSsbxurpNz5CILdKrtyKxcbxxDNEHG5+eJhMk8NPmjzGK7+z7nUHN IjmAOmtaZ5viQ09auLQ470NeRZZsk9q3Ta4Mx+D17KSam3Cs4zD+mnCxMW8TWY22731lNRxJ58Ya fFMr8cPEJG+WlYyLpq7rbA3XwtO4Ya2NhxPApnTpJiu89bb5K91q/jt3ky9Bx6LIWZFF7IRe+NKR T3dH9iQO6/svr3UJD7bCsWksKNAQuQ9x51VQXn8zUjOs4J8O9pPiq3MK4pf74OiuuwAKXsx/Pdh0 gWs0Uw4y3a0is06399zlz6+uV6TK7ALxIs7ITinmPOLi0WLOwqZs+pb6YAVhL42ehBeF4bFSGfkl XR/CXpPdeyPNmhE6Gpz9MJnpMAPlLEld7UixYRdUFrC3BO+YvxTCt0saqLR6oVOl5N3xIokusg5t CTu9TgKnKVJRrQHUf6r5Xk+BqNqAteSHXdbynoeZiigJ39itBfp+BoefdCWsbNyXkVK9Y7BFUXsu udVzMzb0M1nvBltl0vJ5ra2XyuhEb0QVE7jYJbBw9f02NVlG1+zITLw/2pAWhzZ/xtyY2Tu/xMEi v0IGQbxjFdW3ORKGS+8ujTYQb7ak6MUP7EpJTtrJbTqtRYlIKbS6rXARYip5WDAzOigHfKkzN5C/ BCf+4JlFmdXukHOVuWolylR57v7m1yClnsUZL/6NWg5PQ0IZuJnbzJ/wiW+uC82maB/27jynnfgn fgcKlOLM52Kil7zB2Xo2J+Zez4Qh4vFRGGnYBA5P3MUbNLS9dSlOKdK6EgI62sQ36uIFJWuswf50 +jpWV+eEKx/Nzb1ffp0IqjRR+ZKA0zT7PldfnzpC0fElZe9103e2iqb17kCvi+C2QMv5z55kmCMu DHTIveSxRMXCnGUg723hHKrhLvZYAUSEiL50Ul41V9MhDeWYjkCB0I+vRDa1+pyd7rh/yN6yxw0O cgc9YDu29ZoUyLQmvnhKuxBkJp2RcEPna/5TRSf9tQK1JnPKI8s4qYzYlp3xq7q6Zx9N6rsDiVoH 376mqS28Bt/v61umeHfTVV2HKtdXNbRDb0gt7BwzI64dupA5N/QwD9CjjljlF8JQW8jUPX4wjGCF aOtxyhrjOfvYULaweXW3EiHVzaRtHEG3cbMa0JPRZFg5X3hDhaLkYWk0Wga0GVWdYZViqWWobzt0 ifKMX+66ihOV8x635EoUCx1UKt6Ot/Hr1p5zEY/u+l5iar3kXdrP7E/x0ZRI44/xeUGsABM/pKhX pYj4WGnXHatLBCvdXZF1Ovbmw4rj/NDoutqEXIvWkERmXCqsoIbkYZ1Fw01F3hOoxRGdPuQYCHjk n3at+OlQ5cHklVVsFDsrTIYTjTDqX/2pJWXm7ZjAhJ8LxmPO4qRtSGibiGBSDDaqC/7uLzmuancZ d8kNq2AOS6NdtDZRHoGuFoKyFzIbSMG8yjqW8cmLdOfW3QCPk4N6L8HIKmFzmqa3X+W8vLpfD3Y/ B6SnXN3UMfRtn9EJU2sqE1Ek2XySy8Ihkkptp+yrmjixlXtEFf1lt2j6uu2n/XunoP1nxLQXaW+5 qMVrMBlNjQhq3qm/8WGcMCVP+E6pc69Jozn/7TG9wmyu/wGWNZnFF+/Stb1ikBKTW4JX1E8wVH9m xsTvF4oXfUfHwKAvlFbji5yfYUznU88clQNNK8p23qRnIrcPlsWNeTxX+EG/09v8ZIg7wE5APxFQ lH7klvtDJzmcx/ydscMiZQJ1gHm2ULd6w6QWOmTnMW5OaIutlaaKDHRpftmYJVhsE7GU6H7jEtir MeScLcUSeoHTluZHAjyUduC1OpdWHvbxTzua2bwyPCavPhRPlJCuoZWSxX0NImHbJRZH/nAyNXp8 khaxPEOLQWlM//M2lSo5RPQ0yQjsaIuPabGc2qnOvFSauH/sS/Zws7EUdpehDbhdeSlyMMsnpv5S fo0A03np8ySJLPorNcbt+tC+zo+cjRP5lHoqPo9XW3hXc726qeIHW1LIDhNOYZmhjB1hm8UiTnfa TcF8vwqFZnl8sDZ74ptoaDAWjXDVN84ILp/2mjN/4k2mhuUYn/r2kJ/pLWhba4UIzNtckYehawdx fcpRy6YAs4m/1TgSSXNF/cS03RVlXeuV/yReXdRMvgOaXyPJMyjwmbfsuC6aWjrCBXk3CetrwXkJ NnHvarnmcwq1Tq8VhDPX8s1SkY5g+4dVZYgCaeFOKwzLcZwv+sh9FaQ+fCZAldo9TzyHgCaPEhP9 cxBPc/w8EtRU9DX3VRbRXtuu7PRRQ5f7et8g593eSb1dHJiiDR+2abBL1VeLQpRoYqu5tCX+bWvy Nh987IPhTpWWpDnGb6SI5EuWyGeHhcZafJWzec3ywmhWTgi6Ecjdwd8wATSqMs7HaFfqGsjPn3dO H1OvdyI4Z9v7qjW8JNCWGCPsNcey5CXhsMq8mVDzmtFqCtUw62M9qtaRkkpZy1NQZLlOTDG+Mlk+ GTExOyEm1P3gkYNTFEifgvkdK6fKX+29RbFp17PajrWQpsm+JcKih5GxFZTxAZqf9WQn0cACfX2p pYY5LDMUz6RqLOjgDSwWQfTYcoAWYLRjfEt8GEZvgzh0iDbROvK1NT7GGO9F871bmJVNGeJFVwXn Gs8JanwvTRn57H22WtLyNIJEeP6XvnpuRnp0LGVG319fEnZgqqR+quaaqo8B7IhiBob96uODuMEd uu3mwTQDBXuHXUuG5TLjIpxPfNuS0lmZOquWH8XUlS/PEVCetTNjldDsLY8ubgqYC0LbeA64wtfI 5LKKpmr2q2M3sCvkE84ejEy6mn1ibCrtEZOXD6V9PnZZVPQ0/OALU65z/rlZVxAU/FBHjFRbJZes 8aGziaxqBarXY76b6JMqpRrqr3RlosofDNVOKkgXGGbMzTHnxb7+QJqKaGkh+nODkuO85cdrsKpx xg2Ahbc97r6E/5qgR48x0lDN14RNN23w0R0qARLw2OAeVPx1WkEs9+6Z0Zvc3MQGmfOpYjZ8PYXz hNohdrlsnRVZ9ro7B11JeQ2+2ryzQTdvYRMac3NC1vjKmpe4yeLWVHfL7F5FXCWcA6mRVkDK8KeX pHNmydASZrVmgsayVfHHNBWJ9e8GS50PlVj8rd/v0DXKF4wZ3uKlUK7J5dpHlAZ/afxwJziAUE2T KEE6oznyrIx8hY/sNDVLJuFDh6/3XGSNjYi1HHZ8mwVoA4V40RTm7tEVarRYppSZPAq1/WU14EzI G48kN20SQic3IsU7avoh2hLEpDzvmemgt6kuI197zUDUGfr8B0MnahZVViVDmS5eCX7jKrsz+sLE YmBdZETRZlZ26mVMTaCu/Hux5BjrAGP3R7sOKu+aeK37iJsTJyX5qJVJp0cOk69zTvreimqA9jmS r9dWj0JUImkrlF6p00AqMCTLoUTuXSSqTkkbQq9xivVAwHJcimvCJltorbCvZet0buH8wK6B4zDK h9U+XBHzmfPChJvpn+NIeEg1incj/mLajMxqWr+IDY+kxISXwySaKkaFJYfFwpj0Ob3mh8UnKtq5 Q8kvjEjVDqfNhFfVIzTbVrk+ahWZXR8xSNTGyTJ+dlb+Pm8ewfIJm3IrNA04sMcBDg5vHI9Kp49W X7MMmEwLcRZ91nj7KZSeZwubfipz5KnyrcqEkebHuiMXJytqfOgR3inkiZAiqYR9l1xyWEXiC6K0 ottF4za6Vc4UWqbHhfwa2bt2ot477/Nachv/y2e7lCC9CaVk1e1hqOEpL210aIgySWBdlurGs8mk t+MJ7R6NWTL75eioLssU/OYogrpz+Pvp68ajLuS+P+kQ/IV6tuZw2whme9ZufILRjHq0l4ha7GRm tlKhzfdqMfeq0jvy7lG55ZN7G6USYF/zxQWrq7Bpn2frVQG44jWcPZYFXHMrxfoQLUUtg4OUx20x yObiQ4q4ntFzBgvXb8s93R2rYyAe7fS7dmQxtQrC4ZioX0U/EARDaf4HLrKbuAplbmRzdHJlYW0K ZW5kb2JqCjI2NCAwIG9iaiA8PAovVHlwZSAvRm9udERlc2NyaXB0b3IKL0ZvbnROYW1lIC9KR01V VUIrQ01CWDEyCi9GbGFncyA0Ci9Gb250QkJveCBbLTUzIC0yNTEgMTEzOSA3NTBdCi9Bc2NlbnQg Njk0Ci9DYXBIZWlnaHQgNjg2Ci9EZXNjZW50IC0xOTQKL0l0YWxpY0FuZ2xlIDAKL1N0ZW1WIDEw OQovWEhlaWdodCA0NDQKL0NoYXJTZXQgKC9BL0MvSS9ML00vTi9PL1AvUS9SL1MvVC9hL2IvYy9k L2UvZi9maXZlL2ZvdXIvZy9oL2kvay9sL20vbi9vL29uZS9wL3BlcmlvZC9xdW90ZXJpZ2h0L3Iv cy9zaXgvdC90aHJlZS90d28vdS92L3kveikKL0ZvbnRGaWxlIDI2MyAwIFIKPj4gZW5kb2JqCjI2 NSAwIG9iaiA8PAovTGVuZ3RoMSAyMDM2Ci9MZW5ndGgyIDE1NDIyCi9MZW5ndGgzIDAKL0xlbmd0 aCAxNjUxNyAgICAgCi9GaWx0ZXIgL0ZsYXRlRGVjb2RlCj4+CnN0cmVhbQp42q23ZVSc3bK2i0Nw d2mcQHB3J7i7W+PuTnB3d9cQ3N1dggV3dwjuh3etvVey9vf3DBiMvqpqVt1VNbufhpxYXolW0NjW EChma+NEy0jHyAUQllFkZAAw0jEwCMGSkws7AA2czG1tRAycgFwARk5OJoAY0PDjxccvFysLFysT LDlA2NbO3cHc1MwJQCX8+Z8gdoCgNdDB3MjABiBj4GQGtP7IYWRgBVCyNTIHOrnTAQStrACK/5xw BCgCHYEOLkBjOlhGRoCxuZETwBBoam4DS/+PJAkbE1sA+7/Nxs52/+tyATo4fogCUP1L5mfAh0hj Wxsrd4Ax0ASWXtb2oxrwQ8v/H7L+b3IxZysrWQPrf9L/M6j/x21gbW7l/j8BttZ2zk5AB4CMrTHQ web/hqoB/61NBmhs7mz9f70STgZW5kaCNqZWQADDv03mjmLmbkBjeXMnIzOAiYGVI/BfdqCN8f8V 8TG5f0mgF9QUF5UTpPn3Tv/lkzcwt3FSdrf7T9Z/gv/FjH/4YzoO5m4ALYaP8TJ+BH78/O8rnf9T S9TGyNbY3MYUwMTKBjBwcDBwh/24PR/ECvBkBJjbGAPdAEC3D8H0dDa2Th9HAB8z8QaY2DrA/rNQ NtYPkf+Y/k1sAHqhP8QOoBf+QxwAepE/xAmgF/0PsTMA6MX+ECOA/usfYgLQi/8hZgC9xB9iAdBL /qEPLVJ/6EOL9B/60CLzhz60yP6hDy1y/yGODy3yf+hDi8If+tCi+Ic+tCj9oQ8tyn/oQ4vKH/rQ ovqHPrSo/aEPLer/oY87Tm/wH2L5qGfg+HEFzR0t/4zuo5CB058TH+cN/9CHXkMHAyNLoJMV0OSv KOb/2P/9lvqP46N5o/8Q60cyI1urj7fmfySw/GOxtv4jipHhY0LGf+FHSeCfDB+tAv+rAiPDRxcm f/Aj3OQvZPkHzf/wP8F/kJX5H3T5k5/xH4PVH/8/4bbODn9V+wgw/Qs/8pv96eZjLWbudmZAm78i Pmx/1Wf4aMDiL/xYiOVf+DEgq7/wY3rWf7X2MZk/mVk/jtqY2/yl/Z/ebf+I+Ths+1/uj2bs/rg/ ktkZOABt/muRLIz/Y/3vNTJ/1LIDOhgBbf4KZfuXzdz2z7JYPoZjZ+Xs+FfND4v9n9vwocDe2dYJ aGxo9V9lmVn+OP5PZc7/8fy3mfGfxf61FsaPKf8py/pxyBFobf7fd431nxigy1/LYf1I4vjxSfYf /R9tOloZOJr9lfijyz9lWT/G42TmAPzrQn6M0cnV9q8DHzmc/8KPjbr8hR/KXP+6jR+n3f7Cj/Tu f+HHuDz+iPvI5AF0+Hep//cTXUjI1s2TlulD4ccfhn/eRpwATjZO7/+KNHJ2+Nit078emB8Phv9l E/OPxwgQ6AY0gl36ZWvEHWiR0hhc5iNa8LMckhpUyLQpVraue7YDLmAxDtSqeFTKnnq9Vv3pezoa 4j7kPpHrC55jeLuXwoTYhZ99bOr8276L/n66Rwue+u90Gfc9O5L7gBOktsa5m1NWULmZ9bGyRI3C gazLwZM8eSoR5QPoVWKQHi2X+p6MQDZ2dbF0K5WQoFoKZmJF5FT7slCWkDVX5MR4iLWpAB+LEJhm mpUr23Zn1KcCmNyEN+17jBgUo3YiZsVtanTFA/7T0sIQZKSa9/7hKoEMgKmSA2AfchlGcVQiIBst uCrLA1dUb/oSa1I0VMbl4ktLuzrxKzmbznrxrh4zjZ5ZoeRiEcNlfIFtRRTlI4zH2zEg+YEzv10q wZds89uFF1KCU16UqvZnTUhihBYLUizNgfSMn+gejIg3mSq4gj6wJHb8ie+ezgLpOoLexY6w5jvI TxZCn1985AzhkPoHeeSPsrGyGwilpfoVsRzoCaMFrraEot3pqja1NeVnIxVRZF5mZJTBvLrIUddQ bCGM1gUUS34oNQrm+/jt+iW6BU6ymuBJYPDnZcNSB8N7GqgE2zPw7ldClSLKiiJiQbm47LfVU6eT VbTzVY96enC/lcqdcY4/Wytr1bb3Z+tiphhDf89KVLGau4Qhu1DLMANpXOWqCoTjH/SncmCL5hZy WoMaZauKMRLrwRMechgno+cm/iK1ABpln1cinZ54BpJQ9AxUu9l0Rv5atQBIPS0Aba40Q0FKZU/e 87uCQpdQ2NByhmDKZ3gtaHDW5Gg4SKH+3kMKlYub9vKAnWXfvHKTJN96nHnV4tU1NJ4sET2eEIGL hdxoB/Q+Ii3WWAlRQ/dEhxWHcqQ62Hns88YOrQ2MFQYVhd9sxzg/BtmNnDAKvX7hvlhc6gcB1QIi 0StZg6tS1LzDmi8wDeUFWBtpM3RbnglTOtp93mtVZ2g5DBcg62OymLmW+9rwlbM+lPyHSdr9NNax tOSpiECXdTlI2vorkyFrsraRsTuxf8Rv89NhDxr8yB9Wbo17BtXQKZ00Q6NM9UoCzncSeEca03es Ynz2ptmKvnKitq5S1A9v14uD3PQRaW9Ijq0idVMYxWhfCQuG8ibcePnqiSQn9wDOGRbSIibbi4j3 Q8GWP6D2NiBYZgahX/xHTuYWY+l2YV2w+iorxrwmQRizoFzLrZs2yeEUYmOSzV07IqOgXztufqqL yHp7x7lFHad5dUKKxtKZ4kh5FkzA3Si/FMOlA/gsGyhm5huYCLeiZnJrdJXam3c2kU3rEGfWvrRU WzOSlLALK0HO0R4NNqLHW76KbCBPi4CdnL3DoUvhZ8zQOrorGr4dvzEOlxD3zlnkwiOb4ZWlIHy6 OpbLU7VM3iYOlhTNl1w+NbrDz5kOcJnNRlrbeZZrX7PwNIEKT5vFv5Ve2CAxXI4bH6IKGy2mIbAl VhmPToT9wro4wTekRIEdTcuAHHuN24DEUOE60y/aes/EHCZgJWKMx+XQazlRKCQvA25FUtCKa773 4FMIIo/LzcS4a5tcwWWFKClnS7xZ23mhtIl5LWMHzko0Tcam+IlikIk4EJk1/fEd01V+dhKhgjuu DrlfTYAOsg/zBoTMKpKjJXIYHMkeWar/CRKy4aLwdiBbLt+Lzx3BPDiW2VB5YUdEYT++krRL77mi 45qPnDVjpvog18wETDVi2Inkmix4TN7Vyqf84KrLrZZqlElZAUqJ18isMFVb77Yw/AJz67v9wuQX E4nfU1JU7nNPECScDRCPoTPPh17cQ4F7WtE7tngNF+iv6myjItFo2Q9vJIT+3lAwxS2IMGM3kgwm 6Tfb8PPdw5DYTVVyvbfmEL2BOb6QHdnynxuHssh3ZLGxLChVRqmCUqbHsRcxUI74DyMSl8dMr1EL U203ltAwJWeobgFEm3TFA+/8lngL8c9pftnkYZ4vHoo+aa/4KEbTcAEdBgtjyV9ki31CfVuD1gtq 88wjLcKMQnfG8rhOKKPAWGV0BM5ESy0rbYk5oI6KUp/j3+liJCLKKH6uRmN6Mq3Ve2vaE38Z5Ntu RWOq5REX5r6PJNnLled0RhtqKVOuhQH9cci+6qC7xyG6XJql0T9O9jgsAeu95gazt4OlMmkbpjai 1xhK2vIo0joejc3ghXw0bzL9q7CzNJ9hr+/sW0sHEjXDdWasHkogVyZ3CD9AHkxnJuUO11ukKMKo JxKzv2N9pYTT/Qd+by/Klq7QXRXXm5SZVXauemMBQ1VaG5QjM3+37C/tG62qgxjstA03+t7NHlhR Q0qAst7RpkyfHf+DYVoWYMKyPUzk/oKwVPYwPZj/YiaTzmAoX6ScXLoJHGfA17P/4BTP5+f2Zuez 5/diYX1zOKb1nCWMqEqcdlXIShCoYvS5nQVwYruI3PRbVxnZO7ouq41pF0UmC8vXs97U9vLqWrBP Vc1flnbLjTq1f6CrlGcN/MJCMveBCR+zLd8R8uSi2Fz8uSVhNuI4ihAxgiTkVtNRbfqdhco+4zip NDphmuVTfi61T7crz5LcHBt5GRyxIA0LvkYITgBrMjpMhmJ8b1smtqQef1xIaricCeUg/1EXKmqZ DLbeIfh+C1CUbM/8Ry3p4fq3bJEVdwJ8sartjiA6Jf+65MgWF5prDw5DCw4dPfBfmbE1qdnVaVbn iPge12s4kbewgyl14jldKDm98ULHmrZgTRDYzGDeTD7NZZVHVGaEd5T55YuEZn595kvdOVVTGyQD EJhe8/3BmXhoed0K6MP813D1XQ5bv5oltHvE4IotO2yiDtQxHuaQGxY8KH6QNOty9K1z/AIBqG4k JiXI//I4HcMuJ3to5P0VmoCrzWmjMKpaDZ6PaSVwwj9xvHwx70jGNWdx9GT6YNmO6b1eA5MfUWtQ dEHHK/3Te5UguWW67oKFy4xVnvSWth0GljVPOvZkJBXWSBXAE3fE23OGYe+ncCTaQMBJ+wYrPm77 6lI+QSkHK10u8oNy3XGjoWd5lfFp2H9JVbmfNYHApnVtB4tpBtABohwxQuT0RNI3yDBoFeu5Inn4 7XtWGoG6VSeDrpLtvY5dFhlkhoNhoSvGxOTGp3bYpUrLUzCcGjR1RnzpUvZCGZhVk/QApSsb4zY+ +/O4Hqrs6Et2ZCoaQywv/E7I/roeI2euW++YlYRsENxuGTu4LFV6VyaoyV6imks6TPHj8i0/dNsi EoaSJS9+169TXticSXL2vokLc3UtgzYZn8uvzF89oCXLE+ja1x/Io5+z0HOjVA3LCq9b8zocjWSs +ccDnHN9AsR1kvjMu+xFf9SyKXFJYmYSYd+cffsCtEW1MqdS8GXUR2LUf1Rce1IsySSQAOegpptI L/POXRy0K9YcKbiu5V9iVFmR8sXhe5GSgsnoNTYf3tBN89MzAvH59mn8hgVyQ8bZiLsDNo9hmJ9A Q+koGG1ElwEV9OdBdIfw4EbxzBJdjfoQH0RV1p7tOH9LsF6BKoHbPjeZ9jfRxWTPQWWb7LTDd5jh W5RalM9MfQQBk5GocG9hxEfu3CrwSTmSGwjM8eM/FwJFgvvcVHujpe1BZZ01zeLumCsJVkW9eQqf HuI1yTh5TzZnmXM2syXobDLikN3fNVxS4iQXIblwFGb7+OWXa34JHMEkJ0sPqeR1RjYfwzZ75gp9 OXI0PzQiGAG5ne8qYafg9nFdbUIrPq8TsKD/EsyXB9bqOCeld+8kJIK4HobaEPZMrsnTm1u1Sk7T kapdu97Y8cQDtXCDoWs2BPoEoZXLqjc8KKuaK2SGrJZxzImyGkemsXl4L6SyVMRXIJA5gr2J4vze bPK43OpKjLbRbwvLisefDSNy7Lq9WftO3Ph77PNDmRLDUI60wjJyKn3clWqGo3dPrSFdTjnLiL+s uTQK6aMhs3yTDKTWvY0Npi5R5HO66tehuglsns4J4XrL3ScJHJ8aKxXuKZIqg5J0uZy88sB5YVc3 OZzAhwUZ44jrocr+b8WUZFV8fUxHeFYN2hEhiew0axGL0flamY7QPEp6sAxzLImRpCOaNWP8Jlya Tq3TomXg2kQh3hWvqATrSUPZ4oTL0C+6b1y5xx7fmNLpEmlsLUt8lnkLC69G6w8uReNiOiGLBqi+ 4ccWY7EK8Z8rXfm328YY5BgLWCWI4UknNgYfoR4E7nCdDFDtksKqxNjQa5lVQq8SuZw3geUyrEeO Whb05TrHw2OxpvPImX1/KHZKzrnQ6U3whiOLp3TIlo3+saPTxCLrpc5VwTfDhrl7jlzAtlOXEtmd ReNhDhLBu7n1XOJ/odu1fqI/Dpo/rWAnrNPT7WuCqeIEER4Z09WXwNbiAf5lzwd1y6sZRWRiSyYl FANctzPlm1pCCVkQSLQrl0LOnmI573QMY7lspsFXy0S2YhFYp5HcbzPxlYnoAe2XwPqkembnqZ9s /c2cwm9ljeVFys9R2iOppVe5+lc3oyplGkwCHYErLcAYQIWMcFohlR76KSUhK12OwSPebIJgBvlR wJYJa7J9MQnM92FdaYX1OYHLF/YrDyDGcpcWoyU+5+xIxjD65tO6ndGgvrMBUaCeAr6aDnrhgy6T H0oGk3g0XX2+gauYi9XNUmBB0ruB03jZwi9Rs1ayqf3fylO047uJNvcXoF3tdCTaKuDuuD9ReCoJ +Vl+cYeCSPqhbBD1erNA1YQElY//rmM2YTDaHWkk+gn60zHTDsNQjcw4KqQuyXKljWDnYKEBJWTb CmvyqOYFW1kKeO+9DNHRxlBYf5u4T1wbmFqP8Cwaj6On+sXUbFMGidosQcjuy4DOcDeh/5j2mN6C u8OIcuaSLLMm09ELbdJqJoFV6Mh+soEGNzWDWngvD8sv1SZn8r78TaupwFl3fVJyTyf04qiYjdik WtswaT9oOWq9Y6jW5t5Py4x3MUmL3xvtj7UoQrsTFYOGErUwL9g4GBbWy9PXX1VYs354bVlHFguM WvcAQS5c6eXvE28Xl8SayY02aj24yKDFPrsuAQsrIVnAzxjdltlhVh4kyF7vuVTJYivR1MA0WpGz pQyjhp8WFoPpE6plq7RGtHNBP19/yZSg4aWTxxMNeBWF7/WRdmJxkL6PQ0cMzcMk89W/HLhy8317 6XKFSQVKOOexGZt61RDMumx5bRRDBUg2TPLV2x0BnqOyfIaOJPWDUs6JLd55Vfj1zdfWrm7Gpbot ypKyb+0Brjowqg+7sf5dQT93Qleotf1zJ9Kny0DvHDkfBbgZaIr1Gxsi1dJ2dSi7nh4Qdc8ru+9P 01fKsCTwbUJQ++E+V2vdBuNdEt6eVx0TwotHegqnec3kzr6YpB+VMlUwMo85tcYS8Xds1wywh9zk Tmb5XOXH9vYqezj7jpfrXzCn9MqF3xzcC3tIbfSwOaO+zRUThPK6NnFKU7Oe0J4tOe7N3o8ry0+E GeEo9z/zJXsfO9o3WbbpaLOXKxwHVYZOkRKxt8XnhNsBLPX4ZbgAgjWX7vYZuw0CGaLVn9xPJfY3 GaAzWN/vzUBUEAgicleMk0vTkhIwMWmZX+OeXgm5tAqQ7Q/l472aLx6/myAzUL5Ptr79OJnpeo1P yLMGxjPs0/M2ihfq/FA1nHM8ITVRAFkvg6+9romSoFJ5VfL/eFRQogRfPXWcfPK9dlullVGcmqgK +9I9s+EmQ0aTINzzKek0Oqi6l58lwUb+wlddPHYRO4DetIjf6dslVgSazYiBnG2orgrK9r6jlfaS EbaswRRtNZ+zhhjJVODDfEqEFwzxUFITi6LJQpbmHP2u7xvuaELCPujJi2+ZqFHeTbPD5U89ZtIv K9gKI2e5ZLaFxSzhkCXmzWHyXqixiSXa+IVwiW52SBbM+rem1RRqNCcVlDrKh81DJFmSnUTqXAcK cRXMKIbZHhcWGZ/cI/rG0y/kSiBaW0NUq8kT+fB1awtTu9kDfyHcMDwnGYH2C56ISFk4a0J33Z4o XXd7HqFr0kTfMof/zruXyfTjenj2bahqK9xM8KMIZuMI50LxjNL1H1BaLasORB2Z8EOb0BrW/fJ9 b6cair5Vh7VjBMfm9wKdKOupwSgLQiPsy5hsQdpDgBK+A6zgUa4/ABMMxDQMv0w7SuJBG3PacLvh rklsy+1JD9MDxjNUe/TxhvezxcB+AFO8WTkCyR3ST0U/t32SNBOQQWmkVXddcu/i2FsrjWtG1Qz7 4e6v87mC4PHDLfwbotP48G+pjCJt2SJJlFuasdZK15ZHD+EhwcSe9SRk7D5ArYyIGUl+O8QgZ4AF AOv8yVnhoUCUKi0031st3kEA+23EyV5QpcXGoHPiXFiE7xNBE2QxXmNYd2A/u2rO9xZwGKmHBQY9 ekSyHVK9+NVdkVUZ+DgRb2JcfRfhg+obmDxEUIZNHm52wkUvMYEy9rX8HHxRLOPSUOHRFzNI0t9t kjRKyebs3QxdM/Jt1ND1ay9KnBXlpii0i042uBJSXk4k7UQLc66N/BOwJH7P5u7oSZdMvb2rdx1M dlSz/KciLy90XviN9lC/dO7cIzr7IWJ2vkTtVvQiLfwK+v1F+i43bSLoshxhQie8IQA+IiLeaWZL ZVCGUfzVZQPyHUyNKFjPu02CyRt7oDNPYz1FE5RW7QCGKsWQn1r3mjA/yDkjgvuHLcHKRNRv7SZm PopJzQSbkTKXs12okTDK7Or5C+K4J7ZD1ObYBvzJVQ+MtQgGyjsvhCKUx/LZcaGRPuSX38fXAi04 JWUhVhR69tkVO8enjNxZ8oLiot1RDIF7tk5aLO2zyMAa4fff9ExVFhXzzsG/MsaJSH55Xx+r0ooW Pi9baDPZ9HDzPjpHy2STDPr0ldnlROBXolwSia6aMIfBTps3MF+V5QqQIs2xDbg7KqZO7VtHZjD1 JqB8D9aTBTbfrW0TqeLJ90a1j0up+xL5mx25M/p/h+K0EptKGQ9A82IN9ptkDJMxmA2i/gVynSK1 UkQy4kkRCG2P41c07qts0a5G8ObsqfrLY/Ks7TtuX+rbjrs76XLk1QvcANcCgTl4VdqrxLgnXLfW dL+OFGSeXokZYbIkm4axJsOzcOKkpDmVowkam8qTBB1FRMPJiwHNF9GOvWPqMu+50pFmicDBsZyA tUhh9bMiO3LZAHsQZVitiyr/49fJGnEYjJ5+cbE+FtPMuECuC3x3kXjW5Srog4l1uOcRCt1c9mAG pqGUZmIXnrSj/MMy49uvawiQuncUPrhlRKe9mCiAsr5HCIJHCNVgWA9UKNrhjvVUN2L8lBOSomLZ RUhichYOigGCjDb4oiNK07fAiHPcCi0ic6Imb4XkCjc8AxIPPv1JkSAcMR1XnOVA2UhSyyahnhTh bu7Pc9bju4iuUNGuA8EBv9RwcQd1+aKSfydg4EafioDpMnTo9NW15CFHtknoMi9r+K/1b3SdoCxv y179Si3ZttJAJNXxdu/klzmUFXVIfIt4ZosH3YthvhtbrS7zLDOp/br1TSWEWY29paV3xV3cRwmv r5BsBH3sIRpsc6vncnTKBnrsc0ym8pZSKClmNLz/1OY9qqQ73gWJhaWFcrCEGjynWw4BmsOIr+vi 4Mg6+JU9k7YZTgQm+SIpl2nHUjUdLCryuETbiweOD9KpfLuX81LxZoP2j91ut0+nZ9JU7gUlq1a4 cyyy5tojUVUn/gzjkQmDUPCmB8YrHqXkhecgAcYnccZkRbmZYZEGDk5nrfaDnzFgpP1z88jVFiCu NnyTcvgG1sXoGIFXX8hcDcGcNjkolGyclKsDPz2GO1+A1gShFk/IPkUdhywegyedug2HQRN5v2MI Yc1G90a9aDN6XNIwH05s2UPq6gOQ1r5GcyReN2sKWSIcEEkpWFJ3okc8bpFJebSolOa3NDcRsQVq aXoKL546LDvcMN8xJnvptpkxl8grAaXIxbH8z+zPAOPLyo0czlxmEKJLUi6mICFhL0ymeTbffTza kKm3k0rl1GF0n4brGxDO0+olBNAEw/ktYwtjVlJRAef0V/q1FbW0pCEp1hQPuaYagTYBA45phsJB KLcSb41CHZyOFl/AvQvt2xmo6SDkoAHv4kT78y/yRgy5K4lqQijfsyDvArU9mEfrJpWjFQKY16pS PT3Ew3zT77avD30mU8wOCIyKUUrwP5Go+nZyCzwcPg5GCLLoJdrcODWtxh5q+R7qEYARMoE0XNUb T5K8j+EH7aRx1wLSfFO0U6D8TzsdDLlJYUgqSkTReJlBk8cFHUf9xOmgd1d2masINsLjvX/b7Sit NkJFyhhWOXiK2C12T6b+2MrZFA4nU4WydeHeBcMNW9M5Ziz67C9uSbgifZ0oPWVTei3ok1RvmbwV ztDzSQBx37F6Luwpvf90a4hWxxuUsU2cRBeF6hRbywXal6hklVZbOpHc0PrLr06Peq6ToKA4CWmn roohTfzZRYq+WPMg39AIcgqN+YMEYxWQXA80+XqDGoOeDKr4qGpMp2JU9O9neTcO6UY4l6ep9vV8 NxEo0wskvWymooCg2Prs5Xx7Lz/7YW7qpMfT2UlOgbiF+t1SeL6g+HZHkYeX13kU/S5w+6K9CZcx sOwebVq4/GwPqp01Ma746MgJi/EK4FvdYJ5cdQMnt95n2tEeSjXBAKcinLJXMdaHG2slkeQ13L31 T6Z+nLmyKl9s4ys3U1CmT1gD4dsVe4Fuk7yMZrwID+89FdzqwuwI5mnnl0bMlhwlJWXYQr/4d6ep gkFpM5ESG9jJbuxXLLWiUn6+g3YRguA+lUdrg0lvemH5S/naslHbrpy2d6XgsSQhkjgIfTcvXvh6 MYHiulAPOwpeNYvnFGN044EYsRRFXXSaa7xVO1qYFSghRzdGiLF/iXaaZvGUslp72P0rqlKDPlkG qa5pVm+RDcJ4a//xFLKhLgy+dGED/dpegqCehC2Xan5ZyaqHlxkaet8vls+VxlxO1zimrDIsAiQw zu+npHXnNn2YQCeLOzlxBal9aIyfg1mx3VOxSJfS4r4Wxu1cdMV3pC+yNSzoF6l94bkja/MxA1Dn tMhdhktvwhrTxg/xUbt0I+pJC3NBZdA1s3DYAWxS+ERNC0c5BxlGzHfQmFqn2h5j7Um/xFXwAsz1 w7Rgwp9iF9j2MlVAguJy4Z97wNnALbf3wss4xn8a5nityHwTS+Xs446NWyMHlVsIw68dfRCpVo4j ikxOtBmTmBieLgHjMGjalkRPnRNK6EmFKI+Oc9h/4Mv4JKajKap3rDn80+s4Bv02fSEp1bAKtu1n N4uhLiWNOkgCGeBU/eiUmUCJ353XR6LJ5ShQJmbZL9GgStvHhmOmvfW9RMU1Fg65/gdIpNELRcz4 fJpaZJGGbocZjZnPSq2OeXM0cuuvI3VDjHaQnSYBAn/kNMrBQ1hTDHMXLucEk/FUYxJ4z0ZBvl3e yaVfmvqPSv6zhjvEg7Jh2XvZ3Yw0K3Sb3x1N4zNH3r3KyKrN7ZyzvUNdBgG2KSur34KIV/oc33Qt Tqys+wteR9uyNvCQ0XJVpFTb6vAHKqlU7tY+HauHe39JKuaCPVOWC08bylgzdztHrD0TF/RgQFtu WhszIUlT7249oaUnM7c0Ct7PewkIiz6WNapTusqhsXGOLiC3fZKLwl1CMt0yHkTfJc0pJsY6Mfvs 5377I/8cywCD6rbP8gpmDJMlzuustJgcMOrxUkv+1Js9v16nLT6T92OPkF1//3cE8jVEpbZPUKf8 aO2FTwmSaOLOKIzf6ytr+jkUOO5pB3mJAiCQc98qOlHrXLWfXefE3PuXUpH94UMoj31pIKan8dgW wNDLkCZuMhQPmlI71QHLDLG5pJBIZP5E6Vm5VAx0uJXw2s6ka6bzTOqgLwLY27LuRwQKgkmTM5G4 UcRWfcyDAyvOaSJFgYeNVOHZrVLeEAkO6KBYQKUMwU52Q+QBm4ZKJICbzXDFHDp++RGlU08GEcJ4 G5gIs7J5HYGgVGRg7CxWVQjrAqUYtYJNdieWfwF3C9qIBKxcXK8Fw2R63wroPzA+LVxlKheUW5s1 emXMAkUsenDwJF7n+2pwnG38+8pHEFaatKereFK8VIYt9X62fbEQG+R1ZdI31kZghRjMpVMzhC3V m30p4boVflC/7hPY7iRIKKRx4Z48Y9nrsxVTVwpLJDRNJeJOXd1+C9p5031LGAYm1BuMNFvQocud VJeGy9j0ZUsGhUqCGeQpZAye/Izc3FrAO7yBdcMqlTT/CRJa5CbKuYx6LlV/bcY+fzCfqik/bS15 rZdcttIi44I2dZIHF4cFLB61ST8no7Jf493BNYrXgEDZV+KEDDMraOwLvPbsNF5gopUNZtPCsziu 94pttSkelWpkSn70XdyAWfTsF1vI+cpPK8xB+69Lkj8OSjdT2y0lciQ6Pc7JDzJjE3KmYmMmeNi8 LKckVV1imx5UYr7pZtMi01fmN/5gHQRBpBSMSwg4I715l0anqQr+6hUgEX0Gr4TyQGaHzqmrnNzN KZZlsyIgDm75roK5iZNChpF2bWvNHpPhFbwYuYFIylEZp6Q2HI1o6sIxTGWURHpR1EeJKjnrS5KR x1dhjOZA0X4nl1xtllvOl2tYXGtKvz3xSvLQ912Snkg1sNsV9h4CR5WWkj0wL5W7j6XokGlXn5jn KccvGSPfritXowxfBU2Q7+orGo/6gpu+oxVm0gC4wuSSqSOuQOo3B9TORx1/6KRh7T1MQYsRY3rV pgbF2f0WKnlxLoC8bFgl5H6R3YVrTBqOKfRmgwhrTZY5xz656aKlABFGnBVUCwLUZbFpux/wbuIN FvNwfq7ZjGUQ8wr5uUjhG6usuUmbu7shH/Ad96l7qOh8/QfvAvygOnWjtLdw0GRnA78FJhQcQNzR zDc96H0y6lOOCU64TtXO2YP4YPwl2lw3nSnG9wkBnFv40Ma0PQ7noYdIqPh5XWGppgSZH3C3SBep z/QV0goI8uPLTRwoJ1+7m+bo197NibcmGUIq04kUJRB0lw+h2iSn9q8K7hxKT9MWHmjfTJ+di7/3 47b/9B1BiAS7zvn2DP3MKM2L4oYZDy0mz2N4XM3p9RMK8xIG4IabYTRBK/4bEKHnnIxKnpD6fjTF fqkNIYR7B0PVukEiO+y0cWZiPxT4qWwQo6HPMH1txBJlOaBTv2Cs2KjmPMSlrfFUMVyPxNXAfmHS PUsxgL1BlIE40tWpGo2DV264iaN5xTT7rYU4uvS+PthPkn/CVESEfTiH0vPt3LWYRMXqctXt/fTH K3yOruE5CZ/xstldDWwU3QokdIaa3z7RV3/xMss2NhVUFz0mBMVot+DgvljqLM6eb4XsNJacIiqU RHmuecRe2mOmiE+pp3Jg2zW/NHgNviarHodL3llo8yVrfC2Zh3Bh2ohAK0IIridHQK9PN5OkBxlV OHs3Zyjz2nuxYKGvrNx+ogg1Llzz1PLmwKAnPKjkEDafEbeHma3L0Pjt++4neTEvBaLYwhArZjpA qwDKFaO2sOurAE1HQ75e/zmlAJIQevsEjbrd8kG9IF5nA4ShWJW1TVL6W60T/ssGxBesdkyQSNva Ude1/kFdL/dOXE3GtfgKC/aMU91ZYiftIB8xLHb60OdNvQXXzs/7qkVkEsJkeGcGVHMWLqN2ih51 dtlgQHlu9arqsfQDl7I4JlvkkA4dX+IO1IL189gDPg5iEeUgIUGfchAQU2OzWKIDOzVQndsg3Lp7 5x4aacflWalhxvsfjZgRk0a86ccqLlvsA1OdnPN2N5HTjzodIcONvFW3Q6UcbaeR4F425NCSTofh yOW079GfzraFzIyy7PmjM9XO8CsZEuba0zdLrJZq2hsf94o//15TcgrFFa64ZIofh9fU8CuFgO/t XalmMS5G3hAdNveKArWvvmN0/YbzBsNEQt3Q6FDE5LlymBoH2zsK3zwW/RjYh+HFfyDaaR0nUiF+ uHoMhRcbkBzhEywAm4Zf6eeW5vItZ0cIo6lSGe9moHt185M2D14O7peBSGJ7qod8pkiFDC+NPQLt kGRWu99tEiHw6G0p33/umk25iYZsR1S4zj4Lg6HijWDfK4/K/8yOdwpkYvFQbguQ84HzlPOdLsGP oFPFZ6A/nyyCe5iRtEHFzHSGf7vY3Y2hk7w1B5wGX+OybXjzfs61vZjBnT6vVVltCxIKdi+Q7ezH ZhRAeXSguq6avpTO940dCcchYO0z5Gv4CaRCy3i0Svn66c5s/ILrc4/nbk+gyMFdq1GEhnwcqjUm T1QbTLZi23hK3/wpS46utk/pOWzP2dsb8yshMcgJLlSKy8xgdZ2TjO40W7tvLeurBzrrDEMIC+zq aZBgx9U3FwI8HMwUkYhvbjZ+V9+mFIKMUQrzaPV5v0CTetsZGCWZrr1lCQpwXTxkM2+40/60faAs E8IMZFBOlk8DUURhRdPMKxt3mk4vvi+bEH8qvyyUCUSusONj/MKTqhP7mIou/c6TadzM2fB+do/V j4TFRWQPteZ1TcrTuOMOoNQ/In5zkZM4N9R7DqGM6R/9YXOAc+JPjO3mZtejW3bjXJyLqliMplQV QTPhLihIepvsMT4PQbyn+Omr4Hnds+D54/jhCUAiNDeXpj+Zw+O3Cd640MYWvvQXF/sChZsDVnDC UwYeJJeCEX9lAV/EH/OF6L8334NvTCCsOTFcrN/hYLB7Z2xSPPR/8GV3iPj6tlyg8pEP7iQFuU/m i8F3k1bkSrpy3yDj8QQj4OL9/EpZb0tNLLM/gVQuBvz2dMsKmbXLbN5l8ztv6YiiVSVKS7fve3Zt IRaqpxqh7KVsjllcW4HBIJfwL94mdfJMPg6g7tnvcCqwbzmmXrwwxTEQdKpB1MWRhTPcMKcSgiPv EjYs1vJo2NUxHotBTrmM9dDzxloPSR5jWisv9j/L+EpXVjDmTgyDm8pNa4M9Vj8jljeVrOqUV6QR CycdZ5OkUWoZ92XWFaeDCOr69WZ5zFS7XGNGjeVGRvekww+KFE5/sjBpcV98cmtcfasTvf4q7tiu lTKF2OBZ5xrn9zBGqGj+xc9hfGUfRhe5/5v8V3A+FweineBSF9oQEJk+2E2cgU0Xrp/eshvyEGAm 4i1WVV29kk3HyXsEq2VD9kTLD88NaFphvVP61Wuzp01gCG2/VSCuW+TJmY6aaG9UJzZL+irdEYj9 meQhuE9Jd3v5VQ3HBuisTG8t6WrdA+qfBSW/9kmH25Cpac+bro3EJjJGW0GNP/FszqUMfoF5wTF+ CHitw/Pc7EkEq51Ql305NwJxNG7rKdPPMtPLhMT65diAUQG9wMNNjfBzz6sDX/ycIyomAIoDIXzZ L7iYsU55skgXzuLX74ujnNXm4+UGsQDEmEmENpCIM6RH6f3y1lQ2Zd7s7cv8AZNPZkpIzXEsu0B5 KBpN0J3i2agaTfWblORDzdlryFrvAD4S9IzcY2mXYhfQT7bSENl9y2FbCKZIJ4MOsZWZTyENbI7a V9GqFvW7nFQBbs2yS7i4HdR9nPFh670ZRgNauAa4wpeqMmDQ4FJ1ZMUkhY2EfEquofj3zMQYT0Sb xDKZraI6FwnGjxdI5SWCNXe1ZsJWYgPAPKQMPrtkpVzkylorX9IlHPmYeEoJRCRnCkT9OeFH+7f1 JTV+XBrhu1oNTqofI3N6/TOA0OEpD9v61dz3joLULApmabqFTFfYUeOHRTgLROTUDqVIf+ziO5zC /HzQBX4R87dKdkxIexxFYiry0Z71K2twWrqFQmH+F+knvVti5g3EWiMQ5PvC2gg3gSpQ+LzkAjLK OPpKFaUQuA278s14nTv8pRp9PdZM9WjT2EIQqmEeaeJhTcTunJ2uZXJhlVdT/AFJnyoRKB6sSKKv d4ARVXI3Hx1PlB2svLtcYxizyq7UuB0ZaYyHT2W07bwGP0FHF1jwoVFUZvNhafDBnjBdRTBPujh/ nMBmpX33X22vj8Q6OF6rXtIseN9eI5FmrcZURdrorwuaFAzSi1HpK3c6rjih0g610xXRzUDG4TmA j7Axvu5vy+wEheAAh0E8qo+P3x+20UN90qBnaJDkIT2QWBZO7vOKUXLi22kblR/p9XDn1/HPMa1F 2rw6fu2sdPIyLmJJZ6x4arfIjpdOIbfeEaFCv49Yt6WbmVmlH5aazvLJKL5sptkssj7Ru/MIZJHY sgnGtwvDTYba7zpwnMqtWlq3QfCNjb5+Q9AKDQa9VeiwyLGuNpodLWylrGr3q06iaDHQ55Tkd2mv figoejb8smVm84i5xCROA2c+uvgAIuUqQk3NFLgmsikIZjFD7fBZtaKw55PeJl1n0wIdDGk1MvZy E0nFAqo1k4ao8XFioZEfWc4PBp5+lq+hhgh2r2e55FkkFS2lHlBOif0bWdPrWSTNu44ylGUsEWZ7 3RHuZvUFlU6N9glYNNaVW8KuE3xXbjJSqqfJBKRtXRHDG2BgBiuObOI8OPJyQrKfbXifb/tZrRwT WrnrexV9bZALlq608Q9KHpd9M0LG2QFTLP1EtMdNaHPHZScDmiLEVnf1pJEhetRDo2xjSr1wc6rg AGzobHSHt7DL2Ni5Hm68lKwrIW1kRWmoFTEOv8aX4u5NoghU9NJClT3lkdEAdzSv7Np+fZK4nta7 qjjm4vq1s/xODnVUvOTsMho/r5XNrwQJBa0PP4+FhXHkpzEl2ooizoYWf8DMeOg5jxAJ6oEOdupN qo9gdS5NVnRoFnOsTMqdRSw4O+rUQ+Vh0p69WsIhLuXGnXJhDzq73lZnnrUa25VDtmmSoexoZg4I oSLyR1iudbyrgs7b6cK3QyoaPz3zdLPwPHbhw+MVAx8gFcwbmgQ/m1SDewegdT22TMH0tt64CVMK /NYE17on6rqVhO8fvcbHJWVFmpWfoPgmj63BqOplAc0zeq61bAbNlGLf4Q9mJ2d6jW2DUfyZfKtH /jewWArDZnJIggWPyR2f6yql5pze9wRH4DbtQd1vdjykpwK3D2w69+UzqgtmL6bgyXeX+95yFreh WZG3xrQzI6yEBbOwK5le35ZAlQL1ES7wc6wws7tg70panMhJFNHWrfg9yJWlW1c4hKLH4rpJq8Jy dlknIa7hFmvaBLAMU1w7nd52OZOfkcpUmUsFWgFezn7kCAwrwnrThrwQJTUaWUMzlJnH6m+Z0hWx JWlvq2PJXlO8DLqzrOw1BhNQTXY4bSFffkum8NlZ6IlGrK/cXG2t80RAcmgt+iG6vUWR7eFcc907 YM37/8gC+TXlcATgJS6Cx3EKvWbsPnDsSi/8gd2xaAExpR17nTAycPf2tXyd7Dc0+ZxBczgrHPLC VYwTq91JIOYLdW9cwUZABN3zNhQiope3z9NvKushyZprm0BBQfB3fWdQoySFCRwLQ2mo787fdzrp zlOs6BRVk7ZgLcnmj7BqZUxjJYIQJ9FVhDty2LqtNmVQvgaH8IajYje7MRASR/vBqbTYtNIkfHxz pjuEyCc4Sxv2KqL1NJqv0+Lj3xeQDzXDJ232SiY0wJ+NwX8sxGkrpVBHSAKVRSdkin6PoLJuXT2B fYp+wVDWtl7/ysfvwSKtSH/mqzH2ffSEp50GyrAuUodu6sReKNStDcGE6o7aXGyMY+mY+hVl4u1Y v0OUHEU5xMUHq7bhou2AeM+Cmlq3eaUuq4UMrAlAFS0Ikurzcws8jPyXcrjNYxKt5WhkJmD7SZXg tRXVy3hhFPJyPPUVeuyG1eeW8RkFHsIrlf4NAeMN3lu/bXkdFXzzIZHBBmtDuvYruqFryUYnrAq9 4D4FNPqXKOynC/pn+nIVUGZI0NkNnbqWIVtbVaLH0IFj62Yw+MtA02DresfFLXsib4m4JBWceJf6 bxK/qLLBucA509Y14wqC7le5FaEs5HR/E/MxnG3CkYSrppIRANlgN42O786Vv4yyaqBhVwLJWsIa UuPp3lt3wItbKvVqUDYeMGpumJOZ+kscfBRDOPTn+D/+Bzwz3K+oqiE+prpwe+EU26NBK7b0RVdo t6IuPToXZXX2TnUFicDTbZN3HoWl/GKtVMv0uU6lUm1tfpSXqefszE6ssSNjtVKx8zZV4Gjj0uG2 J0piWWBI5IRavC6kAw1MgUBknFbrPUh1Nuucdkoh+ns7ShIUCmWo5FNgn42nyJ6CiJYkmfVlZ8ue SwMPO1rTcV0aIK6V2j58iFkoWCkI7AfjtWbhIIa8IAmbt6SHKnQx95jIyOYCCVoDw5W1VFZfotoj 1lrGL0cZNb3ap8IebmK1EgQzNVTtLZ2mok3O+oJROWZbWJV8UuIxk8s+Qglv7JjfDM2OWdokuTnf UwlJrmdGfr1rpTgnPmWYJC28447tO4SdnGIcmD6m9LQ1eoEJFvVlhdsTe+rC+akJguN9IscrHXl/ KKj9qtY8G2juE2/cTtYbwJ6IuY9nBu+BSYjznRVu1RC0dna7c8iBvC0A38seuWW2XftexRlq02Hg cVY5ObYFS/ZGLdHwG3pwI4tFkkmrg0wjQVGe3aFX5uW2Yp3CYQjuCCFszpCro8yBDgDcH79+uGzU uyq1+1O31HfXkgkfnIik4/BX+vEn2bTezER7a/9whSVBLjHf7ArrQf4B6HzuIpYiNTcQ58kUX5Ya nh8jrpqeK4zsj0ETFlxGtsU40OTIBRpxZZkKUv0rl9bLZea0n78CIQyKNNumzcQCmO3AkOulfie6 nIzSgG7FlIKAc8paKCY14tvc/1Yxq1f0V9qbzvVwJGsa0YQc0QMwmFF1SUT5y2w93zYUsawwMqVI A5FmqZZ7DmmBErQspR23ir0WcwnA5wGMfTlk2/xl0kK/qc9pIN3fr0A+bW3UIUdaFKjMpCWvErvw pZcf9dnwF+3Sfi49lX9SI+P3TPCMzHcsPM0oCXri3vAR1Lu3iYQeJ0cW6/psOq7M2XULtuUi9GCq yOnQ2HtkdqKoJ6uIGD1PVqZOwWmoMVJ0hF62c1PhP4bqpem7ClcSvd9tjX1AeZoEh/C1Q4qyK00R EexovZ7i6w8vJiVh3OcvDryVUFCCOKCYlW706gXlgN4xDh2l+A3RHsQYEm7HW4vwi8tZdCdw4h5g Xpkm/tPV/sr1qbSn0RwM86KNSldO0VBf/nhWKKW04/BGtT8+IpEXUvuxIw3W6+vEpNosvb6LWcwC rve0aNv+mPFMr8XQjKWuK6jK6ZL1565djVDVGAG3ib5trw05A/SW5zepgtZdj1pSgjRmWl8c0Sst O/9tPfFpbX6YLTXrkCsfPupeoQvck0pYuplcZhtaXfNypnpry/wB1IlazDBhcEl+zIHF6vjKYJpq TXQcs7k8w6+Yp5fHoeG+bKl1XQBtVnfkp3TS5jbOKA2vri0B2KdZ4nWJCHlKbIsD1zq6wvYErABw zGMDGW6NiCNvk8xAQyismp0JPvhWOW/Ri5oOJLIJaZGgCyuyO5jM1mt/9/jtiIVh6Rlkm6srlhpY JbY56gM3jojDpfdppbWOXx3OIYPjy/v1iwjUDmHwsmfOjsMDQ1Hr9Y8Q4rXTgaNEuwwUJfzvhFJN vi94pEoeFEPqByn1a6P6lIx0QGeE7Ng6pisO7t2BpSjD1VdC9YhypVLt1M+LpnaB5ewDWxpGxmWr 7wjc3NIwA88rup2PU045YjJjfNwDCruevigBriKGzjaBQwuRAhPtUu1zrSPrDY3GAcyOPj8jqh3Y bqglOTswiPX6SzjnZQrfmYZPR5VXqYvGbuhNudyciSJJMHzGkliPYoJy00a2OBwCNrIxeCyFpHth Hx8m6ICKEAco26lpn7zOgjFZutOa94nYo/JIpbWnwac+G0G6u7zVrDjhIeXe/TTemenylPup4dwa 8n2xP8HXMUDQYlJUOTAfZGmUpRQqdkh2g4rSdrQKRL3FdYCwz1saZVhExG0wFLSLcJSA4noTiV4S e8d2q1VaN+mkT5PdPFEjO7kbFFJsXwvNpjg0j9mbf7OAmNVRqVc9GUatzct3SuVlEQ4jF2eleJmr W025ZkHlNUcYT/7k9pZXFvQRdZ5QTQXqa8k6Mq+Npv/0mQxWnFu1pKlXhIzJVjNNiIEciQhg44hY +rDP1HlcN6qB9+Li7RkdI3WtvSAQhUkPNp9FB1N+HObkx7dY8LupJJKRtYFtreusqMKmqh0T6cqW dHr87b7Ssbt6woGaSgi7ZWK5lq5VE9lKNcXbwUL9xwPs53RwNCxnOJ5UPORwxYu1Qt3EU5zPoVff t9bCwdKt+7MdaPJgyTesgZvvQSRS7q0Yh3pHzRs8VDx63aCWU0CAwRVpproMGkq6kl97IiiHdWo8 ccwdaaS0Q5R1wIkFygO5M/sFG1hwD/hqzEycccV2v5KO4JNfrEIdIjeP22zAHLSUm1xwPKdaLp77 NpiVCY6bMOoNIl6VCSEK0sMwOsdp1PRlgyp8FFEo2TeemTsW+8roioa2x45rcF8hS1QRhzRWBLCY ZCYTSwtg6Vfd6hx991N/tO2w0hi1eh/abf1AKlj3m2Dda/3Wk1Ox1mlTdR8lfbiZaK8Iaypq5JXk k3zHSX8gtkm9iGIJtbo60RrQDNEA/EVjR3BBETRkEfakdbrYYfdnbxanqkOpl41tEWZ70dXuCYnv 24VH55kYdjj3A0AGUJ/G7a5aQkMR1nlz1jQ36RmhmXJyK6OKOH4O/8mZspPm2k/KsDSIPHINSyVJ YPU0WwAnzBW4iziTTAAWemxCS8p35xUuUrVJRBlQWecCD0TxPOej0vUMntAADSLkV0Db2MApupac tAOjZBlW48v5rbCD3UE4f/AT7Y2XPBtTHgzushflEAKMausrH1UFUG6OQqHER1IVQwc92wYeTNXO Ya6z8JViimawO686PoX+iagOdLTobVedx6Xa52Uv1sV4Xap8m2MmeIzXH8uc4cDI0nhTLBJY2kdG T5H/tvk1/oq5/xft1lEreOK4oE7NjScRZPi2nRvnvLzqpWOYCgvB4+lgk/sWDAOvTuPQzRFU4FN9 Sa42szT4+1QBp2KQut6k52l/B/ixGwTiedtLVcDOJSni5qKeRCM/GfX08v3jFkNf1VFUQuqOMD96 4FRR8DfEJ88ch+5AMe5HDMzC299ESNT2psdu0lEzAi5gx0jf6F0j9Em/d3dldTPZ14ldaJ0O80FO VQ8oK2MrBWDvhl+q5B26ev9CNYLf0+q3aBcrijDhEJ8vTfLaZ19lOPlM13wWOZyu9SV6y83Rghmr 9Eabboh6gx7JAA++ctQH9NSnOCtQu+GdlEIcdm290vhmywoJj5OBarOlgcMQ0YuyrQVGyckQo4tQ iY2F3FS04A26RmkXnGoS2e5J4m6a16Jw5pN3EId0OqvG5zVRg/3mkS3ZqjhiGwMiqEmVRq9lLrBS USLrTZvm9W8Z2IB9QAHeVYD7iRZdhXdhB+/7kmnCt9OHVSpFtpPlS8R7/EOcK8s5IzSixNhgI6Qv 4M7BIo+DL4A7TInOQ0PYm1uvFZXceJxdkV5rnOnPSPCrMpcxX/cXF/VFwCJwVNLu1OwsmRVzVI0Y lpNZ0kOMHsf8g5Nxjqc43GuF7OV7s14WdMcUjwJwOIqRusfb3CwamzxL9zAkDnYzHUNdfiTR1xqg mhf16BRBZaCQG5Hv6Ut6W8PZHOTy90irCZWVHrrdwvKXpCRVGCiIaeM7jczedDmwRHEHpJfdI6wU C9B0JoqA5VlGagRqyBMrgHPOICRaCescc9W95YYROhFlmR/XusLwYdmmOJsiv8bRtIN4wNVtTrLR Rt/sAZ1oaJhKbb7MJ4+0j2VYqLiJ9LDqeWe8H+ltzhY1FS3kMLrUz6eQaDvKgp08ffoSiDMIaso0 uz15RbxcfM+rGHKhE+aVOdCg6PC1RrXwBCbiW4GqcTlWVyjUZmLt1Jip2Eahe2/Pd0F+0lfPwBut HEG7pIB+3XI58GdlT6ZO65yDlKPCUMGSmw5Ca6TWacl9an0J5QEwrvwQ63VCQQeLxhe/PELPiY5z josDPLq42cWkhJ1iRLEojwmfPPw8sQKztJbCOb9gEMw9ZnDd+u6wXjBN1eQKaoRNTWjbyGdYtrOw 7KydWEIOoEnodz0/I5dvjSgh7VoUcb6s6KmWKeHsznYDb7cHNrzEXRFPIkysfHgb8GuTl/UxyWxU prFZk0nGBfVrFZ2xeVyvNzull+9eWqIz5KVptHld5/uxruq5xgrFzgHENB5xIisSgiXMv677l68P XRc1VuXnjn49dA6hK/+ypVSgtrnXr4ToFUUJou/iPOOhRgtxwXSHV5ZL8/ncoOBrRI9kXYWtMNec F9Aototl7qbz5OmKclC71+Y6ZuJjZdcYS3TrGJtZGk+qa51eFiH3otCH+hRHjyJDF7Qx2+KGyZHh Qa1ZPPR+mh2ZxvRzwOErshHipwtV25+lV+j2MzdsLLkwO5pUCSiBCeirWW01lSN8/IeI2rstunJ6 sLMAa88Usl1+f0iMRuPYMQtdfcMRDQNMakwFMAQD7YXJNcy6zv2484iGCKB5+w+XNe7NIKuWcPbC Szn8zGT3CCuA8AASwRxjEsnGHZksnxA4mUtVQUpS+z3v/Tte4AD//dTeJV96utL66shyoOUbKS+l 8rFTGy97S5aVa32D5qQkWAoXUx3+Dp/YLrwQaCgczEJOZQTS9Vss7NDMd91lpPomvH0nucS6yXlU DFpxfKhZv1J3pP1+mil81wMSFrwV09XF7YoJdK20nWWoft2BOk/rus85O8+cEj9uGE0Xh1Cdv9/O W59GQjdq//7iNinY+8ws86DrYeIAugQU+/8AZT5njgplbmRzdHJlYW0KZW5kb2JqCjI2NiAwIG9i aiA8PAovVHlwZSAvRm9udERlc2NyaXB0b3IKL0ZvbnROYW1lIC9BWkhFT0ErQ01SMTAKL0ZsYWdz IDQKL0ZvbnRCQm94IFstMjUxIC0yNTAgMTAwOSA5NjldCi9Bc2NlbnQgNjk0Ci9DYXBIZWlnaHQg NjgzCi9EZXNjZW50IC0xOTQKL0l0YWxpY0FuZ2xlIDAKL1N0ZW1WIDY5Ci9YSGVpZ2h0IDQzMQov Q2hhclNldCAoL0EvQi9DL0QvRS9GL0cvSC9JL0ovSy9ML00vTi9PL1AvUS9SL1MvVC9VL1YvVy9Y L2EvYXN0ZXJpc2svYXQvYi9icmFja2V0bGVmdC9icmFja2V0cmlnaHQvYy9jb2xvbi9jb21tYS9k L2UvZWlnaHQvZi9mZi9mZmkvZmkvZml2ZS9mbC9mb3VyL2cvaC9oeXBoZW4vaS9qL2svbC9tL24v bmluZS9vL29uZS9wL3BhcmVubGVmdC9wYXJlbnJpZ2h0L3BlcmNlbnQvcGVyaW9kL3BsdXMvcS9x dW90ZWRibGxlZnQvcXVvdGVkYmxyaWdodC9xdW90ZXJpZ2h0L3Ivcy9zZW1pY29sb24vc2V2ZW4v c2l4L3NsYXNoL3QvdGhyZWUvdHdvL3Uvdi93L3gveS96L3plcm8pCi9Gb250RmlsZSAyNjUgMCBS Cj4+IGVuZG9iagoyNjcgMCBvYmogPDwKL0xlbmd0aDEgNzUwCi9MZW5ndGgyIDU3NgovTGVuZ3Ro MyAwCi9MZW5ndGggMTA4OSAgICAgIAovRmlsdGVyIC9GbGF0ZURlY29kZQo+PgpzdHJlYW0KeNpT VQwI1nVMyU9KdcvPK9E11DO0UnD2DY40NFAw1DPgUlV1LkpNLMnMz3NJLEm1UjC0tDRUcCxNVzA0 VTAwtzIysDI151JVcM4vqCzKTM8oUdBw1gQpMldwzE0tykxOzFPwTSzJSM0FmpGcmKMQnJ+cmVpS qafgmJOjEATSUawQlFqcWlSWmqLHZWiokJKZXKKQlJqemcelD3KRZ15avoI5RDiltAAmVZZaVAx0 lIIG0JGaCkAnpuTn5VQqpKSmcen75QPtSgW6hBqOQjfcrTQnxy8xF2Q8OJQw5BNzM3MqoSrycwtK S1KLFHzzU1KL8tCVhqdCHOebmpJZmosu61mSmJOZ7JiXnpOqoGtoomdgbAqRyCx2y6xITQnILEnO UEhLzClOBYun5qWgOwUYfGCH6Lu7OYYHuWtD4xUsGZCYmVcSUlmQqmCAUA3mGyL4wFAqyqxQiDbQ MzAwBCoEQhgrFs0y17zk/JTMvHQFI1MzhcSiosRKLmAKAvJMFaoNFTLzUlIrFFIrgC7W18vLLwFq UQAGTa1CWn4RFyhagclJPwkYtKklIHEuTI84OeVXVOsaWSroWpoBDTY0NFMwNzetRVGYXFpUlJpX Ak4rwOCA8dMygUGYmlqRmsx181p+snVL1vRtbSvrXBdfWMWqz/nzxNqXN9kPROyom52ZUhtsOi9Q Mb1kyauFj7b2HRbPvijhlWw9Vbhoi2SvX0/cl0XCa7Z2LVgWMaHBdL/ejWDxyuauabz/tNVfeR4u DJsxp/WRtNX+osezOpV1bn5Rrj/BMy/lhVPU4n3f713jFtIKmqSlJGV+cwX7XUYx8cq7zy/Lf9pR P/24bfK7s7d8PAPEi9261C+m2XEnfUn89oQrNq3s4kXtwGeOB6+8eFQukfJHwL9nf3TFG9kOpXbV j0eCl1V87aqTrr5+qoBd/FLH696FX2v8Obn2yzodvXvhcMvxR/r9De77ZH1kTjw2zvgtdULbb5pI usE9Y6ZNz3ZIns56ErpxvWH7/xfsUkvrfixLzJ6zfYqsy5uqwuW7bb+HivfW6nlvmxH5fsnuw9zX dosaCttfuenc/3M+p98Zti4j39Kt36btyOh7rS/+9K3JmWsX3Jc8bshl4JGcWxMYu52r1z/R7R9b 78Gn97qPFpgL3uJkFtplf4CL40jwMc5j6iv2nc2TX+hlzeSeN2HVjS0FPA7MDXtm/d9f4f5aI016 7uFV/C5HjT89qD3j+3CuWfUn5ce2hxUvqFTx5X1bfeJXkOg6Focp79O72tXO1jDKM+3/sTpv3TtL qRvmQhzK+y5svfFjY5CreUXhMv8K8+4txoye16bIV7X9/n9k9uSTjqFff9V+0isSCZThmpRp73P7 c4tgqqhDuL7udd5JXg8+9slcbfx8otByovr/WPYVGR3R8d/Pvg7YYWStanzvx53p1lIv/BcsAgDD HQ2BCmVuZHN0cmVhbQplbmRvYmoKMjY4IDAgb2JqIDw8Ci9UeXBlIC9Gb250RGVzY3JpcHRvcgov Rm9udE5hbWUgL0dGQVdSRytDTVNZMTAKL0ZsYWdzIDQKL0ZvbnRCQm94IFstMjkgLTk2MCAxMTE2 IDc3NV0KL0FzY2VudCA3NTAKL0NhcEhlaWdodCA2ODMKL0Rlc2NlbnQgLTE5NAovSXRhbGljQW5n bGUgLTE0Ci9TdGVtViA4NQovWEhlaWdodCA0MzEKL0NoYXJTZXQgKC9idWxsZXQpCi9Gb250Rmls ZSAyNjcgMCBSCj4+IGVuZG9iago4NCAwIG9iaiA8PAovVHlwZSAvRm9udAovU3VidHlwZSAvVHlw ZTEKL0Jhc2VGb250IC9SSEZBUVIrQ01CWDEwCi9Gb250RGVzY3JpcHRvciAyNjIgMCBSCi9GaXJz dENoYXIgNDkKL0xhc3RDaGFyIDEyMQovV2lkdGhzIDI1OCAwIFIKPj4gZW5kb2JqCjgyIDAgb2Jq IDw8Ci9UeXBlIC9Gb250Ci9TdWJ0eXBlIC9UeXBlMQovQmFzZUZvbnQgL0pHTVVVQitDTUJYMTIK L0ZvbnREZXNjcmlwdG9yIDI2NCAwIFIKL0ZpcnN0Q2hhciAzOQovTGFzdENoYXIgMTIyCi9XaWR0 aHMgMjU5IDAgUgo+PiBlbmRvYmoKNjMgMCBvYmogPDwKL1R5cGUgL0ZvbnQKL1N1YnR5cGUgL1R5 cGUxCi9CYXNlRm9udCAvQVpIRU9BK0NNUjEwCi9Gb250RGVzY3JpcHRvciAyNjYgMCBSCi9GaXJz dENoYXIgMTEKL0xhc3RDaGFyIDEyMgovV2lkdGhzIDI2MCAwIFIKPj4gZW5kb2JqCjg5IDAgb2Jq IDw8Ci9UeXBlIC9Gb250Ci9TdWJ0eXBlIC9UeXBlMQovQmFzZUZvbnQgL0dGQVdSRytDTVNZMTAK L0ZvbnREZXNjcmlwdG9yIDI2OCAwIFIKL0ZpcnN0Q2hhciAxNQovTGFzdENoYXIgMTUKL1dpZHRo cyAyNTcgMCBSCj4+IGVuZG9iago2NCAwIG9iaiA8PAovVHlwZSAvUGFnZXMKL0NvdW50IDYKL1Bh cmVudCAyNjkgMCBSCi9LaWRzIFs1OCAwIFIgNzkgMCBSIDg2IDAgUiA5MiAwIFIgMTA0IDAgUiAx MDkgMCBSXQo+PiBlbmRvYmoKMTIzIDAgb2JqIDw8Ci9UeXBlIC9QYWdlcwovQ291bnQgNgovUGFy ZW50IDI2OSAwIFIKL0tpZHMgWzEyMCAwIFIgMTM4IDAgUiAxNjQgMCBSIDE4MCAwIFIgMjA0IDAg UiAyMjMgMCBSXQo+PiBlbmRvYmoKMjQ0IDAgb2JqIDw8Ci9UeXBlIC9QYWdlcwovQ291bnQgMgov UGFyZW50IDI2OSAwIFIKL0tpZHMgWzI0MSAwIFIgMjUzIDAgUl0KPj4gZW5kb2JqCjI2OSAwIG9i aiA8PAovVHlwZSAvUGFnZXMKL0NvdW50IDE0Ci9LaWRzIFs2NCAwIFIgMTIzIDAgUiAyNDQgMCBS XQo+PiBlbmRvYmoKMjcwIDAgb2JqIDw8Ci9UeXBlIC9PdXRsaW5lcwovRmlyc3QgNyAwIFIKL0xh c3QgNDcgMCBSCi9Db3VudCA2Cj4+IGVuZG9iago1NSAwIG9iaiA8PAovVGl0bGUgNTYgMCBSCi9B IDUzIDAgUgovUGFyZW50IDQ3IDAgUgovUHJldiA1MSAwIFIKPj4gZW5kb2JqCjUxIDAgb2JqIDw8 Ci9UaXRsZSA1MiAwIFIKL0EgNDkgMCBSCi9QYXJlbnQgNDcgMCBSCi9OZXh0IDU1IDAgUgo+PiBl bmRvYmoKNDcgMCBvYmogPDwKL1RpdGxlIDQ4IDAgUgovQSA0NSAwIFIKL1BhcmVudCAyNzAgMCBS Ci9QcmV2IDIzIDAgUgovRmlyc3QgNTEgMCBSCi9MYXN0IDU1IDAgUgovQ291bnQgLTIKPj4gZW5k b2JqCjQzIDAgb2JqIDw8Ci9UaXRsZSA0NCAwIFIKL0EgNDEgMCBSCi9QYXJlbnQgMjMgMCBSCi9Q cmV2IDM5IDAgUgo+PiBlbmRvYmoKMzkgMCBvYmogPDwKL1RpdGxlIDQwIDAgUgovQSAzNyAwIFIK L1BhcmVudCAyMyAwIFIKL1ByZXYgMzUgMCBSCi9OZXh0IDQzIDAgUgo+PiBlbmRvYmoKMzUgMCBv YmogPDwKL1RpdGxlIDM2IDAgUgovQSAzMyAwIFIKL1BhcmVudCAyMyAwIFIKL1ByZXYgMzEgMCBS Ci9OZXh0IDM5IDAgUgo+PiBlbmRvYmoKMzEgMCBvYmogPDwKL1RpdGxlIDMyIDAgUgovQSAyOSAw IFIKL1BhcmVudCAyMyAwIFIKL1ByZXYgMjcgMCBSCi9OZXh0IDM1IDAgUgo+PiBlbmRvYmoKMjcg MCBvYmogPDwKL1RpdGxlIDI4IDAgUgovQSAyNSAwIFIKL1BhcmVudCAyMyAwIFIKL05leHQgMzEg MCBSCj4+IGVuZG9iagoyMyAwIG9iaiA8PAovVGl0bGUgMjQgMCBSCi9BIDIxIDAgUgovUGFyZW50 IDI3MCAwIFIKL1ByZXYgMTkgMCBSCi9OZXh0IDQ3IDAgUgovRmlyc3QgMjcgMCBSCi9MYXN0IDQz IDAgUgovQ291bnQgLTUKPj4gZW5kb2JqCjE5IDAgb2JqIDw8Ci9UaXRsZSAyMCAwIFIKL0EgMTcg MCBSCi9QYXJlbnQgMjcwIDAgUgovUHJldiAxNSAwIFIKL05leHQgMjMgMCBSCj4+IGVuZG9iagox NSAwIG9iaiA8PAovVGl0bGUgMTYgMCBSCi9BIDEzIDAgUgovUGFyZW50IDI3MCAwIFIKL1ByZXYg MTEgMCBSCi9OZXh0IDE5IDAgUgo+PiBlbmRvYmoKMTEgMCBvYmogPDwKL1RpdGxlIDEyIDAgUgov QSA5IDAgUgovUGFyZW50IDI3MCAwIFIKL1ByZXYgNyAwIFIKL05leHQgMTUgMCBSCj4+IGVuZG9i ago3IDAgb2JqIDw8Ci9UaXRsZSA4IDAgUgovQSA1IDAgUgovUGFyZW50IDI3MCAwIFIKL05leHQg MTEgMCBSCj4+IGVuZG9iagoyNzEgMCBvYmogPDwKL05hbWVzIFsoRG9jLVN0YXJ0KSA2MiAwIFIg KGZpZ3VyZS4xKSA5NSAwIFIgKGZpZ3VyZS4xMCkgMTk4IDAgUiAoZmlndXJlLjExKSAxOTkgMCBS IChmaWd1cmUuMTIpIDIyMSAwIFIgKGZpZ3VyZS4yKSAxMTIgMCBSXQovTGltaXRzIFsoRG9jLVN0 YXJ0KSAoZmlndXJlLjIpXQo+PiBlbmRvYmoKMjcyIDAgb2JqIDw8Ci9OYW1lcyBbKGZpZ3VyZS4z KSAxMzEgMCBSIChmaWd1cmUuNCkgMTMyIDAgUiAoZmlndXJlLjUpIDE1NSAwIFIgKGZpZ3VyZS42 KSAxNTYgMCBSIChmaWd1cmUuNykgMTU3IDAgUiAoZmlndXJlLjgpIDE1OCAwIFJdCi9MaW1pdHMg WyhmaWd1cmUuMykgKGZpZ3VyZS44KV0KPj4gZW5kb2JqCjI3MyAwIG9iaiA8PAovTmFtZXMgWyhm aWd1cmUuOSkgMTk3IDAgUiAocGFnZS4xKSA2MSAwIFIgKHBhZ2UuMTApIDE4MiAwIFIgKHBhZ2Uu MTEpIDIwNiAwIFIgKHBhZ2UuMTIpIDIyNSAwIFIgKHBhZ2UuMTMpIDI0MyAwIFJdCi9MaW1pdHMg WyhmaWd1cmUuOSkgKHBhZ2UuMTMpXQo+PiBlbmRvYmoKMjc0IDAgb2JqIDw8Ci9OYW1lcyBbKHBh Z2UuMTQpIDI1NSAwIFIgKHBhZ2UuMikgODEgMCBSIChwYWdlLjMpIDg4IDAgUiAocGFnZS40KSA5 NCAwIFIgKHBhZ2UuNSkgMTA2IDAgUiAocGFnZS42KSAxMTEgMCBSXQovTGltaXRzIFsocGFnZS4x NCkgKHBhZ2UuNildCj4+IGVuZG9iagoyNzUgMCBvYmogPDwKL05hbWVzIFsocGFnZS43KSAxMjIg MCBSIChwYWdlLjgpIDE0MCAwIFIgKHBhZ2UuOSkgMTY2IDAgUiAoc2VjdGlvbiouMSkgODMgMCBS IChzZWN0aW9uKi4yKSAyNTYgMCBSIChzZWN0aW9uLjEpIDYgMCBSXQovTGltaXRzIFsocGFnZS43 KSAoc2VjdGlvbi4xKV0KPj4gZW5kb2JqCjI3NiAwIG9iaiA8PAovTmFtZXMgWyhzZWN0aW9uLjIp IDEwIDAgUiAoc2VjdGlvbi4zKSAxNCAwIFIgKHNlY3Rpb24uNCkgMTggMCBSIChzZWN0aW9uLjUp IDIyIDAgUiAoc2VjdGlvbi42KSA0NiAwIFIgKHN1YnNlY3Rpb24uNS4xKSAyNiAwIFJdCi9MaW1p dHMgWyhzZWN0aW9uLjIpIChzdWJzZWN0aW9uLjUuMSldCj4+IGVuZG9iagoyNzcgMCBvYmogPDwK L05hbWVzIFsoc3Vic2VjdGlvbi41LjIpIDMwIDAgUiAoc3Vic2VjdGlvbi41LjMpIDM0IDAgUiAo c3Vic2VjdGlvbi41LjQpIDM4IDAgUiAoc3Vic2VjdGlvbi41LjUpIDQyIDAgUiAoc3Vic2VjdGlv bi42LjEpIDUwIDAgUiAoc3Vic2VjdGlvbi42LjIpIDU0IDAgUl0KL0xpbWl0cyBbKHN1YnNlY3Rp b24uNS4yKSAoc3Vic2VjdGlvbi42LjIpXQo+PiBlbmRvYmoKMjc4IDAgb2JqIDw8Ci9LaWRzIFsy NzEgMCBSIDI3MiAwIFIgMjczIDAgUiAyNzQgMCBSIDI3NSAwIFIgMjc2IDAgUl0KL0xpbWl0cyBb KERvYy1TdGFydCkgKHN1YnNlY3Rpb24uNS4xKV0KPj4gZW5kb2JqCjI3OSAwIG9iaiA8PAovS2lk cyBbMjc3IDAgUl0KL0xpbWl0cyBbKHN1YnNlY3Rpb24uNS4yKSAoc3Vic2VjdGlvbi42LjIpXQo+ PiBlbmRvYmoKMjgwIDAgb2JqIDw8Ci9LaWRzIFsyNzggMCBSIDI3OSAwIFJdCi9MaW1pdHMgWyhE b2MtU3RhcnQpIChzdWJzZWN0aW9uLjYuMildCj4+IGVuZG9iagoyODEgMCBvYmogPDwKL0Rlc3Rz IDI4MCAwIFIKPj4gZW5kb2JqCjI4MiAwIG9iaiA8PAovVHlwZSAvQ2F0YWxvZwovUGFnZXMgMjY5 IDAgUgovT3V0bGluZXMgMjcwIDAgUgovTmFtZXMgMjgxIDAgUgovUGFnZU1vZGUvVXNlT3V0bGlu ZXMKL09wZW5BY3Rpb24gNTcgMCBSCj4+IGVuZG9iagoyODMgMCBvYmogPDwKL0F1dGhvcigpL1Rp dGxlKCkvU3ViamVjdCgpL0NyZWF0b3IoTGFUZVggd2l0aCBoeXBlcnJlZiBwYWNrYWdlKS9Qcm9k dWNlcihwZGZUZVgtMS40MC4zKS9LZXl3b3JkcygpCi9DcmVhdGlvbkRhdGUgKEQ6MjAwOTEyMjEy MjUxMzctMDUnMDAnKQovTW9kRGF0ZSAoRDoyMDA5MTIyMTIyNTEzNy0wNScwMCcpCi9UcmFwcGVk IC9GYWxzZQovUFRFWC5GdWxsYmFubmVyIChUaGlzIGlzIHBkZlRlWCwgVmVyc2lvbiAzLjE0MTU5 Mi0xLjQwLjMtMi4yIChXZWIyQyA3LjUuNikga3BhdGhzZWEgdmVyc2lvbiAzLjUuNikKPj4gZW5k b2JqCnhyZWYKMCAyODQKMDAwMDAwMDAwMSA2NTUzNSBmIAowMDAwMDAwMDAyIDAwMDAwIGYgCjAw MDAwMDAwMDMgMDAwMDAgZiAKMDAwMDAwMDAwNCAwMDAwMCBmIAowMDAwMDAwMDAwIDAwMDAwIGYg CjAwMDAwMDAwMTUgMDAwMDAgbiAKMDAwMDAwODU1OCAwMDAwMCBuIAowMDAwMTY2ODQxIDAwMDAw IG4gCjAwMDAwMDAwNjAgMDAwMDAgbiAKMDAwMDAwMDA4OSAwMDAwMCBuIAowMDAwMDA4NjEyIDAw MDAwIG4gCjAwMDAxNjY3NTUgMDAwMDAgbiAKMDAwMDAwMDEzNCAwMDAwMCBuIAowMDAwMDAwMTY1 IDAwMDAwIG4gCjAwMDAwMjc0ODAgMDAwMDAgbiAKMDAwMDE2NjY2NyAwMDAwMCBuIAowMDAwMDAw MjExIDAwMDAwIG4gCjAwMDAwMDAyMzYgMDAwMDAgbiAKMDAwMDAyNzUzNSAwMDAwMCBuIAowMDAw MTY2NTc5IDAwMDAwIG4gCjAwMDAwMDAyODIgMDAwMDAgbiAKMDAwMDAwMDMxNyAwMDAwMCBuIAow MDAwMDMzNDIxIDAwMDAwIG4gCjAwMDAxNjY0NTQgMDAwMDAgbiAKMDAwMDAwMDM2MyAwMDAwMCBu IAowMDAwMDAwNDA1IDAwMDAwIG4gCjAwMDAwMzM0NzcgMDAwMDAgbiAKMDAwMDE2NjM4MCAwMDAw MCBuIAowMDAwMDAwNDU2IDAwMDAwIG4gCjAwMDAwMDA0OTMgMDAwMDAgbiAKMDAwMDAzMzUzMyAw MDAwMCBuIAowMDAwMTY2MjkzIDAwMDAwIG4gCjAwMDAwMDA1NDQgMDAwMDAgbiAKMDAwMDAwMDU3 NSAwMDAwMCBuIAowMDAwMDQyMzUyIDAwMDAwIG4gCjAwMDAxNjYyMDYgMDAwMDAgbiAKMDAwMDAw MDYyNiAwMDAwMCBuIAowMDAwMDAwNjYzIDAwMDAwIG4gCjAwMDAwNDI0MDggMDAwMDAgbiAKMDAw MDE2NjExOSAwMDAwMCBuIAowMDAwMDAwNzE0IDAwMDAwIG4gCjAwMDAwMDA3NTYgMDAwMDAgbiAK MDAwMDA2NDg4OCAwMDAwMCBuIAowMDAwMTY2MDQ1IDAwMDAwIG4gCjAwMDAwMDA4MDcgMDAwMDAg biAKMDAwMDAwMDg0NiAwMDAwMCBuIAowMDAwMTE0NDQxIDAwMDAwIG4gCjAwMDAxNjU5MzMgMDAw MDAgbiAKMDAwMDAwMDg5MiAwMDAwMCBuIAowMDAwMDAwOTIxIDAwMDAwIG4gCjAwMDAxMTQ0OTcg MDAwMDAgbiAKMDAwMDE2NTg1OSAwMDAwMCBuIAowMDAwMDAwOTcyIDAwMDAwIG4gCjAwMDAwMDEw MTEgMDAwMDAgbiAKMDAwMDExNDU1MyAwMDAwMCBuIAowMDAwMTY1Nzg1IDAwMDAwIG4gCjAwMDAw MDEwNjIgMDAwMDAgbiAKMDAwMDAwMTEwMyAwMDAwMCBuIAowMDAwMDAyNjk0IDAwMDAwIG4gCjAw MDAwMDI5MTIgMDAwMDAgbiAKMDAwMDAwMTE1MyAwMDAwMCBuIAowMDAwMDAyODAyIDAwMDAwIG4g CjAwMDAwMDI4NTcgMDAwMDAgbiAKMDAwMDE2NTAzNiAwMDAwMCBuIAowMDAwMTY1MzIwIDAwMDAw IG4gCjAwMDAwMDQzNzEgMDAwMDAgbiAKMDAwMDAwNDUyMSAwMDAwMCBuIAowMDAwMDA0NjcxIDAw MDAwIG4gCjAwMDAwMDQ4MjEgMDAwMDAgbiAKMDAwMDAwNDk3MCAwMDAwMCBuIAowMDAwMDA1MTIw IDAwMDAwIG4gCjAwMDAwMDUyNzQgMDAwMDAgbiAKMDAwMDAwNTQyOSAwMDAwMCBuIAowMDAwMDA1 NTg0IDAwMDAwIG4gCjAwMDAwMDU3MzkgMDAwMDAgbiAKMDAwMDAwNTg5NCAwMDAwMCBuIAowMDAw MDA2MDQ0IDAwMDAwIG4gCjAwMDAwMDYxOTggMDAwMDAgbiAKMDAwMDAwNjQ2MiAwMDAwMCBuIAow MDAwMDA0MTYwIDAwMDAwIG4gCjAwMDAwMDI5ODIgMDAwMDAgbiAKMDAwMDAwNjM1MiAwMDAwMCBu IAowMDAwMTY0ODkzIDAwMDAwIG4gCjAwMDAwMDY0MDcgMDAwMDAgbiAKMDAwMDE2NDc1MCAwMDAw MCBuIAowMDAwMDA4NjY3IDAwMDAwIG4gCjAwMDAwMDgzOTUgMDAwMDAgbiAKMDAwMDAwNjU1NiAw MDAwMCBuIAowMDAwMDA4NTAzIDAwMDAwIG4gCjAwMDAxNjUxNzggMDAwMDAgbiAKMDAwMDAxMTA5 OSAwMDAwMCBuIAowMDAwMDI3NjUwIDAwMDAwIG4gCjAwMDAwMTA5OTEgMDAwMDAgbiAKMDAwMDAw ODc2MSAwMDAwMCBuIAowMDAwMDI3NDI1IDAwMDAwIG4gCjAwMDAwMjc1OTAgMDAwMDAgbiAKMDAw MDAxMTQ0NyAwMDAwMCBuIAowMDAwMDExNTkxIDAwMDAwIG4gCjAwMDAwMjY1MTUgMDAwMDAgbiAK MDAwMDAyNjUzNCAwMDAwMCBuIAowMDAwMDI2NTU2IDAwMDAwIG4gCjAwMDAwMjY1OTMgMDAwMDAg biAKMDAwMDAyNzQwNCAwMDAwMCBuIAowMDAwMDMwNjExIDAwMDAwIG4gCjAwMDAwMzA0NDMgMDAw MDAgbiAKMDAwMDAyNzc1OSAwMDAwMCBuIAowMDAwMDMwNTU0IDAwMDAwIG4gCjAwMDAwMzMyMTMg MDAwMDAgbiAKMDAwMDAzMzU4OCAwMDAwMCBuIAowMDAwMDMzMDgyIDAwMDAwIG4gCjAwMDAwMzA2 ODIgMDAwMDAgbiAKMDAwMDAzMzM2NCAwMDAwMCBuIAowMDAwMDQyMjkwIDAwMDAwIG4gCjAwMDAw MzU5NzUgMDAwMDAgbiAKMDAwMDA0MTkzMyAwMDAwMCBuIAowMDAwMDQ0MzAyIDAwMDAwIG4gCjAw MDAwNDIwODQgMDAwMDAgbiAKMDAwMDA1MDYwNCAwMDAwMCBuIAowMDAwMDU1ODE2IDAwMDAwIG4g CjAwMDAwNDI0NjQgMDAwMDAgbiAKMDAwMDAzNTgzNSAwMDAwMCBuIAowMDAwMDMzNjcxIDAwMDAw IG4gCjAwMDAwNDIyMzMgMDAwMDAgbiAKMDAwMDE2NTQzMiAwMDAwMCBuIAowMDAwMDM2MzI3IDAw MDAwIG4gCjAwMDAwMzY0NzIgMDAwMDAgbiAKMDAwMDA0MTAyMiAwMDAwMCBuIAowMDAwMDQxMDQy IDAwMDAwIG4gCjAwMDAwNDEwNjQgMDAwMDAgbiAKMDAwMDA0MTEwMSAwMDAwMCBuIAowMDAwMDQx OTEyIDAwMDAwIG4gCjAwMDAwNTY0NzcgMDAwMDAgbiAKMDAwMDA1NjUzOSAwMDAwMCBuIAowMDAw MDU5MjQyIDAwMDAwIG4gCjAwMDAwNTU5NjcgMDAwMDAgbiAKMDAwMDA1NjExOCAwMDAwMCBuIAow MDAwMDU2MjY5IDAwMDAwIG4gCjAwMDAwNTY2MDEgMDAwMDAgbiAKMDAwMDA0NDE0NiAwMDAwMCBu IAowMDAwMDQyNTc1IDAwMDAwIG4gCjAwMDAwNTY0MjAgMDAwMDAgbiAKMDAwMDA0NDY1OSAwMDAw MCBuIAowMDAwMDQ0ODA0IDAwMDAwIG4gCjAwMDAwNDk2OTMgMDAwMDAgbiAKMDAwMDA0OTcxMyAw MDAwMCBuIAowMDAwMDQ5NzM1IDAwMDAwIG4gCjAwMDAwNDk3NzIgMDAwMDAgbiAKMDAwMDA1MDU4 MyAwMDAwMCBuIAowMDAwMDUwOTU1IDAwMDAwIG4gCjAwMDAwNTExMDAgMDAwMDAgbiAKMDAwMDA1 NDkwNSAwMDAwMCBuIAowMDAwMDU0OTI1IDAwMDAwIG4gCjAwMDAwNTQ5NDcgMDAwMDAgbiAKMDAw MDA1NDk4NCAwMDAwMCBuIAowMDAwMDU1Nzk1IDAwMDAwIG4gCjAwMDAwNjQ4MjYgMDAwMDAgbiAK MDAwMDA4NDg5OCAwMDAwMCBuIAowMDAwMDg0OTU5IDAwMDAwIG4gCjAwMDAwOTk0ODcgMDAwMDAg biAKMDAwMDA2NjUzNSAwMDAwMCBuIAowMDAwMDc0ODI5IDAwMDAwIG4gCjAwMDAwODYwOTkgMDAw MDAgbiAKMDAwMDA4NDM4OCAwMDAwMCBuIAowMDAwMDY0OTQ0IDAwMDAwIG4gCjAwMDAwNTkxMzAg MDAwMDAgbiAKMDAwMDA1NjcxMyAwMDAwMCBuIAowMDAwMDY0NzY5IDAwMDAwIG4gCjAwMDAwNTk1 OTggMDAwMDAgbiAKMDAwMDA1OTc0MyAwMDAwMCBuIAowMDAwMDYzMjIyIDAwMDAwIG4gCjAwMDAw NjMyNDIgMDAwMDAgbiAKMDAwMDA2MzI2NCAwMDAwMCBuIAowMDAwMDYzOTAwIDAwMDAwIG4gCjAw MDAwNjM5MzcgMDAwMDAgbiAKMDAwMDA2NDc0OCAwMDAwMCBuIAowMDAwMDg0NTM5IDAwMDAwIG4g CjAwMDAwODQ2OTAgMDAwMDAgbiAKMDAwMDA5MzkzMSAwMDAwMCBuIAowMDAwMTAwNzI5IDAwMDAw IG4gCjAwMDAwODUwMjAgMDAwMDAgbiAKMDAwMDA2NjM4NyAwMDAwMCBuIAowMDAwMDY1MDU1IDAw MDAwIG4gCjAwMDAwODQ4NDEgMDAwMDAgbiAKMDAwMDA2Njg5MSAwMDAwMCBuIAowMDAwMDY3MDM2 IDAwMDAwIG4gCjAwMDAwNzM5MTggMDAwMDAgbiAKMDAwMDA3MzkzOCAwMDAwMCBuIAowMDAwMDcz OTYwIDAwMDAwIG4gCjAwMDAwNzM5OTcgMDAwMDAgbiAKMDAwMDA3NDgwOCAwMDAwMCBuIAowMDAw MDc1MTg3IDAwMDAwIG4gCjAwMDAwNzUzMzIgMDAwMDAgbiAKMDAwMDA4MzQ3NyAwMDAwMCBuIAow MDAwMDgzNDk3IDAwMDAwIG4gCjAwMDAwODM1MTkgMDAwMDAgbiAKMDAwMDA4MzU1NiAwMDAwMCBu IAowMDAwMDg0MzY3IDAwMDAwIG4gCjAwMDAwOTk1NDggMDAwMDAgbiAKMDAwMDExNDMxNyAwMDAw MCBuIAowMDAwMTE0Mzc5IDAwMDAwIG4gCjAwMDAxMDc1NjYgMDAwMDAgbiAKMDAwMDA5OTI3OCAw MDAwMCBuIAowMDAwMTE2NDEzIDAwMDAwIG4gCjAwMDAwOTk2MTAgMDAwMDAgbiAKMDAwMDA4NTk2 NyAwMDAwMCBuIAowMDAwMDg1MTMyIDAwMDAwIG4gCjAwMDAwOTk0MzAgMDAwMDAgbiAKMDAwMDA4 NjQ1NCAwMDAwMCBuIAowMDAwMDg2NTk5IDAwMDAwIG4gCjAwMDAwOTMwMjAgMDAwMDAgbiAKMDAw MDA5MzA0MCAwMDAwMCBuIAowMDAwMDkzMDYyIDAwMDAwIG4gCjAwMDAwOTMwOTkgMDAwMDAgbiAK MDAwMDA5MzkxMCAwMDAwMCBuIAowMDAwMDk0MjkyIDAwMDAwIG4gCjAwMDAwOTQ0MzcgMDAwMDAg biAKMDAwMDA5ODM2NyAwMDAwMCBuIAowMDAwMDk4Mzg3IDAwMDAwIG4gCjAwMDAwOTg0MDkgMDAw MDAgbiAKMDAwMDA5ODQ0NiAwMDAwMCBuIAowMDAwMDk5MjU3IDAwMDAwIG4gCjAwMDAxMjY2OTkg MDAwMDAgbiAKMDAwMDExNDYwOSAwMDAwMCBuIAowMDAwMTAwNjE3IDAwMDAwIG4gCjAwMDAwOTk3 MjIgMDAwMDAgbiAKMDAwMDExNDI2MCAwMDAwMCBuIAowMDAwMTAxMDkwIDAwMDAwIG4gCjAwMDAx MDEyMzUgMDAwMDAgbiAKMDAwMDEwNjY1NSAwMDAwMCBuIAowMDAwMTA2Njc1IDAwMDAwIG4gCjAw MDAxMDY2OTcgMDAwMDAgbiAKMDAwMDEwNjczNCAwMDAwMCBuIAowMDAwMTA3NTQ1IDAwMDAwIG4g CjAwMDAxMDc5MjkgMDAwMDAgbiAKMDAwMDEwODA3NCAwMDAwMCBuIAowMDAwMTEzMzQ5IDAwMDAw IG4gCjAwMDAxMTMzNjkgMDAwMDAgbiAKMDAwMDExMzM5MSAwMDAwMCBuIAowMDAwMTEzNDI4IDAw MDAwIG4gCjAwMDAxMTQyMzkgMDAwMDAgbiAKMDAwMDEyNjc2MSAwMDAwMCBuIAowMDAwMTE2MzAx IDAwMDAwIG4gCjAwMDAxMTQ3MzUgMDAwMDAgbiAKMDAwMDEyNjY0MiAwMDAwMCBuIAowMDAwMTY1 NTQ5IDAwMDAwIG4gCjAwMDAxMTY3NzEgMDAwMDAgbiAKMDAwMDExNjkxNiAwMDAwMCBuIAowMDAw MTI1NzMxIDAwMDAwIG4gCjAwMDAxMjU3NTEgMDAwMDAgbiAKMDAwMDEyNTc3MyAwMDAwMCBuIAow MDAwMTI1ODEwIDAwMDAwIG4gCjAwMDAxMjY2MjEgMDAwMDAgbiAKMDAwMDEyNzg3MSAwMDAwMCBu IAowMDAwMTI3NjQ1IDAwMDAwIG4gCjAwMDAxMjY4NjEgMDAwMDAgbiAKMDAwMDEyNzc1NyAwMDAw MCBuIAowMDAwMTI3ODE0IDAwMDAwIG4gCjAwMDAxMjc5NTQgMDAwMDAgbiAKMDAwMDEyNzk3NyAw MDAwMCBuIAowMDAwMTI4NDAyIDAwMDAwIG4gCjAwMDAxMjg4OTMgMDAwMDAgbiAKMDAwMDEyOTUx NiAwMDAwMCBuIAowMDAwMTM3MzQ3IDAwMDAwIG4gCjAwMDAxMzc2NDcgMDAwMDAgbiAKMDAwMDE0 NTgxMyAwMDAwMCBuIAowMDAwMTQ2MTQ2IDAwMDAwIG4gCjAwMDAxNjI3ODQgMDAwMDAgbiAKMDAw MDE2MzMxNiAwMDAwMCBuIAowMDAwMTY0NTIzIDAwMDAwIG4gCjAwMDAxNjU2MzQgMDAwMDAgbiAK MDAwMDE2NTcxMSAwMDAwMCBuIAowMDAwMTY2OTEzIDAwMDAwIG4gCjAwMDAxNjcwOTQgMDAwMDAg biAKMDAwMDE2NzI3MiAwMDAwMCBuIAowMDAwMTY3NDQyIDAwMDAwIG4gCjAwMDAxNjc2MDMgMDAw MDAgbiAKMDAwMDE2Nzc3NiAwMDAwMCBuIAowMDAwMTY3OTY2IDAwMDAwIG4gCjAwMDAxNjgxODYg MDAwMDAgbiAKMDAwMDE2ODMwNCAwMDAwMCBuIAowMDAwMTY4Mzg3IDAwMDAwIG4gCjAwMDAxNjg0 NzMgMDAwMDAgbiAKMDAwMDE2ODUxMSAwMDAwMCBuIAowMDAwMTY4NjM4IDAwMDAwIG4gCnRyYWls ZXIKPDwgL1NpemUgMjg0Ci9Sb290IDI4MiAwIFIKL0luZm8gMjgzIDAgUgovSUQgWzwyREY1Q0M2 RUZBN0VGNTFEOUU5QjRGMkQ4MENBQUE3RD4gPDJERjVDQzZFRkE3RUY1MUQ5RTlCNEYyRDgwQ0FB QTdEPl0gPj4Kc3RhcnR4cmVmCjE2ODk1MgolJUVPRgo= --Apple-Mail-33--246182827 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=US-ASCII
From: = "Rene Struik" <rstruik@certicom.com>
Date: December 22, 2009 7:36:50 AM = EST
To: "Jaudelice de Oliveira" <jau@ece.drexel.edu>
=
Subject: = RE: [Roll] Fwd: New Version Notification = fordraft-tripathi-roll-rpl-simulation-01

Hi = Jau:
Best = regards, Rene
From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Jaudelice de = Oliveira
Sent: Monday, December 21, 2009 = 11:12 PM
To: ROLL WG
Cc: Joydeep = Tripathi
Subject: [Roll] Fwd: New Version = Notification = fordraft-tripathi-roll-rpl-simulation-01
 
Dear = WG,
We have just posted = draft-tripathi-roll-rpl-simulation-01with a detailed performance = evaluation of RPL for several metrics of interest (please see PDF file = with plots). We are currently working on results with local repair and = shall post them shortly. We would love feedback/suggestions from the WG. = Are there other metrics you would like to = see?
Jaudelice C. = de Oliveira
<= /div>
 
 
A new version = of I-D, draft-tripathi-roll-rpl-simulation-01.txt has been successfuly = submitted by Jaudelice Oliveira and posted to the IETF = repository.
Filename:        <= span = class=3D"Apple-converted-space"> draft-tripathi-roll-rp= l-simulation
Revision:        <= span = class=3D"Apple-converted-space"> 01
Title:        &= nbsp;       Performance = Evaluation of Routing Protocol for Low Power and Lossy Networks = (RPL)
Creation_date:        &= nbsp;   2009-12-21<= /div>
WG ID:        &= nbsp;           &nb= sp;  Independent = Submission
Number_of_pages: = 12
This document presents a = performance evaluation of the Routing
Protocol for Low power and Lossy Networks (RPL).  Detailed
simulations are carried out to produce = several routing performance
metrics using a set of real-life = scenarios.
Status of this = Memo
This Internet-Draft is = submitted to IETF in full conformance with = the
provisions of BCP 78 and = BCP 79.
Internet-Drafts are = working documents of the Internet = Engineering
Task Force (IETF), its = areas, and its working groups.  Note = that
other groups may also = distribute working documents as = Internet-
Internet-Drafts are draft = documents valid for a maximum of six = months
and may be updated, = replaced, or obsoleted by other documents at = any
time.  It is inappropriate = to use Internet-Drafts as reference
material or to cite them other than as "work in = progress."
The list of current = Internet-Drafts can be accessed at
(http://trustee.ietf.org/license-info) = in effect on the date of
publication of this document.  Please review these = documents
carefully, as they = describe your rights and restrictions with = respect
to this document.  Code Components = extracted from this document must
include Simplified BSD License text as described in Section 4.e = of
the Trust Legal = Provisions and are provided without warranty = as
described in the BSD = License.
The IETF = Secretariat.
 
This transmission = (including any attachments) may contain confidential information, = privileged material (including material protected by the = solicitor-client or other applicable privileges), or constitute = non-public information. Any use of this information by anyone other than = the intended recipient is prohibited. If you have received this = transmission in error, please immediately reply to the sender and delete = this information from your system. Use, dissemination, distribution, or = reproduction of this transmission by unintended recipients is not = authorized and may be = unlawful.

= --Apple-Mail-33--246182827-- --Apple-Mail-32--246182828-- From stevedh@eecs.berkeley.edu Wed Dec 23 10:12:42 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1D8353A68E6 for ; Wed, 23 Dec 2009 10:12:42 -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=[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 2K9wABxlku5B for ; Wed, 23 Dec 2009 10:12:40 -0800 (PST) Received: from gateway0.EECS.Berkeley.EDU (gateway0.EECS.Berkeley.EDU [169.229.60.87]) by core3.amsl.com (Postfix) with ESMTP id 2BB023A67F6 for ; Wed, 23 Dec 2009 10:12:40 -0800 (PST) Received: from [192.168.1.4] (ool-18b86739.dyn.optonline.net [24.184.103.57]) (authenticated bits=0) by gateway0.EECS.Berkeley.EDU (8.14.3/8.13.5) with ESMTP id nBNICCVd015311 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 23 Dec 2009 10:12:14 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Stephen Dawson-Haggerty In-Reply-To: Date: Wed, 23 Dec 2009 13:12:12 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <16470B82-5A96-4959-9896-128594908DA3@eecs.berkeley.edu> References: <20091222035821.C522A3A6966@core3.amsl.com> To: Omprakash Gnawali X-Mailer: Apple Mail (2.1077) Cc: Joydeep Tripathi , ROLL WG Subject: Re: [Roll] Fwd: New Version Notification for draft-tripathi-roll-rpl-simulation-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, 23 Dec 2009 18:12:42 -0000 On Dec 23, 2009, at 2:52 AM, Omprakash Gnawali wrote: > I managed to find the pdf with the graphs. Here are some comments. >=20 > It will help greatly if more information about the link model were > included. -01 mentions: >=20 > "* Link failure model: Time varying real network traces containing > packet delivery probability for each > link and over all channels for both indoor network deployment and > outdoor network deployment were used. > Thus, di erent types of link characteristics are used in the study. > * Topology: The topologies are gathered from real-life deployment > (traces mentioned above) as opposed > to random topology simulations. are repeated here:" Also, it would be great if you could model link bandwidth and packet = collisions. When using low-bandwidth links these become very = significant, since each packet may take 5-500ms of air time to transmit.=20= Thanks for getting started on this! Steve >=20 > Is the simulation topology a topology from real-world deployment or > the one mentioned in figure 1? >=20 > Some graphs showing link characteristics (including temporal > characteristics) will also be helpful. Right now, we just know that > the link is modeled on real world deployments. What radio was used? > Indoor/outdoor? And any other relevant information. >=20 > These additional information will help us understand how and why of > RPL's performance. >=20 > A lot of people are interested in path stretch for p2p routing. Some > of this information is available on the plots but not directly. It > will be great if we can have a plot that shows the distribution of > path stretch for p2p routing. >=20 > - om_p >=20 > On Tue, Dec 22, 2009 at 11:09 PM, Omprakash Gnawali > wrote: >> It is great to start understanding how RPL would work. >>=20 >> On this file: >> http://tools.ietf.org/html/draft-tripathi-roll-rpl-simulation-00 >>=20 >> I don't see the figures... >>=20 >> - om_p >>=20 >> On Mon, Dec 21, 2009 at 8:12 PM, Jaudelice de Oliveira >> wrote: >>> Dear WG, >>> We have just posted draft-tripathi-roll-rpl-simulation-01with a = detailed >>> performance evaluation of RPL for several metrics of interest = (please see >>> PDF file with plots). We are currently working on results with local = repair >>> and shall post them shortly. We would love feedback/suggestions from = the WG. >>> Are there other metrics you would like to see? >>> Cheers, >>> Jau. >>>=20 >>>=20 >>>=20 >>>=20 >>> Jaudelice C. de Oliveira >>> Associate Professor >>> ECE Dept., Drexel University >>> http://www.ece.drexel.edu/faculty/deoliveira/ >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>> Begin forwarded message: >>>=20 >>> From: IETF I-D Submission Tool >>> Date: December 21, 2009 10:58:21 PM EST >>> To: jau@ece.drexel.edu >>> Cc: jt369@drexel.edu,jpv@cisco.com >>> Subject: New Version Notification for >>> draft-tripathi-roll-rpl-simulation-01 >>>=20 >>> A new version of I-D, draft-tripathi-roll-rpl-simulation-01.txt has = been >>> successfuly submitted by Jaudelice Oliveira and posted to the IETF >>> repository. >>> Filename: draft-tripathi-roll-rpl-simulation >>> Revision: 01 >>> Title: Performance Evaluation of Routing Protocol for Low Power and = Lossy >>> Networks (RPL) >>> Creation_date: 2009-12-21 >>> WG ID: Independent Submission >>> Number_of_pages: 12 >>> Abstract: >>> This document presents a performance evaluation of the Routing >>> Protocol for Low power and Lossy Networks (RPL). Detailed >>> simulations are carried out to produce several routing performance >>> metrics using a set of real-life scenarios. >>> Status of this Memo >>> This Internet-Draft is submitted to IETF in full conformance with = the >>> provisions of BCP 78 and BCP 79. >>> Internet-Drafts are working documents of the Internet Engineering >>> Task Force (IETF), its areas, and its working groups. Note that >>> other groups may also distribute working documents as Internet- >>> Drafts. >>> Internet-Drafts are draft documents valid for a maximum of six = months >>> and may be updated, replaced, or obsoleted by other documents at any >>> time. It is inappropriate to use Internet-Drafts as reference >>> material or to cite them other than as "work in progress." >>> The list of current Internet-Drafts can be accessed at >>> http://www.ietf.org/ietf/1id-abstracts.txt. >>> The list of Internet-Draft Shadow Directories can be accessed at >>> http://www.ietf.org/shadow.html. >>> This Internet-Draft will expire on June 24, 2010. >>> Copyright Notice >>> Copyright (c) 2009 IETF Trust and the persons identified as the >>> document authors. All rights reserved. >>> This document is subject to BCP 78 and the IETF Trust's Legal >>> Provisions Relating to IETF Documents >>> (http://trustee.ietf.org/license-info) in effect on the date of >>> publication of this document. Please review these documents >>> carefully, as they describe your rights and restrictions with = respect >>> to this document. Code Components extracted from this document must >>> include Simplified BSD License text as described in Section 4.e of >>> the Trust Legal Provisions and are provided without warranty as >>> described in the BSD License. >>>=20 >>>=20 >>> The IETF Secretariat. >>>=20 >>>=20 >>>=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 From tazaki@sfc.wide.ad.jp Wed Dec 23 16:26:27 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 060A23A67A6 for ; Wed, 23 Dec 2009 16:26:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.971 X-Spam-Level: ** X-Spam-Status: No, score=2.971 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RCVD_NUMERIC_HELO=2.067, RELAY_IS_203=0.994] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cadAA1zaIjbE for ; Wed, 23 Dec 2009 16:26:25 -0800 (PST) Received: from mail.sfc.wide.ad.jp (mail.sfc.wide.ad.jp [203.178.142.146]) by core3.amsl.com (Postfix) with ESMTP id 9913F3A67F1 for ; Wed, 23 Dec 2009 16:26:25 -0800 (PST) Received: from 222.249.10.10.in-addr.arpa.sfc.wide.ad.jp (i60-43-49-13.s30.a048.ap.plala.or.jp [60.43.49.13]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id CA5514CD25; Thu, 24 Dec 2009 09:26:02 +0900 (JST) Date: Thu, 24 Dec 2009 09:26:02 +0900 Message-ID: From: Hajime Tazaki To: gnawali@cs.stanford.edu In-Reply-To: References: <20091222035821.C522A3A6966@core3.amsl.com> User-Agent: Wanderlust/2.15.6 (Almost Unreal) Emacs/22.2 Mule/5.0 (SAKAKI) X-Face: "+?b:_s\r$dbBx'Ur*k#`5|~\>v~i`PzaxANTx_S?J>:mTQrtm:c7'f5b~W2eX~Fl[0Pw, 0bow)8r8Z5, D&>]C/'ujqr:fbY>]/52T^Q~cX*y5\?!"i<^Vp=zCNguAeyPH$`ZTv{di25X8, %@! MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: joydeep.tripathi@gmail.com, roll@ietf.org Subject: Re: [Roll] Fwd: New Version Notification for draft-tripathi-roll-rpl-simulation-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: Thu, 24 Dec 2009 00:28:43 -0000 Dear authors, I also really wanna see the pdf with figures. regards, hajime At Tue, 22 Dec 2009 23:09:59 -0800, Omprakash Gnawali wrote: > >It is great to start understanding how RPL would work. > >On this file: >http://tools.ietf.org/html/draft-tripathi-roll-rpl-simulation-00 > >I don't see the figures... > >- om_p > >On Mon, Dec 21, 2009 at 8:12 PM, Jaudelice de Oliveira > wrote: >> Dear WG, >> We have just posted draft-tripathi-roll-rpl-simulation-01with a detailed >> performance evaluation of RPL for several metrics of interest (please see >> PDF file with plots). We are currently working on results with local rep= air >> and shall post them shortly. We would love feedback/suggestions from the= WG. >> Are there other metrics you would like to see? >> Cheers, >> Jau. >> >> >> >> >> Jaudelice C. de Oliveira >> Associate Professor >> ECE Dept.,=A0Drexel University >> http://www.ece.drexel.edu/faculty/deoliveira/ >> >> >> >> >> >> Begin forwarded message: >> >> From: IETF I-D Submission Tool >> Date: December 21, 2009 10:58:21 PM EST >> To: jau@ece.drexel.edu >> Cc: jt369@drexel.edu,jpv@cisco.com >> Subject: New Version Notification for >> draft-tripathi-roll-rpl-simulation-01 >> >> A new version of I-D, draft-tripathi-roll-rpl-simulation-01.txt has been >> successfuly submitted by Jaudelice Oliveira and posted to the IETF >> repository. >> Filename: draft-tripathi-roll-rpl-simulation >> Revision: 01 >> Title: Performance Evaluation of Routing Protocol for Low Power and Lossy >> Networks (RPL) >> Creation_date: 2009-12-21 >> WG ID: Independent Submission >> Number_of_pages: 12 >> Abstract: >> This document presents a performance evaluation of the Routing >> Protocol for Low power and Lossy Networks (RPL).=A0 Detailed >> simulations are carried out to produce several routing performance >> metrics using a set of real-life scenarios. >> Status of this Memo >> This Internet-Draft is submitted to IETF in full conformance with the >> provisions of BCP 78 and BCP 79. >> Internet-Drafts are working documents of the Internet Engineering >> Task Force (IETF), its areas, and its working groups.=A0 Note that >> other groups may also distribute working documents as Internet- >> Drafts. >> Internet-Drafts are draft documents valid for a maximum of six months >> and may be updated, replaced, or obsoleted by other documents at any >> time.=A0 It is inappropriate to use Internet-Drafts as reference >> material or to cite them other than as "work in progress." >> The list of current Internet-Drafts can be accessed at >> http://www.ietf.org/ietf/1id-abstracts.txt. >> The list of Internet-Draft Shadow Directories can be accessed at >> http://www.ietf.org/shadow.html. >> This Internet-Draft will expire on June 24, 2010. >> Copyright Notice >> Copyright (c) 2009 IETF Trust and the persons identified as the >> document authors.=A0 All rights reserved. >> This document is subject to BCP 78 and the IETF Trust's Legal >> Provisions Relating to IETF Documents >> (http://trustee.ietf.org/license-info) in effect on the date of >> publication of this document.=A0 Please review these documents >> carefully, as they describe your rights and restrictions with respect >> to this document.=A0 Code Components extracted from this document must >> include Simplified BSD License text as described in Section 4.e of >> the Trust Legal Provisions and are provided without warranty as >> described in the BSD License. >> >> >> 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 joydeep.tripathi@gmail.com Wed Dec 23 22:24:57 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9B9DE3A68AB for ; Wed, 23 Dec 2009 22:24:56 -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 B5gsPsuC20ky for ; Wed, 23 Dec 2009 22:24:45 -0800 (PST) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.26]) by core3.amsl.com (Postfix) with ESMTP id 7D17D3A67AD for ; Wed, 23 Dec 2009 22:24:44 -0800 (PST) Received: by ey-out-2122.google.com with SMTP id 22so716715eye.51 for ; Wed, 23 Dec 2009 22:24:23 -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:content-type :content-transfer-encoding; bh=48XzvWAc1+DdzCMpj7cY3zNdP9jorkQkwIdWqUe/+yA=; b=SAnsTcbWZMBMsQcOPmx6aKiIucBHSGsJRVL3PyXSsxGrBXks/Z6U5kM4gPHZ/30L+Y 9BillMeIuGjxVnShwlK8h7mAukom+7etaQtJsYa2fgH+be6IdUwtgRvqMXajoKNM/JtS V6KyQFTVbOYBqbLyIXXSwJUcqPENn3Cdf7P0A= 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=N8LOSju6qS8yyzBqn9jD7Ry9ubNyDeBaK3rTV88dfV8eWXpst3GRZkOaB6Jz9QT8WY dbZ/8lJkuXB4HFvEwh3EP/tgyIcuJ8SOloLY9XLY2wJKTCVw6JWOHwGh7a6wYFtQX0PE XCuQTt8q3NUT3rjGj3yfz+6L1jrCu17aF0MxE= MIME-Version: 1.0 Received: by 10.216.85.132 with SMTP id u4mr534499wee.191.1261635863398; Wed, 23 Dec 2009 22:24:23 -0800 (PST) In-Reply-To: References: <20091222035821.C522A3A6966@core3.amsl.com> Date: Thu, 24 Dec 2009 01:24:23 -0500 Message-ID: From: Joydeep Tripathi To: roll@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [Roll] Fwd: New Version Notification for draft-tripathi-roll-rpl-simulation-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: Thu, 24 Dec 2009 06:24:57 -0000 Hi, For those who cannot find the pdf version, you can click this link http://tools.ietf.org/pdf/draft-tripathi-roll-rpl-simulation-01.pdf Thanks, Joydeep > > On Wed, Dec 23, 2009 at 7:26 PM, Hajime Tazaki wr= ote: >> >> Dear authors, >> >> I also really wanna see the pdf with figures. >> >> regards, >> hajime >> >> At Tue, 22 Dec 2009 23:09:59 -0800, >> Omprakash Gnawali wrote: >>> >>>It is great to start understanding how RPL would work. >>> >>>On this file: >>>http://tools.ietf.org/html/draft-tripathi-roll-rpl-simulation-00 >>> >>>I don't see the figures... >>> >>>- om_p >>> >>>On Mon, Dec 21, 2009 at 8:12 PM, Jaudelice de Oliveira >>> wrote: >>>> Dear WG, >>>> We have just posted draft-tripathi-roll-rpl-simulation-01with a detail= ed >>>> performance evaluation of RPL for several metrics of interest (please = see >>>> PDF file with plots). We are currently working on results with local r= epair >>>> and shall post them shortly. We would love feedback/suggestions from t= he WG. >>>> Are there other metrics you would like to see? >>>> Cheers, >>>> Jau. >>>> >>>> >>>> >>>> >>>> Jaudelice C. de Oliveira >>>> Associate Professor >>>> ECE Dept.,=A0Drexel University >>>> http://www.ece.drexel.edu/faculty/deoliveira/ >>>> >>>> >>>> >>>> >>>> >>>> Begin forwarded message: >>>> >>>> From: IETF I-D Submission Tool >>>> Date: December 21, 2009 10:58:21 PM EST >>>> To: jau@ece.drexel.edu >>>> Cc: jt369@drexel.edu,jpv@cisco.com >>>> Subject: New Version Notification for >>>> draft-tripathi-roll-rpl-simulation-01 >>>> >>>> A new version of I-D, draft-tripathi-roll-rpl-simulation-01.txt has be= en >>>> successfuly submitted by Jaudelice Oliveira and posted to the IETF >>>> repository. >>>> Filename: draft-tripathi-roll-rpl-simulation >>>> Revision: 01 >>>> Title: Performance Evaluation of Routing Protocol for Low Power and Lo= ssy >>>> Networks (RPL) >>>> Creation_date: 2009-12-21 >>>> WG ID: Independent Submission >>>> Number_of_pages: 12 >>>> Abstract: >>>> This document presents a performance evaluation of the Routing >>>> Protocol for Low power and Lossy Networks (RPL).=A0 Detailed >>>> simulations are carried out to produce several routing performance >>>> metrics using a set of real-life scenarios. >>>> Status of this Memo >>>> This Internet-Draft is submitted to IETF in full conformance with the >>>> provisions of BCP 78 and BCP 79. >>>> Internet-Drafts are working documents of the Internet Engineering >>>> Task Force (IETF), its areas, and its working groups.=A0 Note that >>>> other groups may also distribute working documents as Internet- >>>> Drafts. >>>> Internet-Drafts are draft documents valid for a maximum of six months >>>> and may be updated, replaced, or obsoleted by other documents at any >>>> time.=A0 It is inappropriate to use Internet-Drafts as reference >>>> material or to cite them other than as "work in progress." >>>> The list of current Internet-Drafts can be accessed at >>>> http://www.ietf.org/ietf/1id-abstracts.txt. >>>> The list of Internet-Draft Shadow Directories can be accessed at >>>> http://www.ietf.org/shadow.html. >>>> This Internet-Draft will expire on June 24, 2010. >>>> Copyright Notice >>>> Copyright (c) 2009 IETF Trust and the persons identified as the >>>> document authors.=A0 All rights reserved. >>>> This document is subject to BCP 78 and the IETF Trust's Legal >>>> Provisions Relating to IETF Documents >>>> (http://trustee.ietf.org/license-info) in effect on the date of >>>> publication of this document.=A0 Please review these documents >>>> carefully, as they describe your rights and restrictions with respect >>>> to this document.=A0 Code Components extracted from this document must >>>> include Simplified BSD License text as described in Section 4.e of >>>> the Trust Legal Provisions and are provided without warranty as >>>> described in the BSD License. >>>> >>>> >>>> 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 joydeep.tripathi@gmail.com Wed Dec 23 22:25:07 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 823F43A68EF for ; Wed, 23 Dec 2009 22:25:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.282 X-Spam-Level: X-Spam-Status: No, score=-2.282 tagged_above=-999 required=5 tests=[AWL=-0.283, BAYES_00=-2.599, J_CHICKENPOX_82=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8y2lje9fvkgM for ; Wed, 23 Dec 2009 22:25:05 -0800 (PST) Received: from mail-ew0-f214.google.com (mail-ew0-f214.google.com [209.85.219.214]) by core3.amsl.com (Postfix) with ESMTP id 2338A3A68AB for ; Wed, 23 Dec 2009 22:25:01 -0800 (PST) Received: by ewy6 with SMTP id 6so5997176ewy.29 for ; Wed, 23 Dec 2009 22:24:41 -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:content-type :content-transfer-encoding; bh=uBQgBqM17IEniJ6aJ2uSkesWjj8u9sIj+JoRw0cLQOo=; b=MjOF6mOWcrLYNB0vw/Ldgi8/yAsLXGOsljwgoLDHCfh7WKZe2icJCgN8gSOT0Lr4u3 UZlqL8RlfAwmPcLWzk5mqbBloxyIV+gakuh1e6yRhtnVYm2+r3w0/HT8cDYI5JKoD2Fs +dMGZUgwFYJxpkKgwqbW035jNoCsPBRXY8T7k= 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=XLgLVMkkC04zstd2NxhtVtT3s/YJ0t0fBO8PKR3ilX8P5IzYM2CGArJKBvDqIJ5lR1 alajDJ3G/6wYLA1mNaBUZ3QoUPjnaZWwwAP3wx5TzPUyY82wrFL8rUK4YBq6dEry2llX C8dhL/cDo/ofr24n0/e4kmnIpRG/MRj760SeQ= MIME-Version: 1.0 Received: by 10.216.90.13 with SMTP id d13mr3723591wef.130.1261635881268; Wed, 23 Dec 2009 22:24:41 -0800 (PST) In-Reply-To: References: <20091222035821.C522A3A6966@core3.amsl.com> Date: Thu, 24 Dec 2009 01:24:41 -0500 Message-ID: From: Joydeep Tripathi To: ROLL WG Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [Roll] Fwd: New Version Notification for draft-tripathi-roll-rpl-simulation-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: Thu, 24 Dec 2009 06:25:07 -0000 On Wed, Dec 23, 2009 at 2:52 AM, Omprakash Gnawali wrote: > > I managed to find the pdf with the graphs. Here are some comments. > > It will help greatly if more information about the link model were > included. -01 mentions: > > "* Link failure model: Time varying real network traces containing > packet delivery probability for each > link and over all channels for both indoor network deployment and > outdoor network deployment were used. > Thus, di erent types of link characteristics are used in the study. > * Topology: The topologies are gathered from real-life deployment > (traces mentioned above) as opposed > to random topology simulations. are repeated here:" > Actually,we collected real-life traces with hundreds of links varying with time for the network,=A0 and simulated the same variation in PDR for each link as in the real deployment. > > Is the simulation topology a topology from real-world deployment or > the one mentioned in figure 1? It is indeed from a real life deployment of an indoor network, where the topology looks like the one shown in figure 1. We have shown a link between two nodes in the topology if they are heard by each other. > > Some graphs showing link characteristics (including temporal > characteristics) will also be helpful. Right now, we just know that > the link is modeled on real world deployments. What radio was used? > Indoor/outdoor? And any other relevant information. That is a wonderful idea. We will include temporal link characteristics in further revision which we plan to submit very soon. > These additional information will help us understand how and why of > RPL's performance. > > A lot of people are interested in path stretch for p2p routing. Some > of this information is available on the plots but not directly. It > will be great if we can have a plot that shows the distribution of > path stretch for p2p routing. We also plan to show this metric, keeping in mind the typical scenarios of P2P routing in building and home routing (or any other interesting scenario, on request). Once again, thanks for your feedback. Thanks, Joydeep > > - om_p >> > > > On Mon, Dec 21, 2009 at 8:12 PM, Jaudelice de Oliveira > > wrote: > >> Dear WG, >> >> We have just posted draft-tripathi-roll-rpl-simulation-01with a >> >> detailed >> >> performance evaluation of RPL for several metrics of interest (please >> >> see >> >> PDF file with plots). We are currently working on results with local >> >> repair >> >> and shall post them shortly. We would love feedback/suggestions from >> >> the WG. >> >> Are there other metrics you would like to see? >> >> Cheers, >> >> Jau. >> >> >> >> >> >> >> >> >> >> Jaudelice C. de Oliveira >> >> Associate Professor >> >> ECE Dept.,=A0Drexel University >> >> http://www.ece.drexel.edu/faculty/deoliveira/ >> >> >> >> >> >> >> >> >> >> >> >> Begin forwarded message: >> >> >> >> From: IETF I-D Submission Tool >> >> Date: December 21, 2009 10:58:21 PM EST >> >> To: jau@ece.drexel.edu >> >> Cc: jt369@drexel.edu,jpv@cisco.com >> >> Subject: New Version Notification for >> >> draft-tripathi-roll-rpl-simulation-01 >> >> >> >> A new version of I-D, draft-tripathi-roll-rpl-simulation-01.txt has >> >> been >> >> successfuly submitted by Jaudelice Oliveira and posted to the IETF >> >> repository. >> >> Filename: draft-tripathi-roll-rpl-simulation >> >> Revision: 01 >> >> Title: Performance Evaluation of Routing Protocol for Low Power and >> >> Lossy >> >> Networks (RPL) >> >> Creation_date: 2009-12-21 >> >> WG ID: Independent Submission >> >> Number_of_pages: 12 >> >> Abstract: >> >> This document presents a performance evaluation of the Routing >> >> Protocol for Low power and Lossy Networks (RPL).=A0 Detailed >> >> simulations are carried out to produce several routing performance >> >> metrics using a set of real-life scenarios. >> >> Status of this Memo >> >> This Internet-Draft is submitted to IETF in full conformance with the >> >> provisions of BCP 78 and BCP 79. >> >> Internet-Drafts are working documents of the Internet Engineering >> >> Task Force (IETF), its areas, and its working groups.=A0 Note that >> >> other groups may also distribute working documents as Internet- >> >> Drafts. >> >> Internet-Drafts are draft documents valid for a maximum of six months >> >> and may be updated, replaced, or obsoleted by other documents at any >> >> time.=A0 It is inappropriate to use Internet-Drafts as reference >> >> material or to cite them other than as "work in progress." >> >> The list of current Internet-Drafts can be accessed at >> >> http://www.ietf.org/ietf/1id-abstracts.txt. >> >> The list of Internet-Draft Shadow Directories can be accessed at >> >> http://www.ietf.org/shadow.html. >> >> This Internet-Draft will expire on June 24, 2010. >> >> Copyright Notice >> >> Copyright (c) 2009 IETF Trust and the persons identified as the >> >> document authors.=A0 All rights reserved. >> >> This document is subject to BCP 78 and the IETF Trust's Legal >> >> Provisions Relating to IETF Documents >> >> (http://trustee.ietf.org/license-info) in effect on the date of >> >> publication of this document.=A0 Please review these documents >> >> carefully, as they describe your rights and restrictions with respect >> >> to this document.=A0 Code Components extracted from this document mus= t >> >> include Simplified BSD License text as described in Section 4.e of >> >> the Trust Legal Provisions and are provided without warranty as >> >> described in the BSD License. >> >> >> >> >> >> The IETF Secretariat. >> >> >> >> >> >> >> >> _______________________________________________ >> >> Roll mailing list >> >> Roll@ietf.org >> >> https://www.ietf.org/mailman/listinfo/roll >> >> >> >> >> > > > From pal@cs.stanford.edu Tue Dec 29 12:07:07 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 06F163A6808 for ; Tue, 29 Dec 2009 12:07:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.196 X-Spam-Level: X-Spam-Status: No, score=-5.196 tagged_above=-999 required=5 tests=[AWL=-1.197, 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 3zxAHRqbS+QN for ; Tue, 29 Dec 2009 12:07:06 -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 1C29B3A6927 for ; Tue, 29 Dec 2009 12:07:06 -0800 (PST) Received: from [76.14.71.8] (helo=[192.168.1.103]) by cs-smtp-2.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1NPiL7-0000Nh-ES; Tue, 29 Dec 2009 12:06:45 -0800 Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Philip Levis In-Reply-To: <87hbrju07x.fsf@kelsey-ws.hq.ember.com> Date: Tue, 29 Dec 2009 12:06:44 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <3C0BFC81-8F24-49B1-9804-9BD51201D180@cs.stanford.edu> References: <7FA5EF01-E149-4D8C-91F1-A16898FC0D54@cisco.com> <87k4wgsb6g.fsf@kelsey-ws.hq.ember.com> <87hbrju07x.fsf@kelsey-ws.hq.ember.com> To: Richard Kelsey X-Mailer: Apple Mail (2.1077) X-Scan-Signature: daeb03f1a6494d8fe08e106a714ef916 Cc: roll@ietf.org Subject: Re: [Roll] DIO DAGRank field X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 29 Dec 2009 20:07:07 -0000 On Dec 21, 2009, at 8:00 PM, Richard Kelsey wrote: >> From: JP Vasseur >> Date: Mon, 21 Dec 2009 14:41:10 +0100 >>=20 >> On Dec 21, 2009, at 2:34 PM, Richard Kelsey wrote: >>=20 >>> Yes, there is a latency metric with a 32-bit floating point >>> latency in milliseconds. >>=20 >> We can certainly change the way we encode this metric and others. >>=20 >>> It seems silly to have that much >>> precision and range in the metric and then use an 8-bit >>> rank. >>=20 >> They may not be correlated at all, the rank only being >> used for "loop management" and the latency for path >> computation. >=20 > This has been gone over in detail before on this list. The > rank trumps the metric. It may only be for "loop > management", but if the rank makes a neighbor ineligble as a > parent, it doesn't matter what the neighbor's metric is, > the neighbor cannot be a parent. >=20 >>> For a DAG based on latency you need to pick the >>> latency that corresponds to a rank increase of one. >>=20 >> Why ? >=20 > To minimize the discrepancy between the metric and the rank. > The set of possible parents is based on rank, not metric. > If the metric and rank are not in sync, then the best > parents according to the metric may easily not be in the set > of possible parents allowed by the rank. >=20 >>> Here >>> are some possibilities: >>>=20 >>> latency per rank increment 10ms 30ms 100ms >>> maximum path latency 2.5 sec 7.5 sec 25 sec >>>=20 >>> For a very low power 802.15.4 network, a maximum path >>> latency of 25 seconds seems none too high. At the same >>> time, a pair of line-powered 802.15.4 neighbors should have >>> a latency of 30ms or less. All that range in the metric >>> doesn't help because it gets lost in the translation to >>> the rank. >>=20 >> But it does not have to be translated to the rank at all ? >=20 > If the latency is not translated into the rank then > the DAG will not optimize latency. RPL optimizes rank > first and metric second. Richard -- I agree with your analysis of Rank. Right now it seems to be = a bit vague, and operating under the assumption that we'll figure it out = later. It is a mix of a logical property for loop avoidance and a route = quality property. It should be clearly one or the other. At the very = least, if we follow the current hybrid approach, there need to be = constraints on how much Rank can increment on each hop, and this value = needs to be considered in the field width. For example, with OF0 it's a = bit strange that two neighbors, both of whom have a hopcount of 2, can = have Ranks of 2 and 32. I'm also a bit worried as to how Rank will = translate from highly variable metrics such as latency, or decreasing = metrics, such as a throughput. These are the kinds of things we should be discussing and resolving with = respect to the draft. Before we start adding additional mechanisms for = optimization, we need to make sure the existing ones are sound and = effective. It seems to me that RPL would be much simpler if there were a strong = division between Rank and metric, with the former being used for loop = avoidance and detection and the latter being used for route = optimization. It would, at the very least, simplify route selection and = OF definition. Phil= From joydeep.tripathi@gmail.com Tue Dec 29 15:58:57 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 59E0B3A6966 for ; Tue, 29 Dec 2009 15:58:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.925 X-Spam-Level: X-Spam-Status: No, score=-0.925 tagged_above=-999 required=5 tests=[AWL=-1.526, BAYES_50=0.001, J_CHICKENPOX_82=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I11KllXpo5br for ; Tue, 29 Dec 2009 15:58:56 -0800 (PST) Received: from mail-bw0-f223.google.com (mail-bw0-f223.google.com [209.85.218.223]) by core3.amsl.com (Postfix) with ESMTP id 506BD3A690F for ; Tue, 29 Dec 2009 15:58:56 -0800 (PST) Received: by bwz23 with SMTP id 23so7513927bwz.29 for ; Tue, 29 Dec 2009 15:58: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:content-type :content-transfer-encoding; bh=bAfF4WK10Q+6W+BFnD5r9FSaN3sDgm0yR1Bhkr9Hf2c=; b=pRa7g9K/h2oQjDOc/8B3dB6WD+dQlGLgTwbalguHm/MGfolE1MfUREuCr/t91FJccU Xu1K7fnLPnmyGlwdyMlknb4AR3P9mN6KS8G7FK94PgnOCZURxGQ5SDFWWgOI5yb+Ap10 KPgN9+8k/fdrTPqUX5H36RNT/NGDjBzCZzlgU= 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=uP9r0Qvk+LO6MrCMqA1t4jpAXEDboHDa105wRXBsP5Iq0QuzB4DmDu8W9tpD4ZnEP4 OR+viDCAzQij2OLvePaLUW56P76hLyccwkTKANgwqVRVUTeWvErHtePRx3UqmfIhokxU fJH/tFcxbCZeqMm3oReIpph1Cz1YIrwdpnEVw= MIME-Version: 1.0 Received: by 10.204.2.73 with SMTP id 9mr3777918bki.159.1262131113703; Tue, 29 Dec 2009 15:58:33 -0800 (PST) In-Reply-To: <32377771-299D-41B6-98A4-02AF14167D99@cs.stanford.edu> References: <20091222035821.C522A3A6966@core3.amsl.com> <32377771-299D-41B6-98A4-02AF14167D99@cs.stanford.edu> Date: Tue, 29 Dec 2009 18:58:33 -0500 Message-ID: From: Joydeep Tripathi To: Philip Levis , ROLL WG Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [Roll] Fwd: New Version Notification for draft-tripathi-roll-rpl-simulation-01 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Dec 2009 23:58:57 -0000 Hi, On Thu, Dec 24, 2009 at 2:25 AM, Philip Levis wrote: > > On Dec 23, 2009, at 10:24 PM, Joydeep Tripathi wrote: > >> On Wed, Dec 23, 2009 at 2:52 AM, Omprakash Gnawali >> >> =A0wrote: >>> >>> I managed to find the pdf with the graphs. Here are some comments. >>> >>> It will help greatly if more information about the link model were >>> included. -01 mentions: >>> >>> "* Link failure model: Time varying real network traces containing >>> packet delivery probability for each >>> link and over all channels for both indoor network deployment and >>> outdoor network deployment were used. >>> Thus, di erent types of link characteristics are used in the study. >>> * Topology: The topologies are gathered from real-life deployment >>> (traces mentioned above) as opposed >>> to random topology simulations. are repeated here:" >>> >> Actually,we collected real-life traces with hundreds of links varying >> with time for the network, =A0and simulated the same variation in PDR >> for each link as in the real deployment. > > I don't understand -- how do you do this? There has to be some interval o= ver > which you average, unless you are replaying success/failure traces. Link = can > very much faster than every ten seconds. Actually you are right, the PDR value of a link is averaged over 100 packets over an interval. When the trace was gathered, during each 15 minutes interval, 100 packets are transmitted over a link in the network. Out of 100 packets, number of successfully received packets was count for each link between two communicating nodes that are physically one hop away. The number of successfully received packets out of 100 packets originally transmitted was recorded as the PDR of the link after each 15 minutes interval. In our simulation, we consider the PDR between those two nodes to be constant during a 10 minutes interval. When an interval gets over, we consider the next PDR value between same two nodes in the database of traces, that was collected during the next interval and use that value for next interval. I hope this clarifies how the link quality traces are gathered and used. Please let me know if you have further questions. Thanks, Joydeep > > Phil > > From gnawali@cs.stanford.edu Tue Dec 29 16:17:56 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7EDBE3A691A for ; Tue, 29 Dec 2009 16:17:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.277 X-Spam-Level: X-Spam-Status: No, score=-4.277 tagged_above=-999 required=5 tests=[AWL=-1.500, BAYES_50=0.001, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_82=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 46QfY999QbJy for ; Tue, 29 Dec 2009 16:17:55 -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 AF6AE3A68E7 for ; Tue, 29 Dec 2009 16:17:55 -0800 (PST) Received: from qw-out-2122.google.com ([74.125.92.25]) by cs-smtp-2.Stanford.EDU with esmtpsa (TLSv1:RC4-MD5:128) (Exim 4.60) (envelope-from ) id 1NPmFr-0007pb-JE for roll@ietf.org; Tue, 29 Dec 2009 16:17:36 -0800 Received: by qw-out-2122.google.com with SMTP id 9so2539375qwb.31 for ; Tue, 29 Dec 2009 16:17:34 -0800 (PST) MIME-Version: 1.0 Received: by 10.224.84.197 with SMTP id k5mr2206688qal.204.1262132254661; Tue, 29 Dec 2009 16:17:34 -0800 (PST) In-Reply-To: References: <20091222035821.C522A3A6966@core3.amsl.com> <32377771-299D-41B6-98A4-02AF14167D99@cs.stanford.edu> Date: Tue, 29 Dec 2009 19:17:34 -0500 Message-ID: From: Omprakash Gnawali To: Joydeep Tripathi Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Scan-Signature: 1c1d34d4ae2aac1d1f929c6f17b0cb0c Cc: ROLL WG Subject: Re: [Roll] Fwd: New Version Notification for draft-tripathi-roll-rpl-simulation-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, 30 Dec 2009 00:17:56 -0000 On Tue, Dec 29, 2009 at 6:58 PM, Joydeep Tripathi wrote: > Hi, > > On Thu, Dec 24, 2009 at 2:25 AM, Philip Levis wrote= : >> >> On Dec 23, 2009, at 10:24 PM, Joydeep Tripathi wrote: >> >>> On Wed, Dec 23, 2009 at 2:52 AM, Omprakash Gnawali >>> >>> =A0wrote: >>>> >>>> I managed to find the pdf with the graphs. Here are some comments. >>>> >>>> It will help greatly if more information about the link model were >>>> included. -01 mentions: >>>> >>>> "* Link failure model: Time varying real network traces containing >>>> packet delivery probability for each >>>> link and over all channels for both indoor network deployment and >>>> outdoor network deployment were used. >>>> Thus, di erent types of link characteristics are used in the study. >>>> * Topology: The topologies are gathered from real-life deployment >>>> (traces mentioned above) as opposed >>>> to random topology simulations. are repeated here:" >>>> >>> Actually,we collected real-life traces with hundreds of links varying >>> with time for the network, =A0and simulated the same variation in PDR >>> for each link as in the real deployment. >> >> I don't understand -- how do you do this? There has to be some interval = over >> which you average, unless you are replaying success/failure traces. Link= can >> very much faster than every ten seconds. > > Actually you are right, the PDR value of a link is averaged over 100 > packets over an interval. When the trace was gathered, during each 15 > minutes interval, 100 packets are transmitted over a link in the > network. Out of 100 packets, number of successfully received packets > was count for each link between two communicating nodes that are > physically one hop away. The number of successfully received packets > out of 100 packets originally transmitted was recorded as the PDR of > the link after each 15 minutes interval. In our simulation, we > consider the PDR between those two nodes to be constant during a 10 > minutes interval. When an interval gets over, we consider the next PDR > value between same two nodes in the database of traces, that was > collected during the next interval and use that value for next > interval. > > I hope this clarifies how the link quality traces are gathered and > used. Please let me know if you have further questions. Each node sends a packet every 9 seconds to estimate the link quality and the estimate is updated every 100 packets? Do you consider datarate in your simulation? I did not understand why data collection uses a window of 15 mins and data use uses a window of 10 mins. - om_p From joydeep.tripathi@gmail.com Tue Dec 29 17:12:23 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8EA013A6863 for ; Tue, 29 Dec 2009 17:12:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.971 X-Spam-Level: X-Spam-Status: No, score=-1.971 tagged_above=-999 required=5 tests=[AWL=0.028, BAYES_00=-2.599, J_CHICKENPOX_82=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Aodr0fvJvRQc for ; Tue, 29 Dec 2009 17:12:22 -0800 (PST) Received: from mail-bw0-f223.google.com (mail-bw0-f223.google.com [209.85.218.223]) by core3.amsl.com (Postfix) with ESMTP id 455693A67A1 for ; Tue, 29 Dec 2009 17:12:22 -0800 (PST) Received: by bwz23 with SMTP id 23so7532239bwz.29 for ; Tue, 29 Dec 2009 17:11:59 -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:content-type :content-transfer-encoding; bh=ojOqQtutptSAXNTVTpad10T8T52o1IA+JDxCI0itxjw=; b=epyFotMLyiIqKL/61mDH1sWDypqtdxVbzbJOvKqOcfk2qHpEIp09BmXPW/rZvykG/n ebCqyv4JwiXbScP3csX+CJQ2JvaNURZHnA0yUpj+sFn9eCJO3t6kndlVqNkNwtdrj2E6 vRSRg3qSNBU00NSxS1J0aq7YsM05dzsZd0X1Q= 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=JYK1fsSj6dqov6lF5bW9loanxBdx9gOPvnq5iSvRF8ln0afBiGgeJdiV8t4jMKPrqd 03WIfsaLeKC87Jb5QgLay2WawTeJjaH1qegIDtXZgDB9j35wzkNfzzeNrV08UpYstRPD 9ZMoPPl+3ex3cvEqRhAw9JKr9Pw6sI/GR+U4Y= MIME-Version: 1.0 Received: by 10.204.5.207 with SMTP id 15mr8447362bkw.89.1262135519426; Tue, 29 Dec 2009 17:11:59 -0800 (PST) In-Reply-To: References: <20091222035821.C522A3A6966@core3.amsl.com> <32377771-299D-41B6-98A4-02AF14167D99@cs.stanford.edu> Date: Tue, 29 Dec 2009 20:11:59 -0500 Message-ID: From: Joydeep Tripathi To: Omprakash Gnawali , ROLL WG Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [Roll] Fwd: New Version Notification for draft-tripathi-roll-rpl-simulation-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, 30 Dec 2009 01:12:23 -0000 On Tue, Dec 29, 2009 at 7:17 PM, Omprakash Gnawali wrote: > On Tue, Dec 29, 2009 at 6:58 PM, Joydeep Tripathi > wrote: >> Hi, >> >> On Thu, Dec 24, 2009 at 2:25 AM, Philip Levis wrot= e: >>> >>> On Dec 23, 2009, at 10:24 PM, Joydeep Tripathi wrote: >>> >>>> On Wed, Dec 23, 2009 at 2:52 AM, Omprakash Gnawali >>>> >>>> =A0wrote: >>>>> >>>>> I managed to find the pdf with the graphs. Here are some comments. >>>>> >>>>> It will help greatly if more information about the link model were >>>>> included. -01 mentions: >>>>> >>>>> "* Link failure model: Time varying real network traces containing >>>>> packet delivery probability for each >>>>> link and over all channels for both indoor network deployment and >>>>> outdoor network deployment were used. >>>>> Thus, di erent types of link characteristics are used in the study. >>>>> * Topology: The topologies are gathered from real-life deployment >>>>> (traces mentioned above) as opposed >>>>> to random topology simulations. are repeated here:" >>>>> >>>> Actually,we collected real-life traces with hundreds of links varying >>>> with time for the network, =A0and simulated the same variation in PDR >>>> for each link as in the real deployment. >>> >>> I don't understand -- how do you do this? There has to be some interval= over >>> which you average, unless you are replaying success/failure traces. Lin= k can >>> very much faster than every ten seconds. >> >> Actually you are right, the PDR value of a link is averaged over 100 >> packets over an interval. When the trace was gathered, during each 15 >> minutes interval, 100 packets are transmitted over a link in the >> network. Out of 100 packets, number of successfully received packets >> was count for each link between two communicating nodes that are >> physically one hop away. The number of successfully received packets >> out of 100 packets originally transmitted was recorded as the PDR of >> the link after each 15 minutes interval. In our simulation, we >> consider the PDR between those two nodes to be constant during a 10 >> minutes interval. When an interval gets over, we consider the next PDR >> value between same two nodes in the database of traces, that was >> collected during the next interval and use that value for next >> interval. >> >> I hope this clarifies how the link quality traces are gathered and >> used. Please let me know if you have further questions. > > Each node sends a packet every 9 seconds to estimate the link quality > and the estimate is updated every 100 packets? > > Do you consider datarate in your simulation? When the link trace was gathered, I believe the intention was to check how the connectivity between the nodes vary over time. The trace reflects the quality of the links between the nodes, and the packets used for trace gathering in real implementation did not use RPL headers. However, in our simulation, we considered RPL headers, MAC headers etc. For simulation, we also used specifications of TelosB CC2420 radio, which has a datarate of 250 Kbps. > I did not understand why data collection uses a window of 15 mins and > data use uses a window of 10 mins. The simulation used a 10 minute window to update PDR for every link. However, in simulation also, the links have same temporal characteristics as seen in the real link quality trace gathering. The 10 minutes interval is just to make the simulation generic to other gathered traces from other deployment as well. There may be traces which update the link quality after an interval other than 15 minutes (we do have such traces). We will include samples of link quality (in terms of PDR) in our next revision as well. > > - om_p > From pal@cs.stanford.edu Tue Dec 29 18:19:43 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 62C4F3A69FE for ; Tue, 29 Dec 2009 18:19:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.11 X-Spam-Level: X-Spam-Status: No, score=-6.11 tagged_above=-999 required=5 tests=[AWL=-0.111, BAYES_00=-2.599, J_CHICKENPOX_82=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nt9mkeHpORc0 for ; Tue, 29 Dec 2009 18:19:42 -0800 (PST) Received: from cs-smtp-1.Stanford.EDU (cs-smtp-1.Stanford.EDU [171.64.64.25]) by core3.amsl.com (Postfix) with ESMTP id 6A4E03A6817 for ; Tue, 29 Dec 2009 18:19:42 -0800 (PST) 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 1NPo9i-0005rp-I0; Tue, 29 Dec 2009 18:19:23 -0800 Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Philip Levis In-Reply-To: Date: Tue, 29 Dec 2009 18:19:20 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <116063A6-3486-428E-A94E-B7C02BCA4AEE@cs.stanford.edu> References: <20091222035821.C522A3A6966@core3.amsl.com> <32377771-299D-41B6-98A4-02AF14167D99@cs.stanford.edu> To: Joydeep Tripathi X-Mailer: Apple Mail (2.1077) X-Scan-Signature: c147875fdaedb8b2f3ad62e75043243e Cc: ROLL WG Subject: Re: [Roll] Fwd: New Version Notification for draft-tripathi-roll-rpl-simulation-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, 30 Dec 2009 02:19:43 -0000 On Dec 29, 2009, at 5:11 PM, Joydeep Tripathi wrote: > On Tue, Dec 29, 2009 at 7:17 PM, Omprakash Gnawali > wrote: >> On Tue, Dec 29, 2009 at 6:58 PM, Joydeep Tripathi >> wrote: >>> Hi, >>>=20 >>> On Thu, Dec 24, 2009 at 2:25 AM, Philip Levis = wrote: >>>>=20 >>>> On Dec 23, 2009, at 10:24 PM, Joydeep Tripathi wrote: >>>>=20 >>>>> On Wed, Dec 23, 2009 at 2:52 AM, Omprakash Gnawali >>>>> >>>>> wrote: >>>>>>=20 >>>>>> I managed to find the pdf with the graphs. Here are some = comments. >>>>>>=20 >>>>>> It will help greatly if more information about the link model = were >>>>>> included. -01 mentions: >>>>>>=20 >>>>>> "* Link failure model: Time varying real network traces = containing >>>>>> packet delivery probability for each >>>>>> link and over all channels for both indoor network deployment and >>>>>> outdoor network deployment were used. >>>>>> Thus, di erent types of link characteristics are used in the = study. >>>>>> * Topology: The topologies are gathered from real-life deployment >>>>>> (traces mentioned above) as opposed >>>>>> to random topology simulations. are repeated here:" >>>>>>=20 >>>>> Actually,we collected real-life traces with hundreds of links = varying >>>>> with time for the network, and simulated the same variation in = PDR >>>>> for each link as in the real deployment. >>>>=20 >>>> I don't understand -- how do you do this? There has to be some = interval over >>>> which you average, unless you are replaying success/failure traces. = Link can >>>> very much faster than every ten seconds. >>>=20 >>> Actually you are right, the PDR value of a link is averaged over 100 >>> packets over an interval. When the trace was gathered, during each = 15 >>> minutes interval, 100 packets are transmitted over a link in the >>> network. Out of 100 packets, number of successfully received packets >>> was count for each link between two communicating nodes that are >>> physically one hop away. The number of successfully received packets >>> out of 100 packets originally transmitted was recorded as the PDR of >>> the link after each 15 minutes interval. In our simulation, we >>> consider the PDR between those two nodes to be constant during a 10 >>> minutes interval. When an interval gets over, we consider the next = PDR >>> value between same two nodes in the database of traces, that was >>> collected during the next interval and use that value for next >>> interval. >>>=20 >>> I hope this clarifies how the link quality traces are gathered and >>> used. Please let me know if you have further questions. >>=20 >> Each node sends a packet every 9 seconds to estimate the link quality >> and the estimate is updated every 100 packets? >>=20 >> Do you consider datarate in your simulation? >=20 > When the link trace was gathered, I believe the intention was to > check how the connectivity between the nodes vary over time. The trace > reflects the quality of the links between the nodes, and the packets > used for trace gathering in real implementation did not use RPL > headers. However, in our simulation, we considered RPL headers, MAC > headers etc. For simulation, we also used specifications of TelosB > CC2420 radio, which has a datarate of 250 Kbps. >=20 >> I did not understand why data collection uses a window of 15 mins and >> data use uses a window of 10 mins. >=20 > The simulation used a 10 minute window to update PDR for every link. > However, in simulation also, the links have same temporal > characteristics as seen in the real link quality trace gathering. The > 10 minutes interval is just to make the simulation generic to other > gathered traces from other deployment as well. There may be traces > which update the link quality after an interval other than 15 minutes > (we do have such traces). We will include samples of link quality (in > terms of PDR) in our next revision as well. Jodeep, It's worth noting that links can vary as quickly as 500ms or less[1]. So = 10 minute variations ignore some of the short-term dynamics you might = see. This is especially important for problems like establishing an = efficient yet reasonably stable tree. Phil [1] Kannan Srinivasan, Maria A. Kazandjieva, Saatvik Agarwal, Philip = Levis: The beta-factor: measuring wireless link burstiness. SenSys 2008: = 29-42