From qiuying@i2r.a-star.edu.sg Thu Nov 1 00:39:47 2012 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5953321F8533 for ; Thu, 1 Nov 2012 00:39:47 -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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QuDMFdODJQBk for ; Thu, 1 Nov 2012 00:39:46 -0700 (PDT) Received: from gw1.scei.a-star.edu.sg (gw1.scei.a-star.edu.sg [192.122.140.10]) by ietfa.amsl.com (Postfix) with ESMTP id 544FC21F852C for ; Thu, 1 Nov 2012 00:39:45 -0700 (PDT) Received: from S3-CAS04.shared-svc.local ([10.217.253.200]) by gw1.scei.a-star.edu.sg (8.14.4/8.14.4) with ESMTP id qA17dVrc006861; Thu, 1 Nov 2012 15:39:31 +0800 Received: from Win7PC (10.217.253.130) by S3-CAS04.shared-svc.local (10.217.253.200) with Microsoft SMTP Server id 14.1.339.1; Thu, 1 Nov 2012 15:39:31 +0800 From: QIU Ying To: "'Philip Levis'" , "'Michael Richardson'" References: <1351629716.36391.YahooMailNeo@web160605.mail.bf1.yahoo.com> <47B5B50A-369F-474A-A4C8-1A951C164E1B@etri.re.kr> <8702.1351708776@obiwan.sandelman.ca> <50BC36AD-E4E2-4FD4-8BF1-B697EA86367C@cs.stanford.edu> In-Reply-To: <50BC36AD-E4E2-4FD4-8BF1-B697EA86367C@cs.stanford.edu> Date: Thu, 1 Nov 2012 15:45:59 +0800 Message-ID: <03ab01cdb804$ef219d70$cd64d850$@a-star.edu.sg> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac23veFJC3ysv+bcSmmUurdfEwX5KwARo+eA Content-Language: en-sg X-Originating-IP: [10.217.253.130] X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.7.7855, 1.0.431, 0.0.0000 definitions=2012-11-01_02:2012-11-01, 2012-11-01, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=0 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=6.0.2-1203120001 definitions=main-1211010011 Cc: 'JeongGil Ko' , roll@ietf.org Subject: Re: [Roll] Draft Agenda X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Nov 2012 07:39:47 -0000 I support Michael's priority order. But according to the current agenda, we remain almost half time space for nothing. Also agree Philip's point that "the goal of the presentation is to clearly state the points for discussion". For example, without Tero presentation on in last Vancouver meeting, which topic was not discussed in mail list before the meeting, we might not pay much attention on the progress of IEEE 802.15.9. Tero's slides give a good discussion point if the ROLL documents should be compatible with IEEE 802.15.9. Hence, the update of KEMP is the produce of the consideration. In personally, I do not like this KMP Information Element format designed by IEEE 802.15.9 WG. In LLNs, we struggle every bit in transmission, but the KMP format too complicated with many chian information in order to flexible. It's the discussion point I would like to bring to discuss in WG meeting. MRC> If it's not, then we don't need to discuss it. Since KEMP has not got positive or negative feedback, it seems likes controversial :) So, is it time for chairs to raise a consensus call? ;) Regards Qiu Ying > -----Original Message----- > From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of > Philip Levis > Sent: Thursday, November 01, 2012 7:17 AM > To: Michael Richardson > Cc: JeongGil Ko; roll@ietf.org WG > Subject: Re: [Roll] Draft Agenda > > On Oct 31, 2012, at 11:39 AM, Michael Richardson wrote: > > > > > Please be aware that among JP and I, I'm the one pushing loudest to > > restrict our meeting slot time to (in order of priority): > > > > 1) things in our charter. > > 2) things with activity on the mailing list. > > 3) things with reproduceable problem statements that might need > > to go into the charter. > > > > You may have noticed how incredibly full the IETF meetings are. > > > > The Area Directors have been pushing very hard on the WG chairs to > > make sure that we understand that the IETF sessions are *not* for > > presentations, but for discussion. > > This makes a lot of sense -- the goal of the presentation is to clearly > state the points for discussion. That being said, it does seem a little > weird that drafts which haven't been mentioned on the mailing list are > going to be discussed. > > > So, again: If there is work that you think has relevance to the ROLL > > WG, then please bring it up on the list. > > If it's not controversial, then we don't need to discuss it. > > > > If it's very controversial, then we need to pin down the set of > > concerns we have with it, so that, next week, when are together, we > > can focus on the actual issues. We aren't there to watch powerpoints. > > Whether RPL should support mixed mode operation seems pretty > controversial to me. > > Phil > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll Institute for Infocomm Research disclaimer: "This email is confidential and may be privileged. If you are not the intended recipient, please delete it and notify us immediately. Please do not copy or use it for any purpose, or disclose its contents to any other person. Thank you." From qiuying@i2r.a-star.edu.sg Thu Nov 1 00:52:19 2012 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C013321F84F6 for ; Thu, 1 Nov 2012 00:52:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vIHf0MUhdKiO for ; Thu, 1 Nov 2012 00:52:18 -0700 (PDT) Received: from gw2.scei.a-star.edu.sg (gw2.scei.a-star.edu.sg [192.122.140.11]) by ietfa.amsl.com (Postfix) with ESMTP id 7E01921F84DB for ; Thu, 1 Nov 2012 00:52:18 -0700 (PDT) Received: from pps.filterd (gw2 [127.0.0.1]) by gw2.scei.a-star.edu.sg (8.14.4/8.14.4) with SMTP id qA17mIwq005712; Thu, 1 Nov 2012 15:52:10 +0800 Received: from s3-cas04.shared-svc.local ([10.217.253.200]) by gw2.scei.a-star.edu.sg with ESMTP id 18bmnfr11p-1; Thu, 01 Nov 2012 15:52:10 +0800 Received: from Win7PC (10.217.253.130) by S3-CAS04.shared-svc.local (10.217.253.200) with Microsoft SMTP Server id 14.1.339.1; Thu, 1 Nov 2012 15:52:09 +0800 From: QIU Ying To: "'QIU Ying'" , "'Philip Levis'" , "'Michael Richardson'" References: <1351629716.36391.YahooMailNeo@web160605.mail.bf1.yahoo.com> <47B5B50A-369F-474A-A4C8-1A951C164E1B@etri.re.kr> <8702.1351708776@obiwan.sandelman.ca> <50BC36AD-E4E2-4FD4-8BF1-B697EA86367C@cs.stanford.edu> In-Reply-To: Date: Thu, 1 Nov 2012 15:58:37 +0800 Message-ID: <03b101cdb806$b3289bf0$1979d3d0$@a-star.edu.sg> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac23veFJC3ysv+bcSmmUurdfEwX5KwARo+eAAAB3BhA= Content-Language: en-sg X-Originating-IP: [10.217.253.130] X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.7.7855, 1.0.431, 0.0.0000 definitions=2012-11-01_02:2012-11-01, 2012-11-01, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=0 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=6.0.2-1203120001 definitions=main-1211010013 Cc: 'JeongGil Ko' , roll@ietf.org Subject: Re: [Roll] Draft Agenda X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Nov 2012 07:52:19 -0000 Sorry, missing a few key words in the last paragraph. MRC> If it's not controversial, then we don't need to discuss it. Since KEMP has not got positive or negative feedback, it seems likes not controversial :) Then, is it time for chairs to raise a consensus call? ;) > -----Original Message----- > From: QIU Ying [mailto:qiuying@i2r.a-star.edu.sg] > Sent: Thursday, November 01, 2012 3:46 PM > To: 'Philip Levis'; 'Michael Richardson' > Cc: 'JeongGil Ko'; 'roll@ietf.org WG' > Subject: RE: [Roll] Draft Agenda > > I support Michael's priority order. But according to the current agenda, > we remain almost half time space for nothing. > > Also agree Philip's point that "the goal of the presentation is to > clearly state the points for discussion". For example, without Tero > presentation on in last Vancouver meeting, which topic was not > discussed in mail list before the meeting, we might not pay much > attention on the progress of IEEE 802.15.9. Tero's slides give a good > discussion point if the ROLL documents should be compatible with IEEE > 802.15.9. Hence, the update of KEMP is the produce of the consideration. > > In personally, I do not like this KMP Information Element format > designed by IEEE 802.15.9 WG. In LLNs, we struggle every bit in > transmission, but the KMP format too complicated with many chian > information in order to flexible. It's the discussion point I would > like to bring to discuss in WG meeting. > > MRC> If it's not, then we don't need to discuss it. > Since KEMP has not got positive or negative feedback, it seems likes > controversial :) So, is it time for chairs to raise a consensus call? ;) > > Regards > Qiu Ying > > > > -----Original Message----- > > From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf > > Of Philip Levis > > Sent: Thursday, November 01, 2012 7:17 AM > > To: Michael Richardson > > Cc: JeongGil Ko; roll@ietf.org WG > > Subject: Re: [Roll] Draft Agenda > > > > On Oct 31, 2012, at 11:39 AM, Michael Richardson wrote: > > > > > > > > Please be aware that among JP and I, I'm the one pushing loudest to > > > restrict our meeting slot time to (in order of priority): > > > > > > 1) things in our charter. > > > 2) things with activity on the mailing list. > > > 3) things with reproduceable problem statements that might need > > > to go into the charter. > > > > > > You may have noticed how incredibly full the IETF meetings are. > > > > > > The Area Directors have been pushing very hard on the WG chairs to > > > make sure that we understand that the IETF sessions are *not* for > > > presentations, but for discussion. > > > > This makes a lot of sense -- the goal of the presentation is to > > clearly state the points for discussion. That being said, it does > seem > > a little weird that drafts which haven't been mentioned on the > mailing > > list are going to be discussed. > > > > > So, again: If there is work that you think has relevance to the > ROLL > > > WG, then please bring it up on the list. > > > If it's not controversial, then we don't need to discuss it. > > > > > > If it's very controversial, then we need to pin down the set of > > > concerns we have with it, so that, next week, when are together, we > > > can focus on the actual issues. We aren't there to watch > powerpoints. > > > > Whether RPL should support mixed mode operation seems pretty > > controversial to me. > > > > Phil > > _______________________________________________ > > Roll mailing list > > Roll@ietf.org > > https://www.ietf.org/mailman/listinfo/roll Institute for Infocomm Research disclaimer: "This email is confidential and may be privileged. If you are not the intended recipient, please delete it and notify us immediately. Please do not copy or use it for any purpose, or disclose its contents to any other person. Thank you." From robert.cragie@gridmerge.com Thu Nov 1 01:29:26 2012 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55D4921F87CE for ; Thu, 1 Nov 2012 01:29:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.734 X-Spam-Level: X-Spam-Status: No, score=-0.734 tagged_above=-999 required=5 tests=[AWL=1.864, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mlY69EXuJ0x1 for ; Thu, 1 Nov 2012 01:29:24 -0700 (PDT) Received: from mail78.extendcp.co.uk (mail78.extendcp.co.uk [79.170.40.78]) by ietfa.amsl.com (Postfix) with ESMTP id 72C3C21F8635 for ; Thu, 1 Nov 2012 01:29:23 -0700 (PDT) Received: from client-86-29-60-219.glfd.adsl.virginmedia.com ([86.29.60.219] helo=[192.168.0.2]) by mail78.extendcp.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.77) id 1TTq9P-0007cE-RU for roll@ietf.org; Thu, 01 Nov 2012 08:29:21 +0000 Message-ID: <50923327.1090500@gridmerge.com> Date: Thu, 01 Nov 2012 08:30:31 +0000 From: Robert Cragie Organization: Gridmerge Ltd. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: roll@ietf.org References: <5091B2A3.1090205@exegin.com> In-Reply-To: <5091B2A3.1090205@exegin.com> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms070205090006030402030604" X-Authenticated-As: robert.cragie@gridmerge.com Subject: Re: [Roll] WG Last Call draft-ietf-roll-trickle-mcast-02 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: robert.cragie@gridmerge.com List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Nov 2012 08:29:26 -0000 This is a cryptographically signed message in MIME format. --------------ms070205090006030402030604 Content-Type: multipart/mixed; boundary="------------000503070407030003080605" This is a multi-part message in MIME format. --------------000503070407030003080605 Content-Type: multipart/alternative; boundary="------------050404010602070707010400" --------------050404010602070707010400 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Hi Dario, Some comments inline. I have also attached some diagrams which hopefully = help to illustrate some of the thought processes we went through when=20 implementing and testing between the ZigBee IP vendors (comments=20 welcome). Apologies in advance for the PDF format but ASCII art would=20 have been difficult :-) Robert On 31/10/2012 11:22 PM, Dario Tedeschi wrote: > Yes, I'd like to try clarify why link-local scope was suggested for=20 > the *outer* header. The reasons were: > > 1. Link-local scope is the only scope where the boundaries are well > defined (i.e. on the link). Higher scopes are not well-defined and > can cover wide domains depending on network configuration and > administration. > I agree and made essentially the same comment re. higher scopes. > > 1. With a higher scope, there is a chance that non-MPL aware routers > may simply forward encapsulated multicast datagrams (MPL HbH > option and all). We wouldn't want MPL datagrams to leak outside of > an MPL domain. > Which is why I think the encapsulation rules do need to be pretty=20 specific. If link-local encapsulation is always used then providing the=20 MPL forwarder rules are clear, the MPL domain is then entirely bounded=20 by the MPL forwarders and there is no question regarding address scope=20 and administration thereof. This cleanly covers Peter's case as well=20 where he wants to forward into another PAN - it would be processed=20 internally as an original non-MPL packet and then be "launched" into the = other PAN using LL encapsulation for that PAN. Using other scopes for=20 the outer header would still work but then there is the issue of=20 administering the scope. However, this would need to be done in the case = where no encapsulation is done anyway. > > 1. A higher scope complicates the forwarding logic that needs to be > implemented in an MPL router. The complication comes when a router > receives an MPL datagram and needs to figure out whether to > decapsulate or not. Granted, the use of an MPL group would > mitigate this problem to a degree, but link-local scope would make > the decision to decapsulate very obvious and simple. > I think it would have to be effectively decapsulated at every=20 router anyway irrespective of the scope of the outer header to see if it = needs to be processed - it is the inner header which counts there and=20 the comments about multicast groups come into play in that discussion.=20 But I agree using link-local makes that decision easy and somewhat=20 clearer > > 1. In conjunction with 3. Link-local scope also makes it easier for > an MPL router to determine if the inner multicast address is one > that a higher layer (or an app) may be interested in. > Agree that the rules are clearer for link-local > > 1. > > > Hopefully I haven't made things more confusing. Perish the thought ;-) > > - Dario > > On 31/10/2012 7:53 AM, Jonathan Hui (johui) wrote: >> Hi Peter, >> >> The current draft does not place any restrictions on the MPL multicast= scope. >> >> If the LLN border router is an MPL forwarder, it can forward MPL multi= cast packets between different MPL multicast scope zones. To be explicit= , if the original multicast packet's destination address has link-local s= cope, the MPL forwarder should not forward the packet again. If the orig= inal multicast packet's destination has a scope larger than the MPL multi= cast scope, then the MPL forwarder needs to forward the packet to other M= PL multicast scope zones (which may or may not involve different interfac= es). >> >> Does that address your question? >> >> -- >> Jonathan Hui >> >> On Oct 31, 2012, at 3:54 AM, peter van der Stok w= rote: >> >>> Hi Jonathan, >>> >>> To be absolutely sure: the MPL multicast scope can be link-local, ULA= or site-local? meaning the LLN border router can be a MPL forwarder? >>> In the latter case the LLN border router can forward link-local multi= cast from one interface to another? >>> >>> Greetings, >>> >>> peter >>> >>> Jonathan Hui (johui) schreef op 2012-10-30 18:27: >>>> Yes, a goal of the current draft is to support both cases (use of >>>> IPv6-in-IPv6 encapsulation or not). >>>> >>>> The intent is as follows: >>>> 1) If the source of the multicast packet is within the MPL forwardin= g >>>> domain and the destination has a scope equal to or smaller than the >>>> MPL multicast scope, then no IPv6-in-IPv6 encapsulation is required.= >>>> 2) If the source of the multicast packet is outside the MPL >>>> forwarding domain or the destination has scope greater than the MPL >>>> multicast scope, then IPv6-in-IPv6 encapsulation is required. When >>>> using IPv6-in-IPv6 encapsulation, then the all MPL forwarders >>>> multicast address with scope =3D MPL multicast scope is used as the >>>> destination address in the outer header. >>>> >>>> As mentioned in my other email, IPv6-in-IPv6 encapsulation is >>>> required if you want to use the IPv6 Destination Address to identify= >>>> MPL forwarding scope zones. >>>> >>>> Of course, this brings up Dario's practical point of how to configur= e >>>> the MPL multicast scope if we allow that to dynamically change. He >>>> proposes a simplifying suggestion of requiring IPv6-in-IPv6 >>>> encapsulation for all non-link-local multicasts. In other words, >>>> setting the MPL multicast scope to link-local. >>>> >>>> Thoughts? >>>> >>>> -- >>>> Jonathan Hui >>>> >>>> On Oct 30, 2012, at 4:46 AM, Don Sturek wrote: >>>> >>>>> Hi Peter, >>>>> >>>>> I still need to read the latest draft so take what I say here with = that in >>>>> mind...... >>>>> >>>>> I was hoping that we could support not using IP in IP tunneling if = the >>>>> scope of the multicast transmission was only within the multi-link = subnet >>>>> managed by the border router. I was hoping that only transmission= >>>>> emanating from outside the multi-link subnet, received at the borde= r >>>>> router, with scope that includes the devices in the multi-link subn= et >>>>> would require IP in IP tunneling (and vice versa in terms of multic= asts >>>>> generated in the multi-link subnet with scope outside). I haven't = yet >>>>> read the draft carefully to know if this is possible. >>>>> >>>>> Don >>>>> >>>>> >>>>> On 10/30/12 1:34 AM, "peter van der Stok" wrot= e: >>>>> >>>>>> Hi Don, >>>>>> >>>>>> and more specifically under which conditions. That gives the >>>>>> possibility to choose the conditions such that the encapsulation i= s not >>>>>> needed. >>>>>> >>>>>> Don Sturek schreef op 2012-10-29 16:56: >>>>>>> Hi Peter, >>>>>>> >>>>>>> I think your suggested changes to the Trickle Multicast draft poi= nt >>>>>>> out >>>>>>> why IP in IP tunneling is needed. >>>>>>> >>>>>>> Don >>>>>>> >>>>>>> >>>>>>> >>>>>>> On 10/29/12 3:44 AM, "peter van der Stok" wr= ote: >>>>>>> >>>>>>>> Dear WG, >>>>>>>> >>>>>>>> >>>>>>>> Attached my suggestions for text modifications including some ni= ts. I >>>>>>>> used the facilities of word to edit and comment text with traces= =2E >>>>>>>> >>>>>>>> When writing text about MC scope and MC domain, I was puzzled by= the >>>>>>>> all MPL forwarders multicast address which removes the possibili= ty to >>>>>>>> address a given multicast group. We expect multiple (possibly >>>>>>>> disjunct) >>>>>>>> MC groups in our wireless networks. >>>>>>>> Also I failed to understand why encapsulation was necessary once= the >>>>>>>> message was received by the seed. >>>>>>>> To make it possible to configure the interface with one MC scope= I >>>>>>>> added the possibility to use Unicast-Prefix-based IPv6 Multicast= >>>>>>>> Addresses (RFC 3306). >>>>>>>> >>>>>>>> >>>>>>>> Probably, I overlooked many aspects which make the suggestions >>>>>>>> impractical, but I hope that the intention is clear. >>>>>>>> >>>>>>>> Peter van der Stok >>>>>>>> >>>>>>>> Michael Richardson schreef op 2012-10-25 23:30: >>>>>>>>> I suggest that you propose specific text to the list to modify = the >>>>>>>>> document. >>>>>>>> _______________________________________________ >>>>>>>> Roll mailing 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 --------------050404010602070707010400 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Dario,

Some comments inline. I have also attached some diagrams which hopefully help to illustrate some of the thought processes we went through when implementing and testing between the ZigBee IP vendors (comments welcome). Apologies in advance for the PDF format but ASCII art would have been difficult :-)

Robert


On 31/10/2012 11:22 PM, Dario Tedeschi= wrote:
Yes, I'd like to try clarify why link-local scope was suggested for the *outer* header. The reasons were:
  1. Link-local scope is the only scope where the boundaries are well defined (i.e. on the link). Higher scopes are not well-defined and can cover wide domains depending on network configuration and administration.
<RCC>I agree and made essentially the same comment re. higher scopes.</RCC>
  1. With a higher scope, there is a chance that non-MPL aware routers may simply forward encapsulated multicast datagrams (MPL HbH option and all). We wouldn't want MPL datagrams to leak outside of an MPL domain.
<RCC>Which is why I think the encapsulation rules do need to be pretty specific. If link-local encapsulation is always used then providing the MPL forwarder rules are clear, the MPL domain is then entirely bounded by the MPL forwarders and there is no question regarding address scope and administration thereof. This cleanly covers Peter's case as well where he wants to forward into another PAN - it would be processed internally as an original non-MPL packet and then be "launched" into the other PAN using LL encapsulation for that PAN. Using other scopes for the outer header would still work but then there is the issue of administering the scope. However, this would need to be done in the case where no encapsulation is done anyway.</RCC>
  1. A higher scope complicates the forwarding logic that needs to be implemented in an MPL router. The complication comes when a router receives an MPL datagram and needs to figure out whether to decapsulate or not. Granted, the use of an MPL group would mitigate this problem to a degree, but link-local scope would make the decision to decapsulate very obvious and simple.
<RCC>I think it would have to be effectively decapsulated at every router anyway irrespective of the scope of the outer header to see if it needs to be processed - it is the inner header which counts there and the comments about multicast groups come into play in that discussion. But I agree using link-local makes that decision easy and somewhat clearer</RCC>
  1. In conjunction with 3. Link-local scope also makes it easier for an MPL router to determine if the inner multicast address is one that a higher layer (or an app) may be interested in.
<RCC>Agree that the rules are clearer for link-local</RCC>

Hopefully I haven't made things more confusing.

<RCC>Perish the thought ;-)</RCC>
<= br> - Dario

On 31/10/2012 7:53 AM, Jonathan Hui (johui) wrote: 
Hi Peter,

The current draft does not place any restrictions on the MPL multicast sc=
ope.

If the LLN border router is an MPL forwarder, it can forward MPL multicas=
t packets between different MPL multicast scope zones.  To be explicit, i=
f the original multicast packet's destination address has link-local scop=
e, the MPL forwarder should not forward the packet again.  If the origina=
l multicast packet's destination has a scope larger than the MPL multicas=
t scope, then the MPL forwarder needs to forward the packet to other MPL =
multicast scope zones (which may or may not involve different interfaces)=
=2E

Does that address your question?

--
Jonathan Hui

On Oct 31, 2012, at 3:54 AM, peter van der Stok <=
;stokcons@xs4all.nl> wrote:


Hi Jonathan,

To be absolutely sure: the MPL multicast scope can be link-local, ULA or =
site-local? meaning the LLN border router can be a MPL forwarder?
In the latter case the LLN border router can forward link-local multicast=
 from one interface to another?

Greetings,

peter

Jonathan Hui (johui) schreef op 2012-10-30 18:27:

Yes, a goal of the current draft is to support=
 both cases (use of
IPv6-in-IPv6 encapsulation or not).

The intent is as follows:
1) If the source of the multicast packet is within the MPL forwarding
domain and the destination has a scope equal to or smaller than the
MPL multicast scope, then no IPv6-in-IPv6 encapsulation is required.
2) If the source of the multicast packet is outside the MPL
forwarding domain or the destination has scope greater than the MPL
multicast scope, then IPv6-in-IPv6 encapsulation is required.  When
using IPv6-in-IPv6 encapsulation, then the all MPL forwarders
multicast address with scope =3D MPL multicast scope is used as the
destination address in the outer header.

As mentioned in my other email, IPv6-in-IPv6 encapsulation is
required if you want to use the IPv6 Destination Address to identify
MPL forwarding scope zones.

Of course, this brings up Dario's practical point of how to configure
the MPL multicast scope if we allow that to dynamically change.  He
proposes a simplifying suggestion of requiring IPv6-in-IPv6
encapsulation for all non-link-local multicasts.  In other words,
setting the MPL multicast scope to link-local.

Thoughts?

--
Jonathan Hui

On Oct 30, 2012, at 4:46 AM, Don Sturek <d.sturek@=
att.net> wrote:


Hi Peter,

I still need to read the latest draft so take what I say here with that i=
n
mind......

I was hoping that we could support not using IP in IP tunneling if the
scope of the multicast transmission was only within the multi-link subnet=

managed by the border router.   I was hoping that only transmission
emanating from outside the multi-link subnet, received at the border
router, with scope that includes the devices in the multi-link subnet
would require IP in IP tunneling (and vice versa in terms of multicasts
generated in the multi-link subnet with scope outside).  I haven't yet
read the draft carefully to know if this is possible.

Don


On 10/30/12 1:34 AM, "peter van der Stok" <stokc=
ons@xs4all.nl> wrote:


Hi Don,

and more specifically under which conditions. That gives the
possibility to choose the conditions such that the encapsulation is not
needed.

Don Sturek schreef op 2012-10-29 16:56:

Hi Peter,

I think your suggested changes to the Trickle Multicast draft point
out
why IP in IP tunneling is needed.

Don



On 10/29/12 3:44 AM, "peter van der Stok" <stokc=
ons@xs4all.nl> wrote:


Dear WG,


Attached my suggestions for text modifications including some nits. I
used the facilities of word to edit and comment text with traces.

When writing text about MC scope and MC domain, I was puzzled by the
all MPL forwarders multicast address which removes the possibility to
address a given multicast group. We expect multiple (possibly
disjunct)
MC groups in our wireless networks.
Also I failed to understand why encapsulation was necessary once the
message was received by the seed.
To make it possible to configure the interface with one MC scope I
added the possibility to use Unicast-Prefix-based IPv6 Multicast
Addresses (RFC 3306).


Probably, I overlooked many aspects which make the suggestions
impractical, but I hope that the intention is clear.

Peter van der Stok

Michael Richardson schreef op 2012-10-25 23:30:

I suggest that you propose specific =
text to the list to modify the
document.

______________________________________=
_________
Roll mailing list
Roll@ietf.org
https://www.ietf.org/mailman/listi=
nfo/roll

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

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




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

--------------050404010602070707010400-- --------------000503070407030003080605 Content-Type: application/pdf; name="HbHTunnelMcast_v7.pdf" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="HbHTunnelMcast_v7.pdf" JVBERi0xLjQKJcOkw7zDtsOfCjIgMCBvYmoKPDwvTGVuZ3RoIDMgMCBSL0ZpbHRlci9GbGF0 ZURlY29kZT4+CnN0cmVhbQp4nNUaXY/bNuxdv8LPBS7Tt2UgCJBr7wb0rdsBexj2tnVFcR6w vvTvjxIpW7RlJe2cYMOhiehQJMVPk6o8qO6r+LuTnYSVG9xBd8GqQ+i+/CF+edP9JVQX/778 KST8oLtRZCTdvdKGuPWVSMRv/O2T+PgGKcMf7H98Edbog+m8HmDTy+/dD89AGlYffz1KJfXp QcmjNKdwlBbXDr6O0ss+fYeTm34ZTvooz+nxIz55G5+8Oz3A7oz+oAnxKS1N2hzpDaffXt6L pxfxQaB4P/2YJP0K/97DaT8L48PBdX2vDunI3h8GguDQCLke1oRXrgnrk/gZyLeoXsafOY2i 5FrDDSGq1iJhdbCA6uDztbuHGLOJTdDgBb2XSwM/R0P0S+spCYZ7cEel4JHSJ+WP9MAkW6GJ yeiP8yMlo5skTOkV2hWJ4y+GdiKGnRyFPoHtmXzBX+sLq+PT2mqIlsn6HNq0VknzEm7JZxSc aw1fmWHpChDRpuUKO8pRuELvE28HGHdzhs0M4HICkJgB9K7OMSmln1SS1joc/OwOHGqYkFO9 jD/zGkXJt+oeg0ruYRI2OYjuU+6+hyRFOVBD5G0UYKwcJJoGzTik9dLSysESnATMrfzJDNmc uNPRzpz8KUXoa+05nSA5OZ2BIGUBY7IihxBTNGxKlLlHNMIt0R8F513D15DvB7Br/JzsqjRA DbvuLE1ZB0zi3wMGty1Ed7SQJoMUUXxt9JfBLzdLQSR4gzJQ1QBBUqY0S5gcQsyWZxBl7lcN WyT6o+C8q/RVfDMrC4IfwqFv+cXOspRFoQfOvTSAcT+/4FXB5Zxy66pQ1QpCPviUcRGTQ4TZ 8hWizD1t2z5IfxScd5W+W748+GBTVriXLEV90JH7AL9f6ylzdUgok7dorAiS7Kr6iBgdgfJF tvZ1drVSH+aXQYSyXU0IRT3gEGE27JopM/yGLpH+KDjv7epgoOLO1cEE36wOe0tTZAHIP6Ez 8CZSrw6F4VKUy/9K+q8fkaDeFgl/ASFmw/SZMnechrIT/VFw3tvp3ygMOzJ9j69w95KmfDGI BSCWgXoB+E7TF+1ASuRTetfF5vmxopyv9/aPqh4I8rJI8gsIMVv+QZS5dzUskuiPgvPeTvkL /3ChmfT3lqacEcWmwHizkfaXOX2R0ud3/XVOhxNJ8Po0zTIqDrl0GNIMRMPbqiPotUPIwLtr 6tashKccIkxGhSZeW+5xE35r9ekhHlEPZXgFVF9QoB5/VMMJPs4beol1Qs1yal/wQyhLxqVm J2JU2nq5Db+KXmx06LVejurx9PK55iAhlrssGDPDwkRWuxU0GaygcsFBbsKvkn99VEHVQTQE keIxs1AivD6Erh8MxPByL8QbhKVRb+VZDlNShkdnSJ9QguQThKvnORjSLzzxzRD1yhUhg1A2 Pw4xsn4WEGIyKteE6N78tkLUa/OvQnSSMwXJJCdCJBmXmp2IUbkmRPfmtxWia71cCNEsGDPD wkQYJAsoG6ygck2I7s1vK0SrDlIJUQUKsV3kDrsVvFjbSUTVy0LnBGXrcMuVVmVU2iq5Db+1 SlSIOafmG04+T97BVWFVYS2lTMGCIBKGC8oOwahcUMVN+FVUoWXEqKaPlDyCGtS7Df8IbpLQ +YIRAlkiLi07SZgjuqWMffmsldDXneFpcoXaxaORZnXxmArXdPEYq1dxK4GjhKKnpOrlsbV4 LNuT1LA4CFB/MgncqKEoSqzQq1sRbDqQHU6scI3Xl7pN0dpVK/089z/nst3JF6Hl9aos7lfZ yJ0aogvnsWbdyl8xdfuWy1iXphW5hXA0uyCox9kEYXIIMRutVabM8BvNDNIfBeddv2uJJdC6 MDVWju5Z7yXLcubiegcY/6uZS/2IBLnySm0B9ZfGbZkyd5uGsl15LZS51cdt8ZLN+jwaTaZ3 rZH73rKUho+9tPPra7aF4bdn6rJ208ryxkZox4c7eoLL07ee1njN6qxN/9WBsDjktmdXnOpl /JnXKEq+9ambjoF/KELftmdue8pR5mcPCcfZHjAW1t+8QdXzBSpa9dtvUGfxknuSgAQZie/M iMkhxGwFLVHmxm4ESqI/Cs67PghLc243kBmS0XT7pmxvaUrDRc7OVN5ZVvlaz28Li7sNWRmE sTdCbEegfk8tTVznhsam2WBuYRYQ4k3722+E+/LZapqsWU8mLrRM2LCjYNiyIkNakyhcTHaA af8FBezKpzZWqCmg0SBhR04CpX6MBMI1icDFY4JP+9sH35dP5eDGpt9Xli+nKVo2O2aUDlsx 5ErrLA+XtTjFvL+thX35VNrCQaffl+afW6IP3T9NHpR7CmVuZHN0cmVhbQplbmRvYmoKCjMg MCBvYmoKMTc0NAplbmRvYmoKCjUgMCBvYmoKPDwvTGVuZ3RoIDYgMCBSL0ZpbHRlci9GbGF0 ZURlY29kZT4+CnN0cmVhbQp4nO1bTY8jtxG961f02cAq/GYTGAiYGY8D+OZ4gRyCnJQ4QbAb IL7476fqvSK7JXE046MXg4V3ye5ifbPIrie7o19+O/xvcYuTUW75GJY1+eO6/PrPw1+/W/57 8Iv++fVfBycvwvL10InC8sUW6NIvxkL/5bt/H375Tla7Y5L/gnJoTf4tuR6rsGnlWGzSktCU vB7j0oLwKLnJu/OytmNbSvHLuurCEuTpWvAsiYbnw5qVR6myZs0yaMJBB9UL0ZnDdMwL6WoR WVxf8RpcV6+LIGkN8jc1WJO8Ox+omSzPC/WV5X6hHRieF+/UW5x516m9K8K2s/FuxWLl770b Yr33x2zaeB+UD5T0Pqpc6N7HMOlgM1hqK2C+caJfugw4zGQX33Wicw/QFT43CxiKLUTn/cTC 6TTKy1/+jIz5Tf77UXLjPx+B/WMH9ufDTwcna51QY6uHUMbCrzJLgzyEYMyDbzLvEQ2+Qn0v owzlVcXg06b8IYiJwcwKPkD5Bk4YW2z7TFfaCrjOeKlLDyZDXB265FVdZjpJcDSA0FWClhaz YBWNaNmqjgqhYaU8jR5hBG2MSBnjEQuyBtxjBXdIja3rkpw6nzrKuHXdbWxWcUZ7uYJ+iFvS G396jnLVn9Sn+5maMgLU3+KyRex8Eb/7O/cj0t9WpHUr4zSXP7KRnz4ffNTiVJvy/vyP5U8/ SL1Yl8+//O3BBykQyUX36Ir8eTnlBxfk2XPwp/Lg3emTPEgydNlH/edZn3h9EgJePsvSoG+i Sy7roLjqVi5qIHnU4ZNQZj6NXhe1098//3h4+XyjbdTAJKlP/kpZ9wPY1UvO3plS0O+RIp7c oz4XBzooK7o9uchBscVl2CPq0nJR7NmtXKH2rDItoq9Z9ijBfJZJdY38ryzaeccF4VNPvpoI +jPRF0We3TW+rreRSsLycQtBJD/VK2RGIhQSaDRfAtz0otHc7Axc9LRj5J7otmhhZvjUG0mt VF1lFCyEYvTjVaSvSc0LEBGq+kn94B/eslmyvF4HPKiy1E9iSZZh+BjKPFseVj5ou1TQCClN iCOXRzL0CJeh7y5hn28SorvnJiGyhSPLTiqnhMVM0yycX3ouvGF7XKWGXNleXdl2Ds2S7FPZ ZNn2Fqleuee6JCWDnnYqSJIMFXYHgZa63w77e8jXg5ebUbTZl+XnsUBvBbvqrYQRVVrr05fF ZkWvSF8u6vzt+UOx+6r59RAdKuJMbAxlR8ZbHoXazIRudK+JjHmz7eshiftfsTRl2tYJcVk0 oTYzoXvKd1oq7tYvrSbvJpZm3GOVTNzhEthGt+JLq5mVpLlvZedDK/uKiZUbodqVJY6blXl1 Oyvvi73Mjn7qF3DjqXRBV/SyOeiyfkZO6ZKehoMupTmV7KG0UcUIrWfJ61WQEkpAYKIkq2RR 2GY7ujdMHbyyHuDBTUyoSheMLuj3cYkTukC1Ox34pRkd+CWji+CXJ3Rxc+pXzFbMyo1TLjJT 7xJ13CWC+FTZK/M9XXfK/nshQtl+i4yxji/AyE2GW0yMcfcNGKPD7dFLSrfxURPFxO2eJMk+ vgOxvXGr2jb62cZ6CzNa3M6MC25txh13OZOJO55pY7c/0xP3QtNfbotmF+6QMQW7T8aUO2Wq eG88JFdz5549uENqDqgf0EZ2Uu1aWjmC9rvSdO4zWssV9AE5de9QBv1G2epN6tS9rLrS+9Sf UdnF63wRvftfCx9x/pbivC8ZF4dsmFduPmfdxnhStfHcajbH1xUbT61eczyp1nhh9TVGOMPq c/QNtdJm4a1afcEp6FVrVqlj9KNORyg0q9MxblU64to2q9Ix+VGjYwKvSY2OaavQMkZgJhX6 8sqiEfQjgpoX2Sr0nu71Cp1rYPSQ+ZxxR+QasSNwN5FMrWPn5lps5+Zax87NtR3b2Ll5DbZz 85ps5/K2cLZxGzs3Nz92bm5p7Nzcyti5uelb0wbNqrFznd5IbOc63ReW1RiP3WtvcqfHXhmc sIdMBvaWycauM52wG01Xu1C1sX+HbTZLY/+aJ8ip+4gy6D3KVp9Sp+7rlHsMYIHFZhe180UM 31OnP6L9LUX7uobmtVoFzXL6zKpsrnnU6lwnJUifyxnTa3XObUaBu79RpHVSovRF1EZXr9U5 tV2tHrNBd69WD06o1RlpcFurc+ry8GGSZlSqeqcCr9lxJbU6F7er1bnMqLoDe63W2Su12uKC Sq3R2yp1LnVUaqUyN1z2BIIc82GpSTdGbwqk0QHz2hpop08rOhynTwGNHI/PfhdPn8qDf9a/ 0WJTKrzVLsn64JOsSA9hPcnzZKufhPLp9Q6FaRPytS4mzWSSszB6wUM0EaFWo2Cdyb9ZiLzo In+XU8ymnWmi3SSvipdJryI03U7V22dezYa6MOrb9wxuUuN7puKqsDJUoQbe/HS8o5tGATeY 4uKV2d7DqUG7cTQZhs29f6/rBf6SA8drCQgIXZu0H4eRuSYZV4nY6VOdxfYtgdUfbyKZ6X/f I4pmMEYvKtRiufZYan/xTkuLcnK+yV6L8oVxMIyzYRmFqVWeVjHH74rDXrsUdzflu2GTRPM5 47wLxEMcz5dqzZNXugkezZziPboJ2rPRzk2YdxNuEXFJ5w6b6hDQJFMckGWoPH4AZYaq2CYA Tk3vlbBnwDlksGnAASV5HlZliQGPQh02hQRJJ0cfV+M8NNg0NK2VkBWd+hU6RKdHjMGm0al3 oG902i6CFRx22JQzhSJJTYiysyF0Sf6ENCmWYGfXhzCoqskWJXW3MU069JkqY/Qw3zjRL10G HEbZ9CO1MgcDOKXfaQOC0QN03obvwMI/QvrHC+krKDhDSVxRx4o1kiUxyB5LopNUgqgllSOa KWoPXJTmsDSomXmMG5FIznAbtRVA74wTXWnIqDo5mWxxvumkQYmGizJY1F9DGAxB5Lhjo/YG mKOtABo5OAGlhARglyY3tk0fXMlMU/QLzQKOu202K4abxu6N2LqPyJ++g1TzKfQZ3oamFgdY wNj0iJ130XsPAv4R5W8hyrfo96rtNLls3EBscg/NF7jgDAb37i38O3Qw8nsixqHJpSYQtbxC xjf8egKQh0cCysCp/QaivoGUaxW8Bk790w4I32HkhoTKRe8KAi0GggITryF2/Ts4qijvBQq6 UcfNf5kI7RyOHl69haMN4SVP0n0vzCD0PdhxczexvYCJ5fIXAm5/4o8d7J+G/vQ5CW71bPr5 YhBvbA9AlQ35BuotEVdQ/Xt98CJXY3Cwnxn0/GGkX+jHoGlD7zx28yX+8rI7by/tru1Vr5LT 30nkqdgZrLxZukeXZQFMfB7c8Axsk2yOiVnvAJl5xHeQmbMpTrcRRhRDdkZttrIlsqe8D712 boRepYzOWhh6cfcGvCog5w14DVjE9gVp7sOCXVifxdEouKKrG/6p36ZzZDOUssNJQ/G3YB/f yHdL3eiyO94Yaa9iQDtHEdCQPT+NgYCO2Y7u9VYyD0y25nTMhh1LNVt5vYizycfyzuYfyz6b gjwO2CwMo53Io4MjHikYWzMRtDiCjIcdTsYdhxal6lFGbfoRRz15+FF7Hoq0qh+XbMv1N7nT o4k3OKG5Bwlo+ZlcNAOHRmgTmq5o/IRdk3HYZjPYzBXWZAQveogy6DlINo9Cp+HrlHsMYAEi M+J13sXuPQ3kjxj/8WN83c4dtTDMixOe1942nhUmPLeyxPFtUcJzK0kcTwoSXlg5YuO4lyA2 jscsvF2OfHMjVXXMFJDRSFXf/C5V9SjpqaqnUU8z3yqRBSSgNnaSVX7cmccZYMnqcMdmsrqR qt7vU9VHYBjYIPipiG0dX/TDuW8qX0eyBk8cF2HEuCdrf5M7PROjc2LKUAZTibKZYl0rJp8b yUobbJz2yUqbQW+eAKfhI8gw70G2eRVaDX+n3OMAGxCdEbPzLn7vKUkfcf424nxTLNAwZbHw bZ2WJZHaKeSzLs8o1u0XDL7Of8HgqxtlyZd8nP4Kz6e6K0u+lF1ZGrNBdwfIoSevWuGAQPRb 7w2w5lPorWv7DesOsFH6AcL469624gNo3N/FdWIsu69HwwN2kI1XyEaxgXAKCtmE+rshm4gf qSkWgytma3PIZlyaV4dTtoIsVJ7qvIzvKV8HbbR9cm3T73H4G1iD5mb7/RDKDGnAj/l63sse lK+Onvev3Nk9+5V2FAZ2NMP+d4uXx+T9DxT+5Hb6EXZxUXBsKPMTzGb4H56+LBvdPUi3c+JP UacC+QPTjRD98mY/seXMvvr2lHeFmmNNqH24zYTad5+J8W4nVCtg3YTuv/5+Wv4PidVRYwpl bmRzdHJlYW0KZW5kb2JqCgo2IDAgb2JqCjMyMjEKZW5kb2JqCgo4IDAgb2JqCjw8L0xlbmd0 aCA5IDAgUi9GaWx0ZXIvRmxhdGVEZWNvZGU+PgpzdHJlYW0KeJztXUtvZLtx3utX9NrAKHw/ AEHAjGYmgHeOB8jCyKoTJzCuAtib+/fD7/uK59HqVvd1NIsrCNfuIc8h68lTJKuKlLv3h1/v /n5wBzdKuef7cGjJ37fDP/7r7t//cPjfO3/Af//47zs3XoTD891sFA6/WAd0/cVA4F+9+5+7 v/7hzt2X8bgJQihhtC7Oj3bPdyG3+2i1kDNLfZT86FJcHOXjIaTGHhlvUh6AikOvkCLK3t/X w/EukODiMyAlN9oW3+7TLIcwehyXWhkQrUfo93nCigEY7wxLLMRC7LGNJ0bXgFEBC/SmMMrG xYBRDsYfywNSKYOe+aYPeqxHDcAwIdWy4qgNOIS7OZaNqhZQE70tjl/jw8rGoWriXT0kE8Ga 0hIWyVHYJV/RNSUviqUTcSJNbXR43Gl0ahwD4fBv/8pB9ev4/x+H8v/2oft3r/s/3/1JhmT8 Nz72Lz+GlonB4/fHfx7+5fuwJO3w468P4cvjj7/dffsxeuwMhO9+EJaju4eh8a0OMlTzLcE+ RSDzDeLLEWz7Wtkjj1Ia5OaIPr5CdDkB8PHO19EzJUCptHKp3udZHqpNhKNaZm+U2sBhcAaj nnCIoWT2Jt5SxxOjZwgNwjNKKwaZcVCheuON5QFrGM64vIFS1CO4sEAKDtQIR3B1vBXu4DrL oipQtaI3eCheXMyy+LMaObcelIjBMkkZFsrQsMcsmiRtUSotiANpZ6O3406LrxuFD32/R32/ NAS+sW/C784Q+G+LIfDDDKQDYIw+sYHMWjVbxAYbpVocti2PcjjE2ke9VrAbax4s1lpGKQ4k tcIOxgrCavNkNtKq1YYVSywNUBp+rdwDBTdrsMPWo/f7YrCai4BEHM0V4gDm5mDDRVHzFK5R 2jwsqzhoPo624k3lAavjX3vTq7VPDsKYkJLDLCUcycGaCndyjWXQlDwGtGhN3hsHKokzlsmx taUkBGPKSNAlPWGFTEWNSbpXSZ90T52s2jrudPf65/+h5fej5ZcffWyE3MrpRx+ezn/0PjiQ nTKHgx/LhmI1PwQ3mEjl4Gm/UoLAvMST3SjhXwjAD9uVctY84CCAlPvo2/GTCnRlxUJxqTIm g3iw5hVrNoKpNNwA3RxBE13DFGFkDNNPQkTe4HRMASJ7TATD0IshlgekkNhfb/BrPWheF1gx sQ+xjNVgn9jHKrFPmriaNUoTjLtxoLKxNmvg2XpQFAZpCkk4JDzhhkBFk8QsWiF8cSCVbJR1 3KnuypT/oeT3ouQz87wfPYt7Mcuvy/2/H2D4fh0rj6K1DjaDpAiuhDzgAuoCM6TKnQjs2WgY YKlzx+8vhxAbuznVNi1fjkBDOhZxYy8TsegZ843D8q4UqPIEbfQV26Ta2TAMhHXUhCi6xm6e 3bYtz7k8oucqr0AzAxI3aar9Ylu20DrXTTE5bup2NbXcQbkypf4UfGe2dt2xBWSx1fVfHnzz 7fFTefD9cfx8fvyPH388s9Mbm2huKI3OUDb4rGaU7anecbSDcsX98FPwnZFLatzyn8pl+w3s B0ijX8AI26nhREUp5Je1qbANlGtrrp+B78zsX7BhOjtAgq+P3j+4L+vY2K8DOp0YRqJ2ahOV 1aZ29prbanUH5dou9GfgO7cLinSovBwb2X2/sCSieV9IG1PQisJqRsye0B0TOyhXRPFT8J0R RXBscc580Hi0san8emF8tLxQmMsGkSqToj21O07a+kW/Joy3xfNSCPX8YPh2wVDIJtPBt1h2 1hYrlUDY8hnva2q5g3LTTPLG+C7OJAHrgf/HTDLp1Dc56VTNKNtTveNoB+WmmeSN8V2cSV7I 5dpMYoTt1HCiIrPl+9pU2AbKTTPJG+O7OJOcGyA3ziRGohkpQ2W1qZ295rZa3UG5aSZ5Y3wX Z5IzY+PaTDJJk52apKlmxOwJ3TGxg3LTTPLG+C7OJGfNx00ziVEoo26IVJkU7andcdLWL/ra TPJ2eM7PJC8Hw8UoC4Xqa95M8qotaF3aTuu7mrXcQbllKLw1vktDQd/GxaFwaRppeaGQWpmI pKJJ0Z7aHScLgKtD4Q3xnBkK2AC/lMHFWUOBgkU5W5GfqMOmrF1tUrKFcmX6/Cn4zgyGXhlG OjMYzswa00MQE3pVek7HnFaxeKs58Yvcewhqp4PatlElsSHXPwyr1uxZXluZWJBMAQuE77BU +qX6mN6GKEqmZwo1X+B6TvQq+OLpK5KT2OdOnxJCsz7Tzdvgl/K50u8EOo53PsuLRc9TzvQv cVyo3DECjkuNMSn16PD9GKxeFN0Rlt4m7i4KQVV2jsFn0ZsdYk/iA2XQDg5VHpBKX2qMuak9 Q88LpJrgWROOKvrQmv6rSVGtrJFWObHFg5WNO9XEt3pIHoI1JSUckqFwS7akapF69Ys2+qKz rf6OO21esYcfen/Hej9jipgoAcz5ZIL+ulmrLWYhOmf5Htxg9MYsD9RCxySB8pjvO72XEabl OGqRns2xru6ez8GYtlYlZmaR9HvltsiBEZl3UmZ5ZqRYLdgOF7kqINsgpUKWDcfYoPiJOYk+ 0pTByHFSy4C0cZHRz/hj+Ti4DUsNHtlkPSJjVBNWdM1wRCcKgTt6x7KowlYzGr3adoqPWRaH ViPv1oMyMViUleGgDIk5hkmPydsopSaMgyDqVt0dd5q8spf60Pk71fk5h0dmdtdLc+DOmYMQ G7M9GACJxcqImQybmsegiIjq5OIg/gjkuTBZK3RmrOBtCI3lpAySoFyWYvtOZJzUpdxp+axW mQKm9oxEGaSayazhqLCAhruKOtLE1c9x0spENHLQ/IFcNVKTmImDZwnYrF1C4HmBkBAbMtjc IBnOxPyVSU1qrJHOJMpIv8qTM6uRZ/WAJARpSkg4JDvhlkxFlWQtaqEBcWB6mdo6bjR3ZUn8 oeF3oeEzn3oEHYC434udn/fJZPVdWwpluLCGrJSxjQhoGMlkDUrzikwWqyEwwwUs1cAckwIb U0MmmdieoFaZ7QIB1IAcFitHj+XVUqMFVI+YJyTaS0AiDllS4Y6kUFQls5Sil+IzPhIEbRyy jPyautSwUQqzxxgoC6SG5ZjhaKKPuFtm2ahqhbVBbSukljxY2bhTTXyrveQhSFNSwiEZCrdk C5qmzEWrtCEeTEur/o47bV6Z+z/0/o71fsafzUSCgflk9v921igwK81FrgsjsjlViUjsiMzX jumgVIZBYuDqBT24SKEF7WypTHJb9GA5CBnQi2LFZItBVhThYmvaPMIITmsuwg7IRhW+QILG /5g5cjTaQqacQHHAXkucsIg8NgialcTebJ2YtGdQUjXIiSQRn1aDRgeXiaIvkyRSbUVxYxWm wqo1eJ9rStBB2E47OEpONJg8RRulLIol+1Unx23ldcffhyZ/X5o88+EmNmg3buM7E0HMQViX LBLKNBQvSYdiCamB2RWiEiuaAr6pLZzAyFPnCBhH6TZYBJ7FQGNnFSZ661BJMRi1ymISdpUC 2cpp3AV6P0zjgYlporktclLRNK5KUuwbrZOSRQQlVYOcRBDTVblbNDqoQ1CXRRCXjyqKE6tw 2cW25FswTB6CTTkBH2UnKkymoo6S3iQkbPRy3CrpyiT9oc3fnTYvfMED403LcQKb0e26xO4l U99M0pr2Tf5Bxpo7qjAtdghp0XfI02Jjy1VmsdNzqUr002KP3cO02CFmukAFO9ZpsZEDGUlH 7KvFxnbFLLYOvokXra1M48oVVcTRLbI2KNAAIUsrxCdtGR3SIumTbkm1isaNVeq02OJdUCgR waacgC+4ZdyZTNOMgJrNNvmvejlulXTL9/uhzd+TNi99vyHe5jkjuBlpjDoDlqfNRjiAsvZc ypvOFTygXnzt02b75lebjZCi2WyPsLwKkOlxVvq02L5TbITRdRBMsDsdlsTYucYadPSy2mxE L81mKxtEvPS22mxVKFW1prQnlFQNMvUifNTWpINaFH3Urai2orixSpbGxbdgmDwEm3JKSxiG VJhMRV3VGZUl2L3Ry3GrpBu+4A9t/q60eeELHhgv7n1PlF4SPSDJ7DYOIFTf6Kmg58HRj19w Bro0nsfKOGJRSud4gHQKXYCRe3ucli7UG1rlXrjiSXRrAkbIdB2mrC1UxH4h+86MJBhNHf8s OKJBfj2dhik3HsTQSZYhI+JKVDhOsHBzREPah94CTGCDuZb1bZGnMKCExn4ZK7DuaUk9rW9v DMBScdz4ZP76AGXlqOMijY5LBjSZVZpbtcEyZOPtZLcHFYiLYDKBhwMHGbCYAq2l2SlxniWr zlu8pA+ZJ27ounlGMKCQKwE/ixsy52m66OiBWjV23OlvOyA2zm8HinOHsxZHgDNPoUcGXPso dwapGWPyjXg9vUI4A58pgRlL8UHn7zGWvSfXmcdiPE/vZ/TSIZ5SKg/0ECpXqzraUiqO4/gh B3mqpNPS+A3nNEoKJDt7ynAzpVwa8IEXTyli9YCVaqnZHMWks7oxwrDELWXeDIBoWTZzk6gb 7tgt0seRu8SaaHEUswqOW3ppNs2oFuNVR8bLKs7JcPuLaz24h+ic4Lsd/W2RIyRxXQ6XPb+F HG3kaPwzLNC6cZN7YEbOqrHjTn9Tw/tssxKXwCYyCbzVfNZlCzzTxJNJJWq34FOnSodaUrnX pQg4AyXxOCqGIpFBoi2S2KycFfabNZoc9cj8gAWpeMXvhYM7D2IusJdGUekacqK1+oNxwKgD OaveDEHhYFIOAdIL2ZqRigVKrRN65QULwtk4UCY13IkZnU2DWCZTZeNMNfGsHpKFYElGwiHZ AbMkKoqmpEWpdCAOpJtFZ8eN/q5ltXzo+f3o+UwWS64WaN9N3c7vpu5N7ItZL1iIrAl4gQl4 4fvjp/DgPj9+8g9uWCj+m/lbXOW/jS30pj9aY4eUPTx5evyU59vA383zEPDrEzt499geQnuc zVm31icgw+xjIJ8WMCLBx00vwREdYXmOhqCgPfpkXb3zTwTuvpGlsDZTF1GIx2myFN2lJNUY o41KHmAMXePPnLQYl0x+YOgCE5uSHzSSC9MimJ7BA+zyrBYeX8e0wqUSD7BbugSXkFZmwseS SNHrQe0rs7cEqTo76k4c1XFXS9zVda6PeaTfc7Fp9FYf+YaBFY9FgjhUecAaSxt7nhzDYmzP GO0CKdUVR2K+pXBnBqMmVTmyRnozEznAhZWMO9XEN9ubPAhpkRRxmAyJ22RLqhapk17TR6xT Sxv9HXfavLL3+dD7O9b7mV1S0BKznib0h3I+izs53tc0BkfiAXeUo3KxmHaJexwiV9a6s0Jr a+5VG1f+vB8CMdHMu6K4R2qcQnw+6IwO1t9xlkOw6KpqhdHVeD/vqTJIdoOV4eDdVoY7Yrdi VM0sLdHLCdy44GqevNm6PjlMmPbcY51t7b0tGggp+WYYEqO1wpzCXHzQbxY4tZJanUgSF7Ms /qxGzq2HzxOSyclwUILETLkaRSZxo5W6MB6GhqbWjov+XjcDH1p+P1o+89F3ys+Dvv1n//3C R1/pxLDMscRTBqqlQkctnRmpMByjdSdvZ2h0E0S4LbCpK5lOB93HwBXsXcq8kaHC8qUc6R4h u1buUoBqHBDWo+meCcLqCu4aFl4kY9iZz210dW3qRXGx2zncFB05NOHVpoHOezP8bMshuEBp dHwIvm6lEl4OwYUiXlpptPbC3DTyoPLkzmryc7OH5CFYU1LCIhkKu2TbZk4ZpU6KTR/kw/S0 0eBxp88rhuBD8+9a8y+NQyrKdgS1++Blu+A6xX1s2fA/32U6PnGbzKCAzqLEZK1E92CqmV5m nv9gDmaiuwwnJ+DIpB7t2sfkC52i4DL2xtvhOhOiwFsk1zFXjqJEZ3gwFxRyTZgS7qutGKlj OiOVuVFyZwYG9uCcLJRMrb50g8Hh25n9gTVlvlcSOOhD8lbhmrIyrQuYlfqlCzIjXW5wHmM6 9FxtOk5CXDXbGZNh/unAw/VDYxrg/XupaAKjD3y5dJNnYzhamQnrAzmWky5zksmZkorgJzMA lxl7y0EJ7pmhuqz+CtDRxbvV3HGnxwsTh4JqBcH4/VG36B5DHVvMsfkc+804tqLNfXZP7uvY Zpexy7aNqN66NLbffWxWN6fizqCh13ePxn3xyX3lJtt9G1vc85vXBJ93Q+9hsph9p1qSuHVn 2XKUR4HLzCM+GJQcvh0DJtFfCeFTYYVXFNJXnZjym5nyM8tNM7NqunVNPTjPChY8/PoMmV8U mAExcOeQ7bMdSmHW4NGozdy6iAsoCLx0K8E08BpJPefAsva8t21Cyi4ahqyrF4k3O14haRRl xxuPSGum51c8WNm4mzVeV6kelIdgTUkJi2QI3CZZ3SU3JS4DKl2Qi6mjWTpu9HhlkvrQ9zvU 95mpqQUasZPNarzkGIwMkeUwzUiYfkHnzUUWtm7BS9ZIgTawSihDHuPBaw7JyFASZ4a9P9J/ AV5z9RX5G59Ww1hUicHnx/bgw+On8VvQOEZ4Adlv52OUZy8mePYyAcmZGKaDbxjijb/QkH21 7nVxLYa4cS2qUd04PeVRnJLaEd43zsunx+Jwq8yrguRU/JsE6TGtvuLYNXq2bs+04Rmi9VsX 7pQ4mpfVu1rs0eIFni/aCmCIqU7oeByn0MOUxEaQUz3mc/U7nZ1x6X4+dTDbk/DCfe22/ut8 yu46xLb8blzcUnnHoPlKaOHzKoap48247CuTXzEmXwwfI3Tz8oweNmxPicAjbaSq7xxTJ05w 4g5f0CSU14cXT/z+luHVt/ciaXTFwi9PhNXVmx+35Li09ep/2em2jP8+L3IMNm6MpY18gsfi 6PNO4nk3gJ7WQeU34YuQVpVsx3046RyW8XLJHoSTIMU/FyUJu0G+j1pki06sIYcpIg6ujSBO oy37mMkqBDfJ28h2o6xd6OPyIhOjgzuovfKJ0i1BI3Fi7H7dfJHu4YXZmVysg+NFzGgH7jfI eiHraZV+qI++LtrefI4n4+U1AdQlzHbj51LD6Zw21g1jkop96u/7ZhivEjpjkeLuWV/EM3Xc NnPijbE293B+UAnTDH5tQ3D1RM7zmzMGXn42r0mTOTq/RZq5bbY4NrWVzdT2dQ6klavFUKyf 7RxJ7uVQystQPBlKp9PCtAahB0dZfd4N5LK1NRfWLUL3eZEbR2i7oJHVyLt1agjLaPJb2zR1 tZ1fDOiF6CWjSPMIjO5Ds/MWdjtajIqJ6Pqwk5qdzNhCueUGu7fGd+kGu8i41D9/g91CJ8/l LnSqZpTtqd5xtINyyw12b43v0g12L+Vy5Qa75YzUVg0nKpLH/qQ2FbaBcssNdm+N79INdmcH yG032E0SdUHSRGW1qZ295rZa3UG55Qa7t8Z36Qa7c2Pjyg12C2k+blBYzYjZE7pjYgfllmvL 3hrfpWvLzpuPW26wmxTyBrGJSJVJ0Z7aHSdt/aKvXFv2hnguXFv2uqmYd3T5KP+RZya45/H6 zPzNkzu6fNVfNEl0QeE+IzhmInOTkSLr6cWWytaWp4Oi604S5FE+47J2pg104iLzmfkBz5ar DW9z3bzM8NQ884qBwDPM255MZH7mOSsdlW58WXQV0pA1Mjzv0+ZVLXSIiZjIewvWl90xnMMM +UOsSGqozDvFS+94tEp3nzPy2nheWvSMMTisGoCmgHxOZOwGvYn6KxGVfCC/uVhqBt9mHj5j HvUzPG2H6uZtaZ4u68gQwrP5mJRygbe41y0jbDDeZWZxF7tC6c92fUWkD2+8DcxtZZ4y3+Zk Gd/P+HM19/MvcPFdwzve3nbIvAaihHmtfKRXbXlbFM9N821SVvl8q8sxmuGMzAHWmfjlbZo3 x0OqgefUO99meuyiQX65KKkTzx0OvDWrhcAwR2n3+vNHitTzGiqLkEfz1ETOQPHQdchGd/wX XQRWGJTi6KIjUqNQKTM2XpULxIUxOCCUwoyWJXG6VuZSMtZBh6EIqr4yYC5SawTxYkGjUMyp jNybttQi/5KQeqTYmdMjWLg5qxsWODO9Yc9RuZ+iC7EUbwSb+Jtu8GB5YZA1cc4eJhDCmpIS lmTOXsa5nM4/8tCACV0USx3iRGraKvC4U+cF96iWSavXMSzuDC3dx9anj7U21tbYZXK3PjcP AUGap7HE5i7aM2RjffAemwoD8MReY8+FPt/Gkt5P4OGRK3/tJ0b9G58EOVufQhh9tJinIwk7 AZ/xBH7Yseinm1N7h4DtXbIiuxndgBtBH9v7zWLmT4f/A0R5c48KZW5kc3RyZWFtCmVuZG9i agoKOSAwIG9iago2MTU4CmVuZG9iagoKMTEgMCBvYmoKPDwvTGVuZ3RoIDEyIDAgUi9GaWx0 ZXIvRmxhdGVEZWNvZGU+PgpzdHJlYW0KeJztXcuOXDly3ddX5HoAlfl+AEIBUkkyMLvxCPBi 4FXaY2PQMjCz6d83zznB+8i6WVk9Li26UFB3iryXjCdvkIwIUu7en369+/vJndwo5Z7vw6kl f99O//ivu3//w+l/7/wJf/7x33duvAinH3ezUTj9Yh3Q9RcDgb/17n/u/vqHO3dfxuMmCKGE 0bo4P9r9uAu53UerhZxZ6qPkR5fi4iifTyE19sh4k/IAVBx6hRRR9v6+ns53gQQXnwEpudG2 +HafZjmE0eO81MqAaD1Cv88TVgzAeGdYYiEWYo9tPDG6BowKWKA3hVE2LgaMcjL+WB6QShn0 zDd90GM9agCGCamWFUdtwCHczbFsVLWAmuhtcfwaH1Y2DlUT7+ohmQjWlJawSI7CLvmKril5 USydiBNpaqPD806jU+MYCKd/+1cOql/H/38cyv/bu+7fvO7/fPcnGZLxZ3zsn78PLRODx+/3 /zz9y7dhSdrp+18/hs8P3/929/X76LEzEL77QViO7h6Gxrc6yFDNtwT7FIHMN4gvR7Dta2WP PEppkJsj+vgK0eUEwOc7X0fPlACl0sqlep9neag2EY5qmb1RagOHwRmMesIhhpLZm3hLHU+M niE0CM8orRhkxkGF6o03lgesYTjj8gZKUY/gwgIpOFAjHMHV8Va4g+ssi6pA1Yre4KF4cTHL 4s9q5Nx6UCIGyyRlWChDwx6zaJK0Ram0IA6knY3ezjstPm8U3vX9FvX91BD4xr4JvztD4L8u hsAPM5BOgDH6xAYya9VsERtslGpx2LY8yuEUax/1WsFurHmwWGsZpTiQ1Ao7GCsIq82T2Uir VhtWLLE0QGn4tXIPFNyswQ5bj97vi8FqLgIScTRXiAOYm4MNF0XNU7hGafOwrOKg+TjaijeV B6yOv+1Nr9Y+OQhjQkoOs5RwJAdrKtzJNZZBU/IY0KI1eW8cqCTOWCbH1paSEIwpI0GX9IQV MhU1JuleJX3SPXWyauu8093zn/+7lt+Olp9+9LERciuXH314PP7ofXAgO2UOBz+WDcVqfghu MJHKydN+pQSBeYknu1HC3xCAH7Yr5ax5wEEAKffRt+MnFejKioXiUmVMBvFkzSvWbARTabgB ujmCJrqGKcLIGKafhIi8wemYAkT2mAiGoRdDLA9IIbG/3uDXetC8LrBiYh9iGavBPrGPVWKf NHE1a5QmGHfjQGVjbdbAs/WgKAzSFJJwSHjCDYGKJolZtEL44kAq2SjrvFPdjSn/XclvRckH 87wfPYt7Msuvy/2/n2D4fh0rj6K1DjaDpAiuhDzgAuoCM6TKnQjs2WgYYKlzx+8vpxAbuznV Ni2fjkBDOhZxYy8TsegZ843D8q4UqPICbfQV26Ta2TAMhHXUhCi6xm6e3bYtj1we0XOVV6CZ AYmbNNV+sS1baJ3rppgcN3W7mlruoNyYUn8KvoOtXXdsAVlsdf2Xj7759vChfPT9Yfx8eviP 73882OmNTTQ3lEZnKBt8VjPK9lTvONpBueF++Cn4DuSSGrf8l3LZfgP7AdLoFzDCdmq4UFEK +WltKmwD5daa62fgO5j9CzZMhwMk+Prg/Uf3eR0b+3VApxPDSNRObaKy2tTOXnNbre6g3NqF /gx8R7ugSIfK07GR3bcrSyKa94W0MQWtKKxmxOwJ3TGxg3JDFD8F34EogmOLI/NB49HGpvLL lfHR8kJhLhtEqkyK9tTuOGnrF/2cMF4Xz1Mh1OPB8PWKoZBNpoNvseysLVYqgbDlM97X1HIH 5UUzySvjuzqTBKwH/h8zyaRT3+SkUzWjbE/1jqMdlBfNJK+M7+pM8kQut2YSI2ynhgsVmS3f 16bCNlBeNJO8Mr6rM8nRAHnhTGIkmpEyVFab2tlrbqvVHZQXzSSvjO/qTHIwNm7NJJM02alJ mmpGzJ7QHRM7KC+aSV4Z39WZ5NB8vGgmMQpl1A2RKpOiPbU7Ttr6Rd+aSV4Pz/FM8nQwXI2y UKi+5s0kr9qC1qXttL6rWcsdlJcMhdfGd20o6Nu4OhSuTSMtLxRSKxORVDQp2lO742QBcHMo vCKeg6GADfBTGVydNRQoWJSzFfmFOmzK2tUmJVsoN6bPn4LvYDD0yjDSwWA4mDWmhyAm9Kr0 nI45rWLxVnPiF7n3ENROB7Vto0piQ65/GFat2bO8tjKxIJkCFgjfYan0S/UxvQ1RlEzPFGq+ wPWc6FXwxdNXJCexz50+JYRmfaabt8Ev5XOl3wl0nO98lheLnqec6V/iuFC5YwSclxpjUurR 4fsxWL0ouiMsvU3cXRSCquwcg8+iNzvEnsQHyqAdHKo8IJW+1BhzU3uGnhdINcGzJhxV9KE1 /VeTolpZI61yYosHKxt3qolv9ZA8BGtKSjgkQ+GWbEnVIvXqF230RWdb/Z132rxhD9/1/ob1 fmCKmCgBzPligv6yWastZiE6Z/ke3GD0xiwP1ELHJIHymO87vZcRpuU8apGezbGu7p7PwZi2 ViVmZpH0e+W2yIERmXdSZnlmpFgt2A4XuSog2yClQpYNx9ig+Ik5iT7SlMHIeVLLgLRxkdHP +GP5PLgNSw0e2WQ9ImNUE1Z0zXBEJwqBO3rHsqjCVjMavdp2io9ZFodWI+/WgzIxWJSV4aAM iTmGSY/J2yilJoyDIOpW3Z13mryxl3rX+RvV+ZHDIzO766k5cEfmIMTGbA8GQGKxMmImw6bm MSgiojq5OIg/AnkuTNYKnRkreBtCYzkpgyQol6XYvhMZJ3Upd1o+q1WmgKk9I1EGqWYyazgq LKDhrqKONHH1c560MhGNHDR/IleN1CRm4uBZAjZrlxB4XiAkxIYMNjdIhjMxf2VSkxprpDOJ MtKv8uTMauRZPSAJQZoSEg7JTrglU1ElWYtaaEAcmF6mts4bzd1YEr9r+E1o+OBTj6ADEPd7 seN5n0xW37WlUIYLa8hKGduIgIaRTNagNK/IZLEaAjNcwFINzDEpsDE1ZJKJ7QlqldkuEEAN yGGxcvRYXi01WkD1iHlCor0EJOKQJRXuSApFVTJLKXopPuMjQdDGIcvIr6lLDRulMHuMgbJA aliOGY4m+oi7ZZaNqlZYG9S2QmrJg5WNO9XEt9pLHoI0JSUckqFwS7agacpctEob4sG0tOrv vNPmjbn/Xe9vWO8H/mwmEgzMF7P/10OjwKw0F7kujMjmVCUisSMyXzumk1IZBomBqxf04CKF FrSzpTLJbdGD5SBkQC+KFZMtBllRhIutafMIIzituQg7IBtV+AIJGv8xc+RstIVMOYHigL2W OGEReWwQNCuJvdk6MWnPoKRqkBNJIj6tBo0OLhNFXyZJpNqK4sYqTIVVa/A+15Sgg7CddnCU nGgweYo2SlkUS/arTs7byvOOv3dN/r40efDhJjZoL9zGdyaCmIOwLlkklGkoXpIOxRJSA7Mr RCVWNAV8U1s4gZGnzhEwjtJtsAg8i4HGzipM9NahkmIwapXFJOwqBbKV07gL9H6YxgMT00Rz W+SkomlclaTYN1onJYsISqoGOYkgpqtyt2h0UIegLosgLh9VFCdW4bKLbcm3YJg8BJtyAj7K TlSYTEUdJb1JSNjo5bxV0o1J+l2bvzttXvmCB8YXLccJbEa36xK7l0x9M0lr2jf5Bxlr7qjC tNghpEXfIU+LjS1XmcVOz6Uq0U+LPXYP02KHmOkCFexYp8VGDmQkHbGvFhvbFbPYOvgmXrS2 Mo0rV1QRR7fI2qBAA4QsrRCftGV0SIukT7ol1SoaN1ap02KLd0GhRASbcgK+4JZxZzJNMwJq Ntvkv+rlvFXSS77fd23+nrR57fsN8WWeM4KbkcaoM2B52myEAyhrz6W86VzBA+rF1z5ttm9+ tdkIKZrN9gjLqwCZnmelT4vtO8VGGF0HwQS702FJjJ1rrEFHL6vNRvTSbLayQcRLb6vNVoVS VWtKe0JJ1SBTL8JHbU06qEXRR92KaiuKG6tkaVx8C4bJQ7App7SEYUiFyVTUVZ1RWYLdG72c t0p6wRf8rs3flTavfMED49W974XSS6IHJJndxgGE6hs9FfQ8OPrxC85Al8bzWBlHLErpHA+Q TqELMHJvj9PShXpDq9wLVzyJbk3ACJmuw5S1hYrYL2TfmZEEo6njnwVHNMivp9Mw5caDGDrJ MmREXIkKxwkWbo5oSPvQW4AJbDDXsr4t8hQGlNDYL2MF1j0tqaf17Y0BWCqOG5/MXx+grBx1 XKTRccmAJrNKc6s2WIZsvJ3s9qACcRFMJvBw4CADFlOgtTQ7Jc6zZNV5i5f0IfPEDV03zwgG FHIl4GdxQ+Y8TRcdPVCrxs47/W0HxMb57UBx7nDW4ghw5in0yIBrH+XOIDVjTL4Rr6dXCGfg MyUwYyk+6Pw9xrL35DrzWIzn6f2MXjrEU0rlgR5C5WpVR1tKxXEcP+QgT5V0Whq/4ZxGSYFk Z08ZbqaUSwM+8OIpRawesFItNZujmHRWN0YYlrilzJsBEC3LZm4SdcMdu0X6OHKXWBMtjmJW wXFLL82mGdVivOrMeFnFORluf3GtB/cQnRN8t6O/LXKEJK7L4bLnt5CjjRyNf4YFWjducg/M yFk1dt7pb2p4n21W4hLYRCaBt5rPumyBZ5p4MqlE7RZ86lTpUEsq97oUAWegJB5HxVAkMki0 RRKblbPCfrNGk6MemR+wIBWv+L1wcOdBzAX20igqXUNOtFZ/Mg4YdSBn1ZshKBxMyiFAeiFb M1KxQKl1Qq+8YEE4GwfKpIY7MaOzaRDLZKpsnKkmntVDshAsyUg4JDtglkRF0ZS0KJUOxIF0 s+jsvNHfrayWdz2/HT0fZLHkaoH23dTt/G7q3sS+mPWChciagBeYgBe+PXwIH92nhw/+oxsW in9n/hZX+XdjC73pD9bYIWUPTx4fPuT5NvB38zwE/PrEDt49tI+hPczmrFvrC5Bh9jGQjwsY keDjppfgiI6wPEdDUNAefLKu3vlHAndfyVJYm6mLKMTjNFmK7lqSaozRRiUPMIau8WdOWoxL Jj8wdIGJTckPGsmFaRFMz+ABdnlWC4+vY1rhUokH2C1dgktIKzPhY0mk6PWk9pXZW4JUnR11 J47quKsl7uo618c80u+52DR6q498w8CKxyJBHKo8YI2ljT1PjmExtmeMdoGU6oojMd9SuDOD UZOqHFkjvZmJHODCSsadauKb7U0ehLRIijhMhsRtsiVVi9RJr+kj1qmljf7OO23e2Pu86/0N 6/1glxS0xKyXCf2hHGdxJ8f7msbgSDzgjnJULhbTLnGPQ+TKWndWaG3NvWrjyp/3QyAmmnlX FPdIjVOIzyed0cH6O85yCBZdVa0wuhrv5z1VBslusDIcvNvKcEfsVoyqmaUlejmBGxdczZM3 W9cnhwnTnnuss629t0UDISXfDENitFaYU5iLD/rNAqdWUqsTSeJilsWf1ci59fB5QjI5GQ5K kJgpV6PIJG60UhfGw9DQ1Np50d/zZuBdy29Hywcffaf8POjbf/bfrnz0lU4MyxxLPGWgWip0 1NKZkQrDMVp38naGRjdBhNsCm7qS6XTQfQxcwd6lzBsZKixfypHuEbJr5S4FqMYBYT2a7pkg rK7grmHhRTKGnfncRlfXpl4UF7udw03RkUMTXm0a6Lw3w8+2HIILlEbHh+DrVirh5RBcKOKl lUZrL8xNIw8qT+6sJj83e0gegjUlJSySobBLtm3mlFHqpNj0QT5MTxsNnnf6vGEI3jX/pjX/ 1DikomxHULsPXrYrrlPcx5YN/4+7TMcnbpMZFNBZlJislegeTDXTy8zzH8zBTHSX4eQEHJnU o137mHyhUxRcxt54O1xnQhR4i+Q65spRlOgMD+aCQq4JU8J9tRUjdUxnpDI3Su7MwMAenJOF kqnVl24wOHw7sz+wpsz3SgIHfUjeKlxTVqZ1AbNSv3RBZqTLDc5jTIeeq03HSYirZjtjMsw/ HXi4fmhMA7x/LxVNYPSBL5du8mwMRyszYX0gx3LSZU4yOVNSEfxkBuAyY285KME9M1SX1V8B Orp4t5o77/R4ZeJQUK0gGL8/6hbdQ6hjizk2n2O/GcdWtLlP7tF9GdvsMnbZthHVW5fG9ruP zermVNwBGnp992jcZ5/cF26y3dexxT3evCb4vBt6D5PF7DvVksStO8uWozwKXGYe8cGg5PDt GDCJ/koInworvKKQvurElN/MlJ9ZbpqZVdOta+rBeVaw4OHXZ8j8osAMiIE7h2yf7VAKswbP Rm3m1kVcQEHgpVsJpoHXSOo5B5a1571tE1J20TBkXb1IvNnxCkmjKDveeERaMz2/4sHKxt2s 8bpK9aA8BGtKSlgkQ+A2yeouuSlxGVDpglxMHc3SeaPHG5PUu77foL4PpqYWaMQuNqvxmmMw MkSWwzQjYfoFnTcXWdi6Ba9ZIwXawCqhDHmMB885JCNDSZwZ9v5I/xl4zdVX5G98XA1j2fr5 FocgnsCvF4MfKvIFj6NRLQfg9DjKzzemwbwA9sGZrxE2+dPq5hSmLw8f2uxeF0djiBtHI12K deuvnEZcXDx8qDuQfePffHwoDtfMPCtZzs2/SbIe8+wznl6T7NYPuhUm6Pdbn+5UAZqX1d1a 7NHiFp4v2gogkv1kruT8MeZFX8K2ceYuGjInrN+p7cDH++nS42xPwhN/tts6tPMlu+uY2/K7 8XlL632w7r8QWvi0imGO1s1AXQfllRFkhG5eHuhhw/aUCFzURqr6bsbU1itO3OEzmoTy/PDi EeDfMrz69qIkja5YgMkIq6t7P27JmR/a51Vri27L+PNpkWOwcWMsbeQTPFZLn3YSz7sB9LgO Kr+JZ4S0qmQ77sNF57CMFxu/G6uwANhFLf65sEnYDfJ9GCNbuGKNQUwRcXBtBHEZftkHUVYh uEneRrYbZe1iIddXnRgd3FLtlU+UbokiiRNj98vmi3Qfn5idycU6OJ4EkXbgfoOsF7IeV+mH +uDrou3N53gxXp4TQF3ibi/8XGq4nOQ0S8U+9fdtM4xXCR1YpLh71hfxTB23zST5wuCb+3g8 qIRpRsO2Mbl6Ief5zRkDTz+b56TJpJ3fIs3cNnsem9rKZmr7MgfSytViKNbPdo4k93Qo5WUo Xgyly2lhWoPQg6OsPu0GctnammsLGaL7tMiNI7Rd0chq5N126TFHk9/apqmr7fxiQI93hH5z FGNeDGQHMOzSmxgVJNHNMBc1O6qxhfKSi4heG9+1i4giA1X/zEVEk0LeCTQRqTIp2lO742QB cPMiolfEc+UioqcyuHER0aKcrcgv1KGrgC5qRskWyksuInptfNcuIjocDM9cROSjNsme6a6e Z4gzk9QuLiLyVf9sQ+I+G5e2YPcZmYCJPEBPV51G8dryUjRdFy8gWewHbqRmbLQTF8dDZhD0 hyWkwqVWNy8ztqM/eI468KDmtiezNX/wMInOgza+LLrvZcgeaWz3afOqFu76RUzk4ez1ZXf0 WTMN+BQrIreVyXV46R3Pj+iCZ4aXGg+Fip7xWZ5SANAUkLSGtMSgN1FX4VfygSTOYvFnvs08 YcNk0R9wJ5yqm1dCefrlIv2kP2wjrbgy3uLyqgzf6HiXmapa7J6YP9sZ/UhHxXgbmMDHZEy+ zcnSWn/g3+S4n//MEN81vOMVVafMs+4lzLuzI10Hy9uioFWab5NSZ+db3QDQDGdkoqMO/i5v 07weG1INPIzb+TbTLREN8tO7Q+vEc4dTPc1qIdCXW9q9/o0XhSN5146FAaPtPiPDcvHUdZJA F5kX3XZU6Hnn6KK3RaNQeQE2XpXwwMkeHBBKYdh+yQ6tlQljdOjSKyKCqq86fkVSawTxYkGj UMypjASDttQi/7kU9UixM3FBsHA9UDcs8Nh4w56jEtxEFxzG3gg28TddU8DywiBr4pw9TCCE NSUlLMk8WnTmOx3yYma0CV0USx3iRGraKvC8U+cVI+cg0ehW30pY9mhaj4z1XB8LCC1oRqWN 1cJcEQW4oh/HuoFbA0/HtPXBe/kzCODRs/lYSWJtEeQwgstZaxkseqxq7x5DYGP1GyiwsImV QAqeb2zvn07/B+gvx90KZW5kc3RyZWFtCmVuZG9iagoKMTIgMCBvYmoKNjAzOAplbmRvYmoK CjE0IDAgb2JqCjw8L0xlbmd0aCAxNSAwIFIvRmlsdGVyL0ZsYXRlRGVjb2RlPj4Kc3RyZWFt Cnic7VxLbyQ5cr7rV9R5gZb5fgCCgH6Ngb2t3YAPhk9lrxeL6QV2L/P3ze/7glnMUpYkL7oP Iwg9UyIzyXgyg2REkO7en367+/vJndwo5Z7vw6klf99O//ifu//4w+lvd/6Ef//43zs3XoTT 97vZKJx+tQ7o+quBwF+9+8vdn/9w5+7LeNwEIZQwWhfnR7vvdyG3+2i1kDNLfZT86FJcHOXz KaTGHhlvUh6AikOvkCLK3t/X0/kukODiMyAlN9oW3+7TLIcwepy3WhkQrUfo93nCigEY7wxL LMRC7LGNJ0bXgFEBC/SmMMrGxYBRTsYfywNSKYOe+aYPeqxHDcAwIdVywVEbcAh3cywbVS2g JnpbHL/Gh5WNQ9XEu3pIJoI1pSUskqOwS76ia0peFEsn4kSaWnR43ml0ahwD4fRv/8pB9dv4 /49D+X991/2b1/2/3/1JhmT8Gx/7p29Dy8Tg8fvtv0//8suwJO307c8P4dPjt7/eff02euwM hO9+EJaju4eh8a0OMlTzLcE+RSDzDeLLEWz7Wtkjj1Ia5OaIPr5CdDkB8PnO19EzJUCptHKp 3udZHqpNhKNaZm+U2sBhcAajnnCIoWT2Jt5SxxOjZwgNwjNKKwaZcVCheuON5QFrGM64vYFS 1CO4sEEKDtQIR3B1vBXu4DrLoipQtaI3eCheXMyy+LMaObcelIjBMkkZFsrQsMcsmiRtUSot iANpZ9HbeafF543Cu77for6fGgLf2Dfhd2cI/NfNEPhhBtIJMEaf2EBmrZotYoONUi0O25ZH OZxi7aNeK9iNNQ8Way2jFAeSWmEHYwVhtXkyG2nVasOKJZYGKA2/Vu6Bgps12GHr0ft9MVjN RUAijuYKcQBzc7Dhoqh5CtcobR6WVRw0H0db8abygNXx1970au2TgzAmpOQwSwlHcrCmwp1c Yxk0JY8BLVqT98aBSuKMZXJsbSkJwZgyEnRJT1ghU1Fjku5V0ifdUycXbZ13unv+83/X8tvR 8tOPPjZCbuX6ow+fjz96HxzITpnDwY9lQ7GaH4IbTKRy8rRfKUFgXuLJbpTwFwLww3alnDUP OAgg5T76dvykAl1ZsVBcqozJIJ6secWajWAqDTdAN0fQRNcwRRgZw/STEJE3OB1TgMgeE8Ew 9GKI5QEpJPbXG/xaD5rXDVZM7EMsYzXYJ/axSuyTJq5mjdIE424cqGyszRp4th4UhUGaQhIO CU+4IVDRJDGLVghfHEgli7LOO9W9MOW/K/mtKPlgnvejZ3FPZvnLcv/vJxi+38bKo2itg80g KYIrIQ+4gLrBDKlyJwJ7NhoGWOrc8fvrKcTGbk61peXTEWhIxyJu7GUiFj1jvnFY3pUCVV6h jb5im1Q7G4aBsI6aEEXX2M2z29ryyOURPUxuHEY2ARI3aar9alu2GD37xgQzeFVTyx2UF6bU n4LvYGvXwSLa5Z2u//PBN98eP5QH3x/Hz8fH//r2x4Od3thEY0qZdIay4LOaUbanesfRDsoL 7oefgu9ALgmLg6dyWVe6+wHSsCWYhO3UcKWiFPLT2lTYAuWlNdfPwHcw+xdsmA4HSPD10fsH 9+kyNvbrgM5lnZGondpEZbWpnb3mVq3uoLy0C/0Z+I52QXCvHI2N7H65sSSied9I83FBYTUj Zk/ojokdlBdE8VPwHYgiYAt9bD5oPNrYVH65MT5a3ijMZUGkyqRoT+2Ok3b5op8Txo/F81QI 9Xgw3DIUtMmhYI6fll21aaVC69yB6zO+qqnlDsprZpIfje/WTBIKZtV/fibZ6OQ3udGpmlG2 p3rH0Q7Ka2aSH43v1kzyVC4vzCSTsJ0arlQkW35VmwpboLxmJvnR+G7NJIcD5HUzySRRRmqi strUzl5zq1Z3UF4zk/xofLdmkqOx8cJMspFGO7WRppoRsyd0x8QOymtmkh+N79ZMcmw+XjOT TApp1CciVSZFe2p3nLTLF/3CTPID8RzOJAeD4WaURUJlqGhTDWsb2gTCNmXsa2q5g/KqofCD 8d0cCgE7y5tD4dY0AgkbhdKKIVJlUrSndsfJBuDlofDj8BwPhScSuDlnKEywqWYV+JUybMLa 14yOFcoLk+dPwXcwFHrFHHM0FA7mjOkfiAm9Kv2mY0ar+OBqTqRg7x+one5pm/pKYkM0iwyq 1uxZvrQysSCVAvYHMJyzsC53pL0xmIta6GAa5aHLTidFdIoQ9UgHxmCtez6HT0orqBIzg8X9 XiFszS6R4eUyyzPwbLVg5gchafhgDFKCy3bAEo7UIHphTqKPNGVHD5RRy7iTcZHRz/hj+Ty4 DVsNjpdkPSJd0RNWdM1wRCcKG3fTjmVRhRVlNHq1uhQfsywOrUberQdlYrAoK8NBGRJzDJMe k7dRSk0YB0HUXXR33mnyhSXTu87fqM6P9jWZSRzpyQbvy7JC28xBiI1BXfo5Y7EyXKNhlMeg iHDe5uIg/gjkuTAnI3QGpvE2hMZyUqA4KGRdbHmJwHLdyp2OaKtVZnqoPR3OBqlmMms4Km2q cFdRR5po5s6TVuabkIPmT+SqkZrEgDueJWCzdgnxpQ1CggvYYNPyG87EMPWkJjXWSGcSZaRf 5cmZ1cizekASgjQlJBySnXBLpqJKsha10IA4ML1MbZ0Xzb0w971r+E1o+OBTj6ADEPfr78MP PZLJ6rvWDgpks4bg81gvBDSMZLIGZXNE5oTUEBjIBks1MJRcYGNqyCQT6xDU6HilAGqgN1rl 6JGtsdVoAdUj5gmJ9hKQiEOWVLgjKRRVySyl6KX4jI8EQRuHLCOMXrcaVkRh9hgDZYPUsAAz HE30EXfLLBtVrbA2qG2F1JIHKxt3qolvtZc8BGlKSjgkQ+GWbEHTlLlolTbEg2npor/zTpsv zP3ven/Dej9wWzFeODBfGQV3aBSYfDKDMnULOcVsEYaBP50UsRwkBq5e0IOLFFrQzpZKGLVF D5aDDMJwu6RissUgK3I/sDVtHmEEpzUXYQcknQlfIEHjPwaIz0ZbyJQTKA7IfhEnLCJdBYJm JbE3WydGkgxKqgY5kSTi02rQ6OAyUfRlkkSqrShurMKMN7UG73NNCToIm3ICviE50WDyTNNp P8i8RC4WnZzXyvP7+3dN/r40efDhJjZo1+v2G9N5Z4q3eQLq5uKnTEPxknQolncW6PoWlXTh gm9qC4nWeeoc3rwo3QZzj7IYaOyswnxO5Y4Xg1GrLCZhVymQrZzGXWhe447UMf9ENLdNTiqa xlVJckyidZInX1BSNchJBDErjbtFo4M6BHVZBHH5qKI4sQqXXWxLvgXD5CHYlBPwUXaiwmQq 6ijpxVu86OW8KumFSfpdm787bd74ggfG1+y7BcwckpIeK5KpbyZpTfsm/yBjzR1VmBY7hLTp O+RpsbHlKrMIVFPf0U+LPXYP02KHCFFMjcc6LTZSnSLpiP1isbFdMYut8y3iRWsr07hSwuRN dpusDQo0QMjSCvFJW0aHtEj6pFtSraJxY5U6LbZ4FxRKRLApJ+ALbht3JtM0vdtms03+F72c VyW95vt91+bvSZu3vt8Qn8zAbskj3Km9JO6gkukdeYrVN+50uHNx9AMWHJUqjWnbGZmYpXRq Ar7EQhdC5N4Ah6oKNYdWuRdazES3CGCE3O08A5dgEeuN7Bmv9xC6TokUZHJSe55Oh5Qb8zWV 8JpOnrgSVY5EVy6uqIieRwEibFC3tNcikzWx9Wrsl2HBu6cmPLXXcSYkMSHSc+GU+esD8hdz VFZpo+MDOyjPkGFu2Cf5niAbbwfAPKiAXxWDETsk5DvCGIPW0uwwGVPOq/Pmbx27RZ+4IOy2 s/KQdKrcp7khcybdR6b+LBo77/S3DonFeeZAce5w9uCkUOZhtUE3z84UBw59po/aN+L13FXi qFymBKYv1gcd08Ns5D25zsye9Tzkl9FLub6lVOb9EipnO2XAloqsXT/koJ2udFoaPpVBwygx 47c6e1p4Sqhy7AEfePGUIqwPZrpSszmaSGd1Y4RhiixlHiCEt51ZuDYOCx1bM1LAkbv5qnng QD7voCxNaTZNrzj93Wf62yvSabl8xulfrkF6tLRanhBqkSMkcV6Hy4/fQo42cjT+6VZs3bjJ HZpfNXbe6W9qeB+ULnELjPiMT0k1n3Umk6nPTGAuUasNnzpVOtSSyr3OTiJVWuJxVAxFQpOk 8LHEZuWssMGsJfZWyIIfsCAVz82L4eDKhZgL7KtRVLqGnGiteE4O6LUkZ9WbISgcTHxekYXA 1vR0blBqndArz2EKZ+NAmdRwJWd0Ng1i0m9l40w18awekoVgSUbCIdkBsyQqiqakRal0IA6k m01n50V/LyQDvOv5Den5IPKeqwXqdlO387upe5nrORNmqIMdYGQZqB89PoQHFx7Hz7BPjx/8 g8trzP4plIAZn1CGORoPnsXLGYPLm0mo8IZfiPcjEY6JBfi/Gil4JEr644eM5/nB64FefrbH aF4e23xQ7BGBfVxatguA+PihTuh4HDNbfH4Mhs1HvmN37/Q3AG0yEPOhwQ6X5vb7aXn7caH6 It4P3oHaulFxxe5g4oDf2SbYg9AH6+ELoYWPFzEkk+nnTXgGmEyO9s3a+HrpJEKXlwd6WNie EnEDgpGqvoIGIhdBOuEOn9AklOeHl09zsLx2ePmwHIXR8IoFqIyyKrWB2bjSQ+bcVNinnXLH 7L2V2JYDx3haBBT8Y3lYWoL7vBtBny+jyl8GwENIF52sAz9cdQ7bgLEB7D8bukWpn1ZRr+Ns HWYfwm4MfVyZp3qWUe5MXgtD3s1PaBERR9ciiHUEhmsEixDcJG+R7aIsk8Lk8Lnx0teEPLNp n4ThowmMnBi7X5ZP0j08sTuTi8vgCNff9A7c/0PWG1mfL9IP9dHXTdvL93g1Xp4TQKtTAK/8 Xlpepg1JzGcffHmMfWrwl2UgX2R0YJTi7lnfBDS1TOtWLkYj78ZXuBg/idVEdDishMlGqQaU IalXkp5fnTHw9MN5Tp51m1VfKc8arue2ssxtX+ZAuvC0GYrLZztHkns6lPI2FK+G0vW8MK3B 2DA6SurjbiCX1dZcZhHRNSkiuo+b1DhC2w19XKy8u8wNYRtLfrVNU1PrBGNAb+hC954oM+KZ pcM/Z+z2Rmr3/JWD9MB++p3FWIbs0+lwNa7rAoJKHPiWxcYYtU/miGU6FoX2TVzs83H2bYzR 1tE8mRm6VswWlsJKmuleDNZiK650L629eRqHoaRSdfiOW2eey8dGmM4dnsy3BDFmWFuZKW5b 6livJ7Wvzm0xtursDD9xVEc/HnFX1xkt410FPMlzNnqr57FB8gGnCE4IAZPKA1as83lyTARg e2albJBSveBITCUV7szw+6QqR9ZIb2bqGriwknGnmvhme5MHIW2SIg6TIXGbbEnVJnXSa/qI dWpp0d95p80X/LXven/Dej/w7AY5xa4zpT6NmekwQT05XkQ1BkfiyX2Uo7JPHQnokR6teK/L OOQNZDy70VfJiy8iVxaFHr4zL6bg9VgnHT6CxzDOcgiWT6JaYT5JvJ8XcBkku5rLcPDSLsMd 4V81qmZequily8G4oP+RvJknMjksluy5h2fQ2ntzcxBS8s0wJOanCHMK013CSEGgM4DU6qiV uJhl8Wc1cm49fJ6QTE6GgxIkZsrVKDKJG63UhfEwNDS1dt7097wZeNfy29HywUffKT8P+vaf /S83PvrKsIvlyiYeoFAtFYamGH5JhQFoecp47URjYCMi0AI3dMkMk+iiCfrc7lLmVRMVli/l yIAO2bVylwJU44CwHk0XaBBWVzqLYeENOYa9w7FudHWFIURxsWtH3BQdOTTh1aaBzgtB/GzL IbhBaQzVCL6u2xJeDsGNIt7GabT2wmxc8qDy5M5qiuyxh+QhWFNSwiIZCrtk22YWLaVOik0f 5MP0tGjwvNPnC4bgXfNvWvNPjUMqyu+O99fpGu1GsBcXzWXD//0uM1SLa3IGBQxvJaanJgY0 U82MjCOAlZh1nhjgw6U8CL1Sj3afZfKFYVxwGXvjtXedKaDgLZLrmCtHEbhC2FhBM2TX8RCM r7ZipI4ZPlWuWsmdOWeIGnCy0PER9WXgDiHqznw3rCmzEvcYI0e6auGasjKRFZiV7KqbPyOD hAh3Yzr0XG06TkJcNXPkcMJgyBH3Ko1pgBcLpqIJjNkD222ikB2vuHHM/feBHCusmDnJ5ExJ RfCTmXKQmW2Qg470ZCYnZPVXSgKD0qvmzjs9HoYEE6LfDR/RMAXM41UtiQ1dcqZLzLqzFAgQ H6hsDosORSRGLsEUBVF4pyGj1omHBzKTB2e5acZTTde0qQfnL8FCrF/Dm5mKgblUA3cO2T6H wSzzj89GbeaWQFyAcfDSrYRPjvdO6jkVZu150duElF00DFl3NRJvdrxz0ijKjlckkdbMGLB4 sLJxN2u831I9KA/BmpISFskQuE2yunxuSlyGSbogF1NHs3Re9PiC8X/X9xvU94HJb4HG4WoT GG/6Mr201a6O8kb3GANcql9dxA0hq6PQfXZfXFXlEquDUw4xvWc898DFjJU9LvcJGBKdpmUA W92D23DuOteIXIrvuNeNG/HOw8M83p254x6vOuwn7HddXmbo6DuPKQWeg1h7MpnpO3M1ddyi 8SXPcQyNjVeRGR6XV7XwUxAxkWefLi+74wIJzoDxssJNUJl7gpfeJctLauMt9jKNZy5Ejw9u 7CAANIXIkxJY9PBN1IWSlXwgx6mYs4NvMxNYmUv1Hd/YmPLm0WrPSSByUv5uo0tODLwNjuc+ K95lZnLBWRH1zk69MC9ofCHMb2GuEt/mZFlf33Gz7f28rJvvGt7xqPeYsHgqNMwb6CK/p+1t 0Q4pzbdJmWXzrQ7YNcMZmQekczXb2zQvmYNUA8+6dL7N/FajQX56A0+deO6QNNusFgIXDgV0 IPivvS/v8bM9Z7SAZeQeMJ66EvV0HWDhV8+LOW100QRpFMoJZeNV3jXuFsEBoRT6iLbkqVqZ T8HVA02FCKq+KruZpNaYmAeNX41CMacyvFltq0VeOqweKXZ6yQQrVW6+ZSSdvIDcFUTlf4gu rE68EWzibzoFyPLGIGvinD1MIIQ1JSUsycw8V45OOdRMHDShi2KpQ5xITasCzzt13sidcJBo dBdLF7agsRztaVgz9/FRXvxRaT49zljDaNFg9h4Zq0SsYbRVH7xHEMIAfPZs7h0efg1KtIBJ U3AFURir2rvPIbCx+g0UiLTESiAFzZbI+Z9O/wdsCkVyCmVuZHN0cmVhbQplbmRvYmoKCjE1 IDAgb2JqCjU0MzIKZW5kb2JqCgoxNyAwIG9iago8PC9MZW5ndGggMTggMCBSL0ZpbHRlci9G bGF0ZURlY29kZT4+CnN0cmVhbQp4nO1dy44ku3Hd91fUWsC0+X4AjQZm5s41oJ2sAbwwvCpb NoQZA9Lm/r55zglmJbuzplp2z+I2GpJ6yEpmPJnBYESQcvf+9Nvd307u5EYr93wfTi35+3b6 +3/e/esfTv9z50/4z9//686NB+H0/W4OCqdv9gJe/WYg8K+e/ffdX/5w5+7L+LkJQihhjC7O j3Hf70Ju99F6IWe2+mj58UpxcbTPp5Aa38h4kvIAVBzeCimi7f19PZ3vAgkuPgNScmNs8e0+ zXYI443z1isDor0R+n2esGIAxjvDEguxEHts4xeja8CogAV6Uxht42LAKCfjj+0BqZRBz3zS Bz32Rg3AMCHVcsFRG3AId3NsG1UtoCd6Wxx/jQ9rG4fqiXe9IZkI1pSWsEiOwi75iq4peVEs nYgTaWqnw/Oi0alxTITTv/wzJ9Vv439/HMr/67vu37zu/3z3JxmS8Z/xsX/6OrRMDB5/v/7H 6Z9+HZaknb7+5SF8evz617svX8cbi4Hw3Q/CcnT3MDS+1UGGer4l2KcIZL5BfDmCbV8r38ij lQa5OeIdXyG6nAD4fOfreDMlQKm0cqne59keqk2Eo17m22i1gcPgDEY94RBDyXybeEsdvxg9 Q2gQnlFaMcmMgwrVG29sD1jDcMbtCZSiN4ILG6TgQI1wBFfHU+EOrrMtqgJVK3qDh+LFxWyL P+uRc3uDEjFYJinDQhka9phFk6QtSqUFcSDt7PR2XrT4Y6Pwru+3qO/nhsA3vpvwdzEE/stm CPwwA+kEGOOd2EBmrVotYoONUi8O25ZHO5xi7aNfK9iNNQ8Way2jFQeSWmEHYwVhtXkyG2nV aoPHEksDlIa/1u6Bgps92GF7o/f7YrCai4BEHM0V4gDm5mDDRVHzFK5R2jwsqzhoPo6x4k3t AavjX3vSq41PDsKYkJLDKiUcycGaCndyjW3QlDwmtGhN3hsHaokztsmxjaUkBGPKSNAlPWGF TEWNSbpXSZ90T51ctHVedPfjz/9dy29Hy88/+tgIuZWnH334fPzR++BAdsqcDn64DcV6fghu MJHKydN+pQSBeYknu9HCvxCAH7Yr5ax1wEEAKffxbsefVKAraxaKS52xGMSTDa/w2Qim0nAD dHMETXQNS4SRMUw/CRF5g9OxBIjssRAMQy+G2B6QQuL7eoK/9gbN6wYrJr5DLMMb7BP78BL7 pInerFGaYNyNA7WNtdkDz/YGRWGQppCEQ8ITbghUNEnMohXCFwdSyU5Z50V1N5b8dyW/FSUf rPN+vFncs1X+mrtP4uOwQIlzAf+q9+1kvQiL9c3ctSc9jVyg3Jh7PwXfgRgCHMQ43K68COLf Hnx7/FDG3+EyfXz8969/PBBKyxuFY/t0QaTOpGilduFkA/Dt7kfCeF08z4XAVfK5DPbWfw0O 0WPdlLMX+RN1jA34855RsodyIyDxU/AdTIZe4YocTYbg66P3D+7TZSr87QTH4LcxybBEp15I GxbvPL7bMnAAwwbf88fUsFMfAzONQYcx+EbTMLYvDnPx22k/8rlghDR4mI7cHCI0qTIG0Ahr QRpoI8c+BcNoLXIttAnB089vshCXcVcR0oko2ZH86CuCE7VTzivKsf3ypxKxXRlIOyIwVUga YzYZotmPOoo/Qgljy1WEThET9b5Z/AQEYRMTk2OEZelp5ALlhn/7U/AdxFm64wiY/Kf2xixO fxx/rpkcTemNzlB2+KxnlK1ULxwtUG58ej8F34FcUqccn8rlqg2CM183whY1PFFRCvl5byps B+XWBuhn4DtwxQuiF4cT5MAGrU55Z0TRSJRhnKisN7Wzam6v1QXKrZDQz8B3FJKIjG4+mxs+ u1+v7E+48G+kcTHcSFPPiFkJXZhYoLzEXXltfNfclWPzsbkrv1yZHy1vFNJzmIjUmRSt1C6c tMsXfcNdeUU8B+5KoGl5bio+hXLFWMguM+K+WXf2NkuVCtde+5TXnkYuUF60mrwyvqurScDi /f9YTSad+i4nneoZZSvVC0cLlBetJq+M7+pq8kwut1YTI2xRwxMVmT1fe1NhOygvWk1eGd/V 1eRogrxwNTESzVAZKutN7aya22t1gfKi1eSV8V1dTZ7PjZurySRNtmqSpp4RsxK6MLFAedFq 8sr4rq4mh+bjRauJUSjDbojUmRSt1C6ctMsXfWs1eT08R5vfQ0NxJQ4im+xr3u0T1NuslEv7 ncHSs5ELlJesJK+N79pKom/j/76SbHTym9zo1BdqlK1ULxwtUF6ykrw2vmsryXO53FhJJmGL Gp6oyGz50tsUtoPykpXktfFdW0kOJ8gPYiORUc3KIohBXe1MFcnLW6IGMSH0UpkHGQOL52tc DjPkW6MjQ5dRJhZUPMEqwUyXyuBxH4QOs1kyw8fo+YL8UGK4whfPgK4yOT53Bn4Ra/GZuZiG 4LHPlcFhpJXPdz4r1MxZljODwBhr7Q4Kz1uPotQbHSEXg9WLUrDC0tvE3UUhqEIEiMlc0psd EsTiA23QDg7VHpBK33pMjGs860M2SJWxJOGoog+jGWSeFNXKHmlVpkk8WNu4U0986w3JQ7Cm pIRDMqyXOJao2qRe/aaNvulsr7/zos0by+W73t+w3g/cFlYzAfPTePW+RGEzC9E5K8ripqM3 lmKhFzr8BbSHD9DBSImwTefRiwxPDnvZPX8HY1okS8ws9WI8NM7ARmRxWJntWTZmvWA7XxSU gWyDlApZNhypwXsT5iT6SFMGI+dJLatGjIuM94w/ts+D27D1ooNq9UZkInnCiq4ZjuhEYWMK wLEtquA0RKNXDoT4mG1xaD3ybm9QJgaLsjIclCExxzDpMXkbpdSEcRBE3UV350WTN1bFd52/ UZ0fua6ZJZjPzMHYuhyYgxAbS7IyJkYs1g4RblHOY1JEpF5zcRB/BPJcWFEZOsvK8DSExnZS mVdQwVkxzxNlYXVrd1o+61XWaWo808UGqWYyazgqLKDhrqKONNF9Ok9aWS1KDtqgDlw1UpNY LofflFXSuITqkA1CQrGaweamyXAmFplNalJjj3QmUUb61Z6cWY886w1IQpCmhIRDshNuyVRU SdaiFhoQB6aXqa3zTnM39gbvGn4TGj741CPoAMR13XeH6z6ZrL5rZ6QyNPZQOjb2IQEDI5ms QbWYkRWdNQSWoYGlGlgIVmBjasgkM5bEXmVJGgRQA1PoakcP92rr0QLqjZgnJNpLQCIOWVLh jqRQVCWzlKKX4jM+EgRtHLKNIri69bDTCvONMVE2SA3umOFooo+4mQfeqGqFvUFtK6SWPFjb uFNPfGu85CFIU1LCIRkKt2QLmqbMRau0IR5MSxf9nRdt3lj73/X+hvV+EJmoLIYMTzcDh6t/ 7LtKkoiSa3Ui4hSRhypiomtCsQV6L3iDTgotaOdIHfcwpwfuIGTAChNrJnMG2VHmi6Np8wgj OPlchB1QMi58gQSN/7Jg42y0hUw5geKAvZY4YRPFphA0O4lvc3RiZa1BSdUgJ5JEfPIGjQ66 iaKPVR6i2prixjqsV9do8D59StBB2E47OEpONJg80yxKGmReKrN2OjnvOz+OC79r8velyYMP N3FAe7aNv/7lbvUXdasuoUxD8ZJ0KFY1Hlh1ISrh0RTwTW3hmFSeOkcaOUq3wTLzbAYaO+vw NIZOfhWDUassJmFXKZCjnOZdYPTDNB5YPSqa2yYnNU3j6iTlxDE6qYhEUFI1yEkEsaacu0Wj gzoEdVkE0X1UU5xYh24Xx5JvwTB5CDblBHyUnagwmYo6SnpXqLDTy3mvpBuL9Ls2f3favPIF D4wv2XcL2Mx41y2fL5n6ZpLWsm/yDzLW3FGFabFDSJu+Q54WG1uuMpudkUt1op8We+wepsUO MTMEKtixTos9NiAwe4OO2C8WG9sVs9g6nSpe5FuZxlXQrSyk22RtUKABQpZWiE/aMjqkRdIn 3ZJqNY0b69RpscW7oFAigk05AV9w27wzmaaZFTWbbfK/6OW8V9JLvt93bf6etHnt+w3x2Qp8 vKEGuC3TWLc8KqWKdABl7enKm86VPKBefO3TZvvmLzYbKUWz2R6pejUg0/Ps9GmxfafYCKPr tKZgdwYsibHTxxp09HKx2ajsNputChHx0tvFZqtDqWo0pT2hpGqQqRfho7YmHdSi6KNuRbU1 xY11sjQuvgXD5CHYlFPa0jBK09aLzZakRXPd/Ec1z3slveALftfm70qbV77ggfFqIuyJ0kti BCSZ3cYpoeobIxWMPDjG8QsuKiiNhyYzzkGV0jkfIJ3CEGDk3h5XGhTqDaNyL/R4EsOagBEy Q4cpawsVsV/IvrNKCUZTZ7QLzlGRX8+gYcqNRyJ03GzIiLgSFY5jZtwc0ZD2obcAE9hgrmV9 W+RRKSih8b0MD6x7WlJP69sbE7BUHDc+mX99gLJy1JmuxsAlE5qsNc2t2mQZsvF2/YIHFciL YDFBhKMUOVOgtTS7yoEHPqvzli/pQ+aJG7pukRFMKBQ3qNAhMgQ6WoxAXTR2XvS3nxC74LcD xbkjWItz+plXRUQmXPtodyapmWPyjXg9o0K4qCJTAjOX4oMuycBc9p5cZ55d87xiI+MtnbQr pfLUHaHSW9X5s1JxZs4POShSJZ0WHgMZNIyWEsnOfmW6mVIuDfjAi6cU4T3AUy01W6CYdFY3 Zhhc3FLm9R3IlmUzN4m64Y7dMn2cuVuuiRZHOavguKWXZtPMajFfdWa+bMyFruwa7t7hHqJz ge92Pr9FzpBEvxwhe34LOdrM0fxnWqB14yZ3aH6vsfOiv6nh9SReiVtiE5UE3no+60YUHjzk 8cEStVvwqVOlQy2p3OvmEhxUlHgcFUORyCDRFkls1s5K+80eTY7eyPyABal45e+FgzsPYi6w l0ZR6ZpyorX6k3HArAM5q94MQeFkUg0Bypg4mpmKDUqtE3rlLSjC2ThRJjXciRmdTZNYJlNt 40w98aw3JAvBkoyEQ7IDZklUFE1Ji1LpQBxIN5vOzjv93apqedfz29HzQRVLrpZoX5Zu55el e5f7YtULDt5dSlUDC/Bie/wQHnx6/OAf3OfH0cw++PIYret+efzQHlzlc451HT9/YXOYND4o +vHz44eMR+NPGL+7hxDwC6G7B+8e24Sn1/o23ggIVypEY4w2A3AuEEtfsJ6inYUXrkSmCbCI qNBAs4bnXBnELHZWlUaf9znAhNMt4Y0OVppAd83aLK7YihZ6PWl8ZaWUIFVndz8QR3XcQRJ3 dZ2+KO+44MHQs9FbfeQTJjE8FmRxqPaANdwI+z05pqA4nvnQDRJPRhqOxOJI4c5M/EyqcmSP 9GYWTYALaxl36olvjjd5ENImKeIwGRK3yZZUbVInvaaPWKeWdvo7L9q8sc941/sb1vvBjiTI nXuao796OCs5XmA2JkfijQ9oR9U9scQRF5tEerG6xEV+LPeFjV42L0xB/jHz8jTuRxrNtc8n VTbD142zHYJlMtUrzGTG+3lxm0GyK90MBy97M9wROwOjalZEiV4ulsYFPWfyZj50clic7HcP n9bGe1ugCSn5ZhgSM6PCnMJc6BmjClzGSK3quMXFbIs/65Fze8PnCcnkZDgoQWKmXI0ik7jR Sl0YD0NDU2vnTX8/NgPvWn47Wj746Dvl50Hf+tn/euWjrwwYWJVW4pEA9VJhUJSBg1SY+pCP x+tKGrfkESECbKBK5gZflxfQW7xLObHyCZYv5chQBNm1dpcC1OOEsDeaLl4hrK5EqmHhzUqG nbXTRlfXBloUF7uuxk3RkUMTXm2a6LxIxs+xnIIblMYgg+Drmjbh5RTcKOItrkZrL6wDIw9q T+6sp5gy35A8BGtKSlgkQ2GXbNus36LUSbHpg3yYnnYaPC/6vGEI3jX/pjX/3DikospCULsm CtuVMCUuKMyG//tdZpAR1ysNChiYSSyMSgzFpZoZ0eVZC9Y7JoamcEoBQUPq0e5BTb4wAAku Y2+8LrGz+Ai8RXIdc+UsSgw8Bwv3oK6D5de+msdIHTPwpyqJkjurHbDf5WKhwmW9y5ATgqud lRbwKfO9Cq5BHwqlCn3KyhIqYFaZlW6MjQxvIVCL5dDT23RchOg123mOYf4ZLMN9XGMZ4IWU qWgBY7x5u4WW51A4W1l16gM5VkAsc5HJmZKK4Ccz2ZWZ58pBxeSZabGs95UMYzh1r7nzosfD YFZC3LbhIxqmgBVk6iWxocvxtuMoSr5lHlOBsjktOhSRGHMDUxRE4V2YjLcmlq1mlq3MdtOK p56u99MbXL8EC1FqTW/WyARm8QfuHLJ9DoNZVr6djdrMLYG4AOPgpVsLnxzvK9XvVJiN5wWB E1J20TBk3fFJvNnxrlKjKLvOHtXE6KV4sLZxN3u8F1VvUB6CNSUlLJIhcJtkdWnhlLgMk3RB LqaOZuu80+MN4/+u7zeo7wOT3wKNw5NNYLwW3BqbbuqnPTlbGt1jDA/euS8u+s+uISz10WJU v7j6WB5ccx1PXUKnWDzq8/4o6jNETLSsiNwnnG5OA2iawa9rEJiRymGCCDMM5zzjaeFxF1TL P4YSoBVCGapDXO8H8b/IzA0XhzX8Fz4hHDd213lG7z5aIA5/L5QoyFcZx5Mk9xG8j/ZcENLW 2+KEl+igAn1QygASPOT+xVjHW8dQAwOJPo33LFCoKCLjlQouWoSSiIqB/MSfPlpoE8jzY3vw Ae8ixNknzxy4QFb7JcrkWv4PqcFjXX4ShS2kSVirJIRgaST1zkKxxqnY+mRynFIqi7xcfPxQ H3zcCZUClsRXfeWLmAY8CSruJMLnIdm3EVaFhScvB413Eyu+vI87pXLERTHueJLNUPOcDmEb /WkLVM8psQ8u7xjapkrciWgLTZsg9hM2PEWwE4Kb5O1ku1OWSeGW+cD06Pubh8I0H8Tw0QRG TozdX3bfo1tC7wsXl8kRLpPDVLkH9w/IeiPr80X6oT76umnb103kT+bLjwTQ6hTAC78XbitW ic0cxfYB/7qbyBcZ+d3Et4Fx+a1vAppapmmzD+N58iJcLJ/EaiI6nFbCZLP0mqlavjpj4PmH c0mKTM+o63Am9pPfTz4yFt4TL0bIhVtUuOXfWbSiKoG2e8iqk+88a4UjG333iLGg7yw3DTwX oocl2Z5p7KmQ6r6Pu4cMB6cqYmKa50v0sDvttfGoYs9VqVU88o5nvSNmxHcGxSqPjehFH9wp Bd4ZPv5llDzo+onxTLsGV0ls4pkxxM11hyXyhYUBN4gg6YgMi0z4tOlYSsOz1iweLriBx0oj 75f8PpyQmT2QZFFyF3jkBu/mwDR/8QZX6frICtnvuGD/XiUQ4jU0PeX/BcLYATGTwQMveBp9 uTwrCrjNa0CjjtpuT3UerxlWhCJ11KhentpVNn++S6pn5Dn777Znzz4a5Oe3xWxU3Kn6Vz1c /tl4l/r8P2yILMNAtpelwY73orAsJfHIAesaUlYdEi//SE3RFvOcozWzampszhZugBmGBAd2 5rnS+xT4wu220BZ6niKoevnEIrVGMCwWNBPFnNpIjrStF7vqZejzRyVmzFPnZQPCMrxiw50j t81G1djqGrEm+qZjnWxvzLEnrnOZoogKNUlGgC/RCatEKnqmsEWp1CAOpJ694s6LGqd/fXA3 1yze07VPs0rMLoGa992sd+Hs78lZoLzkbq7Xxnftbq6D23Zu3c21kebjDoXdA2XErIQuTCxQ XnI312vju3Y31/GFTC+5m2tSyGuyJiLdmTUpWqldOGmXO5Ju3M31ingO7+Y6mgxfrvganuGw 6C5bpLD55nAo4CwkLNjwJVzDWm57NXlQWOPH5qFweQ/b1pIPOKaw2d1nj+7wHzDqy3AYsNGA 9xBsYIf3kuBQ0J8gvo94HDv8jK7OAOA1xiVD2IZHtun0T6f/BT5FggkKZW5kc3RyZWFtCmVu ZG9iagoKMTggMCBvYmoKNTkwNwplbmRvYmoKCjIwIDAgb2JqCjw8L0xlbmd0aCAyMSAwIFIv RmlsdGVyL0ZsYXRlRGVjb2RlPj4Kc3RyZWFtCnic7V3Ljlw5ct3XV+R6AJX5fgBCAVJJMjC7 8QjwYuBV2mNj0DIws+nfN885wfvIullZPS4tulBQd4q8l4wnb5CMCFLu3p9+vfv7yZ3cKOWe 78OpJX/fTv/4r7t//8Ppf+/8CX/+8d93brwIpx93s1E4/WId0PUXA4G/9e5/7v76hzt3X8bj JgihhNG6OD/a/bgLud1Hq4WcWeqj5EeX4uIon08hNfbIeJPyAFQceoUUUfb+vp7Od4EEF58B KbnRtvh2n2Y5hNHjvNTKgGg9Qr/PE1YMwHhnWGIhFmKPbTwxugaMCligN4VRNi4GjHIy/lge kEoZ9Mw3fdBjPWoAhgmplhVHbcAh3M2xbFS1gJrobXH8Gh9WNg5VE+/qIZkI1pSWsEiOwi75 iq4peVEsnYgTaWqjw/NOo1PjGAinf/tXDqpfx/9/HMr/27vu37zu/3z3JxmS8Wd87J+/Dy0T g8fv9/88/cu3YUna6ftfP4bPD9//dvf1++ixMxC++0FYju4ehsa3OshQzbcE+xSBzDeIL0ew 7WtljzxKaZCbI/r4CtHlBMDnO19Hz5QApdLKpXqfZ3moNhGOapm9UWoDh8EZjHrCIYaS2Zt4 Sx1PjJ4hNAjPKK0YZMZBheqNN5YHrGE44/IGSlGP4MICKThQIxzB1fFWuIPrLIuqQNWK3uCh eHExy+LPauTcelAiBsskZVgoQ8Mes2iStEWptCAOpJ2N3s47LT5vFN71/Rb1/dQQ+Ma+Cb87 Q+C/LobADzOQToAx+sQGMmvVbBEbbJRqcdi2PMrhFGsf9VrBbqx5sFhrGaU4kNQKOxgrCKvN k9lIq1YbViyxNEBp+LVyDxTcrMEOW4/e74vBai4CEnE0V4gDmJuDDRdFzVO4RmnzsKzioPk4 2oo3lQesjr/tTa/WPjkIY0JKDrOUcCQHayrcyTWWQVPyGNCiNXlvHKgkzlgmx9aWkhCMKSNB l/SEFTIVNSbpXiV90j11smrrvNPd85//u5bfjpaffvSxEXIrlx99eDz+6H1wIDtlDgc/lg3F an4IbjCRysnTfqUEgXmJJ7tRwt8QgB+2K+WsecBBACn30bfjJxXoyoqF4lJlTAbxZM0r1mwE U2m4Abo5gia6hinCyBimn4SIvMHpmAJE9pgIhqEXQywPSCGxv97g13rQvC6wYmIfYhmrwT6x j1VinzRxNWuUJhh340BlY23WwLP1oCgM0hSScEh4wg2BiiaJWbRC+OJAKtko67xT3Y0p/13J b0XJB/O8Hz2LezLLr8v9v59g+H4dK4+itQ42g6QIroQ84ALqAjOkyp0I7NloGGCpc8fvL6cQ G7s51TYtn45AQzoWcWMvE7HoGfONw/KuFKjyAm30Fduk2tkwDIR11IQousZunt22LY9cHtFz lVegmQGJmzTVfrEtW2id66aYHDd1u5pa7qDcmFJ/Cr6DrV13bAFZbHX9l4+++fbwoXz0/WH8 fHr4j+9/PNjpjU00N5RGZygbfFYzyvZU7zjaQbnhfvgp+A7kkhq3/Jdy2X4D+wHS6BcwwnZq uFBRCvlpbSpsA+XWmutn4DuY/Qs2TIcDJPj64P1H93kdG/t1QKcTw0jUTm2istrUzl5zW63u oNzahf4MfEe7oEiHytOxkd23K0simveFtDEFrSisZsTsCd0xsYNyQxQ/Bd+BKIJjiyPzQePR xqbyy5Xx0fJCYS4bRKpMivbU7jhp6xf9nDBeF89TIdTjwfD1iqGQTaaDb7HsrC1WKoGw5TPe 19RyB+VFM8kr47s6kwSsB/4fM8mkU9/kpFM1o2xP9Y6jHZQXzSSvjO/qTPJELrdmEiNsp4YL FZkt39emwjZQXjSTvDK+qzPJ0QB54UxiJJqRMlRWm9rZa26r1R2UF80kr4zv6kxyMDZuzSST NNmpSZpqRsye0B0TOygvmkleGd/VmeTQfLxoJjEKZdQNkSqToj21O07a+kXfmkleD8/xTPJ0 MFyNslCovubNJK/agtal7bS+q1nLHZSXDIXXxndtKOjbuDoUrk0jLS8UUisTkVQ0KdpTu+Nk AXBzKLwinoOhgA3wUxlcnTUUKFiUsxX5hTpsytrVJiVbKDemz5+C72Aw9Mow0sFgOJg1pocg JvSq9JyOOa1i8VZz4he59xDUTge1baNKYkOufxhWrdmzvLYysSCZAhYI32Gp9Ev1Mb0NUZRM zxRqvsD1nOhV8MXTVyQnsc+dPiWEZn2mm7fBL+Vzpd8JdJzvfJYXi56nnOlf4rhQuWMEnJca Y1Lq0eH7MVi9KLojLL1N3F0UgqrsHIPPojc7xJ7EB8qgHRyqPCCVvtQYc1N7hp4XSDXBsyYc VfShNf1Xk6JaWSOtcmKLBysbd6qJb/WQPARrSko4JEPhlmxJ1SL16hdt9EVnW/2dd9q8YQ/f 9f6G9X5gipgoAcz5YoL+slmrLWYhOmf5Htxg9MYsD9RCxySB8pjvO72XEablPGqRns2xru6e z8GYtlYlZmaR9HvltsiBEZl3UmZ5ZqRYLdgOF7kqINsgpUKWDcfYoPiJOYk+0pTByHlSy4C0 cZHRz/hj+Ty4DUsNHtlkPSJjVBNWdM1wRCcKgTt6x7KowlYzGr3adoqPWRaHViPv1oMyMViU leGgDIk5hkmPydsopSaMgyDqVt2dd5q8sZd61/kb1fmRwyMzu+upOXBH5iDExmwPBkBisTJi JsOm5jEoIqI6uTiIPwJ5LkzWCp0ZK3gbQmM5KYMkKJel2L4TGSd1KXdaPqtVpoCpPSNRBqlm Mms4Kiyg4a6ijjRx9XOetDIRjRw0fyJXjdQkZuLgWQI2a5cQeF4gJMSGDDY3SIYzMX9lUpMa a6QziTLSr/LkzGrkWT0gCUGaEhIOyU64JVNRJVmLWmhAHJheprbOG83dWBK/a/hNaPjgU4+g AxD3e7HjeZ9MVt+1pVCGC2vIShnbiICGkUzWoDSvyGSxGgIzXMBSDcwxKbAxNWSSie0JapXZ LhBADchhsXL0WF4tNVpA9Yh5QqK9BCTikCUV7kgKRVUySyl6KT7jI0HQxiHLyK+pSw0bpTB7 jIGyQGpYjhmOJvqIu2WWjapWWBvUtkJqyYOVjTvVxLfaSx6CNCUlHJKhcEu2oGnKXLRKG+LB tLTq77zT5o25/13vb1jvB/5sJhIMzBez/9dDo8CsNBe5LozI5lQlIrEjMl87ppNSGQaJgasX 9OAihRa0s6UyyW3Rg+UgZEAvihWTLQZZUYSLrWnzCCM4rbkIOyAbVfgCCRr/MXPkbLSFTDmB 4oC9ljhhEXlsEDQrib3ZOjFpz6CkapATSSI+rQaNDi4TRV8mSaTaiuLGKkyFVWvwPteUoIOw nXZwlJxoMHmKNkpZFEv2q07O28rzjr93Tf6+NHnw4SY2aC/cxncmgpiDsC5ZJJRpKF6SDsUS UgOzK0QlVjQFfFNbOIGRp84RMI7SbbAIPIuBxs4qTPTWoZJiMGqVxSTsKgWyldO4C/R+mMYD E9NEc1vkpKJpXJWk2DdaJyWLCEqqBjmJIKarcrdodFCHoC6LIC4fVRQnVuGyi23Jt2CYPASb cgI+yk5UmExFHSW9SUjY6OW8VdKNSfpdm787bV75ggfGFy3HCWxGt+sSu5dMfTNJa9o3+QcZ a+6owrTYIaRF3yFPi40tV5nFTs+lKtFPiz12D9Nih5jpAhXsWKfFRg5kJB2xrxYb2xWz2Dr4 Jl60tjKNK1dUEUe3yNqgQAOELK0Qn7RldEiLpE+6JdUqGjdWqdNii3dBoUQEm3ICvuCWcWcy TTMCajbb5L/q5bxV0ku+33dt/p60ee37DfFlnjOCm5HGqDNgedpshAMoa8+lvOlcwQPqxdc+ bbZvfrXZCCmazfYIy6sAmZ5npU+L7TvFRhhdB8EEu9NhSYyda6xBRy+rzUb00my2skHES2+r zVaFUlVrSntCSdUgUy/CR21NOqhF0UfdimorihurZGlcfAuGyUOwKae0hGFIhclU1FWdUVmC 3Ru9nLdKesEX/K7N35U2r3zBA+PVve+F0kuiBySZ3cYBhOobPRX0PDj68QvOQJfG81gZRyxK 6RwPkE6hCzByb4/T0oV6Q6vcC1c8iW5NwAiZrsOUtYWK2C9k35mRBKOp458FRzTIr6fTMOXG gxg6yTJkRFyJCscJFm6OaEj70FuACWww17K+LfIUBpTQ2C9jBdY9Lamn9e2NAVgqjhufzF8f oKwcdVyk0XHJgCazSnOrNliGbLyd7PagAnERTCbwcOAgAxZToLU0OyXOs2TVeYuX9CHzxA1d N88IBhRyJeBncUPmPE0XHT1Qq8bOO/1tB8TG+e1Ace5w1uIIcOYp9MiAax/lziA1Y0y+Ea+n Vwhn4DMlMGMpPuj8Pcay9+Q681iM5+n9jF46xFNK5YEeQuVqVUdbSsVxHD/kIE+VdFoav+Gc RkmBZGdPGW6mlEsDPvDiKUWsHrBSLTWbo5h0VjdGGJa4pcybARAty2ZuEnXDHbtF+jhyl1gT LY5iVsFxSy/NphnVYrzqzHhZxTkZbn9xrQf3EJ0TfLejvy1yhCSuy+Gy57eQo40cjX+GBVo3 bnIPzMhZNXbe6W9qeJ9tVuIS2EQmgbeaz7psgWeaeDKpRO0WfOpU6VBLKve6FAFnoCQeR8VQ JDJItEUSm5Wzwn6zRpOjHpkfsCAVr/i9cHDnQcwF9tIoKl1DTrRWfzIOGHUgZ9WbISgcTMoh QHohWzNSsUCpdUKvvGBBOBsHyqSGOzGjs2kQy2SqbJypJp7VQ7IQLMlIOCQ7YJZERdGUtCiV DsSBdLPo7LzR362slnc9vx09H2Sx5GqB9t3U7fxu6t7Evpj1goXImoAXmIAXvj18CB/dp4cP /qMbFop/Z/4WV/l3Ywu96Q/W2CFlD08eHz7k+Tbwd/M8BPz6xA7ePbSPoT3M5qxb6wuQYfYx kI8LGJHg46aX4IiOsDxHQ1DQHnyyrt75RwJ3X8lSWJupiyjE4zRZiu5akmqM0UYlDzCGrvFn TlqMSyY/MHSBiU3JDxrJhWkRTM/gAXZ5VguPr2Na4VKJB9gtXYJLSCsz4WNJpOj1pPaV2VuC VJ0ddSeO6rirJe7qOtfHPNLvudg0equPfMPAisciQRyqPGCNpY09T45hMbZnjHaBlOqKIzHf Urgzg1GTqhxZI72ZiRzgwkrGnWrim+1NHoS0SIo4TIbEbbIlVYvUSa/pI9appY3+zjtt3tj7 vOv9Dev9YJcUtMSslwn9oRxncSfH+5rG4Eg84I5yVC4W0y5xj0Pkylp3Vmhtzb1q48qf90Mg Jpp5VxT3SI1TiM8nndHB+jvOcggWXVWtMLoa7+c9VQbJbrAyHLzbynBH7FaMqpmlJXo5gRsX XM2TN1vXJ4cJ0557rLOtvbdFAyEl3wxDYrRWmFOYiw/6zQKnVlKrE0niYpbFn9XIufXweUIy ORkOSpCYKVejyCRutFIXxsPQ0NTaedHf82bgXctvR8sHH32n/Dzo23/236589JVODMscSzxl oFoqdNTSmZEKwzFad/J2hkY3QYTbApu6kul00H0MXMHepcwbGSosX8qR7hGya+UuBajGAWE9 mu6ZIKyu4K5h4UUyhp353EZX16ZeFBe7ncNN0ZFDE15tGui8N8PPthyCC5RGx4fg61Yq4eUQ XCjipZVGay/MTSMPKk/urCY/N3tIHoI1JSUskqGwS7Zt5pRR6qTY9EE+TE8bDZ53+rxhCN41 /6Y1/9Q4pKJsR1C7D162K65T3MeWDf+Pu0zHJ26TGRTQWZSYrJXoHkw108vM8x/MwUx0l+Hk BByZ1KNd+5h8oVMUXMbeeDtcZ0IUeIvkOubKUZToDA/mgkKuCVPCfbUVI3VMZ6QyN0ruzMDA HpyThZKp1ZduMDh8O7M/sKbM90oCB31I3ipcU1amdQGzUr90QWakyw3OY0yHnqtNx0mIq2Y7 YzLMPx14uH5oTAO8fy8VTWD0gS+XbvJsDEcrM2F9IMdy0mVOMjlTUhH8ZAbgMmNvOSjBPTNU l9VfATq6eLeaO+/0eGXiUFCtIBi/P+oW3UOoY4s5Np9jvxnHVrS5T+7RfRnb7DJ22bYR1VuX xva7j83q5lTcARp6ffdo3Gef3Bdust3XscU93rwm+Lwbeg+Txew71ZLErTvLlqM8ClxmHvHB oOTw7Rgwif5KCJ8KK7yikL7qxJTfzJSfWW6amVXTrWvqwXlWsODh12fI/KLADIiBO4dsn+1Q CrMGz0Zt5tZFXEBB4KVbCaaB10jqOQeWtee9bRNSdtEwZF29SLzZ8QpJoyg73nhEWjM9v+LB ysbdrPG6SvWgPARrSkpYJEPgNsnqLrkpcRlQ6YJcTB3N0nmjxxuT1Lu+36C+D6amFmjELjar 8ZpjMDJElsM0I2H6BZ03F1nYugWvWSMF2sAqoQx5jAfPOSQjQ0mcGfb+SP8ZeM3VV+RvfFwN Y9n6+RaHIJ7ArxeDHyryBY+jUS0H4PQ4ys83psG0Apa30/yNwy7Dm2j+yA36Lw8f2gRT5XAM H8PWDynXYt36LacxX7iZlKpoDDw+5ICrZp6VLufn3yRdj7n2GW+vSXfrC90KFLT7rV93qgHN y+pyLfZocQ3PF20FMMRUJ3Q8jvlSEqsgFy2ZI9bvVHfg5/106XW2J+GJT9ttndr5kt113G35 3fi95dLug3X/hdDCp1UMU8ebwbpR98HoWQndvDzQw4btKRG4qY1U9RW0J55xjdHPaBLK88OL x4B/y/Dq28uSNLpiASYjrK4u/rj7QNLW1f95p9sy/nxa5Bhs3BhLG/kEjxXTp53E824APa6D ym9iGuOzX1SyHffhonNYxouN37Fa2wQV1GIXufjnQidhN8j3oYxsIYs1DjFFxMG1EcRlCGYf SFmF4CZ5G9lulLWLh1xfeWJ0cFu1Vz5RuiWSJE6M3S+bL3Ja1Y34Jxfr4HgSSNqB+w2yXsh6 XKUf6oOvi7Y3n+PFeHlOAHWJvb3wc6nhcqLTTBX71N+3zTBeJXRgkeLuWV/EM3XcNhPlCwNw 7uPxoBKmGRHbxuXqhZznN7eZTfefzXPSZOLOb5Fmbpt9j01tZTO1fZkDaeVqMRTrZztHkns6 lPIyFC+G0uW0MK1B6MFRVp92A7lsbc21xQzRfVrkxhHarmhkNfJunRrCMpr81jZNXW3nFwN6 vCv0m+MY83IgO4RhF9/EqECJboe5qNlxjS2Ul1xG9Nr4rl1GFBms+mcuI5oU8l6giUiVSdGe 2h0nC4CblxG9Ip4rlxE9lcGNy4gW5WxFfqEOXQd0UTNKtlBechnRa+O7dhnR4WB45jIiH7VR 9kx59TxHnJmodnEZka/6pxsS99q4uAU70MgkTOQCerrrNIrXlpei6bp8AQljP3ArNeOjnbg4 HjIDoT8sKRVutbp5mbEl/cGz1IGHNbc9mbH5gwdKdCa08WXRnS9D9khlu0+bV7Vw5y9iIg9o ry+7o9+aqcCnWBG9rUyww0vveIZElzwzxNR4MFT0jM/ylAKApoDENaQmBr2Jug6/kg8kchaL QfNt5ikbJoz+gEvhVN28FsrTNxfpK/1hm2nFlvEWF1hl+EfHu8x01WJ3xfzZzulHOivG28Ak PiZk8m1Oltr6A/8ux/38p4b4ruEdr6k6ZZ53L2Henx3pPljeFgWu0nyblD473+oWgGY4I5Md dfh3eZvmFdmQauCB3M63ma6JaJCf3h9aJ547nOxpVguB/tzS7vXvvCgkyft2LBQYbfcZGZqL p67TBLrMvOjGo0LvO0cXPS4ahcoNsPGqpAdO9uCAUApD90uGaK1MGqNTl54REVR91REskloj iBcLGoViTmUkGbSlFvlPpqhHip3JC4KFK4K6YYHXxhv2HJXkJrrgNPZGsIm/6aoClhcGWRPn 7GECIawpKWFJ5tWiQ9/poBezo03ooljqECdS01aB5506rxg5B4lGt/pXwrJH03pkrOf6WEBo QTMqbawW5ooowB39ONYN3Bp4OqetD95jpWQAHj2bj5Uk1hZBTiO4nbWWwaLHqvbuMQQ2Vr+B AgubWAmk4PnG9v7p9H/J1ci7CmVuZHN0cmVhbQplbmRvYmoKCjIxIDAgb2JqCjYwMzgKZW5k b2JqCgoyMyAwIG9iago8PC9MZW5ndGggMjQgMCBSL0ZpbHRlci9GbGF0ZURlY29kZT4+CnN0 cmVhbQp4nO1cy24suZHd11fU2sCV+X4AggDdRxvwzu4LeDGYVc3YhnE1gL3p3x+ec4JZmaUs lRpQL1oQ2tYlK8l4MoPBiGC6O3/85fDvozu60co934VjS/6uHf/zv4e//eH4fwd/xH//+cfB jQfh+HSYg8Lxh03A1B8GAv/q2T8Pf//Dwd2V8XMThFDCGF2cH+OeDiG3u2i9kDNbfbT8mFJc HO3TMaTGGRlPUh6AisOskCLa3t/V4+kQSHDxGZCSG2OLb3dptkMYM05LrwyINiP0uzxhxQCM B8MSC7EQe2zjF6NrwKiABXpTGG3jYsAoR+OP7QGplEHPfNIHPTajBmCYkGo546gNOIS7ObaN qhbQE70tjr/Gh7WNQ/XEu2ZIJoI1pSUskqOwS76ia0peFEsn4kSaWunwtNHo1DgWwvGvf+Ki +mX8/89D+f/60P271/3Ph7/IkIz/xsv++fvQMjF4/P3+P8c//jQsSTt+//t9+Pzw/V+Hb9/H jI2B8N0PwnJ0dzA0vtVBhnq+JdinCGS+QXw5gm1fK2fk0UqD3Bwxx1eILicAPh18HTNTApRK K5fqXZ7todpEOOplzkarDRwGZzDqCYcYSuZs4i11/GL0DKFBeEZpxSIzDipUb7yxPWANwxmX J1CKZgQXFkjBgRrhCK6Op8IdXGdbVAWqVvQGD8WLi9kWf9Yj5zaDEjFYJinDQhka9phFk6Qt SqUFcSDtrPR22mjxZaPwoe/3qO/nhsA3zk34uzEE/ttiCPwwA+kIGGNObCCzVu0WscFGqReH bcujHY6x9tGvFezGmgeLtZbRigNJrbCDsYKw2jyZjbRqtcFjiaUBSsNfa/dAwc0e7LDN6P2u GKzmIiARR3OFOIC5OdhwUdQ8hWuUNg/LKg6aj2OseFN7wOr41570auOTgzAmpOSwSwlHcrCm wp1cYxs0JY8FLVqT98aBWuKMbXJsYykJwZgyEnRJT1ghU1Fjku5V0ifdUydnbZ02unv59f/Q 8vvR8vOXPjZCbuXypQ9f9l96HxzITpnLwQ+3oVjPD8ENJlI5etqvlCAwL/FkN1r4FwLww3al nLUPOAgg5T7mdvxJBbqyZqG41BmbQTza8AqfjWAqDTdAN0fQRNewRRgZw/STEJE3OB1bgMge G8Ew9GKI7QEpJM7XE/y1GTSvC6yYOIdYhjfYJ/bhJfZJE71ZozTBuBsHahtrsweebQZFYZCm kIRDwhNuCFQ0ScyiFcIXB1LJSlmnjepubPkfSn4vSt7Z5/2YWdyzXf7s7v/7CMP3y/A8inwd HAZJEUIJecAF1AVmSJUnEdizMTDAUueOvz+OITZOc+qtRj5fgYZ0OHHjLBPh9Iz9xsG9KwWq vEAbfcUxqXYODANhHT0hiq5xmue09UhDu7VpnQeyAs2M5U6vU70f5oOG1uk3hYB1ctHTyA2U Wx71b4Fvz6OLPBxCFltdZ/fTFfPOpbqQNl6nMwrrGTFbQjdMbKDcEMVvgm9HFMFxxKUo/uve t4dPZfz1PbiH//7+5x2htLxQOA7LZ0TqTIq21G44WQD8OLwkjLfF81wIFe/d3nL4fGUxaIUx XLGsU/YWBSSQtqzMbU8jN1Be9V68Mb6r70WAdft178UkTVKfpKlnxGwJ3TCxgfKq9+KN8V19 L56J4tXvhVGoJWqI1JkUbandcLIAuP1evB2ea+/FznJYvxfiHEthnP3hk/Sxgw7VlExfBT1f cBhJ3Gf82HsyPQbu3LnTy0Cwzmc6/g2eis+VnkhiENFn+TX0RXKmx4Gx1u4Iw52WHqMUmtHh DRisXnTeF5beJu4uCkFVdo7hSNGbHaIR4gNt0A4O1R6QSl96jMJoPIORC6Sa4GsJRxV9GE2P ZlJUK3ukVcca8WBt40498a0ZkodgTUkJh2Qo3JItqVqkXv2ijb7obK2/00abN17JD72/Y73v mEaGzoE5XxyNv+6ZheicZQAS3dHGuD96ocMmoT02nU5/NjoFE8fJHb5uGC3P38FY6I4Zjsy8 Qrdsh9zAyExEme2Zo7BeMD8B2QuQbZBSIcuGIzXsEMKcRB9pyo6HFaOWIUrjImOe8cf2aXAb lh589GQzIqMWE9Zwww1HdKIQuKN3bIuq6D17oBftZnzMtji0Hnm3GZSJwaKsDAdlSMwxTHpM 3kYpNWEcBFF31t1po8kbsbEPnb9Tne/kycbRF/m+5+bA7ZmDcfBl/J9H4lisjVP0sKl5LIoY eLZ2EH8E8lyYvgudOQw8DaGxnZRTCMpuFPN3kYOoS7vT8lmvMimo8YxNGKSayazhqLCAhlsu kGiqSGKeJq1MTZKD5o/kqpGaxNwMfkvAZuMSQpELhIRogcGmY2Y4EzMak5rU2COdSZSRfrUn Z9Yjz5oBSQjSlJBwSHbCLZmKKsla1EID4sD0MrV1WmnuRrL8Q8PvQsM7r3oEHYC4PQ7s7/tM SbjILSAiladORFQvMlkf01FxrGGNAg0VZtAeUVidI1VGYPYNlh9pD2YIrZnM7rOjkABHkz3C CE7mlbADUpHCF0jQ+B/DhiejLUA7ojjArRInbCKJAXvMTuJsjk7M2BiUVA1yIknEJ8NvdHBH EH2ZJJFqa4ob6zAPqtHgfW4foIOwnZw1Sk40mDxFG6UsiiX7s05O687Lx8wPTf6+NLmTzUoc 0F7psXcW/ijgRumpQ5mG4iXpUCwbCfmHIioZVgXf1BbKb/LUOeJrUboNFrJkE9NPs8MsvyqK isGoValRwq5SIEc5rbvAg45pPDArIZrbIic1TePqJAULAzMLBCcoqRrkJIKYq6RjaHRQh6Au iyDuFGqKE+vQwnIs+RYMk4dgU07AR9mJCpOpqKOkVxHclV5OayXd8MU/tPm70+aVN3hgfPXO OwODkh47kqlvJmnfz/Y6BBlrOk9hWuwQ0qLvkKfFhndVZrMzSKFO9NNiD0dhWuwQM6Mdgh3r tNhIgEXSEfvZYsMzMYutqkfxktzZYqsjmXK0ZG1QoAFCllaIT9oyOqRF0ifdkmo1jRvr1Gmx xbugUCKCTTkBX3DLujOZphlkNZtt8j/r5bRW0mve3w9t/p60ee39DfGFQ/KF2gsO1JWOCPSO 7HX1jYVBLF5xPPIXFNCWxmKejPx8KZ2aQNig8LQAD6ay1LZQcxiVe6HFTDwBAUbI3arc6IJF +BvZdyZNIHTVDhbk9xVx5Pki5cYsvsog0tETV6LKUf5A54qK6Hk0IMIGdUt7LTKFjxBs47wM C949NeGpvd4Yq2V9AR2nzL8+IIabo2oNGs84jH0yiZcbzn++J8jGW1mw71YGjcWIigNkwWGM QWtpVmLMQqTqvIVW+pB5okNImdMBHJJOWE01uiFzlmJFBGbWGjtt9LdeEqtzsgPFueNch/rR zBLmyNhsH+3OeDbDUb4Rr498ErDveEpVYRcfVLyN3ch7cp1ZU+FZ+p0xSxUgpVRWgxAqdzvV RZSKWg4/5MAt6yCdlpYZeU+jpZizs18ZmaaUSwM+8OIpRVgf7HSlZjtTks7qxgrDFlnKLCtH YI21GbYOC8+wMyjIlbuEpViGpvBWcDwSSLNpBsAY2joxtFZRZEH3GXdC6IP0aMUWrBttkSsk cV/H6Z7vQo62crT+GUFo3bjJHZpfa+y00d/U8LYgvMQlBoqkg7eez6rUZ0EMy1pKlLfhU6dK h1pSuVNFPQpoJB5HxVAkNEnKYkps1s6KEM5e4mxFJ/kCC1LxCvULBz0XYi6wr0ZR6VpyorX6 o3HAAAU5q94MQeFiUroBGVCOZlBjgVLrhF5ZnS+cjQtlUkNPzuhsWsSk39rGmXriWTMkC8GS jIRDsgNmSVQUTUmLUulAHEg3i85OK/3dSoB96Pn96Hkn4ZWrxeQ3W7fz+/dAYowmQBZqhS5R WTwCImRIP3APqslC+hJ6YbCfSQcW6iqIUFimCwvIXZ2FupYEYLmLtZnGWNIDvR41vjInKUjV WUkvcVRHB464q+sMk7B02Xvu36K3+sgnwITdcNhccqj2gDV2Yfs9AZONZ+RxgZTqGUfCX8Od PdtGVY7skd7M9AS4sJZxp5745niTByEtkiIOkyFxm2xJ1SJ10mv6iHVqaaW/00abNxz1D72/ Y73vuPRB3lC9vB4Wyr5hSI730sbiSCzkRTsqw8hiAtSrRzqBqs2XG8hAZqOTyjp41Oln3omj O99o7XxmLX+lqxhnO8gGzl5hHXy8m/fxDJLd1DMcvMNnuCMca6Nq5h5FL/ca44KOJ3kzFzQ5 2Hb73cMltPHe9jdCSr4ZhhSc2fFx0Atzn+QRMXAXILUp4NAgLmZb/FmPnNsMnyckk5PhoASJ mXI1ikziRit1YTwMDU2tnRb9vWwGPrT8frS889J3ys+Dvu1r/9OVl77yvG35UFTBd+ulwpgE z92pMPIoF4lV6I0n2ogTNs4fJfN8rLpzOluHlFl5XmH5Uo48yZNda3cpQD0uCJvRVE9PWF15 DMPCCzOGnVVKRlfX+VMUF7uF4KboyKEJrzYtdN4P8HMsl+ACpfGMLvi6fSe8XIILRbycb7T2 wowreVB7cmc9hXQ4Q/IQrCkpYZEMhV2ybTNTSqmTYtMH+TA9rTR42ujzhiH40Py71vxz45BK X+oOtnH6diXKh3un2fA/HTJjdLg1MyhgXANhsMwaQbQzQ6KsamRlQWJkB/WAiLlRj3a9PfnC +B24jL3xFiwyKZW8RXIdc+UqAleIFypagrQqC518NY+ROmbcTEnKkjuTjTgucrNQiZDmMmKD 2GRnohM+ZVbGlsHRGiJTPtBhZSA28nBa7UMAkdEhxDmxHXp6m46bEL1mq5wc5p+xJlyzGtsA 7xmnog2MYePl4wKs+ORqZX2HD+RY8aTMTSZnSiqCn8xYc2aYOQeVbWVGpbPmKxbNaORac6eN Hq9sHIofF+SdtgXl0T2Eeu+d+/aQ7130X1xzj+6L++rqQ7kfnf7waTzQU5dccd19OVee76Jh gHKLxn32yX0FkOS+uXAGsN2uEJ5tmD1MVmMpL3tJ4tbdzKVAVTH6zMJVLEou344Fkxhag/Cp sMKr2AyrJhayZGa3Z7tpZ1ZPt0s1g/usYCEYrdeQqfTAZN/AnUO213YohYU/J6M28+giLqAg 8NKtBdPA6/L6nQvLxvN+6oSUXTQMWVfMiTc7XpU3irLjzS7SmhmkFA/WNu5mj9fyNYPyEKwp KWGRDIHbJKs7s1PiMqDSBbmYOpqt00qPNzapD32/Q33vbE0t0IhdHFaj32xMKzvCbE4O04wg USAz4h8+hfthPwKt0cMnf+/yVWuknBBYJZQhj/HDNnZ26V8j4MedYRIqvP4z8HohHCYQ+L+c DWNRJwafH9q9Dw+fxt+CwTGOH0RoaDR/aA5z+8inaTwNNxjgFvirGPDYzrYMjAMCBPe4ZuCb yRI/ibOzrTdW9XByiuEF/OiHMrYI8BXHXzfHPhqgRUBtQnNnlVESerzG81mjvmDyFLWQjF+/ Guj1INJrpBIcaZlE6Jf24JOpScM1hD+EMyw/3qKhsugNtNAY7K/OGFhmTejdCP2scVD8elAx nG4R8JT7joDXAnxcQX0UbnbC45B/zBx/fRvGMunrC4X29qwF8LheiAG4kxE1f1yTtQg5LPSI 3PNbKH5NW+e1vr+opgbDmsNLpmd7vVK6sR6G7MNXE8lLcmh1yuGVrw+d863gYuEbLQqqZIT3 IE7KlyU79aS/iySxjmfr+fI6P7mU95nb4ZrZe7ZaOMHDR1srK290y4Ud16j4PKS1/TobgfBs ssGbr+/wDp+932t1DVT1fmdBYD18Cvfrl+DZy3y5BBf0TsI+25CzSM9vmiTxoknRul/Jwd16 hWq4fIHipKKucOwKg+LiInlcmYbHzbQL+ZOHsRtMaNvNJPZpc7aCMgOXzqvy86WtWgnnxclG fnmt6tMy/MrSW9tUmkGQt14QpsoXtcBSj1/zAue2On7Y/m2UTBm6n1Ykv2iU4+a3vrAxF0Jb 7f8Q7rLZcdRmz7+lG2EyDUmAm9V2fm8o3zMDonCtov2bwUHVOVZLrTsLVrhrNxhiVMZB2ZyL npX4rqHc+nDhb4Fv72N50XJT+fK6dPD1wdMO7ItE19InibqnPVFZz4jaErxhZgPlNZfp3xrf tcv0z0Vy8zL9QpqPKxTWM2K2hG6Y2EB5zWX6t8Z37TL97up41WX6SSHvtU9E6kyKttRuOFkA 3LxM/4Z4rlym31sOz78v46MO34jZ4UY144Gs07r41Iuv+uxd4vkdV5xxqo2sIkYpnGcIUCo7 j7RFsSWvg/rzqSssbleg8Qtw7GWEaQJh49wX7CHcyqYbGhCv+jK2WnppntErGPZ0fs7wVWju m+ueIPU4oPllbLgeG27gfotzjpvnPu7gNLWYswlgTYV23bdE4dcTPk3E5HGn0KjFzCzxeNQR 80PMsa4eZpzXn3h9KhwrP0F0fsjKyycWlsdjTYFC/flQdM17LBqUpMFhWR7VwrCIiIm8k3V+ 2B2D+khgj4cVqe3KQjk89I615PrSD/NvbTydnIyX6ZgCgKaAAjSUGAY9ifomWiUfKMgslqDn 08xqexZ+PiHecqzEw2cMXEYGkp8s0qDEO54Gx/uoFc8yy06LXQ//2a7mRUZyxtPAYjwWVvJp Tlai+oSPM97N783yWcMzR/FkXnErYX5EKTK2sjwtyuql+TSpDHY+1cW/ZjgjixZjAffL0zS/ kwSpIruaKHkkBhC3iQb5oqCDn540PAdU+DfrhcBgdwEdqFRSvpZX7C1PGi1uEJm3jMeuqmJ9 0aroIweFqQmuLoajtApVOGHrVRUhdMHAAaEU1jUslZ61sviLEW+GjURQ9VVXMUhqjSBeLGgV ijm1UYHRll7kdzM1I8XOyg7BwlcBumFBSMsb9hxVrCa6EFH3RrCJv+l2ItsLg+yJc84wgRDW lJSwJAv5MdvhdOGDHokJXRRLHeJEalor8LRR59yndpyzeVVm81Gpiw9OyT266NkHhtZQXuOc vTW+a87Z7jeebjlnBtxuH2y+J3TxrSEjatuzb8usobxKJG+M76pI9j7vsyOSvxz/H/2ueQQK ZW5kc3RyZWFtCmVuZG9iagoKMjQgMCBvYmoKNTI4NgplbmRvYmoKCjI2IDAgb2JqCjw8L0xl bmd0aCAyNyAwIFIvRmlsdGVyL0ZsYXRlRGVjb2RlL0xlbmd0aDEgMjIyOD4+CnN0cmVhbQp4 nO1V328UVRQ+d3dnWyql27JgcUHvOAXBzpa2KEpSYNPulv4I3WW3xRldI9Pt0C7ZX9luG2ok RYOKE0BNjCFqQgskxhjILb5gfJGoMTHyoJI+aAw+mOiDxmhiYkza+s3sSivpn+DdzNzvnHvO +c65c+/ZUnHCpLV0ktwUSmWNgp8xwviSiDWkJks8ufGcBPwDdLGjhdHsre3XfiJyteIxRzNT R5vU574h8pzH+pEx0xh59cxSC+S/IO8eg+KFhSeqiCTYU9NYtnRcYT3VkAchV2fyKcNP9pKU xMubNY4XGmgzEpBGIPOckTVvHNrwOeRT4LtdyI+X/HRsCa7OeqFoFhqb/7gCGesEXmLkpI+K iHkd+f/xBr1Or9AV6qWLpNNOeoRUaqcjdIgUClMnyXSDPqOv6BO6TC/Rm/Q8vU0zJOhdCtE0 nWLv0Cb3vLRfeo+ekuoFqYLW94uHY5rom9QFKfsbhbdZ26s7uhM6vyXY+pbGoGAq/1asbQ4K l9of1yKKLgeFW003chGKabII6UHhUW1XWZGf1b4P3NQDsNMWAr/qAUUWUrMmuid1Z0HXEU9S a5NPBoVXnXuQnQY7P51MBgQhTJU61+SoQndU1WpDPd+zMyjWqPyETfIpwnDh3tqrcOHZ1ico plmmZXAbPB6QZT1gOVK8LNmENeXsfAGfjIj3qPxrp5y1Kt8pqpqTGucHlG7jGNf4yHA5hG1X azODmlv8gNVtKBa3FIdOsYOLECxRn60QIdMW4LPOYdo73yjLAT5vYRvg1Itshiq5yY5Znarw +Qq5wrX+REAWTNcsFNSrWAq3ei3FsB3KLvYUFD77MzQg73q7ABs03FWAZU+KcezIykps1/Uq irBetretb0SxqgSPaR2Bj7HiVz+gEAt1drL+6z5KkfO2jYc0+x3XlGFkr3QGMDGlEzsfimvX iFNXqvMa4wyT4Cmxydz8L9cGVUCLfcEraJ9aF84muUakIXQmdJBd9XL9VrleDrv4YhM7vzgm Df39fthzEzf8NvrDtGeGaolk/tA232O7ZX7vRl+V1x1c/P3CzMwFVsdqL128eGl2xnX/zOzs 7MKPs7NOZzi6a9fVp88++kxdx5/0QLVzWb74ua5m5eWRppEBGgzyKQ/4VR1emF5hcnePcbl+ obA3aedF5fbGnHrWVWK4ILto438c19HVO+L0nZiMaiCxilcVbnEZu6F/rYI9wG9VsIQ9uFzB XujnYMk8ayAt0kcVzMjPPqxg5MRuVrAb+u8q2AP8WwVLdJ/LXcFe8ru2bE/t4O2trXt4YiLH D6ZTxfz41HjJzI7z3lyqpWawJxKP8HA0kuAD0UEe0XoTg7zs09bG+yYyaTPHB4xhs1QTi0e6 ImEYdgT3LXskhrq6IpHwsk80k55Mm0XeY2Qy+VK0YOYSU9nhfCZujk5kjOKyYhkdNovj6XyO t7W2t7Qvq2k7zuoOHMN2fJZW2gOUoAnKYT5IaawVKU/jNIWnRCZlMXO0zRxWWrCdg9RDEYrj 4TicUcwJoAGgQcwR0mCbcPBKnjb8OPWBJwMO02EbIIOGgUuIGnMiduEJVyJ2UJD2rcqRoCFY 2ra29Wo8UYdl0mEqQu4BUwa/PLiiVHD4E6gwC/489HFoRp3cDNivZrGa7rATfRwseaeeNvC3 Y4/aV7XG6XHG0ijuwyrjOlt6UbCz1C+qY9ocY+f0uW678wof/lT8cYCT+hZ0yKSmC38z0T+i X6ufCmVuZHN0cmVhbQplbmRvYmoKCjI3IDAgb2JqCjEzMDAKZW5kb2JqCgoyOCAwIG9iago8 PC9UeXBlL0ZvbnREZXNjcmlwdG9yL0ZvbnROYW1lL0RBQUFBQStPcGVuU3ltYm9sCi9GbGFn cyA0Ci9Gb250QkJveFstMTc5IC0zMTIgMTA4MyA5MTddL0l0YWxpY0FuZ2xlIDAKL0FzY2Vu dCA3OTkKL0Rlc2NlbnQgLTIwMAovQ2FwSGVpZ2h0IDkxNgovU3RlbVYgODAKL0ZvbnRGaWxl MiAyNiAwIFIKPj4KZW5kb2JqCgoyOSAwIG9iago8PC9MZW5ndGggMjIyL0ZpbHRlci9GbGF0 ZURlY29kZT4+CnN0cmVhbQp4nF2QQWuEMBCF7/kVc9w9LFGhNxGKZcFDu6W2PyAmow3USRjj wX/fMWtb6CGBl/e+5E102z115JN+5WB7TDB6coxLWNkiDDh5UmUFztt0qLzb2USlhe23JeHc 0RjqWuk38ZbEG5weXRjwrPSNHbKnCU4fbS+6X2P8whkpQaGaBhyOcs+ziS9mRp2pS+fE9mm7 CPIXeN8iQpV1ea9ig8MlGotsaEJVF0UD9fXaKCT3zzuIYbSfhiVZSrJ6aO/Z43Sn9rF+2oBd maVJnj1X2B/3hL/fE0Pcqby+AYr0baMKZW5kc3RyZWFtCmVuZG9iagoKMzAgMCBvYmoKPDwv VHlwZS9Gb250L1N1YnR5cGUvVHJ1ZVR5cGUvQmFzZUZvbnQvREFBQUFBK09wZW5TeW1ib2wK L0ZpcnN0Q2hhciAwCi9MYXN0Q2hhciAxCi9XaWR0aHNbMzY1IDc5NCBdCi9Gb250RGVzY3Jp cHRvciAyOCAwIFIKL1RvVW5pY29kZSAyOSAwIFIKPj4KZW5kb2JqCgozMSAwIG9iago8PC9M ZW5ndGggMzIgMCBSL0ZpbHRlci9GbGF0ZURlY29kZS9MZW5ndGgxIDE2MTMyPj4Kc3RyZWFt Cnic7Xt5XJzV1f+593lmnhlghoEMzLAk88CEJQyEJRCyYHhYXWgMJpiCSoUAMdQECAyJsTWJ W1XiEq27rUGtGo02D0OMYJKKtbu1SWtbl258Wq1LzUfbur2+hvl9752BhDbtp33f/95fZ3Lv Ofec8z333HPPvc8MkGD/YBfF0U5SyOjY1N6XYlE5Ef2YiCV2bAnq9OCSfPCTRNoF6/su2fSV g3/eQ2SvILK8fMnGbetbO2+4iyjeDdmPN3S1dy69p9xJ5IU9Ld4AQdPUVRpRihfj+Rs2BS87 R/k4CWPgKXljb0d7tqVZ6Jswdm5qv6xP5/vFuBNjvad9U9dtX3l8P8bXEM3Z1dc7EHyZ8sJE BS6h7+vv6lvygxWvYVxElPAzyBje4hUH1irGXFEt9P/xy/IMpcv2KKWr2ZROFH59uk11h18X OkH5O0jW3EiLvkL0BL3McplOo+xT8tAnLIUV09mk0seolv10gu4gNzXRnSyR5lMynU9nMxU2 AbqR3RfeEn6bzqDb6MHw0+yq8OPQ30Lfo08QwW9VRuV0LuzPpy56W3mDWsL3ko2uo1haTqtZ MrXTL/H+EDF8lW6nb7Evhz/BrG66Cv4qqIqqws+FP6M8ulHdbXnF/hTdSoeYNdwR7qZ5lElD PBD+Zfh3lE0t9BA9gZgCbEI9izLoUrqW7mYpyvfA3UHfoCkWx1uVGsuzmOlsWks9tJWG6HH6 EUtkjZZXLO+HvxR+k6w0h3IRUze9zcrYSv6wGhdeEX6NLqRx+gHWK94T6oXqo5YLpyrDXw9/ m5LoaRbDDrPnLCWWm09cGX4g/E1UZDYVIyPnYp51dDU9Rz+kP9Nf+I7wDjqL1mDm77K5TGfZ yPgveQrfzrcrL9FCrLYV0Q7SHjKxI8/QITqC3PyKJukN5mZp7By2jt3K/sLjeCc/qtynHFB+ rjL1MeTbT1nIUZAepoM4zy/SUWaB/yLWyL7Ietld7Otskpv8Xf6xalOvVv9bPWHJnpqc+u/w ueEPyUup9Dm6nHYgtw/RKB2gn9Av6C/0V/qIudgStoE9wEw2yd7ldp7JV/E+fid/mD+pnKvc qjynlqnV6qXqi+prlq9Ydmnt2tRnj0x9derJqZ+Gnw7/FLXjhP9sqkdGr0RVPEzP0kvw/ir9 hn4v6gf+l7ML2BcwywC7nt3OnmTfZT9l72CVJN+ZfDmvxay9vB95uop/ld+O2Y/ifYy/xn/D /8Q/VCxKprJY2aw8oJjKmHJM+aPqUrPVhWqxukq9QA1jZ0osZ1rWWPZa9lm+bXnfWmHttPZZ 39Ku0q6x/fhE3onfTtHUhilzahS1a0MlXY5M3E8Pou4PYA9+hIz+BBFP0gfYhVSWwXIQ91JW zxrYSvZ5dhHrYlex69ht7G52H3uQfRMrwBq4htgDvIqv4e28i1/Dr+M38QN4P8N/yH/JX+HH EblH8SsBpVg5W7lAuVDpwRqCynblGmT2VuVx5ajykvKm8pZyHLvmUeepg+rl6j3qo+oB9aeW z1k24f2g5VnLhOWnls8sn1m5NdWabi20ftG61/p7zaot1hq1G7Sfa3+19bF0lofI9VNvC56C MziPP87d6g52HIK5TKV4rDyAfViDU/FXqlSmsC9OoUdsSTxFnSOQVkM1gQ+yQ1TGvks7rFzB TaxOUoj9mk+qz/Mz6BesjaWojyo9lh/xDNqH22g3P8wPsWo6wCv4Wv41hdgbbC+9gXq/jG5n l7IB2seOs2XsClbOdtDPebKyhl1DFeEHucrs7Gz2PiECulLtpC/881uQLaVf09tT96sO9cu4 n8boTuzoE/Q79hh9yizhd3G7KbiN2nHL3Ih6v5bErdeKc7YD5zEFN8hG61E6IJ4oWrl1hXo5 vU//RW9bnkFFVeMmfXOqW71f/UO4PFyAE4ZTRntx7jbQmTgxb6BKjmAsRhfhpMfgLinBqW6k C6iTrsCtd2vYDH8tfHV4W7iXXgD2U5bPPmXDOBFjQFTQD/C+hV5lu3AOz/yfPQWmOmmC3mFe lsVKcB6OW7ZYdlsetxywfMvyorUY2b6G7kNF/x7VHIMVdNBP6R36mNmwNymUT6WIdwlib6aN vEU5QjUslfpwZnNxj1dHVzIAL1che1/DeT6Cs/E+7omL6Fv0CuPMgxV1YH4b/DQgzxfD+hHs 4NVsFJJO3Np59Ces28mW8CDmM+DpTtxaE4jp1/RHZDss48rHvVDL1sLXx/R56sQMi6mRjWAH DtJS3Ky1yo+R7/nMRdUsk30DuDacUCfNpaWWPzBO+VPnhpfwbuUInjFhyIfx9EqjM9hmRBGP dZygJLaKyqZWI4aXmKKa7Gcyint4V/g6ZevURnqBHsOeGOoWrZbIqGoyKlecUbF82dIl5WWl i0qKiwoXFuQH8hbk5mRnzfdnZui+eXPT01JTvJ7kJPecxARXvNMRFxtjt2lWi6pwRvl1/vo2 3cxuM9Vs/1lnFYixvx2C9lMEbaYOUf1sG1Nvk2b6bEsDluv/xtKIWBozlsylV1BFQb5e59fN F2v9+hi74Lxm8DfV+lt087jkV0p+t+Qd4DMyANDrvBtqdZO16XVm/ZYNQ3VttXA3EhtT46/p iinIp5GYWLCx4EyPv2+EeVYwyXBP3bIRTjYHgjJT/bV1Zoq/VkRgKll17Z1m43nNdbVpGRkt Bfkmq+nwrzPJX23GB6QJ1chpTGuNqclp9G6xGtqlj+RPDN045qJ1bYG4Tn9n+0XNptLeIuZI CGDeWtNz+evek0M4T6xpvu5UbZoyVOft1sVwaOg63Zw4r/lUbYboW1rgA1ieVd82VI+pb0QS G9bomI1f29JssmsxpS5WIlYVWV+Xv05I2r6om3Z/tX/D0BfbsDWpQyat3pYRSk01xsOTlFqn DzU1+zPMyjR/S3tt+oibhlZvG00x9JTZmoL8EVdCJLEjzvgoE+c4lema0UlOmguuYfVMZpmI yH82CsLUO3RE0uzHmpaIrmsJDXUsgRleLQwosxM70m3aa9qGXMuEXOBNS5bLrw99SKgA//F3 Z0vaoxJrlutDEqyok5lSg36aNwMBMy9PlIhWgz1FjCvkuKwgf8sYX+zvc+kgSB81IrftLcsK kf6MDLHBu8YMWoeBufO85shYp3VpITIKAy0mbxOaiWlN0vlCs3NaMwNv86OSD8gvCkmmLXvm X7wreU7dhmUmS/4n6q6IvmGNv+G8C5r1uqG2aG4bmmaNIvolM7ooZ86paVbSeJTjaYrUoigv mjEWg+Y4U83CP6ss6k5TQVFKAdPrTVfbWZG+JSYj4x9ixjTbKaCx8PsCJclJWDRKc1lg9nj5 rPGs6OKGFMSrZvOGpguGhmJm6epxAQ0N1fv1+qG2ofax8M51ft3lHxrnj/JHh/rq2qY3dCz8 zK40s/7GFixiA1uGYuVUPeJn1583YrDr11zQPI6vd/r1Tc0hznhNW3XLyHzomsfxUcWQUj4j FSNdjKiBodBD3CZVaeMG0U6pVaVAjjvGGEmZbVrGqGOMR2QuKcOrAB9jxOZb8ManAo2qD3A2 ZdXGeKUxhyzqlEIxmjrFKMVmtUxx5TDLJjs+DHvJG3B9VHGi4lzXBxUrT1RQJXjXZ+iKizIS MhKy0DF8wPhMVyY+Myz036SrE+Ib692Yy4/vYXb2E8NpV6y2FMVjUxNtXFHGwjSaGFsJOjF6 YWupoEbemqZSpUSzuTXNptg41xS7yrkdA9WAjWpAr5ZYj1qYZYzvMlKM2MbYtlilL3ZnLB+O nYjlemxRLI+12aNOBTWca9aU2kvw4aMIjzuFAByNKR70BrCWViwmEKhY6Wpt3dz/UXSExVVW sITEpUsJ7bqFAbyuu+I7I1Ze09Q8Tkp40rA7c0ptOjoR9dN2R6nNQEfCsqW4qEZa7TwYW2bb GVsmF3ZG6sJS2xp0FiVZKVEMRa1XrrXttg3bQrbXFet3lKO212yKrhTaSpXltlW225Q9tmFl v81UnrXFasKDfVFZKTfQYTRpOApLSrkuOs1dBsldhj1jYSlvQiet6+fpGKGzcU3zcsWj5fMc bTlfpJ3LDe0ivlazu3matpLXafdq+7QX+Kv8Lf6m9l88Nofnaudol2nXa09wK0Na+gPTLxJZ kmuk1kXY8ASx6wl3M503szlTL58YsTzzWYHy0qf1yuHP8BGC0+rwW+q96gpy4JPWXcZZb7E3 bR/P+ThJ/T5/y8ITUywpdt7iWjtnbXKL9y5+t/Vu211xY/Zf8F9Zfm3/Rdybljetbzlcj9pe 4D+2Pm/7Xpxl0HaD9RqbkjDGg6GYWA+I4VY191IttS2tL42nOTMoJbW5Su7syuPnujZ/tPI4 VR6vPF5cRJtbsZaaZsPe7VqfuD6526uyViyDtc4pTVy8qISS3OTPnJ+d5U5eVLK4rDTbn2ld PXTia39mpVM/fPe2qY+HmH5nT88dd/T03Mkzb2TWoanvv/fnqeevCe+9f+/e4a/t3Suq3Rd+ i99q+TpW+6KxQCed+WMWxC9znuNsiddSksirJCeRJ3GOm3kSuZt5FbsWo8V5xxgz4skz7DE9 ShvIhEfxjDE1lMTcWOIoJYnzGTSccbH2wphCokJ2MT53wsLI9SrZnsTzkyrde9z73Uqbe6d7 t/uY+323hdwut+4ucqvulNTLhiO1vrm/wSxf02AuxzU4Tu7wxJKWipXiDOMYuD5IeZ28yJU4 1zB9HeWfsCger+Ii1sqS/AnuZGSm3GP1Z2Zn52SXJfjLFpVlJfDLJ2Jz0nPO8a778ucuXxpr v/JKlqpmT041XRVIT3stb9F5dcV3sKOTL31j6gbUQxXqIQf14KZ09tA4ucKfGPWxS++x3+u4 07XX8mjMIfshx1iqzeZmZ/EzrfUxq+btdRy0Hkz9fswP4n4Z80rcJ9rHDkd6fHqSkTa3NMlw JpTGJz2bdDRJSRLnPX5epaRODyi/yYiLdyY2Otuc3OlNZFAcTEkrZYsSSdjM1UslzVwQoYGC CPWmS2rEO+NLh8Vz0oWwL05MFBuhxiZ6xUbMj9UogxUmZaxyMmdq4byL5/XO2zNPnRefYTMc 8aW2lLndkRoMiCJs/ah15fEPRB3iMWa4vUauu9JrzItHl+ZCl55QKY9U5QnoxykRQcAiUQQD I0lhJ2ho2hT7I8+jBBAUiUtF0CGPIOaoPWaFHFZlVAbEldTyegC72SqndxrIklNM6hTTOw0k K3JtFVbg7sPpxs23SOz5ZmoNMIvV6tex2y7CEVEyRAksnpONw6FZPfxT5l389v6pP13bzdwv HWeJ1hOGclV79QU5ymVrL6qoYGx14b0PPHXrb/BVKzD1/akjV+w6i228fEdNzYA4K0WoBRdq IY9/25iwJlj9thxPgsd/d+Ld7rty7siza+56N0885Bh3fj/jDf8njo8yrQsc5zu6HHfE3pX4 aOZ4nFblN+bXZl+S2Zl9XeJ17q9kXj3fXp5dZ62PPcexKr4+ozpTy5yfk10eV5ZRllnmL5uv WWMsCfYMryMnLjMz06/NzzTyB+Iuc29L2rJgMO/6pGvy7k26I+9A5gG/Yye7xXOj9568x/LM fKsnI9nI8JcmG+m+Ul8y+10yS15ky2jMuiWLZxneuaVZqfmiZDwJMZWN+awonxXms/x5GUUu 5lrEMmRZxdsrJYWJLC+7eFqkBC4bE3XyGdKPEtksigX360eBzWKErThOkWeOUWZlzMqSWXbm 4oz6jCbW4ulk3Z6P8L3Rw9XUjEyeO8cRx3NTL1aZWp8b25jKUuvnaJUnWvEvIdGzdLq1bk4b p8zwC6O5eaUZYxGaicfJ6Lz5Yjw56psfGaekyrGRBuZSB1ucWZ95t+P2zO9k/jzTmpEZ51DV VLGOp3CiaJE4W6OegkoWLT45zswqFdSYm4oTxYqYwRqZ2sZ2sveZQvhy24iPz6q0nJMMS1yB K0llF6vvq1wsIdmA6+RFHgN+PQaceoyy8lKPEViILmsBOviN9/g8F3t6Parn/FQjc35pfCpr TA2n8ujiNwc+aI08uF4PiOEHgejjS5wHkYyIEg9strmVNuPV2iqP1PzwDw17bGJlfC465OHd g46lce64pYINxS1Fht4ZiV0qjw0TD8PNrXOy5O2IB0dOdg6KrqwUz5RkjyVyVJLcnmRVfEsW l2cRS03s6dhUnuVOOnvqiQu3v/bGaz/Pnfo44eLm3iI9PZs919L8wXuvnmCFgdXn56YX6knu hIYVa+8ZOnzzruIV1b5k/7yk9PXnNHzltp+Z8nO8xf0lx743t1wcX/GhLcUmfyLy4B8qTv6k m8JvyU9gjOzR3x+I00faiqlzqebkD5H+5ocqFitElu/T3eofaDV/nHzqAFXhA5R4LWZl7El+ hlKj/jGKtFKAuNRxXJiFdD78V/Bv40OmkK5R3iHxaVO8vih7ReJi5EiRKBsFo7xCzfTlKC9+ Lv7zKG8hL70V5a3kZdN+NFrHvFHeRkXs8ihvpyH2eJR38Md56cway9TfRnks0TInynNSLd4o r1C+JT3KqxRjOSvKWyjOsjrKW8F/IcprVGz5YpS3kddyX5S3U51lNMo72PmWT+CZqQrmcmor o7xKqdqFkhfZitEGo7xKydoOyVsht2p3RHmVErX7JK+JvGlPRnnkSntK8jbI47QfRnmVvNov JG8X+deOR3nk3/b5KA8/tvYoj/zbuqM8fNqei/LIv23aD/Jvm/aD/NstUR75t18S5ZF/+11R HvmPyZB8jFh73AtRHmuPe1XysZAnxv01yqs0zxHxGSdic/ijPOJxBCTvFJXmqIzyKqU7Vkle PK4THZdGeeHnCsnPETl03BflkUPHA5J3i3gco1Ee8Tgi602C3O34VZRXSXe8J/lkYe+Mj/Kw d86VfIqwd5ZHedg7GySfJvbUeWmUx546I/s7V8Tj3BXlEY/zVsn7pP1DUV7YR/Z3vthT5/NR HnvqPCr5PJEf55tRHvlxRuIsEH7ilSivEsU7BG+T+Z/hEX98muTluuLLoryQ1wg+LmLfGuWF XK4lTu5L/LVRHvPG30SPkU4luCOK8dapiTZQF+hK6qUetCBtoz4pqcGoH7zo2yHvlhYLoami jXjrtBqyS4AP0oAcdYF2wXoL+k75e6N+WLTDthrYjZD97SzLTrHRZ6yW0VrpZyA6p05l8FZE S8Dlwkc3dUDbC30vrYevBaf18o98nLQtOCWuplk+uuWK2tGCcvWd8LUJtJ8uhUzM+j/J3L+L +Hu7phmuVlpuhWUP9kCnVYhpvcyM0BbI/eildVKv07lSs0Guth1ry4esUc7ULzXdcq1r0A/C vjOaOR0VshQZK6EWIAcxFjnYBjood1qXv2GI5Gq9jDUoZb3oO6W8T863TeZS+NUh6ZcxCcuO KKYrOm6Xnvrk7JtgFZQ6gVonfQSj+dsYXWfPTBQRxHQc/afY9slK6UTEHXKOSD62yrhFRk6/ hshY2HZgtkGZkU5Z+3+bCYHYKLlc2C8AFZWyLhr36X33/C/WftJ758ze98uTN72X09VzuhVM z/73cS0/ZY/ESiJrCcr5putS+I+stROSrXLlvfJ0/LNKaJ+1611yd3qjfWRVEX4Qoz7Z6zLa LTPVHPEjLDfC4p/V0MLH9JKi4mK9aUOXvrK3pze4ra9Lr+nt7+vtbw929/Ys1Ks2btRXd1+y ITigr+4a6Orf0tW5sKq/u31jde/GzmnIMinRhWjZ2q7+ASD1soVFS/Tcld0d/b0DveuDC06a nGohpQXSV1PEontAb9eD/e2dXZva+y/Ve9f/4+D+kWJG1iS62v72rd09l+ir1q/v7ujSC/TV veu6e/Rzuzs29G5sH8jXG9uD/d0d3e36mvbBnk4EpxcvXVLS0juob2rfpg8OdOnBDYhqfW9P UA/26p3dA30boWjv6dT7+rsh7ICmC7R9QO/r6t/UHQx2derrtgHWpW/EnD3CBRTCR7+U9vX3 dg52BHXEsXUDAjllBtDuno6Ng51ItD4dRG/Pxm16bvcCvWvTOvg+xbrnn84uzTvF6vu7BsQq RXpOTiDgM76WyxXldmOWYNcmkcv+bsza2bu1Z2Nve+fsJLRHlt7Vr2NFvZgK/WCwbzCod3Zt EWmGzYaujX2zM7QQF2sXjqA4gEEU+qmPkNmaIA0yB0r07Vk2J6Xr5fE8VReR1Et8cJYmKlOu V44o31GeRT9yqn6W/D8P+/887P/zsP/Pw/7/5MN+5o7t/oe3b0TzOdANoFuAF5LBWbZ/rz1T ZmBgltW0rB639UbcDB/B/m3IZt/Ms3XTmIHoLd57Wo8ntWsld6pNRHKWHG2Rz4TZ+tmaRvgQ qx6Ud4HI1bZZ1qfTn5qp3n+Yw17Vp65Ql6s16mJ1iWqoZ6gN6tJTrU+rbzrtU++ktP7v1hOR NIgRK4bNqbqT0gZ5CvqQ6d6/sZiRswT6veJHPZ+in5F9Tt4SQvqvVtC/mKV/2d8/q7Doz+Ao nEMv02leI007qxzKE7QfjZMLvY42jKaQoTwxqjlKjDHQRLekoeRAyXh4AsyyRVJecHvJzsPK PrqYFkG8L3S+EO8bNWpLJF20PEILiyUN2SJqzV3iq0oFrBCNU3yUW4V2C9oetGfRrAhoH/0O LYymKHuVB0P1Pnh4GI7iq9zKw8QQ5cN0FC2MpiD6h7GWh+m9qERFVA+N2uPE9A9JVJryEFDx 6F1oO9H2ox1Fs1Av+j1oYUX8OGaP8iB0DxJXHlQeCLl8rqoY5X7agcaVeymeiV/+TSh3j7pk bu4ZjZ9TYlS5lDuoEY2TqaykCTQOt7cCditxmDeECoplChtGY5wlLtjvQtC7EIj4ydAweibH Bpqw3zU6J1m4vzoUnyBxXwoVlUaYUZe3pBFZuIyY0qX0kJ98ynbQeaAdoHNB1ymd5JBxGqPx rpKdmK8S5pVKEq5pn1KlJOMh7VNqlVRKk2aDIWdknsFQbl4JVlyjeKVJvOKgUlCbooVKfPoh xZDJv37UHiviuz7kSio5olyraOSG1U5YeXzxR5QY7GyMXEnTqN1RsrsqTmnCMpuQFh9iZMhy j3TUE4KjqgSlTkmnZOguVeZSEmi9Mk/SR5UHcKJ9ytdHs9N9E4eUr0rUbcIppl8RKa0Vow5n yUSVXVkBrancjA24WU6+ezR7SQlVZSu5VITGkeMd4HbIoh8CN4RdG8JODWGnhhDUEKqPlBug Eb/FLFQupz5lK+1G2wNelFVSCAkdl8z83JJxJUXxIjGuQ0glgzR11O4UkXlDiXOkmXc0zllS eUQZQJ0PwKehBEc93pLeQ0qeXEr+qDdNAPpCKNcjiieyNQAmiy05oqQjESIxc5V5oSSfWeXD WBSyjxj/ET8mksRf4r8Q2y3+cljSF6L0xSj9SYSGJ/ixyKHgPxN0siqdvwFnF/Pf0B5wnB/i z+Mzr4+/xsdEFPxVPk6VoK9g3Ak6DroI9JlQxg98Y3xsFASx3xdyJIvF8udDgcIo48uKMp60 KJOYXFKVxb/Nn6N0uHgZdD7oc3yCMkGfBfWCTvAg/QD0KV6GDxk+fiBKv8MPixLnT/OD+Ijp 46MhpwjBDGmC7A9ZBflmiCKjxkLfYf5Nvo9SYfpkKDsV0r2j2fN98Yfgj/GHeTA015dYFcMf YM3sAxgN0yuCUiJ/MFQunOwOHdZ943w33214y40so8B4RCnKKiooekTRs/CduVx/RK9y8Ztx gezhOL98F/py0jmqB81A281vCKnlZtUJrEmsi9NO9MOSa0PfJzlC75rRvi+5Sn4trULj8LEd bQfaTrQrSUV/OdqX0L6MdoWUBNEG0bbiNukDog+IPiD6JKIPiD4g+oDok4g+OfsgmkC0AdEG RBsQbRLRBkQbEG1AtEmEiLcNiDaJaASiEYhGIBolohGIRiAagWiUiEYgGoFolAgDCAMIAwhD IgwgDCAMIAyJMIAwgDAkogiIIiCKgCiSiCIgioAoAqJIIoqAKAKiSCJ0IHQgdCB0idCB0IHQ gdAlQgdCB0KXCBcQLiBcQLgkwgWECwgXEC6JcMn9GUQTiEkgJoGYBGJSIiaBmARiEohJiZgE YhKISb51RDlW9V1AjgFyDJBjEnIMkGOAHAPkmIQcA+QYIMeiSw/KZHCUzXa0HWg70QR2AtgJ YCeAnZDYCVleg2gCawJhAmECYUqECYQJhAmEKREmECYQpkQMAzEMxDAQwxIxDMQwEMNADEvE sCzcQTSB+PeL8t/eGn4la7bhWct3sgWS7qB3Jd1Or0h6BY1I+mV6RNIv0VWSXk7lkm6lbEnh T9Ig+Wws5CuPr0rGFbAK7WK0XrQ9aPvRnkXTJHcU7XdoYV5mZKrx2iptj7Zfe1az7NcmNR5v XWXdY91vfdZq2W+dtHK9Ko075D2Kq4Vukf0O9O+h4SGCvlJylbwU85bini3Du5SXGgnH9ffy 2NE89mwe25/HbsljVXZ+JlPlTadTOUfgrNmIy17hewWtPDtnBW6mmw++6/GFshf7xtjhCFlg BEDfRRtBewTtKrRytBK0ArQsNJ+U5cG+2ciMujyMloOWgaaLKSg5GR8QExNsxjh3sEdGv+sg u5gnJxe4Q6GcIpCxUM4qkKdDOet8VXZ2kHLEpyL2FHZuH+j+kO91qJ+MkCdCvkMge0O+UpDW UM5CkAtDOS/6qhzsfPKpAtoUpWuwbkFXh3xrYXZeyLcAJBDKyRbWeZgoC9oFrJleB82KouZH ZvKHfMtBMkO+pcLaRjli45mVCmR4FjRBlVEE9N44a1aZEes77vuq713A/4TEojxe1cdUkKNZ Y2ytEeM7XHA/jKt8oaoYYY/nw0iUmoI+5Xsk6wbfffDFsg767vEt9N1cMGaD+CbEfYOcIuS7 Sh/j+4w5vp2+Il+w4HXfgO8cX7tvta81C/KQ7yLfYREmtbBmvu+grxEOz8YqskK+M7PGZIj1 vm0+w5fjW6ofFvmlJRG/5QWHRQaoJDJ7PvKblzUmavz88jGWYORp72u7tQu1am255tcytXna XM1tS7S5bE5bnC3GZrNZbaqN28jmFn8BEhC/JXdbXYJYVdGrkndx0fPIHwBwZuN0DplzlAbe sKaaNZgTHdSwTjc/WuMfYzHnXWBa/NXMTGyghqZqc0mgYUwLrzbLAw2m1nhh8whjN7dAavLr xxg1NY+xsBBdmyb+nn2E0bU3pY0TYynX3tTSQt7kLZXeysQVCUvra0/TtUX7wMmX91R2rnln w5pm8/G5LWaJYMJzWxrMK8Vfu4/zeO6oqx3nTkFamsfVPh5ft1rI1b7aFpi9Ls1QzU6YUY4g MLNVky7McJ9UCzPsUcQuG3DYZQgCuxgHZUu77BiHtFOZsBt5Ra+rHdF1aZNF9Iq0eSWLTrFB xQBbO5KdLa38OmsWVqzZr8vAFkhHPh9MCnzSBF+DfdKRj8nJzMKTJllRk7IZkzI5l8JO2vgi Nu7caRt3LmwC/8tXV3WAjRYPbn9e/AeCNn9dF1qbuWvLBq+5c52uj2wfjP7Pguy2dR0bBG3v Mgf9XbXmdn+tPlL8/GnUzwt1sb92hJ6va2oeed7oqg0VG8V1/vbaltHKiuaqWXPdMDNXc8Vp nFUIZ81irsqq06irhLpSzFUl5qoSc1UalXKuum5R943NIzaqbqm5KEJHeWwMargtLaOlOtnV t0IU9PjyDO/2tGdUYnspNtBixvmrTQeaUBVUFVQJFc6ZUDnF/xKJqrzbl2ekPcP2RlUuiBP8 1TTzp7nCqMEsO6/BzFhzQbMoFdNoP/2eDYiXVHuprrsW/zAOyob3qZY0cNpX8HSvwcHBAdEN BgaIGsy8NQ3m4vMQiaZhqrbaFsgWTssURcpG7Pa6sfAElAEEwYJiOsEFmPjTRiMG37o0Pmwd 1rj4qhAcTZ1b0nsET/AdaPgex7eGCuXXZ751NDNLfH8JjhaWRSi+rgoaSs0oEX9jVg6ooFkR aiQUgNmdtbtgd/lw1nDBcLlV/H3oIxD6HhGP0lDhIwoFAwPTiQAbbKHIX1xivgdC6XPlxMOC CQRaAgNM5uvvk82mkz6T2IGo1wHpPji9IRH5QNQJdiIy++A0bDAKkspBCYo4iYxmupMvjIj+ HyPBiQoKZW5kc3RyZWFtCmVuZG9iagoKMzIgMCBvYmoKOTAyMgplbmRvYmoKCjMzIDAgb2Jq Cjw8L1R5cGUvRm9udERlc2NyaXB0b3IvRm9udE5hbWUvQ0FBQUFBK0FyaWFsLUJvbGRNVAov RmxhZ3MgNAovRm9udEJCb3hbLTYyNyAtMzc2IDIwMDAgMTAxOF0vSXRhbGljQW5nbGUgMAov QXNjZW50IDkwNQovRGVzY2VudCAtMjExCi9DYXBIZWlnaHQgMTAxNwovU3RlbVYgODAKL0Zv bnRGaWxlMiAzMSAwIFIKPj4KZW5kb2JqCgozNCAwIG9iago8PC9MZW5ndGggMjQ2L0ZpbHRl ci9GbGF0ZURlY29kZT4+CnN0cmVhbQp4nF1Qu27EIBDs+QrKS3EC++yksZCiy1lykYfi5AMw rB2kMyCMC/99FnxJpBSgmd2d3dGwc/fUWRPZW3Cqh0hHY3WAxa1BAR1gMpYUJdVGxRvLv5ql Jwy1/bZEmDs7uqYh7B17SwwbPTxqN8AdYa9BQzB2oofPc4+8X72/wgw2Uk6EoBpG3PMs/Yuc gWXVsdPYNnE7ouRv4GPzQMvMi92KchoWLxUEaScgDeeCNm0rCFj9r1fvimFUXzLgZIGTnFcX gbjM+L5N+JTxQ5VwtdfrhOu9fsq7b1vSlRTDj3uq1hDQec4qW05mjYXfOL3zSZXfN7wzdtIK ZW5kc3RyZWFtCmVuZG9iagoKMzUgMCBvYmoKPDwvVHlwZS9Gb250L1N1YnR5cGUvVHJ1ZVR5 cGUvQmFzZUZvbnQvQ0FBQUFBK0FyaWFsLUJvbGRNVAovRmlyc3RDaGFyIDAKL0xhc3RDaGFy IDUKL1dpZHRoc1s3NTAgNzIyIDYxMCAzMzMgNTU2IDU1NiBdCi9Gb250RGVzY3JpcHRvciAz MyAwIFIKL1RvVW5pY29kZSAzNCAwIFIKPj4KZW5kb2JqCgozNiAwIG9iago8PC9MZW5ndGgg MzcgMCBSL0ZpbHRlci9GbGF0ZURlY29kZS9MZW5ndGgxIDM4OTAwPj4Kc3RyZWFtCnic3L15 YFTV2Th8zrn7NnNnyeyZzGQyk5AJBkgCBKO5yuKC7IsEiQQFZBXCJigqqCwiKtq61gouVdxK gIABtaaW2rpQaLW22lelLSr6NsprKVUhM7/nnDs3BNt+v/f7/vxmMuc+99zt3HOe/XnOybIl y2chHa1BHLKuXjhj8a+eenAjQuhthLD36hXLEvpf4kcAhp84cfbiaxbqV60cj5BcC/vXXrNg 1ew//PP21Qi5nkRo/oo5s2bMPHZ7vQuh62Nwj4FzoOL23C0S7E+E/bI5C5etFMJzP4L9lbB/ bMGiq2ds819djNANLbC/YuGMlYv76JN42P8j7CeunbFwVvx3798C+98gZEYXL1q67H5UmUdo s58eX7xk1uLrp340EvahPdrPoA7Dl350AEW6TzheECVZUTXdcLlNj9fnLwoEQ+FINFYcL0kk S1Nl6Ux5RZ/KbFXfc6r79R9QU1s3cNDgevT/k4+wH4XhFxGeRmE+g0II5T+D3zG6zc3NH6PH 6ZZ8ASd3FH4IbUcv4LnoBfQqeg0fh6t2oH2oHf0aBdEw9AhajX6INiARTYWa29F4+ApQ/0Mc zrejavQY4NJj6CCcezm6Ce1HARzKf45uRuu4d+CqdchApegCNBYtQnfiy/LL0TT0MX8rGoQu Q9eixXhNfkr+rvy9+SfRT9A+7tf5bqShCLoavgfzXwp/zP8X6gtX3IceQh/je5U9yIKnrIEz f4yWoIe5Zh7nr8l/By1IouugDTwahQ7iTpKFu89Cn+EQXs0Nhbs8kW/LH4CzYqgZzUEPo/24 Dl9EksK0/Kj8QRSAZ6yEuz6EdqG98O1Ar6APsC4czz+ZP47CqApdAu/Tjn6DO7lc99pcI+1o 6KU+qB6OLEI/Q79Ch3EK/5wsEnRhgGAJ1+ffRX7UH02C1j4NV36K/0lugu/N3Ov8iPyFyAX9 cg/tbfRL9GccwdV4DJ5M+pBF5FFuCZLhif3hOxPNhf5+EO7+Ec7ivUQnh7gn+Of4U2Jx7kje BSOSQT9CP0Y/xwa8aQIvxbfg9/BfyVAynfyI/IX7If8M/ztpBrz1lWghuhM9h/6JvXgwHoev wHPwarwB34MfwgfxYXyMXEAmkvnkK24O18q9wl8I3wn8Uv5WYb1wh3gsNyV3IPfb3D/zA/Lr 0TjAh7XQ+vvQo/Bm+9Ah9D58P0Z/wQLWsAu+CZzEk/AN8L0J34kfx9vxM7gdnnIY/wV/jr/G /8CnCIKvSKIkSUrhmyJLyHXkh+QRcgi+h8nfyLdckCvlslwd18A1cYugVRu4LfDdw/2Zj/CH +Dz08wDhfmGrsF14TnhNOC7q0i0ykt8+/UR3ZfdHOZTbmLs/tyvXnv8zKoIxjEAvlKAGaP0M +M6D8b4fMG4Hegfr0HcRXInPx5dBz0zH83ArXgk9eRt+GP+Etf2n+GXopT/gr6DNBomxNp9D 6siFZAx8rySzSCvZQu4l7eQ98h0ncRrn5oq4Su4irpmbxS3jVnH3c23c29yH3F+4k9xp+OZ5 lS/hS/kMn+Uv4qfzy/lH+c/4z4RpwlvCJ6IqLhTXix3i/0gDpfOlsdI4qVm6W9orvSu3AHb+ Au1BL/ameXyEW8sN5/agu0gNHya/Ib8BfJ6OZnKjCGAq2Y43khtxOykTVornknPxaHScz0Bf v062kpPkXG4UHoknoHmkv3030c8/C5sG/heoi38Z3u03cOeVoo5vIl+JOtqFEQFuiX/J9eOz 3FvoA+5jLPGPoT/xKg7iLvI0Nxaw4BX+fGEKSnKPoJ9yrfhGtIcMR0g9JW8GPB6NnwW+MBEP wN9wecSR0YBFg7i/olvRfPJH1AV0vBE9gGfy16C7UA1ejT5DTwFV9BGuFSvFIvwGmctvIj7c jgj/DLxdPS7DnOBHt+Fm7mHxK/I+Wo4O8Sr6iHseWn+I/JQbxR8XxuM5QAE3ovWoNb8WrRKm 8L/D1yAOT0Zp/ghwt9XcAD4J25uBq0wDnrYXqHs/8IELuFFQEwLMuQzwYhJwiIfh+yDwCR4w aC7Q+OXAxX6D2sWJpANdI7gwcB2E+Ldy49HU/FPoofw16Nr8vagv8IMN+dVwx+3oE3Q32o7X 5W5Ai1EcKOcjfJkwghwSRuT7kk3kfTKB3H/2+EJvp3EIfQHfn8LO+cJLaBP/BzQBNeY3538P 2F0BHPYhdBW6FB2Ft/wSnnAx14lqcqPJzvwIbjG878doXP7pfAlW0Zz8AjQGvYx+IglohpSF MW7Dv4P3vQHNIuPzy7hZubnQD3dDL1jQW8uB/9xuDZ008QKr8fzzGs4dUj94UF1tzYD+/arP 6VuVrexTUZ5Jl6VKk4mSeHEsGgmHgoEiv8/rMd0uQ9dURZZEgecIRlXDUyNaEm2ZljY+k7r4 4r50PzUDKmb0qmhpS0DViLPPaUu0sNMSZ59pwZmzv3emZZ9p9ZyJzUQDauhblRieSrQdHJZK dOCp46YAfOewVFOirYvBoxi8hcEGwMkkXJAYHpozLNGGWxLD20asmLNpeMswuN1OTR2aGjpL 7VuFdqoagBpAbcHU4p04eD5mAAkOH7KTINmARrVFUsOGt4VTw2gL2rj08Bkz28aOmzJ8WDSZ bOpb1YaHXp26qg2lLmxzZ9kpaCh7TJs4tE1ij0nMpW+D7kjsrOrctLnDRFe1ZPWZqZkzpk1p 42Y00Wd4svDcYW3B64+GzuzCzb1Dp2zofTTKbRoempugu5s2bUi0bRs3pffRJC2bmuAecC1J j2jZNAIevRk6ceSEBDyNrGua0obXwSMT9E3oW9nvNys1nNa0zEu0KakLU3M2zWuBoYlsakPj VyV3RSLWvvwRFBme2DRxSirZ1hhNNc0YFtvpR5vGr9odthLhs4/0rdppeuyO3elyFwDd6A3M 6jnGIHY6hUaO7+lZTFuUugQQoi1xdQJaMiUF7zSYFrMGo01XD4bT4NOE4aq2mTAic9uUoS2b zCG0nl7fJqTNVGLTPxBgQKrrb2fXzCjUiGnzH4iCFE96UA2OO3BbNttWWUlRRBoKYwptPJ/t 1/WtWtFBUqnFZgI20H1oLPTtjKYh1dD9ySQd4Ds6LHQV7LStGTfF3k+gq6K7kFWdbWojLfRI p3OkaBI9ssY50nN5SwowuZ2pyEVtcqbnz20GfMPnDGnDgf+Hw7Ps4yMnpEaOmzolMXxTS6Fv R048a88+PrjnWAFq8w2dwkVJASJRjh0FpJzWczLdmaK38Wn4ExlSz+yQZMBKVoMTI9rMlovt sklNJv+XF3Xkj9Or2ObMZYVmtg3Jnr1/7ln7ZzVP38RBg0FUjpw4ddMm9axjgGr2Ay8pbADj 0cQpycTQNjQJKDMNfx35zsH01xRts6DLhtITAP/sqsLuWSdGC3ATfCh29q0aAYxu06YRqcSI TS2bZnTk11yVSpipTfvIa+S1TYuHtziI05Hff0e0bcTmJuirOXgIEAVBF+5M4Y3jdlp444Sp U/aZYD9tnDhlF8FkaMuFTTvL4NiUfQmELFZLaC2tpDsJuoNGYnjJXURm50f3WQitYUd5VsH2 r+7AiNXJTh1GV3cQu8506gjU8Xadxeroh/KYoROn9MYeRpJNfQEbCWYKtoBAYwdrMulJetJQ YBC6pxNc52lLQKdQgu+k9t/jIG2pVaOhdqtIFOKyLEmI4+PwoqoS15AsQZda1aa3VprIXZpQ EwZRIwavEF2/cJLi0jQoVd2AMoETcL+EaZJJqCN/st3tLgCGwYDv2nW9AChKT41IgeOWahgA NevnXhHKjjZPZO1Pc8Oobtg0jDZPNo86cTSLGhu6G+jPW1/dYHY39O9X40kWJQu/x/my049y 2dO/524T9r+Qa3w+Z7wALdoA3fApfz7YVTstn8CJPrLd7DD/yn3mO86d9Ik8fXypZtSuMvGD 5uHQkVA+xCdkv8sf8MYECYsBQzVcuqsj/w28yYWTAPi6nb42ACesEtoNrrKQRV87ZGkamaRV UFjzu1xQduT/ZnloB2g8fXutlJ1Br9Q0TYSzTFOk+99aGu0BTXW72f5Jy0v7RrNqBtbmNQx/ 2ugQHYmq2oG1baHjIbI4tC3UFuoM8SGO1BQFZNq2ABuPgE4bFUhj1vseT6GvCwPznRWkLUOs PUil7UE8bQs75qHPR4SNC8/GhD7UC604ThldAh1GRwCNRgdhRFqzPZ8GNkwnGkyoPOsAfLro IbMBxq6xsctTj731/fsNXWUFRI+iyqqkcqKZ8YiuKHar3ihGWZzNVq7Fza0o29xa46kpGlgz IBAAtciT8tRmMqlSsciz4fHlH7Y8NtZU2yvnX7z0aT7zwI7hi0cNuLF7KVl/7cIL7n27+2WK 22Pzx7guGPkI/vs+FKTDTDtGlRnqstLNSpOVHlbuJJSurFrXzW7s1rAFhvdiICPeG9OkUIwH A61IkmkHSjodVkmn3SiZtBulavq6B999HTV2NXaZB5oH0F//flHrIkXHJbGhvqHBCb4JwRZf S/BH5Efcw8aT5pMRXTbC6jwyl5snLNcXG2uMp/Q9yl51j64H9PX6XwnnKp3uXuS+2c25cQd5 1sr0Q7RRLdCsLWgbjMZxpCC3W0Nn2hiDpgOKtbM3BHS1vBQt3GUumY6oqzSKKGrYxwH40lpL j6MyLVuCMcIYW67shZOwRVEKW/QsPJCegS2KJ9iiOIsvpjiCI/SO+JJYEcO/IoZ5RQwLi8oO SbhEapSI5KKXSSq9TGJoTfvuQtZ3UPaP1h4IZc2TNsW3UnQp7ND9JQUWtw9hytrh6JITFKWW sE4GPuCprzabj8Jf/36ouRXwpgnbl+KgKKZKkafWSzEoKNm44w/UDBjINews/uqnH+T+ueTz 21/4r5Id4Zunbnz2ydvm3YXXBV88hIux+jwma3c8Fp2/4BfvvPfaLcCDL80f42OASxVoENlu VSmGUhk2IpV9jMrKemNg0aDokMpLKpuN5sp5xtzKln6bjPV9Hg78KPKMUVTRkT/WTnugHAAr TKGnws9W7A2/VHEgfKjid0UfVsjDAjhOmYKH9o6X9ZGg07KuI3/EGkOhkmBJKFtVWVvP11dd wl9cNVluys6W52ZX6Bv0N/RvjW+znkG1Lsyb1WW1wQFJf2h6n0V9SJ9YtavRdbdrqyvvEra6 dri+cnEuSugaY2E6ZdKw/wXjDoyjJekwuXSGKSLlBq4MY3shxulcMS5IsdAIVdEbhO7zx2IS 6mk6Gl6uDohxWp8Z5gzGfRhiUdZZwLXTloveDYlMKKSTZcAg2bMpQHkgQIwzwf7RdkpVZRRT aacB8F+WRltXxtoF+6eZACnrIFdYrnILZcxMItMvsyMj1APXaqdUmunIv+cAJ/bSR2f604OW EU/V9qvvrCfb6nF9kL7AfHrrIGMCwXSotJphdDXD0WqG0dVlr4qHRFIiNopE9NMa0U/PEdk1 oov2pci4ghiiryDqtP20FOEo7VDRpO0V+w8+g+AOyp+AgnFPWtPlCECbsWY/+YRi+9FsY1d3 9qgHkL7Xta2wD3/12OMN1lMaYLjfChvUmqYUkKmrHThwEPvW1ZZTIpDKzycFpgr0EExlOFFy EZs04CSuYea+eTtevmjpxXXzP7gG1wzfePOq4rbQtYdv3/jsWFMJlr4cC151YNG0AQvnznk8 U3zrpBHPrRu9drTfZUTK0uq1fc9rag213jHSmnHpOSuPn1p33mD8YUXMrBhVfXHLFWPOuw70 E7QhN5dPAjV5URzfby3Tzb7meeZIk29MtCVISaKPnioeUDSg+MLixYktCXlIcEj00uCl0Sb5 Cn1acFp0njxfn2suDM6Pdibe8X8Y+jDyTvyo/2j8SCKfCKT4rJktquOHmCP4S82p5ifafxfn TM3j4gKxmEjlecylIVfYEeNhhxMC8I1VQgc0XHZYxaZqqS3qGpVPMKmesOjAqh35Ty2NDrQa Kuzbag0AXzIsVentKHqqlNrr6Hiry7CvhtR4GUJ5GSp5GVp50wh1YrwFb8Nt+DjmS3AjHoM5 TMmkmCItNulDsEmfgJmMwQybMCUtxoXpqQH6OMzYBfYyfhwuuWhQCPdSpCimLGkYZVJsOnGU bXrhHgLBzGSzlyEQ8NAlqNVHRS+TvUV+QtGo3MMxDKmrpTi04ckh987ZeHje8o9vmHr3OZ6n Vqx87ullS3fm5gqvbBo3bnP+wSdyp+64bEj3Ke7Jgwfe+v1bb/6BSuRGkMg7Ydz7caCLBVlX hFgZZmWFMxblDpBxgLQDlDlAygFKHSDpAAlKzzdTiC/1lw5RLlWGlU0unVW6WrlLua3sKd9z Va9xhhKMhIL9Rla9FxSiZBIh5gCshqbJ05Rp6jRtmj7NmCfPU+ap87R5+jyjPdNe7i7PlJWX 9RlYNlVt0mZmZlYsSy0rW1P2A/UR/d6KB6ru6/ek+oz+RPmTFbszv8wE2LvQ0Sh1gJQDlDlA 4X1F5xVE56VE5zXFScUd+Y8sb7x+qlye1lU+ksgU8do5xRHKhUvDVRQpSsKN4THh6eEd4UNh 0R0uCS8KfxzmS8J3h0n4FWCzRUByz1L5afnp6Sa2MDHxYUwQNjEBHOrc7Q/U0q1lujy1GJ8z rXhBMSmOFUm8zX3JJAA+ZShHActHUY6PnaOVRHCkLGz5QrUD6OV1lDTCIbukuBsOUNwNJ+iV 4QS9Ksx4YDhA358ehbHfT65AUv7rvRQFpLJKuNGeWP3hSlxJn0mvr6QilN6UAfT6Siqz6C0q KV+nd6mMsBYkyytrWwZ0DiCNA9YMIANM0GbKEGsKMpk+m7A7nzAkYW/EsKWEti3BsDBR5ma0 5mZtdyfoyW4qMzO0CW4Xfb6bCUi3yFSs0o8RbkRjgK+F+9cOYgZMc+soh/YohQFLynYtGe0w +Gy2NTuqK3uGOuEgcHjYNna1MvYOJJgFOmUbm8EX+DtozlZ533hK8FdlPKbX9JmcWGokokip kKJY6AtF3A+7SVcqikpThi73UaO4olxRxSwfRSVmMdWxsyZo5HbBtKXK7Nq1a1EvZoGbl7Q2 n6mgJ/kGBWzyL8+Un0NAqAyy2UOPZhUEgRKMgxxhUqdxl/v2G1avrEv/4PWHxlwwuPKeCTe+ MtXTpi+du3peIFAdve3VBybPff3GQ+/j82Lzl8wadl4qlB5wydrRF62qKMlefMM1ofHTxg9K xYp9alnNBaunTd16+fOUg9wKHOQIjczhW/ehCAy4UhSsJQlfoNZNDbmw11+b9eEy2RfQsS+g iUj1gD6CagKO/RZwGH+gx34LpENBamhFmBUXZPZb0EsZcLBHKwkyrSTYY7kFmeUWpDKDWW5B nSJQkFpuBkWQfBB3BnFwdIQiZTk12iLHI2RxZFukLZKP8FTth8boDOF0Jg30tMIokNpaCkZK QjmsHFF4hTactogCloe2SmFtUVTaDoU+kUkAhVltCqGtUUaHLxobOqNHA94xvfpfzDOmXxyl 2kVjA9MhbBSL8KbLcBtElGRRFmQw0Xg9igzZE0XUQKusXAtiAq5M1tGhzpRn6jw1HkAAiiAD Kcw1rv79lU+MMbV2zXPtuHF3ndv+SPvFC8fULSX3du++s/9F4ybcvZHUn/qAjigM6yBhP+Lw KMsgKu0QjpVUuDkK5GnLQyGi0Z7iWAmHux21spuqn3CYp53KsZJdzXRNerVGIWEgJWuB8rtB g2vZtrbO3vbrb29L02xrpQGr3EKJsFX4WODHQHFc4EqExcIaIS/wYAirhGP2NbsTs5GLaupq tyLcCfYYOWMoO4PHjOvifzG8/czwlikqwRm59oLFnXccI6ctlUGj+bOG0+YPMHhgVTf274fZ 3vc/YDt7bm0X9n83gtJNWf5rUik8hIK4ZB/S4VG0v7SOAiA7gOQAogOo9CVTmVqGnBMAWBMG G1E3VMyhgKlk3SpoVJzmNktRKTbOUnJUW8nRcV6ShyvDW6TF0hppi8QjKSFtk9qkTumwJEpU c6JdJNmaEwO+Zjq7ZNNsAWCGtu3IEClwnCpiAInMoqSCgfaetJ/MA+YwcOfs7/UXqD1dtpvC PHqigWI8dB9VeTw1NeYbtBMLp6aDDKfrPKm6Gs8g0IJSHj9FbGJGLmu4akHVbbft3rPHl62I P7bVPH/W4+TqzVhakLtzc/cPRlVFYOxHgqUYBx2nCBXjR61gCYoVkUlcs9CsTNJmcfOFRcos TS6i5g1trwcAazyFimO0LPe+L3znPxnh+3uHhPvHLvCOilwQG+edFh4fm+FdGJkRWymuLDpJ ToZMFMBuIxgcG2gJLA6AcuveYm4ziWny0Zgqof22xGc9yyS7i3YbFYf3+WK8BozqOBveoMMO KStjBlLQMsDSYv1u0LGhrTKouKX9bNBbKSBj2wxsREoobqQztXT7IjWoSnBJgGLtNMZpa2zH ismwwWSYYZZJVlllLfULjJG4ggfA9gYkmA+FWU5SjI267TeIsfFl+oIUjhfka8+4ZpmH8CjU AVs7yVjbKFun7eqGET3KfATNDd2tDZS5MQ0XNzMjCbcucVwEJqoZgDx+KckYGE5mmJnEXbm/ 6st9n+e+wv7/+j124dPH1F3rrt7c/QEZpw+efPvqZ/Dk4BPtuAQ0dh1X5D7KfWsmduyfg+9b P3TOU9TKGQGy6mPgbB7AhFet1Sqwp7RRawwzhDp/XexyMlEd758Qu4bMFGYpV/tbYp0l7wq/ 930Y/sT3if+r4H+HPyk+UpIvCZSUZCMNgYbIyMjiki0l0jmkzDgnMITUGSPJcGOE/5LY5epk 4xrjE/GzwHf4hMvERZxLM90oGtMkD1KLgDpDjvSjwIu000M1lH19/SLjr2mP2znhbMdROXMc pU3zsAebHsvT4lnj4UuYQVTCDCKPlyKYhzkAKO16REq4HqZweegdmLD0MOTzUGyig+mxH2YD Vgtzvi0rcA7bMLL5R5lkMvww6ZFXpUPSx1Je4h3ciffCl7jti2P4wjQzKcKwBvBlbC98oaKP YUePAcQqG0wmHLuzDUcZ4jQ20J+n3lOwh0ATai1IurqCNwl4K+5lDXGDZx24+ffL5717a8v9 1bu7E88vX/GT7TesfGz9o5tPPbEVc5vGXUBc340g3rff/PnrH7x9ANl+aTEDfCJF/rIP+QpU aDrk6HUAjwMUOwIt5gBRB4g4QLHtEymcQ4GoA0QcQHc4u+EALgdwO4CPPpTRrgN4HcDjAD4H ZUwH8DqAxwEMx9KRHQDEyB+tUZpRm+aP8keVPwc/SQi/F04mSFBOpJRQNKFwXCoeE4tiMJhg raciYVM9nMZb0tvSJB0MRlzpLR7s4RnaMUPDw3Q0hnZ+igweangHKXJ4CEM+nSEf8xl5nKBD LxTEzVY8xBiVbYqGmPoQSm+J4ih7QLTnAVH2gCh1mXroA6LMcR5lnk2ozdmqYJSpglHHPRWl T6hApCbFbp9ieJ5ieJ5K48MIUzcuKUHUguCoFlDQE0zbaGHaAvMkoUDBTX+6vaAwnLD8zF9v KwnMxYTCZekOvHJ3kioM2dHfcwAwXtnbK8BcT71ooXv08FnDPgX7v7GhoQF0wlFml9nlCTLN sKAbunS/L+PXPVHsNYoKDvu1Dk/9VzWkRxmxvQlBWvT25VMIAOrVf2zAU/NWPFBy05uPPrs7 Ne38xT9snzLzsrVD+Mx9o6dfNWX/jr3d5eTHC6YPue/J7gfIrpUrxz58T/f7wGc3Ajk1UA0S SfhpK9xbhxRZKf2rPskAwQF45nL5voYpslL6V22TAYID8FT/LP6+/imyUvpXXZQBggOwJw+h kMK00zHKFmWb0qZ0Kh8rxxUJKSXKYmWNsrVQdUTJK2oJmAdY4gmniByVx33ZU2/CSBREXhWl tID4rfw2vo3v5I/wYid/nCeIT/CHYY/nHZWU74kF8Uwl5ZlKyjOVlLddwgywtVK+RxnlR8tn K6MUs5gmCmwzy6Qs/VE5u6T1P+FD1ldXU8QBF93Y3t7O//ehQ6eK+AyYAzTamf9M+FB4F7lQ FAeskRE39pt+fzQYjfK8Cc0LalH+meBe1+suLhgMRUmi2PKM8Y0JWpEpwhTlcnOSZ7pvanB6 aHLk8ugdwYeIGY5znDeuKUUOdytyWGoRNZ5Y9LIok5CwZDs7LrS1yYJO+qWjgR53NNAvmKNP cjga1UmtRiZuImuKcbGbhUbdjNjd7ObuDI2Mygz1dJ25vxklM80VhWNXT+uRUc1MPI02m3ss N0ebaexiij5qbm5u9ZkoOYD3FvkJnyotI4Ns/aWWACGhq/FGPPAtPOK59tzeVw/l9m//NS7+ w59wdNXn9/wm9wfyJl6If/xa7if/9XFu255f46k/y/0zdwjX4uhurP0g9wm0cx0Mwusglzzo I2tUtQ+bPE7xtfxQfgI/m1/Gi4pHVmTF8HkUA3Ey1phTFalKxRYZy6UJH/aRUg97ew9jdR7G 6jy2uWSbt71Dib0spIJ5W7CQRMbzzuJ2zM4tdBuLZaHR3osOnI2LBZPWbD6xBOxa5tas99im bT0y39jguvEAFepLcLPDk4ISc4oDB1r3+PlzG6+48vwLLzz3Sn+czzzWevGQp8svamxZ0v0u tPlV4DNrmaVaClyGDTPHSiIxjiMVuMy3Dpf5tmC1CnTQOVbC4VPtus0KTtm4hwmSCbM+B59n W6E1tfa2bz97W9HH3qZs63R3cdzehiK2tVppmLUJYYuwQ+C4BPTt3SBR2hBfzSKFH4NFKngT ULkFcex05tBAoUKv/82J1H/pROpPWrbUSTAsfZx/r+lMFzcPnTZl1xqEcXMTJXvHaMoWLNGz OL7n1deY+UnQowjx3dBzBgqh41Z8lme+n4w0R/qvMK/w85oed7tcKBiiSQdI9jpk6u2lC9mm iTcj09Z5KCyrtLWySdtItQurL0ULOZKIYPiLhAw2MgZDRIP1s/F/zVCwNEfaiv8+PyF87rTe XpWGQnZCq02uBVJ1EhRofgKVizWe5ADmFyPJpAdgqjOCgZF8lPS5d9SCe5u+zL2R24hvePnR 5sv635a7Xdjv8s7au/ClXHf38xzefPO0W4uMgr7I0UwNP75vHwrA6BcFazkaHmRyP83XccO5 /QbPqoqC4dqg7NE9fk7AyB0TJL+m6o5Wpjsdq9N+qyw4n1iqgYI7FeC6lPQCzBumMG+YwrIZ lJ5shoIHKkLPYx4opuYrzCem9PjEFJbNQI/vZa6p0QGKfX2oMyxwPEAWB7YF2gL5AB8gfsYp /IxT+NmQ+f8zv/gPqQzy91IZAr1SGYjNLIq+L7gKiQvUL9ZLC+rxlyFmCYAh0JO14BJdUtol 6lFsyG5H+UFghmKG8Ha8pLdO035T54qfjmxfPn/snaCidH99b/OTj3RPJ49tuGHCXTd2vwS0 MSx/jC8HfmugMH51b1GINtXnuDPcVJmdxXzl7IBXUsP6ReLF8mSxSb5GnCvLteYQ75BAXWi4 OdI7MjA8NE2Ypow3m73NgfGhhcJCZaa50LswMDN0HS5SRMG4gpsoTFSv0Bdws4RZ6gJdDcZ4 yQPKtt9BCr9jAfrpQPrYwJRFmbUXZYhBRaBt7UnMzitkP1AJWRCMxx3BeJyFwgrCkwGdlqss XdtPwkgypQSYcRQFVaYq9f8YNG56xkLqSgDYxbDCpduRZxawLkO6i1Ktl5EsS75AMTbwzFlQ 0IGZxo8CbOgteBxVrglibgbE7kZJHMr+EepOYAjRw8hsR2lrFki6+UxltrcUpvYgsEFLmSBM UK4SrlJ44IbMWe4zBwEKINsFjny9LMRhT97+yz/hwA3/fcfHua59uzas37V73YZdxIfL71qR +3P3wf++Bcex8fZbb//2l2+9Cfj+IFiHbqB2kwtaulypQdMJK+0ElX1IplRH3192GR4yiTD+ 7WHuzS+tCgrpXnpYcOucgjCRFc2FZAWUY5HlJzHzQgNC2csSk0xkB3hsQeywxtM2a6Tx5oOs AO7W2WkePtxJoxHZrM3xUXSnyLJmSiQmMkRWcqzkWSkkCmz6aytFIcJYLMckOWEBFYXFL1W9 gCbfOFYjC8mKkzIC1hOqt9bNCkHnEHZpSJYx6R15td0L6ktkMvIik0y2jAIvFwuM3L4twvRd TlSfsCm8ocF+meZe8ssOfUStmxFxy34SlfkV+nr919CV+iX6JW6uD582qlxTuCv4FcZK1wZD 1ogg1xsDXWPISG6YZMmjjAtd6oPkIe5+6X55O/e0JHoJSLl+AvELApEBF/sJMoCyPt49ngbk iExnXQHfdLlMOk4t3jVe4t1PtiMD998lJOQO3N8K6IrKbBmV+VbVhKXfrGFtP7ywC2twFumA jRv3zr1gaAJQwr3YxGYHmfxiQmgR1gigC5Dtuz3ngnAPmyeaTzQ3hLopL+wCi7sL9iK9do82 oxDItQaz1zdidnVtEM7JbrjxwIZzQnQDetXINm3CyLb4uKlTXkF6/hRg6XuI5N8bPHhwEx7Z psOxCpbMY+S/2elSaS0QEt19d2+y3lWVrDc6ABxU7xowiIF7+kJt33p7UJpoTKq1GYiNUhuI VQzm5CCcBH6LU9jzIC7DV/QLhOvwdCy8lJu8IzdF2H/q63suHvsj7vR3I/i3TtXxR04lqCy9 H/SRSqAuAd1i6ZjwXFxAcoLHfAd52kpKxFbrOJdtSDLt7X+d3njS0Rq+cbQGsbfWUFAazE+b 7WxGmsNIsxjvf438DrSlv79A25fMjeO+5DMoQuZbJe6QLRztDCvmWWWlmy84XU5Y1TajZC4X Vur2GTbrZKVhB5l0R7OyGB7ZAahC0lux6ndzGhcLu72iJvosrzuhWXrCzbwg7nB1NvJhJHQQ 8IFumG7NQpLR3e4YTTj7yFoYq6/wT3bvUDnLsNzEnajoV2vSQtIVb8AIecu1cr3cGKgPNOpc D3m0Cm+F7+JAk7fJ11Q01zvXN7dolbjCWOW53n990Tpjk2ezd7Pvdv+D6nbtZfMlz37/F+pn /n8Y3ea3/nws7i0wnYBPi0V59zD3bW7OHe5pvq37e+ubmeYftQa53brp8XpVxIX9Pl/aq/ph x627PXpaU8HqVX008UoT6Q1QzIyR6tirMRLrII173NAXlr+DTLS0Rq/lJdO9rwJtduAL97px KRoeVekh1ltWQu+nj9G5sXpeJzqcsbuaJuORxvZoYvXsUBY6r7v1RHNrJMToKmSeOBo2jza3 dkVCZheDgNC6GhmBUeKSbzQPwDaUdQGA4E02uMyGBvnAyDYX0FIIaOkloLNjSMsfw0BNTcDC GEH58x8BFamlQEmgQewpqveUFjEqaqI+UCCiLFDR2RY5yvrK7Qwg+OIaH6UtXw0Gwwhk2c3+ c6saLg56MoKWW/jah9nSkuxf23MLLijrt3pybe6aZ8yKsuh8dzFf0f3Q8rWrV5D5p36948Km CRSXtwOtrQNaU9Dj1nksw/huMLWdJGMkS48kSEIjJKL9f8oq/p7OnvsXnV09d9p/zCk+2qOt N38/n3g79+HpT0hb91iaSzzkhe7Z1DcxKf8Z7xE6kYmKidsybPpyM2VCpJoai0IKIeZDMGkZ pbUs184+K8rMWObFFW0KZaoP83AXqFCNxHnBHzeMoOKkPSgsc5Ap3h7EcvZQwH7rs8TzwYKC 4ojjs+5kZyUpVMoX/LBf2smIcEs7M4IlZiBmUJ0l8e17touJsBmDft0Fo/Wz/BEwQY4gL/zc YG+M5sUNZKO20f2GS1AkLUSG+y4rujQ8NDrRN61oWnh8dL40X7vat6BofrgluopcJ67Qrndv EB+U7jffCH1A3hPf0/7kjvQ019FAzwpOWSzZLrhUsZKgHtIIuakQxXHZsC6KMT/alpKCy6G3 E2IpsyYScGkC0Zx6Ww20fTLsDLQl/qs7epRBJwu1xxA4439Bg+kHU5HW1It4QPdjoYGAt8ik +VLlGZ9JycljgvoniZPmv7Ntxa5lF85757F3V92z75nVq5955qbVlzaTdzCPz3t++u5c/oNc LveLFx58Ef8498BXx/EcPO/LuespBVGsSwpPoTg+bfl8NgdnpcaSMtmr227LUMExecwKMhe9 biebMTEWcrrJcX0yLzk9yQ680FILFZyTx5ihSM/ebfRSOmkOkcFy0mIuNV5UFPN2kJcszc3z 8ZjhAp0+RN1jFEFDdoIOABQxqw9WO/m63QfMA1maFN3Ha+fQsHJkZFXxpuL7fU/7fqG/p/8p Kiu+kKsywin9hH7afsAyDrDM9KlFXp/vTZfb7/L5XW6jgzxp+WhDLNc2F3G53FYRLjTqRTeP 36ETKjpwyPLQ5nmmm4vMm827Td5cIzkYJjkYJvVgmLQ0xDAshFHIDBF4kRMv0iaGtiS8L+M6 5Mb3gUo2eJdrD96PByNEHSo9aLWlpAPfu5PhESDRCfgCFhWQCHQqFpUsxCQ98DO7zKMb5HOy QoG7A4ox5KLpm99jz70ScOwcTh9wKc62NiQam5r0StFDC25pf2Hz5ZsrnrmLvN/94pjb7unE 8rI7T/y6G68xN91x4PGHd41pDJD/eT63Ylru5G9/dc+uIxS/nkRIKKVzQLBOVbFOEKlFtaAT Keo29bBKVIEQTZYFuVe2gN1pzBujUD4tJyRJpAo4S4JlgT+WCMscSSJ1SVQyywCzBNjmNQY2 iMa4vcaoVGPcXrO5PaVUFZrwv2D7coHt//OM0hUoTCVJGDhhjDVajMUGT5Xc5tZelr9j99s1 DSwjkk1RaKhvLnhumEGfhF8KyidfI9+99lq3CCb8U2TqdyPI7u5R0NKNCHHf0J4jr++1tUWl V9987cQWvrb6MxxjRCuyUijAzFAWJ4tTFc5t/F04KYKFQd9atDGU2AmlzNviABwlXcayJ3HX qcQrJnzJWnjc8d3ecpqmcbwdtl6BVSRZhXUb1Ig8L/DiIOUiXkiLfdUp6nXccvUD7q+i9JSI U2JGSsv14mCl0RhjNPFN4hSpSbmRXyU8pLwu/o5/Tzwqfi79U/xWLvKqqsBxPBFFSVFk2FFk OS2JfkAAjufTggpWjaoqsAPWGWLLScAoIZXvwG5LEXiW3F4q073hCTY/wLSd51sAKQrYwDiy ZvO4NCKskrBKwipJGuMtTtIdDZn1/5eQmZ1g42X44e3lMQ7rxp+TF83uHRxrbqVxLsrxbed7 60nqdj+R7UK2IkbRwhOsp/oY31sfk0y5QW7gWFkQucZIBZcot3FECRmeWjqFpaCSWapSVVyv yMXFDTC0H+0qrofNu7sSbLMzaVs4Tcy8aQVhwpQ4Md+5K1lPQzy7AnTz0S6zXrQ3bE9nm52a Yx5R65U+yvshj2V/AJ7m9zewAq46uStEL/7bzqh9OnVZNBeg1h4hRnEe12AwpyTPxnb87Oe5 efjVj3KP3SzsP/0ybsut6J5JSq7PXQG43wB6nQS6UJyE9iGJ5WUyrP/mTAilQAe215HyXFuY 2F2leEwj5POJdpDY42HAl5ZCfTdG3C/EmYSiJ8Tj9Gg85oIjcUYxcSp2dKIGg4kS00NIooRm xb97kJYHUTVLuWT5lAfo/JuCYkUfqHu9LK3lhKW4PcR5zhFL8/rIpLif1tF774Jb2y9QyAF0 sRzAf/M0qiHR59GnsYdZA88VzhVfEl4VX5J+Jb8Rky7Rm/SJrvn6TNf13ut9t3tf9n4S+SR6 PKK/qr3oI1EzZhabcVP8Wf449OIRsJiPIwVINhJXTVkU34xF/LFYRI5FOEzkSIwz4mDDP7l7 jAd7QLTtoW+AaJN3Y6KrjlhTHeajUo7ItEt1afAdYPZUtOGXyFqUQCYebOmePY1kOllEbiY8 2U/KUAm+uyC+mOhqME8UHKFgqlLZRV0lLBV1g+scRgR2ziBydKLBNH98SUEzShclM4Po5IMe ocViwNQ9BlaFxEunB5Fg+omHv9r+0A23PIL3+b757TsnL376tcenxV944YKGqztvOvDJ7Pk/ eGST79D7X7ww5dmXn9w4oz/o4flukFhNwHcl5CLFVC35xnltO8dBcaacCA5Aw562UiTb0zV4 Jv7lwkmFCTGyWODYJ+x9ohdCOiesC3qFkwN2KI+xKpYCbLtjBNU2X9j9GSwxGLvcJvPQfd1e AGw/FKH3bTrj/bKn/FSb/cxr5DlKi7mR22K+IbwudprHTU0WmvBkMtaco7WZf9f/bvzdpfA6 b/AuTlOBq/K64ZJFCQxtgZdFXcKICUO3HciRdGDPOuE4WlfEhEiC1/1wlRIXBDkucmIHWWwp SNY/t8AqI/uxhjDWLK+eQLMkbvxY/hD/Mc9toS4SjC1trN4pfaxzW3Ss033TLR2SyM3SGuDm P3C/9wdAIDByw/CDv1CX7UTqAtO2IdLVeLTB7II/yk6zlJ0CN80WEIlG6jaYBw64DgCXtbfA Ps84ldp5NydL+4FEUP6bwcyrtKS1l5f2Xz8p4GYpLsn5klymXJQ4UvNbMuXD57p/9Nj7+H8e GlEaq6EhKvxybhiZiu/fd92dd1CN6LH8Z0wj8mPdUjPuKfwU+Q2ZZ+ELqhvV8ufKI/hL5RXu p4RjbklHxEOZhqj4HRWptzf95F6q2/gzxIm1kR79iDBZRSgHOof5RZsTAZwIjA0QmtS3JsAF /k0YK5NQseroSCrTkVRHR1IdHUnt0ZFUvuAdtXUktccxpTYXUb2odzYdpfVRZnNza+94Vlcj C2RlgbJrPIWQM8v3Zeqoh295bWbu1Lu/yX23+LWLXrjxvb0gKnZ+mDv9xF3Y+Jwbc3rXq3uu eg37oVcn5z/lAyAxsrh97xlTxaHT3paGpYVDLOIQiiGWvZjVqdHRJ6WCze2Oq2qfoniMj/eJ CX2MlKGHwhh5E6wvE1KG3RNOz1RTE5baHmB9eOsbG2kuC7DsrtfN1731YIUMoD/KsisEI2AM N9Yb/HDP5Z4VUW58YIE5zz8zsNxY5V9vbPLfHv2JoQoJFlvT6NJYvIThuZhyYmpkvITpakYG roOXKeJD+8mTKEzmWAq0UoBmGl6HMZ8V07TtDe/S6YlFCZJg8Z3E/8U0yTDTJIPpXDeScUyT zJa+oQ4wScLv/DuTpOpsk6SXQWIPOLPMutm8si6TsXhnsgEwdBrAxPacyt72hzSotynizBMS JVoiMEYmt5fcN//mHY/fWHOZ36st7Vg/b+5mf3vyi5+ufHP+7Jm3bMkde+/neXxr6KENbbes fsz/KFl549W33HZbYs+vrtk1c/oj58Rfuasz949Pqc/lwtw47gv+fBRHlfiXVoumCf4qLe2/ TBvuF5XicHGVlvFXpeq1gf5LtRH+ydIUbY72nfqPItc5qary81Pnl19WvqVqW5U0MDmwT2PV CG1EcnificmJfeZKVyev7tNStabqg/JjyS9TX5V7ggGxqIPsbK+I+SQ22dZMoH5squ0a1IkO g7jpIDdaphCLudXhpTFdDRTVpGt6C9uvHTn0jVXOpG46FDocxGbQCrYE1wT5KqBJMqmK4XaQ 5U4Ge3Ingyx3Mhhgx2iMzZ5o4C1MNLCDG0E7KMOA7xwnyXfWHOYbWebGaVRawphFCVOXS5i6 XFL2qvuQ+2N33s2XuBvdY9xcwXPFNAM3y7x1R9hsl1I224Um3zlzXFgmpTucrVqWrD07p6y5 dZQ9ddHsnU/JEipZDsZJau8eLZi8R20u0oqaW4N0pgjzNJaD4UrsnMpgHXAUNnOkd9hs9g5t wNBlN24MufCKtj8dv/a3d758/VOz/rTtZ1889NSNq7e/cP3K7VMi49IDZk4d1HYHbvjwQYw3 P7jm9LxvDq18jqv8beerb//i9V9Qju4DVFojvIOCuI8V9yvYHa4O9wtb4cXhH+mPGM8YcsSo MNrCnWE+TPmNFSmpLZYNTnfHVFxEsn4fz4lI3erH/ryP9a/P4u0JbEHW0UHdnjjKI47ci+2p Af0LUwOysZJasFbCFpsXZRnUVPEz07aC2bWlzHipKpi2XxdMW3/BtP3CyX/5lHnwqPH7IrNn ngiFX8b7URKdxCqCgTnZewyoUXsCbJeCWdPVTD2dDUyLAyHLYtl+0yMqkiiLRDQVbxR5RHcU 09kda9fibGszWlJDU+DragedSZIpKqLp8Lu2bvVFbl1x2bTo4AHjhx06xD28uXV+7YjLvT9W R7Rctfn0bKDa9fljfAmNX6Ji/IZ1AxZ0d5lQJwwXhMaSthJSUgKSN3ZhjGY0i0N8NL35ssBl kWa52Zjibg5cGZknLzDmuK8NXBvpLHlf/yD4Qfgvvr8F/xb+K8uJDieEane1v5/Q6LaEy9xj hdnCB8X/4L8zdbPIxYsERWlWkloUc52V+mwz1hDt4zRL9Sw7rGFTs7QWbY3G2xnNGvOvaqFC ePQkM7k1J7itOY5UAI4wgmSLOUxgizcswx7CnI32egI1iM27RyxMU0hSsNdUqOEYtnAMc7g0 If9+FmjOyd53poPqvaaDes+aDvrN96eDhth0UL89HTR+0dlZ872mg7K6oyz7ueeQIxTs3Ife k0KTKTvJIU6KTGDz5Zw/eIZWcd+n25fsvGpHq5X7+pWX55PaSfeseP4ny1c8L+zv/sfdY+5+ c2nuq9x7P8b3vzrpjoNvHX79IOXuz+Y+wrfyGcTRNf2s6qXardoPtCe045qANJxRB6kj1Mnq LHWP+hdV0lSXxHMNWGoQRcHFa8+pHXislRIaeCzyKtg0SBClBl4drA0RqvlGntCI3mPuxx60 1dEGOvOVGvRg1zea3d1dLI4JOgHVPBGbA9KKlrSyzET4+ZlgG7T34MGDYy8fUD+Q45oOHjz9 9MGDrXdkRoVnXEG5yn4oNqCD0Pq0FSINSCUN09EidDPagfhtcHwbzx5+srkZntnVv18N3Hc/ 3JC++WPQ3BeAQkKolAyxkl7Nhb0DY1NLZssLS3iF+XdkVkpmYdJoJ8NFw/ED6Q6gOQAoFX/Z 7Y3Ueqnvp7S81kP3i8trzcLWXdjC8T/uLs7Yx+F8s7Clx61LAEi7Lo1dmpigTYstjC1RVrpW udepG90PGM+4O9zHXJ+5TbBrEh633+Nxe9w6MA+SjARU0UstbCGkKIFgJBwP0hYXvPedVhET ZkGULGVhn1DI7XbJcUdfjjsyNN7jUoxnXI+ITgREdPRa5kusZV5FkU2pb06ULS5bU8aVlYZI ryRupiqH/rfRI/Ff3YiF6FHq3O3/LnpU8ByGj4YK5rHtJ2KhpGyWYll9NbOUbUOZ+nd7TTHq cbewdDpLlS13vdsc4vEOYW6cVub9ceU/siLhek9puN4LP5cVqzdL/fArgV9RweeTbaLZZQXd C8SqL8WdQ8ozqRRLNGOEmXyMbDrw9vVvvjOqYtJl+ROvTbr28r7JkX/Gj627f/QDT+T6CfvH /HrVI+8Vp8tGL8+14v63bR6sSd3LuZpBqy6aw+IPEZp5BjSqkoE07+Trgm3sKiQYfMHYq8w0 FuaiCxRSnU84LqHjFrOGCZvOUdDwg4KMVFnEoooERRYwEcro6AjV2Q8Pmh8e9NTU0AguZT7R F+sEjEo99SqNMRueeiXgjdXKtADL6YvdsMWFrUpnFyjxZC2qgIJNwVdK07UoAAXsfWDdVHFO LUpA4db7oAolo9ajOvVidJE6GYzrJnmKMhvPJnPlucpKdB2+jqySVyrXqRvwBrKeu13aKG9S foweVO5Rn0ePq6+gF6Wd6hvol+oH6Pfq39Bf1VPohFoFr6OGUECtQJR7jUEWWOeWN1ArQOfU Oq4veB/66og6bCw3M8YQ07ZoX9A6No+f9gqrJYKga1Q//zALfQO/g9mDWVTd2MiYc9QapEqy nFZUv6KooH+QNAbLFUNDVKQqskwIFiVV4RAWqsFgL5Uty1LW0OAZju6xhDUCEQCylASxcKn2 xe8oxwKLvbu5uzkS6jrabE+cqu/Bck/92XkfTSAgCmtO9MLu5qaebJrkmXAy/mluwc+OpktC 2b/ty13LZ7pvu2bRxBVkI839xkgEnvgiYJpXmL4PzJgCptm5XyxZsVi3fcB02gmTq4KdbM/k Ltcrzf4LO0vUZO4ZUSw4hb5z5rt8ZwfM7AncXueA3HNAEgtTZb62g2Q2spvMPSTyBUf/6TPr QPUK8XqdkKTcc0DSC+bBCSfn/4RNKp7SwoFjTqjgmJ0y7EnYhwvWxEeOD+uj3WdIaB/yUtOB peDZ66mIBcv/XWb/8nZckM7ESuj2gc52l53532lVU8hjsX3Vw2GkixKgpBtQxtBFJl88mPAq 71ELs2rsuZge6vI8aL530HyXpYM1UixkK4/YY00HPQpKiB9X8n1UcqnnCs9dHo6+D/M9HHFm ExxxZoAdt5SSZK0ZK7aDF9aLJWW1vKgrPjGqhL0Cj3hRUzSX7DWRj/NLMTmqFbvKUFqqlLOu WlQnDZHPdQ3jLhItaZQ8UhvqvshzqfcK93jvfGmmfI13lXi9tEzeJ+537/X+QzylVGieClRh lLsq3OXeav9gNMh7nbxefpB7QH8abyfbtaf0PWivuN/1a/498X3lGH/M/Zn3hPidEtOYwNFZ aYr2Ajn2KgAsM7NA21HV5ea9yCNLclpyp110kQ+XxBlYT4Pkfs8aREWNASTKAmLYwH6fqGqe jJr1TOTHq9M8CzyrPZs8qkflgWDpcNgDc6ar7YyW6uwJ+KP75lH6tVcJgL+o5ecEgYiSJCiq KgM6q6aHTvAbuVtA3kRH/hJrtup2JX7hkeSE5PF6s4LkFwTJBeOcNlygMrpksEezquyHy5HQ w04QwZKXl90e3WWw5nkNXafrxVH+4nXTHG7Vf9I0MA25rTE4owM/bamJMSpepN6sErWDTLKU MR68yHOzhzrMJlmaKeAWNquaAw709B580ndyNhO34VEnmptD3c2t8Ec5UXPo0x724ySg2Z5o xpo8rNwwqjdXOnsDWLnBZR6QXGYD/VGY/ka2lUyY0m4k9AR5OX8EYfi58ofbUT93Auj4CPNo Mz/jyLbaCSzr8vBOifpFoCI5YWRbDctmk/NHdkoJu9ZbcFVSAX54rztB7w2c4PAuqR+94y40 mOy3n9Rz857rguw6T/7IbjXBJ9Dg3hk9rvy7e0FNrYIfjRj5qALQ5OjyBW2C5cadvWrDf/pQ lsw4si9I2XKKK+fwyNxL+59p5Gue2be17ry9O3LtLz3T5w/Aon901PMmubb7wbcOktmnPiCr 95w+BLx6dW4caQGL2kTnWWq5GyPTK8mm2YFrdqOtLhm2lkfa6roScSaX4Djuec+PNzNduPtk F8gXFmylOhHOEA/YmINqAM0lscjE+OP7fjNq6strV5Wfl4J3yI17GX+DXV9+0H3qcNOm+196 JVeSS5z1/FmWXkEqTKKoJkZehbZA3QoGFK5pR1u5K13UeCusb2Vntrrs2dcM+JvlVlW6rEeJ i7ie9xbaSLvoe+30pZCHrn2RKa+hKyeZpBvM5GzpeeXXr3156qhDuXH4CP7zy/vu3zT1d6e6 P/gy93VOBruAZhp+bs8BRpV43T7EA8/uwzJj+RGpyanZqaXKbYo4N7JcWKyA9SPcqonlAYUL lVfGA8WK4x/tydtgyR5Rlpyh+Lzxyso+fVCsmKrUJfG4B8khR6MOORp1yF6TgqrDGdGJLX9q pZlazfKoRcbuRRZLF1kMQmSGozgx7dwt7dwtTe/mo3dLZ/QYvZvOJmIw6VxO76BHqqA9TKln QjPOVPH4/4vlIb+fwZX9N/mTo9n+qN7zF88Eqs6sEMmWymJGLLY9mnSeYi+VGUoXSeHkADtG BdoyHBt0PrHh+0lm+1tLZ1+z7u7L1/x8c+4H+Ly1gy8dOeKWR3N/wguvzAydOmTifZtzYMQ1 7Zt15VM15S+vuWZnS39uvCcwe9Qli/qc2ibpg+ePGL+qP9VtFNBtLgFM8HGJfcgs5Oe6C5Mn 6DSps5UJO2uHaSRMIxDs0BSrNXqyynw9WT1WzZksn4wXh3FAI328fXyD8SBusDxYGWwMcdV5 B/lUry/hTdZ6aQFPO0JzBIzCVilsZWpkLQCAp2dxtABtWCMZvo9UoVW6Mt6B/BB5iEbveLE8 kW+Wp2lTXRO91+BZ/Dx5vjbXNcu7nL9eXqVdb1znvc63nt8kbVLv4zvkF72v82/If+D/KL/v es/7GX9MPub61FslMoVN95BJZoCWmkxL6tfYTYGCaNV0VOQ3Q6pHtLPtXBQyRUQMJKuEMEql AiGbLeR8NtN/ZaFguoQ2p5mmz+0yDGyahsfr82kwIsTQON2nalg0iU9Rfb4EUvwIKRyokwmd 8+s6pyoKBxq1zwBZh+TqIlwUDEYSusWyO6e/mFC3qJ0qp3bgjj3TyVZCCECWKrZb5ljzkMkB O5wOMhCF/UWvJVu2M/dpJDyquzn0SbiruQs07BCbcdt8lnTbIJwlyWhmEHzc7kLyZ+8Nk2IH DjQxAWDjdw/bZ3JDA5tJC9djakKGovVemjgQrffZG6oi7o3Wy6XRerq+x65YPVvgoSRW7wNz k4Of4QoEG3zeQPA8Gaz6Bo4HSKN22DlAUqXeek0vTp6HUXGyQVMpRCik+4JQ5wtCHYUIQGdL n96SCexdfNaaNCgLZkKNndvNUhFo4A4rZFBO/wyrE1L9h+Lyd7q7SfZ47u6SZP+i3BZymvws t3F549jL8bruUae/JVrfurHxHP3vJh+D2nJK6EQq+sAaphYmfzCt2jZfWanaGYC2Ow4szNr5 /M3kbvKQzD/PYwWJAuHAZNMJflO1k5NoEAYVcpWOOLMmCpNiUIwxMleBrx23wsxtW8iuZBwt oguW4bbn7rnovQScECwww8LaftyA1yGqAx2lndJ7BZ+GUWyWLdV6HE5W6MdkyiOKUt1AEKLk VPsF70x84C/Vy/gbzl9d8tOL3pyOCLXgeRN4j4oM/CJd/+U763kWVxR75yIxQWN3jp2jxDpH tPOa7I5ipR01t+PoEkuhlGW7njkCWCnI9tKITFKx0u5k7xR9jv6w/oz+hi5cxl1m/BDUSExk sD44SVA1TqIzZI03Od7PcTxnIDCAeYl7ibyEZNA/t1kq4nk4Bb2p8h1k9ouCoFrFJbWqMwyq nd9aWJDPtjnwIMuQrNJUrbQmWSdtcRN7DqS/FhGTJAhHbGOExWGP7mX29h5XB97MYmZ/o750 OgpMyjSYn5psEMwTDScbnGmlG+y8ILfb7ShrBlCXl01gsLSaeq60bz3HFxczImiCcaNOH79u afX6mrH1upWp10tjsC3Mc2j6d3obyoJkqsM1bD0aDiyz+7tvIz/+weuvt+fq8PSfcHtPX/qT 3GOEJ/d1z0f2jEthKoy4GxXjsOVNlOChsq0neMy4G8lBR7L3zrE9aZVSWR3MJBRse8MVJrDp RD4omU9cYYKeJS1ESooLa7uwCVwmQxrzfy3o/9XZFv93EyUKC8OeJd1Z/GIgF7WXp+JlXgyH IiEiaipoIyonFgX8AV+AE6NcMIm9LihCciyJA6oniRj3qYTPWmxPzQRtjk6lBj0gnRxQSFZh 8zPxt89Nvalp2dLR199zcF1uJ66/5yf9h496YMHoF3JvC/uLii+7KnfowNO53DMzBrwwsP/w z5/69J+VcXj3fkBt+1l2ykdWWGSqkMRKkc0Qlv7TPGGRzRCW/s08YQ+FBBLnOZowD/JM6SBL dyfsbIwXxQQm1RzmAN6DC1zpGF0qlSZIFrr/a6fX/+KMw2mn+51lp+CO8t6Heg+AeYKmxR9t /tRkCzg3FhIjzxgRgJI0V574csX8plxUMF544bu/w/MX5j8T9oFunsajrUjUHy0iLeX4StmH vVxZGUp6gySN4mzlQZqNAmYwFoNxF5eMiwoGdp8uc7CzzMHOMntaMnRDGRgTCZIob2GUe7Qn o8Ih4Q/aCzkVJ6waNr9syZpyXF7MBqCYoWsx00iLWR4FcyWpjDmr4czVzvLj9rT7UQU3b3Nh 6UyqXfQkMtPlt3qW5nMWxxjGp6KxSCwc40Q9Y6aLMiUZOc1nUumQUZxEAbcvCSf7fQkJ9kqF dBLHNEBOvweKuJJMojIOClQQkWx9PudTydbYwHVpj2hnYNR6y2oGgDiWziF0rimYTn4vT6Oq Hu4ysvDu3OFtf8xtbd+Nx/5pK8b3ZnYkr9q7aN1r1yUHb8DknpuOn08an8fdR5Ys3Yev/ON7 eGn7NR0/7Ld4zahxt43ZuPVA7ps1MwZhD+UkE7i/k6kwlhoKoj9a07aGd4TJV9JXPvKx9LGP HJIO+cir0qs+skPa4SNbpa0+crd0t4/cJN3kI6fkU36yQF7gJ1PlqX6iy7qf+H2yFNTdGuLc 37q4b4nLIFhvMFCDgWk4p9q3SLpZulviJOwb7G9wGXqD2+2ygpFa13IsDZYbCEYNHHc3cLJw qPVpe7VFOj4UU1nGGoNQI/CPhi7zrCCPHeehkR60pLW1FbcWPmCEFqVooHNQEDoy2QvG/p8n Kq+oGlTL4R86EH/gtz9Z3zC2z4jgFZefgQDrL8AdZB5ZCFZflRVeTBZzZBQeRQhOIRIRFsMJ YX7xnbZoNz9F1aO6oB3wbB/Q0AWkD2iQe2h/X8R9TkYLb7D+/pM1mvX3cfm4n2AZ+8kR6YiP HJYO+0in1OkjbVKbjzwuPe4j90r3+sgt0i0+slha7COz5Fl+MkGeUOhvt65xyP+cj/awbkDH u6DLsfycRCv6YRgGghowdrkbdOj1ciN4PhAG7XRjOSFcA4KOL0cJjPE81udgIReiabTDj5oM BsKgPd3d5WzP7vKe3m6lUTb62jU0c50F2Wp6wZf/vCR7RdXAOu6PDsB/A9187rg+FwWmTzgD UZuKRQ/RQdBrRu9ROSQ9J9L3yWCuAbpdxTQgB3yxAYmDpSFjkB2a24YEtE0rBAXZqnCm3fQz jbYDdT0BQDv8dybwh9G0/Gf8fwNN9CO/3IfKCwHmjBNpTrNcQxZzZhGPMCsjZmHRpWPO3Hsb 0Bwg5gBs0tB5Z8w5wkrMyqu5q/ml3DKeT5fXcfWxodwl0mXFw0uGlY0on8A1SdOKL6+43edK UX5YWFbbBtIOkHGAcgdIMeFsn2wDaQfIOEA5Zb8jKFRhZMpIGVeeHuiuTQ1LD6+empicmpRe oM0z5rtm+2eFqNF3vftGc3nZ0vR6bpN2u7HJfae5ruzW9L3G/e77i+IFa65vMuONZiJKpg/O INQn4uUH9M+gWUABRt9V0dujJJoOGH3j5WmcFgICZed2kmS8rxKPBzjGhrN0gp+NZc2FuX7B +uou+xu1+qbLXIYmJEHxiYLYBOkp4nRZKdSJQjzaN2JRSXF3BEe6Aqgvk0ZsyrSJE3gsbsGL 8RYsAlNqs1x96SPpo6HFlypOaKsn2V8pKDEAZVAf3IcGxWjEvk9hjVGAIgOSTD9KMhGUZMow 9ADOeGlaID3Z6yhJ3p7MTe9EKs3D/QtyqXnUUernKKSpn3TE1Iku+z8OdDezNWNtr7AnaC8L DmATWxq/l/X1PXOLpnbFSc2AguZTVp5ha4Z/b3FXPsh8JiIIn8y0F43pv75x0bMTxk47N7dg 3Nxrbvr6h098u17Y737hmbbH6gfj96esuX79qR//Kvf3h/AfzGvvvPzCpcOGX5MKzsgOemLW op/PnPv2Wtcdd629YkxNzfyKc/esWH5o6bLPKfcbBZRVBPZaMaokHI1wHHdWHTves7SzE6vp WSvaJptUz5SmpD0Dj5X2rFjZib2IZ9YbYNpEIRpZ4sYleDrmcLQibhnYMPyAIEJp3G+ocYzS Jr2KTcAz40GTJWuxLIwgy8gIFmbLHXz3oPlLRz1opv8Bggbn+s4P42GSVTQsPCwxFQZ0PjdT minP885MLJOXx9bJ6/9Pe9ce3dRx5mfm6nFlWZYswDZYtq5fwiBjGwFrZFMsGRuSeIkdcIjF GoxsCSwwlo8k40ObBWUTmtBsQ7Y9hyZsNiRsz25CkoMsUyIgW9MlTVqabbIJpefkCU17tunZ lKTb3ZSl4P3N3CtjAuTs4789sfyb7zfffPP67uhKdzRzr+OcfLYg3yh+IZmb/WGkQiw15KxM 0W6mcP7oXKVCKeMJ+byVnRaGdhbTt3r5Nz6+3DDbZsoXA5LvTd0ze/rsnbaUsCpuE0sJbZTY cBJABz8Rq4psj9bgimmpb0Zp7rQpPDFaSzPU6ytvLuwtjBbuLtQVig2OhcKLheJeC4UF6sI0 VjnuntpLp35zn77qUB2t6kJDuEnb86QOzOm/GoqhSY3iZox8uTgfkXbt1gr54kYLBXTmtC1R 0uXxoprbt63z393H/C9tOXpl9I0HLlz95d/s/fUL711p6Hjkzth3D33tq4d1a/O21q+uX/7b d/s3Xf3szW98vIu203vpsz945h//+N6Gw4HMk48dOQKPPoErKL6CyURf0larynwrrfjB0Jxd fisX5RZoO3JKOJMZvpwa5ZlGo8yMkiSbdIyZjDK/K8tlcSik7KHgGp9JqBSDQZ9dG6yfWhus V2/fgOskn0vcQ2GDYqaKudO8yTxsTpr1Znlqo2yu2CgrpiYsaNR/b82D7pZrHnKaAtPvciNu ksLvkaJdAl/bKyUeO4DrX52YrVLP68f5Vr0Xc/MXy0ou3wHjxtmHf5vFNe9R2bdSbGc5ttIr +zwq9XiN5bO9+Lr+/rHZoB6Vcm2FoD5zhdeYNxOYweO/PzYDtESlJaCzOP3D2NSCCHrtrOZW bxOwiPJNXDT/iVclduLVP17Vn7h8n273f67UJS8n4SkrIdKnOhexMcov3LXfnG1Tu7nUjfLS 9I3ys6zUbNAxk4EZLDkkR9sgX+cWv9Hliz3xL1rt1IqO8f06vs7Z3vXW/br98uN5B6yn9KcM p4w/sZqsvgLvHGmGaZZljm0JbTTfRx8xy3X2e3QBY8Dcnfcd+ljOY+YXWSb3R+Yzea/Z3pZ+ Zvpnyzu2X+XY7dcmRO351iKLLTshyplVTIjm5DDDjROimw0GSZ0SNZjEpKjVauNzolarxTY1 IWrLMViZNcf2CnnFxGxVU1Oir+C8WDV9VtRgE7OiOR12ar/dsiu3PMcaNJh2+XACKX7RZ+g0 JMW+ghW+PEXaxco74Ozb8+99WdtdIhYYzCn62PYr2+8/vmECtNa9QZsA3aDtjeTzn2LS82U1 hDCKidBl2m9kR/OKSrxibtJc4s0tL/RKAI+ny7w28Yad5aXlZV6Tz5EdLHw7PL97T3Y3PJ94 LOQTjw184lGaS630gauPX/jbWkdN1fjPr/4Vffi9txuvfsSq6dVLq+pbFl2+mnvlp/SOwNUN 4jGT/LFbsw/s8b5V3Gtd9u9ysSyePnnow7nzs0+inLxy9S6DS38W1KQ9e1nkMy6/eidZce2B lZ97LHGjASr9OnJIFycP6gjphLxD482Q99NXyf3MSyrB24GV/BmjhsPkQegfMnhJPztM9kA3 gTKeFPnipBXpj0HuRxllug/JM+B3c+hfJd+F7iHwZfp1k1cQfxp8HdCCMmZAfh3yMHBCpBEy B9KAOu7lQB37ARPsPgB42pMovx7t2I70tYAfWMXLgF0PbFbD5gmUY+XP0iNfp/ezZ3Wd+j81 bpfXmUym7+ecNr9pftMymrfRWmp9znab7Tf55+wXZj4683zByoLnC/9lduHso8Uex3DJU6Xt zs3K3jJ/+d3lR8vfrJxb1VPtqY5V/3DeGfeeGnkBXTBR66tz1Z2se78+UZ/ybFh0aPH+JSc1 jzeSpbh243+M2EgdWUeI7nnz93G9wHgq40/MVtO3ilAS+XJETBK58khC4xLZSP5C4zrYnNc4 f+7xbzRuIHmUadxI+qhN4zKppzGNm8g36CGNW9hhVjM1NpbozmkcQ0Nv1jgjRr1N4xKp0xdq XAeblRrXk1x9u8YNsL9H40ayUL9R4zIp0u/TuIm06f9e4xZ6t/5fUTLVSXwXvdEvOPeQzbha cIPQbxDcKPQRwWXBdwpu4j407tU4fGj8N43Dh8YrGocPZbPG4UM5onH4UI5rHD6UH9Y4fCg/ rnH4UL6scfjQ5NY4fGj6nuA54i4AvYKbedtytwmeK/RfEzxP8AcFt/G25X5b8Bng9tynBZ8p bMYFnyXKmRC8QOhfF3y2yPuO4MXC5iPBS4TNJcGd4hZVesErub0lX/D5gjsFX8BHomUB57Jo v8ZFXRYv57mqvk1w0RfLXeRZohAPqRdPxVZIFxnAdZZCVuN6eAhIkJ1kWGhWIBYD52EQ+oiw qEWKnwzipZA10G1B/gSJi1gYMgzrHQhDsPSDR5B3UKRtISNgQeg+X1fjNEvlc7aNeOfxMuNa /QpZgpIXov0KqUZJEdKP1CjSo2QzSpw3raxb5bxmsRr9n153RPQkCCREr0MoYbtoxzboeA3/ G4/9T3PcaNc1xVqF5Sgsh+AlhXSgTZuFF3jqAuG/KOkT6Qq5U6QMQMO9GSc10HWKmmIiJSL6 uhbhCOxDmr8UeMmL85+HBJBzBHHug52QI+IIc+8MaL7aLNqaELoowpDQD4v6dgpf8nIVaGKi TdyyX8sT1uJBUdKwqH07rBIijefqE2UkNP8Nav0cmmqFmiPbjtg022ExKkJocb+oQ/XHqGg3 98jN+6DGuW0/ahsRHgmJMf95T/Acg4JVw34eJB8pfVq7b1720P+h79dKD00d+5h4x2WPZXb0 3KwH2dpvbFfTtGPEe6L2JSHqy45LXr7a1xA0o6LnUfHu+KKRELzuqIfF0YlqodorlY8gNixC RbR2x9RoVsvhloOw+KIxVPus4qlfuFDpGggrq6ND0cTO4bCyIhobjsaCiUh0qFbxDw4qayJb BhJxZU04Ho7tCIdq/bFIcHBNeMvIYDCWzdUolIqmbVwXjsWRX1lSu7BeqV4d6Y9F49HNiXnC anqiUKzuUnNH4kpQScSCofD2YGybEt1864bdKmFK18WD1lhwNDK0RenYvDnSH1YWKGuifZEh 5c5I/0B0MBivUTqDiVikPxJU1gZHhkJol7LQu9QTiI4o24M7lZF4WEkMoFWbo0MJJRFVQpH4 8CASgkMhZTgWgbIfKWHIYFwZDse2RxKJcEjp24lsYWUQdQ7xIpDAy4gJ7XAsGhrpTyhox+gA GjKtBsjIUP/gSAhOVrKNiA4N7lSqI/OU8PY+lD3NeugLaxfmId77WDjOe8ndc60Cnn2qrCbR o+oIakmEt3NfxiKoNRQdHRqMBkPXOyGodj0cU9CjKKpCOJIYHkkoofAO7mbYDIQHh6/3UC1O qlHxZg2KtwHeptSCYbgVA/EjcdrOpq3FwFTfWvwtFJIOSGPSP0gTwHHphPT8lx/EX34Qf/lB /OUH8f+vD+Lrzo7XeFCMmZulXbjObhDlTD9vijPnLcochM3O6XFdqW6hrl23SvcVhN7rahhC ubcq5U6EO4QX1ff6AE3Rp3GNzY/trfPcnGtzAmRyLl/te+PfcdIlVY+7ipxvvCTNI+cBJs1L u0ucx6W5Ukm6yenLSBXj9lkeq3+BxOdu60SoIIwCR4AJQEd6Jb66xIZwN5AEjgATwBuAAQ0p FakKEAUOAud5ilQiOdKK0+afK81GXn41apUKyUVgEpCIE2Ed0AH0AvuAg4BB2HFNFNgNTACf iBSfVJj+1iK0vTD9sBDjWwc9IhpUoz0bRHT8noAqV9+lytbbVbNG1WzhYlVd26LKuTWqtFd5 klzmWDyn/AVSATrJL3OHEVL2MrFSSpzkKWkWSQFMMmgan2Qfr3R5Dk5IOkIlJlEcY+fkKYmm Lfkefw6bZBeJnTjZb9nHagr7eDwv33PQfwf7BTkCTAAS+wVeF9gFspud5z5H2AwcBCaA14GL gIGdx+sDvN5n7xMre4/UAc1AL3AQmAAuAkb2HkIbe5fPo4iQ82aAsXcR2tg76NY7CK3sbbC3 2dto2lvpBq/nuCDuOo04qzRSWKwRe4Enw95MX5qHEeXCkcaIOimVk+VkkVSerlrozEhF6WUR Z4Z9OK64nU/569lZkgIYWnIWNZ8lCtAJbAKGAQPYObBzJAk8CjwFpACMMoQ2QGFngNeAc6Qe 8AGdgMzeSKOaDHs97Wpx+gvYT9mrpBAe/yf2IyFfY68I+RP2QyF/DFkKeYa9ki51Er8Z6QR5 bJA2yDqk69kPxivtzkl/PpuA75wI64BmoAPoBfYBBjbBytMhpx2FnCRnZALLNPlIyL8jh2Ti 2+r0uVZgACo8cDV+BQzBQeWgi/lc+x9HlAeuR74FxgPXA38JxgPXV+8D44FrcAcYD1yhrWA8 cK3vBeOBq6MLDEGGPfli5VxnQ8c2qvitbBReGoWXRuGlUaJjo/xFLul42/46PX8+PHbA5543 35k8QZMv0eQamjxEk2Ga3EWT99HkMprcSJNumnTQZClN+mjyJF0KVySp7+h1Ua+viCbP0OQL NBmnSRdNVtFkJU0qtMGXYWXp2xcJ0SbEuJ+/6SC/shxnHysrg0fLMObLcE6YQPg6MCliPhgp 5arx7FIuy8fnN6vx2kZP1H8bO42Mp3EYTpMPAB0O0GkMo9Mo5DQKsCJsBnqBU8BFYBIwwLoc Dd8nQivCOqAZ6AV2AxcBg2jORYCRqNbEI6JhdVqjO3iMncarHK8yVuYrsTlsbttt0j4HtZbS jtLJUtZACgpwRrbny/kZajn2meUPn1mIyW9ij7B9pAQH4lFN7ktfKnFm6GNp10mnfxb9DinV YdRRL3HRKsilJC7iS4hD5nIxcbDnID1pxzpks6ZdNc4TNI/nOua85Pil8yNHhoH+2nHS+XMl o6Np58+gee6Y86xjr/PHdRkZmpdcGQpxQhGmxx1LnS+cEab3IeFA2rmLi2POP3escm5ziISw mrAxjpjP6lzjWu+8DeW1OvqcvjjKPOZsdmx0LlOtlvA8x5z1aIJbpfPR2HkOUWlFqSjw7oYM HfDVGPcbu40dxj8xeow1xjKj01hiLDbOlO2yTc6Tc+UcWZYNsk5mMpFn8p+j3XwOeqbBJrZw 6nioE9zGeMjU6XVGZUbuIKkZUjtrX9tC21On+kl7n5L6j7UVGZpz1/qUvqKFpuztpL2rJbXU 3Z4xTq5JNbjbU8bOP+seo/SRALQp9lCGkq7uDJ3kqj3FKfsKfmNSmr/nm8VcVu/5ZiBAigp2 NBc125fne1e23iTYpIXTlkEUXcdLUvvb13anDpcEUh5OJksC7alvr1V6uo/T39FP2lqP00+5 CHQfl5bT37Wt4XppeWsg0J6h64QdUeinsMOI+VTYyfhg5nZEkUtVuwOqXRXyw66SC9iZTKRK 2FWZTMJOR7ndWLyyrXWsslLYFCokLmzihcp0mzNVsKmqEjYFSXJG2JwpSHKb1HJh4nDApNQh TOgc4hAmDjpHmKy7ZlKnmeydMtkrapLoNRuHamM5n7WxnG8N3HDf0lv+hVvcbjreFOjvaQtX tG2qaAsDm1IP7xgoSiX7FGWsP8ATlJTk2tTXP8BlMJwKVIRbU/0VrcpYU89Nknt4clNF6xjp aevqHuvxhVvTTb6mtopga2B8Vefihuvq2jtV1+LOmxTWyQtbzOta1XCT5AaevIrX1cDrauB1 rfKtEnURMcY7u8dk0hJY0aPKcWbOwXjdVFwWaCmwDS8Xg7eprGhX8Ql8W3mGmN2BVG5FS8oC 8KQF/gV+noT3FE/Kg9qqJRXtaiorPkGf0ZJsUOdXtBB3YiQ+QoraIq3qfxx/UCVGuMPV0B2/ 1R/S2lK+YGs8QUh7av7a9lTzXeu7x4xGaDfxLqUaszqzuS0zeUpV1kLZyJWSNGXIdcu4zmTS DG88/iOaFEvmk/wWhr5SmiDxgJQqbe9iOBV0rUdfe9Z3n8B3Kf7xEA+gg3HqpvFsGVqzs09s cBPe5ywSIxrTfJHQpJoTWeJZl0z9cWe5pzyWQIHkvwD1EsdKCmVuZHN0cmVhbQplbmRvYmoK CjM3IDAgb2JqCjIzNzQ3CmVuZG9iagoKMzggMCBvYmoKPDwvVHlwZS9Gb250RGVzY3JpcHRv ci9Gb250TmFtZS9CQUFBQUErQXJpYWxNVAovRmxhZ3MgNAovRm9udEJCb3hbLTY2NCAtMzI0 IDIwMDAgMTAwNl0vSXRhbGljQW5nbGUgMAovQXNjZW50IDkwNQovRGVzY2VudCAtMjExCi9D YXBIZWlnaHQgMTAwNQovU3RlbVYgODAKL0ZvbnRGaWxlMiAzNiAwIFIKPj4KZW5kb2JqCgoz OSAwIG9iago8PC9MZW5ndGggNDcxL0ZpbHRlci9GbGF0ZURlY29kZT4+CnN0cmVhbQp4nF2T TY+bMBCG7/wKH7eHFXjMR1ZCSLvJRsqhH2q2P4CAkyI1gAg55N/X77xuK/WQ6LGZGR4PnnR7 2B3GYU2/LVN39Ks5D2O/+Nt0XzpvTv4yjIkV0w/dGlf6313bOUlD7vFxW/31MJ6nuk7S7+HZ bV0e5um1n07+U5J+XXq/DOPFPP3YHsP6eJ/nX/7qx9VkSdOY3p9Dnc/t/KW9+lSzng99eDys j+eQ8i/g4zF7I7q2VOmm3t/mtvNLO158UmdZY+r9vkn82P/3rKiYcjp3P9slhNoQmmV50QQW 5fId7MgOnJMtuFCuMnBJ1piKrHU2jN+CX7ifg1+5rzFvZN3fKovW3HF/B34nv4D39AyHqm3G mgKO/oix9C9Qx0b/DTj6ay79c9S39M/haaO/1qF/XoLp77Qm/R38Lf1zrU//8g1Mf6du9M/R N0v/ArlCf4e+Cf3LChz7j/dK9Ecdob9DfaG/4BsJ/QuNif6aS/9Ka9Jf4Cn0F5xRor/m0r/Q mOgPZ6G/wzeS2H+wo3+hHPuPdzn4S2bRT0d/QZ9dzn3l6K8x0R99cPR38Hex/ziji/dno5c5 3lpca8zdn3Ex3X1ZwqjocOqMYDqG0f+d33makaW/3xbQ8JMKZW5kc3RyZWFtCmVuZG9iagoK NDAgMCBvYmoKPDwvVHlwZS9Gb250L1N1YnR5cGUvVHJ1ZVR5cGUvQmFzZUZvbnQvQkFBQUFB K0FyaWFsTVQKL0ZpcnN0Q2hhciAwCi9MYXN0Q2hhciA1NwovV2lkdGhzWzc1MCA2NjYgNTU2 IDUwMCA1NTYgNTU2IDUwMCA1NTYgMjIyIDI3NyA1NTYgNTU2IDI3NyA4MzMgMjIyIDc3Nwoz MzMgMjc3IDY2NiA1NTYgNTU2IDgzMyA1NTYgNTAwIDYxMCA1NTYgNTU2IDcyMiA1MDAgNTU2 IDY2NiA3MjIKNTU2IDU1NiAyNzcgNTU2IDI3NyAyNzcgNzIyIDUwMCA3MjIgMzMzIDMzMyA2 NjYgNjY2IDU1NiA1NTYgNzIyCjYxMCA3NzcgMzMzIDMzMyAzMzMgMjc3IDY2NiA1NTYgNzIy IDUwMCBdCi9Gb250RGVzY3JpcHRvciAzOCAwIFIKL1RvVW5pY29kZSAzOSAwIFIKPj4KZW5k b2JqCgo0MSAwIG9iago8PC9GMSA0MCAwIFIvRjIgMzUgMCBSL0YzIDMwIDAgUgo+PgplbmRv YmoKCjQyIDAgb2JqCjw8L0ZvbnQgNDEgMCBSCi9Qcm9jU2V0Wy9QREYvVGV4dF0KPj4KZW5k b2JqCgoxIDAgb2JqCjw8L1R5cGUvUGFnZS9QYXJlbnQgMjUgMCBSL1Jlc291cmNlcyA0MiAw IFIvTWVkaWFCb3hbMCAwIDU5NSA4NDJdL0dyb3VwPDwvUy9UcmFuc3BhcmVuY3kvQ1MvRGV2 aWNlUkdCL0kgdHJ1ZT4+L0NvbnRlbnRzIDIgMCBSPj4KZW5kb2JqCgo0IDAgb2JqCjw8L1R5 cGUvUGFnZS9QYXJlbnQgMjUgMCBSL1Jlc291cmNlcyA0MiAwIFIvTWVkaWFCb3hbMCAwIDU5 NSA4NDJdL0dyb3VwPDwvUy9UcmFuc3BhcmVuY3kvQ1MvRGV2aWNlUkdCL0kgdHJ1ZT4+L0Nv bnRlbnRzIDUgMCBSPj4KZW5kb2JqCgo3IDAgb2JqCjw8L1R5cGUvUGFnZS9QYXJlbnQgMjUg MCBSL1Jlc291cmNlcyA0MiAwIFIvTWVkaWFCb3hbMCAwIDU5NSA4NDJdL0dyb3VwPDwvUy9U cmFuc3BhcmVuY3kvQ1MvRGV2aWNlUkdCL0kgdHJ1ZT4+L0NvbnRlbnRzIDggMCBSPj4KZW5k b2JqCgoxMCAwIG9iago8PC9UeXBlL1BhZ2UvUGFyZW50IDI1IDAgUi9SZXNvdXJjZXMgNDIg MCBSL01lZGlhQm94WzAgMCA1OTUgODQyXS9Hcm91cDw8L1MvVHJhbnNwYXJlbmN5L0NTL0Rl dmljZVJHQi9JIHRydWU+Pi9Db250ZW50cyAxMSAwIFI+PgplbmRvYmoKCjEzIDAgb2JqCjw8 L1R5cGUvUGFnZS9QYXJlbnQgMjUgMCBSL1Jlc291cmNlcyA0MiAwIFIvTWVkaWFCb3hbMCAw IDU5NSA4NDJdL0dyb3VwPDwvUy9UcmFuc3BhcmVuY3kvQ1MvRGV2aWNlUkdCL0kgdHJ1ZT4+ L0NvbnRlbnRzIDE0IDAgUj4+CmVuZG9iagoKMTYgMCBvYmoKPDwvVHlwZS9QYWdlL1BhcmVu dCAyNSAwIFIvUmVzb3VyY2VzIDQyIDAgUi9NZWRpYUJveFswIDAgNTk1IDg0Ml0vR3JvdXA8 PC9TL1RyYW5zcGFyZW5jeS9DUy9EZXZpY2VSR0IvSSB0cnVlPj4vQ29udGVudHMgMTcgMCBS Pj4KZW5kb2JqCgoxOSAwIG9iago8PC9UeXBlL1BhZ2UvUGFyZW50IDI1IDAgUi9SZXNvdXJj ZXMgNDIgMCBSL01lZGlhQm94WzAgMCA1OTUgODQyXS9Hcm91cDw8L1MvVHJhbnNwYXJlbmN5 L0NTL0RldmljZVJHQi9JIHRydWU+Pi9Db250ZW50cyAyMCAwIFI+PgplbmRvYmoKCjIyIDAg b2JqCjw8L1R5cGUvUGFnZS9QYXJlbnQgMjUgMCBSL1Jlc291cmNlcyA0MiAwIFIvTWVkaWFC b3hbMCAwIDU5NSA4NDJdL0dyb3VwPDwvUy9UcmFuc3BhcmVuY3kvQ1MvRGV2aWNlUkdCL0kg dHJ1ZT4+L0NvbnRlbnRzIDIzIDAgUj4+CmVuZG9iagoKNDMgMCBvYmoKPDwvQ291bnQgOC9G aXJzdCA0NCAwIFIvTGFzdCA1MSAwIFIKPj4KZW5kb2JqCgo0NCAwIG9iago8PC9Db3VudCAw L1RpdGxlPEZFRkYwMDUzMDA2QzAwNjkwMDY0MDA2NTAwMjAwMDMxPgovRGVzdFsxIDAgUi9Y WVogMCA4NDIgMF0vUGFyZW50IDQzIDAgUi9OZXh0IDQ1IDAgUj4+CmVuZG9iagoKNDUgMCBv YmoKPDwvQ291bnQgMC9UaXRsZTxGRUZGMDA1MzAwNkMwMDY5MDA2NDAwNjUwMDIwMDAzMj4K L0Rlc3RbNCAwIFIvWFlaIDAgODQyIDBdL1BhcmVudCA0MyAwIFIvUHJldiA0NCAwIFIvTmV4 dCA0NiAwIFI+PgplbmRvYmoKCjQ2IDAgb2JqCjw8L0NvdW50IDAvVGl0bGU8RkVGRjAwNTMw MDZDMDA2OTAwNjQwMDY1MDAyMDAwMzM+Ci9EZXN0WzcgMCBSL1hZWiAwIDg0MiAwXS9QYXJl bnQgNDMgMCBSL1ByZXYgNDUgMCBSL05leHQgNDcgMCBSPj4KZW5kb2JqCgo0NyAwIG9iago8 PC9Db3VudCAwL1RpdGxlPEZFRkYwMDUzMDA2QzAwNjkwMDY0MDA2NTAwMjAwMDM0PgovRGVz dFsxMCAwIFIvWFlaIDAgODQyIDBdL1BhcmVudCA0MyAwIFIvUHJldiA0NiAwIFIvTmV4dCA0 OCAwIFI+PgplbmRvYmoKCjQ4IDAgb2JqCjw8L0NvdW50IDAvVGl0bGU8RkVGRjAwNTMwMDZD MDA2OTAwNjQwMDY1MDAyMDAwMzU+Ci9EZXN0WzEzIDAgUi9YWVogMCA4NDIgMF0vUGFyZW50 IDQzIDAgUi9QcmV2IDQ3IDAgUi9OZXh0IDQ5IDAgUj4+CmVuZG9iagoKNDkgMCBvYmoKPDwv Q291bnQgMC9UaXRsZTxGRUZGMDA1MzAwNkMwMDY5MDA2NDAwNjUwMDIwMDAzNj4KL0Rlc3Rb MTYgMCBSL1hZWiAwIDg0MiAwXS9QYXJlbnQgNDMgMCBSL1ByZXYgNDggMCBSL05leHQgNTAg MCBSPj4KZW5kb2JqCgo1MCAwIG9iago8PC9Db3VudCAwL1RpdGxlPEZFRkYwMDUzMDA2QzAw NjkwMDY0MDA2NTAwMjAwMDM3PgovRGVzdFsxOSAwIFIvWFlaIDAgODQyIDBdL1BhcmVudCA0 MyAwIFIvUHJldiA0OSAwIFIvTmV4dCA1MSAwIFI+PgplbmRvYmoKCjUxIDAgb2JqCjw8L0Nv dW50IDAvVGl0bGU8RkVGRjAwNTMwMDZDMDA2OTAwNjQwMDY1MDAyMDAwMzg+Ci9EZXN0WzIy IDAgUi9YWVogMCA4NDIgMF0vUGFyZW50IDQzIDAgUi9QcmV2IDUwIDAgUj4+CmVuZG9iagoK MjUgMCBvYmoKPDwvVHlwZS9QYWdlcwovUmVzb3VyY2VzIDQyIDAgUgovTWVkaWFCb3hbIDAg MCA1OTUgODQyIF0KL0tpZHNbIDEgMCBSIDQgMCBSIDcgMCBSIDEwIDAgUiAxMyAwIFIgMTYg MCBSIDE5IDAgUiAyMiAwIFIgXQovQ291bnQgOD4+CmVuZG9iagoKNTIgMCBvYmoKPDwvVHlw ZS9DYXRhbG9nL1BhZ2VzIDI1IDAgUgovT3BlbkFjdGlvblsxIDAgUiAvWFlaIG51bGwgbnVs bCAwXQovT3V0bGluZXMgNDMgMCBSCj4+CmVuZG9iagoKNTMgMCBvYmoKPDwvQ3JlYXRvcjxG RUZGMDA0NDAwNzIwMDYxMDA3Nz4KL1Byb2R1Y2VyPEZFRkYwMDRDMDA2OTAwNjIwMDcyMDA2 NTAwNEYwMDY2MDA2NjAwNjkwMDYzMDA2NTAwMjAwMDMzMDAyRTAwMzY+Ci9DcmVhdGlvbkRh dGUoRDoyMDEyMTEwMTA4MjUzNFonKT4+CmVuZG9iagoKeHJlZgowIDU0CjAwMDAwMDAwMDAg NjU1MzUgZiAKMDAwMDA3NzU0OSAwMDAwMCBuIAowMDAwMDAwMDE5IDAwMDAwIG4gCjAwMDAw MDE4MzQgMDAwMDAgbiAKMDAwMDA3NzY5MyAwMDAwMCBuIAowMDAwMDAxODU1IDAwMDAwIG4g CjAwMDAwMDUxNDcgMDAwMDAgbiAKMDAwMDA3NzgzNyAwMDAwMCBuIAowMDAwMDA1MTY4IDAw MDAwIG4gCjAwMDAwMTEzOTcgMDAwMDAgbiAKMDAwMDA3Nzk4MSAwMDAwMCBuIAowMDAwMDEx NDE4IDAwMDAwIG4gCjAwMDAwMTc1MjkgMDAwMDAgbiAKMDAwMDA3ODEyNyAwMDAwMCBuIAow MDAwMDE3NTUxIDAwMDAwIG4gCjAwMDAwMjMwNTYgMDAwMDAgbiAKMDAwMDA3ODI3MyAwMDAw MCBuIAowMDAwMDIzMDc4IDAwMDAwIG4gCjAwMDAwMjkwNTggMDAwMDAgbiAKMDAwMDA3ODQx OSAwMDAwMCBuIAowMDAwMDI5MDgwIDAwMDAwIG4gCjAwMDAwMzUxOTEgMDAwMDAgbiAKMDAw MDA3ODU2NSAwMDAwMCBuIAowMDAwMDM1MjEzIDAwMDAwIG4gCjAwMDAwNDA1NzIgMDAwMDAg biAKMDAwMDA3OTgxMiAwMDAwMCBuIAowMDAwMDQwNTk0IDAwMDAwIG4gCjAwMDAwNDE5ODAg MDAwMDAgbiAKMDAwMDA0MjAwMiAwMDAwMCBuIAowMDAwMDQyMTk0IDAwMDAwIG4gCjAwMDAw NDI0ODYgMDAwMDAgbiAKMDAwMDA0MjY0NyAwMDAwMCBuIAowMDAwMDUxNzU2IDAwMDAwIG4g CjAwMDAwNTE3NzggMDAwMDAgbiAKMDAwMDA1MTk3NCAwMDAwMCBuIAowMDAwMDUyMjkwIDAw MDAwIG4gCjAwMDAwNTI0NjkgMDAwMDAgbiAKMDAwMDA3NjMwMyAwMDAwMCBuIAowMDAwMDc2 MzI2IDAwMDAwIG4gCjAwMDAwNzY1MTcgMDAwMDAgbiAKMDAwMDA3NzA1OCAwMDAwMCBuIAow MDAwMDc3NDQxIDAwMDAwIG4gCjAwMDAwNzc0OTQgMDAwMDAgbiAKMDAwMDA3ODcxMSAwMDAw MCBuIAowMDAwMDc4NzY3IDAwMDAwIG4gCjAwMDAwNzg4ODggMDAwMDAgbiAKMDAwMDA3OTAy MSAwMDAwMCBuIAowMDAwMDc5MTU0IDAwMDAwIG4gCjAwMDAwNzkyODggMDAwMDAgbiAKMDAw MDA3OTQyMiAwMDAwMCBuIAowMDAwMDc5NTU2IDAwMDAwIG4gCjAwMDAwNzk2OTAgMDAwMDAg biAKMDAwMDA3OTk1OSAwMDAwMCBuIAowMDAwMDgwMDYxIDAwMDAwIG4gCnRyYWlsZXIKPDwv U2l6ZSA1NC9Sb290IDUyIDAgUgovSW5mbyA1MyAwIFIKL0lEIFsgPEY3QTI5OThEMDVEN0NB ODM5MjFFMDkzMDNBN0FFQ0ZDPgo8RjdBMjk5OEQwNUQ3Q0E4MzkyMUUwOTMwM0E3QUVDRkM+ IF0KL0RvY0NoZWNrc3VtIC9GRjdBNUQwQTVFNEIxMTM3NkE2MTU0ODgxQTQ4Njg3Rgo+Pgpz dGFydHhyZWYKODAyMjMKJSVFT0YK --------------000503070407030003080605-- --------------ms070205090006030402030604 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIILUDCC BRowggQCoAMCAQICEG0Z6qcZT2ozIuYiMnqqcd4wDQYJKoZIhvcNAQEFBQAwga4xCzAJBgNV BAYTAlVTMQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoT FVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3Qu Y29tMTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQg RW1haWwwHhcNMTEwNDI4MDAwMDAwWhcNMjAwNTMwMTA0ODM4WjCBkzELMAkGA1UEBhMCR0Ix GzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UE ChMRQ09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENPTU9ETyBDbGllbnQgQXV0aGVudGlj YXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC ggEBAJKEhFtLV5jUXi+LpOFAyKNTWF9mZfEyTvefMn1V0HhMVbdClOD5J3EHxcZppLkyxPFA GpDMJ1Zifxe1cWmu5SAb5MtjXmDKokH2auGj/7jfH0htZUOMKi4rYzh337EXrMLaggLW1DJq 1GdvIBOPXDX65VSAr9hxCh03CgJQU2yVHakQFLSZlVkSMf8JotJM3FLb3uJAAVtIaN3FSrTg 7SQfOq9xXwfjrL8UO7AlcWg99A/WF1hGFYE8aIuLgw9teiFX5jSw2zJ+40rhpVJyZCaRTqWS D//gsWD9Gm9oUZljjRqLpcxCm5t9ImPTqaD8zp6Q30QZ9FxbNboW86eb/8ECAwEAAaOCAUsw ggFHMB8GA1UdIwQYMBaAFImCZ33EnSZwAEu0UEh83j2uBG59MB0GA1UdDgQWBBR6E04AdFvG eGNkJ8Ev4qBbvHnFezAOBgNVHQ8BAf8EBAMCAQYwEgYDVR0TAQH/BAgwBgEB/wIBADARBgNV HSAECjAIMAYGBFUdIAAwWAYDVR0fBFEwTzBNoEugSYZHaHR0cDovL2NybC51c2VydHJ1c3Qu Y29tL1VUTi1VU0VSRmlyc3QtQ2xpZW50QXV0aGVudGljYXRpb25hbmRFbWFpbC5jcmwwdAYI KwYBBQUHAQEEaDBmMD0GCCsGAQUFBzAChjFodHRwOi8vY3J0LnVzZXJ0cnVzdC5jb20vVVRO QWRkVHJ1c3RDbGllbnRfQ0EuY3J0MCUGCCsGAQUFBzABhhlodHRwOi8vb2NzcC51c2VydHJ1 c3QuY29tMA0GCSqGSIb3DQEBBQUAA4IBAQCF1r54V1VtM39EUv5C1QaoAQOAivsNsv1Kv/av QUn1G1rF0q0bc24+6SZ85kyYwTAo38v7QjyhJT4KddbQPTmGZtGhm7VNm2+vKGwdr+XqdFqo 2rHA8XV6L566k3nK/uKRHlZ0sviN0+BDchvtj/1gOSBH+4uvOmVIPJg9pSW/ve9g4EnlFsjr P0OD8ODuDcHTzTNfm9C9YGqzO/761Mk6PB/tm/+bSTO+Qik5g+4zaS6CnUVNqGnagBsePdIa XXxHmaWbCG0SmYbWXVcHG6cwvktJRLiQfsrReTjrtDP6oDpdJlieYVUYtCHVmdXgQ0BCML7q peeU0rD+83X5f27nMIIGLjCCBRagAwIBAgIQXDFQ28QtqMuYch5f2nTvZjANBgkqhkiG9w0B AQUFADCBkzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4G A1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENP TU9ETyBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTAeFw0xMTA5 MDIwMDAwMDBaFw0xNDA5MDEyMzU5NTlaMIIBNzELMAkGA1UEBhMCR0IxEDAOBgNVBBETB1dG NCA0V0ExFzAVBgNVBAgTDldlc3QgWW9ya3NoaXJlMRIwEAYDVQQHEwlXYWtlZmllbGQxFDAS BgNVBAkTC0dyYW5nZSBNb29yMR8wHQYDVQQJExY4OSBHcmVlbmZpZWxkIENyZXNjZW50MRcw FQYDVQQKEw5HcmlkbWVyZ2UgTHRkLjE0MDIGA1UECxMrSXNzdWVkIHRocm91Z2ggR3JpZG1l cmdlIEx0ZC4gRS1QS0kgTWFuYWdlcjEfMB0GA1UECxMWQ29ycG9yYXRlIFNlY3VyZSBFbWFp bDEWMBQGA1UEAxMNUm9iZXJ0IENyYWdpZTEqMCgGCSqGSIb3DQEJARYbcm9iZXJ0LmNyYWdp ZUBncmlkbWVyZ2UuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEArcThqvLe WU1Q1ZJmnb+2UQSwOQKWok3A1Mwk582AdvwaAQyBFliPyJ0kXJqtwNBoZvk+3WJr0QA5ZRr+ J0x3sXVpcxadojP2HNzy1gsgDtIGG8ltoU4vmX1A8BTlOIUT+Pg8p/bSruxV0vz0CR8ho2hs R0Zi5vU+rQKNmbgufbkWhlQnMEYjknemscLQfw1YZz90ta67doNDujFy6+X6I06HpjudgMYx 8bdsNS5xVFFwuBA1eqNQra+xLzhCOeX9PPB/zK68qdNhrni3WPYG9EhSt4Dzk+xIz9hj7wrU ZIVXDTPsY8qbUSBVpwmzI5lCHPgzurH1OK7WwgpDSsl5pwIDAQABo4IB1TCCAdEwHwYDVR0j BBgwFoAUehNOAHRbxnhjZCfBL+KgW7x5xXswHQYDVR0OBBYEFBCOXNH+lDm8U9gy3b3bRvrx vKgrMA4GA1UdDwEB/wQEAwIFoDAMBgNVHRMBAf8EAjAAMB0GA1UdJQQWMBQGCCsGAQUFBwME BggrBgEFBQcDAjBGBgNVHSAEPzA9MDsGDCsGAQQBsjEBAgEDBTArMCkGCCsGAQUFBwIBFh1o dHRwczovL3NlY3VyZS5jb21vZG8ubmV0L0NQUzBXBgNVHR8EUDBOMEygSqBIhkZodHRwOi8v Y3JsLmNvbW9kb2NhLmNvbS9DT01PRE9DbGllbnRBdXRoZW50aWNhdGlvbmFuZFNlY3VyZUVt YWlsQ0EuY3JsMIGIBggrBgEFBQcBAQR8MHowUgYIKwYBBQUHMAKGRmh0dHA6Ly9jcnQuY29t b2RvY2EuY29tL0NPTU9ET0NsaWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5j cnQwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmNvbW9kb2NhLmNvbTAmBgNVHREEHzAdgRty b2JlcnQuY3JhZ2llQGdyaWRtZXJnZS5jb20wDQYJKoZIhvcNAQEFBQADggEBAD6b/O0LkPav kR4Znoqxg0Ad7M3duDm4uzfrlX4ecgq56Ccdwd+3Tayz7Ewej30woVMmTKkA/NKRaCd0wVM9 8seF/oZjXKO7o1SH27igRnGSWjCoWXsdwJGfZbYnvcIIhhsxJoCPNbeSR7C0PAFDKsP3xrJy MHMljIJsoRbZu/fnYNyFWh9OXf7fYJOGmKDKAhSabUGfhY7umvU9d/YTqo02Q6YzC7d4zPNG 1a75AuHSEchf6GdKqycG38I5y9jlDaYfXspoS3PlTNCIeZONbOSMZgftnNEVKq+SWytFqyG/ 8+dwpm/a12KMex5J8iHwaUKj++2O2rAFNjDDqXpeEYoxggQZMIIEFQIBATCBqDCBkzELMAkG A1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9y ZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENPTU9ETyBDbGllbnQg QXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIQXDFQ28QtqMuYch5f2nTvZjAJ BgUrDgMCGgUAoIICRTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xMjExMDEwODMwMzFaMCMGCSqGSIb3DQEJBDEWBBTSl1nIPTRKgNyoB2gl8DFqcjkgcTBs BgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcw DgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEo MIG5BgkrBgEEAYI3EAQxgaswgagwgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVy IE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1p dGVkMTkwNwYDVQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUg RW1haWwgQ0ECEFwxUNvELajLmHIeX9p072YwgbsGCyqGSIb3DQEJEAILMYGroIGoMIGTMQsw CQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxm b3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVu dCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhBcMVDbxC2oy5hyHl/adO9m MA0GCSqGSIb3DQEBAQUABIIBACX2Pz8L2dO2w4/EZmDBaibLMDXArujD2fZQN0W9vHb3EX81 DhEq6BP9IeqxlWEW/6oTZSug1Acr9S0JCJ5na1ET6nHltTeZ3d6ckXzZ6Vi7l0ykkWenPzaF Wz+M2QZBctlwzpMC1YjvvvC2FBel6tWH9kzkQ4aO1VMkn0fvf7uufm6ly95O9uOcTs0kQ/6c a5njROET+HmhX3ADIPlHj2ydbDVl6VEaCU0OgHZ39wWnTmGl6zzu4dAi5Re9Wy4nlUFzu8hr 8z9IvWNp2UIJjs6ZGF8GEmBJ4slo5a/0QWY6ZHe1xBo6i+Pmi6RLDO5cdLIJMnhIc95AkUd5 e1bbX8wAAAAAAAA= --------------ms070205090006030402030604-- From esko.dijk@philips.com Thu Nov 1 05:26:28 2012 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 150E121F8957 for ; Thu, 1 Nov 2012 05:26:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.021 X-Spam-Level: X-Spam-Status: No, score=-3.021 tagged_above=-999 required=5 tests=[AWL=0.577, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VEkpHMdG+vsw for ; Thu, 1 Nov 2012 05:26:22 -0700 (PDT) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe002.messaging.microsoft.com [216.32.181.182]) by ietfa.amsl.com (Postfix) with ESMTP id 26D7921F89D9 for ; Thu, 1 Nov 2012 05:26:22 -0700 (PDT) Received: from mail202-ch1-R.bigfish.com (10.43.68.253) by CH1EHSOBE008.bigfish.com (10.43.70.58) with Microsoft SMTP Server id 14.1.225.23; Thu, 1 Nov 2012 12:26:21 +0000 Received: from mail202-ch1 (localhost [127.0.0.1]) by mail202-ch1-R.bigfish.com (Postfix) with ESMTP id 0C92060185; Thu, 1 Nov 2012 12:26:21 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.55.7.222; KIP:(null); UIP:(null); IPV:NLI; H:mail.philips.com; RD:none; EFVD:NLI X-SpamScore: -41 X-BigFish: VPS-41(zzbb2dI217bI98dI15d6O9371I9251J1431J1503M936eIc85fhzz1202h1d1ah1d2ahzz8275ch1033IL8275dhz2dh2a8h668h839hd25hf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh1155h) Received: from mail202-ch1 (localhost.localdomain [127.0.0.1]) by mail202-ch1 (MessageSwitch) id 1351772779755_21286; Thu, 1 Nov 2012 12:26:18 +0000 (UTC) Received: from CH1EHSMHS013.bigfish.com (snatpool2.int.messaging.microsoft.com [10.43.68.230]) by mail202-ch1.bigfish.com (Postfix) with ESMTP id E8A0E22009D; Thu, 1 Nov 2012 12:26:18 +0000 (UTC) Received: from mail.philips.com (157.55.7.222) by CH1EHSMHS013.bigfish.com (10.43.70.13) with Microsoft SMTP Server (TLS) id 14.1.225.23; Thu, 1 Nov 2012 12:26:18 +0000 Received: from 011-DB3MMR1-021.MGDPHG.emi.philips.com (10.128.28.103) by 011-DB3MMR1-008.MGDPHG.emi.philips.com (10.128.28.47) with Microsoft SMTP Server (TLS) id 14.2.309.3; Thu, 1 Nov 2012 12:26:16 +0000 Received: from 011-DB3MPN2-082.MGDPHG.emi.philips.com ([169.254.2.20]) by 011-DB3MMR1-021.MGDPHG.emi.philips.com ([fe80::f066:9203:e7da:3658%11]) with mapi id 14.02.0309.003; Thu, 1 Nov 2012 12:26:16 +0000 From: "Dijk, Esko" To: "robert.cragie@gridmerge.com" , "roll@ietf.org" Thread-Topic: [Roll] WG Last Call draft-ietf-roll-trickle-mcast-02 Thread-Index: AQHNtsPsdFvNKLXuoEuAu7nQQjDukZfTPqUAgABC3ACAAI4SgIAAmTSAgAA+jgA= Date: Thu, 1 Nov 2012 12:26:16 +0000 Message-ID: <031DD135F9160444ABBE3B0C36CED618B09BA5@011-DB3MPN2-082.MGDPHG.emi.philips.com> References: <5091B2A3.1090205@exegin.com> <50923327.1090500@gridmerge.com> In-Reply-To: <50923327.1090500@gridmerge.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [194.171.252.103] Content-Type: multipart/alternative; boundary="_000_031DD135F9160444ABBE3B0C36CED618B09BA5011DB3MPN2082MGDP_" MIME-Version: 1.0 X-OriginatorOrg: philips.com Subject: Re: [Roll] WG Last Call draft-ietf-roll-trickle-mcast-02 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Nov 2012 12:26:28 -0000 --_000_031DD135F9160444ABBE3B0C36CED618B09BA5011DB3MPN2082MGDP_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Robert, these are very useful diagrams. I just wanted to point out for page 6, "Si= te local multicast originating externally", that there is probably also con= figuration required (in the BR) of what multicast traffic is allowed by the= BR onto the LLN. I assume that not all multicast traffic from the high-sp= eed backbone network should be forwarded onto the LLN into the MPL domain a= s that could lead to congestion? As a side note, this configuration would not be needed if we would have an= equivalent of the MLD protocol , to let LLN nodes announce their interest = in specific multicast groups. One specific solution (in case the BR is als= o an RPL DODAG root) is for nodes to use standard RPL DAOs containing multi= cast addresses of interest, to advertize the multicast groups of interest t= o the BR which can then automatically set up the 'filtering rules'. But thi= s is probably beyond the current MPL spec ;-) regards, Esko From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Rob= ert Cragie Sent: Thursday 1 November 2012 9:31 To: roll@ietf.org Subject: Re: [Roll] WG Last Call draft-ietf-roll-trickle-mcast-02 Hi Dario, Some comments inline. I have also attached some diagrams which hopefully he= lp to illustrate some of the thought processes we went through when impleme= nting and testing between the ZigBee IP vendors (comments welcome). Apologi= es in advance for the PDF format but ASCII art would have been difficult :-= ) Robert On 31/10/2012 11:22 PM, Dario Tedeschi wrote: Yes, I'd like to try clarify why link-local scope was suggested for the *ou= ter* header. The reasons were: 1. Link-local scope is the only scope where the boundaries are well defi= ned (i.e. on the link). Higher scopes are not well-defined and can cover wi= de domains depending on network configuration and administration. I agree and made essentially the same comment re. higher scopes. 1. With a higher scope, there is a chance that non-MPL aware routers may= simply forward encapsulated multicast datagrams (MPL HbH option and all). = We wouldn't want MPL datagrams to leak outside of an MPL domain. Which is why I think the encapsulation rules do need to be pretty spec= ific. If link-local encapsulation is always used then providing the MPL for= warder rules are clear, the MPL domain is then entirely bounded by the MPL = forwarders and there is no question regarding address scope and administrat= ion thereof. This cleanly covers Peter's case as well where he wants to for= ward into another PAN - it would be processed internally as an original non= -MPL packet and then be "launched" into the other PAN using LL encapsulatio= n for that PAN. Using other scopes for the outer header would still work bu= t then there is the issue of administering the scope. However, this would n= eed to be done in the case where no encapsulation is done anyway. 1. A higher scope complicates the forwarding logic that needs to be impl= emented in an MPL router. The complication comes when a router receives an = MPL datagram and needs to figure out whether to decapsulate or not. Granted= , the use of an MPL group would mitigate this problem to a degree, but link= -local scope would make the decision to decapsulate very obvious and simple= . I think it would have to be effectively decapsulated at every router a= nyway irrespective of the scope of the outer header to see if it needs to b= e processed - it is the inner header which counts there and the comments ab= out multicast groups come into play in that discussion. But I agree using l= ink-local makes that decision easy and somewhat clearer 1. In conjunction with 3. Link-local scope also makes it easier for an M= PL router to determine if the inner multicast address is one that a higher = layer (or an app) may be interested in. Agree that the rules are clearer for link-local 1. Hopefully I haven't made things more confusing. Perish the thought ;-) - Dario On 31/10/2012 7:53 AM, Jonathan Hui (johui) wrote: Hi Peter, The current draft does not place any restrictions on the MPL multicast scop= e. If the LLN border router is an MPL forwarder, it can forward MPL multicast = packets between different MPL multicast scope zones. To be explicit, if th= e original multicast packet's destination address has link-local scope, the= MPL forwarder should not forward the packet again. If the original multic= ast packet's destination has a scope larger than the MPL multicast scope, t= hen the MPL forwarder needs to forward the packet to other MPL multicast sc= ope zones (which may or may not involve different interfaces). Does that address your question? -- Jonathan Hui On Oct 31, 2012, at 3:54 AM, peter van der Stok wrote: Hi Jonathan, To be absolutely sure: the MPL multicast scope can be link-local, ULA or si= te-local? meaning the LLN border router can be a MPL forwarder? In the latter case the LLN border router can forward link-local multicast f= rom one interface to another? Greetings, peter Jonathan Hui (johui) schreef op 2012-10-30 18:27: Yes, a goal of the current draft is to support both cases (use of IPv6-in-IPv6 encapsulation or not). The intent is as follows: 1) If the source of the multicast packet is within the MPL forwarding domain and the destination has a scope equal to or smaller than the MPL multicast scope, then no IPv6-in-IPv6 encapsulation is required. 2) If the source of the multicast packet is outside the MPL forwarding domain or the destination has scope greater than the MPL multicast scope, then IPv6-in-IPv6 encapsulation is required. When using IPv6-in-IPv6 encapsulation, then the all MPL forwarders multicast address with scope =3D MPL multicast scope is used as the destination address in the outer header. As mentioned in my other email, IPv6-in-IPv6 encapsulation is required if you want to use the IPv6 Destination Address to identify MPL forwarding scope zones. Of course, this brings up Dario's practical point of how to configure the MPL multicast scope if we allow that to dynamically change. He proposes a simplifying suggestion of requiring IPv6-in-IPv6 encapsulation for all non-link-local multicasts. In other words, setting the MPL multicast scope to link-local. Thoughts? -- Jonathan Hui On Oct 30, 2012, at 4:46 AM, Don Sturek wrote: Hi Peter, I still need to read the latest draft so take what I say here with that in mind...... I was hoping that we could support not using IP in IP tunneling if the scope of the multicast transmission was only within the multi-link subnet managed by the border router. I was hoping that only transmission emanating from outside the multi-link subnet, received at the border router, with scope that includes the devices in the multi-link subnet would require IP in IP tunneling (and vice versa in terms of multicasts generated in the multi-link subnet with scope outside). I haven't yet read the draft carefully to know if this is possible. Don On 10/30/12 1:34 AM, "peter van der Stok" wrote: Hi Don, and more specifically under which conditions. That gives the possibility to choose the conditions such that the encapsulation is not needed. Don Sturek schreef op 2012-10-29 16:56: Hi Peter, I think your suggested changes to the Trickle Multicast draft point out why IP in IP tunneling is needed. Don On 10/29/12 3:44 AM, "peter van der Stok" wrote: Dear WG, Attached my suggestions for text modifications including some nits. I used the facilities of word to edit and comment text with traces. When writing text about MC scope and MC domain, I was puzzled by the all MPL forwarders multicast address which removes the possibility to address a given multicast group. We expect multiple (possibly disjunct) MC groups in our wireless networks. Also I failed to understand why encapsulation was necessary once the message was received by the seed. To make it possible to configure the interface with one MC scope I added the possibility to use Unicast-Prefix-based IPv6 Multicast Addresses (RFC 3306). Probably, I overlooked many aspects which make the suggestions impractical, but I hope that the intention is clear. Peter van der Stok Michael Richardson schreef op 2012-10-25 23:30: I suggest that you propose specific text to the list to modify the document. _______________________________________________ Roll mailing 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 ________________________________ The information contained in this message may be confidential and legally p= rotected under applicable law. The message is intended solely for the addre= ssee(s). If you are not the intended recipient, you are hereby notified tha= t any use, forwarding, dissemination, or reproduction of this message is st= rictly prohibited and may be unlawful. If you are not the intended recipien= t, please contact the sender by return e-mail and destroy all copies of the= original message. --_000_031DD135F9160444ABBE3B0C36CED618B09BA5011DB3MPN2082MGDP_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Robert,

 

these are very useful d= iagrams.  I just wanted to point out for page 6, “Site local mul= ticast originating externally”, that there is probably also configura= tion required (in the BR) of what multicast traffic is allowed by the BR onto t= he LLN.  I assume that not all multicast traffic from the high-speed b= ackbone network should be forwarded onto the LLN into the MPL domain as tha= t could lead to congestion?

 

As  a side note, t= his configuration would not be needed if we would have an equivalent of the= MLD protocol , to let LLN nodes announce their interest in specific multicast groups.  One specific solution (in case the BR is also an R= PL DODAG root) is for nodes to use standard RPL DAOs containing multicast a= ddresses of interest, to advertize the multicast groups of interest to the = BR which can then automatically set up the ‘filtering rules’. But this is probably beyond the current= MPL spec ;-)

 

regards,

Esko

 

From: roll-bounces@ietf.org [mailto:roll-bounces@ie= tf.org] On Behalf Of Robert Cragie
Sent: Thursday 1 November 2012 9:31
To: roll@ietf.org
Subject: Re: [Roll] WG Last Call draft-ietf-roll-trickle-mcast-02

 

Hi Dario,

Some comments inline. I have also attached some diagrams which hopefully he= lp to illustrate some of the thought processes we went through when impleme= nting and testing between the ZigBee IP vendors (comments welcome). Apologi= es in advance for the PDF format but ASCII art would have been difficult :-)

Robert

On 31/10/2012 11:22 PM, Dario Tedeschi wrote:

Yes, I'd like to try clarify why link-local scope wa= s suggested for the *outer* header. The reasons were:

  1. Link-local scope is the only scope where= the boundaries are well defined (i.e. on the link). Higher scopes are not = well-defined and can cover wide domains depending on network configuration = and administration.

<RCC>I agree and made essentially the same com= ment re. higher scopes.</RCC>

  1. With a higher scope, there is a chance t= hat non-MPL aware routers may simply forward encapsulated multicast datagra= ms (MPL HbH option and all). We wouldn't want MPL datagrams to leak outside= of an MPL domain.

<RCC>Which is why I think the encapsulation ru= les do need to be pretty specific. If link-local encapsulation is always us= ed then providing the MPL forwarder rules are clear, the MPL domain is then= entirely bounded by the MPL forwarders and there is no question regarding address scope and administration thereo= f. This cleanly covers Peter's case as well where he wants to forward into = another PAN - it would be processed internally as an original non-MPL packe= t and then be "launched" into the other PAN using LL encapsulation for that PAN. Using other scopes for the = outer header would still work but then there is the issue of administering = the scope. However, this would need to be done in the case where no encapsu= lation is done anyway.</RCC>

  1. A higher scope complicates the forwardin= g logic that needs to be implemented in an MPL router. The complication com= es when a router receives an MPL datagram and needs to figure out whether t= o decapsulate or not. Granted, the use of an MPL group would mitigate this problem to a degree, but link-local sc= ope would make the decision to decapsulate very obvious and simple.

    2. <RCC>I think it would have to be effectively d= ecapsulated at every router anyway irrespective of the scope of the outer h= eader to see if it needs to be processed - it is the inner header which cou= nts there and the comments about multicast groups come into play in that discussion. But I agree using link-local mak= es that decision easy and somewhat clearer</RCC>

    1. In conjunction with 3. Link-local scope = also makes it easier for an MPL router to determine if the inner multicast = address is one that a higher layer (or an app) may be interested in.

      2. <RCC>Agree that the rules are clearer for link= -local</RCC>

      1.  

      Hopefully I haven't made things more confusing.


      <RCC>Perish the thought ;-)</RCC>


      - Dario

      On 31/10/2012 7:53 AM, Jonathan Hui (johui) wrote: 

      Hi Peter,
       
      The current draft does not place any restrictions on the MPL multicast=
 scope.
       
      If the LLN border router is an MPL forwarder, it can forward MPL multi=
cast packets between different MPL multicast scope zones.  To be expli=
cit, if the original multicast packet's destination address has link-local =
scope, the MPL forwarder should not forward the packet again.  If the =
original multicast packet's destination has a scope larger than the MPL mul=
ticast scope, then the MPL forwarder needs to forward the packet to other M=
PL multicast scope zones (which may or may not involve different interfaces=
).
       
      Does that address your question?
       
      --
      Jonathan Hui
       
      On Oct 31, 2012, at 3:54 AM, peter van der Stok <stokcons@xs4all.nl> wrote:
       
      Hi Jonathan,
       
      To be absolutely sure: the MPL multicast scope can be link-local, ULA =
or site-local? meaning the LLN border router can be a MPL forwarder?
      In the latter case the LLN border router can forward link-local multic=
ast from one interface to another?
       
      Greetings,
       
      peter
       
      Jonathan Hui (johui) schreef op 2012-10-30 18:27:
      Yes, a goal of the current draft is to support both cases (use of

      IPv6-in-IPv6 encapsulation or not).
      

       
      

      The intent is as follows:
      

      1) If the source of the multicast packet is within the MPL forwarding<=
/pre>

      domain and the destination has a scope equal to or smaller than the

      MPL multicast scope, then no IPv6-in-IPv6 encapsulation is required.

      2) If the source of the multicast packet is outside the MPL
      

      forwarding domain or the destination has scope greater than the MPL

      multicast scope, then IPv6-in-IPv6 encapsulation is required.  Wh=
en
      

      using IPv6-in-IPv6 encapsulation, then the all MPL forwarders
      

      multicast address with scope =3D MPL multicast scope is used as the

      destination address in the outer header.
      

       
      

      As mentioned in my other email, IPv6-in-IPv6 encapsulation is
      

      required if you want to use the IPv6 Destination Address to identify

      MPL forwarding scope zones.
      

       
      

      Of course, this brings up Dario's practical point of how to configure<=
/pre>

      the MPL multicast scope if we allow that to dynamically change.  =
He
      

      proposes a simplifying suggestion of requiring IPv6-in-IPv6
      

      encapsulation for all non-link-local multicasts.  In other words,=

      

      setting the MPL multicast scope to link-local.
      

       
      

      Thoughts?
      

       
      

      --
      

      Jonathan Hui
      

       
      

      On Oct 30, 2012, at 4:46 AM, Don Sturek <d.sturek@att.net> wrote:
      

       
      

      

      Hi Peter,
      

       
      

      I still need to read the latest draft so take what I say here with tha=
t in
      

      mind......
      

       
      

      I was hoping that we could support not using IP in IP tunneling if the=

      

      scope of the multicast transmission was only within the multi-link sub=
net
      

      managed by the border router.   I was hoping that only trans=
mission
      

      emanating from outside the multi-link subnet, received at the border

      router, with scope that includes the devices in the multi-link subnet<=
/pre>

      would require IP in IP tunneling (and vice versa in terms of multicast=
s
      

      generated in the multi-link subnet with scope outside).  I haven'=
t yet
      

      read the draft carefully to know if this is possible.
      

       
      

      Don
      

       
      

       
      

      On 10/30/12 1:34 AM, "peter van der Stok" <stokcons@xs4all.nl> wrote:
      

       
      

      

      Hi Don,
      

       
      

      and more specifically under which conditions. That gives the
      

      possibility to choose the conditions such that the encapsulation is no=
t
      

      needed.
      

       
      

      Don Sturek schreef op 2012-10-29 16:56:
      

      

      Hi Peter,
      

       
      

      I think your suggested changes to the Trickle Multicast draft point

      out
      

      why IP in IP tunneling is needed.
      

       
      

      Don
      

       
      

       
      

       
      

      On 10/29/12 3:44 AM, "peter van der Stok" <stokcons@xs4all.nl> wrote:
      

       
      

      

      Dear WG,
      

       
      

       
      

      Attached my suggestions for text modifications including some nits. I<=
/pre>

      used the facilities of word to edit and comment text with traces.

       
      

      When writing text about MC scope and MC domain, I was puzzled by the

      all MPL forwarders multicast address which removes the possibility to<=
/pre>

      address a given multicast group. We expect multiple (possibly
      

      disjunct)
      

      MC groups in our wireless networks.
      

      Also I failed to understand why encapsulation was necessary once the

      message was received by the seed.
      

      To make it possible to configure the interface with one MC scope I

      added the possibility to use Unicast-Prefix-based IPv6 Multicast
      

      Addresses (RFC 3306).
      

       
      

       
      

      Probably, I overlooked many aspects which make the suggestions
      

      impractical, but I hope that the intention is clear.
      

       
      

      Peter van der Stok
      

       
      

      Michael Richardson schreef op 2012-10-25 23:30:
      

      

      I suggest that you propose specific text to the list to modify the

      document.
      

      

      _______________________________________________
      

      Roll mailing list
      

      Roll@ietf.org
      

      https://www.iet=
f.org/mailman/listinfo/roll
      

      

      

      

       
      

      _______________________________________________
      

      Roll mailing list
      

      Roll@ietf.org
      

      https://www.iet=
f.org/mailman/listinfo/roll
      

      

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





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

       


The information contained in= this message may be confidential and legally protected under applicable la= w. The message is intended solely for the addressee(s). If you are not the = intended recipient, you are hereby notified that any use, forwarding, dissemination, or reproduction of this message i= s strictly prohibited and may be unlawful. If you are not the intended reci= pient, please contact the sender by return e-mail and destroy all copies of= the original message.
 --_000_031DD135F9160444ABBE3B0C36CED618B09BA5011DB3MPN2082MGDP_-- From esko.dijk@philips.com Thu Nov 1 05:46:25 2012 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4EDAD21F8CCB for ; Thu, 1 Nov 2012 05:46:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.409 X-Spam-Level: X-Spam-Status: No, score=-2.409 tagged_above=-999 required=5 tests=[AWL=-0.420, BAYES_00=-2.599, MANGLED_TOOL=2.3, RCVD_IN_DNSWL_MED=-4, SARE_URGBIZ=0.725, URG_BIZ=1.585] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nDANJL3CVNkN for ; Thu, 1 Nov 2012 05:46:24 -0700 (PDT) Received: from tx2outboundpool.messaging.microsoft.com (tx2ehsobe003.messaging.microsoft.com [65.55.88.13]) by ietfa.amsl.com (Postfix) with ESMTP id 6DF6121F8C9B for ; Thu, 1 Nov 2012 05:46:24 -0700 (PDT) Received: from mail151-tx2-R.bigfish.com (10.9.14.254) by TX2EHSOBE008.bigfish.com (10.9.40.28) with Microsoft SMTP Server id 14.1.225.23; Thu, 1 Nov 2012 12:46:23 +0000 Received: from mail151-tx2 (localhost [127.0.0.1]) by mail151-tx2-R.bigfish.com (Postfix) with ESMTP id C12AA340137; Thu, 1 Nov 2012 12:46:23 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.55.7.222; KIP:(null); UIP:(null); IPV:NLI; H:mail.philips.com; RD:none; EFVD:NLI X-SpamScore: -37 X-BigFish: VPS-37(zz217bI98dI15d6O9371I9251Jd6eah542Mzz1202h1d1ah1d2ahzz1033IL8275bh8275dhz2dh2a8h668h839h944hd25hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh1155h) Received: from mail151-tx2 (localhost.localdomain [127.0.0.1]) by mail151-tx2 (MessageSwitch) id 1351773981588752_29552; Thu, 1 Nov 2012 12:46:21 +0000 (UTC) Received: from TX2EHSMHS001.bigfish.com (unknown [10.9.14.247]) by mail151-tx2.bigfish.com (Postfix) with ESMTP id 806C64E0072; Thu, 1 Nov 2012 12:46:21 +0000 (UTC) Received: from mail.philips.com (157.55.7.222) by TX2EHSMHS001.bigfish.com (10.9.99.101) with Microsoft SMTP Server (TLS) id 14.1.225.23; Thu, 1 Nov 2012 12:46:18 +0000 Received: from 011-DB3MPN2-082.MGDPHG.emi.philips.com ([169.254.2.20]) by 011-DB3MMR1-009.MGDPHG.emi.philips.com ([10.128.28.48]) with mapi id 14.02.0309.003; Thu, 1 Nov 2012 12:45:48 +0000 From: "Dijk, Esko" To: "Jonathan Hui (johui)" Thread-Topic: [Roll] I-D Action: draft-ietf-roll-trickle-mcast-02.txt Thread-Index: AQHNrh4EBfIsegKOz0GvSDMMHJeV6pfA4wQAgBKnvHCAAB/ZAIAAD7sg Date: Thu, 1 Nov 2012 12:45:48 +0000 Message-ID: <031DD135F9160444ABBE3B0C36CED618B09BFA@011-DB3MPN2-082.MGDPHG.emi.philips.com> References: <20121019171938.9893.94358.idtracker@ietfa.amsl.com> <031DD135F9160444ABBE3B0C36CED618B09936@011-DB3MPN2-082.MGDPHG.emi.philips.com> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [194.171.252.103] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: philips.com Cc: "roll@ietf.org WG" Subject: Re: [Roll] I-D Action: draft-ietf-roll-trickle-mcast-02.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Nov 2012 12:46:25 -0000 Hi, > the Option Type to '01', which indicates the receiver must drop the packe= t My mistake - I had the version -00 draft opened, hence looking at '00' bits= . There's still the case that multicasts from non-MPL nodes are received by M= PL-forwarder-nodes (presumably). Should there be guidelines here? Example: = if an application on my MPL-forwarder node joins multicast group FF05::1234= , will the application then receive IP multicasts sent with destination FF0= 5::1234, or will it only receive those IP multicasts to FF05::1234 that wer= e delivered encapsulated in an FF0X::MPL packet ? That decision could be out of scope; but on the other hand may lead to diff= erent implementers making different choices here. Esko -----Original Message----- From: Jonathan Hui (johui) [mailto:johui@cisco.com] Sent: Wednesday 31 October 2012 17:19 To: Dijk, Esko Cc: roll@ietf.org WG Subject: Re: [Roll] I-D Action: draft-ietf-roll-trickle-mcast-02.txt Hi Esko, On Oct 31, 2012, at 8:37 AM, "Dijk, Esko" wrote: > 1. Selection of the link-local all-nodes MPL forwarders multicast address= . > When IPv6-in-IPv6 encapsulation is applied, the "all-MPL-forwarders" MC a= ddress will be used a lot. A typical use case of MPL is in 6LoWPAN networks= . It has best header compression of link-local IP multicast destination add= ress when the multicast Group ID is in the range 0x00-0xFF. Therefore we sh= ould put in the IANA allocation request (and in the IANA section in the I-D= too) that we urgently request an allocation in this range. Going outside t= his range to Group IP 0x100 and up, will incur 4 bytes extra overhead. (An = example of a successful earlier registration in the 00-FF range is mDNS FF0= X::FB). Agree. Will include in the next revision. > 2. Warn against mixing MPL-forwarders with non-MPL-nodes in the same LLN. > Mixing MPL-forwarders with non-MPL-nodes (that e.g. listen to specific mu= lticast traffic) may lead to unpredictable behavior. For example, an MPL no= de N1 application sends to FF05::1234, and a non-MPL neighbor node N2 liste= ns to FF05::1234. If MPL does use encapsulation, then node N2 will never re= ceive the packet from N1 (because N1 will send to either FF02::MPL or FF05:= :MPL). If MPL happens to not use encapsulation, node N2 will receive the pa= cket from N1. > So depending on the encapsulation decision different nodes may get/not ge= t the packet - is this intentional? > If not we should warn for this situation, perhaps? In both cases, the MPL multicast packet must contain the MPL Option. The c= urrent draft sets the highest-order bits in the Option Type to '01', which = indicates the receiver must drop the packet if it does not understand the M= PL Option. So non-MPL-nodes should not receive MPL Multicast packets. > 3. Motivation for requiring encapsulation: MPL vs RPL > " IPv6-in-IPv6 > encapsulation also allows an MPL forwarder to remove the MPL Option > when forwarding the original multicast packet over a link that does > not support MPL." > It seems RPL does not use IPv6-in-IPv6 encapsulation but just states that= the RPL router can remove the HbH option. (RFC 6550 Section 11.2.2.1, "A r= outer that forwards a packet outside the RPL network MUST remove the RPL Pa= cket Information.") Is there a reason that MPL cannot do it the RPL way? RFC 6553, which specifies the RPL Option, requires the use of IPv6-in-IPv6 = encapsulation, unless the source and destination are known to be within the= same RPL Instance. -- Jonathan Hui ________________________________ The information contained in this message may be confidential and legally p= rotected under applicable law. The message is intended solely for the addre= ssee(s). If you are not the intended recipient, you are hereby notified tha= t any use, forwarding, dissemination, or reproduction of this message is st= rictly prohibited and may be unlawful. If you are not the intended recipien= t, please contact the sender by return e-mail and destroy all copies of the= original message. From robert.cragie@gridmerge.com Thu Nov 1 05:47:26 2012 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CABB21F87DF for ; Thu, 1 Nov 2012 05:47:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.355 X-Spam-Level: X-Spam-Status: No, score=-1.355 tagged_above=-999 required=5 tests=[AWL=1.243, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LOlA7ZZ6n1zL for ; Thu, 1 Nov 2012 05:47:22 -0700 (PDT) Received: from mail78.extendcp.co.uk (mail78.extendcp.co.uk [79.170.40.78]) by ietfa.amsl.com (Postfix) with ESMTP id 7B52B21F8CF4 for ; Thu, 1 Nov 2012 05:47:20 -0700 (PDT) Received: from client-86-29-60-219.glfd.adsl.virginmedia.com ([86.29.60.219] helo=[192.168.0.2]) by mail78.extendcp.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.77) id 1TTuAx-0001uc-Jx; Thu, 01 Nov 2012 12:47:13 +0000 Message-ID: <50926F96.6050107@gridmerge.com> Date: Thu, 01 Nov 2012 12:48:22 +0000 From: Robert Cragie Organization: Gridmerge Ltd. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: "Dijk, Esko" References: <5091B2A3.1090205@exegin.com> <50923327.1090500@gridmerge.com> <031DD135F9160444ABBE3B0C36CED618B09BA5@011-DB3MPN2-082.MGDPHG.emi.philips.com> In-Reply-To: <031DD135F9160444ABBE3B0C36CED618B09BA5@011-DB3MPN2-082.MGDPHG.emi.philips.com> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms070807070609050103000707" X-Authenticated-As: robert.cragie@gridmerge.com Cc: "roll@ietf.org" Subject: Re: [Roll] WG Last Call draft-ietf-roll-trickle-mcast-02 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: robert.cragie@gridmerge.com List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Nov 2012 12:47:26 -0000 This is a cryptographically signed message in MIME format. --------------ms070807070609050103000707 Content-Type: multipart/mixed; boundary="------------070407090800060502080406" This is a multi-part message in MIME format. --------------070407090800060502080406 Content-Type: multipart/alternative; boundary="------------060001080505080303040403" --------------060001080505080303040403 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Hi Esko, Good point about multicast forwarding policy at the BR. I have redone=20 the diagrams slightly to make a couple of corrections and include the=20 note about multicast forwarding policy at the BR. Robert On 01/11/2012 12:26 PM, Dijk, Esko wrote: > > Hi Robert, > > these are very useful diagrams. I just wanted to point out for page=20 > 6, "Site local multicast originating externally", that there is=20 > probably also configuration required (in the BR) of what multicast=20 > traffic is allowed by the BR onto the LLN. I assume that not all=20 > multicast traffic from the high-speed backbone network should be=20 > forwarded onto the LLN into the MPL domain as that could lead to=20 > congestion? > > As a side note, this configuration would not be needed if we would=20 > have an equivalent of the MLD protocol , to let LLN nodes announce=20 > their interest in specific multicast groups. One specific solution=20 > (in case the BR is also an RPL DODAG root) is for nodes to use=20 > standard RPL DAOs containing multicast addresses of interest, to=20 > advertize the multicast groups of interest to the BR which can then=20 > automatically set up the 'filtering rules'. But this is probably=20 > beyond the current MPL spec ;-) > > regards, > > Esko > > *From:*roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] *On Behalf = > Of *Robert Cragie > *Sent:* Thursday 1 November 2012 9:31 > *To:* roll@ietf.org > *Subject:* Re: [Roll] WG Last Call draft-ietf-roll-trickle-mcast-02 > > Hi Dario, > > Some comments inline. I have also attached some diagrams which=20 > hopefully help to illustrate some of the thought processes we went=20 > through when implementing and testing between the ZigBee IP vendors=20 > (comments welcome). Apologies in advance for the PDF format but ASCII=20 > art would have been difficult :-) > > Robert > > On 31/10/2012 11:22 PM, Dario Tedeschi wrote: > > Yes, I'd like to try clarify why link-local scope was suggested > for the *outer* header. The reasons were: > > 1. Link-local scope is the only scope where the boundaries are > well defined (i.e. on the link). Higher scopes are not > well-defined and can cover wide domains depending on network > configuration and administration. > > I agree and made essentially the same comment re. higher=20 > scopes. > > 1. With a higher scope, there is a chance that non-MPL aware routers > may simply forward encapsulated multicast datagrams (MPL HbH > option and all). We wouldn't want MPL datagrams to leak outside of > an MPL domain. > > Which is why I think the encapsulation rules do need to be pretty = > specific. If link-local encapsulation is always used then providing=20 > the MPL forwarder rules are clear, the MPL domain is then entirely=20 > bounded by the MPL forwarders and there is no question regarding=20 > address scope and administration thereof. This cleanly covers Peter's=20 > case as well where he wants to forward into another PAN - it would be=20 > processed internally as an original non-MPL packet and then be=20 > "launched" into the other PAN using LL encapsulation for that PAN.=20 > Using other scopes for the outer header would still work but then=20 > there is the issue of administering the scope. However, this would=20 > need to be done in the case where no encapsulation is done anyway. > > 1. A higher scope complicates the forwarding logic that needs to be > implemented in an MPL router. The complication comes when a router > receives an MPL datagram and needs to figure out whether to > decapsulate or not. Granted, the use of an MPL group would > mitigate this problem to a degree, but link-local scope would make > the decision to decapsulate very obvious and simple. > > I think it would have to be effectively decapsulated at every=20 > router anyway irrespective of the scope of the outer header to see if=20 > it needs to be processed - it is the inner header which counts there=20 > and the comments about multicast groups come into play in that=20 > discussion. But I agree using link-local makes that decision easy and=20 > somewhat clearer > > 1. In conjunction with 3. Link-local scope also makes it easier for > an MPL router to determine if the inner multicast address is one > that a higher layer (or an app) may be interested in. > > Agree that the rules are clearer for link-local > > 1. > > Hopefully I haven't made things more confusing. > > > Perish the thought ;-) > > > - Dario > > On 31/10/2012 7:53 AM, Jonathan Hui (johui) wrote: > > Hi Peter, > =20 > The current draft does not place any restrictions on the MPL multicast = scope. > =20 > If the LLN border router is an MPL forwarder, it can forward MPL multic= ast packets between different MPL multicast scope zones. To be explicit,= if the original multicast packet's destination address has link-local sc= ope, the MPL forwarder should not forward the packet again. If the origi= nal multicast packet's destination has a scope larger than the MPL multic= ast scope, then the MPL forwarder needs to forward the packet to other MP= L multicast scope zones (which may or may not involve different interface= s). > =20 > Does that address your question? > =20 > -- > Jonathan Hui > =20 > On Oct 31, 2012, at 3:54 AM, peter van der Stok wrote: > =20 > > Hi Jonathan, > > =20 > > To be absolutely sure: the MPL multicast scope can be link-local, U= LA or site-local? meaning the LLN border router can be a MPL forwarder? > > In the latter case the LLN border router can forward link-local mul= ticast from one interface to another? > > =20 > > Greetings, > > =20 > > peter > > =20 > > Jonathan Hui (johui) schreef op 2012-10-30 18:27: > > Yes, a goal of the current draft is to support both cases (use = of > > IPv6-in-IPv6 encapsulation or not). > > =20 > > The intent is as follows: > > 1) If the source of the multicast packet is within the MPL forw= arding > > domain and the destination has a scope equal to or smaller than= the > > MPL multicast scope, then no IPv6-in-IPv6 encapsulation is requ= ired. > > 2) If the source of the multicast packet is outside the MPL > > forwarding domain or the destination has scope greater than the= MPL > > multicast scope, then IPv6-in-IPv6 encapsulation is required. = When > > using IPv6-in-IPv6 encapsulation, then the all MPL forwarders > > multicast address with scope =3D MPL multicast scope is used as= the > > destination address in the outer header. > > =20 > > As mentioned in my other email, IPv6-in-IPv6 encapsulation is > > required if you want to use the IPv6 Destination Address to ide= ntify > > MPL forwarding scope zones. > > =20 > > Of course, this brings up Dario's practical point of how to con= figure > > the MPL multicast scope if we allow that to dynamically change.= He > > proposes a simplifying suggestion of requiring IPv6-in-IPv6 > > encapsulation for all non-link-local multicasts. In other word= s, > > setting the MPL multicast scope to link-local. > > =20 > > Thoughts? > > =20 > > -- > > Jonathan Hui > > =20 > > On Oct 30, 2012, at 4:46 AM, Don Sturek wrote: > > =20 > > Hi Peter, > > =20 > > I still need to read the latest draft so take what I say he= re with that in > > mind...... > > =20 > > I was hoping that we could support not using IP in IP tunne= ling if the > > scope of the multicast transmission was only within the mul= ti-link subnet > > managed by the border router. I was hoping that only tran= smission > > emanating from outside the multi-link subnet, received at t= he border > > router, with scope that includes the devices in the multi-l= ink subnet > > would require IP in IP tunneling (and vice versa in terms o= f multicasts > > generated in the multi-link subnet with scope outside). I = haven't yet > > read the draft carefully to know if this is possible. > > =20 > > Don > > =20 > > =20 > > On 10/30/12 1:34 AM, "peter van der Stok" wrote: > > =20 > > Hi Don, > > =20 > > and more specifically under which conditions. That give= s the > > possibility to choose the conditions such that the enca= psulation is not > > needed. > > =20 > > Don Sturek schreef op 2012-10-29 16:56: > > Hi Peter, > > =20 > > I think your suggested changes to the Trickle Multi= cast draft point > > out > > why IP in IP tunneling is needed. > > =20 > > Don > > =20 > > =20 > > =20 > > On 10/29/12 3:44 AM, "peter van der Stok" wrote: > > =20 > > Dear WG, > > =20 > > =20 > > Attached my suggestions for text modifications = including some nits. I > > used the facilities of word to edit and comment= text with traces. > > =20 > > When writing text about MC scope and MC domain,= I was puzzled by the > > all MPL forwarders multicast address which remo= ves the possibility to > > address a given multicast group. We expect mult= iple (possibly > > disjunct) > > MC groups in our wireless networks. > > Also I failed to understand why encapsulation w= as necessary once the > > message was received by the seed. > > To make it possible to configure the interface = with one MC scope I > > added the possibility to use Unicast-Prefix-bas= ed IPv6 Multicast > > Addresses (RFC 3306). > > =20 > > =20 > > Probably, I overlooked many aspects which make = the suggestions > > impractical, but I hope that the intention is c= lear. > > =20 > > Peter van der Stok > > =20 > > Michael Richardson schreef op 2012-10-25 23:30:= > > I suggest that you propose specific text to= the list to modify the > > document. > > _______________________________________________= > > Roll mailing list > > Roll@ietf.org > > https://www.ietf.org/mailman/listinfo/roll > > =20 > > _______________________________________________ > > Roll mailing list > > Roll@ietf.org > > https://www.ietf.org/mailman/listinfo/roll > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > > > > > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > > > -----------------------------------------------------------------------= - > The information contained in this message may be confidential and=20 > legally protected under applicable law. The message is intended solely = > for the addressee(s). If you are not the intended recipient, you are=20 > hereby notified that any use, forwarding, dissemination, or=20 > reproduction of this message is strictly prohibited and may be=20 > unlawful. If you are not the intended recipient, please contact the=20 > sender by return e-mail and destroy all copies of the original message.= --------------060001080505080303040403 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Esko,

Good point about multicast forwarding policy at the BR. I have redone the diagrams slightly to make a couple of corrections and include the note about multicast forwarding policy at the BR.

Robert

On 01/11/2012 12:26 PM, Dijk, Esko wrote:

Hi Robert,

 

these are very useful diagrams.  I just wanted to point out for page 6, “Site local multicast originating externally”, that there is probably also configuration required (in the BR) of what multicast traffic is allowed by the BR onto the LLN.  I assume that not al= l multicast traffic from the high-speed backbone network should be forwarded onto the LLN into the MPL domain as that could lead to congestion?

 

As  a side note, this configuration would= not be needed if we would have an equivalent of the MLD protocol , to let LLN nodes announce their interest in specific multicast groups.  One specific solution (in case the BR= is also an RPL DODAG root) is for nodes to use standard RPL DAOs containing multicast addresses of interest, to advertize the multicast groups of interest to the BR which can then automatically set up the ‘filtering rules̵= 7;. But this is probably beyond the current MPL spec ;-)

 

regards,

Esko

 

From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Robert Cragie
Sent: Thursday 1 November 2012 9:31
To: roll@ietf.org
Subject: Re: [Roll] WG Last Call draft-ietf-roll-trickle-mcast-02

 

Hi Dario,
Some comments inline. I have also attached some diagrams which hopefully help to illustrate some of the thought processes we went through when implementing and testing between the ZigBee IP vendors (comments welcome). Apologies in advance for the PDF format but ASCII art would have been difficult :-)

Robert

On 31/10/2012 11:22 PM, Dario Tedeschi wrote:

Yes, I'd like to try clarify why link-local scope was suggested for the *outer* header. The reasons were:

  1. Link-local scope is the on= ly scope where the boundaries are well defined (i.e. on the link). Higher scopes are not well-defined and can cover wide domains depending on network configuration and administration.

<RCC>I agree and made essentially th= e same comment re. higher scopes.</RCC>

  1. With a higher scope, there i= s a chance that non-MPL aware routers may simply forward encapsulated multicast datagrams (MPL HbH option and all). We wouldn't want MPL datagrams to leak outside of an MPL domain.

<RCC>Which is why I think the encapsulation rules do need to be pretty specific. If link-local encapsulation is always used then providing the MPL forwarder rules are clear, the MPL domain is then entirely bounded by the MPL forwarders and there is no question regarding address scope and administration thereof. This cleanly covers Peter's case as well where he wants to forward into another PAN - it would be processed internally as an original non-MPL packet and then be "launched" into the other PAN using LL encapsulation for that PAN. Using other scopes for the outer header would still work but then there is the issue of administering the scope. However, this would need to be done in the case where no encapsulation is done anyway.</RCC>

  1. A higher scope complicates t= he forwarding logic that needs to be implemented in an MPL router. The complication comes when a router receives an MPL datagram and needs to figure out whether to decapsulate or not. Granted, the use of an MPL group would mitigate this problem to a degree, but link-local scope would make the decision to decapsulate very obvious and simple.

<RCC>I think it would have to be effectively decapsulated at every router anyway irrespective of the scope of the outer header to see if it needs to be processed - it is the inner header which counts there and the comments about multicast groups come into play in that discussion. But I agree using link-local makes that decision easy and somewhat clearer</RCC>

  1. In conjunction with 3. Link-local scope also makes it easier for an MPL router to determine if the inner multicast address is one that a higher layer (or an app) may be interested in.

<RCC>Agree that the rules are cleare= r for link-local</RCC>

  1.  

Hopefully I haven't made things more confusing.


<RCC>Perish the thought ;-)</RCC>


- Dario

On 31/10/2012 7:53 AM, Jonathan Hui (johui) wrote: 

Hi Peter,
 
The current draft does not place any restrictions on the MPL=
 multicast scope.
 
If the LLN border router is an MPL forwarder, it can forward=
 MPL multicast packets between different MPL multicast scope zones. =
 To be explicit, if the original multicast packet's destination address h=
as link-local scope, the MPL forwarder should not forward the packet agai=
n.  If the original multicast packet's destination has a scope large=
r than the MPL multicast scope, then the MPL forwarder needs to forward t=
he packet to other MPL multicast scope zones (which may or may not involv=
e different interfaces).
 
Does that address your question?
 
--
Jonathan Hui
 
On Oct 31, 2012, at 3:54 AM, peter van der Stok <stokcons@xs4all.nl=
> wrote:
 
Hi Jonathan,
 
To be absolutely sure: the MPL multicast scope can be link=
-local, ULA or site-local? meaning the LLN border router can be a MPL for=
warder?
In the latter case the LLN border router can forward link-=
local multicast from one interface to another?
 
Greetings,
 
peter
 
Jonathan Hui (johui) schreef op 2012-10-30 18:27:
Yes, a goal of the current draft is to support both case=
s (use of
IPv6-in-IPv6 encapsulation or not).
 
The intent is as follows:
1) If the source of the multicast packet is within the M=
PL forwarding
domain and the destination has a scope equal to or small=
er than the
MPL multicast scope, then no IPv6-in-IPv6 encapsulation =
is required.
2) If the source of the multicast packet is outside the =
MPL
forwarding domain or the destination has scope greater t=
han the MPL
multicast scope, then IPv6-in-IPv6 encapsulation is requ=
ired.  When
using IPv6-in-IPv6 encapsulation, then the all MPL forwa=
rders
multicast address with scope =3D MPL multicast scope is =
used as the
destination address in the outer header.
 
As mentioned in my other email, IPv6-in-IPv6 encapsulati=
on is
required if you want to use the IPv6 Destination Address=
 to identify
MPL forwarding scope zones.
 
Of course, this brings up Dario's practical point of how=
 to configure
the MPL multicast scope if we allow that to dynamically =
change.  He
proposes a simplifying suggestion of requiring IPv6-in-I=
Pv6
encapsulation for all non-link-local multicasts.  I=
n other words,
setting the MPL multicast scope to link-local.
 
Thoughts?
 
--
Jonathan Hui
 
On Oct 30, 2012, at 4:46 AM, Don Sturek <d.sturek@att.net>=
 wrote:
 
Hi Peter,
 
I still need to read the latest draft so take what I s=
ay here with that in
mind......
 
I was hoping that we could support not using IP in IP =
tunneling if the
scope of the multicast transmission was only within th=
e multi-link subnet
managed by the border router.   I was hoping=
 that only transmission
emanating from outside the multi-link subnet, received=
 at the border
router, with scope that includes the devices in the mu=
lti-link subnet
would require IP in IP tunneling (and vice versa in te=
rms of multicasts
generated in the multi-link subnet with scope outside)=
=2E  I haven't yet
read the draft carefully to know if this is possible.<=
/pre>
              
 

              
Don

              
 

              
 

              
On 10/30/12 1:34 AM, "peter van der Stok" <stokcons@xs4all.nl=
> wrote:

              
 

              

                
Hi Don,

                
 

                
and more specifically under which conditions. That g=
ives the

                
possibility to choose the conditions such that the e=
ncapsulation is not

                
needed.

                
 

                
Don Sturek schreef op 2012-10-29 16:56:

                

                  
Hi Peter,

                  
 

                  
I think your suggested changes to the Trickle Mult=
icast draft point

                  
out

                  
why IP in IP tunneling is needed.

                  
 

                  
Don

                  
 

                  
 

                  
 

                  
On 10/29/12 3:44 AM, "peter van der Stok" <stokcons@xs4al=
l.nl> wrote:

                  
 

                  

                    
Dear WG,

                    
 

                    
 

                    
Attached my suggestions for text modifications i=
ncluding some nits. I

                    
used the facilities of word to edit and comment =
text with traces.

                    
 

                    
When writing text about MC scope and MC domain, =
I was puzzled by the

                    
all MPL forwarders multicast address which remov=
es the possibility to

                    
address a given multicast group. We expect multi=
ple (possibly

                    
disjunct)

                    
MC groups in our wireless networks.

                    
Also I failed to understand why encapsulation wa=
s necessary once the

                    
message was received by the seed.

                    
To make it possible to configure the interface w=
ith one MC scope I

                    
added the possibility to use Unicast-Prefix-base=
d IPv6 Multicast

                    
Addresses (RFC 3306).

                    
 

                    
 

                    
Probably, I overlooked many aspects which make t=
he suggestions

                    
impractical, but I hope that the intention is cl=
ear.

                    
 

                    
Peter van der Stok

                    
 

                    
Michael Richardson schreef op 2012-10-25 23:30:<=
/pre>
                    

                      
I suggest that you propose specific text to th=
e list to modify the

                      
document.

                    

                    
_______________________________________________<=
/pre>
                    
Roll mailing list

                    
Roll@ietf.org

                    
https://www.ietf.org/mailman/listinfo/rol=
l

                  

                

              

              
 

              
_______________________________________________

              
Roll mailing list

              
Roll@ietf.org

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





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

 


The information cont= ained in this message may be confidential and legally protected under applicable law. The message is intended solely for the addressee(s). If you are not the intended recipient, you are hereby notified that any use, forwarding, dissemination, or reproduction of this message is strictly prohibited and may be unlawful. If you are not the intended recipient, please contact the sender by return e-mail and destroy all copies of the original message.

--------------060001080505080303040403-- --------------070407090800060502080406 Content-Type: application/pdf; name="HbHTunnelMcast_v7.pdf" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="HbHTunnelMcast_v7.pdf" JVBERi0xLjQKJcOkw7zDtsOfCjIgMCBvYmoKPDwvTGVuZ3RoIDMgMCBSL0ZpbHRlci9GbGF0 ZURlY29kZT4+CnN0cmVhbQp4nNUaXY/bNuxdv8LPBS7Tt2UgCJBr7wb0rdsBexj2tnVFcR6w vvTvjxIpW7RlJe2cYMOhiehQJMVPk6o8qO6r+LuTnYSVG9xBd8GqQ+i+/CF+edP9JVQX/778 KST8oLtRZCTdvdKGuPWVSMRv/O2T+PgGKcMf7H98Edbog+m8HmDTy+/dD89AGlYffz1KJfXp QcmjNKdwlBbXDr6O0ss+fYeTm34ZTvooz+nxIz55G5+8Oz3A7oz+oAnxKS1N2hzpDaffXt6L pxfxQaB4P/2YJP0K/97DaT8L48PBdX2vDunI3h8GguDQCLke1oRXrgnrk/gZyLeoXsafOY2i 5FrDDSGq1iJhdbCA6uDztbuHGLOJTdDgBb2XSwM/R0P0S+spCYZ7cEel4JHSJ+WP9MAkW6GJ yeiP8yMlo5skTOkV2hWJ4y+GdiKGnRyFPoHtmXzBX+sLq+PT2mqIlsn6HNq0VknzEm7JZxSc aw1fmWHpChDRpuUKO8pRuELvE28HGHdzhs0M4HICkJgB9K7OMSmln1SS1joc/OwOHGqYkFO9 jD/zGkXJt+oeg0ruYRI2OYjuU+6+hyRFOVBD5G0UYKwcJJoGzTik9dLSysESnATMrfzJDNmc uNPRzpz8KUXoa+05nSA5OZ2BIGUBY7IihxBTNGxKlLlHNMIt0R8F513D15DvB7Br/JzsqjRA DbvuLE1ZB0zi3wMGty1Ed7SQJoMUUXxt9JfBLzdLQSR4gzJQ1QBBUqY0S5gcQsyWZxBl7lcN WyT6o+C8q/RVfDMrC4IfwqFv+cXOspRFoQfOvTSAcT+/4FXB5Zxy66pQ1QpCPviUcRGTQ4TZ 8hWizD1t2z5IfxScd5W+W748+GBTVriXLEV90JH7AL9f6ylzdUgok7dorAiS7Kr6iBgdgfJF tvZ1drVSH+aXQYSyXU0IRT3gEGE27JopM/yGLpH+KDjv7epgoOLO1cEE36wOe0tTZAHIP6Ez 8CZSrw6F4VKUy/9K+q8fkaDeFgl/ASFmw/SZMnechrIT/VFw3tvp3ygMOzJ9j69w95KmfDGI BSCWgXoB+E7TF+1ASuRTetfF5vmxopyv9/aPqh4I8rJI8gsIMVv+QZS5dzUskuiPgvPeTvkL /3ChmfT3lqacEcWmwHizkfaXOX2R0ud3/XVOhxNJ8Po0zTIqDrl0GNIMRMPbqiPotUPIwLtr 6tashKccIkxGhSZeW+5xE35r9ekhHlEPZXgFVF9QoB5/VMMJPs4beol1Qs1yal/wQyhLxqVm J2JU2nq5Db+KXmx06LVejurx9PK55iAhlrssGDPDwkRWuxU0GaygcsFBbsKvkn99VEHVQTQE keIxs1AivD6Erh8MxPByL8QbhKVRb+VZDlNShkdnSJ9QguQThKvnORjSLzzxzRD1yhUhg1A2 Pw4xsn4WEGIyKteE6N78tkLUa/OvQnSSMwXJJCdCJBmXmp2IUbkmRPfmtxWia71cCNEsGDPD wkQYJAsoG6ygck2I7s1vK0SrDlIJUQUKsV3kDrsVvFjbSUTVy0LnBGXrcMuVVmVU2iq5Db+1 SlSIOafmG04+T97BVWFVYS2lTMGCIBKGC8oOwahcUMVN+FVUoWXEqKaPlDyCGtS7Df8IbpLQ +YIRAlkiLi07SZgjuqWMffmsldDXneFpcoXaxaORZnXxmArXdPEYq1dxK4GjhKKnpOrlsbV4 LNuT1LA4CFB/MgncqKEoSqzQq1sRbDqQHU6scI3Xl7pN0dpVK/089z/nst3JF6Hl9aos7lfZ yJ0aogvnsWbdyl8xdfuWy1iXphW5hXA0uyCox9kEYXIIMRutVabM8BvNDNIfBeddv2uJJdC6 MDVWju5Z7yXLcubiegcY/6uZS/2IBLnySm0B9ZfGbZkyd5uGsl15LZS51cdt8ZLN+jwaTaZ3 rZH73rKUho+9tPPra7aF4bdn6rJ208ryxkZox4c7eoLL07ee1njN6qxN/9WBsDjktmdXnOpl /JnXKEq+9ambjoF/KELftmdue8pR5mcPCcfZHjAW1t+8QdXzBSpa9dtvUGfxknuSgAQZie/M iMkhxGwFLVHmxm4ESqI/Cs67PghLc243kBmS0XT7pmxvaUrDRc7OVN5ZVvlaz28Li7sNWRmE sTdCbEegfk8tTVznhsam2WBuYRYQ4k3722+E+/LZapqsWU8mLrRM2LCjYNiyIkNakyhcTHaA af8FBezKpzZWqCmg0SBhR04CpX6MBMI1icDFY4JP+9sH35dP5eDGpt9Xli+nKVo2O2aUDlsx 5ErrLA+XtTjFvL+thX35VNrCQaffl+afW6IP3T9NHpR7CmVuZHN0cmVhbQplbmRvYmoKCjMg MCBvYmoKMTc0NAplbmRvYmoKCjUgMCBvYmoKPDwvTGVuZ3RoIDYgMCBSL0ZpbHRlci9GbGF0 ZURlY29kZT4+CnN0cmVhbQp4nO1bTY8jtxG961f02cAq/GYTGAiYGY8D+OZ4gRyCnJQ4QbAb IL7476fqvSK7JXE046MXg4V3ye5ifbPIrie7o19+O/xvcYuTUW75GJY1+eO6/PrPw1+/W/57 8Iv++fVfBycvwvL10InC8sUW6NIvxkL/5bt/H375Tla7Y5L/gnJoTf4tuR6rsGnlWGzSktCU vB7j0oLwKLnJu/OytmNbSvHLuurCEuTpWvAsiYbnw5qVR6myZs0yaMJBB9UL0ZnDdMwL6WoR WVxf8RpcV6+LIGkN8jc1WJO8Ox+omSzPC/WV5X6hHRieF+/UW5x516m9K8K2s/FuxWLl770b Yr33x2zaeB+UD5T0Pqpc6N7HMOlgM1hqK2C+caJfugw4zGQX33Wicw/QFT43CxiKLUTn/cTC 6TTKy1/+jIz5Tf77UXLjPx+B/WMH9ufDTwcna51QY6uHUMbCrzJLgzyEYMyDbzLvEQ2+Qn0v owzlVcXg06b8IYiJwcwKPkD5Bk4YW2z7TFfaCrjOeKlLDyZDXB265FVdZjpJcDSA0FWClhaz YBWNaNmqjgqhYaU8jR5hBG2MSBnjEQuyBtxjBXdIja3rkpw6nzrKuHXdbWxWcUZ7uYJ+iFvS G396jnLVn9Sn+5maMgLU3+KyRex8Eb/7O/cj0t9WpHUr4zSXP7KRnz4ffNTiVJvy/vyP5U8/ SL1Yl8+//O3BBykQyUX36Ir8eTnlBxfk2XPwp/Lg3emTPEgydNlH/edZn3h9EgJePsvSoG+i Sy7roLjqVi5qIHnU4ZNQZj6NXhe1098//3h4+XyjbdTAJKlP/kpZ9wPY1UvO3plS0O+RIp7c oz4XBzooK7o9uchBscVl2CPq0nJR7NmtXKH2rDItoq9Z9ijBfJZJdY38ryzaeccF4VNPvpoI +jPRF0We3TW+rreRSsLycQtBJD/VK2RGIhQSaDRfAtz0otHc7Axc9LRj5J7otmhhZvjUG0mt VF1lFCyEYvTjVaSvSc0LEBGq+kn94B/eslmyvF4HPKiy1E9iSZZh+BjKPFseVj5ou1TQCClN iCOXRzL0CJeh7y5hn28SorvnJiGyhSPLTiqnhMVM0yycX3ouvGF7XKWGXNleXdl2Ds2S7FPZ ZNn2Fqleuee6JCWDnnYqSJIMFXYHgZa63w77e8jXg5ebUbTZl+XnsUBvBbvqrYQRVVrr05fF ZkWvSF8u6vzt+UOx+6r59RAdKuJMbAxlR8ZbHoXazIRudK+JjHmz7eshiftfsTRl2tYJcVk0 oTYzoXvKd1oq7tYvrSbvJpZm3GOVTNzhEthGt+JLq5mVpLlvZedDK/uKiZUbodqVJY6blXl1 Oyvvi73Mjn7qF3DjqXRBV/SyOeiyfkZO6ZKehoMupTmV7KG0UcUIrWfJ61WQEkpAYKIkq2RR 2GY7ujdMHbyyHuDBTUyoSheMLuj3cYkTukC1Ox34pRkd+CWji+CXJ3Rxc+pXzFbMyo1TLjJT 7xJ13CWC+FTZK/M9XXfK/nshQtl+i4yxji/AyE2GW0yMcfcNGKPD7dFLSrfxURPFxO2eJMk+ vgOxvXGr2jb62cZ6CzNa3M6MC25txh13OZOJO55pY7c/0xP3QtNfbotmF+6QMQW7T8aUO2Wq eG88JFdz5549uENqDqgf0EZ2Uu1aWjmC9rvSdO4zWssV9AE5de9QBv1G2epN6tS9rLrS+9Sf UdnF63wRvftfCx9x/pbivC8ZF4dsmFduPmfdxnhStfHcajbH1xUbT61eczyp1nhh9TVGOMPq c/QNtdJm4a1afcEp6FVrVqlj9KNORyg0q9MxblU64to2q9Ix+VGjYwKvSY2OaavQMkZgJhX6 8sqiEfQjgpoX2Sr0nu71Cp1rYPSQ+ZxxR+QasSNwN5FMrWPn5lps5+Zax87NtR3b2Ll5DbZz 85ps5/K2cLZxGzs3Nz92bm5p7Nzcyti5uelb0wbNqrFznd5IbOc63ReW1RiP3WtvcqfHXhmc sIdMBvaWycauM52wG01Xu1C1sX+HbTZLY/+aJ8ip+4gy6D3KVp9Sp+7rlHsMYIHFZhe180UM 31OnP6L9LUX7uobmtVoFzXL6zKpsrnnU6lwnJUifyxnTa3XObUaBu79RpHVSovRF1EZXr9U5 tV2tHrNBd69WD06o1RlpcFurc+ry8GGSZlSqeqcCr9lxJbU6F7er1bnMqLoDe63W2Su12uKC Sq3R2yp1LnVUaqUyN1z2BIIc82GpSTdGbwqk0QHz2hpop08rOhynTwGNHI/PfhdPn8qDf9a/ 0WJTKrzVLsn64JOsSA9hPcnzZKufhPLp9Q6FaRPytS4mzWSSszB6wUM0EaFWo2Cdyb9ZiLzo In+XU8ymnWmi3SSvipdJryI03U7V22dezYa6MOrb9wxuUuN7puKqsDJUoQbe/HS8o5tGATeY 4uKV2d7DqUG7cTQZhs29f6/rBf6SA8drCQgIXZu0H4eRuSYZV4nY6VOdxfYtgdUfbyKZ6X/f I4pmMEYvKtRiufZYan/xTkuLcnK+yV6L8oVxMIyzYRmFqVWeVjHH74rDXrsUdzflu2GTRPM5 47wLxEMcz5dqzZNXugkezZziPboJ2rPRzk2YdxNuEXFJ5w6b6hDQJFMckGWoPH4AZYaq2CYA Tk3vlbBnwDlksGnAASV5HlZliQGPQh02hQRJJ0cfV+M8NNg0NK2VkBWd+hU6RKdHjMGm0al3 oG902i6CFRx22JQzhSJJTYiysyF0Sf6ENCmWYGfXhzCoqskWJXW3MU069JkqY/Qw3zjRL10G HEbZ9CO1MgcDOKXfaQOC0QN03obvwMI/QvrHC+krKDhDSVxRx4o1kiUxyB5LopNUgqgllSOa KWoPXJTmsDSomXmMG5FIznAbtRVA74wTXWnIqDo5mWxxvumkQYmGizJY1F9DGAxB5Lhjo/YG mKOtABo5OAGlhARglyY3tk0fXMlMU/QLzQKOu202K4abxu6N2LqPyJ++g1TzKfQZ3oamFgdY wNj0iJ130XsPAv4R5W8hyrfo96rtNLls3EBscg/NF7jgDAb37i38O3Qw8nsixqHJpSYQtbxC xjf8egKQh0cCysCp/QaivoGUaxW8Bk790w4I32HkhoTKRe8KAi0GggITryF2/Ts4qijvBQq6 UcfNf5kI7RyOHl69haMN4SVP0n0vzCD0PdhxczexvYCJ5fIXAm5/4o8d7J+G/vQ5CW71bPr5 YhBvbA9AlQ35BuotEVdQ/Xt98CJXY3Cwnxn0/GGkX+jHoGlD7zx28yX+8rI7by/tru1Vr5LT 30nkqdgZrLxZukeXZQFMfB7c8Axsk2yOiVnvAJl5xHeQmbMpTrcRRhRDdkZttrIlsqe8D712 boRepYzOWhh6cfcGvCog5w14DVjE9gVp7sOCXVifxdEouKKrG/6p36ZzZDOUssNJQ/G3YB/f yHdL3eiyO94Yaa9iQDtHEdCQPT+NgYCO2Y7u9VYyD0y25nTMhh1LNVt5vYizycfyzuYfyz6b gjwO2CwMo53Io4MjHikYWzMRtDiCjIcdTsYdhxal6lFGbfoRRz15+FF7Hoq0qh+XbMv1N7nT o4k3OKG5Bwlo+ZlcNAOHRmgTmq5o/IRdk3HYZjPYzBXWZAQveogy6DlINo9Cp+HrlHsMYAEi M+J13sXuPQ3kjxj/8WN83c4dtTDMixOe1942nhUmPLeyxPFtUcJzK0kcTwoSXlg5YuO4lyA2 jscsvF2OfHMjVXXMFJDRSFXf/C5V9SjpqaqnUU8z3yqRBSSgNnaSVX7cmccZYMnqcMdmsrqR qt7vU9VHYBjYIPipiG0dX/TDuW8qX0eyBk8cF2HEuCdrf5M7PROjc2LKUAZTibKZYl0rJp8b yUobbJz2yUqbQW+eAKfhI8gw70G2eRVaDX+n3OMAGxCdEbPzLn7vKUkfcf424nxTLNAwZbHw bZ2WJZHaKeSzLs8o1u0XDL7Of8HgqxtlyZd8nP4Kz6e6K0u+lF1ZGrNBdwfIoSevWuGAQPRb 7w2w5lPorWv7DesOsFH6AcL469624gNo3N/FdWIsu69HwwN2kI1XyEaxgXAKCtmE+rshm4gf qSkWgytma3PIZlyaV4dTtoIsVJ7qvIzvKV8HbbR9cm3T73H4G1iD5mb7/RDKDGnAj/l63sse lK+Onvev3Nk9+5V2FAZ2NMP+d4uXx+T9DxT+5Hb6EXZxUXBsKPMTzGb4H56+LBvdPUi3c+JP UacC+QPTjRD98mY/seXMvvr2lHeFmmNNqH24zYTad5+J8W4nVCtg3YTuv/5+Wv4PidVRYwpl bmRzdHJlYW0KZW5kb2JqCgo2IDAgb2JqCjMyMjEKZW5kb2JqCgo4IDAgb2JqCjw8L0xlbmd0 aCA5IDAgUi9GaWx0ZXIvRmxhdGVEZWNvZGU+PgpzdHJlYW0KeJztXU2PJLlxvfevqLOAbfP7 A2g0MNMza0A3WQP4IPhUtmwIOwaky/59870XzMqsyuqqlXsO22isVENmkvHJDJIRQbZ79Idf H/5+cAc3Srnnx3BoyT+2wz/+6+Hf/3D43wd/wH//+O8HN16Ew/eH2SgcfrEO6PqLgcC/evc/ D3/9w4N7LONxE4RQwmhdnB/tvj+E3B6j1ULOLPVR8qNLcXGUj4eQGntkvEl5ACoOvUKKKHv/ WA/Hh0CCi8+AlNxoW3x7TLMcwuhxXGplQLQeoT/mCSsGYHwwLLEQC7HHNp4YXQNGBSzQm8Io GxcDRjkYfywPSKUMeuabPuixHjUAw4RUywlHbcAh3M2xbFS1gJrobXH8Gh9WNg5VE+/qIZkI 1pSWsEiOwi75iq4peVEsnYgTaWqlw+NGo1PjGAiHf/tXDqpfx///OJT/tw/dv3vd//nhTzIk 47/xsX/+NrRMDB6/3/7z8C8/D0vSDt/++hQ+P3/728PXb6PHxkD47gdhObpHGBrf6iBDNd8S 7FMEMt8gvhzBtq+VPfIopUFujujjK0SXEwAfH3wdPVMClEorl+pjnuWh2kQ4qmX2RqkNHAZn MOoJhxhKZm/iLXU8MXqG0CA8o7RikBkHFao33lgesIbhjMsbKEU9ggsLpOBAjXAEV8db4Q6u syyqAlUreoOH4sXFLIs/q5Fz60GJGCyTlGGhDA17zKJJ0hal0oI4kHZWejtutPi6UfjQ93vU 96Uh8I19E343hsB/XQyBH2YgHQBj9IkNZNaq2SI22CjV4rBteZTDIdY+6rWC3VjzYLHWMkpx IKkVdjBWEFabJ7ORVq02rFhiaYDS8GvlHii4WYMdth69PxaD1VwEJOJorhAHMDcHGy6Kmqdw jdLmYVnFQfNxtBVvKg9YHf/am16tfXIQxoSUHGYp4UgO1lS4k2ssg6bkMaBFa/LeOFBJnLFM jq0tJSEYU0aCLukJK2QqakzSvUr6pHvq5KSt40Z3r3/+H1p+P1q+/OhjI+RWzj/68LL/0fvg QHbKHA5+LBuK1fwQ3GAilYOn/UoJAvMST3ajhH8hAD9sV8pZ84CDAFLuo2/HTyrQlRULxaXK mAziwZpXrNkIptJwA3RzBE10DVOEkTFMPwkReYPTMQWI7DERDEMvhlgekEJif73Br/WgeV1g xcQ+xDJWg31iH6vEPmniatYoTTDuxoHKxtqsgWfrQVEYpCkk4ZDwhBsCFU0Ss2iF8MWBVLJS 1nGjuhtT/oeS34uSd+Z5P3oWdzHLn5b7fz/A8P06Vh5Fax1sBkkRXAl5wAXUBWZIlTsR2LPR MMBS547fXw4hNnZzqq1aXo5AQzoWcWMvE7HoGfONw/KuFKjyDG30Fduk2tkwDIR11IQousZu nt3WLfdcHtFzlVegmQGJmzTVfrEtW2id66aYHDd1m5pabqDcmFJ/CL6drV13bAFZrHX9lyff fHv+qTz5/jx+Pj3/x7c/7uz0xiaaG0qjM5QVPqsZZVuqNxxtoNxwP/wQfDtySY1b/nO5rL+B 7QBp9AsYYRs1nKkohXxZmwpbQbm15voR+HZm/4IN0+4ACb4+e//kPp/GxnYd0OnEMBK1U5uo rDa1s9XcWqsbKLd2oT8C394uKNKhcjk2svv5ypKI5n0hbUxBJxRWM2K2hG6Y2EC5IYofgm9H FMGxxZ75oPFoY1P55cr4aHmhMJcVIlUmRVtqN5y00xf9mjDeFs+lEOr+YPh6xVDIJtPBt1h2 1hYrlUDY8hlva2q5gXLXTPLG+K7OJAHrgf/HTDLp1Dc56VTNKNtSveFoA+WumeSN8V2dSS7k cmsmMcI2ajhTkdnybW0qbAXlrpnkjfFdnUn2BsidM4mRaEbKUFltamerubVWN1DumkneGN/V mWRnbNyaSSZpslOTNNWMmC2hGyY2UO6aSd4Y39WZZNd83DWTGIUy6oZIlUnRltoNJ+30Rd+a Sd4Oz/5McjkYrkZZKFRf82qSV21B69J6Wt/UrOUGyj1D4a3xXRsK+jauDoVr00jLC4XUykQk FU2KttRuOFkA3BwKb4hnZyhgA3wpg6uzhgIFi3LWIj9Th01Zm9qkZA3lxvT5Q/DtDIZeGUba GQw7s8b0EMSEXpWe0zGnVSzeak78IrcegtrpoLZtVElsyPUPw6o1e5ZPrUwsSKaABcJ3WCr9 Un1Mb0MUJdMzhZovcD0nehV88fQVyUnsc6dPCaFZn+nmbfBL+VzpdwIdxwef5cWi5yln+pc4 LlTuGAHHpcaYlHp0+H4MVi+K7ghLbxN3F4WgKjvH4LPozQ6xJ/GBMmgHhyoPSKUvNcbc1J6h 5wVSTfCsCUcVfWhN/9WkqFbWSKuc2OLBysadauJbPSQPwZqSEg7JULglW1K1SL36RRt90dla f8eNNm/Yww+9v2O975giJkoAcz6boL+s1mqLWYjOWb4HNxi9McsDtdAxSaA85vtO72WEaTmO WqRnc6yru+dzMKatVYmZWST9UbktcmBE5p2UWZ4ZKVYLtsNFrgrINkipkGXDMTYofmJOoo80 ZTBynNQyIG1cZPQz/lg+Dm7DUoNHNlmPyBjVhBVdMxzRiULgjt6xLKqw1YxGr7ad4mOWxaHV yLv1oEwMFmVlOChDYo5h0mPyNkqpCeMgiLqT7o4bTd7YS33o/J3qfM/hkZnddWkO3J45CLEx 24MBkFisjJjJsKl5DIqIqE4uDuKPQJ4Lk7VCZ8YK3obQWE7KIAnKZSm270TGSV3KnZbPapUp YGrPSJRBqpnMGo4KC2i4q6gjTVz9HCetTEQjB80fyFUjNYmZOHiWgM3aJQSeFwgJsSGDzQ2S 4UzMX5nUpMYa6UyijPSrPDmzGnlWD0hCkKaEhEOyE27JVFRJ1qIWGhAHppepreNKczeWxB8a fhca3vnUI+gAxO1ebH/eJ5PVd20plOHCGrJSxjYioGEkkzUozSsyWayGwAwXsFQDc0wKbEwN mWRie4JaZbYLBFADclisHD2WV0uNFlA9Yp6QaC8BiThkSYU7kkJRlcxSil6Kz/hIELRxyDLy a+pSw0YpzB5joCyQGpZjhqOJPuJumWWjqhXWBrWtkFryYGXjTjXxrfaShyBNSQmHZCjcki1o mjIXrdKGeDAtnfR33Gjzxtz/ofd3rPcdfzYTCQbms9n/665RYFaai1wXRmRzqhKR2BGZrx3T QakMg8TA1Qt6cJFCC9rZUpnktujBchAyoBfFiskWg6wowsXWtHmEEZzWXIQdkI0qfIEEjf8x c+RotIVMOYHigL2WOGEReWwQNCuJvdk6MWnPoKRqkBNJIj6tBo0OLhNFXyZJpNqK4sYqTIVV a/A+15Sgg7CddnCUnGgweYo2SlkUS/YnnRzXldcdfx+a/H1pcufDTWzQ7tzGdyaCmIOwLlkk lGkoXpIOxRJSA7MrRCVWNAV8U1s4gZGnzhEwjtJtsAg8i4HGzipM9NahkmIwapXFJOwqBbKV 07gL9H6YxgMT00RzW+SkomlclaTYN1onJYsISqoGOYkgpqtyt2h0UIegLosgLh9VFCdW4bKL bcm3YJg8BJtyAj7KTlSYTEUdJb1KSFjp5bhW0o1J+kObvzttXvmCB8a7luMENqPbdYndS6a+ maQ17Zv8g4w1d1RhWuwQ0qLvkKfFxparzGKn51KV6KfFHruHabFDzHSBCnas02IjBzKSjthP FhvbFbPYOvgmXrS2Mo0rV1QRR7fI2qBAA4QsrRCftGV0SIukT7ol1SoaN1ap02KLd0GhRASb cgK+4JZxZzJNMwJqNtvkf9LLca2ke77fD23+nrR57fsN8T7PGcHNSGPUGbA8bTbCAZS151Le dK7gAfXia5822zd/stkIKZrN9gjLqwCZHmelT4vtO8VGGF0HwQS702FJjJ1rrEFHLyebjeil 2Wxlg4iX3k42WxVKVa0p7QklVYNMvQgftTXpoBZFH3Urqq0obqySpXHxLRgmD8GmnNIShiEV JlNRV3VGZQl2r/RyXCvpji/4Q5u/K21e+YIHxqt73zOll0QPSDK7jQMI1Td6Kuh5cPTjF5yB Lo3nsTKOWJTSOR4gnUIXYOTeHqelC/WGVrkXrngS3ZqAETJdhylrCxWxX8i+MyMJRlPHPwuO aJBfT6dhyo0HMXSSZciIuBIVjhMs3BzRkPahtwAT2GCuZX1b5CkMKKGxX8YKrHtaUk/r2xsD sFQcNz6Zvz5AWTnquEij45IBTWaV5lZtsAzZeDvZ7UEF4iKYTODhwEEGLKZAa2l2Spxnyarz Fi/pQ+aJG7punhEMKORKwM/ihsx5mi46eqBOGjtu9LceECvntwPFucNZiyPAmafQIwOufZQ7 g9SMMflGvJ5eIZyBz5TAjKX4oPP3GMvek+vMYzGep/czeukQTymVB3oIlatVHW0pFcdx/JCD PFXSaWn8hnMaJQWSnT1luJlSLg34wIunFLF6wEq11GyOYtJZ3RhhWOKWMm8GQLQsm7lJ1A13 7Bbp48hdYk20OIpZBcctvTSbZlSL8aoj42UV52S4/cW1HtxDdE7w3Y7+tsgRkrguh8ue30KO NnI0/hkWaN24yT0wI+ekseNGf1PD22yzEpfAJjIJvNV81mULPNPEk0klarfgU6dKh1pSedSl CDgDJfE4KoYikUGiLZLYrJwV9ps1mhz1yPyABal4xe+FgzsPYi6wl0ZR6RpyorX6g3HAqAM5 q94MQeFgUg4B0gvZmpGKBUqtE3rlBQvC2ThQJjXciRmdTYNYJlNl40w18awekoVgSUbCIdkB syQqiqakRal0IA6km0Vnx5X+bmW1fOj5/eh5J4slVwu0b6Zu5zdT9yr2xawXLEROCXiBCXjh 5+efwpP79PyTf3LDQvHfzN/iKv9tbKE3/dkaO6Ts4cnL8095vg38XT0PAb8+sYN3z+0ptOfZ nHVrfQYyzD4G8mUBIxJ8XPUSHNERludoCAras0/W1Tv/QuDuK1kKp2bqIgrxOE2WoruWpBpj tFHJA4yha/yZkxbjkskPDF1gYlPyg0ZyYVoE0zN4gF2e1cLj65hWuFTiAXZLl+AS0spM+FgS KXo9qH1l9pYgVWdH3YmjOu5qibu6zvUxj/R7LjaN3uoj3zCw4rFIEIcqD1hjaWPPk2NYjO0Z o10gpXrCkZhvKdyZwahJVY6skd7MRA5wYSXjTjXxzfYmD0JaJEUcJkPiNtmSqkXqpNf0EevU 0kp/x402b+x9PvT+jvW+s0sKWmLW84T+UPazuJPjfU1jcCQecEc5KheLaZe4xyFyZa07K7S2 5l61ceXP+yEQE828K4p7pMYpxOeDzuhg/R1nOQSLrqpWGF2Nj/OeKoNkN1gZDt5tZbgjditG 1czSEr2cwI0LrubJm63rk8OEac891tnW3tuigZCSb4YhMVorzCnMxQf9ZoFTK6nViSRxMcvi z2rk3Hr4PCGZnAwHJUjMlKtRZBI3WqkL42FoaGrtuOjvdTPwoeX3o+Wdj75Tfh70bT/7n698 9JVODMscSzxloFoqdNTSmZEKwzFad/J2hkY3QYTbApu6kul00H0MXME+pMwbGSosX8qR7hGy a+UuBajGAWE9mu6ZIKyu4K5h4UUyhp353EZX16ZeFBe7ncNN0ZFDE15tGui8N8PPthyCC5RG x4fg61Yq4eUQXCjipZVGay/MTSMPKk/urCY/N3tIHoI1JSUskqGwS7Zt5pRR6qTY9EE+TE8r DR43+rxhCD40/641f2kcUlG2I6jdBi/bFdcp7mPLhv/7Q6bjE7fJDAroLEpM1kp0D6aa6WXm +Q/mYCa6y3ByAo5M6tGufUy+0CkKLmNvvB2uMyEKvEVyHXPlKEp0hgdzQSHXhCnhvtqKkTqm M1KZGyV3ZmBgD87JQsnU6ks3GBy+ndkfWFPmRyWBgz4kbxWuKSvTuoBZqV+6IDPS5QbnMaZD z9Wm4yTEVbOdMRnmnw48XD80pgHev5eKJjD6wJdLN3k2hqOVmbA+kGM56TInmZwpqQh+MgNw mbG3HJTgnhmqy+qvAB1dvGvNHTd6vDJxKKhWEIw/O+o2yPLlOfaxV3Wfx460PLkvLo29KPet +5vMBN90w0c5TAuz5FRLEovuFluO3CjAmHkUB4OHw6xDsYl+RQiJgi28SpA+5cTU3MzUnFlu mkFV0+1o6sH5ULDgidfnwjygwEyFgTuHbJ/XEB6z+45GbeYWQ1xAkOClWwmfMK971HMOAGvP +9UmpOyiYci6IpF4s+NVj0ZRdryZiLRmemjFg5WNu1njtZLqQXkI1pSUsEiGwG2S1Z1vU+Iy dNIFuZg6mqXjSo83JpMPfb9Dfe9MIS3Q2JxtKqO74sCLDGXlMGecMP13zpsrK6zdd6uztJdQ AlgllCGP8eA1x2FkyIcWfOs39J+B11xyRX5BueBoz4oq0fv83J58eP5p/BY0jgHeOvbb+ALl gYsRHrhMQHL6hemI8y9rv54h+2Ld6+ICDHHlAlSjunJOyvM3JbUhvK+cjC/PxeH2l1cFySnz NwnSY/p7xQFr9Kzdk2nFM0Tr167WKXE0LycvaLFHi7d2vmgnAENMdULH45hMrGFKYiXIqR7z jfqNznZcr5/OHcH2JFy4md3az5zP2T0NsTW/K1e0VN4xaL4QWvh0EsPU8Wpc9hOTXzAmL4aP Ebp6uaOHFdtTIvAcG6nqO8fUmbOauMNnNAnl9eHFk7m/ZXj19f1FGl0x88sTYfXkdY9rclxa e98/b3Rbxn+fFjkGGzfG0ko+wWM982kj8bwZQC+nQeVXYYawGnfrcR/OOodlvFyzB+EsmPDP RTPCZpBvowvZogin0MAUkS3iFkGcR0W2sY2TENwkbyXblbI2IYqXV4cLdzpb5ROlW4I74sTY /bL6It3ThdmZXJwGx0VsZwPuN8h6IevlJP1Qn31dtL36HM/Gy2sCqEs47M7PpYbzOW21QqfE f14N45OEdixS3Dzri3imjttqTrwzJuae9geVMM0g1TpUVs/kPL85Y+Dys3lNmsyl+S3SzG21 G7apraymti9zIJ24WgzF6bOdI8ldDqW8DMWzoXQ+LUxrEHpwlNWnzUAua1tzZd0idJ8WuXGE tisaORl5d5oawjKa/No2TV2t55dXN4CK9syjKrq3zM5F2C1mMSp2oWu+zmp2gmIN5Z6b5t4a 37Wb5iLjR//8TXMLnTw/u9CpmlG2pXrD0QbKPTfNvTW+azfNXcrlxk1zy1mmtRrOVCTP+llt KmwF5Z6b5t4a37Wb5nYHyH03zU0SdZHRRGW1qZ2t5tZa3UC556a5t8Z37aa5vbFx46a5hTQf VyisZsRsCd0wsYFyz/Vib43v2vVi++bjnpvmJoW86WsiUmVStKV2w0k7fdE3rhd7QzxXrhd7 3VTMu7R8lP/IM2Pb8xh8Zp7l2V1avuovjyS6oHDvEBwzkTnESGX19DZLZaeWNijOfByydSfX QVj2JJp/x/qljwkTEySWilxyzxXAaNHG4y/PXApjATDaqg/eY2VgAF7Yayyc0OfrmJf9BB6e OX1rUTDqX/kkyGPyEsLooxmZu0FM5z7jCZwpY+amr0ILgIA1WrIiuxndgBvRlO39yiItY6Lr HhXkfn7HBfNMdeiUOwdCZk7Dd8svh4e8rl5meK2+81qEwHPX655Mvv7Os2E63t34suj6pjHu kJX6mFavaqFzUMRE3rVwetkdQ1DM6j/EikSMylxZvPSOx8F0XzujxY1nvEXP+B6HhQfQFJCD iizjoDdRf9mikg/kZBdLJ+HbzANzzP3+Dq/jobp5w5unmz0y7PHd/G1KE8Fb3EWXEeoY7zIz z4td+/Rnu3Ij0p853gbm4zK3mm9zsiz17/gTO4/zr4bxXcM73jh3yLy6ooR5FX6kh3F5WxSD TvNtUib8fKsLPZrhjMxb1jn+5W2at91DqoFn6zvfZnovo0G+XKDViecBh/Sa1UJgaKa0R/3J JmUX8Oosi+pH81pFzsbx0HUwSH+XoOjyssJAGkcXnbIahUrzsfGq/CVuEsABoRRm4SzJ3rUy /5PxGTpPRVD1lUF+kVojiBcLGoViTmXkC7WlFvnXj9Qjxc48JMHCbV/dsMCx6w17jspXFV2I /3gj2MTfdOsIywuDrIlz9jCBENaUlLAkc3wzNud0ZpMHHUzooljqECdS01qBx40651T3p8P/ ASYsYGkKZW5kc3RyZWFtCmVuZG9iagoKOSAwIG9iago2MTI1CmVuZG9iagoKMTEgMCBvYmoK PDwvTGVuZ3RoIDEyIDAgUi9GaWx0ZXIvRmxhdGVEZWNvZGU+PgpzdHJlYW0KeJztXctuZDly 3esrcj1Ay3w/AEFAlarawOzGU4AXA6/SHhuDLgMzm/5985wTvMmbylSqx6pFC0J1Z5H3kvHk DZIRQZa794df7/5+cAc3Srnn+3Boyd+3wz/+6+7f/3D43zt/wJ9//PedGy/C4fvdbBQOv1gH dP3FQOBvvfufu7/+4c7dl/G4CUIoYbQuzo923+9CbvfRaiFnlvoo+dGluDjKx0NIjT0y3qQ8 ABWHXiFFlL2/r4fjXSDBxWdASm60Lb7dp1kOYfQ4brUyIFqP0O/zhBUDMN4ZlliIhdhjG0+M rgGjAhboTWGUjYsBoxyMP5YHpFIGPfNNH/RYjxqAYUKq5YSjNuAQ7uZYNqpaQE30tjh+jQ8r G4eqiXf1kEwEa0pLWCRHYZd8RdeUvCiWTsSJNLXo8LjT6NQ4BsLh3/6Vg+rX8f8fh/L/9qH7 d6/7P9/9SYZk/Bkf++dvQ8vE4PH77T8P//LzsCTt8O2vD+Hz47e/3X39NnrsDITvfhCWo7uH ofGtDjJU8y3BPkUg8w3iyxFs+1rZI49SGuTmiD6+QnQ5AfDxztfRMyVAqbRyqd7nWR6qTYSj WmZvlNrAYXAGo55wiKFk9ibeUscTo2cIDcIzSisGmXFQoXrjjeUBaxjOuL2BUtQjuLBBCg7U CEdwdbwV7uA6y6IqULWiN3goXlzMsvizGjm3HpSIwTJJGRbK0LDHLJokbVEqLYgDaWfR23Gn xZeNwoe+36O+nxsC39g34XdnCPzXzRD4YQbSATBGn9hAZq2aLWKDjVItDtuWRzkcYu2jXivY jTUPFmstoxQHklphB2MFYbV5Mhtp1WrDiiWWBigNv1bugYKbNdhh69H7fTFYzUVAIo7mCnEA c3Ow4aKoeQrXKG0ellUcNB9HW/Gm8oDV8be96dXaJwdhTEjJYZYSjuRgTYU7ucYyaEoeA1q0 Ju+NA5XEGcvk2NpSEoIxZSTokp6wQqaixiTdq6RPuqdOTto67nT38uf/oeX3o+XnH31shNzK +Ucfni5/9D44kJ0yh4Mfy4ZiNT8EN5hI5eBpv1KCwLzEk90o4W8IwA/blXLWPOAggJT76Nvx kwp0ZcVCcakyJoN4sOYVazaCqTTcAN0cQRNdwxRhZAzTT0JE3uB0TAEie0wEw9CLIZYHpJDY X2/waz1oXjdYMbEPsYzVYJ/YxyqxT5q4mjVKE4y7caCysTZr4Nl6UBQGaQpJOCQ84YZARZPE LFohfHEglSzKOu5Ud2PK/1Dye1HyhXnej57FPZvlT8v9vx9g+H4dK4+itQ42g6QIroQ84ALq BjOkyp0I7NloGGCpc8fvL4cQG7s51ZaWz0egIR2LuLGXiVj0jPnGYXlXClR5hjb6im1S7WwY BsI6akIUXWM3z25ry0suj+i5yivQzIDETZpqv9iWLbTOdVNMjpu6XU0td1BuTKk/BN+FrV13 bAFZrLr+y4Nvvj3+VB58fxw/nx7/49sfL+z0xiaaG0qjM5QFn9WMsj3VO452UG64H34Ivgty SY1b/nO5rN/AfoA0+gWMsJ0azlSUQn5emwpboNxac/0IfBdm/4IN08UBEnx99P7BfT6Njf06 oNOJYSRqpzZRWW1qZ6+5Vas7KLd2oT8C36VdUKRD5fnYyO7nK0simveNtDEFnVBYzYjZE7pj Ygflhih+CL4LogiOLS6ZDxqPNjaVX66Mj5Y3CnNZEKkyKdpTu+Oknb7ol4TxtnieC6FeHgxf rxgK2WQ6+DbLztpmpRII2z7jfU0td1BeNZO8Mb6rM0nAeuD/MZNMOvVNTjpVM8r2VO842kF5 1UzyxviuziTP5HJrJjHCdmo4U5HZ8n1tKmyB8qqZ5I3xXZ1JLg2QV84kRqIZKUNltamdveZW re6gvGomeWN8V2eSC2Pj1kwySZOdmqSpZsTsCd0xsYPyqpnkjfFdnUkumo9XzSRGoYy6IVJl UrSndsdJO33Rt2aSt8NzeSZ5PhiuRlkoVF/zMsmrtqF1aZ3WdzVruYPymqHw1viuDQV9G1eH wrVppOWNQmplIpKKJkV7anecbABuDoU3xHNhKGAD/FwGV2cNBQo25awiP1OHTVm72qRkhXJj +vwh+C4Mhl4ZRrowGC7MGtNDEBN6VXpOx5xWsXirOfGL3HsIaqeD2rZRJbEh1z8Mq9bsWT61 MrEgmQIWCN9hqfRL9TG9DVGUTM8Uar7A9ZzoVfDF01ckJ7HPnT4lhGZ9ppu3wS/lc6XfCXQc 73yWF4uep5zpX+K4ULljBBy3GmNS6tHh+zFYvSi6Iyy9TdxdFIKq7ByDz6I3O8SexAfKoB0c qjwglb7VGHNTe4aeN0g1wbMmHFX0oTX9V5OiWlkjrXJiiwcrG3eqiW/1kDwEa0pKOCRD4ZZs SdUm9eo3bfRNZ6v+jjtt3rCHH3p/x3q/YIqYKAHM+WyC/rKs1TazEJ2zfA9uMHpjlgdqoWOS QHnM953eywjTchy1SM/mWFd3z+dgTFurEjOzSPq9clvkwIjMOymzPDNSrBZsh4tcFZBtkFIh y4ZjbFD8xJxEH2nKYOQ4qWVA2rjI6Gf8sXwc3IatBo9ssh6RMaoJK7pmOKIThcAdvWNZVGGr GY1ebTvFxyyLQ6uRd+tBmRgsyspwUIbEHMOkx+RtlFITxkEQdSfdHXeavLGX+tD5O9X5JYdH ZnbXc3PgLpmDEBuzPRgAicXKiJkMm5rHoIiI6uTiIP4I5LkwWSt0ZqzgbQiN5aQMkqBclmL7 TmSc1K3cafmsVpkCpvaMRBmkmsms4aiwgIa7ijrSxNXPcdLKRDRy0PyBXDVSk5iJg2cJ2Kxd QuB5g5AQGzLY3CAZzsT8lUlNaqyRziTKSL/KkzOrkWf1gCQEaUpIOCQ74ZZMRZVkLWqhAXFg epnaOi6au7Ek/tDwu9DwhU89gg5A3O/FLs/7ZLL6ri2FMlxYQ1bK2EYENIxksgaleUUmi9UQ mOEClmpgjkmBjakhk0xsT1CrzHaBAGpADouVo8fyaqvRAqpHzBMS7SUgEYcsqXBHUiiqkllK 0UvxGR8JgjYOWUZ+Td1q2CiF2WMMlA1Sw3LMcDTRR9wts2xUtcLaoLYVUkserGzcqSa+1V7y EKQpKeGQDIVbsgVNU+aiVdoQD6alk/6OO23emPs/9P6O9X7Bn81EgoH5bPb/etEoMCvNRa4L I7I5VYlI7IjM147poFSGQWLg6gU9uEihBe1sqUxyW/RgOQgZ0ItixWSLQVYU4WJr2jzCCE5r LsIOyEYVvkCCxn/MHDkabSFTTqA4YK8lTlhEHhsEzUpib7ZOTNozKKka5ESSiE+rQaODy0TR l0kSqbaiuLEKU2HVGrzPNSXoIGynHRwlJxpMnqKNUhbFkv1JJ8e18rLj70OTvy9NXvhwExu0 V27jOxNBzEFYtywSyjQUL0mHYgmpgdkVohIrmgK+qS2cwMhT5wgYR+k2WASexUBjZxUmeutQ STEYtcpiEnaVAtnKadwFej9M44GJaaK5bXJS0TSuSlLsG62TkkUEJVWDnEQQ01W5WzQ6qENQ l0UQl48qihOrcNnFtuRbMEwegk05AR9lJypMpqKOkl4SEha9HFcl3ZikP7T5u9PmlS94YHzV cpzAZnS7brF7ydQ3k7SmfZN/kLHmjipMix1C2vQd8rTY2HKVWez0XKoS/bTYY/cwLXaImS5Q wY51WmzkQEbSEfvJYmO7YhZbB9/Ei9ZWpnHliiri6DZZGxRogJClFeKTtowOaZH0SbekWkXj xip1WmzxLiiUiGBTTsAX3DbuTKZpRkDNZpv8T3o5rkp6zff7oc3fkzavfb8hvs5zRnAz0hh1 BixPm41wAGXtuZQ3nSt4QL342qfN9s2fbDZCimazPcLyKkCmx1np02L7TrERRtdBMMHudFgS Y+caa9DRy8lmI3ppNlvZIOKlt5PNVoVSVWtKe0JJ1SBTL8JHbU06qEXRR92KaiuKG6tkaVx8 C4bJQ7App7SFYUiFyVTUVZ1R2YLdi16Oq5Je8QV/aPN3pc0rX/DAeHXve6b0kugBSWa3cQCh +kZPBT0Pjn78gjPQpfE8VsYRi1I6xwOkU+gCjNzb47R0od7QKvfCFU+iWxMwQqbrMGVtoSL2 C9l3ZiTBaOr4Z8ERDfLr6TRMufEghk6yDBkRV6LCcYKFmyMa0j70FmACG8y1rG+LPIUBJTT2 y1iBdU9L6ml9e2MAlorjxifz1wcoK0cdF2l0XDKgyazS3KoNliEbbye7PahAXASTCTwcOMiA xRRoLc1OifMsWXXe4iV9yDxxQ9fNM4IBhVwJ+FnckDlP00VHD9RJY8ed/tYBsTi/HSjOHc5a HAHOPIUeGXDto9wZpGaMyTfi9fQK4Qx8pgRmLMUHnb/HWPaeXGcei/E8vZ/RS4d4Sqk80EOo XK3qaEupOI7jhxzkqZJOS+M3nNMoKZDs7CnDzZRyacAHXjyliNUDVqqlZnMUk87qxgjDEreU eTMAomXZzE2ibrhjt0gfR+4Wa6LFUcwqOG7ppdk0o1qMVx0ZL6s4J8PtL6714B6ic4LvdvS3 RY6QxHU5XPb8FnK0kaPxz7BA68ZN7oEZOSeNHXf6mxreZ5uVuAU2kUngreazLlvgmSaeTCpR uwWfOlU61JLKvS5FwBkoicdRMRSJDBJtkcRm5ayw36zR5KhH5gcsSMUrfi8c3HkQc4G9NIpK 15ATrdUfjANGHchZ9WYICgeTcgiQXsjWjFRsUGqd0CsvWBDOxoEyqeFOzOhsGsQymSobZ6qJ Z/WQLARLMhIOyQ6YJVFRNCUtSqUDcSDdbDo7Lvq7ldXyoef3o+cLWSy5WqB9N3U7v5u6l9gX s16wEDkl4AUm4IWfH38KD+7T40/+wQ0Lxb8zf4ur/Luxhd70R2vskLKHJ0+PP+X5NvB3eR4C fn1iB+8e20Noj7M569b6DGSYfQzk0wZGJPi49BIc0RG252gICtqjT9bVO/9E4O4rWQqnZuoi CvE4TZaiu5akGmO0UckDjKFr/JmTFuOSyQ8MXWBiU/KDRnJhWgTTM3iAXZ7VwuPrmFa4VOIB dkuX4BLSykz42BIpej2ofWX2liBVZ0fdiaM67mqJu7rO9TGP9HsuNo3e6iPfMLDisUgQhyoP WGNpY8+TY1iM7Rmj3SClesKRmG8p3JnBqElVjqyR3sxEDnBhJeNONfHN9iYPQtokRRwmQ+I2 2ZKqTeqk1/QR69TSor/jTps39j4fen/Her+wSwpaYtbzhP5QLmdxJ8f7msbgSDzgjnJULhbT LnGPQ+TKWndWaG3NvWrjyp/3QyAmmnlXFPdIjVOIzwed0cH6O85yCBZdVa0wuhrv5z1VBslu sDIcvNvKcEfsVoyqmaUlejmBGxdczZM3W9cnhwnTnnuss629t0UDISXfDENitFaYU5iLD/rN AqdWUqsTSeJilsWf1ci59fB5QjI5GQ5KkJgpV6PIJG60UhfGw9DQ1Npx09/LZuBDy+9Hyxc+ +k75edC3/+x/vvLRVzoxLHMs8ZSBaqnQUUtnRioMx2jdydsZGt0EEW4LbOpKptNB9zFwBXuX Mm9kqLB8KUe6R8iulbsUoBoHhPVoumeCsLqCu4aFF8kYduZzG11dm3pRXOx2DjdFRw5NeLVp oPPeDD/bcghuUBodH4KvW6mEl0Nwo4iXVhqtvTA3jTyoPLmzmvzc7CF5CNaUlLBIhsIu2baZ U0apk2LTB/kwPS0aPO70ecMQfGj+XWv+uXFIRdmOoHYfvGxXXKe4jy0b/u93mY5P3CYzKKCz KDFZK9E9mGqml5nnP5iDmeguw8kJODKpR7v2MflCpyi4jL3xdrjOhCjwFsl1zJWjKNEZHswF hVwTpoT7aitG6pjOSGVulNyZgYE9OCcLJVOrL91gcPh2Zn9gTZnvlQQO+pC8VbimrEzrAmal fumCzEiXG5zHmA49V5uOkxBXzXbGZJh/OvBw/dCYBnj/XiqawOgD3y7d5NkYjlZmwvpAjuWk y5xkcqakIvjJDMBlxt5yUIJ7Zqguq78CdHTxrpo77vR4ZeJQUK0gGH921G2Q5ctj7GOv6j6P HWl5cF9cGntR7lsvbzITfNMNH+UwLcySUy1JLLpbbDtyowBj5lEcDB4Osw7FJvoVISQKtvAq QfqUE1NzM1NzZrlpBlVNt6OpB+dDwYInXp8L84ACMxUG7hyyfV5DeMzuOxq1mVsMcQFBgpdu JXzCvO5RzzkArD3vV5uQsouGIeuKROLNjlc9GkXZ8WYi0prpoRUPVjbuZo3XSqoH5SFYU1LC IhkCt0lWd75NicvQSRfkYupolo6LHm9MJh/6fof6vjCFtEBjc7apjO6KAy8ylJXDnHHC9N85 b66ssLrvlrO0z6EEsEooQx7jwUuOw8iQDy343m/oPwOvueSK/IJywdGeldUftznu8AT+t+jN GI7HY3vN13LUTc+g/HExhrwB9mroBp/+aXPxbWi/PP7UZve6OQRDXByCdP3V1a9IWqfYBjl1 B7Ivfsinx+JwHcyLkuUc+psk6zEfvuCRNcmu/spVmKDfr77XqQI0Lye3aLFHm/t2vmgnAJHs J3P55oeYNn0J2+J03TRkzlK/U9sFX+ync8+wPQnP/M5udTznc3ZPY27ld/FNS+t9sO6/EFr4 dBLDHK3LQD0NyisjyAhdXl7Qw8L2lAhcyUaq+i5javVeE3f4jCahvDy8eFT3twyvvl5opNEV MzAZYfXkho8rOfND+3zS2qbbMv582uQYbNwYS4t8gscC59NO4nk3gJ5Og8ovcYewjLt13Iez zmEbLzZ+F6uwAdhFF/658EbYDfJ9uCFbWOEUK5gislXdJojzMMk+2HESgpvkLbJdlLWLWTy9 OFy49dkrnyjdFu0RJ8bul+WLdA/PzM7k4jQ4ngV7duB+g6w3sp5O0g/10ddN28vneDZeXhJA 3eJjr/xcajif5JYlOyX+8zKMTxK6YJHi7lnfxDN13JZJ8pVBMvdweVAJ04xarbGzeibn+c0Z A88/m5ekyeSa3yLN3JbtsU1tZZnavsyBdOJqMxSnz3aOJPd8KOVtKJ4NpfNpYVqD0IOjrD7t BnJZbc21hQzRfdrkxhHarmjkZOTduvSYo8mvtmnqap1fXtwR+uXIxLzAxw5K2OU0MSqYoRtc zmp2pGKF8poLg94a37ULgyIDSv/MhUGTQt7dMxGpMinaU7vjZANw88KgN8Rz5cKg5zK4cWHQ ppxV5Gfq0JU9ZzWjZIXymguD3hrftQuDLg6GFy4M8lGbZM+0VM+zvpnJZGcXBvmqf14hcZ+N y1Ww+4xMlES+nqdLTaP41NJEc0apg88uutMGKWwLLRmVYZT7sAKySqPSxic/zdpo0dzT+Pg5 v8Oqjbbqg/falBDAk2fzMR3AQATt+r4OKyGDBMtlVXv3FAIbq99AAesUaYCHEfIYUqdvaWq7 684H5Kl9x2XYDMt2io9DPDP++t1yYeHNq8vLjB32dx7hDjwjuvZkouh3nmPRUdTGl0VXzYzh hAy6+7S8qoWODBETeS789LI7usuZgXyIFUHjyrw+vIRSlPPZxltEthrPo4qeYWkOKQBoCsiX Q0Zk0JuoW/gr+UD+aLHQN99mHu5hnup3eEgO1c3bqDxdgpEu2u/mG1BIG29xb1aGW3a8y8yS LXZFzZ/teoBI38t4G5g7yDxQvs3JMmq/458DuZ//whHfNbzj7ViHzGP2JcxruyO9IdvbonhZ mm+TsnbnW10+0AxnZI6lzhxvb9O8mRtSDTwH3Pk209MSDfLza0vrxHOHA0XNaiHQjVzavf55 GUVCec2PRSCjbagjI4Lx0HWIQXeoF120VOj05+iiA0mjUCkJNl6Va8H1CzgglMKMgS0xtVbm qtGXTEePCKq+6uQXSa0RxIsFjUIxpzJyG9pWi/yXWtQjxc6cCcHCzUTdsMAJ5Q17jsqtE13w VXsj2MTfdEMCyxuDrIlz9jCBENaUlLAkc9IxjuB0voxJ2SZ0USx1iBOpaVXgcafOabf/dPg/ nxW0uAplbmRzdHJlYW0KZW5kb2JqCgoxMiAwIG9iago2MDA3CmVuZG9iagoKMTQgMCBvYmoK PDwvTGVuZ3RoIDE1IDAgUi9GaWx0ZXIvRmxhdGVEZWNvZGU+PgpzdHJlYW0KeJztXEtvJDly vutX1HmBlvl+AIKAfo2Bva3dgA+GT2WvF4vpBXYv8/fN7/uCWcxSliQvug8jCD1TIjPJeDKD ZESQ7t6ffrv7+8md3Cjlnu/DqSV/307/+J+7//jD6W93/oR///jfOzdehNP3u9konH61Duj6 q4HAX737y92f/3Dn7st43AQhlDBaF+dHu+93Ibf7aLWQM0t9lPzoUlwc5fMppMYeGW9SHoCK Q6+QIsre39fT+S6Q4OIzICU32hbf7tMshzB6nLdaGRCtR+j3ecKKARjvDEssxELssY0nRteA UQEL9KYwysbFgFFOxh/LA1Ipg575pg96rEcNwDAh1XLBURtwCHdzLBtVLaAmelscv8aHlY1D 1cS7ekgmgjWlJSySo7BLvqJrSl4USyfiRJpadHjeaXRqHAPh9G//ykH12/j/j0P5f33X/ZvX /b/f/UmGZPwbH/unb0PLxODx++2/T//yy7Ak7fTtzw/h0+O3v959/TZ67AyE734QlqO7h6Hx rQ4yVPMtwT5FIPMN4ssRbPta2SOPUhrk5og+vkJ0OQHw+c7X0TMlQKm0cqne51keqk2Eo1pm b5TawGFwBqOecIihZPYm3lLHE6NnCA3CM0orBplxUKF6443lAWsYzri9gVLUI7iwQQoO1AhH cHW8Fe7gOsuiKlC1ojd4KF5czLL4sxo5tx6UiMEySRkWytCwxyyaJG1RKi2IA2ln0dt5p8Xn jcK7vt+ivp8aAt/YN+F3Zwj8180Q+GEG0gkwRp/YQGatmi1ig41SLQ7blkc5nGLto14r2I01 DxZrLaMUB5JaYQdjBWG1eTIbadVqw4ollgYoDb9W7oGCmzXYYevR+30xWM1FQCKO5gpxAHNz sOGiqHkK1yhtHpZVHDQfR1vxpvKA1fHX3vRq7ZODMCak5DBLCUdysKbCnVxjGTQljwEtWpP3 xoFK4oxlcmxtKQnBmDISdElPWCFTUWOS7lXSJ91TJxdtnXe6e/7zf9fy29Hy048+NkJu5fqj D5+PP3ofHMhOmcPBj2VDsZofghtMpHLytF8pQWBe4slulPAXAvDDdqWcNQ84CCDlPvp2/KQC XVmxUFyqjMkgnqx5xZqNYCoNN0A3R9BE1zBFGBnD9JMQkTc4HVOAyB4TwTD0YojlASkk9tcb /FoPmtcNVkzsQyxjNdgn9rFK7JMmrmaN0gTjbhyobKzNGni2HhSFQZpCEg4JT7ghUNEkMYtW CF8cSCWLss471b0w5b8r+a0o+WCe96NncU9m+cty/+8nGL7fxsqjaK2DzSApgishD7iAusEM qXInAns2GgZY6tzx++spxMZuTrWl5dMRaEjHIm7sZSIWPWO+cVjelQJVXqGNvmKbVDsbhoGw jpoQRdfYzbPb2vLI5RE9TG4cRjYBEjdpqv1qW7YYPfvGBDN4VVPLHZQXptSfgu9ga9fBItrl na7/88E33x4/lAffH8fPx8f/+vbHg53e2ERjSpl0hrLgs5pRtqd6x9EOygvuh5+C70AuCYuD p3JZV7r7AdKwJZiE7dRwpaIU8tPaVNgC5aU118/AdzD7F2yYDgdI8PXR+wf36TI29uuAzmWd kaid2kRltamdveZWre6gvLQL/Rn4jnZBcK8cjY3sfrmxJKJ530jzcUFhNSNmT+iOiR2UF0Tx U/AdiCJgC31sPmg82thUfrkxPlreKMxlQaTKpGhP7Y6TdvminxPGj8XzVAj1eDDcMhS0yaFg jp+WXbVppULr3IHrM76qqeUOymtmkh+N79ZMEgpm1X9+Jtno5De50amaUbanesfRDsprZpIf je/WTPJULi/MJJOwnRquVCRbflWbClugvGYm+dH4bs0khwPkdTPJJFFGaqKy2tTOXnOrVndQ XjOT/Gh8t2aSo7HxwkyykUY7tZGmmhGzJ3THxA7Ka2aSH43v1kxybD5eM5NMCmnUJyJVJkV7 anectMsX/cJM8gPxHM4kB4PhZpRFQmWoaFMNaxvaBMI2ZexrarmD8qqh8IPx3RwKATvLm0Ph 1jQCCRuF0oohUmVStKd2x8kG4OWh8OPwHA+FJxK4OWcoTLCpZhX4lTJswtrXjI4VyguT50/B dzAUesUcczQUDuaM6R+ICb0q/aZjRqv44GpOpGDvH6id7mmb+kpiQzSLDKrW7Fm+tDKxIJUC 9gcwnLOwLnekvTGYi1roYBrloctOJ0V0ihD1SAfGYK17PodPSiuoEjODxf1eIWzNLpHh5TLL M/BstWDmByFp+GAMUoLLdsASjtQgemFOoo80ZUcPlFHLuJNxkdHP+GP5PLgNWw2Ol2Q9Il3R E1Z0zXBEJwobd9OOZVGFFWU0erW6FB+zLA6tRt6tB2VisCgrw0EZEnMMkx6Tt1FKTRgHQdRd dHfeafKFJdO7zt+ozo/2NZlJHOnJBu/LskLbzEGIjUFd+jljsTJco2GUx6CIcN7m4iD+COS5 MCcjdAam8TaExnJSoDgoZF1seYnAct3KnY5oq1Vmeqg9Hc4GqWYyazgqbapwV1FHmmjmzpNW 5puQg+ZP5KqRmsSAO54lYLN2CfGlDUKCC9hg0/IbzsQw9aQmNdZIZxJlpF/lyZnVyLN6QBKC NCUkHJKdcEumokqyFrXQgDgwvUxtnRfNvTD3vWv4TWj44FOPoAMQ9+vvww89ksnqu9YOCmSz huDzWC8ENIxksgZlc0TmhNQQGMgGSzUwlFxgY2rIJBPrENToeKUAaqA3WuXoka2x1WgB1SPm CYn2EpCIQ5ZUuCMpFFXJLKXopfiMjwRBG4csI4xetxpWRGH2GANlg9SwADMcTfQRd8ssG1Wt sDaobYXUkgcrG3eqiW+1lzwEaUpKOCRD4ZZsQdOUuWiVNsSDaemiv/NOmy/M/e96f8N6P3Bb MV44MF8ZBXdoFJh8MoMydQs5xWwRhoE/nRSxHCQGrl7Qg4sUWtDOlkoYtUUPloMMwnC7pGKy xSArcj+wNW0eYQSnNRdhBySdCV8gQeM/BojPRlvIlBMoDsh+EScsIl0FgmYlsTdbJ0aSDEqq BjmRJOLTatDo4DJR9GWSRKqtKG6swow3tQbvc00JOgibcgK+ITnRYPJM02k/yLxELhadnNfK 8/v7d03+vjR58OEmNmjX6/Yb03lnird5Aurm4qdMQ/GSdCiWdxbo+haVdOGCb2oLidZ56hze vCjdBnOPshho7KzCfE7ljheDUassJmFXKZCtnMZdaF7jjtQx/0Q0t01OKprGVUlyTKJ1kidf UFI1yEkEMSuNu0WjgzoEdVkEcfmoojixCpddbEu+BcPkIdiUE/BRdqLCZCrqKOnFW7zo5bwq 6YVJ+l2bvztt3viCB8bX7LsFzBySkh4rkqlvJmlN+yb/IGPNHVWYFjuEtOk75GmxseUqswhU U9/RT4s9dg/TYocIUUyNxzotNlKdIumI/WKxsV0xi63zLeJFayvTuFLC5E12m6wNCjRAyNIK 8UlbRoe0SPqkW1KtonFjlTottngXFEpEsCkn4AtuG3cm0zS922azTf4XvZxXJb3m+33X5u9J m7e+3xCfzMBuySPcqb0k7qCS6R15itU37nS4c3H0AxYclSqNadsZmZildGoCvsRCF0Lk3gCH qgo1h1a5F1rMRLcIYITc7TwDl2AR643sGa/3ELpOiRRkclJ7nk6HlBvzNZXwmk6euBJVjkRX Lq6oiJ5HASJsULe01yKTNbH1auyXYcG7pyY8tddxJiQxIdJz4ZT56wPyF3NUVmmj4wM7KM+Q YW7YJ/meIBtvB8A8qIBfFYMROyTkO8IYg9bS7DAZU86r8+ZvHbtFn7gg7Laz8pB0qtynuSFz Jt1Hpv4sGjvv9LcOicV55kBx7nD24KRQ5mG1QTfPzhQHDn2mj9o34vXcVeKoXKYEpi/WBx3T w2zkPbnOzJ71POSX0Uu5vqVU5v0SKmc7ZcCWiqxdP+Sgna50Who+lUHDKDHjtzp7WnhKqHLs AR948ZQirA9mulKzOZpIZ3VjhGGKLGUeIIS3nVm4Ng4LHVszUsCRu/mqeeBAPu+gLE1pNk2v OP3dZ/rbK9JpuXzG6V+uQXq0tFqeEGqRIyRxXofLj99CjjZyNP7pVmzduMkdml81dt7pb2p4 H5QucQuM+IxPSTWfdSaTqc9MYC5Rqw2fOlU61JLKvc5OIlVa4nFUDEVCk6TwscRm5aywwawl 9lbIgh+wIBXPzYvh4MqFmAvsq1FUuoacaK14Tg7otSRn1ZshKBxMfF6RhcDW9HRuUGqd0CvP YQpn40CZ1HAlZ3Q2DWLSb2XjTDXxrB6ShWBJRsIh2QGzJCqKpqRFqXQgDqSbTWfnRX8vJAO8 6/kN6fkg8p6rBep2U7fzu6l7mes5E2aogx1gZBmoHz0+hAcXHsfPsE+PH/yDy2vM/imUgBmf UIY5Gg+excsZg8ubSajwhl+I9yMRjokF+L8aKXgkSvrjh4zn+cHrgV5+tsdoXh7bfFDsEYF9 XFq2C4D4+KFO6HgcE1t8fgyGzUe+Y3fv9DcAbTIQ86HBDpfm9vtpeftxofoi3g/egdq6UXHF 7mDigN/ZJtiD0Afr4QuhhY8XMSST6edNeAaYTI72zdr4eukkQpeXB3pY2J4ScQOCkaq+ggYi F0E64Q6f0CSU54eXT3OwvHZ4+bAchdHwihmojLIqtYHZuNJD5txU2KedcsfsvZXYlgPHeFoE FPxjeVhagvu8G0GfL6PKXwbAQ1gG3jrww1XnsA0YG8D+s6FblPppFfU6ztZh9iHsxtDHlXmq ZxnlzuS1MOTd/IQWEXF0LYJYR2C4RrAIwU3yFtkuyjIpTA6fGy99Tcgzm/ZJGD6awMiJsftl +STdwxO7M7m4DI5w/U3vwP0/ZL2R9fki/VAffd20vXyPV+PlOQG0OgXwyu+l5WXakMR89sGX x9inBn9ZBvJFRgdGKe6e9U1AU8u0buViNPJufIWL8ZNYTUSHw0qYbJRqQBmSeiXp+dUZA08/ nOfkWbdZ9ZXyrOF6bivL3PZlDqQLT5uhuHy2cyS5p0Mpb0PxaihdzwvTGowNo6OkPu4Gcllt zWUWEV2TIqL7uEmNI7Td0MfFyrvL3BC2seRX2zQ1tU4wBvSGLnTviTIjnlk6/HPGbm+kds9f OUgP7KffWYxlyD6dDlfjui4gqMSBb1lsjFH7ZI5YpmNRaN/ExT4fZ9/GGG0dzZOZoWvFbGEp rKSZ7sVgLbbiSvfS2puncRhKKlWH77h15rl8bITp3OHJfEsQY4a1lZnitqWO9XpS++rcFmOr zs7wE0d19OMRd3Wd0TLeVcCTPGejt3oeGyQfcIrghBAwqTxgxTqfJ8dEALZnVsoGKdULjsRU UuHODL9PqnJkjfRmpq6BCysZd6qJb7Y3eRDSJiniMBkSt8mWVG1SJ72mj1inlhb9nXfafMFf +673N6z3A89ukFPsOlPq05iZDhPUk+NFVGNwJJ7cRzkq+9SRgB7p0Yr3uoxD3kDGsxt9lbz4 InJlUejhO/NiCl6PddLhI3gM4yyHYPkkqhXmk8T7eQGXQbKruQwHL+0y3BH+VaNq5qWKXroc jAv6H8mbeSKTw2LJnnt4Bq29NzcHISXfDENifoowpzDdJYwUBDoDSK2OWomLWRZ/ViPn1sPn CcnkZDgoQWKmXI0ik7jRSl0YD0NDU2vnTX/Pm4F3Lb8dLR989J3y86Bv/9n/cuOjrwy7WK5s 4gEK1VJhaIrhl1QYgJanjNdONAY2IgItcEOXzDCJLpqgz+0uZV41UWH5Uo4M6JBdK3cpQDUO COvRdIEGYXWlsxgW3pBj2Dsc60ZXVxhCFBe7dsRN0ZFDE15tGui8EMTPthyCG5TGUI3g67ot 4eUQ3CjibZxGay/MxiUPKk/urKbIHntIHoI1JSUskqGwS7ZtZtFS6qTY9EE+TE+LBs87fb5g CN41/6Y1/9Q4pKL87nh/na7RbgR7cdFcNvzf7zJDtbgmZ1DA8FZiempiQDPVzMg4AliJWeeJ AT5cyoPQK/Vo91kmXxjGBZexN15715kCCt4iuY65chSBK4SNFTRDdh0PwfhqK0bqmOFT5aqV 3JlzhqgBJwsdH1FfBu4Qou7Md8OaMitxjzFypKsWrikrE1mBWcmuuvkzMkiIcDemQ8/VpuMk xFUzRw4nDIYcca/SmAZ4sWAqmsCYPbDdJgrZ8Yobx9x/H8ixwoqZk0zOlFQEP5kpB5nZBjno SE9mckJWf6UkMCi9au680+NhSDAh+t3wEQ1TwDxe1ZLY0CVnusSsO0uBAPGByuaw6FBEYuQS TFEQhXcaMmqdeHggM3lwlptmPNV0TZt6cP4SLMT6NbyZqRiYSzVw55DtcxjMMv/4bNRmbgnE BRgHL91K+OR476SeU2HWnhe9TUjZRcOQdVcj8WbHOyeNoux4RRJpzYwBiwcrG3ezxvst1YPy EKwpKWGRDIHbJKvL56bEZZikC3IxdTRL50WPLxj/d32/QX0fmPwWaByuNoHR3fJlemmrXR/l zYieyStWHhOcjO6TT+4LvWLu620XnneJacQXkGGLzsijlR5cdx8f5S4blebT43TqjRZtoPry yKAAnHqjrfrgPbx9BuCzZ3Pv8PBrUEQTdMmLCXenVe3d5xDYWP0GCrg0I722g0W/C1FtX1HX cUqkcHzHdXLc/3eeWeap8syN/njVYbYxbdTlZcbQ+M7TUYHHL9aezKH6zhRRnfJofMnjI2Og jFeRiSWXV7XwCxQxkUeuLi+747oMPojxssI7UZnygpdQitKh2niLLVTjUQ/R44MbGxcATSHy gAbWWnwTdY9lJR9IrSrmY+HbzLxZpnB9x6c9Ztp5ottz7olcC3y3QS3fCd4Gx+OmFe8yE8jg I4l6Z4dtmI40Pkym1TBFim9zsmSz77hQ937eEc53De94wnzMkzyMGubFd5Gf8fa2aGOW5tuk hLb5Vuf6muGMTD/ScZ7tbZp320GqgUdsOt9mmohokJ9e/FMnnjvk6jarhcD1SgEdyDnQlpvX B9pWN1qcNHLrGU9d+YG6hbDQ2PA+UBtdtHwahfJ92XiVU4+bVHBAKIWuqS1nq1amcXDRQgsl gqqvSqomqTWCeLGgUSjmVIYTrW21yLuO1SPFTuecYKXKPb9ss5PzkZuRqLQT0YVFkTeCTfxN hw9Z3hhkTZyzhwmEsKakhCXZ7MIFq1PqNvMVTeiiWOoQJ1LTqsDzTp3THv/p9H/sUTFWCmVu ZHN0cmVhbQplbmRvYmoKCjE1IDAgb2JqCjU0MDYKZW5kb2JqCgoxNyAwIG9iago8PC9MZW5n dGggMTggMCBSL0ZpbHRlci9GbGF0ZURlY29kZT4+CnN0cmVhbQp4nO1dTW8kOXK961fUeYGW +f0BNAS0enoM7G29Dfhg+FT22li0DOxe5u+b771gVlJVpdLa6sMIwuxqyMpkxIsIZpAMBjnu 3h9+u/vbwR3cKOWe78OhJX/fDn//z7t//cPhf+78Af/8/b/u3HgQDk9386Vw+GEN0PSHkcC/ 9ey/7/7yhzt3X8bPTRRCCePt4vx47+ku5HYfrRZyZqmPkh9NioujfDyE1Ngi40nKg1BxaBVS RNn7+3o43gUCLj6DUnLj3eLbfZrlEEaL41Yrg6K1CP0+T1oxgOOdcYmFXMg9tvGL4Ro0KmgB bwqjbFIMGuVg8rE8KJUy8MwnfeCxFjWAw6RUy4lHbeAh3s2xbKhaQE14Wxx/TQ4rm4SqSXa1 kE5Ea2pLXKRHcZd+hWtqXohlE0kiS+1seFwsOi2OjnD4l39mp/pt/P+Pw/h//bD9u7f9n+/+ JEcy/hkf++P3YWVy8Pj7/T8O//Tr8CTt8P0vn8Pjw/e/3n37PlosDsJ3P4Dl6O7haHyrA4Zq viX4pwhmvkF9OUJsXytb5FFKA26OaOMrVJcTCB/vfB0tUwKVSi+X6n2e5WHaRDqqZbZGqQ0e RmcI6kmHHEpma/ItdfxieIbSoDxDWtHJTIIK05tsLA9aw3HG7QmMohbBhY1ScEAjHsHV8VS8 g+ssC1WgaYU3eBheUsyy5LMaJbcW1IjRMk0ZF+rQuMcsTNK2kMoKkkDW2dntuFjxZafwYe/3 aO9zR+Ab2yb8XRyB/7Y5Aj/cQDqAxmgTG2DWqtEiNvgo1eLwbXmUwyHWPuq1QtxY8xCx1jJK cTCpFX4wVgCrzVPYSK9WG2YssTRQafhr5R6ouFmDH7YWvd8Xo9VcBCXyaK6QBzg3Bx8uRM1T uYa0eXhWSdB8HO9KNpUHrY5/25Ne7f3koIxJKTmMUuKRHLypeCfXWAam5NGhhTV5bxKoJMlY psT2LjUhGlNHoi7tiSt0KjSm6V6lfeKeNjlZ67jY7uXP/8PK78fK5x99bKTcyvOPPny9/NH7 4AA7ZXYHP6YNxWp+KG4IkcrB03+lBIV5qSe7UcK/oQA/fFfKWeOAgwJS7qNtx59UYCsrFqpL lTEYxIO9XjFnI5lKxw3SzZE02TUMEQZjuH4CEbwh6RgCBHsMBMPRSyCWB6WQ2F5P8Nda0L1u tGJiG3IZs8E+uY9ZYp+YOJs1pAnO3SRQ2USbNchsLagKozSVJB5SnnhDocIkNQsrlC8JZJKd sY6L6W4M+R9Gfi9GvjDO+9GyuLNR/tp0n+Dj8ECJfQH/Vu3HwWoRHuuHTdee1fTmQuVG3/sp /C6oIWCCGMe0Ky+K+LfPvj18KuPvmDJ9efj373+8oJSWN4Rj+XRipMpEtKJdJNkI/Lh7SRlv y+dcCRwlz3Ww9/5rcIgz1s04e5U/M8dYgJ/XDMmeyo2AxE/hd6Ez9IqpyKXOEHx98P6zezx1 hb8dMDH4bXQyDNGpF2LD4J3Hd1sGD3DY6Hv+mBpW6uPFTGfQ4Qx+0DWM5YtDX/xx2L95rhgx DR6uIzeHCE2qjAE00lqYBvrIsU7Ba/QWuRb6hOA5z2/yEKf3rjLkJKJkR/jRVwQnaqeeV5Zj +eUPJWK5Mph2RGCqmDTGbDJUs3/rUvwRRhhLriJ2ipio9sPiJwCERUxMjhGWpaY3Fyo35rc/ hd+FOEt3fAMu/7m/MY/TH8afay5HXXrDGcqOn9UM2Yp6kWihcuPT+yn8LuglderxuV6u+iBM 5usGbDHDMxOlkM9r02A7KrcWQD+D34WpeEH04mIHueCD1kl5Z0TRIMoxTlZWm9ZZLbe36kLl VkjoZ/C7FJKIjG6e9Q2f3a9X1icc+DdoHAw3aKoZmBXoIsRC5TXTlbfmd226ctl9bNOVX670 j5Y3hJw5TEaqTEQr2kWSdvqib0xX3pDPhelKoGs5dxWPoVxxFvLLjLhv3p21zVOlwrHXPuW1 pjcXKq8aTd6Y39XRJGDw/n+MJhOnvsuJUzVDtqJeJFqovGo0eWN+V0eTM73cGk0M2GKGZyYy f77WpsF2VF41mrwxv6ujyaUO8srRxCCaozJWVpvWWS23t+pC5VWjyRvzuzqanPeNm6PJhCZf NaGpZmBWoIsQC5VXjSZvzO/qaHLRfbxqNDGEcuzGSJWJaEW7SNJOX/St0eTt+Fxa/F50FFfi IPLJvubdOkG1zUu5tF8ZLDV7c6HympHkrfldG0n0bfzfR5INJ7/JDae+UEO2ol4kWqi8ZiR5 a37XRpJzvdwYSSawxQzPTGS+fKltBttRec1I8tb8ro0kFzvIC7GRyKhmZRLEQFc7t4o0y1ui BjEh9FK5DzJeLJ7NOBxm6LdGR4FOb5lakPEErwQ3XSqDx30AHW6zZIaPUfMF+0OJ4QpfPAO6 2snxuTPwi1iLz9yLaQge+1wZHMa28vHOZ4Wa2ctyZhAY71q5A+Fxq1GVatERcjFavWgLVlx6 m7y7EAIVIkDczCXe7LBBLDlQBnZIqPKgVPpW48a43md+yEapMpYkHlX48DaDzBNRrawRq3aa JIOVTTrVJLdaSB+iNTUlHtJhPcWxhGrTevWbNfpms739jos1bwyXH3Z/x3a/MG1hNhM4P49X 71MUNrcQnbOkLC46emMqFmqhY76A8pgDdAhSInzTcdQiw5PDX3bP3yGYBskSM1O9GA+NM7AR mRxWZnmmjVkt2MoXCWWAbZRSocjGIzXM3sQ5CR8xZQhynGiZNWJSZLQz+Vg+DmnDVosOplWL yI3kSSu6ZjyiE8LGLQDHslBh0hANryYQkmOWJaHVKLu1oE6MFnVlPKhDco5h4jF9G1JawiQI Qney3XGx5I1R8cPm79Tml6aumSmYZ+5gLF0uuIMQG1OyMjpGLFYOEdOinEeniNh6zcVB/RHM c2FGZehMK8PTEBrLSWleQQlnxWaeSAurW7nT81mtMk9T73O72CjVTGGNR4UHNN5V6IiJ06fj xMpsUUrQBjpI1YgmMV0Ov2lXSe8lZIdsFBKS1Yw2F03GMzHJbKJJjTXiTEJG/CpPyaxGmdUC mhClqSHxkO7EWzoVKulaaGEBSWB2mdY67ix3Y23wYeF3YeELn3oEDlBcx313cdynkNV3rYyU hsYaUsfGOiTgxUgha1AuZmRGZw2BaWgQqQYmghX4mBoyYcaSWKtMSYMCauAWusrRY3q11egB 1SLmSYn+EpTIQ55UvCMRClUyTym8VJ/JkaBok5BlJMHVrYaVVpgtRkfZKDVMx4xHEz7y5j7w hqoV1gbaVoiWMljZpFNNcut96UOUpqbEQzoUb+kWmKbOhVXWkAxmpZP9jos1b4z9H3Z/x3a/ EJmoTIYMzxcDF0f/2HeZJBEp16pExCkiD1XExKkJ1RY4e0ELTlLoQTvf1HEPm/RgOggdMMPE iskmg6xo54tv0+eRRnCac5F2QMq4+AUCGv9jwsbRsIVMPQFxwFpLkrCIZFMompXE1nw7MbPW qKRqlBMhkZ9mg4aD00ThY5aHUFtR0liF+ep6G7LPOSVwkLbTCo6aEwbTZ5pJSQPmKTNrZ5Pj vvJyXPjDkr8vS174cBNfaGfL+Otf7pZ/UbfsEuo0FC9Nh2JZ44FZF0KJGU2B3LQWjknlaXNs I0fZNtjOPIuBzs4qPI2hk1/FaNQqj0naVQbkW079LjD6YRYPzB4V5rbpSUWzuCpJe+J4OymJ RFRSNcpJgJhTztWi4aANgS4LEKePKkoSq3DaxXcpt2iYPkSbegI/6k4oTKdCR03vEhV2djnu jXRjkP6w5u/Omle+4MHxNetuEZs73nXbz5dOfTNNa9g3/Qc5a66owvTYIaTN3iFPj40lV5nF zsilKtFPjz1WD9Njh5gZAhXtWKfHHgsQuL2BI/aTx8ZyxTy2TqdKFs2tzOJK6NYupNt0bVRg AVKWVchP1jIcsiLxybZEraJJY5U6PbZkFxVqRLSpJ/ALbut3ptM0d0XNZ5v+T3Y57o30mu/3 w5q/J2te+35DPBuBLy+oQW7baazbPiq1iu0A6tpzKm821+YB7eJrnz7bN3/y2dhSNJ/tsVWv AnR6nJU+PbbvVBtpdJ3WFO3OgCU5ds6xBo5eTj4bmd3ms5UhIll6O/lsVahVvU1tTyqpGmXa RfxorYmDVhQ+2laorShprJJlccktGqYP0aae0rYNo23aevLZ0rQw123+qOJxb6RXfMEf1vxd WfPKFzw4Xt0Ie2b0khgBSea3cUqo+sZIBSMPjnH8gosKSuOhyYxzUKV09gdopzAEGLm2x5UG hXbDW7kXzngSw5qgETJDhylrCRWxXsi+M0sJTlNntAvOUVFez6Bhyo1HInTcbOiIvBINjmNm XBzRkfZhtwAX2OCu5X1b5FEpGKGxXcYMrHt6Uk/v2xs3YGk4Lnwy//oAY+WoM12NgUtuaDLX NLdqnWXoxtv1Cx4osC+CwQQRjlI0mQLW0uwqBx74rM7bfkkfOk9c0HWLjKBDIblBiQ6RIdBR YgTqZLHjYr99h9gFvx0Q545gLc7pZ14VEbnh2ke5c5Oae0y+ka9nVAgXVWRqYO6l+KBLMtCX vafUmWfXPK/YyGilk3alVJ66I1XOVnX+rFScmfNDD4pUyaaFx0AGhlHSRrKzX7ndTC2XBn6Q xVOLmD1gplpqtkAxcVY3ehimuKXM6zuwW5bN3STahit22+ljz932muhxtGcVHJf0smyau1rc rzpyv2z0ha7dNdy9wzVE5wDf7Xx+i+whifNyhOz5LeRoPUf9n9sCrZs0ucPye4sdF/tNC68n 8UrcNjaRSeCt5rNuROHBQx4fLFGrBZ86TTrMksq9bi7BQUWpx9EwVIkcEn2R1GblrG2/WaPL UYvMD1iUitf+vXhw5UHOBf7SEJWuLies1R9MAu46ULLqzREUdiblECCNiW9zp2KjUuukXnkL ing2dpSJhisxw9nUieUyVTbJVJPMaiFdiJZ0JB7SHThLo0I0NS2ksoEkkG02mx139ruV1fJh 5/dj5wtZLLnaRvsydDu/DN27vS9mveDg3SlVNTABL9aHT+GzTw+f/Gf39WEUsw++PESrul8e PrXPrvJ5w7uu4+dvLA6XxgdFP359+JTxaPwJ43f3OQT8Qurus3cPbdJTs769bwDClQzRGKP1 AJwLxNAXrKZoZ+GFK5HbBBhElGigXsNzrgxiFjurSqfP+xzgwjkt4Y0OlprA6ZqVmVyxJS30 etD7lZlSolSd3f1AHtVxBUne1XXORXnHBQ+GHg1v9ZFPuInhMSBLQpUHrTGNsN+T4xYU3+d+ 6EaJJyONR2JypHhnbvxMVDmyRryZSROQwkomnWqSm++bPkhp0xR5mA7J23RLVJvWidfsEeu0 0s5+x8WaN9YZH3Z/x3a/sCIJms4936O/ejgrOV5gNjpH4o0PKEflPTHFERebRM5idYmL5rFc FzbOsnlhCvYfMy9P43qk0V37fFBmM+a6cZZDsJ1M1Qp3MuP9vLjNKNmVbsaDl70Z74iVgaGa GVHCy8HSpODMmbLZHDo5DE72u8ec1t73NkCTUvLNOCTujIpzCnOgZ4wqcBgjWuVxS4pZlnxW o+TWwudJyfRkPKhBcqZeDZFp3LDSFibDsNC02nGz38tu4MPK78fKFz76Tv154Fs/+1+vfPSV AQPL0ko8EqBaKgyKMnCQCrc+NMfjdSWNS/KIEAEWUCVzga/LCzhbvEs5MfMJni/lyFAExbVy lwFUY4ewFk0Xr5BW10aqceHNSsadudOGq2sBLcTFrqtxU3WU0JRXmzo6L5Lx8112wY1KY5BB 9HVNm/iyC26IeIurYe2FeWCUQeUpndUUU2YL6UO0pqbERToUd+m2zfwtap2IzR6Uw+y0s+Bx secNR/Bh+Xdt+XPnkIoyC4F23ShsV8KUuKAwG/+nu8wgI65XGggYmElMjEoMxaWaGdHlWQvm OyaGpnBKAUFD2tHuQU2+MAAJKWNvvC6xM/kIskVKHXNlL0oMPAcL9yCvg+nXvtqMkTZm4E9Z EiV3ZjtgvcvBQonLasuQE4KrnZkWmFPmeyVcAx8SpQrnlJUpVOCsNCvdGBsZ3kKgFsOh52zT cRDirNnOcwz3z2AZ7uMawwAvpExFAxjjzdsttDyHwt7KrFMfKLECYpmDTM7UVIQ8mZtdmftc OSiZPHNbLKu9NsMYTt1b7rjY8WIwKyFu2/ARDVfADDLVksTQ5XjbcRRtvmUeU4Gx2S06DJEY c4NQVEThXZiMtyamrWamrcxy04inmq73UwuOX6KFKLW6N3NkAnfxB+8csn0OQ1hmvh0NbeaS QFJAcMjSrYRPjveV6ncazN7nBYGTUnbROGTd8Um+2fGuUkOUXWeNZmL0UjJY2aSbNd6LqhbU h2hNTYmLdAjeplldWjg1LsckW1CKaaNZOu7seMP5f9j7Hdr7gstvgc7h2SIwuivBrbHopn3a 87OlimSlPANTjziEnNwvLs0Y1e7M6UKRG0c5zDEnzGiZ8wx7hYdd7Cu/TCVAeaQyNIzw2wth usgNFvrwNUoXHhE1G4vgTZYvFi/D3xMSxeIqw22u4e19oO2LPReFtNW2cN4piKd4nHdUVPBD cfaKOF6mGhjv82m0s3iegn0MKyoGaIFEMipG8pE/fbEIJJjnh/bZB7RFJLKf7AdMe8oq7wOO eRMh1lNccY9UtPiLjyfWQ9b5PCzkfX1os1XYQdXfxzOa6fRLiM9Fc6dAq8w19UJjWVAV0u+Y rmRf7GweQ/7adYjQTRBU/JezcOymwflQ1mwPMGbUL3wnmsomsgC9EVoIZv+THKYEDyqTrlle dp7dpJ4Z6fGkpjOtjj4BxfHvMPKLCuHp1n/k6+v7m4EsRJ7ZE3dQpbq415UzOz6e4G89qox/ 9l/JsPCnOjvfDHxDhfzO1q80Lz3066nX+t03HxLf3X3JYeceTo2t07nJNfqvW7/YCJw+R3fZ tcx9gPlpbT1qZ7XpCPaR/51Am+XjTkWnTihF7D+Y8JzBTgluwtvpdt+vwiLhS92FK5iXPp8o SUzcX3Ze2C37IosUp84RnruMhdw/oOsN1teT9kN98HWz9s6BPOsvLymgbltKr/xcanimr7l9 tDntX3fd+KQhv+v29mJcfuubehYPaZ/F+b5SOI12Uurjzms971R+eiz00WvD0/LNmQDnn81L 9x/NBCldrTMzceyinXmnyHrfyP4ukoXKa+4/emt+1+4/unCjya37jzZoPu5Y2F07BmYFugix UHnN/Udvze/a/UeXL715zf1HEyGvIpqMdC/RRLSiXSRpp3tobtx/9IZ8Lt5/dKkzfLviMjxD DtGd5rdhG2LhGfDVc6oAp+AaPkqbaMsR4mMdM5bC73Q8aa6PRpEP+E5hsbuvHtXhCPDWN8xA QD2YK8WHCzeU4BnoGMjvCx5H+pGuyiDg9Y5LxrD53Yxj03rXWXlo8OngI7cme+I9NbkwYgjB n5hDqKSttnvIJMAnHn3FCbq+e8TQ/BOz/wOP6elhSRbC8uPhmJPdx91D7s6lKjAxzeN+etid Qp94VBECq/TjeOQdr96IiN8/cY+i8hSfGo7+fkiB/wmH8W9uWgb1mPFMQRxXCTbxCC+2MXWl MNI3Cvc/oIKkE4vM+ePTplOCDc9as+1J0Q085R953e/TWBPOzVxpFhnQgScg0TYHZl0Vb3SV PRV5YOEJ/72Te2WkSdbQ9JT/RZpD5kVNhecP8TT6cnpWtP8xb2WOuvlge6rj0c24YmdIJz/r 6andLPbnu6T0cl578mQh1OyjUT6/vGtDcafDGKrhLubG/7TF/O/nRGbFIfmGJzUcr6lilmDi CTCmmaWstFDexZSagt8WyIhWzEpxtD5bGI/krhAksCsoKoMBIl8Y/RTbwkCAAFWvEIWg1giB JYJ6ooRTGXvVbavFrvRFhmCi9sktcMK7X8Qlu268c2QU01DlXAysqb7plD3Lm3CsSepcpiqi Iv/SEehLdeIqlQrPVLaQygySQObZG+64mHEOJH86/C+zZ9lPCmVuZHN0cmVhbQplbmRvYmoK CjE4IDAgb2JqCjU5OTIKZW5kb2JqCgoyMCAwIG9iago8PC9MZW5ndGggMjEgMCBSL0ZpbHRl ci9GbGF0ZURlY29kZT4+CnN0cmVhbQp4nO1dy45cOXLd11fkegCV+X4AQgFSSTIwu/EI8GLg VdpjY9AyMLPp3zfPOcGbvFmZldXj0qILBXWnyHvJePIGyYgg5e794de7vx/cwY1S7vk+HFry 9+3wj/+6+/c/HP73zh/w5x//fefGi3D4cTcbhcMv1gFdfzEQ+Fvv/ufur3+4c/dlPG6CEEoY rYvzo92Pu5DbfbRayJmlPkp+dCkujvLxEFJjj4w3KQ9AxaFXSBFl7+/r4XgXSHDxGZCSG22L b/dplkMYPY5brQyI1iP0+zxhxQCMd4YlFmIh9tjGE6NrwKiABXpTGGXjYsAoB+OP5QGplEHP fNMHPdajBmCYkGo54agNOIS7OZaNqhZQE70tjl/jw8rGoWriXT0kE8Ga0hIWyVHYJV/RNSUv iqUTcSJNLTo87jQ6NY6BcPi3f+Wg+nX8/8eh/L+96/7N6/7Pd3+SIRl/xsf++fvQMjF4/H7/ z8O/fBuWpB2+//Vj+Pzw/W93X7+PHjsD4bsfhOXo7mFofKuDDNV8S7BPEch8g/hyBNu+VvbI o5QGuTmij68QXU4AfLzzdfRMCVAqrVyq93mWh2oT4aiW2RulNnAYnMGoJxxiKJm9ibfU8cTo GUKD8IzSikFmHFSo3nhjecAahjNub6AU9QgubJCCAzXCEVwdb4U7uM6yqApUregNHooXF7Ms /qxGzq0HJWKwTFKGhTI07DGLJklblEoL4kDaWfR23GnxeaPwru+3qO+nhsA39k343RkC/3Uz BH6YgXQAjNEnNpBZq2aL2GCjVIvDtuVRDodY+6jXCnZjzYPFWssoxYGkVtjBWEFYbZ7MRlq1 2rBiiaUBSsOvlXug4GYNdth69H5fDFZzEZCIo7lCHMDcHGy4KGqewjVKm4dlFQfNx9FWvKk8 YHX8bW96tfbJQRgTUnKYpYQjOVhT4U6usQyakseAFq3Je+NAJXHGMjm2tpSEYEwZCbqkJ6yQ qagxSfcq6ZPuqZOTto473T3/+b9r+e1o+elHHxsht3L+0YfHyx+9Dw5kp8zh4MeyoVjND8EN JlI5eNqvlCAwL/FkN0r4GwLww3alnDUPOAgg5T76dvykAl1ZsVBcqozJIB6secWajWAqDTdA N0fQRNcwRRgZw/STEJE3OB1TgMgeE8Ew9GKI5QEpJPbXG/xaD5rXDVZM7EMsYzXYJ/axSuyT Jq5mjdIE424cqGyszRp4th4UhUGaQhIOCU+4IVDRJDGLVghfHEgli7KOO9XdmPLflfxWlHxh nvejZ3FPZvnTcv/vBxi+X8fKo2itg80gKYIrIQ+4gLrBDKlyJwJ7NhoGWOrc8fvLIcTGbk61 peXTEWhIxyJu7GUiFj1jvnFY3pUCVZ6hjb5im1Q7G4aBsI6aEEXX2M2z29rykssjeq7yCjQz IHGTptovtmULrXPdFJPjpm5XU8sdlBtT6k/Bd2Fr1x1bQBarrv/y0TffHj6Uj74/jJ9PD//x /Y8XdnpjE80NpdEZyoLPakbZnuodRzsoN9wPPwXfBbmkxi3/uVzWb2A/QBr9AkbYTg1nKkoh P61NhS1Qbq25fga+C7N/wYbp4gAJvj54/9F9Po2N/Tqg04lhJGqnNlFZbWpnr7lVqzsot3ah PwPfpV1QpEPl6djI7tuVJRHN+0bamIJOKKxmxOwJ3TGxg3JDFD8F3wVRBMcWl8wHjUcbm8ov V8ZHyxuFuSyIVJkU7andcdJOX/RzwnhdPE+FUC8Phq9XDIVsMh18m2VnbbNSCYRtn/G+ppY7 KC+aSV4Z39WZJGA98P+YSSad+iYnnaoZZXuqdxztoLxoJnllfFdnkidyuTWTGGE7NZypyGz5 vjYVtkB50UzyyviuziSXBsgLZxIj0YyUobLa1M5ec6tWd1BeNJO8Mr6rM8mFsXFrJpmkyU5N 0lQzYvaE7pjYQXnRTPLK+K7OJBfNx4tmEqNQRt0QqTIp2lO746SdvuhbM8nr4bk8kzwdDFej LBSqr3mZ5FXb0Lq0Tuu7mrXcQXnJUHhtfNeGgr6Nq0Ph2jTS8kYhtTIRSUWToj21O042ADeH wiviuTAUsAF+KoOrs4YCBZtyVpGfqcOmrF1tUrJCuTF9/hR8FwZDrwwjXRgMF2aN6SGICb0q PadjTqtYvNWc+EXuPQS100Ft26iS2JDrH4ZVa/Ysn1qZWJBMAQuE77BU+qX6mN6GKEqmZwo1 X+B6TvQq+OLpK5KT2OdOnxJCsz7Tzdvgl/K50u8EOo53PsuLRc9TzvQvcVyo3DECjluNMSn1 6PD9GKxeFN0Rlt4m7i4KQVV2jsFn0ZsdYk/iA2XQDg5VHpBK32qMuak9Q88bpJrgWROOKvrQ mv6rSVGtrJFWObHFg5WNO9XEt3pIHoI1JSUckqFwS7akapN69Zs2+qazVX/HnTZv2MN3vb9h vV8wRUyUAOZ8NkF/WdZqm1mIzlm+BzcYvTHLA7XQMUmgPOb7Tu9lhGk5jlqkZ3Osq7vnczCm rVWJmVkk/V65LXJgROadlFmeGSlWC7bDRa4KyDZIqZBlwzE2KH5iTqKPNGUwcpzUMiBtXGT0 M/5YPg5uw1aDRzZZj8gY1YQVXTMc0YlC4I7esSyqsNWMRq+2neJjlsWh1ci79aBMDBZlZTgo Q2KOYdJj8jZKqQnjIIi6k+6OO03e2Eu96/yN6vySwyMzu+upOXCXzEGIjdkeDIDEYmXETIZN zWNQRER1cnEQfwTyXJisFTozVvA2hMZyUgZJUC5LsX0nMk7qVu60fFarTAFTe0aiDFLNZNZw VFhAw11FHWni6uc4aWUiGjlo/kCuGqlJzMTBswRs1i4h8LxBSIgNGWxukAxnYv7KpCY11khn EmWkX+XJmdXIs3pAEoI0JSQckp1wS6aiSrIWtdCAODC9TG0dF83dWBK/a/hNaPjCpx5BByDu 92KX530yWX3XlkIZLqwhK2VsIwIaRjJZg9K8IpPFagjMcAFLNTDHpMDG1JBJJrYnqFVmu0AA NSCHxcrRY3m11WgB1SPmCYn2EpCIQ5ZUuCMpFFXJLKXopfiMjwRBG4csI7+mbjVslMLsMQbK BqlhOWY4mugj7pZZNqpaYW1Q2wqpJQ9WNu5UE99qL3kI0pSUcEiGwi3ZgqYpc9EqbYgH09JJ f8edNm/M/e96f8N6v+DPZiLBwHw2+3+9aBSYleYi14UR2ZyqRCR2ROZrx3RQKsMgMXD1gh5c pNCCdrZUJrkterAchAzoRbFissUgK4pwsTVtHmEEpzUXYQdkowpfIEHjP2aOHI22kCknUByw 1xInLCKPDYJmJbE3Wycm7RmUVA1yIknEp9Wg0cFloujLJIlUW1HcWIWpsGoN3ueaEnQQttMO jpITDSZP0UYpi2LJ/qST41p53vH3rsnflyYvfLiJDdoLt/GdiSDmIKxbFgllGoqXpEOxhNTA 7ApRiRVNAd/UFk5g5KlzBIyjdBssAs9ioLGzChO9daikGIxaZTEJu0qBbOU07gK9H6bxwMQ0 0dw2OaloGlclKfaN1knJIoKSqkFOIojpqtwtGh3UIajLIojLRxXFiVW47GJb8i0YJg/BppyA j7ITFSZTUUdJLwkJi16Oq5JuTNLv2vzdafPKFzwwvmg5TmAzul232L1k6ptJWtO+yT/IWHNH FabFDiFt+g55WmxsucosdnouVYl+Wuyxe5gWO8RMF6hgxzotNnIgI+mI/WSxsV0xi62Db+JF ayvTuHJFFXF0m6wNCjRAyNIK8UlbRoe0SPqkW1KtonFjlTottngXFEpEsCkn4AtuG3cm0zQj oGazTf4nvRxXJb3k+33X5u9Jm9e+3xBf5jkjuBlpjDoDlqfNRjiAsvZcypvOFTygXnzt02b7 5k82GyFFs9keYXkVINPjrPRpsX2n2Aij6yCYYHc6LImxc4016OjlZLMRvTSbrWwQ8dLbyWar QqmqNaU9oaRqkKkX4aO2Jh3UouijbkW1FcWNVbI0Lr4Fw+Qh2JRT2sIwpMJkKuqqzqhswe5F L8dVSS/4gt+1+bvS5pUveGC8uvc9U3pJ9IAks9s4gFB9o6eCngdHP37BGejSeB4r44hFKZ3j AdIpdAFG7u1xWrpQb2iVe+GKJ9GtCRgh03WYsrZQEfuF7DszkmA0dfyz4IgG+fV0GqbceBBD J1mGjIgrUeE4wcLNEQ1pH3oLMIEN5lrWt0WewoASGvtlrMC6pyX1tL69MQBLxXHjk/nrA5SV o46LNDouGdBkVmlu1QbLkI23k90eVCAugskEHg4cZMBiCrSWZqfEeZasOm/xkj5knrih6+YZ wYBCrgT8LG7InKfpoqMH6qSx405/64BYnN8OFOcOZy2OAGeeQo8MuPZR7gxSM8bkG/F6eoVw Bj5TAjOW4oPO32Mse0+uM4/FeJ7ez+ilQzylVB7oIVSuVnW0pVQcx/FDDvJUSael8RvOaZQU SHb2lOFmSrk04AMvnlLE6gEr1VKzOYpJZ3VjhGGJW8q8GQDRsmzmJlE33LFbpI8jd4s10eIo ZhUct/TSbJpRLcarjoyXVZyT4fYX13pwD9E5wXc7+tsiR0jiuhwue34LOdrI0fhnWKB14yb3 wIyck8aOO/1NDe+zzUrcApvIJPBW81mXLfBME08mlajdgk+dKh1qSeVelyLgDJTE46gYikQG ibZIYrNyVthv1mhy1CPzAxak4hW/Fw7uPIi5wF4aRaVryInW6g/GAaMO5Kx6MwSFg0k5BEgv ZGtGKjYotU7olRcsCGfjQJnUcCdmdDYNYplMlY0z1cSzekgWgiUZCYdkB8ySqCiakhal0oE4 kG42nR0X/d3KannX89vR84Usllwt0L6bup3fTd1L7ItZL1iInBLwAhPwwreHD+Gj+/TwwX90 w0Lx78zf4ir/bmyhN/3BGjuk7OHJ48OHPN8G/i7PQ8CvT+zg3UP7GNrDbM66tT4DGWYfA/m4 gREJPi69BEd0hO05GoKC9uCTdfXOPxK4+0qWwqmZuohCPE6TpeiuJanGGG1U8gBj6Bp/5qTF uGTyA0MXmNiU/KCRXJgWwfQMHmCXZ7Xw+DqmFS6VeIDd0iW4hLQyEz62RIpeD2pfmb0lSNXZ UXfiqI67WuKurnN9zCP9notNo7f6yDcMrHgsEsShygPWWNrY8+QYFmN7xmg3SKmecCTmWwp3 ZjBqUpUja6Q3M5EDXFjJuFNNfLO9yYOQNkkRh8mQuE22pGqTOuk1fcQ6tbTo77jT5o29z7ve 37DeL+ySgpaY9TyhP5TLWdzJ8b6mMTgSD7ijHJWLxbRL3OMQubLWnRVaW3Ov2rjy5/0QiIlm 3hXFPVLjFOLzQWd0sP6OsxyCRVdVK4yuxvt5T5VBshusDAfvtjLcEbsVo2pmaYleTuDGBVfz 5M3W9clhwrTnHutsa+9t0UBIyTfDkBitFeYU5uKDfrPAqZXU6kSSuJhl8Wc1cm49fJ6QTE6G gxIkZsrVKDKJG63UhfEwNDS1dtz097wZeNfy29HyhY++U34e9O0/+29XPvpKJ4ZljiWeMlAt FTpq6cxIheEYrTt5O0OjmyDCbYFNXcl0Oug+Bq5g71LmjQwVli/lSPcI2bVylwJU44CwHk33 TBBWV3DXsPAiGcPOfG6jq2tTL4qL3c7hpujIoQmvNg103pvhZ1sOwQ1Ko+ND8HUrlfByCG4U 8dJKo7UX5qaRB5Und1aTn5s9JA/BmpISFslQ2CXbNnPKKHVSbPogH6anRYPHnT5vGIJ3zb9p zT81Dqko2xHU7oOX7YrrFPexZcP/4y7T8YnbZAYFdBYlJmslugdTzfQy8/wHczAT3WU4OQFH JvVo1z4mX+gUBZexN94O15kQBd4iuY65chQlOsODuaCQa8KUcF9txUgd0xmpzI2SOzMwsAfn ZKFkavWlGwwO387sD6wp872SwEEfkrcK15SVaV3ArNQvXZAZ6XKD8xjToedq03ES4qrZzpgM 808HHq4fGtMA799LRRMYfeDbpZs8G8PRykxYH8ixnHSZk0zOlFQEP5kBuMzYWw5KcM8M1WX1 V4COLt5Vc8edHq9MHAqqFQTjz466DbJ8eYh97FXd57EjLR/dF5fGXpT71subzATfdMNHOUwL s+RUSxKL7hbbjtwowJh5FAeDh8OsQ7GJfkUIiYItvEqQPuXE1NzM1JxZbppBVdPtaOrB+VCw 4InX58I8oMBMhYE7h2yf1xAes/uORm3mFkNcQJDgpVsJnzCve9RzDgBrz/vVJqTsomHIuiKR eLPjVY9GUXa8mYi0ZnpoxYOVjbtZ47WS6kF5CNaUlLBIhsBtktWdb1PiMnTSBbmYOpql46LH G5PJu77foL4vTCEt0NicbSqju+LAiwxl5TBnnDD9d86bKyus7rvlLO1TKAGsEsqQx3jwnOMw MuRDC773G/rPwGsuuSK/oFxwtGdl9cdtjjs8gf8tejOG4/HYXvO1HHXTMyh/XIwhnQDLK2l+ wegf4fUzv+GC/svDhzbBVDkGw8ew+gvlAqyrf5E0T/GVhVIVjYHHhxxwJcyz0uU8+puk6zEn PuOVNemuPstVoKDdr/7XqQY0LyfXaLFHmwt3vmgnAENMdULH45jOJXES5KYlc5j6neou+GM/ nXuH7Ul44nt2q/M5n7N7Gncrv4t/Wq7nPlj3XwgtfDqJYep4GayLui+MnhOhy8sLeljYnhKB O9lIVV9Be+LB1hj9jCahPD+8eFz3twyvvl5qpNEVMzAZYfXkio+7DyStLvnPO92W8efTJsdg 48ZYWuQTPBY5n3YSz7sB9HgaVH6JPYRl3K3jPpx1Dtt4sfHrH1fnv1rsIgz/XIgj7Ab5PuSQ LbRwihdMEdnKbhPEeahkH/A4CcFN8hbZLsraxS0enx0u3P7slU+Ubov4iBNj98vyRU6ruoh/ cnEaHE8CPjtwv0HWG1mPJ+mH+uDrpu3lczwbL88JoG4xshd+LjWcT3TLsp0S/7YM45OELlik uHvWN/FMHbdlonxhoMx9vDyohGlGrtb4WT2T8/zmltl0/9k8J00m2PwWaea2bJFtaivL1PZl DqQTV5uhOH22cyS5p0Mpb0PxbCidTwvTGoQeHGX1aTeQy2prri1miO7TJjeO0HZFIycj705T Q9hGk19t09TVOr88uyv0y7GJeYmPHZawC2piVEBDt7ic1exYxQrlJZcGvTa+a5cGRQaV/plL gyaFvL9nIlJlUrSndsfJBuDmpUGviOfKpUFPZXDj0qBNOavIz9Sha3vOakbJCuUllwa9Nr5r lwZdHAzPXBrkozbKnqmpnud9MxPKzi4N8lX/xELiXhsXrGAHGpksiZw9T7eaRvGppYnmjFIH v110p01S2BZaMirDKPdhBWSVRqWNT36atdGiucfx8XN+h1UbbdUH72HuDMCjZ/MxHcBABO38 vg4rIYMEy2VVe/cYAhur30AB6xRpgIcR8hhSp29parvr3gfkqv3AhdgMzXaKj0M8Mwb7w/Jh 4dGry8uMXfYPHuMOPCe69mSy6A+eZdFx1MaXRdfNjOGELLr7tLyqhc4MERN5Nvz0sju6zJmF fIgVgePK3D68hFKU99nGW0S3Gs+kip5haQ4pAGgKyJlDVmTQm6ib+Cv5QA5psfA332Ye8GGu 6g94SQ7VzRupPN2CkW7aH+YfUFgbb3F3VoZrdrzLzJQtdk3Nn+2KgEj/y3gbmD/IXFC+zcmy an/gnwS5n//KEd81vOMNWYfMo/YlzKu7Iz0i29uimFmab5Myd+dbXUDQDGdknqXOHW9v07yd G1INPAvc+TbT2xIN8tOrS+vEc4dDRc1qIdCVXNq9/okZRUN51Y9FIaNtqCOjgvHQdZBB96gX XbZU6Pjn6KITSaNQaQk2XpVvwfULOCCUwqyBLTm1Vuar0Z9MZ48Iqr7q9BdJrRHEiwWNQjGn MvIb2laL/Nda1CPFzrwJwcLtRN2wwBHlDXuOyq8TXfBXeyPYxN90SwLLG4OsiXP2MIEQ1pSU sCRz1DGW4HTGjInZJnRRLHWIE6lpVeBxp85pt/90+D80N7WWCmVuZHN0cmVhbQplbmRvYmoK CjIxIDAgb2JqCjYwMDcKZW5kb2JqCgoyMyAwIG9iago8PC9MZW5ndGggMjQgMCBSL0ZpbHRl ci9GbGF0ZURlY29kZT4+CnN0cmVhbQp4nO1cS28kOXK+61fUeYGW+X4ADQH9GgN7W08DPhg+ lb02Ft0Gdi/z9x3f9wWzMkullhboOYwgzK6arCTjyQwGI4IZ7uPpt7u/n8IpWKvOep9Oo8T7 cfrHf9/9+59O/3cXT/jvH/9zF+xBOn2/W4PS6ZtPwNRvDgL/6tn/3v31T3fhvtnPQxBSSza6 hWjjvt+lOu6z91KtbE1rRZvSQrb2+ZTK4IyKJ6UaoBYwK5WMdoz3/XS+SyS4xQpIJdjYFsd9 We2UbMZ56zWD6DPSvK8LVk7AeOdYciMWYs/DfnG6DEYHLNBbkrWdC4PRTs4f2wapNaNnPZlG j8/oCRgWpN4uOPoADuEegW2naiT0RO/I9tf58LZzqJ541wzJRLCWtIRFchR2yVd0LcmLYulE nEhTOx2eDxpdGsdCOP3bv3JR/Wb//7Mp/29vun/1uv/17i8yJPafvewfv5qWiSHi79f/Ov3L L2ZJxunrX9+njw9f/3b35avNOBiIOKMRVnO4h6GJoxsZ6sVRYJ8ykMUB8dUMtmPvnFGtVYzc mjEndoiuFgA+38VuM0sBlE4rV/p9XW1TbSEc9SpnozUMh8MxRiPhEEOrnE28rdsvTo8JDcJz SjsWmXPQoXrnjW2DZYYzb0+gFM1IIW2QUgA1wpFCt6fCncJkW1Qlqlb0pgjFi4vVFn/eI+c+ gxJxWC4px0IZOvZcRZOkLUqlBXEg7ez0dj5o8cdG4U3fr1Hfjw1BHJxb8PdgCOKXzRBEMwPl BBg2Jw+Q2bt2izxgo9TLZtuqtdMp92n93sFu7tVY7L1ZKxuS3mEHcwdhfUQym2nV+oDHktsA lIG/3p6Jgls92GGfMed9c1gjZEAijhEacQDzCLDhomhECtcpHRGWVRyMmG2seFPbYE38609m 9/ElQBgLUgnYpYSjBFhT4S5hsA2aSsSCFq0lRudALXHGNjn2sZSEYCwZCbqkJ6yQqahxSc8u 6ZPupZOLts4H3f349X/T8uvR8uOXPg9CHu36pU+fbr/0MQWQXSqXQzS3oXkvmuCMidJOkfar FAgsSjw1WAv/QgDRbFepVftAgABKnTZ34k9p0JU3G8Wljm0G+eTDO3w2guk03AA9AkET3cAW 4WSY6SchIs84tS1AZNtGYIZeDLFtkFLhfD3BX59B87rByoVziMW8wbmwm5c4F030Zp3SAuPu HKjtrK0eePYZFIVDWkISDglPuCFQ0SQxi1YIXxxIJTtlnQ+qe2bLf1Pya1HyjX0+2swWHu3y F3f/7ycYvt/M82jydXAYJEUIJVSDC6gbzFQ6TyKwZzYwwVLXib/fTikPTgvq7UY+XoGO1Jw4 O8tkOD223wS4d61BlVdoc+w4JvXJgckQdusJUQ6D0yKn7Uc62qNNmzyQNWjGlju9TvW+uQ+a xqTflBLWyVVPIw9QnvOofw98tzy6zMMhZHHUdQ2/PGHeuVQ30ux1uqDwnhNzJPTAxAHKM6L4 XfDdEEUKHHEtiv94H8fDu2Z/40zh4T+//vmGUEbdKLTD8gWROouiI7UHTjYA3+5+JIyfi+ex EDreu1vL4eMTi0ErjOGKbZ2ytymggLRtZR57GnmA8qL34ifje/K9SLBu/9x7sUiT1Bdp6jkx R0IPTBygvOi9+Mn4nnwvHonixe+FU6gl6ojUWRQdqT1wsgF4/r34eXieei9uLIf9eyHOsRTs 7A+fZNoOaqpplb4KerHhMFK4z0Tbeyo9Bu7cddLLQLAuVjr+A55KrJ2eSGEQMVb5NfRFaqXH gbHengjDnbceoxSaMeENOKzZdN4XljkW7ikKQVUNgeFI0VsDohHiA23QDg7VNkhtbj1GYTSe wcgNUi/wtYSjiz6MpkezKOqdPdKqY4148LZzp5741gzJQ7CWpIRDMhRuyZZUbVLvcdPG3HS2 19/5oM1nXsk3vb9ivd8wjQydA3O9Ohp/vmUWcgieASh0Rwfj/uilCZuEtm06k/5sDgom2skd vm6yVuTvYCzNwAxHZV5herZDbmBmJqKt9spReC+5n4DsBch2SKWRZcdRBnYIYS6ijzTVwMOK U8sQpXNRMc/5Y/ts3KatBx+9+IzMqMWCZW6448hBFAJ3joFtUZVjZA/0oj2cj9UWh94j7z6D MnFYlJXjoAyJOadFj8vbKaUmnIMk6i66Ox80+Uxs7E3nr1TnN/JkdvRFvu+xOQi3zIEdfBn/ 55E4N2/jFG02tdqiyIln6wDxZyCvjem7NJnDwNOUBttFOYWk7EZzfxc5iL61Jy2f9zqTghrP 2IRD6pXMOo4OC+i45QKJpo4k5nnRytQkORjxRK4GqSnMzeC3Amw+riAUuUEoiBY4bDpmjrMw o7GoKYM90llEGelXe3HmPfKsGZCEIC0JCYdkJ9ySqaiSrEUtNCAOXC9LW+ed5p5Jlr9p+FVo +MarnkEHIB6PA7f3faYkQuYWkJHKUycjqpeZrM/lpDiWWaNEQ4UZtEcU1uRIlRG4fYPlR9qD GUJvFrf77CgkwNFkjzBSkHkl7IRUpPAlEmT/Y9jw7LQlaEcUJ7hV4oRNJDFgj9kpnM3RhRkb h1K6Qy4kifhk+J0O7giir5IkUu1NceMd5kE1Gryv7QN0EHaQs0bJiQaXp2ijlEWxZH/RyXnf +fEx802TfyxN3shmFQ4YL/TYJwt/FHCj9NShTFOLknRqno2E/FMTlQyrgm9qC+U3dekc8bUs 3SYPWbKJ6efVYZZfFUXNYfSu1ChhdymQo4LWXeJBxzWemJUQzWOTk5qucXWKgoWJmQWCE5TS HXIRQcxV0jF0OqhDUFdFEHcKNcWJd2hhOZZ8C4bLQ7ApJ+Cj7ESFy1TUUdK7CO5OL+e9kp7x xd+0+YfT5hNvsGF88c67AoOSHjuSaRwu6Tgv9jolGWs6T2lZ7JTKpu9Ul8WGd9VWczJIoU6O y2Kbo7AsdsqV0Q7Bzn1ZbCTAMunI82Kx4Zm4xVbVo3gp4WKx1ZFMOVqydijQACFLK8QnbTkd 0iLpk25JtZrOjXf6stjiXVAoEcGmnIAvhW3duUzLCrK6zXb5X/Ry3ivpJe/vmzb/SNp86v1N +QeH5Cu1NxyoOx0R6B3Z6x4HC4NYvBJ45G8ooG2DxTwV+fnWJjWBsEHjaQEeTGepbaPmMKrO RotZeAICjFSnV7nRBcvwN2qcTJpA6KodbMjvK+LI80Wpg1l8lUGUUySuQpWj/IHOFRUxqzUg wgF1S3sjM4WPEOzgvAoLPiM1Eam9ORirZX0BHafKvzEhhluzag0GzziMfTKJVwfOf3EWyCZ6 WXCcXgaNxYiKA2TBYYxBaxteYsxCpB6ih1amybzQIaTM6QCapAtWU8/BZM5SrIzAzF5j54P+ 9ktid04OoLhOnOtQP1pZwpwZm53WnoxnMxwVB/HGzCcJ+06kVBV2iUnF29iNYiTXlTUVkaXf FbNUAdJaZzUIoXK3U11E66jliCYHbll30mkblZH3Yi3FnIP/ysg0pdwG8IGXSCnC+mCna736 mZJ09mArDFtka6usHIE11mb4Omw8w66gIFfuFpZiGZrCWynwSCDNlhUAY2jrzNBaR5EF3Wfc CaEPMrMXW7BudGSukMJ9Had7vgs1+8rR+mcEYUznpk5ofq+x80F/S8PHgvCWtxgokg7Re7Gq Up8FMSxraVneRiyTKjW1lHavinoU0Eg8gYqhSGiSlMWU2LxdFSFcvcLZik7yBRakFhXqFw56 LsTcYF+doja15ERrjyfngAEKctajG4LGxaR0AzKgHM2gxgal9wW9szpfOAcXyqKGnpzTObSI Sb+3nTP1xLNmSBaCJRkJh2QHzJKoKFqSFqXSgTiQbjadnXf6ey4B9qbn16PnGwmv2j0mf9i6 Q7x9DyTn7AJkoVaaEpXHIyBChvQT96BePKQvoTcG+5l0YKGuggiNZbqwgNzVWajrSQCWu3ib aYwtPTD7SeM7c5KC1IOX9BJHD3TgiLuHyTAJS5dj5P4tenvMfAJM2A3N5pJDtQ2W7cL+ewEm H8/I4wap9AuOgr+Ou0a2naqa2SO9lekJcOEt50498c3xLg9C2iRFHC5D4nbZkqpN6qTX9ZH7 0tJOf+eDNp9x1N/0/or1fsOlT/KG+vX1sNRuG4YSeC/NFkdhIS/aWRlGFhOgXj3TCVRtvtxA BjIHnVTWwaNOv/JOHN35QWsXK2v5O13FvNpJNnD1Guvg8/26j+eQ/Kae4+AdPsed4Vg7VSv3 KHq51zgXdDzJm7ugJcC2++8RLqGPj76/EVKJwzGUFNyO20EvrX2SR8TEXYDUloRDg7hYbfHn PXLuM2JdkFxOjoMSJGbK1SlyiTut1IXzYBpaWjtv+vuxGXjT8uvR8o2XflJ+EfQdX/tfnnjp O8/bng9FFfz0XmmMSfDcXRojj3KRWIU+eKLNOGHj/NEqz8eqO6ezdVcqK887LF+pmSd5suvt KQWoxwXhM4bq6QlrKo/hWHhhxrGzSsnpmjp/iuLmtxDCEh05dOH1oYXO+wFxjeUS3KAMntEF X7fvhJdLcKOIl/Od1tmYcSUPai/uvKeQDmdIHoK1JCUskqGwS7ZjZUopdVLs+iAfrqedBs8H fT5jCN40/6o1/9g4lDa3uoNjnH48EeXDvdPq+L/fVcbocGvGKGBcA2GwyhpBtCtDoqxqZGVB YWQH9YCIuVGPfr29xMb4HbjMc/AWLDIpnbxlcp1r5yoCV4gXKlqCtCoLnWJ3j5E6ZtxMScpW J5ONOC5ys1CJkOYyYoPY5GSiEz5lVcaWwdGeMlM+0GFnIDbzcNr9QwCZ0SHEObEdRnqbgZsQ vWavnDTzz1gTrlnZNsB7xqVpA2PYePu4ACs+uVpZ3xETOVY8qXKTqZWSyuCnMtZcGWauSWVb lVHpqvmKRTMaudfc+aDHJzYOxY8b8k5XBeVGVmwPeb4Pn8LHWB7a+/A5lPDlob4P6VJiftxW EEYdeCnNtAyW3LJXJBbdodwKSRVLrywwxeLhMptQbGEIDEKiYBuvTDP8WVhwUpmFXu2hHVQ9 3QLVDO6HgoWgsV4XprwTk3KGu6bqr5cJjwU6Z6e28oghLiBI8DK9hVeY19r1OxeAj+c90gWp huwYqq6CE28NvNLuFNXAG1iktTKYKB687dytHq/PawblIVhLUsIiGQK3S1Z3W5fEZeikC3Kx dLRa550en9lM3vT9CvV9YwsZicbm6lCZj2minVlh1qWmteMgoE+rEuLDuwT7YX9yKA/v4vtQ L8bkFpQEVgnF5GE/HGNc134wAnO04ItQ4Y0fgTcKYQsT+D89vDNTRnvW1Mkx1ofxPqaHd/a3 YXBO9oMITQND2YwhfODTbE/TMwxwq/qnGIjYdo4MmCMPwX3YM/DFZYmfxNncWHJW9XBxiuEN /OiHFjr5yvY3rLEfHNAmoLGghYvKKAk93uP5qFGfMHmJWkgCNo8PjwaRXieV4EjLIkK/jIdY XE0ariG+D22w1n4VHbTQOOzPwRnYZi3o0wn9qHFQ/H5Qc5xhE/CS+w0B7wX4YQf1g3Czkz6Y /HPh+E8/XDdzf/HP3569AD7sF2IC7uJErR/3ZG1CThs9IvfyFopf19Zlrd9eVEuDac/hNdOr vV8p01lPJvv02UXyIzmMvuTwwteHTvRRcLnyjRYFXTLCe5AX5duSXXrS302SWMer9Xh5XZ5c y/vCbcjR37PdwkkRbtVeWfWgWy7svEfF52Zx1ut5teyv1oG/PGtVfLx+cww/nutVeMFUZ77u Gcnx02Y0NmZdlDtjc80Yad8bW3qaetkwa78OXb4/XCZ9y4S8cJn0dL1H7DxekvzLjvAfvvj5 8NvcmFhmc+z2GIh5M6gcddhXwPrHa1ulZfLpYixdV1ofjqRf6DxI2Rl4rKzbt0STKjW8rlb1 617E6dXsOSv6rMj+Vc/LPfdQnvuI3e+B79aH07LnKer1SSfF/hD5yt8Wia4oLxJ1Z3eh8p4T dST4wMwByksuVv9sfE9drH4skmcvVm+kxbxD4T0n5kjogYkDlJdcrP7Z+J66WH1zdbzoYvWi kHecFyJ1FkVHag+cbACevVj9E/E8cbH61nJ4/K2RmHXAQ/wGt2sZG2LNztVnP2LXJ9AKz4i4 7oqTU2ZFKcqiIsNBUtllpC+KI3kT1F88+7Rt7YnGL8F5lBGmCYSNC5/M9r7jprZcHXs27OfP D/QE4MvasC8YtD1vmJhG+BJmJEg9Tmh+sk0rYtNK3LMGoyO+LdCBpKnFnH2Q5IaFXbXPh6+E XH1BRDbuqudfjNhDeYmF/dn4nrKwNz/a8ZyFdeBeTnr4QMTVxyOcqGPPPxawh/IikfxkfE+K 5Nb3Gm6IZOpiJirEvuMbRswyT75RfMUr08n2aCI4iOBk3z2sCBh85z2rdOr8VtHlIUs0v7MC PZurlPjG/XrXdB/chIDaNXpR61FvjMuImMzLW5eHMzD6j0y3PezIgXdW1OFhDCw61yeBmKgb 9nRxYpb2VBKAloRKNdQiJj3J+nhaJx+o3GyeyefTyrJ8Voh+R8Dn1ImHzxjhzIw4f/dQhzL0 eJoCL652PKusT21+j/xXv8OXGUqyp4lVe6zA5NNavJb1O77ieL8+TMtnA88CxVN5F66l9bWl zODO9rQp/VfW06J62fVUNwSH48ysbswN3G9Py/qgEqSKNGyh5JFBQOAoO+Sryg9+o9Lx3OEq wPBeSoyKN9CBkiYldnkX3xOq2QMXmQnOfJoqP9anr5q+htCYw+DqYjxMq1AVFr5eVTrCVCg4 IJTGAoitJLR3VokxNM64lQjqsevOBkntudAU4a9WoZhTG6UaY+tlfmBTM0qeLAERLHw+YDoW xNSiY69ZVW2iC6H36AS7+IeuMbK9McieOOcMFwhhLUkJS/GYI9MiQTdD6K660EWx1CFOpKa9 As8HdS5r85fT/wNwQg0KCmVuZHN0cmVhbQplbmRvYmoKCjI0IDAgb2JqCjUxNzYKZW5kb2Jq CgoyNiAwIG9iago8PC9MZW5ndGggMjcgMCBSL0ZpbHRlci9GbGF0ZURlY29kZS9MZW5ndGgx IDIyMjg+PgpzdHJlYW0KeJztVd9vFFUUPnd3Z1sqpduyYHFB7zgFwc6WtihKUmDT7pb+CN1l t8UZXSPT7dAu2V/ZbhtqJEWDihNATYwhakILJMYYyC2+YHyRqDEx8qCSPmgMPpjog8ZoYmJM 2vrN7Eor6Z/g3czc75x7zvnOuXPv2VJxwqS1dJLcFEpljYKfMcL4kog1pCZLPLnxnAT8A3Sx o4XR7K3t134icrXiMUczU0eb1Oe+IfKcx/qRMdMYefXMUgvkvyDvHoPihYUnqogk2FPTWLZ0 XGE91ZAHIVdn8inDT/aSlMTLmzWOFxpoMxKQRiDznJE1bxza8DnkU+C7XciPl/x0bAmuznqh aBYam/+4AhnrBF5i5KSPioh5Hfn/8Qa9Tq/QFeqli6TTTnqEVGqnI3SIFApTJ8l0gz6jr+gT ukwv0Zv0PL1NMyToXQrRNJ1i79Am97y0X3qPnpLqBamC1veLh2Oa6JvUBSn7G4W3WdurO7oT Or8l2PqWxqBgKv9WrG0OCpfaH9ciii4HhVtNN3IRimmyCOlB4VFtV1mRn9W+D9zUA7DTFgK/ 6gFFFlKzJrondWdB1xFPUmuTTwaFV517kJ0GOz+dTAYEIUyVOtfkqEJ3VNVqQz3fszMo1qj8 hE3yKcJw4d7aq3Dh2dYnKKZZpmVwGzwekGU9YDlSvCzZhDXl7HwBn4yI96j8a6ectSrfKaqa kxrnB5Ru4xjX+MhwOYRtV2szg5pb/IDVbSgWtxSHTrGDixAsUZ+tECHTFuCzzmHaO98oywE+ b2Eb4NSLbIYqucmOWZ2q8PkKucK1/kRAFkzXLBTUq1gKt3otxbAdyi72FBQ++zM0IO96uwAb NNxVgGVPinHsyMpKbNf1KoqwXra3rW9EsaoEj2kdgY+x4lc/oBALdXay/us+SpHzto2HNPsd 15RhZK90BjAxpRM7H4pr14hTV6rzGuMMk+Apscnc/C/XBlVAi33BK2ifWhfOJrlGpCF0JnSQ XfVy/Va5Xg67+GITO784Jg39/X7YcxM3/Db6w7RnhmqJZP7QNt9ju2V+70ZfldcdXPz9wszM BVbHai9dvHhpdsZ1/8zs7OzCj7OzTmc4umvX1afPPvpMXcef9EC1c1m++LmuZuXlkaaRARoM 8ikP+FUdXpheYXJ3j3G5fqGwN2nnReX2xpx61lViuCC7aON/HNfR1Tvi9J2YjGogsYpXFW5x Gbuhf62CPcBvVbCEPbhcwV7o52DJPGsgLdJHFczIzz6sYOTEblawG/rvKtgD/FsFS3Sfy13B XvK7tmxP7eDtra17eGIixw+mU8X8+NR4ycyO895cqqVmsCcSj/BwNJLgA9FBHtF6E4O87NPW xvsmMmkzxweMYbNUE4tHuiJhGHYE9y17JIa6uiKR8LJPNJOeTJtF3mNkMvlStGDmElPZ4Xwm bo5OZIzismIZHTaL4+l8jre1tre0L6tpO87qDhzDdnyWVtoDlKAJymE+SGmsFSlP4zSFp0Qm ZTFztM0cVlqwnYPUQxGK4+E4nFHMCaABoEHMEdJgm3DwSp42/Dj1gScDDtNhGyCDhoFLiBpz InbhCVcidlCQ9q3KkaAhWNq2tvVqPFGHZdJhKkLuAVMGvzy4olRw+BOoMAv+PPRxaEad3AzY r2axmu6wE30cLHmnnjbwt2OP2le1xulxxtIo7sMq4zpbelGws9QvqmPaHGPn9Lluu/MKH/5U /HGAk/oWdMikpgt/M9E/ol+rnwplbmRzdHJlYW0KZW5kb2JqCgoyNyAwIG9iagoxMzAwCmVu ZG9iagoKMjggMCBvYmoKPDwvVHlwZS9Gb250RGVzY3JpcHRvci9Gb250TmFtZS9EQUFBQUEr T3BlblN5bWJvbAovRmxhZ3MgNAovRm9udEJCb3hbLTE3OSAtMzEyIDEwODMgOTE3XS9JdGFs aWNBbmdsZSAwCi9Bc2NlbnQgNzk5Ci9EZXNjZW50IC0yMDAKL0NhcEhlaWdodCA5MTYKL1N0 ZW1WIDgwCi9Gb250RmlsZTIgMjYgMCBSCj4+CmVuZG9iagoKMjkgMCBvYmoKPDwvTGVuZ3Ro IDIyMi9GaWx0ZXIvRmxhdGVEZWNvZGU+PgpzdHJlYW0KeJxdkEFrhDAQhe/5FXPcPSxRoTcR imXBQ7ultj8gJqMN1EkY48F/3zFrW+ghgZf3vuRNdNs9deSTfuVge0wwenKMS1jZIgw4eVJl Bc7bdKi829lEpYXttyXh3NEY6lrpN/GWxBucHl0Y8Kz0jR2ypwlOH20vul9j/MIZKUGhmgYc jnLPs4kvZkadqUvnxPZpuwjyF3jfIkKVdXmvYoPDJRqLbGhCVRdFA/X12igk9887iGG0n4Yl WUqyemjv2eN0p/axftqAXZmlSZ49V9gf94S/3xND3Km8vgGK9G2jCmVuZHN0cmVhbQplbmRv YmoKCjMwIDAgb2JqCjw8L1R5cGUvRm9udC9TdWJ0eXBlL1RydWVUeXBlL0Jhc2VGb250L0RB QUFBQStPcGVuU3ltYm9sCi9GaXJzdENoYXIgMAovTGFzdENoYXIgMQovV2lkdGhzWzM2NSA3 OTQgXQovRm9udERlc2NyaXB0b3IgMjggMCBSCi9Ub1VuaWNvZGUgMjkgMCBSCj4+CmVuZG9i agoKMzEgMCBvYmoKPDwvTGVuZ3RoIDMyIDAgUi9GaWx0ZXIvRmxhdGVEZWNvZGUvTGVuZ3Ro MSAxNjEzMj4+CnN0cmVhbQp4nO17eVyc1dX/ufd5Zp4ZYIaBDMywJPPAhCUMhCUQsmB4WF1o DCaYgkqFADHUBAgMibE1iVtV4hKtu61BrRqNNg9DjGCSirW7tUlrW5dufFqtS81H27q9vob5 fe+dgYQ27ad93//eX2dy7zn3nPM999xzz73PDJBg/2AXxdFOUsjo2NTel2JRORH9mIgldmwJ 6vTgknzwk0TaBev7Ltn0lYN/3kNkryCyvHzJxm3rWztvuIso3g3Zjzd0tXcuvafcSeSFPS3e AEHT1FUaUYoX4/kbNgUvO0f5OAlj4Cl5Y29He7alWeibMHZuar+sT+f7xbgTY72nfVPXbV95 fD/G1xDN2dXXOxB8mfLCRAUuoe/r7+pb8oMVr2FcRJTwM8gY3uIVB9YqxlxRLfT/8cvyDKXL 9iilq9mUThR+fbpNdYdfFzpB+TtI1txIi75C9AS9zHKZTqPsU/LQJyyFFdPZpNLHqJb9dILu IDc10Z0skeZTMp1PZzMVNgG6kd0X3hJ+m86g2+jB8NPsqvDj0N9C36NPEMFvVUbldC7sz6cu elt5g1rC95KNrqNYWk6rWTK10y/x/hAxfJVup2+xL4c/waxuugr+KqiKqsLPhT+jPLpR3W15 xf4U3UqHmDXcEe6meZRJQzwQ/mX4d5RNLfQQPYGYAmxCPYsy6FK6lu5mKcr3wN1B36ApFsdb lRrLs5jpbFpLPbSVhuhx+hFLZI2WVyzvh78UfpOsNIdyEVM3vc3K2Er+sBoXXhF+jS6kcfoB 1iveE+qF6qOWC6cqw18Pf5uS6GkWww6z5ywllptPXBl+IPxNVGQ2FSMj52KedXQ1PUc/pD/T X/iO8A46i9Zg5u+yuUxn2cj4L3kK3863Ky/RQqy2FdEO0h4ysSPP0CE6gtz8iibpDeZmaewc to7dyv7C43gnP6rcpxxQfq4y9THk209ZyFGQHqaDOM8v0lFmgf8i1si+yHrZXezrbJKb/F3+ sWpTr1b/Wz1hyZ6anPrv8LnhD8lLqfQ5upx2ILcP0SgdoJ/QL+gv9Ff6iLnYEraBPcBMNsne 5XaeyVfxPn4nf5g/qZyr3Ko8p5ap1eql6ovqa5avWHZp7drUZ49MfXXqyamfhp8O/xS144T/ bKpHRq9EVTxMz9JL8P4q/YZ+L+oH/pezC9gXMMsAu57dzp5k32U/Ze9glSTfmXw5r8Wsvbwf ebqKf5XfjtmP4n2Mv8Z/w//EP1QsSqayWNmsPKCYyphyTPmj6lKz1YVqsbpKvUANY2dKLGda 1lj2WvZZvm1531ph7bT2Wd/SrtKusf34RN6J307R1IYpc2oUtWtDJV2OTNxPD6LuD2APfoSM /gQRT9IH2IVUlsFyEPdSVs8a2Er2eXYR62JXsevYbexudh97kH0TK8AauIbYA7yKr+HtvItf w6/jN/EDeD/Df8h/yV/hxxG5R/ErAaVYOVu5QLlQ6cEagsp25Rpk9lblceWo8pLypvKWchy7 5lHnqYPq5eo96qPqAfWnls9ZNuH9oOVZy4Tlp5bPLJ9ZuTXVmm4ttH7Rutf6e82qLdYatRu0 n2t/tfWxdJaHyPVTbwuegjM4jz/O3eoOdhyCuUyleKw8gH1Yg1PxV6pUprAvTqFHbEk8RZ0j kFZDNYEPskNUxr5LO6xcwU2sTlKI/ZpPqs/zM+gXrI2lqI8qPZYf8Qzah9toNz/MD7FqOsAr +Fr+NYXYG2wvvYF6v4xuZ5eyAdrHjrNl7ApWznbQz3mysoZdQxXhB7nK7Oxs9j4hArpS7aQv /PNbkC2lX9PbU/erDvXLuJ/G6E7s6BP0O/YYfcos4Xdxuym4jdpxy9yIer+WxK3XinO2A+cx BTfIRutROiCeKFq5dYV6Ob1P/0VvW55BRVXjJn1zqlu9X/1DuDxcgBOGU0Z7ce420Jk4MW+g So5gLEYX4aTH4C4pwalupAuok67ArXdr2Ax/LXx1eFu4l14A9lOWzz5lwzgRY0BU0A/wvoVe ZbtwDs/8nz0Fpjppgt5hXpbFSnAejlu2WHZbHrccsHzL8qK1GNm+hu5DRf8e1RyDFXTQT+kd +pjZsDcplE+liHcJYm+mjbxFOUI1LJX6cGZzcY9XR1cyAC9XIXtfw3k+grPxPu6Ji+hb9Arj zIMVdWB+G/w0IM8Xw/oR7ODVbBSSTtzaefQnrNvJlvAg5jPg6U7cWhOI6df0R2Q7LOPKx71Q y9bC18f0eerEDIupkY1gBw7SUtystcqPke/5zEXVLJN9A7g2nFAnzaWllj8wTvlT54aX8G7l CJ4xYciH8fRKozPYZkQRj3WcoCS2isqmViOGl5iimuxnMop7eFf4OmXr1EZ6gR7DnhjqFq2W yKhqMipXnFGxfNnSJeVlpYtKiosKFxbkB/IW5OZkZ833Z2bovnlz09NSU7ye5CT3nMQEV7zT ERcbY7dpVouqcEb5df76Nt3MbjPVbP9ZZxWIsb8dgvZTBG2mDlH9bBtTb5Nm+mxLA5br/8bS iFgaM5bMpVdQRUG+XufXzRdr/foYu+C8ZvA31fpbdPO45FdKfrfkHeAzMgDQ67wbanWTtel1 Zv2WDUN1bbVwNxIbU+Ov6YopyKeRmFiwseBMj79vhHlWMMlwT92yEU42B4IyU/21dWaKv1ZE YCpZde2dZuN5zXW1aRkZLQX5Jqvp8K8zyV9txgekCdXIaUxrjanJafRusRrapY/kTwzdOOai dW2BuE5/Z/tFzabS3iLmSAhg3lrTc/nr3pNDOE+sab7uVG2aMlTn7dbFcGjoOt2cOK/5VG2G 6Fta4ANYnlXfNlSPqW9EEhvW6JiNX9vSbLJrMaUuViJWFVlfl79OSNq+qJt2f7V/w9AX27A1 qUMmrd6WEUpNNcbDk5Rapw81NfszzMo0f0t7bfqIm4ZWbxtNMfSU2ZqC/BFXQiSxI874KBPn OJXpmtFJTpoLrmH1TGaZiMh/NgrC1Dt0RNLsx5qWiK5rCQ11LIEZXi0MKLMTO9Jt2mvahlzL hFzgTUuWy68PfUioAP/xd2dL2qMSa5brQxKsqJOZUoN+mjcDATMvT5SIVoM9RYwr5LisIH/L GF/s73PpIEgfNSK37S3LCpH+jAyxwbvGDFqHgbnzvObIWKd1aSEyCgMtJm8TmolpTdL5QrNz WjMDb/Ojkg/ILwpJpi175l+8K3lO3YZlJkv+J+quiL5hjb/hvAua9bqhtmhuG5pmjSL6JTO6 KGfOqWlW0niU42mK1KIoL5oxFoPmOFPNwj+rLOpOU0FRSgHT601X21mRviUmI+MfYsY02ymg sfD7AiXJSVg0SnNZYPZ4+azxrOjihhTEq2bzhqYLhoZiZunqcQENDdX79fqhtqH2sfDOdX7d 5R8a54/yR4f66tqmN3Qs/MyuNLP+xhYsYgNbhmLlVD3iZ9efN2Kw69dc0DyOr3f69U3NIc54 TVt1y8h86JrH8VHFkFI+IxUjXYyogaHQQ9wmVWnjBtFOqVWlQI47xhhJmW1axqhjjEdkLinD qwAfY8TmW/DGpwKNqg9wNmXVxnilMYcs6pRCMZo6xSjFZrVMceUwyyY7Pgx7yRtwfVRxouJc 1wcVK09UUCV412foiosyEjISstAxfMD4TFcmPjMs9N+kqxPiG+vdmMuP72F29hPDaVesthTF Y1MTbVxRxsI0mhhbCToxemFrqaBG3pqmUqVEs7k1zabYONcUu8q5HQPVgI1qQK+WWI9amGWM 7zJSjNjG2LZYpS92Zywfjp2I5XpsUSyPtdmjTgU1nGvWlNpL8OGjCI87hQAcjSke9AawllYs JhCoWOlqbd3c/1F0hMVVVrCExKVLCe26hQG8rrviOyNWXtPUPE5KeNKwO3NKbTo6EfXTdkep zUBHwrKluKhGWu08GFtm2xlbJhd2RurCUtsadBYlWSlRDEWtV6617bYN20K21xXrd5Sjttds iq4U2kqV5bZVttuUPbZhZb/NVJ61xWrCg31RWSk30GE0aTgKS0q5LjrNXQbJXYY9Y2Epb0In revn6Rihs3FN83LFo+XzHG05X6Sdyw3tIr5Ws7t5mraS12n3avu0F/ir/C3+pvZfPDaH52rn aJdp12tPcCtDWvoD0y8SWZJrpNZF2PAEsesJdzOdN7M5Uy+fGLE881mB8tKn9crhz/ARgtPq 8FvqveoKcuCT1l3GWW+xN20fz/k4Sf0+f8vCE1MsKXbe4lo7Z21yi/cufrf1bttdcWP2X/Bf WX5t/0Xcm5Y3rW85XI/aXuA/tj5v+16cZdB2g/Uam5IwxoOhmFgPiOFWNfdSLbUtrS+Npzkz KCW1uUru7Mrj57o2f7TyOFUerzxeXESbW7GWmmbD3u1an7g+udurslYsg7XOKU1cvKiEktzk z5yfneVOXlSyuKw0259pXT104mt/ZqVTP3z3tqmPh5h+Z0/PHXf09NzJM29k1qGp77/356nn rwnvvX/v3uGv7d0rqt0Xfovfavk6VvuisUAnnfljFsQvc57jbInXUpLIqyQnkSdxjpt5Ermb eRW7FqPFeccYM+LJM+wxPUobyIRH8YwxNZTE3FjiKCWJ8xk0nHGx9sKYQqJCdjE+d8LCyPUq 2Z7E85Mq3Xvc+91Km3une7f7mPt9t4XcLrfuLnKr7pTUy4Yjtb65v8EsX9NgLsc1OE7u8MSS loqV4gzjGLg+SHmdvMiVONcwfR3ln7AoHq/iItbKkvwJ7mRkptxj9WdmZ+dklyX4yxaVZSXw yydic9JzzvGu+/LnLl8aa7/ySpaqZk9ONV0VSE97LW/ReXXFd7Cjky99Y+oG1EMV6iEH9eCm dPbQOLnCnxj1sUvvsd/ruNO11/JozCH7IcdYqs3mZmfxM631Mavm7XUctB5M/X7MD+J+GfNK 3Cfaxw5Henx6kpE2tzTJcCaUxic9m3Q0SUkS5z1+XqWkTg8ov8mIi3cmNjrbnNzpTWRQHExJ K2WLEknYzNVLJc1cEKGBggj1pktqxDvjS4fFc9KFsC9OTBQbocYmesVGzI/VKIMVJmWscjJn auG8i+f1ztszT50Xn2EzHPGltpS53ZEaDIgibP2odeXxD0Qd4jFmuL1GrrvSa8yLR5fmQpee UCmPVOUJ6McpEUHAIlEEAyNJYSdoaNoU+yPPowQQFIlLRdAhjyDmqD1mhRxWZVQGxJXU8noA u9kqp3cayJJTTOoU0zsNJCtybRVW4O7D6cbNt0js+WZqDTCL1erXsdsuwhFRMkQJLJ6TjcOh WT38U+Zd/Pb+qT9d283cLx1nidYThnJVe/UFOcplay+qqGBsdeG9Dzx162/wVSsw9f2pI1fs OottvHxHTc2AOCtFqAUXaiGPf9uYsCZY/bYcT4LHf3fi3e67cu7Is2vuejdPPOQYd34/4w3/ J46PMq0LHOc7uhx3xN6V+GjmeJxW5Tfm12ZfktmZfV3ide6vZF49316eXWetjz3HsSq+PqM6 U8ucn5NdHleWUZZZ5i+br1ljLAn2DK8jJy4zM9Ovzc808gfiLnNvS9qyYDDv+qRr8u5NuiPv QOYBv2Mnu8Vzo/eevMfyzHyrJyPZyPCXJhvpvlJfMvtdMkteZMtozLoli2cZ3rmlWan5omQ8 CTGVjfmsKJ8V5rP8eRlFLuZaxDJkWcXbKyWFiSwvu3hapAQuGxN18hnSjxLZLIoF9+tHgc1i hK04TpFnjlFmZczKkll25uKM+owm1uLpZN2ej/C90cPV1IxMnjvHEcdzUy9WmVqfG9uYylLr 52iVJ1rxLyHRs3S6tW5OG6fM8AujuXmlGWMRmonHyei8+WI8OeqbHxmnpMqxkQbmUgdbnFmf ebfj9szvZP4805qRGedQ1VSxjqdwomiROFujnoJKFi0+Oc7MKhXUmJuKE8WKmMEamdrGdrL3 mUL4ctuIj8+qtJyTDEtcgStJZRer76tcLCHZgOvkRR4Dfj0GnHqMsvJSjxFYiC5rATr4jff4 PBd7ej2q5/xUI3N+aXwqa0wNp/Lo4jcHPmiNPLheD4jhB4Ho40ucB5GMiBIPbLa5lTbj1doq j9T88A8Ne2xiZXwuOuTh3YOOpXHuuKWCDcUtRYbeGYldKo8NEw/Dza1zsuTtiAdHTnYOiq6s FM+UZI8lclSS3J5kVXxLFpdnEUtN7OnYVJ7lTjp76okLt7/2xms/z536OOHi5t4iPT2bPdfS /MF7r55ghYHV5+emF+pJ7oSGFWvvGTp8867iFdW+ZP+8pPT15zR85bafmfJzvMX9Jce+N7dc HF/xoS3FJn8i8uAfKk7+pJvCb8lPYIzs0d8fiNNH2oqpc6nm5A+R/uaHKhYrRJbv093qH2g1 f5x86gBV4QOUeC1mZexJfoZSo/4xirRSgLjUcVyYhXQ+/Ffwb+NDppCuUd4h8WlTvL4oe0Xi YuRIkSgbBaO8Qs305Sgvfi7+8yhvIS+9FeWt5GXTfjRax7xR3kZF7PIob6ch9niUd/DHeenM GsvU30Z5LNEyJ8pzUi3eKK9QviU9yqsUYzkrylsozrI6ylvBfyHKa1Rs+WKUt5HXcl+Ut1Od ZTTKO9j5lk/gmakK5nJqK6O8SqnahZIX2YrRBqO8SsnaDslbIbdqd0R5lRK1+ySvibxpT0Z5 5Ep7SvI2yOO0H0Z5lbzaLyRvF/nXjkd55N/2+SgPP7b2KI/827qjPHzanovyyL9t2g/yb5v2 g/zbLVEe+bdfEuWRf/tdUR75j8mQfIxYe9wLUR5rj3tV8rGQJ8b9NcqrNM8R8RknYnP4ozzi cQQk7xSV5qiM8iqlO1ZJXjyuEx2XRnnh5wrJzxE5dNwX5ZFDxwOSd4t4HKNRHvE4IutNgtzt +FWUV0l3vCf5ZGHvjI/ysHfOlXyKsHeWR3nYOxsknyb21HlplMeeOiP7O1fE49wV5RGP81bJ +6T9Q1Fe2Ef2d77YU+fzUR576jwq+TyRH+ebUR75cUbiLBB+4pUorxLFOwRvk/mf4RF/fJrk 5briy6K8kNcIPi5i3xrlhVyuJU7uS/y1UR7zxt9Ej5FOJbgjivHWqYk2UBfoSuqlHrQgbaM+ KanBqB+86Nsh75YWC6Gpoo1467QaskuAD9KAHHWBdsF6C/pO+Xujfli0w7Ya2I2Q/e0sy06x 0WesltFa6WcgOqdOZfBWREvA5cJHN3VA2wt9L62HrwWn9fKPfJy0LTglrqZZPrrlitrRgnL1 nfC1CbSfLoVMzPo/ydy/i/h7u6YZrlZaboVlD/ZAp1WIab3MjNAWyP3opXVSr9O5UrNBrrYd a8uHrFHO1C813XKta9APwr4zmjkdFbIUGSuhFiAHMRY52AY6KHdal79hiORqvYw1KGW96Dul vE/Ot03mUvjVIemXMQnLjiimKzpul5765OybYBWUOoFaJ30Eo/nbGF1nz0wUEcR0HP2n2PbJ SulExB1yjkg+tsq4RUZOv4bIWNh2YLZBmZFOWft/mwmB2Ci5XNgvABWVsi4a9+l99/wv1n7S e+fM3vfLkze9l9PVc7oVTM/+93EtP2WPxEoiawnK+abrUviPrLUTkq1y5b3ydPyzSmiftetd cnd6o31kVRF+EKM+2esy2i0z1RzxIyw3wuKf1dDCx/SSouJivWlDl76yt6c3uK2vS6/p7e/r 7W8Pdvf2LNSrNm7UV3dfsiE4oK/uGujq39LVubCqv7t9Y3Xvxs5pyDIp0YVo2dqu/gEg9bKF RUv03JXdHf29A73rgwtOmpxqIaUF0ldTxKJ7QG/Xg/3tnV2b2vsv1XvX/+Pg/pFiRtYkutr+ 9q3dPZfoq9av7+7o0gv01b3runv0c7s7NvRubB/I1xvbg/3dHd3t+pr2wZ5OBKcXL11S0tI7 qG9q36YPDnTpwQ2Ian1vT1AP9uqd3QN9G6Fo7+nU+/q7IeyApgu0fUDv6+rf1B0MdnXq67YB 1qVvxJw9wgUUwke/lPb193YOdgR1xLF1AwI5ZQbQ7p6OjYOdSLQ+HURvz8Ztem73Ar1r0zr4 PsW655/OLs07xer7uwbEKkV6Tk4g4DO+lssV5XZjlmDXJpHL/m7M2tm7tWdjb3vn7CS0R5be 1a9jRb2YCv1gsG8wqHd2bRFphs2Gro19szO0EBdrF46gOIBBFPqpj5DZmiANMgdK9O1ZNiel 6+XxPFUXkdRLfHCWJipTrleOKN9RnkU/cqp+lvw/D/v/POz/87D/z8P+/+TDfuaO7f6Ht29E 8znQDaBbgBeSwVm2f689U2ZgYJbVtKwet/VG3Awfwf5tyGbfzLN105iB6C3ee1qPJ7VrJXeq TURylhxtkc+E2frZmkb4EKselHeByNW2Wdan05+aqd5/mMNe1aeuUJerNepidYlqqGeoDerS U61Pq2867VPvpLT+79YTkTSIESuGzam6k9IGeQr6kOnev7GYkbME+r3iRz2fop+RfU7eEkL6 r1bQv5ilf9nfP6uw6M/gKJxDL9NpXiNNO6scyhO0H42TC72ONoymkKE8Mao5Sowx0ES3pKHk QMl4eALMskVSXnB7yc7Dyj66mBZBvC90vhDvGzVqSyRdtDxCC4slDdkias1d4qtKBawQjVN8 lFuFdgvaHrRn0awIaB/9Di2Mpih7lQdD9T54eBiO4qvcysPEEOXDdBQtjKYg+oexlofpvahE RVQPjdrjxPQPSVSa8hBQ8ehdaDvR9qMdRbNQL/o9aGFF/Dhmj/IgdA8SVx5UHgi5fK6qGOV+ 2oHGlXspnolf/k0od4+6ZG7uGY2fU2JUuZQ7qBGNk6mspAk0Dre3AnYrcZg3hAqKZQobRmOc JS7Y70LQuxCI+MnQMHomxwaasN81OidZuL86FJ8gcV8KFZVGmFGXt6QRWbiMmNKl9JCffMp2 0HmgHaBzQdcpneSQcRqj8a6SnZivEuaVShKuaZ9SpSTjIe1TapVUSpNmgyFnZJ7BUG5eCVZc o3ilSbzioFJQm6KFSnz6IcWQyb9+1B4r4rs+5EoqOaJcq2jkhtVOWHl88UeUGOxsjFxJ06jd UbK7Kk5pwjKbkBYfYmTIco901BOCo6oEpU5Jp2ToLlXmUhJovTJP0keVB3CifcrXR7PTfROH lK9K1G3CKaZfESmtFaMOZ8lElV1ZAa2p3IwNuFlOvns0e0kJVWUruVSExpHjHeB2yKIfAjeE XRvCTg1hp4YQ1BCqj5QboBG/xSxULqc+ZSvtRtsDXpRVUggJHZfM/NyScSVF8SIxrkNIJYM0 ddTuFJF5Q4lzpJl3NM5ZUnlEGUCdD8CnoQRHPd6S3kNKnlxK/qg3TQD6QijXI4onsjUAJost OaKkIxEiMXOVeaEkn1nlw1gUso8Y/xE/JpLEX+K/ENst/nJY0hei9MUo/UmEhif4scih4D8T dLIqnb8BZxfz39AecJwf4s/jM6+Pv8bHRBT8VT5OlaCvYNwJOg66CPSZUMYPfGN8bBQEsd8X ciSLxfLnQ4HCKOPLijKetCiTmFxSlcW/zZ+jdLh4GXQ+6HN8gjJBnwX1gk7wIP0A9Clehg8Z Pn4gSr/DD4sS50/zg/iI6eOjIacIwQxpguwPWQX5Zogio8ZC32H+Tb6PUmH6ZCg7FdK9o9nz ffGH4I/xh3kwNNeXWBXDH2DN7AMYDdMrglIifzBULpzsDh3WfeN8N99teMuNLKPAeEQpyioq KHpE0bPwnblcf0SvcvGbcYHs4Ti/fBf6ctI5qgfNQNvNbwip5WbVCaxJrIvTTvTDkmtD3yc5 Qu+a0b4vuUp+La1C4/CxHW0H2k60K0lFfznal9C+jHaFlATRBtG24jbpA6IPiD4g+iSiD4g+ IPqA6JOIPjn7IJpAtAHRBkQbEG0S0QZEGxBtQLRJhIi3DYg2iWgEohGIRiAaJaIRiEYgGoFo lIhGIBqBaJQIAwgDCAMIQyIMIAwgDCAMiTCAMIAwJKIIiCIgioAokogiIIqAKAKiSCKKgCgC okgidCB0IHQgdInQgdCB0IHQJUIHQgdClwgXEC4gXEC4JMIFhAsIFxAuiXDJ/RlEE4hJICaB mARiUiImgZgEYhKISYmYBGISiEm+dUQ5VvVdQI4BcgyQYxJyDJBjgBwD5JiEHAPkGCDHoksP ymRwlM12tB1oO9EEdgLYCWAngJ2Q2AlZXoNoAmsCYQJhAmFKhAmECYQJhCkRJhAmEKZEDAMx DMQwEMMSMQzEMBDDQAxLxLAs3EE0gfj3i/Lf3hp+JWu24VnLd7IFku6gdyXdTq9IegWNSPpl ekTSL9FVkl5O5ZJupWxJ4U/SIPlsLOQrj69KxhWwCu1itF60PWj70Z5F0yR3FO13aGFeZmSq 8doqbY+2X3tWs+zXJjUeb11l3WPdb33WatlvnbRyvSqNO+Q9iquFbpH9DvTvoeEhgr5ScpW8 FPOW4p4tw7uUlxoJx/X38tjRPPZsHtufx27JY1V2fiZT5U2nUzlH4KzZiMte4XsFrTw7ZwVu ppsPvuvxhbIX+8bY4QhZYARA30UbQXsE7Sq0crQStAK0LDSflOXBvtnIjLo8jJaDloGmiyko ORkfEBMTbMY4d7BHRr/rILuYJycXuEOhnCKQsVDOKpCnQznrfFV2dpByxKci9hR2bh/o/pDv daifjJAnQr5DIHtDvlKQ1lDOQpALQzkv+qoc7HzyqQLaFKVrsG5BV4d8a2F2Xsi3ACQQyskW 1nmYKAvaBayZXgfNiqLmR2byh3zLQTJDvqXC2kY5YuOZlQpkeBY0QZVRBPTeOGtWmRHrO+77 qu9dwP+ExKI8XtXHVJCjWWNsrRHjO1xwP4yrfKGqGGGP58NIlJqCPuV7JOsG333wxbIO+u7x LfTdXDBmg/gmxH2DnCLku0of4/uMOb6dviJfsOB134DvHF+7b7WvNQvykO8i32ERJrWwZr7v oK8RDs/GKrJCvjOzxmSI9b5tPsOX41uqHxb5pSURv+UFh0UGqCQyez7ym5c1Jmr8/PIxlmDk ae9ru7ULtWptuebXMrV52lzNbUu0uWxOW5wtxmazWW2qjdvI5hZ/ARIQvyV3W12CWFXRq5J3 cdHzyB8AcGbjdA6Zc5QG3rCmmjWYEx3UsE43P1rjH2Mx511gWvzVzExsoIamanNJoGFMC682 ywMNptZ4YfMIYze3QGry68cYNTWPsbAQXZsm/p59hNG1N6WNE2Mp197U0kLe5C2V3srEFQlL 62tP07VF+8DJl/dUdq55Z8OaZvPxuS1miWDCc1sazCvFX7uP83juqKsd505BWprH1T4eX7da yNW+2haYvS7NUM1OmFGOIDCzVZMuzHCfVAsz7FHELhtw2GUIArsYB2VLu+wYh7RTmbAbeUWv qx3RdWmTRfSKtHkli06xQcUAWzuSnS2t/DprFlas2a/LwBZIRz4fTAp80gRfg33SkY/JyczC kyZZUZOyGZMyOZfCTtr4Ijbu3Gkbdy5sAv/LV1d1gI0WD25/XvwHgjZ/XRdam7lrywavuXOd ro9sH4z+z4LstnUdGwRt7zIH/V215nZ/rT5S/Pxp1M8LdbG/doSer2tqHnne6KoNFRvFdf72 2pbRyormqllz3TAzV3PFaZxVCGfNYq7KqtOoq4S6UsxVJeaqEnNVGpVyrrpuUfeNzSM2qm6p uShCR3lsDGq4LS2jpTrZ1bdCFPT48gzv9rRnVGJ7KTbQYsb5q00HmlAVVBVUCRXOmVA5xf8S iaq825dnpD3D9kZVLogT/NU086e5wqjBLDuvwcxYc0GzKBXTaD/9ng2Il1R7qa67Fv8wDsqG 96mWNHDaV/B0r8HBwQHRDQYGiBrMvDUN5uLzEImmYaq22hbIFk7LFEXKRuz2urHwBJQBBMGC YjrBBZj400YjBt+6ND5sHda4+KoQHE2dW9J7BE/wHWj4Hse3hgrl12e+dTQzS3x/CY4WlkUo vq4KGkrNKBF/Y1YOqKBZEWokFIDZnbW7YHf5cNZwwXC5Vfx96CMQ+h4Rj9JQ4SMKBQMD04kA G2yhyF9cYr4HQulz5cTDggkEWgIDTObr75PNppM+k9iBqNcB6T44vSER+UDUCXYiMvvgNGww CpLKQQmKOImMZrqTL4yI/h8jwYkKCmVuZHN0cmVhbQplbmRvYmoKCjMyIDAgb2JqCjkwMjIK ZW5kb2JqCgozMyAwIG9iago8PC9UeXBlL0ZvbnREZXNjcmlwdG9yL0ZvbnROYW1lL0NBQUFB QStBcmlhbC1Cb2xkTVQKL0ZsYWdzIDQKL0ZvbnRCQm94Wy02MjcgLTM3NiAyMDAwIDEwMThd L0l0YWxpY0FuZ2xlIDAKL0FzY2VudCA5MDUKL0Rlc2NlbnQgLTIxMQovQ2FwSGVpZ2h0IDEw MTcKL1N0ZW1WIDgwCi9Gb250RmlsZTIgMzEgMCBSCj4+CmVuZG9iagoKMzQgMCBvYmoKPDwv TGVuZ3RoIDI0Ni9GaWx0ZXIvRmxhdGVEZWNvZGU+PgpzdHJlYW0KeJxdULtuxCAQ7PkKyktx AvvspLGQostZcpGH4uQDMKwdpDMgjAv/fRZ8SaQUoJndnd3RsHP31FkT2VtwqodIR2N1gMWt QQEdYDKWFCXVRsUby7+apScMtf22RJg7O7qmIewde0sMGz08ajfAHWGvQUMwdqKHz3OPvF+9 v8IMNlJOhKAaRtzzLP2LnIFl1bHT2DZxO6Lkb+Bj80DLzIvdinIaFi8VBGknIA3ngjZtKwhY /a9X74phVF8y4GSBk5xXF4G4zPi+TfiU8UOVcLXX64TrvX7Ku29b0pUUw497qtYQ0HnOKltO Zo2F3zi980mV3ze8M3bSCmVuZHN0cmVhbQplbmRvYmoKCjM1IDAgb2JqCjw8L1R5cGUvRm9u dC9TdWJ0eXBlL1RydWVUeXBlL0Jhc2VGb250L0NBQUFBQStBcmlhbC1Cb2xkTVQKL0ZpcnN0 Q2hhciAwCi9MYXN0Q2hhciA1Ci9XaWR0aHNbNzUwIDcyMiA2MTAgMzMzIDU1NiA1NTYgXQov Rm9udERlc2NyaXB0b3IgMzMgMCBSCi9Ub1VuaWNvZGUgMzQgMCBSCj4+CmVuZG9iagoKMzYg MCBvYmoKPDwvTGVuZ3RoIDM3IDAgUi9GaWx0ZXIvRmxhdGVEZWNvZGUvTGVuZ3RoMSAzODYz Mj4+CnN0cmVhbQp4nNy9eWBU1dk4fM65+zZz7+xbJjOZzGSZYIAkQDCaq2wqhB0kSCQo+yKE TVAUUFlEVLQVl1rBpYpbCRAwoNbUUlsXCq2WVvsqtEVFa5TXUqpCZn7nnHtvCNr3+73f9+c3 kzn3uedu557z7M9zTpYuXjYDqGANYIB5/YJpi+55+qGNAIB3AICe65cvTah/ix/HMP7x42cu mrVAvW7FWADEarx/w6z5K2eevO2oAIDrKQDmLp09Y9r0k3fWugBYGcL36DcbV2zM3YaPrxyN 94tnL1i64o+h9R/g/aV4/8T8hddPe8u/8HMAbpqE95cumLZiUZk6nsX7+PkgccO0BTPif3j/ Nrz/BQB6dNHCJUu3gvI8AHeJ5PiixTMW3TT5o+F4vxQA5Re4DuIv+agY5Mk+YliOF0RJVlTN 5dYNj9fnDwRD4Ug0VhAvTCSLUsXpTElpWXm2otdFlb379K2qrunXfwD4/8uHOwDC+BfhngFh NgPwuOQ/xb+TZJubkz9JjpMtwqMA2u0fADvAi3AOeBG8Bl6Hp/BVO8F+0AZ+C4JgMHgUrAI/ BhsADybjmjvBWPzlcP2PYTjfBirB4xiXHgeH8LlXg1vBARCAofxnYDVYx7yLr1oHNFAELgOj wUJwNxyRXwamgGPs7aA/GAFuAIvgmvyk/D35+/NPgZ+B/cxv811AARFwPf4eyn/J/Tn/X6AX vuIB8DA4Bu+X9gITP2UNPvOnYDF4hGliYX5W/jvcgiS4EbeBBQ3gEOxAWXz3GeBTGIKrmEH4 Lk/mW/MH8Vkx0ARmg0fAAVgDh6EkNyXfkD8EAvgZK/BdHwa7wT78bQevgg+gyp3KP5U/BcKg AlyJ36cN/A52MLmutbl60tG4l8pALT6yEPwC/AYcgSn4S7SQU7m+nMndlH8P+EAfMAG39hl8 5Sfw3+hW/F3NvMEOzV8OXLhf7iO9DX4N/gojsBKOghNRGVqIHmMWAxE/sQ/+TgdzcH8/hO/+ EczCfUhFh5kn2efZs3xB7njehUckA34Cfgp+CTX8pgm4BN4Gj8K/o0FoKvoJ+hvzY/ZZ9g/C NPzW14IF4G7wPPg39MABcAy8Bs6Gq+AGeB98GB6CR+BJdBkaj+ahr5jZTAvzKns5/o5jl7C3 c+u5u/iTuUm5g7nf5/6d75tfD8ZgfFiLW/8AeAy/2X5wGLyPv8fA3yAHFejC3wRMwgnwZvy9 Fd4Nn4A74LOwDT/lCPwb/Ax+Df8FzyKAvzyKoiQqwt8UWoxuRD9Gj6LD+HsEfYG+ZYJMEZNl apg6ppFZiFu1gdmCv3uZv7IR9jCbx/3cl9vKbeN2cM9zr3OneFW4TQTiO+ee7Crv+igHchtz W3O7c235vwI/HsMI7oVCUIdbPw1/5+Lx3ooxbid4F6q47yKwHF4KR+CemQrnwha4AvfkHfAR +DPa9p/DV3Av/Ql+hdusoRht80WoBl2ORuHvtWgGakFb0P2oDR1F3zECozBuxs+UM8OYJmYG s5RZyWxlWpl3mA+ZvzFnmHP4m2dltpAtYjNslh3GTmWXsY+xn7KfclO4t7mPeZlfwK/n2/n/ FvoJlwqjhTFCk3CvsE94T2zG2PkrsBe81JPm4XFmLTOE2QvuQVVsGP0O/Q7j81QwnWlAGFPR DrgR3QLbUDG3gr8YXQxHglNsBvf1G2gbOoMuZhrgcDgOzEV9rLvxPvY5vKljfwU62Vfwu/0O 33kFr8Jb0Ve8CnZDgGrxM3/N9GazzNvgA+YYFNjHwV9YGQZhJ3qGGY2x4FX2Um4SSDKPgp8z LfAWsBcNAUA+K27GeDwSPof5wnjYF37D5AGDRmIs6s/8HdwO5qE/g05MxxvBg3A6OwvcA6rg KvApeBpTRRl3A1/O++GbaA67CXlhG0Dss/jtamExZDgfuAM2MY/wX6H3wTJwmJXBR8wLuPWH 0c+ZBvYUNxbOxhRwC1gPWvJrwUpuEvsHOAswcCJIs8cxd1vF9GWTeLsac5UpmKftw9R9APOB y5gGXBPCmDMC48UEzCEewd+HMJ9gMQbNwTR+NeZivwNt/HjUDmZxLoi5DgDs27mxYHL+afBw fha4IX8/6IX5wYb8KnzHHeBjcC/YAdflbgaLQBxTzkdwBDcUHeaG5nuhTeh9NA5tvXB8cW+n YQh8jr8/xzuXci+DTeyfwDhQn9+c/yPG7lLMYR8G14GrwAn8ll/iJ1zBdICq3Ei0Kz+UWYTf 9xgYk38mXwhlMDs/H4wCr4CfCRyYJmTxGLfCP+D3vRnMQGPzS5kZuTm4H+7FvWDi3lqG+c+d 5qAJ4y8z6y+9pO7igbUD+tdUV/Xt07vyol4V2fKy0pJMujhVlEwUxgti0Ug4FAz4fV6Pobtd mqrIkijwHMsgCCqGpIY2J1ozza1sJnXFFb3IfmoarpjWo6K5NYGrhl54TmuimZ6WuPBME585 83tnmtaZZveZUE/UgbpeFYkhqUTrocGpRDucPGYShu8enGpMtHZSuIHCWyisYTiZxBckhoRm D060wubEkNahy2dvGtI8GN9ulyIPSg2aIfeqALtkBYMKhlqDqUW7YPBSSAEUHDJwFwKihhvV GkkNHtIaTg0mLWhl0kOmTW8dPWbSkMHRZLKxV0UrHHR96rpWkLq81Z2lp4BB9DGt/KBWgT4m MYe8DbgrsauiY9Pmdh1c15xVp6emT5syqZWZ1kieYWTxcwe3Bm86ETq/i2/uGTRpQ8+jUWbT kNCcBNndtGlDonX7mEk9jyZJ2diI74GvRemhzZuG4kdvxp04fFwCPw2ta5zUCtfhRybIm5C3 st5vRmoIqWmem2iVUpenZm+a24yHJrKpFYxdmdwdiZj788dBZEhi0/hJqWRrfTTVOG1wbJcP bBq7ck/YTIQvPNKrYpduWB27y+W2AVXrCczoPkYhejqBho/t7llIWpS6EiNEa+L6BG7JpBR+ pwGkmDEAbLp+AD4Nfxohvqp1Oh6ROa3SoOZN+kBST65v5dJ6KrHpXwBjQKrziwtrptk1fFr/ FyAgwZNuVMPHHbg1m20tLycoIgzCY4rbeCndr+lVsbwdpVKL9ATe4O4Do3HfTmscWIm7P5kk A3xXuwmuwzuta8ZMsvYT4LrobmBWZhtbUTM50uEc8U8gR9Y4R7ovb05hTG6jKrK/Vcx0/7n1 gHfI7IGtMPD/cHiGdXz4uNTwMZMnJYZsarb7dvj4C/as4wO6j9lQq3fQJCaKbAhFGXoUI+WU 7pPJziS1lU3jP54i9fR2QcRYSWtgYmir3nyFVTbKyeT/8qL2/ClyFd2cv8xuZuvA7IX7F1+w f0Hz1E0MbjAWlcPHT960Sb7gGEY164FX2huM8WD8pGRiUCuYgCkzjf/a8x0DyK8x2mriLhtE TsD4Z1XZuxecGLXhRvwh2NmrYihmdJs2DU0lhm5q3jStPb/mulRCT23aj15Hr29aNKTZQZz2 /IG7oq1DNzfivpoNB2KiQODyXSm4ccwuE24cN3nSfh3bTxvHT9qNIBrUfHnjrmJ8bNL+BAAm rUWkllSSnQTZAcMhfsndSKTnR/ebAKyhR1laQfevb4eA1olOHQTXtyOrTnfqEK5jrTqT1pEP 4TGDxk/qiT2UJBt7YWxEkCrYHMAaO7Ymk0bSSOMCYqF7LsF0nDM5cBYk2A5i/z2BpS2xahTQ Zvp5Li6KggAYNo5fVJbiChAF3KVmpe6pFsYzVyXkhIbkiMZKSFUvnyC5FAWXsqrhMgET+H4J XUcTQHv+TJvbbQOaRoHv2lTVBiSpu4YnwClT1jQMNakXXxPKjtRPZ61PU11DF97UjdTPNDWc PpEF9XVddeTnqa2s07vq+vSuMpL+pP17gi0+9xiTPfdH5g7uwIu5+hdy2ou4RRtwN3zCXort ql2ml2N4L9qht+t/Zz71nmLOeHmWPL5I0apX6vAh/UjoeCgfYhOiz+ULeGKcAPmAJmsu1dWe /wa/yeUTMPB1G3ltDJw2C0k3uIpDJnntkKkoaIJSSmDF53Lhsj3/hWmQDlBY8vZKET2DXKko Co/P0nWe7H9rKqQHFNntpvtnTA/pG8Ws6ledVyD+U0aGyEhUVPerbg2dCqFFoe2h1lBHiA0x qMofEEnbAnQ8AippVCANae8bht3X9sB8ZwZJywBtD5BJewBL2kKPGeT5ANFxYemYkId6cCtO EUaXAEfAcYxGI4N4RFqy3Z86Okyn63RcecEB/Okkh/Q6PHb19Z1GLfTU9uk9aKUZ4A1JFmVB Zng9Y/CuKHTLnigEWZjNlq+FTS0g29RSZVT5+1X1DQSwWmSkjOpMJlXE+40NTyz7sPnx0brc Vj7viiXPsJkHdw5Z1ND3lq4laP0NCy67/52uVwhuj86fZDrxyEfgP/eDIBlm0jGySFGXlm5a 6rQ0aLkLEboyq12r3dCtQBMb3oswGbGemCKEYiw20PyCSDpQUMmwCirpRkEn3ShUktc99N4b oL6zvlM/2NSX/Pr0jprDJBUWxgZ5BwXHeccFm73NwZ+gnzCPaE/pT0VUUQvLc9EcZi63TF2k rdGeVvdK++S9qhpQ16t/R4yraKp7oXu1m3HDdvScmekNSKOacbO2gO14NE4BCbjdCjjfxhhu OkaxNvqGGF1ND0ELd7FLJCPqKooCghrWcQx8aa4lx0Gxki2EEEAITVf28gnQJCgFTXIW7EfO gCbBE2gSnIVXEByBEXJHeGXMT/HPTzHPT7HQX3xYgIVCvYAEF7lMkMllAkVr0neX077DZZ9o 9cFQVj9jUXwLQRd7h+wvtlncfgAJa8dHF58mKLWYdjLmA0Ztpd50Av/16Q2aWjDeNELrUhjk +VQRMKo9BIOCgoU7vkBV335M3a6Cr37+Qe7fiz+788X/KtwZXj1543NP3TH3Hrgu+NJhWADl FyBau/Px6Lz5v3r36Ou3YR58Vf4kG8O4VAr6ox1mhaRJ5WEtUl6mlZfXav38/aMDy68sb9Ka yudqc8qbe2/S1pc9EvhJ5FnNX9qeP9lGeqAEA2aYQE+HnyvdF3659GD4cOkf/B+WioMDME6Y gkF6x0P7iFNJWdOeP26OIlBhsDCUrSivrmVrK65kr6iYKDZmZ4pzssvVDeqb6rfat1mjf7UL snplcXWwb9IXmlq2sAyVxSpd9a57XdtceRe3zbXT9ZWLcRFCVygLUwmTxvufU+5AOVqSDJNL pZjCE27gylC2F6KczhVjggQLtVAFuUHoAV8sJoDupoMhJXLfGKOUTdOnUe5DEYuwThvXzpku cjfAU6GQThZjBkmfTQDCAzFEORPeP9FGqKqYYCrpNAz8l6mQ1hXTduH9c1SAFLeja0xXiQky eiaR6Z3ZmeFqMddqI1Saac8fdYDT+8ijM33IQVOLp6p713bUou21sDZIXmAeuXWQMoFgOlRU STG6kuJoJcXoyuLX+MM8KuTrecT7SA3vI+fw9BreRfqSp1yBD5FX4FXSflLy+CjpUF4n7eX7 DDiP4A7Kn8YF5Z6kptMRgBZjzX78McH2E9n6zq7sCQMjfY9rW/A+/quFhidYS2iA4n4L3oCW NKGATE11v3796bemuoQQgVByKbKZKqaHYCrD8IILWaSBT2Lqpu+fu/OVYUuuqJn3wSxYNWTj 6pUFraEbjty58bnRuhQseiUWvO7gwil9F8yZ/USm4PYJQ59fN3LtSJ9LixSn5Rt6XdLYEmq5 a7g57aqLVpw6u+6SAfDD0phe2lB5RfM1oy65EesnYENuDpvE1OQBcbjVXKrqvfRL9OE6W59o TaDCRJmaKujr71twecGixJaEODA4MHpV8Kpoo3iNOiU4JTpXnKfO0RcE50U7Eu/6Pgx9GHk3 fsJ3In48kU8EUmxWz/pr2IH6UPYqfbL+sfKPgpyuGC4mEIvxRJ7HXApwhR0xHnY4IQa+MQvJ gIaLj8hQl025WV4jswkq1RMmGVi5Pf+JqZCBlkP2vqXWYOBLiqUyuR1BT5lQew0Zb3kp9Fah Kg9FKA9FJQ9FK08agA4It8DtsBWegmwhrIejIAMJmRQQpIU6eQjUyRMglTGQYhMkpEW5MDk1 QB4HKbuAHsqPw4XD+odgD0WKYMriugadYNPpE3TTA/cAFsxUNnsoAmEeuhi0eInopbLX70ME jUoMhmJITTXBoQ1PDbx/9sYjc5cdu3nyvRcZTy9f8fwzS5fsys3hXt00Zszm/ENP5s7eNWJg 11nmqUMH3/7j22/9iUjkeiyRd+Fx781gXSxIuyJEyzAtS52xKHGAjAOkHaDYAVIOUOQASQdI EHpeTSC2yFc0ULpKGlw8sWhG0SrpHumO4qe9z1e8zmhSMBIK9h5ecTTIRdEEhPS+UA5NEadI U+QpyhR1ijZXnCvNlecqc9W5WlumrcRdkikuKS7rVzxZblSmZ6aXLk0tLV5T/CP5UfX+0gcr Huj9lPys+mTJU6V7Mr/OBOi7kNEocoCUAxQ7gP2+vPMKvPNSvPOa/ISC9vxHpideO1ksSasy G0lk/KxyUUGEcOGicAVBisJwfXhUeGp4Z/hwmHeHC8MLw8fCbGH43jAKv4rZrB+T3HNEfpo+ croOTYh0eAQiAHWIMA517PEFqsnW1F1GNYQXTSmYX4AKYn6BtbgvmoCBTyjKEcD0EpRjYxcp hREYKQ6b3lB1X3J5DSGNcMgqCe6GAwR3wwlyZThBrgpTHhgOkPcnR/HYH0DXACH/9T6CAkJx Ob7R3ljtkXJYTp5Jri8nIpTclALk+nIis8gtyglfJ3cpj9AWJEvKq5v7dvRF9X3X9EV9dazN FAPaFKBTfTZhdT6iSELfiGJLIWlbgmJhothNac1N2+5OkJPdRGZmSBPcLvJ8NxWQbp6qWEXH AKwHozBfC/ep7k8NmKaWBof2CIVhlpTtXDzSYfDZbEu2oTN7njrxQczh8ba+s4Wyd0yCWUyn dGMxeJu/Y83ZLOkVT3G+ioyhe3SvzvBFWiIKpFIhCrleuIj78G7SlYqCopSmimVyFJaWSDKf ZaOgUC8gOnZWxxq5VVBtqTy7du1a0INZwKbFLU3nK8hJ3v4Bi/xLMiUXISxU+lvsoVuzCmKB EoxjOUKlTv1u9503r1pRk/7RGw+PumxA+X3jbnl1stGqLpmzam4gUBm947UHJ85545bD78NL YvMWzxh8SSqU7nvl2pHDVpYWZq+4eVZo7JSx/VOxAq9cXHXZqimTt139AuEgt2MOcpxE5uDt +0EED7jkD1ajhDdQ7SaGXNjjq856YbHoDajQG1B4IBtYHwFVAcd+CziMP9BtvwXSoSAxtCLU igtS+y3oIQw42K2VBKlWEuy23ILUcgsSmUEtt6BKEChILDeNIEg+CDuCMDgyQpCyhBhtkVMR tCiyPdIayUdYovbjxqgU4VQqDdS0RCmQ2FoSBFJCOiIdl1iJNJy0iACmQVol0bZIMmmHRJ5I JYBErTYJkdZII8PDRofO69EY76he/QPzjOoXJ4h2UV9HdQgLxSKs7tLcGuIFkRc5EZtorBoF mmhEATHQysvXYjGBr0zWkKHOlGRqjCoDIwBBkH4EZupX/fHaJ0fpSpti3DBmzD0Xtz3adsWC UTVL0P1de+7uM2zMuHs3otqzH5ARxcPanzsAGNhgakgmHcLQkgg3R4E8ZxoEQgrpKYaW+HCX o1Z2EfUTH2ZJpzK0pFdTXZNcrRCI60fImiP8rv+AarqtrrG2vftY26I03ZppjFVurpDbxh3j 2FG4OMUxhdwibg2X51hsCMuIofY1vRO1kf1VNdXbAOzA9hg6byg7g0eN64IfGN4+aniLBJXw Gbk22+LOO46Rc6ZMoZHsBcNp8Qc8eNiqru/TG9K973+w7Wzc3sYd+G4ooZvi/NeonHsYBGHh fqDiR5H+UtptQHQAwQF4B5DJS6Yy1RQ5x2FgTRjbiKomQwYEdCnrlrFGxShuvQgUQe0CJUe2 lBwV5gVxiDSkWVgkrBG2CCwQEsJ2oVXoEI4IvEA0J9JFgqU5UeBrqrMLFs3aADW0LUcGT4BT RBHDEE8tSiIYSO8JB9BczBz67Zr5vf7Cak+n5abQT5yuIxiPu4+oPEZVlf4m6UT71HSQ4nSN kaqpMvpjLShl+AhiIz0you66+RV33LFn715vtjT++Db90hlPoOs3Q2F+7u7NXT9qqIjgsR+O LcU41nH8oAA+ZgYLQcyPJjBNXJM0QZnBzOMWSjMU0U/MG9JeAwPmWAIVxEhZ4nmf+853JsL2 8QwM94ld5mmIXBYb45kSHhub5lkQmRZbwa/wn0FnQjoIQLcWDI4ONAcWBbBy696ib9eRrrPR mCyAA5bEpz1LJbuLdBsRhw94Y6yCGdUpOrxBhx0SVkYNpKCpYUuL9rtGxoa0SiPilvSzRm4l YRnbqkEtUkhwI52pJtuXiEFVCAsDBGunUE5bZTlWdIoNOsUMvVgwi8uriV9glMDYHgDLG5Cg PhRqOQkxOuqW3yBGx5fqC0I4bsvX7nHNUg/hCVyH2doZytoaLJ22swuP6AnqI2iq62qpI8yN ariwiRpJsGWx4yLQQVVfYPiEJGVgMJmhZhJz7YGKL/d/lvsK+v7rj9AFz52Ud6+7fnPXB2iM OmDinauehRODT7bBQqyxq7A091HuWz2x88Bs+MD6QbOfJlbOUCyrjmHOZmBMeM1cJWP2lNaq tcEaV+OriV2NxstjfeNis9B0boZ0va851lH4HvdH74fhj70f+74K/iP8ccHxwnxhoLAwG6kL 1EWGRxYVbikULkLF2kWBgahGG46GaEN9V8aulidqs7SP+U8D38HTLh36GZeiu0E0pggGkP2Y OkOO9CPAS6TTQ1WEfX39EuWvacPtnHCh46iEOo7Sun7EgLphGs3GGoMtpAZRITWIDA9BMIM6 AAjtGjwhXIMqXAa5AxWWBkU+g2ATGUzDepgFmM3U+bbU5hyWYWTxj2JBp/ihkyOvCYeFY0Je YB3ciffAl7jli6P4QjUzIUKxBuPL6B74QkQfxY5uA4hW1ulUOHZl605QxKmvIz+j1rDtIawJ tdiSrsb2JmHeCntYQ8yAGQdX/3HZ3Pdub95auacr8cKy5T/bcfOKx9c/tvnsk9sgs2nMZcj1 3VDkeeetX77xwTsHgeWX5jOYT6TQ3/YDr02FukOOHgcwHKDAEWgxB4g6QMQBCiyfiH0OAaIO EHEA1eHsmgO4HMDtAF7yUEq7DuBxAMMBvA7K6A7gcQDDATTH0hEdAIuRP5sNiladZk+wJ6S/ Bj9OcH/kziRQUEykpFA0ITFMKh7j/TE8mNhaT0XCunwkDbekt6dROhiMuNJbDGiwFO2ooWFQ HY2inY8gg0EM7yBBDgNR5FMp8lGfkeEEHXqgIGwy4yHKqCxTNETVh1B6SxRG6QOi3Q+I0gdE icvUIA+IUsd5lHo2cW3OUgWjVBWMOu6pKHlCKUBVKXr7FMXzFMXzVBoeAZC4cVEhIBYEQ7QA W0/QLaOFagvUkwQCtpv+XJutMJw2fdRfbykJ1MUEwsXpdrhiT5IoDNmR33MAUF7Z0ytAXU89 aKFr5JAZgz/B9n99XV0d1gkb9E690whSzdDWDV2qz5vxqUYUejS/7bBf6/DUH6oh3cqI5U0I kqKnL59AGCBe/cf7Pj13+YOFt7712HN7UlMuXfTjtknTR6wdyGYeGDn1ukkHdu7rKkE/nT91 4ANPdT2Idq9YMfqR+7rex3x2IyanOqJBAgE+Y4Z76pA8LYUf6pMU4ByApS6X72uYPC2FH2qb FOAcgCX6Z8H39U+elsIPdVEKcA5AnzyQQBLVTkdJW6TtUqvUIR2TTkkCkAqlRdIaaZtddVzK S3IhNg+gwCJG4hkij3vRp94KAc/xrMwLaQ6w29jtbCvbwR5n+Q72FIsAm2CP4D2WdVRStjsW xFKVlKUqKUtVUtZyCVPA0krZbmWUHSleqIwSzKKaKGabWSplyY/I2cUt/xM+ZL01VX4Gc9GN bW1t7D8OHz7rZzPYHCDRzvyn3Ifce8AFojBgDo+4oU/3+aLBaJRlddy8oBJlnw3uc73hYoLB UBQlCkxjlHdU0IxM4iZJV+sTjKneycGpoYmRq6N3BR9GejjOMJ64Ivkd7uZ3WKqfGE80eunP JAQoWM6Oyy1t0tZJv3Q00FOOBvo5dfQJDkcjOqlZT8VNZE0BLHDT0KibErub3tydIZFRkaKe qlL3N6VkqrmCcOz6Kd0yqomKp5F6U7fl5mgz9Z1U0QdNTU0tXh0k+7Ievw+xqaJi1N/SX6oR JiRwPdwI+70Nhz7fltv32uHcgR2/hQV/+guMrvzsvt/l/oTeggvgT1/P/ey/juW27/0tnPyL 3L9zh2E1jO6Byo9yH+N2rsOD8AaWSwb4yGyo9EKdhSm2mh3EjmNnsktZXjJESZQ0ryFpgBGh Qp2qQJZKt4hQLEp4oRcVGfTtDcrqDMrqDMtcsszbnqHEHhaSbd7aFhJPed4F3I7auXa30VgW GOkZdvBCXLRNWr3p9GJs11K3Zq1hmba1QH9zg+uWg0SoL4ZNDk8KCtQpjjnQuicunVN/zbWX Xn75xdf64mzm8ZYrBj5TMqy+eXHXe7jNr2E+s5ZaqkWYy9BhZmiJBMpxBJvLfOtwmW9tq5Uj g87QEh8+26ZarOCshXsQARFR63PAJZYVWlVtbXv1tralZdY2ZVmnewri1jYUsazVck2vTnBb uJ0cwyRw396LJUorYCtppPAYtkg5TwJXbgEMPZ06NEDI7vUvnEj9l06k/oxpSZ0ExdIn2KON 57u4adCUSbvXAAibGgnZO0ZT1rZEL+D4xmuvU/MTgccAYLtwz2kgBE6Z8RnGPB8arg/3XaNf 42MVNe52uUAwRJIOgOhxyNTTQxeyTBNPRiStMwgsyqS1ok7aSLQLsxdBCzGSiED8FwlpdGQ0 ioga7Wft/5qhYCqOtOX/c35C+OIpPb0qdXZ2QotFrjapOgkKJD+ByMUqI9mX+sVQMmlgmOiM 2MBIPobK7m+Yf3/jl7k3cxvhza881jSizx25O7kDLs+MfQteznV1vcDAzaun3O7XbH2RIZka PvjAfhDAo+8PVjMkPEjlfpqtYYYwBzSWVvmD4eqgaKiGj+EgcMc4wafIqqOVqU7HqqTfym3n E001kGCHhLkuIb0A9YZJ1Bsm0WwGqTubwfZARch51ANF1XyJ+sSkbp+YRLMZyPF91DU1MkCw r4w4wwKnAmhRYHugNZAPsAHko5zCRzmFjw6Z73/mF/9DKoP4vVSGQI9UBmQxC//3BZeduED8 Yj20oG5/GaCWADYEurMWXLxLSLt4NQo10e0oPwCboZAivBUv6anTtN3asfznw9uWzRt9N1ZR ur6+v+mpR7umosc33Dzunlu6Xsa0MTh/ki3B/FYDYfjaPn+INNXruDPcRJmdQX3l9IBHkMPq MP4KcSLfKM7i54hitT7QMzBQExqiD/cMDwwJTeGmSGP1Jk9TYGxoAbdAmq4v8CwITA/dCP0S z2nXMOO58fI16nxmBjdDnq/KwRgrGFjZ9jlI4XMsQB8ZSC8dmOIotfaiFDGICLSsPYHaeXb2 A5GQtmA85QjGUzQUZgtPCnSYruJ0dW8BAkEXEtiMIygoU1WpzzGscZMzFhBXAoZdFCtcqhV5 pgHrYqC6CNV6KMnS5AsQowNPnQW2Dkw1fhCgQ2/ixxHlGgHqZgD0boTEcdknQtwJFCG6GZnl KG3JYpJuOl+Z7SmFiT2I2aApjePGSddx10ks5obUWe7V+2MUAJYLHHh7WIiDn7rz13+BgZv/ cdexXOf+3RvW796zbsNu5IUl9yzP/bXr0D9ug3GovfP2O7//9dtvYXx/CFuHbkztOhM0VbFc wU1HtLQSVPYDkVAdeX/RpRloAqL826DuzS/NUgKpHnKYc6uMBCASJcUFRAkrxzzNT6LmhYIJ ZR9NTNKBFeCxBLHDGs9ZrJHEmw/RAnO3jg79yJEOEo3IZi2OD6K7eJo1UyhQkcHTkqElS0su YbPpr80UgRBlsQyV5IgGVCQav5RVG02+caxGGpLlJ2Q4qCZkT7WbFpzKAOhSgChC1DPyarkX 5JfRROABOppoajYv521Gbt0WQPIupytPWxReV2e9TFMP+WWFPqLmaoDcog9FRXa5ul79Le5K 9Ur1SjdTxqa1Ctck5hp2ubbCtUETFcSJtVo/1yg0nBksmGKDdrlLfgg9zGwVtoo7mGcE3oOw lOvNIR/HIRHjYm9OxKCojnWPJQE5JJJZV5hvulw6GadmzxoP8hxAO4AG++zmEmI77GMGVEmm toxMfatywlRXK1A5gF/YBRV8FmrHGzfsmXtB0QRDCfciHertaOJLCa6ZW8NhXQDt2GNcjIV7 WD/ddLqpLtRFeGEntrg78V6kx+6JJhDCcq1O7/GN6J2dG7iLshtuObjhohDZYL1qeKsybnhr fMzkSa8CNX8WY+lRgPJHBwwY0AiHt6r4WClN5tHy3+xyyaQWExLZfW9fstZVkazV2jHYv9bV tz8F9/bCtb1qrUFpJDGpliZMbITasFiF2JzsD5OY38IUNB6CxfCa3oFwDZwKuZdzE3fmJnEH zn593xWjf8Kc+24o+/bZGvb42QSRpVuxPlKOqYsDt5kqRCwT54CYYCHbjp4xkwKy1DrGZRmS VHv7X6c3nnG0hm8crYHvqTXYSoP+SZOVzUhyGEkW49bX0R+wtvTPF0n7krkxzJdsBkTQPLPQ HbKEo5VhRT2rtHSzttPltFlpMUrqcqGlap1hsU5aalaQSXU0K5PikRWAspPeCmSfm1GYWNjt 4RXea3rcCcVUE27qBXGHK7ORDyOhQxgfyIbq1jQkGd3jjpGEs4/MBbHaUt9E906ZMTXTjdyJ 0t7VOikEVfIEtJCnRClRS7R+aj+txvWwoZR6Sr1XBBo9jd5G/xzPHO8c/0p+ubbSuMl3k3+d tsnY7NnsvdP3kLxDeUV/2Tjg+1z+1PcvrUv/1pePxT020wl4lViUdQ923+Fm3OHu5lu6v6e2 iWr+UbO/263qhscjAybs83rTHtmHd9yq21DTioytXtlLEq8UntwAxPQYqoy9FkOxdlS/1437 wvS1o/GmUu8xPWiq5zVMm+3w8n1uWASGRGVyiPaWmVB7q6NUZrSaV5GKz9hTSZLxUH1bNLFq ZiiLO6+r5XRTSyRE6Sqknz4R1k80tXRGQnonhTChddZTAiPEJd6iH8TbUNaFAYDfZINLr6sT Dw5vdWFaCmFaehnT2Umg5E9CTE2NmIVRgvLlP8JUJBdhSsIaxF5/rVHkp1TUSHygmIiymIou tMhB1ltiZQDhL6zyEtryVkFsGGFZttp3cUXdFUEjwym5Ba9/mC0qzP69LTf/suLeqyZW52Y9 q5cWR+e5C9jSroeXrV21HM07+9udlzeOI7i8A9PaOkxrEnjCvIRmGN+LTW0nyRiIwqMJlFAQ iij/n7KKv6ez536gs8sXT/kfc4pPdGvrTd/PJ97BfHjuY9TaNZrkEg98sWsm8U1MyH/KGlwH 0EEBcpuaRV9uqkzwRFOjUUguRH0IOimjpJbm2llnRakZS724vEWhVPWhHm6bCuVInOV8cU0L Sk7ag0QzB6nibQCaswcC1ltfIJ4P2QqKI44vuJOVlSQRKW/7Yb+0khHxLa3MCJqYAahBdYHE t+7ZxifCegz36248Wr/IH8cmyHHgwT83tjdGsvwGtFHZ6H7TxUmCEkJDvCP8V4UHRcd7p/in hMdG5wnzlOu98/3zws3RlehGfrlyk3sD/5CwVX8z9AE6yh9V/uKOdDfX0UAvCE6ZNNkuuEQy k1g9JBFyXUKS47KhXRSjfrQthbbLoacTYgm1JhL40gQgOfWWGmj5ZOgZYEv8N3d1K4NOFmq3 IXDe/wIGkA8kIq2xB/Fg3Y+GBgIev07ypUoyXp2Qk6Fj9U/gJ8x7d/vy3Usvn/vu4++tvG// s6tWPfvsrauuakLvQhZe8sLUPbn8B7lc7lcvPvQS/Gnuwa9Owdlw7pdz1hMKIliX5J4GcXjO 9HotDk5LhSZl0le33JYh2zF50gxSF71qJZtRMRZyuslxfVIvOTnJCryQUgnZzsmT1FAkZ+/R eiidJIdIozlpMZcc9/tjnnb0sqm4WTYe01xYpw8R9xhB0JCVoIMBgpiVhyqdfN2ug/rBLEmK LvNYOTS0HB5ZWbCpYKv3Ge+v1KPqX6Ki5A25yiOM1JvrrRzAWMZgLNO9st/j9b7lcvtcXp/L rbWjp0wvaYjp2u5CLpfb9EO7US+5WfgumVDRDkOmQZpnTNUX6qv1e3VWXyM4GCY4GCZ0Y5iw JEQxLARBSA8h/CKnXyJNDG1JeF6BNcANH8Aq2YDdrr3wABwAAHGodKPVlsJ2eP8uikcYiU7j L8YiG4mwTkWjknZM0sA/vVM/sUG8KMvZ3B2jGEUukr75PfbcIwHHyuH0Yi7FWNaGQGJTE171 Pzz/trYXN1+9ufTZe9D7XS+NuuO+Diguvfv0b7vgGn3TXQefeGT3qPoA+u8Xcsun5M78/jf3 7T5O8OspALgiMgcEqkQV68Ai1V+NdSJJ3i4fkZHMIaSIIif2yBawOo16YyTCp8WEIPBEAadJ sDTwRxNhqSOJJy6JcmoZQJoA27RGgxpSKLdXKJUqlNsrFrcnlCrjJvwv2L5os/1/n1e6AvZU koQGE9porVlbpLFEyW1q6WH5O3a/VVNHMyLpFIW62ibbc0MN+iT+pXD51Ovou9df7+KxCf80 mvzdULSnqwG3dCMAzDek59Ab+yxtUerRN187sYWvzT4UxyjR8rTkbJgayvxEfrLEuLV/cmd4 bGGQt+YtDEVWQin1tjgAQ0iXsuwJzI0y8vAJb7IaP+7UHk8JSdM41Ya3Ho5WJGmFeQeu4VmW Y/n+0jCWS/O95Enyjcwy+QPm77zwNA9TfEZIi7X8AKleG6U1so38JKFRuoVdyT0svcH/gT3K n+A/E/7Nfyv6PbLMMQyLeF6QJBHvSKKYFngfRgCGZdOcjK0aWZbwDrbOAF1OAo8SkNl26DYl jqXJ7UUi2RuSoPMDdMt5vgUjhY0NlCMrFo9LA0QrEa1EtBKlIdziJN2RkFmfH4TMrAQbD8UP Tw+PcVjV/pocNrNncKyphcS5CMe3nO8tZ4jb/XS2E1iKGEELI1hL9DG2pz4m6GKdWMfQ0ha5 2nAJFkp3MEgKaUY1mcJiq2SmLFUU1EpiQUEdHtqPdhfU4s17uxN0sytpWTiN1LxpwcKEKnF8 vmN3spaEeHYHyOaj3Xotb23onko3uxTHPCLWK3mU50MWir4AfprPV0cLfNWZ3SFy8Re7otbp xGXRZEMt3UKM4DysgticEoyNbfC5z3Jz4Wsf5R5fzR049wpszS3vmo4Kb8pdg3G/Dut1AtaF 4ii0Hwg0L5Ni/TfnQyg2HVheR8JzLWFidZVk6FrI6+WtILFhUOBLUyK+Gy3u4+JUQpET4nFy NB5z4SNxSjFxInZUJAeDiULdQChRSLLi3ztEykOgkqZc0nzKg2T+ja1YkQeqHg9NazltSm4D Oc85bioeL5oQ95E6cu/d+NbWC9g5gC6aA/gfnkY0JPI88jT6MLPfxdzF/Mvca/zLwm/EN2PC lWqjOt41T53uuslzk/dOzyuejyMfR09F1NeUl7woqsf0Aj2u87/In8K9eBxbzKeAhEk2Epd1 keffikV8sVhEjEUYiMRIjNHi2IZ/as8oAxpYtO0lbwBIk/dApMqOWJMd5iMTjki1S3lJ8F3M 7Ilogy+jtSABdDjAVI299WgqWohWIxYdQMWgEN5riy8quur007YjFJuqRHYRVwlNRd3guogS gZUzCBydaADJH19sa0ZpfzLTn0w+6BZaNAZM3GPYqhBY4Vx/FEw/+chXOx6++bZH4X7vN79/ 98wVz7z+xJT4iy9eVnd9x60HP54570ePbvIefv/zFyc998pTG6f1wXp4vgtLrEbMdwXgQgVE LfnGeW0rx0FyppxwDkDCnpZSJFrTNVgq/kX7JHtCjMjbHPu0tY9UO6Rz2rysRzg5YIXyKKui KcCWO4aTLfOF3p/CAoWhy61TD93XbTZg+aEQuW/jee+XNeWnUu+tzxJnS836RmaL/ib3Bt+h n9IVkWuEE9FofbbSqv9T/af2T5fEqqzGuhhFxlyVVTWXyAvY0OZYkVcFCKgwdFuBHEHF7FlF DEPq/FSIJFjVh6+S4hwnxnmGb0eLTAmI6mcmtsrQAagACBXToybADIEZO5o9zB5jmS3ERQKh qYxWO4RjKrNFhSrZ193CYQGtFtZgbv4j99E/YQTCRm4Y//BfqNNyInVi07Yu0ll/ok7vxH+E nWYJO8XcNGsjEonUbdAPHnQdxFzW2mL2ed6p1Ma6GVE4gEkE5L8ZQL1Ki1t6eGl/+ElhbpZi kow3yWRKeIFBVb9Hkz58vusnj78P//vhoUWxKhKigq/kBqPJcOv+G+++i2hEj+c/pRqRD6qm nHFPYieJb4osDV8Q3aiavVgcyl4lLnc/zZ10CypABmEavORzVKSe3vQz+4hu48sgJ9aGuvUj RGUVIhzoIuoXbUoEYCIwOoBIUt+aABP4D2GsTEKGsqMjyVRHkh0dSXZ0JLlbR5JZ2ztq6Uhy t2NKbvITvahnNh2h9Qa9qamlZzyrs54GsrKYsqsMO+RM832pOmqwza9Pz51973e57xa9PuzF W47uw6Ji14e5c0/eA7XPmFHndr+297rXoQ/36sT8J2wAS4wsbNt33lRx6LSnpWEq4RCNOIRi gGYvZlVidJSlZGxzu+OyXOaPx9h4WYwr01KaGgpD4EnQvkwIGXpPfHqmkpiwxPbA1oentr6e 5LJglt35hv6GpxZbIX3Jj7DsUk4LaEO09Ro7xLjaWB5lxgbm63N90wPLtJW+9dom353Rn2ky l6CxNYUsjcUKED8XEk5MjIyXIVnNSIM1+GX8bOgAegqE0WxTwq3kcDM1j8OYL4hpWvaGZ8nU xMIEStD4TuL/YppkqGmSgWSuG8o4pklmS69QOzZJwu/+J5Ok4kKTpIdBYg04tcy66LyyTp2y eGeyAWboJIAJrTmVPe0PoX9PU8SZJ8QLpATYGJnYVvjAvNU7n7ilaoTPoyxpXz93zmZfW/Lz n694a97M6bdtyZ08+ss8vD308IbW21Y97nsMrbjl+tvuuCOx9zezdk+f+uhF8Vfv6cj96xPi c7k8N4b5nL0UxEE5/LXZrCicr0JJ+0YoQ3y8VBAuqFAyvopUrdLPd5Uy1DdRmKTMVr6T/+V3 XZSqKLk0dWnJiJItFdsrhH7JfmX1FUOVockhZeOT48vmCNcnry9rrlhT8UHJyeSXqa9KjGCA 97ejXW2lMa9AJ9vqCdCbTrVdAzrAESxu2tEtps7FYm55SFFMlQP+qnRVT2H7tSOHvjFLqNRN h0JHglAPmsHm4JogW4FpEk2ooLgdpLmTwe7cySDNnQwG6DESY7MmGnjsiQZWcCNoBWUo8J3j JPnOnE19I0vdMA2KCimzKKTqciFVlwuLX3Mfdh9z591sobvePcrN2J4rqhm4aeatO0JnuxTR 2S4k+c6Z40IzKd3hbMXSZPWFOWVNLQ3W1EW9Zz4lTaikORhniL17wjZ5T1hcpAU0tQTJTBHq aSzBhiuyciqDNZij0JkjPcNmM3cqfQctvWVjyAWXt/7l1A2/v/uVm56e8Zftv/j84advWbXj xZtW7JgUGZPuO31y/9a7YN2HD0G4+aE15+Z+c3jF80z57ztee+dXb/yKcHQvRqU13LsgCMvM uE+C7nBluHfYDC8K/0R9VHtWEyNaqdYa7gizYcJvzEhhdYGoMao7JkM/yvq8LMMDeZsP+vJe 2r9ek7UmsAVpRwdVa+IoCxh0P7SmBvSxpwZkY4XV2FoJm3RelKkRU8VHTdtSatcWUeOlwjZt v7ZNW59t2n7u5L98Qj14xPh9idozT4bCr8ADIAnOQBnggTnTcwyIUXsa2y62WdPZRDyddVSL w0KWxrJ9usFLAi/yiNclTxQYvDsKyeyOtWthtqUJLK4iKfA11f3PJ8n4/SQdfve2bd7I7ctH TIkO6Dt28OHDzCObW+ZVD73a81N5aPN1m8/NxFS7Pn+SLSTxS1AA3zRvhpzqLuZquCEcV1/Y WogKC7HkjV0eIxnN/EAvSW8eERgRaRKbtEnupsC1kbnifG22+4bADZGOwvfVD4IfhP/m/SL4 RfjvNCc6nOAq3ZW+3ly92+RGuEdzM7kPCv7Ffqerut/F8ghESVaS7I+5Lkh9thhriPRxmqZ6 Fh9RoK6YSrOyRmGtjGaF+leVkB0ePUNNbsUJbiuOIxUDxylB0sUcxtHFG5ZCA1Fno7WeQBWg 8+4BDdPYSQrWmgpVDMUWhmIOk0boP88CzTnZ+850ULXHdFDPBdNBv/n+dNAQnQ7qs6aDxodd mDXfYzoorTtBs5+7DzlCwcp96DkpNJmykhziyK9jNl/C+ILnaRX2eqZt8a7rdraYua9ffWUe qp5w3/IXfrZs+Qvcga5/3Tvq3reW5L7KHf0p3PrahLsOvX3kjUOEuz+X+wjezmYAQ9b0MyuX KLcrP1KeVE4pHFBgRu4vD5UnyjPkvfLfZEGRXQLL1EGhjuc5F6s8L7fD0WaKq2Mhz8rYpgEc L9Sx8gBlIFfJ1rOIRPQedz/+kKWO1pGZr8Sgx3Z9vd7V1UnjmFgnIJonoHNAWsDiFpqZiH8+ Ktj67zt06NDoq/vW9mOYxkOHzj1z6FDLXZmG8LRrCFc5gIsN4BBufdoMoTogo7qpYCFYDXYC djs+vp2lDz/T1ISf2dmndxW+7wF8Q/Lmj+PmvogpJASK0EAz6VFc0NMvNrlwprigkJWof0ek paDbk0Y7KC5qjh9IdQDFAbBS8bc9nki1h/h+ikqqDbJfUFKt21u3vcXH/7ynIGMdx+fr9pYc N6/EQNp1VeyqxDhlSmxBbLG0wrXSvU7e6H5Qe9bd7j7p+tStY7smYbh9huE23CpmHigZCci8 h1jYXEiSAsFIOB4kLba99x2mnwqzIEgW0bBPKOR2u8S4oy/HHRka73YpxjOuR3knAsI7ei31 JVZTryJPp9Q3JYoXFa8pZoqLQqhHEjdVlUP/2+gR/0M3oh09Sl284z9Fj2zPYfhEyDaPLT8R DSVlswTLaiuppWwZysS/22OKUbe7habTmbJoumvd+kDDM5C6cVqo98eV/8iMhGuNonCtB/9c ZqxWL/LhXyH++W2fT7aRZJfZuhcWq94UcxEqyaRSNNGMEmbycbTp4Ds3vfVuQ+mEEfnTr0+4 4epeyeF/hY+v2zrywSdzvbkDo3678tGjBenikctyLbDPHZsHKELXMqaq/8phs2n8IUIyzzCN yqgfyTv52raNXXaCweeUvYpUY6EuuoCd6nzacQmdMqk1jOh0DlvDD3IikEUe8jLgJJGDiCsm o8NVZj88pH94yKiqIhFcwnyiL9VwEBQZtTKJMWtGrRTwxKpFUmDL6fM9eAvtrUxmF0jxZDUo xQWdgi8VpatBABd47wPz1tKLqkECF261DJRKGbkW1MhXgGHyRGxcN4qTpJlwJpojzpFWgBvh jWiluEK6Ud4AN6D1zJ3CRnGT9FPwkHSf/AJ4Qn4VvCTskt8Ev5Y/AH+UvwB/l8+C03IFfh05 BAJyKSDcaxQwsXVuegLVHO6casf1hd+HvDogDhvTTY0xQLUt0hekjs7jJ71CaxHHqQrRzz/M 4r7Bv0PZQ1lQWV9PmXPU7C8LopiWZJ8kyVj/QGmILVeIGyIDWRJFhCAvyBIDIFeJDfYi0TRN aQ0JnsHoXpNbwyEOQ6aUQCYsUj7/A+FY2GLvaupqioQ6TzRZE6dqu7HcqL0w76MRCwh7zYke 2N3U2J1NkzwfToY/z83/xYl0YSj7xf7cDWym645ZC8cvRxtJ7jcEPOaJL2FM83BT92MzxsY0 K/eLJisWqJYPmEw7oXKVs5LtqdxleqTZf25lierUPcPztlPoO2e+y3dWwMyawO1xDojdBwTe nirztRUks5Bdp+4hnrUd/efOrwPVI8TrcUKSYvcBQbXNg9NOzv9pi1SMIvvASSdUcNJKGTYS 1mHbmvjI8WF9tOc8Ce0HHmI60BQ8az0V3rb836P2L2vFBclMrIRqHehoc1mZ/x1mJYEMk+7L BgOBygsYJd0YZTSVp/LFgIiVWUO2Z9VYczEN4vI8pB89pL9H08HqCRbSlUessSaDHsVKiA+W s2Uyusq4xrjHYMj7UN/DcWc2wXFnBtgpUypMVuuxAit4Yb5UWFzN8qrk5aNS2MOxgOUVSXGJ Hh14GZ8QE6NKgasYpIVyMeuqBjXCQPFi12BmGG8KDeJwZZB7mHGV5xr3WM88Ybo4y7OSv0lY Ku7nD7j3ef7Fn5VKFaMUlGolrlJ3iafSNwD099worhcfYh5Un4E70A7laXUv2McfcP2WPcq/ L51kT7o/9Zzmv5NiChU4Ki113logx1oFgGZm2rQdlV1u1gMMURDTgjvtIot8uARGg2oaS+6j Zn8iajRMojQgBjXo8/KyYmTkrDGeHStPMeYbq4xNhmzILCZYMhzWwJzvaiujpTJ7Gv+Rff0E +VqrBOC/qOljOA7xgsBJsixidJZ1g0zwG76HA55Ee/5Kc6bsdiV+ZQhiQjA8niwn+DhOcOFx TmsurDK6RGyPZmXRhy8HXDc7AQgKHlZ0G6pLo83zaKpK1osj/MXjJjncsu+MrkESclujMVo7 fMaUE6NkuFBeLSO5HU0wpVEGXGisNojDbIKp6BxsprOqGcyBntkLz3jPzKTiNtxwuqkp1NXU gv8IJ2oKfdLNfpwENMsTTVmTQcsNDT250oUbjJUbXPpBwaXXkR+ByW94a+G4SW1aQk2gV/LH AcQ/V/5IG+jtTmA6Pk492tTPOLy1ehzNujyySyB+EVyRHDe8tYpms4n547uEhFXrsV2VRIAf 2edOkHtjTnBkt9Cb3HE3GIAOWE/qvnn3dUF6nZE/vkdOsAkwoGdGjyv/3j6splbgH4kYeYkC 0Ojo8rY2QXPjLly14X/6EJZMObI3SNhyiilh4PDcyweerWernt2/reaSfTtzbS8/W/YnzKJ/ csJ4C93Q9dDbh9DMsx+gVXvPHca8elVuDGrGFrUOLjHlEjcEukcQdb0dVu0B21wi3pqGsM11 LWB0JsEwzAvGTzdTXbjrTCeWLzTYSnQimEEGtjH7V2E0F3i/DuGxB37XMPmVtStLLknhd8iN eQV+A11fftB19kjjpq0vv5orzCUueP4MUy1FpTqSZB0Cj0RaIG/DBhSsagPbmGtdxHiz17ey Mltd1uxrCnxhumWZLOtR6EKuFzx2G0kXfa+d3hQwyNoXmZIqsnKSjrqwmZwtuqTkprWvTG44 nBsDj8O/vrJ/66bJfzjb9cGXua9zIrYLSKbhZ9YcYFAO1+0HLObZZTQzlh2ampiamVoi3SHx cyLLuEUStn642xW+JCAxoZLyeKBAcvyj3XkbNNkjSpMzJK8nXl5eVgZiBUSlLozHDSCGHI06 5GjUIWtNCqIOZ3gntvyJmaZqNc2j5im752ksnacxCJ4ajvz4tHO3tHO3NLmbl9wtnVFj5G4q nYhBpXMJuYMaqcDtoUo9FZpxqorH/18sD/n9DK7sf8ifHEn3G3rOXzwfqDq/QiRdKosasdDy aJJ5ij1UZly6UAom+1oxKqwt42P9L0UWvBVldry9ZOasdfdeveaXm3M/gpesHXDV8KG3PZb7 C1xwbWbQ5IHjH9icw0Zc4/4Z1z5dVfLKmlm7mvswY43AzIYrF5ad3S6oA+YNHbuyD9FtJKzb XIkxwcsk9gPdzs9125MnyDSpC5UJK2uHaiRUI+Cs0BSt1bqzyrzdWT1m1fksn4wHhmFAQWWe Mu8A2J8ZIA6QBmgDXTWe/l7Z4014ktUeUuCnHSc5Apq9leytSIys+RhgyVkMKbA2rKAMWyaU KuWujKcfO1AcqJA7XiGOZ5vEKcpk13jPLDiDnSvOU+a4ZniWsTeJK5WbtBs9N3rXs5uETfID bLv4kucN9k3xT+yfxfddRz2fsifFk65PPBU8VdhUA03QA6RURFISv8YeAtiiVVGB36eHZIO3 su1cBNJ5gDQgyghRSiUCIZu1cz6byL+ykCBZQptRdN3rdmka1HXN8Hi9Ch4RpCmM6pUVyOvI K8lebwJIPgAkBquTCZXxqSojSxKDNWqvhmUdECv90B8MRhKqSbM7p76UkLfIHTIjt8P2vVPR NoQQhkyZbzP10fphncHscCqWgSDs87+ebN5B3aeRcENXU+jjcGdTJ9awQ3TGbdMF0m0Dd4Ek I5lB+ON228mfPTdUih082EgFgIXf3Wyfyg0F20xKuBYSEzIUrfWQxIFordfaEBVxX7RWLIrW kvU9dsdq6QIPhbFaLzY3GfzTXIFgndcTCF4iYqu+jmExpBA77CJMUkWeWkUtSF4CQUGyTpEJ hAikeoO4zhvEdQRCGLpQ+vSUTNjehResSQOy2EyosnK7aSoCCdxBCfXPqZ9CeVyqzyBY8m5X F8qeyt1bmOzjz21B59AvchuX1Y++Gq7rajj3LVJ61YyO58h/NzmG1ZazXAeQwQfmYNme/EG1 ast8paVsZQBa7jhsYVbPY1eje9HDIvsCCyXAc4jBJpuK4FuylZxEgjDAzlU67syasCfFgBhl ZC6br50yw9Rta2dXUo4WUTlTc1tz91zkXhxMcCY2w8LKAVgH1wGiA50gndJzBZ+6BjrLlmg9 Diez+zGZMnheqOmHhSg623bZu+Mf/FvlUvbmS1cV/nzYW1MBIhY8q2PeIwMNvkTWf/nOfIHG FfmeuUhU0FidY+Uo0c7hrbwmq6NoaUXNrTi6QFMoRdGqp44AWnKitTQilVS0tDrZM0mdrT6i Pqu+qXIjmBHaj7EaCZGIrQ9G4GSFEcgMWe0thvUxDMtoABvArMC8jF4GItY/t5syYFl8CnhL ZtvRzJc4TjYLCqtlZxhkK7/VXpDPsjlgf1MTzKJUtbAmWSNscSNrDqSvGiAdJRCDLGOExmFP 7KP29l5XO9xMY2ZfEF86GQUqZer0T3Q6CPrpujN1zrTSDVZekNvtdpQ1DVOXh05gMJWqWqao Vy3DFhRQImjE40acPj7VVGrVNaNrVTNTqxbF8Nae59D4n/Q2kMWSqQZW0fVoGGyZbe26A/30 R2+80ZargVN/xuw7d9XPco8jFj3QNQ9YMy65yXjE3aAAhk1PohAOEi09wdDjbiAGHcneM8f2 jFlEZHUwk5Cg5Q2XqMAmE/lwSX3iEhX0NGkhUlhgr+1CJ3DpFGn0/7Wg/6GzLf6fJkrYC8Ne IN1p/KIfE7WWp2JFlg+HIiHEKzLWRmSG9wd8AW+A4aNMMAk9LlyExFgSBmQjCSj3KceftdCa mom1OTKVGusB6WRfO1mFzs+E3z4/+dbGpUtG3nTfoXW5XbD2vp/1GdLw4PyRL+be4Q74C0Zc lzt88Jlc7tlpfV/s12fIZ09/8u/yOH73BflPuf1YM03DkWYk6ov6UXMJvFb0Qg9TXAySniBK gzhdd4/kYmAjEPLBuItJxnkJYmaXLnbGptgZm2JrUi7u5GKsSidQoqSZ4u2J7nwCB4E/aLMz Ck6bVXR21eI1JbCkgOpjBXSwCqg+VkCzCKgjRaasSQ5nrncW37YmnTfYTs4me+FIIlu703jJ 4lPdC9M5S0MMZlPRWCQWjjG8mtHT/kxhRkyzmVQ6pBUkQcDtTeKTfd6EgPeKuHQSxhQ8ND4D F3EpmQTFDC6ALSDo6nTOp5yuMAFr0gZv5R9Ue4qr+mJhJFyEyExLbDj4PCyJKRrMCLTg3tyR 7X/ObWvbA0f/ZRuE92d2Jq/bt3Dd6zcmB2yA6L5bT12K6l+AXccXL9kPr/3zUbikbVb7j3sv WtMw5o5RG7cdzH2zZlp/aBA6Gsf8E03GY6mAIPizOWVbeGcYfSV85UXHhGNedFg47EWvCa95 0U5hpxdtE7Z50b3CvV50q3CrF50Vz/rQfHG+D00WJ/uQKqo+5POKQlB1K4Bxf+tivkUuDUG1 TgN1GiTBjErvQmG1cK/ACNA7wFfn0tQ6bFibwUi1axkUBoh1CII6hrkX03E41PKMtdYgGR+s 7J6g+VoUAvWYeuo69QtCHFaUg8Q5wOKWlhbYYn+wCeZPkTBf/yDuyGQPGPp+mSi/pqJ/NQN/ 7EDswd//bH3d6LKhwWuuPg9hrL8MtqO5aAG2eSrM8CK0iEENsAEhmAIowi3CJ4TZRXdbgk3/ BFQ2dOJ24Gd7a5L+y1AZ1p/2kv4exnyGRnJv0v7+izmS9vcp8ZQPQRH60HHhuBcdEY54UYfQ 4UWtQqsXPSE84UX3C/d70W3CbV60SFjkRTPEGT40Thxn97dbVRjge95LeljVcMe7cJdD8XmB VPSGeBgQqIPQ5a5Tca+XaMFLMWGQTteWIcTUAdzxJSABIZxL+xzbh3YsiXT4CZ3CmDBIT3d1 OtsLu7y7t1tIjIm8dhXJ26Yhpqoe8NW/LMxeU9GvhvmzA7Df4G6+eEzZsMDUcechYlHQ2Bk4 hKX6yL0yA4TnefI+GcjU4W6XIQlHMXgH8AOEgaOAFZjaDjiwXbFDYnRNNN1q+vlGW2Gq7vCX Ffw6H/aCYEr+U/YfmCZ6o1/vByV2eDXjxFnTNNOORlypvz9My4huLzl00pl5bgGKA8QcgE6Z ueS8MYNoCWl5PXM9u4RZyrLpkhqmNjaIuVIYUTCkcHDx0JJxTKMwpeDq0ju9rhThh/ai0haQ doCMA5Q4QIqKJutkC0g7QMYBSgj7HUqgUi1TjIqZknQ/d3VqcHpI5eTExNSE9HxlrjbPNdM3 I0RMnpvct+jLipek1zOblDu1Te679XXFt6fv17a6t/rjti3TK5nxRDMRKVMGMwCURTxs3z4Z MANTgNZrZfTOKIqmA1qveEkaprkAR9i5lSIY7yXF4wGGsuEsmd5mYVmTPdMtWFvZaX2jZq90 sUtTuCQW+1FR4FkG8TBdXITreC4e7RUxiaS4NwIjnQHQi0ojOmFYhwk4GjbDRXAL5DFTajVd vcgjyaNxi6+SnMBOd6q7ZItwDGVAGSwjISESry6zV9jEUKRvkmoHSSqCklQVxD0AMx6SFEdO 9jgqgqc7b9EznmgS4T62XGpqOEGsfDtJ+4wjpk53WuvtdzXRFVMtn6gRtBbFxmAjXRi+h+3x PWODJDbFUVVfW+4Xl2ToitnfW9qUDVKPAY+FT2bKS9rU396y8Llxo6dcnJs/Zs6sW7/+8ZPf rucOuF98tvXx2gHw/Ulrblp/9qe/yf3zYfgn/Ya7r758yeAhs1LBadn+T85Y+Mvpc95Z67rr nrXXjKqqmld68d7lyw4vWfoZ4X4NmLL82FopAOWIIf79U86aW6e6FzZ2IhXdKyVbZJPqntCT tOaf0dKaEyo6kQf+/Gx7qk3YsbhCNyyEUyEDo6VxU4Oa5sMIwhXFfZochyCtk6vo9DM9HtRp qhLNQQjSfISgPVfs0HuH9F876kET+f8HJDTVa14YDhZM/+Dw4MRkPKDzmOnCdHGuZ3piqbgs tk5cHzsqvhcwBBofKHHCAimaaEegZMJeSuB4W0kilUiSAwZp5WgNG+m+KHx3KrHCSLKd02ZI UuHA3u4Vo3v6ruxEuvQSnSbS6RDomAngFzxFc2r0LRXYXhhgeuNqDwcWxdZ4O6w1i+qDU4ML g6uDbJBO7wvSXgzSlQb+T3vXHt3EdebvvaPHyLIsWYBtsOwZv4RBYBsBa2QTLBkbkniJHXCI xZqHbAksMJaPJONDmyViE5rQbEO2PYcmbDYkbHc3IclBllkQJFvTJU1amm3SbJqekyc07dmm Z1OattuUpdj7u3fGxgTI2cd/e2L5d+/vft93X9/cGWnuzJ0pLNBuy2KVo56plWTa79bp99xp o1W7zQ5u0lf8aANz+jUzMTSpWTyKkN8szUekU3+wQL54zEABnTltQZB0ebRowW071gfu6mGB F7cdvzL8+v0Xxn/2N/t/8fx7V+rbH74j/q0jX/7SUcO6vO11a+pW/Ord3i3jn77x1Y/30DZ6 D33mO0//8x/f23g0mH3i0WPH4NHHcf7A79+x0Bf1ezVlvpBUXC6zTt58KhflFujrUUo4kxl+ nJrlmWazzMySJFsMjFnMMn8myWWxKaTJTcElfosQqSaTcfLOWOPUnbFG7eEFOEvwu8UTBDaq VqpaO6xbrIPWlNVolaeWieaKZaLixNyGRv33rvgbbnrFP6cxOP0ZL+IRIfwJIfoJ4NWVQuKh +zj7M4i5Gu24foovVDuZm79EVnP5+g8Pjj781yzO+I7L/lViMceJVT7Z79Wo12cun+3Dz/X3 T8wG9WqUSysE9VsrfOa8mcAMnv7diRmgJRotAZ3F6R9Gpm4HoFePah5tkfxiypcw0fzHX5HY 6Vf+OG48fXmv4d7/XGVIXU7BU3ZCpE8MbuJglJ+26ldcHVNrmbRl4tL0ZeKz7NRqMjCLiZls OSRHXx5e6xFXqPLFivCTdie1o2N8tYq/Y7Zvg/2g4aD8WN4h+xnjGdMZ8w/sFru/wDdHmmGZ ZZvjWEobrHvpw1a51nm3IWgOWrvyvkkfzXnUepJlc79nPZf3quNt6ceWH9necfw8x+m8Oh3o zLcX2RyT04Gc2cV0YE4OM10/HbjVZJK0CUGTRUwJ2u0OPiNot9scU9OBjhyTndlzHC+Tly3M UTU1IfgyjotV0+cETQ4xJ5jT7qTO22x7cstz7CGTZY8fB5Dik35Thykl7qpf6c9TpT2svB3O vi3/npf0tRXi8vqcoo8dP3f87uPrpv9qPBv16b+N+spAPvsnpvxe0kJEZjENuFy/QnQ8r6jE J2bmrCW+3PJCnwTwdKbM5xA77CwfLS/zWfyuycHCF4PzZ9dMrgXn026FfNqtnk+7SXOpnd4/ /tiFv61xLaga/cn4X9GH3nu7YfwjVk3HL62ua158eTz3yg/p7cHxjUS8Bc04+9BzzT/6/Wb7 8v+Qi2Xx5sUjH86dP/kWxokr43ea3MY3QS36e4dFPvOK8TvIyqsva/zMK3l9JoiM68kRQ4I8 YCCkA/HtOm9CfB99hdzHfKQSvA1Yxd+vaTpKHoD8QZOP9LKjZB9kYyjjCZEvQVqgfxTxQZRR ZviQPA1+F4fxFfItyB4EX25cP3EF6afA1wPNKGMG4q8gPgqcFjpC5iA2oY57OFDHQcACuw8A rnsCbdgJ3TogAKzm+WHTDf0a6B9HGXb+DjnyFXofe8bQYfxT8055vcVi+XbOWesb1jdsw3mb 7KX2Zx23On6Z/5bzwsxHZp4vWFXwXOG/zS6cfbzY6xosebK0Tdmq7i8LlN9Vfrz8jcq5Vd3V 3up49XfnnfPsWyAvpAvHav6utqF2Y+1v62oXvbu4bMmspQ3C0z6yDGds/I8RB6kl6wkxPGf9 Ns4SGGQNjL8lWtNvF6EktlCOSEkiVx5J6lwim8hf6NwAm/M65+/6/aXOTSSPMp2bSQ916Fwm dTSucwv5Kj2icxs7yhZMjYmlhrd0jiFhtOqcEbPRoXOJ1BoLdW6AzSqdG0musU3nJtjfrXMz WWTcpHOZFBkP6NxCWo3/oHMbvcv47yiZGiS+ctwcEJx7yGFeI7hJyDcKbhbyqOCy4LsFt3Af mvfrHD40/1bn8KH5is7hQ9mqc/hQjuocPpQTOocP5Yd0Dh/Kj+kcPpQv6xw+tHh0Dh9a/lHw HLHyfbPgVt623B2C5wr5lwXPE/wBwR28bbnfEHwGuDP3KcFnCptRwWeJcsYELxDy1wSfLfK+ I3ixsPlI8BJhc0lwRTyWySh4Jbe35Qs+X3BF8IV8JNoWci6L9utc1GXzcZ6ryVsFF32x3Ume ISrxkjrxJmiVdJI+nF2pZA3OggeAJNlNBoVkJVJxcB6GII8KixpoAqQfH5WshWwb8idJQqQi iCOw3oUwDMsAeBR5+4VuGxkCC0H22boaplmqn7FtwJ7Hy0zo9atkKUpehParpBolRUkvtDHo Y2QrSpw3rayb5bxqsQb9n153VPQkBCRFr8MoYadoxw7IeA3/G4/9T3Ncb9c5xVqE5TAsB+Al lbSjTVuFF7h2ofBfjPQIvUruEJo+SLg3E2QBZB2iprjQREVf1yEcgn1Y95cKL/Hjn5cEkXMI ae6D3YiHxBbm3unTfbVVtDUpZDGEYSEfFPXtFr7k5aqQxEWbuGWvnieip0OipEFR+05YJYWO 5+oRZSR1//Xr/RyYaoWWY7Id8Wm2g2JUhNHiXlGH5o9h0W7ukRv3QUtz217UNiQ8EhZj/rOe 4Dn6BauG/TzEfKT06O2+cdkD/4e+Xy09PLXt42KPm9yWk6PnRj2YrP36djVO20a8J1pfkqK+ yXHJy9f6GoZkWPQ8JvaOzxsJoWu2ekRsnZgear3S+BBSgyJURWt3TY1mrRxu2Q+LzxtDNc+o 3rpFi9TOvoi6JjYQS+4ejKgrY/HBWDyUjMYGatRAf7+6NrqtL5lQ10YSkfiuSLgmEI+G+tdG tg31h+KTuRqEUNWlDesj8QTyq0trFtWp1WuivfFYIrY1OU9YTVcKwZpOLXc0oYbUZDwUjuwM xXeosa03b9jNFFOyTh60xEPD0YFtavvWrdHeiLpQXRvriQ6od0R7+2L9ocQCtSOUjEd7oyF1 XWhoIIx2qYt8y7zB2JC6M7RbHUpE1GQfWrU1NpBUkzE1HE0M9kMRGgirg/EohL3QRBCHEupg JL4zmkxGwmrPbmSLqP2oc4AXAQUvIy6kg/FYeKg3qaIdw31oyLQaEEcHevuHwnCyOtmI2ED/ brU6Ok+N7OxB2dOsBz63dmEe5r2PRxK8l9w9Vyvg2afKahQ9qo6ilmRkJ/dlPIpaw7Hhgf5Y KHytE0Ja1yNxFT2KoSqEQ8nBoaQajuziboZNX6R/8FoP1eCgGhM7a0jsBthNqQ3DcDsG4kfi sD2pW4eBqe1afBcKS4ekEemfpDHglHRaeu6LL+Ivvoi/+CL+4ov4/9cX8TVHx6s8JMbMjXQX rrHrRznTj5viyHmTMvths3t62lBqWGRoM6w23ILQd00NAyj3ZqXcgXCX8KK2r/fRNH0K59h8 2948z425PidAJubyO1yv/ztFOqXqUXeR8vqL0jxyHmDSvIynRDklzZVKMo2KPytVjDpnee2B hRKfsa0VoYowBhwDxgAD2SzxOyocCO8FUsAxYAx4HTChIaVCqwIx4DBwnmukEsmVURVHYK40 G3n52ahdKiQXgQlAIgrCWqAd2AwcAA4DJmHHJTHgXmAM+LXQ+KXCzNcXo+2FmYdENLq93yuS IS3ZvVEkR+8OavGaO7W45TbNrEEzW7REE9c0a/HcBVrsrPKmeJxj854JFEgF6CQ/zR1ESNlL xE4pUciT0iySBphk0iV+yTla6fYeHpMMhEpMotjGysQZiWZs+d5ADptgF4mTKOxX7GNNwz4e zcv3Hg7czn5KjgFjgMR+is8FdoHcy85znyNsAg4DY8BrwEXAxM7j8wE+77P3iZ29R2qBJmAz cBgYAy4CZvYeQgd7l8+jiJDzJoCxdxE62Dvo1jsI7extsLfZ22jav2bqfd5TgnhqdaJU6aSw WCfOAm+WvZG5NA8jyo0tjRH1glROVpDFUnmmapGSlYoyy6NKln04qnqUJwN17E2SBhha8iZq fpOoQAewBRgETGBvgb1FUsAjwJNAGsAoQ+gAVHYOeBV4i9QBfqADkNnrGVSTZa9l3M1KoID9 kL1CCuHxf2HfE/Gr7GUR/4B9V8TfR1yK+Bx7OVOqkIAVeoI8DsQOxLXQG9l3RiudykQgn43B dwrCWqAJaAc2AwcAExtj5Zmw4kQhL5BzMoFlhnwk4r8nR2Ti36743SsxAFUeuBtuAUNwWD3s Zn73wceQ5IH74a+D8cB9/1+C8cD9pb1gPHD37wLjgTu8HYwH7g2bwXjgbu8EQ5BlT5ysnKvU t++gasDOhuGlYXhpGF4aJgY2zD/kkoG37a8z8+fDY4f8nnnzldRpmnqRptbS1BGaitDUHpra S1PLaWoTTXloykVTpTTlp6kX6DK4IkX9x69J+vxFNHWOpp6nqQRNuWmqiqYqaUql9f4sK8vc tlhErSIaDfCdDvEtK3D0sbMyeLQMY74Mx4QxhK8BEyLlh5FarhnPLuVx+ej8Ji1d0+CNBW5l Z5HxLDbDWfIBYMAGOothdBaFnEUBdoRNwGbgDHARmABMsC5Hww+I0I6wFmgCNgP3AhcBk2jO RYCRmN7EY6JhtXqj23mKncWnHJ8yVuYvcbgcHset0gEXtZfS9tKJUlZPCgpwRHbmy/lZajvx qe0Pn9qIJWBhD7MDpAQb4hE9PpC5VKJk6aMZ9wtKYBb9Jik1YNRRH3HTKsTLSEKklxKXzOMl xMWeRezNuNYjmz3jXqCcpnk81wnlkutnykeuLAP9hesF5Sdq1kAzyo8hefaE8qZrv/L92qwM yYvuLEV0WhWmp1zLlOfPCdO9UBzKKHt4dEL5c9dqZYdLKCKaYlMCKb9dWeveoNyK8lpcPYo/ gTJPKE2uTcpyzWopz3NCqUMTPBqdj8bOc4lKK0pFgXfVZ2mff4H5oLnL3G7+E7PXvMBcZlbM JeZi80zZKTvkPDlXzpFl2SQbZCYTeSa/CO3hc9AzTQ6xbNHAQ4PgDsZDpl3IYFRm5HaSniG1 sbZ1zbQtfaaXtPWo6d+vq8jSnDs3pI0VzTTtbCNtnc3pZZ62rHlibbre05Y2d/xZ1wilDwch TbMHs5R0dmXpBBftK047V/KHcdL8fV8r5nH1vq8Fg6SoYFdTUZNzRb5vVcsNgi16OO3mh6Jr eEn6YNu6rvTRkmDay8lESbAt/Y11anfXKfob+uvWllP0Ex4Fu05JK+hvWtdyubSiJRhsy9L1 wo6o9BPYYcR8IuxkfDFzO6LKpZrdIc2uCvlhV8kj2FkspErYVVksws5Aud1IorK1ZaSyUtgU qiQhbBKF6nSbc1WwqaoSNgUpck7YnCtIcZv0CmHicsGk1CVM6BziEiYuOkeYrL9qUqub7J8y 2S9qkuhVG5dmYzs/aWM73xK87lmdN/2LNHs8dLQx2NvdGqlo3VLRGgG2pB/a1VeUTvWo6khv kCvUtOTe0tPbx+NQJB2siLSkeyta1JHG7huou7m6saJlhHS3dnaNdPsjLZlGf2NrRaglOLq6 Y0n9NXXtn6prSccNCuvghS3hda2uv4G6nqtX87rqeV31vK7V/tWiLiLGeEfXiEyagyu7tXiU WXMwXrcUlwWbCxyDK8TgbSwr2lN8Gr9WniZWTzCdW9GctgFctTCwMMBV2Ke4Kg9iu64q2tNY VnyaPq2rHBDnVzQTT3IoMUSKWqMt2n8CfxAlh7jDtdCTuNkfdK1pf6glkSSkLT1/XVu66c4N XSNmM6RbeJfSDZMyq7U1O3FGE9ZA2MCFkjRlyGXLucxi0Q2v3/5DeixuE0/xx/b5S2mSJIJS urStk+FQ0LkBfe3e0HUav6X410MiiA4mqIcmJsvQmz35lgIP4X2eRHJIZ7ovknqs5USWxKRL pv64szxTHkuiQPJf0nB/fwplbmRzdHJlYW0KZW5kb2JqCgozNyAwIG9iagoyMzYwMwplbmRv YmoKCjM4IDAgb2JqCjw8L1R5cGUvRm9udERlc2NyaXB0b3IvRm9udE5hbWUvQkFBQUFBK0Fy aWFsTVQKL0ZsYWdzIDQKL0ZvbnRCQm94Wy02NjQgLTMyNCAyMDAwIDEwMDZdL0l0YWxpY0Fu Z2xlIDAKL0FzY2VudCA5MDUKL0Rlc2NlbnQgLTIxMQovQ2FwSGVpZ2h0IDEwMDUKL1N0ZW1W IDgwCi9Gb250RmlsZTIgMzYgMCBSCj4+CmVuZG9iagoKMzkgMCBvYmoKPDwvTGVuZ3RoIDQ2 OC9GaWx0ZXIvRmxhdGVEZWNvZGU+PgpzdHJlYW0KeJxdk82OmzAUhfc8BcvpYgS+NiQjoUgz yUTKoj9qpg9AwEmRGkAOWeTt63OP20pdJPow9x4+G26xPewO47AU38LUHf2Sn4exD/423UPn 85O/DGNmJO+HbklX+t9d2zkrYu/xcVv89TCep6bJiu/x3m0Jj/zptZ9O/lNWfA29D8N4yZ9+ bI/x+nif51/+6sclL7PNJu/9OeZ8bucv7dUX2vV86OPtYXk8x5Z/BR+P2eei14Yq3dT729x2 PrTjxWdNWW7yZr/fZH7s/7tX1Ww5nbufbYilJpaWpas2kUW5fgdbsgU7sgFXyqsSXJO1ZkXW nDXrt+AXrjvwK9e15o2s61tl0cwd13fgd/ILeE/PuKnGlMwUcPJHjaF/hRyT/Nfg5K+99HfI N/R38DTJX3Po72ow/a1m0t/C39DfaT796zcw/a260d/h3Az9K/QK/S3OTehfr8Dp/PFcSf7I Efpb5Av9Be9I6F9pTfLXXvqvNJP+Ak+hv2CPkvy1l/6V1iR/OAv9Ld6RpPMHW/o75Fv4S2lw hpb+grO1luvK9BetoX+FvVv6Wzhb+jvsyyb/tX7A6UvFp4xZ+zMieXcPIY6HDqTOBSZiGP3f mZ2nGV36+w1qDu4/CmVuZHN0cmVhbQplbmRvYmoKCjQwIDAgb2JqCjw8L1R5cGUvRm9udC9T dWJ0eXBlL1RydWVUeXBlL0Jhc2VGb250L0JBQUFBQStBcmlhbE1UCi9GaXJzdENoYXIgMAov TGFzdENoYXIgNTYKL1dpZHRoc1s3NTAgNjY2IDU1NiA1MDAgNTU2IDU1NiA1MDAgNTU2IDIy MiAyNzcgNTU2IDU1NiAyNzcgODMzIDIyMiA3NzcKMzMzIDI3NyA2NjYgNTU2IDU1NiA4MzMg NTU2IDUwMCA2MTAgNTU2IDU1NiA3MjIgNTAwIDU1NiA2NjYgNzIyCjU1NiA1NTYgMjc3IDU1 NiAyNzcgMjc3IDcyMiA1MDAgNzIyIDMzMyAzMzMgNjY2IDY2NiA1NTYgNTU2IDcyMgo3Nzcg MzMzIDMzMyAzMzMgMjc3IDY2NiA1NTYgNzIyIDUwMCBdCi9Gb250RGVzY3JpcHRvciAzOCAw IFIKL1RvVW5pY29kZSAzOSAwIFIKPj4KZW5kb2JqCgo0MSAwIG9iago8PC9GMSA0MCAwIFIv RjIgMzUgMCBSL0YzIDMwIDAgUgo+PgplbmRvYmoKCjQyIDAgb2JqCjw8L0ZvbnQgNDEgMCBS Ci9Qcm9jU2V0Wy9QREYvVGV4dF0KPj4KZW5kb2JqCgoxIDAgb2JqCjw8L1R5cGUvUGFnZS9Q YXJlbnQgMjUgMCBSL1Jlc291cmNlcyA0MiAwIFIvTWVkaWFCb3hbMCAwIDU5NSA4NDJdL0dy b3VwPDwvUy9UcmFuc3BhcmVuY3kvQ1MvRGV2aWNlUkdCL0kgdHJ1ZT4+L0NvbnRlbnRzIDIg MCBSPj4KZW5kb2JqCgo0IDAgb2JqCjw8L1R5cGUvUGFnZS9QYXJlbnQgMjUgMCBSL1Jlc291 cmNlcyA0MiAwIFIvTWVkaWFCb3hbMCAwIDU5NSA4NDJdL0dyb3VwPDwvUy9UcmFuc3BhcmVu Y3kvQ1MvRGV2aWNlUkdCL0kgdHJ1ZT4+L0NvbnRlbnRzIDUgMCBSPj4KZW5kb2JqCgo3IDAg b2JqCjw8L1R5cGUvUGFnZS9QYXJlbnQgMjUgMCBSL1Jlc291cmNlcyA0MiAwIFIvTWVkaWFC b3hbMCAwIDU5NSA4NDJdL0dyb3VwPDwvUy9UcmFuc3BhcmVuY3kvQ1MvRGV2aWNlUkdCL0kg dHJ1ZT4+L0NvbnRlbnRzIDggMCBSPj4KZW5kb2JqCgoxMCAwIG9iago8PC9UeXBlL1BhZ2Uv UGFyZW50IDI1IDAgUi9SZXNvdXJjZXMgNDIgMCBSL01lZGlhQm94WzAgMCA1OTUgODQyXS9H cm91cDw8L1MvVHJhbnNwYXJlbmN5L0NTL0RldmljZVJHQi9JIHRydWU+Pi9Db250ZW50cyAx MSAwIFI+PgplbmRvYmoKCjEzIDAgb2JqCjw8L1R5cGUvUGFnZS9QYXJlbnQgMjUgMCBSL1Jl c291cmNlcyA0MiAwIFIvTWVkaWFCb3hbMCAwIDU5NSA4NDJdL0dyb3VwPDwvUy9UcmFuc3Bh cmVuY3kvQ1MvRGV2aWNlUkdCL0kgdHJ1ZT4+L0NvbnRlbnRzIDE0IDAgUj4+CmVuZG9iagoK MTYgMCBvYmoKPDwvVHlwZS9QYWdlL1BhcmVudCAyNSAwIFIvUmVzb3VyY2VzIDQyIDAgUi9N ZWRpYUJveFswIDAgNTk1IDg0Ml0vR3JvdXA8PC9TL1RyYW5zcGFyZW5jeS9DUy9EZXZpY2VS R0IvSSB0cnVlPj4vQ29udGVudHMgMTcgMCBSPj4KZW5kb2JqCgoxOSAwIG9iago8PC9UeXBl L1BhZ2UvUGFyZW50IDI1IDAgUi9SZXNvdXJjZXMgNDIgMCBSL01lZGlhQm94WzAgMCA1OTUg ODQyXS9Hcm91cDw8L1MvVHJhbnNwYXJlbmN5L0NTL0RldmljZVJHQi9JIHRydWU+Pi9Db250 ZW50cyAyMCAwIFI+PgplbmRvYmoKCjIyIDAgb2JqCjw8L1R5cGUvUGFnZS9QYXJlbnQgMjUg MCBSL1Jlc291cmNlcyA0MiAwIFIvTWVkaWFCb3hbMCAwIDU5NSA4NDJdL0dyb3VwPDwvUy9U cmFuc3BhcmVuY3kvQ1MvRGV2aWNlUkdCL0kgdHJ1ZT4+L0NvbnRlbnRzIDIzIDAgUj4+CmVu ZG9iagoKNDMgMCBvYmoKPDwvQ291bnQgOC9GaXJzdCA0NCAwIFIvTGFzdCA1MSAwIFIKPj4K ZW5kb2JqCgo0NCAwIG9iago8PC9Db3VudCAwL1RpdGxlPEZFRkYwMDUzMDA2QzAwNjkwMDY0 MDA2NTAwMjAwMDMxPgovRGVzdFsxIDAgUi9YWVogMCA4NDIgMF0vUGFyZW50IDQzIDAgUi9O ZXh0IDQ1IDAgUj4+CmVuZG9iagoKNDUgMCBvYmoKPDwvQ291bnQgMC9UaXRsZTxGRUZGMDA1 MzAwNkMwMDY5MDA2NDAwNjUwMDIwMDAzMj4KL0Rlc3RbNCAwIFIvWFlaIDAgODQyIDBdL1Bh cmVudCA0MyAwIFIvUHJldiA0NCAwIFIvTmV4dCA0NiAwIFI+PgplbmRvYmoKCjQ2IDAgb2Jq Cjw8L0NvdW50IDAvVGl0bGU8RkVGRjAwNTMwMDZDMDA2OTAwNjQwMDY1MDAyMDAwMzM+Ci9E ZXN0WzcgMCBSL1hZWiAwIDg0MiAwXS9QYXJlbnQgNDMgMCBSL1ByZXYgNDUgMCBSL05leHQg NDcgMCBSPj4KZW5kb2JqCgo0NyAwIG9iago8PC9Db3VudCAwL1RpdGxlPEZFRkYwMDUzMDA2 QzAwNjkwMDY0MDA2NTAwMjAwMDM0PgovRGVzdFsxMCAwIFIvWFlaIDAgODQyIDBdL1BhcmVu dCA0MyAwIFIvUHJldiA0NiAwIFIvTmV4dCA0OCAwIFI+PgplbmRvYmoKCjQ4IDAgb2JqCjw8 L0NvdW50IDAvVGl0bGU8RkVGRjAwNTMwMDZDMDA2OTAwNjQwMDY1MDAyMDAwMzU+Ci9EZXN0 WzEzIDAgUi9YWVogMCA4NDIgMF0vUGFyZW50IDQzIDAgUi9QcmV2IDQ3IDAgUi9OZXh0IDQ5 IDAgUj4+CmVuZG9iagoKNDkgMCBvYmoKPDwvQ291bnQgMC9UaXRsZTxGRUZGMDA1MzAwNkMw MDY5MDA2NDAwNjUwMDIwMDAzNj4KL0Rlc3RbMTYgMCBSL1hZWiAwIDg0MiAwXS9QYXJlbnQg NDMgMCBSL1ByZXYgNDggMCBSL05leHQgNTAgMCBSPj4KZW5kb2JqCgo1MCAwIG9iago8PC9D b3VudCAwL1RpdGxlPEZFRkYwMDUzMDA2QzAwNjkwMDY0MDA2NTAwMjAwMDM3PgovRGVzdFsx OSAwIFIvWFlaIDAgODQyIDBdL1BhcmVudCA0MyAwIFIvUHJldiA0OSAwIFIvTmV4dCA1MSAw IFI+PgplbmRvYmoKCjUxIDAgb2JqCjw8L0NvdW50IDAvVGl0bGU8RkVGRjAwNTMwMDZDMDA2 OTAwNjQwMDY1MDAyMDAwMzg+Ci9EZXN0WzIyIDAgUi9YWVogMCA4NDIgMF0vUGFyZW50IDQz IDAgUi9QcmV2IDUwIDAgUj4+CmVuZG9iagoKMjUgMCBvYmoKPDwvVHlwZS9QYWdlcwovUmVz b3VyY2VzIDQyIDAgUgovTWVkaWFCb3hbIDAgMCA1OTUgODQyIF0KL0tpZHNbIDEgMCBSIDQg MCBSIDcgMCBSIDEwIDAgUiAxMyAwIFIgMTYgMCBSIDE5IDAgUiAyMiAwIFIgXQovQ291bnQg OD4+CmVuZG9iagoKNTIgMCBvYmoKPDwvVHlwZS9DYXRhbG9nL1BhZ2VzIDI1IDAgUgovT3Bl bkFjdGlvblsxIDAgUiAvWFlaIG51bGwgbnVsbCAwXQovT3V0bGluZXMgNDMgMCBSCj4+CmVu ZG9iagoKNTMgMCBvYmoKPDwvQ3JlYXRvcjxGRUZGMDA0NDAwNzIwMDYxMDA3Nz4KL1Byb2R1 Y2VyPEZFRkYwMDRDMDA2OTAwNjIwMDcyMDA2NTAwNEYwMDY2MDA2NjAwNjkwMDYzMDA2NTAw MjAwMDMzMDAyRTAwMzY+Ci9DcmVhdGlvbkRhdGUoRDoyMDEyMTEwMTEyNDYyMVonKT4+CmVu ZG9iagoKeHJlZgowIDU0CjAwMDAwMDAwMDAgNjU1MzUgZiAKMDAwMDA3NzI1MiAwMDAwMCBu IAowMDAwMDAwMDE5IDAwMDAwIG4gCjAwMDAwMDE4MzQgMDAwMDAgbiAKMDAwMDA3NzM5NiAw MDAwMCBuIAowMDAwMDAxODU1IDAwMDAwIG4gCjAwMDAwMDUxNDcgMDAwMDAgbiAKMDAwMDA3 NzU0MCAwMDAwMCBuIAowMDAwMDA1MTY4IDAwMDAwIG4gCjAwMDAwMTEzNjQgMDAwMDAgbiAK MDAwMDA3NzY4NCAwMDAwMCBuIAowMDAwMDExMzg1IDAwMDAwIG4gCjAwMDAwMTc0NjUgMDAw MDAgbiAKMDAwMDA3NzgzMCAwMDAwMCBuIAowMDAwMDE3NDg3IDAwMDAwIG4gCjAwMDAwMjI5 NjYgMDAwMDAgbiAKMDAwMDA3Nzk3NiAwMDAwMCBuIAowMDAwMDIyOTg4IDAwMDAwIG4gCjAw MDAwMjkwNTMgMDAwMDAgbiAKMDAwMDA3ODEyMiAwMDAwMCBuIAowMDAwMDI5MDc1IDAwMDAw IG4gCjAwMDAwMzUxNTUgMDAwMDAgbiAKMDAwMDA3ODI2OCAwMDAwMCBuIAowMDAwMDM1MTc3 IDAwMDAwIG4gCjAwMDAwNDA0MjYgMDAwMDAgbiAKMDAwMDA3OTUxNSAwMDAwMCBuIAowMDAw MDQwNDQ4IDAwMDAwIG4gCjAwMDAwNDE4MzQgMDAwMDAgbiAKMDAwMDA0MTg1NiAwMDAwMCBu IAowMDAwMDQyMDQ4IDAwMDAwIG4gCjAwMDAwNDIzNDAgMDAwMDAgbiAKMDAwMDA0MjUwMSAw MDAwMCBuIAowMDAwMDUxNjEwIDAwMDAwIG4gCjAwMDAwNTE2MzIgMDAwMDAgbiAKMDAwMDA1 MTgyOCAwMDAwMCBuIAowMDAwMDUyMTQ0IDAwMDAwIG4gCjAwMDAwNTIzMjMgMDAwMDAgbiAK MDAwMDA3NjAxMyAwMDAwMCBuIAowMDAwMDc2MDM2IDAwMDAwIG4gCjAwMDAwNzYyMjcgMDAw MDAgbiAKMDAwMDA3Njc2NSAwMDAwMCBuIAowMDAwMDc3MTQ0IDAwMDAwIG4gCjAwMDAwNzcx OTcgMDAwMDAgbiAKMDAwMDA3ODQxNCAwMDAwMCBuIAowMDAwMDc4NDcwIDAwMDAwIG4gCjAw MDAwNzg1OTEgMDAwMDAgbiAKMDAwMDA3ODcyNCAwMDAwMCBuIAowMDAwMDc4ODU3IDAwMDAw IG4gCjAwMDAwNzg5OTEgMDAwMDAgbiAKMDAwMDA3OTEyNSAwMDAwMCBuIAowMDAwMDc5MjU5 IDAwMDAwIG4gCjAwMDAwNzkzOTMgMDAwMDAgbiAKMDAwMDA3OTY2MiAwMDAwMCBuIAowMDAw MDc5NzY0IDAwMDAwIG4gCnRyYWlsZXIKPDwvU2l6ZSA1NC9Sb290IDUyIDAgUgovSW5mbyA1 MyAwIFIKL0lEIFsgPDlFQ0EyQjA3NkZGNTkzMDgxNkZBMkE0NkQyQjY0Mjk5Pgo8OUVDQTJC MDc2RkY1OTMwODE2RkEyQTQ2RDJCNjQyOTk+IF0KL0RvY0NoZWNrc3VtIC80ODRCM0VGNDEy QTIwNTk5NkZEMTVGNDIwOTA3QzExMwo+PgpzdGFydHhyZWYKNzk5MjYKJSVFT0YK --------------070407090800060502080406-- --------------ms070807070609050103000707 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIILUDCC BRowggQCoAMCAQICEG0Z6qcZT2ozIuYiMnqqcd4wDQYJKoZIhvcNAQEFBQAwga4xCzAJBgNV BAYTAlVTMQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoT FVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3Qu Y29tMTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQg RW1haWwwHhcNMTEwNDI4MDAwMDAwWhcNMjAwNTMwMTA0ODM4WjCBkzELMAkGA1UEBhMCR0Ix GzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UE ChMRQ09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENPTU9ETyBDbGllbnQgQXV0aGVudGlj YXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC ggEBAJKEhFtLV5jUXi+LpOFAyKNTWF9mZfEyTvefMn1V0HhMVbdClOD5J3EHxcZppLkyxPFA GpDMJ1Zifxe1cWmu5SAb5MtjXmDKokH2auGj/7jfH0htZUOMKi4rYzh337EXrMLaggLW1DJq 1GdvIBOPXDX65VSAr9hxCh03CgJQU2yVHakQFLSZlVkSMf8JotJM3FLb3uJAAVtIaN3FSrTg 7SQfOq9xXwfjrL8UO7AlcWg99A/WF1hGFYE8aIuLgw9teiFX5jSw2zJ+40rhpVJyZCaRTqWS D//gsWD9Gm9oUZljjRqLpcxCm5t9ImPTqaD8zp6Q30QZ9FxbNboW86eb/8ECAwEAAaOCAUsw ggFHMB8GA1UdIwQYMBaAFImCZ33EnSZwAEu0UEh83j2uBG59MB0GA1UdDgQWBBR6E04AdFvG eGNkJ8Ev4qBbvHnFezAOBgNVHQ8BAf8EBAMCAQYwEgYDVR0TAQH/BAgwBgEB/wIBADARBgNV HSAECjAIMAYGBFUdIAAwWAYDVR0fBFEwTzBNoEugSYZHaHR0cDovL2NybC51c2VydHJ1c3Qu Y29tL1VUTi1VU0VSRmlyc3QtQ2xpZW50QXV0aGVudGljYXRpb25hbmRFbWFpbC5jcmwwdAYI KwYBBQUHAQEEaDBmMD0GCCsGAQUFBzAChjFodHRwOi8vY3J0LnVzZXJ0cnVzdC5jb20vVVRO QWRkVHJ1c3RDbGllbnRfQ0EuY3J0MCUGCCsGAQUFBzABhhlodHRwOi8vb2NzcC51c2VydHJ1 c3QuY29tMA0GCSqGSIb3DQEBBQUAA4IBAQCF1r54V1VtM39EUv5C1QaoAQOAivsNsv1Kv/av QUn1G1rF0q0bc24+6SZ85kyYwTAo38v7QjyhJT4KddbQPTmGZtGhm7VNm2+vKGwdr+XqdFqo 2rHA8XV6L566k3nK/uKRHlZ0sviN0+BDchvtj/1gOSBH+4uvOmVIPJg9pSW/ve9g4EnlFsjr P0OD8ODuDcHTzTNfm9C9YGqzO/761Mk6PB/tm/+bSTO+Qik5g+4zaS6CnUVNqGnagBsePdIa XXxHmaWbCG0SmYbWXVcHG6cwvktJRLiQfsrReTjrtDP6oDpdJlieYVUYtCHVmdXgQ0BCML7q peeU0rD+83X5f27nMIIGLjCCBRagAwIBAgIQXDFQ28QtqMuYch5f2nTvZjANBgkqhkiG9w0B AQUFADCBkzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4G A1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENP TU9ETyBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTAeFw0xMTA5 MDIwMDAwMDBaFw0xNDA5MDEyMzU5NTlaMIIBNzELMAkGA1UEBhMCR0IxEDAOBgNVBBETB1dG NCA0V0ExFzAVBgNVBAgTDldlc3QgWW9ya3NoaXJlMRIwEAYDVQQHEwlXYWtlZmllbGQxFDAS BgNVBAkTC0dyYW5nZSBNb29yMR8wHQYDVQQJExY4OSBHcmVlbmZpZWxkIENyZXNjZW50MRcw FQYDVQQKEw5HcmlkbWVyZ2UgTHRkLjE0MDIGA1UECxMrSXNzdWVkIHRocm91Z2ggR3JpZG1l cmdlIEx0ZC4gRS1QS0kgTWFuYWdlcjEfMB0GA1UECxMWQ29ycG9yYXRlIFNlY3VyZSBFbWFp bDEWMBQGA1UEAxMNUm9iZXJ0IENyYWdpZTEqMCgGCSqGSIb3DQEJARYbcm9iZXJ0LmNyYWdp ZUBncmlkbWVyZ2UuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEArcThqvLe WU1Q1ZJmnb+2UQSwOQKWok3A1Mwk582AdvwaAQyBFliPyJ0kXJqtwNBoZvk+3WJr0QA5ZRr+ J0x3sXVpcxadojP2HNzy1gsgDtIGG8ltoU4vmX1A8BTlOIUT+Pg8p/bSruxV0vz0CR8ho2hs R0Zi5vU+rQKNmbgufbkWhlQnMEYjknemscLQfw1YZz90ta67doNDujFy6+X6I06HpjudgMYx 8bdsNS5xVFFwuBA1eqNQra+xLzhCOeX9PPB/zK68qdNhrni3WPYG9EhSt4Dzk+xIz9hj7wrU ZIVXDTPsY8qbUSBVpwmzI5lCHPgzurH1OK7WwgpDSsl5pwIDAQABo4IB1TCCAdEwHwYDVR0j BBgwFoAUehNOAHRbxnhjZCfBL+KgW7x5xXswHQYDVR0OBBYEFBCOXNH+lDm8U9gy3b3bRvrx vKgrMA4GA1UdDwEB/wQEAwIFoDAMBgNVHRMBAf8EAjAAMB0GA1UdJQQWMBQGCCsGAQUFBwME BggrBgEFBQcDAjBGBgNVHSAEPzA9MDsGDCsGAQQBsjEBAgEDBTArMCkGCCsGAQUFBwIBFh1o dHRwczovL3NlY3VyZS5jb21vZG8ubmV0L0NQUzBXBgNVHR8EUDBOMEygSqBIhkZodHRwOi8v Y3JsLmNvbW9kb2NhLmNvbS9DT01PRE9DbGllbnRBdXRoZW50aWNhdGlvbmFuZFNlY3VyZUVt YWlsQ0EuY3JsMIGIBggrBgEFBQcBAQR8MHowUgYIKwYBBQUHMAKGRmh0dHA6Ly9jcnQuY29t b2RvY2EuY29tL0NPTU9ET0NsaWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5j cnQwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmNvbW9kb2NhLmNvbTAmBgNVHREEHzAdgRty b2JlcnQuY3JhZ2llQGdyaWRtZXJnZS5jb20wDQYJKoZIhvcNAQEFBQADggEBAD6b/O0LkPav kR4Znoqxg0Ad7M3duDm4uzfrlX4ecgq56Ccdwd+3Tayz7Ewej30woVMmTKkA/NKRaCd0wVM9 8seF/oZjXKO7o1SH27igRnGSWjCoWXsdwJGfZbYnvcIIhhsxJoCPNbeSR7C0PAFDKsP3xrJy MHMljIJsoRbZu/fnYNyFWh9OXf7fYJOGmKDKAhSabUGfhY7umvU9d/YTqo02Q6YzC7d4zPNG 1a75AuHSEchf6GdKqycG38I5y9jlDaYfXspoS3PlTNCIeZONbOSMZgftnNEVKq+SWytFqyG/ 8+dwpm/a12KMex5J8iHwaUKj++2O2rAFNjDDqXpeEYoxggQZMIIEFQIBATCBqDCBkzELMAkG A1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9y ZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENPTU9ETyBDbGllbnQg QXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIQXDFQ28QtqMuYch5f2nTvZjAJ BgUrDgMCGgUAoIICRTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xMjExMDExMjQ4MjJaMCMGCSqGSIb3DQEJBDEWBBS9+ZCvB5lXyP1A36Y+fc8DVGQVFTBs BgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcw DgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEo MIG5BgkrBgEEAYI3EAQxgaswgagwgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVy IE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1p dGVkMTkwNwYDVQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUg RW1haWwgQ0ECEFwxUNvELajLmHIeX9p072YwgbsGCyqGSIb3DQEJEAILMYGroIGoMIGTMQsw CQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxm b3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVu dCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhBcMVDbxC2oy5hyHl/adO9m MA0GCSqGSIb3DQEBAQUABIIBAKFN/iRyk6pmyuqV12UuBXMMkgb43NG3bCaYEkQ87ZvZRRQq LSaUyFzYVjXBQb1oik7wltbE+9Nprs2W32rcwiEvpvgZjlevQTke95gzZywl3AXbKmM0DP0f fxbrhdcFRGnnkUK+tJ7xpkIJ1eB2Sj9/iXw59KqnDWMESdf1BR67qRol8CHmL1DLltEC+5B/ SOtHO8Yaljq6RY5+YGttjWYKv8IIjFdi2ZMzvcnpmCKdOqKj9eLEEZv4uT8QXBq9y1y3wNXN j/L819QWOxThy4Ax67wRz7IZtfnQpQyjS9WOXwZhOHCF88ceWvLOyakK3GD2l9m2aaiu8yB6 +SCEwqIAAAAAAAA= --------------ms070807070609050103000707-- From stokcons@xs4all.nl Thu Nov 1 06:13:17 2012 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A766621F8512 for ; Thu, 1 Nov 2012 06:13:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.318 X-Spam-Level: X-Spam-Status: No, score=-0.318 tagged_above=-999 required=5 tests=[AWL=0.186, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TyoSijilSj4h for ; Thu, 1 Nov 2012 06:13:14 -0700 (PDT) Received: from smtp-vbr11.xs4all.nl (smtp-vbr11.xs4all.nl [194.109.24.31]) by ietfa.amsl.com (Postfix) with ESMTP id 64A4A21F85FD for ; Thu, 1 Nov 2012 06:12:42 -0700 (PDT) Received: from roundcube.xs4all.nl (roundcube10.xs4all.net [194.109.20.208]) by smtp-vbr11.xs4all.nl (8.13.8/8.13.8) with ESMTP id qA1DBcU4049667; Thu, 1 Nov 2012 14:11:38 +0100 (CET) (envelope-from stokcons@xs4all.nl) Received: from a82-95-140-48.adsl.xs4all.nl ([82.95.140.48]) by roundcube.xs4all.nl with HTTP (HTTP/1.1 POST); Thu, 01 Nov 2012 14:11:37 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Date: Thu, 01 Nov 2012 14:11:37 +0100 From: peter van der Stok To: "Jonathan Hui (johui)" Organization: vanderstok consultancy Mail-Reply-To: In-Reply-To: References: <5091B2A3.1090205@exegin.com> Message-ID: X-Sender: stokcons@xs4all.nl (8tBezuU/0uo+1audRTbSgF9wvV6yMW+9) User-Agent: XS4ALL Webmail X-Virus-Scanned: by XS4ALL Virus Scanner Cc: "roll@ietf.org WG" Subject: Re: [Roll] WG Last Call draft-ietf-roll-trickle-mcast-02 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: consultancy@vanderstok.org List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Nov 2012 13:13:17 -0000 Hi all, using link-local scope on the outer header is OK with me. I have no ideas about using something else than HbH MPL option. As long as a MPL message created on a host within the MPL domain with the MPL option can be forwarded wihin the zone without encapsulation, my concern about payload size is minimized.(last case of Robert's HbHTunnelMcast-v7 cases). Can some text be added in section 5.3 like: When the multicast destination address in the original MPL message is a unicast prefix multicast address and the the unicast prefix of the forwarder is not a prefix of the unicast prefix of the MC address, the forwarder ignores the message. I think that would limit the forwarding to a subnet identified by a prefix while routers to the subnet continue to forward the message. Apologies for confusing things. peter Jonathan Hui (johui) schreef op 2012-11-01 04:54: > Hi Dario, > > You've made good points on why restricting to link-local scope would > be simpler overall. Except for point 2, non-MPL aware routers will > not > simply forward encapsulated multicast datagrams as long as the MPL > Option type has the highest order bits set to indicate that the > processing node discard the packet if it does not recognize the > option. > > However, restricting to link-local scope does not solve Peter's use > case of limiting the multicast dissemination to a subset of devices. > Having a non-link-local MPL scope is one method to solve his problem. > Granted, the devices within each MPL scope zone needs to be > configured > with an MPL multicast address that identifies the MPL multicast scope > zone. One way forward is to have the draft explicitly indicate that > is > a necessary configuration, and leave the actual configuration method > out of scope. Of course, there are many ways one could configure an > interface (including manual configuration), so that is one argument > for leaving it out of scope. > > Another possible solution is to include an "MPL domain" identifier > within the Hop-by-Hop Option itself rather than using the IPv6 > Destination Address. Still requires some way to configure devices > with > an MPL domain. > > Yet another solution that was discussed is to include some kind of > Hop > Limit field in the Hop-by-Hop Option. But that brought up > complications with what happens with a devices first receives a > messages with different Hop Limit values. > > One final point, if we restrict MPL scope to link-local, then we > could > use a Destination Option instead of a Hop-by-Hop Option. > Alternatively, we could even encapsulate using UDP. > > Thoughts (from Dario, Peter, and the rest of the WG)? > > -- > Jonathan Hui > > On Oct 31, 2012, at 4:22 PM, Dario Tedeschi > wrote: > >> Yes, I'd like to try clarify why link-local scope was suggested for >> the *outer* header. The reasons were: >> >> * Link-local scope is the only scope where the boundaries are well >> defined (i.e. on the link). Higher scopes are not well-defined and >> can cover wide domains depending on network configuration and >> administration. >> * With a higher scope, there is a chance that non-MPL aware routers >> may simply forward encapsulated multicast datagrams (MPL HbH option >> and all). We wouldn't want MPL datagrams to leak outside of an MPL >> domain. >> * A higher scope complicates the forwarding logic that needs to be >> implemented in an MPL router. The complication comes when a router >> receives an MPL datagram and needs to figure out whether to >> decapsulate or not. Granted, the use of an MPL group would mitigate >> this problem to a degree, but link-local scope would make the >> decision to decapsulate very obvious and simple. >> >> * In conjunction with 3. Link-local scope also makes it easier for >> an MPL router to determine if the inner multicast address is one >> that a higher layer (or an app) may be interested in. >> >> Hopefully I haven't made things more confusing. >> >> - Dario >> >> On 31/10/2012 7:53 AM, Jonathan Hui (johui) wrote: >> >>> Hi Peter, >>> >>> The current draft does not place any restrictions on the MPL >>> multicast scope. >>> >>> If the LLN border router is an MPL forwarder, it can forward MPL >>> multicast packets between different MPL multicast scope zones. To >>> be explicit, if the original multicast packet's destination >>> address has link-local scope, the MPL forwarder should not forward >>> the packet again. If the original multicast packet's destination >>> has a scope larger than the MPL multicast scope, then the MPL >>> forwarder needs to forward the packet to other MPL multicast scope >>> zones (which may or may not involve different interfaces). >>> >>> Does that address your question? >>> >>> -- >>> Jonathan Hui >>> >>> On Oct 31, 2012, at 3:54 AM, peter van der Stok >>> wrote: >>> >>>> Hi Jonathan, >>>> >>>> To be absolutely sure: the MPL multicast scope can be >>>> link-local, ULA or site-local? meaning the LLN border router can >>>> be a MPL forwarder? >>>> In the latter case the LLN border router can forward link-local >>>> multicast from one interface to another? >>>> >>>> Greetings, >>>> >>>> peter >>>> >>>> Jonathan Hui (johui) schreef op 2012-10-30 18:27: >>>> >>>>> Yes, a goal of the current draft is to support both cases (use >>>>> of >>>>> IPv6-in-IPv6 encapsulation or not). >>>>> >>>>> The intent is as follows: >>>>> 1) If the source of the multicast packet is within the MPL >>>>> forwarding >>>>> domain and the destination has a scope equal to or smaller >>>>> than the >>>>> MPL multicast scope, then no IPv6-in-IPv6 encapsulation is >>>>> required. >>>>> 2) If the source of the multicast packet is outside the MPL >>>>> forwarding domain or the destination has scope greater than >>>>> the MPL >>>>> multicast scope, then IPv6-in-IPv6 encapsulation is required. >>>>> When >>>>> using IPv6-in-IPv6 encapsulation, then the all MPL forwarders >>>>> multicast address with scope = MPL multicast scope is used as >>>>> the >>>>> destination address in the outer header. >>>>> >>>>> As mentioned in my other email, IPv6-in-IPv6 encapsulation is >>>>> required if you want to use the IPv6 Destination Address to >>>>> identify >>>>> MPL forwarding scope zones. >>>>> >>>>> Of course, this brings up Dario's practical point of how to >>>>> configure >>>>> the MPL multicast scope if we allow that to dynamically >>>>> change. He >>>>> proposes a simplifying suggestion of requiring IPv6-in-IPv6 >>>>> encapsulation for all non-link-local multicasts. In other >>>>> words, >>>>> setting the MPL multicast scope to link-local. >>>>> >>>>> Thoughts? >>>>> >>>>> -- >>>>> Jonathan Hui >>>>> >>>>> On Oct 30, 2012, at 4:46 AM, Don Sturek >>>>> wrote: >>>>> >>>>>> Hi Peter, >>>>>> >>>>>> I still need to read the latest draft so take what I say >>>>>> here with that in >>>>>> mind...... >>>>>> >>>>>> I was hoping that we could support not using IP in IP >>>>>> tunneling if the >>>>>> scope of the multicast transmission was only within the >>>>>> multi-link subnet >>>>>> managed by the border router. I was hoping that only >>>>>> transmission >>>>>> emanating from outside the multi-link subnet, received at >>>>>> the border >>>>>> router, with scope that includes the devices in the >>>>>> multi-link subnet >>>>>> would require IP in IP tunneling (and vice versa in terms of >>>>>> multicasts >>>>>> generated in the multi-link subnet with scope outside). I >>>>>> haven't yet >>>>>> read the draft carefully to know if this is possible. >>>>>> >>>>>> Don >>>>>> >>>>>> On 10/30/12 1:34 AM, "peter van der Stok" >>>>>> wrote: >>>>>> >>>>>>> Hi Don, >>>>>>> >>>>>>> and more specifically under which conditions. That gives >>>>>>> the >>>>>>> possibility to choose the conditions such that the >>>>>>> encapsulation is not >>>>>>> needed. >>>>>>> >>>>>>> Don Sturek schreef op 2012-10-29 16:56: >>>>>>> >>>>>>>> Hi Peter, >>>>>>>> >>>>>>>> I think your suggested changes to the Trickle Multicast >>>>>>>> draft point >>>>>>>> out >>>>>>>> why IP in IP tunneling is needed. >>>>>>>> >>>>>>>> Don >>>>>>>> >>>>>>>> On 10/29/12 3:44 AM, "peter van der Stok" >>>>>>>> wrote: >>>>>>>> >>>>>>>>> Dear WG, >>>>>>>>> >>>>>>>>> Attached my suggestions for text modifications >>>>>>>>> including some nits. I >>>>>>>>> used the facilities of word to edit and comment text >>>>>>>>> with traces. >>>>>>>>> >>>>>>>>> When writing text about MC scope and MC domain, I was >>>>>>>>> puzzled by the >>>>>>>>> all MPL forwarders multicast address which removes the >>>>>>>>> possibility to >>>>>>>>> address a given multicast group. We expect multiple >>>>>>>>> (possibly >>>>>>>>> disjunct) >>>>>>>>> MC groups in our wireless networks. >>>>>>>>> Also I failed to understand why encapsulation was >>>>>>>>> necessary once the >>>>>>>>> message was received by the seed. >>>>>>>>> To make it possible to configure the interface with >>>>>>>>> one MC scope I >>>>>>>>> added the possibility to use Unicast-Prefix-based IPv6 >>>>>>>>> Multicast >>>>>>>>> Addresses (RFC 3306). >>>>>>>>> >>>>>>>>> Probably, I overlooked many aspects which make the >>>>>>>>> suggestions >>>>>>>>> impractical, but I hope that the intention is clear. >>>>>>>>> >>>>>>>>> Peter van der Stok >>>>>>>>> >>>>>>>>> Michael Richardson schreef op 2012-10-25 23:30: >>>>>>>>> >>>>>>>>>> I suggest that you propose specific text to the list >>>>>>>>>> to modify the >>>>>>>>>> document. >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> Roll mailing 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 > > > > Links: > ------ > [1] mailto:dat@exegin.com From rstruik.ext@gmail.com Thu Nov 1 06:13:45 2012 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8581B21F8E6D; Thu, 1 Nov 2012 06:13:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gg9DU11fFrUM; Thu, 1 Nov 2012 06:13:44 -0700 (PDT) Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by ietfa.amsl.com (Postfix) with ESMTP id A9DA521F8E5A; Thu, 1 Nov 2012 06:13:05 -0700 (PDT) Received: by mail-ie0-f172.google.com with SMTP id 9so4055097iec.31 for ; Thu, 01 Nov 2012 06:13:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; bh=KVxXbD3bDV5ciVVoHDBP5+GglneZB7yWe2iN0+Uzbh4=; b=cfziMUgKOHi8dDCh1nJ69VvFnbzaEHtJSemvMdZkkz37tH4/PzRQYys/eGR3WNWy9b nhR140yPULIWePlnmDwxYS2Kij58eF7gjfrrHiHDhC+baIkW0wTtjR4kQSb3svbscYEg VVuGxt8fmqSEBDsQTypW7irc+DJsJLMnSbcjCxs+43XTWrZQQukUSP/5eA6KyXGILJBh YRKIqyq3zfVPBIsdq/kg9pSsh9GRzDL60LQzIWhrjOAeWSX8BO7uqe9v6JzI/kQkTV0p dJDXOKLRsXA7SQrl3O4MnzYA8z02IIOqqf2wOuHb6OT0nzslwJ0QC3pIQLuO0O6BCKDN XwoA== Received: by 10.42.37.142 with SMTP id y14mr34176617icd.44.1351775585274; Thu, 01 Nov 2012 06:13:05 -0700 (PDT) Received: from [192.168.1.100] (CPE0013100e2c51-CM001cea35caa6.cpe.net.cable.rogers.com. [99.231.4.27]) by mx.google.com with ESMTPS id ez8sm5721394igb.17.2012.11.01.06.13.03 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 01 Nov 2012 06:13:04 -0700 (PDT) Message-ID: <5092753D.1040700@gmail.com> Date: Thu, 01 Nov 2012 09:12:29 -0400 From: Rene Struik User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: QIU Ying References: <02a001cdb5ee$e34164d0$a9c42e70$@a-star.edu.sg> <508ECA68.4030402@gmail.com> <036901cdb788$a481d5e0$ed8581a0$@a-star.edu.sg> In-Reply-To: <036901cdb788$a481d5e0$ed8581a0$@a-star.edu.sg> X-Enigmail-Version: 1.4.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: roll@ietf.org, 6lowpan@ietf.org Subject: Re: [Roll] [6lowpan] New Version Notification for draft-qiu-roll-kemp: Do need an alternative security design ? X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Nov 2012 13:13:45 -0000 Hi Qiu: Thanks for your note. One quick note re key revocation: key lifecycle issues are independent of the "color" of the key (i.e., whether the key is symmetric-key or public-key). Interestingly enough, usually this issue is conveniently forgotten when symmetric keys come along, while inflated when the word public key is mentioned. In practice, the main reason for revocation would usually be an authorization change and not so much a key compromise setting. If so, revocation can be toned down in smart object setting, since devices can be expected not to change affiliation that often. On the other hand, devices are less well protected, so key compromise may happen (if one does not implement key security and implementation security with care). I put a marker in my calendar to revisit your draft in detail. Meanwhile, have a good discussion at the IETF meeting next week. Best regards, Rene On 10/31/2012 12:56 PM, QIU Ying wrote: > Hi, Rene > > Thanks for your comments. > > The discussion of using public keys in MIP6 WG was much more than the > description in RFC 4225, e.g. the lack of global PKI, the key revocation, > etc. These issues also restricted to accept the public key schemes in MIPv6 > since a mobile device are always roaming and lost easily. > > Regarding the scalability, according to my understanding, for example IKE, a > pre-configured security policy (SP), which based on the home address of > mobile devices, is needed before IKE exchange procedure. The > pre-configuration is lack of scalability as the visiting mobile devices > could be from any locations or any domains. > > The IKE scheme is only solve the issue of authentication between the mobile > device and the correspondent node. It cannot ensure that a mobile device is > reachable from other nodes. > > "resource utilization": did you mean the limited capability of mobile > devices? I cannot remember if there are a lot of words on the capability in > the MIPv6 specification. I thought it is not practice to involve the > revocation checking in a mobile device. Anyway, the capability issue is much > more sensitive in LLNs than in mobile networks. > > Your observation is correct that "get lots of message traffic to/from this > third party and its local neighbours" because need more hops. In KEMP > protocol, using the base station as the trust third party is only in the > bootstraps phase (or at a specified interval). In the following update > phases, the distribution mode should be employed. In the distribution mode, > the previous neighbour router is role as the trust 3rd party to introduce > the moving sensor to the next neighbour router. In this case, the total hops > could reduce to 3. By the way, in the public key scheme, the extra messages > / communications are required when the certifications need to update. > > I hope that the above explanation could be express the actual concept of the > MIPv6 authors, not just on my own understanding ;) > > Regards > Qiu Ying > > >> -----Original Message----- >> From: Rene Struik [mailto:rstruik.ext@gmail.com] >> Sent: Tuesday, October 30, 2012 2:27 AM >> To: QIU Ying >> Cc: roll@ietf.org; 6lowpan@ietf.org >> Subject: Re: [6lowpan] New Version Notification for draft-qiu-roll-kemp: >> Do need an alternative security design ? >> >> Hi Qiu: >> >> Just curious: could you elaborate a little bit on the RFC 4225, Section >> 5.2 remark below? I just would like to understand scalability, resource >> utilization, and other issues somewhat better and may have missed >> something here. In particular, if one uses a symmetric-key scheme with >> online involvement of a trusted party who distributes pairwise keying >> material, doesn't one then get lots of message traffic to/from this >> third party and its local neighbors for each protocol instantiation? >> >> On a more general note, agreed there is a need to tackle trust life >> cycle management in a dedicated forum. Originally, I thought the Smart >> Object Security Workshop (which we had end of March 2012, just prior to >> the IETF meeting) would be a good forum to tackle issues, but felt we >> missed some opportunities there to bring forward an agenda of things to >> accomplish (in my mind, there was too much inside the box thinking in >> terms of "tweaks to IETF drafts"), with less emphasis on what makes >> ubiquitous networking different from a deployment use case perspective >> (e.g., the lighting use case example comes to mind). >> >> Unfortunately, I will not be at the Atlanta meeting, though I might be >> in Vancouver. Glad to contribute to call to action there. >> >> Best regards, Rene >> >> On 10/29/2012 12:03 PM, QIU Ying wrote: >>> Dear all, >>> >>> Do need an alternative security design instead of the current public >> key protocols in key establishment? It's one of arguments in previous >> WG meeting. >>> My answer is yes. Actually, the similar discussion had been raised in >> mobile IPv6 WG (RFC4225). >>> Besides the authentication, another major check is the reachability >> checking to verify if the claimed mobile node is reachable (section >> 4.1). RFC4225 also explains why the current Public Key Infrastructure >> (i.e. IKE) is not accepted in mobile IPv6 (section 5.2). >>> Frankly, the scheme used in KEMP is not fresh new. It is in style of >> the popular Kerberos. Instead of sending the ticket to visiting server >> from client directly in Kerberos, the ticket is sent to the visiting >> server (new nearby router in KEMP) from the KDC (base station in KEMP). >> The benefit of this modification includes: 1) reduce the communication; >> 2) the client (mobile node in KEMP) is check if reachable from the 3rd >> party (new nearby router); 3) revocation in time. >>> Thank to many WG participants commenting on the draft (inclusive Rene >> Struik, Steve Childress, Shoichi Sakane, Greg Zaverucha, Matthew >> Campagna), the draft should be more mature and stronger. >>> Regards >>> Qiu Ying >>> >>> >>>> -----Original Message----- >>>> From: QIU Ying [mailto:qiuying@i2r.a-star.edu.sg] >>>> Sent: Tuesday, October 23, 2012 11:57 AM >>>> To: 'roll@ietf.org'; '6lowpan@ietf.org' >>>> Subject: FW: New Version Notification for draft-qiu-roll-kemp-02.txt >>>> >>>> Hi, >>>> >>>> The KEMP draft is updated. The messages in the draft will be carried >>>> in KMP format proposed by IEEE802.15.9 working group so that the >> KEMP >>>> protocol is compatible with IEEE802.15.9 and could be deployed in >>>> layer 2. >>>> >>>> Regards >>>> Qiu Ying >>>> >>>> >>>> -----Original Message----- >>>> >>>> A new version of I-D, draft-qiu-roll-kemp-02.txt has been >>>> successfully submitted by Ying Qiu and posted to the IETF repository. >>>> >>>> Filename: draft-qiu-roll-kemp >>>> Revision: 02 >>>> Title: Lightweight Key Establishment and Management >>>> Protocol in Dynamic Sensor Networks (KEMP) >>>> Creation date: 2012-10-22 >>>> WG ID: Individual Submission >>>> Number of pages: 20 >>>> URL: http://www.ietf.org/internet-drafts/draft-qiu-roll- >>>> kemp-02.txt >>>> Status: http://datatracker.ietf.org/doc/draft-qiu-roll-kemp >>>> Htmlized: http://tools.ietf.org/html/draft-qiu-roll-kemp-02 >>>> Diff: http://www.ietf.org/rfcdiff?url2=draft-qiu-roll- >> kemp- >>>> 02 >>>> >>>> Abstract: >>>> When a sensor node roams within a very large and distributed >>>> wireless >>>> sensor network, which consists of numerous sensor nodes, its >> routing >>>> path and neighborhood keep changing. In order to provide a high >>>> level of security in this environment, the moving sensor node >> needs >>>> to be authenticated to new neighboring nodes as well as to >> establish >>>> a key for secure communication. The document proposes an >> efficient >>>> and scalable protocol to establish and update the secure key in a >>>> dynamic wireless sensor network environment. The protocol >>>> guarantees >>>> that two sensor nodes share at least one key with probability 1 >>>> (100%) with less memory and energy cost, while not causing >>>> considerable communication overhead. >>>> >>>> >>>> >>>> >>>> The IETF Secretariat >>> Institute for Infocomm Research disclaimer: "This email is >> confidential and may be privileged. If you are not the intended >> recipient, please delete it and notify us immediately. Please do not >> copy or use it for any purpose, or disclose its contents to any other >> person. Thank you." >>> _______________________________________________ >>> 6lowpan mailing list >>> 6lowpan@ietf.org >>> https://www.ietf.org/mailman/listinfo/6lowpan >> >> -- >> email: rstruik.ext@gmail.com | Skype: rstruik >> cell: +1 (647) 867-5658 | US: +1 (415) 690-7363 > Institute for Infocomm Research disclaimer: "This email is confidential and may be privileged. If you are not the intended recipient, please delete it and notify us immediately. Please do not copy or use it for any purpose, or disclose its contents to any other person. Thank you." -- email: rstruik.ext@gmail.com | Skype: rstruik cell: +1 (647) 867-5658 | US: +1 (415) 690-7363 From d.sturek@att.net Thu Nov 1 06:15:01 2012 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 855D521F8230 for ; Thu, 1 Nov 2012 06:15:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.086 X-Spam-Level: X-Spam-Status: No, score=-0.086 tagged_above=-999 required=5 tests=[AWL=0.516, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v0Y1TVS91bCl for ; Thu, 1 Nov 2012 06:14:56 -0700 (PDT) Received: from nm18.access.bullet.mail.mud.yahoo.com (nm18.access.bullet.mail.mud.yahoo.com [66.94.237.219]) by ietfa.amsl.com (Postfix) with ESMTP id E46B521F86F3 for ; Thu, 1 Nov 2012 06:14:46 -0700 (PDT) Received: from [66.94.237.198] by nm18.access.bullet.mail.mud.yahoo.com with NNFMP; 01 Nov 2012 13:14:46 -0000 Received: from [68.142.198.200] by tm9.access.bullet.mail.mud.yahoo.com with NNFMP; 01 Nov 2012 13:14:46 -0000 Received: from [127.0.0.1] by smtp101.sbc.mail.mud.yahoo.com with NNFMP; 01 Nov 2012 13:14:46 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=att.net; s=s1024; t=1351775686; bh=S2sx+NNDYwrGriNjlSAZ8SopRyagywVU9eT2Cf493aQ=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:Received:User-Agent:Date:Subject:From:To:Message-ID:Thread-Topic:In-Reply-To:Mime-version:Content-type; b=PCkBXpX83I2qNj9c8zwQsr3qjEq+uJPTivY1dVBQ0A/JmythaSqH0kPw4/qaL6abjTaTUK10Ff04FV+Te4JdfreQJVoG4bDmzMHYRvGRRLYL1Gdap9nROOELv9d6/KQx/liWfzy98kzVobdVAe3OmN6W9xiKnOOuwPhgxpRZzUI= X-Yahoo-Newman-Id: 423269.57137.bm@smtp101.sbc.mail.mud.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: 76tAW1YVM1nHe49uoN8OG9KRnSfxIaWJAkLMt0vzqSwqglK 0eQe6T0y_3LrZHf1UuzkgCGJgYM28wB9fHEMM2lECBxGVOF_SNPlMxiDpOgi _TO4Z8h79V__LvUHUpk31gCqKa4Xk0WBTDeTGJ2GkfHv1SWth6NvQxokM37n LCIM7qe7Pq6mCMHBzr8Yg4NZ2U.MyDX2kj8bKaIbWxA3WeSC0UHTCk86pxXL qmce2TWRZmdDZdvL0fc9Sh0cCTL_tWTEbETRsnjjho_zkuW.RHreBadbXMHZ fGDlaDi0D6JYNOCdBbl3JLKBvL3tljhWECnsEpdxVlea9lSiXBqzEShdG0K9 ZWtAFKT2qbtfvPqq.cMu1mfC9CGHR.sDKP3sA.aimtuuuG11_c_wEoCq6I6Y N8A2FK_K_Dk5.a92Y0sGJsdUG7IL10GbmZCA5dCdCX5X2bvdXJynVD0vIwLI Cq2wGSMnEIcMvIQ6LCEYX9ax_38X.UXnffkmG X-Yahoo-SMTP: fvjol_aswBAraSJvMLe2r1XTzhBhbFxY8q8c3jo- Received: from [192.168.0.198] (d.sturek@69.105.136.31 with login) by smtp101.sbc.mail.mud.yahoo.com with SMTP; 01 Nov 2012 06:14:46 -0700 PDT User-Agent: Microsoft-MacOutlook/14.2.4.120824 Date: Thu, 01 Nov 2012 06:13:26 -0700 From: Don Sturek To: "Dijk, Esko" , "robert.cragie@gridmerge.com" , "roll@ietf.org" Message-ID: Thread-Topic: [Roll] WG Last Call draft-ietf-roll-trickle-mcast-02 In-Reply-To: <031DD135F9160444ABBE3B0C36CED618B09BA5@011-DB3MPN2-082.MGDPHG.emi.philips.com> Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3434595284_109971" Subject: Re: [Roll] WG Last Call draft-ietf-roll-trickle-mcast-02 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Nov 2012 13:15:01 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3434595284_109971 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Hi Esko, I think much of what you write about below should be the subject of a different I-D. Back at an IETF a few years ago, we submitted a draft to v6ops that became part of the problem statement for homenet. One topic that I have not seen addressed is how to determine the boundaries of a site scope multicast (related to your point on configuring the border router for multicast traffic). I still think such a draft would be useful. Also, the second paragraph might also be the subject of another interesting I-D (perhaps for homenet). Don From: "Dijk, Esko" Date: Thursday, November 1, 2012 5:26 AM To: "robert.cragie@gridmerge.com" , "roll@ietf.org" Subject: Re: [Roll] WG Last Call draft-ietf-roll-trickle-mcast-02 Hi Robert, =20 these are very useful diagrams. I just wanted to point out for page 6, =B3Site local multicast originating externally=B2, that there is probably also configuration required (in the BR) of what multicast traffic is allowed by the BR onto the LLN. I assume that not all multicast traffic from the high-speed backbone network should be forwarded onto the LLN into the MPL domain as that could lead to congestion? =20 As a side note, this configuration would not be needed if we would have an equivalent of the MLD protocol , to let LLN nodes announce their interest i= n specific multicast groups. One specific solution (in case the BR is also a= n RPL DODAG root) is for nodes to use standard RPL DAOs containing multicast addresses of interest, to advertize the multicast groups of interest to the BR which can then automatically set up the =8Cfiltering rules=B9. But this is probably beyond the current MPL spec ;-) =20 regards, Esko =20 From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Robert Cragie Sent: Thursday 1 November 2012 9:31 To: roll@ietf.org Subject: Re: [Roll] WG Last Call draft-ietf-roll-trickle-mcast-02 =20 Hi Dario, Some comments inline. I have also attached some diagrams which hopefully help to illustrate some of the thought processes we went through when implementing and testing between the ZigBee IP vendors (comments welcome). Apologies in advance for the PDF format but ASCII art would have been difficult :-) Robert On 31/10/2012 11:22 PM, Dario Tedeschi wrote: > Yes, I'd like to try clarify why link-local scope was suggested for the > *outer* header. The reasons were: > 1. Link-local scope is the only scope where the boundaries are well defin= ed > (i.e. on the link). Higher scopes are not well-defined and can cover wide > domains depending on network configuration and administration. I agree and made essentially the same comment re. higher scopes. 1. With a higher scope, there is a chance that non-MPL aware routers may simply forward encapsulated multicast datagrams (MPL HbH option and all). W= e wouldn't want MPL datagrams to leak outside of an MPL domain. Which is why I think the encapsulation rules do need to be pretty specific. If link-local encapsulation is always used then providing the MPL forwarder rules are clear, the MPL domain is then entirely bounded by the MPL forwarders and there is no question regarding address scope and administration thereof. This cleanly covers Peter's case as well where he wants to forward into another PAN - it would be processed internally as an original non-MPL packet and then be "launched" into the other PAN using LL encapsulation for that PAN. Using other scopes for the outer header would still work but then there is the issue of administering the scope. However, this would need to be done in the case where no encapsulation is done anyway. 1. A higher scope complicates the forwarding logic that needs to be implemented in an MPL router. The complication comes when a router receives an MPL datagram and needs to figure out whether to decapsulate or not. Granted, the use of an MPL group would mitigate this problem to a degree, but link-local scope would make the decision to decapsulate very obvious an= d simple. I think it would have to be effectively decapsulated at every router anyway irrespective of the scope of the outer header to see if it needs to be processed - it is the inner header which counts there and the comments about multicast groups come into play in that discussion. But I agree using link-local makes that decision easy and somewhat clearer 1. In conjunction with 3. Link-local scope also makes it easier for an MPL router to determine if the inner multicast address is one that a higher layer (or an app) may be interested in. Agree that the rules are clearer for link-local 1. =20 Hopefully I haven't made things more confusing. Perish the thought ;-) - Dario On 31/10/2012 7:53 AM, Jonathan Hui (johui) wrote: Hi Peter, =20 The current draft does not place any restrictions on the MPL multicast scope. =20 If the LLN border router is an MPL forwarder, it can forward MPL multicast packets between different MPL multicast scope zones. To be explicit, if th= e original multicast packet's destination address has link-local scope, the MPL forwarder should not forward the packet again. If the original multicast packet's destination has a scope larger than the MPL multicast scope, then the MPL forwarder needs to forward the packet to other MPL multicast scope zones (which may or may not involve different interfaces). =20 Does that address your question? =20 -- Jonathan Hui =20 On Oct 31, 2012, at 3:54 AM, peter van der Stok wrote: =20 > Hi Jonathan, > =20 > To be absolutely sure: the MPL multicast scope can be link-local, ULA or > site-local? meaning the LLN border router can be a MPL forwarder? > In the latter case the LLN border router can forward link-local multicast= from > one interface to another? > =20 > Greetings, > =20 > peter > =20 > Jonathan Hui (johui) schreef op 2012-10-30 18:27: >> Yes, a goal of the current draft is to support both cases (use of >> IPv6-in-IPv6 encapsulation or not). >> =20 >> The intent is as follows: >> 1) If the source of the multicast packet is within the MPL forwarding >> domain and the destination has a scope equal to or smaller than the >> MPL multicast scope, then no IPv6-in-IPv6 encapsulation is required. >> 2) If the source of the multicast packet is outside the MPL >> forwarding domain or the destination has scope greater than the MPL >> multicast scope, then IPv6-in-IPv6 encapsulation is required. When >> using IPv6-in-IPv6 encapsulation, then the all MPL forwarders >> multicast address with scope =3D MPL multicast scope is used as the >> destination address in the outer header. >> =20 >> As mentioned in my other email, IPv6-in-IPv6 encapsulation is >> required if you want to use the IPv6 Destination Address to identify >> MPL forwarding scope zones. >> =20 >> Of course, this brings up Dario's practical point of how to configure >> the MPL multicast scope if we allow that to dynamically change. He >> proposes a simplifying suggestion of requiring IPv6-in-IPv6 >> encapsulation for all non-link-local multicasts. In other words, >> setting the MPL multicast scope to link-local. >> =20 >> Thoughts? >> =20 >> -- >> Jonathan Hui >> =20 >> On Oct 30, 2012, at 4:46 AM, Don Sturek >> wrote: >> =20 >>> Hi Peter, >>> =20 >>> I still need to read the latest draft so take what I say here with that= in >>> mind...... >>> =20 >>> I was hoping that we could support not using IP in IP tunneling if the >>> scope of the multicast transmission was only within the multi-link subn= et >>> managed by the border router. I was hoping that only transmission >>> emanating from outside the multi-link subnet, received at the border >>> router, with scope that includes the devices in the multi-link subnet >>> would require IP in IP tunneling (and vice versa in terms of multicasts >>> generated in the multi-link subnet with scope outside). I haven't yet >>> read the draft carefully to know if this is possible. >>> =20 >>> Don >>> =20 >>> =20 >>> On 10/30/12 1:34 AM, "peter van der Stok" >>> wrote: >>> =20 >>>> Hi Don, >>>> =20 >>>> and more specifically under which conditions. That gives the >>>> possibility to choose the conditions such that the encapsulation is no= t >>>> needed. >>>> =20 >>>> Don Sturek schreef op 2012-10-29 16:56: >>>>> Hi Peter, >>>>> =20 >>>>> I think your suggested changes to the Trickle Multicast draft point >>>>> out >>>>> why IP in IP tunneling is needed. >>>>> =20 >>>>> Don >>>>> =20 >>>>> =20 >>>>> =20 >>>>> On 10/29/12 3:44 AM, "peter van der Stok" >>>>> wrote: >>>>> =20 >>>>>> Dear WG, >>>>>> =20 >>>>>> =20 >>>>>> Attached my suggestions for text modifications including some nits. = I >>>>>> used the facilities of word to edit and comment text with traces. >>>>>> =20 >>>>>> When writing text about MC scope and MC domain, I was puzzled by the >>>>>> all MPL forwarders multicast address which removes the possibility t= o >>>>>> address a given multicast group. We expect multiple (possibly >>>>>> disjunct) >>>>>> MC groups in our wireless networks. >>>>>> Also I failed to understand why encapsulation was necessary once the >>>>>> message was received by the seed. >>>>>> To make it possible to configure the interface with one MC scope I >>>>>> added the possibility to use Unicast-Prefix-based IPv6 Multicast >>>>>> Addresses (RFC 3306). >>>>>> =20 >>>>>> =20 >>>>>> Probably, I overlooked many aspects which make the suggestions >>>>>> impractical, but I hope that the intention is clear. >>>>>> =20 >>>>>> Peter van der Stok >>>>>> =20 >>>>>> Michael Richardson schreef op 2012-10-25 23:30: >>>>>>> I suggest that you propose specific text to the list to modify the >>>>>>> document. >>>>>> _______________________________________________ >>>>>> Roll mailing list >>>>>> Roll@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/roll >>> =20 >>> _______________________________________________ >>> Roll mailing list >>> Roll@ietf.org >>> https://www.ietf.org/mailman/listinfo/roll _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll =20 The information contained in this message may be confidential and legally protected under applicable law. The message is intended solely for the addressee(s). If you are not the intended recipient, you are hereby notifie= d that any use, forwarding, dissemination, or reproduction of this message is strictly prohibited and may be unlawful. If you are not the intended recipient, please contact the sender by return e-mail and destroy all copie= s of the original message. _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll --B_3434595284_109971 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable
Hi Esko,

I think much of what you write about below should be the subject of = a different I-D.

Back at an IETF a few years ago, w= e submitted a draft to v6ops that became part of the problem statement for h= omenet.   One topic that I have not seen addressed is how to determine = the boundaries of a site scope multicast (related to your point on configuri= ng the border router for multicast traffic).   I still think such a dra= ft would be useful.

Also, the second paragraph migh= t also be the subject of another interesting I-D (perhaps for homenet).

Don


From: "Dijk, Esko" <esko.dijk@philips.com>
Date: = Thursday, November 1, 2012 5:26 AM
To: "robert.cragie@gri= dmerge.com" <robert.crag= ie@gridmerge.com>, "roll@ietf.org"= <roll@ietf.org>
Subject: Re: [Roll] WG Last Call draft-ietf-roll-tri= ckle-mcast-02

Hi Robert,

 

<= span style=3D"font-size: 11pt; color: rgb(31, 73, 125); font-family: Calibri, = sans-serif; ">these are very useful diagrams.  I just wanted to point o= ut for page 6, “Site local multicast originating externally”, th= at there is probably also configuration required (in the BR) of what multicast traffic is allowed by the BR onto t= he LLN.  I assume that not all multicast traffic from the high-speed ba= ckbone network should be forwarded onto the LLN into the MPL domain as that = could lead to congestion?

&nbs= p;

As  a side note, this = configuration would not be needed if we would have an equivalent of the MLD = protocol , to let LLN nodes announce their interest in specific multicast groups.  One specific solution (in case the BR is also an R= PL DODAG root) is for nodes to use standard RPL DAOs containing multicast ad= dresses of interest, to advertize the multicast groups of interest to the BR= which can then automatically set up the ‘filtering rules’. But this is probably beyond the current= MPL spec ;-)

 

regards,

Esko

 

From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Robert Cragie
Sent: Thursday 1 November 2012 = 9:31
To: roll@ietf.org
Su= bject: Re: [Roll] WG Last Call draft-ietf-roll-trickle-mcast-02

 

Hi Dario,

Some comments inline. I have also attached some diagrams which hopefully he= lp to illustrate some of the thought processes we went through when implemen= ting and testing between the ZigBee IP vendors (comments welcome). Apologies= in advance for the PDF format but ASCII art would have been difficult :-)

Robert

On 31/10/2012 11:22 PM, Dario T= edeschi wrote:

Yes, I'd like to try clarify why link-local scope= was suggested for the *outer* header. The reasons were:

  1. Link-local scope is the only scope whe= re the boundaries are well defined (i.e. on the link). Higher scopes are not= well-defined and can cover wide domains depending on network configuration = and administration.

<RCC>I = agree and made essentially the same comment re. higher scopes.</RCC>

  1. With a highe= r scope, there is a chance that non-MPL aware routers may simply forward enc= apsulated multicast datagrams (MPL HbH option and all). We wouldn't want MPL= datagrams to leak outside of an MPL domain.

&= lt;RCC>Which is why I think the encapsulation rules do need to be pretty = specific. If link-local encapsulation is always used then providing the MPL = forwarder rules are clear, the MPL domain is then entirely bounded by the MP= L forwarders and there is no question regarding address scope and administration thereo= f. This cleanly covers Peter's case as well where he wants to forward into a= nother PAN - it would be processed internally as an original non-MPL packet = and then be "launched" into the other PAN using LL encapsulation for that PAN. Using other scopes for the = outer header would still work but then there is the issue of administering t= he scope. However, this would need to be done in the case where no encapsula= tion is done anyway.</RCC>

  1. A higher scope complicates the forwarding logic that n= eeds to be implemented in an MPL router. The complication comes when a route= r receives an MPL datagram and needs to figure out whether to decapsulate or= not. Granted, the use of an MPL group would mitigate this problem to a degree, but link-local sc= ope would make the decision to decapsulate very obvious and simple.

    2. <RCC>I think it would have to be effectively dec= apsulated at every router anyway irrespective of the scope of the outer head= er to see if it needs to be processed - it is the inner header which counts = there and the comments about multicast groups come into play in that discussion. But I agree using link-local mak= es that decision easy and somewhat clearer</RCC>

    1. In conjunction with 3. Link-loca= l scope also makes it easier for an MPL router to determine if the inner mul= ticast address is one that a higher layer (or an app) may be interested in.<= /li>

    <RCC>Agree that the rules are clearer fo= r link-local</RCC>

    1.  

    Hopefully I haven't made = things more confusing.


    <RCC>Perish the thought ;-)</RCC>


    - Dario

    On 31/10/2012 7:53 AM, Jonathan Hui (johui) wrote: 

    Hi Peter,
    = 
     
    The current draft does not place any restrictions on t=
he MPL multicast scope.
     
    If the LLN border router =
is an MPL forwarder, it can forward MPL multicast packets between different =
MPL multicast scope zones.  To be explicit, if the original multicast p=
acket's destination address has link-local scope, the MPL forwarder should n=
ot forward the packet again.  If the original multicast packet's destin=
ation has a scope larger than the MPL multicast scope, then the MPL forwarde=
r needs to forward the packet to other MPL multicast scope zones (which may =
or may not involve different interfaces).
     
    Does th=
at address your question?
     
    --
    Jonathan H=
ui
     
    On Oct 31, 2012, at 3:54 AM, peter van der Sto=
k <stokcons@xs4all.nl> wrote:<=
/pre>
     
    Hi Jonathan,
     
    To be absolutely sure: the =
MPL multicast scope can be link-local, ULA or site-local? meaning the LLN bo=
rder router can be a MPL forwarder?
    In the latter case the LLN bor=
der router can forward link-local multicast from one interface to another?
     
    Greetings,
     
    peter
    <=
pre> 
    Jonathan Hui (johui) schreef op 2012-10-30 18:27:
    =

    Yes, a goal o=
f the current draft is to support both cases (use of
    IPv6-in-IPv6 =
encapsulation or not).
     
    The intent is as follows:<=
/pre>
    1) If the source of the multicast packet is within the MPL forward=
ing
    domain and the destination has a scope equal to or smaller tha=
n the
    MPL multicast scope, then no IPv6-in-IPv6 encapsulation is r=
equired.
    2) If the source of the multicast packet is outside the M=
PL
    forwarding domain or the destination has scope greater than the=
 MPL
    multicast scope, then IPv6-in-IPv6 encapsulation is required.=
  When
    using IPv6-in-IPv6 encapsulation, then the all MPL for=
warders
    multicast address with scope =3D MPL multicast scope is used=
 as the
    destination address in the outer header.
     <=
/pre>
    As mentioned in my other email, IPv6-in-IPv6 encapsulation is
    required if you want to use the IPv6 Destination Address to identify
    MPL forwarding scope zones.
     
    Of course, t=
his brings up Dario's practical point of how to configure
    the MPL =
multicast scope if we allow that to dynamically change.  He
    p=
roposes a simplifying suggestion of requiring IPv6-in-IPv6
    encapsu=
lation for all non-link-local multicasts.  In other words,
    se=
tting the MPL multicast scope to link-local.
     
    Thou=
ghts?
     
    --
    Jonathan Hui
     <=
/pre>
    On Oct 30, 2012, at 4:46 AM, Don Sturek <d.sturek@att.net> wrote:
     
    Hi Peter,
    &nb=
sp;
    I still need to read the latest draft so take what I say here =
with that in
    mind......
     
    I was hoping th=
at we could support not using IP in IP tunneling if the
    scope of t=
he multicast transmission was only within the multi-link subnet
    ma=
naged by the border router.   I was hoping that only transmission<=
/pre>
    emanating from outside the multi-link subnet, received at the bord=
er
    router, with scope that includes the devices in the multi-link =
subnet
    would require IP in IP tunneling (and vice versa in terms o=
f multicasts
    generated in the multi-link subnet with scope outside=
).  I haven't yet
    read the draft carefully to know if this is=
 possible.
     
    Don
     
     <=
/pre>
    On 10/30/12 1:34 AM, "peter van der Stok" <stokcons@xs4all.nl> wrote:
     
    Hi Don,
     
    and more specifically under which conditions. That gives t=
he
    possibility to choose the conditions such that the encapsulatio=
n is not
    needed.
     
    Don Sturek schreef op =
2012-10-29 16:56:
    Hi Peter,
     
    I think your suggested change=
s to the Trickle Multicast draft point
    out
    why IP in IP =
tunneling is needed.
     
    Don
     
     
     
    On 10/29/12 3:44 AM, "peter van der Sto=
k" <stokcons@xs4all.nl> wrote:=

     
    Dear WG,
     
     
    Attached my s=
uggestions for text modifications including some nits. I
    used the =
facilities of word to edit and comment text with traces.
     
    When writing text about MC scope and MC domain, I was puzzled by the=

    all MPL forwarders multicast address which removes the possibilit=
y to
    address a given multicast group. We expect multiple (possibly=

    disjunct)
    MC groups in our wireless networks.
    Also I failed to understand why encapsulation was necessary once the
    <=
pre>message was received by the seed.
    To make it possible to confi=
gure the interface with one MC scope I
    added the possibility to us=
e Unicast-Prefix-based IPv6 Multicast
    Addresses (RFC 3306).
    <=
pre> 
     
    Probably, I overlooked many aspects wh=
ich make the suggestions
    impractical, but I hope that the intentio=
n is clear.
     
    Peter van der Stok
     
    Michael Richardson schreef op 2012-10-25 23:30:
    I suggest that you propose =
specific text to the list to modify the
    document.
    _______________________________________________
    Roll mailin=
g list
    Roll@ietf.org
    =
https://www.ietf.org/ma=
ilman/listinfo/roll
    &nb=
sp;
    _______________________________________________
    Roll=
 mailing list
    Roll@ietf.org
    https://www.ietf=
.org/mailman/listinfo/roll
    <=
pre>_______________________________________________
    Roll mailing l=
ist
    Roll@ietf.org
    https://www.ietf.org/mailm=
an/listinfo/roll




    ____=
___________________________________________
    Roll mailing list
    Roll@ietf.org
    https://www.ietf.org/mailman/listi=
nfo/roll
     

The information contained in this message may be= confidential and legally protected under applicable law. The message is int= ended solely for the addressee(s). If you are not the intended recipient, yo= u are hereby notified that any use, forwarding, dissemination, or reproduction of this message i= s strictly prohibited and may be unlawful. If you are not the intended recip= ient, please contact the sender by return e-mail and destroy all copies of t= he original message.
_______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/m= ailman/listinfo/roll --B_3434595284_109971-- From esko.dijk@philips.com Thu Nov 1 06:18:13 2012 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CC2E21F89BD for ; Thu, 1 Nov 2012 06:18:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.109 X-Spam-Level: X-Spam-Status: No, score=-3.109 tagged_above=-999 required=5 tests=[AWL=0.490, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mycROW-5oLcb for ; Thu, 1 Nov 2012 06:18:12 -0700 (PDT) Received: from db3outboundpool.messaging.microsoft.com (db3ehsobe002.messaging.microsoft.com [213.199.154.140]) by ietfa.amsl.com (Postfix) with ESMTP id E79AD21F8A5D for ; Thu, 1 Nov 2012 06:17:57 -0700 (PDT) Received: from mail106-db3-R.bigfish.com (10.3.81.249) by DB3EHSOBE007.bigfish.com (10.3.84.27) with Microsoft SMTP Server id 14.1.225.23; Thu, 1 Nov 2012 13:17:57 +0000 Received: from mail106-db3 (localhost [127.0.0.1]) by mail106-db3-R.bigfish.com (Postfix) with ESMTP id E99BB44049C; Thu, 1 Nov 2012 13:17:56 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.55.7.222; KIP:(null); UIP:(null); IPV:NLI; H:mail.philips.com; RD:none; EFVD:NLI X-SpamScore: -39 X-BigFish: VPS-39(zz217bI98dI15d6O9371I9251Jd6eah542M1432I1418Izz1202h1d1ah1d2ahzz1033IL8275bh8275dhz2dh2a8h668h839h944hd25hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh1155h) Received: from mail106-db3 (localhost.localdomain [127.0.0.1]) by mail106-db3 (MessageSwitch) id 1351775875363910_32767; Thu, 1 Nov 2012 13:17:55 +0000 (UTC) Received: from DB3EHSMHS020.bigfish.com (unknown [10.3.81.247]) by mail106-db3.bigfish.com (Postfix) with ESMTP id 4C4022600F6; Thu, 1 Nov 2012 13:17:55 +0000 (UTC) Received: from mail.philips.com (157.55.7.222) by DB3EHSMHS020.bigfish.com (10.3.87.156) with Microsoft SMTP Server (TLS) id 14.1.225.23; Thu, 1 Nov 2012 13:17:53 +0000 Received: from 011-DB3MMR1-022.MGDPHG.emi.philips.com (10.128.28.105) by 011-DB3MMR1-003.MGDPHG.emi.philips.com (10.128.28.53) with Microsoft SMTP Server (TLS) id 14.2.309.3; Thu, 1 Nov 2012 13:17:10 +0000 Received: from 011-DB3MPN2-082.MGDPHG.emi.philips.com ([169.254.2.20]) by 011-DB3MMR1-022.MGDPHG.emi.philips.com ([fe80::1113:17d7:70dc:6faa%11]) with mapi id 14.02.0309.003; Thu, 1 Nov 2012 13:17:10 +0000 From: "Dijk, Esko" To: "Jonathan Hui (johui)" , "Reddy, Joseph" Thread-Topic: [Roll] I-D Action: draft-ietf-roll-trickle-mcast-02.txt Thread-Index: Ac23wx9aBfIsegKOz0GvSDMMHJeV6gAKpCOAABDebyA= Date: Thu, 1 Nov 2012 13:17:10 +0000 Message-ID: <031DD135F9160444ABBE3B0C36CED618B09C5B@011-DB3MPN2-082.MGDPHG.emi.philips.com> References: <2AA5AC69E924D149A8D63EB676AF87DB2CAE2DB8@DLEE10.ent.ti.com> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [194.171.252.103] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: philips.com Cc: "roll@ietf.org" Subject: Re: [Roll] I-D Action: draft-ietf-roll-trickle-mcast-02.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Nov 2012 13:18:13 -0000 > Any feedback from others in the WG on this? Should we include support fo= r selecting 1, 2, or more parameter sets? Having two parameter sets is useful to support two main uses of multicast i= n LLNs for the building control domain; 1) Device/service discovery, such as mDNS and CoAP's /.well-known/core. Latency is less important here; avoiding high network load due to discovery= traffic is also a goal if other more time-critical application are running= at the same time. -> "slow" Trickle parameter set 2) Building Control involving groups of devices Latency can be important (e.g. lighting control, or any device operation tr= iggered by sensors or smartphones) -> "fast" Trickle parameter set Esko -----Original Message----- From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Jon= athan Hui (johui) Sent: Thursday 1 November 2012 6:00 To: Reddy, Joseph Cc: roll@ietf.org Subject: Re: [Roll] I-D Action: draft-ietf-roll-trickle-mcast-02.txt Hi Joseph, Comments below: On Oct 31, 2012, at 5:00 PM, "Reddy, Joseph" wrote: > Here are some comments on the trickle multicast draft rev-02 > > 1. MPL multicast scope: > I think fixing it to link-local is too restrictive as it will force encap= sulation even when it is not needed. > Regarding the practical aspects of determining the MPL scope, I think tha= t can be left to "administrative configuration". Other multicast details (e= .g., the zone boundaries for scopes greater than link local) have to be adm= inistratively configured anyway. I agree that it is desirable to avoid encapsulation when possible. There is an important difference depending on whether encapsulation is used= : 1) With encapsulation, the IPv6 Destination Address of the outer header exp= licitly identifies the MPL scope zone. 2) Without encapsulation, the IPv6 Destination Address identifies the endpo= ints that should process the IPv6 payload. However, the IPv6 Destination A= ddress may not explicitly identify the MPL scope zone. Instead, the IPv6 S= ource Address identifies the MPL scope zone. It is easy to determine the s= cope zone if we require the separation to occur across interface boundaries= (just observe what interface the message came in on). However, it is not = so easy to determine the scope zone if we want a single interface to servic= e more than one MPL scope zone. I believe the latter case is what Peter is= looking for. One solution is to require the IPv6 Destination Address to a= lso identify MPL forwarders that will forward the message. Another solutio= n is to include an MPL domain/instance identifier in the MPL Option. Yet a= nother solution is to eliminate this case and always require encapsulation. > 2. Supporting different Trickle parameter sets: > I think this is a useful feature and should be included even if it is a s= ingle flag (2 parameter sets). Typical use cases for multicast in LLN's try= to achieve either high reliability or low latency and having two sets of t= rickle parameters for each of them should help Any feedback from others in the WG on this? Should we include support for = selecting 1, 2, or more parameter sets? > 3. Version field: > I think adding an explicit version field ( 2 bits should be enough) will = help. OK. Any additional inputs from the WG? > 4. Destination address: > Is there a reason to restrict the destination address of the MPL packet t= o the "all-MPL-forwarders" multicast address? Nodes that receives an MPL pa= cket but don't understand the MPL option will discard it anyway. I think the most compelling reason is to remove yet another configuration p= arameter. But allowing arbitrary multicast addresses to identify MPL forwa= rders would be necessary to support multiple MPL scope zones using the IPv6= Destination Address. If we require encapsulation with link-lcoal multicas= t, then an all-MPL-forwarders address would be ok. Thoughts? -- Jonathan Hui _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll ________________________________ The information contained in this message may be confidential and legally p= rotected under applicable law. The message is intended solely for the addre= ssee(s). If you are not the intended recipient, you are hereby notified tha= t any use, forwarding, dissemination, or reproduction of this message is st= rictly prohibited and may be unlawful. If you are not the intended recipien= t, please contact the sender by return e-mail and destroy all copies of the= original message. From trac+roll@trac.tools.ietf.org Thu Nov 1 07:11:53 2012 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8ED8C21F8CDF for ; Thu, 1 Nov 2012 07:11:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.377 X-Spam-Level: X-Spam-Status: No, score=-102.377 tagged_above=-999 required=5 tests=[AWL=0.222, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AKM4JI8s5Frl for ; Thu, 1 Nov 2012 07:11:53 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [77.72.230.30]) by ietfa.amsl.com (Postfix) with ESMTP id 00D0921F8CD1 for ; Thu, 1 Nov 2012 07:11:53 -0700 (PDT) Received: from localhost ([127.0.0.1]:37663 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1TTvUe-0004XT-T2; Thu, 01 Nov 2012 15:11:46 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "roll issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: draft-ietf-roll-minrank-hysteresis-of@tools.ietf.org, mcr@sandelman.ca X-Trac-Project: roll Date: Thu, 01 Nov 2012 14:11:36 -0000 X-URL: http://tools.ietf.org/wg/roll/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/roll/trac/ticket/99#comment:1 Message-ID: <073.5233c03e546c96c1b89454642398a5d0@trac.tools.ietf.org> References: <058.aaa3fc2efaae8e26a2ada588bce49a89@trac.tools.ietf.org> X-Trac-Ticket-ID: 99 In-Reply-To: <058.aaa3fc2efaae8e26a2ada588bce49a89@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-roll-minrank-hysteresis-of@tools.ietf.org, mcr@sandelman.ca, roll@ietf.org X-SA-Exim-Mail-From: trac+roll@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: gnawali@cs.uh.edu Resent-Message-Id: <20121101141153.00D0921F8CD1@ietfa.amsl.com> Resent-Date: Thu, 1 Nov 2012 07:11:53 -0700 (PDT) Resent-From: trac+roll@trac.tools.ietf.org Cc: roll@ietf.org Subject: Re: [Roll] [roll] #99: clarify for readers how/where provisioning of devices occurs X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Reply-To: roll@ietf.org List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Nov 2012 14:11:53 -0000 #99: clarify for readers how/where provisioning of devices occurs Changes (by mcr@…): * status: new => closed * resolution: => fixed -- -------------------------+------------------------------------------------- Reporter: mcr@… | Owner: draft-ietf-roll-minrank- Type: task | hysteresis-of@… Priority: major | Status: closed Component: minrank- | Milestone: hysteresis-of | Version: Severity: In WG Last | Resolution: fixed Call | Keywords: | -------------------------+------------------------------------------------- Ticket URL: roll From trac+roll@trac.tools.ietf.org Thu Nov 1 07:28:52 2012 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E63DB21F8DBA for ; Thu, 1 Nov 2012 07:28:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.414 X-Spam-Level: X-Spam-Status: No, score=-102.414 tagged_above=-999 required=5 tests=[AWL=0.185, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DApY6XlIYk3N for ; Thu, 1 Nov 2012 07:28:52 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [77.72.230.30]) by ietfa.amsl.com (Postfix) with ESMTP id 5DB3021F8CD7 for ; Thu, 1 Nov 2012 07:28:52 -0700 (PDT) Received: from localhost ([127.0.0.1]:39116 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1TTvl1-0005oj-MB; Thu, 01 Nov 2012 15:28:46 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "roll issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: draft-ietf-roll-trickle-mcast@tools.ietf.org, mcr@sandelman.ca X-Trac-Project: roll Date: Thu, 01 Nov 2012 14:28:31 -0000 X-URL: http://tools.ietf.org/wg/roll/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/roll/trac/ticket/107 Message-ID: <058.d8b807f46e7601c2df8bad69d7cb737b@trac.tools.ietf.org> X-Trac-Ticket-ID: 107 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-roll-trickle-mcast@tools.ietf.org, mcr@sandelman.ca, roll@ietf.org X-SA-Exim-Mail-From: trac+roll@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: jonhui@cisco.com, richard.kelsey@silabs.com Resent-Message-Id: <20121101142852.5DB3021F8CD7@ietfa.amsl.com> Resent-Date: Thu, 1 Nov 2012 07:28:52 -0700 (PDT) Resent-From: trac+roll@trac.tools.ietf.org Cc: roll@ietf.org Subject: [Roll] [roll] #107: trickle-mcast: should multiple parameter sets be supported X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Reply-To: roll@ietf.org List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Nov 2012 14:28:53 -0000 #107: trickle-mcast: should multiple parameter sets be supported Should multiple parameter sets be included as a single flag? Typical use cases for multicast in LLN's try to achieve either high reliability or low latency and having two sets of trickle parameters for each of them should help Any feedback from others in the WG on this? Should we include support for selecting 1, 2, or more parameter sets? -- -----------------------------+--------------------------------------------- Reporter: mcr@… | Owner: draft-ietf-roll-trickle-mcast@… Type: enhancement | Status: new Priority: major | Milestone: Component: trickle-mcast | Version: Severity: In WG Last Call | Keywords: -----------------------------+--------------------------------------------- Ticket URL: roll From trac+roll@trac.tools.ietf.org Thu Nov 1 07:29:59 2012 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C12F721F8CD2 for ; Thu, 1 Nov 2012 07:29:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.441 X-Spam-Level: X-Spam-Status: No, score=-102.441 tagged_above=-999 required=5 tests=[AWL=0.159, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v6QF3gB9ps9X for ; Thu, 1 Nov 2012 07:29:59 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [77.72.230.30]) by ietfa.amsl.com (Postfix) with ESMTP id 2243121F8C17 for ; Thu, 1 Nov 2012 07:29:59 -0700 (PDT) Received: from localhost ([127.0.0.1]:39158 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1TTvmM-00060j-FS; Thu, 01 Nov 2012 15:29:54 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "roll issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: draft-ietf-roll-trickle-mcast@tools.ietf.org, mcr@sandelman.ca X-Trac-Project: roll Date: Thu, 01 Nov 2012 14:29:54 -0000 X-URL: http://tools.ietf.org/wg/roll/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/roll/trac/ticket/108 Message-ID: <058.a2b4f297c2cf9334c783ff7c900bdb13@trac.tools.ietf.org> X-Trac-Ticket-ID: 108 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-roll-trickle-mcast@tools.ietf.org, mcr@sandelman.ca, roll@ietf.org X-SA-Exim-Mail-From: trac+roll@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: jonhui@cisco.com, richard.kelsey@silabs.com Resent-Message-Id: <20121101142959.2243121F8C17@ietfa.amsl.com> Resent-Date: Thu, 1 Nov 2012 07:29:59 -0700 (PDT) Resent-From: trac+roll@trac.tools.ietf.org Cc: roll@ietf.org Subject: [Roll] [roll] #108: trickle-mcast: should there be an explicit version field? X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Reply-To: roll@ietf.org List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Nov 2012 14:29:59 -0000 #108: trickle-mcast: should there be an explicit version field? > 3. Version field: > I think adding an explicit version field ( 2 bits should be enough) > will help. OK. Any additional inputs from the WG? -- -----------------------------+--------------------------------------------- Reporter: mcr@… | Owner: draft-ietf-roll-trickle-mcast@… Type: defect | Status: new Priority: major | Milestone: Component: trickle-mcast | Version: Severity: In WG Last Call | Keywords: -----------------------------+--------------------------------------------- Ticket URL: roll From trac+roll@trac.tools.ietf.org Thu Nov 1 07:34:25 2012 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1170721F8DC3 for ; Thu, 1 Nov 2012 07:34:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.46 X-Spam-Level: X-Spam-Status: No, score=-102.46 tagged_above=-999 required=5 tests=[AWL=0.139, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R9tv6n-Jo7gv for ; Thu, 1 Nov 2012 07:34:24 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [77.72.230.30]) by ietfa.amsl.com (Postfix) with ESMTP id 7458B21F8DC2 for ; Thu, 1 Nov 2012 07:34:24 -0700 (PDT) Received: from localhost ([127.0.0.1]:39587 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1TTvqP-0003vR-4o; Thu, 01 Nov 2012 15:34:20 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "roll issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: draft-ietf-roll-trickle-mcast@tools.ietf.org, mcr@sandelman.ca X-Trac-Project: roll Date: Thu, 01 Nov 2012 14:34:05 -0000 X-URL: http://tools.ietf.org/wg/roll/ X-Trac-Ticket-URL: https://svn.tools.ietf.org/wg/roll/trac/ticket/109 Message-ID: <058.17a4c61a0b0575298f48df9ded41bd6b@trac.tools.ietf.org> X-Trac-Ticket-ID: 109 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-roll-trickle-mcast@tools.ietf.org, mcr@sandelman.ca, roll@ietf.org X-SA-Exim-Mail-From: trac+roll@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: jonhui@cisco.com, richard.kelsey@silabs.com Resent-Message-Id: <20121101143424.7458B21F8DC2@ietfa.amsl.com> Resent-Date: Thu, 1 Nov 2012 07:34:24 -0700 (PDT) Resent-From: trac+roll@trac.tools.ietf.org Cc: roll@ietf.org Subject: [Roll] [roll] #109: trickle-mcast: should all MPL packets be destined to all-MPL-forwarders X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Reply-To: roll@ietf.org List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Nov 2012 14:34:25 -0000 #109: trickle-mcast: should all MPL packets be destined to all-MPL-forwarders > 4. Destination address: Is there a reason to restrict the destination address of the MPL packet to the "all-MPL-forwarders" multicast address? Nodes that receives an MPL packet but don't understand the MPL option will discard it anyway. I think the most compelling reason is to remove yet another configuration parameter. But allowing arbitrary multicast addresses to identify MPL forwarders would be necessary to support multiple MPL scope zones using the IPv6 Destination Address. If we require encapsulation with link-local multicast, then an all-MPL-forwarders address would be ok. -- -----------------------------+--------------------------------------------- Reporter: mcr@… | Owner: draft-ietf-roll-trickle-mcast@… Type: enhancement | Status: new Priority: major | Milestone: Component: trickle-mcast | Version: Severity: In WG Last Call | Keywords: -----------------------------+--------------------------------------------- Ticket URL: roll From d.sturek@att.net Thu Nov 1 07:35:20 2012 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F30E21F87FB for ; Thu, 1 Nov 2012 07:35:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.914 X-Spam-Level: X-Spam-Status: No, score=-0.914 tagged_above=-999 required=5 tests=[AWL=1.085, BAYES_00=-2.599, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b7+dQmGOzPLg for ; Thu, 1 Nov 2012 07:35:19 -0700 (PDT) Received: from nm1.access.bullet.mail.mud.yahoo.com (nm1.access.bullet.mail.mud.yahoo.com [66.94.237.202]) by ietfa.amsl.com (Postfix) with ESMTP id C4BD121F86CE for ; Thu, 1 Nov 2012 07:35:14 -0700 (PDT) Received: from [66.94.237.126] by nm1.access.bullet.mail.mud.yahoo.com with NNFMP; 01 Nov 2012 14:35:14 -0000 Received: from [68.142.198.106] by tm1.access.bullet.mail.mud.yahoo.com with NNFMP; 01 Nov 2012 14:35:14 -0000 Received: from [127.0.0.1] by smtp108.sbc.mail.mud.yahoo.com with NNFMP; 01 Nov 2012 14:35:14 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=att.net; s=s1024; t=1351780514; bh=18egzhVRpn0SqpAwJeTxpsQHT4rqqDVC1LUzZ+YJwJU=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:Received:User-Agent:Date:Subject:From:To:CC:Message-ID:Thread-Topic:In-Reply-To:Mime-version:Content-type:Content-transfer-encoding; b=2IZdQ9OgK8NoSR/Va9XsddPUD0bGoBeZKzGs3zeqSgaKxfoHhMcW2YPevW3cF/ZiH8DY6CtjGzrs3EMoNQ+7Hqzl+TuPFLDbVcyyHxFktL+7bAMZ3bHT6laB1MaHO2dE0MF9cdkEcP/T8YCZsLGlWcLaY4iuzSGBIiUbjqAep/w= X-Yahoo-Newman-Id: 66560.88331.bm@smtp108.sbc.mail.mud.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: Yie1XyYVM1lPGXGRfbYd4fM9hu2sMWLnfdYhNDJzvJ4X9vH 3cvIZ8Z6JShfO2gi7VX3JmIb6psbxId_2npKMUuEigmxIN3KKtxS9SIFQkRb 4PhB_g8Ie3LVsWLRPvga_x2.DwVsyJEnkvrXL762EYsX0jIeMQibctkiDQuW 1jfWEhve8lN3kf7vox2ZP7Au813o33UMVi7TEhlFFeFJvBTla_5wdukjuVwj SBIWqH.Q_9Yc4dGQ_hC7sZe_loG6rEadRqISr3YctXXoP5D.4u3eCOe0lrbD .QxgoFNIw5ItC1OuoDQxwG.PidYH_NdwxmUsG7vrdI7XfKjtlIi6cR1555KJ qBXkoSJ9p27SlZtHQVB8y5nlPqxzyYnkqxRoqZUUM3CmMscwEF2Kt.i.adq1 KOmp8LZFHBJuDwPLikfsrnbsnePj9_swe1mC26BDBsItW_vKI1x92StROQ_e 7WLAut035CH0pzXEieAusJfVSiVxtL0Nkh5M2WqmQA54hJzxfe7ooYeTLoqD cQj4ngYxZHIjsGYNsHP6rq3rUnyX8yRPpizEVby42FpM- X-Yahoo-SMTP: fvjol_aswBAraSJvMLe2r1XTzhBhbFxY8q8c3jo- Received: from [192.168.0.198] (d.sturek@69.105.136.31 with login) by smtp108.sbc.mail.mud.yahoo.com with SMTP; 01 Nov 2012 07:35:13 -0700 PDT User-Agent: Microsoft-MacOutlook/14.2.4.120824 Date: Thu, 01 Nov 2012 07:33:58 -0700 From: Don Sturek To: Michael Richardson Message-ID: Thread-Topic: [Roll] WG Last Call draft-ietf-roll-trickle-mcast-02 In-Reply-To: <1541.1351779655@obiwan.sandelman.ca> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: "roll@ietf.org" Subject: Re: [Roll] WG Last Call draft-ietf-roll-trickle-mcast-02 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Nov 2012 14:35:21 -0000 Hi Michael, I think a document establishing the scoping rules on site local multicast is a completely separate topic from the trickle multicast draft. However, I think an I-D that starts to define site local boundaries would be extremely useful. Don On 11/1/12 7:20 AM, "Michael Richardson" wrote: > >>>>>> "Don" == Don Sturek writes: > Don> I think much of what you write about below should be the subject >of a > Don> different I-D. > > Don> Back at an IETF a few years ago, we submitted a draft to v6ops > Don> that became > Don> part of the problem statement for homenet. One topic that I > Don> have not seen > Don> addressed is how to determine the boundaries of a site scope > Don> multicast > >Are you saying that we should have a normative reference to this work >(which I know is hardly even started), or what? > >-- >Michael Richardson , Sandelman Software Works >IETF ROLL WG co-chair. http://datatracker.ietf.org/wg/roll/charter/ > From trac+roll@trac.tools.ietf.org Thu Nov 1 07:36:01 2012 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBE6A21F86CE for ; Thu, 1 Nov 2012 07:36:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.476 X-Spam-Level: X-Spam-Status: No, score=-102.476 tagged_above=-999 required=5 tests=[AWL=0.123, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bts7Aq3gFxEI for ; Thu, 1 Nov 2012 07:36:00 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [77.72.230.30]) by ietfa.amsl.com (Postfix) with ESMTP id A5C0E21F8B18 for ; Thu, 1 Nov 2012 07:36:00 -0700 (PDT) Received: from localhost ([127.0.0.1]:39954 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1TTvsB-0003wp-Sk; Thu, 01 Nov 2012 15:35:55 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "roll issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: draft-ietf-roll-trickle-mcast@tools.ietf.org, mcr@sandelman.ca X-Trac-Project: roll Date: Thu, 01 Nov 2012 14:35:55 -0000 X-URL: http://tools.ietf.org/wg/roll/ X-Trac-Ticket-URL: https://svn.tools.ietf.org/wg/roll/trac/ticket/107#comment:1 Message-ID: <073.0765e1c9ec66f3b96aa551e138b4b1c3@trac.tools.ietf.org> References: <058.d8b807f46e7601c2df8bad69d7cb737b@trac.tools.ietf.org> X-Trac-Ticket-ID: 107 In-Reply-To: <058.d8b807f46e7601c2df8bad69d7cb737b@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-roll-trickle-mcast@tools.ietf.org, mcr@sandelman.ca, roll@ietf.org X-SA-Exim-Mail-From: trac+roll@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: jonhui@cisco.com, richard.kelsey@silabs.com Resent-Message-Id: <20121101143600.A5C0E21F8B18@ietfa.amsl.com> Resent-Date: Thu, 1 Nov 2012 07:36:00 -0700 (PDT) Resent-From: trac+roll@trac.tools.ietf.org Cc: roll@ietf.org Subject: Re: [Roll] [roll] #107: trickle-mcast: should multiple parameter sets be supported X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Reply-To: roll@ietf.org List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Nov 2012 14:36:02 -0000 #107: trickle-mcast: should multiple parameter sets be supported Comment (by mcr@…): From: "Dijk, Esko" > Any feedback from others in the WG on this? Should we include support for selecting 1, 2, or more parameter sets? Having two parameter sets is useful to support two main uses of multicast in LLNs for the building control domain; 1) Device/service discovery, such as mDNS and CoAP's /.well-known/core. Latency is less important here; avoiding high network load due to discovery traffic is also a goal if other more time-critical application are running at the same time. -> "slow" Trickle parameter set 2) Building Control involving groups of devices Latency can be important (e.g. lighting control, or any device operation triggered by sensors or smartphones) -> "fast" Trickle parameter set -- ----------------------------+---------------------------------------------- Reporter: mcr@… | Owner: draft-ietf-roll-trickle-mcast@… Type: enhancement | Status: new Priority: major | Milestone: Component: trickle-mcast | Version: Severity: In WG Last | Resolution: Call | Keywords: | ----------------------------+---------------------------------------------- Ticket URL: roll From trac+roll@trac.tools.ietf.org Thu Nov 1 07:47:35 2012 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E10721F8B20 for ; Thu, 1 Nov 2012 07:47:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.488 X-Spam-Level: X-Spam-Status: No, score=-102.488 tagged_above=-999 required=5 tests=[AWL=0.111, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8rt+DENUwQft for ; Thu, 1 Nov 2012 07:47:34 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [77.72.230.30]) by ietfa.amsl.com (Postfix) with ESMTP id 6F1B521F8A96 for ; Thu, 1 Nov 2012 07:47:34 -0700 (PDT) Received: from localhost ([127.0.0.1]:40911 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1TTw3D-0000XP-QP; Thu, 01 Nov 2012 15:47:29 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "roll issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: draft-ietf-roll-trickle-mcast@tools.ietf.org, mcr@sandelman.ca X-Trac-Project: roll Date: Thu, 01 Nov 2012 14:47:19 -0000 X-URL: http://tools.ietf.org/wg/roll/ X-Trac-Ticket-URL: https://svn.tools.ietf.org/wg/roll/trac/ticket/110 Message-ID: <058.c053ae172b60ad763a419d3caf1dd7ac@trac.tools.ietf.org> X-Trac-Ticket-ID: 110 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-roll-trickle-mcast@tools.ietf.org, mcr@sandelman.ca, roll@ietf.org X-SA-Exim-Mail-From: trac+roll@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: jonhui@cisco.com, richard.kelsey@silabs.com Resent-Message-Id: <20121101144734.6F1B521F8A96@ietfa.amsl.com> Resent-Date: Thu, 1 Nov 2012 07:47:34 -0700 (PDT) Resent-From: trac+roll@trac.tools.ietf.org Cc: roll@ietf.org Subject: [Roll] [roll] #110: trickle-mcast: do applications receive all multicast, or just MPL encapsulated ones X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Reply-To: roll@ietf.org List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Nov 2012 14:47:35 -0000 #110: trickle-mcast: do applications receive all multicast, or just MPL encapsulated ones There's still the case that multicasts from non-MPL nodes are received by MPL-forwarder-nodes (presumably). Should there be guidelines here? Example: if an application on my MPL-forwarder node joins multicast group FF05::1234, will the application then receive IP multicasts sent with destination FF05::1234, or will it only receive those IP multicasts to FF05::1234 that were delivered encapsulated in an FF0X::MPL packet ? That decision could be out of scope; but on the other hand may lead to different implementers making different choices here. -- -----------------------------+--------------------------------------------- Reporter: mcr@… | Owner: draft-ietf-roll-trickle-mcast@… Type: enhancement | Status: new Priority: major | Milestone: Component: trickle-mcast | Version: Severity: In WG Last Call | Keywords: -----------------------------+--------------------------------------------- Ticket URL: roll From stokcons@xs4all.nl Thu Nov 1 08:08:58 2012 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 307A621F8D01 for ; Thu, 1 Nov 2012 08:08:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.349 X-Spam-Level: X-Spam-Status: No, score=-0.349 tagged_above=-999 required=5 tests=[AWL=0.155, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wwpuw1dMj7wa for ; Thu, 1 Nov 2012 08:08:57 -0700 (PDT) Received: from smtp-vbr5.xs4all.nl (smtp-vbr5.xs4all.nl [194.109.24.25]) by ietfa.amsl.com (Postfix) with ESMTP id 6864C21F8C82 for ; Thu, 1 Nov 2012 08:08:57 -0700 (PDT) Received: from roundcube.xs4all.nl (roundcube10.xs4all.net [194.109.20.208]) by smtp-vbr5.xs4all.nl (8.13.8/8.13.8) with ESMTP id qA1F8N4Y072114; Thu, 1 Nov 2012 16:08:24 +0100 (CET) (envelope-from stokcons@xs4all.nl) Received: from a82-95-140-48.adsl.xs4all.nl ([82.95.140.48]) by roundcube.xs4all.nl with HTTP (HTTP/1.1 POST); Thu, 01 Nov 2012 16:08:23 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Date: Thu, 01 Nov 2012 16:08:23 +0100 From: peter van der Stok To: Michael Richardson Organization: vanderstok consultancy Mail-Reply-To: In-Reply-To: <404.1351779310@obiwan.sandelman.ca> References: <5091B2A3.1090205@exegin.com> <404.1351779310@obiwan.sandelman.ca> Message-ID: <21d5e8c9a5f4a517a8fa421497f37c8a@xs4all.nl> X-Sender: stokcons@xs4all.nl (uQ4trqOiSxb8bImanRvKN0HCNy2wCKz/) User-Agent: XS4ALL Webmail X-Virus-Scanned: by XS4ALL Virus Scanner Cc: "roll@ietf.org WG" , "Jonathan Hui \(johui\)" Subject: Re: [Roll] WG Last Call draft-ietf-roll-trickle-mcast-02 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: consultancy@vanderstok.org List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Nov 2012 15:08:58 -0000 Hi Michael, It is related to the scope of the multicast, but not in the administrative sense, but in an operational sense when wireless forwarders receive MPL messages and they should be able to filter only those messages that are targeted to the subnet of which they are part. I explained the case earlier with an example. Two border routers are connected to two 802.15.4 networks, N1 and N2. The nodes of N1 have a different unicast prefix from the nodes of N2. The nodes of N1 receive packets coming from nodes of N2 and vice versa because the groups are closely spaced. A node A1 in group N1 wants to send a multicast to a group G1 of nodes in N1. The group members of G1 share a Unicast prefix multicast address with the unicast prefix belonging to group N1 nodes. Node A1 uses this MC address when sending a message. To my current understanding, MPL passes the message without encapsulation on to all forwarders in networks N1 and N2. My hope was to limit the reception to forwarders in group N1 only. That suggests a filter at reception on the unicast prefix, when the multicast address is a unicast prefix multicast address. Michael Richardson schreef op 2012-11-01 15:15: >>>>>> "peter" == peter van der Stok writes: > peter> As long as a MPL message created on a host within the MPL > domain with the MPL > peter> option can be forwarded wihin the zone without > encapsulation, > peter> my concern about payload size is minimized.(last case of > Robert's > peter> HbHTunnelMcast-v7 cases). > > peter> Can some text be added in section 5.3 like: > > peter> When the multicast destination address in the original MPL > message is a > peter> unicast prefix multicast address and the > peter> the unicast prefix of the forwarder is not a prefix of the > unicast prefix of > peter> the MC address, the forwarder ignores the message. > > Peter, I want to capture this into a ticket somewhere, but I'm > unclear > if this relates to determining the scope of the MPL domain, or if > it's > related to another problem that I don't yet understand. From johui@cisco.com Thu Nov 1 08:28:44 2012 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9EDA21F8D88 for ; Thu, 1 Nov 2012 08:28:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.215 X-Spam-Level: X-Spam-Status: No, score=-10.215 tagged_above=-999 required=5 tests=[AWL=0.384, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZERBHX4fuaMo for ; Thu, 1 Nov 2012 08:28:44 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 046DC21F8D86 for ; Thu, 1 Nov 2012 08:28:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1166; q=dns/txt; s=iport; t=1351783724; x=1352993324; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=SgeF/4Evh+PwrQxzZyTCm4+3il6J/TBQsdxzR6LW/vo=; b=Oi/Ej3gxjRJ2bs6eWZ7SIJKu/hsq7NYcR4yt7zpaC6AkNj/8K/TTQ0MZ B2Uzhb+5me1gSpIJyliGo0L4TOsk+HYEHFWmhA4GtIKOMbum+u/Pudy1Q 11iEWUy8pC+klRFbWLkJRQRrugUNYqkSALR/ITjmLLTbXwJZwiHnpR3kF Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAB2UklCtJV2Y/2dsb2JhbABEw2uBCIIfAQEEEgFmEAIBCCIkMiUCBA4FCBqHZAucOKAwi3skhTZhA5cTjT2Ba4Jvghk X-IronPort-AV: E=Sophos;i="4.80,693,1344211200"; d="scan'208";a="137825282" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-4.cisco.com with ESMTP; 01 Nov 2012 15:28:43 +0000 Received: from xhc-rcd-x11.cisco.com (xhc-rcd-x11.cisco.com [173.37.183.85]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id qA1FShLm000880 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 1 Nov 2012 15:28:43 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.200]) by xhc-rcd-x11.cisco.com ([173.37.183.85]) with mapi id 14.02.0318.001; Thu, 1 Nov 2012 10:28:43 -0500 From: "Jonathan Hui (johui)" To: "" Thread-Topic: [roll] #105: trickle-mcast: how to determine scope of MPL domain Thread-Index: AQHNuEWTVKkUNGCnjEqLpghV1euTUw== Date: Thu, 1 Nov 2012 15:28:42 +0000 Message-ID: References: <058.e817419e990e1afb26be9aa25d5cfc21@trac.tools.ietf.org> In-Reply-To: <058.e817419e990e1afb26be9aa25d5cfc21@trac.tools.ietf.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [128.107.155.10] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19328.001 x-tm-as-result: No--21.239000-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" , "" Subject: Re: [Roll] [roll] #105: trickle-mcast: how to determine scope of MPL domain X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Nov 2012 15:28:44 -0000 If the draft indicates that the MPL domain scope is a required configuratio= n parameter, would that be sufficient? -- Jonathan Hui On Oct 31, 2012, at 7:37 AM, roll issue tracker wrote: > #105: trickle-mcast: how to determine scope of MPL domain >=20 > There's no explanation on how a node would determine what scope > corresponds > to a MPL domain. How would it do that without being given some additional > information from the edge-router/s. I think what is needed, here, is some > multicast routing information from the edge-router/s. >=20 > --=20 > -----------------------------+-------------------------------------------= -- > Reporter: mcr@=85 | Owner: draft-ietf-roll-trickle-mcas= t@=85 > Type: defect | Status: new > Priority: major | Milestone: > Component: trickle-mcast | Version: > Severity: In WG Last Call | Keywords: > -----------------------------+-------------------------------------------= -- >=20 > Ticket URL: > roll >=20 From johui@cisco.com Thu Nov 1 08:56:58 2012 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2906E21F8F22 for ; Thu, 1 Nov 2012 08:56:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.27 X-Spam-Level: X-Spam-Status: No, score=-10.27 tagged_above=-999 required=5 tests=[AWL=0.329, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z0SPmWPaLNUJ for ; Thu, 1 Nov 2012 08:56:57 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 09C0621F8F1E for ; Thu, 1 Nov 2012 08:56:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2323; q=dns/txt; s=iport; t=1351785417; x=1352995017; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=yAg8gfN7U/ntGJ+/4ZgFeRe5FadRTb0xM2iNgtDnIi4=; b=MWNyW/gHd8g7ebHSwD1NCvw9hOlXILMH2JalDxHJkANNabpj7b/kBcIF 7GfFU1OxKB9r78vdCpClZj2vbi9nKp9buThrtnCV17HAG9sIpxJOzhvgk 1GuHbgLtwxh+fFLPk6H2PM/J+cZFo6G7wFWfK3yDf9g8bMK458VHW39qo E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAJKbklCtJXG9/2dsb2JhbAA6CsNrgQiCHwEBBBIBZhACAQgiJDIlAgQOBQgah2QLnEKgMot7EBSFNmEDlxONPYFrgm+CGQ X-IronPort-AV: E=Sophos;i="4.80,693,1344211200"; d="scan'208";a="137829714" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-3.cisco.com with ESMTP; 01 Nov 2012 15:56:47 +0000 Received: from xhc-rcd-x15.cisco.com (xhc-rcd-x15.cisco.com [173.37.183.89]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id qA1Fuke9017646 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 1 Nov 2012 15:56:46 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.200]) by xhc-rcd-x15.cisco.com ([173.37.183.89]) with mapi id 14.02.0318.001; Thu, 1 Nov 2012 10:56:46 -0500 From: "Jonathan Hui (johui)" To: "" Thread-Topic: [roll] #105: trickle-mcast: how to determine scope of MPL domain Thread-Index: AQHNuEl+VKkUNGCnjEqLpghV1euTUw== Date: Thu, 1 Nov 2012 15:56:45 +0000 Message-ID: References: <058.e817419e990e1afb26be9aa25d5cfc21@trac.tools.ietf.org> In-Reply-To: <058.e817419e990e1afb26be9aa25d5cfc21@trac.tools.ietf.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [128.107.155.10] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19328.001 x-tm-as-result: No--25.507300-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="Windows-1252" Content-ID: <7870D56ED88C874698B37ADA81201EA4@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" , "" Subject: Re: [Roll] [roll] #105: trickle-mcast: how to determine scope of MPL domain X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Nov 2012 15:56:58 -0000 [attempting to move the discussion to this ticket thread] Peter has two concerns: 1) Encapsulation when the source and destination of a multicast packet are = within the same MPL domain. 2) Limiting the physical extent of an MPL domain to a connected subset of d= evices within an LLN. Restricting the MPL scope to link-local and requiring encapsulation for non= -link-local multicast does not address either of Peter's concerns. I think we can solve (2) by allowing the MPL scope to be non-link-local but= still require encapsulation. The outer IPv6 header's IPv6 Destination Add= ress then serves to identify the MPL domain, with the IPv6 Destination Addr= ess carrying the IPv6 multicast group address for the MPL domain. Of cours= e, MPL interfaces would need to be configured with the appropriate IPv6 mul= ticast group(s), but the actual configuration method can be left out-of-sco= pe for this draft. I think we can also solve (1) and (2) simultaneously if we require the IPv6= Destination Address to identify both the MPL domain and application endpoi= nts. Said differently, if the IPv6 Destination for the packet corresponds = to the IPv6 multicast group address for an MPL domain, then no encapsulatio= n is required. Thoughts? -- Jonathan Hui On Oct 31, 2012, at 7:37 AM, roll issue tracker wrote: > #105: trickle-mcast: how to determine scope of MPL domain >=20 > There's no explanation on how a node would determine what scope > corresponds > to a MPL domain. How would it do that without being given some additional > information from the edge-router/s. I think what is needed, here, is some > multicast routing information from the edge-router/s. >=20 > --=20 > -----------------------------+-------------------------------------------= -- > Reporter: mcr@=85 | Owner: draft-ietf-roll-trickle-mcas= t@=85 > Type: defect | Status: new > Priority: major | Milestone: > Component: trickle-mcast | Version: > Severity: In WG Last Call | Keywords: > -----------------------------+-------------------------------------------= -- >=20 > Ticket URL: > roll >=20 From johui@cisco.com Thu Nov 1 09:08:45 2012 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D16E621F8D01 for ; Thu, 1 Nov 2012 09:08:45 -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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fslOhF6xOCWf for ; Thu, 1 Nov 2012 09:08:45 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 241E221F8C85 for ; Thu, 1 Nov 2012 09:08:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1649; q=dns/txt; s=iport; t=1351786125; x=1352995725; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=O73WrxS7lgQ6CTofCQM3xrdxQeVPnd4od2mQHCp+69k=; b=OIHG2BwJwpgIvWNd/S7LpobGzcCLry9UbuYBXBPDO4VmilGYGdRplkAz mfU+0iRoBm1ufGeEHVD/uSbeI8Cu1PtKK2xNwuBYQ65lZP53VOyksKIn5 DUpgAaotTZk0IPP3vwwJf4lPHS0UUSnq9o+J/8FvLIrSm1xqhY5r1fbKz o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAPmdklCtJXG9/2dsb2JhbAA6CsNrgQiCHwEBBBIBZhACAQgiGQsyJQIEDgUIGodkC5xMoDKLexAUhTZhA5cTjT2Ba4Jvghk X-IronPort-AV: E=Sophos;i="4.80,693,1344211200"; d="scan'208";a="137845431" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-4.cisco.com with ESMTP; 01 Nov 2012 16:08:44 +0000 Received: from xhc-rcd-x14.cisco.com (xhc-rcd-x14.cisco.com [173.37.183.88]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id qA1G8iDn005998 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 1 Nov 2012 16:08:44 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.200]) by xhc-rcd-x14.cisco.com ([173.37.183.88]) with mapi id 14.02.0318.001; Thu, 1 Nov 2012 11:08:43 -0500 From: "Jonathan Hui (johui)" To: "" Thread-Topic: [roll] #110: trickle-mcast: do applications receive all multicast, or just MPL encapsulated ones Thread-Index: AQHNuEspMgZUiTBCAUyZhLDpCxipTQ== Date: Thu, 1 Nov 2012 16:08:42 +0000 Message-ID: References: <058.c053ae172b60ad763a419d3caf1dd7ac@trac.tools.ietf.org> In-Reply-To: <058.c053ae172b60ad763a419d3caf1dd7ac@trac.tools.ietf.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [128.107.155.10] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19328.001 x-tm-as-result: No--32.753400-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" , "" Subject: Re: [Roll] [roll] #110: trickle-mcast: do applications receive all multicast, or just MPL encapsulated ones X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Nov 2012 16:08:45 -0000 The FF0X::MPL multicast address serves to identify a group of MPL forwarder= s within an MPL domain. I think if any device sends a packet to FF0X::MPL, it should be delivered t= o and processed by all devices subscribed to that address. Thoughts from others? -- Jonathan Hui On Nov 1, 2012, at 7:47 AM, roll issue tracker wrote: > #110: trickle-mcast: do applications receive all multicast, or just MPL > encapsulated ones >=20 > There's still the case that multicasts from non-MPL nodes are received by > MPL-forwarder-nodes > (presumably). Should there be guidelines here? Example: if an application > on my MPL-forwarder node > joins multicast group FF05::1234, will the application then receive IP > multicasts sent > with destination FF05::1234, or will it only receive those IP multicasts > to FF05::1234 > that were delivered encapsulated in an FF0X::MPL packet ? >=20 > That decision could be out of scope; but on the other hand may lead to > different > implementers making different choices here. >=20 > --=20 > -----------------------------+-------------------------------------------= -- > Reporter: mcr@=85 | Owner: draft-ietf-roll-trickle-mcas= t@=85 > Type: enhancement | Status: new > Priority: major | Milestone: > Component: trickle-mcast | Version: > Severity: In WG Last Call | Keywords: > -----------------------------+-------------------------------------------= -- >=20 > Ticket URL: > roll >=20 From d.sturek@att.net Thu Nov 1 09:38:20 2012 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BBB021F8D5B for ; Thu, 1 Nov 2012 09:38:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.049 X-Spam-Level: X-Spam-Status: No, score=-1.049 tagged_above=-999 required=5 tests=[AWL=1.550, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GwbKcfkaJhAE for ; Thu, 1 Nov 2012 09:38:19 -0700 (PDT) Received: from nm15.access.bullet.mail.mud.yahoo.com (nm15.access.bullet.mail.mud.yahoo.com [66.94.237.216]) by ietfa.amsl.com (Postfix) with ESMTP id 4ACC921F8D5A for ; Thu, 1 Nov 2012 09:38:19 -0700 (PDT) Received: from [66.94.237.200] by nm15.access.bullet.mail.mud.yahoo.com with NNFMP; 01 Nov 2012 16:38:18 -0000 Received: from [98.139.221.51] by tm11.access.bullet.mail.mud.yahoo.com with NNFMP; 01 Nov 2012 16:38:18 -0000 Received: from [127.0.0.1] by smtp104.sbc.mail.bf1.yahoo.com with NNFMP; 01 Nov 2012 16:38:18 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=att.net; s=s1024; t=1351787898; bh=X6zdVZs2iGlVQ5yNLNDu9TJzYcynW1ItUNaGDuyvPM8=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:Received:User-Agent:Date:Subject:From:To:CC:Message-ID:Thread-Topic:In-Reply-To:Mime-version:Content-type:Content-transfer-encoding; b=J8QpfGxDbnWPjG62bqyMCvd+A3adzZD9CrVjkLn8HpHWsSM4ma5KFaV69RuSs8dXUl4atoCodvgOzQzUVr4c5fvlssqmScOWDwVUPD/pqNzbUkCJCynfL6/7My+ctEhwVfnzGItmg7qGQvAbQXn7KRXkgsLA3sQxsECICpbqay0= X-Yahoo-Newman-Id: 831679.74655.bm@smtp104.sbc.mail.bf1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: 9PczhGYVM1lwnFKdb2jISc279CoZN4wK.W8O_eYiHtlXFta Hxt5.FpRgcxdJ0DqjjKJCtDGAOaIJMpugppHXblqeG4yoXAyspn8sVMvsU3q yYhxU35nyJL0PlVQY9dWJjvLPWVjxm1CvVHozxJwD9kTTMKCU7lu250byCmD UgWBLdnr2zMtSpSE3NEbPjM8FhizpeBEJZfE4gsYaDdsqrjOg0F_kmXeQwRg 9YCwt6bR2NEdEyUys_yy0comwy14_jxw8gMnZ29PJFj37Vkh0uQ67yop9cOD 4rUyohMabyeU6ENUG_NM7F74r9T68h.bdLC5PaPsOKS4EEzJ1yHBOOZdw_hZ 6ULGKcggDMXhSNh9t2mCTRYEGWC8WtO9.TjJFURC8CDCZ9oLF1i3a6G6BMB2 T0R0TfEjg_URTNHzxrqk2bIg.0rKNTL3kP8LExWxNOE1.EElNqX2yGiMRu36 yEvUNsIuusHUcYtIqjg-- X-Yahoo-SMTP: fvjol_aswBAraSJvMLe2r1XTzhBhbFxY8q8c3jo- Received: from [10.1.1.135] (d.sturek@66.27.60.174 with login) by smtp104.sbc.mail.bf1.yahoo.com with SMTP; 01 Nov 2012 09:38:18 -0700 PDT User-Agent: Microsoft-MacOutlook/14.2.4.120824 Date: Thu, 01 Nov 2012 09:38:14 -0700 From: Don Sturek To: "Jonathan Hui (johui)" , "" Message-ID: Thread-Topic: [Roll] [roll] #105: trickle-mcast: how to determine scope of MPL domain In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Cc: "" , "" Subject: Re: [Roll] [roll] #105: trickle-mcast: how to determine scope of MPL domain X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Nov 2012 16:38:20 -0000 Hi Jonathan, I agree with the approach you outlined below (ie, require the IPv6 Destination Address to identify both the MPL domain and application endpoints. Said differently, if the IPv6 Destination for the packet corresponds to the IPv6 multicast group address for an MPL domain, then no encapsulation is required). Don On 11/1/12 8:56 AM, "Jonathan Hui (johui)" wrote: > >[attempting to move the discussion to this ticket thread] > >Peter has two concerns: >1) Encapsulation when the source and destination of a multicast packet >are within the same MPL domain. >2) Limiting the physical extent of an MPL domain to a connected subset of >devices within an LLN. > >Restricting the MPL scope to link-local and requiring encapsulation for >non-link-local multicast does not address either of Peter's concerns. > >I think we can solve (2) by allowing the MPL scope to be non-link-local >but still require encapsulation. The outer IPv6 header's IPv6 >Destination Address then serves to identify the MPL domain, with the IPv6 >Destination Address carrying the IPv6 multicast group address for the MPL >domain. Of course, MPL interfaces would need to be configured with the >appropriate IPv6 multicast group(s), but the actual configuration method >can be left out-of-scope for this draft. > >I think we can also solve (1) and (2) simultaneously if we require the >IPv6 Destination Address to identify both the MPL domain and application >endpoints. Said differently, if the IPv6 Destination for the packet >corresponds to the IPv6 multicast group address for an MPL domain, then >no encapsulation is required. > >Thoughts? > >-- >Jonathan Hui > >On Oct 31, 2012, at 7:37 AM, roll issue tracker > wrote: > >> #105: trickle-mcast: how to determine scope of MPL domain >>=20 >> There's no explanation on how a node would determine what scope >> corresponds >> to a MPL domain. How would it do that without being given some >>additional >> information from the edge-router/s. I think what is needed, here, is >>some >> multicast routing information from the edge-router/s. >>=20 >> --=20 >>=20 >>-----------------------------+------------------------------------------- >>-- >> Reporter: mcr@=8A | Owner: >>draft-ietf-roll-trickle-mcast@=8A >> Type: defect | Status: new >> Priority: major | Milestone: >> Component: trickle-mcast | Version: >> Severity: In WG Last Call | Keywords: >>=20 >>-----------------------------+------------------------------------------- >>-- >>=20 >> Ticket URL: >> roll >>=20 > >_______________________________________________ >Roll mailing list >Roll@ietf.org >https://www.ietf.org/mailman/listinfo/roll From robert.cragie@gridmerge.com Thu Nov 1 11:20:19 2012 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30C7721F8E7B for ; Thu, 1 Nov 2012 11:20:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RcmaQ6acHbvt for ; Thu, 1 Nov 2012 11:20:18 -0700 (PDT) Received: from mail78.extendcp.co.uk (mail78.extendcp.co.uk [79.170.40.78]) by ietfa.amsl.com (Postfix) with ESMTP id 37B2021F8E31 for ; Thu, 1 Nov 2012 11:20:18 -0700 (PDT) Received: from client-86-25-47-150.midd-bam-1.adsl.virginmedia.com ([86.25.47.150] helo=[192.168.0.2]) by mail78.extendcp.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.77) id 1TTzNH-0001dZ-BH for roll@ietf.org; Thu, 01 Nov 2012 18:20:16 +0000 Message-ID: <5092BDA4.30607@gridmerge.com> Date: Thu, 01 Nov 2012 18:21:24 +0000 From: Robert Cragie Organization: Gridmerge Ltd. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: roll@ietf.org References: <058.c053ae172b60ad763a419d3caf1dd7ac@trac.tools.ietf.org> In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms040605090600030106060709" X-Authenticated-As: robert.cragie@gridmerge.com Subject: Re: [Roll] [roll] #110: trickle-mcast: do applications receive all multicast, or just MPL encapsulated ones X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: robert.cragie@gridmerge.com List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Nov 2012 18:20:19 -0000 This is a cryptographically signed message in MIME format. --------------ms040605090600030106060709 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable We could say that address has to be subscribed to by all MPL forwarders=20 and SHOULD (MUST?) be used with a MPL Option. If the language in the=20 draft were tightened up a bit regarding packet types, this would mean=20 that if for some reason a packet to FF0X::MPL was originated without a=20 MPL Option, it would be harmlessly (but wastefully) encapsulated and the = chances are anything beyond the MPL domain would not be subscribed so=20 would be ignored for that reason. Of course, if used with a MPL Option,=20 no encapsulation is needed, there is a one-to-one mapping between the=20 MPL domain and the address scope and it would not be forwarded on=20 interfaces which don't understand MPL. Robert On 01/11/2012 4:08 PM, Jonathan Hui (johui) wrote: > The FF0X::MPL multicast address serves to identify a group of MPL forwa= rders within an MPL domain. > > I think if any device sends a packet to FF0X::MPL, it should be deliver= ed to and processed by all devices subscribed to that address. > > Thoughts from others? > > -- > Jonathan Hui > > On Nov 1, 2012, at 7:47 AM, roll issue tracker wrote: > >> #110: trickle-mcast: do applications receive all multicast, or just MP= L >> encapsulated ones >> >> There's still the case that multicasts from non-MPL nodes are received= by >> MPL-forwarder-nodes >> (presumably). Should there be guidelines here? Example: if an applicat= ion >> on my MPL-forwarder node >> joins multicast group FF05::1234, will the application then receive IP= >> multicasts sent >> with destination FF05::1234, or will it only receive those IP multicas= ts >> to FF05::1234 >> that were delivered encapsulated in an FF0X::MPL packet ? >> >> That decision could be out of scope; but on the other hand may lead to= >> different >> implementers making different choices here. >> >> --=20 >> -----------------------------+----------------------------------------= ----- >> Reporter: mcr@=85 | Owner: draft-ietf-roll-trickle-m= cast@=85 >> Type: enhancement | Status: new >> Priority: major | Milestone: >> Component: trickle-mcast | Version: >> Severity: In WG Last Call | Keywords: >> -----------------------------+----------------------------------------= ----- >> >> Ticket URL: >> roll >> > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > --------------ms040605090600030106060709 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIILUDCC BRowggQCoAMCAQICEG0Z6qcZT2ozIuYiMnqqcd4wDQYJKoZIhvcNAQEFBQAwga4xCzAJBgNV BAYTAlVTMQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoT FVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3Qu Y29tMTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQg RW1haWwwHhcNMTEwNDI4MDAwMDAwWhcNMjAwNTMwMTA0ODM4WjCBkzELMAkGA1UEBhMCR0Ix GzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UE ChMRQ09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENPTU9ETyBDbGllbnQgQXV0aGVudGlj YXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC ggEBAJKEhFtLV5jUXi+LpOFAyKNTWF9mZfEyTvefMn1V0HhMVbdClOD5J3EHxcZppLkyxPFA GpDMJ1Zifxe1cWmu5SAb5MtjXmDKokH2auGj/7jfH0htZUOMKi4rYzh337EXrMLaggLW1DJq 1GdvIBOPXDX65VSAr9hxCh03CgJQU2yVHakQFLSZlVkSMf8JotJM3FLb3uJAAVtIaN3FSrTg 7SQfOq9xXwfjrL8UO7AlcWg99A/WF1hGFYE8aIuLgw9teiFX5jSw2zJ+40rhpVJyZCaRTqWS D//gsWD9Gm9oUZljjRqLpcxCm5t9ImPTqaD8zp6Q30QZ9FxbNboW86eb/8ECAwEAAaOCAUsw ggFHMB8GA1UdIwQYMBaAFImCZ33EnSZwAEu0UEh83j2uBG59MB0GA1UdDgQWBBR6E04AdFvG eGNkJ8Ev4qBbvHnFezAOBgNVHQ8BAf8EBAMCAQYwEgYDVR0TAQH/BAgwBgEB/wIBADARBgNV HSAECjAIMAYGBFUdIAAwWAYDVR0fBFEwTzBNoEugSYZHaHR0cDovL2NybC51c2VydHJ1c3Qu Y29tL1VUTi1VU0VSRmlyc3QtQ2xpZW50QXV0aGVudGljYXRpb25hbmRFbWFpbC5jcmwwdAYI KwYBBQUHAQEEaDBmMD0GCCsGAQUFBzAChjFodHRwOi8vY3J0LnVzZXJ0cnVzdC5jb20vVVRO QWRkVHJ1c3RDbGllbnRfQ0EuY3J0MCUGCCsGAQUFBzABhhlodHRwOi8vb2NzcC51c2VydHJ1 c3QuY29tMA0GCSqGSIb3DQEBBQUAA4IBAQCF1r54V1VtM39EUv5C1QaoAQOAivsNsv1Kv/av QUn1G1rF0q0bc24+6SZ85kyYwTAo38v7QjyhJT4KddbQPTmGZtGhm7VNm2+vKGwdr+XqdFqo 2rHA8XV6L566k3nK/uKRHlZ0sviN0+BDchvtj/1gOSBH+4uvOmVIPJg9pSW/ve9g4EnlFsjr P0OD8ODuDcHTzTNfm9C9YGqzO/761Mk6PB/tm/+bSTO+Qik5g+4zaS6CnUVNqGnagBsePdIa XXxHmaWbCG0SmYbWXVcHG6cwvktJRLiQfsrReTjrtDP6oDpdJlieYVUYtCHVmdXgQ0BCML7q peeU0rD+83X5f27nMIIGLjCCBRagAwIBAgIQXDFQ28QtqMuYch5f2nTvZjANBgkqhkiG9w0B AQUFADCBkzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4G A1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENP TU9ETyBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTAeFw0xMTA5 MDIwMDAwMDBaFw0xNDA5MDEyMzU5NTlaMIIBNzELMAkGA1UEBhMCR0IxEDAOBgNVBBETB1dG NCA0V0ExFzAVBgNVBAgTDldlc3QgWW9ya3NoaXJlMRIwEAYDVQQHEwlXYWtlZmllbGQxFDAS BgNVBAkTC0dyYW5nZSBNb29yMR8wHQYDVQQJExY4OSBHcmVlbmZpZWxkIENyZXNjZW50MRcw FQYDVQQKEw5HcmlkbWVyZ2UgTHRkLjE0MDIGA1UECxMrSXNzdWVkIHRocm91Z2ggR3JpZG1l cmdlIEx0ZC4gRS1QS0kgTWFuYWdlcjEfMB0GA1UECxMWQ29ycG9yYXRlIFNlY3VyZSBFbWFp bDEWMBQGA1UEAxMNUm9iZXJ0IENyYWdpZTEqMCgGCSqGSIb3DQEJARYbcm9iZXJ0LmNyYWdp ZUBncmlkbWVyZ2UuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEArcThqvLe WU1Q1ZJmnb+2UQSwOQKWok3A1Mwk582AdvwaAQyBFliPyJ0kXJqtwNBoZvk+3WJr0QA5ZRr+ J0x3sXVpcxadojP2HNzy1gsgDtIGG8ltoU4vmX1A8BTlOIUT+Pg8p/bSruxV0vz0CR8ho2hs R0Zi5vU+rQKNmbgufbkWhlQnMEYjknemscLQfw1YZz90ta67doNDujFy6+X6I06HpjudgMYx 8bdsNS5xVFFwuBA1eqNQra+xLzhCOeX9PPB/zK68qdNhrni3WPYG9EhSt4Dzk+xIz9hj7wrU ZIVXDTPsY8qbUSBVpwmzI5lCHPgzurH1OK7WwgpDSsl5pwIDAQABo4IB1TCCAdEwHwYDVR0j BBgwFoAUehNOAHRbxnhjZCfBL+KgW7x5xXswHQYDVR0OBBYEFBCOXNH+lDm8U9gy3b3bRvrx vKgrMA4GA1UdDwEB/wQEAwIFoDAMBgNVHRMBAf8EAjAAMB0GA1UdJQQWMBQGCCsGAQUFBwME BggrBgEFBQcDAjBGBgNVHSAEPzA9MDsGDCsGAQQBsjEBAgEDBTArMCkGCCsGAQUFBwIBFh1o dHRwczovL3NlY3VyZS5jb21vZG8ubmV0L0NQUzBXBgNVHR8EUDBOMEygSqBIhkZodHRwOi8v Y3JsLmNvbW9kb2NhLmNvbS9DT01PRE9DbGllbnRBdXRoZW50aWNhdGlvbmFuZFNlY3VyZUVt YWlsQ0EuY3JsMIGIBggrBgEFBQcBAQR8MHowUgYIKwYBBQUHMAKGRmh0dHA6Ly9jcnQuY29t b2RvY2EuY29tL0NPTU9ET0NsaWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5j cnQwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmNvbW9kb2NhLmNvbTAmBgNVHREEHzAdgRty b2JlcnQuY3JhZ2llQGdyaWRtZXJnZS5jb20wDQYJKoZIhvcNAQEFBQADggEBAD6b/O0LkPav kR4Znoqxg0Ad7M3duDm4uzfrlX4ecgq56Ccdwd+3Tayz7Ewej30woVMmTKkA/NKRaCd0wVM9 8seF/oZjXKO7o1SH27igRnGSWjCoWXsdwJGfZbYnvcIIhhsxJoCPNbeSR7C0PAFDKsP3xrJy MHMljIJsoRbZu/fnYNyFWh9OXf7fYJOGmKDKAhSabUGfhY7umvU9d/YTqo02Q6YzC7d4zPNG 1a75AuHSEchf6GdKqycG38I5y9jlDaYfXspoS3PlTNCIeZONbOSMZgftnNEVKq+SWytFqyG/ 8+dwpm/a12KMex5J8iHwaUKj++2O2rAFNjDDqXpeEYoxggQZMIIEFQIBATCBqDCBkzELMAkG A1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9y ZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENPTU9ETyBDbGllbnQg QXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIQXDFQ28QtqMuYch5f2nTvZjAJ BgUrDgMCGgUAoIICRTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xMjExMDExODIxMjRaMCMGCSqGSIb3DQEJBDEWBBStLc3Zl4ZSfWqP0Zxi9UgbZlRlMjBs BgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcw DgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEo MIG5BgkrBgEEAYI3EAQxgaswgagwgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVy IE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1p dGVkMTkwNwYDVQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUg RW1haWwgQ0ECEFwxUNvELajLmHIeX9p072YwgbsGCyqGSIb3DQEJEAILMYGroIGoMIGTMQsw CQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxm b3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVu dCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhBcMVDbxC2oy5hyHl/adO9m MA0GCSqGSIb3DQEBAQUABIIBAH/tx3qfm6uuu1ZaeggaIMrbqpx2AJVuig67naZihDSqGls6 /lGn1+PdaK0aIDqcfBL1xTlIdoYqsHOtrJ4WpIVNtpnbfWTRXlG0U4vAfrBMyJ0MLYbXdaAP Ilhpwdih41Gpo+J0O+pW42A1xLNZw9tGM15z4Sjijul2WlrTesKZKB2cUORcnT+K3Gp9tuyV UVxTeLVcNVTVpwgD7CUoXU97dRTr7WZAfbZ6l4tIUDp02C8IKuah5Utsla2L5Z/g/8Yskxmh 4LrKJ9Eu8HWqCWW9tbYpevz52C5Wi/hLk22+ZAUZwX3AzK549P51R63+HHV8gvuxp29Tu0/3 DD/Nlm8AAAAAAAA= --------------ms040605090600030106060709-- From johui@cisco.com Thu Nov 1 11:51:50 2012 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E25B21F939A for ; Thu, 1 Nov 2012 11:51:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.343 X-Spam-Level: X-Spam-Status: No, score=-10.343 tagged_above=-999 required=5 tests=[AWL=0.256, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0j3zhE0UCBhi for ; Thu, 1 Nov 2012 11:51:49 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 8171F21F9136 for ; Thu, 1 Nov 2012 11:51:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3538; q=dns/txt; s=iport; t=1351795909; x=1353005509; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=9+PfJYceS1jriR31V0hJ3mm4QWFhtGHKAJYQULyR+SU=; b=XIe0rmUwqFPUukxSXzwO7BnAX1O1nyd2b/tSBIn8n9SnLDnq03t4xBoL GtJECOQarvU8eqMx4AZ1jn9YK6qP0MZm3wlFp7lDAMvY0kqaVIzsU16cX /8zcs9d3jGi9TGHEnzZJCfm7D3UV0azFO8F4jzEKziVSgcn3WZ0Ne+0DZ w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAHXDklCtJXHA/2dsb2JhbAA6CsN0gQiCHgEBAQMBAQEBDwFbCwULAgEIGAoZCycLJQIEDgUIGodeBgucSKAsi3sQFIU2YQOXE409gWuCb4FkFx4 X-IronPort-AV: E=Sophos;i="4.80,695,1344211200"; d="scan'208";a="137899433" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-3.cisco.com with ESMTP; 01 Nov 2012 18:51:48 +0000 Received: from xhc-rcd-x05.cisco.com (xhc-rcd-x05.cisco.com [173.37.183.79]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id qA1IplR0009133 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 1 Nov 2012 18:51:47 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.200]) by xhc-rcd-x05.cisco.com ([173.37.183.79]) with mapi id 14.02.0318.001; Thu, 1 Nov 2012 13:51:46 -0500 From: "Jonathan Hui (johui)" To: "" Thread-Topic: [Roll] [roll] #110: trickle-mcast: do applications receive all multicast, or just MPL encapsulated ones Thread-Index: AQHNuEspMgZUiTBCAUyZhLDpCxipTQ== Date: Thu, 1 Nov 2012 18:51:46 +0000 Message-ID: References: <058.c053ae172b60ad763a419d3caf1dd7ac@trac.tools.ietf.org> <5092BDA4.30607@gridmerge.com> In-Reply-To: <5092BDA4.30607@gridmerge.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [128.107.155.10] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19328.001 x-tm-as-result: No--35.567900-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="Windows-1252" Content-ID: <33CF6AFD733CA6458890454C40C6E2BD@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" Subject: Re: [Roll] [roll] #110: trickle-mcast: do applications receive all multicast, or just MPL encapsulated ones X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Nov 2012 18:51:50 -0000 HI Robert, I'm not sure I follow you. If we require MPL forwarders to drop packets se= nt to FF0X::MPL and do not contain an MPL Option, how do we expect one to e= ncapsulate it for forwarding within the MPL domain? I suggested in another email that encapsulation be required unless the IPv6= Destination Address be equal to FF0X::MPL. If it is anything else, then e= ncapsulation is required. Also, since Peter would like to use unicast prefix-based multicast addresse= s, there is a one-to-one mapping between the MPL domain and the (address sc= ope, group identifier) tuple. -- Jonathan Hui On Nov 1, 2012, at 11:21 AM, Robert Cragie wr= ote: > We could say that address has to be subscribed to by all MPL forwarders a= nd SHOULD (MUST?) be used with a MPL Option. If the language in the draft w= ere tightened up a bit regarding packet types, this would mean that if for = some reason a packet to FF0X::MPL was originated without a MPL Option, it w= ould be harmlessly (but wastefully) encapsulated and the chances are anythi= ng beyond the MPL domain would not be subscribed so would be ignored for th= at reason. Of course, if used with a MPL Option, no encapsulation is needed= , there is a one-to-one mapping between the MPL domain and the address scop= e and it would not be forwarded on interfaces which don't understand MPL. >=20 > Robert >=20 >=20 > On 01/11/2012 4:08 PM, Jonathan Hui (johui) wrote: >> The FF0X::MPL multicast address serves to identify a group of MPL forwar= ders within an MPL domain. >>=20 >> I think if any device sends a packet to FF0X::MPL, it should be delivere= d to and processed by all devices subscribed to that address. >>=20 >> Thoughts from others? >>=20 >> -- >> Jonathan Hui >>=20 >> On Nov 1, 2012, at 7:47 AM, roll issue tracker wrote: >>=20 >>> #110: trickle-mcast: do applications receive all multicast, or just MPL >>> encapsulated ones >>>=20 >>> There's still the case that multicasts from non-MPL nodes are received = by >>> MPL-forwarder-nodes >>> (presumably). Should there be guidelines here? Example: if an applicati= on >>> on my MPL-forwarder node >>> joins multicast group FF05::1234, will the application then receive IP >>> multicasts sent >>> with destination FF05::1234, or will it only receive those IP multicast= s >>> to FF05::1234 >>> that were delivered encapsulated in an FF0X::MPL packet ? >>>=20 >>> That decision could be out of scope; but on the other hand may lead to >>> different >>> implementers making different choices here. >>>=20 >>> --=20 >>> -----------------------------+-----------------------------------------= ---- >>> Reporter: mcr@=85 | Owner: draft-ietf-roll-trickle-mc= ast@=85 >>> Type: enhancement | Status: new >>> Priority: major | Milestone: >>> Component: trickle-mcast | Version: >>> Severity: In WG Last Call | Keywords: >>> -----------------------------+-----------------------------------------= ---- >>>=20 >>> Ticket URL: >>> roll >>>=20 >> _______________________________________________ >> Roll mailing list >> Roll@ietf.org >> https://www.ietf.org/mailman/listinfo/roll >>=20 >=20 >=20 > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From johui@cisco.com Thu Nov 1 11:54:50 2012 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 155BF21F8D12 for ; Thu, 1 Nov 2012 11:54:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.369 X-Spam-Level: X-Spam-Status: No, score=-10.369 tagged_above=-999 required=5 tests=[AWL=0.231, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MbztLL1bskNG for ; Thu, 1 Nov 2012 11:54:49 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id F0D5721F8D10 for ; Thu, 1 Nov 2012 11:54:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1037; q=dns/txt; s=iport; t=1351796089; x=1353005689; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=IBjG2lX2G8tcE+1cOEoBLSSt+6EzeEATH22A+rz2UV0=; b=l79kHAxoAuA3dvayG1Xry+dI6k/jc+F/hyzH2ankcXabEwJplHk/GnaU 9TIckhBI4y8vdUVcpR+d88zu6LFgcKmad/ffwpPMOL10tutp4sJBbtK12 iOW+YeV3+4Ndmjxtskcxfa3DguHHqmTFXyio8ysCmm6nWb00kiCt5CWm/ s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAKDEklCtJXHB/2dsb2JhbABEw3SBCIIeAQEBAwESASc/BQsCAQgiCwkQMiUCBA4FCBqHXgacVaAsi3uDC4JPYQOkUIFrgm+CGQ X-IronPort-AV: E=Sophos;i="4.80,695,1344211200"; d="scan'208";a="137862640" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-7.cisco.com with ESMTP; 01 Nov 2012 18:54:48 +0000 Received: from xhc-aln-x13.cisco.com (xhc-aln-x13.cisco.com [173.36.12.87]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id qA1Ismj1011015 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 1 Nov 2012 18:54:48 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.200]) by xhc-aln-x13.cisco.com ([173.36.12.87]) with mapi id 14.02.0318.001; Thu, 1 Nov 2012 13:54:48 -0500 From: "Jonathan Hui (johui)" To: Michael Richardson Thread-Topic: [roll] #105: trickle-mcast: how to determine scope of MPL domain Thread-Index: AQHNuEl+VKkUNGCnjEqLpghV1euTUw== Date: Thu, 1 Nov 2012 18:54:47 +0000 Message-ID: References: <058.e817419e990e1afb26be9aa25d5cfc21@trac.tools.ietf.org> <767.1351789816@obiwan.sandelman.ca> In-Reply-To: <767.1351789816@obiwan.sandelman.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [128.107.155.10] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19328.001 x-tm-as-result: No--27.391000-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "roll@ietf.org" , "draft-ietf-roll-trickle-mcast@tools.ietf.org" Subject: Re: [Roll] [roll] #105: trickle-mcast: how to determine scope of MPL domain X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Nov 2012 18:54:50 -0000 On Nov 1, 2012, at 10:10 AM, Michael Richardson wro= te: > Is there a reason to encapsulate other than the Path MTU discovery issue? > I think it has to do with getting the packet to the seed, but I'm > unclear on this. The other reason to encapsulate is for clean removal of the MPL Option. Re= moving the MPL Option would be fairly straightforward if that were the only= IPv6 Option contained in an IPv6 Hop-by-Hop Option header. But things get= a bit hairy when other IPv6 Options exist. > Am I understranding correctly: if the packet originates in the LLN from > an MPL aware node, then encapsulation is not necessary: the originator > knows about the Hop-by-Hop option, and takes that into account for Path > MTU calculations. >=20 > Is this Peter's concern? Peter's primary concern is to eliminate any header overhead caused by encap= sulation. But you are correct that a MPL-aware node can take the MPL Optio= n into account in Path MTU calculations. -- Jonathan Hui From dat@exegin.com Thu Nov 1 17:59:23 2012 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4802121F98A1 for ; Thu, 1 Nov 2012 17:59:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.565 X-Spam-Level: X-Spam-Status: No, score=-2.565 tagged_above=-999 required=5 tests=[AWL=1.034, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SIAZbNFqDXlm for ; Thu, 1 Nov 2012 17:59:22 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id CD6B221F98A5 for ; Thu, 1 Nov 2012 17:59:21 -0700 (PDT) Received: by mail-pb0-f44.google.com with SMTP id ro8so2096384pbb.31 for ; Thu, 01 Nov 2012 17:59:21 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding :x-gm-message-state; bh=eZu/XvzO5F+WnRrAnp/U8ybuBhU7eIHSyc0hnjdJRm8=; b=h7Pg6JhC7j5DkJnST77rZfpRYn1y+QExsJmJ4h5AMEFjD7RZ3IIZBnqDnXUWSpveGJ FlYzZ84dqaVfBkCF1qCL6NRVDruYbyHid/NRXkFHyq356Sio9M7Wun6JYMpIQfkJE9Tx ECjpijzsqiMo5Z6/n67eIOB3bqOB9BnZen662mpQ1OCMvUguJKXELY6ba7n9etCOFRzM bNFbVbUh3p6GkbI0whRX/OylXYo1cuAKDrevqBDinMijAdKkqTk9IzWo4675Rpp4qadI hkmmP0c65UvAGZONnEjW2Sp0Gw2Kv46XhTHWS6Wl37kLk5XzKCxxajN1nMtRnz1D26VC sWDg== Received: by 10.66.83.201 with SMTP id s9mr328940pay.74.1351817961440; Thu, 01 Nov 2012 17:59:21 -0700 (PDT) Received: from [172.16.1.52] ([184.71.143.130]) by mx.google.com with ESMTPS id j10sm4778030pax.8.2012.11.01.17.59.19 (version=SSLv3 cipher=OTHER); Thu, 01 Nov 2012 17:59:20 -0700 (PDT) Message-ID: <50931AE9.9030800@exegin.com> Date: Thu, 01 Nov 2012 17:59:21 -0700 From: Dario Tedeschi User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:7.0) Gecko/20110922 Thunderbird/7.0 MIME-Version: 1.0 To: "Jonathan Hui (johui)" References: <058.e817419e990e1afb26be9aa25d5cfc21@trac.tools.ietf.org> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Gm-Message-State: ALoCoQnAXoP68QPp/nx1hQFb6t4CLaBg6cxEqwiKYpvaCJdnZPGpE4wUhdvArAVV2Idp0OjNsMdu Cc: "" , "" , "" Subject: Re: [Roll] [roll] #105: trickle-mcast: how to determine scope of MPL domain X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Nov 2012 00:59:23 -0000 I'm not so sure. What if, for example, I connected my BR to an existing network that already had say scope 4 (admin-scope) configured to cover a wider domain than just the PAN. I then could not configure the BR to report 4 as the scope of the PAN (the "MPL scope"). Yes, one could use scope 3, but it is currently reserved. Besides, it wouldn't really solve the problem, if you consider that scope 3 could quite easily also cover a wider domain than just the PAN. This is where unicast-prefix-based multicast addressing would become useful. It would remove the need for an "MPL scope", since the MPL domain would be defined by the PAN's prefix. - Dario On 01/11/2012 8:28 AM, Jonathan Hui (johui) wrote: > If the draft indicates that the MPL domain scope is a required configuration parameter, would that be sufficient? > > -- > Jonathan Hui > > On Oct 31, 2012, at 7:37 AM, roll issue tracker wrote: > >> #105: trickle-mcast: how to determine scope of MPL domain >> >> There's no explanation on how a node would determine what scope >> corresponds >> to a MPL domain. How would it do that without being given some additional >> information from the edge-router/s. I think what is needed, here, is some >> multicast routing information from the edge-router/s. >> >> -- >> -----------------------------+--------------------------------------------- >> Reporter: mcr@… | Owner: draft-ietf-roll-trickle-mcast@… >> Type: defect | Status: new >> Priority: major | Milestone: >> Component: trickle-mcast | Version: >> Severity: In WG Last Call | Keywords: >> -----------------------------+--------------------------------------------- >> >> Ticket URL: >> roll >> > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From robert.cragie@gridmerge.com Thu Nov 1 18:03:41 2012 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A541721F9756 for ; Thu, 1 Nov 2012 18:03:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DjGG1gl1eR-p for ; Thu, 1 Nov 2012 18:03:41 -0700 (PDT) Received: from mail78.extendcp.co.uk (mail78.extendcp.co.uk [79.170.40.78]) by ietfa.amsl.com (Postfix) with ESMTP id B904C21F92E0 for ; Thu, 1 Nov 2012 18:03:34 -0700 (PDT) Received: from client-86-25-47-150.midd-bam-1.adsl.virginmedia.com ([86.25.47.150] helo=[192.168.0.2]) by mail78.extendcp.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.77) id 1TU5fY-0004Ew-8d; Fri, 02 Nov 2012 01:03:32 +0000 Message-ID: <50931C2B.4040800@gridmerge.com> Date: Fri, 02 Nov 2012 01:04:43 +0000 From: Robert Cragie Organization: Gridmerge Ltd. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: "Jonathan Hui (johui)" References: <058.c053ae172b60ad763a419d3caf1dd7ac@trac.tools.ietf.org> <5092BDA4.30607@gridmerge.com> In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms090709040106020106010909" X-Authenticated-As: robert.cragie@gridmerge.com Cc: "" Subject: Re: [Roll] [roll] #110: trickle-mcast: do applications receive all multicast, or just MPL encapsulated ones X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: robert.cragie@gridmerge.com List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Nov 2012 01:03:41 -0000 This is a cryptographically signed message in MIME format. --------------ms090709040106020106010909 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable Hi Jonathan, Comments inline. Robert On 01/11/2012 6:51 PM, Jonathan Hui (johui) wrote: > HI Robert, > > I'm not sure I follow you. If we require MPL forwarders to drop packet= s sent to FF0X::MPL and do not contain an MPL Option, how do we expect on= e to encapsulate it for forwarding within the MPL domain? I wasn't suggesting that. If you look at the definitions I=20 suggested, any original non-MPL multicast packet is always encapsulated, = not dropped, irrespective of its destination address (unless link local, = which is never likely to happen). > > I suggested in another email that encapsulation be required unless the = IPv6 Destination Address be equal to FF0X::MPL. If it is anything else, = then encapsulation is required. I was saying that the FF0X::MPL address should also have an=20 accompanying MPL option otherwise if a MPL forwarder encountered an=20 original non-MPL multicast packet with destination address FF0X::MPL, it = would (probably) end up encapsulating it. > > Also, since Peter would like to use unicast prefix-based multicast addr= esses, there is a one-to-one mapping between the MPL domain and the (addr= ess scope, group identifier) tuple. That seems to make sense but I would like to see some more details=20 on that proposal > > -- > Jonathan Hui > > On Nov 1, 2012, at 11:21 AM, Robert Cragie wrote: > >> We could say that address has to be subscribed to by all MPL forwarder= s and SHOULD (MUST?) be used with a MPL Option. If the language in the dr= aft were tightened up a bit regarding packet types, this would mean that = if for some reason a packet to FF0X::MPL was originated without a MPL Opt= ion, it would be harmlessly (but wastefully) encapsulated and the chances= are anything beyond the MPL domain would not be subscribed so would be i= gnored for that reason. Of course, if used with a MPL Option, no encapsul= ation is needed, there is a one-to-one mapping between the MPL domain and= the address scope and it would not be forwarded on interfaces which don'= t understand MPL. >> >> Robert >> >> >> On 01/11/2012 4:08 PM, Jonathan Hui (johui) wrote: >>> The FF0X::MPL multicast address serves to identify a group of MPL for= warders within an MPL domain. >>> >>> I think if any device sends a packet to FF0X::MPL, it should be deliv= ered to and processed by all devices subscribed to that address. >>> >>> Thoughts from others? >>> >>> -- >>> Jonathan Hui >>> >>> On Nov 1, 2012, at 7:47 AM, roll issue tracker wrote: >>> >>>> #110: trickle-mcast: do applications receive all multicast, or just = MPL >>>> encapsulated ones >>>> >>>> There's still the case that multicasts from non-MPL nodes are receiv= ed by >>>> MPL-forwarder-nodes >>>> (presumably). Should there be guidelines here? Example: if an applic= ation >>>> on my MPL-forwarder node >>>> joins multicast group FF05::1234, will the application then receive = IP >>>> multicasts sent >>>> with destination FF05::1234, or will it only receive those IP multic= asts >>>> to FF05::1234 >>>> that were delivered encapsulated in an FF0X::MPL packet ? >>>> >>>> That decision could be out of scope; but on the other hand may lead = to >>>> different >>>> implementers making different choices here. >>>> >>>> --=20 >>>> -----------------------------+--------------------------------------= ------- >>>> Reporter: mcr@=85 | Owner: draft-ietf-roll-trickle= -mcast@=85 >>>> Type: enhancement | Status: new >>>> Priority: major | Milestone: >>>> Component: trickle-mcast | Version: >>>> Severity: In WG Last Call | Keywords: >>>> -----------------------------+--------------------------------------= ------- >>>> >>>> Ticket URL: >>>> roll >>>> >>> _______________________________________________ >>> Roll mailing list >>> Roll@ietf.org >>> https://www.ietf.org/mailman/listinfo/roll >>> >> >> _______________________________________________ >> Roll mailing list >> Roll@ietf.org >> https://www.ietf.org/mailman/listinfo/roll > --------------ms090709040106020106010909 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIILUDCC BRowggQCoAMCAQICEG0Z6qcZT2ozIuYiMnqqcd4wDQYJKoZIhvcNAQEFBQAwga4xCzAJBgNV BAYTAlVTMQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoT FVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3Qu Y29tMTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQg RW1haWwwHhcNMTEwNDI4MDAwMDAwWhcNMjAwNTMwMTA0ODM4WjCBkzELMAkGA1UEBhMCR0Ix GzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UE ChMRQ09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENPTU9ETyBDbGllbnQgQXV0aGVudGlj YXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC ggEBAJKEhFtLV5jUXi+LpOFAyKNTWF9mZfEyTvefMn1V0HhMVbdClOD5J3EHxcZppLkyxPFA GpDMJ1Zifxe1cWmu5SAb5MtjXmDKokH2auGj/7jfH0htZUOMKi4rYzh337EXrMLaggLW1DJq 1GdvIBOPXDX65VSAr9hxCh03CgJQU2yVHakQFLSZlVkSMf8JotJM3FLb3uJAAVtIaN3FSrTg 7SQfOq9xXwfjrL8UO7AlcWg99A/WF1hGFYE8aIuLgw9teiFX5jSw2zJ+40rhpVJyZCaRTqWS D//gsWD9Gm9oUZljjRqLpcxCm5t9ImPTqaD8zp6Q30QZ9FxbNboW86eb/8ECAwEAAaOCAUsw ggFHMB8GA1UdIwQYMBaAFImCZ33EnSZwAEu0UEh83j2uBG59MB0GA1UdDgQWBBR6E04AdFvG eGNkJ8Ev4qBbvHnFezAOBgNVHQ8BAf8EBAMCAQYwEgYDVR0TAQH/BAgwBgEB/wIBADARBgNV HSAECjAIMAYGBFUdIAAwWAYDVR0fBFEwTzBNoEugSYZHaHR0cDovL2NybC51c2VydHJ1c3Qu Y29tL1VUTi1VU0VSRmlyc3QtQ2xpZW50QXV0aGVudGljYXRpb25hbmRFbWFpbC5jcmwwdAYI KwYBBQUHAQEEaDBmMD0GCCsGAQUFBzAChjFodHRwOi8vY3J0LnVzZXJ0cnVzdC5jb20vVVRO QWRkVHJ1c3RDbGllbnRfQ0EuY3J0MCUGCCsGAQUFBzABhhlodHRwOi8vb2NzcC51c2VydHJ1 c3QuY29tMA0GCSqGSIb3DQEBBQUAA4IBAQCF1r54V1VtM39EUv5C1QaoAQOAivsNsv1Kv/av QUn1G1rF0q0bc24+6SZ85kyYwTAo38v7QjyhJT4KddbQPTmGZtGhm7VNm2+vKGwdr+XqdFqo 2rHA8XV6L566k3nK/uKRHlZ0sviN0+BDchvtj/1gOSBH+4uvOmVIPJg9pSW/ve9g4EnlFsjr P0OD8ODuDcHTzTNfm9C9YGqzO/761Mk6PB/tm/+bSTO+Qik5g+4zaS6CnUVNqGnagBsePdIa XXxHmaWbCG0SmYbWXVcHG6cwvktJRLiQfsrReTjrtDP6oDpdJlieYVUYtCHVmdXgQ0BCML7q peeU0rD+83X5f27nMIIGLjCCBRagAwIBAgIQXDFQ28QtqMuYch5f2nTvZjANBgkqhkiG9w0B AQUFADCBkzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4G A1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENP TU9ETyBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTAeFw0xMTA5 MDIwMDAwMDBaFw0xNDA5MDEyMzU5NTlaMIIBNzELMAkGA1UEBhMCR0IxEDAOBgNVBBETB1dG NCA0V0ExFzAVBgNVBAgTDldlc3QgWW9ya3NoaXJlMRIwEAYDVQQHEwlXYWtlZmllbGQxFDAS BgNVBAkTC0dyYW5nZSBNb29yMR8wHQYDVQQJExY4OSBHcmVlbmZpZWxkIENyZXNjZW50MRcw FQYDVQQKEw5HcmlkbWVyZ2UgTHRkLjE0MDIGA1UECxMrSXNzdWVkIHRocm91Z2ggR3JpZG1l cmdlIEx0ZC4gRS1QS0kgTWFuYWdlcjEfMB0GA1UECxMWQ29ycG9yYXRlIFNlY3VyZSBFbWFp bDEWMBQGA1UEAxMNUm9iZXJ0IENyYWdpZTEqMCgGCSqGSIb3DQEJARYbcm9iZXJ0LmNyYWdp ZUBncmlkbWVyZ2UuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEArcThqvLe WU1Q1ZJmnb+2UQSwOQKWok3A1Mwk582AdvwaAQyBFliPyJ0kXJqtwNBoZvk+3WJr0QA5ZRr+ J0x3sXVpcxadojP2HNzy1gsgDtIGG8ltoU4vmX1A8BTlOIUT+Pg8p/bSruxV0vz0CR8ho2hs R0Zi5vU+rQKNmbgufbkWhlQnMEYjknemscLQfw1YZz90ta67doNDujFy6+X6I06HpjudgMYx 8bdsNS5xVFFwuBA1eqNQra+xLzhCOeX9PPB/zK68qdNhrni3WPYG9EhSt4Dzk+xIz9hj7wrU ZIVXDTPsY8qbUSBVpwmzI5lCHPgzurH1OK7WwgpDSsl5pwIDAQABo4IB1TCCAdEwHwYDVR0j BBgwFoAUehNOAHRbxnhjZCfBL+KgW7x5xXswHQYDVR0OBBYEFBCOXNH+lDm8U9gy3b3bRvrx vKgrMA4GA1UdDwEB/wQEAwIFoDAMBgNVHRMBAf8EAjAAMB0GA1UdJQQWMBQGCCsGAQUFBwME BggrBgEFBQcDAjBGBgNVHSAEPzA9MDsGDCsGAQQBsjEBAgEDBTArMCkGCCsGAQUFBwIBFh1o dHRwczovL3NlY3VyZS5jb21vZG8ubmV0L0NQUzBXBgNVHR8EUDBOMEygSqBIhkZodHRwOi8v Y3JsLmNvbW9kb2NhLmNvbS9DT01PRE9DbGllbnRBdXRoZW50aWNhdGlvbmFuZFNlY3VyZUVt YWlsQ0EuY3JsMIGIBggrBgEFBQcBAQR8MHowUgYIKwYBBQUHMAKGRmh0dHA6Ly9jcnQuY29t b2RvY2EuY29tL0NPTU9ET0NsaWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5j cnQwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmNvbW9kb2NhLmNvbTAmBgNVHREEHzAdgRty b2JlcnQuY3JhZ2llQGdyaWRtZXJnZS5jb20wDQYJKoZIhvcNAQEFBQADggEBAD6b/O0LkPav kR4Znoqxg0Ad7M3duDm4uzfrlX4ecgq56Ccdwd+3Tayz7Ewej30woVMmTKkA/NKRaCd0wVM9 8seF/oZjXKO7o1SH27igRnGSWjCoWXsdwJGfZbYnvcIIhhsxJoCPNbeSR7C0PAFDKsP3xrJy MHMljIJsoRbZu/fnYNyFWh9OXf7fYJOGmKDKAhSabUGfhY7umvU9d/YTqo02Q6YzC7d4zPNG 1a75AuHSEchf6GdKqycG38I5y9jlDaYfXspoS3PlTNCIeZONbOSMZgftnNEVKq+SWytFqyG/ 8+dwpm/a12KMex5J8iHwaUKj++2O2rAFNjDDqXpeEYoxggQZMIIEFQIBATCBqDCBkzELMAkG A1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9y ZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENPTU9ETyBDbGllbnQg QXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIQXDFQ28QtqMuYch5f2nTvZjAJ BgUrDgMCGgUAoIICRTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xMjExMDIwMTA0NDNaMCMGCSqGSIb3DQEJBDEWBBSetHUylrkkeJ07T/D2YexD1H9IZzBs BgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcw DgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEo MIG5BgkrBgEEAYI3EAQxgaswgagwgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVy IE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1p dGVkMTkwNwYDVQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUg RW1haWwgQ0ECEFwxUNvELajLmHIeX9p072YwgbsGCyqGSIb3DQEJEAILMYGroIGoMIGTMQsw CQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxm b3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVu dCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhBcMVDbxC2oy5hyHl/adO9m MA0GCSqGSIb3DQEBAQUABIIBAKMlL5SIHZerc83kh+cNccQrepJC/K2IJWTbLu6ptKshOLpZ bIkeMkYXvDUIuSgerIJv752MLwQqvhO5fqSzRdMdBqFMErtpEkfgVgLj0MXq6i50JKfFqAWD JCtLKa6h2aFanbbcAVvGWU8YeLCKTYFBLXziiyWXjKtwMWzRcxZ4jn6wcYkCzSc7/5pT+HB1 naIS271xw4trRKC5Wx/oGCC5ZbPwr4G2ubO4v93G+hD92dLz+U6+HB1Kbv12pBwL0Ilw4jPU mOv2j2VdWwAcIzJfsHd4gqCivMMIDd74o0BmPqrbqdfMPszXgP4SX7EIcwTnkslwi6DevqQe QwlldXsAAAAAAAA= --------------ms090709040106020106010909-- From johui@cisco.com Thu Nov 1 18:13:26 2012 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6CB921F89F5 for ; Thu, 1 Nov 2012 18:13:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fV9V0wYFA206 for ; Thu, 1 Nov 2012 18:13:24 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id C64BB21F89A8 for ; Thu, 1 Nov 2012 18:13:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3274; q=dns/txt; s=iport; t=1351818804; x=1353028404; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=Q96wuvcujGxmIlwEr1UMpcLaY5ks6rh7qUV90eay7Y8=; b=HorVgPak0PD0mV7biYFIZs5tWwm/qqMFDKnaP3APuHe9V3g891IRsPst vKYJExNi0shxjQFI0N37piqRSEGpvUg2P9CxGr/4rpGyRolqNUJ3vVp3d 71FNzuseC434SndGmkddVbBvE+r36xEcz0IXCq/7wKiA/HE2Bpx5KBVt4 U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAIwdk1CtJXHB/2dsb2JhbABEwzKBCIIeAQEBAwEBAQEPAVsLBQsCAQgOCgoCIicLJQIEDgUIGodeBgucfqAei3skhTZhA5cTjT2Ba4JvgWQXHg X-IronPort-AV: E=Sophos;i="4.80,696,1344211200"; d="scan'208";a="137961407" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-8.cisco.com with ESMTP; 02 Nov 2012 01:13:24 +0000 Received: from xhc-rcd-x13.cisco.com (xhc-rcd-x13.cisco.com [173.37.183.87]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id qA21DOUj019683 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 2 Nov 2012 01:13:24 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.200]) by xhc-rcd-x13.cisco.com ([173.37.183.87]) with mapi id 14.02.0318.001; Thu, 1 Nov 2012 20:13:24 -0500 From: "Jonathan Hui (johui)" To: Dario Tedeschi Thread-Topic: [Roll] [roll] #105: trickle-mcast: how to determine scope of MPL domain Thread-Index: AQHNuEWTVKkUNGCnjEqLpghV1euTUw== Date: Fri, 2 Nov 2012 01:13:23 +0000 Message-ID: References: <058.e817419e990e1afb26be9aa25d5cfc21@trac.tools.ietf.org> <50931AE9.9030800@exegin.com> In-Reply-To: <50931AE9.9030800@exegin.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.84.164] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19328.001 x-tm-as-result: No--38.895900-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="Windows-1252" Content-ID: <4083C02167F3E34CB7A9727279887564@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "roll@ietf.org WG" , "draft-ietf-roll-trickle-mcast@tools.ietf.org" , "mcr@sandelman.ca" Subject: Re: [Roll] [roll] #105: trickle-mcast: how to determine scope of MPL domain X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Nov 2012 01:13:26 -0000 Hi Dario, Unicast-prefix-based multicast addresses also contain a scope identifier. = So while the prefix does bound the scope, the scope of a prefix can contain= multiple scopes. In any case, I don't think I properly articulated what I had in mind in my = email below. It seems that we are converging on a definition where an MPL = domain is defined by the IPv6 multicast address that interfaces subscribe t= o. In other words, an IPv6 multicast address identifies an MPL domain. Al= l MPL multicast packets containing an MPL Option must have the IPv6 Destina= tion Address set to the MPL domain that they are being transported in. If = an MPL forwarder wants to forward a multicast packet within an MPL domain a= nd that multicast packet does not have an IPv6 Destination Address correspo= nding to the domain's IPv6 multicast address, then the forwarder MUST encap= sulate it. So now it becomes a simple address match rather whether an IPv6= address is within the scope zone. Does that solve the issue? -- Jonathan Hui On Nov 1, 2012, at 5:59 PM, Dario Tedeschi wrote: > I'm not so sure. What if, for example, I connected my BR to an existing n= etwork that already had say scope 4 (admin-scope) configured to cover a wid= er domain than just the PAN. I then could not configure the BR to report 4 = as the scope of the PAN (the "MPL scope"). Yes, one could use scope 3, but = it is currently reserved. Besides, it wouldn't really solve the problem, if= you consider that scope 3 could quite easily also cover a wider domain tha= n just the PAN. >=20 > This is where unicast-prefix-based multicast addressing would become usef= ul. It would remove the need for an "MPL scope", since the MPL domain would= be defined by the PAN's prefix. >=20 > - Dario >=20 >=20 > On 01/11/2012 8:28 AM, Jonathan Hui (johui) wrote: >> If the draft indicates that the MPL domain scope is a required configura= tion parameter, would that be sufficient? >>=20 >> -- >> Jonathan Hui >>=20 >> On Oct 31, 2012, at 7:37 AM, roll issue tracker wrote: >>=20 >>> #105: trickle-mcast: how to determine scope of MPL domain >>>=20 >>> There's no explanation on how a node would determine what scope >>> corresponds >>> to a MPL domain. How would it do that without being given some addition= al >>> information from the edge-router/s. I think what is needed, here, is so= me >>> multicast routing information from the edge-router/s. >>>=20 >>> --=20 >>> -----------------------------+-----------------------------------------= ---- >>> Reporter: mcr@=85 | Owner: draft-ietf-roll-trickle-mc= ast@=85 >>> Type: defect | Status: new >>> Priority: major | Milestone: >>> Component: trickle-mcast | Version: >>> Severity: In WG Last Call | Keywords: >>> -----------------------------+-----------------------------------------= ---- >>>=20 >>> Ticket URL: >>> roll >>>=20 >> _______________________________________________ >> Roll mailing list >> Roll@ietf.org >> https://www.ietf.org/mailman/listinfo/roll >=20 From dat@exegin.com Thu Nov 1 18:47:59 2012 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4824E21F868F for ; Thu, 1 Nov 2012 18:47:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.824 X-Spam-Level: X-Spam-Status: No, score=-2.824 tagged_above=-999 required=5 tests=[AWL=0.775, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qHSmjtZU-t2J for ; Thu, 1 Nov 2012 18:47:58 -0700 (PDT) Received: from mail-pa0-f44.google.com (mail-pa0-f44.google.com [209.85.220.44]) by ietfa.amsl.com (Postfix) with ESMTP id EFB9421F8857 for ; Thu, 1 Nov 2012 18:47:51 -0700 (PDT) Received: by mail-pa0-f44.google.com with SMTP id fb11so2117462pad.31 for ; Thu, 01 Nov 2012 18:47:51 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding :x-gm-message-state; bh=pZFyvJgVurFoHs9g0ty6I/YZzxpprlnZfrxFXcqgiKY=; b=Uoc8FM7B3RY9okfeDPyJR+I0h9m4wENBGA/5SgzaNGPyceMuEYSRDAz2INj8kZPWYl Y4RvF0PTrBGayV9qQDVJARK5KivBvd6FF4AoCuAyA4MsFuSLWaz2SKw+n8bhHTNHPxi1 GQq5SfKRX2Kza2IqV6sZGcs/eqZ3oZEiAWFd9nlL8soFH6Jcmzfe8gopUOVnaEbCP7LI cgbYPLRpVIU1YnGg0ex9MfNlbUl9oVFDo71Z9oIkCJ8cLG3cNJ8MuRMc7gx3twzDCI8m 0Hwf51+QnpKqx1+/ynjPKSa8TKlDSXzULhICC+ATadhj+NIuShQXX4uOyxhtP1mgBW7k 4bkQ== Received: by 10.68.115.75 with SMTP id jm11mr1514543pbb.28.1351820871799; Thu, 01 Nov 2012 18:47:51 -0700 (PDT) Received: from [172.16.1.52] ([184.71.143.130]) by mx.google.com with ESMTPS id e9sm4833832paz.28.2012.11.01.18.47.49 (version=SSLv3 cipher=OTHER); Thu, 01 Nov 2012 18:47:50 -0700 (PDT) Message-ID: <50932647.3050509@exegin.com> Date: Thu, 01 Nov 2012 18:47:51 -0700 From: Dario Tedeschi User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:7.0) Gecko/20110922 Thunderbird/7.0 MIME-Version: 1.0 To: "Jonathan Hui (johui)" References: <058.e817419e990e1afb26be9aa25d5cfc21@trac.tools.ietf.org> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Gm-Message-State: ALoCoQl7WgiDBHfoYXaE0K9aTLPHeSf/BckiJ0HSFe/OyP69snsNNrk/uw+gigRlaGULSauyzofQ Cc: "" , "" , "" Subject: Re: [Roll] [roll] #105: trickle-mcast: how to determine scope of MPL domain X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Nov 2012 01:47:59 -0000 I don't understand what benefit is gained by allowing the use of non-link-local in the outer header, if encapsulation is required. Supporting both link-local and higher in the outer header just servers to complicate the forwarder. Is item 2 a requirement that a subset of devices in the LLN participate in MPL forwarding and others don't, or is it that there are two MPL domains, or is it that one subset of devices are listening on multicast address A while others are listening on multicast address B? In any case, I don't see how the use of link-local scope in the *outer* header would not work. As for encapsulation, using an MPL multicast address of the from FF02::00XX, in the outer header, would only add three bytes to the packet after 6lowpan compression. - Dario On 01/11/2012 8:56 AM, Jonathan Hui (johui) wrote: > [attempting to move the discussion to this ticket thread] > > Peter has two concerns: > 1) Encapsulation when the source and destination of a multicast packet are within the same MPL domain. > 2) Limiting the physical extent of an MPL domain to a connected subset of devices within an LLN. > > Restricting the MPL scope to link-local and requiring encapsulation for non-link-local multicast does not address either of Peter's concerns. > > I think we can solve (2) by allowing the MPL scope to be non-link-local but still require encapsulation. The outer IPv6 header's IPv6 Destination Address then serves to identify the MPL domain, with the IPv6 Destination Address carrying the IPv6 multicast group address for the MPL domain. Of course, MPL interfaces would need to be configured with the appropriate IPv6 multicast group(s), but the actual configuration method can be left out-of-scope for this draft. > > I think we can also solve (1) and (2) simultaneously if we require the IPv6 Destination Address to identify both the MPL domain and application endpoints. Said differently, if the IPv6 Destination for the packet corresponds to the IPv6 multicast group address for an MPL domain, then no encapsulation is required. > > Thoughts? > > -- > Jonathan Hui > > On Oct 31, 2012, at 7:37 AM, roll issue tracker wrote: > >> #105: trickle-mcast: how to determine scope of MPL domain >> >> There's no explanation on how a node would determine what scope >> corresponds >> to a MPL domain. How would it do that without being given some additional >> information from the edge-router/s. I think what is needed, here, is some >> multicast routing information from the edge-router/s. >> >> -- >> -----------------------------+--------------------------------------------- >> Reporter: mcr@… | Owner: draft-ietf-roll-trickle-mcast@… >> Type: defect | Status: new >> Priority: major | Milestone: >> Component: trickle-mcast | Version: >> Severity: In WG Last Call | Keywords: >> -----------------------------+--------------------------------------------- >> >> Ticket URL: >> roll >> > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From johui@cisco.com Thu Nov 1 19:13:12 2012 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CCBF221F8AD8 for ; Thu, 1 Nov 2012 19:13:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6azoK7qT6oJ2 for ; Thu, 1 Nov 2012 19:13:12 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id DE47421F897D for ; Thu, 1 Nov 2012 19:13:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1426; q=dns/txt; s=iport; t=1351822391; x=1353031991; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=avr1Z4OISxPA3zlGTR5rFs1K1zLQhdvtiKKmi4NtGrE=; b=eaW9qfhBe5KYiIatqoe1MmtIz8+EUJ+lBFo8HZdIEJHj5iN/ajN3UFcU KrKG8Jgv0w90sd3fpQdLRmCTJuQvwuZiAYWj5T8RdDJRyhRzUxAZ/r/Ae Ozz1BcC0BV8/p6mtnUlgB4Mowu3kU76rEwTEaUoJufZqs8SI8CII8QhCt A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EALIrk1CtJXG9/2dsb2JhbABEwzCBCIIeAQEBAwESAVkNBQsCAQgOFCQyJQIEDgUIGodeBpx9oBeLexWFRWEDpFCBa4JvgVwfHg X-IronPort-AV: E=Sophos;i="4.80,696,1344211200"; d="scan'208";a="137755404" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-1.cisco.com with ESMTP; 02 Nov 2012 02:12:59 +0000 Received: from xhc-aln-x04.cisco.com (xhc-aln-x04.cisco.com [173.36.12.78]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id qA22CxOA025206 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 2 Nov 2012 02:12:59 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.200]) by xhc-aln-x04.cisco.com ([173.36.12.78]) with mapi id 14.02.0318.001; Thu, 1 Nov 2012 21:12:58 -0500 From: "Jonathan Hui (johui)" To: Dario Tedeschi Thread-Topic: [Roll] [roll] #105: trickle-mcast: how to determine scope of MPL domain Thread-Index: AQHNuEl+VKkUNGCnjEqLpghV1euTUw== Date: Fri, 2 Nov 2012 02:12:57 +0000 Message-ID: References: <058.e817419e990e1afb26be9aa25d5cfc21@trac.tools.ietf.org> <50932647.3050509@exegin.com> In-Reply-To: <50932647.3050509@exegin.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.71.11] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19328.001 x-tm-as-result: No--29.606100-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" , "" , "" , "Jonathan Hui \(johui\)" Subject: Re: [Roll] [roll] #105: trickle-mcast: how to determine scope of MPL domain X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Nov 2012 02:13:12 -0000 On Nov 1, 2012, at 6:47 PM, Dario Tedeschi wrote: > I don't understand what benefit is gained by allowing the use of non-link= -local in the outer header, if encapsulation is required. Supporting both l= ink-local and higher in the outer header just servers to complicate the for= warder. The purpose is to limit the extent to which MPL disseminates a packet to so= mething smaller than the entire LLN (item 2). > Is item 2 a requirement that a subset of devices in the LLN participate i= n MPL forwarding and others don't, or is it that there are two MPL domains,= or is it that one subset of devices are listening on multicast address A w= hile others are listening on multicast address B? In any case, I don't see = how the use of link-local scope in the *outer* header would not work. As mentioned above, the purpose is to limit the physical extent of MPL forw= arders that disseminate a message. If we use a link-local destination addr= ess in the outer header, how do you propose to limit the region? > As for encapsulation, using an MPL multicast address of the from FF02::00= XX, in the outer header, would only add three bytes to the packet after 6lo= wpan compression. I agree. Maybe you could describe a concrete example of how using link-local address= es in the outer header would address Peter's scenario that he posted to the= list? -- Jonathan Hui From johui@cisco.com Thu Nov 1 20:18:28 2012 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04DE321F86A5 for ; Thu, 1 Nov 2012 20:18:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wrYbLls-I6S8 for ; Thu, 1 Nov 2012 20:18:27 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 18D9221F86A3 for ; Thu, 1 Nov 2012 20:18:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2227; q=dns/txt; s=iport; t=1351826307; x=1353035907; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=6Q2RaN8ve7ju0HfLTkUfCbbs6IZjJbsF4M0EWWGeXWo=; b=lcz1lgUuhXU0e9ARwTcHLeDvkNE+JdV7jxirfUlWRoX9YEcPR7VDe9W3 phriNTjUY+PEUJ8J8YXD0twJvwBVBXug65nubqSfgLRc8VKriBrCiVUjj UzVi37N/h0tAIIb7HeDz4lDpQDo+ozU0LADaTAFqGWEaAQCVfZ+c93Zt0 g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAHA6k1CtJXG9/2dsb2JhbABEwzKBCIIeAQEBAwESAWYFCwIBCBgKGQsyJQIEDgUIGodeBp0BoBWLe4VaYQOkUIFrgm+BZBce X-IronPort-AV: E=Sophos;i="4.80,696,1344211200"; d="scan'208";a="137986396" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-6.cisco.com with ESMTP; 02 Nov 2012 03:18:26 +0000 Received: from xhc-aln-x15.cisco.com (xhc-aln-x15.cisco.com [173.36.12.89]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id qA23IQ55027609 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 2 Nov 2012 03:18:26 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.200]) by xhc-aln-x15.cisco.com ([173.36.12.89]) with mapi id 14.02.0318.001; Thu, 1 Nov 2012 22:18:26 -0500 From: "Jonathan Hui (johui)" To: "" Thread-Topic: [Roll] [roll] #110: trickle-mcast: do applications receive all multicast, or just MPL encapsulated ones Thread-Index: AQHNuEspMgZUiTBCAUyZhLDpCxipTQ== Date: Fri, 2 Nov 2012 03:18:25 +0000 Message-ID: References: <058.c053ae172b60ad763a419d3caf1dd7ac@trac.tools.ietf.org> <5092BDA4.30607@gridmerge.com> <50931C2B.4040800@gridmerge.com> In-Reply-To: <50931C2B.4040800@gridmerge.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.71.11] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19328.001 x-tm-as-result: No--33.713900-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="Windows-1252" Content-ID: <2EE2AE99BE6C6A4EB6948C00E6A52A3A@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "roll@ietf.org WG" Subject: Re: [Roll] [roll] #110: trickle-mcast: do applications receive all multicast, or just MPL encapsulated ones X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Nov 2012 03:18:28 -0000 Hi Robert, On Nov 1, 2012, at 6:04 PM, Robert Cragie wro= te: > On 01/11/2012 6:51 PM, Jonathan Hui (johui) wrote: >>=20 >> I'm not sure I follow you. If we require MPL forwarders to drop packets= sent to FF0X::MPL and do not contain an MPL Option, how do we expect one t= o encapsulate it for forwarding within the MPL domain? > I wasn't suggesting that. If you look at the definitions I suggested= , any original non-MPL multicast packet is always encapsulated, not dropped= , irrespective of its destination address (unless link local, which is neve= r likely to happen). Ah, OK. I believe we are in agreement. That is consistent with what I mea= nt in my original statement: "if any device sends a packet to FF0X::MPL, it= should be delivered to and processed by all devices subscribed to that add= ress." And to further clarify my statement, the delivery occurs with encap= sulation if the source did not include an MPL Option. >> I suggested in another email that encapsulation be required unless the I= Pv6 Destination Address be equal to FF0X::MPL. If it is anything else, the= n encapsulation is required. > I was saying that the FF0X::MPL address should also have an accompan= ying MPL option otherwise if a MPL forwarder encountered an original non-MP= L multicast packet with destination address FF0X::MPL, it would (probably) = end up encapsulating it. In agreement here as well. >> Also, since Peter would like to use unicast prefix-based multicast addre= sses, there is a one-to-one mapping between the MPL domain and the (address= scope, group identifier) tuple. > That seems to make sense but I would like to see some more details o= n that proposal How about defining an MPL domain in this manner: 1) MPL multicast address: An IPv6 multicast address of arbitrary scope used= by MPL forwarders to communicate with other MPL forwarders in the same sco= pe zone of the IPv6 multicast address. 2) MPL domain: A connected set of interfaces subscribed to the same MPL mul= ticast address within the scope zone of that IPv6 multicast address. Comments/suggestions? -- Jonathan Hui From qiuying@i2r.a-star.edu.sg Thu Nov 1 22:39:11 2012 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC60F21F943A; Thu, 1 Nov 2012 22:39: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=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YlHKKvXkzPOJ; Thu, 1 Nov 2012 22:39:10 -0700 (PDT) Received: from gw1.scei.a-star.edu.sg (gw1.scei.a-star.edu.sg [192.122.140.10]) by ietfa.amsl.com (Postfix) with ESMTP id 4D4D721F947B; Thu, 1 Nov 2012 22:39:08 -0700 (PDT) Received: from S3-CAS05.shared-svc.local ([10.217.253.201]) by gw1.scei.a-star.edu.sg (8.14.4/8.14.4) with ESMTP id qA25d3Bc001568; Fri, 2 Nov 2012 13:39:03 +0800 Received: from Win7PC (10.217.253.130) by S3-CAS05.shared-svc.local (10.217.253.201) with Microsoft SMTP Server id 14.1.339.1; Fri, 2 Nov 2012 13:39:02 +0800 From: QIU Ying To: "'Rene Struik'" References: <02a001cdb5ee$e34164d0$a9c42e70$@a-star.edu.sg> <508ECA68.4030402@gmail.com> <036901cdb788$a481d5e0$ed8581a0$@a-star.edu.sg> <5092753D.1040700@gmail.com> In-Reply-To: <5092753D.1040700@gmail.com> Date: Fri, 2 Nov 2012 13:44:50 +0800 Message-ID: <003a01cdb8bd$3b5d1c60$b2175520$@a-star.edu.sg> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac24MqIJUFfwGcaFRPm7g4FzUBBTYgAh6r9g Content-Language: en-sg X-Originating-IP: [10.217.253.130] X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.7.7855, 1.0.431, 0.0.0000 definitions=2012-11-02_01:2012-11-01, 2012-11-02, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=0 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=6.0.2-1203120001 definitions=main-1211010391 Cc: roll@ietf.org, 6lowpan@ietf.org Subject: Re: [Roll] [6lowpan] New Version Notification for draft-qiu-roll-kemp: Do need an alternative security design ? X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Nov 2012 05:39:11 -0000 Hi, Rene The idea of smart setting to tone down the revocation is very interesting. As we know, the vocation issue is a big challenge in security. It is appreciated that you could describe a bit more in detail. Regards and Thanks Qiu Ying > -----Original Message----- > From: Rene Struik [mailto:rstruik.ext@gmail.com] > Sent: Thursday, November 01, 2012 9:12 PM > To: QIU Ying > Cc: roll@ietf.org; 6lowpan@ietf.org > Subject: Re: [6lowpan] New Version Notification for draft-qiu-roll-kemp: > Do need an alternative security design ? > > Hi Qiu: > > Thanks for your note. One quick note re key revocation: key lifecycle > issues are independent of the "color" of the key (i.e., whether the key > is symmetric-key or public-key). Interestingly enough, usually this > issue is conveniently forgotten when symmetric keys come along, while > inflated when the word public key is mentioned. In practice, the main > reason for revocation would usually be an authorization change and not > so much a key compromise setting. If so, revocation can be toned down > in smart object setting, since devices can be expected not to change > affiliation that often. On the other hand, devices are less well > protected, so key compromise may happen (if one does not implement key > security and implementation security with care). > > I put a marker in my calendar to revisit your draft in detail. > Meanwhile, have a good discussion at the IETF meeting next week. > > Best regards, Rene > > On 10/31/2012 12:56 PM, QIU Ying wrote: > > Hi, Rene > > > > Thanks for your comments. > > > > The discussion of using public keys in MIP6 WG was much more than the > > description in RFC 4225, e.g. the lack of global PKI, the key > > revocation, etc. These issues also restricted to accept the public > key > > schemes in MIPv6 since a mobile device are always roaming and lost > easily. > > > > Regarding the scalability, according to my understanding, for example > > IKE, a pre-configured security policy (SP), which based on the home > > address of mobile devices, is needed before IKE exchange procedure. > > The pre-configuration is lack of scalability as the visiting mobile > > devices could be from any locations or any domains. > > > > The IKE scheme is only solve the issue of authentication between the > > mobile device and the correspondent node. It cannot ensure that a > > mobile device is reachable from other nodes. > > > > "resource utilization": did you mean the limited capability of mobile > > devices? I cannot remember if there are a lot of words on the > > capability in the MIPv6 specification. I thought it is not practice > to > > involve the revocation checking in a mobile device. Anyway, the > > capability issue is much more sensitive in LLNs than in mobile > networks. > > > > Your observation is correct that "get lots of message traffic to/from > > this third party and its local neighbours" because need more hops. In > > KEMP protocol, using the base station as the trust third party is > only > > in the bootstraps phase (or at a specified interval). In the > > following update phases, the distribution mode should be employed. In > > the distribution mode, the previous neighbour router is role as the > > trust 3rd party to introduce the moving sensor to the next neighbour > > router. In this case, the total hops could reduce to 3. By the way, > in > > the public key scheme, the extra messages / communications are > required when the certifications need to update. > > > > I hope that the above explanation could be express the actual concept > > of the > > MIPv6 authors, not just on my own understanding ;) > > > > Regards > > Qiu Ying > > > > > >> -----Original Message----- > >> From: Rene Struik [mailto:rstruik.ext@gmail.com] > >> Sent: Tuesday, October 30, 2012 2:27 AM > >> To: QIU Ying > >> Cc: roll@ietf.org; 6lowpan@ietf.org > >> Subject: Re: [6lowpan] New Version Notification for draft-qiu-roll- > kemp: > >> Do need an alternative security design ? > >> > >> Hi Qiu: > >> > >> Just curious: could you elaborate a little bit on the RFC 4225, > >> Section > >> 5.2 remark below? I just would like to understand scalability, > >> resource utilization, and other issues somewhat better and may have > >> missed something here. In particular, if one uses a symmetric-key > >> scheme with online involvement of a trusted party who distributes > >> pairwise keying material, doesn't one then get lots of message > >> traffic to/from this third party and its local neighbors for each > protocol instantiation? > >> > >> On a more general note, agreed there is a need to tackle trust life > >> cycle management in a dedicated forum. Originally, I thought the > >> Smart Object Security Workshop (which we had end of March 2012, just > >> prior to the IETF meeting) would be a good forum to tackle issues, > >> but felt we missed some opportunities there to bring forward an > >> agenda of things to accomplish (in my mind, there was too much > inside > >> the box thinking in terms of "tweaks to IETF drafts"), with less > >> emphasis on what makes ubiquitous networking different from a > >> deployment use case perspective (e.g., the lighting use case example > comes to mind). > >> > >> Unfortunately, I will not be at the Atlanta meeting, though I might > >> be in Vancouver. Glad to contribute to call to action there. > >> > >> Best regards, Rene > >> > >> On 10/29/2012 12:03 PM, QIU Ying wrote: > >>> Dear all, > >>> > >>> Do need an alternative security design instead of the current > public > >> key protocols in key establishment? It's one of arguments in > previous > >> WG meeting. > >>> My answer is yes. Actually, the similar discussion had been raised > >>> in > >> mobile IPv6 WG (RFC4225). > >>> Besides the authentication, another major check is the reachability > >> checking to verify if the claimed mobile node is reachable (section > >> 4.1). RFC4225 also explains why the current Public Key > Infrastructure > >> (i.e. IKE) is not accepted in mobile IPv6 (section 5.2). > >>> Frankly, the scheme used in KEMP is not fresh new. It is in style > of > >> the popular Kerberos. Instead of sending the ticket to visiting > >> server from client directly in Kerberos, the ticket is sent to the > >> visiting server (new nearby router in KEMP) from the KDC (base > station in KEMP). > >> The benefit of this modification includes: 1) reduce the > >> communication; > >> 2) the client (mobile node in KEMP) is check if reachable from the > >> 3rd party (new nearby router); 3) revocation in time. > >>> Thank to many WG participants commenting on the draft (inclusive > >>> Rene > >> Struik, Steve Childress, Shoichi Sakane, Greg Zaverucha, Matthew > >> Campagna), the draft should be more mature and stronger. > >>> Regards > >>> Qiu Ying > >>> > >>> > >>>> -----Original Message----- > >>>> From: QIU Ying [mailto:qiuying@i2r.a-star.edu.sg] > >>>> Sent: Tuesday, October 23, 2012 11:57 AM > >>>> To: 'roll@ietf.org'; '6lowpan@ietf.org' > >>>> Subject: FW: New Version Notification for > >>>> draft-qiu-roll-kemp-02.txt > >>>> > >>>> Hi, > >>>> > >>>> The KEMP draft is updated. The messages in the draft will be > >>>> carried in KMP format proposed by IEEE802.15.9 working group so > >>>> that the > >> KEMP > >>>> protocol is compatible with IEEE802.15.9 and could be deployed in > >>>> layer 2. > >>>> > >>>> Regards > >>>> Qiu Ying > >>>> > >>>> > >>>> -----Original Message----- > >>>> > >>>> A new version of I-D, draft-qiu-roll-kemp-02.txt has been > >>>> successfully submitted by Ying Qiu and posted to the IETF > repository. > >>>> > >>>> Filename: draft-qiu-roll-kemp > >>>> Revision: 02 > >>>> Title: Lightweight Key Establishment and Management > >>>> Protocol in Dynamic Sensor Networks (KEMP) > >>>> Creation date: 2012-10-22 > >>>> WG ID: Individual Submission > >>>> Number of pages: 20 > >>>> URL: http://www.ietf.org/internet-drafts/draft-qiu- > roll- > >>>> kemp-02.txt > >>>> Status: http://datatracker.ietf.org/doc/draft-qiu-roll- > kemp > >>>> Htmlized: http://tools.ietf.org/html/draft-qiu-roll-kemp-02 > >>>> Diff: http://www.ietf.org/rfcdiff?url2=draft-qiu-roll- > >> kemp- > >>>> 02 > >>>> > >>>> Abstract: > >>>> When a sensor node roams within a very large and distributed > >>>> wireless > >>>> sensor network, which consists of numerous sensor nodes, its > >> routing > >>>> path and neighborhood keep changing. In order to provide a > high > >>>> level of security in this environment, the moving sensor node > >> needs > >>>> to be authenticated to new neighboring nodes as well as to > >> establish > >>>> a key for secure communication. The document proposes an > >> efficient > >>>> and scalable protocol to establish and update the secure key in > a > >>>> dynamic wireless sensor network environment. The protocol > >>>> guarantees > >>>> that two sensor nodes share at least one key with probability 1 > >>>> (100%) with less memory and energy cost, while not causing > >>>> considerable communication overhead. > >>>> > >>>> > >>>> > >>>> > >>>> The IETF Secretariat > >>> Institute for Infocomm Research disclaimer: "This email is > >> confidential and may be privileged. If you are not the intended > >> recipient, please delete it and notify us immediately. Please do not > >> copy or use it for any purpose, or disclose its contents to any > other > >> person. Thank you." > >>> _______________________________________________ > >>> 6lowpan mailing list > >>> 6lowpan@ietf.org > >>> https://www.ietf.org/mailman/listinfo/6lowpan > >> > >> -- > >> email: rstruik.ext@gmail.com | Skype: rstruik > >> cell: +1 (647) 867-5658 | US: +1 (415) 690-7363 > > Institute for Infocomm Research disclaimer: "This email is > confidential and may be privileged. If you are not the intended > recipient, please delete it and notify us immediately. Please do not > copy or use it for any purpose, or disclose its contents to any other > person. Thank you." > > > -- > email: rstruik.ext@gmail.com | Skype: rstruik > cell: +1 (647) 867-5658 | US: +1 (415) 690-7363 Institute for Infocomm Research disclaimer: "This email is confidential and may be privileged. If you are not the intended recipient, please delete it and notify us immediately. Please do not copy or use it for any purpose, or disclose its contents to any other person. Thank you." From rstruik.ext@gmail.com Fri Nov 2 06:32:34 2012 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39DD421F8A7F; Fri, 2 Nov 2012 06:32:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kh9PuPey9+VK; Fri, 2 Nov 2012 06:32:33 -0700 (PDT) Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by ietfa.amsl.com (Postfix) with ESMTP id A5D1A21F8921; Fri, 2 Nov 2012 06:32:32 -0700 (PDT) Received: by mail-ie0-f172.google.com with SMTP id 9so5702914iec.31 for ; Fri, 02 Nov 2012 06:32:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; bh=nWvoMy+NI/xXjFi0dkmBPvtjkDZNv9OtwWVo7hMPk+Q=; b=xq8E+6qVpCAtTmP0HV+E7eUmK/wbmWWK8EGCBvt53Cqdrn1hVBy7cZGgCVnVeqjCdw 5ca/YvM7CNU6d/tDal288A13vCpEFaDWH7E8XPby1jCrMeSssixkeYte+tVi73SsXtGx 7pHvMJYwYpCuqqslDLX1yWUamoeWbyiC7w1UkQBFCFEXpQ4mfagGIBYywbIcLJssurEg gu7SmUO04zR4VfbFg4rH06V2dRkakPU1Daurcrz65TbOzk2s1/b/sC8JuuITyYKJD5q+ PLt3RMOZGksiJIBP1qotF+jBrj3Bzy6Go10bMu1Vhj5zCnIlQwBvcNbM2onVlUqJFI1W uLNQ== Received: by 10.50.16.143 with SMTP id g15mr1714252igd.9.1351863151972; Fri, 02 Nov 2012 06:32:31 -0700 (PDT) Received: from [192.168.1.100] (CPE0013100e2c51-CM001cea35caa6.cpe.net.cable.rogers.com. [99.231.4.27]) by mx.google.com with ESMTPS id az4sm1477061igb.2.2012.11.02.06.32.30 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 02 Nov 2012 06:32:31 -0700 (PDT) Message-ID: <5093CB4B.7090904@gmail.com> Date: Fri, 02 Nov 2012 09:31:55 -0400 From: Rene Struik User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: QIU Ying References: <02a001cdb5ee$e34164d0$a9c42e70$@a-star.edu.sg> <508ECA68.4030402@gmail.com> <036901cdb788$a481d5e0$ed8581a0$@a-star.edu.sg> <5092753D.1040700@gmail.com> <003a01cdb8bd$3b5d1c60$b2175520$@a-star.edu.sg> In-Reply-To: <003a01cdb8bd$3b5d1c60$b2175520$@a-star.edu.sg> X-Enigmail-Version: 1.4.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: roll@ietf.org, 6lowpan@ietf.org Subject: Re: [Roll] [6lowpan] New Version Notification for draft-qiu-roll-kemp: Do need an alternative security design ? X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Nov 2012 13:32:34 -0000 Hi Qiu: Perhaps, I was unclear: I did not suggest a "smart setting to tone down revocation". I did suggest that certificate revocation is only necessary in two cases, viz. 1) loss of secrecy and/or authenticity of the corresponding keying material. 2) change to authorization attributes associated with keying material. Case #1 occurs when one has a compromised device (extracted keying material via probing, side channel attacks, crappy security design, etc.). With Case #2, one should think of use cases typically quoted, such as employee receiving a public key issued by organization with authorization attributes and validity period of five years, and then discovering that employee left organization prior to certificate expiration set. (In my mind, not aligning lifetime of authorization with lifetime of cert is an example of bad implementation decisions by the organization [or plain laziness] and not necessary any more.) With smart objects, I do not see those objects being reassigned continuously (a light switch usually assumes its role for its entire life), thus making reason #2 less likely as a trigger for change. Reason #1 could occur though, since objects can be expected low-cost where one cannot necessarily assume a trusted platform on board of the device (although, one could, e.g., wrap keys using a physical unclonable function and only unwrap during use). Handing out short-lived certs to devices, where assigning a new lease of life depends on some routines involving authentication and, e.g., inspection of whether the device's external casing has been damaged could then do the job. Short-lived certificates in a networked environments are perfectly feasible and per-device cost for internet of things environment should be almost zero (subsidies to support CA's lifestyle aside). One final note: once again, it is a misconception to only consider revocation issues with public keys. This topic area is independent of the type of key and applies to symmetric-key keying material as well. (In my mind, the security profession has not done such a terrific job here by mostly ignoring the topic in the symmetric-key case and coming up with umpteen schemes in the public-key setting, not much of them being practical.) I hope this helps. Best regards, Rene == In practice, the main reason for revocation would usually be an authorization change and not so much a key compromise setting. If so, revocation can be toned down in smart object setting, since devices can be expected not to change affiliation that often. On the other hand, devices are less well protected, so key compromise may happen (if one does not implement key security and implementation security with care). On 11/2/2012 1:44 AM, QIU Ying wrote: > Hi, Rene > > The idea of smart setting to tone down the revocation is very interesting. > As we know, the vocation issue is a big challenge in security. It is > appreciated that you could describe a bit more in detail. > > Regards and Thanks > Qiu Ying > > >> -----Original Message----- >> From: Rene Struik [mailto:rstruik.ext@gmail.com] >> Sent: Thursday, November 01, 2012 9:12 PM >> To: QIU Ying >> Cc: roll@ietf.org; 6lowpan@ietf.org >> Subject: Re: [6lowpan] New Version Notification for draft-qiu-roll-kemp: >> Do need an alternative security design ? >> >> Hi Qiu: >> >> Thanks for your note. One quick note re key revocation: key lifecycle >> issues are independent of the "color" of the key (i.e., whether the key >> is symmetric-key or public-key). Interestingly enough, usually this >> issue is conveniently forgotten when symmetric keys come along, while >> inflated when the word public key is mentioned. In practice, the main >> reason for revocation would usually be an authorization change and not >> so much a key compromise setting. If so, revocation can be toned down >> in smart object setting, since devices can be expected not to change >> affiliation that often. On the other hand, devices are less well >> protected, so key compromise may happen (if one does not implement key >> security and implementation security with care). >> >> I put a marker in my calendar to revisit your draft in detail. >> Meanwhile, have a good discussion at the IETF meeting next week. >> >> Best regards, Rene >> >> On 10/31/2012 12:56 PM, QIU Ying wrote: >>> Hi, Rene >>> >>> Thanks for your comments. >>> >>> The discussion of using public keys in MIP6 WG was much more than the >>> description in RFC 4225, e.g. the lack of global PKI, the key >>> revocation, etc. These issues also restricted to accept the public >> key >>> schemes in MIPv6 since a mobile device are always roaming and lost >> easily. >>> Regarding the scalability, according to my understanding, for example >>> IKE, a pre-configured security policy (SP), which based on the home >>> address of mobile devices, is needed before IKE exchange procedure. >>> The pre-configuration is lack of scalability as the visiting mobile >>> devices could be from any locations or any domains. >>> >>> The IKE scheme is only solve the issue of authentication between the >>> mobile device and the correspondent node. It cannot ensure that a >>> mobile device is reachable from other nodes. >>> >>> "resource utilization": did you mean the limited capability of mobile >>> devices? I cannot remember if there are a lot of words on the >>> capability in the MIPv6 specification. I thought it is not practice >> to >>> involve the revocation checking in a mobile device. Anyway, the >>> capability issue is much more sensitive in LLNs than in mobile >> networks. >>> Your observation is correct that "get lots of message traffic to/from >>> this third party and its local neighbours" because need more hops. In >>> KEMP protocol, using the base station as the trust third party is >> only >>> in the bootstraps phase (or at a specified interval). In the >>> following update phases, the distribution mode should be employed. In >>> the distribution mode, the previous neighbour router is role as the >>> trust 3rd party to introduce the moving sensor to the next neighbour >>> router. In this case, the total hops could reduce to 3. By the way, >> in >>> the public key scheme, the extra messages / communications are >> required when the certifications need to update. >>> I hope that the above explanation could be express the actual concept >>> of the >>> MIPv6 authors, not just on my own understanding ;) >>> >>> Regards >>> Qiu Ying >>> >>> >>>> -----Original Message----- >>>> From: Rene Struik [mailto:rstruik.ext@gmail.com] >>>> Sent: Tuesday, October 30, 2012 2:27 AM >>>> To: QIU Ying >>>> Cc: roll@ietf.org; 6lowpan@ietf.org >>>> Subject: Re: [6lowpan] New Version Notification for draft-qiu-roll- >> kemp: >>>> Do need an alternative security design ? >>>> >>>> Hi Qiu: >>>> >>>> Just curious: could you elaborate a little bit on the RFC 4225, >>>> Section >>>> 5.2 remark below? I just would like to understand scalability, >>>> resource utilization, and other issues somewhat better and may have >>>> missed something here. In particular, if one uses a symmetric-key >>>> scheme with online involvement of a trusted party who distributes >>>> pairwise keying material, doesn't one then get lots of message >>>> traffic to/from this third party and its local neighbors for each >> protocol instantiation? >>>> On a more general note, agreed there is a need to tackle trust life >>>> cycle management in a dedicated forum. Originally, I thought the >>>> Smart Object Security Workshop (which we had end of March 2012, just >>>> prior to the IETF meeting) would be a good forum to tackle issues, >>>> but felt we missed some opportunities there to bring forward an >>>> agenda of things to accomplish (in my mind, there was too much >> inside >>>> the box thinking in terms of "tweaks to IETF drafts"), with less >>>> emphasis on what makes ubiquitous networking different from a >>>> deployment use case perspective (e.g., the lighting use case example >> comes to mind). >>>> Unfortunately, I will not be at the Atlanta meeting, though I might >>>> be in Vancouver. Glad to contribute to call to action there. >>>> >>>> Best regards, Rene >>>> >>>> On 10/29/2012 12:03 PM, QIU Ying wrote: >>>>> Dear all, >>>>> >>>>> Do need an alternative security design instead of the current >> public >>>> key protocols in key establishment? It's one of arguments in >> previous >>>> WG meeting. >>>>> My answer is yes. Actually, the similar discussion had been raised >>>>> in >>>> mobile IPv6 WG (RFC4225). >>>>> Besides the authentication, another major check is the reachability >>>> checking to verify if the claimed mobile node is reachable (section >>>> 4.1). RFC4225 also explains why the current Public Key >> Infrastructure >>>> (i.e. IKE) is not accepted in mobile IPv6 (section 5.2). >>>>> Frankly, the scheme used in KEMP is not fresh new. It is in style >> of >>>> the popular Kerberos. Instead of sending the ticket to visiting >>>> server from client directly in Kerberos, the ticket is sent to the >>>> visiting server (new nearby router in KEMP) from the KDC (base >> station in KEMP). >>>> The benefit of this modification includes: 1) reduce the >>>> communication; >>>> 2) the client (mobile node in KEMP) is check if reachable from the >>>> 3rd party (new nearby router); 3) revocation in time. >>>>> Thank to many WG participants commenting on the draft (inclusive >>>>> Rene >>>> Struik, Steve Childress, Shoichi Sakane, Greg Zaverucha, Matthew >>>> Campagna), the draft should be more mature and stronger. >>>>> Regards >>>>> Qiu Ying >>>>> >>>>> >>>>>> -----Original Message----- >>>>>> From: QIU Ying [mailto:qiuying@i2r.a-star.edu.sg] >>>>>> Sent: Tuesday, October 23, 2012 11:57 AM >>>>>> To: 'roll@ietf.org'; '6lowpan@ietf.org' >>>>>> Subject: FW: New Version Notification for >>>>>> draft-qiu-roll-kemp-02.txt >>>>>> >>>>>> Hi, >>>>>> >>>>>> The KEMP draft is updated. The messages in the draft will be >>>>>> carried in KMP format proposed by IEEE802.15.9 working group so >>>>>> that the >>>> KEMP >>>>>> protocol is compatible with IEEE802.15.9 and could be deployed in >>>>>> layer 2. >>>>>> >>>>>> Regards >>>>>> Qiu Ying >>>>>> >>>>>> >>>>>> -----Original Message----- >>>>>> >>>>>> A new version of I-D, draft-qiu-roll-kemp-02.txt has been >>>>>> successfully submitted by Ying Qiu and posted to the IETF >> repository. >>>>>> Filename: draft-qiu-roll-kemp >>>>>> Revision: 02 >>>>>> Title: Lightweight Key Establishment and Management >>>>>> Protocol in Dynamic Sensor Networks (KEMP) >>>>>> Creation date: 2012-10-22 >>>>>> WG ID: Individual Submission >>>>>> Number of pages: 20 >>>>>> URL: http://www.ietf.org/internet-drafts/draft-qiu- >> roll- >>>>>> kemp-02.txt >>>>>> Status: http://datatracker.ietf.org/doc/draft-qiu-roll- >> kemp >>>>>> Htmlized: http://tools.ietf.org/html/draft-qiu-roll-kemp-02 >>>>>> Diff: http://www.ietf.org/rfcdiff?url2=draft-qiu-roll- >>>> kemp- >>>>>> 02 >>>>>> >>>>>> Abstract: >>>>>> When a sensor node roams within a very large and distributed >>>>>> wireless >>>>>> sensor network, which consists of numerous sensor nodes, its >>>> routing >>>>>> path and neighborhood keep changing. In order to provide a >> high >>>>>> level of security in this environment, the moving sensor node >>>> needs >>>>>> to be authenticated to new neighboring nodes as well as to >>>> establish >>>>>> a key for secure communication. The document proposes an >>>> efficient >>>>>> and scalable protocol to establish and update the secure key in >> a >>>>>> dynamic wireless sensor network environment. The protocol >>>>>> guarantees >>>>>> that two sensor nodes share at least one key with probability 1 >>>>>> (100%) with less memory and energy cost, while not causing >>>>>> considerable communication overhead. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> The IETF Secretariat >>>>> Institute for Infocomm Research disclaimer: "This email is >>>> confidential and may be privileged. If you are not the intended >>>> recipient, please delete it and notify us immediately. Please do not >>>> copy or use it for any purpose, or disclose its contents to any >> other >>>> person. Thank you." >>>>> _______________________________________________ >>>>> 6lowpan mailing list >>>>> 6lowpan@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/6lowpan >>>> -- >>>> email: rstruik.ext@gmail.com | Skype: rstruik >>>> cell: +1 (647) 867-5658 | US: +1 (415) 690-7363 >>> Institute for Infocomm Research disclaimer: "This email is >> confidential and may be privileged. If you are not the intended >> recipient, please delete it and notify us immediately. Please do not >> copy or use it for any purpose, or disclose its contents to any other >> person. Thank you." >> >> >> -- >> email: rstruik.ext@gmail.com | Skype: rstruik >> cell: +1 (647) 867-5658 | US: +1 (415) 690-7363 > Institute for Infocomm Research disclaimer: "This email is confidential and may be privileged. If you are not the intended recipient, please delete it and notify us immediately. Please do not copy or use it for any purpose, or disclose its contents to any other person. Thank you." -- email: rstruik.ext@gmail.com | Skype: rstruik cell: +1 (647) 867-5658 | US: +1 (415) 690-7363 From dat@exegin.com Fri Nov 2 10:22:25 2012 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 655F811E80E5 for ; Fri, 2 Nov 2012 10:22:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.979 X-Spam-Level: X-Spam-Status: No, score=-2.979 tagged_above=-999 required=5 tests=[AWL=0.620, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8bMG2ULf--QY for ; Fri, 2 Nov 2012 10:22:24 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 602BF11E80C5 for ; Fri, 2 Nov 2012 10:22:23 -0700 (PDT) Received: by mail-pb0-f44.google.com with SMTP id ro8so2604819pbb.31 for ; Fri, 02 Nov 2012 10:22:22 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding :x-gm-message-state; bh=3uF2Nz+DODm+oZaSarmMUQiaJH3AU5x9ZMk118MfKLU=; b=lvASfumzVe714aJr2PafWrxk33qgKgCqVfj6FWqjjObo6YKInlercFnqonJxPeByTK qI1xPLR57x9QBbGpmSWdmSnNwhbmF+hnJCQNFjX2oc0gp/0eV9SVRqnuCeJJuOx6g4XZ ntmLmpMxryRQuJhplA8Y3lQ3FypcEyNsDywsigAbVpIRcrCQSg+ycFChNEsLobHu/i9z 2f+oXmvSz2YgQj6mMu/o7ufDA0p64WfeF59FlOnm72es+ZtcXH2QDACfRdX63v7TTk3x YtJSsMPVvl4RXERLBNLjsGJ0BZg/YYH/SMgkuYoalRVphx2GQZ+EH+8OgaBBMIscaIb4 55bw== Received: by 10.68.189.233 with SMTP id gl9mr7853804pbc.166.1351876942033; Fri, 02 Nov 2012 10:22:22 -0700 (PDT) Received: from [172.16.1.52] ([184.71.143.130]) by mx.google.com with ESMTPS id wg3sm6044457pbc.28.2012.11.02.10.22.20 (version=SSLv3 cipher=OTHER); Fri, 02 Nov 2012 10:22:20 -0700 (PDT) Message-ID: <5094014D.6070605@exegin.com> Date: Fri, 02 Nov 2012 10:22:21 -0700 From: Dario Tedeschi User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:7.0) Gecko/20110922 Thunderbird/7.0 MIME-Version: 1.0 To: "Jonathan Hui (johui)" References: <058.e817419e990e1afb26be9aa25d5cfc21@trac.tools.ietf.org> <50931AE9.9030800@exegin.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Gm-Message-State: ALoCoQknWXLMBSY5GLW7A7XkdTP483BfNTHzRQ/5U4BkLNkAqqBBDN3m4g8vEHWpxID0INhFBwrV Cc: "roll@ietf.org WG" , "draft-ietf-roll-trickle-mcast@tools.ietf.org" , "mcr@sandelman.ca" Subject: Re: [Roll] [roll] #105: trickle-mcast: how to determine scope of MPL domain X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Nov 2012 17:22:25 -0000 Ok, so an entire multicast address defines an MPL domain. Sending to a multicast address, that does not match an MPL domain's address, requires encapsulation. So if an MPL domain had been assigned an address FF05::1234 and a device sends to FF05::1235 or FF04::1234, it must encapsulate. This would work, but we've also added the need for devices in the network to be told what addresses are MPL addresses (i.e. routing information). In my example above, devices would have to be told that FF05::1234 is an MPL domain adddress. If we take this approach, I think we should also define how this information is disseminated. In one of my previous emails, I suggested adding a RIO to RPL DIO advertisements. If we also allow prefix lengths less than 128, multiple MPL addresses could be aggregated by one RIO. So instead of a simple address match, a device would use longest-prefix match, just like it would for unicast forwarding/sending. - Dario On 01/11/2012 6:13 PM, Jonathan Hui (johui) wrote: > Hi Dario, > > Unicast-prefix-based multicast addresses also contain a scope identifier. So while the prefix does bound the scope, the scope of a prefix can contain multiple scopes. > > In any case, I don't think I properly articulated what I had in mind in my email below. It seems that we are converging on a definition where an MPL domain is defined by the IPv6 multicast address that interfaces subscribe to. In other words, an IPv6 multicast address identifies an MPL domain. All MPL multicast packets containing an MPL Option must have the IPv6 Destination Address set to the MPL domain that they are being transported in. If an MPL forwarder wants to forward a multicast packet within an MPL domain and that multicast packet does not have an IPv6 Destination Address corresponding to the domain's IPv6 multicast address, then the forwarder MUST encapsulate it. So now it becomes a simple address match rather whether an IPv6 address is within the scope zone. > > Does that solve the issue? > > -- > Jonathan Hui > > On Nov 1, 2012, at 5:59 PM, Dario Tedeschi wrote: > >> I'm not so sure. What if, for example, I connected my BR to an existing network that already had say scope 4 (admin-scope) configured to cover a wider domain than just the PAN. I then could not configure the BR to report 4 as the scope of the PAN (the "MPL scope"). Yes, one could use scope 3, but it is currently reserved. Besides, it wouldn't really solve the problem, if you consider that scope 3 could quite easily also cover a wider domain than just the PAN. >> >> This is where unicast-prefix-based multicast addressing would become useful. It would remove the need for an "MPL scope", since the MPL domain would be defined by the PAN's prefix. >> >> - Dario >> >> >> On 01/11/2012 8:28 AM, Jonathan Hui (johui) wrote: >>> If the draft indicates that the MPL domain scope is a required configuration parameter, would that be sufficient? >>> >>> -- >>> Jonathan Hui >>> >>> On Oct 31, 2012, at 7:37 AM, roll issue tracker wrote: >>> >>>> #105: trickle-mcast: how to determine scope of MPL domain >>>> >>>> There's no explanation on how a node would determine what scope >>>> corresponds >>>> to a MPL domain. How would it do that without being given some additional >>>> information from the edge-router/s. I think what is needed, here, is some >>>> multicast routing information from the edge-router/s. >>>> >>>> -- >>>> -----------------------------+--------------------------------------------- >>>> Reporter: mcr@… | Owner: draft-ietf-roll-trickle-mcast@… >>>> Type: defect | Status: new >>>> Priority: major | Milestone: >>>> Component: trickle-mcast | Version: >>>> Severity: In WG Last Call | Keywords: >>>> -----------------------------+--------------------------------------------- >>>> >>>> Ticket URL: >>>> roll >>>> >>> _______________________________________________ >>> Roll mailing list >>> Roll@ietf.org >>> https://www.ietf.org/mailman/listinfo/roll From dat@exegin.com Fri Nov 2 12:34:09 2012 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8F0811E80ED for ; Fri, 2 Nov 2012 12:34:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.082 X-Spam-Level: X-Spam-Status: No, score=-3.082 tagged_above=-999 required=5 tests=[AWL=0.516, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2EHE7sOMUuV0 for ; Fri, 2 Nov 2012 12:34:09 -0700 (PDT) Received: from mail-da0-f44.google.com (mail-da0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id E314811E80D1 for ; Fri, 2 Nov 2012 12:34:08 -0700 (PDT) Received: by mail-da0-f44.google.com with SMTP id h15so1775539dan.31 for ; Fri, 02 Nov 2012 12:34:08 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:x-gm-message-state; bh=R/GgrAKFxNjjct6cmZok3bIQszBSmYIVE9lSYdw7DTw=; b=hUJ3xDv1UMmZ44L2eoDEx4Nl9OnQimxvIC937dp9QDQe+c2JgcTeONn8a8JhCZE2du r36R2euHcYCPrutlUcswvcXfwj/CgV8voTtJwm9BOLKwkViY6mcFQYf9W0LQmZ6PL3+S B2nU7eeR5uzFcgcF1yLWfLxSnBTQ8ngs49j4iopqoAixZbo82wwniwZWL6+E5HhVYmHW h5QmLs6I7Hq8YCGhCHcxDoGazAxuSTK6nQmfVdS05FczG0ThD7v8E3G/VOqCRj+gDM2Q KnDpHNVXylrd84geAWqfVrNsfzeR3myIXXoFv1sJVlFCNqniGplDNZDeUH0KmdwJe8no xRQg== Received: by 10.68.245.167 with SMTP id xp7mr9252739pbc.75.1351884848602; Fri, 02 Nov 2012 12:34:08 -0700 (PDT) Received: from [172.16.1.52] ([184.71.143.130]) by mx.google.com with ESMTPS id nd6sm6174920pbc.68.2012.11.02.12.34.06 (version=SSLv3 cipher=OTHER); Fri, 02 Nov 2012 12:34:07 -0700 (PDT) Message-ID: <5094202F.4010805@exegin.com> Date: Fri, 02 Nov 2012 12:34:07 -0700 From: Dario Tedeschi User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:7.0) Gecko/20110922 Thunderbird/7.0 MIME-Version: 1.0 To: "Jonathan Hui (johui)" References: <058.e817419e990e1afb26be9aa25d5cfc21@trac.tools.ietf.org> <50932647.3050509@exegin.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------070201070909010107040001" X-Gm-Message-State: ALoCoQkITwoMTwpNqgrKon0XYK/hlV04+K22yWydtmlEG2DUKMTL27P/yTDtIKfhtiM6MplW13Ii Cc: "" , "" , "" Subject: Re: [Roll] [roll] #105: trickle-mcast: how to determine scope of MPL domain X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Nov 2012 19:34:10 -0000 This is a multi-part message in MIME format. --------------070201070909010107040001 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit On 01/11/2012 7:12 PM, Jonathan Hui (johui) wrote: > On Nov 1, 2012, at 6:47 PM, Dario Tedeschi wrote: > >> I don't understand what benefit is gained by allowing the use of non-link-local in the outer header, if encapsulation is required. Supporting both link-local and higher in the outer header just servers to complicate the forwarder. > The purpose is to limit the extent to which MPL disseminates a packet to something smaller than the entire LLN (item 2). Isn't that what multicast groups and/or unicast-prefix-based multicasts are for? That is to say, to reach a defined set of devices. > >> Is item 2 a requirement that a subset of devices in the LLN participate in MPL forwarding and others don't, or is it that there are two MPL domains, or is it that one subset of devices are listening on multicast address A while others are listening on multicast address B? In any case, I don't see how the use of link-local scope in the *outer* header would not work. > As mentioned above, the purpose is to limit the physical extent of MPL forwarders that disseminate a message. If we use a link-local destination address in the outer header, how do you propose to limit the region? The destination in the inner header determines if the packet needs to be forwarded or not, or forwarded on a different interface. > >> As for encapsulation, using an MPL multicast address of the from FF02::00XX, in the outer header, would only add three bytes to the packet after 6lowpan compression. > I agree. > > Maybe you could describe a concrete example of how using link-local addresses in the outer header would address Peter's scenario that he posted to the list? Example: Two border routers (BR1 and BR2) each forming a network: --- Network 1 (BR1) --- Unicast prefix: FD01::/64 Unicast-prefix-based multicast address prefix: FF35:0040:FD01::/96 --- Network 2 (BR2) --- Unicast prefix: FD02::/64 Unicast-prefix-based multicast address prefix: FF35:0040:FD02::/96 1. A non-MPL aware node in network 1 wishes to send a multicast to all nodes in network 1. 2. It sends to multicast address FF35:0040:FD01::1, un-encapsulated. 3. The packet is received by a MPL router in network 2 (N2R1). 4. N2R1 finds no higher layer listening to FF35:0040:FD01::1 and, therefore, does not pass the packet up. 5. N2R1 finds no matching routing information for FF35:0040:FD01::1 and does not forward the packet. The packet is, therefore, discarded. 6. The packet is also received by a MPL router in network 1 (N1R1). 7. N1R1 finds a higher layer listening to FF35:0040:FD01::1 and passes a copy of the packet up. Note: This would depend on whether or not any higher layers were actually interested in the mc group. Also, this step is not a prerequisite for the next step to occur. 8. N1R1 finds matching routing information for FF35:0040:FD01::1, because it is a member of network FD01::/64 9. N1R1 encapsulates the packet with a MPL HbH option such that the outer and inner destination addresses appear as: [FF02::MPL][FF35:0040:FD01::1], respectively. 10. N1R1 transmits the new resulting packet. 11. The packet is received by another MPL router in network 1 (N1R2). 12. Seeing that the destination address is FF02::MPL, N1R2 decapsulates the packet (i.e. the original packet exits the tunnel). 13. N1R2 finds a higher layer listening to FF35:0040:FD01::1 and passes a copy of the inner packet up. Note: This step is not a prerequisite for the next step to occur. 14. N1R2 also finds matching routing information for FF35:0040:FD01::1, because it is a member of network FD01::/64. 15. N1R2 re-encapsulates the packet with the *original* MPL HbH option such that the outer and inner destination addresses appear as: [FF02::MPL][FF35:0040:FD01::1], respectively. 16. N1R2 transmits the resulting packet. 17. The packet is received by yet another MPL router in network 2 (N2R2). 18. Seeing that the destination address is FF02::MPL, N2R2 decapsulates the packet (i.e. the original packet exits the tunnel). 19. N2R2 finds no matching routing information or listener for FF35:0040:FD01::1 and, therefore, discards the packet. Note: I chose a non-MPL aware originator of a multicast packet, because I wanted to be more thorough. I could have chosen an example where the originator of the packet *was* a MPL aware device. In such a case, it would have encapsulated with its own MPL HbH option as if it were forwarding the packet (i.e. outer and inner destinations would have been [FF02::MPL][FF35:0040:FD01::1]). One complication of non-MPL aware devices sending non-link-local multicasts is the problem of fan-out: If such a device multicasts/broadcasts at the link-layer for IPv6 multicasts, then many MPL routers may hear the packet and try forward it with their own seeds. Although this wouldn't cause a real packet-storm, it would cause something close to it, depending on how many routers were in earshot of the originator. However, this is a general problem that has nothing to do with MPL's address scope. Secondly, notice that FF02::MPL can be viewed as a well defined address for a "tunnel exit point". It just so happens that it actually identifies multiple physical "exit points". - Dario --------------070201070909010107040001 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 7bit On 01/11/2012 7:12 PM, Jonathan Hui (johui) wrote: 
On Nov 1, 2012, at 6:47 PM, Dario Tedeschi <dat@exegin.com> wrote:


I don't understand what benefit is gained by allowing the use of non-link-local in the outer header, if encapsulation is required. Supporting both link-local and higher in the outer header just servers to complicate the forwarder.

The purpose is to limit the extent to which MPL disseminates a packet to something smaller than the entire LLN (item 2).

Isn't that what multicast groups and/or unicast-prefix-based multicasts are for? That is to say, to reach a defined set of devices.




Is item 2 a requirement that a subset of devices in the LLN participate in MPL forwarding and others don't, or is it that there are two MPL domains, or is it that one subset of devices are listening on multicast address A while others are listening on multicast address B? In any case, I don't see how the use of link-local scope in the *outer* header would not work.

As mentioned above, the purpose is to limit the physical extent of MPL forwarders that disseminate a message.  If we use a link-local destination address in the outer header, how do you propose to limit the region?

The destination in the inner header determines if the packet needs to be forwarded or not, or forwarded on a different interface. 




As for encapsulation, using an MPL multicast address of the from FF02::00XX, in the outer header, would only add three bytes to the packet after 6lowpan compression.

I agree.

Maybe you could describe a concrete example of how using link-local addresses in the outer header would address Peter's scenario that he posted to the list?

Example: Two border routers (BR1 and BR2) each forming a network:

--- Network 1 (BR1) ---
Unicast prefix: FD01::/64
Unicast-prefix-based multicast address prefix: FF35:0040:FD01::/96

--- Network 2 (BR2) ---
Unicast prefix: FD02::/64
Unicast-prefix-based multicast address prefix: FF35:0040:FD02::/96

  1. A non-MPL aware node in network 1 wishes to send a multicast to all nodes in network 1.
  2. It sends to multicast address FF35:0040:FD01::1, un-encapsulated.
  3. The packet is received by a MPL router in network 2 (N2R1).
  4. N2R1 finds no higher layer listening to FF35:0040:FD01::1 and, therefore, does not pass the packet up.
  5. N2R1 finds no matching routing information for FF35:0040:FD01::1 and does not forward the packet. The packet is, therefore, discarded.
  6. The packet is also received by a MPL router in network 1 (N1R1).
  7. N1R1 finds a higher layer listening to FF35:0040:FD01::1 and passes a copy of the packet up. Note: This would depend on whether or not any higher layers were actually interested in the mc group. Also, this step is not a prerequisite for the next step to occur.
  8. N1R1 finds matching routing information for FF35:0040:FD01::1, because it is a member of network FD01::/64
  9. N1R1 encapsulates the packet with a MPL HbH option such that the outer and inner destination addresses appear as: [FF02::MPL][FF35:0040:FD01::1], respectively.
  10. N1R1 transmits the new resulting packet.
  11. The packet is received by another MPL router in network 1 (N1R2).
  12. Seeing that the destination address is FF02::MPL, N1R2 decapsulates the packet (i.e. the original packet exits the tunnel).
  13. N1R2 finds a higher layer listening to FF35:0040:FD01::1 and passes a copy of the inner packet up. Note: This step is not a prerequisite for the next step to occur.
  14. N1R2 also finds matching routing information for FF35:0040:FD01::1, because it is a member of network FD01::/64.
  15. N1R2 re-encapsulates the packet with the *original* MPL HbH option such that the outer and inner destination addresses appear as: [FF02::MPL][FF35:0040:FD01::1], respectively.
  16. N1R2 transmits the resulting packet.
  17. The packet is received by yet another MPL router in network 2 (N2R2).
  18. Seeing that the destination address is FF02::MPL, N2R2 decapsulates the packet (i.e. the original packet exits the tunnel).
  19. N2R2 finds no matching routing information or listener for FF35:0040:FD01::1 and, therefore, discards the packet.

Note:
I chose a non-MPL aware originator of a multicast packet, because I wanted to be more thorough. I could have chosen an example where the originator of the packet *was* a MPL aware device. In such a case, it would have encapsulated with its own MPL HbH option as if it were forwarding the packet (i.e. outer and inner destinations would have been [FF02::MPL][FF35:0040:FD01::1]). One complication of non-MPL aware devices sending non-link-local multicasts is the problem of fan-out: If such a device multicasts/broadcasts at the link-layer for IPv6 multicasts, then many MPL routers may hear the packet and try forward it with their own seeds. Although this wouldn't cause a real packet-storm, it would cause something close to it, depending on how many routers were in earshot of the originator. However, this is a general problem that has nothing to do with MPL's address scope.

Secondly, notice that FF02::MPL can be viewed as a well defined address for a "tunnel exit point". It just so happens that it actually identifies multiple physical "exit points".

- Dario


--------------070201070909010107040001-- From mcr@sandelman.ca Fri Nov 2 17:54:22 2012 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1102B1F0C92 for ; Fri, 2 Nov 2012 17:54:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.222 X-Spam-Level: X-Spam-Status: No, score=-2.222 tagged_above=-999 required=5 tests=[AWL=-0.268, BAYES_00=-2.599, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GtRwI5bpwGEj for ; Fri, 2 Nov 2012 17:54:21 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by ietfa.amsl.com (Postfix) with ESMTP id 3C2F81F0C5F for ; Fri, 2 Nov 2012 17:54:21 -0700 (PDT) Received: from sandelman.ca (ip-64-134-66-63.public.wayport.net [64.134.66.63]) by relay.sandelman.ca (Postfix) with ESMTPS id 2F47781B7; Fri, 2 Nov 2012 20:46:23 -0400 (EDT) Received: from sandelman.ca (quigon.sandelman.ca [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 5AE84CA0CD; Fri, 2 Nov 2012 19:46:55 -0400 (EDT) From: Michael Richardson To: "roll@ietf.org WG" In-reply-to: <21d5e8c9a5f4a517a8fa421497f37c8a@xs4all.nl> References: <5091B2A3.1090205@exegin.com> <404.1351779310@obiwan.sandelman.ca> <21d5e8c9a5f4a517a8fa421497f37c8a@xs4all.nl> Comments: In-reply-to peter van der Stok message dated "Thu, 01 Nov 2012 16:08:23 +0100." X-Mailer: MH-E 8.3; nmh 1.3; XEmacs 21.4 (patch 22) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Fri, 02 Nov 2012 19:46:55 -0400 Message-ID: <19755.1351900015@sandelman.ca> Sender: mcr@sandelman.ca Cc: "Jonathan Hui \(johui\)" Subject: Re: [Roll] WG Last Call draft-ietf-roll-trickle-mcast-02 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Nov 2012 00:54:22 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable see inline peter van der Stok wrote: peter> It is related to the scope of the multicast, but not in the peter> administrative sense, but in an operational sense when peter> wireless forwarders receive MPL messages and they should be peter> able to filter only those messages that are targeted to the peter> subnet of which they are part. Is this about configuring multicast (hardware) filters so that the wrong nodes aren't woken up? Is the case you speak up articulated by one of Robert's diagrams? peter> I explained the case earlier with an example. Yes, I had asked a question about that too. I didn't understand how the two networks overlapped. Do they share the same 15.4 key material? Do they have the same beacons? My feeling is that you are solving a problem which exists on paper, but not in a real 15.4 network. But, I could be completely wrong. =2D-=20 Michael Richardson , Sandelman Software Works=20 IETF ROLL WG co-chair. http://datatracker.ietf.org/wg/roll/charter/ --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iQEcBAABAgAGBQJQlFtvAAoJEKD0KQ7Gj3P2b+4H/i7vItv/OaRnHQ5POYORr8xJ 204ALK/GiqTFy+g/gl9+FzWFfESr+Anr1kYcd5C5zeSAx6zxaCmMT3NeTPoloztW aU6zaHr+lud6fI0UZ58m1IFqnbvFz7C67o/Rx5q7r7/IWxAe05tNaOmOMPMJbGhi peQ4Sg0sS6Jz0UuT+/+dxhFuX3MGPgPB5VsrKfnq5WvyOATRTy4CqNxfE9SYo5Y8 f8ji/bvWT3MfL6eACOAKLsJ3ykPNRq5dF737viCsbUrIXlyUq6mG66rEzBFZa5By JR5ReGNP5RFaBfu8TFcenafsKBtCUsdXSWuI7LSWafk7zRt2xKAsV7hF4yRFyuU= =Tjvp -----END PGP SIGNATURE----- --=-=-=-- From yoshihiro.ohba@toshiba.co.jp Fri Nov 2 19:09:00 2012 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 455A21F0C9D for ; Fri, 2 Nov 2012 19:09:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.089 X-Spam-Level: X-Spam-Status: No, score=-4.089 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XELGpldEth4L for ; Fri, 2 Nov 2012 19:08:59 -0700 (PDT) Received: from imx2.toshiba.co.jp (inet-tsb5.toshiba.co.jp [202.33.96.24]) by ietfa.amsl.com (Postfix) with ESMTP id 6184F1F0C9C for ; Fri, 2 Nov 2012 19:08:59 -0700 (PDT) Received: from arc1.toshiba.co.jp ([133.199.194.235]) by imx2.toshiba.co.jp with ESMTP id qA328q6O016536; Sat, 3 Nov 2012 11:08:52 +0900 (JST) Received: (from root@localhost) by arc1.toshiba.co.jp id qA328q8g028182; Sat, 3 Nov 2012 11:08:52 +0900 (JST) Received: from unknown [133.199.192.144] by arc1.toshiba.co.jp with ESMTP id MAA28181; Sat, 3 Nov 2012 11:08:52 +0900 Received: from mx.toshiba.co.jp (localhost [127.0.0.1]) by ovp2.toshiba.co.jp with ESMTP id qA328qc6016707; Sat, 3 Nov 2012 11:08:52 +0900 (JST) Received: from tsbpoa.po.toshiba.co.jp by toshiba.co.jp id qA328q7Y010995; Sat, 3 Nov 2012 11:08:52 +0900 (JST) Received: from [133.199.16.111] by mail.po.toshiba.co.jp (Sun Java System Messaging Server 6.1 HotFix 0.05 (built Oct 21 2004)) with ESMTPSA id <0MCW00FXJ3AFYV20@mail.po.toshiba.co.jp>; Sat, 03 Nov 2012 11:08:52 +0900 (JST) Date: Sat, 03 Nov 2012 11:08:43 +0900 From: Yoshihiro Ohba In-reply-to: <5094014D.6070605@exegin.com> To: Dario Tedeschi Message-id: <50947CAB.2030809@toshiba.co.jp> MIME-version: 1.0 Content-type: text/plain; charset=windows-1252; format=flowed Content-transfer-encoding: 8BIT References: <058.e817419e990e1afb26be9aa25d5cfc21@trac.tools.ietf.org> <50931AE9.9030800@exegin.com> <5094014D.6070605@exegin.com> User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 Cc: "roll@ietf.org WG" , "draft-ietf-roll-trickle-mcast@tools.ietf.org" , "mcr@sandelman.ca" , "Jonathan Hui \(johui\)" Subject: Re: [Roll] [roll] #105: trickle-mcast: how to determine scope of MPL domain X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Nov 2012 02:09:00 -0000 I don't see much benefit of dynamically allocating an MPL domain address and advertising it via a routing protocol, as each node can be pre-configured to a member of an MPL domain. Isn't it simpler if we can register a fixed MPL domain address with IANA (for each multicast scope that uses MPL)? Yoshihiro Ohba (2012/11/03 2:22), Dario Tedeschi wrote: > Ok, so an entire multicast address defines an MPL domain. Sending to a > multicast address, that does not match an MPL domain's address, > requires encapsulation. So if an MPL domain had been assigned an > address FF05::1234 and a device sends to FF05::1235 or FF04::1234, it > must encapsulate. > > This would work, but we've also added the need for devices in the > network to be told what addresses are MPL addresses (i.e. routing > information). In my example above, devices would have to be told that > FF05::1234 is an MPL domain adddress. If we take this approach, I > think we should also define how this information is disseminated. > > In one of my previous emails, I suggested adding a RIO to RPL DIO > advertisements. If we also allow prefix lengths less than 128, > multiple MPL addresses could be aggregated by one RIO. So instead of a > simple address match, a device would use longest-prefix match, just > like it would for unicast forwarding/sending. > > - Dario > > On 01/11/2012 6:13 PM, Jonathan Hui (johui) wrote: >> Hi Dario, >> >> Unicast-prefix-based multicast addresses also contain a scope >> identifier. So while the prefix does bound the scope, the scope of a >> prefix can contain multiple scopes. >> >> In any case, I don't think I properly articulated what I had in mind >> in my email below. It seems that we are converging on a definition >> where an MPL domain is defined by the IPv6 multicast address that >> interfaces subscribe to. In other words, an IPv6 multicast address >> identifies an MPL domain. All MPL multicast packets containing an >> MPL Option must have the IPv6 Destination Address set to the MPL >> domain that they are being transported in. If an MPL forwarder wants >> to forward a multicast packet within an MPL domain and that multicast >> packet does not have an IPv6 Destination Address corresponding to the >> domain's IPv6 multicast address, then the forwarder MUST encapsulate >> it. So now it becomes a simple address match rather whether an IPv6 >> address is within the scope zone. >> >> Does that solve the issue? >> >> -- >> Jonathan Hui >> >> On Nov 1, 2012, at 5:59 PM, Dario Tedeschi wrote: >> >>> I'm not so sure. What if, for example, I connected my BR to an >>> existing network that already had say scope 4 (admin-scope) >>> configured to cover a wider domain than just the PAN. I then could >>> not configure the BR to report 4 as the scope of the PAN (the "MPL >>> scope"). Yes, one could use scope 3, but it is currently reserved. >>> Besides, it wouldn't really solve the problem, if you consider that >>> scope 3 could quite easily also cover a wider domain than just the PAN. >>> >>> This is where unicast-prefix-based multicast addressing would become >>> useful. It would remove the need for an "MPL scope", since the MPL >>> domain would be defined by the PAN's prefix. >>> >>> - Dario >>> >>> >>> On 01/11/2012 8:28 AM, Jonathan Hui (johui) wrote: >>>> If the draft indicates that the MPL domain scope is a required >>>> configuration parameter, would that be sufficient? >>>> >>>> -- >>>> Jonathan Hui >>>> >>>> On Oct 31, 2012, at 7:37 AM, roll issue >>>> tracker wrote: >>>> >>>>> #105: trickle-mcast: how to determine scope of MPL domain >>>>> >>>>> There's no explanation on how a node would determine what scope >>>>> corresponds >>>>> to a MPL domain. How would it do that without being given some >>>>> additional >>>>> information from the edge-router/s. I think what is needed, here, >>>>> is some >>>>> multicast routing information from the edge-router/s. >>>>> >>>>> -- >>>>> -----------------------------+--------------------------------------------- >>>>> >>>>> Reporter: mcr@… | Owner: >>>>> draft-ietf-roll-trickle-mcast@… >>>>> Type: defect | Status: new >>>>> Priority: major | Milestone: >>>>> Component: trickle-mcast | Version: >>>>> Severity: In WG Last Call | Keywords: >>>>> -----------------------------+--------------------------------------------- >>>>> >>>>> >>>>> Ticket URL: >>>>> roll >>>>> >>>> _______________________________________________ >>>> Roll mailing list >>>> Roll@ietf.org >>>> https://www.ietf.org/mailman/listinfo/roll > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > From johui@cisco.com Fri Nov 2 22:18:34 2012 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 92ECB21F9B59 for ; Fri, 2 Nov 2012 22:18:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n5agYxO2Dh4L for ; Fri, 2 Nov 2012 22:18:33 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 0175F21F8558 for ; Fri, 2 Nov 2012 22:18:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=17018; q=dns/txt; s=iport; t=1351919913; x=1353129513; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=jPEo4MpMOjVje8x7NwVP15pUZmYl42ZxvA9VyTb7+M4=; b=RjGjO2jkNaoRauiyF3UP+YJ7Xh7+6HFWsaos5juANi46LMI8sFwppcPj LQqw3UXx/Njb4nNRIMfoSGI+bFoZoDvwM0P9o4Hnnn3LKXnrMgwdZ3iD+ DB7ggtvsmS1SF1N0tGD1m0pXebGCaZRQn/TBkKdS4OBUAaxbl5H1B5ZOI A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAG+olFCtJXG+/2dsb2JhbAA6CsMwgQiCHwEBBBIBWQ0QAgEIDhQCGwcyFBECBA4FCBqHaJwOn3aMARAFhUZhA6RUgWuCb4FcHx4 X-IronPort-AV: E=Sophos;i="4.80,704,1344211200"; d="scan'208,217";a="138387571" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-7.cisco.com with ESMTP; 03 Nov 2012 05:18:32 +0000 Received: from xhc-rcd-x10.cisco.com (xhc-rcd-x10.cisco.com [173.37.183.84]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id qA35IW2X020896 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 3 Nov 2012 05:18:32 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.200]) by xhc-rcd-x10.cisco.com ([173.37.183.84]) with mapi id 14.02.0318.001; Sat, 3 Nov 2012 00:18:31 -0500 From: "Jonathan Hui (johui)" To: Dario Tedeschi Thread-Topic: [Roll] [roll] #105: trickle-mcast: how to determine scope of MPL domain Thread-Index: AQHNuEl+VKkUNGCnjEqLpghV1euTUw== Date: Sat, 3 Nov 2012 05:18:30 +0000 Message-ID: References: <058.e817419e990e1afb26be9aa25d5cfc21@trac.tools.ietf.org> <50932647.3050509@exegin.com> <5094202F.4010805@exegin.com> In-Reply-To: <5094202F.4010805@exegin.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.146.175] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19336.001 x-tm-as-result: No--44.486900-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: multipart/alternative; boundary="_000_B50D0F163D52B74DA572DD345D5044AF0F6F874Axmbrcdx04ciscoc_" MIME-Version: 1.0 Cc: "" , "" , "" , "Jonathan Hui \(johui\)" Subject: Re: [Roll] [roll] #105: trickle-mcast: how to determine scope of MPL domain X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Nov 2012 05:18:34 -0000 --_000_B50D0F163D52B74DA572DD345D5044AF0F6F874Axmbrcdx04ciscoc_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Dario, Thanks for the detailed example - I see our disconnect now. With your approach (require link-local in the outer header), the IPv6 multi= cast address identifies the application endpoints *and* the MPL domain. Fo= r that reason, your approach really only needs a single identifier to both = limit the flooding scope and determine the application endpoints. I can se= e how that would work (as you demonstrated) if we make the restriction that= the IPv6 multicast addresses used within an MPL domain have the same prefi= x that identifies the MPL domain itself. The trouble comes when you want t= o support the full generality that IPv6 multicast addresses used by applica= tion endpoints can be arbitrary. For example, how does MPL support an application that subscribes to a well-= known non-link-local IPv6 multicast address? I guess one approach is to sa= y that if the IPv6 multicast address is not a unicast-prefix-based multicas= t address, then it disseminates across the entire region of connected MPL f= orwarders. One minor point with your approach is that the delivery requires processing= the MPL Option of the outer header and the inner IPv6 header. That isn't = so nice from an architectural perspective, but that is what we did with RFC= 6553. In my approach (allow non-link-local in the outer header), I tried to separ= ate out the identifiers for the application endpoints and the MPL domain. = That is why I used the outer header's destination address to identify the M= PL domain and the inner header's destination address to identify the applic= ation endpoints. With this approach, it actually becomes feasible to addre= ss situations where the devices within an MPL domain subscribe to arbitrary= IPv6 multicast addresses - not just ones that are based on the unicast pre= fix. -- Jonathan Hui On Nov 2, 2012, at 12:34 PM, Dario Tedeschi > wrote: On 01/11/2012 7:12 PM, Jonathan Hui (johui) wrote: On Nov 1, 2012, at 6:47 PM, Dario Tedeschi wrote: I don't understand what benefit is gained by allowing the use of non-link-l= ocal in the outer header, if encapsulation is required. Supporting both lin= k-local and higher in the outer header just servers to complicate the forwa= rder. The purpose is to limit the extent to which MPL disseminates a packet to so= mething smaller than the entire LLN (item 2). Isn't that what multicast groups and/or unicast-prefix-based multicasts are= for? That is to say, to reach a defined set of devices. Is item 2 a requirement that a subset of devices in the LLN participate in = MPL forwarding and others don't, or is it that there are two MPL domains, o= r is it that one subset of devices are listening on multicast address A whi= le others are listening on multicast address B? In any case, I don't see ho= w the use of link-local scope in the *outer* header would not work. As mentioned above, the purpose is to limit the physical extent of MPL forw= arders that disseminate a message. If we use a link-local destination addr= ess in the outer header, how do you propose to limit the region? The destination in the inner header determines if the packet needs to be fo= rwarded or not, or forwarded on a different interface. As for encapsulation, using an MPL multicast address of the from FF02::00XX= , in the outer header, would only add three bytes to the packet after 6lowp= an compression. I agree. Maybe you could describe a concrete example of how using link-local address= es in the outer header would address Peter's scenario that he posted to the= list? Example: Two border routers (BR1 and BR2) each forming a network: --- Network 1 (BR1) --- Unicast prefix: FD01::/64 Unicast-prefix-based multicast address prefix: FF35:0040:FD01::/96 --- Network 2 (BR2) --- Unicast prefix: FD02::/64 Unicast-prefix-based multicast address prefix: FF35:0040:FD02::/96 1. A non-MPL aware node in network 1 wishes to send a multicast to all n= odes in network 1. 2. It sends to multicast address FF35:0040:FD01::1, un-encapsulated. 3. The packet is received by a MPL router in network 2 (N2R1). 4. N2R1 finds no higher layer listening to FF35:0040:FD01::1 and, theref= ore, does not pass the packet up. 5. N2R1 finds no matching routing information for FF35:0040:FD01::1 and = does not forward the packet. The packet is, therefore, discarded. 6. The packet is also received by a MPL router in network 1 (N1R1). 7. N1R1 finds a higher layer listening to FF35:0040:FD01::1 and passes a= copy of the packet up. Note: This would depend on whether or not any highe= r layers were actually interested in the mc group. Also, this step is not a= prerequisite for the next step to occur. 8. N1R1 finds matching routing information for FF35:0040:FD01::1, becaus= e it is a member of network FD01::/64 9. N1R1 encapsulates the packet with a MPL HbH option such that the oute= r and inner destination addresses appear as: [FF02::MPL][FF35:0040:FD01::1]= , respectively. 10. N1R1 transmits the new resulting packet. 11. The packet is received by another MPL router in network 1 (N1R2). 12. Seeing that the destination address is FF02::MPL, N1R2 decapsulates t= he packet (i.e. the original packet exits the tunnel). 13. N1R2 finds a higher layer listening to FF35:0040:FD01::1 and passes a= copy of the inner packet up. Note: This step is not a prerequisite for the= next step to occur. 14. N1R2 also finds matching routing information for FF35:0040:FD01::1, b= ecause it is a member of network FD01::/64. 15. N1R2 re-encapsulates the packet with the *original* MPL HbH option su= ch that the outer and inner destination addresses appear as: [FF02::MPL][FF= 35:0040:FD01::1], respectively. 16. N1R2 transmits the resulting packet. 17. The packet is received by yet another MPL router in network 2 (N2R2). 18. Seeing that the destination address is FF02::MPL, N2R2 decapsulates t= he packet (i.e. the original packet exits the tunnel). 19. N2R2 finds no matching routing information or listener for FF35:0040:= FD01::1 and, therefore, discards the packet. Note: I chose a non-MPL aware originator of a multicast packet, because I wanted = to be more thorough. I could have chosen an example where the originator of= the packet *was* a MPL aware device. In such a case, it would have encapsu= lated with its own MPL HbH option as if it were forwarding the packet (i.e.= outer and inner destinations would have been [FF02::MPL][FF35:0040:FD01::1= ]). One complication of non-MPL aware devices sending non-link-local multic= asts is the problem of fan-out: If such a device multicasts/broadcasts at t= he link-layer for IPv6 multicasts, then many MPL routers may hear the packe= t and try forward it with their own seeds. Although this wouldn't cause a r= eal packet-storm, it would cause something close to it, depending on how ma= ny routers were in earshot of the originator. However, this is a general pr= oblem that has nothing to do with MPL's address scope. Secondly, notice that FF02::MPL can be viewed as a well defined address for= a "tunnel exit point". It just so happens that it actually identifies mult= iple physical "exit points". - Dario --_000_B50D0F163D52B74DA572DD345D5044AF0F6F874Axmbrcdx04ciscoc_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable

Hi Dario,

Thanks for the detailed example - I see our disconnect now.

With your approach (require link-local in the outer header), the IPv6 = multicast address identifies the application endpoints *and* the MPL domain= .  For that reason, your approach really only needs a single identifie= r to both limit the flooding scope and determine the application endpoints.  I can see how that would work (= as you demonstrated) if we make the restriction that the IPv6 multicast add= resses used within an MPL domain have the same prefix that identifies the M= PL domain itself.  The trouble comes when you want to support the full generality that IPv6 multicast addresses= used by application endpoints can be arbitrary.

For example, how does MPL support an application that subscribes to a = well-known non-link-local IPv6 multicast address?  I guess one approac= h is to say that if the IPv6 multicast address is not a unicast-prefix-base= d multicast address, then it disseminates across the entire region of connected MPL forwarders.

One minor point with your approach is that the delivery requires proce= ssing the MPL Option of the outer header and the inner IPv6 header.  T= hat isn't so nice from an architectural perspective, but that is what we di= d with RFC 6553.

In my approach (allow non-link-local in the outer header), I tried to = separate out the identifiers for the application endpoints and the MPL doma= in.  That is why I used the outer header's destination address to iden= tify the MPL domain and the inner header's destination address to identify the application endpoints.  With this= approach, it actually becomes feasible to address situations where the dev= ices within an MPL domain subscribe to arbitrary IPv6 multicast addresses -= not just ones that are based on the unicast prefix.

--
Jonathan Hui

On Nov 2, 2012, at 12:34 PM, Dario Tedeschi <dat@exegin.com> wrote:

On 01/11/2012 7:12 PM, Jonathan H= ui (johui) wrote: 
On Nov 1, 2012, at 6:47 PM, Dario Tedeschi <dat@exegin.com>=
 wrote:


I don't understand what benefit is gained by allowing the us=
e of non-link-local in the outer header, if encapsulation is required. Supp=
orting both link-local and higher in the outer header just servers to compl=
icate the forwarder.

The purpose is to limit the extent to which MPL disseminates=
 a packet to something smaller than the entire LLN (item 2).

Isn't that what multicast groups and/or unicast-prefix-based multicasts are= for? That is to say, to reach a defined set of devices.






Is item 2 a requirement that a subset of devices in the LLN =
participate in MPL forwarding and others don't, or is it that there are two=
 MPL domains, or is it that one subset of devices are listening on multicas=
t address A while others are listening on multicast address B? In any case,=
 I don't see how the use of link-local scope in the *outer* header would no=
t work.





As mentioned above, the purpose is to limit the physical ext=
ent of MPL forwarders that disseminate a message.  If we use a link-local d=
estination address in the outer header, how do you propose to limit the reg=
ion?





The destination in the inner header determines if the packet needs to be fo=
rwarded or not, or forwarded on a different interface.













As for encapsulation, using an MPL multicast address of the =
from FF02::00XX, in the outer header, would only add three bytes to the pac=
ket after 6lowpan compression.





I agree.

Maybe you could describe a concrete example of how using link-local address=
es in the outer header would address Peter's scenario that he posted to the=
 list?






Example: Two border routers (BR1 and BR2) each forming a network:



--- Network 1 (BR1) ---

Unicast prefix: FD01::/64

Unicast-prefix-based multicast address prefix: FF35:0040:FD01::/96



--- Network 2 (BR2) ---

Unicast prefix: FD02::/64

Unicast-prefix-based multicast address prefix: FF35:0040:FD02::/96




    

  1. A non-MPL aware node in network 1 wishes to send a multicast to all nod=
es in network 1.

  2. It sends to multicast address FF35:0040:FD01::1, un-encapsulated. =

  3. The packet is received by a MPL router in network 2 (N2R1). 
    4. <=
li>N2R1 finds no higher layer listening to FF35:0040:FD01::1 and, therefore=
, does not pass the packet up.
    

  4. N2R1 finds no matching routing information for FF35:0040:FD01::1 a=
nd does not forward the packet. The packet is, therefore, discarded.

  5. The packet is also received by a MPL router in network 1 (N1R1). <=
/li>
  6. N1R1 finds a higher layer listening to FF35:0040:FD01::1 and passes=
 a copy of the packet up. Note: This would depend on whether or not any hig=
her layers were actually interested in the mc group. Also, this step is not=
 a prerequisite for the next step to
 occur. 
  7. N1R1 finds matching routing information for FF35:0040:FD01=
::1, because it is a member of network FD01::/64

  8. N1R1 encapsulates the packet with a MPL HbH option such that the o=
uter and inner destination addresses appear as: [FF02::MPL][FF35:0040:FD01:=
:1], respectively.

  9. N1R1 transmits the new resulting packet. 
  10. The packet is re=
ceived by another MPL router in network 1 (N1R2). 
  11. Seeing that the =
destination address is FF02::MPL, N1R2 decapsulates the packet (i.e. the or=
iginal packet exits the tunnel).

  12. N1R2 finds a higher layer listening to FF35:0040:FD01::1 and passe=
s a copy of the inner packet up. Note: This step is not a prerequisite for =
the next step to occur.
    

  13. N1R2 also finds matching routing information for FF35:0040:FD01::1=
, because it is a member of network FD01::/64.

  14. N1R2 re-encapsulates the packet with the *original* MPL HbH option=
 such that the outer and inner destination addresses appear as: [FF02::MPL]=
[FF35:0040:FD01::1], respectively.

  15. N1R2 transmits the resulting packet. 
  16. The packet is receiv=
ed by yet another MPL router in network 2 (N2R2). 
  17. Seeing that the =
destination address is FF02::MPL, N2R2 decapsulates the packet (i.e. the or=
iginal packet exits the tunnel).

  18. N2R2 finds no matching routing information or listener for FF35:00=
40:FD01::1 and, therefore, discards the packet.
    




Note:

I chose a non-MPL aware originator of a multicast packet, because I wanted =
to be more thorough. I could have chosen an example where the originator of=
 the packet *was* a MPL aware device. In such a case, it would have encapsu=
lated with its own MPL HbH option
 as if it were forwarding the packet (i.e. outer and inner destinations wou=
ld have been [FF02::MPL][FF35:0040:FD01::1]). One complication of non-MPL a=
ware devices sending non-link-local multicasts is the problem of fan-out: I=
f such a device multicasts/broadcasts
 at the link-layer for IPv6 multicasts, then many MPL routers may hear the =
packet and try forward it with their own seeds. Although this wouldn't caus=
e a real packet-storm, it would cause something close to it, depending on h=
ow many routers were in earshot
 of the originator. However, this is a general problem that has nothing to =
do with MPL's address scope.



Secondly, notice that FF02::MPL can be viewed as a well defined address for=
 a "tunnel exit point". It just so happens that it actually ident=
ifies multiple physical "exit points".



- Dario
















--_000_B50D0F163D52B74DA572DD345D5044AF0F6F874Axmbrcdx04ciscoc_--

From jvasseur@cisco.com  Sun Nov  4 02:26:37 2012
Return-Path: 
X-Original-To: roll@ietfa.amsl.com
Delivered-To: roll@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B24721F86A3 for ; Sun,  4 Nov 2012 02:26:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.521
X-Spam-Level: 
X-Spam-Status: No, score=-10.521 tagged_above=-999 required=5 tests=[AWL=0.077, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XNlNBcbxDMOM for ; Sun,  4 Nov 2012 02:26:36 -0800 (PST)
Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 5952B21F86CC for ; Sun,  4 Nov 2012 02:26:36 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4342; q=dns/txt; s=iport; t=1352024794; x=1353234394; h=from:to:subject:date:message-id:mime-version; bh=q2ZCV663etdW8CzfJ55uBaq6666vPTxfDA1Bvtkbawg=; b=G8mLEcRlycbg6+3ruQVKtwEBFyrIUwCYYZQGvLZDo1cymcMOOcUkRQgJ fmU7DOt/iZUph1EycBOYZD56hbE6hYxZEjppbwUK8Mf1wXOzvq8KCl0Pr N6hQmDOApPWUGwiWtLVS3dgP6U7px8rTgD19YAW2N9Zyf6sb6VxCYwCTW A=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av0EAP1BllCtJV2d/2dsb2JhbABEwzqBCIIgAQQSAXgBDB5WJwQbGodomEKBK58TjByFQGEDpFSBa4Jvghk
X-IronPort-AV: E=Sophos;i="4.80,710,1344211200";  d="scan'208,217";a="138371935"
Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-1.cisco.com with ESMTP; 04 Nov 2012 10:26:34 +0000
Received: from xhc-rcd-x08.cisco.com (xhc-rcd-x08.cisco.com [173.37.183.82]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id qA4AQZML031728 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Sun, 4 Nov 2012 10:26:35 GMT
Received: from xmb-rcd-x02.cisco.com ([169.254.4.118]) by xhc-rcd-x08.cisco.com ([173.37.183.82]) with mapi id 14.02.0318.001; Sun, 4 Nov 2012 04:26:35 -0600
From: "JP Vasseur (jvasseur)" 
To: "roll@ietf.org WG" 
Thread-Topic: Updated Agenda
Thread-Index: AQHNunbdrL4mWmhYEEK8g0ekWsttXw==
Date: Sun, 4 Nov 2012 10:26:34 +0000
Message-ID: <03B78081B371D44390ED6E7BADBB4A77220517C5@xmb-rcd-x02.cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.21.120.193]
x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19338.004
x-tm-as-result: No--21.968600-8.000000-31
x-tm-as-user-approved-sender: No
x-tm-as-user-blocked-sender: No
Content-Type: multipart/alternative; boundary="_000_03B78081B371D44390ED6E7BADBB4A77220517C5xmbrcdx02ciscoc_"
MIME-Version: 1.0
Subject: [Roll] Updated Agenda
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Routing Over Low power and Lossy networks 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 04 Nov 2012 10:26:37 -0000

--_000_03B78081B371D44390ED6E7BADBB4A77220517C5xmbrcdx02ciscoc_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Dear WG,

Authors of draft-hui-vasseur-roll-rpl-deployment posted the revision 2, whi=
ch documents another interesting deployment, thus the
5mn slot to provide you an update, considering the interest from the WG. Th=
at being said not sure what happened (apparently a
formatting issue) so the revision 2 could not be posted, so we will cancel =
the slot. Note that other large-scale RPL deployments
will be added soon, so version -03 will be ready for IETF-86.

On the other hand, looking at the activity around Trickle Multicast, we add=
ed a 10mn slot.

Here is the new agenda:

1) Agenda/admin (Chairs - 5mn) [5]

2) WG Status (Chairs - 10 mn) [15]

3) Security Framework and Applicability Statement template
(Michael - 10m) [25]
draft=3Ddraft-richardson-roll-applicability-template-00

4) RPL applicability in industrial networks
draft-phinney-roll-rpl-industrial-applicability-01
(Pascal - 10mn) [35]

5) Industrial Deterministic Routing Extension for Low-Power
and Lossy Networks (M. Wei - 10mn) [45]

6) Multicast Protocol for Low power and Lossy Networks (MPL)
draft-ietf-roll-trickle-mcast-02 (Jonathan - 10mn) [55]

7) Loop Free DODAG Local Repair (Jianlin Guo - 10mn) [65]
draft-guo-roll-loop-free-dodag-repair

8) RPL Routing Pathology In a Network With a Mix of Nodes Operating in
Storing and Non-Storing Modes (JeongGil Ko - 10 mn) [75]
draft-ko-roll-mix-network-pathology-01

Thanks.

JP.



--_000_03B78081B371D44390ED6E7BADBB4A77220517C5xmbrcdx02ciscoc_
Content-Type: text/html; charset="us-ascii"
Content-ID: <48AD6D643BB3E245842476EBF7DE125F@cisco.com>
Content-Transfer-Encoding: quoted-printable






Dear WG,






Authors of draft-hui-vasseur-roll-rpl-deployment posted the revis=
ion 2, which documents another interesting deployment, thus the 


5mn slot to provide you an update, considering the interest from =
the WG. That being said not sure what happened (apparently a 


formatting issue) so the revision 2 could not be posted, so we wi=
ll cancel the slot. Note that other large-scale RPL deployments


will be added soon, so version -03 will be ready for IETF-86.






On the other hand, looking at the activity around Trickle Multicast, w=
e added a 10mn slot.







Here is the new agenda:









1) Agenda/admin (Chairs - 5mn) [5]







2) WG Status (Chairs - 10 mn) [15]







3) Security Framework and Applicability Statement template

(Michael - 10m) [25]


draft=3Ddraft-richardson-roll-applicability-template-00







4) RPL applicability in industrial networks


draft-phinney-roll-rpl-industrial-applicability-01


(Pascal - 10mn) [35]







5) Industrial Deterministic Routing Extension for Low-Power

and Lossy Networks (M. Wei - 10mn) [45]







6) Multicast Protocol for Low power and Lossy Networks (MPL)

draft-ietf-roll-trickle-mcast-02 (Jonathan - 10mn) [55]







7) Loop Free DODAG Local Repair (Jianlin Guo - 10mn) [65]


draft-guo-roll-loop-free-dodag-repair







8) RPL Routing Pathology In a Network With a Mix of Nodes Operating=
 in


Storing and Non-Storing Modes (JeongGil Ko - 10 mn) [75]


draft-ko-roll-mix-network-pathology-01









Thanks.







JP.














--_000_03B78081B371D44390ED6E7BADBB4A77220517C5xmbrcdx02ciscoc_--

From stokcons@xs4all.nl  Mon Nov  5 04:24:08 2012
Return-Path: 
X-Original-To: roll@ietfa.amsl.com
Delivered-To: roll@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E89A21F85B3 for ; Mon,  5 Nov 2012 04:24:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.504
X-Spam-Level: 
X-Spam-Status: No, score=-0.504 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QkHGAVsYFDSB for ; Mon,  5 Nov 2012 04:24:07 -0800 (PST)
Received: from smtp-vbr10.xs4all.nl (smtp-vbr10.xs4all.nl [194.109.24.30]) by ietfa.amsl.com (Postfix) with ESMTP id 36B8321F8585 for ; Mon,  5 Nov 2012 04:24:07 -0800 (PST)
Received: from roundcube.xs4all.nl (roundcube4.xs4all.net [194.109.20.200]) by smtp-vbr10.xs4all.nl (8.13.8/8.13.8) with ESMTP id qA5CNTg4055095; Mon, 5 Nov 2012 13:23:30 +0100 (CET) (envelope-from stokcons@xs4all.nl)
Received: from dhcp-42f7.meeting.ietf.org ([130.129.66.247]) by roundcube.xs4all.nl with HTTP (HTTP/1.1 POST); Mon, 05 Nov 2012 13:23:29 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Date: Mon, 05 Nov 2012 13:23:29 +0100
From: peter van der Stok 
To: Michael Richardson 
Organization: vanderstok consultancy
Mail-Reply-To: 
In-Reply-To: <19755.1351900015@sandelman.ca>
References:     <5091B2A3.1090205@exegin.com>   <404.1351779310@obiwan.sandelman.ca> <21d5e8c9a5f4a517a8fa421497f37c8a@xs4all.nl> <19755.1351900015@sandelman.ca>
Message-ID: <7a5d49da82e9b77ea808b389792ccdeb@xs4all.nl>
X-Sender: stokcons@xs4all.nl (RxmOSHTibiWwtSyLv+l3Ys0kfMqFVmnl)
User-Agent: XS4ALL Webmail
X-Virus-Scanned: by XS4ALL Virus Scanner
Cc: "roll@ietf.org WG" , "Jonathan Hui \(johui\)" 
Subject: Re: [Roll] WG Last Call draft-ietf-roll-trickle-mcast-02
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: consultancy@vanderstok.org
List-Id: Routing Over Low power and Lossy networks 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 05 Nov 2012 12:24:08 -0000

Hi Michael,

The answer to your question is given by the scenario of Dario that I 
reproduced below.

Actions  4 and 5 describe what I intended to limit the forwarding.

In addition I like to mention that when a multicast is intended for a 
group with members in N2 and N1
the multicast address could have a prefix that is a prefix to Fd01::/64 
and Fd02::/64.
For example the MC address is then FF35:0040:FD0::1.
In accordance, I suggest that all forwarders in N1 and in N2 accept and 
forward the message.


As an aside I like to mention that BR1 and BR2 use the same channel for 
802.15.4 because often there are many physical and organisational 
constraints who may dictate such an alocation.

Greetings,

Peter

-------- DArio scenario     -------

Example: Two border routers (BR1 and BR2) each forming a network:

--- Network 1 (BR1) ---
Unicast prefix: FD01::/64
Unicast-prefix-based multicast address prefix: FF35:0040:FD01::/96

--- Network 2 (BR2) ---
Unicast prefix: FD02::/64
Unicast-prefix-based multicast address prefix: FF35:0040:FD02::/96
1.	A non-MPL aware node in network 1 wishes to send a multicast to all 
nodes in network 1.
2.	It sends to multicast address FF35:0040:FD01::1, un-encapsulated.
3.	The packet is received by a MPL router in network 2 (N2R1).
4.	N2R1 finds no higher layer listening to FF35:0040:FD01::1 and, 
therefore, does not pass the packet up.
5.	N2R1 finds no matching routing information for FF35:0040:FD01::1 and 
does not forward the packet. The packet is, therefore, discarded.
6.	The packet is also received by a MPL router in network 1 (N1R1).
7.	N1R1 finds a higher layer listening to FF35:0040:FD01::1 and passes 
a copy of the packet up. Note: This would depend on whether or not any 
higher layers were actually interested in the mc group. Also, this step 
is not a prerequisite for the next step to occur.
8.	N1R1 finds matching routing information for FF35:0040:FD01::1, 
because it is a member of network FD01::/64
9.	N1R1 encapsulates the packet with a MPL HbH option such that the 
outer and inner destination addresses appear as: 
[FF02::MPL][FF35:0040:FD01::1], respectively.
10.	N1R1 transmits the new resulting packet.
11.	The packet is received by another MPL router in network 1 (N1R2).
12.	Seeing that the destination address is FF02::MPL, N1R2 decapsulates 
the packet (i.e. the original packet exits the tunnel).
13.	N1R2 finds a higher layer listening to FF35:0040:FD01::1 and passes 
a copy of the inner packet up. Note: This step is not a prerequisite for 
the next step to occur.
14.	N1R2 also finds matching routing information for FF35:0040:FD01::1, 
because it is a member of network FD01::/64.
15.	N1R2 re-encapsulates the packet with the *original* MPL HbH option 
such that the outer and inner destination addresses appear as: 
[FF02::MPL][FF35:0040:FD01::1], respectively.
16.	N1R2 transmits the resulting packet.
17.	The packet is received by yet another MPL router in network 2 
(N2R2).
18.	Seeing that the destination address is FF02::MPL, N2R2 decapsulates 
the packet (i.e. the original packet exits the tunnel).
19.	N2R2 finds no matching routing information or listener for 
FF35:0040:FD01::1 and, therefore, discards the packet.

----- end Dario scenario -------

Michael Richardson schreef op 2012-11-03 00:46:
> see inline
>
> peter van der Stok  wrote:
>     peter> It is related to the scope of the multicast, but not in 
> the
>     peter> administrative sense, but in an operational sense when
>     peter> wireless forwarders receive MPL messages and they should 
> be
>     peter> able to filter only those messages that are targeted to 
> the
>     peter> subnet of which they are part.
>
> Is this about configuring multicast (hardware) filters so that the 
> wrong
> nodes aren't woken up?
> Is the case you speak up articulated by one of Robert's diagrams?
>
>     peter> I explained the case earlier with an example.
>
> Yes, I had asked a question about that too.  I didn't understand how
> the two networks overlapped.  Do they share the same 15.4 key 
> material?
> Do they have the same beacons?
>
> My feeling is that you are solving a problem which exists on paper, 
> but
> not in a real 15.4 network.  But, I could be completely wrong.


From johui@cisco.com  Mon Nov  5 05:27:34 2012
Return-Path: 
X-Original-To: roll@ietfa.amsl.com
Delivered-To: roll@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A44221F853B for ; Mon,  5 Nov 2012 05:27:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.599
X-Spam-Level: 
X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ojdcXhrXqy3j for ; Mon,  5 Nov 2012 05:27:29 -0800 (PST)
Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 39CFA21F8672 for ; Mon,  5 Nov 2012 05:27:19 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7113; q=dns/txt; s=iport; t=1352122039; x=1353331639; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=BOzV/M+ttuuuh3DDz+wHXo5b52JivO5tibxz3/GGa8A=; b=edEsPNGc6GLTWdSGXKTFXoym+xrdgTRtDUEjL5YGoxcLKcLi2ZYJ6RGK UymwKNqC3DZphjjo/PApAyE78YHVjgmLnrCY5amIPNq9SBnZ4DljaPR2m XQLemXPXj6+3JL0wlq6Gic26Y3yC6IlbedfCXAvTi75MAptRs1SLd6N4N w=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av4EAFS+l1CtJV2b/2dsb2JhbAA6CsNAgQiCHgEBAQMBEgEnPwULAgEIGAoUEDIlAgQOBQgah2IGmk2fX4wBEAWFRmEDpFSBa4JvgVwfHg
X-IronPort-AV: E=Sophos;i="4.80,715,1344211200"; d="scan'208";a="135866829"
Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-9.cisco.com with ESMTP; 05 Nov 2012 13:27:18 +0000
Received: from xhc-aln-x01.cisco.com (xhc-aln-x01.cisco.com [173.36.12.75]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id qA5DRI9E008227 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 5 Nov 2012 13:27:18 GMT
Received: from xmb-rcd-x04.cisco.com ([169.254.8.200]) by xhc-aln-x01.cisco.com ([173.36.12.75]) with mapi id 14.02.0318.001; Mon, 5 Nov 2012 07:27:18 -0600
From: "Jonathan Hui (johui)" 
To: "" 
Thread-Topic: [Roll] WG Last Call draft-ietf-roll-trickle-mcast-02
Thread-Index: AQHNt+Sjjd3eM9iNy0mrVYgwyyr3Lg==
Date: Mon, 5 Nov 2012 13:27:18 +0000
Message-ID: 
References:     <5091B2A3.1090205@exegin.com>   <404.1351779310@obiwan.sandelman.ca> <21d5e8c9a5f4a517a8fa421497f37c8a@xs4all.nl> <19755.1351900015@sandelman.ca> <7a5d49da82e9b77ea808b389792ccdeb@xs4all.nl>
In-Reply-To: <7a5d49da82e9b77ea808b389792ccdeb@xs4all.nl>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.21.124.110]
x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19340.004
x-tm-as-result: No--39.851600-8.000000-31
x-tm-as-user-approved-sender: No
x-tm-as-user-blocked-sender: No
Content-Type: text/plain; charset="us-ascii"
Content-ID: <70B6FB24A57F154DA723748589EB33FB@cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "roll@ietf.org WG" 
Subject: Re: [Roll] WG Last Call draft-ietf-roll-trickle-mcast-02
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Routing Over Low power and Lossy networks 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 05 Nov 2012 13:27:34 -0000

Hi Peter,

To reiterate my thoughts - this works because the IPv6 multicast address id=
entifying the endpoints also identifies the MPL domain.  How would you limi=
t the scope of disseminating a message sent to a well-known IPv6 multicast =
address?  Or is the answer (i) we don't support anything other than unicast=
-prefix-based multicast addresses or (ii) we don't limit the dissemination =
scope sent to anything else?

The options I see:

1) Use the same IPv6 multicast address for identifying both endpoints and M=
PL domain.
1a) MPL is not used to disseminate packets destined to other IPv6 multicast=
 addresses.
1b) MPL may be used to disseminate packets destined to other IPv6 multicast=
 addresses, but will disseminate across any connected region of MPL forward=
ers.

In supporting the cases above, a well-known link-local multicast address is=
 used in the outer IPv6 header when encapsulation is used.  The outer heade=
r's MPL Option and the inner header's IPv6 destination address is used to d=
etermine whether to (i) pass up to higher layers and (ii) forward the packe=
t.

If we decide to support inclusion of the MPL Option without encapsulation, =
then a forwarder needs to understand that the MPL Option and IPv6 destinati=
on address in the same IPv6 header are used to determine (i) pass up to hig=
her layers and (ii) forward the packet.

2) Decouple the concept of MPL domain and application endpoint identifiers.
2a) Identify MPL domain using outer header's IPv6 destination address.
2b) Identify MPL domain using "instance" field in MPL Option.

Both cases above would allow limiting the dissemination scope of any arbitr=
ary IPv6 multicast address, including well-known addresses.  Furthermore, t=
he forwarding decision is made using only information contained in a single=
 IPv6 header - option 2a relies on the MPL Option and the IPv6 destination =
address of the outer header, option 2b relies only on information contained=
 in the MPL Option.

Both options 1 and 2 require managing another identifier space.  Option 1 r=
equires configuring the devices with a prefix.  Option 2a requires configur=
ing devices with a multicast group.  Option 2b requires configuring devices=
 with an MPL instance.

Option 1 avoids the need to carry a separate MPL domain identifier since it=
 requires the IPv6 multicast addresses to use the same prefix that identifi=
es the MPL domain.

Comments/thoughts?

--
Jonatan Hui

On Nov 5, 2012, at 7:23 AM, peter van der Stok  wrote:

> Hi Michael,
>=20
> The answer to your question is given by the scenario of Dario that I repr=
oduced below.
>=20
> Actions  4 and 5 describe what I intended to limit the forwarding.
>=20
> In addition I like to mention that when a multicast is intended for a gro=
up with members in N2 and N1
> the multicast address could have a prefix that is a prefix to Fd01::/64 a=
nd Fd02::/64.
> For example the MC address is then FF35:0040:FD0::1.
> In accordance, I suggest that all forwarders in N1 and in N2 accept and f=
orward the message.
>=20
>=20
> As an aside I like to mention that BR1 and BR2 use the same channel for 8=
02.15.4 because often there are many physical and organisational constraint=
s who may dictate such an alocation.
>=20
> Greetings,
>=20
> Peter
>=20
> -------- DArio scenario     -------
>=20
> Example: Two border routers (BR1 and BR2) each forming a network:
>=20
> --- Network 1 (BR1) ---
> Unicast prefix: FD01::/64
> Unicast-prefix-based multicast address prefix: FF35:0040:FD01::/96
>=20
> --- Network 2 (BR2) ---
> Unicast prefix: FD02::/64
> Unicast-prefix-based multicast address prefix: FF35:0040:FD02::/96
> 1.	A non-MPL aware node in network 1 wishes to send a multicast to all no=
des in network 1.
> 2.	It sends to multicast address FF35:0040:FD01::1, un-encapsulated.
> 3.	The packet is received by a MPL router in network 2 (N2R1).
> 4.	N2R1 finds no higher layer listening to FF35:0040:FD01::1 and, therefo=
re, does not pass the packet up.
> 5.	N2R1 finds no matching routing information for FF35:0040:FD01::1 and d=
oes not forward the packet. The packet is, therefore, discarded.
> 6.	The packet is also received by a MPL router in network 1 (N1R1).
> 7.	N1R1 finds a higher layer listening to FF35:0040:FD01::1 and passes a =
copy of the packet up. Note: This would depend on whether or not any higher=
 layers were actually interested in the mc group. Also, this step is not a =
prerequisite for the next step to occur.
> 8.	N1R1 finds matching routing information for FF35:0040:FD01::1, because=
 it is a member of network FD01::/64
> 9.	N1R1 encapsulates the packet with a MPL HbH option such that the outer=
 and inner destination addresses appear as: [FF02::MPL][FF35:0040:FD01::1],=
 respectively.
> 10.	N1R1 transmits the new resulting packet.
> 11.	The packet is received by another MPL router in network 1 (N1R2).
> 12.	Seeing that the destination address is FF02::MPL, N1R2 decapsulates t=
he packet (i.e. the original packet exits the tunnel).
> 13.	N1R2 finds a higher layer listening to FF35:0040:FD01::1 and passes a=
 copy of the inner packet up. Note: This step is not a prerequisite for the=
 next step to occur.
> 14.	N1R2 also finds matching routing information for FF35:0040:FD01::1, b=
ecause it is a member of network FD01::/64.
> 15.	N1R2 re-encapsulates the packet with the *original* MPL HbH option su=
ch that the outer and inner destination addresses appear as: [FF02::MPL][FF=
35:0040:FD01::1], respectively.
> 16.	N1R2 transmits the resulting packet.
> 17.	The packet is received by yet another MPL router in network 2 (N2R2).
> 18.	Seeing that the destination address is FF02::MPL, N2R2 decapsulates t=
he packet (i.e. the original packet exits the tunnel).
> 19.	N2R2 finds no matching routing information or listener for FF35:0040:=
FD01::1 and, therefore, discards the packet.
>=20
> ----- end Dario scenario -------
>=20
> Michael Richardson schreef op 2012-11-03 00:46:
>> see inline
>>=20
>> peter van der Stok  wrote:
>>    peter> It is related to the scope of the multicast, but not in the
>>    peter> administrative sense, but in an operational sense when
>>    peter> wireless forwarders receive MPL messages and they should be
>>    peter> able to filter only those messages that are targeted to the
>>    peter> subnet of which they are part.
>>=20
>> Is this about configuring multicast (hardware) filters so that the wrong
>> nodes aren't woken up?
>> Is the case you speak up articulated by one of Robert's diagrams?
>>=20
>>    peter> I explained the case earlier with an example.
>>=20
>> Yes, I had asked a question about that too.  I didn't understand how
>> the two networks overlapped.  Do they share the same 15.4 key material?
>> Do they have the same beacons?
>>=20
>> My feeling is that you are solving a problem which exists on paper, but
>> not in a real 15.4 network.  But, I could be completely wrong.
>=20


From fluffy@cisco.com  Sun Nov  4 09:55:52 2012
Return-Path: 
X-Original-To: roll@ietfa.amsl.com
Delivered-To: roll@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 623F621F8626; Sun,  4 Nov 2012 09:55:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.599
X-Spam-Level: 
X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EFiW7OlRIV1P; Sun,  4 Nov 2012 09:55:51 -0800 (PST)
Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 83F2721F8615; Sun,  4 Nov 2012 09:55:47 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3877; q=dns/txt; s=iport; t=1352051747; x=1353261347; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=zx648dV1GzOpShKn+2bM3+/aAeY41xkQ6v7FWY9XXDo=; b=NoZG36LBQv5ZaV3RHwneAQYLTRJQB/Gr9qCius7XHPtpDemmfGOd4ZI4 Q2N2G4p/xJGD6ZEI6tpOECVwmTISG/9ZDX8s2EviC7JkY9GmBRA6sYd9K WPneGSUHxpMjBqBpWy/O2jmV1w79L7xYc3SZXs5+sWnEb+V1ylC0ygJ5z g=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av8EAP2qllCtJV2c/2dsb2JhbABEwzmBCIIeAQEBAgEBAQEBDwEnNAsQAgEIEgYKFBAnCxcOAgQBDQUIDAcHh2IGC5kxnwuMAYVbYQOkVIFrgm+CGQ
X-IronPort-AV: E=Sophos;i="4.80,711,1344211200"; d="scan'208";a="138628238"
Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-2.cisco.com with ESMTP; 04 Nov 2012 17:55:47 +0000
Received: from xhc-aln-x02.cisco.com (xhc-aln-x02.cisco.com [173.36.12.76]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id qA4HtkgV032526 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 4 Nov 2012 17:55:46 GMT
Received: from xmb-aln-x02.cisco.com ([169.254.5.217]) by xhc-aln-x02.cisco.com ([173.36.12.76]) with mapi id 14.02.0318.001; Sun, 4 Nov 2012 11:55:46 -0600
From: "Cullen Jennings (fluffy)" 
To: Stephen Farrell , Michael Richardson , "saag@ietf.org" , Sean Turner , Carsten Bormann 
Thread-Topic: [6lowpan] SOLACE things at SAAG
Thread-Index: AQHNurWd8mDoYb2tQUy4Nk+S++c3Zw==
Date: Sun, 4 Nov 2012 17:55:46 +0000
Message-ID: 
References: <015901cdb0d3$d38cf1f0$7aa6d5d0$@a-star.edu.sg>  <1116.1351177270@sandelman.ca> <02a101cdb5f5$51109a70$f331cf50$@a-star.edu.sg>  <508EBD6B.1070606@cs.tcd.ie> <10703.1351542774@obiwan.sandelman.ca> <508EEB07.8080807@cs.tcd.ie>
In-Reply-To: <508EEB07.8080807@cs.tcd.ie>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.21.78.123]
x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19338.004
x-tm-as-result: No--48.905900-8.000000-31
x-tm-as-user-approved-sender: No
x-tm-as-user-blocked-sender: No
Content-Type: text/plain; charset="us-ascii"
Content-ID: <81E1CB44A01F564E8B2605302FA46364@cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Mailman-Approved-At: Mon, 05 Nov 2012 06:21:37 -0800
Cc: "roll@ietf.org" , "Keoh, Sye Loong" , "6lowpan@ietf.org" <6lowpan@ietf.org>
Subject: Re: [Roll] [6lowpan] SOLACE things at SAAG
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Routing Over Low power and Lossy networks 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 04 Nov 2012 17:55:52 -0000

I have been doing some work with constrained devices and would be happy to =
talk about the problem in SAAG. I've spend a fair amount of time talking to=
 few folks that I think of as part of the security mafia to try and underst=
and how to describe some of the threats and try and get crisp about the ove=
rall goals - particularly in thinking about how the problem is different th=
an security problems we have already solved.=20

I do have a sketch of a proposed solution which I think helps people unders=
tand the problem but may or may not be the right path to a good solution.  =
If someone from the security community wanted to help me move this from a s=
ketch to a well formed proposal, that would be great but I think the key th=
ing for SAAG right now is the problem.=20

I'm glad to do this with Carsten - he and I are at pretty opposite ends of =
the spectrum on some of this stuff but the union of our views likely covers=
 a very large percentage of the broad communities views on the topic.=20

Cullen



On Oct 29, 2012, at 14:45 , Stephen Farrell  wro=
te:

>=20
> Hiya,
>=20
> So Carsten volunteered to give saag a heads-up on the
> problem this time. If he and Cullen want to arm-wrestle
> that's fine:-) I'm sure either would do a fine job.
>=20
> I didn't mean to say anything about the solace draft
> being good, bad or indifferent. But I figured someone
> is working on this problem somewhere and would like
> to make sure that whatever solution looks like it'll
> be adopted is something that wouldn't cause saag folk
> to have fits.
>=20
> Cheers,
> S.
>=20
> On 10/29/2012 08:32 PM, Michael Richardson wrote:
>>=20
>>>>>>> "Stephen" =3D=3D Stephen Farrell  writes=
:
>>   Stephen> Would it be timely to spend 10 minutes on this during the saa=
g
>>   Stephen> session?
>>=20
>> I think, if you want to talk something SOLACE related which is more
>> concrete than a possible SOLACE IRTF "charter", then maybe have Cullen
>> talk about:
>>=20
>> http://www.lix.polytechnique.fr/hipercom/SmartObjectSecurity/papers/Cull=
enJennings.pdf
>> http://www.lix.polytechnique.fr/hipercom/SmartObjectSecurity/slides/Cull=
en1.pdf
>>=20
>>   Stephen> I'd really like that the security area not end up being surpr=
ised
>>   Stephen> by whatever is eventually decided so getting a presentation a=
t
>>   Stephen> saag would be useful at the point where you more or less know
>>   Stephen> the direction, but are still flexible enough to deal with som=
eone
>>   Stephen> who e.g. points out significant security issues.
>>=20
>> Except that:
>> 1) the constrained devices are more constrained than the IP phones
>>  described.
>>=20
>> 2) the constrained devices probably can not be attacked/p0wned until
>>  after they get on the network, and so actually authenticating to the
>>  network is the "application"
>>=20
>> Cullen's slides provide a really good starting explanation.
>> While the details of the ultimate answer are going to be a bit different
>> in small ways,  the basic architecture he presents has been articulated
>> repeatedly by many.
>>=20
>> So, if your aim is to get more security geeks thinking about attacks,
>> and about defenses, in advance of an actual proposed protocol (and
>> SOLACE is an I*R*TF group, recall. A protocol might not be the result
>> anyway), then I suggest giving Cullen a few minutes to talk about his
>> slide 7,8,9.
>>=20
>>   Stephen> It might be that waiting another meeting cycle or two would b=
e
>>   Stephen> better if the basic ideas aren't yet firmed up.
>>=20
>> One meeting cycle won't help.  Four might.
>>=20
> _______________________________________________
> 6lowpan mailing list
> 6lowpan@ietf.org
> https://www.ietf.org/mailman/listinfo/6lowpan


From pthubert@cisco.com  Mon Nov  5 07:35:12 2012
Return-Path: 
X-Original-To: roll@ietfa.amsl.com
Delivered-To: roll@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 825C021F880C for ; Mon,  5 Nov 2012 07:35:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.599
X-Spam-Level: 
X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z1YCjWA0V72A for ; Mon,  5 Nov 2012 07:35:11 -0800 (PST)
Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 6A61121F8440 for ; Mon,  5 Nov 2012 07:33:46 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4269; q=dns/txt; s=iport; t=1352129626; x=1353339226; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=C2GyQjSx1DbNuhz2rLVCV2sm8cfTFg1X+Ao68WQ6whs=; b=NwXKgpfpBFbz+zzJBA7sTEWlmlRz+u4BTcQlPvWmbiwYMGUo32J229w7 Bu+Tc8o0DVl28QrZeJgUQNZeF5MUaYIl9wFYOQp/Pa8veFxqiE1McsGIG M35hAzwYR/u6a35wrhfUQzQnoFQmFPpkCS2ipDxZk3jnKCaINvs7SSSqR k=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av4EAFPbl1CtJXHB/2dsb2JhbABEDsMsgQiCHwEBBBIBJz8QAgEIDgQQFBAyFw4CBA4NGodomnKfapFcYQOSSZILgWuCMj2CGQ
X-IronPort-AV: E=Sophos;i="4.80,715,1344211200"; d="scan'208";a="138913736"
Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-7.cisco.com with ESMTP; 05 Nov 2012 15:33:45 +0000
Received: from xhc-aln-x10.cisco.com (xhc-aln-x10.cisco.com [173.36.12.84]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id qA5FXjuG026493 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 5 Nov 2012 15:33:45 GMT
Received: from xmb-rcd-x01.cisco.com ([169.254.1.28]) by xhc-aln-x10.cisco.com ([173.36.12.84]) with mapi id 14.02.0318.001; Mon, 5 Nov 2012 09:33:45 -0600
From: "Pascal Thubert (pthubert)" 
To: Philip Levis 
Thread-Topic: [Roll] using the flow label instead of hop by hop
Thread-Index: AQHNt4ehZuUPgSVw8Ei66tfzWpWZPpfbYbaQ
Date: Mon, 5 Nov 2012 15:33:41 +0000
Deferred-Delivery: Mon, 5 Nov 2012 15:33:00 +0000
Message-ID: 
References:    <03D5F543-40BD-427C-9C53-EF5172DC0103@cs.stanford.edu>
In-Reply-To: <03D5F543-40BD-427C-9C53-EF5172DC0103@cs.stanford.edu>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.82.211.174]
x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19340.004
x-tm-as-result: No--50.767700-8.000000-31
x-tm-as-user-approved-sender: No
x-tm-as-user-blocked-sender: No
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "roll@ietf.org" 
Subject: Re: [Roll] using the flow label instead of hop by hop
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Routing Over Low power and Lossy networks 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 05 Nov 2012 15:35:12 -0000

Hello Phil:

> [Pascal] Which  I'd suggest exemplifies what must not be done.  The SPI i=
s an end-to-end information that is useless to the network. Thus is does no=
t belong to the IPv6 header. I hope we are not discussing this are we?

I don't understand -- simply because fields are used end-to-end and "useles=
s" to the network doesn't mean it shouldn't belong in the IPv6 header. For =
example, the protocol field in IPv4 (or next header in IPv6 denoting a tran=
sport header). Or the offset/MF in IPv4.=20

[Pascal] let's talk about that over a drink. It has to do with architecture=
, but also with footprint. You can always add destination option space for =
end to end chat, but the space in the packet that the router can look at is=
 definitely constrained, mostly to the header though for load balancing pur=
poses the router sometimes looks deeper.

-----


 [Pascal] Now, if in some future we do need so save the flow label in order=
 to echo it back to the source in an ICMP error, then we can carve a little=
 room for 20 bits in the 6LoWPAN compression. But so far that need was not =
identified and/or cost-justified. So, no, I do not see that we need IP in I=
P when we use the flow label for the RPL information.

Pascal, I think the issue is really simple. IMHO, any reasonable interpreta=
tion of RFC6537 is that a flow label generated outside a RPL instance MUST =
be delivered unchanged to a node inside a RPL instance. Full stop. Applicat=
ions and other protocols using IPv6 and reading RFC6537 might make this ass=
umption: suddenly they might break working when they hit a RPL network.

I mean, please explain, in a single sentence, how the proposed use does not=
 violate this statement:

"A forwarding node MUST either leave a non-zero flow label value unchanged =
or change it only for compelling operational security reasons as described =
in Section 6.1."

[Pascal] I'm modifying / adding the following text in the draft to amend 64=
37:

   In a LLN, each transmitted bit represents energy and every saving
   counts dearly.  Considering that the value for which the Flow Label
   is used in the IPv6 Flow Label Specification [RFC6437] is to serve
   load balancing in the core, it is unlikely that LLN devices will
   consume energy to generate and then transmit a Flow Label to serve
   interests in some other place.  On the other hand, it makes sense to
   recommend the computation of a stateless Flow Label at the root of
   the LLN towards the Internet.

   Reciprocally , [RFC6437] requires that once set, a non-zero flow
   label value is left unchanged.  The value for that setting is
   consumed once the packet has traversed the core and reaches the LLN.
   Then again, there is little value but a high cost for the LLN in
   spending 20 bits to transport a Flow Label from the Internet over the
   constrained network to the destination node.  It results that the
   MUST in [RFC6437] should be alleviated for packets coming from the
   outside on the LLN, and that it should be acceptable that the
   compression over the LLN erases the original flow label.  It should
   also be acceptable that the Flow Label field is reused in the LLN as
   proposed in this draft.

What do you think?


Basically, if 6man is willing to change the flow label specification such t=
hat nodes need to assume it might be changed along a route, then this seems=
 like a reasonable use of the flow label. But to go against a prior specifi=
cation (in a way that can break interoperability) for an as-of-yet-unsubsta=
ntiated optimization effort seems like poor engineering to me.

[Pascal] You'll note that 6550 has externalized the location of the RPL inf=
ormation to other drafts and thus 6550 is not changed.=20
But really, the point is that the actual standards that get deployed are no=
t 6LoWPAN or RPL.=20
They are the likes of ZigBee IP, ISA100.11a, WiHART, etc... which mandate a=
 list of RFC and then come with interop testing (HCF, WCI).
As it goes, the industrial standards did not pick the larger frames from 80=
2.15.4G, and RPL cannot succeed there with the HbH option and the IP in IP =
encapsulation. Simple as that.

Cheers,

Pascal



From robert.cragie@gmail.com  Mon Nov  5 07:55:21 2012
Return-Path: 
X-Original-To: roll@ietfa.amsl.com
Delivered-To: roll@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C15E21F897E for ; Mon,  5 Nov 2012 07:55:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.976
X-Spam-Level: 
X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iZ4f4iupYL-2 for ; Mon,  5 Nov 2012 07:55:13 -0800 (PST)
Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 8561221F881D for ; Mon,  5 Nov 2012 07:55:12 -0800 (PST)
Received: by mail-ee0-f44.google.com with SMTP id d4so3507039eek.31 for ; Mon, 05 Nov 2012 07:55:11 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=eK3h2VPvBY5KIWlKM+YqBjaKpg5jnbm3AIFhMq/n7oE=; b=FnTVTR8D3zKcte4lMnNZJlrR0PQXFkZncWc/NCkQFo/0/vrYTx3QFWH9zyaAai/FlB x89ate0ehQRC9ssENZGQGQTeXdxQ19mWIxJr88ucMRIHqvBfY6otDi2nJp4WCZiSpySD lznm5nCZnX2EcMen0TO1zuv47mku/bUuf5tRmhaOYArpnQlXvIUFxYwqm7xtmk/bXrYe JFgQVbjhdmE8Mdx193qLG3/hjzvpAzy7H1P7UHXnvPqjnpfm1WW+w4TegN+KKTsgsvqD 1KMLjzCRX0e7E+GAr9GE5VG0rKtTBSiwnfAjKQZQshUQ/5io+7SrNrHHDu4n2RQDtQY/ i8xQ==
MIME-Version: 1.0
Received: by 10.14.175.71 with SMTP id y47mr37950930eel.36.1352130911738; Mon, 05 Nov 2012 07:55:11 -0800 (PST)
Sender: robert.cragie@gmail.com
Received: by 10.14.183.194 with HTTP; Mon, 5 Nov 2012 07:55:11 -0800 (PST)
In-Reply-To: 
References:     <5091B2A3.1090205@exegin.com>   <404.1351779310@obiwan.sandelman.ca> <21d5e8c9a5f4a517a8fa421497f37c8a@xs4all.nl> <19755.1351900015@sandelman.ca> <7a5d49da82e9b77ea808b389792ccdeb@xs4all.nl> 
Date: Mon, 5 Nov 2012 15:55:11 +0000
X-Google-Sender-Auth: bhtxScYjknv9BjSmUQUPAl_ZbdU
Message-ID: 
From: Robert Cragie 
To: "Jonathan Hui (johui)" 
Content-Type: multipart/mixed; boundary=047d7b603e96af1aeb04cdc18261
Cc: "roll@ietf.org WG" 
Subject: Re: [Roll] WG Last Call draft-ietf-roll-trickle-mcast-02
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: robert.cragie@gridmerge.com
List-Id: Routing Over Low power and Lossy networks 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 05 Nov 2012 15:55:21 -0000

--047d7b603e96af1aeb04cdc18261
Content-Type: multipart/alternative; boundary=047d7b603e96af1ae604cdc1825f

--047d7b603e96af1ae604cdc1825f
Content-Type: text/plain; charset=ISO-8859-1

Hi Jonathan,

Good summary.

The main issue with option 2a is that the inner packet then gets
effectively multicast tunneled (a slightly paradoxical concept but I was
reminded the term is used legitimately). In this case, it becomes difficult
to manipulate the inner packet as it should be forwarded verbatim. In this
case, the hop count is not decrement and emanates at the multiple tunnel
endpoints as if it had gone one hop. I remember this was not acceptable for
RPL HbH header encapsulation and that the inner packet had to have its hop
count decremented appropriately.

Attached is another revision of the diagrams which show the MPL domain
multicast encapsulation case.

Robert

On Mon, Nov 5, 2012 at 1:27 PM, Jonathan Hui (johui) wrote:

>
> Hi Peter,
>
> To reiterate my thoughts - this works because the IPv6 multicast address
> identifying the endpoints also identifies the MPL domain.  How would you
> limit the scope of disseminating a message sent to a well-known IPv6
> multicast address?  Or is the answer (i) we don't support anything other
> than unicast-prefix-based multicast addresses or (ii) we don't limit the
> dissemination scope sent to anything else?
>
> The options I see:
>
> 1) Use the same IPv6 multicast address for identifying both endpoints and
> MPL domain.
> 1a) MPL is not used to disseminate packets destined to other IPv6
> multicast addresses.
> 1b) MPL may be used to disseminate packets destined to other IPv6
> multicast addresses, but will disseminate across any connected region of
> MPL forwarders.
>
> In supporting the cases above, a well-known link-local multicast address
> is used in the outer IPv6 header when encapsulation is used.  The outer
> header's MPL Option and the inner header's IPv6 destination address is used
> to determine whether to (i) pass up to higher layers and (ii) forward the
> packet.
>
> If we decide to support inclusion of the MPL Option without encapsulation,
> then a forwarder needs to understand that the MPL Option and IPv6
> destination address in the same IPv6 header are used to determine (i) pass
> up to higher layers and (ii) forward the packet.
>
> 2) Decouple the concept of MPL domain and application endpoint identifiers.
> 2a) Identify MPL domain using outer header's IPv6 destination address.
> 2b) Identify MPL domain using "instance" field in MPL Option.
>
> Both cases above would allow limiting the dissemination scope of any
> arbitrary IPv6 multicast address, including well-known addresses.
>  Furthermore, the forwarding decision is made using only information
> contained in a single IPv6 header - option 2a relies on the MPL Option and
> the IPv6 destination address of the outer header, option 2b relies only on
> information contained in the MPL Option.
>
> Both options 1 and 2 require managing another identifier space.  Option 1
> requires configuring the devices with a prefix.  Option 2a requires
> configuring devices with a multicast group.  Option 2b requires configuring
> devices with an MPL instance.
>
> Option 1 avoids the need to carry a separate MPL domain identifier since
> it requires the IPv6 multicast addresses to use the same prefix that
> identifies the MPL domain.
>
> Comments/thoughts?
>
> --
> Jonatan Hui
>
> On Nov 5, 2012, at 7:23 AM, peter van der Stok  wrote:
>
> > Hi Michael,
> >
> > The answer to your question is given by the scenario of Dario that I
> reproduced below.
> >
> > Actions  4 and 5 describe what I intended to limit the forwarding.
> >
> > In addition I like to mention that when a multicast is intended for a
> group with members in N2 and N1
> > the multicast address could have a prefix that is a prefix to Fd01::/64
> and Fd02::/64.
> > For example the MC address is then FF35:0040:FD0::1.
> > In accordance, I suggest that all forwarders in N1 and in N2 accept and
> forward the message.
> >
> >
> > As an aside I like to mention that BR1 and BR2 use the same channel for
> 802.15.4 because often there are many physical and organisational
> constraints who may dictate such an alocation.
> >
> > Greetings,
> >
> > Peter
> >
> > -------- DArio scenario     -------
> >
> > Example: Two border routers (BR1 and BR2) each forming a network:
> >
> > --- Network 1 (BR1) ---
> > Unicast prefix: FD01::/64
> > Unicast-prefix-based multicast address prefix: FF35:0040:FD01::/96
> >
> > --- Network 2 (BR2) ---
> > Unicast prefix: FD02::/64
> > Unicast-prefix-based multicast address prefix: FF35:0040:FD02::/96
> > 1.    A non-MPL aware node in network 1 wishes to send a multicast to
> all nodes in network 1.
> > 2.    It sends to multicast address FF35:0040:FD01::1, un-encapsulated.
> > 3.    The packet is received by a MPL router in network 2 (N2R1).
> > 4.    N2R1 finds no higher layer listening to FF35:0040:FD01::1 and,
> therefore, does not pass the packet up.
> > 5.    N2R1 finds no matching routing information for FF35:0040:FD01::1
> and does not forward the packet. The packet is, therefore, discarded.
> > 6.    The packet is also received by a MPL router in network 1 (N1R1).
> > 7.    N1R1 finds a higher layer listening to FF35:0040:FD01::1 and
> passes a copy of the packet up. Note: This would depend on whether or not
> any higher layers were actually interested in the mc group. Also, this step
> is not a prerequisite for the next step to occur.
> > 8.    N1R1 finds matching routing information for FF35:0040:FD01::1,
> because it is a member of network FD01::/64
> > 9.    N1R1 encapsulates the packet with a MPL HbH option such that the
> outer and inner destination addresses appear as:
> [FF02::MPL][FF35:0040:FD01::1], respectively.
> > 10.   N1R1 transmits the new resulting packet.
> > 11.   The packet is received by another MPL router in network 1 (N1R2).
> > 12.   Seeing that the destination address is FF02::MPL, N1R2
> decapsulates the packet (i.e. the original packet exits the tunnel).
> > 13.   N1R2 finds a higher layer listening to FF35:0040:FD01::1 and
> passes a copy of the inner packet up. Note: This step is not a prerequisite
> for the next step to occur.
> > 14.   N1R2 also finds matching routing information for
> FF35:0040:FD01::1, because it is a member of network FD01::/64.
> > 15.   N1R2 re-encapsulates the packet with the *original* MPL HbH option
> such that the outer and inner destination addresses appear as:
> [FF02::MPL][FF35:0040:FD01::1], respectively.
> > 16.   N1R2 transmits the resulting packet.
> > 17.   The packet is received by yet another MPL router in network 2
> (N2R2).
> > 18.   Seeing that the destination address is FF02::MPL, N2R2
> decapsulates the packet (i.e. the original packet exits the tunnel).
> > 19.   N2R2 finds no matching routing information or listener for
> FF35:0040:FD01::1 and, therefore, discards the packet.
> >
> > ----- end Dario scenario -------
> >
> > Michael Richardson schreef op 2012-11-03 00:46:
> >> see inline
> >>
> >> peter van der Stok  wrote:
> >>    peter> It is related to the scope of the multicast, but not in the
> >>    peter> administrative sense, but in an operational sense when
> >>    peter> wireless forwarders receive MPL messages and they should be
> >>    peter> able to filter only those messages that are targeted to the
> >>    peter> subnet of which they are part.
> >>
> >> Is this about configuring multicast (hardware) filters so that the wrong
> >> nodes aren't woken up?
> >> Is the case you speak up articulated by one of Robert's diagrams?
> >>
> >>    peter> I explained the case earlier with an example.
> >>
> >> Yes, I had asked a question about that too.  I didn't understand how
> >> the two networks overlapped.  Do they share the same 15.4 key material?
> >> Do they have the same beacons?
> >>
> >> My feeling is that you are solving a problem which exists on paper, but
> >> not in a real 15.4 network.  But, I could be completely wrong.
> >
>
> _______________________________________________
> Roll mailing list
> Roll@ietf.org
> https://www.ietf.org/mailman/listinfo/roll
>

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


Hi Jonathan,

Good summary.

The main issue with option 2a is that the inner packet then gets eff=
ectively multicast tunneled (a slightly paradoxical concept but I was remin=
ded the term is used legitimately). In this case, it becomes difficult to m=
anipulate the inner packet as it should be forwarded verbatim. In this case=
, the hop count is not decrement and emanates at the multiple tunnel endpoi=
nts as if it had gone one hop. I remember this was not acceptable for RPL H=
bH header encapsulation and that the inner packet had to have its hop count=
 decremented appropriately.



Attached is another revision of the diagrams which show=
 the MPL domain multicast encapsulation case.

Robe=
rt

On Mon, Nov 5, 2012 at 1:27 PM, Jona=
than Hui (johui) <johui@cisco.com> wrote:




Hi Peter,



To reiterate my thoughts - this works because the IPv6 multicast address id=
entifying the endpoints also identifies the MPL domain. =A0How would you li=
mit the scope of disseminating a message sent to a well-known IPv6 multicas=
t address? =A0Or is the answer (i) we don't support anything other than=
 unicast-prefix-based multicast addresses or (ii) we don't limit the di=
ssemination scope sent to anything else?




The options I see:



1) Use the same IPv6 multicast address for identifying both endpoints and M=
PL domain.

1a) MPL is not used to disseminate packets destined to other IPv6 multicast=
 addresses.

1b) MPL may be used to disseminate packets destined to other IPv6 multicast=
 addresses, but will disseminate across any connected region of MPL forward=
ers.



In supporting the cases above, a well-known link-local multicast address is=
 used in the outer IPv6 header when encapsulation is used. =A0The outer hea=
der's MPL Option and the inner header's IPv6 destination address is=
 used to determine whether to (i) pass up to higher layers and (ii) forward=
 the packet.




If we decide to support inclusion of the MPL Option without encapsulation, =
then a forwarder needs to understand that the MPL Option and IPv6 destinati=
on address in the same IPv6 header are used to determine (i) pass up to hig=
her layers and (ii) forward the packet.




2) Decouple the concept of MPL domain and application endpoint identifiers.=


2a) Identify MPL domain using outer header's IPv6 destination address.<=
br>
2b) Identify MPL domain using "instance" field in MPL Option.



Both cases above would allow limiting the dissemination scope of any arbitr=
ary IPv6 multicast address, including well-known addresses. =A0Furthermore,=
 the forwarding decision is made using only information contained in a sing=
le IPv6 header - option 2a relies on the MPL Option and the IPv6 destinatio=
n address of the outer header, option 2b relies only on information contain=
ed in the MPL Option.




Both options 1 and 2 require managing another identifier space. =A0Option 1=
 requires configuring the devices with a prefix. =A0Option 2a requires conf=
iguring devices with a multicast group. =A0Option 2b requires configuring d=
evices with an MPL instance.




Option 1 avoids the need to carry a separate MPL domain identifier since it=
 requires the IPv6 multicast addresses to use the same prefix that identifi=
es the MPL domain.



Comments/thoughts?



--

Jonatan Hui




On Nov 5, 2012, at 7:23 AM, peter van der Stok <stokcons@xs4all.nl> wrote:



> Hi Michael,

>

> The answer to your question is given by the scenario of Dario that I r=
eproduced below.

>

> Actions =A04 and 5 describe what I intended to limit the forwarding.
>

> In addition I like to mention that when a multicast is intended for a =
group with members in N2 and N1

> the multicast address could have a prefix that is a prefix to Fd01::/6=
4 and Fd02::/64.

> For example the MC address is then FF35:0040:FD0::1.

> In accordance, I suggest that all forwarders in N1 and in N2 accept an=
d forward the message.

>

>

> As an aside I like to mention that BR1 and BR2 use the same channel fo=
r 802.15.4 because often there are many physical and organisational constra=
ints who may dictate such an alocation.

>

> Greetings,

>

> Peter

>

> -------- DArio scenario =A0 =A0 -------

>

> Example: Two border routers (BR1 and BR2) each forming a network:

>

> --- Network 1 (BR1) ---

> Unicast prefix: FD01::/64

> Unicast-prefix-based multicast address prefix: FF35:0040:FD01::/96

>

> --- Network 2 (BR2) ---

> Unicast prefix: FD02::/64

> Unicast-prefix-based multicast address prefix: FF35:0040:FD02::/96

> 1. =A0 =A0A non-MPL aware node in network 1 wishes to send a multicast=
 to all nodes in network 1.

> 2. =A0 =A0It sends to multicast address FF35:0040:FD01::1, un-encapsul=
ated.

> 3. =A0 =A0The packet is received by a MPL router in network 2 (N2R1).<=
br>
> 4. =A0 =A0N2R1 finds no higher layer listening to FF35:0040:FD01::1 an=
d, therefore, does not pass the packet up.

> 5. =A0 =A0N2R1 finds no matching routing information for FF35:0040:FD0=
1::1 and does not forward the packet. The packet is, therefore, discarded.<=
br>
> 6. =A0 =A0The packet is also received by a MPL router in network 1 (N1=
R1).

> 7. =A0 =A0N1R1 finds a higher layer listening to FF35:0040:FD01::1 and=
 passes a copy of the packet up. Note: This would depend on whether or not =
any higher layers were actually interested in the mc group. Also, this step=
 is not a prerequisite for the next step to occur.


> 8. =A0 =A0N1R1 finds matching routing information for FF35:0040:FD01::=
1, because it is a member of network FD01::/64

> 9. =A0 =A0N1R1 encapsulates the packet with a MPL HbH option such that=
 the outer and inner destination addresses appear as: [FF02::MPL][FF35:0040=
:FD01::1], respectively.

> 10. =A0 N1R1 transmits the new resulting packet.

> 11. =A0 The packet is received by another MPL router in network 1 (N1R=
2).

> 12. =A0 Seeing that the destination address is FF02::MPL, N1R2 decapsu=
lates the packet (i.e. the original packet exits the tunnel).

> 13. =A0 N1R2 finds a higher layer listening to FF35:0040:FD01::1 and p=
asses a copy of the inner packet up. Note: This step is not a prerequisite =
for the next step to occur.

> 14. =A0 N1R2 also finds matching routing information for FF35:0040:FD0=
1::1, because it is a member of network FD01::/64.

> 15. =A0 N1R2 re-encapsulates the packet with the *original* MPL HbH op=
tion such that the outer and inner destination addresses appear as: [FF02::=
MPL][FF35:0040:FD01::1], respectively.

> 16. =A0 N1R2 transmits the resulting packet.

> 17. =A0 The packet is received by yet another MPL router in network 2 =
(N2R2).

> 18. =A0 Seeing that the destination address is FF02::MPL, N2R2 decapsu=
lates the packet (i.e. the original packet exits the tunnel).

> 19. =A0 N2R2 finds no matching routing information or listener for FF3=
5:0040:FD01::1 and, therefore, discards the packet.

>

> ----- end Dario scenario -------

>

> Michael Richardson schreef op 2012-11-03 00:46:

>> see inline

>>

>> peter van der Stok <stokc=
ons@xs4all.nl> wrote:

>> =A0 =A0peter> It is related to the scope of the multicast, but =
not in the

>> =A0 =A0peter> administrative sense, but in an operational sense=
 when

>> =A0 =A0peter> wireless forwarders receive MPL messages and they=
 should be

>> =A0 =A0peter> able to filter only those messages that are targe=
ted to the

>> =A0 =A0peter> subnet of which they are part.

>>

>> Is this about configuring multicast (hardware) filters so that the=
 wrong

>> nodes aren't woken up?

>> Is the case you speak up articulated by one of Robert's diagra=
ms?

>>

>> =A0 =A0peter> I explained the case earlier with an example.

>>

>> Yes, I had asked a question about that too. =A0I didn't unders=
tand how

>> the two networks overlapped. =A0Do they share the same 15.4 key ma=
terial?

>> Do they have the same beacons?

>>

>> My feeling is that you are solving a problem which exists on paper=
, but

>> not in a real 15.4 network. =A0But, I could be completely wrong.
>



_______________________________________________

Roll mailing list

Roll@ietf.org

ht=
tps://www.ietf.org/mailman/listinfo/roll





--047d7b603e96af1ae604cdc1825f--
--047d7b603e96af1aeb04cdc18261
Content-Type: application/pdf; name="HbHTunnelMcast_v8.pdf"
Content-Disposition: attachment; filename="HbHTunnelMcast_v8.pdf"
Content-Transfer-Encoding: base64
X-Attachment-Id: f_h95rtugn0

JVBERi0xLjQKJcOkw7zDtsOfCjIgMCBvYmoKPDwvTGVuZ3RoIDMgMCBSL0ZpbHRlci9GbGF0ZURl
Y29kZT4+CnN0cmVhbQp4nN0aTY/ltu3uX+HzAvOqL1s2MHjAbGY3QG5pBsih6K3dBsG6QHPJ3w8l
Uh+0Jdmz0EybYrEe048iKZKiRIriJsffh/+MYhTwNq3TTY2Lkbdl/O2fw88fxn8PcnT/fvvXIOAH
NW5DQFLjVxrghn4lEu4v/vbL8OUDUoZ/MP7jy2C0uulxVisMevnH+JfPQBrevvztUUih7g9SPAp9
Xx6FwfcJ/jyKWVj/d7lP8Zf1rh7Fk//8Eb9857484/vzXa/uy99ffhg+vQw/lsWQE0xzJ8an+wOw
z/it9wd4fnav2jN38qyJMtL96/eexe/w/wfQ1q+DnpfbNNplAkagsnm+rQSB0hCy0quLMDmEmMMv
w08kfI0ywx9L+Dm3beC8S/iL141eQDeOvLyZ0c7rbQb09xImWUqDNBIwDDy5paRw9rZ7b5ASzA4W
kwo+SX2X8yN9QNuhy5ATfUyfpHRu5zEFOIb/AYnjL5pGIoaJjkdPYPtEvjFf9Q2YtmJKUMk3jAL1
R2/gEGK2fIMoM/yWOTz9beC8S/hSr845jCLXAOrTBA7ScI3OsmSusXqKk3PNg2s4I+EixvWbfEM5
13D+EHxDnbsGxpbl/qAoEij/fSZv8D+Qz4QY4WNHPQAp4Wc3H+Pg1QD0MFHIYwJ/szNGtduodP+u
Fr/yCYtDDUfhVM/xE69tyPkWnXCV3gm1x6YIpayPIe8hSWZGuTreWr7CBWOYkRZewQuducN+5T7j
yIlGeo9L7qWu2jPOwC8jmgNB0gBGtCKHELMVXIgy94jGgvb0t4HzLuErCCUr2NU9o12lAqhh187S
5DuP9vwtYOxs6+MHxgB6vnLrycOLqG49juAbbDtFDRAkhN+5CZNDiNnyDKLM/aphC09/GzjvIn3p
TpZp2zHjDMHftvyisyyZX1gLnK3QgPF+fnG+KwjcFlRXXylqBaF5mbMDK4cIs+UrRJl7Wt0+SH8b
OO8i/YkfUcBXFtM+vXaWJd/mHff1eHatekraHfaHFL8jCLKrXByicwSKF8Ha1+wqV5HNAKFgV2kn
H3EJk0OI2bBroMzwG7pE+tvAedd3Byks2cpZVkJeoBuW7S0NP3wugLEARsm2+9Ol+F8J/+UpEgRK
tcnYHELMlult2Lhzx2ko29PfBs67Hv5BGxTSveln4TOJ95ImPxi4DUDOBp4dTZ8lHPF8n3INGpw+
SwoHqrd/FPVAkLHZUXEHIWbLP4gy966GRTz9beC86yF/5x+mFfJ7y5KXllxKICdROTbuI/ouoKeT
/jGiwyYmXNBxnLR0JTo7+8OvWtzMPfB1REAKbxrjFkn+TkjZcGeyLx+qTtGVz1FdanVTWvK1tKC2
VgnOPj/Kpzs8ampwm4KM4qk5MhsRQJFyUfkc0vC2GvryKajBuMTloIZH+d395deS+RflDqEoD9d4
Zgqjpt17QErDT8zflU8hls5uOy+ZX8OKkHwB7FQGuTdYYdXZDhzGwuKBNaZhj3gSa4yv8OkJIiH4
pPgMa2/m4RQiKXyZm+vNVYxVXAgIBVNjPSIoZgchJqNC9fHmuuvNr7b+ZpVnM69fgFFOvxiinAiR
ZFxqNiNGpa2Xt+FXW5BHvZysyCAYM8PORLhCdlAwWEblxEHehF9thRYdpLBEJSjEjI47jJZwRjZR
RGlFpnOCgnW45XKrMiptlbwNv6NK5OJiTsk3rBTRO7gqjMysJaXOWBBEwnBB2SQYlRNVvAm/giqU
qXiHeHbh9FnainMsUxRvmjMuCARxuKhsGktazi1N9OVz1IAte8Jz9IPSzeMqjgXjWMVx959u58pu
trAikKWGtHPNmCF8zLMMn3dYIPd81/L0DtTa4w0Epg7IDetOeBb1dei8Al0iqOBp9nP7lPKYpzxt
CfcZ+TWvyO55WemcEpuTCSl5TMk7X+rqZcmSAYRCiqSpIkGYHELMRooUKDP8RlqC9LeB8y7fmUxg
mpWSHpcgaauaFdTesuxrJ66OWq6glm/mxDGBjpVVOLYtMSO2qZKmw8jqRZnDegrV06s5cnmqBJl0
QcbeG8bhVM/xE6dtyLmWy2buskwZG00PtKelWRDtKUleOHdZup7VoeniamFclC7Rskin8tgFyJ92
gStVSl53yVoLOGZ2EzLrwY+7VGK0CZU6S+94Jau1zLoBdpCp17k41XP8xGsbcr7lCp0CH5tvqeiu
dbs+11OOfA9wMmhtjj5WvW1V6bIVfeD1t61JPL8ESECCpM3uzHcQYrZ2BKLMjd1Yip7+NnDe5aKZ
o+iMlm5bIWNu3qL3liY3nLvP06pwMDrsCTqdSXb3IKJQNmOnTsx33BnBxKwJoZA1OYXYmCftIMRk
VK5kab351bI0l8iY12ZpWCMIImKeHFgRREJxgdlkGJUrlY3e/EqVjbJKGlkalgWiaD4tjKIhRMJw
QdkkGJUrxYze/Aqq0C6xKaviMwTGcsrq8+AgHCaGgQlBQRwuaj4NRuVK9t6bXyFlXV2CUlJGO2cz
Why7Rbs0rV7P1gxE0H1ydZquZaeeKJL7JfUWfUMONC1zdo2IUNjxJsosCJNDiNnY8QJlht/YY5D+
NnDe1cZWY8Jlv9vwJmo9fS9h9o2tk52Ot4h/9sbWshIIMgY3P8TkEGK2fIMoc89qmMPT3wbOu97Y
arKeQqA/tfLj3rLkrrGAtuShMPN2jhEi0Mouo09jSrO5dYKU85u76/s2tybV26h4/045CmFxqOEs
nOo5fuK1DTnfenOrMRM1rvgopdr5ek9J9s2tE5wdCo74X21uTTPwS4nmQJBM6RV7b+icUz3HT5y2
Iedab1syxpKFvD2pHfE9JNk3tE6y3LD0Z21nPc6d3oXMGtd2UNVaOc0z3JzPNnCu9S4mw9rWJ2o2
fA9J9i2skzCV5rX/pxbWslYQMr6TK3gFhwizdRghytzD6vZB+tvAedf7mbinmKVdmuktDW9iNauo
dLu9bRPrsQXDyNmXoDAHRihkxLhrhlLBDkJMRuVKoaI3v1oLBmj52MjyihaMKKdPh6OcCJFkXGo2
I0blStWiN79aC8ZRLyctGEEwZoadibC8toOCwTIqV4p7vfnVintFB7nWghFExDJKYEVQsA63XG5V
RuVKEac3v1oLRsk3Tlowomj+jj+KhhAJwwVlk2BUrrRg9OZXasHwnlZURbW4t0xRMt8IERggECTh
UrIZLGkln3RfdORT7L4ozTxV8n4c/wBXYOAOCmVuZHN0cmVhbQplbmRvYmoKCjMgMCBvYmoKMjQw
NwplbmRvYmoKCjUgMCBvYmoKPDwvTGVuZ3RoIDYgMCBSL0ZpbHRlci9GbGF0ZURlY29kZT4+CnN0
cmVhbQp4nMVZS4sjNxC++1f0ecGOVHp0N5gG2zMO5LaJIYclpySbEHYC2cv+/UgqPaqkbtnOsoSB
mR51SyVVffXVQ+Ighy+7fwYxCPdkZnOAYdLyMA2ff9/9/G74eycH//P5j51wL2B426WPYPgUJ/ip
n+IS/i+++3P38R2u7H7c/PNtB2I66GGc1WEebr8N313d0tNw+/jhKKSAxR6FEloYYf3jKCah/cO8
7M1RXBdzlEaAuAgltTT+zdV9f/IPdvnl9sPu9bZ7X0lUxgsELzYJhCBQjlKJl0XJo7gscBTnZS+F
E+D+HMWrE+z/DULdxvbhK7+L12U/ua2Fkcm/LJvzew/jdtmP/gWkSecwfMKXdAauHGWFCXhKHKBy
ceVz+S1lXpAdXobDy4Ec/Ne3nTiMw5eomB+/d6bcS2ertwHA4uOn4acN3Ul9sKg7GPzA7aMz1nL7
a1Xbs5MzSnCY4NoGsewhaRfivoMKkj5O5BWOeLOAXJKuwqDURCcjmUKnq6RREwURc1Fdn7I2BUpL
mJiZ4ZI5vhIUbrCHUTtnjD6oZ+t8b65RDUEy1JpxaMGtmow4tzVpow6Kwt2mnaHcbi9JQ+IIsODv
vdRJayrB1X0NapnSuD++nPz/KC98NVI8U3tNQVixA50VwRIGQGdD+KOc24NJ6WTGKWNtY/dRnyDs
BM4HnlL+OCe3qJVvM+Kig4LZEm7AC7eTW/BB4XYOM2zjYVn4pWCPmJVoGgK7XiucIoY1gcOpY5D4
Ia46F6gEM9A5OitCMID9d4QGSiDrMleEoIXosWEzyCCIn7A5BA/ZRdAHjGSRKZKNTC48ZxUmbAcf
MfRwKMISdnAL71N4AcIkQEKD/zp5VvgwST4RNdQRAy1IDeHNvoExRIxD2lQhJi5bWFTUzmmKb3YB
HPKFpwDsfEjVIeIUtEAtm9QQFZT9HwcLJCShB7R3S2U0fFBkEzKPOihwBIpG98bznMTonlCZDEm3
IKijKE5KUM1juYHKdkdvbGNiS5VRJ0xyOkEmY4furgHhidiDBoSV2CNI7KEqtnFzyBZj0cC1SQpa
naVp5MzArZiNS9X+nFppkJkWORYKWweNJspeMUAiji021WUz7KTtluRSuUQCac5ZM/+EIPxY4tOQ
3xnx6LnJrWaTxOJAXW5x+Z6pnVku5tix4qpDEghkiwEBfCfECAoH4oti2xnbZDO7OepyJOL6liRL
IDXlhCjOpxmRIUSRyUdQTmitntWxHtwZ0ZHYF6WolIgE5rJlb6hXGo74eVai+PEOGMxc0wIL+ESD
7kyvPAXv+czd/I4dgKJmGyn3E0sojj22+19scB3UlZzXItj/wxfc7wyrcQh5CuIuooRPTEVCXZNU
HQKfJsyzRoxdWEymTZejg65pNnkLE1FqYLH5ZdykzeMsWMRT01hTBQriHA/EYJ7J+VLoXEjg3Pci
ZDla119JfERnjjbJ+eFWwNeZyquMsYqveU8Q6wXMl+9EO5IiXUvCj4+pDjDMDHfyoBXOS82AOzAa
c51WYIS0VhLshGGIFupYgQZTevpIqIW0G4ZNR4ycink8LYpO3YLTaNMkwOKF0CAeJ7HaVKKpYqVX
5aex+ZCtQ5sPOVpQBwpvqqKsrjlWEjTmiefiidFzei0pPHmvJSUml1r2m1JG6aS+B+t1o2RTAMGF
+AeBomInttn4pM5t8viIueIf3U5VXkCx0GBZrqSLCBquo5+NnpJVoKj1jhUv6WmmEVDAe1aVV9Nc
0tJTvrBXpIjPWizeloiM5OkoaBXgxRKqIZWNTp94TH9t3dT1TLnSK451OyVLxmchAUHWf+2vLsYn
u3xGNLn1t+ilWjZpvUeCq2BQob1zeUnkJ/D5idjd78vp+Tll6Vk2pcg3aYkqEarE1KyJk1edFSp3
KeM5q3++YZ3MVpUbPi/IDaq6DOoqehJPdvn1OLWh+GtVzVLRnD4EQnJhtl+8Ka7mnOuy0rAqmXm+
x6ll/YqgTTB5NcZSmWwhB5cphgUKFspMXesY+ciNimIdFsuD91Y8xrU78dj4Rnc/HGuwjzcAET2g
2wbghdwGNDTFunLUI7HVQMpDtJ9jLBeQWfpH40cTqDlQt0zIbUcvOyBVcYEqJXFb0qiMrTCRCbmU
izHwMlKmu1ABqqQG5D0BRDLWIHkDUYMKui1ANKFUTwYmLUXTAiTdI+52JRVZuz+L5+TXJp20qleF
budGUpT2SP+y9bl8WlO+b+5madR4Lunb6o4ybG63gjLi2wTXpsCVMbN1x5HvAAQrL0lqxluvPYip
eWyCM8tRgcCjbR2uNUce6euLNhRBFYlCcCnRqOqG3Vd1zUgM/+vXNvevjFOQqQvY3m2qIdlHNsX7
4V+WADaLCmVuZHN0cmVhbQplbmRvYmoKCjYgMCBvYmoKMTc2OAplbmRvYmoKCjggMCBvYmoKPDwv
TGVuZ3RoIDkgMCBSL0ZpbHRlci9GbGF0ZURlY29kZT4+CnN0cmVhbQp4nO1cTW8duRG861e8c4BV
+M0hYAiQd+0AuSUxkEOQ00s2QbAOkFzy98OuqibneSVZZ0FYrN2cIburq0k+ks1xuI+X/9395xIu
YUp11Pt0OUq8Py7//fvdn39z+fddvNh///3HXZgv0uXrnVdKl1/UwJr+IhX2N9/98+7n39yF+zYf
H9SQS5+1Uyj3pieXej9UyqXMSibXKef7PuU6tV1nKU0VVjqmHPGmzScmxyn3+eQ6dYX7MkvH1Gjy
tBLDkuL887pKCTZQP+atKRoC0wQbsUITbMc2nwhV7LPd1fFGwwQv4nGfL/IPsmk6piV/M6Bp1q8B
LaWnRrSGhZq25ZqBT5jqwlrL1CYfJMs7lcIFtckEtThH1E/2aJesEtHiG0gVCXigCO3YXW8i6ZG2
DnD54+/Qmf43///9DPq/3mP+ZmP+p7s/fBvriWDqOQZjnU0fS0LaxvZhcltPPnRDiBZxdEMIXZSv
d+lIq5RaEpvNZelSCVbYQtZPuK53TyFXSyE/l57xdKIuwNPN01PJ6/9q4ptO9qpB0CRblxqQi3e2
3s5DoLMb2nycet8dtx9rCExX+8BAQVc/wh4Ok4LTIDiyBoGRU7auo0oXrBwNukhe34PgQAd3xIfZ
WPTSO9GrDqQ3A22HdzjXwq5I/eyitMvO64isUxMpOwk9kJzOQ4BeW31yQT3OEi2QP1omr8S0GAdW
xQI+KEY7dtebSH5/4nuP+VuMuQ1vPstRE8DkhTK5yviRMA6nNBF4bHMc+GEw1nOy5RLjkVOUJYtU
Tgm1LII5ZWCjXMy3VWoXr99Pmg5poo2B1rCd0YqosrHgkc05opc0SIe8p+yx9TcDrVEfTC5N4Fg2
wL1sIyoLVS2OFjGED5Lkm0pohdrgQlrEkvSDP9olr0S0GB/kX5H1+Oy4XW+i+JrR/B7vtxXv00hu
Yc3TlMVVC2t5mls8zdNWOjy2La25Nbd8mqdzK2uezq2ueTq3fpqnczvWPJ3b2Lp6WAvUqaXHtUDN
Pa15Ovd8mqdzL4xtL1qeZskrtnoDvqw2eXQtZJj6yTztMiaOyGJFpIwgPZDcT/O0vEb9subpxRIt
kD9aJq/EtBgHVsUClhSjHbvrTSRfNZrfY/7mYm4j2pbvCauRjMV84OrFfsPr0MJ+rmOqrRTSCGAg
1W6//gN1a8MbbAqrrRTSSNyGVFsppDH/rxXP8afkhu2dlzpas/5hVqVpTAumCauREGV5Sqhz4Gni
dgZoc8jWDl6YXC70j/LU1LBC0husnNSinnW1hvaw0rrbbrY2W5jacKwNbNEHyfJOJfiI+mVpEUfQ
LvZgVawCz+IbSBUJeKAInWJ3vYnkyyP6PeZvNeYY0d2QxG6zyoxuNyQspW7Pm7WYs9eAPMxWNyyx
I8I94M2B/YFhid2OCOC9HSscAYjMYjzi8j8eeXkfDz/AsPp1a5p7GGiijQOHErR90B5QTW8iUBXI
3HNMH0a4yLcpmRbjkU8tJl53nHUcNj9K+xG31cOivvDMfVNypNhDyQPJ8EwyPFb9sDU5R7TR3V5c
rI4bvoFXkYAXis+O3PUmjt8Zz+8Rf5MR9xX3tFzMBz8SZolHrCYPrXMifvl9/RULTxjAdg1aMcWK
FYMOhGPFTIk1Vqx7NxVr0T6BJV+XWYu+NO3dlFng7g2WG3dvwDTlvg6E41yvmA140aL2HEmyr7/8
DXoTW2C1s3RhHSQrWB/JOjxYuKrQYpUlHyTLO5V8PyU2pEU8SX9wq2SVeBbfQKpIwANFaMfuehPJ
16QB3mP+9mK+R3Q9GmZr8sIS+apHX2cRJh8ruvXgLijijZ+WWCYyYKXDaNURtVeaVgb3XZQz5iIv
VfUCa9FOujrmNVkZB9rD+hjrFLaFsOI7ZUTO/GghigGTPLZ8anypLpiUDjAs3eBdNhGRhaYulIif
0EuWXypxp7R4kB4xRAvkjpbJKRBttgfYZhzsvcdnR+56E8fXjOf3iL+1iD+V1LP5oKfASNe8Shnr
k3YgoUg5D85sKJlP/cIWtYIP6KJsa7G4SilZLoAtKLsulWCFLWT9hOuZpB5aOvJz6RlPkb8wPNU8
PZVWUu+ZwRDsMLNXHA33DKkkC24P1rkot4yFmkq12fRutWs0YkyDSZOWbEsmk7mAY03KroMlamd9
s7lxPE2IWgHnlp8mQyij/Vxv+btEWCzbYbteTwCzxH7d2u79DaPWe3yLlkJlizq4oz0wXgv7ypFW
ielZtpAsXSrBClvI+gnXSwlgR34uvZQAJp6vNyWvHy+GyWYpSwAjUi1WHE9w486SbdYz5Iat+uwn
sfEoLdjCwEoD23WrxW02nIkHt97DhkFLQVv3luI6img4TL+ukt0m8ProOdSUtFSnjdTdcmIeHpiS
lghEmwZIhRc89qd/kOekEtp63qFpKAj5pGmgNWzEABsd0liIcrTJj1hNPuSDy/TOSzg8VYvgmsSS
LDAlQMuRhyPAtBgHWsWirQjt2F1vIvmdn8j3mL/RmD9zv6NVc4z5BMo8nW/zN8T3ESbvtVCrXI3A
GZ1um0tt/s7llU9oLa21UGt5rYVaK6e1kM166eIt+loLtXZoXUUruIJD6zjPEK4eVzZhyrDRIA2d
uFNeqyG9GWyL1QrWQ9SDVYn0Y7Uiu1jHLES1ONL165CWXE7rIXmN+umkRyzJAnORsExeiWgxPsR/
1HrIY7Rjd72J5GtySO8xf3sx31nhHuw3nNGlTLZMbmKxh8gpCfxaaSi6PSRlC+OUs5i0WPXgse0B
6xPJftGQJeQFVH9sTTFIE2zE5JZjWicoPepyHdFGXuZrkIq8p+yx9TcDrcs6G1iawLFsgHtYRkwW
ohkrIa1cnsIDyX75kSWtCckEtThD1E7uaJWcEs9iG0gVB3ig+Oy4XW+i+JrR/B7vtxXv00guSScV
TbK4KnmdU5i85+leis4pJopS19zaS1vnFBNF6Wue7uVY83Qv4zRP9xrXPN1r2rpqPs3TvZZ1TtHr
vh/Ya9uxZQ7RvKh+u4UbPrFSu3NV9303aSC71EzWaZHxcCwWJWJk7Iidsnul0qEZWixQj/NDC2SO
lskoES2uh5j3UwqPzo7a9SaGrxrH79F+Q9HedzpaTyu7bzKz5VOy/T7y6A3ZN8/tt47tD7hpHecF
yMi3XpnpAjsNN0OZw28dV8wlj5Xbb0eADdQ/4taEUwbP7bcD51e0feD6O1EduEnqeHWWBS9wxiDv
dD7B3Li/KTi5YIt61oU8u6wg/y7ryMwvXG04XmQ15Qdl+ieZV+uHs0EtzhP1k0HaJbNE5JwTK6NB
HyxGK3LXUxRfc5vjPdpvKdr7HgdPfD2rr/PfzudD+fNaB3JbzKxXrPOZca8tKhNfp/64cvq15eVr
bWVxUIH6ukr94vVtV+CaeI9dFvBMljvv3gNTxw1ZYp1PinL6tfOuOXyD7Hl9f2O7EW8xzpqQXZcN
ZN1lG/n4hQqZeuFFBh9eSJJ3KhVl/5PzIU1iijZadMviddwwDrSKBbxQhHbsrjeRfM1NjveYv72Y
nzK/OfCQk3nAzDMG5AHz3jnV7B/l4Sw/+87J3vBmK/DlrF05snoZ91uZ7csrC5i7dgUs+UrM6o+t
qeybtNNG8Z3TlO79vn4t+X5/3Ffnn7Y7gxfF905Jsq+6/A16FFsw8+a6mJOjFebqiu+dFqa6sDLj
l7W6gizvVFImkExQi3NE7WSPVvPeO22+gTTvvZNHaMfuehPJV+V+32P+5mL+VJ6Ln9zq893e/dPQ
YdlUSyIWl6sO+VnKOLOb9WN0pFHytJvqKuVgewbVp+yaWKINtJDtE6ans3lsuVCfSs94OWyVQzxf
b0rfS3gSSlNy3OjhpV2QkHihn3LkQs6Jw/Ubo6fx2BL0NOVSSA/fiAR+xwpHXBNL+gyoLhxnTC/S
46hPpRfpAZ6vN6Xv0GO/oXO9imTO/O0fuFGo1I4ltfkBMmW7fYhzZJaq/Z6xRcz8sg93FLNuQBf7
pFlvEvsfWlCWLpZohS1o/YzrpbsDC/mp9AxF+OTb8GBOPJVe1YP4uRV7kD69Qj/J0YdaOtrqPYlX
xqy3laANd5TsvUdvVmyjy9QDGdpRWzZPWF7qOQvtqfRSz0lFH9qcSq+jBV+tiBZ+wUJaKs4WKCd9
/8VS4JcyHasgd4nyooZvgqdim8uuiSXaID20fcL0Ij2O+lR6kR7g+XpT+t7AqvwXBnQ9+iirZLlK
mw+QVqEcguaLgmUtLwXjz+qbVpft9gmWrHwT+UGy//sDbelSCVbYQv8mwgnXMwOLLR35qfTc9SOg
xgWLrzelFy5aGKS2ku4sMY1t8lCCO+WseNvwSLlgxsEXCbkqUW6Xa9JKuSf8SusbiYzZTLLuKrFU
olLuqSQk5qEJp16eck8FIaPlgj5GTKXypIxocbomLwq/HoF/kJl09+ddc1xRgntrGmjNmRZrf9rG
Kb6jYhKdeJlcNy8k+a0ulcxv1c99axJTspGrWwavwrQYB1rFoq0I7dhdbyL5mosW7zF/ezH36cD+
m4P745c5Pdlg77gt+eVvl99+tg8jLl9+/suH9Pmhfog19NQe2odYwo+hhDTF+deBV/Nn0OqEx9Ae
/vrl93efvvxKPbwuuKN5qz32mMNPD2U2//Hhh/nnx1hN96epHUrTtPcp9HCEwQcZ1YpVamGkiuKP
D7F9SI8POX2YdYEuTTyGb7avMU4HoLdMsGg7DK5sjlishj3eXgpZHqbhV6hynm2fcbbjbiL+KYRb
Z8PnBS3Gh+VyJaIc28Q0prXPhixHYpvPHufrXB5+yJMeExMbAlNKcD2RholvSKs1mlGdluLxELsb
MwCTjI98/5HNYpisDatrbE0l2Wq1pScMqYfzTZQ/4z5yEQX36b/pSXOFPVf/8SElBnCaI475l0Fv
9D19lH/f9I2JslovYCwmCekn74of0UuKeRo/JND5OB+pK3wOGdoH+0J4TCl8zsHqZvQftrAqjuY5
52KyFW7JdlL0TXBnL7XG6KhmUD2UZKW2elio6ROwbWusxfcMU3YnB/ruceotIM76M0ys/oyXGqvp
2djY14zDJpVvwP+kfh0tBsdUkTXCffjZ223DCfXhFwP+7hvJI+O7MVuviu2mOwGpUca4GUvsnRia
/nYGco5Pjl/vsOkzFc3+DTyzo8+xhebPxw5B6+Fb129GhM9CNGxeVsZRFBSfOE49D7GLnAGfbLHH
Ubsdogksa4gaATMAlVo3mLmuf3zwIR4ZfiNFY77zAXtQkb4XRqdlMYolUL6ZiOOeNdZsWEjE7ZQr
8HBj9g/OabvfsJ71m2a9mGw8rpnmdWOadp8b0zdd8IV5GJ/g2XnNNxHHHLAohbY5G8yJtU6u5eaj
5hQf07/q+j6mWQNj+tmOx5/oJ5A8NQlM6Tz698xw+E8ZDNpPGWO06dsA/nD5P/7tjdcKZW5kc3Ry
ZWFtCmVuZG9iagoKOSAwIG9iago0MDU2CmVuZG9iagoKMTEgMCBvYmoKPDwvTGVuZ3RoIDEyIDAg
Ui9GaWx0ZXIvRmxhdGVEZWNvZGU+PgpzdHJlYW0KeJztWktvGzcQvu+v2HMAq3wNH4AgQHLiArml
MdBD0ZPatAjsAs0lf7/zIpcrUbIC9JLAMGKTy+E8vnlwORuzsfPX6d/ZzAZHUGDj5hzsJs9f/px+
fTP/M9mZfr78NRlccPPzVInc/KQbaOuTsqC/svb39OkN7jabgP8ccSgF/0ZIm4RsStxEnZSANBHy
xs/FIY8IBdeOcy6bMsdo55xpY3T4NEd+FlDD45SBeMSEezLgoCAHGiSLREcZhg3MQpciypL9iZeZ
a7a0iSVlh79Fgxxw7TiJZrgdZtEXt9tZ7ODhcbaG0JKZNZXamohsKxtrMm8m/taaJtZauwHVxlpH
fFhJaz3JZd3rmE2adMaW6g42XzkJLlUGA6ayo606CbgT68qYqwXiisVFx36i7jTk5fmXnzlivuK/
9xgbn18d+3079uP0YTK41yA1p7pzsW18xllo5M45Ze5swXn1qLOJ1bc4AlaeVHQ2LMpPDk10apaz
jpUvzInH6ts6o526g6FTXgTppDIQalclZ4JMdULnkANZV3RamNWCjBqJZZmAcq7wTnzqLbuRab3n
kFEePnLUMHefmDtL9aXqEgyBLzriuFTddaxWyUzslR2Cg1+CXvkLciKX8BR9Ks6iqXhA9Fe/LB47
rvx3PXNfPf1jeZpSmU9z/MFEPjxiOZ5TIcaPf8w/PWCxyPPjp9+21mNlAePN3kT8edjB1iCzXdya
+90dbHloLQ1NoKdg+c+9Bef46b3Jus1GmhA3ogj4/B7ZOpp4nAINokkmE3Uwhbfv6ekBKUH4e+Sy
x7XfH99P7x7PzPDkMTBU79kQdDIC8/hpa+zu8fNoB2MPxiEy1fQgppvdXd6aRFILD/dkqGPL89YG
0S3s7hJpSItB11wQSrQ14JLf3UWFJ/JQ2MkYN9gt2oy/HvgB48QE9JDhuhO8iOa+28oLSABm7z2z
Ec0AQVSN1TtVaUJRtyGMrHlZbXQiFH81WyI+3vfKMtm+okDy3eGqPwIfr9/ij8DH9Nof7oHs3ysc
e0NT53dpyyOKSsUSi4H4ZMd0Yvih7cRIU2uSQBoUg87IvDyV2V4kLXgiRGm7CGT+gpcTjNawI0UV
4tQ3DyK78yq0qKk2RlWpWvgS0ImK1DcBnah4nQQ+6ufFghoEqsA6D8TSGlDrGKkIY2nrY1UwYc9h
+lBeM3HR6FvJcn2+Wc43zqZVFpp3pKM6ssO1urrlm138ejAHZbEALK57S8xqQjNn1YX/dLmr+8NS
Gx4kVx1vvr/uJaA3xDXmnFF7jqKDe8fowiUm4IhJaBXrZVdHOheCL+c1ztWQzdVxN3m6c1RfGBKH
r98hNG89CETO7gj1ivglo0RFF28vFFgiAHeEU5MeSN71ZGeCGnxdSVTrygIHRl3oQ4TqHR9z6uc7
u5Th1GCT563ktGjjkFoqAPm6D801nhxl4VtMEagfWiqg8vV0WYqIrQIuOEJgNfQ+cRKiF44jOziO
Wq65qlvFYHw0Yh6yxljfFugTWo/BdIcYvN15qKAY9do671RiMrHikTXv7chXruVxoOmwCKOGeKaE
0wS/lpW+tNS+MSs93jdPi8H/m5VSk9oBJCD22GKmhvNEvVx/RO9Ubq8/HFM+0Tvo95ysStqiOl+M
6u7kaSB2Vyu6PHyd+pv982RL4GsDzZ7mj20D3bO7+xARer73UIY+zTqLFHdPq5vT+Y1OxPb3kOfJ
G75jjMR6Fzsy6ZuIUJ2p0IXukkgPi23PU8BT8IKlAcS2SsjtFxWqMxXaU95oKcJNvcuCawNLgV85
iQzhMIHZepO5d1nUSqG5bmXlI1bWHQMrF0KyC9CPi5WQTWfldbHr6Kj36Mjc5J63oovUvml0QI3Z
IV2g+2WjC2FM5TNq26i8Z61HwWtJEBGiQ9hEDFaMIrfMOroXTG28gK7EzgxMSETnlM5Rxzn6AZ0T
tSsd8wsjOuYXlM4zPxjQ+QXUZ55lnsUzUFaRSbfz1G7nDjEl9sS8p6ug9B04z8rWvoz3qfVUvSQZ
9wW8911X1XvD/RiLIV1am9CjiUvnAYO9dVY5vblPsST6UcfU11Ba7ncoF+6DKHfujqhM7pqoNtpP
UT2506L6Z9RG7OKujA9OOzQ+QKUMideVB8YqVO5gmTtL5TNZtcFMSlVLLUesfVeajnUm1soOwUA4
VXREhuAmsglN0amiTLoK+qK/eKXz13Hlvev9t1c//0h+7kvG6pB148otz6Vu83hQtfm51mwZn1Zs
fqr1WsaDas0LWl+9ZzC0PntbuFbqzL1Uq1ecXCbwBpXae9vqtGeFRnXa+6VKe8+8BlXaB9tqtA/M
a1CjfVgqNI7ZMYMKvX5lIQ/a5kGKC9AK3dNdrtCQnHiPI19mkhGQPGcEv5tgpKaWuZCiZi6k1DIX
UtmUlrmQnWYu5KCZK28LRx2XlrlQbMtcKKFlLpTYMhcKrao2/PmnZa6hNxLNXEN5oVHN45a9ugKV
nnOlceIcUhmcWyqbs0514mxUXfWFqrT8bbbpLLT8VSSEU8VIZAh6IpswFZ0q1gGqD9gC9U3ntePK
h7fU6Vdv/0jePq2hkJNWUMDTZ1RlIUGr1ZAGJYie4xlTazVAGVHwu79ShDwoUbTgqYtbazWE0tXq
Nmt012p148S1GjgMzms1hCqPLyZhREWqVyrmNTqusFZDNF2thjiiqgDWWk2zC7Va/cKVmry3VGqI
qVVqolIY1j0Kh8e8m1Mw500K6TildfflloaEtHC0k77urxy0oXChx6LauLM+ce32aB9DWoSH+umo
fQNZddSHnbTWktNeC7Xvz3sVrlA6JavXvAT6/xjE68t9ht+k2n0m8atCFle55OTNj8Yd3dAL/AYT
zWnvUTpi7aNA+ywxRN9e6W4yf4yB8+7mTR+IDksnaeXblwQme97xf/lrz9LFlM+N3OW8KgfgPHpr
P6szjg2TWbPswterq+I4106+0l0L+WrYINAsAJ93Tv6HgZHzJWnz5EI3wXIzJ1rL3QTq2VDnxo27
CR/m/wBCkdGeCmVuZHN0cmVhbQplbmRvYmoKCjEyIDAgb2JqCjIyNTkKZW5kb2JqCgoxNCAwIG9i
ago8PC9MZW5ndGggMTUgMCBSL0ZpbHRlci9GbGF0ZURlY29kZT4+CnN0cmVhbQp4nO1ZS48bNwy+
+1fMucC6EvUGDAP2JlsgtzQL9FD05DYtgk2B5pK/X/IjpRnb400W7SkIFmtLMxQfHx8SZbf10+fN
P5ObHI9SS1uaavTbOn36Y/PLD9PfGz/J36c/N45f0PRx04loerIFsvTJWMi3vvtr8/4HXu22kf9J
OLTG3zmHbWA2LW+zTVpkGhm2qRHzyFm4nqba+EnOeZumWrFUPmuWp0X4njY1CZdC2zLVxIPI7zAo
vOiEYRW1lK4SS9P1NfKDk/HFI5XGD5JpwQ8qi1DtmudHqjMPy6S2YHiavBPEdOZdp/Yus7jOxrsK
FYS/926I9d5v09DHexJOUNT7IJKhv43VrE2fRazHCkBgvBSbLgWgmXRgaXopyBvoC+zNCnXJ7KrT
cmJudeLt6eefEDmf+f8Nx8iH7w7+Nhz8bvN245ibY2qkPlEeCz/yLA5yIjLm5Bsr2D1LvsDlog75
hNWiJvk4G7AhNpPMNGIzs5ncxwVm2gww2QrAZ7xqBGQmpYqmJp1dEbtetcGR0LcxH7WB3Zgnsw5j
5kPNwoHfBK/xwKOA4DEuISN+wD8U8Ifc0GZ9okNwQFMet26BjrttNoPVukLRCHMKmATFTyUrrqpT
R1x1VV+oDeah2XenM08+n8vfff6t+lzSGzs+/3FyHx83VYSWJmwef59+fOByVKfH97/ufOCKk/Z5
58L+Lu3cQYaZ/x4c8ZCyu6fMZSg6IfLR3ftExJ9FyH1wr/aRl927o3J5DS5RhsrB3c98yQV9lVhA
cXUvpK65gzvOlGATXfCZn7f9b49vNq8frwwKiQ1KTvYEGMRuZ+Mf3++c3z9+WFsBPyQnfugQRIXA
7e/qzhWR2zA8eL+/IyhUxWYoH/d3ZeeOeBntHUWl9Ik1PgqE2YzPGCo7HfMCvxPYmDzsmfurfUjG
R9AT6Egsf9h7gQr0thaMmSS5QwhYoNwSo3ilshd8o63R9QKkPFdhEDCUksVEex92/ClEB7OjDWIK
ex/lRQXPipkCQKqHSie/r2q/zNtO3Srefc6LEdv2S7wYse2ee5FgVdf90PUuZi5JJMM8LinqSdXN
8B8rowQnRhKgHgFqsCwhi2eIHlTSwSwnwajsZoHgvwKYLU9M0YXQAneWAhU6VY+1bmM2lbqFz8PM
5ci/DObiuQhdJAtrF1T/eBZPdB6IFktx1nVOgo4vl8ZleCsi8FuUoDFisGWj7+27dKgukxQpeJiD
T5e/Fj2LRq6thL7d28tEvTedj5yPyrzrvdCeXlmeHpX3A17RMqsgxjjEhT9Ze8nrZ72UEm8C55jz
ogMA4X9ClaB0i0kiYRJHlfuyq7PsKjG067pIPWAHNF/l6bUic1H5QlJsrGB0sG8ZpSpS/voyUWUr
jRQvkfQinr6Y6lbqX15Mh9sP61vDMkB6jKP8lAFcs8p+u76aCBQwiz7KdJyVYqyjQH0Xz3YZ2ehg
z1VEyuPiunnH2zGquLpyVX7P1ebdW4ssLXOB366WM0aIa9fYYuckFe3ELsTfDY0ouHOVwoWzpV4J
/EH4BzlfoATxfi+PqmIu33D8oGWx1Hb2XDV+NaiUZZDqMng84AljHMTcgPQhe+lBrIequzBLz0vK
DCofn03t0NLXV3HkTeBW+KqK/6+pLUaV3djDrkOQ0z1eZ/vtIqZ6F/l8Sb6Hkq9qp38Qmc9v7nW3
2G5Ws30cuOJIYdt29NSrwa4M+lmtDDT1+ThijK0F28e84886RH5mpeFWOVmUkgHios+TC4XPm+WV
w8eNbxGdSOEz89P0biyQ9n+0ZhmEAS2YdAtPk81wFnialpTX7aWKnZshERtYCW5unOxuF2ID5Slx
eCoZd0NecvlpCo67Ged1PGhuihsqCZ8+81BeO6Ezupy137WZXIGs0iXpwAZdbAO1C7oYZyreRf0N
bEkECWEDmShHLku72mcLum7q8oomRLe4ewuhjMu3wCeHYE1iCGFx/RaCQ2OI7KA27pIClcUNHEM8
ruAEbm1cdaQNLcZodI0WDbBxsdbY+KNlNrlopU0ja7JNV26+zQK05GabNesh0mjdQ0xKHQu4Gxd2
R+r8kwd/yEWNHBqlgCYeuiYEv9qQeiLANpvBZl2hSCivjpFKUfRUuqKqenW8RVv1g9qg/ll47nTm
x+cvaL57/Nv0+LKIdMxRAmm9cOG5lS0dXxctPLeShfFKwdLnsVOsFSu8sFIVAuCw8hR8swrXrCp/
qVSlIs7qgaszDYZUetim6nA/reGTKgIAYZVqGGGbalqEbarFwjbh5mDeIU42TiNsUysjbFNrGmwa
trgqt7B1YQ5bF5dh63IPW5fnsMV4hK29SUqt4dG5aOAofw0olYtQGxohCE1XBKfZYGOzTWdqs65Q
JJRXxwhSDD1IN1Sh18CbtYUXYIH5ZuG105kPv6ZMfff2t+Tty7IhWmUrHKzHSmERub20pJJWC1Qq
bhSolONqgUqpdYoU1wtUYme1UaBSSqM82XjQWOBedIxZGqISJRYumgXtV3D5fH3413Zp/a6T9Hzf
+/neMYVx0Xe0BksaBVxF3mpnVTm6ugNaXINdXiNTOb97sN5G7q6uewNqEt/Fa7ZSwRG09p5gPrVy
DxZGR0DYRTN+guWTakHqND2sLylX8cZOxEnxH8C+jReYS2Zcsn/RdelAxxOql0U7OTbTlwtkzs7z
Xn9Zta2Q9PdX/J67fqK/3bwgvRx+FFpr0fpBQcnsB3D0SvpjurZnM9UtgUs+Uasejh8X4mLSrk9P
JjHgF3TrCG1WPNJzSfmc0A6qCu0t3YrQ3hGqmNQq4LNZzQuhZ33h2+lfeYkItAplbmRzdHJlYW0K
ZW5kb2JqCgoxNSAwIG9iagoyMTA4CmVuZG9iagoKMTcgMCBvYmoKPDwvTGVuZ3RoIDE4IDAgUi9G
aWx0ZXIvRmxhdGVEZWNvZGU+PgpzdHJlYW0KeJztWUtvGzcQvutX7DlAVHL4BgQBkhMXyC2NgR6K
ntSmRZAUaC75+535ZshdSSvbRdGLERi2yeVwHt88lsN1Wz992/w9ucnxKLW0palGv63T1983P7+a
/tr4SX6+/rFxvEDTl00noumzbZCtn42F/Ne1PzcfX/Fut438S8KhNf6fc9gGZtPyNtukRaaRYZsa
MY+chetpqo2f5Jy3aaoVW+VvzfK0CN/TpibhUmhbppp4EHkNg8KbThhWUUvpKrE03V8jPzgZXzxS
afwgmRb8oLII1a55fqQ687BMaguGp8k7QUxn3nVq7zKL62y8q1BB+Hvvhljv/TYNfbwn4QRFvQ8i
GfrbWM3a9FnEfuwABMZLselSAJpJB5aml4K8gb7A3qxQl8yuOi0n5lYn3p5++hGR841/33GMfPru
4Jfh4A+b9xvH3BxTI/WJ8tj4hWdxkBORMSffWMHuWfIFLhd1yCfsFjXJx9mADbGZZKYRm5nN5D4u
MNNmgMl2AD7jVSMgMylVNDXp7IrY9aoNjoS+jfmoDezGPJl1GDMfahYOvBK8xgOPAoLHuISM+AH/
UMAfckOb9YkOwQFNedy6BTruttkMVusORSPMKWASFD+VrLiqTh1x1VV9oTaYh2bfnc48+Xguf/f5
S/W5pDfe+PzDyX182EBoacLm4bfph3suR3V6+PjLzgeuOMkFd9jnncv8c++Ih5TdHWWuP9Elnvro
7nwicnf712nniw/uzT6mnc7dUUiSe+uicGEO7s4VGZI7gB0LUEYuYwMWq5I3PIH8I+9L+jRAUJbh
gUl+fXi3eftwZVdIbFdyAm63K6pdd3svOyPzPHi/f03Qte5IuOsD1liWWRILiaKZauN3NsYGGxd2
JEEVWdeVyjIEPGMg075HH/JicocQ8ExXZvOymPfa7DMCZnC/v5B/INr7sOO/mJm4Nogp7Is8hzb8
J3ZLscEnNjbuyO95czQkGBP22WOYRrzZzjGle8U0mNazcCyQxAy04qyFCLOYZ810p4XeQEw4XSru
VOWB7MHgyGczFVU0xIYPUneXeiMOyUfbID6/BP9RIDiLvQLBpYUT7OHjzvn9w6e1Hcj1WDzn7kU4
shqh+8KsVNC6guoZ8RnUDiu2zoGoIzVDPQpfxIWdTZ2vsnzsqWDB3zrPt6JPMUcsfHOVFCM+hc3R
pJ57Buv0BitCBd73WKJlWEOMcegOutdUoh5BzFpC9HXplYHeAp90y1mJxFlJivcznZUbdiQuuhfO
ojl9lkn5lK8Wbl0A4gtqTdiztW9CUqvP0/FwyyhVMY7y9rRRVd4hMbTrgggFrmN/VDOOkXimd0T1
UqN6NSsjg/X5sZcDDewDHAa/H2a44D+s9AgiDdM1tAwRik/W6MNgcmS9Dmtxry5C2onDBuhR9lhk
krxj6GjOvuEIhZXiJahF6hQrxwzf7EPqRjgr9XNC9diukm0d/dVcdQG0+qxj0F8tUsAEyV4gGR2u
updJRDdru2aJHwXquVnCvUf4X7OETwliVjqLyCW6nDnxOnFu1wPoHdrI7memTuDG8aoePJU6aggS
xt47PTLp3CJU6H8b58op3qwpPe4q4s5b3NWruLuCfFnbsVjHn+V72LI6W0oPvBdthfSv3zbLDvfL
xnPXHTDLfCj9MDZItzk6gQzCgBO/HE4/TzbDO/TztKS87mZU7Hz2FrGBleCztJN394XYQHlK8K+Q
8eGbu+vERMHx4dl5HQ+am+KGSsKnzzyU14P3GV3O2l7ZTDruVbokB/5BF9tA7YIuxpmKy7y/gS2J
ICFsIBPlyGXpjvpsQddNXd4IhOgWVz0hlHHXE/hcFKwnCSEsbntCcOhDkEjUxtVFoLK48GGIx42P
wK19ko60f8IYfZXRot8yLtaJGX90aCYXnZtpZD2d6cq9nlmADtBss94wRBqdYohJqWMBd+PC7kid
f/LgD7kop0OjFNAzQteE4FcbUk8E2GYz2Kw7FAnl1TFSKYqeSldUVa+Ot2irflAb1D8Lz53O/Pj4
fcB3j79Mjy+LSMccJZDWCxeeW9nS8XXRwnMrWRivFCx9HjvFWrHCgpWqEACHlafgm1W4ZlX5qVKV
ijirB67ONBhS6WGbqsN1qIZPqggAhFWqYYRtqmkRtqkWC9uE++X5DXGycRphm1oZYZta02DTsMXN
rIWtC3PYurgMW5d72Lo8hy3GI2xtJSm1hkfnooGj/DWgVC5CbWiEIDRdEZxmg43NNp2pzbpDkVBe
HSNIMfQg3VCFXgNv1hZegAXmm4XXTmc+fE6Z+u7tl+Tty7IhWmUrHKzHSmERub20pJJWC1QqbhSo
lONqgUqpdYoU1wtUYme1UaBSSqM82XjQWOCetxWUibUoUWLhqq+Q1oYbi7WLwMX13dy7jrtLvcIb
vYH2DaFTo7vtTRWu5W50SaYcXbY8y5b0st2gct6rW8sjd0HXvQE1ie/iNVup4Ahae08wn1q5XQuj
IyC8RTO++PFJtSB1mh7Wl5SreONNxEnxH8C+jReYS2Zcsndp9HHj6s4arH45uoKOJ1Qvi3ZybKYv
F8icnee9fsizVyHp5z58Plw/0d9uXpBeDt8g1lq0flBQMvveil5Jv91qezZT3RK45BO16uH4cSEu
Ju369GQSAz7YWkdos+KRnkvKx4R2UFVob+lWhPaOUMWkVgGfzWpeCD3rC99P/wBVn7LeCmVuZHN0
cmVhbQplbmRvYmoKCjE4IDAgb2JqCjIwMTkKZW5kb2JqCgoyMCAwIG9iago8PC9MZW5ndGggMjEg
MCBSL0ZpbHRlci9GbGF0ZURlY29kZT4+CnN0cmVhbQp4nO1dy45kuXHd11fkWsCU+X4AjQL6NQa0
k9WAF4ZXaUuCMG1A2szvm+ec4E3erMzKHLt6MYXCSNnkvWQ8eYNkRJDlHv3h14d/HNzBjVLu+TEc
WvKP7fDP/3749z8c/ufBH/DfP//64MaLcPj+MBuFwy/WAV1/MRD4V+/+9vCXPzy4xzIeN0EIJYzW
xfnR7vtDyO0xWi3kzFIfJT+6FBdH+XgIqbFHxpuUB6Di0CukiLL3j/VwfAgkuPgMSMmNtsW3xzTL
IYwex61WBkTrEfpjnrBiAMYHwxILsRB7bOOJ0TVgVMACvSmMsnExYJSD8cfygFTKoGe+6YMe61ED
MExItZxw1AYcwt0cy0ZVC6iJ3hbHr/FhZeNQNfGuHpKJYE1pCYvkKOySr+iakhfF0ok4kaYWHR53
Gp0ax0A4/Nu/clD9Ov7/x6H8v7/r/s3r/s8Pf5IhGf+Nj/3Tt6FlYvD4/fZfh3/5eViSdvj2lw+x
PH37+8PXb6PHzkD47gdhObpHGBrf6iBDNd8S7FMEMt8gvhzBtq+VPfIopUFujujjK0SXEwAfH3wd
PVMClEorl+pjnuWh2kQ4qmX2RqkNHAZnMOoJhxhKZm/iLXU8MXqG0CA8o7RikBkHFao33lgesIbh
jNsbKEU9ggsbpOBAjXAEV8db4Q6usyyqAlUreoOH4sXFLIs/q5Fz60GJGCyTlGGhDA17zKJJ0hal
0oI4kHYWvR13WnzZKLzr+y3q+7kh8I19E353hsB/2QyBH2YgHQBj9IkNZNaq2SI22CjV4rBteZTD
IdY+6rWC3VjzYLHWMkpxIKkVdjBWEFabJ7ORVq02rFhiaYDS8GvlHii4WYMdth69PxaD1VwEJOJo
rhAHMDcHGy6KmqdwjdLmYVnFQfNxtBVvKg9YHf/am16tfXIQxoSUHGYp4UgO1lS4k2ssg6bkMaBF
a/LeOFBJnLFMjq0tJSEYU0aCLukJK2QqakzSvUr6pHvq5KSt4053L3/+71p+O1p+/tHHRsitnH/0
sV7+6H1wIDtlDgc/lg3Fan4IbjCRysHTfqUEgXmJJ7tRwr8QgB+2K+WsecBBACn30bfjJxXoyoqF
4lJlTAbxYM0r1mwEU2m4Abo5gia6hinCyBimn4SIvMHpmAJE9pgIhqEXQywPSCGxv97g13rQvG6w
YmIfYhmrwT6xj1VinzRxNWuUJhh340BlY23WwLP1oCgM0hSScEh4wg2BiiaJWbRC+OJAKlmUddyp
7saU/67kt6LkC/O8Hz2LezbLf94++H8cYPh+HSuPorUONoOkCK6EPOAC6gYzpMqdCOzZaBhgqXPH
7y+HEBu7OdWWls9HoCEdi7ixl4lY9Iz5xmF5VwpUeYY2+optUu1sGAbCOmpCFF1jN89ua8tLLo/o
ucor0MyAxE2aar/Yli20znVTTI6bul1NLXdQbkypPwTfha1dd2wBWay6/o8PYzXYn34qH/zHp/Hz
6ek/v/3xwk5vbKK5oTQ6Q1nwWc0o21O942gH5Yb74YfguyCX1LjlP5fL+g3sB0ijX8AI26nhTEUp
5Oe1qbAFyq0114/Ad2H2L9gwXRwg0bcn7z+4ZWzs1wGdTgwjUTu1icpqUzt7za1a3UG5tQv9Efgu
7YIiHSrPx0b17sqSiOZ9I21MQScUVjNi9oTumNhBuSGKH4LvgijGJHN5dLgvw2y4L75eGRwtb+Tl
smBRZZKzJ3XHRjt9zi9J4nXxPJdAvTwSvlyxEjLI9O5tZp21zUQlELZ9w/uaWu6g3DWNvDK+q9NI
wGLg/zGNTDr1QU46VTPK9lTvONpBuWsaeWV8V6eRZ3K5NY0YYTs1nKnIDPm+NhW2QLlrGnllfFen
kUsD5M5pxEg0C2WorDa1s9fcqtUdlLumkVfGd3UauTA2bk0jkzTZqUmaakbMntAdEzsod00jr4zv
6jRyYXTcM40YebLohkWVSc6e1B0b7fQ535pGXg/P5Wnk+Ui4Gl+hRH3Ny/Su2obWpXVC39Ws5Q7K
PePgtfFdGgfwyOvDOJ9GOIl0//HqHNLyRiG1MhFJRZOiPbU7TjYAN4fCK+K5MBSw9X0ug6tThkIE
m3JWkZ+pw+arXW1SskK5MXf+EHwXBkOvDCBdGAwXpozpG4gJvSp9pmNCq1i51Zz4Re59A7XTNW0b
qJLYkIsfBlRr9iyfWplYkEYBC4TvsFR6pPqwXkMUJdMnhZovcDon+hN88fQSyT3sc6c3CUFZn+ng
bfBI+VzpcQIdxwef5b+izylnepY4LlTuGAHHrcZolHp0eH0MVi+K6whLbxN3F4WgKjvHsLPozQ5R
J/GBMmgHhyoPSKVvNUbb1J5B5w1STfCpCUcVfWhNz9WkqFbWSKvc1+LBysadauJbPSQPwZqSEg7J
ULglW1K1Sb36TRt909mqv+NOmzfs4bve37DeL5gipkgAcz6boNuyUNvMQnTOMj24u+iN+R2ohY5J
AuUx33f6LSNMy3HUIn2aY1HdPZ+DMe2rSszMH+mPymqR6yIy46TM8sxFsVqw7S2yVEC2QUqFLBuO
sTvxE3MSfaQpg5HjpJahaOMio5/xx/JxcBu2GnyxyXpERqcmrOia4YhOFAJ39I5lUYV9ZjR6tecU
H7MsDq1G3q0HZWKwKCvDQRkScwyTHpO3UUpNGAdB1J10d9xp8sZG6l3nb1Tnl7wdmXldz81Bv2QO
QmzM82DoIxYrI1oybGoegyIinpOLg/gjkOfCNK3QmauCtyE0lpNyR4KyWIptOpFrUrdyp+WzWmXy
l9ozBmWQaiazhqPCAhruKupIE1c/x0krU9DIQfMHctVITWIODp4lYLN2CSHnDUJCVMhgc4NkOBMz
VyY1qbFGOpMoI/0qT86sRp7VA5IQpCkh4ZDshFsyFVWStaiFBsSB6WVq67ho7saS+F3Db0LDFz71
CDoAcf+hf7w475PJ6ru2FMptYQ35KGMbEdAwkskalOAVmSZWQ2BuC1iqgdklBTamhkwysT1BrTLP
BQKoAdkrVo4ey6utRguoHjFPSLSXgEQcsqTCHUmhqEpmKUUvxWd8JAjaOGQZmTV1q2GjFGaPMVA2
SA3LMcPRRB9xt8yyUdUKa4PaVkgtebCycaea+FZ7yUOQpqSEQzIUbskWNE2Zi1ZpQzyYlk76O+60
eWPuf9f7G9b7BWc2UwgG5jOj8OmiUWA+motcF0bkcaoSkdIRmakd00FJDIPEwNULenCRQgva2VI5
5LbowXIQMqAXxYrJFoOsKLzF1rR5hBGc1lyEHZCHKnyBBI3/MWfkaLSFTDmB4oC9ljhhERlsEDQr
ib3ZOjFdz6CkapATSSI+rQaNDi4TRV8mSaTaiuLGKkyCVWvwPteUoIOwnXZwlJxoMHmKNkpZFEv2
J50c18rLjr93Tf6+NHnhw01s0O7cxnemgJiDsG75I5RpKF6SDsVSUQPzKkQlVjQFfFNbOHuRp84R
LY7SbbDYO4uBxs4qTPHWcZJiMGqVxSTsKgWyldO4C/R+mMYDU9JEc9vkpKJpXJWkwDdaJ6WJCEqq
BjmJICaqcrdodFCHoC6LIC4fVRQnVuGyi23Jt2CYPASbcgI+yk5UmExFHSW9pCIsejmuSroxSb9r
83enzStf8MB413KcwGZou26Be8nUN5O0pn2Tf5Cx5o4qTIsdQtr0HfK02NhylVns9FyqEv202GP3
MC12iJkuUMGOdVpsZD9G0hH7yWJju2IWW0fexIvWVqZxZYkq4ug2WRsUaICQpRXik7aMDmmR9Em3
pFpF48YqdVps8S4olIhgU07AF9w27kymaUZAzWab/E96Oa5Kuuf7fdfm70mb177fEO/znBHcjDRG
nf7K02YjHEBZey7lTecKHlAvvvZps33zJ5uNkKLZbI+wvAqQ6XFW+rTYvlNshNF1BEywOx2WxNi5
xhp09HKy2Yhems1WKoh46e1ks1WhVNWa0p5QUjXI1IvwUVuTDmpR9FG3otqK4sYqWRoX34Jh8hBs
yiltYRhSYTIVdVWnU7Zg96KX46qkO77gd23+rrR55QseGK/ufc+UXhI9IMnsNo4eVN/oqaDnwdGP
X3D6uTSexMo4XFFK53iAdApdgJF7e5yTLtQbWuVeuOJJdGsCRsh0HaasLVTEfiH7znQkGE0d/Cw4
nEF+PZ2GKTcewdAZliEj4kpUOM6ucHNEQ9qH3gJMYIO5lvVtkecvoITGfhkrsO5pST2tb28MwFJx
3Phk/voAZeWogyKNjksGNJlSmlu1wTJk4+1MtwcViItgMoGHA0cYsJgCraXZ+XCeIqvOW7ykD5kn
bui6eUYwoJArAT+LGzLnObro6IE6aey40986IBbntwPFucNZi8O/mefPIwOufZQ7g9SMMflGvJ5e
IZx+z5TAjKX4oJP3GMvek+vMAzGe5/Yzeun4TimVR3kIlatVHWopFQdx/JCDPFXSaWn8hnMaJQWS
nT1luJlSLo0paI5xsea5esBKtdRsjmLSWd0YYVjiljLvBEC0LJu5SdQNd+wW6ePI3WJNtDiKWQXH
Lb00m2ZUi/GqI+NlFSdkuP3FhR7cQ3RO8N0O/bbIEZK4LofLnt9CjjZyNP4ZFmjduMk9MCPnpLHj
Tn9Tw/tssxK3wCYyCbzVfNY1CzzNxDNJJWq34FOnSodaUnnUdQg4/STxOCqGIpFBoi2S2KycFfab
NZoc9cj8gAWpeMXvhYM7D2IusJdGUekacqK1+oNxwKgDOaveDEHhYFIOAdIL2ZqRig1KrRN65dUK
wtk4UCY13IkZnU2DWCZTZeNMNfGsHpKFYElGwiHZAbMkKoqmpEWpdCAOpJtNZ8dFf7eyWt71/Hb0
fCGLJVcLtO+mbud3U/cS+2LWCxYipwS8oAS8n59+Ch/cx6ef/Ac3LBT/zfwtrvLfxhZ605+ssUPK
Hp58fvopz7eBv8vzEPDrMzt4/9Q+BP80m7Nurc9AhtnHQH7ewIgEn5ZegiM6wvYcDUGBf/LJuo7J
pxC4E9Ph1ExdRCEep8lSHG8uJ6nGGG1U8uhi6Bp/5qTFuGTyA0MXmNiU/KCRXJgWwfQMHl2XZ7Xw
4DqmFS6VeHTd0iW4hLQyEz62RIpeD2pfmb0lSNXZIXfiqI67WuKurnN9zMP8notNo7f6yDcMrHgs
EsShygPWWNrY8+QYFmN7xmg3SKmecCTmWwp3ZjBqUpUja6Q3M5EDXFjJuFNNfLO9yYOQNkkRh8mQ
uE22pGqTOuk1fcQ6tbTo77jT5o29z7ve37DeL+ySgpaY53kDJfx8OYs7Od7UNAZH4tF2lKNysZh2
iRscIlfWuq1Ca2vuVRtX/rwZAjHRzFuiuEdqnEJ8PuiADtbfcZZDsOiqaoXR1fg4b6gySHZ3leHg
rVaGO2K3YlTNLC3RywncuOBqnrzZuj45TJj23GOdbe29LRoIKflmGBKjtcKcwlx80G/GQyOiVseR
xMUsiz+rkXPr4fOEZHIyHJQgMVOuRpFJ3GilLoyHoaGpteOmv5fNwLuW346WL3z0nfLzoG9/dOPa
R1/pxLDMscRTBqqlQkctnRmpMByjdSfvZWh0E0S4LbCpK5lOB93EwBXsQ8q8i6HC8qUc6R4hu1bu
UoBqHBDWo+mGCcLqCu4aFl4hY9iZz210dW3qRXGxezncFB05NOHVpoHOGzP8bMshuEFpdHwIvu6j
El4OwY0iXldptPbC3DTyoPLkzmryc7OH5CFYU1LCIhkKu2TbZk4ZpU6KTR/kw/S0aPC40+cNQ/Cu
+Tet+efGIRVlO4LavXHoV1ynuIktG/7vD5mOT9wjMyigsygxWSvRPZhqppeZ5z+Yg5noLsPJCTgy
qUe78DH5QqcouIy98V64zoQo8BbJdcyVoyjRGR7MBYVcE6aE+2orRuqYzkhlbpTcmYGBPTgnCyVT
qy/dYHD4dmZ/YE2ZH5UEDvqQvFW4pqxM6wJmpX7pasxIlxucx5gOPVebjpMQV812xmSYfzrwcPHQ
mAZ4814qmsDoA9+u2+TZGI5WZsL6QI7lpMucZHKmpCL4yQzAZcbeclCCe2aoLqu/AnR08a6aO+70
eGXiUFCtIBh/dtRtLJzdl6fYx17VfRo70vLBfXVp7EW5b728yUzwTTd8lMO0MEtOtSSx6Fax7ciN
AoyZR3EweDjMOhSb6FeEkCjYwksE6VNOTM3NTM2Z5aYZVDXdi6YenA8FC554fS7MAwrMVBi4c8j2
eQ3hMbvvaNRmbjHEBQQJXrqV8Anzokc95wCw9rxZbULKLhqGrMsRiTc7XvJoFGXHO4lIa6aHVjxY
2bibNV4oqR6Uh2BNSQmLZAjcJlnd9jYlLkMnXZCLqaNZOi56vDGZvOv7Der7whTSAo3N+aby8xUH
XmQoK4c548TNf5fpyopwigVX6LP6sp6lfQ4lgFVCGTSMBy85DiNDPrTgZ37Dz8Drp6eQfkG54GjP
iirR+/rUPvj49FMDXaNxzPDW0bm28wXKAxcDPHCfCEhOv+mTjL6sfj1D9tW6t80FGNLiAlSjujgn
5fmbQHeE98XJ+PmpOFz98qIgOWX+JkF6TH8vOGCNntU9mRaeIVojcPGLWvNy8oIWe7R5a+eLdgIw
VFIndDwOU6xhSmIR5FSP+UanO3UHe3W9fjx3BNuT8MzN7FY/cz5n9zTEVn4XV7RU/mWwHhuhha8n
MUwdL+NyYfIrx+T58DFCl5cX9LCwPSUCz7GRqr5zTJ05q4k7FjQJP788vHgy97cMr75eXqTRFRow
GWH15HWPKznkbfO+f9rptriyldiW48ZYWuQTCtYz63jIu+Hz+TSkjBr+xnhSyDrqw/POBvCaNQhn
oYR7YhknXZ4CD+dDfMF9UrKbEpSAbAnH8VcQb7gSFTF5e8l7lYPJdgJfLdZk8KWxwm3OXvMToUV2
pHaTzdflc3Qfntkc6XIdGc8COztwvyFstJOD9Q/xyddN2cu3eDZcXhJA3WJhd34rNZzb4WV5TuRu
GXQnCV0wR3H3rG/imcpsy4R4Z0DMfTiNqU0d2+w0I1RrnKyeyfnmV/OSNJlI81ukmduyFTbLs85r
X+dAOnG12eXTVztHkns+lPI2FM+G0vmcMI1B+BI7ZfV1N5B38b8rixah+7jJjSO0XdHIycK7k/kL
22jyq2maulonlxd3fwr1zHMqurHMDkXY/WUxKnChC77OanZ8YoVyzx1zr43v2h1zkcGj//sdcxud
PDy70amaUbanesfRDso9d8y9Nr5rd8w9l8uNO+a2g0yrGs5UJLf6WW0qbIFyzx1zr43v2h1zFwfI
fXfMTRJ1i9FEZbWpnb3mVq3uoNxzx9xr47t2x9ylsXHjjrmNNB8XFFYzYvaE7pjYQbnnbrHXxnft
jrlLo+OOO+Ymebzja2JRZZKzJ3XHRjt9zjcuFntFPFcuFnvZTsxbtHyU58gzV9vzAHxmhuXZLVq+
6q+NJDqfcOMQXDKR2cNIYvX0M0tfp5Y2Is68G/jWTy6DcNqLYMZzHRMlpl7XxpSovSgTbjDVY1pN
mCMLFjVaR456H/2WZmOjrIYEMBZOADymZYD9ecynmrqD+qFq7z6HMBprHcetGifoAQaoPLwo8FIE
eCm8UAXPf4TC6I5sM1p6SDy9sDq3hLDTrt9kgYVN4EYdK4rAbQMFQhZFsi+s/GYpGedlXeRt47Tr
Vhdkon7HRfdMvOgcCxycmRkW3y3bHf76urzM8KF95yUNgafA155MBf/Ok2o6bN74sugyqfEtIEf2
MS2vaqGrUsRE3vxwetkdA2I8Y3CIFWkhlZm7eDmU8qis7jbeInbdeOJc9PjgxpQDoCkgIxY5z0Fv
ov7CRiUfyBAvltzCt5nH95iJ/h0+0EN18745T6d/ZBDmu3n/lLSCt7gZLyPwMt5l5sEXu4Tqz3YB
SKR3dbwNzA5mpjff5mQ589/xp34e518v47uGd7z/7pB5kUYJ80r+SH/n9rYoIp7m26S8/PlW14s0
wxmZRa1bBba3ad66D6kGnvTvfJvpS40G+fmKsU48Dzgy2KwWAgNFpT3qT0cp14EXeVmOQTQfWuTy
IB66jinp7yMUXaVWGNbj6KKLWKNQSUc2XpVNxV0LOCCUwpygLfW8VmajMlpEV64Iqr4y5UCk1gji
xYJGoZhTGdlLbatF/hUm9UixMytKsHD3WDcscDN7w56jsmdFF6JR3gg28TfdgcLyxiBr4pw9TCCE
NSUlLMnc8IwUOp0g5bELE7ooljrEidS0KvC4U+ece/90+F+I336VCmVuZHN0cmVhbQplbmRvYmoK
CjIxIDAgb2JqCjYxNjMKZW5kb2JqCgoyMyAwIG9iago8PC9MZW5ndGggMjQgMCBSL0ZpbHRlci9G
bGF0ZURlY29kZT4+CnN0cmVhbQp4nO1dy45kuXHd11fkWsCU+X4AjQL6aUA7WQ14YXiVtmwI0wak
jX7fPOcEb/JmZVbm2NWLKRRk15B5yXiSQTIiyHaP/vCPh78d3MGNUu75MRxa8o/t8Pf/fPjXPxz+
58Ef8L+//9eDGx/C4cfDbBQOv1oHdP3VQOC/+vbfD3/5w4N7LOPnJgihhNG6OD/a/XgIuT1Gq4Wc
Weqj5EeX4uIoHw8hNfbI+JLyAFQceoUUUfb+sR6OD4EEF58BKbnRtvj2mGY5hNHjuNXKgGg9Qn/M
E1YMwPhgWGIhFmKPbfxidA0YFbBAbwqjbFwMGOVg/LE8IJUy6Jlf+qDHetQADBNSLScctQGHcDfH
slHVAmqit8Xx1/iwsnGomnhXD8lEsKa0hEVyFHbJV3RNyYti6UScSFOLDo87jU6NYyAc/uWfOaj+
Mf7/j0P5f33X/ZvX/Z8f/iRDMv43Jvun70PLxODx9/t/HP7p27Ak7fD9Lx9iefr+14ev30ePnYHw
3Q/CcnSPMDS+1UGGar4l2KcIZL5BfDmCbV8re+RRSoPcHNHHV4guJwA+Pvg6eqYEKJVWLtXHPMtD
tYlwVMvsjVIbOAzOYNQTDjGUzN7EW+r4xegZQoPwjNKKQWYcVKjeeGN5wBqGM25foBT1CC5skIID
NcIRXB1fhTu4zrKoClSt6A0eihcXsyz+rEbOrQclYrBMUoaFMjTsMYsmSVuUSgviQNpZ9HbcafFl
o/Cu77eo7+eGwDf2Tfi7MwT+y2YI/DAD6QAYo09sILNWrRaxwUapFodty6McDrH2Ua8V7MaaB4u1
llGKA0mtsIOxgrDaPJmNtGq1YccSSwOUhr9W7oGCmzXYYevR+2MxWM1FQCKO5gpxAHNzsOGiqHkK
1yhtHpZVHDQfR1vxpvKA1fFf+9KrtU8OwpiQksMqJRzJwZoKd3KNZdCUPAa0aE3eGwcqiTOWybG1
pSQEY8pI0CU9YYVMRY1JuldJn3RPnZy0ddzp7uXp/67lt6Pl55M+NkJu5XzSx3p50vvgQHbKHA5+
bBuK1fwQ3GAilYOn/UoJAvMST3ajhP9CAH7YrpSz1gEHAaTcR9+OP6lAV1YsFJcqYzGIB2tesWcj
mErDDdDNETTRNSwRRsYw/SRE5A1OxxIgssdCMAy9GGJ5QAqJ/fUFf60HzesGKyb2IZaxG+wT+9gl
9kkTd7NGaYJxNw5UNtZmDTxbD4rCIE0hCYeEJ9wQqGiSmEUrhC8OpJJFWced6m4s+e9KfitKvrDO
+9GzuGer/Odtwv/tAMP3j7HzKNrr4DBIiuBKyAMuoG4wQ6o8icCejYYBljp3/P31EGJjN6fa0vL5
CDSkYxM3zjIRm56x3jhs70qBKs/QRl9xTKqdDcNAWEdNiKJr7ObZbW15yeURPXd5BZoZkHhIU+1X
O7KF1rlvisnxULerqeUOyo0l9afgu3C0644tIItV1//2YewG+9Mv5YP/+DT+fHr69+9/vHDSG4do
HiiNzlAWfFYzyvZU7zjaQbnhfvgp+C7IJTUe+c/lss6B/QBp9AsYYTs1nKkohfy8NhW2QLm15/oZ
+C6s/gUHposDJPr25P0Ht4yN/T6g04lhJOqkNlFZbWpnr7lVqzsot06hPwPfpVNQpEPl+dio3l3Z
EtG8b6SNJeiEwmpGzJ7QHRM7KDdE8VPwXRBF0Li7JIpv/sr+sOWNslwWBKpMSvZU7jhop5n8khBe
F89z5mujSbnfRMga07W32XTWNvuUQNo2gfc1tdxBuWsNeWV8V9eQgJ3A/2MNmXRqNk46VTPK9lTv
ONpBuWsNeWV8V9eQZ3K5tYYYYTs1nKnIrPi+NhW2QLlrDXllfFfXkEsD5M41xEg082SorDa1s9fc
qtUdlLvWkFfGd3UNuTA2bq0hkzRZqkmaakbMntAdEzsod60hr4zv6hpyURQvriFGmcy5IVBlUrKn
csdBO83kW2vI6+G5tobcbyIkTl/zsrCrtiF2aV3KdzVruYNyzyB4bXyXB8FowVlxvoZwBen+49UF
pOWNQuplIpKSJkV7anecbABuDoZXxHNlMDyXwdXBoODAppxV5GfqsMVqV5uUrFBuLJw/Bd+FwdAr
Q0cXBsOF9WJ6BWJCr0pv6VjNKjZuNSfOyb1XoHY6pe3oVBIbcufDUGrNnuVTKxMLEihggzAPS6Uv
qo+FbYiiZHqjUPMF7uZET4Ivnv4hOYZ97vQjIRzrM127Db4onyt9TaDj+OCzPFf0NuVMnxLHhcod
I+C41RiHUo8Of4/B6kURHWHpbeLuohBUZecYcBa92SHeJD5QBu3gUOUBqfStxjib2jPcvEGqCd40
4aiiD63ps5oU1coaaZXjWjxY2bhTTXyrh+QhWFNSwiEZCrdkS6o2qVe/aaNvOlv1d9xp84Y9fNf7
G9b7BVPE5AhgzmfBj7ZsTDazEJ2zHA8eLXpjZgdqoWORQHls+zo9lhGm5Thqkd7MsQfqnr+DMR2q
SszMHOmPymeR0yIy16TM8sxCsVqw0y3yU0C2QUqFLBuOcTTxE3MSfaQpg5HjpJZBaOMio5/xx/Jx
cBu2GrywyXpExqUmrOia4YhOFAJ39I5lUYVDZjR6deAUH7MsDq1G3q0HZWKwKCvDQRkScwyTHpO3
UUpNGAdB1J10d9xp8sYp6l3nb1Tnl1wdmRldz81Bv2QOQmzM8GDQIxYrI04ybGoegyIikpOLg/gj
kOfCBK3QmaWCryE0lpOyRoLyV4qdOJFlUrdyp+WzWmXal9oz+mSQaiazhqPCAhpuHUZEE3c/x0kr
k8/IQfMHctVITWL2DX5LwGbtEoLNG4SEeJDB5hHJcCbmrExqUmONdCZRRvpVnpxZjTyrByQhSFNC
wiHZCbdkKqoka1ELDYgD08vU1nHR3I0t8buG34SGL0z1CDoAcT/RP15c98lk9V1HCmW1sIZMlHGM
CGgYyWQNSu2KTBCrITCrBSzVwLySAhtTQyaZOJ6gVpnhAgHUgLwVK0eP7dVWowVUj5gnJNpLQCIO
WVLhjqRQVCWzlKKX4jM+EgRtHLKMnJq61XBQCrPHGCgbpIbtmOFooo+4W2bZqGqFtUFtK6SWPFjZ
uFNNfKu95CFIU1LCIRkKt2QLmqbMRau0IR5MSyf9HXfavLH2v+v9Dev9giebyQMD85lR+HTRKDAT
zUXuCyMyOFWJSOaIzNGO6aD0hUFi4O4FPbhJoQXtbKnscdv0YDsIGdCLYsVkm0FWFN1ia9o8wghO
ey7CDshAFb5Agsb/MVvkaLSFTDmB4oCzljhhEblrEDQrib3ZOjFRz6CkapATSSI+7QaNDm4TRV8m
SaTaiuLGKkx/VWvwPveUoIOwnU5wlJxoMHmKNkpZFEv2J50c18rLjr93Tf6+NHlh4iY2aHce4zuT
P8xBWLfMEco0FC9Jh2JJqIExcFGJHU0B39QWbl3kqXOEiqN0GyzqzmKgsbMKk7t1kaQYjFplMQm7
SoFs5TTuAr0fpvHAZDTR3DY5qWgaVyUp7o3WSQkigpKqQU4iiCmqPC0aHdQhqMsiiNtHFcWJVbjt
YlvyLRgmD8GmnICPshMVJlNRR0kvSQiLXo6rkm4s0u/a/N1p88oMHhjv2o4T2Ixr1y1qL5n6ZpLW
sm/yDzLWPFGFabFDSJu+Q54WG0euMoudnktVop8We5wepsUOMdMFKtixTouNvMdIOmI/WWwcV8xi
67KbeNHeyjSu/FDFHN0ma4MCDRCytEJ80pbRIS2SPumWVKto3FilTost3gWFEhFsygn4gtvGnck0
zRio2WyT/0kvx1VJ98zfd23+nrR5bf6GeJ/njOBmpDHq3leeNhvhAMracytvOlfwgHrxtU+b7Zs/
2WyEFM1mewTmVYBMj7PSp8X2nWIjjK7LX4Ld6bAkxs491qCjl5PNRvTSbLbyQMRLbyebrQqlqtaU
9oSSqkGmXoSP2pp0UIuij7oV1VYUN1bJ0rj4FgyTh2BTTmkLw5AKk6moq7qXsgW7F70cVyXdMYPf
tfm70uaVGTwwXj37nim9JHpAktltXDqovtFTQc+Dox+/4N5zabyDlXGtopTO8QDpFLoAI8/2uCFd
qDe0yr1wx5Po1gSMkOk6TFlHqIjzQvaduUgwmrryWXAtg/x6Og1Tbrx8odsrQ0bElahw3Frh4YiG
tA+9BZjABnMt69sib15ACY39MnZg3dOSelrf3hiApeJ48Mn86wOUlaOuiDQ6LhnQZD5pbtUGy5CN
t9vcHlQgLoLFBB4OXF7AZgq0lmY3w3l/rDpv8ZI+ZJ54oOvmGcGAQq4E/CxuyJw36KKjB+qkseNO
f+uAWJzfDhTnDmctrv1m3jyPDLj2Ue4MUjPG5BvxenqFcO89UwIzluKD7txjLHtPrjOvwnje2M/o
pYs7pVRe4iFU7lZ1naVUXMHxQw7yVEmnpXEO5zRKCiQ7+5XhZkq5NOADL55SxO4BO9VSszmKSWd1
Y4Rhi1vKfA0A0bJs5iZRNzyxW6SPI3eLNdHiKGYVHI/00myaUS3Gq46Ml1XcjeHxF0958AzRucB3
u+7bIkdI4r4cLnvOhRxt5Gj8MyzQunGTe2BGzkljx53+pob32WYlboFNZBJ4q/msBxZ4j4m3kUrU
acGnTpUOtaTyqIcQcO9J4nFUDEUig0RbJLFZOSvsN2s0OeqROYEFqXjF74WDJw9iLrCXRlHpGnKi
tfqDccCoAzmr3gxB4WBSDgESDNmakYoNSq0TeuWjCsLZOFAmNTyJGZ1Ng1gmU2XjTDXxrB6ShWBJ
RsIh2QGzJCqKpqRFqXQgDqSbTWfHRX+3slre9fx29HwhiyVXC7Tvlm7nd0v3Evti1gs2IqcEvKAE
vG9Pv4QP7uPTL/6DGxaK/838W1zlfxtb6Et/ssYOKXv45fPTL3l+Dfy7/B4C/vrMDt4/tQ/BP83m
rFvrM5Bh9jGQnzcwIsGnpZfgiI6w/Y6GoMA/+WRdx+JTCNyJ6XBqpi6iED+nyVIcXy4nqcYYbVTy
0mLoGn/mpMW4ZPIDQxdY2JT8oJFcmBbB9AxeWpdntfDKOpYVbpV4ad3SJbiFtDITPrZEil4Pal+Z
vSVI1dn1duKojqda4q6uc3/Ma/yem02jt/rILwyseGwSxKHKA9bY2tjvyTEsxvaM0W6QUj3hSMy3
FO7MYNSkKkfWSG9mIge4sJJxp5r4ZnuTByFtkiIOkyFxm2xJ1SZ10mv6iHVqadHfcafNG2efd72/
Yb1fOCUFbTHP8wZK+HY5izs5vtE0BkfipXaUo3KxmHaJtxsid9Z6p0J7a55VG3f+fBMCMdHM96F4
RmpcQnw+6HYO9t9xlkOw6KpqhdHV+DjfpjJI9mqV4eB7VoY74rRiVM0sLdHLBdy44G6evNm+Pjks
mPa7xz7b2nvbNBBS8s0wJEZrhTmFufmg3yxwaSW1uoskLmZZ/FmNnFsPnyckk5PhoASJmXI1ikzi
Rit1YTwMDU2tHTf9vWwG3rX8drR8YdJ3ys+Dvv3VjWuTvtKJYZljibcMVEuFjlo6M1JhOEb7Tr7I
0OgmiHBb4FBXMp0OeoOBO9iHlPkKQ4XlSznSPUJ2rdylANU4IKxH09sShNUV3DUsfDzGsDOf2+jq
OtSL4mIvcrgpOnJowqtNA51vZfjZlkNwg9Lo+BB8vUQlvByCG0V8qNJo7YW5aeRB5cmd1eTnZg/J
Q7CmpIRFMhR2ybbNnDJKnRSbPsiH6WnR4HGnzxuG4F3zb1rzz41DKsp2BLV749CvuE7xBls2/D8e
Mh2feEFmUEBnUWKyVqJ7MNVMLzPvfzAHM9FdhpsTcGRSj/bUY/KFTlFwGXvji3CdCVHgLZLrmCtH
UaIzPJgLCrkmTAn31XaM1DGdkcrcKLkzAwNncC4WSqZWX7rB4PDtzP7AnjI/Kgkc9CF5q3BPWZnW
BcxK/dKjmJEuNziPsRx67jYdFyHumu2OyTD/dODhyaGxDPDNvVS0gNEHvj20ybsxHK3MhPWBHMtJ
l7nI5ExJRfCTGYDLjL3loAT3zFBdVn8F6OjiXTV33OnxysKhoFpBMP7sqtvYOLsvT7GPs6r7NE6k
5YP76tI4i/LcevmQmeCbbpiUw7QwS061JLHoPbHtyo0CjJlXcTB4OMw6FJvoV4SQKNjC5wPpU05M
zc1MzZnlphVUNb2Iph5cDwULnnhNF+YBBWYqDNw5ZJteQ3jM7jsatZlHDHEBQYKXbiVMYT7xqN85
AKw931SbkLKLhiHrWUTizY7POxpF2fE1ItKa6aEVD1Y27maNT0mqB+UhWFNSwiIZArdJVu+8TYnL
0EkX5GLqaJaOix5vLCbv+n6D+r6whLRAY3N+qPx8xYEXGcrKYa44cfPfZbqyIpxiwRX6rL6sd2mf
QwlglVAGDeOHlxyHkSEfWvAzv+Fn4PXTU0i/oFxwtGdFleh9fWoffHz6pYGu0ThmeOvoXNv5AuWB
iwEeuE8EJKff9ElGX1a/niH7at3b5gIMaXEBqlFdnJPy/E2gO8L74mT8/FQcHkF9UZBcMn+TID2W
vxccsEbP6p5MC88QrRG4+EWteTl5QYv9tHlr54d2AjBUUid0/BymWMOUxCLIqR7zjU536g726nr9
eO4Itl/CMzezW/3M+Zzd0xBb+V1c0VL5l8F6bIQWvp7EMHW8jMuFya8ck+fDxwhdPl7Qw8L2lAg8
x0aq+s4xdeasJu5Y0CR8e3l48WbubxlefX25SKMrNGAywurJ6x5Xcsjb5n3/tNNtceYy/yRfe170
W1bNb975TcDRGE+LJz8UbHum/MI2Bk7ud5v2aYPpLB4R45mNCZt2LgCwGIbhjtBOmTwvc/7Tws69
w/I0uE1+57NiYwwRh7yFEQwq5+kywymSzeSFaSyvWb2XhgxPO2cDYE+bwiGbzV3ZXxn6ssjfQigX
rPvaaErNNL8MuKmha1LfhprmzWoozuX9IdQ5yV8SQ90CY3dOnBrOjfKyVyenbhlTJxN9wTbF3W8y
pJttcDaaym+Kjrl1vGsCLfGwGa5ag2b1ROc03+eTYj+0XpIms2p+izRzW87FNgrXRe7rnJXLLC5X
56N7Ho7M27xeFrjn0ciTKQpfYqesvu7s3S4YeGUHI3QfF2MSoibwBY2czL1bjdwcTdPmfVpt27rS
vHgUVNxnXlrR22V2Q8JeMotRUQw99XVWs7sUK5R7Xpt7bXzXXpuLjCT931+b2+jkTdqNTtWMsj3V
O452UO55be618V17be65XG68NrfdalrVcKYi+djPalNhC5R7Xpt7bXzXXpu7OEDue21ukqgnjSYq
q03t7DW3anUH5Z7X5l4b37XX5i6NjRuvzW2k+bigsJoRsyd0x8QOyj0Pjb02vmuvzV0WxUuvzU3K
+NbXRKDKpGRP5Y6DdprJNx4Ye0U8Vx4Ye9lEzNe0fJQHyTNn2/MifGam5dlrWr7q3xtJdELh5SG4
ZiKziJHM6ulvlqpOLW0wnHk5MM1ProNwOpNgsXMdayRWXdfGaqgzKTenWOWxoiYsjwX7GaUhjXof
/ZZm48CshgQw9kwAPFZkgP02llKt2kH9ULVvn0MYjbWF49aTa/MAA1SeJ40v+ByzQGAXzP8IhdEd
2Wa09JB4emF7PvZacFWfTv8mC7FWyNCewEFJ4VmADp3Y6DV+8tPhQ7mklc/P4kKywuaHIKM1Kusu
bxutXW+8IC/1Bx68ZxpG54jgEM3Mt/hhue/w3tflY4ZH7QefbAi8E772ZGL4D95b09Xzxo9FT0uN
GYGM2ce0fKqFjksRE/kOxOljdwyP8cbBIVYkiVTm8eLjUM2jcrzb+IpIduP9c9EzLMRYcwA0BeTH
IgM66EvUv7RRyQfyxYuluvBr5mU+5qX/gEf0UN18fc4zBBAZkvlhvkClsOAr3snLCMOMb5lZ8cWe
pPqzPQcS6WsdXwNzhZn3za85WQb9D/yTP4/zXzHjt4ZvfA3vkPmsRgnzaf5I7+f2tSg+nubXpCz9
+VWPjTTDGZlTrTcGtq9pvr4PqQbe++/8mulZjQb5+ZaxTjwPuEDYrBYCw0alPeqfkFLmA5/1soyD
aB61yP1BPHRdWtK/k1D0sFphkI+jiw5jjUKlINl4VW4Vjy3ggFAKM4S2RPRamZvK2BEduyKo+soE
BJFaI4gXCxqFYk5l5DK1rRb5rzGpR4qdOVKChZfIumGB09kb9hyVSyu6EJvyRrCJv+lFFJY3BlkT
5+xhAiGsKSlhSeaUZ9zQ6T4pL2GY0EWx1CFOpKZVgcedOufi+6fD/wJeoX/wCmVuZHN0cmVhbQpl
bmRvYmoKCjI0IDAgb2JqCjYxODEKZW5kb2JqCgoyNiAwIG9iago8PC9MZW5ndGggMjcgMCBSL0Zp
bHRlci9GbGF0ZURlY29kZT4+CnN0cmVhbQp4nO1dS29ku3He61f02sAofD8AQcA8A3jneIAsgqw6
sQ3jTgB7c/9++H1f8TRPq1utm2gWVxCu3UOeQ9aTp0hWFSl37w+/3v3j4A5ulHLP9+HQkr9vh3/+
992//+HwP3f+gP/++dc7N16Ew4+72SgcfrEO6PqLgcC/eve3u7/84c7dl/G4CUIoYbQuzo92P+5C
bvfRaiFnlvoo+dGluDjKx0NIjT0y3qQ8ABWHXiFFlL2/r4fjXSDBxWdASm60Lb7dp1kOYfQ4brUy
IFqP0O/zhBUDMN4ZlliIhdhjG0+MrgGjAhboTWGUjYsBoxyMP5YHpFIGPfNNH/RYjxqAYUKq5YSj
NuAQ7uZYNqpaQE30tjh+jQ8rG4eqiXf1kEwEa0pLWCRHYZd8RdeUvCiWTsSJNLXo8LjT6NQ4BsLh
3/6Vg+rX8f8/DuX//V33b173f777kwzJ+G987J++Dy0Tg8fv9/86/Mu3YUna4ftfHmJ5/P73u6/f
R4+dgfDdD8JydPcwNL7VQYZqviXYpwhkvkF8OYJtXyt75FFKg9wc0cdXiC4nAD7e+Tp6pgQolVYu
1fs8y0O1iXBUy+yNUhs4DM5g1BMOMZTM3sRb6nhi9AyhQXhGacUgMw4qVG+8sTxgDcMZtzdQinoE
FzZIwYEa4QiujrfCHVxnWVQFqlb0Bg/Fi4tZFn9WI+fWgxIxWCYpw0IZGvaYRZOkLUqlBXEg7Sx6
O+60+LxReNf3W9T3U0PgG/sm/O4Mgf+yGQI/zEA6AMboExvIrFWzRWywUarFYdvyKIdDrH3UawW7
sebBYq1llOJAUivsYKwgrDZPZiOtWm1YscTSAKXh18o9UHCzBjtsPXq/LwaruQhIxNFcIQ5gbg42
XBQ1T+Eapc3DsoqD5uNoK95UHrA6/rU3vVr75CCMCSk5zFLCkRysqXAn11gGTcljQIvW5L1xoJI4
Y5kcW1tKQjCmjARd0hNWyFTUmKR7lfRJ99TJSVvHne6e//zftfx2tPz0o4+NkFs5/+hjvfzR++BA
dsocDn4sG4rV/BDcYCKVg6f9SgkC8xJPdqOEfyEAP2xXylnzgIMAUu6jb8dPKtCVFQvFpcqYDOLB
mles2Qim0nADdHMETXQNU4SRMUw/CRF5g9MxBYjsMREMQy+GWB6QQmJ/vcGv9aB53WDFxD7EMlaD
fWIfq8Q+aeJq1ihNMO7GgcrG2qyBZ+tBURikKSThkPCEGwIVTRKzaIXwxYFUsijruFPdjSn/Xclv
RckX5nk/ehb3ZJb/vH3w/zjA8P06Vh5Fax1sBkkRXAl5wAXUDWZIlTsR2LPRMMBS547fXw4hNnZz
qi0tn45AQzoWcWMvE7HoGfONw/KuFKjyDG30Fduk2tkwDIR11IQousZunt3WlpdcHtFzlVegmQGJ
mzTVfrEtW2id66aYHDd1u5pa7qDcmFJ/Cr4LW7vu2AKyWHX9Hw9jNdgfP5QH//Fx/Hx6/M/vf7yw
0xubaG4ojc5QFnxWM8r2VO842kG54X74KfguyCU1bvnP5bJ+A/sB0ugXMMJ2ajhTUQr5aW0qbIFy
a831M/BdmP0LNkwXB0j07dH7B7eMjf06oNOJYSRqpzZRWW1qZ6+5Vas7KLd2oT8D36VdUKRD5enY
qN5dWRLRvG+kjSnohMJqRsye0B0TOyg3RPFT8F0QxZhkLo8O92WYDffF1yuDo+WNvFwWLKpMcvak
7thop8/5OUm8Lp6nEqiXR8KXK1ZCBpnevc2ss7aZqATCtm94X1PLHZQXTSOvjO/qNBKwGPh/TCOT
Tn2Qk07VjLI91TuOdlBeNI28Mr6r08gTudyaRoywnRrOVGSGfF+bClugvGgaeWV8V6eRSwPkhdOI
kWgWylBZbWpnr7lVqzsoL5pGXhnf1Wnkwti4NY1M0mSnJmmqGTF7QndM7KC8aBp5ZXxXp5ELo+Ml
04iRJ4tuWFSZ5OxJ3bHRTp/zrWnk9fBcnkaejoSr8RVK1Ne8TO+qbWhdWif0Xc1a7qC8ZBy8Nr5L
4wAeeX0Y59MIJ5HuP16dQ1reKKRWJiKpaFK0p3bHyQbg5lB4RTwXhgK2vk9lcHXKUIhgU84q8jN1
2Hy1q01KVig35s6fgu/CYOiVAaQLg+HClDF9AzGhV6XPdExoFSu3mhO/yL1voHa6pm0DVRIbcvHD
gGrNnuVTKxML0ihggfAdlkqPVB/Wa4iiZPqkUPMFTudEf4Ivnl4iuYd97vQmISjrMx28DR4pnys9
TqDjeOez/Ff0OeVMzxLHhcodI+C41RiNUo8Or4/B6kVxHWHpbeLuohBUZecYdha92SHqJD5QBu3g
UOUBqfStxmib2jPovEGqCT414aiiD63puZoU1coaaZX7WjxY2bhTTXyrh+QhWFNSwiEZCrdkS6o2
qVe/aaNvOlv1d9xp84Y9fNf7G9b7BVPEFAlgzmcTdFsWaptZiM5Zpgd3F70xvwO10DFJoDzm+06/
ZYRpOY5apE9zLKq753Mwpn1ViZn5I/1eWS1yXURmnJRZnrkoVgu2vUWWCsg2SKmQZcMxdid+Yk6i
jzRlMHKc1DIUbVxk9DP+WD4ObsNWgy82WY/I6NSEFV0zHNGJQuCO3rEsqrDPjEav9pziY5bFodXI
u/WgTAwWZWU4KENijmHSY/I2SqkJ4yCIupPujjtN3thIvev8jer8krcjM6/rqTnol8xBiI15Hgx9
xGJlREuGTc1jUETEc3JxEH8E8lyYphU6c1XwNoTGclLuSFAWS7FNJ3JN6lbutHxWq0z+UnvGoAxS
zWTWcFRYQMNdRR1p4urnOGllCho5aP5ArhqpSczBwbMEbNYuIeS8QUiIChlsbpAMZ2LmyqQmNdZI
ZxJlpF/lyZnVyLN6QBKCNCUkHJKdcEumokqyFrXQgDgwvUxtHRfN3VgSv2v4TWj4wqceQQcg7j/0
jxfnfTJZfdeWQrktrCEfZWwjAhpGMlmDErwi08RqCMxtAUs1MLukwMbUkEkmtieoVea5QAA1IHvF
ytFjebXVaAHVI+YJifYSkIhDllS4IykUVckspeil+IyPBEEbhywjs6ZuNWyUwuwxBsoGqWE5Zjia
6CPullk2qlphbVDbCqklD1Y27lQT32oveQjSlJRwSIbCLdmCpilz0SptiAfT0kl/x502b8z973p/
w3q/4MxmCsHAfGYUPl00CsxHc5Hrwog8TlUiUjoiM7VjOiiJYZAYuHpBDy5SaEE7WyqH3BY9WA5C
BvSiWDHZYpAVhbfYmjaPMILTmouwA/JQhS+QoPE/5owcjbaQKSdQHLDXEicsIoMNgmYlsTdbJ6br
GZRUDXIiScSn1aDRwWWi6MskiVRbUdxYhUmwag3e55oSdBC20w6OkhMNJk/RRimLYsn+pJPjWnne
8feuyd+XJi98uIkN2gu38Z0pIOYgrFv+CGUaipekQ7FU1MC8ClGJFU0B39QWzl7kqXNEi6N0Gyz2
zmKgsbMKU7x1nKQYjFplMQm7SoFs5TTuAr0fpvHAlDTR3DY5qWgaVyUp8I3WSWkigpKqQU4iiImq
3C0aHdQhqMsiiMtHFcWJVbjsYlvyLRgmD8GmnICPshMVJlNRR0kvqQiLXo6rkm5M0u/a/N1p88oX
PDC+aDlOYDO0XbfAvWTqm0la077JP8hYc0cVpsUOIW36DnlabGy5yix2ei5ViX5a7LF7mBY7xEwX
qGDHOi02sh8j6Yj9ZLGxXTGLrSNv4kVrK9O4skQVcXSbrA0KNEDI0grxSVtGh7RI+qRbUq2icWOV
Oi22eBcUSkSwKSfgC24bdybTNCOgZrNN/ie9HFclveT7fdfm70mb177fEF/mOSO4GWmMOv2Vp81G
OICy9lzKm84VPKBefO3TZvvmTzYbIUWz2R5heRUg0+Os9GmxfafYCKPrCJhgdzosibFzjTXo6OVk
sxG9NJutVBDx0tvJZqtCqao1pT2hpGqQqRfho7YmHdSi6KNuRbUVxY1VsjQuvgXD5CHYlFPawjCk
wmQq6qpOp2zB7kUvx1VJL/iC37X5u9LmlS94YLy69z1Tekn0gCSz2zh6UH2jp4KeB0c/fsHp59J4
EivjcEUpneMB0il0AUbu7XFOulBvaJV74Yon0a0JGCHTdZiytlAR+4XsO9ORYDR18LPgcAb59XQa
ptx4BENnWIaMiCtR4Ti7ws0RDWkfegswgQ3mWta3RZ6/gBIa+2WswLqnJfW0vr0xAEvFceOT+esD
lJWjDoo0Oi4Z0GRKaW7VBsuQjbcz3R5UIC6CyQQeDhxhwGIKtJZm58N5iqw6b/GSPmSeuKHr5hnB
gEKuBPwsbsic5+iiowfqpLHjTn/rgFic3w4U5w5nLQ7/Zp4/jwy49lHuDFIzxuQb8Xp6hXD6PVMC
M5big07eYyx7T64zD8R4ntvP6KXjO6VUHuUhVK5WdailVBzE8UMO8lRJp6XxG85plBRIdvaU4WZK
uTSmoDnGxZrn6gEr1VKzOYpJZ3VjhGGJW8q8EwDRsmzmJlE33LFbpI8jd4s10eIoZhUct/TSbJpR
LcarjoyXVZyQ4fYXF3pwD9E5wXc79NsiR0jiuhwue34LOdrI0fhnWKB14yb3wIyck8aOO/1NDe+z
zUrcApvIJPBW81nXLPA0E88klajdgk+dKh1qSeVe1yHg9JPE46gYikQGibZIYrNyVthv1mhy1CPz
Axak4hW/Fw7uPIi5wF4aRaVryInW6g/GAaMO5Kx6MwSFg0k5BEgvZGtGKjYotU7olVcrCGfjQJnU
cCdmdDYNYplMlY0z1cSzekgWgiUZCYdkB8ySqCiakhal0oE4kG42nR0X/d3KannX89vR84Usllwt
0L6bup3fTd1L7ItZL1iInBLwghLwvj1+CA/u4+MH/+CGheK/mb/FVf7b2EJv+qM1dkjZw5PPjx/y
fBv4uzwPAb8+s4P3j+0h+MfZnHVrfQYyzD4G8vMGRiT4tPQSHNERtudoCAr8o0/WdUw+hcCdmA6n
ZuoiCvE4TZbieHM5STXGaKOSRxdD1/gzJy3GJZMfGLrAxKbkB43kwrQIpmfw6Lo8q4UH1zGtcKnE
o+uWLsElpJWZ8LElUvR6UPvK7C1Bqs4OuRNHddzVEnd1netjHub3XGwavdVHvmFgxWORIA5VHrDG
0saeJ8ewGNszRrtBSvWEIzHfUrgzg1GTqhxZI72ZiRzgwkrGnWrim+1NHoS0SYo4TIbEbbIlVZvU
Sa/pI9appUV/x502b+x93vX+hvV+YZcUtMQ8zxso4dvlLO7keFPTGByJR9tRjsrFYtolbnCIXFnr
tgqtrblXbVz582YIxEQzb4niHqlxCvH5oAM6WH/HWQ7BoquqFUZX4/28ocog2d1VhoO3WhnuiN2K
UTWztEQvJ3Djgqt58mbr+uQwYdpzj3W2tfe2aCCk5JthSIzWCnMKc/FBvxkPjYhaHUcSF7Ms/qxG
zq2HzxOSyclwUILETLkaRSZxo5W6MB6GhqbWjpv+njcD71p+O1q+8NF3ys+Dvv3RjWsffaUTwzLH
Ek8ZqJYKHbV0ZqTCcIzWnbyXodFNEOG2wKauZDoddBMDV7B3KfMuhgrLl3Kke4TsWrlLAapxQFiP
phsmCKsruGtYeIWMYWc+t9HVtakXxcXu5XBTdOTQhFebBjpvzPCzLYfgBqXR8SH4uo9KeDkEN4p4
XaXR2gtz08iDypM7q8nPzR6Sh2BNSQmLZCjskm2bOWWUOik2fZAP09OiweNOnzcMwbvm37TmnxqH
VJTtCGr3xqFfcZ3iJrZs+H/cZTo+cY/MoIDOosRkrUT3YKqZXmae/2AOZqK7DCcn4MikHu3Cx+QL
naLgMvbGe+E6E6LAWyTXMVeOokRneDAXFHJNmBLuq60YqWM6I5W5UXJnBgb24JwslEytvnSDweHb
mf2BNWW+VxI46EPyVuGasjKtC5iV+qWrMSNdbnAeYzr0XG06TkJcNdsZk2H+6cDDxUNjGuDNe6lo
AqMPfLtuk2djOFqZCesDOZaTLnOSyZmSiuAnMwCXGXvLQQnumaG6rP4K0NHFu2ruuNPjlYlDQbWC
YPzZUbexcHZfHmMfe1X3aexIy4P76tLYi3LfenmTmeCbbvgoh2lhlpxqSWLRrWLbkRsFGDOP4mDw
cJh1KDbRrwghUbCFlwjSp5yYmpuZmjPLTTOoaroXTT04HwoWPPH6XJgHFJipMHDnkO3zGsJjdt/R
qM3cYogLCBK8dCvhE+ZFj3rOAWDtebPahJRdNAxZlyMSb3a85NEoyo53EpHWTA+teLCycTdrvFBS
PSgPwZqSEhbJELhNsrrtbUpchk66IBdTR7N0XPR4YzJ51/cb1PeFKaQFGpvzTeXnKw68yFBWDnPG
iZv/LtOVFeEUC67QZ/VlPUv7FEoAq4QyaBgPnnMcRoZ8aMHP/IafgddPTyH9gnLB0Z6V1R+3Oe7w
BP636M0Yjscxy9MmR930DMofF0P4tAH28k66wawvm4tvQ/v18UOb3dvmEAxpcQjS9VdXvyJpnV7P
Iby6A9kXP+Tnx+JwF8yzkuUc+psk6zEfPuORNcmu/sq0CBP0m3QXR6k1Lye3aLFHm/t2vmgnAJHs
J3P5DtGd9CVsi9N105A5S6d/dQd79cV+PPcM25PwxO/sVsdzPmf3NOZWfhfftLT+ZbAe5R0OX09i
MD2vA3Vh8vIIMkKXlxf0sLA9JQJXspGqvsuYWr3X+iAKmoRvzw8vHtX9LcOrr7cZaXSFBkxGWD25
4eNKzvzQPp20tum2uLKV2Jbjxlha5BMKFjjreMi74fP5NKSMGv7GeFLIOurD084G0Pz0i03YAOxi
Cy8Jbpx0eYpEnA/xBfdJyW5KUAKyNR3HX6FduxwmMXl7yXuVg8l2Aq9Lx8ngc2OF+5695idCC/VI
7Sabr8vn6B6e2Bzpch0ZTyI9O3C/IY60k4P1D/HR103Zy7d4NlyeE0DdgmMv/FZqOLfDy3qdyN0y
6E4SumCO4u5Z38QzldmWGfKFETL3cBpTmzq2mNgMWa2Bs3om55tfzXPSZGbNb5Fmbsve2CzPOq99
nQPpxNVml09f7RxJ7ulQyttQPBtK53PCNAbhS+yU1dfdQN4FBK+tYoju4yY3jtB2RSMnC+/Wdccc
TX41TVNX6+Ty7HbQL+cl5u09dkrCbqaJUZEMXd9yVrPzFCuUl9wW9Nr4rt0WFBlN+r/cFjQp5MU9
E5Eqk6I9tTtONgA3bwt6RTxXbgt6KoMbtwVtyllFfqYO3ddzVjNKVigvuS3otfFduy3o4mB45rYg
H7VD9sxJ9Tzom5lJdnZbkK/6qwqJm2zcrIKtZ2SWJJL1PP1pGsWnliaaPaVZB8NOm6NwWmThU3Yd
FgA2xbXxrWuRzU0ObBjsRcLHX2CtNUGOeh/9lmbYAaDymQDGjADAw94A7LdhKGSTgvoFlLDiGO1D
GI01QXENimfxyyP3hwPQ50FU1T7B4BjQQeuExHSJK/NCkPvwtH0x3i9zKvznXBrlZZ19tsHXdf8E
cuZ+4Epuhog7tckvLjMW/MPycuFZrMvLjN3+Dx4nDzyvuvZk0uoPnqnRsdjGl0XX3ozRjWy++7S8
qoVOFRETeUb99LI7uu6ZDX2IFQHsyhxDvPSOx2h0wzWjbI1nY0XPMHyHFAA0BeTuITsz6E3U3wKo
5AO5rMXC8HybedCIObM/4K05VDdvxvJ0T0a6i3+Yn0LhdbzFHV4ZLuLxLjNjt9h1OX+2qwoi/UDj
bWAeI3NS+TYny+79gT9Kcj//zhLfNbzjTV2HzCP/JczLwyM9M9vbothdmm+TMojnW12E0AxnZL6n
zj9vb9O8HxxSDTyT3Pk20+sTDfLT+1PrxHOHw03NaiHQpV3avf7IjaKyvHLIoqHRNveR0cl46DpQ
oZvciy59KgxAcHTRmaVRqPQIG6/K++ByChwQSmH2wpYkWyvz5ujXptNJBFVfdQqNpNYI4sWCRqGY
Uxl5Fm2rRf69GPVIsTN/Q7BwS1I3LHCIecOeo/L8RBf85t4INvE33dbA8sYga+KcPUwghDUlJSzJ
HIaMaTiddWOCuAldFEsd4kRqWhV43KlzTiN/OvwvZojSdAplbmRzdHJlYW0KZW5kb2JqCgoyNyAw
IG9iago2MDUwCmVuZG9iagoKMjkgMCBvYmoKPDwvTGVuZ3RoIDMwIDAgUi9GaWx0ZXIvRmxhdGVE
ZWNvZGU+PgpzdHJlYW0KeJztXctuZDly3esrcj1Ay3w/gIKAehqY3XgK8MLwKu2xMegyMLOZ3zfP
OcGbvKmbktpWLVoQxlaTecl4kkEyIshy9/70j7u/ndzJjVLu+T6cWvL37fT3/7z71z+c/ufOn/C/
v//XnRsfwunH3WwUTr9aB3T91UDgv/r233d/+cOduy/j5yYIoYTRujg/2v24C7ndR6uFnFnqo+RH
l+LiKJ9PITX2yPiS8gBUHHqFFFH2/r6ezneBBBefASm50bb4dp9mOYTR47zVyoBoPUK/zxNWDMB4
Z1hiIRZij238YnQNGBWwQG8Ko2xcDBjlZPyxPCCVMuiZX/qgx3rUAAwTUi0XHLUBh3A3x7JR1QJq
orfF8df4sLJxqJp4Vw/JRLCmtIRFchR2yVd0TcmLYulEnEhTiw7PO41OjWMgnP7lnzmo/jH+/49D
+X991/2b1/2f7/4kQzL+Nyb7p+9Dy8Tg8ff7f5z+6duwJO30/S8fYnn4/te7r99Hj52B8N0PwnJ0
9zA0vtVBhmq+JdinCGS+QXw5gm1fK3vkUUqD3BzRx1eILicAPt/5OnqmBCiVVi7V+zzLQ7WJcFTL
7I1SGzgMzmDUEw4xlMzexFvq+MXoGUKD8IzSikFmHFSo3nhjecAahjNuX6AU9QgubJCCAzXCEVwd
X4U7uM6yqApUregNHooXF7Ms/qxGzq0HJWKwTFKGhTI07DGLJklblEoL4kDaWfR23mnxaaPwru+3
qO/HhsA39k34uzME/stmCPwwA+kEGKNPbCCzVq0WscFGqRaHbcujHE6x9lGvFezGmgeLtZZRigNJ
rbCDsYKw2jyZjbRqtWHHEksDlIa/Vu6Bgps12GHr0ft9MVjNRUAijuYKcQBzc7Dhoqh5CtcobR6W
VRw0H0db8abygNXxX/vSq7VPDsKYkJLDKiUcycGaCndyjWXQlDwGtGhN3hsHKokzlsmxtaUkBGPK
SNAlPWGFTEWNSbpXSZ90T51ctHXe6e7p6f+u5bej5ceTPjZCbuV60sd6POl9cCA7ZQ4HP7YNxWp+
CG4wkcrJ036lBIF5iSe7UcJ/IQA/bFfKWeuAgwBS7qNvx59UoCsrFopLlbEYxJM1r9izEUyl4Qbo
5gia6BqWCCNjmH4SIvIGp2MJENljIRiGXgyxPCCFxP76gr/Wg+Z1gxUT+xDL2A32iX3sEvukibtZ
ozTBuBsHKhtrswaerQdFYZCmkIRDwhNuCFQ0ScyiFcIXB1LJoqzzTnXPLPnvSn4rSj5Y5/3oWdyj
Vf7zNuH/doLh+8fYeRTtdXAYJEVwJeQBF1A3mCFVnkRgz0bDAEudO/7+egqxsZtTbWn5eAQa0rGJ
G2eZiE3PWG8ctnelQJVXaKOvOCbVzoZhIKyjJkTRNXbz7La2PHJ5RM9dXoFmBiQe0lT71Y5soXXu
m2JyPNTtamq5g/LMkvpT8B0c7bpjC8hi1fW/fRi7wf7wS/ngPz6MP58e/v37Hw9OeuMQzQOl0RnK
gs9qRtme6h1HOyjPuB9+Cr4DuaTGI/+1XNY5sB8gjX4BI2ynhisVpZAf16bCFijP7bl+Br6D1b/g
wHQ4QKJvD95/cMvY2O8DOp0YRqJOahOV1aZ29ppbtbqD8twp9GfgOzoFRTpUHo+N6t2NLRHN+0ba
WIIuKKxmxOwJ3TGxg/KMKH4KvgNRBI27I1F88zf2hy1vlOWyIFBlUrKncsdBu8zkp4TwungeM1+P
B8GXGwZCtpiOvc2is7ZZpwTCtum7r6nlDsqLVpBXxndzBQnYB/w/VpBJp+bipFM1o2xP9Y6jHZQX
rSCvjO/mCvJILs+tIEbYTg1XKjIbvq9NhS1QXrSCvDK+myvI0QB54QpiJJpxMlRWm9rZa27V6g7K
i1aQV8Z3cwU5GBvPrSCTNNmpSZpqRsye0B0TOygvWkFeGd/NFeRQFE+uIEaZjLkhUGVSsqdyx0G7
zOTnVpDXw3O8ghxwfmMFkTB9zcuirtqG1qV1Gd/VrOUOykuGwGvjOx4CowXnxPUKwvWj+483l4+W
NwqplYlIKpoU7andcbIBeHYovCKeg6GAA+9jGdxcLRQY2JSzivxKHbZU7WqTkhXKM8vmT8F3MBh6
ZdjoYDAcrBbTIxATelV6SsdaVrFpqzlxRu49ArXTIW3HppLYkPsehlFr9ixfWplYkDwBC4R5WCr9
UH0sa0MUJdMThZovcDUnehF88fQNySnsc6cPCaFYn+nWbfBD+VzpZwId5zuf5bWipyln+pM4LlTu
GAHnrcYYlHp0+HoMVi+K5ghLbxN3F4WgKjvHYLPozQ6xJvGBMmgHhyoPSKVvNcbY1J6h5g1STfCk
CUcVfWhNf9WkqFbWSKuc1uLBysadauJbPSQPwZqSEg7JULglW1K1Sb36TRt909mqv/NOm8/Yw3e9
v2G9H5giJkYAc74KfLRlW7KZheic5XfwYNEbszpQCx2LBMpjve/0VkaYlvOoRXoyxw6oe/4OxnSk
KjEza6TfK5dFDovIPJMyyzMDxWrBTrbITQHZBikVsmw4xsHET8xJ9JGmDEbOk1oGoI2LjH7GH8vn
wW3YavDAJusRGZOasKJrhiM6UQjc0TuWRRWOmNHo1XFTfMyyOLQaebcelInBoqwMB2VIzDFMekze
Rik1YRwEUXfR3XmnyWfOUO86f6M6P3J0ZGZzPTYH/cgchNiY3cGARyxWRoxk2NQ8BkVEFCcXB/FH
IM+FyVmhM0MFX0NoLCdljATlrhQ7byLDpG7lTstntcqUL7Vn5Mkg1UxmDUeFBTTcVdSRJu5+zpNW
Jp6Rg+ZP5KqRmsTMG/yWgM3aJQSaNwgJsSCDzQOS4UzMV5nUpMYa6UyijPSrPDmzGnlWD0hCkKaE
hEOyE27JVFRJ1qIWGhAHppeprfOiuWe2xO8afhMaPpjqEXQA4n6ifzxc98lk9V1HCmW0sIYslHGM
CGgYyWQNSuuKTA6rITCjBSzVwJySAhtTQyaZOJ6gVpndAgHUgJwVK0eP7dVWowVUj5gnJNpLQCIO
WVLhjqRQVCWzlKKX4jM+EgRtHLKMfJq61XBQCrPHGCgbpIbtmOFooo+4W2bZqGqFtUFtK6SWPFjZ
uFNNfKu95CFIU1LCIRkKt2QLmqbMRau0IR5MSxf9nXfafGbtf9f7G9b7gR+biQMD85VR+HRoFJiF
5iL3hRHZm6pEJHJE5mfHdFLqwiAxcPeCHtyk0IJ2tlTmuG16sB2EDOhFsWKyzSArimyxNW0eYQSn
PRdhB2SfCl8gQeP/mClyNtpCppxAccBZS5ywiLw1CJqVxN5snZikZ1BSNciJJBGfdoNGB7eJoi+T
JFJtRXFjFaa+qjV4n3tK0EHYTic4Sk40mDxFG6UsiiX7i07Oa+Vpx9+7Jn9fmjyYuIkN2guP8Z2J
H+YgrFvWCGUaipekQ7EE1MD4t6jEjqaAb2oLNy7y1DkCxVG6DRZxZzHQ2FmFid26RFIMRq2ymIRd
pUC2chp3gd4P03hgIppobpucVDSNq5IU80brpOQQQUnVICcRxPRUnhaNDuoQ1GURxO2jiuLEKtx2
sS35FgyTh2BTTsBH2YkKk6moo6SXBIRFL+dVSc8s0u/a/N1p88YMHhhftB0nsBnVrlvMXjL1zSSt
Zd/kH2SseaIK02KHkDZ9hzwtNo5cZRY7PZeqRD8t9jg9TIsdYqYLVLBjnRYbOY+RdMR+sdg4rpjF
1kU38aK9lWlcuaGKOLpN1gYFGiBkaYX4pC2jQ1okfdItqVbRuLFKnRZbvAsKJSLYlBPwBbeNO5Np
mhFQs9km/4tezquSXjJ/37X5e9Lmrfkb4ss8ZwQ3I41Rd77ytNkIB1DWnlt507mCB9SLr33abN/8
xWYjpGg22yMsrwJkep6VPi227xQbYXRd/BLsToclMXbusQYdvVxsNqKXZrOVBSJeervYbFUoVbWm
tCeUVA0y9SJ81Nakg1oUfdStqLaiuLFKlsbFt2CYPASbckpbGIZUmExFXdWdlC3YvejlvCrpBTP4
XZu/K23emMED482z75XSS6IHJJndxoWD6hs9FfQ8OPrxC+48l8b7VxlXKkrpHA+QTqELMPJsj9vR
hXpDq9wLdzyJbk3ACJmuw5R1hIo4L2TfmYkEo6nrngVXMsivp9Mw5caLF7q5MmREXIkKx40VHo5o
SPvQW4AJbDDXsr4t8tYFlNDYL2MH1j0tqaf17Y0BWCqOB5/Mvz5AWTnqekij45IBTWaT5lZtsAzZ
eLvJ7UEF4iJYTODhwMUFbKZAa2l2K5x3x6rzFi/pQ+aJB7punhEMKORKwM/ihsx5ey46eqAuGjvv
9LcOiMX57UBx7nDW4spv5q3zyIBrH+XOIDVjTL4Rr6dXCHfeMyUwYyk+6L49xrL35DrzGoznbf2M
Xrq0U0rlBR5C5W5VV1lKxfUbP+QgT5V0WhrncE6jpECys18ZbqaUSwM+8OIpRewesFMtNZujmHRW
N0YYtrilzJcAEC3LZm4SdcMTu0X6OHK3WBMtjmJWwfFIL82mGdVivOrMeFnFvRgef/GMB88QnQt8
t6u+LXKEJO7L4bLnXMjRRo7GP8MCrRs3uQdm5Fw0dt7pb2p4n21W4hbYRCaBt5rPelyBd5h4E6lE
nRZ86lTpUEsq93oEAXeeJB5HxVAkMki0RRKblbPCfrNGk6MemRNYkIpX/F44ePIg5gJ7aRSVriEn
Wqs/GQeMOpCz6s0QFA4m5RAgvZCtGanYoNQ6oVc+qCCcjQNlUsOTmNHZNIhlMlU2zlQTz+ohWQiW
ZCQckh0wS6KiaEpalEoH4kC62XR2XvT3XFbLu57fjp4PslhytUD7bul2frd0L7EvZr1gI3JJwAtK
wPv28Ev44D4+/OI/uGGh+N/Mv8VV/rexhb70B2vskLKHXz4//JLn18C/y+8h4K/P7OD9Q/sQ/MNs
zrq1vgIZZh8D+XkDIxJ8WnoJjugI2+9oCAr8g0/WdSw+hcCdmA6XZuoiCvFzmizF8eU4STXGaKOS
FxZD1/gzJy3GJZMfGLrAwqbkB43kwrQIpmfwwro8q4XX1bGscKvEC+uWLsEtpJWZ8LElUvR6UvvK
7C1Bqs6uthNHdTzVEnd1nftjXuH33GwavdVHfmFgxWOTIA5VHrDG1sZ+T45hMbZnjHaDlOoFR2K+
pXBnBqMmVTmyRnozEznAhZWMO9XEN9ubPAhpkxRxmAyJ22RLqjapk17TR6xTS4v+zjttPnP2edf7
G9b7wSkpaIt5nTdQwrfjLO7k+D7TGByJF9pRjsrFYtol3m2I3FnrjQrtrXlWbdz58z0IxEQz34bi
GalxCfH5pLs52H/HWQ7BoquqFUZX4/18l8og2YtVhoNvWRnuiNOKUTWztEQvF3Djgrt58mb7+uSw
YNrvHvtsa+9t00BIyTfDkBitFeYU5uaDfrPApZXU6iaSuJhl8Wc1cm49fJ6QTE6GgxIkZsrVKDKJ
G63UhfEwNDS1dt7097QZeNfy29HywaTvlJ8HffurG7cmfaUTwzLHEm8ZqJYKHbV0ZqTCcIz2nXyN
odFNEOG2wKGuZDod9P4Cd7B3KfMFhgrLl3Kke4TsWrlLAapxQFiPpnclCKsruGtY+HCMYWc+t9HV
dagXxcVe43BTdOTQhFebBjrfyfCzLYfgBqXR8SH4eoVKeDkEN4r4SKXR2gtz08iDypM7q8nPzR6S
h2BNSQmLZCjskm2bOWWUOik2fZAP09OiwfNOn88YgnfNv2nNPzYOqSjbEdTujUO/4TrF+2vZ8P+4
y3R84vWYQQGdRYnJWonuwVQzvcy8/8EczER3GW5OwJFJPdozj8kXOkXBZeyNr8F1JkSBt0iuY64c
RYnO8GAuKOSaMCXcV9sxUsd0Ripzo+TODAycwblYKJlafekGg8O3M/sDe8p8ryRw0IfkrcI9ZWVa
FzAr9UsPYka63OA8xnLoudt0XIS4a7Y7JsP804GH54bGMsD39lLRAkYf+PbIJu/GcLQyE9YHciwn
XeYikzMlFcFPZgAuM/aWgxLcM0N1Wf0VoKOLd9XceafHGwuHgmoFwfirq25j4+y+PMQ+zqru0ziR
lg/uq0vjLMpz6/EhM8E33TAph2lhlpxqSWLRW2LblRsFGDOv4mDwcJh1KDbRrwghUbCFTwfSp5yY
mpuZmjPLTSuoanoNTT24HgoWPPGaLswDCsxUGLhzyDa9hvCY3Xc2ajOPGOICggQv3UqYwnzeUb9z
AFh7vqc2IWUXDUPWk4jEmx2fdjSKsuNLRKQ100MrHqxs3M0an5FUD8pDsKakhEUyBG6TrN54mxKX
oZMuyMXU0SydFz0+s5i86/sN6vtgCWmBxub6UPn5hgMvMpSVw1xx4ua/y3RlRTjFgiv0WX1Z79I+
hhLAKqEMGsYPTzkOI0M+tOBXfsPPwOunp5B+QbngaM/K6o/bHHf4Bf636M0Yjp9jlqdNjrrpGZQ/
LobwaQPs5Z10g1lfNhffhvbrwy9tdm+bQzCkxSFI119d/YqkdXo9h/DqDmRf/JCfH4rDJf4nJcs1
9DdJ1mM9fMIja5Jd/ZVpESboN+kujlJrXi5u0WI/be7b+aFdAESyn8zlO0R30ZewLU7XTUPmLJ3+
1R3s1Rf78dozbL+ER35ntzqe8zW7lzG38rv4pqX1L4P1KO9w+HoRg+l5HagLk8cjyAhdPh7oYWF7
SgSuZCNVfZcxtXqvNSEKmoRvTw8vXtX9LcOrrw8ZaXSFBkxGWL244eNKzpxony5a23RbnPnQP8n5
nhf9Pj3rx7xNm+TmFAwF+6BlftoYuPjjbfanDaazAEWMV0YnbNo5AGBBjWlCoJ0yeV7m/KeFnZcO
y8vgNvldz4qNMYQg8hZXMKicp8sMp0iG4Zty83EZe6vtU4OnhgyPP1cDYE/bldld2V8Z+rLIf5rq
x+Z+beTypfugehlwU0O3pL4NNc2b1VBcy/tDqHOSPyWGukXKXjhxarg2ysvmnZy6ZUxdTPSBbYq7
32RIN9vgbDSV3xQuc+t41wRaAmQzfrVG0eqFzmm+ryfFfmg9JU2m2fwWaea2HJRtFK6L3Nc5K5dZ
XG7OR/c4Ppm3eb0scI/DkxdTFL7ETll93dm7XXTw1paG6D4uxiRETeADjVzMvVuN3BxN0+Z9Wm3b
utI8eTb0y+WJ+ZSPXZmwZ2piVFhDb7lc1exyxQrlJU8HvTa+W08HRYaW/i9PB00K+YrPRKTKpGhP
7Y6TDcCzTwe9Ip4bTwc9lsEzTwdtyllFfqUOPd5zVTNKVigveTrotfHdejrocDA88XSQjzoueyao
et76zUwru3o6yFf9wwqJJ248s4JzaGTKJDL3PJ1rGsWXliaaa68gh8HlpBS2HRdsiuswADAprs1D
25jlyq+AuR4Tv9BSjy9ttP6GHTmXZjsHsNXoyqWAxmH8MowNisNIyB7BcLE6Svr2GQtCUh/2Hojw
c/zywLMilq3PD6RAyIuBG91Jr6/oyc3WsFntiT1H4L9qs7wpbyIYKvLzpEouRahR/VkEVcrC+Pwm
Yx/E+WWqz8HY9TgFEup+4JVuxo87tcsZmBko/mFJu3A71uVjhivgB++aB15mXXsyo/UHL9zozmzj
x6I3ccZoR6rffVo+1UKPi4iJvMB++dgd/fpMlT7Fiuh2ZQIiPnrHOzZ69JohuMaLs6JnGMJTCgCa
AhL7kLoZ9CXqnweo5AOJrsVi9PyaeQuJCbU/4Mo5VTefzfL0XUb6kn+YE0Oxd3zFA18Z/uPxLTOd
t9hbOn+2dwwinUTja2CSIxNW+TUnS/39gX+n5H7+00v81vCNz3idMt8DKGG+Jx7pttm+FgX20vya
lF48v+qVhGY4I5NBdTl6+5rmk+GQauCF5c6vmS6haJAfv6taJ5473HxqVguB/u7S7vXv3ihky/eI
LFQa7eQfGbqMp67bFnrcvehFqMLoBEcXPV0ahcqdsPGqpBBur8ABoRSmNmwZtLUyqY5Ob3qkRFD1
VVfUSGqNIF4saBSKOZWRhNG2WuQ/IaMeKXYmdwgWnlDqhgXeMm/Yc1QSoOiCU90bwSb+pqccWN4Y
ZE2cs4cJhLCmpIQlmTeRAQ+ni3DMHjehi2KpQ5xITasCzzt1zmXlT6f/BeGX1qYKZW5kc3RyZWFt
CmVuZG9iagoKMzAgMCBvYmoKNjA3NAplbmRvYmoKCjMyIDAgb2JqCjw8L0xlbmd0aCAzMyAwIFIv
RmlsdGVyL0ZsYXRlRGVjb2RlPj4Kc3RyZWFtCnic7VzJjiS5kb3nV8RZQKW4L0AhgKxtAN0kFaDD
YE4xkgZC1wDSpX9/+N4zerhHeGSkBlmHTiSqO5J0J22lG0kzI92jP/z68M+DO7hRyj0/hkNL/rEd
/vXXh7/87vC/D/6Af//6+4MbL8Lhx8NsFA6/WAd0/cVA4K/e/c/D33734B7LeNwEIZQwWhfnR7sf
DyG3x2i1kDNLfZT86FJcHOXTIaTGHhlvUh6AikOvkCLK3j/Ww+khkODiMyAlN9oW3x7TLIcwepyW
WhkQrUfoj3nCigEYHwxLLMRC7LGNJ0bXgFEBC/SmMMrGxYBRDsYfywNSKYOe+aYPeqxHDcAwIdVy
xlEbcAh3cywbVS2gJnpbHL/Gh5WNQ9XEu3pIJoI1pSUskqOwS76ia0peFEsn4kSaWunwtNHo1DgG
wuFP/8FB9ev4/w9D+f941/2b1/2fH/4oQzL+jY/90/ehZWLw+P3+34fffxuWpB2+/+1jLMfv/3j4
+n302BgI3/0gLEf3CEPjWx1kqOZbgn2KQOYbxJcj2Pa1skcepTTIzRF9fIXocgLg04Ovo2dKgFJp
5VJ9zLM8VJsIR7XM3ii1gcPgDEY94RBDyexNvKWOJ0bPEBqEZ5RWDDLjoEL1xhvLA9YwnHF5A6Wo
R3BhgRQcqBGO4Op4K9zBdZZFVaBqRW/wULy4mGXxZzVybj0oEYNlkjIslKFhj1k0SdqiVFoQB9LO
Sm+njRafNwrv+n6L+r42BL6xb8LvxhD4L4sh8MMMpANgjD6xgcxaNVvEBhulWhy2LY9yOMTaR71W
sBtrHizWWkYpDiS1wg7GCsJq82Q20qrVhhVLLA1QGn6t3AMFN2uww9aj98disJqLgEQczRXiAObm
YMNFUfMUrlHaPCyrOGg+jrbiTeUBq+OvvenV2icHYUxIyWGWEo7kYE2FO7nGMmhKHgNatCbvjQOV
xBnL5NjaUhKCMWUk6JKesEKmosYk3aukT7qnTs7aOm109/zn/67lt6Pl648+NkJu5fKjj3X/o/fB
geyUORz8WDYUq/khuMFEKgdP+5USBOYlnuxGCX8hAD9sV8pZ84CDAFLuo2/HTyrQlRULxaXKmAzi
wZpXrNkIptJwA3RzBE10DVOEkTFMPwkReYPTMQWI7DERDEMvhlgekEJif73Br/WgeV1gxcQ+xDJW
g31iH6vEPmniatYoTTDuxoHKxtqsgWfrQVEYpCkk4ZDwhBsCFU0Ss2iF8MWBVLJS1mmjujtT/ruS
34qSd+Z5P3oWdzXLf14++H8eYPh+HSuPorUONoOkCK6EPOAC6gIzpMqdCOzZaBhgqXPH7y+HEBu7
OdVWLa9HoCEdi7ixl4lY9Iz5xmF5VwpUeYE2+optUu1sGAbCOmpCFF1jN89u65Z7Lo/oYXLjMLIJ
kLhJU+0X27LF6Nk3JpjBi5pabqDcmVJ/Cr6drV0Hi2iXN7r+z49jNdiPH8pH/3QcP5+O//X9Dzs7
vbGJxpQy6Qxlhc9qRtmW6g1HGyh33A8/Bd+OXBIWB9dyWa90twOkYUswCduo4UJFKeTr2lTYCsq9
NdfPwLcz+xdsmHYHSPTt6P1Htxob23VA57LOSNRObaKy2tTOVnNrrW6g3NuF/gx8e7sguFf2xkb1
7saSiOZ9Ic3HFQqrGTFbQjdMbKDcEcVPwbcjijHJ7I8O92WYDffF1xuDo+WFvFxWWFSZ5GxJ3bDR
zp/zc5J4XTzXEqj7I+GWlaBBDgUT/DTrqk0TFVrn9lvf8EVNLTdQXjKNvDa+W9NIKJhS///TyEIn
P8iFTtWMsi3VG442UF4yjbw2vlvTyLVc7kwjk7CNGi5UJEN+UZsKW0F5yTTy2vhuTSO7A+Rl08gk
URZqorLa1M5Wc2utbqC8ZBp5bXy3ppG9sXFnGllIo51aSFPNiNkSumFiA+Ul08hr47s1jeyNjhdM
I5M8WvSJRZVJzpbUDRvt/DnfmUZeEc/uNLIzEm7GVyRRBokWvbC2oE0gbNHEtqaWGygvGgevjG9v
HMAjjw8pXU0jnES6f7o5h0DCRqG0YohUmRRtqd1wsgC4PxReD8/+ULiSwM0JQwGCRTVrgV8ow2ar
bc3oWEO5M3P+FHw7Q6FXTDB7Q2FnwpiegZjQq9JjOqazig+u5kQKtp6B2umYtnmvJDZEs8hwas2e
5XMrEwuSKGB/AMM5C+hyL9obw7iohQ6mUR667HRPRKfYUI90XQzWuudzeKO0fCoxM0zcHxW81tQS
GVguszxDzlYLZn4QjIb3xSAlOGsHLOFIDaIX5iT6SFN29D0ZtYw4GRcZ/Yw/lk+D27DU4HJJ1iPS
CT1hRdcMR3SisHEf7VgWVVhORqNXS0vxMcvi0Grk3XpQJgaLsjIclCExxzDpMXkbpdSEcRBE3Vl3
p40m76yX3nX+RnW+t6nJTN9Il7u7+LRani3mIMTGcC49nLFYGU7RMMpjUES4bXNxEH8E8lyYjRE6
Q9J4G0JjOSlEHBSsLra2REi5LuVOF7TVKnM81J6uZoNUM5k1HJU2VbirqCNNNHOnSSszTchB8wdy
1UhNYqgdzxKwWbuEyNICIcH5a7Bp+Q1nYoB6UpMaa6QziTLSr/LkzGrkWT0gCUGaEhIOyU64JVNR
JVmLWmhAHJheprZOK83dmfveNfwmNLzzqUfQAYjbD73tfeiRTFbftXZQCJs1hJ3HeiGgYSSTNSiP
IzIbpIbAEDZYqoFB5AIbU0MmmViHoEaXKwVQA/3QKkePPI2lRguoHjFPSLSXgEQcsqTCHUmhqEpm
KUUvxWd8JAjaOGQZAfS61LAiCrPHGCgLpIYFmOFooo+4W2bZqGqFtUFtK6SWPFjZuFNNfKu95CFI
U1LCIRkKt2QLmqbMRau0IR5MS2f9nTbavDP3v+v9Det9x2fFSOHAfGEU+q5RYNrJDMfUJdgUs8UW
Bv50UKxykBi4ekEPLlJoQTtbKlXUFj1YDtLBzu2SiskWg6zI/cDWtHmEEZzWXIQdkG4mfIEEjf8Y
Gj4ZbSFTTqA4IO9FnLCIRBUImpXE3mydGEMyKKka5ESSiE+rQaODy0TRl0kSqbaiuLEKc93UGrzP
NSXoIGzKCfiG5ESDyTNNj/0g8xyzWOnktK48v79/1+RvS5M7H25ig3a1bt+fzjuTu80TUBf/PmUa
ipekQ7GMs0C/t6ik/xZ8U1tIsc5T5/DmRek2mG+UxUBjZxVmciprvBiMWmUxCbtKgWzlNO5C8xp3
pI6ZJ6K5LXJS0TSuSpJjEq2T3PiCkqpBTiKI+WjcLRod1CGoyyKIy0cVxYlVuOxiW/ItGCYPwaac
gI+yExUmU1FHSa9cxSu9nNZKujNJv2vzN6fNG1/wwPiSfbeAmUNS0mNFMvXNJK1p3+QfZKy5owrT
YoeQFn2HPC02tlxlFoFq6jv6abHH7mFa7BAhiqnxWKfFRpJTJB2xny02titmsXWyRbxobWUaVzKY
vMlukbVBgQYIWVohPmnL6JAWSZ90S6pVNG6sUqfFFu+CQokINuUEfMEt485kmqZ322y2yf+sl9Na
SS/5ft+1+VvS5q3vN8SrGbivMgg3ai+JO6hkekeGYvWNOx3uXBz9gAWHpEpjwnZGDmYpnZqAL7HQ
hRC5N8BxqkLNoVXuhRYz0S0CGCF3O8nAJVjEeiN7Bus9hK7zIQU5nNSep9Mh5cZMTaW6poMnrkSV
I8WViysqoudRgAgb1C3ttcg0TWy9GvtlWPDuqQlP7XWcBklMhfRcOGX++oDMxRyVT9ro+MAOyjNk
mBv2Sb4jhlq8Hf3yoAJ+VQxG7JCQ6QhjDFpLs2NkTDavzpu/dewWfeKCsNvOykPSqXKf5obMmW4f
HXewZ42dNvpbD4mV88yB4tzh7MEZocxjaoNunpopDhz6TB+1b8TruavEIblMCUxfrA86oIfZyHty
nZk363m8L6OXsnxLqcz4JVTOdsp9LRX5un7IQTtd6bQ0fCqDhlFirm919rTwfFDl2GOk2tGv3jyt
D2a6UrM5mkhndWOEYYosZR4dhLed+bc2DgsdWzNSwJG7+Kp51EA+76D8TGk2Ta84/d0n+tsrEmm5
fMa5X65BerSEWp4NapEjJHFeh8uP30KONnI0/ulWbN24yR2aX2vstNHf1PA2KF3iEhjxGZ+Saj7r
NCaTnpm6XKJWGz51qnSoJZVHnZpEkrTE46gYioQmSeFjic3KWWGDWUvsrZAFP2BBKp6bF8PBlQsx
F9hXo6h0DTnRWvGcHNBrSc6qN0NQOJj4vCILga3p6Vyg1DqhV57AFM7GgTKp4UrO6GwaxKTfysaZ
auJZPSQLwZKMhEOyA2ZJVBRNSYtS6UAcSDeLzk4r/d1JBnjX8xvS807kPVcL1G2mbuc3U/dqrudM
mKEOdhiYgwL1+fghfHTxGD4Os1uOHzzSeVYx+2soATM+oQxTMx48i5czBpc3k1DD+414n4hwTCwD
v9OjwEeJv/34IeN5Jp1+vvxsj9G8HNt8UOwRgT2tWrYzgHj8UCd0PA5C8fkYDJvXO3Yf0zv/BqBN
BmI+NNjh3Nx+P63ePq2ojoYWUByorQsVF+wOJnb4nW2CPQhfBuuxEVr4ehZDMpl+XoTnVkx+PX5o
1sa3cycRunq5o4cV21MifkAwUtVX0EDkSpBOuGNBk/Dt+eHl0xwsLx1ePqwOwWh4hQZURlmV2sBs
XNND5txU2KeNcsfsvZTYlgPHeFoJKBTkvq0HRN6Mn8/nMWXU8DfGs0bWwz5cdzaAwhn9JGul0k9r
Qa9H2XqQfQh7ypxjNVyN8RXus5bdlKAExLEVNADLcfTejMCwYDB5e8l7LQeT7QReVx0ng88Nlr7O
xpPmJ8InkxfVbrL5uvoe3ccroyNdrkdG2AgJmlyDe4mow1rSc9ypf4hHXxdlrz7Gi+HynABanQJ4
4cfS8mrOMFNcfRw2P/aJ3q2G3VlGOxYpbp71RUBTnTRt5Wwx8nzDVsEvlk9iNREto2pRyOw4B6lG
02bMnCV997t5Tp51mVJfKM8aLi3PemL7OgfSmafFMJ+/2jmS3PVQystQvBhKl5PCNAbhy9i+Q1Jf
NwO5rE3NeQoRXZMiontapMYR2m7o42zi3dn8hWUs+bVpmppazy4G9IYudN2J0iKeWTf8Gx+g2xPb
1ef9wkF6BfI8Glefhz9/QZu5UHCuVw9U4sC3ssJ+o7e1XXxaKJrfhA308WY/9TbGaItoHsgMXctl
i0lhGc1cL0ZqsQ9XrpcW3jyHwzhSqTpzx30zj+NjF0zPDg/kW3YY06utzPy2JW+s14PaV+eWAFt1
dnSfOKqjE4+4q+sMlfGKAp7hORm9Y6TxDePIHj4NcajygBXrfJ4cswDYnikpC6RUzzgS80iFOzP2
PqnKkTXSm5m3Bi6sZNypJr7Z3uRBSIukiMNkSNwmW1K1SJ30mj5inVpa6e+00eYdZ+273t+w3nfc
ukEescs0qTJmpt3s9OR4/9QYHIkH9lGOSj11JKBHurPio+7gkCuQwexGRyXvu4hcWRS69068j4K3
Yh107AjuwjjLIVgyiWqFySTxcd67ZZDsRi7Dwbu6DHeEc9Womkmpopf+BuOCzkfyZm7I5LBYsuce
bkFr783HQUjJN8OQmJwizClMXwnDBDwKI2p1yEpczLL4sxo5tx4+T0gmJ8NBCRIz5WoUmcSNVurC
eBgamlo7Lfp73gy8a/ntaHnno++Unwd92yMptz76ypiLJcomnp5QLRXGpRh7SYXRZ7nJeNtEY1Qj
IsoCH3TJjJHofgk63B5S5g0TFZYv5choDtm1cpcCVOOAsB5N92YQVlcui2HhxTiGvcOrbnR1xSBE
cbHbRtwUHTk04dWmgc57QPxsyyG4QGmM0wi+btkSXg7BhSJewmm09sJUXPKg8uTOagrrsYfkIVhT
UsIiGQq7ZNtmCi2lTopNH+TD9LTS4GmjzzuG4F3zb1rz18YhFSV3x8eLXA1/K9KL++Wy4f/xkBmn
xe04gwLGthJzUxOjmalmhsURvUpMOU+M7uEuHsRdqUe7xjL5whguuIy98ba7zvxP8BbJdcyVowhc
IWasiBlS63gCxldbMVLHjJ0qUa3kzoQzhAw4WejsiPoyaof4dGeyG9aUWVl7DJAjV7VwTVmZxQrM
ynTVhZ+REULEujEdeq42HSchrpo5cjhhMN6I65TGNMD7BFPRBMbUgeUSUciON9s4Jv77QI4VU8yc
ZHKmpCL4ycw3yEw1yEHneTIzE7L6Kx+BEem15k4bPe7GAxNC3w0f0TAFTOJVLYkN3W2mu8u6s/wH
EB+obA6LDkUkhi3BFAVReJUhQ9aJJwcyMwdnuWnGU023s6kH5y/BQqBfw5tpioGJVAN3Dtk+h8Es
k49PRm3mlkBcgHHw0q2ET47XTeo5FWbteb/bhJRdNAxZVzQSb3a8atIoyo43I5HWzACweLCycTdr
vNZSPSgPwZqSEhbJELhNsrpzbkpchkm6IBdTR7N0WunxjvF/1/cb1PeOyW+BxuFyE/j5li/TS1vt
8hxvRehMwYovxwQno/vks/tKr5j7dtuFl5VzfYYYzpEZ+P9chw8LjkjXfD4qNEc3Flx4cI8leAwL
HLxy6o16H/1WzRA3ROUzAXiPZ99CIViQJkdmUL+AEsIUo30Io7F82oxc4Vn8cmTs038M3wZRVdFF
g2NAB60TEl1zt9yXmqrOUSnjfZ9T4b/k0igva4f18lF3He1EOskPXGpHd0Tn+WmecM/0O4xXHbMI
ZrG6epkxUn/wpFbgUZB1T+Zz/WC6qk6cNL7kUZYxbseryCSX86taaBBETOTxr/PL7rhMhEtkvKxw
llSm3+Cld8lSs9p4ix1d47ET0eODG/soAE0h8rAIln58E3WbZiUfSPMq5vLh28wcXqaT/YClGRP/
PF3uORVGLk1+2DcmVw7eBsejrxXvMpPZ4LKJemcHf5gaNewEU3yYrsW3OVni2w9c6/s4byrnu4Z3
PO0+pm0ejA3z+r1Iq7K8Ldonpvk2KbluvtUZw2Y4I1OhdLRoeZvmDXuQauBxn863mRYrGuTrG4jq
xPOAvOFmtRC4fCqgA/kP8gDwEkPbeUeL2UbuhOOhK1dRdyEW2j7eSmqji4ZYo1CuOBuv8jFyzwwO
CKXQU7bkj9XKlBKuoWgwRVD1VQneJLVGEC8WNArFnMrw6bWlFnnjsnqk2OkrFKxU6YLQVOHkC+Xe
KCoFRnRhjeaNYBN/00FIlhcGWRPn7GECIawpKWFJNtlx/eyURs7cSRO6KJY6xInUtFbgaaPOOT38
8fB/VK5O8wplbmRzdHJlYW0KZW5kb2JqCgozMyAwIG9iago1NDUxCmVuZG9iagoKMzUgMCBvYmoK
PDwvTGVuZ3RoIDM2IDAgUi9GaWx0ZXIvRmxhdGVEZWNvZGU+PgpzdHJlYW0KeJztXMmOJLmRvedX
xFlA5XBfgEQAWdsAumlUgA4DnULLQOgaQLr07w/fe0YP9wiPjNSg6tCJREtZZDhpK2kkzYx0j/7w
68M/D+7gRin3/BgOLfnHdvjXXx/+9LvD/z74A/77198f3PgQDt8fZqNw+MU6oOsvBgL/6tv/PPzt
dw/usYyfmyCEEkbr4vxo9/0h5PYYrRZyZqmPkh9dioujfDqE1Ngj40vKA1Bx6BVSRNn7x3o4PQQS
XHwGpORG2+LbY5rlEEaP01IrA6L1CP0xT1gxAOODYYmFWIg9tvGL0TVgVMACvSmMsnExYJSD8cfy
gFTKoGd+6YMe61EDMExItZxx1AYcwt0cy0ZVC6iJ3hbHX+PDysahauJdPSQTwZrSEhbJUdglX9E1
JS+KpRNxIk2tdHjaaHRqHAPh8F//yUH16/j/74fy//Gu+zev+z8+/EGGZPw3JvvHb0PLxODx99tf
Dv/xdViSdvj2t6dYjt/+8fDl2+ixMRC++0FYju4Rhsa3OshQzbcE+xSBzDeIL0ew7WtljzxKaZCb
I/r4CtHlBMCnB19Hz5QApdLKpfqYZ3moNhGOapm9UWoDh8EZjHrCIYaS2Zt4Sx2/GD1DaBCeUVox
yIyDCtUbbywPWMNwxuULlKIewYUFUnCgRjiCq+OrcAfXWRZVgaoVvcFD8eJilsWf1ci59aBEDJZJ
yrBQhoY9ZtEkaYtSaUEcSDsrvZ02WnzZKLzr+y3q+9oQ+Ma+CX83hsB/XgyBH2YgHQBj9IkNZNaq
1SI22CjV4rBteZTDIdY+6rWC3VjzYLHWMkpxIKkVdjBWEFabJ7ORVq027FhiaYDS8NfKPVBwswY7
bD16fywGq7kISMTRXCEOYG4ONlwUNU/hGqXNw7KKg+bjaCveVB6wOv61L71a++QgjAkpOaxSwpEc
rKlwJ9dYBk3JY0CL1uS9caCSOGOZHFtbSkIwpowEXdITVshU1Jike5X0SffUyVlbp43uXp7+71p+
O1q+nvSxEXIrl5M+1v1J74MD2SlzOPixbShW80Nwg4lUDp72KyUIzEs82Y0S/oUA/LBdKWetAw4C
SLmPvh1/UoGurFgoLlXGYhAP1rxiz0YwlYYboJsjaKJrWCKMjGH6SYjIG5yOJUBkj4VgGHoxxPKA
FBL76wv+Wg+a1wVWTOxDLGM32Cf2sUvskybuZo3SBONuHKhsrM0aeLYeFIVBmkISDglPuCFQ0SQx
i1YIXxxIJStlnTaqu7Pkvyv5rSh5Z533o2dxV6v8p2XC//MAw/fr2HkU7XVwGCRFcCXkARdQF5gh
VZ5EYM9GwwBLnTv+/nIIsbGbU23V8noEGtKxiRtnmYhNz1hvHLZ3pUCVF2ijrzgm1c6GYSCsoyZE
0TV28+y2brnn8ogeJjcOI5sAiYc01X6xI1uMnn1jghm8qKnlBsqdJfWn4Ns52nWwiHZ5o+v/fhq7
wX78UJ7883H8+Xj887ff75z0xiEaS8qkM5QVPqsZZVuqNxxtoNxxP/wUfDtySdgcXMtlvdPdDpCG
I8EkbKOGCxWlkK9rU2ErKPf2XD8D387qX3Bg2h0g0bej909uNTa2+4DObZ2RqJPaRGW1qZ2t5tZa
3UC5dwr9Gfj2TkFwr+yNjerdjS0RzftCmo8rFFYzYraEbpjYQLkjip+Cb0cUgSNtVxRf/Y39YcsL
ZbmsEKgyKdlSueGgnWfyS0L4sXiuma/7g+CWgaAtDgVr+7Toqk3rFFrnyVvT96Kmlhsor1lBfjS+
WytIKFhN//8ryEIn5+JCp2pG2ZbqDUcbKK9ZQX40vlsryLVc7qwgk7CNGi5UJBt+UZsKW0F5zQry
o/HdWkF2B8jrVpBJoozTRGW1qZ2t5tZa3UB5zQryo/HdWkH2xsadFWQhjXZqIU01I2ZL6IaJDZTX
rCA/Gt+tFWRfFC+tIJMyGvOJQJVJyZbKDQftPJPvrCA/EM/uCvJvGAgTJkNDi0pYW9AmELYoYVtT
yw2UVw2BH4xvfwhUzqF0tYJw/ej++ebyAQkbhdKKIVJlUrSldsPJAuD+UPhxePaHwpUEbg4FhQUW
1awFfqEMW6i2NaNjDeXOovlT8O0MhV5hDfaGws5aMf0BMaFXpZ90rGQVE67mRAq2/oDa6Y62Ja8k
NkSzyCBqzZ7lcysTC1InYH8AwzkL4/IE2huDt6iFDqZRHrrsdEpEp4hQj3RYDNa65+/wQWnnVGJm
cLg/KmStVSUynFxmeQaarRbM/CAEDZ+LQUpw0Q5YwpEaRC/MSfSRpuzocTJqGWcyLjL6GX8snwa3
YanB0ZKsR6TrecKKrhmO6ERh4+nZsSyqsJOMRq92leJjlsWh1ci79aBMDBZlZTgoQ2KOYdJj8jZK
qQnjIIi6s+5OG03e2Sq96/yN6nzvPJOZtJEuD3bxebUZWcxBiI1BXPo1Y7EyXKFhlMegiHDW5uIg
/gjkuTAHI3QGovE1hMZyUmA4KERdbFuJQHJdyp2OZ6tVZnaoPR3MBqlmMms4Km2qcFdRR5po5k6T
VuaXkIPmD+SqkZrEADt+S8Bm7RLiSQuEBJevwablN5yJYelJTWqskc4kyki/ypMzq5Fn9YAkBGlK
SDgkO+GWTEWVZC1qoQFxYHqZ2jqtNHdn7XvX8JvQ8M5Uj6ADELcTve1N9Egmq+/aOyhwzRqCzWO/
ENAwkskalL0RmQNSQ2DgGizVwNBxgY2pIZNM7ENQo6OVAqiB3meVo0d2xlKjBVSPmCck2ktAIg5Z
UuGOpFBUJbOUopfiMz4SBG0csoyweV1q2BGF2WMMlAVSwwbMcDTRR9wts2xUtcLaoLYVUkserGzc
qSa+1V7yEKQpKeGQDIVbsgVNU+aiVdoQD6als/5OG23eWfvf9f6G9b7jrmJ8cGC+MAp91ygw2WQG
YeoSYorZIgoDfzooQjlIDNy9oAc3KbSgnS2VIGqbHmwHGXThcUnFZJtBVuR+YGvaPMIITnsuwg5I
MhO+QILG/xgQPhltIVNOoDgg20WcsIj0FAialcTebJ0YOTIoqRrkRJKIT7tBo4PbRNGXSRKptqK4
sQoz3NQavM89JeggbMoJ+IbkRIPJM01n/SDzHKlY6eS0rrx8vn/X5G9LkzsTN7FBu9q37y/nnSnd
5gmoi2ufMg3FS9KhWJ5ZoJNSVNJ1C76pLSRW56lzePOidBvMLcpioLGzCvM3lSteDEatspiEXaVA
tnIad6F5jTtSx3wT0dwWOaloGlclyTGJ1kkefEFJ1SAnEcQsNJ4WjQ7qENRlEcTto4rixCrcdrEt
+RYMk4dgU07AR9mJCpOpqKOkV17ilV5OayXdWaTftfmb0+aNGTwwvubcLWDmkJT0WJFMfTNJa9k3
+QcZa56owrTYIaRF3yFPi40jV5lFoJr6jn5a7HF6mBY7RIhiajzWabGR2hRJR+xni43jills3WcR
L9pbmcaVAiZvsltkbVCgAUKWVohP2jI6pEXSJ92SahWNG6vUabHFu6BQIoJNOQFfcMu4M5mm6d02
m23yP+vltFbSa+bvuzZ/S9q8NX9DvFqB+ypvcKP2kniCSqZ35CVW33jS4cnF0Q9YcDWqNKZpZ2Re
ltKpCfgSC10IkWcDXKIq1Bxa5V5oMRPdIoARcrf7C9yCRew3smec3kPouhVSkLlJ7Xk6HVJuzM9U
gms6eOJKVDkSW7m5oiJ6HgWIsEHd0l6LTM7E0auxX4YF756a8NRexx2QxARIz41T5l8fkK+Yo7JI
Gx0fOEF5hgxzwznJ9wTZeLvw5UEF/KoYjDghIb8Rxhi0lmaXx5hiXp03f+s4LfrEDWG3k5WHpFPl
Oc0NmTPJPjqeYM8aO230tx4SK+eZA8W5w9mDm0GZl9MG3bwrUxw49Jk+at+I1/NUiatxmRKYvlgf
dC0Pq5H35DozW9bzUl9GL+X2llKZ50uoXO2U8VoqsnT9kINOutJpaZgqg4ZRYoZvdfZr4a2gyrEH
fODFU4qwPljpSs3maCKd1Y0RhiWylHlhEN52Zt3aOCx0bM1IAUfu4qvmBQP5vIOyMqXZNL3i9Hef
6G+vSJ/l9hm3fbkH6dHSaHkjqEWOkMR1HS4/zoUcbeRo/NOt2Lpxkzs0v9bYaaO/qeFtULrEJTDi
M6aSaj7rDiZTnZmwXKJ2Gz51qnSoJZVH3ZVEarTE46gYioQmSeFjic3KWWGDWUvsrZAFJ7AgFc/D
i+HgzoWYC+yrUVS6hpxorfidHNBrSc6qN0NQOJj4e0UWAlvT07lAqXVCr7x3KZyNA2VSw52c0dk0
iEm/lY0z1cSzekgWgiUZCYdkB8ySqCiakhal0oE4kG4WnZ1W+ruTDPCu5zek553Ie64WqNss3c5v
lu7VWs+VMEMd7DAwBwXq8/FDeHLxGJ6G2S3HD/7JfV7H7K+hBKz4hDJMzfjhRbxcMbi9mYQa3q/E
+0yEY2EZ+J1+Cvwp8W8/fsj4PZNOPz9+sp/RvBzb/KHYTwT2vGrZzgDi8UOd0PFzEIpPx2DYvL6x
+1je+W8A2mQg5o8GO5yb29+Pq6/PK6qjoQUUB2rrQsUFu4OJHX5nm2A/hM+D9dgILXw5iyGZTD8t
wnMrJr8cPzRr49u5kwhdfdzRw4rtKRE/IBip6itoIHIlSCfcsaBJ+Pry8PJpDpbXDi8fVldfNLxC
AyqjrEptYDau6SFzbirs40a5hQIM+tlNSM8b0VJC9mUl4WicG3S2CuVYzgIMyyB4PpP26Tz6vH0l
6BgXjUuZYVHPDgD1mbgj1FMmz+ehYyw//1vj8jy6TX6X02JhbFTmdJu4iybqaopTJOHjIjcfV4Mv
GtVnwb40Zvo6Kc8GwJa24I+jZsPeb9hfM/R5Jf8n67OSfLlS0iI10/xqwE0N3ZL6MtQ0cdaW4lLe
T6HOWf6SGFqdYnjlzGl5tYCYXa4+jgUg9jkg3WpUna30jnmKm99kSxfz4Gw8lbP5yPMLWw1h50U/
GCmmlvOI1xT6tHScKtbgMST1TOe04JfTYju4XpJnXdbXV8qzhstRuF7lvsxZuZrF5eZ8nNP/ej66
zQq3Xm3Ws1XjeZzlIakvG3tnlm21WF6PcaF7XhmTEDWBd/RxtvdubeTmWJo27+Patq2XGgN6Qxd6
8UQ5Ei9sItZmbC21D2GzdD6vbf5abOFSnK8cpFcgz6NxNT38eQZtFsa16V5vJahEWaBpw/xGb1eW
QhTanEiL9d3Pw40x2o6adzJD197ZAlTYUzPxi2FbHMqV+KVdOO/jMKhUqq7d8RDNG/k4EtPNwzv5
lirGXGsrM9ltSSLr9aD21bkl2lad3d4njuro0SPu6jrjZnylgHd5TkbvGGn8wqCyh4NDHKo8YMU6
f0+OKQFsz/yUBVKqZxyJSaXCnRmIn1TlyBrpzUxiAxdWMu5UE99sb/IgpEVSxGEyJG6TLalapE56
TR+xTi2t9HfaaPOO5/Zd729Y7zs+3iD32GXOVBkr026qenJ8gmoMjsQ7+yhH5aE6EtAjfVvxUc9w
yC/IyHaj15JPXkTuLAp9fSc+ScGHsQ66fgTfYZzlECyzRLXCzJL4OJ/eMkj2KJfh4HNdhjvC02pU
zQxV0Uvng3FBTyR5M59kctgs2e8ePkJr783hQUjJN8OQmKkizClMxwljBoFuAVKry1biYpbFn9XI
ufXweUIyORkOSpCYKVejyCRutFIXxsPQ0NTaadHfy2bgXctvR8s7k75Tfh70be+n3Jr0lQEYy5pN
vEqhWioMUjEQkwpD0fKZ8cGJxhBHRMgFDumSGTDRExP0vj2kzEcmKixfypGhHbJr5S4FqMYBYT2a
ns4grK7EFsPCt3EMe4eL3ejqCkiI4mIPjrgpOnJowqtNA51PgfjZlkNwgdIYtBF8PbQlvByCC0V8
h9No7YV5ueRB5cmd1RTjYw/JQ7CmpIRFMhR2ybbNfFpKnRSbPsiH6WmlwdNGn3cMwbvm37Tmr41D
Ksr0jo8XiRv+VtgXT8xlw//9ITNoiwdyBgUMdCUmqiaGNlPNjJEjlJWYf54Y6sNzPAjCUo/2kmXy
hQFdcBl744N3ncmg4C2S65grRxG4QgBZ4TPk2fE6jK+2Y6SOGUhV1lrJndlniB9wsdBFEvVlCA/B
6s7MN+wps1L4GC1H4mrhnrIypRWYlfaqNz8jw4UIfGM59NxtOi5C3DVz5HDBYPARLyqNZYBPCqai
BYx5BMs7opAdH7dxvAXgAzlWgDFzkcmZkorgJzP5IDPvIAdd7slMU8jqr+QEhqfXmjtt9LgbHEyI
gzdMomEKmNGrWhIbet5Mz5d1Z8kQID5Q2RwWHYpIjGGCKQqi8DVDxq8TrxFkphHOctOKp5oeaFMP
rl+Chai/hjdzFgOzqgbuHLJNh8EsM5FPRm3mkUBcgHHw0q2EKccXJ/U7FWbt+cTbhJRdNAxZrzQS
b3Z8bdIoyo6PI5HWzGiweLCycTdrfNlSPSgPwZqSEhbJELhNsnp2bkpchkm6IBdTR7N0WunxjvF/
1/cb1PeOyW+BxuHyEPjpli/TS1vt8lJvRRwt0uX0+ZjgZHQffXZf6BVzX2+78JIedDlDDEuYBg4t
1+HCgh/StRmQdOko9x08vANFoXN3fGmj9VfE8ejmsughW42udIPRozh+CYXFQZacmPB2sjpK+vYJ
/rKkPuw9EOHn+PnIOCgafj2SAiEvBm50J71DJB4iCWgd2wuBisB3oVevMpoI3Efh/sDYXJmEGtWf
RFClLIzPr3J1BnF+9u/NSd517xO5Jt/xzh3dE52Xq3n9PdMPMT51rCpY1erqY8bI/c5rXIH3RNY9
mez1nbmsuo7S+JH3XMY4Hp8iM2DOn2qhgRAxkXfDzh+747YRLpLxscJ5Upmbg4/eJcvbauMrTniN
d1JEjw9unKsANIXImyTYCvJL1AOblXwgB6yYC4hfMxN8mWv2HZZnbATm1XPPpTFyq/Ld5pxcO/ga
HO/FVnzLzHSDCyfqm90KYt7UsBvM/2EuF7/mZFlx3/HS7+N8vJzfGr7xKvxYxnlrNswX+SKtzPK1
6NyY5tekzLv5VRcQm+GMzJPSvaPla5qP7kGqgXeBOr9mWrBokK9fJqoTzwOSipvVQuB2qoAOJEfI
I8B3De0kHi2gG3kyjoeuREY9j1hoC/lQqY0uGmaNQrnmbLzK58gzNDgglELP2ZJcVivzTbinogEV
QdVXZX+T1BpBvFjQKBRzKsPH15Za5CPM6pFip+9QsFKlS0JLh5NvlGelqPwY0YU9mzeCTfxNtyRZ
XhhkTZyzhwmEsKakhCXZ4sf9tFOOORMrTeiiWOoQJ1LTWoGnjTrncvGHw/8Bs09TJQplbmRzdHJl
YW0KZW5kb2JqCgozNiAwIG9iago1NDc2CmVuZG9iagoKMzggMCBvYmoKPDwvTGVuZ3RoIDM5IDAg
Ui9GaWx0ZXIvRmxhdGVEZWNvZGU+PgpzdHJlYW0KeJztXctuZDly3esrcj1Ay3w/AEFAPboMzG48
BXhheJX22BiUDMxs+vfNc07w5qUyU6mxVYsWhOrOIu8l48kbJCOCLHfvD7/d/e3gDm6Ucs/34dCS
v2+Hv//n3b/+4fA/d/6AP3//rzs3XoTD091sFA4/rAO6/jAQ+Fvv/vvuL3+4c/dlPG6CEEoYrYvz
o93TXcjtPlot5MxSHyU/uhQXR/l4CKmxR8ablAeg4tArpIiy9/f1cLwLJLj4DEjJjbbFt/s0yyGM
HsetVgZE6xH6fZ6wYgDGO8MSC7EQe2zjidE1YFTAAr0pjLJxMWCUg/HH8oBUyqBnvumDHutRAzBM
SLWccNQGHMLdHMtGVQuoid4Wx6/xYWXjUDXxrh6SiWBNaQmL5Cjskq/ompIXxdKJOJGmdjo8Lhqd
GsdAOPzLP3NQ/Tb+/+NQ/l8/dP/udf/nuz/JkIw/42P//H1omRg8fr//x+Gfvg1L0g7f//IQy+P3
v979+n30WAyE734QlqO7h6HxrQ4yVPMtwT5FIPMN4ssRbPta2SOPUhrk5og+vkJ0OQHw8c7X0TMl
QKm0cqne51keqk2Eo1pmb5TawGFwBqOecIihZPYm3lLHE6NnCA3CM0orBplxUKF6443lAWsYzri9
gVLUI7iwQQoO1AhHcHW8Fe7gOsuiKlC1ojd4KF5czLL4sxo5tx6UiMEySRkWytCwxyyaJG1RKi2I
A2lnp7fjosWXjcKHvt+jvs8NgW/sm/C7GAL/dTMEfpiBdACM0Sc2kFmrZovYYKNUi8O25VEOh1j7
qNcKdmPNg8VayyjFgaRW2MFYQVhtnsxGWrXasGKJpQFKw6+Ve6DgZg122Hr0fl8MVnMRkIijuUIc
wNwcbLgoap7CNUqbh2UVB83H0Va8qTxgdfxtb3q19slBGBNScpilhCM5WFPhTq6xDJqSx4AWrcl7
40AlccYyOba2lIRgTBkJuqQnrJCpqDFJ9yrpk+6pk5O2jovuXv78P7T8frR8/tHHRsitPP/oY738
0fvgQHbKHA5+LBuK1fwQ3GAilYOn/UoJAvMST3ajhL8hAD9sV8pZ84CDAFLuo2/HTyrQlRULxaXK
mAziwZpXrNkIptJwA3RzBE10DVOEkTFMPwkReYPTMQWI7DERDEMvhlgekEJif73Br/Wged1gxcQ+
xDJWg31iH6vEPmniatYoTTDuxoHKxtqsgWfrQVEYpCkk4ZDwhBsCFU0Ss2iF8MWBVLJT1nFR3Y0p
/0PJ70XJF+Z5P3oWdzbLf7my3CfxcVigxLGAv1X7cbBahMX6Ycu1ZzW1XKDcGHs/Bd8FMQQsEONY
duVFEP/24PvjL2X8+k/+8+O/f//jBaG0vFE4tk8nRKpMilZqF042AD/uXhLG2+I5FwJnyXMZ7K3/
6hziinVTzl7kz9QxNuDnNaNkD+WGQ+Kn4LswGHrFUuTSYIi+PXr/4HZD4W8HLAx+G4MMU3TqhbRh
8s7juy0DBzBs8D0fpoad+miYaQw6jMEPmoaxfXEYiz8O+5bnghHS4GE6cnPw0KRKH0AjrAVpoI0c
+xQ0o7XItdAmBM91fpOFOLW7ipCLiJIdyY++wjlRO+W8ohzbL38oEduVgbTDA1OFpNFnkyGafatL
/kcoYWy5itDJY6LaD/OfgCBsYmJy9LAsNbVcoNxY3/4UfBf8LN2xBUz+c3tjFufT4/i5ZnI0pDc6
Q9nhs5pRtlK9cLRAufHp/RR8F+SSOuX4XC5XbRAW83UjbFHDMxWlkM9rU2E7KLc2QD8D34WleIH3
4uIAuWCD1kV5p0fRSJRhnKisNrWzam6v1QXKLZfQz8B3ySUR6d08Gxu+endlf8KJfyONk+FGmmpG
zErowsQC5TXLlbfGd2m5kq6MDvd1mA331dcrg6PljTwuGyYWVSY5K6kLG+30Od9Yq7whngtrlUC7
cm4nSvh2xVLIKNPdvpl21jYzlQonXvuO15paLlBeNZW8Mb6rU0nAzP3/mEomnfooJ52qGWUr1QtH
C5RXTSVvjO/qVHIml1tTiRG2qOGZisyYr7WpsB2UV00lb4zv6lRyaYC8cioxEs1KGSqrTe2smttr
dYHyqqnkjfFdnUrOx8bNqWSSJls1SVPNiFkJXZhYoLxqKnljfFenkguj4zVTiZEnq25YVJnkrKQu
bLTT53xrKnk7PJe2vRetxJWApwyyr3m3Q1BtM1Eu7fcES81aLlBeM428Nb5r04g+jP/7NLLRyQ9y
o1Ofp1G2Ur1wtEB5zTTy1viuTSPncrkxjUzCFjU8U5EZ8qW2KWwH5TXTyFvjuzaNXBwgL3hFIv2Z
lekPg7raGSTSEm/xF8QEp0tlBGQ0LJ7dOBdmyLdGR4ZOrUwsyHWCVYKNLpVu4z4IHTazZDqOUfMF
kaFER4Uvnq5cxXB87nT5wsviM6MwDW5jnyvdwggoH+98lpOZoyxnun/R1sodFB63GkWpHh3OFoPV
i4KvwtLbxN1FIaiC74dhXNKbHULD4gNl0A4OVR6QSt9qDImrPTNDNkiVXiThqKIPrelenhTVyhpp
VYxJPFjZuFNNfKuH5CFYU1LCIRnWkwdLVG1Sr37TRt90ttffcdHmjbnyQ+/vWO8X1izMYwLm557q
z7vF22YWonOWjsUdR29MwkItdKwXUB5rgA5GSoRtOo5apGNy2Mvu+RyMaZIsMTPJi57QOF0akWlh
ZZZnwpjVgm17kUoGsg1SKmTZcKSGpZswJ9FHmjIYOU5qmS9iXGT0M/5YPg5uw1aLDqpVj8gQ8oQV
XTMc0YnCRue/Y1lUYdEQjV4tIMTHLItDq5F360GZGCzKynBQhsQcw6TH5G2UUhPGQRB1J90dF03e
mBU/dP5OdX5p6ZqZfHluDj5dMgchNiZjZQyMWKwcIpZFOY9BERF0zcVB/BHIc2EuZehMKMPbEBrL
SQleQalmxVaeSAirW7nT8lmtMkNT7RkoNkg1k1nDUWEBDXcVdaSJy6fjpJV5ouSgDerAVSM1iYly
eKZ4ktol5IVsEBLS1Aw2N02GMzG9bFKTGmukM4ky0q/y5Mxq5Fk9IAlBmhISDslOuCVTUSVZi1po
QByYXqa2jjvN3dgbfGj4XWj4wqceQQcgrh96vzjvk8nqu3ZGSkBjDUljYx8S0DCSyRqUhRmZy1lD
YAIaWKqBKWAFNqaGTDJjSaxVJqNBADUweK5y9FhebTVaQPWIeUKivQQk4pAlFe5ICkVVMkspeik+
4yNB0MYhy0h/q1sNO60we4yBskFqWI4Zjib6iJsR4I2qVlgb1LZCasmDlY071cS32ksegjQlJRyS
oXBLtqBpyly0ShviwbR00t9x0eaNuf9D7+9Y7xc8E5VpkOH57N8uGoW+yyGJSLZWJcJPEXmcIiYu
TSi2wNULenCRQgva2VIHPWzRg+UgZMDcEismWwyyorAXW9PmEUZwWnMRdkCyuPAFEjT+Y6rG0WgL
mXICxQF7LXHCItJMIWhWEnuzdWJOrUFJ1SAnkkR8Wg0aHVwmij7md4hqK4obqzBTXa3B+1xTgg7C
dtrBUXKiweSZZjrSIPOUk7XTyXFfedkv/KHJ35cmL3y4iQ3a2br9+pe7ZV7ULa+EMg3FS9KhWL54
YL6FqMSKpoBvagsHpPLUOWLIUboNFpNnMdDYWYXnMHTmqxiMWmUxCbtKgWzlNO4CvR+m8cC8UdHc
NjmpaBpXJSkgjtZJ6SOCkqpBTiKI2eTcLRod1CGoyyKIy0cVxYlVuOxiW/ItGCYPwaacgI+yExUm
U1FHSe9SFHZ6Oe6VdGOS/tDm706bV77ggfE1+24Bm+HuugXzJVPfTNKa9k3+QcaaO6owLXYIadN3
yNNiY8tVZrHTc6lK9NNij93DtNghZrpABTvWabHHBgRmb9AR+8liY7tiFlvnUsWL1lamcaVyKwrp
NlkbFGiAkKUV4pO2jA5pkfRJt6RaRePGKnVabPEuKJSIYFNOwBfcNu5MpmlGRc1mm/xPejnulfSa
7/dDm78nbV77fkM8m4Evb6gBbos01i2OSqkiHEBZey7lTecKHlAvvvZps33zJ5uNkKLZbI9QvQqQ
6XFW+rTYvlNshNF1TlOwOx2WxNi5xhp09HKy2cjpNput9BDx0tvJZqtCqao1pT2hpGqQqRfho7Ym
HdSi6KNuRbUVxY1VsjQuvgXD5CHYlFPawjAK09aTzZakRXPd1o8qHvdKesUX/KHN35U2r3zBA+PV
QNgzpZdED0gyu43zQdU3eiroeXD04xdcUVAaj0tmnIAqpXM8QDqFLsDIvT0uMyjUG1rlXrjiSXRr
AkbIdB2mrC1UxH4h+84UJRhNnc4uOEFFfj2dhik3HobQQbMhI+JKVDgOmHFzREPah94CTGCDuZb1
bZGHpKCExn4ZK7DuaUk9rW9vDMBScdz4ZP76AGXlqNNcjY5LBjSZaJpbtcEyZOPt4gUPKhAXwWQC
D0cpWkyB1tLsEgce9azOW7ykD5knbui6eUYwoJDcoESHSBfoKNEDddLYcdHffkDsnN8OFOcOZy1O
6GdeEhEZcO2j3BmkZozJN+L19ArhiopMCcxYig+6HgNj2XtynXlqzfNyjYxeOmNXSuV5O0LlalUn
z0rFaTk/5CBPlXRaeABk0DBKCiQ7e8pwM6VcGtPSHONizXP1gJVqqdkcxaSzujHCsMQtZV7cgWhZ
NnOTqBvu2C3Sx5G7xZpocRSzCo5bemk2zagW41VHxsvGWOiKruHWHe4hOif4bifzW+QISVyXw2XP
byFHGzka/wwLtG7c5A7N7zV2XPQ3NbyewStxC2wik8BbzWfdhcIjhzw4WKJ2Cz51qnSoJZV73VmC
I4oSj6NiKBIZJNoiic3KWWG/WaPJUY/MD1iQilf8Xji48yDmAntpFJWuISdaqz8YB4w6kLPqzRAU
DiblECCNia0Zqdig1DqhV95/IpyNA2VSw52Y0dk0iGUyVTbOVBPP6iFZCJZkJBySHTBLoqJoSlqU
SgfiQLrZdHbc6e9WVsuHnt+Pni9kseRqgfZl6nZ+mbp3sS9mveDI3SlVNTABL3x5/CU8+Pz4i39w
Xx4D0pij+/oYrep+ffylPbjK9w1tXcfjbywOk8YXRQ8HrIxX4yeM5+4hBDwhdPfg/WOb8NStb+2N
gHAlQzTGaCMAJwIx9QWrydtZeNVKZJgAk4gSDTRqeMKVTsxip1Rp9HmTA0w4lyW8y8FSE7hcszKT
K7akhV4Pal+ZKSVI1dmtD8RRHXeQxF1d51qUt1vwSOjR6B0y5hsGMTwmZHGo8oA1lhH2PDmGoNie
8dANEs9EGo7E5Ejhzgz8TKpyZI30ZiZNgAsrGXeqiW+2N3kQ0iYp4jAZErfJllRtUie9po9Yp5Z2
+jsu2ryxz/jQ+zvW+4UdSdBy7nmM/urJrOR4ddkYHIl3PaAclffEFEdcaRK5itX1LVrHcl/YuMrm
VSmIP2Zem8b9SKO59vmgzGasdeMsh2CRTNUKI5nxfl7ZZpDsMjfDwWveDHfEzsComhlRopeTpXHB
lTN5szV0cpic7LnHmtbae5ugCSn5ZhgSI6PCnMKc6Omj4qENUas8bnExy+LPauTcevg8IZmcDAcl
SMyUq1FkEjdaqQvjYWhoau246e9lM/Ch5fej5Qsffaf8POhbT1Rd++grHQaWpZV4JEC1VOgUpeMg
FYY+tMbjRSWNW/IIFwE2UCVzg69rC7havEs5MfMJli/lSFcE2bVylwJU44CwHk1XrhBWVyDVsPBO
JcPO3Gmjq2sDLYqLXVTjpujIoQmvNg10XiHjZ1sOwQ1Ko5NB8HVBm/ByCG4U8f5Wo7UX5oGRB5Un
d1aTT5k9JA/BmpISFslQ2CXbNvO3KHVSbPogH6annQaPiz5vGIIPzb9rzZ8bh1SUWQhqV+PQr7gp
cTVhNvxPd5lORlysNCigYyYxMSrRFZdqpkeXZy2Y75jomsIpBTgNqUe7ATX5QgckuIy98aLEzuQj
8BbJdcyVoyjR8RzM3YO8DqZf+2orRuqYjj9lSZTcme2A/S4nCyUuqy9dTnCudmZaYE2Z75VwDfqQ
KFW4pqxMoQJmpVnprthI9xYctZgOPVebjpMQV812nmOYfzrLcBPXmAZ4FWUqmsDob97un+U5FI5W
Zp36QI7lEMucZHKmpCL4yQx2Zca5clAyeWZYLKu/gmF0p+41d1z0eNGZleC3bfiIhilgBplqSWzo
WrztOIqCb5nHVKBsDosORST63MAUBVF4Cyb9rYlpq5lpK7PcNOOppov91IPzl2DBS63hzRyZwCj+
wJ1Dts9hMMvMt6NRm7klEBdgHLx0K+GT402lek6FWXteDTghZRcNQ9btnsSbHW8pNYqy66xRTfRe
igcrG3ezxhtR1YPyEKwpKWGRDIHbJKvrCqfEZZikC3IxdTRLx50ebxj/D32/Q31fMPkt0Dg83wR+
ueLcGptu6qc9P1sqT1bK0zH1GYeQs/vVpemj2p05XSAycJTDnHPi9JbBTQW3F/xkwRX6rL6+DCVA
eIQyuIL77QU3XWSAhTZ89dLFAq9ZINXi5ZP5y/A7vXDZfHGV7jbX0HrvaPtk7wUhbbXNnXdy4skf
5z0FFQpO86uJMF6GGujv82n0M3+enH10K8oHaI5EIioG8jMffTIPJJDXx/bgI/t+fYz9pD/QtIcs
OvYOx88bC+HLya+4p1Sw+MSnE+rB63wfFvC+PbbZK+xI1e/nM5j59CSk56wZxcSRN3amssypCu53
SFewLw42jyl/HTqk0E0iKPhPZ+7YTYLzpbTpH6HMpCdsE31aGA6QGx8N1Qfz927OYQmhAMqEa5qX
nucwqWdK+nwS05lUx5jQdwesNwTC063/yNfX99cCmYu8QUZ7UiW6uJeVMyl9PpG/jagy/uy/kqHh
X+ocfOn0Ies724+WvIzPL6cxa9TwN0a23X3HYWccls4GUDijL9uo2ACcPkZ32bDMKMC5CTjpbJqB
fI6bopuDPu4EtP+INWL2H0zYMJi8bVTu5WCyXS1NWBh8aaxw+/LStxOldpPNrzsT7JagyE6X+5ER
FiFx+O/AvUbUYS/pOe7UP8RHXzdl76zHs+HykgDqFk965bdSwzN5zdjRtNje7QbdSUJbsOc00OPy
rG/iWcyjmY3zoNIwVHOkSKifdyZrUcdmSmyIXpubXvfVvHTz0cyO0qU6Mw3HrtiZF4qsl43sLyJZ
oLzm5qO3xnft5qML15ncuvloI83HHQq7aMeIWQldmFigvObmo7fGd+3mo0sXmrzi5qNJHi8hmlh0
I9EkZyV1YaOdbqC5cfPRG+K5ePPRpZHw9Yq90DkRd1rYhm1uhVXAF881AgyCa3OZPT45GUF8qGOp
UviNjjfN9dEp8gXbFBa7+zK60gig1TdMJIAezIzio4UJSrAKNArE9wmvo4Ox6KoMAF5t8NUTYfPN
Vt8JVHhbvz4DJVq/8ZkXUVdnnSCn0GnFZjIh//5hz14j+94QN2P2m2aNoPj7KXI+R0TXCX5o9+ng
IwOmPfH2nFzox4Tv5omZjUola7uXVNkTD+TiXF/fvWLA4IlnEgIPD+plSeZY8+Nl9PPMoV4yZpiq
iIlpHkLUy+7kkMWrik+rcoLBq7G8xP4xIqrwxMhJ5dlCdRy7sEMK/Cclxt8MpQaN5vFOriVXSWzi
wWIEV3XFMZJKCqMyEEHSOUpmIvJt09nFhnetWdBUcAPvHoi8fvhp7FRniFmSRV524LlM9M2BuWDF
G1zldEUeo3jCv79yrzw58Rqa3vJfyDlkXh9VeCoSb8fMc3pXFJWZt0RH3cewvdWh7WZYEa/SedR6
emv3nf35LinpnZexPJljN/tokM+vFNuouNMREdVwN3TjP7Ux/z2fyFw9pATx/Ijj5VnMXUw8l8bk
t5SVrMobolKTS97cK9GKWYmXNmYLvaSMVYEDuxij0kUh8IU+WaEtdE+IoOrlOBGpNYJhsaCRKOZU
RgS9bbXYlVRJx1BU9N7cObyRRliy64Y7R/pWjaqcixFrom86+8/yxhxr4jqXKYqoeIRkBPgSnbBK
pKJnCluUSg3iQOrZK+64qHHOcH86/C98Q/ktCmVuZHN0cmVhbQplbmRvYmoKCjM5IDAgb2JqCjYw
MzkKZW5kb2JqCgo0MSAwIG9iago8PC9MZW5ndGggNDIgMCBSL0ZpbHRlci9GbGF0ZURlY29kZT4+
CnN0cmVhbQp4nO1dy25kOXLd6ytyPUDLfD+AgoBSVbWB2Y2nAC8Mr9IeG4OSgZlN/755zgnevFRm
KjW2atGCMLaazEvGkwySEUGWu/eH3+7+dnAHN0q55/twaMnft8Pf//PuX/9w+J87f8D//v5fd258
CIenu9koHH5YB3T9YSDwX33777u//OHO3ZfxcxOEUMJoXZwf7Z7uQm730WohZ5b6KPnRpbg4ysdD
SI09Mr6kPAAVh14hRZS9v6+H410gwcVnQEputC2+3adZDmH0OG61MiBaj9Dv84QVAzDeGZZYiIXY
Yxu/GF0DRgUs0JvCKBsXA0Y5GH8sD0ilDHrmlz7osR41AMOEVMsJR23AIdzNsWxUtYCa6G1x/DU+
rGwcqibe1UMyEawpLWGRHIVd8hVdU/KiWDoRJ9LUTofHRaNT4xgIh3/5Zw6q38b//3Eo/68fun/3
uv/z3Z9kSMb/xmR//D60TAwef7//x+Gffh2WpB2+/+VTLA/f/3r37fvosRgI3/0gLEd3D0PjWx1k
qOZbgn2KQOYbxJcj2Pa1skcepTTIzRF9fIXocgLg452vo2dKgFJp5VK9z7M8VJsIR7XM3ii1gcPg
DEY94RBDyexNvKWOX4yeITQIzyitGGTGQYXqjTeWB6xhOOP2BUpRj+DCBik4UCMcwdXxVbiD6yyL
qkDVit7goXhxMcviz2rk3HpQIgbLJGVYKEPDHrNokrRFqbQgDqSdnd6OixZfNgof+n6P+j43BL6x
b8LfxRD4r5sh8MMMpANgjD6xgcxatVrEBhulWhy2LY9yOMTaR71WsBtrHizWWkYpDiS1wg7GCsJq
82Q20qrVhh1LLA1QGv5auQcKbtZgh61H7/fFYDUXAYk4mivEAczNwYaLouYpXKO0eVhWcdB8HG3F
m8oDVsd/7Uuv1j45CGNCSg6rlHAkB2sq3Mk1lkFT8hjQojV5bxyoJM5YJsfWlpIQjCkjQZf0hBUy
FTUm6V4lfdI9dXLS1nHR3cvT/0PL70fL55M+NkJu5fmkj/XypPfBgeyUORz82DYUq/khuMFEKgdP
+5USBOYlnuxGCf+FAPywXSlnrQMOAki5j74df1KBrqxYKC5VxmIQD9a8Ys9GMJWGG6CbI2iia1gi
jIxh+kmIyBucjiVAZI+FYBh6McTygBQS++sL/loPmtcNVkzsQyxjN9gn9rFL7JMm7maN0gTjbhyo
bKzNGni2HhSFQZpCEg4JT7ghUNEkMYtWCF8cSCU7ZR0X1d1Y8j+U/F6UfGGd96NncWer/Jcr230S
H4cFShwL+K9qPw5Wi7BYP2y79qymlguUG2Pvp+C7IIaADWIc2668COLfPvn+8EsZf/1n//jw79//
eEEoLW8UjuPTCZEqk6KV2oWTDcCPu5eE8bZ4zoXAVfJcBnvrvzqHuGPdlLMX+TN1jAP4ec0o2UO5
4ZD4KfguDIZesRW5NBiibw/ef3K7ofC3AzYGv41BhiU69ULasHjnMW/LwAEMG3zPH1PDSX00zDQG
HcbgB03DOL44jMUfh33Lc8EIafAwHbk5eGhSpQ+gEdaCNNBGjnMKmtFa5FpoE4LnPr/JQpzaXUXI
TUTJjuRHX+GcqJ1yXlGO45c/lIjjykDa4YGpQtLos8kQzb7VJf8jlDCOXEXo5DFR7Yf5T0AQDjEx
OXpYlppaLlBu7G9/Cr4Lfpbu2AIm/7m9MYvz+WH8uWZyNKQ3OkPZ4bOaUbZSvXC0QLkx9X4Kvgty
SZ1yfC6XqzYIm/m6Ebao4ZmKUsjntamwHZRbB6Cfge/CVrzAe3FxgFywQeumvNOjaCTKME5UVpva
WTW31+oC5ZZL6Gfgu+SSiPRuno0NX727cj7hwr+RxsVwI001I2YldGFigfKa7cpb47u8Xbk4TYYo
fvVXDmstb5RxxzARqDIpWalcOGinmXxjm/KGeC5sUwJNyrmJKOHXK0ZC9pie9s2qs7ZZqFS45toU
XmtquUB51SryxviuriIBi/b/YxWZdGo+TjpVM8pWqheOFiivWkXeGN/VVeRMLrdWESNsUcMzFZkd
X2tTYTsor1pF3hjf1VXk0gB55SpiJJqBMlRWm9pZNbfX6gLlVavIG+O7uoqcj42bq8gkTbZqkqaa
EbMSujCxQHnVKvLG+K6uIhdF8eIqYpTJoBsCVSYlK5ULB+00k2+tIm+H59oqcsFE3FhFfM27s4Fq
m4VyaX8aWGrWcoHymlXkrfFdW0U0L/7vq8hGJ+fjRqdmp1G2Ur1wtEB5zSry1viurSLncrmxikzC
FjU8U5HZ8aW2KWwH5TWryFvju7aKXBwgL/hDIj2ZlYkPg7raGR7SDm/xFMQEd0tl7GM0LJ7duBRm
yLdGR4ZOrUwsyHKCZYKJLpUO4z4IHSazZLqMUfMFMaFEF4Uvnk5cRW987nT2wr/iM+MvDQ5jnysd
wgglH+98lnuZoyxnOn7R1sodFB63GkWpHh1uFoPVi8KuwtLbxN1FIaiC14cBXNKbHYLC4gNl0A4O
VR6QSt9qDIarPXNCNkiV/iPhqKIPrelYnhTVyhppVXRJPFjZuFNNfKuH5CFYU1LCIRnWk+9KVG1S
r37TRt90ttffcdHmjaXyQ+/vWO8XtizMYALm5z7qx912ZTML0TlLxOKBozemX6EWOvYMKI/NYAcj
JcI2HUct0iU57GX3/B2MaZEsMTO9iz7QOJ0ZkQlhZZZnqpjVgp16kUQGsg1SKmTZcKSGnZswJ9FH
mjIYOU5qmSliXGT0M/5YPg5uw1aLDqpVj8jg8YQVXTMc0YnCRre/Y1lUYdMQjV5tIMTHLItDq5F3
60GZGCzKynBQhsQcw6TH5G2UUhPGQRB1J90dF03eWBU/dP5OdX5p65qZdnluDj5fMgchNqZhZQyM
WKwcIrZFOY9BERFuzcVB/BHIc2EWZehMJcPXEBrLSaldQUlmxXaeSAWrW7nT8lmtMjdT7RkiNkg1
k1nDUWEBDXcVdaSJ26fjpJUZouSgDerAVSM1iSly+E2RJLVLyAjZICQkqBlsHpwMZ2Ji2aQmNdZI
ZxJlpF/lyZnVyLN6QBKCNCUkHJKdcEumokqyFrXQgDgwvUxtHXeau3E2+NDwu9DwhakeQQcgrhO9
X1z3yWT1XScjpZ6xhnSxcQ4JaBjJZA3Kv4zM4qwhMPUMLNXA5K8CG1NDJpmxJNYq09AggBoYNlc5
emyvthotoHrEPCHRXgIScciSCnckhaIqmaUUvRSf8ZEgaOOQZSS+1a2Gk1aYPcZA2SA1bMcMRxN9
xM3Y70ZVK6wNalshteTBysadauJb7SUPQZqSEg7JULglW9A0ZS5apQ3xYFo66e+4aPPG2v+h93es
9wueicoEyPB89W8XjULfZY9EpFmrEuGniLxIERO3JhRb4O4FPbhJoQXtbKkrHrbpwXYQMmBWiRWT
bQZZUdSLrWnzCCM47bkIOyBNXPgCCRr/xySNo9EWMuUEigPOWuKERSSYQtCsJPZm68RsWoOSqkFO
JIn4tBs0OrhNFH3M7BDVVhQ3VmGOulqD97mnBB2E7XSCo+REg8kzzUSkQeYpG2unk+O+8rJv+EOT
vy9NXpi4iQ3a2b79+szdci7qllFCmYbiJelQLFM8MDYuKrGjKeCb2sLVqDx1jhBylG6DReNZDDR2
VuENDN32KgajVllMwq5SIFs5jbtA74dpPDBjVDS3TU4qmsZVSYqHo3VS4oigpGqQkwhiHjlPi0YH
dQjqsgji9lFFcWIVbrvYlnwLhslDsCkn4KPsRIXJVNRR0rvkhJ1ejnsl3VikP7T5u9PmlRk8ML7m
3C1gM9pdt1i+ZOqbSVrLvsk/yFjzRBWmxQ4hbfoOeVpsHLnKLHZ6LlWJflrscXqYFjvETBeoYMc6
LfY4gMDsDTpiP1lsHFfMYutGqnjR3so0riRuRSLdJmuDAg0QsrRCfNKW0SEtkj7pllSraNxYpU6L
Ld4FhRIRbMoJ+ILbxp3JNM3IqNlsk/9JL8e9kl4zfz+0+XvS5rX5G+LZCnz5QA1wW6SxbnFUShXh
AMracytvOlfwgHrxtU+b7Zs/2WyEFM1me4TrVYBMj7PSp8X2nWIjjK4bmoLd6bAkxs491qCjl5PN
Rja32Wxlh4iX3k42WxVKVa0p7QklVYNMvQgftTXpoBZFH3Urqq0obqySpXHxLRgmD8GmnNIWhlGY
tp5stiQtmuu2f1TxuFfSK2bwhzZ/V9q8MoMHxquBsGdKL4kekGR2GzeDqm/0VNDz4OjHL3icoDRe
lMy4+1RK53iAdApdgJFnezxjUKg3tMq9cMeT6NYEjJDpOkxZR6iI80L2nRlKMJq6l11wd4r8ejoN
U268BqErZkNGxJWocFwt4+GIhrQPvQWYwAZzLevbIq9HQQmN/TJ2YN3Tknpa394YgKXiePDJ/OsD
lJWj7nE1Oi4Z0GSeaW7VBsuQjbcnFzyoQFwEiwk8HKVoMwVaS7PnG3jJszpv8ZI+ZJ54oOvmGcGA
QnKDEh0iXaCjRA/USWPHRX/7AbFzfjtQnDuctbibn/k8RGTAtY9yZ5CaMSbfiNfTK4THKTIlMGMp
PuhhDIxl78l15n01z2c1Mnrpdl0plTftCJW7Vd05KxX35PyQgzxV0mnh1Y9BwygpkOzsV4abKeXS
gA+8eEoRuwfsVEvN5igmndWNEYYtbinzyQ5Ey7KZm0Td8MRukT6O3C3WRIujmFVwPNJLs2lGtRiv
OjJeNsZCV3QN7+3wDNG5wHe7k98iR0jivhwue86FHG3kaPwzLNC6cZM7NL/X2HHR39TwevuuxC2w
iUwCbzWf9QoKLxvyymCJOi341KnSoZZU7vVaCS4nSjyOiqFIZJBoiyQ2K2eF/WaNJkc9MiewIBWv
+L1w8ORBzAX20igqXUNOtFZ/MA4YdSBn1ZshKBxMyiFAGhNbM1KxQal1Qq98+UQ4GwfKpIYnMaOz
aRDLZKpsnKkmntVDshAsyUg4JDtglkRF0ZS0KJUOxIF0s+nsuNPfrayWDz2/Hz1fyGLJ1QLty9Lt
/LJ072JfzHrBZbtTsmpgAl748vBL+OTzwy/+k/vyEJC6G93Xh2hV9+3hl/bJVX5vaOs6fv6VxWHS
+KHoxwEr49P4E8bv7lMI+IXQ3SfvH9qEp259a28EhCsZojFGGwG4C4ilL1hN3s7CR1YiwwRYRJRo
oFHDu610Yha7n0qjzzccYMK5LeErDpaawO2alZlcsSUt9HpQ+8pMKUGqzt57II7qeIIk7uo696J8
14KXQY9G75AxvzCI4bEgi0OVB6yxjbDfk2MIiu0ZD90g8Tak4UhMjhTuzMDPpCpH1khvZtIEuLCS
caea+GZ7kwchbZIiDpMhcZtsSdUmddJr+oh1ammnv+OizRvnjA+9v2O9XziRBG3nnsfor6bUJ8dH
y8bgSHzlAeWovCemOOIxk8hdrB5u0T6W58LGXTYfSUH8MfPBNJ5HGs21zwdlNmOvG2c5BItkqlYY
yYz387E2g2TPuBkOPvBmuCNOBkbVzIgSvVwsjQvunMmb7aGTw+Jkv3vsaa29twWakJJvhiExMirM
KcyFnj6qwGWM1CqPW1zMsvizGjm3Hj5PSCYnw0EJEjPlahSZxI1W6sJ4GBqaWjtu+nvZDHxo+f1o
+cKk75SfB33rLaJrk77SYWBZWolXAlRLhU5ROg5SYehDezw+UdJ4JI9wEeAAVTIP+HqwgLvFu5QT
M59g+VKOdEWQXSt3KUA1Dgjr0fTYCmF1BVINC19TMuzMnTa6ug7QorjYEzVuio4cmvBq00Dn4zF+
tuUQ3KA0OhkEX0+zCS+H4EYRX241WnthHhh5UHlyZzX5lNlD8hCsKSlhkQyFXbJtM3+LUifFpg/y
YXraafC46POGIfjQ/LvW/LlxSEWZhaB2NQ79ipsSjxJmw/90l+lkxJNKgwI6ZhIToxJdcalmenR5
14L5jomuKdxSgNOQerS3T5MvdECCy9gbn0jsTD4Cb5Fcx1w5ihIdz8HcPcjrYPq1r7ZjpI7p+FOW
RMmd2Q4473KxUOKy+tLlBOdqZ6YF9pT5XgnXoA+JUoV7ysoUKmBWmpVeiY10b8FRi+XQc7fpuAhx
12z3OYb5p7MMb3CNZYCPUKaiBYz+5u3lWd5D4Whl1qkP5FgOscxFJmdKKoKfzGBXZpwrByWTZ4bF
svorGEZ36l5zx0WPF51ZCX7bhkk0TAEzyFRLYkMP4m3XURR8y7ymAmVzWHQoItHnBqYoiML3L+lv
TUxbzUxbmeWmFU81PemnHly/BAteag1v5sgERvEH7hyyTYfBLDPfjkZt5pFAXIBx8NKthCnHN0r1
OxVm7fko4ISUXTQMWe96Em92fJ/UKMqus0Y10XspHqxs3M0a30JVD8pDsKakhEUyBG6TrB4qnBKX
YZIuyMXU0Swdd3q8Yfw/9P0O9X3B5LdA4/D8EPjlinNrHLqpn/b8bqk8WSlPx9QjLiFn982l6aPa
3TldIDJwlMNcc+L0lsFNBbcX/GTBFfqsvr4MJUB4hDK4gvvtBTddZICFNnz10sUCr1kg1eLls/nL
8Hd64bL54irdba6h9d7R9tm+C0Laaps77+TEkz/OewoqlCE4ayKMl6EG+vt8Gv3MnydnH92K8gGa
I5GIioF85E+fzQMJ5PWhffKRfb8+xH7SH2jaQxYde4fj48ZC+HLyK+4pFSz+4tMJ9eB1fg8LeN8e
2uwVdqTq7+MZzHz6JaTnrBnFxJE3dqayzKkK7ndIV7AvDjaPJX8dOqTQTSIo+M9n7thNgvOjtOkf
oMykX9gm+rQwHCA3/jRUH8zfuzmHJYQCKBOuaV56nsOkninp8SSmM6mOMaF5B6w3BMLbrf/I7Ov7
V4HMRd4goz2pEl3cy8qZlB5P5G8jqsxZJlUYpHU2ht3YliDYY8rboLOVpuNusOadhkXal9PongOM
oGO84Kafc+cMgBkUw81hWRY97qal0bM3RW7aoqum6HE31sxyTLuzmyFzlGzyHvJ8aItBokjG3J9y
M+MhjNGoPgn2pSHDU8yzAbDSpmlhxsEv7O8Z+rqTv02lveTLmZI2qZnm93MjvCz1bahpOu8Xh7NZ
FbQ8hG8viqFuwaVXTpwankltBpKm+fZuN6ZOMaQt8nOa33H5TfMfo3KxlSa/8wjTEHXetINx8riz
X7sJtFvnTMHXFqq5PjyfFOvQeukVpJkqpQd2Zk6OPbczXxdZXx7Zv0qyQHnNK0hvje/aK0gX3ja5
9QrSRpqPOxT28o4RsxK6MLFAec0rSG+N79orSJdF8dIrSJMyPkg0Eeh1oknJSuXCQTu9RHPjFaQ3
xHPlFaRLT9zsQzbP9vf0jrjTJjds66yMwpiJfUwr2YNRaWNOzrVltGjuy7BzNI1YWkZb9cF3rKgG
4Is268MGYIs45jz6/josgGYvdhZWtW9fiDM6Q66OgZ+SMDWA9jQ/X4RdyFYwQ+WFKxA3KbG9sOIE
/ns9u9fyw7Zp8/Ow8Q3GKu2pf8a+kTDFU/a2aBsVXbf5oeGng48MnvbEl3RyoU8TinxilqPSytru
I9MUn3g5F3f8+u4TgwdPvJ8QeJFQH0syJ5sfH6Of9w/1kfHDVEVMTPNCoj52J+csPlU46SrXF3wa
W02cJSMiDE+MolTeM1THMQ8PKfAflhj/ZVg1aESPb3IzuUpiEy8ZI9Cqh46RYFIYoYEIku5UMiuR
X5vuMTZ8a80CqIIb+A5B5CPET+PUOsPNkixytAPvaKJvDswLK97gKr8r8krFE/4VlnvlzInX0PSV
/07OIfMpqcIbkvg6Fp7Tt6IIzXwrOupthu2rLnA3w4rYle6m1tNXe//sz3dJCfB8mOXJnLzZR4N8
/rzYRsWdrouohheiG//Bjfmv+kTm7SE9iHdJHB/SYh5j4h01JsKlrMRVvhaVmtzz5mqJVsxKwrQx
W+gxZdwKHNgjGZXuCoEv9M8KbaGrQgRVLyeKSK0RDIsFjUQxpzKi6W2rxa4ESzqJoiL55trh6zTC
kl033DnSz2pU5VyMWBN90zsALG/MsSauc5miiIpNSEaAL9EJq0QqeqawRanUIA6knr3ijosa5wL3
p8P/AjMx+gIKZW5kc3RyZWFtCmVuZG9iagoKNDIgMCBvYmoKNjA0MgplbmRvYmoKCjQ0IDAgb2Jq
Cjw8L0xlbmd0aCA0NSAwIFIvRmlsdGVyL0ZsYXRlRGVjb2RlPj4Kc3RyZWFtCnic7VzLjh25kd3X
V9y1gS7z/QCEAqRqyYB3nhYwi8Gsru0ZGNIA9qZ/f+KcE8ybWXXrYUC96EKh7RJ5k4wnMxiMCGa4
jadfb/55CqdgrTrrbTqNEm/H6V9/u/nPP5z+7yae8N+//ucm2IN0+n6zBqXTN5+Aqd8cBP7Vs/+9
+fsfbsJts5+HIKSWbHQL0cZ9v0l13GbvpVrZmtaKNqWFbO3zKZXBGRVPSjVALWBWKhntGG/76XyT
SHCLFZBKsLEtjtuy2inZjPPWawbRZ6R5WxesnIDxxrHkRizEnof94nQZjA5YoLckazsXBqOdnD+2
DVJrRs96Mo0en9ETMCxIvV1w9AEcwj0C207VSOiJ3pHtr/PhbedQPfGuGZKJYC1pCYvkKOySr+ha
khfF0ok4kaZ2OjwfNLo0joVw+o8/cVH9av//syn/H++6f/O6/+XmLzIk9p+97J++mpaJIeLv17+e
/vjFLMk4ff37h9zuvv7j5vNXm3EwEHFGI6zmcAtDE0c3MtSLo8A+ZSCLA+KrGWzH3jmjWqsYuTVj
TuwQXS0AfL6J3WaWAiidVq7027raptpCOOpVzkZrGA6HY4xGwiGGVjmbeFu3X5weExqE55R2LDLn
oEP1zhvbBssMZ96eQCmakULaIKUAaoQjhW5PhTuFybaoSlSt6E0RihcXqy3+vEfOfQYl4rBcUo6F
MnTsuYomSVuUSgviQNrZ6e180OLzRuFd329R348NQRycW/D3YAjiz5shiGYGygkwbE4eILN37RZ5
wEapl822VWunU+7T+r2D3dyrsdh7s1Y2JL3DDuYOwvqIZDbTqvUBjyW3ASgDf709EwW3erDDPmPO
2+awRsiARBwjNOIA5hFgw0XRiBSuUzoiLKs4GDHbWPGmtsGa+NefzO7jS4AwFqQSsEsJRwmwpsJd
wmAbNJWIBS1aS4zOgVrijG1y7GMpCcFYMhJ0SU9YIVNR45KeXdIn3UsnF22dD7p7/vV/1/Lb0fLj
lz4PQh7t4Uuf+/WXPqYAskvlcojmNjTvRROcMVHaKdJ+lQKBRYmnBmvhXwggmu0qtWofCBBAqdPm
TvwpDbryZqO41LHNIJ98eIfPRjCdhhugRyBoohvYIpwMM/0kROQZp7YFiGzbCMzQiyG2DVIqnK8n
+OszaF43WLlwDrGYNzgXdvMS56KJ3qxTWmDcnQO1nbXVA88+g6JwSEtIwiHhCTcEKpokZtEK4YsD
qWSnrPNBdS9s+e9KfitKvrLPR5vZwqNd/n574f95guH71TyPJl8Hh0FShFBCNbiAusFMpfMkAntm
AxMsdZ34++2U8uC0oN5u5OMV6EjNibOzTIbTY/tNgHvXGlT5AG2OHcekPjkwGcJuPSHKYXBa5LT9
SEd7tGmTB7IGzdhyp9ep3jf3QdOY9JtSwjp50NPIA5SXPOrfAt81jy7zcAhZHHXdY3jCvHOpbqTZ
63RB4T0n5kjogYkDlBdE8ZvguyKKBAavi+JLfGKvG3WjzA7JFwTqLEqOVB442AB8u3lOCD8Wz2Pm
O963a7zfP7EItLIYptjWJ3ub4AtI21bksaeRByiveh9+ML4n34cEq/bvvQ+LNEl9kaaeE3Mk9MDE
Acqr3ocfjO/J9+GqKJ59H5wyLU1HoM6i5EjlgYMNwMvvw4/D89T7cIX3/fsgzrEE7KwPH2Tajmkq
aZW+CXqx4fBRuK9E22sqPQTu1HXSq0BwLlY6+gOeSaydnkdh0DBW+TH0PWqlh4Gx3p4Iu523HqMS
mjGx+zus2XS+F5Y5Fu4pCkFVDYHhR9FbA6IP4gNt0A4O1TZIbW49Rl00nsHHDVIv8K2Eo4s+jKYH
syjqnT3SqmOMePC2c6ee+NYMyUOwlqSEQzIUbsmWVG1S73HTxtx0ttff+aDNF17Fd72/Yb1fMYkM
lQNzfXAUHtfMQg7BI/6F7udgnB+9NGGT0LbNZtJ/zUHBQzupw7c1yzsjfwdjaQZmNCrzCNOzG3L7
MjMPbbVXTsJ7yf0DZCtAtkMqjSw7jjKwMwhzEX2kqQYeTpxahiSdi4p5zh/bZ+M2bT345MVnZEYp
Fixzux1HDqIQuHMMbIuqHCN7oBft4Xystjj0Hnn3GZSJw6KsHAdlSMw5LXpc3k4pNeEcJFF30d35
oMkXYmHvOn+jOr+SF7OjLvJ7j83BvGYO7KDLeD+PwLl5G6dms6nVFkVOPEsHiD8DeW1M16XJnAWe
pjTYLsohJGUzmvu5yDn0rT1p+bzXmQTUeMYiHFKvZNZxdFhAxy0XSDR1JC3Pi1amIsnBiCdyNUhN
YS4GvxVg83EFoccNQkF0wGHTMXOchRmMRU0Z7JHOIspIv9qLM++RZ82AJARpSUg4JDvhlkxFlWQt
aqEBceB6Wdo67zT3QnL8XcNvQsNXXvUMOgDx+KJ/vLrvMwURMreAjNSdOhlRvMzkfC4nxa3MGiUa
KsygPaKwJkeqbMDtGyw/0hzMCHqzuN1nR6EAjiZ7hJGCzCthJ6QehS+RIPsfw4Rnpy1BO6I4wa0S
J2wiaQF7zE7hbI4uzNA4lNIdciFJxCfD73RwRxB9lSSRam+KG+8w76nR4H1tH6CDsIOcNUpONLg8
RRulLIol+4tOzvvO88fMd03+vjR5JXtVOGC80mOfLPRRoI3SU4cyTS1K0ql59jExYCgqGUYF39QW
ym3q0jnialm6TR6iZBPTz6vDrL4qiJrD6F2pUMLuUiBHBa27xIOOazwxCyGaxyYnNV3j6hQFCRMz
CQQnKKU75CKCmJukY+h0UIegroog7hRqihPv0MJyLPkWDJeHYFNOwEfZiQqXqaijpHcR251eznsl
veCLv2vzd6fNJ95gw/jqnXcFBiU9diTTOFzScV7sdUoy1nSe0rLYKZVN36kuiw3vqq3mZJBCnRyX
xTZHYVnslCujHYKd+7LYSHhl0pHnxWLDM3GLrSpH8VLCxWKrI5lytGTtUKABQpZWiE/acjqkRdIn
3ZJqNZ0b7/RlscW7oFAigk05AV8K27pzmZYVZHWb7fK/6OW8V9Jr3t93bf6etPnU+5vyM4fkB2pv
OFB3OiLQO7LVPQ4WArFYJfDI31Aw2waLdyry8a1NagJhg8bTAjyYztLaRs1hVJ2NFrPwBAQYqU6v
aqMLluFv1DiZLIHQVSvYkM9XxJHni1IHs/YqeyinSFyFKke5A50rKmJWa0CEA+qW9kZmyh4h2MF5
FRZ8RmoiUntzMFbLegI6TpV/Y0IMt2bVFgyecRj7ZPKuDpz/4iyQTfQy4Di97BmLERUGyHrDGIPW
NrykmIVHPUQPrUyTeaFDSJnTATRJF6ymnoPJnKVXGYGZvcbOB/3tl8TunBxAcZ0416FetLJkOTM2
O609Gc9mOCoO4o2ZTxL2nUipKuwSk4q1sRvFSK4raygiS70rZqnio7XO6g9C5W6nOojWUbsRTQ7c
sm6k0zYqI+/FWoo5B/+VkWlKuQ3gAy+RUoT1wU7XevUzJenswVYYtsjWVhk5AmusxfB12HiGXUFB
rtwtLMWyM4W3UuCRQJotKwDG0NaZobWOogq6z7gDQh9kZi+uYJ3oyFwhhfs6Tvd8F2r2laP1zwjC
mM5NndD8XmPng/6Who8F4C1vMVAkHaL3YlVlPgtgWMbSsryNWCZVamop7VYV9CiYkXgCFUOR0CQp
eymxebsqQrh6hbMVneQLLEgtKtQvHPRciLnBvjpFbWrJidYeT84BAxTkrEc3BI2LSekGZEA5mkGN
DUrvC3pnNb5wDi6URQ09OadzaBGTfm87Z+qJZ82QLARLMhIOyQ6YJVFRtCQtSqUDcSDdbDo77/T3
UgLsXc9vR89XEl61e0z+sHWHeP3eR87ZBcjCrDQlKo9HQIQM6SfuQb14SF9Cbwz2M+nAwlwFERrL
cmEBuauzMNeTACxz8TbTGFt6YPaTxnfmJAWpBy/hJY4e6MARdw+TYRKWKsfI/Vv09pj5BJiwG5rN
JYdqGyzbhf33Akw+npHHDVLpFxwFfx13jWw7VTWzR3or0xPgwlvOnXrim+NdHoS0SYo4XIbE7bIl
VZvUSa/rI/elpZ3+zgdtvuCov+v9Dev9ikuf5A09jIa39OW6YSiB99BscRQW7qKdlWFkMQHq0zOd
QNXiyw1kIHPQSWXdO+ryK+/A0Z0ftHaxsna/01XMq51kA1evse493677dw7Jb+Y5Dt7Zc9wZjrVT
tXKPopd7jXNBx5O8uQtaAmy7/x7hEvr46PsbIZU4HENJwe24HfTS2id5REzcBUhtSTg0iIvVFn/e
I+c+I9YFyeXkOChBYqZcnSKXuNNKXTgPpqGltfOmv+fNwLuW346Wr7z0k/KLoO9YE/fUS9953vZ8
KKrep/dKY0yC5+7SGHmUi8Sq88ETbcYJG+ePVnk+Vp05na2bUllp3mH5Ss08yZNdb08pQD0uCJ8x
VD9PWFN5DMfCCzKOnVVKTtfU+VMUN791EJboyKELrw8tdN4HiGssl+AGZfCMLvi6bSe8XIIbRbyM
77TOxowreVB7cec9hXQ4Q/IQrCUpYZEMhV2yHStTSqmTYtcH+XA97TR4PujzBUPwrvk3rfnHxqG0
udUdHI3DU1E+3DOtjv/7TWWMDrdkjALGNRAGq6wRRLsyJMqqRlYWFEZ2UA+ImBv16NfZS2yM34HL
PAdvvSKT0slbJte5dq4icIV4oaIlSKuy0Cl29xipY8bNlKRsdTLZiOMiNwuVCGkuIzaITU4mOuFT
VmVsGRztKTPlAx12BmIzD6fdL/5nRocQ58R2GOltBm5C9Jq9ctLMP2NNuFZl2wDvFZemDYxh4+1j
Aqz45GplfUdM5FjxpMpNplZKKoOfylhzZZi5JpVtVUalq+YrFs1o5F5z54Men9g4FD9uyDvt18Z/
oZI8h5/v8vwQ7sOnWO/ah/A5lPDlrn4I6e6/v/752raCMOrAS2mmZbDklr0isejO5FZIqlh6ZYEp
Fg+X2YRiC0NgEBIF23hFmuHPwoKTyiz0ag/toOrp1qdmcD8ULASN9bow5Z2YlDPcNVV/vUx4LNA5
O7WVRwxxAUGCl+ktvMK8xq7fuQB8PO+NLkg1ZMdQdfWbeGvgFXanqAbeuCKtlcFE8eBt5271eF1e
MygPwVqSEhbJELhdsrrLuiQuQyddkIulo9U67/T4wmbyru83qO8rW8hINDYPD5X3hw1kZ1aYdalp
7Tj5FJOsSr37KX0I+S59iCm0u5/iBzMymzG5BiWBVUIxGuyHY4zroR+MwBwt+CLU8d4DL7Abwham
4Q/2k5ky2rOmTo6x340PMd/9NECXDc7VfggFzRQxlM0Yw0c+TfY0fXqeAW5V/xYDEdvOAwa+UHAf
9wzop8SfSJb9vFhyVvVwcYrhDfzohxY6+cLcsMZ+dECbgMaCZkOy48Fv/rjs8HzSqHtMLk6pkARs
Hh8fDSK9TirBpbIjQr/Eu1hcTRquIb4PbbDWfhUdtNA47M/BedxmLeg/O6GfNI6K3w1qjjNuAl5y
vyLgvQA/7qB+FG520mesGOnp/tl1M/cX/rQIDgL4uF+ICbiLE7V+3JO1CTlt9IjcpdL1ari2xrbW
ry+qpcG05/Ah06u9XymL9WSyz8NF8pwcRl9yeOXrQyf6KLg0oFgnv0tGeA/yonxbsktP+rtJstFE
PFxW69ljOV+4DNn1tX/LUoM79fGikroToEi7v6h6vX0EbdZmvZpHY0VPjWv6uBaw3g6W69Px/XFi
rk31d69cqPKXt12o3hjLsT02HuUgoZ3UjI4neUh42t3Q7Kzes8ukb5mQVy6Tnh6a2J3HS9LCjuhn
X/x8+M0txt3YFDd2ewxEvBnUx9rZCfmqhoTJ9SRZOZJ+ofMg4Z2WjkrapHm4JZpUqeF1tapf9yJO
r2bPWdFnRfYf9Lzccw/lpY/W/Rb4rn0oLXueoj486dgh6C7ylb8uEl1NXiTqru5C5T0n6kjwgZkD
lNdcqP7R+J66UP1YJC9eqN5Ii3mHwntOzJHQAxMHKK+5UP2j8T11ofq6KJ67UL0o493mhUCdRcmR
ygMHG4AXL1T/QDxPXKi+xvvjb4rErIMd4ja4VcuYEGt1HnzeI3Z96qzwbIhrrjgxZVaSohwqMgwk
VV1G+mI4kserqDlcfPq07LVZxYijBKy2tsyCtziuY8ZnmM1yh90OhhS7kv1GFwB7S5j2e+YkDmps
znCfoj2YUTP5Y0LzPmLeAeMVbGh+2UdIrpjXVfh8+CTIg8+FyMA96PlnIvZQXmNefzS+p8zr469U
vMK8OnCvJT18FeLBFyOcqGPPvxSwh/IqkfxgfE+K5NGHCq6LZOpWJsrDvuODRUwxT75WfM8rc8n2
aCIyiMhk3z2siBZ85yWrdOr8MNHlIeszv7P8PJuflPja/XLTdBnchIDCNbpQ61FvDMqImMybW5eH
MzD0jzS3Pex4OzvL6fDQDkq3KrUc9hRZumFPFydmZk8lAWhJKFNDIWLSk6wvpXXygbLN5ml8Pq2s
yWd56HdEe06dePiM4c3McPN3j3MoPY+nKfDWasezyuLU5pfIf/ELfJlxJHuaWLLH8ks+rcULWb/j
k4236yu0fDbwLFA8lRfhWlqfVsqM7GxPm3J/ZT0tKpZdT3U9cDjOzNLG3MD99rSsrydBqsjBFkoe
6QNEjbJDflD2wQ9SOp4b3AMY3kuJIfEGOlDPpKwuL+J7NjV71CIzu5lPU7XH+s5V06cQGhMYXF0M
hmkVqrzC16vqRpgHBQeE0lj9sNWD9s4SMcbFGbQSQT12XdggqT0XmiL81SoUc2qjTmNsvcyvaWpG
yZP1H4KFbwdMx4KAWnTsNaukTXQh7h6dYBf/0B1GtjcG2RPnnOECIawlKWEpHnBkTiToWgh9VRe6
KJY6xInUtFfg+aDOZW3+cvp/GeUJsQplbmRzdHJlYW0KZW5kb2JqCgo0NSAwIG9iago1MTYzCmVu
ZG9iagoKNDcgMCBvYmoKPDwvTGVuZ3RoIDQ4IDAgUi9GaWx0ZXIvRmxhdGVEZWNvZGUvTGVuZ3Ro
MSAyOTM2Pj4Kc3RyZWFtCnic7VZZbxtVFD53xku6Zm1JcaF3Oi0UMs5WtkopuImdZmkTYztlDJFg
4t44k9pj4yVqKlUpiKVYogIJaFW2pFRCCJCuA0KVQAgEPCCoEIvyAEUghOCFPoDECyIp544ni0ok
/gBjz73fOec727Xn2IVckcF6OAEyBBJpI9tACOD1OQCpS0wU6PDmU27EP6IuPJpNpr/ZNfsrgNSK
N0umJkeffXr8WwDXGbRfGGPGYV93sAXAHUb5tjFUPDx/jxflkyjvGEsXjqqkpwrlN1CuSmUShgbD
CN1v4+JJG0ez9fJWLMD9HsrUMtLs3U++W0D5Et692Uy+0ADjVwDW7RL2bI5lG5v+eBPlHpSb8SZg
l48dAfHY8v/XM/A0PAFvQi+cgzi0wC2gQTs8AHeDCkHoBAU+hE/gS/gIzsNj8Bw8BM/DNHB4FQIw
BY+QF2CLPOe+y/0a3Oeu5aBxqO/nN4d13jcR56De1cg9TfreuK07HqffcFLf3OjnRKPf8vVNfi5p
/RE9pMYVP5c1s5HyQFhXeCDu5y5NuCqqckz/3ncx7kOePu+7HPepCnc36bx7Im4b4nGM59Y2DN/r
5x6tvJ2cxOz05PCwjwOG8WrlHbYqsKSq0upq6Z4WP1+j0eMiyccYhnJ5Z69KueuGPg5hvcRKBhXg
Dp+ixH0lW4pUJJFwbaW6Gl+NghHXafQru531Gm3h3qZhndL9arcxTnV6eKQSQvA2iMyYmpbo/lK3
oZZoSbXTqSI4DyAT+xMKHmBCQJ+Ndqa9c42K4qNzJTwGdOrFaoac2hSbVq2pdM5JrlK9P+pTOInr
JWyoVy2ptNRbUg3hUHERm5/XiI+hDuuuFQ0IUHdVAyWxqcb4Ays7Ea71GjZRelwcW99hteTlNKx3
+D5AS4P2FgRIoLOT9F+ogQTYqyAP6WKN6OoIVq92+nAjaieefCCizwKFrkTnLKEEN04TfAvbuphr
k8ZRi+eCi198ayX8boJ02D2Ek8kLzWUCLR2zXlf15fayx32pY1aWEEJZFmq3UM96PTf+3TFLhH53
rVK7U6lVghJd2EHOLIy5h/56Pei6CGIi/ICzZMo1DRtgJ8yipol7Ly7uhG9s4a45vu4ivsvVpAla
2xR64w01t9+m0Gs213g9sn/h95enp18m1WTDK+fOvTIzLV0/PTMzM//zzAxAZeKM7t7tOv3lL/dX
d/wJ26rsh/Az/6fPrnwo3VPYGc5A7LNyoZ/30PzUCsrVs0uSfoOgZ1jUD5WxSexz2ujEkFCWYLNQ
y4u+28lLS3GmlmISWIsScby8OB0qWEb9Uw52IT7rYDee1XkHe1BfrmBcGuFdBxNYA187WIJauORg
GWrgso2JzZ93MPLJJgdLsI1c72AZ6sjeSme4KGTQwYKfdbAE15BJB8tQSyo1i6Y3kRkHE6gi7zgY
6yHvO1iGevKFjV24bCU/OVjEX3CwBHWS18EybJW24MkQ1xqUF6RbHUygQd7tYPwM5P0OllE/5GAX
YtPBbrhWPu5gD+pP70rcRNtbW/fQaNGiB81ELpOfzBdYOk97rUTz2lhPKBKiwcFQlA4MxmhI743G
aMWnrY32FVMms+iAMcIKa8ORUFcoiMQO/53LHtGhrq5QKLjsM5gyJ0yWoz1GKpUpDGaZFZ1Mj2RS
EZYspozcsmIZHWK5vJmxaFtre3P7snpfKkVjk9lMMmdkx8wE7WZGoZhj+QNmsgIcAluydGXSaYyz
ROjOWIkCRs7TwlKcB4srIsQyxQLL09H/4tGhfJGlUnZKtkgaNfOJMTyeg2eTKTMxdoSZBWYtulg2
c18xf4yhzSpaybyRQ/tAJpc20LLE6y5axzC1SWOmExWDHmAVa6xYKDCK9EXWooFmzRcptlu0zH+X
RI8wK81yR66uBklsybSfpRmzkG5ksyxljh9ZURPswml7Ew7SdmjF1x5EUSiChftBMNGWgwzkYRLv
AjBI407xh99CSzM+uDHogRBE8KY4XgdxjyIaQBTDPQQ6cqM2XpmnDV8U+jBPCnMwO9sAGDCCuIBR
w3bELryDTsQO8MOdq+aIwhAyBVewV8szaGeZsDPlUO7BTCl8ZTDXIGTt/FHsMI35M6iPoCZp12Yg
fzXGarpDdvQ8ZsnY/bRh/nY8o/ZV2fZstK8rSWiAVa4L5MqjnDwJ/bwqrJcJORUvd4t/D7wG/xg1
RBCciF+Hv/LDepw3NAH8A5dHaRsKZW5kc3RyZWFtCmVuZG9iagoKNDggMCBvYmoKMTY1NwplbmRv
YmoKCjQ5IDAgb2JqCjw8L1R5cGUvRm9udERlc2NyaXB0b3IvRm9udE5hbWUvQ0FBQUFBK09wZW5T
eW1ib2wKL0ZsYWdzIDQKL0ZvbnRCQm94Wy0xNzkgLTMxMiAxMDgzIDkxN10vSXRhbGljQW5nbGUg
MAovQXNjZW50IDc5OQovRGVzY2VudCAtMjAwCi9DYXBIZWlnaHQgOTE2Ci9TdGVtViA4MAovRm9u
dEZpbGUyIDQ3IDAgUgo+PgplbmRvYmoKCjUwIDAgb2JqCjw8L0xlbmd0aCAyMjIvRmlsdGVyL0Zs
YXRlRGVjb2RlPj4Kc3RyZWFtCnicXZBBa4QwEIXv+RVz3D0sUaE3EYplwUO7pbY/ICajDdRJGOPB
f98xa1voIYGX977kTXTbPXXkk37lYHtMMHpyjEtY2SIMOHlSZQXO23SovNvZRKWF7bcl4dzRGOpa
6TfxlsQbnB5dGPCs9I0dsqcJTh9tL7pfY/zCGSlBoZoGHI5yz7OJL2ZGnalL58T2absI8hd43yJC
lXV5r2KDwyUai2xoQlUXRQP19dooJPfPO4hhtJ+GJVlKsnpo79njdKf2sX7agF2ZpUmePVfYH/eE
v98TQ9ypvL4BivRtowplbmRzdHJlYW0KZW5kb2JqCgo1MSAwIG9iago8PC9UeXBlL0ZvbnQvU3Vi
dHlwZS9UcnVlVHlwZS9CYXNlRm9udC9DQUFBQUErT3BlblN5bWJvbAovRmlyc3RDaGFyIDAKL0xh
c3RDaGFyIDEKL1dpZHRoc1szNjUgNzk0IF0KL0ZvbnREZXNjcmlwdG9yIDQ5IDAgUgovVG9Vbmlj
b2RlIDUwIDAgUgo+PgplbmRvYmoKCjUyIDAgb2JqCjw8L0xlbmd0aCA1MyAwIFIvRmlsdGVyL0Zs
YXRlRGVjb2RlL0xlbmd0aDEgMTk5ODg+PgpzdHJlYW0KeJztfHt8VMX1+Jm59+7d9yub3c1z72bJ
5rGEPEgIgUhuIIloRCIEmqCpCSSYKJCQB4hViPgAgw9846MSaVUEWzYbxESgRm2r1lporc++8mtR
xMpH2lp8kd3fmdlNCBX7+T7++/26y9xz5sw5M+ecOXNm5iahu7OnBYzQCwKoK1Y3dSy5YGYBAPwS
gNhXrOtWYNfMqYiPAsjLVnZctfrWA3/bCaArBZDeuWrVhpWHbslIBLA4ANzXt7Y0Nf/yoafNABnb
sY8ZrUhoCW+Wsf4q1qe0ru6+Nt7wWh3WP8F63ar2FU13lr09ByCzAuvTVjdd26HQF5A/sxvrypqm
1S333LpnH9bvA4jb1tHe1f0OZEcAShXW3tHZ0jHz1TnvY10FsP0GaQS/7GNEVMPqVBAljazV6Q1G
k9litdnjHPHw/9FHeh6SeXkKkkU/JANEjo2XcFvkGGtjkH6MzkqJltgnBM/AOySTKDBIvgIXfEES
SD5cBCJ8jtGyD8bgfnBALTxA7DAFnLAELiIi8gTgdvJIZF3kBFwA98CuyHNkc2QPtt8FP4cvUIM/
igSK4VLkXwItcEL4AOojD4MWtoABZsMi4oQmeBu//0Qd7oX74Cfk+sgXOKoDNmN/pVAO5ZEXI2cg
G24Xt0vv6p6Fu+Eg0URWRNogFdKgjwYib0f+BH6ohx/AM6hTgIyI88EL18AtsIMkCD9H7H74IYSJ
kTYI86QXcKSLYCmsgfXQB3vgF8ROaqR3pVOR70WOgwbiIBN1aoMTpIgsoE+IxsicyPtwOQzDq2gv
+46Il4tPSZeHyyLfj7wE8fAc0ZND5EWpQLpz7MbI45EfY0T6IR89cimOsxxughfhNfgb/J1uimyC
+bAYR/4ZSSEK8aPH36YJdCPdKLwJ09DaBtS2B3ZCEGfkeTgIh9E3v4NR+IA4SBK5mCwnd5O/UyNt
pkeER4T9wm9FIj6N/vZBOvqoG56AA7ie34AjRML+80gNuZq0kwfJ98koDdJP6OeiVrxJ/Fock/zh
0fDXkUsj/wQ3JMIlcB1sQt/+AAZhP/wK3oK/wz/gNLGSmaSVPE6CZJR8QnU0jS6kHfQB+gT9kXCp
cLfwolgkzhWvEd8Q35dulbbJTXL4zJPhe8M/Cv868lzk1xg7ZuzfD1Xo0RsxKp6AF+BN7P09+AP8
mcUP9j+bLCPfxVG6yFZyH/kR+Rn5NfkYrQT+TaOzaQWO2k470U+b6b30Phz9CH6P0vfpH+hf6T8F
SUgTZghrhceFoDAkHBU+FK2iX5wm5osLxWViBGemQLpQWiztlvZKL0mnNKWaZk2H5iN5s3yz9pdj
2WN/DEO4NRwMD2LsajGSrkNPPAa7MO734xz8Aj36K9R4FD7DWUgkXpKBepeQKlJNFpDvkCtIC9lM
tpB7yA7yCNlFfowWoA1URt0DtJwupk20hd5Mt9A76H78Pk9fo2/Td+lJ1Nwl+ISAkC9cJCwTLhfW
oA3dwkbhZvTs3cIe4YjwpnBc+Eg4ibPmElPFHvE68SHxKXG/+GvpEmk1fndJL0gj0q+lM9IZDdUk
apI1uZqrNbs1f5Y18gy5Rr5N/q38D20HSSbZqLkyOVvQBFyDqXQPdYibyEkkpBARLGh5AOdhMa6K
f0CZEMZ5MbN21C2eJohxTFKjikGU7yYHoYj8DDZpqICZWByFEPk9HRVfphfAW6SRJIhPCWukX1Av
7MVstJ0eogfJXNhPS+lS+qgA5AOyGz7AeL8W7iPXkC7YS06SWeQGUkw2wW+pU1hMbobSyC4qEh25
iJwC1ABuFJvhu/8+C5IS+D2cCD8mmsTrMT8NwQM4o8/An8jT8BWRIp9gdhMwGzVhlrkd4/0WYFmv
AdfZJlyPCZhBVmmOwH62o8jFmjnidXAKvoQT0vMYUXMxkx4Pt4mPiX+JFEdycIXhKoPduO5a4UJc
MR9glBzGOqtdgStdj7mkAFd1DSyDZrgBs97dkWDk0chNkQ2RdngdZb8iU8lXpB9XxBBKlMKr+L0L
3iPbcB1e+D/bBcLNMAIfEzdJJwW4Hk5K66Tt0h5pv/QT6Q1NPnr7ZngEI/rPGM16tGAF/Bo+hs+J
FucmAaZCIeo7E3Wvg1W0XjgM80gidOCazcQ8PjdmSRf2shm99yiu58O4Nk5hnrgCfgLvEkpcaNEK
HF+L/VSjn69E7idxBm8ig0hpxqydDX9Fu81kJu3G8VTs6QHMWiOo0+/hQ/R2hOs1FfNCBVmKfX0O
34FmHGEG1JABnIEDUIKZtUL4Jfp7CrHCXJJGfohyjbhCzZACJdJfCIWp4UsjM2mbcBj3mAjS+3H3
SoILyFrUwoJ2jEE8WQhF4UWow5tEEIPkN1yLh2hLZIuwPrwKXoencU5UcZ2MJxa1vFYtm3NB6exZ
JTOLiwqnF+Tn5U7LmRrIzsrM8KdP8aV5FU9qSnJSYoLb5Yx3xNltVovZZDTodVpZI4kCJTC10lfV
qAT9jUHR75s/P4fVfU1IaJpEaAwqSKo6lyeoNHI25VxOFTlX/gunGuVUJziJVSmF0pypSqVPCb5R
4VOGyLLL6hC/o8JXrwRPcnwBx7dz3IS414sCSqW7tUIJkkalMli1rrWvsrECuxsw6Of55rXoc6bC
gN6AqAGxoMvXMUBccwhHqKty1gAFrQmVCib6KiqDCb4KpkFQSK9sag7WXFZXWZHk9dbnTA2SeSt8
y4Pgmxu0BDgLzOPDBDXzgjIfRmlj1sA2ZWDqSN/tQ1ZY3hgwNvuam66oCwpN9WwMWwDHrQi6rjvm
PlvFzu3z6rZMbk0S+irdbQqr9vVtUYIjl9VNbvWyZ3099oGyNL2qsa8Kh74dnVi9WMHR6C31dUFy
Cw6pMEuYVVH7WnyVjNJ4tRLU+eb6WvuubsSpSewLwqIN3lBiojocGYXESqWvts7nDZYl+eqbKpIH
HNC3aMNggqoknNuSM3XAaos6dsBsiSFG02SkZaKNY5ydYdWLJjxLmEa+izAggsoKBTWp86FNM9mj
ZSb0rZiJbPipJygVbMYZaQvq5jX2WWcxOpMPSulWn9L3T8AI8J385FxKU4yiSbf+ExjK4mQi1LB9
HA8GAsHsbBYi8jycU9RxDq8X5UxdN0Rn+DqsCgJ0H9Sgb5vqZ+Wi+71eNsHbhlRYjpVg72V10boC
y5NCoOYG6oO0kbWMjLfEL2EtveMtE+KNPozk/fyiEB/U+if+WazOuMrWWUHi/DfNLdH26sW+6suW
1SmVfY0x31bXnlOLts+caIthwbh5dUISjWE0SeCtGJRXTDCzSp0xKKbjPw0P6uaggEHJCUSpClob
50ef9Xqv91tlhmTtJKGhyCkmxcFZsZiWwVmBc+uzz6mfo52xT0B9RT+trl3W16c/p60KE1BfX5VP
qepr7GsaivQu9ylWX98wfYo+1ddR2Tg+oUOR57clBatur0cjWsksDFYKcwd8ZOtlAyrZunhZ3bAV
b3dba+tClNB5jXPrB6ZgW90wHlVUTqUTVFZTWA2qCQZ6iGp5U9KwCtDLW0VO4PUVQwQ4TTtOI7Bi
iEZpVk7DTw4eY9jkS/jFU4EMc/dTEtbIQ7RMjQNJDAugl8UwgQStRgpT4RDxgw4Pw25wB6ynS8dK
L7V+VrpgrBTKELeewUd+ntfmtaXjg+AB44wijJxRJfgaFHEEx8KbCIhf4D3MgnvRejVdIw07ht3C
hRK5SnpbonZbuslshiRrOjrDAlpnxj6ZyEORkUGdoRCVul11elLyUhpTOlJ6U6QUq0XBI0QedjtE
tw0m5y92B1CfBqbQAuva04G1C06iYkw1e0ku1w0a1pKG6Tav4nLiJqXRyBqfL4FOL5gxo6jQn+H3
3U9+R8yLNu5Z/uClV7/24q596+Z9d35Rv/S80/uHfVuG2mzxY++IL4Ubpy0vr2k16dGlW9BtxeIc
sMJuNfNBiejMZLG0UuqRhFx7nbnV3GEX9TqL0WOkdxkjRlpmXGikxiG6Xs2SZQJ6gWr0maCz6vJ0
HTpRl7jJvtNOr7Rvsu+zH7WLdiv4iTBEslQDpb2kH08XCbayYZIM3NC1aOVJK5uDhrWnGxIWHAM3
s7bsZMPazhLcn0kDmgvVQdfi6mARhvqAvmBmPTR4cW7iZ8yYXuCS/b40jcZG+sPHiTTvmorG+u9c
eMHsRbmi/8FrKor+Oa18T/hv6NxFkY/Eh9FGE56PHlTnf0SOaz+P+zxefIV+hFOWICXoaL11adxS
Z737QbpDs0P7oHFI9xb9nfR73VvG49JxzUcm61Pa1+kvNS9rf26UerS3aW7WCrYh2h3SG1wIVIco
O0rkxMakjiSaZPZCQmJdOTdxwclLcSLZNJ4sO4nTt7aBNKydV6fq2qwr7SudbW6RNKBJpCGu0I4W
QbwDfGlT/OkOJ84pTinat6hv7NG/kcLwa5/cE/68jygPrFlz//1r1jxA024nmr7wK5/+LfzyzZHd
j+3e3f/o7t0sRregvffxGE2G7w+DPfKFmm8oKU66MInal2qW6pc6l7rrkz+XNUXibNPsuKKkSrHa
VB1XmXSf/JBObzTjNEEis06SHcy6OIPBAnqXV5vYkUpSrVlU8FvYpBpJB/TieAkpZeXjE3pyrPTD
cZNLmdFlpTGz0WrDSs1K/UrnSndbssTMDmAk29BsPGuh2f6M+DiH66zhW0jC5tBL4fDY8OUDqr3w
og0NN918Vcut0vNjp+4LHw9/GT4Vfv/y+kdp9hMLO3buPfD499kbpXvx8QzaLsDiYZAiI2qWTV+m
SjUS7ZWCeNM6Kn0qSR6pUdok9SNBQlMxRaBFBHCZqjrvlEJIEMtKuT2BWGpgNpC1DZ1c33tJgvT8
V1Vodzn6OQPjygHJ5AfDYEU/VxlKHtI9bHrAult6Sn9Qd9A0lKjVOsh8eqGmSr8wdbfpgOZA4iv6
V41v6981fiF/bjIlW5Lj1aSUwnjVbCu0xL8QfyReiGcZw5JaxqHZhZDeoRotZnuNudFMzW47wYYD
CUmFZLqdqT2YohRymJYVhYGcKHQnc6hazJbCfrZLWlHtK+12nNVB0WB3s9mdYpDBS3LjvQvNxJyY
m3planvqzlQx1eLVqiZLoTYhpS06uwEWzA2nGxac/IzFM25iqsOtZjrK3GqqBR9JVnwk28oC+Kkv
G8N2Fnsjg8hhZ8ogE4fIx2BonPWzhrUMBrgAYIO9hCkdcjEQHNTp5/BqubcsAIz/WMBmL2ngw5tV
9JKZDWpmw5tVdBbwTjFdBgKdgUApsU1nmWQtRhuRNBqfkuEvsgIuNcHrZLEW58dYkzUu+hVxzzix
L/zXW9qI482TxK4ZU4XNTXOXZQjXLr2itJSQRbkPP/7s3X/Ai1Yg/Er48A3b5pNV122aN6+Lxd1G
vFXvwFjIILOHIQtd3oBxh+MZ4zVOY6FQqC10F/oqaKW20l3hMypCbtZiXWNWb9bOrB9qnpKfND6r
edYYzDqaNZplhqzcrBpseCHrT1maLDUxubAM6728UZK9opyY4uS5R/ay+UsVZavNlpGUnOzP0BPQ
WKx+u01dVtRoI+02glmqSrUkJvlTkpHWnkwak0ky0van+/0ZBFdxCCCDh5uujEF1BuqdgawZajmW
UixTMgoz1FkXFOZmHMn4U4ZgyfBk9GYIkKFk5GVEMsSMhMy/RJcLpu1A9BNL7KdxZnHbOr22gQG+
kEqt/MsyA8FpBCw4PZ2BtZjrSSAOE/v0AqdrBn8643G5FWbwJM9R/zi6kQjbRlY+kFe164qeXZkp
4eMpGZfNbp0WPp5aNqO8NSd8XPTf/XTtkiW1V15RsWOsnl752LTS+dseCFNa9ciyqVU3PzR2Bkjk
DNkjttPrMQF4n80jKqa9IXqDqgOaKEHCvavQpmPWDyF3wcmG/DyhyBsvil1kz29+g7N9D54C6jHL
OCGkBizEQ0rIdDrdOpfMtf2RfEl0suSUptA6W6tNIoTGOWz2OMFBiYXNV4og6/R6R7zeCWDQ+7U6
VZlSuE9HIjqiS3SzKXCmTSnc7u530w73KTf91I2nFYffGc8XMvL2x5NT8SQ+wRXLUuh1lqfYLtoZ
OB2rjTu77GRJic1VIpitpdrS6JZKWMpNped61Eb2bj3c9OhC9KVy2QVVa6aHj2Oi/WDn/I6td43d
TfOfWlZUcdutY5+g0Wi/DqN9pugHI/mDmg8GogcN1cuSLgmcNFW0SYmyQ5eqtxmN9oAQ0PgMJUKJ
Zr4wX7ND2KHRmZkh66deWKgHgyhKos6gF41JkCg6JYcuQR9vNPogU8yQcnSZ+gxjPhRLc3RVcCG9
UJovX6RbD9eK66Vrddfq1xu3wFZxi7RVt1W/xfgevCe+Jb2le0//lvFj+Fg8Jh3Tfaw/ZvwSvhRP
S1/Ip3Vf6k8bcwY0dF5t3X4tMZs0/FzmLRSYPvGIGFRWM2gEILJINDrQR71os7tKMKhZvJYk7X/J
IErKUGTBoEavQ3iJWiCAUUEpwYhnUdEoSHqDrNNqtLIsSaJIKdEY9Xod9pZrLsPs7XIlast1xAwK
Om01GLCoIBDzfoUkmH46TBKjh6PEhAVjie6xscSEMfellS0VHzagMnzpxJaQtZQrhP9s/Ak2rmU9
z3YBYAlyv0E1laCZX4RMJWjlFwdMJQbVyCinQkZGYQBroyEDq40OGEogtoID9SxUvMQbF8f+Ea8g
kPpwkNheeY5YBl4n8eG94b8/t1/0j82nQ6x8/T7dO7YEt5ezO7AM64dBh84tY3uwrkZHe3VB3Yju
qO5TneTRNeo26fqRIAkaGY/qggWICkdhFCUbcFvWSBpZ1FPZT8TxnVlM0H5jZ8bTccPaUkGysmgf
36fjWEBH92o8GiaIB4gYPvP1xaL/6/cxevNw37Zirs6mL6kjGpvGp81w2Vy+HfYdjgcz7s/WyY4q
B7UfNA2bX/F+4PvCdDpNk2VaYmox3W940P5U2rBRLvepUyr8V6U1+7fYtzhuTbtpiq7YX6mpMlxs
Wmip8s5Nk9OmZPiLjUXeorQiX9EUWaOXbDqv25RhTEtL88lT0tSpXcZrHRvi12X1ZG+Nvzn74fj7
s/en7feZesldrtvdD2U/nR2cqnF5narXV+hUkz2FHif5k5M4p2u9Nel3pdN01Z1SmJ44lfnGhf6t
mUryppLcqWRqqjfPSqzTiRdieZ1DZImecHQmPOEErh1ifjyDE43b+dqTseTBbhwsnwROQnShqEUa
QjTESfxpM7xV3lpS72omba7TRE9cVEz0ptHMOJORZiZeKRKxKtNQk0gSq+LksrEG/MfWzXhpWJs0
DGmR1wczswu9Q1GYhiE3mDqF1UcHPVOi9YREXleTELnGRGakVaXtMN2X9tO036ZpvGlGkygmMjue
xdMPTGfnoEFXThmJHRR4PS29kEE1BXdOICyx1xCxkfSSUwRXthVrjUTknHFO5CREXQAiuVI8JVJm
glPFrp3TXSr261KxU5daVFzoUgPT8JGehQ/s1+LyuK50tbtE15JEFdO1JZHUJEYSacz4tYHPGqLL
6FiAVT8LxPZGdnZhzoitMR6usBY/DQ38+DMl8pqqM9jLLJn4QD98gkvW6DCWMBTXKnro4/FFSlAe
D9Zx6ewYU4xn5gx/BgZdUSHfO6XosSYeD9Qie5+pwfN1Hkm0r1mxujjdEX9R+JnLN77/wfu/zQx/
bruyrj1PSfaTF+vrPvv0vTGSG1i0JDM5V4l32KrnLH2o79Cd2/LnzPU4fanxySsvrr71nt8EcZ1v
C68SH+Q3x2R4WJ02M25+HLUXCiWmkrjCpArhItNFcRVJXybp2I2j3h69c5yWv0zS4tKefLtwGgxW
i3n8dmHLMpstfquV8Fvjv94vFpwsxWOF9dg3bhh8X8MbhondMNrs0TuGht0x4qJ3RYhdMfBaP+lu
tY1opv/46mFCw2eG6+5aiLnCeefK5ZtvXXHVVtH/aE1z+I/hsfDp8HtVS8ZOCMODe78/+NSunZhB
lmAGKUPbE+D/qJfVWert9c5WS5u9zXmDe0PCg/RB48+tP3e/Y33bfUJzQnsi7kT8F5q4mXEz4y+2
X+ysctcb24zyLHuxs9gtrJfWW7ZIt1puS9htf8o5bD/g5PvjoDupkMFn7Y5C83QToySkFnJosRWa
niciXlq6VbvNACqygop8MH07IeR5QkDEJsUlE0bFNJBrYogpesBPkr2Oc66n7EAf+OxkAMrGPms4
FsB4/YzFaSD6sgFvbjyUMJKY24rZETqNORODTMwP/9W8YmHbDZuuqVkZTxyBz944Ef4rcZ586QP6
ScHi2rv3HH708vbcn7xEMIcTmaQ/xc4Od6DvFuPZwQmPqq7v2K6yPSAJOk2CppSW2qppte04lfk5
ySYanKCPdzj0Ok2cwx8fDywkzE5+XHKSCObCbzsu6Q1+nXbiuKQlp7RE++3HpWhQQfS4VMqv6Xhd
9RYxS/3+ItxGHPymMIOhwqWzDrdds+cSkuBZVDa/M5sk7Fyy/Lt7HqD9Yfdoy+yFPcfICG4yaOfd
7IyIMeKEnapbjnPFLdO2asUhkeBdwFqhrbCcsEoafiC0yXgYMRoMBOeU+J3ALcTzKXbybyw0mtnp
3WQyThhqJKeMxHiuoRMvWM45Gk62dC17oTLpIMiP4Hg8FOvDx6dcVnJRd4C9Xdn2ZsPDCz009ZmW
mTU3h8IeXB7757Xe/D1mqSfyEb1b+j6uhjfULAUU4tNnWWaZLzbXW+SEeHALznhw2eMcxGWnDuIW
dLJeNrpZ4rWAq98VdAmNCEZcgmuIiCEMJHY9hXj2Fq9bNRsNulx9LkAuuZKd0ImoZroFv8u+JL7M
sdOxzyE0Onod2x1HHaccEjisDsWR5xAxxK/tH7+UVAeLF1cHZ1+2DBOsIzIys750AXvT91lDqfWz
BPbS6SR/+4esx/BEZZtuwQ9LKSTeF536YhcPBUyuNl/R9KJ0G71uxJCRnHGxe/n1l1xXYtDdeCNJ
FP2j4drNgeSk97OnX1aZfz85MvrmD8O3Yf6qxYhvir2P2a7m2Os19RMZcYf8kO4Lna4jtTeVzhIK
jbPiCxMuFiqMF8dXJDyk0zl4ojQkck8YZDOekUDvyjKb/DxBWiyQeBd7J+PFa3pd6aRXTtE3MdET
0smJmWYZsk3TNjlDeqOBjkvaPr3AxdLjpFcwYlP46/KBZc+Fvw6/FNpMEsbsuRXXNW29+armLY9e
Xk8y8C5sJgn3UeuZjj2XrHnih889vhPtvRoj/1bpNUgCD9ykZmus5rhCyWq1F85yz0pQpSXxKxP3
yhqdMw7UBE+hBbkoLEudmYzL/t6Q9WEjMzYtjiTrk4kHiB/AqvNanYqTOhO9Fi/uDdYE5Yl50dkd
z2D2ktyT7EwMZZi/jlnHPmwI4JmYmY07pY/tijOKY0bJ6TOmTC8QcU+UNRoBI55+GiGLTrvTb2q/
ZntSOGwgSR/+naS2PVMfGCMJ5Lpi4/X9r3ryZy/que4GZfCrsd0NT9518bKwnZ0tcTp2AEg+nF0d
+ZVq1gkabYLg0op2LRXwSA2DdkMZu2AMXt4QvWhkL64tFApkrUOWtYKWUlnQ4R1BhxVRRR5RxXax
QHNEItIQ3aYmqIYaQ6NB6DD0Gmi/YcRAFUOegRq0ulinDKrmxYsLdQX8XfIIHp/Z22R9fs/E22R+
IW/AlXA6VuNxwa8PgGXLNHae2HLDT6NnvmEQ8PylM2cUahV8MK2fw0OjVmUnx9ixZR7n6j1gKNL2
Goq4YRckTivULsaHJDiFAkEVxCrhFu12bb82pD0maH4qHNG+rxUUIVdbKMzWLtTeI+zU9gv7tEHh
Ba1B5kfT6UWFVMWHzA6AptyCQqqwh+woQsqDeAWYVkhr8cG5q1IVrOFDS2XZTQWXPJVmyLPpdPlS
qspX0KWyzkGT5AW0Un5Y3iu/Tt+jH9Hj8pfUkEEz5Yvla+Wt8jNUg5elzvHXFgG8NsUOanhymI6L
geVDYttBFFpH4sLvjA1Iz5/JEd78qko4dKYC+M+dJMf3Ej988p0rLaX/1CZo+U/wd/2ldOI3syJn
wqs0O3A1sFszGf8VBwB5TvhSmHf2lx7+5ZcAnBokSUvhfiEFtoh/gUVYttASuFfsgnI5BTYiDmJX
5AzS79GUgC7Wlof1bQiXILwDy910D3gQ1mK5WnqFRSvMgMfwGLyVamipMFdMxm+JOCy9onHLB7Ul
2nd01boRfY3+VUOZcU5MMycEcI2yD8XzXi4sQf1L6Usgcepi4WNgP31hn6v5U+Byel4TuJQWumO4
AHVwfQxnvyf22xgugRs+iuEacJPxfmRYTtwxXAt55LoYroM+sieGm+geWjjhwyLxjzEcXSjFxXAK
ouSO4QJMlZJjOJ6kpPkxXAKjtCiGaxD/bgyXIV+6OoZrwS09EsN1UCkNxnATWSJ9gT0TUcCxzPKC
GC5Conw5x5m39HJPDBfBKW/iuAbpGvn+GC6CXX6E4zLzm/yjGI6+kp/luBbpRvm1GC6CW36L4zrm
f/lkDEf/a78Tw7EfbVMMR/9r22I49ql9MYaj/7Xj/aD/teP9oP91UgxH/+uuiuHof92DMRz9r/dy
XM9sN74ew9F243scNyDdbvxHDBch1RTt08h0M/liOOpjCnDczCLNVBbDRUg2LeQ4e4FtN10Tw1k/
N3A8jvnQ9EgMRx+aHue4g+ljGozhqI8pam880h2m38VwERTTpxx3Mn7cZqM48ptTOJ7A+M3FMRz5
zdUcT2Jzar4mhuOcmqPzm8L0MW+L4aiP+W6Oezj/D2I444/O7xQ2p+aXYzjOqfkIx7OZf8zHYzj6
xxzVM4f1YxFiuAhgMTFcy/0/gaP+liSOc7ssRTGc0ecx3Bjlb4jhjM5tMfJ5sdwSw3Fcyx3wNChQ
gFtMPn4VqIVWaEG4ANphDZZu2AAdnDIPa52Is2cT0ts4xzRsKYdV+FVgEdKuQvlu6OK1FoQtyL0O
n8389yg7kaMJeeei7Cqk/esosybxKBNcs2Ap76crNqYCRdhbHsxELBP7aIMV2NqO7e2wEvvKOm8v
39bHWd6cSXrVntNHG7eoCUs3t74Z+1qNsBOuQRob9X/iuf+uxDf5aiewCs65HjnX4BwosBB1Wsk9
w1pz+Hy0w3LersClvKWVW9uEtk1FWg0fqZO3tHFbF+OzB/mbY55TMEJK0GMFUI+SPVhnPtiAsIfP
tMJ/4y7qq5Vc125Oa8dnM6d38PE2cF+yfhWkdHKdGOeKmExLrN7Ee+rgo69Grm7exqSW8z66Y/5b
FbNzzYQWUYlxPTon8XbwSGlGjVfwMaL+WM/1Zh45vw3ROuNdgaP1cI8089j/V08wiVUcy0T+LIQs
UpbH9D5/32v+F7af7b15Yu47+cobn8vx6DmfBeOjf1Ov2ZPmiFkStaWbjzcel6z/qK3NSFnPLW/n
q+PfRULTObPewmenPfaMWhXFe7DWwZ8K13bdRDRH+2Gcq5Dj38XQtKeVgrz8fKW2tUVZ0L6mvXtD
R4syr72zo72zqbutfc00pXzVKmVR21Wt3V3Kopauls51Lc3TyjvbmlbNbV/VPC4yi1MURpq1tKWz
CyWVoml5M5XMBW0rOtu72ld2Z51lmczBqTm8r9ooR1uX0qR0dzY1t6xu6rxGaV/57cp9W8MErZY9
Kjqb1retuUpZuHJl24oWJUdZ1L68bY1yaduK1vZVTV1TlZqm7s62FW1NyuKmnjXNqJySXzKzoL69
R1ndtEHp6WpRultRq5Xta7qV7nalua2rYxU2NK1pVjo625C4AltaEDZ1KR0tnavburtbmpXlG1Cs
RVmFY65hXWAD66OTUzs625t7VnQrqMf6VlRk0ggI29asWNXTjI5WxpVoX7Nqg5LZlqW0rF6OfU/i
XvNvR+fszcz6zpYuZiVzz9kBmPhEX7O5RZltOEp3y2rmy842HLW5ff2aVe1Nzec6oSlqekungha1
41D47Onu6OlWmlvWMTcjT2vLqo5zPTQNE2sLLkG2ALsx0CdvIee2dEMPMWGInjiH5yx1JV+ek9ui
lCou331OS4wmbBUOCz8VXsDnwOT2c+j/2ez/s9n/Z7P/z2b//+RmP5Fj2741+0ZbLkHYinAdyjNK
zzm832y9kHug6xyucVoVZutVmBlOI/8JpJ2bmc9tG5fpimXx9vP2eLZ1Kccm80Qp83ltHd8Tzm0/
t6UG+2BW9/BcwHy14Rzu87VP9lT7t/qwXfSIc8TZ4jxxhjhTVMULxGqxZDL3edtrz7vrnaVWfcOe
KKWa1Ug+8kxuO0ut5qugAz3d/i8cE3Rigz8LPoznSe0TtEt4lmDU/2oE/Re99F/u799FWOwdHEQy
4B04z2egtrfcJDwD+7BQsOJTwdKPRQBVeGZQNhWoQwjtDg5DzkDBcGQEkVnTOT3nvoLeQ8JeuBKm
I3lvaAkj7x1UKwo4nD47CnPzOQxpo82yo8BTnohiuVgoWGLYQix3YdmJ5QUsGlRoL/wJSwSLIOwW
doWqPNjDE9iRpdwhPAEEtXwCjmCJYBFQ+yfQlifg0xhFRK1+MKgzsuF/wKWShB+glAWfViy9WPZh
OYJFgnZ87sQSEdjrmJ3CLmzbBVTYJTwesnqs5XrhMdiEhQoPg4WwH3ONCDsGrdw3Dw1a4grUcqtw
P9RgoRAUFsAIFord3o1idwNF9upQTj53YfWg3lxgRf5tqPQ2VIS9GerHJ+F1FQvj3zYY52Td3xSy
2Ljc90J5hVFk0OouqEEvXAtEaBHWgA88wkaEqQhXIExBuFxoBhPXUx20WAt6cbwyZC8T4jFNe4Ry
wYmbtEeoEBLZz2aQrSdkjo7TE8rMLkCL5wluzmIRTFCIUCvIoQKPclBQufO3DuoMTL+tIWt8wWHh
FkEGB3L1IpfLYzks6HFm9dyS2kGdqWB7uVGoRTNr0S0e1JGgl9fwjtaEsKNym1ApJIMT264RUiAe
YZWQyuFTwuO4oj3C9wf9yZ6Rg8K9XOoe1ikOPycaWnMGTeaCkXKdMAdbg8KdOAF38sG3D/pnFkC5
X8iEPCwUfbwJsU086PsQ68NZ68OZ6sOZ6kOl+jD6QLgNW9jP63KF66BDWA/bsexEnIVVfAgdOsyR
KZkFw0KC4EbHWA+iKwlSEwd1ZqaZO2SP42zuQaO5oOyw0IVx3oV9qkL3oMtd0H5QyOamTB10JzGB
jhCG62HBFZ0aFHSyKTksJKMjmGNShNRQvCdY7sE6C2QPEPoLepQ5ib5J32LTzf6SlsPXY/CNGPxV
FEZG6NHooqC/YXC0PJl+gJ1dSf8AOxGj9CB9Gc+8Hvo+HWJa0PfoMJQhfBfrzQiHEU5H+HzI+6pn
iA4NIkDdHwmZnMxY+nIokBtDPOkxxJUUQ+zOgvJ0+hJ9EZKxi3cQTkH4Ih2BNIQvIHQjHKHd8CrC
Z2kRHjI8dH8M/pQeYiFOn6MH8IjpoYMhM1MhGJIZ2BfSMPDjEERrNbmeQ/THdC8kIuuPQv5EpO4e
9E/xWA5if4Q+QbtDKR57uZ4+TurIZ8jUD+8yCHa6K1TMOtkeOqR4hul2ul11F6vpao76pJCXnpeT
96SgpOOduVh5Uim30jsxgeykuH7pNnwWg0IxerCoWLbT20JicbB8DG1idlHoxWc/xxrx2cExwKd1
ovUUx8roLbAQC8U+NmLZhKUXy40g4vM6LN/Dcj2WGzilG0sPlvWYTTpQogMlOlCig0t0oEQHSnSg
RAeX6OCj92BhEo0o0YgSjSjRyCUaUaIRJRpRopFLMH0bUaKRS9SgRA1K1KBEDZeoQYkalKhBiRou
UYMSNShRwyVUlFBRQkUJlUuoKKGihIoSKpdQUUJFCZVL5KFEHkrkoUQel8hDiTyUyEOJPC6RhxJ5
KJHHJRSUUFBCQQmFSygooaCEghIKl1BQQkEJhUtYUcKKElaUsHIJK0pYUcKKElYuYeXz04OFSYyi
xChKjKLEKJcYRYlRlBhFiVEuMYoSoygxStcPCEfLf4YiR1HkKIoc5SJHUeQoihxFkaNc5CiKHEWR
ozHTu7kzKIbNRiybsPRiYbIjKDuCsiMoO8JlR3h49WBhskGUCKJEECWCXCKIEkGUCKJEkEsEUSKI
EkEu0Y8S/SjRjxL9XKIfJfpRoh8l+rlEPw/cHixM4r8flP/tqaE3kjot7rW0l2RxuAk+4XAjvMvh
DTDA4fXwJIffg80cXgfFHK4HP4fYH4fd4NGSkKfYUu7EFLAQy5VY2rHsxLIPywtYZI4dwfInLBFa
pKaJFnmhvFPeJ78gS/vkUZlaNAs1OzX7NC9opH2aUQ1VypOoiedRTC1wF39uwuenWHATwWcZx8po
IY5biHm2CL+FtFC1nVQ+zSZHsskL2WRfNrkrm5Tr6IVE5JlOgWKKipM61eif43kXS7E/Yw5mpjsP
fOLyhPwzPEPkUBRkqQGEn2AZwPIkls1YirEUYMnBko7Fw2nZyF+npsW6PIQlA4sXi8KGAKcTD4h2
m1Ydpiby5ODPTKBj42RkotzBUEYegqFQxkIEz4UylnvKdeQAZLBTEXkWZ24vwn0hzzFs/lEUPBPy
HESwO+QpRNAQypiG4PJQxhuechNZAh6RidbG4GK0m8FFIc9SZLss5MlCEAhl+Bl3Ng6Ujq1ZpA6O
IUyPSU2JjuQLeWYjSAt5Shi3FjLYxBMN5HD1JCwMCoOo0KfDpE4kqsFz0nOv5xMU/ys6FsPjPWVI
RHAkfYgsVfWeQzmPIXO5J1SuZ/y4PwzEYJDBZz1Ppt/meQT7IukHPA95pnnuzBnSIvkO1Ps2PkTI
s1kZonvVOE+vJ8/TnXPM0+W52NPkWeRpSEd6yHOF5xBTE+pJHd17wFODHV6EVqSHPBemD3EVqzwb
PKonw1OiHGL+hZnRfotzDjEPQEF09Kno3+z0IRbjS4qHiE3Nlk/J2+XL5bnybNknp8mpcors0Nq1
Vq1Za9TqtVqtRitqqRa0DvZrFgH2U3KHxsqARmRPkeNWyp40+gsAlGgpXAzBOKGaVi+eS6qDIyug
erkSPL3YN0T0ly0LSr65JGivhuraucGZgeohObIoWByoDso1l9cNEHJnPVKDdOsQgdq6IRJhpFuS
2N93DxC45Y6kYSAk4ZY76uvB7VxX5i6zz7GVVFWc59EYewbOftyT0ZTgA9WL64J7UuqDBQyJpNRX
B29kf/09TC3UVFkxTM0M1NcNix3UUrmI0cWOinpkO8bZMJrNyAYZDCCbdi4ojA3zyVzGhnMU5fOj
OPJ5GUA+vQn8nM+vN3E+kTC+gXeVyooBReE86QDvcp5302ESD0YMylYM+P2cy6eQOsZF6nwKVyyL
d+TxIEuOh7PgNdjDO/IQPlgw9yxLeoylaIKliI8lkLM8niiPI3Ocx5GJPIH/5adlboAM5vdsfJn9
QX2jr7IFS2Nw27pWd7B3uaIMbOyJ/aW9v3H5ilYGm1qCPb6WiuBGX4UykP/yeZpfZs35vooBeLmy
tm7gZbWlIpSv5lf6mirqB8tK68rPGeu2ibHqSs/TWSnrrI6NVVZ+nuZy1lzGxipnY5WzscrUMj5W
ZRuL+5q6AS3MrZ93RRQOUoMeY7gxyVs/12ntmMMCeni2170x6XkRyG4wBOqDRt/coAkLa8opzyln
TbjOWJOZ/a8JsSb3xtnepOfJ7liTFck239yJP8cAxsT+DLY66F28rI6FSlBtOv+cdbEPb3ZDZVsF
/sN6Ny/4ncwJXef9dJ/v09PT08UePYEugOpg9uLq4Az2R7myjEM1VtQjbdo4TRA4bUCnqxyKjGBj
AJUg3Ww4hgUI+2M/VY+3Lpn2a/plyq4K3YOJKQXth3EH34QF73F0fSiXX5/p+sG0dHZ/6R7MLYpC
vK4yGEr0FrBfhCtGUQbTo1C15SCyPX17zvbi/vT+nP5i9sc+B55EoudJtpWGcp8UoDvQNe4IRLvr
Ifo3iDje46HkFD5wP0MCgfpAF+H++qazybjTJxzbFeu1i3ffPT4hUXpXrBOciejoPeNiPTEh3tjD
haKdRGsTj7MfrAH8XwDLeUoKZW5kc3RyZWFtCmVuZG9iagoKNTMgMCBvYmoKMTE5NTQKZW5kb2Jq
Cgo1NCAwIG9iago8PC9UeXBlL0ZvbnREZXNjcmlwdG9yL0ZvbnROYW1lL0RBQUFBQStBcmlhbC1C
b2xkTVQKL0ZsYWdzIDQKL0ZvbnRCQm94Wy02MjcgLTM3NiAyMDAwIDEwMThdL0l0YWxpY0FuZ2xl
IDAKL0FzY2VudCA5MDUKL0Rlc2NlbnQgLTIxMQovQ2FwSGVpZ2h0IDEwMTcKL1N0ZW1WIDgwCi9G
b250RmlsZTIgNTIgMCBSCj4+CmVuZG9iagoKNTUgMCBvYmoKPDwvTGVuZ3RoIDMxNy9GaWx0ZXIv
RmxhdGVEZWNvZGU+PgpzdHJlYW0KeJxdkstugzAQRfd8hZfpIsImbwkhpSRILPpQaT8A7CFFKsYy
ZMHf1zNDW6kL0JmnL9fEeXkpbTfFr37QFUyi7azxMA53r0E0cOtspBJhOj0tEb11X7soDrPVPE7Q
l7Yd0jSK30JtnPwsVmczNPAQxS/egO/sTaw+8irE1d25L+jBTkJGWSYMtGHPU+2e6x5imlqXJpS7
aV6Hkb+G99mBSChWLEUPBkZXa/C1vUGUSpmJtCiyCKz5V0uWkabVn7UPrSq0SrmTWeCE+JAgb4j3
BfKWmfI75hx5z7xDPjBfkI/ECe08BU6k2iCfueeI/MhnHZBzzp+QL5yn/isz7Sm4B/NKch7PVax/
f0Ve9G+RF/3ErH+D36JY//ZK5iwuoE14jz/2C333PlhPl02eo9udhd//wQ0Op+j5BqhJnF4KZW5k
c3RyZWFtCmVuZG9iagoKNTYgMCBvYmoKPDwvVHlwZS9Gb250L1N1YnR5cGUvVHJ1ZVR5cGUvQmFz
ZUZvbnQvREFBQUFBK0FyaWFsLUJvbGRNVAovRmlyc3RDaGFyIDAKL0xhc3RDaGFyIDIxCi9XaWR0
aHNbNzUwIDY2NiAzODkgNjEwIDYxMCAyNzcgNTU2IDg4OSAyNzcgNTU2IDYxMCA3NzcgMjc3IDU1
NiA2MTAgNTU2CjYxMCA2MTAgMzMzIDYxMCA2MTAgNzIyIF0KL0ZvbnREZXNjcmlwdG9yIDU0IDAg
UgovVG9Vbmljb2RlIDU1IDAgUgo+PgplbmRvYmoKCjU3IDAgb2JqCjw8L0xlbmd0aCA1OCAwIFIv
RmlsdGVyL0ZsYXRlRGVjb2RlL0xlbmd0aDEgMzk2Njg+PgpzdHJlYW0KeJzcvXlgVNX5P3zOuft+
7+xbkplMZrJMMEASIBjlyqoi+yJBRoIIsiphUxQVqiwiKtqKS23BpYpVS4AAAbWmltq6UGi1WmkV
alHRb6N8LaUqZOZ3zrlzQ7Dt++v7/vnOZM597n7uOc/yeZ7znJuli5fNAipYBRhgz1w4YxH70duv
AgDeAgB6Zi5fGlc/Kj6GafzjJ85edN1C9ZqbxgMg1uH1669bsGL2svEvvwuA/hQA1zfPmTXj2hN3
NegA3Mria/Sbgzfck/uegNcb8XrZnIVLb/pjdObneL0Zr3+94IaZMwbO//wWAG6bgtdvWzjjpkWV
ahM+97Y/4vX49TMWzir+/fvfw+tfA2BGF92wZOlmUJUH4D4f2b9o8axFN0/9cCRex/VRfo63Qfwl
HxWTPFlHDMvxgijJiqrphml5vD5/IBgKR6KxouKSeKI0WZZKl1dUVmWqe11Q07tP39q6+n79BzQM
vLDxIvD/gw+3H4TxL8I9A8JsGoQAyH+KfyfIMjc3f4LsJ0uEewW0F34AbAMvwLngBfAKeBWexGdt
B/tAG/gNCIKh4DGwEvwArAM8mIq33AXG4y+Ht/8AhvNtoAY8jnnpcXAQH3sluA3sBwEYyn8Gbgdr
mLfxWWuABkrBJWAsuAHcA6/ILwPTwFH2DtAfXAGuB4vgqvyU/L35B/JPgZ+Afcxv8l1AAREwE38P
5r/g/pj/M+iFz3gQPAKOwgek3cDGd1mFj/wRWAweZbIszF+X/xbXIAFuxHVgwShwEHagDL76LPAp
DMGVzBB8lSfzrfkD+KgYyII54FGwH9bDESjBTcuPyh8EAXyPm/BVHwE7wR78bQcvgyNQ5U7mn8qf
BGFQDS7Dz9MGfgs7mFzX6twg0tC4lSpBA95zA/g5+DU4DJPwF+gGTuX6cjZ3c/4d4AN9wCRc22fw
mZ/Af6Lb8Pd25jV2eH4w0HG73E9aG/wK/AVGYA0cAyejSnQD+jGzGIj4jn3w91owF7f3w/jqH8IM
3INUdIh5kn2OPcMX5Y7lddwjafBD8CPwC6jhJ43DJfB78F34VzQETUc/RB8xP2CfZX8vzMBPfTVY
CO4Bz4F/Qg8cAMfBq+AcuBKug/fDR+BBeBieQJegiWg++pKZw7QwL7OD8XcCu4S9g1vL3c2fyE3J
Hcj9LvfPfN/8WjAO88NqXPsHwY/xk+0Dh8D7+HsUfAQ5qEAdf+MwASfBW/D3NngPfAJug8/CNnyX
w/Aj+Bn8Cv4DnkEAf3kURQlUir9JtBjdiH6AHkOH8Pcw+hv6hgkypUyGqWcamSbmBlyrdcwm/N3N
/IWNsIfYPG7nvtxmbgu3jXuOe5U7yavC90QgvnX2ya6qrg9zILc+tzm3M9eW/wvw4z6M4FYoAY24
9jPwdx7u782Y47aDt6GK2y4Cq+DF8ArcMtPhPNgCb8IteSd8FP6E1v1n8CXcSu/BL3GdNRSjdb4A
1aPBaAz+Xo1moRa0CT2A2tC76FtGYBTGYPxMFTOCyTKzmKXMCmYz08q8xXzAfMScZs7ib56V2RK2
lE2zGXYEO51dxv6Y/ZT9lJvGvcl9zMv8Qn4t387/r9BPuFgYK4wTssJ9wh7hHbEZc+cvwW6wt6fM
w2PMamYYsxvci2rZMPot+i3m5+ngWmYUwpyKtsH16FbYhsq4m/gL0YVwNDjJpnFbv4a2oNPoQmYU
HAkngHmoj3M13sf+FC8a2V+CTvYl/Gy/xVe+iVfhbehLXgU7IUAN+J6/YnqzGeZNcIQ5CgX2cfAn
VoZB2ImeYcZiLniZvZibAhLMY+BnTAu8FexGwwCQz4gbMR+Phj/FemEi7Au/ZvKAQaMxF/Vn/gru
APPRH0EnluP14CF4LXsduBfUwpXgU/A0lopK7nq+ivfD19FcdgPywjaA2Gfx0zXAMshwPnAnzDKP
8l+i98EycIiVwYfM87j2h9DPmFHsSW48nIMl4FawFrTkV4MV3BT29/A6wMDJIMUew9ptJdOXTeDl
7VirTMM6bQ+W7v1YD1zCjMJbQphzrsB8MQlriEfx92GsJ1jMQXOxjF+JtdhvQRs/EbWD6zgdYq0D
APtmbjyYmn8aPJK/DlyffwD0wvpgXX4lvuI28DG4D2yDa3K3gEWgGEvOh/AKbjg6xA3P90Ib0Pto
Atp8fv/i1k7BEPgcf3+GVy7mXgQb2PfABDAovzH/B8zdFVjDPgKuAZeD4/gpv8B3uJTpALW50WhH
fjizCD/vUTAu/0y+BMpgTn4BGANeAj8RODBDyOA+boW/x897C5iFxueXMrNyc3E73IdbwcattQzr
n7vsIZMmXmIPuviixgsHNgzoX19X27dP75oLelVnqiorytOpsmRpIl5SXBSLRsKhYMDv83os09A1
VZElUeA5lkEQVA9LDm+Ot6abW9l08tJLe5H15Ay8YUaPDc2tcbxp+PnHtMab6WHx84+08ZGzv3Ok
7Rxpdx8JzXgjaOxVHR+WjLceHJqMt8Op46Zg+p6hyaZ4ayelR1F6E6U1TCcS+IT4sNCcofFW2Bwf
1jp8+ZwNw5qH4svtUOQhySGz5F7VYIesYFLBVGswuWgHDF4MKYGCwwbuQEDUcKVaI8mhw1rDyaGk
Bq1MatiMa1vHjpsybGg0kWjqVd0Kh8xMXtMKkoNbjQw9BAyht2nlh7QK9DbxueRpwN3xHdUdGza2
m+Ca5ox6bfLaGdOmtDIzmsg9rAy+79DW4M3HQ+dW8cU9Q6as67k3ymwYFpobJ6sbNqyLt24dN6Xn
3gQpm5rwNfC5KDW8ecNwfOuNuBFHTojju6E1TVNa4Rp8yzh5EvJUzvPNSg4jW5rnxVul5ODknA3z
mnHXRDa0gvErEjsjEXtf/hiIDItvmDglmWgdFE02zRga2+EDG8av2BW24+Hz9/Sq3mFaTsPu0I0C
oWo9iVnd+yhFDyfUyPHdLQtJjZKXYYZojc+M45pMSeJnGkCKWQPAhpkD8GH40wTxWa3X4h6Z2yoN
ad5gDiTbyfmtXMpMxjf8A2AOSHb+7fwtMwpb+JT5D0BIwifdrIb3u3RrJtNaVUVYRBiC+xTX8WK6
Xt+renk7SiYXmXG8wM0HxuK2ndE0sAY3fyJBOvjudhtcg1daV42b4qzHwTXRncCuyTS1omayp8Pd
459E9qxy93Sf3pzEnNxGIbK/VUx3/xlmwDtszsBWGPh/2D3L2T9yQnLkuKlT4sM2NBfaduTE89ac
/QO69xWoVu+QKUwUFSgUZehezJTTug8mK1PUVjaF/3jK1Ne2CyLmSroFxoe3ms2XOmWTnEj8lye1
50+Ss+ji3GmFarYOzJy/fuF56+dVT93A4ApjUzly4tQNG+Tz9mFWc254WWGBOR5MnJKID2kFk7Bk
pvBfe75jAPk1RVtt3GRDyAGY/5xNhdXzDowW6Cb8IdzZq3o4VnQbNgxPxodvaN4woz2/6ppk3Exu
2IdeRa9uWDSs2WWc9vz+u6Otwzc24baaAwdioUBg8I4kXD9uhw3XT5g6ZZ+J/af1E6fsRBANaR7c
tKMM75uyLw6ATbcispVsJCtxsgJGQvyQO5FIj4/uswFYRfeydANdn9kOAd0mutsgmNmOnG2muw3h
bayzzabbyIfomCETp/TkHiqSTb0wNyJIATYHMGLH3mTCSlgpXEBsdM/GmY6zNgfOgDjbQfy/J7C1
JV6NAtpsP88Vi6IgAIYtxg8qS8UKEAXcpHaN6akTJjKXx+W4huSIxkpIVQdPknRFwaWsariMwzi+
Xtw00STQnj/dZhgFQtMo8W2bqhYISerewhPipC1rGqay6oVXhTKjzVMZ55NtHNWFF42jzdPZUaeO
Z8Cgxq5G8vM01DSaXY19etdaCX+i8HuCLTv7YyZz9g/Mndz+F3KDns9pL+AarcPN8Al7Mfardthe
juG9aJvZbv6V+dR7kjnt5Vly+1JFq1thwofNw6FjoXyIjYs+3RfwxDgB8gFN1nRVb89/jZ9k8CRM
fNVGHhsTp+wS0gx6Wcgmjx2yFQVNUioIrfh0HZft+b/ZFmkAhSVPr5TSI8iZiqLw+CjT5Mn6N7ZC
WkCRDYOun7Y9pG0Uu7ZfXV6B+E8ZHSI9UV3Xr641dDKEFoW2hlpDHSE2xKBaf0AkdQvQ/giopFKB
FKStb1mFti50zLd2kNQM0PoAmdQHsKQudJ9F7g8Q7ReW9gm5qQfX4iRRdHFwGBzDbDQ6iHukJdP9
aaTddKrRxBvP24E/nWSX2Yj7btCgTqsBehr69B6ywg7wliSLsiAzvJm2eD0KDdkThSADM5mq1TDb
AjLZllqr1t+vtm8ggGGRlbTq0ulkKe+31j2x7IPmx8eaclvV/EuXPMOmH9o+bNGovrd2LUFrr194
yQNvdb1EeHts/gTTiXs+Av++DwRJN5OGkUXKurQ0aGnS0qLlDkTkyq7TbzegoUAbO96LsBixnpgi
hGIsdtD8gkgaUFBJtwoqaUbBJM0o1JDHPfjOa2BQ56BO80C2L/n16R21R0gqLIkN8Q4JTvBOCDZ7
m4M/RD9kHtWeMp+KqKIWluehucw8bpm6SFulPa3ulvbIu1U1oK5V/4oYvXS6cYNxu8EYsB391E73
BqRSzbham8BW3BsngQQMQwHn6hjDVccs1kafELOr7SFsYZTpIulRvTQKCGs4+zHxhb2a7AdlSqYE
QgAhtPXM4EnQJiwFbXIU7EeOgDbhE2gTnoWXEh6BEXJFeFnMT/nPTznPT7nQX3ZIgCXCIAEJOjlN
kMlpAmVr0naDadvhsk+07kAoY552JL6FsEthhawvLqi4fQAS1Y73Lj5FWGoxbWSsB6yGGjN7HP/1
6Q2yLZhvmqBzKgzyfLIUWHUewkFBweEdX6C2bz+mcUfRlz87kvvn4s/ueuHPJdvDt09d/9On7px3
L1wT3HsIFkH5eYhWb388On/BL99+99XvYR18ef4EG8O8VAH6o212taRJVWEtUlWpVVU1aP38/aMD
qy6rymrZqnna3Krm3hu0tZWPBn4YeVbzV7TnT7SRFijHhB0m1NPhn1bsCb9YcSB8qOL3/g8qxKEB
WEyUgkVax0PbiFNJWd+eP2aPIVRJsCSUqa6qa2Abqi9jL62eLDZlZotzM8vVderr6jfaNxmrf50O
WbOmrC7YN+ELTa+8oRJVxmr0Qfp9+hY9r3Nb9O36lzqjE0FXqApTiZLG659T7UA1WoJ0k65STuGJ
NtDTVO2FqKbTY0yQcKEWqiYXCD3oi8UE0F11MKxc7htjlMoZ5gyqfShjEdVZ4LWztk6uBnhqFFKJ
Mqwg6b0JQXQgpqhmwuvH24hUlRFOJY2GiT/bCqldGa0XXj9LDUhZO7rK1sttkDbT8XTv9PY014C1
VhuR0nR7/l2XOLWH3Drdh+y0teJkXe+Gjga0tQE2BMkDzCeXDlIlEEyFSmsoR9dQHq2hHF1T9gp/
iEcl/CAe8T6yhfeRY3h6Dq+TtuSpVuBD5BF4ldSflDzeSxqUN0l9+T4DzjG4y/KncEG1J9nS6RpA
R7FmPv6YcPvxzKDOrsxxCzN9j3Nb8Dr+a4CWJ9hAZIDyfgtegJYUkYB0fV2/fv3pt76unAiBUH4x
KihVLA/BZJrhBR05ooEPYhqv3Tdv+0sjllxaP//IdbB22PrbVxS1hq4/fNf6n441pWDpS7HgNQdu
mNZ34dw5T6SL7pg0/Lk1o1eP9ulapCwlX9/roqaWUMvdI+0Zl19w08kzay4aAD+oiJkVo2oubb5q
zEU3YnwC1uXmsgksTR5QDDfbS1Wzl3mROdJkB8Vb46gkXqkmi/r6+xYNLloU3xQXBwYHRi8PXh5t
Eq9SpwWnReeJ89W55sLg/GhH/G3fB6EPIm8XH/cdLz4Wz8cDSTZjZvz17EBzOHu5OdX8WPmfopyp
WDoTiMV4Ys9jugL0sGvGw64mxMTXdgnp0HDZYRmasi03y6tkNk6tetwmHSu35z+xFdLRcqiw7sAa
THxBuVQmlyPsKRNpryf9LS+F3lpU66EM5aGs5KFs5UkB0AHhJrgVtsKTkC2Bg+AYyEAiJkWEaaFJ
bgJNcgdIbQyk3ASJaFEtTA4NkNtBqi6gh+rjcMmI/iHYA0gRTlncOMok3HTqOF304D2ADTO1zR7K
QFiHLgYtXmJ6qe31+xBho3KLoRxSX0d4aN1TAx+Ys/7wvGVHb5l63wXW08tveu6ZpUt25OZyL28Y
N25j/uEnc2fuvmJg1xnmqYMH3vzDm2+8RyzyIGyRd+B+781gLBakTRGiZZiWFW5flLtE2iVSLlHm
EkmXKHWJhEvEiTzfTii21Fc6ULpcGlo2uXRW6UrpXunOsqe9z1W/ymhSMBIK9h5Z/W6Qi6JJCJl9
oRyaJk6TpsnTlGnqNG2eOE+aJ89T5qnztLZ0W7lRni4rL6vsVzZVblKuTV9bsTS5tGxV2fflx9QH
Kh6qfrD3U/Kz6pPlT1XsSv8qHaDPQnqj1CWSLlHmEoXn5d1H4N2H4t3H5CcVtec/tD3FDVPF8pQq
s5F42s8qFxRFiBYuDVcTpigJDwqPCU8Pbw8fCvNGuCR8Q/homC0J3xdG4ZexmvVjkfspsZ+2jxxu
QhsiEx6GCEATIsxDHbt8gTqytE3dqoPwgmlFC4pQUcwvsI72RZMw8QllOULYXsJybOwCpSQCI2Vh
2xuq60tOryeiEQ45JeHdcIDwbjhOzgzHyVlhqgPDAfL8ZC/u+/3oKiDkv9pDWEAoq8IX2h1rOFwF
q8g9yflVxISSi1KCnF9FbBa5RBXR6+QqVRFag0R5VV1z346+aFDfVX1RXxOjmTJAqwJMimfjTuMj
yiT0iSi3lJC6xSkXxssMKmsGrbsRJwcbxGamSRUMndzfoAbS4CnEKj0K4CAwBuu1cJ+6/tSBybaM
cmWPSBhWSZnOxaNdBZ/JtGRGdWbOSSfeiTU8Xg7qbKHqHYtgBsspXTgKvqDfMXK2y3sVJzlfddoy
PabXZPhSLR4FUoUQhVwvXBT78GpCT0ZBaVJTxUo5CivKJZnPsFFQYhYRjJ0xMSJ3CoqWqjKrV68G
PZQFzC5uyZ7bQA7y9g844l+eLr8AYaPS31EP3cgqiA1KsBjbEWp1Bu007rpl5U31qe+/9siYSwZU
3T/h1penWq3qkrkr5wUCNdE7X3lo8tzXbj30PrwoNn/xrKEXJUOpvpetHj1iRUVJ5tJbrguNnza+
fzJW5JXLai9ZOW3qliufJxrkDqxBjpGROXjHPhDBHS75g3Uo7g3UGcSRC3t8dRkvLBO9ARV6AwoP
ZAvjEVAbcP23gKv4A93+WyAVChJHK0K9uCD134IeooCD3agkSFFJsNtzC1LPLUhsBvXcgiphoCDx
3DTCIPkg7AjC4OgIYcpy4rRFTkbQosjWSGskH2EJ7MeVUSnDqdQaqCmJSiDxtSQIpLh0WDomsRKp
OKkRIWyL1EqidZFkUg+J3JFaAIl6bRIitZFGh0eMDZ3D0ZjvKK7+F/eM4ovjBF0MaqQYwmGxCGvq
mqEhXhB5kROxi8aqUaCJVhQQB62qajU2E/jMRD3p6nR5ut6qtTADEAbpR2hm0Mo/XP3kGFNpU6zr
x42798K2x9ouXTimfgl6oGvXPX1GjJtw33rUcOYI6VHcrf25/YCBo2wNyaRBGFoS4+YCyLO2RSik
kJZiaIl3d7mwsovAT7ybJY3K0JKeTbEmOVshFNePiDVH9F3/AXV0WVfvLHv3cZalKbq0U5irDK6E
28Id5dgxuDjJMSXcIm4Vl+dY7AjLiKH+Nb0S9ZH9tfV1WwDswP4YOucou51Hneuif3G8fdTxFgkr
4SNybQWPO+8GRs7aMqVGs+d1p6MfcOdhr3pQn96Qrn33g31n6442bv+3w4nclOW/QlXcIyAIS/YB
Fd+KtJfSXiBElxBcgncJmTxkMl1HmXMCJlaFsY+oajJkQMCUMoaMERWjGGYpKIXaeSBHdkCOCvOC
OEwa1iwsElYJmwQWCHFhq9AqdAiHBV4gyIk0keAgJ0p8RTG74MhsgaCOthPI4AlxkgAxTPHUoySG
gbSesB/Nw8qh347Z32kvDHs6nTCFefxUI+F43HwE8li1tebrpBELh6aClKfrrWR9rdUfo6Ck5SOM
jczIFY3XLKi+885du3d7MxXFj28xL571BJq5EQoLcvds7Pr+qOoI7vuR2FMsxhjHD4rgj+1gCYj5
0SQmy2WlScosZj53gzRLEf3EvSH1tTBhjydUUYyU5Z73uW99pyNsH8/AcJ/YJZ5RkUti4zzTwuNj
MzwLIzNiN/E3+U+j0yETBKChBYNjA82BRQEMbo1N5lYTmSYbjckC2O9YfNqy1LLrpNmIOXzQG2MV
rKhO0u4NuuqQqDLqIAVtDXtatN010jekVhoxt6SdNXIpCdvYVg1qkRLCG6l0HVnuJQ5VCSwJEK6d
RjVtrRNYMSk3mJQzzDLBLquqI3GBMQJTiAA40YA4jaFQz0mI0V534gYx2r8ULwjh4oJ97e7XDI0Q
HsfbsFo7TVXbKAfTdnbhHj1OYwTZxq6WRqLcKMKFWeokwZbFbojABLV9geUTElSBwUSauknM1fur
v9j3We5L6PvzH6AOz56Qd66ZubHrCBqnDph818pn4eTgk22wBCN2FVbkPsx9Y8a3758DH1w7ZM7T
xMsZjm3VUazZLMwJr9grZayeUlqdNlTj6n31sSvRRHm8b0LsOnQtN0ua6WuOdZS8w/3B+0H4Y+/H
vi+D/xP+uOhYSb4kUFKSiTQGGiMjI4tKNpUIF6Ay7YLAQFSvjUTDtOG+y2JXypO167SP+U8D38JT
ugn9jK6YBojGFMECsh9LZ8i1foTYSxo9VEvU11d7qX5NWYZ7wPmBo3IaOEqZ5mELmpZtNVurLLaE
OkQl1CGyPITBLBoAILJr8URwLQq4LHIFaiwtynwW4SbSmZZzM4ewm2nwbWlBcziOkaM/ygST8odJ
9rwiHBKOCnmBdXmnuAe/FDuxOMovFJkJEco1mF/G9uAXYvood3Q7QHRjo0mNY1em8ThlnEGN5Gc1
WAV/CCOhloKlqy9Ek7BuhT28IWbArAO3/2HZvHfuaN5cs6sr/vyy5T/ZdstNj6/98cYzT26BzIZx
lyD92+HI89Ybv3jtyFsHiEbeDABbhbmDA9+zVYhYppgDYpyFbDt6xk4IiKEhdkZ3DCIJsTP/dYj9
tGtAvnYj6/yF084pxGxBEX6SdSLqJI5OIumbX0W/xwbj7y8AJ27Op7EeS6KP9gFvQUuYrrrwuITl
EkWuwY25RNQlIi5R5MRsCscQIuoSEZdQXcujuYTuEoZLeMlNqW5xCY9LWC7hdVnadAmPS1guobme
mOgS2Mz90R6laHUp9jh7XPpL8OM49wfudBwFxXhSCkXjEsMki2O8P4aZTYB8MhI25cMpuCm1NYVS
wWBET22yoMVSsaCOkEUxJBULH+keiwQGgoR5LUSFQ6XCQWNaljso0kNEYNYuDlFF6rjKIQpvQqlN
URilN4h23yBKbxAlIV2L3CBKA/tRGnnFW3MOVI1SqBp1w2dRcocKgGqT9PJJKodJKofJFDwMIAkz
oxJAPByGoJQCjjEdp4pyHI10gUBhGOFsWwHQnLJ9dDzBATE0BAbCZal2eNOuBAE0mdHfCVBQXd4z
akFDYz1ktWv0sFlDP2nB3lJjYyPGrKPMTrPTClLkWsCuuurzpn2qFYUezV8YUFjt6vx/hUndYMmJ
dgRJ0XOsgVCYIKMOj/d9et7yh0pue+PHP92VnHbxoh+0Tbn2itUD2fSDo6dfM2X/9j1d5ehHC6YP
fPCprofQzptuGvvo/V3vYzuwHotTI0G4QIDP2OGeGJenpfCveJcSnEuwNCT0XQTM01L4VzRMCc4l
WIKPi76Lj3laCv+KlSnBuQS980BCSRQ9j5E2SVulVqlDOiqdlAQglUiLpFXSlsKmY1Jekkuw+wIF
FjESzxC80Ive9TYIeI5nZV5IcYDdwm5lW9kO9hjLd7AnWQTYOHsYr7GsC5nZ7rEqlkJmlkJmlkJm
1glZU8JBzWw3WGZHi+eDZcJZFCljtZ6hKID8CA5Y3PKf+CHjra/1M1gprm9ra2P/59ChM342jd0V
Mhqb/5T7gHsH6CAKA/bIiAF9ps8XDUajLGvi6gWVKPtscI/+ms4Eg6EoihfZ1hjvmKAdmcJNka40
J1nTvVOD00OTI1dG7w4+gsxwMcN4ihXJ72o3v6tS/cS5o6rfn44LUHCCMYMdtFvAzF+4CPmki5A/
p4FIwdVoBDPbg6g5jKwqgkUGtSsGFXaDXtxIE7MiUtZTVRqep5JMkTUIx2ZO67ahWWo+R5vZbs/S
RVuDOqkjArLZbIvXBIm+rMfvQ2yytAz1d/BVHcKCBGbC9bDfm3D4c225Pa8cyu3f9htY9N6fYHTF
Z/f/NvceegMuhD96NfeTPx/Nbd39Gzj157l/5g7BOhjdBZXv5z7G9VyDO+E1bJcs8KE9qsYLTRYm
2Tp2CDuBnc0uZXnJEiVR0ryWpAFGhAoN+gJZqtgkQrE07oVeVGrRp7eoqrOoqrMcd85xv3sOdfbw
4Arud8GD46nOO0/bUT+80Gx0rA2M9ow4cD4vFlxuM3tqMfa7adi1wXJc7wZgvr5Ov/UAAR2LYdbV
SUGBBu2xBlrzxMVzB1119cWDB194ta+YTT/ecunAZ8pHDGpe3PUOrvMrWM+spp50KdYyDnygJRKo
xhEKWuYbV8t8U/CqOYouaIl3n2lTHVVwxuE9iICIqHc84CLHS66tc5a9ejvLikpnmXS8511Fxc4y
FHG86SrNrItzm7jtHIMxDAD3YYvSCtgaOpJ5FHvMnCeON24CDD2cBlxAqNDqf3NhzhcuzDltO1Yn
Trn0Cfbdph7QZsi0KTtXAQizTUTsXacuU/CUz9P41iuvUvcYgR9jLNaFW04DIXDSLp5lzfehkeZI
31XmVT5WUYsNXQfBEEmKAKLHFVNPDyzkuE6etEhqZxFalEltRZPUkaALuxdhCzESj0D8FwlptGc0
yogabWft/wrvbMW1tvy/z58I90R5LszDrpEjrgVRdRMoSP4EsYsY+fWlcTuUSFiYJpgWO0CJH6PK
B0YteKDpi9zrufXwlpd+nL2iz525u7j9umfWnoUv5rq6nmfgxtun3eHXCniRIZkkPvjgPhDAve8P
1jFk+JLa/RRbzwxj9mss3eQPhuuCoqVaPoaDwIhxgk+RVReVqW7DqqTdqgrBMZoKIcEOCWtdInoB
Gq2TaLROotkWUne2RSFCFiHH0QgZdUMkGrOTumN2Es22IPv30NDZ6ADhvkoSrAucDKBFga2B1kA+
wAaQj2oKH9UUPtplvv+sL/5DqoX4nVSLQI9UC+QoC/93DVchsYLE7XqgoO54HqCeCnZUurMqdF4X
UjqvRqEmGi74AdhNhpThnfGcnpim7baO5T8b2bZs/th7METp+uqB7FOPdU1Hj6+7ZcK9t3a9iGVj
aP4EW471rQbC8JU9/hCpqtcNtxgEzM6isXy6wyPIYXUEf6k4mW8Sr+PnimKdOdAzMFAfGmaO9IwM
DAtN46ZJ482sJxsYH1rILZSuNRd6FgauDd0I/RLPaVcxE7mJ8lXqAmYWN0teoMrBGCtYGGz7XKbw
uR6qj3Skl3ZMWZR6o1HKGMQEOt6oQP3QQnYGsZAFw3jSNYwn6VBdwXhSosPWy1J1vQUIBFOIYzeT
sKBMoVKfoxhxkyMWklAHpnXKFbrqjIzTAfUyoOpEaj1UZGlyCIjRjqfBjAIGpogfBGjX2/h2BFwj
QMMggF6NiDgu+0RIuIMyRLcicwK5LRks0tlzGzM9rTDxV7EatKUJ3ATpGu4aicXakAbzvWZ/zALA
CdEDbw8PduhTd/3qTzBwy//cfTTXuW/nurU7d61ZtxN5Yfm9y3N/6Tr4P9+DxVB76823fverN9/A
/I4xLfM1yRtDr+1xfFTJ7SDRJVgSAOhDAQt9Kp6WXIGmXcBP5qdKjKH9nTvNM5JKBId3+hc5Q6lU
jl2CIdxGh3EmMTfKyMPHvYk6fLuTuzzlJEB5sg0vPRzdkKAb7DvxFp5lOZbvL41guRTfS54i38gs
k48wf+WFp3mY5NNCSmzgB0iDtDFaE9vETxGapFvZFdwj0mv879l3+eP8Z8I/+W9Ev0eWsQFjEc8L
kiTiFUkUUwLvEwSeYdkUJ/s4TpYx6GVFbCjoRCos9EBm26FhSxxL0zpKRbI2LE4zY0wHlm3SoKbQ
RlQoSym0iZQUQHQjohsR3YhSEDtkheEm4oz1+RdnzAkteyi/eXpgkbCq/SUxYnZPtyvbQjwowlAO
rGs5TQDdqUwn1ixkdAjrl0bsXa3jLsiwt5oH8DKU0TEhmGKj2MjQcgdPM6a0kRIske5kkBTSrDqS
vNWEWZGwoSxVFzVIYlFRI+7aD3cWNeDFOzvjdLEj0UAr0oRZNgtbMJPiM/YBPt+xM9FAnIedAbL4
cKfZwDsLuqbSxQ7FOTlDU37IrTwfsFD0BfDdfL5GWuCzTu8MkZP/tiPqHE6EIVugCg4AcPAArIUw
CQUM+uFPP8vNg698mHv8dm7/2Zdga25517Wo5ObcVZj3HwaANzDvm0zQVsUqhXQOLZ3ksX1AJBaH
9IWoaxaahCh2sejQwxd2BaFUD9nNGSojAYhESdGBKGHHkKe5g7Q3FWwk9tCkQRM4g68OCHVhwVkH
FpBckIO0wJa9o8M8fLiDjBRmMg7aAdFC/5QIFC7xtGRoydKSixcgyld2klCIwguGolhEBzslmlsg
qwUV+bUbMaHpEvykNAfVuOypM2jBqQyAugJELAM9syKc0J/8IpoMPMBEk22tgGN4N1TljH5A8iyn
ak451q2x0XmYbA/s5gxLRu3bATJEH4qK7HJ1rfob3JTqZeplBlPJprRqfQpzFbtcu0lfp4kK4sQG
rZ8+Bo1khgq2OEobrMsPo0eYzcJmcRvzjMB7EEZ4vTmEBRiJWDP15kRMiup4YzwZLEcimRGJMYOu
m6Sfmj2rPMizH20DGuyzk4tjke5jB1RJpn68TMc95Lit3q5AZT9+YB0q+CjUjhcG7JkXRdkEU3Fj
kQnNdjR5b5xr5lZxGAejbbusCzGwDZunsqeyjaEuggM6I2GzE69Feqwez4IQxnRUXt1vxOzsJEK7
7tYD67DIrqM+xchWZcLI1uJxU6e8DNT8Gcyl7wKUf3fAgAFNcGSrivdV0EQ7Lf/1Dl0mW6ksavl3
9iQa9OpEg4YFdk//Br1vf0ru7oW39nJFkIwXYxHONjVRYUrAQLBff5jAWAOLlPUwLINX9Q6E6+F0
yL2Ym7w9N4Xbf+ar+y8d+0Pm7LfD2TfP1LPHzsQJjkzkxjFfsGkQQfPtEiPkAC8nu5COKtDSYAsB
vVN2jWOEaTiPlqpzhGOWaak5A6yqi9pt2k/O4Gsh4bNI9hmMwsTChodXeK/tMeKKrcYNGmEzwjWZ
yAeR0EHc3mRB/TY6HB/dZcRIsuWH9sJYQ4VvsrFdZmzNNpARr+hdZ5JCUCVPQAt5ypVytVzrp/bT
6vVHLKXCU+G9NNDkafI2+ed65nrn+lfwy7UV1s2+m/1rtA3WRs9G712+h+Vtykvmi9Z+3+fyp75/
aF3mN758rNhTEOqAV4lFWWOocafBGOHu6jt+pachS73KqN3fMFTT8nhkwIR9Xm/KI/vwiqEalppS
ZJ+iyF6SdKjw5AIgZsZQTeyVGIq1o0G7DdwWtq8dTbSVQR7bg6Z7XsG83w4H7zFgKRgWlcku2lp2
XO2tjlGZsWpeRSo+YlcNSURFg9qi8ZXY7ODG62o5lW2JhCjfhsxTx8Pm8WxLZyRkdlIKM3KnY3gI
84o9LQ7AT7JONxsbxQMjW3XMqyHMqy9iPj4BlPwJiLm1YG72AV/+Q8ylcinmVIwXdvsbrFJ/g2Nk
WkhWXJZYgMx5H5DxljvZb/gLa72Ed721EDvdGCfd7ruwuvHSoJXmlNzCVz/IlJZk/tqWW3BJWe+V
k+ty1z1rVpRF5xtFbEXXI8tWr1yO5p/5zfbBTRMIL2/DfuUabCkk8IR9Ec2uv0+A3Qn2QBQei6O4
glBE+f+UUf8dfzD3L/6gfOG0/5hPf7zbE8x+N5d+G/PB2Y9Ra9dYkkc/8IWu2STuNSn/KWtxHcAE
RciwNUe+DApUeYLL6Ag8F6JwzyRllGyleabOUVEaIqEjBLwjoRRW09GdghTKkWKW8xVrWlByU34k
mjVLnToL0HxVEHCe+jzzd7AAfl1zd96VnIw8iVjRQoz/CycRF1/SyQqiQAxQZ/08i+pcs42Ph80Y
bteduLd+nj+G3dtjwIN/BvZlR7P8OrReWW+8rnOSoITQMO8V/svDQ6ITvdP808Ljo/OF+cpM7wL/
/HBzdAW6kV+u3Gys4x8WNpuvh46gd/l3lT8Zke7qut7NeQOzNk00DS6R7AR2PUh2iCkhyQ0H0iaK
0RjtppJCOKtngGsJ9VTj+NQ4IPNJHBfDiffRI8Cm4l/f3e1ouBnY3U7mudgeGEA+kJiMph7Cg/0K
OiwW8PhNkitYnvaaRJwsE7sWAj9p/ttbl+9cOnje24+/s+L+fc+uXPnss7etvDyL3oYsvOj56bty
+SO5XO6XLzy8F/4o99CXJ+EcOO+LuWuJBBGuS3BPg2J41vZ6HQ3uoGOakEwf3QmJhwpB7xN2kA7/
qE6iJY18hdxmcsPqdASGHOQMOlLQHSoEvk/QIAQ5epfWA9SR/DmN5mPGdLnY74952tGLtmKwbHFM
07G/GCKhV8KgISc5DROEMWsO1ri56l0HzAMZMiGg0uPkj9FyZGRF0Yaizd5nvL9U31X/FBUlb0iv
ijBSb663sh9zGYO5zPTKfo/X+4Zu+HSvTze0dvSU7SUVsfWtOtJ1w/bDQqX2Gix8m0wmaoch2yLV
s6abN5i3m/eZrLlKcDlMcDlM6OYwYUmIclgIgpAZQvhBTu0lVQxtintegvXAgA9iyDNgp74b7ocD
ACDBum622lTSDh/YQfkIM9Ep/MVcVGAijFnoiHxhPN7CP7PTPL5OvCDDFbQ7ZjHKXCR1+TvquUfy
mZO/7MVainE8WYGMy0562f/Igu+1vbDxyo0Vz96L3u/aO+bO+zuguPSeU7/pgqvMDXcfeOLRnWMG
BdD/Pp9bPi13+ne/vn/nMcJfTwHAlRI/FqoE6nRgk+qvY5liSd4qH5aRzCGkiCIn9siU6fZyT9sS
0dNiHDuABODSBHA66E2TwKk3xpNwVxVF3pAmf2dXYWcPKVTbF3w+qu0VR9sTSZVxFf4LtS8W1P4/
zw32BgrTqOIajGtjtWZtkcYSEJlt6RFVcmNKzpZGmg1Mp+c0NmQLUUHqDSXwL4nLp15F3776ahfP
7e96Gk39djja1TUKA8cu3HJNuOUEoKMiIh5fu/lCzjiu5Kb9cy5BhnYc4RSdlHmWsqFYOKgwKUHk
C7GDU846Ugth61P2JT2GzALOcAVtQJqG6cBuTnbMKL0+pQVKQ90wqSf2VVuBcPwNRK7bdM7LcaZd
1Ji9zevEOVKzuZ7ZZL7OvcZ3mCdNReSa4GQ01pyjtJp/V/+u/V2XWJXVWJ1RZOzfs6qmi7yAAR/H
irwqQEA7xXCC1YLqw7sQw5BtfhrOiLOqD58lFWNfo5hn+Ha0yJaAqH5mY3SA9kMFQKjYHjUOZgnM
+LHsIfYoy2wiKQIQ2spYtUM4qjKbVKiSddMQDgnodmGVgITvG+++h+UQg60w/uG/UKfjLHRiiNUY
6Rx0HDsP+I/ArAyBWRhlkaUzOtbQsM48cEA/gNGXs8Qccc55aGMNRhT2509i8f96APUeFrdkvyuw
PT9J7FcnmQTjTTDpcl5gUO3v0JQPnuv64ePvw/99ZHhprJaE4eFLuaFoKty878Z77iaS+Xj+UyqZ
PqjactqYwk4RXxdZGqIlMlrHXigOZy8XlxtPcycMQQXIwqpvJy/5XFHtGTE8vYfImC+N3PEE1C2n
iMopInJ6AfV/s/EAjAfGBhBJrFoVYAL/JlSfjstQdmVVprIqu7Iqu7Iqd8uqzBa8YEdW5e7EDDnr
J/LZM6OJqMtRZjbb0jNmj2ExTVEDWVhrFYbVaM4lVYsW2/zqtbkz7/w29+2iV0e8cOu7e7j9Z3d8
kDv75L1Q+4wZc3bnK7uveRX6nJEObipuVQMUwbDtiZfAIWKsiKBRyyw2gBh0W68n/jhtl5KnDqbj
EnTyfiT6yCSAjksaZSVoxC6nghQpKSrkfNHAqUnttflfJ6/00GcFGFv875JXTp9rru55oTQG3o+J
OmmrrMjy4VAkhHisYmVNZnh/wBfwBhg+ygQT0KPjIiTGsKsqWwlAswOq8Gc1dIZEAsEAGcLUUTKV
IK5B97gI/Oa5qbc1LV0y+ub7D67J7YAN9/+kz7BRDy0Y/ULuLW6/v+iKa3KHDjyTyz07o+8L/foM
++zpT/5ZVYyffTbm6OXc26AIfLl7JppXRFLvnalhgCCS6YSKg77aTLAILC1aBe4s2gQe5Z5jfqLt
Y9q0X2uHwfGivxdZuqfIKipiqvgKqyoWLxmhTfZd6Z8cnsPNL7rFc7fnUeYR/dHYNvgU2mb9QfcC
H4iYPjPCIhI4q2igyYDDKhpMA0A26i1WmWgxK5lp43KQjkMIIyVByu7O7IygXOh4EYp0aFikzoYY
Lu4eFHaHhE+TyGEnhToWcY1xa2YJZsTtShLtHJat85TV9mULKePI7/MQ9mXbXr0o98uPO3Pv/XA7
HPLqn2H1ha/Uvvr9Z/86beEna5/8CKE+X575Bbz+9x/DSTuOvdlr6wNP5L68/8XcZxvoLE8ec/Re
Ng083PR9WCV9VZjapncPIBWpTvSUsCING3BOAgSiaQk9Uh8+d0buTGpOeL5gxL51c5C+dYCmk/Tv
cXeI3TsEvpC+9JUDLp3grUnNGc8WEOjZc3OHe7hGHhfKi907BLpDdkbxXXtI4XxpYccJN8h+whnG
teLO7oIV/tC1uR/uIoQLYz0kVY8Oizhz8PiCpnqnTdWQczWFUFZcdXZ0tOlONkaHXUMoy6brssVA
oGIPGfKGDGRN5Yn4qhZErMxaciHTycnftQgOPmi+e9B8h4Yp8acwW80RaUjjeQHDB6vYShldbl1l
3Wsx5HmorjzmZngcc7MGT9pSSaLOjBU5YX97b0lZHcurkpePSmEPxwKWVyRFFz0m8DI+ISZGlSK9
DKSEKjGj14F6YaB4oT6UGcHbwihxpDLEGGFd7rnKGO+ZL1wrXudZwd8sLBX38fuNPZ5/8GekCsWq
ABVauV5hlHtqfANAf8+N4lrxYeYh9Rm4DW1TnlZ3gz38fv037Lv8+9IJ9oTxqecU/60UU3hSY5WW
Ju9MqnRmjtDRsoKzGpV1g/UASxTElGCkdDIxTBcYDaoprT3/rt2fyJyGUpACSahBnxejICstZ6yJ
7Hh5mrXAWmltsGRLZhkASXc4HXOuqZ1IUE3mFP4j6+Zx8nVmluC/qO1jOA5h7MJJsixidpZNiySF
jtzFAU+8PX+ZPVs29PgvLQGjXcvjyXCCj+MEHfdzStOx76CLlmFkZNGHTwcYNKcgNtyQvItA8LCi
Yam6Rqvn0VSVvGMAIch7DDKuLvtOmxokUHWVxmjt8Blbjo+R4Q3y7Rh+t6NJtjTGgjdYt1vEwE+y
FZODzTQTn+Hwwbvhae/p2VQVhUedymZDXdkW/BcJd2H6k+5hDDcw6nFSxRocmIPLdaN6RknPX2Cu
XKebBwTdbCQ/QpPfyNaSCVPatLgaRy9h7wzin54/3AZ6G3Esx8eoF0Nx0cjWugl0NODwDoE4N3hD
AoOoWhplFfPHdghxZ6unAK32kQvtMeLk2lgTHN4p9CZX3AkGoP3Onbov3n1ekJ5n5Y/tkuNsHAzo
GQnT8+/s8TSAavwjYy1eEgVzXCtnxgARPxqzPX+mz3/6JGCtlwbGvEESHUsy5QwcmXtx/7OD2Npn
922pv2jP9lzbi89Wvsemu3543HoDXd/18JsH0ewzR9DK3WcPYV3txQyxClvAIKy0i30SNMI14d5h
O7wo/EP1Me1ZTYxoFVpruCPMhom+sSMldUWixqhGTIZ+lPF5WYYH8hYf9OW9VLt6bbZgqGggI6g6
03dZwKAHoDNBo09hgkYmVlK3CWDQQ2en2RoZNvNRNFJBoUgpHUirLqCRrwpOlq9gnj93s3w+obEk
glf2UpjyZCj8EtwPEuA0lAFG0T1m9pJB20bzFGa7whBbZ5bE3BoJWOnE/EfRis+0eEngRR7xpuSJ
Aos3opDMsVm9GuLOAYtryUSE+rr+51KB/H4yKWHnli3eyB3Lr5gWHdB3/NBDh5hHN7bMrxt+pedH
8vDmazaenY3bO0JyMrBtlFE/wnEF2+gYJuBEKajN+dwxLShQsISnXNN20qY+FDLPmRA7yIlAFrF6
kQEniRxEXBlpQK4m88FB84ODVm0t0TvEoY/urecgKLUaiDmyNatBCnhidSIpMBr5fBdewsJSJnm3
UnGiDlTggk6elUpTdSCAC7x2xL6t4gLsFOPCUCtBhZSWG0C9fCkYIU/GLlmTOEWaDWejueJc6SZw
I7wRrRBvkm6U18F1aC1zl7Be3CD9CDws3S8/D56QXwZ7hR3y6+BX8hHwB/lv4K/yGXBKrsaPI4dA
QK4Aabm/PAbY2KezPYE6DjdOXUFTS/h5yKMDYphtgxooQKM4pC3INjoDl7QK3Yo4TlXIjO0PMrht
8O9g5mAG1BClTNrH7i8LopiSZJ8kyZhnXbXJyViHS6JItKQgS1ipczXYzSsVbduWVpHQH4zutrEO
RFgHRm0pjmxYqnz+e4KSO4nu68pGQp3HswVV160GrYbzR4WaqAmG57tvINsEe4p8IRgOf5Zb8PPj
qZJQ5m/7ctdjEb/zuhsmLkfrnazItfkTbAkZE8V+xev2LZBTjTKunhvGcYNKWktQSQn28mKDY2QG
Az/QS6YzXBG4IpIVs9oUIxu4OjJPXKDNMa4PXB/pKHlfPRI8Ev7I+7fg38J/pXMgwnGuxqjx9eYG
GTZ3hTGWm80dKfoH+62pmn6d5RGIkiw/2R/Tz5vq4LBxiEhziqZOlx1WoKnYSrOySmEdT0ahMWUl
VBhyPU29EMVNFlHc4LFC0Ad9JQvp5An0ZS1LoUUxpPPmEKsW0PdsAIouC0k/zjtUahmqlxiqo5gU
Qv9+1nfOna3jTv9We0z/9pw3/fvr707/DtHp3z5n+nfxiPNnyfSY/k23HaezHbp3uS6mk0vUcxJ4
IukkDRUjvwmSpeWML3guDAd7PdO2eMc121vs3FcvvzQf1U26f/nzP1m2/Hluf9c/7htz3xtLcl/m
3v0R3PzKpLsPvnn4tYOETzBEh2uxRiJvJhpgx1kO8IKE+EaWaYQ8K6PGGpILQzzFx8XHH3ZiGJ1k
grrZ6RruPr1pci7+7Tt48CDTdPDg2WcOHsTXHpwbx3zOXgyKQRX8ld2sKJyvWkn5rlCG+XipKFxU
raR91ckGpZ/vcmW4b7IwRZmjfCv/w69fkKwuvzh5cfkV5Zuqt1YL/RL9KgdVD1eGJ4ZVTkxMrJwr
zEzMrGyuXlV9pPxE4ovkl+VWMMD729GOtoqYV6CvZTHjoDd9Kcsq0AEO44drR7faJheLGfKw0pgq
B/y1qVrZ9alld5ICjQSUE7aQU6HQ4SA0g3awObgqyFZjA4QmVVMeDdJZNsHuWTZBOssmGKD7qPam
U1I9hSmpzlB70PFsKPGt69J/a8+hdnKpAVOgtIQaghLKliWURUvKXjEOGUeNvMGWGIOMMQZTGOeh
ozQGnaNlROi86FI6L5pMg3BnQ9M5N0Y4U700UXd+dn+2ZZTzkguz58wbOvWGZsOeJtHh44UA8XEn
1oFdx5YgccLpuFw5nyxFzuybYH2t5cwx7pnANHu70nfI0lvXh3S4vPVPJ6//3T0v3fz0rD9t/fnn
jzx968ptL9x807YpkXGpvtdO7d96N2z84GEINz686uy8rw/d9BxT9buOV9765Wu/JBw6FWDZxRil
GJSCO+2ajZG7o2hlZGUUXROZFUXz1Rk6mqpO1FE/faiOomFRYIFZbllAq/TBYtzt2+1kojTRWCKX
NJaWxhsTiWJwdfH18tXBeWXm1XELWvOSV06lQfJOrKxxk9BQXBdugEbzdCONjx93HOgs/oBsFqaJ
9e9/MXKj3wQJsH4feWmHQMQA/hEWB/qUvTjgqRuXPBraF/7nm+9BMPWOKf0iqP0gnFvmmTdq4IWZ
n1wzcO6WTY8EDh75/OnmJ5aOvrx5Qe4hLDcQTMt/yv4PfuLe6Ff7QHlBfaZdPZqiUVuqUSkKCNMy
Yham6JxwMzUdQnGJmEvQYcCLzg3DIFpCWs5kZrJLmKUsmyqvZxpiQ5jLhCuKhpUMLRtePoFpEqYV
XVlxl1dPEmkpvCTGIVIukXaJcpdI0pCSc7BDpFwi7RLlJKQ1nFAVWroMlTHlqX5GXXJoaljN1Pjk
5KTUAmWeNl+f7ZsVWqHcrN1s3GouK1uSWstsUO7SNhj3mGvK7kg9oG02NvuLC8CgVyLtiaYjUroS
pgGojHjYvn3SYBbmJ63XiuhdURRNBbRexeUpmOICHJFkJ9xc3EsqLg4wNGySIUP2jkOWLYzeBxtq
Op1v1O6VKtM1hUvEioqjosCzDOJhqqwUb+O54miviE3E8r4IjHQGQC8a5qFJRiaMw7GwGS7CJoeH
7bDV1nuRW5Jb4xpfLrl2sjuBTyqE3jCVBpWwkgBFonAqCzPmMRXpm6B6IUE1SIJqENwCMO0hAVZy
sMcN7Xm6Y+CeiUSvh/vMdF7ylh2F7VCms5B6dtqNJBViSGZXlr4BwfFXsUDQl9xgsom+6OmcEoHn
TWgnnoy3fzGiE9FJvK6sPE3fgPOdVxWwQfJiE6JFytLT9mrTf3PrDT+dMHbahbkF4+Zed9tXP3jy
m7XcfuOFZ1sfbxgA35+y6ua1Z37069zfH4Hvmdffc+XgJUOHXZcMzsj0f3LWDb+4du5bq/W77119
1Zja2vkVF+5evuzQkqWfkdjUT3MfwjvAQSCD0btlbPKe49vhWDsNmUaM7GTYSOaR4xXADxAGjgHT
wQ3gdrAVcGCrUrB9dNYyeXkaKU3cKJ3OHP1aLPY+qgr67zk49sq+Df2Ygwdb7k6PCs8gGWq9sQ7b
T8dmPrTDPI3nCbTk6RwA4T/NBODpHADh38wEsAjFoWLMdYC+lFZqR0t2xZ2xiL18HKIa/CSY3g0L
41gnyMuayDBVIdD7lRvf/ciN+J51A73uxHd8RXHPIz1DvbgJsG48nv3EpK0wqDA8dc4ltRL1JGMB
eXNF7IZclNNeeOHbv+P778fNvw63PANSdgiRhm50mnc7YLfi/VtZ2sKns1nCbk6D7sdwgvTaYwBw
BMtK8KU9zrCySBJJaNhPcYP+YkgNFDJSiwglIoaJC6JPEESslRlRYhGSBJHku5+h4sW44kW22BLd
FOd5zh2R4LpHJDgnObA9/087TTP0snEFxpWxGLYuwsCVU8TuNBGVpolQ/1bDlfrv8kXYfx047M4X
aeo5f4Cmn5Psc2rIe44U0hdONTSsY6k34ejAfWSgeq9q1YlxlWSAZrCkkoDCkGlT2kR7OE3n3DO8
QbT7OmTfBqE03EDC0nvCmOzrkGRrkpK2kmwQdB/+ecn6qT1eTBY5ZBEm/YT8eoe/wVUE5zRAxklC
q4VkCBNaj/2aQft/fTbH7T+zmr392+HsqjOrcEutzI1DzdjumeAiWy43IDA9gmia7bB2F9iii3hp
W8IW/WrAmEycYZjnrR9tpDzTdZqYbtoQxEzDNLKIha7lBTJNx4Tw6IO/HTX1pdUryi9K4mrlxr0E
v4b6F0e6zhxu2rD5xZdzJbn4efefZasVqMJEkmxC4JFIDeQt2CWAtW1gC3O1TtyRwhvanPxP3Xl/
ACX+ZhuyTF5MU6Ij/XlPoY6kFb5TT28SWOTtLenyWvLuLxN1rcZtVnpR+c2rX5o66lBuHDwG//LS
vs0bpv7+TNeRL3Jf5URsvx7H0vACloYQKEUD7YRH0aGnX2xqyWxxYQkr0fQZkZaCWXi5UQeVdM3N
2lZdQnEJbBI+2uWJ1HlIpnZpeZ1F1ovK68zC0igs8f4/7ipKO/vx8WZhSfbbl2EipV8euzw+QZkW
WxhbLN2krzDWyOuNh7RnjXbjhP6pYeqqGrcMn2UZlqFKnihKRAIy77FMTeVCkhQIRsLFQVLjwkhX
h+2nUDoIEqU0RSsUMgxdLHZHxYpdIS7uHv4vTuuP8W62Eu+KGx33r6MZADTUy2fjZYvKVpUxZaUh
1GMyLx1fCf23mV78f5Tc5IXb/l2mV2GUP3w8VBgnc+IANO0L8wdeaaihMdFgwzrdycXo8SqMcwKV
pYncom00GOZAyzOQiBhsKQQZP7Qj4QYLy7IH/3Q71mCW+vCvBP+6hbOJDKlRkyuQ1wR5k8wFqDyd
TNIJRxTCJx5HGw68dfMbb4+qmHRF/tSrk66/sldi5F/g42s2j37oyVxvbv+Y36x47N2iVNnoZbkW
2OfOjQMUoWsZU9t/xYg5NFfIAID5X+xbmgiSXI5CtMvsnp3gpH0yPdM+/QZUeBZJPOI1GciFdM+a
DI2cUxQe3Wt4oIEfjOSf22PDDVONzexm8RH9UaOD6+A7hDcNybADDRHGK/m1iFkPByqr4b2KWOO5
km0SmpQp+kPwYflhZS9qV3+jvKG/ZR5h/iD9TvuT+bHscUcAFBV4LCOkYQeOJtPphDJ4gDSAZZun
IkwAUCZTSOmczfOMIEoS5HmJYxlGMTCzaxo0DM1UIJCQpjCqKfMGMmTzNfCahMwUkHwASAzSXtOg
llIZn6oysiQxGEhi0VVVII/xQM9l2m1qqWzM4KXbbLkdRvfa/Fh+Fc1OGGLrceY2VDoGN/Zl1ko6
szF7ygk4RUKd5sfmqU76ToFzQXcSb8oWAk7ZQqZPg2GsE2ko3SnxQqCpnY2FyHWbHipqUKgJKGpQ
S4MNDP6R9Z2JBpMaYH8DLE00SJjXXC5tom+Mzbi5nbUQ1gZJ5Ko/yelnyqEB78w98pcnL4hVp3a9
l7sf3v3BkYG5z1AFzH0zovfg2jM5teu38PKmXJb4gBOYv6OpWDMrIAj+aE/bEt4eRl8KX3rRUeGo
Fx0SDnnRK8IrXrRd2O5FW4QtXnSfcJ8X3Sbc5kVnxDM+tEBc4ENTxak+pIqqD/m8ohBUDQUwxjc6
8w3SNQTVRg00apAAwhrvDcLtwn0CI0DvAF+jrqmNWOvYwUidvgwKA8RGBEEjw9yHFVI41PKMg55J
PIdgI2yuGx0KDMpiycaA2nTAIsWK+A+Yr5M33IDFLS0tsKXwwWbLn6SOZZDnhUQPGvp+Ea+6qrp/
HQN/4FLsgd/9ZG3j2MrhwauuPEfhlhrBfIZGc6/TlvqTPZq21EnxpA9BEfrQMeGYFx0WDntRh9Dh
Ra1Cqxc9ITzhRQ8ID3jR94TvedEiYZEXzRJn+dAEcUKhpQxVYYDvOS9pG1XDTabjxoLicwLZ0Bvi
BkSgEULdaFRxe5VrwYtVVSPNpS1DCMNp3GTlgAxmz6OthZm0kbz1sJE21XGT0hRSE0DtLs9vrO52
amnB7YZtJwHcgoO4a3vQV/6iJHNVdb965o8uwX6NG+jCcZUjAtMnnKMIV1FvgMa+dLDGrlmi3KF8
X3lSOalwQIEk5jxcnizPknfLH8mCIusCiYkJjRgi6qzynEyePck1sjRMthobZV5oZOUBykCuhh3E
IgLFHzfckFnhefGTYU1mdnWdxxLAeUD8XG4grduVOFhwJtyomutSYIGfyuyC5fR9JWnbDzgGcl8g
wKyOY7cSwXl8oaEJmobO/HovuTKz/oKDvfGZnn/8I/cFvsolsB3NQwtxG1Tb4UVoEYNGwVHYGUoC
FOEWEfeQXXQPYfDjWfMTUDMKQ3NAmz/hvwRVwvbdu8lbzcm7Uz5z3qwDquCafYDFnmklndPCDk9O
Ts5OLpHulPi5kWXcIgm3M3eHwpcHJCZUXlUcKJKctwj2yAilaaRR6vFKXk9xVVVlJXCyYkqKiy0g
hlz7H3Ltf8h50xsx3mnenbf2iZ2iIIDO/uPpgDhPs/R46uzzNDzLT0y5V0u5VyMhCttLrpZKqzFy
NZVOH6b5C+XkCmqkGteHQhBqv4opcCj+f/HS9e/mhmf+TVINdcOdnKOery/87nvX6QtoaagYeoLu
G5V6GHhc6igJE32dpBls2/E+J4CF6c0ove3NJbOvW3Pflat+sTH3fXjR6gGXjxz+vR/n/gQXXp0e
MnXgxAc35jDkbNo36+qna8tfWnXdjuY+zHgrMHvUZTdUntkqqAPmDx+/og/hSgkLwmWYE7xMfB8w
CzNrjMKUXzK5//x0CycfmOZsUIeXc5IN6VatO1/d250vbNeeC1ylPTAMAwqq9FR6B8D+zABxgDRA
G6jXe/p7ZY837knUeUiB73aMzD/UCkupsBQJJFyACZYcxZDiRnijgtJspVChVOlpTz92oDhQIVe8
VJzIZsVpylR9ouc6OIudJ85X5uqzPMvYm0USkrrRc6N3LbtB2CA/yLaLez2vsa+L77F/FN/X3/V8
yp4QT+ifeKp5mtKiWmiSGSClIpKSjB7sIsQ56OH3mSHZcqEHoUwKPUQZK9p/gR5Z3gEeFHaYptcg
uMM0Ncvj9XZDD6+sQN5EXkn2euPdwEOL90QdyEtRh1jjh/5gMBJXbTpvZPreuLxJ7pAZrPLad09H
WxBCmLJlvs02x5qHTAa7aNNtOQ7CPv+rieZtNNQcCY/qyoY+DndmO7OYoO+J+S4UOW+snyIRikWc
aSU9Fw4sOdBEwa/D391BBwp6FYJNwhiEYMAbijZ4CDaJNnidBUmi2RNtEEujDeSteTtjDfS1aSWx
Bi8GLAz+aXog2Oj1BIIXidgHaWRYTFG8cwEWqVJPg6IWJS6CoCjRqMiEQoRSvUG8zRvE2wiFMHUe
Tj9v7B6j8+8GxggkcmZl0WmOJBUTSqh/Tv0UyhOSfYbA8re7ulDmZO6+kkQff24TOot+nlu/bNDY
K+GarlFnv0FKr/qxxTnyPwOPYnN2husAMjhiD5ULU5bpeIYztExL2Zlb4Ax62ZpVN5+9Hd2HHhHZ
51koAZ5DjMRBFcE3ZCftmWSeg0L06Jg737EwlRvEqCLTC3rtpB2mw/CFeRtUo0VUztYM540TOrkW
B+OczSEurOyHjXANcMxKS+a892JiR4kElogP5GqyQjsmkhZGQ/XE4KMzbZe8PfGhj2qWsrdcvLLk
ZyPemI5rOTn/CRvArZCBbXvOTT9wc557zh7AvBKiIzmhGKCR2QxJroKVSVkzVKNYliv9xTG2uDLG
VWpJTQ2FIfDE6bhfXEjTa+LD0zVkWgqZT3CwBngasF3H9hxr5M7XzNc8DeaBTF/yI6PKFZwW0IZp
azV2mHWltTzKjA8sMOf5rg0s01b41mobfHdFf6LJXJy+i0Eh/+qRFSC+L7bNT+0iEwdehOS/82mw
Hj+Mnw3tR0+BMJpjS7iWHK6m5nFjxue9A8OZQ+BZMj1+QxzF6fsA4v+X6QZpOt0gDcm721HanW6Q
3tQr1A4H7Ay//e+mGVSfP82gxyQDNxsUY7ou+p50EkU+fu7luXDAACrKzv8I6DmnQOjfc3qB+95r
x5SBZGl6clvJg/P/T3vXHh5VkeWr6vbjJulOujshHZJO39t5dIBAXoAhBJNuSEQNgQCRIQwQOumG
NAnpfN0dMviAVkFAHXF1hlXWIcg6O8rI0HQAO8AYFEZWHEdHWXbWx4ijzqg7Cs46PtaBzKlzb4eg
4Pft7n/7mc4553erTr1O1a1b996quhv27b5t8pwMS0ooftdq/70ZBxwf/uIHpzpXeu+4/+L7Z54Z
pndmPbw5esetj2bsZD+4rf2OjRvlgydXxbytj5TYf3nfsYt//SO/Ys2AsYseWo2dZQ0Svdpe+Gra
S1v7qNco5f0LN6DSlNQpCGaTMSs9Xac8YDGbEXzsSuIv/4z2DK0dV7dwBRi6gK/dlgo+dnxFZ+dL
Vgws2WqVJZOZMVniVjr9IucvklLcqhj3IT7B25HadnmCBotFeaLjSkqDS4eaDjQeSzq7yZ7B3Xjc
MYhaKYC6dy6er1dKja+u4unx1DAx1zXV2mrdEe2Q7oj+pPi8TX+DocXQnNpp8KbebLk5favlqOW9
7PdyzmcbhlKeSmc5Jpsp12Q36Z4ePg9WPEtEkEnQL2Tbk02iTnfKlp1hs2WLtmyBMjHbJhjtJt66
55mpOU6zDvISEJ7lAcoMyYk2OvoF7RcufOeZHLK+CtXG2yk9AuNumZjoNJfBfLCWtbIA28A07DAr
IBLdprZJbJEzTJ9eGjh9hI3QqrRC/pglVZ1qD2PbxHqqafyVe1BdVVU4xuGsvEadcnypRfL3FXr4
1+j/Vsmshf+849zjD99yxyN0MP2L37762fU/e3b3Uvveve4Z7cfWn3hvZeeDj9yd/tJ/fLh38Z6j
j23xlPM7kGxoeyYYLSXDuf0U3wf2v11P4ns83eidGXBorHTnyo4N2J3rlOcoSteOXFm5oazl0ONy
MlFU3HFaEXKtqHwiAcfWyJXLgmWxocOww/CE4XmDdo4wx/gjjWCBiiIGnaDXJqcIer4TlfGUoMkQ
BI1gJMxg1OiFI+wIEQmju1zJRKMBFXIqWRNnK5/SapNdudKU5MSFI1lZ66duzK/MI6WVLqPelZc/
RR9xTNXfn8aUvYYyphBmYjITmDLBFNcCvHsIZ+8cTI3Te7Fe/8wfh/Prhvoo/I94C1lr+nTGZzMS
2zdtVnZJSEtLS0zAM8J4wIKLpV0pk6uEvElVgiY3d4byvILgQ7UMgyulyhBpqjK4nFWGPBtIdU11
y5Xm4hF85UEn4760gpmy7Rc2sp88+NxzBy5Opa0/FQ797cafXnwUGuWPL3Ty3mbN8J+0g9pXSSGd
68rOycgZw1YU0eViOrUIBQXEYbGyQuiJ8Jo0BqeQUJ3Vnio47LokCkOEwoLEvUpB4tQoUDZggjos
kAUBOvqiFWi7d0fWVSSM+NoBdWXFp67JuJtAMFJEi3LxLiYXW1Au3sXk4moKnKCdjBf05LHO9u9f
Nr28UX2QuUz9iAEfkY4sq+MbIY9skp7YBrBOk59jy7aNtQk6g9NUOMYpOcVCjTO/MMuY6yCZaekO
UM5Il/VwlKctdFBbitVBM8zA7EkOBykQgBF1WIU7pSf+JuBugnRqofmySe2ZVn0J47vq6HVjMiwa
PmvBLMxha7ZdfHnX7y72HxigTa/3U/qAc5+j7VBg07N9jmmbKfuH9edrWO2T9MLZYGiQLv/dGRo6
sCr+o7KeSOP8jfO29J+4+EXEU0nN/OxtHP6TZgxcOeCelwl8Jvf5xI6X50c+e5C4mox8R0G5muSP
LHl0KCt0kSur5sXEHHPdpb1usH7V/l9KoxJtpQLNGWd3GanRCH1/jjbPnmFMtlNSaOKhcIGuyW41
4fQUHLlYcfaSVV1N++LpF02/SlTYMv51JN7nT+ocS+v0rjF1Y+vkJZZmuVPw6r3iaotXDou9tk3i
XbYz4ulMsx5nghclJoDn45WHI4esbuRz9kCRnC87uIeZ57LJCDcbGTn0VT5Oi/OhSyLPlA8syMGR
70mMvgdXhyWFIRMOS0yUmKAzgQKex7mepvsnQi8yzZVuN4y6EcfuzB6nVa68WmurNWDdYNVYcQG0
Fa1oxX1+rJnKVBxWMFA8stZWGa+MHsEo776VQQuYSV0Tia1w2eh5eXhjQvW4UTG/JPDrg0Xd1seM
m/xk0oxRSyaFrwayJt7Quch9UxtzH1114ELfyxvfvvjuT7a+v/fNC5Xz7psbfGz3LTfv0SxMXV3W
WFbz8RvtKy5+/srdH62nDfRW+sQzjz/7tzeX7WmJ73xo3z784qF27I4tVR//tjVtxl/FHBG/srr7
naIJiS+uDl+4OF/n1J4GmKR+Y5z3RkRfc3EumXXpw6xf+/x2jQ6ctIvIbk2IbNYQ0gTyRhXXgryT
niR3sipSALgB6Dr+LV2Q23V7yGbw26KrIu1sD9kE7kMQz04MGyJ1EH4L6DwE0qF5hzwObjdx0p4k
j2kXDV8A+SjQTqCVQDoInw662aBzF+BBkDOBlkCcS+F4D8RRBvIw6D4C6d3KiccBYdIALwSazfXo
ZrIEsBvCbQdKgjjeAloENAMoG/K7BmQj/4YkuYveyZ7QNGnn6NeIi5KSkp5OPp7ySsorhjzjydRf
pHWnfWV6yDzd4kwvz9iXudx6ImvCWF/2j3MqbG25xtwX7Gsdc/I0+VUFjQW3FO50WotOjCPjbh/X
P/7B8a9OcBbfMnHXpKmTXiiZUNJY0lPaW15WPlDxmymGqdqp/1lZptZEDZlGBKwHRkyklCwC2z6Z
8jTR8h3tyXTGvxiv+K9GLmC4ZDwSMFQqCatYIMvJHSrWgM5ZFfPvfn+oYh1JpUzFetJGTSoWSRkN
qjiJ3E13q9jI9rCJI21mquaMiqHJaFNUzIhea1KxQEq1VhVrQOc6FWuJQdugYh3of0/FelKuXa5i
kWRpt6k4idRrf6ZiI71J+2eImWoEvpJe70bMLWTSNyLWofsyxHp09yMWEa9DnMRtqN+qYrCh/r9U
DDbUX1Ax2FBMUTHYUPSrGGwohlQMNhTvUTHYUHxYxWBD8SsVgw2TilUMNkw6iDgZdwJoRZzC82bo
RGxA91sQpyLejNjE82Z4EHE6YIvhUcQZqDOAeAzGM4Q4E91fQjwWw76OOAd1PkCcizpfIpZwCzQt
4gKubzQjnoBYQjyJt0TjJI5FzL+KMS1jFccGxb0eMZbFOJ88AcP2ClKGX4WXSTPpID6QjSRAuoHC
ZB3pQZdZcBQEzLkH3P2oUQI+btIFP5ksALdVED5MQnjkA+kD7bXAvaDpBuyHsF3ot4r0AvKA29fT
mj5KU/6a7nQ483icITV9mUyFmMsh/zIZBzH5STv4BsA/QFZCjONHxXW1kJc0GqH8o9P2Y0k8QGEs
tRdiWIP56AQ3nsL/xmL/0xDf1GseQXWo2Qea3WAlmcyDPK1EK3DfSWi/AGlDf5nMRZ8OcOHWDJGJ
4NaEKQXRx49lXQi8F/S9qr1ksFIV9H8VpAVC9sIxt8E6kL1Yw9w6HaqtVmJew+gWAO5F9x5Mbx3a
kscrg0sQ88Q129UwPvXYgzH1YOprQCuMfjxUG8YRVu3XpZazeyQXSohEPoKjdHuwVXghx+2YhmKP
Psw3t8iVy6Acc912SK0XLeLFNv91S/AQXYjGgf54kLyltKn5vnLc3f+Hsl+K3TtS90E84xJ1mWg9
VypBIvVv5qt6VB3xkihlCWN6iXbJ41fK6gWXPix5AM+Ob2sJnstq3Ye1E1C5UioF98JRD3IZc7t2
pDUr8XDNLtD4tjZU8oRcUVZeLjd3+OTGQHcgvK7HJ88KBHsCQU/YH+gukd1dXfIC/6qOcEhe4Av5
gmt93hJ30O/pWuBb1dvlCSZCTUdHWXWdvsgXDEF4eWpJeZk8rtHfHgyEAivD41FrtCc6NDYrof0h
2SOHgx6vb40n2CkHVl49Y1fzGHFr5qwu6Onzd6+S561c6W/3yZPkBYE2f7c819/eEejyhCbKTZ5w
0N/u98gLPb3dXsiXXF41raIl0Cuv8ayTe0M+OdwBuVoZ6A7L4YDs9Yd6usDD0+2Ve4J+cGwHHx9I
T0ju8QXX+MNhn1duWwfBfHIXpNnNowAPHkcQXXuCAW9ve1iGfPR1QEZGpQDS393e1esFI8uJTAS6
u9bJ4/zjZd+aNoh7lHb3t6aO6l5e+qAvxEvJzXMpAR58JK5qLNE4P6QS9q3htgz6IVVvoK+7K+Dx
Xm4Ej1J0X1CGEgUgKeC94Z7esOz1reVmBp0OX1fP5RYqgU41gCerB08DOE2pEZrhamiIH2C3nfBb
CA1TObX4KeQVdgj7hV8KQ0CDwmHhye8uxN9diL+7EH93If7/dSG+rHe8hD3YZq7k9/Zlel0Qz+h+
E3vOq8TZBTrrRh9r7JpyTYNmtuZa4FWXpdAN8V4tlrnA16IVlXO9g0bpo3CPzev26mGujNVnAmS4
iM/L+ebfIGkWxg04s6SXjwrjyVkgJoyPFedKg0KRkBurllxxIX/AMqYizT1J4G9/S5HLwANA+4CG
gDSkVeC7qJiAbwCKAO0DGgJ6GUgHGbGjrwwUAOoHOst9hFzBFpMlk7tIGAth+d1ommAl54CGgQQi
AS8FmgfUCrQNqB9Ih3rcJQC0AWgI6Dz6uARr7IHJkHdr7B4UA6u7KvDQoxwuXYaHA99rUWTjfEXW
3aCoTVfUyqcoziUzFVk0UZGWwooIl8nGimPuTCETCslvc3uAU3aCpFFKJLJLGEOiQEzQqS4uwTJQ
4KzoHxI0hApMoFDH0vAxgcaM5gp3Mhtm54iFSOxj9pHiwz4aSDVX9LtvZH8g+4CGgAT2B/i9zd4m
G9hZbnPgtUD9QENALwGdA9Kxs/B7C36/Z78naexNUgpUC9QK1A80BHQOSM/eBG5ib/DnKMg5rgVi
7A3gJvY6FOt14GnsNUCvsdcga6/GKqsqBhEUl6pAKlSBNUcFlsyKOHsl9uV4aFFOqGloUUeEPFJD
Jgt5scJyKS5kxWb4pTh7Z0Aulna5y9hpEgVikJPTkPJpIgM1Aa0A6gHSAToD6AyJAN0PtAsoCgSt
DLgJSGangH4NdIaUAbmAmoBE9nIMkomzl2LOmZI7k/2GnSRWsPiL7F9R/po9h/IF9iuUz4O0gzzF
novZJeJOAX8CYUwgTSBLwV/LnhkosEjDbjMbAttJwEuBaoHmAbUCbQPSsSGWF/NKFojkCDklEtCM
kQ9Q/gvZLRLXasnlnAUNUObMOf1aQMD65X4nczm3PwyHnDnvewAQZ86N9wLizHnz7YA4c3atBcSZ
07saEGfOJa2AOHPOawYELM52PlVQJFXO66SyO431gZX6wEp9YKU+omF9/Ee+1PC8/VNswgSw2A5X
8fgJUuQwjRylkQU0sptGfDSynkZup5EZNLKcRoppxEYjdhpx0cgROg1MEaGuA5cdVrmyaOQUjeyl
kRCNOGmkkEYKaESmla44c8RumIyiHsWAm590IK+tgd4njTnAog5o8w7oE4aAvwQ0jEcuUJLzFOWx
di7zBibUKscl0ysC7uvZcQh4HKrhOHkLSAMVdBya0XGI5DhEkAa8FqgV6BjQOaBhIB1o50HGtyFP
A14KVAvUCrQB6ByQDrNzDoiRgJrFfZixUjXT8/gROw6/PPg5mMOVa7KZik3XC9tsNM1O59mH7ayS
ZGZCj2wxi+Y4NR763PjF50aS5E5i97FtJBcq4n5Vbot9mSvF6UMx5xHJPYb+I7FroNXRKuKkhSCn
kRAeTyU2kcspxMZ+DrIiZlsEwdJizonSYZrKQx2SvrS9K31gizOA79uOSP8uxzU0Jv0buPz8kHTa
tlV6vjQugstRZ5yCOCyj6qBtmrT3FKreDh47YtJ6Lg5Jt9lmS5029PApHstDcORKkxY4l0jXQ3x1
tjbJFYI4D0m1tuXSDEVrKg9zSCqDLBQrcAJkdrwNE823Y4Q3VcZph2uifrt+sX6e/hp9hX6i3qGX
9Ln6HH2GaBFNYqpoEJNFUdSJGpGJRMzgr5yK+TPoDJ0Jt6PScK5BbGKcM+XxOqMiIzeSaLrQwBoW
zqQN0WPtpKFNjn62MD9Ok+cviWrzZ9KopYE0NM+MTituiOuHF0Qrixui+qbvL95P6X0t4BplW+KU
NC+O02HutCknapnFNyel5k0/zOFy3KYftrSQrMy1tVm1lhpz1XV1V2ArVD7qxXLWZTg3ur1h4eLo
ntyWaAUHw7ktDdEHF8pLFw/Sv9Dz9XWD9BMuWhYPCjX0L/ULuLtQU9fS0hCni1CPyPQT0IMW8wnq
iXBh5npEFu2K3g5FrxDCg14BF6CXlEQKUa8wKQn1NJTr7Q8V1NftLyhAHatMQqgTssqjdU4Vgk5h
IepkRsgp1DmVGeE60RpUsdlAxW5DFZpNbKhio9mosuiSSqmqsnVEZSumJNBLOjZFx3g2oWM8W9fy
jb1Lr/rnm1lcTAeqW9qX1vvy61fk1/uAVkTvWduRFY20yfL+9hbuIUcF54q29g4uPb5oS76vLtqe
Xyfvr156Be+l3Ls6v24/WVrfvHj/UpevLlbtqq7P99S1DMxumlJ5WVpbR9Ka0nSFyJp4ZFN4WrMr
r+Bdyb1n87QqeVqVPK3ZrtmYFsE23rR4v0hmtsxaqsgBlpIM7XVFjqNlZqappwYbb7Uja33OYRit
PE5SiluihvyZUSMQ95rknuTmXnBOca9UcE5TvbLWVztyDtPHVS8TOJvzZ5LicG+ol2TV++uU/xD8
gVO4lxtc4cWhq/2BX33U5akLhQlpiE5Y2BCtnb9k8X69HlxX8CJFpyfcUlLq48PHFMcScJzOHQVh
RJG7zeBuSUmq4jfrv1eVOFUkwqciuew0TEItQtTe0MygK2heAmVdumTxYRhL8ctDqAUKGKLFNJSI
Q8124qsIxYSXOUHhXhWptgirUgkJQUIJk4z8cWMVj1gsDBGSvwNKMpnLCmVuZHN0cmVhbQplbmRv
YmoKCjU4IDAgb2JqCjI0MzM5CmVuZG9iagoKNTkgMCBvYmoKPDwvVHlwZS9Gb250RGVzY3JpcHRv
ci9Gb250TmFtZS9CQUFBQUErQXJpYWxNVAovRmxhZ3MgNAovRm9udEJCb3hbLTY2NCAtMzI0IDIw
MDAgMTAwNl0vSXRhbGljQW5nbGUgMAovQXNjZW50IDkwNQovRGVzY2VudCAtMjExCi9DYXBIZWln
aHQgMTAwNQovU3RlbVYgODAKL0ZvbnRGaWxlMiA1NyAwIFIKPj4KZW5kb2JqCgo2MCAwIG9iago8
PC9MZW5ndGggNDg2L0ZpbHRlci9GbGF0ZURlY29kZT4+CnN0cmVhbQp4nF2Ty47aQBBF9/6KXk4W
I7ur/ZiREBIDg8QiD4XJBxi7IZaCbTVmwd+nb91OImWBddquKp8qXPn2sDuMw5J/C1N39Is5D2Mf
/G26h86bk78MY2bF9EO3pJNeu2s7Z3nMPT5ui78exvO0WmX59/jstoSHedr008l/yvKvofdhGC/m
6cf2GM/H+zz/8lc/LqbI1mvT+3Os87mdv7RXn2vW86GPj4fl8RxT/gV8PGZvRM+WKt3U+9vcdj60
48Vnq6JYm9V+v8782P/3rE4pp3P3sw0x1MbQoiirdWRRrt/BjuzAJdmCK+WmANdkjWnIWueF8Vvw
K++X4A3va8wbWe9vlUVr7uijue+M2YH35NfItmDMHkz/RsD0LzWG/hVq2uT/AqZ/rbn0r9/A9C/x
Lkv/RuvQv6zB9Hdak/4OvVj6l1o/+WNWlv6VxtC/RL+S/DE3Sf4NOM0f7xL6N8rJHz0K/d0GnPw1
l/4OfQn9K61Pf8E8hf6VOtBf8F9L8lemv6AXob9gDkL/Cg6O/g1iHPylsKjvhIwZOvo7zNbRX+Dp
6C8aQ/9Sa9K/0pr0d5iho79DLy7NX+PT/NGLS/5an/6xND7+9JVjDbCnf9bLdPcQ4mrpMutOYZuG
0f/d93makaW/3xqi+hkKZW5kc3RyZWFtCmVuZG9iagoKNjEgMCBvYmoKPDwvVHlwZS9Gb250L1N1
YnR5cGUvVHJ1ZVR5cGUvQmFzZUZvbnQvQkFBQUFBK0FyaWFsTVQKL0ZpcnN0Q2hhciAwCi9MYXN0
Q2hhciA2MQovV2lkdGhzWzc1MCA2NjYgNTU2IDUwMCA1NTYgNTU2IDUwMCA1NTYgMjIyIDI3NyA1
NTYgNTU2IDI3NyA1NTYgODMzIDIyMgo3NzcgMzMzIDI3NyA2NjYgNTU2IDU1NiA1MDAgODMzIDUw
MCA2MTAgNTU2IDU1NiA3MjIgNjY2IDcyMiA3MjIKNzIyIDcyMiAyNzcgNTAwIDU1NiAyNzcgNTU2
IDU1NiA2NjYgMjc3IDYxMCAyNzcgNzIyIDMzMyAzMzMgNzIyCjUwMCAzMzMgMzMzIDI3NyAxOTAg
MzMzIDY2NiA2NjYgNTU2IDU1NiA1NTYgNTU2IDc3NyA1NTYgXQovRm9udERlc2NyaXB0b3IgNTkg
MCBSCi9Ub1VuaWNvZGUgNjAgMCBSCj4+CmVuZG9iagoKNjIgMCBvYmoKPDwvRjEgNjEgMCBSL0Yy
IDUxIDAgUi9GMyA1NiAwIFIKPj4KZW5kb2JqCgo2MyAwIG9iago8PC9Gb250IDYyIDAgUgovUHJv
Y1NldFsvUERGL1RleHRdCj4+CmVuZG9iagoKMSAwIG9iago8PC9UeXBlL1BhZ2UvUGFyZW50IDQ2
IDAgUi9SZXNvdXJjZXMgNjMgMCBSL01lZGlhQm94WzAgMCA1OTUgODQyXS9Hcm91cDw8L1MvVHJh
bnNwYXJlbmN5L0NTL0RldmljZVJHQi9JIHRydWU+Pi9Db250ZW50cyAyIDAgUj4+CmVuZG9iagoK
NCAwIG9iago8PC9UeXBlL1BhZ2UvUGFyZW50IDQ2IDAgUi9SZXNvdXJjZXMgNjMgMCBSL01lZGlh
Qm94WzAgMCA1OTUgODQyXS9Hcm91cDw8L1MvVHJhbnNwYXJlbmN5L0NTL0RldmljZVJHQi9JIHRy
dWU+Pi9Db250ZW50cyA1IDAgUj4+CmVuZG9iagoKNyAwIG9iago8PC9UeXBlL1BhZ2UvUGFyZW50
IDQ2IDAgUi9SZXNvdXJjZXMgNjMgMCBSL01lZGlhQm94WzAgMCA1OTUgODQyXS9Hcm91cDw8L1Mv
VHJhbnNwYXJlbmN5L0NTL0RldmljZVJHQi9JIHRydWU+Pi9Db250ZW50cyA4IDAgUj4+CmVuZG9i
agoKMTAgMCBvYmoKPDwvVHlwZS9QYWdlL1BhcmVudCA0NiAwIFIvUmVzb3VyY2VzIDYzIDAgUi9N
ZWRpYUJveFswIDAgNTk1IDg0Ml0vR3JvdXA8PC9TL1RyYW5zcGFyZW5jeS9DUy9EZXZpY2VSR0Iv
SSB0cnVlPj4vQ29udGVudHMgMTEgMCBSPj4KZW5kb2JqCgoxMyAwIG9iago8PC9UeXBlL1BhZ2Uv
UGFyZW50IDQ2IDAgUi9SZXNvdXJjZXMgNjMgMCBSL01lZGlhQm94WzAgMCA1OTUgODQyXS9Hcm91
cDw8L1MvVHJhbnNwYXJlbmN5L0NTL0RldmljZVJHQi9JIHRydWU+Pi9Db250ZW50cyAxNCAwIFI+
PgplbmRvYmoKCjE2IDAgb2JqCjw8L1R5cGUvUGFnZS9QYXJlbnQgNDYgMCBSL1Jlc291cmNlcyA2
MyAwIFIvTWVkaWFCb3hbMCAwIDU5NSA4NDJdL0dyb3VwPDwvUy9UcmFuc3BhcmVuY3kvQ1MvRGV2
aWNlUkdCL0kgdHJ1ZT4+L0NvbnRlbnRzIDE3IDAgUj4+CmVuZG9iagoKMTkgMCBvYmoKPDwvVHlw
ZS9QYWdlL1BhcmVudCA0NiAwIFIvUmVzb3VyY2VzIDYzIDAgUi9NZWRpYUJveFswIDAgNTk1IDg0
Ml0vR3JvdXA8PC9TL1RyYW5zcGFyZW5jeS9DUy9EZXZpY2VSR0IvSSB0cnVlPj4vQ29udGVudHMg
MjAgMCBSPj4KZW5kb2JqCgoyMiAwIG9iago8PC9UeXBlL1BhZ2UvUGFyZW50IDQ2IDAgUi9SZXNv
dXJjZXMgNjMgMCBSL01lZGlhQm94WzAgMCA1OTUgODQyXS9Hcm91cDw8L1MvVHJhbnNwYXJlbmN5
L0NTL0RldmljZVJHQi9JIHRydWU+Pi9Db250ZW50cyAyMyAwIFI+PgplbmRvYmoKCjI1IDAgb2Jq
Cjw8L1R5cGUvUGFnZS9QYXJlbnQgNDYgMCBSL1Jlc291cmNlcyA2MyAwIFIvTWVkaWFCb3hbMCAw
IDU5NSA4NDJdL0dyb3VwPDwvUy9UcmFuc3BhcmVuY3kvQ1MvRGV2aWNlUkdCL0kgdHJ1ZT4+L0Nv
bnRlbnRzIDI2IDAgUj4+CmVuZG9iagoKMjggMCBvYmoKPDwvVHlwZS9QYWdlL1BhcmVudCA0NiAw
IFIvUmVzb3VyY2VzIDYzIDAgUi9NZWRpYUJveFswIDAgNTk1IDg0Ml0vR3JvdXA8PC9TL1RyYW5z
cGFyZW5jeS9DUy9EZXZpY2VSR0IvSSB0cnVlPj4vQ29udGVudHMgMjkgMCBSPj4KZW5kb2JqCgoz
MSAwIG9iago8PC9UeXBlL1BhZ2UvUGFyZW50IDQ2IDAgUi9SZXNvdXJjZXMgNjMgMCBSL01lZGlh
Qm94WzAgMCA1OTUgODQyXS9Hcm91cDw8L1MvVHJhbnNwYXJlbmN5L0NTL0RldmljZVJHQi9JIHRy
dWU+Pi9Db250ZW50cyAzMiAwIFI+PgplbmRvYmoKCjM0IDAgb2JqCjw8L1R5cGUvUGFnZS9QYXJl
bnQgNDYgMCBSL1Jlc291cmNlcyA2MyAwIFIvTWVkaWFCb3hbMCAwIDU5NSA4NDJdL0dyb3VwPDwv
Uy9UcmFuc3BhcmVuY3kvQ1MvRGV2aWNlUkdCL0kgdHJ1ZT4+L0NvbnRlbnRzIDM1IDAgUj4+CmVu
ZG9iagoKMzcgMCBvYmoKPDwvVHlwZS9QYWdlL1BhcmVudCA0NiAwIFIvUmVzb3VyY2VzIDYzIDAg
Ui9NZWRpYUJveFswIDAgNTk1IDg0Ml0vR3JvdXA8PC9TL1RyYW5zcGFyZW5jeS9DUy9EZXZpY2VS
R0IvSSB0cnVlPj4vQ29udGVudHMgMzggMCBSPj4KZW5kb2JqCgo0MCAwIG9iago8PC9UeXBlL1Bh
Z2UvUGFyZW50IDQ2IDAgUi9SZXNvdXJjZXMgNjMgMCBSL01lZGlhQm94WzAgMCA1OTUgODQyXS9H
cm91cDw8L1MvVHJhbnNwYXJlbmN5L0NTL0RldmljZVJHQi9JIHRydWU+Pi9Db250ZW50cyA0MSAw
IFI+PgplbmRvYmoKCjQzIDAgb2JqCjw8L1R5cGUvUGFnZS9QYXJlbnQgNDYgMCBSL1Jlc291cmNl
cyA2MyAwIFIvTWVkaWFCb3hbMCAwIDU5NSA4NDJdL0dyb3VwPDwvUy9UcmFuc3BhcmVuY3kvQ1Mv
RGV2aWNlUkdCL0kgdHJ1ZT4+L0NvbnRlbnRzIDQ0IDAgUj4+CmVuZG9iagoKNjQgMCBvYmoKPDwv
Q291bnQgMTUvRmlyc3QgNjUgMCBSL0xhc3QgNzkgMCBSCj4+CmVuZG9iagoKNjUgMCBvYmoKPDwv
Q291bnQgMC9UaXRsZTxGRUZGMDA1MzAwNkMwMDY5MDA2NDAwNjUwMDIwMDAzMT4KL0Rlc3RbMSAw
IFIvWFlaIDAgODQyIDBdL1BhcmVudCA2NCAwIFIvTmV4dCA2NiAwIFI+PgplbmRvYmoKCjY2IDAg
b2JqCjw8L0NvdW50IDAvVGl0bGU8RkVGRjAwNTMwMDZDMDA2OTAwNjQwMDY1MDAyMDAwMzI+Ci9E
ZXN0WzQgMCBSL1hZWiAwIDg0MiAwXS9QYXJlbnQgNjQgMCBSL1ByZXYgNjUgMCBSL05leHQgNjcg
MCBSPj4KZW5kb2JqCgo2NyAwIG9iago8PC9Db3VudCAwL1RpdGxlPEZFRkYwMDUzMDA2QzAwNjkw
MDY0MDA2NTAwMjAwMDMzPgovRGVzdFs3IDAgUi9YWVogMCA4NDIgMF0vUGFyZW50IDY0IDAgUi9Q
cmV2IDY2IDAgUi9OZXh0IDY4IDAgUj4+CmVuZG9iagoKNjggMCBvYmoKPDwvQ291bnQgMC9UaXRs
ZTxGRUZGMDA1MzAwNkMwMDY5MDA2NDAwNjUwMDIwMDAzND4KL0Rlc3RbMTAgMCBSL1hZWiAwIDg0
MiAwXS9QYXJlbnQgNjQgMCBSL1ByZXYgNjcgMCBSL05leHQgNjkgMCBSPj4KZW5kb2JqCgo2OSAw
IG9iago8PC9Db3VudCAwL1RpdGxlPEZFRkYwMDUzMDA2QzAwNjkwMDY0MDA2NTAwMjAwMDM1Pgov
RGVzdFsxMyAwIFIvWFlaIDAgODQyIDBdL1BhcmVudCA2NCAwIFIvUHJldiA2OCAwIFIvTmV4dCA3
MCAwIFI+PgplbmRvYmoKCjcwIDAgb2JqCjw8L0NvdW50IDAvVGl0bGU8RkVGRjAwNTMwMDZDMDA2
OTAwNjQwMDY1MDAyMDAwMzY+Ci9EZXN0WzE2IDAgUi9YWVogMCA4NDIgMF0vUGFyZW50IDY0IDAg
Ui9QcmV2IDY5IDAgUi9OZXh0IDcxIDAgUj4+CmVuZG9iagoKNzEgMCBvYmoKPDwvQ291bnQgMC9U
aXRsZTxGRUZGMDA1MzAwNkMwMDY5MDA2NDAwNjUwMDIwMDAzNz4KL0Rlc3RbMTkgMCBSL1hZWiAw
IDg0MiAwXS9QYXJlbnQgNjQgMCBSL1ByZXYgNzAgMCBSL05leHQgNzIgMCBSPj4KZW5kb2JqCgo3
MiAwIG9iago8PC9Db3VudCAwL1RpdGxlPEZFRkYwMDUzMDA2QzAwNjkwMDY0MDA2NTAwMjAwMDM4
PgovRGVzdFsyMiAwIFIvWFlaIDAgODQyIDBdL1BhcmVudCA2NCAwIFIvUHJldiA3MSAwIFIvTmV4
dCA3MyAwIFI+PgplbmRvYmoKCjczIDAgb2JqCjw8L0NvdW50IDAvVGl0bGU8RkVGRjAwNTMwMDZD
MDA2OTAwNjQwMDY1MDAyMDAwMzk+Ci9EZXN0WzI1IDAgUi9YWVogMCA4NDIgMF0vUGFyZW50IDY0
IDAgUi9QcmV2IDcyIDAgUi9OZXh0IDc0IDAgUj4+CmVuZG9iagoKNzQgMCBvYmoKPDwvQ291bnQg
MC9UaXRsZTxGRUZGMDA1MzAwNkMwMDY5MDA2NDAwNjUwMDIwMDAzMTAwMzA+Ci9EZXN0WzI4IDAg
Ui9YWVogMCA4NDIgMF0vUGFyZW50IDY0IDAgUi9QcmV2IDczIDAgUi9OZXh0IDc1IDAgUj4+CmVu
ZG9iagoKNzUgMCBvYmoKPDwvQ291bnQgMC9UaXRsZTxGRUZGMDA1MzAwNkMwMDY5MDA2NDAwNjUw
MDIwMDAzMTAwMzE+Ci9EZXN0WzMxIDAgUi9YWVogMCA4NDIgMF0vUGFyZW50IDY0IDAgUi9QcmV2
IDc0IDAgUi9OZXh0IDc2IDAgUj4+CmVuZG9iagoKNzYgMCBvYmoKPDwvQ291bnQgMC9UaXRsZTxG
RUZGMDA1MzAwNkMwMDY5MDA2NDAwNjUwMDIwMDAzMTAwMzI+Ci9EZXN0WzM0IDAgUi9YWVogMCA4
NDIgMF0vUGFyZW50IDY0IDAgUi9QcmV2IDc1IDAgUi9OZXh0IDc3IDAgUj4+CmVuZG9iagoKNzcg
MCBvYmoKPDwvQ291bnQgMC9UaXRsZTxGRUZGMDA1MzAwNkMwMDY5MDA2NDAwNjUwMDIwMDAzMTAw
MzM+Ci9EZXN0WzM3IDAgUi9YWVogMCA4NDIgMF0vUGFyZW50IDY0IDAgUi9QcmV2IDc2IDAgUi9O
ZXh0IDc4IDAgUj4+CmVuZG9iagoKNzggMCBvYmoKPDwvQ291bnQgMC9UaXRsZTxGRUZGMDA1MzAw
NkMwMDY5MDA2NDAwNjUwMDIwMDAzMTAwMzQ+Ci9EZXN0WzQwIDAgUi9YWVogMCA4NDIgMF0vUGFy
ZW50IDY0IDAgUi9QcmV2IDc3IDAgUi9OZXh0IDc5IDAgUj4+CmVuZG9iagoKNzkgMCBvYmoKPDwv
Q291bnQgMC9UaXRsZTxGRUZGMDA1MzAwNkMwMDY5MDA2NDAwNjUwMDIwMDAzMTAwMzU+Ci9EZXN0
WzQzIDAgUi9YWVogMCA4NDIgMF0vUGFyZW50IDY0IDAgUi9QcmV2IDc4IDAgUj4+CmVuZG9iagoK
NDYgMCBvYmoKPDwvVHlwZS9QYWdlcwovUmVzb3VyY2VzIDYzIDAgUgovTWVkaWFCb3hbIDAgMCA1
OTUgODQyIF0KL0tpZHNbIDEgMCBSIDQgMCBSIDcgMCBSIDEwIDAgUiAxMyAwIFIgMTYgMCBSIDE5
IDAgUiAyMiAwIFIgMjUgMCBSIDI4IDAgUiAzMSAwIFIgMzQgMCBSIDM3IDAgUiA0MCAwIFIgNDMg
MCBSIF0KL0NvdW50IDE1Pj4KZW5kb2JqCgo4MCAwIG9iago8PC9UeXBlL0NhdGFsb2cvUGFnZXMg
NDYgMCBSCi9PcGVuQWN0aW9uWzEgMCBSIC9YWVogbnVsbCBudWxsIDBdCi9PdXRsaW5lcyA2NCAw
IFIKPj4KZW5kb2JqCgo4MSAwIG9iago8PC9DcmVhdG9yPEZFRkYwMDQ0MDA3MjAwNjEwMDc3Pgov
UHJvZHVjZXI8RkVGRjAwNEMwMDY5MDA2MjAwNzIwMDY1MDA0RjAwNjYwMDY2MDA2OTAwNjMwMDY1
MDAyMDAwMzMwMDJFMDAzNj4KL0NyZWF0aW9uRGF0ZShEOjIwMTIxMTA1MTUyMTQyWicpPj4KZW5k
b2JqCgp4cmVmCjAgODIKMDAwMDAwMDAwMCA2NTUzNSBmIAowMDAwMTA5Njk1IDAwMDAwIG4gCjAw
MDAwMDAwMTkgMDAwMDAgbiAKMDAwMDAwMjQ5NyAwMDAwMCBuIAowMDAwMTA5ODM5IDAwMDAwIG4g
CjAwMDAwMDI1MTggMDAwMDAgbiAKMDAwMDAwNDM1NyAwMDAwMCBuIAowMDAwMTA5OTgzIDAwMDAw
IG4gCjAwMDAwMDQzNzggMDAwMDAgbiAKMDAwMDAwODUwNSAwMDAwMCBuIAowMDAwMTEwMTI3IDAw
MDAwIG4gCjAwMDAwMDg1MjYgMDAwMDAgbiAKMDAwMDAxMDg1OCAwMDAwMCBuIAowMDAwMTEwMjcz
IDAwMDAwIG4gCjAwMDAwMTA4ODAgMDAwMDAgbiAKMDAwMDAxMzA2MSAwMDAwMCBuIAowMDAwMTEw
NDE5IDAwMDAwIG4gCjAwMDAwMTMwODMgMDAwMDAgbiAKMDAwMDAxNTE3NSAwMDAwMCBuIAowMDAw
MTEwNTY1IDAwMDAwIG4gCjAwMDAwMTUxOTcgMDAwMDAgbiAKMDAwMDAyMTQzMyAwMDAwMCBuIAow
MDAwMTEwNzExIDAwMDAwIG4gCjAwMDAwMjE0NTUgMDAwMDAgbiAKMDAwMDAyNzcwOSAwMDAwMCBu
IAowMDAwMTEwODU3IDAwMDAwIG4gCjAwMDAwMjc3MzEgMDAwMDAgbiAKMDAwMDAzMzg1NCAwMDAw
MCBuIAowMDAwMTExMDAzIDAwMDAwIG4gCjAwMDAwMzM4NzYgMDAwMDAgbiAKMDAwMDA0MDAyMyAw
MDAwMCBuIAowMDAwMTExMTQ5IDAwMDAwIG4gCjAwMDAwNDAwNDUgMDAwMDAgbiAKMDAwMDA0NTU2
OSAwMDAwMCBuIAowMDAwMTExMjk1IDAwMDAwIG4gCjAwMDAwNDU1OTEgMDAwMDAgbiAKMDAwMDA1
MTE0MCAwMDAwMCBuIAowMDAwMTExNDQxIDAwMDAwIG4gCjAwMDAwNTExNjIgMDAwMDAgbiAKMDAw
MDA1NzI3NCAwMDAwMCBuIAowMDAwMTExNTg3IDAwMDAwIG4gCjAwMDAwNTcyOTYgMDAwMDAgbiAK
MDAwMDA2MzQxMSAwMDAwMCBuIAowMDAwMTExNzMzIDAwMDAwIG4gCjAwMDAwNjM0MzMgMDAwMDAg
biAKMDAwMDA2ODY2OSAwMDAwMCBuIAowMDAwMTEzOTQzIDAwMDAwIG4gCjAwMDAwNjg2OTEgMDAw
MDAgbiAKMDAwMDA3MDQzNCAwMDAwMCBuIAowMDAwMDcwNDU2IDAwMDAwIG4gCjAwMDAwNzA2NDgg
MDAwMDAgbiAKMDAwMDA3MDk0MCAwMDAwMCBuIAowMDAwMDcxMTAxIDAwMDAwIG4gCjAwMDAwODMx
NDIgMDAwMDAgbiAKMDAwMDA4MzE2NSAwMDAwMCBuIAowMDAwMDgzMzYxIDAwMDAwIG4gCjAwMDAw
ODM3NDggMDAwMDAgbiAKMDAwMDA4Mzk5MiAwMDAwMCBuIAowMDAwMTA4NDE4IDAwMDAwIG4gCjAw
MDAxMDg0NDEgMDAwMDAgbiAKMDAwMDEwODYzMiAwMDAwMCBuIAowMDAwMTA5MTg4IDAwMDAwIG4g
CjAwMDAxMDk1ODcgMDAwMDAgbiAKMDAwMDEwOTY0MCAwMDAwMCBuIAowMDAwMTExODc5IDAwMDAw
IG4gCjAwMDAxMTE5MzYgMDAwMDAgbiAKMDAwMDExMjA1NyAwMDAwMCBuIAowMDAwMTEyMTkwIDAw
MDAwIG4gCjAwMDAxMTIzMjMgMDAwMDAgbiAKMDAwMDExMjQ1NyAwMDAwMCBuIAowMDAwMTEyNTkx
IDAwMDAwIG4gCjAwMDAxMTI3MjUgMDAwMDAgbiAKMDAwMDExMjg1OSAwMDAwMCBuIAowMDAwMTEy
OTkzIDAwMDAwIG4gCjAwMDAxMTMxMjcgMDAwMDAgbiAKMDAwMDExMzI2NSAwMDAwMCBuIAowMDAw
MTEzNDAzIDAwMDAwIG4gCjAwMDAxMTM1NDEgMDAwMDAgbiAKMDAwMDExMzY3OSAwMDAwMCBuIAow
MDAwMTEzODE3IDAwMDAwIG4gCjAwMDAxMTQxNDAgMDAwMDAgbiAKMDAwMDExNDI0MiAwMDAwMCBu
IAp0cmFpbGVyCjw8L1NpemUgODIvUm9vdCA4MCAwIFIKL0luZm8gODEgMCBSCi9JRCBbIDw1RjVC
MkE2MjEyMUUwMkRGMzNFNzE5RkZFNDJGQzFDRD4KPDVGNUIyQTYyMTIxRTAyREYzM0U3MTlGRkU0
MkZDMUNEPiBdCi9Eb2NDaGVja3N1bSAvMzU0ODU3NUZDNzU3MzQ3QzQzRjU2OEU1NDVFMTgwMkMK
Pj4Kc3RhcnR4cmVmCjExNDQwNAolJUVPRgo=
--047d7b603e96af1aeb04cdc18261--

From pal@cs.stanford.edu  Mon Nov  5 10:17:12 2012
Return-Path: 
X-Original-To: roll@ietfa.amsl.com
Delivered-To: roll@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 340A521F893C for ; Mon,  5 Nov 2012 10:17:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.577
X-Spam-Level: 
X-Spam-Status: No, score=-6.577 tagged_above=-999 required=5 tests=[AWL=0.022,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DzxLAeOjSG0U for ; Mon,  5 Nov 2012 10:17:11 -0800 (PST)
Received: from cs-smtp-1.Stanford.EDU (cs-smtp-1.Stanford.EDU [171.64.64.25]) by ietfa.amsl.com (Postfix) with ESMTP id B3F0921F893D for ; Mon,  5 Nov 2012 10:17:11 -0800 (PST)
Received: from [12.199.7.82] (helo=[172.16.1.87]) by cs-smtp-1.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.77) (envelope-from ) id 1TVREU-0004S4-58; Mon, 05 Nov 2012 10:17:10 -0800
Mime-Version: 1.0 (Apple Message framework v1283)
Content-Type: text/plain; charset=us-ascii
From: Philip Levis 
In-Reply-To: 
Date: Mon, 5 Nov 2012 10:10:20 -0800
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References:    <03D5F543-40BD-427C-9C53-EF5172DC0103@cs.stanford.edu> 
To: Pascal Thubert (pthubert) 
X-Mailer: Apple Mail (2.1283)
X-Scan-Signature: 67f4a389e065da33eb5969ecb4726704
Cc: "roll@ietf.org" 
Subject: Re: [Roll] using the flow label instead of hop by hop
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Routing Over Low power and Lossy networks 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 05 Nov 2012 18:17:12 -0000

On Nov 5, 2012, at 7:33 AM, Pascal Thubert (pthubert) wrote:
> [Pascal] I'm modifying / adding the following text in the draft to =
amend 6437:
>=20
>   In a LLN, each transmitted bit represents energy and every saving
>   counts dearly.  Considering that the value for which the Flow Label
>   is used in the IPv6 Flow Label Specification [RFC6437] is to serve
>   load balancing in the core, it is unlikely that LLN devices will
>   consume energy to generate and then transmit a Flow Label to serve
>   interests in some other place.  On the other hand, it makes sense to
>   recommend the computation of a stateless Flow Label at the root of
>   the LLN towards the Internet.
>=20
>   Reciprocally , [RFC6437] requires that once set, a non-zero flow
>   label value is left unchanged.  The value for that setting is
>   consumed once the packet has traversed the core and reaches the LLN.
>   Then again, there is little value but a high cost for the LLN in
>   spending 20 bits to transport a Flow Label from the Internet over =
the
>   constrained network to the destination node.  It results that the
>   MUST in [RFC6437] should be alleviated for packets coming from the
>   outside on the LLN, and that it should be acceptable that the
>   compression over the LLN erases the original flow label.  It should
>   also be acceptable that the Flow Label field is reused in the LLN as
>   proposed in this draft.
>=20
> What do you think?

Disagree. No matter how many words are put around it, it's still =
violating RFC6537. This is not a question of hypothetical value or cost. =
I'm still waiting for your energy analysis on those 20 bits. "Low =
energy" can be used as a hand-wavy argument to do a lot of things which =
are bad in retrospect.=20

Phil=

From nduong@purdue.edu  Wed Nov  7 11:55:20 2012
Return-Path: 
X-Original-To: roll@ietfa.amsl.com
Delivered-To: roll@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F34C21F8850 for ; Wed,  7 Nov 2012 11:55:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level: 
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yjQnbOi9B9jx for ; Wed,  7 Nov 2012 11:55:19 -0800 (PST)
Received: from mailhub128.itcs.purdue.edu (mailhub128.itcs.purdue.edu [128.210.5.128]) by ietfa.amsl.com (Postfix) with ESMTP id A4D6F21F87F6 for ; Wed,  7 Nov 2012 11:55:19 -0800 (PST)
Received: from mailhub022.itcs.purdue.edu (mailhub022.itcs.purdue.edu [128.210.5.22]) by mailhub128.itcs.purdue.edu (8.14.4/8.14.4/mta-nopmx.smtp.purdue.edu) with ESMTP id qA7JtI0l009756 for ; Wed, 7 Nov 2012 14:55:18 -0500
Date: Wed, 7 Nov 2012 14:55:18 -0500 (EST)
From: Duong Ngoc Nguyen 
To: roll@ietf.org
Message-ID: <157212510.61589.1352318118568.JavaMail.root@mailhub022.itcs.purdue.edu>
In-Reply-To: 
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
X-Originating-IP: [128.210.5.219]
X-Mailer: Zimbra 6.0.10_GA_2692 (ZimbraWebClient - SAF3 (Linux)/6.0.10_GA_2692)
X-PMX-Version: 5.5.9.388399
X-PerlMx-Virus-Scanned: Yes
Subject: [Roll] Some confusions in RFC 6719 (MRHOF)
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Routing Over Low power and Lossy networks 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 07 Nov 2012 19:55:20 -0000

As I work with MRHOF, I find some statements are not consistent that I cannot resolve by myself. I'm very grateful if someone can help me overcome this confusion.

1. Which path cost is carried in Metric Container?

Section 3.2.2 states:

   Once the preferred parent is selected, the node sets its
   cur_min_path_cost variable to the path cost corresponding to the
   preferred parent.  The value of the cur_min_path_cost is carried in
   the Metric Container corresponding to the selected metric when DIO
   messages are sent.

==> it suggests Metric Container carries the cost through the best (i.e. preferred) parent.

While section 3.4 states:

   Once the preferred parent is selected, the node sets its
   cur_min_path_cost variable to the path cost corresponding to its
   preferred parent.  It then calculates the metric it will advertise in
   its metric container.  This value is the path cost of the member of
   the parent set with the highest path cost.  Thus, while
   cur_min_path_cost is the cost through the preferred parent, a node
   advertises the highest cost path from the node to the root through a
   member of the parent set.  The value of the highest cost path is
   carried in the metric container corresponding to the selected metric
   when DIO messages are sent.

==> it suggests Metric Container carries the cost through the worst parent.

2. Which value is written to Rank field of DIO messsage's base object in case ETX is used?

When ETX is the metric, node must not include Metric container, thus the rank field in DIO's base object is the only information to advertise to neighbors.

Section 3.4 states:

   If ETX is the selected metric, a node MUST NOT advertise it in a
   metric container.  Instead, a node MUST advertise an approximation of
   its ETX in its advertised Rank value, following the rules described
   in Section 3.3...

==> The phrase "in its advertised Rank value, following the rules described in Section 3.3." means we would write the value of node rank (computed by rules in section 3.3) into the rank field of DIO message.

On the other hand, section 3.5 states:

   ... Once parent selection and rank computation is performed
   using the ETX metric, the node advertises the Rank and MUST NOT
   include a metric container in its DIO messages.  While assigning Rank
   in this case, use the representation of ETX described in [RFC6551],
   i.e., assign Rank equal to ETX * 128.

==> The phrase "assign Rank equal to ETX * 128" suggests that we should write value of ETX of path cost to the rank field of DIO message.

3. A possible typo.
Section 3.5 states:

   In the absence of a Metric Container, MRHOF uses ETX as its metric.
   It locally computes the ETX of links to its neighbors and adds this
   value to their advertised Rank to compute the associated Rank of
   routes...

==> Adding ETX of link and value of advertised rank is to compute cost of a route, not rank of a route. Rank of a route is computed by adding MinHopRankIncrease (instead of link's ETX) with advertised rank (as in section 3.3)

Sincerely thanks,
Duong Nguyen


From dat@exegin.com  Thu Nov  8 11:10:46 2012
Return-Path: 
X-Original-To: roll@ietfa.amsl.com
Delivered-To: roll@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2109821F841C for ; Thu,  8 Nov 2012 11:10:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.155
X-Spam-Level: 
X-Spam-Status: No, score=-3.155 tagged_above=-999 required=5 tests=[AWL=0.443,  BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ROVA+y8W7qmQ for ; Thu,  8 Nov 2012 11:10:44 -0800 (PST)
Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 75E1521F8417 for ; Thu,  8 Nov 2012 11:10:44 -0800 (PST)
Received: by mail-pb0-f44.google.com with SMTP id ro8so2398217pbb.31 for ; Thu, 08 Nov 2012 11:10:44 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:x-gm-message-state; bh=Zsvv3xC+IuxhxFomMy367kf1Yic6TJinTHuhaRqNNpY=; b=YiUzvtHiUUUCLo4/4QlXXnG8sAaSsq9smx0jjSMVc57iUVJ4P255EqHQ4Ce81UrSiS eIg39nW6KDSVVkpnv24z0y/T15XJ2oSeC8NZrcyOnehWKnQfH1mAwe/Ls9hMGS2JCx82 TJDHhVr7Hs0yrAOuamNK/KeldSKZF5Oa0hfUBTi8a+mor436Faj7ePhVpLT6Hg0xzlJv SIRc/e5Hlk7BBRzpx2oriEUzFqWEPzPaSmtvlbdFsPrD5IJbrUZUycgUkflrkMSX5hR4 p8khFPpNNk2175zHafHVuJqGrciFsu/N5+J8QBVRRK9oT9reOAKA5jAnsU4JXwIMMUpH w89g==
Received: by 10.68.143.201 with SMTP id sg9mr27271166pbb.32.1352401844088; Thu, 08 Nov 2012 11:10:44 -0800 (PST)
Received: from [172.16.1.52] ([184.71.143.130]) by mx.google.com with ESMTPS id ix9sm16358112pbc.7.2012.11.08.11.10.42 (version=SSLv3 cipher=OTHER); Thu, 08 Nov 2012 11:10:43 -0800 (PST)
Message-ID: <509C03C2.50809@exegin.com>
Date: Thu, 08 Nov 2012 11:10:58 -0800
From: Dario Tedeschi 
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:7.0) Gecko/20110922 Thunderbird/7.0
MIME-Version: 1.0
To: "Jonathan Hui (johui)" 
References: <058.e817419e990e1afb26be9aa25d5cfc21@trac.tools.ietf.org>  <50932647.3050509@exegin.com>  <5094202F.4010805@exegin.com> 
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------070202040307020805020506"
X-Gm-Message-State: ALoCoQk7G2QUpVqw64AqnJovqx1H+KSh5Wrq9GwJkQokwG3EZ3sQwZLrsbbkFgIG/3Q9wY9EJM63
Cc: "" , "" , "" 
Subject: Re: [Roll] [roll] #105: trickle-mcast: how to determine scope of MPL domain
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Routing Over Low power and Lossy networks 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 08 Nov 2012 19:10:46 -0000

This is a multi-part message in MIME format.
--------------070202040307020805020506
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit

Hi Jonathan

On 02/11/2012 10:18 PM, Jonathan Hui (johui) wrote:
>
> Hi Dario,
>
> Thanks for the detailed example - I see our disconnect now.
>
> With your approach (require link-local in the outer header), the IPv6 
> multicast address identifies the application endpoints *and* the MPL 
> domain.  For that reason, your approach really only needs a single 
> identifier to both limit the flooding scope and determine the 
> application endpoints.
It depends on what you mean by MPL domain. In my view,  FF02::MPL 
identifies the MPL domain, while the inner IPv6 destination address 
identifies the application endpoint.


>  I can see how that would work (as you demonstrated) if we make the 
> restriction that the IPv6 multicast addresses used within an MPL 
> domain have the same prefix that identifies the MPL domain itself. 
>  The trouble comes when you want to support the full generality that 
> IPv6 multicast addresses used by application endpoints can be arbitrary.

The "generality", you talk of, is why protocols like MLD exist. MLD 
informs routers of mc addresses other devices are interested in. 
Essentially it provides routing information. How could we support the 
"full generality" of mc addresses without this information (whether 
implied or from something like MLD).  With this in mind, I don't 
understand the need for non-link-local scope in the outer header, 
because the "generality" you seek would be determined by the mc address 
of the original packet (i.e. the mc address of the inner header). All my 
approach is really saying is that only the original/inner mc address 
determines how far a packet will propagate, regardless of routing 
domain. MPL could just be one of many routing domains a mc packet must 
traverse before reaching its furthermost boundary. Or MPL may be the 
only routing domain, where the mc packet only reaches a sub-set of 
devices within the domain (i.e. a multicast group or a set based on 
unicast-prefix-based mc).


>
> For example, how does MPL support an application that subscribes to a 
> well-known non-link-local IPv6 multicast address?  I guess one 
> approach is to say that if the IPv6 multicast address is not a 
> unicast-prefix-based multicast address, then it disseminates across 
> the entire region of connected MPL forwarders.

Granted one could have a situation where all routers hear an mc packet 
that is only intended for a subset of devices, but that does not mean 
all routers need to forward that packet or pass it to a higher layer. 
Again, this would depend on the inner mc address and the routing 
information available to routers. The routers without the appropriate 
routing information would not forward. Similarly, routers without mc 
membership information from an app would not pass the packet to the next 
higher layer.



>
> One minor point with your approach is that the delivery requires 
> processing the MPL Option of the outer header and the inner IPv6 
> header.  That isn't so nice from an architectural perspective, but 
> that is what we did with RFC 6553.

Using non-link-local in the outer header does not mitigate that. The 
forwarder still needs to look at the inner header to determine if the 
inner mc address is one an app is listening on. In fact implementing 
this is a bit messy compared to my approach, because the forwarder has 
to look ahead into the packet before decapsulating. My approach always 
requires decapsulation before making any decision about where the packet 
must go next. It's simpler and more consistent. I've actually had the 
fortune/misfortune of implementing both and I can safely say the 
link-local approach was cleaner.


>
> In my approach (allow non-link-local in the outer header), I tried to 
> separate out the identifiers for the application endpoints and the MPL 
> domain.  That is why I used the outer header's destination address to 
> identify the MPL domain and the inner header's destination address to 
> identify the application endpoints.  With this approach, it actually 
> becomes feasible to address situations where the devices within an MPL 
> domain subscribe to arbitrary IPv6 multicast addresses - not just ones 
> that are based on the unicast prefix.

Firstly, yes I agree the inner destination address should determine the 
application endpoint. What I'm not clear on is why we need an MPL domain 
to cover more than the LLN or why we need to support multiple MPL 
domains in one LLN. Tf the latter case is required to allow for 
different sets of MPL propagation parameters, then I'd imagine that 
should rather be handled by the HbH option.

- Dario

>
> --
> Jonathan Hui
>
> On Nov 2, 2012, at 12:34 PM, Dario Tedeschi  > wrote:
>
>> On 01/11/2012 7:12 PM, Jonathan Hui (johui) wrote:
>>> On Nov 1, 2012, at 6:47 PM, Dario Tedeschi  wrote:
>>>
>>>> I don't understand what benefit is gained by allowing the use of non-link-local in the outer header, if encapsulation is required. Supporting both link-local and higher in the outer header just servers to complicate the forwarder.
>>> The purpose is to limit the extent to which MPL disseminates a packet to something smaller than the entire LLN (item 2).
>>
>> Isn't that what multicast groups and/or unicast-prefix-based 
>> multicasts are for? That is to say, to reach a defined set of devices.
>>
>>
>>>> Is item 2 a requirement that a subset of devices in the LLN participate in MPL forwarding and others don't, or is it that there are two MPL domains, or is it that one subset of devices are listening on multicast address A while others are listening on multicast address B? In any case, I don't see how the use of link-local scope in the *outer* header would not work.
>>> As mentioned above, the purpose is to limit the physical extent of MPL forwarders that disseminate a message.  If we use a link-local destination address in the outer header, how do you propose to limit the region?
>>
>> The destination in the inner header determines if the packet needs to 
>> be forwarded or not, or forwarded on a different interface.
>>
>>
>>>> As for encapsulation, using an MPL multicast address of the from FF02::00XX, in the outer header, would only add three bytes to the packet after 6lowpan compression.
>>> I agree.
>>>
>>> Maybe you could describe a concrete example of how using link-local addresses in the outer header would address Peter's scenario that he posted to the list?
>>
>> Example: Two border routers (BR1 and BR2) each forming a network:
>>
>> --- Network 1 (BR1) ---
>> Unicast prefix: FD01::/64
>> Unicast-prefix-based multicast address prefix: FF35:0040:FD01::/96
>>
>> --- Network 2 (BR2) ---
>> Unicast prefix: FD02::/64
>> Unicast-prefix-based multicast address prefix: FF35:0040:FD02::/96
>>
>>  1. A non-MPL aware node in network 1 wishes to send a multicast to
>>     all nodes in network 1.
>>  2. It sends to multicast address FF35:0040:FD01::1, un-encapsulated.
>>  3. The packet is received by a MPL router in network 2 (N2R1).
>>  4. N2R1 finds no higher layer listening to FF35:0040:FD01::1 and,
>>     therefore, does not pass the packet up.
>>  5. N2R1 finds no matching routing information for FF35:0040:FD01::1
>>     and does not forward the packet. The packet is, therefore,
>>     discarded.
>>  6. The packet is also received by a MPL router in network 1 (N1R1).
>>  7. N1R1 finds a higher layer listening to FF35:0040:FD01::1 and
>>     passes a copy of the packet up. Note: This would depend on
>>     whether or not any higher layers were actually interested in the
>>     mc group. Also, this step is not a prerequisite for the next step
>>     to occur.
>>  8. N1R1 finds matching routing information for FF35:0040:FD01::1,
>>     because it is a member of network FD01::/64
>>  9. N1R1 encapsulates the packet with a MPL HbH option such that the
>>     outer and inner destination addresses appear as:
>>     [FF02::MPL][FF35:0040:FD01::1], respectively.
>> 10. N1R1 transmits the new resulting packet.
>> 11. The packet is received by another MPL router in network 1 (N1R2).
>> 12. Seeing that the destination address is FF02::MPL, N1R2
>>     decapsulates the packet (i.e. the original packet exits the tunnel).
>> 13. N1R2 finds a higher layer listening to FF35:0040:FD01::1 and
>>     passes a copy of the inner packet up. Note: This step is not a
>>     prerequisite for the next step to occur.
>> 14. N1R2 also finds matching routing information for
>>     FF35:0040:FD01::1, because it is a member of network FD01::/64.
>> 15. N1R2 re-encapsulates the packet with the *original* MPL HbH
>>     option such that the outer and inner destination addresses appear
>>     as: [FF02::MPL][FF35:0040:FD01::1], respectively.
>> 16. N1R2 transmits the resulting packet.
>> 17. The packet is received by yet another MPL router in network 2
>>     (N2R2).
>> 18. Seeing that the destination address is FF02::MPL, N2R2
>>     decapsulates the packet (i.e. the original packet exits the tunnel).
>> 19. N2R2 finds no matching routing information or listener for
>>     FF35:0040:FD01::1 and, therefore, discards the packet.
>>
>>
>> Note:
>> I chose a non-MPL aware originator of a multicast packet, because I 
>> wanted to be more thorough. I could have chosen an example where the 
>> originator of the packet *was* a MPL aware device. In such a case, it 
>> would have encapsulated with its own MPL HbH option as if it were 
>> forwarding the packet (i.e. outer and inner destinations would have 
>> been [FF02::MPL][FF35:0040:FD01::1]). One complication of non-MPL 
>> aware devices sending non-link-local multicasts is the problem of 
>> fan-out: If such a device multicasts/broadcasts at the link-layer for 
>> IPv6 multicasts, then many MPL routers may hear the packet and try 
>> forward it with their own seeds. Although this wouldn't cause a real 
>> packet-storm, it would cause something close to it, depending on how 
>> many routers were in earshot of the originator. However, this is a 
>> general problem that has nothing to do with MPL's address scope.
>>
>> Secondly, notice that FF02::MPL can be viewed as a well defined 
>> address for a "tunnel exit point". It just so happens that it 
>> actually identifies multiple physical "exit points".
>>
>> - Dario
>>
>>
>


--------------070202040307020805020506
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: 8bit


  
    
  
  
    Hi Jonathan

    

    On 02/11/2012 10:18 PM, Jonathan Hui (johui) wrote:
    

      
      


      

      
Hi Dario,

      


      

      
Thanks for the detailed example - I see our disconnect now.

      


      

      
With your approach (require link-local in the outer header),
        the IPv6 multicast address identifies the application endpoints
        *and* the MPL domain.  For that reason, your approach really
        only needs a single identifier to both limit the flooding scope
        and determine the application endpoints.

    

    It depends on what you mean by MPL domain. In my view,  FF02::MPL
    identifies the MPL domain, while the inner IPv6 destination address
    identifies the application endpoint.

    

    

    

      
  I can see how that would work (as you demonstrated) if we
        make the restriction that the IPv6 multicast addresses used
        within an MPL domain have the same prefix that identifies the
        MPL domain itself.  The trouble comes when you want to support
        the full generality that IPv6 multicast addresses used by
        application endpoints can be arbitrary.

    

    

    The "generality", you talk of, is why protocols like MLD exist. MLD
    informs routers of mc addresses other devices are interested in.
    Essentially it provides routing information. How could we support
    the "full generality" of mc addresses without this information
    (whether implied or from something like MLD).  With this in mind, I
    don't understand the need for non-link-local scope in the outer
    header, because the "generality" you seek would be determined by the
    mc address of the original packet (i.e. the mc address of the inner
    header). All my approach is really saying is that only the
    original/inner mc address determines how far a packet will
    propagate, regardless of routing domain. MPL could just be one of
    many routing domains a mc packet must traverse before reaching its
    furthermost boundary. Or MPL may be the only routing domain, where
    the mc packet only reaches a sub-set of devices within the domain
    (i.e. a multicast group or a set based on unicast-prefix-based mc).

    

    

    

      


      

      
For example, how does MPL support an application that
        subscribes to a well-known non-link-local IPv6 multicast
        address?  I guess one approach is to say that if the IPv6
        multicast address is not a unicast-prefix-based multicast
        address, then it disseminates across the entire region of
        connected MPL forwarders.

    

    

    Granted one could have a situation where all routers hear an mc
    packet that is only intended for a subset of devices, but that does
    not mean all routers need to forward that packet or pass it to a
    higher layer. Again, this would depend on the inner mc address and
    the routing information available to routers. The routers without
    the appropriate routing information would not forward. Similarly,
    routers without mc membership information from an app would not pass
    the packet to the next higher layer.

    

    

    

    

      


      

      
One minor point with your approach is that the delivery
        requires processing the MPL Option of the outer header and the
        inner IPv6 header.  That isn't so nice from an architectural
        perspective, but that is what we did with RFC 6553.

    

    

    Using non-link-local in the outer header does not mitigate that. The
    forwarder still needs to look at the inner header to determine if
    the inner mc address is one an app is listening on. In fact
    implementing this is a bit messy compared to my approach, because
    the forwarder has to look ahead into the packet before
    decapsulating. My approach always requires decapsulation before
    making any decision about where the packet must go next. It's
    simpler and more consistent. I've actually had the
    fortune/misfortune of implementing both and I can safely say the
    link-local approach was cleaner.

    

    

    

      


      

      
In my approach (allow non-link-local in the outer header), I
        tried to separate out the identifiers for the application
        endpoints and the MPL domain.  That is why I used the outer
        header's destination address to identify the MPL domain and the
        inner header's destination address to identify the application
        endpoints.  With this approach, it actually becomes feasible to
        address situations where the devices within an MPL domain
        subscribe to arbitrary IPv6 multicast addresses - not just ones
        that are based on the unicast prefix.

    

    

    Firstly, yes I agree the inner destination address should determine
    the application endpoint. What I'm not clear on is why we need an
    MPL domain to cover more than the LLN or why we need to support
    multiple MPL domains in one LLN. Tf the latter case is required to
    allow for different sets of MPL propagation parameters, then I'd
    imagine that should rather be handled by the HbH option.

    

    - Dario

    

    

      


      

      
--

      
Jonathan Hui

      

      

        
On Nov 2, 2012, at 12:34 PM, Dario Tedeschi <dat@exegin.com>
          wrote:

        

        

          
On 01/11/2012 7:12 PM,
            Jonathan Hui (johui) wrote:
            

              
On Nov 1, 2012, at 6:47 PM, Dario Tedeschi <dat@exegin.com> wrote:



              

                
I don't understand what benefit is gained by allowing the use of non-link-local in the outer header, if encapsulation is required. Supporting both link-local and higher in the outer header just servers to complicate the forwarder.


              

              
The purpose is to limit the extent to which MPL disseminates a packet to something smaller than the entire LLN (item 2).

            

            

            Isn't that what multicast groups and/or unicast-prefix-based
            multicasts are for? That is to say, to reach a defined set
            of devices.

            

            

            

              

                
Is item 2 a requirement that a subset of devices in the LLN participate in MPL forwarding and others don't, or is it that there are two MPL domains, or is it that one subset of devices are listening on multicast address A while others are listening on multicast address B? In any case, I don't see how the use of link-local scope in the *outer* header would not work.


              

              
As mentioned above, the purpose is to limit the physical extent of MPL forwarders that disseminate a message.  If we use a link-local destination address in the outer header, how do you propose to limit the region?

            

            

            The destination in the inner header determines if the packet
            needs to be forwarded or not, or forwarded on a different
            interface.
            

            

            

            

              

                
As for encapsulation, using an MPL multicast address of the from FF02::00XX, in the outer header, would only add three bytes to the packet after 6lowpan compression.


              

              
I agree.

Maybe you could describe a concrete example of how using link-local addresses in the outer header would address Peter's scenario that he posted to the list?


            

            

            Example: Two border routers (BR1 and BR2) each forming a
            network:

            

            --- Network 1 (BR1) ---

            Unicast prefix: FD01::/64

            Unicast-prefix-based multicast address prefix:
            FF35:0040:FD01::/96

            

            --- Network 2 (BR2) ---

            Unicast prefix: FD02::/64

            Unicast-prefix-based multicast address prefix:
            FF35:0040:FD02::/96

            

            
    
              
  1. A non-MPL aware node in network 1 wishes to send a
                multicast to all nodes in network 1.
              
    2. 
              
  2. It sends to multicast address FF35:0040:FD01::1,
                un-encapsulated. 
    3. 
              
  3. The packet is received by a MPL router in network 2
                (N2R1). 
    4. 
              
  4. N2R1 finds no higher layer listening to
                FF35:0040:FD01::1 and, therefore, does not pass the
                packet up.
    
              
    5. 
              
  5. N2R1 finds no matching routing information for
                FF35:0040:FD01::1 and does not forward the packet. The
                packet is, therefore, discarded.
              
    6. 
              
  6. The packet is also received by a MPL router in network
                1 (N1R1). 
    7. 
              
  7. N1R1 finds a higher layer listening to
                FF35:0040:FD01::1 and passes a copy of the packet up.
                Note: This would depend on whether or not any higher
                layers were actually interested in the mc group. Also,
                this step is not a prerequisite for the next step to
                occur. 
    8. 
              
  8. N1R1 finds matching routing information for
                FF35:0040:FD01::1, because it is a member of network
                FD01::/64
              
    9. 
              
  9. N1R1 encapsulates the packet with a MPL HbH option
                such that the outer and inner destination addresses
                appear as: [FF02::MPL][FF35:0040:FD01::1], respectively.
              
    10. 
              
  10. N1R1 transmits the new resulting packet. 
    11. 
              
  11. The packet is received by another MPL router in
                network 1 (N1R2). 
    12. 
              
  12. Seeing that the destination address is FF02::MPL, N1R2
                decapsulates the packet (i.e. the original packet exits
                the tunnel).
              
    13. 
              
  13. N1R2 finds a higher layer listening to
                FF35:0040:FD01::1 and passes a copy of the inner packet
                up. Note: This step is not a prerequisite for the next
                step to occur.
    
              
    14. 
              
  14. N1R2 also finds matching routing information for
                FF35:0040:FD01::1, because it is a member of network
                FD01::/64.
              
    15. 
              
  15. N1R2 re-encapsulates the packet with the *original*
                MPL HbH option such that the outer and inner destination
                addresses appear as: [FF02::MPL][FF35:0040:FD01::1],
                respectively.
              
    16. 
              
  16. N1R2 transmits the resulting packet. 
    17. 
              
  17. The packet is received by yet another MPL router in
                network 2 (N2R2). 
    18. 
              
  18. Seeing that the destination address is FF02::MPL, N2R2
                decapsulates the packet (i.e. the original packet exits
                the tunnel).
              
    19. 
              
  19. N2R2 finds no matching routing information or listener
                for FF35:0040:FD01::1 and, therefore, discards the
                packet.
    
              
    20. 
            

            

            Note:

            I chose a non-MPL aware originator of a multicast packet,
            because I wanted to be more thorough. I could have chosen an
            example where the originator of the packet *was* a MPL aware
            device. In such a case, it would have encapsulated with its
            own MPL HbH option as if it were forwarding the packet (i.e.
            outer and inner destinations would have been
            [FF02::MPL][FF35:0040:FD01::1]). One complication of non-MPL
            aware devices sending non-link-local multicasts is the
            problem of fan-out: If such a device multicasts/broadcasts
            at the link-layer for IPv6 multicasts, then many MPL routers
            may hear the packet and try forward it with their own seeds.
            Although this wouldn't cause a real packet-storm, it would
            cause something close to it, depending on how many routers
            were in earshot of the originator. However, this is a
            general problem that has nothing to do with MPL's address
            scope.

            

            Secondly, notice that FF02::MPL can be viewed as a well
            defined address for a "tunnel exit point". It just so
            happens that it actually identifies multiple physical "exit
            points".

            

            - Dario

            

            

          

        

      

      

    

    

  


--------------070202040307020805020506--

From dat@exegin.com  Thu Nov  8 12:03:53 2012
Return-Path: 
X-Original-To: roll@ietfa.amsl.com
Delivered-To: roll@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D782F21F85B2 for ; Thu,  8 Nov 2012 12:03:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.211
X-Spam-Level: 
X-Spam-Status: No, score=-3.211 tagged_above=-999 required=5 tests=[AWL=0.388,  BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T7L4LCielzkq for ; Thu,  8 Nov 2012 12:03:53 -0800 (PST)
Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id D863021F868D for ; Thu,  8 Nov 2012 12:03:52 -0800 (PST)
Received: by mail-pb0-f44.google.com with SMTP id ro8so2431511pbb.31 for ; Thu, 08 Nov 2012 12:03:52 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding :x-gm-message-state; bh=HxdzTQ1bs/zVPqxNevNg7hOYqp5E69orKBAmlKninxo=; b=TKpTEuN6rytcKzrCUPT+SsN4rgYUhgZDJmvSeis+MfwGIOf6f6shVrxCmqYnKt5E4v VeVEeBD8nbgfJnevq+//h3TAVdkEPXKNlklpXwP/IH0+aLFnu/3rQ9jlrR5YmkcXu5Mo t/5yJAiYHAtStNASsBC80+vgwl+3kLO5j8uYhPBPWx6pOOlxbtYZjbq7Xl+Y2W88hJFa TkbhfKbBMIP3pSQ/4WlCz89Ekj/xisUNykFC7zYtUCAVL1Zi6iVho7T5WDYAQSsdMVZx FNqN6p620N4vAyNuevFku4lg0DRolG9VU8zff3cFtojRmdwMCaWMD/Pyowku57cybyeO wGQQ==
Received: by 10.68.253.102 with SMTP id zz6mr26940166pbc.99.1352405032566; Thu, 08 Nov 2012 12:03:52 -0800 (PST)
Received: from [172.16.1.52] ([184.71.143.130]) by mx.google.com with ESMTPS id pv8sm6312950pbc.26.2012.11.08.12.03.50 (version=SSLv3 cipher=OTHER); Thu, 08 Nov 2012 12:03:51 -0800 (PST)
Message-ID: <509C1037.8030506@exegin.com>
Date: Thu, 08 Nov 2012 12:04:07 -0800
From: Dario Tedeschi 
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:7.0) Gecko/20110922 Thunderbird/7.0
MIME-Version: 1.0
To: "Jonathan Hui (johui)" 
References:     <5091B2A3.1090205@exegin.com>   <404.1351779310@obiwan.sandelman.ca> <21d5e8c9a5f4a517a8fa421497f37c8a@xs4all.nl> <19755.1351900015@sandelman.ca> <7a5d49da82e9b77ea808b389792ccdeb@xs4all.nl> 
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Gm-Message-State: ALoCoQlfw44er7GIl7XKodrUqbr1S/Esicj65lSzwqfL1ecmUVk2klWJRAm5vDUsF31K2/2XnkAq
Cc: "roll@ietf.org WG" 
Subject: Re: [Roll] WG Last Call draft-ietf-roll-trickle-mcast-02
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Routing Over Low power and Lossy networks 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 08 Nov 2012 20:03:54 -0000

On 05/11/2012 5:27 AM, Jonathan Hui (johui) wrote:
> Hi Peter,
>
> To reiterate my thoughts - this works because the IPv6 multicast address identifying the endpoints also identifies the MPL domain.

This depends on how one defines "MPL domain". Is it defined like a 
"routing domain", where a "routing domain"  is a collection of networked 
systems that operate a common routing protocol? Or is it defined as the 
area an mc address will cover. I think it should be the former, in which 
case FF02::MPL would identify the "MPL domain", since any router 
listening on FF02::MPL would be participating in the MPL protocol.


>    How would you limit the scope of disseminating a message sent to a well-known IPv6 multicast address?  Or is the answer (i) we don't support anything other than unicast-prefix-based multicast addresses or (ii) we don't limit the dissemination scope sent to anything else?

That is determined by routing information, and I'm not sure MPL should 
be trying to answer that question. MPL is not really a routing protocol, 
because it does not disseminate routing information. It's more a means 
of propagation. Routing information (implied or explicit) has to come 
from somewhere, though. And since I think MPL was written to support 
RPL's non-storing mode of operation, I think RPL should be responsible 
for providing that information. An example of implied routing 
information could be the prefix in a PIO used for address auto-config (a 
'la unicast-prefixed-based mc), while an example of explicit routing 
information might be a mc prefix in a RIO. If someone wants to use MPL 
without RPL, then routers have to either forward packets based on 
mc-scope alone or they'd have to define some means of disseminating 
routing information.


>
> The options I see:
>
> 1) Use the same IPv6 multicast address for identifying both endpoints and MPL domain.
> 1a) MPL is not used to disseminate packets destined to other IPv6 multicast addresses.
> 1b) MPL may be used to disseminate packets destined to other IPv6 multicast addresses, but will disseminate across any connected region of MPL forwarders.
>
> In supporting the cases above, a well-known link-local multicast address is used in the outer IPv6 header when encapsulation is used.  The outer header's MPL Option and the inner header's IPv6 destination address is used to determine whether to (i) pass up to higher layers and (ii) forward the packet.
>
> If we decide to support inclusion of the MPL Option without encapsulation, then a forwarder needs to understand that the MPL Option and IPv6 destination address in the same IPv6 header are used to determine (i) pass up to higher layers and (ii) forward the packet.
>
> 2) Decouple the concept of MPL domain and application endpoint identifiers.
> 2a) Identify MPL domain using outer header's IPv6 destination address.
> 2b) Identify MPL domain using "instance" field in MPL Option.
>
> Both cases above would allow limiting the dissemination scope of any arbitrary IPv6 multicast address, including well-known addresses.  Furthermore, the forwarding decision is made using only information contained in a single IPv6 header - option 2a relies on the MPL Option and the IPv6 destination address of the outer header, option 2b relies only on information contained in the MPL Option.
>
> Both options 1 and 2 require managing another identifier space.  Option 1 requires configuring the devices with a prefix.  Option 2a requires configuring devices with a multicast group.  Option 2b requires configuring devices with an MPL instance.
>
> Option 1 avoids the need to carry a separate MPL domain identifier since it requires the IPv6 multicast addresses to use the same prefix that identifies the MPL domain.
>
> Comments/thoughts?
>
> --
> Jonatan Hui
>
> On Nov 5, 2012, at 7:23 AM, peter van der Stok  wrote:
>
>> Hi Michael,
>>
>> The answer to your question is given by the scenario of Dario that I reproduced below.
>>
>> Actions  4 and 5 describe what I intended to limit the forwarding.
>>
>> In addition I like to mention that when a multicast is intended for a group with members in N2 and N1
>> the multicast address could have a prefix that is a prefix to Fd01::/64 and Fd02::/64.
>> For example the MC address is then FF35:0040:FD0::1.
>> In accordance, I suggest that all forwarders in N1 and in N2 accept and forward the message.
>>
>>
>> As an aside I like to mention that BR1 and BR2 use the same channel for 802.15.4 because often there are many physical and organisational constraints who may dictate such an alocation.
>>
>> Greetings,
>>
>> Peter
>>
>> -------- DArio scenario     -------
>>
>> Example: Two border routers (BR1 and BR2) each forming a network:
>>
>> --- Network 1 (BR1) ---
>> Unicast prefix: FD01::/64
>> Unicast-prefix-based multicast address prefix: FF35:0040:FD01::/96
>>
>> --- Network 2 (BR2) ---
>> Unicast prefix: FD02::/64
>> Unicast-prefix-based multicast address prefix: FF35:0040:FD02::/96
>> 1.	A non-MPL aware node in network 1 wishes to send a multicast to all nodes in network 1.
>> 2.	It sends to multicast address FF35:0040:FD01::1, un-encapsulated.
>> 3.	The packet is received by a MPL router in network 2 (N2R1).
>> 4.	N2R1 finds no higher layer listening to FF35:0040:FD01::1 and, therefore, does not pass the packet up.
>> 5.	N2R1 finds no matching routing information for FF35:0040:FD01::1 and does not forward the packet. The packet is, therefore, discarded.
>> 6.	The packet is also received by a MPL router in network 1 (N1R1).
>> 7.	N1R1 finds a higher layer listening to FF35:0040:FD01::1 and passes a copy of the packet up. Note: This would depend on whether or not any higher layers were actually interested in the mc group. Also, this step is not a prerequisite for the next step to occur.
>> 8.	N1R1 finds matching routing information for FF35:0040:FD01::1, because it is a member of network FD01::/64
>> 9.	N1R1 encapsulates the packet with a MPL HbH option such that the outer and inner destination addresses appear as: [FF02::MPL][FF35:0040:FD01::1], respectively.
>> 10.	N1R1 transmits the new resulting packet.
>> 11.	The packet is received by another MPL router in network 1 (N1R2).
>> 12.	Seeing that the destination address is FF02::MPL, N1R2 decapsulates the packet (i.e. the original packet exits the tunnel).
>> 13.	N1R2 finds a higher layer listening to FF35:0040:FD01::1 and passes a copy of the inner packet up. Note: This step is not a prerequisite for the next step to occur.
>> 14.	N1R2 also finds matching routing information for FF35:0040:FD01::1, because it is a member of network FD01::/64.
>> 15.	N1R2 re-encapsulates the packet with the *original* MPL HbH option such that the outer and inner destination addresses appear as: [FF02::MPL][FF35:0040:FD01::1], respectively.
>> 16.	N1R2 transmits the resulting packet.
>> 17.	The packet is received by yet another MPL router in network 2 (N2R2).
>> 18.	Seeing that the destination address is FF02::MPL, N2R2 decapsulates the packet (i.e. the original packet exits the tunnel).
>> 19.	N2R2 finds no matching routing information or listener for FF35:0040:FD01::1 and, therefore, discards the packet.
>>
>> ----- end Dario scenario -------
>>
>> Michael Richardson schreef op 2012-11-03 00:46:
>>> see inline
>>>
>>> peter van der Stok  wrote:
>>>     peter>  It is related to the scope of the multicast, but not in the
>>>     peter>  administrative sense, but in an operational sense when
>>>     peter>  wireless forwarders receive MPL messages and they should be
>>>     peter>  able to filter only those messages that are targeted to the
>>>     peter>  subnet of which they are part.
>>>
>>> Is this about configuring multicast (hardware) filters so that the wrong
>>> nodes aren't woken up?
>>> Is the case you speak up articulated by one of Robert's diagrams?
>>>
>>>     peter>  I explained the case earlier with an example.
>>>
>>> Yes, I had asked a question about that too.  I didn't understand how
>>> the two networks overlapped.  Do they share the same 15.4 key material?
>>> Do they have the same beacons?
>>>
>>> My feeling is that you are solving a problem which exists on paper, but
>>> not in a real 15.4 network.  But, I could be completely wrong.
> _______________________________________________
> Roll mailing list
> Roll@ietf.org
> https://www.ietf.org/mailman/listinfo/roll


From mcr@sandelman.ca  Thu Nov  8 12:22:24 2012
Return-Path: 
X-Original-To: roll@ietfa.amsl.com
Delivered-To: roll@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D4C121F88F8 for ; Thu,  8 Nov 2012 12:22:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.886
X-Spam-Level: 
X-Spam-Status: No, score=-1.886 tagged_above=-999 required=5 tests=[AWL=0.068,  BAYES_00=-2.599, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BcL37nIVk+6Y for ; Thu,  8 Nov 2012 12:22:23 -0800 (PST)
Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by ietfa.amsl.com (Postfix) with ESMTP id ED44021F8ACE for ; Thu,  8 Nov 2012 12:22:18 -0800 (PST)
Received: from sandelman.ca (dhcp-1280.meeting.ietf.org [130.129.18.128]) by relay.sandelman.ca (Postfix) with ESMTPS id 9A90B81A9 for ; Thu,  8 Nov 2012 15:14:07 -0500 (EST)
Received: from sandelman.ca (quigon.sandelman.ca [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id A9A73CA0BC for ; Thu,  8 Nov 2012 15:22:16 -0500 (EST)
From: Michael Richardson 
To: "" 
In-reply-to: <509C03C2.50809@exegin.com>
References: <058.e817419e990e1afb26be9aa25d5cfc21@trac.tools.ietf.org>  <50932647.3050509@exegin.com>  <5094202F.4010805@exegin.com>  <509C03C2.50809@exegin.com>
Comments: In-reply-to Dario Tedeschi  message dated "Thu, 08 Nov 2012 11:10:58 -0800."
X-Mailer: MH-E 8.3; nmh 1.3; XEmacs 21.4 (patch 22)
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature"
Date: Thu, 08 Nov 2012 15:22:16 -0500
Message-ID: <19753.1352406136@sandelman.ca>
Sender: mcr@sandelman.ca
Subject: Re: [Roll] [roll] #105: trickle-mcast: how to determine scope of MPL domain
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Routing Over Low power and Lossy networks 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 08 Nov 2012 20:22:24 -0000

--=-=-=
Content-Transfer-Encoding: quoted-printable


>>>>> "Dario" =3D=3D Dario Tedeschi  writes:
    >> In my approach (allow non-link-local in the outer header), I
    >> tried to separate out the identifiers for the application
    >> endpoints and the MPL domain.  That is why I used the outer
    >> header's destination address to identify the MPL domain and the
    >> inner header's destination address to identify the application
    >> endpoints.  With this approach, it actually becomes feasible to
    >> address situations where the devices within an MPL domain
    >> subscribe to arbitrary IPv6 multicast addresses - not just ones
    >> that are based on the unicast prefix.

    Dario> Firstly, yes I agree the inner destination address should
    Dario> determine the application endpoint. What I'm not clear on is
    Dario> why we need an MPL domain to cover more than the LLN or why
    Dario> we need to support multiple MPL domains in one LLN. Tf the
    Dario> latter case is required to allow for different sets of MPL
    Dario> propagation parameters, then I'd imagine that should rather
    Dario> be handled by the HbH option.

So, I think we really need to hear some use cases for having multiple
MPL domains in one LLN.  Please exclude mDNS(ext) in the list.

=2D-=20
Michael Richardson
=2Don the road-




--=-=-=
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)

iQEcBAABAgAGBQJQnBR4AAoJEKD0KQ7Gj3P24CsH/j8toFc/ypgTBvPm1q/QNPaI
YJiLJhqvLS+rtaBj5sJ+gcIU6eS5K0mcbdIxuwADo5VJNz15z4bUWLnE2ulbT9Yb
fhs8OP2hNArnXf9nEdrbeaH50RS+8T1PxWc2X6x0lLIHkz3dN767WWBfV1ua/vgo
UDaMSl5uGBOd//W7U4YO4Lgm42oEuTLIEWQD37GMe/emPZ8+JhTTOiceuucAPPmQ
cv7VfyP/g/xdpr7ACK7vj+Hqp4+TLGUbqsUOaMM/XbpRla++7m8wuEm+JH/QqYhj
mNsgmHOJQfqKOnd+tZPZDpyjt1OB9MvIMehcq8lwrKPuvR3TC+0sEsSo56X7Ia8=
=oPek
-----END PGP SIGNATURE-----
--=-=-=--

From johui@cisco.com  Thu Nov  8 13:02:20 2012
Return-Path: 
X-Original-To: roll@ietfa.amsl.com
Delivered-To: roll@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A11FF21F889E for ; Thu,  8 Nov 2012 13:02:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.389
X-Spam-Level: 
X-Spam-Status: No, score=-10.389 tagged_above=-999 required=5 tests=[AWL=0.210, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FWmL1UfDYBfy for ; Thu,  8 Nov 2012 13:02:19 -0800 (PST)
Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 8EB3C21F85BA for ; Thu,  8 Nov 2012 13:02:19 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7323; q=dns/txt; s=iport; t=1352408539; x=1353618139; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=46uMqetK3o3+Wx4pSMOg9IhBEcOU/tCb81xM4FSeCxk=; b=RpZjlA1K+HyUyNIwvkHz9eodYB7XsvB1XMRIRIamAX3dNatZRGLK3YvQ xZ9AERxbM/uy9EKjEO+NqDJ4xK2+cIptxCpkTc45suz43hIY9zN/hpH17 4TFwha3TKo24lX5EM6nqcFmnyDjjWjHnQtjJX587h47AVhSTsbFGXHhQX Y=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av8EAPIcnFCtJXG8/2dsb2JhbAA6CsNCgQiCHgEBAQMBEgFfBwULAgEIDgoKAiIyJQIEDgUIGodiBpwloDGMEhAFhVFhA6RTgWuCb4FcHx4
X-IronPort-AV: E=Sophos;i="4.80,740,1344211200"; d="scan'208";a="140301572"
Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-8.cisco.com with ESMTP; 08 Nov 2012 21:02:19 +0000
Received: from xhc-aln-x05.cisco.com (xhc-aln-x05.cisco.com [173.36.12.79]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id qA8L2IbN007887 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 8 Nov 2012 21:02:18 GMT
Received: from xmb-rcd-x04.cisco.com ([169.254.8.200]) by xhc-aln-x05.cisco.com ([173.36.12.79]) with mapi id 14.02.0318.001; Thu, 8 Nov 2012 15:02:17 -0600
From: "Jonathan Hui (johui)" 
To: Dario Tedeschi 
Thread-Topic: [Roll] [roll] #105: trickle-mcast: how to determine scope of MPL domain
Thread-Index: AQHNuEl+VKkUNGCnjEqLpghV1euTUw==
Date: Thu, 8 Nov 2012 21:02:16 +0000
Message-ID: 
References: <058.e817419e990e1afb26be9aa25d5cfc21@trac.tools.ietf.org>  <50932647.3050509@exegin.com>  <5094202F.4010805@exegin.com>  <509C03C2.50809@exegin.com>
In-Reply-To: <509C03C2.50809@exegin.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [128.107.155.2]
x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19348.005
x-tm-as-result: No--44.872500-8.000000-31
x-tm-as-user-approved-sender: No
x-tm-as-user-blocked-sender: No
Content-Type: text/plain; charset="Windows-1252"
Content-ID: <19D9765F55820D4D9E56F71EB550B4E6@cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "" , "" , "" , "Jonathan Hui \(johui\)" 
Subject: Re: [Roll] [roll] #105: trickle-mcast: how to determine scope of MPL domain
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Routing Over Low power and Lossy networks 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 08 Nov 2012 21:02:20 -0000

Hi Dario,

On Nov 8, 2012, at 11:10 AM, Dario Tedeschi  wrote:

> On 02/11/2012 10:18 PM, Jonathan Hui (johui) wrote:
>>=20
>> With your approach (require link-local in the outer header), the IPv6 mu=
lticast address identifies the application endpoints *and* the MPL domain. =
 For that reason, your approach really only needs a single identifier to bo=
th limit the flooding scope and determine the application endpoints.
> It depends on what you mean by MPL domain. In my view,  FF02::MPL identif=
ies the MPL domain, while the inner IPv6 destination address identifies the=
 application endpoint.

Let me introduce a new term to help move the discussion forward:  Dissemina=
tion Region - a connected set of MPL devices that attempt to forward the pa=
cket so that all devices receive the packet at least once.  Another definit=
ion may be: a region within which the SeedID must be unique.

>>  I can see how that would work (as you demonstrated) if we make the rest=
riction that the IPv6 multicast addresses used within an MPL domain have th=
e same prefix that identifies the MPL domain itself.  The trouble comes whe=
n you want to support the full generality that IPv6 multicast addresses use=
d by application endpoints can be arbitrary.
>=20
> The "generality", you talk of, is why protocols like MLD exist. MLD infor=
ms routers of mc addresses other devices are interested in. Essentially it =
provides routing information. How could we support the "full generality" of=
 mc addresses without this information (whether implied or from something l=
ike MLD).  With this in mind, I don't understand the need for non-link-loca=
l scope in the outer header, because the "generality" you seek would be det=
ermined by the mc address of the original packet (i.e. the mc address of th=
e inner header). All my approach is really saying is that only the original=
/inner mc address determines how far a packet will propagate, regardless of=
 routing domain. MPL could just be one of many routing domains a mc packet =
must traverse before reaching its furthermost boundary. Or MPL may be the o=
nly routing domain, where the mc packet only reaches a sub-set of devices w=
ithin the domain (i.e. a multicast group or a set based on unicast-prefix-b=
ased mc).

The original intent of MPL was to avoid any routing information within the =
Dissemination Region.  A router then only maintains state about what multic=
ast addresses are of interest to devices within the Dissemination Region.

>> For example, how does MPL support an application that subscribes to a we=
ll-known non-link-local IPv6 multicast address?  I guess one approach is to=
 say that if the IPv6 multicast address is not a unicast-prefix-based multi=
cast address, then it disseminates across the entire region of connected MP=
L forwarders.
>=20
> Granted one could have a situation where all routers hear an mc packet th=
at is only intended for a subset of devices, but that does not mean all rou=
ters need to forward that packet or pass it to a higher layer. Again, this =
would depend on the inner mc address and the routing information available =
to routers. The routers without the appropriate routing information would n=
ot forward. Similarly, routers without mc membership information from an ap=
p would not pass the packet to the next higher layer.

We have different thoughts on how a device determines whether or not to for=
ward the packet.  You take a routing perspective, where a device determines=
 whether or not to forward based on the identifier for the application endp=
oints.  In contrast, I view it as a device determines whether or not to for=
ward based on the Dissemination Region it is in.  Note that in my view, the=
 Dissemination Region does not have to have any relationship with the ident=
ifier for application endpoints.  In other words, you can configure the Dis=
semination Region without any knowledge of the multicast addresses that dev=
ices are interested in.

>> One minor point with your approach is that the delivery requires process=
ing the MPL Option of the outer header and the inner IPv6 header.  That isn=
't so nice from an architectural perspective, but that is what we did with =
RFC 6553.
>=20
> Using non-link-local in the outer header does not mitigate that. The forw=
arder still needs to look at the inner header to determine if the inner mc =
address is one an app is listening on. In fact implementing this is a bit m=
essy compared to my approach, because the forwarder has to look ahead into =
the packet before decapsulating. My approach always requires decapsulation =
before making any decision about where the packet must go next. It's simple=
r and more consistent. I've actually had the fortune/misfortune of implemen=
ting both and I can safely say the link-local approach was cleaner.

I'd argue that using non-link-local in the outer header helps to preserve t=
he layering.
1) Processing the outer header allows a device to determine whether it is a=
 part of the Dissemination Region and the packet was received before.
2) Processing the inner header allows a device to determine whether it shou=
ld process the payload.

Can you explain why a device needs to "look ahead" into the packet before d=
ecapsulating when using a non-link-local outer header?

>> In my approach (allow non-link-local in the outer header), I tried to se=
parate out the identifiers for the application endpoints and the MPL domain=
.  That is why I used the outer header's destination address to identify th=
e MPL domain and the inner header's destination address to identify the app=
lication endpoints.  With this approach, it actually becomes feasible to ad=
dress situations where the devices within an MPL domain subscribe to arbitr=
ary IPv6 multicast addresses - not just ones that are based on the unicast =
prefix.
>=20
> Firstly, yes I agree the inner destination address should determine the a=
pplication endpoint. What I'm not clear on is why we need an MPL domain to =
cover more than the LLN or why we need to support multiple MPL domains in o=
ne LLN. Tf the latter case is required to allow for different sets of MPL p=
ropagation parameters, then I'd imagine that should rather be handled by th=
e HbH option.

Peter's use case involves having multiple Dissemination Regions within a si=
ngle IEEE 802.15.4 PAN.  I agree, one could argue whether the devices shoul=
d all be within the same PAN or different PANs based on the nearest border =
router.

During the WG meeting, people made a good argument that we actually don't k=
now the answer - either because all the use cases are not obvious or becaus=
e we don't understand all the consequences of each approach.  One proposal =
was to have the draft specify well-defined forwarding behavior that support=
s both situations.  For example:
1) If the outer header has an IPv6 Destination Address matching the link-lo=
cal all-MPL-forwarders address, do =85
2) Otherwise, do =85

Then leave it up to those who are using this spec to determine what subset =
they want to use.  Not sure if this is a reasonable approach and would like=
 to get feedback from the WG.

--
Jonathan Hui


From robert.cragie@gridmerge.com  Thu Nov  8 15:54:51 2012
Return-Path: 
X-Original-To: roll@ietfa.amsl.com
Delivered-To: roll@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5EDC721F8B60 for ; Thu,  8 Nov 2012 15:54:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.225
X-Spam-Level: 
X-Spam-Status: No, score=-2.225 tagged_above=-999 required=5 tests=[AWL=0.373,  BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g7Q+WBLadLOV for ; Thu,  8 Nov 2012 15:54:49 -0800 (PST)
Received: from mail78.extendcp.co.uk (mail78.extendcp.co.uk [79.170.40.78]) by ietfa.amsl.com (Postfix) with ESMTP id AA77B21F8B5F for ; Thu,  8 Nov 2012 15:54:48 -0800 (PST)
Received: from client-86-29-206-117.glfd-bam-2.adsl.virginmedia.com ([86.29.206.117] helo=[192.168.0.2]) by mail78.extendcp.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.77) id 1TWbvq-0004yj-Pr for roll@ietf.org; Thu, 08 Nov 2012 23:54:47 +0000
Message-ID: <509C4689.1080700@gridmerge.com>
Date: Thu, 08 Nov 2012 23:55:53 +0000
From: Robert Cragie 
Organization: Gridmerge Ltd.
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121026 Thunderbird/16.0.2
MIME-Version: 1.0
To: roll@ietf.org
References: <058.e817419e990e1afb26be9aa25d5cfc21@trac.tools.ietf.org>  <50932647.3050509@exegin.com>  <5094202F.4010805@exegin.com>  <509C03C2.50809@exegin.com>
In-Reply-To: <509C03C2.50809@exegin.com>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms070906050400000801060504"
X-Authenticated-As: robert.cragie@gridmerge.com
Subject: Re: [Roll] [roll] #105: trickle-mcast: how to determine scope of MPL domain
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: robert.cragie@gridmerge.com
List-Id: Routing Over Low power and Lossy networks 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 08 Nov 2012 23:54:51 -0000

This is a cryptographically signed message in MIME format.

--------------ms070906050400000801060504
Content-Type: multipart/alternative;
 boundary="------------010807040401010800020500"

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

Hi Dario,

Comments inline, bracketed by 

Robert

On 08/11/2012 7:10 PM, Dario Tedeschi wrote:
> Hi Jonathan
>
> On 02/11/2012 10:18 PM, Jonathan Hui (johui) wrote:
>>
>> Hi Dario,
>>
>> Thanks for the detailed example - I see our disconnect now.
>>
>> With your approach (require link-local in the outer header), the IPv6 =

>> multicast address identifies the application endpoints *and* the MPL=20
>> domain.  For that reason, your approach really only needs a single=20
>> identifier to both limit the flooding scope and determine the=20
>> application endpoints.
> It depends on what you mean by MPL domain. In my view,  FF02::MPL=20
> identifies the MPL domain, while the inner IPv6 destination address=20
> identifies the application endpoint.
>
>
>>  I can see how that would work (as you demonstrated) if we make the=20
>> restriction that the IPv6 multicast addresses used within an MPL=20
>> domain have the same prefix that identifies the MPL domain itself.=20
>>  The trouble comes when you want to support the full generality that=20
>> IPv6 multicast addresses used by application endpoints can be arbitrar=
y.
>
> The "generality", you talk of, is why protocols like MLD exist. MLD=20
> informs routers of mc addresses other devices are interested in.=20
> Essentially it provides routing information. How could we support the=20
> "full generality" of mc addresses without this information (whether=20
> implied or from something like MLD).  With this in mind, I don't=20
> understand the need for non-link-local scope in the outer header,=20
> because the "generality" you seek would be determined by the mc=20
> address of the original packet (i.e. the mc address of the inner header=
).=20
Peter van der Stok had a use case where this might be useful=20
whereby a PAN is subdivided into two subnets, using e.g. Prefix1 and=20
Prefix2. A site local multicast would be encapsulated in a packet using=20
a unicast prefix-based multicast for e.g. Prefix1. Then it would only be =

forwarded through Prefix1 subnet to maybe only one border router and=20
emanate on another interface on that border router. Prefix2 MPL=20
forwarders would not do anything. I don't see how you could do that with =

link local multicast as the inner packet's scope has no relation in this =

case.
> All my approach is really saying is that only the original/inner mc=20
> address determines how far a packet will propagate, regardless of=20
> routing domain. MPL could just be one of many routing domains a mc=20
> packet must traverse before reaching its furthermost boundary. Or MPL=20
> may be the only routing domain, where the mc packet only reaches a=20
> sub-set of devices within the domain (i.e. a multicast group or a set=20
> based on unicast-prefix-based mc).
In the last case, you don't need encapsulation of course
>
>
>>
>> For example, how does MPL support an application that subscribes to a =

>> well-known non-link-local IPv6 multicast address?  I guess one=20
>> approach is to say that if the IPv6 multicast address is not a=20
>> unicast-prefix-based multicast address, then it disseminates across=20
>> the entire region of connected MPL forwarders.
>
> Granted one could have a situation where all routers hear an mc packet =

> that is only intended for a subset of devices, but that does not mean=20
> all routers need to forward that packet or pass it to a higher layer.=20
> Again, this would depend on the inner mc address and the routing=20
> information available to routers.

See above case where this may be different
> The routers without the appropriate routing information would not=20
> forward. Similarly, routers without mc membership information from an=20
> app would not pass the packet to the next higher layer.

It is important to distinguish forwarding from processing.

1. In the unencapsulated case:

1a. Whether to forward or not is based in the destination address and=20
the MPL option
1b. Whether to process or not is based in the destination address

2. In the MDM encapsulated case:

2a. Whether to forward or not is based in the outer destination address=20
and the MPL option
2b. Whether to process or not is based in the inner destination address

3. In the LLM encapsulated case:

3a. Whether to forward or not is based in the inner destination address=20
and the MPL option
3b. Whether to process or not is based in the inner destination address

When looking at choosing (2) or (3), consider some of these statements:

(1a) is consistent with (2a) but not consistent with (3a). On that=20
basis, (2) makes more sense
(2b) and (3b) are the same, so both are acceptable
(2b) may seem inconsistent with (2a), i.e. basing the decision to=20
process on the inner header, but clearly separates the endpoint domain=20
from the forwarding domain. (3) cannot make that distinction.




>
>
>
>>
>> One minor point with your approach is that the delivery requires=20
>> processing the MPL Option of the outer header and the inner IPv6=20
>> header.  That isn't so nice from an architectural perspective, but=20
>> that is what we did with RFC 6553.
>
> Using non-link-local in the outer header does not mitigate that. The=20
> forwarder still needs to look at the inner header to determine if the=20
> inner mc address is one an app is listening on. In fact implementing=20
> this is a bit messy compared to my approach, because the forwarder has =

> to look ahead into the packet before decapsulating.=20
I don't see that. It has to decapsulate anyway for processing. If=20
the address means it doesn't get processed, it throws it away. The=20
forwarding logic may come to the same conclusion.
> My approach always requires decapsulation before making any decision=20
> about where the packet must go next. It's simpler and more consistent. =

> I've actually had the fortune/misfortune of implementing both and I=20
> can safely say the link-local approach was cleaner.
I would disagree on the single point that  you need an additional=20
mechanism for handling forwarding from the unencapsulated case. I agree=20
it is a trivial addition but an addition nevertheless
>
>
>>
>> In my approach (allow non-link-local in the outer header), I tried to =

>> separate out the identifiers for the application endpoints and the=20
>> MPL domain.  That is why I used the outer header's destination=20
>> address to identify the MPL domain and the inner header's destination =

>> address to identify the application endpoints.  With this approach,=20
>> it actually becomes feasible to address situations where the devices=20
>> within an MPL domain subscribe to arbitrary IPv6 multicast addresses=20
>> - not just ones that are based on the unicast prefix.
>
> Firstly, yes I agree the inner destination address should determine=20
> the application endpoint. What I'm not clear on is why we need an MPL=20
> domain to cover more than the LLN or why we need to support multiple=20
> MPL domains in one LLN. Tf the latter case is required to allow for=20
> different sets of MPL propagation parameters, then I'd imagine that=20
> should rather be handled by the HbH option.
It could be done that way but you are now introducing another=20
"label" by which to determine forwarding when address scope an group ID=20
seems perfectly adequate to me

>
> - Dario
>
>>
>> --
>> Jonathan Hui
>>
>> On Nov 2, 2012, at 12:34 PM, Dario Tedeschi > > wrote:
>>
>>> On 01/11/2012 7:12 PM, Jonathan Hui (johui) wrote:
>>>> On Nov 1, 2012, at 6:47 PM, Dario Tedeschi  wrote:
>>>>
>>>>> I don't understand what benefit is gained by allowing the use of no=
n-link-local in the outer header, if encapsulation is required. Supportin=
g both link-local and higher in the outer header just servers to complica=
te the forwarder.
>>>> The purpose is to limit the extent to which MPL disseminates a packe=
t to something smaller than the entire LLN (item 2).
>>>
>>> Isn't that what multicast groups and/or unicast-prefix-based=20
>>> multicasts are for? That is to say, to reach a defined set of devices=
=2E
>>>
>>>
>>>>> Is item 2 a requirement that a subset of devices in the LLN partici=
pate in MPL forwarding and others don't, or is it that there are two MPL =
domains, or is it that one subset of devices are listening on multicast a=
ddress A while others are listening on multicast address B? In any case, =
I don't see how the use of link-local scope in the *outer* header would n=
ot work.
>>>> As mentioned above, the purpose is to limit the physical extent of M=
PL forwarders that disseminate a message.  If we use a link-local destina=
tion address in the outer header, how do you propose to limit the region?=

>>>
>>> The destination in the inner header determines if the packet needs=20
>>> to be forwarded or not, or forwarded on a different interface.
>>>
>>>
>>>>> As for encapsulation, using an MPL multicast address of the from FF=
02::00XX, in the outer header, would only add three bytes to the packet a=
fter 6lowpan compression.
>>>> I agree.
>>>>
>>>> Maybe you could describe a concrete example of how using link-local =
addresses in the outer header would address Peter's scenario that he post=
ed to the list?
>>>
>>> Example: Two border routers (BR1 and BR2) each forming a network:
>>>
>>> --- Network 1 (BR1) ---
>>> Unicast prefix: FD01::/64
>>> Unicast-prefix-based multicast address prefix: FF35:0040:FD01::/96
>>>
>>> --- Network 2 (BR2) ---
>>> Unicast prefix: FD02::/64
>>> Unicast-prefix-based multicast address prefix: FF35:0040:FD02::/96
>>>
>>>  1. A non-MPL aware node in network 1 wishes to send a multicast to
>>>     all nodes in network 1.
>>>  2. It sends to multicast address FF35:0040:FD01::1, un-encapsulated.=

>>>  3. The packet is received by a MPL router in network 2 (N2R1).
>>>  4. N2R1 finds no higher layer listening to FF35:0040:FD01::1 and,
>>>     therefore, does not pass the packet up.
>>>  5. N2R1 finds no matching routing information for FF35:0040:FD01::1
>>>     and does not forward the packet. The packet is, therefore,
>>>     discarded.
>>>  6. The packet is also received by a MPL router in network 1 (N1R1).
>>>  7. N1R1 finds a higher layer listening to FF35:0040:FD01::1 and
>>>     passes a copy of the packet up. Note: This would depend on
>>>     whether or not any higher layers were actually interested in the
>>>     mc group. Also, this step is not a prerequisite for the next
>>>     step to occur.
>>>  8. N1R1 finds matching routing information for FF35:0040:FD01::1,
>>>     because it is a member of network FD01::/64
>>>  9. N1R1 encapsulates the packet with a MPL HbH option such that the
>>>     outer and inner destination addresses appear as:
>>>     [FF02::MPL][FF35:0040:FD01::1], respectively.
>>> 10. N1R1 transmits the new resulting packet.
>>> 11. The packet is received by another MPL router in network 1 (N1R2).=

>>> 12. Seeing that the destination address is FF02::MPL, N1R2
>>>     decapsulates the packet (i.e. the original packet exits the
>>>     tunnel).
>>> 13. N1R2 finds a higher layer listening to FF35:0040:FD01::1 and
>>>     passes a copy of the inner packet up. Note: This step is not a
>>>     prerequisite for the next step to occur.
>>> 14. N1R2 also finds matching routing information for
>>>     FF35:0040:FD01::1, because it is a member of network FD01::/64.
>>> 15. N1R2 re-encapsulates the packet with the *original* MPL HbH
>>>     option such that the outer and inner destination addresses
>>>     appear as: [FF02::MPL][FF35:0040:FD01::1], respectively.
>>> 16. N1R2 transmits the resulting packet.
>>> 17. The packet is received by yet another MPL router in network 2
>>>     (N2R2).
>>> 18. Seeing that the destination address is FF02::MPL, N2R2
>>>     decapsulates the packet (i.e. the original packet exits the
>>>     tunnel).
>>> 19. N2R2 finds no matching routing information or listener for
>>>     FF35:0040:FD01::1 and, therefore, discards the packet.
>>>
>>>
>>> Note:
>>> I chose a non-MPL aware originator of a multicast packet, because I=20
>>> wanted to be more thorough. I could have chosen an example where the =

>>> originator of the packet *was* a MPL aware device. In such a case,=20
>>> it would have encapsulated with its own MPL HbH option as if it were =

>>> forwarding the packet (i.e. outer and inner destinations would have=20
>>> been [FF02::MPL][FF35:0040:FD01::1]). One complication of non-MPL=20
>>> aware devices sending non-link-local multicasts is the problem of=20
>>> fan-out: If such a device multicasts/broadcasts at the link-layer=20
>>> for IPv6 multicasts, then many MPL routers may hear the packet and=20
>>> try forward it with their own seeds. Although this wouldn't cause a=20
>>> real packet-storm, it would cause something close to it, depending=20
>>> on how many routers were in earshot of the originator. However, this =

>>> is a general problem that has nothing to do with MPL's address scope.=

>>>
>>> Secondly, notice that FF02::MPL can be viewed as a well defined=20
>>> address for a "tunnel exit point". It just so happens that it=20
>>> actually identifies multiple physical "exit points".
>>>
>>> - Dario
>>>
>>>
>>
>
>
>
> _______________________________________________
> Roll mailing list
> Roll@ietf.org
> https://www.ietf.org/mailman/listinfo/roll


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


  
    
  
  
    Hi Dario,

    

    Comments inline, bracketed by <RCC></RCC>

    

    Robert

    

    
On 08/11/2012 7:10 PM, Dario Tedeschi
      wrote:

    

    

      
      Hi Jonathan

      

      On 02/11/2012 10:18 PM, Jonathan Hui (johui) wrote:
      

        
        


        

        
Hi Dario,

        


        

        
Thanks for the detailed example - I see our disconnect now.<=
/div>
        


        

        
With your approach (require link-local in the outer
          header), the IPv6 multicast address identifies the application
          endpoints *and* the MPL domain.  For that reason, your
          approach really only needs a single identifier to both limit
          the flooding scope and determine the application endpoints.
      

      It depends on what you mean by MPL domain. In my view,  FF02::=
MPL
      identifies the MPL domain, while the inner IPv6 destination
      address identifies the application endpoint.

      

      

      

        
  I can see how that would work (as you demonstrated) i=
f we
          make the restriction that the IPv6 multicast addresses used
          within an MPL domain have the same prefix that identifies the
          MPL domain itself.  The trouble comes when you want to sup=
port
          the full generality that IPv6 multicast addresses used by
          application endpoints can be arbitrary.

      

      

      The "generality", you talk of, is why protocols like MLD exist.
      MLD informs routers of mc addresses other devices are interested
      in. Essentially it provides routing information. How could we
      support the "full generality" of mc addresses without this
      information (whether implied or from something like MLD).  Wit=
h
      this in mind, I don't understand the need for non-link-local scope
      in the outer header, because the "generality" you seek would be
      determined by the mc address of the original packet (i.e. the mc
      address of the inner header). 

    <RCC>Peter van der Stok had a use case where this might be
    useful whereby a PAN is subdivided into two subnets, using e.g.
    Prefix1 and Prefix2. A site local multicast would be encapsulated in
    a packet using a unicast prefix-based multicast for e.g. Prefix1.
    Then it would only be forwarded through Prefix1 subnet to maybe only
    one border router and emanate on another interface on that border
    router. Prefix2 MPL forwarders would not do anything. I don't see
    how you could do that with link local multicast as the inner
    packet's scope has no relation in this case.</RCC>

    
All =
my
      approach is really saying is that only the original/inner mc
      address determines how far a packet will propagate, regardless of
      routing domain. MPL could just be one of many routing domains a mc
      packet must traverse before reaching its furthermost boundary. Or
      MPL may be the only routing domain, where the mc packet only
      reaches a sub-set of devices within the domain (i.e. a multicast
      group or a set based on unicast-prefix-based mc).

    

    <RCC>In the last case, you don't need encapsulation of
    course</RCC>

    
 
      

      

        


        

        
For example, how does MPL support an application that
          subscribes to a well-known non-link-local IPv6 multicast
          address?  I guess one approach is to say that if the IPv6
          multicast address is not a unicast-prefix-based multicast
          address, then it disseminates across the entire region of
          connected MPL forwarders.

      

      

      Granted one could have a situation where all routers hear an mc
      packet that is only intended for a subset of devices, but that
      does not mean all routers need to forward that packet or pass it
      to a higher layer. Again, this would depend on the inner mc
      address and the routing information available to routers.
    

    <RCC>See above case where this may be different</RCC>
=

    
The
      routers without the appropriate routing information would not
      forward. Similarly, routers without mc membership information from
      an app would not pass the packet to the next higher layer.

    

    <RCC>

    It is important to distinguish forwarding from processing.

    

    1. In the unencapsulated case:

    

    1a. Whether to forward or not is based in the destination address
    and the MPL option

    1b. Whether to process or not is based in the destination address
=

    

    2. In the MDM encapsulated case:

    

    2a. Whether to forward or not is based in the outer destination
    address and the MPL option

    2b. Whether to process or not is based in the inner destination
    address

    

    3. In the LLM encapsulated case:

    

    3a. Whether to forward or not is based in the inner destination
    address and the MPL option

    3b. Whether to process or not is based in the inner destination
    address

    

    When looking at choosing (2) or (3), consider some of these
    statements:

    

    (1a) is consistent with (2a) but not consistent with (3a). On that
    basis, (2) makes more sense

    (2b) and (3b) are the same, so both are acceptable

    (2b) may seem inconsistent with (2a), i.e. basing the decision to
    process on the inner header, but clearly separates the endpoint
    domain from the forwarding domain. (3) cannot make that distinction.<=
br>
    </RCC>

    

    

    

    
 
      

      

      

        


        

        
One minor point with your approach is that the delivery
          requires processing the MPL Option of the outer header and the
          inner IPv6 header.  That isn't so nice from an architectur=
al
          perspective, but that is what we did with RFC 6553.

      

      

      Using non-link-local in the outer header does not mitigate that.
      The forwarder still needs to look at the inner header to determine
      if the inner mc address is one an app is listening on. In fact
      implementing this is a bit messy compared to my approach, because
      the forwarder has to look ahead into the packet before
      decapsulating. 

    <RCC>I don't see that. It has to decapsulate anyway for
    processing. If the address means it doesn't get processed, it throws
    it away. The forwarding logic may come to the same
    conclusion.</RCC>

    
My
      approach always requires decapsulation before making any decision
      about where the packet must go next. It's simpler and more
      consistent. I've actually had the fortune/misfortune of
      implementing both and I can safely say the link-local approach was
      cleaner.

    

    <RCC>I would disagree on the single point that  you need a=
n
    additional mechanism for handling forwarding from the unencapsulated
    case. I agree it is a trivial addition but an addition
    nevertheless</RCC>

    
 
      

      

        


        

        
In my approach (allow non-link-local in the outer header),
          I tried to separate out the identifiers for the application
          endpoints and the MPL domain.  That is why I used the oute=
r
          header's destination address to identify the MPL domain and
          the inner header's destination address to identify the
          application endpoints.  With this approach, it actually
          becomes feasible to address situations where the devices
          within an MPL domain subscribe to arbitrary IPv6 multicast
          addresses - not just ones that are based on the unicast
          prefix.

      

      

      Firstly, yes I agree the inner destination address should
      determine the application endpoint. What I'm not clear on is why
      we need an MPL domain to cover more than the LLN or why we need to
      support multiple MPL domains in one LLN. Tf the latter case is
      required to allow for different sets of MPL propagation
      parameters, then I'd imagine that should rather be handled by the
      HbH option.

    

    <RCC>It could be done that way but you are now introducing
    another "label" by which to determine forwarding when address scope
    an group ID seems perfectly adequate to me</RCC>

    

    
 
      - Dario

      

      

        


        

        
--

        
Jonathan Hui

        

        

          
On Nov 2, 2012, at 12:34 PM, Dario Tedeschi <dat=
@exegin.com>

            wrote:

          

          

            
On 01/11/2012 7:12 =
PM,
              Jonathan Hui (johui) wrote:
              

                
On Nov 1, 2012, at 6:47 PM, Dario Tedeschi=
 <dat@exegin.com> wrote:



                

                  
I don't understand what benefit is gaine=
d by allowing the use of non-link-local in the outer header, if encapsula=
tion is required. Supporting both link-local and higher in the outer head=
er just servers to complicate the forwarder.


                

                
The purpose is to limit the extent to whic=
h MPL disseminates a packet to something smaller than the entire LLN (ite=
m 2).

              

              

              Isn't that what multicast groups and/or
              unicast-prefix-based multicasts are for? That is to say,
              to reach a defined set of devices.

              

              

              

                

                  
Is item 2 a requirement that a subset of=
 devices in the LLN participate in MPL forwarding and others don't, or is=
 it that there are two MPL domains, or is it that one subset of devices a=
re listening on multicast address A while others are listening on multica=
st address B? In any case, I don't see how the use of link-local scope in=
 the *outer* header would not work.


                

                
As mentioned above, the purpose is to limi=
t the physical extent of MPL forwarders that disseminate a message.  If w=
e use a link-local destination address in the outer header, how do you pr=
opose to limit the region?

              

              

              The destination in the inner header determines if the
              packet needs to be forwarded or not, or forwarded on a
              different interface. 

              

              

              

                

                  
As for encapsulation, using an MPL multi=
cast address of the from FF02::00XX, in the outer header, would only add =
three bytes to the packet after 6lowpan compression.


                

                
I agree.

Maybe you could describe a concrete example of how using link-local addre=
sses in the outer header would address Peter's scenario that he posted to=
 the list?


              

              

              Example: Two border routers (BR1 and BR2) each forming a
              network:

              

              --- Network 1 (BR1) ---

              Unicast prefix: FD01::/64

              Unicast-prefix-based multicast address prefix:
              FF35:0040:FD01::/96

              

              --- Network 2 (BR2) ---

              Unicast prefix: FD02::/64

              Unicast-prefix-based multicast address prefix:
              FF35:0040:FD02::/96

              

              
    
                
  1. A non-MPL aware node in network 1 wishes to send a
                  multicast to all nodes in network 1. 
    2. 
                
  2. It sends to multicast address FF35:0040:FD01::1,
                  un-encapsulated. 
    3. 
                
  3. The packet is received by a MPL router in network 2
                  (N2R1). 
    4. 
                
  4. N2R1 finds no higher layer listening to
                  FF35:0040:FD01::1 and, therefore, does not pass the
                  packet up.
    
                
    5. 
                
  5. N2R1 finds no matching routing information for
                  FF35:0040:FD01::1 and does not forward the packet. The
                  packet is, therefore, discarded. 
    6. 
                
  6. The packet is also received by a MPL router in
                  network 1 (N1R1). 
    7. 
                
  7. N1R1 finds a higher layer listening to
                  FF35:0040:FD01::1 and passes a copy of the packet up.
                  Note: This would depend on whether or not any higher
                  layers were actually interested in the mc group. Also,
                  this step is not a prerequisite for the next step to
                  occur. 
    8. 
                
  8. N1R1 finds matching routing information for
                  FF35:0040:FD01::1, because it is a member of network
                  FD01::/64 
    9. 
                
  9. N1R1 encapsulates the packet with a MPL HbH option
                  such that the outer and inner destination addresses
                  appear as: [FF02::MPL][FF35:0040:FD01::1],
                  respectively. 
    10. 
                
  10. N1R1 transmits the new resulting packet. 
    11. 
                
  11. The packet is received by another MPL router in
                  network 1 (N1R2). 
    12. 
                
  12. Seeing that the destination address is FF02::MPL,
                  N1R2 decapsulates the packet (i.e. the original packet
                  exits the tunnel). 
    13. 
                
  13. N1R2 finds a higher layer listening to
                  FF35:0040:FD01::1 and passes a copy of the inner
                  packet up. Note: This step is not a prerequisite for
                  the next step to occur.
    
                
    14. 
                
  14. N1R2 also finds matching routing information for
                  FF35:0040:FD01::1, because it is a member of network
                  FD01::/64. 
    15. 
                
  15. N1R2 re-encapsulates the packet with the *original*
                  MPL HbH option such that the outer and inner
                  destination addresses appear as:
                  [FF02::MPL][FF35:0040:FD01::1], respectively. 
    16. 
                
  16. N1R2 transmits the resulting packet. 
    17. 
                
  17. The packet is received by yet another MPL router in
                  network 2 (N2R2). 
    18. 
                
  18. Seeing that the destination address is FF02::MPL,
                  N2R2 decapsulates the packet (i.e. the original packet
                  exits the tunnel). 
    19. 
                
  19. N2R2 finds no matching routing information or
                  listener for FF35:0040:FD01::1 and, therefore,
                  discards the packet.
    
                
    20. 
              

              

              Note:

              I chose a non-MPL aware originator of a multicast packet,
              because I wanted to be more thorough. I could have chosen
              an example where the originator of the packet *was* a MPL
              aware device. In such a case, it would have encapsulated
              with its own MPL HbH option as if it were forwarding the
              packet (i.e. outer and inner destinations would have been
              [FF02::MPL][FF35:0040:FD01::1]). One complication of
              non-MPL aware devices sending non-link-local multicasts is
              the problem of fan-out: If such a device
              multicasts/broadcasts at the link-layer for IPv6
              multicasts, then many MPL routers may hear the packet and
              try forward it with their own seeds. Although this
              wouldn't cause a real packet-storm, it would cause
              something close to it, depending on how many routers were
              in earshot of the originator. However, this is a general
              problem that has nothing to do with MPL's address scope.
              

              Secondly, notice that FF02::MPL can be viewed as a well
              defined address for a "tunnel exit point". It just so
              happens that it actually identifies multiple physical
              "exit points".

              

              - Dario

              

              

            

          

        

        

      

      

      

      

      

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


    

    

  


--------------010807040401010800020500--

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

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIILUDCC
BRowggQCoAMCAQICEG0Z6qcZT2ozIuYiMnqqcd4wDQYJKoZIhvcNAQEFBQAwga4xCzAJBgNV
BAYTAlVTMQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoT
FVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3Qu
Y29tMTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQg
RW1haWwwHhcNMTEwNDI4MDAwMDAwWhcNMjAwNTMwMTA0ODM4WjCBkzELMAkGA1UEBhMCR0Ix
GzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UE
ChMRQ09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENPTU9ETyBDbGllbnQgQXV0aGVudGlj
YXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC
ggEBAJKEhFtLV5jUXi+LpOFAyKNTWF9mZfEyTvefMn1V0HhMVbdClOD5J3EHxcZppLkyxPFA
GpDMJ1Zifxe1cWmu5SAb5MtjXmDKokH2auGj/7jfH0htZUOMKi4rYzh337EXrMLaggLW1DJq
1GdvIBOPXDX65VSAr9hxCh03CgJQU2yVHakQFLSZlVkSMf8JotJM3FLb3uJAAVtIaN3FSrTg
7SQfOq9xXwfjrL8UO7AlcWg99A/WF1hGFYE8aIuLgw9teiFX5jSw2zJ+40rhpVJyZCaRTqWS
D//gsWD9Gm9oUZljjRqLpcxCm5t9ImPTqaD8zp6Q30QZ9FxbNboW86eb/8ECAwEAAaOCAUsw
ggFHMB8GA1UdIwQYMBaAFImCZ33EnSZwAEu0UEh83j2uBG59MB0GA1UdDgQWBBR6E04AdFvG
eGNkJ8Ev4qBbvHnFezAOBgNVHQ8BAf8EBAMCAQYwEgYDVR0TAQH/BAgwBgEB/wIBADARBgNV
HSAECjAIMAYGBFUdIAAwWAYDVR0fBFEwTzBNoEugSYZHaHR0cDovL2NybC51c2VydHJ1c3Qu
Y29tL1VUTi1VU0VSRmlyc3QtQ2xpZW50QXV0aGVudGljYXRpb25hbmRFbWFpbC5jcmwwdAYI
KwYBBQUHAQEEaDBmMD0GCCsGAQUFBzAChjFodHRwOi8vY3J0LnVzZXJ0cnVzdC5jb20vVVRO
QWRkVHJ1c3RDbGllbnRfQ0EuY3J0MCUGCCsGAQUFBzABhhlodHRwOi8vb2NzcC51c2VydHJ1
c3QuY29tMA0GCSqGSIb3DQEBBQUAA4IBAQCF1r54V1VtM39EUv5C1QaoAQOAivsNsv1Kv/av
QUn1G1rF0q0bc24+6SZ85kyYwTAo38v7QjyhJT4KddbQPTmGZtGhm7VNm2+vKGwdr+XqdFqo
2rHA8XV6L566k3nK/uKRHlZ0sviN0+BDchvtj/1gOSBH+4uvOmVIPJg9pSW/ve9g4EnlFsjr
P0OD8ODuDcHTzTNfm9C9YGqzO/761Mk6PB/tm/+bSTO+Qik5g+4zaS6CnUVNqGnagBsePdIa
XXxHmaWbCG0SmYbWXVcHG6cwvktJRLiQfsrReTjrtDP6oDpdJlieYVUYtCHVmdXgQ0BCML7q
peeU0rD+83X5f27nMIIGLjCCBRagAwIBAgIQXDFQ28QtqMuYch5f2nTvZjANBgkqhkiG9w0B
AQUFADCBkzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4G
A1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENP
TU9ETyBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTAeFw0xMTA5
MDIwMDAwMDBaFw0xNDA5MDEyMzU5NTlaMIIBNzELMAkGA1UEBhMCR0IxEDAOBgNVBBETB1dG
NCA0V0ExFzAVBgNVBAgTDldlc3QgWW9ya3NoaXJlMRIwEAYDVQQHEwlXYWtlZmllbGQxFDAS
BgNVBAkTC0dyYW5nZSBNb29yMR8wHQYDVQQJExY4OSBHcmVlbmZpZWxkIENyZXNjZW50MRcw
FQYDVQQKEw5HcmlkbWVyZ2UgTHRkLjE0MDIGA1UECxMrSXNzdWVkIHRocm91Z2ggR3JpZG1l
cmdlIEx0ZC4gRS1QS0kgTWFuYWdlcjEfMB0GA1UECxMWQ29ycG9yYXRlIFNlY3VyZSBFbWFp
bDEWMBQGA1UEAxMNUm9iZXJ0IENyYWdpZTEqMCgGCSqGSIb3DQEJARYbcm9iZXJ0LmNyYWdp
ZUBncmlkbWVyZ2UuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEArcThqvLe
WU1Q1ZJmnb+2UQSwOQKWok3A1Mwk582AdvwaAQyBFliPyJ0kXJqtwNBoZvk+3WJr0QA5ZRr+
J0x3sXVpcxadojP2HNzy1gsgDtIGG8ltoU4vmX1A8BTlOIUT+Pg8p/bSruxV0vz0CR8ho2hs
R0Zi5vU+rQKNmbgufbkWhlQnMEYjknemscLQfw1YZz90ta67doNDujFy6+X6I06HpjudgMYx
8bdsNS5xVFFwuBA1eqNQra+xLzhCOeX9PPB/zK68qdNhrni3WPYG9EhSt4Dzk+xIz9hj7wrU
ZIVXDTPsY8qbUSBVpwmzI5lCHPgzurH1OK7WwgpDSsl5pwIDAQABo4IB1TCCAdEwHwYDVR0j
BBgwFoAUehNOAHRbxnhjZCfBL+KgW7x5xXswHQYDVR0OBBYEFBCOXNH+lDm8U9gy3b3bRvrx
vKgrMA4GA1UdDwEB/wQEAwIFoDAMBgNVHRMBAf8EAjAAMB0GA1UdJQQWMBQGCCsGAQUFBwME
BggrBgEFBQcDAjBGBgNVHSAEPzA9MDsGDCsGAQQBsjEBAgEDBTArMCkGCCsGAQUFBwIBFh1o
dHRwczovL3NlY3VyZS5jb21vZG8ubmV0L0NQUzBXBgNVHR8EUDBOMEygSqBIhkZodHRwOi8v
Y3JsLmNvbW9kb2NhLmNvbS9DT01PRE9DbGllbnRBdXRoZW50aWNhdGlvbmFuZFNlY3VyZUVt
YWlsQ0EuY3JsMIGIBggrBgEFBQcBAQR8MHowUgYIKwYBBQUHMAKGRmh0dHA6Ly9jcnQuY29t
b2RvY2EuY29tL0NPTU9ET0NsaWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5j
cnQwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmNvbW9kb2NhLmNvbTAmBgNVHREEHzAdgRty
b2JlcnQuY3JhZ2llQGdyaWRtZXJnZS5jb20wDQYJKoZIhvcNAQEFBQADggEBAD6b/O0LkPav
kR4Znoqxg0Ad7M3duDm4uzfrlX4ecgq56Ccdwd+3Tayz7Ewej30woVMmTKkA/NKRaCd0wVM9
8seF/oZjXKO7o1SH27igRnGSWjCoWXsdwJGfZbYnvcIIhhsxJoCPNbeSR7C0PAFDKsP3xrJy
MHMljIJsoRbZu/fnYNyFWh9OXf7fYJOGmKDKAhSabUGfhY7umvU9d/YTqo02Q6YzC7d4zPNG
1a75AuHSEchf6GdKqycG38I5y9jlDaYfXspoS3PlTNCIeZONbOSMZgftnNEVKq+SWytFqyG/
8+dwpm/a12KMex5J8iHwaUKj++2O2rAFNjDDqXpeEYoxggQZMIIEFQIBATCBqDCBkzELMAkG
A1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9y
ZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENPTU9ETyBDbGllbnQg
QXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIQXDFQ28QtqMuYch5f2nTvZjAJ
BgUrDgMCGgUAoIICRTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP
Fw0xMjExMDgyMzU1NTNaMCMGCSqGSIb3DQEJBDEWBBTRshb7LfnozKxcoRvpsyG5JNt4CTBs
BgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcw
DgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEo
MIG5BgkrBgEEAYI3EAQxgaswgagwgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVy
IE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1p
dGVkMTkwNwYDVQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUg
RW1haWwgQ0ECEFwxUNvELajLmHIeX9p072YwgbsGCyqGSIb3DQEJEAILMYGroIGoMIGTMQsw
CQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxm
b3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVu
dCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhBcMVDbxC2oy5hyHl/adO9m
MA0GCSqGSIb3DQEBAQUABIIBAGVY7oesvFn5hVoVrwW9T2frqjLbwVZqM8fbz4r7mgiwsmep
Mer16s2rE06YEwUbbcFwkyW+vSKrcnmJnsbYXvUvAwe6pBwYPdVycIP4Z9LUtujxGC2qIORW
C5oopr0/WZ3aP+SXPht8q0KgpBA+1AO0MYCwqenCHpNRwUG/EtcLWHhzNUXZ4kUooyBA1P2J
yXvdpwrrBeXC2kiwMMBqL9WAGCaO7m62m7gCQ1OhSzLriFHnVR3rOFbA4qKF2jeMjbdyXO52
Rgorw1LfoYftUYjinJAGZtMKn+iifP6/zhts+YREKstAVKDygJeRbcJ16SI43ZlhWpho1D38
0u2YVPsAAAAAAAA=
--------------ms070906050400000801060504--

From dat@exegin.com  Thu Nov  8 17:40:01 2012
Return-Path: 
X-Original-To: roll@ietfa.amsl.com
Delivered-To: roll@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B483321F8628 for ; Thu,  8 Nov 2012 17:40:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.254
X-Spam-Level: 
X-Spam-Status: No, score=-3.254 tagged_above=-999 required=5 tests=[AWL=0.345,  BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tdRriQf4Stgx for ; Thu,  8 Nov 2012 17:40:00 -0800 (PST)
Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id B308021F8626 for ; Thu,  8 Nov 2012 17:40:00 -0800 (PST)
Received: by mail-pb0-f44.google.com with SMTP id ro8so2620077pbb.31 for ; Thu, 08 Nov 2012 17:40:00 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding :x-gm-message-state; bh=CfTdtHbkmVecDGukHBZZha98FHJeH23S7ctqUvSes78=; b=NlV2s5RyzRFRmLon48XidT2fEiBMaNi35kEjNh1uOknFlndYdnnNcSKEMEYk/ouLIR b0Vym6aKZP0Mk8W6gtHzWO8vaf2Pj4GffxzCq5e32nywN4n+gAlgmk3XGIPePpCPiGH7 +OL3C4I/LV+MrBbIoIVKfW1zEVS5DSLEw/crn33i+dQEUZWRgy9U3s8RS0oQaeUhxhG+ 5uReflIa8sjKo0Rs0XhrQcpsAnhKU/0MgdPO0um2+b0IXCQQMk7dy73NS0ScsYpB6C6U k4uyYrN5OSDxdhmK8pnOeX6q2bJLrTjqkc/3O/05yUu9X2jVcpFQ8gdfRkBB9lkbdXvq fXUw==
Received: by 10.66.85.69 with SMTP id f5mr27332316paz.50.1352425200460; Thu, 08 Nov 2012 17:40:00 -0800 (PST)
Received: from [172.16.1.52] ([184.71.143.130]) by mx.google.com with ESMTPS id o5sm17012737paz.32.2012.11.08.17.39.58 (version=SSLv3 cipher=OTHER); Thu, 08 Nov 2012 17:39:59 -0800 (PST)
Message-ID: <509C5F00.2050204@exegin.com>
Date: Thu, 08 Nov 2012 17:40:16 -0800
From: Dario Tedeschi 
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:7.0) Gecko/20110922 Thunderbird/7.0
MIME-Version: 1.0
To: "Jonathan Hui (johui)" 
References: <058.e817419e990e1afb26be9aa25d5cfc21@trac.tools.ietf.org>  <50932647.3050509@exegin.com>  <5094202F.4010805@exegin.com>  <509C03C2.50809@exegin.com> 
In-Reply-To: 
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: quoted-printable
X-Gm-Message-State: ALoCoQnMQ70XzTgVP6jT8RJZQiQbeeT2V6b1PO0ElmdAAyq8QrebrGpSpgX5R0V6o6JJNWQbzCiB
Cc: "" , "" , "" 
Subject: Re: [Roll] [roll] #105: trickle-mcast: how to determine scope of MPL domain
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Routing Over Low power and Lossy networks 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 09 Nov 2012 01:40:01 -0000

On 08/11/2012 1:02 PM, Jonathan Hui (johui) wrote:
> Hi Dario,
>
> On Nov 8, 2012, at 11:10 AM, Dario Tedeschi  wrote:
>
>> On 02/11/2012 10:18 PM, Jonathan Hui (johui) wrote:
>>> With your approach (require link-local in the outer header), the IPv6=
 multicast address identifies the application endpoints *and* the MPL dom=
ain.  For that reason, your approach really only needs a single identifie=
r to both limit the flooding scope and determine the application endpoint=
s.
>> It depends on what you mean by MPL domain. In my view,  FF02::MPL iden=
tifies the MPL domain, while the inner IPv6 destination address identifie=
s the application endpoint.
> Let me introduce a new term to help move the discussion forward:  Disse=
mination Region - a connected set of MPL devices that attempt to forward =
the packet so that all devices receive the packet at least once.  Another=
 definition may be: a region within which the SeedID must be unique.

OK, that makes sense to me.

>
>>>   I can see how that would work (as you demonstrated) if we make the =
restriction that the IPv6 multicast addresses used within an MPL domain h=
ave the same prefix that identifies the MPL domain itself.  The trouble c=
omes when you want to support the full generality that IPv6 multicast add=
resses used by application endpoints can be arbitrary.
>> The "generality", you talk of, is why protocols like MLD exist. MLD in=
forms routers of mc addresses other devices are interested in. Essentiall=
y it provides routing information. How could we support the "full general=
ity" of mc addresses without this information (whether implied or from so=
mething like MLD).  With this in mind, I don't understand the need for no=
n-link-local scope in the outer header, because the "generality" you seek=
 would be determined by the mc address of the original packet (i.e. the m=
c address of the inner header). All my approach is really saying is that =
only the original/inner mc address determines how far a packet will propa=
gate, regardless of routing domain. MPL could just be one of many routing=
 domains a mc packet must traverse before reaching its furthermost bounda=
ry. Or MPL may be the only routing domain, where the mc packet only reach=
es a sub-set of devices within the domain (i.e. a multicast group or a se=
t based on unicast-prefix-based mc).
> The original intent of MPL was to avoid any routing information within =
the Dissemination Region.  A router then only maintains state about what =
multicast addresses are of interest to devices within the Dissemination R=
egion.

Yes I understand, but I'm not sure how we can avoid routing information, =

if we are to support sending to sub-sets of devices within one LLN=20
(whether we use non-link-local or link-local in the outer header). To me =

it sounds like we are trying to offer what a storing network provides=20
without actually storing any information on the routers. For unicasts,=20
in RPL, this done by offloading the burden of storing routing=20
information onto the RPL root node (i.e. source-routing). This works for =

unicasts, but it wouldn't work for multicasts.


>
>>> For example, how does MPL support an application that subscribes to a=
 well-known non-link-local IPv6 multicast address?  I guess one approach =
is to say that if the IPv6 multicast address is not a unicast-prefix-base=
d multicast address, then it disseminates across the entire region of con=
nected MPL forwarders.
>> Granted one could have a situation where all routers hear an mc packet=
 that is only intended for a subset of devices, but that does not mean al=
l routers need to forward that packet or pass it to a higher layer. Again=
, this would depend on the inner mc address and the routing information a=
vailable to routers. The routers without the appropriate routing informat=
ion would not forward. Similarly, routers without mc membership informati=
on from an app would not pass the packet to the next higher layer.
> We have different thoughts on how a device determines whether or not to=
 forward the packet.  You take a routing perspective, where a device dete=
rmines whether or not to forward based on the identifier for the applicat=
ion endpoints.  In contrast, I view it as a device determines whether or =
not to forward based on the Dissemination Region it is in.  Note that in =
my view, the Dissemination Region does not have to have any relationship =
with the identifier for application endpoints.  In other words, you can c=
onfigure the Dissemination Region without any knowledge of the multicast =
addresses that devices are interested in.

OK I  see your point of view more clearly now. I assume then that a=20
Dissemination Region would be defined by a non-link-local mc address=20
prefix, and if so, how would MPL routers become aware of it? Without it=20
how would a router be able to differentiate one Dissemination Region=20
from another?


>
>>> One minor point with your approach is that the delivery requires proc=
essing the MPL Option of the outer header and the inner IPv6 header.  Tha=
t isn't so nice from an architectural perspective, but that is what we di=
d with RFC 6553.
>> Using non-link-local in the outer header does not mitigate that. The f=
orwarder still needs to look at the inner header to determine if the inne=
r mc address is one an app is listening on. In fact implementing this is =
a bit messy compared to my approach, because the forwarder has to look ah=
ead into the packet before decapsulating. My approach always requires dec=
apsulation before making any decision about where the packet must go next=
=2E It's simpler and more consistent. I've actually had the fortune/misfo=
rtune of implementing both and I can safely say the link-local approach w=
as cleaner.
> I'd argue that using non-link-local in the outer header helps to preser=
ve the layering.
> 1) Processing the outer header allows a device to determine whether it =
is a part of the Dissemination Region and the packet was received before.=

> 2) Processing the inner header allows a device to determine whether it =
should process the payload.
>
> Can you explain why a device needs to "look ahead" into the packet befo=
re decapsulating when using a non-link-local outer header?

Lets say the packet has outer and inner destination addresses=20
[FF05::1234] and [FF05::5678], respectively. An app on a device=20
receiving this packet, might be interested in [FF05::1234] or=20
[FF05::5678] or both. Which version of the packet gets passed up: The=20
entire MPL encapsulated one or just the inner packet or both. To get=20
around this, I had to add a hack that would do two things:
1. If the network device is a member of [FF05::1234] and there is no=20
IPv6-in-IPv6 encapsulation, then pass the packet up.
2. If there is IPv6-in-IPv6 encapsulation and there is a MPL HbH option=20
and the network device is a member of [FF05::5678], then decapsulate and =

pass the inner packet up.

Note that logic 2. required looking ahead at the inner header to=20
determine if the mc address there was an address some higher layer was=20
interested in. What made things even less palatable, was having to skip=20
over potential extended headers just to determine whether or not the=20
packet was encapsulated. Aside from passing mc packets up, the hack was=20
also needed to decrement the hop-limit when forwarding.

Back then, there was no idea of having an IANA assigned MPL mc-group so=20
I could not rely on a well-known non-link-local address. With a=20
well-known MPL address a MPL router would be able to be a member of that =

group and always try decapsulate upon hearing a packet destined for that =

address. Without this MPL mc address using the link-local all-routers mc =

address, removed the need for the hack. This was because all routers are =

members of the all-routers group.



>
>>> In my approach (allow non-link-local in the outer header), I tried to=
 separate out the identifiers for the application endpoints and the MPL d=
omain.  That is why I used the outer header's destination address to iden=
tify the MPL domain and the inner header's destination address to identif=
y the application endpoints.  With this approach, it actually becomes fea=
sible to address situations where the devices within an MPL domain subscr=
ibe to arbitrary IPv6 multicast addresses - not just ones that are based =
on the unicast prefix.
>> Firstly, yes I agree the inner destination address should determine th=
e application endpoint. What I'm not clear on is why we need an MPL domai=
n to cover more than the LLN or why we need to support multiple MPL domai=
ns in one LLN. Tf the latter case is required to allow for different sets=
 of MPL propagation parameters, then I'd imagine that should rather be ha=
ndled by the HbH option.
> Peter's use case involves having multiple Dissemination Regions within =
a single IEEE 802.15.4 PAN.  I agree, one could argue whether the devices=
 should all be within the same PAN or different PANs based on the nearest=
 border router.

  Or an argument for having multiple Destination Regions identified by=20
some field in the HbH option.


>
> During the WG meeting, people made a good argument that we actually don=
't know the answer - either because all the use cases are not obvious or =
because we don't understand all the consequences of each approach.  One p=
roposal was to have the draft specify well-defined forwarding behavior th=
at supports both situations.  For example:
> 1) If the outer header has an IPv6 Destination Address matching the lin=
k-local all-MPL-forwarders address, do =85
> 2) Otherwise, do =85
>
> Then leave it up to those who are using this spec to determine what sub=
set they want to use.  Not sure if this is a reasonable approach and woul=
d like to get feedback from the WG.

My current implementation is just such a hybrid, except that action 1 is =

decided by scope and not the full address. From an implementation point=20
of view, I'd prefer not to have two code paths, but if it satisfies=20
everyone's needs and we have an IANA assigned address, I can live with=20
it. :-)

- Dario





From stokcons@xs4all.nl  Fri Nov  9 06:24:23 2012
Return-Path: 
X-Original-To: roll@ietfa.amsl.com
Delivered-To: roll@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 337B121F85C3 for ; Fri,  9 Nov 2012 06:24:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.504
X-Spam-Level: 
X-Spam-Status: No, score=-0.504 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MG4QVOSQM8LP for ; Fri,  9 Nov 2012 06:24:22 -0800 (PST)
Received: from smtp-vbr14.xs4all.nl (smtp-vbr14.xs4all.nl [194.109.24.34]) by ietfa.amsl.com (Postfix) with ESMTP id 891D521F8546 for ; Fri,  9 Nov 2012 06:24:20 -0800 (PST)
Received: from roundcube.xs4all.nl (roundcube6.xs4all.net [194.109.20.204]) by smtp-vbr14.xs4all.nl (8.13.8/8.13.8) with ESMTP id qA9ENmYT015384 for ; Fri, 9 Nov 2012 15:23:49 +0100 (CET) (envelope-from stokcons@xs4all.nl)
Received: from dhcp-460a.meeting.ietf.org ([130.129.70.10]) by roundcube.xs4all.nl with HTTP (HTTP/1.1 POST); Fri, 09 Nov 2012 15:23:48 +0100
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="=_1d9a47692d3c983232d0cf038d8f7aac"
Date: Fri, 09 Nov 2012 15:23:48 +0100
From: peter van der Stok 
To: 
Organization: vanderstok consultancy
Mail-Reply-To: 
In-Reply-To: <509C5F00.2050204@exegin.com>
References: <058.e817419e990e1afb26be9aa25d5cfc21@trac.tools.ietf.org>  <50932647.3050509@exegin.com>  <5094202F.4010805@exegin.com>  <509C03C2.50809@exegin.com>  <509C5F00.2050204@exegin.com>
Message-ID: <109e9168af966b0ee543f13886fef7ef@xs4all.nl>
X-Sender: stokcons@xs4all.nl (NohYZmvFajPIWNR084SExFHPLL8U3IXM)
User-Agent: XS4ALL Webmail
X-Virus-Scanned: by XS4ALL Virus Scanner
Subject: Re: [Roll] [roll] #105: trickle-mcast: how to determine scope of MPL domain
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: consultancy@vanderstok.org
List-Id: Routing Over Low power and Lossy networks 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 09 Nov 2012 14:24:23 -0000

--=_1d9a47692d3c983232d0cf038d8f7aac
Content-Transfer-Encoding: 8bit
Content-Type: text/plain; charset=UTF-8;
 format=flowed


Hi Jonathan, Dario, Robert and all,

Given the discussion it is may be helpful when I elaborate a bit my 
example use case. For that purpose I have added a drawing in the PDF 
format (I apologize for the choice of PDF).
The  example does not represent an existing building, but is close 
enough to reality to warrant a look. I am sure that when IP-based 
wireless building control becomes successful more interesting and 
challenging examples will appear.
The drawing represents an office floor with a corridor in the middle. 
On both sides 3 areas are drawn representing open plan offices. I 
covered each open plan office and the corridor with one dissemination 
area (term proposed by Jonathan). Each dissemination area is covered by 
one network and one border router (as proposed by dario)
Example: 6 border routers (BR1,  BR2, BR3, …) each forming a network:

--- Network 1 (BR1) ---
Unicast prefix: FD01::/64
Unicast-prefix-based multicast address prefix: FF35:0040:FD01::/96

--- Network 2 (BR2) ---
Unicast prefix: FD02::/64
Unicast-prefix-based multicast address prefix: FF35:0040:FD02::/96

ETC.

The nodes in all networks use the same communication channel.
For example, imagine the following scenario. A sensor in dissemination 
area 1 multicasts a message, m, to a set of nodes within dissemination 
area1.  Some forwarders in dissemination areas2-6 receive the multicast 
message as well. Because there are no destinations for the multicast 
message in dissemination areas2-6, it is better for the network load if 
the forwarders in dissemination areas2-6 do not forward the message.
In this network configuration the dissemination area is identical with 
a network.
 From a cost perspective (less border routers) it is more realistic if 
one network covers the whole floor. However, for the same reason as 
cited earlier, forwarders in dissemination areas2-6 should not forward 
messages originating in dissemination area 1.
I hope this helps
peter

Dario Tedeschi schreef op 2012-11-09 02:40:
> On 08/11/2012 1:02 PM, Jonathan Hui (johui) wrote:
>> Hi Dario,
>>
>> On Nov 8, 2012, at 11:10 AM, Dario Tedeschi  wrote:
>>
>>> On 02/11/2012 10:18 PM, Jonathan Hui (johui) wrote:
>>>> With your approach (require link-local in the outer header), the 
>>>> IPv6 multicast address identifies the application endpoints *and* 
>>>> the MPL domain.  For that reason, your approach really only needs a 
>>>> single identifier to both limit the flooding scope and determine the 
>>>> application endpoints.
>>> It depends on what you mean by MPL domain. In my view,  FF02::MPL 
>>> identifies the MPL domain, while the inner IPv6 destination address 
>>> identifies the application endpoint.
>> Let me introduce a new term to help move the discussion forward:  
>> Dissemination Region - a connected set of MPL devices that attempt to 
>> forward the packet so that all devices receive the packet at least 
>> once.  Another definition may be: a region within which the SeedID 
>> must be unique.
>
> OK, that makes sense to me.
>
>>
>>>>   I can see how that would work (as you demonstrated) if we make 
>>>> the restriction that the IPv6 multicast addresses used within an MPL 
>>>> domain have the same prefix that identifies the MPL domain itself.  
>>>> The trouble comes when you want to support the full generality that 
>>>> IPv6 multicast addresses used by application endpoints can be 
>>>> arbitrary.
>>> The "generality", you talk of, is why protocols like MLD exist. MLD 
>>> informs routers of mc addresses other devices are interested in. 
>>> Essentially it provides routing information. How could we support the 
>>> "full generality" of mc addresses without this information (whether 
>>> implied or from something like MLD).  With this in mind, I don't 
>>> understand the need for non-link-local scope in the outer header, 
>>> because the "generality" you seek would be determined by the mc 
>>> address of the original packet (i.e. the mc address of the inner 
>>> header). All my approach is really saying is that only the 
>>> original/inner mc address determines how far a packet will propagate, 
>>> regardless of routing domain. MPL could just be one of many routing 
>>> domains a mc packet must traverse before reaching its furthermost 
>>> boundary. Or MPL may be the only routing domain, where the mc packet 
>>> only reaches a sub-set of devices within the domain (i.e. a multicast 
>>> group or a set based on unicast-prefix-based mc).
>> The original intent of MPL was to avoid any routing information 
>> within the Dissemination Region.  A router then only maintains state 
>> about what multicast addresses are of interest to devices within the 
>> Dissemination Region.
>
> Yes I understand, but I'm not sure how we can avoid routing
> information, if we are to support sending to sub-sets of devices
> within one LLN (whether we use non-link-local or link-local in the
> outer header). To me it sounds like we are trying to offer what a
> storing network provides without actually storing any information on
> the routers. For unicasts, in RPL, this done by offloading the burden
> of storing routing information onto the RPL root node (i.e.
> source-routing). This works for unicasts, but it wouldn't work for
> multicasts.
>
>
>>
>>>> For example, how does MPL support an application that subscribes 
>>>> to a well-known non-link-local IPv6 multicast address?  I guess one 
>>>> approach is to say that if the IPv6 multicast address is not a 
>>>> unicast-prefix-based multicast address, then it disseminates across 
>>>> the entire region of connected MPL forwarders.
>>> Granted one could have a situation where all routers hear an mc 
>>> packet that is only intended for a subset of devices, but that does 
>>> not mean all routers need to forward that packet or pass it to a 
>>> higher layer. Again, this would depend on the inner mc address and 
>>> the routing information available to routers. The routers without the 
>>> appropriate routing information would not forward. Similarly, routers 
>>> without mc membership information from an app would not pass the 
>>> packet to the next higher layer.
>> We have different thoughts on how a device determines whether or not 
>> to forward the packet.  You take a routing perspective, where a device 
>> determines whether or not to forward based on the identifier for the 
>> application endpoints.  In contrast, I view it as a device determines 
>> whether or not to forward based on the Dissemination Region it is in.  
>> Note that in my view, the Dissemination Region does not have to have 
>> any relationship with the identifier for application endpoints.  In 
>> other words, you can configure the Dissemination Region without any 
>> knowledge of the multicast addresses that devices are interested in.
>
> OK I  see your point of view more clearly now. I assume then that a
> Dissemination Region would be defined by a non-link-local mc address
> prefix, and if so, how would MPL routers become aware of it? Without
> it how would a router be able to differentiate one Dissemination
> Region from another?
>
>
>>
>>>> One minor point with your approach is that the delivery requires 
>>>> processing the MPL Option of the outer header and the inner IPv6 
>>>> header.  That isn't so nice from an architectural perspective, but 
>>>> that is what we did with RFC 6553.
>>> Using non-link-local in the outer header does not mitigate that. 
>>> The forwarder still needs to look at the inner header to determine if 
>>> the inner mc address is one an app is listening on. In fact 
>>> implementing this is a bit messy compared to my approach, because the 
>>> forwarder has to look ahead into the packet before decapsulating. My 
>>> approach always requires decapsulation before making any decision 
>>> about where the packet must go next. It's simpler and more 
>>> consistent. I've actually had the fortune/misfortune of implementing 
>>> both and I can safely say the link-local approach was cleaner.
>> I'd argue that using non-link-local in the outer header helps to 
>> preserve the layering.
>> 1) Processing the outer header allows a device to determine whether 
>> it is a part of the Dissemination Region and the packet was received 
>> before.
>> 2) Processing the inner header allows a device to determine whether 
>> it should process the payload.
>>
>> Can you explain why a device needs to "look ahead" into the packet 
>> before decapsulating when using a non-link-local outer header?
>
> Lets say the packet has outer and inner destination addresses
> [FF05::1234] and [FF05::5678], respectively. An app on a device
> receiving this packet, might be interested in [FF05::1234] or
> [FF05::5678] or both. Which version of the packet gets passed up: The
> entire MPL encapsulated one or just the inner packet or both. To get
> around this, I had to add a hack that would do two things:
> 1. If the network device is a member of [FF05::1234] and there is no
> IPv6-in-IPv6 encapsulation, then pass the packet up.
> 2. If there is IPv6-in-IPv6 encapsulation and there is a MPL HbH
> option and the network device is a member of [FF05::5678], then
> decapsulate and pass the inner packet up.
>
> Note that logic 2. required looking ahead at the inner header to
> determine if the mc address there was an address some higher layer 
> was
> interested in. What made things even less palatable, was having to
> skip over potential extended headers just to determine whether or not
> the packet was encapsulated. Aside from passing mc packets up, the
> hack was also needed to decrement the hop-limit when forwarding.
>
> Back then, there was no idea of having an IANA assigned MPL mc-group
> so I could not rely on a well-known non-link-local address. With a
> well-known MPL address a MPL router would be able to be a member of
> that group and always try decapsulate upon hearing a packet destined
> for that address. Without this MPL mc address using the link-local
> all-routers mc address, removed the need for the hack. This was
> because all routers are members of the all-routers group.
>
>
>
>>
>>>> In my approach (allow non-link-local in the outer header), I tried 
>>>> to separate out the identifiers for the application endpoints and 
>>>> the MPL domain.  That is why I used the outer header's destination 
>>>> address to identify the MPL domain and the inner header's 
>>>> destination address to identify the application endpoints.  With 
>>>> this approach, it actually becomes feasible to address situations 
>>>> where the devices within an MPL domain subscribe to arbitrary IPv6 
>>>> multicast addresses - not just ones that are based on the unicast 
>>>> prefix.
>>> Firstly, yes I agree the inner destination address should determine 
>>> the application endpoint. What I'm not clear on is why we need an MPL 
>>> domain to cover more than the LLN or why we need to support multiple 
>>> MPL domains in one LLN. Tf the latter case is required to allow for 
>>> different sets of MPL propagation parameters, then I'd imagine that 
>>> should rather be handled by the HbH option.
>> Peter's use case involves having multiple Dissemination Regions 
>> within a single IEEE 802.15.4 PAN.  I agree, one could argue whether 
>> the devices should all be within the same PAN or different PANs based 
>> on the nearest border router.
>
>  Or an argument for having multiple Destination Regions identified by
> some field in the HbH option.
>
>
>>
>> During the WG meeting, people made a good argument that we actually 
>> don't know the answer - either because all the use cases are not 
>> obvious or because we don't understand all the consequences of each 
>> approach.  One proposal was to have the draft specify well-defined 
>> forwarding behavior that supports both situations.  For example:
>> 1) If the outer header has an IPv6 Destination Address matching the 
>> link-local all-MPL-forwarders address, do …
>> 2) Otherwise, do …
>>
>> Then leave it up to those who are using this spec to determine what 
>> subset they want to use.  Not sure if this is a reasonable approach 
>> and would like to get feedback from the WG.
>
> My current implementation is just such a hybrid, except that action 1
> is decided by scope and not the full address. From an implementation
> point of view, I'd prefer not to have two code paths, but if it
> satisfies everyone's needs and we have an IANA assigned address, I 
> can
> live with it. :-)
>
> - Dario
>
>
>
>
> _______________________________________________
> Roll mailing list
> Roll@ietf.org
> https://www.ietf.org/mailman/listinfo/roll

--=_1d9a47692d3c983232d0cf038d8f7aac
Content-Transfer-Encoding: base64
Content-Type: application/pdf;
 name=mcast-example.pdf
Content-Disposition: attachment;
 filename=mcast-example.pdf

JVBERi0xLjUNCiW1tbW1DQoxIDAgb2JqDQo8PC9UeXBlL0NhdGFsb2cvUGFnZXMgMiAwIFIvTGFu
Zyhlbi1VUykgL1N0cnVjdFRyZWVSb290IDEyIDAgUi9NYXJrSW5mbzw8L01hcmtlZCB0cnVlPj4+
Pg0KZW5kb2JqDQoyIDAgb2JqDQo8PC9UeXBlL1BhZ2VzL0NvdW50IDEvS2lkc1sgMyAwIFJdID4+
DQplbmRvYmoNCjMgMCBvYmoNCjw8L1R5cGUvUGFnZS9QYXJlbnQgMiAwIFIvUmVzb3VyY2VzPDwv
WE9iamVjdDw8L0ltYWdlNSA1IDAgUi9JbWFnZTEwIDEwIDAgUj4+L0ZvbnQ8PC9GMSA2IDAgUj4+
L0V4dEdTdGF0ZTw8L0dTOCA4IDAgUi9HUzkgOSAwIFI+Pi9Qcm9jU2V0Wy9QREYvVGV4dC9JbWFn
ZUIvSW1hZ2VDL0ltYWdlSV0gPj4vTWVkaWFCb3hbIDAgMCA3MjAgNTQwXSAvQ29udGVudHMgNCAw
IFIvR3JvdXA8PC9UeXBlL0dyb3VwL1MvVHJhbnNwYXJlbmN5L0NTL0RldmljZVJHQj4+L1RhYnMv
Uy9TdHJ1Y3RQYXJlbnRzIDA+Pg0KZW5kb2JqDQo0IDAgb2JqDQo8PC9GaWx0ZXIvRmxhdGVEZWNv
ZGUvTGVuZ3RoIDEzMDI+Pg0Kc3RyZWFtDQp4nKVZ204cORB9H2n+oR57ImFc5bsU5YHLRllt9kKQ
9gHygMiAZiNAC6z4/S339Azupt3dboQ0jJCryj6nLscGDv+Ejx8Pvx5/OQH56RMcnRzDv8uFBCmk
lEgkHTiSYLSEx/Vy8fcHuF8uEG73a6S0KHVr0c2H5eKv5QJOvx4DJAFwcoD4l/ijLH8Ydn99t1wc
frm7ul0bOHmAPu/UeJfCOMWfHtlYKNTwyLtFLVAZCEF4dko+CHSAkgTSfs8EL7wzYUw0t8bET+fh
7DNHQ/gHRp1869mWarZ1dM4n+AWB+OBWw/lNhDGeEcE7YQG1Euz7/C6CU8PLYS+qk83T6oCqp/Xd
5v7qefNwDytSlV59h/Nfl4tTdhod7zwRBRF06uuigmTtm93pQdCU9CK43XkxkGA4OqD14zVq2geV
SaDanUgpLYgG0TEVf6iqRihi9bxZ6SoChb4yGaC0s8KUAGUHgTLSCU2zgBoz7QPK9QBlFAnry9LI
ZtCxzghJBej4EXSMIK4XQyJQKTrDpn3ohJ6KaxecURyOgAInQT9UmqGKSZXAhZXKwkXC28TdCFoo
p1TdHLjGTPvgQsyXXQahiMymLrp95cXfNVIxzWq0aLj0pqNFh79d3d9C9WN9cHK66pDL/c62uLXB
RLqRz6x14x8zW3GScbTttcN7UXvmfI18UJGFwFwkQ4YkMplgveVWDwaZHzvG3JhpL3N6fLaQNyJ4
IAzCUnn/dDkSyQs+euJ2DDkzZTw3ids/nkeQy5n2ImdHe0Q9lEs7RC7Rmrk8Pefdq1Q6/PzNw+1T
PD/xHvco8JlrZXLhwcJ3DgM/4BUML6ytUeA04qjKhx0YvcrMt+KF6fFw20lL44WZ8UhaEbA4HsmZ
8ZTkEVgeDueGYxlgwy5eE2hCPJoZT7Nv6cvPp2bGMzyRtCuPp+em516wh6hnJscz7yuH4nj2feVQ
HM+9qxyKw83tLk05FMeb212aciiNp+Z2l6YciuNhZ3pp/WZ68Xjm24A2PGJ3yuaPmxWG6mZzXU97
yI0qrhln2pb36+eXh8ef0Q6uH+5vNrdRJ/z3yIMvfonDL6OMtRG6s43BwaeSTnbQvC9Ir0PzXOAV
Ys9zAYtVxi+GJI4nkXWaF96Bsop1QvJ4gDL3eqC693RWDymgyCKRU0MF/XqS39fPEZKXFTIG8dvj
TxZNUQVEoFa+uqyOzrqSoF9tYFQGtu3+cpWjiKuQOnsZRjXpnztQ0dtCUJWvb5jK+GmImmFElTFR
sClOVfY6gGhGgTIIkZBX83gcTrbz64uKslaoIvQtq9risspauPYej2LKn3VvN/20ai2FbptnWdXa
RcnaWjzMqn1bKyw0t6yS1qgzrGJIaTV82deceqyfWdFPYtYNM2u0F26bLyGUM2v4BhdS64RYle00
0sQ7eMtqmFgrg/DU3uWW2+49v59bq1S8Irfss+RaVV8AWouHyfU95Mqgi9nlmyQ3YE5DPuskcrvP
J11ybbxkgkOuvhlla6WLqCXmCbs2a4VcG75tNcIuoYgQpdvcstt99MqwyzPVuLZ9nl2+qHPhtRYP
P7vKtw3ZcNWXNmQf3+f47x6nkau7yqHbky0Kbu+W/c/pyFz2+tU4Idbk+zHbpCYjzZgoCsJkf1tO
u8+8uW7M8q5lnW/G3A09pkuH+RyULUPV2idbCqpVT5Mtc6sVTRCkM9Wqs1aWrUqKFZ0SaPuKtfuP
jkH1NK1YG/U0XKz/AxlnYBkNCmVuZHN0cmVhbQ0KZW5kb2JqDQo1IDAgb2JqDQo8PC9UeXBlL1hP
YmplY3QvU3VidHlwZS9JbWFnZS9XaWR0aCA1L0hlaWdodCA1L0NvbG9yU3BhY2UvRGV2aWNlUkdC
L0JpdHNQZXJDb21wb25lbnQgOC9JbnRlcnBvbGF0ZSBmYWxzZS9GaWx0ZXIvRmxhdGVEZWNvZGUv
TGVuZ3RoIDEyPj4NCnN0cmVhbQ0KeJz7/59qAAAXzkq2DQplbmRzdHJlYW0NCmVuZG9iag0KNiAw
IG9iag0KPDwvVHlwZS9Gb250L1N1YnR5cGUvVHJ1ZVR5cGUvTmFtZS9GMS9CYXNlRm9udC9Bcmlh
bC9FbmNvZGluZy9XaW5BbnNpRW5jb2RpbmcvRm9udERlc2NyaXB0b3IgNyAwIFIvRmlyc3RDaGFy
IDMyL0xhc3RDaGFyIDExOS9XaWR0aHMgNzYgMCBSPj4NCmVuZG9iag0KNyAwIG9iag0KPDwvVHlw
ZS9Gb250RGVzY3JpcHRvci9Gb250TmFtZS9BcmlhbC9GbGFncyAzMi9JdGFsaWNBbmdsZSAwL0Fz
Y2VudCA5MDUvRGVzY2VudCAtMjEwL0NhcEhlaWdodCA3MjgvQXZnV2lkdGggNDQxL01heFdpZHRo
IDI2NjUvRm9udFdlaWdodCA0MDAvWEhlaWdodCAyNTAvTGVhZGluZyAzMy9TdGVtViA0NC9Gb250
QkJveFsgLTY2NSAtMjEwIDIwMDAgNzI4XSA+Pg0KZW5kb2JqDQo4IDAgb2JqDQo8PC9UeXBlL0V4
dEdTdGF0ZS9CTS9Ob3JtYWwvQ0EgMC41MDk4Pj4NCmVuZG9iag0KOSAwIG9iag0KPDwvVHlwZS9F
eHRHU3RhdGUvQk0vTm9ybWFsL0NBIDAuNzAxOTY+Pg0KZW5kb2JqDQoxMCAwIG9iag0KPDwvVHlw
ZS9YT2JqZWN0L1N1YnR5cGUvSW1hZ2UvV2lkdGggNzUvSGVpZ2h0IDU2L0NvbG9yU3BhY2UvRGV2
aWNlUkdCL0JpdHNQZXJDb21wb25lbnQgOC9GaWx0ZXIvRENURGVjb2RlL0ludGVycG9sYXRlIHRy
dWUvTGVuZ3RoIDEzNTk+Pg0Kc3RyZWFtDQr/2P/gABBKRklGAAEBAQBgAGAAAP/bAEMACAYGBwYF
CAcHBwkJCAoMFA0MCwsMGRITDxQdGh8eHRocHCAkLicgIiwjHBwoNyksMDE0NDQfJzk9ODI8LjM0
Mv/bAEMBCQkJDAsMGA0NGDIhHCEyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIy
MjIyMjIyMjIyMjIyMv/AABEIADgASwMBIgACEQEDEQH/xAAfAAABBQEBAQEBAQAAAAAAAAAAAQID
BAUGBwgJCgv/xAC1EAACAQMDAgQDBQUEBAAAAX0BAgMABBEFEiExQQYTUWEHInEUMoGRoQgjQrHB
FVLR8CQzYnKCCQoWFxgZGiUmJygpKjQ1Njc4OTpDREVGR0hJSlNUVVZXWFlaY2RlZmdoaWpzdHV2
d3h5eoOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3uLm6wsPExcbHyMnK0tPU1dbX2Nna
4eLj5OXm5+jp6vHy8/T19vf4+fr/xAAfAQADAQEBAQEBAQEBAAAAAAAAAQIDBAUGBwgJCgv/xAC1
EQACAQIEBAMEBwUEBAABAncAAQIDEQQFITEGEkFRB2FxEyIygQgUQpGhscEJIzNS8BVictEKFiQ0
4SXxFxgZGiYnKCkqNTY3ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqCg4SFhoeI
iYqSk5SVlpeYmZqio6Slpqeoqaqys7S1tre4ubrCw8TFxsfIycrS09TV1tfY2dri4+Tl5ufo6ery
8/T19vf4+fr/2gAMAwEAAhEDEQA/APf6KKKACiiigCrb39vdXV3bROTLaOqSgrjBKhh+hFWq5vQJ
45PFHilEbLJdQBuOh8hK6SgAooooAgt7qC7R3t5UkVJGjYqc4ZThh9Qc1PXOeCCH8PPMCCJb67ky
DnOZ5K6OgAooppIVSSQAPXtQA6isS+8TafaZVH8+QcbY+mfrXO3PirU2lM0bJFbEYEfk5IPru7/k
KHoC1H+DZt/jrxyhP3buA/8AkLH9K7qvGNL1zUdM8RazewmEfbnR5C69SARW3H8QdTUnzI7Zx/uk
f1oA9MqK5lEFrNN/zzRm/IVxEXxCkCgzWCH/AHZMf41V1z4maSmhXsU8N1DLNbyJGRHvXcVIGSOn
JFAF74Rv5nw202Q9XaZj+MrV3FcT8JYTB8MtGUkElHJwc4y7V21ABXhPiHxvfXOpXtndiZ7aK5dF
jMWUyrH064r3avKvFvwuvtV1me+0e6tbeOZvMMMskijefvHjI5z6VrSm4O6t8yJxujlIvHTqAokt
wAMbWixj9RV6DxrI3PlwMPVHI/xqe4+Dmtx2ii31SzuHIDSRSqyrv74POfxArIg+HPibSpnkl0gT
ocZEMysD/I/pXTHFJu0ooydNrZmxF4ph3uZLdj5hBJDBs/nipzqukTqC0cak9S8O3H4gVzmo6Nd2
s0bf2deRKV+YNA4AP4is9l2nBBQ+/BrqhClUV7GLco6XOiv5YVCtaLJOjdoAH2/rmqLxxvbtcXJK
WyKXYupXp7GsnJxlXOQRgg16D4T8JaV4s8MzR6ok0sBlYKqSshHOeoP0rHFUKcIcyWprSnJysdR8
L1C/DrSGAIDxswz15Y119UNH0q10PSbbTLJWW2tkCRhm3HHuav15p0hRRRQAUUUUAFRPBDL/AKyK
N/8AeUGiigDkfFPw7sfElzDcx3cunzxRmMeSilGGc8r3P41q+E/Dp8M6OLJrn7S+8s0mzbn8Mmii
rdSbjyt6EqKvc3qKKKgo/9kNCmVuZHN0cmVhbQ0KZW5kb2JqDQoxMSAwIG9iag0KPDwvVGl0bGUo
Y29hcCB1dGlsaXphdGlvbiBmb3IgYnVpbGRpbmcgY29udHJvbCkvQXV0aG9yKFBldGVyIHZhbiBk
ZXIgU3RvaykvQ3JlYXRpb25EYXRlKEQ6MjAxMjExMDkxNDUyMTYpIC9Nb2REYXRlKEQ6MjAxMjEx
MDkxNDUyMTYpIC9Qcm9kdWNlcij+/wBNAGkAYwByAG8AcwBvAGYAdACuACAATwBmAGYAaQBjAGUA
IABQAG8AdwBlAHIAUABvAGkAbgB0AK4AIAAyADAAMAA3KS9DcmVhdG9yKP7/AE0AaQBjAHIAbwBz
AG8AZgB0AK4AIABPAGYAZgBpAGMAZQAgAFAAbwB3AGUAcgBQAG8AaQBuAHQArgAgADIAMAAwADcp
Pj4NCmVuZG9iag0KMTcgMCBvYmoNCjw8L1R5cGUvT2JqU3RtL04gNjMvRmlyc3QgNDc0L0ZpbHRl
ci9GbGF0ZURlY29kZS9MZW5ndGggODQ2Pj4NCnN0cmVhbQ0KeJy9V01LHEEQvQv+hzomp+mP6i8Q
IRGSgMEsrjcJwSTDIhiVzUr03+d1l9mddnZnZzwEFmpmfPVedVV1d6kdKdKRrCOdKGkymrTxZPDV
483gKZBh/PBoyQS8ObLlEV6RALYJb5HYJrKKOACdyCm8aXIOaEsO1NaQL07kgyXLFDLEU8iQSCFD
AsUMSRQBYU0JEFaU2BECSICwJa0AZ4aN+IzINajZwwagAxaAoDjCZpJE+LNCPLA+kMMCWTM5A4sl
OvA5FcmBLweLn/bKkAOPh7MDr4cOlqoDFuTBEyL8wRvBCwodvScPnoQcevAmkHhkQSngczJB7h1s
Ah4JRCDkE2wEHik0SGlQsEFTyHlGwvFoLMSwBMMqZwkWojm7nBAkrONcLeQ+IkjgUhaHXkK8R0fN
LIMUnTfzZn5/ddvMFmTL+ymp4+PDgxry4XrxsGybdzerN/NPn99/NCffTr68bU4vSX+ltW/f7yW1
WUOQHYHMMosdZLloH1ff7x4zEC2Ib5M0eaNpu5putCZP1vQbTd/VDKM1w2TNuNFMXc00VtOqyZp6
0yvYZh1RPdwXXVW7S9VyxWhGM7rp67Ab1VCp8mjVOF3VrTFcbQftx6ry/v3Q2buyY4ebsAeP0+DD
7fYSbtQ0+HBb9eDDPdODDx9DPfhwb/TgwwdODz7cAz34tKqaaVU106pqt1bVVUehHX1CuP1nYSeA
2/ZPu1hIGFvL76rT0Y6+evz+43FHGFv7xFfnpR19G/md5+W+MLY2lHdVGKMvKO9fG8bWzvOxCmP0
neXTK8PgrS0adDcMHt2iwbw2jK0tGqqbj0e3aNh98/3rtvnN9c+2HNQFm+f7Ykoen6eyPNoXY8UI
UiaZPMwXIw5WixEHubHz3F5MECNIueHypF6MULM4sCiw+LH4sQixuDtxd6LnhMUJixMWJyxyzOSZ
vBhx9+Inmy7P38WIgxc9acE8axcjDkEUwo4R8OLpvm3mq+XDj9XFsm3P7+5Wzexq2d6W1zx3l5v+
8rlamWD91zPU7bR9Iv3Mdfbw6/cl5f+tBJo/7yqTrsrEVZlCt0wy063LJKuRAWldpliVSf+vMoVu
meRwXZfJVmXyVZlSVSZTlem5/w8P/gKdgUZHDQplbmRzdHJlYW0NCmVuZG9iag0KNzYgMCBvYmoN
ClsgMjc4IDAgMCAwIDAgMCAwIDAgMzMzIDMzMyAwIDAgMCAwIDAgMCAwIDU1NiA1NTYgNTU2IDU1
NiA1NTYgNTU2IDU1NiAwIDAgMCAwIDAgMCAwIDAgMCAwIDY2NyAwIDcyMiAwIDAgMCAwIDAgMCAw
IDAgMCA3MjIgNzc4IDAgMCA3MjIgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDU1NiAwIDUw
MCAwIDU1NiAyNzggNTU2IDAgMjIyIDAgNTAwIDAgODMzIDU1NiA1NTYgMCAwIDMzMyA1MDAgMjc4
IDU1NiAwIDcyMl0gDQplbmRvYmoNCjc3IDAgb2JqDQo8PC9UeXBlL1hSZWYvU2l6ZSA3Ny9XWyAx
IDQgMl0gL1Jvb3QgMSAwIFIvSW5mbyAxMSAwIFIvSURbPEY3ODAxNTBFRjg4RUVENDc5MDZDNkQ0
RENDN0EzRkQ2PjxGNzgwMTUwRUY4OEVFRDQ3OTA2QzZENERDQzdBM0ZENj5dIC9GaWx0ZXIvRmxh
dGVEZWNvZGUvTGVuZ3RoIDE3ND4+DQpzdHJlYW0NCnicNdHHEcJADIXhtQm2ScZgcs45mJyPdMUM
pdAEF/qhBM6w7A866BuNNLo8IWS935rsjhBfLnBXaE+FcVaYGtwU1hUe8FLYEl09O8AR9vDbneSl
4/0nDXTwgw8CYEAQTAiBBWGIQgRiEAcbEuBAElLgQhqykIEc5KEARShBGSpQhRrUoQFNaEEbutCB
HgygD0MYwwgm4MEUZrCAOSxhDSvYwA62MhxX5v4BZwYWCg0KZW5kc3RyZWFtDQplbmRvYmoNCnhy
ZWYNCjAgNzgNCjAwMDAwMDAwMTIgNjU1MzUgZg0KMDAwMDAwMDAxNyAwMDAwMCBuDQowMDAwMDAw
MTI1IDAwMDAwIG4NCjAwMDAwMDAxODEgMDAwMDAgbg0KMDAwMDAwMDQ4NSAwMDAwMCBuDQowMDAw
MDAxODYyIDAwMDAwIG4NCjAwMDAwMDIwNDkgMDAwMDAgbg0KMDAwMDAwMjIwOCAwMDAwMCBuDQow
MDAwMDAyNDMyIDAwMDAwIG4NCjAwMDAwMDI0OTAgMDAwMDAgbg0KMDAwMDAwMjU0OSAwMDAwMCBu
DQowMDAwMDA0MDg1IDAwMDAwIG4NCjAwMDAwMDAwMTMgNjU1MzUgZg0KMDAwMDAwMDAxNCA2NTUz
NSBmDQowMDAwMDAwMDE1IDY1NTM1IGYNCjAwMDAwMDAwMTYgNjU1MzUgZg0KMDAwMDAwMDAxNyA2
NTUzNSBmDQowMDAwMDAwMDE4IDY1NTM1IGYNCjAwMDAwMDAwMTkgNjU1MzUgZg0KMDAwMDAwMDAy
MCA2NTUzNSBmDQowMDAwMDAwMDIxIDY1NTM1IGYNCjAwMDAwMDAwMjIgNjU1MzUgZg0KMDAwMDAw
MDAyMyA2NTUzNSBmDQowMDAwMDAwMDI0IDY1NTM1IGYNCjAwMDAwMDAwMjUgNjU1MzUgZg0KMDAw
MDAwMDAyNiA2NTUzNSBmDQowMDAwMDAwMDI3IDY1NTM1IGYNCjAwMDAwMDAwMjggNjU1MzUgZg0K
MDAwMDAwMDAyOSA2NTUzNSBmDQowMDAwMDAwMDMwIDY1NTM1IGYNCjAwMDAwMDAwMzEgNjU1MzUg
Zg0KMDAwMDAwMDAzMiA2NTUzNSBmDQowMDAwMDAwMDMzIDY1NTM1IGYNCjAwMDAwMDAwMzQgNjU1
MzUgZg0KMDAwMDAwMDAzNSA2NTUzNSBmDQowMDAwMDAwMDM2IDY1NTM1IGYNCjAwMDAwMDAwMzcg
NjU1MzUgZg0KMDAwMDAwMDAzOCA2NTUzNSBmDQowMDAwMDAwMDM5IDY1NTM1IGYNCjAwMDAwMDAw
NDAgNjU1MzUgZg0KMDAwMDAwMDA0MSA2NTUzNSBmDQowMDAwMDAwMDQyIDY1NTM1IGYNCjAwMDAw
MDAwNDMgNjU1MzUgZg0KMDAwMDAwMDA0NCA2NTUzNSBmDQowMDAwMDAwMDQ1IDY1NTM1IGYNCjAw
MDAwMDAwNDYgNjU1MzUgZg0KMDAwMDAwMDA0NyA2NTUzNSBmDQowMDAwMDAwMDQ4IDY1NTM1IGYN
CjAwMDAwMDAwNDkgNjU1MzUgZg0KMDAwMDAwMDA1MCA2NTUzNSBmDQowMDAwMDAwMDUxIDY1NTM1
IGYNCjAwMDAwMDAwNTIgNjU1MzUgZg0KMDAwMDAwMDA1MyA2NTUzNSBmDQowMDAwMDAwMDU0IDY1
NTM1IGYNCjAwMDAwMDAwNTUgNjU1MzUgZg0KMDAwMDAwMDA1NiA2NTUzNSBmDQowMDAwMDAwMDU3
IDY1NTM1IGYNCjAwMDAwMDAwNTggNjU1MzUgZg0KMDAwMDAwMDA1OSA2NTUzNSBmDQowMDAwMDAw
MDYwIDY1NTM1IGYNCjAwMDAwMDAwNjEgNjU1MzUgZg0KMDAwMDAwMDA2MiA2NTUzNSBmDQowMDAw
MDAwMDYzIDY1NTM1IGYNCjAwMDAwMDAwNjQgNjU1MzUgZg0KMDAwMDAwMDA2NSA2NTUzNSBmDQow
MDAwMDAwMDY2IDY1NTM1IGYNCjAwMDAwMDAwNjcgNjU1MzUgZg0KMDAwMDAwMDA2OCA2NTUzNSBm
DQowMDAwMDAwMDY5IDY1NTM1IGYNCjAwMDAwMDAwNzAgNjU1MzUgZg0KMDAwMDAwMDA3MSA2NTUz
NSBmDQowMDAwMDAwMDcyIDY1NTM1IGYNCjAwMDAwMDAwNzMgNjU1MzUgZg0KMDAwMDAwMDA3NCA2
NTUzNSBmDQowMDAwMDAwMDc1IDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAwNTM0
OSAwMDAwMCBuDQowMDAwMDA1NjA4IDAwMDAwIG4NCnRyYWlsZXINCjw8L1NpemUgNzgvUm9vdCAx
IDAgUi9JbmZvIDExIDAgUi9JRFs8Rjc4MDE1MEVGODhFRUQ0NzkwNkM2RDREQ0M3QTNGRDY+PEY3
ODAxNTBFRjg4RUVENDc5MDZDNkQ0RENDN0EzRkQ2Pl0gPj4NCnN0YXJ0eHJlZg0KNTk4Mw0KJSVF
T0YNCnhyZWYNCjAgMA0KdHJhaWxlcg0KPDwvU2l6ZSA3OC9Sb290IDEgMCBSL0luZm8gMTEgMCBS
L0lEWzxGNzgwMTUwRUY4OEVFRDQ3OTA2QzZENERDQzdBM0ZENj48Rjc4MDE1MEVGODhFRUQ0Nzkw
NkM2RDREQ0M3QTNGRDY+XSAvUHJldiA1OTgzL1hSZWZTdG0gNTYwOD4+DQpzdGFydHhyZWYNCjc2
OTkNCiUlRU9G
--=_1d9a47692d3c983232d0cf038d8f7aac--


From dat@exegin.com  Fri Nov  9 09:46:15 2012
Return-Path: 
X-Original-To: roll@ietfa.amsl.com
Delivered-To: roll@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D506321F8759 for ; Fri,  9 Nov 2012 09:46:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.289
X-Spam-Level: 
X-Spam-Status: No, score=-3.289 tagged_above=-999 required=5 tests=[AWL=0.310,  BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A1nMbdhVZfiH for ; Fri,  9 Nov 2012 09:46:14 -0800 (PST)
Received: from mail-pa0-f44.google.com (mail-pa0-f44.google.com [209.85.220.44]) by ietfa.amsl.com (Postfix) with ESMTP id BD40E21F8501 for ; Fri,  9 Nov 2012 09:46:14 -0800 (PST)
Received: by mail-pa0-f44.google.com with SMTP id fb11so3142730pad.31 for ; Fri, 09 Nov 2012 09:46:14 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding :x-gm-message-state; bh=ujuz1Xw0zi+JNlqLUkvhNge8em9cqzJ9LapDWTUw6XM=; b=JmGYssn4+eqiDeGaVXSrP25FEK+vpreVeROkV+utHKyaTim2gPJfdM6UTj6NF9LQox rD8gYb57Zuq6m7Q/5O5Aan3oq3XsXLyVrjzhz8juYn2IPbqE8iTmOgp+dMCqvj0DkL82 6wbr4v4+H/RV4LBcgNG0ijRBzHZCJSRjPp94SZ5pIHBuSeEgJAX3ojHabWQjyE12AgGG 10b54AwcEg++aYiaM9rkPw2ccNCZwxLtYJDWszFzRUfGsQ2baRlk1AzMlx5wjcwWIFxT WGtNutsrRApoSJ53LZ4EgUDR0RvM9mAiLdn4qP264HXgXAaX1SkpgT0qA0J4DpqxWlHd HrOQ==
Received: by 10.68.143.106 with SMTP id sd10mr14341922pbb.62.1352483174131; Fri, 09 Nov 2012 09:46:14 -0800 (PST)
Received: from [172.16.1.52] ([184.71.143.130]) by mx.google.com with ESMTPS id yi9sm18032016pbc.39.2012.11.09.09.46.12 (version=SSLv3 cipher=OTHER); Fri, 09 Nov 2012 09:46:12 -0800 (PST)
Message-ID: <509D4179.8070505@exegin.com>
Date: Fri, 09 Nov 2012 09:46:33 -0800
From: Dario Tedeschi 
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:7.0) Gecko/20110922 Thunderbird/7.0
MIME-Version: 1.0
To: "Jonathan Hui (johui)" 
References: <058.e817419e990e1afb26be9aa25d5cfc21@trac.tools.ietf.org>  <50932647.3050509@exegin.com>  <5094202F.4010805@exegin.com>  <509C03C2.50809@exegin.com>  <509C5F00.2050204@exegin.com>
In-Reply-To: <509C5F00.2050204@exegin.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
X-Gm-Message-State: ALoCoQlOF/yTn61671bfQe3iwgw9YTfCRjfq/mDFheAx6xJzJi2nDVOaw7+Ysw0qHLGZL+AN2Q0y
Cc: "" , "" , "" 
Subject: Re: [Roll] [roll] #105: trickle-mcast: how to determine scope of MPL domain
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Routing Over Low power and Lossy networks 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 09 Nov 2012 17:46:15 -0000

Hi Jonathan

According to your approach please could you give examples of what the 
outer and inner mc addresses would look like and where the HbH option 
would be placed.

- Dario


On 08/11/2012 5:40 PM, Dario Tedeschi wrote:
> On 08/11/2012 1:02 PM, Jonathan Hui (johui) wrote:
>> Hi Dario,
>>
>> On Nov 8, 2012, at 11:10 AM, Dario Tedeschi  wrote:
>>
>>> On 02/11/2012 10:18 PM, Jonathan Hui (johui) wrote:
>>>> With your approach (require link-local in the outer header), the 
>>>> IPv6 multicast address identifies the application endpoints *and* 
>>>> the MPL domain.  For that reason, your approach really only needs a 
>>>> single identifier to both limit the flooding scope and determine 
>>>> the application endpoints.
>>> It depends on what you mean by MPL domain. In my view,  FF02::MPL 
>>> identifies the MPL domain, while the inner IPv6 destination address 
>>> identifies the application endpoint.
>> Let me introduce a new term to help move the discussion forward:  
>> Dissemination Region - a connected set of MPL devices that attempt to 
>> forward the packet so that all devices receive the packet at least 
>> once.  Another definition may be: a region within which the SeedID 
>> must be unique.
>
> OK, that makes sense to me.
>
>>
>>>>   I can see how that would work (as you demonstrated) if we make 
>>>> the restriction that the IPv6 multicast addresses used within an 
>>>> MPL domain have the same prefix that identifies the MPL domain 
>>>> itself.  The trouble comes when you want to support the full 
>>>> generality that IPv6 multicast addresses used by application 
>>>> endpoints can be arbitrary.
>>> The "generality", you talk of, is why protocols like MLD exist. MLD 
>>> informs routers of mc addresses other devices are interested in. 
>>> Essentially it provides routing information. How could we support 
>>> the "full generality" of mc addresses without this information 
>>> (whether implied or from something like MLD).  With this in mind, I 
>>> don't understand the need for non-link-local scope in the outer 
>>> header, because the "generality" you seek would be determined by the 
>>> mc address of the original packet (i.e. the mc address of the inner 
>>> header). All my approach is really saying is that only the 
>>> original/inner mc address determines how far a packet will 
>>> propagate, regardless of routing domain. MPL could just be one of 
>>> many routing domains a mc packet must traverse before reaching its 
>>> furthermost boundary. Or MPL may be the only routing domain, where 
>>> the mc packet only reaches a sub-set of devices within the domain 
>>> (i.e. a multicast group or a set based on unicast-prefix-based mc).
>> The original intent of MPL was to avoid any routing information 
>> within the Dissemination Region.  A router then only maintains state 
>> about what multicast addresses are of interest to devices within the 
>> Dissemination Region.
>
> Yes I understand, but I'm not sure how we can avoid routing 
> information, if we are to support sending to sub-sets of devices 
> within one LLN (whether we use non-link-local or link-local in the 
> outer header). To me it sounds like we are trying to offer what a 
> storing network provides without actually storing any information on 
> the routers. For unicasts, in RPL, this done by offloading the burden 
> of storing routing information onto the RPL root node (i.e. 
> source-routing). This works for unicasts, but it wouldn't work for 
> multicasts.
>
>
>>
>>>> For example, how does MPL support an application that subscribes to 
>>>> a well-known non-link-local IPv6 multicast address?  I guess one 
>>>> approach is to say that if the IPv6 multicast address is not a 
>>>> unicast-prefix-based multicast address, then it disseminates across 
>>>> the entire region of connected MPL forwarders.
>>> Granted one could have a situation where all routers hear an mc 
>>> packet that is only intended for a subset of devices, but that does 
>>> not mean all routers need to forward that packet or pass it to a 
>>> higher layer. Again, this would depend on the inner mc address and 
>>> the routing information available to routers. The routers without 
>>> the appropriate routing information would not forward. Similarly, 
>>> routers without mc membership information from an app would not pass 
>>> the packet to the next higher layer.
>> We have different thoughts on how a device determines whether or not 
>> to forward the packet.  You take a routing perspective, where a 
>> device determines whether or not to forward based on the identifier 
>> for the application endpoints.  In contrast, I view it as a device 
>> determines whether or not to forward based on the Dissemination 
>> Region it is in.  Note that in my view, the Dissemination Region does 
>> not have to have any relationship with the identifier for application 
>> endpoints.  In other words, you can configure the Dissemination 
>> Region without any knowledge of the multicast addresses that devices 
>> are interested in.
>
> OK I  see your point of view more clearly now. I assume then that a 
> Dissemination Region would be defined by a non-link-local mc address 
> prefix, and if so, how would MPL routers become aware of it? Without 
> it how would a router be able to differentiate one Dissemination 
> Region from another?
>
>
>>
>>>> One minor point with your approach is that the delivery requires 
>>>> processing the MPL Option of the outer header and the inner IPv6 
>>>> header.  That isn't so nice from an architectural perspective, but 
>>>> that is what we did with RFC 6553.
>>> Using non-link-local in the outer header does not mitigate that. The 
>>> forwarder still needs to look at the inner header to determine if 
>>> the inner mc address is one an app is listening on. In fact 
>>> implementing this is a bit messy compared to my approach, because 
>>> the forwarder has to look ahead into the packet before 
>>> decapsulating. My approach always requires decapsulation before 
>>> making any decision about where the packet must go next. It's 
>>> simpler and more consistent. I've actually had the 
>>> fortune/misfortune of implementing both and I can safely say the 
>>> link-local approach was cleaner.
>> I'd argue that using non-link-local in the outer header helps to 
>> preserve the layering.
>> 1) Processing the outer header allows a device to determine whether 
>> it is a part of the Dissemination Region and the packet was received 
>> before.
>> 2) Processing the inner header allows a device to determine whether 
>> it should process the payload.
>>
>> Can you explain why a device needs to "look ahead" into the packet 
>> before decapsulating when using a non-link-local outer header?
>
> Lets say the packet has outer and inner destination addresses 
> [FF05::1234] and [FF05::5678], respectively. An app on a device 
> receiving this packet, might be interested in [FF05::1234] or 
> [FF05::5678] or both. Which version of the packet gets passed up: The 
> entire MPL encapsulated one or just the inner packet or both. To get 
> around this, I had to add a hack that would do two things:
> 1. If the network device is a member of [FF05::1234] and there is no 
> IPv6-in-IPv6 encapsulation, then pass the packet up.
> 2. If there is IPv6-in-IPv6 encapsulation and there is a MPL HbH 
> option and the network device is a member of [FF05::5678], then 
> decapsulate and pass the inner packet up.
>
> Note that logic 2. required looking ahead at the inner header to 
> determine if the mc address there was an address some higher layer was 
> interested in. What made things even less palatable, was having to 
> skip over potential extended headers just to determine whether or not 
> the packet was encapsulated. Aside from passing mc packets up, the 
> hack was also needed to decrement the hop-limit when forwarding.
>
> Back then, there was no idea of having an IANA assigned MPL mc-group 
> so I could not rely on a well-known non-link-local address. With a 
> well-known MPL address a MPL router would be able to be a member of 
> that group and always try decapsulate upon hearing a packet destined 
> for that address. Without this MPL mc address using the link-local 
> all-routers mc address, removed the need for the hack. This was 
> because all routers are members of the all-routers group.
>
>
>
>>
>>>> In my approach (allow non-link-local in the outer header), I tried 
>>>> to separate out the identifiers for the application endpoints and 
>>>> the MPL domain.  That is why I used the outer header's destination 
>>>> address to identify the MPL domain and the inner header's 
>>>> destination address to identify the application endpoints.  With 
>>>> this approach, it actually becomes feasible to address situations 
>>>> where the devices within an MPL domain subscribe to arbitrary IPv6 
>>>> multicast addresses - not just ones that are based on the unicast 
>>>> prefix.
>>> Firstly, yes I agree the inner destination address should determine 
>>> the application endpoint. What I'm not clear on is why we need an 
>>> MPL domain to cover more than the LLN or why we need to support 
>>> multiple MPL domains in one LLN. Tf the latter case is required to 
>>> allow for different sets of MPL propagation parameters, then I'd 
>>> imagine that should rather be handled by the HbH option.
>> Peter's use case involves having multiple Dissemination Regions 
>> within a single IEEE 802.15.4 PAN.  I agree, one could argue whether 
>> the devices should all be within the same PAN or different PANs based 
>> on the nearest border router.
>
>  Or an argument for having multiple Destination Regions identified by 
> some field in the HbH option.
>
>
>>
>> During the WG meeting, people made a good argument that we actually 
>> don't know the answer - either because all the use cases are not 
>> obvious or because we don't understand all the consequences of each 
>> approach.  One proposal was to have the draft specify well-defined 
>> forwarding behavior that supports both situations.  For example:
>> 1) If the outer header has an IPv6 Destination Address matching the 
>> link-local all-MPL-forwarders address, do …
>> 2) Otherwise, do …
>>
>> Then leave it up to those who are using this spec to determine what 
>> subset they want to use.  Not sure if this is a reasonable approach 
>> and would like to get feedback from the WG.
>
> My current implementation is just such a hybrid, except that action 1 
> is decided by scope and not the full address. From an implementation 
> point of view, I'd prefer not to have two code paths, but if it 
> satisfies everyone's needs and we have an IANA assigned address, I can 
> live with it. :-)
>
> - Dario
>
>
>
>


From dat@exegin.com  Fri Nov  9 11:34:58 2012
Return-Path: 
X-Original-To: roll@ietfa.amsl.com
Delivered-To: roll@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6838A21F852C for ; Fri,  9 Nov 2012 11:34:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.317
X-Spam-Level: 
X-Spam-Status: No, score=-3.317 tagged_above=-999 required=5 tests=[AWL=0.282,  BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wfznLIuqXfOq for ; Fri,  9 Nov 2012 11:34:57 -0800 (PST)
Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 5405121F8523 for ; Fri,  9 Nov 2012 11:34:57 -0800 (PST)
Received: by mail-pb0-f44.google.com with SMTP id ro8so3237504pbb.31 for ; Fri, 09 Nov 2012 11:34:57 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding :x-gm-message-state; bh=3vvXYmgqaXdvFftz9yEC16hlaoFnWvbWOUt0kzHwJEk=; b=e3H9jW4TkJzAy4gJQQqWHXUm1xtdaJSqWFB8GFU1hI7t9oXPmrtASa1fGbseWhqCG2 aX09RAOzMHnZtQx4aqhdGTQUr8kytcqA6xva0xCN7W6qM0rPzTHPKodpncVVg2wd+QRx 23xPP1XeaBwbCPWGFA5+j7jOk44MzhBCy0XwAaBVYHU41ki+krKk9i9+lXIwQSk66GHr 0xQY1K3ojP+fgFXu56Rs7hKqr1twpkHPaSUCjpuYJUjNUV7gP62ZPOz8S+Eb/Gl8/P3T SBPFR9nyFBimGX+9HmJwxNCQuOMd6FrzmagWf0IN1XezvLxhg51eAmVO3cYdryuzFPUw ys+A==
Received: by 10.66.88.133 with SMTP id bg5mr34173864pab.80.1352489697152; Fri, 09 Nov 2012 11:34:57 -0800 (PST)
Received: from [172.16.1.52] ([184.71.143.130]) by mx.google.com with ESMTPS id ni3sm18160478pbc.2.2012.11.09.11.34.55 (version=SSLv3 cipher=OTHER); Fri, 09 Nov 2012 11:34:56 -0800 (PST)
Message-ID: <509D5AF5.4040304@exegin.com>
Date: Fri, 09 Nov 2012 11:35:17 -0800
From: Dario Tedeschi 
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:7.0) Gecko/20110922 Thunderbird/7.0
MIME-Version: 1.0
To: "Jonathan Hui (johui)" 
References: <058.e817419e990e1afb26be9aa25d5cfc21@trac.tools.ietf.org>  <50932647.3050509@exegin.com>  <5094202F.4010805@exegin.com>  <509C03C2.50809@exegin.com>  <509C5F00.2050204@exegin.com>
In-Reply-To: <509C5F00.2050204@exegin.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
X-Gm-Message-State: ALoCoQn6BZUNuEOd0q1SbHC6Az2gZKPpxR2zX44XnOK1UIREtNa9qud8qrKSEoux4g4lhoJqjALq
Cc: "" 
Subject: Re: [Roll] [roll] #105: trickle-mcast: how to determine scope of MPL domain
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Routing Over Low power and Lossy networks 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 09 Nov 2012 19:34:58 -0000

After some lengthy discussions, Owen Kirby and I think the use of a 
non-link-local mc address in the outer header is fine as long as that 
address *uniquely* identifies the MPL domain (whether it be IANA 
assigned or determined at run-time).

- Dario



On 08/11/2012 5:40 PM, Dario Tedeschi wrote:
> On 08/11/2012 1:02 PM, Jonathan Hui (johui) wrote:
>> Hi Dario,
>>
>> On Nov 8, 2012, at 11:10 AM, Dario Tedeschi  wrote:
>>
>>> On 02/11/2012 10:18 PM, Jonathan Hui (johui) wrote:
>>>> With your approach (require link-local in the outer header), the 
>>>> IPv6 multicast address identifies the application endpoints *and* 
>>>> the MPL domain.  For that reason, your approach really only needs a 
>>>> single identifier to both limit the flooding scope and determine 
>>>> the application endpoints.
>>> It depends on what you mean by MPL domain. In my view,  FF02::MPL 
>>> identifies the MPL domain, while the inner IPv6 destination address 
>>> identifies the application endpoint.
>> Let me introduce a new term to help move the discussion forward:  
>> Dissemination Region - a connected set of MPL devices that attempt to 
>> forward the packet so that all devices receive the packet at least 
>> once.  Another definition may be: a region within which the SeedID 
>> must be unique.
>
> OK, that makes sense to me.
>
>>
>>>>   I can see how that would work (as you demonstrated) if we make 
>>>> the restriction that the IPv6 multicast addresses used within an 
>>>> MPL domain have the same prefix that identifies the MPL domain 
>>>> itself.  The trouble comes when you want to support the full 
>>>> generality that IPv6 multicast addresses used by application 
>>>> endpoints can be arbitrary.
>>> The "generality", you talk of, is why protocols like MLD exist. MLD 
>>> informs routers of mc addresses other devices are interested in. 
>>> Essentially it provides routing information. How could we support 
>>> the "full generality" of mc addresses without this information 
>>> (whether implied or from something like MLD).  With this in mind, I 
>>> don't understand the need for non-link-local scope in the outer 
>>> header, because the "generality" you seek would be determined by the 
>>> mc address of the original packet (i.e. the mc address of the inner 
>>> header). All my approach is really saying is that only the 
>>> original/inner mc address determines how far a packet will 
>>> propagate, regardless of routing domain. MPL could just be one of 
>>> many routing domains a mc packet must traverse before reaching its 
>>> furthermost boundary. Or MPL may be the only routing domain, where 
>>> the mc packet only reaches a sub-set of devices within the domain 
>>> (i.e. a multicast group or a set based on unicast-prefix-based mc).
>> The original intent of MPL was to avoid any routing information 
>> within the Dissemination Region.  A router then only maintains state 
>> about what multicast addresses are of interest to devices within the 
>> Dissemination Region.
>
> Yes I understand, but I'm not sure how we can avoid routing 
> information, if we are to support sending to sub-sets of devices 
> within one LLN (whether we use non-link-local or link-local in the 
> outer header). To me it sounds like we are trying to offer what a 
> storing network provides without actually storing any information on 
> the routers. For unicasts, in RPL, this done by offloading the burden 
> of storing routing information onto the RPL root node (i.e. 
> source-routing). This works for unicasts, but it wouldn't work for 
> multicasts.
>
>
>>
>>>> For example, how does MPL support an application that subscribes to 
>>>> a well-known non-link-local IPv6 multicast address?  I guess one 
>>>> approach is to say that if the IPv6 multicast address is not a 
>>>> unicast-prefix-based multicast address, then it disseminates across 
>>>> the entire region of connected MPL forwarders.
>>> Granted one could have a situation where all routers hear an mc 
>>> packet that is only intended for a subset of devices, but that does 
>>> not mean all routers need to forward that packet or pass it to a 
>>> higher layer. Again, this would depend on the inner mc address and 
>>> the routing information available to routers. The routers without 
>>> the appropriate routing information would not forward. Similarly, 
>>> routers without mc membership information from an app would not pass 
>>> the packet to the next higher layer.
>> We have different thoughts on how a device determines whether or not 
>> to forward the packet.  You take a routing perspective, where a 
>> device determines whether or not to forward based on the identifier 
>> for the application endpoints.  In contrast, I view it as a device 
>> determines whether or not to forward based on the Dissemination 
>> Region it is in.  Note that in my view, the Dissemination Region does 
>> not have to have any relationship with the identifier for application 
>> endpoints.  In other words, you can configure the Dissemination 
>> Region without any knowledge of the multicast addresses that devices 
>> are interested in.
>
> OK I  see your point of view more clearly now. I assume then that a 
> Dissemination Region would be defined by a non-link-local mc address 
> prefix, and if so, how would MPL routers become aware of it? Without 
> it how would a router be able to differentiate one Dissemination 
> Region from another?
>
>
>>
>>>> One minor point with your approach is that the delivery requires 
>>>> processing the MPL Option of the outer header and the inner IPv6 
>>>> header.  That isn't so nice from an architectural perspective, but 
>>>> that is what we did with RFC 6553.
>>> Using non-link-local in the outer header does not mitigate that. The 
>>> forwarder still needs to look at the inner header to determine if 
>>> the inner mc address is one an app is listening on. In fact 
>>> implementing this is a bit messy compared to my approach, because 
>>> the forwarder has to look ahead into the packet before 
>>> decapsulating. My approach always requires decapsulation before 
>>> making any decision about where the packet must go next. It's 
>>> simpler and more consistent. I've actually had the 
>>> fortune/misfortune of implementing both and I can safely say the 
>>> link-local approach was cleaner.
>> I'd argue that using non-link-local in the outer header helps to 
>> preserve the layering.
>> 1) Processing the outer header allows a device to determine whether 
>> it is a part of the Dissemination Region and the packet was received 
>> before.
>> 2) Processing the inner header allows a device to determine whether 
>> it should process the payload.
>>
>> Can you explain why a device needs to "look ahead" into the packet 
>> before decapsulating when using a non-link-local outer header?
>
> Lets say the packet has outer and inner destination addresses 
> [FF05::1234] and [FF05::5678], respectively. An app on a device 
> receiving this packet, might be interested in [FF05::1234] or 
> [FF05::5678] or both. Which version of the packet gets passed up: The 
> entire MPL encapsulated one or just the inner packet or both. To get 
> around this, I had to add a hack that would do two things:
> 1. If the network device is a member of [FF05::1234] and there is no 
> IPv6-in-IPv6 encapsulation, then pass the packet up.
> 2. If there is IPv6-in-IPv6 encapsulation and there is a MPL HbH 
> option and the network device is a member of [FF05::5678], then 
> decapsulate and pass the inner packet up.
>
> Note that logic 2. required looking ahead at the inner header to 
> determine if the mc address there was an address some higher layer was 
> interested in. What made things even less palatable, was having to 
> skip over potential extended headers just to determine whether or not 
> the packet was encapsulated. Aside from passing mc packets up, the 
> hack was also needed to decrement the hop-limit when forwarding.
>
> Back then, there was no idea of having an IANA assigned MPL mc-group 
> so I could not rely on a well-known non-link-local address. With a 
> well-known MPL address a MPL router would be able to be a member of 
> that group and always try decapsulate upon hearing a packet destined 
> for that address. Without this MPL mc address using the link-local 
> all-routers mc address, removed the need for the hack. This was 
> because all routers are members of the all-routers group.
>
>
>
>>
>>>> In my approach (allow non-link-local in the outer header), I tried 
>>>> to separate out the identifiers for the application endpoints and 
>>>> the MPL domain.  That is why I used the outer header's destination 
>>>> address to identify the MPL domain and the inner header's 
>>>> destination address to identify the application endpoints.  With 
>>>> this approach, it actually becomes feasible to address situations 
>>>> where the devices within an MPL domain subscribe to arbitrary IPv6 
>>>> multicast addresses - not just ones that are based on the unicast 
>>>> prefix.
>>> Firstly, yes I agree the inner destination address should determine 
>>> the application endpoint. What I'm not clear on is why we need an 
>>> MPL domain to cover more than the LLN or why we need to support 
>>> multiple MPL domains in one LLN. Tf the latter case is required to 
>>> allow for different sets of MPL propagation parameters, then I'd 
>>> imagine that should rather be handled by the HbH option.
>> Peter's use case involves having multiple Dissemination Regions 
>> within a single IEEE 802.15.4 PAN.  I agree, one could argue whether 
>> the devices should all be within the same PAN or different PANs based 
>> on the nearest border router.
>
>  Or an argument for having multiple Destination Regions identified by 
> some field in the HbH option.
>
>
>>
>> During the WG meeting, people made a good argument that we actually 
>> don't know the answer - either because all the use cases are not 
>> obvious or because we don't understand all the consequences of each 
>> approach.  One proposal was to have the draft specify well-defined 
>> forwarding behavior that supports both situations.  For example:
>> 1) If the outer header has an IPv6 Destination Address matching the 
>> link-local all-MPL-forwarders address, do …
>> 2) Otherwise, do …
>>
>> Then leave it up to those who are using this spec to determine what 
>> subset they want to use.  Not sure if this is a reasonable approach 
>> and would like to get feedback from the WG.
>
> My current implementation is just such a hybrid, except that action 1 
> is decided by scope and not the full address. From an implementation 
> point of view, I'd prefer not to have two code paths, but if it 
> satisfies everyone's needs and we have an IANA assigned address, I can 
> live with it. :-)
>
> - Dario
>
>
>
>


From dat@exegin.com  Fri Nov  9 17:37:34 2012
Return-Path: 
X-Original-To: roll@ietfa.amsl.com
Delivered-To: roll@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61F7D21F898B for ; Fri,  9 Nov 2012 17:37:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.34
X-Spam-Level: 
X-Spam-Status: No, score=-3.34 tagged_above=-999 required=5 tests=[AWL=0.258,  BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MhAR15jOnvsj for ; Fri,  9 Nov 2012 17:37:32 -0800 (PST)
Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id AB5FD21F8964 for ; Fri,  9 Nov 2012 17:37:32 -0800 (PST)
Received: by mail-pb0-f44.google.com with SMTP id ro8so3380597pbb.31 for ; Fri, 09 Nov 2012 17:37:32 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:x-gm-message-state; bh=8D/1QqCW2Y03d8RaM3rbt0hC51ZajTuwVCHR8zlwPKA=; b=n7z/DS06wqi5CNmfEENcbE7M/epb4A9dH6Q9yEhZQjhZrLKAiMBKdBKTLPB7zcpp6I gyIYQ1RXg1O2KKbLw8Z2xAHAbUPMjPAf75ZUpQJWukYBipXHhflB81/wlWLazLjXRPdh G77Lrmn1I3t9vzIV2DU3zkU8oExW7flkCxYisdH+am077gOQV9ZYR09R7E2HjYFmLSUG XLFIOAvL+JLoqLUZCW94++T241zqEXeNm+ybX+JPKRCNqugrW4eitQejIf0EI4ReiPfj GYw61/CS857U4SlBfWe4aOadM13bvC9n4S0ewf60oPzYiniCfGmiCLUnTlI9uaH4f5x3 0EEQ==
Received: by 10.68.197.197 with SMTP id iw5mr31694306pbc.22.1352511452280; Fri, 09 Nov 2012 17:37:32 -0800 (PST)
Received: from [172.16.1.52] ([184.71.143.130]) by mx.google.com with ESMTPS id ju7sm112584pbb.60.2012.11.09.17.37.30 (version=SSLv3 cipher=OTHER); Fri, 09 Nov 2012 17:37:31 -0800 (PST)
Message-ID: <509DAFEF.5020504@exegin.com>
Date: Fri, 09 Nov 2012 17:37:51 -0800
From: Dario Tedeschi 
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:7.0) Gecko/20110922 Thunderbird/7.0
MIME-Version: 1.0
To: "Jonathan Hui (johui)" 
References: <058.e817419e990e1afb26be9aa25d5cfc21@trac.tools.ietf.org>  <50932647.3050509@exegin.com>  <5094202F.4010805@exegin.com>  <509C03C2.50809@exegin.com>  <509C5F00.2050204@exegin.com> <509D5AF5.4040304@exegin.com>
In-Reply-To: <509D5AF5.4040304@exegin.com>
Content-Type: multipart/alternative; boundary="------------030505070407020106090804"
X-Gm-Message-State: ALoCoQkrjgF72cGMPk7JP1qRlxH+gIaWhSXIhAQ47tHaKltxd75735Q17U3KfyLskPIJRLBD/8gO
Cc: "" 
Subject: Re: [Roll] [roll] #105: trickle-mcast: how to determine scope of MPL domain
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Routing Over Low power and Lossy networks 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 10 Nov 2012 01:37:34 -0000

This is a multi-part message in MIME format.
--------------030505070407020106090804
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit

Actually, I missed something. I should have said:

Non-link-local would be fine with the following caveats:

 1. A non-link-local mc address that *uniquely* identifies the MPL
    domain must exist, whether it be IANA assigned or determined at
    run-time.
 2. A packet injected into an MPL domain that has a mc address that does
    not match the MPL domain address must be tunneled.

- Dario

On 09/11/2012 11:35 AM, Dario Tedeschi wrote:
>
> After some lengthy discussions, Owen Kirby and I think the use of a 
> non-link-local mc address in the outer header is fine as long as that 
> address *uniquely* identifies the MPL domain (whether it be IANA 
> assigned or determined at run-time).
>
> - Dario
>
>
>
> On 08/11/2012 5:40 PM, Dario Tedeschi wrote:
>> On 08/11/2012 1:02 PM, Jonathan Hui (johui) wrote:
>>> Hi Dario,
>>>
>>> On Nov 8, 2012, at 11:10 AM, Dario Tedeschi  wrote:
>>>
>>>> On 02/11/2012 10:18 PM, Jonathan Hui (johui) wrote:
>>>>> With your approach (require link-local in the outer header), the 
>>>>> IPv6 multicast address identifies the application endpoints *and* 
>>>>> the MPL domain.  For that reason, your approach really only needs 
>>>>> a single identifier to both limit the flooding scope and determine 
>>>>> the application endpoints.
>>>> It depends on what you mean by MPL domain. In my view,  FF02::MPL 
>>>> identifies the MPL domain, while the inner IPv6 destination address 
>>>> identifies the application endpoint.
>>> Let me introduce a new term to help move the discussion forward:  
>>> Dissemination Region - a connected set of MPL devices that attempt 
>>> to forward the packet so that all devices receive the packet at 
>>> least once.  Another definition may be: a region within which the 
>>> SeedID must be unique.
>>
>> OK, that makes sense to me.
>>
>>>
>>>>>   I can see how that would work (as you demonstrated) if we make 
>>>>> the restriction that the IPv6 multicast addresses used within an 
>>>>> MPL domain have the same prefix that identifies the MPL domain 
>>>>> itself.  The trouble comes when you want to support the full 
>>>>> generality that IPv6 multicast addresses used by application 
>>>>> endpoints can be arbitrary.
>>>> The "generality", you talk of, is why protocols like MLD exist. MLD 
>>>> informs routers of mc addresses other devices are interested in. 
>>>> Essentially it provides routing information. How could we support 
>>>> the "full generality" of mc addresses without this information 
>>>> (whether implied or from something like MLD).  With this in mind, I 
>>>> don't understand the need for non-link-local scope in the outer 
>>>> header, because the "generality" you seek would be determined by 
>>>> the mc address of the original packet (i.e. the mc address of the 
>>>> inner header). All my approach is really saying is that only the 
>>>> original/inner mc address determines how far a packet will 
>>>> propagate, regardless of routing domain. MPL could just be one of 
>>>> many routing domains a mc packet must traverse before reaching its 
>>>> furthermost boundary. Or MPL may be the only routing domain, where 
>>>> the mc packet only reaches a sub-set of devices within the domain 
>>>> (i.e. a multicast group or a set based on unicast-prefix-based mc).
>>> The original intent of MPL was to avoid any routing information 
>>> within the Dissemination Region.  A router then only maintains state 
>>> about what multicast addresses are of interest to devices within the 
>>> Dissemination Region.
>>
>> Yes I understand, but I'm not sure how we can avoid routing 
>> information, if we are to support sending to sub-sets of devices 
>> within one LLN (whether we use non-link-local or link-local in the 
>> outer header). To me it sounds like we are trying to offer what a 
>> storing network provides without actually storing any information on 
>> the routers. For unicasts, in RPL, this done by offloading the burden 
>> of storing routing information onto the RPL root node (i.e. 
>> source-routing). This works for unicasts, but it wouldn't work for 
>> multicasts.
>>
>>
>>>
>>>>> For example, how does MPL support an application that subscribes 
>>>>> to a well-known non-link-local IPv6 multicast address?  I guess 
>>>>> one approach is to say that if the IPv6 multicast address is not a 
>>>>> unicast-prefix-based multicast address, then it disseminates 
>>>>> across the entire region of connected MPL forwarders.
>>>> Granted one could have a situation where all routers hear an mc 
>>>> packet that is only intended for a subset of devices, but that does 
>>>> not mean all routers need to forward that packet or pass it to a 
>>>> higher layer. Again, this would depend on the inner mc address and 
>>>> the routing information available to routers. The routers without 
>>>> the appropriate routing information would not forward. Similarly, 
>>>> routers without mc membership information from an app would not 
>>>> pass the packet to the next higher layer.
>>> We have different thoughts on how a device determines whether or not 
>>> to forward the packet.  You take a routing perspective, where a 
>>> device determines whether or not to forward based on the identifier 
>>> for the application endpoints.  In contrast, I view it as a device 
>>> determines whether or not to forward based on the Dissemination 
>>> Region it is in.  Note that in my view, the Dissemination Region 
>>> does not have to have any relationship with the identifier for 
>>> application endpoints.  In other words, you can configure the 
>>> Dissemination Region without any knowledge of the multicast 
>>> addresses that devices are interested in.
>>
>> OK I  see your point of view more clearly now. I assume then that a 
>> Dissemination Region would be defined by a non-link-local mc address 
>> prefix, and if so, how would MPL routers become aware of it? Without 
>> it how would a router be able to differentiate one Dissemination 
>> Region from another?
>>
>>
>>>
>>>>> One minor point with your approach is that the delivery requires 
>>>>> processing the MPL Option of the outer header and the inner IPv6 
>>>>> header.  That isn't so nice from an architectural perspective, but 
>>>>> that is what we did with RFC 6553.
>>>> Using non-link-local in the outer header does not mitigate that. 
>>>> The forwarder still needs to look at the inner header to determine 
>>>> if the inner mc address is one an app is listening on. In fact 
>>>> implementing this is a bit messy compared to my approach, because 
>>>> the forwarder has to look ahead into the packet before 
>>>> decapsulating. My approach always requires decapsulation before 
>>>> making any decision about where the packet must go next. It's 
>>>> simpler and more consistent. I've actually had the 
>>>> fortune/misfortune of implementing both and I can safely say the 
>>>> link-local approach was cleaner.
>>> I'd argue that using non-link-local in the outer header helps to 
>>> preserve the layering.
>>> 1) Processing the outer header allows a device to determine whether 
>>> it is a part of the Dissemination Region and the packet was received 
>>> before.
>>> 2) Processing the inner header allows a device to determine whether 
>>> it should process the payload.
>>>
>>> Can you explain why a device needs to "look ahead" into the packet 
>>> before decapsulating when using a non-link-local outer header?
>>
>> Lets say the packet has outer and inner destination addresses 
>> [FF05::1234] and [FF05::5678], respectively. An app on a device 
>> receiving this packet, might be interested in [FF05::1234] or 
>> [FF05::5678] or both. Which version of the packet gets passed up: The 
>> entire MPL encapsulated one or just the inner packet or both. To get 
>> around this, I had to add a hack that would do two things:
>> 1. If the network device is a member of [FF05::1234] and there is no 
>> IPv6-in-IPv6 encapsulation, then pass the packet up.
>> 2. If there is IPv6-in-IPv6 encapsulation and there is a MPL HbH 
>> option and the network device is a member of [FF05::5678], then 
>> decapsulate and pass the inner packet up.
>>
>> Note that logic 2. required looking ahead at the inner header to 
>> determine if the mc address there was an address some higher layer 
>> was interested in. What made things even less palatable, was having 
>> to skip over potential extended headers just to determine whether or 
>> not the packet was encapsulated. Aside from passing mc packets up, 
>> the hack was also needed to decrement the hop-limit when forwarding.
>>
>> Back then, there was no idea of having an IANA assigned MPL mc-group 
>> so I could not rely on a well-known non-link-local address. With a 
>> well-known MPL address a MPL router would be able to be a member of 
>> that group and always try decapsulate upon hearing a packet destined 
>> for that address. Without this MPL mc address using the link-local 
>> all-routers mc address, removed the need for the hack. This was 
>> because all routers are members of the all-routers group.
>>
>>
>>
>>>
>>>>> In my approach (allow non-link-local in the outer header), I tried 
>>>>> to separate out the identifiers for the application endpoints and 
>>>>> the MPL domain.  That is why I used the outer header's destination 
>>>>> address to identify the MPL domain and the inner header's 
>>>>> destination address to identify the application endpoints.  With 
>>>>> this approach, it actually becomes feasible to address situations 
>>>>> where the devices within an MPL domain subscribe to arbitrary IPv6 
>>>>> multicast addresses - not just ones that are based on the unicast 
>>>>> prefix.
>>>> Firstly, yes I agree the inner destination address should determine 
>>>> the application endpoint. What I'm not clear on is why we need an 
>>>> MPL domain to cover more than the LLN or why we need to support 
>>>> multiple MPL domains in one LLN. Tf the latter case is required to 
>>>> allow for different sets of MPL propagation parameters, then I'd 
>>>> imagine that should rather be handled by the HbH option.
>>> Peter's use case involves having multiple Dissemination Regions 
>>> within a single IEEE 802.15.4 PAN.  I agree, one could argue whether 
>>> the devices should all be within the same PAN or different PANs 
>>> based on the nearest border router.
>>
>>  Or an argument for having multiple Destination Regions identified by 
>> some field in the HbH option.
>>
>>
>>>
>>> During the WG meeting, people made a good argument that we actually 
>>> don't know the answer - either because all the use cases are not 
>>> obvious or because we don't understand all the consequences of each 
>>> approach.  One proposal was to have the draft specify well-defined 
>>> forwarding behavior that supports both situations.  For example:
>>> 1) If the outer header has an IPv6 Destination Address matching the 
>>> link-local all-MPL-forwarders address, do …
>>> 2) Otherwise, do …
>>>
>>> Then leave it up to those who are using this spec to determine what 
>>> subset they want to use.  Not sure if this is a reasonable approach 
>>> and would like to get feedback from the WG.
>>
>> My current implementation is just such a hybrid, except that action 1 
>> is decided by scope and not the full address. From an implementation 
>> point of view, I'd prefer not to have two code paths, but if it 
>> satisfies everyone's needs and we have an IANA assigned address, I 
>> can live with it. :-)
>>
>> - Dario
>>
>>
>>
>>
>


--------------030505070407020106090804
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: 8bit


  
    
  
  
    Actually, I missed something. I should have said:

    

    Non-link-local would be fine with the following caveats:

    
    
      
  1. A non-link-local mc address that *uniquely* identifies the MPL
        domain must exist, whether it be IANA assigned or determined at
        run-time.  
    2. 
      
  2. A packet injected into an MPL domain that has a mc address
        that does not match the MPL domain address must be tunneled.
    
      
    3. 
    

    - Dario

    

    On 09/11/2012 11:35 AM, Dario Tedeschi wrote:
    

      

      After some lengthy discussions, Owen Kirby and I think the use of
      a non-link-local mc address in the outer header is fine as long as
      that address *uniquely* identifies the MPL domain (whether it be
      IANA assigned or determined at run-time).
      

      

      - Dario
      

      

      

      

      On 08/11/2012 5:40 PM, Dario Tedeschi wrote:
      

      
On 08/11/2012 1:02 PM, Jonathan Hui
        (johui) wrote:
        

        
Hi Dario,
          

          

          On Nov 8, 2012, at 11:10 AM, Dario
          Tedeschi<dat@exegin.com>  wrote:
          

          

          
On 02/11/2012 10:18 PM, Jonathan Hui
            (johui) wrote:
            

            
With your approach (require
              link-local in the outer header), the IPv6 multicast
              address identifies the application endpoints *and* the MPL
              domain.  For that reason, your approach really only needs
              a single identifier to both limit the flooding scope and
              determine the application endpoints.
              

            

            It depends on what you mean by MPL domain. In my view, 
            FF02::MPL identifies the MPL domain, while the inner IPv6
            destination address identifies the application endpoint.
            

          

          Let me introduce a new term to help move the discussion
          forward:  Dissemination Region - a connected set of MPL
          devices that attempt to forward the packet so that all devices
          receive the packet at least once.  Another definition may be:
          a region within which the SeedID must be unique.
          

        

        

        OK, that makes sense to me.
        

        

        

          

          

            
  I can see how that would work (as
              you demonstrated) if we make the restriction that the IPv6
              multicast addresses used within an MPL domain have the
              same prefix that identifies the MPL domain itself.  The
              trouble comes when you want to support the full generality
              that IPv6 multicast addresses used by application
              endpoints can be arbitrary.
              

            

            The "generality", you talk of, is why protocols like MLD
            exist. MLD informs routers of mc addresses other devices are
            interested in. Essentially it provides routing information.
            How could we support the "full generality" of mc addresses
            without this information (whether implied or from something
            like MLD).  With this in mind, I don't understand the need
            for non-link-local scope in the outer header, because the
            "generality" you seek would be determined by the mc address
            of the original packet (i.e. the mc address of the inner
            header). All my approach is really saying is that only the
            original/inner mc address determines how far a packet will
            propagate, regardless of routing domain. MPL could just be
            one of many routing domains a mc packet must traverse before
            reaching its furthermost boundary. Or MPL may be the only
            routing domain, where the mc packet only reaches a sub-set
            of devices within the domain (i.e. a multicast group or a
            set based on unicast-prefix-based mc).
            

          

          The original intent of MPL was to avoid any routing
          information within the Dissemination Region.  A router then
          only maintains state about what multicast addresses are of
          interest to devices within the Dissemination Region.
          

        

        

        Yes I understand, but I'm not sure how we can avoid routing
        information, if we are to support sending to sub-sets of devices
        within one LLN (whether we use non-link-local or link-local in
        the outer header). To me it sounds like we are trying to offer
        what a storing network provides without actually storing any
        information on the routers. For unicasts, in RPL, this done by
        offloading the burden of storing routing information onto the
        RPL root node (i.e. source-routing). This works for unicasts,
        but it wouldn't work for multicasts.
        

        

        

        

          

          

            
For example, how does MPL support an
              application that subscribes to a well-known non-link-local
              IPv6 multicast address?  I guess one approach is to say
              that if the IPv6 multicast address is not a
              unicast-prefix-based multicast address, then it
              disseminates across the entire region of connected MPL
              forwarders.
              

            

            Granted one could have a situation where all routers hear an
            mc packet that is only intended for a subset of devices, but
            that does not mean all routers need to forward that packet
            or pass it to a higher layer. Again, this would depend on
            the inner mc address and the routing information available
            to routers. The routers without the appropriate routing
            information would not forward. Similarly, routers without mc
            membership information from an app would not pass the packet
            to the next higher layer.
            

          

          We have different thoughts on how a device determines whether
          or not to forward the packet.  You take a routing perspective,
          where a device determines whether or not to forward based on
          the identifier for the application endpoints.  In contrast, I
          view it as a device determines whether or not to forward based
          on the Dissemination Region it is in.  Note that in my view,
          the Dissemination Region does not have to have any
          relationship with the identifier for application endpoints. 
          In other words, you can configure the Dissemination Region
          without any knowledge of the multicast addresses that devices
          are interested in.
          

        

        

        OK I  see your point of view more clearly now. I assume then
        that a Dissemination Region would be defined by a non-link-local
        mc address prefix, and if so, how would MPL routers become aware
        of it? Without it how would a router be able to differentiate
        one Dissemination Region from another?
        

        

        

        

          

          

            
One minor point with your approach
              is that the delivery requires processing the MPL Option of
              the outer header and the inner IPv6 header.  That isn't so
              nice from an architectural perspective, but that is what
              we did with RFC 6553.
              

            

            Using non-link-local in the outer header does not mitigate
            that. The forwarder still needs to look at the inner header
            to determine if the inner mc address is one an app is
            listening on. In fact implementing this is a bit messy
            compared to my approach, because the forwarder has to look
            ahead into the packet before decapsulating. My approach
            always requires decapsulation before making any decision
            about where the packet must go next. It's simpler and more
            consistent. I've actually had the fortune/misfortune of
            implementing both and I can safely say the link-local
            approach was cleaner.
            

          

          I'd argue that using non-link-local in the outer header helps
          to preserve the layering.
          

          1) Processing the outer header allows a device to determine
          whether it is a part of the Dissemination Region and the
          packet was received before.
          

          2) Processing the inner header allows a device to determine
          whether it should process the payload.
          

          

          Can you explain why a device needs to "look ahead" into the
          packet before decapsulating when using a non-link-local outer
          header?
          

        

        

        Lets say the packet has outer and inner destination addresses
        [FF05::1234] and [FF05::5678], respectively. An app on a device
        receiving this packet, might be interested in [FF05::1234] or
        [FF05::5678] or both. Which version of the packet gets passed
        up: The entire MPL encapsulated one or just the inner packet or
        both. To get around this, I had to add a hack that would do two
        things:
        

        1. If the network device is a member of [FF05::1234] and there
        is no IPv6-in-IPv6 encapsulation, then pass the packet up.
        

        2. If there is IPv6-in-IPv6 encapsulation and there is a MPL HbH
        option and the network device is a member of [FF05::5678], then
        decapsulate and pass the inner packet up.
        

        

        Note that logic 2. required looking ahead at the inner header to
        determine if the mc address there was an address some higher
        layer was interested in. What made things even less palatable,
        was having to skip over potential extended headers just to
        determine whether or not the packet was encapsulated. Aside from
        passing mc packets up, the hack was also needed to decrement the
        hop-limit when forwarding.
        

        

        Back then, there was no idea of having an IANA assigned MPL
        mc-group so I could not rely on a well-known non-link-local
        address. With a well-known MPL address a MPL router would be
        able to be a member of that group and always try decapsulate
        upon hearing a packet destined for that address. Without this
        MPL mc address using the link-local all-routers mc address,
        removed the need for the hack. This was because all routers are
        members of the all-routers group.
        

        

        

        

        

          

          

            
In my approach (allow non-link-local
              in the outer header), I tried to separate out the
              identifiers for the application endpoints and the MPL
              domain.  That is why I used the outer header's destination
              address to identify the MPL domain and the inner header's
              destination address to identify the application
              endpoints.  With this approach, it actually becomes
              feasible to address situations where the devices within an
              MPL domain subscribe to arbitrary IPv6 multicast addresses
              - not just ones that are based on the unicast prefix.
              

            

            Firstly, yes I agree the inner destination address should
            determine the application endpoint. What I'm not clear on is
            why we need an MPL domain to cover more than the LLN or why
            we need to support multiple MPL domains in one LLN. Tf the
            latter case is required to allow for different sets of MPL
            propagation parameters, then I'd imagine that should rather
            be handled by the HbH option.
            

          

          Peter's use case involves having multiple Dissemination
          Regions within a single IEEE 802.15.4 PAN.  I agree, one could
          argue whether the devices should all be within the same PAN or
          different PANs based on the nearest border router.
          

        

        

         Or an argument for having multiple Destination Regions
        identified by some field in the HbH option.
        

        

        

        

          

          During the WG meeting, people made a good argument that we
          actually don't know the answer - either because all the use
          cases are not obvious or because we don't understand all the
          consequences of each approach.  One proposal was to have the
          draft specify well-defined forwarding behavior that supports
          both situations.  For example:
          

          1) If the outer header has an IPv6 Destination Address
          matching the link-local all-MPL-forwarders address, do …
          

          2) Otherwise, do …
          

          

          Then leave it up to those who are using this spec to determine
          what subset they want to use.  Not sure if this is a
          reasonable approach and would like to get feedback from the
          WG.
          

        

        

        My current implementation is just such a hybrid, except that
        action 1 is decided by scope and not the full address. From an
        implementation point of view, I'd prefer not to have two code
        paths, but if it satisfies everyone's needs and we have an IANA
        assigned address, I can live with it. :-)
        

        

        - Dario
        

        

        

        

        

      

      

    

    

  


--------------030505070407020106090804--

From jvasseur@cisco.com  Mon Nov 12 03:12:20 2012
Return-Path: 
X-Original-To: roll@ietfa.amsl.com
Delivered-To: roll@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF9FF21F8514 for ; Mon, 12 Nov 2012 03:12:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.49
X-Spam-Level: 
X-Spam-Status: No, score=-10.49 tagged_above=-999 required=5 tests=[AWL=0.109,  BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4pyDK4jUE9DW for ; Mon, 12 Nov 2012 03:12:20 -0800 (PST)
Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 18E0521F84BC for ; Mon, 12 Nov 2012 03:12:20 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=875; q=dns/txt; s=iport; t=1352718740; x=1353928340; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=qUw+S/PCjdX/8zv+HBdG9wqCe98jtM8QRghAK7m62ww=; b=aGFzJrltxnpFMEgM/Fgl/F8STqdK0WbpEdPXV8L79lwDyvTN/SiwW5vG 6O94X6N1VGbo5aZfryMwppKL3nx8Vf0rhlBzKwuMWcY4e0YuQcnqeMZJf rbWlEEy/LT1uLUR+dlMwtA/IkDptLeUXyd+KNJQbvUkC8DOAzl+W59+1P M=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AjMHAHfYoFCtJV2b/2dsb2JhbABEhVO8CQGBeoEIgh4BAQEDAQEBAQ8BJzQLBQsCASoUECcLJQIEAQ0FCBqHYgYLmmWfNQSMFSSFRWEDpFSBa4Jvghk
X-IronPort-AV: E=McAfee;i="5400,1158,6893"; a="141239412"
Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-7.cisco.com with ESMTP; 12 Nov 2012 11:12:19 +0000
Received: from xhc-rcd-x08.cisco.com (xhc-rcd-x08.cisco.com [173.37.183.82]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id qACBCJ4a001062 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 12 Nov 2012 11:12:19 GMT
Received: from xmb-rcd-x02.cisco.com ([169.254.4.241]) by xhc-rcd-x08.cisco.com ([173.37.183.82]) with mapi id 14.02.0318.001; Mon, 12 Nov 2012 05:12:19 -0600
From: "JP Vasseur (jvasseur)" 
To: "roll@ietf.org WG" , "Jonathan Hui (johui)" 
Thread-Topic: END of WG LC -- Re: [Roll] WG Last Call draft-ietf-roll-trickle-mcast-02
Thread-Index: AQHNsn26aiFXfsVin0Sq6ZVjYiOAPpfmeaGA
Date: Mon, 12 Nov 2012 11:12:18 +0000
Message-ID: <03B78081B371D44390ED6E7BADBB4A77220865A5@xmb-rcd-x02.cisco.com>
References: <03B78081B371D44390ED6E7BADBB4A77220226E7@xmb-rcd-x02.cisco.com>
In-Reply-To: <03B78081B371D44390ED6E7BADBB4A77220226E7@xmb-rcd-x02.cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.21.122.80]
x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19356.005
x-tm-as-result: No--46.516200-8.000000-31
x-tm-as-user-approved-sender: No
x-tm-as-user-blocked-sender: No
Content-Type: text/plain; charset="us-ascii"
Content-ID: <3671CAC20BCF124B91D2E872E6F7F4D3@cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: Michael Richardson 
Subject: [Roll] END of WG LC -- Re: WG Last Call draft-ietf-roll-trickle-mcast-02
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Routing Over Low power and Lossy networks 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 12 Nov 2012 11:12:20 -0000

Dear all,

The WG LC has now ended and led to a number of comments (thanks!) and open =
tickets. Let's now address the tickets one
by one (since as discussed during the WG, there is no further need to run i=
t by other WG) and we may re-issue another short
LC.

Thanks.

JP.

On Oct 25, 2012, at 8:55 AM, JP Vasseur (jvasseur) wrote:

> Dear all,
>=20
> draft-ietf-roll-trickle-mcast-02  has been discussed on the mailing list =
and during WG meeting a number of time; the document is stable and=20
> has been implemented. Thus this starts a 2-week WG Last call ending on No=
v 9 at noon ET. Please send your comments to the authors=20
> and copy the mailing list and the co-chairs.
>=20
> Thanks.
>=20
> JP.
>=20
> _______________________________________________
> Roll mailing list
> Roll@ietf.org
> https://www.ietf.org/mailman/listinfo/roll


From jvasseur@cisco.com  Mon Nov 12 03:12:21 2012
Return-Path: 
X-Original-To: roll@ietfa.amsl.com
Delivered-To: roll@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D573421F854C for ; Mon, 12 Nov 2012 03:12:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.492
X-Spam-Level: 
X-Spam-Status: No, score=-10.492 tagged_above=-999 required=5 tests=[AWL=0.106, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cdVh7LZoCdUH for ; Mon, 12 Nov 2012 03:12:21 -0800 (PST)
Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 0225F21F84BC for ; Mon, 12 Nov 2012 03:12:20 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4802; q=dns/txt; s=iport; t=1352718741; x=1353928341; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=nMbCf93SXqQFw3UDYwP/0qIVCrsYlYhgZp6iGnsxcmQ=; b=dJxOyZcQi2dIedXrLIBTND7LKqGnrFT/uEi1f/BRP6fZOnOG4BhD4Vru NCGmAeH18lRiTS+UZQ2n2TxDAxRSzeCaN01zgi8ME0gC4ZWamxjWihQUW dPcX2ixB25pxO6AX4x4M+aSckSYfMVrurykNi1s0pttu4RFZ7xBsjJ3Er s=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av8EAO/YoFCtJXHA/2dsb2JhbABEgknBDoEIgh8BAQQBAQEPAVsbAgEIBB4dBycLFBECBBMIEweHaAuaZJ81BIwVhWlhA6RUgWuCb4IZ
X-IronPort-AV: E=McAfee;i="5400,1158,6893"; a="141026055"
Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-1.cisco.com with ESMTP; 12 Nov 2012 11:12:20 +0000
Received: from xhc-rcd-x09.cisco.com (xhc-rcd-x09.cisco.com [173.37.183.83]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id qACBCKgF025356 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 12 Nov 2012 11:12:20 GMT
Received: from xmb-rcd-x02.cisco.com ([169.254.4.241]) by xhc-rcd-x09.cisco.com ([173.37.183.83]) with mapi id 14.02.0318.001; Mon, 12 Nov 2012 05:12:19 -0600
From: "JP Vasseur (jvasseur)" 
To: roll WG 
Thread-Topic: [Roll] WG Last Call draft-ietf-roll-security-threats
Thread-Index: AQHNrO+4vJffuTmqFkeNA/oIwWSGlpfmhUyA
Date: Mon, 12 Nov 2012 11:12:19 +0000
Message-ID: <03B78081B371D44390ED6E7BADBB4A77220865B0@xmb-rcd-x02.cisco.com>
References: <03B78081B371D44390ED6E7BADBB4A7721FF384D@xmb-rcd-x02.cisco.com>
In-Reply-To: <03B78081B371D44390ED6E7BADBB4A7721FF384D@xmb-rcd-x02.cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.21.122.80]
x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19356.005
x-tm-as-result: No--44.428300-8.000000-31
x-tm-as-user-approved-sender: No
x-tm-as-user-blocked-sender: No
Content-Type: multipart/alternative; boundary="_000_03B78081B371D44390ED6E7BADBB4A77220865B0xmbrcdx02ciscoc_"
MIME-Version: 1.0
Subject: Re: [Roll] WG Last Call draft-ietf-roll-security-threats
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Routing Over Low power and Lossy networks 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 12 Nov 2012 11:12:22 -0000

--_000_03B78081B371D44390ED6E7BADBB4A77220865B0xmbrcdx02ciscoc_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Dear all,

The WG LC has now ended, without objection. Will proceed with Publication R=
equest.

Thanks.

JP.

On Oct 18, 2012, at 7:16 AM, JP Vasseur (jvasseur) wrote:

Dear all,

As you know, we have been discussing security framework document in the WG,=
 which is one of our WG item.

draft-ietf-roll-security-threats-00 is a revision of draft-ietf-roll-securi=
ty-framework-07 that has been reviewed in great
details by the WG and IESG, waiting for 400 days.  The title has been chang=
ed, and the focus of the document is on
security threats, rather than solutions, in line with our ROLL WG item:

Sep 2012        Submit first draft of RPL threat analysis to the IESG to be=
 considered as an Informational RFC

Section 7 was removed: this is the result of negotiation with the IESG on w=
here and how security issues will be addressed.

The goal of this new document is to outline threats with the expectation th=
at applicability statements will have to cover
(i.e. mitigate or solve) these threats in some way.  Please read this docum=
ent and ask if the questions it asks are clear
enough.

This starts a WG Last call, ending on Nov 9, at noon ET. Please send your q=
uestions and comments to the authors, copying
the mailing list.

Thanks.

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


--_000_03B78081B371D44390ED6E7BADBB4A77220865B0xmbrcdx02ciscoc_
Content-Type: text/html; charset="us-ascii"
Content-ID: 
Content-Transfer-Encoding: quoted-printable






Dear all,






The WG LC has now ended, without objection. Will proceed with Publicat=
ion Request.







Thanks.







JP.











On Oct 18, 2012, at 7:16 AM, JP Vasseur (jvasseur) wrote:







Dear all,






As you know, we have been discussing security framework document in th=
e WG, which is one of our WG item.







draft-ietf-roll-security-threats-00 is a revision of draft-ietf-r=
oll-security-framework-07 that has been reviewed in great


details by the WG and IESG, waiting for 400 days.  The title has =
been changed, and the focus of the document is on 


security threats, rather than solutions, in line with our ROLL WG item=
:













Sep 2012
Submit first draft of RPL threat analysis to the IESG to be considered =
as an Informational RFC













Section 7 was removed: this is the result of negotiation with the IESG=
 on where and how security issues will be addressed.  



The goal of this new document is to outline threats with the expectation&nb=
sp;that applicability statements will have to cover 


(i.e. mitigate or solve) these threats in some way.  Please =
read this document and ask if the questions it asks are clear 

enough.






This starts a WG Last call, ending on Nov 9, at noon ET. Please send y=
our questions and comments to the authors, copying


the mailing list.







Thanks.







JP.



_______________________________________________

Roll mailing list

Roll@ietf.org

https://www.ietf.org/mailman/listinfo/roll












--_000_03B78081B371D44390ED6E7BADBB4A77220865B0xmbrcdx02ciscoc_--

From thomas@thomasclausen.org  Mon Nov 12 08:06:21 2012
Return-Path: 
X-Original-To: roll@ietfa.amsl.com
Delivered-To: roll@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8901321F868B for ; Mon, 12 Nov 2012 08:06:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.265
X-Spam-Level: 
X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vbny3RGX5SKb for ; Mon, 12 Nov 2012 08:06:21 -0800 (PST)
Received: from morbo.mail.tigertech.net (morbo.mail.tigertech.net [67.131.251.54]) by ietfa.amsl.com (Postfix) with ESMTP id 0A08E21F8618 for ; Mon, 12 Nov 2012 08:06:21 -0800 (PST)
Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) by morbo.tigertech.net (Postfix) with ESMTP id 8A7CD557F7A for ; Mon, 12 Nov 2012 08:06:20 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 0B56D1C08F0; Mon, 12 Nov 2012 08:06:15 -0800 (PST)
X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net
Received: from [192.168.147.111] (mtg91-1-82-227-24-173.fbx.proxad.net [82.227.24.173]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 982B91C08E9; Mon, 12 Nov 2012 08:06:13 -0800 (PST)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
From: Thomas Clausen 
In-Reply-To: <03B78081B371D44390ED6E7BADBB4A77220865A5@xmb-rcd-x02.cisco.com>
Date: Mon, 12 Nov 2012 17:06:11 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <03B78081B371D44390ED6E7BADBB4A77220226E7@xmb-rcd-x02.cisco.com> <03B78081B371D44390ED6E7BADBB4A77220865A5@xmb-rcd-x02.cisco.com>
To: "JP Vasseur (jvasseur)" 
X-Mailer: Apple Mail (2.1499)
Cc: "roll@ietf.org WG" , Michael Richardson , "Jonathan Hui \(johui\)" 
Subject: Re: [Roll] END of WG LC -- Re: WG Last Call draft-ietf-roll-trickle-mcast-02
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Routing Over Low power and Lossy networks 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 12 Nov 2012 16:06:21 -0000

Dear JP, Michael, Adrian, All,

Considering that the document was *incomplete* at the last WGLC, I would =
submit that - once that (and other issues) have been addressed - a =
regular-length WGLC is not just a good idea, but is required.

As security isn't a slap-on-as-an-afterthought feature, I can hardly =
imagine that designing security for the protocol would not also cause =
other changes to the specification.

Respectfully yours,

Thomas

On Nov 12, 2012, at 12:12 PM, "JP Vasseur (jvasseur)" =
 wrote:

> Dear all,
>=20
> The WG LC has now ended and led to a number of comments (thanks!) and =
open tickets. Let's now address the tickets one
> by one (since as discussed during the WG, there is no further need to =
run it by other WG) and we may re-issue another short
> LC.
>=20
> Thanks.
>=20
> JP.
>=20
> On Oct 25, 2012, at 8:55 AM, JP Vasseur (jvasseur) wrote:
>=20
>> Dear all,
>>=20
>> draft-ietf-roll-trickle-mcast-02  has been discussed on the mailing =
list and during WG meeting a number of time; the document is stable and=20=

>> has been implemented. Thus this starts a 2-week WG Last call ending =
on Nov 9 at noon ET. Please send your comments to the authors=20
>> and copy the mailing list and the co-chairs.
>>=20
>> Thanks.
>>=20
>> JP.
>>=20
>> _______________________________________________
>> Roll mailing list
>> Roll@ietf.org
>> https://www.ietf.org/mailman/listinfo/roll
>=20
> _______________________________________________
> Roll mailing list
> Roll@ietf.org
> https://www.ietf.org/mailman/listinfo/roll


From mcr@sandelman.ca  Mon Nov 12 14:14:29 2012
Return-Path: 
X-Original-To: roll@ietfa.amsl.com
Delivered-To: roll@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 531B421F8683 for ; Mon, 12 Nov 2012 14:14:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.855
X-Spam-Level: 
X-Spam-Status: No, score=-1.855 tagged_above=-999 required=5 tests=[AWL=0.099,  BAYES_00=-2.599, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e5EuDjFFHtwB for ; Mon, 12 Nov 2012 14:14:28 -0800 (PST)
Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by ietfa.amsl.com (Postfix) with ESMTP id D7F2521F8626 for ; Mon, 12 Nov 2012 14:14:28 -0800 (PST)
Received: from sandelman.ca (unknown [75.98.19.134]) by relay.sandelman.ca (Postfix) with ESMTPS id 2B03E81A9 for ; Mon, 12 Nov 2012 17:06:06 -0500 (EST)
Received: from sandelman.ca (quigon.sandelman.ca [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 411AECA0C7 for ; Mon, 12 Nov 2012 17:14:02 -0500 (EST)
From: Michael Richardson 
To: "" 
In-reply-to: <509DAFEF.5020504@exegin.com>
References: <058.e817419e990e1afb26be9aa25d5cfc21@trac.tools.ietf.org>  <50932647.3050509@exegin.com>  <5094202F.4010805@exegin.com>  <509C03C2.50809@exegin.com>  <509C5F00.2050204@exegin.com> <509D5AF5.4040304@exegin.com> <509DAFEF.5020504@exegin.com>
Comments: In-reply-to Dario Tedeschi  message dated "Fri, 09 Nov 2012 17:37:51 -0800."
X-Mailer: MH-E 8.3; nmh 1.3; XEmacs 21.4 (patch 22)
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature"
Date: Mon, 12 Nov 2012 17:14:02 -0500
Message-ID: <9143.1352758442@sandelman.ca>
Sender: mcr@sandelman.ca
Subject: Re: [Roll] [roll] #105: trickle-mcast: how to determine scope of MPL domain
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Routing Over Low power and Lossy networks 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 12 Nov 2012 22:14:29 -0000

--=-=-=
Content-Transfer-Encoding: quoted-printable


see inline

>>>>> "Dario" =3D=3D Dario Tedeschi  writes:
    Dario> Non-link-local would be fine with the following caveats:

    Dario> 1. A non-link-local mc address that *uniquely* identifies the MPL
    Dario> domain must exist, whether it be IANA assigned or determined at
    Dario> run-time.

    Dario> 2. A packet injected into an MPL domain that has a mc address th=
at does
    Dario> not match the MPL domain address must be tunneled.

okay...
a packet with a link-local mc address does not need tunnelling, because,
by definition, it can not leave the MPL domain, so it never needs
tunnelling?

=2D-=20
Michael Richardson , Sandelman Software Works=20



--=-=-=
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)

iQEcBAABAgAGBQJQoXSpAAoJEKD0KQ7Gj3P2R0YH/23JZNwygqGcGxO5DDKrRQs6
GDopDn9dfyov3LGmoKeHGkTRS+TYWviOirEovO6+I26opwo5OlU+B9rt9zWf8mO6
XU85BwzuM3iCRRyHVN9MMIXUrfXgfbGpU6Bnu3l7AQ9nW8sH1triC16a+2PKllTR
q1tarPsQKnLKq9U6BneK543ihW8DYyX40WPPYzu9+DyYZ5zYe9EPrlrDOZg0jAbj
qeaQLratMO23Dyi1J0vni8hh/0p774Lis+DFWWIFgQymHRUu8GnfPSv/ZZ9PEZeR
A1Z/o5JI9wAdvmoUXCww6mGNVhD10+bwQhFNOT00G7MKlgGGmWlwHWMbs1Pz7yU=
=pm7e
-----END PGP SIGNATURE-----
--=-=-=--

From mcr@sandelman.ca  Mon Nov 12 14:17:36 2012
Return-Path: 
X-Original-To: roll@ietfa.amsl.com
Delivered-To: roll@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 429A721F866B for ; Mon, 12 Nov 2012 14:17:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.895
X-Spam-Level: 
X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[AWL=0.059,  BAYES_00=-2.599, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ci5EVNxWNA0W for ; Mon, 12 Nov 2012 14:17:35 -0800 (PST)
Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by ietfa.amsl.com (Postfix) with ESMTP id DA11321F860F for ; Mon, 12 Nov 2012 14:17:35 -0800 (PST)
Received: from sandelman.ca (unknown [75.98.19.134]) by relay.sandelman.ca (Postfix) with ESMTPS id A8ACE81A9; Mon, 12 Nov 2012 17:08:59 -0500 (EST)
Received: from sandelman.ca (quigon.sandelman.ca [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id A3114CA0BC; Mon, 12 Nov 2012 17:07:40 -0500 (EST)
From: Michael Richardson 
To: consultancy@vanderstok.org
In-reply-to: <109e9168af966b0ee543f13886fef7ef@xs4all.nl>
References: <058.e817419e990e1afb26be9aa25d5cfc21@trac.tools.ietf.org>  <50932647.3050509@exegin.com>  <5094202F.4010805@exegin.com>  <509C03C2.50809@exegin.com>  <509C5F00.2050204@exegin.com> <109e9168af966b0ee543f13886fef7ef@xs4all.nl>
Comments: In-reply-to peter van der Stok  message dated "Fri, 09 Nov 2012 15:23:48 +0100."
X-Mailer: MH-E 8.3; nmh 1.3; XEmacs 21.4 (patch 22)
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature"
Date: Mon, 12 Nov 2012 17:07:40 -0500
Message-ID: <8796.1352758060@sandelman.ca>
Sender: mcr@sandelman.ca
Cc: roll@ietf.org
Subject: Re: [Roll] [roll] #105: trickle-mcast: how to determine scope of MPL domain
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Routing Over Low power and Lossy networks 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 12 Nov 2012 22:17:36 -0000

--=-=-=
Content-Transfer-Encoding: quoted-printable


splitting up your text to emphasize a few things:

>>>>> "peter" =3D=3D peter van der Stok  writes:
    peter> The nodes in all networks use the same communication channel.

...

    peter> not forward the message.  In this network configuration the
    peter> dissemination area is identical with a network.  From a cost
    peter> perspective (less border routers) it is more realistic if one
    peter> network covers the whole floor.=20

But, in your diagram, you have 6 border routers?!?

I don't understand why nodes in area1 and area2 should use the same
communication channel.=20=20

=2D-=20
Michael Richardson , Sandelman Software Works=20



--=-=-=
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)

iQEcBAABAgAGBQJQoXMsAAoJEKD0KQ7Gj3P27T4H/0D21bqqpsSHw9lIoBwFUNph
2XCPKs4mFCKbZN9ETgZmsLcgVqiP64QyAcPTbS3NBDA6MMlammk3GBxUq4J+IHUB
lt0glreHdkUJ0rx9WZ1Z7Ie7o045LZMk/uureckOn+SxeGOCTxRj7J+L8Qp4aw44
dV6CeU88DnlkV4yzpcfBeM8VIX/dnjC77KL2BQMNMgHpxVEdEPRimIUz++rMUYPu
KKD4JeFWBpH9ZbPT/Xi0KA2uqto9RoTu8UDV94+ifdvVJBgVbvaj21F05ijpYG+Y
uDtmPQaA2y2OAQU0SnpuC0O+atDHnKLl8cAu3IFmW17YFPcMax9Hwq3QYp2imNY=
=CDgN
-----END PGP SIGNATURE-----
--=-=-=--

From stokcons@xs4all.nl  Wed Nov 14 00:39:03 2012
Return-Path: 
X-Original-To: roll@ietfa.amsl.com
Delivered-To: roll@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F99B21F8922 for ; Wed, 14 Nov 2012 00:39:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.542
X-Spam-Level: 
X-Spam-Status: No, score=0.542 tagged_above=-999 required=5 tests=[AWL=-0.813,  BAYES_20=-0.74, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0kjggqcvCzA7 for ; Wed, 14 Nov 2012 00:39:02 -0800 (PST)
Received: from smtp-vbr15.xs4all.nl (smtp-vbr15.xs4all.nl [194.109.24.35]) by ietfa.amsl.com (Postfix) with ESMTP id 12EE321F8876 for ; Wed, 14 Nov 2012 00:39:01 -0800 (PST)
Received: from roundcube.xs4all.nl (roundcube11.xs4all.net [194.109.20.209]) by smtp-vbr15.xs4all.nl (8.13.8/8.13.8) with ESMTP id qAE8cS6M093981; Wed, 14 Nov 2012 09:38:28 +0100 (CET) (envelope-from stokcons@xs4all.nl)
Received: from a82-95-140-48.adsl.xs4all.nl ([82.95.140.48]) by roundcube.xs4all.nl with HTTP (HTTP/1.1 POST); Wed, 14 Nov 2012 09:38:28 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Date: Wed, 14 Nov 2012 09:38:28 +0100
From: peter van der Stok 
To: Michael Richardson 
Organization: vanderstok consultancy
Mail-Reply-To: 
In-Reply-To: <8796.1352758060@sandelman.ca>
References: <058.e817419e990e1afb26be9aa25d5cfc21@trac.tools.ietf.org>  <50932647.3050509@exegin.com>  <5094202F.4010805@exegin.com>  <509C03C2.50809@exegin.com>  <509C5F00.2050204@exegin.com> <109e9168af966b0ee543f13886fef7ef@xs4all.nl> <8796.1352758060@sandelman.ca>
Message-ID: <895d55da5f389dc29760cd52aaf91d61@xs4all.nl>
X-Sender: stokcons@xs4all.nl (d1rGJMmIvMYxW2WAy0+zHpUvq13TZuhN)
User-Agent: XS4ALL Webmail
X-Virus-Scanned: by XS4ALL Virus Scanner
Cc: roll@ietf.org
Subject: Re: [Roll] [roll] #105: trickle-mcast: how to determine scope of MPL domain
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: consultancy@vanderstok.org
List-Id: Routing Over Low power and Lossy networks 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 14 Nov 2012 08:39:03 -0000

Hi Michael,

sorry to be confusing.

Again, this is not a real installation, just an example of what to 
expect.
Surface area can be something like 100x30 square meters.

I show 6 border routers coinciding with 6 disseminatiuon areas due to a 
remark by Dario where he asked if it is possible that multiple 
disseminations areas can be present in one PAN.
The answer is yes, because giving a border router to each dissemination 
area (6) is quite expensive.

Concerning the use of the same channel.
When we have one PAN, one channel is used, that is clear.
Having several PANs, it perspires that often only 2 channels of the 
ones specified by 802.15.4 provide good communication ([presence of 
802.11, etc.).

Several other additional organisational boundary conditions can dictate 
the channel numbers.

Hope this helps,

peter


Michael Richardson schreef op 2012-11-12 23:07:
> splitting up your text to emphasize a few things:
>
>>>>>> "peter" == peter van der Stok  writes:
>     peter> The nodes in all networks use the same communication 
> channel.
>
> ...
>
>     peter> not forward the message.  In this network configuration 
> the
>     peter> dissemination area is identical with a network.  From a 
> cost
>     peter> perspective (less border routers) it is more realistic if 
> one
>     peter> network covers the whole floor.
>
> But, in your diagram, you have 6 border routers?!?
>
> I don't understand why nodes in area1 and area2 should use the same
> communication channel.


From robert.cragie@gridmerge.com  Wed Nov 14 03:37:38 2012
Return-Path: 
X-Original-To: roll@ietfa.amsl.com
Delivered-To: roll@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6B0A21F8546 for ; Wed, 14 Nov 2012 03:37:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.332
X-Spam-Level: 
X-Spam-Status: No, score=-2.332 tagged_above=-999 required=5 tests=[AWL=0.266,  BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VRvDrNdoF5ci for ; Wed, 14 Nov 2012 03:37:38 -0800 (PST)
Received: from mail41.extendcp.co.uk (mail41.extendcp.co.uk [79.170.44.41]) by ietfa.amsl.com (Postfix) with ESMTP id C0CE521F84E8 for ; Wed, 14 Nov 2012 03:37:37 -0800 (PST)
Received: from client-86-29-206-117.glfd-bam-2.adsl.virginmedia.com ([86.29.206.117] helo=[192.168.0.2]) by mail41.extendcp.com with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.77) id 1TYbHj-0002Vw-Oo for roll@ietf.org; Wed, 14 Nov 2012 11:37:36 +0000
Message-ID: <50A382DA.9030706@gridmerge.com>
Date: Wed, 14 Nov 2012 11:39:06 +0000
From: Robert Cragie 
Organization: Gridmerge Ltd.
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121026 Thunderbird/16.0.2
MIME-Version: 1.0
To: roll@ietf.org
References: <058.e817419e990e1afb26be9aa25d5cfc21@trac.tools.ietf.org>  <50932647.3050509@exegin.com>  <5094202F.4010805@exegin.com>  <509C03C2.50809@exegin.com>  <509C5F00.2050204@exegin.com> <509D5AF5.4040304@exegin.com> <509DAFEF.5020504@exegin.com> <9143.1352758442@sandelman.ca>
In-Reply-To: <9143.1352758442@sandelman.ca>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms070101080703020002050400"
X-Authenticated-As: robert.cragie@gridmerge.com
Subject: Re: [Roll] [roll] #105: trickle-mcast: how to determine scope of MPL domain
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: robert.cragie@gridmerge.com
List-Id: Routing Over Low power and Lossy networks 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 14 Nov 2012 11:37:38 -0000

This is a cryptographically signed message in MIME format.

--------------ms070101080703020002050400
Content-Type: multipart/alternative;
 boundary="------------010500090706050608050400"

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


On 12/11/2012 10:14 PM, Michael Richardson wrote:
> see inline
>
>>>>>> "Dario" =3D=3D Dario Tedeschi  writes:
>      Dario> Non-link-local would be fine with the following caveats:
>
>      Dario> 1. A non-link-local mc address that *uniquely* identifies t=
he MPL
>      Dario> domain must exist, whether it be IANA assigned or determine=
d at
>      Dario> run-time.
>
>      Dario> 2. A packet injected into an MPL domain that has a mc addre=
ss that does
>      Dario> not match the MPL domain address must be tunneled.
>
> okay...
> a packet with a link-local mc address does not need tunnelling, because=
,
> by definition, it can not leave the MPL domain, so it never needs
> tunnelling?

It's not quite as simple as that:

 1. A packet with a link-local mc address doesn't need tunnelling and
    doesn't need trickle multicast as it is intended to go only one hop
    and is therefore sent using link-layer broadcast without any MPL opti=
on.
 2. We have generally used the term "subnet-local" in the case of where
    the MPL domain covers the multi-link subnet exactly. If the
    originator is in the MPL domain, and all the intended recipients are
    in the MPL domain, then any packet forwarded by a MPL forwarder will =
be:
     1. Unencapsulated
     2. Have subnet-local mc address (e.g. FF03-based)
     3. Have a MPL option
 3. There is the other case where if the originator is not in the MPL
    domain or at least one of the intended recipients is not in the MPL
    domain (scope rules), then any packet forwarded by a MPL forwarder
    will be:
     1. Encapsulated
     2. Outer header will have subnet-local mc address (e.g.
        FF03-based). This can be used to control propagation in
        conjunction with the MPL option.
     3. Outer header will have a MPL option
     4. Inner header will have site local mc address (e.g. FF05-based).
        This will be tunnelled to multicast exit points
     5. Inner header will not have a MPL option
 4. The alternative to (3) is to use link-local mc address in
    conjunction with a MPL option:
     1. Encapsulated
     2. Outer header will have link-local mc address (e.g. FF02-based).
        This cannot be used to control propagation as it only goes one
        hop; the MPL option is used alone
     3. Outer header will have a MPL option
     4. Inner header will have site local mc address (e.g. FF05-based).
        This will not be tunnelled as it is recapsulated every hop
     5. Inner header will not have a MPL option


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


  
    
  
  
    

    
On 12/11/2012 10:14 PM, Michael
      Richardson wrote:

    

    

      
see inline



      

        

          

            

              

                
"Dario" =3D=3D Dario Tedeschi <dat@exegin.com&=
gt; writes:


              

            

          

        

      

      
    Dario> Non-link-local would be fine with the =
following caveats:

    Dario> 1. A non-link-local mc address that *uniquely* identifies t=
he MPL
    Dario> domain must exist, whether it be IANA assigned or determine=
d at
    Dario> run-time.

    Dario> 2. A packet injected into an MPL domain that has a mc addre=
ss that does
    Dario> not match the MPL domain address must be tunneled.

okay...
a packet with a link-local mc address does not need tunnelling, because,
by definition, it can not leave the MPL domain, so it never needs
tunnelling?

    

    

    It's not quite as simple as that:

    

    
    
      
  1. A packet with a link-local mc address doesn't need tunnelling
        and doesn't need trickle multicast as it is intended to go only
        one hop and is therefore sent using link-layer broadcast without
        any MPL option.
    2. 
      
  2. We have generally used the term "subnet-local" in the case of
        where the MPL domain covers the multi-link subnet exactly. If
        the originator is in the MPL domain, and all the intended
        recipients are in the MPL domain, then any packet forwarded by a
        MPL forwarder will be:
    3. 
      
      
        
    1. Unencapsulated
      
        
      2. 
        
    2. Have subnet-local mc address (e.g. FF03-based)
      3. 
        
    3. Have a MPL option
      4. 
      
    
      
  3. There is the other case where if the originator is not in the
        MPL domain or at least one of the intended recipients is not in
        the MPL domain (scope rules), then any packet forwarded by a MPL
        forwarder will be:
    4. 
      
      
        
    1. Encapsulated
      2. 
        
    2. Outer header will have subnet-local mc address (e.g.
          FF03-based). This can be used to control propagation in
          conjunction with the MPL option.
      
        
      3. 
        
    3. Outer header will have a MPL option
      4. 
        
    4. Inner header will have site local mc address (e.g.
          FF05-based). This will be tunnelled to multicast exit points
        
      5. 
        
    5. Inner header will not have a MPL option
      6. 
      
    
      
  4. The alternative to (3) is to use link-local mc address in
        conjunction with a MPL option:
    5. 
      
      
        
    1. Encapsulated
      2. 
        
    2. Outer header will have link-local mc address (e.g.
          FF02-based). This cannot be used to control propagation as it
          only goes one hop; the MPL option is used alone
      
        
      3. 
        
    3. Outer header will have a MPL option
      4. 
        
    4. Inner header will have site local mc address (e.g.
          FF05-based). This will not be tunnelled as it is recapsulated
          every hop
      
        
      5. 
        
    5. Inner header will not have a MPL option
      6. 
      
    
    

  


--------------010500090706050608050400--

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

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIILUDCC
BRowggQCoAMCAQICEG0Z6qcZT2ozIuYiMnqqcd4wDQYJKoZIhvcNAQEFBQAwga4xCzAJBgNV
BAYTAlVTMQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoT
FVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3Qu
Y29tMTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQg
RW1haWwwHhcNMTEwNDI4MDAwMDAwWhcNMjAwNTMwMTA0ODM4WjCBkzELMAkGA1UEBhMCR0Ix
GzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UE
ChMRQ09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENPTU9ETyBDbGllbnQgQXV0aGVudGlj
YXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC
ggEBAJKEhFtLV5jUXi+LpOFAyKNTWF9mZfEyTvefMn1V0HhMVbdClOD5J3EHxcZppLkyxPFA
GpDMJ1Zifxe1cWmu5SAb5MtjXmDKokH2auGj/7jfH0htZUOMKi4rYzh337EXrMLaggLW1DJq
1GdvIBOPXDX65VSAr9hxCh03CgJQU2yVHakQFLSZlVkSMf8JotJM3FLb3uJAAVtIaN3FSrTg
7SQfOq9xXwfjrL8UO7AlcWg99A/WF1hGFYE8aIuLgw9teiFX5jSw2zJ+40rhpVJyZCaRTqWS
D//gsWD9Gm9oUZljjRqLpcxCm5t9ImPTqaD8zp6Q30QZ9FxbNboW86eb/8ECAwEAAaOCAUsw
ggFHMB8GA1UdIwQYMBaAFImCZ33EnSZwAEu0UEh83j2uBG59MB0GA1UdDgQWBBR6E04AdFvG
eGNkJ8Ev4qBbvHnFezAOBgNVHQ8BAf8EBAMCAQYwEgYDVR0TAQH/BAgwBgEB/wIBADARBgNV
HSAECjAIMAYGBFUdIAAwWAYDVR0fBFEwTzBNoEugSYZHaHR0cDovL2NybC51c2VydHJ1c3Qu
Y29tL1VUTi1VU0VSRmlyc3QtQ2xpZW50QXV0aGVudGljYXRpb25hbmRFbWFpbC5jcmwwdAYI
KwYBBQUHAQEEaDBmMD0GCCsGAQUFBzAChjFodHRwOi8vY3J0LnVzZXJ0cnVzdC5jb20vVVRO
QWRkVHJ1c3RDbGllbnRfQ0EuY3J0MCUGCCsGAQUFBzABhhlodHRwOi8vb2NzcC51c2VydHJ1
c3QuY29tMA0GCSqGSIb3DQEBBQUAA4IBAQCF1r54V1VtM39EUv5C1QaoAQOAivsNsv1Kv/av
QUn1G1rF0q0bc24+6SZ85kyYwTAo38v7QjyhJT4KddbQPTmGZtGhm7VNm2+vKGwdr+XqdFqo
2rHA8XV6L566k3nK/uKRHlZ0sviN0+BDchvtj/1gOSBH+4uvOmVIPJg9pSW/ve9g4EnlFsjr
P0OD8ODuDcHTzTNfm9C9YGqzO/761Mk6PB/tm/+bSTO+Qik5g+4zaS6CnUVNqGnagBsePdIa
XXxHmaWbCG0SmYbWXVcHG6cwvktJRLiQfsrReTjrtDP6oDpdJlieYVUYtCHVmdXgQ0BCML7q
peeU0rD+83X5f27nMIIGLjCCBRagAwIBAgIQXDFQ28QtqMuYch5f2nTvZjANBgkqhkiG9w0B
AQUFADCBkzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4G
A1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENP
TU9ETyBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTAeFw0xMTA5
MDIwMDAwMDBaFw0xNDA5MDEyMzU5NTlaMIIBNzELMAkGA1UEBhMCR0IxEDAOBgNVBBETB1dG
NCA0V0ExFzAVBgNVBAgTDldlc3QgWW9ya3NoaXJlMRIwEAYDVQQHEwlXYWtlZmllbGQxFDAS
BgNVBAkTC0dyYW5nZSBNb29yMR8wHQYDVQQJExY4OSBHcmVlbmZpZWxkIENyZXNjZW50MRcw
FQYDVQQKEw5HcmlkbWVyZ2UgTHRkLjE0MDIGA1UECxMrSXNzdWVkIHRocm91Z2ggR3JpZG1l
cmdlIEx0ZC4gRS1QS0kgTWFuYWdlcjEfMB0GA1UECxMWQ29ycG9yYXRlIFNlY3VyZSBFbWFp
bDEWMBQGA1UEAxMNUm9iZXJ0IENyYWdpZTEqMCgGCSqGSIb3DQEJARYbcm9iZXJ0LmNyYWdp
ZUBncmlkbWVyZ2UuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEArcThqvLe
WU1Q1ZJmnb+2UQSwOQKWok3A1Mwk582AdvwaAQyBFliPyJ0kXJqtwNBoZvk+3WJr0QA5ZRr+
J0x3sXVpcxadojP2HNzy1gsgDtIGG8ltoU4vmX1A8BTlOIUT+Pg8p/bSruxV0vz0CR8ho2hs
R0Zi5vU+rQKNmbgufbkWhlQnMEYjknemscLQfw1YZz90ta67doNDujFy6+X6I06HpjudgMYx
8bdsNS5xVFFwuBA1eqNQra+xLzhCOeX9PPB/zK68qdNhrni3WPYG9EhSt4Dzk+xIz9hj7wrU
ZIVXDTPsY8qbUSBVpwmzI5lCHPgzurH1OK7WwgpDSsl5pwIDAQABo4IB1TCCAdEwHwYDVR0j
BBgwFoAUehNOAHRbxnhjZCfBL+KgW7x5xXswHQYDVR0OBBYEFBCOXNH+lDm8U9gy3b3bRvrx
vKgrMA4GA1UdDwEB/wQEAwIFoDAMBgNVHRMBAf8EAjAAMB0GA1UdJQQWMBQGCCsGAQUFBwME
BggrBgEFBQcDAjBGBgNVHSAEPzA9MDsGDCsGAQQBsjEBAgEDBTArMCkGCCsGAQUFBwIBFh1o
dHRwczovL3NlY3VyZS5jb21vZG8ubmV0L0NQUzBXBgNVHR8EUDBOMEygSqBIhkZodHRwOi8v
Y3JsLmNvbW9kb2NhLmNvbS9DT01PRE9DbGllbnRBdXRoZW50aWNhdGlvbmFuZFNlY3VyZUVt
YWlsQ0EuY3JsMIGIBggrBgEFBQcBAQR8MHowUgYIKwYBBQUHMAKGRmh0dHA6Ly9jcnQuY29t
b2RvY2EuY29tL0NPTU9ET0NsaWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5j
cnQwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmNvbW9kb2NhLmNvbTAmBgNVHREEHzAdgRty
b2JlcnQuY3JhZ2llQGdyaWRtZXJnZS5jb20wDQYJKoZIhvcNAQEFBQADggEBAD6b/O0LkPav
kR4Znoqxg0Ad7M3duDm4uzfrlX4ecgq56Ccdwd+3Tayz7Ewej30woVMmTKkA/NKRaCd0wVM9
8seF/oZjXKO7o1SH27igRnGSWjCoWXsdwJGfZbYnvcIIhhsxJoCPNbeSR7C0PAFDKsP3xrJy
MHMljIJsoRbZu/fnYNyFWh9OXf7fYJOGmKDKAhSabUGfhY7umvU9d/YTqo02Q6YzC7d4zPNG
1a75AuHSEchf6GdKqycG38I5y9jlDaYfXspoS3PlTNCIeZONbOSMZgftnNEVKq+SWytFqyG/
8+dwpm/a12KMex5J8iHwaUKj++2O2rAFNjDDqXpeEYoxggQZMIIEFQIBATCBqDCBkzELMAkG
A1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9y
ZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENPTU9ETyBDbGllbnQg
QXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIQXDFQ28QtqMuYch5f2nTvZjAJ
BgUrDgMCGgUAoIICRTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP
Fw0xMjExMTQxMTM5MDZaMCMGCSqGSIb3DQEJBDEWBBRjxfih6XfnB4DAf0TeawpFWfng1TBs
BgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcw
DgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEo
MIG5BgkrBgEEAYI3EAQxgaswgagwgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVy
IE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1p
dGVkMTkwNwYDVQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUg
RW1haWwgQ0ECEFwxUNvELajLmHIeX9p072YwgbsGCyqGSIb3DQEJEAILMYGroIGoMIGTMQsw
CQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxm
b3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVu
dCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhBcMVDbxC2oy5hyHl/adO9m
MA0GCSqGSIb3DQEBAQUABIIBAJNpyqBqm0ToeUWSGRaQjrue+nLwksboBmiRPfzKmzUpSNqa
WASxyEylJdL7k0d/GBdoqoinkSaKXVWwm8mu+B2m6Yc0WiQEtbQXi1oW++qRhxReqyAUN6AE
iPD3W7eqrHN5yQwd3GjqaSYNpWtIR742s0WN8ggAdHGje+DpS2okxF+Jl5Ye1tyLnRxweLqJ
7mzG73zd3M86lEu9iN1H7gGTnxZXwEq41QbiVIUHnBdQehVnPnF2btWKs5Hc6hqXpbXVDa9A
shcZ6J22grX3PG7K6FepxQSET8VNWa9juzCRw2+svdPOQMaoLVjeEQ/RaWntKcXbFbbKqnpA
OebFDXQAAAAAAAA=
--------------ms070101080703020002050400--

From trac+roll@trac.tools.ietf.org  Wed Nov 14 13:09:37 2012
Return-Path: 
X-Original-To: roll@ietfa.amsl.com
Delivered-To: roll@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A34B21F86DC for ; Wed, 14 Nov 2012 13:09:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.498
X-Spam-Level: 
X-Spam-Status: No, score=-102.498 tagged_above=-999 required=5 tests=[AWL=0.101, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c58caWn7fxVU for ; Wed, 14 Nov 2012 13:09:36 -0800 (PST)
Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [77.72.230.30]) by ietfa.amsl.com (Postfix) with ESMTP id 7600C21F846E for ; Wed, 14 Nov 2012 13:09:35 -0800 (PST)
Received: from localhost ([127.0.0.1]:52648 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1TYkCx-00017d-MB; Wed, 14 Nov 2012 22:09:25 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: "roll issue tracker" 
X-Trac-Version: 0.12.2
Precedence: bulk
Auto-Submitted: auto-generated
X-Mailer: Trac 0.12.2, by Edgewall Software
To: draft-ietf-roll-trickle-mcast@tools.ietf.org, mcr@sandelman.ca
X-Trac-Project: roll
Date: Wed, 14 Nov 2012 21:09:15 -0000
X-URL: http://tools.ietf.org/wg/roll/
X-Trac-Ticket-URL: https://svn.tools.ietf.org/wg/roll/trac/ticket/105#comment:2
Message-ID: <073.3a31432a0dac11b017222660a68d27c5@trac.tools.ietf.org>
References: <058.e817419e990e1afb26be9aa25d5cfc21@trac.tools.ietf.org>
X-Trac-Ticket-ID: 105
In-Reply-To: <058.e817419e990e1afb26be9aa25d5cfc21@trac.tools.ietf.org>
X-SA-Exim-Connect-IP: 127.0.0.1
X-SA-Exim-Rcpt-To: draft-ietf-roll-trickle-mcast@tools.ietf.org, mcr@sandelman.ca, roll@ietf.org
X-SA-Exim-Mail-From: trac+roll@trac.tools.ietf.org
X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false
Resent-To: jonhui@cisco.com, richard.kelsey@silabs.com
Resent-Message-Id: <20121114210936.7600C21F846E@ietfa.amsl.com>
Resent-Date: Wed, 14 Nov 2012 13:09:35 -0800 (PST)
Resent-From: trac+roll@trac.tools.ietf.org
Cc: roll@ietf.org
Subject: Re: [Roll] [roll] #105: trickle-mcast: how to determine scope of MPL domain
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.12
Reply-To: roll@ietf.org
List-Id: Routing Over Low power and Lossy networks 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 14 Nov 2012 21:09:37 -0000

#105: trickle-mcast: how to determine scope of MPL domain


Comment (by mcr@…):

 From: Robert Cragie 

 1. A packet with a link-local mc address doesn't need tunnelling and
    doesn't need trickle multicast as it is intended to go only one hop
    and is therefore sent using link-layer broadcast without any MPL
 option.

 2. We have generally used the term "subnet-local" in the case of where
    the MPL domain covers the multi-link subnet exactly. If the
    originator is in the MPL domain, and all the intended recipients are
    in the MPL domain, then any packet forwarded by a MPL forwarder will
 be:
     1. Unencapsulated
     2. Have subnet-local mc address (e.g. FF03-based)
     3. Have a MPL option

 3. There is the other case where if the originator is not in the MPL
    domain or at least one of the intended recipients is not in the MPL
    domain (scope rules), then any packet forwarded by a MPL forwarder
    will be:
     1. Encapsulated
     2. Outer header will have subnet-local mc address (e.g.
        FF03-based). This can be used to control propagation in
        conjunction with the MPL option.
     3. Outer header will have a MPL option
     4. Inner header will have site local mc address (e.g. FF05-based).
        This will be tunnelled to multicast exit points
     5. Inner header will not have a MPL option

 4. The alternative to (3) is to use link-local mc address in
    conjunction with a MPL option:
     1. Encapsulated
     2. Outer header will have link-local mc address (e.g. FF02-based).
        This cannot be used to control propagation as it only goes one
        hop; the MPL option is used alone
     3. Outer header will have a MPL option
     4. Inner header will have site local mc address (e.g. FF05-based).
        This will not be tunnelled as it is recapsulated every hop
     5. Inner header will not have a MPL option

-- 
----------------------------+----------------------------------------------
 Reporter:  mcr@…           |       Owner:  draft-ietf-roll-trickle-mcast@…
     Type:  defect          |      Status:  new
 Priority:  major           |   Milestone:
Component:  trickle-mcast   |     Version:
 Severity:  In WG Last      |  Resolution:
  Call                      |
 Keywords:                  |
----------------------------+----------------------------------------------

Ticket URL: 
roll 


From esko.dijk@philips.com  Thu Nov 15 01:48:01 2012
Return-Path: 
X-Original-To: roll@ietfa.amsl.com
Delivered-To: roll@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C1A321F8821 for ; Thu, 15 Nov 2012 01:48:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.099
X-Spam-Level: 
X-Spam-Status: No, score=-5.099 tagged_above=-999 required=5 tests=[AWL=1.500,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EUhd-0yWO8kn for ; Thu, 15 Nov 2012 01:47:55 -0800 (PST)
Received: from co9outboundpool.messaging.microsoft.com (co9ehsobe005.messaging.microsoft.com [207.46.163.28]) by ietfa.amsl.com (Postfix) with ESMTP id 83DCE21F867F for ; Thu, 15 Nov 2012 01:47:55 -0800 (PST)
Received: from mail112-co9-R.bigfish.com (10.236.132.250) by CO9EHSOBE016.bigfish.com (10.236.130.79) with Microsoft SMTP Server id 14.1.225.23; Thu, 15 Nov 2012 09:47:54 +0000
Received: from mail112-co9 (localhost [127.0.0.1])	by mail112-co9-R.bigfish.com (Postfix) with ESMTP id 832A9C0019B; Thu, 15 Nov 2012 09:47:54 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:157.55.7.222; KIP:(null); UIP:(null); IPV:NLI; H:mail.philips.com; RD:none; EFVD:NLI
X-SpamScore: -38
X-BigFish: VPS-38(zz217bI15d6O9251Jd6eah936eI542M1432I328cMzz1de0h1202h1d1ah1d2ahzz1033IL8275dhz2dh2a8h668h839h944hd25hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h15d0l1155h)
Received: from mail112-co9 (localhost.localdomain [127.0.0.1]) by mail112-co9 (MessageSwitch) id 135297287260862_5538; Thu, 15 Nov 2012 09:47:52 +0000 (UTC)
Received: from CO9EHSMHS031.bigfish.com (unknown [10.236.132.229])	by mail112-co9.bigfish.com (Postfix) with ESMTP id 0BE654C0019; Thu, 15 Nov 2012 09:47:52 +0000 (UTC)
Received: from mail.philips.com (157.55.7.222) by CO9EHSMHS031.bigfish.com (10.236.130.41) with Microsoft SMTP Server (TLS) id 14.1.225.23; Thu, 15 Nov 2012 09:47:51 +0000
Received: from 011-DB3MPN2-082.MGDPHG.emi.philips.com ([169.254.2.20]) by 011-DB3MMR1-001.MGDPHG.emi.philips.com ([10.128.28.51]) with mapi id 14.02.0318.003; Thu, 15 Nov 2012 09:46:51 +0000
From: "Dijk, Esko" 
To: "consultancy@vanderstok.org" , Michael Richardson 
Thread-Topic: [Roll] [roll] #105: trickle-mcast: how to determine scope of MPL domain
Thread-Index: AQHNwkOFtl9ztYUSrkiATuslfJmcUZfpG0MQ
Date: Thu, 15 Nov 2012 09:46:51 +0000
Message-ID: <031DD135F9160444ABBE3B0C36CED618B0C67D@011-DB3MPN2-082.MGDPHG.emi.philips.com>
References: <058.e817419e990e1afb26be9aa25d5cfc21@trac.tools.ietf.org>  <50932647.3050509@exegin.com>  <5094202F.4010805@exegin.com>  <509C03C2.50809@exegin.com>  <509C5F00.2050204@exegin.com>	<109e9168af966b0ee543f13886fef7ef@xs4all.nl> <8796.1352758060@sandelman.ca> <895d55da5f389dc29760cd52aaf91d61@xs4all.nl>
In-Reply-To: <895d55da5f389dc29760cd52aaf91d61@xs4all.nl>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [86.94.216.29]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: philips.com
Cc: "roll@ietf.org" 
Subject: Re: [Roll] [roll] #105: trickle-mcast: how to determine scope of MPL domain
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Routing Over Low power and Lossy networks 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 15 Nov 2012 09:48:01 -0000

Hi Peter, Michael,

a question from your last 2 emails is the following:
if multiple LoWPAN networks are assigned the same 802.15.4 channel (which i=
s likely as Peter explained), would they not be assigned a different Pan-ID=
 to logically separate them? So for the drawing that shows the 6 border rou=
ters case, there would be no mutual connectivity between dissemination regi=
ons anyway.

A related question is whether nodes from different LoWPANs are allowed, or =
not, to mutually communicate. (I could not find text on this in RFC 6282 an=
d RFC 6775 (6lowpan-nd) ).
If they are allowed that leads to some strange implications, for example a =
node in LoWPAN1 sends a link-local packet which is received by a node in Lo=
WPAN2 even though it is on a different link (and different IPv6 prefix).

I can put this question on the 6lowpan list, if needed.

regards,
Esko


-----Original Message-----
From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of pet=
er van der Stok
Sent: Wednesday 14 November 2012 9:38
To: Michael Richardson
Cc: roll@ietf.org
Subject: Re: [Roll] [roll] #105: trickle-mcast: how to determine scope of M=
PL domain

Hi Michael,

sorry to be confusing.

Again, this is not a real installation, just an example of what to
expect.
Surface area can be something like 100x30 square meters.

I show 6 border routers coinciding with 6 disseminatiuon areas due to a
remark by Dario where he asked if it is possible that multiple
disseminations areas can be present in one PAN.
The answer is yes, because giving a border router to each dissemination
area (6) is quite expensive.

Concerning the use of the same channel.
When we have one PAN, one channel is used, that is clear.
Having several PANs, it perspires that often only 2 channels of the
ones specified by 802.15.4 provide good communication ([presence of
802.11, etc.).

Several other additional organisational boundary conditions can dictate
the channel numbers.

Hope this helps,

peter


Michael Richardson schreef op 2012-11-12 23:07:
> splitting up your text to emphasize a few things:
>
>>>>>> "peter" =3D=3D peter van der Stok  writes:
>     peter> The nodes in all networks use the same communication
> channel.
>
> ...
>
>     peter> not forward the message.  In this network configuration
> the
>     peter> dissemination area is identical with a network.  From a
> cost
>     peter> perspective (less border routers) it is more realistic if
> one
>     peter> network covers the whole floor.
>
> But, in your diagram, you have 6 border routers?!?
>
> I don't understand why nodes in area1 and area2 should use the same
> communication channel.

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

________________________________
The information contained in this message may be confidential and legally p=
rotected under applicable law. The message is intended solely for the addre=
ssee(s). If you are not the intended recipient, you are hereby notified tha=
t any use, forwarding, dissemination, or reproduction of this message is st=
rictly prohibited and may be unlawful. If you are not the intended recipien=
t, please contact the sender by return e-mail and destroy all copies of the=
 original message.


From stokcons@xs4all.nl  Thu Nov 15 02:01:59 2012
Return-Path: 
X-Original-To: roll@ietfa.amsl.com
Delivered-To: roll@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A7C121F8530 for ; Thu, 15 Nov 2012 02:01:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.297
X-Spam-Level: 
X-Spam-Status: No, score=-0.297 tagged_above=-999 required=5 tests=[AWL=0.207,  BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6o6VI2rV99-h for ; Thu, 15 Nov 2012 02:01:58 -0800 (PST)
Received: from smtp-vbr11.xs4all.nl (smtp-vbr11.xs4all.nl [194.109.24.31]) by ietfa.amsl.com (Postfix) with ESMTP id 4DFB321F84DB for ; Thu, 15 Nov 2012 02:01:58 -0800 (PST)
Received: from roundcube.xs4all.nl (roundcube6.xs4all.net [194.109.20.204]) by smtp-vbr11.xs4all.nl (8.13.8/8.13.8) with ESMTP id qAFA1Qnl005331; Thu, 15 Nov 2012 11:01:26 +0100 (CET) (envelope-from stokcons@xs4all.nl)
Received: from a82-95-140-48.adsl.xs4all.nl ([82.95.140.48]) by roundcube.xs4all.nl with HTTP (HTTP/1.1 POST); Thu, 15 Nov 2012 11:01:25 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Date: Thu, 15 Nov 2012 11:01:25 +0100
From: peter van der Stok 
To: "Dijk, Esko" 
Organization: vanderstok consultancy
Mail-Reply-To: 
In-Reply-To: <031DD135F9160444ABBE3B0C36CED618B0C67D@011-DB3MPN2-082.MGDPHG.emi.philips.com>
References: <058.e817419e990e1afb26be9aa25d5cfc21@trac.tools.ietf.org>  <50932647.3050509@exegin.com>  <5094202F.4010805@exegin.com>  <509C03C2.50809@exegin.com>  "<509C5F00.2050204@exegin.com>" <109e9168af966b0ee543f13886fef7ef@xs4all.nl> <8796.1352758060@sandelman.ca> <895d55da5f389dc29760cd52aaf91d61@xs4all.nl> <031DD135F9160444ABBE3B0C36CED618B0C67D@011-DB3MPN2-082.MGDPHG.emi.philips.com>
Message-ID: <717524bfa3e3bcd7b8e99d632178d95c@xs4all.nl>
X-Sender: stokcons@xs4all.nl (wZ/eM00kM1/deZngrTA04Sj+t9zxnuby)
User-Agent: XS4ALL Webmail
X-Virus-Scanned: by XS4ALL Virus Scanner
Cc: roll@ietf.org
Subject: Re: [Roll] [roll] #105: trickle-mcast: how to determine scope of MPL domain
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: consultancy@vanderstok.org
List-Id: Routing Over Low power and Lossy networks 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 15 Nov 2012 10:01:59 -0000

HI Esko,

The few LoWPAN implementations I have experience with, ignore the 
PANid.
Actually, this is great because when the original PANid node is removed 
the network continues to exist.
Contrary to Zigbee, where this is a problem and has led to 
standardization modifications.
So please do not start this discussion again.

So your implication (strange or not) is correct, and therfore I create 
these problems with unicast prefix based MC addresses.

Greetings,

Peter

Dijk, Esko schreef op 2012-11-15 10:46:
> Hi Peter, Michael,
>
> a question from your last 2 emails is the following:
> if multiple LoWPAN networks are assigned the same 802.15.4 channel
> (which is likely as Peter explained), would they not be assigned a
> different Pan-ID to logically separate them? So for the drawing that
> shows the 6 border routers case, there would be no mutual 
> connectivity
> between dissemination regions anyway.
>
> A related question is whether nodes from different LoWPANs are
> allowed, or not, to mutually communicate. (I could not find text on
> this in RFC 6282 and RFC 6775 (6lowpan-nd) ).
> If they are allowed that leads to some strange implications, for
> example a node in LoWPAN1 sends a link-local packet which is received
> by a node in LoWPAN2 even though it is on a different link (and
> different IPv6 prefix).
>
> I can put this question on the 6lowpan list, if needed.
>
> regards,
> Esko
>
>
> -----Original Message-----
> From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf
> Of peter van der Stok
> Sent: Wednesday 14 November 2012 9:38
> To: Michael Richardson
> Cc: roll@ietf.org
> Subject: Re: [Roll] [roll] #105: trickle-mcast: how to determine
> scope of MPL domain
>
> Hi Michael,
>
> sorry to be confusing.
>
> Again, this is not a real installation, just an example of what to
> expect.
> Surface area can be something like 100x30 square meters.
>
> I show 6 border routers coinciding with 6 disseminatiuon areas due to 
> a
> remark by Dario where he asked if it is possible that multiple
> disseminations areas can be present in one PAN.
> The answer is yes, because giving a border router to each 
> dissemination
> area (6) is quite expensive.
>
> Concerning the use of the same channel.
> When we have one PAN, one channel is used, that is clear.
> Having several PANs, it perspires that often only 2 channels of the
> ones specified by 802.15.4 provide good communication ([presence of
> 802.11, etc.).
>
> Several other additional organisational boundary conditions can 
> dictate
> the channel numbers.
>
> Hope this helps,
>
> peter
>
>
> Michael Richardson schreef op 2012-11-12 23:07:
>> splitting up your text to emphasize a few things:
>>
>>>>>>> "peter" == peter van der Stok  writes:
>>     peter> The nodes in all networks use the same communication
>> channel.
>>
>> ...
>>
>>     peter> not forward the message.  In this network configuration
>> the
>>     peter> dissemination area is identical with a network.  From a
>> cost
>>     peter> perspective (less border routers) it is more realistic if
>> one
>>     peter> network covers the whole floor.
>>
>> But, in your diagram, you have 6 border routers?!?
>>
>> I don't understand why nodes in area1 and area2 should use the same
>> communication channel.
>
> _______________________________________________
> Roll mailing list
> Roll@ietf.org
> https://www.ietf.org/mailman/listinfo/roll
>
> ________________________________
> The information contained in this message may be confidential and
> legally protected under applicable law. The message is intended 
> solely
> for the addressee(s). If you are not the intended recipient, you are
> hereby notified that any use, forwarding, dissemination, or
> reproduction of this message is strictly prohibited and may be
> unlawful. If you are not the intended recipient, please contact the
> sender by return e-mail and destroy all copies of the original
> message.


From esko.dijk@philips.com  Thu Nov 15 02:31:17 2012
Return-Path: 
X-Original-To: roll@ietfa.amsl.com
Delivered-To: roll@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC10821F858E for ; Thu, 15 Nov 2012 02:31:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.849
X-Spam-Level: 
X-Spam-Status: No, score=-5.849 tagged_above=-999 required=5 tests=[AWL=0.750,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fjh1gPhZEzus for ; Thu, 15 Nov 2012 02:31:17 -0800 (PST)
Received: from co9outboundpool.messaging.microsoft.com (co9ehsobe001.messaging.microsoft.com [207.46.163.24]) by ietfa.amsl.com (Postfix) with ESMTP id D166021F88CA for ; Thu, 15 Nov 2012 02:31:16 -0800 (PST)
Received: from mail176-co9-R.bigfish.com (10.236.132.226) by CO9EHSOBE004.bigfish.com (10.236.130.67) with Microsoft SMTP Server id 14.1.225.23; Thu, 15 Nov 2012 10:31:14 +0000
Received: from mail176-co9 (localhost [127.0.0.1])	by mail176-co9-R.bigfish.com (Postfix) with ESMTP id BDA41700159; Thu, 15 Nov 2012 10:31:14 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:157.55.7.222; KIP:(null); UIP:(null); IPV:NLI; H:mail.philips.com; RD:none; EFVD:NLI
X-SpamScore: -38
X-BigFish: VPS-38(zz217bI15d6O9251Jd6eah936eI542M1432I328cMzz1de0h1202h1d1ah1d2ahzz1033IL8275dhz2dh2a8h668h839h93fhd25hf0ah1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h15d0l1155h)
Received: from mail176-co9 (localhost.localdomain [127.0.0.1]) by mail176-co9 (MessageSwitch) id 1352975472714051_3087; Thu, 15 Nov 2012 10:31:12 +0000 (UTC)
Received: from CO9EHSMHS030.bigfish.com (unknown [10.236.132.233])	by mail176-co9.bigfish.com (Postfix) with ESMTP id AC49DA80064; Thu, 15 Nov 2012 10:31:12 +0000 (UTC)
Received: from mail.philips.com (157.55.7.222) by CO9EHSMHS030.bigfish.com (10.236.130.40) with Microsoft SMTP Server (TLS) id 14.1.225.23; Thu, 15 Nov 2012 10:31:12 +0000
Received: from 011-DB3MPN2-082.MGDPHG.emi.philips.com ([169.254.2.20]) by 011-DB3MMR1-002.MGDPHG.emi.philips.com ([10.128.28.52]) with mapi id 14.02.0318.003; Thu, 15 Nov 2012 10:30:06 +0000
From: "Dijk, Esko" 
To: "consultancy@vanderstok.org" 
Thread-Topic: [Roll] [roll] #105: trickle-mcast: how to determine scope of MPL domain
Thread-Index: AQHNwkOFtl9ztYUSrkiATuslfJmcUZfpG0MQgAGQjoCAAARjkA==
Date: Thu, 15 Nov 2012 10:30:06 +0000
Message-ID: <031DD135F9160444ABBE3B0C36CED618B0C6CB@011-DB3MPN2-082.MGDPHG.emi.philips.com>
References: <058.e817419e990e1afb26be9aa25d5cfc21@trac.tools.ietf.org>  <50932647.3050509@exegin.com>  <5094202F.4010805@exegin.com>  <509C03C2.50809@exegin.com>  "<509C5F00.2050204@exegin.com>" <109e9168af966b0ee543f13886fef7ef@xs4all.nl> <8796.1352758060@sandelman.ca> <895d55da5f389dc29760cd52aaf91d61@xs4all.nl> <031DD135F9160444ABBE3B0C36CED618B0C67D@011-DB3MPN2-082.MGDPHG.emi.philips.com> <717524bfa3e3bcd7b8e99d632178d95c@xs4all.nl>
In-Reply-To: <717524bfa3e3bcd7b8e99d632178d95c@xs4all.nl>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [86.94.216.29]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: philips.com
Cc: "roll@ietf.org" 
Subject: Re: [Roll] [roll] #105: trickle-mcast: how to determine scope of MPL domain
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Routing Over Low power and Lossy networks 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 15 Nov 2012 10:31:17 -0000

SGkgUGV0ZXIsDQoNCkRpZCBub3QgbWVhbiB0byBzdGFydCBhIG5ldyBkaXNjdXNzaW9uIC0gSnVz
dCBub3RpY2VkIHRoYXQgeW91IGFzc3VtZSBkaWZmZXJlbnQgTG9XUEFOIG5vZGVzIHdpbGwgcHJv
Y2VzcyBlYWNob3RoZXIncyA2TG9XUEFOIGZyYW1lcywgd2hpbGUgTWljaGFlbCBhc3N1bWVkIHRo
YXQgd291bGQgbmV2ZXIgYmUgdGhlIGNhc2UgYmVjYXVzZSB0aGV5IGFyZSBzZXBhcmF0ZSBzdWJu
ZXRzLiBTbyB0aGUgY29uY2x1c2lvbiBpcyBpdCAqY2FuKiBiZSB0aGUgY2FzZSBldmVuIHRob3Vn
aCB0aGF0IHZpb2xhdGVzIHRoZSBJUHY2IGxpbmsvc3VibmV0IG1vZGVsLg0KDQpJbiBDb250aWtp
T1MgKHdoZXJlIEkgaGF2ZSBleHBlcmllbmNlIHdpdGgpIHRoZSBQYW4tSUQgaXMgbm90IGlnbm9y
ZWQ7IDZMb1dQQU4gZnJhbWVzIGRlc3RpbmVkIHRvIGFub3RoZXIgUEFOIHRoYW4gdGhlIG5vZGUg
aXMgY29uZmlndXJlZCB3aXRoLCBhcmUgZmlsdGVyZWQgb3V0Lg0KDQpFc2tvDQoNCi0tLS0tT3Jp
Z2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBwZXRlciB2YW4gZGVyIFN0b2sgW21haWx0bzpzdG9r
Y29uc0B4czRhbGwubmxdDQpTZW50OiBUaHVyc2RheSAxNSBOb3ZlbWJlciAyMDEyIDExOjAxDQpU
bzogRGlqaywgRXNrbw0KQ2M6IGNvbnN1bHRhbmN5QHZhbmRlcnN0b2sub3JnOyBNaWNoYWVsIFJp
Y2hhcmRzb247IHJvbGxAaWV0Zi5vcmcNClN1YmplY3Q6IFJFOiBbUm9sbF0gW3JvbGxdICMxMDU6
IHRyaWNrbGUtbWNhc3Q6IGhvdyB0byBkZXRlcm1pbmUgc2NvcGUgb2YgTVBMIGRvbWFpbg0KDQpI
SSBFc2tvLA0KDQpUaGUgZmV3IExvV1BBTiBpbXBsZW1lbnRhdGlvbnMgSSBoYXZlIGV4cGVyaWVu
Y2Ugd2l0aCwgaWdub3JlIHRoZQ0KUEFOaWQuDQpBY3R1YWxseSwgdGhpcyBpcyBncmVhdCBiZWNh
dXNlIHdoZW4gdGhlIG9yaWdpbmFsIFBBTmlkIG5vZGUgaXMgcmVtb3ZlZA0KdGhlIG5ldHdvcmsg
Y29udGludWVzIHRvIGV4aXN0Lg0KQ29udHJhcnkgdG8gWmlnYmVlLCB3aGVyZSB0aGlzIGlzIGEg
cHJvYmxlbSBhbmQgaGFzIGxlZCB0bw0Kc3RhbmRhcmRpemF0aW9uIG1vZGlmaWNhdGlvbnMuDQpT
byBwbGVhc2UgZG8gbm90IHN0YXJ0IHRoaXMgZGlzY3Vzc2lvbiBhZ2Fpbi4NCg0KU28geW91ciBp
bXBsaWNhdGlvbiAoc3RyYW5nZSBvciBub3QpIGlzIGNvcnJlY3QsIGFuZCB0aGVyZm9yZSBJIGNy
ZWF0ZQ0KdGhlc2UgcHJvYmxlbXMgd2l0aCB1bmljYXN0IHByZWZpeCBiYXNlZCBNQyBhZGRyZXNz
ZXMuDQoNCkdyZWV0aW5ncywNCg0KUGV0ZXINCg0KRGlqaywgRXNrbyBzY2hyZWVmIG9wIDIwMTIt
MTEtMTUgMTA6NDY6DQo+IEhpIFBldGVyLCBNaWNoYWVsLA0KPg0KPiBhIHF1ZXN0aW9uIGZyb20g
eW91ciBsYXN0IDIgZW1haWxzIGlzIHRoZSBmb2xsb3dpbmc6DQo+IGlmIG11bHRpcGxlIExvV1BB
TiBuZXR3b3JrcyBhcmUgYXNzaWduZWQgdGhlIHNhbWUgODAyLjE1LjQgY2hhbm5lbA0KPiAod2hp
Y2ggaXMgbGlrZWx5IGFzIFBldGVyIGV4cGxhaW5lZCksIHdvdWxkIHRoZXkgbm90IGJlIGFzc2ln
bmVkIGENCj4gZGlmZmVyZW50IFBhbi1JRCB0byBsb2dpY2FsbHkgc2VwYXJhdGUgdGhlbT8gU28g
Zm9yIHRoZSBkcmF3aW5nIHRoYXQNCj4gc2hvd3MgdGhlIDYgYm9yZGVyIHJvdXRlcnMgY2FzZSwg
dGhlcmUgd291bGQgYmUgbm8gbXV0dWFsDQo+IGNvbm5lY3Rpdml0eQ0KPiBiZXR3ZWVuIGRpc3Nl
bWluYXRpb24gcmVnaW9ucyBhbnl3YXkuDQo+DQo+IEEgcmVsYXRlZCBxdWVzdGlvbiBpcyB3aGV0
aGVyIG5vZGVzIGZyb20gZGlmZmVyZW50IExvV1BBTnMgYXJlDQo+IGFsbG93ZWQsIG9yIG5vdCwg
dG8gbXV0dWFsbHkgY29tbXVuaWNhdGUuIChJIGNvdWxkIG5vdCBmaW5kIHRleHQgb24NCj4gdGhp
cyBpbiBSRkMgNjI4MiBhbmQgUkZDIDY3NzUgKDZsb3dwYW4tbmQpICkuDQo+IElmIHRoZXkgYXJl
IGFsbG93ZWQgdGhhdCBsZWFkcyB0byBzb21lIHN0cmFuZ2UgaW1wbGljYXRpb25zLCBmb3INCj4g
ZXhhbXBsZSBhIG5vZGUgaW4gTG9XUEFOMSBzZW5kcyBhIGxpbmstbG9jYWwgcGFja2V0IHdoaWNo
IGlzIHJlY2VpdmVkDQo+IGJ5IGEgbm9kZSBpbiBMb1dQQU4yIGV2ZW4gdGhvdWdoIGl0IGlzIG9u
IGEgZGlmZmVyZW50IGxpbmsgKGFuZA0KPiBkaWZmZXJlbnQgSVB2NiBwcmVmaXgpLg0KPg0KPiBJ
IGNhbiBwdXQgdGhpcyBxdWVzdGlvbiBvbiB0aGUgNmxvd3BhbiBsaXN0LCBpZiBuZWVkZWQuDQo+
DQo+IHJlZ2FyZHMsDQo+IEVza28NCj4NCj4NCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0N
Cj4gRnJvbTogcm9sbC1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86cm9sbC1ib3VuY2VzQGlldGYu
b3JnXSBPbiBCZWhhbGYNCj4gT2YgcGV0ZXIgdmFuIGRlciBTdG9rDQo+IFNlbnQ6IFdlZG5lc2Rh
eSAxNCBOb3ZlbWJlciAyMDEyIDk6MzgNCj4gVG86IE1pY2hhZWwgUmljaGFyZHNvbg0KPiBDYzog
cm9sbEBpZXRmLm9yZw0KPiBTdWJqZWN0OiBSZTogW1JvbGxdIFtyb2xsXSAjMTA1OiB0cmlja2xl
LW1jYXN0OiBob3cgdG8gZGV0ZXJtaW5lDQo+IHNjb3BlIG9mIE1QTCBkb21haW4NCj4NCj4gSGkg
TWljaGFlbCwNCj4NCj4gc29ycnkgdG8gYmUgY29uZnVzaW5nLg0KPg0KPiBBZ2FpbiwgdGhpcyBp
cyBub3QgYSByZWFsIGluc3RhbGxhdGlvbiwganVzdCBhbiBleGFtcGxlIG9mIHdoYXQgdG8NCj4g
ZXhwZWN0Lg0KPiBTdXJmYWNlIGFyZWEgY2FuIGJlIHNvbWV0aGluZyBsaWtlIDEwMHgzMCBzcXVh
cmUgbWV0ZXJzLg0KPg0KPiBJIHNob3cgNiBib3JkZXIgcm91dGVycyBjb2luY2lkaW5nIHdpdGgg
NiBkaXNzZW1pbmF0aXVvbiBhcmVhcyBkdWUgdG8NCj4gYQ0KPiByZW1hcmsgYnkgRGFyaW8gd2hl
cmUgaGUgYXNrZWQgaWYgaXQgaXMgcG9zc2libGUgdGhhdCBtdWx0aXBsZQ0KPiBkaXNzZW1pbmF0
aW9ucyBhcmVhcyBjYW4gYmUgcHJlc2VudCBpbiBvbmUgUEFOLg0KPiBUaGUgYW5zd2VyIGlzIHll
cywgYmVjYXVzZSBnaXZpbmcgYSBib3JkZXIgcm91dGVyIHRvIGVhY2gNCj4gZGlzc2VtaW5hdGlv
bg0KPiBhcmVhICg2KSBpcyBxdWl0ZSBleHBlbnNpdmUuDQo+DQo+IENvbmNlcm5pbmcgdGhlIHVz
ZSBvZiB0aGUgc2FtZSBjaGFubmVsLg0KPiBXaGVuIHdlIGhhdmUgb25lIFBBTiwgb25lIGNoYW5u
ZWwgaXMgdXNlZCwgdGhhdCBpcyBjbGVhci4NCj4gSGF2aW5nIHNldmVyYWwgUEFOcywgaXQgcGVy
c3BpcmVzIHRoYXQgb2Z0ZW4gb25seSAyIGNoYW5uZWxzIG9mIHRoZQ0KPiBvbmVzIHNwZWNpZmll
ZCBieSA4MDIuMTUuNCBwcm92aWRlIGdvb2QgY29tbXVuaWNhdGlvbiAoW3ByZXNlbmNlIG9mDQo+
IDgwMi4xMSwgZXRjLikuDQo+DQo+IFNldmVyYWwgb3RoZXIgYWRkaXRpb25hbCBvcmdhbmlzYXRp
b25hbCBib3VuZGFyeSBjb25kaXRpb25zIGNhbg0KPiBkaWN0YXRlDQo+IHRoZSBjaGFubmVsIG51
bWJlcnMuDQo+DQo+IEhvcGUgdGhpcyBoZWxwcywNCj4NCj4gcGV0ZXINCj4NCj4NCj4gTWljaGFl
bCBSaWNoYXJkc29uIHNjaHJlZWYgb3AgMjAxMi0xMS0xMiAyMzowNzoNCj4+IHNwbGl0dGluZyB1
cCB5b3VyIHRleHQgdG8gZW1waGFzaXplIGEgZmV3IHRoaW5nczoNCj4+DQo+Pj4+Pj4+ICJwZXRl
ciIgPT0gcGV0ZXIgdmFuIGRlciBTdG9rIDxzdG9rY29uc0B4czRhbGwubmw+IHdyaXRlczoNCj4+
ICAgICBwZXRlcj4gVGhlIG5vZGVzIGluIGFsbCBuZXR3b3JrcyB1c2UgdGhlIHNhbWUgY29tbXVu
aWNhdGlvbg0KPj4gY2hhbm5lbC4NCj4+DQo+PiAuLi4NCj4+DQo+PiAgICAgcGV0ZXI+IG5vdCBm
b3J3YXJkIHRoZSBtZXNzYWdlLiAgSW4gdGhpcyBuZXR3b3JrIGNvbmZpZ3VyYXRpb24NCj4+IHRo
ZQ0KPj4gICAgIHBldGVyPiBkaXNzZW1pbmF0aW9uIGFyZWEgaXMgaWRlbnRpY2FsIHdpdGggYSBu
ZXR3b3JrLiAgRnJvbSBhDQo+PiBjb3N0DQo+PiAgICAgcGV0ZXI+IHBlcnNwZWN0aXZlIChsZXNz
IGJvcmRlciByb3V0ZXJzKSBpdCBpcyBtb3JlIHJlYWxpc3RpYyBpZg0KPj4gb25lDQo+PiAgICAg
cGV0ZXI+IG5ldHdvcmsgY292ZXJzIHRoZSB3aG9sZSBmbG9vci4NCj4+DQo+PiBCdXQsIGluIHlv
dXIgZGlhZ3JhbSwgeW91IGhhdmUgNiBib3JkZXIgcm91dGVycz8hPw0KPj4NCj4+IEkgZG9uJ3Qg
dW5kZXJzdGFuZCB3aHkgbm9kZXMgaW4gYXJlYTEgYW5kIGFyZWEyIHNob3VsZCB1c2UgdGhlIHNh
bWUNCj4+IGNvbW11bmljYXRpb24gY2hhbm5lbC4NCj4NCj4gX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gUm9sbCBtYWlsaW5nIGxpc3QNCj4gUm9sbEBp
ZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3JvbGwNCj4N
Cj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gVGhlIGluZm9ybWF0aW9uIGNv
bnRhaW5lZCBpbiB0aGlzIG1lc3NhZ2UgbWF5IGJlIGNvbmZpZGVudGlhbCBhbmQNCj4gbGVnYWxs
eSBwcm90ZWN0ZWQgdW5kZXIgYXBwbGljYWJsZSBsYXcuIFRoZSBtZXNzYWdlIGlzIGludGVuZGVk
DQo+IHNvbGVseQ0KPiBmb3IgdGhlIGFkZHJlc3NlZShzKS4gSWYgeW91IGFyZSBub3QgdGhlIGlu
dGVuZGVkIHJlY2lwaWVudCwgeW91IGFyZQ0KPiBoZXJlYnkgbm90aWZpZWQgdGhhdCBhbnkgdXNl
LCBmb3J3YXJkaW5nLCBkaXNzZW1pbmF0aW9uLCBvcg0KPiByZXByb2R1Y3Rpb24gb2YgdGhpcyBt
ZXNzYWdlIGlzIHN0cmljdGx5IHByb2hpYml0ZWQgYW5kIG1heSBiZQ0KPiB1bmxhd2Z1bC4gSWYg
eW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCwgcGxlYXNlIGNvbnRhY3QgdGhlDQo+
IHNlbmRlciBieSByZXR1cm4gZS1tYWlsIGFuZCBkZXN0cm95IGFsbCBjb3BpZXMgb2YgdGhlIG9y
aWdpbmFsDQo+IG1lc3NhZ2UuDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N
ClRoZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaW4gdGhpcyBtZXNzYWdlIG1heSBiZSBjb25maWRl
bnRpYWwgYW5kIGxlZ2FsbHkgcHJvdGVjdGVkIHVuZGVyIGFwcGxpY2FibGUgbGF3LiBUaGUgbWVz
c2FnZSBpcyBpbnRlbmRlZCBzb2xlbHkgZm9yIHRoZSBhZGRyZXNzZWUocykuIElmIHlvdSBhcmUg
bm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQsIHlvdSBhcmUgaGVyZWJ5IG5vdGlmaWVkIHRoYXQg
YW55IHVzZSwgZm9yd2FyZGluZywgZGlzc2VtaW5hdGlvbiwgb3IgcmVwcm9kdWN0aW9uIG9mIHRo
aXMgbWVzc2FnZSBpcyBzdHJpY3RseSBwcm9oaWJpdGVkIGFuZCBtYXkgYmUgdW5sYXdmdWwuIElm
IHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQsIHBsZWFzZSBjb250YWN0IHRoZSBz
ZW5kZXIgYnkgcmV0dXJuIGUtbWFpbCBhbmQgZGVzdHJveSBhbGwgY29waWVzIG9mIHRoZSBvcmln
aW5hbCBtZXNzYWdlLg0K


From d.sturek@att.net  Thu Nov 15 06:04:34 2012
Return-Path: 
X-Original-To: roll@ietfa.amsl.com
Delivered-To: roll@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D90EC21F8500 for ; Thu, 15 Nov 2012 06:04:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.625
X-Spam-Level: 
X-Spam-Status: No, score=-1.625 tagged_above=-999 required=5 tests=[AWL=0.974,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pqAIRhFdkhom for ; Thu, 15 Nov 2012 06:04:34 -0800 (PST)
Received: from nm19-vm0.access.bullet.mail.mud.yahoo.com (nm19-vm0.access.bullet.mail.mud.yahoo.com [66.94.236.25]) by ietfa.amsl.com (Postfix) with ESMTP id ED4D321F84E6 for ; Thu, 15 Nov 2012 06:04:33 -0800 (PST)
Received: from [66.94.237.194] by nm19.access.bullet.mail.mud.yahoo.com with NNFMP; 15 Nov 2012 14:04:33 -0000
Received: from [68.142.198.105] by tm5.access.bullet.mail.mud.yahoo.com with NNFMP; 15 Nov 2012 14:04:33 -0000
Received: from [127.0.0.1] by smtp107.sbc.mail.mud.yahoo.com with NNFMP; 15 Nov 2012 14:04:33 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=att.net; s=s1024; t=1352988273; bh=xTsHJ4j3C+vU2eBXEZAjIJpbPiQh7+oDvajcixzGYvo=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:Received:User-Agent:Date:Subject:From:To:CC:Message-ID:Thread-Topic:In-Reply-To:Mime-version:Content-type:Content-transfer-encoding; b=jdEMMcFcOrQcjIeB72LQYYogAnkHgLQK2DJjYClF4Ul4avIeO09WwDsOPFR/PfzL05r7vnJxTRJ17QHAf8dCr7kxDSWF73I7HAsmAMcxFlyf2U/48uL4C+WFxFik8xlBJ8B5Oi1qCYaf65XoD5X/dfhFZynRMsHtFNE6tNNvUJg=
X-Yahoo-Newman-Id: 213692.40407.bm@smtp107.sbc.mail.mud.yahoo.com
X-Yahoo-Newman-Property: ymail-3
X-YMail-OSG: Ia8ZOUkVM1lpakieFIR82qB8NKEMa43VszNkeDxlP1BXLY5 UWIdvb.2UaN3X.vvp5pYbyI6WLQoULHIlap2Ue.tysur7wNvctq.tyuHeGp3 TRkgd4nWchA1s8wYQWkfWCXbN8PhZ.4Ec0kg5k3jhCm5q0qD9mpqTdhKYuiC QRHlsRTRdHSyjhRabK5GvsxJknVDqSwrlueOmLUFN9Jy8KU6kv9PisRq22eK EkwbRAKUmtwMEx.SqLSsQySHR7xwLtaaXdbLGhUs6g.qKOljOJHTdDuf7iIs 0xcqeLa_nnmVOE.d7vYrw00M2.3_xo00p6rYTh6CdqeJqushyutmUHsLI.KQ 90WBE2e0iBQEUHYTrpfBdviradvx6JkwQnPYgsZ_ZiN.nkdx1ibMW0.arXpY _CMSXNrnn3g3BlNHJpwqUBU8oH0uWKGTIAFB809iBzQVqdBom2QCxXCG4uRR X3H4lD_DIaOVrauOMWC0-
X-Yahoo-SMTP: fvjol_aswBAraSJvMLe2r1XTzhBhbFxY8q8c3jo-
Received: from [192.168.0.198] (d.sturek@67.124.200.173 with login) by smtp107.sbc.mail.mud.yahoo.com with SMTP; 15 Nov 2012 06:04:33 -0800 PST
User-Agent: Microsoft-MacOutlook/14.2.4.120824
Date: Thu, 15 Nov 2012 06:03:17 -0800
From: Don Sturek 
To: "Dijk, Esko" , "consultancy@vanderstok.org" 
Message-ID: 
Thread-Topic: [Roll] [roll] #105: trickle-mcast: how to determine scope of MPL domain
In-Reply-To: <031DD135F9160444ABBE3B0C36CED618B0C6CB@011-DB3MPN2-082.MGDPHG.emi.philips.com>
Mime-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
Cc: "roll@ietf.org" 
Subject: Re: [Roll] [roll] #105: trickle-mcast: how to determine scope of MPL domain
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Routing Over Low power and Lossy networks 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 15 Nov 2012 14:04:35 -0000

Hi Esko,

I actually don't know of an IEEE 802.15.4 radio implementation that would
not filter on PAN ID.  You should only see (at the next higher layer)
frames with the PAN ID you are a member of or the broadcast PAN ID (but
never multiple different PAN ID's)

Don



On 11/15/12 2:30 AM, "Dijk, Esko"  wrote:

>Hi Peter,
>
>Did not mean to start a new discussion - Just noticed that you assume
>different LoWPAN nodes will process eachother's 6LoWPAN frames, while
>Michael assumed that would never be the case because they are separate
>subnets. So the conclusion is it *can* be the case even though that
>violates the IPv6 link/subnet model.
>
>In ContikiOS (where I have experience with) the Pan-ID is not ignored;
>6LoWPAN frames destined to another PAN than the node is configured with,
>are filtered out.
>
>Esko
>
>-----Original Message-----
>From: peter van der Stok [mailto:stokcons@xs4all.nl]
>Sent: Thursday 15 November 2012 11:01
>To: Dijk, Esko
>Cc: consultancy@vanderstok.org; Michael Richardson; roll@ietf.org
>Subject: RE: [Roll] [roll] #105: trickle-mcast: how to determine scope of
>MPL domain
>
>HI Esko,
>
>The few LoWPAN implementations I have experience with, ignore the
>PANid.
>Actually, this is great because when the original PANid node is removed
>the network continues to exist.
>Contrary to Zigbee, where this is a problem and has led to
>standardization modifications.
>So please do not start this discussion again.
>
>So your implication (strange or not) is correct, and therfore I create
>these problems with unicast prefix based MC addresses.
>
>Greetings,
>
>Peter
>
>Dijk, Esko schreef op 2012-11-15 10:46:
>> Hi Peter, Michael,
>>
>> a question from your last 2 emails is the following:
>> if multiple LoWPAN networks are assigned the same 802.15.4 channel
>> (which is likely as Peter explained), would they not be assigned a
>> different Pan-ID to logically separate them? So for the drawing that
>> shows the 6 border routers case, there would be no mutual
>> connectivity
>> between dissemination regions anyway.
>>
>> A related question is whether nodes from different LoWPANs are
>> allowed, or not, to mutually communicate. (I could not find text on
>> this in RFC 6282 and RFC 6775 (6lowpan-nd) ).
>> If they are allowed that leads to some strange implications, for
>> example a node in LoWPAN1 sends a link-local packet which is received
>> by a node in LoWPAN2 even though it is on a different link (and
>> different IPv6 prefix).
>>
>> I can put this question on the 6lowpan list, if needed.
>>
>> regards,
>> Esko
>>
>>
>> -----Original Message-----
>> From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf
>> Of peter van der Stok
>> Sent: Wednesday 14 November 2012 9:38
>> To: Michael Richardson
>> Cc: roll@ietf.org
>> Subject: Re: [Roll] [roll] #105: trickle-mcast: how to determine
>> scope of MPL domain
>>
>> Hi Michael,
>>
>> sorry to be confusing.
>>
>> Again, this is not a real installation, just an example of what to
>> expect.
>> Surface area can be something like 100x30 square meters.
>>
>> I show 6 border routers coinciding with 6 disseminatiuon areas due to
>> a
>> remark by Dario where he asked if it is possible that multiple
>> disseminations areas can be present in one PAN.
>> The answer is yes, because giving a border router to each
>> dissemination
>> area (6) is quite expensive.
>>
>> Concerning the use of the same channel.
>> When we have one PAN, one channel is used, that is clear.
>> Having several PANs, it perspires that often only 2 channels of the
>> ones specified by 802.15.4 provide good communication ([presence of
>> 802.11, etc.).
>>
>> Several other additional organisational boundary conditions can
>> dictate
>> the channel numbers.
>>
>> Hope this helps,
>>
>> peter
>>
>>
>> Michael Richardson schreef op 2012-11-12 23:07:
>>> splitting up your text to emphasize a few things:
>>>
>>>>>>>> "peter" == peter van der Stok  writes:
>>>     peter> The nodes in all networks use the same communication
>>> channel.
>>>
>>> ...
>>>
>>>     peter> not forward the message.  In this network configuration
>>> the
>>>     peter> dissemination area is identical with a network.  From a
>>> cost
>>>     peter> perspective (less border routers) it is more realistic if
>>> one
>>>     peter> network covers the whole floor.
>>>
>>> But, in your diagram, you have 6 border routers?!?
>>>
>>> I don't understand why nodes in area1 and area2 should use the same
>>> communication channel.
>>
>> _______________________________________________
>> Roll mailing list
>> Roll@ietf.org
>> https://www.ietf.org/mailman/listinfo/roll
>>
>> ________________________________
>> The information contained in this message may be confidential and
>> legally protected under applicable law. The message is intended
>> solely
>> for the addressee(s). If you are not the intended recipient, you are
>> hereby notified that any use, forwarding, dissemination, or
>> reproduction of this message is strictly prohibited and may be
>> unlawful. If you are not the intended recipient, please contact the
>> sender by return e-mail and destroy all copies of the original
>> message.
>
>
>________________________________
>The information contained in this message may be confidential and legally
>protected under applicable law. The message is intended solely for the
>addressee(s). If you are not the intended recipient, you are hereby
>notified that any use, forwarding, dissemination, or reproduction of this
>message is strictly prohibited and may be unlawful. If you are not the
>intended recipient, please contact the sender by return e-mail and
>destroy all copies of the original message.
>_______________________________________________
>Roll mailing list
>Roll@ietf.org
>https://www.ietf.org/mailman/listinfo/roll



From d.sturek@att.net  Thu Nov 15 06:09:27 2012
Return-Path: 
X-Original-To: roll@ietfa.amsl.com
Delivered-To: roll@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B538721F84E0 for ; Thu, 15 Nov 2012 06:09:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.764
X-Spam-Level: 
X-Spam-Status: No, score=-1.764 tagged_above=-999 required=5 tests=[AWL=0.835,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g7cQy4RXheUO for ; Thu, 15 Nov 2012 06:09:23 -0800 (PST)
Received: from nm11-vm1.access.bullet.mail.mud.yahoo.com (nm11-vm1.access.bullet.mail.mud.yahoo.com [66.94.237.184]) by ietfa.amsl.com (Postfix) with ESMTP id 991DC21F84DB for ; Thu, 15 Nov 2012 06:09:23 -0800 (PST)
Received: from [66.94.237.127] by nm11.access.bullet.mail.mud.yahoo.com with NNFMP; 15 Nov 2012 14:09:22 -0000
Received: from [68.142.198.106] by tm2.access.bullet.mail.mud.yahoo.com with NNFMP; 15 Nov 2012 14:09:22 -0000
Received: from [127.0.0.1] by smtp108.sbc.mail.mud.yahoo.com with NNFMP; 15 Nov 2012 14:09:22 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=att.net; s=s1024; t=1352988562; bh=7/iOd+KBVTUfm0wY6t/Il86GedKy3uYlG82Gd4gJZHQ=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:Received:User-Agent:Date:Subject:From:To:CC:Message-ID:Thread-Topic:In-Reply-To:Mime-version:Content-type:Content-transfer-encoding; b=X0jwA10JsazGev7jpW9rjD2WEaAMr0cnN2G4nUzLVw8lnvT9Xt6uqs4tjkS17xI5zcWvMTl4Gq1CXFNy6JhDpyTy2Yw2YMghPWD2hhpWuNIGTaRoqUQTw+vB3UkWbCaJEhADsIgHJE3piK62dOhZDImtONBwJKyYYkCFp0n4+SI=
X-Yahoo-Newman-Id: 171260.79918.bm@smtp108.sbc.mail.mud.yahoo.com
X-Yahoo-Newman-Property: ymail-3
X-YMail-OSG: S1hkvJYVM1ldkYUYJDSrcEhnwSVL3XU.hWJF8uN5qnQ4Pux 7LXaR95wHBlc9qyG2WUUm5CehCcV11PS8FeWReq1VUuQDLnHrh7GTjGEsiPs fq.nYNgMYlIF_IeJDvfOhe7cjSL3QTq9GZJ1gGGX7AAJX4Bgiz9apPL993lk hn4mSToAxdBKNC9AaeYefvhUFeT402Q8KdoUupAOHqA7jK0H1f4ogIC69mfE NylhD6KnLvDk0rDRz1kqmTgEyK.RsrjS5avz7W1jJ7bKAf2rXX7MsrP50zGT RXmdhs.5MbOMkJonPLdzT3UX4RwePtBAmgFbvO_BmSm_WvKAgGdEywP4_THD UfwOSnHsxDUtxoYNiJTnxZ4MMmc.FlAi9Ss.QgLyI6KQCN6RAe3U8xiurh2a PZXrD4B._oRPJB4WiOoY1B1k6HWVa.40P371yk.GFOn1mVPYyP_GoL1A8dMF CrwaSqBmAPszpEfQaeL0-
X-Yahoo-SMTP: fvjol_aswBAraSJvMLe2r1XTzhBhbFxY8q8c3jo-
Received: from [192.168.0.198] (d.sturek@67.124.200.173 with login) by smtp108.sbc.mail.mud.yahoo.com with SMTP; 15 Nov 2012 06:09:21 -0800 PST
User-Agent: Microsoft-MacOutlook/14.2.4.120824
Date: Thu, 15 Nov 2012 06:08:05 -0800
From: Don Sturek 
To: "Dijk, Esko" , "consultancy@vanderstok.org" , Michael Richardson 
Message-ID: 
Thread-Topic: [Roll] [roll] #105: trickle-mcast: how to determine scope of MPL domain
In-Reply-To: <031DD135F9160444ABBE3B0C36CED618B0C67D@011-DB3MPN2-082.MGDPHG.emi.philips.com>
Mime-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
Cc: "roll@ietf.org" 
Subject: Re: [Roll] [roll] #105: trickle-mcast: how to determine scope of MPL domain
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Routing Over Low power and Lossy networks 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 15 Nov 2012 14:09:27 -0000

Hi Esko,

The topic discussed below is really an IEEE 802.15.4 topic.   That
specification has a management information block (MIB) that holds the PAN
ID the device is a member of as well as the short ID of the device within
that PAN.

While it is possible to implement devices which are simultaneously members
of multiple PAN ID's, each with different short ID's, in practice, most
silicon implementations use the MIB values as described in the
specification to perform filtering on incoming packets.   To that end, you
should only see packets with the PAN ID/short or long ID of your device
(or the broadcast PAN ID) but never packets with multiple different PAN
ID's/short ID's (at least from all of the implementations I know
about......)

Don



On 11/15/12 1:46 AM, "Dijk, Esko"  wrote:

>Hi Peter, Michael,
>
>a question from your last 2 emails is the following:
>if multiple LoWPAN networks are assigned the same 802.15.4 channel (which
>is likely as Peter explained), would they not be assigned a different
>Pan-ID to logically separate them? So for the drawing that shows the 6
>border routers case, there would be no mutual connectivity between
>dissemination regions anyway.
>
>A related question is whether nodes from different LoWPANs are allowed,
>or not, to mutually communicate. (I could not find text on this in RFC
>6282 and RFC 6775 (6lowpan-nd) ).
>If they are allowed that leads to some strange implications, for example
>a node in LoWPAN1 sends a link-local packet which is received by a node
>in LoWPAN2 even though it is on a different link (and different IPv6
>prefix).
>
>I can put this question on the 6lowpan list, if needed.
>
>regards,
>Esko
>
>
>-----Original Message-----
>From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of
>peter van der Stok
>Sent: Wednesday 14 November 2012 9:38
>To: Michael Richardson
>Cc: roll@ietf.org
>Subject: Re: [Roll] [roll] #105: trickle-mcast: how to determine scope of
>MPL domain
>
>Hi Michael,
>
>sorry to be confusing.
>
>Again, this is not a real installation, just an example of what to
>expect.
>Surface area can be something like 100x30 square meters.
>
>I show 6 border routers coinciding with 6 disseminatiuon areas due to a
>remark by Dario where he asked if it is possible that multiple
>disseminations areas can be present in one PAN.
>The answer is yes, because giving a border router to each dissemination
>area (6) is quite expensive.
>
>Concerning the use of the same channel.
>When we have one PAN, one channel is used, that is clear.
>Having several PANs, it perspires that often only 2 channels of the
>ones specified by 802.15.4 provide good communication ([presence of
>802.11, etc.).
>
>Several other additional organisational boundary conditions can dictate
>the channel numbers.
>
>Hope this helps,
>
>peter
>
>
>Michael Richardson schreef op 2012-11-12 23:07:
>> splitting up your text to emphasize a few things:
>>
>>>>>>> "peter" == peter van der Stok  writes:
>>     peter> The nodes in all networks use the same communication
>> channel.
>>
>> ...
>>
>>     peter> not forward the message.  In this network configuration
>> the
>>     peter> dissemination area is identical with a network.  From a
>> cost
>>     peter> perspective (less border routers) it is more realistic if
>> one
>>     peter> network covers the whole floor.
>>
>> But, in your diagram, you have 6 border routers?!?
>>
>> I don't understand why nodes in area1 and area2 should use the same
>> communication channel.
>
>_______________________________________________
>Roll mailing list
>Roll@ietf.org
>https://www.ietf.org/mailman/listinfo/roll
>
>________________________________
>The information contained in this message may be confidential and legally
>protected under applicable law. The message is intended solely for the
>addressee(s). If you are not the intended recipient, you are hereby
>notified that any use, forwarding, dissemination, or reproduction of this
>message is strictly prohibited and may be unlawful. If you are not the
>intended recipient, please contact the sender by return e-mail and
>destroy all copies of the original message.
>
>_______________________________________________
>Roll mailing list
>Roll@ietf.org
>https://www.ietf.org/mailman/listinfo/roll



From robert.cragie@gridmerge.com  Thu Nov 15 07:08:06 2012
Return-Path: 
X-Original-To: roll@ietfa.amsl.com
Delivered-To: roll@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C38A621F88D4 for ; Thu, 15 Nov 2012 07:08:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level: 
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WCI89t80MLxJ for ; Thu, 15 Nov 2012 07:08:06 -0800 (PST)
Received: from mail41.extendcp.co.uk (mail41.extendcp.co.uk [79.170.44.41]) by ietfa.amsl.com (Postfix) with ESMTP id 714C021F88E0 for ; Thu, 15 Nov 2012 07:08:05 -0800 (PST)
Received: from client-86-9-227-213.oxfd-bam-1.adsl.virginmedia.com ([86.9.227.213] helo=[192.168.0.2]) by mail41.extendcp.com with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.77) id 1TZ12v-0000H6-SQ; Thu, 15 Nov 2012 15:08:02 +0000
Message-ID: <50A505AC.2000200@gridmerge.com>
Date: Thu, 15 Nov 2012 15:09:32 +0000
From: Robert Cragie 
Organization: Gridmerge Ltd.
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121026 Thunderbird/16.0.2
MIME-Version: 1.0
To: Michael Richardson 
References: <058.e817419e990e1afb26be9aa25d5cfc21@trac.tools.ietf.org>  <50932647.3050509@exegin.com>  <5094202F.4010805@exegin.com>  <509C03C2.50809@exegin.com>  <509C5F00.2050204@exegin.com> <509D5AF5.4040304@exegin.com> <509DAFEF.5020504@exegin.com> <9143.1352758442@sandelman.ca> <50A382DA.9030706@gridmerge.com> <2150.1352927633@obiwan.sandelman.ca>
In-Reply-To: <2150.1352927633@obiwan.sandelman.ca>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms030004090400050807090403"
X-Authenticated-As: robert.cragie@gridmerge.com
Cc: roll@ietf.org
Subject: Re: [Roll] [roll] #105: trickle-mcast: how to determine scope of MPL domain
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: robert.cragie@gridmerge.com
List-Id: Routing Over Low power and Lossy networks 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 15 Nov 2012 15:08:06 -0000

This is a cryptographically signed message in MIME format.

--------------ms030004090400050807090403
Content-Type: multipart/mixed;
 boundary="------------020405050606000107050304"

This is a multi-part message in MIME format.
--------------020405050606000107050304
Content-Type: multipart/alternative;
 boundary="------------000302070703000102010602"


--------------000302070703000102010602
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable


On 14/11/2012 9:13 PM, Michael Richardson wrote:
> Robert, has written 3 rules about when to encapsulate, and how to
> recognize the MPL domain.  With two options #3 and #4.
>
> the difference is  (#3):
>
>>     2. Outer header will have subnet-local mc address (e.g.
>>        FF03-based). This can be used to control propagation in
>>        conjunction with the MPL option.
> vs (#4)
>
> <    2. Outer header will have link-local mc address (e.g. FF02-based).=

> <       This cannot be used to control propagation as it only goes one
> <       hop; the MPL option is used alone
>
> and as far as I can understand in both cases MPL forwarders will
> decapsulate and re-encapsulate, thus decrementing the inner TTL each
> time.   Or did I misunderstand here?

Almost there. In the case of forwarding using MPL domain (subnet-local)=20
mc address, the inner packet is strictly tunnelled, i.e. there will be=20
no hop count decrementing per hop. I discussed this offline with=20
Jonathan Hui and he thought that was acceptable. In the case of=20
link-local mc address, the inner packet would have its hop count=20
decremented.

Why the difference? Consider the two cases more closely:

  * In the MPL domain multicast case, the encapsulated packet traverses
    throughout the scope dictated by the MPL domain multicast address.
    On receipt, the inner packet is decapsulated for processing. Once it
    has been processed it is effectively discarded. The outer packet,
    complete with MPL option is then passed to the MPL forwarder, which,
    if it decides to forward, manipulates the MPL option only and sends
    the outer packet as it came in
  * In the link-local case, the encapsulated packet only goes one hop.
    On receipt, the inner packer is decapsulated for processing. The
    outer header is discarded and the MPL option retained. As the inner
    packet is no longer encapsulated, it can be manipulated. The MPL
    forwarder is then passed the MPL option and the inner packet, which,
    if it decides to forward, manipulates the MPL option and
    recapsulates the inner packet

See attached diagrams for pictorial explanation.

>
> I think that we are very closing to closing issue #105, and I think tha=
t
> issue #106 would be resolved as "no" by this choice.
>


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


  
    
  
  
    

    
On 14/11/2012 9:13 PM, Michael
      Richardson wrote:

    

    

      
Robert, has written 3 rules about when to encapsulate, and how to
recognize the MPL domain.  With two options #3 and #4.

the difference is  (#3):



      

        
   2. Outer header will have subnet-local mc addre=
ss (e.g.
      FF03-based). This can be used to control propagation in
      conjunction with the MPL option.


      

      
vs (#4)

<    2. Outer header will have link-local mc address (e.g. FF02-based)=
=2E
<       This cannot be used to control propagation as it only goes one=

<       hop; the MPL option is used alone

and as far as I can understand in both cases MPL forwarders will
decapsulate and re-encapsulate, thus decrementing the inner TTL each
time.   Or did I misunderstand here?

    

    <RCC>

    Almost there. In the case of forwarding using MPL domain
    (subnet-local) mc address, the inner packet is strictly tunnelled,
    i.e. there will be no hop count decrementing per hop. I discussed
    this offline with Jonathan Hui and he thought that was acceptable.
    In the case of link-local mc address, the inner packet would have
    its hop count decremented.

    

    Why the difference? Consider the two cases more closely:

    

    
    
      
  • In the MPL domain multicast case, the encapsulated packet
        traverses throughout the scope dictated by the MPL domain
        multicast address. On receipt, the inner packet is decapsulated
        for processing. Once it has been processed it is effectively
        discarded. The outer packet, complete with MPL option is then
        passed to the MPL forwarder, which, if it decides to forward,
        manipulates the MPL option only and sends the outer packet as it
        came in
    • 
      
  • In the link-local case, the encapsulated packet only goes one
        hop. On receipt, the inner packer is decapsulated for
        processing. The outer header is discarded and the MPL option
        retained. As the inner packet is no longer encapsulated, it can
        be manipulated. The MPL forwarder is then passed the MPL option
        and the inner packet, which, if it decides to forward,
        manipulates the MPL option and recapsulates the inner packet
    
      
    • 
    

    See attached diagrams for pictorial explanation.

    </RCC>

    

      

I think that we are very closing to closing issue #105, and I think that
issue #106 would be resolved as "no" by this choice.



    

    

  


--------------000302070703000102010602--

--------------020405050606000107050304
Content-Type: application/pdf;
 name="McAddressProc.pdf"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
 filename="McAddressProc.pdf"

JVBERi0xLjQKJcOkw7zDtsOfCjIgMCBvYmoKPDwvTGVuZ3RoIDMgMCBSL0ZpbHRlci9GbGF0
ZURlY29kZT4+CnN0cmVhbQp4nM1bSW8dxxG+v18xZwN66X0BiAeIihzAN0cEcjByiu0Ehhgg
vvjvp7bu6WWG5DwNg0CQOM2vl6+rqmvpGamrXv64/GdRi4Inn/3VLMnpa1p+/+Xyt++Wf1/0
gn9+/+dFAWCW50vpZJavMgCHfpUp8Cdj/7r8+h2MVlcHfw3OkPwSfcQpwjXSI8xAj8lfLTS0
ttB7aFE3Gfr1QrOqq1c6h2X8+de/0Fb+gL8/AOnfTlrxy+VHFhH8gW08Pl2ivgIc/PL08/Kn
70FAaXn69acHpW8f/IMyt78//XD5/ATD1DVpHZFhVj4l/BlUTDiNjl44PV+0i3VheRZKRjmQ
6tDifnX8Uamcu/IsHR0CGNAongdlQTJPv70qGGONUHq+tMsOhILCRfoW96vjjwrm3JVnwRgd
cZ7ZbpzyNx0fVGgsh8YBRVkATE4DLWvK89fly6VObh2esbUTKRLU5KCbtEApGVtNTzmkL+jC
hnQtZ0hG0k7lWWRgM849tLhfHX9UF+euPOvC+rx9hu2BM+yMF2JAsl28o+W8xaX6FvVbxx8V
z7krz+JxKm+c4WKqettUtVX1/MizNrBkZ6oCKAWcsJu7BuhG7tcEPB783PTaiSVOo5sR384N
8e7OebJu9udDSzrWCe6IKSeuvBNbnHGgxm+OLoUoe/ZCQFpCjp3b0BJ+7SzVWRyKMmcz2Is2
s8D6eNMZDxtXpdZpZ9BcR7TbRDfLYeG8C4MN4WgPYtkSTgRzenMwLkQ73Yx6ozg1tIRoO8tR
Ub0Pg73gvHnwXg/PzpbgjE8bobl0IPVZ9L0lMDuDjqMENh7+trBcZCIjZW/SEilwPBhaIpN2
lqNaeR8Ge2F6UyvHA3Wl25IYCHKQHFpCt53lqMDeh8Fe4N434xdDd3VI1LLRUPSdgrcNivJM
Dt7YLdfwXVtNz50AbhxavoRRbkgYNbENnENLOtYJSgAvW5EZNKzzvMD6vk7wRbCAJx0wZD9h
lrHU0CiYz4DA/tKMoLgBQz1OGDqI5yXpCeH9004qQu6kIvnajgq4SsGyhQ02WGqxCIpbsWgr
opVuJAoQimIFfQcmlOEK5k6UlFRWUBTlyC4BzBugEjCvaqxgYKUCGK9+Ag0oCkFkH0bUJ0kx
kX6cUEdFEKK5kWxBlaBH0r8T7XYn/UPW6VvSPw53hSiHyUJAWrENk0NL+LWz3Be2z2awF7Y3
BbYRtjfSwEKx19KgQUq7hpZQbGcpQqpeVWZhXwTK6o5ssW72Rtro7tAW1AraH81iv5mw/mSu
lk+otZ2bWy0/ERo7R9dKAVCnB7Q7nRCiWleIO2hRllk9u7CDMKKhnl3YQ5zQenZhD2lClUQn
3EMeUTiPhlFnJsxUbGLkUrlbOZbLn21Ge7n8bOlDLt9HdGt1E9FNitsRnTmViI7dUo3otdX0
nAy9lwG34N+wuZhO8G9dzPJVlCxWWk3P7cVcxMSoLOb8zs44jyqLYbc1V6mtpudbk+8iWE52
uVVS35L1cF43tLhnN8u4QZkFTNiCYVq35lFfKmbIpVgy1wml3z5Lrxl1hOHsE2YzOQ1Lh2tG
PTkNSwdzRrWgtLMGdS1KDqFFE65UUbSgBvVmNeLFJjWgYdUEoHgyGjSg/a1oanSBqGvR3O2W
sr8VI735TLYCKGWAI+olubFx1fKKasluLGSBAwZeIAiG9jeitqJ5Rm0W92kpGxxRfzS5eR/T
3qvqkP4UtI9XdZVuS2IgyFXU0BK67Sz3VXVnM9ir6jYFtlXVvXYvWB11G4KG8DQkaW0C180y
eWeZRXIeP2Q1Ersl5/F+E5WcB6zEzSjnPMH2OY9gkvOE2Oc8gkrOE4esppHCs7zdalDfZTUx
9zmP77KaZLsCEHfQot1I2EGT8WTTlXq4gybjyaHPHGEHa8ZjlBrQ0GCsxVKY6aSagq+gqqJu
RmtpBvyberCgNb/Lpqn5BF1rM9iBm9CS3+EO/IQers3ex7j3rpy3MrHdK2eo+nxCfyBlIzek
bAyaLwQ5W+xbpWOd4I73FSeuvFOw+nzK+4pClJVVCHCrkGNl9a3Cr53lvvcVZzPYM55ZYK++
r6jUOu0MmuuIdpvoZtkuVIPGy6FSqJZZSlEIqqJ8lAvVGbXs8KlQHVGfs5SxGPhn1NdCdcZ0
LVMnjCUiZWqLYpm6opibNSiVqSvKEjPFyVGZOqAqVTSvRlJRV1wglakjqooLpDK1Rz25xVKm
jli5fsUydcDIFd9Rpp5tRHtl6pZ9H3rlVIh2x2s8enRX1LcK0XaW++6uzmawd3e16Tvfdncl
r9qbz5aGD5q6L3q6b33q+MNfD5268p79zF8PvXDJkbRt7h0iXSFvfXNAbOo3Bzk19w611fTc
vneoJ4hbUYlrGBbzlPqUxXzU1/UTh9pqespiQ53k0BFHhzlWkYYRA7l9SA8q3eCffPug1YP6
qB7h4UF9gj9/vkHk/cy///4WHrS6Ge6I/T5qzRAN/7Sa2Obq4PLMuDpXaZ9pPlmGF8cZYTFA
tcFfaMtrakcd1IP2wIR7gHEjRlw/QRfumuTXPF94mZxT+H3J/0I01QrkhRy9z3WUV+MzPhm6
3HCLo5wYry788o/WMqTqc54MyAW6gfF8jekCXnxZ/jin6bdpFxhKIIza1nHI5iPyJgnocLO5
KCOSwPO6N51ADpsib1SYSZJZNMHK+mBoNu1EcyJZUen28jyFWISn39DY3BgQ9NxRteyWwvaw
23WCB/0RqbHbFPp2RZn+Kgykz4MTSAJagyh2DwWTMeCz4/+/6F/eQ0IvtCXQVxT1uJ5gOiWP
csiQvOUuRphp0YyvCB7/MuITnb1JTYrP5EE1jeVWoBpZih5ulI9/5asyiVhdq3SsE9xRbp24
8k65FZL69mKr0JR0T5aXUC3U5MvXrlXYtbPcV2ydzWCv2BrFdfBT5EKzW3wkxl/pdq1Cs53l
vlT0bAZ7qeiGXb0tEa2a7Ex5MPNOr53Ou1nu+5bubAZ7ielsSy8kppUUt+h7r41ckeuHkisG
s757k+em12Y+gPepSM1P+YD+JI5V0ivyzGrDNRd3/zi54TWPK04egkyUnk06J04/1VzrsQnO
4+RljG/Sg914JduLG7neXTEXx4Q+a92LlN5JJpbetjL74RpAjYTtLlHppNUE0LdKzJSdceoa
lXs14PM2rJkC/luC7CSjDQdQ3zPTgSuvMqQlLz34wA0teQXSznKfAzibwZ4DmF/C7LiA9m0Q
uG6NLzrSWJkatb4fwU6O3j046mY03agnIx/NtG9StooC+h8e3uKmBifOJuJ8LbxA31D5ZNgz
l0MaJAsuoqTNAbsE/JHECgMVT9DNgFlkKqiC1FNgrwFLqT3bi/gOREN9HQZamlbg8ehTkB45
JFxAW/ZNkg0jOWAbmBr4GEj9kICMIlb4i4+I1CpvnxWXj1a3wjqztv324110Jcf7Jf8om1Hj
Vu463D8u/wU7KlseCmVuZHN0cmVhbQplbmRvYmoKCjMgMCBvYmoKMjU4NwplbmRvYmoKCjUg
MCBvYmoKPDwvTGVuZ3RoIDYgMCBSL0ZpbHRlci9GbGF0ZURlY29kZS9MZW5ndGgxIDI1NzQ0
Pj4Kc3RyZWFtCnic7Xx7YFTF1fjM3Ofefd19ZN/J3mSTTcgGAkkgBCK5QAJo5P0wQSIJJEB4
5QmCooT6ANEqta1V2wpaq6htWULAgLbwqfVrVQpfq/arrUpbrGiLUj9KFUz2d2bu3RBa7e/1
3+/37d2ZOfO48zhz5sw5Z2a3u3NDC7KhHsQhffm6pvb1HauXIYReQwi7l2/s1mx/yDoFMDhx
wYr2letsyzbNQ0gug/j6lWs3r0jOnrkLIcfjCI1/aVVLU/OZHROdCE1fBXWMWwUJawe/IkF8
D8RzV63r3rTElr8e4i9BvHtt2/Km8C9jP0FoxniIV65r2tQ+wlbOQ7wb4tr6pnUtWb/8zVcg
/g2E1HB7W1f3A6gwhVBdkua3d7a037T4nVqIn0TICvUgDA/92AAUaZxwvCBKskWx2uwOp+py
e7wZPn8gGApH0P8PH+EICoILCU+iIB9HAYRS74M7Q8PB1tQZmk9D8iEU7jcdQnvRD3Er+iE6
il7A5+Ctfegw6kM/Q35Ujb6DtqBvoO1IRIsh5S40Dx4B0r+Bg6k+VIweBVp6FB2HstehW9ER
5MOB1AdoK7qD+xW8dQeyoxw0Gc1Bbeir+NrUBrQEvcvfhsrRtWg9asc9qbrUvan7U4+j76PD
3M9SA8iKQmg5PMdTHwn/mfodGglvfBM9hN7F91sOIh1a6YGS30Wd6GGugceplamL0INsdCP0
gUcz0XF8jCSg9hb0Pg7gLdxUqOV7qWTqJSgVQQ1oFXoYHcFj8XSSLSxJzUwdRz5oYxPU+hDq
RYfg6Uc/Rm9hm3Au9XjqHAqiInQ1jKcP/QIf4wYHtg1WUUQDlkagCshpQz9B/45O4hj+N9Im
2IQSQRduSr2OvGgMWgi9fRLe/BP+O7kVnq3cy/y01BTkALx8jWIb/RT9HodwMZ6NF5ERpI08
wnUiGVocA08zagV8Pwi1v4MT+BCxkRPc9/hn+Eti5uCplANmJI6+jb6L/g3bYaQa7sJfwW/i
P5KpZCn5NvkD9w3+Kf6XUhOM+ga0Dn0VPYP+jt14PJ6Lr8er8Ba8HX8NP4SP45P4DJlMFpA1
5GNuFdfB/ZifAs98vou/TbhTuFs8M1g3+NLgfwz+PVWSuhPNBXrYBr3/JnoERnYYnUC/gedd
9AcsYCt2wKPhbLwQ3wzPrfir+DG8Fz+F+6CVk/gP+AP8Cf4bvkQQPCIJk2ySA0+MdJIbyTfI
d8gJeE6Sv5DPOD+XwyW4sVwlV8+1Qa+2c7vgOcj9ng/xJ/gU4LlEeEDYLewVnhFeEM6JNukr
MpJf+/x7A4UD7wyiwR2DDwz2Dvalfo8yYA5DgIUoqoTeN8GzGub7AaC4fehX2Aa4C+FCPAlf
C5hZilfjDrwJMHk7fhh/n/X9R/h5wNKv8cfQZzuJsD6PImPJFDIbnhtIC+kgu8j9pI+8SS5y
EmflnFwGV8hN5xq4Fq6b28w9wCW517i3uT9wF7jP4UnxCh/lc/g4n+Cn80v5Dfwj/Pv8+8IS
4VXhPVER14l3iv3iX6Vx0iRpjjRXapDukw5Jr8uNQJ0vooPo2eFrHp/itnE13EF0Lynlg+QX
5BdAz0tRMzeTAKWSvXgHuQX3kVxhkziRTMSz0Dk+Drh+mewmF8hEbiauxfPRajLGqE308k9D
UMm/iM7yz8PYfgE1bxJt+FbysWhDvRiRCmjzp9xoPsG9it7i3sUS/yj6La9gPz5LnuTmABX8
mJ8k1KFs7jvoR1wHvgUdJDUIKZfke4COZ+GngS8swCX4Uy6FODILqKic+yO6Da0h/4nOwjre
gb6Fm/mV6F5Uireg99ETsCpGCOvFQjED/5y08juJB/chwj8Fo6vAuZgTvOh23MA9LH5MfoM2
oBO8gt7hfgC9P0F+xM3kzwnz8CpYAbegO1FHahvaLNTxv8QrEYcXoTz+FHC3LVwJnw3hVuAq
S4CnHYLVfQT4wGRuJqQEgHKuBbpYCBziYXgeBD7BAwW1whq/DrjYL1CfuID0o5WCAwPXQYh/
dXAeWpx6Aj2UWonWp+5HI4EfbE9tgRr3ovfQfWgvvmPwZtSOsmDlvIOvFaaRE8K01Eiyk/yG
zCcPXDm/gO08HEAfwvMjiEwSnkM7+V+j+agqdU/qDaDuAuCwD6Fl6Bp0Gkb5EbQwgzuGSgdn
kf2paVw7jPddNDf1ZCqKFbQqtRbNRs+j70sCapISMMdJ/EsY782ohcxLdXMtg62Ah/sACzpg
awPwn7v0qQsXTNarJl1VOXFCxfjysWWlJWNGF48aWZQoHFGQH8/LjeVka9GszEg4FAz4fRle
j9ulOh12m1WxyJIo8BzBqKgmNq1RS8Ybk3w8NmPGSBqPNUFC07CExqQGSdOuLJPUGlkx7cqS
OpRc8Q8ldaOkPlQSq1olqhxZpNXEtOTx6pjWjxfPrQP4q9Wxei15lsEzGbyLwXaAs7PhBa0m
sKpaS+JGrSY5beOqnTWN1VDdfqsyNTa1RRlZhPYrVgCtACX9sfb92D8JM4D4aybsJ0i2Q6eS
oVh1TTIYq6Y9SHJ5NU3NyTlz62qqw9nZ9SOLknjq8tiyJIpNSToTrAiayppJilOTEmtGa6Wj
QXdr+4uO7bynX0XLGhO25lhz05K6JNdUT9twJaDd6qT/ptOBy1Go3D21bvvw3DC3sybQqtHo
zp3bteSeuXXDc7OpX18PdcC7JG9a485p0PQ9gMTa+Rq0Ru6or0viO6BJjY6EjsoYX0ushqY0
rtaSltiU2KqdqxthakI7k2je5uzeUEg/nDqFQjXazgV1sexkVThW31Qd2e9FO+dtPhDUteCV
OSOL9qsuA7H7HU4TsNmHAy1DeQxixSlUO28Is5j2KHY1EERSW65BT+piMKbx1GsZj3YuHw/F
4FOP4a1kM8xIa9IytXGnOoGm0/eTQp4a03b+DQEFxM7+5cqUJjNFzFP/hihI6WSI1CA/DScT
iWRhISURaSrMKfRxEouPHVm0sZ/EYu2qBgGgD80B3DbVTygG9Gdn0wm+u19HyyCS7JlbZ8Q1
tCzci/TiRH2SNNKcY+mcjIU0pyedM/R6YwwouY+JyBlJOT70dao+T82qCUns+xfZLUZ+7fxY
7dzFdVrNzkYTt7ULrogZ+eOH8kwo6Zlax4WJCZEwx3KBKJcMFaaROluSz4OvyIi6uV+SgSpZ
CtamJdXGGYZfr2Rn/y++1J86R99iweXXzG4mJySujE+8In5F92w7OegwbJW1Cxbv3KlckQek
ZjR4tRkAxaMFddna1CRaCCszD779qWPjqasPJ3VA2VRaAOjPSDKjVxQMm3A9fCh1jiyaBoxu
585pMW3azsadTf2pnmUxTY3tPExeIC/sbK9pTBNOf+rI3eHktHvqAVer8ARYFARN2R/DO+bu
1/GO+YvrDqugP+1YUNdLMJnaOKV+fy7k1R3WENJZKqGpNJFGNBpBtRgG2UtkVj58WEeoh+Xy
LIHFl/djxNLkdBpGy/uJkaam0wik8UaaztLoh/KYqQvqhlMPW5L1I4EaCWYCtoBAYgdtMtuV
7coDD8Om+7nGHftcF9AlpPHHEK079b7wtvA6SNRh7NNrQ07sVb3esD8c5nmV91r91jD/lP+Q
42UH5/cHwkTL1F2zPbP9eqhOqLNcpy50LfUs9i8NLApdF77b/xBRg1kc586yWjL6U4N9NtuU
hQB80me1MuCCrtjsAMU1CUv9qfMsHYAzfapKKPBRn93OgHPwLgM+hDLiQlbYbmfARb3KZgMo
1JOJM52EtuF00IqcrHJnXAM8yjQB2WgCEmkNSKQvoWBk+ZJAYpZ6PgGfhplnwZ+lNlxIGB8j
AVWdrTo7ZjRu6EANDQ0dHhVll/DuDC/hYzm5pFxFpSXIVUbisRy0HO/A417F057pGzx09MTg
kb0/w5m//i0Ob/7ga78Y/DV5Ba/D331h8Pu/e3dwz8Gf4cU/Gfz74AlchsMHsPXrg+9BPx+H
mcoBrdKKbYeRPXVM93kyynguy6LsUU4qRBEIscqyIKexKaexKVNsWuj4ZE2SRIo6p5MsBOAT
3UqRKKoUgxA/pRdSBIiYIkBs6LFjO7EytFkZ2qwMbVYNU7zBAtIV6ALS6IxA9AKrlgG0VkTx
b6U1UxSLNP73PobZ/tSnuo9OEWqwaXas2efYG+3tdn5ifSDR0KGmUZxoqBwAvzKN9EqVRVFV
ZVVlRUNx5UAlYD5R6ioFqi11xcB//AVy8YUXBkThyMATZPHFaeTAwEzo6VGQ67YB5jicowcJ
Gw/HfCLRUXHMx/2pzxi6oHuf6S4KEYEOl2M+ZF/qYzQCgEGbGGQPIgAaDoy/qoyFpWVGOHK0
ERaMMMJYnhFmZhlhIMRCvdCulmnCLmGfwHEaLMX70B6URHwxSIRzQM87hwS3Bom7EMeKs8lC
ARPdf0mj+6M0ui/obCKRxtD9GP8m4DONzQZg5r09COOG+o7OyoGGNI4BnVUUjUMfis+jLwhH
Lk6DNf8ISNgDgDk7SObn9KwW1xovqVVrvder13t5qy3L6XAgfyCLUFS404TnThMeAJ8esgOm
3HFGgy4KywrtrazSPkLqeX0kpQk5pIUwfEMBO5sZO6M3O8Oz3aC3/zmZ2Uwyu5gms3O6YpBZ
cOKSy6hI09UstcOgLHMpVwFFuStMumpADUBXJf4sAqs5O9sF8LixZfH8eCz7ETLi/plr76//
aPDngzvwzc8/0nDtmNsH7xKOONwth9Y9Nzgw8AMO37N1yW0Zdmo3yx6cy33Ex1GIrNGjzgDF
gddG/Qzm+5jv5BmeKD6KKeRgqXbm24wSNooXB/PtzLfZ0tjWFYotG8PZfkLZvZ6peJ2gHkeC
TrdoFT2626lZdZvmDFDkOYPFidDbocDxUFClAYy96qzbXzFmdPiAM4Kd/al39HWRigLvIuc+
hdPtupM4tYLRZSr1JJvF7bMH3PnWfFu+fZxtnH2s4yGXtcBd4Jnhq3fXe+ozWt2tntaMzeJG
+2bXTd6bMu6w73Td477Hc5f3QWWv9Xn1OdcR74fK+96/2QfUz7ypSJZ7v8h67fNYI2HeWe28
3ck5g0PdZ/1zuSsaMHgVYb3c6bSpLrdbQVzQ6/HkuRUvRJw2p8uWZ1W8VqvicbttNqtIK0AR
NUKKI0cjJNJPqg46ARe6t58s0K1Vbt1NlrqPuom7H0855MQ5qCas0CyGLV2zjbbNtnFzbCkb
sUGJA8VOwA2p6gtrW1YEEoC8gY7zDR2hwFkAzwbU86eD6umGjrOhgHqWQSgA+0OlCs92YVRC
vkV9CcJAwgEAgpFsd6iVlfJLtUnH/NpkAHbn55AtdQZZU2fweJBNgAph0R5G3tQ7h8orlJzy
CgfsfwczKlw5GRWUbusbOoBuOxoSsKgTV3xQwpPvKy0ZV04fXOrx+ceVe0qxKIliLGerd2JR
5Qy/Ky5YB9e98HYiJ5r4Y9/g2sm5o7csKhtc+ZRakBte48zkCwYe2rBty0ay5tLP9k2pn09l
gGmpM9y7wA9cKBMf1bcohLfn2cvs1XZhrHds5DqyQJnnnR9ZSZqFFstyb2PkWPR14Q3P28H3
PO95P/b/Ofhe5qloKuqLRhOhSl9lqDbUHt0VlUaRXPso3wQy1l5LauzTvFdHrlMW2Vfa3xPf
913E5x0qzuAcVtWJwhGr5EJKRoSzBoC39NF1QYFn6UIIlNI96ZNnGQ/PcznTBZxUIGBbP10p
+Wz7z1PVky6sunRXo6vHxUd1q5UsjOqUn7jclM+46Ep00bXiEh0O8AMsj22ZlMu4HKoq0vhH
jNe4jMYMQG+krbm63TJb08YqZWvTnSupNCapNOeodEJ6V0pJfFSqkmZLnJRFeyEFmDiTxaQb
xtEkGxNnQkyUCWaVzRmSSoCVdZjsa2DY7Dd0VKo0DfbLytOGkFJJnasCiG7MaNSAOxpQR/ZY
oIV4fGyZe1xpic8PbB97Kc0Al4vliNz4lpe2vrFh9eu3NT5QfGBA+8GGjd/fe/OmR+985J5L
39uNuZ1zJxMH7LDu1175t5ffeu0lyukeREh0AnWonF+3yYVWGCNhvsGTDiMZNgHGqmWH3UUW
ErZ3AQC720d6AYVsbpotOG2cBWEiW6wOJFuIYhXppFhVihQrMPhDtJRVhfn+U5+5LXya3hY+
N7aFYkDAceYB9zh2TD158pgLWFwiYex2KGyynKjEtkuR+RzzeeYLmrlFfaLHKETYZHBMOCQO
6lts1FeYL6UpQKYUEKVQXMA2TXGXOZkn2DiEHVYky5godOC0NiVNQMpzZBFyI5Us0u3mPiam
ZSVWLcJ0LOeLz9P5BAGo0hhMw7C9GzE/rG9FxCl7SVjmN9rutP0MUGm72na1kxvB59mLHHXc
9fxG+ybHdrtsJYJcYR/nmE1quWpJl2fapziUB8lD3APSA/Je7klJdBPY4UcLxCsIRAYyHC3I
AMq2ec55WMeEyPT8B8QSh0Ol89To7gFeeoTsRXY8plfQ5H48RvfZLArbnxSF0r6i6batVmw9
AgN2YCuUIv0QODHb0U0BjJEJQJqzXcVqP1n0rCY0Cj0CyEFk7wEXFRSD6vmG8w2VgQEqGDIG
DLHQsOjpBmC/gCh12BNSz56lrHj7LS9tB0YMASyH2qQV+G8W8N8fA/+9BFT6JiKpN8cDD8a1
SRvkFUAelbk/3e9QaCpjy/bU64eyKxxF2RX2fgCBO5eUM/DgSEgdWWFMSn0nXWsNwKHrERWu
sjHlxTgb5FUcw64HcS6+frQvOBYvxcJzg4v2DdYJRy598rUZc77NfX5xGv/qpbH8qUsaXV13
AAN+mZ8EvPcdfWaxB6s8jvFl/FR+Pr+C7+ZFi0u2yBa7x2WxI07G1ogoYREploJdMpZzNA/2
kBwXY0MuxphcjDG58gxJXi0dV3aOWig0dBKdAv2PEl56aekuygMRz6QskXIpts4oC0SUUfqc
ziGClRm1znJPf2mYxEX5FBO6TqsN5ztPG/t5RQV82Y6O1J9vd7C5aOjEIHeVZowDnuSXKCOS
xAzXHY9Naq26/oZJU6ZMvMGbxccf7Zgx4cn86VWNnQOvw65UnTrD5wNm7CiIjx7KCNAeeKiq
SAHg+mf0FgoFWYZbUoK26eIMeZFYL68UW2W5TJ3gnuAbG6hRa921vprAEmGJZZ7a4G7wzQus
E9ZZmtV17nW+5sCNOMMiCvbruQXCAuV621quRWhR1toUf4SXXBGr1ZuWe73pHcdLcedhEl9u
mO0uYbbTUGXV2F0ktq9Iqpl6Lq3CnkursOf6KG5NNZcBx3RHbl7ZaAkjSZU02DboDCi0EWnM
u2EcpiXWZcXKRgPskA1hkomObO4ducjmoIzSzbikjU1phE2pg7EdB5s/G5tbH5tRHZqLoipA
NBNEEauNMinwx4TKys15HlIpEmzv6UiAcN1wOTExXF+mawIWkW6ZL8y3LBOWWXhYIIx/edRy
mHqU4aWSCvIM25GqH7/rp7/Fvpv/fPe7g2cP926/s/fAHdt7iQfn37tx8PcDx//8FZyF7a+9
+tp//PTVV4CS54CschaoIoT/6zDygy6Qw9iPTH0L853MV5nvYr4pPJc5toKkZ8VUDWtHHOLd
IHgEIrwVOzIkma4FuidTn+3VxuxR/pw4/vrLbIzqSw0l1IFErU+32HA0MtUz1T/fM9/f6Gn0
f5t8m3vY/rj6eMgm24PKatLKrRY22NrtPfYnbActh5SDNpsPePcfCefIWepsc24FcRj3k6f1
+GimGzZCt3aBsngKdEQLcjqt6HIfI1RIHS7yuJnIk+tgK9ORE2a6u5FPtUd9G5vJXGsiijEo
iFh3JEC51elcY52WwuOYgqxT+sA6pQw8g1IGDtEa8dWRDNnQZ5gRh5FZRu4JCVO5hkiMrCSF
via5GQ0zMpJYaWlMuOwyowDZmZLOZa7RaZqtDiNMzXWQ23meElInQzIoa66KYrUBmMppyjs6
cENHvbkdYj8jIJcp3UhxSkIZjJy4yv2ZH//orcG/d35w1w9/F90X3Lp4x9OP3776XnyH/9kT
OBMrP8Bk275Hw2vWvvirN1/4ChB+LXCYLKClDJB7H9H9URTJIAu5BqHBstDawq0R2iwtVjmj
P3U6LQSe1udRKDNC/Xz3b4SL3gshfox7QnBMZLJ7ZmhyZK57SXBepMm9LtQU2SRuyrhALgRU
5MNOu98/x9foa/dxvohzl7pHJarKhyOKhI6QpykeGFvGjBFQpKowZd/0wMT7DSYxZaE/zYj8
aQXcr8PG9DsmGNkNg4FIgQ8ZT7HTqiz5hWVJO7aHotRAkRcvo+GzlI1EcdQH3F5fwrTVUmO5
qGyWVTbvaq6k5xaWpaVYY16NOdaGSbQRtmIMaogwOmA2ICrRlg+TaCkjmcm2CkgD6fZCxzAV
/Sw1XJxmMw9KfEcl2z2oTEv1dTrrHZ3piTdsb14p20fnHGdT1R3E2huOFH10+IPBj7H3d29g
B/78jNJ7x/J7Bt4ic23jF9215Sm8yP+9PhzFHLbhgsF3Bj9TtX1HVuFv3jl11RN0F64CrrIf
KGE0t1/3+BkWAswPMr8gvbLy00A8DeSlgdw0EEsDOWkgOw1olKlvpRCf482ZYLnGUp27KKcl
Z4vlXsvtuU94nil6gbNb/KGAf3Rt0Zt+IQzSNFFLsBJYIi+xLFGWWJfYlthXy6stq5XV1tW2
1fa+eF++Mz+em587YlzuYqXe2hxvLuiOdef25H5d+Y7t/oJvFX1z9OPKU7bv5T9ecCD+07iv
IG1JzUkDsTSQmwbM8YrpIYjpQYnpYcIioOYEd1bFYjk/z6bwIS2ewVtHZYYoP8sJFjHVK1gV
nB1cGtwXPBEUncFosC34bpCPBu8LkuCPYWvKANmH0b7upcVVKnyq+CQmCKuY0LVwwOsrY2tC
dbjKMB61JHNtJsmMZEi8YTwmC3lDWRAZoHvotspHRlmjIRzKDeqeQFkJfX0s3ZWDAcOnFBv0
UeoNavTNoEbfCqp0VEFGvTQX5v4IuR5JqU8OMSN1biFUdDBScbIQF9I26fuFVByhlTKAvl9I
lx+tAoDzh2gthSHWg2xYiY0lx0pIVUlPCSmhyzsXsa4gle3NmoF8woiEjYhRS5T2TWNUqOU6
2Z7kZH13arSwk9rJ4sz6w5QXJ9MqnSLbJnLeRbgKzQZOFxxjrsaGjpnpFUnXXkKFsHOWCoKc
wZ476JocWrM0E5YnhFVnO2B1Ul7eCdLeAAtglcIXu5iJaepmXc8fmRUTvEVxl+pWPSon5ti1
MLIUSGEsjAQvywvRbEcsjHJidps8QgnjgnyLIib4MIqqmWEMogIV5w2PcfzCxLZt29AwFRg3
UMl7KIEW8pT7DHEiP54/iowtG1dOxUzf5d3B74OHWvwoC4lX9TrvunnLprF5X3/5odmTxxd+
bf4tP17sStq6Wres9vmKw7cf/dai1pdvOfEbfFVkTWdL9VWxQF7J1dtmTd9cEE3MuHllYN6S
eeWxSKZHyS2dvGXJ4t3X/YDaUHYAG6mk1mgk4Sf1IGG6Ecd8kfmSYtqjP0+rQwYgpAGesuNM
ZqFmahLHfJH5EvPh5YH0Bm8AQhqAlwf0TGb9ZjZHjvki8yXmY0OHnpJWps2WKcBankAhyzhK
YLMtuyx7LEnLMcu7lnMWCVmilnZLj2W3mXTKkrIoUQtIFRJPOIvIUfoeyVq9FSNREHlFlPIE
xO/m9/BJ/hh/iheP8ed4gniNPwkxnk+rITwlXz8VvXimhvAKW9Nepq/TpWSu7EG2plg/FUrm
/Cx5+pwrNZHOygFq9a4EcmX7B3V0B+nsSHzZxzO2NINzlbp29PX18X8+ceJSBh+/9BbdD7Yj
xP0J9gMfhv1A4EQP2av2q3/k3vec4y54RJ4aoXOs9rLNKn5QPRk4FUgFeE32Orw+d0QABc1n
V+wOmyNtrHKkt24HW9JMbs8N6BQDAaY6WAuYJcRLMWHtT/2FGtUBYjix5rAS9E1mpLJ6KVKs
9DzDSrFiVSiLsFL1mgliVh2UvpQVw9c6K0DnpqhsXFkycC5A2gN7AsnAsQAf4Ehpho/t8z7G
W3xsf/flGfq6y2VY4NOqojlHpqrI5gjxabM8VXkAIkyr4Bkvo426/1H1nOVXLzQMmwzDXH++
kjGfhitnibIcYALUJkJVSuw2OIxPdFkUWZEUTlTjLtERxk7FTfkG8IHCbfS8DgiBKZqMAfgy
QB8vM7iAa/tjG95ufHSOqvQVrpnR9SQf/9a+mvaZJbcMdJE716+bfP9rA8/TdTxlcC73Icx8
FirEP9UbrVZgaNY877XWGq9oyQxmFlnj3qJYhXWc9xrrNO8iqc66ynpR+VuGY1SsKH9SbFL+
tfm7ivYUSeOyx42oKppmnZZdM2JB9oIRrdLy7OUjGot6it7KP5P9UezjfJffJ2b0k/19BRGP
xNQAVUOjmRLQg44B0iTUT27RVSEScSo1ORGb4ssozStV0rTEAKb8UH00n86lkhcInPRj1a/7
G/09fr5It8KEFTEd1c8soP4hC6ifWUD9PpZHNVdGXLSUSOOGActvsAgGXExLoRf1VUz67Hbi
PJQTZfQTZbQUZVQUzT3qPOF815ly8lFnlXM2aDks3cnso04mPTpDbA/LYXtYhLZs7lzMHuoM
Joq6s6lJNDHrsgDZwcTF82fV4VZRZhZlguUFIJezp6kweZqGleYBboef8n9mNc8H/k8My6h/
bKnL2A+GK6Mr9llLpnbfsiPgwBuTvz23/j+++vxNT7T8ds9PPnzoiVu27P3hTZv21oXm5pU0
Ly5P3o0r334Q43se7Pl89acnNj3DFf7HsaOvvfjyi5R/3Aby5Cl6fxjfdhiFqCCe4S8jmsdX
5qSsI+j2liU8OFf2+GzY47OKSHFFOCsq9aU5hi89y74hjuHLC/jp0g4xvuFnHMPvZpNIOQY7
RvSzFeof4hV+rzmdnxq8wm+ja9VPeYWdIjrlx8f82D8rRFdsPmUToXMh0h7aE0qGUiGeKrL2
9BGUcTBly7MMGZZgC7BolpOwIfCWNEe3DBmWLKwv1JIo0tQLhj3JwviEhdDeWGYFr+DiwASY
pvhPDMEwMlHtsKrSMC4xdhDiVYfdaSeiJIuyIANT4G1hZJddYURZQmHhNtRAJQTTJp4fHwvM
HsQBOuHjKMxVbXnjhu/NVq19Vtf6uXPvndj3nb4Z62aP7SL3Dxz46pjpc+fft4NUwJZA0PbB
Vj4b+IIbZeEH9G6bOlK9Sq1V+SotqZGoNsIWyyzJKMmcktmu7dLkCf4J4Wv814Tr5ettS/xL
wqvlNbZWdZ1/TfiY9ivv24G3Q7/KOu09nXVKS2m+GA9iWMZYfoI6jb9GXay+Z/1z5qBqdTlA
VWTmPl/EYUWOYJokgml1ImgapQHKPalgVdGVRqVH4TW2p2hs2StULLbSBa8EzPhFJrsOt1af
Z+YohdrUxjK7dTf2lJJS86jDOOQwDjzyEDqG8S68ByfxOcxHcRWeDVoVE13opGNmzMfsxBoz
aRUzuzem2wqzMdCijBIws7BjN7M2BKPTywN4uL7ItvSZbGmfP315yRvGBNjoz7KdwTz5gLKo
w2NaGH2+DC+hM57v4oYt7u2PT7h/1Y6Tqze8e/Pi+0a5nti46Zknu7v2D7YKP945d+49qQe/
N3jp7msnDFziHj/+0qtvvPrKr+l+cE3qDB+BeS9A5WSvXmSxWwqD9lDhCHthYYV9XEZ5eELh
1YUN9obC1fbWwsbRO+13jnjY9+3QU/aMAqoT0LHnU7wGKfRE8OmCQ8HnCl4Knij4ZcbbBXK1
D2cxjkxR4Wbbt8DQMpZe25hNoag/GkgUFZZV8BVFV/MzihbJ9YkVcmtio2277ee2z+yfJVzl
ZQ7Mq8W5Zf6SbG9g6Yi2EWREpNhR5bjPsduRcgi7HfscHzs4BztTZ2KIjRKEwxCwiCGVZNPZ
cTAm7BDp/DjiTHQJGFbGCOenW5Q9UMSU4296IxEJDXUd1eQrJcDBRjSpTcMt/p+mxdXPdQeT
PUWm8eRl59KbDrTt3CHelcv4RS41t1C6yTU0PKZx/k630t7lsn7l0j3JUEXJ9bojX0dxNa7F
R8f3xYUK4E19lA5BP38zDZxnxpL4GJqp26nxo+JYBdlTgSsYo1zDWCSzf/jzAjnFjOiLGbkX
M9Ivzj0qnhBJVKwSiehlEr2XSdfsHdHBrt0wy6HIbCKijfZfZHQvMsOryHRLccz4ywJrmpLP
nzUZHk05O0T9jOMl3nuP8rzToH0NMHWreNi7HYb6lda/mKEkgTsa6NlxHtvZQBUyjoqZbkSN
7vmTiCkYZXh9/licEyUHMcxnUIirbD68et/z07tmjF3z1kpcWrNj6+bMZGD9ybt2PD1Htfhz
no/4l73UtqRkXeuqx+KZty2c9swds7bN8jrsodw8Zf3Iq+o7Ah131+pN14zadO7SHVeNx28X
RNSCmcUzGq+ffdWNdF8ELYn7lN52Ii8f4hhyLcPuM32S1oM+0ccwlYlNgsh8wYSZcUlcJC62
cE77fwkXRM5io3QkGkyRGOyM7TxpgKPrjynZC7kbFeIWNU92GTR37oA7v8xCzWsQugWWkM0S
9NshReR5gRfLLdN5IU8cqdQpN3IblLe4P4rSEyKOiXEpT64Qx1uq7LPt9Xy9WCfVW27hNwsP
WV4Wf8m/KZ4WP5D+Ln4mZ7gVReA4noiiZLHIELHIcp4keiVJ5Hg+T1C8gqAooEbxMgYVif78
SrZakcL3Y6duEXjGFHJkGqvRmO1VNa6/7bJju3mDi9GslaHImocISyQskbBEkgdMO20MAHVK
H8PkedWwPwyT6t1MqncPO/MJ2uy/z56+YrgoBiLXTOMo2rg+13GBXpw7nziLjGsR9CTT5a+g
R3L88NsRkipXypUc881zWnutBUctt3PEErC7yqj4bl6Q0BVLUWaFRc7MrISpfac3swKC13s1
FuzPNs7h6tkhHEj9CXZ2J6aO9WZXUHW010eDd3rVCtEIWMzGgv3W9CEelQ1oU+63eSx7fdCa
11vJPHjrQm+AvvyX/WGjOD3KaDAhUzZBxr0qXIpxDEugRuKnPxhcjY++M/joVuHI58/j5ODG
gWYSvWnweqD93NQnpFB4CPlx9DCymbeqrMPu9RmAlAbENKCwy2bxMiZ4zQegJwi6t82uYA75
VEvCqYCEwFmdag7KwfYrNm3F2LRtOCXJNZaaRqld6pF2STySNGmPlJSOSSclkV27NO9fnmfm
LImuRXYgYsijJmDeyLzINnJ6eEUFC7oczTMs42hOOkJWg+A7bv+K4Qo6zCxs42fNu3+nz1ey
+wsDlXQLd5WWqj+n4rpZNM9v3GFwxUBKL4ddPebyUqGNqKFrK5etLbr99gMHD3oSBVmP7lYn
tTxGlt+DpbWDX71n4Oszi0KA6QcQ4guBywjoK7oNE57LEpCs8ZjvJ0/q2RIxrgka/Idjl9G4
/+llNDZ4ljJ02dG8hSYOv4WWvtz4pwZER1c1ZjS7yZjxwAvkl8KRi//1Q8oFPSBY9Ai/AkoY
oWd5LdgZLA6ODurB9uC3bd+xP2WXQ/YCezJ4LMgH6ZTroWhZpmznbM6IgjNIwuvhOdAYdnux
N+Vhg/DovGG09rPJ99uMzYxHHLkfs5PgA2PGlzG1PBGJlgEnCOrMFqrbKRvwsmEXsDHnMMZQ
ZA77E/MOntdU9j9Mnw7/iUmMFDHPMnx8LxB8Hh9B2egCVhDwimH7HD1CrFRBz680WcbZBmqn
qaToOVvhMkR5r+oSLZIoww6rWtxh5BKdYUxl+G3bcKKjAXWWUmIYW1Z++Qg5I4MSRu/u3Z7Q
bRuvXRIeXzKv+sQJ7uF7OtaUTbvO/V1lWuOyez5fAfgWERKeBW3MLSw9jJBx2Sd9cmqjIkCm
zeCU9NiDGcsEw3xGmFFrmOHsQ+O2o8rsqyLzLWnN2GFeWZximl/d6Qx5KENiGTaKVz9j0cZ5
i8hkCt7cDj+/bCli/XTazFuX59P7pJkh2UwzwPm0Fe88laSmLHTlmBln0hvqGePqq0szsk2u
8k7adPjOgcvHpIeRm0p1bNEb0ppo6g2v99nsxKjNSiGXZjMyQOQybHnH9GIKuXQWV1wcRjZR
ErHoVJBit4mUlmwuWJEK71JoxJXmLy4QbY4fV988rr7OrvbAx5RrDBqirDoMeoMXF/IjFHKN
63rXvS6OjofpLafS9sFT6aO6c7olml2mRjKNLV5/Nppbxos2i0cMW4JugUe8aLVYHbJbRR7O
K0XksDXTkYvypEI54ShDY6UJ8kRHNTdd1KWZcq11qnO66xr39c557jVSs7zSvVm8SeqWD4tH
nIfcfxMvWQqsrgJUYM93FDjz3cXe8ajcfaN8p/wg9y3bk3gv2Wt9wnYQHRKPOH4GosFvLGf4
M8733efFi5aIVaQ9tjFfFQ3x27Dhs3sN5j4ZVhxO3o1csgSygzPPQRUxh8TZsS3PDqKuXk4X
qB22eXbVG9ux1yMqVldcSbgW8POUJa61ri2unS7FpfAcwnQ6jIm5jGrjFmZx4jx8aVw9TR9D
yIRvWPdyggCqtiRYFEUGclZUF72OV3tAQG6tP3W1vkJxOrQXXZKsSS63OyFIINhIDpjnPLsD
BGaH7HI6E4rshdeRQKCvyAvMCREsuXnZ6bI57Kx7brvNJsuSRAgW3U56F1nxXlDtmF4m77Fz
9n78pK5osxXcpmxViNJPFuqW2S7c5trqIi4as6oCbhTajYtF+MmD+ILnwgp2+hGceb6hITDQ
0AHfUHAA4D8NiSzpy0QwdPP8kV5kAX/7zOE3i64MgCq3O0CwcaiV1FGYutpkdH5dn12zaeT5
1CmEwTlSJ/vQaKcG6/gUHm9+6muTZfPZDbqT+6XRmCVkz69NlrLDcTl1ar+kGalu8y7TYVrR
IadG6wZOcLJXGk1r7EXjyRGjpaHKh97zs/dcqVMHFI3X0Pjht1AdqdcPuStQETgqV3morFOf
Vr8NESfB7jldeebyZZ9sXOphl1I9fnozNcblc7h28LkjT1XxpU8d3j32qkP7Bvuee2rEr/n4
wLdPu14h6wcefPU4WXHpLbLl4OcnDMu7GAd9O0b+cBh5TJVAHXb33ABcaSAzzZ0jaSCcBkJp
INPQGM0yFAingVAasKWlLXsacKQBZxrwpC2uahpwpwFXGvCkLXhqGnCnAVcasKfPWeU0ACzq
P/WZVntZHn+aP235vf89TXhDuKARv6zFLIGwZuG4WFZEzKCmUgmLsVBQVU7m4V15e/JInt8f
cuTtcmEXzy65smNOF9Or2SVXr8lpz9BNByDCrrqyu0AuplG70pfrh114xQ16VoApuMZBeIDt
iIG8XWEcZg2EhxoIswbC9NKJizYQZkcDYXY3JEyVDWZ6DDPTYzitvIdpCwWIlMZY9TEmuMSY
4BLLwycRphdhCL2gNBtxTGXJ/CeVhenZyGfKJsNurnmZcMJOisybT8HcvH686UD29CttyoaR
ybjCNiyRKebDBJiBWTUt1X/q6ERUbAHZBbQf9azLYBSmLdJh83riXpsrjN32DPNIYlv6/sKX
LZf0nTifn3rDTysoBAA9t3i05InVG78VvfWVR54+EFsyqf0bfXXN126bwMe/OWvpsroj+w4N
5JPvrl064ZuPD3yL9G7aNOfhrw38htqgQdQsZ7+Pmanbh59HXnEGaf4mZtiJ4xWnjNS8c+WZ
4hXniIa8IbBTQ/YbmPLxxm9hysYa4egxRphj/FZGz8vwlzmFqLBbeFfgZ4N3TuCijFenBB42
A4VwxtVFWhMTWDNA6tuN8DF0DlTXL7rHeNGkjOGHU4a8KpsEYZweApBKC+/mMSKaxV95jGhw
PeMkkZ0fdH7hpLlu62M/pQEsPz34Dr4NHUcKmnVQ4ZD0jNiP5+hxzFXC/qXgSjoiiCBxvDRh
NlqK2tBWIGwB7bE++iC0fL6BaUX0qIv6QFcDZw37dunY0gyvKOWPG1d+6Pic60oqxnHHj3fc
HZ8ZbKLa5GOg49B/I7GiPj1DFLLojok4nv5oR7FkWZHM7hQWq+4yaQF3jaZoQAIhO29hqo/F
ML0w1cfyv6z6XOyzWIZSrvwljm3i9cMv+zQYa6pylnqhYeb50wlDFzJ/iKPSX+JQnSjbdI/x
uZ8/wiU+f4O7XTjyw8GqHwzaf8h+VSsEH155lfzyUmfl3+SwzH7J/9gf8wsv/65/cK4YF14H
wGL+jw2dESRNGpyFpl7+8f8//MVLpkhVggq0XPh39DipQEeFRegRHqFsvgtNE59GD5Kn0R0A
V0PaHAhrIazC/452ALwd3BT6/w0Q3mbGr4H8HZCWC/ADEHqgXhHq2Q7v3Abxp6H+x+hvhNEb
uJM4yX7eL8TFN6Rl8jrL15UHbYftexzfdR5zHlOfcn3fc633lYytGSd824MNYRI+GP5rZBkb
QSYaT+mf/roTqagYLYI+/MD6E6AkmjqB0H/z4Vj+auZzbOQKi3HsLQfqNmEO3YC+YsI8lDll
wvQ/WT40YRE5MDFhCS3DqgnLaDTuNGEL2okfM2E7eZoUDeF6LP+mCWMkCFYTJkgSVBPmULHg
N2EeykwzYQHZhFoTFqH8dSYsoTHCDSYso4BwnwlbUI3wpAnb8ULhL1AzBhmXIJs0mcEUQ6o0
k8EiS29gsMTSWxksM3gzgy0Uh9JdJgw4lP7LhAGH0oAJAw5lqwkDDuVWEwYcyl0mDDiU7zZh
wKH8kAkDDuVLJgw4tCRMGHBoOchghfbTtpTBVto32xoG21j6zQx2MHg7g1XaN9vXGewB2G17
lMFeVuYAgzNYPUcZ7GPpJxgcZO/+lsFhVuYDBmeyMp8xOMquCQsMzqXl7S4GFzI4yuCRlBLt
Iykss/6bMGvLXkFhm5Few2A2Fvtc9BQw9RI0mv1jj4YWoFWoBcKZwCnXg+tGm1E7S5kKsU6A
qd8E6a2sxCjImYzWwqOheZC2Et7vRl0s1gJhC5TeCH4zlJwMcCu8u5blrUQbAGqCtH9sa8Kw
kto/lJ0AK4/W2WW2r6GxUPMY6L+GCqCmVrQcctsgvw2tgBpHDKvry968XGImjH94261sJE3g
utmom6GGdawfayCNtvB/grH/3Tf+udyCIaialbwRSq4HLGkgra2Ah2KB5o5k+GtDy1i+hmax
nFWQQrHZhYogbQ5rqZPltLKxzgd/A5RvNvGlAZYqgP+VoHp4cwPEKQ42Q7iBzTDFzioTVytY
X7tZWhv4zSy9nbW3meGS1qtBSifrEy253HynxYw3sZraWevroFQ3y6NvLWN1dJv4W2uOc/1Q
L4w30v3oHFa2nVFFM/R4OWvDwMeNrN8UI188BiNOyy6H1jYwjDQzmv9HTNA31jKoAMqPgJBS
yjKz319c9/r/i7Ffrr15aO472YpLz2Waer5oBOnW/7lfE4fNER2JMZZu1l6aLmn9xlibIeVG
NvI2tjr+FSU0XTHrLWx22kzfGJUBb4BYO/M11tuNQ9Rs1ENLroUS/4qGRj2llYweM0ZbsKpF
m9m2vq17c3uLNrWts72ts6m7tW39KG3y2rXavNaVq7q7tHktXS2dG1uaR03ubG1aO69l5Ya1
TZ3ptyawRM1MnbCopbML3tfGjhozWiuY2bq8s62rbUX3CFZqeCZLmLnAeLu1S2vSujubmlvW
NXWu0dpWfHnHvixjKG0B9ao7m25sXb9Sm71iRevyFm2kNq9tWet6bVbr8lVta5u6irQ5Td2d
rctbm7T5TRvWN0O/tDEV40vq2zZo65o2axu6WrTuVdCrFW3ru7XuNq25tat9LWQ0rW/W2jtb
IXE55LRA2NSltbd0rmvt7m5p1pZthtdatLXQ5npaBWTQOjpZantnW/OG5d0a9OPGVdCRYS1A
2Lp++doNzYBkLd2JtvVrN2sFrSO0lnXLoO5hpdf/y9ZZ8WY6+s6WLjpKip7LDdDXh+qayEZU
0AqtdLeso7jsbIVWm9tuXL+2ran5SiQ0GUNv6dRgRG3QFPgbuts3dGvNLRspmqHMqpa17Vdi
aBQw1Ta2WJvYMoBliu1AhquBED9gbDudNx8I01hadAk1cw9z+7kfc0fBHeaOcD/47434vzfi
/96I/3sj/n9rI76CO16GmxjNfFHe768otxbqGc43Gef8kjrXQpnNw+N8Fj+Gr+Wn81eBX3FF
C+uh3i+rZRb4GxkWjbW+Cifxo6Bj07n98ne+GDZtAiiVT0/F//lzGC3gCg7EA9GTz3Mj0Clw
hBvRm8iMHubyuczeiVG9n4sdcGeUOCeP5KidqJj5Gvht4PaBOwqOR0u5LEhXwd8KrgfcPnBH
wZ0EJ0JHsliuBq4N3G5wp2gOl8lFerWoOjmfC8K7VBt1cn70MbgUOA5FwS8GNxvcUnD3gdsN
TmTlaEobuK3gjoI7x3J0zt97fyn03d97NwsOrF5bwqJNRnRJA4seuK7eCGfONcLqq41iE4xi
Y8qM5FFTjDC/yAjdeSU9NFTsJccm+zgfDJKque3gY/IScmKMomgPl4GS4Agnmik65z6QGy/Z
fZTjEeYIh2GOo6ljHO61u0omKyRFPkZuFCUfkbNGDjl7wOEq2T35GvIHtA/cUXAc+QM8vye/
R1vJKYpz8KvA7QZ3FNwJcB+DE8kpeN6F5x3yDnKSt1ExuCpwS8HtBncU3MfgJPI2+Cr5HbWj
MJ/CVeAI+R34KvktDOu34DvJWwC9Rd6Crv2qt7yi5DADEsUmEM0zAX/YBNy+kn7yy97PRgBF
xWGmgaKe43LQJFTK5fTmjYn2c4HeytZoP/njAS0R3TN5NHkdJQn9/TcCXwWngZsDrhFcOzgR
oDcBehP1gNsFbg+4JDigMvBVcBp5Bdxr4N5Eo8Hp4OaAk8nJXmimn5zojU+JTvaRX5B/R37A
+HHyMxa+Rl5m4avkpyz8OYRZEL5CXu7NiqLJVshH8I4KoQphMeQL5N8O5LqjqckuchRwFwW/
GFwVuNngloK7D5xIjpKc3uaoGyp5Dr0iIyjZiz5g4RPoMRnpq6N6fCoQoEa9+ISrAAJvt7Y7
TvT4Aw9BlHrxe+8HiHrx2+8BiHrxm7YBRL342o0AUS/evBog6sUXLwWIevHZCwACr5888mxu
frR89hqsTXaSGwFLNwKWbgQs3Yh4ciN90Gc87du3ewsLAWMP64kRhdGeI7jnedwzD/c8hnta
cM+tuGcb7qnEPTfgngTuieCeLNyj457n8HhARQ/W+66IVugB3PMK7vkh7unCPXHck4d7cnGP
hsv1fpLde3UpC2pYcGAyXXQQXjUJuI+TZANGs4Hms4EnHAX/BLgUi+lQSMsxCgezaJhzoLDK
iI+aUNI2eQZ5EV58EabhRfQuOB4m6EUgoxehkhehAif4VeCWgjsG7mNwKXAilM6Bjt/HfCf4
xeCqwC0FtxXcx+BE1p2PwRHUZnZxH+tYsdnp2TRGXoSH/llzNsnWM9WImlBncPdFsDMLz85K
ZZFy5PMBR3a7ZFc/th/6u/3Tv9uRZbKF3EvuQ5kwEbvM8L7ezzKj/fjB3vhz0ckZ+Fsoiweq
wxUojvMgHI+6WHwsisg0LEMR8gyEJb2RRfCaszdeFD2CHfStQ9HPIqejH0T6CYBnIs9Ff631
87g3+gakPHMo+nrkrujPi/tlSHk+3o8hOKKxoocj46M/fIUV3QYZD/dGb6XBoegtkenRNRGW
0WJk3NAFMd0ZnRdfHJ0B9VVHlkX1LqjzULQqckO00ig1lr5zKDoaupAwwELo7IgIazSWxSpc
WN6PV+lF0gNSnTRbGieVSEVSthSVMqWw5JXdsio7ZJusyLIsyrxMZCR76SXqBLVBe0WVBiJP
fZ7BKqE+MQ4ICJYJugYlPVwtqZ0/Bdcmjy1Htcu05IX5sX6szF2cFGJTcNJdi2oXTEmOT9T2
S6l5yfJEbVKac33dfozvrYfUJNnRj9GCun6cokl3hOl/yB5GGLvu+GqYhgV3fLW+HgV8G6sC
Ve5Jropp1V/gNZr+sCOnwBVwZvKB2vl1yacz65MlFEhl1tcmv07/ZPYw/gSfq6k+jP9Kg/q6
w9wk/EnNPJrOTaqur6/tx4tYOaThv0I5oJi/snIybMy0HNLkLKPcw0a5PHgfyuXSAMpZLCiP
lcuzWFg5HtNy+7tya6r35+ayMn4NdbEyXX5teJlX8qBMXh4r4+tBr7Ayr/h6aJnkJFYkEoEi
WRFWBIdQhBWJ4BArsuhykWKzyF1DRe5iLXH4cpmIUcZ+Kl3GfgrK/Iu7C1d+WqYkEvjAxPrl
S+gf9DbGalrANSbv3rgqkOxZpmn7l9eb/9wbb1y2fBUNm1qS9bGW6uTyWLW2f+KSL8heQrMn
xqr3oyU1C+r2L9Fbqnsn6hNrYk3V9Qemzykrv6Ktu4baKpvzBZXNoZWV0baml39BdjnNnk7b
KqdtldO2puvTWVuI0ficuv0ymlI/dYkRHiBWBei1MZxdP8Wntk9ixDsxO3Br+AhIK3uRNVGf
tMWmJO3gaNbIySMn0yxYUzTLQf+F2cwK3DoxO3wE7zWzVEh2xaagRPeGrg0oUNNabXy74ANJ
3Rsowg0/0fVlH8irSepN1V3dCNUmC+fXJqvmLq7bL0mQ2kiHlJyQTrNaa/pTx4zEUZA4gSZy
3FBBmlZJ0ywWs+A/z/8GM2S3ZHrIcwewnoW7UVc9l8yqXUCAFSww/+72CMhSdHvoqocBduEE
7krXYXY7/R9OCUTHnHbdG0zIxEW3GRpvwitdaZQMfSiyEkMY64YK0f8AVuAI0QplbmRzdHJl
YW0KZW5kb2JqCgo2IDAgb2JqCjE1NDgwCmVuZG9iagoKNyAwIG9iago8PC9UeXBlL0ZvbnRE
ZXNjcmlwdG9yL0ZvbnROYW1lL0JBQUFBQStBcmlhbE1UCi9GbGFncyA0Ci9Gb250QkJveFst
NjY0IC0zMjQgMjAwMCAxMDA2XS9JdGFsaWNBbmdsZSAwCi9Bc2NlbnQgOTA1Ci9EZXNjZW50
IC0yMTEKL0NhcEhlaWdodCAxMDA1Ci9TdGVtViA4MAovRm9udEZpbGUyIDUgMCBSCj4+CmVu
ZG9iagoKOCAwIG9iago8PC9MZW5ndGggMzQ3L0ZpbHRlci9GbGF0ZURlY29kZT4+CnN0cmVh
bQp4nF2Sy26DMBBF93yFl+0iwiY8EgkhJSSRWPSh0n4AsYcUqRhkyIK/r2eGtlIXoGP7znCw
HZbVqbLdHL66Qdcwi7azxsE03J0GcYVbZwMVCdPpeR3RW/fNGIS+tl6mGfrKtkOeB+GbX5tm
t4iHgxmu8BiEL86A6+xNPHyUtR/X93H8gh7sLGRQFMJA6/s8NeNz00NIVZvK+OVuXja+5C/w
vowgIhorVtGDgWlsNLjG3iDIpSxEfrkUAVjzby3accm11Z+N81Hlo1LGPpzLiHmHvGXeI8fE
iUROiDOaT4nTGDnj/Al5x5kIec8Z6n9g3iIfmRPkkvM0f+J56n9mPiNfmDPPShJH6KPYP8M+
iv0zmmf/VCGzf3pEXv3RWbF/XCKzf5oir/70rdUf/0ut/pRn/4iY/eOENnzdWdx6vBs/Ryr0
3Tl/nHSB6BzxBDsLv3dsHEasoucbADas7AplbmRzdHJlYW0KZW5kb2JqCgo5IDAgb2JqCjw8
L1R5cGUvRm9udC9TdWJ0eXBlL1RydWVUeXBlL0Jhc2VGb250L0JBQUFBQStBcmlhbE1UCi9G
aXJzdENoYXIgMAovTGFzdENoYXIgMjgKL1dpZHRoc1s3NTAgNzc3IDcyMiAyNzcgNjY2IDUw
MCA1NTYgODMzIDMzMyA1NTYgNTAwIDU1NiA1MDAgMjIyIDU1NiA1NTYKMjc3IDU1NiA1NTYg
NTU2IDUwMCAyNzcgNTU2IDI3NyA3MjIgODMzIDIyMiAyNzcgNjY2IF0KL0ZvbnREZXNjcmlw
dG9yIDcgMCBSCi9Ub1VuaWNvZGUgOCAwIFIKPj4KZW5kb2JqCgoxMCAwIG9iago8PC9GMSA5
IDAgUgo+PgplbmRvYmoKCjExIDAgb2JqCjw8L0ZvbnQgMTAgMCBSCi9Qcm9jU2V0Wy9QREYv
VGV4dF0KPj4KZW5kb2JqCgoxIDAgb2JqCjw8L1R5cGUvUGFnZS9QYXJlbnQgNCAwIFIvUmVz
b3VyY2VzIDExIDAgUi9NZWRpYUJveFswIDAgNTk1IDg0Ml0vR3JvdXA8PC9TL1RyYW5zcGFy
ZW5jeS9DUy9EZXZpY2VSR0IvSSB0cnVlPj4vQ29udGVudHMgMiAwIFI+PgplbmRvYmoKCjEy
IDAgb2JqCjw8L0NvdW50IDEvRmlyc3QgMTMgMCBSL0xhc3QgMTMgMCBSCj4+CmVuZG9iagoK
MTMgMCBvYmoKPDwvQ291bnQgMC9UaXRsZTxGRUZGMDA1MzAwNkMwMDY5MDA2NDAwNjUwMDIw
MDAzMT4KL0Rlc3RbMSAwIFIvWFlaIDAgODQyIDBdL1BhcmVudCAxMiAwIFI+PgplbmRvYmoK
CjQgMCBvYmoKPDwvVHlwZS9QYWdlcwovUmVzb3VyY2VzIDExIDAgUgovTWVkaWFCb3hbIDAg
MCA1OTUgODQyIF0KL0tpZHNbIDEgMCBSIF0KL0NvdW50IDE+PgplbmRvYmoKCjE0IDAgb2Jq
Cjw8L1R5cGUvQ2F0YWxvZy9QYWdlcyA0IDAgUgovT3BlbkFjdGlvblsxIDAgUiAvWFlaIG51
bGwgbnVsbCAwXQovT3V0bGluZXMgMTIgMCBSCj4+CmVuZG9iagoKMTUgMCBvYmoKPDwvQ3Jl
YXRvcjxGRUZGMDA0NDAwNzIwMDYxMDA3Nz4KL1Byb2R1Y2VyPEZFRkYwMDRDMDA2OTAwNjIw
MDcyMDA2NTAwNEYwMDY2MDA2NjAwNjkwMDYzMDA2NTAwMjAwMDMzMDAyRTAwMzY+Ci9DcmVh
dGlvbkRhdGUoRDoyMDEyMTExNTE1MDIyM1onKT4+CmVuZG9iagoKeHJlZgowIDE2CjAwMDAw
MDAwMDAgNjU1MzUgZiAKMDAwMDAxOTI0MSAwMDAwMCBuIAowMDAwMDAwMDE5IDAwMDAwIG4g
CjAwMDAwMDI2NzcgMDAwMDAgbiAKMDAwMDAxOTU0OSAwMDAwMCBuIAowMDAwMDAyNjk4IDAw
MDAwIG4gCjAwMDAwMTgyNjMgMDAwMDAgbiAKMDAwMDAxODI4NSAwMDAwMCBuIAowMDAwMDE4
NDc0IDAwMDAwIG4gCjAwMDAwMTg4OTAgMDAwMDAgbiAKMDAwMDAxOTE1NCAwMDAwMCBuIAow
MDAwMDE5MTg2IDAwMDAwIG4gCjAwMDAwMTkzODQgMDAwMDAgbiAKMDAwMDAxOTQ0MCAwMDAw
MCBuIAowMDAwMDE5NjQ4IDAwMDAwIG4gCjAwMDAwMTk3NDkgMDAwMDAgbiAKdHJhaWxlcgo8
PC9TaXplIDE2L1Jvb3QgMTQgMCBSCi9JbmZvIDE1IDAgUgovSUQgWyA8QkIxODU2NjUwQTNC
NjY5MUM2OTA3Q0U4ODEzM0NGRUM+CjxCQjE4NTY2NTBBM0I2NjkxQzY5MDdDRTg4MTMzQ0ZF
Qz4gXQovRG9jQ2hlY2tzdW0gLzA3MDBBRTAyRTcwMkQ0N0EyQjMwNzhCNkY2RkYwMDRFCj4+
CnN0YXJ0eHJlZgoxOTkxMQolJUVPRgo=
--------------020405050606000107050304--

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

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIILUDCC
BRowggQCoAMCAQICEG0Z6qcZT2ozIuYiMnqqcd4wDQYJKoZIhvcNAQEFBQAwga4xCzAJBgNV
BAYTAlVTMQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoT
FVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3Qu
Y29tMTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQg
RW1haWwwHhcNMTEwNDI4MDAwMDAwWhcNMjAwNTMwMTA0ODM4WjCBkzELMAkGA1UEBhMCR0Ix
GzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UE
ChMRQ09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENPTU9ETyBDbGllbnQgQXV0aGVudGlj
YXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC
ggEBAJKEhFtLV5jUXi+LpOFAyKNTWF9mZfEyTvefMn1V0HhMVbdClOD5J3EHxcZppLkyxPFA
GpDMJ1Zifxe1cWmu5SAb5MtjXmDKokH2auGj/7jfH0htZUOMKi4rYzh337EXrMLaggLW1DJq
1GdvIBOPXDX65VSAr9hxCh03CgJQU2yVHakQFLSZlVkSMf8JotJM3FLb3uJAAVtIaN3FSrTg
7SQfOq9xXwfjrL8UO7AlcWg99A/WF1hGFYE8aIuLgw9teiFX5jSw2zJ+40rhpVJyZCaRTqWS
D//gsWD9Gm9oUZljjRqLpcxCm5t9ImPTqaD8zp6Q30QZ9FxbNboW86eb/8ECAwEAAaOCAUsw
ggFHMB8GA1UdIwQYMBaAFImCZ33EnSZwAEu0UEh83j2uBG59MB0GA1UdDgQWBBR6E04AdFvG
eGNkJ8Ev4qBbvHnFezAOBgNVHQ8BAf8EBAMCAQYwEgYDVR0TAQH/BAgwBgEB/wIBADARBgNV
HSAECjAIMAYGBFUdIAAwWAYDVR0fBFEwTzBNoEugSYZHaHR0cDovL2NybC51c2VydHJ1c3Qu
Y29tL1VUTi1VU0VSRmlyc3QtQ2xpZW50QXV0aGVudGljYXRpb25hbmRFbWFpbC5jcmwwdAYI
KwYBBQUHAQEEaDBmMD0GCCsGAQUFBzAChjFodHRwOi8vY3J0LnVzZXJ0cnVzdC5jb20vVVRO
QWRkVHJ1c3RDbGllbnRfQ0EuY3J0MCUGCCsGAQUFBzABhhlodHRwOi8vb2NzcC51c2VydHJ1
c3QuY29tMA0GCSqGSIb3DQEBBQUAA4IBAQCF1r54V1VtM39EUv5C1QaoAQOAivsNsv1Kv/av
QUn1G1rF0q0bc24+6SZ85kyYwTAo38v7QjyhJT4KddbQPTmGZtGhm7VNm2+vKGwdr+XqdFqo
2rHA8XV6L566k3nK/uKRHlZ0sviN0+BDchvtj/1gOSBH+4uvOmVIPJg9pSW/ve9g4EnlFsjr
P0OD8ODuDcHTzTNfm9C9YGqzO/761Mk6PB/tm/+bSTO+Qik5g+4zaS6CnUVNqGnagBsePdIa
XXxHmaWbCG0SmYbWXVcHG6cwvktJRLiQfsrReTjrtDP6oDpdJlieYVUYtCHVmdXgQ0BCML7q
peeU0rD+83X5f27nMIIGLjCCBRagAwIBAgIQXDFQ28QtqMuYch5f2nTvZjANBgkqhkiG9w0B
AQUFADCBkzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4G
A1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENP
TU9ETyBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTAeFw0xMTA5
MDIwMDAwMDBaFw0xNDA5MDEyMzU5NTlaMIIBNzELMAkGA1UEBhMCR0IxEDAOBgNVBBETB1dG
NCA0V0ExFzAVBgNVBAgTDldlc3QgWW9ya3NoaXJlMRIwEAYDVQQHEwlXYWtlZmllbGQxFDAS
BgNVBAkTC0dyYW5nZSBNb29yMR8wHQYDVQQJExY4OSBHcmVlbmZpZWxkIENyZXNjZW50MRcw
FQYDVQQKEw5HcmlkbWVyZ2UgTHRkLjE0MDIGA1UECxMrSXNzdWVkIHRocm91Z2ggR3JpZG1l
cmdlIEx0ZC4gRS1QS0kgTWFuYWdlcjEfMB0GA1UECxMWQ29ycG9yYXRlIFNlY3VyZSBFbWFp
bDEWMBQGA1UEAxMNUm9iZXJ0IENyYWdpZTEqMCgGCSqGSIb3DQEJARYbcm9iZXJ0LmNyYWdp
ZUBncmlkbWVyZ2UuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEArcThqvLe
WU1Q1ZJmnb+2UQSwOQKWok3A1Mwk582AdvwaAQyBFliPyJ0kXJqtwNBoZvk+3WJr0QA5ZRr+
J0x3sXVpcxadojP2HNzy1gsgDtIGG8ltoU4vmX1A8BTlOIUT+Pg8p/bSruxV0vz0CR8ho2hs
R0Zi5vU+rQKNmbgufbkWhlQnMEYjknemscLQfw1YZz90ta67doNDujFy6+X6I06HpjudgMYx
8bdsNS5xVFFwuBA1eqNQra+xLzhCOeX9PPB/zK68qdNhrni3WPYG9EhSt4Dzk+xIz9hj7wrU
ZIVXDTPsY8qbUSBVpwmzI5lCHPgzurH1OK7WwgpDSsl5pwIDAQABo4IB1TCCAdEwHwYDVR0j
BBgwFoAUehNOAHRbxnhjZCfBL+KgW7x5xXswHQYDVR0OBBYEFBCOXNH+lDm8U9gy3b3bRvrx
vKgrMA4GA1UdDwEB/wQEAwIFoDAMBgNVHRMBAf8EAjAAMB0GA1UdJQQWMBQGCCsGAQUFBwME
BggrBgEFBQcDAjBGBgNVHSAEPzA9MDsGDCsGAQQBsjEBAgEDBTArMCkGCCsGAQUFBwIBFh1o
dHRwczovL3NlY3VyZS5jb21vZG8ubmV0L0NQUzBXBgNVHR8EUDBOMEygSqBIhkZodHRwOi8v
Y3JsLmNvbW9kb2NhLmNvbS9DT01PRE9DbGllbnRBdXRoZW50aWNhdGlvbmFuZFNlY3VyZUVt
YWlsQ0EuY3JsMIGIBggrBgEFBQcBAQR8MHowUgYIKwYBBQUHMAKGRmh0dHA6Ly9jcnQuY29t
b2RvY2EuY29tL0NPTU9ET0NsaWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5j
cnQwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmNvbW9kb2NhLmNvbTAmBgNVHREEHzAdgRty
b2JlcnQuY3JhZ2llQGdyaWRtZXJnZS5jb20wDQYJKoZIhvcNAQEFBQADggEBAD6b/O0LkPav
kR4Znoqxg0Ad7M3duDm4uzfrlX4ecgq56Ccdwd+3Tayz7Ewej30woVMmTKkA/NKRaCd0wVM9
8seF/oZjXKO7o1SH27igRnGSWjCoWXsdwJGfZbYnvcIIhhsxJoCPNbeSR7C0PAFDKsP3xrJy
MHMljIJsoRbZu/fnYNyFWh9OXf7fYJOGmKDKAhSabUGfhY7umvU9d/YTqo02Q6YzC7d4zPNG
1a75AuHSEchf6GdKqycG38I5y9jlDaYfXspoS3PlTNCIeZONbOSMZgftnNEVKq+SWytFqyG/
8+dwpm/a12KMex5J8iHwaUKj++2O2rAFNjDDqXpeEYoxggQZMIIEFQIBATCBqDCBkzELMAkG
A1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9y
ZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENPTU9ETyBDbGllbnQg
QXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIQXDFQ28QtqMuYch5f2nTvZjAJ
BgUrDgMCGgUAoIICRTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP
Fw0xMjExMTUxNTA5MzJaMCMGCSqGSIb3DQEJBDEWBBScIC0ZN3McCV/2IeKrfaNXsz0h4DBs
BgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcw
DgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEo
MIG5BgkrBgEEAYI3EAQxgaswgagwgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVy
IE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1p
dGVkMTkwNwYDVQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUg
RW1haWwgQ0ECEFwxUNvELajLmHIeX9p072YwgbsGCyqGSIb3DQEJEAILMYGroIGoMIGTMQsw
CQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxm
b3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVu
dCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhBcMVDbxC2oy5hyHl/adO9m
MA0GCSqGSIb3DQEBAQUABIIBADqAop7O5TjeoUo8ez9ouA9Oa8Xb/+4ygNz3NphIMqHMb8nu
xv8KoBaF1TMiBHZ3IuxpJ30mhgGZ9X+jEPz0fhiFP/xFrdoP369x8bk1V8iTWBLJPoRV5JmN
hbjonG7bmg5HJ66+Vc+8407pWj9eoOLCvGORfxAe8r78xbGLUzFsBEEYYOjDDYuEcJN2yEH1
ikfouXnTmiwCaqebXiTd9hswWUEly+USreT0zBvi6Ovhs43XrkzrJyxZ1s0WjbJXvsnAko7z
PsjmI0xqs35yKsOAvLDbfcBI8/7EXqMsuoaBg4eVi/khcojHzj7ixYkBMx0fAk4t3QDJAQyS
QUBpuqgAAAAAAAA=
--------------ms030004090400050807090403--

From dat@exegin.com  Thu Nov 15 09:59:59 2012
Return-Path: 
X-Original-To: roll@ietfa.amsl.com
Delivered-To: roll@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00C7121F88A9 for ; Thu, 15 Nov 2012 09:59:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.36
X-Spam-Level: 
X-Spam-Status: No, score=-3.36 tagged_above=-999 required=5 tests=[AWL=0.238,  BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PQW+xptJ1SK6 for ; Thu, 15 Nov 2012 09:59:57 -0800 (PST)
Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 3261A21F8947 for ; Thu, 15 Nov 2012 09:59:57 -0800 (PST)
Received: by mail-pb0-f44.google.com with SMTP id uo1so1336852pbc.31 for ; Thu, 15 Nov 2012 09:59:57 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:x-gm-message-state; bh=5NZFqk178n7Uljy1BZyXA+y3rAle7h0dd56nWN4onzU=; b=aC0zgrNSFiEYM4ZmH2eOeYGWZA7bPsi6ue1v2os8aHa+J4bMT2izqogEGkqr02Idqx EnUWrPo4SgXf2PkQj5JNJOs7Sn6z0RimLHAPwX5xj+I+1DStlt96J3dyLNiHPIBCCWHp QV3n6K2R01ivK3A3bXLCsSKfqcf5WYY9O/v1NXOPZGVamwGbw2SiXOwXKo+DYye2WnDG u4aNJtmp/GsunyHVrOOtf36yZfeT1hFAPUU/t3GEXoypXbv4R+1BsaU2ebD/FsMwncEi 5QhIhaGPxhdT/8NcpfUmIZrf5Y+WtY/ZR8HExjm78LWYBA+tuy++MscXxev7x+oc/8zU SVJg==
Received: by 10.68.229.194 with SMTP id ss2mr7247714pbc.17.1353002396789; Thu, 15 Nov 2012 09:59:56 -0800 (PST)
Received: from [172.16.1.52] ([184.71.143.130]) by mx.google.com with ESMTPS id oj1sm9839121pbb.19.2012.11.15.09.59.55 (version=SSLv3 cipher=OTHER); Thu, 15 Nov 2012 09:59:55 -0800 (PST)
Message-ID: <50A52D91.5000206@exegin.com>
Date: Thu, 15 Nov 2012 09:59:45 -0800
From: Dario Tedeschi 
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:7.0) Gecko/20110922 Thunderbird/7.0
MIME-Version: 1.0
To: Michael Richardson 
References: <058.e817419e990e1afb26be9aa25d5cfc21@trac.tools.ietf.org>  <50932647.3050509@exegin.com>  <5094202F.4010805@exegin.com>  <509C03C2.50809@exegin.com>  <509C5F00.2050204@exegin.com> <509D5AF5.4040304@exegin.com> <509DAFEF.5020504@exegin.com> <9143.1352758442@sandelman.ca>
In-Reply-To: <9143.1352758442@sandelman.ca>
Content-Type: multipart/alternative; boundary="------------070204030109060809090400"
X-Gm-Message-State: ALoCoQkiIWAomq9BQuSx14BuJwRGn8lbHkgsD5GM+eV3XdVbZHPgPxolRGn3o4VVzA1lIfZVRkrO
Cc: "" 
Subject: Re: [Roll] [roll] #105: trickle-mcast: how to determine scope of MPL domain
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Routing Over Low power and Lossy networks 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 15 Nov 2012 17:59:59 -0000

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

On 12/11/2012 2:14 PM, Michael Richardson wrote:
> see inline
>
>>>>>> "Dario" == Dario Tedeschi  writes:
>      Dario>  Non-link-local would be fine with the following caveats:
>
>      Dario>  1. A non-link-local mc address that *uniquely* identifies the MPL
>      Dario>  domain must exist, whether it be IANA assigned or determined at
>      Dario>  run-time.
>
>      Dario>  2. A packet injected into an MPL domain that has a mc address that does
>      Dario>  not match the MPL domain address must be tunneled.
>
> okay...
> a packet with a link-local mc address does not need tunnelling, because,
> by definition, it can not leave the MPL domain, so it never needs
> tunnelling?
Agreed. I was assuming we were only talking of the forwarding of 
non-link-local multicasts. Of course, link-local scoped packets must not 
be forwarded.


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


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


  
    
  
  
    On 12/11/2012 2:14 PM, Michael Richardson wrote:
    

      
see inline



      

        

          

            

              

                
"Dario" == Dario Tedeschi <dat@exegin.com> writes:


              

            

          

        

      

      
    Dario> Non-link-local would be fine with the following caveats:

    Dario> 1. A non-link-local mc address that *uniquely* identifies the MPL
    Dario> domain must exist, whether it be IANA assigned or determined at
    Dario> run-time.

    Dario> 2. A packet injected into an MPL domain that has a mc address that does
    Dario> not match the MPL domain address must be tunneled.

okay...
a packet with a link-local mc address does not need tunnelling, because,
by definition, it can not leave the MPL domain, so it never needs
tunnelling?


    

    Agreed. I was assuming we were only talking of the forwarding of
    non-link-local multicasts. Of course, link-local scoped packets must
    not be forwarded.

    

    

    

      

      

      

      

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


    

    

  


--------------070204030109060809090400--

From ulrich@herberg.name  Thu Nov 15 15:38:53 2012
Return-Path: 
X-Original-To: roll@ietfa.amsl.com
Delivered-To: roll@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9CC921F8855 for ; Thu, 15 Nov 2012 15:38:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.695
X-Spam-Level: 
X-Spam-Status: No, score=-2.695 tagged_above=-999 required=5 tests=[AWL=0.281,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NhfXbecjVs7M for ; Thu, 15 Nov 2012 15:38:52 -0800 (PST)
Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id BCA8721F8694 for ; Thu, 15 Nov 2012 15:38:52 -0800 (PST)
Received: by mail-vc0-f172.google.com with SMTP id fl11so2487732vcb.31 for ; Thu, 15 Nov 2012 15:38:52 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herberg.name; s=dkim; h=mime-version:date:message-id:subject:from:to:content-type; bh=y7jHPc1JUqVI/x2KF3GSjS2Q9sNKPdbhMVRS654cycg=; b=wWXvR6UM4DXMWicxqTzimYti1l8Q7KCQAUudS7okVwlCC1ttSUxnqXZV9lxLFuTabr pRrNTA93Umk2cslDpP2Rcj2br4EqNTpJe7uD1jgE93yQU9KfLVYcvrz0uDg+aS8ML24S KOyDzYqfuUltkgVVa+52+1yPIF3pUNavA4dUk=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type :x-gm-message-state; bh=y7jHPc1JUqVI/x2KF3GSjS2Q9sNKPdbhMVRS654cycg=; b=b5eJpjxI5yspYhWEi76e7Nwy1z3MyLpxhM1uiLg/la9tcbYZU++3VJdpZ5B00WvpUa B7HTtFDiIzxlfMwC5TCNWSWZ+qBPlZ5v+EAXd6jm/XXSJfgpnsYZfQQYWuQ+9gdqk06j ge0n71axnBA692DHzVb2EsRsxRfEpAtO0iIIwaMRj3vPFB53snGSrLwVGNawul/yTm9L BLH8e88i70M8/dmXuP4v82P3U+tCi3DHrwzZHym48iQiNFKaWgMKyOwIGYSfpGclOTXr aZP8VDJBuQvWxYIJ8rw97jgJXtuLCdWEnIbDisnp8B6RuF8IybuXxFafq+sgydxHxCDm xgxg==
MIME-Version: 1.0
Received: by 10.220.119.196 with SMTP id a4mr3805487vcr.19.1353022732153; Thu, 15 Nov 2012 15:38:52 -0800 (PST)
Received: by 10.58.94.103 with HTTP; Thu, 15 Nov 2012 15:38:52 -0800 (PST)
Date: Thu, 15 Nov 2012 15:38:52 -0800
Message-ID: 
From: Ulrich Herberg 
To: roll WG 
Content-Type: multipart/alternative; boundary=bcaec54ee94e52b39004ce9127a6
X-Gm-Message-State: ALoCoQnniME0Tyrheo2hcU9XQCnLKZFqXtowEHMxtxUUKLnZR+g0Ntd+IP/D6dyNGYmJfRWBV4Ah
Subject: [Roll] Proceedings
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Routing Over Low power and Lossy networks 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 15 Nov 2012 23:38:53 -0000

--bcaec54ee94e52b39004ce9127a6
Content-Type: text/plain; charset=ISO-8859-1

Dear chairs, dear WG secretary,

could you please upload the missing slides of slots that have been
presented in the ROLL meeting?

Thanks
Ulrich

--bcaec54ee94e52b39004ce9127a6
Content-Type: text/html; charset=ISO-8859-1

Dear chairs, dear WG secretary,

could you please upload the missing slides of slots that have been presented in the ROLL meeting?

Thanks


Ulrich


--bcaec54ee94e52b39004ce9127a6--

From esko.dijk@philips.com  Mon Nov 19 00:03:44 2012
Return-Path: 
X-Original-To: roll@ietfa.amsl.com
Delivered-To: roll@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DED221F8645 for ; Mon, 19 Nov 2012 00:03:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level: 
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kPIlqFRgwB82 for ; Mon, 19 Nov 2012 00:03:42 -0800 (PST)
Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe005.messaging.microsoft.com [216.32.181.185]) by ietfa.amsl.com (Postfix) with ESMTP id A1D7621F8635 for ; Mon, 19 Nov 2012 00:03:42 -0800 (PST)
Received: from mail162-ch1-R.bigfish.com (10.43.68.238) by CH1EHSOBE013.bigfish.com (10.43.70.63) with Microsoft SMTP Server id 14.1.225.23; Mon, 19 Nov 2012 08:03:41 +0000
Received: from mail162-ch1 (localhost [127.0.0.1])	by mail162-ch1-R.bigfish.com (Postfix) with ESMTP id 7EE0C2C04D3; Mon, 19 Nov 2012 08:03:41 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:157.55.7.222; KIP:(null); UIP:(null); IPV:NLI; H:mail.philips.com; RD:none; EFVD:NLI
X-SpamScore: -31
X-BigFish: VPS-31(zz217bI15d6O9251Jd6eah542Mzz1de0h1202h1d1ah1d2ahzz1033IL17326ah8275bh8275dhz2dh2a8h668h839h944hd25hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h15d0l1155h)
Received: from mail162-ch1 (localhost.localdomain [127.0.0.1]) by mail162-ch1 (MessageSwitch) id 1353312219875150_6540; Mon, 19 Nov 2012 08:03:39 +0000 (UTC)
Received: from CH1EHSMHS007.bigfish.com (snatpool2.int.messaging.microsoft.com [10.43.68.238])	by mail162-ch1.bigfish.com (Postfix) with ESMTP id C9EEEC005A;	Mon, 19 Nov 2012 08:03:39 +0000 (UTC)
Received: from mail.philips.com (157.55.7.222) by CH1EHSMHS007.bigfish.com (10.43.70.7) with Microsoft SMTP Server (TLS) id 14.1.225.23; Mon, 19 Nov 2012 08:03:38 +0000
Received: from 011-DB3MPN2-083.MGDPHG.emi.philips.com ([169.254.3.209]) by 011-DB3MMR1-010.MGDPHG.emi.philips.com ([10.128.28.49]) with mapi id 14.02.0318.003; Mon, 19 Nov 2012 08:03:36 +0000
From: "Dijk, Esko" 
To: Michael Richardson 
Thread-Topic: [Roll] [roll] #105: trickle-mcast: how to determine scope of MPL domain
Thread-Index: AQHNwkOFtl9ztYUSrkiATuslfJmcUZfpG0MQgAVVjYCAAmIfMA==
Date: Mon, 19 Nov 2012 08:03:35 +0000
Message-ID: <031DD135F9160444ABBE3B0C36CED618B1D844@011-DB3MPN2-083.MGDPHG.emi.philips.com>
References: <058.e817419e990e1afb26be9aa25d5cfc21@trac.tools.ietf.org>  <50932647.3050509@exegin.com>  <5094202F.4010805@exegin.com>  <509C03C2.50809@exegin.com>  <509C5F00.2050204@exegin.com> <109e9168af966b0ee543f13886fef7ef@xs4all.nl> <8796.1352758060@sandelman.ca> <895d55da5f389dc29760cd52aaf91d61@xs4all.nl> <031DD135F9160444ABBE3B0C36CED618B0C67D@011-DB3MPN2-082.MGDPHG.emi.philips.com> <6733.1353180917@obiwan.sandelman.ca>
In-Reply-To: <6733.1353180917@obiwan.sandelman.ca>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [62.140.132.87]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: philips.com
Cc: "roll@ietf.org" 
Subject: Re: [Roll] [roll] #105: trickle-mcast: how to determine scope of MPL domain
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Routing Over Low power and Lossy networks 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 19 Nov 2012 08:03:44 -0000

> Yes, this is my belief as well.
> so I still do not think that we have a clear use case/description of what=
/how a less-than-subnet MPL domain would be
> defined/used.

A clear use case seems to be Peter's office topology where all nodes are co=
nnected as a single LoWPAN with one 6LBR. Each office/room can be configure=
d as an MPL domain. The event information sent by a pushbutton or sensor (t=
o trigger the lights) only needs to be disseminated to all the nodes in the=
 local room; hence defining a separate MPL domain is useful.

Esko

-----Original Message-----
From: mcr@obiwan.sandelman.ca [mailto:mcr@obiwan.sandelman.ca] On Behalf Of=
 Michael Richardson
Sent: Saturday 17 November 2012 20:35
To: Dijk, Esko
Cc: consultancy@vanderstok.org; roll@ietf.org
Subject: Re: [Roll] [roll] #105: trickle-mcast: how to determine scope of M=
PL domain


>>>>> "Dijk" =3D=3D Dijk, Esko  writes:
    Dijk> a question from your last 2 emails is the following: if
    Dijk> multiple LoWPAN networks are assigned the same 802.15.4
    Dijk> channel (which is likely as Peter explained), would they not
    Dijk> be assigned a different Pan-ID to logically separate them? So
    Dijk> for the drawing that shows the 6 border routers case, there
    Dijk> would be no mutual connectivity between dissemination regions
    Dijk> anyway.

Yes, this is my belief as well.
so I still do not think that we have a clear use case/description of what/h=
ow a less-than-subnet MPL domain would be defined/used.

It seems to me that we understand how we would implement such a thing, at l=
east.


--
Michael Richardson , Sandelman Software Works
IETF ROLL WG co-chair.    http://datatracker.ietf.org/wg/roll/charter/


________________________________
The information contained in this message may be confidential and legally p=
rotected under applicable law. The message is intended solely for the addre=
ssee(s). If you are not the intended recipient, you are hereby notified tha=
t any use, forwarding, dissemination, or reproduction of this message is st=
rictly prohibited and may be unlawful. If you are not the intended recipien=
t, please contact the sender by return e-mail and destroy all copies of the=
 original message.


From jeonggil.ko@gmail.com  Mon Nov 19 00:33:34 2012
Return-Path: 
X-Original-To: roll@ietfa.amsl.com
Delivered-To: roll@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A29C21F8444 for ; Mon, 19 Nov 2012 00:33:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.297
X-Spam-Level: 
X-Spam-Status: No, score=-1.297 tagged_above=-999 required=5 tests=[AWL=2.302,  BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qmtWljfzlgxu for ; Mon, 19 Nov 2012 00:33:33 -0800 (PST)
Received: from mail-pa0-f44.google.com (mail-pa0-f44.google.com [209.85.220.44]) by ietfa.amsl.com (Postfix) with ESMTP id D6ECD21F8438 for ; Mon, 19 Nov 2012 00:33:33 -0800 (PST)
Received: by mail-pa0-f44.google.com with SMTP id hz11so1299703pad.31 for ; Mon, 19 Nov 2012 00:33:33 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=4kI80Hth27nuFLV39e9/34jCMKg3BCfzaqXRwMHW7Cg=; b=N5n6PGirXiarVSoMvmcrqTzejq+h9lyPo0BJeqSQxHfp8ZZd1Hg27SYg72XZJ5uyj6 7sZ0BAWQurZf0pgIbd35e3iemTRH9zO0z/HxHdJ4+p3nWLA5aSKuxl2Mj6XiidmubMJS tSmEgVhusSlVceqEUA9rhw+qSS4MSHBA2GwKmQggEqLcPuqWaFy1zdcqieHYhOuUbPfU aXvPVsA5E9CENC7O9RO+pW7vKcX6rMdxPeX3pWJ2s1ApdK/3u0yvmDU/5BBAg4wtmilE 6/coCUyLq1oY2iwMCcwkkn++rsRXZFhtPO72jA5EYKhSXrLDkyi09Mhi7u/LaECucnsM UVfQ==
Received: by 10.66.75.162 with SMTP id d2mr33728115paw.27.1353314013676; Mon, 19 Nov 2012 00:33:33 -0800 (PST)
Received: from [10.211.10.10] ([129.254.38.231]) by mx.google.com with ESMTPS id g10sm5825181pav.9.2012.11.19.00.33.31 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 19 Nov 2012 00:33:32 -0800 (PST)
Content-Type: text/plain; charset=iso-8859-1
Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
From: JeongGil Ko 
In-Reply-To: 
Date: Mon, 19 Nov 2012 17:33:28 +0900
Content-Transfer-Encoding: quoted-printable
Message-Id: <8B619F6B-0F88-4E11-AD0C-012CE3A6011B@gmail.com>
References: 
To: Ulrich Herberg 
X-Mailer: Apple Mail (2.1499)
Cc: roll WG 
Subject: Re: [Roll] Proceedings
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Routing Over Low power and Lossy networks 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 19 Nov 2012 08:33:34 -0000

Additionally, can we also get the minutes from the meeting as well?

-John

------
JeongGil Ko, Ph.D.
Researcher
Electronics and Telecommunications Research Institute (ETRI)
http://sites.google.com/site/jeonggilko/

On Nov 16, 2012, at 8:38 AM, Ulrich Herberg  wrote:

> Dear chairs, dear WG secretary,
>=20
> could you please upload the missing slides of slots that have been =
presented in the ROLL meeting?
>=20
> Thanks
> Ulrich
> _______________________________________________
> Roll mailing list
> Roll@ietf.org
> https://www.ietf.org/mailman/listinfo/roll


From robert.cragie@gridmerge.com  Mon Nov 19 04:46:49 2012
Return-Path: 
X-Original-To: roll@ietfa.amsl.com
Delivered-To: roll@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71FEE21F8596 for ; Mon, 19 Nov 2012 04:46:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.001,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q9O1qVB+0pQN for ; Mon, 19 Nov 2012 04:46:49 -0800 (PST)
Received: from mail41.extendcp.co.uk (mail41.extendcp.co.uk [79.170.44.41]) by ietfa.amsl.com (Postfix) with ESMTP id BAF4A21F859D for ; Mon, 19 Nov 2012 04:46:48 -0800 (PST)
Received: from client-86-9-227-213.oxfd-bam-1.adsl.virginmedia.com ([86.9.227.213] helo=[192.168.0.2]) by mail41.extendcp.com with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.77) id 1TaQkQ-0006en-UT for roll@ietf.org; Mon, 19 Nov 2012 12:46:47 +0000
Message-ID: <50AA2A9A.1030000@gridmerge.com>
Date: Mon, 19 Nov 2012 12:48:26 +0000
From: Robert Cragie 
Organization: Gridmerge Ltd.
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121026 Thunderbird/16.0.2
MIME-Version: 1.0
To: roll@ietf.org
References: <058.a2b4f297c2cf9334c783ff7c900bdb13@trac.tools.ietf.org>
In-Reply-To: <058.a2b4f297c2cf9334c783ff7c900bdb13@trac.tools.ietf.org>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms010802020806020408010409"
X-Authenticated-As: robert.cragie@gridmerge.com
Subject: Re: [Roll] [roll] #108: trickle-mcast: should there be an explicit version field?
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: robert.cragie@gridmerge.com
List-Id: Routing Over Low power and Lossy networks 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 19 Nov 2012 12:46:49 -0000

This is a cryptographically signed message in MIME format.

--------------ms010802020806020408010409
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable

Regarding having an explicit version field: I have thought about this=20
more and I am happy with the text in draft 02 as it stands, as it leaves =

it free for future versions to define the reserved fields in more detail =

providing at least 1 bit is set to 1. I certainly wouldn't see the point =

in making the whole set of reserved bits into a version number as this=20
could limit flexibility in the future.

Robert

On 01/11/2012 2:29 PM, roll issue tracker wrote:
> #108: trickle-mcast: should there be an explicit version field?
>
>   > 3. Version field:
>   > I think adding an explicit version field ( 2 bits should be enough)=

>   > will help.
>
>   OK.  Any additional inputs from the WG?
>



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

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIILUDCC
BRowggQCoAMCAQICEG0Z6qcZT2ozIuYiMnqqcd4wDQYJKoZIhvcNAQEFBQAwga4xCzAJBgNV
BAYTAlVTMQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoT
FVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3Qu
Y29tMTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQg
RW1haWwwHhcNMTEwNDI4MDAwMDAwWhcNMjAwNTMwMTA0ODM4WjCBkzELMAkGA1UEBhMCR0Ix
GzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UE
ChMRQ09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENPTU9ETyBDbGllbnQgQXV0aGVudGlj
YXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC
ggEBAJKEhFtLV5jUXi+LpOFAyKNTWF9mZfEyTvefMn1V0HhMVbdClOD5J3EHxcZppLkyxPFA
GpDMJ1Zifxe1cWmu5SAb5MtjXmDKokH2auGj/7jfH0htZUOMKi4rYzh337EXrMLaggLW1DJq
1GdvIBOPXDX65VSAr9hxCh03CgJQU2yVHakQFLSZlVkSMf8JotJM3FLb3uJAAVtIaN3FSrTg
7SQfOq9xXwfjrL8UO7AlcWg99A/WF1hGFYE8aIuLgw9teiFX5jSw2zJ+40rhpVJyZCaRTqWS
D//gsWD9Gm9oUZljjRqLpcxCm5t9ImPTqaD8zp6Q30QZ9FxbNboW86eb/8ECAwEAAaOCAUsw
ggFHMB8GA1UdIwQYMBaAFImCZ33EnSZwAEu0UEh83j2uBG59MB0GA1UdDgQWBBR6E04AdFvG
eGNkJ8Ev4qBbvHnFezAOBgNVHQ8BAf8EBAMCAQYwEgYDVR0TAQH/BAgwBgEB/wIBADARBgNV
HSAECjAIMAYGBFUdIAAwWAYDVR0fBFEwTzBNoEugSYZHaHR0cDovL2NybC51c2VydHJ1c3Qu
Y29tL1VUTi1VU0VSRmlyc3QtQ2xpZW50QXV0aGVudGljYXRpb25hbmRFbWFpbC5jcmwwdAYI
KwYBBQUHAQEEaDBmMD0GCCsGAQUFBzAChjFodHRwOi8vY3J0LnVzZXJ0cnVzdC5jb20vVVRO
QWRkVHJ1c3RDbGllbnRfQ0EuY3J0MCUGCCsGAQUFBzABhhlodHRwOi8vb2NzcC51c2VydHJ1
c3QuY29tMA0GCSqGSIb3DQEBBQUAA4IBAQCF1r54V1VtM39EUv5C1QaoAQOAivsNsv1Kv/av
QUn1G1rF0q0bc24+6SZ85kyYwTAo38v7QjyhJT4KddbQPTmGZtGhm7VNm2+vKGwdr+XqdFqo
2rHA8XV6L566k3nK/uKRHlZ0sviN0+BDchvtj/1gOSBH+4uvOmVIPJg9pSW/ve9g4EnlFsjr
P0OD8ODuDcHTzTNfm9C9YGqzO/761Mk6PB/tm/+bSTO+Qik5g+4zaS6CnUVNqGnagBsePdIa
XXxHmaWbCG0SmYbWXVcHG6cwvktJRLiQfsrReTjrtDP6oDpdJlieYVUYtCHVmdXgQ0BCML7q
peeU0rD+83X5f27nMIIGLjCCBRagAwIBAgIQXDFQ28QtqMuYch5f2nTvZjANBgkqhkiG9w0B
AQUFADCBkzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4G
A1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENP
TU9ETyBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTAeFw0xMTA5
MDIwMDAwMDBaFw0xNDA5MDEyMzU5NTlaMIIBNzELMAkGA1UEBhMCR0IxEDAOBgNVBBETB1dG
NCA0V0ExFzAVBgNVBAgTDldlc3QgWW9ya3NoaXJlMRIwEAYDVQQHEwlXYWtlZmllbGQxFDAS
BgNVBAkTC0dyYW5nZSBNb29yMR8wHQYDVQQJExY4OSBHcmVlbmZpZWxkIENyZXNjZW50MRcw
FQYDVQQKEw5HcmlkbWVyZ2UgTHRkLjE0MDIGA1UECxMrSXNzdWVkIHRocm91Z2ggR3JpZG1l
cmdlIEx0ZC4gRS1QS0kgTWFuYWdlcjEfMB0GA1UECxMWQ29ycG9yYXRlIFNlY3VyZSBFbWFp
bDEWMBQGA1UEAxMNUm9iZXJ0IENyYWdpZTEqMCgGCSqGSIb3DQEJARYbcm9iZXJ0LmNyYWdp
ZUBncmlkbWVyZ2UuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEArcThqvLe
WU1Q1ZJmnb+2UQSwOQKWok3A1Mwk582AdvwaAQyBFliPyJ0kXJqtwNBoZvk+3WJr0QA5ZRr+
J0x3sXVpcxadojP2HNzy1gsgDtIGG8ltoU4vmX1A8BTlOIUT+Pg8p/bSruxV0vz0CR8ho2hs
R0Zi5vU+rQKNmbgufbkWhlQnMEYjknemscLQfw1YZz90ta67doNDujFy6+X6I06HpjudgMYx
8bdsNS5xVFFwuBA1eqNQra+xLzhCOeX9PPB/zK68qdNhrni3WPYG9EhSt4Dzk+xIz9hj7wrU
ZIVXDTPsY8qbUSBVpwmzI5lCHPgzurH1OK7WwgpDSsl5pwIDAQABo4IB1TCCAdEwHwYDVR0j
BBgwFoAUehNOAHRbxnhjZCfBL+KgW7x5xXswHQYDVR0OBBYEFBCOXNH+lDm8U9gy3b3bRvrx
vKgrMA4GA1UdDwEB/wQEAwIFoDAMBgNVHRMBAf8EAjAAMB0GA1UdJQQWMBQGCCsGAQUFBwME
BggrBgEFBQcDAjBGBgNVHSAEPzA9MDsGDCsGAQQBsjEBAgEDBTArMCkGCCsGAQUFBwIBFh1o
dHRwczovL3NlY3VyZS5jb21vZG8ubmV0L0NQUzBXBgNVHR8EUDBOMEygSqBIhkZodHRwOi8v
Y3JsLmNvbW9kb2NhLmNvbS9DT01PRE9DbGllbnRBdXRoZW50aWNhdGlvbmFuZFNlY3VyZUVt
YWlsQ0EuY3JsMIGIBggrBgEFBQcBAQR8MHowUgYIKwYBBQUHMAKGRmh0dHA6Ly9jcnQuY29t
b2RvY2EuY29tL0NPTU9ET0NsaWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5j
cnQwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmNvbW9kb2NhLmNvbTAmBgNVHREEHzAdgRty
b2JlcnQuY3JhZ2llQGdyaWRtZXJnZS5jb20wDQYJKoZIhvcNAQEFBQADggEBAD6b/O0LkPav
kR4Znoqxg0Ad7M3duDm4uzfrlX4ecgq56Ccdwd+3Tayz7Ewej30woVMmTKkA/NKRaCd0wVM9
8seF/oZjXKO7o1SH27igRnGSWjCoWXsdwJGfZbYnvcIIhhsxJoCPNbeSR7C0PAFDKsP3xrJy
MHMljIJsoRbZu/fnYNyFWh9OXf7fYJOGmKDKAhSabUGfhY7umvU9d/YTqo02Q6YzC7d4zPNG
1a75AuHSEchf6GdKqycG38I5y9jlDaYfXspoS3PlTNCIeZONbOSMZgftnNEVKq+SWytFqyG/
8+dwpm/a12KMex5J8iHwaUKj++2O2rAFNjDDqXpeEYoxggQZMIIEFQIBATCBqDCBkzELMAkG
A1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9y
ZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENPTU9ETyBDbGllbnQg
QXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIQXDFQ28QtqMuYch5f2nTvZjAJ
BgUrDgMCGgUAoIICRTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP
Fw0xMjExMTkxMjQ4MjZaMCMGCSqGSIb3DQEJBDEWBBTJ+5f0kZDqLbvxO1FzwNUBtAJPGDBs
BgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcw
DgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEo
MIG5BgkrBgEEAYI3EAQxgaswgagwgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVy
IE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1p
dGVkMTkwNwYDVQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUg
RW1haWwgQ0ECEFwxUNvELajLmHIeX9p072YwgbsGCyqGSIb3DQEJEAILMYGroIGoMIGTMQsw
CQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxm
b3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVu
dCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhBcMVDbxC2oy5hyHl/adO9m
MA0GCSqGSIb3DQEBAQUABIIBAKy9o+AbfD5MCGrahhtIcf3GYqcafnR1/CV52geDA1ozgsDl
U18wsYwtU+tJQ6ia+iHhkZr/PqO+BkTC+m/CA7kJkDXeWJ3xg/UYP9TJk15+17sFl514If+H
YCZsNPSkhJEnu/bJpd8M3QtT78K6gUSnnc1zCSOxgcJUKPgTeYdeXjZPI9uD4MPhdRU0dbFn
La4ROaz8d5dPkKwSZx9GTnaS7ZiTBQcCAxrnGtdmyOkKCiLSfxfOZ0lWlGjoZyhpR7Ab00QN
dniel/O5cIcEe4KMj6fiHhcPfZfBNk9/hmhShNdAA8lJvPdRF7tDGMrkXl7w563B5hyq9vYl
N1NfEZYAAAAAAAA=
--------------ms010802020806020408010409--

From esko.dijk@philips.com  Mon Nov 19 07:33:05 2012
Return-Path: 
X-Original-To: roll@ietfa.amsl.com
Delivered-To: roll@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D924021F8697 for ; Mon, 19 Nov 2012 07:33:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.207
X-Spam-Level: 
X-Spam-Status: No, score=-3.207 tagged_above=-999 required=5 tests=[AWL=0.392,  BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r9esDxOotNXq for ; Mon, 19 Nov 2012 07:33:05 -0800 (PST)
Received: from db3outboundpool.messaging.microsoft.com (db3ehsobe006.messaging.microsoft.com [213.199.154.144]) by ietfa.amsl.com (Postfix) with ESMTP id C387621F8683 for ; Mon, 19 Nov 2012 07:33:04 -0800 (PST)
Received: from mail97-db3-R.bigfish.com (10.3.81.237) by DB3EHSOBE007.bigfish.com (10.3.84.27) with Microsoft SMTP Server id 14.1.225.23; Mon, 19 Nov 2012 15:33:03 +0000
Received: from mail97-db3 (localhost [127.0.0.1])	by mail97-db3-R.bigfish.com (Postfix) with ESMTP id 9CAD8160420; Mon, 19 Nov 2012 15:33:03 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:157.55.7.222; KIP:(null); UIP:(null); IPV:NLI; H:mail.philips.com; RD:none; EFVD:NLI
X-SpamScore: -32
X-BigFish: VPS-32(zz217bI15d6O9251Jd6eah542M1432Izz1de0h1202h1d1ah1d2ahzz1033IL17326ah8275bh8275dhz2dh2a8h668h839h944hd25hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h15d0l1155h)
Received: from mail97-db3 (localhost.localdomain [127.0.0.1]) by mail97-db3 (MessageSwitch) id 1353339181585487_16268; Mon, 19 Nov 2012 15:33:01 +0000 (UTC)
Received: from DB3EHSMHS001.bigfish.com (unknown [10.3.81.237])	by mail97-db3.bigfish.com (Postfix) with ESMTP id 8264C6005A; Mon, 19 Nov 2012 15:33:01 +0000 (UTC)
Received: from mail.philips.com (157.55.7.222) by DB3EHSMHS001.bigfish.com (10.3.87.101) with Microsoft SMTP Server (TLS) id 14.1.225.23; Mon, 19 Nov 2012 15:32:57 +0000
Received: from 011-DB3MMR1-016.MGDPHG.emi.philips.com (10.128.28.100) by 011-DB3MMR1-011.MGDPHG.emi.philips.com (10.128.28.50) with Microsoft SMTP Server (TLS) id 14.2.318.3; Mon, 19 Nov 2012 15:32:47 +0000
Received: from 011-DB3MPN2-083.MGDPHG.emi.philips.com ([169.254.3.209]) by 011-DB3MMR1-016.MGDPHG.emi.philips.com ([10.128.28.100]) with mapi id 14.02.0318.003; Mon, 19 Nov 2012 15:32:47 +0000
From: "Dijk, Esko" 
To: Michael Richardson 
Thread-Topic: [Roll] [roll] #105: trickle-mcast: how to determine scope of MPL domain
Thread-Index: AQHNwkOFtl9ztYUSrkiATuslfJmcUZfpG0MQgAVVjYCAAmIfMIAAeegAgAADkUA=
Date: Mon, 19 Nov 2012 15:32:46 +0000
Message-ID: <031DD135F9160444ABBE3B0C36CED618B20638@011-DB3MPN2-083.MGDPHG.emi.philips.com>
References: <058.e817419e990e1afb26be9aa25d5cfc21@trac.tools.ietf.org>  <50932647.3050509@exegin.com>  <5094202F.4010805@exegin.com>  <509C03C2.50809@exegin.com>  <509C5F00.2050204@exegin.com> <109e9168af966b0ee543f13886fef7ef@xs4all.nl> <8796.1352758060@sandelman.ca> <895d55da5f389dc29760cd52aaf91d61@xs4all.nl> <031DD135F9160444ABBE3B0C36CED618B0C67D@011-DB3MPN2-082.MGDPHG.emi.philips.com> <6733.1353180917@obiwan.sandelman.ca> <031DD135F9160444ABBE3B0C36CED618B1D844@011-DB3MPN2-083.MGDPHG.emi.philips.com> <21170.1353338118@obiwan.sandelman.ca>
In-Reply-To: <21170.1353338118@obiwan.sandelman.ca>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [194.171.252.103]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: philips.com
Cc: "roll@ietf.org" 
Subject: Re: [Roll] [roll] #105: trickle-mcast: how to determine scope of MPL domain
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Routing Over Low power and Lossy networks 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 19 Nov 2012 15:33:06 -0000

> but, it's not at all clear to me that this is a real use case!
> Is the PAN-ID relevant?  is there one 6LBR or 6 of them?

As Peter remarked earlier, the case with one 6LBR is more realistic than th=
e case with 6 6LBRs for cost reasons. For the case of a single 6LoWPAN (one=
 6LBR), the PAN-ID discussion is not relevant as there's just one big LoWPA=
N.

Esko

-----Original Message-----
From: mcr@obiwan.sandelman.ca [mailto:mcr@obiwan.sandelman.ca] On Behalf Of=
 Michael Richardson
Sent: Monday 19 November 2012 16:15
To: Dijk, Esko
Cc: consultancy@vanderstok.org; roll@ietf.org
Subject: Re: [Roll] [roll] #105: trickle-mcast: how to determine scope of M=
PL domain

<#part sign=3Dpgpmime>

>>>>> "Dijk" =3D=3D Dijk, Esko  writes:
    >> Yes, this is my belief as well.  so I still do not think that we
    >> have a clear use case/description of what/how a less-than-subnet
    >> MPL domain would be defined/used.

    Dijk> A clear use case seems to be Peter's office topology where all
    Dijk> nodes are connected as a single LoWPAN with one 6LBR. **Each
    Dijk> office/room can be configured as an MPL domain** The event

but, it's not at all clear to me that this is a real use case!
Is the PAN-ID relevant?  is there one 6LBR or 6 of them?

--
Michael Richardson , Sandelman Software Works
IETF ROLL WG co-chair.    http://datatracker.ietf.org/wg/roll/charter/


________________________________
The information contained in this message may be confidential and legally p=
rotected under applicable law. The message is intended solely for the addre=
ssee(s). If you are not the intended recipient, you are hereby notified tha=
t any use, forwarding, dissemination, or reproduction of this message is st=
rictly prohibited and may be unlawful. If you are not the intended recipien=
t, please contact the sender by return e-mail and destroy all copies of the=
 original message.


From robert.cragie@gridmerge.com  Tue Nov 20 14:57:56 2012
Return-Path: 
X-Original-To: roll@ietfa.amsl.com
Delivered-To: roll@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C8F821F8787 for ; Tue, 20 Nov 2012 14:57:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iR2FXtuc8p93 for ; Tue, 20 Nov 2012 14:57:55 -0800 (PST)
Received: from mail41.extendcp.co.uk (mail41.extendcp.co.uk [79.170.44.41]) by ietfa.amsl.com (Postfix) with ESMTP id 7604D21F86E5 for ; Tue, 20 Nov 2012 14:57:55 -0800 (PST)
Received: from client-86-9-227-213.oxfd-bam-1.adsl.virginmedia.com ([86.9.227.213] helo=[192.168.0.2]) by mail41.extendcp.com with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.77) id 1TawlJ-00061U-92; Tue, 20 Nov 2012 22:57:49 +0000
Message-ID: <50AC0B4F.8020705@gridmerge.com>
Date: Tue, 20 Nov 2012 22:59:27 +0000
From: Robert Cragie 
Organization: Gridmerge Ltd.
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121026 Thunderbird/16.0.2
MIME-Version: 1.0
To: Michael Richardson 
References: <058.a2b4f297c2cf9334c783ff7c900bdb13@trac.tools.ietf.org> <50AA2A9A.1030000@gridmerge.com> <21594.1353433215@obiwan.sandelman.ca>
In-Reply-To: <21594.1353433215@obiwan.sandelman.ca>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms020104020607000209000905"
X-Authenticated-As: robert.cragie@gridmerge.com
Cc: roll@ietf.org
Subject: Re: [Roll] [roll] #108: trickle-mcast: should there be an explicit version field?
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: robert.cragie@gridmerge.com
List-Id: Routing Over Low power and Lossy networks 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 20 Nov 2012 22:57:56 -0000

This is a cryptographically signed message in MIME format.

--------------ms020104020607000209000905
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable


On 20/11/2012 5:40 PM, Michael Richardson wrote:
>>>>>> "Robert" =3D=3D Robert Cragie  writes=
:
>      Robert> Regarding having an explicit version field: I have thought=

>      Robert> about this more and I am happy with the text in draft 02 a=
s
>      Robert> it stands, as it leaves it free for future versions to
>      Robert> define the reserved fields in more detail providing at lea=
st
>      Robert> 1 bit is set to 1. I certainly wouldn't see the point in
>      Robert> making the whole set of reserved bits into a version numbe=
r
>      Robert> as this could limit flexibility in the future.
>
> What would an existing implementation do when it sees these reserved
> bits?
Discard the packet if any are set - that's what's specified now. So =

this can be implicitly regarded as a version number, where (rsvd =3D=3D 0=
)=20
-> version 0, (rsvd > 0) -> not version 0.
>
> Turning reserved bits into a version number after the fact is a bad
> idea... how much would change with the version number?
> This needs to be thought out beforehand.

So there are currently 5 reserved bits. How many do we want to use for a =

version number? It could be argued that one bit is enough as to some=20
extent in the next version, you are free to change the format providing=20
earlier versions discard newer versions.

So maybe:

       0                   1 2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                      |  Option Type  |  Opt Data Len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | S |M|V| rsv   |   sequence    |      seed-id (optional)       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

would be adequate where:

V =3D version number. Must be set to 0, must be received as 0.

Some may argue about backwards compatibility but this means you have to=20
ignore bits set on receipt and you are not at liberty to change the=20
header apart from filling in the reserved fields. This only works=20
acceptably if the fields aren't tightly packed and there are plenty of=20
reserved fields - not in this case.



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

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIILUDCC
BRowggQCoAMCAQICEG0Z6qcZT2ozIuYiMnqqcd4wDQYJKoZIhvcNAQEFBQAwga4xCzAJBgNV
BAYTAlVTMQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoT
FVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3Qu
Y29tMTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQg
RW1haWwwHhcNMTEwNDI4MDAwMDAwWhcNMjAwNTMwMTA0ODM4WjCBkzELMAkGA1UEBhMCR0Ix
GzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UE
ChMRQ09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENPTU9ETyBDbGllbnQgQXV0aGVudGlj
YXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC
ggEBAJKEhFtLV5jUXi+LpOFAyKNTWF9mZfEyTvefMn1V0HhMVbdClOD5J3EHxcZppLkyxPFA
GpDMJ1Zifxe1cWmu5SAb5MtjXmDKokH2auGj/7jfH0htZUOMKi4rYzh337EXrMLaggLW1DJq
1GdvIBOPXDX65VSAr9hxCh03CgJQU2yVHakQFLSZlVkSMf8JotJM3FLb3uJAAVtIaN3FSrTg
7SQfOq9xXwfjrL8UO7AlcWg99A/WF1hGFYE8aIuLgw9teiFX5jSw2zJ+40rhpVJyZCaRTqWS
D//gsWD9Gm9oUZljjRqLpcxCm5t9ImPTqaD8zp6Q30QZ9FxbNboW86eb/8ECAwEAAaOCAUsw
ggFHMB8GA1UdIwQYMBaAFImCZ33EnSZwAEu0UEh83j2uBG59MB0GA1UdDgQWBBR6E04AdFvG
eGNkJ8Ev4qBbvHnFezAOBgNVHQ8BAf8EBAMCAQYwEgYDVR0TAQH/BAgwBgEB/wIBADARBgNV
HSAECjAIMAYGBFUdIAAwWAYDVR0fBFEwTzBNoEugSYZHaHR0cDovL2NybC51c2VydHJ1c3Qu
Y29tL1VUTi1VU0VSRmlyc3QtQ2xpZW50QXV0aGVudGljYXRpb25hbmRFbWFpbC5jcmwwdAYI
KwYBBQUHAQEEaDBmMD0GCCsGAQUFBzAChjFodHRwOi8vY3J0LnVzZXJ0cnVzdC5jb20vVVRO
QWRkVHJ1c3RDbGllbnRfQ0EuY3J0MCUGCCsGAQUFBzABhhlodHRwOi8vb2NzcC51c2VydHJ1
c3QuY29tMA0GCSqGSIb3DQEBBQUAA4IBAQCF1r54V1VtM39EUv5C1QaoAQOAivsNsv1Kv/av
QUn1G1rF0q0bc24+6SZ85kyYwTAo38v7QjyhJT4KddbQPTmGZtGhm7VNm2+vKGwdr+XqdFqo
2rHA8XV6L566k3nK/uKRHlZ0sviN0+BDchvtj/1gOSBH+4uvOmVIPJg9pSW/ve9g4EnlFsjr
P0OD8ODuDcHTzTNfm9C9YGqzO/761Mk6PB/tm/+bSTO+Qik5g+4zaS6CnUVNqGnagBsePdIa
XXxHmaWbCG0SmYbWXVcHG6cwvktJRLiQfsrReTjrtDP6oDpdJlieYVUYtCHVmdXgQ0BCML7q
peeU0rD+83X5f27nMIIGLjCCBRagAwIBAgIQXDFQ28QtqMuYch5f2nTvZjANBgkqhkiG9w0B
AQUFADCBkzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4G
A1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENP
TU9ETyBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTAeFw0xMTA5
MDIwMDAwMDBaFw0xNDA5MDEyMzU5NTlaMIIBNzELMAkGA1UEBhMCR0IxEDAOBgNVBBETB1dG
NCA0V0ExFzAVBgNVBAgTDldlc3QgWW9ya3NoaXJlMRIwEAYDVQQHEwlXYWtlZmllbGQxFDAS
BgNVBAkTC0dyYW5nZSBNb29yMR8wHQYDVQQJExY4OSBHcmVlbmZpZWxkIENyZXNjZW50MRcw
FQYDVQQKEw5HcmlkbWVyZ2UgTHRkLjE0MDIGA1UECxMrSXNzdWVkIHRocm91Z2ggR3JpZG1l
cmdlIEx0ZC4gRS1QS0kgTWFuYWdlcjEfMB0GA1UECxMWQ29ycG9yYXRlIFNlY3VyZSBFbWFp
bDEWMBQGA1UEAxMNUm9iZXJ0IENyYWdpZTEqMCgGCSqGSIb3DQEJARYbcm9iZXJ0LmNyYWdp
ZUBncmlkbWVyZ2UuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEArcThqvLe
WU1Q1ZJmnb+2UQSwOQKWok3A1Mwk582AdvwaAQyBFliPyJ0kXJqtwNBoZvk+3WJr0QA5ZRr+
J0x3sXVpcxadojP2HNzy1gsgDtIGG8ltoU4vmX1A8BTlOIUT+Pg8p/bSruxV0vz0CR8ho2hs
R0Zi5vU+rQKNmbgufbkWhlQnMEYjknemscLQfw1YZz90ta67doNDujFy6+X6I06HpjudgMYx
8bdsNS5xVFFwuBA1eqNQra+xLzhCOeX9PPB/zK68qdNhrni3WPYG9EhSt4Dzk+xIz9hj7wrU
ZIVXDTPsY8qbUSBVpwmzI5lCHPgzurH1OK7WwgpDSsl5pwIDAQABo4IB1TCCAdEwHwYDVR0j
BBgwFoAUehNOAHRbxnhjZCfBL+KgW7x5xXswHQYDVR0OBBYEFBCOXNH+lDm8U9gy3b3bRvrx
vKgrMA4GA1UdDwEB/wQEAwIFoDAMBgNVHRMBAf8EAjAAMB0GA1UdJQQWMBQGCCsGAQUFBwME
BggrBgEFBQcDAjBGBgNVHSAEPzA9MDsGDCsGAQQBsjEBAgEDBTArMCkGCCsGAQUFBwIBFh1o
dHRwczovL3NlY3VyZS5jb21vZG8ubmV0L0NQUzBXBgNVHR8EUDBOMEygSqBIhkZodHRwOi8v
Y3JsLmNvbW9kb2NhLmNvbS9DT01PRE9DbGllbnRBdXRoZW50aWNhdGlvbmFuZFNlY3VyZUVt
YWlsQ0EuY3JsMIGIBggrBgEFBQcBAQR8MHowUgYIKwYBBQUHMAKGRmh0dHA6Ly9jcnQuY29t
b2RvY2EuY29tL0NPTU9ET0NsaWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5j
cnQwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmNvbW9kb2NhLmNvbTAmBgNVHREEHzAdgRty
b2JlcnQuY3JhZ2llQGdyaWRtZXJnZS5jb20wDQYJKoZIhvcNAQEFBQADggEBAD6b/O0LkPav
kR4Znoqxg0Ad7M3duDm4uzfrlX4ecgq56Ccdwd+3Tayz7Ewej30woVMmTKkA/NKRaCd0wVM9
8seF/oZjXKO7o1SH27igRnGSWjCoWXsdwJGfZbYnvcIIhhsxJoCPNbeSR7C0PAFDKsP3xrJy
MHMljIJsoRbZu/fnYNyFWh9OXf7fYJOGmKDKAhSabUGfhY7umvU9d/YTqo02Q6YzC7d4zPNG
1a75AuHSEchf6GdKqycG38I5y9jlDaYfXspoS3PlTNCIeZONbOSMZgftnNEVKq+SWytFqyG/
8+dwpm/a12KMex5J8iHwaUKj++2O2rAFNjDDqXpeEYoxggQZMIIEFQIBATCBqDCBkzELMAkG
A1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9y
ZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENPTU9ETyBDbGllbnQg
QXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIQXDFQ28QtqMuYch5f2nTvZjAJ
BgUrDgMCGgUAoIICRTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP
Fw0xMjExMjAyMjU5MjdaMCMGCSqGSIb3DQEJBDEWBBTTgPVzEGyvmuaf/QRWYg3C9zqvTTBs
BgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcw
DgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEo
MIG5BgkrBgEEAYI3EAQxgaswgagwgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVy
IE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1p
dGVkMTkwNwYDVQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUg
RW1haWwgQ0ECEFwxUNvELajLmHIeX9p072YwgbsGCyqGSIb3DQEJEAILMYGroIGoMIGTMQsw
CQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxm
b3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVu
dCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhBcMVDbxC2oy5hyHl/adO9m
MA0GCSqGSIb3DQEBAQUABIIBACgRaL3a5IocODZYTISVvC7jnw7psjZ3mHoFewv7LycZozSK
rKYwxlgKJSPGGs+RKg2fbC0cLK0vHO67ODB6L5Js79O6Vw4tpmKxyYK7Ia/L2csuzjCOZBx8
hJS58UE90s+2Z4M4pxz6BBmTz0DFDjkSExa8c7ygiJeHbv8g93bZcpAI0ApYqD5laIlOunyc
y/vxz8Y/7OJy5a9M+jX0Y1Xn66lZfV4i/CA6Xxu7KlBk5P85sxH2akAwiNhRuOYS1L0UrRA3
3F1+J76hD+GGwEoIGGJfBhWWvSzu1s+OP+SqgP6xWtBgsB3Evdpk1dFkiiG2AwCSmKiBkBSF
dkqwJeIAAAAAAAA=
--------------ms020104020607000209000905--

From robert.cragie@gridmerge.com  Wed Nov 21 10:07:53 2012
Return-Path: 
X-Original-To: roll@ietfa.amsl.com
Delivered-To: roll@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D79021F861E for ; Wed, 21 Nov 2012 10:07:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.35
X-Spam-Level: 
X-Spam-Status: No, score=-2.35 tagged_above=-999 required=5 tests=[AWL=0.249,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3JuQ8iGuPFS8 for ; Wed, 21 Nov 2012 10:07:52 -0800 (PST)
Received: from mail41.extendcp.co.uk (mail41.extendcp.co.uk [79.170.44.41]) by ietfa.amsl.com (Postfix) with ESMTP id C22A221F85B8 for ; Wed, 21 Nov 2012 10:07:51 -0800 (PST)
Received: from client-86-29-108-132.glfd.adsl.virginmedia.com ([86.29.108.132] helo=[192.168.0.2]) by mail41.extendcp.com with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.77) id 1TbEi2-0004Kf-Le for roll@ietf.org; Wed, 21 Nov 2012 18:07:38 +0000
Message-ID: <50AD18CC.90907@gridmerge.com>
Date: Wed, 21 Nov 2012 18:09:16 +0000
From: Robert Cragie 
Organization: Gridmerge Ltd.
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0
MIME-Version: 1.0
To: Roll WG 
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms070702060401040209000503"
X-Authenticated-As: robert.cragie@gridmerge.com
Subject: [Roll] 'S' field in MPL Options
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: robert.cragie@gridmerge.com
List-Id: Routing Over Low power and Lossy networks 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 21 Nov 2012 18:07:53 -0000

This is a cryptographically signed message in MIME format.

--------------ms070702060401040209000503
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable

Referring to http://tools.ietf.org/html/draft-ietf-roll-trickle-mcast-02 =

section 4.1 - maybe I'm missing something but why is the 'S' field=20
needed? Given that the text for Opt Data Len is wrong (it should say=20
"Length of the Option Data field in octets.  MUST be set to 2, 4, 10 or=20
18"), surely Opt Data Len is sufficient for working out which Seed IDs=20
are in there?

Robert


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

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIILUDCC
BRowggQCoAMCAQICEG0Z6qcZT2ozIuYiMnqqcd4wDQYJKoZIhvcNAQEFBQAwga4xCzAJBgNV
BAYTAlVTMQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoT
FVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3Qu
Y29tMTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQg
RW1haWwwHhcNMTEwNDI4MDAwMDAwWhcNMjAwNTMwMTA0ODM4WjCBkzELMAkGA1UEBhMCR0Ix
GzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UE
ChMRQ09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENPTU9ETyBDbGllbnQgQXV0aGVudGlj
YXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC
ggEBAJKEhFtLV5jUXi+LpOFAyKNTWF9mZfEyTvefMn1V0HhMVbdClOD5J3EHxcZppLkyxPFA
GpDMJ1Zifxe1cWmu5SAb5MtjXmDKokH2auGj/7jfH0htZUOMKi4rYzh337EXrMLaggLW1DJq
1GdvIBOPXDX65VSAr9hxCh03CgJQU2yVHakQFLSZlVkSMf8JotJM3FLb3uJAAVtIaN3FSrTg
7SQfOq9xXwfjrL8UO7AlcWg99A/WF1hGFYE8aIuLgw9teiFX5jSw2zJ+40rhpVJyZCaRTqWS
D//gsWD9Gm9oUZljjRqLpcxCm5t9ImPTqaD8zp6Q30QZ9FxbNboW86eb/8ECAwEAAaOCAUsw
ggFHMB8GA1UdIwQYMBaAFImCZ33EnSZwAEu0UEh83j2uBG59MB0GA1UdDgQWBBR6E04AdFvG
eGNkJ8Ev4qBbvHnFezAOBgNVHQ8BAf8EBAMCAQYwEgYDVR0TAQH/BAgwBgEB/wIBADARBgNV
HSAECjAIMAYGBFUdIAAwWAYDVR0fBFEwTzBNoEugSYZHaHR0cDovL2NybC51c2VydHJ1c3Qu
Y29tL1VUTi1VU0VSRmlyc3QtQ2xpZW50QXV0aGVudGljYXRpb25hbmRFbWFpbC5jcmwwdAYI
KwYBBQUHAQEEaDBmMD0GCCsGAQUFBzAChjFodHRwOi8vY3J0LnVzZXJ0cnVzdC5jb20vVVRO
QWRkVHJ1c3RDbGllbnRfQ0EuY3J0MCUGCCsGAQUFBzABhhlodHRwOi8vb2NzcC51c2VydHJ1
c3QuY29tMA0GCSqGSIb3DQEBBQUAA4IBAQCF1r54V1VtM39EUv5C1QaoAQOAivsNsv1Kv/av
QUn1G1rF0q0bc24+6SZ85kyYwTAo38v7QjyhJT4KddbQPTmGZtGhm7VNm2+vKGwdr+XqdFqo
2rHA8XV6L566k3nK/uKRHlZ0sviN0+BDchvtj/1gOSBH+4uvOmVIPJg9pSW/ve9g4EnlFsjr
P0OD8ODuDcHTzTNfm9C9YGqzO/761Mk6PB/tm/+bSTO+Qik5g+4zaS6CnUVNqGnagBsePdIa
XXxHmaWbCG0SmYbWXVcHG6cwvktJRLiQfsrReTjrtDP6oDpdJlieYVUYtCHVmdXgQ0BCML7q
peeU0rD+83X5f27nMIIGLjCCBRagAwIBAgIQXDFQ28QtqMuYch5f2nTvZjANBgkqhkiG9w0B
AQUFADCBkzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4G
A1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENP
TU9ETyBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTAeFw0xMTA5
MDIwMDAwMDBaFw0xNDA5MDEyMzU5NTlaMIIBNzELMAkGA1UEBhMCR0IxEDAOBgNVBBETB1dG
NCA0V0ExFzAVBgNVBAgTDldlc3QgWW9ya3NoaXJlMRIwEAYDVQQHEwlXYWtlZmllbGQxFDAS
BgNVBAkTC0dyYW5nZSBNb29yMR8wHQYDVQQJExY4OSBHcmVlbmZpZWxkIENyZXNjZW50MRcw
FQYDVQQKEw5HcmlkbWVyZ2UgTHRkLjE0MDIGA1UECxMrSXNzdWVkIHRocm91Z2ggR3JpZG1l
cmdlIEx0ZC4gRS1QS0kgTWFuYWdlcjEfMB0GA1UECxMWQ29ycG9yYXRlIFNlY3VyZSBFbWFp
bDEWMBQGA1UEAxMNUm9iZXJ0IENyYWdpZTEqMCgGCSqGSIb3DQEJARYbcm9iZXJ0LmNyYWdp
ZUBncmlkbWVyZ2UuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEArcThqvLe
WU1Q1ZJmnb+2UQSwOQKWok3A1Mwk582AdvwaAQyBFliPyJ0kXJqtwNBoZvk+3WJr0QA5ZRr+
J0x3sXVpcxadojP2HNzy1gsgDtIGG8ltoU4vmX1A8BTlOIUT+Pg8p/bSruxV0vz0CR8ho2hs
R0Zi5vU+rQKNmbgufbkWhlQnMEYjknemscLQfw1YZz90ta67doNDujFy6+X6I06HpjudgMYx
8bdsNS5xVFFwuBA1eqNQra+xLzhCOeX9PPB/zK68qdNhrni3WPYG9EhSt4Dzk+xIz9hj7wrU
ZIVXDTPsY8qbUSBVpwmzI5lCHPgzurH1OK7WwgpDSsl5pwIDAQABo4IB1TCCAdEwHwYDVR0j
BBgwFoAUehNOAHRbxnhjZCfBL+KgW7x5xXswHQYDVR0OBBYEFBCOXNH+lDm8U9gy3b3bRvrx
vKgrMA4GA1UdDwEB/wQEAwIFoDAMBgNVHRMBAf8EAjAAMB0GA1UdJQQWMBQGCCsGAQUFBwME
BggrBgEFBQcDAjBGBgNVHSAEPzA9MDsGDCsGAQQBsjEBAgEDBTArMCkGCCsGAQUFBwIBFh1o
dHRwczovL3NlY3VyZS5jb21vZG8ubmV0L0NQUzBXBgNVHR8EUDBOMEygSqBIhkZodHRwOi8v
Y3JsLmNvbW9kb2NhLmNvbS9DT01PRE9DbGllbnRBdXRoZW50aWNhdGlvbmFuZFNlY3VyZUVt
YWlsQ0EuY3JsMIGIBggrBgEFBQcBAQR8MHowUgYIKwYBBQUHMAKGRmh0dHA6Ly9jcnQuY29t
b2RvY2EuY29tL0NPTU9ET0NsaWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5j
cnQwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmNvbW9kb2NhLmNvbTAmBgNVHREEHzAdgRty
b2JlcnQuY3JhZ2llQGdyaWRtZXJnZS5jb20wDQYJKoZIhvcNAQEFBQADggEBAD6b/O0LkPav
kR4Znoqxg0Ad7M3duDm4uzfrlX4ecgq56Ccdwd+3Tayz7Ewej30woVMmTKkA/NKRaCd0wVM9
8seF/oZjXKO7o1SH27igRnGSWjCoWXsdwJGfZbYnvcIIhhsxJoCPNbeSR7C0PAFDKsP3xrJy
MHMljIJsoRbZu/fnYNyFWh9OXf7fYJOGmKDKAhSabUGfhY7umvU9d/YTqo02Q6YzC7d4zPNG
1a75AuHSEchf6GdKqycG38I5y9jlDaYfXspoS3PlTNCIeZONbOSMZgftnNEVKq+SWytFqyG/
8+dwpm/a12KMex5J8iHwaUKj++2O2rAFNjDDqXpeEYoxggQZMIIEFQIBATCBqDCBkzELMAkG
A1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9y
ZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENPTU9ETyBDbGllbnQg
QXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIQXDFQ28QtqMuYch5f2nTvZjAJ
BgUrDgMCGgUAoIICRTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP
Fw0xMjExMjExODA5MTZaMCMGCSqGSIb3DQEJBDEWBBQdCmEkNDaZYw6mAB493lYWIdFTADBs
BgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcw
DgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEo
MIG5BgkrBgEEAYI3EAQxgaswgagwgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVy
IE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1p
dGVkMTkwNwYDVQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUg
RW1haWwgQ0ECEFwxUNvELajLmHIeX9p072YwgbsGCyqGSIb3DQEJEAILMYGroIGoMIGTMQsw
CQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxm
b3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVu
dCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhBcMVDbxC2oy5hyHl/adO9m
MA0GCSqGSIb3DQEBAQUABIIBABWcJMbNLjO3dbkpbbJYijMpkWXyxFG0r2P+uAUJ+Jox0usX
9sB3XnVfkElygWqn3IFjxTl8ipInBYhkUoPCqVtl1/v+K/MJDGn0uCaPvEjYEmRTIvTr3gaa
eburafF+dpc4k3krRbUUD3MYxs4EuSLtisOWNI3HE0LB5caeue1Sud2LPBGY2N1nlW8h2szd
Dxjfm0sgntLBvhOAVCsY8UjSyCBw2sO+Rod85tIBfmDVuWTsatoyE5Y6appoCmOJ2yefM88v
5MwwPOimmTToKGFOtgy2XHWK3QmvDDuOAHsoHpy8YQ1TXkM0AHTcBj4Ar0za9h1jUmotGYRU
fvt6Ub8AAAAAAAA=
--------------ms070702060401040209000503--

From dat@exegin.com  Wed Nov 21 17:01:09 2012
Return-Path: 
X-Original-To: roll@ietfa.amsl.com
Delivered-To: roll@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4E5C21F8456 for ; Wed, 21 Nov 2012 17:01:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.377
X-Spam-Level: 
X-Spam-Status: No, score=-3.377 tagged_above=-999 required=5 tests=[AWL=0.221,  BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 85K4j4NvugQc for ; Wed, 21 Nov 2012 17:01:09 -0800 (PST)
Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 55C5321F8452 for ; Wed, 21 Nov 2012 17:01:09 -0800 (PST)
Received: by mail-pb0-f44.google.com with SMTP id uo1so5422642pbc.31 for ; Wed, 21 Nov 2012 17:01:09 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:x-gm-message-state; bh=SWOn+CTPUqTo0Lrpqc24NJFQOGFwgmB68TKvmovu6Sk=; b=U0SMKXNAtzS7YMolKqsVeSXjcFJBL03hOcRY7ULeRugbXMq1XBfavuCP9BgrMZ6WVH +w1B2b72pgY3q2pcWPIhncuBRP52BfnTYXWBEOPT0mDwv+7Pjkbrlyw+ybMVz7YRs35y JD5CJtgxWXz1JTuY1eo1+XjxD+ikx0BleGRAo4bdpjYKc98cPdVCA/il9LPWBwn1TH26 flPWGisL2/UWCvNBzJ55Pex4Zx/JWPV3Cq6bW8kWwW9/PV2zlx1UllL76bd0uchE08jQ 6YTWG5QzxAWGUZnNP6tLSFdTro/WfREIb27uMw83bt/mt+XnZy4Mr2uoS83Nyi3dDBAc 63vw==
Received: by 10.68.248.70 with SMTP id yk6mr4310377pbc.160.1353546069139; Wed, 21 Nov 2012 17:01:09 -0800 (PST)
Received: from [172.16.1.52] ([184.71.143.130]) by mx.google.com with ESMTPS id c7sm886724pay.10.2012.11.21.17.01.06 (version=SSLv3 cipher=OTHER); Wed, 21 Nov 2012 17:01:07 -0800 (PST)
Message-ID: <50AD7947.8050303@exegin.com>
Date: Wed, 21 Nov 2012 17:00:55 -0800
From: Dario Tedeschi 
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:7.0) Gecko/20110922 Thunderbird/7.0
MIME-Version: 1.0
To: robert.cragie@gridmerge.com
References: <50AD18CC.90907@gridmerge.com>
In-Reply-To: <50AD18CC.90907@gridmerge.com>
Content-Type: multipart/alternative; boundary="------------090605030300040301030808"
X-Gm-Message-State: ALoCoQlY7+V+m3QDDZ0uzT/N8Eig1oYRu0cc4I7haGqf8q7142ybJp98+AXEF3X6g/cZTsl5HIyk
Cc: Roll WG 
Subject: Re: [Roll] 'S' field in MPL Options
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Routing Over Low power and Lossy networks 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 22 Nov 2012 01:01:09 -0000

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

I agree

The 'S' field seems redundant, because an implementation would still 
need to read the Length field so it can make sure the 'S' field wasn't 
lying.

- Dario

On 21/11/2012 10:09 AM, Robert Cragie wrote:
> Referring to 
> http://tools.ietf.org/html/draft-ietf-roll-trickle-mcast-02 section 
> 4.1 - maybe I'm missing something but why is the 'S' field needed? 
> Given that the text for Opt Data Len is wrong (it should say "Length 
> of the Option Data field in octets.  MUST be set to 2, 4, 10 or 18"), 
> surely Opt Data Len is sufficient for working out which Seed IDs are 
> in there?
>
> Robert
>
>
>
> _______________________________________________
> Roll mailing list
> Roll@ietf.org
> https://www.ietf.org/mailman/listinfo/roll


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


  
    
  
  
    I agree

    

    The 'S' field seems redundant, because an implementation would still
    need to read the Length field so it can make sure the 'S' field
    wasn't lying.

    

    - Dario

    

    On 21/11/2012 10:09 AM, Robert Cragie wrote:
    
Referring
      to http://tools.ietf.org/html/draft-ietf-roll-trickle-mcast-02
      section 4.1 - maybe I'm missing something but why is the 'S' field
      needed? Given that the text for Opt Data Len is wrong (it should
      say "Length of the Option Data field in octets.  MUST be set to 2,
      4, 10 or 18"), surely Opt Data Len is sufficient for working out
      which Seed IDs are in there?
      

      

      Robert
      

      

      

      

      

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


    

    

  


--------------090605030300040301030808--

From johui@cisco.com  Wed Nov 21 17:06:18 2012
Return-Path: 
X-Original-To: roll@ietfa.amsl.com
Delivered-To: roll@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2ED3921E8044 for ; Wed, 21 Nov 2012 17:06:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.598
X-Spam-Level: 
X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kgm6gA9McJL7 for ; Wed, 21 Nov 2012 17:06:17 -0800 (PST)
Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 7C5EA21E8034 for ; Wed, 21 Nov 2012 17:06:17 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4308; q=dns/txt; s=iport; t=1353546377; x=1354755977; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=2NxmFh6RWfJH7DtvG2HI4iEFXXh80pzemEO0s2PZ6dE=; b=djzrqTrv8Wu14cRwqYGYQ52Wo5GbSahRzliWUoFYZ5PBxMamA3EZ+k/N 4HNezthrsBm0BLfvnjNXzn3mNtSSWPL33IHJ+D7wKw+cVt7n8QpZENbRP PPGyJDkigFTBdq2AB8kPpR7XyREysw81GRWRKn5ruQ5d7YwaYt+WM11r/ s=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av8EADV5rVCtJV2d/2dsb2JhbABEwhgWc4IfAQEEAQEBawsQAgEIBAoUHQcnCxQRAgQOBQiIBQu/N4w0hAJhA4gnjnOPJYJvghk
X-IronPort-AV: E=McAfee;i="5400,1158,6903"; a="145034668"
Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-6.cisco.com with ESMTP; 22 Nov 2012 01:06:17 +0000
Received: from xhc-rcd-x06.cisco.com (xhc-rcd-x06.cisco.com [173.37.183.80]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id qAM16G2o007460 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 22 Nov 2012 01:06:16 GMT
Received: from xmb-rcd-x04.cisco.com ([169.254.8.108]) by xhc-rcd-x06.cisco.com ([173.37.183.80]) with mapi id 14.02.0318.001; Wed, 21 Nov 2012 19:06:16 -0600
From: "Jonathan Hui (johui)" 
To: Dario Tedeschi 
Thread-Topic: [Roll] 'S' field in MPL Options
Thread-Index: AQHNyE2SRfkeZRROFE+IAT0ZGkHBPQ==
Date: Thu, 22 Nov 2012 01:06:15 +0000
Message-ID: 
References: <50AD18CC.90907@gridmerge.com> <50AD7947.8050303@exegin.com>
In-Reply-To: <50AD7947.8050303@exegin.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.21.74.19]
Content-Type: multipart/alternative; boundary="_000_B50D0F163D52B74DA572DD345D5044AF0F779FCFxmbrcdx04ciscoc_"
MIME-Version: 1.0
Cc: Roll WG 
Subject: Re: [Roll] 'S' field in MPL Options
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Routing Over Low power and Lossy networks 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 22 Nov 2012 01:06:18 -0000

--_000_B50D0F163D52B74DA572DD345D5044AF0F779FCFxmbrcdx04ciscoc_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable


The question is whether we want to allow sub-TLVs in the MPL Option.  A fut=
ure specification could introduce sub-TLVs, but that would not be backwards=
 compatible if we did not have an explicit length for the seed-id.  Given t=
he small namespace for IPv6 Options, we might want to consider having a way=
 of including additional fields that is backwards compatible.

--
Jonathan Hui

On Nov 21, 2012, at 5:00 PM, Dario Tedeschi > wrote:

I agree

The 'S' field seems redundant, because an implementation would still need t=
o read the Length field so it can make sure the 'S' field wasn't lying.

- Dario

On 21/11/2012 10:09 AM, Robert Cragie wrote:
Referring to http://tools.ietf.org/html/draft-ietf-roll-trickle-mcast-02 se=
ction 4.1 - maybe I'm missing something but why is the 'S' field needed? Gi=
ven that the text for Opt Data Len is wrong (it should say "Length of the O=
ption Data field in octets.  MUST be set to 2, 4, 10 or 18"), surely Opt Da=
ta Len is sufficient for working out which Seed IDs are in there?

Robert




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


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


--_000_B50D0F163D52B74DA572DD345D5044AF0F779FCFxmbrcdx04ciscoc_
Content-Type: text/html; charset="iso-8859-1"
Content-ID: 
Content-Transfer-Encoding: quoted-printable












The question is whether we want to allow sub-TLVs in the MPL Option. &=
nbsp;A future specification could introduce sub-TLVs, but that would not be=
 backwards compatible if we did not have an explicit length for the seed-id=
.  Given the small namespace for IPv6
 Options, we might want to consider having a way of including additional fi=
elds that is backwards compatible.







--


Jonathan Hui






On Nov 21, 2012, at 5:00 PM, Dario Tedeschi <dat@exegin.com> wrote:






I agree



The 'S' field seems redundant, because an implementation would still need t=
o read the Length field so it can make sure the 'S' field wasn't lying.



- Dario



On 21/11/2012 10:09 AM, Robert Cragie wrote:

Referri=
ng to 
http://tools.ietf.org/html/draft-ietf-roll-trickle-mcast-02 section 4.1=
 - maybe I'm missing something but why is the 'S' field needed? Given that =
the text for Opt Data Len is wrong (it should say "Length of the Optio=
n Data field in octets.  MUST be set
 to 2, 4, 10 or 18"), surely Opt Data Len is sufficient for working ou=
t which Seed IDs are in there?




Robert 






 


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








_______________________________________________

Roll mailing list

Roll@ietf.org

https://www.ietf.org/mailman/listinfo/roll










--_000_B50D0F163D52B74DA572DD345D5044AF0F779FCFxmbrcdx04ciscoc_--

From robert.cragie@gridmerge.com  Thu Nov 22 02:04:10 2012
Return-Path: 
X-Original-To: roll@ietfa.amsl.com
Delivered-To: roll@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F6FC21F88D5 for ; Thu, 22 Nov 2012 02:04:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level: 
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Men8eLOuJfDu for ; Thu, 22 Nov 2012 02:04:09 -0800 (PST)
Received: from mail41.extendcp.co.uk (mail41.extendcp.co.uk [79.170.44.41]) by ietfa.amsl.com (Postfix) with ESMTP id C6D4D21F88D1 for ; Thu, 22 Nov 2012 02:04:08 -0800 (PST)
Received: from client-82-26-195-127.pete.adsl.virginmedia.com ([82.26.195.127] helo=[192.168.0.2]) by mail41.extendcp.com with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.77) id 1TbTdd-0003vn-Ap; Thu, 22 Nov 2012 10:04:05 +0000
Message-ID: <50ADF8F6.5000405@gridmerge.com>
Date: Thu, 22 Nov 2012 10:05:42 +0000
From: Robert Cragie 
Organization: Gridmerge Ltd.
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0
MIME-Version: 1.0
To: "Jonathan Hui (johui)" 
References: <50AD18CC.90907@gridmerge.com> <50AD7947.8050303@exegin.com> 
In-Reply-To: 
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms070402070605000105010900"
X-Authenticated-As: robert.cragie@gridmerge.com
Cc: Roll WG 
Subject: Re: [Roll] 'S' field in MPL Options
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: robert.cragie@gridmerge.com
List-Id: Routing Over Low power and Lossy networks 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 22 Nov 2012 10:04:10 -0000

This is a cryptographically signed message in MIME format.

--------------ms070402070605000105010900
Content-Type: multipart/alternative;
 boundary="------------060406010109040602020207"

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

OK, so we're onto the subject of backwards compatibility. So we have two =

choices here (not mutually exclusive):

 1. Always maintain backwards compatibility
 2. Allow future revisions to change the format

(1) is desirable of course but means more restrictions in how the format =

can be changed. (2) gives flexibility but breaks backwards compatibility.=


 1. If we are ever going to consider (2) we need some sort of version
    numbering (implicit or explicit) and an ability to discard the
    packet if the header is not understood. We sort of have that now
    with the 'rsv' field as mentioned in previous posts but it might be
    better to specify at least one bit as a version field to ensure a
    "version > 0" option format sets that bit to ensure "version =3D=3D 0=
"
    implementations discard it (better to discard than erroneously proces=
s).
 2. If we always want to maintain backwards compatibility from now on,
    we don't strictly need a version number providing the rules are
    clear in "version =3D=3D 0" and the format allows extension of the
    option. In this case,  we would need to:
     1. Keep the 'S' field
     2. State that future revisions MUST only extend using sub-TLVs and
        cannot fundamentally change the format of the option (see point 2=
=2E4)
     3. State that any unknown extension of the option MUST be skipped ov=
er
     4. Suggest changing the rules for 'rsv' to be set to 0 and ignored
        on receipt. This would allow future revisions to use these bits
        and remain backwards compatible

On point 2.4, we could still have a version number/bit in the 'rsv'=20
field meaning that future revisions have a choice. I can't think why a=20
future revision would deliberately break backward compatibility - the=20
only possible one would be compact encoding (TLVs are not that efficient)=
=2E

Robert


On 22/11/2012 1:06 AM, Jonathan Hui (johui) wrote:
>
> The question is whether we want to allow sub-TLVs in the MPL Option.=20
>  A future specification could introduce sub-TLVs, but that would not=20
> be backwards compatible if we did not have an explicit length for the=20
> seed-id.  Given the small namespace for IPv6 Options, we might want to =

> consider having a way of including additional fields that is backwards =

> compatible.
>
> --
> Jonathan Hui
>
> On Nov 21, 2012, at 5:00 PM, Dario Tedeschi  > wrote:
>
>> I agree
>>
>> The 'S' field seems redundant, because an implementation would still=20
>> need to read the Length field so it can make sure the 'S' field=20
>> wasn't lying.
>>
>> - Dario
>>
>> On 21/11/2012 10:09 AM, Robert Cragie wrote:
>>> Referring to=20
>>> http://tools.ietf.org/html/draft-ietf-roll-trickle-mcast-02 section=20
>>> 4.1 - maybe I'm missing something but why is the 'S' field needed?=20
>>> Given that the text for Opt Data Len is wrong (it should say "Length =

>>> of the Option Data field in octets. MUST be set to 2, 4, 10 or 18"), =

>>> surely Opt Data Len is sufficient for working out which Seed IDs are =

>>> in there?
>>>
>>> Robert
>>>
>>>
>>>
>>> _______________________________________________
>>> Roll mailing list
>>> Roll@ietf.org
>>> https://www.ietf.org/mailman/listinfo/roll
>>
>> _______________________________________________
>> Roll mailing list
>> Roll@ietf.org 
>> https://www.ietf.org/mailman/listinfo/roll
>


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


  
    
  
  
    OK, so we're onto the subject of backwards compatibility. So we have
    two choices here (not mutually exclusive):

    

    
    
      
  1. Always maintain backwards compatibility
    2. 
      
  2. Allow future revisions to change the format
    3. 
    

    (1) is desirable of course but means more restrictions in how the
    format can be changed. (2) gives flexibility but breaks backwards
    compatibility.

    

    
    
      
  1. If we are ever going to consider (2) we need some sort of
        version numbering (implicit or explicit) and an ability to
        discard the packet if the header is not understood. We sort of
        have that now with the 'rsv' field as mentioned in previous
        posts but it might be better to specify at least one bit as a
        version field to ensure a "version > 0" option format sets
        that bit to ensure "version =3D=3D 0" implementations discard it
        (better to discard than erroneously process).
    2. 
      
  2. If we always want to maintain backwards compatibility from now
        on, we don't strictly need a version number providing the rules
        are clear in "version =3D=3D 0" and the format allows extension o=
f
        the option. In this case,  we would need to:
    3. 
      
      
        
    1. Keep the 'S' field
      2. 
        
    2. State that future revisions MUST only extend using sub-TLVs
          and cannot fundamentally change the format of the option (see
          point 2.4)
      
        
      3. 
        
    3. State that any unknown extension of the option MUST be
          skipped over
      4. 
        
    4. Suggest changing the rules for 'rsv' to be set to 0 and
          ignored on receipt. This would allow future revisions to use
          these bits and remain backwards compatible
      
        
      5. 
      
    
    

    On point 2.4, we could still have a version number/bit in the 'rsv'
    field meaning that future revisions have a choice. I can't think why
    a future revision would deliberately break backward compatibility -
    the only possible one would be compact encoding (TLVs are not that
    efficient).

    

    Robert

    

    

    
On 22/11/2012 1:06 AM, Jonathan Hui
      (johui) wrote:

    

    

      
      


      

      
The question is whether we want to allow sub-TLVs in the MPL
        Option.  A future specification could introduce sub-TLVs, bu=
t
        that would not be backwards compatible if we did not have an
        explicit length for the seed-id.  Given the small namespace =
for
        IPv6 Options, we might want to consider having a way of
        including additional fields that is backwards compatible.

      


      

      
--

      
Jonathan Hui

      

      

        
On Nov 21, 2012, at 5:00 PM, Dario Tedeschi <dat@e=
xegin.com>
          wrote:

        

        

          
I agree

            

            The 'S' field seems redundant, because an implementation
            would still need to read the Length field so it can make
            sure the 'S' field wasn't lying.

            

            - Dario

            

            On 21/11/2012 10:09 AM, Robert Cragie wrote:
            
Referring to 
http://tools.ietf.org/html/draft-ietf-roll-trickle-mcast-02 section
              4.1 - maybe I'm missing something but why is the 'S' field
              needed? Given that the text for Opt Data Len is wrong (it
              should say "Length of the Option Data field in octets. =
;
              MUST be set to 2, 4, 10 or 18"), surely Opt Data Len is
              sufficient for working out which Seed IDs are in there?
              

              

              Robert 

              

              

              

              

              
____________________________________________=
___
Roll mailing list
Roll@ietf.org
https://www.ietf.org/mailman/listi=
nfo/roll


            

            

          

          _______________________________________________

          Roll mailing list

          Roll@=
ietf.org

          https://www.ietf.org/mailman/listinfo/roll
        

      

      

    

    

  


--------------060406010109040602020207--

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

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIILUDCC
BRowggQCoAMCAQICEG0Z6qcZT2ozIuYiMnqqcd4wDQYJKoZIhvcNAQEFBQAwga4xCzAJBgNV
BAYTAlVTMQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoT
FVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3Qu
Y29tMTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQg
RW1haWwwHhcNMTEwNDI4MDAwMDAwWhcNMjAwNTMwMTA0ODM4WjCBkzELMAkGA1UEBhMCR0Ix
GzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UE
ChMRQ09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENPTU9ETyBDbGllbnQgQXV0aGVudGlj
YXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC
ggEBAJKEhFtLV5jUXi+LpOFAyKNTWF9mZfEyTvefMn1V0HhMVbdClOD5J3EHxcZppLkyxPFA
GpDMJ1Zifxe1cWmu5SAb5MtjXmDKokH2auGj/7jfH0htZUOMKi4rYzh337EXrMLaggLW1DJq
1GdvIBOPXDX65VSAr9hxCh03CgJQU2yVHakQFLSZlVkSMf8JotJM3FLb3uJAAVtIaN3FSrTg
7SQfOq9xXwfjrL8UO7AlcWg99A/WF1hGFYE8aIuLgw9teiFX5jSw2zJ+40rhpVJyZCaRTqWS
D//gsWD9Gm9oUZljjRqLpcxCm5t9ImPTqaD8zp6Q30QZ9FxbNboW86eb/8ECAwEAAaOCAUsw
ggFHMB8GA1UdIwQYMBaAFImCZ33EnSZwAEu0UEh83j2uBG59MB0GA1UdDgQWBBR6E04AdFvG
eGNkJ8Ev4qBbvHnFezAOBgNVHQ8BAf8EBAMCAQYwEgYDVR0TAQH/BAgwBgEB/wIBADARBgNV
HSAECjAIMAYGBFUdIAAwWAYDVR0fBFEwTzBNoEugSYZHaHR0cDovL2NybC51c2VydHJ1c3Qu
Y29tL1VUTi1VU0VSRmlyc3QtQ2xpZW50QXV0aGVudGljYXRpb25hbmRFbWFpbC5jcmwwdAYI
KwYBBQUHAQEEaDBmMD0GCCsGAQUFBzAChjFodHRwOi8vY3J0LnVzZXJ0cnVzdC5jb20vVVRO
QWRkVHJ1c3RDbGllbnRfQ0EuY3J0MCUGCCsGAQUFBzABhhlodHRwOi8vb2NzcC51c2VydHJ1
c3QuY29tMA0GCSqGSIb3DQEBBQUAA4IBAQCF1r54V1VtM39EUv5C1QaoAQOAivsNsv1Kv/av
QUn1G1rF0q0bc24+6SZ85kyYwTAo38v7QjyhJT4KddbQPTmGZtGhm7VNm2+vKGwdr+XqdFqo
2rHA8XV6L566k3nK/uKRHlZ0sviN0+BDchvtj/1gOSBH+4uvOmVIPJg9pSW/ve9g4EnlFsjr
P0OD8ODuDcHTzTNfm9C9YGqzO/761Mk6PB/tm/+bSTO+Qik5g+4zaS6CnUVNqGnagBsePdIa
XXxHmaWbCG0SmYbWXVcHG6cwvktJRLiQfsrReTjrtDP6oDpdJlieYVUYtCHVmdXgQ0BCML7q
peeU0rD+83X5f27nMIIGLjCCBRagAwIBAgIQXDFQ28QtqMuYch5f2nTvZjANBgkqhkiG9w0B
AQUFADCBkzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4G
A1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENP
TU9ETyBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTAeFw0xMTA5
MDIwMDAwMDBaFw0xNDA5MDEyMzU5NTlaMIIBNzELMAkGA1UEBhMCR0IxEDAOBgNVBBETB1dG
NCA0V0ExFzAVBgNVBAgTDldlc3QgWW9ya3NoaXJlMRIwEAYDVQQHEwlXYWtlZmllbGQxFDAS
BgNVBAkTC0dyYW5nZSBNb29yMR8wHQYDVQQJExY4OSBHcmVlbmZpZWxkIENyZXNjZW50MRcw
FQYDVQQKEw5HcmlkbWVyZ2UgTHRkLjE0MDIGA1UECxMrSXNzdWVkIHRocm91Z2ggR3JpZG1l
cmdlIEx0ZC4gRS1QS0kgTWFuYWdlcjEfMB0GA1UECxMWQ29ycG9yYXRlIFNlY3VyZSBFbWFp
bDEWMBQGA1UEAxMNUm9iZXJ0IENyYWdpZTEqMCgGCSqGSIb3DQEJARYbcm9iZXJ0LmNyYWdp
ZUBncmlkbWVyZ2UuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEArcThqvLe
WU1Q1ZJmnb+2UQSwOQKWok3A1Mwk582AdvwaAQyBFliPyJ0kXJqtwNBoZvk+3WJr0QA5ZRr+
J0x3sXVpcxadojP2HNzy1gsgDtIGG8ltoU4vmX1A8BTlOIUT+Pg8p/bSruxV0vz0CR8ho2hs
R0Zi5vU+rQKNmbgufbkWhlQnMEYjknemscLQfw1YZz90ta67doNDujFy6+X6I06HpjudgMYx
8bdsNS5xVFFwuBA1eqNQra+xLzhCOeX9PPB/zK68qdNhrni3WPYG9EhSt4Dzk+xIz9hj7wrU
ZIVXDTPsY8qbUSBVpwmzI5lCHPgzurH1OK7WwgpDSsl5pwIDAQABo4IB1TCCAdEwHwYDVR0j
BBgwFoAUehNOAHRbxnhjZCfBL+KgW7x5xXswHQYDVR0OBBYEFBCOXNH+lDm8U9gy3b3bRvrx
vKgrMA4GA1UdDwEB/wQEAwIFoDAMBgNVHRMBAf8EAjAAMB0GA1UdJQQWMBQGCCsGAQUFBwME
BggrBgEFBQcDAjBGBgNVHSAEPzA9MDsGDCsGAQQBsjEBAgEDBTArMCkGCCsGAQUFBwIBFh1o
dHRwczovL3NlY3VyZS5jb21vZG8ubmV0L0NQUzBXBgNVHR8EUDBOMEygSqBIhkZodHRwOi8v
Y3JsLmNvbW9kb2NhLmNvbS9DT01PRE9DbGllbnRBdXRoZW50aWNhdGlvbmFuZFNlY3VyZUVt
YWlsQ0EuY3JsMIGIBggrBgEFBQcBAQR8MHowUgYIKwYBBQUHMAKGRmh0dHA6Ly9jcnQuY29t
b2RvY2EuY29tL0NPTU9ET0NsaWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5j
cnQwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmNvbW9kb2NhLmNvbTAmBgNVHREEHzAdgRty
b2JlcnQuY3JhZ2llQGdyaWRtZXJnZS5jb20wDQYJKoZIhvcNAQEFBQADggEBAD6b/O0LkPav
kR4Znoqxg0Ad7M3duDm4uzfrlX4ecgq56Ccdwd+3Tayz7Ewej30woVMmTKkA/NKRaCd0wVM9
8seF/oZjXKO7o1SH27igRnGSWjCoWXsdwJGfZbYnvcIIhhsxJoCPNbeSR7C0PAFDKsP3xrJy
MHMljIJsoRbZu/fnYNyFWh9OXf7fYJOGmKDKAhSabUGfhY7umvU9d/YTqo02Q6YzC7d4zPNG
1a75AuHSEchf6GdKqycG38I5y9jlDaYfXspoS3PlTNCIeZONbOSMZgftnNEVKq+SWytFqyG/
8+dwpm/a12KMex5J8iHwaUKj++2O2rAFNjDDqXpeEYoxggQZMIIEFQIBATCBqDCBkzELMAkG
A1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9y
ZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENPTU9ETyBDbGllbnQg
QXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIQXDFQ28QtqMuYch5f2nTvZjAJ
BgUrDgMCGgUAoIICRTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP
Fw0xMjExMjIxMDA1NDJaMCMGCSqGSIb3DQEJBDEWBBTentcVAyt48lFqwmDKR6S0RdUU2TBs
BgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcw
DgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEo
MIG5BgkrBgEEAYI3EAQxgaswgagwgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVy
IE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1p
dGVkMTkwNwYDVQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUg
RW1haWwgQ0ECEFwxUNvELajLmHIeX9p072YwgbsGCyqGSIb3DQEJEAILMYGroIGoMIGTMQsw
CQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxm
b3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVu
dCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhBcMVDbxC2oy5hyHl/adO9m
MA0GCSqGSIb3DQEBAQUABIIBAJGa1PYK1QT9JTdpJgeDZcCA3gkX+K9vdZFN9bMfOQuMb1d4
ynestpCFK7RwzGZR2rLX1vFMgHETNsbtXxM+xRJkz/K45Wun6GEFL4EojoDQCrECJ4Ssc3gn
h5iiRoylh1KimrOk7UKAqY1wC+dbDyCmuwTExmU9D/qZNLHvUoC0J+6kU5u8U4dY0/y/YODd
Ko9hhUWQqSjzp41yEN2TRWhwx9E36lQjKZZmmxINB69lxmmhM9ShVWPyg0wsfwOoeTFIgP9L
Rf4zlEYsCJzC41Db8oUa2thwfH42X8/UI2nq1asW5Kg7c7SpW+K1viumC1WvswdB8IGx8NPy
7q6qzDcAAAAAAAA=
--------------ms070402070605000105010900--

From dat@exegin.com  Thu Nov 22 13:27:43 2012
Return-Path: 
X-Original-To: roll@ietfa.amsl.com
Delivered-To: roll@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DE2D21F86C3 for ; Thu, 22 Nov 2012 13:27:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.392
X-Spam-Level: 
X-Spam-Status: No, score=-3.392 tagged_above=-999 required=5 tests=[AWL=0.206,  BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7OsnwJh7G3Js for ; Thu, 22 Nov 2012 13:27:41 -0800 (PST)
Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 0C43B21F8683 for ; Thu, 22 Nov 2012 13:27:40 -0800 (PST)
Received: by mail-pb0-f44.google.com with SMTP id uo1so6040563pbc.31 for ; Thu, 22 Nov 2012 13:27:40 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:x-gm-message-state; bh=RR6R+JZ7d911nNUha0BAgTIbG6wGdTyPzNbfX6fgfZc=; b=BlirvZ4rcFAW2N09tUZgx8KMRd46teQu+Kxiw+ImpBqIiTLm7bNTxsvVPU9MSdx7+N xYaLqfg9n+3EFwjn8Jth+8xY9kKAzb0mR9Hy5JhOACTHmhlRNgOxAmpwO/gKqv4fTbOU qqyXwm8OXEiOljgQE7hhjpit8kCa0XbK2j9kCHKf4cwWR9kumaKW6ov0THS+pkdBf1/c 72NjASgius6XgnP1th9H7SBEk2M7iZCoQAGQGIKlVpb9YPFN6CcM9YPtnuvqYR41zJUa fiZwCgDh4usYIADK7PxFjIs+NjoTRVb+hYAtMIV1gEx7yt69MZ2njvJSk4UCVovxr891 1Yng==
Received: by 10.66.79.195 with SMTP id l3mr2096461pax.82.1353619660716; Thu, 22 Nov 2012 13:27:40 -0800 (PST)
Received: from [172.16.1.52] ([184.71.143.130]) by mx.google.com with ESMTPS id ok3sm2612599pbb.11.2012.11.22.13.27.38 (version=SSLv3 cipher=OTHER); Thu, 22 Nov 2012 13:27:39 -0800 (PST)
Message-ID: <50AE98BE.3000007@exegin.com>
Date: Thu, 22 Nov 2012 13:27:26 -0800
From: Dario Tedeschi 
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:7.0) Gecko/20110922 Thunderbird/7.0
MIME-Version: 1.0
To: "Jonathan Hui (johui)" 
References: <50AD18CC.90907@gridmerge.com> <50AD7947.8050303@exegin.com> 
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------010805070803090301030208"
X-Gm-Message-State: ALoCoQmAG9Pr5kvQIhO01nMGYbQ5INvwjSXao91xPobh1Y1qNvaImUQBGe0Oz4YnGs1fQWgzLFuL
Cc: Roll WG 
Subject: Re: [Roll] 'S' field in MPL Options
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Routing Over Low power and Lossy networks 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 22 Nov 2012 21:27:43 -0000

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

I have no strong opinion on the matter. Besides, I don't want to get 
stuck in an argument over 1 bit. :-)

If you think sub-TLVs could be a real use-case, I'm fine with it. 
However, I will say that I'm unaware of any hop-options that have sub-TLVs.

- Dario


On 21/11/2012 5:06 PM, Jonathan Hui (johui) wrote:
>
> The question is whether we want to allow sub-TLVs in the MPL Option. 
>  A future specification could introduce sub-TLVs, but that would not 
> be backwards compatible if we did not have an explicit length for the 
> seed-id.  Given the small namespace for IPv6 Options, we might want to 
> consider having a way of including additional fields that is backwards 
> compatible.
>
> --
> Jonathan Hui
>
> On Nov 21, 2012, at 5:00 PM, Dario Tedeschi  > wrote:
>
>> I agree
>>
>> The 'S' field seems redundant, because an implementation would still 
>> need to read the Length field so it can make sure the 'S' field 
>> wasn't lying.
>>
>> - Dario
>>
>> On 21/11/2012 10:09 AM, Robert Cragie wrote:
>>> Referring to 
>>> http://tools.ietf.org/html/draft-ietf-roll-trickle-mcast-02 section 
>>> 4.1 - maybe I'm missing something but why is the 'S' field needed? 
>>> Given that the text for Opt Data Len is wrong (it should say "Length 
>>> of the Option Data field in octets.  MUST be set to 2, 4, 10 or 
>>> 18"), surely Opt Data Len is sufficient for working out which Seed 
>>> IDs are in there?
>>>
>>> Robert
>>>
>>>
>>>
>>> _______________________________________________
>>> Roll mailing list
>>> Roll@ietf.org
>>> https://www.ietf.org/mailman/listinfo/roll
>>
>> _______________________________________________
>> Roll mailing list
>> Roll@ietf.org 
>> https://www.ietf.org/mailman/listinfo/roll
>


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


  
    
  
  
    I have no strong opinion on the matter. Besides, I don't want to get
    stuck in an argument over 1 bit. :-)

    

    If you think sub-TLVs could be a real use-case, I'm fine with it.
    However, I will say that I'm unaware of any hop-options that have
    sub-TLVs. 

    

    - Dario

    

    

    On 21/11/2012 5:06 PM, Jonathan Hui (johui) wrote:
    

      
      


      

      
The question is whether we want to allow sub-TLVs in the MPL
        Option.  A future specification could introduce sub-TLVs, but
        that would not be backwards compatible if we did not have an
        explicit length for the seed-id.  Given the small namespace for
        IPv6 Options, we might want to consider having a way of
        including additional fields that is backwards compatible.

      


      

      
--

      
Jonathan Hui

      

      

        
On Nov 21, 2012, at 5:00 PM, Dario Tedeschi <dat@exegin.com>
          wrote:

        

        

          
I agree

            

            The 'S' field seems redundant, because an implementation
            would still need to read the Length field so it can make
            sure the 'S' field wasn't lying.

            

            - Dario

            

            On 21/11/2012 10:09 AM, Robert Cragie wrote:
            
Referring to 
http://tools.ietf.org/html/draft-ietf-roll-trickle-mcast-02 section
              4.1 - maybe I'm missing something but why is the 'S' field
              needed? Given that the text for Opt Data Len is wrong (it
              should say "Length of the Option Data field in octets. 
              MUST be set to 2, 4, 10 or 18"), surely Opt Data Len is
              sufficient for working out which Seed IDs are in there?
              

              

              Robert 

              

              

              

              

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


            

            

          

          _______________________________________________

          Roll mailing list

          Roll@ietf.org

          https://www.ietf.org/mailman/listinfo/roll

        

      

      

    

    

  


--------------010805070803090301030208--

From pal@cs.stanford.edu  Wed Nov 28 13:27:22 2012
Return-Path: 
X-Original-To: roll@ietfa.amsl.com
Delivered-To: roll@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A67FA21F85C9 for ; Wed, 28 Nov 2012 13:27:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level: 
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b-oPe-844sy0 for ; Wed, 28 Nov 2012 13:27:22 -0800 (PST)
Received: from cs-smtp-1.Stanford.EDU (cs-smtp-1.Stanford.EDU [171.64.64.25]) by ietfa.amsl.com (Postfix) with ESMTP id 3082A21F86C6 for ; Wed, 28 Nov 2012 13:27:22 -0800 (PST)
Received: from 23-24-194-1-static.hfc.comcastbusiness.net ([23.24.194.1] helo=[10.111.222.25]) by cs-smtp-1.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.77) (envelope-from ) id 1TdpA8-0000Y5-RC; Wed, 28 Nov 2012 13:27:21 -0800
Mime-Version: 1.0 (Apple Message framework v1283)
Content-Type: text/plain; charset=us-ascii
From: Philip Levis 
In-Reply-To: <157212510.61589.1352318118568.JavaMail.root@mailhub022.itcs.purdue.edu>
Date: Wed, 28 Nov 2012 13:27:25 -0800
Content-Transfer-Encoding: quoted-printable
Message-Id: <75DCAA86-EF9A-4401-B125-0FFC5E743667@cs.stanford.edu>
References: <157212510.61589.1352318118568.JavaMail.root@mailhub022.itcs.purdue.edu>
To: Duong Ngoc Nguyen 
X-Mailer: Apple Mail (2.1283)
X-Scan-Signature: fb418a055a615a79fddacbea7bf2a8e8
Cc: roll@ietf.org
Subject: Re: [Roll] Some confusions in RFC 6719 (MRHOF)
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Routing Over Low power and Lossy networks 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 28 Nov 2012 21:27:22 -0000

Phil

On Nov 7, 2012, at 11:55 AM, Duong Ngoc Nguyen wrote:

> As I work with MRHOF, I find some statements are not consistent that I =
cannot resolve by myself. I'm very grateful if someone can help me =
overcome this confusion.
>=20
> 1. Which path cost is carried in Metric Container?
>=20
> Section 3.2.2 states:
>=20
>   Once the preferred parent is selected, the node sets its
>   cur_min_path_cost variable to the path cost corresponding to the
>   preferred parent.  The value of the cur_min_path_cost is carried in
>   the Metric Container corresponding to the selected metric when DIO
>   messages are sent.
>=20
> =3D=3D> it suggests Metric Container carries the cost through the best =
(i.e. preferred) parent.
>=20
> While section 3.4 states:
>=20
>   Once the preferred parent is selected, the node sets its
>   cur_min_path_cost variable to the path cost corresponding to its
>   preferred parent.  It then calculates the metric it will advertise =
in
>   its metric container.  This value is the path cost of the member of
>   the parent set with the highest path cost.  Thus, while
>   cur_min_path_cost is the cost through the preferred parent, a node
>   advertises the highest cost path from the node to the root through a
>   member of the parent set.  The value of the highest cost path is
>   carried in the metric container corresponding to the selected metric
>   when DIO messages are sent.
>=20
> =3D=3D> it suggests Metric Container carries the cost through the =
worst parent.

3.4 is correct.

> 2. Which value is written to Rank field of DIO messsage's base object =
in case ETX is used?
>=20
> When ETX is the metric, node must not include Metric container, thus =
the rank field in DIO's base object is the only information to advertise =
to neighbors.
>=20
> Section 3.4 states:
>=20
>   If ETX is the selected metric, a node MUST NOT advertise it in a
>   metric container.  Instead, a node MUST advertise an approximation =
of
>   its ETX in its advertised Rank value, following the rules described
>   in Section 3.3...
>=20
> =3D=3D> The phrase "in its advertised Rank value, following the rules =
described in Section 3.3." means we would write the value of node rank =
(computed by rules in section 3.3) into the rank field of DIO message.
>=20
> On the other hand, section 3.5 states:
>=20
>   ... Once parent selection and rank computation is performed
>   using the ETX metric, the node advertises the Rank and MUST NOT
>   include a metric container in its DIO messages.  While assigning =
Rank
>   in this case, use the representation of ETX described in [RFC6551],
>   i.e., assign Rank equal to ETX * 128.
>=20
> =3D=3D> The phrase "assign Rank equal to ETX * 128" suggests that we =
should write value of ETX of path cost to the rank field of DIO message.
>=20

3.4 is correct. The term "assign" is meant to describe the =
transformation between ETX and rank values, not the Rank in the DIO.

Phil=

From nduong@purdue.edu  Thu Nov 29 05:45:24 2012
Return-Path: 
X-Original-To: roll@ietfa.amsl.com
Delivered-To: roll@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6932021F89F3 for ; Thu, 29 Nov 2012 05:45:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level: 
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3h0CmH9Gcr8v for ; Thu, 29 Nov 2012 05:45:23 -0800 (PST)
Received: from mailhub130.itcs.purdue.edu (mailhub130.itcs.purdue.edu [128.210.5.130]) by ietfa.amsl.com (Postfix) with ESMTP id AEA2F21F89F4 for ; Thu, 29 Nov 2012 05:45:19 -0800 (PST)
Received: from mailhub022.itcs.purdue.edu (mailhub022.itcs.purdue.edu [128.210.5.22]) by mailhub130.itcs.purdue.edu (8.14.4/8.14.4/mta-nopmx.smtp.purdue.edu) with ESMTP id qATDjE6b019938; Thu, 29 Nov 2012 08:45:14 -0500
Date: Thu, 29 Nov 2012 08:45:14 -0500 (EST)
From: Duong Ngoc Nguyen 
To: Philip Levis 
Message-ID: <1302650519.102474.1354196714342.JavaMail.root@mailhub022.itcs.purdue.edu>
In-Reply-To: <75DCAA86-EF9A-4401-B125-0FFC5E743667@cs.stanford.edu>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
X-Originating-IP: [128.210.5.221]
X-Mailer: Zimbra 6.0.10_GA_2692 (ZimbraWebClient - SAF3 (Linux)/6.0.10_GA_2692)
X-PMX-Version: 5.5.9.388399
X-PerlMx-Virus-Scanned: Yes
Cc: roll@ietf.org
Subject: Re: [Roll] Some confusions in RFC 6719 (MRHOF)
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Routing Over Low power and Lossy networks 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 29 Nov 2012 13:45:24 -0000

Thanks.

Sincerely,
Duong Nguyen

----- Original Message -----
> From: "Philip Levis" 
> To: "Duong Ngoc Nguyen" 
> Cc: roll@ietf.org
> Sent: Wednesday, November 28, 2012 4:27:25 PM
> Subject: Re: [Roll] Some confusions in RFC 6719 (MRHOF)
> Phil
> 
> On Nov 7, 2012, at 11:55 AM, Duong Ngoc Nguyen wrote:
> 
> > As I work with MRHOF, I find some statements are not consistent that
> > I cannot resolve by myself. I'm very grateful if someone can help me
> > overcome this confusion.
> >
> > 1. Which path cost is carried in Metric Container?
> >
> > Section 3.2.2 states:
> >
> >   Once the preferred parent is selected, the node sets its
> >   cur_min_path_cost variable to the path cost corresponding to the
> >   preferred parent. The value of the cur_min_path_cost is carried in
> >   the Metric Container corresponding to the selected metric when DIO
> >   messages are sent.
> >
> > ==> it suggests Metric Container carries the cost through the best
> > (i.e. preferred) parent.
> >
> > While section 3.4 states:
> >
> >   Once the preferred parent is selected, the node sets its
> >   cur_min_path_cost variable to the path cost corresponding to its
> >   preferred parent. It then calculates the metric it will advertise
> >   in
> >   its metric container. This value is the path cost of the member of
> >   the parent set with the highest path cost. Thus, while
> >   cur_min_path_cost is the cost through the preferred parent, a node
> >   advertises the highest cost path from the node to the root through
> >   a
> >   member of the parent set. The value of the highest cost path is
> >   carried in the metric container corresponding to the selected
> >   metric
> >   when DIO messages are sent.
> >
> > ==> it suggests Metric Container carries the cost through the worst
> > parent.
> 
> 3.4 is correct.
> 
> > 2. Which value is written to Rank field of DIO messsage's base
> > object in case ETX is used?
> >
> > When ETX is the metric, node must not include Metric container, thus
> > the rank field in DIO's base object is the only information to
> > advertise to neighbors.
> >
> > Section 3.4 states:
> >
> >   If ETX is the selected metric, a node MUST NOT advertise it in a
> >   metric container. Instead, a node MUST advertise an approximation
> >   of
> >   its ETX in its advertised Rank value, following the rules
> >   described
> >   in Section 3.3...
> >
> > ==> The phrase "in its advertised Rank value, following the rules
> > described in Section 3.3." means we would write the value of node
> > rank (computed by rules in section 3.3) into the rank field of DIO
> > message.
> >
> > On the other hand, section 3.5 states:
> >
> >   ... Once parent selection and rank computation is performed
> >   using the ETX metric, the node advertises the Rank and MUST NOT
> >   include a metric container in its DIO messages. While assigning
> >   Rank
> >   in this case, use the representation of ETX described in
> >   [RFC6551],
> >   i.e., assign Rank equal to ETX * 128.
> >
> > ==> The phrase "assign Rank equal to ETX * 128" suggests that we
> > should write value of ETX of path cost to the rank field of DIO
> > message.
> >
> 
> 3.4 is correct. The term "assign" is meant to describe the
> transformation between ETX and rank values, not the Rank in the DIO.
> 
> Phil

From trac+roll@trac.tools.ietf.org  Fri Nov 30 11:12:29 2012
Return-Path: 
X-Original-To: roll@ietfa.amsl.com
Delivered-To: roll@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6AC3821F8B4E for ; Fri, 30 Nov 2012 11:12:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level: 
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O9SPfIw1KbWU for ; Fri, 30 Nov 2012 11:12:22 -0800 (PST)
Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 1DC1E21F8952 for ; Fri, 30 Nov 2012 11:12:15 -0800 (PST)
Received: from localhost ([127.0.0.1]:42971 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1TeW0R-000186-3J; Fri, 30 Nov 2012 20:12:11 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: "roll issue tracker" 
X-Trac-Version: 0.12.3
Precedence: bulk
Auto-Submitted: auto-generated
X-Mailer: Trac 0.12.3, by Edgewall Software
To: draft-ietf-roll-trickle-mcast@tools.ietf.org, mcr@sandelman.ca
X-Trac-Project: roll
Date: Fri, 30 Nov 2012 19:12:11 -0000
X-URL: http://tools.ietf.org/wg/roll/
X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/roll/trac/ticket/108#comment:1
Message-ID: <073.a55e9385387a6c81240cee76e3187dbf@trac.tools.ietf.org>
References: <058.a2b4f297c2cf9334c783ff7c900bdb13@trac.tools.ietf.org>
X-Trac-Ticket-ID: 108
In-Reply-To: <058.a2b4f297c2cf9334c783ff7c900bdb13@trac.tools.ietf.org>
X-SA-Exim-Connect-IP: 127.0.0.1
X-SA-Exim-Rcpt-To: draft-ietf-roll-trickle-mcast@tools.ietf.org, mcr@sandelman.ca, roll@ietf.org
X-SA-Exim-Mail-From: trac+roll@trac.tools.ietf.org
X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false
Resent-To: jonhui@cisco.com, richard.kelsey@silabs.com
Resent-Message-Id: <20121130191216.1DC1E21F8952@ietfa.amsl.com>
Resent-Date: Fri, 30 Nov 2012 11:12:15 -0800 (PST)
Resent-From: trac+roll@trac.tools.ietf.org
Cc: roll@ietf.org
Subject: Re: [Roll] [roll] #108: trickle-mcast: should there be an explicit version field?
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.12
Reply-To: roll@ietf.org
List-Id: Routing Over Low power and Lossy networks 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 30 Nov 2012 19:12:29 -0000

#108: trickle-mcast: should there be an explicit version field?


Comment (by mcr@sandelman.ca):

 {{{


      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
                                     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                     |  Option Type  |  Opt Data Len |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | S |M|V| rsv   |   sequence    |      seed-id (optional)       |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

 would be adequate where:

 V = version number. Must be set to 0, must be received as 0.

 }}}

-- 
-------------------------+-------------------------------------------------
 Reporter:               |       Owner:  draft-ietf-roll-trickle-
  mcr@sandelman.ca       |  mcast@tools.ietf.org
     Type:  defect       |      Status:  new
 Priority:  major        |   Milestone:
Component:  trickle-     |     Version:
  mcast                  |  Resolution:
 Severity:  In WG Last   |
  Call                   |
 Keywords:               |
-------------------------+-------------------------------------------------

Ticket URL: 
roll