From pthubert@cisco.com Wed Apr 1 00:30: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 60B483A6B2B for ; Wed, 1 Apr 2009 00:30:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.066 X-Spam-Level: X-Spam-Status: No, score=-8.066 tagged_above=-999 required=5 tests=[AWL=-1.467, 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 nG4YWm4jwoSl for ; Wed, 1 Apr 2009 00:30:05 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id E6AC83A67A7 for ; Wed, 1 Apr 2009 00:30:04 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.39,305,1235952000"; d="scan'208";a="164785862" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by sj-iport-1.cisco.com with ESMTP; 01 Apr 2009 07:31:04 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n317V3dn007409; Wed, 1 Apr 2009 09:31:03 +0200 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n317V3Ud027575; Wed, 1 Apr 2009 07:31:03 GMT Received: from xmb-ams-337.cisco.com ([144.254.231.82]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 1 Apr 2009 09:31:03 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 1 Apr 2009 09:30:59 +0200 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC07365AF6@xmb-ams-337.emea.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] FW: New Version Notification for draft-thubert-roll-fundamentals-00 Thread-Index: AcmyRa2+3VM+yQ6kRtuEbSfTXGgGDwAVRe/A References: <7892795E1A87F04CADFCCF41FADD00FC07365A53@xmb-ams-337.emea.cisco.com> From: "Pascal Thubert (pthubert)" To: "Philip Levis" X-OriginalArrivalTime: 01 Apr 2009 07:31:03.0687 (UTC) FILETIME=[D00BA970:01C9B29B] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3643; t=1238571063; x=1239435063; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pthubert@cisco.com; z=From:=20=22Pascal=20Thubert=20(pthubert)=22=20 |Subject:=20RE=3A=20[Roll]=20FW=3A=20New=20Version=20Notifi cation=20for=20draft-thubert-roll-fundamentals-00 |Sender:=20; bh=I+PKkH0Fq3f22wO2WRsG33TdTeRo89NnhwLgFHbqFf0=; b=hvH+F5OZp/zzI6WS9RTm4V8koIBNH+LQenIGuYOTw+ZZgR2eHtkgANK3wg ZkxVBmcHYc8j7PPR7aVMHuvABJWlkwNP4NWX6cKd50mBIt3lG62qPayN8R5N cQohLYQ5Qq; Authentication-Results: ams-dkim-2; header.From=pthubert@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Cc: ROLL WG Subject: Re: [Roll] FW: New Version Notification for draft-thubert-roll-fundamentals-00 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2009 07:30:06 -0000 Hi Phil: This is a neat thing to consider adding. What I fail to understand is the relationship with the text you mention.=20 The text is about building the tree that sets the reference structure though it might not be used a lot for forwarding (forwarding metrics are used). Specifically, that part of the text is about switching the default routing topology and is designed to make the merge of 2 large topologies smoother. The tree hop timer makes it so that when 2 trees collide, the merge spreads like a wave from the collision point into the tree that is being absorbed starting as high in the absorbing tree as possible. CC'ing the list since the topic might interest a larger community. Pascal >-----Original Message----- >From: Philip Levis [mailto:pal@cs.stanford.edu] >Sent: mardi 31 mars 2009 23:14 >To: Pascal Thubert (pthubert) >Subject: Re: [Roll] FW: New Version Notification for draft-thubert-roll-fundamentals-00 > >OK, I skimmed the draft. > >The issue is this: > >"A LLN Router may move from its current tree into any different > tree at any time and whatever the depth it reaches in the new > tree but, before it can do so, it may have to wait for a Tree >Hop > Timer to elapse." > >This idea of sequence numbering based on a timer ignores the possibly >highly dynamic nature of wireless communication. Instead, what you see >LLN protocols doing today is putting some topology information into >the datapath in order to detect loops. In particular, a data packet >contains the transmitter's believed hop count (or some other >gradient). If you're asked to forward a data packet whose hop count is ><=3D your own, then you think there might be a loop and try to repair >the problem. > >This approach, using the datapath to validate the topology, allows >protocols to quickly adapt without imposing a large overhead. > >Phil > > >On Mar 31, 2009, at 2:05 PM, Pascal Thubert (pthubert) wrote: > >> Dear Rollers, >> >> This is to announce that we just posted a draft that details the >> approach I proposed in the broad lines at the ROLL WG meeting in SFO >> last week: >> >> http://www.ietf.org/internet-drafts/draft-thubert-roll-fundamentals-00.t xt >> >> The authors expect to provide a refined refresher sometime soon but >> the 00 already provides a rather clear view on our approach. >> >> Comments appreciated as usual, >> >> Pascal >> >> -----Original Message----- >> From: IETF I-D Submission Tool [mailto:idsubmission@ietf.org] >> Sent: mardi 31 mars 2009 23:00 >> To: Pascal Thubert (pthubert) >> Cc: watteyne@eecs.berkeley.edu; zach@sensinode.com; dominique.barthel@orange-ftgroup.com >> Subject: New Version Notification for draft-thubert-roll- >> fundamentals-00 >> >> >> A new version of I-D, draft-thubert-roll-fundamentals-00.txt has >> been successfuly submitted by Pascal Thubert and posted to the IETF >> repository. >> >> Filename: draft-thubert-roll-fundamentals >> Revision: 00 >> Title: LLN Routing Fundamentals >> Creation_date: 2009-03-31 >> WG ID: Independent Submission >> Number_of_pages: 33 >> >> Abstract: >> This document describes a basic set of fundamental mechanisms for >> routing on a Low-power and Lossy Network (LLN). It does not intend >> to specify a full-blown protocol. It is rather offered as a basis to >> support the discussion while designing the ROLL protocol. >> >> >> >> The IETF Secretariat. >> >> >> _______________________________________________ >> Roll mailing list >> Roll@ietf.org >> https://www.ietf.org/mailman/listinfo/roll From jvasseur@cisco.com Wed Apr 1 00:56: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 7E5D63A67A7 for ; Wed, 1 Apr 2009 00:56:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.342 X-Spam-Level: X-Spam-Status: No, score=-8.342 tagged_above=-999 required=5 tests=[AWL=-1.744, 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 JtsfTAwGSWVN for ; Wed, 1 Apr 2009 00:56:35 -0700 (PDT) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id 3AFAC3A6888 for ; Wed, 1 Apr 2009 00:56:35 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.39,305,1235952000"; d="scan'208,217";a="32836657" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by sj-iport-4.cisco.com with ESMTP; 01 Apr 2009 07:57:34 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n317vYfU016102; Wed, 1 Apr 2009 09:57:34 +0200 Received: from xbh-ams-331.emea.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n317vYsA006616; Wed, 1 Apr 2009 07:57:34 GMT Received: from xfe-ams-331.emea.cisco.com ([144.254.231.72]) by xbh-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 1 Apr 2009 09:57:34 +0200 Received: from ams-jvasseur-8712.cisco.com ([10.55.201.131]) by xfe-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 1 Apr 2009 09:57:33 +0200 Message-Id: <0BD8BD8B-FD05-46E9-9AD4-7E9F312AAD21@cisco.com> From: JP Vasseur To: ROLL WG Content-Type: multipart/alternative; boundary=Apple-Mail-51-419933444 Mime-Version: 1.0 (Apple Message framework v930.3) Date: Wed, 1 Apr 2009 09:57:34 +0200 X-Mailer: Apple Mail (2.930.3) X-OriginalArrivalTime: 01 Apr 2009 07:57:33.0741 (UTC) FILETIME=[83CAA5D0:01C9B29F] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=6779; t=1238572654; x=1239436654; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:=20JP=20Vasseur=20 |Subject:=20Formation=20of=20a=20Routing=20Protocol=20Desig n=20Team=20for=20ROLL |Sender:=20; bh=/TE/I0E5V0ZZjuAcmacAv6EQHcdHnqt8WftXG1ELPNs=; b=UDGxckZ42w2Rt2G0bk02Cwd3Z0guicIvaU8ldl63APrn5QEJ991btq/x+1 ri1H8Tk3vZaUTOeMDNxVaxBK/I2LVoGWDl+hHuf/64Anc4EAkQatf5HNbbCn DiuVUdIVWq; Authentication-Results: ams-dkim-2; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Subject: [Roll] Formation of a Routing Protocol Design Team for ROLL X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2009 07:56:36 -0000 --Apple-Mail-51-419933444 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Dear WG, We have formed a new Design Team in the ROLL Working Group. Please find below the charter and team members. Since some of you may not be familiar with the concept of a Design Team, I would like to remind a few points: * The work produced by a Design Team has no special status in the WG and is subject to WG consensus as any other individual submission * We ask the Design Team to request for input from the WG and to provide regular updates on the progress: please send input requests to the mailing list, post regular updates of the document to get a chance to everybody to comment, ... * All: please provide input to the Design Team and copy the mailing list. Design Team Members ################### Tim Winter (Editor) Pascal Thubert Stephen Dawson Kris Pister Thomas Clausen Jonathan Hui (Thanks to the DT members) Charter ###### The charter is fairly simple: produce an IPv6 routing solution for LLN (one of our new WG item) in light of the four application-specific routing requirements documents: * draft-ietf-roll-urban-routing-reqs * draft-ietf-roll-industrial-routing-reqs * draft-ietf-roll-home-routing-reqs * draft-ietf-roll-building-routing-reqs The routing solution may either be based on an extension of an existing routing protocol or a new protocol. In the former case, the design team is expected to interact with the WG that is responsible for the development of the protocol. Please make sure to be aligned with the ROLL terminology document and provide input to their authors should new terms be introduced. According to our charter, it is asked to pay a particular attention to the security and manageability aspects of the routing solution. The Design Team is not tasked to produce a MIB for the routing solution. Milestones ######### May 1: produce a first draft of the routing solution document IETF-75 meeting: produce a more complete version of the document by the cut-off submission date for the IETF-75 meeting. The Design Team will be dissolved once the WG will have adopted a routing solution document as a WG document (should it be the one proposed by the WG or not). It is strongly encouraged to produce new version as the document progress (each time a substantial change is made to the document). Thanks. JP. --Apple-Mail-51-419933444 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Dear WG,

We = have formed a new Design Team in the ROLL Working Group. Please find = below the charter and team members.

Since some = of you may not be familiar with the concept of a Design Team, I would = like to remind a few points:

* The work = produced by a Design Team has no special status in the WG and is subject = to WG consensus as any other individual submission
* We ask = the Design Team to request for input from the WG and to provide regular = updates on the progress: please send input requests to the mailing list, = post regular updates of the document to get a chance to everybody to = comment, ... 
* All: please provide input to the Design = Team and copy the mailing list.

Design Team = Members
###################
Tim = Winter (Editor)
Pascal Thubert
Stephen = Dawson
Kris Pister
Thomas = Clausen
Jonathan = Hui

(Thanks to the DT = members)

Charter
######

<= /div>
The charter is fairly simple: produce an IPv6 routing solution = for LLN (one of our new WG item) in light of the four = application-specific routing requirements documents:
= * draft-ietf-roll-urban-routing-reqs
= * draft-ietf-roll-industrial-routing-reqs
= * draft-ietf-roll-home-routing-reqs
= *  References: <7892795E1A87F04CADFCCF41FADD00FC07365A53@xmb-ams-337.emea.cisco.com> <7892795E1A87F04CADFCCF41FADD00FC07365AF6@xmb-ams-337.emea.cisco.com> In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FC07365AF6@xmb-ams-337.emea.cisco.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: ROLL WG Subject: Re: [Roll] FW: New Version Notification for draft-thubert-roll-fundamentals-00 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2009 07:57:53 -0000 Hi, I believe Phil, you are referring to piggybacking a metric (or depth) on data packets as used in e.g. the TinyOS CTP protocol? With regard to ROLL this can be thought of as an alternative method for carrying tree discovery information as a hop-by-hop option with data in addition to ND traffic. What you are saying is that this can be used to detect loops or better default routers faster. In general I agree that this can be useful in highly dynamic networks. However a timer is still needed even in that case. When a problem is detected (using ND or data piggybacked info) and a node needs to change its default router there should still be a timer to make tree collision smoother. This timer may be very, very small as appropriate for dynamic networks, and can be set for the whole LLN in the TIO option. So these things are orthogonal. Definitely needs to be discussed in -01 of this draft. - Zach Pascal Thubert (pthubert) wrote: > Hi Phil: > > This is a neat thing to consider adding. What I fail to understand is > the relationship with the text you mention. > > The text is about building the tree that sets the reference structure > though it might not be used a lot for forwarding (forwarding metrics are > used). > > Specifically, that part of the text is about switching the default > routing topology and is designed to make the merge of 2 large topologies > smoother. The tree hop timer makes it so that when 2 trees collide, the > merge spreads like a wave from the collision point into the tree that is > being absorbed starting as high in the absorbing tree as possible. > > CC'ing the list since the topic might interest a larger community. > > Pascal > >> -----Original Message----- >> From: Philip Levis [mailto:pal@cs.stanford.edu] >> Sent: mardi 31 mars 2009 23:14 >> To: Pascal Thubert (pthubert) >> Subject: Re: [Roll] FW: New Version Notification for > draft-thubert-roll-fundamentals-00 >> OK, I skimmed the draft. >> >> The issue is this: >> >> "A LLN Router may move from its current tree into any different >> tree at any time and whatever the depth it reaches in the new >> tree but, before it can do so, it may have to wait for a Tree >> Hop >> Timer to elapse." >> >> This idea of sequence numbering based on a timer ignores the possibly >> highly dynamic nature of wireless communication. Instead, what you see >> LLN protocols doing today is putting some topology information into >> the datapath in order to detect loops. In particular, a data packet >> contains the transmitter's believed hop count (or some other >> gradient). If you're asked to forward a data packet whose hop count is >> <= your own, then you think there might be a loop and try to repair >> the problem. >> >> This approach, using the datapath to validate the topology, allows >> protocols to quickly adapt without imposing a large overhead. >> >> Phil >> >> >> On Mar 31, 2009, at 2:05 PM, Pascal Thubert (pthubert) wrote: >> >>> Dear Rollers, >>> >>> This is to announce that we just posted a draft that details the >>> approach I proposed in the broad lines at the ROLL WG meeting in SFO >>> last week: >>> >>> > http://www.ietf.org/internet-drafts/draft-thubert-roll-fundamentals-00.t > xt >>> The authors expect to provide a refined refresher sometime soon but >>> the 00 already provides a rather clear view on our approach. >>> >>> Comments appreciated as usual, >>> >>> Pascal >>> >>> -----Original Message----- >>> From: IETF I-D Submission Tool [mailto:idsubmission@ietf.org] >>> Sent: mardi 31 mars 2009 23:00 >>> To: Pascal Thubert (pthubert) >>> Cc: watteyne@eecs.berkeley.edu; zach@sensinode.com; > dominique.barthel@orange-ftgroup.com >>> Subject: New Version Notification for draft-thubert-roll- >>> fundamentals-00 >>> >>> >>> A new version of I-D, draft-thubert-roll-fundamentals-00.txt has >>> been successfuly submitted by Pascal Thubert and posted to the IETF >>> repository. >>> >>> Filename: draft-thubert-roll-fundamentals >>> Revision: 00 >>> Title: LLN Routing Fundamentals >>> Creation_date: 2009-03-31 >>> WG ID: Independent Submission >>> Number_of_pages: 33 >>> >>> Abstract: >>> This document describes a basic set of fundamental mechanisms for >>> routing on a Low-power and Lossy Network (LLN). It does not intend >>> to specify a full-blown protocol. It is rather offered as a basis to >>> support the discussion while designing the ROLL protocol. >>> >>> >>> >>> 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 -- http://zachshelby.org - My blog “On the Internet of Things” Mobile: +358 40 7796297 Zach Shelby Head of Research Sensinode Ltd. Kidekuja 2 88610 Vuokatti, FINLAND This e-mail and all attached material are confidential and may contain legally privileged information. If you are not the intended recipient, please contact the sender and delete the e-mail from your system without producing, distributing or retaining copies thereof. From alexandru.petrescu@gmail.com Wed Apr 1 01:06: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 018B43A6982 for ; Wed, 1 Apr 2009 01:06:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.169 X-Spam-Level: X-Spam-Status: No, score=-2.169 tagged_above=-999 required=5 tests=[AWL=0.080, 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 S6S4VY4ZvKae for ; Wed, 1 Apr 2009 01:06:50 -0700 (PDT) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.166.172.106]) by core3.amsl.com (Postfix) with ESMTP id 245093A67A7 for ; Wed, 1 Apr 2009 01:06:45 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.0) with ESMTP id n3187f5U007936 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 1 Apr 2009 10:07:41 +0200 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (8.14.2/8.14.2) with ESMTP id n318AEld004185; Wed, 1 Apr 2009 10:10:14 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.133.173]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id n3187eUL005345; Wed, 1 Apr 2009 10:07:41 +0200 Message-ID: <49D320CC.20309@gmail.com> Date: Wed, 01 Apr 2009 10:07:40 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: JP Vasseur References: <0BD8BD8B-FD05-46E9-9AD4-7E9F312AAD21@cisco.com> In-Reply-To: <0BD8BD8B-FD05-46E9-9AD4-7E9F312AAD21@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: ROLL WG Subject: Re: [Roll] Formation of a Routing Protocol Design Team for ROLL X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2009 08:06:51 -0000 JP Vasseur a écrit : [...] > Charter > ###### > > The charter is fairly simple: produce an IPv6 routing solution for LLN > (one of our new WG item) in light of the four application-specific > routing requirements documents: > * draft-ietf-roll-urban-routing-reqs > * draft-ietf-roll-industrial-routing-reqs > * draft-ietf-roll-home-routing-reqs > * draft-ietf-roll-building-routing-reqs > > The routing solution may either be based on an extension of an existing > routing protocol or a new protocol. In the former case, the design team > is expected to interact with the WG that is responsible for the > development of the protocol. And in the latter case?... is the DT free to not interact with the WG and go ahead design a new protocol? Who makes the choice new vs existing? Is it the DT making that choice? Alex > > Please make sure to be aligned with the ROLL terminology document and > provide input to their authors should new terms be introduced. > > According to our charter, it is asked to pay a particular attention to > the security and manageability aspects of the routing solution. > > The Design Team is not tasked to produce a MIB for the routing solution. > > Milestones > ######### > > May 1: produce a first draft of the routing solution document > IETF-75 meeting: produce a more complete version of the document by the > cut-off submission date for the IETF-75 meeting. > > The Design Team will be dissolved once the WG will have adopted a > routing solution document as a WG document (should it be the one > proposed by the WG or not). > > It is strongly encouraged to produce new version as the document > progress (each time a substantial change is made to the document). > > Thanks. > > JP. > > > ------------------------------------------------------------------------ > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From jvasseur@cisco.com Wed Apr 1 01:14: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 22B1F3A6B7D for ; Wed, 1 Apr 2009 01:14:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.311 X-Spam-Level: X-Spam-Status: No, score=-10.311 tagged_above=-999 required=5 tests=[AWL=0.288, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iDKHUtxSAyUR for ; Wed, 1 Apr 2009 01:14:39 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 9BF503A68C8 for ; Wed, 1 Apr 2009 01:14:38 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.39,305,1235952000"; d="scan'208";a="37177952" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 01 Apr 2009 08:15:36 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n318Fa9N013806; Wed, 1 Apr 2009 10:15:36 +0200 Received: from xbh-ams-331.emea.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n318Fa3U015856; Wed, 1 Apr 2009 08:15:36 GMT Received: from xfe-ams-331.emea.cisco.com ([144.254.231.72]) by xbh-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 1 Apr 2009 10:15:36 +0200 Received: from ams-jvasseur-8712.cisco.com ([10.55.201.131]) by xfe-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 1 Apr 2009 10:15:35 +0200 Message-Id: From: JP Vasseur To: Alexandru Petrescu In-Reply-To: <49D320CC.20309@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 v930.3) Date: Wed, 1 Apr 2009 10:15:36 +0200 References: <0BD8BD8B-FD05-46E9-9AD4-7E9F312AAD21@cisco.com> <49D320CC.20309@gmail.com> X-Mailer: Apple Mail (2.930.3) X-OriginalArrivalTime: 01 Apr 2009 08:15:36.0113 (UTC) FILETIME=[08EF8210:01C9B2A2] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2598; t=1238573736; x=1239437736; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:=20JP=20Vasseur=20 |Subject:=20Re=3A=20[Roll]=20Formation=20of=20a=20Routing=2 0Protocol=20Design=20Team=20for=20ROLL |Sender:=20; bh=6o7YMCgQ4A0SVrBQ1YmlNPs5tEnEODs+eVx9drYlBLk=; b=bTzt1cdw8CAYgf3/T/uo9HlfIPeys7ouCLGxcQoYHFOOSykpyt6TkAAxvi C/miR+AvpGRX3kt5utyC5NJtqam8xom8ZYx4ebIyzXcL79IhPE9XmpJMtcG8 l+huOoJNe2; Authentication-Results: ams-dkim-1; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Cc: ROLL WG Subject: Re: [Roll] Formation of a Routing Protocol Design Team for ROLL X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2009 08:14:40 -0000 Hi Alex, On Apr 1, 2009, at 10:07 AM, Alexandru Petrescu wrote: > JP Vasseur a =E9crit : > [...] >> Charter >> ###### >> The charter is fairly simple: produce an IPv6 routing solution for =20= >> LLN (one of our new WG item) in light of the four application-=20 >> specific routing requirements documents: >> * draft-ietf-roll-urban-routing-reqs >> * draft-ietf-roll-industrial-routing-reqs >> * draft-ietf-roll-home-routing-reqs >> * draft-ietf-roll-building-routing-reqs >> The routing solution may either be based on an extension of an =20 >> existing routing protocol or a new protocol. In the former case, =20 >> the design team is expected to interact with the WG that is =20 >> responsible for the development of the protocol. > > And in the latter case?... There is nothing specific to this WG: when a WG specify a protocol, =20 the WG will have to decide whether or not interacting with a existing =20= WG is necessary or not. > is the DT free to not interact with the WG and go ahead design a =20 > new protocol? > > Who makes the choice new vs existing? Is it the DT making that =20 > choice? As pointed out in the email: "* The work produced by a Design Team has no special status in the WG =20= and is subject to WG consensus as any other individual submission" The DT will make that choice - Anyone is free to make any proposal. JP. > > Alex > >> Please make sure to be aligned with the ROLL terminology document =20 >> and provide input to their authors should new terms be introduced. >> According to our charter, it is asked to pay a particular attention =20= >> to the security and manageability aspects of the routing solution. >> The Design Team is not tasked to produce a MIB for the routing =20 >> solution. >> Milestones >> ######### >> May 1: produce a first draft of the routing solution document >> IETF-75 meeting: produce a more complete version of the document by =20= >> the cut-off submission date for the IETF-75 meeting. >> The Design Team will be dissolved once the WG will have adopted a =20 >> routing solution document as a WG document (should it be the one =20 >> proposed by the WG or not). >> It is strongly encouraged to produce new version as the document =20 >> progress (each time a substantial change is made to the document). >> Thanks. >> JP. >> = ------------------------------------------------------------------------ >> _______________________________________________ >> Roll mailing list >> Roll@ietf.org >> https://www.ietf.org/mailman/listinfo/roll > > From alexandru.petrescu@gmail.com Wed Apr 1 01:45:41 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4F2353A67A7 for ; Wed, 1 Apr 2009 01:45:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.17 X-Spam-Level: X-Spam-Status: No, score=-2.17 tagged_above=-999 required=5 tests=[AWL=0.079, 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 xMOWqTnCmVRv for ; Wed, 1 Apr 2009 01:45:40 -0700 (PDT) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.1]) by core3.amsl.com (Postfix) with ESMTP id 317A83A6983 for ; Wed, 1 Apr 2009 01:45:40 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.0) with ESMTP id n318ie3e011642 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 1 Apr 2009 10:44:40 +0200 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (8.14.2/8.14.2) with ESMTP id n318n8fg016968; Wed, 1 Apr 2009 10:49:09 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.133.173]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id n318kZFG024542; Wed, 1 Apr 2009 10:46:35 +0200 Message-ID: <49D329EB.3080206@gmail.com> Date: Wed, 01 Apr 2009 10:46:35 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: "Pascal Thubert (pthubert)" References: <7892795E1A87F04CADFCCF41FADD00FC07365A53@xmb-ams-337.emea.cisco.com> In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FC07365A53@xmb-ams-337.emea.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: ROLL WG , dominique.barthel@orange-ftgroup.com, Robert Assimiti Subject: Re: [Roll] IPR and Tree Discovery (was: FW: New Version Notification for draft-thubert-roll-fundamentals-00) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2009 08:45:41 -0000 IPR related to ROLL Fundamentals? Pascal, what is the IPR status of the Tree Discovery described in draft-thubert-roll-fundamentals-00.txt section 2.1. Overview "LLN Tree Discovery..." and e.g. the tree-based topologies for mobile adhoc networks described in various IPRs, among which e.g. "DIRECTED ACYCLIC GRAPH DISCOVERY AND NETWORK PREFIX INFORMATION DISTRIBUTION RELATIVE TO A CLUSTERHEAD IN AN AD HOC MOBILE NETWORK" EP1897295 "ARRANGEMENT FOR PROVIDING OPTIMIZED CONNECTIONS BETWEEN PEER ROUTERS IN A TREE-BASED AD HOC MOBILE NETWORK" EP1867104 Have the Chairs received any notification about potential IPR with respect to Tree Discovery document? It is good to have this settled right from the start. Alex Pascal Thubert (pthubert) a écrit : > Dear Rollers, > > This is to announce that we just posted a draft that details the > approach I proposed in the broad lines at the ROLL WG meeting in SFO > last week: > > http://www.ietf.org/internet-drafts/draft-thubert-roll-fundamentals-00.txt > > > The authors expect to provide a refined refresher sometime soon but > the 00 already provides a rather clear view on our approach. > > Comments appreciated as usual, > > Pascal > > -----Original Message----- From: IETF I-D Submission Tool > [mailto:idsubmission@ietf.org] Sent: mardi 31 mars 2009 23:00 To: > Pascal Thubert (pthubert) Cc: watteyne@eecs.berkeley.edu; > zach@sensinode.com; dominique.barthel@orange-ftgroup.com Subject: New > Version Notification for draft-thubert-roll-fundamentals-00 > > > A new version of I-D, draft-thubert-roll-fundamentals-00.txt has been > successfuly submitted by Pascal Thubert and posted to the IETF > repository. > > Filename: draft-thubert-roll-fundamentals Revision: 00 Title: LLN > Routing Fundamentals Creation_date: 2009-03-31 WG ID: Independent > Submission Number_of_pages: 33 > > Abstract: This document describes a basic set of fundamental > mechanisms for routing on a Low-power and Lossy Network (LLN). It > does not intend to specify a full-blown protocol. It is rather > offered as a basis to support the discussion while designing the ROLL > protocol. > > > > The IETF Secretariat. > > > _______________________________________________ Roll mailing list > Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll > From alexandru.petrescu@gmail.com Wed Apr 1 01:50:22 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 652563A68C8 for ; Wed, 1 Apr 2009 01:50:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.17 X-Spam-Level: X-Spam-Status: No, score=-2.17 tagged_above=-999 required=5 tests=[AWL=0.079, 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 HkRbeS-Nxcdi for ; Wed, 1 Apr 2009 01:50:21 -0700 (PDT) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.166.172.106]) by core3.amsl.com (Postfix) with ESMTP id 677103A684A for ; Wed, 1 Apr 2009 01:50:20 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.0) with ESMTP id n318pKZL031254 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Wed, 1 Apr 2009 10:51:20 +0200 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (8.14.2/8.14.2) with ESMTP id n318rrnM018518 for ; Wed, 1 Apr 2009 10:53:53 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.133.173]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id n318pJQT026693 for ; Wed, 1 Apr 2009 10:51:19 +0200 Message-ID: <49D32B07.2000303@gmail.com> Date: Wed, 01 Apr 2009 10:51:19 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: ROLL WG Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [Roll] Clarification about IPR and ROLL X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2009 08:50:22 -0000 Dear ROLLers, Have the Chairs received any IPR notification about any ROLL I-D currently posted? (draft-ietf-roll-*) Has there been any IPR disclosure made in the IETF IPR disclosure page with respect to ROLL documents? https://datatracker.ietf.org/ipr/about/ It is good to have this settled from the start, avoid later misunderstandings. There are specific ways in which IPR is treated in IETF in general and I haven't seen any public discussion about it in ROLL, although silence doesn't necessarily mean absence of IPR in this space. Moreover, having a DT set out to do work now may need to thave the IPR aspects settled, and publicly is better. Alex From Jerald.P.Martocci@jci.com Wed Apr 1 07:42: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 354A428C1FE; Wed, 1 Apr 2009 07:42:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.612 X-Spam-Level: X-Spam-Status: No, score=-6.612 tagged_above=-999 required=5 tests=[AWL=-0.014, 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 2sNsjM4RwURg; Wed, 1 Apr 2009 07:42:10 -0700 (PDT) Received: from exprod8og118.obsmtp.com (exprod8og118.obsmtp.com [64.18.3.36]) by core3.amsl.com (Postfix) with ESMTP id EE86828C1F6; Wed, 1 Apr 2009 07:42:09 -0700 (PDT) Received: from source ([192.132.24.137]) (using SSLv3) by exprod8ob118.postini.com ([64.18.7.12]) with SMTP ID DSNKSdN9fZmUYJAq6C6EMQ2xxD9ahmgcT44A@postini.com; Wed, 01 Apr 2009 07:43:10 PDT Received: from jwimkrs1.na.jci.com ([10.10.6.31]) by smtpmke01.jci.com (Lotus Domino Release 8.0.1) with ESMTP id 2009040109433381-2673504 ; Wed, 1 Apr 2009 09:43:33 -0500 In-Reply-To: <49CB86DA.9050104@eecs.berkeley.edu> MIME-Version: 1.0 To: Kris Pister X-Mailer: Lotus Notes Release 6.5.2 June 01, 2004 From: Jerald.P.Martocci@jci.com Message-ID: Date: Wed, 1 Apr 2009 09:42:55 -0500 X-MIMETrack: Serialize by Router on jwimkrs1.na.jci.com/NA/Johnson_Controls at 04/01/2009 09:43:00 AM, Serialize complete at 04/01/2009 09:43:00 AM, Itemize by SMTP Server on smtpmke01.jci.com/JCI_SMTP(Release 8.0.1|February 07, 2008) at 04/01/2009 09:43:33 AM, Serialize by Router on smtpmke01.jci.com/JCI_SMTP(Release 8.0.1|February 07, 2008) at 04/01/2009 09:43:43 AM, Serialize complete at 04/01/2009 09:43:43 AM Content-Type: multipart/alternative; boundary="=_alternative 0050D5758625758B_=" Cc: ROLL WG , roll-bounces@ietf.org, Ted.Humpal@jci.com Subject: Re: [Roll] security update? X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 01 Apr 2009 14:42:11 -0000 This is a multipart message in MIME format. --=_alternative 0050D5758625758B_= Content-Type: text/plain; charset="US-ASCII" Kris, I think having network security is an important requirement of ROLL. However, my opinion is it's too early to mandate network security to be always 'turned on'. Empirical testing on 802.15.4 based systems show 33 to 50% degradation in network performance when security was turned 'on'. This is primarily due to needing to decrypt and re-encrypt every packet at every hop. If the security model only encrypts the pay load, then it needn't be decrypted/encrypted at each hop. Furthermore the AES integrity code can chew up up to 16 bytes of the available 802.15.4 80 byte payload Secondly, we would not want security turned 'on' while in the 'configuration' mode. We have a strong requirement for zero-based configuration. Having to add network and application keys and installing trust centers just to get a temperature sensor working in a vacant building is a bit overkill. I think the default 'out-of-the-box' security profile should be 'off'. Once the device is configured and on the operational network, I have no issue with requiring encryption and authentication if it doesn't impinge on the constrained processing power or the payload size. Jerry Kris Pister Sent by: roll-bounces@ietf.org 03/26/2009 08:39 AM To ROLL WG cc Subject [Roll] security update? Since we weren't able to get an update on the security draft at this meeting, perhaps we could get an email summary? I'm confident that we can come up with a good routing protocol, and I'm 100% certain that the networks it serves will be attacked. We need to come up with something that is strong, but simple enough that everyone uses it by default. My strong preference would be that security is an intrinsic part of the routing protocol, and can't be "turned off". ksjp _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll --=_alternative 0050D5758625758B_= Content-Type: text/html; charset="US-ASCII"


Kris,

I think having network security is an important requirement of ROLL.  However, my opinion is it's too early to mandate network security to be always 'turned on'.  Empirical testing on 802.15.4 based systems show 33 to 50% degradation in network performance when security was turned 'on'.  This is primarily due to needing to decrypt and re-encrypt every packet at every hop.  If the security model only encrypts the pay load, then it needn't be decrypted/encrypted at each hop.  Furthermore the AES integrity code can chew up up to 16 bytes of the available 802.15.4 80 byte payload

Secondly, we would not want security turned 'on' while in the 'configuration' mode.  We have a strong requirement for zero-based configuration.  Having to add network and application keys and installing trust centers just to get a temperature sensor working in a vacant building is a bit overkill.

I think the default 'out-of-the-box' security profile should be 'off'.  Once the device is configured and on the operational network, I have no issue with requiring encryption and authentication if it doesn't impinge on the constrained processing power or the payload size.

Jerry






Kris Pister <pister@eecs.berkeley.edu>
Sent by: roll-bounces@ietf.org

03/26/2009 08:39 AM

To
ROLL WG <roll@ietf.org>
cc
Subject
[Roll] security update?





Since we weren't able to get an update on the security draft at this
meeting, perhaps we could get an email summary?

I'm confident that we can come up with a good routing protocol, and I'm
100% certain that the networks it serves will be attacked.  We need to
come up with something that is strong, but simple enough that everyone
uses it by default.  My strong preference would be that security is an
intrinsic part of the routing protocol, and can't be "turned off".

ksjp
_______________________________________________
Roll mailing list
Roll@ietf.org
https://www.ietf.org/mailman/listinfo/roll
--=_alternative 0050D5758625758B_=-- From jvasseur@cisco.com Wed Apr 1 09:07: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 7284B3A693C for ; Wed, 1 Apr 2009 09:07:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.316 X-Spam-Level: X-Spam-Status: No, score=-10.316 tagged_above=-999 required=5 tests=[AWL=0.283, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id juOYci247cZm for ; Wed, 1 Apr 2009 09:07:15 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 37EBE3A68EB for ; Wed, 1 Apr 2009 09:07:15 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.39,307,1235952000"; d="scan'208";a="37227105" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 01 Apr 2009 16:08:14 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n31G8Eon009814; Wed, 1 Apr 2009 18:08:14 +0200 Received: from xbh-ams-331.emea.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n31G8ELk010888; Wed, 1 Apr 2009 16:08:14 GMT Received: from xfe-ams-332.cisco.com ([144.254.231.73]) by xbh-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 1 Apr 2009 18:08:14 +0200 Received: from ams-jvasseur-8712.cisco.com ([10.55.201.131]) by xfe-ams-332.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 1 Apr 2009 18:08:12 +0200 Message-Id: From: JP Vasseur To: Alexandru Petrescu In-Reply-To: <49D32B07.2000303@gmail.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Wed, 1 Apr 2009 18:08:09 +0200 References: <49D32B07.2000303@gmail.com> X-Mailer: Apple Mail (2.930.3) X-OriginalArrivalTime: 01 Apr 2009 16:08:13.0761 (UTC) FILETIME=[0F693310:01C9B2E4] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=987; t=1238602094; x=1239466094; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:=20JP=20Vasseur=20 |Subject:=20Re=3A=20[Roll]=20Clarification=20about=20IPR=20 and=20ROLL |Sender:=20; bh=Rr923+5eoi/jHVEka4uAP3H3ngiEC601kGutA5iCRpA=; b=oMRzeID5B/KR3ngG8tPbQoS4aUd9FsyIzx0G2PIabZ5e8c67B8uG6avL0G 68ss58Cpgj4JN5lMB4VpdeSysl1I3nSXNOgrLpddgWhVZi6/AN//9Uc3GX3s nQPtsIbJbQ; Authentication-Results: ams-dkim-1; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Cc: ROLL WG Subject: Re: [Roll] Clarification about IPR and ROLL X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2009 16:07:16 -0000 On Apr 1, 2009, at 10:51 AM, Alexandru Petrescu wrote: > Dear ROLLers, > > Have the Chairs received any IPR notification about any ROLL I-D > currently posted? (draft-ietf-roll-*) No. > > Has there been any IPR disclosure made in the IETF IPR disclosure page > with respect to ROLL documents? > https://datatracker.ietf.org/ipr/about/ > > It is good to have this settled from the start, avoid later > misunderstandings. > > There are specific ways in which IPR is treated in IETF in general > and I > haven't seen any public discussion about it in ROLL, although silence > doesn't necessarily mean absence of IPR in this space. > > Moreover, having a DT set out to do work now may need to thave the > IPR aspects settled, and publicly is better. > Do not worry, we are not ignoring any of this. JP. > Alex > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From pister@eecs.berkeley.edu Wed Apr 1 10:56: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 24FB33A6A98 for ; Wed, 1 Apr 2009 10:56:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.288 X-Spam-Level: X-Spam-Status: No, score=-6.288 tagged_above=-999 required=5 tests=[AWL=0.310, 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 cSTx-o7e+JNb for ; Wed, 1 Apr 2009 10:56:58 -0700 (PDT) Received: from gateway0.EECS.Berkeley.EDU (gateway0.EECS.Berkeley.EDU [169.229.60.87]) by core3.amsl.com (Postfix) with ESMTP id 0A4ED3A67F7 for ; Wed, 1 Apr 2009 10:56:58 -0700 (PDT) Received: from [127.0.0.1] (dhcp-32-46.EECS.Berkeley.EDU [128.32.32.46]) (authenticated bits=0) by gateway0.EECS.Berkeley.EDU (8.14.3/8.13.5) with ESMTP id n31HvtW4000043 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 1 Apr 2009 10:57:57 -0700 (PDT) Message-ID: <49D3AB1E.7040403@eecs.berkeley.edu> Date: Wed, 01 Apr 2009 10:57:50 -0700 From: Kris Pister User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Jerald.P.Martocci@jci.com References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------080607000208050207090602" Cc: ROLL WG , Ted.Humpal@jci.com Subject: Re: [Roll] security update? X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 01 Apr 2009 17:56:59 -0000 This is a multi-part message in MIME format. --------------080607000208050207090602 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Jerry - I'm hopeful that we can come up with something that is light-weight enough that people won't notice the impact, and so the default will be to leave it on. That's a challenge, I realize, and even if we achieve it, some people will still want to leave security off. I'm pretty surprised by some of your numbers. In the systems that I'm familiar with, security adds only a few percent at most to the overall energy/time/bw cost. Can you share any of the details of the experiments that showed a 33-50% hit due to security? The AES engine on most 15.4 chips can generate or verify a MIC for less than the energy cost of sending or receiving a single bit over the radio. Even in software on an 8 bit processor it's still a small fraction of the communication cost, for radio systems anyway. Maybe it's different for PLC? I would imagine that we'd use at most a 4 byte MIC, perhaps even smaller. That does cut into payload space, but it would be on the whole IP packet - for small packets it wouldn't be a problem, and for big packets they're going to be fragmented anyway. I'm in complete agreement on the need for an operation mode with zero-configuration. The challenge will be to come up with something that still gives some degree of protection there. I'll know we've succeeded if we can convince you that it's ok! ksjp Jerald.P.Martocci@jci.com wrote: > > > > Kris, > > I think having network security is an important requirement of ROLL. > However, my opinion is it's too early to mandate network security to > be always 'turned on'. Empirical testing on 802.15.4 based systems > show 33 to 50% degradation in network performance when security was > turned 'on'. This is primarily due to needing to decrypt and > re-encrypt every packet at every hop. If the security model only > encrypts the pay load, then it needn't be decrypted/encrypted at each > hop. Furthermore the AES integrity code can chew up up to 16 bytes of > the available 802.15.4 80 byte payload > > Secondly, we would not want security turned 'on' while in the > 'configuration' mode. We have a strong requirement for zero-based > configuration. Having to add network and application keys and > installing trust centers just to get a temperature sensor working in a > vacant building is a bit overkill. > > I think the default 'out-of-the-box' security profile should be 'off'. > Once the device is configured and on the operational network, I have > no issue with requiring encryption and authentication if it doesn't > impinge on the constrained processing power or the payload size. > > Jerry > > > > > > > *Kris Pister * > Sent by: roll-bounces@ietf.org > > 03/26/2009 08:39 AM > > > To > ROLL WG > cc > > Subject > [Roll] security update? > > > > > > > > > > Since we weren't able to get an update on the security draft at this > meeting, perhaps we could get an email summary? > > I'm confident that we can come up with a good routing protocol, and I'm > 100% certain that the networks it serves will be attacked. We need to > come up with something that is strong, but simple enough that everyone > uses it by default. My strong preference would be that security is an > intrinsic part of the routing protocol, and can't be "turned off". > > ksjp > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > --------------080607000208050207090602 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Jerry -  I'm hopeful that we can come up with something that is light-weight enough that people won't notice the impact, and so the default will be to leave it on.  That's a challenge, I realize, and even if we achieve it, some people will still want to leave security off.

I'm pretty surprised by some of your numbers.  In the systems that I'm familiar with, security adds only a few percent at most to the overall energy/time/bw cost.
Can you share any of the details of the experiments that showed a 33-50% hit due to security?  The AES engine on most 15.4 chips can generate or verify a MIC for less than the energy cost of sending or receiving a single bit over the radio.  Even in software on an 8 bit processor it's still a small fraction of the communication cost, for radio systems anyway.  Maybe it's different for PLC?
I would imagine that we'd use at most a 4 byte MIC, perhaps even smaller.  That does cut into payload space, but it would be on the whole IP packet - for small packets it wouldn't be a problem, and for big packets they're going to be fragmented anyway.

I'm in complete agreement on the need for an operation mode with zero-configuration.  The challenge will be to come up with something that still gives some degree of protection there.  I'll know we've succeeded if we can convince you that it's ok!

ksjp

Jerald.P.Martocci@jci.com wrote:



Kris,

I think having network security is an important requirement of ROLL.  However, my opinion is it's too early to mandate network security to be always 'turned on'.  Empirical testing on 802.15.4 based systems show 33 to 50% degradation in network performance when security was turned 'on'.  This is primarily due to needing to decrypt and re-encrypt every packet at every hop.  If the security model only encrypts the pay load, then it needn't be decrypted/encrypted at each hop.  Furthermore the AES integrity code can chew up up to 16 bytes of the available 802.15.4 80 byte payload

Secondly, we would not want security turned 'on' while in the 'configuration' mode.  We have a strong requirement for zero-based configuration.  Having to add network and application keys and installing trust centers just to get a temperature sensor working in a vacant building is a bit overkill.

I think the default 'out-of-the-box' security profile should be 'off'.  Once the device is configured and on the operational network, I have no issue with requiring encryption and authentication if it doesn't impinge on the constrained processing power or the payload size.

Jerry






Kris Pister <pister@eecs.berkeley.edu>
Sent by: roll-bounces@ietf.org

03/26/2009 08:39 AM

To
 ROLL WG <roll@ietf.org>
cc
Subject
 [Roll] security update?







Since we weren't able to get an update on the security draft at this
meeting, perhaps we could get an email summary?

I'm confident that we can come up with a good routing protocol, and I'm
100% certain that the networks it serves will be attacked.  We need to
come up with something that is strong, but simple enough that everyone
uses it by default.  My strong preference would be that security is an
intrinsic part of the routing protocol, and can't be "turned off".

ksjp
_______________________________________________
Roll mailing list
Roll@ietf.org
https://www.ietf.org/mailman/listinfo/roll
--------------080607000208050207090602-- From jvasseur@cisco.com Wed Apr 1 20:31: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 755F43A694D for ; Wed, 1 Apr 2009 20:31:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.321 X-Spam-Level: X-Spam-Status: No, score=-10.321 tagged_above=-999 required=5 tests=[AWL=0.277, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lIIJzBN9Bkd1 for ; Wed, 1 Apr 2009 20:31:17 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 803AD3A6917 for ; Wed, 1 Apr 2009 20:31:16 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.39,310,1235952000"; d="scan'208,217";a="37263799" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 02 Apr 2009 03:32:15 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n323WF94002282 for ; Thu, 2 Apr 2009 05:32:15 +0200 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n323WFan004388 for ; Thu, 2 Apr 2009 03:32:15 GMT Received: from xfe-ams-332.cisco.com ([144.254.231.73]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 2 Apr 2009 05:32:15 +0200 Received: from ams-jvasseur-8712.cisco.com ([10.55.201.131]) by xfe-ams-332.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 2 Apr 2009 05:32:14 +0200 Message-Id: <8CD13826-B1FF-4B12-93E0-1E0B843D86B9@cisco.com> From: JP Vasseur To: ROLL WG Content-Type: multipart/alternative; boundary=Apple-Mail-96-490413094 Mime-Version: 1.0 (Apple Message framework v930.3) Date: Thu, 2 Apr 2009 05:32:14 +0200 References: <0BD8BD8B-FD05-46E9-9AD4-7E9F312AAD21@cisco.com> X-Mailer: Apple Mail (2.930.3) X-OriginalArrivalTime: 02 Apr 2009 03:32:15.0100 (UTC) FILETIME=[9DF48BC0:01C9B343] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=9637; t=1238643135; x=1239507135; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:=20JP=20Vasseur=20 |Subject:=20*=20one=20correction=20*=20Fwd=3A=20[Roll]=20Fo rmation=20of=20a=20Routing=20Protocol=20Design=20Team=20for= 20ROLL |Sender:=20; bh=GFe8bWGkKyyWmRv+d85MKfmj9SbSkCbL7YX99LNeGJ4=; b=axkvwnpsA5gqW+L7W8ZdMshe2MUMnpYCnk0q6stf22cmt0RbVhqWUWizLO bOCIr1eXikhs+d8ED1nsOO3Z8OUaxDE2KIWrCMLg2txq4k3sNEVGah/Lwl6i 0GOLdEmx10; Authentication-Results: ams-dkim-1; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Subject: [Roll] * one correction * Fwd: Formation of a Routing Protocol Design Team for ROLL X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Apr 2009 03:31:18 -0000 --Apple-Mail-96-490413094 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Begin forwarded message: > From: JP Vasseur > Date: April 1, 2009 9:57:34 AM CEDT > To: ROLL WG > Subject: [Roll] Formation of a Routing Protocol Design Team for ROLL > > Dear WG, > > We have formed a new Design Team in the ROLL Working Group. Please > find below the charter and team members. > > Since some of you may not be familiar with the concept of a Design > Team, I would like to remind a few points: > > * The work produced by a Design Team has no special status in the WG > and is subject to WG consensus as any other individual submission > * We ask the Design Team to request for input from the WG and to > provide regular updates on the progress: please send input requests > to the mailing list, post regular updates of the document to get a > chance to everybody to comment, ... > * All: please provide input to the Design Team and copy the mailing > list. > > Design Team Members > ################### > Tim Winter (Editor) > Pascal Thubert > Stephen Dawson > Kris Pister > Thomas Clausen > Jonathan Hui Anders Brandt > > (Thanks to the DT members) > > Charter > ###### > > The charter is fairly simple: produce an IPv6 routing solution for > LLN (one of our new WG item) in light of the four application- > specific routing requirements documents: > * draft-ietf-roll-urban-routing-reqs > * draft-ietf-roll-industrial-routing-reqs > * draft-ietf-roll-home-routing-reqs > * draft-ietf-roll-building-routing-reqs > > The routing solution may either be based on an extension of an > existing routing protocol or a new protocol. In the former case, the > design team is expected to interact with the WG that is responsible > for the development of the protocol. > > Please make sure to be aligned with the ROLL terminology document > and provide input to their authors should new terms be introduced. > > According to our charter, it is asked to pay a particular attention > to the security and manageability aspects of the routing solution. > > The Design Team is not tasked to produce a MIB for the routing > solution. > > Milestones > ######### > > May 1: produce a first draft of the routing solution document > IETF-75 meeting: produce a more complete version of the document by > the cut-off submission date for the IETF-75 meeting. > > The Design Team will be dissolved once the WG will have adopted a > routing solution document as a WG document (should it be the one > proposed by the WG or not). > > It is strongly encouraged to produce new version as the document > progress (each time a substantial change is made to the document). > > Thanks. > > JP. > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll --Apple-Mail-96-490413094 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable

Begin = forwarded message:

From: = JP Vasseur <jvasseur@cisco.com>
=
Date: = April 1, 2009 9:57:34 AM CEDT
To: ROLL WG = <roll@ietf.org>
Subject: = [Roll] Formation of a Routing Protocol Design Team for = ROLL

=
Dear WG,

We = have formed a new Design Team in the ROLL Working Group. Please find = below the charter and team members.

Since some = of you may not be familiar with the concept of a Design Team, I would = like to remind a few points:

* The work = produced by a Design Team has no special status in the WG and is subject = to WG consensus as any other individual submission
* We ask = the Design Team to request for input from the WG and to provide regular = updates on the progress: please send input requests to the mailing list, = post regular updates of the document to get a chance to everybody to = comment, ... 
* All: please provide input to the Design = Team and copy the mailing list.

Design Team = Members
###################
Tim = Winter (Editor)
Pascal Thubert
Stephen = Dawson
Kris Pister
Thomas = Clausen
Jonathan = Hui

=    Anders Brandt

= * draft-ietf-roll-urban-routing-reqs
= * draft-ietf-roll-industrial-routing-reqs
= * draft-ietf-roll-home-routing-reqs
= * Roll@ietf.org
https://www.ietf.org/ma= ilman/listinfo/roll

= --Apple-Mail-96-490413094-- From jvasseur@cisco.com Wed Apr 1 22:44: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 62E253A6971 for ; Wed, 1 Apr 2009 22:44:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.326 X-Spam-Level: X-Spam-Status: No, score=-10.326 tagged_above=-999 required=5 tests=[AWL=0.273, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mkYu6+ZV3-iu for ; Wed, 1 Apr 2009 22:44:28 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id DBAA43A6BD7 for ; Wed, 1 Apr 2009 22:44:27 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.39,311,1235952000"; d="scan'208";a="37267491" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 02 Apr 2009 05:45:24 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n325jOUk001742; Thu, 2 Apr 2009 07:45:24 +0200 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n325jOIh022794; Thu, 2 Apr 2009 05:45:24 GMT Received: from xfe-ams-332.cisco.com ([144.254.231.73]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 2 Apr 2009 07:45:24 +0200 Received: from ams-jvasseur-8712.cisco.com ([10.55.201.131]) by xfe-ams-332.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 2 Apr 2009 07:45:23 +0200 Message-Id: From: JP Vasseur To: Tzeta Tsao In-Reply-To: <49D218CC.6040304@ekasystems.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Thu, 2 Apr 2009 07:45:22 +0200 References: <49CB86DA.9050104@eecs.berkeley.edu> <49D218CC.6040304@ekasystems.com> X-Mailer: Apple Mail (2.930.3) X-OriginalArrivalTime: 02 Apr 2009 05:45:23.0695 (UTC) FILETIME=[378767F0:01C9B356] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2114; t=1238651124; x=1239515124; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:=20JP=20Vasseur=20 |Subject:=20Re=3A=20[Roll]=20security=20update? |Sender:=20; bh=6Y0PJwFYIUQxiFrv0ygo49uhcbBuM/UEvc5JuP2Dj8g=; b=U24zpQjQZNBdxUuoe9CgGUKFZoF9meR+nCQttVaNGh+vfsoCQgXbtq1oRE YUntcK7voVPJoOz8h3H/n4MkwypKAVcq2HNli9sernbTUxssmg+JhsEeZ2u+ 8xUALhNkRC; Authentication-Results: ams-dkim-2; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Cc: ROLL WG Subject: Re: [Roll] security update? X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 02 Apr 2009 05:44:29 -0000 Hi, On Mar 31, 2009, at 3:21 PM, Tzeta Tsao wrote: > Hi Kris, All, > > We are indeed working on an update to the security draft and will > present it once the revision is in shape. At the same time, I welcome, > and I believe other authors, too, any comments and suggestions. > All, please provide some feed-back to the authors. Just so you know, we are also looking at other contributors to help there. This is a key WG item and we do want to address these aspects in parallel with the routing design effort and clearly not at the last minute. > I share the view that security should be an integral part of a ROLL > protocol, but not an after-the-fact extension. In fact, even > considering > such diversified applications and capabilities of the LLN devices, I > still hope this working group will come to the consensus that the > stipulation should be such that an implementation of a ROLL protocol > may > choose not to conform rather than be given the choice of reduced > security services. Security requirements do vary with the applications and can range from none to high level of security. Thus the routing protocol must be designed to turn on or off several of the security features. Thanks. JP. > > Regards, > Tzeta > > Kris Pister wrote: >> Since we weren't able to get an update on the security draft at this >> meeting, perhaps we could get an email summary? >> >> I'm confident that we can come up with a good routing protocol, and >> I'm 100% certain that the networks it serves will be attacked. We >> need to come up with something that is strong, but simple enough that >> everyone uses it by default. My strong preference would be that >> security is an intrinsic part of the routing protocol, and can't be >> "turned off". >> >> ksjp >> _______________________________________________ >> Roll mailing 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 Thu Apr 2 07:33: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 958973A6B32; Thu, 2 Apr 2009 07:33:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.61 X-Spam-Level: X-Spam-Status: No, score=-6.61 tagged_above=-999 required=5 tests=[AWL=-0.012, 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 XF7SnvyPrnsM; Thu, 2 Apr 2009 07:33:05 -0700 (PDT) Received: from exprod8og113.obsmtp.com (exprod8og113.obsmtp.com [64.18.3.26]) by core3.amsl.com (Postfix) with ESMTP id 1F56F3A688A; Thu, 2 Apr 2009 07:33:04 -0700 (PDT) Received: from source ([192.132.24.137]) (using SSLv3) by exprod8ob113.postini.com ([64.18.7.12]) with SMTP ID DSNKSdTM2ori+qUE4cWMRbddF4CqR5yEF40G@postini.com; Thu, 02 Apr 2009 07:34:07 PDT Received: from jwimkrs1.na.jci.com ([10.10.6.31]) by smtpmke01.jci.com (Lotus Domino Release 8.0.1) with ESMTP id 2009040209335402-27413 ; Thu, 2 Apr 2009 09:33:54 -0500 In-Reply-To: <49C93116.20102@eecs.berkeley.edu> MIME-Version: 1.0 To: "David E. Culler" X-Mailer: Lotus Notes Release 6.5.2 June 01, 2004 From: Jerald.P.Martocci@jci.com Message-ID: Date: Thu, 2 Apr 2009 09:33:48 -0500 X-MIMETrack: Serialize by Router on jwimkrs1.na.jci.com/NA/Johnson_Controls at 04/02/2009 09:33:51 AM, Serialize complete at 04/02/2009 09:33:51 AM, Itemize by SMTP Server on smtpmke01.jci.com/JCI_SMTP(Release 8.0.1|February 07, 2008) at 04/02/2009 09:33:54 AM, Serialize by Router on smtpmke01.jci.com/JCI_SMTP(Release 8.0.1|February 07, 2008) at 04/02/2009 09:34:07 AM, Serialize complete at 04/02/2009 09:34:07 AM Content-Type: multipart/related; boundary="=_related 005000488625758C_=" Cc: roll@ietf.org, roll-bounces@ietf.org Subject: Re: [Roll] Polling WG for adoption of Metrics Draft X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 02 Apr 2009 14:33:06 -0000 This is a multipart message in MIME format. --=_related 005000488625758C_= Content-Type: multipart/alternative; boundary="=_alternative 005000488625758C_=" --=_alternative 005000488625758C_= Content-Type: text/plain; charset="US-ASCII" Good draft. Comments below. Mainly grammatical and typos. I approve moving this document forward. p5. "It is also worth mentioning that it fairly common for link in LLNs to ..." s/b "It is also worth mentioning that it is fairly common for links in LLNs to ..." p6/s3. "In LLNs, it is not uncommon.." might read better as "In LLNs, it is common" p6/s 3.1 "Units to be determined" seems like an editors note that should be deleted. p6/s 3.2 This is somewhat of an erroneous statement and merits more consideration. While it might be true that the communication processing eats up 10% of the processing power, you fail to note that in LLNs the devices deployed have a primary application (e.g controlling HVAC) that will require most of the processor's bandwidth. This is somewhat different than other communication networks where there are dedicated communication device deployed such as switches and routers. I think the CPU resource metric is important, and would read better if it stated that the metric will limit the communication processing to less than or equal to 10% of the processor's bandwidth. That saves the other 90% for the application layer. p6.s3.3 "scavening" s/b "scavenging" p6.s3.3 Also in the same sentence, you are noting that the routing path may indeed be a longer (more hops) path to to steer around energy starved devices. This is ok. However, you then note that the devices that are not energy starved are "mains-powered nodes or nodes equiped with energy scavenging". In my experience energy scavenged devices have even less available disposable energy than battery powered devices. They should NOT be considered in the same light as mains-powered devices. p8/s3.4 "Algorithms used to set the overload bit and to compute path to potentially avoid node..." s/b "Algorithms used to set the overload bit and to compute paths to potentially avoid nodes ... p8/s3.5 "Applications where high directional data flow is expected in a regular basis..." s/b "Applications where high directional data flow is expected on a regular basis..." p8/s4. "Even in case ..." s/b "Even in the case ..." p9/s6. "shoudl" s/b "should" "David E. Culler" Sent by: roll-bounces@ietf.org 03/24/2009 02:14 PM To roll@ietf.org cc Subject [Roll] Polling WG for adoption of Metrics Draft The ROLL charter includes the following work item: * Specification of routing metrics used in path calculation. This includes static and dynamic link/node attributes required for routing in LLNs. The following draft has been submitted and discussed at the ROLL WG meeting during IETF 74: * http://tools.ietf.org/html/draft-mjkim-roll-routing-metrics-03 The consensus at the meeting was that it was ready to WG polling. I would like to poll the WG for adoption of this draft as a WG draft. Please respond to the list to establish consensus. Also, please provide feedback to the authors on the draft through the list. Thanks, David Culler _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll --=_alternative 005000488625758C_= Content-Type: text/html; charset="US-ASCII"
Good draft.  Comments below.  Mainly grammatical and typos.  I approve moving this document forward.


p5.  "It is also worth mentioning that it fairly common for link in LLNs to ..."   s/b  "It is also worth mentioning that it is fairly common for links in LLNs to ..."
p6/s3.  "In LLNs, it is not uncommon.."  might read better as "In LLNs, it is common"

p6/s 3.1 "Units to be determined" seems like an editors note that should be deleted.

p6/s 3.2 This is somewhat of an erroneous statement and merits more consideration.  While it might be true that the communication processing eats up 10% of the processing power, you fail to note that in LLNs the devices deployed have a primary application (e.g controlling HVAC) that will require most of the processor's bandwidth.  This is somewhat different than other communication networks where there are dedicated communication device deployed such as switches and routers.

I think the CPU resource metric is important, and would read better if it stated that the metric will limit the communication processing to less than or equal to 10% of the processor's bandwidth.  That saves the other 90% for the application layer.


p6.s3.3  "scavening" s/b "scavenging"

p6.s3.3  Also in the same sentence, you are noting that the routing path may indeed be a longer (more hops) path to to steer around energy starved devices.  This is ok.  However, you then note that the devices that are not energy starved are "mains-powered nodes or nodes equiped with energy scavenging".  In my experience energy scavenged devices have even less available disposable energy than battery powered devices.  They should NOT be considered in the same light as mains-powered devices.


p8/s3.4 "Algorithms used to set the overload bit and to compute path to
  potentially avoid node..." s/b "Algorithms used to set the overload bit and to compute paths to
  potentially avoid nodes ...

p8/s3.5 "Applications where high directional data flow is expected in a
  regular basis..." s/b "Applications where high directional data flow is expected on a
  regular basis..."

p8/s4. "Even in case ..." s/b "Even in the case ..."

p9/s6.  "shoudl" s/b "should"






"David E. Culler" <culler@eecs.berkeley.edu>
Sent by: roll-bounces@ietf.org

03/24/2009 02:14 PM

To
roll@ietf.org
cc
Subject
[Roll] Polling WG for adoption of Metrics Draft





The ROLL charter includes the following work item:
* Specification of routing metrics used in path calculation. This
includes static and dynamic link/node attributes required for routing in
LLNs.

The following draft has been submitted and discussed at the ROLL WG
meeting during IETF 74:
* http://tools.ietf.org/html/draft-mjkim-roll-routing-metrics-03

The consensus at the meeting was that it was ready to WG polling.  I
would like to poll the WG for adoption of this draft as a WG draft.  
Please respond to the list to establish consensus.

Also, please provide feedback to the authors on the draft through the list.

Thanks,

 David Culler
_______________________________________________
Roll mailing list
Roll@ietf.org
https://www.ietf.org/mailman/listinfo/roll
--=_alternative 005000488625758C_=-- --=_related 005000488625758C_= Content-Transfer-Encoding: base64 Content-Type: image/jpeg Content-ID: <_2_0E2BBB240E2BB9DC005000488625758C> /9j/4AAQSkZJRgABAQEASABIAAD/2wBDAAgGBgcGBQgHBwcJCQgKDBQNDAsLDBkSEw8UHRofHh0a HBwgJC4nICIsIxwcKDcpLDAxNDQ0Hyc5PTgyPC4zNDL/2wBDAQkJCQwLDBgNDRgyIRwhMjIyMjIy MjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjL/wAARCABZAn4DASIA AhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQA AAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3 ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWm p6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEA AwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSEx BhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElK U1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3 uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwD1TxT4 nvdEvo4LaK3dGiDkyKxOckdiPSsAfELVicfZrL/vh/8A4qvSqK66delGKUqd36nmV8HipzcoV3Fd rf8ABPOR4/1XH/HvZ/8AfDf/ABVH/Cfar/z72f8A3w3/AMVXo1FV9Yof8+/x/wCAZ/UcZ/0EP/wH /gnnP/Cfar/z72f/AHw3/wAVR/wn2q/8+9n/AN8N/wDFV6NRR9Yof8+/x/4AfUcX/wBBD/8AAf8A gnnP/Cfar/z72f8A3w3/AMVR/wAJ9qv/AD72f/fDf/FV6NRR9Yof8+/x/wCAH1HF/wDQQ/8AwH/g nnP/AAn2q/8APvZ/98N/8VR/wn+q/wDPvZ/98P8A/FV6NRR9Yof8+/x/4A/qOL/6CH93/BPOD4/1 X/n3sv8Avh//AIqg/EDVR/y72f8A3w//AMVXo9FL6xR/59/j/wAAf1HF/wDQQ/u/4J5v/wALB1X/ AJ97P/vh/wD4qk/4WFqn/PtZ/wDfD/8AxVek0UfWKP8Az7/H/gD+pYv/AJ//AIf8E82/4WHqn/Pt Z/8AfLf/ABVJ/wALE1T/AJ9rP/vhv/iq9Koo+sUf+ff4/wDAH9TxX/P/APD/AIJ5r/wsTVP+faz/ AO+G/wDiqT/hYup/8+1n/wB8t/8AFV6XRR9Yo/8APv8AH/gB9TxX/P8A/D/gnmf/AAsbVP8An1s/ ++W/+KpD8R9V/wCfay/74f8A+Kr02ij29H/n3+P/AAB/VMT/AM/vw/4J5gfiRq3/AD7WX/ft/wD4 qj/hZGrf8+1l/wB+3/8Aiq9Poo9vR/59/j/wA+qYr/n9+H/BPLz8SdW/59bL/vhv/iqP+Fk6t/z6 2X/fD/8AxVeoUUe3o/8APv8AH/gFfVcT/wA/vw/4J5d/wsrVv+fWy/74b/4qj/hZeq97Wy/74f8A +Kr1Gil7ej/z7/Ef1bEf8/fw/wCCeXf8LL1X/n1sv++H/wDiqT/hZmq/8+tl/wB8P/8AFV6lRR7e j/z7/Ef1bEf8/fw/4J5afiZqg/5dbL/vh/8A4qkPxO1Qf8ull/3w/wD8VXqdFHt6P/Pv8R/V6/8A z9/D/gnlf/Cz9UHW0s/++X/+KoPxQ1P/AJ9LP/vl/wD4qvVKKPb0f+ff4j+r1v8An5+B5V/wtLUw P+PSz/75f/4qk/4WnqX/AD52f/fL/wDxVerUUe3pf8+/xH7Ct/z8/A8o/wCFqap/z52f/fD/APxV N/4Wrqn/AD52f/fD/wDxVes0Ue3pf8+/xD2Fb/n5+B5N/wALW1P/AJ87P/vl/wD4qk/4WxqX/PnZ /wDfLf8AxVetUUvb0v8An3+P/AH7Gt/z8/A8k/4WzqX/AD5Wf/fLf/FUf8La1H/nytP++W/+Kr1u ij29H/n3+P8AwB+yq/z/AIHkf/C3L/8A587T/vlv/iqP+Fu3/wDz5Wn/AHy3/wAVXrlFP29H/n3+ P/AH7Kr/AD/geRf8Levv+fK1/wC+W/8AiqP+Fv33/Pla/wDfLf8AxVeu0Ue3o/8APv8AH/gD9nU/ n/A8h/4W/ff8+Vp/3y3/AMVSj4vX5OPsVp/3y3/xVeu0UvbUf+ff4/8AAD2dT+f8DyMfFy/LY+x2 n/fLf/FU7/hbOoE4Fnaf98t/8VXrVFHtqX8n4kujVf2/wPJz8VtR/wCfO0/75b/4qnf8LT1L/nzt P++W/wDiq9Wope1pfyfiQ6Fb/n5+H/BPLP8AhaGpYz9jtP8Avlv/AIqnD4namRn7Jaf98N/8VXqN FHtaX8n4k/Vq/wDz9/D/AIJ5ePiXqZGfslp/3w//AMVTh8SdUP8Ay6Wn/fD/APxVenUUva0/5PxF 9WxH/P38P+CeZD4kaof+XS0/74f/AOKp3/CxtUP/AC6Wn/fDf/FV6XRSdWn/ACfiL6rif+f34f8A BPNR8RdUP/Lraf8AfDf/ABVKPiJqf/Praf8AfDf/ABVek0UnOH8ofVcT/wA/vw/4J5v/AMLC1T/n 1tP++W/+Kpf+Fhap/wA+tp/3y3/xVej0VPNHsH1XEf8AP78P+Cecf8LB1T/n1tP++W/+Kpf+Fg6p /wA+tp/3y3/xVejUUuaPYf1XEf8AP78P+Cedf8J/qf8Az7Wn/fLf/FUf8J/qf/Ptaf8AfLf/ABVe i0VLa7B9VxH/AD9/D/gnnf8Awn2qf8+1p/3y3/xVH/Cfan/z7Wn/AHy3/wAVXolFS7lfVq//AD9/ A88Hj3U/+fa0/wC+G/8AiqP+E81P/n2tP++W/wDiq9DoqeV9x/V63/P38Dz3/hPNT/59rT/vlv8A 4qj/AITzU/8An2tP++W/+Kr0Kik4S7j9hW/5+fgefDx3qf8Az7Wn/fDf/FUf8J1qf/Pvaf8AfDf/ ABVeg0VHs5/zD9hV/wCfn4Hn3/Cdan/z72n/AHw3/wAVR/wnWp/8+9p/3w3/AMVXoNFS6NX+f8Bq jU/n/A8+/wCE61P/AJ97T/vhv/iqP+E61P8A597T/vlv/iq9BoqXQrf8/Pw/4JXsqn8559/wnep/ 8+9p/wB8t/8AFUf8J3qX/Pvaf98N/wDFV6DRU/Vq/wDz9/D/AII/Z1P5vwPPv+E71P8A597T/vlv /iq7HQ7+XU9HgvJlRZJN2QgIHDEd/pWhRWlGjVhK858y9CoRknq7hRRRXSaBRRRQAUUUUAFFFFAB RRRQAUUUUAFFZ0+tWkMgiD+ZI0D3CBejKnXn8aoWvi/T7i5sYnzCt5ZG8ikkYAbQQCv1GRVqlNq9 iPaw7nQUVFb3EV1Ak8Lbo3GVOCM1LUNWKTTV1sFFFFAwoqO4uILS3kuLmaOGCJS8kkjBVRR1JJ4A p4IIBByD0IoAWiignAyelABRVBNb0mXS31OPVLJ9PTO+6W4QxLg4OXzgYPvV2ORJoklidXjcBlZT kMD0IPcUAOooooAKKKq2Go2up27T2cvmxLLJCW2lcOjFGHIHRlI/CgC1RRRQAUUUUAFFFFABRRRQ AUVFFcwTyTRwzxyPC+yVUcExtgHDAdDgg4PYihbq3a7e0WeI3MaLI8Icb1UkgMR1AJBwfY+lAEtF FFABRRVXUNTsNJtTdalfW1nbghTLcyrGmT0GWIFAFqikVldFdGDKwyCDkEUtABRRUTXVul1HatPE txIrOkJcB2VcBiB1IGRk9sj1oAlooqIXMDXLWwmjNwiB2iDDcqkkAkdcEg8+xoAlooooAKKKKACi iigAooooAKKypPEemxav/Zkj3C3G9Y95tJRCHIBC+dt8vJBGBuzkgdeK0opVmTeocDJX50Kng46E A4469+o4o8w62H0UUwTRNO0AkQzIodoww3BSSASPQ4P5H0oAfRRRQAUVVfUbWPUotOaQ/apY2lVA hI2ggEk4wOvAJycHGcHDbXVbG9spLy3uFe2jLBpSCFwOSQT1XHII4IwQSKAsXKKzn1yxTRU1fdO1 m6qylLaRpDuIAHlhd+ckDGM0y48Qafa29rPObqOO55TdZzZQccyDbmMDIyX2gd6A6XNSiqr6jax6 nFpzSH7VLG0qoEJG0EAknGB14BOTg4zg4STUrSLUY9PeXFzJE0qptJG1SASWxgdeATzg4zg4LgW6 KxYvFmiyxPILqRQjqm2S3kRn3Z2sqsoLqQrHcoK4VjnCkizd65p9lqMNjcSyLPMVCkQuyKWOFDuA VQseBuIyeBmgDRooooAKKKKACiiigAooooAKKKKACiiigAoqnp+rWOqed9huUn8hzHJtz8relSX1 5Fp9hPeT7vKgjMj7Rk4AycCnyu9raiurXLFFU9K1O31nS7bUbTd5FwgdN4wce4q5Q007Mad9Qooo pAFFFFABXMa3r7W094sbAQWduWlb+9I3Cr+tdPXmusiLUNYOj28oMEcputSuO3HOD9BXVhIRlJ83 Q87MalSEIqHV/wDDL79X5JlY3zW+oW8bt81poEryexYZOf0rkm1GC2g8BXl6vnRRmeN4vVd+B/Sr d5qRm03xLr+NiXO2yth/sk9B7bVx+NYOqxbx4J0xsbinmkf7MkuR+gr1VD7/APgP/M46TvFpaq36 pL8j2mw1SU2w1rVJmt7dvltbSPuOgOO5rqI38yJH2ldyg7T1FcI0qXvjMpLj7JpqEqnbCj/Gup0D UZdU003UoALSsFA7AHivlaeJU6vJ62+W7/E9HCt2abv+r6v/ACNSiiius7Dm/H3mSeB9WtIbe5uL i8tpLaGO3geUs7qQM7Qdo/2jgDua51Idebx7ObrUdRtoYpALWCOyuZIZofIHBkV/IX5y/LJvyB82 CBXoF1cpaRLJIGIMiR/L6swUfqRUc2pWFvfQWM17bR3lwCYbd5VEkoHXapOTj2o1tb+v6/QDzrQ9 G1m8TwtBqV14hRLjSJpdRZry4jYXH7kIGYMChHzYUYzhs5y2dTwFdarqI1R9SmuXbTwuk/vHys0s JbzJgPVty89flx2rqR4i0Qi9I1jTyLE4uz9pT/R+SP3nPycg9cdKpW+uaTbaA2o6dag2z3UkUcdu I08+YzFCVJYJl3yQSwzuHc03dp/1vt+qBRsv67f8C55zpWga1Do9voh066XTrnT01KffEeJ44fL8 jBGVYuIZAOp2tWhq0uv21/4fis7bVITbwaeP3MF3IkoL4mVwjiGPYo58xWJDcYwK79PEukfa5LOe +htb2G2F1PbXEio8MfOWbnGBg5IJA4PQgnM1X4h+GdJjtJZNUtZ4bmOSVJYLmIrsT7xBLjdz8oC5 JPbg4Sdnf0/C/wCmnyG1zO9u/wCNn/wfmcnJol7c2+n6nqg1+WWHxFOZFW4usx23mTCMrEh+7ymG AztPXbTbpvFe68OmjWv7dDX/AJ5mEv2bycP9n8kN+5Lf6nGz5vvbu9d5/wAJGZINMltNJvbv7fEZ lWCW3PlINvzMxlCkfOPuFqurrWlNLdxLqdmZLNN9ygnXMC88uM/KODyfShXjo/P8kv01Fu0/63f+ f5HGnzPtuiiE+J/7F8ubbkXPnm53R+X5m795s/1v+t+T1+XbW/4O/tD+yLr+0vtXnf2jebPtO7d5 fnvsxu527cY7Yxjir9pr+l6golsb+1urXY7NcwXEbxrtIyCQ3X5h2wO5HGQ+IdEXTP7TOsaeNP37 PtRuU8rdnGN+cZzxjNNv+vn/AEvuEjSoqrLqenwXtvZS31tHd3ILQQPKoklA5JVc5bHtTre/s7yW eK2u4J5IG2TJFIGMbejAHg/WkMsUUUUAFFFFABRRRQB5jL9vku7+++za1Do15roe5+zQTxXLwLaK gYKgEwXzUUHaASB/dzWXBpviIyahqbw6wt5Fp1qbJ1aZXkC3M5RZAD+8YRMm5Xz1+YZr0uHXvMS/ lk0y9gtrRnVZ38plnKsVIQK5bqP4gvUVD/wkczWMk8egao88MpjntN1uskPyhtxLShCpBHKsevqD huX4W/KwpRvdf1vc4pbbxF5PnNca5DLcT6pBNJieURQh3MLLFkcjjaVwxGAp6U3zdWfR9I/tO18Q QWQtbsOuny3skr3IdRE7H/XqrL5hCycDIDdBXe3GuPDpdjeRaTf3Et4VCWkflLKpKF/m3yKowAc/ Mfxq7c3otNLmvpYJcRQmVoRtL8DJXrtz26496TTV0/6/r8xr89TzrS4fFa3SXepHVDexaraRsqyS eQYmtohOQgOxk37+cEKc4wc10fiAy2HjDRdXmtbu402G2uYX+y27ztDK5QqxjQFuVV13AHGcHGa1 3162WHT5BFM/20gKqhcx8cl8njBIU4zyR9al/tvTkezhnvLeC6vI/MgtpJ08yQYydoBO7H+zke9N vr5/pa36kpL8P1/r7jhLg6w3iGbyINahu/t8H2KNVmWzSx8tDIGC/ud3+t+98+7bjtWNPpWvXXha zjvY9enabS7O5vVeW4ZxPHPHuwM5V9m4lVAJIzgsAa9RtNf0/ULUT2NxFcgSJFIkU0ZaF2x8r/Nw RnkdfQGmP4o8PRPdpJrumI9n/wAfKtdxgwc7fn5+Xkgc96VrK39bf0/XUrrf+t7/APA9Dirm31kx +ILuCTXvs639rHAgkn3/AGIpAZjGh+YtjfyAXB3YwxOaEdlrFxrLTxDWYNPWy1KKxu54J5biGNvs +3cHIlLbhKVUkOVAx2r0sa5pLS2kQ1SyMl4oa1QXCZnGM5QZ+YY54qObW4IdWawMMreVEJbicMgj gU52lwWDYO1uQpHByRQ3bf8Ar+v1fcVtPx/H+vuXYxvB2qXH9mabp19YXkV7JFNI7SSTSAKj7Q7G c+au/OVVgSBkdqyvFdtq48R3txpsV8vmRaXGJrZX5UXb+aMjsEOW9AeeK6u18T6DeWNpewaxYtbX efs7mdV8wjqBk5yO46jvUh8Q6KNKXVTrGnjTmO1bs3KeSTnGA+cdeOtD3TfRlXsnHv8A1+hw9tFq 9trkVpenXzo8F1dJbNC88kjSbojDvflmjwZcGQmP+90FegWF79uilk+y3Nv5czxbbiPYW2sRuHqp xkHuKista0zUb68srO+gnurJglxEjgtGSARkemD16ZBHUGr9CfupPt9/mK1mwooooAKKKKACiiig DnrjTtWn1K7g8qyXTbi4inNx9oczDYI8r5ezHJT72/jOcdqePDqS3drPdJBI9sLgwsRuMbySBldQ RgMB36jJx1NB1yeDVNUguEjaGED7IEUhnYKhKkk4JLSLjGOvtmo7TxHMkdtHeWUs0nC3V1bKqwQs WKjIZ9/JHRQ2MjOKOi/roD3MTSvBeo6fo2pWkyWd0biaN/s80sYguQpyxkEdtHgv/ESJM4GSQOdK 28MLb6rJfroWiL52lJZtApwsZUt+7U+VzGwYAnAwEHyntZj8SSyRXiyWVxbtEs7RXLxq0UvluVOF 3h8jjrtB7HFakF7LJcTxmAusdz5O6PA2L5Ybc2T6nHGTyOOppq/9fcC0f9epdUYUDAGB0HQUtFFI Dnv+Ecuk8URasmtXrQbpHktXEOzLKAAD5e/HHduw96ji0rWdRtr2DUXj0vzLlbiGXTboTscY4YSw BQPlB6HPtjlB4vsZfGUWhw6lpuQJI5IDMPtBlUBgAu7IAGeoOecY28zS+If7K0i5u9ansbaSO48h WMnlxBiAVBdvTOC3GcZwOlTG2tv62/4A35/1v/wSIaDeweDE0h3/ALTuV25aa8a0zh9wxLDHuXGB jC545Peo7jT/ABCmk6fYwwWF5GA32tLrUJVJGQUQSGJ2kUDIJYAtgZ6kUsXiK5vfAsOsWFxa3Nyw QNLa2sl1HneFcrFGxdsDJ2hsjHWkvdb1GLSNNvrS8tpfMOJ92lzhZCOoJ3/6NjDAmTdg9emC42sr baCe135lgeHLpPE8WrJrN60G6R5LRxCUyygAA+Xvxx3bsPeo5/C1zJr/ANvXW7428gl822YQ7RvU KApEe/HH9/jAx3pB4vsZfGUWiQ6lppOJI5IDMPtBlUBgAu7gAZ6g55xgLzY/tLU/7ajObQ6bJcta CLymEwYIW3792CMqRt29Dnd2qOWMtP66f8Ad2v6/rzKMum+InsLlvsmlNePDHaqn22RYzGu4+YW8 okMS33MED+8at3Gnatc3a7obJLa58mW6IuXZ4XjIJWMbMOpwBklMcnB6VV1HXNZtdOGPskd2bwwM 0drJcrGuzcMRqyvJ2UsMd2KgA404NRvZp9Kf/QzaXcG52icuWcqW+UjjaMded27tj5tdXq/6/r+t CdE7Lp+mhsUUUUhhRRRQAUUUUAFFFFABRRRQAUUVn60mqyaa6aNLbw3pI2vcKWVR34FNK7sJux47 p2u6hpNjf2WlSrBd6nrzWwuGXIiHUn681tahf61oOqal4Z1HVH1W1utKlnilkTDxsFOc+3B/Suhs fhxZf8ItJpWq3D3NxPcG7kuY/kZZT3T0Apy+DNC0SG/vdU1S4lmu4DbPe3043JGRjCk8CvSlXpNu 2vy37O5zKnNI4zSJNe8OeHvCepxa7JNa3cscDWLxjYsbHoPf3q7c3vibUG8V6jD4jmtV0Wd1hgSI bHVQThvyxXXW3hvQtX8P6VYWeom4tNMkR4pIZVYkr03ECrkfg+wjttcgEs+3WWZrg7hlSwIO3jjr 3zUyxELtta+nS/8AkNU5Wt09fI4LWPEviCe30XUry9vNN0W4sUllu7GASBZj13+i1qS6nrHirxa+ haVrpsrKzso52u4VBe5ZgCD7DnpWxd/Du1u9Pg07+2NVisYrdLc28cwCSKvTcMdafefD7SLqa1ms Lq706e1gFsJbOXazRgY2tS9tRtp59Ng5J/0zix4x8R3mjWunf2iIL4asdOmvI4gd6dmA9fpXT+GL rWNO8c6h4c1DVX1K3jtVuIpZUw6knkVow/D7RrfT9Ns4DPGljc/ag4YFpZO5ckc5rS/sOytPEN14 jaWQTvbCKQEjYEXnOMZqalak04xW9+nW+g4wmmm2bNedeLbC+lvR4e0LTzCt+fOu7r+FhnkZ9BXd abqdnrFhHfWE4ntpM7JACAcHHejVLH+09MuLL7RLb+chTzYThlz6VhRqOlPX+v8AhgxFFVoW/r+m eI6xax61rmmeDtFYSWlkT50w6PIf9Y5PoBxWFfahFqfxPhltDmysJEjhI6eXFxn8cfrXoereE7/w h4TnsvC1hNf6jegpcXvAdE9AM/yqp4H+H2oaBAW1OxScalGEmVCN9sM5HJ79zXpuvD2bcX0aXd92 edUpThBpLV9unRf8E6BbZU8XThiBBqcDGJ+3zCuv0axOnaTBbNjeq5fH97vVXSdD+xWkVvdul0Le QtbsV5Qdq2a+bpYaMKjqddbejPQw0JRjeSs2FFFFdR0lHVrO4vtPaG1uIre4DxyRySxGVQVcNyoZ SRxjqKxbnwrdXutWOp3GpKXiEZuYo/tMccrI25SqLOEXn++snatnV557WxFzAwXypUaUMODHuAft 2Uk/UCsiw1W/uLn7PJOheSZrmMqgH+iFSU9ed2BnvSvbXt/X9enoG6t/X9f5+pAnhHUE1C/vTrKS TSur23nRTSrEQ+8bleYqR2xGIx37DGguhXMPh2bTYru1aaaWWSR7iz8yF/MdndWi3glfnIxu9OTz mH/hIbq2tTM1kZrW30+O6mnaXMrMwbCrGifMfl5Ix1GAelJpviK51G2tLieymsm+0SRzRNFKocLE zgr5scbkdOdo5BHPU01ZOPRApXfN1f8AX6jYPC93axSLBqio02ni0dhAw2srOytGRICijzGG3JIA XDAjJq2/giZNMktbjVPNlktLu2aXy5G/1+z5sySu52+X0LHOeoAxTrPxjfX2jX17BoM/mwFGijkj uY1kjbvlrcOWABJVEfqME540bHXbq5v7mCWyijijtlnhkSWRzOCATtzGFIBOOGJ6ZVcijmcZOXX+ mOMnGzj02/Ibr3h19XvdNuo/7LL2RYqL/T/tWCSh3J867GGzrz1qLU9AdNJuPsiebcCC6VEjUIzm Zw5wdy4OR/eXJ/iXqI7K9v7XSItRbU11S41BImhtpGjigR3I+46JuEeWxlt54GMnq658TahDaLJF pEMs0Uc0l0gvMKgiYK4jYp85OflyFBxyVoa+z6/8EIvVWK2haBez+Hmt9UjaCR4Z7dkmBkdlkYHc +6abJ4PHmNkY6fdFvW/CrapHM1tfNaXD3IuFdTMgB8tYyG8mWNm4X+8O3BxUNx4n1a3NzGdDgaa1 8ySYLffL5SLG2VJjyXIk+6QBlT82ME6NlrNzLcfZr2yjt5vtTW+I7jzFI8rzAwJVTnHBGODnkjkj u0LYzZPBmdT0y5ivmSC0jhSS3Mtztk8o5UgCcL1/56LITxmuhsLJLC2MCFSDLJISF28u7Of1b8ax LHxNdahNAy6dGlhORGtwt0GfeYRKCE24KY4zuzn+HHNKdev0tke3tIJ4obJJ7iW5umSTLISoVI4m 35IwSAvX5QTxQ20tfX7wtZqJ0lFcfpnirVtU1HT4f7Lt7eGaG5a5EksyyRmNkAKLJChOfMHDKvX0 A3XLDxBdyvbB7RGs3Cwm4a5BmMxjD8xhAu3HfIP+zjmk9FcHpY6SiuSPivVUt45ZNDhQOIZd32t3 WOGTd8zlImKsCvIwUAOS4GcdbTasD0dgooopAcvB4SZLzVLp5NNhlvVYK9jp3kMWLbg8xLt5rAgY Py9W9eLq6HdTabcW99fQyz3kqvdvDbFI5IxtBjCF2IBRdpJY9SfTGcurX4jvrFrs/bLieX7FLtTK Rh2VsDGDsCZyQc7lBzmrdnqd5KtsQ7SO821lfaA3+j78AheBu57nrzjgC017A3aXm2TeJtA/4SCw t7fGnN5M4l2ahZfaoW+VlwU3rz82Qc8Yq5JZXFxpVzZXE8OZojErQwFAgKAHgsc85PUcEDtk51l4 pivZY0W2aMShGjMj4yCm58jHGzofciodB8VTas4judO+yyGfyl5mAZfLZww82KNj90jhcehPNNdQ vsW08P7bm5lN1lJJ0khj8viFQdzKOedz7mJ9wO1Lb6Pe2d5C1vfW4tvs8cFxHJalnk2KQpRw42de QQ3tjJqnbeKRNqlvCIyUurOK6TOdiqQ5YK+3DuQBhepAJ4ANVLfxxNNot5ftot0jxNGIENvdATBz hetuHz/e2I4GRyc0ujX9dhNa3e5rweHo7dIFjkRRFDawjbEBkQsWHfoc9O3vXM2Hh/XrmfW4H8/T kuHzFcyySHpIWwnl3ZIUgnOwQduDyB2Wj6g+qaVBeSWstrJIDuiljdCpBIPDqrY4yCVUkYOBWGdb vrW6j+03EfkWUkqX/wAgyysxELZ4xwBkAclvaiTfNqUm9/T8NixYeFltLBIJbhJpQturS+UfmMUp kH3mZupOMsSOuSasX+i3N9rlnem6tlt7ZtyqbXNwp7hJt42o2BuUqcjIz0xFb3GrTaJqq72bUY02 wiNUBWQwowA3fL95j97j14qgJtVuPDDrBc+IF1G3nKShlsPtIOM4bjydmGU/L82PfIpttb+ore7b oy1D4Uxo8Gn3N4JPIsZLGOaKMxOIyV2nIbIICLkgjJ5G3pVE+B7k6Gtp/a7rfLcm4+1LLeYYlQmD /pXmH5R/z1x7VcgvL+S7ivLfUmvIvsnmT2yRIsKfuwylTt372bBwWxtJ4HBqkJtS8qWBvEl0xlhh uYZYYLcy733/ALqPKFSp2gjILAA5bHITe9/61f6oL8zu/wCtv8zb0PQ30SS5VLhHtphEVj2NuR0j WMnezsSpCLgHkHOWOeNisyS5uoF0hLh41mmlEdxs+6zeU5IGe24DFY15qt8JY7uO9f8As+3nm+0m 28pmVVkKjerDJjG1gShDggdecN3crbib93mf9f1Y6yiua03xC954pubI/avsxDpF5llJHGGjIB2y lAr7sseGOAn1rpaXS4+tgooooAKKKKAKU2kWNxcRzywBpY7gXKtuPEgTYG6/3eMdO/XmoH8O6ZJe xXZimEkXRVuZFR/mLDegba+CSRuBx2xXMXFu8HjDXLq3s4RqDQn7Lcf2FK8ufJQD/SvuFcgjZ1z3 rVt4NdtNRXzdVvby3juWiKSW0Q82Mw7wxKovIf5QRgY4IJ5o6J/MbRox+G9LjubicQSs86ujb7iR 1UOcuEUsQm48naBnAz0q79jhEvmKHVjL5x2yMAzbdvIBwRjseMgHGRmuO8MXetahhtUjupfLum8t 7q2IdFMLdC1vDjnAyFPXG45wOm0gNHbW0LtcK6WcIaF4sIpwRkNt+9xgjJxgcDOSxa3/AK9DTooo pARPbxSXEU7LmWIMEbJ4DYz/ACFU9L0Sz0drhrRrwmdg0n2i9muOR3HmO238MZwPQVjancagDrd5 pcM/mqkMAZoZEbKs+9kzE+/AYYKo4J7GptLk1m8t9LkuriaICGWSdUh5mIZQgYyRIVJXJICJk9MA V0/VWo890l/wL/8AAJUuj/roa02k2k2mDTv9IitxjH2e5khcYOeHRgw/Oq8vhvTZoLWBxdiG2ztj W9mVZMnJ8wB8S5PXfuzk56nOD4dutZvmV79buQxXRMZuYmQgGFxgkwQ8ZxztPX7x6Cfw9JdDVb2+ vH1KYSW1tCXubIxlZfMl3Iqqgyql1+bkYOSxAzVzwcqXMrq8bbethqVzqHtopLiKdkzLEGCNk8A4 z/IVUXRbFNWbU1jl+0t1/fuY84xuEe7YGwMbgM44zWPpmpXjardPPcahPBH55ljNjiKILJhBGwTd IxUHIBfkdFOBU9zBrM+qOYtTure2e4MISO3jISPyd28FlJ3bxjJyvONueah4Vxk02lpe+v8Al/SA cPB2kCORA+qZkkEpf+1rreGwRw3mblyDyAQDgZzgYsv4b017ixmVbqL7CqrbxwXk0UahegMauFb0 OQcjg8VzMWpeJ21GWHdeZGnk/PanyxN5QIYDyAM7s/L5zdSNo7aUsWrWGtXjLqGp3a/2YpgV4EaN 5VZ9xO1AA4BTAyu7PfHy6SwUoOzkr2ut/wDIHLc6qiuOt76/aa1SS/1z7C0v7u5OmYmmbK/JKnk/ u05b5ti9PvDGTcspbm41ofaJL6SSO5bdDPYhIYF2yBTFJ5Y3ZG3J3t1x8ucVMsJKKbb29f8AL/hv XQnn8jpaK8qaOPUPEbxCOObWymwfvLTzoGZMmTLt9oXY5PC4UKFCq3WuslurgG2QT3tvbtdXALWN kJd7CYgJJiNtqkZy2B7sO+tXAOHKlK7f9dLhzas6miuavLqe20WwgRtQstsUX2iSx08yvECpwFTy 2X7y4ICnaCOBkGnLd358ReUJ9QKggCBrPFuYtmfM83Z9/dxt3D/d71h9Vk1e/fv0+Q+bujo6K5W3 i8QqIZJdUupDi1meM2kYBLuRLHwuQoXkc7lPJYjiuqrOrS9m/iT9L/qkVcKKKKyAKKKKACvMpLK3 8VfF6/stYHnWml2qNbWrn5GZsZYjv1/lXptcr4i8FJrGqw6zYajPperQrsFxCM719GHet8PNRbu7 XW/YzqRbSsZviGeLwabHTfC2nWlvqGs3IjDFfkXH8RHfrVCXxl4i8P3ur6RrBs7m8t9Pa+tbiJCq uB1DDtWndeAr7VLFP7T8R3M+owTrPaXSRKv2dgMYA7g0kXw8ecardatq8l7ql/bG1FwYwqwoR0Va 6Izo2993773+/tYzanfRWMm08UeLbKfw7dalcWF1Z624jWOOMq0JYZBz3xmqngqXxFZt4lvDeWcl vbXMzTRsjZeQKSNp7LnFdfceC1ntPDcH25h/YsqSA7B+92gDB9OlVIPA9/Z6nqjWmuGPTdRd5JbV oAx3MpHDe2c/hT9rScWlZX8vP/IXJO6Zz/8Awmfiiz8J2/iC4nsrg6kVis7RIiojdmxlj3AAq7Nr /iPRtYTQvEclpdpqVlM8M9smwxuqElSO4/xrbfwFa3Hge28N3F1I32bDRXSLhlcHIbH49KgsvAdy +qHU9c1qXU7uO3a3ti0YRYgwILYHU4NHtKDvt16fdb9R8tTT+vU4fSvFGraH4Q8NWtrNFp9jcRSG TUJoDKivuOFIGcfX3r2LS5ZJ9LtZZbmG5kaNS00P3HOOo9q41vAOpxeGoNCs/EPlWawtDMj2ivvD EktyeDziur0DRoPD+h2ml27u8Vum0M/VvU1niZ05q8d7sdKMk7M0qKKK4zcKKKKACiiigBskaSxt HIivG4KsrDIYHqCKjW0tklEq28QkEflBwgyE67c+ntU1FAEQtbdUZBBEFZBGVCDBUdF+nJ496gsd J03S7dLfT9PtLSFGLpHbwrGqsRgkAAAEjvVyigDKPhnQDa3NqdD037PdOJLiL7JHslcHIZhjDHPc 1ZttK06yu5ru10+1guZwommihVXkAGAGYDJwOmauUUbAZi+HdDRL1F0bT1S+ObtRaoBcHJOZOPn5 JPOepq1Fp1jBbJbQ2dvHbxxmJIkiUKqHqoAGAvA46VZooAha0tnaRmt4maRSrkoDuBABB9RgD8hU V7pWnalbyW99YWt1BIwd454VdWYYwSCMEjA59qt0UAQR2drEipHbQoqHKhUAAO3bkfhx9OKrXWg6 PfSRSXek2FxJDGYommtkcohGCoJHAIJGBWhRQBn2+g6PZxW8VtpNjBHbO0kCRW6KImYEFlAHykgn JHrT00bS4r8X8em2aXoj8n7QsCiTZ/d3Yzt9ulXaKAKN1oulXvkfa9Ms7jyCrQ+bAr+WVztK5HGM nGOmavUUUAFFFFAEH2K181Zfs0PmIHCv5Yyoc5fB9yAT64pyWtvHt2QRLtO5dqAYONufy4+lS0UA VotPsoHV4rO3jZd+1kiUEb23Pjj+JuT6nk1SXwt4eSxlsU0HS1s5XEkluLOMRu46MVxgn3rWooAg FjaBUUWsAVNu0eWMLt+7j0x29Kqx+H9Fht7u3i0iwSC8Ja5iW2QLOT1LjGG/GtGijcCjbaRY2UsD 2ttFAlvC0EEUSBEjRiCwVQOMlV/KppbGzmWZZbWCQT4MoeMHzMdN3rjA61Yoo3AgnsrS5gnguLaG WG4BE0ckYZZBjHzA8HgAc+lUZPDOgS6bDpsmh6a9hC++K1a0jMSNzyqYwDyeQO5rVooAzl0DRl1b +1V0iwGpf8/Ytk877u37+M9OOvTioZPCvh2W0a1k0DS3tmmM7QtZxlDIRguRjG7HGeta9FAFObSd OuNMGmT6fay2AVUFq8KtEFXG0bCMYGBgY4xUb6Bo0gsg+k2DCwwbMNbIfs+MY8vj5Og6Y6CtCii+ twITa25EIMEREDbohsH7s4IyvocEjjsTU1FFABRRRQAUUUUAZcuv2cMojdZt/wBtWyYKmdrlQwJx 0Ugqc+471I2uabCI/tN5Ba+bcNbQi4kWMyyA7dqZPzHIPA5qC90IXl5cz/aNgmg8tUKbgknaTr1G F49utZmr+Dn1O2sI01F4nt4zFOd06LOrYL5EM0fJI/iLDk8Ul0v/AF/X6+QP+v6/rY2o9b06TVJN L+2QJfoTi2eVRI6gAllXOSvPXHY1chniuYEnglSWGRQySRsGVgehBHUVjjQ7ka4bsXsC2RuPtRgW 1/eNJ5YjGZN2CuB0256fNjg7EIlWBBO6PMFG9o0KKT3IBJwPbJ+tV0AkooopAYE3hzwjdXTyz6No ktxK7s7vaxM7uDlySRknuf1qNPDHgqTbs0Pw+2/O3baQnOOuOO3elv8Awt9sv7q5S88rzmRlHlbi hICS4O7+NFVeAMHJ5zRe+FRdXtzcR3YhEzIyqIsmM4CS4O7+ONVXgDByec1ssTXtbnf3v/PYXKhE 8MeCpNuzQ/D7b87dtpCc46447d6VvCnhFTBjw1orLO2EYWUGPuls8jngds/lk0XvhUXV7c3Ed2IR MyMqiLJjOAkuDu/jjVV4AwcnnNW722u59Rs4TFvtVleTzYwEESeUUCHLEsxZyQQoAA5wQMv61Xt8 b+9hyoxjp3w9NpPdRaX4bngt5RDcSQ29uywtkA7zjC4zk56CpH0j4ex21rcSad4YSC7IFvK0NuFm J6bDjDZ9qt2nhy4WNV1C9trgxGBYfJtPKURxOHUMC7ZbP8QwB2UVNJ4bhkinQvH+9huouYQcCd97 d/z9aaxNbrN/e/8AMFGPX+v+G/EzpdH+H0E13DNp3hiOWzQSXKPBbhoEPRnBHyjkcmh9I+Hsdta3 EmneGEguyBbytDbhZiemw4w2farNx4dv5b+8uodSgiEhje3i+zOyI6EHdIpl2seDygjPPJJAIkHh rzLWRLq4iluJra4hlkWDCkzEFiqliQuR93J9zSWKr9Zv73/X9fcKKvqik2kfD1HvVbTvDCtYgG7B htwbcHoZOPl/HFD6R8PYra2uZNP8MJBdkC3laG3CzE9Nhxhs+1WxoWpJZzWqalZiNJhPZbrEkxMH L/vP3mJBk9gh75zzTh4a8y1kS6uIpbia2uIZZFgwpMxBYqpYkLkfdyfc0LFV+s397/zBJPdGXb2f w2urWS6isvDBgiuDbPIbeBQsoONhyOvp6jBGQRU0WkeArmN3s9H8PXgjnW3k+zWsEnlyFgu1sDgj PI61oWvh0wgRzXKSwx3k91CBDtdPND7gW3HJBkbBAHGBjuWWPh+7hVftt/BM8fkpEYLUwgRxNuAY b2yx9Rgeiij61XuvfdvV/wBf15akktbIr2+geBLs3QttJ8OTG0YpcCO2gbyWHUPgfKeDwarjT/hu bS2uhaeFDbXUnlW8wjt9kr5xtU4wxz2FXo/D18LfUbd9Sg8m8kZhGts+2JSpACq8rAHO0nGFOD8g LE0t1ousXkUTS6pYC5MUlvcuuntseJiDhFMpKNgdSzA916YX1rEfzv73/X9dQ5V2K72HgHSL/wDe WnhqyvLYC4+aOCOSIKR8/YqAcc9uK6eORJoklidXjcBlZTkMD0IPcVlpoUCXSTgoSl39qGYwTnyf K6+uO/4Vd06zXT9NtbJSCtvEsQIXaCAMdO1TOpKes5N+o7LoWaKKKzAKKKKACiiigAooooAKKKKA CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKAP//Z --=_related 005000488625758C_=-- From pister@eecs.berkeley.edu Thu Apr 2 11:04: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 D3DE73A6C74 for ; Thu, 2 Apr 2009 11:04:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.392 X-Spam-Level: X-Spam-Status: No, score=-6.392 tagged_above=-999 required=5 tests=[AWL=0.207, 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 zGUCjb8dsCry for ; Thu, 2 Apr 2009 11:04:04 -0700 (PDT) Received: from gateway0.EECS.Berkeley.EDU (gateway0.EECS.Berkeley.EDU [169.229.60.87]) by core3.amsl.com (Postfix) with ESMTP id F2E0D3A6A29 for ; Thu, 2 Apr 2009 11:04:03 -0700 (PDT) Received: from [127.0.0.1] (dhcp-32-46.EECS.Berkeley.EDU [128.32.32.46]) (authenticated bits=0) by gateway0.EECS.Berkeley.EDU (8.14.3/8.13.5) with ESMTP id n32I52V1018860 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 2 Apr 2009 11:05:03 -0700 (PDT) Message-ID: <49D4FE48.3010104@eecs.berkeley.edu> Date: Thu, 02 Apr 2009 11:04:56 -0700 From: Kris Pister User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Tzeta Tsao References: <49CB86DA.9050104@eecs.berkeley.edu> <49D218CC.6040304@ekasystems.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: ROLL WG Subject: [Roll] simple security (Re: security update?) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 02 Apr 2009 18:04:04 -0000 Tzeta - there is a lot of great stuff in your document, and our challenge is to distill it down to a minimal set of things to put into the first draft of the protocol. So far only "MUST"s are * MUST verify the liveliness of both principals of a connection; * MUST verify message freshness; * MUST verify message sequence and integrity * If a LLN employs multicast and/or anycast, it MUST secure these protocols with the services listed in this sections. Furthermore, the nodes MUST provide adequate physical tamper resistance to ensure the integrity of stored routing information. and then two SHOULDs: * SHOULD provide payload encryption * SHOULD provide privacy With that as background, how do you feel about using something similar to OSPF authentication as a starting point? The security contents would be something like: , and conceptually at least the flags might be: 0 no authentication - no optional fields, probably no overhead at all if we can use 1 bit in the header 1 well-known key - no configuration necessary, optional fields contain MIC 2 shared key - configured, optional fields contain nonce counter, MIC 3 public key - no configuration necessary, optional fields contain certs and/or signature Does this seem like at least a framework to start with? ksjp JP Vasseur wrote: > Hi, > > On Mar 31, 2009, at 3:21 PM, Tzeta Tsao wrote: > >> Hi Kris, All, >> >> We are indeed working on an update to the security draft and will >> present it once the revision is in shape. At the same time, I welcome, >> and I believe other authors, too, any comments and suggestions. >> > > All, please provide some feed-back to the authors. > > Just so you know, we are also looking at other contributors to help > there. This is a key > WG item and we do want to address these aspects in parallel with the > routing design > effort and clearly not at the last minute. > >> I share the view that security should be an integral part of a ROLL >> protocol, but not an after-the-fact extension. In fact, even considering >> such diversified applications and capabilities of the LLN devices, I >> still hope this working group will come to the consensus that the >> stipulation should be such that an implementation of a ROLL protocol may >> choose not to conform rather than be given the choice of reduced >> security services. > > Security requirements do vary with the applications and can range from > none to high > level of security. Thus the routing protocol must be designed to turn > on or off several of > the security features. > > Thanks. > > JP. > >> >> Regards, >> Tzeta >> >> Kris Pister wrote: >>> Since we weren't able to get an update on the security draft at this >>> meeting, perhaps we could get an email summary? >>> >>> I'm confident that we can come up with a good routing protocol, and >>> I'm 100% certain that the networks it serves will be attacked. We >>> need to come up with something that is strong, but simple enough that >>> everyone uses it by default. My strong preference would be that >>> security is an intrinsic part of the routing protocol, and can't be >>> "turned off". >>> >>> ksjp >>> _______________________________________________ >>> Roll mailing 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 tzeta.tsao@ekasystems.com Thu Apr 2 14:43: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 0BE8D3A6C13 for ; Thu, 2 Apr 2009 14:43:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 hYZEHkdeVHat for ; Thu, 2 Apr 2009 14:43:14 -0700 (PDT) Received: from smtp102.biz.mail.re2.yahoo.com (smtp102.biz.mail.re2.yahoo.com [68.142.229.216]) by core3.amsl.com (Postfix) with SMTP id 55BF83A6B39 for ; Thu, 2 Apr 2009 14:43:07 -0700 (PDT) Received: (qmail 70359 invoked from network); 2 Apr 2009 21:44:09 -0000 Received: from unknown (HELO ?192.168.0.237?) (tzeta.tsao@209.48.242.70 with plain) by smtp102.biz.mail.re2.yahoo.com with SMTP; 2 Apr 2009 21:44:08 -0000 X-Yahoo-SMTP: 18Fc8ICswBBVPDv5exrrk3k0phuhQJtGVVI9vm7eGXDtosryT8s- X-YMail-OSG: OctCqDUVM1kLR1OZ8hP6p0fUyfTa7B5DgUkS5WX.rBzhJUQwsbO8Zd5jMz.MH2ilIJxO1PhzIF_06U4DVAD5Hp2Uh3OVCYLqW1..eV_KL_3I6fhaM8AClGRlLSv_MwJ1uwdLTY_cpI5mQJj7GRDTf3dWZkry2QICracWxoiSL.xrZbLii2O31GeFRn_tioPvjSh7jOTobUqE6xz_4xjdaFhhZA8qs_O9gs_Ezuy.NIixrZPjY57Zl2j7nAvAGG.E5SfQ_qD2xoc2MVAV9bGmFRwj.IGmtPaREGv4MUvi8Bnt1C21socGixLi9aL5JBUUERLRsrSOA.BHPbZEiZA- X-Yahoo-Newman-Property: ymail-3 Message-ID: <49D53180.5030509@ekasystems.com> Date: Thu, 02 Apr 2009 17:43:28 -0400 From: Tzeta Tsao User-Agent: Mozilla-Thunderbird 2.0.0.19 (X11/20090103) MIME-Version: 1.0 To: Kris Pister , ROLL WG References: <49CB86DA.9050104@eecs.berkeley.edu> <49D218CC.6040304@ekasystems.com> <49D4FE48.3010104@eecs.berkeley.edu> In-Reply-To: <49D4FE48.3010104@eecs.berkeley.edu> X-Enigmail-Version: 0.95.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Roll] simple security (Re: security update?) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 02 Apr 2009 21:43:15 -0000 Kris, In a way, we may say that the mechanism used in OSPF, or RIP, reflects generally accepted practice in this field, which allows no authentication; if it eventually becomes the consensus of the ROLL WG, we will have to change the language from MUSTs to SHOULDs in the security framework draft. But I need to point out that the current Internet has so much human effort devoted to its management, while in contrast, it is a stated goal that a LLN should have minimal or even be autonomous; I wonder if that does not prompt for a need of more security for LLNs? Regards, Tzeta Kris Pister wrote: > Tzeta - there is a lot of great stuff in your document, and our > challenge is to distill it down to a minimal set of things to put into > the first draft of the protocol. > So far only "MUST"s are > * MUST verify the liveliness of both principals of a connection; > * MUST verify message freshness; > * MUST verify message sequence and integrity > * If a LLN employs multicast and/or anycast, it MUST secure these > protocols with the services listed in this sections. Furthermore, the > nodes MUST provide adequate physical tamper resistance to ensure the > integrity of stored routing information. > > and then two SHOULDs: > * SHOULD provide payload encryption > * SHOULD provide privacy > > With that as background, how do you feel about using something similar > to OSPF authentication as a starting point? The security contents > would be something like: > , > and conceptually at least the flags might be: > 0 no authentication - no optional fields, probably no overhead at all > if we can use 1 bit in the header > 1 well-known key - no configuration necessary, optional fields contain > MIC > 2 shared key - configured, optional fields contain nonce counter, MIC > 3 public key - no configuration necessary, optional fields contain > certs and/or signature > > Does this seem like at least a framework to start with? > > ksjp > > JP Vasseur wrote: >> Hi, >> >> On Mar 31, 2009, at 3:21 PM, Tzeta Tsao wrote: >> >>> Hi Kris, All, >>> >>> We are indeed working on an update to the security draft and will >>> present it once the revision is in shape. At the same time, I welcome, >>> and I believe other authors, too, any comments and suggestions. >>> >> >> All, please provide some feed-back to the authors. >> >> Just so you know, we are also looking at other contributors to help >> there. This is a key >> WG item and we do want to address these aspects in parallel with the >> routing design >> effort and clearly not at the last minute. >> >>> I share the view that security should be an integral part of a ROLL >>> protocol, but not an after-the-fact extension. In fact, even >>> considering >>> such diversified applications and capabilities of the LLN devices, I >>> still hope this working group will come to the consensus that the >>> stipulation should be such that an implementation of a ROLL protocol >>> may >>> choose not to conform rather than be given the choice of reduced >>> security services. >> >> Security requirements do vary with the applications and can range >> from none to high >> level of security. Thus the routing protocol must be designed to turn >> on or off several of >> the security features. >> >> Thanks. >> >> JP. >> >>> >>> Regards, >>> Tzeta >>> >>> Kris Pister wrote: >>>> Since we weren't able to get an update on the security draft at this >>>> meeting, perhaps we could get an email summary? >>>> >>>> I'm confident that we can come up with a good routing protocol, and >>>> I'm 100% certain that the networks it serves will be attacked. We >>>> need to come up with something that is strong, but simple enough that >>>> everyone uses it by default. My strong preference would be that >>>> security is an intrinsic part of the routing protocol, and can't be >>>> "turned off". >>>> >>>> ksjp >>>> _______________________________________________ >>>> Roll mailing list >>>> Roll@ietf.org >>>> https://www.ietf.org/mailman/listinfo/roll >>>> >>> >>> _______________________________________________ >>> Roll mailing list >>> Roll@ietf.org >>> https://www.ietf.org/mailman/listinfo/roll >> >> _______________________________________________ >> Roll mailing list >> Roll@ietf.org >> https://www.ietf.org/mailman/listinfo/roll > From wwwrun@core3.amsl.com Thu Apr 2 15:00:25 2009 Return-Path: X-Original-To: roll@ietf.org Delivered-To: roll@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id E804F3A6D55; Thu, 2 Apr 2009 15:00:25 -0700 (PDT) X-idtracker: yes From: The IESG To: IETF-Announce Message-Id: <20090402220025.E804F3A6D55@core3.amsl.com> Date: Thu, 2 Apr 2009 15:00:25 -0700 (PDT) Cc: roll mailing list , Internet Architecture Board , roll chair , RFC Editor Subject: [Roll] Document Action: 'Urban WSNs Routing Requirements in Low Power and Lossy Networks' to Informational RFC X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Apr 2009 22:00:26 -0000 The IESG has approved the following document: - 'Urban WSNs Routing Requirements in Low Power and Lossy Networks ' as an Informational RFC This document is the product of the Routing Over Low power and Lossy networks Working Group. The IESG contact persons are Adrian Farrel and Ross Callon. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-roll-urban-routing-reqs-05.txt Technical Summary The application-specific routing requirements for Urban Low Power and Lossy Networks (U-LLNs) are presented in this document. Working Group Summary The I-D has been extensively discussed with the participation of several key members of the Working Group. There were no Last Call concerns. Document Quality There were no issues in the contents of the doc by the WG or community. Personnel JP Vasseur is the doc shepherd. From pthubert@cisco.com Fri Apr 3 01:59: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 C5ED03A6859 for ; Fri, 3 Apr 2009 01:59:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.84 X-Spam-Level: X-Spam-Status: No, score=-9.84 tagged_above=-999 required=5 tests=[AWL=0.759, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YZFuRIFX0XVt for ; Fri, 3 Apr 2009 01:59:58 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 3AD063A6358 for ; Fri, 3 Apr 2009 01:59:58 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.39,318,1235952000"; d="scan'208";a="37388804" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 03 Apr 2009 09:00:59 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n3390xoP017411; Fri, 3 Apr 2009 11:00:59 +0200 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n3390xa1026569; Fri, 3 Apr 2009 09:00:59 GMT Received: from xmb-ams-337.cisco.com ([144.254.231.82]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 3 Apr 2009 11:00:59 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 3 Apr 2009 11:00:54 +0200 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC073C3E79@xmb-ams-337.emea.cisco.com> In-Reply-To: <200904021954.n32JsfUu016043@kelsey-ws.hq.ember.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] FW: New Version Notification fordraft-thubert-roll-fundamentals-00 Thread-Index: AcmzzOxXBTYM/rhPTsiBJdd+BZUxCgAahLdg References: <7892795E1A87F04CADFCCF41FADD00FC07365A53@xmb-ams-337.emea.cisco.com> <200904021954.n32JsfUu016043@kelsey-ws.hq.ember.com> From: "Pascal Thubert (pthubert)" To: "Richard Kelsey" X-OriginalArrivalTime: 03 Apr 2009 09:00:59.0359 (UTC) FILETIME=[B4F15EF0:01C9B43A] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2957; t=1238749259; x=1239613259; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pthubert@cisco.com; z=From:=20=22Pascal=20Thubert=20(pthubert)=22=20 |Subject:=20RE=3A=20[Roll]=20FW=3A=20New=20Version=20Notifi cation=20fordraft-thubert-roll-fundamentals-00 |Sender:=20; bh=kNwVSUMKTTXVeRXXrR+2r3f1M5k5QEbgI4ha3cDdbOE=; b=bYs8m7nH/+T7q6USxsXTillsBdjr9HQh/Hb9J26seNEIdkoHXLphs80wOC hO0y1zCMqKAGNIAIeWceWyHItYrhqm+AYKcHtsDIFymljn6OXVeWqEa9MobS az6oOznm0Q; Authentication-Results: ams-dkim-1; header.From=pthubert@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Cc: roll@ietf.org Subject: Re: [Roll] FW: New Version Notification fordraft-thubert-roll-fundamentals-00 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Apr 2009 08:59:59 -0000 Hi Richard: >If a Router receives a TIO with a more recent sequence number >than previously seen, isn't it safe for it to pick the sender >of the TIO as a new parent regardless of the Router's current >depth? The sender's path back to the root must all have >sequence numbers more recent than the Router's and thus >cannot include it. Allowing this could improve the speed >with which the network reacts to topography changes. Great point. The case might effectively happen and your proposal seems safe. In particular if the parent is dead and we do not know it yet, some time might pass during which we actually receive such TIOs from deeper with a newer sequence. At the moment the text ignores TIOs from deeper. In fact, we could store them if the sequence is newer, and that could allow a node to move deeper within the tree without the freezing transition. That optimization could be used if the node memory permits but is not necessary for the operation. I do like it. >Is it necessary to have separate mechanisms for disseminating >upwards and downwards unicast routes? It looks to me as if >the main reason for needing both is that currently all trees >have a border router as the root. If other destinations were >allowed to be roots then all routes could be upwards and >there would be no need for route dissemination. Having only >one mechanism would be simpler. But would cost a lot, lot more signaling.=20 The spec does not prevent all nodes to keep building their own tree, a tree being a topology. We can add some text that the node could install a route towards the treeID (address or prefix in case of a backbone) via the parent. So in a given deployment you could do just what you say. But the spec does not require all nodes to participate to all those topologies either.=20 Sending the RIO up the tree costs a lot less in terms of traffic and states, but you only get what you paid for, source/sink routes along the tree, which is what the req drafts ask us to optimize for in the first place. Finally you can use only one tree and source routing on the way back. The cool thing is that when you have RIO basde states that RPF match the source path, then you do not need to add to the record route so the size of the source route information can be dynamically adjusted depending on whether nodes support RIO or not. > >Multicasts would still need to be handled somehow, but >perhaps using a multicast-specific protocol would have its >own benefits. Could be. We propose one way that has a very minimum overhead since the signaling is merged with the unicast signaling and benefits from the tree that's already there for source/sink.=20 We'll probably submit a 01 real soon including some text to include your first proposal. But then the DT work will start and I'll have to focus on that. Thanks a bunch, Richard, for your excellent remarks. Pascal From jvasseur@cisco.com Fri Apr 3 02:24: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 5A03928C203 for ; Fri, 3 Apr 2009 02:24:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.309 X-Spam-Level: X-Spam-Status: No, score=-10.309 tagged_above=-999 required=5 tests=[AWL=0.246, BAYES_00=-2.599, DATE_IN_PAST_03_06=0.044, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hRxcFBhe4DKI for ; Fri, 3 Apr 2009 02:24:25 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 45AA628C13D for ; Fri, 3 Apr 2009 02:24:24 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.39,318,1235952000"; d="scan'208";a="37391001" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 03 Apr 2009 09:25:25 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n339PP10027190; Fri, 3 Apr 2009 11:25:25 +0200 Received: from xbh-ams-331.emea.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n339PP3Q007406; Fri, 3 Apr 2009 09:25:25 GMT Received: from xfe-ams-331.emea.cisco.com ([144.254.231.72]) by xbh-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 3 Apr 2009 11:25:25 +0200 Received: from dhcp-lyon-144-254-54-100.cisco.com ([144.254.54.100]) by xfe-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 3 Apr 2009 11:25:24 +0200 Message-Id: From: JP Vasseur To: Tzeta Tsao In-Reply-To: <49D53180.5030509@ekasystems.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Fri, 3 Apr 2009 07:13:49 +0200 References: <49CB86DA.9050104@eecs.berkeley.edu> <49D218CC.6040304@ekasystems.com> <49D4FE48.3010104@eecs.berkeley.edu> <49D53180.5030509@ekasystems.com> X-Mailer: Apple Mail (2.930.3) X-OriginalArrivalTime: 03 Apr 2009 09:25:24.0915 (UTC) FILETIME=[1E7B7830:01C9B43E] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=4978; t=1238750725; x=1239614725; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:=20JP=20Vasseur=20 |Subject:=20Re=3A=20[Roll]=20simple=20security=20(Re=3A=20= 20security=20update?) |Sender:=20; bh=SoDRe9nY+xfo9DY3AwSZpvvRgbUEepSPJEodh1za80I=; b=De61ue1sn1xwVNp6QTugvtUL1r/P4B8S62gHciWfFMyQ6frRjgSkx4QhUr o1CBVAYhKQFCSRt2lqcGt6h0LNzvcBSqefGqZ19tJpk1bpfQxeBgWW9/3+rL zpivHPuekL; Authentication-Results: ams-dkim-1; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Cc: ROLL WG Subject: Re: [Roll] simple security (Re: security update?) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 03 Apr 2009 09:24:26 -0000 Hi Tzeta, On Apr 2, 2009, at 11:43 PM, Tzeta Tsao wrote: > Kris, > > In a way, we may say that the mechanism used in OSPF, or RIP, reflects > generally accepted practice in this field, which allows no > authentication; if it eventually becomes the consensus of the ROLL WG, > we will have to change the language from MUSTs to SHOULDs in the > security framework draft. > > But I need to point out that the current Internet has so much human > effort devoted to its management, while in contrast, it is a stated > goal > that a LLN should have minimal or even be autonomous; I wonder if that > does not prompt for a need of more security for LLNs? How do you come up with the conclusion that minimal configuration implies more security ? Thanks. JP. > > Regards, > Tzeta > > > Kris Pister wrote: >> Tzeta - there is a lot of great stuff in your document, and our >> challenge is to distill it down to a minimal set of things to put >> into >> the first draft of the protocol. >> So far only "MUST"s are >> * MUST verify the liveliness of both principals of a connection; >> * MUST verify message freshness; >> * MUST verify message sequence and integrity >> * If a LLN employs multicast and/or anycast, it MUST secure these >> protocols with the services listed in this sections. Furthermore, the >> nodes MUST provide adequate physical tamper resistance to ensure the >> integrity of stored routing information. >> >> and then two SHOULDs: >> * SHOULD provide payload encryption >> * SHOULD provide privacy >> >> With that as background, how do you feel about using something >> similar >> to OSPF authentication as a starting point? The security contents >> would be something like: >> , >> and conceptually at least the flags might be: >> 0 no authentication - no optional fields, probably no overhead at all >> if we can use 1 bit in the header >> 1 well-known key - no configuration necessary, optional fields >> contain >> MIC >> 2 shared key - configured, optional fields contain nonce counter, MIC >> 3 public key - no configuration necessary, optional fields contain >> certs and/or signature >> >> Does this seem like at least a framework to start with? >> >> ksjp >> >> JP Vasseur wrote: >>> Hi, >>> >>> On Mar 31, 2009, at 3:21 PM, Tzeta Tsao wrote: >>> >>>> Hi Kris, All, >>>> >>>> We are indeed working on an update to the security draft and will >>>> present it once the revision is in shape. At the same time, I >>>> welcome, >>>> and I believe other authors, too, any comments and suggestions. >>>> >>> >>> All, please provide some feed-back to the authors. >>> >>> Just so you know, we are also looking at other contributors to help >>> there. This is a key >>> WG item and we do want to address these aspects in parallel with the >>> routing design >>> effort and clearly not at the last minute. >>> >>>> I share the view that security should be an integral part of a ROLL >>>> protocol, but not an after-the-fact extension. In fact, even >>>> considering >>>> such diversified applications and capabilities of the LLN >>>> devices, I >>>> still hope this working group will come to the consensus that the >>>> stipulation should be such that an implementation of a ROLL >>>> protocol >>>> may >>>> choose not to conform rather than be given the choice of reduced >>>> security services. >>> >>> Security requirements do vary with the applications and can range >>> from none to high >>> level of security. Thus the routing protocol must be designed to >>> turn >>> on or off several of >>> the security features. >>> >>> Thanks. >>> >>> JP. >>> >>>> >>>> Regards, >>>> Tzeta >>>> >>>> Kris Pister wrote: >>>>> Since we weren't able to get an update on the security draft at >>>>> this >>>>> meeting, perhaps we could get an email summary? >>>>> >>>>> I'm confident that we can come up with a good routing protocol, >>>>> and >>>>> I'm 100% certain that the networks it serves will be attacked. We >>>>> need to come up with something that is strong, but simple enough >>>>> that >>>>> everyone uses it by default. My strong preference would be that >>>>> security is an intrinsic part of the routing protocol, and can't >>>>> be >>>>> "turned off". >>>>> >>>>> ksjp >>>>> _______________________________________________ >>>>> Roll mailing 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 chris.dearlove@baesystems.com Fri Apr 3 02:58: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 E76EB3A696E for ; Fri, 3 Apr 2009 02:58:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.627 X-Spam-Level: X-Spam-Status: No, score=-6.627 tagged_above=-999 required=5 tests=[AWL=-0.028, 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 kV8z5VexLY5k for ; Fri, 3 Apr 2009 02:58:42 -0700 (PDT) Received: from smtp1.bae.co.uk (smtp1.bae.co.uk [20.133.0.11]) by core3.amsl.com (Postfix) with ESMTP id BC1D63A6AC7 for ; Fri, 3 Apr 2009 02:58:41 -0700 (PDT) Received: from smtpb.greenlnk.net (smtpb.greenlnk.net [10.15.160.219]) by smtp1.bae.co.uk (Switch-3.1.10/Switch-3.1.10) with ESMTP id n339xgbj007853 for ; Fri, 3 Apr 2009 10:59:42 +0100 (BST) Received: from glkas0002.GREENLNK.NET (glkas0002.greenlnk.net [10.15.184.52]) by smtpb.greenlnk.net (Switch-3.1.9/Switch-3.1.9) with ESMTP id n339xgqV023158 for ; Fri, 3 Apr 2009 10:59:42 +0100 Received: from glkms1100.GREENLNK.NET ([10.15.184.108]) by glkas0002.GREENLNK.NET with InterScan Message Security Suite; Fri, 03 Apr 2009 10:59:41 +0100 Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1100.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.2499); Fri, 3 Apr 2009 10:59:41 +0100 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Fri, 3 Apr 2009 10:59:40 +0100 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] simple security (Re: security update?) Thread-Index: Acm0PjN+7sNLJfb+SJOVr2ZxNtZ7dwAA8DhQ References: <49CB86DA.9050104@eecs.berkeley.edu><49D218CC.6040304@ekasystems.com><49D4FE48.3010104@eecs.berkeley.edu><49D53180.5030509@ekasystems.com> From: "Dearlove, Christopher (UK)" To: "JP Vasseur" , "Tzeta Tsao" X-OriginalArrivalTime: 03 Apr 2009 09:59:41.0659 (UTC) FILETIME=[E865B2B0:01C9B442] Cc: ROLL WG Subject: Re: [Roll] simple security (Re: security update?) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 03 Apr 2009 09:58:43 -0000 >> But I need to point out that the current Internet has so much human >> effort devoted to its management, while in contrast, it is a stated =20 >> goal >> that a LLN should have minimal or even be autonomous; I wonder if that >> does not prompt for a need of more security for LLNs? > How do you come up with the conclusion that minimal configuration =20 > implies more security ? I thought his possible (he says "I wonder") conclusion was a need for more security, not achieving more security. While I'm not sure it's the minimal configuration that's the only reason why, a scenario where devices are distributed without either human attendance or continual monitoring certainly raises some difficult security issues. ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** From pthubert@cisco.com Fri Apr 3 09:01: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 11F763A680D for ; Fri, 3 Apr 2009 09:01:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.807 X-Spam-Level: X-Spam-Status: No, score=-9.807 tagged_above=-999 required=5 tests=[AWL=0.791, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M1Kylwo9FUJA for ; Fri, 3 Apr 2009 09:01:39 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 3B1513A67FB for ; Fri, 3 Apr 2009 09:01:38 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.39,320,1235952000"; d="scan'208,217";a="37406883" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 03 Apr 2009 16:02:39 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n33G2dxL003778; Fri, 3 Apr 2009 18:02:39 +0200 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n33G2dFc006892; Fri, 3 Apr 2009 16:02:39 GMT Received: from xmb-ams-337.cisco.com ([144.254.231.82]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 3 Apr 2009 18:02:39 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C9B475.9C99BF7D" Date: Fri, 3 Apr 2009 18:02:15 +0200 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC073C4145@xmb-ams-337.emea.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] FW: New Version Notification fordraft-thubert-roll-fundamentals-00 Thread-Index: AcmzzOxXBTYM/rhPTsiBJdd+BZUxCgAahLdgAAyQg2YAAk6YZAAAKncg References: <7892795E1A87F04CADFCCF41FADD00FC07365A53@xmb-ams-337.emea.cisco.com> <200904021954.n32JsfUu016043@kelsey-ws.hq.ember.com> <7892795E1A87F04CADFCCF41FADD00FC073C3E79@xmb-ams-337.emea.cisco.com> From: "Pascal Thubert (pthubert)" To: "Richard Kelsey" X-OriginalArrivalTime: 03 Apr 2009 16:02:39.0716 (UTC) FILETIME=[9D217A40:01C9B475] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=16432; t=1238774559; x=1239638559; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pthubert@cisco.com; z=From:=20=22Pascal=20Thubert=20(pthubert)=22=20 |Subject:=20RE=3A=20[Roll]=20FW=3A=20New=20Version=20Notifi cation=20fordraft-thubert-roll-fundamentals-00 |Sender:=20; bh=oX105DjCDSkScGLfd2Ct+m1rQK88HrBCRZQKkKtseso=; b=AWO9P7omk+5F5bW0nGjfisShF7eeS3dDIbPnP1gDSqAQtqQLGcqC3slZgm HoRBn+cprJD5gH/u59HbcZ+yI9qqdnu9/EK5+HFa2LSD8kihh9eSFhFwqtsW atC1IUT/Kt; Authentication-Results: ams-dkim-1; header.From=pthubert@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Cc: roll@ietf.org Subject: Re: [Roll] FW: New Version Notification fordraft-thubert-roll-fundamentals-00 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Apr 2009 16:01:47 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C9B475.9C99BF7D Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Richard, =20 Richard>=20 For control traffic, which version is less costly depends on the details. For example, if there are few enough unique destinations** that all of the tree data can be piggy-backed on the router advertisements, then just using the trees has less overhead because it doesn't require route dissemination. As the number of unique destinations rises, the only-tree version does require more control traffic. Pascal> RIO is optional and I still think the RIO makes sense is many destinations are to be reached and mostly from the sink. Only destinations that need to be reached from the sink need to send RIOs. So same thing here.=20 But a tree rooted at a destination would be propagated to a lot more nodes then just the parents up the tree.=20 So more control is what I'm saying. ROI for control is another discussion though. For data traffic the all-tree version requires much less signalling, as all messages take an optimized path, rather than just messages to or from the border router. If the average depth of a tree is D, then the all-tree version averages D hops per message. Using route dissemination the average is D hops per message to or from the border router and 2D hops for other messages. Worse, the extra hops are not distributed evenly. The border router and its children pay most of the cost. If there's a tree routed at the destination then you get an optimized path from all sources in the tree that's true. You get value for your extra control as long as there is traffic that justifies it. So it's fair to say that for very special destinations it might be worth spawning a tree if many nodes in the LLN need to reach that very special destination. If none or only a few need so then it might be better to use a more on-demand mechanism such as offline or aodv (we have text about that already). =20 Given that there is going to be a lot more data traffic than control traffic, using only trees will be considerably more efficient if there is a significant amount of traffic between non-border-router nodes. =20 Any to any is not what the requirements ask to optimize for. But I agree with you that it can be worth spawning additional topologies. There is text for that in the second half of the document but nothing for special (worthy) destinations so I can add some text there.=20 Would that be what you're asking for? =20 Pascal From: Richard Kelsey [mailto:richard.kelsey@ember.com]=20 Sent: vendredi 3 avril 2009 17:40 To: Richard Kelsey; Pascal Thubert (pthubert) Cc: roll@ietf.org Subject: RE: [Roll] FW: New Version Notification fordraft-thubert-roll-fundamentals-00 =20 [Re-sent due to an email problem which prevented this from getting to the ROLL list. -Richard Kelsey] Date: Fri, 3 Apr 2009 11:00:54 +0200 From: "Pascal Thubert (pthubert)" >Is it necessary to have separate mechanisms for disseminating >upwards and downwards unicast routes? It looks to me as if >the main reason for needing both is that currently all trees >have a border router as the root. If other destinations were >allowed to be roots then all routes could be upwards and >there would be no need for route dissemination. Having only >one mechanism would be simpler. But would cost a lot, lot more signaling. It seems to me that it would cost a lot less signalling. For control traffic, which version is less costly depends on the details. For example, if there are few enough unique destinations** that all of the tree data can be piggy-backed on the router advertisements, then just using the trees has less overhead because it doesn't require route dissemination. As the number of unique destinations rises, the only-tree version does require more control traffic. For data traffic the all-tree version requires much less signalling, as all messages take an optimized path, rather than just messages to or from the border router. If the average depth of a tree is D, then the all-tree version averages D hops per message. Using route dissemination the average is D hops per message to or from the border router and 2D hops for other messages. Worse, the extra hops are not distributed evenly. The border router and its children pay most of the cost. Given that there is going to be a lot more data traffic than control traffic, using only trees will be considerably more efficient if there is a significant amount of traffic between non-border-router nodes. -Richard Kelsey ** I have not found a definition of 'unique destination'. The routing protocol survey makes it clear that most nodes are not unique destinations, but doesn't define the term. ---------------- This message and the information it contains are the proprietary and confidential property of Ember Corporation and may be privileged. If you are not the intended recipient, please do not read, copy, disclose or distribute its contents to any party, and notify the sender immediately. ------_=_NextPart_001_01C9B475.9C99BF7D Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable RE: [Roll] FW: New Version Notification fordraft-thubert-roll-fundamentals-00

Hi Richard,

 

Richard>
For control traffic, which version is less costly depends on
the details.  For example, if there are few enough unique
destinations** that all of the tree data can be piggy-backed
on the router advertisements, then just using the trees has
less overhead because it doesn't require route
dissemination.  As the number of unique destinations rises,
the only-tree version does require more control traffic.

Pascal>

RIO is optional and I still think the RIO makes sense is = many destinations are to be reached and mostly from the = sink.

Only destinations that need to be reached from the = sink  need to send RIOs.  So same thing here.

But a tree rooted at a destination would be propagated to = a lot more nodes then just the parents up the tree.

So more control is what I’m saying. ROI for control = is another discussion though.


For data traffic the all-tree version requires much less
signalling, as all messages take an optimized path, rather
than just messages to or from the border router.  If the
average depth of a tree is D, then the all-tree version
averages D hops per message.  Using route dissemination the
average is D hops per message to or from the border router
and 2D hops for other messages.  Worse, the extra hops are
not distributed evenly.  The border router and its children
pay most of the cost.

If there’s a tree routed at the destination then = you get an optimized path from all sources in the tree that’s = true.

You get value for your extra control as long as there is = traffic that justifies it. So it’s fair to say that for very special = destinations it might be worth spawning a tree if many nodes in the LLN need to reach = that very special destination. If none or only a few need so then it might be = better to use a more on-demand mechanism such as offline or aodv (we have text = about that already).

 

Given that there = is going to be a lot more data traffic than
control traffic, using only trees will be considerably more
efficient if there is a significant amount of traffic
between non-border-router nodes.

 

Any to any is not what the requirements ask to optimize = for. But I agree with you that it can be worth spawning additional topologies. = There is text for that in the second half of the document but nothing for special = (worthy) destinations so I can add some text there.

Would that be what you’re asking = for?

 

Pascal

From:= Richard = Kelsey [mailto:richard.kelsey@ember.com]
Sent: vendredi 3 avril 2009 17:40
To: Richard Kelsey; Pascal Thubert (pthubert)
Cc: roll@ietf.org
Subject: RE: [Roll] FW: New Version Notification fordraft-thubert-roll-fundamentals-00

 

[Re-sent due to an email problem which prevented this from getting
to the ROLL list.  -Richard Kelsey]

   Date: Fri, 3 Apr 2009 11:00:54 +0200
   From: "Pascal Thubert (pthubert)" <pthubert@cisco.com>

   >Is it necessary to have separate mechanisms for = disseminating
   >upwards and downwards unicast routes?  It looks to = me as if
   >the main reason for needing both is that currently all = trees
   >have a border router as the root.  If other = destinations were
   >allowed to be roots then all routes could be upwards = and
   >there would be no need for route dissemination.  = Having only
   >one mechanism would be simpler.

   But would cost a lot, lot more signaling.

It seems to me that it would cost a lot less signalling.

For control traffic, which version is less costly depends on
the details.  For example, if there are few enough unique
destinations** that all of the tree data can be piggy-backed
on the router advertisements, then just using the trees has
less overhead because it doesn't require route
dissemination.  As the number of unique destinations rises,
the only-tree version does require more control traffic.

For data traffic the all-tree version requires much less
signalling, as all messages take an optimized path, rather
than just messages to or from the border router.  If the
average depth of a tree is D, then the all-tree version
averages D hops per message.  Using route dissemination the
average is D hops per message to or from the border router
and 2D hops for other messages.  Worse, the extra hops are
not distributed evenly.  The border router and its children
pay most of the cost.

Given that there is going to be a lot more data traffic than
control traffic, using only trees will be considerably more
efficient if there is a significant amount of traffic
between non-border-router nodes.

            &= nbsp;           &n= bsp;           &nb= sp;  -Richard Kelsey

** I have not found a definition of 'unique destination'.
The routing protocol survey makes it clear that most nodes
are not unique destinations, but doesn't define the term.

----------------
This message and the information it contains are the proprietary
and confidential property of Ember Corporation and may be = privileged.
If you are not the intended recipient, please do not read, copy,
disclose or distribute its contents to any party, and notify the
sender immediately.

------_=_NextPart_001_01C9B475.9C99BF7D-- From jvasseur@cisco.com Sun Apr 5 23:48: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 EB9883A67F8 for ; Sun, 5 Apr 2009 23:48:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.306 X-Spam-Level: X-Spam-Status: No, score=-8.306 tagged_above=-999 required=5 tests=[AWL=-1.707, 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 52Z0bJvcWjZS for ; Sun, 5 Apr 2009 23:48:17 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 0DBE73A6B53 for ; Sun, 5 Apr 2009 23:48:17 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.39,329,1235952000"; d="scan'208";a="167210312" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by sj-iport-1.cisco.com with ESMTP; 06 Apr 2009 06:49:21 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n366nLlP011447; Mon, 6 Apr 2009 08:49:21 +0200 Received: from xbh-ams-331.emea.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n366nLVX023736; Mon, 6 Apr 2009 06:49:21 GMT Received: from xfe-ams-332.cisco.com ([144.254.231.73]) by xbh-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 6 Apr 2009 08:49:21 +0200 Received: from ams-jvasseur-8713.cisco.com ([10.55.201.132]) by xfe-ams-332.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 6 Apr 2009 08:49:20 +0200 Message-Id: <8CF80793-154E-4DC3-A7A2-F3B8CF471DDD@cisco.com> From: JP Vasseur To: "Dearlove, Christopher (UK)" 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 v930.3) Date: Mon, 6 Apr 2009 08:49:20 +0200 References: <49CB86DA.9050104@eecs.berkeley.edu><49D218CC.6040304@ekasystems.com><49D4FE48.3010104@eecs.berkeley.edu><49D53180.5030509@ekasystems.com> X-Mailer: Apple Mail (2.930.3) X-OriginalArrivalTime: 06 Apr 2009 06:49:20.0712 (UTC) FILETIME=[D038BC80:01C9B683] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1620; t=1239000561; x=1239864561; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:=20JP=20Vasseur=20 |Subject:=20Re=3A=20[Roll]=20simple=20security=20(Re=3A=20= 20security=20update?) |Sender:=20; bh=Cy7R+FSDslNAAw8BgFw+bmeu93HhOc6GuoOFC77acuQ=; b=cPgmlR5qtsy2ypUF6BPRU8sN/zdgYShhyzXTR1d4JUZE+7QYfNFSJhhxRw IwVqwJ3EySXl6BVoIGrxjoCPscuJ9KMWZd5arg9WnrZASLr0Fi47b16hIf8i gxaDlKJ4fm; Authentication-Results: ams-dkim-2; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Cc: ROLL WG Subject: Re: [Roll] simple security (Re: security update?) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 06 Apr 2009 06:48:23 -0000 On Apr 3, 2009, at 11:59 AM, Dearlove, Christopher (UK) wrote: > >>> But I need to point out that the current Internet has so much human >>> effort devoted to its management, while in contrast, it is a stated >>> goal >>> that a LLN should have minimal or even be autonomous; I wonder if > that >>> does not prompt for a need of more security for LLNs? > >> How do you come up with the conclusion that minimal configuration >> implies more security ? > > I thought his possible (he says "I wonder") conclusion was a need for > more security, not achieving more security. While I'm not sure it's > the minimal configuration that's the only reason why, a scenario where > devices are distributed without either human attendance or continual > monitoring certainly raises some difficult security issues. This is exactly my point. This is not the 0-config requirement that requires more security. Of course 0-config with high security requirements is more challenging. Cheers. JP. > > ******************************************************************** > This email and any attachments are confidential to the intended > recipient and may also be privileged. If you are not the intended > recipient please delete it from your system and notify the sender. > You should not copy it or use it for any purpose nor disclose or > distribute its contents to any other person. > ******************************************************************** > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From pthubert@cisco.com Mon Apr 6 00:38: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 502B03A6B7D for ; Mon, 6 Apr 2009 00:38:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.857 X-Spam-Level: X-Spam-Status: No, score=-7.857 tagged_above=-999 required=5 tests=[AWL=-1.259, 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 AyWIZdW5s0hJ for ; Mon, 6 Apr 2009 00:38:05 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 2F4D23A6BC3 for ; Mon, 6 Apr 2009 00:38:05 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.39,329,1235952000"; d="scan'208,217";a="280919610" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by sj-iport-6.cisco.com with ESMTP; 06 Apr 2009 07:39:09 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n367d8Af026225; Mon, 6 Apr 2009 09:39:08 +0200 Received: from xbh-ams-331.emea.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n367d8fb009345; Mon, 6 Apr 2009 07:39:08 GMT Received: from xmb-ams-337.cisco.com ([144.254.231.82]) by xbh-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 6 Apr 2009 09:39:08 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C9B68A.C4B26113" Date: Mon, 6 Apr 2009 09:39:03 +0200 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC073C432D@xmb-ams-337.emea.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] FW: New Version Notification fordraft-thubert-roll-fundamentals-00 Thread-Index: AcmzzOxXBTYM/rhPTsiBJdd+BZUxCgAahLdgAAyQg2YAAk6YZAAAKncgAAaoWKcAfhLWoA== References: <7892795E1A87F04CADFCCF41FADD00FC07365A53@xmb-ams-337.emea.cisco.com> <200904021954.n32JsfUu016043@kelsey-ws.hq.ember.com> <7892795E1A87F04CADFCCF41FADD00FC073C3E79@xmb-ams-337.emea.cisco.com> <7892795E1A87F04CADFCCF41FADD00FC073C4145@xmb-ams-337.emea.cisco.com> From: "Pascal Thubert (pthubert)" To: "Richard Kelsey" X-OriginalArrivalTime: 06 Apr 2009 07:39:08.0241 (UTC) FILETIME=[C4ED7C10:01C9B68A] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=23342; t=1239003548; x=1239867548; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pthubert@cisco.com; z=From:=20=22Pascal=20Thubert=20(pthubert)=22=20 |Subject:=20RE=3A=20[Roll]=20FW=3A=20New=20Version=20Notifi cation=20fordraft-thubert-roll-fundamentals-00 |Sender:=20; bh=CbOPb5CI/Ax2UCE08VUoTY2/mkfmwmuB/Mb5wJhKdrQ=; b=guFkQ1MqsG2ceJSOqFhgXxNF2QZ3++7s7w2oX+XQ497aiR3XpefYiljJ5R ZAfSsLCMTiteYkvs5hUP7VbwB94Uh4uAVyrKD6WUC694kuzotWdrkgDic/3s YVHA14yOO4; Authentication-Results: ams-dkim-2; header.From=pthubert@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Cc: roll@ietf.org, stevey@amsl.com Subject: Re: [Roll] FW: New Version Notification fordraft-thubert-roll-fundamentals-00 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Apr 2009 07:38:15 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C9B68A.C4B26113 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Richard: =20 Richard> Pascal, while I agree with you in general, I don't see how this fits the requirements. As spelled out in the protocol survey document, routing state should be bounded by O(D), =20 Pascal>=20 The difference we are talking about is whether a destination in the LLN needs to be reachable from all other nodes in the LLN or only/mostly from the sink and whatever's behind the sink. Whether you do new trees or RIO, only the destinations that need to be reachable need to advertise themselves so you get your o (or O or Omega or ?) of D. It's more a matter of whether an assembly is overkill or insufficient for a given use case. =20 RIO only advertise along a unicast path towards the sink that's already there as part of the tree, so that's the minimum control. =20 Building a tree to LLN destinations would require maintaining and flooding new topological information and metrics to all and that's a lot more, one thing we do not seem to agree upon but that's fine. =20 The intermediate approach to build on demand constrained routes is also discussed in the draft.=20 =20 The question is whether one of those 3 approaches fits it all and I don't think so.=20 So we'll have to sort out what's mandatory and what's optional, based on common value I guess. =20 =20 Thus there is a set of special (worthy) destinations, which get special consideration. These clearly include any border routers, and may include other routers. For example, the industrial requirements document says: Most of the traffic over the LLN is publish/subscribe of sensor data from the field device towards a sink that can be a backbone router, a gateway, or a controller/manager. The controller/managers seem likely candidates for special destinations. For all examples I know of, those devices are either the sinks or attached to a backbone via the sink.=20 So the default route is enough to reach these devices and TD/RIO fits the bill. =20 I would like multiple trees to be explictly supported by the text, including trees that are not rooted at border routers. As it stands, while not explicitly prohibited, the text is somewhat ambiguous as to whether additional trees are allowed and exactly how they should work. Will do. There is text in multiple topologies about that but after this discussion, it is clear that some addition would be required. . Note that we're getting close a classical DV if we follow that path too far and I do not think that this is the general direction we're taking. =20 I need to make sure that the text is clear that the default route is only installed when the G bit is set, that there can be only one tree with the G bit set (unless some Multi topology routing is in place). I can also indicate that nodes might belong to multiple non-g trees; and that nodes install a route to the tree ID over the corresponding tree. =20 I plan to submit by Wednesday. If you have a suggestion for text to add/modify/remove you're certainly welcome J =20 Best, =20 Pascal From: Richard Kelsey [mailto:richard.kelsey@ember.com]=20 Sent: vendredi 3 avril 2009 21:11 To: Pascal Thubert (pthubert) Cc: roll@ietf.org; stevey@amsl.com Subject: RE: [Roll] FW: New Version Notification fordraft-thubert-roll-fundamentals-00 =20 Date: Fri, 3 Apr 2009 18:02:15 +0200 From: "Pascal Thubert (pthubert)" Date: Fri, 3 Apr 2009 11:40:15 -0400 From: "Richard Kelsey" For control traffic, which version is less costly depends on the details. For example, if there are few enough unique destinations** that all of the tree data can be piggy-backed on the router advertisements, then just using the trees has less overhead because it doesn't require route dissemination. As the number of unique destinations rises, the only-tree version does require more control traffic. RIO is optional and I still think the RIO makes sense is many destinations are to be reached and mostly from the sink. Pascal, while I agree with you in general, I don't see how this fits the requirements. As spelled out in the protocol survey document, routing state should be bounded by O(D), where D is the number of "unique destinations". This term is not defined, but the document states that it scales at less than O(N), where N is the number of nodes. Thus there is a set of special (worthy) destinations, which get special consideration. These clearly include any border routers, and may include other routers. For example, the industrial requirements document says: Most of the traffic over the LLN is publish/subscribe of sensor data from the field device towards a sink that can be a backbone router, a gateway, or a controller/manager. The controller/managers seem likely candidates for special destinations. Given the O(D) bound on routing state, only a small subset of routers can be destinations for RIO routes. My point is that that same subset of routers could just as well be roots of trees. This wouldn't make sense if D were proportional to N, but the requirements make it clear that this isn't the case. The O(D) bound means that the situation you mention, where there are many destinations to be reached and mostly from the sink, needs to be handled through some other means, presumably by using source routing. But a tree rooted at a destination would be propagated to a lot more nodes then just the parents up the tree. Yes, but that doesn't mean that it takes a lot more effort. A single message from A to B can propogate information about as many trees as will fit in the message. Seeing as how at least one tree needs to be maintained, no additional messages may be needed at all, depending on the number of unique/special destinations. Any to any is not what the requirements ask to optimize for. But I agree with you that it can be worth spawning additional topologies. There is text for that in the second half of the document but nothing for special (worthy) destinations so I can add some text there. Would that be what you're asking for? Not really. I would like multiple trees to be explictly supported by the text, including trees that are not rooted at border routers. As it stands, while not explicitly prohibited, the text is somewhat ambiguous as to whether additional trees are allowed and exactly how they should work. Because I think that using multiple trees is a better fit with the requirements than using RIO, I want to raise the possibility of removing the RIO section. While RIO is optional, having it does make the document more complicated. I fully understand that you may not agree with me on this. Thanks for listening. -Richard Kelsey ---------------- This message and the information it contains are the proprietary and confidential property of Ember Corporation and may be privileged. If you are not the intended recipient, please do not read, copy, disclose or distribute its contents to any party, and notify the sender immediately. ------_=_NextPart_001_01C9B68A.C4B26113 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable RE: [Roll] FW: New Version Notification fordraft-thubert-roll-fundamentals-00

Hi Richard:

 


Richard>


Pascal, while I agree with you in general, I don't see how
this fits the requirements.  As spelled out in the protocol
survey document, routing state should be bounded by = O(D),

 

Pascal>

The difference we are talking about is whether a = destination in the LLN needs to be reachable from all other nodes in the LLN or = only/mostly from the sink and whatever’s behind the sink. Whether you do new = trees or RIO, only the destinations that need to be reachable need to advertise themselves so you get your o (or O or Omega or ?) of D. It’s more = a matter of whether an assembly is overkill or insufficient for a given = use case.

 

RIO only advertise along a unicast path towards the sink = that’s already there as part of the tree, so that’s the minimum = control.

 

Building a tree to LLN destinations would require = maintaining and flooding new topological information and metrics to all and = that’s a lot more, one thing we do not seem to agree upon but that’s = fine.

 

The intermediate approach to build on demand constrained = routes is also discussed in the draft.

 

The question is whether one of those 3 approaches fits it = all and I don’t think so.

So we’ll have to sort out what’s mandatory = and what’s optional, based on common value I guess.

 

 

Thus there is a = set of special (worthy) destinations, which
get special consideration.  These clearly include any border
routers, and may include other routers.  For example, the
industrial requirements document says:

   Most of the traffic over the LLN is publish/subscribe = of
   sensor data from the field device towards a sink that = can
   be a backbone router, a gateway, or a = controller/manager.

The controller/managers seem likely candidates for special
destinations.

For all examples I know of, those devices are either the = sinks or attached to a backbone via the sink.

So the default route is enough to reach these devices and = TD/RIO fits the bill.

 

I would like = multiple trees to be explictly
supported by the text, including trees that are not rooted
at border routers.  As it stands, while not explicitly
prohibited, the text is somewhat ambiguous as to whether
additional trees are allowed and exactly how they should
work.

Will do. There is text in multiple topologies about that = but after this discussion, it is clear that some addition would be required. = . Note that we’re getting close a classical DV if we follow that path too = far and I do not think that this is the general direction we’re = taking.

 

I need to make sure that the text is clear that the = default route is only installed when the G bit is set, that there can be only = one tree with the G bit set (unless some Multi topology routing is in place). I = can also indicate that nodes might belong to multiple non-g trees; and that nodes install a route to the tree ID over the corresponding = tree.

 

I plan to submit by Wednesday. If you have a suggestion = for text to add/modify/remove you’re certainly welcome J

 

Best,

 

Pascal

From:= Richard = Kelsey [mailto:richard.kelsey@ember.com]
Sent: vendredi 3 avril 2009 21:11
To: Pascal Thubert (pthubert)
Cc: roll@ietf.org; stevey@amsl.com
Subject: RE: [Roll] FW: New Version Notification fordraft-thubert-roll-fundamentals-00

 

   Date: Fri, 3 Apr 2009 18:02:15 +0200
   From: "Pascal Thubert (pthubert)" <pthubert@cisco.com>

      Date: Fri, 3 Apr 2009 11:40:15 -0400
      From: "Richard Kelsey" <richard.kelsey@ember.com>

      For control traffic, which version is = less costly depends on
      the details.  For example, if there = are few enough unique
      destinations** that all of the tree data = can be piggy-backed
      on the router advertisements, then just = using the trees has
      less overhead because it doesn't require = route
      dissemination.  As the number of = unique destinations rises,
      the only-tree version does require more = control traffic.

   RIO is optional and I still think the RIO makes sense is = many
   destinations are to be reached and mostly from the = sink.

Pascal, while I agree with you in general, I don't see how
this fits the requirements.  As spelled out in the protocol
survey document, routing state should be bounded by O(D),
where D is the number of "unique destinations".  This = term
is not defined, but the document states that it scales at
less than O(N), where N is the number of nodes.

Thus there is a set of special (worthy) destinations, which
get special consideration.  These clearly include any border
routers, and may include other routers.  For example, the
industrial requirements document says:

   Most of the traffic over the LLN is publish/subscribe = of
   sensor data from the field device towards a sink that = can
   be a backbone router, a gateway, or a = controller/manager.

The controller/managers seem likely candidates for special
destinations.

Given the O(D) bound on routing state, only a small subset
of routers can be destinations for RIO routes.  My point is
that that same subset of routers could just as well be roots
of trees.  This wouldn't make sense if D were proportional
to N, but the requirements make it clear that this isn't the
case.

The O(D) bound means that the situation you mention, where
there are many destinations to be reached and mostly from
the sink, needs to be handled through some other means,
presumably by using source routing.

   But a tree rooted at a destination would be propagated = to
   a lot more nodes then just the parents up the tree.

Yes, but that doesn't mean that it takes a lot more effort.
A single message from A to B can propogate information about
as many trees as will fit in the message.  Seeing as how at
least one tree needs to be maintained, no additional
messages may be needed at all, depending on the number of
unique/special destinations.

   Any to any is not what the requirements ask to optimize
   for.  But I agree with you that it can be worth = spawning
   additional topologies. There is text for that in the
   second half of the document but nothing for special
   (worthy) destinations so I can add some text there.

   Would that be what you're asking for?

Not really.  I would like multiple trees to be explictly
supported by the text, including trees that are not rooted
at border routers.  As it stands, while not explicitly
prohibited, the text is somewhat ambiguous as to whether
additional trees are allowed and exactly how they should
work.

Because I think that using multiple trees is a better fit
with the requirements than using RIO, I want to raise the
possibility of removing the RIO section.  While RIO is
optional, having it does make the document more complicated.
I fully understand that you may not agree with me on this.

Thanks for listening.

            &= nbsp;           &n= bsp;       -Richard Kelsey
----------------
This message and the information it contains are the proprietary
and confidential property of Ember Corporation and may be = privileged.
If you are not the intended recipient, please do not read, copy,
disclose or distribute its contents to any party, and notify the
sender immediately.

------_=_NextPart_001_01C9B68A.C4B26113-- From tzeta.tsao@ekasystems.com Mon Apr 6 09:31: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 DC77F3A6CAE for ; Mon, 6 Apr 2009 09:31:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 cHmRM6BVeXow for ; Mon, 6 Apr 2009 09:31:25 -0700 (PDT) Received: from smtp108.biz.mail.re2.yahoo.com (smtp108.biz.mail.re2.yahoo.com [206.190.52.47]) by core3.amsl.com (Postfix) with SMTP id F30C23A6CCA for ; Mon, 6 Apr 2009 09:31:24 -0700 (PDT) Received: (qmail 83854 invoked from network); 6 Apr 2009 16:32:30 -0000 Received: from unknown (HELO ?192.168.0.237?) (tzeta.tsao@209.48.242.70 with plain) by smtp108.biz.mail.re2.yahoo.com with SMTP; 6 Apr 2009 16:32:30 -0000 X-Yahoo-SMTP: 18Fc8ICswBBVPDv5exrrk3k0phuhQJtGVVI9vm7eGXDtosryT8s- X-Yahoo-Newman-Property: ymail-3 Message-ID: <49DA2E6E.3040700@ekasystems.com> Date: Mon, 06 Apr 2009 12:31:42 -0400 From: Tzeta Tsao User-Agent: Mozilla-Thunderbird 2.0.0.19 (X11/20090103) MIME-Version: 1.0 To: JP Vasseur References: <49CB86DA.9050104@eecs.berkeley.edu><49D218CC.6040304@ekasystems.com><49D4FE48.3010104@eecs.berkeley.edu><49D53180.5030509@ekasystems.com> <8CF80793-154E-4DC3-A7A2-F3B8CF471DDD@cisco.com> In-Reply-To: <8CF80793-154E-4DC3-A7A2-F3B8CF471DDD@cisco.com> X-Enigmail-Version: 0.95.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "Dearlove, Christopher \(UK\)" , ROLL WG Subject: Re: [Roll] simple security (Re: security update?) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 06 Apr 2009 16:31:25 -0000 >> >> I thought his possible (he says "I wonder") conclusion was a need for >> more security, not achieving more security. While I'm not sure it's >> the minimal configuration that's the only reason why, a scenario where >> devices are distributed without either human attendance or continual >> monitoring certainly raises some difficult security issues. > > This is exactly my point. This is not the 0-config requirement that > requires more security. > Of course 0-config with high security requirements is more challenging. > > Hi JP, All: It may be true that 0-config itself does not call for more security. It is the additional requirement of autonomous operation that deployed LLN devices will not have either human attendance or continual monitoring that prompts the question of whether these devices need more security. LLNs of smaller number of devices may or may not have a problem of getting human intervention when disasters occur; LLNs with tens of thousands of devices cannot rely on such procedures. The model of having an operator going up to a router to reconfigure is not widely applicable to LLNs. It is mission critical for certain types of LLNs to be secure out-of-the-box, even for their entire life-cycle, without reconfiguration. Would people, especially who work on smaller sized LLNs, offer some insight. Regards, Tzeta From bmarq@estv.ipv.pt Mon Apr 6 14:25: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 DF5A83A682D for ; Mon, 6 Apr 2009 14:25:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.178 X-Spam-Level: X-Spam-Status: No, score=-1.178 tagged_above=-999 required=5 tests=[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 iRmZtr+iuyO7 for ; Mon, 6 Apr 2009 14:25:02 -0700 (PDT) Received: from vinfante.estv.ipv.pt (infante.estv.ipv.pt [193.137.7.3]) by core3.amsl.com (Postfix) with ESMTP id 471FC3A6D09 for ; Mon, 6 Apr 2009 14:25:00 -0700 (PDT) Received: (qmail 15297 invoked by uid 89); 6 Apr 2009 21:25:23 -0000 Received: from unknown (HELO ?192.168.2.102?) (bmarq@estv.ipv.pt@83.132.62.78) by 0 with ESMTPA; 6 Apr 2009 21:25:23 -0000 Message-Id: From: Bruno Marques To: roll@ietf.org Content-Type: multipart/alternative; boundary=Apple-Mail-3-900441112 Mime-Version: 1.0 (Apple Message framework v930.3) Date: Mon, 6 Apr 2009 22:26:02 +0100 X-Mailer: Apple Mail (2.930.3) Subject: [Roll] 6LoWPAN + LOAD NS-2 Implementations X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 06 Apr 2009 21:25:10 -0000 --Apple-Mail-3-900441112 Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Hello I'm a portuguese PhD Student at the Engineering Faculty of the =20 University of Porto (FEUP). I'm researching on low power Application Driven routing protocols for =20= WSN. In that context, it is possible to have the source code of 6LoWPAN =20 Adaptation layer and LOAD routing protocol implementation in NS-2 used =20= for comparison, or perhaps indicate somebody else who can help me ? Thanking you in advance, best wishes, ------------------------------------------------------------------ Bruno Filipe Marques, MsC in Electrical and Computer Engineering FCT PhD Schollarship (SFRH/BD/36221/2007) PhD Student @ DEEC/FEUP WiMobNet, UTM, INESC Porto, Departamento de Engenharia Electrot=E9cnica Escola Superior de Tecnologia Instituto Polit=E9cnico de Viseu Portugal url: http://www.estv.ipv.pt/paginaspessoais/bmarq/ e-mail: bmarq@estv.ipv.pt Lembre-se da sua responsabilidade para com o ambiente antes de =20 imprimir este e-mail ! --Apple-Mail-3-900441112 Content-Type: multipart/related; boundary=Apple-Mail-4-900441112; type="text/html" --Apple-Mail-4-900441112 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hello

I'm a portuguese = PhD Student at the Engineering Faculty of the University of Porto = (FEUP).

I'm researching on low power Application Driven routing = protocols for WSN.
----------------------------------------------------= --------------
Bruno Filipe Marques,
MsC = in Electrical and Computer Engineering

FCT = PhD Schollarship (SFRH/BD/36221/2007)
PhD Student @ = DEEC/FEUP
WiMobNet, UTM, INESC = Porto,

Departamento de Engenharia = Electrot=E9cnica
Escola Superior de = Tecnologia
Instituto Polit=E9cnico de = Viseu
Portugal

<= /div>




Lembre-se da sua = responsabilidade para com o ambiente antes de imprimir este e-mail = !

= --Apple-Mail-4-900441112 Content-Disposition: inline; filename=MadeOn_lime.gif Content-Transfer-Encoding: base64 Content-Type: image/gif; x-unix-mode=0644; name="MadeOn_lime.gif" Content-Id: <76987BA1-3CDD-483E-BD72-CC0C1D808C3E@netvisao.pt> R0lGODlhWAAfANUAAGu3QrW1tXi8Qb+/v3p6enBwcO/v7/b5+N/f38zMzFi2Ra2trWO2RQ0NDdbW 1l5eXj09PVOuQzMzM0OfL6Ojo7/evEWTOUqnQXnASx0dHZmZmRlvF9Hm10WcN+bz6K/Vr1ahW4OD g3O+SU1NTXG7YMLCwiqIH5nMmT6JMt3s4oS4g3y5fVGgQsznyUiQSzKAKJfDnhBjEGegdRuGIYq3 ljOZM1igT3mvd0qCUI6OjgAAAGZmZv///wAAAAAAAAAAACH5BAAAAAAALAAAAABYAB8AAAb/wJxw SCwaj8ikcslc8p7QqHRKrVqv2GxVqO16v2AsN6x1BALPUqBkDTjI33H3ULnBDtjAbofgFXY5Vjto cF1yWQcfETUnWXoEbjsEgQE5Ggk8CBp6aA4UGm9QBgsabCU5p4RPlZdbgV0VESYkKY47CzkBIUII AQk5BQcFIRSDBoN6BlAEIQs7ajsaGnxPvb8Frl0eJCYgHFp6CTvNQgY5BAQ7Duo8yIA5g0/rb0J6 PPNP5ug72VYHHh7+qVjBwUCKFHja8NuDoN4OA8WOURDni8+BAH14CJtY4Aw/fDySFes35QCHDydO fGjBgUOFFSBA0MhIxZ4GbLwIDNtxoEQB/3hoAvxZECVBiAIULn5kl0lnCJ5UDkFJtIKEVRIrTqhg cKHrBhwtCoklI/XJBxsKAKhduxYDhhkbKoyd66UsBxATRIgQwLevALcdUNz5kiCDDglTRuhoMIBu 1FdRYLwAgMGvXxGyVCT8gkCHDkyiPIN2LEWqARk13Frmq3ZCB7lkGujABoWCZ9KPpaRw0aGy5bUM JkQISwZChgxRRiiWkmCAsigIBtCsC/nJ7gkY9Ipgu3bCBdhhIBT4nC8DAR1QFmSQIKHBcwMQHkjQ MQKMVA94RTBgwH1thAmNFDeADq9QUMB5TwyIzQI6NGaABAQ88UAD9lWn0Q0mKBABf/0BoP/ABCwQ 9wV8PDSAGA8jJHAeJvEl2CAPBLgHhYVZlPWBCR0ooACHbDGgwAUo2FDBZloMgM0DOvSB2HmNNeZi YxlAIJZdFmSo435Y+qghCjGA4MEXA0TIYA4LYMNkURC8ONuUNPKgwgY5Xrmfjj9a8EIMMhCZRZhP mPgAJmc+UQAEOahJGxxl8cCBBRuwEMGjdEZwgQUobIACeF3wyQOSyPHAoIMSPMDDgI01IGUhifLw wQaNssDCBa51YIEFNcxAg541RuipDqKO+mIBnX6KooyItqmRCjFs8MILKMxqAawzyPDcFwUc2gBR fqyZpnPzPRAdr+lNV6OxGsHgggsrVJBMQgsnkCDTl2AU0EADvb5y3mI5KGZioQ1QwEOhEBDwQK/U 4ZYFAgYYIK4UBqDTxwKjqUgAtnGQa/DFYaSK8cYFc+xxxk2ELPLIJDcRBAA7 --Apple-Mail-4-900441112-- --Apple-Mail-3-900441112-- From kavaler@dslextreme.com Mon Apr 6 22:21: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 6ACF73A680A for ; Mon, 6 Apr 2009 22:21:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sX8sKR7ieMyw for ; Mon, 6 Apr 2009 22:21:52 -0700 (PDT) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.228]) by core3.amsl.com (Postfix) with ESMTP id D362C3A67FD for ; Mon, 6 Apr 2009 22:21:52 -0700 (PDT) Received: by rv-out-0506.google.com with SMTP id b25so127668rvf.5 for ; Mon, 06 Apr 2009 22:22:59 -0700 (PDT) Received: by 10.140.172.20 with SMTP id u20mr1738833rve.244.1239081779120; Mon, 06 Apr 2009 22:22:59 -0700 (PDT) Received: from ?10.0.0.2? (netblock-68-183-26-10.dslextreme.com [68.183.26.10]) by mx.google.com with ESMTPS id k37sm856814rvb.6.2009.04.06.22.22.56 (version=SSLv3 cipher=RC4-MD5); Mon, 06 Apr 2009 22:22:58 -0700 (PDT) Sender: Robert Kavaler Message-ID: <49DAE32E.9060706@sensysnetworks.com> Date: Mon, 06 Apr 2009 22:22:54 -0700 From: Robert Kavaler User-Agent: Thunderbird 2.0.0.21 (X11/20090320) MIME-Version: 1.0 To: Tzeta Tsao References: <49CB86DA.9050104@eecs.berkeley.edu><49D218CC.6040304@ekasystems.com><49D4FE48.3010104@eecs.berkeley.edu><49D53180.5030509@ekasystems.com> <8CF80793-154E-4DC3-A7A2-F3B8CF471DDD@cisco.com> <49DA2E6E.3040700@ekasystems.com> In-Reply-To: <49DA2E6E.3040700@ekasystems.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: ROLL WG Subject: Re: [Roll] simple security (Re: security update?) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 07 Apr 2009 05:23:22 -0000 Our application consists of a relatively small number of sensors and routers in any given cluster (maybe 50 sensors, 4 repeaters, 1 access point is a typical cluster). We had two issues when we implemented security: key distribution and the number of keys required. We used a simple scheme based on private keys and a NONCE. The idea of being secure out of the box is a difficult one because somehow you need to get at least one key (in our case two) into each unit before it is deployed. For our application, once a sensor is deployed you cannot get to it again, ever (they are embedded in the roadway). One can insert a private key into each unit and ship these keys along with the units so that any peer might be able to communicate with the unit. Unfortunately this didn't work for a couple reasons: first our customers did not like the idea that even we knew the key for each unit and second this method requires that a router have a list of keys, one for each sensor that it must talk with. The customer ended up installing their own keys with some special hardware we developed. The second issue is defining the total number of keys involved. We opted for a one key per application approach. One application was the routing/configuration/synchronization application. For us, these three applications are embedded in the same packet. This application uses a single key for all sensors, repeaters and access points in a given cluster (a PAN). The second application was our reporting application, which would encrypt "data" packets with a per sensor key. Thus each sensor had two keys, each repeater and access point had one key, and the processing application, which ran on a external server, had lots of keys (the peers of the sensor keys). Robert Kavaler www.sensysnetworks.com Tzeta Tsao wrote: >>> I thought his possible (he says "I wonder") conclusion was a need for >>> more security, not achieving more security. While I'm not sure it's >>> the minimal configuration that's the only reason why, a scenario where >>> devices are distributed without either human attendance or continual >>> monitoring certainly raises some difficult security issues. >>> >> This is exactly my point. This is not the 0-config requirement that >> requires more security. >> Of course 0-config with high security requirements is more challenging. >> >> >> > Hi JP, All: > > It may be true that 0-config itself does not call for more security. > > It is the additional requirement of autonomous operation that deployed > LLN devices > will not have either human attendance or continual monitoring that > prompts the > question of whether these devices need more security. > > LLNs of smaller number of devices may or may not have a problem of > getting human > intervention when disasters occur; LLNs with tens of thousands of > devices cannot > rely on such procedures. The model of having an operator going up to a > router to > reconfigure is not widely applicable to LLNs. It is mission critical for > certain types of > LLNs to be secure out-of-the-box, even for their entire life-cycle, without > reconfiguration. > > Would people, especially who work on smaller sized LLNs, offer some insight. > > Regards, > Tzeta > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > > From Jerald.P.Martocci@jci.com Tue Apr 7 06:35:13 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 C64DD3A69D8; Tue, 7 Apr 2009 06:35:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.608 X-Spam-Level: X-Spam-Status: No, score=-6.608 tagged_above=-999 required=5 tests=[AWL=-0.010, 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 r0rmrI7irgsx; Tue, 7 Apr 2009 06:35:12 -0700 (PDT) Received: from exprod8og119.obsmtp.com (exprod8og119.obsmtp.com [64.18.3.38]) by core3.amsl.com (Postfix) with ESMTP id 329553A69CE; Tue, 7 Apr 2009 06:35:12 -0700 (PDT) Received: from source ([192.132.24.137]) (using SSLv3) by exprod8ob119.postini.com ([64.18.7.12]) with SMTP ID DSNKSdtW0e5OHom4fBJlUafr/E4QoXKyHPQ4@postini.com; Tue, 07 Apr 2009 06:36:19 PDT Received: from jwimkrs1.na.jci.com ([10.10.6.31]) by smtpmke01.jci.com (Lotus Domino Release 8.0.1) with ESMTP id 2009040708362059-462849 ; Tue, 7 Apr 2009 08:36:20 -0500 In-Reply-To: <49DA2E6E.3040700@ekasystems.com> MIME-Version: 1.0 To: Tzeta Tsao X-Mailer: Lotus Notes Release 6.5.2 June 01, 2004 From: Jerald.P.Martocci@jci.com Message-ID: Date: Tue, 7 Apr 2009 08:36:09 -0500 X-MIMETrack: Serialize by Router on jwimkrs1.na.jci.com/NA/Johnson_Controls at 04/07/2009 08:36:12 AM, Serialize complete at 04/07/2009 08:36:12 AM, Itemize by SMTP Server on smtpmke01.jci.com/JCI_SMTP(Release 8.0.1|February 07, 2008) at 04/07/2009 08:36:20 AM, Serialize by Router on smtpmke01.jci.com/JCI_SMTP(Release 8.0.1|February 07, 2008) at 04/07/2009 08:36:26 AM, Serialize complete at 04/07/2009 08:36:26 AM Content-Type: multipart/alternative; boundary="=_alternative 004AB8B186257591_=" Cc: "Dearlove, Christopher \(UK\)" , ROLL WG , roll-bounces@ietf.org Subject: Re: [Roll] simple security (Re: security update?) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 07 Apr 2009 13:35:13 -0000 This is a multipart message in MIME format. --=_alternative 004AB8B186257591_= Content-Type: text/plain; charset="US-ASCII" Tzeta, Per your request, here are my comments on LLNs being installed in Commercial Buildings... Most automation companies install sensors and controllers into a building. These devices may be installed over a fairly wide time frame, yet must somehow be able to easily coalesce into a single LLN all operating under a single parameter set. This coalescence of various geographical (e.g. Floor 1, Floor 2, Floor 2) and logical building functions (Fire, Security, HVAC) is difficult process further complicated by the need to address network security issues. These devices are typically not customizable prior to delivery to the site. They are shrink-wrapped clones that differ only be their unique MAC address. In the commercial building sector, devices must come 'out of the box' with no security turned 'on'. This allows for tradesmen (electricians) to install the devices into a partially constructed building and verify operation without requiring sophisticated on-site device programming of network and link keys. We also cannot count on any IT devices (DHCP, L2 switches, L3 routers, AAA servers) being previously installed and operational. Once the system is totally constructed the need for network security is variable based on the building occupant(s). For example a single tenant owner occupied office building has little security threat and hence need little to no active security policy in place. A multi-tenant facility will require a higher layer of security to isolate the individual building occupants. A pharmaceutical or military facility will require a very high level of security. This security policy must be deployable from a central location since (as Robert Kavalar also points out in the urban market) many of these devices are now hidden under dry wall or above the ceiling grid. So in summary, for the commercial building sector, we need devices that can be installed with no security, ramped up to various levels of security once operational that must be downloaded with the security policy from a centralized source. This centralized source most often will not be available during the installation phase. Hope this helps. Jerry Martocci Tzeta Tsao Sent by: roll-bounces@ietf.org 04/06/2009 11:32 AM To JP Vasseur cc "Dearlove, Christopher \(UK\)" , ROLL WG Subject Re: [Roll] simple security (Re: security update?) >> >> I thought his possible (he says "I wonder") conclusion was a need for >> more security, not achieving more security. While I'm not sure it's >> the minimal configuration that's the only reason why, a scenario where >> devices are distributed without either human attendance or continual >> monitoring certainly raises some difficult security issues. > > This is exactly my point. This is not the 0-config requirement that > requires more security. > Of course 0-config with high security requirements is more challenging. > > Hi JP, All: It may be true that 0-config itself does not call for more security. It is the additional requirement of autonomous operation that deployed LLN devices will not have either human attendance or continual monitoring that prompts the question of whether these devices need more security. LLNs of smaller number of devices may or may not have a problem of getting human intervention when disasters occur; LLNs with tens of thousands of devices cannot rely on such procedures. The model of having an operator going up to a router to reconfigure is not widely applicable to LLNs. It is mission critical for certain types of LLNs to be secure out-of-the-box, even for their entire life-cycle, without reconfiguration. Would people, especially who work on smaller sized LLNs, offer some insight. Regards, Tzeta _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll --=_alternative 004AB8B186257591_= Content-Type: text/html; charset="US-ASCII"

Tzeta,

Per your request, here are my comments on LLNs being installed in Commercial Buildings...

Most automation companies install sensors and controllers into a building.  These devices may be installed over a fairly wide time frame, yet must somehow be able to easily coalesce into a single LLN all operating under a single parameter set.  This coalescence of various geographical (e.g. Floor 1, Floor 2, Floor 2) and logical building functions (Fire, Security, HVAC) is difficult process further complicated by the need to address network security issues.  These devices are typically not customizable prior to delivery to the site.  They are shrink-wrapped clones that differ only be their unique MAC address.

In the commercial building sector, devices must come 'out of the box' with no security turned 'on'.  This allows for tradesmen (electricians) to install the devices into a partially constructed building and verify operation without requiring sophisticated on-site device programming of network and link keys.  We also cannot count on any IT devices (DHCP, L2 switches, L3 routers, AAA servers) being previously installed and operational.

Once the system is totally constructed the need for network security is variable based on the building occupant(s).  For example a single tenant owner occupied office building has little security threat and hence need little to no active security policy in place.  A multi-tenant facility will require a higher layer of security to isolate the individual building occupants.  A pharmaceutical or military facility will require a very high level of security.  This security policy must be deployable from a central location since (as Robert Kavalar also points out in the urban market) many of these devices are now hidden under dry wall or above the ceiling grid.

So in summary, for the commercial building sector, we need devices that can be installed with no security, ramped up to various levels of security once operational that must be downloaded with the security policy from a centralized source.  This centralized source most often will not be available during the installation phase.

Hope this helps.

Jerry Martocci





Tzeta Tsao <tzeta.tsao@ekasystems.com>
Sent by: roll-bounces@ietf.org

04/06/2009 11:32 AM

To
JP Vasseur <jvasseur@cisco.com>
cc
"Dearlove, Christopher \(UK\)" <Chris.Dearlove@baesystems.com>, ROLL WG <roll@ietf.org>
Subject
Re: [Roll] simple security (Re:  security update?)






>>
>> I thought his possible (he says "I wonder") conclusion was a need for
>> more security, not achieving more security. While I'm not sure it's
>> the minimal configuration that's the only reason why, a scenario where
>> devices are distributed without either human attendance or continual
>> monitoring certainly raises some difficult security issues.
>
> This is exactly my point. This is not the 0-config requirement that
> requires more security.
> Of course 0-config with high security requirements is more challenging.
>
>
Hi JP, All:

It may be true that 0-config itself does not call for more security.

It is the additional requirement of autonomous operation that deployed
LLN devices
will not have either human attendance or continual monitoring that
prompts the
question of whether these devices need more security.

LLNs of smaller number of devices may or may not have a problem of
getting human
intervention when disasters occur; LLNs with tens of thousands of
devices cannot
rely on such procedures. The model of having an operator going up to a
router to
reconfigure is not widely applicable to LLNs. It is mission critical for
certain types of
LLNs to be secure out-of-the-box, even for their entire life-cycle, without
reconfiguration.

Would people, especially who work on smaller sized LLNs, offer some insight.

Regards,
Tzeta
_______________________________________________
Roll mailing list
Roll@ietf.org
https://www.ietf.org/mailman/listinfo/roll
--=_alternative 004AB8B186257591_=-- From chris.dearlove@baesystems.com Tue Apr 7 06:43: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 6408C3A6978 for ; Tue, 7 Apr 2009 06:43:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.614 X-Spam-Level: X-Spam-Status: No, score=-6.614 tagged_above=-999 required=5 tests=[AWL=-0.015, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1abV-6aHv7LP for ; Tue, 7 Apr 2009 06:43:29 -0700 (PDT) Received: from smtp2.bae.co.uk (smtp2.bae.co.uk [20.133.0.12]) by core3.amsl.com (Postfix) with ESMTP id 55DE73A677C for ; Tue, 7 Apr 2009 06:43:29 -0700 (PDT) Received: from smtpb.greenlnk.net (smtpb.greenlnk.net [10.15.160.219]) by smtp2.bae.co.uk (Switch-3.1.10/Switch-3.1.10) with ESMTP id n37DiWf1009237 for ; Tue, 7 Apr 2009 14:44:32 +0100 (BST) Received: from glkas0002.GREENLNK.NET (glkas0002.greenlnk.net [10.15.184.52]) by smtpb.greenlnk.net (Switch-3.1.9/Switch-3.1.9) with ESMTP id n37DiWRB009882 for ; Tue, 7 Apr 2009 14:44:32 +0100 Received: from glkms1100.GREENLNK.NET ([10.15.184.108]) by glkas0002.GREENLNK.NET with InterScan Message Security Suite; Tue, 07 Apr 2009 14:44:32 +0100 Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1100.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.2499); Tue, 7 Apr 2009 14:44:31 +0100 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Tue, 7 Apr 2009 14:44:30 +0100 Message-ID: In-Reply-To: <8CF80793-154E-4DC3-A7A2-F3B8CF471DDD@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] simple security (Re: security update?) Thread-Index: Acm2g9LSRP0esVrqSO2luVFlTvMV0QBAkIDQ References: <49CB86DA.9050104@eecs.berkeley.edu><49D218CC.6040304@ekasystems.com><49D4FE48.3010104@eecs.berkeley.edu><49D53180.5030509@ekasystems.com> <8CF80793-154E-4DC3-A7A2-F3B8CF471DDD@cisco.com> From: "Dearlove, Christopher (UK)" To: "JP Vasseur" X-OriginalArrivalTime: 07 Apr 2009 13:44:31.0826 (UTC) FILETIME=[FAD0D320:01C9B786] Cc: ROLL WG Subject: Re: [Roll] simple security (Re: security update?) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 07 Apr 2009 13:43:30 -0000 JPV > Of course 0-config with high security requirements is more challenging. Which means that in at least some ROLL scenarios you have - High security requirements. - Serious threats (e.g. due to unattended devices). - Zero or limited pre-configuration. - A desire/need for decentralisation. I think challenging is a good word. (I could have added a fifth point of limited resources to use on the problem.) ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** From pister@eecs.berkeley.edu Tue Apr 7 08:36: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 43BCB3A6889; Tue, 7 Apr 2009 08:36:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.443 X-Spam-Level: X-Spam-Status: No, score=-6.443 tagged_above=-999 required=5 tests=[AWL=0.155, 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 CVd96Gx5xYU1; Tue, 7 Apr 2009 08:36:28 -0700 (PDT) Received: from gateway0.EECS.Berkeley.EDU (gateway0.EECS.Berkeley.EDU [169.229.60.87]) by core3.amsl.com (Postfix) with ESMTP id F23FB3A67A6; Tue, 7 Apr 2009 08:36:27 -0700 (PDT) Received: from [127.0.0.1] (dhcp-32-46.EECS.Berkeley.EDU [128.32.32.46]) (authenticated bits=0) by gateway0.EECS.Berkeley.EDU (8.14.3/8.13.5) with ESMTP id n37FbPtx024706 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 7 Apr 2009 08:37:26 -0700 (PDT) Message-ID: <49DB7330.9010307@eecs.berkeley.edu> Date: Tue, 07 Apr 2009 08:37:20 -0700 From: Kris Pister User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Jerald.P.Martocci@jci.com References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------050008090908060609050607" Cc: "Dearlove, Christopher \(UK\)" , ROLL WG , roll-bounces@ietf.org Subject: Re: [Roll] simple security (Re: security update?) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 07 Apr 2009 15:36:29 -0000 This is a multi-part message in MIME format. --------------050008090908060609050607 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Jerry - good input. I have one correction and one opinion: >> devices must come 'out of the box' with no security turned 'on'. I completely agree with the need for 0-config on security. We ship into an industry in which (customer quote) "the only tools the installer knows how to use are a sledge hammer and a blowtorch." :) This does NOT mean that the networks must have no security. There are simple security mechanisms that allow such networks to be built with 0-config, and still maintain many/most/all of the desired security properties. >> office building has little security threat and hence need little to no active security policy in place In my opinion, it won't take hackers very long to figure out that they can have a lot of fun taking over HVAC and lighting systems in office buildings. It won't take very many such takeovers before 1) everyone demands more security, or 2) people abandon the technology altogether. ksjp Jerald.P.Martocci@jci.com wrote: > > > Tzeta, > > Per your request, here are my comments on LLNs being installed in > Commercial Buildings... > > Most automation companies install sensors and controllers into a > building. These devices may be installed over a fairly wide time > frame, yet must somehow be able to easily coalesce into a single LLN > all operating under a single parameter set. This coalescence of > various geographical (e.g. Floor 1, Floor 2, Floor 2) and logical > building functions (Fire, Security, HVAC) is difficult process further > complicated by the need to address network security issues. These > devices are typically not customizable prior to delivery to the site. > They are shrink-wrapped clones that differ only be their unique MAC > address. > > In the commercial building sector, devices must come 'out of the box' > with no security turned 'on'. This allows for tradesmen > (electricians) to install the devices into a partially constructed > building and verify operation without requiring sophisticated on-site > device programming of network and link keys. We also cannot count on > any IT devices (DHCP, L2 switches, L3 routers, AAA servers) being > previously installed and operational. > > Once the system is totally constructed the need for network security > is variable based on the building occupant(s). For example a single > tenant owner occupied office building has little security threat and > hence need little to no active security policy in place. A > multi-tenant facility will require a higher layer of security to > isolate the individual building occupants. A pharmaceutical or > military facility will require a very high level of security. This > security policy must be deployable from a central location since (as > Robert Kavalar also points out in the urban market) many of these > devices are now hidden under dry wall or above the ceiling grid. > > So in summary, for the commercial building sector, we need devices > that can be installed with no security, ramped up to various levels of > security once operational that must be downloaded with the security > policy from a centralized source. This centralized source most often > will not be available during the installation phase. > > Hope this helps. > > Jerry Martocci > > > > > > *Tzeta Tsao * > Sent by: roll-bounces@ietf.org > > 04/06/2009 11:32 AM > > > To > JP Vasseur > cc > "Dearlove, Christopher \(UK\)" , ROLL > WG > Subject > Re: [Roll] simple security (Re: security update?) > > > > > > > > > > > >> > >> I thought his possible (he says "I wonder") conclusion was a need for > >> more security, not achieving more security. While I'm not sure it's > >> the minimal configuration that's the only reason why, a scenario where > >> devices are distributed without either human attendance or continual > >> monitoring certainly raises some difficult security issues. > > > > This is exactly my point. This is not the 0-config requirement that > > requires more security. > > Of course 0-config with high security requirements is more challenging. > > > > > Hi JP, All: > > It may be true that 0-config itself does not call for more security. > > It is the additional requirement of autonomous operation that deployed > LLN devices > will not have either human attendance or continual monitoring that > prompts the > question of whether these devices need more security. > > LLNs of smaller number of devices may or may not have a problem of > getting human > intervention when disasters occur; LLNs with tens of thousands of > devices cannot > rely on such procedures. The model of having an operator going up to a > router to > reconfigure is not widely applicable to LLNs. It is mission critical for > certain types of > LLNs to be secure out-of-the-box, even for their entire life-cycle, > without > reconfiguration. > > Would people, especially who work on smaller sized LLNs, offer some > insight. > > Regards, > Tzeta > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > > ------------------------------------------------------------------------ > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > --------------050008090908060609050607 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Jerry - good input.  I have one correction and one opinion:
>> devices must come 'out of the box' with no security turned 'on'.

I completely agree with the need for 0-config on security.  We ship into an industry in which (customer quote) "the only tools the installer knows how to use are a sledge hammer and a blowtorch." :)
This does NOT mean that the networks must have no security.  There are simple security mechanisms that allow such networks to be built with 0-config, and still maintain many/most/all of the desired security properties.

>> office building has little security threat and hence need little to no active security policy in place

In my opinion, it won't take hackers very long to figure out that they can have a lot of fun taking over HVAC and lighting systems in office buildings.  It won't take very many such takeovers before 1) everyone demands more security, or 2) people abandon the technology altogether.

ksjp

Jerald.P.Martocci@jci.com wrote:


Tzeta,

Per your request, here are my comments on LLNs being installed in Commercial Buildings...

Most automation companies install sensors and controllers into a building.  These devices may be installed over a fairly wide time frame, yet must somehow be able to easily coalesce into a single LLN all operating under a single parameter set.  This coalescence of various geographical (e.g. Floor 1, Floor 2, Floor 2) and logical building functions (Fire, Security, HVAC) is difficult process further complicated by the need to address network security issues.  These devices are typically not customizable prior to delivery to the site.  They are shrink-wrapped clones that differ only be their unique MAC address.

In the commercial building sector, devices must come 'out of the box' with no security turned 'on'.  This allows for tradesmen (electricians) to install the devices into a partially constructed building and verify operation without requiring sophisticated on-site device programming of network and link keys.  We also cannot count on any IT devices (DHCP, L2 switches, L3 routers, AAA servers) being previously installed and operational.

Once the system is totally constructed the need for network security is variable based on the building occupant(s).  For example a single tenant owner occupied office building has little security threat and hence need little to no active security policy in place.  A multi-tenant facility will require a higher layer of security to isolate the individual building occupants.  A pharmaceutical or military facility will require a very high level of security.  This security policy must be deployable from a central location since (as Robert Kavalar also points out in the urban market) many of these devices are now hidden under dry wall or above the ceiling grid.

So in summary, for the commercial building sector, we need devices that can be installed with no security, ramped up to various levels of security once operational that must be downloaded with the security policy from a centralized source.  This centralized source most often will not be available during the installation phase.

Hope this helps.

Jerry Martocci





Tzeta Tsao <tzeta.tsao@ekasystems.com>
Sent by: roll-bounces@ietf.org

04/06/2009 11:32 AM

To
 JP Vasseur <jvasseur@cisco.com>
cc
 "Dearlove, Christopher \(UK\)" <Chris.Dearlove@baesystems.com>, ROLL WG <roll@ietf.org>
Subject
 Re: [Roll] simple security (Re:  security update?)








>>
>> I thought his possible (he says "I wonder") conclusion was a need for
>> more security, not achieving more security. While I'm not sure it's
>> the minimal configuration that's the only reason why, a scenario where
>> devices are distributed without either human attendance or continual
>> monitoring certainly raises some difficult security issues.
>
> This is exactly my point. This is not the 0-config requirement that
> requires more security.
> Of course 0-config with high security requirements is more challenging.
>
>
Hi JP, All:

It may be true that 0-config itself does not call for more security.

It is the additional requirement of autonomous operation that deployed
LLN devices
will not have either human attendance or continual monitoring that
prompts the
question of whether these devices need more security.

LLNs of smaller number of devices may or may not have a problem of
getting human
intervention when disasters occur; LLNs with tens of thousands of
devices cannot
rely on such procedures. The model of having an operator going up to a
router to
reconfigure is not widely applicable to LLNs. It is mission critical for
certain types of
LLNs to be secure out-of-the-box, even for their entire life-cycle, without
reconfiguration.

Would people, especially who work on smaller sized LLNs, offer some insight.

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

_______________________________________________
Roll mailing list
Roll@ietf.org
https://www.ietf.org/mailman/listinfo/roll
--------------050008090908060609050607-- From pthubert@cisco.com Tue Apr 7 08: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 EB6073A68D1 for ; Tue, 7 Apr 2009 08:52:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.783 X-Spam-Level: X-Spam-Status: No, score=-9.783 tagged_above=-999 required=5 tests=[AWL=0.816, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bi1lvjy5oumr for ; Tue, 7 Apr 2009 08:52:36 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 5571C3A67A6 for ; Tue, 7 Apr 2009 08:52:36 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.39,338,1235952000"; d="scan'208";a="37645516" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 07 Apr 2009 15:53:41 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n37FrfAS009463; Tue, 7 Apr 2009 17:53:41 +0200 Received: from xbh-ams-331.emea.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n37FrfHO017120; Tue, 7 Apr 2009 15:53:41 GMT Received: from xmb-ams-337.cisco.com ([144.254.231.82]) by xbh-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 7 Apr 2009 17:53:41 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 7 Apr 2009 17:53:35 +0200 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC07427042@xmb-ams-337.emea.cisco.com> In-Reply-To: <200904061817.n36IHPhc005447@kelsey-ws.hq.ember.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] FW: New Version Notification fordraft-thubert-roll-fundamentals-00 Thread-Index: Acm24/nRd8IKcG6eS8e3zlHwk13OUQAtFnoA References: <7892795E1A87F04CADFCCF41FADD00FC07365A53@xmb-ams-337.emea.cisco.com> <200904021954.n32JsfUu016043@kelsey-ws.hq.ember.com> <7892795E1A87F04CADFCCF41FADD00FC073C3E79@xmb-ams-337.emea.cisco.com> <7892795E1A87F04CADFCCF41FADD00FC073C4145@xmb-ams-337.emea.cisco.com> <7892795E1A87F04CADFCCF41FADD00FC073C432D@xmb-ams-337.emea.cisco.com> <200904061817.n36IHPhc005447@kelsey-ws.hq.ember.com> From: "Pascal Thubert (pthubert)" To: "Richard Kelsey" X-OriginalArrivalTime: 07 Apr 2009 15:53:41.0747 (UTC) FILETIME=[0620EC30:01C9B799] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3708; t=1239119621; x=1239983621; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pthubert@cisco.com; z=From:=20=22Pascal=20Thubert=20(pthubert)=22=20 |Subject:=20RE=3A=20[Roll]=20FW=3A=20New=20Version=20Notifi cation=20fordraft-thubert-roll-fundamentals-00 |Sender:=20; bh=/HtgC0Yh33oiUC2AY8/Dw+qCySF+qwWWKql6oN618UU=; b=UbVzDDCzCTR7odrjgxHuPkwNnr8zS3UwjlNpmtAHVz4pvmM/qP9T8acVNg g6SWfsyE3dfpx+DcznjmD4kiBisMe2DZ5YWe7Sdx38szYGiJEx+dkTY6rgqV 3M0zVJfehW; Authentication-Results: ams-dkim-1; header.From=pthubert@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Cc: roll@ietf.org Subject: Re: [Roll] FW: New Version Notification fordraft-thubert-roll-fundamentals-00 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Apr 2009 15:52:38 -0000 Hi Richard: I'm working on changes to accommodate multiple trees. The trouble I have is for the default route. Whether the tree is Grounded or not, there can be only one tree used for default route, unless you enter MTR and flow labels. But the default is useful even if the tree is Floating.=20 The way I see it, we end up with a new bit, "default" and a node can only belong to one default tree. It'd better select a Grounded one. If a node belongs to 2 trees where the parent advertise default, the router will have to abandon the default on one of them as it propagates the TIO. I think we can easily describe that but I'm unsure whether that goes in the main text or in 6.5. What do you think? Pascal >-----Original Message----- >From: Richard Kelsey [mailto:kelsey@ember.com] >Sent: lundi 6 avril 2009 20:17 >To: Pascal Thubert (pthubert) >Cc: roll@ietf.org >Subject: Re: [Roll] FW: New Version Notification fordraft-thubert-roll-fundamentals-00 > >[Resending in the hopes that my mailing list problems >have finally been solved. Pascal, I apologize for the >duplicates. -RK] > > > Date: Mon, 6 Apr 2009 09:39:03 +0200 > From: "Pascal Thubert (pthubert)" > > Date: Fri, 3 Apr 2009 11:40:15 -0400 > From: "Richard Kelsey" > > The difference we are talking about is whether a > destination in the LLN needs to be reachable from all > other nodes in the LLN or only/mostly from the sink and > whatever's behind the sink. > >I thought we were disagreeing about the requirement for >routing state, which is not allowed to scale linearly with >the size of the network or with the size a node's >neighborhood. It seems to me that to meet this requirement >the RIO state can only contain information about a small >subset of the nodes in a network. > > Thus there is a set of special (worthy) destinations, which > get special consideration. These clearly include any border > routers, and may include other routers. For example, the > industrial requirements document says: > > Most of the traffic over the LLN is publish/subscribe of > sensor data from the field device towards a sink that can > be a backbone router, a gateway, or a controller/manager. > > The controller/managers seem likely candidates for special > destinations. > > For all examples I know of, those devices are either the sinks or > attached to a backbone via the sink. > >This is not the case for smart energy. An electric meter is >a data sink and has a backhaul connection, but it is very >unlikely that a utility will allow non-utility traffic onto >its backhaul network. The meter won't act as a border router. > > I need to make sure that the text is clear that the default route is > only installed when the G bit is set, that there can be only one tree > with the G bit set (unless some Multi topology routing is in place). I > can also indicate that nodes might belong to multiple non-g trees; and > that nodes install a route to the tree ID over the corresponding tree. > > I plan to submit by Wednesday. If you have a suggestion for text to > add/modify/remove you're certainly welcome J > >I'll try to get you something today. > > -Richard Kelsey > >---------------- >This message and the information it contains are the proprietary >and confidential property of Ember Corporation and may be privileged. >If you are not the intended recipient, please do not read, copy, >disclose or distribute its contents to any party, and notify the >sender immediately. From richard.kelsey@ember.com Tue Apr 7 09:16: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 4272B3A68A5 for ; Tue, 7 Apr 2009 09:16:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kvzBdn-YddfM for ; Tue, 7 Apr 2009 09:16:22 -0700 (PDT) Received: from EMPIRE.hq.ember.com (mail.ember.com [74.10.175.227]) by core3.amsl.com (Postfix) with ESMTP id 3A07B3A6888 for ; Tue, 7 Apr 2009 09:16:22 -0700 (PDT) Received: from kelsey-ws.hq.ember.com ([192.168.81.55]) by EMPIRE.hq.ember.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 7 Apr 2009 12:18:10 -0400 Received: from kelsey-ws.hq.ember.com (localhost.localdomain [127.0.0.1]) by kelsey-ws.hq.ember.com (8.13.4/8.13.4) with ESMTP id n37GHRKN016890; Tue, 7 Apr 2009 12:17:27 -0400 Received: (from kelsey@localhost) by kelsey-ws.hq.ember.com (8.13.4/8.12.8/Submit) id n37GHRGU016887; Tue, 7 Apr 2009 12:17:27 -0400 Date: Tue, 7 Apr 2009 12:17:27 -0400 Message-Id: <200904071617.n37GHRGU016887@kelsey-ws.hq.ember.com> To: pthubert@cisco.com In-reply-to: <7892795E1A87F04CADFCCF41FADD00FC07427042@xmb-ams-337.emea.cisco.com> (pthubert@cisco.com) From: Richard Kelsey References: <7892795E1A87F04CADFCCF41FADD00FC07365A53@xmb-ams-337.emea.cisco.com> <200904021954.n32JsfUu016043@kelsey-ws.hq.ember.com> <7892795E1A87F04CADFCCF41FADD00FC073C3E79@xmb-ams-337.emea.cisco.com> <7892795E1A87F04CADFCCF41FADD00FC073C4145@xmb-ams-337.emea.cisco.com> <7892795E1A87F04CADFCCF41FADD00FC073C432D@xmb-ams-337.emea.cisco.com> <200904061817.n36IHPhc005447@kelsey-ws.hq.ember.com> <7892795E1A87F04CADFCCF41FADD00FC07427042@xmb-ams-337.emea.cisco.com> X-OriginalArrivalTime: 07 Apr 2009 16:18:10.0661 (UTC) FILETIME=[71AB6950:01C9B79C] Cc: roll@ietf.org Subject: Re: [Roll] FW: New Version Notification fordraft-thubert-roll-fundamentals-00 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Apr 2009 16:16:23 -0000 Date: Tue, 7 Apr 2009 17:53:35 +0200 From: "Pascal Thubert (pthubert)" I'm working on changes to accommodate multiple trees. The trouble I have is for the default route. Whether the tree is Grounded or not, there can be only one tree used for default route, unless you enter MTR and flow labels. But the default is useful even if the tree is Floating. Makes sense. The way I see it, we end up with a new bit, "default" and a node can only belong to one default tree. It'd better select a Grounded one. If a node belongs to 2 trees where the parent advertise default, the router will have to abandon the default on one of them as it propagates the TIO. I think we can easily describe that but I'm unsure whether that goes in the main text or in 6.5. What do you think? Moving between trees is discussed in item 6 in 2.1, so I think it needs to mentioned there. Perhaps that item should be moved to 6.5? -Richard Kelsey ---------------- This message and the information it contains are the proprietary and confidential property of Ember Corporation and may be privileged. If you are not the intended recipient, please do not read, copy, disclose or distribute its contents to any party, and notify the sender immediately. From Jerald.P.Martocci@jci.com Tue Apr 7 11:40: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 474F43A6D91; Tue, 7 Apr 2009 11:40:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.607 X-Spam-Level: X-Spam-Status: No, score=-6.607 tagged_above=-999 required=5 tests=[AWL=-0.009, 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 pmCM6XCnNtxH; Tue, 7 Apr 2009 11:40:25 -0700 (PDT) Received: from exprod8og110.obsmtp.com (exprod8og110.obsmtp.com [64.18.3.100]) by core3.amsl.com (Postfix) with ESMTP id C284A3A6D85; Tue, 7 Apr 2009 11:40:24 -0700 (PDT) Received: from source ([192.132.24.139]) (using SSLv3) by exprod8ob110.postini.com ([64.18.7.12]) with SMTP ID DSNKSdueWlzU4nZ6IXuoLPB3l7vE4P4ZGNJE@postini.com; Tue, 07 Apr 2009 11:41:32 PDT Received: from jwimkrs1.na.jci.com ([10.10.6.31]) by smtpmke02.jci.com (Lotus Domino Release 8.0.1) with ESMTP id 2009040713435104-1908872 ; Tue, 7 Apr 2009 13:43:51 -0500 In-Reply-To: <49DB7330.9010307@eecs.berkeley.edu> MIME-Version: 1.0 To: Kris Pister X-Mailer: Lotus Notes Release 6.5.2 June 01, 2004 From: Jerald.P.Martocci@jci.com Message-ID: Date: Tue, 7 Apr 2009 13:41:22 -0500 X-MIMETrack: Serialize by Router on jwimkrs1.na.jci.com/NA/Johnson_Controls at 04/07/2009 01:41:26 PM, Serialize complete at 04/07/2009 01:41:26 PM, Itemize by SMTP Server on smtpmke02.jci.com/JCI_SMTP(Release 8.0.1|February 07, 2008) at 04/07/2009 01:43:51 PM, Serialize by Router on smtpmke02.jci.com/JCI_SMTP(Release 8.0.1|February 07, 2008) at 04/07/2009 01:43:55 PM, Serialize complete at 04/07/2009 01:43:55 PM Content-Type: multipart/related; boundary="=_related 0066A8CD86257591_=" Cc: "Dearlove, Christopher \(UK\)" , ROLL WG , roll-bounces@ietf.org Subject: Re: [Roll] simple security (Re: security update?) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 07 Apr 2009 18:40:27 -0000 This is a multipart message in MIME format. --=_related 0066A8CD86257591_= Content-Type: multipart/alternative; boundary="=_alternative 0066A8CD86257591_=" --=_alternative 0066A8CD86257591_= Content-Type: text/plain; charset="US-ASCII" Agreed. My comments were based on our existing products. I don't have a problem if out-of-the box security is turned on if it's with a well-known network key. Maybe when a device is in 'ad hoc' mode (as would be done durng commissioning) it can run open, but in 'infrastructure' mode it must have at least a network key. I have the same guys installing our systems as you do. We somehow have to lower the system complexity during the commission phase so we don't need a degreed IT professional installing our temperature sensors!!! Jerry Kris Pister 04/07/2009 10:37 AM To Jerald.P.Martocci@jci.com cc Tzeta Tsao , "Dearlove, Christopher (UK)" , ROLL WG , roll-bounces@ietf.org Subject Re: [Roll] simple security (Re: security update?) Jerry - good input. I have one correction and one opinion: >> devices must come 'out of the box' with no security turned 'on'. I completely agree with the need for 0-config on security. We ship into an industry in which (customer quote) "the only tools the installer knows how to use are a sledge hammer and a blowtorch." :) This does NOT mean that the networks must have no security. There are simple security mechanisms that allow such networks to be built with 0-config, and still maintain many/most/all of the desired security properties. >> office building has little security threat and hence need little to no active security policy in place In my opinion, it won't take hackers very long to figure out that they can have a lot of fun taking over HVAC and lighting systems in office buildings. It won't take very many such takeovers before 1) everyone demands more security, or 2) people abandon the technology altogether. ksjp Jerald.P.Martocci@jci.com wrote: Tzeta, Per your request, here are my comments on LLNs being installed in Commercial Buildings... Most automation companies install sensors and controllers into a building. These devices may be installed over a fairly wide time frame, yet must somehow be able to easily coalesce into a single LLN all operating under a single parameter set. This coalescence of various geographical (e.g. Floor 1, Floor 2, Floor 2) and logical building functions (Fire, Security, HVAC) is difficult process further complicated by the need to address network security issues. These devices are typically not customizable prior to delivery to the site. They are shrink-wrapped clones that differ only be their unique MAC address. In the commercial building sector, devices must come 'out of the box' with no security turned 'on'. This allows for tradesmen (electricians) to install the devices into a partially constructed building and verify operation without requiring sophisticated on-site device programming of network and link keys. We also cannot count on any IT devices (DHCP, L2 switches, L3 routers, AAA servers) being previously installed and operational. Once the system is totally constructed the need for network security is variable based on the building occupant(s). For example a single tenant owner occupied office building has little security threat and hence need little to no active security policy in place. A multi-tenant facility will require a higher layer of security to isolate the individual building occupants. A pharmaceutical or military facility will require a very high level of security. This security policy must be deployable from a central location since (as Robert Kavalar also points out in the urban market) many of these devices are now hidden under dry wall or above the ceiling grid. So in summary, for the commercial building sector, we need devices that can be installed with no security, ramped up to various levels of security once operational that must be downloaded with the security policy from a centralized source. This centralized source most often will not be available during the installation phase. Hope this helps. Jerry Martocci Tzeta Tsao Sent by: roll-bounces@ietf.org 04/06/2009 11:32 AM To JP Vasseur cc "Dearlove, Christopher \(UK\)" , ROLL WG Subject Re: [Roll] simple security (Re: security update?) >> >> I thought his possible (he says "I wonder") conclusion was a need for >> more security, not achieving more security. While I'm not sure it's >> the minimal configuration that's the only reason why, a scenario where >> devices are distributed without either human attendance or continual >> monitoring certainly raises some difficult security issues. > > This is exactly my point. This is not the 0-config requirement that > requires more security. > Of course 0-config with high security requirements is more challenging. > > Hi JP, All: It may be true that 0-config itself does not call for more security. It is the additional requirement of autonomous operation that deployed LLN devices will not have either human attendance or continual monitoring that prompts the question of whether these devices need more security. LLNs of smaller number of devices may or may not have a problem of getting human intervention when disasters occur; LLNs with tens of thousands of devices cannot rely on such procedures. The model of having an operator going up to a router to reconfigure is not widely applicable to LLNs. It is mission critical for certain types of LLNs to be secure out-of-the-box, even for their entire life-cycle, without reconfiguration. Would people, especially who work on smaller sized LLNs, offer some insight. Regards, Tzeta _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll --=_alternative 0066A8CD86257591_= Content-Type: text/html; charset="US-ASCII"
Agreed.  

My comments were based on our existing products.  I don't have a problem if out-of-the box security is turned on if it's with a well-known network key.  Maybe when a device is in 'ad hoc' mode (as would be done durng commissioning) it can run open, but in 'infrastructure' mode it must have at least a network key.

I have the same guys installing our systems as you do.  We somehow have to lower the system complexity during the commission phase so we don't need a degreed IT professional installing our temperature sensors!!!

Jerry







Kris Pister <pister@eecs.berkeley.edu>

04/07/2009 10:37 AM

To
Jerald.P.Martocci@jci.com
cc
Tzeta Tsao <tzeta.tsao@ekasystems.com>, "Dearlove, Christopher (UK)" <Chris.Dearlove@baesystems.com>, ROLL WG <roll@ietf.org>, roll-bounces@ietf.org
Subject
Re: [Roll] simple security (Re:  security update?)





Jerry - good input.  I have one correction and one opinion:
>> devices must come 'out of the box' with no security turned 'on'.

I completely agree with the need for 0-config on security.  We ship into an industry in which (customer quote) "the only tools the installer knows how to use are a sledge hammer and a blowtorch." :)
This does NOT mean that the networks must have no security.  There are simple security mechanisms that allow such networks to be built with 0-config, and still maintain many/most/all of the desired security properties.

>> office building has little security threat and hence need little to no active security policy in place

In my opinion, it won't take hackers very long to figure out that they can have a lot of fun taking over HVAC and lighting systems in office buildings.  It won't take very many such takeovers before 1) everyone demands more security, or 2) people abandon the technology altogether.

ksjp

Jerald.P.Martocci@jci.com wrote:


Tzeta,

Per your request, here are my comments on LLNs being installed in Commercial Buildings...

Most automation companies install sensors and controllers into a building.  These devices may be installed over a fairly wide time frame, yet must somehow be able to easily coalesce into a single LLN all operating under a single parameter set.  This coalescence of various geographical (e.g. Floor 1, Floor 2, Floor 2) and logical building functions (Fire, Security, HVAC) is difficult process further complicated by the need to address network security issues.  These devices are typically not customizable prior to delivery to the site.  They are shrink-wrapped clones that differ only be their unique MAC address.

In the commercial building sector, devices must come 'out of the box' with no security turned 'on'.  This allows for tradesmen (electricians) to install the devices into a partially constructed building and verify operation without requiring sophisticated on-site device programming of network and link keys.  We also cannot count on any IT devices (DHCP, L2 switches, L3 routers, AAA servers) being previously installed and operational.

Once the system is totally constructed the need for network security is variable based on the building occupant(s).  For example a single tenant owner occupied office building has little security threat and hence need little to no active security policy in place.  A multi-tenant facility will require a higher layer of security to isolate the individual building occupants.  A pharmaceutical or military facility will require a very high level of security.  This security policy must be deployable from a central location since (as Robert Kavalar also points out in the urban market) many of these devices are now hidden under dry wall or above the ceiling grid.

So in summary, for the commercial building sector, we need devices that can be installed with no security, ramped up to various levels of security once operational that must be downloaded with the security policy from a centralized source.  This centralized source most often will not be available during the installation phase.

Hope this helps.

Jerry Martocci




Tzeta Tsao <tzeta.tsao@ekasystems.com>
Sent by: roll-bounces@ietf.org

04/06/2009 11:32 AM


To
JP Vasseur <jvasseur@cisco.com>
cc
"Dearlove, Christopher \(UK\)" <Chris.Dearlove@baesystems.com>, ROLL WG <roll@ietf.org>
Subject
Re: [Roll] simple security (Re:  security update?)








>>
>> I thought his possible (he says "I wonder") conclusion was a need for
>> more security, not achieving more security. While I'm not sure it's
>> the minimal configuration that's the only reason why, a scenario where
>> devices are distributed without either human attendance or continual
>> monitoring certainly raises some difficult security issues.
>
> This is exactly my point. This is not the 0-config requirement that
> requires more security.
> Of course 0-config with high security requirements is more challenging.
>
>
Hi JP, All:

It may be true that 0-config itself does not call for more security.

It is the additional requirement of autonomous operation that deployed
LLN devices
will not have either human attendance or continual monitoring that
prompts the
question of whether these devices need more security.

LLNs of smaller number of devices may or may not have a problem of
getting human
intervention when disasters occur; LLNs with tens of thousands of
devices cannot
rely on such procedures. The model of having an operator going up to a
router to
reconfigure is not widely applicable to LLNs. It is mission critical for
certain types of
LLNs to be secure out-of-the-box, even for their entire life-cycle, without
reconfiguration.

Would people, especially who work on smaller sized LLNs, offer some insight.

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


_______________________________________________
Roll mailing list
Roll@ietf.org
https://www.ietf.org/mailman/listinfo/roll
 
--=_alternative 0066A8CD86257591_=-- --=_related 0066A8CD86257591_= Content-Transfer-Encoding: base64 Content-Type: image/jpeg Content-ID: <_2_0B37A9780B37A4280066A8CD86257591> /9j/4AAQSkZJRgABAQEASABIAAD/2wBDAAgGBgcGBQgHBwcJCQgKDBQNDAsLDBkSEw8UHRofHh0a HBwgJC4nICIsIxwcKDcpLDAxNDQ0Hyc5PTgyPC4zNDL/2wBDAQkJCQwLDBgNDRgyIRwhMjIyMjIy MjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjL/wAARCABZAn4DASIA AhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQA AAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3 ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWm p6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEA AwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSEx BhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElK U1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3 uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwD1TxT4 nvdEvo4LaK3dGiDkyKxOckdiPSsAfELVicfZrL/vh/8A4qvSqK66delGKUqd36nmV8HipzcoV3Fd rf8ABPOR4/1XH/HvZ/8AfDf/ABVH/Cfar/z72f8A3w3/AMVXo1FV9Yof8+/x/wCAZ/UcZ/0EP/wH /gnnP/Cfar/z72f/AHw3/wAVR/wn2q/8+9n/AN8N/wDFV6NRR9Yof8+/x/4AfUcX/wBBD/8AAf8A gnnP/Cfar/z72f8A3w3/AMVR/wAJ9qv/AD72f/fDf/FV6NRR9Yof8+/x/wCAH1HF/wDQQ/8AwH/g nnP/AAn2q/8APvZ/98N/8VR/wn+q/wDPvZ/98P8A/FV6NRR9Yof8+/x/4A/qOL/6CH93/BPOD4/1 X/n3sv8Avh//AIqg/EDVR/y72f8A3w//AMVXo9FL6xR/59/j/wAAf1HF/wDQQ/u/4J5v/wALB1X/ AJ97P/vh/wD4qk/4WFqn/PtZ/wDfD/8AxVek0UfWKP8Az7/H/gD+pYv/AJ//AIf8E82/4WHqn/Pt Z/8AfLf/ABVJ/wALE1T/AJ9rP/vhv/iq9Koo+sUf+ff4/wDAH9TxX/P/APD/AIJ5r/wsTVP+faz/ AO+G/wDiqT/hYup/8+1n/wB8t/8AFV6XRR9Yo/8APv8AH/gB9TxX/P8A/D/gnmf/AAsbVP8An1s/ ++W/+KpD8R9V/wCfay/74f8A+Kr02ij29H/n3+P/AAB/VMT/AM/vw/4J5gfiRq3/AD7WX/ft/wD4 qj/hZGrf8+1l/wB+3/8Aiq9Poo9vR/59/j/wA+qYr/n9+H/BPLz8SdW/59bL/vhv/iqP+Fk6t/z6 2X/fD/8AxVeoUUe3o/8APv8AH/gFfVcT/wA/vw/4J5d/wsrVv+fWy/74b/4qj/hZeq97Wy/74f8A +Kr1Gil7ej/z7/Ef1bEf8/fw/wCCeXf8LL1X/n1sv++H/wDiqT/hZmq/8+tl/wB8P/8AFV6lRR7e j/z7/Ef1bEf8/fw/4J5afiZqg/5dbL/vh/8A4qkPxO1Qf8ull/3w/wD8VXqdFHt6P/Pv8R/V6/8A z9/D/gnlf/Cz9UHW0s/++X/+KoPxQ1P/AJ9LP/vl/wD4qvVKKPb0f+ff4j+r1v8An5+B5V/wtLUw P+PSz/75f/4qk/4WnqX/AD52f/fL/wDxVerUUe3pf8+/xH7Ct/z8/A8o/wCFqap/z52f/fD/APxV N/4Wrqn/AD52f/fD/wDxVes0Ue3pf8+/xD2Fb/n5+B5N/wALW1P/AJ87P/vl/wD4qk/4WxqX/PnZ /wDfLf8AxVetUUvb0v8An3+P/AH7Gt/z8/A8k/4WzqX/AD5Wf/fLf/FUf8La1H/nytP++W/+Kr1u ij29H/n3+P8AwB+yq/z/AIHkf/C3L/8A587T/vlv/iqP+Fu3/wDz5Wn/AHy3/wAVXrlFP29H/n3+ P/AH7Kr/AD/geRf8Levv+fK1/wC+W/8AiqP+Fv33/Pla/wDfLf8AxVeu0Ue3o/8APv8AH/gD9nU/ n/A8h/4W/ff8+Vp/3y3/AMVSj4vX5OPsVp/3y3/xVeu0UvbUf+ff4/8AAD2dT+f8DyMfFy/LY+x2 n/fLf/FU7/hbOoE4Fnaf98t/8VXrVFHtqX8n4kujVf2/wPJz8VtR/wCfO0/75b/4qnf8LT1L/nzt P++W/wDiq9Wope1pfyfiQ6Fb/n5+H/BPLP8AhaGpYz9jtP8Avlv/AIqnD4namRn7Jaf98N/8VXqN FHtaX8n4k/Vq/wDz9/D/AIJ5ePiXqZGfslp/3w//AMVTh8SdUP8Ay6Wn/fD/APxVenUUva0/5PxF 9WxH/P38P+CeZD4kaof+XS0/74f/AOKp3/CxtUP/AC6Wn/fDf/FV6XRSdWn/ACfiL6rif+f34f8A BPNR8RdUP/Lraf8AfDf/ABVKPiJqf/Praf8AfDf/ABVek0UnOH8ofVcT/wA/vw/4J5v/AMLC1T/n 1tP++W/+Kpf+Fhap/wA+tp/3y3/xVej0VPNHsH1XEf8AP78P+Cecf8LB1T/n1tP++W/+Kpf+Fg6p /wA+tp/3y3/xVejUUuaPYf1XEf8AP78P+Cedf8J/qf8Az7Wn/fLf/FUf8J/qf/Ptaf8AfLf/ABVe i0VLa7B9VxH/AD9/D/gnnf8Awn2qf8+1p/3y3/xVH/Cfan/z7Wn/AHy3/wAVXolFS7lfVq//AD9/ A88Hj3U/+fa0/wC+G/8AiqP+E81P/n2tP++W/wDiq9DoqeV9x/V63/P38Dz3/hPNT/59rT/vlv8A 4qj/AITzU/8An2tP++W/+Kr0Kik4S7j9hW/5+fgefDx3qf8Az7Wn/fDf/FUf8J1qf/Pvaf8AfDf/ ABVeg0VHs5/zD9hV/wCfn4Hn3/Cdan/z72n/AHw3/wAVR/wnWp/8+9p/3w3/AMVXoNFS6NX+f8Bq jU/n/A8+/wCE61P/AJ97T/vhv/iqP+E61P8A597T/vlv/iq9BoqXQrf8/Pw/4JXsqn8559/wnep/ 8+9p/wB8t/8AFUf8J3qX/Pvaf98N/wDFV6DRU/Vq/wDz9/D/AII/Z1P5vwPPv+E71P8A597T/vlv /iq7HQ7+XU9HgvJlRZJN2QgIHDEd/pWhRWlGjVhK858y9CoRknq7hRRRXSaBRRRQAUUUUAFFFFAB RRRQAUUUUAFFZ0+tWkMgiD+ZI0D3CBejKnXn8aoWvi/T7i5sYnzCt5ZG8ikkYAbQQCv1GRVqlNq9 iPaw7nQUVFb3EV1Ak8Lbo3GVOCM1LUNWKTTV1sFFFFAwoqO4uILS3kuLmaOGCJS8kkjBVRR1JJ4A p4IIBByD0IoAWiignAyelABRVBNb0mXS31OPVLJ9PTO+6W4QxLg4OXzgYPvV2ORJoklidXjcBlZT kMD0IPcUAOooooAKKKq2Go2up27T2cvmxLLJCW2lcOjFGHIHRlI/CgC1RRRQAUUUUAFFFFABRRRQ AUVFFcwTyTRwzxyPC+yVUcExtgHDAdDgg4PYihbq3a7e0WeI3MaLI8Icb1UkgMR1AJBwfY+lAEtF FFABRRVXUNTsNJtTdalfW1nbghTLcyrGmT0GWIFAFqikVldFdGDKwyCDkEUtABRRUTXVul1HatPE txIrOkJcB2VcBiB1IGRk9sj1oAlooqIXMDXLWwmjNwiB2iDDcqkkAkdcEg8+xoAlooooAKKKKACi iigAooooAKKypPEemxav/Zkj3C3G9Y95tJRCHIBC+dt8vJBGBuzkgdeK0opVmTeocDJX50Kng46E A4469+o4o8w62H0UUwTRNO0AkQzIodoww3BSSASPQ4P5H0oAfRRRQAUVVfUbWPUotOaQ/apY2lVA hI2ggEk4wOvAJycHGcHDbXVbG9spLy3uFe2jLBpSCFwOSQT1XHII4IwQSKAsXKKzn1yxTRU1fdO1 m6qylLaRpDuIAHlhd+ckDGM0y48Qafa29rPObqOO55TdZzZQccyDbmMDIyX2gd6A6XNSiqr6jax6 nFpzSH7VLG0qoEJG0EAknGB14BOTg4zg4STUrSLUY9PeXFzJE0qptJG1SASWxgdeATzg4zg4LgW6 KxYvFmiyxPILqRQjqm2S3kRn3Z2sqsoLqQrHcoK4VjnCkizd65p9lqMNjcSyLPMVCkQuyKWOFDuA VQseBuIyeBmgDRooooAKKKKACiiigAooooAKKKKACiiigAoqnp+rWOqed9huUn8hzHJtz8relSX1 5Fp9hPeT7vKgjMj7Rk4AycCnyu9raiurXLFFU9K1O31nS7bUbTd5FwgdN4wce4q5Q007Mad9Qooo pAFFFFABXMa3r7W094sbAQWduWlb+9I3Cr+tdPXmusiLUNYOj28oMEcputSuO3HOD9BXVhIRlJ83 Q87MalSEIqHV/wDDL79X5JlY3zW+oW8bt81poEryexYZOf0rkm1GC2g8BXl6vnRRmeN4vVd+B/Sr d5qRm03xLr+NiXO2yth/sk9B7bVx+NYOqxbx4J0xsbinmkf7MkuR+gr1VD7/APgP/M46TvFpaq36 pL8j2mw1SU2w1rVJmt7dvltbSPuOgOO5rqI38yJH2ldyg7T1FcI0qXvjMpLj7JpqEqnbCj/Gup0D UZdU003UoALSsFA7AHivlaeJU6vJ62+W7/E9HCt2abv+r6v/ACNSiiius7Dm/H3mSeB9WtIbe5uL i8tpLaGO3geUs7qQM7Qdo/2jgDua51Idebx7ObrUdRtoYpALWCOyuZIZofIHBkV/IX5y/LJvyB82 CBXoF1cpaRLJIGIMiR/L6swUfqRUc2pWFvfQWM17bR3lwCYbd5VEkoHXapOTj2o1tb+v6/QDzrQ9 G1m8TwtBqV14hRLjSJpdRZry4jYXH7kIGYMChHzYUYzhs5y2dTwFdarqI1R9SmuXbTwuk/vHys0s JbzJgPVty89flx2rqR4i0Qi9I1jTyLE4uz9pT/R+SP3nPycg9cdKpW+uaTbaA2o6dag2z3UkUcdu I08+YzFCVJYJl3yQSwzuHc03dp/1vt+qBRsv67f8C55zpWga1Do9voh066XTrnT01KffEeJ44fL8 jBGVYuIZAOp2tWhq0uv21/4fis7bVITbwaeP3MF3IkoL4mVwjiGPYo58xWJDcYwK79PEukfa5LOe +htb2G2F1PbXEio8MfOWbnGBg5IJA4PQgnM1X4h+GdJjtJZNUtZ4bmOSVJYLmIrsT7xBLjdz8oC5 JPbg4Sdnf0/C/wCmnyG1zO9u/wCNn/wfmcnJol7c2+n6nqg1+WWHxFOZFW4usx23mTCMrEh+7ymG AztPXbTbpvFe68OmjWv7dDX/AJ5mEv2bycP9n8kN+5Lf6nGz5vvbu9d5/wAJGZINMltNJvbv7fEZ lWCW3PlINvzMxlCkfOPuFqurrWlNLdxLqdmZLNN9ygnXMC88uM/KODyfShXjo/P8kv01Fu0/63f+ f5HGnzPtuiiE+J/7F8ubbkXPnm53R+X5m795s/1v+t+T1+XbW/4O/tD+yLr+0vtXnf2jebPtO7d5 fnvsxu527cY7Yxjir9pr+l6golsb+1urXY7NcwXEbxrtIyCQ3X5h2wO5HGQ+IdEXTP7TOsaeNP37 PtRuU8rdnGN+cZzxjNNv+vn/AEvuEjSoqrLqenwXtvZS31tHd3ILQQPKoklA5JVc5bHtTre/s7yW eK2u4J5IG2TJFIGMbejAHg/WkMsUUUUAFFFFABRRRQB5jL9vku7+++za1Do15roe5+zQTxXLwLaK gYKgEwXzUUHaASB/dzWXBpviIyahqbw6wt5Fp1qbJ1aZXkC3M5RZAD+8YRMm5Xz1+YZr0uHXvMS/ lk0y9gtrRnVZ38plnKsVIQK5bqP4gvUVD/wkczWMk8egao88MpjntN1uskPyhtxLShCpBHKsevqD huX4W/KwpRvdf1vc4pbbxF5PnNca5DLcT6pBNJieURQh3MLLFkcjjaVwxGAp6U3zdWfR9I/tO18Q QWQtbsOuny3skr3IdRE7H/XqrL5hCycDIDdBXe3GuPDpdjeRaTf3Et4VCWkflLKpKF/m3yKowAc/ Mfxq7c3otNLmvpYJcRQmVoRtL8DJXrtz26496TTV0/6/r8xr89TzrS4fFa3SXepHVDexaraRsqyS eQYmtohOQgOxk37+cEKc4wc10fiAy2HjDRdXmtbu402G2uYX+y27ztDK5QqxjQFuVV13AHGcHGa1 3162WHT5BFM/20gKqhcx8cl8njBIU4zyR9al/tvTkezhnvLeC6vI/MgtpJ08yQYydoBO7H+zke9N vr5/pa36kpL8P1/r7jhLg6w3iGbyINahu/t8H2KNVmWzSx8tDIGC/ud3+t+98+7bjtWNPpWvXXha zjvY9enabS7O5vVeW4ZxPHPHuwM5V9m4lVAJIzgsAa9RtNf0/ULUT2NxFcgSJFIkU0ZaF2x8r/Nw RnkdfQGmP4o8PRPdpJrumI9n/wAfKtdxgwc7fn5+Xkgc96VrK39bf0/XUrrf+t7/APA9Dirm31kx +ILuCTXvs639rHAgkn3/AGIpAZjGh+YtjfyAXB3YwxOaEdlrFxrLTxDWYNPWy1KKxu54J5biGNvs +3cHIlLbhKVUkOVAx2r0sa5pLS2kQ1SyMl4oa1QXCZnGM5QZ+YY54qObW4IdWawMMreVEJbicMgj gU52lwWDYO1uQpHByRQ3bf8Ar+v1fcVtPx/H+vuXYxvB2qXH9mabp19YXkV7JFNI7SSTSAKj7Q7G c+au/OVVgSBkdqyvFdtq48R3txpsV8vmRaXGJrZX5UXb+aMjsEOW9AeeK6u18T6DeWNpewaxYtbX efs7mdV8wjqBk5yO46jvUh8Q6KNKXVTrGnjTmO1bs3KeSTnGA+cdeOtD3TfRlXsnHv8A1+hw9tFq 9trkVpenXzo8F1dJbNC88kjSbojDvflmjwZcGQmP+90FegWF79uilk+y3Nv5czxbbiPYW2sRuHqp xkHuKista0zUb68srO+gnurJglxEjgtGSARkemD16ZBHUGr9CfupPt9/mK1mwooooAKKKKACiiig DnrjTtWn1K7g8qyXTbi4inNx9oczDYI8r5ezHJT72/jOcdqePDqS3drPdJBI9sLgwsRuMbySBldQ RgMB36jJx1NB1yeDVNUguEjaGED7IEUhnYKhKkk4JLSLjGOvtmo7TxHMkdtHeWUs0nC3V1bKqwQs WKjIZ9/JHRQ2MjOKOi/roD3MTSvBeo6fo2pWkyWd0biaN/s80sYguQpyxkEdtHgv/ESJM4GSQOdK 28MLb6rJfroWiL52lJZtApwsZUt+7U+VzGwYAnAwEHyntZj8SSyRXiyWVxbtEs7RXLxq0UvluVOF 3h8jjrtB7HFakF7LJcTxmAusdz5O6PA2L5Ybc2T6nHGTyOOppq/9fcC0f9epdUYUDAGB0HQUtFFI Dnv+Ecuk8URasmtXrQbpHktXEOzLKAAD5e/HHduw96ji0rWdRtr2DUXj0vzLlbiGXTboTscY4YSw BQPlB6HPtjlB4vsZfGUWhw6lpuQJI5IDMPtBlUBgAu7IAGeoOecY28zS+If7K0i5u9ansbaSO48h WMnlxBiAVBdvTOC3GcZwOlTG2tv62/4A35/1v/wSIaDeweDE0h3/ALTuV25aa8a0zh9wxLDHuXGB jC545Peo7jT/ABCmk6fYwwWF5GA32tLrUJVJGQUQSGJ2kUDIJYAtgZ6kUsXiK5vfAsOsWFxa3Nyw QNLa2sl1HneFcrFGxdsDJ2hsjHWkvdb1GLSNNvrS8tpfMOJ92lzhZCOoJ3/6NjDAmTdg9emC42sr baCe135lgeHLpPE8WrJrN60G6R5LRxCUyygAA+Xvxx3bsPeo5/C1zJr/ANvXW7428gl822YQ7RvU KApEe/HH9/jAx3pB4vsZfGUWiQ6lppOJI5IDMPtBlUBgAu7gAZ6g55xgLzY/tLU/7ajObQ6bJcta CLymEwYIW3792CMqRt29Dnd2qOWMtP66f8Ad2v6/rzKMum+InsLlvsmlNePDHaqn22RYzGu4+YW8 okMS33MED+8at3Gnatc3a7obJLa58mW6IuXZ4XjIJWMbMOpwBklMcnB6VV1HXNZtdOGPskd2bwwM 0drJcrGuzcMRqyvJ2UsMd2KgA404NRvZp9Kf/QzaXcG52icuWcqW+UjjaMded27tj5tdXq/6/r+t CdE7Lp+mhsUUUUhhRRRQAUUUUAFFFFABRRRQAUUVn60mqyaa6aNLbw3pI2vcKWVR34FNK7sJux47 p2u6hpNjf2WlSrBd6nrzWwuGXIiHUn681tahf61oOqal4Z1HVH1W1utKlnilkTDxsFOc+3B/Suhs fhxZf8ItJpWq3D3NxPcG7kuY/kZZT3T0Apy+DNC0SG/vdU1S4lmu4DbPe3043JGRjCk8CvSlXpNu 2vy37O5zKnNI4zSJNe8OeHvCepxa7JNa3cscDWLxjYsbHoPf3q7c3vibUG8V6jD4jmtV0Wd1hgSI bHVQThvyxXXW3hvQtX8P6VYWeom4tNMkR4pIZVYkr03ECrkfg+wjttcgEs+3WWZrg7hlSwIO3jjr 3zUyxELtta+nS/8AkNU5Wt09fI4LWPEviCe30XUry9vNN0W4sUllu7GASBZj13+i1qS6nrHirxa+ haVrpsrKzso52u4VBe5ZgCD7DnpWxd/Du1u9Pg07+2NVisYrdLc28cwCSKvTcMdafefD7SLqa1ms Lq706e1gFsJbOXazRgY2tS9tRtp59Ng5J/0zix4x8R3mjWunf2iIL4asdOmvI4gd6dmA9fpXT+GL rWNO8c6h4c1DVX1K3jtVuIpZUw6knkVow/D7RrfT9Ns4DPGljc/ag4YFpZO5ckc5rS/sOytPEN14 jaWQTvbCKQEjYEXnOMZqalak04xW9+nW+g4wmmm2bNedeLbC+lvR4e0LTzCt+fOu7r+FhnkZ9BXd abqdnrFhHfWE4ntpM7JACAcHHejVLH+09MuLL7RLb+chTzYThlz6VhRqOlPX+v8AhgxFFVoW/r+m eI6xax61rmmeDtFYSWlkT50w6PIf9Y5PoBxWFfahFqfxPhltDmysJEjhI6eXFxn8cfrXoereE7/w h4TnsvC1hNf6jegpcXvAdE9AM/yqp4H+H2oaBAW1OxScalGEmVCN9sM5HJ79zXpuvD2bcX0aXd92 edUpThBpLV9unRf8E6BbZU8XThiBBqcDGJ+3zCuv0axOnaTBbNjeq5fH97vVXSdD+xWkVvdul0Le QtbsV5Qdq2a+bpYaMKjqddbejPQw0JRjeSs2FFFFdR0lHVrO4vtPaG1uIre4DxyRySxGVQVcNyoZ SRxjqKxbnwrdXutWOp3GpKXiEZuYo/tMccrI25SqLOEXn++snatnV557WxFzAwXypUaUMODHuAft 2Uk/UCsiw1W/uLn7PJOheSZrmMqgH+iFSU9ed2BnvSvbXt/X9enoG6t/X9f5+pAnhHUE1C/vTrKS TSur23nRTSrEQ+8bleYqR2xGIx37DGguhXMPh2bTYru1aaaWWSR7iz8yF/MdndWi3glfnIxu9OTz mH/hIbq2tTM1kZrW30+O6mnaXMrMwbCrGifMfl5Ix1GAelJpviK51G2tLieymsm+0SRzRNFKocLE zgr5scbkdOdo5BHPU01ZOPRApXfN1f8AX6jYPC93axSLBqio02ni0dhAw2srOytGRICijzGG3JIA XDAjJq2/giZNMktbjVPNlktLu2aXy5G/1+z5sySu52+X0LHOeoAxTrPxjfX2jX17BoM/mwFGijkj uY1kjbvlrcOWABJVEfqME540bHXbq5v7mCWyijijtlnhkSWRzOCATtzGFIBOOGJ6ZVcijmcZOXX+ mOMnGzj02/Ibr3h19XvdNuo/7LL2RYqL/T/tWCSh3J867GGzrz1qLU9AdNJuPsiebcCC6VEjUIzm Zw5wdy4OR/eXJ/iXqI7K9v7XSItRbU11S41BImhtpGjigR3I+46JuEeWxlt54GMnq658TahDaLJF pEMs0Uc0l0gvMKgiYK4jYp85OflyFBxyVoa+z6/8EIvVWK2haBez+Hmt9UjaCR4Z7dkmBkdlkYHc +6abJ4PHmNkY6fdFvW/CrapHM1tfNaXD3IuFdTMgB8tYyG8mWNm4X+8O3BxUNx4n1a3NzGdDgaa1 8ySYLffL5SLG2VJjyXIk+6QBlT82ME6NlrNzLcfZr2yjt5vtTW+I7jzFI8rzAwJVTnHBGODnkjkj u0LYzZPBmdT0y5ivmSC0jhSS3Mtztk8o5UgCcL1/56LITxmuhsLJLC2MCFSDLJISF28u7Of1b8ax LHxNdahNAy6dGlhORGtwt0GfeYRKCE24KY4zuzn+HHNKdev0tke3tIJ4obJJ7iW5umSTLISoVI4m 35IwSAvX5QTxQ20tfX7wtZqJ0lFcfpnirVtU1HT4f7Lt7eGaG5a5EksyyRmNkAKLJChOfMHDKvX0 A3XLDxBdyvbB7RGs3Cwm4a5BmMxjD8xhAu3HfIP+zjmk9FcHpY6SiuSPivVUt45ZNDhQOIZd32t3 WOGTd8zlImKsCvIwUAOS4GcdbTasD0dgooopAcvB4SZLzVLp5NNhlvVYK9jp3kMWLbg8xLt5rAgY Py9W9eLq6HdTabcW99fQyz3kqvdvDbFI5IxtBjCF2IBRdpJY9SfTGcurX4jvrFrs/bLieX7FLtTK Rh2VsDGDsCZyQc7lBzmrdnqd5KtsQ7SO821lfaA3+j78AheBu57nrzjgC017A3aXm2TeJtA/4SCw t7fGnN5M4l2ahZfaoW+VlwU3rz82Qc8Yq5JZXFxpVzZXE8OZojErQwFAgKAHgsc85PUcEDtk51l4 pivZY0W2aMShGjMj4yCm58jHGzofciodB8VTas4judO+yyGfyl5mAZfLZww82KNj90jhcehPNNdQ vsW08P7bm5lN1lJJ0khj8viFQdzKOedz7mJ9wO1Lb6Pe2d5C1vfW4tvs8cFxHJalnk2KQpRw42de QQ3tjJqnbeKRNqlvCIyUurOK6TOdiqQ5YK+3DuQBhepAJ4ANVLfxxNNot5ftot0jxNGIENvdATBz hetuHz/e2I4GRyc0ujX9dhNa3e5rweHo7dIFjkRRFDawjbEBkQsWHfoc9O3vXM2Hh/XrmfW4H8/T kuHzFcyySHpIWwnl3ZIUgnOwQduDyB2Wj6g+qaVBeSWstrJIDuiljdCpBIPDqrY4yCVUkYOBWGdb vrW6j+03EfkWUkqX/wAgyysxELZ4xwBkAclvaiTfNqUm9/T8NixYeFltLBIJbhJpQturS+UfmMUp kH3mZupOMsSOuSasX+i3N9rlnem6tlt7ZtyqbXNwp7hJt42o2BuUqcjIz0xFb3GrTaJqq72bUY02 wiNUBWQwowA3fL95j97j14qgJtVuPDDrBc+IF1G3nKShlsPtIOM4bjydmGU/L82PfIpttb+ore7b oy1D4Uxo8Gn3N4JPIsZLGOaKMxOIyV2nIbIICLkgjJ5G3pVE+B7k6Gtp/a7rfLcm4+1LLeYYlQmD /pXmH5R/z1x7VcgvL+S7ivLfUmvIvsnmT2yRIsKfuwylTt372bBwWxtJ4HBqkJtS8qWBvEl0xlhh uYZYYLcy733/ALqPKFSp2gjILAA5bHITe9/61f6oL8zu/wCtv8zb0PQ30SS5VLhHtphEVj2NuR0j WMnezsSpCLgHkHOWOeNisyS5uoF0hLh41mmlEdxs+6zeU5IGe24DFY15qt8JY7uO9f8As+3nm+0m 28pmVVkKjerDJjG1gShDggdecN3crbib93mf9f1Y6yiua03xC954pubI/avsxDpF5llJHGGjIB2y lAr7sseGOAn1rpaXS4+tgooooAKKKKAKU2kWNxcRzywBpY7gXKtuPEgTYG6/3eMdO/XmoH8O6ZJe xXZimEkXRVuZFR/mLDegba+CSRuBx2xXMXFu8HjDXLq3s4RqDQn7Lcf2FK8ufJQD/SvuFcgjZ1z3 rVt4NdtNRXzdVvby3juWiKSW0Q82Mw7wxKovIf5QRgY4IJ5o6J/MbRox+G9LjubicQSs86ujb7iR 1UOcuEUsQm48naBnAz0q79jhEvmKHVjL5x2yMAzbdvIBwRjseMgHGRmuO8MXetahhtUjupfLum8t 7q2IdFMLdC1vDjnAyFPXG45wOm0gNHbW0LtcK6WcIaF4sIpwRkNt+9xgjJxgcDOSxa3/AK9DTooo pARPbxSXEU7LmWIMEbJ4DYz/ACFU9L0Sz0drhrRrwmdg0n2i9muOR3HmO238MZwPQVjancagDrd5 pcM/mqkMAZoZEbKs+9kzE+/AYYKo4J7GptLk1m8t9LkuriaICGWSdUh5mIZQgYyRIVJXJICJk9MA V0/VWo890l/wL/8AAJUuj/roa02k2k2mDTv9IitxjH2e5khcYOeHRgw/Oq8vhvTZoLWBxdiG2ztj W9mVZMnJ8wB8S5PXfuzk56nOD4dutZvmV79buQxXRMZuYmQgGFxgkwQ8ZxztPX7x6Cfw9JdDVb2+ vH1KYSW1tCXubIxlZfMl3Iqqgyql1+bkYOSxAzVzwcqXMrq8bbethqVzqHtopLiKdkzLEGCNk8A4 z/IVUXRbFNWbU1jl+0t1/fuY84xuEe7YGwMbgM44zWPpmpXjardPPcahPBH55ljNjiKILJhBGwTd IxUHIBfkdFOBU9zBrM+qOYtTure2e4MISO3jISPyd28FlJ3bxjJyvONueah4Vxk02lpe+v8Al/SA cPB2kCORA+qZkkEpf+1rreGwRw3mblyDyAQDgZzgYsv4b017ixmVbqL7CqrbxwXk0UahegMauFb0 OQcjg8VzMWpeJ21GWHdeZGnk/PanyxN5QIYDyAM7s/L5zdSNo7aUsWrWGtXjLqGp3a/2YpgV4EaN 5VZ9xO1AA4BTAyu7PfHy6SwUoOzkr2ut/wDIHLc6qiuOt76/aa1SS/1z7C0v7u5OmYmmbK/JKnk/ u05b5ti9PvDGTcspbm41ofaJL6SSO5bdDPYhIYF2yBTFJ5Y3ZG3J3t1x8ucVMsJKKbb29f8AL/hv XQnn8jpaK8qaOPUPEbxCOObWymwfvLTzoGZMmTLt9oXY5PC4UKFCq3WuslurgG2QT3tvbtdXALWN kJd7CYgJJiNtqkZy2B7sO+tXAOHKlK7f9dLhzas6miuavLqe20WwgRtQstsUX2iSx08yvECpwFTy 2X7y4ICnaCOBkGnLd358ReUJ9QKggCBrPFuYtmfM83Z9/dxt3D/d71h9Vk1e/fv0+Q+bujo6K5W3 i8QqIZJdUupDi1meM2kYBLuRLHwuQoXkc7lPJYjiuqrOrS9m/iT9L/qkVcKKKKyAKKKKACvMpLK3 8VfF6/stYHnWml2qNbWrn5GZsZYjv1/lXptcr4i8FJrGqw6zYajPperQrsFxCM719GHet8PNRbu7 XW/YzqRbSsZviGeLwabHTfC2nWlvqGs3IjDFfkXH8RHfrVCXxl4i8P3ur6RrBs7m8t9Pa+tbiJCq uB1DDtWndeAr7VLFP7T8R3M+owTrPaXSRKv2dgMYA7g0kXw8ecardatq8l7ql/bG1FwYwqwoR0Va 6Izo2993773+/tYzanfRWMm08UeLbKfw7dalcWF1Z624jWOOMq0JYZBz3xmqngqXxFZt4lvDeWcl vbXMzTRsjZeQKSNp7LnFdfceC1ntPDcH25h/YsqSA7B+92gDB9OlVIPA9/Z6nqjWmuGPTdRd5JbV oAx3MpHDe2c/hT9rScWlZX8vP/IXJO6Zz/8Awmfiiz8J2/iC4nsrg6kVis7RIiojdmxlj3AAq7Nr /iPRtYTQvEclpdpqVlM8M9smwxuqElSO4/xrbfwFa3Hge28N3F1I32bDRXSLhlcHIbH49KgsvAdy +qHU9c1qXU7uO3a3ti0YRYgwILYHU4NHtKDvt16fdb9R8tTT+vU4fSvFGraH4Q8NWtrNFp9jcRSG TUJoDKivuOFIGcfX3r2LS5ZJ9LtZZbmG5kaNS00P3HOOo9q41vAOpxeGoNCs/EPlWawtDMj2ivvD EktyeDziur0DRoPD+h2ml27u8Vum0M/VvU1niZ05q8d7sdKMk7M0qKKK4zcKKKKACiiigBskaSxt HIivG4KsrDIYHqCKjW0tklEq28QkEflBwgyE67c+ntU1FAEQtbdUZBBEFZBGVCDBUdF+nJ496gsd J03S7dLfT9PtLSFGLpHbwrGqsRgkAAAEjvVyigDKPhnQDa3NqdD037PdOJLiL7JHslcHIZhjDHPc 1ZttK06yu5ru10+1guZwommihVXkAGAGYDJwOmauUUbAZi+HdDRL1F0bT1S+ObtRaoBcHJOZOPn5 JPOepq1Fp1jBbJbQ2dvHbxxmJIkiUKqHqoAGAvA46VZooAha0tnaRmt4maRSrkoDuBABB9RgD8hU V7pWnalbyW99YWt1BIwd454VdWYYwSCMEjA59qt0UAQR2drEipHbQoqHKhUAAO3bkfhx9OKrXWg6 PfSRSXek2FxJDGYommtkcohGCoJHAIJGBWhRQBn2+g6PZxW8VtpNjBHbO0kCRW6KImYEFlAHykgn JHrT00bS4r8X8em2aXoj8n7QsCiTZ/d3Yzt9ulXaKAKN1oulXvkfa9Ms7jyCrQ+bAr+WVztK5HGM nGOmavUUUAFFFFAEH2K181Zfs0PmIHCv5Yyoc5fB9yAT64pyWtvHt2QRLtO5dqAYONufy4+lS0UA VotPsoHV4rO3jZd+1kiUEb23Pjj+JuT6nk1SXwt4eSxlsU0HS1s5XEkluLOMRu46MVxgn3rWooAg FjaBUUWsAVNu0eWMLt+7j0x29Kqx+H9Fht7u3i0iwSC8Ja5iW2QLOT1LjGG/GtGijcCjbaRY2UsD 2ttFAlvC0EEUSBEjRiCwVQOMlV/KppbGzmWZZbWCQT4MoeMHzMdN3rjA61Yoo3AgnsrS5gnguLaG WG4BE0ckYZZBjHzA8HgAc+lUZPDOgS6bDpsmh6a9hC++K1a0jMSNzyqYwDyeQO5rVooAzl0DRl1b +1V0iwGpf8/Ytk877u37+M9OOvTioZPCvh2W0a1k0DS3tmmM7QtZxlDIRguRjG7HGeta9FAFObSd OuNMGmT6fay2AVUFq8KtEFXG0bCMYGBgY4xUb6Bo0gsg+k2DCwwbMNbIfs+MY8vj5Og6Y6CtCii+ twITa25EIMEREDbohsH7s4IyvocEjjsTU1FFABRRRQAUUUUAZcuv2cMojdZt/wBtWyYKmdrlQwJx 0Ugqc+471I2uabCI/tN5Ba+bcNbQi4kWMyyA7dqZPzHIPA5qC90IXl5cz/aNgmg8tUKbgknaTr1G F49utZmr+Dn1O2sI01F4nt4zFOd06LOrYL5EM0fJI/iLDk8Ul0v/AF/X6+QP+v6/rY2o9b06TVJN L+2QJfoTi2eVRI6gAllXOSvPXHY1chniuYEnglSWGRQySRsGVgehBHUVjjQ7ka4bsXsC2RuPtRgW 1/eNJ5YjGZN2CuB0256fNjg7EIlWBBO6PMFG9o0KKT3IBJwPbJ+tV0AkooopAYE3hzwjdXTyz6No ktxK7s7vaxM7uDlySRknuf1qNPDHgqTbs0Pw+2/O3baQnOOuOO3elv8Awt9sv7q5S88rzmRlHlbi hICS4O7+NFVeAMHJ5zRe+FRdXtzcR3YhEzIyqIsmM4CS4O7+ONVXgDByec1ssTXtbnf3v/PYXKhE 8MeCpNuzQ/D7b87dtpCc46447d6VvCnhFTBjw1orLO2EYWUGPuls8jngds/lk0XvhUXV7c3Ed2IR MyMqiLJjOAkuDu/jjVV4AwcnnNW722u59Rs4TFvtVleTzYwEESeUUCHLEsxZyQQoAA5wQMv61Xt8 b+9hyoxjp3w9NpPdRaX4bngt5RDcSQ29uywtkA7zjC4zk56CpH0j4ex21rcSad4YSC7IFvK0NuFm J6bDjDZ9qt2nhy4WNV1C9trgxGBYfJtPKURxOHUMC7ZbP8QwB2UVNJ4bhkinQvH+9huouYQcCd97 d/z9aaxNbrN/e/8AMFGPX+v+G/EzpdH+H0E13DNp3hiOWzQSXKPBbhoEPRnBHyjkcmh9I+Hsdta3 EmneGEguyBbytDbhZiemw4w2farNx4dv5b+8uodSgiEhje3i+zOyI6EHdIpl2seDygjPPJJAIkHh rzLWRLq4iluJra4hlkWDCkzEFiqliQuR93J9zSWKr9Zv73/X9fcKKvqik2kfD1HvVbTvDCtYgG7B htwbcHoZOPl/HFD6R8PYra2uZNP8MJBdkC3laG3CzE9Nhxhs+1WxoWpJZzWqalZiNJhPZbrEkxMH L/vP3mJBk9gh75zzTh4a8y1kS6uIpbia2uIZZFgwpMxBYqpYkLkfdyfc0LFV+s397/zBJPdGXb2f w2urWS6isvDBgiuDbPIbeBQsoONhyOvp6jBGQRU0WkeArmN3s9H8PXgjnW3k+zWsEnlyFgu1sDgj PI61oWvh0wgRzXKSwx3k91CBDtdPND7gW3HJBkbBAHGBjuWWPh+7hVftt/BM8fkpEYLUwgRxNuAY b2yx9Rgeiij61XuvfdvV/wBf15akktbIr2+geBLs3QttJ8OTG0YpcCO2gbyWHUPgfKeDwarjT/hu bS2uhaeFDbXUnlW8wjt9kr5xtU4wxz2FXo/D18LfUbd9Sg8m8kZhGts+2JSpACq8rAHO0nGFOD8g LE0t1ousXkUTS6pYC5MUlvcuuntseJiDhFMpKNgdSzA916YX1rEfzv73/X9dQ5V2K72HgHSL/wDe WnhqyvLYC4+aOCOSIKR8/YqAcc9uK6eORJoklidXjcBlZTkMD0IPcVlpoUCXSTgoSl39qGYwTnyf K6+uO/4Vd06zXT9NtbJSCtvEsQIXaCAMdO1TOpKes5N+o7LoWaKKKzAKKKKACiiigAooooAKKKKA CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKAP//Z --=_related 0066A8CD86257591_=-- From pister@eecs.berkeley.edu Tue Apr 7 12:40: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 C1F973A6A28 for ; Tue, 7 Apr 2009 12:40:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.474 X-Spam-Level: X-Spam-Status: No, score=-6.474 tagged_above=-999 required=5 tests=[AWL=0.124, 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 FhcKXMsNspS5 for ; Tue, 7 Apr 2009 12:40:46 -0700 (PDT) Received: from gateway0.EECS.Berkeley.EDU (gateway0.EECS.Berkeley.EDU [169.229.60.87]) by core3.amsl.com (Postfix) with ESMTP id C9ED63A6843 for ; Tue, 7 Apr 2009 12:40:46 -0700 (PDT) Received: from [127.0.0.1] (dhcp-32-46.EECS.Berkeley.EDU [128.32.32.46]) (authenticated bits=0) by gateway0.EECS.Berkeley.EDU (8.14.3/8.13.5) with ESMTP id n37JfoTw001292 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 7 Apr 2009 12:41:51 -0700 (PDT) Message-ID: <49DBAC78.7090603@eecs.berkeley.edu> Date: Tue, 07 Apr 2009 12:41:44 -0700 From: Kris Pister User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: "Dearlove, Christopher (UK)" References: <49CB86DA.9050104@eecs.berkeley.edu> <49D218CC.6040304@ekasystems.com> <49D4FE48.3010104@eecs.berkeley.edu> <49D53180.5030509@ekasystems.com> <8CF80793-154E-4DC3-A7A2-F3B8CF471DDD@cisco.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------040806080004040103090808" Cc: ROLL WG Subject: Re: [Roll] simple security (Re: security update?) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 07 Apr 2009 19:40:47 -0000 This is a multi-part message in MIME format. --------------040806080004040103090808 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit I can throw out a couple of ideas on how one might implement 0-config security. My goal for the draft is to provide enough flexibility that people can implement the things that they want, without placing any burden on those who don't want. The details of security policy are out of scope - we're not trying to prescribe anything - but the underlying mechanisms are in scope. With that in mind, here are some examples of things that people might want to do. * Association by physical contact. Eaton has a nice solution on their Home Heartbeat system. When you buy an off-the-shelf, 0-config, shrink-wrapped, 3rd party sensor for your home automation system, you just slide the new device across the surface of the "gateway", and security information is exchanged. Done right, this provides essentially everything that you could want: IDs can be registered in access control lists, unique keys can be generated and installed in both devices, etc. The "gateway" can be in a physically secure location. * Association by RF proximity to the gateway. As above, but without physical contact. 1-hop to a very low power transceiver (or near-field transceiver) in a physically secure location. * Association by push-button. Along the lines of cell-phone pairing with bluetooth ear-phone, having a button on one or more devices provides a mechanism to limit any open-air exchanges to a brief (seconds to minutes) period of time. * Association by pre-installed certificates. This requires PK, which requires roughly 10kB/1kB program/data, and roughly one second of processing time. Prohibitively expensive for many applications, perfectly acceptable for others. * Association by physical plug-in. Like a cell-phone SIM card. All of these mechanisms get used in different applications today. Some of them will get used in LLNs. We don't need to define much in RoLL to allow people to build higher-layer stuff like this on top of our protocol. ksjp Dearlove, Christopher (UK) wrote: > JPV > >> Of course 0-config with high security requirements is more >> > challenging. > > Which means that in at least some ROLL scenarios you have > - High security requirements. > - Serious threats (e.g. due to unattended devices). > - Zero or limited pre-configuration. > - A desire/need for decentralisation. > > I think challenging is a good word. > > (I could have added a fifth point of limited resources to use > on the problem.) > > ******************************************************************** > This email and any attachments are confidential to the intended > recipient and may also be privileged. If you are not the intended > recipient please delete it from your system and notify the sender. > You should not copy it or use it for any purpose nor disclose or > distribute its contents to any other person. > ******************************************************************** > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > --------------040806080004040103090808 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit I can throw out a couple of ideas on how one might implement 0-config security.
My goal for the draft is to provide enough flexibility that people can implement the things that they want, without placing any burden on those who don't want.
The details of security policy are out of scope - we're not trying to prescribe anything - but the underlying mechanisms are in scope.

With that in mind, here are some examples of things that people might want to do.
* Association by physical contact.  Eaton has a nice solution on their Home Heartbeat system.  When you buy an off-the-shelf, 0-config, shrink-wrapped, 3rd party sensor for your home automation system, you just slide the new device across the surface of the "gateway", and security information is exchanged.  Done right, this provides essentially everything that you could want: IDs can be registered in access control lists, unique keys can be generated and installed in both devices, etc.  The "gateway" can be in a physically secure location.

* Association by RF proximity to the gateway.  As above, but without physical contact.  1-hop to a very low power transceiver (or near-field transceiver) in a physically secure location.

* Association by push-button.  Along the lines of cell-phone pairing with bluetooth ear-phone, having a button on one or more devices provides a mechanism to limit any open-air exchanges to a brief (seconds to minutes) period of time.

* Association by pre-installed certificates.  This requires PK, which requires roughly 10kB/1kB program/data, and roughly one second of processing time.  Prohibitively expensive for many applications, perfectly acceptable for others.

* Association by physical plug-in.  Like a cell-phone SIM card.

All of these mechanisms get used in different applications today.  Some of them will get used in LLNs.  We don't need to define much in RoLL to allow people to build higher-layer stuff like this on top of our protocol.

ksjp

Dearlove, Christopher (UK) wrote: 
JPV
  
Of course 0-config with high security requirements is more
    
challenging.

Which means that in at least some ROLL scenarios you have
- High security requirements.
- Serious threats (e.g. due to unattended devices).
- Zero or limited pre-configuration.
- A desire/need for decentralisation.

I think challenging is a good word.

(I could have added a fifth point of limited resources to use
on the problem.)

********************************************************************
This email and any attachments are confidential to the intended
recipient and may also be privileged. If you are not the intended
recipient please delete it from your system and notify the sender.
You should not copy it or use it for any purpose nor disclose or
distribute its contents to any other person.
********************************************************************

_______________________________________________
Roll mailing list
Roll@ietf.org
https://www.ietf.org/mailman/listinfo/roll
--------------040806080004040103090808-- From jhui@archrock.com Tue Apr 7 13:08: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 6BDDB3A6DE9 for ; Tue, 7 Apr 2009 13:08:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9HipqAtUzLz3 for ; Tue, 7 Apr 2009 13:08:11 -0700 (PDT) Received: from mail.sf.archrock.com (mail.sf.archrock.com [216.121.16.71]) by core3.amsl.com (Postfix) with ESMTP id 7FA703A6A5E for ; Tue, 7 Apr 2009 13:08:11 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.sf.archrock.com (Postfix) with ESMTP id 59DF7AF8B6; Tue, 7 Apr 2009 13:09:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at Received: from mail.sf.archrock.com ([127.0.0.1]) by localhost (mail.sf.archrock.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WVHmBQtZr50K; Tue, 7 Apr 2009 13:09:14 -0700 (PDT) Received: from [10.0.1.200] (adsl-71-142-74-235.dsl.pltn13.pacbell.net [71.142.74.235]) by mail.sf.archrock.com (Postfix) with ESMTP id 13E51AF881; Tue, 7 Apr 2009 13:09:14 -0700 (PDT) Message-Id: From: Jonathan Hui To: Kris Pister In-Reply-To: <49DBAC78.7090603@eecs.berkeley.edu> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Tue, 7 Apr 2009 13:09:13 -0700 References: <49CB86DA.9050104@eecs.berkeley.edu> <49D218CC.6040304@ekasystems.com> <49D4FE48.3010104@eecs.berkeley.edu> <49D53180.5030509@ekasystems.com> <8CF80793-154E-4DC3-A7A2-F3B8CF471DDD@cisco.com> <49DBAC78.7090603@eecs.berkeley.edu> X-Mailer: Apple Mail (2.930.3) Cc: ROLL WG Subject: Re: [Roll] simple security (Re: security update?) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 07 Apr 2009 20:08:12 -0000 Completely agree with Kris and all of the mechanisms he mentioned work and have been used for years. Though I do think that naming the goal "0-config" is a non-starter. The association process needs to have a human in the loop. Even for the simple case where no security is required, nodes still need to know what network to join. Maybe its better to say something along the lines of "1-step binary human interface config." In some workflows it is possible to separate the person that physically installs the device from the one that associates the device. This is the only case where "0-config" makes any sense to me and it only makes sense from the view of the physical installer. -- Jonathan Hui On Apr 7, 2009, at 12:41 PM, Kris Pister wrote: > I can throw out a couple of ideas on how one might implement 0- > config security. > My goal for the draft is to provide enough flexibility that people > can implement the things that they want, without placing any burden > on those who don't want. > The details of security policy are out of scope - we're not trying > to prescribe anything - but the underlying mechanisms are in scope. > > With that in mind, here are some examples of things that people > might want to do. > * Association by physical contact. Eaton has a nice solution on > their Home Heartbeat system. When you buy an off-the-shelf, 0- > config, shrink-wrapped, 3rd party sensor for your home automation > system, you just slide the new device across the surface of the > "gateway", and security information is exchanged. Done right, this > provides essentially everything that you could want: IDs can be > registered in access control lists, unique keys can be generated and > installed in both devices, etc. The "gateway" can be in a > physically secure location. > > * Association by RF proximity to the gateway. As above, but without > physical contact. 1-hop to a very low power transceiver (or near- > field transceiver) in a physically secure location. > > * Association by push-button. Along the lines of cell-phone pairing > with bluetooth ear-phone, having a button on one or more devices > provides a mechanism to limit any open-air exchanges to a brief > (seconds to minutes) period of time. > > * Association by pre-installed certificates. This requires PK, > which requires roughly 10kB/1kB program/data, and roughly one second > of processing time. Prohibitively expensive for many applications, > perfectly acceptable for others. > > * Association by physical plug-in. Like a cell-phone SIM card. > > All of these mechanisms get used in different applications today. > Some of them will get used in LLNs. We don't need to define much in > RoLL to allow people to build higher-layer stuff like this on top of > our protocol. > > ksjp > > Dearlove, Christopher (UK) wrote: >> >> JPV >> >>> Of course 0-config with high security requirements is more >>> >> challenging. >> >> Which means that in at least some ROLL scenarios you have >> - High security requirements. >> - Serious threats (e.g. due to unattended devices). >> - Zero or limited pre-configuration. >> - A desire/need for decentralisation. >> >> I think challenging is a good word. >> >> (I could have added a fifth point of limited resources to use >> on the problem.) >> >> ******************************************************************** >> This email and any attachments are confidential to the intended >> recipient and may also be privileged. If you are not the intended >> recipient please delete it from your system and notify the sender. >> You should not copy it or use it for any purpose nor disclose or >> distribute its contents to any other person. >> ******************************************************************** >> >> _______________________________________________ >> Roll mailing 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 kavaler@dslextreme.com Tue Apr 7 14: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 7A0CE28C118 for ; Tue, 7 Apr 2009 14:03:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.976 X-Spam-Level: X-Spam-Status: No, score=-1.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PPKKrUY1acLj for ; Tue, 7 Apr 2009 14:03:03 -0700 (PDT) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.238]) by core3.amsl.com (Postfix) with ESMTP id 8F3DC3A6DCD for ; Tue, 7 Apr 2009 14:02:14 -0700 (PDT) Received: by rv-out-0506.google.com with SMTP id k40so2467226rvb.49 for ; Tue, 07 Apr 2009 14:03:21 -0700 (PDT) MIME-Version: 1.0 Sender: kavaler@dslextreme.com Received: by 10.142.154.9 with SMTP id b9mr136948wfe.327.1239138201268; Tue, 07 Apr 2009 14:03:21 -0700 (PDT) In-Reply-To: <49DBAC78.7090603@eecs.berkeley.edu> References: <49CB86DA.9050104@eecs.berkeley.edu> <49D218CC.6040304@ekasystems.com> <49D4FE48.3010104@eecs.berkeley.edu> <49D53180.5030509@ekasystems.com> <8CF80793-154E-4DC3-A7A2-F3B8CF471DDD@cisco.com> <49DBAC78.7090603@eecs.berkeley.edu> Date: Tue, 7 Apr 2009 14:03:21 -0700 X-Google-Sender-Auth: 78bb593b0070ede4 Message-ID: <4b3cccaa0904071403q5396ac43t2b5a65814eef703e@mail.gmail.com> From: Robert Kavaler To: Kris Pister Content-Type: multipart/alternative; boundary=000e0cd331de5072b80466fd58f4 Cc: ROLL WG Subject: Re: [Roll] simple security (Re: security update?) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 07 Apr 2009 21:03:05 -0000 --000e0cd331de5072b80466fd58f4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit For our application, we have have found that there is a flip side to security. Security suggests that it is difficult, if not impossible, to put a system into a state that the operator/designer does not wish that system to be in. Said another way, you don't want to let someone hijack your system. This is especially true if we are talking about security with routing protocols. One thing that we found works against most security schemes (for our system) is recoverability. That is, if something has taken over your system either intentionally, or if the system has been driven into a bad state because of programming error or temporary hardware malfunction, we want to be able to recover that system back to a working state without having to dig up (literally) our sensors. For some small number of applications this is not an issue, but for the vast majority of our customers this is a big issue. The fact that we can recover "lost" sensors after an untrained technician attempts to install our product, or that we can download new code to a dysfunctional system to fix it has been a big advantage for us. My feeling is that it is impossible to guard against all possible sources of sensor corruption, so we have opted, in general, to make our system easily visible and recoverable instead of making it "secure". Let me give you one example of a difficulty associated with strict security. Our secure system uses a NONCE that contains a counter to prevent a playback attack. Both the transmitter of the packet and the receiver of the packet must store the counter in nonvolatile memory. If that state is corrupted then you may not be able to recover the sensor without further corrupting the state, potentially to the point where the counter saturates and bricks the sensor. Thus the desire for strict security has made the device unrecoverable. These issues can be resolved by layering security features, but I'm suggesting that recoverability is a nice feature that might trump traditional security. Robert Kavaler www.sensysnetworks.com On Tue, Apr 7, 2009 at 12:41 PM, Kris Pister wrote: > I can throw out a couple of ideas on how one might implement 0-config > security. > My goal for the draft is to provide enough flexibility that people can > implement the things that they want, without placing any burden on those who > don't want. > The details of security policy are out of scope - we're not trying to > prescribe anything - but the underlying mechanisms are in scope. > > With that in mind, here are some examples of things that people might want > to do. > * Association by physical contact. Eaton has a nice solution on their Home > Heartbeat system. When you buy an off-the-shelf, 0-config, shrink-wrapped, > 3rd party sensor for your home automation system, you just slide the new > device across the surface of the "gateway", and security information is > exchanged. Done right, this provides essentially everything that you could > want: IDs can be registered in access control lists, unique keys can be > generated and installed in both devices, etc. The "gateway" can be in a > physically secure location. > > * Association by RF proximity to the gateway. As above, but without > physical contact. 1-hop to a very low power transceiver (or near-field > transceiver) in a physically secure location. > > * Association by push-button. Along the lines of cell-phone pairing with > bluetooth ear-phone, having a button on one or more devices provides a > mechanism to limit any open-air exchanges to a brief (seconds to minutes) > period of time. > > * Association by pre-installed certificates. This requires PK, which > requires roughly 10kB/1kB program/data, and roughly one second of processing > time. Prohibitively expensive for many applications, perfectly acceptable > for others. > > * Association by physical plug-in. Like a cell-phone SIM card. > > All of these mechanisms get used in different applications today. Some of > them will get used in LLNs. We don't need to define much in RoLL to allow > people to build higher-layer stuff like this on top of our protocol. > > ksjp > > > Dearlove, Christopher (UK) wrote: > > JPV > > > Of course 0-config with high security requirements is more > > > challenging. > > Which means that in at least some ROLL scenarios you have > - High security requirements. > - Serious threats (e.g. due to unattended devices). > - Zero or limited pre-configuration. > - A desire/need for decentralisation. > > I think challenging is a good word. > > (I could have added a fifth point of limited resources to use > on the problem.) > > ******************************************************************** > This email and any attachments are confidential to the intended > recipient and may also be privileged. If you are not the intended > recipient please delete it from your system and notify the sender. > You should not copy it or use it for any purpose nor disclose or > distribute its contents to any other person. > ******************************************************************** > > _______________________________________________ > Roll mailing listRoll@ietf.orghttps://www.ietf.org/mailman/listinfo/roll > > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > > --000e0cd331de5072b80466fd58f4 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable For our application, we have have found that there is a flip side to securi= ty. Security suggests that it is difficult, if not impossible, to put a sys= tem into a state that the operator/designer does not wish that system to be= in. Said another way, you don't want to let someone hijack your system= . This is especially true if we are talking about security with routing pro= tocols.

One thing that we found works against most security schemes (for our sy= stem) is recoverability. That is, if something has taken over your system e= ither intentionally, or if the system has been driven into a bad state beca= use of programming error or temporary hardware malfunction, we want to be a= ble to recover that system back to a working state without having to dig up= (literally) our sensors. For some small number of applications this is not= an issue, but for the vast majority of our customers this is a big issue. = The fact that we can recover "lost" sensors after an untrained te= chnician attempts to install our product, or that we can download new code = to a dysfunctional system to fix it has been a big advantage for us.

My feeling is that it is impossible to guard against all possible sourc= es of sensor corruption, so we have opted, in general, to make our system e= asily visible and recoverable instead of making it "secure".

Let me give you one example of a difficulty associated with strict secu= rity.=A0 Our secure system uses a NONCE that contains a counter to prevent = a playback attack.=A0 Both the transmitter of the packet and the receiver o= f the packet must store the counter in nonvolatile memory. If that state is= corrupted then you may not be able to recover the sensor without further c= orrupting the state, potentially to the point where the counter saturates a= nd bricks the sensor. Thus the desire for strict security has made the devi= ce unrecoverable.

These issues can be resolved by layering security features, but I'm= suggesting that recoverability is a nice feature that might trump traditio= nal security.

Robert Kavaler
www.sensysnetworks.com


On Tue, Apr 7, 2009 at 12:41 PM, Kris Pi= ster <pist= er@eecs.berkeley.edu> wrote:
=20
I can throw out a couple of ideas on how one might implement 0-config security.
My goal for the draft is to provide enough flexibility that people can implement the things that they want, without placing any burden on those who don't want.
The details of security policy are out of scope - we're not trying to prescribe anything - but the underlying mechanisms are in scope.

With that in mind, here are some examples of things that people might want to do.
* Association by physical contact.=A0 Eaton has a nice solution on their Home Heartbeat system.=A0 When you buy an off-the-shelf, 0-config, shrink-wrapped, 3rd party sensor for your home automation system, you just slide the new device across the surface of the "gateway", an= d security information is exchanged.=A0 Done right, this provides essentially everything that you could want: IDs can be registered in access control lists, unique keys can be generated and installed in both devices, etc.=A0 The "gateway" can be in a physically secure location.

* Association by RF proximity to the gateway.=A0 As above, but without physical contact.=A0 1-hop to a very low power transceiver (or near-field transceiver) in a physically secure location.

* Association by push-button.=A0 Along the lines of cell-phone pairing with bluetooth ear-phone, having a button on one or more devices provides a mechanism to limit any open-air exchanges to a brief (seconds to minutes) period of time.

* Association by pre-installed certificates.=A0 This requires PK, which requires roughly 10kB/1kB program/data, and roughly one second of processing time.=A0 Prohibitively expensive for many applications, perfectly acceptable for others.

* Association by physical plug-in.=A0 Like a cell-phone SIM card.

All of these mechanisms get used in different applications today.=A0 Some of them will get used in LLNs.=A0 We don't need to define much in RoLL = to allow people to build higher-layer stuff like this on top of our protocol.

ksjp


Dearlove, Christopher (UK) wrote: 
JPV
  
Of course 0-config with high security requirements is more
    
challenging.

Which means that in at least some ROLL scenarios you have
- High security requirements.
- Serious threats (e.g. due to unattended devices).
- Zero or limited pre-configuration.
- A desire/need for decentralisation.

I think challenging is a good word.

(I could have added a fifth point of limited resources to use
on the problem.)

********************************************************************
This email and any attachments are confidential to the intended
recipient and may also be privileged. If you are not the intended
recipient please delete it from your system and notify the sender.
You should not copy it or use it for any purpose nor disclose or
distribute its contents to any other person.
********************************************************************

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

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


--000e0cd331de5072b80466fd58f4-- From richard.kelsey@ember.com Tue Apr 7 16:36: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 3A69F3A6863 for ; Tue, 7 Apr 2009 16:36:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 486EuZZDOrUU for ; Tue, 7 Apr 2009 16:36:57 -0700 (PDT) Received: from EMPIRE.hq.ember.com (mail.ember.com [74.10.175.227]) by core3.amsl.com (Postfix) with ESMTP id 732263A6821 for ; Tue, 7 Apr 2009 16:36:57 -0700 (PDT) Received: from kelsey-ws.hq.ember.com ([192.168.81.55]) by EMPIRE.hq.ember.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 7 Apr 2009 19:38:46 -0400 Received: from kelsey-ws.hq.ember.com (localhost.localdomain [127.0.0.1]) by kelsey-ws.hq.ember.com (8.13.4/8.13.4) with ESMTP id n37Nc2ep020767; Tue, 7 Apr 2009 19:38:02 -0400 Received: (from kelsey@localhost) by kelsey-ws.hq.ember.com (8.13.4/8.12.8/Submit) id n37Nc2v3020764; Tue, 7 Apr 2009 19:38:02 -0400 Date: Tue, 7 Apr 2009 19:38:02 -0400 Message-Id: <200904072338.n37Nc2v3020764@kelsey-ws.hq.ember.com> To: pister@eecs.berkeley.edu In-reply-to: <49DBAC78.7090603@eecs.berkeley.edu> (message from Kris Pister on Tue, 07 Apr 2009 12:41:44 -0700) From: Richard Kelsey References: <49CB86DA.9050104@eecs.berkeley.edu> <49D218CC.6040304@ekasystems.com> <49D4FE48.3010104@eecs.berkeley.edu> <49D53180.5030509@ekasystems.com> <8CF80793-154E-4DC3-A7A2-F3B8CF471DDD@cisco.com> <49DBAC78.7090603@eecs.berkeley.edu> X-OriginalArrivalTime: 07 Apr 2009 23:38:46.0350 (UTC) FILETIME=[FE916EE0:01C9B7D9] Cc: roll@ietf.org Subject: Re: [Roll] simple security (Re: security update?) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 07 Apr 2009 23:36:58 -0000 Date: Tue, 07 Apr 2009 12:41:44 -0700 From: Kris Pister * Association by physical contact. Eaton has a nice solution on their Home Heartbeat system. When you buy an off-the-shelf, 0-config, shrink-wrapped, 3rd party sensor for your home automation system, you just slide the new device across the surface of the "gateway", and security information is exchanged. I believe they do this by having a reed switch and a magnet in the devices. It's association by push button and RF proximity, with a different kind of button. -Richard Kelsey From pal@cs.stanford.edu Wed Apr 8 14:10: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 D49633A6EB4 for ; Wed, 8 Apr 2009 14:10:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8nIcz5QEoSkv for ; Wed, 8 Apr 2009 14:10:27 -0700 (PDT) Received: from cs-smtp-3.Stanford.EDU (cs-smtp-3.Stanford.EDU [171.64.64.27]) by core3.amsl.com (Postfix) with ESMTP id 2E2103A6EB2 for ; Wed, 8 Apr 2009 14:10:27 -0700 (PDT) Received: from dnab422193.stanford.edu ([171.66.33.147]) by cs-smtp-3.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1Lrf3W-0003H7-JY; Wed, 08 Apr 2009 14:11:34 -0700 Message-Id: <257B9AAC-B5A5-4141-86B6-0E04C5DA3DA9@cs.stanford.edu> From: Philip Levis To: JP Vasseur In-Reply-To: <0BD8BD8B-FD05-46E9-9AD4-7E9F312AAD21@cisco.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Wed, 8 Apr 2009 14:11:33 -0700 References: <0BD8BD8B-FD05-46E9-9AD4-7E9F312AAD21@cisco.com> X-Mailer: Apple Mail (2.930.3) X-Scan-Signature: a11a15d02c0ec4233875b3872b0caebb Cc: ROLL WG Subject: Re: [Roll] Formation of a Routing Protocol Design Team for ROLL X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Apr 2009 21:10:27 -0000 On Apr 1, 2009, at 12:57 AM, JP Vasseur wrote: > Dear WG, > > We have formed a new Design Team in the ROLL Working Group. Please > find below the charter and team members. > > Since some of you may not be familiar with the concept of a Design > Team, I would like to remind a few points: > > * The work produced by a Design Team has no special status in the WG > and is subject to WG consensus as any other individual submission > * We ask the Design Team to request for input from the WG and to > provide regular updates on the progress: please send input requests > to the mailing list, post regular updates of the document to get a > chance to everybody to comment, ... > * All: please provide input to the Design Team and copy the mailing > list. JP, How does one join the design team? I would like to join. Phil From teco@inf-net.nl Thu Apr 9 00:58: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 91FE23A6EA9 for ; Thu, 9 Apr 2009 00:58:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.15 X-Spam-Level: X-Spam-Status: No, score=-1.15 tagged_above=-999 required=5 tests=[AWL=0.354, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XD-GyBjrREdO for ; Thu, 9 Apr 2009 00:58:23 -0700 (PDT) Received: from server9.hosting2go.nl (server9.hosting2go.nl [83.137.194.84]) by core3.amsl.com (Postfix) with ESMTP id 54E353A6A05 for ; Thu, 9 Apr 2009 00:58:22 -0700 (PDT) Received: (qmail 5623 invoked from network); 9 Apr 2009 09:59:27 +0200 Received: from static.kpn.net (HELO M90Teco) (77.61.241.196) by server9.hosting2go.nl with SMTP; 9 Apr 2009 09:59:27 +0200 From: "Teco Boot" To: References: <7892795E1A87F04CADFCCF41FADD00FC07365A53@xmb-ams-337.emea.cisco.com> <200904021954.n32JsfUu016043@kelsey-ws.hq.ember.com> <7892795E1A87F04CADFCCF41FADD00FC073C3E79@xmb-ams-337.emea.cisco.com> <7892795E1A87F04CADFCCF41FADD00FC073C4145@xmb-ams-337.emea.cisco.com> <7892795E1A87F04CADFCCF41FADD00FC073C432D@xmb-ams-337.emea.cisco.com> <200904061817.n36IHPhc005447@kelsey-ws.hq.ember.com> <7892795E1A87F04CADFCCF41FADD00FC07427042@xmb-ams-337.emea.cisco.com> <200904071617.n37GHRGU016887@kelsey-ws.hq.ember.com> In-Reply-To: <200904071617.n37GHRGU016887@kelsey-ws.hq.ember.com> Date: Thu, 9 Apr 2009 09:58:56 +0200 Message-ID: <000001c9b8e9$1bb6def0$53249cd0$@nl> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acm3nIKPdEd1D/bgT8y8BTIRpRSBcwBPy3qw Content-Language: nl Cc: roll@ietf.org Subject: Re: [Roll] FW: New Version Notification fordraft-thubert-roll-fundamentals-00 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2009 07:58:24 -0000 Hi Pascal, For multiple trees (DAGs) and efficient routing without default routes / MTR / flow labels, you could check Border Router Discovery Protocol and related BRDP based routing: http://tools.ietf.org/html/draft-boot-autoconf-brdp http://tools.ietf.org/html/draft-boot-brdp-based-routing BRDP provides DAGs to attachment points, called Border Router. There is no TIO (no Tree) but BRIO (Border Router). The sub-DAG tree identifier is the Border Router address. Nodes can use source addresses based on advertized BR prefixes. This enables using these addresses as locators. BRDP / BRDP based routing use a routing protocol for reachability to the backbone: next-hop to the Border Router. BRDP has its history in MANET / Autoconf. It is easy to add paths to the backbone, learned from BRDP (path to BR) or towards nodes (explicit messages, routing header and / or snooping). Routing to the backbone uses the source addresses, when destination is not in routing table. The requirement is that nexthop towards BR is in the routing table. Check also loop prevention, I use this for building DAGs for BRIO distribution. It can be reused for loop-free routing. BRDP uses hop-count and metrics, with seq.no. and thresholds for loop prevention. For now, BRDP is IPv6. I planned to add IPv4 support in next version. Address generation is not possible (possibility for duplicates to large for skipping DAD). Routing v4 over the DAGs (including SA based routing to backbone) is no problem. I have some ideas on using BRIO information for SA selection. Each node has information on the best path to the backbone (or Internet default free zone), and a corresponding SA should be used for nodes not listed in the routing table. Regards, Teco |-----Oorspronkelijk bericht----- |Van: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] Namens Richard |Kelsey |Verzonden: dinsdag 7 april 2009 18:17 |Aan: pthubert@cisco.com |CC: roll@ietf.org |Onderwerp: Re: [Roll] FW: New Version Notification fordraft-thubert- |roll-fundamentals-00 | | Date: Tue, 7 Apr 2009 17:53:35 +0200 | From: "Pascal Thubert (pthubert)" | | I'm working on changes to accommodate multiple trees. The trouble I | have is for the default route. Whether the tree is Grounded or | not, there can be only one tree used for default route, unless you | enter MTR and flow labels. But the default is useful even if the | tree is Floating. | |Makes sense. | | The way I see it, we end up with a new bit, "default" and a node | can only belong to one default tree. It'd better select a Grounded | one. If a node belongs to 2 trees where the parent advertise | default, the router will have to abandon the default on one of them | as it propagates the TIO. | | I think we can easily describe that but I'm unsure whether that | goes in the main text or in 6.5. | | What do you think? | |Moving between trees is discussed in item 6 in 2.1, so I |think it needs to mentioned there. Perhaps that item should |be moved to 6.5? | -Richard Kelsey | |---------------- |This message and the information it contains are the proprietary |and confidential property of Ember Corporation and may be privileged. |If you are not the intended recipient, please do not read, copy, |disclose or distribute its contents to any party, and notify the |sender immediately. |_______________________________________________ |Roll mailing list |Roll@ietf.org |https://www.ietf.org/mailman/listinfo/roll From pthubert@cisco.com Thu Apr 9 01:59: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 519EB3A6B7E for ; Thu, 9 Apr 2009 01:59:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.706 X-Spam-Level: X-Spam-Status: No, score=-9.706 tagged_above=-999 required=5 tests=[AWL=0.893, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dUDX1mh2TQod for ; Thu, 9 Apr 2009 01:59:11 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id BFD1F3A6A10 for ; Thu, 9 Apr 2009 01:59:10 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,159,1238976000"; d="scan'208";a="37830180" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 09 Apr 2009 08:59:41 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n398xf0Y020074 for ; Thu, 9 Apr 2009 10:59:41 +0200 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n398xf95027676 for ; Thu, 9 Apr 2009 08:59:41 GMT Received: from xmb-ams-337.cisco.com ([144.254.231.82]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 9 Apr 2009 10:59:41 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 Date: Thu, 9 Apr 2009 10:59:34 +0200 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC074276FB@xmb-ams-337.emea.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: New Version Notification for draft-thubert-roll-fundamentals-01 Thread-Index: Acm42PAQcZbxX+SHRFuYq5SOkYMd6QADySOg From: "Pascal Thubert (pthubert)" To: X-OriginalArrivalTime: 09 Apr 2009 08:59:41.0333 (UTC) FILETIME=[84EA0C50:01C9B8F1] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=6102; t=1239267581; x=1240131581; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pthubert@cisco.com; z=From:=20=22Pascal=20Thubert=20(pthubert)=22=20 |Subject:=20FW=3A=20New=20Version=20Notification=20for=20dr aft-thubert-roll-fundamentals-01=20 |Sender:=20; bh=q3WwZHCfq8WcFuKwSMxTKzb+JUlilkPhiTzc7xsFeoY=; b=uphiANYh/PD8sMwlnpbnKZoa/K0w0dzZKbYo8TEzRp0ky+Qffo3fMvQO0b lIb8kp23P6pM5jXgD8x1640aHTtQpQwPWjHrpGIsbe3NawPvW6xMA7bx9plN 3eus9Ur+ON; Authentication-Results: ams-dkim-2; header.From=pthubert@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Subject: [Roll] FW: New Version Notification for draft-thubert-roll-fundamentals-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, 09 Apr 2009 08:59:12 -0000 RGVhciBSb2xsZXJzOg0KDQpUYWtpbmcgZmVlZGJhY2sgZnJvbSBhIG51bWJlciBvZiBzb3VyY2Vz LCB3ZSBkZWNpZGVkIHRvIHB1Ymxpc2ggYSBuZXcgdmVyc2lvbiBvZiBkcmFmdC10aHViZXJ0LXJv bGwtZnVuZGFtZW50YWxzIHRoYXQgbGV0cyBvdXQgc29tZSBnb3J5IGRldGFpbHMgb2YgdGhlIGV4 YWN0IG9wZXJhdGlvbnMgZnJvbSAwMCB0byBwcm92aWRlIGEgY2xlYXJlciBhbmQgbW9yZSBjb21w cmVoZW5zaXZlIHZpZXcgb2YgdGhlIG92ZXJhbGwgcHJvcG9zZWQgYXBwcm9hY2guIFRoZSBnb2Fs IG9mIHRoZSBkcmFmdCBpcyBjZXJ0YWlubHkgbm90IHRvIGNvbXBldGUgd2l0aCB0aGUgRFQgZWZm b3J0IGJ1dCB0byBwcm92aWRlIHNvbWUgaW5wdXQgdG8gdGhlIERUIHRoYXQgd2FzIGp1c3QgZm9y bWVkIGFuZCBoZWxwIGl0cyBraWNrLW9mZi4gDQoNCjEpIFRoaXMgY29udHJpYnV0aW9uIGRldGFp bHMgdGhlIGZvcm1hdGlvbiBvZiBhIERpc3RhbmNlIFZlY3RvciB0cmVlIHVzaW5nIE5EIGV4dGVu c2lvbnM7IG1vc3QgZXhpc3RpbmcgY29udHJpYnV0aW9ucyB0byB0aGlzIFdHIHN1Z2dlc3QgdGhh dCBhcHByb2FjaCAoVGVjbydzIEJSRFAsIEFyc2FsYW4gJiBhbC4gJ3MgSHlkcm8ncyBEZWZhdWx0 IFJvdXRlIEZvcm1hdGlvbiwgUGhpbCAmIGFsLiBVc2VuaXggcGFwZXIncyBUcmVlIGJhc2VkIHJv dXRpbmcuLi4pIGFuZCB0aGUgdmFsdWUgd2UgcHJvdmlkZSBoZXJlIGlzIG1vcmUgcmVmaW5lZCBk ZXRhaWxzIG9uIHN1Y2ggb3BlcmF0aW9uLCB0byBhZGRyZXNzIGZvciBpbnN0YW5jZSBtZXJnaW5n IGFuZCBzcGxpdHRpbmcgb2YgdHJlZXMgb3IgdGhlIGludGVncmF0aW9uIHdpdGggdGhlIDZMb1dQ QU4gYmFja2JvbmUuIA0KDQoyKSBGb3J3YXJkaW5nIGFsb25nIHRoZSB0cmVlIHRvIHRoZSBzaW5r IGlzIGEgYml0IGRpZmZlcmVudCBmcm9tIG9uZSBkcmFmdCBhbmQgcGFwZXIgdG8gYW5vdGhlci4g V2UgKFJPTEwpIGhhdmUgYSBjbGVhciByZXF1aXJlbWVudCB0byBmb3J3YXJkIGFuZCBlbmFibGUg cmV0cmllcyBvdmVyIG11bHRpcGxlIG5leHQgaG9wcyBhbG9uZyBhIGdyYXBoIHRvIHRoZSBzaW5r IHRoYXQgZGVyaXZlcyBmcm9tIHRoZSBsb3NzeW5lc3Mgb2Ygc29tZSBvZiB0aGUgbGlua3Mgd2Ug b3BlcmF0ZSBvbi4gVGhpcyBkcmFmdCBzdWdnZXN0cyB0aGF0IHRoZSB0cmVlIGlzIG1lcmVseSBh IHNrZWxldG9uIGZvciBzdWNoIGEgZmFicmljIGFuZCB0aGF0IHBhY2tldHMgY2FuIGJlIGZvcndh cmRlZCBhbG9uZyBhIGdyYXBoIHRoYXQgZm9ybXMgdGhlICdhdXJhJyBvZiB0aGF0IHRyZWUuIA0K DQpCYXNpY2FsbHksIHNpbmNlIHdlIGhhdmUgYSBkZXB0aCwgd2UgaGF2ZSBmZWFzaWJsZSBwYXJl bnRzIChvZiBsZXNzZXIgZGVwdGgpIGFuZCBzaWJsaW5ncyAob2Ygc2FtZSBkZXB0aCkuIFRoZSBk cmFmdCBzdWdnZXN0cyB0aGF0IHdlIGNhbiBzZWxlY3QgYW55IHBhcmVudCB0byBmb3J3YXJkIG9u IGEgcGVyIHBhY2tldCBiYXNpcyB1c2luZyB0aGUgYmVzdCBtZXRyaWMgb3IgbW9yZSBhZHZhbmNl ZCBsb2FkIGJhbGFuY2luZyBmdW5jdGlvbmFsaXR5OyBpZiB0aGF0IGZhaWxzIHRoZW4gd2UgY2Fu IHVzZSBhIHNpYmxpbmcgd2l0aCBzb21lIGJhc2ljIGxvb3AgYXZvaWRhbmNlIGxpa2UgcG9pc29u IHJldHVybiBvciBtb3JlIGFkdmFuY2VkIHBhdGggdmVjdG9yIChmb3IgaHlkcm9waGlsZXMpLg0K DQpPbmUgYmVuZWZpdCBvZiB0aGF0IGFwcHJvYWNoIGlzIHRoYXQgdGhlcmUgaXMgbm90IG9uZSBE QUcgZml0cy1pdC1hbGwsIGJ1dCBhbiBlcXVhbCBvcHBvcnR1bml0eSBiZXR3ZWVuIHNpYmxpbmdz IHRvIHVzZSBvbmUgYW5vdGhlciBvbiBhIHBlciBwYWNrZXQgYmFzaXMuIFNvIHJvdXRlciBCIG1p Z2h0IGZvcndhcmQgYSBnaXZlbiBwYWNrZXQgdG8gc2libGluZyByb3V0ZXIgQSB0aGF0IHBhc3Nl cyBpdCB0byBvbmUgb2YgaXRzIHBhcmVudHMgd2hlcmVhcyBsYXRlciByb3V0ZXIgQiB3b3VsZCBm b3J3YXJkIGFub3RoZXIgcGFja2V0IHRvIEEgdGhhdCB3b3VsZCBwYXNzIGl0IHRvIG9uZSBvZiBp dHMgcGFyZW50cywgYWxsIGZvciBhbiB1bmNoYW5nZWQgc2FtZSB0cmVlIHN0cnVjdHVyZS4NCg0K QW5vdGhlciBiZW5lZml0IGlzIHRoYXQgd2UgY2FuIGJlIGEgbG90IG1vcmUgbGF6eSBpbiByZXN0 cnVjdHVyaW5nIHRoZSB0cmVlIHRvIGFkYXB0IHRoZSByb3V0aW5nIHRvIHRoZSBtZXRyaWMgY2hh bmdlcyBzaW5jZSB0aGUgZm9yd2FyZGluZyBjYW4gc3RhcnQgdXNpbmcgdGhlIG1ldHJpYyB1cGRh dGUgYSBsb3QgZWFybGllciBhbnl3YXkuIFRoZSBpZGVhIGlzIHRoYXQgd2UgYWRhcHQgdG8gYW5k IHByb3BhZ2F0ZSB0aGUgbWV0cmljIHJhcGlkbHkgYnV0IHdlIGFjdCB1cG9uIHRoZSBtZXRyaWMg dG8gcmVzdHJ1Y3R1cmUgdGhlIHRyZWUgb25seSBhZnRlciBpdCBhcHBlYXJzIHRoYXQgdGhlIG5l dyBjb25kaXRpb25zIGFyZSBzdGFibGUgZW5vdWdoIHRvIGp1c3RpZnkgdGhlIGVmZm9ydC4NCg0K Mykgcm91dGluZyB0b3dhcmRzIHRoZSBsZWF2ZXMgaXMgYSBtb3JlIG1ham9yIGRpZmZlcmVuY2Ug YW5kIEkgZ3Vlc3Mgd2UgbmVlZCB0byB0YWxrLiBUaGlzIGRyYWZ0IHN1Z2dlc3RzIHRoYXQgdGhl IGludGVyZXN0aW5nIGxlYXZlcyBjYW4gcGVyY29sYXRlIHVuaWNhc3QgYW5kIG11bHRpY2FzdCBp bmZvcm1hdGlvbiBpbiBOQSBtZXNzYWdlcyB0b3dhcmRzIHRoZSByb290LCBlbmFibGluZyByb3V0 aW5nIGFsb25nIHRoZSB0cmVlLiBZb3UgZmluZCBhIHNpbWlsYXIgaWRlYSB3aXRoIFRlY28ncyBC UklPLiBUaGUgZHJhZnQgYWxzbyBhbGxvd3MgZm9yOg0KLSBtdWx0aXBsZSBhbHRlcm5hdGUgdHJl ZXMgZm9yIG1vcmUgc3BlY2lmaWMgZGVzdGluYXRpb25zIA0KLSBzb3VyY2Ugcm91dGluZyBhbG9u ZyB0aGUgdHJlZSB0aGF04oCZcyBkeW5hbWljYWxseSBjb21wcmVzc2VkIHdoZW4gcm91dGluZyBz dGF0ZXMgbWF0Y2ggdGhlIHNvdXJjZSByb3V0ZSBpbmZvDQoNCjQpIGZpbmFsbHkgdGhlIGRyYWZ0 IGxpc3RzIGEgbnVtYmVyIG9mIGFkZGl0aW9uYWwgZmVhdHVyZXMgdGhhdCBtaWdodCBvciBtaWdo dCBub3QgYmUgY29uc2lkZXJlZCBmb3IgaW5jbHVzaW9uIHRvIGJldHRlciBmaXQgc29tZSBzcGVj aWZpYyByZXF1aXJlbWVudHMuIFlvdSdsbCBmaW5kIHNvbWUgaGludHMgb24gaG93IHRvIHVzZSBN dWx0aXBsZSB0b3BvbG9neSBSb3V0aW5nIHVzaW5nIG11bHRpcGxlIGRlZmF1bHQgdHJlZXMsIE9m ZmxpbmUgUm91dGluZyBmb3IgYmFzaWMgVHJhZmZpYyBFbmdpbmVlcmluZyAoc2ltaWxhciB0byBI eWRybyksIHNvbWUgb24tZGVtYW5kIGFkaG9jIHVzaW5nIHJlYWN0aXZlIE1BTkVUIChzaW1pbGFy IHRvIDgwMi4xMVMpIGV0Yy4uLg0KDQpIYXBweSByZWFkaW5nLA0KDQpQYXNjYWwNCg0KLS0tLS1P cmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IElFVEYgSS1EIFN1Ym1pc3Npb24gVG9vbCBbbWFp bHRvOmlkc3VibWlzc2lvbkBpZXRmLm9yZ10gDQpTZW50OiBqZXVkaSA5IGF2cmlsIDIwMDkgMDg6 MDINClRvOiBQYXNjYWwgVGh1YmVydCAocHRodWJlcnQpDQpDYzogd2F0dGV5bmVAZWVjcy5iZXJr ZWxleS5lZHU7IHphY2hAc2Vuc2lub2RlLmNvbTsgZG9taW5pcXVlLmJhcnRoZWxAb3JhbmdlLWZ0 Z3JvdXAuY29tDQpTdWJqZWN0OiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LXRo dWJlcnQtcm9sbC1mdW5kYW1lbnRhbHMtMDEgDQoNCg0KQSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRy YWZ0LXRodWJlcnQtcm9sbC1mdW5kYW1lbnRhbHMtMDEudHh0IGhhcyBiZWVuIHN1Y2Nlc3NmdWx5 IHN1Ym1pdHRlZCBieSBQYXNjYWwgVGh1YmVydCBhbmQgcG9zdGVkIHRvIHRoZSBJRVRGIHJlcG9z aXRvcnkuDQoNCkZpbGVuYW1lOgkgZHJhZnQtdGh1YmVydC1yb2xsLWZ1bmRhbWVudGFscw0KUmV2 aXNpb246CSAwMQ0KVGl0bGU6CQkgTExOIFJvdXRpbmcgRnVuZGFtZW50YWxzDQpDcmVhdGlvbl9k YXRlOgkgMjAwOS0wNC0wOQ0KV0cgSUQ6CQkgSW5kZXBlbmRlbnQgU3VibWlzc2lvbg0KTnVtYmVy X29mX3BhZ2VzOiAyOQ0KDQpBYnN0cmFjdDoNClRoaXMgZG9jdW1lbnQgZGVzY3JpYmVzIGEgYmFz aWMgc2V0IG9mIGZ1bmRhbWVudGFsIG1lY2hhbmlzbXMgZm9yDQpyb3V0aW5nIG9uIGEgTG93LXBv d2VyIGFuZCBMb3NzeSBOZXR3b3JrIChMTE4pLiAgSXQgZG9lcyBub3QgaW50ZW5kDQp0byBzcGVj aWZ5IGEgZnVsbC1ibG93biBwcm90b2NvbC4gIEl0IGlzIHJhdGhlciBvZmZlcmVkIGFzIGEgYmFz aXMgdG8NCnN1cHBvcnQgdGhlIGRpc2N1c3Npb24gd2hpbGUgZGVzaWduaW5nIHRoZSBST0xMIHBy b3RvY29sLg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIA0KDQoNClRoZSBJRVRGIFNlY3JldGFy aWF0Lg0KDQoNCg== From pthubert@cisco.com Thu Apr 9 05:08: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 0050228C0F0 for ; Thu, 9 Apr 2009 05:08:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.748 X-Spam-Level: X-Spam-Status: No, score=-9.748 tagged_above=-999 required=5 tests=[AWL=0.851, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f2xzcHsTulwe for ; Thu, 9 Apr 2009 05:08:43 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 314433A6C3A for ; Thu, 9 Apr 2009 05:08:43 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,160,1238976000"; d="scan'208";a="37863558" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 09 Apr 2009 12:09:50 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n39C9oSd029985; Thu, 9 Apr 2009 14:09:50 +0200 Received: from xbh-ams-331.emea.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n39C9m9c021227; Thu, 9 Apr 2009 12:09:49 GMT Received: from xmb-ams-337.cisco.com ([144.254.231.82]) by xbh-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 9 Apr 2009 14:09:48 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 9 Apr 2009 14:09:41 +0200 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC0742780E@xmb-ams-337.emea.cisco.com> In-Reply-To: <000001c9b8e9$1bb6def0$53249cd0$@nl> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] FW: New Version Notification fordraft-thubert-roll-fundamentals-00 Thread-Index: Acm3nIKPdEd1D/bgT8y8BTIRpRSBcwBPy3qwAAs/saA= References: <7892795E1A87F04CADFCCF41FADD00FC07365A53@xmb-ams-337.emea.cisco.com> <200904021954.n32JsfUu016043@kelsey-ws.hq.ember.com> <7892795E1A87F04CADFCCF41FADD00FC073C3E79@xmb-ams-337.emea.cisco.com> <7892795E1A87F04CADFCCF41FADD00FC073C4145@xmb-ams-337.emea.cisco.com> <7892795E1A87F04CADFCCF41FADD00FC073C432D@xmb-ams-337.emea.cisco.com> <200904061817.n36IHPhc005447@kelsey-ws.hq.ember.com> <7892795E1A87F04CADFCCF41FADD00FC07427042@xmb-ams-337.emea.cisco.com> <200904071617.n37GHRGU016887@kelsey-ws.hq.ember.com> <000001c9b8e9$1bb6def0$53249cd0$@nl> From: "Pascal Thubert (pthubert)" To: "Teco Boot" X-OriginalArrivalTime: 09 Apr 2009 12:09:48.0721 (UTC) FILETIME=[143F5210:01C9B90C] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=4934; t=1239278990; x=1240142990; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pthubert@cisco.com; z=From:=20=22Pascal=20Thubert=20(pthubert)=22=20 |Subject:=20RE=3A=20[Roll]=20FW=3A=20New=20Version=20Notifi cation=09fordraft-thubert-roll-fundamentals-00 |Sender:=20; bh=SJYv55wyfDtww7dlhTbOzbe6x78NYV1jRlxhJ15on+w=; b=kPtvGZsFvaSCpJit3c/QOfMHzF/hchduYChoQnpfpHJ5XSewd9hFfYuVLJ 7VZ44rYc8I01aVjoYg5nMbORBHeN1hYPzsucZfiR4T4+XLji/P+2hJ93MnIp EyAgpYgRLp; Authentication-Results: ams-dkim-2; header.From=pthubert@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Cc: roll@ietf.org Subject: Re: [Roll] FW: New Version Notification fordraft-thubert-roll-fundamentals-00 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2009 12:08:45 -0000 Hi Teco, Please note that the tree formation in draft 01 incorporates your suggestion (Richard had the same) about allowing to attach to a deeper parent if the sequence is newer :)=20 Please see below: >For multiple trees (DAGs) and efficient routing without default routes / MTR >/ flow labels, you could check Border Router Discovery Protocol and related >BRDP based routing: >http://tools.ietf.org/html/draft-boot-autoconf-brdp >http://tools.ietf.org/html/draft-boot-brdp-based-routing > >BRDP provides DAGs to attachment points, called Border Router. There is no >TIO (no Tree) but BRIO (Border Router). Makes sense. Note that for 6LoWPAN backbone, the backbone owns the prefix and is the virtual root of the aggregated tree. >The sub-DAG tree identifier is the Border Router address. Nodes can use >source addresses based on advertized BR prefixes. This enables using these >addresses as locators. Added something similar in 01 from (again) Richard's suggestion >BRDP / BRDP based routing use a routing protocol for reachability to the >backbone: next-hop to the Border Router. BRDP has its history in MANET / >Autoconf. It is easy to add paths to the backbone, learned from BRDP (path >to BR) or towards nodes (explicit messages, routing header and / or >snooping). Routing to the backbone uses the source addresses, when >destination is not in routing table. The requirement is that nexthop towards >BR is in the routing table. As you know I like explicit messages but all 3 types of methods to route towards node seem to have their own support. What's not totally clear to me in the BRDP draft is the link / dependence to a MANET routing protocol. Is there any? I mean when you say MANET router could we try LLN router and get the same result? =20 >Check also loop prevention, I use this for building DAGs for BRIO >distribution. It can be reused for loop-free routing. BRDP uses hop-count >and metrics, with seq.no. and thresholds for loop prevention. Will do. You know that I do not like using UPM for loop prevention and I prefer the depth. The depth is a guaranteed Esperanto whereas the metric might be hardly comparable over heterogeneous hops. Also the roll-fundamentals draft enables forwarding along the best metric while keeping the tree intact for a while, so we manage to get similar benefit in terms of path metrics with a better topological stability while using common sense depth as the base loop avoidance method. >For now, BRDP is IPv6. I planned to add IPv4 support in next version. >Address generation is not possible (possibility for duplicates to large for >skipping DAD). Routing v4 over the DAGs (including SA based routing to >backbone) is no problem. > >I have some ideas on using BRIO information for SA selection. Each node has >information on the best path to the backbone (or Internet default free >zone), and a corresponding SA should be used for nodes not listed in the >routing table. Makes sense Cheers, Pascal > > >|-----Oorspronkelijk bericht----- >|Van: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] Namens Richard >|Kelsey >|Verzonden: dinsdag 7 april 2009 18:17 >|Aan: pthubert@cisco.com >|CC: roll@ietf.org >|Onderwerp: Re: [Roll] FW: New Version Notification fordraft-thubert- >|roll-fundamentals-00 >| >| Date: Tue, 7 Apr 2009 17:53:35 +0200 >| From: "Pascal Thubert (pthubert)" >| >| I'm working on changes to accommodate multiple trees. The trouble I >| have is for the default route. Whether the tree is Grounded or >| not, there can be only one tree used for default route, unless you >| enter MTR and flow labels. But the default is useful even if the >| tree is Floating. >| >|Makes sense. >| >| The way I see it, we end up with a new bit, "default" and a node >| can only belong to one default tree. It'd better select a Grounded >| one. If a node belongs to 2 trees where the parent advertise >| default, the router will have to abandon the default on one of them >| as it propagates the TIO. >| >| I think we can easily describe that but I'm unsure whether that >| goes in the main text or in 6.5. >| >| What do you think? >| >|Moving between trees is discussed in item 6 in 2.1, so I >|think it needs to mentioned there. Perhaps that item should >|be moved to 6.5? >| -Richard Kelsey >| >|---------------- >|This message and the information it contains are the proprietary >|and confidential property of Ember Corporation and may be privileged. >|If you are not the intended recipient, please do not read, copy, >|disclose or distribute its contents to any party, and notify the >|sender immediately. >|_______________________________________________ >|Roll mailing list >|Roll@ietf.org >|https://www.ietf.org/mailman/listinfo/roll From jvasseur@cisco.com Thu Apr 9 05:09: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 822B128C0F0 for ; Thu, 9 Apr 2009 05:09:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.262 X-Spam-Level: X-Spam-Status: No, score=-10.262 tagged_above=-999 required=5 tests=[AWL=0.336, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m1dYhuYQMgkm for ; Thu, 9 Apr 2009 05:09:42 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 66A7D3A6C3A for ; Thu, 9 Apr 2009 05:09:42 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,160,1238976000"; d="scan'208,217";a="37863681" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 09 Apr 2009 12:10:47 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n39CAkGQ030304 for ; Thu, 9 Apr 2009 14:10:46 +0200 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n39CAkDn021580 for ; Thu, 9 Apr 2009 12:10:46 GMT Received: from xfe-ams-331.emea.cisco.com ([144.254.231.72]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 9 Apr 2009 14:10:46 +0200 Received: from ams-jvasseur-8713.cisco.com ([10.55.201.132]) by xfe-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 9 Apr 2009 14:10:46 +0200 Message-Id: <6B0F7142-E6D3-456D-A15E-FC1B4E2DE554@cisco.com> From: JP Vasseur To: ROLL WG Content-Type: multipart/alternative; boundary=Apple-Mail-58--1021159147 Mime-Version: 1.0 (Apple Message framework v930.3) Date: Thu, 9 Apr 2009 14:10:45 +0200 X-Mailer: Apple Mail (2.930.3) X-OriginalArrivalTime: 09 Apr 2009 12:10:46.0355 (UTC) FILETIME=[36999230:01C9B90C] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=867; t=1239279046; x=1240143046; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:=20JP=20Vasseur=20 |Subject:=20Our=20first=20document=20in=20RFC=20ed=20queue= 20=3A-) |Sender:=20; bh=/64i16+QwdECZXef0cfJouq8EnyZ3XdasKWOKvD1KhY=; b=E0z3ayDT3VeoZQfByCHzLclOqlfaNmeidP8aPsUFpJvZog3TBwuYBelNI1 VfIGoBpP1t2o0M+6jVB3VxF4fD0NuWElqzlFLhp5ZSC49HMpnCzykWSpmnkn VGLu3qPyhe; Authentication-Results: ams-dkim-2; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Subject: [Roll] Our first document in RFC ed queue :-) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 09 Apr 2009 12:09:43 -0000 --Apple-Mail-58--1021159147 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit 'State Changes to RFC Ed Queue from Approved-announcement sent by Cindy Morgan' ID Tracker URL: https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=17207&rfc_flag=0 --Apple-Mail-58--1021159147 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit 'State Changes to RFC Ed Queue from Approved-announcement sent by Cindy Morgan'
ID Tracker URL: https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=17207&rfc_flag=0
--Apple-Mail-58--1021159147-- From richard.kelsey@ember.com Thu Apr 9 12:09: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 3BDE43A6C92 for ; Thu, 9 Apr 2009 12:09:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 1rxkWptdpRYw for ; Thu, 9 Apr 2009 12:09:05 -0700 (PDT) Received: from EMPIRE.hq.ember.com (mail.ember.com [74.10.175.227]) by core3.amsl.com (Postfix) with ESMTP id 6ADEB3A6C78 for ; Thu, 9 Apr 2009 12:09:05 -0700 (PDT) Received: from kelsey-ws.hq.ember.com ([192.168.81.55]) by EMPIRE.hq.ember.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 9 Apr 2009 15:10:56 -0400 Received: from kelsey-ws.hq.ember.com (localhost.localdomain [127.0.0.1]) by kelsey-ws.hq.ember.com (8.13.4/8.13.4) with ESMTP id n39JACDs011046; Thu, 9 Apr 2009 15:10:12 -0400 Received: (from kelsey@localhost) by kelsey-ws.hq.ember.com (8.13.4/8.12.8/Submit) id n39JACUF011043; Thu, 9 Apr 2009 15:10:12 -0400 Date: Thu, 9 Apr 2009 15:10:12 -0400 Message-Id: <200904091910.n39JACUF011043@kelsey-ws.hq.ember.com> To: pthubert@cisco.com In-reply-to: <7892795E1A87F04CADFCCF41FADD00FC074276FB@xmb-ams-337.emea.cisco.com> (pthubert@cisco.com) From: Richard Kelsey References: <7892795E1A87F04CADFCCF41FADD00FC074276FB@xmb-ams-337.emea.cisco.com> X-OriginalArrivalTime: 09 Apr 2009 19:10:56.0923 (UTC) FILETIME=[E944F6B0:01C9B946] Cc: roll@ietf.org Subject: Re: [Roll] FW: New Version Notification for draft-thubert-roll-fundamentals-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, 09 Apr 2009 19:09:06 -0000 Date: Thu, 9 Apr 2009 10:59:34 +0200 From: "Pascal Thubert (pthubert)" 3) routing towards the leaves is a more major difference and I guess we need to talk. This draft suggests that the interesting leaves can percolate unicast and multicast information in NA messages towards the root, enabling routing along the tree. I think that we need to be careful with this to avoid requiring too much routing state. The root and its children could end up having to store a lot of information. As spelled out in the protocol survey document, routing state should be bounded by O(D), where D is the number of "unique destinations". I couldn't find a definition for this, but the document states that it scales at less than O(N), where N is the number of nodes. This means that most nodes cannot be included in the disseminated information. Presumably these less-interesting devices can be reached via route records or other topology information stored on a root. Given that most nodes can only be reached via a root in any case, it isn't clear to me that route dissemination is worth the trouble. -Richard Kelsey From teco@inf-net.nl Thu Apr 9 12:41:48 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2BECD3A69BC for ; Thu, 9 Apr 2009 12:41:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.21 X-Spam-Level: X-Spam-Status: No, score=-2.21 tagged_above=-999 required=5 tests=[AWL=0.389, 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 xhbB369Tx5TO for ; Thu, 9 Apr 2009 12:41:47 -0700 (PDT) Received: from CPSMTPM-EML108.kpnxchange.com (Cpsmtpm-eml108.kpnxchange.com [195.121.3.12]) by core3.amsl.com (Postfix) with ESMTP id DA8BA3A6AE0 for ; Thu, 9 Apr 2009 12:41:11 -0700 (PDT) Received: from M90Teco ([86.83.9.22]) by CPSMTPM-EML108.kpnxchange.com with Microsoft SMTPSVC(7.0.6001.18000); Thu, 9 Apr 2009 21:42:19 +0200 From: "Teco Boot" To: "'Pascal Thubert \(pthubert\)'" References: <7892795E1A87F04CADFCCF41FADD00FC07365A53@xmb-ams-337.emea.cisco.com> <200904021954.n32JsfUu016043@kelsey-ws.hq.ember.com> <7892795E1A87F04CADFCCF41FADD00FC073C3E79@xmb-ams-337.emea.cisco.com> <7892795E1A87F04CADFCCF41FADD00FC073C4145@xmb-ams-337.emea.cisco.com> <7892795E1A87F04CADFCCF41FADD00FC073C432D@xmb-ams-337.emea.cisco.com> <200904061817.n36IHPhc005447@kelsey-ws.hq.ember.com> <7892795E1A87F04CADFCCF41FADD00FC07427042@xmb-ams-337.emea.cisco.com> <200904071617.n37GHRGU016887@kelsey-ws.hq.ember.com> <000001c9b8e9$1bb6def0$53249cd0$@nl> <7892795E1A87F04CADFCCF41FADD00FC0742780E@xmb-ams-337.emea.cisco.com> In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FC0742780E@xmb-ams-337.emea.cisco.com> Date: Thu, 9 Apr 2009 21:42:19 +0200 Message-ID: <000001c9b94b$4b544730$e1fcd590$@nl> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acm3nIKPdEd1D/bgT8y8BTIRpRSBcwBPy3qwAAs/saAAEEEj4A== Content-Language: nl X-OriginalArrivalTime: 09 Apr 2009 19:42:19.0589 (UTC) FILETIME=[4B6CFF50:01C9B94B] Cc: roll@ietf.org Subject: Re: [Roll] FW: New Version Notification fordraft-thubert-roll-fundamentals-00 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2009 19:41:48 -0000 Hi Pascal, |>BRDP / BRDP based routing use a routing protocol for reachability to |the |>backbone: next-hop to the Border Router. BRDP has its history in MANET |/ |>Autoconf. It is easy to add paths to the backbone, learned from BRDP |(path |>to BR) or towards nodes (explicit messages, routing header and / or |>snooping). Routing to the backbone uses the source addresses, when |>destination is not in routing table. The requirement is that nexthop |towards |>BR is in the routing table. | |As you know I like explicit messages but all 3 types of methods to route |towards node seem to have their own support. What's not totally clear to |me in the BRDP draft is the link / dependence to a MANET routing |protocol. Is there any? I mean when you say MANET router could we try |LLN router and get the same result? There is no dependency. BRDP does not provide paths, that is up to routing. But the upstream node advertizing the BRIO could be used as next hop to that BR. Maybe we need a flag for this, indicating all nodes to the BR have the next hop. Or just define this as mandatory. |>Check also loop prevention, I use this for building DAGs for BRIO |>distribution. It can be reused for loop-free routing. BRDP uses |hop-count |>and metrics, with seq.no. and thresholds for loop prevention. |Will do. You know that I do not like using UPM for loop prevention and I |prefer the depth. | |The depth is a guaranteed Esperanto whereas the metric might be hardly |comparable over heterogeneous hops. The metric is for the path, not for the link. Lower metric as the threshold means guaranteed loop-free. No difference with depth. You know I dislike the hop-count protocols :-) Anyway, I use both. This beats your proposal. Teco. From eunah.ietf@gmail.com Thu Apr 9 23:58: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 F348E3A6845 for ; Thu, 9 Apr 2009 23:58:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.556 X-Spam-Level: X-Spam-Status: No, score=-2.556 tagged_above=-999 required=5 tests=[AWL=0.043, 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 vqKERbpmn1qi for ; Thu, 9 Apr 2009 23:58:39 -0700 (PDT) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.236]) by core3.amsl.com (Postfix) with ESMTP id 08ECE3A6B72 for ; Thu, 9 Apr 2009 23:58:38 -0700 (PDT) Received: by rv-out-0506.google.com with SMTP id b25so577468rvf.5 for ; Thu, 09 Apr 2009 23:59:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=NaR3VUiQN7aF5QO5TnXZdyINAx4H8S4l/Fv9+LUeqAg=; b=vCIfEYHv1F8UdT0AtlvXy3T5YbXTuG/RpRdY8hQTsHTp3sDa5jy/kxLKG5WSKUGPJZ HsnOmU3Mn2hnOKSsMq2RqTGulbiAWkB88tnh2OQYU32RslhtZrsx6aYPr/XrwvnA2O9c XRFGSbdv7/IsPz8PK5Pij0ra33zd7vJLYBHNI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=DeVf6+mFccgEhEM6DElVgesejoBoav1WJEUCiBuMc/q2hAsDDv3q3hZyEtBJ810OzU 3oLULi+h23DA2o+BYt9EB8x4DqRGqjcFCcamlnUjWTp7gFE455IePrhy9AFCQUmq6D8G utHSHDi/VHFTybzshS49Pmlw5FAKQuei/Ps1o= MIME-Version: 1.0 Received: by 10.141.137.16 with SMTP id p16mr1387377rvn.180.1239346787062; Thu, 09 Apr 2009 23:59:47 -0700 (PDT) In-Reply-To: <257B9AAC-B5A5-4141-86B6-0E04C5DA3DA9@cs.stanford.edu> References: <0BD8BD8B-FD05-46E9-9AD4-7E9F312AAD21@cisco.com> <257B9AAC-B5A5-4141-86B6-0E04C5DA3DA9@cs.stanford.edu> Date: Fri, 10 Apr 2009 15:59:47 +0900 Message-ID: <77f1dba80904092359v5bb941eeu2f2c6f3065954bfa@mail.gmail.com> From: "Eunsook \"Eunah\" Kim" To: Philip Levis Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: ROLL WG Subject: Re: [Roll] Formation of a Routing Protocol Design Team for ROLL X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Apr 2009 06:58:40 -0000 Hi JP, It' my pure question about design team. I only saw the case that WG decides to make a design team for a certain WG item when people agreed to have a design team in the meeting. And, chairmen askes volunteers for the DT. I never saw that DT has been just announced in the mailing list. (Well, i have only 10years experience in the ietf. Maybe it's possible but i never saw the case like this so far. Thus I feel a bit that there is inner-circle discussion in ROLL WG, which normal participants cannot share.) Please don't misunderstand me. I think the current design team members are great and I think the members are the best choice what ROLL could have for a ROLL routing solution. -eunah On Thu, Apr 9, 2009 at 6:11 AM, Philip Levis wrote: > On Apr 1, 2009, at 12:57 AM, JP Vasseur wrote: > >> Dear WG, >> >> We have formed a new Design Team in the ROLL Working Group. Please find >> below the charter and team members. >> >> Since some of you may not be familiar with the concept of a Design Team, I >> would like to remind a few points: >> >> * The work produced by a Design Team has no special status in the WG and >> is subject to WG consensus as any other individual submission >> * We ask the Design Team to request for input from the WG and to provide >> regular updates on the progress: please send input requests to the mailing >> list, post regular updates of the document to get a chance to everybody to >> comment, ... >> * All: please provide input to the Design Team and copy the mailing list. > > JP, > > How does one join the design team? I would like to join. > > Phil > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > From jvasseur@cisco.com Fri Apr 10 00:08: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 AD7553A69A6 for ; Fri, 10 Apr 2009 00:08:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.268 X-Spam-Level: X-Spam-Status: No, score=-10.268 tagged_above=-999 required=5 tests=[AWL=0.331, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dstvubG7+wW7 for ; Fri, 10 Apr 2009 00:08:44 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 42D4A3A6AF4 for ; Fri, 10 Apr 2009 00:08:44 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,165,1238976000"; d="scan'208";a="37922986" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 10 Apr 2009 07:09:51 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n3A79p0o004807; Fri, 10 Apr 2009 09:09:51 +0200 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n3A79pYJ024360; Fri, 10 Apr 2009 07:09:51 GMT Received: from xfe-ams-331.emea.cisco.com ([144.254.231.72]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 10 Apr 2009 09:09:51 +0200 Received: from ams-jvasseur-8713.cisco.com ([10.55.201.132]) by xfe-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 10 Apr 2009 09:09:50 +0200 Message-Id: From: JP Vasseur To: Eunsook Eunah Kim In-Reply-To: <77f1dba80904092359v5bb941eeu2f2c6f3065954bfa@mail.gmail.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Fri, 10 Apr 2009 09:09:50 +0200 References: <0BD8BD8B-FD05-46E9-9AD4-7E9F312AAD21@cisco.com> <257B9AAC-B5A5-4141-86B6-0E04C5DA3DA9@cs.stanford.edu> <77f1dba80904092359v5bb941eeu2f2c6f3065954bfa@mail.gmail.com> X-Mailer: Apple Mail (2.930.3) X-OriginalArrivalTime: 10 Apr 2009 07:09:51.0051 (UTC) FILETIME=[573691B0:01C9B9AB] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2793; t=1239347391; x=1240211391; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:=20JP=20Vasseur=20 |Subject:=20Re=3A=20[Roll]=20Formation=20of=20a=20Routing=2 0Protocol=20Design=20Team=20for=20ROLL |Sender:=20; bh=9TWzXZm8xF6CqiIqQRIqCg3eg0YXhZCQ1C2H4hm9Irg=; b=dKX4fwznB3JOm1htJHKrl5OKk2fuVNDGfOnnOWz/kQOmE3ITKa79SuOON0 8sIXV2D/cFxZV4ioFoK/I+8fT6l5fqLZQc7FMlzy3wK9WYP27onibFssnis8 KYdoZr5GfR; Authentication-Results: ams-dkim-1; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Cc: ROLL WG Subject: Re: [Roll] Formation of a Routing Protocol Design Team for ROLL X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Apr 2009 07:08:45 -0000 Hi Eunah, On Apr 10, 2009, at 8:59 AM, Eunsook Eunah Kim wrote: > Hi JP, > > It' my pure question about design team. > I only saw the case that WG decides to make a design team for a > certain WG item when people agreed to have a design team in the > meeting. And, chairmen askes volunteers for the DT. > I never saw that DT has been just announced in the mailing list. > (Well, i have only 10years experience in the ietf. Maybe it's possible > but i never saw the case like this so far. Thus I feel a bit that > there is inner-circle discussion in ROLL WG, which normal participants > cannot share.) Not at all. We (co-chair) came up with a list of names. Such a process is not unusual at all. Should you be interested you please look at Section 6.5 of RFC 2418 > > Please don't misunderstand me. I think the current design team members > are great and > I think the members are the best choice what ROLL could have for a > ROLL routing solution. > Thanks for the feed-back. Something really important: as pointed out in my first email the DT has no special status and nobody should feel "excluded" ! We do need to contribution of all ROLL contributors. Furthermore, the DT will regularly poll the other members for feed- back, advise, ... and in addition everybody is free to post its own proposal of course. Last but not least: there are many very valuable contributors of ROLL that are purposely not part of the DT: it is also extremely important to have non DT members providing inputs, contribution, ... Hope this help. Thanks. JP. > -eunah > > > On Thu, Apr 9, 2009 at 6:11 AM, Philip Levis > wrote: >> On Apr 1, 2009, at 12:57 AM, JP Vasseur wrote: >> >>> Dear WG, >>> >>> We have formed a new Design Team in the ROLL Working Group. Please >>> find >>> below the charter and team members. >>> >>> Since some of you may not be familiar with the concept of a Design >>> Team, I >>> would like to remind a few points: >>> >>> * The work produced by a Design Team has no special status in the >>> WG and >>> is subject to WG consensus as any other individual submission >>> * We ask the Design Team to request for input from the WG and to >>> provide >>> regular updates on the progress: please send input requests to the >>> mailing >>> list, post regular updates of the document to get a chance to >>> everybody to >>> comment, ... >>> * All: please provide input to the Design Team and copy the >>> mailing list. >> >> JP, >> >> How does one join the design team? I would like to join. >> >> Phil >> _______________________________________________ >> Roll mailing list >> Roll@ietf.org >> https://www.ietf.org/mailman/listinfo/roll >> From alexandru.petrescu@gmail.com Fri Apr 10 04:09:36 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B634B3A68BF for ; Fri, 10 Apr 2009 04:09:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.166 X-Spam-Level: X-Spam-Status: No, score=-2.166 tagged_above=-999 required=5 tests=[AWL=0.083, 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 K+X+PIgpsiZf for ; Fri, 10 Apr 2009 04:09:35 -0700 (PDT) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.166.172.107]) by core3.amsl.com (Postfix) with ESMTP id 985F63A6853 for ; Fri, 10 Apr 2009 04:09:35 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.0) with ESMTP id n3ABACri001995 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 10 Apr 2009 13:10:12 +0200 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (8.14.2/8.14.2) with ESMTP id n3ABD9Ct003499; Fri, 10 Apr 2009 13:13:09 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.133.173]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id n3ABA7jU006962; Fri, 10 Apr 2009 13:10:11 +0200 Message-ID: <49DF2910.3050304@gmail.com> Date: Fri, 10 Apr 2009 13:10:08 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: JP Vasseur References: <0BD8BD8B-FD05-46E9-9AD4-7E9F312AAD21@cisco.com> <257B9AAC-B5A5-4141-86B6-0E04C5DA3DA9@cs.stanford.edu> <77f1dba80904092359v5bb941eeu2f2c6f3065954bfa@mail.gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: ROLL WG Subject: Re: [Roll] Formation of a Routing Protocol Design Team for ROLL X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Apr 2009 11:09:36 -0000 JP, I must say I was also a bit surprised to see a declaration of forming a DT... without it been mentioned at the last WG meeting. I doubt it is clear what the DT is going to produce, what is its goal, what is the starting document. The individual proposal documents (HYDRO, and thubert-fundamentals) that I think are related to this DT have _very_ few things in common. I am not sure there is any other proposal document which is supposed to be part of the DT scope. Another less clear aspect is the 6lowpan relationship: 6lowpan does link (but also 6lowpan ND does 'multi-hop'), and ROLL does routing (but also HYDRO does NS/NA)... What is the base doc of the DT? What are the docs considered by the DT? I also mean to say that I generally think that the DT as presented does seem to correspond to the IETF procedure, _is_ subject to the WG remarks, and may produce a good output, IMHO. Alex JP Vasseur a écrit : > Hi Eunah, > > On Apr 10, 2009, at 8:59 AM, Eunsook Eunah Kim wrote: > >> Hi JP, >> >> It' my pure question about design team. I only saw the case that WG >> decides to make a design team for a certain WG item when people >> agreed to have a design team in the meeting. And, chairmen askes >> volunteers for the DT. I never saw that DT has been just announced >> in the mailing list. (Well, i have only 10years experience in the >> ietf. Maybe it's possible but i never saw the case like this so >> far. Thus I feel a bit that there is inner-circle discussion in >> ROLL WG, which normal participants cannot share.) > > Not at all. We (co-chair) came up with a list of names. Such a > process is not unusual at all. Should you be interested you please > look at Section 6.5 of RFC 2418 > >> >> Please don't misunderstand me. I think the current design team >> members are great and I think the members are the best choice what >> ROLL could have for a ROLL routing solution. >> > > Thanks for the feed-back. > > Something really important: as pointed out in my first email the DT > has no special status and nobody should feel "excluded" ! We do need > to contribution of all ROLL contributors. Furthermore, the DT will > regularly poll the other members for feed-back, advise, ... and in > addition everybody is free to post its own proposal of course. > > Last but not least: there are many very valuable contributors of ROLL > that are purposely not part of the DT: it is also extremely > important to have non DT members providing inputs, contribution, ... > > Hope this help. > > Thanks. > > JP. > >> -eunah >> >> >> On Thu, Apr 9, 2009 at 6:11 AM, Philip Levis >> wrote: >>> On Apr 1, 2009, at 12:57 AM, JP Vasseur wrote: >>> >>>> Dear WG, >>>> >>>> We have formed a new Design Team in the ROLL Working Group. >>>> Please find below the charter and team members. >>>> >>>> Since some of you may not be familiar with the concept of a >>>> Design Team, I would like to remind a few points: >>>> >>>> * The work produced by a Design Team has no special status in >>>> the WG and is subject to WG consensus as any other individual >>>> submission * We ask the Design Team to request for input from >>>> the WG and to provide regular updates on the progress: please >>>> send input requests to the mailing list, post regular updates >>>> of the document to get a chance to everybody to comment, ... * >>>> All: please provide input to the Design Team and copy the >>>> mailing list. >>> >>> JP, >>> >>> How does one join the design team? I would like to join. >>> >>> Phil _______________________________________________ Roll mailing >>> list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll >>> > > _______________________________________________ Roll mailing list > Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll > From alexandru.petrescu@gmail.com Fri Apr 10 04:11: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 63A863A67EC for ; Fri, 10 Apr 2009 04:11:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.167 X-Spam-Level: X-Spam-Status: No, score=-2.167 tagged_above=-999 required=5 tests=[AWL=0.082, 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 7oHIkGisbeSl for ; Fri, 10 Apr 2009 04:11:15 -0700 (PDT) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.166.172.107]) by core3.amsl.com (Postfix) with ESMTP id 522953A6973 for ; Fri, 10 Apr 2009 04:11:15 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.0) with ESMTP id n3ABCJQk003823 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 10 Apr 2009 13:12:19 +0200 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (8.14.2/8.14.2) with ESMTP id n3ABFHkE003946; Fri, 10 Apr 2009 13:15:17 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.133.173]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id n3ABCHCs007409; Fri, 10 Apr 2009 13:12:19 +0200 Message-ID: <49DF2991.40503@gmail.com> Date: Fri, 10 Apr 2009 13:12:17 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: JP Vasseur References: <0BD8BD8B-FD05-46E9-9AD4-7E9F312AAD21@cisco.com> <257B9AAC-B5A5-4141-86B6-0E04C5DA3DA9@cs.stanford.edu> <77f1dba80904092359v5bb941eeu2f2c6f3065954bfa@mail.gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: ROLL WG Subject: Re: [Roll] Formation of a Routing Protocol Design Team for ROLL X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Apr 2009 11:11:16 -0000 JP, Other IETF Design Teams have their email list public read access (private write access) - this is pretty much useful to follow up what's going on. Is it the case of the ROLL DT? Are the archives available somewhere? Thanks, Alex JP Vasseur a écrit : > Hi Eunah, > > On Apr 10, 2009, at 8:59 AM, Eunsook Eunah Kim wrote: > >> Hi JP, >> >> It' my pure question about design team. >> I only saw the case that WG decides to make a design team for a >> certain WG item when people agreed to have a design team in the >> meeting. And, chairmen askes volunteers for the DT. >> I never saw that DT has been just announced in the mailing list. >> (Well, i have only 10years experience in the ietf. Maybe it's possible >> but i never saw the case like this so far. Thus I feel a bit that >> there is inner-circle discussion in ROLL WG, which normal participants >> cannot share.) > > Not at all. We (co-chair) came up with a list of names. Such a process > is not > unusual at all. Should you be interested you please look at Section 6.5 > of RFC 2418 > >> >> Please don't misunderstand me. I think the current design team members >> are great and >> I think the members are the best choice what ROLL could have for a >> ROLL routing solution. >> > > Thanks for the feed-back. > > Something really important: as pointed out in my first email the DT has > no special status > and nobody should feel "excluded" ! We do need to contribution of all > ROLL contributors. > Furthermore, the DT will regularly poll the other members for feed-back, > advise, ... and in > addition everybody is free to post its own proposal of course. > > Last but not least: there are many very valuable contributors of ROLL > that are purposely not part > of the DT: it is also extremely important to have non DT members > providing inputs, contribution, ... > > Hope this help. > > Thanks. > > JP. > >> -eunah >> >> >> On Thu, Apr 9, 2009 at 6:11 AM, Philip Levis wrote: >>> On Apr 1, 2009, at 12:57 AM, JP Vasseur wrote: >>> >>>> Dear WG, >>>> >>>> We have formed a new Design Team in the ROLL Working Group. Please find >>>> below the charter and team members. >>>> >>>> Since some of you may not be familiar with the concept of a Design >>>> Team, I >>>> would like to remind a few points: >>>> >>>> * The work produced by a Design Team has no special status in the WG >>>> and >>>> is subject to WG consensus as any other individual submission >>>> * We ask the Design Team to request for input from the WG and to >>>> provide >>>> regular updates on the progress: please send input requests to the >>>> mailing >>>> list, post regular updates of the document to get a chance to >>>> everybody to >>>> comment, ... >>>> * All: please provide input to the Design Team and copy the mailing >>>> list. >>> >>> JP, >>> >>> How does one join the design team? I would like to join. >>> >>> Phil >>> _______________________________________________ >>> Roll mailing list >>> Roll@ietf.org >>> https://www.ietf.org/mailman/listinfo/roll >>> > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > From cabo@tzi.org Fri Apr 10 04:50:33 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 30BC13A68BF for ; Fri, 10 Apr 2009 04:50:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W2MZ9PJIAZer for ; Fri, 10 Apr 2009 04:50:32 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9:209:3dff:fe00:7136]) by core3.amsl.com (Postfix) with ESMTP id 0F5863A693F for ; Fri, 10 Apr 2009 04:50:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.2/8.14.2) with ESMTP id n3ABpNi9020540; Fri, 10 Apr 2009 13:51:23 +0200 (CEST) Received: from [192.168.217.107] (p5489DD1C.dip.t-dialin.net [84.137.221.28]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTP id 9E6B71704D7; Fri, 10 Apr 2009 13:51:23 +0200 (CEST) From: Carsten Bormann To: Alexandru Petrescu In-Reply-To: <49DF2910.3050304@gmail.com> References: <0BD8BD8B-FD05-46E9-9AD4-7E9F312AAD21@cisco.com> <257B9AAC-B5A5-4141-86B6-0E04C5DA3DA9@cs.stanford.edu> <77f1dba80904092359v5bb941eeu2f2c6f3065954bfa@mail.gmail.com> <49DF2910.3050304@gmail.com> Message-Id: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Fri, 10 Apr 2009 13:51:22 +0200 X-Mailer: Apple Mail (2.930.3) Cc: ROLL WG Subject: [Roll] 6lowpan-ND vs. ROLL (Re: Formation of a Routing Protocol Design Team for ROLL) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Apr 2009 11:50:33 -0000 On Apr 10, 2009, at 13:10, Alexandru Petrescu wrote: > Another less clear aspect is the 6lowpan relationship: 6lowpan does > link > (but also 6lowpan ND does 'multi-hop'), and ROLL does routing (but > also > HYDRO does NS/NA)... Well, let's work on this relationship then. 6lowpan-nd strictly is about maintaining the router-host relationship. (Some confusion about this previously well-defined term may come in when a router wants to bootstrap in a host role before going router.) 6lowpan-nd mentions "multi-hop" in two places: -- in the definitions of "6LoWPAN node", "mesh-under" and "route- over", and related explanatory introductions. -- in the "Multi-Hop Information Option". The latter provides for an optimization that "allows for the full set of prefix information options to be sent only periodically in unsolicited RAs". You could argue whether the name of the option is that great; the point here is that ND information has to percolate through the whole LoWPAN and not just on a single link, and that adding a sequence number can make this percolation much more efficient. There is also a discussion in 6lowpan-nd about a way for a router to indicate to hosts some form of preference in an RA. There were proposals to make this depend on a hop-count (which would work best with routing protocols where hop-counts are an important metric), but I think we are arriving at a more general solution. I think some confusion may come from the term "neighbor". In ND this really means "peer on the link that I (want to) know the L2 address and liveliness of". In routing protocols that means "node I can directly communicate with and may want to exchange routing information with". Historically, those two meanings were very close. With the more complex link models we are going to, there is a big difference. MANET has started calling the second kind of relationship "neighborhood" in order to have two different terms. Gruesse, Carsten From alexandru.petrescu@gmail.com Fri Apr 10 06:43: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 770B23A6DDE for ; Fri, 10 Apr 2009 06:43:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.168 X-Spam-Level: X-Spam-Status: No, score=-2.168 tagged_above=-999 required=5 tests=[AWL=0.081, 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 FtYRRWdsO+hp for ; Fri, 10 Apr 2009 06:43:36 -0700 (PDT) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.1]) by core3.amsl.com (Postfix) with ESMTP id 5E1FE3A6E32 for ; Fri, 10 Apr 2009 06:43:36 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.0) with ESMTP id n3ADgg3v002391 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 10 Apr 2009 15:42:42 +0200 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (8.14.2/8.14.2) with ESMTP id n3ADlccY015381; Fri, 10 Apr 2009 15:47:38 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.133.173]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id n3ADiSTW024423; Fri, 10 Apr 2009 15:44:40 +0200 Message-ID: <49DF4D3C.6040702@gmail.com> Date: Fri, 10 Apr 2009 15:44:28 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Carsten Bormann References: <0BD8BD8B-FD05-46E9-9AD4-7E9F312AAD21@cisco.com> <257B9AAC-B5A5-4141-86B6-0E04C5DA3DA9@cs.stanford.edu> <77f1dba80904092359v5bb941eeu2f2c6f3065954bfa@mail.gmail.com> <49DF2910.3050304@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: ROLL WG Subject: Re: [Roll] 6lowpan-ND vs. ROLL X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Apr 2009 13:43:37 -0000 Hi, let me take advantage of this to talk about the 6lowpan ND document. Carsten Bormann a écrit : > On Apr 10, 2009, at 13:10, Alexandru Petrescu wrote: [...] > 6lowpan-nd mentions "multi-hop" in two places: > > -- in the definitions of "6LoWPAN node", "mesh-under" and > "route-over", and related explanatory introductions. -- in the > "Multi-Hop Information Option". > > The latter provides for an optimization that "allows for the full set > of prefix information options to be sent only periodically in > unsolicited RAs". But the full set of PIOs is _always_ sent periodically in unsolicited RAs, anyways. Does it mean some options are sent some times, and some other options other times? If yes - what does this have to do with 'multi-hop' at all. > You could argue whether the name of the option is that great; YEs - I argue. By your explanation it should be better called "sequence number tagging information option" and less a "multi-hop information option". > the point here is that ND information has to percolate through the > whole LoWPAN and not just on a single link, and that adding a > sequence number can make this percolation much more efficient. But I thought the entire lowpan is a subnet is a link (the link-scope multicast covers the entire lowpan subnet). Whereas you seem to mean the whole LoWPAN is not just a single link... The 'percolation' seems to be new. Some contradictory but sparsed paragraphs: > This document also specifies the seamless integration of an extended > LoWPAN and multiple edge routers on a shared backbone link (e.g. > Ethernet) to form a single IPv6 subnet. So both the entire lowpan and the ER's egress interface form a single IPv6 subnet. > The link-local scope is defined by a LoWPAN link, which > includes nodes reachable over a single radio transmission at each > instant. But a single IPv6 subnet is the link-local scope, and Ethernet is wired, so does the link-local scope cover the Ethernet as well? > As a result, > we extend ND as specified in [RFC4861] to operate over an entire > LoWPAN subnet, rather than a single IP link. "Rather"? But I thought the entire link is an IP subnet is an IP link. > In mesh under, each intermidiate > node performs multi-hop forwarding at L2. In route over, each > intermidiate node serves as a LoWPAN router performing IP routing. It is not clear if the text means by IP routing a typical routing between two subnets with a routing table and a longest-prefix match search and two interfaces, or a _new_ "IP" routing. > Note that routers only exist > in route over networks, and in mesh under networks nodes are on the > same link with edge routers. ... and route over networks are routing between subnets, whereas here we only have one subnet. Can one "IP route" between a single IP subnet? > With the backhaul model, in a mesh under network the link and subnet > are equivalent as the link spans the entire LoWPAN. But do you mean when there's no backhaul model the link and subnet are not equivalent? > In this document, a LoWPAN subnet is defined to be a collection of > LoWPAN links interconnected by routers that have the same subnet > prefix. Let's exemplify collection with two members: How does a router connect two links, yet has a single interface, and has the same subnet prefix on both (on both "what")? Is that a "bridge" actually? Is that a dumb repeater? Is that an application-layer (UDP) repeating all packets it receives? (no routing table entry, only one interface). Alex PS: paragraphs below worth discussing one day: C. Bormann wrote: > There is also a discussion in 6lowpan-nd about a way for a router to > indicate to hosts some form of preference in an RA. There were > proposals to make this depend on a hop-count (which would work best > with routing protocols where hop-counts are an important metric), but > I think we are arriving at a more general solution. > > I think some confusion may come from the term "neighbor". In ND this > really means "peer on the link that I (want to) know the L2 address > and liveliness of". In routing protocols that means "node I can > directly communicate with and may want to exchange routing > information with". Historically, those two meanings were very close. > With the more complex link models we are going to, there is a big > difference. MANET has started calling the second kind of relationship > "neighborhood" in order to have two different terms. > > Gruesse, Carsten > > From pal@cs.stanford.edu Fri Apr 10 06:50: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 321E43A697A for ; Fri, 10 Apr 2009 06:50:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.592 X-Spam-Level: X-Spam-Status: No, score=-6.592 tagged_above=-999 required=5 tests=[AWL=0.007, 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 XFgH5aSQnqE0 for ; Fri, 10 Apr 2009 06:50:56 -0700 (PDT) Received: from cs-smtp-3.Stanford.EDU (cs-smtp-3.Stanford.EDU [171.64.64.27]) by core3.amsl.com (Postfix) with ESMTP id 3F4F63A6806 for ; Fri, 10 Apr 2009 06:50:56 -0700 (PDT) Received: from [76.14.71.8] (helo=[192.168.1.103]) by cs-smtp-3.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1LsH9I-0003fB-Hv; Fri, 10 Apr 2009 06:52:05 -0700 Message-Id: From: Philip Levis To: Pascal Thubert (pthubert) In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FC074276FB@xmb-ams-337.emea.cisco.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Fri, 10 Apr 2009 06:52:04 -0700 References: <7892795E1A87F04CADFCCF41FADD00FC074276FB@xmb-ams-337.emea.cisco.com> X-Mailer: Apple Mail (2.930.3) X-Scan-Signature: 67f4a389e065da33eb5969ecb4726704 Cc: roll@ietf.org Subject: Re: [Roll] FW: New Version Notification for draft-thubert-roll-fundamentals-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: Fri, 10 Apr 2009 13:50:57 -0000 On Apr 9, 2009, at 1:59 AM, Pascal Thubert (pthubert) wrote: > 1) This contribution details the formation of a Distance Vector tree > using ND extensions; most existing contributions to this WG suggest > that approach (Teco's BRDP, Arsalan & al. 's Hydro's Default Route > Formation, Phil & al. Usenix paper's Tree based routing...) and the > value we provide here is more refined details on such operation, to > address for instance merging and splitting of trees or the > integration with the 6LoWPAN backbone. It's worth noting that the networking abstractions paper is, at this point, 5 years old. Protocols have progressed a lot since then. And I think it's safe to say that the statements of "IP doesn't seem to be useful" should be "at that time, we didn't think IP would be useful and gosh were we wrong!" > Basically, since we have a depth, we have feasible parents (of > lesser depth) and siblings (of same depth). The draft suggests that > we can select any parent to forward on a per packet basis using the > best metric or more advanced load balancing functionality; if that > fails then we can use a sibling with some basic loop avoidance like > poison return or more advanced path vector (for hydrophiles). Here's a URL to a paper that describes one way to solve this problem, using the techniques I mentioned a few weeks ago and touched on in my talk in SF: http://sing.stanford.edu/pubs/ctp.pdf The source code for CTP (the tree protocol in the paper) is part of a TinyOS release and is under a BSD license. It can be found at http://www.tinyos.net/tinyos-2.x/tos/lib/net/ctp/ Phil From cabo@tzi.org Fri Apr 10 09:59: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 A5E1C3A69E1 for ; Fri, 10 Apr 2009 09:59:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9FwaF534VjOm for ; Fri, 10 Apr 2009 09:59:46 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9:209:3dff:fe00:7136]) by core3.amsl.com (Postfix) with ESMTP id 646A73A682D for ; Fri, 10 Apr 2009 09:59:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.2/8.14.2) with ESMTP id n3AH0hKa019995; Fri, 10 Apr 2009 19:00:43 +0200 (CEST) Received: from [192.168.217.107] (p5489BFA1.dip.t-dialin.net [84.137.191.161]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTP id 4C32A1704D7; Fri, 10 Apr 2009 19:00:43 +0200 (CEST) From: Carsten Bormann To: Alexandru Petrescu In-Reply-To: <49DF4D3C.6040702@gmail.com> References: <0BD8BD8B-FD05-46E9-9AD4-7E9F312AAD21@cisco.com> <257B9AAC-B5A5-4141-86B6-0E04C5DA3DA9@cs.stanford.edu> <77f1dba80904092359v5bb941eeu2f2c6f3065954bfa@mail.gmail.com> <49DF2910.3050304@gmail.com> <49DF4D3C.6040702@gmail.com> Message-Id: <406F3572-344F-4DE1-863D-F3F2743416AF@tzi.org> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Fri, 10 Apr 2009 19:00:42 +0200 X-Mailer: Apple Mail (2.930.3) Cc: ROLL WG Subject: Re: [Roll] 6lowpan-ND vs. ROLL X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Apr 2009 16:59:47 -0000 On Apr 10, 2009, at 15:44, Alexandru Petrescu wrote: > Hi, let me take advantage of this to talk about the 6lowpan ND > document. Well, we should have the detailed discussion of the ND specific aspects on the 6lowpan list, please. However, we do need to have agreement between the ROLL WG (as a purveyor of routing protocols) and the 6lowpan WG on this point about the model we are using: > Can one "IP route" between a single IP subnet? Yes. That is a result of the definition of "subnet" and "route-over" that we have arrived at. This is the point of section 5 of draft-ietf-6lowpan-nd-02. (If you think that routing within a subnet is not something that immediately comes to mind when hearing "route-over", I'm with you, but again that is the current terminology.) >> With the backhaul model, in a mesh under network the link and >> subnet >> are equivalent as the link spans the entire LoWPAN. > > But do you mean when there's no backhaul model (I don't tend to think about the case where there is no Edge Router -- is that what you mean?) > the link and subnet are not equivalent? In a pure mesh-under world (which the cited text is talking about), they are equivalent -- making them equivalent is exactly the job of a full mesh-under protocol. In a route-over world (with or without embedded mesh-under islands), they aren't. >> In this document, a LoWPAN subnet is defined to be a collection of >> LoWPAN links interconnected by routers that have the same subnet >> prefix. > > Let's exemplify collection with two members: > > How does a router connect two links, yet has a single interface, and > has the same subnet prefix on both (on both "what")? ("Two links" sounds as if the extent of a "link" is independent from one's point of view, which in a radio network it isn't. A 6lowpan node typically has exactly one interface and thus one link.) By making the on-link decision (i.e., L2-address the host via ND vs. L2-address the next-hop router via the routing protocol) based on the routing information instead of just using the prefix. > Is that a "bridge" actually? No. No MAC address learning is involved. > Is that a dumb repeater? No. Forwarding of a packet received is based on L2 address matching (possibly followed by reassembly) followed by a consultation of the L3 FIB. > Is that an application-layer (UDP) repeating all packets it > receives? (no routing table entry, only one interface). No. The forwarding is at L3, e.g., no interpretation of IPv6 fragment headers or destination options headers is involved in the forwarding. Gruesse, Carsten From richard.kelsey@ember.com Fri Apr 10 10:56: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 C3F423A6944 for ; Fri, 10 Apr 2009 10:56:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C0lMGA8O5RYP for ; Fri, 10 Apr 2009 10:56:04 -0700 (PDT) Received: from EMPIRE.hq.ember.com (mail.ember.com [74.10.175.227]) by core3.amsl.com (Postfix) with ESMTP id D1A4B3A6928 for ; Fri, 10 Apr 2009 10:55:46 -0700 (PDT) Received: from kelsey-ws.hq.ember.com ([192.168.81.55]) by EMPIRE.hq.ember.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 10 Apr 2009 13:57:39 -0400 Received: from kelsey-ws.hq.ember.com (localhost.localdomain [127.0.0.1]) by kelsey-ws.hq.ember.com (8.13.4/8.13.4) with ESMTP id n3AHusKs022897; Fri, 10 Apr 2009 13:56:54 -0400 Received: (from kelsey@localhost) by kelsey-ws.hq.ember.com (8.13.4/8.12.8/Submit) id n3AHusWx022894; Fri, 10 Apr 2009 13:56:54 -0400 Date: Fri, 10 Apr 2009 13:56:54 -0400 Message-Id: <200904101756.n3AHusWx022894@kelsey-ws.hq.ember.com> To: pal@cs.stanford.edu In-reply-to: (message from Philip Levis on Fri, 10 Apr 2009 06:52:04 -0700) From: Richard Kelsey References: <7892795E1A87F04CADFCCF41FADD00FC074276FB@xmb-ams-337.emea.cisco.com> X-OriginalArrivalTime: 10 Apr 2009 17:57:39.0845 (UTC) FILETIME=[D6D1DB50:01C9BA05] Cc: roll@ietf.org Subject: Re: [Roll] FW: New Version Notification for draft-thubert-roll-fundamentals-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: Fri, 10 Apr 2009 17:56:05 -0000 From: Philip Levis Date: Fri, 10 Apr 2009 06:52:04 -0700 On Apr 9, 2009, at 1:59 AM, Pascal Thubert (pthubert) wrote: > Basically, since we have a depth, we have feasible parents (of > lesser depth) and siblings (of same depth). The draft suggests that > we can select any parent to forward on a per packet basis using the > best metric or more advanced load balancing functionality; if that > fails then we can use a sibling with some basic loop avoidance like > poison return or more advanced path vector (for hydrophiles). Here's a URL to a paper that describes one way to solve this problem, using the techniques I mentioned a few weeks ago and touched on in my talk in SF: http://sing.stanford.edu/pubs/ctp.pdf Good stuff. Relating this back to the Routing Fundamentals draft, it seems clear that ROLL will most likely use trees for at least some routing, and while Router Advertisements can be used to build trees, it will be good if tree building and/or maintenance can be performed independently of Router Advertisements. They add too much overhead to make it easy to react quickly to changing conditions. -Richard Kelsey From alexandru.petrescu@gmail.com Fri Apr 10 11:11: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 D3E573A6C22 for ; Fri, 10 Apr 2009 11:11:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.025 X-Spam-Level: X-Spam-Status: No, score=-2.025 tagged_above=-999 required=5 tests=[AWL=0.224, 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 Ktvd5qDmmyhp for ; Fri, 10 Apr 2009 11:11:35 -0700 (PDT) Received: from smtp6-g21.free.fr (smtp6-g21.free.fr [212.27.42.6]) by core3.amsl.com (Postfix) with ESMTP id 6BED53A6CD7 for ; Fri, 10 Apr 2009 11:11:31 -0700 (PDT) Received: from smtp6-g21.free.fr (localhost [127.0.0.1]) by smtp6-g21.free.fr (Postfix) with ESMTP id 9578AE080FB; Fri, 10 Apr 2009 20:12:36 +0200 (CEST) Received: from [127.0.0.1] (bur91-3-82-239-213-32.fbx.proxad.net [82.239.213.32]) by smtp6-g21.free.fr (Postfix) with ESMTP id 80197E08106; Fri, 10 Apr 2009 20:12:33 +0200 (CEST) Message-ID: <49DF8C10.3030604@gmail.com> Date: Fri, 10 Apr 2009 20:12:32 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Carsten Bormann References: <0BD8BD8B-FD05-46E9-9AD4-7E9F312AAD21@cisco.com> <257B9AAC-B5A5-4141-86B6-0E04C5DA3DA9@cs.stanford.edu> <77f1dba80904092359v5bb941eeu2f2c6f3065954bfa@mail.gmail.com> <49DF2910.3050304@gmail.com> <49DF4D3C.6040702@gmail.com> <406F3572-344F-4DE1-863D-F3F2743416AF@tzi.org> In-Reply-To: <406F3572-344F-4DE1-863D-F3F2743416AF@tzi.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: ROLL WG Subject: Re: [Roll] 6lowpan-ND vs. ROLL X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Apr 2009 18:11:35 -0000 Carsten, Thank you for the clarifications mentioned below (single-interface router is not a bridge/repeater and with the definition of subnet arrived at). I will try to clarify further on the 6lowpan list. Alex Carsten Bormann a écrit : > On Apr 10, 2009, at 15:44, Alexandru Petrescu wrote: > >> Hi, let me take advantage of this to talk about the 6lowpan ND document. > > Well, we should have the detailed discussion of the ND specific aspects > on the 6lowpan list, please. > > However, we do need to have agreement between the ROLL WG (as a purveyor > of routing protocols) and the 6lowpan WG on this point about the model > we are using: > >> Can one "IP route" between a single IP subnet? > > Yes. That is a result of the definition of "subnet" and "route-over" > that we have arrived at. > This is the point of section 5 of draft-ietf-6lowpan-nd-02. > > (If you think that routing within a subnet is not something that > immediately comes to mind when hearing "route-over", I'm with you, but > again that is the current terminology.) > >>> With the backhaul model, in a mesh under network the link and subnet >>> are equivalent as the link spans the entire LoWPAN. >> >> But do you mean when there's no backhaul model > > (I don't tend to think about the case where there is no Edge Router -- > is that what you mean?) > >> the link and subnet are not equivalent? > > In a pure mesh-under world (which the cited text is talking about), they > are equivalent -- making them equivalent is exactly the job of a full > mesh-under protocol. > In a route-over world (with or without embedded mesh-under islands), > they aren't. > >>> In this document, a LoWPAN subnet is defined to be a collection of >>> LoWPAN links interconnected by routers that have the same subnet >>> prefix. >> >> Let's exemplify collection with two members: >> >> How does a router connect two links, yet has a single interface, and >> has the same subnet prefix on both (on both "what")? > > ("Two links" sounds as if the extent of a "link" is independent from > one's point of view, which in a radio network it isn't. A 6lowpan node > typically has exactly one interface and thus one link.) > By making the on-link decision (i.e., L2-address the host via ND vs. > L2-address the next-hop router via the routing protocol) based on the > routing information instead of just using the prefix. > >> Is that a "bridge" actually? > > No. No MAC address learning is involved. > >> Is that a dumb repeater? > > No. Forwarding of a packet received is based on L2 address matching > (possibly followed by reassembly) followed by a consultation of the L3 FIB. > >> Is that an application-layer (UDP) repeating all packets it receives? >> (no routing table entry, only one interface). > > No. The forwarding is at L3, e.g., no interpretation of IPv6 fragment > headers or destination options headers is involved in the forwarding. > > Gruesse, Carsten > > From richard.kelsey@ember.com Fri Apr 10 13:00:13 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 A549D3A6D93 for ; Fri, 10 Apr 2009 13:00:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 12zshLV3b8sY for ; Fri, 10 Apr 2009 13:00:12 -0700 (PDT) Received: from EMPIRE.hq.ember.com (mail.ember.com [74.10.175.227]) by core3.amsl.com (Postfix) with ESMTP id BCE1A3A6D91 for ; Fri, 10 Apr 2009 13:00:12 -0700 (PDT) Received: from kelsey-ws.hq.ember.com ([192.168.81.55]) by EMPIRE.hq.ember.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 10 Apr 2009 16:02:05 -0400 Received: from kelsey-ws.hq.ember.com (localhost.localdomain [127.0.0.1]) by kelsey-ws.hq.ember.com (8.13.4/8.13.4) with ESMTP id n3AK1KtW023961; Fri, 10 Apr 2009 16:01:20 -0400 Received: (from kelsey@localhost) by kelsey-ws.hq.ember.com (8.13.4/8.12.8/Submit) id n3AK1KD4023958; Fri, 10 Apr 2009 16:01:20 -0400 Date: Fri, 10 Apr 2009 16:01:20 -0400 Message-Id: <200904102001.n3AK1KD4023958@kelsey-ws.hq.ember.com> To: cabo@tzi.org In-reply-to: <406F3572-344F-4DE1-863D-F3F2743416AF@tzi.org> (message from Carsten Bormann on Fri, 10 Apr 2009 19:00:42 +0200) From: Richard Kelsey References: <0BD8BD8B-FD05-46E9-9AD4-7E9F312AAD21@cisco.com> <257B9AAC-B5A5-4141-86B6-0E04C5DA3DA9@cs.stanford.edu> <77f1dba80904092359v5bb941eeu2f2c6f3065954bfa@mail.gmail.com> <49DF2910.3050304@gmail.com> <49DF4D3C.6040702@gmail.com> <406F3572-344F-4DE1-863D-F3F2743416AF@tzi.org> X-OriginalArrivalTime: 10 Apr 2009 20:02:05.0787 (UTC) FILETIME=[38DE32B0:01C9BA17] Cc: roll@ietf.org Subject: Re: [Roll] 6lowpan-ND vs. ROLL X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Apr 2009 20:00:13 -0000 From: Carsten Bormann Date: Fri, 10 Apr 2009 19:00:42 +0200 (I don't tend to think about the case where there is no Edge Router -- ...) I have a question on this, stemming from my lack of familiarity with the details of IP routing. Suppose I have a 6LowPAN/ROLL network being used for energy management in a home. The network includes the electric meter, which has a backhaul connection back to the utility. The utility, being very protective of its backhaul network, has a firewall in the meter to keep out everything except the utility's own traffic. Given the presence of the firewall, does it still make sense to use the meter as an Edge Router? -Richard Kelsey From richard.kelsey@ember.com Fri Apr 10 13:43: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 372D93A6B71 for ; Fri, 10 Apr 2009 13:43:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qG2JB8N4TnRi for ; Fri, 10 Apr 2009 13:43:27 -0700 (PDT) Received: from EMPIRE.hq.ember.com (mail.ember.com [74.10.175.227]) by core3.amsl.com (Postfix) with ESMTP id 546633A6C13 for ; Fri, 10 Apr 2009 13:43:27 -0700 (PDT) Received: from kelsey-ws.hq.ember.com ([192.168.81.55]) by EMPIRE.hq.ember.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 10 Apr 2009 16:45:20 -0400 Received: from kelsey-ws.hq.ember.com (localhost.localdomain [127.0.0.1]) by kelsey-ws.hq.ember.com (8.13.4/8.13.4) with ESMTP id n3AKiZCG024346; Fri, 10 Apr 2009 16:44:35 -0400 Received: (from kelsey@localhost) by kelsey-ws.hq.ember.com (8.13.4/8.12.8/Submit) id n3AKiZSC024343; Fri, 10 Apr 2009 16:44:35 -0400 Date: Fri, 10 Apr 2009 16:44:35 -0400 Message-Id: <200904102044.n3AKiZSC024343@kelsey-ws.hq.ember.com> To: geoff@proto6.com In-reply-to: <1239394271.6458.3451.camel@DellX1> (message from Geoff Mulligan on Fri, 10 Apr 2009 14:11:11 -0600) From: Richard Kelsey References: <0BD8BD8B-FD05-46E9-9AD4-7E9F312AAD21@cisco.com> <257B9AAC-B5A5-4141-86B6-0E04C5DA3DA9@cs.stanford.edu> <77f1dba80904092359v5bb941eeu2f2c6f3065954bfa@mail.gmail.com> <49DF2910.3050304@gmail.com> <49DF4D3C.6040702@gmail.com> <406F3572-344F-4DE1-863D-F3F2743416AF@tzi.org> <200904102001.n3AK1KD4023958@kelsey-ws.hq.ember.com> <1239394271.6458.3451.camel@DellX1> X-OriginalArrivalTime: 10 Apr 2009 20:45:20.0878 (UTC) FILETIME=[43A9A8E0:01C9BA1D] Cc: roll@ietf.org Subject: Re: [Roll] 6lowpan-ND vs. ROLL X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Apr 2009 20:43:28 -0000 From: Geoff Mulligan Date: Fri, 10 Apr 2009 14:11:11 -0600 On Fri, 2009-04-10 at 16:01 -0400, Richard Kelsey wrote: > From: Carsten Bormann > Date: Fri, 10 Apr 2009 19:00:42 +0200 > > (I don't tend to think about the case where there is no > Edge Router -- ...) > > I have a question on this, stemming from my lack of > familiarity with the details of IP routing. > > Suppose I have a 6LowPAN/ROLL network being used for energy > management in a home. The network includes the electric > meter, which has a backhaul connection back to the utility. > The utility, being very protective of its backhaul network, > has a firewall in the meter to keep out everything except > the utility's own traffic. Given the presence of the > firewall, does it still make sense to use the meter as an > Edge Router? yes as an edge router for the in home devices connected to the utilities network. Thanks for the quick response. >From the LLN Routing Fundamentals draft, the meter would then make itself the root of a grounded tree. Would it set the Default flag in the TIO? What if another Edge Router with a less-restrictive backhaul, via an ISP perhaps, is added to the home network? As long as the meter is the only Edge Router it makes sense to have it be the default. What happens when the second one is added isn't clear to me. I expect this may turn out to be a common arrangement, with the second Edge Router being a third-party energy management device. -Richard Kelsey From alexandru.petrescu@gmail.com Fri Apr 10 13:52:48 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 48AE23A680C for ; Fri, 10 Apr 2009 13:52:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.035 X-Spam-Level: X-Spam-Status: No, score=-2.035 tagged_above=-999 required=5 tests=[AWL=0.214, 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 4esgiT8d9FJ3 for ; Fri, 10 Apr 2009 13:52:47 -0700 (PDT) Received: from smtp2-g21.free.fr (smtp2-g21.free.fr [212.27.42.2]) by core3.amsl.com (Postfix) with ESMTP id 5E6AC3A68EC for ; Fri, 10 Apr 2009 13:52:45 -0700 (PDT) Received: from smtp2-g21.free.fr (localhost [127.0.0.1]) by smtp2-g21.free.fr (Postfix) with ESMTP id B254B4B0103; Fri, 10 Apr 2009 22:53:50 +0200 (CEST) Received: from [127.0.0.1] (bur91-3-82-239-213-32.fbx.proxad.net [82.239.213.32]) by smtp2-g21.free.fr (Postfix) with ESMTP id 9E84B4B00BC; Fri, 10 Apr 2009 22:53:47 +0200 (CEST) Message-ID: <49DFB1DB.3040602@gmail.com> Date: Fri, 10 Apr 2009 22:53:47 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Richard Kelsey References: <0BD8BD8B-FD05-46E9-9AD4-7E9F312AAD21@cisco.com> <257B9AAC-B5A5-4141-86B6-0E04C5DA3DA9@cs.stanford.edu> <77f1dba80904092359v5bb941eeu2f2c6f3065954bfa@mail.gmail.com> <49DF2910.3050304@gmail.com> <49DF4D3C.6040702@gmail.com> <406F3572-344F-4DE1-863D-F3F2743416AF@tzi.org> <200904102001.n3AK1KD4023958@kelsey-ws.hq.ember.com> In-Reply-To: <200904102001.n3AK1KD4023958@kelsey-ws.hq.ember.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: roll@ietf.org Subject: Re: [Roll] 6lowpan-ND vs. ROLL X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Apr 2009 20:52:48 -0000 Richard Kelsey a écrit : > From: Carsten Bormann > Date: Fri, 10 Apr 2009 19:00:42 +0200 > > (I don't tend to think about the case where there is no > Edge Router -- ...) > > I have a question on this, stemming from my lack of > familiarity with the details of IP routing. > > Suppose I have a 6LowPAN/ROLL network being used for energy > management in a home. The network includes the electric > meter, which has a backhaul connection back to the utility. > The utility, being very protective of its backhaul network, > has a firewall in the meter to keep out everything except > the utility's own traffic. Given the presence of the > firewall, does it still make sense to use the meter as an > Edge Router? I don't think it would make much sense because Edge Router as currently specified by 6LoWPAN ND seems to not be doing any routing at all - but a sort of bridging, and firewalls are very much rules on the IP fields, and less if at all rules on the MAC fields. I doubt Utility would be happy with Client meter bridging all sensor traffic into the backhaul, or otherwise filtered by huge tables of MAC filter rules... Alex > -Richard Kelsey > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > From zach@sensinode.com Sat Apr 11 00:07: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 772513A6807 for ; Sat, 11 Apr 2009 00:07:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.524 X-Spam-Level: X-Spam-Status: No, score=-3.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DypUT1V3qH6Z for ; Sat, 11 Apr 2009 00:06:49 -0700 (PDT) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by core3.amsl.com (Postfix) with ESMTP id 1C8D93A694D for ; Sat, 11 Apr 2009 00:06:48 -0700 (PDT) Received: from snl-zach.local ([62.145.172.50]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.4/8.13.4) with ESMTP id n3B76ois032638 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 11 Apr 2009 10:06:51 +0300 Message-ID: <49E041A2.9020206@sensinode.com> Date: Sat, 11 Apr 2009 10:07:14 +0300 From: Zach Shelby User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Richard Kelsey References: <7892795E1A87F04CADFCCF41FADD00FC074276FB@xmb-ams-337.emea.cisco.com> <200904101756.n3AHusWx022894@kelsey-ws.hq.ember.com> In-Reply-To: <200904101756.n3AHusWx022894@kelsey-ws.hq.ember.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: roll@ietf.org Subject: Re: [Roll] FW: New Version Notification for draft-thubert-roll-fundamentals-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: Sat, 11 Apr 2009 07:07:24 -0000 Richard, Richard Kelsey wrote: > From: Philip Levis > Date: Fri, 10 Apr 2009 06:52:04 -0700 > > On Apr 9, 2009, at 1:59 AM, Pascal Thubert (pthubert) wrote: > > > Basically, since we have a depth, we have feasible parents (of > > lesser depth) and siblings (of same depth). The draft suggests that > > we can select any parent to forward on a per packet basis using the > > best metric or more advanced load balancing functionality; if that > > fails then we can use a sibling with some basic loop avoidance like > > poison return or more advanced path vector (for hydrophiles). > > Here's a URL to a paper that describes one way to solve this problem, > using the techniques I mentioned a few weeks ago and touched on in my > talk in SF: > > http://sing.stanford.edu/pubs/ctp.pdf > > Good stuff. Relating this back to the Routing Fundamentals > draft, it seems clear that ROLL will most likely use trees > for at least some routing, and while Router Advertisements > can be used to build trees, it will be good if tree > building and/or maintenance can be performed independently > of Router Advertisements. They add too much overhead > to make it easy to react quickly to changing conditions. Don't think of router advertisements as overhead - as we are working with IP networks you will always have RAs as they are an integral part of network bootstrapping and maintenance (Neighbor Discovery). As you have RAs anyways, you might as well piggyback some tree information. Trickle can also be used to optimize the RA traffic to an appropriate level. The same can be said about other ND traffic in these networks such as NS/NAs (IPv6), or RR/RCs (in 6LoWPAN). If you have the ND traffic anyways, piggybacking is good. That said, I do see the need for carrying metric information (as done in the CTP protocol Phil is referencing) in data traffic (using an IPv6 hop-by-hop option) especially for very dynamic networks. I had this in mind when we wrote the Routing Fundamentals draft as an option. From my practical experience it is useful, and only needs to be applied to 1-10% of data packets depending on how dynamic the network is. - Zach > -Richard Kelsey > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll -- http://zachshelby.org - My blog “On the Internet of Things” Mobile: +358 40 7796297 Zach Shelby Head of Research Sensinode Ltd. Kidekuja 2 88610 Vuokatti, FINLAND This e-mail and all attached material are confidential and may contain legally privileged information. If you are not the intended recipient, please contact the sender and delete the e-mail from your system without producing, distributing or retaining copies thereof. From zach@sensinode.com Sat Apr 11 00:09: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 1A7003A696B for ; Sat, 11 Apr 2009 00:09:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.539 X-Spam-Level: X-Spam-Status: No, score=-3.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i-oJajP9t1bK for ; Sat, 11 Apr 2009 00:09:31 -0700 (PDT) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by core3.amsl.com (Postfix) with ESMTP id E97533A6807 for ; Sat, 11 Apr 2009 00:09:30 -0700 (PDT) Received: from snl-zach.local ([62.145.172.50]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.4/8.13.4) with ESMTP id n3B7AaqZ032702 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 11 Apr 2009 10:10:36 +0300 Message-ID: <49E04284.6000900@sensinode.com> Date: Sat, 11 Apr 2009 10:11:00 +0300 From: Zach Shelby User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Alexandru Petrescu References: <0BD8BD8B-FD05-46E9-9AD4-7E9F312AAD21@cisco.com> <257B9AAC-B5A5-4141-86B6-0E04C5DA3DA9@cs.stanford.edu> <77f1dba80904092359v5bb941eeu2f2c6f3065954bfa@mail.gmail.com> <49DF2910.3050304@gmail.com> <49DF4D3C.6040702@gmail.com> <406F3572-344F-4DE1-863D-F3F2743416AF@tzi.org> <200904102001.n3AK1KD4023958@kelsey-ws.hq.ember.com> <49DFB1DB.3040602@gmail.com> In-Reply-To: <49DFB1DB.3040602@gmail.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: roll@ietf.org Subject: Re: [Roll] 6lowpan-ND vs. ROLL X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Apr 2009 07:09:32 -0000 Hi, Alexandru Petrescu wrote: > Richard Kelsey a écrit : >> From: Carsten Bormann >> Date: Fri, 10 Apr 2009 19:00:42 +0200 >> >> (I don't tend to think about the case where there is no >> Edge Router -- ...) >> >> I have a question on this, stemming from my lack of >> familiarity with the details of IP routing. >> >> Suppose I have a 6LowPAN/ROLL network being used for energy >> management in a home. The network includes the electric >> meter, which has a backhaul connection back to the utility. >> The utility, being very protective of its backhaul network, >> has a firewall in the meter to keep out everything except >> the utility's own traffic. Given the presence of the >> firewall, does it still make sense to use the meter as an >> Edge Router? > > I don't think it would make much sense because Edge Router as currently > specified by 6LoWPAN ND seems to not be doing any routing at all - but a > sort of bridging, and firewalls are very much rules on the IP fields, > and less if at all rules on the MAC fields. That is not true. In 6LoWPAN the edge router is an IP router just like any other, and is a natural place to use a firewall. The same goes for Border Routers in ROLL. I think the terminology actually needs to be synchronized - we should call it a Border Router also in 6LoWPAN? > I doubt Utility would be happy with Client meter bridging all sensor > traffic into the backhaul, or otherwise filtered by huge tables of MAC > filter rules... > Alex > > >> -Richard Kelsey >> _______________________________________________ >> Roll mailing list >> Roll@ietf.org >> https://www.ietf.org/mailman/listinfo/roll >> > > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll -- http://zachshelby.org - My blog “On the Internet of Things” Mobile: +358 40 7796297 Zach Shelby Head of Research Sensinode Ltd. Kidekuja 2 88610 Vuokatti, FINLAND This e-mail and all attached material are confidential and may contain legally privileged information. If you are not the intended recipient, please contact the sender and delete the e-mail from your system without producing, distributing or retaining copies thereof. From zach@sensinode.com Sat Apr 11 00:17: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 843883A69DF for ; Sat, 11 Apr 2009 00:17:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.549 X-Spam-Level: X-Spam-Status: No, score=-3.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MqPyPgPT33mc for ; Sat, 11 Apr 2009 00:17:26 -0700 (PDT) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by core3.amsl.com (Postfix) with ESMTP id 221FD3A6814 for ; Sat, 11 Apr 2009 00:17:25 -0700 (PDT) Received: from snl-zach.local ([62.145.172.50]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.4/8.13.4) with ESMTP id n3B7ISRx000374 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 11 Apr 2009 10:18:28 +0300 Message-ID: <49E0445C.900@sensinode.com> Date: Sat, 11 Apr 2009 10:18:52 +0300 From: Zach Shelby User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Richard Kelsey References: <0BD8BD8B-FD05-46E9-9AD4-7E9F312AAD21@cisco.com> <257B9AAC-B5A5-4141-86B6-0E04C5DA3DA9@cs.stanford.edu> <77f1dba80904092359v5bb941eeu2f2c6f3065954bfa@mail.gmail.com> <49DF2910.3050304@gmail.com> <49DF4D3C.6040702@gmail.com> <406F3572-344F-4DE1-863D-F3F2743416AF@tzi.org> <200904102001.n3AK1KD4023958@kelsey-ws.hq.ember.com> <1239394271.6458.3451.camel@DellX1> <200904102044.n3AKiZSC024343@kelsey-ws.hq.ember.com> In-Reply-To: <200904102044.n3AKiZSC024343@kelsey-ws.hq.ember.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: roll@ietf.org Subject: Re: [Roll] 6lowpan-ND vs. ROLL X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Apr 2009 07:17:27 -0000 Hi, Richard Kelsey wrote: > From: Geoff Mulligan > Date: Fri, 10 Apr 2009 14:11:11 -0600 > > On Fri, 2009-04-10 at 16:01 -0400, Richard Kelsey wrote: > > From: Carsten Bormann > > Date: Fri, 10 Apr 2009 19:00:42 +0200 > > > > (I don't tend to think about the case where there is no > > Edge Router -- ...) > > > > I have a question on this, stemming from my lack of > > familiarity with the details of IP routing. > > > > Suppose I have a 6LowPAN/ROLL network being used for energy > > management in a home. The network includes the electric > > meter, which has a backhaul connection back to the utility. > > The utility, being very protective of its backhaul network, > > has a firewall in the meter to keep out everything except > > the utility's own traffic. Given the presence of the > > firewall, does it still make sense to use the meter as an > > Edge Router? > > yes as an edge router for the in home devices connected to the utilities > network. > > Thanks for the quick response. > > From the LLN Routing Fundamentals draft, the meter would > then make itself the root of a grounded tree. Would it set > the Default flag in the TIO? What if another Edge Router > with a less-restrictive backhaul, via an ISP perhaps, is > added to the home network? As long as the meter is the > only Edge Router it makes sense to have it be the default. > What happens when the second one is added isn't clear to > me. As both the meter, and the router of the ISP are attached to the Internet in different places, each will have a different IPv6 prefix to advertise on their ROLL interface. Thus they are two different networks, each having its own grounded tree. Sensor nodes will just have to choose which it wants to attach to using the information in the RA. Both ERs would be default, but the depth and metric to them will be different. > I expect this may turn out to be a common arrangement, with > the second Edge Router being a third-party energy management > device. > > -Richard Kelsey > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll -- http://zachshelby.org - My blog “On the Internet of Things” Mobile: +358 40 7796297 Zach Shelby Head of Research Sensinode Ltd. Kidekuja 2 88610 Vuokatti, FINLAND This e-mail and all attached material are confidential and may contain legally privileged information. If you are not the intended recipient, please contact the sender and delete the e-mail from your system without producing, distributing or retaining copies thereof. From cabo@tzi.org Sat Apr 11 00:21: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 9CAF33A6A1C for ; Sat, 11 Apr 2009 00:21:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TTrdzyFfsAq1 for ; Sat, 11 Apr 2009 00:21:38 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9:209:3dff:fe00:7136]) by core3.amsl.com (Postfix) with ESMTP id 7B8453A69DF for ; Sat, 11 Apr 2009 00:21:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.2/8.14.2) with ESMTP id n3B7MdS9016030; Sat, 11 Apr 2009 09:22:39 +0200 (CEST) Received: from [192.168.217.107] (p5489BFA1.dip.t-dialin.net [84.137.191.161]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTP id 344A11704D7; Sat, 11 Apr 2009 09:22:39 +0200 (CEST) From: Carsten Bormann To: Zach Shelby In-Reply-To: <49E04284.6000900@sensinode.com> References: <0BD8BD8B-FD05-46E9-9AD4-7E9F312AAD21@cisco.com> <257B9AAC-B5A5-4141-86B6-0E04C5DA3DA9@cs.stanford.edu> <77f1dba80904092359v5bb941eeu2f2c6f3065954bfa@mail.gmail.com> <49DF2910.3050304@gmail.com> <49DF4D3C.6040702@gmail.com> <406F3572-344F-4DE1-863D-F3F2743416AF@tzi.org> <200904102001.n3AK1KD4023958@kelsey-ws.hq.ember.com> <49DFB1DB.3040602@gmail.com> <49E04284.6000900@sensinode.com> Message-Id: <5A3DD606-6417-4837-81BA-E88E5C999C61@tzi.org> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Sat, 11 Apr 2009 09:22:38 +0200 X-Mailer: Apple Mail (2.930.3) Cc: roll@ietf.org Subject: Re: [Roll] 6lowpan-ND vs. ROLL X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Apr 2009 07:21:39 -0000 On Apr 11, 2009, at 09:11, Zach Shelby wrote: > Border Router In general usage, Border Routers are typically the ones that have to handle cross-domain issues. A 6lowpan Edge Router may have that role in certain cases, but in others, it doesn't. I'd prefer to stay with a term that doesn't always imply a change of domain. Gruesse, Carsten From alexandru.petrescu@gmail.com Sat Apr 11 05:06: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 B217228C0E7 for ; Sat, 11 Apr 2009 05:06:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.039 X-Spam-Level: X-Spam-Status: No, score=-2.039 tagged_above=-999 required=5 tests=[AWL=0.210, 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 OWzjFu1PjJAy for ; Sat, 11 Apr 2009 05:06:38 -0700 (PDT) Received: from smtp6-g21.free.fr (smtp6-g21.free.fr [212.27.42.6]) by core3.amsl.com (Postfix) with ESMTP id 9D6AE28C0EC for ; Sat, 11 Apr 2009 05:06:37 -0700 (PDT) Received: from smtp6-g21.free.fr (localhost [127.0.0.1]) by smtp6-g21.free.fr (Postfix) with ESMTP id 3BD98E08054; Sat, 11 Apr 2009 14:07:42 +0200 (CEST) Received: from [127.0.0.1] (bur91-3-82-239-213-32.fbx.proxad.net [82.239.213.32]) by smtp6-g21.free.fr (Postfix) with ESMTP id EBB95E08106; Sat, 11 Apr 2009 14:07:39 +0200 (CEST) Message-ID: <49E0880E.1030803@gmail.com> Date: Sat, 11 Apr 2009 14:07:42 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Zach Shelby References: <0BD8BD8B-FD05-46E9-9AD4-7E9F312AAD21@cisco.com> <257B9AAC-B5A5-4141-86B6-0E04C5DA3DA9@cs.stanford.edu> <77f1dba80904092359v5bb941eeu2f2c6f3065954bfa@mail.gmail.com> <49DF2910.3050304@gmail.com> <49DF4D3C.6040702@gmail.com> <406F3572-344F-4DE1-863D-F3F2743416AF@tzi.org> <200904102001.n3AK1KD4023958@kelsey-ws.hq.ember.com> <49DFB1DB.3040602@gmail.com> <49E04284.6000900@sensinode.com> In-Reply-To: <49E04284.6000900@sensinode.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: roll@ietf.org Subject: Re: [Roll] 6lowpan-ND vs. ROLL X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Apr 2009 12:06:39 -0000 Zach Shelby a écrit : > Hi, > > Alexandru Petrescu wrote: >> Richard Kelsey a écrit : >>> From: Carsten Bormann Date: Fri, 10 Apr 2009 >>> 19:00:42 +0200 >>> >>> (I don't tend to think about the case where there is no Edge >>> Router -- ...) >>> >>> I have a question on this, stemming from my lack of familiarity >>> with the details of IP routing. >>> >>> Suppose I have a 6LowPAN/ROLL network being used for energy >>> management in a home. The network includes the electric meter, >>> which has a backhaul connection back to the utility. The utility, >>> being very protective of its backhaul network, has a firewall in >>> the meter to keep out everything except the utility's own >>> traffic. Given the presence of the firewall, does it still make >>> sense to use the meter as an Edge Router? >> >> I don't think it would make much sense because Edge Router as >> currently specified by 6LoWPAN ND seems to not be doing any routing >> at all - but a sort of bridging, and firewalls are very much rules >> on the IP fields, and less if at all rules on the MAC fields. > > That is not true. In 6LoWPAN the edge router is an IP router just > like any other, and is a natural place to use a firewall. Yes, but, pictorially speaking: |egress(backbone) \ ------ | | ER | | ------ > single IPv6 subnet |ingress | o o | o o (lowpan nodes) / ND doc: > This document also specifies the seamless integration of an extended > LoWPAN and multiple edge routers on a shared backbone link (e.g. > Ethernet) to form a single IPv6 subnet. The ND document says that ER egress interface and the LoWPAN nodes form a single subnet - that is not a typical router. A typical router is connected to two or more different subnets. In this sense, it's difficult to consider ER to be a typical router doing a typical firewall. Alex From alexandru.petrescu@gmail.com Sat Apr 11 05:11: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 F380C3A6E38 for ; Sat, 11 Apr 2009 05:11:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.042 X-Spam-Level: X-Spam-Status: No, score=-2.042 tagged_above=-999 required=5 tests=[AWL=0.207, 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 AORYr5DuAYfm for ; Sat, 11 Apr 2009 05:11:39 -0700 (PDT) Received: from smtp1-g21.free.fr (smtp1-g21.free.fr [212.27.42.1]) by core3.amsl.com (Postfix) with ESMTP id 113BE3A69A7 for ; Sat, 11 Apr 2009 05:11:37 -0700 (PDT) Received: from smtp1-g21.free.fr (localhost [127.0.0.1]) by smtp1-g21.free.fr (Postfix) with ESMTP id 1A93B940048; Sat, 11 Apr 2009 14:12:42 +0200 (CEST) Received: from [127.0.0.1] (bur91-3-82-239-213-32.fbx.proxad.net [82.239.213.32]) by smtp1-g21.free.fr (Postfix) with ESMTP id 0D03C9400A8; Sat, 11 Apr 2009 14:12:40 +0200 (CEST) Message-ID: <49E0893A.3090905@gmail.com> Date: Sat, 11 Apr 2009 14:12:42 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Carsten Bormann References: <0BD8BD8B-FD05-46E9-9AD4-7E9F312AAD21@cisco.com> <257B9AAC-B5A5-4141-86B6-0E04C5DA3DA9@cs.stanford.edu> <77f1dba80904092359v5bb941eeu2f2c6f3065954bfa@mail.gmail.com> <49DF2910.3050304@gmail.com> <49DF4D3C.6040702@gmail.com> <406F3572-344F-4DE1-863D-F3F2743416AF@tzi.org> <200904102001.n3AK1KD4023958@kelsey-ws.hq.ember.com> <49DFB1DB.3040602@gmail.com> <49E04284.6000900@sensinode.com> <5A3DD606-6417-4837-81BA-E88E5C999C61@tzi.org> In-Reply-To: <5A3DD606-6417-4837-81BA-E88E5C999C61@tzi.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: roll@ietf.org Subject: Re: [Roll] 6lowpan-ND vs. ROLL X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Apr 2009 12:11:40 -0000 Carsten Bormann a écrit : > On Apr 11, 2009, at 09:11, Zach Shelby wrote: > >> Border Router > > In general usage, Border Routers are typically the ones that have to > handle cross-domain issues. A 6lowpan Edge Router may have that role > in certain cases, but in others, it doesn't. I'd prefer to stay with > a term that doesn't always imply a change of domain. Well I also see Border Router indeed to be OSPF router at the limit of an OSPF area... I used the term Border Router in some drafts where OSPF wasn't used (but Mobile IP) and it seemed to be understood by others. I could live with Edge Router as well. And Access Router could be proposed as well, because it typically links a wired Ethernet to a wireless medium (it's used for WiFi and 3G and more). Alex > > Gruesse, Carsten > > From richard.kelsey@ember.com Sat Apr 11 11:14: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 623703A6D8F for ; Sat, 11 Apr 2009 11:14:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FgUBG6mFwDsx for ; Sat, 11 Apr 2009 11:14:52 -0700 (PDT) Received: from EMPIRE.hq.ember.com (mail.ember.com [74.10.175.227]) by core3.amsl.com (Postfix) with ESMTP id 7EB913A6AEE for ; Sat, 11 Apr 2009 11:14:52 -0700 (PDT) Received: from kelsey-ws.hq.ember.com ([192.168.81.55]) by EMPIRE.hq.ember.com with Microsoft SMTPSVC(6.0.3790.3959); Sat, 11 Apr 2009 14:16:47 -0400 Received: from kelsey-ws.hq.ember.com (localhost.localdomain [127.0.0.1]) by kelsey-ws.hq.ember.com (8.13.4/8.13.4) with ESMTP id n3BIG1aj002949; Sat, 11 Apr 2009 14:16:01 -0400 Received: (from kelsey@localhost) by kelsey-ws.hq.ember.com (8.13.4/8.12.8/Submit) id n3BIG1iQ002946; Sat, 11 Apr 2009 14:16:01 -0400 Date: Sat, 11 Apr 2009 14:16:01 -0400 Message-Id: <200904111816.n3BIG1iQ002946@kelsey-ws.hq.ember.com> To: zach@sensinode.com In-reply-to: <49E0445C.900@sensinode.com> (message from Zach Shelby on Sat, 11 Apr 2009 10:18:52 +0300) From: Richard Kelsey References: <0BD8BD8B-FD05-46E9-9AD4-7E9F312AAD21@cisco.com> <257B9AAC-B5A5-4141-86B6-0E04C5DA3DA9@cs.stanford.edu> <77f1dba80904092359v5bb941eeu2f2c6f3065954bfa@mail.gmail.com> <49DF2910.3050304@gmail.com> <49DF4D3C.6040702@gmail.com> <406F3572-344F-4DE1-863D-F3F2743416AF@tzi.org> <200904102001.n3AK1KD4023958@kelsey-ws.hq.ember.com> <1239394271.6458.3451.camel@DellX1> <200904102044.n3AKiZSC024343@kelsey-ws.hq.ember.com> <49E0445C.900@sensinode.com> X-OriginalArrivalTime: 11 Apr 2009 18:16:47.0461 (UTC) FILETIME=[AD43E950:01C9BAD1] Cc: roll@ietf.org Subject: Re: [Roll] 6lowpan-ND vs. ROLL X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Apr 2009 18:14:53 -0000 Date: Sat, 11 Apr 2009 10:18:52 +0300 From: Zach Shelby Richard Kelsey wrote: > From: Geoff Mulligan > Date: Fri, 10 Apr 2009 14:11:11 -0600 > > On Fri, 2009-04-10 at 16:01 -0400, Richard Kelsey wrote: > > From: Carsten Bormann > > Date: Fri, 10 Apr 2009 19:00:42 +0200 > > > > (I don't tend to think about the case where there is no > > Edge Router -- ...) > > > > I have a question on this, stemming from my lack of > > familiarity with the details of IP routing. > > > > Suppose I have a 6LowPAN/ROLL network being used for energy > > management in a home. The network includes the electric > > meter, which has a backhaul connection back to the utility. > > The utility, being very protective of its backhaul network, > > has a firewall in the meter to keep out everything except > > the utility's own traffic. Given the presence of the > > firewall, does it still make sense to use the meter as an > > Edge Router? > > yes as an edge router for the in home devices connected to the utilities > network. > > Thanks for the quick response. > > From the LLN Routing Fundamentals draft, the meter would > then make itself the root of a grounded tree. Would it set > the Default flag in the TIO? What if another Edge Router > with a less-restrictive backhaul, via an ISP perhaps, is > added to the home network? As long as the meter is the > only Edge Router it makes sense to have it be the default. > What happens when the second one is added isn't clear to > me. As both the meter, and the router of the ISP are attached to the Internet in different places, each will have a different IPv6 prefix to advertise on their ROLL interface. Thus they are two different networks, each having its own grounded tree. Sensor nodes will just have to choose which it wants to attach to using the information in the RA. Both ERs would be default, but the depth and metric to them will be different. How are packets routed between the two different networks? In the LLN Routing Fundamentals draft a router "uses and advertises at most one tree as Default tree". How does a router using the meter's default tree get a packet to the ISP router and from there to the Internet? If it sends it up to the meter it will get blocked by the firewall. Does the ISP's router indicate that it is a better default in some way? -Richard Kelsey From jhui@archrock.com Sat Apr 11 11:18:39 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 52D693A69D4; Sat, 11 Apr 2009 11:18:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u10XUtUXOWuN; Sat, 11 Apr 2009 11:18:38 -0700 (PDT) Received: from mail.sf.archrock.com (mail.sf.archrock.com [216.121.16.71]) by core3.amsl.com (Postfix) with ESMTP id 51C523A6860; Sat, 11 Apr 2009 11:18:38 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.sf.archrock.com (Postfix) with ESMTP id ECB50AF8B1; Sat, 11 Apr 2009 11:19:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at Received: from mail.sf.archrock.com ([127.0.0.1]) by localhost (mail.sf.archrock.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UasdrxZ7PP1W; Sat, 11 Apr 2009 11:19:43 -0700 (PDT) Received: from [10.0.1.200] (adsl-71-142-74-235.dsl.pltn13.pacbell.net [71.142.74.235]) by mail.sf.archrock.com (Postfix) with ESMTP id 8241AAF882; Sat, 11 Apr 2009 11:19:43 -0700 (PDT) Message-Id: <78F9E848-A866-45C6-94ED-A5BC6F741F8B@archrock.com> From: Jonathan Hui To: Richard Kelsey In-Reply-To: <200904102001.n3AK1KD4023958@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 v930.3) Date: Sat, 11 Apr 2009 11:19:42 -0700 References: <0BD8BD8B-FD05-46E9-9AD4-7E9F312AAD21@cisco.com> <257B9AAC-B5A5-4141-86B6-0E04C5DA3DA9@cs.stanford.edu> <77f1dba80904092359v5bb941eeu2f2c6f3065954bfa@mail.gmail.com> <49DF2910.3050304@gmail.com> <49DF4D3C.6040702@gmail.com> <406F3572-344F-4DE1-863D-F3F2743416AF@tzi.org> <200904102001.n3AK1KD4023958@kelsey-ws.hq.ember.com> X-Mailer: Apple Mail (2.930.3) Cc: 6lowpan <6lowpan@ietf.org>, roll@ietf.org Subject: Re: [Roll] 6lowpan-ND vs. ROLL X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Apr 2009 18:18:39 -0000 Hi Richard, If both egress routers are advertising default routes, then I see no problem with the stub network deciding which to choose. If they have different costs, then definitely the two should be advertising different costs. If the meter network only wants to accept traffic to a particular prefix, then it should only be advertising that. I do think we need to better define what exactly is an Edge Router in and out of a 6lowpan context. In general, I think of an Edge Router as nothing more than a router that routes between an L2N network to a non- L2N network. In the 6lowpan context, we typically associate an Edge Router with one that also maintains the "whiteboard" for nodes in the 6lowpan network. However, I'm not sure we need to bind them together. Specific to the 6LoWPAN ND draft, you do bring up an important case - one where two or more Edge Routers are not connected by a "backbone" network. I think there are interesting questions there that are not dealt with in the current 6LoWPAN ND draft (e.g. how is the whiteboard information distributed between edge routers if at all? can we have a particular whiteboard specific for a prefix maintained at only the Edge Router that advertises that prefix? do whiteboards have to be maintained at edge routers?). We should probably open a new thread on this topic in the 6LoWPAN ML... -- Jonathan Hui On Apr 10, 2009, at 1:01 PM, Richard Kelsey wrote: > From: Carsten Bormann > Date: Fri, 10 Apr 2009 19:00:42 +0200 > > (I don't tend to think about the case where there is no > Edge Router -- ...) > > I have a question on this, stemming from my lack of > familiarity with the details of IP routing. > > Suppose I have a 6LowPAN/ROLL network being used for energy > management in a home. The network includes the electric > meter, which has a backhaul connection back to the utility. > The utility, being very protective of its backhaul network, > has a firewall in the meter to keep out everything except > the utility's own traffic. Given the presence of the > firewall, does it still make sense to use the meter as an > Edge Router? > -Richard Kelsey > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From ietf-roll@mulligan.org Sat Apr 11 17:28:17 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E8B273A6B7F for ; Sat, 11 Apr 2009 17:28:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r+idS-WAt7UC for ; Sat, 11 Apr 2009 17:28:17 -0700 (PDT) Received: from server1.coslabs.com (grab.coslabs.com [199.233.92.34]) by core3.amsl.com (Postfix) with ESMTP id 0221F3A6B49 for ; Sat, 11 Apr 2009 17:28:16 -0700 (PDT) Received: from [199.233.92.20] (dev20.coslabs.com [199.233.92.20]) by server1.coslabs.com (8.13.6/8.13.6) with ESMTP id n3C0TMS0015114; Sat, 11 Apr 2009 18:29:22 -0600 (MDT) From: Geoff Mulligan To: Alexandru Petrescu In-Reply-To: <49DFB1DB.3040602@gmail.com> References: <0BD8BD8B-FD05-46E9-9AD4-7E9F312AAD21@cisco.com> <257B9AAC-B5A5-4141-86B6-0E04C5DA3DA9@cs.stanford.edu> <77f1dba80904092359v5bb941eeu2f2c6f3065954bfa@mail.gmail.com> <49DF2910.3050304@gmail.com> <49DF4D3C.6040702@gmail.com> <406F3572-344F-4DE1-863D-F3F2743416AF@tzi.org> <200904102001.n3AK1KD4023958@kelsey-ws.hq.ember.com> <49DFB1DB.3040602@gmail.com> Content-Type: text/plain; charset="UTF-8" Date: Sat, 11 Apr 2009 18:29:20 -0600 Message-Id: <1239496160.6458.5422.camel@DellX1> Mime-Version: 1.0 X-Mailer: Evolution 2.24.3 Content-Transfer-Encoding: 8bit Cc: roll@ietf.org Subject: Re: [Roll] 6lowpan-ND vs. ROLL X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Apr 2009 00:28:18 -0000 I don't think that there is any restriction that Edge Router (even as defined in the ND draft) is not doing routing. But, I was interpretting the term edge router as a generic term for a device on the edge between a 6lowpan network and some other network, perhaps using a different media. In this case the edge router might only bridge, but it might also route if they are different subnets. This would then be a perfectly appropriate place to place a firewall. geoff On Fri, 2009-04-10 at 22:53 +0200, Alexandru Petrescu wrote: > Richard Kelsey a écrit : > > From: Carsten Bormann > > Date: Fri, 10 Apr 2009 19:00:42 +0200 > > > > (I don't tend to think about the case where there is no > > Edge Router -- ...) > > > > I have a question on this, stemming from my lack of > > familiarity with the details of IP routing. > > > > Suppose I have a 6LowPAN/ROLL network being used for energy > > management in a home. The network includes the electric > > meter, which has a backhaul connection back to the utility. > > The utility, being very protective of its backhaul network, > > has a firewall in the meter to keep out everything except > > the utility's own traffic. Given the presence of the > > firewall, does it still make sense to use the meter as an > > Edge Router? > > I don't think it would make much sense because Edge Router as currently > specified by 6LoWPAN ND seems to not be doing any routing at all - but a > sort of bridging, and firewalls are very much rules on the IP fields, > and less if at all rules on the MAC fields. > > I doubt Utility would be happy with Client meter bridging all sensor > traffic into the backhaul, or otherwise filtered by huge tables of MAC > filter rules... > > Alex > > > > -Richard Kelsey > > _______________________________________________ > > Roll mailing list > > Roll@ietf.org > > https://www.ietf.org/mailman/listinfo/roll > > > > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From geoff@proto6.com Fri Apr 10 13:10: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 E0E2B3A680C for ; Fri, 10 Apr 2009 13:10:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.299 X-Spam-Level: X-Spam-Status: No, score=-1.299 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z32IMwpV9p8r for ; Fri, 10 Apr 2009 13:10:09 -0700 (PDT) Received: from server1.coslabs.com (grab.coslabs.com [199.233.92.34]) by core3.amsl.com (Postfix) with ESMTP id 23BD53A63EB for ; Fri, 10 Apr 2009 13:10:09 -0700 (PDT) Received: from [199.233.92.20] (dev20.coslabs.com [199.233.92.20]) by server1.coslabs.com (8.13.6/8.13.6) with ESMTP id n3AKBGuu021976; Fri, 10 Apr 2009 14:11:16 -0600 (MDT) From: Geoff Mulligan To: Richard Kelsey In-Reply-To: <200904102001.n3AK1KD4023958@kelsey-ws.hq.ember.com> References: <0BD8BD8B-FD05-46E9-9AD4-7E9F312AAD21@cisco.com> <257B9AAC-B5A5-4141-86B6-0E04C5DA3DA9@cs.stanford.edu> <77f1dba80904092359v5bb941eeu2f2c6f3065954bfa@mail.gmail.com> <49DF2910.3050304@gmail.com> <49DF4D3C.6040702@gmail.com> <406F3572-344F-4DE1-863D-F3F2743416AF@tzi.org> <200904102001.n3AK1KD4023958@kelsey-ws.hq.ember.com> Content-Type: text/plain Date: Fri, 10 Apr 2009 14:11:11 -0600 Message-Id: <1239394271.6458.3451.camel@DellX1> Mime-Version: 1.0 X-Mailer: Evolution 2.24.3 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Sun, 12 Apr 2009 20:54:01 -0700 Cc: roll@ietf.org Subject: Re: [Roll] 6lowpan-ND vs. ROLL X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Apr 2009 20:54:46 -0000 yes as an edge router for the in home devices connected to the utilities network. geoff On Fri, 2009-04-10 at 16:01 -0400, Richard Kelsey wrote: > From: Carsten Bormann > Date: Fri, 10 Apr 2009 19:00:42 +0200 > > (I don't tend to think about the case where there is no > Edge Router -- ...) > > I have a question on this, stemming from my lack of > familiarity with the details of IP routing. > > Suppose I have a 6LowPAN/ROLL network being used for energy > management in a home. The network includes the electric > meter, which has a backhaul connection back to the utility. > The utility, being very protective of its backhaul network, > has a firewall in the meter to keep out everything except > the utility's own traffic. Given the presence of the > firewall, does it still make sense to use the meter as an > Edge Router? > -Richard Kelsey > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From richard.kelsey@ember.com Mon Apr 13 03:03: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 4FDF73A69B6 for ; Mon, 13 Apr 2009 03:03:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vJK8Lx-p7n4S for ; Mon, 13 Apr 2009 03:03:33 -0700 (PDT) Received: from EMPIRE.hq.ember.com (mail.ember.com [74.10.175.227]) by core3.amsl.com (Postfix) with ESMTP id 446C53A6993 for ; Mon, 13 Apr 2009 03:03:33 -0700 (PDT) Received: from kelsey-ws.hq.ember.com ([192.168.81.55]) by EMPIRE.hq.ember.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 13 Apr 2009 06:05:30 -0400 Received: from kelsey-ws.hq.ember.com (localhost.localdomain [127.0.0.1]) by kelsey-ws.hq.ember.com (8.13.4/8.13.4) with ESMTP id n3DA4hM9028342; Mon, 13 Apr 2009 06:04:43 -0400 Received: (from kelsey@localhost) by kelsey-ws.hq.ember.com (8.13.4/8.12.8/Submit) id n3DA4gxC028339; Mon, 13 Apr 2009 06:04:42 -0400 Date: Mon, 13 Apr 2009 06:04:42 -0400 Message-Id: <200904131004.n3DA4gxC028339@kelsey-ws.hq.ember.com> To: zach@sensinode.com In-reply-to: <49E041A2.9020206@sensinode.com> (message from Zach Shelby on Sat, 11 Apr 2009 10:07:14 +0300) From: Richard Kelsey References: <7892795E1A87F04CADFCCF41FADD00FC074276FB@xmb-ams-337.emea.cisco.com> <200904101756.n3AHusWx022894@kelsey-ws.hq.ember.com> <49E041A2.9020206@sensinode.com> X-OriginalArrivalTime: 13 Apr 2009 10:05:30.0148 (UTC) FILETIME=[603E6640:01C9BC1F] Cc: roll@ietf.org Subject: Re: [Roll] FW: New Version Notification for draft-thubert-roll-fundamentals-01 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Apr 2009 10:03:34 -0000 Date: Sat, 11 Apr 2009 10:07:14 +0300 From: Zach Shelby Richard Kelsey wrote: > From: Philip Levis > Date: Fri, 10 Apr 2009 06:52:04 -0700 > > On Apr 9, 2009, at 1:59 AM, Pascal Thubert (pthubert) wrote: > > > Basically, since we have a depth, we have feasible parents (of > > lesser depth) and siblings (of same depth). The draft suggests that > > we can select any parent to forward on a per packet basis using the > > best metric or more advanced load balancing functionality; if that > > fails then we can use a sibling with some basic loop avoidance like > > poison return or more advanced path vector (for hydrophiles). > > Here's a URL to a paper that describes one way to solve this problem, > using the techniques I mentioned a few weeks ago and touched on in my > talk in SF: > > http://sing.stanford.edu/pubs/ctp.pdf > > Good stuff. Relating this back to the Routing Fundamentals > draft, it seems clear that ROLL will most likely use trees > for at least some routing, and while Router Advertisements > can be used to build trees, it will be good if tree > building and/or maintenance can be performed independently > of Router Advertisements. They add too much overhead > to make it easy to react quickly to changing conditions. Don't think of router advertisements as overhead - as we are working with IP networks you will always have RAs as they are an integral part of network bootstrapping and maintenance (Neighbor Discovery). As you have RAs anyways, you might as well piggyback some tree information. To be pedantic, they aren't application payload, so they are overhead. That wasn't the point I was making, though. The piggybacking only works if there happens to be an RA going out around the time that new tree information needs to be sent. Am I missing a connection between the two that makes this likely? The Collection Tree Protocol mentioned above reacts to topology changes within a second or two. I don't know if that low a response time is necessary, but it does seem clear that tree topology will sometimes be changing much faster than the data in the RAs. If new tree information needs to be sent, but new RA information does not, then the RA data is overhead. I am not suggesting that we not piggyback tree information on RAs, just that it would be good to also be able to piggyback it on other messages or send it independently. -Richard Kelsey From jvasseur@cisco.com Tue Apr 14 05:06: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 B2C653A6DA2 for ; Tue, 14 Apr 2009 05:06:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.273 X-Spam-Level: X-Spam-Status: No, score=-10.273 tagged_above=-999 required=5 tests=[AWL=0.326, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id krwXA6IeSRUE for ; Tue, 14 Apr 2009 05:06:04 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id E769C3A6892 for ; Tue, 14 Apr 2009 05:06:03 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,184,1238976000"; d="scan'208";a="38242697" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 14 Apr 2009 12:07:14 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n3EC7Eks027662; Tue, 14 Apr 2009 14:07:14 +0200 Received: from xbh-ams-331.emea.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n3EC7EZc013647; Tue, 14 Apr 2009 12:07:14 GMT Received: from xfe-ams-332.cisco.com ([144.254.231.73]) by xbh-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 14 Apr 2009 14:07:14 +0200 Received: from dhcp-144-254-20-121.cisco.com ([144.254.20.121]) by xfe-ams-332.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 14 Apr 2009 14:07:13 +0200 Message-Id: From: JP Vasseur To: Alexandru Petrescu In-Reply-To: <49DF2910.3050304@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 v930.3) Date: Tue, 14 Apr 2009 13:45:45 +0200 References: <0BD8BD8B-FD05-46E9-9AD4-7E9F312AAD21@cisco.com> <257B9AAC-B5A5-4141-86B6-0E04C5DA3DA9@cs.stanford.edu> <77f1dba80904092359v5bb941eeu2f2c6f3065954bfa@mail.gmail.com> <49DF2910.3050304@gmail.com> X-Mailer: Apple Mail (2.930.3) X-OriginalArrivalTime: 14 Apr 2009 12:07:14.0017 (UTC) FILETIME=[8C1A1D10:01C9BCF9] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=4499; t=1239710834; x=1240574834; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:=20JP=20Vasseur=20 |Subject:=20Re=3A=20[Roll]=20Formation=20of=20a=20Routing=2 0Protocol=20Design=20Team=20for=20ROLL |Sender:=20; bh=vL3/cEQno219fqXCRAJdTLSu3ahyff4+UZtpYyGTuS8=; b=sfAda1Pf2QEUNGIJdrX2kXFfiZ8FTNlX7kEu9XY+id6Yh83/Q00k2eHDkt bz+cp3ohiwVuEEcLCl3TTaMrfmlHqspfAm7Hwgv6FTkIJkFlK5AXuu8s1P1/ 5BfgpqQePX; Authentication-Results: ams-dkim-2; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Cc: ROLL WG Subject: Re: [Roll] Formation of a Routing Protocol Design Team for ROLL X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Apr 2009 12:06:05 -0000 Hi Alex, On Apr 10, 2009, at 1:10 PM, Alexandru Petrescu wrote: > JP, I must say I was also a bit surprised to see a declaration of > forming a DT... without it been mentioned at the last WG meeting. > DT formation are always announced on the ML. > I doubt it is clear what the DT is going to produce, what is its goal, > what is the starting document. > Please see the email. We discussed with the DT and apparently this is =20= clear for them and others. > The individual proposal documents (HYDRO, and thubert-fundamentals) =20= > that > I think are related to this DT have _very_ few things in common. I am > not sure there is any other proposal document which is supposed to be > part of the DT scope. > The goal of the DT is not to merge all potential proposals but to =20 produce a routing specification according to our charter. Please read my original email. > Another less clear aspect is the 6lowpan relationship: 6lowpan does =20= > link > (but also 6lowpan ND does 'multi-hop'), and ROLL does routing (but =20 > also > HYDRO does NS/NA)... > > What is the base doc of the DT? > > What are the docs considered by the DT? > Please see the DT milestones. > I also mean to say that I generally think that the DT as presented =20 > does > seem to correspond to the IETF procedure, _is_ subject to the WG > remarks, and may produce a good output, IMHO. > Thanks. JP. > Alex > > JP Vasseur a =E9crit : >> Hi Eunah, >> On Apr 10, 2009, at 8:59 AM, Eunsook Eunah Kim wrote: >>> Hi JP, >>> It' my pure question about design team. I only saw the case that WG >>> decides to make a design team for a certain WG item when people =20 >>> agreed to have a design team in the meeting. And, chairmen askes =20 >>> volunteers for the DT. I never saw that DT has been just announced =20= >>> in the mailing list. (Well, i have only 10years experience in the =20= >>> ietf. Maybe it's possible but i never saw the case like this so =20 >>> far. Thus I feel a bit that there is inner-circle discussion in =20 >>> ROLL WG, which normal participants cannot share.) >> Not at all. We (co-chair) came up with a list of names. Such a =20 >> process is not unusual at all. Should you be interested you please =20= >> look at Section 6.5 of RFC 2418 >>> Please don't misunderstand me. I think the current design team =20 >>> members are great and I think the members are the best choice what =20= >>> ROLL could have for a ROLL routing solution. >> Thanks for the feed-back. >> Something really important: as pointed out in my first email the DT =20= >> has no special status and nobody should feel "excluded" ! We do =20 >> need to contribution of all ROLL contributors. Furthermore, the DT =20= >> will regularly poll the other members for feed-back, advise, ... =20 >> and in addition everybody is free to post its own proposal of course. >> Last but not least: there are many very valuable contributors of ROLL >> that are purposely not part of the DT: it is also extremely =20 >> important to have non DT members providing inputs, contribution, ... >> Hope this help. >> Thanks. >> JP. >>> -eunah >>> On Thu, Apr 9, 2009 at 6:11 AM, Philip Levis =20= >>> wrote: >>>> On Apr 1, 2009, at 12:57 AM, JP Vasseur wrote: >>>>> Dear WG, >>>>> We have formed a new Design Team in the ROLL Working Group. =20 >>>>> Please find below the charter and team members. >>>>> Since some of you may not be familiar with the concept of a =20 >>>>> Design Team, I would like to remind a few points: >>>>> * The work produced by a Design Team has no special status in =20 >>>>> the WG and is subject to WG consensus as any other individual =20 >>>>> submission * We ask the Design Team to request for input from =20 >>>>> the WG and to provide regular updates on the progress: please =20 >>>>> send input requests to the mailing list, post regular updates of =20= >>>>> the document to get a chance to everybody to comment, ... * All: =20= >>>>> please provide input to the Design Team and copy the mailing list. >>>> JP, >>>> How does one join the design team? I would like to join. >>>> Phil _______________________________________________ Roll mailing >>>> list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll >> _______________________________________________ Roll mailing list = Roll@ietf.org=20 >> https://www.ietf.org/mailman/listinfo/roll > > From pthubert@cisco.com Tue Apr 14 07:48: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 E4DD73A6CCF for ; Tue, 14 Apr 2009 07:48:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.787 X-Spam-Level: X-Spam-Status: No, score=-9.787 tagged_above=-999 required=5 tests=[AWL=0.812, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U7sgC+Q66GZ5 for ; Tue, 14 Apr 2009 07:48:05 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 3A90D3A69DD for ; Tue, 14 Apr 2009 07:48:05 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,185,1238976000"; d="scan'208";a="38270220" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 14 Apr 2009 14:49:14 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n3EEnEQI024922; Tue, 14 Apr 2009 16:49:14 +0200 Received: from xbh-ams-331.emea.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n3EEnEHZ021409; Tue, 14 Apr 2009 14:49:14 GMT Received: from xmb-ams-337.cisco.com ([144.254.231.82]) by xbh-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 14 Apr 2009 16:49:14 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 14 Apr 2009 16:46:57 +0200 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC0748F7C7@xmb-ams-337.emea.cisco.com> In-Reply-To: <200904131004.n3DA4gxC028339@kelsey-ws.hq.ember.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] FW: New VersionNotification for draft-thubert-roll-fundamentals-01 Thread-Index: Acm8H0iSt8q7K+c7SpGSixH7+paxqAA74KFA References: <7892795E1A87F04CADFCCF41FADD00FC074276FB@xmb-ams-337.emea.cisco.com> <200904101756.n3AHusWx022894@kelsey-ws.hq.ember.com><49E041A2.9020206@sensinode.com> <200904131004.n3DA4gxC028339@kelsey-ws.hq.ember.com> From: "Pascal Thubert (pthubert)" To: "Richard Kelsey" , X-OriginalArrivalTime: 14 Apr 2009 14:49:14.0504 (UTC) FILETIME=[2DF6B880:01C9BD10] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3756; t=1239720554; x=1240584554; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pthubert@cisco.com; z=From:=20=22Pascal=20Thubert=20(pthubert)=22=20 |Subject:=20RE=3A=20[Roll]=20FW=3A=20New=20VersionNotificat ion=09for=09draft-thubert-roll-fundamentals-01 |Sender:=20; bh=wlJWrmtoyqQQMzQ9Vre4PYNPEB8IDmJe3nt7suDGGi0=; b=DDGC/SIT6BB7XtYbdz794NCeFOBynjHx7JykXVOxzV9iCIdGHY4XIzcjyN zw775BRJo62mBGeRsJq8wMvy+Aun1T8/qjSWhalzvpiFHlVVXW74cciyIHen FZpImvkaZu; Authentication-Results: ams-dkim-2; header.From=pthubert@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Cc: roll@ietf.org Subject: Re: [Roll] FW: New VersionNotification for draft-thubert-roll-fundamentals-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, 14 Apr 2009 14:48:07 -0000 Hi Richard: The routing - that builds the tree - in the fundamentals draft reacts lazily to metrics changes, so seconds are OK, even way longer and that can match an acceptable RA period. The reason is that changing the tree has more dramatic impacts then just forwarding over a better parent. The catch is that the forwarding reacts a lot quicker, and yes, another (faster) way to carry the metrics would be very helpful. The draft mentions an out-of-band forwarding protocol in [6.2.3. Graph forwarding], and in-band piggy backed with data could be used too as Zach indicates. =20 Pascal >-----Original Message----- >From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Richard Kelsey >Sent: lundi 13 avril 2009 12:05 >To: zach@sensinode.com >Cc: roll@ietf.org >Subject: Re: [Roll] FW: New VersionNotification for draft-thubert-roll-fundamentals-01 > > Date: Sat, 11 Apr 2009 10:07:14 +0300 > From: Zach Shelby > > Richard Kelsey wrote: > > From: Philip Levis > > Date: Fri, 10 Apr 2009 06:52:04 -0700 > > > > On Apr 9, 2009, at 1:59 AM, Pascal Thubert (pthubert) wrote: > > > > > Basically, since we have a depth, we have feasible parents (of > > > lesser depth) and siblings (of same depth). The draft suggests that > > > we can select any parent to forward on a per packet basis using the > > > best metric or more advanced load balancing functionality; if that > > > fails then we can use a sibling with some basic loop avoidance like > > > poison return or more advanced path vector (for hydrophiles). > > > > Here's a URL to a paper that describes one way to solve this problem, > > using the techniques I mentioned a few weeks ago and touched on in my > > talk in SF: > > > > http://sing.stanford.edu/pubs/ctp.pdf > > > > Good stuff. Relating this back to the Routing Fundamentals > > draft, it seems clear that ROLL will most likely use trees > > for at least some routing, and while Router Advertisements > > can be used to build trees, it will be good if tree > > building and/or maintenance can be performed independently > > of Router Advertisements. They add too much overhead > > to make it easy to react quickly to changing conditions. > > Don't think of router advertisements as overhead - as we > are working with IP networks you will always have RAs as > they are an integral part of network bootstrapping and > maintenance (Neighbor Discovery). As you have RAs > anyways, you might as well piggyback some tree > information. > >To be pedantic, they aren't application payload, so they are >overhead. That wasn't the point I was making, though. > >The piggybacking only works if there happens to be an RA >going out around the time that new tree information needs to >be sent. Am I missing a connection between the two that >makes this likely? The Collection Tree Protocol mentioned >above reacts to topology changes within a second or two. I >don't know if that low a response time is necessary, but it >does seem clear that tree topology will sometimes be >changing much faster than the data in the RAs. If new tree >information needs to be sent, but new RA information does >not, then the RA data is overhead. > >I am not suggesting that we not piggyback tree information >on RAs, just that it would be good to also be able to >piggyback it on other messages or send it independently. > > -Richard Kelsey >_______________________________________________ >Roll mailing list >Roll@ietf.org >https://www.ietf.org/mailman/listinfo/roll From pthubert@cisco.com Tue Apr 14 07:48:08 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6483528C14C for ; Tue, 14 Apr 2009 07:48:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.822 X-Spam-Level: X-Spam-Status: No, score=-9.822 tagged_above=-999 required=5 tests=[AWL=0.777, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F3F2qXVxCVx8 for ; Tue, 14 Apr 2009 07:48:07 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 136153A67D7 for ; Tue, 14 Apr 2009 07:48:05 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,185,1238976000"; d="scan'208";a="38270227" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 14 Apr 2009 14:49:16 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n3EEnFC2015628; Tue, 14 Apr 2009 16:49:15 +0200 Received: from xbh-ams-331.emea.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n3EEnF5b021430; Tue, 14 Apr 2009 14:49:15 GMT Received: from xmb-ams-337.cisco.com ([144.254.231.82]) by xbh-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 14 Apr 2009 16:49:15 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 14 Apr 2009 16:49:09 +0200 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC0748F7C8@xmb-ams-337.emea.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] FW: New Version Notification for draft-thubert-roll-fundamentals-01 Thread-Index: Acm544tUeu6WCfA+QzWaCYwddOs31gDLJNcA References: <7892795E1A87F04CADFCCF41FADD00FC074276FB@xmb-ams-337.emea.cisco.com> From: "Pascal Thubert (pthubert)" To: "Philip Levis" X-OriginalArrivalTime: 14 Apr 2009 14:49:15.0207 (UTC) FILETIME=[2E61FD70:01C9BD10] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1970; t=1239720555; x=1240584555; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pthubert@cisco.com; z=From:=20=22Pascal=20Thubert=20(pthubert)=22=20 |Subject:=20RE=3A=20[Roll]=20FW=3A=20New=20Version=20Notifi cation=20for=20draft-thubert-roll-fundamentals-01 |Sender:=20; bh=XGCGb6fjdpbOzFA9SwKgRzf4WaI8LaA7t/yv+vneVXQ=; b=jFZdvJ+lcsI2X/Hbt7vCdZz8yBVJ6/4vgYAl3naulsiscdfsM6f4neGw2I pheEesQznDtUADU0A0EFDJ7E6gsl6ZjwNQV26+nZdgfFHq8QAt37NHmz7fVd uL38wkqic7; Authentication-Results: ams-dkim-1; header.From=pthubert@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Cc: roll@ietf.org Subject: Re: [Roll] FW: New Version Notification for draft-thubert-roll-fundamentals-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, 14 Apr 2009 14:48:08 -0000 Thanks Phil :)=20 Pascal >-----Original Message----- >From: Philip Levis [mailto:pal@cs.stanford.edu] >Sent: vendredi 10 avril 2009 15:52 >To: Pascal Thubert (pthubert) >Cc: roll@ietf.org >Subject: Re: [Roll] FW: New Version Notification for draft-thubert-roll-fundamentals-01 > >On Apr 9, 2009, at 1:59 AM, Pascal Thubert (pthubert) wrote: > >> 1) This contribution details the formation of a Distance Vector tree >> using ND extensions; most existing contributions to this WG suggest >> that approach (Teco's BRDP, Arsalan & al. 's Hydro's Default Route >> Formation, Phil & al. Usenix paper's Tree based routing...) and the >> value we provide here is more refined details on such operation, to >> address for instance merging and splitting of trees or the >> integration with the 6LoWPAN backbone. > >It's worth noting that the networking abstractions paper is, at this >point, 5 years old. Protocols have progressed a lot since then. And I >think it's safe to say that the statements of "IP doesn't seem to be >useful" should be "at that time, we didn't think IP would be useful >and gosh were we wrong!" > >> Basically, since we have a depth, we have feasible parents (of >> lesser depth) and siblings (of same depth). The draft suggests that >> we can select any parent to forward on a per packet basis using the >> best metric or more advanced load balancing functionality; if that >> fails then we can use a sibling with some basic loop avoidance like >> poison return or more advanced path vector (for hydrophiles). > >Here's a URL to a paper that describes one way to solve this problem, >using the techniques I mentioned a few weeks ago and touched on in my >talk in SF: > >http://sing.stanford.edu/pubs/ctp.pdf > >The source code for CTP (the tree protocol in the paper) is part of a >TinyOS release and is under a BSD license. It can be found at > >http://www.tinyos.net/tinyos-2.x/tos/lib/net/ctp/ > >Phil From pal@cs.stanford.edu Tue Apr 14 18:26: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 DAB573A6A71 for ; Tue, 14 Apr 2009 18:26:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.98 X-Spam-Level: X-Spam-Status: No, score=-5.98 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r9U9APtthwpt for ; Tue, 14 Apr 2009 18:26:58 -0700 (PDT) Received: from cs-smtp-1.Stanford.EDU (cs-smtp-1.Stanford.EDU [171.64.64.25]) by core3.amsl.com (Postfix) with ESMTP id B6B6C3A699D for ; Tue, 14 Apr 2009 18:26:58 -0700 (PDT) Received: from 209.220.168.194.ptr.us.xo.net ([209.220.168.194] helo=[10.71.2.4]) by cs-smtp-1.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1Lttv5-0004gq-LF; Tue, 14 Apr 2009 18:28:09 -0700 Message-Id: <0719A7FB-BEC0-4CB2-9EF0-4CD4CE4CDE26@cs.stanford.edu> From: Philip Levis To: Richard Kelsey In-Reply-To: <200904131004.n3DA4gxC028339@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 v930.3) Date: Tue, 14 Apr 2009 16:52:38 -0700 References: <7892795E1A87F04CADFCCF41FADD00FC074276FB@xmb-ams-337.emea.cisco.com> <200904101756.n3AHusWx022894@kelsey-ws.hq.ember.com> <49E041A2.9020206@sensinode.com> <200904131004.n3DA4gxC028339@kelsey-ws.hq.ember.com> X-Mailer: Apple Mail (2.930.3) X-Scan-Signature: f3ece08579cbcd970dc3d33c6519ba8c Cc: roll@ietf.org Subject: Re: [Roll] FW: New Version Notification for draft-thubert-roll-fundamentals-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, 15 Apr 2009 01:26:59 -0000 On Apr 13, 2009, at 3:04 AM, Richard Kelsey wrote: > Date: Sat, 11 Apr 2009 10:07:14 +0300 > From: Zach Shelby > > Richard Kelsey wrote: >> From: Philip Levis >> Date: Fri, 10 Apr 2009 06:52:04 -0700 >> >> On Apr 9, 2009, at 1:59 AM, Pascal Thubert (pthubert) wrote: >> >>> Basically, since we have a depth, we have feasible parents (of >>> lesser depth) and siblings (of same depth). The draft suggests that >>> we can select any parent to forward on a per packet basis using the >>> best metric or more advanced load balancing functionality; if that >>> fails then we can use a sibling with some basic loop avoidance like >>> poison return or more advanced path vector (for hydrophiles). >> >> Here's a URL to a paper that describes one way to solve this >> problem, >> using the techniques I mentioned a few weeks ago and touched on >> in my >> talk in SF: >> >> http://sing.stanford.edu/pubs/ctp.pdf >> >> Good stuff. Relating this back to the Routing Fundamentals >> draft, it seems clear that ROLL will most likely use trees >> for at least some routing, and while Router Advertisements >> can be used to build trees, it will be good if tree >> building and/or maintenance can be performed independently >> of Router Advertisements. They add too much overhead >> to make it easy to react quickly to changing conditions. > > Don't think of router advertisements as overhead - as we > are working with IP networks you will always have RAs as > they are an integral part of network bootstrapping and > maintenance (Neighbor Discovery). As you have RAs > anyways, you might as well piggyback some tree > information. > > To be pedantic, they aren't application payload, so they are > overhead. That wasn't the point I was making, though. Even if it isn't the point you were trying to make, I'd agree with it. :) It's hard to say that a routing protocol is efficient if it sends 1000 RAs for every data packet. At the most abstract level, a protocol's overhead is (total bytes - data bytes)/data bytes. That being said, the presence of energy as a critical metric means that there can and are situations where higher overhead can lead to greater efficiency. For example, a header field that gives some sort of rendezvous timing as in Jonathan's IP stack. > The piggybacking only works if there happens to be an RA > going out around the time that new tree information needs to > be sent. Am I missing a connection between the two that > makes this likely? The Collection Tree Protocol mentioned > above reacts to topology changes within a second or two. Even faster -- one experiment we did on this saw 10-15 packet times, which was 200-300ms. It turns out that, for 802.15.4 at least, in tough environments links tend to have a coherence time around 500ms, so you'd like to be able to either react much faster or much slower than that. Faster so you don't keep on hammering a bad link, or slower so that the next transmission is a random coin toss. > I > don't know if that low a response time is necessary, but it > does seem clear that tree topology will sometimes be > changing much faster than the data in the RAs. If new tree > information needs to be sent, but new RA information does > not, then the RA data is overhead. I agree with this: it's the exact problem that adaptive beaconing tries to solve. Any periodic RA mechanism introduces a tough tradeoff: beacon faster for fast adaptation but high cost, or beacon slower for efficiency but slow adaptation. Hence the point of borrowing and extending Trickle -- send just enough RAs for nodes to discover each other and verify that the tree is still consistent. Data path validation allows the protocol to verify the tree's consistency without introducing additional (RA) overhead. > I am not suggesting that we not piggyback tree information > on RAs, just that it would be good to also be able to > piggyback it on other messages or send it independently. The design question here is *what* information to piggyback. One interesting way that the paper I sent out differs from Jonathan's IP stack is his stack includes hop count in data packets (Section 8.1.4 of the SenSys 2008 paper). From an academic standpoint, it would be an interesting evaluation to see whether the cost of this field is less than the cost of false positives on CTP's loop detection (the case where a node's ETX goes up but its children don't know yet, so it thinks there might be a loop). I say it's academic because my guess is that it's a comparatively small difference either way, compared to other, more important issues. Om -- this might be a nice experiment to look at from the traces, just compute how often CTP beacon resets are false positives on loop detection. Phil From pthubert@cisco.com Wed Apr 15 03:57:14 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 19DD83A6AA0 for ; Wed, 15 Apr 2009 03:57:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.884 X-Spam-Level: X-Spam-Status: No, score=-9.884 tagged_above=-999 required=5 tests=[AWL=0.715, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u3K8u113YjPv for ; Wed, 15 Apr 2009 03:57:12 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 527DC3A6839 for ; Wed, 15 Apr 2009 03:57:12 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,192,1238976000"; d="scan'208";a="38351980" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 15 Apr 2009 10:58:23 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n3FAwNXa012130; Wed, 15 Apr 2009 12:58:23 +0200 Received: from xbh-ams-331.emea.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n3FAwNIw001197; Wed, 15 Apr 2009 10:58:23 GMT Received: from xmb-ams-337.cisco.com ([144.254.231.82]) by xbh-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 15 Apr 2009 12:58:23 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 15 Apr 2009 12:58:17 +0200 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC0748FB3D@xmb-ams-337.emea.cisco.com> In-Reply-To: <0719A7FB-BEC0-4CB2-9EF0-4CD4CE4CDE26@cs.stanford.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] FW: New VersionNotification for draft-thubert-roll-fundamentals-01 Thread-Index: Acm9aX0Zo/na5J8uSLedp9ISlD394wATjulA References: <7892795E1A87F04CADFCCF41FADD00FC074276FB@xmb-ams-337.emea.cisco.com> <200904101756.n3AHusWx022894@kelsey-ws.hq.ember.com><49E041A2.9020206@sensinode.com><200904131004.n3DA4gxC028339@kelsey-ws.hq.ember.com> <0719A7FB-BEC0-4CB2-9EF0-4CD4CE4CDE26@cs.stanford.edu> From: "Pascal Thubert (pthubert)" To: "Philip Levis" , "Richard Kelsey" X-OriginalArrivalTime: 15 Apr 2009 10:58:23.0455 (UTC) FILETIME=[18821EF0:01C9BDB9] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=6073; t=1239793103; x=1240657103; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pthubert@cisco.com; z=From:=20=22Pascal=20Thubert=20(pthubert)=22=20 |Subject:=20RE=3A=20[Roll]=20FW=3A=20New=20VersionNotificat ion=09for=09draft-thubert-roll-fundamentals-01 |Sender:=20; bh=s0qrDZr7wJ4v0P/+6+Lwt012DIUrHTCWld5ydFMwnB8=; b=NYq0CsdxEbcKkBOPtqLOzKiGOGssEVCaTC0ympSof/2uYU88QyKkCse+VR q9QWfhR7hv8VEbTv4wemqekWuwOONMQgwUQSg0lTI/OfSGTGbtBmeU1CzRVu 4yK2iGvgDy; Authentication-Results: ams-dkim-1; header.From=pthubert@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Cc: roll@ietf.org Subject: Re: [Roll] FW: New VersionNotification for draft-thubert-roll-fundamentals-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, 15 Apr 2009 10:57:14 -0000 Hi Phil, The fundamentals draft was published as a proposed approach to the problem - basically build a tree, forward over a graph, and then provide additional optional features.=20 This draft being done, I'm happy to switch to a DT hat and discuss if such an approach is desirable. If that's so, CTP presents a number of advantages for building the tree that the DT will certainly recognize.=20 The cool thing is that from the very beginning of the IETF work, we already have a wealth of ideas and experiments on the table. Considering the schedule we have, this existing art is certainly welcome. Pascal >-----Original Message----- >From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Philip Levis >Sent: mercredi 15 avril 2009 01:53 >To: Richard Kelsey >Cc: roll@ietf.org >Subject: Re: [Roll] FW: New VersionNotification for draft-thubert-roll-fundamentals-01 > > >On Apr 13, 2009, at 3:04 AM, Richard Kelsey wrote: > >> Date: Sat, 11 Apr 2009 10:07:14 +0300 >> From: Zach Shelby >> >> Richard Kelsey wrote: >>> From: Philip Levis >>> Date: Fri, 10 Apr 2009 06:52:04 -0700 >>> >>> On Apr 9, 2009, at 1:59 AM, Pascal Thubert (pthubert) wrote: >>> >>>> Basically, since we have a depth, we have feasible parents (of >>>> lesser depth) and siblings (of same depth). The draft suggests that >>>> we can select any parent to forward on a per packet basis using the >>>> best metric or more advanced load balancing functionality; if that >>>> fails then we can use a sibling with some basic loop avoidance like >>>> poison return or more advanced path vector (for hydrophiles). >>> >>> Here's a URL to a paper that describes one way to solve this >>> problem, >>> using the techniques I mentioned a few weeks ago and touched on >>> in my >>> talk in SF: >>> >>> http://sing.stanford.edu/pubs/ctp.pdf >>> >>> Good stuff. Relating this back to the Routing Fundamentals >>> draft, it seems clear that ROLL will most likely use trees >>> for at least some routing, and while Router Advertisements >>> can be used to build trees, it will be good if tree >>> building and/or maintenance can be performed independently >>> of Router Advertisements. They add too much overhead >>> to make it easy to react quickly to changing conditions. >> >> Don't think of router advertisements as overhead - as we >> are working with IP networks you will always have RAs as >> they are an integral part of network bootstrapping and >> maintenance (Neighbor Discovery). As you have RAs >> anyways, you might as well piggyback some tree >> information. >> >> To be pedantic, they aren't application payload, so they are >> overhead. That wasn't the point I was making, though. > >Even if it isn't the point you were trying to make, I'd agree with >it. :) It's hard to say that a routing protocol is efficient if it >sends 1000 RAs for every data packet. At the most abstract level, a >protocol's overhead is (total bytes - data bytes)/data bytes. That >being said, the presence of energy as a critical metric means that >there can and are situations where higher overhead can lead to greater >efficiency. For example, a header field that gives some sort of >rendezvous timing as in Jonathan's IP stack. > >> The piggybacking only works if there happens to be an RA >> going out around the time that new tree information needs to >> be sent. Am I missing a connection between the two that >> makes this likely? The Collection Tree Protocol mentioned >> above reacts to topology changes within a second or two. > >Even faster -- one experiment we did on this saw 10-15 packet times, >which was 200-300ms. It turns out that, for 802.15.4 at least, in >tough environments links tend to have a coherence time around 500ms, >so you'd like to be able to either react much faster or much slower >than that. Faster so you don't keep on hammering a bad link, or slower >so that the next transmission is a random coin toss. > > >> I >> don't know if that low a response time is necessary, but it >> does seem clear that tree topology will sometimes be >> changing much faster than the data in the RAs. If new tree >> information needs to be sent, but new RA information does >> not, then the RA data is overhead. > >I agree with this: it's the exact problem that adaptive beaconing >tries to solve. Any periodic RA mechanism introduces a tough tradeoff: >beacon faster for fast adaptation but high cost, or beacon slower for >efficiency but slow adaptation. Hence the point of borrowing and >extending Trickle -- send just enough RAs for nodes to discover each >other and verify that the tree is still consistent. Data path >validation allows the protocol to verify the tree's consistency >without introducing additional (RA) overhead. > > >> I am not suggesting that we not piggyback tree information >> on RAs, just that it would be good to also be able to >> piggyback it on other messages or send it independently. > >The design question here is *what* information to piggyback. One >interesting way that the paper I sent out differs from Jonathan's IP >stack is his stack includes hop count in data packets (Section 8.1.4 >of the SenSys 2008 paper). From an academic standpoint, it would be an >interesting evaluation to see whether the cost of this field is less >than the cost of false positives on CTP's loop detection (the case >where a node's ETX goes up but its children don't know yet, so it >thinks there might be a loop). I say it's academic because my guess is >that it's a comparatively small difference either way, compared to >other, more important issues. > >Om -- this might be a nice experiment to look at from the traces, just >compute how often CTP beacon resets are false positives on loop >detection. > >Phil > > >_______________________________________________ >Roll mailing list >Roll@ietf.org >https://www.ietf.org/mailman/listinfo/roll From pthubert@cisco.com Wed Apr 15 08:30: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 E5CA028C229 for ; Wed, 15 Apr 2009 08:30:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.912 X-Spam-Level: X-Spam-Status: No, score=-9.912 tagged_above=-999 required=5 tests=[AWL=0.687, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i8HwqeaQKlxf for ; Wed, 15 Apr 2009 08:30:22 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id C03AB28C21D for ; Wed, 15 Apr 2009 08:30:21 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,192,1238976000"; d="scan'208";a="38373916" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 15 Apr 2009 15:31:33 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n3FFVXjU007228; Wed, 15 Apr 2009 17:31:33 +0200 Received: from xbh-ams-331.emea.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n3FFVXtZ011550; Wed, 15 Apr 2009 15:31:33 GMT Received: from xmb-ams-337.cisco.com ([144.254.231.82]) by xbh-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 15 Apr 2009 17:31:33 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 15 Apr 2009 17:31:27 +0200 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC0748FD1A@xmb-ams-337.emea.cisco.com> In-Reply-To: <200904111816.n3BIG1iQ002946@kelsey-ws.hq.ember.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] 6lowpan-ND vs. ROLL Thread-Index: Acm60ZWpXb2EFxZ1T2OcRtTvUmwFWQDC7y7g References: <0BD8BD8B-FD05-46E9-9AD4-7E9F312AAD21@cisco.com> <257B9AAC-B5A5-4141-86B6-0E04C5DA3DA9@cs.stanford.edu> <77f1dba80904092359v5bb941eeu2f2c6f3065954bfa@mail.gmail.com> <49DF2910.3050304@gmail.com> <49DF4D3C.6040702@gmail.com> <406F3572-344F-4DE1-863D-F3F2743416AF@tzi.org> <200904102001.n3AK1KD4023958@kelsey-ws.hq.ember.com> <1239394271.6458.3451.camel@DellX1><200904102044.n3AKiZSC024343@kelsey-ws.hq.ember.com><49E0445C.900@sensinode.com> <200904111816.n3BIG1iQ002946@kelsey-ws.hq.ember.com> From: "Pascal Thubert (pthubert)" To: "Richard Kelsey" , X-OriginalArrivalTime: 15 Apr 2009 15:31:33.0000 (UTC) FILETIME=[41703880:01C9BDDF] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=5064; t=1239809493; x=1240673493; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pthubert@cisco.com; z=From:=20=22Pascal=20Thubert=20(pthubert)=22=20 |Subject:=20RE=3A=20[Roll]=206lowpan-ND=20vs.=20ROLL |Sender:=20; bh=/2K2YaMJu/Kapdldliek+gpKz2jENkMnBBDboe+nKLk=; b=dOKSC8t0m+8SVqmXSB/Tk8vAbzT/mQOdMbkw1wROrQ+tQa1JbvdwTYLX+5 gcCWdutXwQMBUWseJFzDtDZHCr2neqMAxc1GQhndLK4RvmxvxCI0/JRWBSVs qjMeC1r6Be; Authentication-Results: ams-dkim-1; header.From=pthubert@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Cc: roll@ietf.org Subject: Re: [Roll] 6lowpan-ND vs. ROLL X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Apr 2009 15:30:24 -0000 Hi Richard: I see 2 things here that are supposed to help, one is security/policy and the other is multiple tree with eventually Multi-Topology Routing. I suspect that the meters from the utility could have their own L2 security in place and only talk to one another. If that's so then the home and the meter networks will act as ship in the night? If not, then it can be a matter of policy, that can be implemented by what tree discovery calls a plug in, arguably a ill-chosen term (sorry Charlie). A plugin is a decision engine that selects a preferred parent based on multiple information. As we discussed at the WG meeting, we get an optimum network only if all nodes share the same plugin, otherwise we get at least something loopless. For instance, a given plug in might white list or black list trees based on information in the TIO. The result is the same, you end up with 2 different networks.=20 In the second category, if the meter edge router advertises a prefix that encompasses all that the metering applications need, then it does not need to be advertised as default tree. The nodes can participate to that tree as non default but since they install a route to the Tree ID via the root of tree, all the metering traffic will go that way whereas the default will be routed via the default tree. Finally MTR (listed in the advanced section) enables joining multiple default trees if that's what you really need in a given deployment. If you use a default route for a given packet then you need to mark the packet to indicate which default tree you have selected, and every node along the way have to understand that marking and follow the same tree. An example of marking is a routing header indicating that the packet is to be routed via the root of the selected default tree. That way, a meter would flag its packets as metering and they would be forwarded over the meter tree. Pascal >-----Original Message----- >From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Richard Kelsey >Sent: samedi 11 avril 2009 20:16 >To: zach@sensinode.com >Cc: roll@ietf.org >Subject: Re: [Roll] 6lowpan-ND vs. ROLL > > Date: Sat, 11 Apr 2009 10:18:52 +0300 > From: Zach Shelby > > Richard Kelsey wrote: > > From: Geoff Mulligan > > Date: Fri, 10 Apr 2009 14:11:11 -0600 > > > > On Fri, 2009-04-10 at 16:01 -0400, Richard Kelsey wrote: > > > From: Carsten Bormann > > > Date: Fri, 10 Apr 2009 19:00:42 +0200 > > > > > > (I don't tend to think about the case where there is no > > > Edge Router -- ...) > > > > > > I have a question on this, stemming from my lack of > > > familiarity with the details of IP routing. > > > > > > Suppose I have a 6LowPAN/ROLL network being used for energy > > > management in a home. The network includes the electric > > > meter, which has a backhaul connection back to the utility. > > > The utility, being very protective of its backhaul network, > > > has a firewall in the meter to keep out everything except > > > the utility's own traffic. Given the presence of the > > > firewall, does it still make sense to use the meter as an > > > Edge Router? > > > > yes as an edge router for the in home devices connected to the utilities > > network. > > > > Thanks for the quick response. > > > > From the LLN Routing Fundamentals draft, the meter would > > then make itself the root of a grounded tree. Would it set > > the Default flag in the TIO? What if another Edge Router > > with a less-restrictive backhaul, via an ISP perhaps, is > > added to the home network? As long as the meter is the > > only Edge Router it makes sense to have it be the default. > > What happens when the second one is added isn't clear to > > me. > > As both the meter, and the router of the ISP are attached to the > Internet in different places, each will have a different IPv6 prefix to > advertise on their ROLL interface. Thus they are two different networks, > each having its own grounded tree. Sensor nodes will just have to choose > which it wants to attach to using the information in the RA. Both ERs > would be default, but the depth and metric to them will be different. > >How are packets routed between the two different networks? >In the LLN Routing Fundamentals draft a router "uses and >advertises at most one tree as Default tree". How does a >router using the meter's default tree get a packet to the >ISP router and from there to the Internet? If it sends it up >to the meter it will get blocked by the firewall. Does the >ISP's router indicate that it is a better default in some >way? > -Richard Kelsey >_______________________________________________ >Roll mailing list >Roll@ietf.org >https://www.ietf.org/mailman/listinfo/roll From richard.kelsey@ember.com Wed Apr 15 12:23: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 14F203A6F1E for ; Wed, 15 Apr 2009 12:23:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z5utNNLFCAhj for ; Wed, 15 Apr 2009 12:23:26 -0700 (PDT) Received: from EMPIRE.hq.ember.com (mail.ember.com [74.10.175.227]) by core3.amsl.com (Postfix) with ESMTP id 245E93A68D5 for ; Wed, 15 Apr 2009 12:23:26 -0700 (PDT) Received: from kelsey-ws.hq.ember.com ([192.168.81.55]) by EMPIRE.hq.ember.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 15 Apr 2009 15:25:22 -0400 Received: from kelsey-ws.hq.ember.com (localhost.localdomain [127.0.0.1]) by kelsey-ws.hq.ember.com (8.13.4/8.13.4) with ESMTP id n3FJOYje025804; Wed, 15 Apr 2009 15:24:34 -0400 Received: (from kelsey@localhost) by kelsey-ws.hq.ember.com (8.13.4/8.12.8/Submit) id n3FJOYTA025801; Wed, 15 Apr 2009 15:24:34 -0400 Date: Wed, 15 Apr 2009 15:24:34 -0400 Message-Id: <200904151924.n3FJOYTA025801@kelsey-ws.hq.ember.com> To: pthubert@cisco.com In-reply-to: <7892795E1A87F04CADFCCF41FADD00FC0748FD1A@xmb-ams-337.emea.cisco.com> (pthubert@cisco.com) From: Richard Kelsey References: <0BD8BD8B-FD05-46E9-9AD4-7E9F312AAD21@cisco.com> <257B9AAC-B5A5-4141-86B6-0E04C5DA3DA9@cs.stanford.edu> <77f1dba80904092359v5bb941eeu2f2c6f3065954bfa@mail.gmail.com> <49DF2910.3050304@gmail.com> <49DF4D3C.6040702@gmail.com> <406F3572-344F-4DE1-863D-F3F2743416AF@tzi.org> <200904102001.n3AK1KD4023958@kelsey-ws.hq.ember.com> <1239394271.6458.3451.camel@DellX1><200904102044.n3AKiZSC024343@kelsey-ws.hq.ember.com><49E0445C.900@sensinode.com> <200904111816.n3BIG1iQ002946@kelsey-ws.hq.ember.com> <7892795E1A87F04CADFCCF41FADD00FC0748FD1A@xmb-ams-337.emea.cisco.com> X-OriginalArrivalTime: 15 Apr 2009 19:25:22.0934 (UTC) FILETIME=[EBEE4160:01C9BDFF] Cc: roll@ietf.org Subject: Re: [Roll] 6lowpan-ND vs. ROLL X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Apr 2009 19:23:27 -0000 Date: Wed, 15 Apr 2009 17:31:27 +0200 From: "Pascal Thubert (pthubert)" I suspect that the meters from the utility could have their own L2 security in place and only talk to one another. If that's so then the home and the meter networks will act as ship in the night? In the network I was describing there are three typs of device: - a meter, which has an essentially private backhaul network - an energy management device, which has a connection to a normal ISP - one or more appliances The appliances need to exchange messages with both the meter and the management device, so they all need to be on the same L2 network. In the second category, if the meter edge router advertises a prefix that encompasses all that the metering applications need, then it does not need to be advertised as default tree. The nodes can participate to that tree as non default but since they install a route to the Tree ID via the root of tree, all the metering traffic will go that way whereas the default will be routed via the default tree. The network monitoring device, which is the one with the (relatively) unrestricted backhaul, is optional. If it isn't there, and the only access router is the meter, then the network has no default tree. Is that acceptable? Finally MTR (listed in the advanced section) enables joining multiple default trees if that's what you really need in a given deployment. If you use a default route for a given packet then you need to mark the packet to indicate which default tree you have selected, and every node along the way have to understand that marking and follow the same tree. An example of marking is a routing header indicating that the packet is to be routed via the root of the selected default tree. That way, a meter would flag its packets as metering and they would be forwarded over the meter tree. Presumably the decision as to which default tree to use is made on the basis of the destination address. That doesn't sound like a default. Or the is choice of which default tree to use made on the basis of some other information? -Richard Kelsey From pthubert@cisco.com Thu Apr 16 01:37: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 205263A6845 for ; Thu, 16 Apr 2009 01:37:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.937 X-Spam-Level: X-Spam-Status: No, score=-9.937 tagged_above=-999 required=5 tests=[AWL=0.662, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tcLYpLiSF27e for ; Thu, 16 Apr 2009 01:37:55 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 9DCE33A6359 for ; Thu, 16 Apr 2009 01:37:54 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,197,1238976000"; d="scan'208";a="38415325" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 16 Apr 2009 08:39:06 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n3G8d64u030749; Thu, 16 Apr 2009 10:39:06 +0200 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n3G8d6g0003960; Thu, 16 Apr 2009 08:39:06 GMT Received: from xmb-ams-337.cisco.com ([144.254.231.82]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 16 Apr 2009 10:39:06 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 16 Apr 2009 10:39:00 +0200 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC0748FF65@xmb-ams-337.emea.cisco.com> In-Reply-To: <200904151924.n3FJOYTA025801@kelsey-ws.hq.ember.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] 6lowpan-ND vs. ROLL Thread-Index: Acm9/9Viz6VbqKz3QPGLl1aCInZ3dQAbXxJw References: <0BD8BD8B-FD05-46E9-9AD4-7E9F312AAD21@cisco.com> <257B9AAC-B5A5-4141-86B6-0E04C5DA3DA9@cs.stanford.edu> <77f1dba80904092359v5bb941eeu2f2c6f3065954bfa@mail.gmail.com> <49DF2910.3050304@gmail.com> <49DF4D3C.6040702@gmail.com> <406F3572-344F-4DE1-863D-F3F2743416AF@tzi.org> <200904102001.n3AK1KD4023958@kelsey-ws.hq.ember.com> <1239394271.6458.3451.camel@DellX1><200904102044.n3AKiZSC024343@kelsey-ws.hq.ember.com><49E0445C.900@sensinode.com> <200904111816.n3BIG1iQ002946@kelsey-ws.hq.ember.com> <7892795E1A87F04CADFCCF41FADD00FC0748FD1A@xmb-ams-337.emea.cisco.com> <200904151924.n3FJOYTA025801@kelsey-ws.hq.ember.com> From: "Pascal Thubert (pthubert)" To: "Richard Kelsey" X-OriginalArrivalTime: 16 Apr 2009 08:39:06.0294 (UTC) FILETIME=[CDAA4D60:01C9BE6E] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2753; t=1239871146; x=1240735146; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pthubert@cisco.com; z=From:=20=22Pascal=20Thubert=20(pthubert)=22=20 |Subject:=20RE=3A=20[Roll]=206lowpan-ND=20vs.=20ROLL |Sender:=20; bh=Gk9oOzlRmLU03KBo2VkFHH/dwHh3L9r/+17gVuDvONM=; b=tz6oPSB25M8eMGZEfxq+jCfpwvJbF+8Cn/q9ivUoo0RZcFkg+KmGqZta3P zaS31Td0aGJDVFdmfEJsMHxo3Z4xUuR2wWSCD/fHidNUxPuS5iah8ZaIfCvI aSce/f08KG; Authentication-Results: ams-dkim-1; header.From=pthubert@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Cc: roll@ietf.org Subject: Re: [Roll] 6lowpan-ND vs. ROLL X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Apr 2009 08:37:56 -0000 Hi Richard >In the network I was describing there are three typs of device: > - a meter, which has an essentially private backhaul network > - an energy management device, which has a connection to > a normal ISP > - one or more appliances >The appliances need to exchange messages with both the >meter and the management device, so they all need to be on >the same L2 network. > > In the second category, if the meter edge router advertises a prefix > that encompasses all that the metering applications need, then it does > not need to be advertised as default tree. The nodes can participate to > that tree as non default but since they install a route to the Tree ID > via the root of tree, all the metering traffic will go that way whereas > the default will be routed via the default tree. > >The network monitoring device, which is the one with the >(relatively) unrestricted backhaul, is optional. If it >isn't there, and the only access router is the meter, >then the network has no default tree. Is that acceptable? Well packets that do not match a route are dropped. That's certainly acceptable. > Finally MTR (listed in the advanced section) enables joining multiple > default trees if that's what you really need in a given deployment. If > you use a default route for a given packet then you need to mark the > packet to indicate which default tree you have selected, and every node > along the way have to understand that marking and follow the same tree. > An example of marking is a routing header indicating that the packet is > to be routed via the root of the selected default tree. That way, a > meter would flag its packets as metering and they would be forwarded > over the meter tree. > >Presumably the decision as to which default tree to use is >made on the basis of the destination address. That doesn't >sound like a default. Or the is choice of which default >tree to use made on the basis of some other information? That would be the previous case. Long as you route per destination that match prefixes advertised by the root you're fine, the longest match wins and you follow that tree to the root.=20 You want MTR when the qualification of the packet is the flow as opposed the destination. Say the address of the metering application in the Internet is anything and cannot be aggregated within the prefix advertised by the metering root. A meter sending a metering packet will flag it 'meter' so it follows the 'meter' default tree towards the metering edge router whereas general traffic can be flagged as 'user' to follow the tree that leads to a Home backbone and gateway. I hope it's clearer now, Pascal From jvasseur@cisco.com Thu Apr 16 06:29: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 93DCF28C14C for ; Thu, 16 Apr 2009 06:29:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.282 X-Spam-Level: X-Spam-Status: No, score=-10.282 tagged_above=-999 required=5 tests=[AWL=0.317, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UUHXnTT-QKkh for ; Thu, 16 Apr 2009 06:29:57 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 1446C28C0F9 for ; Thu, 16 Apr 2009 06:29:56 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,198,1238976000"; d="scan'208";a="38459063" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 16 Apr 2009 13:31:08 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n3GDV8LO015358 for ; Thu, 16 Apr 2009 15:31:08 +0200 Received: from xbh-ams-331.emea.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n3GDV8PA002019; Thu, 16 Apr 2009 13:31:08 GMT Received: from xfe-ams-331.emea.cisco.com ([144.254.231.72]) by xbh-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 16 Apr 2009 15:31:08 +0200 Received: from ams-jvasseur-8713.cisco.com ([10.55.201.132]) by xfe-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 16 Apr 2009 15:31:07 +0200 Message-Id: From: JP Vasseur To: dtroll@external.cisco.com Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Thu, 16 Apr 2009 15:31:07 +0200 X-Mailer: Apple Mail (2.930.3) X-OriginalArrivalTime: 16 Apr 2009 13:31:07.0821 (UTC) FILETIME=[994F25D0:01C9BE97] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2146; t=1239888668; x=1240752668; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:=20JP=20Vasseur=20 |Subject:=20Few=20comments=20for=20our=20first=20discussion =20today |Sender:=20; bh=ZJvm1/4+buYKUVA79ny0c4fxLLlENp5QEChhB50/+sA=; b=HsDRlcVrXlc4PsjGHKl43nJnTMxf9KQSFWk8n9anShb7gWskCS8W4gsqye VpqlctX4E3GNBFPYcXza/789ppDe5ak5IKKiA5Jv0IVaQrSWJznNwfa90MnD 49Yj4Ko68u; Authentication-Results: ams-dkim-2; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Cc: ROLL WG Subject: [Roll] Few comments for our first discussion today X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 16 Apr 2009 13:29:58 -0000 Dear all, First many thanks again for accepting to be part of the DT. I did not want to comment on the various individual submissions so far since it was much more appropriate to provide feed-back to the DT, especially because the authors of these drafts are part of the DT. Please find below some comments (that apply to the IDs already posted): - No Layer-2 dependency: We do need to avoid any layer-2 dependency. It is of course fine to refer to specific optimization on 15.4 but I saw in some proposals assumptions that we would be using 16-bit identifier a la "6LoWPAN" for example: the routing protocol MUST be media "agnostic" (no layer dependencies). There are other areas where the routing mandates ACK at layer 2, which may not be available. It is fine to benefit from L2 related information bearing in mind that they may not be available, thus they should not be mandatory for the routing protocol to operate. - We need to have a discussion on whether temporary (or bounded) loops are acceptable. - We also need to define how to perform non shortest path selection (constrained based routing): label/flow switch versus source routing - We will need to carefully consider the option of either extending existing IPv6 packets (e.g. ND) versus defining new packets. - In some proposals I saw a combination of periodic refresh mechanisms for prefix dissemination *and* mechanism to explicitly withdraw some prefixes: we do not need both. The point here is that each time we consider several options we will need to look at the consequences in term of: * States maintenance in a router * Control plane traffic in the network (e.g. header overhead in case of source routing or loop detection for example, periodic route refresh, ...) * Manageability and Security - Careful consideration must be given to auto-adaptative behavior. Since the routing protocol will adapt to a wide range of situations *and* considering that 0-config is a MUST from most of the routing requirements ID, protocol auto-adaptation (e.g. timers) is critical. Thanks. JP From jvasseur@cisco.com Thu Apr 16 10:04: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 3A65D28C245 for ; Thu, 16 Apr 2009 10:04:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.287 X-Spam-Level: X-Spam-Status: No, score=-8.287 tagged_above=-999 required=5 tests=[AWL=-1.688, 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 GseLDEddFy+z for ; Thu, 16 Apr 2009 10:04:51 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id 4166428C234 for ; Thu, 16 Apr 2009 10:04:51 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,199,1238976000"; d="scan'208";a="155525766" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by sj-iport-2.cisco.com with ESMTP; 16 Apr 2009 17:06:03 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n3GH625X017592 for ; Thu, 16 Apr 2009 19:06:02 +0200 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n3GH62GK012845 for ; Thu, 16 Apr 2009 17:06:02 GMT Received: from xfe-ams-331.emea.cisco.com ([144.254.231.72]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 16 Apr 2009 19:06:01 +0200 Received: from ams-jvasseur-8713.cisco.com ([10.55.201.132]) by xfe-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 16 Apr 2009 19:06:01 +0200 Message-Id: <3D13276C-5823-40DE-8DFB-BFD0F39901EF@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 v930.3) Date: Thu, 16 Apr 2009 19:06:00 +0200 References: <7892795E1A87F04CADFCCF41FADD00FC074F5E28@xmb-ams-337.emea.cisco.com> X-Mailer: Apple Mail (2.930.3) X-OriginalArrivalTime: 16 Apr 2009 17:06:01.0609 (UTC) FILETIME=[9E9B0F90:01C9BEB5] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2049; t=1239901562; x=1240765562; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:=20JP=20Vasseur=20 |Subject:=20IPR=20Statement=20RE=3A=20draft-thubert-roll-fu ndamentals |Sender:=20; bh=087ixGOYN7qq61qvjNe3OQbWwAh7edmSr6iPZiEgwU4=; b=eI8YJuTiODPz0b5Lrg81QXBmvNx60IWrCahjxNWumIcv2g/O7MkNBOVRtN JhKCr+DjrA73cXf4opAMsDcrtF8MF7+vqs0WS0NsHVA7zE3A+MJ3X5QtWe9b 0x+kVuZylQ; Authentication-Results: ams-dkim-2; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Subject: [Roll] IPR Statement RE: draft-thubert-roll-fundamentals X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 16 Apr 2009 17:04:52 -0000 FYI, Thanks. JP. > -----Original Message----- > From: Rachel Albright -X (ralbrigh - Unknown at Cisco) > Sent: mercredi 15 avril 2009 22:03 > To: ietf-ipr@ietf.org > Cc: Pascal Thubert (pthubert) > Subject: IPR Statement RE: draft-thubert-roll-fundamentals > > Cisco is the owner of US Patent Nos. 7,190,678, 7,203,175, 7,209,978, > 7,366,111 and 7,428,221, US Published Patent Applications 20060291404 > and 20070091811, and US Patent Application Serial Nos. 11/714,884 and > 11/984,049 relating to the subject matter of "LLN Routing > Fundamentals" > . > > If technology in this document is included in a standard adopted by > IETF > and any claims of any Cisco patents are necessary for practicing the > standard, any party will have the right to use any such patent claims > under reasonable, non-discriminatory terms, with reciprocity, to > implement and fully comply with the standard. > > The reasonable non-discriminatory terms are: > > If this standard is adopted, Cisco will not assert any patents owned > or > controlled by Cisco against any party for making, using, selling, > importing or offering for sale a product that implements the standard, > provided, however that Cisco retains the right to assert its patents > (including the right to claim past royalties) against any party that > asserts a patent it owns or controls (either directly or indirectly) > against Cisco or any of Cisco's affiliates or successors in title or > against any products of Cisco or any products of any of Cisco's > affiliates either alone or in combination with other products; and > Cisco > retains the right to assert its patents against any product or portion > thereof that is not necessary for compliance with the standard. > > Royalty-bearing licenses will be available to anyone who prefers that > option. > > For information contact: > > Dan Lang > Director, Intellectual Property > Cisco Systems > +1 408-526-6672 > standards-ipr@cisco.com > From jvasseur@cisco.com Fri Apr 17 01: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 960783A6AC2 for ; Fri, 17 Apr 2009 01:39:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.268 X-Spam-Level: X-Spam-Status: No, score=-10.268 tagged_above=-999 required=5 tests=[AWL=0.331, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ktJitKlMt5kR for ; Fri, 17 Apr 2009 01:39:54 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 03C8D3A69F2 for ; Fri, 17 Apr 2009 01:39:53 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,203,1238976000"; d="scan'208";a="38518189" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 17 Apr 2009 08:41:06 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n3H8f6cZ009594; Fri, 17 Apr 2009 10:41:06 +0200 Received: from xbh-ams-331.emea.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n3H8f6fa008358; Fri, 17 Apr 2009 08:41:06 GMT Received: from xfe-ams-331.emea.cisco.com ([144.254.231.72]) by xbh-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 17 Apr 2009 10:41:06 +0200 Received: from ams-jvasseur-8713.cisco.com ([10.55.201.132]) by xfe-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 17 Apr 2009 10:41:05 +0200 Message-Id: <4823B598-3B43-4216-BF2D-33C54FE9F35A@cisco.com> From: JP Vasseur To: Zach Shelby In-Reply-To: <49E041A2.9020206@sensinode.com> Content-Type: text/plain; charset=WINDOWS-1252; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v930.3) Date: Fri, 17 Apr 2009 10:41:04 +0200 References: <7892795E1A87F04CADFCCF41FADD00FC074276FB@xmb-ams-337.emea.cisco.com> <200904101756.n3AHusWx022894@kelsey-ws.hq.ember.com> <49E041A2.9020206@sensinode.com> X-Mailer: Apple Mail (2.930.3) X-OriginalArrivalTime: 17 Apr 2009 08:41:05.0541 (UTC) FILETIME=[3F27B350:01C9BF38] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3652; t=1239957666; x=1240821666; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:=20JP=20Vasseur=20 |Subject:=20Re=3A=20[Roll]=20FW=3A=20New=20Version=20Notifi cation=09for=09draft-thubert-roll-fundamentals-01 |Sender:=20; bh=nU2jseYJVTAW7xMysmn92h3fprBIueOOCpP/0fwCJ6w=; b=oNOWraF5u/PUFyp4wb5G1DICG4Pnww2H/ATbDdI7LeleHGpO6U3uMAdFav QhCVmFfD3R5Nsac1sro3zYs+221UjKk3bLoY1BmZz6UX+b8ZPM+HV9vjIXbA mjUmexDQCd; Authentication-Results: ams-dkim-2; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Cc: roll@ietf.org Subject: Re: [Roll] FW: New Version Notification for draft-thubert-roll-fundamentals-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: Fri, 17 Apr 2009 08:39:55 -0000 Hi Zach, On Apr 11, 2009, at 9:07 AM, Zach Shelby wrote: > Richard, > > Richard Kelsey wrote: >> From: Philip Levis >> Date: Fri, 10 Apr 2009 06:52:04 -0700 >> On Apr 9, 2009, at 1:59 AM, Pascal Thubert (pthubert) wrote: >> > Basically, since we have a depth, we have feasible parents =20 >> (of > lesser depth) and siblings (of same depth). The draft =20 >> suggests that > we can select any parent to forward on a per =20 >> packet basis using the > best metric or more advanced load =20 >> balancing functionality; if that > fails then we can use a =20 >> sibling with some basic loop avoidance like > poison return or =20= >> more advanced path vector (for hydrophiles). >> Here's a URL to a paper that describes one way to solve this =20 >> problem, using the techniques I mentioned a few weeks ago and =20 >> touched on in my talk in SF: >> http://sing.stanford.edu/pubs/ctp.pdf >> Good stuff. Relating this back to the Routing Fundamentals >> draft, it seems clear that ROLL will most likely use trees >> for at least some routing, and while Router Advertisements >> can be used to build trees, it will be good if tree >> building and/or maintenance can be performed independently >> of Router Advertisements. They add too much overhead >> to make it easy to react quickly to changing conditions. > > Don't think of router advertisements as overhead - as we are working =20= > with IP networks you will always have RAs as they are an integral =20 > part of network bootstrapping and maintenance (Neighbor Discovery). =20= > As you have RAs anyways, you might as well piggyback some tree =20 > information. Trickle can also be used to optimize the RA traffic to =20= > an appropriate level. > > The same can be said about other ND traffic in these networks such =20 > as NS/NAs (IPv6), or RR/RCs (in 6LoWPAN). If you have the ND traffic =20= > anyways, piggybacking is good. > > That said, I do see the need for carrying metric information (as =20 > done in the CTP protocol Phil is referencing) in data traffic (using =20= > an IPv6 hop-by-hop option) especially for very dynamic networks. I =20 > had this in mind when we wrote the Routing Fundamentals draft as an =20= > option. =46rom my practical experience it is useful, and only needs to = =20 > be applied to 1-10% of data packets depending on how dynamic the =20 > network is. > I do agree with you ... Just a word of cautious though. Piggybacking =20 can be an interesting option but we need to be a bit careful at not =20 spreading out routing control plane traffic in N existing protocols. =20 In this particular I do not want to wait for traffic to make my =20 routing decision. Cheers, JP. > - Zach > > >> -Richard Kelsey >> _______________________________________________ >> Roll mailing list >> Roll@ietf.org >> https://www.ietf.org/mailman/listinfo/roll > > --=20 > http://zachshelby.org - My blog =93On the Internet of Things=94 > Mobile: +358 40 7796297 > > Zach Shelby > Head of Research > Sensinode Ltd. > Kidekuja 2 > 88610 Vuokatti, FINLAND > > This e-mail and all attached material are confidential and may =20 > contain legally privileged information. If you are not the intended =20= > recipient, please contact the sender and delete the e-mail from your =20= > system without producing, distributing or retaining copies thereof. > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From jvasseur@cisco.com Fri Apr 17 01:48: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 58B313A6EA5 for ; Fri, 17 Apr 2009 01:48:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.272 X-Spam-Level: X-Spam-Status: No, score=-10.272 tagged_above=-999 required=5 tests=[AWL=0.327, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z2S4C8wANv5n for ; Fri, 17 Apr 2009 01:48:37 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id D532A3A6D4A for ; Fri, 17 Apr 2009 01:48:36 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,203,1238976000"; d="scan'208";a="38519329" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 17 Apr 2009 08:49:47 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n3H8nlVJ004433; Fri, 17 Apr 2009 10:49:47 +0200 Received: from xbh-ams-331.emea.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n3H8nlbY011456; Fri, 17 Apr 2009 08:49:47 GMT Received: from xfe-ams-332.cisco.com ([144.254.231.73]) by xbh-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 17 Apr 2009 10:49:47 +0200 Received: from ams-jvasseur-8713.cisco.com ([10.55.201.132]) by xfe-ams-332.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 17 Apr 2009 10:49:46 +0200 Message-Id: From: JP Vasseur To: Philip Levis In-Reply-To: <0719A7FB-BEC0-4CB2-9EF0-4CD4CE4CDE26@cs.stanford.edu> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Fri, 17 Apr 2009 10:49:43 +0200 References: <7892795E1A87F04CADFCCF41FADD00FC074276FB@xmb-ams-337.emea.cisco.com> <200904101756.n3AHusWx022894@kelsey-ws.hq.ember.com> <49E041A2.9020206@sensinode.com> <200904131004.n3DA4gxC028339@kelsey-ws.hq.ember.com> <0719A7FB-BEC0-4CB2-9EF0-4CD4CE4CDE26@cs.stanford.edu> X-Mailer: Apple Mail (2.930.3) X-OriginalArrivalTime: 17 Apr 2009 08:49:46.0408 (UTC) FILETIME=[759DB280:01C9BF39] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2745; t=1239958187; x=1240822187; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:=20JP=20Vasseur=20 |Subject:=20Re=3A=20[Roll]=20FW=3A=20New=20Version=20Notifi cation=09for=09draft-thubert-roll-fundamentals-01 |Sender:=20; bh=UVDiJaj+uZpxUGm1KoV0zoNWJYOCtANABjftioOg/2s=; b=afYsr3NnSKxoUlyf7tEciLcUw4h3dmbeZj3VrwFFxRFlWI1fLEvv89s/wy tRVEJBCPbd8zy/SGktYP4EGU2GF3TcQkV87VwxN3kuADCU4J5bjBFuKUh9Bd vtFxrZf6Yj; Authentication-Results: ams-dkim-1; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Cc: roll@ietf.org Subject: Re: [Roll] FW: New Version Notification for draft-thubert-roll-fundamentals-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: Fri, 17 Apr 2009 08:48:38 -0000 [snip] >> I >> don't know if that low a response time is necessary, but it >> does seem clear that tree topology will sometimes be >> changing much faster than the data in the RAs. If new tree >> information needs to be sent, but new RA information does >> not, then the RA data is overhead. > > I agree with this: it's the exact problem that adaptive beaconing > tries to solve. Any periodic RA mechanism introduces a tough > tradeoff: beacon faster for fast adaptation but high cost, or beacon > slower for efficiency but slow adaptation. Right and this is not specific to RA but any routing protocol control plane. Look at routing protocol such as OSPF. If you quickly want to detect a failure, you increase the periodic hellos or use BFD: more overhead, higher cost faster reaction. It is just that in LLN higher cost is a serious issue, thus the need for Trickle but I do not need to convince you there ;-) > Hence the point of borrowing and extending Trickle -- send just > enough RAs for nodes to discover each other and verify that the tree > is still consistent. Data path validation allows the protocol to > verify the tree's consistency without introducing additional (RA) > overhead. There seems to be a confusion floating around: we do not need to recompute the tree/DAG to find an alternate path. The backup path MUST be in place before any failure thanks to the use of an alternate parent/sibling in forwarding or alternate parent in a DAG or alternate tree. > > >> I am not suggesting that we not piggyback tree information >> on RAs, just that it would be good to also be able to >> piggyback it on other messages or send it independently. > > The design question here is *what* information to piggyback. One > interesting way that the paper I sent out differs from Jonathan's IP > stack is his stack includes hop count in data packets (Section 8.1.4 > of the SenSys 2008 paper). From an academic standpoint, it would be > an interesting evaluation to see whether the cost of this field is > less than the cost of false positives on CTP's loop detection (the > case where a node's ETX goes up but its children don't know yet, so > it thinks there might be a loop). I say it's academic because my > guess is that it's a comparatively small difference either way, > compared to other, more important issues. > > Om -- this might be a nice experiment to look at from the traces, > just compute how often CTP beacon resets are false positives on loop > detection. > > Phil > > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From richard.kelsey@ember.com Fri Apr 17 10:55: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 56A403A6FA9 for ; Fri, 17 Apr 2009 10:55:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 VFupYkqNrsVJ for ; Fri, 17 Apr 2009 10:55:29 -0700 (PDT) Received: from EMPIRE.hq.ember.com (mail.ember.com [74.10.175.227]) by core3.amsl.com (Postfix) with ESMTP id 6D8063A6E63 for ; Fri, 17 Apr 2009 10:55:29 -0700 (PDT) Received: from kelsey-ws.hq.ember.com ([192.168.81.55]) by EMPIRE.hq.ember.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 17 Apr 2009 13:57:31 -0400 Received: from kelsey-ws.hq.ember.com (localhost.localdomain [127.0.0.1]) by kelsey-ws.hq.ember.com (8.13.4/8.13.4) with ESMTP id n3HHugEY003064; Fri, 17 Apr 2009 13:56:42 -0400 Received: (from kelsey@localhost) by kelsey-ws.hq.ember.com (8.13.4/8.12.8/Submit) id n3HHuf9n003061; Fri, 17 Apr 2009 13:56:42 -0400 Date: Fri, 17 Apr 2009 13:56:42 -0400 Message-Id: <200904171756.n3HHuf9n003061@kelsey-ws.hq.ember.com> To: jvasseur@cisco.com In-reply-to: (message from JP Vasseur on Fri, 17 Apr 2009 10:49:43 +0200) From: Richard Kelsey References: <7892795E1A87F04CADFCCF41FADD00FC074276FB@xmb-ams-337.emea.cisco.com> <200904101756.n3AHusWx022894@kelsey-ws.hq.ember.com> <49E041A2.9020206@sensinode.com> <200904131004.n3DA4gxC028339@kelsey-ws.hq.ember.com> <0719A7FB-BEC0-4CB2-9EF0-4CD4CE4CDE26@cs.stanford.edu> X-OriginalArrivalTime: 17 Apr 2009 17:57:32.0216 (UTC) FILETIME=[FB2A0380:01C9BF85] Cc: roll@ietf.org Subject: Re: [Roll] FW: New Version Notification for draft-thubert-roll-fundamentals-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: Fri, 17 Apr 2009 17:55:30 -0000 From: JP Vasseur Date: Fri, 17 Apr 2009 10:49:43 +0200 There seems to be a confusion floating around: we do not need to recompute the tree/DAG to find an alternate path. The backup path MUST be in place before any failure thanks to the use of an alternate parent/sibling in forwarding or alternate parent in a DAG or alternate tree. Does the requirement for a backup path stem from some particular reliability or latency requirement? Whether having a precomputed backup path performs better or worse than a local on-demand tree recomputation would seem to depend on the particular details of the protocols used and the stability characteristics of the network. For example, it isn't at all clear to me how configuring redundant paths using HYDRO would perform compared to the Collection Tree Protocol's local recomputation. It would be interesting to try them both out on a selection of deployed networks; it would also be a lot of work. -Richard Kelsey From jvasseur@cisco.com Fri Apr 17 11:03: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 B8E183A6E39 for ; Fri, 17 Apr 2009 11:03:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.277 X-Spam-Level: X-Spam-Status: No, score=-10.277 tagged_above=-999 required=5 tests=[AWL=0.322, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xLOJb0AQxF3y for ; Fri, 17 Apr 2009 11:03:26 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 53C563A6872 for ; Fri, 17 Apr 2009 11:03:26 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,205,1238976000"; d="scan'208";a="38583109" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 17 Apr 2009 18:04:39 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n3HI4dS2005733; Fri, 17 Apr 2009 20:04:39 +0200 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n3HI4dS2004870; Fri, 17 Apr 2009 18:04:39 GMT Received: from xfe-ams-331.emea.cisco.com ([144.254.231.72]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 17 Apr 2009 20:04:39 +0200 Received: from ams-jvasseur-8713.cisco.com ([10.55.201.132]) by xfe-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 17 Apr 2009 20:04:38 +0200 Message-Id: <4F518D3B-70C3-4C39-BECF-534FFF5D9677@cisco.com> From: JP Vasseur To: Richard Kelsey In-Reply-To: <200904171756.n3HHuf9n003061@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 v930.3) Date: Fri, 17 Apr 2009 20:04:37 +0200 References: <7892795E1A87F04CADFCCF41FADD00FC074276FB@xmb-ams-337.emea.cisco.com> <200904101756.n3AHusWx022894@kelsey-ws.hq.ember.com> <49E041A2.9020206@sensinode.com> <200904131004.n3DA4gxC028339@kelsey-ws.hq.ember.com> <0719A7FB-BEC0-4CB2-9EF0-4CD4CE4CDE26@cs.stanford.edu> <200904171756.n3HHuf9n003061@kelsey-ws.hq.ember.com> X-Mailer: Apple Mail (2.930.3) X-OriginalArrivalTime: 17 Apr 2009 18:04:38.0525 (UTC) FILETIME=[F9439AD0:01C9BF86] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1507; t=1239991479; x=1240855479; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:=20JP=20Vasseur=20 |Subject:=20Re=3A=20[Roll]=20FW=3A=20New=20Version=20Notifi cation=09for=09draft-thubert-roll-fundamentals-01 |Sender:=20; bh=ViDjRDcA/OC6fswDUzwiFr4azOoy98I44xdrSal/GQk=; b=Tz/M5HyZCUxiktC2kYqlox/iAjXWv8qYHRLTpyARom3I7ZigG6bYfbGE0j BLp6VuH37mugfpeQmmzo7j+umV41OTgo1jjvtpOi6SYD0wb98Ontm9r6ygb4 orLiMBo3z4; Authentication-Results: ams-dkim-1; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Cc: roll@ietf.org Subject: Re: [Roll] FW: New Version Notification for draft-thubert-roll-fundamentals-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: Fri, 17 Apr 2009 18:03:27 -0000 Hi Richard, On Apr 17, 2009, at 7:56 PM, Richard Kelsey wrote: > From: JP Vasseur > Date: Fri, 17 Apr 2009 10:49:43 +0200 > > There seems to be a confusion floating around: we do not need to > recompute the tree/DAG to find an alternate path. The backup path > MUST > be in place before any failure thanks to the use of an alternate > parent/sibling in forwarding or alternate parent in a DAG or > alternate > tree. > > Does the requirement for a backup path stem from some > particular reliability or latency requirement? Whether > having a precomputed backup path performs better or worse > than a local on-demand tree recomputation would seem to > depend on the particular details of the protocols used and > the stability characteristics of the network. For example, > it isn't at all clear to me how configuring redundant paths > using HYDRO would perform compared to the Collection Tree > Protocol's local recomputation. It would be interesting to > try them both out on a selection of deployed networks; it > would also be a lot of work. > The major advantage of "local reroute" is not only to improve the convergence time but also to limit the repair scope as opposed to recompute an entire tree/DAG/... Cheers. JP. > -Richard Kelsey > > > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From pal@cs.stanford.edu Fri Apr 17 11:49:10 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CBFD83A6E39 for ; Fri, 17 Apr 2009 11:49:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C+7EwxghMfdP for ; Fri, 17 Apr 2009 11:49:09 -0700 (PDT) Received: from cs-smtp-3.Stanford.EDU (cs-smtp-3.Stanford.EDU [171.64.64.27]) by core3.amsl.com (Postfix) with ESMTP id E81D53A6E43 for ; Fri, 17 Apr 2009 11:49:09 -0700 (PDT) Received: from dnab42217b.stanford.edu ([171.66.33.123]) by cs-smtp-3.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1Lut8p-0006QR-Og; Fri, 17 Apr 2009 11:50:23 -0700 Message-Id: From: Philip Levis To: JP Vasseur In-Reply-To: <4F518D3B-70C3-4C39-BECF-534FFF5D9677@cisco.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Fri, 17 Apr 2009 11:50:23 -0700 References: <7892795E1A87F04CADFCCF41FADD00FC074276FB@xmb-ams-337.emea.cisco.com> <200904101756.n3AHusWx022894@kelsey-ws.hq.ember.com> <49E041A2.9020206@sensinode.com> <200904131004.n3DA4gxC028339@kelsey-ws.hq.ember.com> <0719A7FB-BEC0-4CB2-9EF0-4CD4CE4CDE26@cs.stanford.edu> <200904171756.n3HHuf9n003061@kelsey-ws.hq.ember.com> <4F518D3B-70C3-4C39-BECF-534FFF5D9677@cisco.com> X-Mailer: Apple Mail (2.930.3) X-Scan-Signature: a11a15d02c0ec4233875b3872b0caebb Cc: roll@ietf.org Subject: Re: [Roll] FW: New Version Notification for draft-thubert-roll-fundamentals-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: Fri, 17 Apr 2009 18:49:10 -0000 On Apr 17, 2009, at 11:04 AM, JP Vasseur wrote: >> > > The major advantage of "local reroute" is not only to improve the > convergence > time but also to limit the repair scope as opposed to recompute an > entire tree/DAG/... The problem with pursuing stability is that it comes at a cost of efficiency. I think that one of the lessons you can draw from the CTP paper, and wireless measurement studies in general, is that the idea of "convergence time" is a red herring. It implies that the underlying wireless network is itself stable on time scales well beyond a few packets, suggesting there is some notion of the "true" network topology that you wish to converge to. But this is often really not the case. You can pick only highly stable links with a high SNR, but in so doing waste energy. Furthermore, interference means that the link-layer topology itself changes with load. That being said, limiting repair scope is a good design principle. Phil From pister@eecs.berkeley.edu Sat Apr 18 15:37: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 9415A3A6EF5 for ; Sat, 18 Apr 2009 15:37:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.74 X-Spam-Level: X-Spam-Status: No, score=-4.74 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K17cGa1fJ61G for ; Sat, 18 Apr 2009 15:37:33 -0700 (PDT) Received: from gateway0.EECS.Berkeley.EDU (gateway0.EECS.Berkeley.EDU [169.229.60.87]) by core3.amsl.com (Postfix) with ESMTP id CF3F93A6947 for ; Sat, 18 Apr 2009 15:37:33 -0700 (PDT) Received: from [75.208.178.81] (81.sub-75-208-178.myvzw.com [75.208.178.81]) (authenticated bits=0) by gateway0.EECS.Berkeley.EDU (8.14.3/8.13.5) with ESMTP id n3IMceP9027390 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 18 Apr 2009 15:38:42 -0700 (PDT) Message-ID: <49EA5694.9050205@eecs.berkeley.edu> Date: Sat, 18 Apr 2009 15:39:16 -0700 From: Kris Pister User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Philip Levis References: <7892795E1A87F04CADFCCF41FADD00FC074276FB@xmb-ams-337.emea.cisco.com> <200904101756.n3AHusWx022894@kelsey-ws.hq.ember.com> <49E041A2.9020206@sensinode.com> <200904131004.n3DA4gxC028339@kelsey-ws.hq.ember.com> <0719A7FB-BEC0-4CB2-9EF0-4CD4CE4CDE26@cs.stanford.edu> <200904171756.n3HHuf9n003061@kelsey-ws.hq.ember.com> <4F518D3B-70C3-4C39-BECF-534FFF5D9677@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: roll@ietf.org Subject: Re: [Roll] FW: New Version Notification for draft-thubert-roll-fundamentals-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: Sat, 18 Apr 2009 22:37:34 -0000 Let's be careful to stay link agnostic. Convergence time is definitely not a red herring with a channel hopping 15.4 wireless DLL, for example. If you hop on at least a handful of channels in the 2.4GHz spectrum your links are in fact stable on time scales well beyond a few packets. Individual channels often vary from 100% to 0% PDR and back again on short time scales, but the link average remains relatively constant in commercial and industrial environments over periods of hours to months. In many of these networks there really are long-lived "true" network topologies, and corresponding optimal routes. I imagine this will also be true for networks with PLC links as well. ksjp Philip Levis wrote: > > The problem with pursuing stability is that it comes at a cost of > efficiency. I think that one of the lessons you can draw from the CTP > paper, and wireless measurement studies in general, is that the idea > of "convergence time" is a red herring. It implies that the underlying > wireless network is itself stable on time scales well beyond a few > packets, suggesting there is some notion of the "true" network > topology that you wish to converge to. But this is often really not > the case. You can pick only highly stable links with a high SNR, but > in so doing waste energy. Furthermore, interference means that the > link-layer topology itself changes with load. > > That being said, limiting repair scope is a good design principle. > > Phil > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From root@core3.amsl.com Tue Apr 21 00: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 9D9DA3A6AF9; Tue, 21 Apr 2009 00:30:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090421073001.9D9DA3A6AF9@core3.amsl.com> Date: Tue, 21 Apr 2009 00:30:01 -0700 (PDT) Cc: roll@ietf.org Subject: [Roll] I-D Action:draft-ietf-roll-indus-routing-reqs-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, 21 Apr 2009 07:30: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 : Industrial Routing Requirements in Low Power and Lossy Networks Author(s) : D. Networks, et al. Filename : draft-ietf-roll-indus-routing-reqs-05.txt Pages : 25 Date : 2009-04-21 The wide deployment of lower cost wireless devices will significantly improve the productivity and safety of the plants while increasing the efficiency of the plant workers by extending the information set available about the plant operations. The aim of this document is to analyze the functional requirements for a routing protocol used in industrial Low power and Lossy Networks (LLN) of field devices. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-roll-indus-routing-reqs-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-indus-routing-reqs-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-04-21001744.I-D@ietf.org> --NextPart-- From david.bruemmer@johnsondiversey.com Tue Apr 21 14: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 494B53A6F9B for ; Tue, 21 Apr 2009 14:01:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.289 X-Spam-Level: X-Spam-Status: No, score=-2.289 tagged_above=-999 required=5 tests=[AWL=0.310, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sCZuhJZZoiE9 for ; Tue, 21 Apr 2009 14:01:50 -0700 (PDT) Received: from usstuh502.johnsondiversey.com (mail4.johnsondiversey.com [208.251.229.31]) by core3.amsl.com (Postfix) with ESMTP id 7A4353A6C61 for ; Tue, 21 Apr 2009 14:01:50 -0700 (PDT) From: david.bruemmer@johnsondiversey.com To: roll@ietf.org Message-ID: Date: Tue, 21 Apr 2009 16:02:38 -0500 X-MIMETrack: Serialize by Router on USSTUH502/SVR/CMI(Release 7.0.3FP1|February 24, 2008) at 04/21/2009 16:03:07 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Subject: [Roll] David Bruemmer is out of the office. X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 21 Apr 2009 21:01:51 -0000 I will be out of the office starting 04/21/2009 and will not return until 04/22/2009. Therefore I will process your e-mail on Wednesday. From zahariad@teihal.gr Thu Apr 23 11:37:17 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3ACB328C166 for ; Thu, 23 Apr 2009 11:37:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.336 X-Spam-Level: X-Spam-Status: No, score=0.336 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iYfh4yNuIGyl for ; Thu, 23 Apr 2009 11:37:16 -0700 (PDT) Received: from outbound-mail-18.bluehost.com (outbound-mail-18.bluehost.com [69.89.20.233]) by core3.amsl.com (Postfix) with SMTP id F2D2428C14C for ; Thu, 23 Apr 2009 11:37:14 -0700 (PDT) Received: (qmail 20099 invoked by uid 0); 23 Apr 2009 17:37:02 -0000 Received: from unknown (HELO box521.bluehost.com) (74.220.219.121) by outboundproxy1.bluehost.com with SMTP; 23 Apr 2009 17:37:02 -0000 Received: from ppp-94-66-54-14.home.otenet.gr ([94.66.54.14] helo=sVAIO) by box521.bluehost.com with smtp (Exim 4.69) (envelope-from ) id 1Lx3oc-0001Xk-De; Thu, 23 Apr 2009 12:38:32 -0600 Message-ID: <731FE93954BB4192BC6AD25893E2A908@sVAIO> From: "Theodore Zahariadis" To: Date: Thu, 23 Apr 2009 21:38:25 +0300 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_074B_01C9C45B.D545A8B0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Windows Mail 6.0.6001.18000 X-MimeOLE: Produced By Microsoft MimeOLE V6.0.6001.18049 X-Identified-User: {712:box521.bluehost.com:synelixi:synelixis.com} {sentby:bopbeforesmtp 94.66.54.14 authed with synelixis.com} Cc: Sotiris Maniatis , Panagiotis Trakadas , Manuel.CARVALHOSA@ec.europa.eu Subject: [Roll] Trust Management & draft-tsao-roll-security-framework-00 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Apr 2009 18:46:11 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_074B_01C9C45B.D545A8B0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dear all, =20 Thank you for allowing me any my team in the ROLL email list and sharing = our thoughts with you. First of all let me introduce myself. My name is Theodore Zahariadis and = I am the Technical Manager of the project AWISSENET.=20 AWISSENET started on 1/1/2008 and is partially funded by EC under FP7. = It includes key industrial partners e.g. Hellenic Aerospace Industry, = Alcatel-Lucent and Thales Communications. Among its main objectives is = to design, simulate and implement a secure routing scheme for Wireless = Sensor Networks. So far, we have designed a trust management scheme, = which includes both direct and indirect trust, weighting factors' = values, which are auto-adjusted according to the attacks, and node's = energy information. Then, we modified the GPSR protocol in order to = include both trust and energy-efficient metrics and simulated the result = in J-Sim. The simulations show that the scheme can provide energy-aware = routing paths that bypass malicious nodes of many kinds. From our = experience, up to now, sensor nodes resources are adequate for = implementing at least some of the trust metrics; thus currently, we are = implementing the scheme in TinyOS v2.1 on IRIS and MicaZ motes. More = info may be found at www.awissenet.eu. =20 In this context, we think that trust for LLN could be in conformance = with the application-specific documents in ROLL. In more details: =20 Trust models for sensor networks [1-3] allow for detecting a list of = attacks including black-hole, selective forwarding, = integrity/modification attacks. The nodes may also exchange opinions as = regards the trustworthiness of their neighbors [4-5]. Trust & reputation = information can be accelerated for new-comers, i.e. is useful in case of = mobile nodes and/or newly initiated nodes. =20 The draft-tsao-roll-security-framework-00 provides an excellent = description of a security framework for sensor networks. In section = 5.3.3, the selective forwarding attack is described and two = countermeasures are sought. We believe, that a third way to defend = against this attack may be to realize a trust model i.e. in case = messages are not encrypted (and this may be the case in the majority of = sensor networks), each node monitors/overhears the behavior of its = neighbors in order to check whether they sincerely execute the routing = protocol and behave as expected. If for example, node A selects node B = for forwarding packet P1, after transmitting the packet, node A = overhears the wireless medium in order to check whether node B actually = forwarded the packet P1 correctly. The end result is that each node = calculates the trustworthiness of its neighbors and then takes into = account this information to avoid choosing malicious nodes during = routing decisions, either for key distribution [1], for data aggregation = or for cluster head election.=20 =20 Also, in the definition of selective forwarding, the case where a = malicious node behaves differently towards different neighbors could = also be covered. i.e. maybe by replacing the sentence "An insider = malicious node basically blends neatly in with the network but then may = decide to forward and/or manipulate certain packets." with "An insider = malicious node basically blends neatly in with the network, but then may = decide to forward and/or manipulate certain packets from all or part of = its neighbors." This behavior is called conflicting behavior in [6]. =20 [1] Nathan Lewis, Noria Foukia, "Using Trust for Key Distribution and = Route Selection in Wireless Sensor Networks" IEEE Globecom 2007, 26-30 = Nov. 2007=20 [2] A.A. Pirzada and C. McDonald, "Trust Establishment In Pure Ad-hoc = Networks", Wireless Personal Communications Vol. 37, 2006, pp: 139-163 [3] Sapon Tanachaiwiwat, Pinalkumar Dave, Rohan Bhindwale, Ahmed = Helmy "Location-centric Isolation of Misbehavior and Trust Routing in = Energy-constrained Sensor Networks" IEEE International Conference on = Performance, Computing, and Communications, 2004 [4] G. Theodorakopoulos and J. S. Baras, "On Trust Models and Trust = Evaluation Metrics for Ad-Hoc Networks," IEEE Journal on Selected Areas = in Communications (JSAC), Feb. 2006. [5] S. Ganeriwal and M. B. Srivastava. Reputation-Based Framework for = High Integrity Sensor Networks. In 2nd ACM Workshop on Security of Ad = Hoc and Sensor Networks., pages 66-77, Washington, DC, USA, 2004 [6] Yan (Lindsay) Sun, Zhu Han, K. J. Ray Liu, "Defense of Trust = Management Vulnerabilities in Distributed Networks", IEEE Communications = Magazine, Vol. 25, No.2, February 2008, pp. 112-119. Looking forward to hearing from you, Theodore ------------------------------------------------------ Dr. Theodore Zahariadis Ass. Professor, TEI of Chalkida Email: zahariad@teihal.gr ------=_NextPart_000_074B_01C9C45B.D545A8B0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Dear = all,

 

Thank you for = allowing me any my=20 team in the ROLL email list and sharing our thoughts with = you.

 

First of all let me = introduce=20 myself. My name is Theodore Zahariadis and I am the Technical Manager of = the=20 project AWISSENET.

AWISSENET started = on 1/1/2008 and=20 is partially funded by EC under FP7. It includes key industrial partners = e.g.=20 Hellenic Aerospace Industry, Alcatel-Lucent and Thales Communications. = Among its=20 main objectives is to design, simulate and implement a secure routing = scheme for=20 Wireless Sensor Networks. So far, we have designed a trust management = scheme,=20 which includes both direct and indirect trust, weighting factors=92 = values, which=20 are auto-adjusted according to the attacks, and node=92s energy = information. Then,=20 we modified the GPSR protocol in order to include both trust and=20 energy-efficient metrics and simulated the result in J-Sim. The = simulations show=20 that the scheme can provide energy-aware routing paths that bypass = malicious=20 nodes of many kinds. From our experience, up to now, sensor nodes = resources are=20 adequate for implementing at least some of the trust metrics; thus = currently, we=20 are implementing the scheme in TinyOS v2.1 on IRIS and MicaZ motes. More = info=20 may be found at www.awissenet.eu.

 

In this context, we think that trust = for LLN could=20 be in conformance with the application-specific documents in ROLL. In = more=20 details:

 

Trust models for sensor networks [1-3] allow = for=20 detecting a list of attacks including black-hole, selective forwarding,=20 integrity/modification attacks. The nodes may also exchange opinions as = regards=20 the trustworthiness of their neighbors [4-5]. Trust & reputation = information=20 can be accelerated for new-comers, i.e. is useful in case of mobile = nodes and/or=20 newly initiated nodes.

 

The draft-tsao-roll-security-framework-00 = provides an=20 excellent description of a security framework for sensor networks. In = section=20 5.3.3, the selective forwarding attack is described and two = countermeasures are=20 sought. We believe, that a third way to defend against this attack may = be to=20 realize a trust model i.e. in case messages are not encrypted (and this = may be=20 the case in the majority of sensor networks), each node = monitors/overhears the=20 behavior of its neighbors in order to check whether they sincerely = execute the=20 routing protocol and behave as expected. If for example, node A selects = node B=20 for forwarding packet P1, after transmitting the packet, node A = overhears the=20 wireless medium in order to check whether node B actually forwarded the = packet=20 P1 correctly. The=20 end result is that each node calculates the trustworthiness of its = neighbors and=20 then takes into account this information to avoid choosing malicious = nodes=20 during routing decisions, either for key distribution [1], for data = aggregation=20 or for cluster head election.

  

Also, in the definition of selective = forwarding, the case=20 where a malicious node behaves differently towards different neighbors = could=20 also be covered.  i.e. = maybe by=20 replacing the sentence =93An insider malicious node basically blends = neatly in=20 with the network but then may decide to forward and/or manipulate = certain=20 packets.=94 with =93An insider malicious node basically blends neatly in = with the=20 network, but then may decide to forward and/or manipulate certain = packets from=20 all or part of its neighbors.=94 This behavior is called conflicting = behavior in=20 [6].

 

[1]   =20 Nathan Lewis, Noria Foukia, =93Using Trust for = Key=20 Distribution and Route Selection in Wireless Sensor Networks=94 IEEE = Globecom=20 2007, 26-30 Nov. 2007=20

[2]   =20 A.A.=20 Pirzada and C. McDonald, =93Trust Establishment In Pure Ad-hoc = Networks=94, Wireless=20 Personal Communications Vol. 37, 2006, pp: = 139=96163

[3]   =20 Sapon Tanachaiwiwat, Pinalkumar Dave, Rohan = Bhindwale,=20 Ahmed Helmy =93Location-centric Isolation of Misbehavior and Trust = Routing in=20 Energy-constrained Sensor Networks=94 IEEE International Conference on=20 Performance, Computing, and Communications, = 2004

[4]   =20 G.=20 Theodorakopoulos and J. S. Baras, "On Trust Models and Trust Evaluation = Metrics=20 for Ad-Hoc Networks," IEEE Journal on Selected Areas in Communications = (JSAC),=20 Feb. 2006.

[5]   =20 S.=20 Ganeriwal and M. B. Srivastava. Reputation-Based Framework for High = Integrity=20 Sensor Networks. In 2nd ACM Workshop on Security of Ad = Hoc and=20 Sensor Networks., pages 66=9677, Washington, DC, USA,=20 2004

[6] Yan (Lindsay) Sun, Zhu Han, K. J. Ray Liu, = =93Defense=20 of Trust Management Vulnerabilities in Distributed Networks=94, IEEE=20 Communications Magazine, Vol. 25, No.2, February 2008, pp.=20 112-119.

 

Looking=20 forward to hearing from you,

Theodore

 

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

Dr.=20 Theodore Zahariadis

Ass.=20 Professor, TEI of Chalkida

Email:=20 zahariad@teihal.gr

------=_NextPart_000_074B_01C9C45B.D545A8B0-- From richard.kelsey@ember.com Thu Apr 23 12:40: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 42FD228C6EF for ; Thu, 23 Apr 2009 12:40:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U4NTNewwX15u for ; Thu, 23 Apr 2009 12:40:36 -0700 (PDT) Received: from EMPIRE.hq.ember.com (mail.ember.com [74.10.175.227]) by core3.amsl.com (Postfix) with ESMTP id 3519F28C6ED for ; Thu, 23 Apr 2009 12:40:36 -0700 (PDT) Received: from kelsey-ws.hq.ember.com ([192.168.81.55]) by EMPIRE.hq.ember.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 23 Apr 2009 15:42:46 -0400 Received: from kelsey-ws.hq.ember.com (localhost.localdomain [127.0.0.1]) by kelsey-ws.hq.ember.com (8.13.4/8.13.4) with ESMTP id n3NJfqDg026307 for ; Thu, 23 Apr 2009 15:41:52 -0400 Received: (from kelsey@localhost) by kelsey-ws.hq.ember.com (8.13.4/8.12.8/Submit) id n3NJfqhS026304; Thu, 23 Apr 2009 15:41:52 -0400 Date: Thu, 23 Apr 2009 15:41:52 -0400 Message-Id: <200904231941.n3NJfqhS026304@kelsey-ws.hq.ember.com> To: roll@ietf.org From: Richard Kelsey X-OriginalArrivalTime: 23 Apr 2009 19:42:46.0109 (UTC) FILETIME=[AD0420D0:01C9C44B] Subject: [Roll] FW: New Version Notification for draft-kelsey-roll-lip-00 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Apr 2009 19:40:37 -0000 ROLLers, I have submitted an Internet Draft describing some extensions to MPLS for use in ROLL-style networks, including RIP-like commands for creating and maintaining tree labels. My hope is that this may be of use to the design team or anyone else working on a routing proposal. It is not a complete routing solution. Please send comments to me or to the list. -Richard Kelsey ------- Start of forwarded message ------- From: IETF I-D Submission Tool To: kelsey@ember.com Subject: New Version Notification for draft-kelsey-roll-lip-00 Date: Thu, 23 Apr 2009 12:00:51 -0700 (PDT) A new version of I-D, draft-kelsey-roll-lip-00.txt has been successfuly submitted by Richard Kelsey and posted to the IETF repository. Filename: draft-kelsey-roll-lip Revision: 00 Title: LIP: Label Information Protocol Creation_date: 2009-04-23 WG ID: Independent Submission Number_of_pages: 13 Abstract: LIP is an extension of MPLS for use in Lossy and Low power Networks (LLN). Use of MPLS allows rapid response to local topology changes within an LLN, while still using full IP routing both within the LLN and for packets that cross into other domains. LIP has optional RIP commands for discovering and maintaining label switched tree routes. To support local route repair, labeled packets include a path metric used to detect loops in label-switched paths. Labeled messages may optionally include a source route or route record at the label level in order to allow their use without losing the advantages of label switching. The IETF Secretariat. ------- End of forwarded message ------- From jvasseur@cisco.com Thu Apr 23 21:57:14 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DD7C03A69FA for ; Thu, 23 Apr 2009 21:57:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.281 X-Spam-Level: X-Spam-Status: No, score=-8.281 tagged_above=-999 required=5 tests=[AWL=-1.682, 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 F9ESyaJDzQVC for ; Thu, 23 Apr 2009 21:57:13 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id ECD1E28C691 for ; Thu, 23 Apr 2009 21:57:10 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,239,1238976000"; d="scan'208";a="292036020" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by sj-iport-6.cisco.com with ESMTP; 24 Apr 2009 04:58:28 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n3O4wSOv032563; Fri, 24 Apr 2009 06:58:28 +0200 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n3O4wS0C004186; Fri, 24 Apr 2009 04:58:28 GMT Received: from xfe-ams-332.cisco.com ([144.254.231.73]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 24 Apr 2009 06:58:27 +0200 Received: from ams-jvasseur-8712.cisco.com ([10.55.201.131]) by xfe-ams-332.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 24 Apr 2009 06:58:27 +0200 Message-Id: <110DDF8C-44B2-475D-B784-5B69806408A0@cisco.com> From: JP Vasseur To: Richard Kelsey In-Reply-To: <200904231941.n3NJfqhS026304@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 v930.3) Date: Fri, 24 Apr 2009 06:58:26 +0200 References: <200904231941.n3NJfqhS026304@kelsey-ws.hq.ember.com> X-Mailer: Apple Mail (2.930.3) X-OriginalArrivalTime: 24 Apr 2009 04:58:27.0424 (UTC) FILETIME=[4DFD0E00:01C9C499] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2587; t=1240549108; x=1241413108; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:=20JP=20Vasseur=20 |Subject:=20Re=3A=20[Roll]=20FW=3A=20New=20Version=20Notifi cation=20for=20draft-kelsey-roll-lip-00 |Sender:=20; bh=rJIaT/bo4a9HSyjC7sqBktdmbPDHziCAD79g+NqlgAg=; b=fdOi1ZtWz9agyfhPVsAKMPM+29+d9RAa+wCNc8UWJK/7Cj34XMAYsO9OSQ dH2PlztvL2jbwuXx4EapeTuN1xYWWYlZz6hwJRdSM1F4aJubIZJCaaViCExJ Gmt5afOueO; Authentication-Results: ams-dkim-2; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Cc: roll@ietf.org Subject: Re: [Roll] FW: New Version Notification for draft-kelsey-roll-lip-00 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Apr 2009 04:57:15 -0000 Thanks Richard, the DT will of course look at it. For information, the use of labels instead of addresses to save header size in particular has already been discussed (e.g. use of the Flow Label) and is on the discussion list by the DT. This can also help with regard to TE but requires states maintenance, label assignment/ distribution, ... We'll come bak to you soon. Haven't read your ID yet. WG, for information the DT had two times 2h of discussions + emails exchanges and is progressing well. The hope is to start writing within 2-3 weeks and go back to the list. Thanks. JP. On Apr 23, 2009, at 9:41 PM, Richard Kelsey wrote: > ROLLers, > > I have submitted an Internet Draft describing some > extensions to MPLS for use in ROLL-style networks, including > RIP-like commands for creating and maintaining tree labels. > My hope is that this may be of use to the design team or > anyone else working on a routing proposal. It is not a > complete routing solution. > > Please send comments to me or to the list. > > -Richard Kelsey > > ------- Start of forwarded message ------- > From: IETF I-D Submission Tool > To: kelsey@ember.com > Subject: New Version Notification for draft-kelsey-roll-lip-00 > Date: Thu, 23 Apr 2009 12:00:51 -0700 (PDT) > > > A new version of I-D, draft-kelsey-roll-lip-00.txt has been > successfuly submitted by Richard Kelsey and posted to the IETF > repository. > > Filename: draft-kelsey-roll-lip > Revision: 00 > Title: LIP: Label Information Protocol > Creation_date: 2009-04-23 > WG ID: Independent Submission > Number_of_pages: 13 > > Abstract: > LIP is an extension of MPLS for use in Lossy and Low power Networks > (LLN). Use of MPLS allows rapid response to local topology changes > within an LLN, while still using full IP routing both within the LLN > and for packets that cross into other domains. LIP has optional RIP > commands for discovering and maintaining label switched tree routes. > To support local route repair, labeled packets include a path metric > used to detect loops in label-switched paths. Labeled messages may > optionally include a source route or route record at the label level > in order to allow their use without losing the advantages of label > switching. > > > > The IETF Secretariat. > ------- End of forwarded message ------- > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From jvasseur@cisco.com Thu Apr 23 21:58: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 78C7828C365 for ; Thu, 23 Apr 2009 21:58:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.258 X-Spam-Level: X-Spam-Status: No, score=-8.258 tagged_above=-999 required=5 tests=[AWL=-1.660, 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 zBCmR8Td7Vea for ; Thu, 23 Apr 2009 21:58:16 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 644DB3A6861 for ; Thu, 23 Apr 2009 21:58:16 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,239,1238976000"; d="scan'208,217";a="176212512" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by sj-iport-1.cisco.com with ESMTP; 24 Apr 2009 04:59:33 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n3O4xWtB032716; Fri, 24 Apr 2009 06:59:32 +0200 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n3O4xWpT004303; Fri, 24 Apr 2009 04:59:32 GMT Received: from xfe-ams-331.emea.cisco.com ([144.254.231.72]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 24 Apr 2009 06:59:32 +0200 Received: from ams-jvasseur-8712.cisco.com ([10.55.201.131]) by xfe-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 24 Apr 2009 06:59:31 +0200 Message-Id: <78096489-DE1A-4F06-A9A4-05ADC79EF0CE@cisco.com> From: JP Vasseur To: Theodore Zahariadis In-Reply-To: <731FE93954BB4192BC6AD25893E2A908@sVAIO> Content-Type: multipart/alternative; boundary=Apple-Mail-2-248965978 Mime-Version: 1.0 (Apple Message framework v930.3) X-Priority: 3 Date: Fri, 24 Apr 2009 06:59:30 +0200 References: <731FE93954BB4192BC6AD25893E2A908@sVAIO> X-Mailer: Apple Mail (2.930.3) X-OriginalArrivalTime: 24 Apr 2009 04:59:31.0818 (UTC) FILETIME=[745ECCA0:01C9C499] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=20303; t=1240549172; x=1241413172; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:=20JP=20Vasseur=20 |Subject:=20Re=3A=20[Roll]=20Trust=20Management=20&=20draft -tsao-roll-security-framework-00 |Sender:=20; bh=CzYYDlLXSqps/q+Zm8FVcnT7/fAyMspPOOUKkqFt93M=; b=FN1SVYZZUYlYA0qCh1roFwkUhDlWzkhdefsFVrXcjUzq8+fqNt3idJiq3g lPLeLy68W4NhqD0+93IOq0llX7b02FQKgy29Gsv1VN07DEJTQHBagRqfBCc0 +tsjaMkOsZ; Authentication-Results: ams-dkim-2; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Cc: roll@ietf.org, Sotiris Maniatis , Manuel.CARVALHOSA@ec.europa.eu, Panagiotis Trakadas Subject: Re: [Roll] Trust Management & draft-tsao-roll-security-framework-00 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Apr 2009 04:58:18 -0000 --Apple-Mail-2-248965978 Content-Type: text/plain; charset=WINDOWS-1252; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Thanks for the pointers. I am sure that the authors will come back to =20= you with comments. Thanks. JP. On Apr 23, 2009, at 8:38 PM, Theodore Zahariadis wrote: > Dear all, > > Thank you for allowing me any my team in the ROLL email list and =20 > sharing our thoughts with you. > > First of all let me introduce myself. My name is Theodore Zahariadis =20= > and I am the Technical Manager of the project AWISSENET. > AWISSENET started on 1/1/2008 and is partially funded by EC under =20 > FP7. It includes key industrial partners e.g. Hellenic Aerospace =20 > Industry, Alcatel-Lucent and Thales Communications. Among its main =20 > objectives is to design, simulate and implement a secure routing =20 > scheme for Wireless Sensor Networks. So far, we have designed a =20 > trust management scheme, which includes both direct and indirect =20 > trust, weighting factors=92 values, which are auto-adjusted according =20= > to the attacks, and node=92s energy information. Then, we modified the = =20 > GPSR protocol in order to include both trust and energy-efficient =20 > metrics and simulated the result in J-Sim. The simulations show that =20= > the scheme can provide energy-aware routing paths that bypass =20 > malicious nodes of many kinds. =46rom our experience, up to now, =20 > sensor nodes resources are adequate for implementing at least some =20 > of the trust metrics; thus currently, we are implementing the scheme =20= > in TinyOS v2.1 on IRIS and MicaZ motes. More info may be found at = www.awissenet.eu=20 > . > > In this context, we think that trust for LLN could be in conformance =20= > with the application-specific documents in ROLL. In more details: > > Trust models for sensor networks [1-3] allow for detecting a list of =20= > attacks including black-hole, selective forwarding, integrity/=20 > modification attacks. The nodes may also exchange opinions as =20 > regards the trustworthiness of their neighbors [4-5]. Trust & =20 > reputation information can be accelerated for new-comers, i.e. is =20 > useful in case of mobile nodes and/or newly initiated nodes. > > The draft-tsao-roll-security-framework-00 provides an excellent =20 > description of a security framework for sensor networks. In section =20= > 5.3.3, the selective forwarding attack is described and two =20 > countermeasures are sought. We believe, that a third way to defend =20 > against this attack may be to realize a trust model i.e. in case =20 > messages are not encrypted (and this may be the case in the majority =20= > of sensor networks), each node monitors/overhears the behavior of =20 > its neighbors in order to check whether they sincerely execute the =20 > routing protocol and behave as expected. If for example, node A =20 > selects node B for forwarding packet P1, after transmitting the =20 > packet, node A overhears the wireless medium in order to check =20 > whether node B actually forwarded the packet P1 correctly. The end =20 > result is that each node calculates the trustworthiness of its =20 > neighbors and then takes into account this information to avoid =20 > choosing malicious nodes during routing decisions, either for key =20 > distribution [1], for data aggregation or for cluster head election. > > Also, in the definition of selective forwarding, the case where a =20 > malicious node behaves differently towards different neighbors could =20= > also be covered. i.e. maybe by replacing the sentence =93An insider =20= > malicious node basically blends neatly in with the network but then =20= > may decide to forward and/or manipulate certain packets.=94 with =93An = =20 > insider malicious node basically blends neatly in with the network, =20= > but then may decide to forward and/or manipulate certain packets =20 > from all or part of its neighbors.=94 This behavior is called =20 > conflicting behavior in [6]. > > [1] Nathan Lewis, Noria Foukia, =93Using Trust for Key Distribution = =20 > and Route Selection in Wireless Sensor Networks=94 IEEE Globecom 2007, = =20 > 26-30 Nov. 2007 > [2] A.A. Pirzada and C. McDonald, =93Trust Establishment In Pure = Ad-=20 > hoc Networks=94, Wireless Personal Communications Vol. 37, 2006, pp: =20= > 139=96163 > [3] Sapon Tanachaiwiwat, Pinalkumar Dave, Rohan Bhindwale, Ahmed =20= > Helmy =93Location-centric Isolation of Misbehavior and Trust Routing =20= > in Energy-constrained Sensor Networks=94 IEEE International Conference = =20 > on Performance, Computing, and Communications, 2004 > [4] G. Theodorakopoulos and J. S. Baras, "On Trust Models and =20 > Trust Evaluation Metrics for Ad-Hoc Networks," IEEE Journal on =20 > Selected Areas in Communications (JSAC), Feb. 2006. > [5] S. Ganeriwal and M. B. Srivastava. Reputation-Based Framework =20= > for High Integrity Sensor Networks. In 2nd ACM Workshop on Security =20= > of Ad Hoc and Sensor Networks., pages 66=9677, Washington, DC, USA, = 2004 > [6] Yan (Lindsay) Sun, Zhu Han, K. J. Ray Liu, =93Defense of Trust =20 > Management Vulnerabilities in Distributed Networks=94, IEEE =20 > Communications Magazine, Vol. 25, No.2, February 2008, pp. 112-119. > > Looking forward to hearing from you, > Theodore > > ------------------------------------------------------ > Dr. Theodore Zahariadis > Ass. Professor, TEI of Chalkida > Email: zahariad@teihal.gr > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll --Apple-Mail-2-248965978 Content-Type: text/html; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable Thanks for the pointers. I am = sure that the authors will come back to you with = comments.

Thanks.

JP.

On Apr 23, 2009, at 8:38 PM, Theodore Zahariadis = wrote:

Dear = all,
 
Thank you for allowing me any my team in the ROLL = email list and sharing our thoughts with you.

 

First of all let me introduce myself. My name is Theodore = Zahariadis and I am the Technical Manager of the project = AWISSENET.
AWISSENET started on 1/1/2008 and is partially funded by EC = under FP7. It includes key industrial partners e.g. Hellenic Aerospace = Industry, Alcatel-Lucent and Thales Communications. Among its main = objectives is to design, simulate and implement a secure routing scheme = for Wireless Sensor Networks. So far, we have designed a trust = management scheme, which includes both direct and indirect trust, = weighting factors=92 values, which are auto-adjusted according to the = attacks, and node=92s energy information. Then, we modified the GPSR = protocol in order to include both trust and energy-efficient metrics and = simulated the result in J-Sim. The simulations show that the scheme can = provide energy-aware routing paths that bypass malicious nodes of many = kinds. =46rom our experience, up to now, sensor nodes resources are = adequate for implementing at least some of the trust metrics; thus = currently, we are implementing the scheme in TinyOS v2.1 on IRIS and = MicaZ motes. More info may be found at www.awissenet.eu.
=
 
In this context, we think that trust for LLN could be in = conformance with the application-specific documents in ROLL. In more = details:
 
Trust = models for sensor networks [1-3] allow for detecting a list of attacks = including black-hole, selective forwarding, integrity/modification = attacks. The nodes may also exchange opinions as regards the = trustworthiness of their neighbors [4-5]. Trust & reputation = information can be accelerated for new-comers, i.e. is useful in case of = mobile nodes and/or newly initiated = nodes.
 
The = draft-tsao-roll-security-framework-00 provides an excellent description = of a security framework for sensor networks. In section 5.3.3, the = selective forwarding attack is described and two countermeasures are = sought. We believe, that a third way to defend against this attack may = be to realize a trust model i.e. in case messages are not encrypted (and = this may be the case in the majority of sensor networks), each node = monitors/overhears the behavior of its neighbors in order to check = whether they sincerely execute the routing protocol and behave as = expected. If for example, node A selects node B for forwarding packet = P1, after transmitting the packet, node A overhears the wireless medium = in order to check whether node B actually forwarded the packet P1 = correctly. The end result is that each = node calculates the trustworthiness of its neighbors and then takes into = account this information to avoid choosing malicious nodes during = routing decisions, either for key distribution [1], for data aggregation = or for cluster head election.
  
Also, in the definition of selective = forwarding, the case where a malicious node behaves differently towards = different neighbors could also be covered.  i.e. maybe by = replacing the sentence =93An insider malicious node basically blends = neatly in with the network but then may decide to forward and/or = manipulate certain packets.=94 with =93An insider malicious node = basically blends neatly in with the network, but then may decide to = forward and/or manipulate certain packets from all or part of its = neighbors.=94 This behavior is called conflicting behavior in = [6].
 
[5] S. = Ganeriwal and M. B. Srivastava. Reputation-Based Framework for High = Integrity Sensor Networks. In 2nd ACM = Workshop on Security of Ad Hoc and Sensor Networks., pages 66=9677, = Washington, DC, USA, = 2004

 

Looking forward to = hearing from you,
 

Dr. Theodore = Zahariadis
Ass. = Professor, TEI of Chalkida
_______________________________________________
Roll mailing = list
Roll@ietf.org
https://www.ietf.org/m= ailman/listinfo/roll

= --Apple-Mail-2-248965978-- From mischa.dohler@cttc.es Fri Apr 24 00:09: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 7731D3A6AF0 for ; Fri, 24 Apr 2009 00:09:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.197 X-Spam-Level: X-Spam-Status: No, score=-2.197 tagged_above=-999 required=5 tests=[AWL=0.402, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DubVCnxc-iiJ for ; Fri, 24 Apr 2009 00:09:17 -0700 (PDT) Received: from scorpius.cttc.es (scorpius.cttc.es [84.88.62.197]) by core3.amsl.com (Postfix) with ESMTP id AB6ED3A6A97 for ; Fri, 24 Apr 2009 00:09:16 -0700 (PDT) Received: from leo (postfix@leo.cttc.es [84.88.62.208]) by scorpius.cttc.es (8.13.8/8.13.5) with ESMTP id n3O79KER023168; Fri, 24 Apr 2009 09:09:20 +0200 Received: from [84.88.61.89] (pcmdohler.cttc.es [84.88.61.89]) by leo (Postfix) with ESMTP id 4377E10C31E; Fri, 24 Apr 2009 09:09:20 +0200 (CEST) Message-ID: <49F16550.5060902@cttc.es> Date: Fri, 24 Apr 2009 09:08:00 +0200 From: Mischa Dohler User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Theodore Zahariadis References: <731FE93954BB4192BC6AD25893E2A908@sVAIO> In-Reply-To: <731FE93954BB4192BC6AD25893E2A908@sVAIO> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (leo); Fri, 24 Apr 2009 09:09:20 +0200 (CEST) X-Scanned-By: MIMEDefang 2.57 on 84.88.62.197 Cc: Sotiris Maniatis , roll@ietf.org, Manuel.CARVALHOSA@ec.europa.eu, Panagiotis Trakadas Subject: Re: [Roll] Trust Management & draft-tsao-roll-security-framework-00 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Apr 2009 07:09:18 -0000 Thanks, Theodore, for your comments. To facilitate a practical way forward, I propose the following: 1) You and your team propose additions/deletions/amendments directly in draft-tsao-roll-security-framework-00 to speed up publication of -01. 2) You and your team propose some viable trust management scheme (and ideally a complete security suite) which is implementable into a ROLL protocol, i.e. for the time being HYDRO. You may need to synchronize with the design team and any other partners working on security for ROLL. Thanks and kind regards, Mischa. Theodore Zahariadis wrote: > Dear all, > > > > Thank you for allowing me any my team in the ROLL email list and sharing > our thoughts with you. > > > > First of all let me introduce myself. My name is Theodore Zahariadis and > I am the Technical Manager of the project AWISSENET. > > AWISSENET started on 1/1/2008 and is partially funded by EC under FP7. > It includes key industrial partners e.g. Hellenic Aerospace Industry, > Alcatel-Lucent and Thales Communications. Among its main objectives is > to design, simulate and implement a secure routing scheme for Wireless > Sensor Networks. So far, we have designed a trust management scheme, > which includes both direct and indirect trust, weighting factors’ > values, which are auto-adjusted according to the attacks, and node’s > energy information. Then, we modified the GPSR protocol in order to > include both trust and energy-efficient metrics and simulated the result > in J-Sim. The simulations show that the scheme can provide energy-aware > routing paths that bypass malicious nodes of many kinds. From our > experience, up to now, sensor nodes resources are adequate for > implementing at least some of the trust metrics; thus currently, we are > implementing the scheme in TinyOS v2.1 on IRIS and MicaZ motes. More > info may be found at www.awissenet.eu . > > > > In this context, we think that trust for LLN could be in conformance > with the application-specific documents in ROLL. In more details: > > > > Trust models for sensor networks [1-3] allow for detecting a list of > attacks including black-hole, selective forwarding, > integrity/modification attacks. The nodes may also exchange opinions as > regards the trustworthiness of their neighbors [4-5]. Trust & reputation > information can be accelerated for new-comers, i.e. is useful in case of > mobile nodes and/or newly initiated nodes. > > > > The draft-tsao-roll-security-framework-00 provides an excellent > description of a security framework for sensor networks. In section > 5.3.3, the selective forwarding attack is described and two > countermeasures are sought. We believe, that a third way to defend > against this attack may be to realize a trust model i.e. in case > messages are not encrypted (and this may be the case in the majority of > sensor networks), each node monitors/overhears the behavior of its > neighbors in order to check whether they sincerely execute the routing > protocol and behave as expected. If for example, node A selects node B > for forwarding packet P1, after transmitting the packet, node A > overhears the wireless medium in order to check whether node B actually > forwarded the packet P1 correctly. The end result is that each node > calculates the trustworthiness of its neighbors and then takes into > account this information to avoid choosing malicious nodes during > routing decisions, either for key distribution [1], for data aggregation > or for cluster head election. > > > > Also, in the definition of selective forwarding, the case where a > malicious node behaves differently towards different neighbors could > also be covered. i.e. maybe by replacing the sentence “An insider > malicious node basically blends neatly in with the network but then may > decide to forward and/or manipulate certain packets.” with “An insider > malicious node basically blends neatly in with the network, but then may > decide to forward and/or manipulate certain packets from all or part of > its neighbors.” This behavior is called conflicting behavior in [6]. > > > > [1] Nathan Lewis, Noria Foukia, “Using Trust for Key Distribution and > Route Selection in Wireless Sensor Networks” IEEE Globecom 2007, 26-30 > Nov. 2007 > > [2] A.A. Pirzada and C. McDonald, “Trust Establishment In Pure Ad-hoc > Networks”, Wireless Personal Communications Vol. 37, 2006, pp: 139–163 > > [3] Sapon Tanachaiwiwat, Pinalkumar Dave, Rohan Bhindwale, Ahmed > Helmy “Location-centric Isolation of Misbehavior and Trust Routing in > Energy-constrained Sensor Networks” IEEE International Conference on > Performance, Computing, and Communications, 2004 > > [4] G. Theodorakopoulos and J. S. Baras, "On Trust Models and Trust > Evaluation Metrics for Ad-Hoc Networks," IEEE Journal on Selected Areas > in Communications (JSAC), Feb. 2006. > > [5] S. Ganeriwal and M. B. Srivastava. Reputation-Based Framework for > High Integrity Sensor Networks. In 2nd ACM Workshop on Security of Ad > Hoc and Sensor Networks., pages 66–77, Washington, DC, USA, 2004 > > [6] Yan (Lindsay) Sun, Zhu Han, K. J. Ray Liu, “Defense of Trust > Management Vulnerabilities in Distributed Networks”, IEEE Communications > Magazine, Vol. 25, No.2, February 2008, pp. 112-119. > > > > Looking forward to hearing from you, > > Theodore > > > > ------------------------------------------------------ > > Dr. Theodore Zahariadis > > Ass. Professor, TEI of Chalkida > > Email: zahariad@teihal.gr > From alexandru.petrescu@gmail.com Fri Apr 24 03:20: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 CA4F43A68BB for ; Fri, 24 Apr 2009 03:20:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.163 X-Spam-Level: X-Spam-Status: No, score=-2.163 tagged_above=-999 required=5 tests=[AWL=0.086, 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 m0CihGE4HLd7 for ; Fri, 24 Apr 2009 03:20:09 -0700 (PDT) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.166.172.106]) by core3.amsl.com (Postfix) with ESMTP id BFA9D3A67EE for ; Fri, 24 Apr 2009 03:20:08 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.0) with ESMTP id n3OALQnA026681 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Fri, 24 Apr 2009 12:21:26 +0200 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (8.14.2/8.14.2) with ESMTP id n3OALPWJ006819 for ; Fri, 24 Apr 2009 12:21:26 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.133.173]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id n3OALOZa007169 for ; Fri, 24 Apr 2009 12:21:25 +0200 Message-ID: <49F192A4.10501@gmail.com> Date: Fri, 24 Apr 2009 12:21:24 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: roll@ietf.org References: <49C93116.20102@eecs.berkeley.edu> <86c3ed7b0903241432vf5307a0o506085aea3357e45@mail.gmail.com> <49CAD3AA.7060002@eecs.berkeley.edu> <49CBEF58.5090204@gmail.com> In-Reply-To: <49CBEF58.5090204@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [Roll] Energy metric for link (was: Polling WG for adoption of Metrics Draft) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 24 Apr 2009 10:20:09 -0000 Dear ROLLers, let me revive this thread... I would like to propose a different perspective of an energy metric. This perspective is different than in draft-mjkim-roll-routing-metrics-03, which proposes to quantify the Residual Energy in a node. Here I need Energy for links, not for nodes. This energy metric for a link says how much energy is needed to send (or rcv) an IPv6 MTU packet on that particular link. It assumes that regardless of the type of Node device, the same amount of energy is needed to send 1280bytes on a particular link-layer technology. For example, my LiIon-powered PDA needs 500mW to send 1280bytes on WiFi, and the mains-powered AP needs the same amount of energy to send 1280bytes. This could be encoded as a min-max value: a device needs between min and max Watts to send a packet on this link. Any oppinion on this "link" energy metric kind? Alex Alexandru Petrescu a écrit : > Kris Pister a écrit : [...] >> Below are some candidate metrics with more detail. I've made the >> assumption/recommendation that the node can summarize it's energy >> in terms of packets that it can forward (short packets? long >> packets? Usually there's an affine relationship between packet >> length and energy consumption), and it's power consumption in units >> of packets per second. > > Energy akin to MTU? > > For a particular link, energy representation for a link as MTU. This > computer's interface needs x Watts to send a typical 1280byte IPv6 > packet and y Watts to receive such. > > (Watt and not Joule for this case). > > These x and y figures are usually the same for all interfaces > attached to that link, independent of computer - a server would spend > same amount of energy to send that packet on that link, as a > micro-controller on a PDA. > > Which would give to represent energy in the RA, as MTU is. > > Alex > > > _______________________________________________ Roll mailing list > Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll > From mirossi@gmail.com Fri Apr 24 07:03: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 E7EAD3A701A for ; Fri, 24 Apr 2009 07:03:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5QU9obsTRzYk for ; Fri, 24 Apr 2009 07:03:34 -0700 (PDT) Received: from mail-ew0-f176.google.com (mail-ew0-f176.google.com [209.85.219.176]) by core3.amsl.com (Postfix) with ESMTP id 424463A701C for ; Fri, 24 Apr 2009 07:03:34 -0700 (PDT) Received: by ewy24 with SMTP id 24so1046780ewy.37 for ; Fri, 24 Apr 2009 07:04:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type:content-transfer-encoding; bh=ZsnC81sF66cbxBRVbPaqMWEBxWeeTOmC5XAVSm2dYEg=; b=F9XQd+YPNgicn6Fvj2BgVy8VLfspGGn42TY6q2/gSSLRn4BseoCCUZleJskZpvQ+dz MqDbxb51qaFpfih36nIK9lwBBSFpKteaC8RscFhay8AHl81Qif2TTb0DsLyvR6j4aI2T tQBlZNdaNMguyw6NCRsp8Ape/Ko7uZ7iF9O34= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=imfvnSB9EMsR/9ATHX5JfXwCr6vn4So89uDBVc1e4M1nzjjpunlWvF9e64SdvMVwbq /g4LihDEWqlpQubQtntVOYp9ti2Ag10rS+qefFWaU3TtnAoWwJ26eKf/PZiAOBCnUREg M9IXpq+x482ZQ4iHhmVTUdQ644ZY1Ed8ovDao= MIME-Version: 1.0 Sender: mirossi@gmail.com Received: by 10.210.127.13 with SMTP id z13mr1307189ebc.91.1240581889875; Fri, 24 Apr 2009 07:04:49 -0700 (PDT) In-Reply-To: <49F192A4.10501@gmail.com> References: <49C93116.20102@eecs.berkeley.edu> <86c3ed7b0903241432vf5307a0o506085aea3357e45@mail.gmail.com> <49CAD3AA.7060002@eecs.berkeley.edu> <49CBEF58.5090204@gmail.com> <49F192A4.10501@gmail.com> Date: Fri, 24 Apr 2009 16:04:49 +0200 X-Google-Sender-Auth: a5fcde4a84c62fb8 Message-ID: <34b478810904240704v718e68acw1ab2282daa886b43@mail.gmail.com> From: Michele Rossi To: Alexandru Petrescu Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: roll@ietf.org Subject: Re: [Roll] Energy metric for link (was: Polling WG for adoption of Metrics Draft) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 24 Apr 2009 14:03:36 -0000 I all, I'm new to the ROLL mailing list. My personal opinion is that we need both energy metrics. 1. A metric is needed for sure in oder to characterize the residual energy of the nodes (e.g., related to battery level). I'm thinking of a sensor network, for instance, where you may want to perform routing exploiting energy rich nodes in order to prolong the network lifetime. As a further example, if there are two nodes that performs the same service, you may want to use the one with higher residual energy in order to balance energy consumption. 2. A metric for the energy expenditure in sending an IPv6 packet over the links is however also useful. As Alex suggests this metric is related to the type of PHY interface, e.g., energy consumption for IEEE802.5.4 differs from that of IEEE802.11g. However, I also think that in homogeneous wireless nets (where all or most of the nodes have the same radio interface) it might be also useful to define a metric weighing the expected amount of energy needed to transmit a packet between any two given nodes A and B. This metric depends on the energy consumed in sending the packet as well as on the status of the link, i.e., on the overall packet error probability over the link and hence on the total number of retransmissions to correctly deliver this packet. Here you may consider the well known Expected Transmission Count metric ETX [1] or its variants, see [2]. [1] D. De Couto, D. Aguayo, J. Bicket, and R. Morris, =93A high throughput path metric for multi-hop wireless routing,=94 in Proc. MobiCom, 2003. [2] Koksal, C.E.; Balakrishnan, H., "Quality-Aware Routing Metrics for Time-Varying Wireless Mesh Networks," Selected Areas in Communications, IEEE Journal on, Volume 24, Issue 11, Nov. 2006 Page(s):1984 - 1994. I hope you'll find this useful. Respectfully, Michele. On Fri, Apr 24, 2009 at 12:21 PM, Alexandru Petrescu wrote: > Dear ROLLers, let me revive this thread... > > I would like to propose a different perspective of an energy metric. > This perspective is different than in > draft-mjkim-roll-routing-metrics-03, which proposes to quantify the > Residual Energy in a node. > > Here I need Energy for links, not for nodes. > > This energy metric for a link says how much energy is needed to send (or > rcv) an IPv6 MTU packet on that particular link. =A0It assumes that regar= dless > of the type of Node device, the same amount of energy is needed to send > 1280bytes on a particular link-layer technology. > > For example, my LiIon-powered PDA needs 500mW to send 1280bytes on WiFi, > and the mains-powered AP needs the same amount of energy to send 1280byte= s. > > This could be encoded as a min-max value: a device needs between min and > max Watts to send a packet on this link. > > Any oppinion on this "link" energy metric kind? > > Alex > > Alexandru Petrescu a =E9crit : >> >> Kris Pister a =E9crit : [...] >>> >>> Below are some candidate metrics with more detail. =A0I've made the >>> assumption/recommendation that the node can summarize it's energy >>> in terms of packets that it can forward (short packets? =A0long >>> packets? Usually there's an affine relationship between packet >>> length and energy consumption), and it's power consumption in units >>> of packets per second. >> >> Energy akin to MTU? >> >> For a particular link, energy representation for a link as MTU. =A0This >> =A0computer's interface needs x Watts to send a typical 1280byte IPv6 pa= cket >> and y Watts to receive such. >> >> (Watt and not Joule for this case). >> >> These x and y figures are usually the same for all interfaces >> attached to that link, independent of computer - a server would spend >> same amount of energy to send that packet on that link, as a >> micro-controller on a PDA. >> >> Which would give to represent energy in the RA, as MTU is. >> >> Alex >> >> >> _______________________________________________ Roll mailing list >> Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll >> > > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > --=20 Michele Rossi - Assistant Professor, "SIGNET Group" Dep. of Inf. Engineering, University of Padova, Italy Office: +39 049 827 7915 - Fax: +39 049 827 7699 rossi@dei.unipd.it - http://www.dei.unipd.it/~rossi From richard.kelsey@ember.com Fri Apr 24 08:52:17 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A85023A69F0 for ; Fri, 24 Apr 2009 08:52:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.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 LQc52SnysJld for ; Fri, 24 Apr 2009 08:52:16 -0700 (PDT) Received: from EMPIRE.hq.ember.com (mail.ember.com [74.10.175.227]) by core3.amsl.com (Postfix) with ESMTP id 678E63A6B17 for ; Fri, 24 Apr 2009 08:50:48 -0700 (PDT) Received: from kelsey-ws.hq.ember.com ([192.168.81.55]) by EMPIRE.hq.ember.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 24 Apr 2009 11:53:00 -0400 Received: from kelsey-ws.hq.ember.com (localhost.localdomain [127.0.0.1]) by kelsey-ws.hq.ember.com (8.13.4/8.13.4) with ESMTP id n3OFq6qq004365; Fri, 24 Apr 2009 11:52:06 -0400 Received: (from kelsey@localhost) by kelsey-ws.hq.ember.com (8.13.4/8.12.8/Submit) id n3OFq6X3004362; Fri, 24 Apr 2009 11:52:06 -0400 Date: Fri, 24 Apr 2009 11:52:06 -0400 Message-Id: <200904241552.n3OFq6X3004362@kelsey-ws.hq.ember.com> To: rossi@dei.unipd.it In-reply-to: <34b478810904240704v718e68acw1ab2282daa886b43@mail.gmail.com> (message from Michele Rossi on Fri, 24 Apr 2009 16:04:49 +0200) From: Richard Kelsey References: <49C93116.20102@eecs.berkeley.edu> <86c3ed7b0903241432vf5307a0o506085aea3357e45@mail.gmail.com> <49CAD3AA.7060002@eecs.berkeley.edu> <49CBEF58.5090204@gmail.com> <49F192A4.10501@gmail.com> <34b478810904240704v718e68acw1ab2282daa886b43@mail.gmail.com> X-OriginalArrivalTime: 24 Apr 2009 15:53:00.0395 (UTC) FILETIME=[BE80DBB0:01C9C4F4] Cc: roll@ietf.org Subject: Re: [Roll] Energy metric for link (was: Polling WG for adoption of Metrics Draft) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 24 Apr 2009 15:52:17 -0000 Date: Fri, 24 Apr 2009 16:04:49 +0200 From: Michele Rossi 1. A metric is needed for sure in oder to characterize the residual energy of the nodes (e.g., related to battery level). I'm thinking of a sensor network, for instance, where you may want to perform routing exploiting energy rich nodes in order to prolong the network lifetime. As a further example, if there are two nodes that performs the same service, you may want to use the one with higher residual energy in order to balance energy consumption. It isn't clear to me what the goal is. Prefering devices with higher residual energies makes sense if the goal is to have all devices run out of energy at about the same time. This can make it hard to predict the lifetime of any one device. A new device added to an old network is likely to have a much shorter lifetime than the original devices. In my experience battery-powered devices are usually designed and marketed with some particular minimum lifetime. If device has sufficient energy to relay X messages and has to last Y years, then on average it can relay X/Y messages per year, or X/12Y messages per month, or X/365 messages per day, and so on. Relating the capacity to the battery level is equivalent to averging over the lifetime of the device. Desiging in a minimum lifetime would require rationing energy in smaller allotments. For example, a device that was expected to last two years might be limited to using only 1/24 of its energy each month. Such a device would report the percentage of the current month's energy remaining, not the percentage of total energy. In the limit this makes battery powered device behave like energy scavenging devices, with a bandwidth limit rather than an energy limit. Using a bandwidth metric instead of a residual energy metric could lead to more stable routing. Routes would need to change only in response to the topology changes, and not in response to the passage of time alone. -Richard Kelsey From prvs=358905b19=mukul@uwm.edu Fri Apr 24 09:49: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 37DBF3A6E47 for ; Fri, 24 Apr 2009 09:49:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.405 X-Spam-Level: X-Spam-Status: No, score=-2.405 tagged_above=-999 required=5 tests=[AWL=0.194, 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 9Msu+43os0Ts for ; Fri, 24 Apr 2009 09:48:55 -0700 (PDT) Received: from ip1mta.uwm.edu (ip1mta.uwm.edu [129.89.7.18]) by core3.amsl.com (Postfix) with ESMTP id 34FE73A6403 for ; Fri, 24 Apr 2009 09:48:52 -0700 (PDT) Received: from mta02.pantherlink.uwm.edu ([129.89.7.82]) by ip1mta.uwm.edu with ESMTP; 24 Apr 2009 11:50:10 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by mta02.pantherlink.uwm.edu (Postfix) with ESMTP id 8A3742C10F9A; Fri, 24 Apr 2009 11:50:10 -0500 (CDT) X-Virus-Scanned: amavisd-new at mta02.pantherlink.uwm.edu Received: from mta02.pantherlink.uwm.edu ([127.0.0.1]) by localhost (mta02.pantherlink.uwm.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bjqISSgkKpnz; Fri, 24 Apr 2009 11:50:10 -0500 (CDT) Received: from mail02.pantherlink.uwm.edu (mail02.pantherlink.uwm.edu [129.89.7.86]) by mta02.pantherlink.uwm.edu (Postfix) with ESMTP id 1CC9F2C10FB5; Fri, 24 Apr 2009 11:50:05 -0500 (CDT) Date: Fri, 24 Apr 2009 11:50:05 -0500 (CDT) From: Mukul Goyal To: Richard Kelsey Message-ID: <1068684476.126101240591804987.JavaMail.root@mail02.pantherlink.uwm.edu> In-Reply-To: <200904241552.n3OFq6X3004362@kelsey-ws.hq.ember.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [129.89.7.92] X-Mailer: Zimbra 5.0.15_GA_2851.RHEL4_64 (ZimbraWebClient - FF3.0 (Win)/5.0.15_GA_2851.RHEL4_64) X-Authenticated-User: mukul@uwm.edu Cc: rossi@dei.unipd.it, roll@ietf.org Subject: Re: [Roll] Energy metric for link (was: Polling WG for adoption of Metrics Draft) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 24 Apr 2009 16:50:16 -0000 I think that linking routes too tightly to node battery levels may prove to be counter-productive. I think a routing protocol should allow a node to decline being part of a route based on its local conditions (such as remaining battery levels) without requiring the node to send this information to other nodes. The criteria used by a node to determine if it wants to be part of a route or not should be local, i.e., the node should decide which metric would it consider. The routing protocol should not impose a particular metric on the nodes. Thanks Mukul ----- Original Message ----- From: "Richard Kelsey" To: rossi@dei.unipd.it Cc: roll@ietf.org Sent: Friday, April 24, 2009 10:52:06 AM GMT -06:00 US/Canada Central Subject: Re: [Roll] Energy metric for link (was: Polling WG for adoption of Metrics Draft) Date: Fri, 24 Apr 2009 16:04:49 +0200 From: Michele Rossi 1. A metric is needed for sure in oder to characterize the residual energy of the nodes (e.g., related to battery level). I'm thinking of a sensor network, for instance, where you may want to perform routing exploiting energy rich nodes in order to prolong the network lifetime. As a further example, if there are two nodes that performs the same service, you may want to use the one with higher residual energy in order to balance energy consumption. It isn't clear to me what the goal is. Prefering devices with higher residual energies makes sense if the goal is to have all devices run out of energy at about the same time. This can make it hard to predict the lifetime of any one device. A new device added to an old network is likely to have a much shorter lifetime than the original devices. In my experience battery-powered devices are usually designed and marketed with some particular minimum lifetime. If device has sufficient energy to relay X messages and has to last Y years, then on average it can relay X/Y messages per year, or X/12Y messages per month, or X/365 messages per day, and so on. Relating the capacity to the battery level is equivalent to averging over the lifetime of the device. Desiging in a minimum lifetime would require rationing energy in smaller allotments. For example, a device that was expected to last two years might be limited to using only 1/24 of its energy each month. Such a device would report the percentage of the current month's energy remaining, not the percentage of total energy. In the limit this makes battery powered device behave like energy scavenging devices, with a bandwidth limit rather than an energy limit. Using a bandwidth metric instead of a residual energy metric could lead to more stable routing. Routes would need to change only in response to the topology changes, and not in response to the passage of time alone. -Richard Kelsey _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From root@core3.amsl.com Fri Apr 24 14:15:01 2009 Return-Path: X-Original-To: roll@ietf.org Delivered-To: roll@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 62C363A6C3A; Fri, 24 Apr 2009 14:15:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090424211501.62C363A6C3A@core3.amsl.com> Date: Fri, 24 Apr 2009 14:15:01 -0700 (PDT) Cc: roll@ietf.org Subject: [Roll] I-D ACTION:draft-ietf-roll-protocols-survey-07.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Apr 2009 21:15:01 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Routing Over Low power and Lossy networks Working Group of the IETF. Title : Overview of Existing Routing Protocols for Low Power and Lossy Networks Author(s) : A. Tavakoli, S. Dawson-Haggerty, P. Levis Filename : draft-ietf-roll-protocols-survey-07.txt Pages : 26 Date : 2009-4-24 Low-power wireless devices, such as sensors, actuators and smart objects, present difficult constraints: very limited memory, little processing power, and long sleep periods. As most of these devices are battery-powered, energy efficiency is critically important. Wireless link qualities can vary significantly over time, requiring protocols to make agile decisions yet minimize topology change energy costs. Routing over such low power and lossy networks introduces requirements that existing routing protocols may not fully address. Using existing application requirements documents, this document derives a minimal and not exhaustive set of criteria for routing in low-power and lossy networks. It provides a brief survey of the strengths and weaknesses of existing protocols with respect to these criteria. From this survey it examines whether existing and mature IETF protocols can be used without modification in these networks, or whether further work is necessary. It concludes that no existing IETF protocol meets the requirements of this domain. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-roll-protocols-survey-07.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-roll-protocols-survey-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-4-24140402.I-D@ietf.org> --NextPart-- From mirossi@gmail.com Fri Apr 24 14:29: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 3E7173A6FF4 for ; Fri, 24 Apr 2009 14:29:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o1Cdukp9T2CJ for ; Fri, 24 Apr 2009 14:29:51 -0700 (PDT) Received: from mail-ew0-f176.google.com (mail-ew0-f176.google.com [209.85.219.176]) by core3.amsl.com (Postfix) with ESMTP id 78DF43A6FCF for ; Fri, 24 Apr 2009 14:29:51 -0700 (PDT) Received: by ewy24 with SMTP id 24so1235040ewy.37 for ; Fri, 24 Apr 2009 14:31:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type:content-transfer-encoding; bh=jbUq7mMoLb35gktt+rtwRGr4lGnF5q/pRCBZqXqeNmM=; b=VrDdhHBVtD/P2XhmhESFWR0h8f0cNlHZSi3D6ApUuNAXvud9bv5hRbXlPR/DfXZCI4 Au6fdL9vVlId6vSyDRXmsQrjOZN6wnMqxwJedtZBUO50lhkoNo5/64f4b7+DOxO7Lawu fNIQt5RedklXPP2+XUMN1Z02n0iqdfAt11/6w= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=VJJx9pIssXegVgFHAlJZ9qg8hKJ7vtIG6ix1eNBNGiQgVN2Uyw+bgqVJXlpF256DNn 6SXuyTvxXnpAJsN5/FuURgMAAnCZ9xiQs65IPKAeD0u3QM5OkZZ1b4W6/LVE8U8ncPcy mYyw5syb6xHQo7xBjgdCla8B0lbL4hKZW9dyE= MIME-Version: 1.0 Sender: mirossi@gmail.com Received: by 10.210.119.5 with SMTP id r5mr1319415ebc.99.1240608669307; Fri, 24 Apr 2009 14:31:09 -0700 (PDT) In-Reply-To: <1068684476.126101240591804987.JavaMail.root@mail02.pantherlink.uwm.edu> References: <200904241552.n3OFq6X3004362@kelsey-ws.hq.ember.com> <1068684476.126101240591804987.JavaMail.root@mail02.pantherlink.uwm.edu> Date: Fri, 24 Apr 2009 23:31:09 +0200 X-Google-Sender-Auth: 8ba56e9ecd6366b4 Message-ID: <34b478810904241431h20435ecq81bd2f16d8973fc1@mail.gmail.com> From: Michele Rossi To: Mukul Goyal Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: roll@ietf.org Subject: Re: [Roll] Energy metric for link (was: Polling WG for adoption of Metrics Draft) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 24 Apr 2009 21:29:53 -0000 Hi all, thanks a lot for your comments. I understand the arguments from Richard and I also think that defining a routing protocol that *always* makes routing decisions based on residual energy of the nodes is not the way to go. I also agree with the fact that linking routes to tightly to battery levels may be counter-productive (see email by Mukul). My point is just that residual energies should not be completely neglected. In some cases, we may want to extend the lifetime of some specific nodes due to their location in the network or to their specific function, and residual energies can be used as a metric to implement this. Thus, I agree with Mukul in that a node could locally decide whether to participate or not in the routing based on local metrics, such as its residual battery level (among others). As an example, nodes in a sensor network that are sensing an important event and that are also running out of battery could decide to use their energy to send their measurements to a gathering point rather than relaying messages from other nodes. I think a good protocol should also allow this type of optimization, if nee= ded. Finally, I agree with Richard in that using a link metric would lead to more stable routing. So my view is that the routing protocol should be flexible enough to allow routing using local and/or link metrics. The implementer could then decide which option best suites its specific application. Overall, local metrics may be used to decide whether a node participates in the routing process and link metrics could be used for path selection (considering the nodes that decide to participate). Best, Michele. On Fri, Apr 24, 2009 at 6:50 PM, Mukul Goyal wrote: > I think that linking routes too tightly to node battery levels may prove = to be counter-productive. I think a routing protocol should allow a node to= decline being part of a route based on its local conditions (such as remai= ning battery levels) without requiring the node to send this information to= other nodes. The criteria used by a node to determine if it wants to be pa= rt of a route or not should be local, i.e., the node should decide which me= tric would it consider. The routing protocol should not impose a particular= metric on the nodes. > > Thanks > Mukul > > > ----- Original Message ----- > From: "Richard Kelsey" > To: rossi@dei.unipd.it > Cc: roll@ietf.org > Sent: Friday, April 24, 2009 10:52:06 AM GMT -06:00 US/Canada Central > Subject: Re: [Roll] Energy metric for link (was: Polling WG for adoption = of =A0 =A0 Metrics Draft) > > =A0 Date: Fri, 24 Apr 2009 16:04:49 +0200 > =A0 From: Michele Rossi > > =A0 1. A metric is needed for sure in oder to characterize the residual > =A0 energy of the nodes (e.g., related to battery level). I'm thinking of > =A0 a sensor network, for instance, where you may want to perform routing > =A0 exploiting energy rich nodes in order to prolong the network lifetime= . > =A0 As a further example, if there are two nodes that performs the same > =A0 service, you may want to use the one with higher residual energy in > =A0 order to balance energy consumption. > > It isn't clear to me what the goal is. =A0Prefering devices > with higher residual energies makes sense if the goal is to > have all devices run out of energy at about the same time. > This can make it hard to predict the lifetime of any one > device. =A0A new device added to an old network is likely to > have a much shorter lifetime than the original devices. > > In my experience battery-powered devices are usually > designed and marketed with some particular minimum lifetime. > > If device has sufficient energy to relay X messages and has > to last Y years, then on average it can relay X/Y messages > per year, or X/12Y messages per month, or X/365 messages per > day, and so on. =A0Relating the capacity to the battery level > is equivalent to averging over the lifetime of the device. > > Desiging in a minimum lifetime would require rationing > energy in smaller allotments. =A0For example, a device that > was expected to last two years might be limited to using > only 1/24 of its energy each month. =A0Such a device would > report the percentage of the current month's energy > remaining, not the percentage of total energy. =A0In the limit > this makes battery powered device behave like energy > scavenging devices, with a bandwidth limit rather than an > energy limit. > > Using a bandwidth metric instead of a residual energy metric > could lead to more stable routing. =A0Routes would need to > change only in response to the topology changes, and not in > response to the passage of time alone. > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 -Richard = Kelsey > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > --=20 Michele Rossi - Assistant Professor, "SIGNET Group" Dep. of Inf. Engineering, University of Padova, Italy Office: +39 049 827 7915 - Fax: +39 049 827 7699 rossi@dei.unipd.it - http://www.dei.unipd.it/~rossi From pal@cs.stanford.edu Fri Apr 24 19:07:48 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D343D3A69DB for ; Fri, 24 Apr 2009 19:07:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.594 X-Spam-Level: X-Spam-Status: No, score=-6.594 tagged_above=-999 required=5 tests=[AWL=0.006, 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 XlMiut3BNPhW for ; Fri, 24 Apr 2009 19:07:48 -0700 (PDT) Received: from cs-smtp-1.Stanford.EDU (cs-smtp-1.Stanford.EDU [171.64.64.25]) by core3.amsl.com (Postfix) with ESMTP id 1F49E3A63EC for ; Fri, 24 Apr 2009 19:07:46 -0700 (PDT) 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 1LxXKD-0007Fd-3C for roll@ietf.org; Fri, 24 Apr 2009 19:09:05 -0700 Mime-Version: 1.0 (Apple Message framework v753.1) In-Reply-To: <20090424211501.62C363A6C3A@core3.amsl.com> References: <20090424211501.62C363A6C3A@core3.amsl.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Philip Levis Date: Fri, 24 Apr 2009 19:08:42 -0700 To: ROLL WG X-Mailer: Apple Mail (2.753.1) X-Scan-Signature: f9929892efd47015c544d6ca2fb551e9 Subject: Re: [Roll] I-D ACTION:draft-ietf-roll-protocols-survey-07.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Apr 2009 02:07:48 -0000 On Apr 24, 2009, at 2:15 PM, Internet-Drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Routing Over Low power and Lossy > networks Working Group of the IETF. > > Title : Overview of Existing Routing Protocols for Low Power and > Lossy Networks > Author(s) : A. Tavakoli, S. Dawson-Haggerty, P. Levis > Filename : draft-ietf-roll-protocols-survey-07.txt > Pages : 26 > Date : 2009-4-24 > > Low-power wireless devices, such as sensors, actuators and smart > objects, present difficult constraints: very limited memory, little > processing power, and long sleep periods. As most of these devices > are battery-powered, energy efficiency is critically important. > Wireless link qualities can vary significantly over time, requiring > protocols to make agile decisions yet minimize topology change > energy > costs. Routing over such low power and lossy networks introduces > requirements that existing routing protocols may not fully address. > Using existing application requirements documents, this document > derives a minimal and not exhaustive set of criteria for routing in > low-power and lossy networks. It provides a brief survey of the > strengths and weaknesses of existing protocols with respect to > these > criteria. From this survey it examines whether existing and mature > IETF protocols can be used without modification in these > networks, or > whether further work is necessary. It concludes that no existing > IETF protocol meets the requirements of this domain. There is one minor change in -07; DYMO's analysis for "node cost" is now "?" rather than "fail." Ian is very certain that DYMO could meet this criterion somehow. We therefore think it's safer to make it "?": there is a possibility that the criterion could be met within the specification, but doing so would require further investigation and specification. As there's consensus on the conclusion of the document, it seems more important to have it on the permanent record as an RFC which we can reference than spin on details. Phil From zahariad@teihal.gr Sun Apr 26 11:52: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 536EB3A6D0F for ; Sun, 26 Apr 2009 11:52:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.305 X-Spam-Level: X-Spam-Status: No, score=0.305 tagged_above=-999 required=5 tests=[AWL=-0.031, BAYES_50=0.001, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nDfYynu-s6s1 for ; Sun, 26 Apr 2009 11:52:38 -0700 (PDT) Received: from outbound-mail-127.bluehost.com (outbound-mail-127.bluehost.com [67.222.38.27]) by core3.amsl.com (Postfix) with SMTP id 6277A3A6C90 for ; Sun, 26 Apr 2009 11:52:38 -0700 (PDT) Received: (qmail 5416 invoked by uid 0); 26 Apr 2009 18:53:49 -0000 Received: from unknown (HELO box521.bluehost.com) (74.220.219.121) by outboundproxy4.bluehost.com with SMTP; 26 Apr 2009 18:53:49 -0000 Received: from ppp-94-66-7-81.home.otenet.gr ([94.66.7.81] helo=sVAIO) by box521.bluehost.com with smtp (Exim 4.69) (envelope-from ) id 1Ly9U7-0005Lo-GE; Sun, 26 Apr 2009 12:53:58 -0600 Message-ID: From: "Theodore Zahariadis" To: "culler" Date: Sun, 26 Apr 2009 21:53:44 +0300 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_004D_01C9C6B9.784F1D70" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Windows Mail 6.0.6001.18000 x-mimeole: Produced By Microsoft MimeOLE V6.0.6001.18049 X-Identified-User: {712:box521.bluehost.com:synelixi:synelixis.com} {sentby:bopbeforesmtp 94.66.7.81 authed with synelixis.com} Cc: roll@ietf.org Subject: Re: [Roll] Trust Management & draft-tsao-roll-security-framework-00 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Apr 2009 18:52:39 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_004D_01C9C6B9.784F1D70 Content-Type: multipart/alternative; boundary="----=_NextPart_001_004E_01C9C6B9.784F4480" ------=_NextPart_001_004E_01C9C6B9.784F4480 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I am sending now only the revisions... I hope this time it goes through. Sorry for the inconsistency Theodore ----- Original Message -----=20 From: Theodore Zahariadis=20 To: culler=20 Cc: roll@ietf.org ; Mischa Dohler=20 Sent: Sunday, April 26, 2009 9:32 PM Subject: Re: Roll post from zahariad@teihal.gr requires approval I am trying again with ZIP,=20 as the comments are with revisions. BR, Theodore ----- Original Message -----=20 From: culler=20 To: zahariad@teihal.gr=20 Sent: Friday, April 24, 2009 8:55 PM Subject: Fwd: Roll post from zahariad@teihal.gr requires approval The tools barf on the word document. Perhaps you could paste the = text into a mail message. Begin forwarded message: zahariad@teihal.gr> ------=_NextPart_001_004E_01C9C6B9.784F4480 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
I am sending now only the = revisions...
I hope this time it goes = through.
 
Sorry for the = inconsistency
Theodore
 
----- Original Message -----
From:=20 Theodore=20 Zahariadis
To: culler
Sent: Sunday, April 26, 2009 = 9:32=20 PM
Subject: Re: Roll post from zahariad@teihal.gr requires=20 approval

I am trying again with ZIP, =
as the comments are with = revisions.
 
BR,
Theodore
 
 
----- Original Message -----
From:=20 culler
Sent: Friday, April 24, 2009 = 8:55=20 PM
Subject: Fwd: Roll post from = zahariad@teihal.gr requires=20 approval

The tools barf on the word document.  Perhaps you could = paste the=20 text into a mail message.



Begin forwarded message:

zahariad@teihal.gr>
<= /DIV>

------=_NextPart_001_004E_01C9C6B9.784F4480-- ------=_NextPart_000_004D_01C9C6B9.784F1D70 Content-Type: application/msword; name="draft-tsao-roll-security-framework-00_TBZ1.doc" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="draft-tsao-roll-security-framework-00_TBZ1.doc" 0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAABAAAAeQAAAAAAAAAA EAAAewAAAAEAAAD+////AAAAAHgAAAD///////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////s pcEAcWAIBAAA8BK/AAAAAAAAMAAAAAAABgAAFzUAAA4AYmpianFQcVAAAAAAAAAAAAAAAAAAAAAA AAAJBBYANHgAABM6AQATOgEAqCsAAAAAAAAAAAAAAAAAAG4BAAAAAAAAAAAAAAAAAAD//w8AAAAA AAAAAAD//w8AAAAAAAAAAAD//w8AAAAAAAAAAAAAAAAAAAAAAKQAAAAAAPwEAAAAAAAA/AQAAPwE AAAAAAAA/AQAAAAAAAAqBQAAJgAAAGIFAAAMAAAAbgUAABQAAAAAAAAAAAAAAIIFAAAAAAAAqjAA AAAAAACqMAAAAAAAAKowAAAAAAAAqjAAAGQAAAAOMQAApAAAAIIFAAAAAAAAsz8AALoBAAC+MQAA AAAAAL4xAAAAAAAAvjEAAAAAAAC+MQAAAAAAAL4xAAAAAAAAmTIAAAAAAACZMgAAAAAAAJkyAAAA AAAA+D4AAAIAAAD6PgAAAAAAAPo+AAAAAAAA+j4AAAAAAAD6PgAAAAAAAPo+AAAAAAAA+j4AACQA AABtQQAAaAIAANVDAADMAAAAHj8AABUAAAAAAAAAAAAAAAAAAAAAAAAA/AQAAC4AAACZMgAAEgAA AAAAAAAAAAAAAAAAAAAAAACZMgAAAAAAAJkyAAAAAAAAqzIAAAwAAAC3MgAACAAAAB4/AAAAAAAA AAAAAAAAAAD8BAAAAAAAAPwEAAAAAAAAvjEAAAAAAAAAAAAAAAAAAL4xAADbAAAAMz8AAEQAAADF OwAAAAAAAMU7AAAAAAAAxTsAAAAAAAC/MgAAhAEAAPwEAAAAAAAAvjEAAAAAAAD8BAAAAAAAAL4x AAAAAAAA+D4AAAAAAAAAAAAAAAAAAMU7AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAmTIAAAAAAAD4PgAAAAAAAAAAAAAAAAAAxTsAAAAAAADFOwAA HgAAAEA+AAAYAAAA/AQAAAAAAAD8BAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAjD4AAAAAAAC+MQAAAAAAALIxAAAMAAAAUCAkTaDG yQEAAAAAAAAAAKowAAAAAAAAQzQAADYHAABYPgAACAAAAAAAAAAAAAAA+D4AAAAAAAB3PwAAPAAA ALM/AAAAAAAAYD4AACwAAAChRAAAAAAAAHk7AABMAAAAoUQAABAAAACMPgAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACM PgAAFAAAAKFEAAAAAAAAAAAAAAAAAABQBQAAEgAAAKA+AABYAAAAmTIAAAAAAACZMgAAAAAAAMU7 AAAAAAAAmTIAAAAAAACZMgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAmTIA AAAAAACZMgAAAAAAAJkyAAAAAAAAHj8AAAAAAAAePwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAxTsAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAJkyAAAA AAAAmTIAAAAAAACZMgAAAAAAALM/AAAAAAAAmTIAAAAAAACZMgAAAAAAAJkyAAAAAAAAmTIAAAAA AAAAAAAAAAAAAIIFAAAAAAAAggUAAAAAAACCBQAA5B0AAGYjAABEDQAAggUAAAAAAACCBQAAAAAA AIIFAAAAAAAAZiMAAAAAAACCBQAAAAAAAIIFAAAAAAAAggUAAAAAAAD8BAAAAAAAAPwEAAAAAAAA /AQAAAAAAAD8BAAAAAAAAPwEAAAAAAAA/AQAAAAAAAD/////AAAAAAIADAEAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGRyYWZ0 LXRzYW8tcm9sbC1zZWN1cml0eS1mcmFtZXdvcmstMDAudHh0DQ1OZXR3b3JraW5nIFdvcmtpbmcg R3JvdXAgVC4gVHNhbywgRWQuDUludGVybmV0LURyYWZ0IFIuIEFsZXhhbmRlciwgRWQuDUludGVu ZGVkIHN0YXR1czogSW5mb3JtYXRpb25hbCBFa2EgU3lzdGVtcw1FeHBpcmVzOiBBdWd1c3QgMjAs IDIwMDkgTS4gRG9obGVyLCBFZC4NQ1RUQw1WLiBEYXphLCBFZC4NQS4gTG96YW5vLCBFZC4NVW5p dmVyc2l0YXQgUG9tcGV1IEZhYnJhDUZlYnJ1YXJ5IDE2LCAyMDA5DQ1BIFNlY3VyaXR5IEZyYW1l d29yayBmb3IgUm91dGluZyBvdmVyIExvdyBQb3dlciBhbmQgTG9zc3kgTmV0d29ya3MNZHJhZnQt dHNhby1yb2xsLXNlY3VyaXR5LWZyYW1ld29yay0wMA1UZXh0IHN1cHByZXNzZWQgDQ1GaWd1cmUg MSBzaG93cyB0aGF0IG5vZGVzIHBhcnRpY2lwYXRpbmcgaW4gdGhlIHJvdXRpbmcgcHJvY2Vzcw10 cmFuc21pdCBtZXNzYWdlcyB0byBkZXRlcm1pbmUgdGhlaXIgbmVpZ2hib3JzIChuZWlnaGJvciBk aXNjb3ZlcnkpLg1Vc2luZyB0aGUgbmVpZ2hib3JpbmcgcmVsYXRpb25zaGlwcywgcm91dGluZyBw cm90b2NvbHMgbWF5IGV4Y2hhbmdlDW5ldHdvcmsgdG9wb2xvZ3kgKGluY2x1ZGluZyBsaW5rLXNw ZWNpZmljIGluZm9ybWF0aW9uKSB0byBnZW5lcmF0ZQ1yb3V0ZXMgb3IgbWF5IGV4Y2hhbmdlIHJv dXRlcyBkaXJlY3RseSBhcyBwYXJ0IG9mIGEgcm91dGluZyBleGNoYW5nZTsNbm9kZXMgd2hpY2gg ZG8gbm90IGRpcmVjdGx5IHBhcnRpY2lwYXRlIGluIHRoZSBwcm9jZXNzIHdpdGggYSBnaXZlbg1u b2RlIHdpbGwgZ2V0IHRoZSByb3V0ZS90b3BvbG9neSBpbmZvcm1hdGlvbiByZWxheWVkIGZyb20g b3RoZXJzLiBJdA1pcyBsaWtlbHkgdGhhdCBhIG5vZGUgd2lsbCBzdG9yZSBzb21lIG9yIGFsbCBv ZiB0aGUgcm91dGVzIGFuZA10b3BvbG9neSBpbmZvcm1hdGlvbiBhY2NvcmRpbmcgdG8gdHJhZGVv ZmZzIG9mIG5vZGUgcmVzb3VyY2VzIGFuZA1sYXRlbmN5IGFzc29jaWF0ZWQgd2l0aCB0aGUgcGFy dGljdWxhciByb3V0aW5nIHByb3RvY29sLiBUaGUgbm9kZXMNdXNlIHRoZSBkZXJpdmVkIHJvdXRl cyBmb3IgbWFraW5nIGZvcndhcmRpbmcgZGVjaXNpb25zBS4NLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uDTogOg06IF9fX19fX19fX19fX19fX19fIDoN fE5vZGVfaXw8LS0tLS0tLT4oTmVpZ2hib3IgRGlzY292ZXJ5KS0tLT5OZWlnaGJvciBUb3BvbG9n eSA6DTogLS0tLS0tLS0tLS0tLS0tLS0gOg06IHwgOg18Tm9kZV9qfDwtLS0tLS0tPihSb3V0ZS9U b3BvbG9neSArLS0tLS0tLS0rIDoNOiBFeGNoYW5nZSApIHwgOg06IHwgViBfX19fX18gOg06ICst LS0tPihSb3V0ZSBHZW5lcmF0aW9uKS0tLT5Sb3V0ZXMgOg06IC0tLS0tLSA6DTogfCA6DTogUm91 dGluZyBvbiBhIE5vZGUgTm9kZV9rIHwgOg0uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4NfA18Rm9yd2FyZGluZyB8DU9uIE5vZGVfayB8PC0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSsNTm90YXRpb246DShQcm9jKSBBIHBy b2Nlc3MgUHJvYw1fX19fX19fXw1EYXRhQmFzZSBBIGRhdGEgc3RvcmFnZSBEYXRhQmFzZQ0tLS0t LS0tLQ18Tm9kZV9ufCBBbiBleHRlcm5hbCBlbnRpdHkgTm9kZV9uDS0tLS0tLS0+IERhdGEgZmxv dw1GaWd1cmUgMTogRGF0YSBGbG93IERpYWdyYW0gb2YgYSBHZW5lcmljIFJvdXRpbmcgUHJvY2Vz cw1JdCBpcyBzZWVuIGZyb20gRmlndXJlIDEgdGhhdA1vIEFzc2V0cyBpbmNsdWRlDSogcm91dGlu ZyBhbmQvb3IgdG9wb2xvZ3kgaW5mb3JtYXRpb247DSogY29tbXVuaWNhdGlvbiBjaGFubmVsIHJl c291cmNlcyAoYmFuZHdpZHRoKTsNKiBub2RlIHJlc291cmNlcyAoY29tcHV0aW5nIGNhcGFjaXR5 LCBtZW1vcnksIGFuZCByZW1haW5pbmcNZW5lcmd5KTsNKiBub2RlIGlkZW50aWZpZXJzIChpbmNs dWRpbmcgbm9kZSBpZGVudGl0eSBhbmQgYXNjcmliZWQNYXR0cmlidXRlcyBzdWNoIGFzIHJlbGF0 aXZlIG9yIGFic29sdXRlIG5vZGUgbG9jYXRpb24pLg1vIFBvaW50cyBvZiBhY2Nlc3MgaW5jbHVk ZQ0qIG5laWdoYm9yIGRpc2NvdmVyeTsNKiByb3V0ZS90b3BvbG9neSBleGNoYW5nZTsNKiBub2Rl IHBoeXNpY2FsIGludGVyZmFjZXMgKGluY2x1ZGluZyBhY2Nlc3MgdG8gZGF0YSBzdG9yYWdlKS4N T3B0aW9uYWxseSwgaW4gY2FzZSB0cnVzdCBhbmQgZW5lcmd5IGVmZmljaWVuY3kgbW9kZWxzIGFy ZSBhcHBsaWVkIHRoZQ1ub2RlcyBtYXkgZXhjaGFuZ2U6DSogbmVpZ2hib3VyaW5nIG5vZGVzIGVu ZXJneSANKiBuZWlnaGJvdXJpbmcgdHJ1c3QvcmVwdXRhdGlvbiANQSBmb2N1cyBvbiB0aGUgYWJv dmUgbGlzdCBvZiBhc3NldHMgYW5kIHBvaW50cyBvZiBhY2Nlc3MgZW5hYmxlcyBhDW1vcmUgZGly ZWN0ZWQgYXNzZXNzbWVudCBvZiByb3V0aW5nIHNlY3VyaXR5Lg0zLjIuIFRoZSBDSUEgU2VjdXJp dHkgUmVmZXJlbmNlIE1vZGVsDUF0IHRoZSBjb25jZXB0dWFsIGxldmVsLCBzZWN1cml0eSB3aXRo aW4gYW4gaW5mb3JtYXRpb24gc3lzdGVtIGluDWdlbmVyYWwgYW5kIGFwcGxpZWQgdG8gUk9MTCBp biBwYXJ0aWN1bGFyIGlzIGNvbmNlcm5lZCB3aXRoIHRoZQ1wcmltYXJ5IGlzc3VlcyBvZiBjb25m aWRlbnRpYWxpdHksIGludGVncml0eSwgYW5kIGF2YWlsYWJpbGl0eS4gSW4NdGhlIGNvbnRleHQg b2YgUk9MTDoNVGV4dCBzdXBwcmVzc2VkIA0NNS4zLiBBdmFpbGFiaWxpdHkgQXR0YWNrIENvdW50 ZXJtZWFzdXJlcw1BcyBhbGx1ZGVkIHRvIGJlZm9yZSwgYXZhaWxhYmlsaXR5IHJlcXVpcmVzIHRo YXQgcm91dGluZyBpbmZvcm1hdGlvbg1leGNoYW5nZXMgYW5kIGZvcndhcmRpbmcgbWVjaGFuaXNt cyBiZSBhdmFpbGFibGUgd2hlbiBuZWVkZWQgc28gYXMgdG8NZ3VhcmFudGVlIGEgcHJvcGVyIGZ1 bmN0aW9uaW5nIG9mIHRoZSBuZXR3b3JrLiBUaGlzIG1heSwgZS5nLiwNaW5jbHVkZSB0aGUgY29y cmVjdCBvcGVyYXRpb24gb2Ygcm91dGluZyBpbmZvcm1hdGlvbiBhbmQgbmVpZ2hib3INc3RhdGUg YW5kIHJlbWFpbmluZy1lbmVyZ3kgaW5mb3JtYXRpb24gZXhjaGFuZ2VzLCBhbW9uZyBvdGhlcnMu IA1XZSB3aWxsIGhpZ2hsaWdodCB0aGUga2V5DWZlYXR1cmVzIG9mIHRoZSBzZWN1cml0eSB0aHJl YXRzIGFsb25nIHdpdGggdHlwaWNhbCBjb3VudGVybWVhc3VyZXMNdG8gcHJldmVudCBvciBhdCBs ZWFzdCBtaXRpZ2F0ZSB0aGVtLiBXZSB3aWxsIGFsc28gbm90ZSB0aGF0IGFuDWF2YWlsYWJpbGl0 eSBhdHRhY2sgbWF5IGJlIGZhY2lsaXRhdGVkIGJ5IGFuIGlkZW50aXR5IGF0dGFjayBhcyB3ZWxs DWFzIGEgcmVwbGF5IGF0dGFjaywgYXMgd2FzIGFkZHJlc3NlZCBpbiBTZWN0aW9uIDUuMi4zIGFu ZA1TZWN0aW9uIDUuMi40LCByZXNwZWN0aXZlbHkuDVRleHQgc3VwcHJlc3NlZCANDTUuMy4zLiBD b3VudGVyaW5nIFNlbGVjdGl2ZSBGb3J3YXJkaW5nIEF0dGFja3MNU2VsZWN0aXZlIGZvcndhcmRp bmcgYXR0YWNrcyBhcmUgYW5vdGhlciBmb3JtIG9mIERvUyBhdHRhY2sgd2hpY2gNaW1wYWN0cyB0 aGUgcm91dGluZyBwYXRoIGF2YWlsYWJpbGl0eS4NQW4gaW5zaWRlciBtYWxpY2lvdXMgbm9kZSBi YXNpY2FsbHkgYmxlbmRzIG5lYXRseSBpbiB3aXRoIHRoZSBuZXR3b3JrDWJ1dCB0aGVuIG1heSBk ZWNpZGUgdG8gZm9yd2FyZCBhbmQvb3IgbWFuaXB1bGF0ZSBjZXJ0YWluIHBhY2tldHMgZnJvbSAN YW55IG9yIHBhcnQgb2YgaXRzIG5laWdoYm9ycy4gDUlmIHNvbWUgcGFja2V0cyBhcmUgc2VsZWN0 aXZlbHkgZHJvcHBlZCwgdGhlbiB0aGlzIGF0dGFjaGVyIGlzIG9mdGVuIA1yZWZlcnJlZCBhcyCT Z3JheSBob2xllCwgd2hpbGUgaWYgDWFsbCBwYWNrZXRzIGFyZSBkcm9wcGVkLCB0aGVuIHRoaXMg DWF0dGFja2VyIGlzIGFsc28gb2Z0ZW4gcmVmZXJyZWQgdG8gDWFzIGEgImJsYWNrIGhvbGUiLiAN U3VjaCBhIGZvcm0gb2YgYXR0YWNrIGlzIHBhcnRpY3VsYXJseSBkYW5nZXJvdXMNaWYgY291cGxl ZCB3aXRoIHNpbmtob2xlIGF0dGFja3MsIHNpbmNlIGluaGVyZW50bHkgYSBsYXJnZSBhbW91bnQg b2YNdHJhZmZpYyBpcyBhdHRyYWN0ZWQgdG8gdGhlIG1hbGljaW91cyBub2RlIGFuZCB0aGVyZWJ5 IGNhdXNpbmcNc2lnbmlmaWNhbnQgZGFtYWdlLiBBbiBvdXRzaWRlIG1hbGljaW91cyBub2RlIHdv dWxkIHNlbGVjdGl2ZWx5IGphbQ1vdmVyaGVhcmQgZGF0YSBmbG93cywgd2hlcmUgdGhlIHRodXMg Y2F1c2VkIGNvbGxpc2lvbnMgaW5jdXINc2VsZWN0aXZlIGZvcndhcmRpbmcuDU1vcmVvdmVyLCCT Z3JheSBob2xllCBhdHRhY2tzIGFyZSB3b3JzZSB0aGFuIJNibGFjayBob2xllCBhdHRhY2tzIGFz DWl0IGlzIG1vcmUgZGlmZmljdWx0IHRvIGRldGVjdCB0aGVtLg1TZWxlY3RpdmUgRm9yd2FyZGlu ZyBhdHRhY2tzIGNhbiBiZSBjb3VudGVyZWQgYnkgZGVwbG95aW5nIGEgc2VyaWVzDW9mIG11dHVh bGx5IG5vbi1leGNsdXNpdmUgc2VjdXJpdHkgbWVhc3VyZXM6DW8gbXVsdGlwYXRoIHJvdXRpbmcg b2YgdGhlIHNhbWUgbWVzc2FnZSBvdmVyIGRpc2pvaW50IHBhdGhzOw1vIGR5bmFtaWNhbGx5IHNl bGVjdCB0aGUgbmV4dCBob3AgZnJvbSBhIHNldCBvZiBjYW5kaWRhdGVzOw1vIHJlYWxpc2UgYSB0 cnVzdCBtb2RlbCB0byBzZWxlY3QgdGhlIG5leHQgaG9wIGNhbmRpZGF0ZS4NVGhlIGZpcnN0IG1l YXN1cmUgYmFzaWNhbGx5IGd1YXJhbnRlZXMgdGhhdCBpZiBhIG1lc3NhZ2UgZ2V0cyBsb3N0IG9u DWEgcGFydGljdWxhciByb3V0aW5nIHBhdGggZHVlIHRvIGEgbWFsaWNpb3VzIHNlbGVjdGl2ZSBm b3J3YXJkaW5nDWF0dGFjaywgdGhlcmUgd2lsbCBiZSBhbm90aGVyIHJvdXRlIHdoaWNoIHN1Y2Nl c3NmdWxseSBkZWxpdmVycyB0aGUNZGF0YS4gU3VjaCBtZXRob2QgaXMgaW5oZXJlbnRseSBzdWJv cHRpbWFsIGZyb20gYW4gZW5lcmd5DWNvbnN1bXB0aW9uIHBvaW50IG9mIHZpZXcuIFRoZSBzZWNv bmQgbWV0aG9kIGJhc2ljYWxseSBpbnZvbHZlcyBhDWNvbnN0YW50bHkgY2hhbmdpbmcgcm91dGlu ZyB0b3BvbG9neSBpbiB0aGF0IG5leHQtaG9wIHJvdXRlcnMgYXJlDWNob3NlbiBmcm9tIGEgZHlu YW1pYyBzZXQgaW4gdGhlIGhvcGUgdGhhdCB0aGUgbnVtYmVyIG9mIG1hbGljaW91cw1ub2RlcyBp biB0aGlzIHNldCBpcyBuZWdsaWdpYmxlLiBUaGUgdGhpcmQgbWV0aG9kIGJ1aWxkcyBhIHRydXN0 IHRhYmxlDWZvciBuZWlnaGJvcmluZyBub2RlcyBhbmQgbmV4dC1ob3Agcm91dGVycyBhcmUgY2hv c2VuIGZyb20gYSBncm91cCBvZiANbm9kZXMgdGhhdCBmdWxmaWwgYSBzZXQgb2YgY3JpdGVyaWEg KGUuZy4gdGhlIGJlc3QgYXZlcmFnZSBiZXR3ZWVuIHRydXN0IGFuZCByZW1haW5pbmcgZW5lcmd5 KS4gRWFjaCBub2RlIG1vbml0b3JzL292ZXJoZWFycyB0aGUgYmVoYXZpb3Igb2YgaXRzIA1uZWln aGJvcnMgaW4gb3JkZXIgdG8gY2hlY2sgd2hldGhlciB0aGV5IHNpbmNlcmVseSBleGVjdXRlIHRo ZSByb3V0aW5nIA1wcm90b2NvbCBhbmQgYmVoYXZlIGFzIGV4cGVjdGVkLiBUaGUgZW5kIHJlc3Vs dCBpcyB0aGF0IGVhY2ggbm9kZSANY2FsY3VsYXRlcyB0aGUgdHJ1c3R3b3J0aGluZXNzIG9mIGl0 cyBuZWlnaGJvcnMgYW5kIHRoZW4gdGFrZXMgaW50byANYWNjb3VudCB0aGlzICBpbmZvcm1hdGlv biB0byBhdm9pZCBjaG9vc2luZyBtYWxpY2lvdXMgbm9kZXMgZHVyaW5nIHJvdXRpbmcgDWRlY2lz aW9ucywga2V5IGRpc3RyaWJ1dGlvbiwgb3IgY2x1c3RlciBoZWFkIGVsZWN0aW9uLiANIA0NNS4z LjQuIENvdW50ZXJpbmcgU2lua2hvbGUgQXR0YWNrcw1JbiBzaW5raG9sZSBhdHRhY2tzLCB0aGUg bWFsaWNpb3VzIG5vZGUgbWFuYWdlcyB0byBhdHRyYWN0IGEgbG90IG9mDXRyYWZmaWMgbWFpbmx5 IGJ5IGFkdmVydGlzaW5nIHRoZSBhdmFpbGFiaWxpdHkgb2YgaGlnaC1xdWFsaXR5IGxpbmtzDWV2 ZW4gdGhvdWdoIHRoZXJlIGFyZSBub25lLiBJdCBoZW5jZSBjb25zdGl0dXRlcyBhIHNlcmlvdXMg YXR0YWNrIG9uDWF2YWlsYWJpbGl0eS4NVGhlIG1hbGljaW91cyBub2RlIGNyZWF0ZXMgYSBzaW5r aG9sZSBieSBhdHRyYWN0aW5nIGEgbGFyZ2UgYW1vdW50DW9mLCBpZiBub3QgYWxsLCB0cmFmZmlj IGZyb20gc3Vycm91bmRpbmcgbmVpZ2hib3JzIGJ5IGFkdmVydGlzaW5nIGluDWFuZCBvdXR3YXJk cyBsaW5rcyBvZiBzdXBlcmlvciBxdWFsaXR5LiBBZmZlY3RlZCBub2RlcyBoZW5jZSBlYWdlcmx5 DXJvdXRlIHRoZWlyIHRyYWZmaWMgdmlhIHRoZSBtYWxpY2lvdXMgbm9kZSB3aGljaCwgaWYgY291 cGxlZCB3aXRoDW90aGVyIGF0dGFja3Mgc3VjaCBhcyBzZWxlY3RpdmUgZm9yd2FyZGluZywgbWF5 IGxlYWQgdG8gc2VyaW91cw1hdmFpbGFiaWxpdHkgYW5kIHNlY3VyaXR5IGJyZWFjaGVzLiBTdWNo IGFuIGF0dGFjayBjYW4gb25seSBiZQ1leGVjdXRlZCBieSBhbiBpbnNpZGUgbWFsaWNpb3VzIG5v ZGUgYW5kIGlzIGdlbmVyYWxseSB2ZXJ5IGRpZmZpY3VsdA10byBkZXRlY3QuIEFuIG9uZ29pbmcg YXR0YWNrIGhhcyBhIHByb2ZvdW5kIGltcGFjdCBvbiB0aGUgbmV0d29yaw10b3BvbG9neSBhbmQg ZXNzZW50aWFsbHkgYmVjb21lcyBhIHByb2JsZW0gb2YgZmxvdyBjb250cm9sLg1TaW5raG9sZSBh dHRhY2tzIGNhbiBiZSBjb3VudGVyZWQgYnkgZGVwbG95aW5nIGEgc2VyaWVzIG9mIG11dHVhbGx5 DW5vbi1leGNsdXNpdmUgc2VjdXJpdHkgbWVhc3VyZXM6DW8gdXNlIGdlb2dyYXBoaWNhbCBpbnNp Z2h0cyBmb3IgZmxvdyBjb250cm9sOw1vIGlzb2xhdGUgbm9kZXMgd2hpY2ggcmVjZWl2ZSB0cmFm ZmljIGFib3ZlIGEgY2VydGFpbiB0aHJlc2hvbGQ7DW8gZHluYW1pY2FsbHkgcGljayB1cCBuZXh0 IGhvcCBmcm9tIHNldCBvZiBjYW5kaWRhdGVzOw1vIGFsbG93IG9ubHkgdHJ1c3RlZCBkYXRhIHRv IGJlIHJlY2VpdmVkIGFuZCBmb3J3YXJkZWQ7DW8gcmVhbGlzZSBhIHRydXN0IG1vZGVsIHRvIHNl bGVjdCB0aGUgbmV4dCBob3AgY2FuZGlkYXRlLi4NV2hpbHN0IG1vc3Qgb2YgdGhlc2UgY291bnRl cm1lYXN1cmVzIGhhdmUgYmVlbiBkaXNjdXNzZWQgYmVmb3JlLCB0aGUNdXNlIG9mIGdlb2dyYXBo aWNhbCBpbmZvcm1hdGlvbiBkZXNlcnZlcyBmdXJ0aGVyIGF0dGVudGlvbi4NRXNzZW50aWFsbHks IGlmIGdlb2dyYXBoaWMgcG9zaXRpb25zIG9mIG5vZGVzIGFyZSBhdmFpbGFibGUsIHRoZW4gdGhl DW5ldHdvcmsgY2FuIGFzc3VyZSB0aGF0IGRhdGEgaXMgYWN0dWFsbHkgcm91dGVkIHRvd2FyZHMg dGhlIHNpbmsocykNYW5kIG5vdCBlbHNld2hlcmUuIE9uIHRoZSBvdGhlciBoYW5kLCBnZW9ncmFw aGljIHBvc2l0aW9uIGlzIGENc2Vuc2l0aXZlIGluZm9ybWF0aW9uIHRoYXQgbWF5IGhhdmUgc2Vj dXJpdHkgYW5kL29yIHByaXZhY3kNY29uc2VxdWVuY2VzLg01LjMuNS4gQ291bnRlcmluZyBXb3Jt aG9sZSBBdHRhY2tzDUluIHdvcm1ob2xlIGF0dGFja3MgYXQgbGVhc3QgdHdvIG1hbGljaW91cyBu b2RlcyBzaG9ydGN1dCBvciBkaXZlcnQNdGhlIHVzdWFsIHJvdXRpbmcgcGF0aCBieSBtZWFucyBv ZiBhIGxvdy1sYXRlbmN5IG91dC1vZi1iYW5kIGNoYW5uZWwuDVRoaXMgY2hhbmdlcyB0aGUgYXZh aWxhYmlsaXR5IG9mIGNlcnRhaW4gcm91dGluZyBwYXRocyBhbmQgaGVuY2UNY29uc3RpdHV0ZXMg YSBzZXJpb3VzIHNlY3VyaXR5IGJyZWFjaC4NRXNzZW50aWFsbHksIHR3byBtYWxpY2lvdXMgaW5z aWRlciBub2RlcyB1c2UgYW5vdGhlciwgbW9yZSBwb3dlcmZ1bCwNcmFkaW8gdG8gY29tbXVuaWNh dGUgd2l0aCBlYWNoIG90aGVyIGFuZCB0aGVyZWJ5IGRpc3RvcnQgdGhlIHdvdWxkYmUtDWFncmVl ZCByb3V0aW5nIHBhdGguIFRoaXMgZGlzdG9ydGlvbiBjb3VsZCBpbnZvbHZlIHNob3J0Y3V0dGlu Zw1hbmQgaGVuY2UgcGFyYWx5emluZyBhIGxhcmdlIHBhcnQgb2YgdGhlIG5ldHdvcms7IGl0IGNv dWxkIGFsc28NaW52b2x2ZSB0dW5uZWxpbmcgdGhlIGluZm9ybWF0aW9uIHRvIGFub3RoZXIgcmVn aW9uIG9mIHRoZSBuZXR3b3JrDXdoZXJlIHRoZXJlIGFyZSwgZS5nLiwgbW9yZSBtYWxpY2lvdXMg bm9kZXMgYXZhaWxhYmxlIHRvIGFpZCB0aGUNaW50cnVzaW9uIG9yIHdoZXJlIG1lc3NhZ2VzIGFy ZSByZXBsYXllZCwgZXRjLiBJbiBjb25qdW5jdGlvbiB3aXRoDXNlbGVjdGl2ZSBmb3J3YXJkaW5n LCB3b3JtaG9sZSBhdHRhY2tzIGNhbiBjcmVhdGUgcmFjZSBjb25kaXRpb25zDXdoaWNoIGltcGFj dCB0b3BvbG9neSBtYWludGVuYW5jZSwgcm91dGluZyBwcm90b2NvbHMgYXMgd2VsbCBhcyBhbnkN c2VjdXJpdHkgc3VpdHMgYnVpbHQgb24gInRpbWUgb2YgY2hlY2siIGFuZCAidGltZSBvZiB1c2Ui Lg1Xb3JtaG9sZSBhdHRhY2tzIGFyZSB2ZXJ5IGRpZmZpY3VsdCB0byBkZXRlY3QgaW4gZ2VuZXJh bCBidXQgY2FuIGJlDW1pdGlnYXRlZCB1c2luZyBzaW1pbGFyIHN0cmF0ZWdpZXMgYXMgYWxyZWFk eSBvdXRsaW5lZCBhYm92ZSBpbiB0aGUNY29udGV4dCBvZiBzaW5raG9sZSBhdHRhY2tzLg02LiBS T0xMIFNlY3VyaXR5IEZlYXR1cmVzDVRoZSBpc3N1ZXMgZGlzY3Vzc2VkIGluIFNlY3Rpb24gNCwg dG9nZXRoZXIgd2l0aCB0aGUgY291bnRlcm1lYXN1cmVzDWRlc2NyaWJlZCBpbiBTZWN0aW9uIDUs IHByb3ZpZGUgdGhlIGJhc2lzIGZvciB0aGUgcmVxdWlyZW1lbnRzIG9mIHRoZQ1mb2xsb3dpbmcg Uk9MTCBzZWN1cml0eSBmZWF0dXJlczsgaW4gY29uZm9ybWFuY2UsIHRoZSBkZXNpZ24gb2YgYQ1z ZWN1cmVkIFJPTEwgcHJvdG9jb2wgbmVlZHMgdG8gdXNlIHdlbGwta25vd24gbWVjaGFuaXNtcyB0 byBpbXBsZW1lbnQNdGhlIHNlcnZpY2VzLg02LjEuIENvbmZpZGVudGlhbGl0eSBGZWF0dXJlcw1U byBwcm90ZWN0IGNvbmZpZGVudGlhbGl0eSwgYSBzZWN1cmVkIFJPTEwgcHJvdG9jb2wNbyBTSE9V TEQgcHJvdmlkZSBwYXlsb2FkIGVuY3J5cHRpb247DW8gTUFZIHByb3ZpZGUgdHVubmVsaW5nOw1v IE1BWSBwcm92aWRlIGxvYWQgYmFsYW5jaW5nOw1vIFNIT1VMRCBwcm92aWRlIHByaXZhY3ksIGUu Zy4sIHdoZW4gZ2VvZ3JhcGhpYyBpbmZvcm1hdGlvbiBpcyB1c2VkLg02LjIuIEludGVncml0eSBG ZWF0dXJlcw1UbyBwcm90ZWN0IGludGVncml0eSwgYSBzZWN1cmVkIFJPTEwgcHJvdG9jb2wNbyBN VVNUIHZlcmlmeSB0aGUgbGl2ZWxpbmVzcyBvZiBib3RoIHByaW5jaXBhbHMgb2YgYSBjb25uZWN0 aW9uOw1vIE1VU1QgdmVyaWZ5IG1lc3NhZ2UgZnJlc2huZXNzOw1vIE1VU1QgdmVyaWZ5IG1lc3Nh Z2Ugc2VxdWVuY2UgYW5kIGludGVncml0eTsNbyBNQVkgZXZhbHVhdGUgdHJ1c3QgYW5kIHRydXN0 d29ydGhpbmVzcyBvZiBuZWlnaGJvcmluZyBub2Rlcw02LjMuIEF2YWlsYWJpbGl0eSBGZWF0dXJl cw1UbyBwcm90ZWN0IGF2YWlsYWJpbGl0eSwgYSBzZWN1cmVkIFJPTEwgcHJvdG9jb2wNbyBNQVkg cmVzdHJpY3QgbmVpZ2hib3Job29kIGNhcmRpbmFsaXR5Ow1vIE1BWSB1c2UgbXVsdGlwbGUgcGF0 aHM7DW8gTUFZIHVzZSBtdWx0aXBsZSBkZXN0aW5hdGlvbnM7DW8gTUFZIGNob29zZSByYW5kb21s eSBpZiBtdWx0aXBsZSBwYXRocyBhcmUgYXZhaWxhYmxlOw1vIE1BWSBzZXQgcXVvdGFzIHRvIGxp bWl0IHRyYW5zbWl0IG9yIHJlY2VpdmUgdm9sdW1lOw1vIE1BWSB1c2UgZ2VvZ3JhcGhpYyBpbnNp Z2h0cyBmb3IgZmxvdyBjb250cm9sLg02LjQuIEFkZGl0aW9uYWwgQ29uc2lkZXJhdGlvbnMNSWYg YSBMTE4gZW1wbG95cyBtdWx0aWNhc3QgYW5kL29yIGFueWNhc3QsIGl0IE1VU1Qgc2VjdXJlIHRo ZXNlDXByb3RvY29scyB3aXRoIHRoZSBzZXJ2aWNlcyBsaXN0ZWQgaW4gdGhpcyBzZWN0aW9ucy4g RnVydGhlcm1vcmUsDXRoZSBub2RlcyBNVVNUIHByb3ZpZGUgYWRlcXVhdGUgcGh5c2ljYWwgdGFt cGVyIHJlc2lzdGFuY2UgdG8gZW5zdXJlDXRoZSBpbnRlZ3JpdHkgb2Ygc3RvcmVkIHJvdXRpbmcg aW5mb3JtYXRpb24uDVRoZSBmdW5jdGlvbmluZyBvZiB0aGUgc2VjdXJpdHkgc2VydmljZXMgcmVx dWlyZXMga2V5cyBhbmQNY3JlZGVudGlhbHMuIFRoZXJlZm9yZSwgZXZlbiB0aG91Z2ggbm90IGRp cmVjdGx5IGEgUk9MTCBzZWN1cml0eQ1yZXF1aXJlbWVudCwgYSBMTE4gbXVzdCBpbmNsdWRlIGEg cHJvY2VzcyBmb3Iga2V5IGFuZCBjcmVkZW50aWFsDWRpc3RyaWJ1dGlvbjsgYSBMTE4gaXMgZW5j b3VyYWdlZCB0byBoYXZlIHByb2NlZHVyZXMgZm9yIHRoZWlyDXJldm9jYXRpb24gYW5kIHJlcGxh Y2VtZW50Lg03LiBJQU5BIENvbnNpZGVyYXRpb25zDVRoaXMgbWVtbyBpbmNsdWRlcyBubyByZXF1 ZXN0IHRvIElBTkEuDTguIFNlY3VyaXR5IENvbnNpZGVyYXRpb25zDVRoZSBmcmFtZXdvcmsgcHJl c2VudGVkIGluIHRoaXMgZG9jdW1lbnQgcHJvdmlkZXMgc2VjdXJpdHkgYW5hbHlzaXMNYW5kIGRl c2lnbiBndWlkZWxpbmVzIHdpdGggYSBzY29wZSBsaW1pdGVkIHRvIFJPTEwuIFRoZQ1pbnZlc3Rp Z2F0aW9uIGlzIGF0IGEgaGlnaC1sZXZlbCBhbmQgbm90IHNwZWNpZmljIHRvIGEgcGFydGljdWxh cg1wcm90b2NvbC4gU2VjdXJpdHkgc2VydmljZXMsIGJ1dCBub3QgbWVjaGFuaXNtcywgYXJlIGlk ZW50aWZpZWQgYXMNcmVxdWlyZW1lbnRzIGZvciBzZWN1cmluZyBST0xMLg05LiBUcnVzdC9UcnVz dHdvcnRoaW5lc3MgQ29uc2lkZXJhdGlvbnMNVGhlIHNlY3VyaXR5IGZyYW1ld29yayBtYXkgb3B0 aW9uYWxseSBzdXBwb3J0ZWQgYW5kIGV4dGVuZGVkIGJ5IGEgdHJ1c3QgDWZyYW1ld29yaywgV2hp Y2ggbWF5IGJlIGFwcGxpZWQgaW4gdGhlIHNlbGVjdGlvbiBvZiBhIHNlY3VyZSBST0xMLiANVGhl IHRydXN0IGZyYW1ld29yayBtYXkgYmUgYmFzZWQgb24gk2RpcmVjdCB0cnVzdJQsIHdoaWNoIGlz IHRoZSB0cnVzdCANdGhhdCBhIG5vZGUgYnVpbGRzIHByb2dyZXNzaXZlbHkgdXRpbGlzaW5nIGl0 cyBvd24gcm91dGluZyBleHBlcmllbmNlIA1hbmQgbmV0d29yayBvdmVyaGVhcmluZy9zbmlmZmlu ZywgYW5kIG9uIJNpbmRpcmVjdCB0cnVzdJQgKGFsc28gcmVmZXJyZWQgDXRvIGFzIHJlcHV0YXRp b24pLCB3aGljaCBpcyB0aGUgdHJ1c3QgdGhhdCBzZWxlY3RlZCBuZWlnaGJvdXJpbmcgbm9kZXMN c2hhcmVzIHdpdGggdGhlIGludGVyZXN0aW5nIG5vZGUuIA0NMTAgQWNrbm93bGVkZ21lbnRzDQ0F SW4gdGhpcyBzY2hlbWUgd2UgY2FuIGFkZCB0d28gZnVuY3Rpb25hbGl0aWVzOg1Ob2RlcyBtYXkg YnVpbGQgbm90IG9ubHkgYSBuZWlnaGJvciBUb3BvbG9neSwgYnV0IGFsc28gYSB0cnVzdCB0YWJs ZQ1Ob2RlcyBtYXkgbm90IG9ubHkgZXhjaGFuZ2Ugcm91dGUvdG9wb2xvZ3kgaW5mb3JtYXRpb24s IGJ1dCBhbHNvIHRydXN0L3JlcHV0YXRpb24gaW5mb3JtYXRpb24NDU1vcmVvdmVyLCBpbiBhbiBl bmVyZ3kgZWZmaWNpZW50IGFwcHJvYWNoIHdlIG1heSBhZGQgdGhlIGVuZXJneSBhcyBwYXJ0IG9m IHRoZSBleGNoYW5nZWQgbWVzc2FnZXM6IHRodXMgdGhlIHJvdXRpbmcgbWF5IGFjaGlldmUgbG9u Z2VyIG5ldHdvcmsgbGlmZXRpbWUuDQ0NAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABgAAewkAAIoJAACLCQAAjAkAAI0JAABhDAAA YgwAADYOAABVDgAAdg4AAOvVw7GSc1dzQicAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA1FWhnP/gA FmgUFGMAQ0oUAE9KAwBRSgMAXkoDAGFKFABtSBAEc0gQBInKBwEBAG/V1AaDKgEoFWhnP/gAFmgU FGMAQ0oUAE9KAwBRSgMAXkoDAGFKFABtSBAEc0gQBAA3A2oAAAAAFWgRF2QAFmjAe3cAMEoQAFUI AYnKBwEBAPXE1KaDKgEDagAAAABVCAFtSAkEc0gJBD0VaBEXZAAWaBQUYwBDShQAT0oDAFFKAwBe SgMAYUoUAG1ICQhzSAkIicoHAQEA9cTUpoMqAW1ICQRzSAkEPRVoERdkABZoZz/4AENKFABPSgMA UUoDAF5KAwBhShQAbUgJCHNICQiJygcBAQD1xNSmgyoBbUgJBHNICQQiFmgUFGMAQ0oUAE9KAwBR SgMAXkoDAGFKFABtSAkEc0gJBAAiFmhnP/gAQ0oUAE9KAwBRSgMAXkoDAGFKFABtSAkEc0gJBAAr DCoHFWhnP/gAFmhnP/gAQ0oUAE9KAwBRSgMAXkoDAGFKFABtSAkEc0gJBCgVaBEXZAAWaBQUYwBD ShQAT0oDAFFKAwBeSgMAYUoUAG1ICQRzSAkECgAGAAAqCAAAKwgAAFEIAAByCAAAnQgAAMUIAADK CAAA1wgAAOYIAAD/CAAAEQkAABIJAABVCQAAewkAAIwJAACNCQAAzAkAABEKAABVCgAAmAoAAN4K AAAiCwAAZwsAAKYLAADoCwAAKwwAAPEAAAAAAAAAAAAAAADmAAAAAAAAAAAAAAAA5gAAAAAAAAAA AAAAAOYAAAAAAAAAAAAAAADmAAAAAAAAAAAAAAAA5gAAAAAAAAAAAAAAAOYAAAAAAAAAAAAAAADm AAAAAAAAAAAAAAAA5gAAAAAAAAAAAAAAAOYAAAAAAAAAAAAAAADmAAAAAAAAAAAAAAAA5gAAAAAA AAAAAAAAAOYAAAAAAAAAAAAAAADmAAAAAAAAAAAAAAAA5gAAAAAAAAAAAAAAAOYAAAAAAAAAAAAA AADmAAAAAAAAAAAAAAAA5gAAAAAAAAAAAAAAAOYAAAAAAAAAAAAAAADmAAAAAAAAAAAAAAAA5gAA AAAAAAAAAAAAAOYAAAAAAAAAAAAAAADmAAAAAAAAAAAAAAAA5gAAAAAAAAAAAAAAAOYAAAAAAAAA AAAAAADmAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAALAAATpHgANyQAOCQASCQAZ2QUFGMADgAA AyQBE6R4ADckADgkAEgkAGEkAWdkFBRjAAAaAAYAAKgzAAAWNQAA/f0AAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAEBAABAQIrDAAAZAwAAJgMAACcDAAAsgwAAO8MAAAFDQAACw0A ADkNAABKDQAAWQ0AAIANAACLDQAAkQ0AALANAADkDQAA5g0AAPQNAAAsDgAANg4AAEwOAABVDgAA dg4AAH8OAACiDgAAtQ4AAO4OAAAMDwAAHQ8AAPQAAAAAAAAAAAAAAAD0AAAAAAAAAAAAAAAA9AAA AAAAAAAAAAAAAPQAAAAAAAAAAAAAAAD0AAAAAAAAAAAAAAAA9AAAAAAAAAAAAAAAAPQAAAAAAAAA AAAAAAD0AAAAAAAAAAAAAAAA9AAAAAAAAAAAAAAAAPQAAAAAAAAAAAAAAAD0AAAAAAAAAAAAAAAA 9AAAAAAAAAAAAAAAAPQAAAAAAAAAAAAAAAD0AAAAAAAAAAAAAAAA9AAAAAAAAAAAAAAAAPQAAAAA AAAAAAAAAAD0AAAAAAAAAAAAAAAA9AAAAAAAAAAAAAAAAPQAAAAAAAAAAAAAAAD0AAAAAAAAAAAA AAAA9AAAAAAAAAAAAAAAAPQAAAAAAAAAAAAAAAD0AAAAAAAAAAAAAAAA9AAAAAAAAAAAAAAAAPQA AAAAAAAAAAAAAAD0AAAAAAAAAAAAAAAA9AAAAAAAAAAAAAAAAPQAAAAAAAAAAAAAAAAAAAAAAAAA AAsAABOkeAA3JAA4JABIJABnZBQUYwAAHHYOAACiDgAAdBAAAHUQAAC0EAAAvhAAAL8QAADOEAAA 5BAAAPcQAAD7EAAA/BAAAEwRAABNEQAAvhIAAOTFn8V5U3kteS1TLXnFAAAAAAAAAAAAAAAAAAAA AEoBCAEESAEABWjexNSmFWgRF2QAFmheUz0AQ0oUAE9KAwBRSgMAXkoDAGFKFABtSAkIc0gJCInK BwEBAPXE1KaDKgFtSAkEc0gJBABKAQgBBEgBAAVo38TUphVoERdkABZoXlM9AENKFABPSgMAUUoD AF5KAwBhShQAbUgJCHNICQiJygcBAQD1xNSmgyoBbUgJBHNICQQASgEIAQRIAQAFaN3E1KYVaBEX ZAAWaF5TPQBDShQAT0oDAFFKAwBeSgMAYUoUAG1ICQhzSAkIicoHAQEA9cTUpoMqAW1ICQRzSAkE AEoBCAEESAEABWjcxNSmFWgRF2QAFmgUFGMAQ0oUAE9KAwBRSgMAXkoDAGFKFABtSAkIc0gJCInK BwEBAPXE1KaDKgFtSAkEc0gJBAA9FWgRF2QAFmgUFGMAQ0oUAE9KAwBRSgMAXkoDAGFKFABtSAkI c0gJCInKBwEBAPXE1KaDKgFtSAkEc0gJBDUVaGc/+AAWaBQUYwBDShQAT0oDAFFKAwBeSgMAYUoU AG1IFgRzSBYEicoHAQEAb9XUBoMqAQAOHQ8AAEQPAABzDwAArw8AALgPAADxDwAAKRAAAEQQAABa EAAAdRAAALQQAAD7EAAA9AAAAAAAAAAAAAAAAPQAAAAAAAAAAAAAAAD0AAAAAAAAAAAAAAAA9AAA AAAAAAAAAAAAAPQAAAAAAAAAAAAAAAD0AAAAAAAAAAAAAAAA9AAAAAAAAAAAAAAAAPQAAAAAAAAA AAAAAAD0AAAAAAAAAAAAAAAA6QAAAAAAAAAAAAAAAJsAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAE4AABOkeAA3 JAA4JABDJAFFxoAAAAEA3cTUpgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEgkAGdkFBRjAAsAABOkeAA3JAA4JABIJABnZF5TPQAL AAATpHgANyQAOCQASCQAZ2QUFGMAAAv7EAAADxEAACwRAABNEQAAkBEAAL4RAADkEQAAJhIAAGYS AACpEgAAvhIAAM8SAACxAAAAAAAAAAAAAAAAsQAAAAAAAAAAAAAAALEAAAAAAAAAAAAAAACmAAAA AAAAAAAAAAAApgAAAAAAAAAAAAAAAKYAAAAAAAAAAAAAAACmAAAAAAAAAAAAAAAApgAAAAAAAAAA AAAAAKYAAAAAAAAAAAAAAACmAAAAAAAAAAAAAAAAmwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACwAAE6R4ADck ADgkAEgkAGdkZz/4AAsAABOkeAA3JAA4JABIJABnZBQUYwBOAAATpHgANyQAOCQAQyQBRcaAAAAB AN7E1KYAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAABIJABnZF5TPQAAC74SAADNEgAAzxIAANASAAALFAAAIBQAAEUUAABGFAAAgBUA AI8VAACSFQAAsBYAALcWAADp17GSepJ6kmRSkiwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABKAQgB BEgBAAVo1cTUphVoERdkABZowHt3AENKFABPSgMAUUoDAF5KAwBhShQAbUgJCHNICQiJygcBAQD1 xNSmgyoBbUgJBHNICQQAIhZoJRRfAENKFABPSgMAUUoDAF5KAwBhShQAbUgJBHNICQQAKwwqBxVo Zz/4ABZoJRRfAENKFABPSgMAUUoDAF5KAwBhShQAbUgJBHNICQQvAQiBBEgBAAVo+cTUphZoERdk AENKFABPSgMAUUoDAF5KAwBhShQAbUgJBHNICQQ9FWgRF2QAFmgUFGMAQ0oUAE9KAwBRSgMAXkoD AGFKFABtSAkIc0gJCInKBwEBAPXE1KaDKgFtSAkEc0gJBEoBCAEESAEABWjfxNSmFWgRF2QAFmhe Uz0AQ0oUAE9KAwBRSgMAXkoDAGFKFABtSAkIc0gJCInKBwEBAPXE1KaDKgFtSAkEc0gJBAAiFmhn P/gAQ0oUAE9KAwBRSgMAXkoDAGFKFABtSAkEc0gJBAArDCoHFWhnP/gAFmhnP/gAQ0oUAE9KAwBR SgMAXkoDAGFKFABtSAkEc0gJBAAMzxIAANASAAD5EgAAPhMAAIQTAADDEwAABRQAAEYUAABgFAAA pBQAAOQUAACxAAAAAAAAAAAAAAAApgAAAAAAAAAAAAAAAKYAAAAAAAAAAAAAAACmAAAAAAAAAAAA AAAApgAAAAAAAAAAAAAAAKYAAAAAAAAAAAAAAACmAAAAAAAAAAAAAAAAWAAAAAAAAAAAAAAAAKYA AAAAAAAAAAAAAACmAAAAAAAAAAAAAAAAAABOAAATpHgANyQAOCQAQyQBRcaAAAABAPnE1KYAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AABIJABnZBQUYwALAAATpHgANyQAOCQASCQAZ2QUFGMATgAAE6R4ADckADgkAEMkAUXGgAAAAQDf xNSmAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAASCQAZ2QUFGMAAArkFAAAKRUAAGMVAACAFQAAkRUAAJIVAADBFQAAAxYAACoWAABw FgAAtxYAANYWAAAcFwAAPxcAAGMXAAD0AAAAAAAAAAAAAAAA9AAAAAAAAAAAAAAAAPQAAAAAAAAA AAAAAADpAAAAAAAAAAAAAAAA9AAAAAAAAAAAAAAAAPQAAAAAAAAAAAAAAAD0AAAAAAAAAAAAAAAA 9AAAAAAAAAAAAAAAAPQAAAAAAAAAAAAAAAD0AAAAAAAAAAAAAAAA3AAAAAAAAAAAAAAAANwAAAAA AAAAAAAAAACHAAAAAAAAAAAAAAAA3AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAVAAAE6R4ADckADgkAEMkAUXGgAAAAQDmxNSmAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAASCQAZ2QZeFQAb8YHAQEA5sTU pmQmAQAMAAATpHgANyQAOCQAQyQBSCQAZ2TAe3cACwAAE6R4ADckADgkAEgkAGdkJRRfAAsAABOk eAA3JAA4JABIJABnZBQUYwAADrcWAAC6FgAA0xYAANUWAADWFgAA2BYAANkWAAAbFwAAHBcAAB4X AAAoFwAAKRcAAC4XAAAzFwAA2rSVtJW0b0lvSSNJIwBKAQgBBEgBAAVo58TUphVoERdkABZoGXhU AENKFABPSgMAUUoDAF5KAwBhShQAbUgJCHNICQiJygcBAQD1xNSmgyoBbUgJBHNICQQASgEIAQRI AQAFaObE1KYVaBEXZAAWaF5TPQBDShQAT0oDAFFKAwBeSgMAYUoUAG1ICQhzSAkIicoHAQEA9cTU poMqAW1ICQRzSAkEAEoBCAEESAEABWjlxNSmFWgRF2QAFmheUz0AQ0oUAE9KAwBRSgMAXkoDAGFK FABtSAkIc0gJCInKBwEBAPXE1KaDKgFtSAkEc0gJBAA9FWgRF2QAFmgUFGMAQ0oUAE9KAwBRSgMA XkoDAGFKFABtSAkIc0gJCInKBwEBAPXE1KaDKgFtSAkEc0gJBEoBCAEESAEABWjVxNSmFWgRF2QA FmjAe3cAQ0oUAE9KAwBRSgMAXkoDAGFKFABtSAkIc0gJCInKBwEBAPXE1KaDKgFtSAkEc0gJBABK AQgBBEgBAAVo5MTUphVoERdkABZoXlM9AENKFABPSgMAUUoDAF5KAwBhShQAbUgJCHNICQiJygcB AQD1xNSmgyoBbUgJBHNICQQNMxcAAD4XAAA/FwAAYhcAAGMXAACFFwAAhhcAAIcXAACaFwAAmxcA AOsXAADsFwAA5RgAANqrjNqM2l2M2ow3jAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAABKAQgBBEgBAAVozMTUphVoERdkABZoKVfhAENKFABPSgMAUUoDAF5KAwBh ShQAbUgJCHNICQiJygcBAQD1xNSmgyoBbUgJBHNICQQAXAAIARVoERdkABZoFBRjABdoXlM9AENK FABPSgMAUUoDAF5KAwBhShQAY0gBAGRoAAAAAGRoAAAAAGRo5sTUpm1ICQhzSAkIicoHAQEA9cTU poMqAW1ICQRzSAkEAD0VaBEXZAAWaBQUYwBDShQAT0oDAFFKAwBeSgMAYUoUAG1ICQhzSAkIicoH AQEA9cTUpoMqAW1ICQRzSAkEXAAIARVoERdkABZoFBRjABdowHt3AENKFABPSgMAUUoDAF5KAwBh ShQAY0gBAGRoAAAAAGRoAAAAAGRo1cTUpm1ICQhzSAkIicoHAQEA9cTUpoMqAW1ICQRzSAkEAEoB CAEESAEABWjmxNSmFWgRF2QAFmheUz0AQ0oUAE9KAwBRSgMAXkoDAGFKFABtSAkIc0gJCInKBwEB APXE1KaDKgFtSAkEc0gJBAxjFwAAhxcAAJsXAADLFwAAEBgAAE8YAACTGAAA0BgAAOYYAACxAAAA AAAAAAAAAAAApAAAAAAAAAAAAAAAAFYAAAAAAAAAAAAAAABLAAAAAAAAAAAAAAAASwAAAAAAAAAA AAAAAEsAAAAAAAAAAAAAAABLAAAAAAAAAAAAAAAASwAAAAAAAAAAAAAAAAAAAAAAAAAAAAALAAAT pHgANyQAOCQASCQAZ2QUFGMATgAAE6R4ADckADgkAEMkAUXGgAAAAQDmxNSmAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAASCQAZ2Re Uz0AAAwAABOkeAA3JAA4JABDJAFIJABnZF5TPQBOAAATpHgANyQAOCQAQyQBRcaAAAABAObE1KYA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAABIJABnZMB7dwAACOUYAADmGAAAKxkAAE8ZAABQGQAAOBoAADwaAADatI5vUCoAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEoBCAEESAEABWjMxNSm FWgRF2QAFmgpV+EAQ0oUAE9KAwBRSgMAXkoDAGFKFABtSAkIc0gJCInKBwEBAPXE1KaDKgFtSAkE c0gJBAA9FWgRF2QAFmgUFGMAQ0oUAE9KAwBRSgMAXkoDAGFKFABtSAkIc0gJCInKBwEBAPXE1KaD KgFtSAkEc0gJBD0VaBEXZAAWaBl4VABDShQAT0oDAFFKAwBeSgMAYUoUAG1ICQhzSAkIicoHAQEA 9cTUpoMqAW1ICQRzSAkESgEIAQRIAQAFaOjE1KYVaBEXZAAWaBl4VABDShQAT0oDAFFKAwBeSgMA YUoUAG1ICQhzSAkIicoHAQEA9cTUpoMqAW1ICQRzSAkEAEoBCAEESAEABWjnxNSmFWgRF2QAFmgZ eFQAQ0oUAE9KAwBRSgMAXkoDAGFKFABtSAkIc0gJCInKBwEBAPXE1KaDKgFtSAkEc0gJBABKAQgB BEgBAAVo58TUphVoERdkABZoFBRjAENKFABPSgMAUUoDAF5KAwBhShQAbUgJCHNICQiJygcBAQD1 xNSmgyoBbUgJBHNICQQG5hgAACsZAABQGQAAlBkAAMEZAAD+GQAAOhoAALEAAAAAAAAAAAAAAABj AAAAAAAAAAAAAAAAWAAAAAAAAAAAAAAAAFgAAAAAAAAAAAAAAABYAAAAAAAAAAAAAAAAWAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAALAAATpHgANyQAOCQASCQAZ2QUFGMATgAAE6R4ADckADgkAEMk AUXGgAAAAQDoxNSmAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAASCQAZ2QZeFQATgAAE6R4ADckADgkAEMkAUXGgAAAAQDnxNSmAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAASCQAZ2QUFGMAAAY8GgAAaBoAAHIaAABhHAAAhxwAAIgcAACMHAAAkxwAAJccAACdHAAAxRwA ANq0lW9JbyNJb0kAAAAAAAAAAAAAAAAAAAAASgEIAQRIAQAFaM/E1KYVaBEXZAAWaBEXZABDShQA T0oDAFFKAwBeSgMAYUoUAG1ICQhzSAkIicoHAQEA9cTUpoMqAW1ICQRzSAkEAEoBCAEESAEABWjP xNSmFWgRF2QAFmgpV+EAQ0oUAE9KAwBRSgMAXkoDAGFKFABtSAkIc0gJCInKBwEBAPXE1KaDKgFt SAkEc0gJBABKAQgBBEgBAAVozsTUphVoERdkABZoKVfhAENKFABPSgMAUUoDAF5KAwBhShQAbUgJ CHNICQiJygcBAQD1xNSmgyoBbUgJBHNICQQAPRVoERdkABZoFBRjAENKFABPSgMAUUoDAF5KAwBh ShQAbUgJCHNICQiJygcBAQD1xNSmgyoBbUgJBHNICQRKAQgBBEgBAAVo6MTUphVoERdkABZoGXhU AENKFABPSgMAUUoDAF5KAwBhShQAbUgJCHNICQiJygcBAQD1xNSmgyoBbUgJBHNICQQASgEIAQRI AQAFaM3E1KYVaBEXZAAWaClX4QBDShQAT0oDAFFKAwBeSgMAYUoUAG1ICQhzSAkIicoHAQEA9cTU poMqAW1ICQRzSAkECjoaAAB0GgAAuhoAAPwaAABAGwAAehsAALwbAAD+GwAAQRwAAIgcAADPHAAA sQAAAAAAAAAAAAAAAKYAAAAAAAAAAAAAAACmAAAAAAAAAAAAAAAApgAAAAAAAAAAAAAAAKYAAAAA AAAAAAAAAACmAAAAAAAAAAAAAAAApgAAAAAAAAAAAAAAAKYAAAAAAAAAAAAAAACmAAAAAAAAAAAA AAAAWAAAAAAAAAAAAAAAAAAATgAAE6R4ADckADgkAEMkAUXGgAAAAQDPxNSmAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAASCQAZ2QR F2QACwAAE6R4ADckADgkAEgkAGdkFBRjAE4AABOkeAA3JAA4JABDJAFFxoAAAAEAzMTUpgAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AEgkAGdkKVfhAAAKxRwAAMocAADUHAAAFh0AAC0dAAAuHQAALx0AADAdAADrHQAA7B0AADAeAADn wZt1wV1BG+cbSgEIAQRIAQAFaNHE1KYVaBEXZAAWaClX4QBDShQAT0oDAFFKAwBeSgMAYUoUAG1I CQhzSAkIicoHAQEA9cTUpoMqAW1ICQRzSAkEADYBCAEESAEABWjRxNSmFWgRF2QAFmgpV+EAbUgJ CHNICQiJygcBAQD1xNSmgyoBbUgJBHNICQQALgEIAQRIAQAFaNHE1KYVaBEXZAAWaClX4QCJygcB AQD1xNSmgyoBbUgJBHNICQQASgEIAQRIAQAFaNPE1KYVaBEXZAAWaMB7dwBDShQAT0oDAFFKAwBe SgMAYUoUAG1ICQhzSAkIicoHAQEA9cTUpoMqAW1ICQRzSAkEAEoBCAEESAEABWjSxNSmFWgRF2QA FmjAe3cAQ0oUAE9KAwBRSgMAXkoDAGFKFABtSAkIc0gJCInKBwEBAPXE1KaDKgFtSAkEc0gJBABK AQgBBEgBAAVoz8TUphVoERdkABZoKVfhAENKFABPSgMAUUoDAF5KAwBhShQAbUgJCHNICQiJygcB AQD1xNSmgyoBbUgJBHNICQQALwEIgQRIAQAFaPXE1KYWaBEXZABDShQAT0oDAFFKAwBeSgMAYUoU AG1ICQRzSAkEAArPHAAAYR0AAKkdAACxAAAAAAAAAAAAAAAAYwAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABOAAATpHgANyQAOCQAQyQBRcaA AAABANHE1KYAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAABIJABnZClX4QBOAAATpHgANyQAOCQAQyQBRcaAAAABANHE1KYAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABI JABnZMB7dwAAAqkdAADsHQAAMR4AAH0eAACxAAAAAAAAAAAAAAAAYwAAAAAAAAAAAAAAAGMAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAE4AABOkeAA3JAA4JABDJAFFxoAA AAEA0sTUpgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAEgkAGdkERdkAE4AABOkeAA3JAA4JABDJAFFxoAAAAEA0sTUpgAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEgk AGdkKVfhAAADMB4AADEeAAA+HgAAPx4AAHweAAB9HgAAiB4AAJgeAACpHgAAqh4AALceAABJIwAA SyMAAOfBqcHnwYPBXcE+JgAAAAAAAAAAAAAAAC8BCIEESAEABWj3xNSmFmgRF2QAQ0oUAE9KAwBR SgMAXkoDAGFKFABtSAkEc0gJBD0VaBEXZAAWaBQUYwBDShQAT0oDAFFKAwBeSgMAYUoUAG1ICQhz SAkIicoHAQEA9cTUpoMqAW1ICQRzSAkESgEIAQRIAQAFaPTE1KYVaBEXZAAWaBEXZABDShQAT0oD AFFKAwBeSgMAYUoUAG1ICQhzSAkIicoHAQEA9cTUpoMqAW1ICQRzSAkEAEoBCAEESAEABWjRxNSm FWgRF2QAFmjAe3cAQ0oUAE9KAwBRSgMAXkoDAGFKFABtSAkIc0gJCInKBwEBAPXE1KaDKgFtSAkE c0gJBAAvAQiBBEgBAAVo9cTUphZoERdkAENKFABPSgMAUUoDAF5KAwBhShQAbUgJBHNICQRKAQgB BEgBAAVo0cTUphVoERdkABZoKVfhAENKFABPSgMAUUoDAF5KAwBhShQAbUgJCHNICQiJygcBAQD1 xNSmgyoBbUgJBHNICQQALwEIgQRIAQAFaPbE1KYWaBEXZABDShQAT0oDAFFKAwBeSgMAYUoUAG1I CQRzSAkEAAx9HgAAtR4AALceAACxAAAAAAAAAAAAAAAAYwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABOAAATpHgANyQAOCQAQyQBRcaAAAAB ANHE1KYAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAABIJABnZClX4QBOAAATpHgANyQAOCQAQyQBRcaAAAABAPbE1KYAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABIJABn ZBEXZAAAArceAAC4HgAA2x4AAB8fAABkHwAAqR8AALcfAAD6HwAAPyAAAIQgAADGIAAABiEAAEUh AACKIQAAzCEAAAgiAABMIgAAbSIAAJsiAADcIgAAsQAAAAAAAAAAAAAAAKYAAAAAAAAAAAAAAACm AAAAAAAAAAAAAAAApgAAAAAAAAAAAAAAAKYAAAAAAAAAAAAAAACmAAAAAAAAAAAAAAAApgAAAAAA AAAAAAAAAKYAAAAAAAAAAAAAAACmAAAAAAAAAAAAAAAApgAAAAAAAAAAAAAAAKYAAAAAAAAAAAAA AACmAAAAAAAAAAAAAAAApgAAAAAAAAAAAAAAAKYAAAAAAAAAAAAAAACmAAAAAAAAAAAAAAAApgAA AAAAAAAAAAAAAKYAAAAAAAAAAAAAAACmAAAAAAAAAAAAAAAApgAAAAAAAAAAAAAAAAAAAAAACwAA E6R4ADckADgkAEgkAGdkFBRjAE4AABOkeAA3JAA4JABDJAFFxoAAAAEAz8TUpgAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEgkAGdk KVfhAAAT3CIAABMjAABLIwAAhiMAAMsjAAAHJAAATSQAAJEkAADQJAAADCUAABolAAA9JQAAgSUA AMclAAAIJgAALyYAAHQmAAC6JgAA+iYAADonAAD0AAAAAAAAAAAAAAAA9AAAAAAAAAAAAAAAAKYA AAAAAAAAAAAAAAD0AAAAAAAAAAAAAAAA9AAAAAAAAAAAAAAAAPQAAAAAAAAAAAAAAAD0AAAAAAAA AAAAAAAA9AAAAAAAAAAAAAAAAPQAAAAAAAAAAAAAAAD0AAAAAAAAAAAAAAAA9AAAAAAAAAAAAAAA APQAAAAAAAAAAAAAAAD0AAAAAAAAAAAAAAAA9AAAAAAAAAAAAAAAAPQAAAAAAAAAAAAAAAD0AAAA AAAAAAAAAAAA9AAAAAAAAAAAAAAAAPQAAAAAAAAAAAAAAAD0AAAAAAAAAAAAAAAAAAAAAABOAAAT pHgANyQAOCQAQyQBRcaAAAABAPfE1KYAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABIJABnZBQUYwALAAATpHgANyQAOCQASCQAZ2QU FGMAABNLIwAATSMAAIQjAABqLAAAaywAAGwsAAB6LAAAqCwAAKksAACeMQAA5MmqkndfRyiqAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD0VaBEXZAAWaBEXZABDShQAT0oDAFFKAwBeSgMA YUoUAG1ICQhzSAkIicoHAQEA9cTUpoMqAW1ICQRzSAkELwEIgQRIAQAFaPvE1KYWaBEXZABDShQA T0oDAFFKAwBeSgMAYUoUAG1ICQRzSAkELwEIgQRIAQAFaPrE1KYWaBEXZABDShQAT0oDAFFKAwBe SgMAYUoUAG1ICQRzSAkENQEIgQRIAQAFaPrE1KYVaBEXZAAWaBEXZABDShQAT0oDAFFKAwBeSgMA YUoUAG1ICQRzSAkELwEIgQRIAQAFaPrE1KYWaBQUYwBDShQAT0oDAFFKAwBeSgMAYUoUAG1ICQRz SAkEPRVoERdkABZoFBRjAENKFABPSgMAUUoDAF5KAwBhShQAbUgJCHNICQiJygcBAQD1xNSmgyoB bUgJBHNICQQ1AQiBBEgBAAVo98TUphVoERdkABZoERdkAENKFABPSgMAUUoDAF5KAwBhShQAbUgJ BHNICQQ1AQiBBEgBAAVo+MTUphVoERdkABZoERdkAENKFABPSgMAUUoDAF5KAwBhShQAbUgJBHNI CQQACTonAAB9JwAAvicAAAEoAABDKAAAhygAAMIoAAAGKQAASikAAGcpAACBKQAAxikAAAwqAABO KgAAlCoAAKIqAADAKgAA9CoAABkrAAAyKwAAUCsAAJUrAACtKwAA2ysAABwsAAA9LAAAaywAAPQA AAAAAAAAAAAAAAD0AAAAAAAAAAAAAAAA9AAAAAAAAAAAAAAAAPQAAAAAAAAAAAAAAAD0AAAAAAAA AAAAAAAA9AAAAAAAAAAAAAAAAPQAAAAAAAAAAAAAAAD0AAAAAAAAAAAAAAAA9AAAAAAAAAAAAAAA APQAAAAAAAAAAAAAAAD0AAAAAAAAAAAAAAAA9AAAAAAAAAAAAAAAAPQAAAAAAAAAAAAAAAD0AAAA AAAAAAAAAAAA9AAAAAAAAAAAAAAAAPQAAAAAAAAAAAAAAAD0AAAAAAAAAAAAAAAA9AAAAAAAAAAA AAAAAPQAAAAAAAAAAAAAAAD0AAAAAAAAAAAAAAAA9AAAAAAAAAAAAAAAAPQAAAAAAAAAAAAAAAD0 AAAAAAAAAAAAAAAA9AAAAAAAAAAAAAAAAPQAAAAAAAAAAAAAAAD0AAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACwAAE6R4ADckADgkAEgkAGdkFBRj AAAaaywAAKksAADELAAA9SwAAB4tAAA4LQAAWS0AAJAtAADGLQAA9i0AABUuAABVLgAAly4AANwu AAAJLwAARC8AAIUvAADGLwAABTAAACEwAACxAAAAAAAAAAAAAAAApgAAAAAAAAAAAAAAAKYAAAAA AAAAAAAAAACmAAAAAAAAAAAAAAAApgAAAAAAAAAAAAAAAKYAAAAAAAAAAAAAAACmAAAAAAAAAAAA AAAApgAAAAAAAAAAAAAAAKYAAAAAAAAAAAAAAACmAAAAAAAAAAAAAAAApgAAAAAAAAAAAAAAAKYA AAAAAAAAAAAAAACmAAAAAAAAAAAAAAAApgAAAAAAAAAAAAAAAKYAAAAAAAAAAAAAAACmAAAAAAAA AAAAAAAApgAAAAAAAAAAAAAAAKYAAAAAAAAAAAAAAACmAAAAAAAAAAAAAAAAAAAAAAALAAATpHgA NyQAOCQASCQAZ2QUFGMATgAAE6R4ADckADgkAEMkAUXGgAAAAQD6xNSmAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAASCQAZ2QRF2QA ABMhMAAAODAAAF8wAAB6MAAAvjAAAPYwAAA4MQAAezEAAJsxAADDMQAADDIAAPQAAAAAAAAAAAAA AAD0AAAAAAAAAAAAAAAA9AAAAAAAAAAAAAAAAPQAAAAAAAAAAAAAAAD0AAAAAAAAAAAAAAAA9AAA AAAAAAAAAAAAAPQAAAAAAAAAAAAAAAD0AAAAAAAAAAAAAAAA9AAAAAAAAAAAAAAAAKYAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAE4AABOkeAA3 JAA4JABDJAFFxoAAAAEABMXUpgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEgkAGdkz2C2AAsAABOkeAA3JAA4JABIJABnZBQUYwAA Cp4xAADDMQAAxDEAANAxAADZMQAA6TEAAPcxAAAAMgAAAzIAAAsyAAAMMgAAFTIAAB0yAABAMgAA QjIAAEkyAABNMgAATzIAAFAyAABkMgAAajIAAGsyAACXMgAAmDIAAN4yAADfMgAA9jIAAOfPtJnP gc+BtIG0gbRptFG0gbRRgbSBtIG0AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAC8BCIEESAEA BWgCxdSmFmgRF2QAQ0oUAE9KAwBRSgMAXkoDAGFKFABtSAkEc0gJBC8BCIEESAEABWgCxdSmFmjP YLYAQ0oUAE9KAwBRSgMAXkoDAGFKFABtSAkEc0gJBC8BCIEESAEABWgFxdSmFmjPYLYAQ0oUAE9K AwBRSgMAXkoDAGFKFABtSAkEc0gJBDUBCIEESAEABWgBxdSmFWgRF2QAFmgRF2QAQ0oUAE9KAwBR SgMAXkoDAGFKFABtSAkEc0gJBDUBCIEESAEABWgAxdSmFWgRF2QAFmgRF2QAQ0oUAE9KAwBRSgMA XkoDAGFKFABtSAkEc0gJBC8BCIEESAEABWgExdSmFmjPYLYAQ0oUAE9KAwBRSgMAXkoDAGFKFABt SAkEc0gJBC8BCIEESAEABWgAxdSmFmgRF2QAQ0oUAE9KAwBRSgMAXkoDAGFKFABtSAkEc0gJBAAa DDIAAFAyAACYMgAA3zIAACkzAABwMwAAkzMAALEAAAAAAAAAAAAAAACxAAAAAAAAAAAAAAAAsQAA AAAAAAAAAAAAAGMAAAAAAAAAAAAAAACxAAAAAAAAAAAAAAAAsQAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAATgAAE6R4ADckADgkAEMkAUXGgAAAAQACxdSmAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAASCQAZ2TPYLYATgAAE6R4ADckADgkAEMkAUXGgAAAAQAAxdSmAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAASCQAZ2TPYLYAAAb2 MgAA/zIAACgzAAApMwAALjMAAC8zAABvMwAAcDMAAJEzAACSMwAAkzMAAJQzAACXMwAApzMAAKgz AACpMwAAFDUAABU1AAAWNQAAFzUAAOfMtMy0zLTM55zntH1yaGBVUXIAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGFmglFF8AABQV aMB7dwAWaMB7dwBtSAkEc0gJBAAOFmjAe3cAbUgJBHNICQQAEwNqAAAAABZowHt3ADBKEABVCAEU FWgRF2QAFmgUFGMAbUgJBHNICQQAPRVoERdkABZoFBRjAENKFABPSgMAUUoDAF5KAwBhShQAbUgJ CHNICQiJygcBAQD1xNSmgyoBbUgJBHNICQQvAQiBBEgBAAVoAMXUphZoERdkAENKFABPSgMAUUoD AF5KAwBhShQAbUgJBHNICQQvAQiBBEgBAAVoBsXUphZoz2C2AENKFABPSgMAUUoDAF5KAwBhShQA bUgJBHNICQQ1AQiBBEgBAAVoAMXUphVoERdkABZoERdkAENKFABPSgMAUUoDAF5KAwBhShQAbUgJ BHNICQQvAQiBBEgBAAVoA8XUphZoz2C2AENKFABPSgMAUUoDAF5KAwBhShQAbUgJBHNICQQAE5Mz AACUMwAApzMAAKgzAADYMwAAHTQAAHs0AAB8NAAAFTUAALEAAAAAAAAAAAAAAABjAAAAAAAAAAAA AAAAWAAAAAAAAAAAAAAAAFYAAAAAAAAAAAAAAABOAAAAAAAAAAAAAAAATgAAAAAAAAAAAAAAAEkA AAAAAAAAAAAAAABJAAAAAAAAAAAAAAAAAAAAAAAAAAQRAGdkwHt3AAgRAAomAAtGAQBnZMB7dwAA AREACwAAE6R4ADckADgkAEgkAGdkZz/4AE4AABOkeAA3JAA4JABDJAFFxoAAAAEAAMXUpgAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AEgkAGdkFBRjAE4AABOkeAA3JAA4JABDJAFFxoAAAAEAA8XUpgAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEgkAGdkFBRjAAAIFTUA ABY1AAAXNQAA/QAAAAAAAAAAAAAAAPIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAsAABOkeAA3JAA4JABIJABnZGc/+AAAAQAAAAIyADGQ aAE6cBQUYwAfsIIuILDGQSGwoAUisLoFI5CgBSSQoAUlsAAAF7DEAhiwxAIMkMQCAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACGAhQAEgABAJwADwAE AAAABAAAAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAABEAABA8f8CAEQADAQAAAAAAAAAAAYATgBvAHIAbQBhAGwAAAACAAAAHABDShgAX0gB BGFKGABtSAgEbkgRBHNICAR0SBEEAAAAAAAAAAAAAAAAAAAAAAAARABBQPL/oQBEAAwFAAAAAAAA AAAWAEQAZQBmAGEAdQBsAHQAIABQAGEAcgBhAGcAcgBhAHAAaAAgAEYAbwBuAHQAAAAAAFIAaUDz /7MAUgAMBQAAAAAAAAAADABUAGEAYgBsAGUAIABOAG8AcgBtAGEAbAAAABwAF/YDAAA01gYAAQoD bAA01gYAAQUDAABh9gMAAAIACwAAACgAa0D0/8EAKAAABQAAAAAAAAAABwBOAG8AIABMAGkAcwB0 AAAAAgAAAAAAAABIAJlAAQDyAEgADAUAAClX4QAAAAwAQgBhAGwAbABvAG8AbgAgAFQAZQB4AHQA AAACAA8AFABDShAAT0oFAFFKBQBeSgUAYUoQAEIAJ0CiAAEBQgAMBQAAwHt3AAAAEQBDAG8AbQBt AGUAbgB0ACAAUgBlAGYAZQByAGUAbgBjAGUAAAAIAENKEABhShAAPAAeQAEAEgE8AAwFAADAe3cA AAAMAEMAbwBtAG0AZQBuAHQAIABUAGUAeAB0AAAAAgARAAgAQ0oUAGFKFABAAGoAEQESAUAADAUA AMB7dwAAAA8AQwBvAG0AbQBlAG4AdAAgAFMAdQBiAGoAZQBjAHQAAAACABIABgA1CIFcCIFEAFpA AQAyAUQADAQAABEXZAAAAAoAUABsAGEAaQBuACAAVABlAHgAdAAAAAIAEwAUAENKFABPSgYAUUoG AF5KBgBhShQAFgBUAGgAZQBvAGQAbwByAGUAIABCAC4AIABaAGEAaABhAHIAaQBhAGQAaQBzAGEE AAAXLQAAAwBUAEIAWgAAAAAAAAAAAAAAAAAAAAAAAADfkJwN3MTUpgAAAAAAAAAAAAAAAAAAAAAA AG0BAABwAQAAAAAAABctAAAEAAB4AAAAAP////8AAAAAKgAAACsAAABRAAAAcgAAAJ0AAADFAAAA ygAAANcAAADmAAAA/wAAABEBAAASAQAAVQEAAHsBAACMAQAAjQEAAMwBAAARAgAAVQIAAJgCAADe AgAAIgMAAGcDAACmAwAA6AMAACsEAABkBAAAmAQAAJwEAACyBAAA7wQAAAUFAAALBQAAOQUAAEoF AABZBQAAgAUAAIsFAACRBQAAsAUAAOQFAADmBQAA9AUAACwGAAA2BgAATAYAAFUGAAB2BgAAfwYA AKIGAAC1BgAA7gYAAAwHAAAdBwAARAcAAHMHAACvBwAAuAcAAPEHAAApCAAARAgAAFoIAAB1CAAA tAgAAPsIAAAPCQAALAkAAE0JAACQCQAAvgkAAOQJAAAmCgAAZgoAAKkKAAC+CgAAzwoAANAKAAD5 CgAAPgsAAIQLAADDCwAABQwAAEYMAABgDAAApAwAAOQMAAApDQAAYw0AAIANAACRDQAAkg0AAMEN AAADDgAAKg4AAHAOAAC3DgAA1g4AABwPAAA/DwAAYw8AAIcPAACbDwAAyw8AABAQAABPEAAAkxAA ANAQAADmEAAAKxEAAFARAACUEQAAwREAAP4RAAA6EgAAdBIAALoSAAD8EgAAQBMAAHoTAAC8EwAA /hMAAEEUAACIFAAAzxQAAGEVAACpFQAA7BUAADEWAAB9FgAAtRYAALcWAAC4FgAA2xYAAB8XAABk FwAAqRcAALcXAAD6FwAAPxgAAIQYAADGGAAABhkAAEUZAACKGQAAzBkAAAgaAABMGgAAbRoAAJsa AADcGgAAExsAAEsbAACGGwAAyxsAAAccAABNHAAAkRwAANAcAAAMHQAAGh0AAD0dAACBHQAAxx0A AAgeAAAvHgAAdB4AALoeAAD6HgAAOh8AAH0fAAC+HwAAASAAAEMgAACHIAAAwiAAAAYhAABKIQAA ZyEAAIEhAADGIQAADCIAAE4iAACUIgAAoiIAAMAiAAD0IgAAGSMAADIjAABQIwAAlSMAAK0jAADb IwAAHCQAAD0kAABrJAAAqSQAAMQkAAD1JAAAHiUAADglAABZJQAAkCUAAMYlAAD2JQAAFSYAAFUm AACXJgAA3CYAAAknAABEJwAAhScAAMYnAAAFKAAAISgAADgoAABfKAAAeigAAL4oAAD2KAAAOCkA AHspAACbKQAAwykAAAwqAABQKgAAmCoAAN8qAAApKwAAcCsAAJMrAACUKwAApysAAKgrAADYKwAA HSwAAHssAAB8LAAAFS0AABgtAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAIAAmAAAAAAwAAAA AAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAA AAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAA AACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAA AIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAA gAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACA AAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAA AACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAA AIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAA gAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACA AAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAA AAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAA AAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAA AAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAA AAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAA AAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAA AAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAA AAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAA AACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAA AJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAA mAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACY AAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgA AAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAA AAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAA ADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAA MAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAw AAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAA AAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAA AAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAA AAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAA AAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAA AACAAAAAgAAAAAAAAAAAEACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAA AIAAAACAAAAAAAAAAAAQAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAEACYAAAAADAAAAAAAAAA gAAAAIAAAAAAAAAAABAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAQAJgAAAAAMAAAAAAAAACA AAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAA AACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAA AIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAA gAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACA AAAAAAAAAAAQAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAA AAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAA AAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAA AAAAAAAQAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAA AAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAA AAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAA AAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAA AAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAZgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAA AACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAA AJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAEACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAABAA mAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAQAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAACACY AAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAABAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAIAJgA AAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAEACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAA AAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAA ADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAA MAAAAAAAAACAAAAAgAAAAAAAAAAAEACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAABAAmAAAAAAw AAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAA AAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAA AAAAAACAAAAAgAAAAAAAAAAAEACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAA AAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAA AAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAA AACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAA AIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAEACYAAAAADAAAAAAAAAA gAAAAIAAAAAAAAAAABAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAQAJgAAAAAMAAAAAAAAACA AAAAgAAAAAAAAAAAEACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAABAAmAAAAAAwAAAAAAAAAIAA AACAAAAAAAAAAAAQAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAEACYAAAAADAAAAAAAAAAgAAA AIAAAAAAAAAAABAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAQAJgAAAAAMAAAAAAAAACAAAAA gAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACA AAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAA AAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAA AAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAA AAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAA AAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAA AAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAA AAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAA AAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAA AACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAQ AJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAA mAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACY AAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgA AAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAA AAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAA ADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAA MAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAw AAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAA AAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAA AAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAA AAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAA AAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAA AACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAA AIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAA gAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACA AAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAA AACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAA AIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAA gAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACA AAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAA AAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAA AAAAAAAAEACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAA AAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAA AAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAA AAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAA AAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAA AAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAA AACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAA AJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAA mAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACY AAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgA AAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAA AAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAA ADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAA MAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAABAAmAAAAAAw AAAAAAAAAIAAAACAAAAAAAAAAAAQAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAEACYAAAAADAA AAAAAAAAgAAAAIAAAAAAAAAAABAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAQAJgAAAAAMAAA AAAAAACAAAAAgAAAAAAAAAAAEACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAABAAmAAAAAAwAAAA AAAAAIAAAACAAAAAAAAAAAAQAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAEACYAAAAADAAAAAA AAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJhAAAARMAAAAAAA AACAAAAAgAAAAKAAAAAAAAeYQAEgETAAAAAAAAAAgAAAAIAAAACgAAAAAAAEmEABIBEwAQAAAAAA AIAAAACAAAAAoAAAAAAABJhAAAARMAAAAAAAAACAAAAAgAAAAKAAAAAAAACYQAAAETAAAAAAAAAA gAAAAIAAAACgAAAAAAAACAAAAAAwAAAAAAAAAAAAAAAABjBtAQAAAAAABwAAAAARAQAAEgEAAFUB AAB7AQAAjAEAAI0BAADxBwAAKQgAAEQIAABaCAAAdQgAALQIAAD7CAAADwkAACwJAABNCQAAkAkA ACYKAABmCgAAqQoAAL4KAADPCgAA0AoAAD4LAACECwAAwwsAAAUMAABGDAAAYAwAAOQMAAApDQAA Yw0AAIANAACRDQAAkg0AAMENAAADDgAAKg4AAHAOAAC3DgAA1g4AABwPAAA/DwAAYw8AAIcPAACb DwAAyw8AABAQAABPEAAAkxAAANAQAADmEAAAKxEAAFARAACUEQAAwREAAP4RAAA6EgAAdBIAAHoT AAC8EwAA/hMAAEEUAACIFAAAzxQAAGEVAACpFQAA7BUAADEWAAB9FgAAtRYAALcWAAC4FgAAbRoA AJsaAADcGgAAExsAAEsbAACGGwAArSMAANsjAAAcJAAAPSQAAGskAACpJAAA9igAADgpAAB7KQAA mykAAMMpAAAMKgAAUCoAAJgqAADfKgAAKSsAAHArAACTKwAAlCsAAKcrAACoKwAA2CsAAB0sAAB7 LAAAfCwAABUtAAAYLQAASYgAMAAwAAAAAAAAAQAAAHYAAAABAAAAcHsMB0mIADAAMAAAAAAAAAEA AAB1AAAAAAAAAAAAAAFJiAAwADAAAAAAAAABAAAAeQAAAAAAAAAAAAABSYgAMAAwAAAAAAAAAQAA AHgAAAAAAAAAAAAAAUmIADAAMAAAAAAAAAIAAAB2AAAAAAAAAAAAAAdJiAAwADAAAAAAAAACAAAA dgAAAAAAAAAAAAAHSYgAMAQwAAAAAAAAAQAAACcAAAAFAAAAfLV1B0mIADAEMAAAAAAAAAEAAAAm AAAAAAAAAAAAAAdJiAAwBDAAAAAAAAACAAAAJAAAAAAAAAAAAAAHSYgAMAQwAAAAAAAAAQAAACAA AAAAAAAAAAAAB0mIADAEMAAAAAAAAAEAAAAhAAAAAAAAAAAAEAdJiAAwBDAAAAAAAAABAAAAIQAA AAAAAAAAAAAHSYgAMAQwAAAAAAAAAQAAACEAAAAAAAAAAAAQB0mIADAEMAAAAAAAAAEAAAAhAAAA AAAAAAAAEAdJyAAwBDAAAAAAAAABAAAAIQAAAAAAAAAAABAHSYgAMAQwAAAAAAAAAQAAACEAAAAA AAAAAAAQB0mIADAEMAAAAAAAAAEAAAAhAAAAAAAAAAAAAAdJiAAwDzAAAAAAAAABAAAAJwAAABAA AAD0yHQHSYgAMA8wAAAAAAAAAQAAACYAAAAAAAAAAAAAAUmIADAPMAAAAAAAAAIAAAAkAAAAAAAA AAAAAAFJiAAwBDAAAAAAAAABAAAAIAAAAAAAAAAAAAABScgAMAAwAAAAAAAAAgAAAHYAAAAAAAAA AAAAAUmIADAEMAAAAAAAAAEAAAAhAAAAAAAAAAAAEAFJiAAwLjAAAAAAAAABAAAAMQAAAC8AAAB0 nG0HSYgAMC4wAAAAAAAAAQAAADAAAAAAAAAAAAAAB0mIADAuMAAAAAAAAAIAAAAuAAAAAAAAAAAA AAdJiAAwBDAAAAAAAAABAAAAIAAAAAAAAAAAAAAHSYgAMAQwAAAAAAAAAQAAACEAAAAAAAAAAAAQ B0mIADAEMAAAAAAAAAEAAAAhAAAAAAAAAAAAAAdJiAAwHTAAAAAAAAABAAAARQAAAB4AAACQ2c4H SYgAMB0wAAAAAAAAAQAAAEUAAAAAAAAAAACAAUmIADAdMAAAAAAAAAEAAABEAAAAAAAAAAAAgAFJ iAAwHTAAAAAAAAACAAAAQgAAAAAAAAAAAIABScgAMAAwAAAAAAAAAgAAAHYAAAAAAAAAAAAAAUmI ADAEMAAAAAAAAAEAAAAhAAAAAAAAAAAAAAFJiAAwBDAAAAAAAAABAAAAIQAAAAUAAACUl3UHSYgA MAQwAAAAAAAAAQAAACAAAAAAAAAAAAAAB0mIADAEMAAAAAAAAAEAAAAfAAAAAAAAAAAAAAdJiAAw BDAAAAAAAAABAAAABQAAAAAAAAAAAAAHSYgAMAQwAAAAAAAAAQAAAAQAAAAAAAAAAAAQB0mIADAE MAAAAAAAAAEAAAAEAAAAAAAAAAAAEAdJiAAwBDAAAAAAAAABAAAABAAAAAAAAAAAABAHSYgAMAQw AAAAAAAAAQAAAAQAAAAAAAAAAAAIB0mIADAEMAAAAAAAAAIAAAACAAAAAAAAAAAAEAdJiAAwBDAA AAAAAAACAAAAAgAAAAAAAAAAAAgHSYgAMAAwAAAAAAAAAQAAAAAAAAAAAAAAAAAQB0mIADAAMAAA AAAAAAEAAAAAAAAAAAAAAAAAAAdJyAAwADAAAAAAAAABAAAABAAAAAAAAAAAAAAHSYgAMDswAAAA AAAAAQAAABwAAAAAAAAAAAAAB0mIADA7MAAAAAAAAAIAAAAaAAAAAAAAAAAAAAdJiAAwCTAAAAAA AAABAAAABAAAAAAAAAAAAAAHSYgAMAkwAAAAAAAAAQAAAAUAAAAAAAAAAAAQB0mIADAJMAAAAAAA AAEAAAAFAAAAAAAAAAAAEAdJiAAwCTAAAAAAAAABAAAABQAAAAAAAAAAAAAHSYgAMAkwAAAAAAAA AQAAAAQAAAAAAAAAAAAAB0mIADAJMAAAAAAAAAIAAAACAAAAAAAAAAAAAAdJiAAwADAAAAAAAAAB AAAAAAAAAAAAAAAAAAAHScgAMAAwAAAAAAAAAQAAAAQAAAAAAAAAAAAQB0nIADAAMAAAAAAAAAEA AAAEAAAAAAAAAAAAAAdJiAAwDzAAAAAAAAABAAAABQAAABAAAABMc3sHSYgAMA8wAAAAAAAAAQAA AAQAAAAAAAAAAAAAB0mIADAPMAAAAAAAAAIAAAACAAAAAAAAAAAAAAdJiAAwADAAAAAAAAABAAAA AAAAAAAAAAAAAAAHScgAMAAwAAAAAAAAAQAAAAQAAAAAAAAAAAAQB0nIADAAMAAAAAAAAAEAAAAA AAAAAAAAAAAAEAdJiAAwFTAAAAAAAAACAAAAAwAAAAAAAAAAABAHSYgAMBUwAAAAAAAAAgAAAAMA AAAAAAAAAAAQB0mIADAVMAAAAAAAAAIAAAADAAAAAAAAAAAAEAdJiAAwFTAAAAAAAAACAAAAAwAA AAAAAAAAABAHSYgAMBUwAAAAAAAAAgAAAAMAAAAAAAAAAAAQB0mIADAVMAAAAAAAAAIAAAADAAAA AAAAAAAAEAdJyAAwADAAAAAAAAABAAAABAAAAAAAAAAAABAHScgAMAAwAAAAAAAAAQAAAAQAAAAA AAAAAAAAB0mIADBUMAAAAAAAAAEAAAAFAAAAVQAAAJygbQdJiAAwVDAAAAAAAAABAAAABAAAAAAA AAAAAAAHSYgAMFQwAAAAAAAAAgAAAAIAAAAAAAAAAAAAB0mIADAAMAAAAAAAAAEAAAAAAAAAAAAA AAAAAAdJyAAwADAAAAAAAAABAAAABAAAAAAAAAAAABAHScgAMAAwAAAAAAAAAQAAAAQAAAAAAAAA AAAAB0mIADBgMAAAAAAAAAEAAAAFAAAAYQAAAOyhbQdJiAAwYDAAAAAAAAABAAAABAAAAAAAAAAA AAAHSYgAMGAwAAAAAAAAAgAAAAIAAAAAAAAAAAAAB0mIADAAMAAAAAAAAAEAAAAAAAAAAAAAAAAA AAdJyAAwADAAAAAAAAABAAAABAAAAAAAAAAAABAHScgAMAAwAAAAAAAAAQAAAAQAAAAAAAAAAAAA B0mIADBmMAAAAAAAAAEAAAAFAAAAZwAAAJSibQdJiAAwZjAAAAAAAAABAAAABAAAAAAAAAAAAAAH SYgAMGYwAAAAAAAAAgAAAAIAAAAAAAAAAAAAAUmIADAAMAAAAAAAAAEAAAAAAAAAAAAAAAAAAAFJ yAAwADAAAAAAAAABAAAABAAAAAAAAAAAABABSYgAMGswAAAAAAAAAQAAAAsAAAAAAAAAAAAQAUmI ADBrMAAAAAAAAAEAAAAHAAAAAAAAAAAAEAFJiAAwazAAAAAAAAABAAAABgAAAAAAAAAAABABSYgA MGswAAAAAAAAAgAAAAQAAAAAAAAAAAAQAUmIADBrMAAAAAAAAAIAAAAEAAAAAAAAAAAAEAFJyAAw ADAAAAAAAAABAAAABAAAAAAAAAAAABABScgAMAAwAAAAAAAAAQAAAAQAAAAAAAAAAAAQAUnIADAA MAAAAAAAAAEAAAAEAAAAAAAAAAAAEAFJyAAwADAAAAAAAAABAAAABAAAAAAAAAAAAAABCAAAAAAw AAAAAAAAAAAAAAAABjBtAQAAAAAAB5pAAAARMAAAAAAAAACAAAAAgAAAAAAAAAAAAAeYQAEgETAA AAAAAAAAgAAAAIAAAAAAAAAAAAAHmEABIBEwAQAAAAAAAIAAAACAAAAAAAAAAAAAB5hAASARMAIA AAAAAACAAAAAgAAAAAAAAAAAAAeYQAEgETACAAAAAAAAgAAAAIAAAAAAAAAAAAAHCgAAAAAwAAAA AAAAAAAAAAAABjBtAQAAAAAABwAGAAB2DgAAvhIAALcWAAAzFwAA5RgAADwaAADFHAAAMB4AAEsj AACeMQAA9jIAABc1AAAbAAAAHwAAACIAAAAlAAAAJgAAACgAAAAqAAAALAAAAC8AAAAzAAAANwAA ADkAAAAABgAAKwwAAB0PAAD7EAAAzxIAAOQUAABjFwAA5hgAADoaAADPHAAAqR0AAH0eAAC3HgAA 3CIAADonAABrLAAAITAAAAwyAACTMwAAFTUAABc1AAAcAAAAHgAAACAAAAAhAAAAIwAAACQAAAAn AAAAKQAAACsAAAAtAAAALgAAADAAAAAxAAAAMgAAADQAAAA1AAAANgAAADgAAAA6AAAAOwAAAAAG AAAWNQAAHQAAAA8AAPA4AAAAAAAG8BgAAAACCAAAAgAAAAEAAAABAAAAAQAAAAIAAABAAB7xEAAA AP//AAAAAP8AgICAAPcAABAADwAC8JIAAAAQAAjwCAAAAAEAAAABBAAADwAD8DAAAAAPAATwKAAA AAEACfAQAAAAAAAAAAAAAAAAAAAAAAAAAAIACvAIAAAAAAQAAAUAAAAPAATwQgAAABIACvAIAAAA AQQAAAAOAABTAAvwHgAAAL8BAAAQAMsBAAAAAP8BAAAIAAQDCQAAAD8DAQABAAAAEfAEAAAAAQAA AP//AQAKAAAAAAHfkJwN/////zsEAACqKwAAAAAAAGEEAACqKwAAAAAAAEcAAABLAAAAkQAAAJQA AAC5AAAAvwAAAMUAAADJAAAAzQAAANEAAADmAAAA8QAAAPIAAAD4AAAA+QAAAP4AAACzBAAAuQQA AAwFAAASBQAApQUAAKsFAAD3BQAA/QUAADcGAABMBgAAVQYAAH8GAACABgAAogYAABEJAAAdCQAA LgkAADoJAADyDQAA9Q0AAAkPAAARDwAAwxEAAMwRAAA8EgAAQxIAANoUAADgFAAATRsAAFQbAACx HgAAuB4AABomAAAdJgAANyYAAD4mAACUJwAAlycAANYnAADZJwAAJCgAACgoAABZKAAAXSgAALkq AADCKgAAqCsAABgtAAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAc AAcAHAAHAAUABwAFAAcABQAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwA BwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAHAAAAAAApAAAAVQEAAHoBAACWAQAAmwEAAMwBAADU AQAAVQIAAFwCAACYAgAAngIAAN4CAADjAgAAIgMAACYDAABnAwAAaQMAAKYDAACuAwAA6AMAAO8D AAArBAAALgQAAMIEAADEBAAAGwUAAB0FAAA7BQAARQUAAFUFAABYBQAAYAUAAGIFAACsBQAArwUA ADYGAABLBgAATAYAAFQGAABVBgAAdQYAAHYGAAB+BgAAfwYAAKEGAAAMBwAADQcAAEYHAABTBwAA dQcAAHkHAACvBwAAtQcAALoHAAC+BwAA8QcAAPsHAAApCAAAKggAAEYIAABOCAAAXAgAAGoIAAB3 CAAAewgAAPsIAAAACQAAEQkAAB0JAAAuCQAAOgkAAJAJAACUCQAAJgoAAC0KAABmCgAAbQoAAKkK AACsCgAA/AoAAAMLAAA+CwAARwsAAIQLAACNCwAAwAsAAMILAADDCwAAygsAAAUMAAAKDAAAYAwA AGgMAACkDAAApgwAAOQMAADwDAAAKQ0AACsNAABjDQAAfw0AAAMOAAAKDgAAcA4AAHMOAAC3DgAA ug4AABwPAAAkDwAAPw8AAEIPAABjDwAAaw8AAIcPAACJDwAAyw8AAM0PAAAQEAAAFxAAAE8QAABa EAAAkxAAAJwQAADQEAAA2RAAAPYQAAD6EAAAKxEAAC0RAACUEQAAlhEAAMERAADCEQAA/hEAAP8R AAA6EgAAOxIAALoSAAC7EgAA/BIAAAITAABAEwAARBMAAHATAAB5EwAAehMAAIUTAAC8EwAAxhMA AP4TAAAEFAAAQRQAAEYUAACIFAAAixQAAM8UAADUFAAAYRUAAGoVAACpFQAAsRUAAOwVAAD2FQAA MRYAADgWAAB9FgAAhhYAAB8XAAAmFwAAZBcAAGgXAACpFwAAtRcAAPoXAAD8FwAAPxgAAEIYAACE GAAAiRgAAMYYAADLGAAABhkAABIZAABFGQAATRkAAIoZAACMGQAAzBkAANQZAABMGgAAWRoAAG0a AABuGgAAmxoAAJwaAADcGgAA3RoAABMbAAAUGwAASxsAAEwbAADLGwAAzhsAAE0cAABUHAAAkRwA AJQcAADQHAAA2RwAAAwdAAAYHQAAgR0AAIQdAAAIHgAAEx4AAHQeAAB5HgAAuh4AAMAeAAD6HgAA /R4AADofAABBHwAAfR8AAIIfAAC+HwAAxx8AAAEgAAAKIAAAQyAAAEggAACHIAAAjyAAAAYhAAAP IQAASiEAAFEhAADGIQAAzyEAAAwiAAAVIgAATiIAAFUiAACUIgAAlyIAAPQiAAD1IgAAGSMAABoj AAAyIwAAMyMAAFAjAABRIwAA2yMAANwjAAAcJAAAHSQAAD0kAAA+JAAAayQAAGwkAAD1JAAA9iQA AB4lAAAfJQAAOCUAADklAABZJQAAWiUAAJAlAACRJQAAxiUAAMclAABVJgAAXiYAAJcmAACaJgAA 3CYAAN8mAABEJwAATycAAIUnAACQJwAAxicAANInAAAFKAAADygAAL4oAADBKAAA9igAAAMpAAA4 KQAAQCkAAHspAACHKQAADCoAABUqAACYKgAAnCoAAN8qAADiKgAAKSsAACsrAABwKwAAdisAAKgr AAAYLQAAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAH ADMABwAzAAcAMwAHADMABwAzAAcABQAHAAUABwAFAAcABQAHAAUABwAzAAcAMwAHADMABwAzAAcA MwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAz AAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMA BwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAH ADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcA MwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAz AAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMA BwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAH ADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcA MwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcABwAAAAAAewEA AI0BAAC+CgAAzwoAANAKAAD5CgAAgA0AAJkNAACUKwAApysAAKgrAAAYLQAABwAFAAcABQAHAAUA BwAFAAcABQAHAAcAAQBEWsdlHj/CGP8P/w//D/8P/w//D/8P/w//DxAAAQAAAAQAAQAAAAAAAAAA AAAAAAAAAAAAAxgAAA+E0AIRhJj+FcYFAAHQAgZehNACYISY/m8oAAIAAAApAAEAAAAEgAEAAAAA AAAAAAAAAAAAAAAAAAoYAAAPhKAFEYSY/hXGBQABoAUGXoSgBWCEmP6HaAAAAACISAAAAgABAC4A AQAAAAKCAQAAAAAAAAAAAAAAAAAAAAAAChgAAA+EcAgRhEz/FcYFAAFwCAZehHAIYIRM/4doAAAA AIhIAAACAAIALgABAAAAAIABAAAAAAAAAAAAAAAAAAAAAAAKGAAAD4RACxGEmP4VxgUAAUALBl6E QAtghJj+h2gAAAAAiEgAAAIAAwAuAAEAAAAEgAEAAAAAAAAAAAAAAAAAAAAAAAoYAAAPhBAOEYSY /hXGBQABEA4GXoQQDmCEmP6HaAAAAACISAAAAgAEAC4AAQAAAAKCAQAAAAAAAAAAAAAAAAAAAAAA ChgAAA+E4BARhEz/FcYFAAHgEAZehOAQYIRM/4doAAAAAIhIAAACAAUALgABAAAAAIABAAAAAAAA AAAAAAAAAAAAAAAKGAAAD4SwExGEmP4VxgUAAbATBl6EsBNghJj+h2gAAAAAiEgAAAIABgAuAAEA AAAEgAEAAAAAAAAAAAAAAAAAAAAAAAoYAAAPhIAWEYSY/hXGBQABgBYGXoSAFmCEmP6HaAAAAACI SAAAAgAHAC4AAQAAAAKCAQAAAAAAAAAAAAAAAAAAAAAAChgAAA+EUBkRhEz/FcYFAAFQGQZehFAZ YIRM/4doAAAAAIhIAAACAAgALgABAAAARFrHZQAAAAAAAAAAAAAAAP///////wEAAAAAAP//AQAA ABIAWrAqIRkACAQbAAgEDwAIBBkACAQbAAgEDwAIBBkACAQbAAgEAQACDMYKAAAAAAAAAAAAAQIA AgAQAAAABAAAAAgAAADlAAAAAAAAAA8AAABeUz0AXl4+ABl4VAAlFF8AFBRjABEXZADAe3cAVSWG AFp0iwDPYLYAZ3/OAHsb4QApV+EAnDPkAJl58gBnP/gA/0ADgAEABQwAAAUMAADIcE0CAQABAAUM AAAAAAAABQwAAAAAAAACEAAAAAAAAAAXLQAAQAAAEABAAAD//wIAAAAHAFUAbgBrAG4AbwB3AG4A FgBUAGgAZQBvAGQAbwByAGUAIABCAC4AIABaAGEAaABhAHIAaQBhAGQAaQBzAP//AgAIAAAAAAAA AAAAAAAAAAAAAAAAAAEA//8CAAAAAAAAAP//AAACAP//AAAAAP//AAACAP//AAAAAAcAAABHFpAB oQACAgYDBQQFAgME7zoA4EF4AMAJAAAAAAAAAP8BAAAAAAAAVABpAG0AZQBzACAATgBlAHcAIABS AG8AbQBhAG4AAAA1FpABAgAFBQECAQcGAgUHAAAAAAAAABAAAAAAAAAAAAAAAIAAAAAAUwB5AG0A YgBvAGwAAAAzJpABoQACCwYEAgICAgIE/zoA4EN4AMAJAAAAAAAAAP8BAAAAAAAAQQByAGkAYQBs AAAARTWQAaEAAgsGCQQFBAICBI8CAIAAGAAAAAAAAAAAAAAfAAAAAAAAAEwAdQBjAGkAZABhACAA QwBvAG4AcwBvAGwAZQAAAEc1kAGACgICBgkEAgUIAwT/AgDg+/3HahIAAAAAAAAAnwACAAAAAABN AFMAIABNAGkAbgBjAGgAbwAAAC3/M/8gAA5mHWcAADUmkAGhAAILBgQDBQQEAgT/OgDhW2AAwCkA AAAAAAAA/wEBAAAAAABUAGEAaABvAG0AYQAAAD81kAGhAAIHAwkCAgUCBAT/OgDgQ3gAwAkAAAAA AAAA/wEAAAAAAABDAG8AdQByAGkAZQByACAATgBlAHcAAAAiAAQAcQiIGADw0AIAAGgBAAAAAAfF 1KZ11dQGAAAAAAQACgAAANIGAADWJAAAAQAWAAAABAADEE4AAADSBgAA1iQAAAEAFgAAAE4AAAAA AAAAcQMA8BAAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAoAWgBbQAtACBgTI0AAAQABkAZAAA ABkAAACSKwAAkisAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAIAAAAAAAAAAAAJMoNRAPAQAAgAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAEhYAAAAAAnw/w8BAAE/AADlBAAAjAEAAP///3////9/////f////3////9/////fxQU YwAAAAAAMgAAAAAAAAAAAAAAAAABAAAA//8SAAAAAAAAACUAZAByAGEAZgB0AC0AdABzAGEAbwAt AHIAbwBsAGwALQBzAGUAYwB1AHIAaQB0AHkALQBmAHIAYQBtAGUAdwBvAHIAawAtADAAMAAAAAAA AAAWAFQAaABlAG8AZABvAHIAZQAgAEIALgAgAFoAYQBoAGEAcgBpAGEAZABpAHMAFgBUAGgAZQBv AGQAbwByAGUAIABCAC4AIABaAGEAaABhAHIAaQBhAGQAaQBzAAAAAAAAAAAAAAAAAAAAAAAAAAAA EAAAAAYAAAABAAAAAAAMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAA/v8AAAYAAgAAAAAAAAAAAAAAAAAAAAAAAQAAAOCFn/L5T2gQq5EIACsns9kwAAAA sAEAABEAAAABAAAAkAAAAAIAAACYAAAAAwAAAMgAAAAEAAAA1AAAAAUAAAD0AAAABgAAAAABAAAH AAAADAEAAAgAAAAgAQAACQAAAEABAAASAAAATAEAAAoAAABsAQAADAAAAHgBAAANAAAAhAEAAA4A AACQAQAADwAAAJgBAAAQAAAAoAEAABMAAACoAQAAAgAAAOUEAAAeAAAAKAAAAGRyYWZ0LXRzYW8t cm9sbC1zZWN1cml0eS1mcmFtZXdvcmstMDAAAAAeAAAABAAAAAAAAAAeAAAAGAAAAFRoZW9kb3Jl IEIuIFphaGFyaWFkaXMAAB4AAAAEAAAAAAAAAB4AAAAEAAAAAAAAAB4AAAAMAAAATm9ybWFsLmRv dAAAHgAAABgAAABUaGVvZG9yZSBCLiBaYWhhcmlhZGlzAAAeAAAABAAAADQAAAAeAAAAGAAAAE1p Y3Jvc29mdCBPZmZpY2UgV29yZAAAAEAAAAAAvKBlAQAAAEAAAAAA0rYU/8TJAUAAAAAATmU4oMbJ AQMAAAABAAAAAwAAANIGAAADAAAA1iQAAAMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AP7/AAAGAAIAAAAAAAAAAAAAAAAAAAAAAAEAAAAC1c3VnC4bEJOXCAArLPmuMAAAAAwBAAAMAAAA AQAAAGgAAAAPAAAAcAAAAAUAAAB8AAAABgAAAIQAAAARAAAAjAAAABcAAACUAAAACwAAAJwAAAAQ AAAApAAAABMAAACsAAAAFgAAALQAAAANAAAAvAAAAAwAAADuAAAAAgAAAOUEAAAeAAAABAAAAAAA AAADAAAATgAAAAMAAAAWAAAAAwAAAJIrAAADAAAADycLAAsAAAAAAAAACwAAAAAAAAALAAAAAAAA AAsAAAAAAAAAHhAAAAEAAAAmAAAAZHJhZnQtdHNhby1yb2xsLXNlY3VyaXR5LWZyYW1ld29yay0w MAAMEAAAAgAAAB4AAAAGAAAAVGl0bGUAAwAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABAAAAAgAA AAMAAAAEAAAABQAAAAYAAAAHAAAACAAAAAkAAAAKAAAACwAAAAwAAAANAAAADgAAAA8AAAAQAAAA EQAAABIAAAATAAAAFAAAABUAAAAWAAAAFwAAABgAAAAZAAAAGgAAABsAAAAcAAAAHQAAAB4AAAAf AAAAIAAAACEAAAAiAAAAIwAAACQAAAAlAAAAJgAAACcAAAAoAAAAKQAAACoAAAArAAAALAAAAC0A AAAuAAAALwAAADAAAAAxAAAAMgAAADMAAAA0AAAANQAAADYAAAA3AAAAOAAAADkAAAA6AAAAOwAA ADwAAAD+////PgAAAD8AAABAAAAAQQAAAEIAAABDAAAARAAAAP7///9GAAAARwAAAEgAAABJAAAA SgAAAEsAAABMAAAATQAAAE4AAABPAAAAUAAAAFEAAABSAAAAUwAAAFQAAABVAAAAVgAAAFcAAABY AAAAWQAAAFoAAABbAAAAXAAAAF0AAABeAAAAXwAAAGAAAABhAAAAYgAAAGMAAABkAAAAZQAAAGYA AABnAAAA/v///2kAAABqAAAAawAAAGwAAABtAAAAbgAAAG8AAAD+////cQAAAHIAAABzAAAAdAAA AHUAAAB2AAAAdwAAAP7////9////egAAAP7////+/////v///////////////////1IAbwBvAHQA IABFAG4AdAByAHkAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAW AAUB//////////8DAAAABgkCAAAAAADAAAAAAAAARgAAAAAAAAAAAAAAANBvNk2gxskBfAAAAIAA AAAAAAAARABhAHQAYQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAoAAgH///////////////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAA9AAAAABAAAAAAAAAxAFQAYQBiAGwAZQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADgACAQEAAAAGAAAA/////wAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAEUAAACxRAAAAAAAAFcAbwByAGQARABvAGMAdQBtAGUAbgB0 AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAaAAIBAgAAAAUAAAD///// AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADR4AAAAAAAABQBTAHUAbQBt AGEAcgB5AEkAbgBmAG8AcgBtAGEAdABpAG8AbgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACgA AgH///////////////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABoAAAAABAA AAAAAAAFAEQAbwBjAHUAbQBlAG4AdABTAHUAbQBtAGEAcgB5AEkAbgBmAG8AcgBtAGEAdABpAG8A bgAAAAAAAAAAAAAAOAACAQQAAAD//////////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAHAAAAAAEAAAAAAAAAEAQwBvAG0AcABPAGIAagAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAASAAIA////////////////AAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD///////////////8A AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABAAAA/v////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// /////////////////////////////////////////////////////////////wEA/v8DCgAA//// /wYJAgAAAAAAwAAAAAAAAEYfAAAATWljcm9zb2Z0IE9mZmljZSBXb3JkIERvY3VtZW50AAoAAABN U1dvcmREb2MAEAAAAFdvcmQuRG9jdW1lbnQuOAD0ObJxAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA ------=_NextPart_000_004D_01C9C6B9.784F1D70-- From richard.kelsey@ember.com Mon Apr 27 08:03: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 B06F63A6EFA for ; Mon, 27 Apr 2009 08:03:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.669 X-Spam-Level: X-Spam-Status: No, score=-1.669 tagged_above=-999 required=5 tests=[AWL=-0.929, BAYES_20=-0.74] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zk-CJ9IeYujY for ; Mon, 27 Apr 2009 08:03:08 -0700 (PDT) Received: from EMPIRE.hq.ember.com (mail.ember.com [74.10.175.227]) by core3.amsl.com (Postfix) with ESMTP id C20073A67DB for ; Mon, 27 Apr 2009 08:03:08 -0700 (PDT) Received: from kelsey-ws.hq.ember.com ([192.168.81.55]) by EMPIRE.hq.ember.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 27 Apr 2009 11:05:24 -0400 Received: from kelsey-ws.hq.ember.com (localhost.localdomain [127.0.0.1]) by kelsey-ws.hq.ember.com (8.13.4/8.13.4) with ESMTP id n3RF4Sas004910; Mon, 27 Apr 2009 11:04:28 -0400 Received: (from kelsey@localhost) by kelsey-ws.hq.ember.com (8.13.4/8.12.8/Submit) id n3RF4RJt004817; Mon, 27 Apr 2009 11:04:27 -0400 Date: Mon, 27 Apr 2009 11:04:27 -0400 Message-Id: <200904271504.n3RF4RJt004817@kelsey-ws.hq.ember.com> To: rossi@dei.unipd.it In-reply-to: <34b478810904241431h20435ecq81bd2f16d8973fc1@mail.gmail.com> (message from Michele Rossi on Fri, 24 Apr 2009 23:31:09 +0200) From: Richard Kelsey References: <200904241552.n3OFq6X3004362@kelsey-ws.hq.ember.com> <1068684476.126101240591804987.JavaMail.root@mail02.pantherlink.uwm.edu> <34b478810904241431h20435ecq81bd2f16d8973fc1@mail.gmail.com> X-OriginalArrivalTime: 27 Apr 2009 15:05:24.0344 (UTC) FILETIME=[97674F80:01C9C749] Cc: roll@ietf.org Subject: Re: [Roll] Energy metric for link (was: Polling WG for adoption of Metrics Draft) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 27 Apr 2009 15:03:09 -0000 Date: Fri, 24 Apr 2009 23:31:09 +0200 From: Michele Rossi In some cases, we may want to extend the lifetime of some specific nodes due to their location in the network or to their specific function, and residual energies can be used as a metric to implement this. This requires a mechanism to determine which nodes should use their residual energy to originate messages and which nodes should use their residual energy to forward messages. Thus, I agree with Mukul in that a node could locally decide whether to participate or not in the routing based on local metrics, such as its residual battery level (among others). As an example, nodes in a sensor network that are sensing an important event and that are also running out of battery could decide to use their energy to send their measurements to a gathering point rather than relaying messages from other nodes. How does a node determine whether its measurements are more or less important than some other device's measurements? Not participating in routing makes sense only if the device's local measurements have a higher priority than other devices'. This doesn't seem like a decision that can be made locally. If every node decides to reserve the last X% of its battery for its own measurements, then a network is likely to shut down as soon as a significant number of nodes is down to X% battery. This make sense only if X is zero. Why shut down when there is still energy available? Finally, I agree with Richard in that using a link metric would lead to more stable routing. That wasn't the point I was trying to make. My point was that it makes more sense to treat a battery powered device as being bandwith limited, with the limit determined by its initial energy and its design lifetime, than as a device that has one behavior for the first part of its lifetime and then switches to some other behavior when its battery gets low. How this is reflected in a metric is a separate issue. For example, a battery-powered node could dynamically adjust its cost(s) to be as low as possible within its bandwidth limit. If it forwards too many messages it pushes the cost up; too few and it reduces its cost, down to some floor determined by its non-energy-related costs. This would maximize the utility of the network while ensuring that the device lasts as long as it is meant to. -Richard Kelsey From prvs=3610cae43=mukul@uwm.edu Mon Apr 27 11:48:15 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5CB7128C193 for ; Mon, 27 Apr 2009 11:48:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.447 X-Spam-Level: X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[AWL=0.152, 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 uZrqYhTPFLAA for ; Mon, 27 Apr 2009 11:48:14 -0700 (PDT) Received: from ip2mta.uwm.edu (ip2mta.uwm.edu [129.89.7.20]) by core3.amsl.com (Postfix) with ESMTP id 6263828C186 for ; Mon, 27 Apr 2009 11:48:14 -0700 (PDT) Received: from mta02.pantherlink.uwm.edu ([129.89.7.82]) by ip2mta.uwm.edu with ESMTP; 27 Apr 2009 13:49:34 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by mta02.pantherlink.uwm.edu (Postfix) with ESMTP id C27922C10F99; Mon, 27 Apr 2009 13:49:34 -0500 (CDT) X-Virus-Scanned: amavisd-new at mta02.pantherlink.uwm.edu Received: from mta02.pantherlink.uwm.edu ([127.0.0.1]) by localhost (mta02.pantherlink.uwm.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1ICZdnXjJjN4; Mon, 27 Apr 2009 13:49:34 -0500 (CDT) Received: from mail02.pantherlink.uwm.edu (mail02.pantherlink.uwm.edu [129.89.7.86]) by mta02.pantherlink.uwm.edu (Postfix) with ESMTP id 930192C10C78; Mon, 27 Apr 2009 13:49:34 -0500 (CDT) Date: Mon, 27 Apr 2009 13:49:34 -0500 (CDT) From: Mukul Goyal To: Richard Kelsey Message-ID: <1577497720.863631240858174495.JavaMail.root@mail02.pantherlink.uwm.edu> In-Reply-To: <1081395601.852021240857475473.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.15_GA_2851.RHEL4_64 (ZimbraWebClient - IE7 (Win)/5.0.15_GA_2851.RHEL4_64) X-Authenticated-User: mukul@uwm.edu Cc: rossi@dei.unipd.it, roll@ietf.org Subject: Re: [Roll] Energy metric for link (was: Polling WG for adoption of Metrics Draft) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 27 Apr 2009 18:48:46 -0000 I am not sure if the routing protocol MUST aim for maximization of the network life time. There will be a variety of the nodes in the network - some nodes dedicated to forwarding packets of others, some nodes just acting as end points and some nodes doing both operations. I think, rather than aiming for optimizing the life time/performance, the routing protocol should allow different "local" policies to be enforced. The routing protocol should not decide whether a node must participate in routing. The routing protocol should find the best routes among the nodes willing to forward packets. A node should be able to decide whether to forward packets or not based on the local policy factors such as battery levels. Thanks Mukul ----- Original Message ----- From: "Richard Kelsey" To: rossi@dei.unipd.it Cc: mukul@uwm.edu, roll@ietf.org Sent: Monday, April 27, 2009 10:04:27 AM GMT -06:00 US/Canada Central Subject: Re: [Roll] Energy metric for link (was: Polling WG for adoption of Metrics Draft) Date: Fri, 24 Apr 2009 23:31:09 +0200 From: Michele Rossi In some cases, we may want to extend the lifetime of some specific nodes due to their location in the network or to their specific function, and residual energies can be used as a metric to implement this. This requires a mechanism to determine which nodes should use their residual energy to originate messages and which nodes should use their residual energy to forward messages. Thus, I agree with Mukul in that a node could locally decide whether to participate or not in the routing based on local metrics, such as its residual battery level (among others). As an example, nodes in a sensor network that are sensing an important event and that are also running out of battery could decide to use their energy to send their measurements to a gathering point rather than relaying messages from other nodes. How does a node determine whether its measurements are more or less important than some other device's measurements? Not participating in routing makes sense only if the device's local measurements have a higher priority than other devices'. This doesn't seem like a decision that can be made locally. If every node decides to reserve the last X% of its battery for its own measurements, then a network is likely to shut down as soon as a significant number of nodes is down to X% battery. This make sense only if X is zero. Why shut down when there is still energy available? Finally, I agree with Richard in that using a link metric would lead to more stable routing. That wasn't the point I was trying to make. My point was that it makes more sense to treat a battery powered device as being bandwith limited, with the limit determined by its initial energy and its design lifetime, than as a device that has one behavior for the first part of its lifetime and then switches to some other behavior when its battery gets low. How this is reflected in a metric is a separate issue. For example, a battery-powered node could dynamically adjust its cost(s) to be as low as possible within its bandwidth limit. If it forwards too many messages it pushes the cost up; too few and it reduces its cost, down to some floor determined by its non-energy-related costs. This would maximize the utility of the network while ensuring that the device lasts as long as it is meant to. -Richard Kelsey From robert.assimiti@nivis.com Mon Apr 27 14:02:01 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 8D5753A680D for ; Mon, 27 Apr 2009 14:02:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.577 X-Spam-Level: X-Spam-Status: No, score=-1.577 tagged_above=-999 required=5 tests=[AWL=1.022, 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 qyotqSqGtCOL for ; Mon, 27 Apr 2009 14:02:00 -0700 (PDT) Received: from mail.nivis.com (mail.nivis.com [65.205.163.229]) by core3.amsl.com (Postfix) with SMTP id E226C3A6A79 for ; Mon, 27 Apr 2009 14:01:59 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 27 Apr 2009 17:03:16 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Energy metric for link (was: Polling WG for adoption of thread-index: AcnHastPZGSp8lbXSoe7yxOoh/U4HQADY/8g References: From: "Robert Assimiti" To: Subject: Re: [Roll] Energy metric for link (was: Polling WG for adoption of X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Apr 2009 21:02:01 -0000 Hello, It is my understanding that the final goal of the ROLL group is to have a= n interoperable routing methodology for LLNs. The key word here is not just interoperability, but fair interoperability= within a multipath battery operated LLN.=20 Anyone that has worked with battery powered wireless nodes knows that pro= longed battery life (building a wireless router that will actually delive= r the advertised battery life) is quite a difficult thing in a multipath = wireless environment. There must be (IMHO) a system of checks and balances that is put into pla= ce (hooks in each device) that ensure that routers behave fairly and are = good neighbors and routers. Otherwise, a vendor could always restrict (or minimize) routing of other = router's packets and save all battery for its internally generated packet= s. Let's break down the operation of a wireless LLN node (don't know enough = about PLC technology, therefore I will not include it in the discussion).= The battery depleting operations that a wireless router participates in a= re: 1. Routing/forwarding of PDU's for other nodes a. Running its receiver periodically in order to listing to incoming PDU= 's that need routing b. Sending the PDUs received from other nodes along the appropriate rout= e 2. Sending PDUs internally generated by the battery 3. Advertisements that allows other nodes to join the network or beaconi= ng for synchronization etc Therefore, all these operations need to be captured in a metric, a metric= that can be shared with other nodes, or possibly a central management en= tity. When joining the network, each node should report its energy capabilities= such as: 1. I can run my receiver for X seconds/hour in order to receive incoming = PDU's that need routing.=20 2. I can spend Y seconds/ hour TXing PDUs on behalf of other nodes (routi= ng) and my internally generated PDUs 3. I can spend Z seconds/ hour advertising for other devices that want to= join the network (beacons for synch etc) Once this parameters are available as READ ONLY MIB attributes, other nod= es (or a central management entity in a deterministic network) can reques= t this MIBs and base their routing decision on them. What do YOU think? =20 "The nice thing about standards is that there are so many to choose from.= " - Andrew S. Tanenbaum=20 Robert Assimiti Executive Staff=A0Engineer Office: [678]-202-6859 Mobile: [404]-578-0205 robert.assimiti@nivis.com -----Original Message----- From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of r= oll-request@ietf.org Sent: Monday, April 27, 2009 3:00 PM To: roll@ietf.org Subject: Roll Digest, Vol 15, Issue 32 If you have received this digest without all the individual message attachments you will need to update your digest options in your list subscription. To do so, go to=20 https://www.ietf.org/mailman/listinfo/roll Click the 'Unsubscribe or edit options' button, log in, and set "Get MIME or Plain Text Digests?" to MIME. You can set this option globally for all the list digests you receive at this point. Send Roll mailing list submissions to roll@ietf.org To subscribe or unsubscribe via the World Wide Web, visit https://www.ietf.org/mailman/listinfo/roll or, via email, send a message with subject or body 'help' to roll-request@ietf.org You can reach the person managing the list at roll-owner@ietf.org When replying, please edit your Subject line so it is more specific than "Re: Contents of Roll digest..." Today's Topics: 1. Re: Energy metric for link (was: Polling WG for adoption of Metrics Draft) (Richard Kelsey) 2. Re: Energy metric for link (was: Polling WG for adoption of Metrics Draft) (Mukul Goyal) ---------------------------------------------------------------------- Message: 1 Date: Mon, 27 Apr 2009 11:04:27 -0400 From: Richard Kelsey Subject: Re: [Roll] Energy metric for link (was: Polling WG for adoption of Metrics Draft) To: rossi@dei.unipd.it Cc: roll@ietf.org Message-ID: <200904271504.n3RF4RJt004817@kelsey-ws.hq.ember.com> Date: Fri, 24 Apr 2009 23:31:09 +0200 From: Michele Rossi In some cases, we may want to extend the lifetime of some specific nodes due to their location in the network or to their specific function, and residual energies can be used as a metric to implement this. This requires a mechanism to determine which nodes should use their residual energy to originate messages and which nodes should use their residual energy to forward messages. Thus, I agree with Mukul in that a node could locally decide whether to participate or not in the routing based on local metrics, such as its residual battery level (among others). As an example, nodes in a sensor network that are sensing an important event and that are also running out of battery could decide to use their energy to send their measurements to a gathering point rather than relaying messages from other nodes. How does a node determine whether its measurements are more or less important than some other device's measurements? Not participating in routing makes sense only if the device's local measurements have a higher priority than other devices'. This doesn't seem like a decision that can be made locally. If every node decides to reserve the last X% of its battery for its own measurements, then a network is likely to shut down as soon as a significant number of nodes is down to X% battery. This make sense only if X is zero. Why shut down when there is still energy available? Finally, I agree with Richard in that using a link metric would lead to more stable routing. That wasn't the point I was trying to make. My point was that it makes more sense to treat a battery powered device as being bandwith limited, with the limit determined by its initial energy and its design lifetime, than as a device that has one behavior for the first part of its lifetime and then switches to some other behavior when its battery gets low. How this is reflected in a metric is a separate issue. For example, a battery-powered node could dynamically adjust its cost(s) to be as low as possible within its bandwidth limit. If it forwards too many messages it pushes the cost up; too few and it reduces its cost, down to some floor determined by its non-energy-related costs. This would maximize the utility of the network while ensuring that the device lasts as long as it is meant to. -Richard Kelsey ------------------------------ Message: 2 Date: Mon, 27 Apr 2009 13:49:34 -0500 (CDT) From: Mukul Goyal Subject: Re: [Roll] Energy metric for link (was: Polling WG for adoption of Metrics Draft) To: Richard Kelsey Cc: rossi@dei.unipd.it, roll@ietf.org Message-ID: <1577497720.863631240858174495.JavaMail.root@mail02.pantherlink.uwm.edu>= =09 Content-Type: text/plain; charset=3Dutf-8 I am not sure if the routing protocol MUST aim for maximization of the ne= twork life time. There will be a variety of the nodes in the network - so= me nodes dedicated to forwarding packets of others, some nodes just actin= g as end points and some nodes doing both operations. I think, rather tha= n aiming for optimizing the life time/performance, the routing protocol s= hould allow different "local" policies to be enforced. The routing protoc= ol should not decide whether a node must participate in routing. The rout= ing protocol should find the best routes among the nodes willing to forwa= rd packets. A node should be able to decide whether to forward packets or= not based on the local policy factors such as battery levels. Thanks Mukul =20 ----- Original Message ----- From: "Richard Kelsey" To: rossi@dei.unipd.it Cc: mukul@uwm.edu, roll@ietf.org Sent: Monday, April 27, 2009 10:04:27 AM GMT -06:00 US/Canada Central Subject: Re: [Roll] Energy metric for link (was: Polling WG for adoption = of Metrics Draft) Date: Fri, 24 Apr 2009 23:31:09 +0200 From: Michele Rossi In some cases, we may want to extend the lifetime of some specific nodes due to their location in the network or to their specific function, and residual energies can be used as a metric to implement this. This requires a mechanism to determine which nodes should use their residual energy to originate messages and which nodes should use their residual energy to forward messages. Thus, I agree with Mukul in that a node could locally decide whether to participate or not in the routing based on local metrics, such as its residual battery level (among others). As an example, nodes in a sensor network that are sensing an important event and that are also running out of battery could decide to use their energy to send their measurements to a gathering point rather than relaying messages from other nodes. How does a node determine whether its measurements are more or less important than some other device's measurements? Not participating in routing makes sense only if the device's local measurements have a higher priority than other devices'. This doesn't seem like a decision that can be made locally. If every node decides to reserve the last X% of its battery for its own measurements, then a network is likely to shut down as soon as a significant number of nodes is down to X% battery. This make sense only if X is zero. Why shut down when there is still energy available? Finally, I agree with Richard in that using a link metric would lead to more stable routing. That wasn't the point I was trying to make. My point was that it makes more sense to treat a battery powered device as being bandwith limited, with the limit determined by its initial energy and its design lifetime, than as a device that has one behavior for the first part of its lifetime and then switches to some other behavior when its battery gets low. How this is reflected in a metric is a separate issue. For example, a battery-powered node could dynamically adjust its cost(s) to be as low as possible within its bandwidth limit. If it forwards too many messages it pushes the cost up; too few and it reduces its cost, down to some floor determined by its non-energy-related costs. This would maximize the utility of the network while ensuring that the device lasts as long as it is meant to. -Richard Kelsey ------------------------------ _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll End of Roll Digest, Vol 15, Issue 32 ************************************ This e-mail (including any attachments to it) is confidential, proprietar= y, legally privileged, subject to copyright and is sent for the personal = attention of the intended recipient only. If you have received this e-mai= l in error, please reply to advise us immediately, delete it and destroy = any printed copies of it. You are notified that reading, disclosing, copy= ing, distributing or taking any action in reliance on the contents of thi= s information is strictly prohibited. No employee is authorized to conclu= de any binding agreement on behalf of NIVIS LLC with another party by e-m= ail without express written confirmation by an officer of the company. Al= though we have taken reasonable precautions to ensure no viruses are pres= ent in this e-mail, we cannot accept responsibility for any loss or damag= e arising from the viruses in this e-mail or attachments. From mischa.dohler@cttc.es Tue Apr 28 00:28:11 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D37833A6B0A for ; Tue, 28 Apr 2009 00:28:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1RGZzRbs68On for ; Tue, 28 Apr 2009 00:28:00 -0700 (PDT) Received: from scorpius.cttc.es (scorpius.cttc.es [84.88.62.197]) by core3.amsl.com (Postfix) with ESMTP id 6D5D83A7077 for ; Tue, 28 Apr 2009 00:27:59 -0700 (PDT) Received: from leo (postfix@leo.cttc.es [84.88.62.208]) by scorpius.cttc.es (8.13.8/8.13.5) with ESMTP id n3S7ScAg003855; Tue, 28 Apr 2009 09:28:38 +0200 Received: from [127.0.0.1] (63.Red-83-61-205.dynamicIP.rima-tde.net [83.61.205.63]) by leo (Postfix) with ESMTP id 61FD810C31E; Tue, 28 Apr 2009 09:28:37 +0200 (CEST) Message-ID: <49F6B023.1080602@cttc.es> Date: Tue, 28 Apr 2009 09:28:35 +0200 From: Mischa Dohler User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Mukul Goyal References: <1577497720.863631240858174495.JavaMail.root@mail02.pantherlink.uwm.edu> In-Reply-To: <1577497720.863631240858174495.JavaMail.root@mail02.pantherlink.uwm.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 090427-0, 27/04/2009), Outbound message X-Antivirus-Status: Clean X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (leo); Tue, 28 Apr 2009 09:28:38 +0200 (CEST) X-Scanned-By: MIMEDefang 2.57 on 84.88.62.197 Cc: rossi@dei.unipd.it, roll@ietf.org Subject: Re: [Roll] Energy metric for link X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Apr 2009 07:28:11 -0000 Mukul, for the reasons you outlined and a long list of other reasons, we have been very careful to use the word "optimize" instead of "maximize" in our drafts. Mischa. Mukul Goyal wrote: > I am not sure if the routing protocol MUST aim for maximization of the network life time. There will be a variety of the nodes in the network - some nodes dedicated to forwarding packets of others, some nodes just acting as end points and some nodes doing both operations. I think, rather than aiming for optimizing the life time/performance, the routing protocol should allow different "local" policies to be enforced. The routing protocol should not decide whether a node must participate in routing. The routing protocol should find the best routes among the nodes willing to forward packets. A node should be able to decide whether to forward packets or not based on the local policy factors such as battery levels. > > Thanks > Mukul > > ----- Original Message ----- > From: "Richard Kelsey" > To: rossi@dei.unipd.it > Cc: mukul@uwm.edu, roll@ietf.org > Sent: Monday, April 27, 2009 10:04:27 AM GMT -06:00 US/Canada Central > Subject: Re: [Roll] Energy metric for link (was: Polling WG for adoption of Metrics Draft) > > Date: Fri, 24 Apr 2009 23:31:09 +0200 > From: Michele Rossi > > In some cases, we may want to extend the lifetime of some specific > nodes due to their location in the network or to their specific > function, and residual energies can be used as a metric to implement > this. > > This requires a mechanism to determine which nodes should > use their residual energy to originate messages and which > nodes should use their residual energy to forward messages. > > Thus, I agree with Mukul in that a node could locally > decide whether to participate or not in the routing based > on local metrics, such as its residual battery level > (among others). As an example, nodes in a sensor network > that are sensing an important event and that are also > running out of battery could decide to use their energy > to send their measurements to a gathering point rather > than relaying messages from other nodes. > > How does a node determine whether its measurements are more > or less important than some other device's measurements? > Not participating in routing makes sense only if the > device's local measurements have a higher priority than > other devices'. This doesn't seem like a decision that can > be made locally. > > If every node decides to reserve the last X% of its battery > for its own measurements, then a network is likely to > shut down as soon as a significant number of nodes is down to > X% battery. This make sense only if X is zero. Why shut > down when there is still energy available? > > Finally, I agree with Richard in that using a link metric > would lead to more stable routing. > > That wasn't the point I was trying to make. My point was > that it makes more sense to treat a battery powered device > as being bandwith limited, with the limit determined by its > initial energy and its design lifetime, than as a device > that has one behavior for the first part of its lifetime and > then switches to some other behavior when its battery gets > low. How this is reflected in a metric is a separate issue. > > For example, a battery-powered node could dynamically adjust > its cost(s) to be as low as possible within its bandwidth > limit. If it forwards too many messages it pushes the cost > up; too few and it reduces its cost, down to some floor > determined by its non-energy-related costs. This would > maximize the utility of the network while ensuring that > the device lasts as long as it is meant to. > > -Richard Kelsey > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From pthubert@cisco.com Tue Apr 28 01:51: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 31BD528C19F for ; Tue, 28 Apr 2009 01:51:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.961 X-Spam-Level: X-Spam-Status: No, score=-9.961 tagged_above=-999 required=5 tests=[AWL=0.638, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MqWdgtVNAcYw for ; Tue, 28 Apr 2009 01:51:44 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 106AE3A6F7A for ; Tue, 28 Apr 2009 01:51:20 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,259,1238976000"; d="scan'208";a="39289799" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 28 Apr 2009 08:52:41 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n3S8qfKZ010471; Tue, 28 Apr 2009 10:52:41 +0200 Received: from xbh-ams-331.emea.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n3S8qfZK011545; Tue, 28 Apr 2009 08:52:41 GMT Received: from xmb-ams-337.cisco.com ([144.254.231.82]) by xbh-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 28 Apr 2009 10:52:41 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 28 Apr 2009 10:52:35 +0200 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC075C24AD@xmb-ams-337.emea.cisco.com> In-Reply-To: <49F6B023.1080602@cttc.es> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] Energy metric for link Thread-Index: AcnH0yTUdu0dBreLSI6sJvRXCSxRMAABnSJw References: <1577497720.863631240858174495.JavaMail.root@mail02.pantherlink.uwm.edu> <49F6B023.1080602@cttc.es> From: "Pascal Thubert (pthubert)" To: "Mischa Dohler" , "Mukul Goyal" X-OriginalArrivalTime: 28 Apr 2009 08:52:41.0334 (UTC) FILETIME=[B06C8960:01C9C7DE] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=6568; t=1240908761; x=1241772761; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pthubert@cisco.com; z=From:=20=22Pascal=20Thubert=20(pthubert)=22=20 |Subject:=20RE=3A=20[Roll]=20Energy=20metric=20for=20link |Sender:=20; bh=VpoucPwII0c6q6kSX8HMjMxkP3vDvOjFXPLNOlH50cU=; b=HRX3s+iY5CvEQrpVhEH3gtge9Gs0hzmR43LE9bPqeJltmWJO+tALSZhPT0 RQxH9Y9fib8aVXTPaNfCiiUxSgRUVoQcID26xd/vh2xXGcdIWFopavMde7Tf pea6j+Pjvz; Authentication-Results: ams-dkim-2; header.From=pthubert@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Cc: rossi@dei.unipd.it, roll@ietf.org Subject: Re: [Roll] Energy metric for link X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Apr 2009 08:51:46 -0000 Hi Mukul and Misha: I think you're making a fundamental point that there is some deployment/case specific logic that will influence the selection of the routing topologies that a node belongs to, the peers it associates with, and the next hops it selects for a given route. There will be routing time logic (participating to a topology) and forwarding time logic (distributing packets to feasible successors). =20 The routing logic might use battery levels, the scavenging capabilities, or it might not. It might use a number of other parameters such as level of security, Group identifier, available bandwidth, and anything from barometric pressure to relative speed. The forwarding logic might use filtered forwarding success history, fairness/load balancing, bicasting, interference level, xmit power, etc...). An example in the Home Automation case is for a node to decide to participate (or not) to a routing topology towards a given sink, depending on the reachability that the sink provides (default route vs. power utility network vs. home surveillance network). =20 The roll fundamentals drafts identifies this external decision engine as a plug-in to the tree formation protocol because we expect a same core routing mechanism with loop avoidance Esperanto, but multiple, case-by-case, routing and forwarding policies. In particular, it should be possible to get some basic, un-optimized and maybe degraded services out of a network of nodes that do not all implement a same common set of policies because if we fail to enable that, we'll be stuck with our initial set of policies and will block all evolution. I understand that the term 'plug-in' might be ill-chosen. More important than the name is to reach consensus on the concept, at which point we'll probably have to define an open TLV infrastructure with generic propagation rules to enable the advertisement of specific information and enable the implementation of the specific 'plug-ins' that will be required for specific policies. Pascal >-----Original Message----- >From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Mischa Dohler >Sent: mardi 28 avril 2009 09:29 >To: Mukul Goyal >Cc: rossi@dei.unipd.it; roll@ietf.org >Subject: Re: [Roll] Energy metric for link > >Mukul, for the reasons you outlined and a long list of other reasons, we >have been very careful to use the word "optimize" instead of "maximize" >in our drafts. Mischa. > > > >Mukul Goyal wrote: >> I am not sure if the routing protocol MUST aim for maximization of the network life time. There will be a >variety of the nodes in the network - some nodes dedicated to forwarding packets of others, some nodes just >acting as end points and some nodes doing both operations. I think, rather than aiming for optimizing the life >time/performance, the routing protocol should allow different "local" policies to be enforced. The routing >protocol should not decide whether a node must participate in routing. The routing protocol should find the >best routes among the nodes willing to forward packets. A node should be able to decide whether to forward >packets or not based on the local policy factors such as battery levels. >> >> Thanks >> Mukul >> >> ----- Original Message ----- >> From: "Richard Kelsey" >> To: rossi@dei.unipd.it >> Cc: mukul@uwm.edu, roll@ietf.org >> Sent: Monday, April 27, 2009 10:04:27 AM GMT -06:00 US/Canada Central >> Subject: Re: [Roll] Energy metric for link (was: Polling WG for adoption of Metrics Draft) >> >> Date: Fri, 24 Apr 2009 23:31:09 +0200 >> From: Michele Rossi >> >> In some cases, we may want to extend the lifetime of some specific >> nodes due to their location in the network or to their specific >> function, and residual energies can be used as a metric to implement >> this. >> >> This requires a mechanism to determine which nodes should >> use their residual energy to originate messages and which >> nodes should use their residual energy to forward messages. >> >> Thus, I agree with Mukul in that a node could locally >> decide whether to participate or not in the routing based >> on local metrics, such as its residual battery level >> (among others). As an example, nodes in a sensor network >> that are sensing an important event and that are also >> running out of battery could decide to use their energy >> to send their measurements to a gathering point rather >> than relaying messages from other nodes. >> >> How does a node determine whether its measurements are more >> or less important than some other device's measurements? >> Not participating in routing makes sense only if the >> device's local measurements have a higher priority than >> other devices'. This doesn't seem like a decision that can >> be made locally. >> >> If every node decides to reserve the last X% of its battery >> for its own measurements, then a network is likely to >> shut down as soon as a significant number of nodes is down to >> X% battery. This make sense only if X is zero. Why shut >> down when there is still energy available? >> >> Finally, I agree with Richard in that using a link metric >> would lead to more stable routing. >> >> That wasn't the point I was trying to make. My point was >> that it makes more sense to treat a battery powered device >> as being bandwith limited, with the limit determined by its >> initial energy and its design lifetime, than as a device >> that has one behavior for the first part of its lifetime and >> then switches to some other behavior when its battery gets >> low. How this is reflected in a metric is a separate issue. >> >> For example, a battery-powered node could dynamically adjust >> its cost(s) to be as low as possible within its bandwidth >> limit. If it forwards too many messages it pushes the cost >> up; too few and it reduces its cost, down to some floor >> determined by its non-energy-related costs. This would >> maximize the utility of the network while ensuring that >> the device lasts as long as it is meant to. >> >> -Richard Kelsey >> _______________________________________________ >> Roll mailing list >> Roll@ietf.org >> https://www.ietf.org/mailman/listinfo/roll >_______________________________________________ >Roll mailing list >Roll@ietf.org >https://www.ietf.org/mailman/listinfo/roll From Dali.Wei@surrey.ac.uk Tue Apr 28 02:33: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 485573A6A1A for ; Tue, 28 Apr 2009 02:33:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZpN6WdPwsHov for ; Tue, 28 Apr 2009 02:33:29 -0700 (PDT) Received: from mail114.messagelabs.com (mail114.messagelabs.com [195.245.231.163]) by core3.amsl.com (Postfix) with SMTP id D91583A65A5 for ; Tue, 28 Apr 2009 02:33:28 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: Dali.Wei@surrey.ac.uk X-Msg-Ref: server-9.tower-114.messagelabs.com!1240911237!53059559!8 X-StarScan-Version: 6.0.0; banners=-,-,- X-Originating-IP: [131.227.102.140] Received: (qmail 24811 invoked from network); 28 Apr 2009 09:34:03 -0000 Received: from ads40.surrey.ac.uk (HELO ads40.surrey.ac.uk) (131.227.102.140) by server-9.tower-114.messagelabs.com with SMTP; 28 Apr 2009 09:34:03 -0000 Received: from EVS-EC1-NODE3.surrey.ac.uk ([131.227.102.138]) by ads40.surrey.ac.uk with Microsoft SMTPSVC(6.0.3790.3959); Tue, 28 Apr 2009 10:34: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, 28 Apr 2009 10:34:03 +0100 Message-ID: In-Reply-To: <1577497720.863631240858174495.JavaMail.root@mail02.pantherlink.uwm.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] Energy metric for link (was: Polling WG for adoption of Metrics Draft) Thread-Index: AcnHaP/xcjwA2pLCQGGlK4Oknhr75AAevl0g References: <1081395601.852021240857475473.JavaMail.root@mail02.pantherlink.uwm.edu> <1577497720.863631240858174495.JavaMail.root@mail02.pantherlink.uwm.edu> From: To: X-OriginalArrivalTime: 28 Apr 2009 09:34:00.0802 (UTC) FILETIME=[764D5420:01C9C7E4] Cc: rossi@dei.unipd.it, roll@ietf.org Subject: Re: [Roll] Energy metric for link (was: Polling WG for adoption of Metrics Draft) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 28 Apr 2009 09:33:30 -0000 Hi all: It looks that the residual node energy has been extensively discussed. Well, how about the expected node lifetime itself? The residual energy rule helps equalize node lifetime yet sometimes node lifetimes are not expected the same according to their roles. For instance, one sensor node may be expected to work for years while another one may only be expected to work for months. So, besides the residual node energy parameter, how about to jointly consider another one, such as expected node lifetime? Best, Dali -----Original Message----- From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Mukul Goyal Sent: 27 April 2009 19:50 To: Richard Kelsey Cc: rossi@dei.unipd.it; roll@ietf.org Subject: Re: [Roll] Energy metric for link (was: Polling WG for adoption of Metrics Draft) I am not sure if the routing protocol MUST aim for maximization of the network life time. There will be a variety of the nodes in the network - some nodes dedicated to forwarding packets of others, some nodes just acting as end points and some nodes doing both operations. I think, rather than aiming for optimizing the life time/performance, the routing protocol should allow different "local" policies to be enforced. The routing protocol should not decide whether a node must participate in routing. The routing protocol should find the best routes among the nodes willing to forward packets. A node should be able to decide whether to forward packets or not based on the local policy factors such as battery levels. Thanks Mukul =20 ----- Original Message ----- From: "Richard Kelsey" To: rossi@dei.unipd.it Cc: mukul@uwm.edu, roll@ietf.org Sent: Monday, April 27, 2009 10:04:27 AM GMT -06:00 US/Canada Central Subject: Re: [Roll] Energy metric for link (was: Polling WG for adoption of Metrics Draft) Date: Fri, 24 Apr 2009 23:31:09 +0200 From: Michele Rossi In some cases, we may want to extend the lifetime of some specific nodes due to their location in the network or to their specific function, and residual energies can be used as a metric to implement this. This requires a mechanism to determine which nodes should use their residual energy to originate messages and which nodes should use their residual energy to forward messages. Thus, I agree with Mukul in that a node could locally decide whether to participate or not in the routing based on local metrics, such as its residual battery level (among others). As an example, nodes in a sensor network that are sensing an important event and that are also running out of battery could decide to use their energy to send their measurements to a gathering point rather than relaying messages from other nodes. How does a node determine whether its measurements are more or less important than some other device's measurements? Not participating in routing makes sense only if the device's local measurements have a higher priority than other devices'. This doesn't seem like a decision that can be made locally. If every node decides to reserve the last X% of its battery for its own measurements, then a network is likely to shut down as soon as a significant number of nodes is down to X% battery. This make sense only if X is zero. Why shut down when there is still energy available? Finally, I agree with Richard in that using a link metric would lead to more stable routing. That wasn't the point I was trying to make. My point was that it makes more sense to treat a battery powered device as being bandwith limited, with the limit determined by its initial energy and its design lifetime, than as a device that has one behavior for the first part of its lifetime and then switches to some other behavior when its battery gets low. How this is reflected in a metric is a separate issue. For example, a battery-powered node could dynamically adjust its cost(s) to be as low as possible within its bandwidth limit. If it forwards too many messages it pushes the cost up; too few and it reduces its cost, down to some floor determined by its non-energy-related costs. This would maximize the utility of the network while ensuring that the device lasts as long as it is meant to. -Richard Kelsey _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From jvasseur@cisco.com Tue Apr 28 03:49: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 D7AB228C0DC for ; Tue, 28 Apr 2009 03:49:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.224 X-Spam-Level: X-Spam-Status: No, score=-10.224 tagged_above=-999 required=5 tests=[AWL=0.330, BAYES_00=-2.599, DATE_IN_PAST_03_06=0.044, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id px1EG5B97w+s for ; Tue, 28 Apr 2009 03:49:48 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 50A533A6C99 for ; Tue, 28 Apr 2009 03:49:47 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,259,1238976000"; d="scan'208,217";a="39300225" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 28 Apr 2009 10:51:07 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n3SAp7sp016907; Tue, 28 Apr 2009 12:51:07 +0200 Received: from xbh-ams-331.emea.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n3SAp7nV002159; Tue, 28 Apr 2009 10:51:07 GMT Received: from xfe-ams-332.cisco.com ([144.254.231.73]) by xbh-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 28 Apr 2009 12:51:07 +0200 Received: from dhcp-144-254-57-175.cisco.com ([144.254.57.175]) by xfe-ams-332.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 28 Apr 2009 12:51:07 +0200 Message-Id: From: JP Vasseur To: Theodore Zahariadis In-Reply-To: Content-Type: multipart/alternative; boundary=Apple-Mail-58-601746176 Mime-Version: 1.0 (Apple Message framework v930.3) X-Priority: 3 Date: Tue, 28 Apr 2009 08:59:11 +0200 References: X-Mailer: Apple Mail (2.930.3) X-OriginalArrivalTime: 28 Apr 2009 10:51:07.0312 (UTC) FILETIME=[3BEABB00:01C9C7EF] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=8582; t=1240915867; x=1241779867; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:=20JP=20Vasseur=20 |Subject:=20Re=3A=20[Roll]=20Trust=20Management=20&=20draft -tsao-roll-security-framework-00 |Sender:=20; bh=IGalta0ChAb4u2Qo4P04szvzRy9IeX7VeRRZ9IJZnkE=; b=cAuQ/lTUD7K+z7OEFEar8aVo96zi+6eGe5mz7bSdgn/Wn4z9m/aUhKYnGD pQT5LIQpyQetXMbo/BUrfh/UYWZzInQyyh4kBzE9vg2ez0yLluqPUSrU+k/Q JErquPGsJi; Authentication-Results: ams-dkim-1; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Cc: roll@ietf.org Subject: Re: [Roll] Trust Management & draft-tsao-roll-security-framework-00 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Apr 2009 10:49:50 -0000 --Apple-Mail-58-601746176 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Hi Theodore, Could you please send your comments in text form to the list ? Thanks. JP. On Apr 26, 2009, at 8:53 PM, Theodore Zahariadis wrote: > I am sending now only the revisions... > I hope this time it goes through. > > Sorry for the inconsistency > Theodore > > ----- Original Message ----- > From: Theodore Zahariadis > To: culler > Cc: roll@ietf.org ; Mischa Dohler > Sent: Sunday, April 26, 2009 9:32 PM > Subject: Re: Roll post from zahariad@teihal.gr requires approval > > I am trying again with ZIP, > as the comments are with revisions. > > BR, > Theodore > > > ----- Original Message ----- > From: culler > To: zahariad@teihal.gr > Sent: Friday, April 24, 2009 8:55 PM > Subject: Fwd: Roll post from zahariad@teihal.gr requires approval > > The tools barf on the word document. Perhaps you could paste the > text into a mail message. > > > > Begin forwarded message: > >> zahariad@teihal.gr> >> > > framework-00_TBZ1.doc>_______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll --Apple-Mail-58-601746176 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Hi = Theodore,

Could you please send your comments in text = form to the list = ?

Thanks.

JP.
=
On Apr 26, 2009, at 8:53 PM, Theodore Zahariadis = wrote:

I am sending now only the revisions...
I hope this time it goes = through.
 
Sorry = for the inconsistency
Theodore
 
----- Original Message = -----
To: culler
 Sunday, = April 26, 2009 9:32 PM
Subject: Re: Roll post from zahariad@teihal.gr requires = approval

I am trying again with ZIP,
as the comments are with = revisions.
 
BR,
Theodore
 
 
----- = Original Message -----
 Friday, = April 24, 2009 8:55 PM
Subject: Fwd: Roll post from zahariad@teihal.gr requires = approval

The tools barf on the word document. =  Perhaps you could paste the text into a mail = message.



Begin forwarded message:


<draft-tsao-roll-security-framework-00_TBZ1.doc>_______________________________________________
Roll mailing = list
Roll@ietf.org
https://www.ietf.org/m= ailman/listinfo/roll

= --Apple-Mail-58-601746176-- From jvasseur@cisco.com Tue Apr 28 03:49: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 0470D3A6C99 for ; Tue, 28 Apr 2009 03:49:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.228 X-Spam-Level: X-Spam-Status: No, score=-10.228 tagged_above=-999 required=5 tests=[AWL=0.327, BAYES_00=-2.599, DATE_IN_PAST_03_06=0.044, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yI5kXS5kcuqg for ; Tue, 28 Apr 2009 03:49:49 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 3F3903A6CB1 for ; Tue, 28 Apr 2009 03:49:49 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,259,1238976000"; d="scan'208";a="39300230" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 28 Apr 2009 10:51:10 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n3SApA7H016925; Tue, 28 Apr 2009 12:51:10 +0200 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n3SApAbj002174; Tue, 28 Apr 2009 10:51:10 GMT Received: from xfe-ams-332.cisco.com ([144.254.231.73]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 28 Apr 2009 12:51:10 +0200 Received: from dhcp-144-254-57-175.cisco.com ([144.254.57.175]) by xfe-ams-332.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 28 Apr 2009 12:51:10 +0200 Message-Id: <8D340638-DCFB-4E71-9AB3-9A726AEC9D3E@cisco.com> From: JP Vasseur To: Mischa Dohler In-Reply-To: <49F16550.5060902@cttc.es> Content-Type: text/plain; charset=WINDOWS-1252; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v930.3) Date: Tue, 28 Apr 2009 09:08:34 +0200 References: <731FE93954BB4192BC6AD25893E2A908@sVAIO> <49F16550.5060902@cttc.es> X-Mailer: Apple Mail (2.930.3) X-OriginalArrivalTime: 28 Apr 2009 10:51:10.0202 (UTC) FILETIME=[3DA3B5A0:01C9C7EF] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=6680; t=1240915870; x=1241779870; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:=20JP=20Vasseur=20 |Subject:=20Re=3A=20[Roll]=20Trust=20Management=20&=20draft -tsao-roll-security-framework-00 |Sender:=20; bh=lsHq4xckuYJ8M5rEPqKddjQduaMq1V0mDpncKP2kfJ4=; b=Y+wtZa212uQ6qed/3Qd3war29Ewx72UltOYT/HAHFdQA3QMDpb0oJa3zKa n+OOFLYUbYSJdYvVAfbzK6XUnM91abwhzOC4j7+C1Hg7wP6J3+JbLWG/hi5q A0QXxUDIpO; Authentication-Results: ams-dkim-1; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Cc: Panagiotis Trakadas , roll@ietf.org, Sotiris Maniatis , Manuel.CARVALHOSA@ec.europa.eu, Theodore Zahariadis Subject: Re: [Roll] Trust Management & draft-tsao-roll-security-framework-00 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Apr 2009 10:49:51 -0000 Hi Mischa, On Apr 24, 2009, at 9:08 AM, Mischa Dohler wrote: > Thanks, Theodore, for your comments. To facilitate a practical way =20 > forward, I propose the following: > > 1) You and your team propose additions/deletions/amendments directly =20= > in draft-tsao-roll-security-framework-00 to speed up publication of =20= > -01. > Theodore: your call to send your comments directly to the authors in =20 whichever form you prefer (this is an individual submission at this =20 time), or to the list (in text form please) if it relates to a WG =20 document. > 2) You and your team propose some viable trust management scheme =20 > (and ideally a complete security suite) which is implementable into =20= > a ROLL protocol, i.e. for the time being HYDRO. You may need to =20 > synchronize with the design team and any other partners working on =20 > security for ROLL. > Please send your comments to the DT. I would suggest you to wait a few =20= more weeks, once there will be a first draft out. Thanks. JP. > Thanks and kind regards, > Mischa. > > > > > > Theodore Zahariadis wrote: >> Dear all, >> Thank you for allowing me any my team in the ROLL email list and =20 >> sharing our thoughts with you. >> First of all let me introduce myself. My name is Theodore =20 >> Zahariadis and I am the Technical Manager of the project AWISSENET. >> AWISSENET started on 1/1/2008 and is partially funded by EC under =20 >> FP7. It includes key industrial partners e.g. Hellenic Aerospace =20 >> Industry, Alcatel-Lucent and Thales Communications. Among its main =20= >> objectives is to design, simulate and implement a secure routing =20 >> scheme for Wireless Sensor Networks. So far, we have designed a =20 >> trust management scheme, which includes both direct and indirect =20 >> trust, weighting factors=92 values, which are auto-adjusted according = =20 >> to the attacks, and node=92s energy information. Then, we modified =20= >> the GPSR protocol in order to include both trust and energy-=20 >> efficient metrics and simulated the result in J-Sim. The =20 >> simulations show that the scheme can provide energy-aware routing =20 >> paths that bypass malicious nodes of many kinds. =46rom our =20 >> experience, up to now, sensor nodes resources are adequate for =20 >> implementing at least some of the trust metrics; thus currently, we =20= >> are implementing the scheme in TinyOS v2.1 on IRIS and MicaZ motes. =20= >> More info may be found at www.awissenet.eu . >> In this context, we think that trust for LLN could be in =20 >> conformance with the application-specific documents in ROLL. In =20 >> more details: >> Trust models for sensor networks [1-3] allow for detecting a list =20 >> of attacks including black-hole, selective forwarding, integrity/=20 >> modification attacks. The nodes may also exchange opinions as =20 >> regards the trustworthiness of their neighbors [4-5]. Trust & =20 >> reputation information can be accelerated for new-comers, i.e. is =20 >> useful in case of mobile nodes and/or newly initiated nodes. >> The draft-tsao-roll-security-framework-00 provides an excellent =20 >> description of a security framework for sensor networks. In section =20= >> 5.3.3, the selective forwarding attack is described and two =20 >> countermeasures are sought. We believe, that a third way to defend =20= >> against this attack may be to realize a trust model i.e. in case =20 >> messages are not encrypted (and this may be the case in the =20 >> majority of sensor networks), each node monitors/overhears the =20 >> behavior of its neighbors in order to check whether they sincerely =20= >> execute the routing protocol and behave as expected. If for =20 >> example, node A selects node B for forwarding packet P1, after =20 >> transmitting the packet, node A overhears the wireless medium in =20 >> order to check whether node B actually forwarded the packet P1 =20 >> correctly. The end result is that each node calculates the =20 >> trustworthiness of its neighbors and then takes into account this =20 >> information to avoid choosing malicious nodes during routing =20 >> decisions, either for key distribution [1], for data aggregation or =20= >> for cluster head election. >> Also, in the definition of selective forwarding, the case where a =20= >> malicious node behaves differently towards different neighbors =20 >> could also be covered. i.e. maybe by replacing the sentence =93An =20= >> insider malicious node basically blends neatly in with the network =20= >> but then may decide to forward and/or manipulate certain packets.=94 =20= >> with =93An insider malicious node basically blends neatly in with the = =20 >> network, but then may decide to forward and/or manipulate certain =20 >> packets from all or part of its neighbors.=94 This behavior is called = =20 >> conflicting behavior in [6]. >> [1] Nathan Lewis, Noria Foukia, =93Using Trust for Key =20 >> Distribution and Route Selection in Wireless Sensor Networks=94 IEEE =20= >> Globecom 2007, 26-30 Nov. 2007 >> [2] A.A. Pirzada and C. McDonald, =93Trust Establishment In Pure =20= >> Ad-hoc Networks=94, Wireless Personal Communications Vol. 37, 2006, =20= >> pp: 139=96163 >> [3] Sapon Tanachaiwiwat, Pinalkumar Dave, Rohan Bhindwale, Ahmed =20= >> Helmy =93Location-centric Isolation of Misbehavior and Trust Routing =20= >> in Energy-constrained Sensor Networks=94 IEEE International =20 >> Conference on Performance, Computing, and Communications, 2004 >> [4] G. Theodorakopoulos and J. S. Baras, "On Trust Models and =20 >> Trust Evaluation Metrics for Ad-Hoc Networks," IEEE Journal on =20 >> Selected Areas in Communications (JSAC), Feb. 2006. >> [5] S. Ganeriwal and M. B. Srivastava. Reputation-Based =20 >> Framework for High Integrity Sensor Networks. In 2nd ACM Workshop =20 >> on Security of Ad Hoc and Sensor Networks., pages 66=9677, =20 >> Washington, DC, USA, 2004 >> [6] Yan (Lindsay) Sun, Zhu Han, K. J. Ray Liu, =93Defense of Trust =20= >> Management Vulnerabilities in Distributed Networks=94, IEEE =20 >> Communications Magazine, Vol. 25, No.2, February 2008, pp. 112-119. >> Looking forward to hearing from you, >> Theodore >> ------------------------------------------------------ >> Dr. Theodore Zahariadis >> Ass. Professor, TEI of Chalkida >> Email: zahariad@teihal.gr > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From alexandru.petrescu@gmail.com Tue Apr 28 04:58: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 A781D3A70A5 for ; Tue, 28 Apr 2009 04:58:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.164 X-Spam-Level: X-Spam-Status: No, score=-2.164 tagged_above=-999 required=5 tests=[AWL=0.085, 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 Ss6Jh7O0Xdks for ; Tue, 28 Apr 2009 04:58:03 -0700 (PDT) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.166.172.107]) by core3.amsl.com (Postfix) with ESMTP id AFA303A6C12 for ; Tue, 28 Apr 2009 04:58:02 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.0) with ESMTP id n3SBxJq3003893 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 28 Apr 2009 13:59:19 +0200 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (8.14.2/8.14.2) with ESMTP id n3SBxIJJ017407; Tue, 28 Apr 2009 13:59:18 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.133.173]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id n3SBxIkL008483; Tue, 28 Apr 2009 13:59:18 +0200 Message-ID: <49F6EF96.3070407@gmail.com> Date: Tue, 28 Apr 2009 13:59:18 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Mukul Goyal References: <1577497720.863631240858174495.JavaMail.root@mail02.pantherlink.uwm.edu> In-Reply-To: <1577497720.863631240858174495.JavaMail.root@mail02.pantherlink.uwm.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: rossi@dei.unipd.it, roll@ietf.org Subject: Re: [Roll] Energy metric for link X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Apr 2009 11:58:03 -0000 Mukul Goyal a écrit : > I am not sure if the routing protocol MUST aim for maximization of > the network life time. I think the routing protocol could maximize for the network life time, or for path life time, or for other relevant criterion. I think it's worth conceiving the metrics now and make use of them in various ways later. > There will be a variety of the nodes in the network - some nodes > dedicated to forwarding packets of others, some nodes just acting as > end points and some nodes doing both operations. I think, rather than > aiming for optimizing the life time/performance, the routing protocol > should allow different "local" policies to be enforced. The routing > protocol should not decide whether a node must participate in > routing. The routing protocol should find the best routes among the > nodes willing to forward packets. A node should be able to decide > whether to forward packets or not based on the local policy factors > such as battery levels. I agree mainly with the policy aspect. I just think today although there are ideas about what a ROLL routing protocol may be, there is really no detail concept of an energy-related metric, or how that ROLL protocol may make use of it. Alex From alexandru.petrescu@gmail.com Tue Apr 28 05:09: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 5E44F3A684E for ; Tue, 28 Apr 2009 05:09:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.165 X-Spam-Level: X-Spam-Status: No, score=-2.165 tagged_above=-999 required=5 tests=[AWL=0.084, 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 v-ySBso2BrmH for ; Tue, 28 Apr 2009 05:09:28 -0700 (PDT) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.166.172.106]) by core3.amsl.com (Postfix) with ESMTP id 5D4A13A67E4 for ; Tue, 28 Apr 2009 05:09:28 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.0) with ESMTP id n3SCAllG023751 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 28 Apr 2009 14:10:48 +0200 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (8.14.2/8.14.2) with ESMTP id n3SCAlol021055; Tue, 28 Apr 2009 14:10:47 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.133.173]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id n3SCAlmF013426; Tue, 28 Apr 2009 14:10:47 +0200 Message-ID: <49F6F247.8050009@gmail.com> Date: Tue, 28 Apr 2009 14:10:47 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Robert Assimiti References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: roll@ietf.org Subject: Re: [Roll] Energy metric for link X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Apr 2009 12:09:29 -0000 Hi Robert, With respect your text below, I think the following: Robert Assimiti a écrit : [...] > When joining the network, each node should report its energy > capabilities such as: > > 1. I can run my receiver for X seconds/hour in order to receive > incoming PDU's that need routing. > > 2. I can spend Y seconds/ hour TXing PDUs on behalf of other nodes > (routing) and my internally generated PDUs > > 3. I can spend Z seconds/ hour advertising for other devices that > want to join the network (beacons for synch etc) I believe a ROLL router should send on each of its interface an RA (ICMP Router Advertisement) containing a description of the energy needed to send or receive an 1280byte-sized packet on that link: 1. Sending an MTU packet on this link requires max X watts 2. Sending an MTU packet on this link requires min Y watts 3. Receiving an MTU packet on this link requires max X watts 4. Receiving an MTU packet on this link requires min Y watts This information may be used by the receivers in many different ways: e.g. a host chooses among two default routers the one through which lower energy is needed (a default router qualifier is also in RA), e.g. two neighboring routers learn from each other's RA that link's characteristics, and many more. This same way of encoding the energy for link in a metric can be encoded in OSPF and RIP metrics (and not in RA). In this way the OSPF or RIP routing protocol could build paths depending not only on hop count but also on the energy needed to travel that path. What do people think about this energy metric for a link? > Once this parameters are available as READ ONLY MIB attributes, other > nodes (or a central management entity in a deterministic network) > can request this MIBs and base their routing decision on them. These paramters, or metrics, should certainly figure in a ROLL MIB (Management Information Base), I agree. Alex From alexandru.petrescu@gmail.com Tue Apr 28 05:11: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 B2BE33A70A5 for ; Tue, 28 Apr 2009 05:11:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.166 X-Spam-Level: X-Spam-Status: No, score=-2.166 tagged_above=-999 required=5 tests=[AWL=0.083, 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 NLipPTOoKAsl for ; Tue, 28 Apr 2009 05:11:23 -0700 (PDT) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.166.172.106]) by core3.amsl.com (Postfix) with ESMTP id B679928C1E2 for ; Tue, 28 Apr 2009 05:11:17 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.0) with ESMTP id n3SCCY46027514 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 28 Apr 2009 14:12:34 +0200 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (8.14.2/8.14.2) with ESMTP id n3SCCY6A021587; Tue, 28 Apr 2009 14:12:34 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.133.173]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id n3SCCYNP014101; Tue, 28 Apr 2009 14:12:34 +0200 Message-ID: <49F6F2B2.2040600@gmail.com> Date: Tue, 28 Apr 2009 14:12:34 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Dali.Wei@surrey.ac.uk References: <1081395601.852021240857475473.JavaMail.root@mail02.pantherlink.uwm.edu> <1577497720.863631240858174495.JavaMail.root@mail02.pantherlink.uwm.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: rossi@dei.unipd.it, roll@ietf.org Subject: Re: [Roll] Energy metric for link X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Apr 2009 12:11:24 -0000 Dali.Wei@surrey.ac.uk a écrit : > Hi all: It looks that the residual node energy has been extensively > discussed. Well, how about the expected node lifetime itself? The > residual energy rule helps equalize node lifetime yet sometimes node > lifetimes are not expected the same according to their roles. For > instance, one sensor node may be expected to work for years while > another one may only be expected to work for months. So, besides the > residual node energy parameter, how about to jointly consider another > one, such as expected node lifetime? I agree, I think representing the residual energy level of a battery absolutely needs to express how old is that battery and maybe how many recharging cycles has it been subjected to. My liion battery lasts much shorter now than a year ago. Alex > > Best, Dali > > -----Original Message----- From: roll-bounces@ietf.org > [mailto:roll-bounces@ietf.org] On Behalf Of Mukul Goyal Sent: 27 > April 2009 19:50 To: Richard Kelsey Cc: rossi@dei.unipd.it; > roll@ietf.org Subject: Re: [Roll] Energy metric for link (was: > Polling WG for adoption of Metrics Draft) > > I am not sure if the routing protocol MUST aim for maximization of > the network life time. There will be a variety of the nodes in the > network - some nodes dedicated to forwarding packets of others, some > nodes just acting as end points and some nodes doing both operations. > I think, rather than aiming for optimizing the life > time/performance, the routing protocol should allow different "local" > policies to be enforced. The routing protocol should not decide > whether a node must participate in routing. The routing protocol > should find the best routes among the nodes willing to forward > packets. A node should be able to decide whether to forward packets > or not based on the local policy factors such as battery levels. > > Thanks Mukul > > ----- Original Message ----- From: "Richard Kelsey" > To: rossi@dei.unipd.it Cc: mukul@uwm.edu, > roll@ietf.org Sent: Monday, April 27, 2009 10:04:27 AM GMT -06:00 > US/Canada Central Subject: Re: [Roll] Energy metric for link (was: > Polling WG for adoption of Metrics Draft) > > Date: Fri, 24 Apr 2009 23:31:09 +0200 From: Michele Rossi > > > In some cases, we may want to extend the lifetime of some specific > nodes due to their location in the network or to their specific > function, and residual energies can be used as a metric to implement > this. > > This requires a mechanism to determine which nodes should use their > residual energy to originate messages and which nodes should use > their residual energy to forward messages. > > Thus, I agree with Mukul in that a node could locally decide whether > to participate or not in the routing based on local metrics, such as > its residual battery level (among others). As an example, nodes in a > sensor network that are sensing an important event and that are also > running out of battery could decide to use their energy to send > their measurements to a gathering point rather than relaying messages > from other nodes. > > How does a node determine whether its measurements are more or less > important than some other device's measurements? Not participating in > routing makes sense only if the device's local measurements have a > higher priority than other devices'. This doesn't seem like a > decision that can be made locally. > > If every node decides to reserve the last X% of its battery for its > own measurements, then a network is likely to shut down as soon as a > significant number of nodes is down to X% battery. This make sense > only if X is zero. Why shut down when there is still energy > available? > > Finally, I agree with Richard in that using a link metric would lead > to more stable routing. > > That wasn't the point I was trying to make. My point was that it > makes more sense to treat a battery powered device as being bandwith > limited, with the limit determined by its initial energy and its > design lifetime, than as a device that has one behavior for the first > part of its lifetime and then switches to some other behavior when > its battery gets low. How this is reflected in a metric is a > separate issue. > > For example, a battery-powered node could dynamically adjust its > cost(s) to be as low as possible within its bandwidth limit. If it > forwards too many messages it pushes the cost up; too few and it > reduces its cost, down to some floor determined by its > non-energy-related costs. This would maximize the utility of the > network while ensuring that the device lasts as long as it is meant > to. > > -Richard Kelsey _______________________________________________ Roll > mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll > _______________________________________________ Roll mailing list > Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll > From alexandru.petrescu@gmail.com Tue Apr 28 06:27: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 1998328C248 for ; Tue, 28 Apr 2009 06:27:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.547 X-Spam-Level: X-Spam-Status: No, score=-1.547 tagged_above=-999 required=5 tests=[AWL=-0.538, BAYES_00=-2.599, HELO_EQ_FR=0.35, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PNob7IxoDDz1 for ; Tue, 28 Apr 2009 06:27:15 -0700 (PDT) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.166.172.107]) by core3.amsl.com (Postfix) with ESMTP id 1F31A28C23C for ; Tue, 28 Apr 2009 06:27:14 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.0) with ESMTP id n3SDSVVW013731 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 28 Apr 2009 15:28:31 +0200 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (8.14.2/8.14.2) with ESMTP id n3SDSUiV011194; Tue, 28 Apr 2009 15:28:31 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.133.173]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id n3SDSUKl009869; Tue, 28 Apr 2009 15:28:30 +0200 Message-ID: <49F7047E.3000604@gmail.com> Date: Tue, 28 Apr 2009 15:28:30 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Mukul Goyal References: <1477499340.1166081240923852078.JavaMail.root@mail02.pantherlink.uwm.edu> In-Reply-To: <1477499340.1166081240923852078.JavaMail.root@mail02.pantherlink.uwm.edu> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: rossi@dei.unipd.it, roll@ietf.org Subject: Re: [Roll] Energy metric for link X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Apr 2009 13:27:16 -0000 Mukul Goyal a écrit : > Alex > > There are many different aspects of energy consumption. Folks on this > list have already identified some of these aspects - battery levels, > the expectation regarding node life times, the power consumed for > transmission/reception on a link etc. I am interested in a metric reflecting the energy needed for transmission/reception on a link. Unfortunately this type of metric is only briefly alluded to by draft-mjkim-roll-routing-metrics-03: "Raw power and energy values are meaningless without knowledge of the energy cost of sending and receiving packets" I agree with it and I propose to represent energy send/rcv in Watt fractions in an RA, related to the MTU 1280bytes. However, the draft takes a negative turn and says: "Given the complexity of trying to address such a broad collection of constraints, a much simpler path is preferable in the short term. A few energy levels, for example, unlimited, scavenger supported, enough energy and low energy, may be sufficient to compute an adequate path in highly constrained scenarios will be specified in a further revision of this document." And I don't agree at all with such conclusion. I think it _is_ possible to describe an energy representation and the relatic metric, for link capabilities of sending/receiving 1280bytes. > We may decide to define metrics representing each one of these > aspects. But the list seems endless to me. Maybe we could converge defining a few (1, 2?) metrics and representation... but we should start somewhere... Alex From alexandru.petrescu@gmail.com Tue Apr 28 06:34: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 D578628C24A for ; Tue, 28 Apr 2009 06:34:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.162 X-Spam-Level: X-Spam-Status: No, score=-2.162 tagged_above=-999 required=5 tests=[AWL=0.087, 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 nR+KQxV3RRiy for ; Tue, 28 Apr 2009 06:34:34 -0700 (PDT) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.166.172.106]) by core3.amsl.com (Postfix) with ESMTP id B221C3A6CE4 for ; Tue, 28 Apr 2009 06:34:33 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.0) with ESMTP id n3SDZojI016327 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 28 Apr 2009 15:35:50 +0200 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (8.14.2/8.14.2) with ESMTP id n3SDZofj013422; Tue, 28 Apr 2009 15:35:50 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.133.173]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id n3SDZoOV012785; Tue, 28 Apr 2009 15:35:50 +0200 Message-ID: <49F70636.6000709@gmail.com> Date: Tue, 28 Apr 2009 15:35:50 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Richard Kelsey References: <200904241552.n3OFq6X3004362@kelsey-ws.hq.ember.com> <1068684476.126101240591804987.JavaMail.root@mail02.pantherlink.uwm.edu> <34b478810904241431h20435ecq81bd2f16d8973fc1@mail.gmail.com> <200904271504.n3RF4RJt004817@kelsey-ws.hq.ember.com> In-Reply-To: <200904271504.n3RF4RJt004817@kelsey-ws.hq.ember.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: rossi@dei.unipd.it, roll@ietf.org Subject: Re: [Roll] Energy metric for link X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Apr 2009 13:34:34 -0000 Richard Kelsey a écrit : > Date: Fri, 24 Apr 2009 23:31:09 +0200 > From: Michele Rossi > > In some cases, we may want to extend the lifetime of some specific > nodes due to their location in the network or to their specific > function, and residual energies can be used as a metric to implement > this. > > This requires a mechanism to determine which nodes should > use their residual energy to originate messages and which > nodes should use their residual energy to forward messages. > > Thus, I agree with Mukul in that a node could locally > decide whether to participate or not in the routing based > on local metrics, such as its residual battery level > (among others). As an example, nodes in a sensor network > that are sensing an important event and that are also > running out of battery could decide to use their energy > to send their measurements to a gathering point rather > than relaying messages from other nodes. > > How does a node determine whether its measurements are more > or less important than some other device's measurements? > Not participating in routing makes sense only if the > device's local measurements have a higher priority than > other devices'. This doesn't seem like a decision that can > be made locally. > > If every node decides to reserve the last X% of its battery > for its own measurements, then a network is likely to > shut down as soon as a significant number of nodes is down to > X% battery. This make sense only if X is zero. Why shut > down when there is still energy available? > > Finally, I agree with Richard in that using a link metric > would lead to more stable routing. > > That wasn't the point I was trying to make. My point was > that it makes more sense to treat a battery powered device > as being bandwith limited, with the limit determined by its > initial energy and its design lifetime, This - relating bandwidth uniquely to battery-level - seems a stretch to me. Supposedly, the way batteries deplete (the time it takes to send a 1280bytes at a high bandwidth) vary largely with other factors such as battery age and number of recycle duties. However, I do find it meaningful to relate the energy for transmission uniquely to the link type and to the number of bytes to be transmitted. Something like: Sending 1280bytes on this link (802.15.4-XY-enhancement-bandwidthZ) takes between 20mW and 200mW, no more no less, independent of the battery level, independendent of the memory size, independent of collisions, independent of daytime. -sending -1280bytes -802.15.4-variantX-enhancementY-bandwidthZ -min 20mW -max 200mW The values of min and max could be found by measurement. Alex than as a device > that has one behavior for the first part of its lifetime and > then switches to some other behavior when its battery gets > low. How this is reflected in a metric is a separate issue. > > For example, a battery-powered node could dynamically adjust > its cost(s) to be as low as possible within its bandwidth > limit. If it forwards too many messages it pushes the cost > up; too few and it reduces its cost, down to some floor > determined by its non-energy-related costs. This would > maximize the utility of the network while ensuring that > the device lasts as long as it is meant to. > > -Richard Kelsey > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > From prvs=3628035da=mukul@uwm.edu Tue Apr 28 06:03:08 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B0C2028C10C for ; Tue, 28 Apr 2009 06:03:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.49 X-Spam-Level: X-Spam-Status: No, score=-2.49 tagged_above=-999 required=5 tests=[AWL=0.109, 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 cwQ7Xx3te+kE for ; Tue, 28 Apr 2009 06:03:07 -0700 (PDT) Received: from ip1mta.uwm.edu (ip1mta.uwm.edu [129.89.7.18]) by core3.amsl.com (Postfix) with ESMTP id 3E72F3A709E for ; Tue, 28 Apr 2009 06:02:51 -0700 (PDT) Received: from mta02.pantherlink.uwm.edu ([129.89.7.82]) by ip1mta.uwm.edu with ESMTP; 28 Apr 2009 08:04:12 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by mta02.pantherlink.uwm.edu (Postfix) with ESMTP id 79FFE2C10FB8; Tue, 28 Apr 2009 08:04:12 -0500 (CDT) X-Virus-Scanned: amavisd-new at mta02.pantherlink.uwm.edu Received: from mta02.pantherlink.uwm.edu ([127.0.0.1]) by localhost (mta02.pantherlink.uwm.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PpckYnNOo7ZT; Tue, 28 Apr 2009 08:04:12 -0500 (CDT) Received: from mail02.pantherlink.uwm.edu (mail02.pantherlink.uwm.edu [129.89.7.86]) by mta02.pantherlink.uwm.edu (Postfix) with ESMTP id 3081D2C10F9F; Tue, 28 Apr 2009 08:04:12 -0500 (CDT) Date: Tue, 28 Apr 2009 08:04:12 -0500 (CDT) From: Mukul Goyal To: Alexandru Petrescu Message-ID: <1477499340.1166081240923852078.JavaMail.root@mail02.pantherlink.uwm.edu> In-Reply-To: <960584398.1165991240923834589.JavaMail.root@mail02.pantherlink.uwm.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Originating-IP: [129.89.7.92] X-Mailer: Zimbra 5.0.15_GA_2851.RHEL4_64 (ZimbraWebClient - [unknown] (Win)/5.0.15_GA_2851.RHEL4_64) X-Authenticated-User: mukul@uwm.edu Cc: rossi@dei.unipd.it, roll@ietf.org Subject: Re: [Roll] Energy metric for link X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Apr 2009 14:26:38 -0000 Alex There are many different aspects of energy consumption. Folks on this list = have already identified some of these aspects - battery levels, the expecta= tion regarding node life times, the power consumed for transmission/recepti= on on a link etc. We may decide to define metrics representing each one of = these aspects. But the list seems endless to me. Some routing protocols, de= signed to optimize life times, may need this information from all/some node= s in the network while other protocols may consider such details strictly l= ocal. Whether such details are considered local or not may have an impact o= n the scalability of the protocol. > I just think today although there are ideas about what a ROLL routing=20 protocol may be, there is really no detail concept of an energy-related=20 metric, or how that ROLL protocol may make use of it. I agree. Regards Mukul ----- Original Message ----- From: "Alexandru Petrescu" To: "Mukul Goyal" Cc: "Richard Kelsey" , rossi@dei.unipd.it, roll@i= etf.org Sent: Tuesday, April 28, 2009 6:59:18 AM GMT -06:00 US/Canada Central Subject: Re: [Roll] Energy metric for link Mukul Goyal a =C3=A9crit : > I am not sure if the routing protocol MUST aim for maximization of=20 > the network life time. I think the routing protocol could maximize for the network life time, or for path life time, or for other relevant criterion. I think it's worth conceiving the metrics now and make use of them in various ways later. > There will be a variety of the nodes in the network - some nodes > dedicated to forwarding packets of others, some nodes just acting as > end points and some nodes doing both operations. I think, rather than > aiming for optimizing the life time/performance, the routing protocol > should allow different "local" policies to be enforced. The routing > protocol should not decide whether a node must participate in > routing. The routing protocol should find the best routes among the > nodes willing to forward packets. A node should be able to decide > whether to forward packets or not based on the local policy factors > such as battery levels. I agree mainly with the policy aspect. I just think today although there are ideas about what a ROLL routing=20 protocol may be, there is really no detail concept of an energy-related=20 metric, or how that ROLL protocol may make use of it. Alex From richard.kelsey@ember.com Tue Apr 28 11:14: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 72C1228C2AA for ; Tue, 28 Apr 2009 11:14:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.555 X-Spam-Level: X-Spam-Status: No, score=-2.555 tagged_above=-999 required=5 tests=[AWL=0.044, 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 lmVM2z4Su1Fk for ; Tue, 28 Apr 2009 11:14:11 -0700 (PDT) Received: from EMPIRE.hq.ember.com (mail.ember.com [74.10.175.227]) by core3.amsl.com (Postfix) with ESMTP id 002FB28C28B for ; Tue, 28 Apr 2009 11:14:10 -0700 (PDT) Received: from kelsey-ws.hq.ember.com ([192.168.81.55]) by EMPIRE.hq.ember.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 28 Apr 2009 14:16:28 -0400 Received: from kelsey-ws.hq.ember.com (localhost.localdomain [127.0.0.1]) by kelsey-ws.hq.ember.com (8.13.4/8.13.4) with ESMTP id n3SIFWVV023618; Tue, 28 Apr 2009 14:15:32 -0400 Received: (from kelsey@localhost) by kelsey-ws.hq.ember.com (8.13.4/8.12.8/Submit) id n3SIFVmM023615; Tue, 28 Apr 2009 14:15:31 -0400 Date: Tue, 28 Apr 2009 14:15:31 -0400 Message-Id: <200904281815.n3SIFVmM023615@kelsey-ws.hq.ember.com> To: alexandru.petrescu@gmail.com In-reply-to: <49F70636.6000709@gmail.com> (message from Alexandru Petrescu on Tue, 28 Apr 2009 15:35:50 +0200) From: Richard Kelsey References: <200904241552.n3OFq6X3004362@kelsey-ws.hq.ember.com> <1068684476.126101240591804987.JavaMail.root@mail02.pantherlink.uwm.edu> <34b478810904241431h20435ecq81bd2f16d8973fc1@mail.gmail.com> <200904271504.n3RF4RJt004817@kelsey-ws.hq.ember.com> <49F70636.6000709@gmail.com> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 28 Apr 2009 18:16:28.0567 (UTC) FILETIME=[7306AA70:01C9C82D] Cc: rossi@dei.unipd.it, roll@ietf.org Subject: Re: [Roll] Energy metric for link X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Apr 2009 18:14:12 -0000 Date: Tue, 28 Apr 2009 15:35:50 +0200 From: Alexandru Petrescu Richard Kelsey a écrit : > > That wasn't the point I was trying to make. My point was > that it makes more sense to treat a battery powered device > as being bandwith limited, with the limit determined by its > initial energy and its design lifetime, This - relating bandwidth uniquely to battery-level - seems a stretch to me. Supposedly, the way batteries deplete (the time it takes to send a 1280bytes at a high bandwidth) vary largely with other factors such as battery age and number of recycle duties. Battery level need be only one input into the bandwidth calculation. Basically, each node would make its own determination as to the bandwidth it could support, taking into account whatever local state that it deemed relevent. That limit could then be both reported to other devices and enforced by the node itself. In making routing decisions, what matters in the end is the bandwidth and latency through each possible relay. I think it would be both simpler and more effective to have each node be responsible for determining its own bandwidth and latency constraints rather than have each node report its internal condition (link and battery parameters, for example) and have some other device translate those into bandwidth and latency constaints. -Richard Kelsey From jvasseur@cisco.com Tue Apr 28 23:18:14 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BA04A3A6859 for ; Tue, 28 Apr 2009 23:18:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.756 X-Spam-Level: X-Spam-Status: No, score=-9.756 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, DATE_IN_PAST_12_24=0.992, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t1-RBa1vjXRo for ; Tue, 28 Apr 2009 23:18:12 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 19BF73A6887 for ; Tue, 28 Apr 2009 23:18:10 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,264,1238976000"; d="scan'208,217";a="39369591" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 29 Apr 2009 06:19:28 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n3T6JS7H006897 for ; Wed, 29 Apr 2009 08:19:28 +0200 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n3T6JSOV025864 for ; Wed, 29 Apr 2009 06:19:28 GMT Received: from xfe-ams-331.emea.cisco.com ([144.254.231.72]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 29 Apr 2009 08:19:28 +0200 Received: from ams-jvasseur-8712.cisco.com ([10.55.201.131]) by xfe-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 29 Apr 2009 08:19:28 +0200 Message-Id: <6C7CF9A5-1485-40B6-9195-06E91A6C0261@cisco.com> From: JP Vasseur To: ROLL WG Content-Type: multipart/alternative; boundary=Apple-Mail-8-633001745 Mime-Version: 1.0 (Apple Message framework v930.3) Date: Tue, 28 Apr 2009 17:40:06 +0200 References: <20090422162325.GB16226@isi.edu> X-Mailer: Apple Mail (2.930.3) X-OriginalArrivalTime: 29 Apr 2009 06:19:28.0314 (UTC) FILETIME=[735EC1A0:01C9C892] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=4906; t=1240985968; x=1241849968; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:=20JP=20Vasseur=20 |Subject:=20Fwd=3A=20Cluster=20Pages=20Now=20Available |Sender:=20; bh=Dm7VBSO0uNq4X5hN2YjiE1wJ1yaTjDCfAfzYlpLZ4Po=; b=EvGA2X/qogInrvTEzWILl+PX+sdlsMP7R5MmwS3BkQpAuMyxS+Huh2vN0M FumqUxqdERZagPrGJPoJea/nC7XgVu8HVcM22GX54S7fMi0jC8N1QKIoZtBj G82YZju5QJ; Authentication-Results: ams-dkim-1; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Subject: [Roll] Fwd: Cluster Pages Now Available X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 29 Apr 2009 06:18:14 -0000 --Apple-Mail-8-633001745 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Although not yet directly applicable to ROLL you may want to bookmark this. Begin forwarded message: > > Date: Tue, 21 Apr 2009 17:28:38 -0700 > From: RFC Editor > To: rfc-interest@rfc-editor.org > Cc: RFC Editor > Subject: [rfc-i] Cluster Pages Now Available > > Greetings All, > > The RFC Editor has made pages available to show the clusters of > documents that are linked by Normative References. Please see these > pages for more information: > http://www.rfc-editor.org/all_clusters.php > http://www.rfc-editor.org/cluster_def.html > > The purpose of the new cluster pages is to make clear why specific > drafts are being held (to authors, WG chairs, ADs, and other > interested parties) and to aid in the RFC Editor's processing of > documents. As noted on http://www.rfc-editor.org/cluster_def.html: > > A cluster is a set of 2 or more drafts that are moving through the > RFC publication process together for one of the following reasons: > > * They are linked by normative references directly. > > * They are linked by normative references indirectly > (i.e., 2nd or 3rd generation). > > * There was a specific request from the IESG or authors for > simultaneous publication. > > At this time, the cluster information is available from the queue > page (http://www.rfc-editor.org/queue2.html), but not the XML version > of the queue. > > RFC Editor > _______________________________________________ > rfc-interest mailing list > rfc-interest@rfc-editor.org > http://mailman.rfc-editor.org/mailman/listinfo/rfc-interest > > ----- End forwarded message ----- --Apple-Mail-8-633001745 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Although not yet directly = applicable to ROLL you may want to bookmark this.

Begin = forwarded message:


Date: Tue, 21 Apr = 2009 17:28:38 -0700
From: RFC Editor <rfc-editor@rfc-editor.org>= ;
To: rfc-interest@rfc-editor.org
Cc: RFC Editor <rfc-editor@rfc-editor.org>= ;
Subject: [rfc-i] Cluster Pages Now Available

Greetings = All,

The RFC Editor has made pages available to show the clusters = of  
documents that are linked by Normative References. Please = see these  
pages for more information:
 http://www.rfc-editor.= org/all_clusters.php
 http://www.rfc-editor.= org/cluster_def.html

The purpose of the new cluster pages is = to make clear why specific  
drafts are being held (to authors, = WG chairs, ADs, and other  
interested parties) and to aid in = the RFC Editor's processing of  
documents. As noted on http://www.rfc-editor.= org/cluster_def.html:

A cluster is a set of 2 or more drafts = that are moving through the  
RFC publication process together = for one of the following reasons:

   * They are = linked by normative references directly.

   * = They are linked by normative references indirectly
=      (i.e., 2nd or 3rd generation).

=    * There was a specific request from the IESG or = authors for  
     simultaneous = publication.

At this time, the cluster information is available = from the queue  
page (http://www.rfc-editor.org/q= ueue2.html), but not the XML version  
of the = queue.

RFC = Editor
_______________________________________________
rfc-interest = mailing list
rfc-interest@rfc-editor.org
http:= //mailman.rfc-editor.org/mailman/listinfo/rfc-interest

----- = End forwarded message = -----

= --Apple-Mail-8-633001745-- From zahariad@teihal.gr Fri Apr 24 10:18: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 A3BDB3A6F31 for ; Fri, 24 Apr 2009 10:18:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.289 X-Spam-Level: X-Spam-Status: No, score=0.289 tagged_above=-999 required=5 tests=[AWL=-0.046, BAYES_50=0.001, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 31YMNNhNtn-T for ; Fri, 24 Apr 2009 10:18:56 -0700 (PDT) Received: from outbound-mail-303.bluehost.com (outbound-mail-303.bluehost.com [67.222.53.10]) by core3.amsl.com (Postfix) with SMTP id 9211F3A6B8F for ; Fri, 24 Apr 2009 10:18:55 -0700 (PDT) Received: (qmail 25197 invoked by uid 0); 24 Apr 2009 17:13:33 -0000 Received: from unknown (HELO box521.bluehost.com) (74.220.219.121) by outboundproxy6.bluehost.com with SMTP; 24 Apr 2009 17:13:33 -0000 Received: from ppp-94-66-1-79.home.otenet.gr ([94.66.1.79] helo=sVAIO) by box521.bluehost.com with smtp (Exim 4.69) (envelope-from ) id 1LxP4A-00086F-4p; Fri, 24 Apr 2009 11:20:14 -0600 Message-ID: <3352A285921A43028170655A8DD10725@sVAIO> From: "Theodore Zahariadis" To: "Mischa Dohler" References: <731FE93954BB4192BC6AD25893E2A908@sVAIO> <49F16550.5060902@cttc.es> <49F16F56.9000104@cttc.es> In-Reply-To: <49F16F56.9000104@cttc.es> Date: Fri, 24 Apr 2009 20:19:52 +0300 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_023F_01C9C51A.067AC320" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Windows Mail 6.0.6001.18000 x-mimeole: Produced By Microsoft MimeOLE V6.0.6001.18049 X-Identified-User: {712:box521.bluehost.com:synelixi:synelixis.com} {sentby:bopbeforesmtp 94.66.1.79 authed with synelixis.com} X-Mailman-Approved-At: Wed, 29 Apr 2009 00:29:01 -0700 Cc: roll@ietf.org Subject: Re: [Roll] Trust Management & draft-tsao-roll-security-framework-00 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Apr 2009 17:18:57 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_023F_01C9C51A.067AC320 Content-Type: text/plain; format=flowed; charset="WINDOWS-1252"; reply-type=response Content-Transfer-Encoding: 7bit Dear Mischa, all, Attached please find some comments/revisions on the draft-tsao-roll-security-framework-00 in word format. Best Regards, Theodore ------=_NextPart_000_023F_01C9C51A.067AC320 Content-Type: application/msword; name="draft-tsao-roll-security-framework-00_TBZ1.doc" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="draft-tsao-roll-security-framework-00_TBZ1.doc" 0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAADAAAARQEAAAAAAAAA EAAARwEAAAEAAAD+////AAAAAEIBAABDAQAARAEAAP////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////s pcEAcWAIBAAA8BK/AAAAAAAAMAAAAAAABgAA0PYAAA4AYmpianFQcVAAAAAAAAAAAAAAAAAAAAAA AAAJBBYANHwBABM6AQATOgEAYe0AAAAAAAAAAAAAAAAAAG4BAAAAAAAAAAAAAAAAAAD//w8AAAAA AAAAAAD//w8AAAAAAAAAAAD//w8AAAAAAAAAAAAAAAAAAAAAAKQAAAAAAPwEAAAAAAAA/AQAAPwE AAAAAAAA/AQAAAAAAAAqBQAAJgAAAGIFAAAMAAAAbgUAABQAAAAAAAAAAAAAAIIFAAAAAAAASqIA AAAAAABKogAAAAAAAEqiAAAAAAAASqIAAGwAAAC2ogAApAEAAIIFAAAAAAAA288AAMQBAABmpAAA AAAAAGakAAAAAAAAZqQAAAAAAABmpAAAAAAAAGakAAAAAAAAQaUAAAAAAABBpQAAAAAAAEGlAAAA AAAAIM8AAAIAAAAizwAAAAAAACLPAAAAAAAAIs8AAAAAAAAizwAAAAAAACLPAAAAAAAAIs8AACQA AACf0QAAaAIAAAfUAADMAAAARs8AABUAAAAAAAAAAAAAAAAAAAAAAAAA/AQAAC4AAABBpQAAEgAA AAAAAAAAAAAAAAAAAAAAAABBpQAAAAAAAEGlAAAAAAAAU6UAAAwAAABfpQAACAAAAEbPAAAAAAAA AAAAAAAAAAD8BAAAAAAAAPwEAAAAAAAAZqQAAAAAAAAAAAAAAAAAAGakAADbAAAAW88AAEQAAAD1 ywAAAAAAAPXLAAAAAAAA9csAAAAAAABnpQAA1gMAAPwEAAAAAAAAZqQAAAAAAAD8BAAAAAAAAGak AAAAAAAAIM8AAAAAAAAAAAAAAAAAAPXLAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAQaUAAAAAAAAgzwAAAAAAAAAAAAAAAAAA9csAAAAAAAD1ywAA HgAAAHDOAAAYAAAA/AQAAAAAAAD8BAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAvM4AAAAAAABmpAAAAAAAAFqkAAAMAAAAQBtWI//E yQEAAAAAAAAAAEqiAAAAAAAAPakAAFoiAACIzgAACAAAAAAAAAAAAAAAIM8AAAAAAACfzwAAPAAA ANvPAAAAAAAAkM4AACwAAADT1AAAAAAAAJfLAABeAAAA09QAABAAAAC8zgAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAC8 zgAAFAAAANPUAAAAAAAAAAAAAAAAAABQBQAAEgAAANDOAABQAAAAQaUAAAAAAABBpQAAAAAAAPXL AAAAAAAAQaUAAAAAAABBpQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQaUA AAAAAABBpQAAAAAAAEGlAAAAAAAARs8AAAAAAABGzwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAA9csAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEGlAAAA AAAAQaUAAAAAAABBpQAAAAAAANvPAAAAAAAAQaUAAAAAAABBpQAAAAAAAEGlAAAAAAAAQaUAAAAA AAAAAAAAAAAAAIIFAAAAAAAAggUAAAAAAACCBQAAxIwAAEaSAAAEEAAAggUAAAAAAACCBQAAAAAA AIIFAAAAAAAARpIAAAAAAACCBQAAAAAAAIIFAAAAAAAAggUAAAAAAAD8BAAAAAAAAPwEAAAAAAAA /AQAAAAAAAD8BAAAAAAAAPwEAAAAAAAA/AQAAAAAAAD/////AAAAAAIADAEAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGRyYWZ0 LXRzYW8tcm9sbC1zZWN1cml0eS1mcmFtZXdvcmstMDAudHh0DQ1OZXR3b3JraW5nIFdvcmtpbmcg R3JvdXAgVC4gVHNhbywgRWQuDUludGVybmV0LURyYWZ0IFIuIEFsZXhhbmRlciwgRWQuDUludGVu ZGVkIHN0YXR1czogSW5mb3JtYXRpb25hbCBFa2EgU3lzdGVtcw1FeHBpcmVzOiBBdWd1c3QgMjAs IDIwMDkgTS4gRG9obGVyLCBFZC4NQ1RUQw1WLiBEYXphLCBFZC4NQS4gTG96YW5vLCBFZC4NVW5p dmVyc2l0YXQgUG9tcGV1IEZhYnJhDUZlYnJ1YXJ5IDE2LCAyMDA5DQ1BIFNlY3VyaXR5IEZyYW1l d29yayBmb3IgUm91dGluZyBvdmVyIExvdyBQb3dlciBhbmQgTG9zc3kgTmV0d29ya3MNZHJhZnQt dHNhby1yb2xsLXNlY3VyaXR5LWZyYW1ld29yay0wMA0NU3RhdHVzIG9mIHRoaXMgTWVtbw1UaGlz IEludGVybmV0LURyYWZ0IGlzIHN1Ym1pdHRlZCB0byBJRVRGIGluIGZ1bGwgY29uZm9ybWFuY2Ug d2l0aCB0aGUNcHJvdmlzaW9ucyBvZiBCQ1AgNzggYW5kIEJDUCA3OS4NSW50ZXJuZXQtRHJhZnRz IGFyZSB3b3JraW5nIGRvY3VtZW50cyBvZiB0aGUgSW50ZXJuZXQgRW5naW5lZXJpbmcNVGFzayBG b3JjZSAoSUVURiksIGl0cyBhcmVhcywgYW5kIGl0cyB3b3JraW5nIGdyb3Vwcy4gTm90ZSB0aGF0 DW90aGVyIGdyb3VwcyBtYXkgYWxzbyBkaXN0cmlidXRlIHdvcmtpbmcgZG9jdW1lbnRzIGFzIElu dGVybmV0LQ1EcmFmdHMuDUludGVybmV0LURyYWZ0cyBhcmUgZHJhZnQgZG9jdW1lbnRzIHZhbGlk IGZvciBhIG1heGltdW0gb2Ygc2l4IG1vbnRocw1hbmQgbWF5IGJlIHVwZGF0ZWQsIHJlcGxhY2Vk LCBvciBvYnNvbGV0ZWQgYnkgb3RoZXIgZG9jdW1lbnRzIGF0IGFueQ10aW1lLiBJdCBpcyBpbmFw cHJvcHJpYXRlIHRvIHVzZSBJbnRlcm5ldC1EcmFmdHMgYXMgcmVmZXJlbmNlDW1hdGVyaWFsIG9y IHRvIGNpdGUgdGhlbSBvdGhlciB0aGFuIGFzICJ3b3JrIGluIHByb2dyZXNzLiINVGhlIGxpc3Qg b2YgY3VycmVudCBJbnRlcm5ldC1EcmFmdHMgY2FuIGJlIGFjY2Vzc2VkIGF0DWh0dHA6Ly93d3cu aWV0Zi5vcmcvaWV0Zi8xaWQtYWJzdHJhY3RzLnR4dC4NVGhlIGxpc3Qgb2YgSW50ZXJuZXQtRHJh ZnQgU2hhZG93IERpcmVjdG9yaWVzIGNhbiBiZSBhY2Nlc3NlZCBhdA1odHRwOi8vd3d3LmlldGYu b3JnL3NoYWRvdy5odG1sLg1UaGlzIEludGVybmV0LURyYWZ0IHdpbGwgZXhwaXJlIG9uIEF1Z3Vz dCAyMCwgMjAwOS4NQ29weXJpZ2h0IE5vdGljZQ1Db3B5cmlnaHQgKGMpIDIwMDkgSUVURiBUcnVz dCBhbmQgdGhlIHBlcnNvbnMgaWRlbnRpZmllZCBhcyB0aGUNZG9jdW1lbnQgYXV0aG9ycy4gQWxs IHJpZ2h0cyByZXNlcnZlZC4NVGhpcyBkb2N1bWVudCBpcyBzdWJqZWN0IHRvIEJDUCA3OCBhbmQg dGhlIElFVEYgVHJ1c3QncyBMZWdhbA1Qcm92aXNpb25zIFJlbGF0aW5nIHRvIElFVEYgRG9jdW1l bnRzDShodHRwOi8vdHJ1c3RlZS5pZXRmLm9yZy9saWNlbnNlLWluZm8pIGluIGVmZmVjdCBvbiB0 aGUgZGF0ZSBvZg1wdWJsaWNhdGlvbiBvZiB0aGlzIGRvY3VtZW50LiBQbGVhc2UgcmV2aWV3IHRo ZXNlIGRvY3VtZW50cw1jYXJlZnVsbHksIGFzIHRoZXkgZGVzY3JpYmUgeW91ciByaWdodHMgYW5k IHJlc3RyaWN0aW9ucyB3aXRoIHJlc3BlY3QNdG8gdGhpcyBkb2N1bWVudC4NDQxBYnN0cmFjdA1U aGlzIGRvY3VtZW50IHByZXNlbnRzIGEgc2VjdXJpdHkgZnJhbWV3b3JrIGZvciByb3V0aW5nIG92 ZXIgbG93DXBvd2VyIGFuZCBsb3NzeSBuZXR3b3Jrcy4gVGhlIGRldmVsb3BtZW50IG9mIHRoZSBm cmFtZXdvcmsgYnVpbGRzDXVwb24gcHJldmlvdXMgd29yayBvbiByb3V0aW5nIHNlY3VyaXR5IGFu ZCBhZGFwdHMgdGhlIHNlY3VyaXR5DWFzc2Vzc21lbnRzIHRvIHRoZSBpc3N1ZXMgYW5kIGNvbnN0 cmFpbnRzIHNwZWNpZmljIHRvIGxvdyBwb3dlciBhbmQNbG9zc3kgbmV0d29ya3MuIEEgc3lzdGVt YXRpYyBhcHByb2FjaCBpcyB1c2VkIGluIGRlZmluaW5nIGFuZA1hc3Nlc3NpbmcgdGhlIHNlY3Vy aXR5IHRocmVhdHMgYW5kIGlkZW50aWZ5aW5nIGFwcGxpY2FibGUNY291bnRlcm1lYXN1cmVzLiBU aGVzZSBhc3Nlc3NtZW50cyBwcm92aWRlIHRoZSBiYXNpcyBvZiB0aGUgc2VjdXJpdHkNcmVjb21t ZW5kYXRpb25zIGZvciBpbmNvcnBvcmF0aW9uIGludG8gbG93IHBvd2VyLCBsb3NzeSBuZXR3b3Jr DXJvdXRpbmcgcHJvdG9jb2xzLg1SZXF1aXJlbWVudHMgTGFuZ3VhZ2UNVGhlIGtleSB3b3JkcyAi TVVTVCIsICJNVVNUIE5PVCIsICJSRVFVSVJFRCIsICJTSEFMTCIsICJTSEFMTCBOT1QiLA0iU0hP VUxEIiwgIlNIT1VMRCBOT1QiLCAiUkVDT01NRU5ERUQiLCAiTUFZIiwgYW5kICJPUFRJT05BTCIg aW4gdGhpcw1kb2N1bWVudCBhcmUgdG8gYmUgaW50ZXJwcmV0ZWQgYXMgZGVzY3JpYmVkIGluIFJG QyAyMTE5IFtSRkMyMTE5XS4NDQ1UYWJsZSBvZiBDb250ZW50cw0xLiBUZXJtaW5vbG9neSAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDUNMi4gSW50cm9k dWN0aW9uIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g NQ0zLiBDb25zaWRlcmF0aW9ucyBvbiBST0xMIFNlY3VyaXR5IC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIDUNMy4xLiBSb3V0aW5nIEFzc2V0cyBhbmQgUG9pbnRzIG9mIEFjY2VzcyAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gNg0zLjIuIFRoZSBDSUEgU2VjdXJpdHkgUmVmZXJlbmNlIE1vZGVs IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gOA0zLjMuIElzc3VlcyBTcGVjaWZpYyB0byBvciBN YWduaWZpZWQgaW4gTExOcyAuIC4gLiAuIC4gLiAuIC4gLiAxMA00LiBUaHJlYXRzIGFuZCBBdHRh Y2tzIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDExDTQuMS4gVGhy ZWF0cyBhbmQgQXR0YWNrcyBvbiBDb25maWRlbnRpYWxpdHkgLiAuIC4gLiAuIC4gLiAuIC4gLiAx Mg00LjEuMS4gUm91dGluZyBFeGNoYW5nZSBFeHBvc3VyZSAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gMTINNC4xLjIuIFJvdXRpbmcgSW5mb3JtYXRpb24gKFJvdXRlcyBhbmQgTmV0d29yayBU b3BvbG9neSkNRXhwb3N1cmUgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIDEyDTQuMi4gVGhyZWF0cyBhbmQgQXR0YWNrcyBvbiBJbnRlZ3JpdHkgLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAxMw00LjIuMS4gUm91dGluZyBJbmZvcm1hdGlvbiBNYW5pcHVsYXRp b24gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDEzDTQuMi4yLiBOb2RlIElkZW50aXR5IE1pc2FwcHJv cHJpYXRpb24gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMTMNNC4zLiBUaHJlYXRzIGFuZCBBdHRh Y2tzIG9uIEF2YWlsYWJpbGl0eSAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMTQNNC4zLjEuIFJvdXRp bmcgRXhjaGFuZ2UgSW50ZXJmZXJlbmNlIG9yIERpc3J1cHRpb24gLiAuIC4gLiAuIDE0DTQuMy4y LiBOZXR3b3JrIFRyYWZmaWMgRm9yd2FyZGluZyBEaXNydXB0aW9uIC4gLiAuIC4gLiAuIC4gLiAx NA00LjMuMy4gQ29tbXVuaWNhdGlvbnMgUmVzb3VyY2UgRGlzcnVwdGlvbiAuIC4gLiAuIC4gLiAu IC4gLiAuIDE0DTQuMy40LiBOb2RlIFJlc291cmNlIEV4aGF1c3Rpb24gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gMTUNNS4gQ291bnRlcm1lYXN1cmVzIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAxNQ01LjEuIENvbmZpZGVudGlhbGl0eSBBdHRhY2sg Q291bnRlcm1lYXN1cmVzIC4gLiAuIC4gLiAuIC4gLiAuIC4gMTYNNS4xLjEuIENvdW50ZXJpbmcg RGVsaWJlcmF0ZSBFeHBvc3VyZSBBdHRhY2tzIC4gLiAuIC4gLiAuIC4gLiAxNg01LjEuMi4gQ291 bnRlcmluZyBTbmlmZmluZyBBdHRhY2tzIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMTYNNS4x LjMuIENvdW50ZXJpbmcgVHJhZmZpYyBBbmFseXNpcyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IDE3DTUuMS40LiBDb3VudGVyaW5nIFBoeXNpY2FsIERldmljZSBDb21wcm9taXNlIC4gLiAuIC4g LiAuIC4gLiAxOA01LjEuNS4gQ291bnRlcmluZyBSZW1vdGUgRGV2aWNlIEFjY2VzcyBBdHRhY2tz IC4gLiAuIC4gLiAuIC4gMjANNS4yLiBJbnRlZ3JpdHkgQXR0YWNrIENvdW50ZXJtZWFzdXJlcyAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDIwDTUuMi4xLiBDb3VudGVyaW5nIFRhbXBlcmluZyBB dHRhY2tzIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMjENNS4yLjIuIENvdW50ZXJpbmcgT3Zl cmNsYWltaW5nIGFuZCBNaXNjbGFpbWluZyBBdHRhY2tzIC4gLiAuIDIxDTUuMi4zLiBDb3VudGVy aW5nIElkZW50aXR5IChpbmNsdWRpbmcgU3liaWwpIEF0dGFja3MgLiAuIC4gLiAyMQ01LjIuNC4g Q291bnRlcmluZyBSb3V0aW5nIEluZm9ybWF0aW9uIFJlcGxheSBBdHRhY2tzIC4gLiAuIC4gMjIN NS4zLiBBdmFpbGFiaWxpdHkgQXR0YWNrIENvdW50ZXJtZWFzdXJlcyAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gMjINNS4zLjEuIENvdW50ZXJpbmcgSEVMTE8gRmxvb2QgQXR0YWNrcyBhbmQgQUNLIFNw b29maW5nIEF0dGFja3MgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIDIyDTUuMy4yLiBDb3VudGVyaW5nIE92ZXJsb2FkIEF0dGFja3MgLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAyNA01LjMuMy4gQ291bnRlcmluZyBTZWxlY3RpdmUgRm9yd2FyZGluZyBBdHRh Y2tzIC4gLiAuIC4gLiAuIC4gMjUNNS4zLjQuIENvdW50ZXJpbmcgU2lua2hvbGUgQXR0YWNrcyAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDI1DTUuMy41LiBDb3VudGVyaW5nIFdvcm1ob2xlIEF0 dGFja3MgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAyNg02LiBST0xMIFNlY3VyaXR5IEZlYXR1 cmVzIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAyNg02LjEuIENvbmZp ZGVudGlhbGl0eSBGZWF0dXJlcyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMjcN Ni4yLiBJbnRlZ3JpdHkgRmVhdHVyZXMgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIDI3DTYuMy4gQXZhaWxhYmlsaXR5IEZlYXR1cmVzIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIDI3DTYuNC4gQWRkaXRpb25hbCBDb25zaWRlcmF0aW9ucyAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDI3DTcuIElBTkEgQ29uc2lkZXJhdGlvbnMgLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMjgNOC4gU2VjdXJpdHkgQ29uc2lk ZXJhdGlvbnMgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAyOA05LiBBY2tu b3dsZWRnbWVudHMgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IDI4DQwxMC4gUmVmZXJlbmNlcyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gMjgNMTAuMS4gTm9ybWF0aXZlIFJlZmVyZW5jZXMgLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAyOA0xMC4yLiBJbmZvcm1hdGl2ZSBSZWZlcmVuY2Vz IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDI4DUF1dGhvcnMnIEFkZHJlc3Nl cyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAzMA0MMS4g VGVybWlub2xvZ3kNVGhpcyBkb2N1bWVudCBjb25mb3JtcyB0byB0aGUgdGVybWlub2xvZ3kgZGVm aW5lZCBpbg1bSS1ELmlldGYtcm9sbC10ZXJtaW5vbG9neV0sIHdpdGggdGhlIGZvbGxvd2luZyBh ZGRpdGlvbnMuDUxpbmsgQ29zdCBBIHF1YW50aWZpY2F0aW9uIG9mIGNob3NlbiBjaGFyYWN0ZXJp c3RpY3Mgb2YgYSBsaW5rLg1Ob2RlIEEgYmFzZSB1bml0IG9mIGEgbmV0d29yaywgZS5nLiwgYSBy b3V0ZXIgb3IgYSBob3N0IG9uIGEgbG93DXBvd2VyIGFuZCBsb3NzeSBuZXR3b3JrLg1Sb3V0aW5n IE1ldHJpYyBBIGZ1bmN0aW9uIG9mIGxpbmsgY29zdHMgYWxvbmcgcm91dGVzLCB3aG9zZSB2YWx1 ZQ1naXZlcyByaXNlIHRvIHByZWZlcmVuY2Ugb2Ygcm91dGluZyBjaG9pY2VzLg0NMi4gSW50cm9k dWN0aW9uDUluIHJlY2VudCB0aW1lcywgbmV0d29ya2VkIHdpcmVsZXNzIGRldmljZXMgaGF2ZSBm b3VuZCBhbiBpbmNyZWFzaW5nDW51bWJlciBvZiBhcHBsaWNhdGlvbnMgaW4gdmFyaW91cyBmaWVs ZHMuIFlldCwgZm9yIHJlYXNvbnMgcmFuZ2luZw1mcm9tIG9wZXJhdGlvbmFsIGFwcGxpY2F0aW9u IHRvIGVjb25vbWljcywgdGhlc2Ugd2lyZWxlc3MgZGV2aWNlcyBhcmUNb2Z0ZW4gc3VwcGxpZWQg d2l0aCBtaW5pbXVtIHBoeXNpY2FsIHJlc291cmNlcywgZS5nLiwgbGltaXRlZCBwb3dlcg1yZXNl cnZlLCBzbG93IHNwZWVkIG9yIGxvdyBjYXBhYmlsaXR5IGNvbXB1dGF0aW9uLCBvciBzbWFsbCBt ZW1vcnkNc2l6ZS4gQXMgYSBjb25zZXF1ZW5jZSwgdGhlIHJlc3VsdGluZyBuZXR3b3JrcyBhcmUg bW9yZSBwcm9uZSB0bw1sb3NzIG9mIHRyYWZmaWMgYW5kIG90aGVyIHZ1bG5lcmFiaWxpdGllcy4g VGhlIHByb2xpZmVyYXRpb24gb2YNdGhlc2UgbG93IHBvd2VyIGFuZCBsb3NzeSBuZXR3b3JrcyAo TExOcyksIGhvd2V2ZXIsIGFyZSBkcmF3aW5nDWVmZm9ydHMgdG8gZXhhbWluZSBhbmQgYWRkcmVz cyB0aGVpciBwb3RlbnRpYWwgbmV0d29ya2luZyBjaGFsbGVuZ2VzLg1UaGlzIGRvY3VtZW50IHBy ZXNlbnRzIGEgZnJhbWV3b3JrIGZvciBzZWN1cmluZyByb3V0aW5nIG92ZXIgbG93DXBvd2VyIGFu ZCBsb3NzeSBuZXR3b3JrcyAoUk9MTCkgdGhyb3VnaCBhbiBhbmFseXNpcyB0aGF0IHN0YXJ0cyBm cm9tDXRoZSByb3V0aW5nIGJhc2ljcy4gVGhlIG9iamVjdGl2ZSBpcyB0d28tZm9sZC4gRmlyc3Qs IHRoZSBmcmFtZXdvcmsNd2lsbCBiZSB1c2VkIHRvIGlkZW50aWZ5IHBlcnRpbmVudCBzZWN1cml0 eSBpc3N1ZXMuIFNlY29uZCwgaXQgd2lsbA1mYWNpbGl0YXRlIGJvdGggdGhlIGFzc2Vzc21lbnQg b2YgYSBwcm90b2NvbCdzIHNlY3VyaXR5IHRocmVhdHMgYW5kDXRoZSBpZGVudGlmaWNhdGlvbiBv ZiB0aGUgbmVjZXNzYXJ5IGZlYXR1cmVzIGZvciBkZXZlbG9wbWVudCBvZg1zZWN1cmUgcHJvdG9j b2xzIGZvciBST0xMLg1UaGUgYXBwcm9hY2ggYWRvcHRlZCBpbiB0aGlzIGVmZm9ydCBwcm9jZWVk cyBpbiBmb3VyIHN0ZXBzLCB0bw1leGFtaW5lIFJPTEwgc2VjdXJpdHkgaXNzdWVzLCB0byBhbmFs eXplIHRocmVhdHMgYW5kIGF0dGFja3MsIHRvDWNvbnNpZGVyIHRoZSBjb3VudGVybWVhc3VyZXMs IGFuZCB0aGVuIHRvIG1ha2UgcmVjb21tZW5kYXRpb25zIGZvcg1zZWN1cmluZyBST0xMLiBUaGUg YmFzaXMgaXMgZm91bmQgb24gaWRlbnRpZnlpbmcgdGhlIGFzc2V0cyBhbmQNcG9pbnRzIG9mIGFj Y2VzcyBvZiByb3V0aW5nIGFuZCBldmFsdWF0aW5nIHRoZWlyIHNlY3VyaXR5IG5lZWRzIGJhc2Vk DW9uIHRoZSBDb25maWRlbnRpYWxpdHksIEludGVncml0eSwgYW5kIEF2YWlsYWJpbGl0eSAoQ0lB KSBtb2RlbCBpbg10aGUgY29udGV4dCBvZiBMTE4uDQ0zLiBDb25zaWRlcmF0aW9ucyBvbiBST0xM IFNlY3VyaXR5DVRoaXMgc2VjdGlvbiBzZXRzIHRoZSBzdGFnZSBmb3IgdGhlIGRldmVsb3BtZW50 IG9mIHRoZSBmcmFtZXdvcmsgYnkNYXBwbHlpbmcgdGhlIHN5c3RlbWF0aWMgYXBwcm9hY2ggcHJv cG9zZWQgaW4gW015YWdtYXIyMDA1XSB0byB0aGUNcm91dGluZyBzZWN1cml0eSBwcm9ibGVtLCB3 aGlsZSBhbHNvIGRyYXdpbmcgcmVmZXJlbmNlcyBmcm9tIG90aGVyDXJldmlld3MgYW5kIGFzc2Vz c21lbnRzIGZvdW5kIGluIHRoZSBsaXRlcmF0dXJlLCBwYXJ0aWN1bGFybHksDVtSRkM0NTkzXSBh bmQgW0thcmxvZjIwMDNdLiBUaGUgc3Vic2VxdWVudCBzdWJzZWN0aW9ucyBiZWdpbiB3aXRoIGEN Zm9jdXMgb24gdGhlIGVsZW1lbnRzIG9mIGEgZ2VuZXJpYyByb3V0aW5nIHByb2Nlc3MgdGhhdCBp cyB1c2VkIHRvDWVzdGFibGlzaCByb3V0aW5nIGFzc2V0cyBhbmQgcG9pbnRzIG9mIGFjY2VzcyBv ZiB0aGUgcm91dGluZw1mdW5jdGlvbmFsaXR5LiBOZXh0LCB0aGUgQ0lBIHNlY3VyaXR5IG1vZGVs IGlzIGJyaWVmbHkgZGVzY3JpYmVkLg1UaGVuLCBjb25zaWRlcmF0aW9uIGlzIGdpdmVuIHRvIGlz c3VlcyBzcGVjaWZpYyB0byBvciBtYWduaWZpZWQgaW4NTExOcy4NMy4xLiBSb3V0aW5nIEFzc2V0 cyBhbmQgUG9pbnRzIG9mIEFjY2Vzcw1BbiBhc3NldCBpbXBsaWVzIGltcG9ydGFudCBzeXN0ZW0g Y29tcG9uZW50IChpbmNsdWRpbmcgaW5mb3JtYXRpb24sDXByb2Nlc3MsIG9yIHBoeXNpY2FsIHJl c291cmNlKSwgdGhlIGFjY2VzcyB0bywgY29ycnVwdGlvbiBvciBsb3NzIG9mDXdoaWNoIGFkdmVy c2VseSBhZmZlY3RzIHRoZSBzeXN0ZW0uIEluIG5ldHdvcmsgcm91dGluZywgYXNzZXRzIGxpZQ1p biB0aGUgcm91dGluZyBpbmZvcm1hdGlvbiwgcm91dGluZyBwcm9jZXNzLCBhbmQgbm9kZSdzIHBo eXNpY2FsDXJlc291cmNlcy4gVGhhdCBpcywgdGhlIGFjY2VzcyB0bywgY29ycnVwdGlvbiwgb3Ig bG9zcyBvZiB0aGVzZQ1lbGVtZW50cyBhZHZlcnNlbHkgYWZmZWN0cyBzeXN0ZW0gcm91dGluZy4g SW4gbmV0d29yayByb3V0aW5nLCBhDXBvaW50IG9mIGFjY2VzcyByZWZlcnMgdG8gdGhlIHBvaW50 IG9mIGVudHJ5IGZhY2lsaXRhdGluZw1jb21tdW5pY2F0aW9uIHdpdGggb3Igb3RoZXIgaW50ZXJh Y3Rpb24gd2l0aCBhIHN5c3RlbSBjb21wb25lbnQgaW4Nb3JkZXIgdG8gdXNlIHN5c3RlbSByZXNv dXJjZXMgdG8gZWl0aGVyIG1hbmlwdWxhdGUgaW5mb3JtYXRpb24gb3INZ2FpbiBrbm93bGVkZ2Ug b2YgdGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCB3aXRoaW4gdGhlIHN5c3RlbS4NU2VjdXJpdHkg b2YgdGhlIHJvdXRpbmcgcHJvdG9jb2wgbXVzdCBiZSBmb2N1c2VkIG9uIHRoZSBhc3NldHMgb2Yg dGhlDXJvdXRpbmcgbm9kZXMgYW5kIHRoZSBwb2ludHMgb2YgYWNjZXNzIG9mIHRoZSBpbmZvcm1h dGlvbiBleGNoYW5nZXMNYW5kIGluZm9ybWF0aW9uIHN0b3JhZ2UgdGhhdCBtYXkgcGVybWl0IHJv dXRpbmcgY29tcHJvbWlzZS4gVGhlDWlkZW50aWZpY2F0aW9uIG9mIHJvdXRpbmcgYXNzZXRzIGFu ZCBwb2ludHMgb2YgYWNjZXNzIGhlbmNlIHByb3ZpZGVzDWEgYmFzaXMgZm9yIHRoZSBpZGVudGlm aWNhdGlvbiBvZiBhc3NvY2lhdGVkIHRocmVhdHMgYW5kIGF0dGFja3MuDVRoaXMgc3Vic2VjdGlv biBpZGVudGlmaWVzIGFzc2V0cyBhbmQgcG9pbnRzIG9mIGFjY2VzcyBvZiBhIGdlbmVyaWMNcm91 dGluZyBwcm9jZXNzIHdpdGggYSBsZXZlbC0wIGRhdGEgZmxvdyBkaWFncmFtLiBUaGUgdXNlIG9m IHRoZQ1kYXRhIGZsb3cgZGlhZ3JhbSBhbGxvd3MgZm9yIGEgY2xlYXIsIGNvbmNpc2UgbW9kZWwg b2YgdGhlIHJvdXRpbmcNZnVuY3Rpb25hbGl0eTsgaXQgYWxzbyBoYXMgdGhlIGJlbmVmaXQgb2Yg c2hvd2luZyB0aGUgbWFubmVyIGluIHdoaWNoDW5vZGVzIHBhcnRpY2lwYXRlIGluIHRoZSByb3V0 aW5nIHByb2Nlc3MsIHRodXMgcHJvdmlkaW5nIGNvbnRleHQgd2hlbg1sYXRlciB0aHJlYXRzIGFu ZCBhdHRhY2tzIGFyZSBjb25zaWRlcmVkLiBUaGUgZ29hbCBvZiB0aGUgbW9kZWwgaXMNdG8gYmUg YXMgZGV0YWlsZWQgYXMgcG9zc2libGUgc28gdGhhdCBjb3JyZXNwb25kaW5nIGNvbXBvbmVudHMg YW5kDW1lY2hhbmlzbXMgaW4gYW4gaW5kaXZpZHVhbCByb3V0aW5nIHByb3RvY29sIGNhbiBiZSBy ZWFkaWx5DWlkZW50aWZpZWQsIGJ1dCBhbHNvIHRvIGJlIGFzIGdlbmVyYWwgYXMgcG9zc2libGUg dG8gbWF4aW1pemUgdGhlDXJlbGV2YW5jeSBvZiB0aGlzIGVmZm9ydCBmb3IgdGhlIHZhcmlvdXMg ZXhpc3RpbmcgYW5kIGZ1dHVyZQ1wcm90b2NvbHMuIE5ldmVydGhlbGVzcywgdGhlcmUgbWF5IGJl IGRpc2NyZXBhbmNpZXMsIGxpa2VseSBpbiB0aGUNZm9ybSBvZiBhZGRpdGlvbmFsIGVsZW1lbnRz LCB3aGVuIHRoZSBtb2RlbCBpcyBhcHBsaWVkIHRvIHNvbWUNcHJvdG9jb2xzLiBGb3Igc3VjaCBj YXNlcywgdGhlIGFuYWx5c2lzIGFwcHJvYWNoIGxhaWQgb3V0IGluIHRoaXMNZG9jdW1lbnQgc2hv dWxkIHN0aWxsIHByb3ZpZGUgYSB2YWxpZCBhbmQgaWxsdXN0cmF0aXZlIHBhdGggZm9yIHRoZWly DXNlY3VyaXR5IGFzc2Vzc21lbnQuDUZpZ3VyZSAxIHNob3dzIHRoYXQgbm9kZXMgcGFydGljaXBh dGluZyBpbiB0aGUgcm91dGluZyBwcm9jZXNzDXRyYW5zbWl0IG1lc3NhZ2VzIHRvIGRldGVybWlu ZSB0aGVpciBuZWlnaGJvcnMgKG5laWdoYm9yIGRpc2NvdmVyeSkuDVVzaW5nIHRoZSBuZWlnaGJv cmluZyByZWxhdGlvbnNoaXBzLCByb3V0aW5nIHByb3RvY29scyBtYXkgZXhjaGFuZ2UNbmV0d29y ayB0b3BvbG9neSAoaW5jbHVkaW5nIGxpbmstc3BlY2lmaWMgaW5mb3JtYXRpb24pIHRvIGdlbmVy YXRlDXJvdXRlcyBvciBtYXkgZXhjaGFuZ2Ugcm91dGVzIGRpcmVjdGx5IGFzIHBhcnQgb2YgYSBy b3V0aW5nIGV4Y2hhbmdlOw1ub2RlcyB3aGljaCBkbyBub3QgZGlyZWN0bHkgcGFydGljaXBhdGUg aW4gdGhlIHByb2Nlc3Mgd2l0aCBhIGdpdmVuDW5vZGUgd2lsbCBnZXQgdGhlIHJvdXRlL3RvcG9s b2d5IGluZm9ybWF0aW9uIHJlbGF5ZWQgZnJvbSBvdGhlcnMuIEl0DWlzIGxpa2VseSB0aGF0IGEg bm9kZSB3aWxsIHN0b3JlIHNvbWUgb3IgYWxsIG9mIHRoZSByb3V0ZXMgYW5kDXRvcG9sb2d5IGlu Zm9ybWF0aW9uIGFjY29yZGluZyB0byB0cmFkZW9mZnMgb2Ygbm9kZSByZXNvdXJjZXMgYW5kDWxh dGVuY3kgYXNzb2NpYXRlZCB3aXRoIHRoZSBwYXJ0aWN1bGFyIHJvdXRpbmcgcHJvdG9jb2wuIFRo ZSBub2Rlcw11c2UgdGhlIGRlcml2ZWQgcm91dGVzIGZvciBtYWtpbmcgZm9yd2FyZGluZyBkZWNp c2lvbnMFLg0uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4NOiA6DTogX19fX19fX19fX19fX19fX18gOg18Tm9kZV9pfDwtLS0tLS0tPihOZWlnaGJvciBE aXNjb3ZlcnkpLS0tPk5laWdoYm9yIFRvcG9sb2d5IDoNOiAtLS0tLS0tLS0tLS0tLS0tLSA6DTog fCA6DXxOb2RlX2p8PC0tLS0tLS0+KFJvdXRlL1RvcG9sb2d5ICstLS0tLS0tLSsgOg06IEV4Y2hh bmdlICkgfCA6DTogfCBWIF9fX19fXyA6DTogKy0tLS0+KFJvdXRlIEdlbmVyYXRpb24pLS0tPlJv dXRlcyA6DTogLS0tLS0tIDoNOiB8IDoNOiBSb3V0aW5nIG9uIGEgTm9kZSBOb2RlX2sgfCA6DS4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLg18DXxGb3J3 YXJkaW5nIHwNT24gTm9kZV9rIHw8LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tKw1Ob3RhdGlvbjoNKFByb2MpIEEgcHJvY2VzcyBQcm9jDV9fX19fX19fDURhdGFCYXNl IEEgZGF0YSBzdG9yYWdlIERhdGFCYXNlDS0tLS0tLS0tDXxOb2RlX258IEFuIGV4dGVybmFsIGVu dGl0eSBOb2RlX24NLS0tLS0tLT4gRGF0YSBmbG93DUZpZ3VyZSAxOiBEYXRhIEZsb3cgRGlhZ3Jh bSBvZiBhIEdlbmVyaWMgUm91dGluZyBQcm9jZXNzDUl0IGlzIHNlZW4gZnJvbSBGaWd1cmUgMSB0 aGF0DW8gQXNzZXRzIGluY2x1ZGUNKiByb3V0aW5nIGFuZC9vciB0b3BvbG9neSBpbmZvcm1hdGlv bjsNKiBjb21tdW5pY2F0aW9uIGNoYW5uZWwgcmVzb3VyY2VzIChiYW5kd2lkdGgpOw0qIG5vZGUg cmVzb3VyY2VzIChjb21wdXRpbmcgY2FwYWNpdHksIG1lbW9yeSwgYW5kIHJlbWFpbmluZw1lbmVy Z3kpOw0qIG5vZGUgaWRlbnRpZmllcnMgKGluY2x1ZGluZyBub2RlIGlkZW50aXR5IGFuZCBhc2Ny aWJlZA1hdHRyaWJ1dGVzIHN1Y2ggYXMgcmVsYXRpdmUgb3IgYWJzb2x1dGUgbm9kZSBsb2NhdGlv bikuDW8gUG9pbnRzIG9mIGFjY2VzcyBpbmNsdWRlDSogbmVpZ2hib3IgZGlzY292ZXJ5Ow0qIHJv dXRlL3RvcG9sb2d5IGV4Y2hhbmdlOw0qIG5vZGUgcGh5c2ljYWwgaW50ZXJmYWNlcyAoaW5jbHVk aW5nIGFjY2VzcyB0byBkYXRhIHN0b3JhZ2UpLg1PcHRpb25hbGx5LCBpbiBjYXNlIHRydXN0IGFu ZCBlbmVyZ3kgZWZmaWNpZW5jeSBtb2RlbHMgYXJlIGFwcGxpZWQgdGhlDW5vZGVzIG1heSBleGNo YW5nZToNKiBuZWlnaGJvdXJpbmcgbm9kZXMgZW5lcmd5IA0qIG5laWdoYm91cmluZyB0cnVzdC9y ZXB1dGF0aW9uIA1BIGZvY3VzIG9uIHRoZSBhYm92ZSBsaXN0IG9mIGFzc2V0cyBhbmQgcG9pbnRz IG9mIGFjY2VzcyBlbmFibGVzIGENbW9yZSBkaXJlY3RlZCBhc3Nlc3NtZW50IG9mIHJvdXRpbmcg c2VjdXJpdHkuDTMuMi4gVGhlIENJQSBTZWN1cml0eSBSZWZlcmVuY2UgTW9kZWwNQXQgdGhlIGNv bmNlcHR1YWwgbGV2ZWwsIHNlY3VyaXR5IHdpdGhpbiBhbiBpbmZvcm1hdGlvbiBzeXN0ZW0gaW4N Z2VuZXJhbCBhbmQgYXBwbGllZCB0byBST0xMIGluIHBhcnRpY3VsYXIgaXMgY29uY2VybmVkIHdp dGggdGhlDXByaW1hcnkgaXNzdWVzIG9mIGNvbmZpZGVudGlhbGl0eSwgaW50ZWdyaXR5LCBhbmQg YXZhaWxhYmlsaXR5LiBJbg10aGUgY29udGV4dCBvZiBST0xMOg0NQ29uZmlkZW50aWFsaXR5DUNv bmZpZGVudGlhbGl0eSBpbnZvbHZlcyB0aGUgcHJvdGVjdGlvbiBvZiByb3V0aW5nIGluZm9ybWF0 aW9uDWFzIHdlbGwgYXMgcm91dGluZyBuZWlnaGJvciBtYWludGVuYW5jZSBleGNoYW5nZXMgc28g dGhhdCBvbmx5DWF1dGhvcml6ZWQgYW5kIGludGVuZGVkIG5ldHdvcmsgZW50aXRpZXMgbWF5IHZp ZXcgb3IgYWNjZXNzIGl0Lg1CZWNhdXNlIG9mIHRoZSB3aXJlbGVzcywgYW5kIHNvbWV0aW1lcyBh ZCBob2MsIG5hdHVyZSBvZiB0aGUNbmV0d29yaywgY29uZmlkZW50aWFsaXR5IGFsc28gZXh0ZW5k cyB0byB0aGUgbmVpZ2hib3Igc3RhdGUgYW5kDWRhdGFiYXNlIGluZm9ybWF0aW9uIHdpdGhpbiB0 aGUgcm91dGluZyBkZXZpY2Ugc2luY2UgdGhlDWRlcGxveW1lbnQgb2YgdGhlIG5ldHdvcmsgY3Jl YXRlcyB0aGUgcG90ZW50aWFsIGZvcg11bmF1dGhvcml6ZWQgYWNjZXNzIHRvIHRoZSBwaHlzaWNh bCBkZXZpY2VzIHRoZW1zZWx2ZXMuDQ1JbnRlZ3JpdHkNSW50ZWdyaXR5LCBhcyBhIHNlY3VyaXR5 IHByaW5jaXBsZSwgZW50YWlscyB0aGUgcHJvdGVjdGlvbiBvZg1yb3V0aW5nIGluZm9ybWF0aW9u IGFuZCByb3V0aW5nIG5laWdoYm9yIG1haW50ZW5hbmNlIGV4Y2hhbmdlcywNYXMgd2VsbCBhcyBk ZXJpdmVkIGluZm9ybWF0aW9uIG1haW50YWluZWQgaW4gdGhlIGRhdGFiYXNlLCBmcm9tDW1pc3Vz ZSBvciB1bmF1dGhvcml6ZWQgYW5kIGltcHJvcGVyIG1vZGlmaWNhdGlvbi4gSW4gYWRkaXRpb24s DWludGVncml0eSBhbHNvIHJlcXVpcmVzIHRoZSBhdXRoZW50aWNpdHkgb2YgY2xhaW1lZCBpZGVu dGl0eSBpbg10aGUgb3JpZ2luIGFuZCBkZXN0aW5hdGlvbiBvZiBhIG1lc3NhZ2UsIGFjY2VzcyBh bmQgcmVtb3ZhbCBvZg1kYXRhLCBleGVjdXRpb24gb2YgdGhlIHJvdXRpbmcgcHJvY2VzcywgYW5k IHVzZSBvZiBjb21wdXRpbmcNYW5kIGVuZXJneSByZXNvdXJjZXMuDQ1BdmFpbGFiaWxpdHkNQXZh aWxhYmlsaXR5IGVuc3VyZXMgdGhhdCByb3V0aW5nIGluZm9ybWF0aW9uIGV4Y2hhbmdlcyBhbmQN Zm9yd2FyZGluZyBzZXJ2aWNlcyBuZWVkIHRvIGJlIGF2YWlsYWJsZSB3aGVuIHRoZXkgYXJlIHJl cXVpcmVkDWZvciB0aGUgZnVuY3Rpb25pbmcgb2YgdGhlIHNlcnZpbmcgbmV0d29yay4gQXZhaWxh YmlsaXR5IHdpbGwNYXBwbHkgdG8gbWFpbnRhaW5pbmcgZWZmaWNpZW50IGFuZCBjb3JyZWN0IG9w ZXJhdGlvbiBvZiByb3V0aW5nDWFuZCBuZWlnaGJvciBkaXNjb3ZlcnkgZXhjaGFuZ2VzIChpbmNs dWRpbmcgbmVlZGVkIGluZm9ybWF0aW9uKQ1hbmQgZm9yd2FyZGluZyBzZXJ2aWNlcyBzbyBhcyBu b3QgdG8gaW1wYWlyIG9yIGxpbWl0IHRoZQ1uZXR3b3JrJ3MgY2VudHJhbCB0cmFmZmljIGZsb3cg ZnVuY3Rpb24uDQ1JdCBpcyBub3RlZCB0aGF0LCBiZXNpZGVzIHRob3NlIGNhcHR1cmVkIGluIHRo ZSBDSUEgbW9kZWwsIG5vbnJlcHVkaWF0aW9uDWlzIGFub3RoZXIgc2VjdXJpdHkgY29uY2VybiBl dmFsdWF0ZWQuIFdpdGggcmVzcGVjdCB0bw1yb3V0aW5nLCBub24tcmVwdWRpYXRpb24gd2lsbCBp bnZvbHZlIHByb3ZpZGluZyBzb21lIGFiaWxpdHkgdG8gYWxsb3cNdHJhY2VhYmlsaXR5IG9yIG5l dHdvcmsgbWFuYWdlbWVudCByZXZpZXcgb2YgcGFydGljaXBhbnRzIG9mIHRoZQ1yb3V0aW5nIHBy b2Nlc3MgaW5jbHVkaW5nIHRoZSBhYmlsaXR5IHRvIGRldGVybWluZSB0aGUgZXZlbnRzIGFuZA1h Y3Rpb25zIGxlYWRpbmcgdG8gYSBwYXJ0aWN1bGFyIHJvdXRpbmcgc3RhdGUuIE5vbi1yZXB1ZGlh dGlvbg1pbXBsaWVzIGFmdGVyIHRoZSBmYWN0IGFuZCB0aHVzIHJlbGllcyBvbiB0aGUgbG9nZ2lu ZyBvciBvdGhlcg1jYXB0dXJlIG9mIG9uLWdvaW5nIHJvdXRpbmcgZXhjaGFuZ2VzLiBHaXZlbiB0 aGUgbGltaXRlZCByZXNvdXJjZXMNb2YgYSBub2RlIGFuZCBwb3RlbnRpYWxseSB0aGUgY29tbXVu aWNhdGlvbiBjaGFubmVsLCBhbmQgY29uc2lkZXJpbmcNdGhlIG9wZXJhdGluZyBtb2RlIGFzc29j aWF0ZWQgd2l0aCBMTE5zLCByb3V0aW5nIHRyYW5zYWN0aW9uIGxvZ2dpbmcNb3IgYXVkaXRpbmcg cHJvY2VzcyBjb21tdW5pY2F0aW9uIG92ZXJoZWFkIHdpbGwgbm90IGJlIHByYWN0aWNhbDsgYXMN c3VjaCwgbm9uLXJlcHVkaWF0aW9uIGlzIG5vdCBmdXJ0aGVyIGNvbnNpZGVyZWQgYXMgYSByZWxl dmFudCBST0xMDXNlY3VyaXR5IGlzc3VlLg1CYXNlZCB1cG9uIHRoZSBDSUEgbW9kZWwsIGEgaGln aC1sZXZlbCBhc3Nlc3NtZW50IG9mIHRoZSBzZWN1cml0eQ1uZWVkcyBvZiB0aGUgYXNzZXRzIGZv dW5kIGluIFNlY3Rpb24gMy4xIHNob3dzIHRoYXQNbyByb3V0aW5nL3RvcG9sb2d5IGluZm9ybWF0 aW9uIG5lZWRzIHRvIGJlIGludGVncml0eSBwcm90ZWN0ZWQsDW1haW50YWluZWQgd2l0aCBjb25m aWRlbnRpYWxpdHksIGFuZCBwcmV2ZW50ZWQgZnJvbSB1bmF1dGhvcml6ZWQNdXNlOw1vIG5laWdo Ym9yIGRpc2NvdmVyeSBwcm9jZXNzIG5lZWRzIHRvIG9wZXJhdGUgd2l0aG91dCB1bmRlcm1pbmlu Zw1yb3V0aW5nIGF2YWlsYWJpbGl0eTsNbyByb3V0aW5nL3RvcG9sb2d5IGV4Y2hhbmdlIHByb2Nl c3MgbmVlZHMgdG8gZW5zdXJlIHRoYXQgdGhlDXBhcnRpY2lwYW50cyBhcmUgYXV0aGVudGljYXRl ZCwgdGhlIGNvbW11bmljYXRpb24gb2YgaW5mb3JtYXRpb24NaXMgaW50ZWdyaXR5IHByb3RlY3Rl ZCBhbmQgY29uZmlkZW50aWFsOw1vIGNvbW11bmljYXRpb24gY2hhbm5lbHMgYW5kIG5vZGUgcmVz b3VyY2VzIChlLmcuIGF2YWlsYWJsZSANZW5lcmd5KSBuZWVkIHRvIGhhdmUgdGhlaXINIGF2YWls YWJpbGl0eSBtYWludGFpbmVkOw1vIHRoZSBpbnRlcm5hbCBhbmQgZXh0ZXJuYWwgaW50ZXJmYWNl cyBvZiBhIG5vZGUgbmVlZCB0byBiZQ1wcm90ZWN0ZWQgdG8gZW5zdXJlIHRoYXQgaW50ZWdyaXR5 IGFuZCBjb25maWRlbnRpYWxpdHkgb2Ygc3RvcmVkDWluZm9ybWF0aW9uIGlzIG1haW50YWluZWQg YXMgd2VsbCBhcyB0aGUgaW50ZWdyaXR5IG9mIHJvdXRpbmcgYW5kDXJvdXRlIGdlbmVyYXRpb24g cHJvY2Vzc2VzIGlzIGFzc3VyZWQuDQ1FYWNoIGluZGl2aWR1YWwgc3lzdGVtJ3MgdXNlIGFuZCBl bnZpcm9ubWVudCB3aWxsIGRpY3RhdGUgaG93IHRoZQ1hYm92ZSBnZW5lcmFsIGFzc2Vzc21lbnRz IGFyZSBhcHBsaWVkLCBpbmNsdWRpbmcgdGhlIGNob2ljZXMgb2YNc2VjdXJpdHkgc2VydmljZXMg YXMgd2VsbCBhcyB0aGUgc3RyZW5ndGhzIG9mIHRoZSBtZWNoYW5pc21zIHRoYXQNbXVzdCBiZSBp bXBsZW1lbnRlZC4gVGhlIG5leHQgc3Vic2VjdGlvbiBicmluZ3MgTExOLXJlbGF0ZWQgaXNzdWVz DXRvIGxpZ2h0Lg0zLjMuIElzc3VlcyBTcGVjaWZpYyB0byBvciBNYWduaWZpZWQgaW4gTExOcw1G b3VyIG90aGVyIGNvbmN1cnJlbnQgZWZmb3J0cywgW0ktRC5pZXRmLXJvbGwtdXJiYW4tcm91dGlu Zy1yZXFzXSwNW0ktRC5pZXRmLXJvbGwtaW5kdXMtcm91dGluZy1yZXFzXSwNW0ktRC5pZXRmLXJv bGwtaG9tZS1yb3V0aW5nLXJlcXNdLCBhbmQNW0ktRC5pZXRmLXJvbGwtYnVpbGRpbmctcm91dGlu Zy1yZXFzXSwgaGF2ZSBpZGVudGlmaWVkIFJPTEwgc3BlY2lmaWMNcmVxdWlyZW1lbnRzIGFuZCBj b25zdHJhaW50czsgdGhlIGZvbGxvd2luZyBpcyBhIGxpc3Qgb2Ygb2JzZXJ2YXRpb25zDWFuZCBl dmFsdWF0aW9uIG9mIHRoZWlyIGltcGFjdCBvbiByb3V0aW5nIHNlY3VyaXR5IGNvbnNpZGVyYXRp b25zLg1MaW1pdGVkIGVuZXJneSByZXNlcnZlLCBtZW1vcnksIGFuZCBwcm9jZXNzaW5nIHJlc291 cmNlcw1BcyBhIGNvbnNlcXVlbmNlIG9mIHRoZXNlIGNvbnN0cmFpbnRzLCB0aGVyZSBpcyBhbiBl dmVuIG1vcmUNY3JpdGljYWwgbmVlZCB0aGFuIHVzdWFsIGZvciBhIGNhcmVmdWwgdHJhZGUgc3R1 ZHkgb24gd2hpY2ggYW5kDXdoYXQgbGV2ZWwgb2Ygc2VjdXJpdHkgc2VydmljZXMgYXJlIHRvIGJl IGFmZm9yZGVkIGR1cmluZyB0aGUNc3lzdGVtIGRlc2lnbiBwcm9jZXNzLiBJbiBhZGRpdGlvbiwg cm91dGluZyBzY2hlbWVzIGJhc2VkIG9uDXZhcmlvdXMgbWV0cmljcyBoYXZlIGJlZW4gcHJvcG9z ZWQsIGUuZy4sIGdlb2dyYXBoaWMgbG9jYXRpb24uDVRyYW5zbWlzc2lvbiBhbmQgZXhjaGFuZ2lu ZyBzdWNoIG1ldHJpY3MgbWF5IGhhdmUgc2VjdXJpdHkNYW5kL29yIHByaXZhY3kgY29uY2VybnMu DUxhcmdlIHNjYWxlIG9mIHJvbGxlZCBvdXQgbmV0d29yaw1UaGUgcG9zc2libHkgbnVtZXJvdXMg bm9kZXMgdG8gYmUgZGVwbG95ZWQsIGFzIHdlbGwgYXMgdGhlDWdlbmVyYWwgbGV2ZWwgb2YgZXhw ZXJ0aXNlIG9mIHRoZSBpbnN0YWxsZXJzLCBtYWtlIG1hbnVhbCBvbnNpdGUNY29uZmlndXJhdGlv biB1bmxpa2VseS4gUHJvbG9uZ2VkIHJvbGxvdXQgYW5kIGRlbGF5ZWQNYWRkaXRpb24gb2Ygbm9k ZXMsIHdoaWNoIG1heSBiZSBmcm9tIG9sZCBpbnZlbnRvcnksIG92ZXIgdGhlDWxpZmV0aW1lIG9m IHRoZSBuZXR3b3JrLCBhbHNvIGNvbXBsaWNhdGUgdGhlIG9wZXJhdGlvbnMgb2Yga2V5DW1hbmFn ZW1lbnQuDQ1BdXRvbm9tb3VzIG9wZXJhdGlvbnMNU2VsZi1mb3JtaW5nIGFuZCBzZWxmLW9yZ2Fu aXppbmcgYXJlIGNvbW1vbmx5IHByZXNjcmliZWQNcmVxdWlyZW1lbnRzIG9mIFJPTEwuIEluIG90 aGVyIHdvcmRzLCBhIFJPTEwgcHJvdG9jb2wgbmVlZHMgdG8NY29udGFpbiBlbGVtZW50cyBvZiBh ZCBob2MgbmV0d29ya2luZyBhbmQgY2Fubm90IHJlbHkgb24gbWFudWFsDWNvbmZpZ3VyYXRpb24g Zm9yIGluaXRpYWxpemF0aW9uIG9yIGxvY2FsIGZpbHRlcmluZyBydWxlcy4NSGlnaGx5IGRpcmVj dGlvbmFsIHRyYWZmaWMNU29tZSB0eXBlcyBvZiBMTE5zIHNlZSBhIGhpZ2ggcGVyY2VudGFnZSBv ZiB0aGVpciB0b3RhbCB0cmFmZmljDXRyYXZlcnNlIGJldHdlZW4gdGhlIG5vZGVzIGFuZCB0aGUg Z2F0ZXdheXMgd2hlcmUgdGhlIExMTnMNY29ubmVjdCB0byB3aXJlZCBuZXR3b3Jrcy4gVGhlIHNw ZWNpYWwgcm91dGluZyBzdGF0dXMgb2YgYW5kDXRoZSBncmVhdGVyIHZvbHVtZSBvZiB0cmFmZmlj IG5lYXIgdGhlIGdhdGV3YXlzIGhhdmUgcm91dGluZw1zZWN1cml0eSBjb25zZXF1ZW5jZXMuDVVu YXR0ZW5kZWQgbG9jYXRpb25zIGFuZCBsaW1pdGVkIHBoeXNpY2FsIHNlY3VyaXR5DU1hbnkgYXBw bGljYXRpb25zIGhhdmUgdGhlIG5vZGVzIGRlcGxveWVkIGluIHVuYXR0ZW5kZWQgb3INcmVtb3Rl IGxvY2F0aW9uczsgZnVydGhlcm1vcmUsIHRoZSBub2RlcyB0aGVtc2VsdmVzIGFyZSBvZnRlbg1i dWlsdCB3aXRoIG1pbmltYWwgcGh5c2ljYWwgcHJvdGVjdGlvbi4gVGhlc2UgY29uc3RyYWludHMN bG93ZXIgdGhlIGJhcnJpZXIgb2YgYWNjZXNzaW5nIHRoZSBkYXRhIG9yIHNlY3VyaXR5IG1hdGVy aWFsDXN0b3JlZCBvbiB0aGUgbm9kZXMgdGhyb3VnaCBwaHlzaWNhbCBtZWFucy4NDVN1cHBvcnQg Zm9yIG1vYmlsaXR5DU9uIHRoZSBvbmUgaGFuZCwgb25seSBhIG51bWJlciBvZiBhcHBsaWNhdGlv bnMgcmVxdWlyZSB0aGUNc3VwcG9ydCBvZiBtb2JpbGUgbm9kZXMsIGUuZy4sIGEgaG9tZSBMTE4g dGhhdCBpbmNsdWRlcyBub2Rlcw1vbiB3ZWFyYWJsZSBoZWFsdGggY2FyZSBkZXZpY2VzIG9yIGFu IGluZHVzdHJ5IExMTiB0aGF0DWluY2x1ZGVzIG5vZGVzIG9uIGNyYW5lcyBhbmQgdmVoaWNsZXMu IE9uIHRoZSBvdGhlciBoYW5kLCBpZiBhDXJvdXRpbmcgcHJvdG9jb2wgaXMgaW5kZWVkIHVzZWQg aW4gc3VjaCBhcHBsaWNhdGlvbnMsIGl0IHdpbGwNY2xlYXJseSBuZWVkIHRvIGhhdmUgY29ycmVz cG9uZGluZyBzZWN1cml0eSBtZWNoYW5pc21zLg1TdXBwb3J0IGZvciBtdWx0aWNhc3QgYW5kIGFu eWNhc3QNUk9MTCBzdXBwb3J0IGZvciBtdWx0aWNhc3QgYW5kIGFueWNhc3QgaXMgY2FsbGVkIG91 dCBjaGllZmx5DWZvciBsYXJnZS1zY2FsZSBuZXR3b3Jrcy4gQXMgdGhlc2UgYXJlIHJlbGF0aXZl bHkgbmV3IHJvdXRpbmcNdGVjaG5vbG9naWVzLCB0aGVyZSBoYXMgYmVlbiBhbiBvbmdvaW5nIGVm Zm9ydCBkZXZvdGVkIHRvIHRoZWlyDXNlY3VyaXR5IG1lY2hhbmlzbXMsIGUuZy4sIGZyb20gdGhl IElFVEYgTXVsdGljYXN0IFNlY3VyaXR5DXdvcmtpbmcgZ3JvdXAuIEhvd2V2ZXIsIHRoZSB0aHJl YXQgbW9kZWwgYW5kIGF0dGFjayBhbmFseXNpcw1hcmUgc3RpbGwgYXJlYXMgbm90IGZ1bGx5IGV2 YWx1YXRlZCwgYW5kIGhlbmNlIHRoZWlyIGltcGFjdCBpcw1ub3QgeWV0IGZ1bGx5IHVuZGVyc3Rv b2QsIHdoZXRoZXIgaW4gYSB3aXJlZCwgd2lyZWxlc3MsIG9yIExMTi4NVGhlIGFib3ZlIGxpc3Qg Y29uc2lkZXJzIGhvdyBhIExMTidzIHBoeXNpY2FsIGNvbnN0cmFpbnRzLCBzaXplLA1vcGVyYXRp b25zLCBhbmQgdmFyaWV0aWVzIG9mIGFwcGxpY2F0aW9uIGFyZWFzIG1heSBpbXBhY3Qgc2VjdXJp dHkuDUl0IGlzIG5vdGVkIGhlcmUgYWxzbyB0aGF0IExMTnMgY29tbW9ubHkgaGF2ZSB0aGUgbWFq b3JpdHksIGlmIG5vdA1hbGwsIG9mIHRoZWlyIG5vZGVzIGVxdWlwcGVkIHRvIHJvdXRlLiBPbmUg b2YgdGhlIGNvbnNlcXVlbmNlcyBpcw10aGF0IHRoZSBkaXN0aW5jdGlvbiBiZXR3ZWVuIHRoZSBs aW5rIGFuZCBuZXR3b3JrIGxheWVycyBiZWNvbWUNYXJ0aWZpY2lhbCBpbiBzb21lIHJlc3BlY3Rz LiBTaW1pbGFybHksIHRoZSBkaXN0aW5jdGlvbiBiZXR3ZWVuIGENaG9zdCBhbmQgYSByb3V0ZXIg aXMgYmx1cnJlZCwgZXNwZWNpYWxseSB3aGVuIHRoZSBzZXQgb2YgYXBwbGljYXRpb25zDXJ1bm5p bmcgb24gYSBub2RlIGlzIHNtYWxsLiBUaGUgY29udGludWVkIGV2b2x1dGlvbiBvZiBST0xMIGFu ZCBpdHMNc2VjdXJpdHkgZnVuY3Rpb25hbGl0eSByZXF1aXJlbWVudHMgbmVlZCBjbG9zZSBhdHRl bnRpb24uDQ00LiBUaHJlYXRzIGFuZCBBdHRhY2tzDVRoaXMgc2VjdGlvbiBvdXRsaW5lcyBnZW5l cmFsIGNhdGVnb3JpZXMgb2YgdGhyZWF0cyB1bmRlciB0aGUgQ0lBDW1vZGVsIGFuZCBoaWdobGln aHRzIHRoZSBzcGVjaWZpYyBhdHRhY2tzIGluIGVhY2ggb2YgdGhlc2UgY2F0ZWdvcmllcw1mb3Ig Uk9MTC4gQXMgZGVmaW5lZCBpbiBbUkZDNDk0OV0sIGEgdGhyZWF0IGlzICJhIHBvdGVudGlhbCBm b3INdmlvbGF0aW9uIG9mIHNlY3VyaXR5LCB3aGljaCBleGlzdHMgd2hlbiB0aGVyZSBpcyBhIGNp cmN1bXN0YW5jZSwNY2FwYWJpbGl0eSwgYWN0aW9uLCBvciBldmVudCB0aGF0IGNvdWxkIGJyZWFj aCBzZWN1cml0eSBhbmQgY2F1c2UNaGFybS4iIEFuIGF0dGFjayBpcyAiYW4gYXNzYXVsdCBvbiBz eXN0ZW0gc2VjdXJpdHkgdGhhdCBkZXJpdmVzIGZyb20NYW4gaW50ZWxsaWdlbnQgdGhyZWF0LCBp LmUuLCBhbiBpbnRlbGxpZ2VudCBhY3QgdGhhdCBpcyBhIGRlbGliZXJhdGUNYXR0ZW1wdCAoZXNw ZWNpYWxseSBpbiB0aGUgc2Vuc2Ugb2YgYSBtZXRob2Qgb3IgdGVjaG5pcXVlKSB0byBldmFkZQ1z ZWN1cml0eSBzZXJ2aWNlcyBhbmQgdmlvbGF0ZSB0aGUgc2VjdXJpdHkgcG9saWN5IG9mIGEgc3lz dGVtLiINVGhlIHN1YnNlcXVlbnQgc3Vic2VjdGlvbnMgY29uc2lkZXIgdGhlIHRocmVhdHMgYW5k IHRoZWlyIHJlYWxpemluZw1hdHRhY2tzIHRoYXQgY2FuIGNhdXNlIHNlY3VyaXR5IGJyZWFjaGVz IHVuZGVyIHRoZSBDSUEgbW9kZWwgdG8gdGhlDWFzc2V0cyBpZGVudGlmaWVkIGluIFNlY3Rpb24g My4xLiBUaGUgYW5hbHlzaXMgc3RlcHMgdGhyb3VnaCB0aGUNc2VjdXJpdHkgY29uY2VybnMgb2Yg ZWFjaCByb3V0aW5nIGFzc2V0IGFuZCBsb29rcyBhdCB0aGUgYXR0YWNrcyB0aGF0DWNhbiBleHBs b2l0IHBvaW50cyBvZiBhY2Nlc3MuIFRoZSBtYW5pZmVzdGF0aW9uIG9mIHRoZSBhdHRhY2tzIGlz DWFzc3VtZWQgdG8gYmUgZnJvbSBlaXRoZXIgaW5zaWRlIG9yIG91dHNpZGUgYXR0YWNrZXJzLCB3 aG9zZQ1jYXBhYmlsaXRpZXMgbWF5IGJlIGxpbWl0ZWQgdG8gbm9kZS1lcXVpdmFsZW50IG9yIG1v cmUgc29waGlzdGljYXRlZA1jb21wdXRpbmcgcGxhdGZvcm1zLg0NNC4xLiBUaHJlYXRzIGFuZCBB dHRhY2tzIG9uIENvbmZpZGVudGlhbGl0eQ1UaGUgYXNzZXNzbWVudCBpbiBTZWN0aW9uIDMuMiBp bmRpY2F0ZXMgdGhhdCBpbmZvcm1hdGlvbiBhc3NldHMgYXJlDWV4cG9zZWQgdG8gY29uZmlkZW50 aWFsaXR5IHRocmVhdHMgZnJvbSBhbGwgcG9pbnRzIG9mIGFjY2Vzcy4NNC4xLjEuIFJvdXRpbmcg RXhjaGFuZ2UgRXhwb3N1cmUNUm91dGluZyBleGNoYW5nZXMgaW5jbHVkZSBib3RoIHJvdXRpbmcg aW5mb3JtYXRpb24gYXMgd2VsbCBhcw1pbmZvcm1hdGlvbiBhc3NvY2lhdGVkIHdpdGggdGhlIGVz dGFibGlzaG1lbnQgYW5kIG1haW50ZW5hbmNlIG9mDW5laWdoYm9yIHN0YXRlIGluZm9ybWF0aW9u Lg1UaGUgZXhwb3N1cmUgb2Ygcm91dGluZyBpbmZvcm1hdGlvbiBleGNoYW5nZWQgd2lsbCBhbGxv dyB1bmF1dGhvcml6ZWQNc291cmNlcyB0byBnYWluIGFjY2VzcyB0byB0aGUgY29udGVudCBvZiB0 aGUgZXhjaGFuZ2VzIGJldHdlZW4NY29tbXVuaWNhdGluZyBub2Rlcy4gVGhlIGV4cG9zdXJlIG9m IG5laWdoYm9yIHN0YXRlIGluZm9ybWF0aW9uIHdpbGwNYWxsb3cgdW5hdXRob3JpemVkIHNvdXJj ZXMgdG8gZ2FpbiBrbm93bGVkZ2Ugb2YgY29tbXVuaWNhdGlvbiBsaW5rcw1iZXR3ZWVuIHJvdXRp bmcgbm9kZXMgdGhhdCBhcmUgbmVjZXNzYXJ5IHRvIG1haW50YWluIHJvdXRpbmcNaW5mb3JtYXRp b24gZXhjaGFuZ2VzLg1UaGUgZm9ybXMgb2YgYXR0YWNrIHRoYXQgYWxsb3cgdW5hdXRob3JpemVk IGFjY2VzcyBvciBleHBvc3VyZSBvZg1yb3V0aW5nIGV4Y2hhbmdlIGluZm9ybWF0aW9uLCBhcyBy ZXBvcnRlZCBpbiB0aGUgbGl0ZXJhdHVyZSwgaW5jbHVkZQ1vIERlbGliZXJhdGUgZXhwb3N1cmU7 DW8gU25pZmZpbmc7DW8gVHJhZmZpYyBhbmFseXNpcy4NNC4xLjIuIFJvdXRpbmcgSW5mb3JtYXRp b24gKFJvdXRlcyBhbmQgTmV0d29yayBUb3BvbG9neSkgRXhwb3N1cmUNUm91dGVzIGFuZCBuZWln aGJvciB0b3BvbG9neSBpbmZvcm1hdGlvbiBhcmUgdGhlIHByb2R1Y3RzIG9mIHRoZQ1yb3V0aW5n IHByb2Nlc3MgdGhhdCBhcmUgc3RvcmVkIHdpdGhpbiB0aGUgbm9kZSBkZXZpY2UgZGF0YWJhc2Vz Lg1UaGUgZXhwb3N1cmUgb2YgdGhpcyBpbmZvcm1hdGlvbiB3aWxsIGFsbG93IHVuYXV0aG9yaXpl ZCBzb3VyY2VzIHRvDWdhaW4gZGlyZWN0IGFjY2VzcyB0byB0aGUgY29uZmlndXJhdGlvbiBhbmQg Y29ubmVjdGl2aXR5IG9mIHRoZQ1uZXR3b3JrIHRoZXJlYnkgZXhwb3Npbmcgcm91dGluZyB0byB0 YXJnZXRlZCBhdHRhY2tzIG9uIGtleSBub2RlcyBvcg1saW5rcy4gU2luY2Ugcm91dGVzIGFuZCBu ZWlnaGJvciB0b3BvbG9neSBpbmZvcm1hdGlvbiBpcyBzdG9yZWQNd2l0aGluIHRoZSBub2RlIGRl dmljZSwgdGhyZWF0cyBvciBhdHRhY2tzIG9uIHRoZSBjb25maWRlbnRpYWxpdHkgb2YNdGhlIGlu Zm9ybWF0aW9uIHdpbGwgYXBwbHkgdG8gdGhlIHBoeXNpY2FsIGRldmljZSBpbmNsdWRpbmcgc3Bl Y2lmaWVkDWFuZCB1bnNwZWNpZmllZCBpbnRlcm5hbCBhbmQgZXh0ZXJuYWwgaW50ZXJmYWNlcy4N VGhlIGZvcm1zIG9mIGF0dGFjayB0aGF0IGFsbG93IHVuYXV0aG9yaXplZCBhY2Nlc3Mgb3IgZXhw b3N1cmUgb2YgdGhlDXJvdXRpbmcgaW5mb3JtYXRpb24gKG90aGVyIHRoYW4gb2NjdXJyaW5nIHRo cm91Z2ggZXhwbGljaXQgbm9kZQ1leGNoYW5nZXMpIHdpbGwgaW5jbHVkZQ1vIFBoeXNpY2FsIGRl dmljZSBjb21wcm9taXNlOw1vIFJlbW90ZSBkZXZpY2UgYWNjZXNzIGF0dGFja3MgKGluY2x1ZGlu ZyB0aG9zZSBvY2N1cnJpbmcgdGhyb3VnaA1yZW1vdGUgbmV0d29yayBtYW5hZ2VtZW50IG9yIHNv ZnR3YXJlL2ZpZWxkIHVwZ3JhZGUgaW50ZXJmYWNlcykuDU1vcmUgZGV0YWlsZWQgZGVzY3JpcHRp b25zIG9mIHRoZSBleHBvc3VyZSBhdHRhY2tzIG9uIHJvdXRpbmcNZXhjaGFuZ2UgYW5kIGluZm9y bWF0aW9uIHdpbGwgYmUgZ2l2ZW4gaW4gU2VjdGlvbiA1IHRvZ2V0aGVyIHdpdGggdGhlDWNvcnJl c3BvbmRpbmcgY291bnRlcm1lYXN1cmVzLg00LjIuIFRocmVhdHMgYW5kIEF0dGFja3Mgb24gSW50 ZWdyaXR5DVRoZSBhc3Nlc3NtZW50IGluIFNlY3Rpb24gMy4yIGluZGljYXRlcyB0aGF0IGluZm9y bWF0aW9uIGFuZCBpZGVudGl0eQ1hc3NldHMgYXJlIGV4cG9zZWQgdG8gaW50ZWdyaXR5IHRocmVh dHMgZnJvbSBhbGwgcG9pbnRzIG9mIGFjY2Vzcy4NNC4yLjEuIFJvdXRpbmcgSW5mb3JtYXRpb24g TWFuaXB1bGF0aW9uDU1hbmlwdWxhdGlvbiBvZiByb3V0aW5nIGluZm9ybWF0aW9uIHdpbGwgYWxs b3cgdW5hdXRob3JpemVkIHNvdXJjZXMNdG8gaW5mbHVlbmNlIHRoZSBvcGVyYXRpb24gYW5kIGNv bnZlcmdlbmNlIG9mIHRoZSByb3V0aW5nIHByb3RvY29scw1hbmQgdWx0aW1hdGVseSBpbXBhY3Qg dGhlIGZvcndhcmRpbmcgZGVjaXNpb25zIG1hZGUgaW4gdGhlIG5ldHdvcmsuDU1hbmlwdWxhdGlv biBvZiBuZWlnaGJvciBzdGF0ZSAodG9wb2xvZ3kpIGluZm9ybWF0aW9uIHdpbGwgYWxsb3cNdW5h dXRob3JpemVkIHNvdXJjZXMgdG8gaW5mbHVlbmNlIHRoZSBub2RlcyB3aXRoIHdoaWNoIHJvdXRp bmcNaW5mb3JtYXRpb24gaXMgZXhjaGFuZ2VkIGFuZCB1cGRhdGVkLiBUaGUgY29uc2VxdWVuY2Ug b2YNbWFuaXB1bGF0aW5nIHJvdXRpbmcgZXhjaGFuZ2VzIGNhbiB0aHVzIGxlYWQgdG8gc3ViLW9w dGltYWxpdHkgYW5kDWZyYWdtZW50YXRpb24gb3IgcGFydGl0aW9uaW5nIG9mIHRoZSBuZXR3b3Jr IGJ5IHJlc3RyaWN0aW5nIHRoZQ11bml2ZXJzZSBvZiByb3V0ZXJzIHdpdGggd2hpY2ggYXNzb2Np YXRpb25zIGNhbiBiZSBlc3RhYmxpc2hlZCBhbmQNbWFpbnRhaW5lZC4NVGhlIGZvcm1zIG9mIGF0 dGFjayB0aGF0IGFsbG93IG1hbmlwdWxhdGlvbiBvZiByb3V0aW5nIGluZm9ybWF0aW9uDWluY2x1 ZGUNbyBGYWxzaWZpY2F0aW9uLCBpbmNsdWRpbmcgb3ZlcmNsYWltaW5nIGFuZCBtaXNjbGFpbWlu ZzsNbyBSb3V0aW5nIGluZm9ybWF0aW9uIHJlcGxheTsNbyBQaHlzaWNhbCBkZXZpY2UgY29tcHJv bWlzZS4NNC4yLjIuIE5vZGUgSWRlbnRpdHkgTWlzYXBwcm9wcmlhdGlvbg1GYWxzaWZpY2F0aW9u IG9yIG1pc2FwcHJvcHJpYXRpb24gb2Ygbm9kZSBpZGVudGl0eSBiZXR3ZWVuIHJvdXRpbmcNcGFy dGljaXBhbnRzIG9wZW5zIHRoZSBkb29yIGZvciBvdGhlciBhdHRhY2tzOyBpdCBjYW4gYWxzbyBj YXVzZQ1pbmNvcnJlY3Qgcm91dGluZyByZWxhdGlvbnNoaXBzIHRvIGZvcm0gYW5kL29yIHRvcG9s b2dpZXMgdG8gZW1lcmdlLg1Sb3V0aW5nIGF0dGFja3MgbWF5IGFsc28gYmUgbW91bnRlZCB0aHJv dWdoIGxlc3Mgc29waGlzdGljYXRlZCBub2RlDWlkZW50aXR5IG1pc2FwcHJvcHJpYXRpb24gaW4g d2hpY2ggdGhlIHZhbGlkIGluZm9ybWF0aW9uIGJyb2FkY2FzdCBvcg1leGNoYW5nZWQgYnkgYSBu b2RlIGlzIHJlcGxheWVkIHdpdGhvdXQgbW9kaWZpY2F0aW9uLiBUaGUgcmVjZWlwdCBvZg1zZWVt aW5nbHkgdmFsaWQgaW5mb3JtYXRpb24gdGhhdCBpcyBob3dldmVyIG5vIGxvbmdlciBjdXJyZW50 IGNhbg1yZXN1bHQgaW4gcm91dGluZyBkaXNydXB0aW9uLCBhbmQgaW5zdGFiaWxpdHkgKGluY2x1 ZGluZyBmYWlsdXJlIHRvDWNvbnZlcmdlKS4gV2l0aG91dCBtZWFzdXJlcyB0byBhdXRoZW50aWNh dGUgdGhlIHJvdXRpbmcgcGFydGljaXBhbnRzDWFuZCB0byBlbnN1cmUgdGhlIGZyZXNobmVzcyBh bmQgdmFsaWRpdHkgb2YgdGhlIHJlY2VpdmVkIGluZm9ybWF0aW9uDXRoZSBwcm90b2NvbCBvcGVy YXRpb24gY2FuIGJlIGNvbXByb21pc2VkLiBUaGUgZm9ybXMgb2YgYXR0YWNrIHRoYXQNbWlzdXNl IG5vZGUgaWRlbnRpdHkgaW5jbHVkZQ1vIElkZW50aXR5IChpbmNsdWRpbmcgU3liaWwpIGF0dGFj a3M7DW8gUm91dGluZyBpbmZvcm1hdGlvbiByZXBsYXkuDTQuMy4gVGhyZWF0cyBhbmQgQXR0YWNr cyBvbiBBdmFpbGFiaWxpdHkNVGhlIGFzc2Vzc21lbnQgaW4gU2VjdGlvbiAzLjIgaW5kaWNhdGVz IHRoYXQgdGhlIHByb2Nlc3MgYW5kDXJlc291cmNlcyBhc3NldHMgYXJlIGV4cG9zZWQgdG8gYXZh aWxhYmlsaXR5IHRocmVhdHM7IGF0dGFja3Mgb2YgdGhpcw1jYXRlZ29yeSBtYXkgZXhwbG9pdCBk aXJlY3RseSBvciBpbmRpcmVjdGx5IGluZm9ybWF0aW9uIGV4Y2hhbmdlIG9yDWZvcndhcmRpbmcu DTQuMy4xLiBSb3V0aW5nIEV4Y2hhbmdlIEludGVyZmVyZW5jZSBvciBEaXNydXB0aW9uDUludGVy ZmVyZW5jZSBvciBkaXNydXB0aW9uIG9mIHJvdXRpbmcgaW5mb3JtYXRpb24gZXhjaGFuZ2VzIHdp bGwNYWxsb3cgdW5hdXRob3JpemVkIHNvdXJjZXMgdG8gaW5mbHVlbmNlIHRoZSBvcGVyYXRpb24g YW5kIGNvbnZlcmdlbmNlDW9mIHRoZSByb3V0aW5nIHByb3RvY29scyBieSBpbXBlZGluZyB0aGUg cmVndWxhcml0eSBvZiByb3V0aW5nDWluZm9ybWF0aW9uIGV4Y2hhbmdlLg1UaGUgZm9ybXMgb2Yg YXR0YWNrIHRoYXQgYWxsb3cgaW50ZXJmZXJlbmNlIG9yIGRpc3J1cHRpb24gb2Ygcm91dGluZw1l eGNoYW5nZSBpbmNsdWRlDW8gUm91dGluZyBpbmZvcm1hdGlvbiByZXBsYXk7DW8gSEVMTE8gZmxv b2QgYXR0YWNrcyBhbmQgQUNLIHNwb29maW5nOw1vIE92ZXJsb2FkIGF0dGFja3MuDTQuMy4yLiBO ZXR3b3JrIFRyYWZmaWMgRm9yd2FyZGluZyBEaXNydXB0aW9uDVRoZSBkaXNydXB0aW9uIG9mIHRo ZSBuZXR3b3JrIHRyYWZmaWMgZm9yd2FyZGluZyBjYXBhYmlsaXR5IG9mIHRoZQ1uZXR3b3JrIHdp bGwgdW5kZXJtaW5lIHRoZSBjZW50cmFsIGZ1bmN0aW9uIG9mIG5ldHdvcmsgcm91dGVycyBhbmQN dGhlIGFiaWxpdHkgdG8gaGFuZGxlIHVzZXIgdHJhZmZpYy4gVGhpcyB0aHJlYXQgYW5kIHRoZSBh c3NvY2lhdGVkDWF0dGFja3MgYWZmZWN0IHRoZSBhdmFpbGFiaWxpdHkgb2YgdGhlIG5ldHdvcmsg YmVjYXVzZSBvZiB0aGUNcG90ZW50aWFsIHRvIGltcGFpciB0aGUgcHJpbWFyeSBjYXBhYmlsaXR5 IG9mIHRoZSBuZXR3b3JrLg1UaGUgZm9ybXMgb2YgYXR0YWNrIHRoYXQgYWxsb3dzIGRpc3J1cHRp b24gb2YgbmV0d29yayB0cmFmZmljDWZvcndhcmRpbmcgaW5jbHVkZQ1vIFNlbGVjdGl2ZSBmb3J3 YXJkaW5nIGF0dGFja3M7DW8gU2lua2hvbGUgYXR0YWNrczsNbyBXb3JtaG9sZSBhdHRhY2tzLg00 LjMuMy4gQ29tbXVuaWNhdGlvbnMgUmVzb3VyY2UgRGlzcnVwdGlvbg1BdHRhY2tzIG1vdW50ZWQg YWdhaW5zdCB0aGUgY29tbXVuaWNhdGlvbiBjaGFubmVsIHJlc291cmNlIGFzc2V0cw1uZWVkZWQg YnkgdGhlIHJvdXRpbmcgcHJvdG9jb2wgY2FuIGJlIHVzZWQgYXMgYSBtZWFucyBvZiBkaXNydXB0 aW5nDWl0cyBvcGVyYXRpb24uIEhvd2V2ZXIsIHdoaWxlIHZhcmlvdXMgZm9ybXMgb2YgRGVuaWFs IG9mIFNlcnZpY2UNKERvUykgYXR0YWNrcyBvbiB0aGUgdW5kZXJseWluZyB0cmFuc3BvcnQgc3Vi c3lzdGVtIHdpbGwgYWZmZWN0DXJvdXRpbmcgcHJvdG9jb2wgZXhjaGFuZ2VzIGFuZCBvcGVyYXRp b24gKGZvciBleGFtcGxlIHBoeXNpY2FsIGxheWVyDVJGIGphbW1pbmcgaW4gYSB3aXJlbGVzcyBu ZXR3b3JrIG9yIGxpbmsgbGF5ZXIgYXR0YWNrcyksIHRoZXNlDWF0dGFja3MgY2Fubm90IGJlIGNv dW50ZXJlZCBieSB0aGUgcm91dGluZyBwcm90b2NvbC4gQXMgc3VjaCwgdGhlDXRocmVhdHMgdG8g dGhlIHVuZGVybHlpbmcgdHJhbnNwb3J0IG5ldHdvcmsgdGhhdCBzdXBwb3J0cyByb3V0aW5nIGlz DWNvbnNpZGVyZWQgYmV5b25kIHRoZSBzY29wZSBvZiB0aGUgY3VycmVudCBkb2N1bWVudC4gTm9u ZXRoZWxlc3MsDWF0dGFja3Mgb24gdGhlIHN1YnN5c3RlbSB3aWxsIGFmZmVjdCByb3V0aW5nIG9w ZXJhdGlvbiBhbmQgc28gbXVzdCBiZQ1kaXJlY3RseSBhZGRyZXNzZWQgd2l0aGluIHRoZSB1bmRl cmx5aW5nIHN1YnN5c3RlbSBhbmQgaXRzDWltcGxlbWVudGVkIHByb3RvY29sIGxheWVycy4NNC4z LjQuIE5vZGUgUmVzb3VyY2UgRXhoYXVzdGlvbg1BIHBvdGVudGlhbCBzZWN1cml0eSB0aHJlYXQg dG8gcm91dGluZyBjYW4gYXJpc2UgZnJvbSBhdHRlbXB0cyB0bw1leGhhdXN0IHRoZSBub2RlIHJl c291cmNlIGFzc2V0IGJ5IGluaXRpYXRpbmcgZXhjaGFuZ2VzIHRoYXQgY2FuIGxlYWQNdG8gdGhl IHVuZHVlIHV0aWxpemF0aW9uIG9mIGV4aGF1c3Rpb24gb2YgcHJvY2Vzc2luZywgbWVtb3J5IG9y DWVuZXJneSByZXNvdXJjZXMuIFRoZSBlc3RhYmxpc2htZW50IGFuZCBtYWludGVuYW5jZSBvZiBy b3V0aW5nDW5laWdoYm9ycyBvcGVucyB0aGUgcm91dGluZyBwcm9jZXNzIHRvIGVuZ2FnZW1lbnQg YW5kIHBvdGVudGlhbA1hY2NlcHRhbmNlIG9mIG11bHRpcGxlIG5laWdoYm9yaW5nIHBlZXJzLiBB c3NvY2lhdGlvbiBpbmZvcm1hdGlvbg1tdXN0IGJlIHN0b3JlZCBmb3IgZWFjaCBwZWVyIGVudGl0 eSBhbmQgZm9yIHRoZSB3aXJlbGVzcyBuZXR3b3JrDW9wZXJhdGlvbiBwcm92aXNpb25zIG1hZGUg dG8gcGVyaW9kaWNhbGx5IHVwZGF0ZSBhbmQgcmVhc3Nlc3MgdGhlDWFzc29jaWF0aW9ucy4gQW4g aW50cm9kdWNlZCBwcm9saWZlcmF0aW9uIG9mIGFwcGFyZW50IHJvdXRpbmcgcGVlcnMNY2FuIHRo ZXJlZm9yZSBoYXZlIGEgbmVnYXRpdmUgaW1wYWN0IG9uIG5vZGUgcmVzb3VyY2VzLg1Ob2RlIHJl c291cmNlcyBtYXkgYWxzbyBiZSB1bmR1bHkgY29uc3VtZWQgYnkgdGhlIGF0dGFja2Vycw1hdHRl bXB0aW5nIHVuY29udHJvbGxlZCB0b3BvbG9neSBwZWVyaW5nIG9yIHJvdXRpbmcgZXhjaGFuZ2Vz LA1yb3V0aW5nIHJlcGxheXMsIG9yIHRoZSBnZW5lcmF0aW5nIG9mIG90aGVyIGRhdGEgdHJhZmZp YyBmbG9vZHMuDUJleW9uZCB0aGUgZGlzcnVwdGlvbiBvZiBjb21tdW5pY2F0aW9ucyBjaGFubmVs IHJlc291cmNlcywgdGhlc2UNdGhyZWF0cyBtYXkgYmUgYWJsZSB0byBleGhhdXN0IG5vZGUgcmVz b3VyY2VzIG9ubHkgd2hlcmUgdGhlDWVuZ2FnZW1lbnRzIGFyZSBhYmxlIHRvIHByb2NlZWQgd2l0 aCB0aGUgcGVlciByb3V0aW5nIGVudGl0aWVzLg1Sb3V0aW5nIG9wZXJhdGlvbiBhbmQgbmV0d29y ayBmb3J3YXJkaW5nIGZ1bmN0aW9ucyBjYW4gdGh1cyBiZQ1hZHZlcnNlbHkgaW1wYWN0ZWQgYnkg bm9kZSByZXNvdXJjZXMgZXhoYXVzdGlvbiB0aGF0IHN0ZW1zIGZyb20NYXR0YWNrcyB0aGF0IGlu Y2x1ZGUNbyBJZGVudGl0eSAoaW5jbHVkaW5nIFN5YmlsKSBhdHRhY2tzOw1vIFJvdXRpbmcgaW5m b3JtYXRpb24gcmVwbGF5IGF0dGFja3M7DW8gSEVMTE8gZmxvb2QgYXR0YWNrcyBhbmQgQUNLIHNw b29maW5nOw1vIE92ZXJsb2FkIGF0dGFja3MuDTUuIENvdW50ZXJtZWFzdXJlcw1CeSByZWNvZ25p emluZyB0aGUgY2hhcmFjdGVyaXN0aWNzIG9mIExMTnMgdGhhdCBtYXkgaW1wYWN0IHJvdXRpbmcN YW5kIGlkZW50aWZ5aW5nIHBvdGVudGlhbCBjb3VudGVybWVhc3VyZXMsIHRoaXMgZnJhbWV3b3Jr IHByb3ZpZGVzDXRoZSBiYXNpcyBmb3IgZGV2ZWxvcGluZyBjYXBhYmlsaXRpZXMgd2l0aGluIFJP TEwgcHJvdG9jb2xzIHRvIGRldGVyDXRoZSBpZGVudGlmaWVkIGF0dGFja3MgYW5kIG1pdGlnYXRl IHRoZSB0aHJlYXRzLiBUaGUgZm9sbG93aW5nDXN1YnNlY3Rpb25zIGNvbnNpZGVyIHN1Y2ggY291 bnRlcm1lYXN1cmVzIGJ5IGdyb3VwaW5nIHRoZSBhdHRhY2tzDUludGVybmV0LURyYWZ0IFNlY3Vy aXR5IEZyYW1ld29yayBmb3IgUk9MTCBGZWJydWFyeSAyMDA5DWFjY29yZGluZyB0byB0aGUgY2xh c3NpZmljYXRpb24gb2YgdGhlIENJQSBtb2RlbCBzbyB0aGF0IGFzc29jaWF0aW9ucw13aXRoIHRo ZSBuZWNlc3Nhcnkgc2VjdXJpdHkgc2VydmljZXMgYXJlIG1vcmUgcmVhZGlseSB2aXNpYmxlLg01 LjEuIENvbmZpZGVudGlhbGl0eSBBdHRhY2sgQ291bnRlcm1lYXN1cmVzDUF0dGFja3Mgb24gY29u ZmlkZW50aWFsaXR5IG1heSBiZSBtb3VudGVkIGF0IHRoZSBsZXZlbCBvZiB0aGUgcm91dGluZw1p bmZvcm1hdGlvbiBhc3NldHMsIGF0IHRoZSBwb2ludHMgb2YgYWNjZXNzIGFzc29jaWF0ZWQgd2l0 aCByb3V0aW5nDWV4Y2hhbmdlcyBiZXR3ZWVuIG5vZGVzLCBvciB0aHJvdWdoIGRldmljZSBpbnRl cmZhY2UgYWNjZXNzLiBUbyBnYWluDWFjY2VzcyB0byByb3V0aW5nL3RvcG9sb2d5IGluZm9ybWF0 aW9uLCB0aGUgYXR0YWNrZXIgbWF5IHJlbHkgb24gYQ1jb21wcm9taXNlZCBub2RlIHRoYXQgZGVs aWJlcmF0ZWx5IGV4cG9zZXMgdGhlIGluZm9ybWF0aW9uIGR1cmluZyB0aGUNcm91dGluZyBleGNo YW5nZSBwcm9jZXNzLCBtYXkgcmVseSBvbiBwYXNzaXZlIHNuaWZmaW5nIG9yIGFuYWx5c2lzIG9m DXJvdXRpbmcgdHJhZmZpYywgb3IgbWF5IGF0dGVtcHQgYWNjZXNzIHRocm91Z2ggYSBjb21wb25l bnQgb3IgZGV2aWNlDWludGVyZmFjZSBvZiBhIHRhbXBlcmVkIHJvdXRpbmcgbm9kZS4NNS4xLjEu IENvdW50ZXJpbmcgRGVsaWJlcmF0ZSBFeHBvc3VyZSBBdHRhY2tzDUEgZGVsaWJlcmF0ZSBleHBv c3VyZSBhdHRhY2sgaXMgb25lIGluIHdoaWNoIGFuIGVudGl0eSB0aGF0IGlzIHBhcnR5DXRvIHRo ZSByb3V0aW5nIHByb2Nlc3Mgb3IgdG9wb2xvZ3kgZXhjaGFuZ2UgYWxsb3dzIHRoZSByb3V0aW5n Lw10b3BvbG9neSBpbmZvcm1hdGlvbiBvciBnZW5lcmF0ZWQgcm91dGUgaW5mb3JtYXRpb24gdG8g YmUgZXhwb3NlZCB0bw1hbiB1bmF1dGhvcml6ZWQgZW50aXR5IGR1cmluZyB0aGUgZXhjaGFuZ2Uu DUEgcHJlcmVxdWlzaXRlIHRvIGNvdW50ZXJpbmcgdGhpcyB0eXBlIG9mIGNvbmZpZGVudGlhbGl0 eSBhdHRhY2tzDWFzc29jaWF0ZWQgd2l0aCB0aGUgcm91dGluZy90b3BvbG9neSBleGNoYW5nZSBp cyB0byBlbnN1cmUgdGhhdCB0aGUNY29tbXVuaWNhdGluZyBub2RlcyBhcmUgYXV0aGVudGljYXRl ZCBwcmlvciB0byBkYXRhIGVuY3J5cHRpb24NYXBwbGllZCBpbiB0aGUgcm91dGluZyBleGNoYW5n ZS4gQXV0aGVudGljYXRpb24gZW5zdXJlcyB0aGF0IHRoZQ1ub2RlcyBhcmUgd2hvIHRoZXkgY2xh aW0gdG8gYmUgZXZlbiB0aG91Z2ggaXQgZG9lcyBub3QgcHJvdmlkZSBhbg1pbmRpY2F0aW9uIG9m IHdoZXRoZXIgdGhlIG5vZGUgaGFzIGJlZW4gY29tcHJvbWlzZWQuDVRvIHByZXZlbnQgZGVsaWJl cmF0ZSBleHBvc3VyZSwgdGhlIHByb2Nlc3MgdGhhdCBjb21tdW5pY2F0aW5nIG5vZGVzDXVzZSBm b3IgZXN0YWJsaXNoaW5nIGNvbW11bmljYXRpb24gc2Vzc2lvbiBrZXlzIG11c3QgYmUgc3ltbWV0 cmljIGF0DWVhY2ggbm9kZSBzbyB0aGF0IG5laXRoZXIgbm9kZSBjYW4gaW5kZXBlbmRlbnRseSB3 ZWFrZW4gdGhlDWNvbmZpZGVudGlhbGl0eSBvZiB0aGUgZXhjaGFuZ2Ugd2l0aG91dCB0aGUga25v d2xlZGdlIG9mIGl0cw1jb21tdW5pY2F0aW5nIHBlZXIuIEEgZGVsaWJlcmF0ZSBleHBvc3VyZSBh dHRhY2sgd2lsbCB0aGVyZWZvcmUNcmVxdWlyZSBtb3JlIG92ZXJ0IGFuZCBpbmRlcGVuZGVudCBh Y3Rpb24gb24gdGhlIHBhcnQgb2YgdGhlDW9mZmVuZGluZyBub2RlLg1Ob3RlIHRoYXQgdGhlIHNh bWUgbWVhc3VyZXMgd2hpY2ggYXBwbHkgdG8gc2VjdXJpbmcgcm91dGluZy90b3BvbG9neQ1leGNo YW5nZXMgYmV0d2VlbiBvcGVyYXRpb25hbCBub2RlcyBtdXN0IGFsc28gZXh0ZW5kIHRvIGZpZWxk IHRvb2xzDWFuZCBvdGhlciBkZXZpY2VzIHVzZWQgaW4gYSBkZXBsb3llZCBuZXR3b3JrIHdoZXJl IHN1Y2ggZGV2aWNlcyBjYW4NYmUgY29uZmlndXJlZCB0byBwYXJ0aWNpcGF0ZSBpbiByb3V0aW5n IGV4Y2hhbmdlcy4NNS4xLjIuIENvdW50ZXJpbmcgU25pZmZpbmcgQXR0YWNrcw1BIHNuaWZmaW5n IGF0dGFjayBzZWVrcyB0byBicmVhY2ggcm91dGluZyBjb25maWRlbnRpYWxpdHkgdGhyb3VnaA1w YXNzaXZlLCBkaXJlY3QgYW5hbHlzaXMgYW5kIHByb2Nlc3Npbmcgb2YgdGhlIGluZm9ybWF0aW9u IGV4Y2hhbmdlcw1iZXR3ZWVuIG5vZGVzLiBBIHNuaWZmaW5nIGF0dGFjayBpbiBhbiBMTE4gdGhh dCBpcyBub3QgYmFzZWQgb24gYQ1waHlzaWNhbCBkZXZpY2UgY29tcHJvbWlzZSB3aWxsIHJlbHkg b24gdGhlIGF0dGFja2VyIGF0dGVtcHRpbmcgdG8NZGlyZWN0bHkgZGVyaXZlIGluZm9ybWF0aW9u IGZyb20gdGhlIG92ZXItdGhlLWFpciByb3V0aW5nL3RvcG9sb2d5DWNvbW11bmljYXRpb24gZXhj aGFuZ2UgKG5laWdoYm9yIGRpc2NvdmVyeSBleGNoYW5nZXMgbWF5IG9mIG5lY2Vzc2l0eQ1iZSBj b25kdWN0ZWQgaW4gdGhlIGNsZWFyIHRodXMgbGltaXRpbmcgdGhlIGV4dGVudCB0byB3aGljaCB0 aGUNaW5mb3JtYXRpb24gY2FuIGJlIGtlcHQgY29uZmlkZW50aWFsKS4NU25pZmZpbmcgYXR0YWNr cyBjYW4gYmUgZGlyZWN0bHkgY291bnRlcmVkIHRocm91Z2ggdGhlIHVzZSBvZiBkYXRhDWVuY3J5 cHRpb24gZm9yIGFsbCByb3V0aW5nIGV4Y2hhbmdlcy4gT25seSB3aGVuIGEgdmFsaWRhdGVkIGFu ZA1hdXRoZW50aWNhdGVkIG5vZGUgYXNzb2NpYXRpb24gaXMgY29tcGxldGVkIHdpbGwgcm91dGlu ZyBleGNoYW5nZSBiZQ1hbGxvd2VkIHRvIHByb2NlZWQgdXNpbmcgZXN0YWJsaXNoZWQgc2Vzc2lv biBjb25maWRlbnRpYWxpdHkga2V5cyBhbmQNYW4gYWdyZWVkIGNvbmZpZGVudGlhbGl0eSBhbGdv cml0aG0uIFRoZSBsZXZlbCBvZiBzZWN1cml0eSBhcHBsaWVkDWluIHByb3ZpZGluZyBjb25maWRl bnRpYWxpdHkgd2lsbCBkZXRlcm1pbmUgdGhlIG1pbmltdW0gcmVxdWlyZW1lbnQNZm9yIGFuIGF0 dGFja2VyIG1vdW50aW5nIHRoaXMgcGFzc2l2ZSBzZWN1cml0eSBhdHRhY2suIEJlY2F1c2Ugb2YN dGhlIHJlc291cmNlIGNvbnN0cmFpbnRzIG9mIExMTiBkZXZpY2VzLCBzeW1tZXRyaWMgKHByaXZh dGUpIGtleQ1zZXNzaW9uIHNlY3VyaXR5IHdpbGwgcHJvdmlkZSB0aGUgYmVzdCB0cmFkZW9mZiBp biB0ZXJtcyBvZiBub2RlIGFuZA1jaGFubmVsIHJlc291cmNlIG92ZXJoZWFkIGFuZCB0aGUgbGV2 ZWwgb2Ygc2VjdXJpdHkgYWNoaWV2ZWQuIFRoaXMNd2lsbCBvZiBjb3Vyc2Ugbm90IHByZWNsdWRl IHRoZSB1c2Ugb2YgYXN5bW1ldHJpYyAocHVibGljKSBrZXkNZW5jcnlwdGlvbiBkdXJpbmcgdGhl IHNlc3Npb24ga2V5IGVzdGFibGlzaG1lbnQgcGhhc2UuDUFzIHdpdGggdGhlIGtleSBlc3RhYmxp c2htZW50IHByb2Nlc3MsIGRhdGEgZW5jcnlwdGlvbiBtdXN0IGluY2x1ZGUNYW4gYXV0aGVudGlj YXRpb24gcHJlcmVxdWlzaXRlIHRvIGVuc3VyZSB0aGF0IGVhY2ggbm9kZSBpcw1pbXBsZW1lbnRp bmcgYSBsZXZlbCBvZiBzZWN1cml0eSB0aGF0IHByZXZlbnRzIGRlbGliZXJhdGUgb3INaW5hZHZl cnRlbnQgZXhwb3N1cmUuIFRoZSBhdXRoZW50aWNhdGVkIGtleSBlc3RhYmxpc2htZW50IHdpbGwN ZW5zdXJlIHRoYXQgY29uZmlkZW50aWFsaXR5IGlzIG5vdCBjb21wcm9taXNlZCBieSBwcm92aWRp bmcgdGhlDWluZm9ybWF0aW9uIHRvIGFuIHVuYXV0aG9yaXplZCBlbnRpdHkgKHNlZSBhbHNvIFtI dWFuZzIwMDNdKS4NQmFzZWQgb24gdGhlIGN1cnJlbnQgc3RhdGUgb2YgdGhlIGFydCwgYSBtaW5p bXVtIDEyOC1iaXQga2V5IGxlbmd0aA1zaG91bGQgYmUgYXBwbGllZCB3aGVyZSByb2J1c3QgY29u ZmlkZW50aWFsaXR5IGlzIGRlbWFuZGVkIGZvcg1yb3V0aW5nIHByb3RlY3Rpb24uIFRoaXMgc2Vz c2lvbiBrZXkgc2hhbGwgYmUgYXBwbGllZCBpbiBjb25qdW5jdGlvbg13aXRoIGFuIGVuY3J5cHRp b24gYWxnb3JpdGhtIHRoYXQgaGFzIGJlZW4gcHVibGljbHkgdmV0dGVkIGFuZCB3aGVyZQ1hcHBs aWNhYmxlIGFwcHJvdmVkIGZvciB0aGUgbGV2ZWwgb2Ygc2VjdXJpdHkgZGVzaXJlZC4gQWxnb3Jp dGhtcw1zdWNoIGFzIEFFUyAoYWRvcHRlZCBieSB0aGUgVS5TLiBnb3Zlcm5tZW50KSBvciBLYXN1 bWktTWlzdHkgKGFkb3B0ZWQNYnkgdGhlIDNHUFAgM3JkIGdlbmVyYXRpb24gd2lyZWxlc3MgbW9i aWxlIGNvbnNvcnRpdW0pIGFyZSBleGFtcGxlcw1vZiBzeW1tZXRyaWMta2V5IGFsZ29yaXRobXMg Y2FwYWJsZSBvZiBlbnN1cmluZyByb2J1c3QNY29uZmlkZW50aWFsaXR5IGZvciByb3V0aW5nIGV4 Y2hhbmdlcy4gVGhlIGtleSBsZW5ndGgsIGFsZ29yaXRobSBhbmQNbW9kZSBvZiBvcGVyYXRpb24g d2lsbCBiZSBzZWxlY3RlZCBhcyBwYXJ0IG9mIHRoZSBvdmVyYWxsIHNlY3VyaXR5DXRyYWRlb2Zm IHRoYXQgYWxzbyBhY2hpZXZlcyBhIGJhbGFuY2Ugd2l0aCB0aGUgbGV2ZWwgb2YNY29uZmlkZW50 aWFsaXR5IGFmZm9yZGVkIGJ5IHRoZSBwaHlzaWNhbCBkZXZpY2UgaW4gcHJvdGVjdGluZyB0aGUN cm91dGluZyBhc3NldHMgKHNlZSBTZWN0aW9uIDUuMS40IGJlbG93KS4NQXMgd2l0aCBhbnkgZW5j cnlwdGlvbiBhbGdvcml0aG0sIHRoZSB1c2Ugb2YgY2lwaGVyaW5nDXN5bmNocm9uaXphdGlvbiBw YXJhbWV0ZXJzIGFuZCBsaW1pdGF0aW9ucyB0byB0aGUgdXNhZ2UgZHVyYXRpb24gb2YNZXN0YWJs aXNoZWQga2V5cyBzaG91bGQgYmUgcGFydCBvZiB0aGUgc2VjdXJpdHkgc3BlY2lmaWNhdGlvbiB0 bw1yZWR1Y2UgdGhlIHBvdGVudGlhbCBmb3IgYnJ1dGUgZm9yY2UgYW5hbHlzaXMuDTUuMS4zLiBD b3VudGVyaW5nIFRyYWZmaWMgQW5hbHlzaXMNVHJhZmZpYyBhbmFseXNpcyBwcm92aWRlcyBhbiBp bmRpcmVjdCBtZWFucyBvZiBzdWJ2ZXJ0aW5nDWNvbmZpZGVudGlhbGl0eSBhbmQgZ2FpbmluZyBh Y2Nlc3MgdG8gcm91dGluZyBpbmZvcm1hdGlvbiBieSBhbGxvd2luZw1hbiBhdHRhY2tlciB0byBp bmRpcmVjdGx5IG1hcCB0aGUgY29ubmVjdGl2aXR5IG9yIGZsb3cgcGF0dGVybnMNKGluY2x1ZGlu ZyBsaW5rLWxvYWQpIG9mIHRoZSBuZXR3b3JrIGZyb20gd2hpY2ggb3RoZXIgYXR0YWNrcyBjYW4g YmUNbW91bnRlZC4gVGhlIHRyYWZmaWMgYW5hbHlzaXMgYXR0YWNrIG9uIGEgTExOIG1heSBiZSBw YXNzaXZlIGFuZA1yZWx5aW5nIG9uIHRoZSBhYmlsaXR5IHRvIHJlYWQgdGhlIGltbXV0YWJsZSBz b3VyY2UvZGVzdGluYXRpb24Ncm91dGluZyBpbmZvcm1hdGlvbiB0aGF0IG11c3QgcmVtYWluIHVu ZW5jcnlwdGVkIHRvIHBlcm1pdCBuZXR3b3JrDXJvdXRpbmcuIEFsdGVybmF0aXZlbHksIGF0dGFj a3MgY2FuIGJlIGFjdGl2ZSB0aHJvdWdoIHRoZSBpbmplY3Rpb24Nb2YgdW5hdXRob3JpemVkIGRp c2NvdmVyeSB0cmFmZmljIGludG8gdGhlIG5ldHdvcmsuIEJ5IGltcGxlbWVudGluZw1hdXRoZW50 aWNhdGlvbiBtZWFzdXJlcyBiZXR3ZWVuIGNvbW11bmljYXRpbmcgbm9kZXMsIGFjdGl2ZSB0cmFm ZmljDWFuYWx5c2lzIGF0dGFja3MgY2FuIGJlIHByZXZlbnRlZCB3aXRoaW4gdGhlIExMTiB0aGVy ZWJ5IHJlZHVjaW5nDWNvbmZpZGVudGlhbGl0eSB2dWxuZXJhYmlsaXRpZXMgdG8gdGhvc2UgYXNz b2NpYXRlZCB3aXRoIHBhc3NpdmUNYW5hbHlzaXMuDU9uZSB3YXkgaW4gd2hpY2ggcGFzc2l2ZSB0 cmFmZmljIGFuYWx5c2lzIGF0dGFja3MgY2FuIGJlIG11dGVkIGlzDXRocm91Z2ggdGhlIHN1cHBv cnQgb2YgbG9hZCBiYWxhbmNpbmcgdGhhdCBhbGxvd3MgdHJhZmZpYyB0byBhIGdpdmVuDWRlc3Rp bmF0aW9uIHRvIGJlIHNlbnQgYWxvbmcgZGl2ZXJzZSByb3V0aW5nIHBhdGhzLiBXaGVyZSB0aGUN cm91dGluZyBwcm90b2NvbCBzdXBwb3J0cyBsb2FkIGJhbGFuY2luZyBhbG9uZyBtdWx0aXBsZSBs aW5rcyBhdCBlYWNoDW5vZGUsIHRoZSBudW1iZXIgb2Ygcm91dGluZyBwZXJtdXRhdGlvbnMgaW4g YSB3aWRlIGFyZWEgbmV0d29yaw1zdXJnZXMgdGh1cyBpbmNyZWFzaW5nIHRoZSBjb3N0IG9mIHRy YWZmaWMgYW5hbHlzaXMuIE5ldHdvcmsNYW5hbHlzaXMgdGhyb3VnaCB0aGlzIHBhc3NpdmUgYXR0 YWNrIHdpbGwgcmVxdWlyZSBhIHdpZGVyIGFycmF5IG9mDWFuYWx5c2lzIHBvaW50cyBhbmQgYWRk aXRpb25hbCBwcm9jZXNzaW5nIG9uIHRoZSBwYXJ0IG9mIHRoZQ1hdHRhY2tlci4gSW4gTExOcywg dGhlIGRpdmVyc2UgcmFkaW8gY29ubmVjdGl2aXR5IGFuZCBkeW5hbWljIGxpbmtzDShpbmNsdWRp bmcgcG90ZW50aWFsIGZyZXF1ZW5jeSBob3BwaW5nKSB3aWxsIGhlbHAgdG8gZnVydGhlciBtaXRp Z2F0ZQ10cmFmZmljIGFuYWx5c2lzIGF0dGFja3Mgd2hlbiBsb2FkIGJhbGFuY2luZyBpcyBpbXBs ZW1lbnRlZC4NVGhlIG9ubHkgbWVhbnMgb2YgZnVsbHkgY291bnRlcmluZyBhIHRyYWZmaWMgYW5h bHlzaXMgYXR0YWNrIGlzDXRocm91Z2ggdGhlIHVzZSBvZiB0dW5uZWxpbmcgKGVuY2Fwc3VsYXRp b24pIHdoZXJlIGVuY3J5cHRpb24gaXMNYXBwbGllZCBhY3Jvc3MgdGhlIGVudGlyZXR5IG9mIHRo ZSBvcmlnaW5hbCBwYWNrZXQgc291cmNlL2Rlc3RpbmF0aW9uDWFkZHJlc3Nlcy4gV2l0aCB0dW5u ZWxpbmcgdGhlcmUgaXMgYSBmdXJ0aGVyIHJlcXVpcmVtZW50IHRoYXQgdGhlDWVuY2Fwc3VsYXRp bmcgaW50ZXJtZWRpYXRlIG5vZGVzIGFwcGx5IGFuIGFkZGl0aW9uYWwgbGF5ZXIgb2Ygcm91dGlu Zw1zbyB0aGF0IHRyYWZmaWMgYXJyaXZlcyBhdCB0aGUgZGVzdGluYXRpb24gdGhyb3VnaCBkeW5h bWljIHJvdXRlcy4NRm9yIExMTnMsIG1lbW9yeSBhbmQgcHJvY2Vzc2luZyBjb25zdHJhaW50cyBh cyB3ZWxsIGFzIHRoZQ1saW1pdGF0aW9ucyBvZiB0aGUgY29tbXVuaWNhdGlvbiBjaGFubmVsIHdp bGwgcHJlY2x1ZGUgYm90aCB0aGUNYWRkaXRpb25hbCByb3V0aW5nIHRyYWZmaWMgb3ZlcmhlYWQg YW5kIHRoZSBub2RlIGltcGxlbWVudGF0aW9uDXJlcXVpcmVkIGZvciB0dW5uZWxpbmcgY291bnRl cm1lYXN1cmVzIHRvIHRyYWZmaWMgYW5hbHlzaXMuDQ01LjEuNC4gQ291bnRlcmluZyBQaHlzaWNh bCBEZXZpY2UgQ29tcHJvbWlzZQ1HaXZlbiB0aGUgZGlzdHJpYnV0ZWQgbmF0dXJlIG9mIExMTnMs IGNvbmZpZGVudGlhbGl0eSBvZiByb3V0aW5nDWFzc2V0cyBhbmQgcG9pbnRzIG9mIGFjY2VzcyB3 aWxsIHJlbHkgaGVhdmlseSBvbiB0aGUgc2VjdXJpdHkgb2YgdGhlDXJvdXRpbmcgZGV2aWNlcy4g T25lIG1lYW5zIG9mIHByZWNsdWRpbmcgYXR0YWNrcyBvbiB0aGUgcGh5c2ljYWwNZGV2aWNlIGlz IHRvIHByZXZlbnQgcGh5c2ljYWwgYWNjZXNzIHRvIHRoZSBub2RlIHRocm91Z2ggb3RoZXINZXh0 ZXJuYWwgc2VjdXJpdHkgbWVhbnMuIEhvd2V2ZXIsIGdpdmVuIHRoZSBlbnZpcm9ubWVudCBpbiB3 aGljaA1MTE5zIG9wZXJhdGUsIHByZXZlbnRpbmcgdW5hdXRob3JpemVkIGFjY2VzcyB0byB0aGUg cGh5c2ljYWwgZGV2aWNlDWNhbm5vdCBiZSBhc3N1cmVkLiBDb3VudGVybWVhc3VyZXMgbXVzdCB0 aGVyZWZvcmUgYmUgZW1wbG95ZWQgYXQgdGhlDWRldmljZSBhbmQgY29tcG9uZW50IGxldmVsIHNv IHRoYXQgcm91dGluZy90b3BvbG9neSBvciBuZWlnaGJvcg1pbmZvcm1hdGlvbiBhbmQgc3RvcmVk IHJvdXRlIGluZm9ybWF0aW9uIGNhbm5vdCBiZSBhY2Nlc3NlZCBldmVuIGlmDXBoeXNpY2FsIGFj Y2VzcyB0byB0aGUgbm9kZSBpcyBvYnRhaW5lZC4NV2l0aCB0aGUgcGh5c2ljYWwgZGV2aWNlIGlu IHRoZSBwb3NzZXNzaW9uIG9mIGFuIGF0dGFja2VyLA11bmF1dGhvcml6ZWQgaW5mb3JtYXRpb24g YWNjZXNzIGNhbiBiZSBhdHRlbXB0ZWQgYnkgcHJvYmluZyBpbnRlcm5hbA1pbnRlcmZhY2VzIG9y IGRldmljZSBjb21wb25lbnRzLiBEZXZpY2Ugc2VjdXJpdHkgbXVzdCB0aGVyZWZvcmUgbW92ZQ10 byBwcmV2ZW50aW5nIHRoZSByZWFkaW5nIG9mIGRldmljZSBwcm9jZXNzb3IgY29kZSBvciBtZW1v cnkNbG9jYXRpb25zIHdpdGhvdXQgdGhlIGFwcHJvcHJpYXRlIHNlY3VyaXR5IGtleXMgYW5kIGlu IHByZXZlbnRpbmcgdGhlDWFjY2VzcyB0byBhbnkgaW5mb3JtYXRpb24gZXhjaGFuZ2VzIG9jY3Vy cmluZyBiZXR3ZWVuIGluZGl2aWR1YWwNY29tcG9uZW50cy4gSW5mb3JtYXRpb24gYWNjZXNzIHdp bGwgdGhlbiBiZSByZXN0cmljdGVkIHRvIGV4dGVybmFsDWludGVyZmFjZXMgaW4gd2hpY2ggY29u ZmlkZW50aWFsaXR5LCBpbnRlZ3JpdHkgYW5kIGF1dGhlbnRpY2F0aW9uDW1lYXN1cmVzIGNhbiBi ZSBhcHBsaWVkLg1UbyBwcmV2ZW50IGNvbXBvbmVudCBpbmZvcm1hdGlvbiBhY2Nlc3MsIGRlcGxv eWVkIHJvdXRpbmcgZGV2aWNlcw1tdXN0IGVuc3VyZSB0aGF0IHRoZWlyIGltcGxlbWVudGF0aW9u IGF2b2lkcyBhZGRyZXNzIG9yIGRhdGEgYnVzZXMNYmVpbmcgY29ubmVjdGVkIHRvIGV4dGVybmFs IGdlbmVyYWwgcHVycG9zZSBpbnB1dC9vdXRwdXQgKEdQSU8pIHBpbnMuDUJleW9uZCB0aGlzIG1l YXN1cmUsIGFuIGltcG9ydGFudCBjb21wb25lbnQgaW50ZXJmYWNlIHRvIGJlIHByb3RlY3RlZA1h Z2FpbnN0IGF0dGFjayBpcyB0aGUgSm9pbnQgVGVzdCBBY3Rpb24gR3JvdXAgKEpUQUcpIGludGVy ZmFjZSB1c2VkDWZvciBjb21wb25lbnQgYW5kIHBvcHVsYXRlZCBjaXJjdWl0IGJvYXJkIHRlc3Rp bmcgYWZ0ZXIgbWFudWZhY3R1cmUuDVRvIHByb3ZpZGUgc2VjdXJpdHkgb24gdGhlIHJvdXRpbmcg ZGV2aWNlcywgY29tcG9uZW50cyBzaG91bGQgYmUNZW1wbG95ZWQgdGhhdCBhbGxvdyBmdXNlcyBv biB0aGUgSlRBRyBpbnRlcmZhY2VzIHRvIGJlIGJsb3duIHRvDWRpc2FibGUgYWNjZXNzLiBUaGlz IHdpbGwgcmFpc2UgdGhlIGJhciBvbiB1bmF1dGhvcml6ZWQgY29tcG9uZW50DWluZm9ybWF0aW9u IGFjY2VzcyB3aXRoaW4gYSBjYXB0dXJlZCBkZXZpY2UuDUF0IHRoZSBkZXZpY2UgbGV2ZWwgYSBr ZXkgY29tcG9uZW50IGluZm9ybWF0aW9uIGV4Y2hhbmdlIGlzIGJldHdlZW4NdGhlIG1pY3JvcHJv Y2Vzc29yIGFuZCBpdCBhc3NvY2lhdGVkIGV4dGVybmFsIG1lbW9yeS4gV2hpbGUNZW5jcnlwdGlv biBjYW4gYmUgaW1wbGVtZW50ZWQgdG8gc2VjdXJlIGRhdGEgYnVzIGV4Y2hhbmdlcywgdGhlIHVz ZQ1vZiBpbnRlZ3JhdGVkIHBoeXNpY2FsIHBhY2thZ2luZyB3aGljaCBhdm9pZHMgaW50ZXItY29t cG9uZW50DWV4Y2hhbmdlcyAob3RoZXIgdGhhbiBzZWN1cmUgZXh0ZXJuYWwgZGV2aWNlIGV4Y2hh bmdlcykgd2lsbCBpbmNyZWFzZQ1yb3V0aW5nIHNlY3VyaXR5IGFnYWluc3QgYSBwaHlzaWNhbCBk ZXZpY2UgaW50ZXJmYWNlIGF0dGFjay4gV2l0aCBhbg1pbnRlZ3JhdGVkIHBhY2thZ2UgYW5kIGRp c2FibGVkIGludGVybmFsIGNvbXBvbmVudCBpbnRlcmZhY2VzLCB0aGUNbGV2ZWwgb2YgcGh5c2lj YWwgZGV2aWNlIHNlY3VyaXR5IGNhbiBiZSBjb250cm9sbGVkIGJ5IG1hbmFnaW5nIHRoZQ1kZWdy ZWUgdG8gd2hpY2ggdGhlIGRldmljZSBwYWNrYWdpbmcgaXMgcHJvdGVjdGVkIGFnYWluc3QgZXhw ZXJ0DXBoeXNpY2FsIGRlY29tcG9zaXRpb24gYW5kIGFuYWx5c2lzLg1UaGUgZGV2aWNlIHBhY2th Z2Ugc2hvdWxkIGJlIGhhcmRlbmVkIHN1Y2ggdGhhdCBhdHRlbXB0cyB0byByZW1vdmUNdGhlIGlu dGVncmF0ZWQgY29tcG9uZW50cyB3aWxsIHJlc3VsdCBpbiBkYW1hZ2UgdG8gYWNjZXNzIGludGVy ZmFjZXMsDXBvcnRzIG9yIHBpbnMgdGhhdCBwcmV2ZW50IHJldHJpZXZhbCBvZiBjb2RlIG9yIHN0 b3JlZCBpbmZvcm1hdGlvbi4NVGhlIGRlZ3JlZSBvZiBWTFNJIG9yIFBDQiBwYWNrYWdlIHNlY3Vy aXR5IHRocm91Z2ggbWFudWZhY3R1cmUgY2FuIGJlDXNlbGVjdGVkIGFzIGEgdHJhZGVvZmYgb3Ig ZGVzaXJlZCBzZWN1cml0eSBjb25zaXN0ZW50IHdpdGggdGhlIGxldmVsDW9mIHNlY3VyaXR5IGFj aGlldmVkIGJ5IG1lYXN1cmVzIGFwcGxpZWQgZm9yIG90aGVyIHJvdXRpbmcgYXNzZXRzIGFuZA1w b2ludHMgb2YgYWNjZXNzLiBXaXRoIHBhY2thZ2UgaGFyZGVuaW5nIGFuZCByZXN0cmljdGVkIGNv bXBvbmVudA1hY2Nlc3MgY291bnRlcm1lYXN1cmVzLCB0aGUgc2VjdXJpdHkgbGV2ZWwgd2lsbCBi ZSByYWlzZWQgdG8gdGhhdA1wcm92aWRlZCBieSBtZWFzdXJlcyBlbXBsb3llZCBhdCB0aGUgZXh0 ZXJuYWwgY29tbXVuaWNhdGlvbnMNaW50ZXJmYWNlcy4NQW5vdGhlciBhcmVhIG9mIG5vZGUgaW50 ZXJmYWNlIHZ1bG5lcmFiaWxpdHkgaXMgdGhhdCBhc3NvY2lhdGVkIHdpdGgNaW50ZXJmYWNlcyBw cm92aWRlZCBmb3IgcmVtb3RlIHNvZnR3YXJlIG9yIGZpcm13YXJlIHVwZ3JhZGVzLiBUaGlzDW1h eSBpbXBhY3QgYm90aCByb3V0aW5nIGluZm9ybWF0aW9uIGFuZCByb3V0aW5nL3RvcG9sb2d5IGV4 Y2hhbmdlDXNlY3VyaXR5IHdoZXJlIGl0IGxlYWRzIHRvIHVuYXV0aG9yaXplZCB1cGdyYWRlIG9y IGNoYW5nZSB0byB0aGUNcm91dGluZyBwcm90b2NvbCBydW5uaW5nIG9uIGEgZ2l2ZW4gbm9kZSBh cyB0aGlzIHR5cGUgb2YgYXR0YWNrIGNhbg1hbGxvdyBmb3IgdGhlIGV4ZWN1dGlvbiBvZiBjb21w cm9taXNlZCBvciBpbnRlbnRpb25hbGx5IG1hbGljaW91cw1yb3V0aW5nIGNvZGUgb24gbXVsdGlw bGUgbm9kZXMuIENvdW50ZXJtZWFzdXJlcyB0byB0aGlzIGRldmljZQ1pbnRlcmZhY2UgY29uZmlk ZW50aWFsaXR5IGF0dGFjayBuZWVkcyB0byBiZSBhZGRyZXNzZWQgaW4gdGhlIGxhcmdlcg1jb250 ZXh0IG9mIG5vZGUgcmVtb3RlIGFjY2VzcyBzZWN1cml0eS4gVGhpcyB3aWxsIGVuc3VyZSBub3Qg b25seQ10aGUgYXV0aGVudGljaXR5IG9mIHRoZSBwcm92aWRlZCBjb2RlIChpbmNsdWRpbmcgcm91 dGluZyBwcm90b2NvbCkNYnV0IHRoYXQgdGhlIHByb2Nlc3MgaXMgaW5pdGlhdGVkIGJ5IGFuIGF1 dGhvcml6ZWQgKGF1dGhlbnRpY2F0ZWQpDWVudGl0eS4NVGhlIGFib3ZlIGlkZW50aWZpZWQgY291 bnRlcm1lYXN1cmVzIGFnYWluc3QgYXR0YWNrcyBvbiByb3V0aW5nDWluZm9ybWF0aW9uIGNvbmZp ZGVudGlhbGl0eSB0aHJvdWdoIGludGVybmFsIGRldmljZSBpbnRlcmZhY2UNY29tcHJvbWlzZSBt dXN0IGJlIHBhcnQgb2YgdGhlIGxhcmdlciBMTE4gc3lzdGVtIHNlY3VyaXR5IGFzIHRoZXkNY2Fu bm90IGJlIGFkZHJlc3NlZCB3aXRoaW4gdGhlIHJvdXRpbmcgcHJvdG9jb2wgaXRzZWxmLiBTaW1p bGFybHksDXRoZSB1c2Ugb2YgZmllbGQgdG9vbHMgb3Igb3RoZXIgZGV2aWNlcyB0aGF0IGFsbG93 IGV4cGxpY2l0IGFjY2VzcyB0bw1ub2RlIGluZm9ybWF0aW9uIG11c3QgaW1wbGVtZW50IHNlY3Vy aXR5IG1lY2hhbmlzbXMgdG8gZW5zdXJlIHRoYXQNcm91dGluZyBpbmZvcm1hdGlvbiBjYW4gYmUg cHJvdGVjdGVkIGFnYWluc3QgdW5hdXRob3JpemVkIGFjY2Vzcy4NVGhlc2UgcHJvdGVjdGlvbnMg d2lsbCBhbHNvIGJlIGV4dGVybmFsIHRvIHRoZSByb3V0aW5nIHByb3RvY29sIGFuZA1oZW5jZSBu b3QgcGFydCBvZiBST0xMLg01LjEuNS4gQ291bnRlcmluZyBSZW1vdGUgRGV2aWNlIEFjY2VzcyBB dHRhY2tzDVdoZXJlIExMTiBub2RlcyBhcmUgZGVwbG95ZWQgaW4gdGhlIGZpZWxkLCBtZWFzdXJl cyBhcmUgaW50cm9kdWNlZCB0bw1hbGxvdyBmb3IgcmVtb3RlIHJldHJpZXZhbCBvZiByb3V0aW5n IGRhdGEgYW5kIGZvciBzb2Z0d2FyZSBvciBmaWVsZA11cGdyYWRlcy4gVGhlc2UgcGF0aHMgY3Jl YXRlIHRoZSBwb3RlbnRpYWwgZm9yIGEgZGV2aWNlIHRvIGJlDXJlbW90ZWx5IGFjY2Vzc2VkIGFj cm9zcyB0aGUgbmV0d29yayBvciB0aHJvdWdoIGEgcHJvdmlkZWQgZmllbGQNdG9vbC4gSW4gdGhl IGNhc2Ugb2YgbmV0d29yayBtYW5hZ2VtZW50IGEgbm9kZSBjYW4gYmUgZGlyZWN0bHkNcmVxdWVz dGVkIHRvIHByb3ZpZGUgcm91dGluZyB0YWJsZXMgYW5kIG5laWdoYm9yIGluZm9ybWF0aW9uLg1U byBlbnN1cmUgY29uZmlkZW50aWFsaXR5IG9mIHRoZSBub2RlIHJvdXRpbmcgaW5mb3JtYXRpb24g YWdhaW5zdA1hdHRhY2tzIHRocm91Z2ggcmVtb3RlIGFjY2VzcywgYW55IGRldmljZSBsb2NhbCBv ciByZW1vdGUgcmVxdWVzdGluZw1yb3V0aW5nIGluZm9ybWF0aW9uIG11c3QgYmUgYXV0aGVudGlj YXRlZCB0byBlbnN1cmUgYXV0aG9yaXplZA1hY2Nlc3MuIFNpbmNlIHJlbW90ZSBhY2Nlc3MgaXMg bm90IGludm9rZWQgYXMgcGFydCBvZiBhIHJvdXRpbmcNcHJvdG9jb2wgc2VjdXJpdHkgb2Ygcm91 dGluZyBpbmZvcm1hdGlvbiBzdG9yZWQgb24gdGhlIG5vZGUgYWdhaW5zdA1yZW1vdGUgYWNjZXNz IHdpbGwgbm90IGJlIGFkZHJlc3NhYmxlIGFzIHBhcnQgb2YgdGhlIHJvdXRpbmcNcHJvdG9jb2wu DTUuMi4gSW50ZWdyaXR5IEF0dGFjayBDb3VudGVybWVhc3VyZXMNSW50ZWdyaXR5IGF0dGFjayBj b3VudGVybWVhc3VyZXMgYWRkcmVzcyByb3V0aW5nIGluZm9ybWF0aW9uDW1hbmlwdWxhdGlvbiwg YXMgd2VsbCBhcyBub2RlIGlkZW50aXR5IGFuZCByb3V0aW5nIGluZm9ybWF0aW9uDW1pc3VzZS4g TWFuaXB1bGF0aW9uIGNhbiBvY2N1ciBpbiB0aGUgZm9ybSBvZiBmYWxzaWZpY2F0aW9uIGF0dGFj aw1hbmQgcGh5c2ljYWwgY29tcHJvbWlzZS4gVG8gYmUgZWZmZWN0aXZlLCB0aGUgZm9sbG93aW5n IGRldmVsb3BtZW50DWNvbnNpZGVycyB0aGUgdHdvIGFzcGVjdHMgb2YgZmFsc2lmaWNhdGlvbiwg bmFtZWx5LCB0aGUgdGFtcGVyaW5nDWFjdGlvbnMgYW5kIHRoZSBvdmVyY2xhaW1pbmcgYW5kIG1p c2NsYWltaW5nIGNvbnRlbnQuIFRoZSBjb3VudGVyaW5nDW9mIHBoeXNpY2FsIGNvbXByb21pc2Ug d2FzIGNvbnNpZGVyZWQgaW4gdGhlIHByZXZpb3VzIHNlY3Rpb24gYW5kIGlzDW5vdCByZXBlYXRl ZCBoZXJlLiBXaXRoIHJlZ2FyZCB0byBtaXN1c2UsIHRoZXJlIGFyZSB0d28gdHlwZXMgb2YNYXR0 YWNrcyB0byBiZSBkZXRlcnJlZCwgaWRlbnRpdHkgYXR0YWNrcyBhbmQgcmVwbGF5IGF0dGFja3Mu DTUuMi4xLiBDb3VudGVyaW5nIFRhbXBlcmluZyBBdHRhY2tzDVRhbXBlcmluZyBtYXkgb2NjdXIg aW4gdGhlIGZvcm0gb2YgYWx0ZXJpbmcgdGhlIG1lc3NhZ2UgYmVpbmcNdHJhbnNmZXJyZWQgb3Ig dGhlIGRhdGEgc3RvcmVkLiBUaGVyZWZvcmUsIGl0IGlzIG5lY2Vzc2FyeSB0byBlbnN1cmUNdGhh dCBvbmx5IGF1dGhvcml6ZWQgbm9kZXMgY2FuIGNoYW5nZSB0aGUgcG9ydGlvbiBvZiB0aGUgaW5m b3JtYXRpb24NdGhhdCBpcyBhbGxvd2VkIHRvIGJlIG11dGFibGUsIHdoaWxlIHRoZSBpbnRlZ3Jp dHkgb2YgdGhlIHJlc3Qgb2YgdGhlDWluZm9ybWF0aW9uIGlzIHByb3RlY3RlZCwgZS5nLiwgdGhy b3VnaCB3ZWxsLXN0dWRpZWQgY3J5cHRvZ3JhcGhpYw1tZWNoYW5pc21zLg1UYW1wZXJpbmcgbWF5 IGFsc28gb2NjdXIgaW4gdGhlIGZvcm0gb2YgaW5zZXJ0aW9uIG9yIGRlbGV0aW9uIG9mDW1lc3Nh Z2VzIGR1cmluZyBwcm90b2NvbCBjaGFuZ2VzLiBUaGVyZWZvcmUsIHRoZSBwcm90b2NvbCBuZWVk cyB0bw1lbnN1cmUgdGhlIGludGVncml0eSBvZiB0aGUgc2VxdWVuY2Ugb2YgdGhlIGV4Y2hhbmdl IHNlcXVlbmNlLg1UaGUgY291bnRlcm1lYXN1cmUgdG8gdGFtcGVyaW5nIG5lZWRzIHRvDW8gaW1w bGVtZW50IGFjY2VzcyBjb250cm9sIG9uIHN0b3JhZ2U7DW8gcHJvdmlkZSBkYXRhIGludGVncml0 eSBzZXJ2aWNlIHRvIHRyYW5zZmVycmVkIG1lc3NhZ2VzIGFuZCBzdG9yZWQNZGF0YTsNbyBpbmNs dWRlIHNlcXVlbmNlIG51bWJlciB1bmRlciBpbnRlZ3JpdHkgcHJvdGVjdGlvbi4NNS4yLjIuIENv dW50ZXJpbmcgT3ZlcmNsYWltaW5nIGFuZCBNaXNjbGFpbWluZyBBdHRhY2tzDUJvdGggb3ZlcmNs YWltaW5nIGFuZCBtaXNjbGFpbWluZyBhaW0gdG8gaW50cm9kdWNlIGZhbHNlIHJvdXRlcyBvcg10 b3BvbG9neSB0aGF0IHdvdWxkIG5vdCBiZSBnZW5lcmF0ZWQgYnkgdGhlIG5ldHdvcmsgb3RoZXJ3 aXNlLCB3aGlsZQ10aGVyZSBpcyBub3QgbmVjZXNzYXJpbHkgdGFtcGVyaW5nLiBUaGUgcmVxdWlz aXRlIGZvciBhIGNvdW50ZXIgaXMNdGhlIGNhcGFiaWxpdHkgdG8gZGV0ZXJtaW5lIHVucmVhc29u YWJsZSByb3V0ZXMgb3IgdG9wb2xvZ3kuDVRoZSBjb3VudGVyIHRvIG92ZXJjbGFpbWluZyBhbmQg bWlzY2xhaW1pbmcgbWF5IGVtcGxveQ1vIGNvbXBhcmlzb24gd2l0aCBoaXN0b3JpY2FsIHJvdXRp bmcvdG9wb2xvZ3kgZGF0YTsNbyBkZXNpZ25zIHdoaWNoIHJlc3RyaWN0IHJlYWxpemFibGUgbmV0 d29yayB0b3BvbG9naWVzLg01LjIuMy4gQ291bnRlcmluZyBJZGVudGl0eSAoaW5jbHVkaW5nIFN5 YmlsKSBBdHRhY2tzDUlkZW50aXR5IGF0dGFja3MsIHNvbWV0aW1lcyBzaW1wbHkgY2FsbGVkIHNw b29maW5nLCBzZWVrIHRvIGdhaW4gb3INZGFtYWdlIGFzc2V0cyB3aG9zZSBhY2Nlc3MgaXMgY29u dHJvbGxlZCB0aHJvdWdoIGlkZW50aXR5LiBJbg1yb3V0aW5nLCBhbiBpZGVudGl0eSBhdHRhY2tl ciBjYW4gaWxsZWdpdGltYXRlbHkgcGFydGljaXBhdGUgaW4Ncm91dGluZyBleGNoYW5nZXMsIGRp c3RyaWJ1dGUgZmFsc2Ugcm91dGluZyBpbmZvcm1hdGlvbiwgb3IgY2F1c2UgYW4NaW52YWxpZCBv dXRjb21lIG9mIGEgcm91dGluZyBwcm9jZXNzLg1BIHBlcnBldHJhdG9yIG9mIFN5YmlsIGF0dGFj a3MgYXNzdW1lcyBtdWx0aXBsZSBpZGVudGl0aWVzLiBUaGUNcmVzdWx0IGlzIG5vdCBvbmx5IGFu IGFtcGxpZmljYXRpb24gb2YgdGhlIGRhbWFnZSB0byByb3V0aW5nLCBidXQNZXh0ZW5zaW9uIHRv IG5ldyBhcmVhcywgZS5nLiwgd2hlcmUgZ2VvZ3JhcGhpYyBkaXN0cmlidXRpb24gaXMNZXhwbGlj aXQgb3IgaW1wbGljaXQgYW4gYXNzZXQgdG8gYW4gYXBwbGljYXRpb24gcnVubmluZyBvbiB0aGUg TExOLg1UaGUgY291bnRlciBvZiBpZGVudGl0eSBhdHRhY2tzIG5lZWQgdG8gZW5zdXJlIHRoZSBh dXRoZW50aWNpdHkgYW5kDWxpdmVuZXNzIG9mIHRoZSBwYXJ0aWVzIG9mIGEgbWVzc2FnZSBleGNo YW5nZTsgdGhlIG1lYXN1cmUgbWF5IHVzZQ1zaGFyZWQga2V5IG9yIHB1YmxpYyBrZXkgYmFzZWQg YXV0aGVudGljYXRpb24gc2NoZW1lLiBPbiB0aGUgb25lDWhhbmQsIHRoZSBsYXJnZS1zY2FsZSBu YXR1cmUgb2YgdGhlIExMTnMgbWFrZXMgdGhlIG5ldHdvcmstd2lkZQ1zaGFyZWQga2V5IHNjaGVt ZSB1bmRlc2lyYWJsZSBmcm9tIGEgc2VjdXJpdHkgcGVyc3BlY3RpdmU7IG9uIHRoZQ1vdGhlciBo YW5kLCBwdWJsaWMta2V5IGJhc2VkIGFwcHJvYWNoZXMgZ2VuZXJhbGx5IHJlcXVpcmUgbW9yZQ1j b21wdXRhdGlvbmFsIHJlc291cmNlcy4gRWFjaCBzeXN0ZW0gd2lsbCBuZWVkIHRvIG1ha2UgdHJh ZGUtb2ZmDWRlY2lzaW9ucyBiYXNlZCBvbiBpdHMgc2VjdXJpdHkgcmVxdWlyZW1lbnRzLg01LjIu NC4gQ291bnRlcmluZyBSb3V0aW5nIEluZm9ybWF0aW9uIFJlcGxheSBBdHRhY2tzDUluIHJvdXRp bmcsIG1lc3NhZ2UgcmVwbGF5IGNhbiByZXN1bHQgaW4gZmFsc2UgdG9wb2xvZ3kgYW5kL29yDXJv dXRlcy4gVGhlIGNvdW50ZXIgb2YgcmVwbGF5IGF0dGFja3MgbmVlZCB0byBlbnN1cmUgdGhlIGZy ZXNobmVzcw1vZiB0aGUgbWVzc2FnZS4gT24gdGhlIG9uZSBoYW5kLCB0aGVyZSBhcmUgYSBudW1i ZXIgb2YgbWVjaGFuaXNtcw1jb21tb25seSB1c2VkIGZvciBjb3VudGVyaW5nIHJlcGxheS4gT24g dGhlIG90aGVyIGhhbmQsIHRoZSBjaG9pY2UNc2hvdWxkIHRha2UgaW50byBhY2NvdW50IGhvdyBh IHBhcnRpY3VsYXIgbWVjaGFuaXNtIGlzIG1hZGUgYXZhaWxhYmxlDWluIGEgTExOLiBGb3IgZXhh bXBsZSwgbWFueSBMTE5zIGhhdmUgYSBjZW50cmFsIHNvdXJjZSBvZiB0aW1lIGFuZA1oYXZlIGl0 IGRpc3RyaWJ1dGVkIGJ5IHJlbGF5aW5nLCBzdWNoIHRoYXQgc2VjdXJlZCB0aW1lIGRpc3RyaWJ1 dGlvbg1iZWNvbWVzIGEgcHJlcmVxdWlzaXRlIG9mIHVzaW5nIHRpbWVzdGFtcGluZyB0byBjb3Vu dGVyIHJlcGxheS4NNS4zLiBBdmFpbGFiaWxpdHkgQXR0YWNrIENvdW50ZXJtZWFzdXJlcw1BcyBh bGx1ZGVkIHRvIGJlZm9yZSwgYXZhaWxhYmlsaXR5IHJlcXVpcmVzIHRoYXQgcm91dGluZyBpbmZv cm1hdGlvbg1leGNoYW5nZXMgYW5kIGZvcndhcmRpbmcgbWVjaGFuaXNtcyBiZSBhdmFpbGFibGUg d2hlbiBuZWVkZWQgc28gYXMgdG8NZ3VhcmFudGVlIGEgcHJvcGVyIGZ1bmN0aW9uaW5nIG9mIHRo ZSBuZXR3b3JrLiBUaGlzIG1heSwgZS5nLiwNaW5jbHVkZSB0aGUgY29ycmVjdCBvcGVyYXRpb24g b2Ygcm91dGluZyBpbmZvcm1hdGlvbiBhbmQgbmVpZ2hib3INc3RhdGUgYW5kIHJlbWFpbmluZy1l bmVyZ3kgaW5mb3JtYXRpb24gZXhjaGFuZ2VzLCBhbW9uZyBvdGhlcnMuIA1XZSB3aWxsIGhpZ2hs aWdodCB0aGUga2V5DWZlYXR1cmVzIG9mIHRoZSBzZWN1cml0eSB0aHJlYXRzIGFsb25nIHdpdGgg dHlwaWNhbCBjb3VudGVybWVhc3VyZXMNdG8gcHJldmVudCBvciBhdCBsZWFzdCBtaXRpZ2F0ZSB0 aGVtLiBXZSB3aWxsIGFsc28gbm90ZSB0aGF0IGFuDWF2YWlsYWJpbGl0eSBhdHRhY2sgbWF5IGJl IGZhY2lsaXRhdGVkIGJ5IGFuIGlkZW50aXR5IGF0dGFjayBhcyB3ZWxsDWFzIGEgcmVwbGF5IGF0 dGFjaywgYXMgd2FzIGFkZHJlc3NlZCBpbiBTZWN0aW9uIDUuMi4zIGFuZA1TZWN0aW9uIDUuMi40 LCByZXNwZWN0aXZlbHkuDTUuMy4xLiBDb3VudGVyaW5nIEhFTExPIEZsb29kIEF0dGFja3MgYW5k IEFDSyBTcG9vZmluZyBBdHRhY2tzDUhFTExPIEZsb29kIFtLYXJsb2YyMDAzXSxbSS1ELnN1aG9w YXJrLWhlbGxvLXdzbl0gYW5kIEFDSyBTcG9vZmluZw1hdHRhY2tzIGFyZSBkaWZmZXJlbnQgYnV0 IGhpZ2hseSByZWxhdGVkIGZvcm1zIG9mIGF0dGFja2luZyBhIExMTi4NVGhleSBlc3NlbnRpYWxs eSBsZWFkIG5vZGVzIHRvIGJlbGlldmUgdGhhdCBzdWl0YWJsZSByb3V0ZXMgYXJlDWF2YWlsYWJs ZSBldmVuIHRob3VnaCB0aGV5IGFyZSBub3QgYW5kIGhlbmNlIGNvbnN0aXR1dGUgYSBzZXJpb3Vz DWF2YWlsYWJpbGl0eSBhdHRhY2suDVRoZSBvcmlnaW4gb2YgZmFjaWxpdGF0aW5nIGEgSEVMTE8g Zmxvb2QgYXR0YWNrIGxpZXMgaW4gdGhlIGZhY3QgdGhhdA1tYW55IHdpcmVsZXNzIHJvdXRpbmcg cHJvdG9jb2xzIHJlcXVpcmUgbm9kZXMgdG8gc2VuZCBIRUxMTyBwYWNrZXRzDWVpdGhlciB1cG9u IGpvaW5pbmcgb3IgaW4gcmVndWxhciBpbnRlcnZhbHMgc28gYXMgdG8gYW5ub3VuY2Ugb3INY29u ZmlybSB0aGVpciBleGlzdGVuY2UgdG8gdGhlIG5ldHdvcmsuIFRob3NlIG5vZGVzIHRoYXQgcmVj ZWl2ZSB0aGUNSEVMTE8gcGFja2V0IGFzc3VtZSB0aGF0IHRoZXkgYXJlIHdpdGhpbiByYWRpbyBy YW5nZSBvZiB0aGUNdHJhbnNtaXR0ZXIgYnkgbWVhbnMgb2YgYSBiaWRpcmVjdGlvbmFsIGNvbW11 bmljYXRpb24gbGluay4NV2l0aCB0aGlzIGluIG1pbmQsIGEgbWFsaWNpb3VzIG5vZGUgY2FuIHNl bmQgb3IgcmVwbGF5IEhFTExPIHBhY2tldHMNdXNpbmcgYSBoaWdoZXIgdHJhbnNtaXNzaW9uIHBv d2VyLiBUaGF0IGNyZWF0ZXMgdGhlIGZhbHNlIGlsbHVzaW9uDW9mIGJlaW5nIGEgbmVpZ2hib3Ig dG8gYW4gaW5jcmVhc2VkIG51bWJlciBvZiBub2RlcyBpbiB0aGUgbmV0d29yaywNdGhlcmVieSBl ZmZlY3RpdmVseSBpbmNyZWFzaW5nIGl0cyB1bmlkaXJlY3Rpb25hbCBuZWlnaGJvcmhvb2QNY2Fy ZGluYWxpdHkuIFRoZSBoaWdoIHF1YWxpdHkgb2YgdGhlIGZhbHNlbHkgYWR2ZXJ0aXNlZCBsaW5r IG1heQ1jb2VyY2Ugbm9kZXMgdG8gcm91dGUgZGF0YSB2aWEgdGhlIG1hbGljaW91cyBub2RlLiBI b3dldmVyLCB0aG9zZQ1hZmZlY3RlZCBub2RlcywgZm9yIHdoaWNoIHRoZSBtYWxpY2lvdXMgbm9k ZSBpcyBvdXQgb2YgcmFkaW8gcmFuZ2UsDW5ldmVyIHN1Y2NlZWQgaW4gdGhlaXIgZGVsaXZlcnkg YW5kIHRoZSBwYWNrZXRzIGFyZSBlZmZlY3RpdmVseQ1kcm9wcGVkLiBUaGUgc3ltcHRvbXMgYXJl IGhlbmNlIHNpbWlsYXIgdG8gdGhvc2Ugb2YgYSBzaW5raG9sZSwNd29ybWhvbGUgYW5kIHNlbGVj dGl2ZSBmb3J3YXJkaW5nIGF0dGFjay4NQSBtYWxpY2lvdXMgSEVMTE8gZmxvb2QgYXR0YWNrIGNs ZWFybHkgZGlzdG9ydHMgdGhlIG5ldHdvcmsgdG9wb2xvZ3kuDUl0IHRodXMgYWZmZWN0cyBwcm90 b2NvbHMgYnVpbGRpbmcgYW5kIG1haW50YWluaW5nIHRoZSBuZXR3b3JrDXRvcG9sb2d5IGFzIHdl bGwgYXMgcm91dGluZyBwcm90b2NvbHMgYXMgc3VjaCwgc2luY2UgdGhlIGF0dGFjayBpcw1wcmlt YXJpbHkgdGFyZ2V0ZWQgb24gcHJvdG9jb2xzIHRoYXQgcmVxdWlyZSBzaGFyaW5nIG9mIGluZm9y bWF0aW9uDWZvciB0b3BvbG9neSBtYWludGVuYW5jZSBvciBmbG93IGNvbnRyb2wuDVRvIGNvdW50 ZXIgSEVMTE8gZmxvb2QgYXR0YWNrcywgc2V2ZXJhbCBtdXR1YWxseSBub24tZXhjbHVzaXZlDW1l dGhvZHMgYXJlIGZlYXNpYmxlOg1vIHJlc3RyaWN0aW5nIG5laWdoYm9yaG9vZCBjYXJkaW5hbGl0 eTsNbyBmYWNpbGl0YXRpbmcgbXVsdGlwYXRoIHJvdXRpbmc7DW8gdmVyaWZ5aW5nIGJpZGlyZWN0 aW9uYWxpdHkuDVJlc3RyaWN0aW5nIHRoZSBuZWlnaGJvcmhvb2QgY2FyZGluYWxpdHkgcHJldmVu dHMgbWFsaWNpb3VzIG5vZGVzDWZyb20gaGF2aW5nIGFuIGV4dGVuZGVkIHNldCBvZiBuZWlnaGJv cnMgYmV5b25kIHNvbWUgdG9sZXJhdGVkDXRocmVzaG9sZCBhbmQgdGhlcmVieSBwcmV2ZW50aW5n IHRvcG9sb2dpZXMgdG8gYmUgYnVpbHQgd2hlcmUNbWFsaWNpb3VzIG5vZGVzIGhhdmUgYW4gZXh0 ZW5kZWQgbmVpZ2hib3Job29kIHNldC4gRnVydGhlcm1vcmUsIGFzDXNob3duIGluIFtJLUQuc3Vo b3BhcmstaGVsbG8td3NuXSwgaWYgdGhlIHJvdXRpbmcgcHJvdG9jb2wgc3VwcG9ydHMNbXVsdGlw bGUgcGF0aHMgZnJvbSBhIHNlbnNpbmcgbm9kZSB0b3dhcmRzIHNldmVyYWwgZ2F0ZXdheXMgdGhl bg1IRUxMTyBmbG9vZCBhdHRhY2tzIGNhbiBhbHNvIGJlIGRpbWluaXNoZWQ7IGhvd2V2ZXIsIHRo ZSBlbmVyZ3llZmZpY2llbmN5DW9mIHN1Y2ggYXBwcm9hY2ggaXMgY2xlYXJseSBzdWItb3B0aW1h bC4gRmluYWxseSwNdmVyaWZ5aW5nIHRoYXQgdGhlIGxpbmsgaXMgdHJ1bHkgYmlkaXJlY3Rpb25h bCBieSBtZWFucyBvZiwgZS5nLiwgYW4NQUNLIGhhbmRzaGFrZSBhbmQgYXBwcm9wcmlhdGUgc2Vj dXJpdHkgbWVhc3VyZXMgZW5zdXJlcyB0aGF0IGENY29tbXVuaWNhdGlvbiBsaW5rIGlzIG9ubHkg ZXN0YWJsaXNoZWQgaWYgbm90IG9ubHkgdGhlIGFmZmVjdGVkIG5vZGUNaXMgd2l0aGluIHJhbmdl IG9mIHRoZSBtYWxpY2lvdXMgbm9kZSBidXQgYWxzbyB2aWNlIHZlcnNhLiBXaGlsc3QNdGhpcyBk b2VzIG5vdCByZWFsbHkgZWxpbWluYXRlIHRoZSBwcm9ibGVtIG9mIEhFTExPIGZsb29kaW5nLCBp dA1ncmVhdGx5IHJlZHVjZXMgdGhlIG51bWJlciBvZiBhZmZlY3RlZCBub2RlcyBhbmQgdGhlIHBy b2JhYmlsaXR5IG9mDXN1Y2ggYW4gYXR0YWNrIHN1Y2NlZWRpbmcuDUFzIGZvciB0aGUgbGF0dGVy LCB0aGUgYWR2ZXJzYXJ5IG1heSBzcG9vZiB0aGUgQUNLIG1lc3NhZ2VzIHRvDWNvbnZpbmNlIHRo ZSBhZmZlY3RlZCBub2RlIHRoYXQgdGhlIGxpbmsgaXMgdHJ1bHkgYmlkaXJlY3Rpb25hbCBhbmQN dGhlcmV1cG9uIGRyb3AsIHR1bm5lbCBvciBzZWxlY3RpdmVseSBmb3J3YXJkIG1lc3NhZ2VzLiBT dWNoIEFDSw1zcG9vZmluZyBhdHRhY2sgaXMgcG9zc2libGUgaWYgdGhlIG1hbGljaW91cyBub2Rl IGhhcyBhIHJlY2VpdmVyDXdoaWNoIGlzIHNpZ25pZmljYW50bHkgbW9yZSBzZW5zaXRpdmUgdGhh biB0aGF0IG9mIGEgbm9ybWFsIG5vZGUsDXRoZXJlYnkgZWZmZWN0aXZlbHkgZXh0ZW5kaW5nIGl0 cyByYW5nZS4gU2luY2UgYW4gQUNLIHNwb29maW5nDWF0dGFjayBmYWNpbGl0YXRlcyBhIEhFTExP IGZsb29kIGF0dGFjaywgc2ltaWxhciBjb3VudGVybWVhc3VyZSBhcmUNYXBwbGljYWJsZSBoZXJl LiBWaWFibGUgY291bnRlciBhbmQgc2VjdXJpdHkgbWVhc3VyZXMgZm9yIGJvdGgNYXR0YWNrcyBo YXZlIGJlZW4gZXhwb3NlZCBpbiBbSS1ELnN1aG9wYXJrLWhlbGxvLXdzbl0uDTUuMy4yLiBDb3Vu dGVyaW5nIE92ZXJsb2FkIEF0dGFja3MNT3ZlcmxvYWQgYXR0YWNrcyBhcmUgYSBmb3JtIG9mIERv UyBhdHRhY2sgaW4gdGhhdCBhIG1hbGljaW91cyBub2RlDW92ZXJsb2FkcyB0aGUgbmV0d29yayB3 aXRoIGlycmVsZXZhbnQgdHJhZmZpYywgdGhlcmVieSBkcmFpbmluZyB0aGUNbm9kZXMnIGVuZXJn eSBidWRnZXQgcXVpY2tlci4gSXQgdGh1cyBzaWduaWZpY2FudGx5IHNob3J0ZW5zIHRoZQ1uZXR3 b3JrIGxpZmV0aW1lIGFuZCBoZW5jZSBjb25zdGl0dXRlcyBhbm90aGVyIHNlcmlvdXMgYXZhaWxh YmlsaXR5DWF0dGFjay4NV2l0aCBlbmVyZ3kgYmVpbmcgb25lIG9mIHRoZSBtb3N0IHByZWNpb3Vz IGFzc2V0cyBvZiBMTE5zLCB0YXJnZXRpbmcNaXRzIGF2YWlsYWJpbGl0eSBpcyBhIGZhaXJseSBv YnZpb3VzIGF0dGFjay4gQW5vdGhlciB3YXkgb2YNZGVwbGV0aW5nIHRoZSBlbmVyZ3kgb2YgYSBM TE4gbm9kZSBpcyB0byBoYXZlIHRoZSBtYWxpY2lvdXMgbm9kZQ1vdmVybG9hZCB0aGUgbmV0d29y ayB3aXRoIGlycmVsZXZhbnQgdHJhZmZpYy4gVGhpcyBpbXBhY3RzDWF2YWlsYWJpbGl0eSBzaW5j ZSBjZXJ0YWluIHJvdXRlcyBnZXQgY29uZ2VzdGVkIHdoaWNoDW8gcmVuZGVycyB0aGVtIHVzZWxl c3MgZm9yIGFmZmVjdGVkIG5vZGVzIGFuZCBkYXRhIGNhbiBoZW5jZSBub3QgYmUNZGVsaXZlcmVk Ow1vIG1ha2VzIHJvdXRlcyBsb25nZXIgYXMgc2hvcnRlc3QgcGF0aCBhbGdvcml0aG1zIHdvcmsg d2l0aCB0aGUNY29uZ2VzdGVkIG5ldHdvcms7DW8gZGVwbGV0ZXMgbm9kZXMgcXVpY2tlciBhbmQg dGh1cyBzaG9ydGVucyB0aGUgbmV0d29yaydzDWF2YWlsYWJpbGl0eSBhdCBsYXJnZS4NT3Zlcmxv YWQgYXR0YWNrcyBjYW4gYmUgY291bnRlcmVkIGJ5IGRlcGxveWluZyBhIHNlcmllcyBvZiBtdXR1 YWxseQ1ub24tZXhjbHVzaXZlIHNlY3VyaXR5IG1lYXN1cmVzOg1vIGludHJvZHVjZSBxdW90YXMg b24gdGhlIHRyYWZmaWMgcmF0ZSBlYWNoIG5vZGUgaXMgYWxsb3dlZCB0byBzZW5kOw1vIGlzb2xh dGUgbm9kZXMgd2hpY2ggc2VuZCB0cmFmZmljIGFib3ZlIGEgY2VydGFpbiB0aHJlc2hvbGQ7DW8g YWxsb3cgb25seSB0cnVzdGVkIGRhdGEgdG8gYmUgcmVjZWl2ZWQgYW5kIGZvcndhcmRlZC4NQXMg Zm9yIHRoZSBmaXJzdCBvbmUsIGEgc2ltcGxlIGFwcHJvYWNoIHRvIG1pbmltaXplIHRoZSBoYXJt ZnVsDWltcGFjdCBvZiBhbiBvdmVybG9hZCBhdHRhY2sgaXMgdG8gaW50cm9kdWNlIHRyYWZmaWMg cXVvdGFzLiBUaGlzDXByZXZlbnRzIGEgbWFsaWNpb3VzIG5vZGUgZnJvbSBpbmplY3RpbmcgYSBs YXJnZSBhbW91bnQgb2YgdHJhZmZpYw1pbnRvIHRoZSBuZXR3b3JrLCBldmVuIHRob3VnaCBpdCBk b2VzIG5vdCBwcmV2ZW50IHNhaWQgbm9kZSBmcm9tDWluamVjdGluZyBpcnJlbGV2YW50IHRyYWZm aWMgYXQgYWxsLiBBbm90aGVyIG1ldGhvZCBpcyB0byBpc29sYXRlDW5vZGVzIGZyb20gdGhlIG5l dHdvcmsgb25jZSBpdCBoYXMgYmVlbiBkZXRlY3RlZCB0aGF0IG1vcmUgdHJhZmZpYyBpcw1pbmpl Y3RlZCBpbnRvIHRoZSBuZXR3b3JrIHRoYW4gYWxsb3dlZCBieSBhIHByaW9yIHNldCBvciBkeW5h bWljYWxseQ1hZGp1c3RlZCB0aHJlc2hvbGQuIEZpbmFsbHksIGlmIGNvbW11bmljYXRpb24gaXMg c3VmZmljaWVudGx5DXNlY3VyZWQsIG9ubHkgdHJ1c3RlZCBub2RlcyBjYW4gcmVjZWl2ZSBhbmQg Zm9yd2FyZCB0cmFmZmljIHdoaWNoDWFsc28gbG93ZXJzIHRoZSByaXNrIG9mIGFuIG92ZXJsb2Fk IGF0dGFjay4NNS4zLjMuIENvdW50ZXJpbmcgU2VsZWN0aXZlIEZvcndhcmRpbmcgQXR0YWNrcw1T ZWxlY3RpdmUgZm9yd2FyZGluZyBhdHRhY2tzIGFyZSBhbm90aGVyIGZvcm0gb2YgRG9TIGF0dGFj ayB3aGljaA1pbXBhY3RzIHRoZSByb3V0aW5nIHBhdGggYXZhaWxhYmlsaXR5Lg1BbiBpbnNpZGVy IG1hbGljaW91cyBub2RlIGJhc2ljYWxseSBibGVuZHMgbmVhdGx5IGluIHdpdGggdGhlIG5ldHdv cmsNYnV0IHRoZW4gbWF5IGRlY2lkZSB0byBmb3J3YXJkIGFuZC9vciBtYW5pcHVsYXRlIGNlcnRh aW4gcGFja2V0cyBmcm9tIA1hbnkgb3IgcGFydCBvZiBpdHMgbmVpZ2hib3JzLiANSWYgc29tZSBw YWNrZXRzIGFyZSBzZWxlY3RpdmVseSBkcm9wcGVkLCB0aGVuIHRoaXMgYXR0YWNoZXIgaXMgb2Z0 ZW4gDXJlZmVycmVkIGFzIJNncmF5IGhvbGWULCB3aGlsZSBpZiANYWxsIHBhY2tldHMgYXJlIGRy b3BwZWQsIHRoZW4gdGhpcyANYXR0YWNrZXIgaXMgYWxzbyBvZnRlbiByZWZlcnJlZCB0byANYXMg YSAiYmxhY2sgaG9sZSIuIA1TdWNoIGEgZm9ybSBvZiBhdHRhY2sgaXMgcGFydGljdWxhcmx5IGRh bmdlcm91cw1pZiBjb3VwbGVkIHdpdGggc2lua2hvbGUgYXR0YWNrcywgc2luY2UgaW5oZXJlbnRs eSBhIGxhcmdlIGFtb3VudCBvZg10cmFmZmljIGlzIGF0dHJhY3RlZCB0byB0aGUgbWFsaWNpb3Vz IG5vZGUgYW5kIHRoZXJlYnkgY2F1c2luZw1zaWduaWZpY2FudCBkYW1hZ2UuIEFuIG91dHNpZGUg bWFsaWNpb3VzIG5vZGUgd291bGQgc2VsZWN0aXZlbHkgamFtDW92ZXJoZWFyZCBkYXRhIGZsb3dz LCB3aGVyZSB0aGUgdGh1cyBjYXVzZWQgY29sbGlzaW9ucyBpbmN1cg1zZWxlY3RpdmUgZm9yd2Fy ZGluZy4NTW9yZW92ZXIsIJNncmF5IGhvbGWUIGF0dGFja3MgYXJlIHdvcnNlIHRoYW4gk2JsYWNr IGhvbGWUIGF0dGFja3MgYXMNaXQgaXMgbW9yZSBkaWZmaWN1bHQgdG8gZGV0ZWN0IHRoZW0uDVNl bGVjdGl2ZSBGb3J3YXJkaW5nIGF0dGFja3MgY2FuIGJlIGNvdW50ZXJlZCBieSBkZXBsb3lpbmcg YSBzZXJpZXMNb2YgbXV0dWFsbHkgbm9uLWV4Y2x1c2l2ZSBzZWN1cml0eSBtZWFzdXJlczoNbyBt dWx0aXBhdGggcm91dGluZyBvZiB0aGUgc2FtZSBtZXNzYWdlIG92ZXIgZGlzam9pbnQgcGF0aHM7 DW8gZHluYW1pY2FsbHkgc2VsZWN0IHRoZSBuZXh0IGhvcCBmcm9tIGEgc2V0IG9mIGNhbmRpZGF0 ZXM7DW8gcmVhbGlzZSBhIHRydXN0IG1vZGVsIHRvIHNlbGVjdCB0aGUgbmV4dCBob3AgY2FuZGlk YXRlLg1UaGUgZmlyc3QgbWVhc3VyZSBiYXNpY2FsbHkgZ3VhcmFudGVlcyB0aGF0IGlmIGEgbWVz c2FnZSBnZXRzIGxvc3Qgb24NYSBwYXJ0aWN1bGFyIHJvdXRpbmcgcGF0aCBkdWUgdG8gYSBtYWxp Y2lvdXMgc2VsZWN0aXZlIGZvcndhcmRpbmcNYXR0YWNrLCB0aGVyZSB3aWxsIGJlIGFub3RoZXIg cm91dGUgd2hpY2ggc3VjY2Vzc2Z1bGx5IGRlbGl2ZXJzIHRoZQ1kYXRhLiBTdWNoIG1ldGhvZCBp cyBpbmhlcmVudGx5IHN1Ym9wdGltYWwgZnJvbSBhbiBlbmVyZ3kNY29uc3VtcHRpb24gcG9pbnQg b2Ygdmlldy4gVGhlIHNlY29uZCBtZXRob2QgYmFzaWNhbGx5IGludm9sdmVzIGENY29uc3RhbnRs eSBjaGFuZ2luZyByb3V0aW5nIHRvcG9sb2d5IGluIHRoYXQgbmV4dC1ob3Agcm91dGVycyBhcmUN Y2hvc2VuIGZyb20gYSBkeW5hbWljIHNldCBpbiB0aGUgaG9wZSB0aGF0IHRoZSBudW1iZXIgb2Yg bWFsaWNpb3VzDW5vZGVzIGluIHRoaXMgc2V0IGlzIG5lZ2xpZ2libGUuIFRoZSB0aGlyZCBtZXRo b2QgYnVpbGRzIGEgdHJ1c3QgdGFibGUNZm9yIG5laWdoYm9yaW5nIG5vZGVzIGFuZCBuZXh0LWhv cCByb3V0ZXJzIGFyZSBjaG9zZW4gZnJvbSBhIGdyb3VwIG9mIA1ub2RlcyB0aGF0IGZ1bGZpbCBh IHNldCBvZiBjcml0ZXJpYSAoZS5nLiB0aGUgYmVzdCBhdmVyYWdlIGJldHdlZW4gdHJ1c3QgYW5k IHJlbWFpbmluZyBlbmVyZ3kpLiBFYWNoIG5vZGUgbW9uaXRvcnMvb3ZlcmhlYXJzIHRoZSBiZWhh dmlvciBvZiBpdHMgDW5laWdoYm9ycyBpbiBvcmRlciB0byBjaGVjayB3aGV0aGVyIHRoZXkgc2lu Y2VyZWx5IGV4ZWN1dGUgdGhlIHJvdXRpbmcgDXByb3RvY29sIGFuZCBiZWhhdmUgYXMgZXhwZWN0 ZWQuIFRoZSBlbmQgcmVzdWx0IGlzIHRoYXQgZWFjaCBub2RlIA1jYWxjdWxhdGVzIHRoZSB0cnVz dHdvcnRoaW5lc3Mgb2YgaXRzIG5laWdoYm9ycyBhbmQgdGhlbiB0YWtlcyBpbnRvIA1hY2NvdW50 IHRoaXMgIGluZm9ybWF0aW9uIHRvIGF2b2lkIGNob29zaW5nIG1hbGljaW91cyBub2RlcyBkdXJp bmcgcm91dGluZyANZGVjaXNpb25zLCBrZXkgZGlzdHJpYnV0aW9uLCBvciBjbHVzdGVyIGhlYWQg ZWxlY3Rpb24uIA0gDQ01LjMuNC4gQ291bnRlcmluZyBTaW5raG9sZSBBdHRhY2tzDUluIHNpbmto b2xlIGF0dGFja3MsIHRoZSBtYWxpY2lvdXMgbm9kZSBtYW5hZ2VzIHRvIGF0dHJhY3QgYSBsb3Qg b2YNdHJhZmZpYyBtYWlubHkgYnkgYWR2ZXJ0aXNpbmcgdGhlIGF2YWlsYWJpbGl0eSBvZiBoaWdo LXF1YWxpdHkgbGlua3MNZXZlbiB0aG91Z2ggdGhlcmUgYXJlIG5vbmUuIEl0IGhlbmNlIGNvbnN0 aXR1dGVzIGEgc2VyaW91cyBhdHRhY2sgb24NYXZhaWxhYmlsaXR5Lg1UaGUgbWFsaWNpb3VzIG5v ZGUgY3JlYXRlcyBhIHNpbmtob2xlIGJ5IGF0dHJhY3RpbmcgYSBsYXJnZSBhbW91bnQNb2YsIGlm IG5vdCBhbGwsIHRyYWZmaWMgZnJvbSBzdXJyb3VuZGluZyBuZWlnaGJvcnMgYnkgYWR2ZXJ0aXNp bmcgaW4NYW5kIG91dHdhcmRzIGxpbmtzIG9mIHN1cGVyaW9yIHF1YWxpdHkuIEFmZmVjdGVkIG5v ZGVzIGhlbmNlIGVhZ2VybHkNcm91dGUgdGhlaXIgdHJhZmZpYyB2aWEgdGhlIG1hbGljaW91cyBu b2RlIHdoaWNoLCBpZiBjb3VwbGVkIHdpdGgNb3RoZXIgYXR0YWNrcyBzdWNoIGFzIHNlbGVjdGl2 ZSBmb3J3YXJkaW5nLCBtYXkgbGVhZCB0byBzZXJpb3VzDWF2YWlsYWJpbGl0eSBhbmQgc2VjdXJp dHkgYnJlYWNoZXMuIFN1Y2ggYW4gYXR0YWNrIGNhbiBvbmx5IGJlDWV4ZWN1dGVkIGJ5IGFuIGlu c2lkZSBtYWxpY2lvdXMgbm9kZSBhbmQgaXMgZ2VuZXJhbGx5IHZlcnkgZGlmZmljdWx0DXRvIGRl dGVjdC4gQW4gb25nb2luZyBhdHRhY2sgaGFzIGEgcHJvZm91bmQgaW1wYWN0IG9uIHRoZSBuZXR3 b3JrDXRvcG9sb2d5IGFuZCBlc3NlbnRpYWxseSBiZWNvbWVzIGEgcHJvYmxlbSBvZiBmbG93IGNv bnRyb2wuDVNpbmtob2xlIGF0dGFja3MgY2FuIGJlIGNvdW50ZXJlZCBieSBkZXBsb3lpbmcgYSBz ZXJpZXMgb2YgbXV0dWFsbHkNbm9uLWV4Y2x1c2l2ZSBzZWN1cml0eSBtZWFzdXJlczoNbyB1c2Ug Z2VvZ3JhcGhpY2FsIGluc2lnaHRzIGZvciBmbG93IGNvbnRyb2w7DW8gaXNvbGF0ZSBub2RlcyB3 aGljaCByZWNlaXZlIHRyYWZmaWMgYWJvdmUgYSBjZXJ0YWluIHRocmVzaG9sZDsNbyBkeW5hbWlj YWxseSBwaWNrIHVwIG5leHQgaG9wIGZyb20gc2V0IG9mIGNhbmRpZGF0ZXM7DW8gYWxsb3cgb25s eSB0cnVzdGVkIGRhdGEgdG8gYmUgcmVjZWl2ZWQgYW5kIGZvcndhcmRlZDsNbyByZWFsaXNlIGEg dHJ1c3QgbW9kZWwgdG8gc2VsZWN0IHRoZSBuZXh0IGhvcCBjYW5kaWRhdGUuLg1XaGlsc3QgbW9z dCBvZiB0aGVzZSBjb3VudGVybWVhc3VyZXMgaGF2ZSBiZWVuIGRpc2N1c3NlZCBiZWZvcmUsIHRo ZQ11c2Ugb2YgZ2VvZ3JhcGhpY2FsIGluZm9ybWF0aW9uIGRlc2VydmVzIGZ1cnRoZXIgYXR0ZW50 aW9uLg1Fc3NlbnRpYWxseSwgaWYgZ2VvZ3JhcGhpYyBwb3NpdGlvbnMgb2Ygbm9kZXMgYXJlIGF2 YWlsYWJsZSwgdGhlbiB0aGUNbmV0d29yayBjYW4gYXNzdXJlIHRoYXQgZGF0YSBpcyBhY3R1YWxs eSByb3V0ZWQgdG93YXJkcyB0aGUgc2luayhzKQ1hbmQgbm90IGVsc2V3aGVyZS4gT24gdGhlIG90 aGVyIGhhbmQsIGdlb2dyYXBoaWMgcG9zaXRpb24gaXMgYQ1zZW5zaXRpdmUgaW5mb3JtYXRpb24g dGhhdCBtYXkgaGF2ZSBzZWN1cml0eSBhbmQvb3IgcHJpdmFjeQ1jb25zZXF1ZW5jZXMuDTUuMy41 LiBDb3VudGVyaW5nIFdvcm1ob2xlIEF0dGFja3MNSW4gd29ybWhvbGUgYXR0YWNrcyBhdCBsZWFz dCB0d28gbWFsaWNpb3VzIG5vZGVzIHNob3J0Y3V0IG9yIGRpdmVydA10aGUgdXN1YWwgcm91dGlu ZyBwYXRoIGJ5IG1lYW5zIG9mIGEgbG93LWxhdGVuY3kgb3V0LW9mLWJhbmQgY2hhbm5lbC4NVGhp cyBjaGFuZ2VzIHRoZSBhdmFpbGFiaWxpdHkgb2YgY2VydGFpbiByb3V0aW5nIHBhdGhzIGFuZCBo ZW5jZQ1jb25zdGl0dXRlcyBhIHNlcmlvdXMgc2VjdXJpdHkgYnJlYWNoLg1Fc3NlbnRpYWxseSwg dHdvIG1hbGljaW91cyBpbnNpZGVyIG5vZGVzIHVzZSBhbm90aGVyLCBtb3JlIHBvd2VyZnVsLA1y YWRpbyB0byBjb21tdW5pY2F0ZSB3aXRoIGVhY2ggb3RoZXIgYW5kIHRoZXJlYnkgZGlzdG9ydCB0 aGUgd291bGRiZS0NYWdyZWVkIHJvdXRpbmcgcGF0aC4gVGhpcyBkaXN0b3J0aW9uIGNvdWxkIGlu dm9sdmUgc2hvcnRjdXR0aW5nDWFuZCBoZW5jZSBwYXJhbHl6aW5nIGEgbGFyZ2UgcGFydCBvZiB0 aGUgbmV0d29yazsgaXQgY291bGQgYWxzbw1pbnZvbHZlIHR1bm5lbGluZyB0aGUgaW5mb3JtYXRp b24gdG8gYW5vdGhlciByZWdpb24gb2YgdGhlIG5ldHdvcmsNd2hlcmUgdGhlcmUgYXJlLCBlLmcu LCBtb3JlIG1hbGljaW91cyBub2RlcyBhdmFpbGFibGUgdG8gYWlkIHRoZQ1pbnRydXNpb24gb3Ig d2hlcmUgbWVzc2FnZXMgYXJlIHJlcGxheWVkLCBldGMuIEluIGNvbmp1bmN0aW9uIHdpdGgNc2Vs ZWN0aXZlIGZvcndhcmRpbmcsIHdvcm1ob2xlIGF0dGFja3MgY2FuIGNyZWF0ZSByYWNlIGNvbmRp dGlvbnMNd2hpY2ggaW1wYWN0IHRvcG9sb2d5IG1haW50ZW5hbmNlLCByb3V0aW5nIHByb3RvY29s cyBhcyB3ZWxsIGFzIGFueQ1zZWN1cml0eSBzdWl0cyBidWlsdCBvbiAidGltZSBvZiBjaGVjayIg YW5kICJ0aW1lIG9mIHVzZSIuDVdvcm1ob2xlIGF0dGFja3MgYXJlIHZlcnkgZGlmZmljdWx0IHRv IGRldGVjdCBpbiBnZW5lcmFsIGJ1dCBjYW4gYmUNbWl0aWdhdGVkIHVzaW5nIHNpbWlsYXIgc3Ry YXRlZ2llcyBhcyBhbHJlYWR5IG91dGxpbmVkIGFib3ZlIGluIHRoZQ1jb250ZXh0IG9mIHNpbmto b2xlIGF0dGFja3MuDTYuIFJPTEwgU2VjdXJpdHkgRmVhdHVyZXMNVGhlIGlzc3VlcyBkaXNjdXNz ZWQgaW4gU2VjdGlvbiA0LCB0b2dldGhlciB3aXRoIHRoZSBjb3VudGVybWVhc3VyZXMNZGVzY3Jp YmVkIGluIFNlY3Rpb24gNSwgcHJvdmlkZSB0aGUgYmFzaXMgZm9yIHRoZSByZXF1aXJlbWVudHMg b2YgdGhlDWZvbGxvd2luZyBST0xMIHNlY3VyaXR5IGZlYXR1cmVzOyBpbiBjb25mb3JtYW5jZSwg dGhlIGRlc2lnbiBvZiBhDXNlY3VyZWQgUk9MTCBwcm90b2NvbCBuZWVkcyB0byB1c2Ugd2VsbC1r bm93biBtZWNoYW5pc21zIHRvIGltcGxlbWVudA10aGUgc2VydmljZXMuDTYuMS4gQ29uZmlkZW50 aWFsaXR5IEZlYXR1cmVzDVRvIHByb3RlY3QgY29uZmlkZW50aWFsaXR5LCBhIHNlY3VyZWQgUk9M TCBwcm90b2NvbA1vIFNIT1VMRCBwcm92aWRlIHBheWxvYWQgZW5jcnlwdGlvbjsNbyBNQVkgcHJv dmlkZSB0dW5uZWxpbmc7DW8gTUFZIHByb3ZpZGUgbG9hZCBiYWxhbmNpbmc7DW8gU0hPVUxEIHBy b3ZpZGUgcHJpdmFjeSwgZS5nLiwgd2hlbiBnZW9ncmFwaGljIGluZm9ybWF0aW9uIGlzIHVzZWQu DTYuMi4gSW50ZWdyaXR5IEZlYXR1cmVzDVRvIHByb3RlY3QgaW50ZWdyaXR5LCBhIHNlY3VyZWQg Uk9MTCBwcm90b2NvbA1vIE1VU1QgdmVyaWZ5IHRoZSBsaXZlbGluZXNzIG9mIGJvdGggcHJpbmNp cGFscyBvZiBhIGNvbm5lY3Rpb247DW8gTVVTVCB2ZXJpZnkgbWVzc2FnZSBmcmVzaG5lc3M7DW8g TVVTVCB2ZXJpZnkgbWVzc2FnZSBzZXF1ZW5jZSBhbmQgaW50ZWdyaXR5Ow1vIE1BWSBldmFsdWF0 ZSB0cnVzdCBhbmQgdHJ1c3R3b3J0aGluZXNzIG9mIG5laWdoYm9yaW5nIG5vZGVzDTYuMy4gQXZh aWxhYmlsaXR5IEZlYXR1cmVzDVRvIHByb3RlY3QgYXZhaWxhYmlsaXR5LCBhIHNlY3VyZWQgUk9M TCBwcm90b2NvbA1vIE1BWSByZXN0cmljdCBuZWlnaGJvcmhvb2QgY2FyZGluYWxpdHk7DW8gTUFZ IHVzZSBtdWx0aXBsZSBwYXRoczsNbyBNQVkgdXNlIG11bHRpcGxlIGRlc3RpbmF0aW9uczsNbyBN QVkgY2hvb3NlIHJhbmRvbWx5IGlmIG11bHRpcGxlIHBhdGhzIGFyZSBhdmFpbGFibGU7DW8gTUFZ IHNldCBxdW90YXMgdG8gbGltaXQgdHJhbnNtaXQgb3IgcmVjZWl2ZSB2b2x1bWU7DW8gTUFZIHVz ZSBnZW9ncmFwaGljIGluc2lnaHRzIGZvciBmbG93IGNvbnRyb2wuDTYuNC4gQWRkaXRpb25hbCBD b25zaWRlcmF0aW9ucw1JZiBhIExMTiBlbXBsb3lzIG11bHRpY2FzdCBhbmQvb3IgYW55Y2FzdCwg aXQgTVVTVCBzZWN1cmUgdGhlc2UNcHJvdG9jb2xzIHdpdGggdGhlIHNlcnZpY2VzIGxpc3RlZCBp biB0aGlzIHNlY3Rpb25zLiBGdXJ0aGVybW9yZSwNdGhlIG5vZGVzIE1VU1QgcHJvdmlkZSBhZGVx dWF0ZSBwaHlzaWNhbCB0YW1wZXIgcmVzaXN0YW5jZSB0byBlbnN1cmUNdGhlIGludGVncml0eSBv ZiBzdG9yZWQgcm91dGluZyBpbmZvcm1hdGlvbi4NVGhlIGZ1bmN0aW9uaW5nIG9mIHRoZSBzZWN1 cml0eSBzZXJ2aWNlcyByZXF1aXJlcyBrZXlzIGFuZA1jcmVkZW50aWFscy4gVGhlcmVmb3JlLCBl dmVuIHRob3VnaCBub3QgZGlyZWN0bHkgYSBST0xMIHNlY3VyaXR5DXJlcXVpcmVtZW50LCBhIExM TiBtdXN0IGluY2x1ZGUgYSBwcm9jZXNzIGZvciBrZXkgYW5kIGNyZWRlbnRpYWwNZGlzdHJpYnV0 aW9uOyBhIExMTiBpcyBlbmNvdXJhZ2VkIHRvIGhhdmUgcHJvY2VkdXJlcyBmb3IgdGhlaXINcmV2 b2NhdGlvbiBhbmQgcmVwbGFjZW1lbnQuDTcuIElBTkEgQ29uc2lkZXJhdGlvbnMNVGhpcyBtZW1v IGluY2x1ZGVzIG5vIHJlcXVlc3QgdG8gSUFOQS4NOC4gU2VjdXJpdHkgQ29uc2lkZXJhdGlvbnMN VGhlIGZyYW1ld29yayBwcmVzZW50ZWQgaW4gdGhpcyBkb2N1bWVudCBwcm92aWRlcyBzZWN1cml0 eSBhbmFseXNpcw1hbmQgZGVzaWduIGd1aWRlbGluZXMgd2l0aCBhIHNjb3BlIGxpbWl0ZWQgdG8g Uk9MTC4gVGhlDWludmVzdGlnYXRpb24gaXMgYXQgYSBoaWdoLWxldmVsIGFuZCBub3Qgc3BlY2lm aWMgdG8gYSBwYXJ0aWN1bGFyDXByb3RvY29sLiBTZWN1cml0eSBzZXJ2aWNlcywgYnV0IG5vdCBt ZWNoYW5pc21zLCBhcmUgaWRlbnRpZmllZCBhcw1yZXF1aXJlbWVudHMgZm9yIHNlY3VyaW5nIFJP TEwuDTkuIFRydXN0L1RydXN0d29ydGhpbmVzcyBDb25zaWRlcmF0aW9ucw1UaGUgc2VjdXJpdHkg ZnJhbWV3b3JrIG1heSBvcHRpb25hbGx5IHN1cHBvcnRlZCBhbmQgZXh0ZW5kZWQgYnkgYSB0cnVz dCANZnJhbWV3b3JrLCBXaGljaCBtYXkgYmUgYXBwbGllZCBpbiB0aGUgc2VsZWN0aW9uIG9mIGEg c2VjdXJlIFJPTEwuIA1UaGUgdHJ1c3QgZnJhbWV3b3JrIG1heSBiZSBiYXNlZCBvbiCTZGlyZWN0 IHRydXN0lCwgd2hpY2ggaXMgdGhlIHRydXN0IA10aGF0IGEgbm9kZSBidWlsZHMgcHJvZ3Jlc3Np dmVseSB1dGlsaXNpbmcgaXRzIG93biByb3V0aW5nIGV4cGVyaWVuY2UgDWFuZCBuZXR3b3JrIG92 ZXJoZWFyaW5nL3NuaWZmaW5nLCBhbmQgb24gk2luZGlyZWN0IHRydXN0lCAoYWxzbyByZWZlcnJl ZCANdG8gYXMgcmVwdXRhdGlvbiksIHdoaWNoIGlzIHRoZSB0cnVzdCB0aGF0IHNlbGVjdGVkIG5l aWdoYm91cmluZyBub2Rlcw1zaGFyZXMgd2l0aCB0aGUgaW50ZXJlc3Rpbmcgbm9kZS4gDQ0xMCBB Y2tub3dsZWRnbWVudHMNMTAxLiBSZWZlcmVuY2VzDTExMC4xLiBOb3JtYXRpdmUgUmVmZXJlbmNl cw1bUkZDMjExOV0gQnJhZG5lciwgUy4sICJLZXkgd29yZHMgZm9yIHVzZSBpbiBSRkNzIHRvIElu ZGljYXRlDVJlcXVpcmVtZW50IExldmVscyIsIEJDUCAxNCwgUkZDIDIxMTksIE1hcmNoIDE5OTcu DTExMC4yLiBJbmZvcm1hdGl2ZSBSZWZlcmVuY2VzDVtIdWFuZzIwMDNdDUh1YW5nLCBRLiwgQ3Vr aWVyLCBKLiwgS29iYXlhc2hpLCBILiwgTGl1LCBCLiwgYW5kIEouDVpoYW5nLCAiRmFzdCBBdXRo ZW50aWNhdGVkIEtleSBFc3RhYmxpc2htZW50IFByb3RvY29scyBmb3INU2VsZi1Pcmdhbml6aW5n IFNlbnNvciBOZXR3b3JrcyIsIGluIFByb2NlZWRpbmdzIG9mIHRoZQ0ybmQgQUNNIEludGVybmF0 aW9uYWwgQ29uZmVyZW5jZSBvbiBXaXJlbGVzcyBTZW5zb3INTmV0d29ya3MgYW5kIEFwcGxpY2F0 aW9ucyBTYW4gRGllZ28sIENBLCBVU0EsIHBwLiAxNDEtMTUwLA1TZXB0LiAxOSAyMDAzLg1bSS1E LmlldGYtcm9sbC1idWlsZGluZy1yb3V0aW5nLXJlcXNdDU1hcnRvY2NpLCBKLiwgUmlvdSwgTi4s IE1pbCwgUC4sIGFuZCBXLiBWZXJtZXlsZW4sDSJCdWlsZGluZyBBdXRvbWF0aW9uIFJvdXRpbmcg UmVxdWlyZW1lbnRzIGluIExvdyBQb3dlciBhbmQNTG9zc3kgTmV0d29ya3MiLCBkcmFmdC1pZXRm LXJvbGwtYnVpbGRpbmctcm91dGluZy1yZXFzLTA1DSh3b3JrIGluIHByb2dyZXNzKSwgRmVicnVh cnkgMjAwOS4NW0ktRC5pZXRmLXJvbGwtaG9tZS1yb3V0aW5nLXJlcXNdDVBvcmN1LCBHLiwgIkhv bWUgQXV0b21hdGlvbiBSb3V0aW5nIFJlcXVpcmVtZW50cyBpbiBMb3cNUG93ZXIgYW5kIExvc3N5 IE5ldHdvcmtzIiwNZHJhZnQtaWV0Zi1yb2xsLWhvbWUtcm91dGluZy1yZXFzLTA2ICh3b3JrIGlu IHByb2dyZXNzKSwNTm92ZW1iZXIgMjAwOC4NW0ktRC5pZXRmLXJvbGwtaW5kdXMtcm91dGluZy1y ZXFzXQ1OZXR3b3JrcywgRC4sIFRodWJlcnQsIFAuLCBEd2FycywgUy4sIGFuZCBULiBQaGlubmV5 LA0iSW5kdXN0cmlhbCBSb3V0aW5nIFJlcXVpcmVtZW50cyBpbiBMb3cgUG93ZXIgYW5kIExvc3N5 DU5ldHdvcmtzIiwgZHJhZnQtaWV0Zi1yb2xsLWluZHVzLXJvdXRpbmctcmVxcy0wNCAod29yayBp bg1wcm9ncmVzcyksIEphbnVhcnkgMjAwOS4NW0ktRC5pZXRmLXJvbGwtdGVybWlub2xvZ3ldDVZh c3NldXIsIEouLCAiVGVybWlub2xvZ3kgaW4gTG93IHBvd2VyIEFuZCBMb3NzeQ1OZXR3b3JrcyIs IGRyYWZ0LWlldGYtcm9sbC10ZXJtaW5vbG9neS0wMCAod29yayBpbg1wcm9ncmVzcyksIE9jdG9i ZXIgMjAwOC4NW0ktRC5pZXRmLXJvbGwtdXJiYW4tcm91dGluZy1yZXFzXQ1Eb2hsZXIsIE0uLCBX YXR0ZXluZSwgVC4sIFdpbnRlciwgVC4sIEJhcnRoZWwsIEQuLA1KYWNxdWVuZXQsIEMuLCBNYWRo dXN1ZGFuLCBHLiwgYW5kIEcuIENoZWdhcmF5LCAiVXJiYW4NV1NOcyBSb3V0aW5nIFJlcXVpcmVt ZW50cyBpbiBMb3cgUG93ZXIgYW5kIExvc3N5DU5ldHdvcmtzIiwgZHJhZnQtaWV0Zi1yb2xsLXVy YmFuLXJvdXRpbmctcmVxcy0wNCAod29yayBpbg1wcm9ncmVzcyksIEZlYnJ1YXJ5IDIwMDkuDVtJ LUQuc3Vob3BhcmstaGVsbG8td3NuXQ1QYXJrLCBTLiwgIlJvdXRpbmcgU2VjdXJpdHkgaW4gU2Vu c29yIE5ldHdvcms6IEhFTExPIEZsb29kDUF0dGFjayBhbmQgRGVmZW5zZSIsIGRyYWZ0LXN1aG9w YXJrLWhlbGxvLXdzbi0wMCAod29yayBpbg1wcm9ncmVzcyksIERlY2VtYmVyIDIwMDUuDVtLYXJs b2YyMDAzXQ1LYXJsb2YsIEMuIGFuZCBELiBXYWduZXIsICJTZWN1cmUgcm91dGluZyBpbiB3aXJl bGVzcw1zZW5zb3IgbmV0d29ya3M6IGF0dGFja3MgYW5kIGNvdW50ZXJtZWFzdXJlcyIsIEVsc2V2 aWVyDUFkSG9jIE5ldHdvcmtzIEpvdXJuYWwsIFNwZWNpYWwgSXNzdWUgb24gU2Vuc29yIE5ldHdv cmsNQXBwbGljYXRpb25zIGFuZCBQcm90b2NvbHMsIDEoMik6MjkzLTMxNSwgU2VwdGVtYmVyIDIw MDMuDVtNeWFnbWFyMjAwNV0NTXlhZ21hciwgUy4sIExlZSwgQUouLCBhbmQgVy4gWXVyY2lrLCAi VGhyZWF0IE1vZGVsaW5nIGFzDWEgQmFzaXMgZm9yIFNlY3VyaXR5IFJlcXVpcmVtZW50cyIsIGlu IFByb2NlZWRpbmdzIG9mIHRoZQ1TeW1wb3NpdW0gb24gUmVxdWlyZW1lbnRzIEVuZ2luZWVyaW5n IGZvciBJbmZvcm1hdGlvbg1TZWN1cml0eSAoU1JFSVMnMDUpLCBQYXJpcywgRnJhbmNlLCBwcC4g OTQtMTAyLCBBdWcNMjksIDIwMDUuDVtSRkM0NTkzXSBCYXJiaXIsIEEuLCBNdXJwaHksIFMuLCBh bmQgWS4gWWFuZywgIkdlbmVyaWMgVGhyZWF0cyB0bw1Sb3V0aW5nIFByb3RvY29scyIsIFJGQyA0 NTkzLCBPY3RvYmVyIDIwMDYuDVtSRkM0OTQ5XSBTaGlyZXksIFIuLCAiSW50ZXJuZXQgU2VjdXJp dHkgR2xvc3NhcnksIFZlcnNpb24gMiIsDVJGQyA0OTQ5LCBBdWd1c3QgMjAwNy4NQXV0aG9ycycg QWRkcmVzc2VzDVR6ZXRhIFRzYW8gKGVkaXRvcikNRWthIFN5c3RlbXMNMjAyMDEgQ2VudHVyeSBC bHZkLiBTdWl0ZSAyNTANR2VybWFudG93biwgTWFyeWxhbmQgMjA4NzQNVVNBDUVtYWlsOiB0emV0 YS50c2FvQGVrYXN5c3RlbXMuY29tDVJvZ2VyIEsuIEFsZXhhbmRlciAoZWRpdG9yKQ1Fa2EgU3lz dGVtcw0yMDIwMSBDZW50dXJ5IEJsdmQuIFN1aXRlIDI1MA1HZXJtYW50b3duLCBNYXJ5bGFuZCAy MDg3NA1VU0ENRW1haWw6IHJvZ2VyLmFsZXhhbmRlckBla2FzeXN0ZW1zLmNvbQ1NaXNjaGEgRG9o bGVyIChlZGl0b3IpDUNUVEMNUGFyYyBNZWRpdGVycmFuaSBkZSBsYSBUZWNub2xvZ2lhLCBBdi4g Q2FuYWwgT2xpbXBpYyBTL04NQ2FzdGVsbGRlZmVscywgQmFyY2Vsb25hIDA4ODYwDVNwYWluDUVt YWlsOiBtaXNjaGEuZG9obGVyQGN0dGMuZXMNVmFuZXNhIERhemEgKGVkaXRvcikNVW5pdmVyc2l0 YXQgUG9tcGV1IEZhYnJhDVAvIENpcmN1bXZhbC5sYWNpbyA4LCBPZmljaW5hIDMwOA1CYXJjZWxv bmEgMDgwMDMNU3BhaW4NRW1haWw6IHZhbmVzYS5kYXphQHVwZi5lZHUNQW5nZWwgTG96YW5vIChl ZGl0b3IpDVVuaXZlcnNpdGF0IFBvbXBldSBGYWJyYQ1QLyBDaXJjdW12YWwubGFjaW8gOCwgT2Zp Y2luYSAzMDkNQmFyY2Vsb25hIDA4MDAzDVNwYWluDUVtYWlsOiBhbmdlbC5sb3phbm9AdXBmLmVk dQ0FSW4gdGhpcyBzY2hlbWUgd2UgY2FuIGFkZCB0d28gZnVuY3Rpb25hbGl0aWVzOg1Ob2RlcyBt YXkgYnVpbGQgbm90IG9ubHkgYSBuZWlnaGJvciBUb3BvbG9neSwgYnV0IGFsc28gYSB0cnVzdCB0 YWJsZQ1Ob2RlcyBtYXkgbm90IG9ubHkgZXhjaGFuZ2Ugcm91dGUvdG9wb2xvZ3kgaW5mb3JtYXRp b24sIGJ1dCBhbHNvIHRydXN0L3JlcHV0YXRpb24gaW5mb3JtYXRpb24NDU1vcmVvdmVyLCBpbiBh biBlbmVyZ3kgZWZmaWNpZW50IGFwcHJvYWNoIHdlIG1heSBhZGQgdGhlIGVuZXJneSBhcyBwYXJ0 IG9mIHRoZSBleGNoYW5nZWQgbWVzc2FnZXM6IHRodXMgdGhlIHJvdXRpbmcgbWF5IGFjaGlldmUg bG9uZ2VyIG5ldHdvcmsgbGlmZXRpbWUuDQ0NAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGAACOFAAAEBUA ANIVAABUFgAAkTIAAJIyAABmNAAApjQAANI0AACkNgAApTYAAOQ2AADgweDB4KXghmfgQeAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAABKAQgBBEgBAAVo3MTUphVoERdkABZoFBRjAENKFABPSgMAUUoDAF5KAwBhShQAbUgJCHNI CQiJygcBAQD1xNSmgyoBbUgJBHNICQQAPRVoERdkABZoFBRjAENKFABPSgMAUUoDAF5KAwBhShQA bUgWBHNIFgSJygcBAQD1xNSmgyoBbUgJBHNICQQ9FWgRF2QAFmgUFGMAQ0oUAE9KAwBRSgMAXkoD AGFKFABtSBAEc0gQBInKBwEBAPXE1KaDKgFtSAkEc0gJBDcDagAAAAAVaBEXZAAWaMB7dwAwShAA VQgBicoHAQEA9cTUpoMqAQNqAAAAAFUIAW1ICQRzSAkEPRVoERdkABZoFBRjAENKFABPSgMAUUoD AF5KAwBhShQAbUgMBHNIDASJygcBAQD1xNSmgyoBbUgJBHNICQQ9FWgRF2QAFmgUFGMAQ0oUAE9K AwBRSgMAXkoDAGFKFABtSAkIc0gJCInKBwEBAPXE1KaDKgFtSAkEc0gJBAAMAAYAACoIAAArCAAA UQgAAHIIAACdCAAAxQgAAMoIAADXCAAA5ggAAP8IAAARCQAAEgkAAFUJAAB7CQAAfAkAAJAJAADW CQAA9wkAADkKAAB5CgAAuQoAAMEKAAAHCwAATAsAAIoLAADFCwAA8QAAAAAAAAAAAAAAAOYAAAAA AAAAAAAAAADmAAAAAAAAAAAAAAAA5gAAAAAAAAAAAAAAAOYAAAAAAAAAAAAAAADmAAAAAAAAAAAA AAAA5gAAAAAAAAAAAAAAAOYAAAAAAAAAAAAAAADmAAAAAAAAAAAAAAAA5gAAAAAAAAAAAAAAAOYA AAAAAAAAAAAAAADmAAAAAAAAAAAAAAAA5gAAAAAAAAAAAAAAAOYAAAAAAAAAAAAAAADmAAAAAAAA AAAAAAAA5gAAAAAAAAAAAAAAAOYAAAAAAAAAAAAAAADmAAAAAAAAAAAAAAAA5gAAAAAAAAAAAAAA AOYAAAAAAAAAAAAAAADmAAAAAAAAAAAAAAAA5gAAAAAAAAAAAAAAAOYAAAAAAAAAAAAAAADmAAAA AAAAAAAAAAAA5gAAAAAAAAAAAAAAAOYAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAsAABOkeAA3 JAA4JABIJABnZBQUYwAOAAADJAETpHgANyQAOCQASCQAYSQBZ2QUFGMAABoABgAAYfUAAM/2AAD+ /gAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAgEBAsULAAD8CwAAKAwAAGkM AACKDAAAvgwAAM8MAAAPDQAANg0AAHQNAACaDQAA2g0AABYOAABcDgAAbg4AAG8OAAB5DgAAug4A APwOAAA7DwAAfw8AAL0PAAD3DwAAPBAAAHwQAACPEAAApRAAAOkQAAAuEQAA9AAAAAAAAAAAAAAA APQAAAAAAAAAAAAAAAD0AAAAAAAAAAAAAAAA9AAAAAAAAAAAAAAAAPQAAAAAAAAAAAAAAAD0AAAA AAAAAAAAAAAA9AAAAAAAAAAAAAAAAPQAAAAAAAAAAAAAAAD0AAAAAAAAAAAAAAAA9AAAAAAAAAAA AAAAAPQAAAAAAAAAAAAAAAD0AAAAAAAAAAAAAAAA9AAAAAAAAAAAAAAAAPQAAAAAAAAAAAAAAAD0 AAAAAAAAAAAAAAAA9AAAAAAAAAAAAAAAAPQAAAAAAAAAAAAAAAD0AAAAAAAAAAAAAAAA9AAAAAAA AAAAAAAAAPQAAAAAAAAAAAAAAAD0AAAAAAAAAAAAAAAA9AAAAAAAAAAAAAAAAPQAAAAAAAAAAAAA AAD0AAAAAAAAAAAAAAAA9AAAAAAAAAAAAAAAAPQAAAAAAAAAAAAAAAD0AAAAAAAAAAAAAAAA9AAA AAAAAAAAAAAAAAAAAAAAAAAACwAAE6R4ADckADgkAEgkAGdkFBRjAAAcLhEAAHERAAByEQAAcxEA AIURAADIEQAADBIAAE8SAACQEgAA0hIAABQTAABYEwAAmxMAANsTAAAUFAAAThQAAJEUAADSFAAA ExUAAFUVAACVFQAA1RUAABYWAABXFgAAmxYAAN4WAAAfFwAAXxcAAJ8XAAD0AAAAAAAAAAAAAAAA 9AAAAAAAAAAAAAAAAPQAAAAAAAAAAAAAAAD0AAAAAAAAAAAAAAAA9AAAAAAAAAAAAAAAAPQAAAAA AAAAAAAAAAD0AAAAAAAAAAAAAAAA9AAAAAAAAAAAAAAAAPQAAAAAAAAAAAAAAAD0AAAAAAAAAAAA AAAA9AAAAAAAAAAAAAAAAPQAAAAAAAAAAAAAAAD0AAAAAAAAAAAAAAAA9AAAAAAAAAAAAAAAAPQA AAAAAAAAAAAAAAD0AAAAAAAAAAAAAAAA9AAAAAAAAAAAAAAAAPQAAAAAAAAAAAAAAAD0AAAAAAAA AAAAAAAA9AAAAAAAAAAAAAAAAPQAAAAAAAAAAAAAAAD0AAAAAAAAAAAAAAAA9AAAAAAAAAAAAAAA APQAAAAAAAAAAAAAAAD0AAAAAAAAAAAAAAAA9AAAAAAAAAAAAAAAAPQAAAAAAAAAAAAAAAD0AAAA AAAAAAAAAAAAAAAAAAAAAAALAAATpHgANyQAOCQASCQAZ2QUFGMAAByfFwAA3xcAAB8YAABiGAAA oxgAAOMYAAAjGQAAYxkAAKUZAAAVGgAAVRoAAJUaAADVGgAAFRsAAFobAACdGwAA4BsAACIcAABk HAAAqBwAAOwcAAAwHQAAdx0AALsdAAD/HQAARR4AAFUeAACKHgAAxR4AAPQAAAAAAAAAAAAAAAD0 AAAAAAAAAAAAAAAA9AAAAAAAAAAAAAAAAPQAAAAAAAAAAAAAAAD0AAAAAAAAAAAAAAAA9AAAAAAA AAAAAAAAAPQAAAAAAAAAAAAAAAD0AAAAAAAAAAAAAAAA9AAAAAAAAAAAAAAAAPQAAAAAAAAAAAAA AAD0AAAAAAAAAAAAAAAA9AAAAAAAAAAAAAAAAPQAAAAAAAAAAAAAAAD0AAAAAAAAAAAAAAAA9AAA AAAAAAAAAAAAAPQAAAAAAAAAAAAAAAD0AAAAAAAAAAAAAAAA9AAAAAAAAAAAAAAAAPQAAAAAAAAA AAAAAAD0AAAAAAAAAAAAAAAA9AAAAAAAAAAAAAAAAPQAAAAAAAAAAAAAAAD0AAAAAAAAAAAAAAAA 9AAAAAAAAAAAAAAAAPQAAAAAAAAAAAAAAAD0AAAAAAAAAAAAAAAA9AAAAAAAAAAAAAAAAPQAAAAA AAAAAAAAAAAAAAAAAAAAAAsAABOkeAA3JAA4JABIJABnZBQUYwAAHMUeAAAFHwAARh8AAF8fAACh HwAAzh8AAM8fAADfHwAAJCAAAGcgAACtIAAA8SAAADQhAAB1IQAAtSEAAPUhAAA7IgAAfCIAAMEi AAAFIwAASSMAAI0jAADNIwAA6CMAACckAABoJAAAqyQAAOskAAAxJQAA9AAAAAAAAAAAAAAAAPQA AAAAAAAAAAAAAAD0AAAAAAAAAAAAAAAA9AAAAAAAAAAAAAAAAPQAAAAAAAAAAAAAAAD0AAAAAAAA AAAAAAAA9AAAAAAAAAAAAAAAAPQAAAAAAAAAAAAAAAD0AAAAAAAAAAAAAAAA9AAAAAAAAAAAAAAA APQAAAAAAAAAAAAAAAD0AAAAAAAAAAAAAAAA9AAAAAAAAAAAAAAAAPQAAAAAAAAAAAAAAAD0AAAA AAAAAAAAAAAA9AAAAAAAAAAAAAAAAPQAAAAAAAAAAAAAAAD0AAAAAAAAAAAAAAAA9AAAAAAAAAAA AAAAAPQAAAAAAAAAAAAAAAD0AAAAAAAAAAAAAAAA9AAAAAAAAAAAAAAAAPQAAAAAAAAAAAAAAAD0 AAAAAAAAAAAAAAAA9AAAAAAAAAAAAAAAAPQAAAAAAAAAAAAAAAD0AAAAAAAAAAAAAAAA9AAAAAAA AAAAAAAAAAAAAAAAAAAACwAAE6R4ADckADgkAEgkAGdkFBRjAAAcMSUAAHQlAACIJQAAiSUAAKwl AADwJQAAMiYAAHUmAAC0JgAA+CYAADsnAAB4JwAAuicAAP0nAAADKAAALCgAAHAoAAC1KAAA+CgA ADkpAAB5KQAAuikAAPQpAAA3KgAAeSoAALgqAAD+KgAAQisAAIIrAAD0AAAAAAAAAAAAAAAA9AAA AAAAAAAAAAAAAPQAAAAAAAAAAAAAAAD0AAAAAAAAAAAAAAAA9AAAAAAAAAAAAAAAAPQAAAAAAAAA AAAAAAD0AAAAAAAAAAAAAAAA9AAAAAAAAAAAAAAAAPQAAAAAAAAAAAAAAAD0AAAAAAAAAAAAAAAA 9AAAAAAAAAAAAAAAAPQAAAAAAAAAAAAAAAD0AAAAAAAAAAAAAAAA9AAAAAAAAAAAAAAAAPQAAAAA AAAAAAAAAAD0AAAAAAAAAAAAAAAA9AAAAAAAAAAAAAAAAPQAAAAAAAAAAAAAAAD0AAAAAAAAAAAA AAAA9AAAAAAAAAAAAAAAAPQAAAAAAAAAAAAAAAD0AAAAAAAAAAAAAAAA9AAAAAAAAAAAAAAAAPQA AAAAAAAAAAAAAAD0AAAAAAAAAAAAAAAA9AAAAAAAAAAAAAAAAPQAAAAAAAAAAAAAAAD0AAAAAAAA AAAAAAAAAAAAAAAAAAALAAATpHgANyQAOCQASCQAZ2QUFGMAAByCKwAAxysAAAksAABNLAAAjiwA ANEsAAAXLQAAXS0AAKAtAADjLQAAHy4AAGEuAACeLgAA4S4AACAvAABiLwAAqC8AAL0vAAD8LwAA QTAAAIUwAADIMAAADjEAAFIxAACXMQAA1jEAABgyAABbMgAAlDIAAPQAAAAAAAAAAAAAAAD0AAAA AAAAAAAAAAAA9AAAAAAAAAAAAAAAAPQAAAAAAAAAAAAAAAD0AAAAAAAAAAAAAAAA9AAAAAAAAAAA AAAAAPQAAAAAAAAAAAAAAAD0AAAAAAAAAAAAAAAA9AAAAAAAAAAAAAAAAPQAAAAAAAAAAAAAAAD0 AAAAAAAAAAAAAAAA9AAAAAAAAAAAAAAAAPQAAAAAAAAAAAAAAAD0AAAAAAAAAAAAAAAA9AAAAAAA AAAAAAAAAPQAAAAAAAAAAAAAAAD0AAAAAAAAAAAAAAAA9AAAAAAAAAAAAAAAAPQAAAAAAAAAAAAA AAD0AAAAAAAAAAAAAAAA9AAAAAAAAAAAAAAAAPQAAAAAAAAAAAAAAAD0AAAAAAAAAAAAAAAA9AAA AAAAAAAAAAAAAPQAAAAAAAAAAAAAAAD0AAAAAAAAAAAAAAAA9AAAAAAAAAAAAAAAAPQAAAAAAAAA AAAAAAAAAAAAAAAAAAsAABOkeAA3JAA4JABIJABnZBQUYwAAHJQyAADIMgAAzDIAAOIyAAAfMwAA NTMAADszAABpMwAAejMAAIkzAACwMwAAuzMAAMEzAADgMwAAFDQAABY0AAAkNAAAXDQAAGY0AAB8 NAAAhTQAAKY0AACvNAAA0jQAAOU0AAAeNQAAPDUAAE01AAB0NQAA9AAAAAAAAAAAAAAAAPQAAAAA AAAAAAAAAAD0AAAAAAAAAAAAAAAA9AAAAAAAAAAAAAAAAPQAAAAAAAAAAAAAAAD0AAAAAAAAAAAA AAAA9AAAAAAAAAAAAAAAAPQAAAAAAAAAAAAAAAD0AAAAAAAAAAAAAAAA9AAAAAAAAAAAAAAAAPQA AAAAAAAAAAAAAAD0AAAAAAAAAAAAAAAA9AAAAAAAAAAAAAAAAPQAAAAAAAAAAAAAAAD0AAAAAAAA AAAAAAAA9AAAAAAAAAAAAAAAAPQAAAAAAAAAAAAAAAD0AAAAAAAAAAAAAAAA9AAAAAAAAAAAAAAA APQAAAAAAAAAAAAAAAD0AAAAAAAAAAAAAAAA9AAAAAAAAAAAAAAAAPQAAAAAAAAAAAAAAAD0AAAA AAAAAAAAAAAA9AAAAAAAAAAAAAAAAPQAAAAAAAAAAAAAAAD0AAAAAAAAAAAAAAAA9AAAAAAAAAAA AAAAAAAAAAAAAAAACwAAE6R4ADckADgkAEgkAGdkFBRjAAAcdDUAAKM1AADfNQAA6DUAACE2AABZ NgAAdDYAAIo2AAClNgAA5DYAACs3AAD0AAAAAAAAAAAAAAAA9AAAAAAAAAAAAAAAAPQAAAAAAAAA AAAAAAD0AAAAAAAAAAAAAAAA9AAAAAAAAAAAAAAAAPQAAAAAAAAAAAAAAAD0AAAAAAAAAAAAAAAA 9AAAAAAAAAAAAAAAAOkAAAAAAAAAAAAAAACbAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAE4AABOkeAA3JAA4JABDJAFFxoAAAAEA3cTUpgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEgkAGdkFBRjAAsAABOkeAA3JAA4 JABIJABnZF5TPQALAAATpHgANyQAOCQASCQAZ2QUFGMAAArkNgAA7jYAAO82AAD+NgAAFDcAACc3 AAArNwAALDcAAHw3AAB9NwAA7jgAAO84AADfOgAA4DoAAGM+AABkPgAAuEMAANFDAADjQwAA2rTa jtqOtI7ab7RvtG+0b0lvAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAEoBCAEESAEABWjhxNSmFWgRF2QAFmheUz0AQ0oUAE9KAwBRSgMAXkoDAGFKFABt SAkIc0gJCInKBwEBAPXE1KaDKgFtSAkEc0gJBAA9FWgRF2QAFmgUFGMAQ0oUAE9KAwBRSgMAXkoD AGFKFABtSAkIc0gJCInKBwEBAPXE1KaDKgFtSAkEc0gJBEoBCAEESAEABWjexNSmFWgRF2QAFmhe Uz0AQ0oUAE9KAwBRSgMAXkoDAGFKFABtSAkIc0gJCInKBwEBAPXE1KaDKgFtSAkEc0gJBABKAQgB BEgBAAVo38TUphVoERdkABZoXlM9AENKFABPSgMAUUoDAF5KAwBhShQAbUgJCHNICQiJygcBAQD1 xNSmgyoBbUgJBHNICQQASgEIAQRIAQAFaN3E1KYVaBEXZAAWaF5TPQBDShQAT0oDAFFKAwBeSgMA YUoUAG1ICQhzSAkIicoHAQEA9cTUpoMqAW1ICQRzSAkEEis3AAA/NwAAXDcAAH03AADANwAA7jcA ABQ4AABWOAAAljgAANk4AADuOAAAsQAAAAAAAAAAAAAAALEAAAAAAAAAAAAAAACxAAAAAAAAAAAA AAAApgAAAAAAAAAAAAAAAKYAAAAAAAAAAAAAAACmAAAAAAAAAAAAAAAApgAAAAAAAAAAAAAAAKYA AAAAAAAAAAAAAACmAAAAAAAAAAAAAAAApgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACwAAE6R4ADckADgkAEgkAGdkFBRjAE4AABOkeAA3JAA4 JABDJAFFxoAAAAEA3sTUpgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAEgkAGdkXlM9AAAK7jgAAO84AAD/OAAAPjkAAH05AAC9OQAA +jkAADo6AABzOgAApzoAAN86AADgOgAA6joAACg7AABoOwAAqDsAAOc7AAAnPAAAZjwAAKM8AACx AAAAAAAAAAAAAAAApgAAAAAAAAAAAAAAAKYAAAAAAAAAAAAAAACmAAAAAAAAAAAAAAAApgAAAAAA AAAAAAAAAKYAAAAAAAAAAAAAAACmAAAAAAAAAAAAAAAApgAAAAAAAAAAAAAAAKYAAAAAAAAAAAAA AACmAAAAAAAAAAAAAAAAsQAAAAAAAAAAAAAAAKYAAAAAAAAAAAAAAACmAAAAAAAAAAAAAAAApgAA AAAAAAAAAAAAAKYAAAAAAAAAAAAAAACmAAAAAAAAAAAAAAAApgAAAAAAAAAAAAAAAKYAAAAAAAAA AAAAAACmAAAAAAAAAAAAAAAAAAAAAAALAAATpHgANyQAOCQASCQAZ2QUFGMATgAAE6R4ADckADgk AEMkAUXGgAAAAQDfxNSmAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAASCQAZ2QUFGMAABOjPAAAuTwAALo8AADHPAAAAz0AAEM9AACB PQAAwT0AAAE+AAA6PgAAYz4AAGQ+AACuPgAA5T4AACs/AABsPwAArj8AAO0/AAAsQAAAb0AAAPQA AAAAAAAAAAAAAAD0AAAAAAAAAAAAAAAA9AAAAAAAAAAAAAAAAPQAAAAAAAAAAAAAAAD0AAAAAAAA AAAAAAAA9AAAAAAAAAAAAAAAAPQAAAAAAAAAAAAAAAD0AAAAAAAAAAAAAAAA9AAAAAAAAAAAAAAA APQAAAAAAAAAAAAAAACmAAAAAAAAAAAAAAAA9AAAAAAAAAAAAAAAAPQAAAAAAAAAAAAAAAD0AAAA AAAAAAAAAAAA9AAAAAAAAAAAAAAAAPQAAAAAAAAAAAAAAAD0AAAAAAAAAAAAAAAA9AAAAAAAAAAA AAAAAPQAAAAAAAAAAAAAAAAAAAAAAE4AABOkeAA3JAA4JABDJAFFxoAAAAEA38TUpgAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEgk AGdkFBRjAAsAABOkeAA3JAA4JABIJABnZBQUYwAAE29AAAC0QAAA+UAAAD5BAACBQQAAkUEAANNB AAAHQgAAR0IAAIhCAACNQgAAz0IAAOVCAAAiQwAAY0MAAIxDAADJQwAA5EMAAP5DAAD0AAAAAAAA AAAAAAAA9AAAAAAAAAAAAAAAAPQAAAAAAAAAAAAAAAD0AAAAAAAAAAAAAAAA9AAAAAAAAAAAAAAA APQAAAAAAAAAAAAAAAD0AAAAAAAAAAAAAAAA9AAAAAAAAAAAAAAAAPQAAAAAAAAAAAAAAAD0AAAA AAAAAAAAAAAA9AAAAAAAAAAAAAAAAPQAAAAAAAAAAAAAAAD0AAAAAAAAAAAAAAAA9AAAAAAAAAAA AAAAAPQAAAAAAAAAAAAAAADpAAAAAAAAAAAAAAAAmwAAAAAAAAAAAAAAAOkAAAAAAAAAAAAAAABO AAATpHgANyQAOCQAQyQBRcaAAAABAOHE1KYAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABIJABnZF5TPQALAAATpHgANyQAOCQASCQA Z2ReUz0ACwAAE6R4ADckADgkAEgkAGdkFBRjAAAS40MAAORDAADlQwAA5EQAAOVEAABuWwAAkVsA AGm1AAB+tQAAo7UAAKS1AAA4zAAA0auMZoxHjC+ML4wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAC8BCIEESAEABWj5xNSmFmgRF2QAQ0oUAE9KAwBRSgMAXkoDAGFKFABtSAkEc0gJ BD0VaBEXZAAWaBQUYwBDShQAT0oDAFFKAwBeSgMAYUoUAG1IFgRzSBYEicoHAQEA9cTUpoMqAW1I CQRzSAkESgEIAQRIAQAFaODE1KYVaBEXZAAWaF5TPQBDShQAT0oDAFFKAwBeSgMAYUoUAG1ICQhz SAkIicoHAQEA9cTUpoMqAW1ICQRzSAkEAD0VaBEXZAAWaBQUYwBDShQAT0oDAFFKAwBeSgMAYUoU AG1ICQhzSAkIicoHAQEA9cTUpoMqAW1ICQRzSAkESgEIAQRIAQAFaOHE1KYVaBEXZAAWaF5TPQBD ShQAT0oDAFFKAwBeSgMAYUoUAG1ICQhzSAkIicoHAQEA9cTUpoMqAW1ICQRzSAkEAFwACAEVaBEX ZAAWaBQUYwAXaF5TPQBDShQAT0oDAFFKAwBeSgMAYUoUAGNIAQBkaAAAAABkaAAAAABkaOHE1KZt SAkIc0gJCInKBwEBAPXE1KaDKgFtSAkEc0gJBAv+QwAAOkQAAHtEAAC9RAAA5EQAAOVEAAAnRQAA Z0UAAKlFAADsRQAA9kUAACNGAABmRgAAikYAALFGAAD2RgAAPEcAAH9HAAC4RwAA9UcAAPQAAAAA AAAAAAAAAAD0AAAAAAAAAAAAAAAA9AAAAAAAAAAAAAAAAPQAAAAAAAAAAAAAAACmAAAAAAAAAAAA AAAA9AAAAAAAAAAAAAAAAPQAAAAAAAAAAAAAAAD0AAAAAAAAAAAAAAAA9AAAAAAAAAAAAAAAAPQA AAAAAAAAAAAAAAD0AAAAAAAAAAAAAAAA9AAAAAAAAAAAAAAAAPQAAAAAAAAAAAAAAAD0AAAAAAAA AAAAAAAA9AAAAAAAAAAAAAAAAPQAAAAAAAAAAAAAAAD0AAAAAAAAAAAAAAAA9AAAAAAAAAAAAAAA APQAAAAAAAAAAAAAAAAAAAAAAE4AABOkeAA3JAA4JABDJAFFxoAAAAEA4MTUpgAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEgkAGdk FBRjAAsAABOkeAA3JAA4JABIJABnZBQUYwAAE/VHAAA1SAAAc0gAALBIAADvSAAAKkkAAENJAABl SQAAoEkAAOFJAAAXSgAAVEoAAJNKAACfSgAAoEoAALZKAADvSgAALksAAG5LAACpSwAAxEsAAARM AAA/TAAAfEwAALlMAADQTAAAA00AAD5NAAB8TQAA9AAAAAAAAAAAAAAAAPQAAAAAAAAAAAAAAAD0 AAAAAAAAAAAAAAAA9AAAAAAAAAAAAAAAAPQAAAAAAAAAAAAAAAD0AAAAAAAAAAAAAAAA9AAAAAAA AAAAAAAAAPQAAAAAAAAAAAAAAAD0AAAAAAAAAAAAAAAA9AAAAAAAAAAAAAAAAPQAAAAAAAAAAAAA AAD0AAAAAAAAAAAAAAAA9AAAAAAAAAAAAAAAAPQAAAAAAAAAAAAAAAD0AAAAAAAAAAAAAAAA9AAA AAAAAAAAAAAAAPQAAAAAAAAAAAAAAAD0AAAAAAAAAAAAAAAA9AAAAAAAAAAAAAAAAPQAAAAAAAAA AAAAAAD0AAAAAAAAAAAAAAAA9AAAAAAAAAAAAAAAAPQAAAAAAAAAAAAAAAD0AAAAAAAAAAAAAAAA 9AAAAAAAAAAAAAAAAPQAAAAAAAAAAAAAAAD0AAAAAAAAAAAAAAAA9AAAAAAAAAAAAAAAAAAAAAAA AAAACwAAE6R4ADckADgkAEgkAGdkFBRjAAAcfE0AALZNAADzTQAAH04AACBOAAA1TgAAcE4AAK5O AADmTgAAJU8AAGNPAACbTwAAvU8AAPpPAAA4UAAAeFAAALRQAADxUAAAMFEAAHBRAACxUQAA9VEA ADhSAAB6UgAAulIAAPxSAABCUwAAhlMAAMBTAAD0AAAAAAAAAAAAAAAA9AAAAAAAAAAAAAAAAPQA AAAAAAAAAAAAAAD0AAAAAAAAAAAAAAAA9AAAAAAAAAAAAAAAAPQAAAAAAAAAAAAAAAD0AAAAAAAA AAAAAAAA9AAAAAAAAAAAAAAAAPQAAAAAAAAAAAAAAAD0AAAAAAAAAAAAAAAA9AAAAAAAAAAAAAAA APQAAAAAAAAAAAAAAAD0AAAAAAAAAAAAAAAA9AAAAAAAAAAAAAAAAPQAAAAAAAAAAAAAAAD0AAAA AAAAAAAAAAAA9AAAAAAAAAAAAAAAAPQAAAAAAAAAAAAAAAD0AAAAAAAAAAAAAAAA9AAAAAAAAAAA AAAAAPQAAAAAAAAAAAAAAAD0AAAAAAAAAAAAAAAA9AAAAAAAAAAAAAAAAPQAAAAAAAAAAAAAAAD0 AAAAAAAAAAAAAAAA9AAAAAAAAAAAAAAAAPQAAAAAAAAAAAAAAAD0AAAAAAAAAAAAAAAAAAAAAAAA AAALAAATpHgANyQAOCQASCQAZ2QUFGMAABzAUwAAwVMAANhTAAAaVAAAYFQAAKBUAADiVAAAJFUA AGlVAACuVQAA8lUAADJWAAB2VgAAulYAAPtWAABBVwAAg1cAAMBXAAAFWAAAGlgAABtYAABHWAAA i1gAAMlYAADqWAAAKFkAAGlZAACFWQAAy1kAAPQAAAAAAAAAAAAAAAD0AAAAAAAAAAAAAAAA9AAA AAAAAAAAAAAAAPQAAAAAAAAAAAAAAAD0AAAAAAAAAAAAAAAA9AAAAAAAAAAAAAAAAPQAAAAAAAAA AAAAAAD0AAAAAAAAAAAAAAAA9AAAAAAAAAAAAAAAAPQAAAAAAAAAAAAAAAD0AAAAAAAAAAAAAAAA 9AAAAAAAAAAAAAAAAPQAAAAAAAAAAAAAAAD0AAAAAAAAAAAAAAAA9AAAAAAAAAAAAAAAAPQAAAAA AAAAAAAAAAD0AAAAAAAAAAAAAAAA9AAAAAAAAAAAAAAAAPQAAAAAAAAAAAAAAAD0AAAAAAAAAAAA AAAA9AAAAAAAAAAAAAAAAPQAAAAAAAAAAAAAAAD0AAAAAAAAAAAAAAAA9AAAAAAAAAAAAAAAAPQA AAAAAAAAAAAAAAD0AAAAAAAAAAAAAAAA9AAAAAAAAAAAAAAAAPQAAAAAAAAAAAAAAAAAAAAAAAAA AAsAABOkeAA3JAA4JABIJABnZBQUYwAAHMtZAAAKWgAAT1oAAJNaAADQWgAA51oAAClbAABuWwAA hVsAAJFbAAClWwAA51sAAChcAABqXAAArlwAAO5cAAAzXQAAc10AALhdAAD+XQAAMF4AAHZeAAC2 XgAAzl4AAOxeAAAuXwAAb18AAK1fAADzXwAA9AAAAAAAAAAAAAAAAPQAAAAAAAAAAAAAAAD0AAAA AAAAAAAAAAAA9AAAAAAAAAAAAAAAAPQAAAAAAAAAAAAAAAD0AAAAAAAAAAAAAAAA9AAAAAAAAAAA AAAAAPQAAAAAAAAAAAAAAAD0AAAAAAAAAAAAAAAA9AAAAAAAAAAAAAAAAPQAAAAAAAAAAAAAAAD0 AAAAAAAAAAAAAAAA9AAAAAAAAAAAAAAAAPQAAAAAAAAAAAAAAAD0AAAAAAAAAAAAAAAA9AAAAAAA AAAAAAAAAPQAAAAAAAAAAAAAAAD0AAAAAAAAAAAAAAAA9AAAAAAAAAAAAAAAAPQAAAAAAAAAAAAA AAD0AAAAAAAAAAAAAAAA9AAAAAAAAAAAAAAAAPQAAAAAAAAAAAAAAAD0AAAAAAAAAAAAAAAA9AAA AAAAAAAAAAAAAPQAAAAAAAAAAAAAAAD0AAAAAAAAAAAAAAAA9AAAAAAAAAAAAAAAAAAAAAAAAAAA CwAAE6R4ADckADgkAEgkAGdkFBRjAAAc818AABJgAAA4YAAAfmAAAMFgAADpYAAALWEAAHFhAAC1 YQAA9mEAADViAABuYgAAsWIAAPFiAAA0YwAAQGMAAINjAACLYwAAxGMAAOJjAAAAZAAAJmQAAGlk AACqZAAA72QAADNlAAB5ZQAAvmUAAABmAAD0AAAAAAAAAAAAAAAA9AAAAAAAAAAAAAAAAPQAAAAA AAAAAAAAAAD0AAAAAAAAAAAAAAAA9AAAAAAAAAAAAAAAAPQAAAAAAAAAAAAAAAD0AAAAAAAAAAAA AAAA9AAAAAAAAAAAAAAAAPQAAAAAAAAAAAAAAAD0AAAAAAAAAAAAAAAA9AAAAAAAAAAAAAAAAPQA AAAAAAAAAAAAAAD0AAAAAAAAAAAAAAAA9AAAAAAAAAAAAAAAAPQAAAAAAAAAAAAAAAD0AAAAAAAA AAAAAAAA9AAAAAAAAAAAAAAAAPQAAAAAAAAAAAAAAAD0AAAAAAAAAAAAAAAA9AAAAAAAAAAAAAAA APQAAAAAAAAAAAAAAAD0AAAAAAAAAAAAAAAA9AAAAAAAAAAAAAAAAPQAAAAAAAAAAAAAAAD0AAAA AAAAAAAAAAAA9AAAAAAAAAAAAAAAAPQAAAAAAAAAAAAAAAD0AAAAAAAAAAAAAAAAAAAAAAAAAAAL AAATpHgANyQAOCQASCQAZ2QUFGMAABwAZgAARGYAAIlmAADOZgAAEmcAAC9nAABVZwAAc2cAAJxn AADZZwAAH2gAAGNoAABvaAAAomgAAONoAAApaQAAaGkAAH5pAADDaQAA1GkAAPJpAAAaagAALmoA AFtqAACeagAA4WoAACRrAABiawAAnWsAAPQAAAAAAAAAAAAAAAD0AAAAAAAAAAAAAAAA9AAAAAAA AAAAAAAAAPQAAAAAAAAAAAAAAAD0AAAAAAAAAAAAAAAA9AAAAAAAAAAAAAAAAPQAAAAAAAAAAAAA AAD0AAAAAAAAAAAAAAAA9AAAAAAAAAAAAAAAAPQAAAAAAAAAAAAAAAD0AAAAAAAAAAAAAAAA9AAA AAAAAAAAAAAAAPQAAAAAAAAAAAAAAAD0AAAAAAAAAAAAAAAA9AAAAAAAAAAAAAAAAPQAAAAAAAAA AAAAAAD0AAAAAAAAAAAAAAAA9AAAAAAAAAAAAAAAAPQAAAAAAAAAAAAAAAD0AAAAAAAAAAAAAAAA 9AAAAAAAAAAAAAAAAPQAAAAAAAAAAAAAAAD0AAAAAAAAAAAAAAAA9AAAAAAAAAAAAAAAAPQAAAAA AAAAAAAAAAD0AAAAAAAAAAAAAAAA9AAAAAAAAAAAAAAAAPQAAAAAAAAAAAAAAAAAAAAAAAAAAAsA ABOkeAA3JAA4JABIJABnZBQUYwAAHJ1rAADbawAA7msAAA5sAAAibAAANmwAAGBsAACibAAA5mwA ACdtAABnbQAArG0AAOttAAAtbgAAcm4AALRuAAD6bgAANW8AAFJvAABybwAAtG8AAPpvAAA6cAAA eXAAALlwAAD7cAAAPHEAAH5xAADCcQAA9AAAAAAAAAAAAAAAAPQAAAAAAAAAAAAAAAD0AAAAAAAA AAAAAAAA9AAAAAAAAAAAAAAAAPQAAAAAAAAAAAAAAAD0AAAAAAAAAAAAAAAA9AAAAAAAAAAAAAAA APQAAAAAAAAAAAAAAAD0AAAAAAAAAAAAAAAA9AAAAAAAAAAAAAAAAPQAAAAAAAAAAAAAAAD0AAAA AAAAAAAAAAAA9AAAAAAAAAAAAAAAAPQAAAAAAAAAAAAAAAD0AAAAAAAAAAAAAAAA9AAAAAAAAAAA AAAAAPQAAAAAAAAAAAAAAAD0AAAAAAAAAAAAAAAA9AAAAAAAAAAAAAAAAPQAAAAAAAAAAAAAAAD0 AAAAAAAAAAAAAAAA9AAAAAAAAAAAAAAAAPQAAAAAAAAAAAAAAAD0AAAAAAAAAAAAAAAA9AAAAAAA AAAAAAAAAPQAAAAAAAAAAAAAAAD0AAAAAAAAAAAAAAAA9AAAAAAAAAAAAAAAAAAAAAAAAAAACwAA E6R4ADckADgkAEgkAGdkFBRjAAAcwnEAAPpxAAA2cgAAdXIAALZyAAD3cgAANHMAAHRzAACzcwAA 83MAAAh0AAAudAAAVHQAAHx0AACQdAAAo3QAAOZ0AAApdQAAbnUAAK11AADvdQAAKHYAAG52AACt dgAA2XYAAB93AABjdwAAqHcAAOt3AAD0AAAAAAAAAAAAAAAA9AAAAAAAAAAAAAAAAPQAAAAAAAAA AAAAAAD0AAAAAAAAAAAAAAAA9AAAAAAAAAAAAAAAAPQAAAAAAAAAAAAAAAD0AAAAAAAAAAAAAAAA 9AAAAAAAAAAAAAAAAPQAAAAAAAAAAAAAAAD0AAAAAAAAAAAAAAAA9AAAAAAAAAAAAAAAAPQAAAAA AAAAAAAAAAD0AAAAAAAAAAAAAAAA9AAAAAAAAAAAAAAAAPQAAAAAAAAAAAAAAAD0AAAAAAAAAAAA AAAA9AAAAAAAAAAAAAAAAPQAAAAAAAAAAAAAAAD0AAAAAAAAAAAAAAAA9AAAAAAAAAAAAAAAAPQA AAAAAAAAAAAAAAD0AAAAAAAAAAAAAAAA9AAAAAAAAAAAAAAAAPQAAAAAAAAAAAAAAAD0AAAAAAAA AAAAAAAA9AAAAAAAAAAAAAAAAPQAAAAAAAAAAAAAAAD0AAAAAAAAAAAAAAAAAAAAAAAAAAALAAAT pHgANyQAOCQASCQAZ2QUFGMAABzrdwAAMXgAAHd4AAC8eAAA4ngAABB5AABVeQAAlXkAANp5AAAG egAASHoAAIx6AADLegAADHsAAE57AACDewAAyHsAAA18AABJfAAAhnwAAMZ8AAADfQAAE30AAFh9 AACcfQAA4H0AABN+AAA2fgAAeH4AAPQAAAAAAAAAAAAAAAD0AAAAAAAAAAAAAAAA9AAAAAAAAAAA AAAAAPQAAAAAAAAAAAAAAAD0AAAAAAAAAAAAAAAA9AAAAAAAAAAAAAAAAPQAAAAAAAAAAAAAAAD0 AAAAAAAAAAAAAAAA9AAAAAAAAAAAAAAAAPQAAAAAAAAAAAAAAAD0AAAAAAAAAAAAAAAA9AAAAAAA AAAAAAAAAPQAAAAAAAAAAAAAAAD0AAAAAAAAAAAAAAAA9AAAAAAAAAAAAAAAAPQAAAAAAAAAAAAA AAD0AAAAAAAAAAAAAAAA9AAAAAAAAAAAAAAAAPQAAAAAAAAAAAAAAAD0AAAAAAAAAAAAAAAA9AAA AAAAAAAAAAAAAPQAAAAAAAAAAAAAAAD0AAAAAAAAAAAAAAAA9AAAAAAAAAAAAAAAAPQAAAAAAAAA AAAAAAD0AAAAAAAAAAAAAAAA9AAAAAAAAAAAAAAAAPQAAAAAAAAAAAAAAAAAAAAAAAAAAAsAABOk eAA3JAA4JABIJABnZBQUYwAAHHh+AAC9fgAA/34AAEJ/AACFfwAAy38AAAuAAAAygAAAdYAAALWA AAD6gAAAQIEAAIOBAADHgQAACYIAAEqCAACPggAA0oIAABGDAABIgwAAjIMAAMeDAAAEhAAAQ4QA AIOEAADBhAAABYUAAESFAACJhQAA9AAAAAAAAAAAAAAAAPQAAAAAAAAAAAAAAAD0AAAAAAAAAAAA AAAA9AAAAAAAAAAAAAAAAPQAAAAAAAAAAAAAAAD0AAAAAAAAAAAAAAAA9AAAAAAAAAAAAAAAAPQA AAAAAAAAAAAAAAD0AAAAAAAAAAAAAAAA9AAAAAAAAAAAAAAAAPQAAAAAAAAAAAAAAAD0AAAAAAAA AAAAAAAA9AAAAAAAAAAAAAAAAPQAAAAAAAAAAAAAAAD0AAAAAAAAAAAAAAAA9AAAAAAAAAAAAAAA APQAAAAAAAAAAAAAAAD0AAAAAAAAAAAAAAAA9AAAAAAAAAAAAAAAAPQAAAAAAAAAAAAAAAD0AAAA AAAAAAAAAAAA9AAAAAAAAAAAAAAAAPQAAAAAAAAAAAAAAAD0AAAAAAAAAAAAAAAA9AAAAAAAAAAA AAAAAPQAAAAAAAAAAAAAAAD0AAAAAAAAAAAAAAAA9AAAAAAAAAAAAAAAAAAAAAAAAAAACwAAE6R4 ADckADgkAEgkAGdkFBRjAAAciYUAAM6FAAAQhgAAVoYAAJqGAADRhgAAFocAAFmHAACRhwAA04cA AP2HAAA0iAAAeIgAALmIAADoiAAAC4kAAEWJAACLiQAAy4kAABCKAABRigAAkYoAANSKAAAYiwAA XIsAAKCLAADiiwAAI4wAAC2MAAD0AAAAAAAAAAAAAAAA9AAAAAAAAAAAAAAAAPQAAAAAAAAAAAAA AAD0AAAAAAAAAAAAAAAA9AAAAAAAAAAAAAAAAPQAAAAAAAAAAAAAAAD0AAAAAAAAAAAAAAAA9AAA AAAAAAAAAAAAAPQAAAAAAAAAAAAAAAD0AAAAAAAAAAAAAAAA9AAAAAAAAAAAAAAAAPQAAAAAAAAA AAAAAAD0AAAAAAAAAAAAAAAA9AAAAAAAAAAAAAAAAPQAAAAAAAAAAAAAAAD0AAAAAAAAAAAAAAAA 9AAAAAAAAAAAAAAAAPQAAAAAAAAAAAAAAAD0AAAAAAAAAAAAAAAA9AAAAAAAAAAAAAAAAPQAAAAA AAAAAAAAAAD0AAAAAAAAAAAAAAAA9AAAAAAAAAAAAAAAAPQAAAAAAAAAAAAAAAD0AAAAAAAAAAAA AAAA9AAAAAAAAAAAAAAAAPQAAAAAAAAAAAAAAAD0AAAAAAAAAAAAAAAAAAAAAAAAAAALAAATpHgA NyQAOCQASCQAZ2QUFGMAABwtjAAAb4wAALSMAADyjAAAOI0AAHiNAAC1jQAA+I0AADWOAAB5jgAA v44AAPyOAAA8jwAAfY8AAMOPAAAFkAAAS5AAAI6QAADJkAAACZEAAEmRAACFkQAAhpEAALORAAD0 kQAAOZIAAHqSAAC5kgAA+pIAAPQAAAAAAAAAAAAAAAD0AAAAAAAAAAAAAAAA9AAAAAAAAAAAAAAA APQAAAAAAAAAAAAAAAD0AAAAAAAAAAAAAAAA9AAAAAAAAAAAAAAAAPQAAAAAAAAAAAAAAAD0AAAA AAAAAAAAAAAA9AAAAAAAAAAAAAAAAPQAAAAAAAAAAAAAAAD0AAAAAAAAAAAAAAAA9AAAAAAAAAAA AAAAAPQAAAAAAAAAAAAAAAD0AAAAAAAAAAAAAAAA9AAAAAAAAAAAAAAAAPQAAAAAAAAAAAAAAAD0 AAAAAAAAAAAAAAAA9AAAAAAAAAAAAAAAAPQAAAAAAAAAAAAAAAD0AAAAAAAAAAAAAAAA9AAAAAAA AAAAAAAAAPQAAAAAAAAAAAAAAAD0AAAAAAAAAAAAAAAA9AAAAAAAAAAAAAAAAPQAAAAAAAAAAAAA AAD0AAAAAAAAAAAAAAAA9AAAAAAAAAAAAAAAAPQAAAAAAAAAAAAAAAAAAAAAAAAAAAsAABOkeAA3 JAA4JABIJABnZBQUYwAAHPqSAAA+kwAAg5MAAMOTAAAHlAAAMJQAAGuUAACwlAAA9ZQAADKVAAB4 lQAAuZUAAPyVAAA+lgAAV5YAAJmWAADclgAAIpcAAGiXAACslwAA8ZcAADKYAABymAAAtJgAAOGY AAAlmQAAYZkAAKWZAADjmQAA9AAAAAAAAAAAAAAAAPQAAAAAAAAAAAAAAAD0AAAAAAAAAAAAAAAA 9AAAAAAAAAAAAAAAAPQAAAAAAAAAAAAAAAD0AAAAAAAAAAAAAAAA9AAAAAAAAAAAAAAAAPQAAAAA AAAAAAAAAAD0AAAAAAAAAAAAAAAA9AAAAAAAAAAAAAAAAPQAAAAAAAAAAAAAAAD0AAAAAAAAAAAA AAAA9AAAAAAAAAAAAAAAAPQAAAAAAAAAAAAAAAD0AAAAAAAAAAAAAAAA9AAAAAAAAAAAAAAAAPQA AAAAAAAAAAAAAAD0AAAAAAAAAAAAAAAA9AAAAAAAAAAAAAAAAPQAAAAAAAAAAAAAAAD0AAAAAAAA AAAAAAAA9AAAAAAAAAAAAAAAAPQAAAAAAAAAAAAAAAD0AAAAAAAAAAAAAAAA9AAAAAAAAAAAAAAA APQAAAAAAAAAAAAAAAD0AAAAAAAAAAAAAAAA9AAAAAAAAAAAAAAAAAAAAAAAAAAACwAAE6R4ADck ADgkAEgkAGdkFBRjAAAc45kAACmaAABumgAAsZoAAPWaAAA2mwAAW5sAAJ6bAADkmwAAKJwAAG6c AACznAAA+ZwAADudAAB9nQAAup0AAMadAAALngAATp4AAJCeAADRngAAFZ8AAFefAACWnwAA258A AB2gAABgoAAAo6AAAKugAAD0AAAAAAAAAAAAAAAA9AAAAAAAAAAAAAAAAPQAAAAAAAAAAAAAAAD0 AAAAAAAAAAAAAAAA9AAAAAAAAAAAAAAAAPQAAAAAAAAAAAAAAAD0AAAAAAAAAAAAAAAA9AAAAAAA AAAAAAAAAPQAAAAAAAAAAAAAAAD0AAAAAAAAAAAAAAAA9AAAAAAAAAAAAAAAAPQAAAAAAAAAAAAA AAD0AAAAAAAAAAAAAAAA9AAAAAAAAAAAAAAAAPQAAAAAAAAAAAAAAAD0AAAAAAAAAAAAAAAA9AAA AAAAAAAAAAAAAPQAAAAAAAAAAAAAAAD0AAAAAAAAAAAAAAAA9AAAAAAAAAAAAAAAAPQAAAAAAAAA AAAAAAD0AAAAAAAAAAAAAAAA9AAAAAAAAAAAAAAAAPQAAAAAAAAAAAAAAAD0AAAAAAAAAAAAAAAA 9AAAAAAAAAAAAAAAAPQAAAAAAAAAAAAAAAD0AAAAAAAAAAAAAAAAAAAAAAAAAAALAAATpHgANyQA OCQASCQAZ2QUFGMAAByroAAA66AAACmhAABroQAArqEAAPShAAA3ogAAeaIAAL2iAADVogAABKMA AEqjAACPowAAzaMAAA6kAABNpAAAi6QAAM2kAAASpQAAUaUAAJGlAADVpQAAEqYAABymAABCpgAA f6YAAL6mAAABpwAARacAAPQAAAAAAAAAAAAAAAD0AAAAAAAAAAAAAAAA9AAAAAAAAAAAAAAAAPQA AAAAAAAAAAAAAAD0AAAAAAAAAAAAAAAA9AAAAAAAAAAAAAAAAPQAAAAAAAAAAAAAAAD0AAAAAAAA AAAAAAAA9AAAAAAAAAAAAAAAAPQAAAAAAAAAAAAAAAD0AAAAAAAAAAAAAAAA9AAAAAAAAAAAAAAA APQAAAAAAAAAAAAAAAD0AAAAAAAAAAAAAAAA9AAAAAAAAAAAAAAAAPQAAAAAAAAAAAAAAAD0AAAA AAAAAAAAAAAA9AAAAAAAAAAAAAAAAPQAAAAAAAAAAAAAAAD0AAAAAAAAAAAAAAAA9AAAAAAAAAAA AAAAAPQAAAAAAAAAAAAAAAD0AAAAAAAAAAAAAAAA9AAAAAAAAAAAAAAAAPQAAAAAAAAAAAAAAAD0 AAAAAAAAAAAAAAAA9AAAAAAAAAAAAAAAAPQAAAAAAAAAAAAAAAAAAAAAAAAAAAsAABOkeAA3JAA4 JABIJABnZBQUYwAAHEWnAACHpwAAzKcAABGoAABSqAAAj6gAALOoAADxqAAANqkAAHupAADBqQAA BKoAABCqAABRqgAAlKoAANOqAAD8qgAAI6sAAGerAABtqwAAo6sAANqrAAAdrAAAYqwAAKWsAADi rAAAGa0AAE2tAACFrQAA9AAAAAAAAAAAAAAAAPQAAAAAAAAAAAAAAAD0AAAAAAAAAAAAAAAA9AAA AAAAAAAAAAAAAPQAAAAAAAAAAAAAAAD0AAAAAAAAAAAAAAAA9AAAAAAAAAAAAAAAAPQAAAAAAAAA AAAAAAD0AAAAAAAAAAAAAAAA9AAAAAAAAAAAAAAAAPQAAAAAAAAAAAAAAAD0AAAAAAAAAAAAAAAA 9AAAAAAAAAAAAAAAAPQAAAAAAAAAAAAAAAD0AAAAAAAAAAAAAAAA9AAAAAAAAAAAAAAAAPQAAAAA AAAAAAAAAAD0AAAAAAAAAAAAAAAA9AAAAAAAAAAAAAAAAPQAAAAAAAAAAAAAAAD0AAAAAAAAAAAA AAAA9AAAAAAAAAAAAAAAAPQAAAAAAAAAAAAAAAD0AAAAAAAAAAAAAAAA9AAAAAAAAAAAAAAAAPQA AAAAAAAAAAAAAAD0AAAAAAAAAAAAAAAA9AAAAAAAAAAAAAAAAAAAAAAAAAAACwAAE6R4ADckADgk AEgkAGdkFBRjAAAcha0AALqtAAD+rQAAPK4AAHyuAADBrgAA564AACevAABprwAAqK8AAOyvAAAw sAAAc7AAALSwAAD0sAAANrEAAHWxAAC2sQAA5LEAABmyAABYsgAAm7IAAN2yAAAgswAAZrMAAKmz AADuswAALrQAAFe0AAD0AAAAAAAAAAAAAAAA9AAAAAAAAAAAAAAAAPQAAAAAAAAAAAAAAAD0AAAA AAAAAAAAAAAA9AAAAAAAAAAAAAAAAPQAAAAAAAAAAAAAAAD0AAAAAAAAAAAAAAAA9AAAAAAAAAAA AAAAAPQAAAAAAAAAAAAAAAD0AAAAAAAAAAAAAAAA9AAAAAAAAAAAAAAAAPQAAAAAAAAAAAAAAAD0 AAAAAAAAAAAAAAAA9AAAAAAAAAAAAAAAAPQAAAAAAAAAAAAAAAD0AAAAAAAAAAAAAAAA9AAAAAAA AAAAAAAAAPQAAAAAAAAAAAAAAAD0AAAAAAAAAAAAAAAA9AAAAAAAAAAAAAAAAPQAAAAAAAAAAAAA AAD0AAAAAAAAAAAAAAAA9AAAAAAAAAAAAAAAAPQAAAAAAAAAAAAAAAD0AAAAAAAAAAAAAAAA9AAA AAAAAAAAAAAAAPQAAAAAAAAAAAAAAAD0AAAAAAAAAAAAAAAAAAAAAAAAAAALAAATpHgANyQAOCQA SCQAZ2QUFGMAABxXtAAAnLQAAOK0AAAhtQAAY7UAAKS1AAC+tQAAArYAAEK2AACHtgAAwbYAAN62 AAAdtwAAYLcAAKO3AADjtwAAJbgAADq4AACAuAAAxLgAAPQAAAAAAAAAAAAAAAD0AAAAAAAAAAAA AAAA9AAAAAAAAAAAAAAAAPQAAAAAAAAAAAAAAAD0AAAAAAAAAAAAAAAApgAAAAAAAAAAAAAAAPQA AAAAAAAAAAAAAAD0AAAAAAAAAAAAAAAA9AAAAAAAAAAAAAAAAPQAAAAAAAAAAAAAAAD0AAAAAAAA AAAAAAAA9AAAAAAAAAAAAAAAAPQAAAAAAAAAAAAAAAD0AAAAAAAAAAAAAAAA9AAAAAAAAAAAAAAA APQAAAAAAAAAAAAAAAD0AAAAAAAAAAAAAAAA9AAAAAAAAAAAAAAAAPQAAAAAAAAAAAAAAAAAAAAA AE4AABOkeAA3JAA4JABDJAFFxoAAAAEA+cTUpgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEgkAGdkFBRjAAsAABOkeAA3JAA4JABI JABnZBQUYwAAE8S4AAAFuQAASrkAAIa5AADCuQAAB7oAAEq6AACOugAAzboAAA67AABQuwAAlLsA ANS7AAAUvAAAPrwAAIS8AADDvAAABr0AAEq9AAB0vQAAs70AAMm9AADxvQAAE74AADG+AABzvgAA sr4AAPC+AAAzvwAA9AAAAAAAAAAAAAAAAPQAAAAAAAAAAAAAAAD0AAAAAAAAAAAAAAAA9AAAAAAA AAAAAAAAAPQAAAAAAAAAAAAAAAD0AAAAAAAAAAAAAAAA9AAAAAAAAAAAAAAAAPQAAAAAAAAAAAAA AAD0AAAAAAAAAAAAAAAA9AAAAAAAAAAAAAAAAPQAAAAAAAAAAAAAAAD0AAAAAAAAAAAAAAAA9AAA AAAAAAAAAAAAAPQAAAAAAAAAAAAAAAD0AAAAAAAAAAAAAAAA9AAAAAAAAAAAAAAAAPQAAAAAAAAA AAAAAAD0AAAAAAAAAAAAAAAA9AAAAAAAAAAAAAAAAPQAAAAAAAAAAAAAAAD0AAAAAAAAAAAAAAAA 9AAAAAAAAAAAAAAAAPQAAAAAAAAAAAAAAAD0AAAAAAAAAAAAAAAA9AAAAAAAAAAAAAAAAPQAAAAA AAAAAAAAAAD0AAAAAAAAAAAAAAAA9AAAAAAAAAAAAAAAAAAAAAAAAAAACwAAE6R4ADckADgkAEgk AGdkFBRjAAAcM78AAHe/AAC4vwAAAsAAADTAAAB5wAAAuMAAAP3AAAA/wQAAgMEAAMTBAADfwQAA HsIAAGLCAACjwgAA5MIAACbDAABlwwAAqcMAAOjDAAAfxAAAQsQAAIXEAADJxAAACsUAAE7FAABW xQAAm8UAANfFAAD0AAAAAAAAAAAAAAAA9AAAAAAAAAAAAAAAAPQAAAAAAAAAAAAAAAD0AAAAAAAA AAAAAAAA9AAAAAAAAAAAAAAAAPQAAAAAAAAAAAAAAAD0AAAAAAAAAAAAAAAA9AAAAAAAAAAAAAAA APQAAAAAAAAAAAAAAAD0AAAAAAAAAAAAAAAA9AAAAAAAAAAAAAAAAPQAAAAAAAAAAAAAAAD0AAAA AAAAAAAAAAAA9AAAAAAAAAAAAAAAAPQAAAAAAAAAAAAAAAD0AAAAAAAAAAAAAAAA9AAAAAAAAAAA AAAAAPQAAAAAAAAAAAAAAAD0AAAAAAAAAAAAAAAA9AAAAAAAAAAAAAAAAPQAAAAAAAAAAAAAAAD0 AAAAAAAAAAAAAAAA9AAAAAAAAAAAAAAAAPQAAAAAAAAAAAAAAAD0AAAAAAAAAAAAAAAA9AAAAAAA AAAAAAAAAPQAAAAAAAAAAAAAAAD0AAAAAAAAAAAAAAAAAAAAAAAAAAALAAATpHgANyQAOCQASCQA Z2QUFGMAABzXxQAAGMYAAFPGAACJxgAAzcYAANjGAAAYxwAAK8cAAGTHAAB7xwAAv8cAAODHAAAl yAAAY8gAAJvIAADbyAAAHckAAGDJAAChyQAA48kAACnKAABuygAArMoAAO7KAAAaywAAScsAAIvL AACyywAA+MsAAPQAAAAAAAAAAAAAAAD0AAAAAAAAAAAAAAAA9AAAAAAAAAAAAAAAAPQAAAAAAAAA AAAAAAD0AAAAAAAAAAAAAAAA9AAAAAAAAAAAAAAAAPQAAAAAAAAAAAAAAAD0AAAAAAAAAAAAAAAA 9AAAAAAAAAAAAAAAAPQAAAAAAAAAAAAAAAD0AAAAAAAAAAAAAAAA9AAAAAAAAAAAAAAAAPQAAAAA AAAAAAAAAAD0AAAAAAAAAAAAAAAA9AAAAAAAAAAAAAAAAPQAAAAAAAAAAAAAAAD0AAAAAAAAAAAA AAAA9AAAAAAAAAAAAAAAAPQAAAAAAAAAAAAAAAD0AAAAAAAAAAAAAAAA9AAAAAAAAAAAAAAAAPQA AAAAAAAAAAAAAAD0AAAAAAAAAAAAAAAA9AAAAAAAAAAAAAAAAPQAAAAAAAAAAAAAAAD0AAAAAAAA AAAAAAAA9AAAAAAAAAAAAAAAAPQAAAAAAAAAAAAAAAAAAAAAAAAAAAsAABOkeAA3JAA4JABIJABn ZBQUYwAAHPjLAAA/zAAAXswAAKTMAADHzAAA68wAAA/NAAD0AAAAAAAAAAAAAAAA5wAAAAAAAAAA AAAAAOcAAAAAAAAAAAAAAACSAAAAAAAAAAAAAAAA5wAAAAAAAAAAAAAAAEQAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABOAAATpHgANyQAOCQAQyQBRcaAAAABAObE1KYA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAABIJABnZMB7dwAAVAAAE6R4ADckADgkAEMkAUXGgAAAAQDmxNSmAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAASCQAZ2QZeFQA b8YHAQEA5sTUpmQmAQAMAAATpHgANyQAOCQAQyQBSCQAZ2TAe3cACwAAE6R4ADckADgkAEgkAGdk FBRjAAAGOMwAAD/MAABCzAAAW8wAAF3MAABezAAAYMwAAGHMAACjzAAApMwAAKbMAACwzAAAscwA ALbMAADatNqV2pXab0lvSSNJAEoBCAEESAEABWjnxNSmFWgRF2QAFmgZeFQAQ0oUAE9KAwBRSgMA XkoDAGFKFABtSAkIc0gJCInKBwEBAPXE1KaDKgFtSAkEc0gJBABKAQgBBEgBAAVo5sTUphVoERdk ABZoXlM9AENKFABPSgMAUUoDAF5KAwBhShQAbUgJCHNICQiJygcBAQD1xNSmgyoBbUgJBHNICQQA SgEIAQRIAQAFaOXE1KYVaBEXZAAWaF5TPQBDShQAT0oDAFFKAwBeSgMAYUoUAG1ICQhzSAkIicoH AQEA9cTUpoMqAW1ICQRzSAkEAD0VaBEXZAAWaBQUYwBDShQAT0oDAFFKAwBeSgMAYUoUAG1ICQhz SAkIicoHAQEA9cTUpoMqAW1ICQRzSAkESgEIAQRIAQAFaOTE1KYVaBEXZAAWaF5TPQBDShQAT0oD AFFKAwBeSgMAYUoUAG1ICQhzSAkIicoHAQEA9cTUpoMqAW1ICQRzSAkEAEoBCAEESAEABWjVxNSm FWgRF2QAFmjAe3cAQ0oUAE9KAwBRSgMAXkoDAGFKFABtSAkIc0gJCInKBwEBAPXE1KaDKgFtSAkE c0gJBA22zAAAu8wAAMbMAADHzAAA6swAAOvMAAANzQAADs0AAA/NAAAizQAAI80AAHPNAADatIVm tGa0N2a0ZgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AFwACAEVaBEXZAAWaBQUYwAXaF5TPQBDShQAT0oDAFFKAwBeSgMAYUoUAGNIAQBkaAAAAABkaAAA AABkaObE1KZtSAkIc0gJCInKBwEBAPXE1KaDKgFtSAkEc0gJBAA9FWgRF2QAFmgUFGMAQ0oUAE9K AwBRSgMAXkoDAGFKFABtSAkIc0gJCInKBwEBAPXE1KaDKgFtSAkEc0gJBFwACAEVaBEXZAAWaBQU YwAXaMB7dwBDShQAT0oDAFFKAwBeSgMAYUoUAGNIAQBkaAAAAABkaAAAAABkaNXE1KZtSAkIc0gJ CInKBwEBAPXE1KaDKgFtSAkEc0gJBABKAQgBBEgBAAVo5sTUphVoERdkABZoXlM9AENKFABPSgMA UUoDAF5KAwBhShQAbUgJCHNICQiJygcBAQD1xNSmgyoBbUgJBHNICQQASgEIAQRIAQAFaOfE1KYV aBEXZAAWaBl4VABDShQAT0oDAFFKAwBeSgMAYUoUAG1ICQhzSAkIicoHAQEA9cTUpoMqAW1ICQRz SAkECw/NAAAjzQAAU80AAJjNAADXzQAAG84AAFjOAABuzgAAs84AAPIAAAAAAAAAAAAAAACkAAAA AAAAAAAAAAAAmQAAAAAAAAAAAAAAAJkAAAAAAAAAAAAAAACZAAAAAAAAAAAAAAAAmQAAAAAAAAAA AAAAAJkAAAAAAAAAAAAAAABLAAAAAAAAAAAAAAAAAAAAAAAAAAAAAE4AABOkeAA3JAA4JABDJAFF xoAAAAEA58TUpgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAEgkAGdkFBRjAAsAABOkeAA3JAA4JABIJABnZBQUYwBOAAATpHgANyQA OCQAQyQBRcaAAAABAObE1KYAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAABIJABnZF5TPQAADAAAE6R4ADckADgkAEMkAUgkAGdkXlM9 AAAIc80AAHTNAABtzgAAbs4AALPOAADXzgAA2M4AAMDPAADEzwAA2ruVb0kqu9oAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAPRVoERdkABZoGXhUAENKFABPSgMAUUoDAF5K AwBhShQAbUgJCHNICQiJygcBAQD1xNSmgyoBbUgJBHNICQRKAQgBBEgBAAVo6MTUphVoERdkABZo GXhUAENKFABPSgMAUUoDAF5KAwBhShQAbUgJCHNICQiJygcBAQD1xNSmgyoBbUgJBHNICQQASgEI AQRIAQAFaOfE1KYVaBEXZAAWaBl4VABDShQAT0oDAFFKAwBeSgMAYUoUAG1ICQhzSAkIicoHAQEA 9cTUpoMqAW1ICQRzSAkEAEoBCAEESAEABWjnxNSmFWgRF2QAFmgUFGMAQ0oUAE9KAwBRSgMAXkoD AGFKFABtSAkIc0gJCInKBwEBAPXE1KaDKgFtSAkEc0gJBAA9FWgRF2QAFmgUFGMAQ0oUAE9KAwBR SgMAXkoDAGFKFABtSAkIc0gJCInKBwEBAPXE1KaDKgFtSAkEc0gJBEoBCAEESAEABWjMxNSmFWgR F2QAFmgpV+EAQ0oUAE9KAwBRSgMAXkoDAGFKFABtSAkIc0gJCInKBwEBAPXE1KaDKgFtSAkEc0gJ BAizzgAA2M4AABzPAABJzwAAhs8AAMLPAAD8zwAAQtAAAITQAADI0AAAAtEAALEAAAAAAAAAAAAA AACmAAAAAAAAAAAAAAAApgAAAAAAAAAAAAAAAKYAAAAAAAAAAAAAAACmAAAAAAAAAAAAAAAAWAAA AAAAAAAAAAAAAKYAAAAAAAAAAAAAAACmAAAAAAAAAAAAAAAApgAAAAAAAAAAAAAAAKYAAAAAAAAA AAAAAAAAAE4AABOkeAA3JAA4JABDJAFFxoAAAAEAzMTUpgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEgkAGdkKVfhAAsAABOkeAA3 JAA4JABIJABnZBQUYwBOAAATpHgANyQAOCQAQyQBRcaAAAABAOjE1KYAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABIJABnZBl4VAAA CsTPAADwzwAA+s8AAOnRAAAP0gAAENIAABTSAAAb0gAAH9IAACXSAABN0gAA2rSVb0lvI0lvSQAA AAAAAAAAAAAAAAAAAABKAQgBBEgBAAVoz8TUphVoERdkABZoERdkAENKFABPSgMAUUoDAF5KAwBh ShQAbUgJCHNICQiJygcBAQD1xNSmgyoBbUgJBHNICQQASgEIAQRIAQAFaM/E1KYVaBEXZAAWaClX 4QBDShQAT0oDAFFKAwBeSgMAYUoUAG1ICQhzSAkIicoHAQEA9cTUpoMqAW1ICQRzSAkEAEoBCAEE SAEABWjOxNSmFWgRF2QAFmgpV+EAQ0oUAE9KAwBRSgMAXkoDAGFKFABtSAkIc0gJCInKBwEBAPXE 1KaDKgFtSAkEc0gJBAA9FWgRF2QAFmgUFGMAQ0oUAE9KAwBRSgMAXkoDAGFKFABtSAkIc0gJCInK BwEBAPXE1KaDKgFtSAkEc0gJBEoBCAEESAEABWjoxNSmFWgRF2QAFmgZeFQAQ0oUAE9KAwBRSgMA XkoDAGFKFABtSAkIc0gJCInKBwEBAPXE1KaDKgFtSAkEc0gJBABKAQgBBEgBAAVozcTUphVoERdk ABZoKVfhAENKFABPSgMAUUoDAF5KAwBhShQAbUgJCHNICQiJygcBAQD1xNSmgyoBbUgJBHNICQQK AtEAAETRAACG0QAAydEAABDSAABX0gAA6dIAAPQAAAAAAAAAAAAAAAD0AAAAAAAAAAAAAAAA9AAA AAAAAAAAAAAAAPQAAAAAAAAAAAAAAACmAAAAAAAAAAAAAAAAWAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAABOAAATpHgANyQAOCQAQyQBRcaAAAABANHE1KYAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABIJABnZMB7dwBOAAATpHgANyQA OCQAQyQBRcaAAAABAM/E1KYAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAABIJABnZBEXZAALAAATpHgANyQAOCQASCQAZ2QUFGMAAAZN 0gAAUtIAAFzSAACe0gAAtdIAALbSAAC30gAAuNIAAHPTAAB00wAAuNMAAOfBm3XBXUEb5xtKAQgB BEgBAAVo0cTUphVoERdkABZoKVfhAENKFABPSgMAUUoDAF5KAwBhShQAbUgJCHNICQiJygcBAQD1 xNSmgyoBbUgJBHNICQQANgEIAQRIAQAFaNHE1KYVaBEXZAAWaClX4QBtSAkIc0gJCInKBwEBAPXE 1KaDKgFtSAkEc0gJBAAuAQgBBEgBAAVo0cTUphVoERdkABZoKVfhAInKBwEBAPXE1KaDKgFtSAkE c0gJBABKAQgBBEgBAAVo08TUphVoERdkABZowHt3AENKFABPSgMAUUoDAF5KAwBhShQAbUgJCHNI CQiJygcBAQD1xNSmgyoBbUgJBHNICQQASgEIAQRIAQAFaNLE1KYVaBEXZAAWaMB7dwBDShQAT0oD AFFKAwBeSgMAYUoUAG1ICQhzSAkIicoHAQEA9cTUpoMqAW1ICQRzSAkEAEoBCAEESAEABWjPxNSm FWgRF2QAFmgpV+EAQ0oUAE9KAwBRSgMAXkoDAGFKFABtSAkIc0gJCInKBwEBAPXE1KaDKgFtSAkE c0gJBAAvAQiBBEgBAAVo9cTUphZoERdkAENKFABPSgMAUUoDAF5KAwBhShQAbUgJBHNICQQACunS AAAx0wAAdNMAALEAAAAAAAAAAAAAAABjAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAE4AABOkeAA3JAA4JABDJAFFxoAAAAEA0sTUpgAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AEgkAGdkKVfhAE4AABOkeAA3JAA4JABDJAFFxoAAAAEA0cTUpgAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEgkAGdkKVfhAAACdNMA ALnTAAAF1AAAPdQAALEAAAAAAAAAAAAAAACxAAAAAAAAAAAAAAAAYwAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAATgAAE6R4ADckADgkAEMkAUXGgAAAAQD2xNSmAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA SCQAZ2QRF2QATgAAE6R4ADckADgkAEMkAUXGgAAAAQDSxNSmAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAASCQAZ2QRF2QAAAO40wAA udMAAMbTAADH0wAABNQAAAXUAAAQ1AAAINQAADHUAAAy1AAAP9QAANHYAADT2AAA58GpwefBg8Fd wT4mAAAAAAAAAAAAAAAALwEIgQRIAQAFaPfE1KYWaBEXZABDShQAT0oDAFFKAwBeSgMAYUoUAG1I CQRzSAkEPRVoERdkABZoFBRjAENKFABPSgMAUUoDAF5KAwBhShQAbUgJCHNICQiJygcBAQD1xNSm gyoBbUgJBHNICQRKAQgBBEgBAAVo9MTUphVoERdkABZoERdkAENKFABPSgMAUUoDAF5KAwBhShQA bUgJCHNICQiJygcBAQD1xNSmgyoBbUgJBHNICQQASgEIAQRIAQAFaNHE1KYVaBEXZAAWaMB7dwBD ShQAT0oDAFFKAwBeSgMAYUoUAG1ICQhzSAkIicoHAQEA9cTUpoMqAW1ICQRzSAkEAC8BCIEESAEA BWj1xNSmFmgRF2QAQ0oUAE9KAwBRSgMAXkoDAGFKFABtSAkEc0gJBEoBCAEESAEABWjRxNSmFWgR F2QAFmgpV+EAQ0oUAE9KAwBRSgMAXkoDAGFKFABtSAkIc0gJCInKBwEBAPXE1KaDKgFtSAkEc0gJ BAAvAQiBBEgBAAVo9sTUphZoERdkAENKFABPSgMAUUoDAF5KAwBhShQAbUgJBHNICQQADD3UAAA/ 1AAAQNQAAGPUAACn1AAA7NQAADHVAAA/1QAAgtUAAMfVAAAM1gAAsQAAAAAAAAAAAAAAAGMAAAAA AAAAAAAAAABYAAAAAAAAAAAAAAAAWAAAAAAAAAAAAAAAAFgAAAAAAAAAAAAAAABYAAAAAAAAAAAA AAAAWAAAAAAAAAAAAAAAAFgAAAAAAAAAAAAAAABYAAAAAAAAAAAAAAAAWAAAAAAAAAAAAAAAAAAA CwAAE6R4ADckADgkAEgkAGdkFBRjAE4AABOkeAA3JAA4JABDJAFFxoAAAAEAz8TUpgAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEgk AGdkKVfhAE4AABOkeAA3JAA4JABDJAFFxoAAAAEA0cTUpgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEgkAGdkKVfhAAAKDNYAAE7W AACO1gAAzdYAABLXAABU1wAAkNcAANTXAAD11wAAI9gAAGTYAACb2AAA09gAAA7ZAABT2QAAj9kA ANXZAAAZ2gAAWNoAAJTaAAD0AAAAAAAAAAAAAAAA9AAAAAAAAAAAAAAAAPQAAAAAAAAAAAAAAAD0 AAAAAAAAAAAAAAAA9AAAAAAAAAAAAAAAAPQAAAAAAAAAAAAAAAD0AAAAAAAAAAAAAAAA9AAAAAAA AAAAAAAAAPQAAAAAAAAAAAAAAAD0AAAAAAAAAAAAAAAA9AAAAAAAAAAAAAAAAPQAAAAAAAAAAAAA AACmAAAAAAAAAAAAAAAA9AAAAAAAAAAAAAAAAPQAAAAAAAAAAAAAAAD0AAAAAAAAAAAAAAAA9AAA AAAAAAAAAAAAAPQAAAAAAAAAAAAAAAD0AAAAAAAAAAAAAAAAAAAAAABOAAATpHgANyQAOCQAQyQB RcaAAAABAPfE1KYAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAABIJABnZBQUYwALAAATpHgANyQAOCQASCQAZ2QUFGMAABPT2AAA1dgA AAzZAADy4QAA8+EAAPThAAAC4gAAMOIAADHiAAAm5wAA5MmqkndfRyiqAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAD0VaBEXZAAWaBEXZABDShQAT0oDAFFKAwBeSgMAYUoUAG1ICQhzSAkI icoHAQEA9cTUpoMqAW1ICQRzSAkELwEIgQRIAQAFaPvE1KYWaBEXZABDShQAT0oDAFFKAwBeSgMA YUoUAG1ICQRzSAkELwEIgQRIAQAFaPrE1KYWaBEXZABDShQAT0oDAFFKAwBeSgMAYUoUAG1ICQRz SAkENQEIgQRIAQAFaPrE1KYVaBEXZAAWaBEXZABDShQAT0oDAFFKAwBeSgMAYUoUAG1ICQRzSAkE LwEIgQRIAQAFaPrE1KYWaBQUYwBDShQAT0oDAFFKAwBeSgMAYUoUAG1ICQRzSAkEPRVoERdkABZo FBRjAENKFABPSgMAUUoDAF5KAwBhShQAbUgJCHNICQiJygcBAQD1xNSmgyoBbUgJBHNICQQ1AQiB BEgBAAVo98TUphVoERdkABZoERdkAENKFABPSgMAUUoDAF5KAwBhShQAbUgJBHNICQQ1AQiBBEgB AAVo+MTUphVoERdkABZoERdkAENKFABPSgMAUUoDAF5KAwBhShQAbUgJBHNICQQACZTaAACi2gAA xdoAAAnbAABP2wAAkNsAALfbAAD82wAAQtwAAILcAADC3AAABd0AAEbdAACJ3QAAy90AAA/eAABK 3gAAjt4AANLeAADv3gAACd8AAE7fAACU3wAA1t8AABzgAAAq4AAASOAAAHzgAACh4AAA9AAAAAAA AAAAAAAAAPQAAAAAAAAAAAAAAAD0AAAAAAAAAAAAAAAA9AAAAAAAAAAAAAAAAPQAAAAAAAAAAAAA AAD0AAAAAAAAAAAAAAAA9AAAAAAAAAAAAAAAAPQAAAAAAAAAAAAAAAD0AAAAAAAAAAAAAAAA9AAA AAAAAAAAAAAAAPQAAAAAAAAAAAAAAAD0AAAAAAAAAAAAAAAA9AAAAAAAAAAAAAAAAPQAAAAAAAAA AAAAAAD0AAAAAAAAAAAAAAAA9AAAAAAAAAAAAAAAAPQAAAAAAAAAAAAAAAD0AAAAAAAAAAAAAAAA 9AAAAAAAAAAAAAAAAPQAAAAAAAAAAAAAAAD0AAAAAAAAAAAAAAAA9AAAAAAAAAAAAAAAAPQAAAAA AAAAAAAAAAD0AAAAAAAAAAAAAAAA9AAAAAAAAAAAAAAAAPQAAAAAAAAAAAAAAAD0AAAAAAAAAAAA AAAA9AAAAAAAAAAAAAAAAAAAAAAAAAAACwAAE6R4ADckADgkAEgkAGdkFBRjAAAcoeAAALrgAADY 4AAAHeEAADXhAABj4QAApOEAAMXhAADz4QAAMeIAAEziAAB94gAApuIAAMDiAADh4gAAGOMAAE7j AAB+4wAAneMAAN3jAAD0AAAAAAAAAAAAAAAA9AAAAAAAAAAAAAAAAPQAAAAAAAAAAAAAAAD0AAAA AAAAAAAAAAAA9AAAAAAAAAAAAAAAAPQAAAAAAAAAAAAAAAD0AAAAAAAAAAAAAAAA9AAAAAAAAAAA AAAAAKYAAAAAAAAAAAAAAAD0AAAAAAAAAAAAAAAA9AAAAAAAAAAAAAAAAPQAAAAAAAAAAAAAAAD0 AAAAAAAAAAAAAAAA9AAAAAAAAAAAAAAAAPQAAAAAAAAAAAAAAAD0AAAAAAAAAAAAAAAA9AAAAAAA AAAAAAAAAPQAAAAAAAAAAAAAAAD0AAAAAAAAAAAAAAAAAAAAAABOAAATpHgANyQAOCQAQyQBRcaA AAABAPrE1KYAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAABIJABnZBEXZAALAAATpHgANyQAOCQASCQAZ2QUFGMAABPd4wAAH+QAAGTk AACR5AAAzOQAAA3lAABO5QAAjeUAAKnlAADA5QAA5+UAAALmAABG5gAAfuYAAMDmAAAD5wAAI+cA AEvnAACU5wAA9AAAAAAAAAAAAAAAAPQAAAAAAAAAAAAAAAD0AAAAAAAAAAAAAAAA9AAAAAAAAAAA AAAAAPQAAAAAAAAAAAAAAAD0AAAAAAAAAAAAAAAA9AAAAAAAAAAAAAAAAPQAAAAAAAAAAAAAAAD0 AAAAAAAAAAAAAAAA9AAAAAAAAAAAAAAAAPQAAAAAAAAAAAAAAAD0AAAAAAAAAAAAAAAA9AAAAAAA AAAAAAAAAPQAAAAAAAAAAAAAAAD0AAAAAAAAAAAAAAAA9AAAAAAAAAAAAAAAAPQAAAAAAAAAAAAA AACmAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAE4AABOkeAA3JAA4JABDJAFFxoAA AAEABMXUpgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAEgkAGdkz2C2AAsAABOkeAA3JAA4JABIJABnZBQUYwAAEibnAABL5wAATOcA AFjnAABh5wAAcecAAH/nAACI5wAAi+cAAJPnAACU5wAAnecAAKXnAADI5wAAyucAANHnAADV5wAA 1+cAANjnAADs5wAA8ucAAPPnAAAf6AAAIOgAAGboAABn6AAAfugAAOfPtJnPgc+BtIG0gbRptFG0 gbRRgbSBtIG0AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAC8BCIEESAEABWgCxdSmFmgRF2QA Q0oUAE9KAwBRSgMAXkoDAGFKFABtSAkEc0gJBC8BCIEESAEABWgCxdSmFmjPYLYAQ0oUAE9KAwBR SgMAXkoDAGFKFABtSAkEc0gJBC8BCIEESAEABWgFxdSmFmjPYLYAQ0oUAE9KAwBRSgMAXkoDAGFK FABtSAkEc0gJBDUBCIEESAEABWgBxdSmFWgRF2QAFmgRF2QAQ0oUAE9KAwBRSgMAXkoDAGFKFABt SAkEc0gJBDUBCIEESAEABWgAxdSmFWgRF2QAFmgRF2QAQ0oUAE9KAwBRSgMAXkoDAGFKFABtSAkE c0gJBC8BCIEESAEABWgExdSmFmjPYLYAQ0oUAE9KAwBRSgMAXkoDAGFKFABtSAkEc0gJBC8BCIEE SAEABWgAxdSmFmgRF2QAQ0oUAE9KAwBRSgMAXkoDAGFKFABtSAkEc0gJBAAalOcAANjnAAAg6AAA Z+gAALHoAAD46AAAG+kAALEAAAAAAAAAAAAAAACxAAAAAAAAAAAAAAAAsQAAAAAAAAAAAAAAAGMA AAAAAAAAAAAAAACxAAAAAAAAAAAAAAAAsQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAATgAAE6R4ADckADgkAEMkAUXGgAAAAQACxdSmAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAASCQAZ2TPYLYA TgAAE6R4ADckADgkAEMkAUXGgAAAAQAAxdSmAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAASCQAZ2TPYLYAAAZ+6AAAh+gAALDoAACx 6AAAtugAALfoAAD36AAA+OgAABnpAAAa6QAAG+kAABzpAAAf6QAAMOkAADHpAAAy6QAAQOkAAEHp AABC6QAAzekAAM7pAADP6QAAQ+sAAOfMtMy0zLTM55zntH1OtH20Tn20Tn0AAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABcAAgBFWgRF2QAFmgUFGMAF2jPYLYAQ0oUAE9K AwBRSgMAXkoDAGFKFABjSAEAZGgAAAAAZGgAAAAAZGgGxdSmbUgJCHNICQiJygcBAQD1xNSmgyoB bUgJBHNICQQAPRVoERdkABZoFBRjAENKFABPSgMAUUoDAF5KAwBhShQAbUgJCHNICQiJygcBAQD1 xNSmgyoBbUgJBHNICQQvAQiBBEgBAAVoAMXUphZoERdkAENKFABPSgMAUUoDAF5KAwBhShQAbUgJ BHNICQQvAQiBBEgBAAVoBsXUphZoz2C2AENKFABPSgMAUUoDAF5KAwBhShQAbUgJBHNICQQ1AQiB BEgBAAVoAMXUphVoERdkABZoERdkAENKFABPSgMAUUoDAF5KAwBhShQAbUgJBHNICQQvAQiBBEgB AAVoA8XUphZoz2C2AENKFABPSgMAUUoDAF5KAwBhShQAbUgJBHNICQQAFhvpAAAc6QAAL+kAAD/p AABb6QAAmekAAMzpAADq6QAA9ukAALEAAAAAAAAAAAAAAABjAAAAAAAAAAAAAAAAWAAAAAAAAAAA AAAAAE0AAAAAAAAAAAAAAABNAAAAAAAAAAAAAAAATQAAAAAAAAAAAAAAAE0AAAAAAAAAAAAAAABN AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAALAAATpHgANyQAOCQASCQAZ2QUFGMACwAAE6R4ADck ADgkAEgkAGdkz2C2AE4AABOkeAA3JAA4JABDJAFFxoAAAAEAAMXUpgAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEgkAGdkFBRjAE4A ABOkeAA3JAA4JABDJAFFxoAAAAEAA8XUpgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEgkAGdkFBRjAAAI9ukAACzqAABn6gAAn+oA ANPqAAAO6wAAHesAAEPrAAB26wAAsesAAOvrAAAO7AAAMOwAAGjsAACD7AAAvOwAAMvsAADu7AAA JO0AAFztAACW7QAAr+0AAMvtAAD87QAAL+4AAEjuAABr7gAAnu4AANXuAAD0AAAAAAAAAAAAAAAA 9AAAAAAAAAAAAAAAAPQAAAAAAAAAAAAAAAD0AAAAAAAAAAAAAAAA9AAAAAAAAAAAAAAAAPQAAAAA AAAAAAAAAAD0AAAAAAAAAAAAAAAA9AAAAAAAAAAAAAAAAPQAAAAAAAAAAAAAAAD0AAAAAAAAAAAA AAAA9AAAAAAAAAAAAAAAAPQAAAAAAAAAAAAAAAD0AAAAAAAAAAAAAAAA9AAAAAAAAAAAAAAAAPQA AAAAAAAAAAAAAAD0AAAAAAAAAAAAAAAA9AAAAAAAAAAAAAAAAPQAAAAAAAAAAAAAAAD0AAAAAAAA AAAAAAAA9AAAAAAAAAAAAAAAAPQAAAAAAAAAAAAAAAD0AAAAAAAAAAAAAAAA9AAAAAAAAAAAAAAA APQAAAAAAAAAAAAAAAD0AAAAAAAAAAAAAAAA9AAAAAAAAAAAAAAAAPQAAAAAAAAAAAAAAAD0AAAA AAAAAAAAAAAAAAAAAAAAAAALAAATpHgANyQAOCQASCQAZ2QUFGMAABxD6wAAdusAAGvuAACe7gAA k/IAAKryAADi8wAACfQAAGH1AABi9QAAzfYAAM72AADP9gAA0PYAAODBosGDwWTgWlJHQ+AAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAYWaM9gtgAAFBVowHt3ABZowHt3AG1ICQRzSAkEAA4WaMB7dwBtSAkEc0gJBAATA2oAAAAA FmjAe3cAMEoQAFUIAT0VaBEXZAAWaBQUYwBDShQAT0oDAFFKAwBeSgMAYUoUAG1IEARzSBAEicoH AQEA9cTUpoMqAW1ICQRzSAkEPRVoERdkABZoFBRjAENKFABPSgMAUUoDAF5KAwBhShQAbUgGBHNI BgSJygcBAQD1xNSmgyoBbUgJBHNICQQ9FWgRF2QAFmgUFGMAQ0oUAE9KAwBRSgMAXkoDAGFKFABt SAcEc0gHBInKBwEBAPXE1KaDKgFtSAkEc0gJBD0VaBEXZAAWaBQUYwBDShQAT0oDAFFKAwBeSgMA YUoUAG1ICQhzSAkIicoHAQEA9cTUpoMqAW1ICQRzSAkEPRVoERdkABZoFBRjAENKFABPSgMAUUoD AF5KAwBhShQAbUgWBHNIFgSJygcBAQD1xNSmgyoBbUgJBHNICQQADdXuAAAG7wAAQO8AAFrvAABz 7wAAru8AAOjvAAAC8AAAD/AAAEXwAAB98AAAtfAAAO/wAAD98AAAN/EAAHHxAACn8QAA2/EAAOXx AAAo8gAAVPIAAJPyAACq8gAAvfIAANHyAADd8gAA+/IAABbzAAAa8wAA9AAAAAAAAAAAAAAAAPQA AAAAAAAAAAAAAAD0AAAAAAAAAAAAAAAA9AAAAAAAAAAAAAAAAPQAAAAAAAAAAAAAAAD0AAAAAAAA AAAAAAAA9AAAAAAAAAAAAAAAAPQAAAAAAAAAAAAAAAD0AAAAAAAAAAAAAAAA9AAAAAAAAAAAAAAA APQAAAAAAAAAAAAAAAD0AAAAAAAAAAAAAAAA9AAAAAAAAAAAAAAAAPQAAAAAAAAAAAAAAAD0AAAA AAAAAAAAAAAA9AAAAAAAAAAAAAAAAPQAAAAAAAAAAAAAAAD0AAAAAAAAAAAAAAAA9AAAAAAAAAAA AAAAAPQAAAAAAAAAAAAAAAD0AAAAAAAAAAAAAAAA9AAAAAAAAAAAAAAAAPQAAAAAAAAAAAAAAAD0 AAAAAAAAAAAAAAAA9AAAAAAAAAAAAAAAAPQAAAAAAAAAAAAAAAD0AAAAAAAAAAAAAAAA9AAAAAAA AAAAAAAAAAAAAAAAAAAACwAAE6R4ADckADgkAEgkAGdkFBRjAAAcGvMAADvzAABX8wAAY/MAAIHz AACc8wAAoPMAAMbzAADd8wAA4vMAABv0AAA69AAAQPQAAF30AABy9AAAi/QAAK30AAC99AAAw/QA AN70AAD09AAADfUAAC/1AAA/9QAARfUAAGH1AACR9QAA1vUAAPQAAAAAAAAAAAAAAAD0AAAAAAAA AAAAAAAA9AAAAAAAAAAAAAAAAPQAAAAAAAAAAAAAAAD0AAAAAAAAAAAAAAAA9AAAAAAAAAAAAAAA APQAAAAAAAAAAAAAAAD0AAAAAAAAAAAAAAAA9AAAAAAAAAAAAAAAAPQAAAAAAAAAAAAAAAD0AAAA AAAAAAAAAAAA9AAAAAAAAAAAAAAAAPQAAAAAAAAAAAAAAAD0AAAAAAAAAAAAAAAA9AAAAAAAAAAA AAAAAPQAAAAAAAAAAAAAAAD0AAAAAAAAAAAAAAAA9AAAAAAAAAAAAAAAAPQAAAAAAAAAAAAAAAD0 AAAAAAAAAAAAAAAA9AAAAAAAAAAAAAAAAPQAAAAAAAAAAAAAAAD0AAAAAAAAAAAAAAAA9AAAAAAA AAAAAAAAAPQAAAAAAAAAAAAAAADyAAAAAAAAAAAAAAAA6gAAAAAAAAAAAAAAAAAAAAAACBEACiYA C0YBAGdkwHt3AAABEQALAAATpHgANyQAOCQASCQAZ2QUFGMAABvW9QAANPYAADX2AADO9gAAz/YA AND2AAD3AAAAAAAAAAAAAAAA8gAAAAAAAAAAAAAAAPIAAAAAAAAAAAAAAADwAAAAAAAAAAAAAAAA 5QAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAsAABOkeAA3JAA4JABIJABn ZBQUYwAAAQAAAAQRAGdkwHt3AAgRAAomAAtGAQBnZMB7dwAABTIAMZBoATpwFBRjAB+wgi4gsMZB IbCgBSKwugUjkKAFJJCgBSWwAAAXsMQCGLDEAgyQxAIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIYCFAASAAEAnAAPAAQAAAAEAAAAAAAEAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEQAAEDx/wIA RAAMBAAAAAAAAAAABgBOAG8AcgBtAGEAbAAAAAIAAAAcAENKGABfSAEEYUoYAG1ICARuSBEEc0gI BHRIEQQAAAAAAAAAAAAAAAAAAAAAAABEAEFA8v+hAEQADAUAAAAAAAAAABYARABlAGYAYQB1AGwA dAAgAFAAYQByAGEAZwByAGEAcABoACAARgBvAG4AdAAAAAAAUgBpQPP/swBSAAwFAAAAAAAAAAAM AFQAYQBiAGwAZQAgAE4AbwByAG0AYQBsAAAAHAAX9gMAADTWBgABCgNsADTWBgABBQMAAGH2AwAA AgALAAAAKABrQPT/wQAoAAAFAAAAAAAAAAAHAE4AbwAgAEwAaQBzAHQAAAACAAAAAAAAAEgAmUAB APIASAAMBQAAKVfhAAAADABCAGEAbABsAG8AbwBuACAAVABlAHgAdAAAAAIADwAUAENKEABPSgUA UUoFAF5KBQBhShAAQgAnQKIAAQFCAAwFAADAe3cAAAARAEMAbwBtAG0AZQBuAHQAIABSAGUAZgBl AHIAZQBuAGMAZQAAAAgAQ0oQAGFKEAA8AB5AAQASATwADAUAAMB7dwAAAAwAQwBvAG0AbQBlAG4A dAAgAFQAZQB4AHQAAAACABEACABDShQAYUoUAEAAakARARIBQAAMBQAAwHt3AAAADwBDAG8AbQBt AGUAbgB0ACAAUwB1AGIAagBlAGMAdAAAAAIAEgAGADUIgVwIgUQAWmABADIBRAAMBAAAERdkAAAA CgBQAGwAYQBpAG4AIABUAGUAeAB0AAAAAgATABQAQ0oUAE9KBgBRSgYAXkoGAGFKFAAWAFQAaABl AG8AZABvAHIAZQAgAEIALgAgAFoAYQBoAGEAcgBpAGEAZABpAHMAkSoAANDuAAADAFQAQgBaAAAA AAAAAAAAAAAAAAAAAAAAAN+QnA3cxNSmAAAAAAAAAAAAAAAAAAAAAAAAbQEAAHABAAAAAAAA0O4A AAgAAHwBAAMA/////wAAAAAqAAAAKwAAAFEAAAByAAAAnQAAAMUAAADKAAAA1wAAAOYAAAD/AAAA EQEAABIBAABVAQAAewEAAHwBAACQAQAA1gEAAPcBAAA5AgAAeQIAALkCAADBAgAABwMAAEwDAACK AwAAxQMAAPwDAAAoBAAAaQQAAIoEAAC+BAAAzwQAAA8FAAA2BQAAdAUAAJoFAADaBQAAFgYAAFwG AABuBgAAbwYAAHkGAAC6BgAA/AYAADsHAAB/BwAAvQcAAPcHAAA8CAAAfAgAAI8IAAClCAAA6QgA AC4JAABxCQAAcgkAAHMJAACFCQAAyAkAAAwKAABPCgAAkAoAANIKAAAUCwAAWAsAAJsLAADbCwAA FAwAAE4MAACRDAAA0gwAABMNAABVDQAAlQ0AANUNAAAWDgAAVw4AAJsOAADeDgAAHw8AAF8PAACf DwAA3w8AAB8QAABiEAAAoxAAAOMQAAAjEQAAYxEAAKURAAAVEgAAVRIAAJUSAADVEgAAFRMAAFoT AACdEwAA4BMAACIUAABkFAAAqBQAAOwUAAAwFQAAdxUAALsVAAD/FQAARRYAAFUWAACKFgAAxRYA AAUXAABGFwAAXxcAAKEXAADOFwAAzxcAAN8XAAAkGAAAZxgAAK0YAADxGAAANBkAAHUZAAC1GQAA 9RkAADsaAAB8GgAAwRoAAAUbAABJGwAAjRsAAM0bAADoGwAAJxwAAGgcAACrHAAA6xwAADEdAAB0 HQAAiB0AAIkdAACsHQAA8B0AADIeAAB1HgAAtB4AAPgeAAA7HwAAeB8AALofAAD9HwAAAyAAACwg AABwIAAAtSAAAPggAAA5IQAAeSEAALohAAD0IQAANyIAAHkiAAC4IgAA/iIAAEIjAACCIwAAxyMA AAkkAABNJAAAjiQAANEkAAAXJQAAXSUAAKAlAADjJQAAHyYAAGEmAACeJgAA4SYAACAnAABiJwAA qCcAAL0nAAD8JwAAQSgAAIUoAADIKAAADikAAFIpAACXKQAA1ikAABgqAABbKgAAlCoAAMgqAADM KgAA4ioAAB8rAAA1KwAAOysAAGkrAAB6KwAAiSsAALArAAC7KwAAwSsAAOArAAAULAAAFiwAACQs AABcLAAAZiwAAHwsAACFLAAApiwAAK8sAADSLAAA5SwAAB4tAAA8LQAATS0AAHQtAACjLQAA3y0A AOgtAAAhLgAAWS4AAHQuAACKLgAApS4AAOQuAAArLwAAPy8AAFwvAAB9LwAAwC8AAO4vAAAUMAAA VjAAAJYwAADZMAAA7jAAAO8wAAD/MAAAPjEAAH0xAAC9MQAA+jEAADoyAABzMgAApzIAAN8yAADg MgAA6jIAACgzAABoMwAAqDMAAOczAAAnNAAAZjQAAKM0AAC5NAAAujQAAMc0AAADNQAAQzUAAIE1 AADBNQAAATYAADo2AABjNgAAZDYAAK42AADlNgAAKzcAAGw3AACuNwAA7TcAACw4AABvOAAAtDgA APk4AAA+OQAAgTkAAJE5AADTOQAABzoAAEc6AACIOgAAjToAAM86AADlOgAAIjsAAGM7AACMOwAA yTsAAOQ7AAD+OwAAOjwAAHs8AAC9PAAA5DwAAOU8AAAnPQAAZz0AAKk9AADsPQAA9j0AACM+AABm PgAAij4AALE+AAD2PgAAPD8AAH8/AAC4PwAA9T8AADVAAABzQAAAsEAAAO9AAAAqQQAAQ0EAAGVB AACgQQAA4UEAABdCAABUQgAAk0IAAJ9CAACgQgAAtkIAAO9CAAAuQwAAbkMAAKlDAADEQwAABEQA AD9EAAB8RAAAuUQAANBEAAADRQAAPkUAAHxFAAC2RQAA80UAAB9GAAAgRgAANUYAAHBGAACuRgAA 5kYAACVHAABjRwAAm0cAAL1HAAD6RwAAOEgAAHhIAAC0SAAA8UgAADBJAABwSQAAsUkAAPVJAAA4 SgAAekoAALpKAAD8SgAAQksAAIZLAADASwAAwUsAANhLAAAaTAAAYEwAAKBMAADiTAAAJE0AAGlN AACuTQAA8k0AADJOAAB2TgAAuk4AAPtOAABBTwAAg08AAMBPAAAFUAAAGlAAABtQAABHUAAAi1AA AMlQAADqUAAAKFEAAGlRAACFUQAAy1EAAApSAABPUgAAk1IAANBSAADnUgAAKVMAAG5TAACFUwAA kVMAAKVTAADnUwAAKFQAAGpUAACuVAAA7lQAADNVAABzVQAAuFUAAP5VAAAwVgAAdlYAALZWAADO VgAA7FYAAC5XAABvVwAArVcAAPNXAAASWAAAOFgAAH5YAADBWAAA6VgAAC1ZAABxWQAAtVkAAPZZ AAA1WgAAbloAALFaAADxWgAANFsAAEBbAACDWwAAi1sAAMRbAADiWwAAAFwAACZcAABpXAAAqlwA AO9cAAAzXQAAeV0AAL5dAAAAXgAARF4AAIleAADOXgAAEl8AAC9fAABVXwAAc18AAJxfAADZXwAA H2AAAGNgAABvYAAAomAAAONgAAApYQAAaGEAAH5hAADDYQAA1GEAAPJhAAAaYgAALmIAAFtiAACe YgAA4WIAACRjAABiYwAAnWMAANtjAADuYwAADmQAACJkAAA2ZAAAYGQAAKJkAADmZAAAJ2UAAGdl AACsZQAA62UAAC1mAAByZgAAtGYAAPpmAAA1ZwAAUmcAAHJnAAC0ZwAA+mcAADpoAAB5aAAAuWgA APtoAAA8aQAAfmkAAMJpAAD6aQAANmoAAHVqAAC2agAA92oAADRrAAB0awAAs2sAAPNrAAAIbAAA LmwAAFRsAAB8bAAAkGwAAKNsAADmbAAAKW0AAG5tAACtbQAA720AAChuAABubgAArW4AANluAAAf bwAAY28AAKhvAADrbwAAMXAAAHdwAAC8cAAA4nAAABBxAABVcQAAlXEAANpxAAAGcgAASHIAAIxy AADLcgAADHMAAE5zAACDcwAAyHMAAA10AABJdAAAhnQAAMZ0AAADdQAAE3UAAFh1AACcdQAA4HUA ABN2AAA2dgAAeHYAAL12AAD/dgAAQncAAIV3AADLdwAAC3gAADJ4AAB1eAAAtXgAAPp4AABAeQAA g3kAAMd5AAAJegAASnoAAI96AADSegAAEXsAAEh7AACMewAAx3sAAAR8AABDfAAAg3wAAMF8AAAF fQAARH0AAIl9AADOfQAAEH4AAFZ+AACafgAA0X4AABZ/AABZfwAAkX8AANN/AAD9fwAANIAAAHiA AAC5gAAA6IAAAAuBAABFgQAAi4EAAMuBAAAQggAAUYIAAJGCAADUggAAGIMAAFyDAACggwAA4oMA ACOEAAAthAAAb4QAALSEAADyhAAAOIUAAHiFAAC1hQAA+IUAADWGAAB5hgAAv4YAAPyGAAA8hwAA fYcAAMOHAAAFiAAAS4gAAI6IAADJiAAACYkAAEmJAACFiQAAhokAALOJAAD0iQAAOYoAAHqKAAC5 igAA+ooAAD6LAACDiwAAw4sAAAeMAAAwjAAAa4wAALCMAAD1jAAAMo0AAHiNAAC5jQAA/I0AAD6O AABXjgAAmY4AANyOAAAijwAAaI8AAKyPAADxjwAAMpAAAHKQAAC0kAAA4ZAAACWRAABhkQAApZEA AOORAAApkgAAbpIAALGSAAD1kgAANpMAAFuTAACekwAA5JMAACiUAABulAAAs5QAAPmUAAA7lQAA fZUAALqVAADGlQAAC5YAAE6WAACQlgAA0ZYAABWXAABXlwAAlpcAANuXAAAdmAAAYJgAAKOYAACr mAAA65gAACmZAABrmQAArpkAAPSZAAA3mgAAeZoAAL2aAADVmgAABJsAAEqbAACPmwAAzZsAAA6c AABNnAAAi5wAAM2cAAASnQAAUZ0AAJGdAADVnQAAEp4AAByeAABCngAAf54AAL6eAAABnwAARZ8A AIefAADMnwAAEaAAAFKgAACPoAAAs6AAAPGgAAA2oQAAe6EAAMGhAAAEogAAEKIAAFGiAACUogAA 06IAAPyiAAAjowAAZ6MAAG2jAACjowAA2qMAAB2kAABipAAApaQAAOKkAAAZpQAATaUAAIWlAAC6 pQAA/qUAADymAAB8pgAAwaYAAOemAAAnpwAAaacAAKinAADspwAAMKgAAHOoAAC0qAAA9KgAADap AAB1qQAAtqkAAOSpAAAZqgAAWKoAAJuqAADdqgAAIKsAAGarAACpqwAA7qsAAC6sAABXrAAAnKwA AOKsAAAhrQAAY60AAKStAAC+rQAAAq4AAEKuAACHrgAAwa4AAN6uAAAdrwAAYK8AAKOvAADjrwAA JbAAADqwAACAsAAAxLAAAAWxAABKsQAAhrEAAMKxAAAHsgAASrIAAI6yAADNsgAADrMAAFCzAACU swAA1LMAABS0AAA+tAAAhLQAAMO0AAAGtQAASrUAAHS1AACztQAAybUAAPG1AAATtgAAMbYAAHO2 AACytgAA8LYAADO3AAB3twAAuLcAAAK4AAA0uAAAebgAALi4AAD9uAAAP7kAAIC5AADEuQAA37kA AB66AABiugAAo7oAAOS6AAAmuwAAZbsAAKm7AADouwAAH7wAAEK8AACFvAAAybwAAAq9AABOvQAA Vr0AAJu9AADXvQAAGL4AAFO+AACJvgAAzb4AANi+AAAYvwAAK78AAGS/AAB7vwAAv78AAOC/AAAl wAAAY8AAAJvAAADbwAAAHcEAAGDBAAChwQAA48EAACnCAABuwgAArMIAAO7CAAAawwAAScMAAIvD AACywwAA+MMAAD/EAABexAAApMQAAMfEAADrxAAAD8UAACPFAABTxQAAmMUAANfFAAAbxgAAWMYA AG7GAACzxgAA2MYAABzHAABJxwAAhscAAMLHAAD8xwAAQsgAAITIAADIyAAAAskAAETJAACGyQAA yckAABDKAABXygAA6coAADHLAAB0ywAAucsAAAXMAAA9zAAAP8wAAEDMAABjzAAAp8wAAOzMAAAx zQAAP80AAILNAADHzQAADM4AAE7OAACOzgAAzc4AABLPAABUzwAAkM8AANTPAAD1zwAAI9AAAGTQ AACb0AAA09AAAA7RAABT0QAAj9EAANXRAAAZ0gAAWNIAAJTSAACi0gAAxdIAAAnTAABP0wAAkNMA ALfTAAD80wAAQtQAAILUAADC1AAABdUAAEbVAACJ1QAAy9UAAA/WAABK1gAAjtYAANLWAADv1gAA CdcAAE7XAACU1wAA1tcAABzYAAAq2AAASNgAAHzYAACh2AAAutgAANjYAAAd2QAANdkAAGPZAACk 2QAAxdkAAPPZAAAx2gAATNoAAH3aAACm2gAAwNoAAOHaAAAY2wAATtsAAH7bAACd2wAA3dsAAB/c AABk3AAAkdwAAMzcAAAN3QAATt0AAI3dAACp3QAAwN0AAOfdAAAC3gAARt4AAH7eAADA3gAAA98A ACPfAABL3wAAlN8AANjfAAAg4AAAZ+AAALHgAAD44AAAG+EAABzhAAAv4QAAP+EAAFvhAACZ4QAA zOEAAOrhAAD24QAALOIAAGfiAACf4gAA0+IAAA7jAAAd4wAAQ+MAAHbjAACx4wAA6+MAAA7kAAAw 5AAAaOQAAIPkAAC85AAAy+QAAO7kAAAk5QAAXOUAAJblAACv5QAAy+UAAPzlAAAv5gAASOYAAGvm AACe5gAA1eYAAAbnAABA5wAAWucAAHPnAACu5wAA6OcAAALoAAAP6AAARegAAH3oAAC16AAA7+gA AP3oAAA36QAAcekAAKfpAADb6QAA5ekAACjqAABU6gAAk+oAAKrqAAC96gAA0eoAAN3qAAD76gAA FusAABrrAAA76wAAV+sAAGPrAACB6wAAnOsAAKDrAADG6wAA3esAAOLrAAAb7AAAOuwAAEDsAABd 7AAAcuwAAIvsAACt7AAAvewAAMPsAADe7AAA9OwAAA3tAAAv7QAAP+0AAEXtAABh7QAAke0AANbt AAA07gAANe4AAM7uAADR7gAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAACAAZgAAAAAMAAAAAAA AACAAAAAgAAAAAAAAAAAAAGYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAABmAAAAAAwAAAAAAAA AIAAAACAAAAAAAAAAAAAAZgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAAGYAAAAADAAAAAAAAAA gAAAAIAAAAAAAAAAAAABmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAZgAAAAAMAAAAAAAAACA AAAAgAAAAAAAAAAAAAGYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAABmAAAAAAwAAAAAAAAAIAA AACAAAAAAAAAAAAAAZgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAAGYAAAAADAAAAAAAAAAgAAA AIAAAAAAAAAAAAABmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAZgAAAAAMAAAAAAAAACAAAAA gAAAAAAAAAAAAAGYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAABmAAAAAAwAAAAAAAAAIAAAACA AAAAAAAAAAAAAZgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAAGYAAAAADAAAAAAAAAAgAAAAIAA AAAAAAAAAAABmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAZgAAAAAMAAAAAAAAACAAAAAgAAA AAAAAAAAAAGYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAABmAAAAAAwAAAAAAAAAIAAAACAAAAA AAAAAAAAAZgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAAGYAAAAADAAAAAAAAAAgAAAAIAAAAAA AAAAAAABmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAZgAAAAAMAAAAAAAAACAAAAAgAAAAAAA AAAAAAGYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAABmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAA AAAAAZgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAAGYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAA AAABmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAZgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAA AAGYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAABmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAA AZgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAAGYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAB mAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAZgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAAGY AAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAABmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAZgA AAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAAGYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAABmAAA AAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAZgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAAGYAAAA ADAAAAAAAAAAgAAAAIAAAAAAAAAAAAABmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAZgAAAAA MAAAAAAAAACAAAAAgAAAAAAAAAAAAAGYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAABmAAAAAAw AAAAAAAAAIAAAACAAAAAAAAAAAAAAZgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAAGYAAAAADAA AAAAAAAAgAAAAIAAAAAAAAAAAAABmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAZgAAAAAMAAA AAAAAACAAAAAgAAAAAAAAAAAAAGYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAABmAAAAAAwAAAA AAAAAIAAAACAAAAAAAAAAAAAAZgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAAGYAAAAADAAAAAA AAAAgAAAAIAAAAAAAAAAAAABmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAZgAAAAAMAAAAAAA AACAAAAAgAAAAAAAAAAAAAGYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAABmAAAAAAwAAAAAAAA AIAAAACAAAAAAAAAAAAAAZgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAAGYAAAAADAAAAAAAAAA gAAAAIAAAAAAAAAAAAABmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAZgAAAAAMAAAAAAAAACA AAAAgAAAAAAAAAAAAAGYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAABmAAAAAAwAAAAAAAAAIAA AACAAAAAAAAAAAAAAZgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAAGYAAAAADAAAAAAAAAAgAAA AIAAAAAAAAAAAAABmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAZgAAAAAMAAAAAAAAACAAAAA gAAAAAAAAAAAAAGYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAABmAAAAAAwAAAAAAAAAIAAAACA AAAAAAAAAAAAAZgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAAGYAAAAADAAAAAAAAAAgAAAAIAA AAAAAAAAAAABmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAZgAAAAAMAAAAAAAAACAAAAAgAAA AAAAAAAAAAGYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAABmAAAAAAwAAAAAAAAAIAAAACAAAAA AAAAAAAAAZgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAAGYAAAAADAAAAAAAAAAgAAAAIAAAAAA AAAAAAABmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAZgAAAAAMAAAAAAAAACAAAAAgAAAAAAA AAAAAAGYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAABmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAA AAAAAZgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAAGYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAA AAABmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAZgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAA AAGYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAABmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAA AZgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAAGYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAB mAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAZgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAAGY AAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAABmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAZgA AAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAAGYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAABmAAA AAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAZgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAAGYAAAA ADAAAAAAAAAAgAAAAIAAAAAAAAAAAAABmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAZgAAAAA MAAAAAAAAACAAAAAgAAAAAAAAAAAAAGYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAABmAAAAAAw AAAAAAAAAIAAAACAAAAAAAAAAAAAAZgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAAGYAAAAADAA AAAAAAAAgAAAAIAAAAAAAAAAAAABmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAZgAAAAAMAAA AAAAAACAAAAAgAAAAAAAAAAAAAGYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAABmAAAAAAwAAAA AAAAAIAAAACAAAAAAAAAAAAAAZgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAAGYAAAAADAAAAAA AAAAgAAAAIAAAAAAAAAAAAABmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAZgAAAAAMAAAAAAA AACAAAAAgAAAAAAAAAAAAAGYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAABmAAAAAAwAAAAAAAA AIAAAACAAAAAAAAAAAAAAZgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAAGYAAAAADAAAAAAAAAA gAAAAIAAAAAAAAAAAAABmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAZgAAAAAMAAAAAAAAACA AAAAgAAAAAAAAAAAAAGYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAABmAAAAAAwAAAAAAAAAIAA AACAAAAAAAAAAAAAAZgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAAGYAAAAADAAAAAAAAAAgAAA AIAAAAAAAAAAAAABmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAZgAAAAAMAAAAAAAAACAAAAA gAAAAAAAAAAAAAGYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAABmAAAAAAwAAAAAAAAAIAAAACA AAAAAAAAAAAAAZgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAAGYAAAAADAAAAAAAAAAgAAAAIAA AAAAAAAAAAABmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAZgAAAAAMAAAAAAAAACAAAAAgAAA AAAAAAAAAAGYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAABmAAAAAAwAAAAAAAAAIAAAACAAAAA AAAAAAAAAZgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAAGYAAAAADAAAAAAAAAAgAAAAIAAAAAA AAAAAAABmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAZgAAAAAMAAAAAAAAACAAAAAgAAAAAAA AAAAAAGYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAABmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAA AAAAAZgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAAGYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAA AAABmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAZgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAA AAGYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAABmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAA AZgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAAGYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAB mAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAZgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAAGY AAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAABmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAZgA AAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAAGYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAABmAAA AAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAZgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAAGYAAAA ADAAAAAAAAAAgAAAAIAAAAAAAAAAAAABmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAZgAAAAA MAAAAAAAAACAAAAAgAAAAAAAAAAAAAGYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAABmAAAAAAw AAAAAAAAAIAAAACAAAAAAAAAAAAAAZgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAAGYAAAAADAA AAAAAAAAgAAAAIAAAAAAAAAAAAABmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAZgAAAAAMAAA AAAAAACAAAAAgAAAAAAAAAAAAAGYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAABmAAAAAAwAAAA AAAAAIAAAACAAAAAAAAAAAAAAZgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAAGYAAAAADAAAAAA AAAAgAAAAIAAAAAAAAAAAAABmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAZgAAAAAMAAAAAAA AACAAAAAgAAAAAAAAAAAAAGYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAABmAAAAAAwAAAAAAAA AIAAAACAAAAAAAAAAAAAAZgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAAGYAAAAADAAAAAAAAAA gAAAAIAAAAAAAAAAAAABmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAZgAAAAAMAAAAAAAAACA AAAAgAAAAAAAAAAAAAGYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAABmAAAAAAwAAAAAAAAAIAA AACAAAAAAAAAAAAAAZgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAAGYAAAAADAAAAAAAAAAgAAA AIAAAAAAAAAAAAABmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAZgAAAAAMAAAAAAAAACAAAAA gAAAAAAAAAAAAAGYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAABmAAAAAAwAAAAAAAAAIAAAACA AAAAAAAAAAAAAZgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAAGYAAAAADAAAAAAAAAAgAAAAIAA AAAAAAAAAAABmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAZgAAAAAMAAAAAAAAACAAAAAgAAA AAAAAAAAAAGYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAABmAAAAAAwAAAAAAAAAIAAAACAAAAA AAAAAAAAAZgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAAGYAAAAADAAAAAAAAAAgAAAAIAAAAAA AAAAAAABmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAZgAAAAAMAAAAAAAAACAAAAAgAAAAAAA AAAAAAGYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAABmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAA AAAAAZgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAAGYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAA AAABmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAZgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAA AAGYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAABmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAA AZgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAAGYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAB mAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAZgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAAGY AAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAABmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAZgA AAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAAGYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAABmAAA AAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAZgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAAGYAAAA ADAAAAAAAAAAgAAAAIAAAAAAAAAAAAABmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAZgAAAAA MAAAAAAAAACAAAAAgAAAAAAAAAAAAAGYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAABmAAAAAAw AAAAAAAAAIAAAACAAAAAAAAAAAAAAZgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAAGYAAAAADAA AAAAAAAAgAAAAIAAAAAAAAAAAAABmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAZgAAAAAMAAA AAAAAACAAAAAgAAAAAAAAAAAAAGYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAABmAAAAAAwAAAA AAAAAIAAAACAAAAAAAAAAAAAAZgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAAGYAAAAADAAAAAA AAAAgAAAAIAAAAAAAAAAAAABmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAZgAAAAAMAAAAAAA AACAAAAAgAAAAAAAAAAAEAGYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAABmAAAAAAwAAAAAAAA AIAAAACAAAAAAAAAAAAQAZgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAEAGYAAAAADAAAAAAAAAA gAAAAIAAAAAAAAAAABABmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAQAZgAAAAAMAAAAAAAAACA AAAAgAAAAAAAAAAAAAGYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAABmAAAAAAwAAAAAAAAAIAA AACAAAAAAAAAAAAAAZgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAAGYAAAAADAAAAAAAAAAgAAA AIAAAAAAAAAAAAABmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAZgAAAAAMAAAAAAAAACAAAAA gAAAAAAAAAAAAAGYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAABABmAAAAAAwAAAAAAAAAIAAAACA AAAAAAAAAAAAAZgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAAGYAAAAADAAAAAAAAAAgAAAAIAA AAAAAAAAAAABmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAZgAAAAAMAAAAAAAAACAAAAAgAAA AAAAAAAAAAGYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAABmAAAAAAwAAAAAAAAAIAAAACAAAAA AAAAAAAAAZgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAAGYAAAAADAAAAAAAAAAgAAAAIAAAAAA AAAAAAABmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAQAZgAAAAAMAAAAAAAAACAAAAAgAAAAAAA AAAAAAGYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAABmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAA AAAAAZgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAAGYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAA AAABmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAZgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAA AAGYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAABmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAA AZgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAAGYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAB mAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAZgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAAGY AAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAABmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAZgA AAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAAGYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAABmAAA AAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAZgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAEAGYAAAA ADAAAAAAAAAAgAAAAIAAAAAAAAAAAAABmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAZgAAAAA MAAAAAAAAACAAAAAgAAAAAAAAAAAAAGYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAABmAAAAAAw AAAAAAAAAIAAAACAAAAAAAAAAAAAAZgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAAGYAAAAADAA AAAAAAAAgAAAAIAAAAAAAAAAAAABmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAZgAAAAAMAAA AAAAAACAAAAAgAAAAAAAAAAAAAGYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAABmAAAAAAwAAAA AAAAAIAAAACAAAAAAAAAAAAAAZgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAAGYAAAAADAAAAAA AAAAgAAAAIAAAAAAAAAAAAABmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAZgAAAAAMAAAAAAA AACAAAAAgAAAAAAAAAAAAAGYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAABmAAAAAAwAAAAAAAA AIAAAACAAAAAAAAAAAAAAZgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAAGYAAAAADAAAAAAAAAA gAAAAIAAAAAAAAAAAAABmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAZgAAAAAMAAAAAAAAACA AAAAgAAAAAAAAAAAAAGYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAABmAAAAAAwAAAAAAAAAIAA AACAAAAAAAAAAAAAAZgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAEAGYAAAAADAAAAAAAAAAgAAA AIAAAAAAAAAAAAgBmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAZgAAAAAMAAAAAAAAACAAAAA gAAAAAAAAAAAAAGYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAABmAAAAAAwAAAAAAAAAIAAAACA AAAAAAAAAAAAAZgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAAGYAAAAADAAAAAAAAAAgAAAAIAA AAAAAAAAABABmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAZgAAAAAMAAAAAAAAACAAAAAgAAA AAAAAAAAAAGYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAABmAAAAAAwAAAAAAAAAIAAAACAAAAA AAAAAAAAAZgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAAGYAAAAADAAAAAAAAAAgAAAAIAAAAAA AAAAAAABmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAZgAAAAAMAAAAAAAAACAAAAAgAAAAAAA AAAAAAGYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAABmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAA AAAAAZgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAAGYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAA AAABmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAZgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAA AAGYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAABmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAA AZgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAAGYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAB mAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAZgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAAGY AAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAABmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAZgA AAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAAGYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAABmAAA AAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAZgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAAGYAAAA ADAAAAAAAAAAgAAAAIAAAAAAAAAAAAABmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAZgAAAAA MAAAAAAAAACAAAAAgAAAAAAAAAAAAAGYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAABmAAAAAAw AAAAAAAAAIAAAACAAAAAAAAAAAAAAZgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAAGYAAAAADAA AAAAAAAAgAAAAIAAAAAAAAAAAAABmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAZgAAAAAMAAA AAAAAACAAAAAgAAAAAAAAAAAAAGYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAABmAAAAAAwAAAA AAAAAIAAAACAAAAAAAAAAAAAAZgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAAGYAAAAADAAAAAA AAAAgAAAAIAAAAAAAAAAAAABmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAZgAAAAAMAAAAAAA AACAAAAAgAAAAAAAAAAAAAGYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAABmAAAAAAwAAAAAAAA AIAAAACAAAAAAAAAAAAAAZgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAAGYAAAAADAAAAAAAAAA gAAAAIAAAAAAAAAAAAABmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAZgAAAAAMAAAAAAAAACA AAAAgAAAAAAAAAAAAAGYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAABmAAAAAAwAAAAAAAAAIAA AACAAAAAAAAAAAAAAZgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAAGYAAAAADAAAAAAAAAAgAAA AIAAAAAAAAAAAAABmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAZgAAAAAMAAAAAAAAACAAAAA gAAAAAAAAAAAAAGYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAABmAAAAAAwAAAAAAAAAIAAAACA AAAAAAAAAAAAAZgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAAGYAAAAADAAAAAAAAAAgAAAAIAA AAAAAAAAAAABmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAZgAAAAAMAAAAAAAAACAAAAAgAAA AAAAAAAAAAGYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAABmAAAAAAwAAAAAAAAAIAAAACAAAAA AAAAAAAAAZgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAAGYAAAAADAAAAAAAAAAgAAAAIAAAAAA AAAAAAABmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAZgAAAAAMAAAAAAAAACAAAAAgAAAAAAA AAAAAAGYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAABmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAA AAAAAZgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAAGYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAA AAABmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAZgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAA AAGYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAABmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAA AZgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAAGYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAB mAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAZgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAAGY AAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAABmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAZgA AAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAAGYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAABmAAA AAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAZgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAAGYAAAA ADAAAAAAAAAAgAAAAIAAAAAAAAAAAAABmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAZgAAAAA MAAAAAAAAACAAAAAgAAAAAAAAAAAAAGYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAABmAAAAAAw AAAAAAAAAIAAAACAAAAAAAAAAAAAAZgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAAGYAAAAADAA AAAAAAAAgAAAAIAAAAAAAAAAAAABmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAZgAAAAAMAAA AAAAAACAAAAAgAAAAAAAAAAAAAGYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAABmAAAAAAwAAAA AAAAAIAAAACAAAAAAAAAAAAAAZgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAAGYAAAAADAAAAAA AAAAgAAAAIAAAAAAAAAAAAABmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAZgAAAAAMAAAAAAA AACAAAAAgAAAAAAAAAAAAAGYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAABmAAAAAAwAAAAAAAA AIAAAACAAAAAAAAAAAAAAZgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAAGYAAAAADAAAAAAAAAA gAAAAIAAAAAAAAAAAAABmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAZgAAAAAMAAAAAAAAACA AAAAgAAAAAAAAAAAAAGYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAABmAAAAAAwAAAAAAAAAIAA AACAAAAAAAAAAAAAAZgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAAGYAAAAADAAAAAAAAAAgAAA AIAAAAAAAAAAAAABmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAZgAAAAAMAAAAAAAAACAAAAA gAAAAAAAAAAAAAGYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAABmAAAAAAwAAAAAAAAAIAAAACA AAAAAAAAAAAAAZgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAAGYAAAAADAAAAAAAAAAgAAAAIAA AAAAAAAAAAABmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAZgAAAAAMAAAAAAAAACAAAAAgAAA AAAAAAAAAAGYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAABmAAAAAAwAAAAAAAAAIAAAACAAAAA AAAAAAAAAZgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAAGYAAAAADAAAAAAAAAAgAAAAIAAAAAA AAAAAAABmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAZgAAAAAMAAAAAAAAACAAAAAgAAAAAAA AAAAAAGYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAABmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAA AAAAAZgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAAGYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAA AAABmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAZgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAA AAGYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAABmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAA AZgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAAGYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAB mAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAZgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAAGY AAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAABmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAZgA AAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAAGYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAABmAAA AAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAZgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAAGYAAAA ADAAAAAAAAAAgAAAAIAAAAAAAAAAAAABmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAZgAAAAA MAAAAAAAAACAAAAAgAAAAAAAAAAAAAGYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAABmAAAAAAw AAAAAAAAAIAAAACAAAAAAAAAAAAAAZgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAAGYAAAAADAA AAAAAAAAgAAAAIAAAAAAAAAAAAABmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAZgAAAAAMAAA AAAAAACAAAAAgAAAAAAAAAAAAAGYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAABmAAAAAAwAAAA AAAAAIAAAACAAAAAAAAAAAAAAZgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAAGYAAAAADAAAAAA AAAAgAAAAIAAAAAAAAAAAAABmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAZgAAAAAMAAAAAAA AACAAAAAgAAAAAAAAAAAAAGYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAABmAAAAAAwAAAAAAAA AIAAAACAAAAAAAAAAAAAAZgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAAGYAAAAADAAAAAAAAAA gAAAAIAAAAAAAAAAAAABmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAZgAAAAAMAAAAAAAAACA AAAAgAAAAAAAAAAAAAGYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAABmAAAAAAwAAAAAAAAAIAA AACAAAAAAAAAAAAAAZgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAAGYAAAAADAAAAAAAAAAgAAA AIAAAAAAAAAAAAABmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAZgAAAAAMAAAAAAAAACAAAAA gAAAAAAAAAAAAAGYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAABmAAAAAAwAAAAAAAAAIAAAACA AAAAAAAAAAAAAZgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAAGYAAAAADAAAAAAAAAAgAAAAIAA AAAAAAAAAAABmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAZgAAAAAMAAAAAAAAACAAAAAgAAA AAAAAAAAAAGYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAABmAAAAAAwAAAAAAAAAIAAAACAAAAA AAAAAAAAAZgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAAGYAAAAADAAAAAAAAAAgAAAAIAAAAAA AAAAAAABmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAZgAAAAAMAAAAAAAAACAAAAAgAAAAAAA AAAAAAGYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAABmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAA AAAAAZgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAAGYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAA AAABmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAZgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAA AAGYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAABmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAA AZgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAAGYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAB mAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAZgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAAGY AAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAABmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAZgA AAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAAGYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAABmAAA AAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAZgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAAGYAAAA ADAAAAAAAAAAgAAAAIAAAAAAAAAAAAABmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAZgAAAAA MAAAAAAAAACAAAAAgAAAAAAAAAAAAAGYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAABmAAAAAAw AAAAAAAAAIAAAACAAAAAAAAAAAAAAZgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAAGYAAAAADAA AAAAAAAAgAAAAIAAAAAAAAAAAAABmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAZgAAAAAMAAA AAAAAACAAAAAgAAAAAAAAAAAAAGYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAABmAAAAAAwAAAA AAAAAIAAAACAAAAAAAAAAAAAAZgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAAGYAAAAADAAAAAA AAAAgAAAAIAAAAAAAAAAAAABmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAZgAAAAAMAAAAAAA AACAAAAAgAAAAAAAAAAAAAGYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAABmAAAAAAwAAAAAAAA AIAAAACAAAAAAAAAAAAAAZgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAAGYAAAAADAAAAAAAAAA gAAAAIAAAAAAAAAAAAABmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAZgAAAAAMAAAAAAAAACA AAAAgAAAAAAAAAAAAAGYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAABmAAAAAAwAAAAAAAAAIAA AACAAAAAAAAAAAAAAZgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAAGYAAAAADAAAAAAAAAAgAAA AIAAAAAAAAAAAAABmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAZgAAAAAMAAAAAAAAACAAAAA gAAAAAAAAAAAAAGYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAABmAAAAAAwAAAAAAAAAIAAAACA AAAAAAAAAAAAAZgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAAGYAAAAADAAAAAAAAAAgAAAAIAA AAAAAAAAAAABmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAZgAAAAAMAAAAAAAAACAAAAAgAAA AAAAAAAAAAGYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAABmAAAAAAwAAAAAAAAAIAAAACAAAAA AAAAAAAAAZgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAAGYAAAAADAAAAAAAAAAgAAAAIAAAAAA AAAAAAABmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAZgAAAAAMAAAAAAAAACAAAAAgAAAAAAA AAAAAAGYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAABmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAA AAAAAZgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAAGYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAA AAABmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAZgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAA AAGYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAABmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAA AZgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAAGYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAB mAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAZgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAAGY AAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAABmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAZgA AAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAAGYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAABmAAA AAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAZgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAAGYAAAA ADAAAAAAAAAAgAAAAIAAAAAAAAAAAAABmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAZgAAAAA MAAAAAAAAACAAAAAgAAAAAAAAAAAAAGYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAABmAAAAAAw AAAAAAAAAIAAAACAAAAAAAAAAAAAAZgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAAGYAAAAADAA AAAAAAAAgAAAAIAAAAAAAAAAAAABmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAZgAAAAAMAAA AAAAAACAAAAAgAAAAAAAAAAAAAGYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAABmAAAAAAwAAAA AAAAAIAAAACAAAAAAAAAAAAAAZgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAAGYAAAAADAAAAAA AAAAgAAAAIAAAAAAAAAAAAABmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAZgAAAAAMAAAAAAA AACAAAAAgAAAAAAAAAAAAAGYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAABmAAAAAAwAAAAAAAA AIAAAACAAAAAAAAAAAAAAZgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAAGYAAAAADAAAAAAAAAA gAAAAIAAAAAAAAAAAAABmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAZgAAAAAMAAAAAAAAACA AAAAgAAAAAAAAAAAAAGYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAABmAAAAAAwAAAAAAAAAIAA AACAAAAAAAAAAAAAAZgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAAGYAAAAADAAAAAAAAAAgAAA AIAAAAAAAAAAAAABmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAZgAAAAAMAAAAAAAAACAAAAA gAAAAAAAAAAAAAGYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAABmAAAAAAwAAAAAAAAAIAAAACA AAAAAAAAAAAAAZgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAAGYAAAAADAAAAAAAAAAgAAAAIAA AAAAAAAAAAABmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAZgAAAAAMAAAAAAAAACAAAAAgAAA AAAAAAAAAAGYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAABmAAAAAAwAAAAAAAAAIAAAACAAAAA AAAAAAAAAZgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAAGYAAAAADAAAAAAAAAAgAAAAIAAAAAA AAAAAAABmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAZgAAAAAMAAAAAAAAACAAAAAgAAAAAAA AAAAAAGYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAABmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAA AAAAAZgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAAGYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAA AAABmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAZgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAA AAGYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAABmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAA AZgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAAGYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAB mAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAZgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAAGY AAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAABmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAZgA AAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAAGYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAABmAAA AAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAZgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAAGYAAAA ADAAAAAAAAAAgAAAAIAAAAAAAAAAAAABmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAZgAAAAA MAAAAAAAAACAAAAAgAAAAAAAAAAAAAGYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAABmAAAAAAw AAAAAAAAAIAAAACAAAAAAAAAAAAAAZgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAAGYAAAAADAA AAAAAAAAgAAAAIAAAAAAAAAAAAABmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAZgAAAAAMAAA AAAAAACAAAAAgAAAAAAAAAAAAAGYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAABmAAAAAAwAAAA AAAAAIAAAACAAAAAAAAAAAAAAZgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAAGYAAAAADAAAAAA AAAAgAAAAIAAAAAAAAAAAAABmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAZgAAAAAMAAAAAAA AACAAAAAgAAAAAAAAAAAAAGYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAABmAAAAAAwAAAAAAAA AIAAAACAAAAAAAAAAAAAAZgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAAGYAAAAADAAAAAAAAAA gAAAAIAAAAAAAAAAAAABmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAZgAAAAAMAAAAAAAAACA AAAAgAAAAAAAAAAAAAGYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAABmAAAAAAwAAAAAAAAAIAA AACAAAAAAAAAAAAAAZgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAAGYAAAAADAAAAAAAAAAgAAA AIAAAAAAAAAAAAABmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAZgAAAAAMAAAAAAAAACAAAAA gAAAAAAAAAAAAAGYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAABmAAAAAAwAAAAAAAAAIAAAACA AAAAAAAAAAAAAZgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAAGYAAAAADAAAAAAAAAAgAAAAIAA AAAAAAAAAAABmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAZgAAAAAMAAAAAAAAACAAAAAgAAA AAAAAAAAAAGYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAABmAAAAAAwAAAAAAAAAIAAAACAAAAA AAAAAAAAAZgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAAGYAAAAADAAAAAAAAAAgAAAAIAAAAAA AAAAAAABmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAZgAAAAAMAAAAAAAAACAAAAAgAAAAAAA AAAAAAGYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAABmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAA AAAAAZgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAAGYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAA AAABmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAZgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAA AAGYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAABmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAA AZgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAAGYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAB mAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAZgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAAGY AAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAABmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAZgA AAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAAGYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAABmAAA AAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAZgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAAGYAAAA ADAAAAAAAAAAgAAAAIAAAAAAAAAAAAABmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAZgAAAAA MAAAAAAAAACAAAAAgAAAAAAAAAAAAAGYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAABmAAAAAAw AAAAAAAAAIAAAACAAAAAAAAAAAAAAZgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAAGYAAAAADAA AAAAAAAAgAAAAIAAAAAAAAAAAAABmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAZgAAAAAMAAA AAAAAACAAAAAgAAAAAAAAAAAAAGYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAABmAAAAAAwAAAA AAAAAIAAAACAAAAAAAAAAAAAAZgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAAGYAAAAADAAAAAA AAAAgAAAAIAAAAAAAAAAAAABmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAZgAAAAAMAAAAAAA AACAAAAAgAAAAAAAAAAAAAGYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAABmAAAAAAwAAAAAAAA AIAAAACAAAAAAAAAAAAAAZgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAAGYAAAAADAAAAAAAAAA gAAAAIAAAAAAAAAAAAABmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAZgAAAAAMAAAAAAAAACA AAAAgAAAAAAAAAAAAAGYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAABmAAAAAAwAAAAAAAAAIAA AACAAAAAAAAAAAAAAZgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAAGYAAAAADAAAAAAAAAAgAAA AIAAAAAAAAAAAAABmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAZgAAAAAMAAAAAAAAACAAAAA gAAAAAAAAAAAAAGYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAABmAAAAAAwAAAAAAAAAIAAAACA AAAAAAAAAAAAAZgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAAGYAAAAADAAAAAAAAAAgAAAAIAA AAAAAAAAAAABmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAZgAAAAAMAAAAAAAAACAAAAAgAAA AAAAAAAAAAGYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAABmAAAAAAwAAAAAAAAAIAAAACAAAAA AAAAAAAAAZgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAAGYAAAAADAAAAAAAAAAgAAAAIAAAAAA AAAAAAABmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAZgAAAAAMAAAAAAAAACAAAAAgAAAAAAA AAAAAAGYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAABmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAA AAAAAZgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAAGYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAA AAABmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAZgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAA AAGYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAABmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAA AZgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAAGYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAB mAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAZgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAAGY AAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAABmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAZgA AAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAAGYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAABmAAA AAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAZgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAAGYAAAA ADAAAAAAAAAAgAAAAIAAAAAAAAAAAAABmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAZgAAAAA MAAAAAAAAACAAAAAgAAAAAAAAAAAAAGYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAABmAAAAAAw AAAAAAAAAIAAAACAAAAAAAAAAAAAAZgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAAGYAAAAADAA AAAAAAAAgAAAAIAAAAAAAAAAAAABmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAZgAAAAAMAAA AAAAAACAAAAAgAAAAAAAAAAAAAGYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAABmAAAAAAwAAAA AAAAAIAAAACAAAAAAAAAAAAAAZgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAAGYAAAAADAAAAAA AAAAgAAAAIAAAAAAAAAAAAABmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAZgAAAAAMAAAAAAA AACAAAAAgAAAAAAAAAAAAAGYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAABmAAAAAAwAAAAAAAA AIAAAACAAAAAAAAAAAAAAZgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAAGYAAAAADAAAAAAAAAA gAAAAIAAAAAAAAAAAAABmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAZgAAAAAMAAAAAAAAACA AAAAgAAAAAAAAAAAAAGYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAABmAAAAAAwAAAAAAAAAIAA AACAAAAAAAAAAAAAAZgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAAGYAAAAADAAAAAAAAAAgAAA AIAAAAAAAAAAAAABmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAZgAAAAAMAAAAAAAAACAAAAA gAAAAAAAAAAAAAGYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAABmAAAAAAwAAAAAAAAAIAAAACA AAAAAAAAAAAAAZgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAAGYAAAAADAAAAAAAAAAgAAAAIAA AAAAAAAAAAABmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAZgAAAAAMAAAAAAAAACAAAAAgAAA AAAAAAAAAAGYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAABmAAAAAAwAAAAAAAAAIAAAACAAAAA AAAAAAAAAZgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAAGYAAAAADAAAAAAAAAAgAAAAIAAAAAA AAAAAAABmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAZgAAAAAMAAAAAAAAACAAAAAgAAAAAAA AAAAAAGYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAABmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAA AAAAAZgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAAGYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAA AAABmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAZgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAA AAGYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAABmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAA AZgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAAGYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAB mAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAZgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAAGY AAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAABmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAZgA AAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAAGYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAABmAAA AAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAZgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAAGYAAAA ADAAAAAAAAAAgAAAAIAAAAAAAAAAAAABmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAZgAAAAA MAAAAAAAAACAAAAAgAAAAAAAAAAAAAGYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAABmAAAAAAw AAAAAAAAAIAAAACAAAAAAAAAAAAAAZgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAAGYAAAAADAA AAAAAAAAgAAAAIAAAAAAAAAAAAABmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAZgAAAAAMAAA AAAAAACAAAAAgAAAAAAAAAAAAAGYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAABmAAAAAAwAAAA AAAAAIAAAACAAAAAAAAAAAAAAZgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAAGYAAAAADAAAAAA AAAAgAAAAIAAAAAAAAAAABABmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAZgAAAAAMAAAAAAA AACAAAAAgAAAAAAAAAAAAAGYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAABmAAAAAAwAAAAAAAA AIAAAACAAAAAAAAAAAAAAZgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAAGYAAAAADAAAAAAAAAA gAAAAIAAAAAAAAAAAAABmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAZgAAAAAMAAAAAAAAACA AAAAgAAAAAAAAAAAAAGYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAABmAAAAAAwAAAAAAAAAIAA AACAAAAAAAAAAAAAAZgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAAGYAAAAADAAAAAAAAAAgAAA AIAAAAAAAAAAAAABmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAZgAAAAAMAAAAAAAAACAAAAA gAAAAAAAAAAAAAGYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAABmAAAAAAwAAAAAAAAAIAAAACA AAAAAAAAAAAAAZgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAAGYAAAAADAAAAAAAAAAgAAAAIAA AAAAAAAAAAABmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAZgAAAAAMAAAAAAAAACAAAAAgAAA AAAAAAAAAAGYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAABmAAAAAAwAAAAAAAAAIAAAACAAAAA AAAAAAAAAZgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAAGYAAAAADAAAAAAAAAAgAAAAIAAAAAA AAAAAAABmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAZgAAAAAMAAAAAAAAACAAAAAgAAAAAAA AAAAAAGYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAABmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAA AAAAAZgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAAGYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAA AAABmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAZgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAA AAGYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAABmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAA AZgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAAGYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAB mAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAZgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAAGY AAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAABmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAZgA AAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAAGYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAABmAAA AAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAZgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAAGYAAAA ADAAAAAAAAAAgAAAAIAAAAAAAAAAAAABmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAZgAAAAA MAAAAAAAAACAAAAAgAAAAAAAAAAAAAGYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAABmAAAAAAw AAAAAAAAAIAAAACAAAAAAAAAAAAAAZgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAAGYAAAAADAA AAAAAAAAgAAAAIAAAAAAAAAAAAABmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAZgAAAAAMAAA AAAAAACAAAAAgAAAAAAAAAAAAAGYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAABmAAAAAAwAAAA AAAAAIAAAACAAAAAAAAAAAAAAZgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAAGYAAAAADAAAAAA AAAAgAAAAIAAAAAAAAAAAAABmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAZgAAAAAMAAAAAAA AACAAAAAgAAAAAAAAAAAAAGYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAABmAAAAAAwAAAAAAAA AIAAAACAAAAAAAAAAAAAAZgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAAGYAAAAADAAAAAAAAAA gAAAAIAAAAAAAAAAAAABmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAZgAAAAAMAAAAAAAAACA AAAAgAAAAAAAAAAAAAGYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAABmAAAAAAwAAAAAAAAAIAA AACAAAAAAAAAAAAAAZgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAAGYAAAAADAAAAAAAAAAgAAA AIAAAAAAAAAAAAABmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAZgAAAAAMAAAAAAAAACAAAAA gAAAAAAAAAAAAAGYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAABmAAAAAAwAAAAAAAAAIAAAACA AAAAAAAAAAAAAZgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAAGYAAAAADAAAAAAAAAAgAAAAIAA AAAAAAAAAAABmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAZgAAAAAMAAAAAAAAACAAAAAgAAA AAAAAAAAAAGYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAABmAAAAAAwAAAAAAAAAIAAAACAAAAA AAAAAAAAAZgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAAGYAAAAADAAAAAAAAAAgAAAAIAAAAAA AAAAAAABmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAZgAAAAAMAAAAAAAAACAAAAAgAAAAAAA AAAAAAGYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAABmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAA AAAAAZgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAAGYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAA AAABmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAZgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAA AAGYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAABmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAA AZgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAAGYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAB mAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAZgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAAGY AAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAABmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAZgA AAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAAGYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAABABmAAA AAAwAAAAAAAAAIAAAACAAAAAAAAAAAAQAZgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAEAGYAAAA ADAAAAAAAAAAgAAAAIAAAAAAAAAAAAgBmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAQAZgAAAAA MAAAAAAAAACAAAAAgAAAAAAAAAAACAGYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAABABmAAAAAAw AAAAAAAAAIAAAACAAAAAAAAAAAAAAZgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAAGYAAAAADAA AAAAAAAAgAAAAIAAAAAAAAAAAAABmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAZgAAAAAMAAA AAAAAACAAAAAgAAAAAAAAAAAAAGYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAABABmAAAAAAwAAAA AAAAAIAAAACAAAAAAAAAAAAQAZgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAAGYAAAAADAAAAAA AAAAgAAAAIAAAAAAAAAAAAABmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAZgAAAAAMAAAAAAA AACAAAAAgAAAAAAAAAAAAAGYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAABABmAAAAAAwAAAAAAAA AIAAAACAAAAAAAAAAAAAAZgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAAGYAAAAADAAAAAAAAAA gAAAAIAAAAAAAAAAAAABmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAZgAAAAAMAAAAAAAAACA AAAAgAAAAAAAAAAAAAGYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAABmAAAAAAwAAAAAAAAAIAA AACAAAAAAAAAAAAAAZgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAAGYAAAAADAAAAAAAAAAgAAA AIAAAAAAAAAAABABmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAQAZgAAAAAMAAAAAAAAACAAAAA gAAAAAAAAAAAEAGYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAABABmAAAAAAwAAAAAAAAAIAAAACA AAAAAAAAAAAQAZgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAEAGYAAAAADAAAAAAAAAAgAAAAIAA AAAAAAAAABABmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAQAZgAAAAAMAAAAAAAAACAAAAAgAAA AAAAAAAAEAGYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAABmAAAAAAwAAAAAAAAAIAAAACAAAAA AAAAAAAAAZgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAAGYAAAAADAAAAAAAAAAgAAAAIAAAAAA AAAAAAABmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAZgAAAAAMAAAAAAAAACAAAAAgAAAAAAA AAAAAAGYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAABmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAA AAAAAZgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAAGYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAA AAABmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAZgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAA AAGYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAABmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAA AZgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAAGYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAB mAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAZgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAAGY AAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAABmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAZgA AAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAEAGYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAABmAAA AAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAZgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAAGYAAAA ADAAAAAAAAAAgAAAAIAAAAAAAAAAAAABmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAZgAAAAA MAAAAAAAAACAAAAAgAAAAAAAAAAAAAGYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAABmAAAAAAw AAAAAAAAAIAAAACAAAAAAAAAAAAAAZgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAAGYAAAAADAA AAAAAAAAgAAAAIAAAAAAAAAAAAABmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAZgAAAAAMAAA AAAAAACAAAAAgAAAAAAAAAAAAAGYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAABmAAAAAAwAAAA AAAAAIAAAACAAAAAAAAAAAAAAZgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAAGYAAAAADAAAAAA AAAAgAAAAIAAAAAAAAAAAAABmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAZgAAAAAMAAAAAAA AACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAA AIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAA gAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACA AAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAA AACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAA AIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAA gAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACA AAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAA AAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAA AAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAA AAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAA AAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAA AAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAABAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAA AAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAA AAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAA AACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAA AJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAA mAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACY AAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgA AAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAA AAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAA ADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAA MAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAw AAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAA AAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAA AAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAA AAAAAIAAAACAAAAAAAAAAAAQAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAEACYAAAAADAAAAAA AAAAgAAAAIAAAAAAAAAAABAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAQAJgAAAAAMAAAAAAA AACAAAAAgAAAAAAAAAAAEACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAABAAmAAAAAAwAAAAAAAA AIAAAACAAAAAAAAAAAAQAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAEACYAAAAADAAAAAAAAAA gAAAAIAAAAAAAAAAABAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACA AAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAA AACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAA AIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAA gAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACA AAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAA AAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAA AAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAA AAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAA AAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAA AAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAA AAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAA AAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAA AACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAA AZgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAAGYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAB mAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAZgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAAGY AAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAABmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAZgA AAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAAGYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAABmAAA AAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAZgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAAGYAAAA ADAAAAAAAAAAgAAAAIAAAAAAAAAAAAABmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAZgAAAAA MAAAAAAAAACAAAAAgAAAAAAAAAAAAAGYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAABmAAAAAAw AAAAAAAAAIAAAACAAAAAAAAAAAAAAZgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAAGYAAAAADAA AAAAAAAAgAAAAIAAAAAAAAAAAAABmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAZgAAAAAMAAA AAAAAACAAAAAgAAAAAAAAAAAAAGYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAABmAAAAAAwAAAA AAAAAIAAAACAAAAAAAAAAAAAAZgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAAGYAAAAADAAAAAA AAAAgAAAAIAAAAAAAAAAAAABmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAZgAAAAAMAAAAAAA AACAAAAAgAAAAAAAAAAAAAGYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAABmAAAAAAwAAAAAAAA AIAAAACAAAAAAAAAAAAAAZgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAAGYAAAAADAAAAAAAAAA gAAAAIAAAAAAAAAAAAABmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAZgAAAAAMAAAAAAAAACA AAAAgAAAAAAAAAAAAAGYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAABmAAAAAAwAAAAAAAAAIAA AACAAAAAAAAAAAAAAZgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAA AIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAA gAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACA AAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAA AAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAA AAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAA AAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAA AAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAA AAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAA AAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAA AAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAA AACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAA AJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAA mAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJpAAAARMAAAAAAAAACAAAAAgAAAAKAAAAAAAASY QAEgETAAAAAAAAAAgAAAAIAAAACgAAAAAAAEmEABIBEwAQAAAAAAAIAAAACAAAAAoAAAAAAABJhA AAARMAAAAAAAAACAAAAAgAAAAKAAAAAAAAWYQAAAETAAAAAAAAAAgAAAAIAAAACgAAAAAAAFCgAA AAAwAAAAAAAAAAAAAAAABjBtAQAAAAAABwAAAAD8AwAAKAQAAGkEAACKBAAAIS4AAFkuAAB0LgAA ii4AAKUuAADkLgAAKy8AAD8vAABcLwAAfS8AAMAvAABWMAAAljAAANkwAADuMAAA7zAAAP8wAAA6 MgAAczIAAKcyAADfMgAA4DIAAOoyAADBNQAAATYAADo2AABjNgAAZDYAAK42AADlOgAAIjsAAGM7 AACMOwAAyTsAAOQ7AAD+OwAAOjwAAHs8AAC9PAAA5DwAAOU8AAAnPQAAnKwAAOKsAAAhrQAAY60A AKStAAC+rQAAScMAAIvDAACywwAA+MMAAD/EAABexAAApMQAAMfEAADrxAAAD8UAACPFAABTxQAA mMUAANfFAAAbxgAAWMYAAG7GAACzxgAA2MYAABzHAABJxwAAhscAAMLHAAD8xwAAAskAAETJAACG yQAAyckAABDKAABXygAA6coAADHLAAB0ywAAucsAAAXMAAA9zAAAP8wAAEDMAAD1zwAAI9AAAGTQ AACb0AAA09AAAA7RAAA12QAAY9kAAKTZAADF2QAA89kAADHaAAB+3gAAwN4AAAPfAAAj3wAAS98A AJTfAADY3wAAIOAAAGfgAACx4AAA+OAAABvhAAAc4QAAL+EAAD/hAABb4QAAmeEAAMzhAADq4QAA Ye0AAJHtAADW7QAANO4AADXuAADO7gAA0e4AAEnIADAAMAAAAAAAAAEAAAAJAAAAAQAAACiiewdJ yAAwADAAAAAAAAABAAAACAAAAAAAAAAAAAAHScgAMAAwAAAAAAAAAgAAAAYAAAAAAAAAAAAAB0nI ADAAMAAAAAAAAAEAAAADAAAAAAAAAAAAAAdJiAAwBDAAAAAAAAABAAAAJwAAAAUAAAB8tXUHSYgA MAQwAAAAAAAAAQAAACYAAAAAAAAAAAAAB0mIADAEMAAAAAAAAAIAAAAkAAAAAAAAAAAAAAdJiAAw BDAAAAAAAAABAAAAIAAAAAAAAAAAAAAHSYgAMAQwAAAAAAAAAQAAACEAAAAAAAAAAAAQB0mIADAE MAAAAAAAAAEAAAAhAAAAAAAAAAAAAAdJiAAwBDAAAAAAAAABAAAAIQAAAAAAAAAAABAHSYgAMAQw AAAAAAAAAQAAACEAAAAAAAAAAAAQB0nIADAEMAAAAAAAAAEAAAAhAAAAAAAAAAAAEAdJiAAwBDAA AAAAAAABAAAAIQAAAAAAAAAAABAHSYgAMAQwAAAAAAAAAQAAACEAAAAAAAAAAAAAB0mIADAPMAAA AAAAAAEAAAAnAAAAEAAAAPTIdAdJiAAwDzAAAAAAAAABAAAAJgAAAAAAAAAAAAAHSYgAMA8wAAAA AAAAAgAAACQAAAAAAAAAAAAAB0mIADAEMAAAAAAAAAEAAAAgAAAAAAAAAAAAAAdJiAAwBDAAAAAA AAABAAAAIQAAAAAAAAAAABAHSYgAMAQwAAAAAAAAAQAAACEAAAAAAAAAAAAAB0mIADAVMAAAAAAA AAEAAAAnAAAAFgAAAEB4dAdJiAAwFTAAAAAAAAABAAAAJgAAAAAAAAAAAAAHSYgAMBUwAAAAAAAA AgAAACQAAAAAAAAAAAAAB0mIADAEMAAAAAAAAAEAAAAgAAAAAAAAAAAAAAdJiAAwBDAAAAAAAAAB AAAAIQAAAAAAAAAAABAHSYgAMAQwAAAAAAAAAQAAACEAAAAAAAAAAAAAB0mIADAbMAAAAAAAAAEA AAAnAAAAHAAAAOh4dAdJiAAwGzAAAAAAAAABAAAAJgAAAAAAAAAAAAAHSYgAMBswAAAAAAAAAgAA ACQAAAAAAAAAAAAAB0mIADAEMAAAAAAAAAEAAAAgAAAAAAAAAAAAAAdJiAAwBDAAAAAAAAABAAAA IQAAAAAAAAAAABAHSYgAMAQwAAAAAAAAAQAAACEAAAAAAAAAAAAAB0mIADAhMAAAAAAAAAEAAAAt AAAAIgAAAGzLdAdJiAAwITAAAAAAAAABAAAALAAAAAAAAAAAAAAHSYgAMCEwAAAAAAAAAgAAACoA AAAAAAAAAAAAB0mIADAhMAAAAAAAAAEAAAAmAAAAAAAAAAAAAAdJiAAwITAAAAAAAAABAAAAJwAA AAAAAAAAABAHSYgAMCEwAAAAAAAAAQAAACcAAAAAAAAAAAAIB0mIADAhMAAAAAAAAAEAAAAnAAAA AAAAAAAAAAdJiAAwITAAAAAAAAABAAAAJwAAACIAAABsy3QHSYgAMCEwAAAAAAAAAQAAACYAAAAA AAAAAAAAB0mIADAhMAAAAAAAAAIAAAAkAAAAAAAAAAAAAAdJiAAwBDAAAAAAAAABAAAAIAAAAAAA AAAAAAAHSYgAMAQwAAAAAAAAAQAAACEAAAAAAAAAAAAQB0mIADAEMAAAAAAAAAEAAAAhAAAAAAAA AAAAAAdJiAAwLjAAAAAAAAABAAAAMQAAAC8AAAB0nG0HSYgAMC4wAAAAAAAAAQAAADAAAAAAAAAA AAAAB0mIADAuMAAAAAAAAAIAAAAuAAAAAAAAAAAAAAdJiAAwBDAAAAAAAAABAAAAIAAAAAAAAAAA AAAHSYgAMAQwAAAAAAAAAQAAACEAAAAAAAAAAAAQB0mIADAEMAAAAAAAAAEAAAAhAAAAAAAAAAAA AAdJiAAwBDAAAAAAAAABAAAAIQAAAAUAAACUl3UHSYgAMAQwAAAAAAAAAQAAACAAAAAAAAAAAAAA B0mIADAEMAAAAAAAAAEAAAAfAAAAAAAAAAAAAAdJiAAwBDAAAAAAAAABAAAABQAAAAAAAAAAAAAH SYgAMAQwAAAAAAAAAQAAAAQAAAAAAAAAAAAQB0mIADAEMAAAAAAAAAEAAAAEAAAAAAAAAAAAEAdJ iAAwBDAAAAAAAAABAAAABAAAAAAAAAAAABAHSYgAMAQwAAAAAAAAAQAAAAQAAAAAAAAAAAAIB0mI ADAEMAAAAAAAAAIAAAACAAAAAAAAAAAAEAdJiAAwBDAAAAAAAAACAAAAAgAAAAAAAAAAAAgHSYgA MAAwAAAAAAAAAQAAAAAAAAAAAAAAAAAQB0mIADAAMAAAAAAAAAEAAAAAAAAAAAAAAAAAAAdJyAAw ADAAAAAAAAABAAAABAAAAAAAAAAAAAAHSYgAMDswAAAAAAAAAQAAABwAAAAAAAAAAAAAB0mIADA7 MAAAAAAAAAIAAAAaAAAAAAAAAAAAAAdJiAAwCTAAAAAAAAABAAAABAAAAAAAAAAAAAAHSYgAMAkw AAAAAAAAAQAAAAUAAAAAAAAAAAAQB0mIADAJMAAAAAAAAAEAAAAFAAAAAAAAAAAAEAdJiAAwCTAA AAAAAAABAAAABQAAAAAAAAAAAAAHSYgAMAkwAAAAAAAAAQAAAAQAAAAAAAAAAAAAB0mIADAJMAAA AAAAAAIAAAACAAAAAAAAAAAAAAdJiAAwADAAAAAAAAABAAAAAAAAAAAAAAAAAAAHScgAMAAwAAAA AAAAAQAAAAQAAAAAAAAAAAAQB0nIADAAMAAAAAAAAAEAAAAEAAAAAAAAAAAAAAdJiAAwDzAAAAAA AAABAAAABQAAABAAAABMc3sHSYgAMA8wAAAAAAAAAQAAAAQAAAAAAAAAAAAAB0mIADAPMAAAAAAA AAIAAAACAAAAAAAAAAAAAAdJiAAwADAAAAAAAAABAAAAAAAAAAAAAAAAAAAHScgAMAAwAAAAAAAA AQAAAAQAAAAAAAAAAAAQB0nIADAAMAAAAAAAAAEAAAAAAAAAAAAAAAAAEAdJiAAwFTAAAAAAAAAC AAAAAwAAAAAAAAAAABAHSYgAMBUwAAAAAAAAAgAAAAMAAAAAAAAAAAAQB0mIADAVMAAAAAAAAAIA AAADAAAAAAAAAAAAEAdJiAAwFTAAAAAAAAACAAAAAwAAAAAAAAAAABAHSYgAMBUwAAAAAAAAAgAA AAMAAAAAAAAAAAAQB0mIADAVMAAAAAAAAAIAAAADAAAAAAAAAAAAEAdJyAAwADAAAAAAAAABAAAA BAAAAAAAAAAAABAHScgAMAAwAAAAAAAAAQAAAAQAAAAAAAAAAAAAB0mIADBUMAAAAAAAAAEAAAAF AAAAVQAAAJygbQdJiAAwVDAAAAAAAAABAAAABAAAAAAAAAAAAAAHSYgAMFQwAAAAAAAAAgAAAAIA AAAAAAAAAAAAB0mIADAAMAAAAAAAAAEAAAAAAAAAAAAAAAAAAAdJyAAwADAAAAAAAAABAAAABAAA AAAAAAAAABAHScgAMAAwAAAAAAAAAQAAAAQAAAAAAAAAAAAAB0mIADBgMAAAAAAAAAEAAAAFAAAA YQAAAOyhbQdJiAAwYDAAAAAAAAABAAAABAAAAAAAAAAAAAAHSYgAMGAwAAAAAAAAAgAAAAIAAAAA AAAAAAAAB0mIADAAMAAAAAAAAAEAAAAAAAAAAAAAAAAAAAdJyAAwADAAAAAAAAABAAAABAAAAAAA AAAAABAHScgAMAAwAAAAAAAAAQAAAAQAAAAAAAAAAAAAB0mIADBmMAAAAAAAAAEAAAAFAAAAZwAA AJSibQdJiAAwZjAAAAAAAAABAAAABAAAAAAAAAAAAAAHSYgAMGYwAAAAAAAAAgAAAAIAAAAAAAAA AAAAAUmIADAAMAAAAAAAAAEAAAAAAAAAAAAAAAAAAAFJyAAwADAAAAAAAAABAAAABAAAAAAAAAAA ABABSYgAMGsQAAAAAAAAAQAAAAsAAAAAAAAAAAAQAUmIADBrMAAAAAAAAAEAAAAHAAAAAAAAAAAA EAFJiAAwazAAAAAAAAABAAAABgAAAAAAAAAAABABSYgAMGswAAAAAAAAAgAAAAQAAAAAAAAAAAAQ AUmIADBrMAAAAAAAAAIAAAAEAAAAAAAAAAAAEAFJyAAwADAAAAAAAAABAAAABAAAAAAAAAAAABAB ScgAMAAwAAAAAAAAAQAAAAQAAAAAAAAAAAAQAUnIADAAMAAAAAAAAAEAAAAEAAAAAAAAAAAAEAFJ yAAwADAAAAAAAAABAAAABAAAAAAAAAAAAAABScgAMAAwAAAAAAAAAQAAAAQAAAAAAAAAAAAAAUnI ADAAMAAAAAAAAAEAAAAEAAAAAAAAAAAAAAFJiAAwdgAAAAAAAAABAAAABAAAAAAAAAAAAAABSYgA MHYAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAUmIADAAMAAAAAAAAAEAAAAAAAAAAAAAAAAAAAdJyAAw ADAAAAAAAAABAAAABAAAAAEAAAAoonsHmEAAABEwAAAAAAAAAIAAAACAAAAAAAAAAAAAB5hAASAR MAAAAAAAAACAAAAAgAAAAAAAAAAAAAeYQAEgETABAAAAAAAAgAAAAIAAAAAAAAAAAAAHmEABIBEw AgAAAAAAAIAAAACAAAAAAAAAAAAAB5hAASARMAIAAAAAAACAAAAAgAAAAAAAAAAAAAcIAAAAADAA AAAAAAAAAAAAAAAGMG0BAAAAAAAHAAYAAOQ2AADjQwAAOMwAALbMAABzzQAAxM8AAE3SAAC40wAA 09gAACbnAAB+6AAAQ+sAAND2AAB8AAAAhwAAAIwAAACkAAAApQAAAKcAAACpAAAAqwAAAK4AAACx AAAAtQAAALcAAAC6AAAAAAYAAMULAAAuEQAAnxcAAMUeAAAxJQAAgisAAJQyAAB0NQAAKzcAAO44 AACjPAAAb0AAAP5DAAD1RwAAfE0AAMBTAADLWQAA818AAABmAACdawAAwnEAAOt3AAB4fgAAiYUA AC2MAAD6kgAA45kAAKugAABFpwAAha0AAFe0AADEuAAAM78AANfFAAD4ywAAD80AALPOAAAC0QAA 6dIAAHTTAAA91AAADNYAAJTaAACh4AAA3eMAAJTnAAAb6QAA9ukAANXuAAAa8wAA1vUAAND2AAB9 AAAAfwAAAIAAAACBAAAAggAAAIMAAACEAAAAhQAAAIYAAACIAAAAiQAAAIoAAACLAAAAjQAAAI4A AACPAAAAkAAAAJEAAACSAAAAkwAAAJQAAACVAAAAlgAAAJcAAACYAAAAmQAAAJoAAACbAAAAnAAA AJ0AAACeAAAAnwAAAKAAAAChAAAAogAAAKMAAACmAAAAqAAAAKoAAACsAAAArQAAAK8AAACwAAAA sgAAALMAAAC0AAAAtgAAALgAAAC5AAAAuwAAALwAAAC9AAAAAAYAAM/2AAB+AAAADwAA8DgAAAAA AAbwGAAAAAIIAAACAAAAAQAAAAEAAAABAAAAAgAAAEAAHvEQAAAA//8AAAAA/wCAgIAA9wAAEAAP AALwkgAAABAACPAIAAAAAQAAAAEEAAAPAAPwMAAAAA8ABPAoAAAAAQAJ8BAAAAAAAAAAAAAAAAAA AAAAAAAAAgAK8AgAAAAABAAABQAAAA8ABPBCAAAAEgAK8AgAAAABBAAAAA4AAFMAC/AeAAAAvwEA ABAAywEAAAAA/wEAAAgABAMJAAAAPwMBAAEAAAAR8AQAAAABAAAA//8BAAoAAAAAAd+QnA3///// ayoAAGPtAAAAAAAAkSoAAGPtAAAAAAAARwAAAEsAAACRAAAAlAAAALkAAAC/AAAAxQAAAMkAAADN AAAA0QAAAOYAAADxAAAA8gAAAPgAAAD5AAAA/gAAAOQBAADnAQAA7wEAAPIBAAAoAwAAMQMAANoE AADbBAAAUgUAAFUFAAB7CAAAtqkAAGurAABuqwAAgqsAAIarAAAOrAAAGqwAAKStAACmrQAAp60A AKutAACsrQAAta0AAAivAAALrwAAOa8AAE2vAABTrwAAVq8AAJ6vAAChrwAAALYAAAm2AAAftgAA L7YAAD+3AABTtwAA8bcAAAG4AAB5uAAAfLgAAA66AAARugAAn7oAAKK6AABYuwAAW7sAAAi8AAAc vAAAYbwAAGS8AACLvQAAj70AAPG9AAD0vQAAesMAAH3DAACRxAAAmcQAAEvHAABUxwAAxMcAAMvH AABiygAAaMoAANXQAADc0AAAOdQAAEDUAAAr2gAAMNoAAKLbAACl2wAAv9sAAMbbAAAc3QAAH90A AF7dAABh3QAArN0AALDdAADh3QAA5d0AAEHgAABK4AAAZeEAAGzhAACI4QAAjOEAAK7hAACx4QAA tuEAALnhAAAB4gAAB+IAACDjAABB4wAAQ+MAAEvjAABR4wAAVeMAAGvjAAB04wAAEeQAAC7kAAAw 5AAANeQAAM7kAADs5AAA/OQAAAPlAAAJ5QAADuUAABvlAAAi5QAAsuUAALjlAADL5QAA0uUAAEvm AABp5gAAa+YAAHHmAAB35gAAf+YAAJHmAACY5gAAnuYAAKfmAACt5gAAt+YAAMTmAADM5gAA1eYA ANnmAABd5wAAcecAAA/oAAAV6AAAfegAAILoAADw6AAAYe0AAMTuAADM7gAA0e4AAAcAHAAHABwA BwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHAAMABwAcAAcAHAAH ABwABwADAAcAAwAHAAMABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcA HAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHAAMABwAc AAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwA BwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAH ABwABwAcAAcAHAAHABwABwAcAAcAHAAHAAMABwADAAcAAAAAACkAAABVAQAAegEAANYBAADgAQAA OQIAAG4CAAB5AgAAfgIAALkCAADAAgAABwMAAAoDAABMAwAAUAMAAIoDAACSAwAADwUAABcFAADa BQAA5QUAABYGAAAfBgAAXAYAAF4GAAC6BgAAvwYAAPwGAAAABwAAOwcAAEYHAAB/BwAAhAcAAL0H AADGBwAA9wcAAAYIAAA8CAAASwgAAHwIAACDCAAALgkAADYJAACKFgAAxBYAAM8WAADQFgAARhcA AEsXAABuFwAAbxcAAKEXAACmFwAAJBgAACoYAABnGAAAaxgAAK0YAACyGAAA8RgAAPgYAAA0GQAA OBkAAHUZAAB5GQAAtRkAALoZAAD1GQAA/BkAAHwaAACBGgAAwRoAAMQaAAAFGwAACRsAAEkbAABT GwAAjRsAAJAbAADNGwAA0xsAACccAAAuHAAAaBwAAHAcAACrHAAAsxwAAOscAADxHAAAMR0AADMd AAB0HQAAdx0AAPAdAAD4HQAAMh4AADkeAAB1HgAAfB4AALQeAADPHgAA+B4AAP0eAAA7HwAARB8A AHgfAACFHwAA/R8AAAIgAABwIAAAdyAAALUgAAC6IAAA+CAAAPogAAA5IQAAQiEAAHkhAACBIQAA uiEAAL8hAAD0IQAAASIAADciAAA8IgAAeSIAAH0iAAD+IgAABSMAAEIjAABFIwAAgiMAAJAjAADH IwAAyCMAAE0kAABUJAAAjiQAAJIkAADRJAAA3iQAABclAAAcJQAAXSUAAGIlAACgJQAAoiUAAOMl AADtJQAAHyYAACkmAABhJgAAaiYAAJ4mAACnJgAA4SYAAOUmAAAgJwAAKScAAGInAABqJwAAqCcA ALAnAADGJwAAyycAAPwnAAAEKAAAhSgAAIwoAADIKAAAzigAAA4pAAATKQAAUikAAFYpAACXKQAA mSkAANYpAADeKQAAGCoAAB8qAABbKgAAXioAAPIqAAD0KgAASysAAE0rAABrKwAAdSsAAIUrAACI KwAAkCsAAJIrAADcKwAA3ysAAI4sAACPLAAAuCwAALosAAA8LQAAPS0AAHYtAACDLQAApS0AAKkt AADfLQAA5S0AAOotAADuLQAAIS4AACsuAABZLgAAWi4AAHYuAAB+LgAAjC4AAJouAACnLgAAqy4A ACsvAAAwLwAAQS8AAE0vAABeLwAAai8AAMAvAADELwAAVjAAAF0wAACWMAAAnTAAANkwAADcMAAA PjEAAEAxAAB9MQAAhzEAAPoxAAABMgAAOjIAAEIyAABzMgAAfTIAAKcyAACzMgAAKDMAAC8zAABo MwAAajMAAKgzAACuMwAA5zMAAPAzAAAnNAAAKjQAAGY0AABqNAAAozQAAKY0AAADNQAADTUAAEM1 AABGNQAAgTUAAIY1AADBNQAAxDUAAAE2AAAENgAAOjYAAEM2AACuNgAAsDYAAOU2AADsNgAAKzcA ADc3AABsNwAAczcAAK43AAC1NwAA7TcAAPQ3AAAsOAAAMzgAAG84AABxOAAAtDgAALc4AAD5OAAA +zgAAD45AABCOQAAgTkAAIk5AADTOQAA2DkAAAc6AAAIOgAARzoAAFE6AACIOgAAizoAAI06AACO OgAAzzoAANY6AADlOgAA5joAACI7AAAuOwAAYzsAAGU7AACMOwAAjTsAAMk7AADPOwAA5TsAAPE7 AAD+OwAA/zsAADo8AABDPAAAezwAAIY8AAC9PAAAwjwAACc9AAAsPQAAZz0AAG89AACpPQAArT0A AOw9AADuPQAA9j4AAAI/AAA8PwAAPz8AAPU/AAD9PwAANUAAADlAAABzQAAAeUAAALBAAAC3QAAA KkEAADBBAACgQQAAp0EAAOFBAADuQQAAF0IAAB9CAABUQgAAXEIAAJNCAACdQgAA70IAAPtCAAAu QwAANUMAAG5DAAB7QwAABEQAAAxEAAA/RAAARkQAAHxEAAB/RAAAuUQAAMFEAAA+RQAAREUAAHxF AACBRQAAtkUAALtFAADzRQAA+UUAAHBGAAB3RgAArkYAALBGAADmRgAA7kYAACVHAAAsRwAAY0cA AGpHAAD6RwAA/UcAAB1IAAAgSAAAOEgAAERIAAB4SAAAgEgAALRIAAC7SAAA8UgAAPRIAAAwSQAA M0kAALFJAAC7SQAAOEoAADtKAAB6SgAAfkoAALpKAADESgAA/EoAAABLAABCSwAASUsAAIZLAACO SwAAGkwAAB9MAABgTAAAY0wAAKBMAACpTAAA4kwAAOxMAAAkTQAAKE0AAGlNAABrTQAArk0AALVN AADyTQAA+k0AAHZOAAB9TgAAuk4AAMBOAAD7TgAAA08AAEFPAABETwAAg08AAIpPAADATwAAzE8A AAVQAAAOUAAAi1AAAJJQAAAoUQAAM1EAAGlRAABxUQAAy1EAANJRAAAKUgAAF1IAAE9SAABUUgAA k1IAAJpSAADQUgAA21IAAClTAAAwUwAAblMAAG9TAACFUwAAhlMAAJFTAACSUwAAKFQAAC9UAACu VAAAslQAAO5UAAD1VAAAM1UAADhVAABzVQAAeVUAALhVAAC7VQAA/lUAAAFWAAB2VgAAfVYAALZW AAC/VgAAzlYAAM9WAADsVgAA7VYAAC5XAAA0VwAArVcAALVXAADzVwAAAFgAAH5YAACEWAAALVkA AC9ZAABxWQAAdFkAAPZZAAACWgAANVoAAEBaAABuWgAAeloAALFaAAC+WgAA8VoAAPlaAAA0WwAA PlsAAINbAACKWwAAi1sAAIxbAADEWwAAxVsAAOJbAADjWwAAaVwAAHVcAACqXAAAs1wAADNdAAA7 XQAAeV0AAIJdAAC+XQAAx10AAABeAAAGXgAARF4AAExeAACJXgAAjF4AAM5eAADRXgAAEl8AABhf AAAvXwAAMF8AAFVfAABWXwAA2V8AAOJfAAAfYAAAJ2AAAGNgAABtYAAA42AAAOhgAAApYQAAK2EA AGhhAABzYQAAw2EAAMthAADUYQAA1WEAAPJhAADzYQAAGmIAABtiAACeYgAApWIAAOFiAADkYgAA JGMAACtjAABiYwAAa2MAANtjAADlYwAA7mMAAO9jAAAOZAAAD2QAACJkAAAjZAAAomQAAKhkAADm ZAAA6WQAAGdlAABuZQAA62UAAPJlAAAtZgAANGYAAHJmAAB8ZgAAtGYAALtmAAD6ZgAAAmcAADVn AABAZwAAtGcAALtnAAD6ZwAA/GcAADpoAABAaAAAeWgAAIJoAAC5aAAAw2gAAPtoAAD/aAAAPGkA AEVpAAB+aQAAimkAAMJpAADFaQAANmoAAEBqAAB1agAAfGoAAPdqAAD+agAANGsAAD9rAACzawAA vGsAAPNrAAD6awAACGwAAAlsAAAubAAAL2wAAFRsAABVbAAAfGwAAH1sAADmbAAA6WwAACltAAAs bQAAbm0AAHFtAACtbQAAuG0AAChuAAAxbgAAbm4AAHJuAAAfbwAAKm8AAGNvAABsbwAAqG8AAK5v AADrbwAA9m8AADFwAAA4cAAAd3AAAH5wAAC8cAAAxXAAAFVxAABXcQAAlXEAAJ1xAADacQAA3HEA AEhyAABScgAAjHIAAJlyAADLcgAA0nIAAAxzAAARcwAATnMAAFhzAADIcwAAy3MAAA10AAARdAAA SXQAAFh0AACGdAAAk3QAAMZ0AADNdAAAA3UAAAx1AABYdQAAYXUAAJx1AACfdQAA4HUAAOJ1AAB4 dgAAf3YAAL12AADEdgAA/3YAAAd3AABCdwAASncAAIV3AACSdwAAy3cAAM13AAALeAAAFngAAHV4 AAB/eAAAtXgAAMJ4AAD6eAAAAXkAAEB5AABCeQAAg3kAAIV5AADHeQAAynkAAAl6AAAMegAASnoA AFF6AACPegAAlnoAANJ6AADWegAAEXsAABt7AACMewAAjnsAAMd7AADTewAABHwAAA98AABDfAAA SXwAAIN8AACOfAAABX0AAAt9AABEfQAAS30AAIl9AACNfQAAzn0AANh9AAAQfgAAFH4AAFZ+AABY fgAAmn4AAJx+AADRfgAA4H4AABZ/AAAafwAAWX8AAGF/AACRfwAAoH8AANN/AADafwAANIAAAEOA AAB4gAAAg4AAALmAAAC/gAAARYEAAFSBAACLgQAAjYEAAMyBAADVgQAAEIIAABeCAABRggAAWIIA AJGCAACYggAA1IIAANuCAAAYgwAAGoMAAFyDAABqgwAAoIMAAKiDAADigwAA8YMAACOEAAArhAAA b4QAAHaEAAC0hAAAv4QAAPKEAAD5hAAAOIUAADyFAAB4hQAAfoUAALWFAAC9hQAA+IUAAACGAAA1 hgAAPYYAAHqGAACDhgAAv4YAAMaGAAA8hwAAQ4cAAH2HAACEhwAAw4cAAMyHAAAFiAAAEogAAEuI AABNiAAAyYgAANSIAAAJiQAAE4kAAEmJAABRiQAA9IkAAPqJAAA5igAAQIoAAHqKAACAigAAuYoA AMGKAAA+iwAARIsAAIOLAACJiwAAw4sAAM6LAAAHjAAAD4wAAGuMAAB3jAAAsIwAALqMAAD1jAAA 94wAADKNAAA7jQAAeI0AAH6NAAC5jQAAw40AAPyNAAAGjgAAPo4AAEaOAACZjgAAnY4AANyOAADh jgAAaI8AAG+PAACsjwAAr48AADKQAAA6kAAAcpAAAHmQAAC0kAAAv5AAACWRAAAokQAAYZEAAGuR AAClkQAAp5EAAOORAADskQAAKZIAADCSAABukgAAeJIAALGSAAC2kgAA9ZIAAPuSAAA2kwAAPpMA AJ6TAAChkwAA5JMAAOmTAABulAAAdpQAALOUAAC1lAAA+ZQAAP+UAAA7lQAAQZUAAH2VAACFlQAA upUAAMSVAAALlgAAFZYAAE6WAABRlgAAkJYAAJiWAADRlgAA2JYAABWXAAAalwAAV5cAAF6XAACW lwAAn5cAANuXAADilwAAHZgAACCYAABgmAAAY5gAAKOYAACpmAAA65gAAPaYAAApmQAAM5kAAGuZ AABxmQAArpkAALGZAAD0mQAA+JkAADeaAAA+mgAAvZoAAMKaAABKmwAAT5sAAI+bAACXmwAAzZsA ANWbAAAOnAAAEpwAAE2cAABWnAAAzZwAANScAAASnQAAGZ0AAFGdAABXnQAAkZ0AAJmdAADVnQAA 250AABKeAAAangAAf54AAIueAAC+ngAAxJ4AAAGfAAAEnwAARZ8AAE6fAACHnwAAjp8AAMyfAADO nwAAEaAAABSgAABSoAAAWaAAAPGgAAD8oAAANqEAADqhAAB7oQAAf6EAAMGhAADMoQAABKIAAA6i AABRogAAWaIAAJSiAACaogAA/KIAAP2iAAAjowAAJKMAAGejAABrowAAbaMAAG6jAAAdpAAAJaQA AGKkAABnpAAApaQAAKikAAAZpQAAGqUAAE2lAABOpQAA/qUAAASmAAA8pgAAQ6YAAHymAACDpgAA waYAAMimAAAnpwAALacAAGmnAABypwAAqKcAALCnAAAwqAAAOKgAAHOoAAB5qAAAtKgAALioAAD0 qAAA+qgAADapAAA7qQAAdakAAIKpAAC2qQAAv6kAAFiqAABeqgAAZKoAAIKqAACbqgAAnaoAAN2q AADlqgAAIKsAACarAABmqwAAaKsAAKmrAACtqwAA7qsAAPWrAABarAAAYawAAJysAAClrAAA4qwA AOusAAAerQAAIK0AACGtAAAorQAAY60AAGitAAC+rQAAxq0AAAKuAAAErgAAQq4AAE6uAACHrgAA ia4AAMGuAADdrgAANa8AADevAABgrwAAZ68AAOOvAADsrwAAJbAAADGwAACAsAAAhLAAAMSwAADK sAAABbEAAAyxAACGsQAAkbEAAAeyAAAMsgAASrIAAEyyAACOsgAAlbIAAM2yAADYsgAADrMAABSz AABQswAAWLMAAJSzAACZswAA1LMAANuzAAAUtAAAHLQAAMO0AADLtAAABrUAAA+1AABKtQAATbUA ALO1AAC6tQAAybUAAMq1AADxtQAA8rUAABO2AAAUtgAAc7YAAHe2AACytgAAu7YAAPC2AAD5tgAA M7cAADi3AAB3twAAf7cAAAK4AAAEuAAANLgAAD24AAC4uAAAxbgAAP24AAD/uAAAP7kAAEO5AACA uQAAh7kAAMS5AADIuQAAHroAACa6AABiugAAa7oAAKO6AACrugAA5LoAAOm6AAAmuwAALbsAAGW7 AABruwAAqbsAALO7AADouwAA77sAAIW8AACOvAAAybwAAM68AAAKvQAAEb0AAE69AABUvQAAm70A AJ69AADXvQAA4L0AABi+AAAgvgAARr4AAFK+AABTvgAAX74AAIm+AACKvgAAzb4AANa+AADYvgAA 2b4AABi/AAAhvwAAK78AACy/AABkvwAAcL8AAL+/AADMvwAA4L8AAOG/AAAlwAAAJsAAAGPAAABk wAAA28AAAOHAAAAdwQAAJcEAAGDBAABkwQAAocEAAKrBAADjwQAA6MEAACnCAAAxwgAAbsIAAHbC AACswgAAs8IAAO7CAADywgAAi8MAAJLDAAD4wwAA+8MAAD/EAABCxAAApMQAAKzEAADHxAAAysQA AOvEAADzxAAAD8UAABHFAABTxQAAVcUAAJjFAACfxQAA18UAAOLFAAAbxgAAJMYAAFjGAABhxgAA fsYAAILGAACzxgAAtcYAABzHAAAexwAASccAAErHAACGxwAAh8cAAMLHAADDxwAAQsgAAEPIAACE yAAAisgAAMjIAADMyAAA+MgAAAHJAAACyQAADckAAETJAABOyQAAhskAAIzJAADJyQAAzskAABDK AAATygAAV8oAAFzKAADpygAA8soAADHLAAA5ywAAdMsAAH7LAAC5ywAAwMsAAAXMAAAOzAAAp8wA AK7MAADszAAA8MwAADHNAAA9zQAAgs0AAITNAADHzQAAys0AAAzOAAARzgAATs4AAFPOAACOzgAA ms4AAM3OAADVzgAAEs8AABTPAABUzwAAXM8AANTPAADhzwAA9c8AAPbPAAAj0AAAJNAAAGTQAABl 0AAAm9AAAJzQAADT0AAA1NAAAFPRAABW0QAA1dEAANzRAAAZ0gAAHNIAAFjSAABh0gAAlNIAAKDS AAAJ0wAADNMAAJDTAACb0wAA/NMAAAHUAABC1AAASNQAAILUAACF1AAAwtQAAMnUAAAF1QAACtUA AEbVAABP1QAAidUAAJLVAADL1QAA0NUAAA/WAAAX1gAAjtYAAJfWAADS1gAA2dYAAE7XAABX1wAA lNcAAJ3XAADW1wAA3dcAABzYAAAf2AAAfNgAAH3YAACh2AAAotgAALrYAAC72AAA2NgAANnYAABj 2QAAZNkAAKTZAACl2QAAxdkAAMbZAADz2QAA9NkAAH3aAAB+2gAAptoAAKfaAADA2gAAwdoAAOHa AADi2gAAGNsAABnbAABO2wAAT9sAAN3bAADm2wAAH9wAACLcAABk3AAAZ9wAAMzcAADX3AAADd0A ABjdAABO3QAAWt0AAI3dAACX3QAARt4AAEneAAB+3gAAi94AAMDeAADI3gAAA98AAA/fAACU3wAA nd8AACDgAAAk4AAAZ+AAAGrgAACx4AAAs+AAAPjgAAD+4AAAL+EAADPhAAD24QAAK+IAAOzjAADw 4wAAg+QAAKfkAACW5QAAnuUAAC/mAAA35gAAQOcAAEjnAADo5wAA8OcAAEXoAABL6AAAD+kAABPp AAA36QAAOOkAANvpAADk6QAAYe0AANHuAAAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAH ADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcA MwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAz AAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMA BwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAH ADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcA MwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAz AAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMA BwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAH ADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcA MwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAz AAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMA BwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAH ADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcA MwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAz AAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMA BwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAH ADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcA MwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAz AAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMA BwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAH ADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcA MwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAz AAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMA BwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAH ADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcA MwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAz AAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMA BwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAH ADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcA MwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAz AAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMA BwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAH ADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcA MwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAz AAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMA BwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAH ADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcA MwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAz AAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMA BwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAH ADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcA MwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAz AAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMA BwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAH ADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcA MwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAz AAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMA BwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAH ADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcA MwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAz AAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAHAAAAAABjrQAA vq0AABDKAABXygAAUssAAEDMAACb0AAADtEAAPLZAAAx2gAAS98AABzhAAA04QAAYe0AANHuAAAI AAcACAAHAAgABwAIAAcACAAHAAgABwAFAAgABwABAERax2UeP8IY/w//D/8P/w//D/8P/w//D/8P EAABAAAABAABAAAAAAAAAAAAAAAAAAAAAAADGAAAD4TQAhGEmP4VxgUAAdACBl6E0AJghJj+bygA AgAAACkAAQAAAASAAQAAAAAAAAAAAAAAAAAAAAAAChgAAA+EoAURhJj+FcYFAAGgBQZehKAFYISY /odoAAAAAIhIAAACAAEALgABAAAAAoIBAAAAAAAAAAAAAAAAAAAAAAAKGAAAD4RwCBGETP8VxgUA AXAIBl6EcAhghEz/h2gAAAAAiEgAAAIAAgAuAAEAAAAAgAEAAAAAAAAAAAAAAAAAAAAAAAoYAAAP hEALEYSY/hXGBQABQAsGXoRAC2CEmP6HaAAAAACISAAAAgADAC4AAQAAAASAAQAAAAAAAAAAAAAA AAAAAAAAChgAAA+EEA4RhJj+FcYFAAEQDgZehBAOYISY/odoAAAAAIhIAAACAAQALgABAAAAAoIB AAAAAAAAAAAAAAAAAAAAAAAKGAAAD4TgEBGETP8VxgUAAeAQBl6E4BBghEz/h2gAAAAAiEgAAAIA BQAuAAEAAAAAgAEAAAAAAAAAAAAAAAAAAAAAAAoYAAAPhLATEYSY/hXGBQABsBMGXoSwE2CEmP6H aAAAAACISAAAAgAGAC4AAQAAAASAAQAAAAAAAAAAAAAAAAAAAAAAChgAAA+EgBYRhJj+FcYFAAGA FgZehIAWYISY/odoAAAAAIhIAAACAAcALgABAAAAAoIBAAAAAAAAAAAAAAAAAAAAAAAKGAAAD4RQ GRGETP8VxgUAAVAZBl6EUBlghEz/h2gAAAAAiEgAAAIACAAuAAEAAABEWsdlAAAAAAAAAAAAAAAA ////////AQAAAAAA//8BAAAAEgBasCohGQAIBBsACAQPAAgEGQAIBBsACAQPAAgEGQAIBBsACAQB AAIMxgoAAAAAAAAAAAABAgACAA4AAAAEAAAACAAAAOUAAAAAAAAADQAAAF5TPQBeXj4AGXhUABQU YwARF2QAwHt3AFUlhgBadIsAz2C2AGd/zgB7G+EAKVfhAJwz5ACZefIA/0ADAAEAAAAAACkAAABs ipwHAQABAAAAAAACAAAAAAAAAAAAAAACEAAAAAAAAADQ7gAAgAAAEABAAAD//wIAAAAHAFUAbgBr AG4AbwB3AG4AFgBUAGgAZQBvAGQAbwByAGUAIABCAC4AIABaAGEAaABhAHIAaQBhAGQAaQBzAP// AgAIAAAAAAAAAAAAAAAAAAAAAAAAAAEA//8CAAAAAAAAAP//AAACAP//AAAAAP//AAACAP//AAAA AAcAAABHFpABoQACAgYDBQQFAgME7zoA4EF4AMAJAAAAAAAAAP8BAAAAAAAAVABpAG0AZQBzACAA TgBlAHcAIABSAG8AbQBhAG4AAAA1FpABAgAFBQECAQcGAgUHAAAAAAAAABAAAAAAAAAAAAAAAIAA AAAAUwB5AG0AYgBvAGwAAAAzJpABoQACCwYEAgICAgIE/zoA4EN4AMAJAAAAAAAAAP8BAAAAAAAA QQByAGkAYQBsAAAARTWQAaEAAgsGCQQFBAICBI8CAIAAGAAAAAAAAAAAAAAfAAAAAAAAAEwAdQBj AGkAZABhACAAQwBvAG4AcwBvAGwAZQAAAFE1kAGACgICBgkEAgUIAwT/AgDg+/3HahIAAAAAAAAA nwACAAAAAABNAFMAIABNAGkAbgBjAGgAbwAAAD8AbAA/AHIAIAA/AD8AgQBmAGMAAAA1JpABoQAC CwYEAwUEBAIE/zoA4VtgAMApAAAAAAAAAP8BAQAAAAAAVABhAGgAbwBtAGEAAAA/NZABoQACBwMJ AgIFAgQE/zoA4EN4AMAJAAAAAAAAAP8BAAAAAAAAQwBvAHUAcgBpAGUAcgAgAE4AZQB3AAAAIgAE ADGIiBgA8NACAABoAQAAAAAHxdSmB8XUpgAAAAACAAUAAAAXJQAASsgAAAEAeQAAAAQAAxCrAQAA FyUAAErIAAABAHkAAACrAQAAAAAAAHEDAPAQAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAKAF oAW0ALQAgYEyNAAAEAAZAGQAAAAZAAAA6OwAAOjsAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACAAAAAAAAAAAACTKDUQDwEAAIAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABIWAAAAAAJ8P8PAQABPwAA5QQAAAAAAAD///9///// fwAAAAD///9/////f////38UFGMAAAAAADIAAAAAAAAAAAAAAAAAAQAAAP//EgAAAAAAAAAlAGQA cgBhAGYAdAAtAHQAcwBhAG8ALQByAG8AbABsAC0AcwBlAGMAdQByAGkAdAB5AC0AZgByAGEAbQBl AHcAbwByAGsALQAwADAAAAAAAAAAFgBUAGgAZQBvAGQAbwByAGUAIABCAC4AIABaAGEAaABhAHIA aQBhAGQAaQBzABYAVABoAGUAbwBkAG8AcgBlACAAQgAuACAAWgBhAGgAYQByAGkAYQBkAGkAcwAA AAAAAAAAAAAAAAAAAAAAAAAAABAAAAAGAAAAAQAAAAAADAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD+/wAABgACAAAAAAAAAAAAAAAAAAAA AAABAAAA4IWf8vlPaBCrkQgAKyez2TAAAACwAQAAEQAAAAEAAACQAAAAAgAAAJgAAAADAAAAyAAA AAQAAADUAAAABQAAAPQAAAAGAAAAAAEAAAcAAAAMAQAACAAAACABAAAJAAAAQAEAABIAAABMAQAA CgAAAGwBAAAMAAAAeAEAAA0AAACEAQAADgAAAJABAAAPAAAAmAEAABAAAACgAQAAEwAAAKgBAAAC AAAA5QQAAB4AAAAoAAAAZHJhZnQtdHNhby1yb2xsLXNlY3VyaXR5LWZyYW1ld29yay0wMAAAAB4A AAAEAAAAAAAAAB4AAAAYAAAAVGhlb2RvcmUgQi4gWmFoYXJpYWRpcwAAHgAAAAQAAAAAAAAAHgAA AAQAAAAAAAAAHgAAAAwAAABOb3JtYWwuZG90AAAeAAAAGAAAAFRoZW9kb3JlIEIuIFphaGFyaWFk aXMAAB4AAAAEAAAAMgAAAB4AAAAYAAAATWljcm9zb2Z0IE9mZmljZSBXb3JkAAAAQAAAAABe0LIA AAAAQAAAAADSthT/xMkBQAAAAADSthT/xMkBAwAAAAEAAAADAAAAFyUAAAMAAABKyAAAAwAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA/v8AAAYAAgAAAAAAAAAAAAAAAAAAAAAAAQAAAALV zdWcLhsQk5cIACss+a4wAAAADAEAAAwAAAABAAAAaAAAAA8AAABwAAAABQAAAHwAAAAGAAAAhAAA ABEAAACMAAAAFwAAAJQAAAALAAAAnAAAABAAAACkAAAAEwAAAKwAAAAWAAAAtAAAAA0AAAC8AAAA DAAAAO4AAAACAAAA5QQAAB4AAAAEAAAAAAAAAAMAAACrAQAAAwAAAHkAAAADAAAA6OwAAAMAAAAP JwsACwAAAAAAAAALAAAAAAAAAAsAAAAAAAAACwAAAAAAAAAeEAAAAQAAACYAAABkcmFmdC10c2Fv LXJvbGwtc2VjdXJpdHktZnJhbWV3b3JrLTAwAAwQAAACAAAAHgAAAAYAAABUaXRsZQADAAAAAQAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAEAAAACAAAAAwAAAAQAAAAFAAAABgAAAAcAAAAIAAAACQAAAAoA AAALAAAADAAAAA0AAAAOAAAADwAAABAAAAARAAAAEgAAABMAAAAUAAAAFQAAABYAAAAXAAAAGAAA ABkAAAAaAAAAGwAAABwAAAAdAAAAHgAAAB8AAAAgAAAAIQAAACIAAAAjAAAAJAAAACUAAAAmAAAA JwAAACgAAAApAAAAKgAAACsAAAAsAAAALQAAAC4AAAAvAAAAMAAAADEAAAAyAAAAMwAAADQAAAA1 AAAANgAAADcAAAA4AAAAOQAAADoAAAA7AAAAPAAAAD0AAAA+AAAAPwAAAEAAAABBAAAAQgAAAEMA AABEAAAARQAAAEYAAABHAAAASAAAAEkAAABKAAAASwAAAEwAAABNAAAATgAAAE8AAABQAAAAUQAA AFIAAABTAAAAVAAAAFUAAABWAAAAVwAAAFgAAABZAAAAWgAAAFsAAABcAAAAXQAAAF4AAABfAAAA YAAAAGEAAABiAAAAYwAAAGQAAABlAAAAZgAAAGcAAABoAAAAaQAAAGoAAABrAAAAbAAAAG0AAABu AAAAbwAAAHAAAABxAAAAcgAAAHMAAAB0AAAAdQAAAHYAAAB3AAAAeAAAAHkAAAB6AAAAewAAAHwA AAB9AAAAfgAAAH8AAACAAAAAgQAAAIIAAACDAAAAhAAAAIUAAACGAAAAhwAAAIgAAACJAAAAigAA AIsAAACMAAAAjQAAAI4AAACPAAAAkAAAAJEAAACSAAAAkwAAAJQAAACVAAAAlgAAAJcAAACYAAAA mQAAAJoAAACbAAAAnAAAAJ0AAACeAAAAnwAAAKAAAAChAAAAogAAAKMAAACkAAAApQAAAKYAAACn AAAAqAAAAKkAAACqAAAAqwAAAKwAAACtAAAArgAAAK8AAACwAAAAsQAAALIAAACzAAAAtAAAALUA AAC2AAAAtwAAALgAAAC5AAAAugAAALsAAAC8AAAAvQAAAL4AAAD+////wAAAAMEAAADCAAAAwwAA AMQAAADFAAAAxgAAAP7////IAAAAyQAAAMoAAADLAAAAzAAAAM0AAADOAAAAzwAAANAAAADRAAAA 0gAAANMAAADUAAAA1QAAANYAAADXAAAA2AAAANkAAADaAAAA2wAAANwAAADdAAAA3gAAAN8AAADg AAAA4QAAAOIAAADjAAAA5AAAAOUAAADmAAAA5wAAAOgAAADpAAAA6gAAAOsAAADsAAAA7QAAAO4A AADvAAAA8AAAAPEAAADyAAAA8wAAAPQAAAD1AAAA9gAAAPcAAAD4AAAA+QAAAPoAAAD7AAAA/AAA AP0AAAD+AAAA/wAAAAABAAABAQAAAgEAAAMBAAAEAQAABQEAAAYBAAAHAQAACAEAAAkBAAAKAQAA CwEAAAwBAAANAQAADgEAAA8BAAAQAQAAEQEAABIBAAATAQAAFAEAABUBAAAWAQAAFwEAABgBAAAZ AQAAGgEAABsBAAAcAQAAHQEAAB4BAAAfAQAAIAEAACEBAAAiAQAAIwEAACQBAAAlAQAAJgEAACcB AAAoAQAAKQEAACoBAAArAQAALAEAAC0BAAAuAQAALwEAADABAAAxAQAA/v///zMBAAA0AQAANQEA ADYBAAA3AQAAOAEAADkBAAD+////OwEAADwBAAA9AQAAPgEAAD8BAABAAQAAQQEAAP7////9//// /f////3///9GAQAA/v////7////+//////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// /////////////////////1IAbwBvAHQAIABFAG4AdAByAHkAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAWAAUB//////////8DAAAABgkCAAAAAADAAAAAAAAARgAA AAAAAAAAAAAAAOC4aCP/xMkBSAEAAIAAAAAAAAAARABhAHQAYQAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAoAAgH///////////////8AAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAC/AAAAABAAAAAAAAAxAFQAYQBiAGwAZQAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADgACAQEA AAAGAAAA/////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAMcAAADj1AAAAAAA AFcAbwByAGQARABvAGMAdQBtAGUAbgB0AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAaAAIBAgAAAAUAAAD/////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAADR8AQAAAAAABQBTAHUAbQBtAGEAcgB5AEkAbgBmAG8AcgBtAGEAdABpAG8AbgAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAACgAAgH///////////////8AAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAyAQAAABAAAAAAAAAFAEQAbwBjAHUAbQBlAG4AdABTAHUAbQBtAGEA cgB5AEkAbgBmAG8AcgBtAGEAdABpAG8AbgAAAAAAAAAAAAAAOAACAQQAAAD//////////wAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADoBAAAAEAAAAAAAAAEAQwBvAG0AcABPAGIA agAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAASAAIA//// ////////////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHEAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAD///////////////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAABAAAA/v////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// /////////////////wEA/v8DCgAA/////wYJAgAAAAAAwAAAAAAAAEYfAAAATWljcm9zb2Z0IE9m ZmljZSBXb3JkIERvY3VtZW50AAoAAABNU1dvcmREb2MAEAAAAFdvcmQuRG9jdW1lbnQuOAD0ObJx AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAA ------=_NextPart_000_023F_01C9C51A.067AC320-- From alexandru.petrescu@gmail.com Wed Apr 29 07:17: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 0116A3A7152 for ; Wed, 29 Apr 2009 07:17:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.163 X-Spam-Level: X-Spam-Status: No, score=-2.163 tagged_above=-999 required=5 tests=[AWL=0.086, 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 1sq6TJeHFcdk for ; Wed, 29 Apr 2009 07:17:57 -0700 (PDT) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.166.172.107]) by core3.amsl.com (Postfix) with ESMTP id 8065428C2B4 for ; Wed, 29 Apr 2009 07:17:35 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.0) with ESMTP id n3TEIqD7000487 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 29 Apr 2009 16:18:52 +0200 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.2/8.14.2) with ESMTP id n3TEIqwt001538; Wed, 29 Apr 2009 16:18:52 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.133.173]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id n3TEIpK9025306; Wed, 29 Apr 2009 16:18:52 +0200 Message-ID: <49F861CB.3000305@gmail.com> Date: Wed, 29 Apr 2009 16:18:51 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Richard Kelsey References: <200904241552.n3OFq6X3004362@kelsey-ws.hq.ember.com> <1068684476.126101240591804987.JavaMail.root@mail02.pantherlink.uwm.edu> <34b478810904241431h20435ecq81bd2f16d8973fc1@mail.gmail.com> <200904271504.n3RF4RJt004817@kelsey-ws.hq.ember.com> <49F70636.6000709@gmail.com> <200904281815.n3SIFVmM023615@kelsey-ws.hq.ember.com> In-Reply-To: <200904281815.n3SIFVmM023615@kelsey-ws.hq.ember.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: rossi@dei.unipd.it, roll@ietf.org Subject: Re: [Roll] Energy metric for link X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Apr 2009 14:17:58 -0000 Richard Kelsey a écrit : > Date: Tue, 28 Apr 2009 15:35:50 +0200 From: Alexandru Petrescu > > > Richard Kelsey a écrit : >> >> That wasn't the point I was trying to make. My point was that it >> makes more sense to treat a battery powered device as being >> bandwith limited, with the limit determined by its initial energy >> and its design lifetime, > > This - relating bandwidth uniquely to battery-level - seems a stretch > to me. Supposedly, the way batteries deplete (the time it takes to > send a 1280bytes at a high bandwidth) vary largely with other factors > such as battery age and number of recycle duties. > > Battery level need be only one input into the bandwidth calculation. > Basically, each node would make its own determination as to the > bandwidth it could support, taking into account whatever local state > that it deemed relevent. That limit could then be both reported to > other devices and enforced by the node itself. Richard, I can understand a node would need more battery to transmit at higher speed (higher bandwidth). I can also see a node settling for less transmission speed if it had less battery available. You seem to say nodes would exchange each other's such limits and maybe elect the lowest common denominator for that limit, and all conclude to transmit at that bandwidth limit. Sounds as an idea which should be listed too. It's different than the energy metric for the link idea I suggested earlier. May I then ask: what should be encoded in the metric? Bandwidth? expressed how on bits/secods? Millseconds? Alex > In making routing decisions, what matters in the end is the bandwidth > and latency through each possible relay. I think it would be both > simpler and more effective to have each node be responsible for > determining its own bandwidth and latency constraints rather than > have each node report its internal condition (link and battery > parameters, for example) and have some other device translate those > into bandwidth and latency constaints. > > -Richard Kelsey > From culler@cs.berkeley.edu Wed Apr 29 08:35: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 D8C633A6F1B for ; Wed, 29 Apr 2009 08:35:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9WbDUPK84yD7 for ; Wed, 29 Apr 2009 08:35:04 -0700 (PDT) Received: from gateway0.EECS.Berkeley.EDU (gateway0.EECS.Berkeley.EDU [169.229.60.87]) by core3.amsl.com (Postfix) with ESMTP id 36CFB3A6C7D for ; Wed, 29 Apr 2009 08:35:04 -0700 (PDT) Received: from dhcp-44-135.EECS.Berkeley.EDU (dhcp-44-135.EECS.Berkeley.EDU [128.32.44.135]) (authenticated bits=0) by gateway0.EECS.Berkeley.EDU (8.14.3/8.13.5) with ESMTP id n3TFaNPf007990 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Wed, 29 Apr 2009 08:36:25 -0700 (PDT) Message-Id: From: culler To: roll@ietf.org Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Wed, 29 Apr 2009 08:36:18 -0700 X-Mailer: Apple Mail (2.930.3) Subject: [Roll] WG Adoption of Metrics Draft X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 29 Apr 2009 15:35:04 -0000 The response to polling the WG for adoption on March 24 was largely an extensive discussion of issues within the draft. Implicit in that discussion is that this draft is adequate to be a basis for building a consensus on those issues. Metrics are always extremely tricky. There is an inherent "Goldilocks" problem of having them specific enough to be meaningful, general enough to be manageable, and concise enough to be useful. We are already deep into debating the specifics. So I move that at this point we adopt the draft as a working group document. Hopefully it will evolve and consensus will be established. Let me be redundant are remind us that the goal is rough consensus AND running, not indefinite discussions about how many angels can dance on the tend of a low power pin. From richard.kelsey@ember.com Wed Apr 29 08:44: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 75C4028C2B6 for ; Wed, 29 Apr 2009 08:44:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.557 X-Spam-Level: X-Spam-Status: No, score=-2.557 tagged_above=-999 required=5 tests=[AWL=0.042, 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 4BkPGehntDr1 for ; Wed, 29 Apr 2009 08:44:05 -0700 (PDT) Received: from EMPIRE.hq.ember.com (mail.ember.com [74.10.175.227]) by core3.amsl.com (Postfix) with ESMTP id 7264C28C2A2 for ; Wed, 29 Apr 2009 08:44:05 -0700 (PDT) Received: from kelsey-ws.hq.ember.com ([192.168.81.55]) by EMPIRE.hq.ember.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 29 Apr 2009 11:46:23 -0400 Received: from kelsey-ws.hq.ember.com (localhost.localdomain [127.0.0.1]) by kelsey-ws.hq.ember.com (8.13.4/8.13.4) with ESMTP id n3TFjQZQ002235; Wed, 29 Apr 2009 11:45:26 -0400 Received: (from kelsey@localhost) by kelsey-ws.hq.ember.com (8.13.4/8.12.8/Submit) id n3TFjQFK002232; Wed, 29 Apr 2009 11:45:26 -0400 Date: Wed, 29 Apr 2009 11:45:26 -0400 Message-Id: <200904291545.n3TFjQFK002232@kelsey-ws.hq.ember.com> To: alexandru.petrescu@gmail.com In-reply-to: <49F861CB.3000305@gmail.com> (message from Alexandru Petrescu on Wed, 29 Apr 2009 16:18:51 +0200) From: Richard Kelsey References: <200904241552.n3OFq6X3004362@kelsey-ws.hq.ember.com> <1068684476.126101240591804987.JavaMail.root@mail02.pantherlink.uwm.edu> <34b478810904241431h20435ecq81bd2f16d8973fc1@mail.gmail.com> <200904271504.n3RF4RJt004817@kelsey-ws.hq.ember.com> <49F70636.6000709@gmail.com> <200904281815.n3SIFVmM023615@kelsey-ws.hq.ember.com> <49F861CB.3000305@gmail.com> X-OriginalArrivalTime: 29 Apr 2009 15:46:23.0908 (UTC) FILETIME=[A63E7E40:01C9C8E1] Cc: rossi@dei.unipd.it, roll@ietf.org Subject: Re: [Roll] Energy metric for link X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Apr 2009 15:44:06 -0000 Date: Wed, 29 Apr 2009 16:18:51 +0200 From: Alexandru Petrescu Richard, I can understand a node would need more battery to transmit at higher speed (higher bandwidth). I can also see a node settling for less transmission speed if it had less battery available. You seem to say nodes would exchange each other's such limits and maybe elect the lowest common denominator for that limit, and all conclude to transmit at that bandwidth limit. That is not what I am suggesting. Given its current battery level, design lifetime, internal requirements, and so forth, a battery-powered device has some amount of energy that it is willing to expend in forwarding messages for other devices. Combining this with the energy efficiency of the link you get the bandwidth that the device is willing to make available for forwarding messages. For example, a device might be willing to forward ten 1280-byte messages every hour. Regardless of what information is exchanged between devices, in the end the decision comes down whether to forward a particular packet via a particular neighbor. Rather than get all of the details of the neighbor's state and making some judgement call, it seems much simpler just to find out the rate at which the neighbor is willing to forward packets. May I then ask: what should be encoded in the metric? Bandwidth? expressed how on bits/secods? Millseconds? Byte/second would be fine, plus a per-packet overhead in bytes. For example, 1k bytes/second plus a 100 byte per-packet overhead would mean that the device was willing to forward one 900-byte packet or two 400-byte packets every second. The overhead is not the actual size of any link headers, but reflects the additional per-packet cost incurred by the device. This might include the expected cost of PHY backoffs, for example. -Richard Kelsey From alexandru.petrescu@gmail.com Wed Apr 29 09:48: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 0235B3A6EEF for ; Wed, 29 Apr 2009 09:48:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.157 X-Spam-Level: X-Spam-Status: No, score=-2.157 tagged_above=-999 required=5 tests=[AWL=0.092, 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 mR6L3LJAWUiK for ; Wed, 29 Apr 2009 09:48:15 -0700 (PDT) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.1]) by core3.amsl.com (Postfix) with ESMTP id 02C523A6DFD for ; Wed, 29 Apr 2009 09:48:14 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.0) with ESMTP id n3TGlRur023854 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 29 Apr 2009 18:47:27 +0200 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (8.14.2/8.14.2) with ESMTP id n3TGnWCm032712; Wed, 29 Apr 2009 18:49:32 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.133.173]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id n3TGnV4J023569; Wed, 29 Apr 2009 18:49:32 +0200 Message-ID: <49F8851B.7090705@gmail.com> Date: Wed, 29 Apr 2009 18:49:31 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Richard Kelsey References: <200904241552.n3OFq6X3004362@kelsey-ws.hq.ember.com> <1068684476.126101240591804987.JavaMail.root@mail02.pantherlink.uwm.edu> <34b478810904241431h20435ecq81bd2f16d8973fc1@mail.gmail.com> <200904271504.n3RF4RJt004817@kelsey-ws.hq.ember.com> <49F70636.6000709@gmail.com> <200904281815.n3SIFVmM023615@kelsey-ws.hq.ember.com> <49F861CB.3000305@gmail.com> <200904291545.n3TFjQFK002232@kelsey-ws.hq.ember.com> In-Reply-To: <200904291545.n3TFjQFK002232@kelsey-ws.hq.ember.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: rossi@dei.unipd.it, roll@ietf.org Subject: Re: [Roll] Energy metric for link X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Apr 2009 16:48:16 -0000 Richard Kelsey a écrit : > Date: Wed, 29 Apr 2009 16:18:51 +0200 > From: Alexandru Petrescu > > Richard, I can understand a node would need more battery to transmit at > higher speed (higher bandwidth). > > I can also see a node settling for less transmission speed if it had > less battery available. > > You seem to say nodes would exchange each other's such limits and maybe > elect the lowest common denominator for that limit, and all conclude to > transmit at that bandwidth limit. > > That is not what I am suggesting. > > Given its current battery level, design lifetime, internal > requirements, and so forth, a battery-powered device has > some amount of energy that it is willing to expend in > forwarding messages for other devices. Combining this with > the energy efficiency of the link you get the bandwidth that > the device is willing to make available for forwarding > messages. For example, a device might be willing to forward > ten 1280-byte messages every hour. > > Regardless of what information is exchanged between devices, > in the end the decision comes down whether to forward a > particular packet via a particular neighbor. Rather than > get all of the details of the neighbor's state and making > some judgement call, it seems much simpler just to find out > the rate at which the neighbor is willing to forward > packets. > > May I then ask: what should be encoded in the metric? > Bandwidth? expressed how on bits/secods? Millseconds? > > Byte/second would be fine, plus a per-packet overhead in > bytes. For example, 1k bytes/second plus a 100 byte > per-packet overhead would mean that the device was willing > to forward one 900-byte packet or two 400-byte packets every > second. The overhead is not the actual size of any link > headers, but reflects the additional per-packet cost > incurred by the device. This might include the expected > cost of PHY backoffs, for example. Richard, Is there any other place RFC/draft which specifies such a bandwidth metric encoding that we could reuse in ROLL? (I've looked quickly at RIP and OSPF and couldn't find). Alex From richard.kelsey@ember.com Wed Apr 29 10:52: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 E20963A6D0A for ; Wed, 29 Apr 2009 10:52:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.559 X-Spam-Level: X-Spam-Status: No, score=-2.559 tagged_above=-999 required=5 tests=[AWL=0.040, 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 0AFN-fQNgMHz for ; Wed, 29 Apr 2009 10:52:15 -0700 (PDT) Received: from EMPIRE.hq.ember.com (mail.ember.com [74.10.175.227]) by core3.amsl.com (Postfix) with ESMTP id 8E70D3A67F0 for ; Wed, 29 Apr 2009 10:52:15 -0700 (PDT) Received: from kelsey-ws.hq.ember.com ([192.168.81.55]) by EMPIRE.hq.ember.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 29 Apr 2009 13:54:34 -0400 Received: from kelsey-ws.hq.ember.com (localhost.localdomain [127.0.0.1]) by kelsey-ws.hq.ember.com (8.13.4/8.13.4) with ESMTP id n3THrbXU003429; Wed, 29 Apr 2009 13:53:37 -0400 Received: (from kelsey@localhost) by kelsey-ws.hq.ember.com (8.13.4/8.12.8/Submit) id n3THraJ1003426; Wed, 29 Apr 2009 13:53:36 -0400 Date: Wed, 29 Apr 2009 13:53:36 -0400 Message-Id: <200904291753.n3THraJ1003426@kelsey-ws.hq.ember.com> To: alexandru.petrescu@gmail.com In-reply-to: <49F8851B.7090705@gmail.com> (message from Alexandru Petrescu on Wed, 29 Apr 2009 18:49:31 +0200) From: Richard Kelsey References: <200904241552.n3OFq6X3004362@kelsey-ws.hq.ember.com> <1068684476.126101240591804987.JavaMail.root@mail02.pantherlink.uwm.edu> <34b478810904241431h20435ecq81bd2f16d8973fc1@mail.gmail.com> <200904271504.n3RF4RJt004817@kelsey-ws.hq.ember.com> <49F70636.6000709@gmail.com> <200904281815.n3SIFVmM023615@kelsey-ws.hq.ember.com> <49F861CB.3000305@gmail.com> <200904291545.n3TFjQFK002232@kelsey-ws.hq.ember.com> <49F8851B.7090705@gmail.com> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 29 Apr 2009 17:54:34.0458 (UTC) FILETIME=[8E2B4BA0:01C9C8F3] Cc: rossi@dei.unipd.it, roll@ietf.org Subject: Re: [Roll] Energy metric for link X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Apr 2009 17:52:17 -0000 Date: Wed, 29 Apr 2009 18:49:31 +0200 From: Alexandru Petrescu Richard Kelsey a écrit : > Given its current battery level, design lifetime, internal > requirements, and so forth, a battery-powered device has > some amount of energy that it is willing to expend in > forwarding messages for other devices. Combining this with > the energy efficiency of the link you get the bandwidth that > the device is willing to make available for forwarding > messages. For example, a device might be willing to forward > ten 1280-byte messages every hour. > > Regardless of what information is exchanged between devices, > in the end the decision comes down whether to forward a > particular packet via a particular neighbor. Rather than > get all of the details of the neighbor's state and making > some judgement call, it seems much simpler just to find out > the rate at which the neighbor is willing to forward > packets. > > May I then ask: what should be encoded in the metric? > Bandwidth? expressed how on bits/secods? Millseconds? > > Byte/second would be fine, plus a per-packet overhead in > bytes. For example, 1k bytes/second plus a 100 byte > per-packet overhead would mean that the device was willing > to forward one 900-byte packet or two 400-byte packets every > second. The overhead is not the actual size of any link > headers, but reflects the additional per-packet cost > incurred by the device. This might include the expected > cost of PHY backoffs, for example. Is there any other place RFC/draft which specifies such a bandwidth metric encoding that we could reuse in ROLL? (I've looked quickly at RIP and OSPF and couldn't find). Alex, Not that I am aware of. The closest that I know of is the OLSRv2 'willingness' metric, for which no units are specified. One difficulty is that it is really a node cost, not a link cost, and most IETF protocols do not have metrics for node costs. An alternative would be for a node to adjust its advertised link costs in order to limit the number of messages that it was asked to forward. Rather than advertising a maximum acceptable bandwidth, the node would increase its advertised link costs until the actual bandwidth dropped to an acceptable level. If the actual bandwidth was low enough, 1/2 the acceptable maximum, say, the node could reduce its advertised costs. -Richard Kelsey From robert.assimiti@nivis.com Wed Apr 29 13:23:33 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0F5913A6ED5 for ; Wed, 29 Apr 2009 13:23:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.917 X-Spam-Level: X-Spam-Status: No, score=-1.917 tagged_above=-999 required=5 tests=[AWL=0.682, 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 4+nuZr+Q4mMV for ; Wed, 29 Apr 2009 13:23:32 -0700 (PDT) Received: from mail.nivis.com (mail.nivis.com [65.205.163.229]) by core3.amsl.com (Postfix) with SMTP id 06D873A6ABB for ; Wed, 29 Apr 2009 13:23:31 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 29 Apr 2009 16:24:56 -0400 Message-ID: In-Reply-To: <49F6F247.8050009@gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] Energy metric for link thread-index: AcnH+mFaSAPvFo3bRdqxVvOffn8mCQBC4Tiw References: <49F6F247.8050009@gmail.com> From: "Robert Assimiti" To: "Alexandru Petrescu" Cc: roll@ietf.org Subject: Re: [Roll] Energy metric for link X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Apr 2009 20:23:33 -0000 Hello Alex, I completely agree with the necessity of a "energy cost" metric in routin= g decisions. I would like to add though that this has to be translated to a bandwidth = capacity metric as well (speaking from router A's point of view): 1. If you want me to route an MTU for you it will cost me (battery operat= ed router A) xxx mW 2. I have the capacity (since I am battery operated) to route yyy MTU's/p= er hour. -----Original Message----- From: Alexandru Petrescu [mailto:alexandru.petrescu@gmail.com]=20 Sent: Tuesday, April 28, 2009 8:11 AM To: Robert Assimiti Cc: roll@ietf.org Subject: Re: [Roll] Energy metric for link Hi Robert, With respect your text below, I think the following: Robert Assimiti a =E9crit : [...] > When joining the network, each node should report its energy=20 > capabilities such as: >=20 > 1. I can run my receiver for X seconds/hour in order to receive=20 > incoming PDU's that need routing. >=20 > 2. I can spend Y seconds/ hour TXing PDUs on behalf of other nodes=20 > (routing) and my internally generated PDUs >=20 > 3. I can spend Z seconds/ hour advertising for other devices that=20 > want to join the network (beacons for synch etc) I believe a ROLL router should send on each of its interface an RA (ICMP Router Advertisement) containing a description of the energy needed to send or receive an 1280byte-sized packet on that link: 1. Sending an MTU packet on this link requires max X watts 2. Sending an MTU packet on this link requires min Y watts 3. Receiving an MTU packet on this link requires max X watts 4. Receiving an MTU packet on this link requires min Y watts This information may be used by the receivers in many different ways: e.g. a host chooses among two default routers the one through which lower energy is needed (a default router qualifier is also in RA), e.g. two neighboring routers learn from each other's RA that link's characteristics, and many more. This same way of encoding the energy for link in a metric can be encoded in OSPF and RIP metrics (and not in RA). In this way the OSPF or RIP routing protocol could build paths depending not only on hop count but also on the energy needed to travel that path. What do people think about this energy metric for a link? > Once this parameters are available as READ ONLY MIB attributes, other > nodes (or a central management entity in a deterministic network)=20 > can request this MIBs and base their routing decision on them. These paramters, or metrics, should certainly figure in a ROLL MIB (Management Information Base), I agree. Alex This e-mail (including any attachments to it) is confidential, proprietar= y, legally privileged, subject to copyright and is sent for the personal = attention of the intended recipient only. If you have received this e-mai= l in error, please reply to advise us immediately, delete it and destroy = any printed copies of it. You are notified that reading, disclosing, copy= ing, distributing or taking any action in reliance on the contents of thi= s information is strictly prohibited. No employee is authorized to conclu= de any binding agreement on behalf of NIVIS LLC with another party by e-m= ail without express written confirmation by an officer of the company. Al= though we have taken reasonable precautions to ensure no viruses are pres= ent in this e-mail, we cannot accept responsibility for any loss or damag= e arising from the viruses in this e-mail or attachments. From robert.assimiti@nivis.com Wed Apr 29 13:54: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 4FB013A69EC for ; Wed, 29 Apr 2009 13:54:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.088 X-Spam-Level: X-Spam-Status: No, score=-2.088 tagged_above=-999 required=5 tests=[AWL=0.511, 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 PzoaLGdxkDsP for ; Wed, 29 Apr 2009 13:54:44 -0700 (PDT) Received: from mail.nivis.com (mail.nivis.com [65.205.163.229]) by core3.amsl.com (Postfix) with SMTP id 47E023A67F9 for ; Wed, 29 Apr 2009 13:54:44 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 29 Apr 2009 16:56:10 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RE: [ROLL] Energy metric for link thread-index: AcnJDOx02nuKBCvKRFyJTA5wNxFabg== From: "Robert Assimiti" To: "Alexandru Petrescu" Cc: roll@ietf.org Subject: Re: [Roll] [ROLL] Energy metric for link X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Apr 2009 20:54:45 -0000 Hello Alex and Richard, An effective energy metric should be completely agnostic of: 1. The PHY/MAC employed by the router (baud rate) 2. The maximum DPDU that is supported by the PHY/MAC (128 bytes in 802.15= =2E4). Therefore expressing energy in terms of the 1280 MTU is meaningles= s for most wireless technologies, given that they fragment the packet any= way into the max DPDU length packets. 3. Battery chemistry, battery depletion level, recharge cycles, device in= ternal power supply conversion losses etc etc This should all be an internal device matters that would all be compacted= in a single energy metric. A very simple one that makes sense is millise= conds/second because it suits all currently existing RF technologies that= we are targeting in ROLL. Bits/second would be PHY/MAC dependent. Thks Date: Wed, 29 Apr 2009 16:18:51 +0200 From: Alexandru Petrescu Subject: Re: [Roll] Energy metric for link To: Richard Kelsey Cc: rossi@dei.unipd.it, roll@ietf.org Message-ID: <49F861CB.3000305@gmail.com> Content-Type: text/plain; charset=3DUTF-8; format=3Dflowed Richard Kelsey a ?crit : > Date: Tue, 28 Apr 2009 15:35:50 +0200 From: Alexandru Petrescu=20 > >=20 > Richard Kelsey a ?crit : >>=20 >> That wasn't the point I was trying to make. My point was that it=20 >> makes more sense to treat a battery powered device as being bandwith=20= >> limited, with the limit determined by its initial energy and its=20 >> design lifetime, >=20 > This - relating bandwidth uniquely to battery-level - seems a stretch=20= > to me. Supposedly, the way batteries deplete (the time it takes to=20 > send a 1280bytes at a high bandwidth) vary largely with other factors=20= > such as battery age and number of recycle duties. >=20 > Battery level need be only one input into the bandwidth calculation. > Basically, each node would make its own determination as to the=20 > bandwidth it could support, taking into account whatever local state=20= > that it deemed relevent. That limit could then be both reported to=20 > other devices and enforced by the node itself. Richard, I can understand a node would need more battery to transmit at h= igher speed (higher bandwidth). I can also see a node settling for less transmission speed if it had less= battery available. You seem to say nodes would exchange each other's such limits and maybe e= lect the lowest common denominator for that limit, and all conclude to tr= ansmit at that bandwidth limit. Sounds as an idea which should be listed too. It's different than the energy metric for the link idea I suggested earli= er. May I then ask: what should be encoded in the metric? Bandwidth?=20 expressed how on bits/secods? Millseconds? Alex > In making routing decisions, what matters in the end is the bandwidth=20= > and latency through each possible relay. I think it would be both=20 > simpler and more effective to have each node be responsible for=20 > determining its own bandwidth and latency constraints rather than have=20= > each node report its internal condition (link and battery parameters,=20= > for example) and have some other device translate those into bandwidth=20= > and latency constaints. >=20 > -Richard Kelsey >=20 "The nice thing about standards is that there are so many to choose from.= " - Andrew S. Tanenbaum=20 Robert Assimiti Executive Staff=A0Engineer Office: [678]-202-6859 Mobile: [404]-578-0205 robert.assimiti@nivis.com This e-mail (including any attachments to it) is confidential, proprietar= y, legally privileged, subject to copyright and is sent for the personal = attention of the intended recipient only. If you have received this e-mai= l in error, please reply to advise us immediately, delete it and destroy = any printed copies of it. You are notified that reading, disclosing, copy= ing, distributing or taking any action in reliance on the contents of thi= s information is strictly prohibited. No employee is authorized to conclu= de any binding agreement on behalf of NIVIS LLC with another party by e-m= ail without express written confirmation by an officer of the company. Al= though we have taken reasonable precautions to ensure no viruses are pres= ent in this e-mail, we cannot accept responsibility for any loss or damag= e arising from the viruses in this e-mail or attachments. From alexandru.petrescu@gmail.com Wed Apr 29 14:46: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 AEDDD3A6E98 for ; Wed, 29 Apr 2009 14:46:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.837 X-Spam-Level: X-Spam-Status: No, score=-0.837 tagged_above=-999 required=5 tests=[AWL=-1.002, BAYES_40=-0.185, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Be9JTZZ0TmZi for ; Wed, 29 Apr 2009 14:46:55 -0700 (PDT) Received: from smtp3-g21.free.fr (smtp3-g21.free.fr [212.27.42.3]) by core3.amsl.com (Postfix) with ESMTP id 20C733A6A03 for ; Wed, 29 Apr 2009 14:46:53 -0700 (PDT) Received: from smtp3-g21.free.fr (localhost [127.0.0.1]) by smtp3-g21.free.fr (Postfix) with ESMTP id 667BD81806B; Wed, 29 Apr 2009 23:48:06 +0200 (CEST) Received: from [127.0.0.1] (bur91-3-82-239-213-32.fbx.proxad.net [82.239.213.32]) by smtp3-g21.free.fr (Postfix) with ESMTP id 5243E818042; Wed, 29 Apr 2009 23:48:04 +0200 (CEST) Message-ID: <49F8CB14.5080404@gmail.com> Date: Wed, 29 Apr 2009 23:48:04 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Robert Assimiti References: <49F6F247.8050009@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] Energy metric for link X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Apr 2009 21:46:59 -0000 Robert Assimiti a écrit : > Hello Alex, > > I completely agree with the necessity of a "energy cost" metric in routing decisions. > > I would like to add though that this has to be translated to a bandwidth capacity metric as well (speaking from router A's point of view): > > 1. If you want me to route an MTU for you it will cost me (battery operated router A) xxx mW > 2. I have the capacity (since I am battery operated) to route yyy MTU's/per hour. I tend to agree, and would qualify it as a node metric. I think this metric tends to be hard to express, many semantics possible... needs many perspectives to be looked from... Alex From alexandru.petrescu@gmail.com Wed Apr 29 14:53: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 C94A328C1B0 for ; Wed, 29 Apr 2009 14:53:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.03 X-Spam-Level: X-Spam-Status: No, score=-2.03 tagged_above=-999 required=5 tests=[AWL=0.219, 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 saGKjWsXnay1 for ; Wed, 29 Apr 2009 14:53:43 -0700 (PDT) Received: from smtp1-g21.free.fr (smtp1-g21.free.fr [212.27.42.1]) by core3.amsl.com (Postfix) with ESMTP id B72F73A67F9 for ; Wed, 29 Apr 2009 14:53:41 -0700 (PDT) Received: from smtp1-g21.free.fr (localhost [127.0.0.1]) by smtp1-g21.free.fr (Postfix) with ESMTP id E59F29400C4; Wed, 29 Apr 2009 23:54:44 +0200 (CEST) Received: from [127.0.0.1] (bur91-3-82-239-213-32.fbx.proxad.net [82.239.213.32]) by smtp1-g21.free.fr (Postfix) with ESMTP id D9F15940051; Wed, 29 Apr 2009 23:54:41 +0200 (CEST) Message-ID: <49F8CCA2.4030901@gmail.com> Date: Wed, 29 Apr 2009 23:54:42 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Robert Assimiti References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: roll@ietf.org Subject: Re: [Roll] [ROLL] Energy metric for link X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Apr 2009 21:53:43 -0000 Robert Assimiti a écrit : > Hello Alex and Richard, > > > An effective energy metric should be completely agnostic of: > > 1. The PHY/MAC employed by the router (baud rate) I agree. > 2. The maximum DPDU that is supported by the PHY/MAC (128 bytes in > 802.15.4). Therefore expressing energy in terms of the 1280 MTU is > meaningless for most wireless technologies, given that they fragment > the packet anyway into the max DPDU length packets. But this contradicts 1 above, no? If the link metric is independent of PHY/MAC then it doesn't care of DPDU no? > 3. Battery chemistry, battery depletion level, recharge cycles, > device internal power supply conversion losses etc etc I agree. > This should all be an internal device matters that would all be > compacted in a single energy metric. A very simple one that makes > sense is milliseconds/second because it suits all currently existing > RF technologies that we are targeting in ROLL. But second is not an unit for energy/power, like Watt/Joule/Amp-hour are, no? I think the unit chosen to represent and encode should be a unit used straightforardly during the measurements. The measurement should be as easy as counting bytes. Some chipsets report energy/power in a certain unit. I could open up another thread about choice of unit of measurement, and how we call it "energy metric" or "power metric" - Watt, Joule, amp-hour, horsepower, whatnot. Alex From richard.kelsey@ember.com Thu Apr 30 07:27: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 CBE4B3A6827 for ; Thu, 30 Apr 2009 07:27:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.56 X-Spam-Level: X-Spam-Status: No, score=-2.56 tagged_above=-999 required=5 tests=[AWL=0.039, 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 WekpQ-HkV4e6 for ; Thu, 30 Apr 2009 07:27:48 -0700 (PDT) Received: from EMPIRE.hq.ember.com (mail.ember.com [74.10.175.227]) by core3.amsl.com (Postfix) with ESMTP id 503FC3A6A4D for ; Thu, 30 Apr 2009 07:27:48 -0700 (PDT) Received: from kelsey-ws.hq.ember.com ([192.168.81.55]) by EMPIRE.hq.ember.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 30 Apr 2009 10:30:08 -0400 Received: from kelsey-ws.hq.ember.com (localhost.localdomain [127.0.0.1]) by kelsey-ws.hq.ember.com (8.13.4/8.13.4) with ESMTP id n3UETAj9014047; Thu, 30 Apr 2009 10:29:10 -0400 Received: (from kelsey@localhost) by kelsey-ws.hq.ember.com (8.13.4/8.12.8/Submit) id n3UETARS014044; Thu, 30 Apr 2009 10:29:10 -0400 Date: Thu, 30 Apr 2009 10:29:10 -0400 Message-Id: <200904301429.n3UETARS014044@kelsey-ws.hq.ember.com> To: robert.assimiti@nivis.com In-reply-to: (robert.assimiti@nivis.com) From: Richard Kelsey References: X-OriginalArrivalTime: 30 Apr 2009 14:30:08.0665 (UTC) FILETIME=[29999090:01C9C9A0] Cc: roll@ietf.org Subject: Re: [Roll] [ROLL] Energy metric for link X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Apr 2009 14:27:49 -0000 Date: Wed, 29 Apr 2009 16:56:10 -0400 From: "Robert Assimiti" An effective energy metric should be completely agnostic of: 1. The PHY/MAC employed by the router (baud rate) 2. The maximum DPDU that is supported by the PHY/MAC (128 bytes in 802.15.4). Therefore expressing energy in terms of the 1280 MTU is meaningless for most wireless technologies, given that they fragment the packet anyway into the max DPDU length packets. 3. Battery chemistry, battery depletion level, recharge cycles, device internal power supply conversion losses etc etc This should all be an internal device matters that would all be compacted in a single energy metric. A very simple one that makes sense is milliseconds/second because it suits all currently existing RF technologies that we are targeting in ROLL. Bits/second would be PHY/MAC dependent. I think we are trying to solve two different problems: A) Energy-aware routing that minimizes the total energy used. B) Energy-aware routing that takes into account the energy constraints of individual devices. Bits/second doesn't work for A, because it doesn't take into account the energy cost of the PHY/MAC. Bits/second does work for B, because what matters is a device's capacity for forwarding messages, which already factors in the energy cost of the PHY/MAC. -Richard Kelsey